From whuang at openjdk.java.net Tue Jun 1 03:21:57 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Tue, 1 Jun 2021 03:21:57 GMT Subject: [vectorIntrinsics] RFR: 8266286: Add LoadVectorGather and StoreVectorScatter's partial version [v2] In-Reply-To: References: Message-ID: > * Add LoadVectorGather and StoreVectorScatter's partial version > * use `sve_whilelo` Wang Huang has updated the pull request incrementally with one additional commit since the last revision: fix style ------------- Changes: - all: https://git.openjdk.java.net/panama-vector/pull/88/files - new: https://git.openjdk.java.net/panama-vector/pull/88/files/dd909962..4f0c1273 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=88&range=01 - incr: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=88&range=00-01 Stats: 154 lines in 2 files changed: 66 ins; 64 del; 24 mod Patch: https://git.openjdk.java.net/panama-vector/pull/88.diff Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/88/head:pull/88 PR: https://git.openjdk.java.net/panama-vector/pull/88 From whuang at openjdk.java.net Tue Jun 1 03:22:00 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Tue, 1 Jun 2021 03:22:00 GMT Subject: [vectorIntrinsics] RFR: 8266286: Add LoadVectorGather and StoreVectorScatter's partial version [v2] In-Reply-To: References: Message-ID: On Mon, 31 May 2021 08:19:10 GMT, Ningsheng Jian wrote: >> src/hotspot/cpu/aarch64/aarch64_sve.ad line 4175: >> >>> 4173: n->as_LoadVectorGather()->memory_size() < MaxVectorSize && >>> 4174: (n->bottom_type()->is_vect()->element_basic_type() == T_INT || >>> 4175: n->bottom_type()->is_vect()->element_basic_type() == T_FLOAT)); >> >> Style nit: add one more space at the beginning of these lines to have better indentation? > >> Style nit: add one more space at the beginning of these lines to have better indentation? > > One more nit: I would suggest to group those gather partial rules together with other gather rules, as well as scatter parts. Sure. I will change that. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/88 From njian at openjdk.java.net Tue Jun 1 03:24:40 2021 From: njian at openjdk.java.net (Ningsheng Jian) Date: Tue, 1 Jun 2021 03:24:40 GMT Subject: [vectorIntrinsics] RFR: 8266286: Add LoadVectorGather and StoreVectorScatter's partial version [v2] In-Reply-To: References: Message-ID: On Tue, 1 Jun 2021 03:21:57 GMT, Wang Huang wrote: >> * Add LoadVectorGather and StoreVectorScatter's partial version >> * use `sve_whilelo` > > Wang Huang has updated the pull request incrementally with one additional commit since the last revision: > > fix style Marked as reviewed by njian (Committer). ------------- PR: https://git.openjdk.java.net/panama-vector/pull/88 From whuang at openjdk.java.net Tue Jun 1 06:23:34 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Tue, 1 Jun 2021 06:23:34 GMT Subject: [vectorIntrinsics] Integrated: 8266286: Add LoadVectorGather and StoreVectorScatter's partial version In-Reply-To: References: Message-ID: On Mon, 31 May 2021 07:20:20 GMT, Wang Huang wrote: > * Add LoadVectorGather and StoreVectorScatter's partial version > * use `sve_whilelo` This pull request has now been integrated. Changeset: 73e78a37 Author: Wang Huang URL: https://git.openjdk.java.net/panama-vector/commit/73e78a3700b5586e6252e779885d9a1eab9ba645 Stats: 202 lines in 2 files changed: 178 ins; 8 del; 16 mod 8266286: Add LoadVectorGather and StoreVectorScatter's partial version Co-authored-by: Wang Huang Co-authored-by: Ai Jiaming Reviewed-by: xgong, njian ------------- PR: https://git.openjdk.java.net/panama-vector/pull/88 From jvernee at openjdk.java.net Tue Jun 1 09:53:29 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Tue, 1 Jun 2021 09:53:29 GMT Subject: [foreign-memaccess+abi] RFR: 8267989: Exceptions thrown during upcalls should be handled [v2] In-Reply-To: References: <7Opm0PCCmpX2e_YCCafEFoEhuBbyKTLQ6ZMD4Y0fw1w=.bdabcf7e-80b0-4e24-9a6e-c3f311cb25fb@github.com> <8wv2DfSZyAbpoSJ-lv3LCoStYLg-Jmy685BQd19LaDA=.2c5421ab-8730-4a64-b32b-2b3fc5f30b91@github.com> Message-ID: On Mon, 31 May 2021 21:12:48 GMT, Maurizio Cimadamore wrote: >> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: >> >> Address review comments: >> - tweak documentation >> - remove system property >> - simplify test & check stderr for stack trace message > > src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java line 119: > >> 117: * @see CLinker#upcallStub(MethodHandle, FunctionDescriptor, ResourceScope) >> 118: */ >> 119: int ERR_UNCAUGHT_EXCEPTION = 1; > > On a second thought, I'm not super sure of the value of documenting what the exit code should be? Maybe we can leave that unspecified? I agree. Without a system property, having a constant doesn't really make sense. I looked around in the documentation of exit codes in the JDK, and most places seem to at least specify the exit code to be non-zero in case of error. I'll add a note like that to the documentation of upcallStub. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/543 From jvernee at openjdk.java.net Tue Jun 1 12:00:10 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Tue, 1 Jun 2021 12:00:10 GMT Subject: [foreign-memaccess+abi] RFR: 8267989: Exceptions thrown during upcalls should be handled [v3] In-Reply-To: <7Opm0PCCmpX2e_YCCafEFoEhuBbyKTLQ6ZMD4Y0fw1w=.bdabcf7e-80b0-4e24-9a6e-c3f311cb25fb@github.com> References: <7Opm0PCCmpX2e_YCCafEFoEhuBbyKTLQ6ZMD4Y0fw1w=.bdabcf7e-80b0-4e24-9a6e-c3f311cb25fb@github.com> Message-ID: > Hi, > > This patch regularizes exception handling for exceptions thrown during upcalls. Exceptions thrown during upcalls are now always handled by printing out the stack trace and then calling `System::exit` (see the JBS issue for some motivation). > > I've added some documentation for the exception handling to `CLinker::upcallStub`, as well as a new public `int` constant in `CLinker` which is the error code that is passed to `System::exit`. The returned error code can also be configured by a system property, which for now is mostly useful for testing purposes to make sure we don't get a consistent false positive. > > Thanks, > Jorn Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: - remove exit code constant - add security manager into test - use privilegedGetProperty instead of System.getProperty in CABI ------------- Changes: - all: https://git.openjdk.java.net/panama-foreign/pull/543/files - new: https://git.openjdk.java.net/panama-foreign/pull/543/files/668e15df..a7e73a9b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=543&range=02 - incr: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=543&range=01-02 Stats: 76 lines in 7 files changed: 50 ins; 14 del; 12 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/543.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/543/head:pull/543 PR: https://git.openjdk.java.net/panama-foreign/pull/543 From jvernee at openjdk.java.net Tue Jun 1 12:05:27 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Tue, 1 Jun 2021 12:05:27 GMT Subject: [foreign-memaccess+abi] RFR: 8267989: Exceptions thrown during upcalls should be handled [v2] In-Reply-To: <8wv2DfSZyAbpoSJ-lv3LCoStYLg-Jmy685BQd19LaDA=.2c5421ab-8730-4a64-b32b-2b3fc5f30b91@github.com> References: <7Opm0PCCmpX2e_YCCafEFoEhuBbyKTLQ6ZMD4Y0fw1w=.bdabcf7e-80b0-4e24-9a6e-c3f311cb25fb@github.com> <8wv2DfSZyAbpoSJ-lv3LCoStYLg-Jmy685BQd19LaDA=.2c5421ab-8730-4a64-b32b-2b3fc5f30b91@github.com> Message-ID: On Mon, 31 May 2021 18:43:17 GMT, Jorn Vernee wrote: >> Hi, >> >> This patch regularizes exception handling for exceptions thrown during upcalls. Exceptions thrown during upcalls are now always handled by printing out the stack trace and then calling `System::exit` (see the JBS issue for some motivation). >> >> I've added some documentation for the exception handling to `CLinker::upcallStub`, as well as a new public `int` constant in `CLinker` which is the error code that is passed to `System::exit`. The returned error code can also be configured by a system property, which for now is mostly useful for testing purposes to make sure we don't get a consistent false positive. >> >> Thanks, >> Jorn > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments: > - tweak documentation > - remove system property > - simplify test & check stderr for stack trace message I've switched to using `Shutdown.exit`, and added a `SecurityManager` that blocks the normal `System.exit` call into the test. I've also switched `CABI` from using `System.getProperty` to determine the platform, to using `priviledgedGetProperty`, to avoid any security exceptions (found during testing). I've removed the public `ERR_UNCAUGHT_EXCEPTION` constant, and changed the documentation to say that the VM will exit with a non-zero exit status in the case of an uncaught exception. Finally, I've changed the test to always print the output as well, besides checking the contents. I still have to add an eager check (and test) to see if the target of an upcall throws an exception. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/543 From samuel.audet at gmail.com Wed Jun 2 01:03:53 2021 From: samuel.audet at gmail.com (Samuel Audet) Date: Wed, 2 Jun 2021 10:03:53 +0900 Subject: taming resource scopes In-Reply-To: <3cea136a-e273-79f5-72ae-430836804342@oracle.com> References: <27aac969-2291-40e1-e50a-544caab8ee9b@oracle.com> <9683ecf2-948a-2558-ad63-2f2f67d66797@gmail.com> <3cea136a-e273-79f5-72ae-430836804342@oracle.com> Message-ID: <5612ea99-5f4c-3d30-0f78-0739baf798fb@gmail.com> Let's see, I guess what I wanted to say with "concurrent" is "efficient lock-free" and "GC" is "tracing GC". I don't think Rust Arc provides the kind of general mechanism I have in mind, for example, here is an example trying to handle lazily initialized data, which models well resources external to the CPU such as GPUs, FPGAs, etc that need deterministic deallocation: "On my 2012 desktop workstation with 3GHz Xeon W3550, the Java benchmark reports an average of 7.3 ns per getTransformed invocation. The Rust benchmark reports 128 ns in get_transformed, a whopping 17 times slower execution." https://morestina.net/blog/784/exploring-lock-free-rust-3-crossbeam Unless things have changed dramatically in the last couple of years, I don't think Rust Arc offers an efficient and safe mechanism that can be used in all cases. I'm sorry to hear Java isn't going to try to provide something approaching Rust's Arc, but oh well, something is better than nothing. :) Keep up the good work Samuel On 5/31/21 8:57 PM, Maurizio Cimadamore wrote: > > On 30/05/2021 00:18, Samuel Audet wrote: >> Hi, Maurizio, >> >> Thanks for taking the time to write this down! It's all very >> interesting to have a sense of how various resources could be managed. >> >> This is starting to sound a lot like reference counting, and there are >> many implementations out there that use reference counting >> "automatically", most notably Swift. I'm not aware of any concurrent >> thread-safe implementation though, which would be nice if it can be >> achieved in general, but even if that works out, I'm assuming we could >> still end up with reference cycles. What's your thoughts on that >> subject? CPython deals with those with GC... > Hi Samuel, > > I believe Swift's Automatic Reference Counting (not be confused with > Rust's Atomic Reference Counting - the two tragically share the same > acronym :-)) is a form of garbage collection where, rather than having a > separate process grovelling through memory (like the JVM's GC does), > increments and decrements are generated (presumably by the compiler) in > the user code directly, thus achieving a lower footprint solution, which > might be good in certain situations. Of course we know the issues with > reference counting when used as a _general_ mechanism for garbage > collection - the main ones being the inability to deal with cycles, and > another being expensive at dealing with atomicity, as you say. By the > way, the latter _can_ be addressed: in fact, the other ARC, Rust's one, > does exactly that [1], and, in a way, what we do for (shared) resource > scopes is inspired by that work. It is just generally less efficient, as > it involves atomic operations. > > Now, when it comes to resource scopes, it is not our goal to come up > with a perfect and general garbage collection mechanism. If the users > wanted that, well, they could just use the GC itself (and use an > implicit, GC-backed scope). What we're after here is a mechanism which > provides a _reliable_ programming model in the face of deterministic > deallocation. The NIO async [2] use case shows the problem pretty clearly: > > * thread A initiates an async operation on a resource R > * at some point later, thread B picks up resource R and starts working > > In this case, you need to define a "bubble" which starts when thread A > submits the async operation, and finishes when thread B has finished > executing such operation. If R is released between (1) and (2) several > errors, with varying degree of gravity can occur - from an exception to > a VM crash, if the resource is released when the IO operation has > already been submitted to the OS. > > In the document, I note that native calls are not too different from the > async use case. Ideally, you'd like for all resources used by a native > call to remain alive until the native code completes. These kinds of > invariants have to be built _on top_ - classic JVM's garbage collection > cannot help when deterministic deallocation is involved in the picture. > And, while we can use GC-related techniques to speed up access to shared > segment w/o compromising safety, we can only do that if (a) access to a > resource is lexically enclosed (e.g. if you could write a try/finally > block around it - which e.g. you can't do in the async case, as it spans > across multiple threads) and (b) if we can make sure that the number of > the stack frames involved in the resource access is bounded (which is > not the case with native calls, as, with upcalls, the stack during a > native call can grow w/o bounds). > > I think it's also very interesting to notice that, even when working > with a _confined_ segment, you need some way to block deterministic > closure, otherwise you end up with issues in the following case: > > * thread A creates segment S > * thread A passes pointer to S to native code > * native code upcalls to some Java code > * Java code (again, in thread A) closes the scope to which S belongs > * when upcall completes, control returns to native call which attempts to dereference S* > * crash > > Here we only have access from one thread - and even that is not enough > to guarantee safety, as some accesses (those in native code) are > blissfully unaware of the liveness checks occurring in the Java code. > > For these reasons we need some way to define a "bubble" where close > operations are restricted. This is not a new concept, in fact the API > proposed for Java 17 already had a concept of acquire/release; the > document just describes a possible restacking where, instead of dealing > with acquire/release calls directly, clients set up temporal > dependencies between scopes (but under the hood the acquire/release > remains). The only way (I know) to avoid reference counting and still > get benefits of deterministic deallocation would be to track resource > usage at compile-time (e.g. memory ownership) - but, when calls to > foreign functions are involved, not even these more advances systems > would be enough. > > One last note: what we do is not, strictly speaking, reference counting > either :-) Reference counting is symmetric, at least in its classic > definition. The following works: > > ``` > resource.inc(); > // use resource > resource.dec(); > ``` > > But so does this: > > ``` > resource.inc(); > // use resource > resource.dec().dec().dec(); > ``` > > There is something wrong with the latter example, as a client is > attempting to decrement a counter which was incremented by some other > use of the resource. In our API, releasing a scope (or decrementing the > scope counter, if you will), can only be done by the very client that > did the acquire (or increment). This is what makes the API safe - a > plain reference counting mechanism (even if atomic) would have done > nothing for the NIO use case, for instance, as a client could still have > decremented the counter enough times so that a call to close() was > possible, thus defeating the very purpose of the reference counting. > > Maurizio > > [1] - https://doc.rust-lang.org/std/sync/struct.Arc.html > [2] - https://inside.java/2021/04/21/fma-and-nio-channels/ > From whuang at openjdk.java.net Wed Jun 2 03:13:22 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Wed, 2 Jun 2021 03:13:22 GMT Subject: [vectorIntrinsics] RFR: 8266720: Wrong implementation in LibraryCallKit::inline_vector_shuffle_iota [v2] In-Reply-To: References: Message-ID: > Because JDK-8266317 has not been merged into jdk/jdk. So I fix this bug here. > * This comparsion should be a unsigned cmp > * `x86` is not wrong because `x86` does not have 1024-bits vl here. > ```c++ > > ConINode* pred_node = (ConINode*)gvn().makecon(TypeInt::make(BoolTest::ge)); // should BoolTest::ugt > Node * lane_cnt = gvn().makecon(TypeInt::make(num_elem)); > Node * bcast_lane_cnt = gvn().transform(VectorNode::scalar2vector(lane_cnt, num_elem, type_bt)); > // should BoolTest::ugt > Node* mask = gvn().transform(new VectorMaskCmpNode(BoolTest::ge, bcast_lane_cnt, res, pred_node, vt)); Wang Huang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - merge vectorIntrinsics - fix format - 8266720: Wrong implementation in LibraryCallKit::inline_vector_shuffle_iota ------------- Changes: https://git.openjdk.java.net/panama-vector/pull/81/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=81&range=01 Stats: 101 lines in 6 files changed: 99 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/panama-vector/pull/81.diff Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/81/head:pull/81 PR: https://git.openjdk.java.net/panama-vector/pull/81 From whuang at openjdk.java.net Wed Jun 2 08:05:07 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Wed, 2 Jun 2021 08:05:07 GMT Subject: [vectorIntrinsics] RFR: 8266720: Wrong implementation in LibraryCallKit::inline_vector_shuffle_iota [v3] In-Reply-To: References: Message-ID: <1YWES0jFg8uA3GLedDyEbUq-jhROJOIDXoml4RZ3zkw=.2bc9a3c9-1d94-4790-8678-f1f0809ea584@github.com> > Because JDK-8266317 has not been merged into jdk/jdk. So I fix this bug here. > * This comparsion should be a unsigned cmp > * `x86` is not wrong because `x86` does not have 1024-bits vl here. > ```c++ > > ConINode* pred_node = (ConINode*)gvn().makecon(TypeInt::make(BoolTest::ge)); // should BoolTest::ugt > Node * lane_cnt = gvn().makecon(TypeInt::make(num_elem)); > Node * bcast_lane_cnt = gvn().transform(VectorNode::scalar2vector(lane_cnt, num_elem, type_bt)); > // should BoolTest::ugt > Node* mask = gvn().transform(new VectorMaskCmpNode(BoolTest::ge, bcast_lane_cnt, res, pred_node, vt)); Wang Huang has updated the pull request incrementally with one additional commit since the last revision: only fix IR ------------- Changes: - all: https://git.openjdk.java.net/panama-vector/pull/81/files - new: https://git.openjdk.java.net/panama-vector/pull/81/files/781d67cb..bd17e1dc Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=81&range=02 - incr: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=81&range=01-02 Stats: 27 lines in 5 files changed: 13 ins; 13 del; 1 mod Patch: https://git.openjdk.java.net/panama-vector/pull/81.diff Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/81/head:pull/81 PR: https://git.openjdk.java.net/panama-vector/pull/81 From mr.chrisvest at gmail.com Wed Jun 2 08:16:52 2021 From: mr.chrisvest at gmail.com (Chris Vest) Date: Wed, 2 Jun 2021 10:16:52 +0200 Subject: taming resource scopes In-Reply-To: <5612ea99-5f4c-3d30-0f78-0739baf798fb@gmail.com> References: <27aac969-2291-40e1-e50a-544caab8ee9b@oracle.com> <9683ecf2-948a-2558-ad63-2f2f67d66797@gmail.com> <3cea136a-e273-79f5-72ae-430836804342@oracle.com> <5612ea99-5f4c-3d30-0f78-0739baf798fb@gmail.com> Message-ID: You can build an Arc (Atomic Reference Counted) like thing as a library, but without deep language integration it will be easy for the contained reference to escape the Arc. Thankfully MemorySegments will still prevent you from accessing freed memory. An alternative to building a generic Arc is to build specialised atomically reference counting wrappers for each thing you wish to have reference counted, and then delegate calls instead of exposing the inner reference. You still run into problems that, without language integration, object references can be shared without any enforcement of counter adjustments. This makes usage awkward and introduces a new class of bugs that can occur in programs. You might also run into an issue that your object can now be in one of three states: owned, shared, and closed/freed/released ? the distinction between owned and shared is the new thing. Objects that are in a shared state might not support all of the operations of an owned object. Rust tracks this information in the type system as part of the language. I built a prototype buffer implementation where I tracked this information at runtime, but discarded the idea because it is, again, awkward and error prone. There were many places where the code had to check and branch on the owned/shared state, and failure to do so would cause exceptions at runtime. So my point is that Rust and Swift have good reference counting stories because of specific language features, and without similar language features I don't think having a generic or general Arc class in Java will be very helpful. Cheers, Chris On Wed, 2 Jun 2021 at 03:04, Samuel Audet wrote: > Let's see, I guess what I wanted to say with "concurrent" is "efficient > lock-free" and "GC" is "tracing GC". I don't think Rust Arc provides the > kind of general mechanism I have in mind, for example, here is an > example trying to handle lazily initialized data, which models well > resources external to the CPU such as GPUs, FPGAs, etc that need > deterministic deallocation: > > "On my 2012 desktop workstation with 3GHz Xeon W3550, the Java benchmark > reports an average of 7.3 ns per getTransformed invocation. The Rust > benchmark reports 128 ns in get_transformed, a whopping 17 times slower > execution." > https://morestina.net/blog/784/exploring-lock-free-rust-3-crossbeam > > Unless things have changed dramatically in the last couple of years, I > don't think Rust Arc offers an efficient and safe mechanism that can be > used in all cases. > > I'm sorry to hear Java isn't going to try to provide something > approaching Rust's Arc, but oh well, something is better than nothing. > :) Keep up the good work > > Samuel > > On 5/31/21 8:57 PM, Maurizio Cimadamore wrote: > > > > On 30/05/2021 00:18, Samuel Audet wrote: > >> Hi, Maurizio, > >> > >> Thanks for taking the time to write this down! It's all very > >> interesting to have a sense of how various resources could be managed. > >> > >> This is starting to sound a lot like reference counting, and there are > >> many implementations out there that use reference counting > >> "automatically", most notably Swift. I'm not aware of any concurrent > >> thread-safe implementation though, which would be nice if it can be > >> achieved in general, but even if that works out, I'm assuming we could > >> still end up with reference cycles. What's your thoughts on that > >> subject? CPython deals with those with GC... > > Hi Samuel, > > > > I believe Swift's Automatic Reference Counting (not be confused with > > Rust's Atomic Reference Counting - the two tragically share the same > > acronym :-)) is a form of garbage collection where, rather than having a > > separate process grovelling through memory (like the JVM's GC does), > > increments and decrements are generated (presumably by the compiler) in > > the user code directly, thus achieving a lower footprint solution, which > > might be good in certain situations. Of course we know the issues with > > reference counting when used as a _general_ mechanism for garbage > > collection - the main ones being the inability to deal with cycles, and > > another being expensive at dealing with atomicity, as you say. By the > > way, the latter _can_ be addressed: in fact, the other ARC, Rust's one, > > does exactly that [1], and, in a way, what we do for (shared) resource > > scopes is inspired by that work. It is just generally less efficient, as > > it involves atomic operations. > > > > Now, when it comes to resource scopes, it is not our goal to come up > > with a perfect and general garbage collection mechanism. If the users > > wanted that, well, they could just use the GC itself (and use an > > implicit, GC-backed scope). What we're after here is a mechanism which > > provides a _reliable_ programming model in the face of deterministic > > deallocation. The NIO async [2] use case shows the problem pretty > clearly: > > > > * thread A initiates an async operation on a resource R > > * at some point later, thread B picks up resource R and starts working > > > > In this case, you need to define a "bubble" which starts when thread A > > submits the async operation, and finishes when thread B has finished > > executing such operation. If R is released between (1) and (2) several > > errors, with varying degree of gravity can occur - from an exception to > > a VM crash, if the resource is released when the IO operation has > > already been submitted to the OS. > > > > In the document, I note that native calls are not too different from the > > async use case. Ideally, you'd like for all resources used by a native > > call to remain alive until the native code completes. These kinds of > > invariants have to be built _on top_ - classic JVM's garbage collection > > cannot help when deterministic deallocation is involved in the picture. > > And, while we can use GC-related techniques to speed up access to shared > > segment w/o compromising safety, we can only do that if (a) access to a > > resource is lexically enclosed (e.g. if you could write a try/finally > > block around it - which e.g. you can't do in the async case, as it spans > > across multiple threads) and (b) if we can make sure that the number of > > the stack frames involved in the resource access is bounded (which is > > not the case with native calls, as, with upcalls, the stack during a > > native call can grow w/o bounds). > > > > I think it's also very interesting to notice that, even when working > > with a _confined_ segment, you need some way to block deterministic > > closure, otherwise you end up with issues in the following case: > > > > * thread A creates segment S > > * thread A passes pointer to S to native code > > * native code upcalls to some Java code > > * Java code (again, in thread A) closes the scope to which S belongs > > * when upcall completes, control returns to native call which attempts > to dereference S* > > * crash > > > > Here we only have access from one thread - and even that is not enough > > to guarantee safety, as some accesses (those in native code) are > > blissfully unaware of the liveness checks occurring in the Java code. > > > > For these reasons we need some way to define a "bubble" where close > > operations are restricted. This is not a new concept, in fact the API > > proposed for Java 17 already had a concept of acquire/release; the > > document just describes a possible restacking where, instead of dealing > > with acquire/release calls directly, clients set up temporal > > dependencies between scopes (but under the hood the acquire/release > > remains). The only way (I know) to avoid reference counting and still > > get benefits of deterministic deallocation would be to track resource > > usage at compile-time (e.g. memory ownership) - but, when calls to > > foreign functions are involved, not even these more advances systems > > would be enough. > > > > One last note: what we do is not, strictly speaking, reference counting > > either :-) Reference counting is symmetric, at least in its classic > > definition. The following works: > > > > ``` > > resource.inc(); > > // use resource > > resource.dec(); > > ``` > > > > But so does this: > > > > ``` > > resource.inc(); > > // use resource > > resource.dec().dec().dec(); > > ``` > > > > There is something wrong with the latter example, as a client is > > attempting to decrement a counter which was incremented by some other > > use of the resource. In our API, releasing a scope (or decrementing the > > scope counter, if you will), can only be done by the very client that > > did the acquire (or increment). This is what makes the API safe - a > > plain reference counting mechanism (even if atomic) would have done > > nothing for the NIO use case, for instance, as a client could still have > > decremented the counter enough times so that a call to close() was > > possible, thus defeating the very purpose of the reference counting. > > > > Maurizio > > > > [1] - https://doc.rust-lang.org/std/sync/struct.Arc.html > > [2] - https://inside.java/2021/04/21/fma-and-nio-channels/ > > > From maurizio.cimadamore at oracle.com Wed Jun 2 10:21:00 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 2 Jun 2021 11:21:00 +0100 Subject: taming resource scopes In-Reply-To: References: <27aac969-2291-40e1-e50a-544caab8ee9b@oracle.com> <9683ecf2-948a-2558-ad63-2f2f67d66797@gmail.com> <3cea136a-e273-79f5-72ae-430836804342@oracle.com> <5612ea99-5f4c-3d30-0f78-0739baf798fb@gmail.com> Message-ID: On 02/06/2021 09:16, Chris Vest wrote: > So my point is that Rust and Swift have good reference counting > stories because of specific language features, and without similar > language features I don't think having a generic or general Arc class > in Java will be very helpful. This is the key observation. Without language help these strategies don't go that far. When I mentioned Arc I was merely observing that the behavior of our pseudo reference counting (only for _shared_ scopes) is more similar to that - but we clearly don't want to add a general purpose Arc - at least not in the scope of this project. In the case of memory segments, I don't expect these kind of locks to be used a lot, honestly. But there are circumstances in which you need to prevent a scope from being closed, in a certain region of code. If you need that, you can use the acquire/release mechanisms we provide (or the scope temporal dependency, which is an higher level way to do the same thing). Maurizio From youngty1997 at gmail.com Wed Jun 2 10:33:09 2021 From: youngty1997 at gmail.com (Ty Young) Date: Wed, 2 Jun 2021 05:33:09 -0500 Subject: taming resource scopes In-Reply-To: References: <27aac969-2291-40e1-e50a-544caab8ee9b@oracle.com> <9683ecf2-948a-2558-ad63-2f2f67d66797@gmail.com> <3cea136a-e273-79f5-72ae-430836804342@oracle.com> <5612ea99-5f4c-3d30-0f78-0739baf798fb@gmail.com> Message-ID: MemorySegments/scopes don't prevent freed memory from being accessed If you enable restricted methods and invoke the CLinker.freeMemory method. This seems like a bug with the method itself since it's officially part of Panama's API, even if part of the "unsafe" part. Custom made free bindings may not automatically call close, of course, but CLinker.freeMemory maybe should? On the topic of free memory, what's the deal with calling free from different bindings/methods? If you do: MemorySegment segment = MemorySegment.allocateNative(4, ResourceScope.newSharedScope()); CLinker.freeMemory(segment.address()); CLinker.freeMemory(segment.address()); or, with hand made bindings: MemorySegment segment = MemorySegment.allocateNative(4, ResourceScope.newSharedScope()); clib.free(segment.address()); clib.free(segment.address()); On Linux you get: free(): double free detected in tcache 2 as expected but mixing free bindings: MemorySegment segment = MemorySegment.allocateNative(4, ResourceScope.newSharedScope()); clib.free(segment.address()); CLinker.freeMemory(segment.address()); gives nothing nor does using the same bindings in different methods.Is this expected? On 6/2/21 3:16 AM, Chris Vest wrote: > You can build an Arc (Atomic Reference Counted) like thing as a library, > but without deep language integration it will be easy for the contained > reference to escape the Arc. > Thankfully MemorySegments will still prevent you from accessing freed > memory. > An alternative to building a generic Arc is to build specialised atomically > reference counting wrappers for each thing you wish to have reference > counted, and then delegate calls instead of exposing the inner reference. > You still run into problems that, without language integration, object > references can be shared without any enforcement of counter adjustments. > This makes usage awkward and introduces a new class of bugs that can occur > in programs. > You might also run into an issue that your object can now be in one of > three states: owned, shared, and closed/freed/released ? the distinction > between owned and shared is the new thing. > Objects that are in a shared state might not support all of the operations > of an owned object. > Rust tracks this information in the type system as part of the language. > I built a prototype buffer implementation where I tracked this information > at runtime, but discarded the idea because it is, again, awkward and error > prone. > There were many places where the code had to check and branch on the > owned/shared state, and failure to do so would cause exceptions at runtime. > So my point is that Rust and Swift have good reference counting stories > because of specific language features, and without similar language > features I don't think having a generic or general Arc class in Java will > be very helpful. > > Cheers, > Chris From maurizio.cimadamore at oracle.com Wed Jun 2 10:43:41 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 2 Jun 2021 11:43:41 +0100 Subject: taming resource scopes In-Reply-To: References: <27aac969-2291-40e1-e50a-544caab8ee9b@oracle.com> <9683ecf2-948a-2558-ad63-2f2f67d66797@gmail.com> <3cea136a-e273-79f5-72ae-430836804342@oracle.com> <5612ea99-5f4c-3d30-0f78-0739baf798fb@gmail.com> Message-ID: On 02/06/2021 11:33, Ty Young wrote: > MemorySegments/scopes don't prevent freed memory from being accessed > If you enable restricted methods and invoke the CLinker.freeMemory > method. This seems like a bug with the method itself since it's > officially part of Panama's API, even if part of the "unsafe" part. > Custom made free bindings may not automatically call close, of course, > but CLinker.freeMemory maybe should? That's the meaning of restricted - if you call these methods, you abandon safety guarantees. In the case of CLinker::freeMemory, the reason this method (and his companion CLinker::allocateMemory) exist, is to provide a plain wrapper around malloc/free. Sometimes native code gives an address to you and expects you to free it. You don't have a segment, nor a scope. You just have an address. The only wa > > > On the topic of free memory, what's the deal with calling free from > different bindings/methods? If you do: > > > MemorySegment segment = MemorySegment.allocateNative(4, > ResourceScope.newSharedScope()); > > CLinker.freeMemory(segment.address()); > CLinker.freeMemory(segment.address()); > > > or, with hand made bindings: > > > MemorySegment segment = MemorySegment.allocateNative(4, > ResourceScope.newSharedScope()); > > clib.free(segment.address()); > clib.free(segment.address()); > > > On Linux you get: > > > free(): double free detected in tcache 2 > > > as expected but mixing free bindings: > > > MemorySegment segment = MemorySegment.allocateNative(4, > ResourceScope.newSharedScope()); > > clib.free(segment.address()); > CLinker.freeMemory(segment.address()); > > > gives nothing nor does using the same bindings in different methods.Is > this expected? First, you should never mix safe segments with unsafe, restricted code. CLinker::freeMemory is not something you should look at if you are after writing safe code. I explained above when these methods are meant to be used. The message you see come from the guts of `free`. As long as your clib::free indeed point to the same free function, then the difference is probably explained in terms of a failure in the heuristics which detects double free. If your clib::free links a _different_ free method, then this is more expected, as different allocators typically do not cooperate with each other. But since you are seeing same problem with calling same free binding on different methods, I'd put that down to a failure in heuristics. But the point remains: CLinker::free offers (as you can see) no safety guarantees - which is why it's a restricted method and why you have to pass a flag on the command line to use it. Maurizio > > > On 6/2/21 3:16 AM, Chris Vest wrote: >> You can build an Arc (Atomic Reference Counted) like thing as a library, >> but without deep language integration it will be easy for the contained >> reference to escape the Arc. >> Thankfully MemorySegments will still prevent you from accessing freed >> memory. >> An alternative to building a generic Arc is to build specialised >> atomically >> reference counting wrappers for each thing you wish to have reference >> counted, and then delegate calls instead of exposing the inner >> reference. >> You still run into problems that, without language integration, object >> references can be shared without any enforcement of counter adjustments. >> This makes usage awkward and introduces a new class of bugs that can >> occur >> in programs. >> You might also run into an issue that your object can now be in one of >> three states: owned, shared, and closed/freed/released ? the distinction >> between owned and shared is the new thing. >> Objects that are in a shared state might not support all of the >> operations >> of an owned object. >> Rust tracks this information in the type system as part of the language. >> I built a prototype buffer implementation where I tracked this >> information >> at runtime, but discarded the idea because it is, again, awkward and >> error >> prone. >> There were many places where the code had to check and branch on the >> owned/shared state, and failure to do so would cause exceptions at >> runtime. >> So my point is that Rust and Swift have good reference counting stories >> because of specific language features, and without similar language >> features I don't think having a generic or general Arc class in Java >> will >> be very helpful. >> >> Cheers, >> Chris From youngty1997 at gmail.com Wed Jun 2 11:29:09 2021 From: youngty1997 at gmail.com (Ty Young) Date: Wed, 2 Jun 2021 06:29:09 -0500 Subject: taming resource scopes In-Reply-To: References: <27aac969-2291-40e1-e50a-544caab8ee9b@oracle.com> <9683ecf2-948a-2558-ad63-2f2f67d66797@gmail.com> <3cea136a-e273-79f5-72ae-430836804342@oracle.com> <5612ea99-5f4c-3d30-0f78-0739baf798fb@gmail.com> Message-ID: <444a4010-9078-1551-39e6-5db3299d072d@gmail.com> On 6/2/21 5:43 AM, Maurizio Cimadamore wrote: > > On 02/06/2021 11:33, Ty Young wrote: >> MemorySegments/scopes don't prevent freed memory from being accessed >> If you enable restricted methods and invoke the CLinker.freeMemory >> method. This seems like a bug with the method itself since it's >> officially part of Panama's API, even if part of the "unsafe" part. >> Custom made free bindings may not automatically call close, of >> course, but CLinker.freeMemory maybe should? > That's the meaning of restricted - if you call these methods, you > abandon safety guarantees. In the case of CLinker::freeMemory, the > reason this method (and his companion CLinker::allocateMemory) exist, > is to provide a plain wrapper around malloc/free. Sometimes native > code gives an address to you and expects you to free it. You don't > have a segment, nor a scope. You just have an address. The only wa Then just returning a primitive address would probably be better then, right? Maybe an override could be added that accepts a primitive long and does what freeMemory does now while modifying the existing method that accepts a MemoryAddress to call close maybe? free knows nothing about MemoryAddress or scopes yet the method takes in a MemoryAddress and doesn't invalidate the scope by calling close, all of which are Panama related and, again, have nothing to do with free. It just feels off since MemoryAddress isn't *just* a wrapper around a long anymore but has a scope tied to it. I can do this myself with custom bindings, I guess. >> >> >> On the topic of free memory, what's the deal with calling free from >> different bindings/methods? If you do: >> >> >> MemorySegment segment = MemorySegment.allocateNative(4, >> ResourceScope.newSharedScope()); >> >> CLinker.freeMemory(segment.address()); >> CLinker.freeMemory(segment.address()); >> >> >> or, with hand made bindings: >> >> >> MemorySegment segment = MemorySegment.allocateNative(4, >> ResourceScope.newSharedScope()); >> >> clib.free(segment.address()); >> clib.free(segment.address()); >> >> >> On Linux you get: >> >> >> free(): double free detected in tcache 2 >> >> >> as expected but mixing free bindings: >> >> >> MemorySegment segment = MemorySegment.allocateNative(4, >> ResourceScope.newSharedScope()); >> >> clib.free(segment.address()); >> CLinker.freeMemory(segment.address()); >> >> >> gives nothing nor does using the same bindings in different >> methods.Is this expected? > > First, you should never mix safe segments with unsafe, restricted > code. CLinker::freeMemory is not something you should look at if you > are after writing safe code. I explained above when these methods are > meant to be used. > > The message you see come from the guts of `free`. As long as your > clib::free indeed point to the same free function, then the difference > is probably explained in terms of a failure in the heuristics which > detects double free. > > If your clib::free links a _different_ free method, then this is more > expected, as different allocators typically do not cooperate with each > other. But since you are seeing same problem with calling same free > binding on different methods, I'd put that down to a failure in > heuristics. > > But the point remains: CLinker::free offers (as you can see) no safety > guarantees - which is why it's a restricted method and why you have to > pass a flag on the command line to use it. I'm more than fully aware about the safety guareantees. I just wasn't sure if this was an issue with Panama. > > Maurizio > >> >> >> On 6/2/21 3:16 AM, Chris Vest wrote: >>> You can build an Arc (Atomic Reference Counted) like thing as a >>> library, >>> but without deep language integration it will be easy for the contained >>> reference to escape the Arc. >>> Thankfully MemorySegments will still prevent you from accessing freed >>> memory. >>> An alternative to building a generic Arc is to build specialised >>> atomically >>> reference counting wrappers for each thing you wish to have reference >>> counted, and then delegate calls instead of exposing the inner >>> reference. >>> You still run into problems that, without language integration, object >>> references can be shared without any enforcement of counter >>> adjustments. >>> This makes usage awkward and introduces a new class of bugs that can >>> occur >>> in programs. >>> You might also run into an issue that your object can now be in one of >>> three states: owned, shared, and closed/freed/released ? the >>> distinction >>> between owned and shared is the new thing. >>> Objects that are in a shared state might not support all of the >>> operations >>> of an owned object. >>> Rust tracks this information in the type system as part of the >>> language. >>> I built a prototype buffer implementation where I tracked this >>> information >>> at runtime, but discarded the idea because it is, again, awkward and >>> error >>> prone. >>> There were many places where the code had to check and branch on the >>> owned/shared state, and failure to do so would cause exceptions at >>> runtime. >>> So my point is that Rust and Swift have good reference counting stories >>> because of specific language features, and without similar language >>> features I don't think having a generic or general Arc class in Java >>> will >>> be very helpful. >>> >>> Cheers, >>> Chris From maurizio.cimadamore at oracle.com Wed Jun 2 11:53:50 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 2 Jun 2021 12:53:50 +0100 Subject: taming resource scopes In-Reply-To: <444a4010-9078-1551-39e6-5db3299d072d@gmail.com> References: <27aac969-2291-40e1-e50a-544caab8ee9b@oracle.com> <9683ecf2-948a-2558-ad63-2f2f67d66797@gmail.com> <3cea136a-e273-79f5-72ae-430836804342@oracle.com> <5612ea99-5f4c-3d30-0f78-0739baf798fb@gmail.com> <444a4010-9078-1551-39e6-5db3299d072d@gmail.com> Message-ID: <91af7cd5-3dd2-ca24-d713-e0e496da4b36@oracle.com> On 02/06/2021 12:29, Ty Young wrote: > Then just returning a primitive address would probably be better then, > right? Maybe an override could be added that accepts a primitive long > and does what freeMemory does now while modifying the existing method > that accepts a MemoryAddress to call close maybe? If CLinker::allocateMemory returned a plain `long`, it would be more awkward to interact with it - e.g. to create an unsafe segment out of it. > > > free knows nothing about MemoryAddress or scopes yet the method takes > in a MemoryAddress and doesn't invalidate the scope by calling close, > all of which are Panama related and, again, have nothing to do with > free. It just feels off since MemoryAddress isn't *just* a wrapper > around a long anymore but has a scope tied to it. It seems like you are reading too much from the method signature alone. We could add an extra check to make sure that the address passed in has the global scope - but it seems like of dubious value, and would likely restrict usability. Note that "being attached to a scope" doesn't necessarily means that the scope is gonna call "free": ``` var scope = ... var addr = CLinker.allocateMemory(100); var segment = addr.asSegment(100, scope) ``` Here, `addr` is attached to `scope` - but that doesn't mean an awful lot, as no cleanup action is defined (and even if a cleanup action was defined, maybe that cleanup action would just do logging, and not call "free"). But, stepping back, if you find yourself in a situation where you want to call CLinker::freeMemory and you don't know if the address comes from a (safe) segment, or just native code/unsafe allocation, I believe there should be other (better) ways to solve that problem, rather than having the unsafe CLinker::freeMemory deal with the mismatch. These API are useful to create "unsafe" segments - e.g. ``` var scope = ... var addr = CLinker.allocateMemory(100); var segment = addr.asSegment(100, () -> CLinker.freeMemory(addr), scope) ``` This gives you a segment backed by malloc which, when `scope` is closed, will automatically call `free` on the address. So, from the point of view of clients of this unsafe segment, it's just another segment. Attempting to dereference will be subject to bound checks and, since deallocation will occur via ResourceScope::close that will be checked too. There are of course cases where you don't want to create a segment (this is the case of pooled allocator, see [1]) - but in those cases the user is definitively in "sudo" mode (e.g. I know what I'm doing, don't bother me with checks which, in fact, would only slow things down, since I know usage is correct). Maurizio [1] - https://git.openjdk.java.net/panama-foreign/pull/509 > > > I can do this myself with custom bindings, I guess. From jvernee at openjdk.java.net Wed Jun 2 12:26:20 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 2 Jun 2021 12:26:20 GMT Subject: [foreign-memaccess+abi] RFR: 8267989: Exceptions thrown during upcalls should be handled [v4] In-Reply-To: <7Opm0PCCmpX2e_YCCafEFoEhuBbyKTLQ6ZMD4Y0fw1w=.bdabcf7e-80b0-4e24-9a6e-c3f311cb25fb@github.com> References: <7Opm0PCCmpX2e_YCCafEFoEhuBbyKTLQ6ZMD4Y0fw1w=.bdabcf7e-80b0-4e24-9a6e-c3f311cb25fb@github.com> Message-ID: > Hi, > > This patch regularizes exception handling for exceptions thrown during upcalls. Exceptions thrown during upcalls are now always handled by printing out the stack trace and then calling `System::exit` (see the JBS issue for some motivation). > > I've added some documentation for the exception handling to `CLinker::upcallStub`, as well as a new public `int` constant in `CLinker` which is the error code that is passed to `System::exit`. The returned error code can also be configured by a system property, which for now is mostly useful for testing purposes to make sure we don't get a consistent false positive. > > Thanks, > Jorn Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: Eagerly check whether upcall target throws any exceptions. Adapt the existing exception check done by MemoryHandles to be more lenient towards bound method handles which might or might not throw an exception, and re-use that check. ------------- Changes: - all: https://git.openjdk.java.net/panama-foreign/pull/543/files - new: https://git.openjdk.java.net/panama-foreign/pull/543/files/a7e73a9b..2a602b0a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=543&range=03 - incr: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=543&range=02-03 Stats: 145 lines in 12 files changed: 90 ins; 18 del; 37 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/543.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/543/head:pull/543 PR: https://git.openjdk.java.net/panama-foreign/pull/543 From jvernee at openjdk.java.net Wed Jun 2 12:33:46 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 2 Jun 2021 12:33:46 GMT Subject: [foreign-memaccess+abi] RFR: 8267989: Exceptions thrown during upcalls should be handled [v4] In-Reply-To: References: <7Opm0PCCmpX2e_YCCafEFoEhuBbyKTLQ6ZMD4Y0fw1w=.bdabcf7e-80b0-4e24-9a6e-c3f311cb25fb@github.com> Message-ID: <7PROAjkwtzhM9Oi661HAR2Dm0BBNlPYP0my2h8vvQA0=.b07ac719-00aa-49e9-b141-6af73646bdb1@github.com> On Wed, 2 Jun 2021 12:26:20 GMT, Jorn Vernee wrote: >> Hi, >> >> This patch regularizes exception handling for exceptions thrown during upcalls. Exceptions thrown during upcalls are now always handled by printing out the stack trace and then calling `System::exit` (see the JBS issue for some motivation). >> >> I've added some documentation for the exception handling to `CLinker::upcallStub`, as well as a new public `int` constant in `CLinker` which is the error code that is passed to `System::exit`. The returned error code can also be configured by a system property, which for now is mostly useful for testing purposes to make sure we don't get a consistent false positive. >> >> Thanks, >> Jorn > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > Eagerly check whether upcall target throws any exceptions. > > Adapt the existing exception check done by MemoryHandles to be more lenient towards bound method handles which might or might not throw an exception, and re-use that check. I've now added the eager exception checking to upcallStub. As discussed offline, this reuses the exception check done for the VarHandle adapters, but makes the check more lenient towards BoundMetrhodHandles that might or might not throw an exception. The current check was too conservative toward rejecting such handles, because it rejects a BoundMehtodHandle that contained any MethodHandle field that could throw an exception. But, such an exception might be caught be an exclosing method handle. (see also https://bugs.openjdk.java.net/browse/JDK-8268031) Instead, when a filter used for a var handle combinator throws a checked a exception when invoked, it is caught, and an IllegalStateException is thrown instead (with the original exception as the cause). ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/543 From jvernee at openjdk.java.net Wed Jun 2 12:41:17 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 2 Jun 2021 12:41:17 GMT Subject: [foreign-memaccess+abi] RFR: 8267989: Exceptions thrown during upcalls should be handled [v5] In-Reply-To: <7Opm0PCCmpX2e_YCCafEFoEhuBbyKTLQ6ZMD4Y0fw1w=.bdabcf7e-80b0-4e24-9a6e-c3f311cb25fb@github.com> References: <7Opm0PCCmpX2e_YCCafEFoEhuBbyKTLQ6ZMD4Y0fw1w=.bdabcf7e-80b0-4e24-9a6e-c3f311cb25fb@github.com> Message-ID: > Hi, > > This patch regularizes exception handling for exceptions thrown during upcalls. Exceptions thrown during upcalls are now always handled by printing out the stack trace and then calling `System::exit` (see the JBS issue for some motivation). > > I've added some documentation for the exception handling to `CLinker::upcallStub`, as well as a new public `int` constant in `CLinker` which is the error code that is passed to `System::exit`. The returned error code can also be configured by a system property, which for now is mostly useful for testing purposes to make sure we don't get a consistent false positive. > > Thanks, > Jorn Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: Fix typo ------------- Changes: - all: https://git.openjdk.java.net/panama-foreign/pull/543/files - new: https://git.openjdk.java.net/panama-foreign/pull/543/files/2a602b0a..9bb8c1a8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=543&range=04 - incr: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=543&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/543.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/543/head:pull/543 PR: https://git.openjdk.java.net/panama-foreign/pull/543 From jvernee at openjdk.java.net Wed Jun 2 12:41:20 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 2 Jun 2021 12:41:20 GMT Subject: [foreign-memaccess+abi] RFR: 8267989: Exceptions thrown during upcalls should be handled [v4] In-Reply-To: References: <7Opm0PCCmpX2e_YCCafEFoEhuBbyKTLQ6ZMD4Y0fw1w=.bdabcf7e-80b0-4e24-9a6e-c3f311cb25fb@github.com> Message-ID: On Wed, 2 Jun 2021 12:26:20 GMT, Jorn Vernee wrote: >> Hi, >> >> This patch regularizes exception handling for exceptions thrown during upcalls. Exceptions thrown during upcalls are now always handled by printing out the stack trace and then calling `System::exit` (see the JBS issue for some motivation). >> >> I've added some documentation for the exception handling to `CLinker::upcallStub`, as well as a new public `int` constant in `CLinker` which is the error code that is passed to `System::exit`. The returned error code can also be configured by a system property, which for now is mostly useful for testing purposes to make sure we don't get a consistent false positive. >> >> Thanks, >> Jorn > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > Eagerly check whether upcall target throws any exceptions. > > Adapt the existing exception check done by MemoryHandles to be more lenient towards bound method handles which might or might not throw an exception, and re-use that check. src/java.base/share/classes/java/lang/invoke/VarHandles.java line 649: > 647: } > 648: > 649: assert handle instanceof BoundMethodHandle : "Unecpexted handle type: " + handle; Suggestion: assert handle instanceof BoundMethodHandle : "Unexpected handle type: " + handle; ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/543 From mcimadamore at openjdk.java.net Wed Jun 2 12:55:46 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 2 Jun 2021 12:55:46 GMT Subject: [foreign-memaccess+abi] RFR: 8267989: Exceptions thrown during upcalls should be handled [v5] In-Reply-To: References: <7Opm0PCCmpX2e_YCCafEFoEhuBbyKTLQ6ZMD4Y0fw1w=.bdabcf7e-80b0-4e24-9a6e-c3f311cb25fb@github.com> Message-ID: On Wed, 2 Jun 2021 12:41:17 GMT, Jorn Vernee wrote: >> Hi, >> >> This patch regularizes exception handling for exceptions thrown during upcalls. Exceptions thrown during upcalls are now always handled by printing out the stack trace and then calling `System::exit` (see the JBS issue for some motivation). >> >> I've added some documentation for the exception handling to `CLinker::upcallStub`, as well as a new public `int` constant in `CLinker` which is the error code that is passed to `System::exit`. The returned error code can also be configured by a system property, which for now is mostly useful for testing purposes to make sure we don't get a consistent false positive. >> >> Thanks, >> Jorn > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > Fix typo Looks very good - thanks for fixing the VH adaptation code as well! ------------- Marked as reviewed by mcimadamore (Committer). PR: https://git.openjdk.java.net/panama-foreign/pull/543 From duke at openjdk.java.net Wed Jun 2 13:08:32 2021 From: duke at openjdk.java.net (duke) Date: Wed, 2 Jun 2021 13:08:32 GMT Subject: git: openjdk/panama-foreign: foreign-jextract: 2 new changesets Message-ID: <6dfde9e9-8cbc-4d32-8790-c22e1218b16b@openjdk.org> Changeset: d1b8b670 Author: Jorn Vernee Date: 2021-06-02 13:06:31 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d1b8b67021f037b362780354b4caa0b77e9c6e29 8267989: Exceptions thrown during upcalls should be handled 8268031: VarHandle combinator check for exceptions is too strict Reviewed-by: mcimadamore ! src/java.base/share/classes/java/lang/System.java ! src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/java.base/share/classes/java/lang/invoke/VarHandles.java ! src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java ! src/java.base/share/classes/jdk/internal/access/JavaLangInvokeAccess.java ! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java ! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemoryHandles.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/CABI.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/ProgrammableUpcallHandler.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/SharedUtils.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/aarch64/AArch64Linker.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/x64/sysv/SysVx64Linker.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/x64/windows/Windowsx64Linker.java ! test/jdk/java/foreign/TestAdaptVarHandles.java ! test/jdk/java/foreign/TestUpcall.java + test/jdk/java/foreign/TestUpcallException.java + test/jdk/java/foreign/ThrowingUpcall.java Changeset: ca5d8780 Author: duke Date: 2021-06-02 13:07:17 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ca5d878092169c9e729403c9b1d4a023adf4e1fb Automatic merge of foreign-memaccess+abi into foreign-jextract From jvernee at openjdk.java.net Wed Jun 2 13:09:47 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 2 Jun 2021 13:09:47 GMT Subject: [foreign-memaccess+abi] Integrated: 8267989: Exceptions thrown during upcalls should be handled In-Reply-To: <7Opm0PCCmpX2e_YCCafEFoEhuBbyKTLQ6ZMD4Y0fw1w=.bdabcf7e-80b0-4e24-9a6e-c3f311cb25fb@github.com> References: <7Opm0PCCmpX2e_YCCafEFoEhuBbyKTLQ6ZMD4Y0fw1w=.bdabcf7e-80b0-4e24-9a6e-c3f311cb25fb@github.com> Message-ID: On Mon, 31 May 2021 17:39:41 GMT, Jorn Vernee wrote: > Hi, > > This patch regularizes exception handling for exceptions thrown during upcalls. Exceptions thrown during upcalls are now always handled by printing out the stack trace and then calling `System::exit` (see the JBS issue for some motivation). > > I've added some documentation for the exception handling to `CLinker::upcallStub`, as well as a new public `int` constant in `CLinker` which is the error code that is passed to `System::exit`. The returned error code can also be configured by a system property, which for now is mostly useful for testing purposes to make sure we don't get a consistent false positive. > > Thanks, > Jorn This pull request has now been integrated. Changeset: d1b8b670 Author: Jorn Vernee URL: https://git.openjdk.java.net/panama-foreign/commit/d1b8b67021f037b362780354b4caa0b77e9c6e29 Stats: 385 lines in 17 files changed: 324 ins; 21 del; 40 mod 8267989: Exceptions thrown during upcalls should be handled 8268031: VarHandle combinator check for exceptions is too strict Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/543 From jvernee at openjdk.java.net Wed Jun 2 14:26:54 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 2 Jun 2021 14:26:54 GMT Subject: Integrated: Merge jdk:master Message-ID: Manual merge of jdk/master into panama-foreign/master ------------- Commit messages: - Merge branch 'jdk_master' into merge_jdk_master - Automatic merge of jdk:master into master - Automatic merge of jdk:master into master - Automatic merge of jdk:master into master - Automatic merge of jdk:master into master - Automatic merge of jdk:master into master - Automatic merge of jdk:master into master - Automatic merge of jdk:master into master - Automatic merge of jdk:master into master - Automatic merge of jdk:master into master - ... and 263 more: https://git.openjdk.java.net/panama-foreign/compare/47677580...7c85d407 The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.java.net/panama-foreign/pull/544/files Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/544.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/544/head:pull/544 PR: https://git.openjdk.java.net/panama-foreign/pull/544 From jvernee at openjdk.java.net Wed Jun 2 14:26:57 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 2 Jun 2021 14:26:57 GMT Subject: Integrated: Merge jdk:master In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 14:16:29 GMT, Jorn Vernee wrote: > Manual merge of jdk/master into panama-foreign/master This pull request has now been integrated. Changeset: 21a08587 Author: Jorn Vernee URL: https://git.openjdk.java.net/panama-foreign/commit/21a0858726d3eaa197dd215e8850075281a416dc Stats: 44163 lines in 2007 files changed: 15771 ins; 23786 del; 4606 mod Merge Manual merge of jdk/master into panama-foreign/master ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/544 From jvernee at openjdk.java.net Wed Jun 2 14:30:47 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 2 Jun 2021 14:30:47 GMT Subject: [foreign-memaccess+abi] RFR: Merge master In-Reply-To: <8inAKVp1NLC1kri0nd35Ri8Efw4s5l5REfBc-cmijPk=.58482dea-c00b-4ac1-8905-afbebdfd34b1@github.com> References: <8inAKVp1NLC1kri0nd35Ri8Efw4s5l5REfBc-cmijPk=.58482dea-c00b-4ac1-8905-afbebdfd34b1@github.com> Message-ID: <7sPw_GUSqm0LH2VQeku9jF4KkMdNiDv1nh5Pjifr_-E=.cd40c2c6-23b2-4d43-80be-15435d3411bb@github.com> On Fri, 28 May 2021 11:01:22 GMT, J. Duke wrote: > Hi all, > > this is an _automatically_ generated pull request to notify you that there are 90 commits from the branch `master`that can **not** be merged into the branch `foreign-memaccess+abi`: > > The following files contains merge conflicts: > > - src/java.base/share/classes/java/lang/Module.java > - src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.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-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 +96:openjdk-bot-96 > $ git checkout openjdk-bot-96 > > # 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-96:96 > > > _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 Closing to redo merge with other changes as well ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/542 From jvernee at openjdk.java.net Wed Jun 2 14:30:47 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 2 Jun 2021 14:30:47 GMT Subject: [foreign-memaccess+abi] Withdrawn: Merge master In-Reply-To: <8inAKVp1NLC1kri0nd35Ri8Efw4s5l5REfBc-cmijPk=.58482dea-c00b-4ac1-8905-afbebdfd34b1@github.com> References: <8inAKVp1NLC1kri0nd35Ri8Efw4s5l5REfBc-cmijPk=.58482dea-c00b-4ac1-8905-afbebdfd34b1@github.com> Message-ID: On Fri, 28 May 2021 11:01:22 GMT, J. Duke wrote: > Hi all, > > this is an _automatically_ generated pull request to notify you that there are 90 commits from the branch `master`that can **not** be merged into the branch `foreign-memaccess+abi`: > > The following files contains merge conflicts: > > - src/java.base/share/classes/java/lang/Module.java > - src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.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-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 +96:openjdk-bot-96 > $ git checkout openjdk-bot-96 > > # 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-96:96 > > > _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 been closed without being integrated. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/542 From duke at openjdk.java.net Wed Jun 2 14:37:58 2021 From: duke at openjdk.java.net (J.Duke) Date: Wed, 2 Jun 2021 14:37:58 GMT Subject: [foreign-memaccess+abi] RFR: Merge master Message-ID: <8s7lJ3gQ_q9zUfXesrqGkO1HoQtprLxYjDqvBSZarHU=.8fcf2a88-b622-465c-9142-dfd5aff5a030@github.com> Hi all, this is an _automatically_ generated pull request to notify you that there are 152 commits from the branch `master`that can **not** be merged into the branch `foreign-memaccess+abi`: Over 63 files contains merge conflicts. 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 +97:openjdk-bot-97 $ git checkout openjdk-bot-97 # 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-97:97 _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: - Merge - 8267920: Create separate Events buffer for VMOperations - 8268094: Some vmTestbase/nsk tests fail after ACC_STRICT/strictfp changes - 8268103: JNI functions incorrectly return a double after JDK-8265836 - 8266459: Implement JEP 411: Deprecate the Security Manager for Removal - 8266281: Assign Symbols to the package selector expression - 8264774: Implementation of Foreign Function and Memory API (Incubator) - 8267118: OutOfMemoryError cannot be caught as a Throwable - 8267459: Pasting Unicode characters into JShell does not work. - 8265270: Type.getEnclosingType() may fail with CompletionFailure - ... and 142 more: https://git.openjdk.java.net/panama-foreign/compare/3241dded...21a08587 The webrev contains the conflicts with foreign-memaccess+abi: - merge conflicts: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=545&range=00.conflicts Changes: https://git.openjdk.java.net/panama-foreign/pull/545/files Stats: 86733 lines in 3517 files changed: 26181 ins; 52310 del; 8242 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/545.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/545/head:pull/545 PR: https://git.openjdk.java.net/panama-foreign/pull/545 From duke at openjdk.java.net Wed Jun 2 16:10:42 2021 From: duke at openjdk.java.net (J.Duke) Date: Wed, 2 Jun 2021 16:10:42 GMT Subject: [foreign-memaccess+abi] RFR: Merge master [v2] In-Reply-To: <8s7lJ3gQ_q9zUfXesrqGkO1HoQtprLxYjDqvBSZarHU=.8fcf2a88-b622-465c-9142-dfd5aff5a030@github.com> References: <8s7lJ3gQ_q9zUfXesrqGkO1HoQtprLxYjDqvBSZarHU=.8fcf2a88-b622-465c-9142-dfd5aff5a030@github.com> Message-ID: > Hi all, > > this is an _automatically_ generated pull request to notify you that there are 152 commits from the branch `master`that can **not** be merged into the branch `foreign-memaccess+abi`: > > Over 63 files contains merge conflicts. > > 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 +97:openjdk-bot-97 > $ git checkout openjdk-bot-97 > > # 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-97:97 > > > _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 789 additional commits since the last revision: - Remove spurious changes - Merge branch 'foreign-memaccess+abi' into openjdk-bot-97 - 8267989: Exceptions thrown during upcalls should be handled 8268031: VarHandle combinator check for exceptions is too strict Reviewed-by: mcimadamore - Automatic merge of master into foreign-memaccess+abi - 8267240: Bounded arena allocator doesn't work if bounded size > BLOCK_SIZE Reviewed-by: jvernee - Remove printf and vprintf tests Reviewed-by: mcimadamore - Automatic merge of master into foreign-memaccess+abi - 8266911: On Windows the system lookup should load ucrtbase if possible Reviewed-by: mcimadamore - 8266916: Simplify logic for creating libSysLookup Reviewed-by: sundar - 8266814: Improve library loading with SymbolLookup abstraction Reviewed-by: jvernee, sundar - ... and 779 more: https://git.openjdk.java.net/panama-foreign/compare/21a08587...4ea25155 ------------- Changes: - all: https://git.openjdk.java.net/panama-foreign/pull/545/files - new: https://git.openjdk.java.net/panama-foreign/pull/545/files/21a08587..4ea25155 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=545&range=01 - incr: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=545&range=00-01 Stats: 1715 lines in 60 files changed: 944 ins; 639 del; 132 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/545.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/545/head:pull/545 PR: https://git.openjdk.java.net/panama-foreign/pull/545 From duke at openjdk.java.net Wed Jun 2 16:10:45 2021 From: duke at openjdk.java.net (J.Duke) Date: Wed, 2 Jun 2021 16:10:45 GMT Subject: [foreign-memaccess+abi] Integrated: Merge master In-Reply-To: <8s7lJ3gQ_q9zUfXesrqGkO1HoQtprLxYjDqvBSZarHU=.8fcf2a88-b622-465c-9142-dfd5aff5a030@github.com> References: <8s7lJ3gQ_q9zUfXesrqGkO1HoQtprLxYjDqvBSZarHU=.8fcf2a88-b622-465c-9142-dfd5aff5a030@github.com> Message-ID: On Wed, 2 Jun 2021 14:29:22 GMT, J. Duke wrote: > Hi all, > > this is an _automatically_ generated pull request to notify you that there are 152 commits from the branch `master`that can **not** be merged into the branch `foreign-memaccess+abi`: > > Over 63 files contains merge conflicts. > > 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 +97:openjdk-bot-97 > $ git checkout openjdk-bot-97 > > # 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-97:97 > > > _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: 1a6aa790 Author: J. Duke Committer: Maurizio Cimadamore URL: https://git.openjdk.java.net/panama-foreign/commit/1a6aa790fee31d31c92e829cdef1a53cac7bb6f2 Stats: 73283 lines in 3379 files changed: 17871 ins; 48932 del; 6480 mod Merge master ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/545 From duke at openjdk.java.net Wed Jun 2 16:25:52 2021 From: duke at openjdk.java.net (duke) Date: Wed, 2 Jun 2021 16:25:52 GMT Subject: git: openjdk/panama-foreign: foreign-jextract: 154 new changesets Message-ID: Changeset: 4ba76138 Author: Nils Eliasson Date: 2021-05-21 14:06:18 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4ba761381c60197be08d34580b92b5203fa9b189 8267332: xor value should handle bounded values Reviewed-by: thartmann, redestad ! src/hotspot/share/opto/addnode.cpp + test/hotspot/jtreg/compiler/types/TestMeetXor.java Changeset: ec8a8097 Author: Jan Lahoda Date: 2021-05-21 14:09:42 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ec8a8097c309920982b0b8253a76c7c938f1f48d 8267119: switch expressions lack support for deferred type-checking Reviewed-by: mcimadamore ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java ! test/langtools/tools/javac/switchexpr/ExpressionSwitch-old.out ! test/langtools/tools/javac/switchexpr/ExpressionSwitch.java Changeset: 94cfeb9c Author: Marcus G K Williams Committer: Stefan Johansson Date: 2021-05-21 14:15:29 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/94cfeb9c4fee2ba5db8e5efa6b0f2041400c8b3a 8256155: Allow multiple large page sizes to be used on Linux Co-authored-by: Marcus G K Williams Co-authored-by: Stefan Johansson Co-authored-by: Thomas Stuefe Reviewed-by: stuefe, sjohanss ! src/hotspot/os/linux/os_linux.cpp ! src/hotspot/os/linux/os_linux.hpp ! src/hotspot/share/runtime/globals.hpp Changeset: 8f10c5a8 Author: Sandhya Viswanathan Date: 2021-05-21 18:15:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8f10c5a8900517cfa04256eab909e18535086b98 8267190: Optimize Vector API test operations Reviewed-by: psandoz, kvn ! src/hotspot/share/opto/vectorIntrinsics.cpp ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/DoubleMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/FloatMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/IntMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/LongMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ShortMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-VectorBits.java.template Changeset: fe333431 Author: Daniel D. Daugherty Date: 2021-05-21 18:32:25 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fe333431c8c0f089e4fd55bf10903e1fba7fc6c4 8256304: should MonitorUsedDeflationThreshold be experimental or diagnostic 8256301: ObjectMonitor::is_busy() should return bool Reviewed-by: coleenp, pchilanomate ! src/hotspot/share/runtime/globals.hpp ! src/hotspot/share/runtime/objectMonitor.cpp ! src/hotspot/share/runtime/objectMonitor.hpp ! src/hotspot/share/runtime/synchronizer.cpp Changeset: 72c9567b Author: Ajit Ghaisas Date: 2021-05-22 03:16:17 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/72c9567b4663fc816e4b85b46ea49b20ea78bd72 8263486: Clean up MTLSurfaceDataBase.h Reviewed-by: serb ! src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLBlitLoops.m ! src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLPipelineStatesStorage.m ! src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLRenderQueue.m ! src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLSurfaceData.m ! src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLSurfaceDataBase.h ! src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLTextRenderer.m Changeset: 24623167 Author: Jaroslav Bachorik Date: 2021-05-22 09:17:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/24623167ffbf8e192ef539fd0a969412719f850c 8261354: SIGSEGV at MethodIteratorHost Reviewed-by: mgronlun ! src/hotspot/share/jfr/recorder/checkpoint/types/jfrTypeSet.cpp Changeset: 4023646e Author: Hui Shi Committer: Jie Fu Date: 2021-05-22 11:51:37 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4023646ed1bcb821b1d18f7e5104f04995e8171d 8266528: Optimize C2 VerifyIterativeGVN execution time Reviewed-by: kvn, thartmann ! src/hotspot/share/opto/node.cpp ! src/hotspot/share/opto/node.hpp ! src/hotspot/share/opto/phaseX.cpp ! test/hotspot/jtreg/compiler/debug/TraceIterativeGVN.java Changeset: 71e2fa25 Author: Aleksey Shipilev Date: 2021-05-22 15:13:06 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/71e2fa25f73b0006a024edb59d79d837227ecd40 8267531: [x86] Assembler::andb(Address,Register) encoding is incorrect Reviewed-by: azeemj, vlivanov, jiefu ! src/hotspot/cpu/x86/assembler_x86.cpp Changeset: 6288a993 Author: Jie Fu Date: 2021-05-22 22:59:55 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6288a9936cc7e69cab0cc5f3e49c803f184bf2ca 8267404: vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java failed with OutOfMemoryError Co-authored-by: xiangyuan Reviewed-by: stuefe ! test/hotspot/jtreg/ProblemList.txt ! test/hotspot/jtreg/vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java Changeset: 4d26f22b Author: Pankaj Bansal Date: 2021-05-23 03:00:48 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4d26f22b9adcf7cecca5316348ef670ac2dbc365 8264304: Create implementation for NSAccessibilityToolbar protocol peer Reviewed-by: kizune ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CommonComponentAccessibility.m = src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ToolbarAccessibility.h + src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ToolbarAccessibility.m Changeset: 31139108 Author: David Holmes Date: 2021-05-24 05:29:55 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/31139108c1ca9d355bd484d692830dfbc8317477 8267553: Extra JavaThread assignment in ClassLoader::create_class_path_entry() Reviewed-by: ccheung ! src/hotspot/share/classfile/classLoader.cpp Changeset: 54520fbf Author: Guoxiong Li Committer: Maurizio Cimadamore Date: 2021-05-24 11:17:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/54520fbf49bb6a7bdcff1a69a0bb46f842bdc054 8267580: The method JavacParser#peekToken is wrong when the first parameter is not zero Reviewed-by: mcimadamore ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java Changeset: 49f622c9 Author: Alexander Zuev Date: 2021-05-24 12:01:54 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/49f622c9473464bf1d1f33b88abf46adadd9fa1c 8208747: [a11y] [macos] In Optionpane Demo, inside ComponentDialog Example, unable to navigate to all items, with VO on Reviewed-by: pbansal ! src/java.desktop/macosx/native/libawt_lwawt/awt/JavaComponentAccessibility.m Changeset: f4531661 Author: Guoxiong Li Committer: Jan Lahoda Date: 2021-05-24 12:31:21 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f4531661b55458554f907ba988eca22b72c72bf3 8267578: Remove unnecessary preview checks Reviewed-by: jlahoda ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java Changeset: d8e6e287 Author: Roger Riggs Date: 2021-05-24 14:10:09 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d8e6e2877aa8a89ad403f06b0adea19c7896d834 8267544: (test) rmi test NonLocalSkeleton fails if network has multiple adapters with the same address Reviewed-by: dfuchs ! test/jdk/java/rmi/registry/nonLocalRegistry/NonLocalSkeletonTest.java Changeset: f5562f12 Author: Vicente Romero Date: 2021-05-24 14:50:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f5562f1214478439899b803f80247d2347a00dab 8258535: jvm.ClassReader should set the accessor to the corresponding record component Reviewed-by: jfranck ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java + test/langtools/tools/javac/processing/model/element/CheckingAccessorsOnLoadedRecordClasses.java Changeset: f2d880c1 Author: Hai-May Chao Date: 2021-05-24 15:38:32 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f2d880c11a99ef587e7e7c0398f0834c32a22d63 8266400: importkeystore fails to a password less pkcs12 keystore Reviewed-by: weijun ! src/java.base/share/classes/sun/security/tools/keytool/Main.java + test/jdk/sun/security/tools/keytool/ImportToPwordlessPK12.java Changeset: 838a0071 Author: Weijun Wang Date: 2021-05-24 15:45:01 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/838a0071030e9c8b9ab57df39a4e0384d433a2bc 8267584: The java.security.krb5.realm system property only needs to be defined once Reviewed-by: mullan ! src/java.security.jgss/share/classes/javax/security/auth/kerberos/KerberosPrincipal.java Changeset: f04db5fb Author: Vicente Romero Date: 2021-05-24 15:55:04 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f04db5fbd77892e94a325942542815bbb24cddea 8224158: assertion related to NPE at DynamicCallSiteDesc::withArgs should be reworded Reviewed-by: jlahoda ! src/java.base/share/classes/java/lang/constant/DynamicCallSiteDesc.java Changeset: 640a2afd Author: Weijun Wang Date: 2021-05-24 16:55:55 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/640a2afda36857410b7abf398af81e35430a62e7 8267184: Add -Djava.security.manager=allow to tests calling System.setSecurityManager Co-authored-by: Lance Andersen Co-authored-by: Weijun Wang Reviewed-by: dholmes, alanb, dfuchs, mchung, mullan, prr ! test/hotspot/jtreg/compiler/exceptions/ExceptionInInit.java ! test/hotspot/jtreg/compiler/jvmci/SecurityRestrictionsTest.java ! test/hotspot/jtreg/runtime/Dictionary/CleanProtectionDomain.java ! test/hotspot/jtreg/runtime/logging/ProtectionDomainVerificationTest.java ! test/hotspot/jtreg/vmTestbase/gc/ArrayJuggle/Juggle11/TestDescription.java ! test/jaxp/javax/xml/jaxp/functional/catalog/CatalogReferCircularityTest.java ! test/jaxp/javax/xml/jaxp/functional/catalog/DefaultFeaturesTest.java ! test/jaxp/javax/xml/jaxp/functional/catalog/DeferFeatureTest.java ! test/jaxp/javax/xml/jaxp/functional/catalog/DelegatePublicTest.java ! test/jaxp/javax/xml/jaxp/functional/catalog/DelegateSystemTest.java ! test/jaxp/javax/xml/jaxp/functional/catalog/DelegateUriTest.java ! test/jaxp/javax/xml/jaxp/functional/catalog/GroupTest.java ! test/jaxp/javax/xml/jaxp/functional/catalog/LoadCatalogTest.java ! test/jaxp/javax/xml/jaxp/functional/catalog/NextCatalogTest.java ! test/jaxp/javax/xml/jaxp/functional/catalog/NormalizationTest.java ! test/jaxp/javax/xml/jaxp/functional/catalog/PreferFeatureTest.java ! test/jaxp/javax/xml/jaxp/functional/catalog/PreferTest.java ! test/jaxp/javax/xml/jaxp/functional/catalog/PublicFamilyTest.java ! test/jaxp/javax/xml/jaxp/functional/catalog/PublicTest.java ! test/jaxp/javax/xml/jaxp/functional/catalog/ResolveFeatureTest.java ! test/jaxp/javax/xml/jaxp/functional/catalog/RewriteSystemTest.java ! test/jaxp/javax/xml/jaxp/functional/catalog/RewriteUriTest.java ! test/jaxp/javax/xml/jaxp/functional/catalog/SpecifyCatalogTest.java ! test/jaxp/javax/xml/jaxp/functional/catalog/SystemFamilyTest.java ! test/jaxp/javax/xml/jaxp/functional/catalog/SystemSuffixTest.java ! test/jaxp/javax/xml/jaxp/functional/catalog/SystemTest.java ! test/jaxp/javax/xml/jaxp/functional/catalog/UriFamilyTest.java ! test/jaxp/javax/xml/jaxp/functional/catalog/UriSuffixTest.java ! test/jaxp/javax/xml/jaxp/functional/catalog/UriTest.java ! test/jaxp/javax/xml/jaxp/functional/catalog/UrnUnwrappingTest.java ! test/jaxp/javax/xml/jaxp/functional/catalog/ValidateCatalogTest.java ! test/jaxp/javax/xml/jaxp/functional/javax/xml/datatype/ptests/DurationTest.java ! test/jaxp/javax/xml/jaxp/functional/javax/xml/datatype/ptests/FactoryNewInstanceTest.java ! test/jaxp/javax/xml/jaxp/functional/javax/xml/datatype/ptests/XMLGregorianCalendarTest.java ! test/jaxp/javax/xml/jaxp/functional/javax/xml/parsers/ptests/DBFNamespaceTest.java ! test/jaxp/javax/xml/jaxp/functional/javax/xml/parsers/ptests/DocumentBuilderFactoryTest.java ! test/jaxp/javax/xml/jaxp/functional/javax/xml/parsers/ptests/DocumentBuilderImpl01.java ! test/jaxp/javax/xml/jaxp/functional/javax/xml/parsers/ptests/FactoryConfErrorTest.java ! test/jaxp/javax/xml/jaxp/functional/javax/xml/parsers/ptests/SAXFactoryNewInstanceTest.java ! test/jaxp/javax/xml/jaxp/functional/javax/xml/parsers/ptests/SAXParserFactTest.java ! test/jaxp/javax/xml/jaxp/functional/javax/xml/parsers/ptests/SAXParserTest.java ! test/jaxp/javax/xml/jaxp/functional/javax/xml/parsers/ptests/SAXParserTest02.java ! test/jaxp/javax/xml/jaxp/functional/javax/xml/parsers/ptests/SAXParserTest03.java ! test/jaxp/javax/xml/jaxp/functional/javax/xml/stream/ptests/XMLEventFactoryNewInstanceTest.java ! test/jaxp/javax/xml/jaxp/functional/javax/xml/stream/ptests/XMLInputFactoryNewInstanceTest.java ! test/jaxp/javax/xml/jaxp/functional/javax/xml/stream/ptests/XMLOutputFactoryNewInstanceTest.java ! test/jaxp/javax/xml/jaxp/functional/javax/xml/transform/ptests/Bug6384418Test.java ! test/jaxp/javax/xml/jaxp/functional/javax/xml/transform/ptests/DOMResultTest.java ! test/jaxp/javax/xml/jaxp/functional/javax/xml/transform/ptests/ErrorListenerTest.java ! test/jaxp/javax/xml/jaxp/functional/javax/xml/transform/ptests/SAXSourceTest.java ! test/jaxp/javax/xml/jaxp/functional/javax/xml/transform/ptests/SAXTFactoryTest.java ! test/jaxp/javax/xml/jaxp/functional/javax/xml/transform/ptests/StreamResultTest.java ! test/jaxp/javax/xml/jaxp/functional/javax/xml/transform/ptests/TfClearParamTest.java ! test/jaxp/javax/xml/jaxp/functional/javax/xml/transform/ptests/TransformTest.java ! test/jaxp/javax/xml/jaxp/functional/javax/xml/transform/ptests/TransformerExcpTest.java ! test/jaxp/javax/xml/jaxp/functional/javax/xml/transform/ptests/TransformerFactoryTest.java ! test/jaxp/javax/xml/jaxp/functional/javax/xml/transform/ptests/TransformerTest.java ! test/jaxp/javax/xml/jaxp/functional/javax/xml/transform/ptests/TransformerTest02.java ! test/jaxp/javax/xml/jaxp/functional/javax/xml/transform/ptests/TransformerTest03.java ! test/jaxp/javax/xml/jaxp/functional/javax/xml/transform/ptests/URIResolverTest.java ! test/jaxp/javax/xml/jaxp/functional/javax/xml/transform/ptests/othervm/TFCErrorTest.java ! test/jaxp/javax/xml/jaxp/functional/javax/xml/validation/ptests/SchemaFactoryTest.java ! test/jaxp/javax/xml/jaxp/functional/javax/xml/validation/ptests/TypeInfoProviderTest.java ! test/jaxp/javax/xml/jaxp/functional/javax/xml/validation/ptests/ValidatorHandlerTest.java ! test/jaxp/javax/xml/jaxp/functional/javax/xml/validation/ptests/ValidatorTest.java ! test/jaxp/javax/xml/jaxp/functional/javax/xml/xpath/ptests/XPathEvaluationResultTest.java ! test/jaxp/javax/xml/jaxp/functional/javax/xml/xpath/ptests/XPathExpressionTest.java ! test/jaxp/javax/xml/jaxp/functional/javax/xml/xpath/ptests/XPathFactoryTest.java ! test/jaxp/javax/xml/jaxp/functional/javax/xml/xpath/ptests/XPathFunctionResolverTest.java ! test/jaxp/javax/xml/jaxp/functional/javax/xml/xpath/ptests/XPathTest.java ! test/jaxp/javax/xml/jaxp/functional/org/w3c/dom/ptests/AttrTest.java ! test/jaxp/javax/xml/jaxp/functional/org/w3c/dom/ptests/CommentTest.java ! test/jaxp/javax/xml/jaxp/functional/org/w3c/dom/ptests/DocumentTest.java ! test/jaxp/javax/xml/jaxp/functional/org/w3c/dom/ptests/DocumentTypeTest.java ! test/jaxp/javax/xml/jaxp/functional/org/w3c/dom/ptests/DomImplementationTest.java ! test/jaxp/javax/xml/jaxp/functional/org/w3c/dom/ptests/ElementTest.java ! test/jaxp/javax/xml/jaxp/functional/org/w3c/dom/ptests/EntityChildTest.java ! test/jaxp/javax/xml/jaxp/functional/org/w3c/dom/ptests/NamedNodeMapTest.java ! test/jaxp/javax/xml/jaxp/functional/org/w3c/dom/ptests/NodeListTest.java ! test/jaxp/javax/xml/jaxp/functional/org/w3c/dom/ptests/NodeTest.java ! test/jaxp/javax/xml/jaxp/functional/org/w3c/dom/ptests/NotationTest.java ! test/jaxp/javax/xml/jaxp/functional/org/w3c/dom/ptests/PITest.java ! test/jaxp/javax/xml/jaxp/functional/org/w3c/dom/ptests/TextTest.java ! test/jaxp/javax/xml/jaxp/functional/org/w3c/dom/ptests/TypeInfoTest.java ! test/jaxp/javax/xml/jaxp/functional/org/xml/sax/ptests/AttrImplTest.java ! test/jaxp/javax/xml/jaxp/functional/org/xml/sax/ptests/AttributesNSTest.java ! test/jaxp/javax/xml/jaxp/functional/org/xml/sax/ptests/AttributesTest.java ! test/jaxp/javax/xml/jaxp/functional/org/xml/sax/ptests/ContentHandlerTest.java ! test/jaxp/javax/xml/jaxp/functional/org/xml/sax/ptests/DefaultHandlerTest.java ! test/jaxp/javax/xml/jaxp/functional/org/xml/sax/ptests/EHFatalTest.java ! test/jaxp/javax/xml/jaxp/functional/org/xml/sax/ptests/NSSupportTest.java ! test/jaxp/javax/xml/jaxp/functional/org/xml/sax/ptests/NSTableTest.java ! test/jaxp/javax/xml/jaxp/functional/org/xml/sax/ptests/ParserAdapterTest.java ! test/jaxp/javax/xml/jaxp/functional/org/xml/sax/ptests/ResolverTest.java ! test/jaxp/javax/xml/jaxp/functional/org/xml/sax/ptests/SAXParserNSTableTest.java ! test/jaxp/javax/xml/jaxp/functional/org/xml/sax/ptests/XMLFilterCBTest.java ! test/jaxp/javax/xml/jaxp/functional/org/xml/sax/ptests/XMLFilterTest.java ! test/jaxp/javax/xml/jaxp/functional/org/xml/sax/ptests/XMLReaderAdapterTest.java ! test/jaxp/javax/xml/jaxp/functional/org/xml/sax/ptests/XMLReaderFactoryTest.java ! test/jaxp/javax/xml/jaxp/functional/org/xml/sax/ptests/XMLReaderNSTableTest.java ! test/jaxp/javax/xml/jaxp/functional/org/xml/sax/ptests/XMLReaderTest.java ! test/jaxp/javax/xml/jaxp/functional/test/astro/AstroTest.java ! test/jaxp/javax/xml/jaxp/functional/test/astro/DocumentLSTest.java ! test/jaxp/javax/xml/jaxp/functional/test/astro/NamespaceContextTest.java ! test/jaxp/javax/xml/jaxp/functional/test/astro/SAX201Test.java ! test/jaxp/javax/xml/jaxp/functional/test/astro/SchemaValidationTest.java ! test/jaxp/javax/xml/jaxp/functional/test/astro/XPathAPITest.java ! test/jaxp/javax/xml/jaxp/functional/test/auctionportal/AuctionController.java ! test/jaxp/javax/xml/jaxp/functional/test/auctionportal/AuctionItemRepository.java ! test/jaxp/javax/xml/jaxp/functional/test/auctionportal/UserController.java ! test/jaxp/javax/xml/jaxp/functional/test/gaptest/Bug4511326.java ! test/jaxp/javax/xml/jaxp/functional/test/gaptest/Bug4512806.java ! test/jaxp/javax/xml/jaxp/functional/test/gaptest/Bug4515047.java ! test/jaxp/javax/xml/jaxp/functional/test/gaptest/Bug4515660.java ! test/jaxp/javax/xml/jaxp/functional/test/gaptest/Bug4693341.java ! test/jaxp/javax/xml/jaxp/functional/test/gaptest/Bug4848653.java ! test/jaxp/javax/xml/jaxp/functional/test/gaptest/Bug4858685.java ! test/jaxp/javax/xml/jaxp/unittest/catalog/CatalogAccessTest.java ! test/jaxp/javax/xml/jaxp/unittest/catalog/CatalogSupport.java ! test/jaxp/javax/xml/jaxp/unittest/catalog/CatalogSupport1.java ! test/jaxp/javax/xml/jaxp/unittest/catalog/CatalogSupport2.java ! test/jaxp/javax/xml/jaxp/unittest/catalog/CatalogSupport3.java ! test/jaxp/javax/xml/jaxp/unittest/catalog/CatalogSupport4.java ! test/jaxp/javax/xml/jaxp/unittest/catalog/CatalogSupport5.java ! test/jaxp/javax/xml/jaxp/unittest/catalog/CatalogTest.java ! test/jaxp/javax/xml/jaxp/unittest/common/Bug6350682.java ! test/jaxp/javax/xml/jaxp/unittest/common/Bug6723276Test.java ! test/jaxp/javax/xml/jaxp/unittest/common/Bug7143711Test.java ! test/jaxp/javax/xml/jaxp/unittest/common/CDataChunkSizeTest.java ! test/jaxp/javax/xml/jaxp/unittest/common/EncodingErrorsReportingTest.java ! test/jaxp/javax/xml/jaxp/unittest/common/Sources.java ! test/jaxp/javax/xml/jaxp/unittest/common/TransformationWarningsTest.java ! test/jaxp/javax/xml/jaxp/unittest/common/ValidationWarningsTest.java ! test/jaxp/javax/xml/jaxp/unittest/common/prettyprint/PrettyPrintTest.java ! test/jaxp/javax/xml/jaxp/unittest/datatype/Bug6320118.java ! test/jaxp/javax/xml/jaxp/unittest/datatype/Bug6937951Test.java ! test/jaxp/javax/xml/jaxp/unittest/datatype/Bug6937964Test.java ! test/jaxp/javax/xml/jaxp/unittest/datatype/Bug7042647Test.java ! test/jaxp/javax/xml/jaxp/unittest/datatype/DatatypeFactoryTest.java ! test/jaxp/javax/xml/jaxp/unittest/datatype/DurationTest.java ! test/jaxp/javax/xml/jaxp/unittest/datatype/FactoryFindTest.java ! test/jaxp/javax/xml/jaxp/unittest/datatype/JDK8068839Test.java ! test/jaxp/javax/xml/jaxp/unittest/datatype/XMLGregorianCalendarTest.java ! test/jaxp/javax/xml/jaxp/unittest/dom/Bug4915524.java ! test/jaxp/javax/xml/jaxp/unittest/dom/Bug4915748.java ! test/jaxp/javax/xml/jaxp/unittest/dom/Bug4966082.java ! test/jaxp/javax/xml/jaxp/unittest/dom/Bug4966138.java ! test/jaxp/javax/xml/jaxp/unittest/dom/Bug4966142.java ! test/jaxp/javax/xml/jaxp/unittest/dom/Bug4966143.java ! test/jaxp/javax/xml/jaxp/unittest/dom/Bug6339023.java ! test/jaxp/javax/xml/jaxp/unittest/dom/Bug6355326.java ! test/jaxp/javax/xml/jaxp/unittest/dom/Bug6367542.java ! test/jaxp/javax/xml/jaxp/unittest/dom/Bug6520131.java ! test/jaxp/javax/xml/jaxp/unittest/dom/Bug6521260.java ! test/jaxp/javax/xml/jaxp/unittest/dom/Bug6582545Test.java ! test/jaxp/javax/xml/jaxp/unittest/dom/Bug6879614Test.java ! test/jaxp/javax/xml/jaxp/unittest/dom/CR6333993Test.java ! test/jaxp/javax/xml/jaxp/unittest/dom/CR6517707Test.java ! test/jaxp/javax/xml/jaxp/unittest/dom/CR6517717Test.java ! test/jaxp/javax/xml/jaxp/unittest/dom/CR6909336Test.java ! test/jaxp/javax/xml/jaxp/unittest/dom/DOMConfigurationTest.java ! test/jaxp/javax/xml/jaxp/unittest/dom/DOMXPathTest.java ! test/jaxp/javax/xml/jaxp/unittest/dom/ElementTraversal.java ! test/jaxp/javax/xml/jaxp/unittest/dom/JdkXmlDomTest.java ! test/jaxp/javax/xml/jaxp/unittest/dom/TCKEncodingTest.java ! test/jaxp/javax/xml/jaxp/unittest/dom/ls/Bug4973153.java ! test/jaxp/javax/xml/jaxp/unittest/dom/ls/Bug6290947.java ! test/jaxp/javax/xml/jaxp/unittest/dom/ls/Bug6354955.java ! test/jaxp/javax/xml/jaxp/unittest/dom/ls/Bug6376823.java ! test/jaxp/javax/xml/jaxp/unittest/dom/ls/Bug6710741Test.java ! test/jaxp/javax/xml/jaxp/unittest/dom/ls/LSParserTCKTest.java ! test/jaxp/javax/xml/jaxp/unittest/dom/ls/LSParserTest.java ! test/jaxp/javax/xml/jaxp/unittest/dom/ls/LSSerializerTest.java ! test/jaxp/javax/xml/jaxp/unittest/parsers/BaseParsingTest.java ! test/jaxp/javax/xml/jaxp/unittest/parsers/Bug4674384_MAX_OCCURS_Test.java ! test/jaxp/javax/xml/jaxp/unittest/parsers/Bug4934208.java ! test/jaxp/javax/xml/jaxp/unittest/parsers/Bug4967002.java ! test/jaxp/javax/xml/jaxp/unittest/parsers/Bug4985486.java ! test/jaxp/javax/xml/jaxp/unittest/parsers/Bug4991020.java ! test/jaxp/javax/xml/jaxp/unittest/parsers/Bug4991946.java ! test/jaxp/javax/xml/jaxp/unittest/parsers/Bug5010072.java ! test/jaxp/javax/xml/jaxp/unittest/parsers/Bug5025825.java ! test/jaxp/javax/xml/jaxp/unittest/parsers/Bug6309988.java ! test/jaxp/javax/xml/jaxp/unittest/parsers/Bug6341770.java ! test/jaxp/javax/xml/jaxp/unittest/parsers/Bug6361283.java ! test/jaxp/javax/xml/jaxp/unittest/parsers/Bug6506304Test.java ! test/jaxp/javax/xml/jaxp/unittest/parsers/Bug6518733.java ! test/jaxp/javax/xml/jaxp/unittest/parsers/Bug6564400.java ! test/jaxp/javax/xml/jaxp/unittest/parsers/Bug6573786.java ! test/jaxp/javax/xml/jaxp/unittest/parsers/Bug6594813.java ! test/jaxp/javax/xml/jaxp/unittest/parsers/Bug6608841.java ! test/jaxp/javax/xml/jaxp/unittest/parsers/Bug6690015.java ! test/jaxp/javax/xml/jaxp/unittest/parsers/Bug6760982.java ! test/jaxp/javax/xml/jaxp/unittest/parsers/Bug6849942Test.java ! test/jaxp/javax/xml/jaxp/unittest/parsers/Bug7157608Test.java ! test/jaxp/javax/xml/jaxp/unittest/parsers/Bug7166896Test.java ! test/jaxp/javax/xml/jaxp/unittest/parsers/Bug8003147Test.java ! test/jaxp/javax/xml/jaxp/unittest/parsers/Bug8073385.java ! test/jaxp/javax/xml/jaxp/unittest/parsers/FactoryFindTest.java ! test/jaxp/javax/xml/jaxp/unittest/parsers/HandleError.java ! test/jaxp/javax/xml/jaxp/unittest/parsers/ParseEmptyStream.java ! test/jaxp/javax/xml/jaxp/unittest/parsers/SupplementaryChars.java ! test/jaxp/javax/xml/jaxp/unittest/parsers/xinclude/Bug6794483Test.java ! test/jaxp/javax/xml/jaxp/unittest/sax/Attributes2ImplTest.java ! test/jaxp/javax/xml/jaxp/unittest/sax/Bug6889654Test.java ! test/jaxp/javax/xml/jaxp/unittest/sax/Bug6925410Test.java ! test/jaxp/javax/xml/jaxp/unittest/sax/Bug6949607Test.java ! test/jaxp/javax/xml/jaxp/unittest/sax/Bug6992561Test.java ! test/jaxp/javax/xml/jaxp/unittest/sax/Bug7057778Test.java ! test/jaxp/javax/xml/jaxp/unittest/sax/DefaultHandler2Test.java ! test/jaxp/javax/xml/jaxp/unittest/sax/IssueTracker56Test.java ! test/jaxp/javax/xml/jaxp/unittest/sax/NSSupportTest.java ! test/jaxp/javax/xml/jaxp/unittest/sax/SymbolTableResetTest.java ! test/jaxp/javax/xml/jaxp/unittest/sax/XMLReaderTest.java ! test/jaxp/javax/xml/jaxp/unittest/stream/AttributeLocalNameTest/AttributeLocalNameTest.java ! test/jaxp/javax/xml/jaxp/unittest/stream/Bug6370703.java ! test/jaxp/javax/xml/jaxp/unittest/stream/Bug6378422.java ! test/jaxp/javax/xml/jaxp/unittest/stream/Bug6380870.java ! test/jaxp/javax/xml/jaxp/unittest/stream/Bug6489502.java ! test/jaxp/javax/xml/jaxp/unittest/stream/Bug6509774.java ! test/jaxp/javax/xml/jaxp/unittest/stream/Bug6688002Test.java ! test/jaxp/javax/xml/jaxp/unittest/stream/Bug6976938Test.java ! test/jaxp/javax/xml/jaxp/unittest/stream/CoalesceTest/CoalesceTest.java ! test/jaxp/javax/xml/jaxp/unittest/stream/EntitiesTest/EntityTest.java ! test/jaxp/javax/xml/jaxp/unittest/stream/EventReaderDelegateTest.java ! test/jaxp/javax/xml/jaxp/unittest/stream/EventsTest/Issue41Test.java ! test/jaxp/javax/xml/jaxp/unittest/stream/EventsTest/Issue48Test.java ! test/jaxp/javax/xml/jaxp/unittest/stream/EventsTest/Issue53Test.java ! test/jaxp/javax/xml/jaxp/unittest/stream/EventsTest/Issue58Test.java ! test/jaxp/javax/xml/jaxp/unittest/stream/FactoryFindTest.java ! test/jaxp/javax/xml/jaxp/unittest/stream/IgnoreExternalDTDTest.java ! test/jaxp/javax/xml/jaxp/unittest/stream/ProcessingInstructionTest/ProcessingInstructionTest.java ! test/jaxp/javax/xml/jaxp/unittest/stream/StreamReaderDelegateTest.java ! test/jaxp/javax/xml/jaxp/unittest/stream/XMLEventLocationTest.java ! test/jaxp/javax/xml/jaxp/unittest/stream/XMLEventReaderTest/Bug6489890.java ! test/jaxp/javax/xml/jaxp/unittest/stream/XMLEventReaderTest/Bug6555001.java ! test/jaxp/javax/xml/jaxp/unittest/stream/XMLEventReaderTest/Bug6586466Test.java ! test/jaxp/javax/xml/jaxp/unittest/stream/XMLEventReaderTest/Bug6613059Test.java ! test/jaxp/javax/xml/jaxp/unittest/stream/XMLEventReaderTest/Bug6668115Test.java ! test/jaxp/javax/xml/jaxp/unittest/stream/XMLEventReaderTest/Bug6846133Test.java ! test/jaxp/javax/xml/jaxp/unittest/stream/XMLEventReaderTest/Bug8153781.java ! test/jaxp/javax/xml/jaxp/unittest/stream/XMLEventReaderTest/Issue40Test.java ! test/jaxp/javax/xml/jaxp/unittest/stream/XMLEventReaderTest/JDK8201138.java ! test/jaxp/javax/xml/jaxp/unittest/stream/XMLEventReaderTest/JDK8209615.java ! test/jaxp/javax/xml/jaxp/unittest/stream/XMLEventWriterTest/ReaderToWriterTest.java ! test/jaxp/javax/xml/jaxp/unittest/stream/XMLEventWriterTest/XMLEventWriterTest.java ! test/jaxp/javax/xml/jaxp/unittest/stream/XMLInputFactoryTest/Bug6756677Test.java ! test/jaxp/javax/xml/jaxp/unittest/stream/XMLInputFactoryTest/Bug6909759Test.java ! test/jaxp/javax/xml/jaxp/unittest/stream/XMLInputFactoryTest/IssueTracker38.java ! test/jaxp/javax/xml/jaxp/unittest/stream/XMLOutputFactoryTest/Bug6846132Test.java ! test/jaxp/javax/xml/jaxp/unittest/stream/XMLOutputFactoryTest/DuplicateNSDeclarationTest.java ! test/jaxp/javax/xml/jaxp/unittest/stream/XMLOutputFactoryTest/StreamResultTest.java ! test/jaxp/javax/xml/jaxp/unittest/stream/XMLResolverTest/XMLResolverTest.java ! test/jaxp/javax/xml/jaxp/unittest/stream/XMLStreamExceptionTest/ExceptionTest.java ! test/jaxp/javax/xml/jaxp/unittest/stream/XMLStreamFilterTest/Bug6481615.java ! test/jaxp/javax/xml/jaxp/unittest/stream/XMLStreamFilterTest/Bug6481678.java ! test/jaxp/javax/xml/jaxp/unittest/stream/XMLStreamFilterTest/HasNextTest.java ! test/jaxp/javax/xml/jaxp/unittest/stream/XMLStreamReaderTest/BOMTest.java ! test/jaxp/javax/xml/jaxp/unittest/stream/XMLStreamReaderTest/Bug6388460.java ! test/jaxp/javax/xml/jaxp/unittest/stream/XMLStreamReaderTest/Bug6472982Test.java ! test/jaxp/javax/xml/jaxp/unittest/stream/XMLStreamReaderTest/Bug6767322Test.java ! test/jaxp/javax/xml/jaxp/unittest/stream/XMLStreamReaderTest/Bug6847819Test.java ! test/jaxp/javax/xml/jaxp/unittest/stream/XMLStreamReaderTest/BugTest.java ! test/jaxp/javax/xml/jaxp/unittest/stream/XMLStreamReaderTest/DefaultAttributeTest.java ! test/jaxp/javax/xml/jaxp/unittest/stream/XMLStreamReaderTest/DoubleXmlnsTest.java ! test/jaxp/javax/xml/jaxp/unittest/stream/XMLStreamReaderTest/IsValidatingTest.java ! test/jaxp/javax/xml/jaxp/unittest/stream/XMLStreamReaderTest/Issue44Test.java ! test/jaxp/javax/xml/jaxp/unittest/stream/XMLStreamReaderTest/Issue47Test.java ! test/jaxp/javax/xml/jaxp/unittest/stream/XMLStreamReaderTest/IssueTracker24.java ! test/jaxp/javax/xml/jaxp/unittest/stream/XMLStreamReaderTest/IssueTracker35.java ! test/jaxp/javax/xml/jaxp/unittest/stream/XMLStreamReaderTest/IssueTracker70.java ! test/jaxp/javax/xml/jaxp/unittest/stream/XMLStreamReaderTest/Jsr173MR1Req5Test.java ! test/jaxp/javax/xml/jaxp/unittest/stream/XMLStreamReaderTest/Jsr173MR1Req8Test.java ! test/jaxp/javax/xml/jaxp/unittest/stream/XMLStreamReaderTest/NamespaceTest.java ! test/jaxp/javax/xml/jaxp/unittest/stream/XMLStreamReaderTest/StreamReaderTest.java ! test/jaxp/javax/xml/jaxp/unittest/stream/XMLStreamReaderTest/SupportDTDTest.java ! test/jaxp/javax/xml/jaxp/unittest/stream/XMLStreamReaderTest/VoiceXMLDTDTest.java ! test/jaxp/javax/xml/jaxp/unittest/stream/XMLStreamReaderTest/XML11Test.java ! test/jaxp/javax/xml/jaxp/unittest/stream/XMLStreamWriterTest/AttributeEscapeTest.java ! test/jaxp/javax/xml/jaxp/unittest/stream/XMLStreamWriterTest/Bug6452107.java ! test/jaxp/javax/xml/jaxp/unittest/stream/XMLStreamWriterTest/Bug6600882Test.java ! test/jaxp/javax/xml/jaxp/unittest/stream/XMLStreamWriterTest/Bug6675332Test.java ! test/jaxp/javax/xml/jaxp/unittest/stream/XMLStreamWriterTest/Bug7037352Test.java ! test/jaxp/javax/xml/jaxp/unittest/stream/XMLStreamWriterTest/DomUtilTest.java ! test/jaxp/javax/xml/jaxp/unittest/stream/XMLStreamWriterTest/EmptyElementTest.java ! test/jaxp/javax/xml/jaxp/unittest/stream/XMLStreamWriterTest/EncodingTest.java ! test/jaxp/javax/xml/jaxp/unittest/stream/XMLStreamWriterTest/NamespaceTest.java ! test/jaxp/javax/xml/jaxp/unittest/stream/XMLStreamWriterTest/NullUriDetectionTest.java ! test/jaxp/javax/xml/jaxp/unittest/stream/XMLStreamWriterTest/SqeLinuxTest.java ! test/jaxp/javax/xml/jaxp/unittest/stream/XMLStreamWriterTest/SurrogatesTest.java ! test/jaxp/javax/xml/jaxp/unittest/stream/XMLStreamWriterTest/UnprefixedNameTest.java ! test/jaxp/javax/xml/jaxp/unittest/stream/XMLStreamWriterTest/WriterTest.java ! test/jaxp/javax/xml/jaxp/unittest/stream/XMLStreamWriterTest/XMLStreamWriterTest.java ! test/jaxp/javax/xml/jaxp/unittest/transform/Bug4693341Test.java ! test/jaxp/javax/xml/jaxp/unittest/transform/Bug4892774.java ! test/jaxp/javax/xml/jaxp/unittest/transform/Bug5073477.java ! test/jaxp/javax/xml/jaxp/unittest/transform/Bug6175602.java ! test/jaxp/javax/xml/jaxp/unittest/transform/Bug6206491.java ! test/jaxp/javax/xml/jaxp/unittest/transform/Bug6216226Test.java ! test/jaxp/javax/xml/jaxp/unittest/transform/Bug6311448.java ! test/jaxp/javax/xml/jaxp/unittest/transform/Bug6384805.java ! test/jaxp/javax/xml/jaxp/unittest/transform/Bug6465722.java ! test/jaxp/javax/xml/jaxp/unittest/transform/Bug6467808.java ! test/jaxp/javax/xml/jaxp/unittest/transform/Bug6490380.java ! test/jaxp/javax/xml/jaxp/unittest/transform/Bug6490921.java ! test/jaxp/javax/xml/jaxp/unittest/transform/Bug6513892.java ! test/jaxp/javax/xml/jaxp/unittest/transform/Bug6537167.java ! test/jaxp/javax/xml/jaxp/unittest/transform/Bug6540545.java ! test/jaxp/javax/xml/jaxp/unittest/transform/Bug6551616.java ! test/jaxp/javax/xml/jaxp/unittest/transform/Bug6559595.java ! test/jaxp/javax/xml/jaxp/unittest/transform/Bug6565260.java ! test/jaxp/javax/xml/jaxp/unittest/transform/Bug6940416.java ! test/jaxp/javax/xml/jaxp/unittest/transform/BugDB12665704Test.java ! test/jaxp/javax/xml/jaxp/unittest/transform/CLITest.java ! test/jaxp/javax/xml/jaxp/unittest/transform/CR6401137Test.java ! test/jaxp/javax/xml/jaxp/unittest/transform/CR6551600Test.java ! test/jaxp/javax/xml/jaxp/unittest/transform/CR6577667Test.java ! test/jaxp/javax/xml/jaxp/unittest/transform/CR6652519Test.java ! test/jaxp/javax/xml/jaxp/unittest/transform/CR6689809Test.java ! test/jaxp/javax/xml/jaxp/unittest/transform/CR6905829Test.java ! test/jaxp/javax/xml/jaxp/unittest/transform/CR6935697Test.java ! test/jaxp/javax/xml/jaxp/unittest/transform/CR6941869Test.java ! test/jaxp/javax/xml/jaxp/unittest/transform/CR6957215Test.java ! test/jaxp/javax/xml/jaxp/unittest/transform/CR7098746Test.java ! test/jaxp/javax/xml/jaxp/unittest/transform/DOMResultTest.java ! test/jaxp/javax/xml/jaxp/unittest/transform/FactoryFindTest.java ! test/jaxp/javax/xml/jaxp/unittest/transform/Issue2204Test.java ! test/jaxp/javax/xml/jaxp/unittest/transform/Issue2290Test.java ! test/jaxp/javax/xml/jaxp/unittest/transform/NamespacePrefixTest.java ! test/jaxp/javax/xml/jaxp/unittest/transform/OpenJDK100017Test.java ! test/jaxp/javax/xml/jaxp/unittest/transform/SAX2DOMTest.java ! test/jaxp/javax/xml/jaxp/unittest/transform/SecureProcessingTest.java ! test/jaxp/javax/xml/jaxp/unittest/transform/SourceTest.java ! test/jaxp/javax/xml/jaxp/unittest/transform/StAXSourceTest.java ! test/jaxp/javax/xml/jaxp/unittest/transform/StylesheetTest.java ! test/jaxp/javax/xml/jaxp/unittest/transform/TemplatesTest.java ! test/jaxp/javax/xml/jaxp/unittest/transform/TransformerFactoryTest.java ! test/jaxp/javax/xml/jaxp/unittest/transform/TransformerTest.java ! test/jaxp/javax/xml/jaxp/unittest/transform/XSLTFunctionsTest.java ! test/jaxp/javax/xml/jaxp/unittest/transform/sax/Bug6451633.java ! test/jaxp/javax/xml/jaxp/unittest/transform/sort/SortTest.java ! test/jaxp/javax/xml/jaxp/unittest/validation/AnyElementTest.java ! test/jaxp/javax/xml/jaxp/unittest/validation/Bug4966232.java ! test/jaxp/javax/xml/jaxp/unittest/validation/Bug4966254.java ! test/jaxp/javax/xml/jaxp/unittest/validation/Bug4969042.java ! test/jaxp/javax/xml/jaxp/unittest/validation/Bug4969089.java ! test/jaxp/javax/xml/jaxp/unittest/validation/Bug4969110.java ! test/jaxp/javax/xml/jaxp/unittest/validation/Bug4969689.java ! test/jaxp/javax/xml/jaxp/unittest/validation/Bug4969692.java ! test/jaxp/javax/xml/jaxp/unittest/validation/Bug4969693.java ! test/jaxp/javax/xml/jaxp/unittest/validation/Bug4969695.java ! test/jaxp/javax/xml/jaxp/unittest/validation/Bug4969732.java ! test/jaxp/javax/xml/jaxp/unittest/validation/Bug4970380.java ! test/jaxp/javax/xml/jaxp/unittest/validation/Bug4970383.java ! test/jaxp/javax/xml/jaxp/unittest/validation/Bug4970400.java ! test/jaxp/javax/xml/jaxp/unittest/validation/Bug4970402.java ! test/jaxp/javax/xml/jaxp/unittest/validation/Bug4970951.java ! test/jaxp/javax/xml/jaxp/unittest/validation/Bug4971605.java ! test/jaxp/javax/xml/jaxp/unittest/validation/Bug4971607.java ! test/jaxp/javax/xml/jaxp/unittest/validation/Bug4972882.java ! test/jaxp/javax/xml/jaxp/unittest/validation/Bug4986844.java ! test/jaxp/javax/xml/jaxp/unittest/validation/Bug4987574.java ! test/jaxp/javax/xml/jaxp/unittest/validation/Bug4988267.java ! test/jaxp/javax/xml/jaxp/unittest/validation/Bug4988268.java ! test/jaxp/javax/xml/jaxp/unittest/validation/Bug4988387.java ! test/jaxp/javax/xml/jaxp/unittest/validation/Bug4996446.java ! test/jaxp/javax/xml/jaxp/unittest/validation/Bug4997818.java ! test/jaxp/javax/xml/jaxp/unittest/validation/Bug5011500.java ! test/jaxp/javax/xml/jaxp/unittest/validation/Bug5072946.java ! test/jaxp/javax/xml/jaxp/unittest/validation/Bug6378043.java ! test/jaxp/javax/xml/jaxp/unittest/validation/Bug6449797.java ! test/jaxp/javax/xml/jaxp/unittest/validation/Bug6457662.java ! test/jaxp/javax/xml/jaxp/unittest/validation/Bug6467424Test.java ! test/jaxp/javax/xml/jaxp/unittest/validation/Bug6483188.java ! test/jaxp/javax/xml/jaxp/unittest/validation/Bug6493687.java ! test/jaxp/javax/xml/jaxp/unittest/validation/Bug6509668.java ! test/jaxp/javax/xml/jaxp/unittest/validation/Bug6526547.java ! test/jaxp/javax/xml/jaxp/unittest/validation/Bug6531160.java ! test/jaxp/javax/xml/jaxp/unittest/validation/Bug6695843Test.java ! test/jaxp/javax/xml/jaxp/unittest/validation/Bug6773084Test.java ! test/jaxp/javax/xml/jaxp/unittest/validation/Bug6859210.java ! test/jaxp/javax/xml/jaxp/unittest/validation/Bug6925531Test.java ! test/jaxp/javax/xml/jaxp/unittest/validation/Bug6946312Test.java ! test/jaxp/javax/xml/jaxp/unittest/validation/Bug6954738_Test.java ! test/jaxp/javax/xml/jaxp/unittest/validation/CR6708840Test.java ! test/jaxp/javax/xml/jaxp/unittest/validation/CR6740048.java ! test/jaxp/javax/xml/jaxp/unittest/validation/Issue682Test.java ! test/jaxp/javax/xml/jaxp/unittest/validation/IssueTracker30.java ! test/jaxp/javax/xml/jaxp/unittest/validation/JaxpIssue43Test.java ! test/jaxp/javax/xml/jaxp/unittest/validation/JaxpIssue49.java ! test/jaxp/javax/xml/jaxp/unittest/validation/LargeMaxOccursTest.java ! test/jaxp/javax/xml/jaxp/unittest/validation/MultiOccursTest.java ! test/jaxp/javax/xml/jaxp/unittest/validation/MultiOccursUnboundedTest.java ! test/jaxp/javax/xml/jaxp/unittest/validation/OccursTest.java ! test/jaxp/javax/xml/jaxp/unittest/validation/OccursUnboundedTest.java ! test/jaxp/javax/xml/jaxp/unittest/validation/OccursWildcardTest.java ! test/jaxp/javax/xml/jaxp/unittest/validation/OccursWildcardUnbounded.java ! test/jaxp/javax/xml/jaxp/unittest/validation/ParticlesId005Test.java ! test/jaxp/javax/xml/jaxp/unittest/validation/ParticlesIg004Test.java ! test/jaxp/javax/xml/jaxp/unittest/validation/ParticlesQ013Test.java ! test/jaxp/javax/xml/jaxp/unittest/validation/TCKGroupA008Test.java ! test/jaxp/javax/xml/jaxp/unittest/validation/ValidatorTest.java ! test/jaxp/javax/xml/jaxp/unittest/validation/tck/Bug6943252Test.java ! test/jaxp/javax/xml/jaxp/unittest/validation/tck/Bug6963124Test.java ! test/jaxp/javax/xml/jaxp/unittest/validation/tck/Bug6963468Test.java ! test/jaxp/javax/xml/jaxp/unittest/validation/tck/Bug6964720Test.java ! test/jaxp/javax/xml/jaxp/unittest/validation/tck/Bug6967214Test.java ! test/jaxp/javax/xml/jaxp/unittest/validation/tck/Bug6970890Test.java ! test/jaxp/javax/xml/jaxp/unittest/validation/tck/Bug6971190Test.java ! test/jaxp/javax/xml/jaxp/unittest/validation/tck/Bug6974551Test.java ! test/jaxp/javax/xml/jaxp/unittest/validation/tck/Bug6975265Test.java ! test/jaxp/javax/xml/jaxp/unittest/validation/tck/Bug6977201Test.java ! test/jaxp/javax/xml/jaxp/unittest/validation/tck/Bug6989956Test.java ! test/jaxp/javax/xml/jaxp/unittest/validation/tck/Bug7014246Test.java ! test/jaxp/javax/xml/jaxp/unittest/validation/tck/ParticleTest.java ! test/jaxp/javax/xml/jaxp/unittest/validation/tck/RegexWord.java ! test/jaxp/javax/xml/jaxp/unittest/xpath/Bug4991857.java ! test/jaxp/javax/xml/jaxp/unittest/xpath/Bug4991939.java ! test/jaxp/javax/xml/jaxp/unittest/xpath/Bug4992788.java ! test/jaxp/javax/xml/jaxp/unittest/xpath/Bug4992793.java ! test/jaxp/javax/xml/jaxp/unittest/xpath/Bug4992805.java ! test/jaxp/javax/xml/jaxp/unittest/xpath/ClassLoaderTest.java ! test/jaxp/javax/xml/jaxp/unittest/xpath/SecureProcessingTest.java ! test/jaxp/javax/xml/jaxp/unittest/xpath/XPathAnyTypeTest.java ! test/jaxp/javax/xml/jaxp/unittest/xpath/XPathExpAnyTypeTest.java ! test/jaxp/javax/xml/jaxp/unittest/xpath/XPathTest.java ! test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java ! test/jdk/com/sun/jndi/ldap/LdapDnsProviderTest.java ! test/jdk/com/sun/management/DiagnosticCommandMBean/DcmdMBeanPermissionsTest.java ! test/jdk/java/awt/FontClass/CreateFont/BigFont.java ! test/jdk/java/awt/FontClass/CreateFont/fileaccess/TestFontFile.sh ! test/jdk/java/awt/FontClass/FontAccess.java ! test/jdk/java/awt/FontClass/FontPrivilege.java ! test/jdk/java/awt/FullScreen/SetFSWindow/FSFrame.java ! test/jdk/java/awt/Toolkit/GetImage/bug8078165.java ! test/jdk/java/awt/Toolkit/SecurityTest/SecurityTest2.java ! test/jdk/java/awt/color/LoadProfileWithSM.java ! test/jdk/java/awt/print/PrintServicesSecurityManager.java ! test/jdk/java/awt/print/PrinterJob/CheckAccess.java ! test/jdk/java/awt/print/PrinterJob/SecurityDialogTest.java ! test/jdk/java/awt/regtesthelpers/process/ProcessCommunicator.java ! test/jdk/java/awt/security/Permissions.java ! test/jdk/java/beans/Beans/Test4080522.java ! test/jdk/java/beans/EventHandler/Test6277246.java ! test/jdk/java/beans/EventHandler/Test6277266.java ! test/jdk/java/beans/Introspector/7084904/Test7084904.java ! test/jdk/java/beans/Introspector/Test4683761.java ! test/jdk/java/beans/Introspector/Test6277246.java ! test/jdk/java/beans/PropertyEditor/TestBooleanClass.java ! test/jdk/java/beans/PropertyEditor/TestBooleanType.java ! test/jdk/java/beans/PropertyEditor/TestByteClass.java ! test/jdk/java/beans/PropertyEditor/TestByteType.java ! test/jdk/java/beans/PropertyEditor/TestColorClass.java ! test/jdk/java/beans/PropertyEditor/TestDoubleClass.java ! test/jdk/java/beans/PropertyEditor/TestDoubleType.java ! test/jdk/java/beans/PropertyEditor/TestEnumClass.java ! test/jdk/java/beans/PropertyEditor/TestEnumSubclass.java ! test/jdk/java/beans/PropertyEditor/TestFloatClass.java ! test/jdk/java/beans/PropertyEditor/TestFloatType.java ! test/jdk/java/beans/PropertyEditor/TestFontClass.java ! test/jdk/java/beans/PropertyEditor/TestIntegerClass.java ! test/jdk/java/beans/PropertyEditor/TestIntegerType.java ! test/jdk/java/beans/PropertyEditor/TestLongClass.java ! test/jdk/java/beans/PropertyEditor/TestLongType.java ! test/jdk/java/beans/PropertyEditor/TestShortClass.java ! test/jdk/java/beans/PropertyEditor/TestShortType.java ! test/jdk/java/beans/PropertyEditor/TestStringClass.java ! test/jdk/java/beans/Statement/Test6224433.java ! test/jdk/java/beans/XMLDecoder/spec/TestArray.java ! test/jdk/java/beans/XMLDecoder/spec/TestBoolean.java ! test/jdk/java/beans/XMLDecoder/spec/TestByte.java ! test/jdk/java/beans/XMLDecoder/spec/TestChar.java ! test/jdk/java/beans/XMLDecoder/spec/TestClass.java ! test/jdk/java/beans/XMLDecoder/spec/TestDouble.java ! test/jdk/java/beans/XMLDecoder/spec/TestFalse.java ! test/jdk/java/beans/XMLDecoder/spec/TestField.java ! test/jdk/java/beans/XMLDecoder/spec/TestFloat.java ! test/jdk/java/beans/XMLDecoder/spec/TestInt.java ! test/jdk/java/beans/XMLDecoder/spec/TestJava.java ! test/jdk/java/beans/XMLDecoder/spec/TestLong.java ! test/jdk/java/beans/XMLDecoder/spec/TestMethod.java ! test/jdk/java/beans/XMLDecoder/spec/TestNew.java ! test/jdk/java/beans/XMLDecoder/spec/TestNull.java ! test/jdk/java/beans/XMLDecoder/spec/TestObject.java ! test/jdk/java/beans/XMLDecoder/spec/TestProperty.java ! test/jdk/java/beans/XMLDecoder/spec/TestShort.java ! test/jdk/java/beans/XMLDecoder/spec/TestString.java ! test/jdk/java/beans/XMLDecoder/spec/TestTrue.java ! test/jdk/java/beans/XMLDecoder/spec/TestVar.java ! test/jdk/java/beans/XMLEncoder/4741757/TestSecurityManager.java ! test/jdk/java/beans/XMLEncoder/6777487/TestBox.java ! test/jdk/java/beans/XMLEncoder/6777487/TestCheckedCollection.java ! test/jdk/java/beans/XMLEncoder/6777487/TestCheckedList.java ! test/jdk/java/beans/XMLEncoder/6777487/TestCheckedMap.java ! test/jdk/java/beans/XMLEncoder/6777487/TestCheckedRandomAccessList.java ! test/jdk/java/beans/XMLEncoder/6777487/TestCheckedSet.java ! test/jdk/java/beans/XMLEncoder/6777487/TestCheckedSortedMap.java ! test/jdk/java/beans/XMLEncoder/6777487/TestCheckedSortedSet.java ! test/jdk/java/beans/XMLEncoder/6777487/TestEnumMap.java ! test/jdk/java/beans/XMLEncoder/6777487/TestEnumSet.java ! test/jdk/java/beans/XMLEncoder/ReferenceToNonStaticField.java ! test/jdk/java/beans/XMLEncoder/Test4631471.java ! test/jdk/java/beans/XMLEncoder/Test4652928.java ! test/jdk/java/beans/XMLEncoder/Test4679556.java ! test/jdk/java/beans/XMLEncoder/Test4903007.java ! test/jdk/java/beans/XMLEncoder/Test4935607.java ! test/jdk/java/beans/XMLEncoder/Test4936682.java ! test/jdk/java/beans/XMLEncoder/Test4993777.java ! test/jdk/java/beans/XMLEncoder/Test4994637.java ! test/jdk/java/beans/XMLEncoder/Test5023550.java ! test/jdk/java/beans/XMLEncoder/Test5023552.java ! test/jdk/java/beans/XMLEncoder/Test5023557.java ! test/jdk/java/beans/XMLEncoder/Test5023559.java ! test/jdk/java/beans/XMLEncoder/Test6176120.java ! test/jdk/java/beans/XMLEncoder/Test6187118.java ! test/jdk/java/beans/XMLEncoder/Test6256805.java ! test/jdk/java/beans/XMLEncoder/Test6437265.java ! test/jdk/java/beans/XMLEncoder/Test6501431.java ! test/jdk/java/beans/XMLEncoder/Test6505888.java ! test/jdk/java/beans/XMLEncoder/Test6531597.java ! test/jdk/java/beans/XMLEncoder/Test6570354.java ! test/jdk/java/beans/XMLEncoder/Test6852574.java ! test/jdk/java/beans/XMLEncoder/Test6921644.java ! test/jdk/java/beans/XMLEncoder/Test6989223.java ! test/jdk/java/beans/XMLEncoder/Test7080156.java ! test/jdk/java/beans/XMLEncoder/Test7092744.java ! test/jdk/java/beans/XMLEncoder/Test7169395.java ! test/jdk/java/beans/XMLEncoder/Test8013416.java ! test/jdk/java/beans/XMLEncoder/Test8013557.java ! test/jdk/java/beans/XMLEncoder/Test8016545.java ! test/jdk/java/beans/XMLEncoder/Test8027066.java ! test/jdk/java/beans/XMLEncoder/java_awt_AWTKeyStroke.java ! test/jdk/java/beans/XMLEncoder/java_awt_BasicStroke.java ! test/jdk/java/beans/XMLEncoder/java_awt_BorderLayout.java ! test/jdk/java/beans/XMLEncoder/java_awt_CardLayout.java ! test/jdk/java/beans/XMLEncoder/java_awt_Color.java ! test/jdk/java/beans/XMLEncoder/java_awt_Component.java ! test/jdk/java/beans/XMLEncoder/java_awt_Cursor.java ! test/jdk/java/beans/XMLEncoder/java_awt_Dimension.java ! test/jdk/java/beans/XMLEncoder/java_awt_Font.java ! test/jdk/java/beans/XMLEncoder/java_awt_GradientPaint.java ! test/jdk/java/beans/XMLEncoder/java_awt_GridBagConstraints.java ! test/jdk/java/beans/XMLEncoder/java_awt_GridBagLayout.java ! test/jdk/java/beans/XMLEncoder/java_awt_Insets.java ! test/jdk/java/beans/XMLEncoder/java_awt_LinearGradientPaint.java ! test/jdk/java/beans/XMLEncoder/java_awt_MenuShortcut.java ! test/jdk/java/beans/XMLEncoder/java_awt_Point.java ! test/jdk/java/beans/XMLEncoder/java_awt_RadialGradientPaint.java ! test/jdk/java/beans/XMLEncoder/java_awt_Rectangle.java ! test/jdk/java/beans/XMLEncoder/java_awt_ScrollPane.java ! test/jdk/java/beans/XMLEncoder/java_awt_geom_AffineTransform.java ! test/jdk/java/beans/XMLEncoder/java_beans_EventHandler.java ! test/jdk/java/beans/XMLEncoder/java_beans_Expression.java ! test/jdk/java/beans/XMLEncoder/java_beans_Statement.java ! test/jdk/java/beans/XMLEncoder/java_lang_Character.java ! test/jdk/java/beans/XMLEncoder/java_lang_Class.java ! test/jdk/java/beans/XMLEncoder/java_lang_Enum.java ! test/jdk/java/beans/XMLEncoder/java_lang_String.java ! test/jdk/java/beans/XMLEncoder/java_lang_reflect_Field.java ! test/jdk/java/beans/XMLEncoder/java_lang_reflect_Method.java ! test/jdk/java/beans/XMLEncoder/java_net_URI.java ! test/jdk/java/beans/XMLEncoder/java_sql_Date.java ! test/jdk/java/beans/XMLEncoder/java_sql_Time.java ! test/jdk/java/beans/XMLEncoder/java_sql_Timestamp.java ! test/jdk/java/beans/XMLEncoder/java_util_ArrayList.java ! test/jdk/java/beans/XMLEncoder/java_util_Collections_EmptyList.java ! test/jdk/java/beans/XMLEncoder/java_util_Collections_EmptyMap.java ! test/jdk/java/beans/XMLEncoder/java_util_Collections_EmptySet.java ! test/jdk/java/beans/XMLEncoder/java_util_Collections_SingletonList.java ! test/jdk/java/beans/XMLEncoder/java_util_Collections_SingletonMap.java ! test/jdk/java/beans/XMLEncoder/java_util_Collections_SingletonSet.java ! test/jdk/java/beans/XMLEncoder/java_util_Collections_SynchronizedCollection.java ! test/jdk/java/beans/XMLEncoder/java_util_Collections_SynchronizedList.java ! test/jdk/java/beans/XMLEncoder/java_util_Collections_SynchronizedMap.java ! test/jdk/java/beans/XMLEncoder/java_util_Collections_SynchronizedRandomAccessList.java ! test/jdk/java/beans/XMLEncoder/java_util_Collections_SynchronizedSet.java ! test/jdk/java/beans/XMLEncoder/java_util_Collections_SynchronizedSortedMap.java ! test/jdk/java/beans/XMLEncoder/java_util_Collections_SynchronizedSortedSet.java ! test/jdk/java/beans/XMLEncoder/java_util_Collections_UnmodifiableCollection.java ! test/jdk/java/beans/XMLEncoder/java_util_Collections_UnmodifiableList.java ! test/jdk/java/beans/XMLEncoder/java_util_Collections_UnmodifiableMap.java ! test/jdk/java/beans/XMLEncoder/java_util_Collections_UnmodifiableRandomAccessList.java ! test/jdk/java/beans/XMLEncoder/java_util_Collections_UnmodifiableSet.java ! test/jdk/java/beans/XMLEncoder/java_util_Collections_UnmodifiableSortedMap.java ! test/jdk/java/beans/XMLEncoder/java_util_Collections_UnmodifiableSortedSet.java ! test/jdk/java/beans/XMLEncoder/java_util_Date.java ! test/jdk/java/beans/XMLEncoder/java_util_HashMap.java ! test/jdk/java/beans/XMLEncoder/javax_swing_Box.java ! test/jdk/java/beans/XMLEncoder/javax_swing_BoxLayout.java ! test/jdk/java/beans/XMLEncoder/javax_swing_Box_Filler.java ! test/jdk/java/beans/XMLEncoder/javax_swing_DefaultCellEditor.java ! test/jdk/java/beans/XMLEncoder/javax_swing_JButton.java ! test/jdk/java/beans/XMLEncoder/javax_swing_JComponent.java ! test/jdk/java/beans/XMLEncoder/javax_swing_JLayeredPane.java ! test/jdk/java/beans/XMLEncoder/javax_swing_JSplitPane.java ! test/jdk/java/beans/XMLEncoder/javax_swing_JTree.java ! test/jdk/java/beans/XMLEncoder/javax_swing_KeyStroke.java ! test/jdk/java/beans/XMLEncoder/javax_swing_OverlayLayout.java ! test/jdk/java/beans/XMLEncoder/javax_swing_border_BevelBorder.java ! test/jdk/java/beans/XMLEncoder/javax_swing_border_CompoundBorder.java ! test/jdk/java/beans/XMLEncoder/javax_swing_border_EmptyBorder.java ! test/jdk/java/beans/XMLEncoder/javax_swing_border_EtchedBorder.java ! test/jdk/java/beans/XMLEncoder/javax_swing_border_LineBorder.java ! test/jdk/java/beans/XMLEncoder/javax_swing_border_MatteBorder.java ! test/jdk/java/beans/XMLEncoder/javax_swing_border_SoftBevelBorder.java ! test/jdk/java/beans/XMLEncoder/javax_swing_border_StrokeBorder.java ! test/jdk/java/beans/XMLEncoder/javax_swing_border_TitledBorder.java ! test/jdk/java/beans/XMLEncoder/javax_swing_plaf_BorderUIResource_BevelBorderUIResource.java ! test/jdk/java/beans/XMLEncoder/javax_swing_plaf_BorderUIResource_CompoundBorderUIResource.java ! test/jdk/java/beans/XMLEncoder/javax_swing_plaf_BorderUIResource_EmptyBorderUIResource.java ! test/jdk/java/beans/XMLEncoder/javax_swing_plaf_BorderUIResource_EtchedBorderUIResource.java ! test/jdk/java/beans/XMLEncoder/javax_swing_plaf_BorderUIResource_LineBorderUIResource.java ! test/jdk/java/beans/XMLEncoder/javax_swing_plaf_BorderUIResource_MatteBorderUIResource.java ! test/jdk/java/beans/XMLEncoder/javax_swing_plaf_BorderUIResource_TitledBorderUIResource.java ! test/jdk/java/beans/XMLEncoder/javax_swing_plaf_ColorUIResource.java ! test/jdk/java/beans/XMLEncoder/javax_swing_plaf_FontUIResource.java ! test/jdk/java/beans/XMLEncoder/javax_swing_tree_DefaultTreeModel.java ! test/jdk/java/beans/XMLEncoder/javax_swing_tree_TreePath.java ! test/jdk/java/beans/XMLEncoder/sun_swing_PrintColorUIResource.java ! test/jdk/java/io/File/CheckPermission.java ! test/jdk/java/io/File/GetXSpace.java ! test/jdk/java/io/Serializable/auditStreamSubclass/AuditStreamSubclass.java ! test/jdk/java/lang/Class/forName/modules/TestDriver.java ! test/jdk/java/lang/Class/getDeclaredField/ClassDeclaredFieldsTest.java ! test/jdk/java/lang/Class/getDeclaredField/FieldSetAccessibleTest.java ! test/jdk/java/lang/Class/getEnclosingConstructor/EnclosingConstructorWithSecurityManager.java ! test/jdk/java/lang/Class/getEnclosingMethod/EnclosingMethodWithSecurityManager.java ! test/jdk/java/lang/Class/getResource/ResourcesTest.java ! test/jdk/java/lang/ClassLoader/UninitializedParent.java ! test/jdk/java/lang/ClassLoader/getResource/modules/ResourcesTest.java ! test/jdk/java/lang/ModuleTests/WithSecurityManager.java ! test/jdk/java/lang/ProcessBuilder/Basic.java ! test/jdk/java/lang/ProcessBuilder/SecurityManagerClinit.java ! test/jdk/java/lang/ProcessHandle/PermissionTest.java ! test/jdk/java/lang/RuntimeTests/exec/ExecCommand.java ! test/jdk/java/lang/SecurityManager/CheckPackageMatching.java ! test/jdk/java/lang/SecurityManager/CheckSecurityProvider.java ! test/jdk/java/lang/StackWalker/CallerSensitiveMethod/Main.java ! test/jdk/java/lang/StackWalker/GetCallerClassTest.java ! test/jdk/java/lang/String/concat/WithSecurityManager.java ! test/jdk/java/lang/System/Logger/custom/CustomLoggerTest.java ! test/jdk/java/lang/System/Logger/default/DefaultLoggerTest.java ! test/jdk/java/lang/System/LoggerFinder/BaseLoggerFinderTest/BaseLoggerFinderTest.java ! test/jdk/java/lang/System/LoggerFinder/DefaultLoggerFinderTest/DefaultLoggerFinderTest.java ! test/jdk/java/lang/System/LoggerFinder/internal/BaseDefaultLoggerFinderTest/BaseDefaultLoggerFinderTest.java ! test/jdk/java/lang/System/LoggerFinder/internal/BaseLoggerBridgeTest/BaseLoggerBridgeTest.java ! test/jdk/java/lang/System/LoggerFinder/internal/BasePlatformLoggerTest/BasePlatformLoggerTest.java ! test/jdk/java/lang/System/LoggerFinder/internal/BootstrapLogger/BootstrapLoggerTest.java ! test/jdk/java/lang/System/LoggerFinder/internal/LoggerBridgeTest/LoggerBridgeTest.java ! test/jdk/java/lang/System/LoggerFinder/internal/LoggerFinderLoaderTest/LoggerFinderLoaderTest.java ! test/jdk/java/lang/System/LoggerFinder/internal/PlatformLoggerBridgeTest/PlatformLoggerBridgeTest.java ! test/jdk/java/lang/System/LoggerFinder/jdk/DefaultLoggerBridgeTest/DefaultLoggerBridgeTest.java ! test/jdk/java/lang/System/LoggerFinder/jdk/DefaultPlatformLoggerTest/DefaultPlatformLoggerTest.java ! test/jdk/java/lang/annotation/ParameterAnnotations.java ! test/jdk/java/lang/annotation/repeatingAnnotations/CustomRepeatingWithSecurityManager.java ! test/jdk/java/lang/annotation/repeatingAnnotations/RepeatingWithSecurityManager.java ! test/jdk/java/lang/invoke/InvokeDynamicPrintArgs.java ! test/jdk/java/lang/invoke/MethodHandleConstants.java ! test/jdk/java/lang/invoke/MethodTypeSecurityManager.java ! test/jdk/java/lang/invoke/TestPrivateMember.java ! test/jdk/java/lang/invoke/lambda/LambdaAccessControlDoPrivilegedTest.java ! test/jdk/java/lang/invoke/lambda/LambdaAccessControlTest.java ! test/jdk/java/lang/invoke/lambda/LogGeneratedClassesTest.java ! test/jdk/java/lang/module/ModuleFinderWithSecurityManager.java ! test/jdk/java/lang/reflect/Nestmates/TestSecurityManagerChecks.java ! test/jdk/java/lang/reflect/Proxy/nonPublicProxy/NonPublicProxyClass.java ! test/jdk/java/lang/reflect/Proxy/nonPublicProxy/SimpleProxy.java ! test/jdk/java/lang/reflect/sealed_classes/TestSecurityManagerChecks.java ! test/jdk/java/net/Authenticator/GetAuthenticatorTest.java ! test/jdk/java/net/DatagramSocket/ConnectPortZero.java ! test/jdk/java/net/DatagramSocket/SendPortZero.java ! test/jdk/java/net/InetAddress/GetLocalHostWithSM.java ! test/jdk/java/net/MulticastSocket/SendPortZero.java ! test/jdk/java/net/NetworkInterface/Equals.java ! test/jdk/java/net/ServerSocket/TestLocalAddress.java ! test/jdk/java/net/Socket/UdpSocket.java ! test/jdk/java/net/SocketPermission/SocketPermissionTest.java ! test/jdk/java/net/URL/OpenConnection.java ! test/jdk/java/net/URL/TestIPv6Addresses.java ! test/jdk/java/net/URLPermission/OpenURL.java ! test/jdk/java/net/URLPermission/URLTest.java ! test/jdk/java/net/URLPermission/nstest/LookupTest.java ! test/jdk/java/nio/channels/AsynchronousChannelGroup/AsExecutor.java ! test/jdk/java/nio/channels/AsynchronousServerSocketChannel/WithSecurityManager.java ! test/jdk/java/nio/channels/DatagramChannel/ConnectPortZero.java ! test/jdk/java/nio/channels/DatagramChannel/SendPortZero.java ! test/jdk/java/nio/channels/FileChannel/MapWithSecurityManager.java ! test/jdk/java/nio/channels/FileChannel/Size.java ! test/jdk/java/nio/channels/SocketChannel/OpenLeak.java ! test/jdk/java/nio/channels/unixdomain/Security.java ! test/jdk/java/nio/file/Files/CheckPermissions.java ! test/jdk/java/nio/file/Files/walkFileTree/WalkWithSecurity.java ! test/jdk/java/nio/file/WatchService/WithSecurityManager.java ! test/jdk/java/rmi/RMISecurityManager/checkPackageAccess/CheckPackageAccess.java ! test/jdk/java/rmi/activation/ActivationGroup/downloadActivationGroup/DownloadActivationGroup.java ! test/jdk/java/rmi/registry/classPathCodebase/ClassPathCodebase.java ! test/jdk/java/rmi/registry/readTest/CodebaseTest.java ! test/jdk/java/rmi/reliability/benchmark/bench/rmi/Main.java ! test/jdk/java/rmi/server/RMIClassLoader/delegateBeforePermissionCheck/DelegateBeforePermissionCheck.java ! test/jdk/java/rmi/server/RMISocketFactory/useSocketFactory/activatable/UseCustomSocketFactory.java ! test/jdk/java/rmi/server/RMISocketFactory/useSocketFactory/registry/UseCustomSocketFactory.java ! test/jdk/java/rmi/server/RMISocketFactory/useSocketFactory/unicast/UseCustomSocketFactory.java ! test/jdk/java/rmi/server/Unreferenced/unreferencedContext/UnreferencedContext.java ! test/jdk/java/rmi/testlibrary/RMID.java ! test/jdk/java/rmi/testlibrary/TestParams.java ! test/jdk/java/security/BasicPermission/NullOrEmptyName.java ! test/jdk/java/security/Policy/PolicyProvider/UseSystemClassLoader.java ! test/jdk/java/security/ProtectionDomain/AllPerm.java ! test/jdk/java/security/SecureClassLoader/DefineClass.java = test/jdk/java/sql/permissionTests/DriverManagerPermissionsTests.java ! test/jdk/java/util/Properties/LoadAndStoreXML.java ! test/jdk/java/util/ResourceBundle/Bug6359330.java ! test/jdk/java/util/ResourceBundle/modules/security/TestPermission.java ! test/jdk/java/util/ServiceLoader/security/SecurityTest.java ! test/jdk/java/util/TimeZone/Bug6912560.java ! test/jdk/java/util/TimeZone/SetDefaultSecurityTest.java ! test/jdk/java/util/concurrent/Executors/PrivilegedCallables.java ! test/jdk/java/util/concurrent/ThreadPoolExecutor/ConfigChanges.java ! test/jdk/java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java ! test/jdk/java/util/concurrent/atomic/AtomicUpdaters.java ! test/jdk/java/util/concurrent/tck/JSR166TestCase.java ! test/jdk/java/util/logging/AnonymousLogger/TestAnonymousLogger.java ! test/jdk/java/util/logging/FileHandlerLongLimit.java ! test/jdk/java/util/logging/FileHandlerPath.java ! test/jdk/java/util/logging/FileHandlerPatternExceptions.java ! test/jdk/java/util/logging/HandlersConfigTest.java ! test/jdk/java/util/logging/LogManager/Configuration/ParentLoggerWithHandlerGC.java ! test/jdk/java/util/logging/LogManager/Configuration/TestConfigurationLock.java ! test/jdk/java/util/logging/LogManager/Configuration/updateConfiguration/HandlersOnComplexResetUpdate.java ! test/jdk/java/util/logging/LogManager/Configuration/updateConfiguration/HandlersOnComplexUpdate.java ! test/jdk/java/util/logging/LogManager/Configuration/updateConfiguration/SimpleUpdateConfigWithInputStreamTest.java ! test/jdk/java/util/logging/LogManager/Configuration/updateConfiguration/SimpleUpdateConfigurationTest.java ! test/jdk/java/util/logging/LogManager/Configuration/updateConfiguration/UpdateConfigurationTest.java ! test/jdk/java/util/logging/LogManager/RootLogger/setLevel/TestRootLoggerLevel.java ! test/jdk/java/util/logging/Logger/getLogger/TestLogger.java ! test/jdk/java/util/logging/Logger/setResourceBundle/TestSetResourceBundle.java ! test/jdk/java/util/logging/RootLogger/RootLevelInConfigFile.java ! test/jdk/java/util/logging/SystemLoggerConfigTest.java ! test/jdk/java/util/logging/TestAppletLoggerContext.java ! test/jdk/java/util/logging/TestConfigurationListeners.java ! test/jdk/java/util/logging/TestGetLoggerNPE.java ! test/jdk/java/util/logging/TestLogConfigurationDeadLock.java ! test/jdk/java/util/logging/TestLogConfigurationDeadLockWithConf.java ! test/jdk/java/util/logging/TestLoggerBundleSync.java ! test/jdk/java/util/logging/TestLoggingWithMainAppContext.java ! test/jdk/java/util/logging/TestMainAppContext.java ! test/jdk/java/util/spi/ResourceBundleControlProvider/UserDefaultControlTest.java ! test/jdk/java/util/spi/ToolProviderTest.java ! test/jdk/javax/imageio/CachePremissionsTest/CachePermissionsTest.java ! test/jdk/javax/management/Introspector/AnnotationSecurityTest.java ! test/jdk/javax/management/remote/mandatory/loading/RMIDownloadTest.java ! test/jdk/javax/management/remote/mandatory/notif/NoPermToRemoveTest.java ! test/jdk/javax/management/remote/mandatory/notif/NotificationEmissionTest.java ! test/jdk/javax/management/remote/mandatory/subjectDelegation/SubjectDelegation2Test.java ! test/jdk/javax/management/remote/mandatory/subjectDelegation/SubjectDelegation3Test.java = test/jdk/javax/sql/permissionTests/SyncFactoryPermissionsTests.java ! test/jdk/javax/swing/JComboBox/8080972/TestBasicComboBoxEditor.java ! test/jdk/javax/swing/JEditorPane/5076514/bug5076514.java ! test/jdk/javax/swing/JEditorPane/8080972/TestJEditor.java ! test/jdk/javax/swing/JFileChooser/6484091/bug6484091.java ! test/jdk/javax/swing/JFileChooser/6570445/bug6570445.java ! test/jdk/javax/swing/JFormattedTextField/8080972/TestDefaultFormatter.java ! test/jdk/javax/swing/JOptionPane/8081019/bug8081019.java ! test/jdk/javax/swing/JPopupMenu/6675802/bug6675802.java ! test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java ! test/jdk/javax/swing/JPopupMenu/6694823/bug6694823.java ! test/jdk/javax/swing/JTable/8080972/TestJTableCellEditor.java ! test/jdk/javax/swing/UIDefaults/6622002/bug6622002.java ! test/jdk/javax/swing/UIDefaults/6795356/TableTest.java ! test/jdk/javax/swing/UIDefaults/8080972/TestProxyLazyValue.java ! test/jdk/javax/swing/dnd/8080972/TestTransferHandler.java ! test/jdk/javax/swing/plaf/nimbus/8080972/TestAbstractRegionPainter.java ! test/jdk/javax/swing/plaf/synth/Test8043627.java ! test/jdk/javax/swing/text/View/8080972/TestObjectView.java ! test/jdk/javax/xml/crypto/dsig/SecurityManager/XMLDSigWithSecMgr.java ! test/jdk/javax/xml/jaxp/transform/8004476/XPathExFuncTest.java ! test/jdk/javax/xml/jaxp/transform/8004476/XSLTExFuncTest.java ! test/jdk/jdk/internal/jrtfs/WithSecurityManager.java ! test/jdk/sun/management/PlatformMBeanProviderConstructorCheck.java ! test/jdk/sun/net/www/protocol/jrt/WithSecurityManager.java ! test/jdk/sun/nio/cs/TestSJIS0213_SM.java ! test/jdk/sun/nio/cs/TestStringCoding.java ! test/jdk/sun/nio/cs/TestStringCodingUTF8.java ! test/jdk/sun/rmi/runtime/Log/checkLogging/CheckLogging.java ! test/jdk/sun/rmi/transport/tcp/disableMultiplexing/DisableMultiplexing.java ! test/jdk/sun/security/krb5/auto/AcceptPermissions.java ! test/jdk/sun/security/krb5/auto/HttpNegotiateServer.java ! test/jdk/sun/security/krb5/auto/KeyPermissions.java ! test/jdk/sun/security/pkcs11/Cipher/ReinitCipher.java ! test/jdk/sun/security/pkcs11/Cipher/TestPKCS5PaddingError.java ! test/jdk/sun/security/pkcs11/Cipher/TestRSACipher.java ! test/jdk/sun/security/pkcs11/Cipher/TestRSACipherWrap.java ! test/jdk/sun/security/pkcs11/Cipher/TestRawRSACipher.java ! test/jdk/sun/security/pkcs11/Cipher/TestSymmCiphers.java ! test/jdk/sun/security/pkcs11/Cipher/TestSymmCiphersNoPad.java ! test/jdk/sun/security/pkcs11/KeyAgreement/IllegalPackageAccess.java ! test/jdk/sun/security/pkcs11/KeyAgreement/SupportedDHKeys.java ! test/jdk/sun/security/pkcs11/KeyAgreement/TestDH.java ! test/jdk/sun/security/pkcs11/KeyAgreement/TestInterop.java ! test/jdk/sun/security/pkcs11/KeyAgreement/TestShort.java ! test/jdk/sun/security/pkcs11/KeyAgreement/UnsupportedDHKeys.java ! test/jdk/sun/security/pkcs11/KeyGenerator/DESParity.java ! test/jdk/sun/security/pkcs11/KeyGenerator/HmacDefKeySizeTest.java ! test/jdk/sun/security/pkcs11/KeyGenerator/TestKeyGenerator.java ! test/jdk/sun/security/pkcs11/KeyPairGenerator/TestDH2048.java ! test/jdk/sun/security/pkcs11/Mac/MacKAT.java ! test/jdk/sun/security/pkcs11/Mac/MacSameTest.java ! test/jdk/sun/security/pkcs11/Mac/ReinitMac.java ! test/jdk/sun/security/pkcs11/MessageDigest/DigestKAT.java ! test/jdk/sun/security/pkcs11/MessageDigest/ReinitDigest.java ! test/jdk/sun/security/pkcs11/MessageDigest/TestCloning.java ! test/jdk/sun/security/pkcs11/Provider/Login.sh ! test/jdk/sun/security/pkcs11/Secmod/AddPrivateKey.java ! test/jdk/sun/security/pkcs11/Secmod/AddTrustedCert.java ! test/jdk/sun/security/pkcs11/Secmod/Crypto.java ! test/jdk/sun/security/pkcs11/Secmod/GetPrivateKey.java ! test/jdk/sun/security/pkcs11/Secmod/JksSetPrivateKey.java ! test/jdk/sun/security/pkcs11/Secmod/LoadKeystore.java ! test/jdk/sun/security/pkcs11/Secmod/TrustAnchors.java ! test/jdk/sun/security/pkcs11/SecureRandom/Basic.java ! test/jdk/sun/security/pkcs11/Signature/ByteBuffers.java ! test/jdk/sun/security/pkcs11/Signature/TestDSA.java ! test/jdk/sun/security/pkcs11/Signature/TestDSAKeyLength.java ! test/jdk/sun/security/pkcs11/Signature/TestRSAKeyLength.java ! test/jdk/sun/security/pkcs11/ec/ReadCertificates.java ! test/jdk/sun/security/pkcs11/ec/ReadPKCS12.java ! test/jdk/sun/security/pkcs11/ec/TestCurves.java ! test/jdk/sun/security/pkcs11/ec/TestECDH.java ! test/jdk/sun/security/pkcs11/ec/TestECDH2.java ! test/jdk/sun/security/pkcs11/ec/TestECDSA.java ! test/jdk/sun/security/pkcs11/ec/TestECDSA2.java ! test/jdk/sun/security/pkcs11/ec/TestECGenSpec.java ! test/jdk/sun/security/pkcs11/ec/TestKeyFactory.java ! test/jdk/sun/security/pkcs11/rsa/KeyWrap.java ! test/jdk/sun/security/pkcs11/rsa/TestCACerts.java ! test/jdk/sun/security/pkcs11/rsa/TestKeyFactory.java ! test/jdk/sun/security/pkcs11/rsa/TestKeyPairGenerator.java ! test/jdk/sun/security/pkcs11/rsa/TestP11KeyFactoryGetRSAKeySpec.java ! test/jdk/sun/security/pkcs11/rsa/TestSignatures.java ! test/jdk/sun/security/pkcs11/tls/TestKeyMaterial.java ! test/jdk/sun/security/pkcs11/tls/TestLeadingZeroesP11.java ! test/jdk/sun/security/pkcs11/tls/TestMasterSecret.java ! test/jdk/sun/security/pkcs11/tls/TestPRF.java ! test/jdk/sun/security/pkcs11/tls/TestPremaster.java ! test/jdk/sun/security/provider/PolicyFile/BadPolicyFile.java ! test/jdk/sun/tools/jstatd/JstatdTest.java ! test/jdk/sun/util/locale/provider/Bug8152817.java ! test/jdk/tools/jlink/SecurityTest.java ! test/langtools/ProblemList.txt ! test/langtools/tools/doclint/tool/RunTest.java ! test/langtools/tools/javac/api/ToolProvider/ToolProviderTest.java ! test/langtools/tools/javac/processing/6348193/T6348193.java Changeset: bb085f68 Author: Mark Sheppard Date: 2021-05-24 17:59:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bb085f684d1154ffd6b2169259c67cfb19958380 8265362: java/net/Socket/UdpSocket.java fails with "java.net.BindException: Address already in use" (macos-aarch64) Reviewed-by: dfuchs, alanb ! test/jdk/ProblemList.txt ! test/jdk/java/net/Socket/UdpSocket.java Changeset: a5467ae7 Author: Andy Herrick Date: 2021-05-24 19:28:50 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a5467ae7bb5780f34728ad073c5c4158894c7c4b 8267423: Fix copyrights in jpackage tests Reviewed-by: kcr, asemenyuk ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JPackageCommand.java ! test/jdk/tools/jpackage/junit/jdk/jpackage/internal/AppImageFileTest.java ! test/jdk/tools/jpackage/junit/jdk/jpackage/internal/ApplicationLayoutTest.java ! test/jdk/tools/jpackage/junit/jdk/jpackage/internal/OverridableResourceTest.java ! test/jdk/tools/jpackage/junit/jdk/jpackage/internal/PathGroupTest.java ! test/jdk/tools/jpackage/junit/jdk/jpackage/internal/ToolValidatorTest.java ! test/jdk/tools/jpackage/junit/junit.java ! test/jdk/tools/jpackage/junit/run_junit.sh ! test/jdk/tools/jpackage/run_tests.sh ! test/jdk/tools/jpackage/test_jpackage.sh Changeset: 209769b5 Author: Ioi Lam Date: 2021-05-24 21:52:13 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/209769b5ad462ce3dd47f18d93e12147730f8123 8267347: CDS record_linking_constraint asserts with unregistered class Reviewed-by: minqi, ccheung ! src/hotspot/share/classfile/systemDictionaryShared.cpp ! test/hotspot/jtreg/runtime/cds/appcds/loaderConstraints/DynamicLoaderConstraintsTest.java ! test/hotspot/jtreg/runtime/cds/appcds/loaderConstraints/LoaderConstraintsApp.java ! test/hotspot/jtreg/runtime/cds/appcds/loaderConstraints/LoaderConstraintsTest.java + test/hotspot/jtreg/runtime/cds/appcds/test-classes/CustomAppLoader.java Changeset: ebc9357d Author: Ian Graves Date: 2021-05-24 21:57:30 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ebc9357d58957702abbd003d21082badc630876d 8267329: Modernize Javadoc code to use instanceof with pattern matching Reviewed-by: prappo, jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/api/JavadocTool.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Contents.java ! 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/SourceToHTMLConverter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SystemPropertiesWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TagletWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/ContentBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlTree.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/CommentUtils.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/MemberSummaryBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/TagletManager.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/TagletWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/ThrowsTaglet.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/DocPath.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Extern.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/ElementsTable.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/JavadocTool.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/Messager.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/Start.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/ToolEnvironment.java Changeset: f6909596 Author: Kim Barrett Date: 2021-05-24 22:43:42 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f6909596cae7c47514c10b614cc006169bcee04b 8267446: Taskqueue code fails with assert(bottom_relaxed() == age_top_relaxed()) failed: not empty Reviewed-by: stefank, pliden ! src/hotspot/share/gc/shared/taskTerminator.cpp ! src/hotspot/share/gc/shared/taskqueue.hpp Changeset: c519ba2e Author: Claes Redestad Date: 2021-05-24 23:02:40 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c519ba2e437a05ac83e53b358b6a02b2f6e20563 8267614: Outline VarHandleGuards exact behavior checks Reviewed-by: psandoz, mchung ! src/java.base/share/classes/java/lang/invoke/VarHandle.java ! src/java.base/share/classes/java/lang/invoke/VarHandleGuards.java ! src/java.base/share/classes/java/lang/invoke/VarHandles.java Changeset: de27da7d Author: Calvin Cheung Date: 2021-05-25 00:42:21 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/de27da7dedb217481b5e1582c38313232828a18c 8267431: Rename InstanceKlass::has_old_class_version to can_be_verified_at_dumptime Reviewed-by: iklam ! src/hotspot/share/cds/metaspaceShared.cpp ! src/hotspot/share/classfile/systemDictionaryShared.cpp ! src/hotspot/share/interpreter/rewriter.cpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/instanceKlass.hpp ! src/hotspot/share/oops/klassVtable.cpp Changeset: 461a3fee Author: Calvin Cheung Date: 2021-05-25 00:48:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/461a3feebedccbf83bf3871d65ed7f2d1ad79307 8261478: InstanceKlass::set_classpath_index does not match comments Reviewed-by: minqi ! src/hotspot/share/oops/instanceKlass.cpp Changeset: b4d4884c Author: Jonathan Gibbons Date: 2021-05-25 01:33:13 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b4d4884c03b03d3073ef137a899f3612993f5e65 8267126: javadoc should show "line and caret" for diagnostics. Reviewed-by: prappo ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/WorkArounds.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/TagletManager.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/ElementsTable.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/Messager.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/Start.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/ToolEnvironment.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/resources/javadoc.properties ! test/langtools/jdk/javadoc/doclet/testCharsetDocencodingOptions/TestCharsetDocencodingOptions.java + test/langtools/jdk/javadoc/doclet/testDiagsLineCaret/MyTaglet.java + test/langtools/jdk/javadoc/doclet/testDiagsLineCaret/TestDiagsLineCaret.java ! test/langtools/jdk/javadoc/doclet/testDocFiles/TestDocFiles.java ! test/langtools/jdk/javadoc/doclet/testJavaFX/TestJavaFX.java ! test/langtools/jdk/javadoc/doclet/testLinkOption/TestRedirectLinks.java ! test/langtools/jdk/javadoc/doclet/testMissingComment/TestMissingComment.java ! test/langtools/jdk/javadoc/doclet/testNewLanguageFeatures/TestNewLanguageFeatures.java ! test/langtools/jdk/javadoc/doclet/testNoFrames/TestNoFrames.java ! test/langtools/jdk/javadoc/doclet/testOptions/TestOptions.java ! test/langtools/jdk/javadoc/doclet/testReturnTag/TestReturnTag.java ! test/langtools/jdk/javadoc/doclet/testSearch/TestSearch.java ! test/langtools/jdk/javadoc/doclet/testTagInheritence/TestTagInheritence.java ! test/langtools/jdk/javadoc/doclet/testTagMisuse/TestTagMisuse.java ! test/langtools/jdk/javadoc/doclet/testValueTag/TestValueTag.java ! test/langtools/jdk/javadoc/doclet/testWarnBadParamNames/TestWarnBadParamNames.java ! test/langtools/jdk/javadoc/tool/6958836/Test.java ! test/langtools/jdk/javadoc/tool/6964914/TestStdDoclet.java ! test/langtools/jdk/javadoc/tool/8224613/OptionProcessingFailureTest.java ! test/langtools/jdk/javadoc/tool/BadOptionsTest.java ! test/langtools/jdk/javadoc/tool/CheckResourceKeys.java ! test/langtools/jdk/javadoc/tool/MaxWarns.java ! test/langtools/jdk/javadoc/tool/api/basic/GetTask_DiagListenerTest.java ! test/langtools/jdk/javadoc/tool/doclint/DocLintTest.java ! test/langtools/jdk/javadoc/tool/exceptionHandling/TestExceptionHandling.java ! test/langtools/jdk/javadoc/tool/modules/Modules.java ! test/langtools/jdk/javadoc/tool/modules/PackageOptions.java ! test/langtools/jdk/javadoc/tool/removeOldDoclet/RemoveOldDoclet.java ! test/langtools/jdk/javadoc/tool/testWErrorOption/TestWErrorOption.java Changeset: 123cdd1f Author: Dong Bo Committer: Fei Yang Date: 2021-05-25 02:17:19 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/123cdd1fbd4fa02177c06afb67a09aee21d0a482 8264973: AArch64: Optimize vector max/min/add reduction of two integers with NEON pairwise instructions Reviewed-by: njian, aph ! src/hotspot/cpu/aarch64/aarch64_neon.ad ! src/hotspot/cpu/aarch64/aarch64_neon_ad.m4 ! src/hotspot/cpu/aarch64/assembler_aarch64.hpp ! test/hotspot/gtest/aarch64/aarch64-asmtest.py ! test/hotspot/gtest/aarch64/asmtest.out.h Changeset: 2e8812df Author: Denghui Dong Committer: Vladimir Kozlov Date: 2021-05-25 04:11:12 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2e8812df142430d1a6b0a4df0259d2656a1548c9 8265129: Add intrinsic support for JVM.getClassId Reviewed-by: kvn, mgronlun ! src/hotspot/share/c1/c1_Compiler.cpp ! src/hotspot/share/c1/c1_LIRGenerator.cpp ! src/hotspot/share/jfr/jfr.cpp ! src/hotspot/share/jfr/jfr.hpp ! src/hotspot/share/jfr/jni/jfrJniMethodRegistration.cpp ! src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdEpoch.hpp ! src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdLoadBarrier.hpp ! src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdLoadBarrier.inline.hpp ! src/hotspot/share/jfr/utilities/jfrSignal.hpp ! src/hotspot/share/opto/escape.cpp ! src/hotspot/share/opto/idealKit.cpp ! src/hotspot/share/opto/idealKit.hpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/opto/runtime.cpp ! src/hotspot/share/opto/runtime.hpp ! src/hotspot/share/runtime/sharedRuntime.cpp ! src/jdk.jfr/share/classes/jdk/jfr/internal/EventWriter.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/JVM.java ! test/jdk/jdk/jfr/jvm/TestClearStaleConstants.java ! test/jdk/jdk/jfr/jvm/TestJFRIntrinsic.java Changeset: 31d0f0d8 Author: Adam Sotona Date: 2021-05-25 04:52:42 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/31d0f0d895ef4039d2e96a8fb6e990e93eed4d41 8248843: java in source-file mode suggests javac-only options Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/Main.java Changeset: d86f9164 Author: Alexander Zuev Date: 2021-05-25 06:46:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d86f91642d7dcf829b8093ebed336d4386bff67a 8267066: New NSAccessibility peers should return they roles and subroles directly Reviewed-by: pbansal ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ButtonAccessibility.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ButtonAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CheckboxAccessibility.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CheckboxAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CommonComponentAccessibility.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CommonComponentAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CommonTextAccessibility.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/GroupAccessibility.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/GroupAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ImageAccessibility.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ImageAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/RadiobuttonAccessibility.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/RadiobuttonAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ScrollAreaAccessibility.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ScrollAreaAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ScrollBarAccessibility.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ScrollBarAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/SliderAccessibility.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/SliderAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/SpinboxAccessibility.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/SpinboxAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/StaticTextAccessibility.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/StaticTextAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ToolbarAccessibility.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ToolbarAccessibility.m Changeset: 0a03fc84 Author: Jaikiran Pai Date: 2021-05-25 07:40:48 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0a03fc84b3289cf8c8effca7324f71146270a8e2 8255674: SSLEngine class description is missing "case" in switch statement Reviewed-by: xuelei ! src/java.base/share/classes/javax/net/ssl/SSLEngine.java Changeset: a52c4ede Author: Patrick Concannon Date: 2021-05-25 08:24:49 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a52c4ede2f043b7d4a234c7d06f91871312e9654 8267110: Update java.util to use instanceof pattern variable Reviewed-by: lancea, naoto ! src/java.base/share/classes/java/util/AbstractMap.java ! src/java.base/share/classes/java/util/BitSet.java ! src/java.base/share/classes/java/util/Collections.java ! src/java.base/share/classes/java/util/EnumMap.java ! src/java.base/share/classes/java/util/HashMap.java ! src/java.base/share/classes/java/util/Hashtable.java ! src/java.base/share/classes/java/util/IdentityHashMap.java ! src/java.base/share/classes/java/util/JumboEnumSet.java ! src/java.base/share/classes/java/util/KeyValueHolder.java ! src/java.base/share/classes/java/util/LinkedHashMap.java ! src/java.base/share/classes/java/util/Locale.java ! src/java.base/share/classes/java/util/Optional.java ! src/java.base/share/classes/java/util/OptionalDouble.java ! src/java.base/share/classes/java/util/OptionalInt.java ! src/java.base/share/classes/java/util/OptionalLong.java ! src/java.base/share/classes/java/util/PropertyPermission.java ! src/java.base/share/classes/java/util/RegularEnumSet.java ! src/java.base/share/classes/java/util/Scanner.java ! src/java.base/share/classes/java/util/ServiceLoader.java ! src/java.base/share/classes/java/util/SimpleTimeZone.java ! src/java.base/share/classes/java/util/TreeMap.java ! src/java.base/share/classes/java/util/TreeSet.java ! src/java.base/share/classes/java/util/WeakHashMap.java ! src/java.base/share/classes/java/util/jar/Attributes.java ! src/java.base/share/classes/java/util/jar/JarVerifier.java ! src/java.base/share/classes/java/util/jar/Manifest.java ! src/java.base/share/classes/java/util/regex/Pattern.java ! src/java.base/share/classes/java/util/regex/PrintPattern.java ! src/java.base/share/classes/java/util/zip/ZipFile.java Changeset: 66b190e1 Author: Claes Redestad Date: 2021-05-25 11:47:33 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/66b190e1e7d06f3fc59917b5346e94a128e928cd 8267612: Declare package-private VarHandle.AccessMode/AccessType counts Reviewed-by: mchung ! src/java.base/share/classes/java/lang/invoke/IndirectVarHandle.java ! src/java.base/share/classes/java/lang/invoke/Invokers.java ! src/java.base/share/classes/java/lang/invoke/VarForm.java ! src/java.base/share/classes/java/lang/invoke/VarHandle.java Changeset: b403d399 Author: Jie Fu Date: 2021-05-25 11:49:58 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b403d3990894853d6e291c8ff8abb44bddb3c99f 8267213: cpuinfo_segv is incorrectly triaged as execution protection violation on x86_32 Reviewed-by: dholmes ! src/hotspot/os_cpu/bsd_x86/os_bsd_x86.cpp ! src/hotspot/os_cpu/linux_x86/os_linux_x86.cpp Changeset: 86a8f442 Author: Maurizio Cimadamore Date: 2021-05-25 11:51:25 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/86a8f4427139f983faa57b9174c90949628236ca 8267317: Remove DeferredTypeCompleter Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ArgumentAttr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java Changeset: 5a5b807e Author: Pavel Rappo Date: 2021-05-25 14:22:36 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5a5b807e8e3b3148eea911ed1b2c9624b6846370 8267633: Clarify documentation of (Doc)TreeScanner Reviewed-by: jjg ! src/jdk.compiler/share/classes/com/sun/source/util/DocTreeScanner.java ! src/jdk.compiler/share/classes/com/sun/source/util/TreePath.java ! src/jdk.compiler/share/classes/com/sun/source/util/TreeScanner.java Changeset: cc687fd4 Author: Jonathan Gibbons Date: 2021-05-25 14:54:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/cc687fd43ade6be8760c559f3ffa909c5937727c 8267575: Add new documentation group in HtmlStyle Reviewed-by: hannesw ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlStyle.java Changeset: 2ef2450a Author: Adam Sotona Date: 2021-05-25 15:58:00 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2ef2450aa6f560a0bcf6ab687b83c2f1d9e3c87e 8263445: Duplicate key compiler.err.expected.module in compiler.properties Reviewed-by: vromero, jlahoda ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties Changeset: 594d4544 Author: Jonathan Gibbons Date: 2021-05-25 17:36:50 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/594d4544759a240690ed4c0432c8140b852aea5a 8267574: Dead code in HtmlStyle/HtmlDocletWriter Reviewed-by: hannesw ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlStyle.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css Changeset: 0b773593 Author: Joe Darcy Date: 2021-05-25 18:04:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0b7735938407fad5c2dbfb509d2d47bf172305e9 8224243: Add implSpec's to AccessibleObject and seal Executable Reviewed-by: alanb ! src/java.base/share/classes/java/lang/reflect/AccessibleObject.java ! src/java.base/share/classes/java/lang/reflect/Executable.java ! src/java.base/share/classes/java/lang/reflect/Field.java Changeset: e751b7b1 Author: Bradford Wetmore Date: 2021-05-25 19:38:00 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e751b7b1b6f7269a1fe20c07748c726536388f6d 8267683: rfc7301Grease8F value not displayed correctly in SSLParameters javadoc Reviewed-by: coffeys ! src/java.base/share/classes/javax/net/ssl/SSLParameters.java Changeset: c20ca42e Author: Coleen Phillimore Date: 2021-05-25 19:42:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c20ca42e62a0a7419c04ff95087c7c2b4d2e0335 8267691: Change table to obsolete CriticalJNINatives in JDK 18, not 17 Reviewed-by: hseigel ! src/hotspot/share/runtime/arguments.cpp Changeset: 5aa45f2e Author: Alexander Matveev Date: 2021-05-25 22:08:33 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5aa45f2edf278bab4403704ab4b6644096f8c077 8267403: tools/jpackage/share/FileAssociationsTest.java#id0 failed with "Error: Bundler "Mac PKG Package" (pkg) failed to produce a package" Reviewed-by: herrick, asemenyuk ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacPkgBundler.java ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/Executor.java ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/IOUtils.java ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/JLinkBundlerHelper.java ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/Log.java Changeset: a98e476c Author: Jie Fu Date: 2021-05-25 22:46:19 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a98e476c0a5860dd2bd9e57aeceb1f724868c970 8267311: vmTestbase/gc/gctests/StringInternGC/StringInternGC.java eventually OOMEs 8267311: vmTestbase/gc/gctests/StringInternGC/StringInternGC.java eventually OOMEs Co-authored-by: Thomas Schatzl Reviewed-by: tschatzl ! test/hotspot/jtreg/vmTestbase/gc/gctests/StringInternGC/StringInternGC.java Changeset: d0d2ddcc Author: David Holmes Date: 2021-05-25 23:35:17 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d0d2ddccaf93a1f97843e7d01c5bf6eb8ba3aece 8267651: runtime/handshake/HandshakeTimeoutTest.java times out when dumping core Reviewed-by: dcubed ! test/hotspot/jtreg/runtime/handshake/HandshakeTimeoutTest.java Changeset: ac36b7d3 Author: Tagir F. Valeev Date: 2021-05-26 01:17:02 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ac36b7d3e2d521652576fba3b1760586f582544f 8267452: Delegate forEachRemaining in Spliterators.iterator() Reviewed-by: psandoz ! src/java.base/share/classes/java/util/Spliterators.java + test/jdk/java/util/Spliterator/IteratorFromSpliteratorTest.java Changeset: b33b8bc8 Author: Bradford Wetmore Date: 2021-05-26 03:17:32 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b33b8bc88da3afe4f9f6321673df061ea4196962 8267750: Incomplete fix for JDK-8267683 Reviewed-by: jnimeh ! src/java.base/share/classes/javax/net/ssl/SSLParameters.java Changeset: 03944168 Author: Albert Mingkun Yang Date: 2021-05-26 06:50:23 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/039441689d21f3dccf515bb2be89608b0772a235 8267468: Rename refill waster counters in ThreadLocalAllocBuffer Reviewed-by: kbarrett, sspitsyn ! src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp ! src/hotspot/share/gc/shared/threadLocalAllocBuffer.hpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/resources/aliasmap Changeset: 9d305b9c Author: Roland Westrelin Date: 2021-05-26 09:20:42 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9d305b9c0625d73c752724569dbb7f6c8e80931c 8252372: Check if cloning is required to move loads out of loops in PhaseIdealLoop::split_if_with_blocks_post() Reviewed-by: thartmann, kvn ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/arm/arm.ad ! src/hotspot/cpu/ppc/ppc.ad ! src/hotspot/cpu/s390/s390.ad ! src/hotspot/cpu/x86/x86.ad ! src/hotspot/cpu/x86/x86_32.ad ! src/hotspot/cpu/x86/x86_64.ad ! src/hotspot/share/adlc/formssel.cpp ! src/hotspot/share/opto/castnode.hpp ! src/hotspot/share/opto/classes.hpp ! src/hotspot/share/opto/loopnode.cpp ! src/hotspot/share/opto/loopnode.hpp ! src/hotspot/share/opto/loopopts.cpp ! src/hotspot/share/opto/node.hpp Changeset: 083416d3 Author: Wang Huang Committer: Hamlin Li Date: 2021-05-26 10:21:46 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/083416d36c0d7fd17dd0db546129411450dfcccf 8267130: Memory Overflow in Disassembler::load_library Co-authored-by: Wang Huang Co-authored-by: Miao Zhuojun Reviewed-by: neliasso, mli ! src/hotspot/share/compiler/disassembler.cpp Changeset: bf8d4a8e Author: Athijegannathan Sundararajan Date: 2021-05-26 11:04:59 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bf8d4a8ecab216e7d117ce045d4498d1fa1a6029 8267583: jmod fails on symlink to class file Reviewed-by: alanb ! src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.java ! test/jdk/tools/jmod/JmodTest.java Changeset: f6322549 Author: Jan Lahoda Date: 2021-05-26 11:12:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f632254943e335d0b4a76d03530309cd194b0813 8267221: jshell feedback is incorrect when creating method with array varargs parameter Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java ! test/langtools/jdk/jshell/MethodsTest.java ! test/langtools/tools/javac/parser/JavacParserTest.java Changeset: 4343997a Author: Pavel Rappo Date: 2021-05-26 11:27:15 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4343997a1a2b38581488932f6a4971ce330bd467 8267708: Remove references to com.sun.tools.javadoc.** This commit changes BaseOptions.java to fix the NoStringToLower test that failed after jdk.javadoc has been added to the list of package prefixes that NoStringToLower scans. Reviewed-by: jjg ! src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacTrees.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/Log.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/BaseOptions.java ! test/langtools/jdk/javadoc/tool/CheckResourceKeys.java ! test/langtools/tools/javac/NoStringToLower.java ! test/langtools/tools/javac/T8003967/DetectMutableStaticFields.java Changeset: 45e05970 Author: Pankaj Bansal Date: 2021-05-26 12:17:21 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/45e05970bcee842f98eeeef054f574ccf4b43fad 8264302: Create implementation for Accessibility native peer for Splitpane java role Reviewed-by: kizune ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CommonComponentAccessibility.m = src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/SplitpaneAccessibility.h + src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/SplitpaneAccessibility.m Changeset: 9c346a1e Author: Yude Lin Committer: David Holmes Date: 2021-05-26 12:26:52 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9c346a1ec78b45c61fbfc76961dc5674cfd98520 8266963: Remove safepoint poll introduced in 8262443 due to reentrance issue Reviewed-by: rehn, zgu, dholmes ! src/hotspot/share/oops/generateOopMap.cpp ! src/hotspot/share/oops/generateOopMap.hpp Changeset: a4c46e1e Author: Naoto Sato Date: 2021-05-26 15:52:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a4c46e1e4f4f2f05c8002b2af683a390fc46b424 8263202: Update Hebrew/Indonesian/Yiddish ISO 639 language codes to current Reviewed-by: joehw ! make/jdk/src/classes/build/tools/cldrconverter/Bundle.java ! make/jdk/src/classes/build/tools/cldrconverter/CLDRConverter.java ! src/java.base/share/classes/java/util/Locale.java ! src/java.base/share/classes/java/util/ResourceBundle.java ! src/java.base/share/classes/java/util/spi/AbstractResourceBundleProvider.java ! src/java.base/share/classes/sun/util/locale/BaseLocale.java ! src/java.base/share/classes/sun/util/resources/Bundles.java ! src/java.base/share/classes/sun/util/resources/LocaleData.java ! src/java.desktop/share/classes/java/awt/ComponentOrientation.java = src/jdk.localedata/share/classes/sun/text/resources/ext/CollationData_he.java = src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_he.java = src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_he_IL.java = src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_id.java = src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_id_ID.java = src/jdk.localedata/share/classes/sun/text/resources/ext/JavaTimeSupplementary_he.java = src/jdk.localedata/share/classes/sun/text/resources/ext/JavaTimeSupplementary_id.java = src/jdk.localedata/share/classes/sun/util/resources/ext/CalendarData_he.properties = src/jdk.localedata/share/classes/sun/util/resources/ext/CalendarData_id_ID.properties = src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_he_IL.properties = src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_id_ID.properties = src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_he.properties = src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_id.properties ! src/jdk.localedata/share/classes/sun/util/resources/provider/LocaleDataProvider.java ! src/jdk.localedata/share/classes/sun/util/resources/provider/SupplementaryLocaleDataProvider.java ! test/jdk/java/awt/ComponentOrientation/BasicTest.java ! test/jdk/java/util/Locale/LocaleEnhanceTest.java ! test/jdk/java/util/Locale/LocaleTest.java ! test/jdk/java/util/ResourceBundle/modules/ModuleTestUtil.java ! test/jdk/java/util/ResourceBundle/modules/basic/BasicTest.java ! test/jdk/java/util/ResourceBundle/modules/basic/srcBasic/asiabundles/jdk/test/resources/asia/MyResourcesAsia.java + test/jdk/java/util/ResourceBundle/modules/basic/srcBasic/asiabundles/jdk/test/resources/asia/MyResources_id.properties ! test/jdk/java/util/ResourceBundle/modules/basic/srcBasic/eubundles/jdk/test/resources/eu/MyResourcesEU.java + test/jdk/java/util/ResourceBundle/modules/basic/srcBasic/eubundles/jdk/test/resources/eu/MyResources_ji.java ! test/jdk/java/util/ResourceBundle/modules/basic/srcBasic/test/jdk/test/Main.java ! test/jdk/tools/jlink/plugins/IncludeLocalesPluginTest.java Changeset: de91643b Author: Stefan Karlsson Date: 2021-05-26 17:57:30 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/de91643bfa80ae7cc2d228f882b2de3d8af543c8 8267611: Print more info when pointer_delta assert fails Reviewed-by: dholmes, jiefu, tschatzl, kbarrett ! src/hotspot/share/utilities/globalDefinitions.hpp Changeset: c59484e7 Author: Coleen Phillimore Date: 2021-05-26 19:07:53 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c59484e71517ea9fea7df7b0344b633495f8fd81 8267653: Remove Mutex::_safepoint_check_sometimes Reviewed-by: dholmes, pchilanomate ! src/hotspot/share/gc/shenandoah/shenandoahReferenceProcessor.cpp ! src/hotspot/share/runtime/mutex.cpp ! src/hotspot/share/runtime/mutex.hpp ! src/hotspot/share/runtime/mutexLocker.cpp ! src/hotspot/share/runtime/thread.cpp Changeset: 8c4719a5 Author: Joe Wang Date: 2021-05-26 19:34:06 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8c4719a58834dddcea39d69b199abf1aabf780e2 8265248: Implementation Specific Properties: change prefix, plus add existing properties Reviewed-by: lancea, rriggs - src/java.xml/share/classes/com/sun/org/apache/xalan/internal/XalanConstants.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/utils/FeaturePropertyBase.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/utils/XMLSecurityManager.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/utils/XMLSecurityPropertyManager.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Import.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Include.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Parser.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/XSLTC.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/LoadDocument.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/AbstractTranslet.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TemplatesHandlerImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TemplatesImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerFactoryImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/Util.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/dom/DOMConfigurationImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/Constants.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/PropertyManager.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XMLDocumentFragmentScannerImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/XMLSchemaLoader.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/XMLSchemaValidator.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/opti/SchemaParsingConfig.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDHandler.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/DocumentBuilderFactoryImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/DocumentBuilderImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/SAXParserImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/DOMValidatorHelper.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/StAXValidatorHelper.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/StreamValidatorHelper.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/ValidatorHandlerImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaFactory.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaValidatorComponentManager.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/parsers/DOMParser.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/parsers/DTDConfiguration.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/parsers/NonValidatingConfiguration.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/parsers/SAXParser.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/parsers/XML11Configuration.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/parsers/XMLParser.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/util/SecurityManager.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/utils/XMLLimitAnalyzer.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/utils/XMLSecurityManager.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/utils/XMLSecurityPropertyManager.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/xinclude/XIncludeHandler.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/OutputPropertiesFactory.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/SerializationHandler.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/SerializerBase.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/ToStream.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/dom3/DOMConstants.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/dom3/LSSerializerImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/utils/XMLReaderManager.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/CachedXPathAPI.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/XPathAPI.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/jaxp/XPathFactoryImpl.java ! src/java.xml/share/classes/javax/xml/datatype/DatatypeFactory.java + src/java.xml/share/classes/jdk/xml/internal/JdkConstants.java + src/java.xml/share/classes/jdk/xml/internal/JdkProperty.java ! src/java.xml/share/classes/jdk/xml/internal/JdkXmlFeatures.java ! src/java.xml/share/classes/jdk/xml/internal/JdkXmlUtils.java ! src/java.xml/share/classes/module-info.java + test/jaxp/javax/xml/jaxp/unittest/common/ImplPropertyTest.java Changeset: e6302354 Author: Mark Reinhold Date: 2021-05-26 20:55:53 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e63023546aaf48ae39c72ab37f6ef3f5474e19cc 8266851: Implement JEP 403: Strongly Encapsulate JDK Internals Co-authored-by: Alan Bateman Reviewed-by: mchung, alanb, hseigel ! src/hotspot/share/runtime/arguments.cpp ! src/java.base/share/classes/java/lang/Module.java ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java ! src/java.base/share/classes/java/lang/reflect/AccessibleObject.java ! src/java.base/share/classes/jdk/internal/module/ExplodedSystemModules.java - src/java.base/share/classes/jdk/internal/module/IllegalAccessLogger.java - src/java.base/share/classes/jdk/internal/module/IllegalAccessMaps.java ! src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java ! src/java.base/share/classes/jdk/internal/module/SystemModules.java - src/java.base/share/classes/jdk/internal/module/jdk8_packages.dat ! src/java.base/share/classes/sun/launcher/resources/launcher.properties ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java ! test/jdk/java/lang/ModuleTests/BasicModuleTest.java ! test/jdk/java/lang/instrument/RedefineModuleTest.java ! test/jdk/java/lang/invoke/CallerSensitiveAccess.java ! test/jdk/java/lang/reflect/AccessibleObject/CanAccessTest.java ! test/jdk/java/lang/reflect/AccessibleObject/ModuleSetAccessibleTest.java ! test/jdk/java/lang/reflect/AccessibleObject/TrySetAccessibleTest.java ! test/jdk/java/util/ResourceBundle/modules/cache/CacheTest.java ! test/jdk/jdk/modules/open/Basic.java ! test/jdk/tools/launcher/modules/addexports/manifest/AddExportsAndOpensInManifest.java ! test/jdk/tools/launcher/modules/illegalaccess/IllegalAccessTest.java - test/jdk/tools/launcher/modules/illegalaccess/TryAccess.java - test/jdk/tools/launcher/modules/illegalaccess/modules/m/module-info.java - test/jdk/tools/launcher/modules/illegalaccess/modules/m/p/Type.java - test/jdk/tools/launcher/modules/illegalaccess/patchsrc/java.base/java/lang/Helper.java Changeset: a859d87c Author: Evgeny Astigeevich Committer: Paul Hohensee Date: 2021-05-26 21:08:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a859d87cc1d0629609883968656f0187909a099d 8267721: Enable sun/security/pkcs11 tests for Amazon Linux 2 AArch64 Reviewed-by: phh ! test/jdk/sun/security/pkcs11/PKCS11Test.java Changeset: 0fc7c8d1 Author: Roger Riggs Date: 2021-05-26 22:03:13 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0fc7c8d101d526f1bc86831996b6883209d77451 8267751: (test) jtreg.SkippedException has no serial VersionUID Reviewed-by: naoto, iignatyev, iris ! test/lib/jtreg/SkippedException.java Changeset: 1899f022 Author: Vladimir Ivanov Date: 2021-05-26 22:53:28 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1899f022b1cb66ecc0615ff5939b5492e2805a1c 8267805: Add UseVtableBasedCHA to the list of JVM flags known to jtreg Reviewed-by: shade ! test/jtreg-ext/requires/VMProps.java Changeset: 6ffa3e66 Author: Jie Fu Date: 2021-05-26 22:58:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6ffa3e66db55774673ce17be4f8f2d510abf8a84 8267754: cds/appcds/loaderConstraints/LoaderConstraintsTest.java fails on x86_32 due to customized class loader is not supported Reviewed-by: minqi, dholmes, iklam ! test/hotspot/jtreg/runtime/cds/appcds/loaderConstraints/LoaderConstraintsTest.java Changeset: 37bc4e2e Author: Yasumasa Suenaga Date: 2021-05-27 04:54:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/37bc4e2e3c2968d7419dae4f421755b6f7d06090 8263635: Add --servername option to jhsdb debugd Reviewed-by: cjplummer, sspitsyn ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/DebugServer.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/HotSpotAgent.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/RMIHelper.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/SALauncher.java ! src/jdk.hotspot.agent/share/man/jhsdb.1 ! test/hotspot/jtreg/serviceability/sa/sadebugd/ClhsdbAttachToDebugServer.java ! test/hotspot/jtreg/serviceability/sa/sadebugd/ClhsdbTestConnectArgument.java ! test/hotspot/jtreg/serviceability/sa/sadebugd/DebugdConnectTest.java ! test/hotspot/jtreg/serviceability/sa/sadebugd/DebugdUtils.java ! test/hotspot/jtreg/serviceability/sa/sadebugd/DisableRegistryTest.java ! test/hotspot/jtreg/serviceability/sa/sadebugd/PmapOnDebugdTest.java ! test/hotspot/jtreg/serviceability/sa/sadebugd/RunCommandOnServerTest.java Changeset: bfa46f0a Author: Albert Mingkun Yang Date: 2021-05-27 08:09:58 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bfa46f0af30e9ec073ab5e6411ca94e140113790 8252476: as_Worker_thread() doesn't check what it intends Co-authored-by: David Holmes Reviewed-by: iklam, kbarrett ! src/hotspot/share/gc/shared/referenceProcessor.cpp ! src/hotspot/share/runtime/nonJavaThread.hpp ! src/hotspot/share/runtime/thread.hpp ! src/hotspot/share/runtime/thread.inline.hpp Changeset: 7278f56b Author: Denghui Dong Committer: Tobias Hartmann Date: 2021-05-27 08:36:34 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7278f56bb6345d7b023516d0f44de71cd74ff264 8267800: Remove the '_dirty' set in BCEscapeAnalyzer Reviewed-by: kvn, thartmann ! src/hotspot/share/ci/bcEscapeAnalyzer.cpp ! src/hotspot/share/ci/bcEscapeAnalyzer.hpp Changeset: 85f61652 Author: Dongbo He Committer: Claes Redestad Date: 2021-05-27 11:49:25 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/85f616522b2dc8e7b4c31d760c3171ac74a5490f 8267817: [TEST] Remove unnecessary init in test/micro/org/openjdk/bench/javax/crypto/full/AESGCMBench:setup Reviewed-by: redestad ! test/micro/org/openjdk/bench/javax/crypto/full/AESGCMBench.java Changeset: 3623abb7 Author: Jorn Vernee Date: 2021-05-27 12:28:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3623abb7f6d9112d4cbcffd89852e826c56ae348 8263087: Add a MethodHandle combinator that switches over a set of MethodHandles Reviewed-by: redestad ! src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java ! src/java.base/share/classes/java/lang/invoke/LambdaForm.java ! src/java.base/share/classes/java/lang/invoke/LambdaFormEditor.java ! src/java.base/share/classes/java/lang/invoke/MethodHandle.java ! src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java + test/jdk/java/lang/invoke/MethodHandles/TestTableSwitch.java + test/micro/org/openjdk/bench/java/lang/invoke/MethodHandlesTableSwitchConstant.java + test/micro/org/openjdk/bench/java/lang/invoke/MethodHandlesTableSwitchOpaqueSingle.java + test/micro/org/openjdk/bench/java/lang/invoke/MethodHandlesTableSwitchRandom.java Changeset: ec65cf83 Author: Athijegannathan Sundararajan Date: 2021-05-27 12:29:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ec65cf833294e21e9dc59dfe014148d3e1210b53 8240347: remove undocumented options from jlink --help message Reviewed-by: alanb, redestad ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/TaskHelper.java Changeset: bea4109e Author: Naoto Sato Date: 2021-05-27 13:18:34 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bea4109ef75a6536af4296db56e6ec90ab0f30fc 8187649: ArrayIndexOutOfBoundsException in java.util.JapaneseImperialCalendar Reviewed-by: joehw, rriggs ! src/java.base/share/classes/java/util/JapaneseImperialCalendar.java ! test/jdk/java/util/Calendar/CalendarTestScripts/JapaneseTests.java ! test/jdk/java/util/Calendar/CalendarTestScripts/japanese/japanese_roll.cts Changeset: 10a6f5d6 Author: Guoxiong Li Committer: Jonathan Gibbons Date: 2021-05-27 14:04:56 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/10a6f5d637053395839002b6617f94f49d3701e7 8230623: Extract command-line help for -Xlint sub-options to new --help-lint Reviewed-by: jjg ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/Arguments.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties ! test/langtools/tools/javac/options/modes/InfoOptsTest.java Changeset: ef368b32 Author: Hao Tang Committer: Severin Gehwolf Date: 2021-05-27 14:40:29 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ef368b32bc8609bdc46cda628fa25e9bcad751e3 8265836: OperatingSystemImpl.getCpuLoad() returns incorrect CPU load inside a container Co-authored-by: Shaojun Wang Co-authored-by: Severin Gehwolf Reviewed-by: sgehwolf, ysuenaga ! src/jdk.management/aix/native/libmanagement_ext/UnixOperatingSystem.c ! src/jdk.management/linux/native/libmanagement_ext/UnixOperatingSystem.c ! src/jdk.management/macosx/native/libmanagement_ext/UnixOperatingSystem.c ! src/jdk.management/unix/classes/com/sun/management/internal/OperatingSystemImpl.java Changeset: 23189a1f Author: Daniel D. Daugherty Date: 2021-05-27 14:58:26 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/23189a1f9de5e7c039a4f6b9e5eefe4fa3c6dcef 8191786: Thread-SMR hash table size should be dynamic Reviewed-by: dholmes, rehn, coleenp, eosterlund ! src/hotspot/share/runtime/threadSMR.cpp Changeset: 07542660 Author: Jonathan Gibbons Date: 2021-05-27 15:01:03 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/07542660446e47164e5a402380bdf7cbfd7b37ad 8267709: Investigate differences between HtmlStyle and stylesheet.css Reviewed-by: hannesw ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlStyle.java + test/langtools/jdk/javadoc/doclet/checkStylesheetClasses/CheckStylesheetClasses.java Changeset: 7c85f351 Author: Stuart Marks Date: 2021-05-27 15:19:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7c85f3510cb84881ff232548fbcc933ef4b34972 8267123: Remove RMI Activation Reviewed-by: erikj, rriggs, alanb ! make/modules/java.rmi/Launcher.gmk ! src/java.base/share/conf/security/java.security - src/java.rmi/share/classes/com/sun/rmi/rmid/ExecOptionPermission.java - src/java.rmi/share/classes/com/sun/rmi/rmid/ExecPermission.java ! src/java.rmi/share/classes/java/rmi/AccessException.java ! src/java.rmi/share/classes/java/rmi/NoSuchObjectException.java ! src/java.rmi/share/classes/java/rmi/Remote.java ! src/java.rmi/share/classes/java/rmi/StubNotFoundException.java - src/java.rmi/share/classes/java/rmi/activation/Activatable.java - src/java.rmi/share/classes/java/rmi/activation/ActivateFailedException.java - src/java.rmi/share/classes/java/rmi/activation/ActivationDesc.java - src/java.rmi/share/classes/java/rmi/activation/ActivationException.java - src/java.rmi/share/classes/java/rmi/activation/ActivationGroup.java - src/java.rmi/share/classes/java/rmi/activation/ActivationGroupDesc.java - src/java.rmi/share/classes/java/rmi/activation/ActivationGroupID.java - src/java.rmi/share/classes/java/rmi/activation/ActivationGroup_Stub.java - src/java.rmi/share/classes/java/rmi/activation/ActivationID.java - src/java.rmi/share/classes/java/rmi/activation/ActivationInstantiator.java - src/java.rmi/share/classes/java/rmi/activation/ActivationMonitor.java - src/java.rmi/share/classes/java/rmi/activation/ActivationSystem.java - src/java.rmi/share/classes/java/rmi/activation/Activator.java - src/java.rmi/share/classes/java/rmi/activation/UnknownGroupException.java - src/java.rmi/share/classes/java/rmi/activation/UnknownObjectException.java - src/java.rmi/share/classes/java/rmi/activation/package-info.java ! src/java.rmi/share/classes/java/rmi/server/ExportException.java ! src/java.rmi/share/classes/java/rmi/server/RMIClientSocketFactory.java ! src/java.rmi/share/classes/java/rmi/server/RMIServerSocketFactory.java ! src/java.rmi/share/classes/java/rmi/server/RemoteObject.java ! src/java.rmi/share/classes/java/rmi/server/RemoteObjectInvocationHandler.java ! src/java.rmi/share/classes/module-info.java ! src/java.rmi/share/classes/sun/rmi/registry/RegistryImpl.java - src/java.rmi/share/classes/sun/rmi/server/ActivatableRef.java - src/java.rmi/share/classes/sun/rmi/server/ActivatableServerRef.java - src/java.rmi/share/classes/sun/rmi/server/Activation$ActivationSystemImpl_Stub.java - src/java.rmi/share/classes/sun/rmi/server/Activation.java - src/java.rmi/share/classes/sun/rmi/server/ActivationGroupImpl.java - src/java.rmi/share/classes/sun/rmi/server/ActivationGroupInit.java - src/java.rmi/share/classes/sun/rmi/server/InactiveGroupException.java ! src/java.rmi/share/classes/sun/rmi/server/MarshalInputStream.java - src/java.rmi/share/classes/sun/rmi/server/resources/rmid.properties - src/java.rmi/share/classes/sun/rmi/server/resources/rmid_de.properties - src/java.rmi/share/classes/sun/rmi/server/resources/rmid_es.properties - src/java.rmi/share/classes/sun/rmi/server/resources/rmid_fr.properties - src/java.rmi/share/classes/sun/rmi/server/resources/rmid_it.properties - src/java.rmi/share/classes/sun/rmi/server/resources/rmid_ja.properties - src/java.rmi/share/classes/sun/rmi/server/resources/rmid_ko.properties - src/java.rmi/share/classes/sun/rmi/server/resources/rmid_pt_BR.properties - src/java.rmi/share/classes/sun/rmi/server/resources/rmid_sv.properties - src/java.rmi/share/classes/sun/rmi/server/resources/rmid_zh_CN.properties - src/java.rmi/share/classes/sun/rmi/server/resources/rmid_zh_TW.properties - src/java.rmi/share/man/rmid.1 ! test/jdk/ProblemList.txt ! test/jdk/TEST.groups ! test/jdk/java/rmi/RemoteException/chaining/Chaining.java - test/jdk/java/rmi/activation/Activatable/checkActivateRef/ActivateMe.java - test/jdk/java/rmi/activation/Activatable/checkActivateRef/CheckActivateRef.java - test/jdk/java/rmi/activation/Activatable/checkActivateRef/CheckActivateRef_Stub.java - test/jdk/java/rmi/activation/Activatable/checkActivateRef/group.security.policy - test/jdk/java/rmi/activation/Activatable/checkActivateRef/rmid.security.policy - test/jdk/java/rmi/activation/Activatable/checkActivateRef/security.policy - test/jdk/java/rmi/activation/Activatable/checkAnnotations/CheckAnnotations.java - test/jdk/java/rmi/activation/Activatable/checkAnnotations/CheckAnnotations_Stub.java - test/jdk/java/rmi/activation/Activatable/checkAnnotations/MyRMI.java - test/jdk/java/rmi/activation/Activatable/checkAnnotations/group.security.policy - test/jdk/java/rmi/activation/Activatable/checkAnnotations/rmid.security.policy - test/jdk/java/rmi/activation/Activatable/checkAnnotations/security.policy - test/jdk/java/rmi/activation/Activatable/checkImplClassLoader/ActivatableImpl.java - test/jdk/java/rmi/activation/Activatable/checkImplClassLoader/ActivatableImpl_Stub.java - test/jdk/java/rmi/activation/Activatable/checkImplClassLoader/CheckImplClassLoader.java - test/jdk/java/rmi/activation/Activatable/checkImplClassLoader/MyRMI.java - test/jdk/java/rmi/activation/Activatable/checkImplClassLoader/rmid.security.policy - test/jdk/java/rmi/activation/Activatable/checkImplClassLoader/security.policy - test/jdk/java/rmi/activation/Activatable/checkRegisterInLog/ActivateMe.java - test/jdk/java/rmi/activation/Activatable/checkRegisterInLog/CheckRegisterInLog.java - test/jdk/java/rmi/activation/Activatable/checkRegisterInLog/CheckRegisterInLog_Stub.java - test/jdk/java/rmi/activation/Activatable/checkRegisterInLog/group.security.policy - test/jdk/java/rmi/activation/Activatable/checkRegisterInLog/rmid.security.policy - test/jdk/java/rmi/activation/Activatable/checkRegisterInLog/security.policy - test/jdk/java/rmi/activation/Activatable/createPrivateActivable/ActivateMe.java - test/jdk/java/rmi/activation/Activatable/createPrivateActivable/CreatePrivateActivatable.java - test/jdk/java/rmi/activation/Activatable/createPrivateActivable/group.security.policy - test/jdk/java/rmi/activation/Activatable/createPrivateActivable/rmid.security.policy - test/jdk/java/rmi/activation/Activatable/createPrivateActivable/security.policy - test/jdk/java/rmi/activation/Activatable/downloadParameterClass/Bar.java - test/jdk/java/rmi/activation/Activatable/downloadParameterClass/DownloadParameterClass.java - test/jdk/java/rmi/activation/Activatable/downloadParameterClass/Foo.java - test/jdk/java/rmi/activation/Activatable/downloadParameterClass/FooReceiverImpl.java - test/jdk/java/rmi/activation/Activatable/downloadParameterClass/FooReceiverImpl_Stub.java - test/jdk/java/rmi/activation/Activatable/downloadParameterClass/group.security.policy - test/jdk/java/rmi/activation/Activatable/downloadParameterClass/manual.security.policy - test/jdk/java/rmi/activation/Activatable/downloadParameterClass/rmid.security.policy - test/jdk/java/rmi/activation/Activatable/downloadParameterClass/security.policy - test/jdk/java/rmi/activation/Activatable/elucidateNoSuchMethod/ActivateMe.java - test/jdk/java/rmi/activation/Activatable/elucidateNoSuchMethod/ElucidateNoSuchMethod.java - test/jdk/java/rmi/activation/Activatable/elucidateNoSuchMethod/ElucidateNoSuchMethod_Stub.java - test/jdk/java/rmi/activation/Activatable/elucidateNoSuchMethod/group.security.policy - test/jdk/java/rmi/activation/Activatable/elucidateNoSuchMethod/rmid.security.policy - test/jdk/java/rmi/activation/Activatable/elucidateNoSuchMethod/security.policy - test/jdk/java/rmi/activation/Activatable/extLoadedImpl/CheckLoader.java - test/jdk/java/rmi/activation/Activatable/extLoadedImpl/ExtLoadedImpl.java - test/jdk/java/rmi/activation/Activatable/extLoadedImpl/ExtLoadedImplTest.java - test/jdk/java/rmi/activation/Activatable/extLoadedImpl/ExtLoadedImpl_Stub.java - test/jdk/java/rmi/activation/Activatable/extLoadedImpl/ext.sh - test/jdk/java/rmi/activation/Activatable/extLoadedImpl/group.security.policy - test/jdk/java/rmi/activation/Activatable/extLoadedImpl/rmid.security.policy - test/jdk/java/rmi/activation/Activatable/extLoadedImpl/security.policy - test/jdk/java/rmi/activation/Activatable/forceLogSnapshot/ActivateMe.java - test/jdk/java/rmi/activation/Activatable/forceLogSnapshot/ForceLogSnapshot.java - test/jdk/java/rmi/activation/Activatable/forceLogSnapshot/ForceLogSnapshot_Skel.java - test/jdk/java/rmi/activation/Activatable/forceLogSnapshot/ForceLogSnapshot_Stub.java - test/jdk/java/rmi/activation/Activatable/forceLogSnapshot/group.security.policy - test/jdk/java/rmi/activation/Activatable/forceLogSnapshot/rmid.security.policy - test/jdk/java/rmi/activation/Activatable/forceLogSnapshot/security.policy - test/jdk/java/rmi/activation/Activatable/inactiveGroup/ActivateMe.java - test/jdk/java/rmi/activation/Activatable/inactiveGroup/InactiveGroup.java - test/jdk/java/rmi/activation/Activatable/inactiveGroup/InactiveGroup_Stub.java - test/jdk/java/rmi/activation/Activatable/inactiveGroup/group.security.policy - test/jdk/java/rmi/activation/Activatable/inactiveGroup/rmid.security.policy - test/jdk/java/rmi/activation/Activatable/inactiveGroup/security.policy - test/jdk/java/rmi/activation/Activatable/lookupActivationSystem/LookupActivationSystem.java - test/jdk/java/rmi/activation/Activatable/lookupActivationSystem/rmid.security.policy - test/jdk/java/rmi/activation/Activatable/nestedActivate/ActivateMe.java - test/jdk/java/rmi/activation/Activatable/nestedActivate/NestedActivate.java - test/jdk/java/rmi/activation/Activatable/nestedActivate/NestedActivate_Stub.java - test/jdk/java/rmi/activation/Activatable/nestedActivate/group.security.policy - test/jdk/java/rmi/activation/Activatable/nestedActivate/rmid.security.policy - test/jdk/java/rmi/activation/Activatable/nestedActivate/security.policy - test/jdk/java/rmi/activation/Activatable/nonExistentActivatable/ActivateMe.java - test/jdk/java/rmi/activation/Activatable/nonExistentActivatable/NonExistentActivatable.java - test/jdk/java/rmi/activation/Activatable/nonExistentActivatable/NonExistentActivatable_Stub.java - test/jdk/java/rmi/activation/Activatable/nonExistentActivatable/group.security.policy - test/jdk/java/rmi/activation/Activatable/nonExistentActivatable/rmid.security.policy - test/jdk/java/rmi/activation/Activatable/nonExistentActivatable/security.policy - test/jdk/java/rmi/activation/Activatable/notSerializable/NotSerializable.java - test/jdk/java/rmi/activation/Activatable/restartCrashedService/ActivateMe.java - test/jdk/java/rmi/activation/Activatable/restartCrashedService/RestartCrashedService.java - test/jdk/java/rmi/activation/Activatable/restartCrashedService/RestartCrashedService_Stub.java - test/jdk/java/rmi/activation/Activatable/restartCrashedService/group.security.policy - test/jdk/java/rmi/activation/Activatable/restartCrashedService/rmid.security.policy - test/jdk/java/rmi/activation/Activatable/restartCrashedService/security.policy - test/jdk/java/rmi/activation/Activatable/restartLatecomer/RestartLatecomer.java - test/jdk/java/rmi/activation/Activatable/restartLatecomer/RestartLatecomer_Stub.java - test/jdk/java/rmi/activation/Activatable/restartLatecomer/group.security.policy - test/jdk/java/rmi/activation/Activatable/restartLatecomer/rmid.security.policy - test/jdk/java/rmi/activation/Activatable/restartLatecomer/security.policy - test/jdk/java/rmi/activation/Activatable/restartService/ActivateMe.java - test/jdk/java/rmi/activation/Activatable/restartService/RestartService.java - test/jdk/java/rmi/activation/Activatable/restartService/RestartService_Stub.java - test/jdk/java/rmi/activation/Activatable/restartService/group.security.policy - test/jdk/java/rmi/activation/Activatable/restartService/rmid.security.policy - test/jdk/java/rmi/activation/Activatable/restartService/security.policy - test/jdk/java/rmi/activation/Activatable/shutdownGracefully/RegisteringActivatable.java - test/jdk/java/rmi/activation/Activatable/shutdownGracefully/ShutdownGracefully.java - test/jdk/java/rmi/activation/Activatable/shutdownGracefully/ShutdownGracefully_Stub.java - test/jdk/java/rmi/activation/Activatable/shutdownGracefully/TestSecurityManager.java - test/jdk/java/rmi/activation/Activatable/shutdownGracefully/group.security.policy - test/jdk/java/rmi/activation/Activatable/shutdownGracefully/rmid.security.policy - test/jdk/java/rmi/activation/Activatable/shutdownGracefully/security.policy - test/jdk/java/rmi/activation/Activatable/unregisterInactive/ActivateMe.java - test/jdk/java/rmi/activation/Activatable/unregisterInactive/UnregisterInactive.java - test/jdk/java/rmi/activation/Activatable/unregisterInactive/UnregisterInactive_Stub.java - test/jdk/java/rmi/activation/Activatable/unregisterInactive/group.security.policy - test/jdk/java/rmi/activation/Activatable/unregisterInactive/rmid.security.policy - test/jdk/java/rmi/activation/Activatable/unregisterInactive/security.policy - test/jdk/java/rmi/activation/ActivateFailedException/activateFails/ActivateFails.java - test/jdk/java/rmi/activation/ActivateFailedException/activateFails/ActivateFails_Stub.java - test/jdk/java/rmi/activation/ActivateFailedException/activateFails/ActivateMe.java - test/jdk/java/rmi/activation/ActivateFailedException/activateFails/ShutdownThread.java - test/jdk/java/rmi/activation/ActivateFailedException/activateFails/group.security.policy - test/jdk/java/rmi/activation/ActivateFailedException/activateFails/rmid.security.policy - test/jdk/java/rmi/activation/ActivateFailedException/activateFails/security.policy - test/jdk/java/rmi/activation/ActivationGroup/downloadActivationGroup/DownloadActivationGroup.java - test/jdk/java/rmi/activation/ActivationGroup/downloadActivationGroup/DownloadActivationGroup_Stub.java - test/jdk/java/rmi/activation/ActivationGroup/downloadActivationGroup/MyActivationGroupImpl.java - test/jdk/java/rmi/activation/ActivationGroup/downloadActivationGroup/group.security.policy - test/jdk/java/rmi/activation/ActivationGroup/downloadActivationGroup/rmid.security.policy - test/jdk/java/rmi/activation/ActivationGroup/downloadActivationGroup/security.policy - test/jdk/java/rmi/activation/ActivationGroupDesc/checkDefaultGroupName/CheckDefaultGroupName.java - test/jdk/java/rmi/activation/ActivationSystem/activeGroup/IdempotentActiveGroup.java - test/jdk/java/rmi/activation/ActivationSystem/activeGroup/rmid.security.policy - test/jdk/java/rmi/activation/ActivationSystem/activeGroup/security.policy - test/jdk/java/rmi/activation/ActivationSystem/modifyDescriptor/ActivateMe.java - test/jdk/java/rmi/activation/ActivationSystem/modifyDescriptor/ModifyDescriptor.java - test/jdk/java/rmi/activation/ActivationSystem/modifyDescriptor/ModifyDescriptor_Stub.java - test/jdk/java/rmi/activation/ActivationSystem/modifyDescriptor/group.security.policy - test/jdk/java/rmi/activation/ActivationSystem/modifyDescriptor/rmid.security.policy - test/jdk/java/rmi/activation/ActivationSystem/modifyDescriptor/security.policy - test/jdk/java/rmi/activation/ActivationSystem/stubClassesPermitted/CanCreateStubs.java - test/jdk/java/rmi/activation/ActivationSystem/stubClassesPermitted/StubClassesPermitted.java - test/jdk/java/rmi/activation/ActivationSystem/stubClassesPermitted/StubClassesPermitted_Stub.java - test/jdk/java/rmi/activation/ActivationSystem/stubClassesPermitted/group.security.policy - test/jdk/java/rmi/activation/ActivationSystem/stubClassesPermitted/rmid.security.policy - test/jdk/java/rmi/activation/ActivationSystem/stubClassesPermitted/security.policy - test/jdk/java/rmi/activation/ActivationSystem/unregisterGroup/ActivateMe.java - test/jdk/java/rmi/activation/ActivationSystem/unregisterGroup/UnregisterGroup.java - test/jdk/java/rmi/activation/ActivationSystem/unregisterGroup/group.security.policy - test/jdk/java/rmi/activation/ActivationSystem/unregisterGroup/rmid.security.policy - test/jdk/java/rmi/activation/ActivationSystem/unregisterGroup/security.policy - test/jdk/java/rmi/activation/CommandEnvironment/Doctor.java - test/jdk/java/rmi/activation/CommandEnvironment/Doctor_Stub.java - test/jdk/java/rmi/activation/CommandEnvironment/Eliza.java - test/jdk/java/rmi/activation/CommandEnvironment/NullOptions.java - test/jdk/java/rmi/activation/CommandEnvironment/Retireable.java - test/jdk/java/rmi/activation/CommandEnvironment/SetChildEnv.java - test/jdk/java/rmi/activation/CommandEnvironment/group.security.policy - test/jdk/java/rmi/activation/CommandEnvironment/rmid.security.policy - test/jdk/java/rmi/activation/CommandEnvironment/security.policy - test/jdk/java/rmi/activation/log/LogTest.java - test/jdk/java/rmi/activation/nonLocalActivation/NonLocalActivationTest.java - test/jdk/java/rmi/activation/rmidViaInheritedChannel/InheritedChannelNotServerSocket.java - test/jdk/java/rmi/activation/rmidViaInheritedChannel/rmid.security.policy ! test/jdk/java/rmi/registry/altSecurityManager/AltSecurityManager.java ! test/jdk/java/rmi/registry/altSecurityManager/TestSecurityManager.java ! test/jdk/java/rmi/registry/altSecurityManager/rmid.security.policy - test/jdk/java/rmi/server/RMISocketFactory/useSocketFactory/activatable/CompressConstants.java - test/jdk/java/rmi/server/RMISocketFactory/useSocketFactory/activatable/CompressInputStream.java - test/jdk/java/rmi/server/RMISocketFactory/useSocketFactory/activatable/CompressOutputStream.java - test/jdk/java/rmi/server/RMISocketFactory/useSocketFactory/activatable/Echo.java - test/jdk/java/rmi/server/RMISocketFactory/useSocketFactory/activatable/EchoImpl.java - test/jdk/java/rmi/server/RMISocketFactory/useSocketFactory/activatable/EchoImpl_Stub.java - test/jdk/java/rmi/server/RMISocketFactory/useSocketFactory/activatable/MultiSocketFactory.java - test/jdk/java/rmi/server/RMISocketFactory/useSocketFactory/activatable/UseCustomSocketFactory.java - test/jdk/java/rmi/server/RMISocketFactory/useSocketFactory/activatable/group.security.policy - test/jdk/java/rmi/server/RMISocketFactory/useSocketFactory/activatable/rmid.security.policy - test/jdk/java/rmi/server/RMISocketFactory/useSocketFactory/activatable/security.policy ! test/jdk/java/rmi/server/RMISocketFactory/useSocketFactory/registry/security.policy ! test/jdk/java/rmi/server/RMISocketFactory/useSocketFactory/unicast/UseCustomSocketFactory.java ! test/jdk/java/rmi/server/RMISocketFactory/useSocketFactory/unicast/security.policy ! test/jdk/java/rmi/server/RemoteObject/unrecognizedRefType/UnrecognizedRefType.java ! test/jdk/java/rmi/server/clientStackTrace/security.policy - test/jdk/java/rmi/testlibrary/ActivationLibrary.java ! test/jdk/java/rmi/testlibrary/JavaVM.java ! test/jdk/java/rmi/testlibrary/README.jcov - test/jdk/java/rmi/testlibrary/RMID.java - test/jdk/java/rmi/testlibrary/RMIDSelectorProvider.java ! test/jdk/java/rmi/testlibrary/TestLibrary.java ! test/jdk/java/rmi/testlibrary/TestParams.java ! test/jdk/java/rmi/transport/checkLeaseInfoLeak/security.policy ! test/jdk/java/rmi/transport/dgcDeadLock/registry.security.policy ! test/jdk/java/rmi/transport/dgcDeadLock/security.policy ! test/jdk/java/security/PermissionCollection/Concurrent.java ! test/jdk/tools/launcher/HelpFlagsTest.java ! test/jdk/tools/launcher/VersionCheck.java Changeset: 41185d38 Author: Xin Liu Committer: Paul Hohensee Date: 2021-05-27 16:35:24 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/41185d38f21e448370433f7e4f1633777cab6170 8229517: Support for optional asynchronous/buffered logging Reviewed-by: ysuenaga, simonis, stuefe, phh, dholmes, ayang ! src/hotspot/os/windows/os_windows.cpp + src/hotspot/share/logging/logAsyncWriter.cpp + src/hotspot/share/logging/logAsyncWriter.hpp ! src/hotspot/share/logging/logConfiguration.cpp ! src/hotspot/share/logging/logConfiguration.hpp ! src/hotspot/share/logging/logDecorators.hpp ! src/hotspot/share/logging/logFileOutput.cpp ! src/hotspot/share/logging/logFileOutput.hpp ! src/hotspot/share/logging/logOutputList.hpp ! src/hotspot/share/logging/logTagSet.hpp ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/globals.hpp ! src/hotspot/share/runtime/init.cpp ! src/hotspot/share/runtime/os.hpp ! src/hotspot/share/runtime/thread.cpp ! src/hotspot/share/runtime/thread.hpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/hotspot/share/utilities/hashtable.cpp ! test/hotspot/gtest/logging/logTestFixture.cpp ! test/hotspot/gtest/logging/logTestUtils.inline.hpp + test/hotspot/gtest/logging/test_asynclog.cpp ! test/hotspot/gtest/logging/test_log.cpp + test/hotspot/jtreg/gtest/AsyncLogGtest.java Changeset: ae258f1e Author: ?????? ??????? Committer: Claes Redestad Date: 2021-05-27 20:21:34 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ae258f1e6a6335585190aaa9358a4290a453fdbf 8265418: Clean-up redundant null-checks of Class.getPackageName() Reviewed-by: redestad ! src/java.base/share/classes/java/io/ObjectStreamClass.java ! src/java.base/share/classes/java/lang/Class.java ! src/java.base/share/classes/java/util/concurrent/atomic/AtomicIntegerFieldUpdater.java ! src/java.base/share/classes/java/util/concurrent/atomic/AtomicLongFieldUpdater.java ! src/java.base/share/classes/java/util/concurrent/atomic/AtomicReferenceFieldUpdater.java ! src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java ! src/java.base/share/classes/sun/invoke/util/VerifyAccess.java ! src/java.base/share/classes/sun/reflect/misc/ReflectUtil.java Changeset: 8a31c075 Author: Daniel D. Daugherty Date: 2021-05-27 20:26:05 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8a31c07598cd5ea1305a9706d80b0251fd3a1e6d 8267886: ProblemList javax/management/remote/mandatory/connection/RMIConnector_NPETest.java Reviewed-by: smarks ! test/jdk/ProblemList.txt Changeset: 7f52c50b Author: Alexander Zuev Date: 2021-05-27 21:49:20 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7f52c50ba32eecf5f379f8db30ac6a5cc50b3b66 8182043: Access to Windows Large Icons Reviewed-by: aivanov, azvegint, prr ! src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java ! src/java.desktop/share/classes/sun/awt/shell/ShellFolder.java ! src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java ! src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolderManager2.java ! src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp + test/jdk/javax/swing/JFileChooser/FileSystemView/SystemIconTest.java Changeset: 95b1fa7a Author: Claes Redestad Date: 2021-05-27 23:09:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/95b1fa7a88ec3c017734c9d0a6b6b6117f74a610 8267529: StringJoiner can create a String that breaks String::equals Reviewed-by: naoto ! src/java.base/share/classes/java/lang/String.java ! test/jdk/java/lang/String/StringJoinTest.java Changeset: 0c9daa7e Author: Tagir F. Valeev Date: 2021-05-28 01:56:38 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0c9daa7ed579cd82343f37a68964876ebc48122e 8265029: Preserve SIZED characteristics on slice operations (skip, limit) Reviewed-by: psandoz ! src/java.base/share/classes/java/util/stream/AbstractPipeline.java ! src/java.base/share/classes/java/util/stream/PipelineHelper.java ! src/java.base/share/classes/java/util/stream/ReduceOps.java ! src/java.base/share/classes/java/util/stream/SliceOps.java ! src/java.base/share/classes/java/util/stream/StreamOpFlag.java ! src/java.base/share/classes/java/util/stream/StreamSpliterators.java ! test/jdk/java/util/stream/test/org/openjdk/tests/java/util/stream/CountTest.java ! test/jdk/java/util/stream/test/org/openjdk/tests/java/util/stream/SliceOpTest.java + test/micro/org/openjdk/bench/java/util/stream/ops/ref/SliceToList.java + test/micro/org/openjdk/bench/java/util/stream/ops/value/SizedCount.java + test/micro/org/openjdk/bench/java/util/stream/ops/value/SizedSum.java + test/micro/org/openjdk/bench/java/util/stream/ops/value/SliceToArray.java Changeset: 6eb91145 Author: Jaroslav Tulach Committer: Jonathan Gibbons Date: 2021-05-28 04:16:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6eb91145823275248d049f8557462f09270c0b36 8266877: Missing local debug information when debugging JEP-330 Reviewed-by: alanb, jjg ! src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/Main.java Changeset: 97ec5ad0 Author: Robbin Ehn Date: 2021-05-28 07:30:14 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/97ec5ad0a6ed2cd87a9c75b0559e9bb55b72121e 8265753: Remove manual JavaThread transitions to blocked Reviewed-by: dcubed, rrich, dholmes, pchilanomate ! src/hotspot/share/prims/jvmtiEnv.cpp ! src/hotspot/share/prims/jvmtiRawMonitor.cpp ! src/hotspot/share/prims/jvmtiRawMonitor.hpp ! src/hotspot/share/runtime/handshake.cpp ! src/hotspot/share/runtime/handshake.hpp ! src/hotspot/share/runtime/interfaceSupport.inline.hpp ! src/hotspot/share/runtime/objectMonitor.cpp ! src/hotspot/share/runtime/objectMonitor.hpp Changeset: 1d2c7ac3 Author: Volker Simonis Date: 2021-05-28 08:32:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1d2c7ac3f7492b335757bf0fd3f6ca3941c5fc72 8267555: Fix class file version during redefinition after 8238048 Reviewed-by: coleenp, sspitsyn ! src/hotspot/share/oops/constantPool.cpp ! src/hotspot/share/prims/jvmtiRedefineClasses.cpp + test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/ClassVersionAfterRedefine.java + test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/TestClassNew.jasm + test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/TestClassOld.jasm Changeset: d85793d0 Author: duke Date: 2021-05-28 11:00:54 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d85793d0e995a30e751e519029e3a61f19974cef Automatic merge of jdk:master into master Changeset: 1413f9e0 Author: Jie Fu Date: 2021-05-28 13:51:37 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1413f9e070b19bed33a4552f3e7adb53cf7daf73 8241423: NUMA APIs fail to work in dockers due to dependent syscalls are disabled by default Reviewed-by: dholmes, pliden ! src/hotspot/os/linux/os_linux.cpp Changeset: 24bf35f8 Author: Daniel Fuchs Date: 2021-05-28 14:21:11 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/24bf35f862e285eeca662b9829901c0f91d247d5 8265367: [macos-aarch64] 3 java/net/httpclient/websocket tests fail with "IOException: No buffer space available" Reviewed-by: chegar ! src/java.net.http/share/classes/jdk/internal/net/http/HttpClientImpl.java ! src/java.net.http/share/classes/jdk/internal/net/http/PlainHttpConnection.java ! test/jdk/ProblemList.txt ! test/jdk/java/net/httpclient/websocket/BlowupOutputQueue.java ! test/jdk/java/net/httpclient/websocket/DummyWebSocketServer.java ! test/jdk/java/net/httpclient/websocket/PendingBinaryPingClose.java ! test/jdk/java/net/httpclient/websocket/PendingBinaryPongClose.java ! test/jdk/java/net/httpclient/websocket/PendingOperations.java ! test/jdk/java/net/httpclient/websocket/PendingPingBinaryClose.java ! test/jdk/java/net/httpclient/websocket/PendingPingTextClose.java ! test/jdk/java/net/httpclient/websocket/PendingPongBinaryClose.java ! test/jdk/java/net/httpclient/websocket/PendingPongTextClose.java ! test/jdk/java/net/httpclient/websocket/PendingTextPingClose.java ! test/jdk/java/net/httpclient/websocket/PendingTextPongClose.java Changeset: 0c0ff7fb Author: Aleksei Efimov Date: 2021-05-28 14:54:49 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0c0ff7fb0c1ff45ebaee863f73902cab1e9de4f3 8265309: com/sun/jndi/dns/ConfigTests/Timeout.java fails with "Address already in use" BindException Reviewed-by: dfuchs ! src/jdk.naming.dns/share/classes/com/sun/jndi/dns/DnsClient.java ! test/jdk/com/sun/jndi/dns/ConfigTests/Timeout.java Changeset: 591b0c3a Author: Daniel D. Daugherty Date: 2021-05-28 16:24:04 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/591b0c3a463e07d2ec26047f0e61855cbfde13b6 8264624: change the guarantee() calls added by JDK-8264123 to assert() calls Reviewed-by: pchilanomate, coleenp ! src/hotspot/share/runtime/threadSMR.cpp ! src/hotspot/share/runtime/threadSMR.hpp Changeset: 964bac9e Author: Nikita Gubarkov Committer: Alexey Ushakov Date: 2021-05-28 19:53:57 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/964bac9e38460df4bd1ad9d25136d5e9743028dd 8267706: bin/idea.sh tries to use cygpath on WSL Reviewed-by: erikj ! bin/idea.sh - make/ide/idea/jdk/build.xml ! make/ide/idea/jdk/idea.gmk - make/ide/idea/jdk/template/ant.xml ! make/ide/idea/jdk/template/compiler.xml ! make/ide/idea/jdk/template/jdk.iml ! make/ide/idea/jdk/template/misc.xml + make/ide/idea/jdk/template/module.iml ! make/ide/idea/jdk/template/modules.xml - make/ide/idea/jdk/template/src/idea/IdeaLoggerWrapper.java - make/ide/idea/jdk/template/src/idea/JdkIdeaAntLogger.java + make/ide/idea/jdk/template/test.iml ! make/ide/idea/jdk/template/vcs.xml ! make/ide/idea/jdk/template/workspace.xml Changeset: 66274320 Author: Daniel D. Daugherty Date: 2021-05-29 17:46:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/66274320251f492b0bba79cdfef88ad5b0d104fa 8267953: restore 'volatile' to ObjectMonitor::_owner field Reviewed-by: aph ! src/hotspot/share/runtime/objectMonitor.hpp Changeset: 9031477f Author: Jie Fu Date: 2021-05-30 23:03:57 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9031477f275a2ecab4167b5367a25731e5e14c2a 8267945: ZGC: Revert NUMA changes (JDK-8266217 and JDK-8241354) after JDK-8241423 Reviewed-by: pliden ! src/hotspot/os/bsd/gc/z/zNUMA_bsd.cpp ! src/hotspot/os/linux/gc/z/zNUMA_linux.cpp ! src/hotspot/os/windows/gc/z/zNUMA_windows.cpp ! src/hotspot/share/gc/z/zNUMA.cpp ! src/hotspot/share/gc/z/zNUMA.hpp ! src/hotspot/share/gc/z/zNUMA.inline.hpp Changeset: 1ab27769 Author: Hannes Walln?fer Date: 2021-05-31 06:45:37 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1ab277694740ce77ad70d030c437f47359dbd64e 8247608: Javadoc: CSS margin is not applied consistently Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css Changeset: 236bd89d Author: Dmitry Batrak Date: 2021-05-31 07:14:53 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/236bd89dc3be60cac13099618f5e6518437a5098 8263583: Emoji rendering on macOS Reviewed-by: serb, prr ! src/java.desktop/macosx/native/libawt_lwawt/font/AWTFont.h ! src/java.desktop/macosx/native/libawt_lwawt/font/AWTFont.m ! src/java.desktop/macosx/native/libawt_lwawt/font/AWTStrike.m ! src/java.desktop/macosx/native/libawt_lwawt/font/CGGlyphImages.h ! src/java.desktop/macosx/native/libawt_lwawt/font/CGGlyphImages.m ! src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLTextRenderer.m + src/java.desktop/share/classes/sun/font/ColorGlyphSurfaceData.java ! src/java.desktop/share/classes/sun/font/GlyphList.java ! src/java.desktop/share/classes/sun/java2d/SurfaceData.java ! src/java.desktop/share/classes/sun/java2d/loops/DrawGlyphList.java ! src/java.desktop/share/classes/sun/java2d/loops/DrawGlyphListAA.java + src/java.desktop/share/classes/sun/java2d/loops/DrawGlyphListColor.java ! src/java.desktop/share/classes/sun/java2d/loops/DrawGlyphListLCD.java ! src/java.desktop/share/classes/sun/java2d/loops/GeneralRenderer.java ! src/java.desktop/share/classes/sun/java2d/loops/RenderLoops.java ! src/java.desktop/share/classes/sun/java2d/pipe/AATextRenderer.java ! src/java.desktop/share/classes/sun/java2d/pipe/GlyphListLoopPipe.java ! src/java.desktop/share/classes/sun/java2d/pipe/LCDTextRenderer.java ! src/java.desktop/share/classes/sun/java2d/pipe/SolidTextRenderer.java ! src/java.desktop/share/classes/sun/java2d/pipe/TextRenderer.java ! src/java.desktop/share/native/common/java2d/opengl/OGLTextRenderer.c + src/java.desktop/share/native/libfontmanager/ColorGlyphSurfaceData.c ! src/java.desktop/share/native/libfontmanager/DrawGlyphList.c ! src/java.desktop/share/native/libfontmanager/glyphblitting.h ! src/java.desktop/share/native/libfontmanager/sunFont.c ! src/java.desktop/unix/classes/sun/font/X11TextRenderer.java ! src/java.desktop/unix/classes/sun/font/XRTextRenderer.java ! src/java.desktop/unix/native/libfontmanager/X11TextRenderer.c + test/jdk/java/awt/font/MacEmoji.java Changeset: 1e29005a Author: Martin Doerr Date: 2021-05-31 08:27:52 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1e29005a22c7951242cf3b0d8cf2e6adc0b7b315 8267842: SIGSEGV in get_current_contended_monitor Reviewed-by: stefank, dcubed, ysuenaga, dholmes ! src/hotspot/share/runtime/thread.hpp ! src/hotspot/share/runtime/vmStructs.cpp Changeset: 35916ed5 Author: Vladimir Ivanov Date: 2021-05-31 08:45:07 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/35916ed57f425ea674de1e9d5023e7cf199a6740 8267806: C1: Relax inlining checks for not yet initialized classes Reviewed-by: roland, thartmann ! src/hotspot/share/c1/c1_GraphBuilder.cpp Changeset: ab5a7ff2 Author: Tagir F. Valeev Date: 2021-05-31 08:48:38 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ab5a7ff2304dd4cb069ae2bbd6fdd99b3de7a6a3 8267587: Update java.util to use enhanced switch Reviewed-by: iris ! src/java.base/share/classes/java/util/Calendar.java ! src/java.base/share/classes/java/util/Formatter.java ! src/java.base/share/classes/java/util/GregorianCalendar.java ! src/java.base/share/classes/java/util/JapaneseImperialCalendar.java ! src/java.base/share/classes/java/util/Locale.java ! src/java.base/share/classes/java/util/Properties.java ! src/java.base/share/classes/java/util/PropertyPermission.java ! src/java.base/share/classes/java/util/ResourceBundle.java ! src/java.base/share/classes/java/util/SimpleTimeZone.java ! src/java.base/share/classes/java/util/jar/JarFile.java ! src/java.base/share/classes/java/util/regex/CharPredicates.java ! src/java.base/share/classes/java/util/regex/Pattern.java ! src/java.base/share/classes/java/util/regex/PrintPattern.java ! src/java.base/share/classes/java/util/stream/Nodes.java ! src/java.base/share/classes/java/util/zip/ZipOutputStream.java Changeset: 64f0f689 Author: Stefan Karlsson Date: 2021-05-31 08:59:19 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/64f0f68958a74d4ee34c4b738759fc2278fa8b47 8267464: Circular-dependency resilient inline headers Reviewed-by: kbarrett, eosterlund, dholmes, kvn ! doc/hotspot-style.html ! doc/hotspot-style.md ! src/hotspot/cpu/aarch64/vtableStubs_aarch64.cpp ! src/hotspot/cpu/arm/icBuffer_arm.cpp ! src/hotspot/cpu/arm/icache_arm.cpp ! src/hotspot/cpu/arm/jniFastGetField_arm.cpp ! src/hotspot/cpu/arm/nativeInst_arm_32.cpp ! src/hotspot/cpu/arm/relocInfo_arm.cpp ! src/hotspot/cpu/arm/runtime_arm.cpp ! src/hotspot/cpu/arm/sharedRuntime_arm.cpp ! src/hotspot/cpu/arm/stubGenerator_arm.cpp ! src/hotspot/cpu/arm/vtableStubs_arm.cpp ! src/hotspot/cpu/ppc/icBuffer_ppc.cpp ! src/hotspot/cpu/zero/assembler_zero.cpp ! src/hotspot/cpu/zero/icBuffer_zero.cpp ! src/hotspot/cpu/zero/icache_zero.cpp ! src/hotspot/cpu/zero/jniFastGetField_zero.cpp ! src/hotspot/cpu/zero/nativeInst_zero.cpp ! src/hotspot/cpu/zero/sharedRuntime_zero.cpp ! src/hotspot/cpu/zero/stubGenerator_zero.cpp ! src/hotspot/cpu/zero/vm_version_zero.cpp ! src/hotspot/os/aix/os_aix.inline.hpp ! src/hotspot/os/bsd/os_bsd.inline.hpp ! src/hotspot/os/linux/os_linux.inline.hpp ! src/hotspot/os/posix/os_posix.inline.hpp ! src/hotspot/os/windows/os_windows.inline.hpp ! src/hotspot/os_cpu/bsd_zero/os_bsd_zero.cpp ! src/hotspot/os_cpu/linux_arm/os_linux_arm.cpp ! src/hotspot/os_cpu/linux_zero/os_linux_zero.cpp ! src/hotspot/share/asm/macroAssembler.inline.hpp ! src/hotspot/share/c1/c1_ValueSet.inline.hpp ! src/hotspot/share/cds/archiveUtils.inline.hpp ! src/hotspot/share/cds/heapShared.inline.hpp ! src/hotspot/share/ci/ciUtilities.inline.hpp ! src/hotspot/share/classfile/classLoader.inline.hpp ! src/hotspot/share/classfile/classLoaderData.inline.hpp ! src/hotspot/share/classfile/classLoaderDataGraph.inline.hpp ! src/hotspot/share/classfile/javaClasses.inline.hpp ! src/hotspot/share/code/compiledMethod.inline.hpp ! src/hotspot/share/code/oopRecorder.inline.hpp ! src/hotspot/share/code/vmreg.inline.hpp ! src/hotspot/share/gc/g1/g1AllocRegion.inline.hpp ! src/hotspot/share/gc/g1/g1Allocator.inline.hpp ! src/hotspot/share/gc/g1/g1BarrierSet.inline.hpp ! src/hotspot/share/gc/g1/g1BlockOffsetTable.inline.hpp ! src/hotspot/share/gc/g1/g1CardTable.inline.hpp ! src/hotspot/share/gc/g1/g1CollectedHeap.inline.hpp ! src/hotspot/share/gc/g1/g1CommittedRegionMap.inline.hpp ! src/hotspot/share/gc/g1/g1ConcurrentMark.inline.hpp ! src/hotspot/share/gc/g1/g1ConcurrentMarkBitMap.inline.hpp ! src/hotspot/share/gc/g1/g1ConcurrentMarkObjArrayProcessor.inline.hpp ! src/hotspot/share/gc/g1/g1ConcurrentMarkThread.inline.hpp ! src/hotspot/share/gc/g1/g1EvacStats.inline.hpp ! src/hotspot/share/gc/g1/g1FullCollector.inline.hpp ! src/hotspot/share/gc/g1/g1FullGCMarker.hpp ! src/hotspot/share/gc/g1/g1FullGCMarker.inline.hpp ! src/hotspot/share/gc/g1/g1FullGCOopClosures.inline.hpp ! src/hotspot/share/gc/g1/g1OopClosures.inline.hpp ! src/hotspot/share/gc/g1/g1OopStarChunkedList.inline.hpp ! src/hotspot/share/gc/g1/g1ParScanThreadState.inline.hpp ! src/hotspot/share/gc/g1/g1RegionMarkStatsCache.inline.hpp ! src/hotspot/share/gc/g1/heapRegion.inline.hpp ! src/hotspot/share/gc/g1/heapRegionManager.inline.hpp ! src/hotspot/share/gc/g1/heapRegionRemSet.inline.hpp ! src/hotspot/share/gc/g1/heapRegionSet.inline.hpp ! src/hotspot/share/gc/g1/sparsePRT.inline.hpp ! src/hotspot/share/gc/parallel/parMarkBitMap.inline.hpp ! src/hotspot/share/gc/parallel/parallelScavengeHeap.inline.hpp ! src/hotspot/share/gc/parallel/psClosure.inline.hpp ! src/hotspot/share/gc/parallel/psCompactionManager.inline.hpp ! src/hotspot/share/gc/parallel/psParallelCompact.inline.hpp ! src/hotspot/share/gc/parallel/psPromotionLAB.inline.hpp ! src/hotspot/share/gc/parallel/psPromotionManager.inline.hpp ! src/hotspot/share/gc/parallel/psScavenge.inline.hpp ! src/hotspot/share/gc/serial/defNewGeneration.inline.hpp ! src/hotspot/share/gc/serial/markSweep.inline.hpp ! src/hotspot/share/gc/serial/serialHeap.inline.hpp ! src/hotspot/share/gc/serial/tenuredGeneration.inline.hpp ! src/hotspot/share/gc/shared/ageTable.inline.hpp ! src/hotspot/share/gc/shared/barrierSet.inline.hpp ! src/hotspot/share/gc/shared/blockOffsetTable.inline.hpp ! src/hotspot/share/gc/shared/cardGeneration.inline.hpp ! src/hotspot/share/gc/shared/cardTableBarrierSet.inline.hpp ! src/hotspot/share/gc/shared/collectedHeap.inline.hpp ! src/hotspot/share/gc/shared/gcLocker.inline.hpp ! src/hotspot/share/gc/shared/gcTraceTime.inline.hpp ! src/hotspot/share/gc/shared/gcUtil.inline.hpp ! src/hotspot/share/gc/shared/genOopClosures.inline.hpp ! src/hotspot/share/gc/shared/locationPrinter.inline.hpp ! src/hotspot/share/gc/shared/markBitMap.inline.hpp ! src/hotspot/share/gc/shared/modRefBarrierSet.inline.hpp ! src/hotspot/share/gc/shared/oopStorage.inline.hpp ! src/hotspot/share/gc/shared/oopStorageParState.inline.hpp ! src/hotspot/share/gc/shared/oopStorageSet.inline.hpp ! src/hotspot/share/gc/shared/oopStorageSetParState.inline.hpp ! src/hotspot/share/gc/shared/partialArrayTaskStepper.inline.hpp ! src/hotspot/share/gc/shared/plab.inline.hpp ! src/hotspot/share/gc/shared/preservedMarks.inline.hpp ! src/hotspot/share/gc/shared/referenceProcessor.inline.hpp ! src/hotspot/share/gc/shared/space.inline.hpp ! src/hotspot/share/gc/shared/spaceDecorator.inline.hpp ! src/hotspot/share/gc/shared/taskqueue.inline.hpp ! src/hotspot/share/gc/shared/threadLocalAllocBuffer.inline.hpp ! src/hotspot/share/gc/shared/weakProcessor.inline.hpp ! src/hotspot/share/gc/shared/workerDataArray.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahBarrierSetClone.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahClosures.hpp ! src/hotspot/share/gc/shenandoah/shenandoahClosures.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahCollectionSet.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahEvacOOMHandler.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahForwarding.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahHeapRegionSet.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahMark.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahMarkBitMap.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahMarkingContext.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahNMethod.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahOopClosures.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahPacer.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahPadding.hpp ! src/hotspot/share/gc/shenandoah/shenandoahParallelCleaning.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahStringDedup.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahTaskqueue.inline.hpp ! src/hotspot/share/gc/z/zAbort.inline.hpp ! src/hotspot/share/gc/z/zAddress.inline.hpp ! src/hotspot/share/gc/z/zArray.inline.hpp ! src/hotspot/share/gc/z/zAttachedArray.inline.hpp ! src/hotspot/share/gc/z/zBarrier.inline.hpp ! src/hotspot/share/gc/z/zBarrierSet.inline.hpp ! src/hotspot/share/gc/z/zBitMap.inline.hpp ! src/hotspot/share/gc/z/zCPU.inline.hpp ! src/hotspot/share/gc/z/zForwarding.inline.hpp ! src/hotspot/share/gc/z/zForwardingAllocator.inline.hpp ! src/hotspot/share/gc/z/zForwardingTable.inline.hpp ! src/hotspot/share/gc/z/zFuture.inline.hpp ! src/hotspot/share/gc/z/zGranuleMap.inline.hpp ! src/hotspot/share/gc/z/zHash.inline.hpp ! src/hotspot/share/gc/z/zHeap.inline.hpp ! src/hotspot/share/gc/z/zList.inline.hpp ! src/hotspot/share/gc/z/zLiveMap.inline.hpp ! src/hotspot/share/gc/z/zLock.inline.hpp ! src/hotspot/share/gc/z/zMark.inline.hpp ! src/hotspot/share/gc/z/zMarkCache.inline.hpp ! src/hotspot/share/gc/z/zMarkStack.inline.hpp ! src/hotspot/share/gc/z/zMarkTerminate.inline.hpp ! src/hotspot/share/gc/z/zMemory.inline.hpp ! src/hotspot/share/gc/z/zMessagePort.inline.hpp ! src/hotspot/share/gc/z/zPage.inline.hpp ! src/hotspot/share/gc/z/zPageTable.inline.hpp ! src/hotspot/share/gc/z/zPhysicalMemory.inline.hpp ! src/hotspot/share/gc/z/zRelocationSet.inline.hpp ! src/hotspot/share/gc/z/zRelocationSetSelector.inline.hpp ! src/hotspot/share/gc/z/zResurrection.inline.hpp ! src/hotspot/share/gc/z/zSafeDelete.inline.hpp ! src/hotspot/share/gc/z/zThread.inline.hpp ! src/hotspot/share/gc/z/zTracer.inline.hpp ! src/hotspot/share/gc/z/zUtils.inline.hpp ! src/hotspot/share/gc/z/zValue.inline.hpp ! src/hotspot/share/gc/z/zVirtualMemory.inline.hpp ! src/hotspot/share/gc/z/zWorkers.inline.hpp ! src/hotspot/share/interpreter/bytecode.inline.hpp ! src/hotspot/share/interpreter/zero/bytecodeInterpreter.inline.hpp ! src/hotspot/share/jfr/leakprofiler/chains/bitset.inline.hpp ! src/hotspot/share/jfr/leakprofiler/utilities/unifiedOopRef.inline.hpp ! src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceId.inline.hpp ! src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp ! src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdLoadBarrier.inline.hpp ! src/hotspot/share/jfr/recorder/storage/jfrEpochStorage.inline.hpp ! src/hotspot/share/jfr/recorder/storage/jfrFullStorage.inline.hpp ! src/hotspot/share/jfr/recorder/storage/jfrMemorySpace.inline.hpp ! src/hotspot/share/jfr/recorder/storage/jfrStorageUtils.inline.hpp ! src/hotspot/share/jfr/utilities/jfrConcurrentLinkedListHost.inline.hpp ! src/hotspot/share/jfr/utilities/jfrConcurrentQueue.inline.hpp ! src/hotspot/share/jfr/utilities/jfrEpochQueue.inline.hpp ! src/hotspot/share/jfr/utilities/jfrLinkedList.inline.hpp ! src/hotspot/share/jfr/utilities/jfrVersionSystem.inline.hpp ! src/hotspot/share/jfr/writers/jfrStreamWriterHost.inline.hpp ! src/hotspot/share/jfr/writers/jfrWriterHost.inline.hpp ! src/hotspot/share/jvmci/jniAccessMark.inline.hpp ! src/hotspot/share/memory/allocation.inline.hpp ! src/hotspot/share/memory/iterator.inline.hpp ! src/hotspot/share/memory/padded.inline.hpp ! src/hotspot/share/memory/resourceArea.inline.hpp ! src/hotspot/share/oops/access.inline.hpp ! src/hotspot/share/oops/accessBackend.inline.hpp ! src/hotspot/share/oops/array.inline.hpp ! src/hotspot/share/oops/arrayKlass.inline.hpp ! src/hotspot/share/oops/compiledICHolder.inline.hpp ! src/hotspot/share/oops/compressedOops.inline.hpp ! src/hotspot/share/oops/constantPool.inline.hpp ! src/hotspot/share/oops/cpCache.inline.hpp ! src/hotspot/share/oops/fieldStreams.inline.hpp ! src/hotspot/share/oops/instanceClassLoaderKlass.inline.hpp ! src/hotspot/share/oops/instanceKlass.inline.hpp ! src/hotspot/share/oops/instanceMirrorKlass.inline.hpp ! src/hotspot/share/oops/instanceRefKlass.inline.hpp ! src/hotspot/share/oops/klass.inline.hpp ! src/hotspot/share/oops/markWord.inline.hpp ! src/hotspot/share/oops/method.inline.hpp ! src/hotspot/share/oops/methodData.inline.hpp ! src/hotspot/share/oops/objArrayKlass.inline.hpp ! src/hotspot/share/oops/objArrayOop.inline.hpp ! src/hotspot/share/oops/oop.inline.hpp ! src/hotspot/share/oops/oopHandle.inline.hpp ! src/hotspot/share/oops/typeArrayKlass.inline.hpp ! src/hotspot/share/oops/typeArrayOop.inline.hpp ! src/hotspot/share/oops/weakHandle.inline.hpp ! src/hotspot/share/prims/foreign_globals.inline.hpp ! src/hotspot/share/prims/jvmtiEnter.inline.hpp ! src/hotspot/share/prims/jvmtiEventController.inline.hpp ! src/hotspot/share/prims/jvmtiThreadState.inline.hpp ! src/hotspot/share/prims/whitebox.inline.hpp ! src/hotspot/share/runtime/fieldDescriptor.inline.hpp ! src/hotspot/share/runtime/frame.inline.hpp ! src/hotspot/share/runtime/handles.inline.hpp ! src/hotspot/share/runtime/interfaceSupport.inline.hpp ! src/hotspot/share/runtime/jniHandles.inline.hpp ! src/hotspot/share/runtime/objectMonitor.inline.hpp ! src/hotspot/share/runtime/perfData.inline.hpp ! src/hotspot/share/runtime/prefetch.inline.hpp ! src/hotspot/share/runtime/safefetch.inline.hpp ! src/hotspot/share/runtime/safepointMechanism.inline.hpp ! src/hotspot/share/runtime/semaphore.inline.hpp ! src/hotspot/share/runtime/stackFrameStream.inline.hpp ! src/hotspot/share/runtime/stackWatermark.inline.hpp ! src/hotspot/share/runtime/stackWatermarkSet.inline.hpp ! src/hotspot/share/runtime/thread.inline.hpp ! src/hotspot/share/runtime/threadSMR.inline.hpp ! src/hotspot/share/runtime/threadWXSetters.inline.hpp ! src/hotspot/share/runtime/vframe.inline.hpp ! src/hotspot/share/services/mallocTracker.inline.hpp ! src/hotspot/share/utilities/bitMap.inline.hpp ! src/hotspot/share/utilities/concurrentHashTable.inline.hpp ! src/hotspot/share/utilities/concurrentHashTableTasks.inline.hpp ! src/hotspot/share/utilities/filterQueue.inline.hpp ! src/hotspot/share/utilities/globalCounter.inline.hpp ! src/hotspot/share/utilities/hashtable.inline.hpp ! src/hotspot/share/utilities/lockFreeQueue.inline.hpp ! src/hotspot/share/utilities/stack.inline.hpp Changeset: 2c8e94f6 Author: Jan Lahoda Date: 2021-05-31 09:25:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2c8e94f6804fee269a882a3e92b7ce844451eb11 8247403: JShell: No custom input (e.g. from GUI) possible with JavaShellToolBuilder Reviewed-by: vromero ! src/jdk.internal.le/share/classes/jdk/internal/org/jline/reader/impl/LineReaderImpl.java ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/ConsoleIOContext.java ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellTool.java ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellToolBuilder.java ! src/jdk.jshell/share/classes/jdk/jshell/tool/JavaShellToolBuilder.java + test/langtools/jdk/jshell/CustomInputToolBuilder.java ! test/langtools/jdk/jshell/HistoryUITest.java ! test/langtools/jdk/jshell/IndentUITest.java ! test/langtools/jdk/jshell/PasteAndMeasurementsUITest.java ! test/langtools/jdk/jshell/ToolMultilineSnippetHistoryTest.java ! test/langtools/jdk/jshell/ToolShiftTabTest.java ! test/langtools/jdk/jshell/ToolTabCommandTest.java ! test/langtools/jdk/jshell/ToolTabSnippetTest.java ! test/langtools/jdk/jshell/UITesting.java Changeset: 7ab6b401 Author: Wang Huang Committer: Nils Eliasson Date: 2021-05-31 09:40:18 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7ab6b4012026d4786a4c3937b559da9d3142a228 8267375: Aarch64: JVM crashes with option -XX:PrintIdealGraphLevel=3 on SVE backend Co-authored-by: Wang Huang Co-authored-by: Ai Jiaming Reviewed-by: aph, neliasso ! src/hotspot/share/opto/type.cpp + test/hotspot/jtreg/compiler/vectorapi/TestVectorInsertByte.java Changeset: bd31653e Author: Chris Hegarty Date: 2021-05-31 09:44:38 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bd31653e6f99d4337e4af1f7f138d688ec99c19d 8267938: (sctp) SCTP channel factory methods should check platform support Reviewed-by: dfuchs, jiefu, alanb, vtewari ! src/jdk.sctp/unix/native/libsctp/SctpNet.c Changeset: 4ade125c Author: Hamlin Li Date: 2021-05-31 11:17:19 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4ade125c8a53e0bdc105e5f65e8c1d7aa13db950 8267934: remove dead code in CLD Reviewed-by: stefank, tschatzl ! src/hotspot/share/classfile/classLoaderData.hpp Changeset: ce44cd68 Author: Stefan Johansson Date: 2021-05-31 12:08:24 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ce44cd6881bcbef81a840d7961a951ba586c0eae 8267845: Add @requires to avoid running G1 large pages test with wrong page size Reviewed-by: tschatzl, kbarrett ! test/hotspot/jtreg/gc/g1/TestLargePageUseForAuxMemory.java ! test/hotspot/jtreg/gc/g1/TestLargePageUseForHeap.java Changeset: 5df25dc0 Author: Stefan Johansson Date: 2021-05-31 12:51:21 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5df25dc088cfc3069e451b48c4f013d1d0491aa2 8266807: Windows os_windows-gtest broken for UseLargePages Reviewed-by: iwalulya, ayang, tschatzl ! test/hotspot/gtest/runtime/test_os_windows.cpp Changeset: 382e7eca Author: Hannes Walln?fer Date: 2021-05-31 14:27:54 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/382e7eca48a3e7ec4901aa4c9b4a4ee19f4accc2 8246351: elements in headings are of incorrect size Reviewed-by: prappo ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css Changeset: c06db45f Author: Sergey Tsypanov Committer: Mandy Chung Date: 2021-05-31 16:58:38 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c06db45fa77c8a90518d6ff023de6c46b7c89997 8267921: Remove redundant loop from sun.reflect.misc.ReflectUtil.privateCheckPackageAccess() Reviewed-by: alanb, mchung ! src/java.base/share/classes/sun/reflect/misc/ReflectUtil.java Changeset: ae2f37f8 Author: Dong Bo Committer: Fei Yang Date: 2021-06-01 00:37:28 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ae2f37f868bfdcb3d46098e91ed537fb199d7dbe 8267616: AArch64: Fix AES assertion messages in stubGenerator_aarch64.cpp Reviewed-by: aph, neliasso ! src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp Changeset: f5634fe3 Author: Vladimir Ivanov Date: 2021-06-01 09:15:46 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f5634fe39db44d5d504e1b2f8aba1bca3e479a89 8267979: C2: Fix verification code in SubTypeCheckNode::Ideal() Reviewed-by: neliasso, roland ! src/hotspot/share/opto/subtypenode.cpp ! src/hotspot/share/opto/subtypenode.hpp Changeset: 4eb21682 Author: Patrick Concannon Date: 2021-06-01 10:14:56 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4eb216824f39e3c3536972d76d778466c140df50 8267670: Update java.io, java.math, and java.text to use switch expressions Reviewed-by: darcy, chegar, naoto, iris, dfuchs, lancea, vtewari ! src/java.base/share/classes/java/io/DataInputStream.java ! src/java.base/share/classes/java/io/ObjectInputStream.java ! src/java.base/share/classes/java/io/ObjectStreamClass.java ! src/java.base/share/classes/java/io/ObjectStreamField.java ! src/java.base/share/classes/java/io/StreamTokenizer.java ! src/java.base/share/classes/java/math/BigDecimal.java ! src/java.base/share/classes/java/math/BigInteger.java ! src/java.base/share/classes/java/math/RoundingMode.java ! src/java.base/share/classes/java/text/BreakIterator.java ! src/java.base/share/classes/java/text/NumberFormat.java ! src/java.base/share/classes/java/text/PatternEntry.java Changeset: 6149b9ad Author: Stefan Karlsson Date: 2021-06-01 10:23:13 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6149b9ad7569ce1711201353fd644b6a739d5a5b 8267914: Remove DeferredObjectToKlass workaround Reviewed-by: eosterlund, tschatzl ! src/hotspot/share/oops/markWord.hpp ! src/hotspot/share/oops/markWord.inline.hpp ! src/hotspot/share/oops/oop.inline.hpp Changeset: 229a6e2f Author: Vladimir Ivanov Date: 2021-06-01 11:09:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/229a6e2f3646bfb52708e4f865bd55a838b8222d 8267095: Miscellaneous cleanups in vm.runtime.defmeth tests Reviewed-by: dholmes, hseigel ! test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/AccessibilityFlagsTest.java ! test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/BasicTest.java ! test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/ConflictingDefaultsTest.java ! test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/DefaultVsAbstractTest.java ! test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/MethodResolutionTest.java ! test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/ObjectMethodOverridesTest.java ! test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/PrivateMethodsTest.java ! test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/README ! test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/RedefineTest.java ! test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/StaticMethodsTest.java ! test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/StressTest.java ! test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/SuperCallTest.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/AccessibilityFlags_v52_none_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/AccessibilityFlags_v52_none_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/AccessibilityFlags_v52_none_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/AccessibilityFlags_v52_none_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/AccessibilityFlags_v52_none_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/AccessibilityFlags_v52_none_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/AccessibilityFlags_v52_strict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/AccessibilityFlags_v52_strict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/AccessibilityFlags_v52_strict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/AccessibilityFlags_v52_strict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/AccessibilityFlags_v52_strict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/AccessibilityFlags_v52_strict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/AccessibilityFlags_v52_sync_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/AccessibilityFlags_v52_sync_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/AccessibilityFlags_v52_sync_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/AccessibilityFlags_v52_sync_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/AccessibilityFlags_v52_sync_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/AccessibilityFlags_v52_sync_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/AccessibilityFlags_v52_syncstrict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/AccessibilityFlags_v52_syncstrict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/AccessibilityFlags_v52_syncstrict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/AccessibilityFlags_v52_syncstrict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/AccessibilityFlags_v52_syncstrict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/AccessibilityFlags_v52_syncstrict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v49_none_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v49_none_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v49_none_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v49_none_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v49_none_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v49_none_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v49_strict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v49_strict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v49_strict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v49_strict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v49_strict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v49_strict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v49_sync_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v49_sync_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v49_sync_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v49_sync_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v49_sync_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v49_sync_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v49_syncstrict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v49_syncstrict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v49_syncstrict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v49_syncstrict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v49_syncstrict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v49_syncstrict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v52_none_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v52_none_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v52_none_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v52_none_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v52_none_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v52_none_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v52_strict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v52_strict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v52_strict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v52_strict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v52_strict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v52_strict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v52_sync_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v52_sync_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v52_sync_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v52_sync_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v52_sync_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v52_sync_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v52_syncstrict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v52_syncstrict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v52_syncstrict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v52_syncstrict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v52_syncstrict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v52_syncstrict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v49_none_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v49_none_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v49_none_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v49_none_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v49_none_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v49_none_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v49_strict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v49_strict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v49_strict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v49_strict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v49_strict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v49_strict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v49_sync_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v49_sync_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v49_sync_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v49_sync_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v49_sync_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v49_sync_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v49_syncstrict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v49_syncstrict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v49_syncstrict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v49_syncstrict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v49_syncstrict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v49_syncstrict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v52_none_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v52_none_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v52_none_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v52_none_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v52_none_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v52_none_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v52_strict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v52_strict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v52_strict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v52_strict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v52_strict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v52_strict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v52_sync_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v52_sync_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v52_sync_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v52_sync_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v52_sync_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v52_sync_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v52_syncstrict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v52_syncstrict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v52_syncstrict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v52_syncstrict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v52_syncstrict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v52_syncstrict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v49_none_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v49_none_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v49_none_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v49_none_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v49_none_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v49_none_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v49_strict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v49_strict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v49_strict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v49_strict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v49_strict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v49_strict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v49_sync_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v49_sync_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v49_sync_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v49_sync_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v49_sync_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v49_sync_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v49_syncstrict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v49_syncstrict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v49_syncstrict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v49_syncstrict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v49_syncstrict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v49_syncstrict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v52_none_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v52_none_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v52_none_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v52_none_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v52_none_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v52_none_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v52_strict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v52_strict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v52_strict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v52_strict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v52_strict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v52_strict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v52_sync_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v52_sync_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v52_sync_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v52_sync_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v52_sync_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v52_sync_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v52_syncstrict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v52_syncstrict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v52_syncstrict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v52_syncstrict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v52_syncstrict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v52_syncstrict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v49_none_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v49_none_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v49_none_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v49_none_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v49_none_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v49_none_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v49_strict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v49_strict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v49_strict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v49_strict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v49_strict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v49_strict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v49_sync_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v49_sync_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v49_sync_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v49_sync_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v49_sync_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v49_sync_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v49_syncstrict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v49_syncstrict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v49_syncstrict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v49_syncstrict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v49_syncstrict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v49_syncstrict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v52_none_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v52_none_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v52_none_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v52_none_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v52_none_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v52_none_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v52_strict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v52_strict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v52_strict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v52_strict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v52_strict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v52_strict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v52_sync_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v52_sync_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v52_sync_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v52_sync_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v52_sync_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v52_sync_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v52_syncstrict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v52_syncstrict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v52_syncstrict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v52_syncstrict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v52_syncstrict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v52_syncstrict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ObjectMethodOverrides_v52_none_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ObjectMethodOverrides_v52_none_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ObjectMethodOverrides_v52_none_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ObjectMethodOverrides_v52_none_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ObjectMethodOverrides_v52_none_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ObjectMethodOverrides_v52_none_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v49_none_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v49_none_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v49_none_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v49_none_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v49_none_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v49_none_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v49_strict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v49_strict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v49_strict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v49_strict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v49_strict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v49_strict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v49_sync_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v49_sync_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v49_sync_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v49_sync_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v49_sync_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v49_sync_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v49_syncstrict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v49_syncstrict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v49_syncstrict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v49_syncstrict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v49_syncstrict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v49_syncstrict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v52_none_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v52_none_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v52_none_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v52_none_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v52_none_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v52_none_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v52_strict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v52_strict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v52_strict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v52_strict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v52_strict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v52_strict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v52_sync_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v52_sync_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v52_sync_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v52_sync_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v52_sync_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v52_sync_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v52_syncstrict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v52_syncstrict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v52_syncstrict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v52_syncstrict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v52_syncstrict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v52_syncstrict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v49_none_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v49_none_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v49_none_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v49_none_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v49_strict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v49_strict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v49_strict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v49_strict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v49_sync_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v49_sync_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v49_sync_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v49_sync_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v49_syncstrict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v49_syncstrict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v49_syncstrict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v49_syncstrict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v52_none_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v52_none_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v52_none_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v52_none_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v52_strict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v52_strict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v52_strict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v52_strict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v52_sync_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v52_sync_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v52_sync_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v52_sync_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v52_syncstrict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v52_syncstrict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v52_syncstrict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v52_syncstrict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v49_none_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v49_none_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v49_none_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v49_none_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v49_none_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v49_none_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v49_strict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v49_strict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v49_strict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v49_strict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v49_strict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v49_strict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v49_sync_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v49_sync_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v49_sync_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v49_sync_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v49_sync_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v49_sync_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v49_syncstrict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v49_syncstrict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v49_syncstrict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v49_syncstrict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v49_syncstrict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v49_syncstrict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v52_none_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v52_none_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v52_none_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v52_none_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v52_none_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v52_none_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v52_strict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v52_strict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v52_strict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v52_strict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v52_strict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v52_strict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v52_sync_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v52_sync_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v52_sync_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v52_sync_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v52_sync_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v52_sync_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v52_syncstrict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v52_syncstrict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v52_syncstrict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v52_syncstrict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v52_syncstrict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v52_syncstrict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Stress_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Stress_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/SuperCall_v52_none_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/SuperCall_v52_none_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/SuperCall_v52_none_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/SuperCall_v52_none_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/SuperCall_v52_none_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/SuperCall_v52_none_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/SuperCall_v52_strict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/SuperCall_v52_strict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/SuperCall_v52_strict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/SuperCall_v52_strict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/SuperCall_v52_strict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/SuperCall_v52_strict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/SuperCall_v52_sync_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/SuperCall_v52_sync_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/SuperCall_v52_sync_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/SuperCall_v52_sync_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/SuperCall_v52_sync_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/SuperCall_v52_sync_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/SuperCall_v52_syncstrict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/SuperCall_v52_syncstrict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/SuperCall_v52_syncstrict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/SuperCall_v52_syncstrict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/SuperCall_v52_syncstrict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/SuperCall_v52_syncstrict_reflect_redefine/TestDescription.java ! test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/shared/DefMethTest.java ! test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/shared/Printer.java ! test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/shared/Util.java ! test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/shared/builder/MethodBuilder.java ! test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/shared/builder/TestBuilder.java ! test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/shared/builder/TesterBuilder.java Changeset: ffd28c4a Author: Vladimir Ivanov Date: 2021-06-01 11:59:28 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ffd28c4a86aa8e8e59afb13abd4aeeea66557f66 8267947: CI: Preserve consistency between has_subklass() and is_subclass_of() Reviewed-by: thartmann, roland ! src/hotspot/share/ci/ciInstanceKlass.hpp ! src/hotspot/share/ci/ciKlass.cpp Changeset: 1c7c0e1d Author: Thomas Schatzl Date: 2021-06-01 12:02:25 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1c7c0e1de0c69f5c6082c3217b0baa33c0fbb0a8 8267937: Wrong indentation in G1 gc+phases log for free cset subphases Reviewed-by: ayang, sjohanss ! src/hotspot/share/gc/g1/g1GCPhaseTimes.cpp Changeset: 68f3b3ac Author: Vladimir Ivanov Date: 2021-06-01 12:03:34 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/68f3b3acce0393aa9c91878f7ad848d4a41a2fe1 8267807: C2: Downcast receiver to target holder during inlining Reviewed-by: roland, thartmann ! src/hotspot/share/opto/doCall.cpp ! src/hotspot/share/opto/parse1.cpp Changeset: 20479c3d Author: Vladimir Ivanov Date: 2021-06-01 12:06:57 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/20479c3de93736d62bca97c4fe422a19ad87d52a 8065760: CHA: Improve abstract method support Reviewed-by: neliasso, thartmann ! src/hotspot/share/ci/ciMethod.cpp ! src/hotspot/share/ci/ciMethod.hpp ! src/hotspot/share/code/dependencies.cpp + test/hotspot/jtreg/compiler/cha/AbstractRootMethod.java ! test/hotspot/jtreg/compiler/cha/StrengthReduceInterfaceCall.java + test/hotspot/jtreg/compiler/cha/Utils.java Changeset: 74b70a56 Author: Vladimir Ivanov Date: 2021-06-01 12:14:48 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/74b70a56774e7bf716356cf38395f8e7d7dadc78 8036580: CHA: improve default method support Reviewed-by: thartmann, neliasso ! src/hotspot/share/c1/c1_GraphBuilder.cpp ! src/hotspot/share/ci/ciMethod.cpp ! src/hotspot/share/code/dependencies.cpp ! src/hotspot/share/opto/doCall.cpp + test/hotspot/jtreg/compiler/cha/DefaultRootMethod.java ! test/hotspot/jtreg/compiler/cha/StrengthReduceInterfaceCall.java Changeset: 36dc268a Author: Daniel D. Daugherty Date: 2021-06-01 15:30:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/36dc268abea2522596efe830365ba4bbe6e2696c 8268036: ProblemList gtest/AsyncLogGtest.java 8268041: ProblemList runtime/cds/appcds/dynamicArchive/TestDynamicDumpAtOom.java on linux-x64 in -Xcomp Reviewed-by: ccheung ! test/hotspot/jtreg/ProblemList-Xcomp.txt ! test/hotspot/jtreg/ProblemList.txt Changeset: 9d8ad2ed Author: Daniel Fuchs Date: 2021-06-01 17:10:38 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9d8ad2ed62325bd8d813974d5aa1e031ed8bf8da 8267990: Revisit some uses of `synchronized` in the HttpClient API Reviewed-by: chegar ! src/java.net.http/share/classes/jdk/internal/net/http/Http1AsyncReceiver.java ! src/java.net.http/share/classes/jdk/internal/net/http/Http1Exchange.java ! src/java.net.http/share/classes/jdk/internal/net/http/Http2Connection.java ! src/java.net.http/share/classes/jdk/internal/net/http/LineSubscriberAdapter.java ! src/java.net.http/share/classes/jdk/internal/net/http/RequestPublishers.java ! src/java.net.http/share/classes/jdk/internal/net/http/SocketTube.java ! src/java.net.http/share/classes/jdk/internal/net/http/Stream.java ! src/java.net.http/share/classes/jdk/internal/net/http/common/SSLFlowDelegate.java ! src/java.net.http/share/classes/jdk/internal/net/http/common/SequentialScheduler.java ! src/java.net.http/share/classes/jdk/internal/net/http/common/SubscriberWrapper.java ! src/java.net.http/share/classes/jdk/internal/net/http/common/Utils.java ! test/jdk/java/net/httpclient/LineBodyHandlerTest.java ! test/jdk/java/net/httpclient/whitebox/java.net.http/jdk/internal/net/http/SSLEchoTubeTest.java Changeset: d4b4caec Author: Daniel Fuchs Date: 2021-06-01 17:55:36 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d4b4caecad58998f8855a64436b1ebd47f7e7bfb 8268023: Improve diagnostic for HandshakeFailureTest Reviewed-by: chegar ! src/java.net.http/share/classes/jdk/internal/net/http/Http2Connection.java ! test/jdk/java/net/httpclient/HandshakeFailureTest.java Changeset: 64ba2f0e Author: Maxim Kartashev Committer: Erik Joelsson Date: 2021-06-01 17:56:44 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/64ba2f0e8f38a92edf8a301f43b3a0d4e239e1b2 8265431: Add -fno-delete-null-pointer-checks to clang builds Reviewed-by: erikj ! make/autoconf/flags-cflags.m4 Changeset: 2b338355 Author: Leonid Mesnik Date: 2021-06-01 18:06:19 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2b3383557f71ede15d00bd87742a277c0c764d20 8265148: StackWatermarkSet being updated during AsyncGetCallTrace Reviewed-by: stefank, eosterlund ! src/hotspot/share/prims/forte.cpp Changeset: b17b11eb Author: Jiangli Zhou Date: 2021-06-01 18:17:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b17b11eb178d7aab84517771e5afc03b40095cd0 8267562: G1: Missing BOT in Open Archive regions causes long pauses Reviewed-by: tschatzl, mli ! src/hotspot/share/cds/filemap.cpp ! src/hotspot/share/gc/g1/g1BlockOffsetTable.cpp ! src/hotspot/share/gc/g1/g1BlockOffsetTable.hpp ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1CollectedHeap.hpp ! src/hotspot/share/gc/g1/g1FullGCPrepareTask.cpp ! src/hotspot/share/gc/g1/g1FullGCPrepareTask.hpp ! src/hotspot/share/gc/g1/heapRegion.hpp Changeset: 40e4171f Author: Daniel D. Daugherty Date: 2021-06-01 18:51:40 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/40e4171f562da2f6a507efc7ad359e298199ed71 8264800: cleanup Threads_lock comments in JVM/TI function headers Reviewed-by: coleenp, rehn, dholmes, sspitsyn ! src/hotspot/share/prims/jvmtiEnv.cpp ! src/hotspot/share/prims/jvmtiEnv.xsl ! src/hotspot/share/prims/jvmtiEnvBase.cpp Changeset: ccfcd926 Author: Fernando Guallini Committer: Xue-Lei Andrew Fan Date: 2021-06-01 19:09:42 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ccfcd926674ee0bd88f34b16b489abe008169b11 8180571: Refactor sun/security/pkcs11 shell tests to plain java tests and fix failures Reviewed-by: xuelei ! test/jdk/ProblemList.txt ! test/jdk/sun/security/pkcs11/Config/ReadConfInUTF16Env.java - test/jdk/sun/security/pkcs11/Config/ReadConfInUTF16Env.sh ! test/jdk/sun/security/pkcs11/KeyStore/Basic.java - test/jdk/sun/security/pkcs11/KeyStore/Basic.sh ! test/jdk/sun/security/pkcs11/KeyStore/ClientAuth.java - test/jdk/sun/security/pkcs11/KeyStore/ClientAuth.sh ! test/jdk/sun/security/pkcs11/KeyStore/ClientAuthData/cert8.db ! test/jdk/sun/security/pkcs11/KeyStore/ClientAuthData/key3.db ! test/jdk/sun/security/pkcs11/KeyStore/ClientAuthData/secmod.db ! test/jdk/sun/security/pkcs11/KeyStore/ClientAuthData/truststore ! test/jdk/sun/security/pkcs11/KeyStore/SecretKeysBasic.java - test/jdk/sun/security/pkcs11/KeyStore/SecretKeysBasic.sh ! test/jdk/sun/security/pkcs11/PKCS11Test.java ! test/jdk/sun/security/pkcs11/Provider/ConfigQuotedString.java - test/jdk/sun/security/pkcs11/Provider/ConfigQuotedString.sh ! test/jdk/sun/security/pkcs11/Provider/Login.java - test/jdk/sun/security/pkcs11/Provider/Login.sh Changeset: c2c0208d Author: Yi Yang Committer: Ioi Lam Date: 2021-06-01 19:56:57 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c2c0208dfd986eef19a65727e875b023fb595436 8267089: Use typedef KVHashtable for ID2KlassTable Reviewed-by: iklam, coleenp ! src/hotspot/share/cds/classListParser.cpp ! src/hotspot/share/cds/classListParser.hpp Changeset: 0ae4ceb4 Author: Joe Darcy Date: 2021-06-01 21:59:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0ae4ceb413a7ea92a41cd55cd338f866098eb9b4 8244146: javac changes for JEP 306 8266399: Core libs update for JEP 306 Reviewed-by: sadayapalam, bpb, naoto ! src/java.base/share/classes/java/lang/FdLibm.java ! src/java.base/share/classes/java/lang/StrictMath.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ConstFold.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Target.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties ! src/jdk.jshell/share/classes/jdk/jshell/TaskFactory.java ! test/jdk/java/lang/reflect/Method/GenericStringTest.java ! test/langtools/tools/javac/7166455/CheckACC_STRICTFlagOnclinitTest.java ! test/langtools/tools/javac/8005931/CheckACC_STRICTFlagOnPkgAccessClassTest.java ! test/langtools/tools/javac/FloatingPointChanges/BadConstructorModifiers.java ! test/langtools/tools/javac/FloatingPointChanges/BadConstructorModifiers.out ! test/langtools/tools/javac/T6397044.java ! test/langtools/tools/javac/annotations/AnnotationTypeElementModifiers.java ! test/langtools/tools/javac/annotations/AnnotationTypeElementModifiers.out ! test/langtools/tools/javac/annotations/typeAnnotations/classfile/NestedLambdasCastedTest.java ! test/langtools/tools/javac/defaultMethods/CheckACC_STRICTFlagOnDefaultMethodTest.java + test/langtools/tools/javac/diags/examples/UnneededStrictfpWarning.java ! test/langtools/tools/javac/lambda/LambdaTestStrictFPFlag.java + test/langtools/tools/javac/processing/model/element/ObsoleteStrictfp/StrictfpHost.java + test/langtools/tools/javac/processing/model/element/ObsoleteStrictfp/StrictfpInSource.java + test/langtools/tools/javac/processing/model/element/ObsoleteStrictfp/TestStrictfpRetention.java ! test/langtools/tools/javac/processing/model/element/TestExecutableElement.java + test/langtools/tools/javac/warnings/UnneededStrictfpWarningToolBox.java Changeset: 8624cb53 Author: Joe Darcy Date: 2021-06-01 22:00:48 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8624cb53cdf34555ca76ed8ea89878b6e54cd769 8266530: HotSpot changes for JEP 306 Reviewed-by: dholmes, hseigel ! src/hotspot/share/classfile/classFileParser.cpp + test/hotspot/jtreg/runtime/strictfp/AbstractStrictfpIntMethod60.jcod + test/hotspot/jtreg/runtime/strictfp/AbstractStrictfpIntMethod61.jcod + test/hotspot/jtreg/runtime/strictfp/AbstractStrictfpMethod60.jcod + test/hotspot/jtreg/runtime/strictfp/AbstractStrictfpMethod61.jcod + test/hotspot/jtreg/runtime/strictfp/StrictfpModifierChecksTest.java Changeset: cb7128b5 Author: David Holmes Date: 2021-06-01 22:04:02 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/cb7128b58e02fa0a8dd69e9a9bdd587aa8052d73 8266950: Remove vestigial support for non-strict floating-point execution Co-authored-by: Vladimir Ivanov Reviewed-by: vlivanov, kvn ! src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/c1_LIRGenerator_aarch64.cpp ! src/hotspot/cpu/arm/c1_LIRAssembler_arm.cpp ! src/hotspot/cpu/arm/c1_LIRGenerator_arm.cpp ! src/hotspot/cpu/ppc/c1_LIRAssembler_ppc.cpp ! src/hotspot/cpu/ppc/c1_LIRGenerator_ppc.cpp ! src/hotspot/cpu/s390/c1_LIRAssembler_s390.cpp ! src/hotspot/cpu/s390/c1_LIRGenerator_s390.cpp ! src/hotspot/cpu/x86/c1_LIRAssembler_x86.cpp ! src/hotspot/cpu/x86/c1_LIRGenerator_x86.cpp ! src/hotspot/cpu/x86/c1_LinearScan_x86.cpp ! src/hotspot/cpu/x86/stubGenerator_x86_32.cpp ! src/hotspot/cpu/x86/stubGenerator_x86_64.cpp ! src/hotspot/cpu/x86/stubRoutines_x86.hpp ! src/hotspot/cpu/x86/stubRoutines_x86_32.cpp ! src/hotspot/cpu/x86/templateTable_x86.cpp ! src/hotspot/cpu/x86/x86_32.ad ! src/hotspot/share/c1/c1_GraphBuilder.cpp ! src/hotspot/share/c1/c1_Instruction.cpp ! src/hotspot/share/c1/c1_Instruction.hpp ! src/hotspot/share/c1/c1_LIR.cpp ! src/hotspot/share/c1/c1_LIR.hpp ! src/hotspot/share/c1/c1_LIRAssembler.cpp ! src/hotspot/share/c1/c1_LIRGenerator.cpp ! src/hotspot/share/c1/c1_LIRGenerator.hpp ! src/hotspot/share/c1/c1_LinearScan.cpp ! src/hotspot/share/c1/c1_RangeCheckElimination.cpp ! src/hotspot/share/ci/ciFlags.cpp ! src/hotspot/share/ci/ciFlags.hpp ! src/hotspot/share/ci/ciMethod.hpp ! src/hotspot/share/oops/method.hpp ! src/hotspot/share/opto/addnode.cpp ! src/hotspot/share/opto/c2_globals.hpp ! src/hotspot/share/opto/divnode.cpp ! src/hotspot/share/opto/doCall.cpp ! src/hotspot/share/opto/graphKit.cpp ! src/hotspot/share/opto/graphKit.hpp ! src/hotspot/share/opto/mulnode.cpp ! src/hotspot/share/opto/subnode.cpp ! src/hotspot/share/runtime/stubRoutines.cpp ! src/hotspot/share/runtime/stubRoutines.hpp ! src/hotspot/share/utilities/accessFlags.cpp ! src/hotspot/share/utilities/accessFlags.hpp Changeset: 00c7aeee Author: Joe Darcy Date: 2021-06-02 00:33:17 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/00c7aeee005f08689d0647b460eb55b6a5385f72 8267861: Update SourceVersion with new language features in 16 and 17 Reviewed-by: jjg ! src/java.compiler/share/classes/javax/lang/model/SourceVersion.java Changeset: 379376f0 Author: Gavin Bierman Committer: Vicente Romero Date: 2021-06-02 00:49:49 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/379376f0783facba93e1d11db9b184ef8183a13b 8265130: Make ConstantDesc class hierarchy sealed Reviewed-by: mchung, jvernee, vromero ! src/java.base/share/classes/java/lang/constant/ClassDesc.java ! src/java.base/share/classes/java/lang/constant/ConstantDesc.java ! src/java.base/share/classes/java/lang/constant/DirectMethodHandleDesc.java ! src/java.base/share/classes/java/lang/constant/DynamicConstantDesc.java ! src/java.base/share/classes/java/lang/constant/MethodHandleDesc.java ! src/java.base/share/classes/java/lang/constant/MethodTypeDesc.java Changeset: b98e52a4 Author: Guoxiong Li Committer: Vicente Romero Date: 2021-06-02 04:25:46 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b98e52a49191cfbb7d954646cd80a6711daeaca6 8267570: The comment of the class JavacParser is not appropriate Reviewed-by: jjg ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java Changeset: 7530c00b Author: Joe Wang Date: 2021-06-02 04:57:30 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7530c00b33aac8918841dbae4d928956b60c261f 8266559: XPathEvaluationResult.XPathResultType.NODESET maps to incorrect type Reviewed-by: lancea, naoto ! src/java.xml/share/classes/javax/xml/xpath/XPath.java ! src/java.xml/share/classes/javax/xml/xpath/XPathEvaluationResult.java ! src/java.xml/share/classes/javax/xml/xpath/XPathExpression.java ! src/java.xml/share/classes/javax/xml/xpath/package-info.java Changeset: 1cea6cac Author: Koichi Sakata Committer: Christian Hagedorn Date: 2021-06-02 07:13:00 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1cea6cac121f9688c27d8a59563023de2379e22d 8260360: IGV: Short name of combined nodes is hidden by background color Reviewed-by: neliasso, chagedorn ! src/utils/IdealGraphVisualizer/Filter/src/main/java/com/sun/hotspot/igv/filter/CombineFilter.java Changeset: 496fb90b Author: Xiaohong Gong Committer: Nils Eliasson Date: 2021-06-02 07:50:46 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/496fb90b3a038f5fe76acc8a98bcd0dac4071cf9 8267969: Add vectorized implementation for VectorMask.eq() Reviewed-by: psandoz, neliasso ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractMask.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/DoubleMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/FloatMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/IntMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/LongMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ShortMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-VectorBits.java.template Changeset: d47a77d2 Author: Nils Eliasson Date: 2021-06-02 07:57:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d47a77d2d54ee8c41ef969b42b3336a646dffd7b 8267773: PhaseStringOpts::int_stringSize doesn't handle min_jint correctly Co-authored-by: Adam Farley Co-authored-by: Aleksey Shipilev Co-authored-by: Nils Eliasson Reviewed-by: roland ! src/hotspot/share/opto/stringopts.cpp + test/jdk/java/lang/String/concat/IntegerMinValue.java Changeset: bba3728e Author: Nils Eliasson Date: 2021-06-02 09:02:37 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bba3728e238855d509b38a021691b677fb904241 8267726: ZGC: array_copy_requires_gc_barriers too strict Reviewed-by: thartmann, vlivanov ! src/hotspot/share/gc/shared/c2/barrierSetC2.hpp ! src/hotspot/share/gc/shared/c2/cardTableBarrierSetC2.cpp ! src/hotspot/share/gc/shared/c2/cardTableBarrierSetC2.hpp ! src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.cpp ! src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.hpp ! src/hotspot/share/gc/z/c2/zBarrierSetC2.cpp ! src/hotspot/share/gc/z/c2/zBarrierSetC2.hpp ! src/hotspot/share/opto/arraycopynode.cpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/opto/macroArrayCopy.cpp Changeset: 2d494bff Author: Thomas Schatzl Date: 2021-06-02 09:31:59 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2d494bffffd532be0b5d2c17495d705f925932e7 8267836: Separate eager reclaim remembered set threshold from G1RSetSparseRegionEntries Reviewed-by: sjohanss, lkorinth ! src/hotspot/share/gc/g1/g1Arguments.cpp ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1RemSet.cpp ! src/hotspot/share/gc/g1/g1_globals.hpp Changeset: 9247630a Author: Jan Lahoda Date: 2021-06-02 09:53:31 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9247630a0d024550813f651c1ec0ce228ff27210 8265270: Type.getEnclosingType() may fail with CompletionFailure Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! test/langtools/tools/javac/processing/model/completionfailure/MissingClassFile.java Changeset: de6472c4 Author: Jan Lahoda Date: 2021-06-02 09:55:06 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/de6472c44166e57cd440b7bffcfc876585aca7dd 8267459: Pasting Unicode characters into JShell does not work. Reviewed-by: vromero ! src/jdk.internal.le/share/classes/jdk/internal/org/jline/utils/NonBlocking.java ! test/langtools/jdk/jshell/PasteAndMeasurementsUITest.java ! test/langtools/jdk/jshell/UITesting.java Changeset: 71425ddf Author: David Holmes Date: 2021-06-02 10:42:17 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/71425ddfb4a7cc9e2d1c7c12cfac61c4d9d7fdf4 8267118: OutOfMemoryError cannot be caught as a Throwable Co-authored-by: Ioi Lam Reviewed-by: coleenp ! src/hotspot/share/classfile/verifier.cpp ! src/hotspot/share/oops/method.cpp + test/hotspot/jtreg/runtime/Throwable/TestCatchThrowableOOM.java Changeset: a223189b Author: Maurizio Cimadamore Date: 2021-06-02 10:53:06 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a223189b069a7cfe49511d49b5b09e7107cb3cab 8264774: Implementation of Foreign Function and Memory API (Incubator) Co-authored-by: Paul Sandoz Co-authored-by: Jorn Vernee Co-authored-by: Vladimir Ivanov Co-authored-by: Athijegannathan Sundararajan Co-authored-by: Chris Hegarty Reviewed-by: psandoz, chegar, mchung, vlivanov ! src/hotspot/cpu/aarch64/foreign_globals_aarch64.cpp ! src/hotspot/cpu/aarch64/frame_aarch64.cpp ! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp ! src/hotspot/cpu/aarch64/universalUpcallHandler_aarch64.cpp ! src/hotspot/cpu/x86/foreign_globals_x86.cpp ! src/hotspot/cpu/x86/frame_x86.cpp ! src/hotspot/cpu/x86/javaFrameAnchor_x86.hpp ! src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp ! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp ! src/hotspot/cpu/x86/universalUpcallHandler_x86_32.cpp ! src/hotspot/cpu/x86/universalUpcallHandler_x86_64.cpp ! src/hotspot/share/ci/ciNativeEntryPoint.cpp ! src/hotspot/share/ci/ciNativeEntryPoint.hpp ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/classfile/javaClasses.hpp ! src/hotspot/share/classfile/vmSymbols.hpp ! src/hotspot/share/code/codeBlob.cpp ! src/hotspot/share/code/codeBlob.hpp ! src/hotspot/share/logging/logTag.hpp ! src/hotspot/share/opto/callGenerator.cpp ! src/hotspot/share/opto/callnode.cpp ! src/hotspot/share/opto/graphKit.cpp ! src/hotspot/share/opto/graphKit.hpp ! src/hotspot/share/opto/lcm.cpp ! src/hotspot/share/prims/foreign_globals.cpp ! src/hotspot/share/prims/foreign_globals.hpp ! src/hotspot/share/prims/nativeEntryPoint.cpp ! src/hotspot/share/prims/universalNativeInvoker.cpp ! src/hotspot/share/prims/universalUpcallHandler.cpp ! src/hotspot/share/prims/universalUpcallHandler.hpp ! src/hotspot/share/prims/upcallStubs.cpp ! src/hotspot/share/prims/whitebox.cpp ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/frame.cpp ! src/hotspot/share/runtime/frame.hpp ! src/hotspot/share/runtime/frame.inline.hpp ! src/hotspot/share/runtime/globals.hpp ! src/hotspot/share/runtime/reflection.cpp ! src/hotspot/share/runtime/sharedRuntime.cpp ! src/hotspot/share/runtime/sharedRuntime.hpp ! src/java.base/share/classes/java/lang/Module.java ! src/java.base/share/classes/java/lang/System.java ! src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/java.base/share/classes/java/lang/invoke/NativeMethodHandle.java ! src/java.base/share/classes/java/nio/Buffer.java ! src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java ! src/java.base/share/classes/jdk/internal/access/JavaLangInvokeAccess.java ! src/java.base/share/classes/jdk/internal/access/JavaNioAccess.java ! src/java.base/share/classes/jdk/internal/invoke/NativeEntryPoint.java ! src/java.base/share/classes/jdk/internal/loader/BootLoader.java ! src/java.base/share/classes/jdk/internal/misc/X-ScopedMemoryAccess.java.template ! src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java ! src/java.base/share/classes/jdk/internal/reflect/Reflection.java ! src/java.base/share/classes/module-info.java ! src/java.base/share/classes/sun/launcher/resources/launcher.properties ! src/java.base/share/classes/sun/nio/ch/IOUtil.java ! src/java.base/share/native/libjli/java.c ! src/java.base/unix/classes/sun/nio/ch/UnixAsynchronousSocketChannelImpl.java ! src/java.base/windows/classes/sun/nio/ch/WindowsAsynchronousSocketChannelImpl.java ! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/AbstractLayout.java ! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/Addressable.java ! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java ! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/GroupLayout.java ! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/LibraryLookup.java - src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MappedMemorySegments.java ! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemoryAddress.java ! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemoryHandles.java ! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemoryLayout.java ! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemoryLayouts.java ! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemorySegment.java - src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/NativeScope.java + src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/ResourceScope.java + src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/SegmentAllocator.java ! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/SequenceLayout.java ! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/package-info.java + src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/AbstractCLinker.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java - src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/AbstractNativeScope.java + src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/ArenaAllocator.java + src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/ConfinedScope.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/HeapMemorySegmentImpl.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/LayoutPath.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/LibrariesHelper.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/MappedMemorySegmentImpl.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/MemoryAddressImpl.java - src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/MemoryScope.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/NativeMemorySegmentImpl.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/PlatformLayouts.java + src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/ResourceScopeImpl.java + src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/SharedScope.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/Utils.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/Binding.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/BindingInterpreter.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/BufferLayout.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/ProgrammableInvoker.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/ProgrammableUpcallHandler.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/SharedUtils.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/UpcallStubs.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/aarch64/AArch64Linker.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/aarch64/AArch64VaList.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/aarch64/CallArranger.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/x64/sysv/CallArranger.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/x64/sysv/SysVVaList.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/x64/sysv/SysVx64Linker.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/x64/windows/CallArranger.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/x64/windows/WinVaList.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/x64/windows/Windowsx64Linker.java ! test/hotspot/jtreg/gc/shenandoah/compiler/TestLinkToNativeRBP.java ! test/jdk/TEST.groups ! test/jdk/java/foreign/CallGeneratorHelper.java ! test/jdk/java/foreign/NativeTestHelper.java + test/jdk/java/foreign/SafeFunctionAccessTest.java ! test/jdk/java/foreign/StdLibTest.java ! test/jdk/java/foreign/TestAdaptVarHandles.java ! test/jdk/java/foreign/TestAddressHandle.java ! test/jdk/java/foreign/TestArrays.java ! test/jdk/java/foreign/TestByteBuffer.java - test/jdk/java/foreign/TestCleaner.java ! test/jdk/java/foreign/TestCondy.java ! test/jdk/java/foreign/TestDowncall.java ! test/jdk/java/foreign/TestFree.java ! test/jdk/java/foreign/TestHandshake.java ! test/jdk/java/foreign/TestIllegalLink.java ! test/jdk/java/foreign/TestIntrinsics.java ! test/jdk/java/foreign/TestLayoutConstants.java ! test/jdk/java/foreign/TestLayoutEquality.java ! test/jdk/java/foreign/TestLayoutPaths.java ! test/jdk/java/foreign/TestLayouts.java ! test/jdk/java/foreign/TestLibraryLookup.java + test/jdk/java/foreign/TestMatrix.java ! test/jdk/java/foreign/TestMemoryAccess.java ! test/jdk/java/foreign/TestMemoryAlignment.java ! test/jdk/java/foreign/TestMemoryCopy.java ! test/jdk/java/foreign/TestMemoryHandleAsUnsigned.java ! test/jdk/java/foreign/TestMismatch.java ! test/jdk/java/foreign/TestNative.java - test/jdk/java/foreign/TestNativeScope.java ! test/jdk/java/foreign/TestNoForeignUnsafeOverride.java ! test/jdk/java/foreign/TestNulls.java ! test/jdk/java/foreign/TestRebase.java ! test/jdk/java/foreign/TestReshape.java + test/jdk/java/foreign/TestResourceScope.java + test/jdk/java/foreign/TestRestricted.java + test/jdk/java/foreign/TestScopedOperations.java + test/jdk/java/foreign/TestSegmentAllocators.java ! test/jdk/java/foreign/TestSegments.java ! test/jdk/java/foreign/TestSharedAccess.java ! test/jdk/java/foreign/TestSlices.java ! test/jdk/java/foreign/TestSpliterator.java ! test/jdk/java/foreign/TestTypeAccess.java ! test/jdk/java/foreign/TestUnsupportedPlatform.java ! test/jdk/java/foreign/TestUpcall.java ! test/jdk/java/foreign/TestUpcallHighArity.java + test/jdk/java/foreign/TestUpcallStructScope.java - test/jdk/java/foreign/TestUpcallStubs.java ! test/jdk/java/foreign/TestVarArgs.java ! test/jdk/java/foreign/TestVarHandleCombinators.java ! test/jdk/java/foreign/callarranger/TestAarch64CallArranger.java ! test/jdk/java/foreign/callarranger/TestSysVCallArranger.java ! test/jdk/java/foreign/callarranger/TestWindowsCallArranger.java + test/jdk/java/foreign/channels/AbstractChannelsTest.java + test/jdk/java/foreign/channels/TestAsyncSocketChannels.java + test/jdk/java/foreign/channels/TestSocketChannels.java + test/jdk/java/foreign/enablenativeaccess/TestDriver.java + test/jdk/java/foreign/enablenativeaccess/org/openjdk/foreigntest/PanamaMainUnnamedModule.java + test/jdk/java/foreign/enablenativeaccess/panama_module/module-info.java + test/jdk/java/foreign/enablenativeaccess/panama_module/org/openjdk/foreigntest/PanamaMain.java + test/jdk/java/foreign/enablenativeaccess/panama_module/org/openjdk/foreigntest/PanamaMainInvoke.java + test/jdk/java/foreign/enablenativeaccess/panama_module/org/openjdk/foreigntest/PanamaMainReflection.java + test/jdk/java/foreign/handles/Driver.java + test/jdk/java/foreign/handles/invoker_module/handle/invoker/MethodHandleInvoker.java + test/jdk/java/foreign/handles/invoker_module/module-info.java + test/jdk/java/foreign/handles/lookup_module/handle/lookup/MethodHandleLookup.java + test/jdk/java/foreign/handles/lookup_module/module-info.java ! test/jdk/java/foreign/libLookupTest.c + test/jdk/java/foreign/libSafeAccess.c = test/jdk/java/foreign/libTestUpcallStructScope.c ! test/jdk/java/foreign/stackwalk/TestStackWalk.java ! test/jdk/java/foreign/valist/VaListTest.java + test/jdk/java/foreign/virtual/TestVirtualCalls.java + test/jdk/java/foreign/virtual/libVirtual.c ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestExact.java ! test/jdk/java/util/stream/test/org/openjdk/tests/java/util/stream/SegmentTestDataProvider.java ! test/jdk/java/util/stream/test/org/openjdk/tests/java/util/stream/SpliteratorTest.java ! test/jdk/jdk/nio/zipfs/LargeEntriesTest.java ! test/jdk/tools/jar/modularJar/Basic.java ! test/lib/sun/hotspot/WhiteBox.java + test/micro/org/openjdk/bench/jdk/incubator/foreign/BulkMismatchAcquire.java ! test/micro/org/openjdk/bench/jdk/incubator/foreign/BulkOps.java - test/micro/org/openjdk/bench/jdk/incubator/foreign/CallOverhead.java + test/micro/org/openjdk/bench/jdk/incubator/foreign/CallOverheadConstant.java + test/micro/org/openjdk/bench/jdk/incubator/foreign/CallOverheadHelper.java + test/micro/org/openjdk/bench/jdk/incubator/foreign/CallOverheadVirtual.java ! test/micro/org/openjdk/bench/jdk/incubator/foreign/LoopOverConstant.java ! test/micro/org/openjdk/bench/jdk/incubator/foreign/LoopOverNew.java ! test/micro/org/openjdk/bench/jdk/incubator/foreign/LoopOverNonConstant.java ! test/micro/org/openjdk/bench/jdk/incubator/foreign/LoopOverNonConstantFP.java ! test/micro/org/openjdk/bench/jdk/incubator/foreign/LoopOverNonConstantHeap.java ! test/micro/org/openjdk/bench/jdk/incubator/foreign/LoopOverNonConstantMapped.java ! test/micro/org/openjdk/bench/jdk/incubator/foreign/LoopOverNonConstantShared.java ! test/micro/org/openjdk/bench/jdk/incubator/foreign/LoopOverPollutedSegments.java ! test/micro/org/openjdk/bench/jdk/incubator/foreign/ParallelSum.java + test/micro/org/openjdk/bench/jdk/incubator/foreign/ResourceScopeClose.java + test/micro/org/openjdk/bench/jdk/incubator/foreign/StrLenTest.java ! test/micro/org/openjdk/bench/jdk/incubator/foreign/TestAdaptVarHandles.java ! test/micro/org/openjdk/bench/jdk/incubator/foreign/UnrolledAccess.java ! test/micro/org/openjdk/bench/jdk/incubator/foreign/Upcalls.java ! test/micro/org/openjdk/bench/jdk/incubator/foreign/VaList.java ! test/micro/org/openjdk/bench/jdk/incubator/foreign/VarHandleExact.java ! test/micro/org/openjdk/bench/jdk/incubator/foreign/libCallOverhead.c ! test/micro/org/openjdk/bench/jdk/incubator/foreign/libCallOverheadJNI.c + test/micro/org/openjdk/bench/jdk/incubator/foreign/libStrLen.c ! test/micro/org/openjdk/bench/jdk/incubator/foreign/libUpcalls.c ! test/micro/org/openjdk/bench/jdk/incubator/foreign/libUpcallsJNI.c ! test/micro/org/openjdk/bench/jdk/incubator/foreign/points/PointsAccess.java ! test/micro/org/openjdk/bench/jdk/incubator/foreign/points/PointsAlloc.java ! test/micro/org/openjdk/bench/jdk/incubator/foreign/points/PointsDistance.java ! test/micro/org/openjdk/bench/jdk/incubator/foreign/points/PointsFree.java ! test/micro/org/openjdk/bench/jdk/incubator/foreign/points/support/PanamaPoint.java Changeset: 19450b99 Author: Jan Lahoda Date: 2021-06-02 11:16:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/19450b99512ce4ad4ab41be5034806e2c9dbcd59 8266281: Assign Symbols to the package selector expression Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Enter.java ! test/langtools/tools/javac/api/TestGetElementReference.java ! test/langtools/tools/javac/api/TestGetElementReferenceData.java ! test/langtools/tools/javac/api/lambdaErrorRecovery/TestGetTypeMirrorReference.java ! test/langtools/tools/javac/api/lambdaErrorRecovery/TestGetTypeMirrorReferenceData.java Changeset: 6765f902 Author: Weijun Wang Date: 2021-06-02 11:57:31 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6765f902505fbdd02f25b599f942437cd805cad1 8266459: Implement JEP 411: Deprecate the Security Manager for Removal Co-authored-by: Sean Mullan Co-authored-by: Lance Andersen Co-authored-by: Weijun Wang Reviewed-by: erikj, darcy, chegar, naoto, joehw, alanb, mchung, kcr, prr, lancea ! make/RunTests.gmk ! src/demo/share/jfc/J2Ddemo/java2d/Tools.java ! src/java.base/aix/classes/sun/nio/ch/DefaultSelectorProvider.java ! src/java.base/linux/classes/jdk/internal/platform/CgroupUtil.java ! src/java.base/linux/classes/sun/nio/ch/DefaultSelectorProvider.java ! src/java.base/macosx/classes/apple/security/AppleProvider.java ! src/java.base/macosx/classes/apple/security/KeychainStore.java ! src/java.base/macosx/classes/java/net/DefaultInterface.java ! src/java.base/macosx/classes/sun/nio/ch/DefaultSelectorProvider.java ! src/java.base/share/classes/com/sun/crypto/provider/DHKeyAgreement.java ! src/java.base/share/classes/com/sun/crypto/provider/JceKeyStore.java ! src/java.base/share/classes/com/sun/crypto/provider/SealedObjectForKeyProtector.java ! src/java.base/share/classes/com/sun/crypto/provider/SunJCE.java ! src/java.base/share/classes/java/io/File.java ! src/java.base/share/classes/java/io/FileInputStream.java ! src/java.base/share/classes/java/io/FileOutputStream.java ! src/java.base/share/classes/java/io/FilePermission.java ! src/java.base/share/classes/java/io/ObjectInputFilter.java ! src/java.base/share/classes/java/io/ObjectInputStream.java ! src/java.base/share/classes/java/io/ObjectOutputStream.java ! src/java.base/share/classes/java/io/ObjectStreamClass.java ! src/java.base/share/classes/java/io/ObjectStreamField.java ! src/java.base/share/classes/java/io/RandomAccessFile.java ! src/java.base/share/classes/java/lang/CharacterName.java ! src/java.base/share/classes/java/lang/Class.java ! src/java.base/share/classes/java/lang/ClassLoader.java ! src/java.base/share/classes/java/lang/LiveStackFrame.java ! src/java.base/share/classes/java/lang/Module.java ! src/java.base/share/classes/java/lang/ModuleLayer.java ! src/java.base/share/classes/java/lang/Package.java ! src/java.base/share/classes/java/lang/ProcessBuilder.java ! src/java.base/share/classes/java/lang/ProcessHandleImpl.java ! src/java.base/share/classes/java/lang/PublicMethods.java ! src/java.base/share/classes/java/lang/Runtime.java ! src/java.base/share/classes/java/lang/SecurityManager.java ! src/java.base/share/classes/java/lang/StackWalker.java ! src/java.base/share/classes/java/lang/String.java ! src/java.base/share/classes/java/lang/System.java ! src/java.base/share/classes/java/lang/Thread.java ! src/java.base/share/classes/java/lang/ThreadGroup.java ! src/java.base/share/classes/java/lang/constant/MethodTypeDescImpl.java ! src/java.base/share/classes/java/lang/invoke/ClassSpecializer.java ! src/java.base/share/classes/java/lang/invoke/InfoFromMemberName.java ! src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java ! src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.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/lang/invoke/MethodType.java ! src/java.base/share/classes/java/lang/invoke/ProxyClassesDumper.java ! src/java.base/share/classes/java/lang/invoke/SerializedLambda.java ! src/java.base/share/classes/java/lang/module/ModuleFinder.java ! src/java.base/share/classes/java/lang/ref/Finalizer.java ! src/java.base/share/classes/java/lang/reflect/AccessibleObject.java ! src/java.base/share/classes/java/lang/reflect/Proxy.java ! src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java ! src/java.base/share/classes/java/lang/runtime/ObjectMethods.java ! src/java.base/share/classes/java/net/AbstractPlainSocketImpl.java ! src/java.base/share/classes/java/net/Authenticator.java ! src/java.base/share/classes/java/net/CookieHandler.java ! src/java.base/share/classes/java/net/DatagramSocket.java ! src/java.base/share/classes/java/net/HttpConnectSocketImpl.java ! src/java.base/share/classes/java/net/HttpURLConnection.java ! src/java.base/share/classes/java/net/IDN.java ! src/java.base/share/classes/java/net/InetAddress.java ! src/java.base/share/classes/java/net/NetMulticastSocket.java ! src/java.base/share/classes/java/net/NetworkInterface.java ! src/java.base/share/classes/java/net/ProxySelector.java ! src/java.base/share/classes/java/net/ResponseCache.java ! src/java.base/share/classes/java/net/ServerSocket.java ! src/java.base/share/classes/java/net/Socket.java ! src/java.base/share/classes/java/net/SocketImpl.java ! src/java.base/share/classes/java/net/SocketPermission.java ! src/java.base/share/classes/java/net/SocksSocketImpl.java ! src/java.base/share/classes/java/net/URL.java ! src/java.base/share/classes/java/net/URLClassLoader.java ! src/java.base/share/classes/java/net/URLConnection.java ! src/java.base/share/classes/java/net/spi/URLStreamHandlerProvider.java ! src/java.base/share/classes/java/nio/channels/spi/AsynchronousChannelProvider.java ! src/java.base/share/classes/java/nio/channels/spi/SelectorProvider.java ! src/java.base/share/classes/java/nio/charset/Charset.java ! src/java.base/share/classes/java/nio/charset/spi/CharsetProvider.java ! src/java.base/share/classes/java/nio/file/FileSystems.java ! src/java.base/share/classes/java/nio/file/FileTreeWalker.java ! src/java.base/share/classes/java/nio/file/Files.java ! src/java.base/share/classes/java/nio/file/TempFileHelper.java ! src/java.base/share/classes/java/nio/file/spi/FileSystemProvider.java ! src/java.base/share/classes/java/nio/file/spi/FileTypeDetector.java ! src/java.base/share/classes/java/security/AccessControlContext.java ! src/java.base/share/classes/java/security/AccessControlException.java ! src/java.base/share/classes/java/security/AccessController.java ! src/java.base/share/classes/java/security/DomainCombiner.java ! src/java.base/share/classes/java/security/KeyStore.java ! src/java.base/share/classes/java/security/Permission.java ! src/java.base/share/classes/java/security/Policy.java ! src/java.base/share/classes/java/security/PolicySpi.java ! src/java.base/share/classes/java/security/ProtectionDomain.java ! src/java.base/share/classes/java/security/Provider.java ! src/java.base/share/classes/java/security/SecureRandom.java ! src/java.base/share/classes/java/security/Security.java ! src/java.base/share/classes/java/security/URIParameter.java ! src/java.base/share/classes/java/security/cert/CertPathBuilder.java ! src/java.base/share/classes/java/security/cert/CertPathValidator.java ! src/java.base/share/classes/java/security/cert/CertStore.java ! src/java.base/share/classes/java/time/chrono/HijrahChronology.java ! src/java.base/share/classes/java/time/zone/ZoneRulesProvider.java ! src/java.base/share/classes/java/util/Arrays.java ! src/java.base/share/classes/java/util/Calendar.java ! src/java.base/share/classes/java/util/Currency.java ! src/java.base/share/classes/java/util/Locale.java ! src/java.base/share/classes/java/util/ResourceBundle.java ! src/java.base/share/classes/java/util/ServiceLoader.java ! src/java.base/share/classes/java/util/TimeZone.java ! src/java.base/share/classes/java/util/Tripwire.java ! src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListSet.java ! src/java.base/share/classes/java/util/concurrent/CopyOnWriteArrayList.java ! src/java.base/share/classes/java/util/concurrent/Executors.java ! src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java ! src/java.base/share/classes/java/util/concurrent/ForkJoinWorkerThread.java ! src/java.base/share/classes/java/util/concurrent/ThreadLocalRandom.java ! src/java.base/share/classes/java/util/concurrent/ThreadPoolExecutor.java ! src/java.base/share/classes/java/util/concurrent/atomic/AtomicIntegerFieldUpdater.java ! src/java.base/share/classes/java/util/concurrent/atomic/AtomicLongFieldUpdater.java ! src/java.base/share/classes/java/util/concurrent/atomic/AtomicReferenceArray.java ! src/java.base/share/classes/java/util/concurrent/atomic/AtomicReferenceFieldUpdater.java ! src/java.base/share/classes/java/util/concurrent/atomic/Striped64.java ! src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java ! src/java.base/share/classes/java/util/spi/AbstractResourceBundleProvider.java ! src/java.base/share/classes/java/util/spi/LocaleServiceProvider.java ! src/java.base/share/classes/java/util/spi/ToolProvider.java ! src/java.base/share/classes/java/util/stream/Tripwire.java ! src/java.base/share/classes/java/util/zip/ZipFile.java ! src/java.base/share/classes/javax/crypto/JceSecurity.java.template ! src/java.base/share/classes/javax/crypto/JceSecurityManager.java ! src/java.base/share/classes/javax/crypto/ProviderVerifier.java ! src/java.base/share/classes/javax/net/ssl/HttpsURLConnection.java ! src/java.base/share/classes/javax/net/ssl/KeyManagerFactory.java ! src/java.base/share/classes/javax/net/ssl/SSLContext.java ! src/java.base/share/classes/javax/net/ssl/SSLSocketFactory.java ! src/java.base/share/classes/javax/net/ssl/TrustManagerFactory.java ! src/java.base/share/classes/javax/security/auth/Subject.java ! src/java.base/share/classes/javax/security/auth/SubjectDomainCombiner.java ! src/java.base/share/classes/javax/security/auth/login/Configuration.java ! src/java.base/share/classes/javax/security/auth/login/LoginContext.java ! src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java ! src/java.base/share/classes/jdk/internal/access/JavaSecurityAccess.java ! src/java.base/share/classes/jdk/internal/icu/impl/ICUBinary.java ! src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java ! src/java.base/share/classes/jdk/internal/jimage/NativeImageBuffer.java ! src/java.base/share/classes/jdk/internal/jrtfs/JrtFileSystemProvider.java ! src/java.base/share/classes/jdk/internal/jrtfs/SystemImage.java ! src/java.base/share/classes/jdk/internal/loader/BootLoader.java ! src/java.base/share/classes/jdk/internal/loader/BuiltinClassLoader.java ! src/java.base/share/classes/jdk/internal/loader/ClassLoaders.java ! src/java.base/share/classes/jdk/internal/loader/Loader.java ! src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java ! src/java.base/share/classes/jdk/internal/loader/URLClassPath.java ! src/java.base/share/classes/jdk/internal/logger/BootstrapLogger.java ! src/java.base/share/classes/jdk/internal/logger/DefaultLoggerFinder.java ! src/java.base/share/classes/jdk/internal/logger/LazyLoggers.java ! src/java.base/share/classes/jdk/internal/logger/LoggerFinderLoader.java ! src/java.base/share/classes/jdk/internal/logger/SimpleConsoleLogger.java ! src/java.base/share/classes/jdk/internal/misc/ExtendedMapMode.java ! src/java.base/share/classes/jdk/internal/misc/InnocuousThread.java ! src/java.base/share/classes/jdk/internal/module/ModuleReferences.java ! src/java.base/share/classes/jdk/internal/module/Modules.java ! src/java.base/share/classes/jdk/internal/module/SystemModuleFinders.java ! src/java.base/share/classes/jdk/internal/perf/Perf.java ! src/java.base/share/classes/jdk/internal/perf/PerfCounter.java ! src/java.base/share/classes/jdk/internal/ref/Cleaner.java ! src/java.base/share/classes/jdk/internal/reflect/ClassDefiner.java ! src/java.base/share/classes/jdk/internal/reflect/MethodAccessorGenerator.java ! src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java ! src/java.base/share/classes/jdk/internal/util/random/RandomSupport.java ! src/java.base/share/classes/sun/invoke/util/VerifyAccess.java ! src/java.base/share/classes/sun/net/InetAddressCachePolicy.java ! src/java.base/share/classes/sun/net/NetProperties.java ! src/java.base/share/classes/sun/net/NetworkClient.java ! src/java.base/share/classes/sun/net/ResourceManager.java ! src/java.base/share/classes/sun/net/ftp/FtpClientProvider.java ! src/java.base/share/classes/sun/net/ftp/impl/FtpClient.java ! src/java.base/share/classes/sun/net/spi/DefaultProxySelector.java ! src/java.base/share/classes/sun/net/util/IPAddressUtil.java ! src/java.base/share/classes/sun/net/util/SocketExceptions.java ! src/java.base/share/classes/sun/net/www/MimeTable.java ! src/java.base/share/classes/sun/net/www/http/HttpCapture.java ! src/java.base/share/classes/sun/net/www/http/HttpClient.java ! src/java.base/share/classes/sun/net/www/http/KeepAliveCache.java ! src/java.base/share/classes/sun/net/www/http/KeepAliveStream.java ! src/java.base/share/classes/sun/net/www/http/KeepAliveStreamCleaner.java ! src/java.base/share/classes/sun/net/www/protocol/ftp/FtpURLConnection.java ! src/java.base/share/classes/sun/net/www/protocol/http/AuthenticationInfo.java ! src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java ! src/java.base/share/classes/sun/net/www/protocol/http/HttpURLConnection.java ! src/java.base/share/classes/sun/net/www/protocol/https/HttpsClient.java ! src/java.base/share/classes/sun/net/www/protocol/jar/URLJarFile.java ! src/java.base/share/classes/sun/net/www/protocol/jrt/JavaRuntimeURLConnection.java ! src/java.base/share/classes/sun/net/www/protocol/mailto/MailToURLConnection.java ! src/java.base/share/classes/sun/nio/ch/AsynchronousChannelGroupImpl.java ! src/java.base/share/classes/sun/nio/ch/AsynchronousServerSocketChannelImpl.java ! src/java.base/share/classes/sun/nio/ch/AsynchronousSocketChannelImpl.java ! src/java.base/share/classes/sun/nio/ch/DatagramChannelImpl.java ! src/java.base/share/classes/sun/nio/ch/DatagramSocketAdaptor.java ! src/java.base/share/classes/sun/nio/ch/Invoker.java ! src/java.base/share/classes/sun/nio/ch/Net.java ! src/java.base/share/classes/sun/nio/ch/Reflect.java ! src/java.base/share/classes/sun/nio/ch/ServerSocketAdaptor.java ! src/java.base/share/classes/sun/nio/ch/ServerSocketChannelImpl.java ! src/java.base/share/classes/sun/nio/ch/SocketAdaptor.java ! src/java.base/share/classes/sun/nio/ch/SocketChannelImpl.java ! src/java.base/share/classes/sun/nio/ch/ThreadPool.java ! src/java.base/share/classes/sun/nio/ch/UnixDomainSockets.java ! src/java.base/share/classes/sun/nio/ch/Util.java ! src/java.base/share/classes/sun/nio/cs/CharsetMapping.java ! src/java.base/share/classes/sun/nio/fs/AbstractPoller.java ! src/java.base/share/classes/sun/nio/fs/AbstractUserDefinedFileAttributeView.java ! src/java.base/share/classes/sun/nio/fs/PollingWatchService.java ! src/java.base/share/classes/sun/nio/fs/Reflect.java ! src/java.base/share/classes/sun/reflect/annotation/AnnotationInvocationHandler.java ! src/java.base/share/classes/sun/reflect/annotation/AnnotationParser.java ! src/java.base/share/classes/sun/reflect/annotation/AnnotationSupport.java ! src/java.base/share/classes/sun/reflect/annotation/AnnotationType.java ! src/java.base/share/classes/sun/reflect/misc/MethodUtil.java ! src/java.base/share/classes/sun/reflect/misc/ReflectUtil.java ! src/java.base/share/classes/sun/security/action/GetBooleanAction.java ! src/java.base/share/classes/sun/security/action/GetIntegerAction.java ! src/java.base/share/classes/sun/security/action/GetPropertyAction.java ! src/java.base/share/classes/sun/security/jca/ProviderConfig.java ! src/java.base/share/classes/sun/security/jca/ProviderList.java ! src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java ! src/java.base/share/classes/sun/security/provider/ConfigFile.java ! src/java.base/share/classes/sun/security/provider/DRBG.java ! src/java.base/share/classes/sun/security/provider/MD4.java ! src/java.base/share/classes/sun/security/provider/PolicyFile.java ! src/java.base/share/classes/sun/security/provider/PolicySpiFile.java ! src/java.base/share/classes/sun/security/provider/SeedGenerator.java ! src/java.base/share/classes/sun/security/provider/SubjectCodeSource.java ! src/java.base/share/classes/sun/security/provider/Sun.java ! src/java.base/share/classes/sun/security/provider/SunEntries.java ! src/java.base/share/classes/sun/security/provider/VerificationProvider.java ! src/java.base/share/classes/sun/security/provider/certpath/OCSP.java ! src/java.base/share/classes/sun/security/provider/certpath/OCSPResponse.java ! src/java.base/share/classes/sun/security/provider/certpath/RevocationChecker.java ! src/java.base/share/classes/sun/security/rsa/SunRsaSign.java ! src/java.base/share/classes/sun/security/ssl/AlpnExtension.java ! src/java.base/share/classes/sun/security/ssl/PredefinedDHParameterSpecs.java ! src/java.base/share/classes/sun/security/ssl/SSLCipher.java ! src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java ! src/java.base/share/classes/sun/security/ssl/SSLContextImpl.java ! src/java.base/share/classes/sun/security/ssl/SSLEngineImpl.java ! src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java ! src/java.base/share/classes/sun/security/ssl/ServerHandshakeContext.java ! src/java.base/share/classes/sun/security/ssl/StatusResponseManager.java ! src/java.base/share/classes/sun/security/ssl/SunJSSE.java ! src/java.base/share/classes/sun/security/ssl/TransportContext.java ! src/java.base/share/classes/sun/security/ssl/TrustManagerFactoryImpl.java ! src/java.base/share/classes/sun/security/ssl/TrustStoreManager.java ! src/java.base/share/classes/sun/security/util/AbstractAlgorithmConstraints.java ! src/java.base/share/classes/sun/security/util/AnchorCertificates.java ! src/java.base/share/classes/sun/security/util/DomainName.java ! src/java.base/share/classes/sun/security/util/KeyStoreDelegator.java ! src/java.base/share/classes/sun/security/util/SecurityProperties.java ! src/java.base/share/classes/sun/security/util/UntrustedCertificates.java ! src/java.base/share/classes/sun/security/validator/CADistrustPolicy.java ! src/java.base/share/classes/sun/security/x509/X500Name.java ! src/java.base/share/classes/sun/util/calendar/ZoneInfoFile.java ! src/java.base/share/classes/sun/util/cldr/CLDRLocaleProviderAdapter.java ! src/java.base/share/classes/sun/util/locale/provider/AuxLocaleProviderAdapter.java ! src/java.base/share/classes/sun/util/locale/provider/JRELocaleProviderAdapter.java ! src/java.base/share/classes/sun/util/locale/provider/SPILocaleProviderAdapter.java ! src/java.base/share/classes/sun/util/resources/BreakIteratorResourceBundle.java ! src/java.base/share/classes/sun/util/resources/Bundles.java ! src/java.base/share/classes/sun/util/resources/LocaleData.java ! src/java.base/unix/classes/java/io/UnixFileSystem.java ! src/java.base/unix/classes/java/lang/ProcessImpl.java ! src/java.base/unix/classes/sun/net/dns/ResolverConfigurationImpl.java ! src/java.base/unix/classes/sun/net/www/protocol/http/ntlm/NTLMAuthentication.java ! src/java.base/unix/classes/sun/net/www/protocol/jar/JarFileFactory.java ! src/java.base/unix/classes/sun/nio/ch/InheritedChannel.java ! src/java.base/unix/classes/sun/nio/ch/UnixAsynchronousServerSocketChannelImpl.java ! src/java.base/unix/classes/sun/nio/ch/UnixAsynchronousSocketChannelImpl.java ! src/java.base/unix/classes/sun/nio/ch/UnixDomainSocketsUtil.java ! src/java.base/unix/classes/sun/nio/fs/MimeTypesFileTypeDetector.java ! src/java.base/unix/classes/sun/nio/fs/UnixChannelFactory.java ! src/java.base/unix/classes/sun/nio/fs/UnixCopyFile.java ! src/java.base/unix/classes/sun/nio/fs/UnixFileAttributeViews.java ! src/java.base/unix/classes/sun/nio/fs/UnixFileStore.java ! src/java.base/unix/classes/sun/nio/fs/UnixFileSystem.java ! src/java.base/unix/classes/sun/nio/fs/UnixFileSystemProvider.java ! src/java.base/unix/classes/sun/nio/fs/UnixPath.java ! src/java.base/unix/classes/sun/nio/fs/UnixSecureDirectoryStream.java ! src/java.base/unix/classes/sun/nio/fs/UnixUserDefinedFileAttributeView.java ! src/java.base/unix/classes/sun/nio/fs/UnixUserPrincipals.java ! src/java.base/unix/classes/sun/security/provider/NativePRNG.java ! src/java.base/windows/classes/java/io/WinNTFileSystem.java ! src/java.base/windows/classes/java/lang/ProcessImpl.java ! src/java.base/windows/classes/java/net/PlainSocketImpl.java ! src/java.base/windows/classes/sun/net/www/protocol/http/ntlm/NTLMAuthentication.java ! src/java.base/windows/classes/sun/net/www/protocol/jar/JarFileFactory.java ! src/java.base/windows/classes/sun/nio/ch/DefaultSelectorProvider.java ! src/java.base/windows/classes/sun/nio/ch/PipeImpl.java ! src/java.base/windows/classes/sun/nio/ch/UnixDomainSocketsUtil.java ! src/java.base/windows/classes/sun/nio/ch/WindowsAsynchronousServerSocketChannelImpl.java ! src/java.base/windows/classes/sun/nio/ch/WindowsAsynchronousSocketChannelImpl.java ! src/java.base/windows/classes/sun/nio/fs/WindowsAclFileAttributeView.java ! src/java.base/windows/classes/sun/nio/fs/WindowsChannelFactory.java ! src/java.base/windows/classes/sun/nio/fs/WindowsFileCopy.java ! src/java.base/windows/classes/sun/nio/fs/WindowsFileSystem.java ! src/java.base/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java ! src/java.base/windows/classes/sun/nio/fs/WindowsLinkSupport.java ! src/java.base/windows/classes/sun/nio/fs/WindowsPath.java ! src/java.base/windows/classes/sun/nio/fs/WindowsUserDefinedFileAttributeView.java ! src/java.base/windows/classes/sun/nio/fs/WindowsUserPrincipals.java ! src/java.compiler/share/classes/javax/tools/ToolProvider.java ! src/java.datatransfer/share/classes/java/awt/datatransfer/DataFlavor.java ! src/java.datatransfer/share/classes/java/awt/datatransfer/SystemFlavorMap.java ! src/java.desktop/macosx/classes/apple/laf/JRSUIUtils.java ! src/java.desktop/macosx/classes/com/apple/eawt/Application.java ! src/java.desktop/macosx/classes/com/apple/eio/FileManager.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaFileView.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaImageFactory.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaLookAndFeel.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaMenuBarUI.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaNativeResources.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaUtilControlSize.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaUtils.java ! src/java.desktop/macosx/classes/com/apple/laf/ScreenMenu.java ! src/java.desktop/macosx/classes/sun/awt/CGraphicsDevice.java ! src/java.desktop/macosx/classes/sun/awt/PlatformGraphicsInfo.java ! src/java.desktop/macosx/classes/sun/font/CFontManager.java ! src/java.desktop/macosx/classes/sun/java2d/MacOSFlags.java ! src/java.desktop/macosx/classes/sun/java2d/metal/MTLGraphicsConfig.java ! src/java.desktop/macosx/classes/sun/java2d/metal/MTLRenderQueue.java ! src/java.desktop/macosx/classes/sun/lwawt/LWComponentPeer.java ! src/java.desktop/macosx/classes/sun/lwawt/LWToolkit.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CAccessibility.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CDragSourceContextPeer.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CFileDialog.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CPrinterJob.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CTrayIcon.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/LWCToolkit.java ! src/java.desktop/share/classes/com/sun/beans/decoder/DocumentHandler.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/bmp/BMPImageReader.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageReader.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageWriter.java ! src/java.desktop/share/classes/com/sun/imageio/stream/StreamCloser.java ! src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKLookAndFeel.java ! src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/Metacity.java ! src/java.desktop/share/classes/com/sun/media/sound/JDK13Services.java ! src/java.desktop/share/classes/com/sun/media/sound/JSSecurityManager.java ! src/java.desktop/share/classes/com/sun/media/sound/Platform.java ! src/java.desktop/share/classes/com/sun/media/sound/Printer.java ! src/java.desktop/share/classes/com/sun/media/sound/SoftSynthesizer.java ! src/java.desktop/share/classes/java/awt/AWTEvent.java ! src/java.desktop/share/classes/java/awt/Component.java ! src/java.desktop/share/classes/java/awt/Container.java ! src/java.desktop/share/classes/java/awt/Cursor.java ! src/java.desktop/share/classes/java/awt/DefaultKeyboardFocusManager.java ! src/java.desktop/share/classes/java/awt/Desktop.java ! src/java.desktop/share/classes/java/awt/Dialog.java ! src/java.desktop/share/classes/java/awt/EventQueue.java ! src/java.desktop/share/classes/java/awt/Font.java ! src/java.desktop/share/classes/java/awt/GraphicsEnvironment.java ! src/java.desktop/share/classes/java/awt/KeyboardFocusManager.java ! src/java.desktop/share/classes/java/awt/MenuComponent.java ! src/java.desktop/share/classes/java/awt/MouseInfo.java ! src/java.desktop/share/classes/java/awt/Robot.java ! src/java.desktop/share/classes/java/awt/SequencedEvent.java ! src/java.desktop/share/classes/java/awt/SplashScreen.java ! src/java.desktop/share/classes/java/awt/SystemTray.java ! src/java.desktop/share/classes/java/awt/Taskbar.java ! src/java.desktop/share/classes/java/awt/TextComponent.java ! src/java.desktop/share/classes/java/awt/Toolkit.java ! src/java.desktop/share/classes/java/awt/TrayIcon.java ! src/java.desktop/share/classes/java/awt/WaitDispatchSupport.java ! src/java.desktop/share/classes/java/awt/Window.java ! src/java.desktop/share/classes/java/awt/color/ICC_Profile.java ! src/java.desktop/share/classes/java/awt/dnd/DragSource.java ! src/java.desktop/share/classes/java/awt/event/InputEvent.java ! src/java.desktop/share/classes/java/awt/event/NativeLibLoader.java ! src/java.desktop/share/classes/java/awt/image/BufferedImage.java ! src/java.desktop/share/classes/java/awt/image/ColorModel.java ! src/java.desktop/share/classes/java/awt/print/PrinterJob.java ! src/java.desktop/share/classes/java/beans/Beans.java ! src/java.desktop/share/classes/java/beans/EventHandler.java ! src/java.desktop/share/classes/java/beans/Introspector.java ! src/java.desktop/share/classes/java/beans/MetaData.java ! src/java.desktop/share/classes/java/beans/PropertyEditorManager.java ! src/java.desktop/share/classes/java/beans/SimpleBeanInfo.java ! src/java.desktop/share/classes/java/beans/Statement.java ! src/java.desktop/share/classes/java/beans/XMLDecoder.java ! src/java.desktop/share/classes/javax/accessibility/AccessibilityProvider.java ! src/java.desktop/share/classes/javax/imageio/ImageIO.java ! src/java.desktop/share/classes/javax/imageio/metadata/IIOMetadata.java ! src/java.desktop/share/classes/javax/imageio/spi/IIORegistry.java ! src/java.desktop/share/classes/javax/imageio/spi/ImageReaderWriterSpi.java ! src/java.desktop/share/classes/javax/imageio/spi/ServiceRegistry.java ! src/java.desktop/share/classes/javax/print/DocFlavor.java ! src/java.desktop/share/classes/javax/print/PrintServiceLookup.java ! src/java.desktop/share/classes/javax/print/StreamPrintServiceFactory.java ! src/java.desktop/share/classes/javax/swing/AbstractAction.java ! src/java.desktop/share/classes/javax/swing/DefaultListCellRenderer.java ! src/java.desktop/share/classes/javax/swing/ImageIcon.java ! src/java.desktop/share/classes/javax/swing/JFrame.java ! src/java.desktop/share/classes/javax/swing/JLayer.java ! src/java.desktop/share/classes/javax/swing/JPopupMenu.java ! src/java.desktop/share/classes/javax/swing/JRootPane.java ! src/java.desktop/share/classes/javax/swing/RepaintManager.java ! src/java.desktop/share/classes/javax/swing/SortingFocusTraversalPolicy.java ! src/java.desktop/share/classes/javax/swing/SwingPaintEventDispatcher.java ! src/java.desktop/share/classes/javax/swing/SwingUtilities.java ! src/java.desktop/share/classes/javax/swing/SwingWorker.java ! src/java.desktop/share/classes/javax/swing/Timer.java ! src/java.desktop/share/classes/javax/swing/TimerQueue.java ! src/java.desktop/share/classes/javax/swing/TransferHandler.java ! src/java.desktop/share/classes/javax/swing/UIDefaults.java ! src/java.desktop/share/classes/javax/swing/UIManager.java ! src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicComboBoxRenderer.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicLabelUI.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicLookAndFeel.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicPopupMenuUI.java ! src/java.desktop/share/classes/javax/swing/plaf/metal/DefaultMetalTheme.java ! src/java.desktop/share/classes/javax/swing/plaf/metal/MetalLabelUI.java ! src/java.desktop/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java ! src/java.desktop/share/classes/javax/swing/plaf/metal/MetalSliderUI.java ! src/java.desktop/share/classes/javax/swing/plaf/nimbus/NimbusLookAndFeel.java ! src/java.desktop/share/classes/javax/swing/table/DefaultTableCellRenderer.java ! src/java.desktop/share/classes/javax/swing/text/AbstractDocument.java ! src/java.desktop/share/classes/javax/swing/text/JTextComponent.java ! src/java.desktop/share/classes/javax/swing/text/PlainView.java ! src/java.desktop/share/classes/javax/swing/text/html/HTMLEditorKit.java ! src/java.desktop/share/classes/javax/swing/text/html/parser/ParserDelegator.java ! src/java.desktop/share/classes/javax/swing/text/rtf/RTFReader.java ! src/java.desktop/share/classes/sun/awt/AWTAccessor.java ! src/java.desktop/share/classes/sun/awt/AWTAutoShutdown.java ! src/java.desktop/share/classes/sun/awt/AppContext.java ! src/java.desktop/share/classes/sun/awt/CausedFocusEvent.java ! src/java.desktop/share/classes/sun/awt/DebugSettings.java ! src/java.desktop/share/classes/sun/awt/FontConfiguration.java ! src/java.desktop/share/classes/sun/awt/FontDescriptor.java ! src/java.desktop/share/classes/sun/awt/NativeLibLoader.java ! src/java.desktop/share/classes/sun/awt/SunToolkit.java ! src/java.desktop/share/classes/sun/awt/datatransfer/DataTransferer.java ! src/java.desktop/share/classes/sun/awt/datatransfer/TransferableProxy.java ! src/java.desktop/share/classes/sun/awt/dnd/SunDropTargetContextPeer.java ! src/java.desktop/share/classes/sun/awt/im/ExecutableInputMethodManager.java ! src/java.desktop/share/classes/sun/awt/im/InputContext.java ! src/java.desktop/share/classes/sun/awt/im/InputMethodContext.java ! src/java.desktop/share/classes/sun/awt/image/FileImageSource.java ! src/java.desktop/share/classes/sun/awt/image/ImageConsumerQueue.java ! src/java.desktop/share/classes/sun/awt/image/ImageDecoder.java ! src/java.desktop/share/classes/sun/awt/image/ImageFetcher.java ! src/java.desktop/share/classes/sun/awt/image/ImageWatched.java ! src/java.desktop/share/classes/sun/awt/image/ImagingLib.java ! src/java.desktop/share/classes/sun/awt/image/InputStreamImageSource.java ! src/java.desktop/share/classes/sun/awt/image/JPEGImageDecoder.java ! src/java.desktop/share/classes/sun/awt/image/NativeLibLoader.java ! src/java.desktop/share/classes/sun/awt/image/URLImageSource.java ! src/java.desktop/share/classes/sun/awt/image/VSyncedBSManager.java ! src/java.desktop/share/classes/sun/awt/shell/ShellFolderManager.java ! src/java.desktop/share/classes/sun/awt/util/PerformanceLogger.java ! src/java.desktop/share/classes/sun/font/CreatedFontTracker.java ! src/java.desktop/share/classes/sun/font/FileFont.java ! src/java.desktop/share/classes/sun/font/FontManagerFactory.java ! src/java.desktop/share/classes/sun/font/FontManagerNativeLibrary.java ! src/java.desktop/share/classes/sun/font/FontUtilities.java ! src/java.desktop/share/classes/sun/font/StrikeCache.java ! src/java.desktop/share/classes/sun/font/SunFontManager.java ! src/java.desktop/share/classes/sun/font/TrueTypeFont.java ! src/java.desktop/share/classes/sun/font/Type1Font.java ! src/java.desktop/share/classes/sun/java2d/Disposer.java ! src/java.desktop/share/classes/sun/java2d/SunGraphicsEnvironment.java ! src/java.desktop/share/classes/sun/java2d/SurfaceData.java ! src/java.desktop/share/classes/sun/java2d/SurfaceDataProxy.java ! src/java.desktop/share/classes/sun/java2d/cmm/CMSManager.java ! src/java.desktop/share/classes/sun/java2d/cmm/lcms/LCMS.java ! src/java.desktop/share/classes/sun/java2d/loops/GraphicsPrimitive.java ! src/java.desktop/share/classes/sun/java2d/marlin/DMarlinRenderingEngine.java ! src/java.desktop/share/classes/sun/java2d/marlin/MarlinProperties.java ! src/java.desktop/share/classes/sun/java2d/marlin/RendererStats.java ! src/java.desktop/share/classes/sun/java2d/opengl/OGLRenderQueue.java ! src/java.desktop/share/classes/sun/java2d/opengl/OGLSurfaceData.java ! src/java.desktop/share/classes/sun/java2d/pipe/RenderingEngine.java ! src/java.desktop/share/classes/sun/print/PSPrinterJob.java ! src/java.desktop/share/classes/sun/print/PrintJob2D.java ! src/java.desktop/share/classes/sun/print/RasterPrinterJob.java ! src/java.desktop/share/classes/sun/print/ServiceDialog.java ! src/java.desktop/share/classes/sun/swing/JLightweightFrame.java ! src/java.desktop/share/classes/sun/swing/SwingUtilities2.java ! src/java.desktop/unix/classes/sun/awt/PlatformGraphicsInfo.java ! src/java.desktop/unix/classes/sun/awt/UNIXToolkit.java ! src/java.desktop/unix/classes/sun/awt/X11/InfoWindow.java ! src/java.desktop/unix/classes/sun/awt/X11/MotifColorUtilities.java ! src/java.desktop/unix/classes/sun/awt/X11/Native.java ! src/java.desktop/unix/classes/sun/awt/X11/XClipboard.java ! src/java.desktop/unix/classes/sun/awt/X11/XEmbedCanvasPeer.java ! src/java.desktop/unix/classes/sun/awt/X11/XErrorHandlerUtil.java ! src/java.desktop/unix/classes/sun/awt/X11/XFileDialogPeer.java ! src/java.desktop/unix/classes/sun/awt/X11/XRobotPeer.java ! src/java.desktop/unix/classes/sun/awt/X11/XTaskbarPeer.java ! src/java.desktop/unix/classes/sun/awt/X11/XToolkit.java ! src/java.desktop/unix/classes/sun/awt/X11/XTrayIconPeer.java ! src/java.desktop/unix/classes/sun/awt/X11/XWindowPeer.java ! src/java.desktop/unix/classes/sun/awt/X11/XlibWrapper.java ! src/java.desktop/unix/classes/sun/awt/X11GraphicsDevice.java ! src/java.desktop/unix/classes/sun/awt/X11GraphicsEnvironment.java ! src/java.desktop/unix/classes/sun/java2d/x11/X11SurfaceData.java ! src/java.desktop/unix/classes/sun/java2d/xr/XRCompositeManager.java ! src/java.desktop/unix/classes/sun/print/CUPSPrinter.java ! src/java.desktop/unix/classes/sun/print/IPPPrintService.java ! src/java.desktop/unix/classes/sun/print/PrintServiceLookupProvider.java ! src/java.desktop/unix/classes/sun/print/UnixPrintJob.java ! src/java.desktop/unix/classes/sun/print/UnixPrintService.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/AnimationController.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/XPStyle.java ! src/java.desktop/windows/classes/sun/awt/Win32FontManager.java ! src/java.desktop/windows/classes/sun/awt/Win32GraphicsDevice.java ! src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java ! src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolderManager2.java ! src/java.desktop/windows/classes/sun/awt/windows/TranslucentWindowPainter.java ! src/java.desktop/windows/classes/sun/awt/windows/WEmbeddedFrame.java ! src/java.desktop/windows/classes/sun/awt/windows/WFileDialogPeer.java ! src/java.desktop/windows/classes/sun/awt/windows/WFramePeer.java ! src/java.desktop/windows/classes/sun/awt/windows/WMenuItemPeer.java ! src/java.desktop/windows/classes/sun/awt/windows/WPathGraphics.java ! src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java ! src/java.desktop/windows/classes/sun/awt/windows/WToolkit.java ! src/java.desktop/windows/classes/sun/java2d/d3d/D3DScreenUpdateManager.java ! src/java.desktop/windows/classes/sun/java2d/windows/WindowsFlags.java ! src/java.desktop/windows/classes/sun/print/PrintServiceLookupProvider.java ! src/java.desktop/windows/classes/sun/print/Win32PrintJob.java ! src/java.desktop/windows/classes/sun/print/Win32PrintService.java ! src/java.instrument/share/classes/sun/instrument/InstrumentationImpl.java ! src/java.logging/share/classes/java/util/logging/FileHandler.java ! src/java.logging/share/classes/java/util/logging/Handler.java ! src/java.logging/share/classes/java/util/logging/Level.java ! src/java.logging/share/classes/java/util/logging/LogManager.java ! src/java.logging/share/classes/java/util/logging/LogRecord.java ! src/java.logging/share/classes/java/util/logging/Logger.java ! src/java.logging/share/classes/java/util/logging/StreamHandler.java ! src/java.logging/share/classes/sun/util/logging/internal/LoggingProviderImpl.java ! src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java ! src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnector.java ! src/java.management/share/classes/com/sun/jmx/interceptor/DefaultMBeanServerInterceptor.java ! src/java.management/share/classes/com/sun/jmx/mbeanserver/ClassLoaderRepositorySupport.java ! src/java.management/share/classes/com/sun/jmx/mbeanserver/Introspector.java ! src/java.management/share/classes/com/sun/jmx/mbeanserver/JmxMBeanServer.java ! src/java.management/share/classes/com/sun/jmx/mbeanserver/MBeanInstantiator.java ! src/java.management/share/classes/com/sun/jmx/mbeanserver/MXBeanLookup.java ! src/java.management/share/classes/com/sun/jmx/mbeanserver/PerInterface.java ! src/java.management/share/classes/com/sun/jmx/remote/internal/ArrayNotificationBuffer.java ! src/java.management/share/classes/com/sun/jmx/remote/internal/ClientNotifForwarder.java ! src/java.management/share/classes/com/sun/jmx/remote/internal/ServerNotifForwarder.java ! src/java.management/share/classes/com/sun/jmx/remote/security/FileLoginModule.java ! src/java.management/share/classes/com/sun/jmx/remote/security/HashedPasswordManager.java ! src/java.management/share/classes/com/sun/jmx/remote/security/JMXPluggableAuthenticator.java ! src/java.management/share/classes/com/sun/jmx/remote/security/JMXSubjectDomainCombiner.java ! src/java.management/share/classes/com/sun/jmx/remote/security/MBeanServerAccessController.java ! src/java.management/share/classes/com/sun/jmx/remote/security/MBeanServerFileAccessController.java ! src/java.management/share/classes/com/sun/jmx/remote/security/SubjectDelegator.java ! src/java.management/share/classes/com/sun/jmx/remote/util/EnvHelp.java ! src/java.management/share/classes/java/lang/management/ManagementFactory.java ! src/java.management/share/classes/java/lang/management/RuntimeMXBean.java ! src/java.management/share/classes/javax/management/ClassAttributeValueExp.java ! src/java.management/share/classes/javax/management/MBeanAttributeInfo.java ! src/java.management/share/classes/javax/management/MBeanInfo.java ! src/java.management/share/classes/javax/management/MBeanServerFactory.java ! src/java.management/share/classes/javax/management/Notification.java ! src/java.management/share/classes/javax/management/NumericValueExp.java ! src/java.management/share/classes/javax/management/ObjectName.java ! src/java.management/share/classes/javax/management/StandardMBean.java ! src/java.management/share/classes/javax/management/loading/MLet.java ! src/java.management/share/classes/javax/management/modelmbean/DescriptorSupport.java ! src/java.management/share/classes/javax/management/modelmbean/InvalidTargetObjectTypeException.java ! src/java.management/share/classes/javax/management/modelmbean/ModelMBeanAttributeInfo.java ! src/java.management/share/classes/javax/management/modelmbean/ModelMBeanConstructorInfo.java ! src/java.management/share/classes/javax/management/modelmbean/ModelMBeanInfoSupport.java ! src/java.management/share/classes/javax/management/modelmbean/ModelMBeanNotificationInfo.java ! src/java.management/share/classes/javax/management/modelmbean/ModelMBeanOperationInfo.java ! src/java.management/share/classes/javax/management/modelmbean/RequiredModelMBean.java ! src/java.management/share/classes/javax/management/modelmbean/XMLParseException.java ! src/java.management/share/classes/javax/management/monitor/Monitor.java ! src/java.management/share/classes/javax/management/openmbean/OpenType.java ! src/java.management/share/classes/javax/management/openmbean/TabularDataSupport.java ! src/java.management/share/classes/javax/management/relation/MBeanServerNotificationFilter.java ! src/java.management/share/classes/javax/management/relation/RelationNotification.java ! src/java.management/share/classes/javax/management/relation/RelationTypeSupport.java ! src/java.management/share/classes/javax/management/relation/Role.java ! src/java.management/share/classes/javax/management/relation/RoleInfo.java ! src/java.management/share/classes/javax/management/relation/RoleResult.java ! src/java.management/share/classes/javax/management/relation/RoleUnresolved.java ! src/java.management/share/classes/javax/management/remote/JMXConnectorFactory.java ! src/java.management/share/classes/sun/management/ManagementFactoryHelper.java ! src/java.management/share/classes/sun/management/MappedMXBeanType.java ! src/java.management/share/classes/sun/management/Util.java ! src/java.management/share/classes/sun/management/VMManagementImpl.java ! src/java.management/share/classes/sun/management/spi/PlatformMBeanProvider.java ! src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java ! src/java.naming/share/classes/com/sun/jndi/ldap/LdapBindingEnumeration.java ! src/java.naming/share/classes/com/sun/jndi/ldap/LdapCtx.java ! src/java.naming/share/classes/com/sun/jndi/ldap/LdapDnsProviderService.java ! src/java.naming/share/classes/com/sun/jndi/ldap/LdapPoolManager.java ! src/java.naming/share/classes/com/sun/jndi/ldap/LdapSearchEnumeration.java ! src/java.naming/share/classes/com/sun/jndi/ldap/VersionHelper.java ! src/java.naming/share/classes/com/sun/naming/internal/VersionHelper.java ! src/java.naming/share/classes/javax/naming/ldap/StartTlsRequest.java ! src/java.naming/share/classes/javax/naming/ldap/spi/LdapDnsProvider.java ! src/java.naming/share/classes/javax/naming/spi/NamingManager.java ! src/java.naming/share/classes/sun/security/provider/certpath/ldap/JdkLDAP.java ! src/java.naming/share/classes/sun/security/provider/certpath/ldap/LDAPCertStore.java ! src/java.naming/share/classes/sun/security/provider/certpath/ldap/LDAPCertStoreImpl.java ! src/java.net.http/share/classes/jdk/internal/net/http/Exchange.java ! src/java.net.http/share/classes/jdk/internal/net/http/HttpClientImpl.java ! src/java.net.http/share/classes/jdk/internal/net/http/HttpRequestImpl.java ! src/java.net.http/share/classes/jdk/internal/net/http/MultiExchange.java ! src/java.net.http/share/classes/jdk/internal/net/http/PlainHttpConnection.java ! src/java.net.http/share/classes/jdk/internal/net/http/PrivilegedExecutor.java ! src/java.net.http/share/classes/jdk/internal/net/http/RequestPublishers.java ! src/java.net.http/share/classes/jdk/internal/net/http/ResponseBodyHandlers.java ! src/java.net.http/share/classes/jdk/internal/net/http/ResponseSubscribers.java ! src/java.net.http/share/classes/jdk/internal/net/http/common/Utils.java ! src/java.net.http/share/classes/jdk/internal/net/http/hpack/HPACK.java ! src/java.net.http/share/classes/jdk/internal/net/http/websocket/OpeningHandshake.java ! src/java.prefs/macosx/classes/java/util/prefs/MacOSXPreferencesFile.java ! src/java.prefs/share/classes/java/util/prefs/AbstractPreferences.java ! src/java.prefs/share/classes/java/util/prefs/Preferences.java ! src/java.prefs/unix/classes/java/util/prefs/FileSystemPreferences.java ! src/java.prefs/windows/classes/java/util/prefs/WindowsPreferences.java ! src/java.rmi/share/classes/java/rmi/MarshalledObject.java ! src/java.rmi/share/classes/java/rmi/RMISecurityManager.java ! src/java.rmi/share/classes/java/rmi/server/LogStream.java ! src/java.rmi/share/classes/java/rmi/server/ObjID.java ! src/java.rmi/share/classes/java/rmi/server/RMIClassLoader.java ! src/java.rmi/share/classes/java/rmi/server/RMISocketFactory.java ! src/java.rmi/share/classes/sun/rmi/log/ReliableLog.java ! src/java.rmi/share/classes/sun/rmi/registry/RegistryImpl.java ! src/java.rmi/share/classes/sun/rmi/runtime/Log.java ! src/java.rmi/share/classes/sun/rmi/runtime/NewThreadAction.java ! src/java.rmi/share/classes/sun/rmi/runtime/RuntimeUtil.java ! src/java.rmi/share/classes/sun/rmi/server/LoaderHandler.java ! src/java.rmi/share/classes/sun/rmi/server/MarshalInputStream.java ! src/java.rmi/share/classes/sun/rmi/server/MarshalOutputStream.java ! src/java.rmi/share/classes/sun/rmi/server/UnicastRef.java ! src/java.rmi/share/classes/sun/rmi/server/UnicastServerRef.java ! src/java.rmi/share/classes/sun/rmi/server/Util.java ! src/java.rmi/share/classes/sun/rmi/transport/DGCAckHandler.java ! src/java.rmi/share/classes/sun/rmi/transport/DGCClient.java ! src/java.rmi/share/classes/sun/rmi/transport/DGCImpl.java ! src/java.rmi/share/classes/sun/rmi/transport/GC.java ! src/java.rmi/share/classes/sun/rmi/transport/ObjectTable.java ! src/java.rmi/share/classes/sun/rmi/transport/StreamRemoteCall.java ! src/java.rmi/share/classes/sun/rmi/transport/Target.java ! src/java.rmi/share/classes/sun/rmi/transport/Transport.java ! src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java ! src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPEndpoint.java ! src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPTransport.java ! src/java.scripting/share/classes/javax/script/ScriptEngineManager.java ! src/java.security.jgss/share/classes/javax/security/auth/kerberos/KerberosPrincipal.java ! src/java.security.jgss/share/classes/javax/security/auth/kerberos/KeyTab.java ! src/java.security.jgss/share/classes/sun/security/jgss/GSSUtil.java ! src/java.security.jgss/share/classes/sun/security/jgss/LoginConfigImpl.java ! src/java.security.jgss/share/classes/sun/security/jgss/SunProvider.java ! src/java.security.jgss/share/classes/sun/security/jgss/krb5/InitialToken.java ! src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5AcceptCredential.java ! src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5Context.java ! src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5InitCredential.java ! src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5MechFactory.java ! src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5NameElement.java ! src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5Util.java ! src/java.security.jgss/share/classes/sun/security/jgss/wrapper/GSSCredElement.java ! src/java.security.jgss/share/classes/sun/security/jgss/wrapper/GSSNameElement.java ! src/java.security.jgss/share/classes/sun/security/jgss/wrapper/Krb5Util.java ! src/java.security.jgss/share/classes/sun/security/jgss/wrapper/NativeGSSContext.java ! src/java.security.jgss/share/classes/sun/security/jgss/wrapper/SunNativeProvider.java ! src/java.security.jgss/share/classes/sun/security/krb5/Config.java ! src/java.security.jgss/share/classes/sun/security/krb5/Credentials.java ! src/java.security.jgss/share/classes/sun/security/krb5/KdcComm.java ! src/java.security.jgss/share/classes/sun/security/krb5/KrbServiceLocator.java ! src/java.security.jgss/share/classes/sun/security/krb5/SCDynamicStoreConfig.java ! src/java.security.jgss/share/classes/sun/security/krb5/internal/ccache/FileCredentialsCache.java ! src/java.security.sasl/share/classes/com/sun/security/sasl/Provider.java ! src/java.security.sasl/share/classes/javax/security/sasl/Sasl.java ! src/java.smartcardio/share/classes/javax/smartcardio/TerminalFactory.java ! src/java.smartcardio/share/classes/sun/security/smartcardio/CardImpl.java ! src/java.smartcardio/share/classes/sun/security/smartcardio/ChannelImpl.java ! src/java.smartcardio/share/classes/sun/security/smartcardio/SunPCSC.java ! src/java.smartcardio/share/classes/sun/security/smartcardio/TerminalImpl.java ! src/java.smartcardio/unix/classes/sun/security/smartcardio/PlatformPCSC.java ! src/java.smartcardio/windows/classes/sun/security/smartcardio/PlatformPCSC.java ! src/java.sql.rowset/share/classes/com/sun/rowset/CachedRowSetImpl.java ! src/java.sql.rowset/share/classes/javax/sql/rowset/RowSetProvider.java ! src/java.sql.rowset/share/classes/javax/sql/rowset/serial/SerialJavaObject.java ! src/java.sql.rowset/share/classes/javax/sql/rowset/spi/SyncFactory.java ! src/java.sql/share/classes/java/sql/DriverManager.java ! src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/Init.java ! src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/UtfHelpper.java ! src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/parser/XMLParserImpl.java ! src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/signature/Manifest.java ! src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/signature/Reference.java ! src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/utils/IgnoreAllErrorHandler.java ! src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/utils/JavaUtils.java ! src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/utils/XMLUtils.java ! src/java.xml.crypto/share/classes/com/sun/org/slf4j/internal/Logger.java ! src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMReference.java ! src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/Policy.java ! src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/XMLDSigRI.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/utils/ObjectFactory.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/Type.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TemplatesImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerFactoryImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/DocumentBuilderFactoryImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/SAXParserFactoryImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaFactory.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaValidatorComponentManager.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/utils/ObjectFactory.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/jaxp/XPathFactoryImpl.java ! src/java.xml/share/classes/javax/xml/datatype/FactoryFinder.java ! src/java.xml/share/classes/javax/xml/parsers/FactoryFinder.java ! src/java.xml/share/classes/javax/xml/stream/FactoryFinder.java ! src/java.xml/share/classes/javax/xml/transform/FactoryFinder.java ! src/java.xml/share/classes/javax/xml/transform/TransformerException.java ! src/java.xml/share/classes/javax/xml/validation/SchemaFactoryFinder.java ! src/java.xml/share/classes/javax/xml/xpath/XPathFactoryFinder.java ! src/java.xml/share/classes/jdk/xml/internal/JdkXmlUtils.java ! src/java.xml/share/classes/jdk/xml/internal/SecuritySupport.java ! src/java.xml/share/classes/org/w3c/dom/bootstrap/DOMImplementationRegistry.java ! src/java.xml/share/classes/org/xml/sax/helpers/NewInstance.java ! src/java.xml/share/classes/org/xml/sax/helpers/XMLReaderFactory.java ! src/jdk.accessibility/share/classes/com/sun/java/accessibility/util/AWTEventMonitor.java ! src/jdk.accessibility/share/classes/com/sun/java/accessibility/util/EventQueueMonitor.java ! src/jdk.accessibility/windows/classes/com/sun/java/accessibility/internal/AccessBridge.java ! src/jdk.attach/share/classes/com/sun/tools/attach/spi/AttachProvider.java ! src/jdk.attach/share/classes/sun/tools/attach/HotSpotAttachProvider.java ! src/jdk.attach/share/classes/sun/tools/attach/HotSpotVirtualMachine.java ! src/jdk.charsets/share/classes/sun/nio/cs/ext/JISAutoDetect.java ! src/jdk.charsets/share/classes/sun/nio/cs/ext/SJIS_0213.java ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/Config.java ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11KeyAgreement.java ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Util.java ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11.java ! src/jdk.crypto.ec/share/classes/sun/security/ec/SunEC.java ! src/jdk.crypto.mscapi/windows/classes/sun/security/mscapi/CKeyStore.java ! src/jdk.crypto.mscapi/windows/classes/sun/security/mscapi/SunMSCAPI.java ! src/jdk.dynalink/share/classes/jdk/dynalink/BiClassValue.java ! src/jdk.dynalink/share/classes/jdk/dynalink/DynamicLinkerFactory.java ! src/jdk.dynalink/share/classes/jdk/dynalink/SecureLookupSupplier.java ! src/jdk.dynalink/share/classes/jdk/dynalink/beans/BeanIntrospector.java ! src/jdk.dynalink/share/classes/jdk/dynalink/beans/CallerSensitiveDynamicMethod.java ! src/jdk.dynalink/share/classes/jdk/dynalink/beans/CheckRestrictedPackage.java ! src/jdk.dynalink/share/classes/jdk/dynalink/beans/ClassString.java ! src/jdk.dynalink/share/classes/jdk/dynalink/beans/OverloadedDynamicMethod.java ! src/jdk.dynalink/share/classes/jdk/dynalink/internal/AccessControlContextFactory.java ! src/jdk.dynalink/share/classes/jdk/dynalink/linker/GuardingDynamicLinkerExporter.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/SALauncherLoader.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/jcore/ByteCodeRewriter.java ! src/jdk.httpserver/share/classes/com/sun/net/httpserver/spi/HttpServerProvider.java ! src/jdk.httpserver/share/classes/sun/net/httpserver/ServerConfig.java ! src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java ! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/LibraryLookup.java ! src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/PerfDataBuffer.java ! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.services/src/jdk/vm/ci/services/JVMCIServiceLocator.java ! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.services/src/jdk/vm/ci/services/Services.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/VirtualMachineManagerImpl.java ! src/jdk.jfr/share/classes/jdk/jfr/FlightRecorder.java ! src/jdk.jfr/share/classes/jdk/jfr/FlightRecorderPermission.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/RecordingStream.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/Control.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/PlatformRecorder.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/PlatformRecording.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/PrivateAccess.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/RequestEngine.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/SecuritySupport.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/ShutdownHook.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/Utils.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/WriteableUserPath.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/AbstractEventStream.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/EventDirectoryStream.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/EventFileStream.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/management/ManagementSupport.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/Jlink.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/Main.java ! src/jdk.jstatd/share/classes/sun/tools/jstatd/Jstatd.java ! src/jdk.management.agent/share/classes/jdk/internal/agent/spi/AgentProvider.java ! src/jdk.management.agent/unix/classes/jdk/internal/agent/FileSystemImpl.java ! src/jdk.management.agent/windows/classes/jdk/internal/agent/FileSystemImpl.java ! src/jdk.management.jfr/share/classes/jdk/management/jfr/FlightRecorderMXBeanImpl.java ! src/jdk.management.jfr/share/classes/jdk/management/jfr/MBeanUtils.java ! src/jdk.management.jfr/share/classes/jdk/management/jfr/RemoteRecordingStream.java ! src/jdk.management/share/classes/com/sun/management/internal/DiagnosticCommandImpl.java ! src/jdk.management/share/classes/com/sun/management/internal/Flag.java ! src/jdk.management/share/classes/com/sun/management/internal/GarbageCollectionNotifInfoCompositeData.java ! src/jdk.management/share/classes/com/sun/management/internal/GcInfoCompositeData.java ! src/jdk.management/share/classes/com/sun/management/internal/HotSpotDiagnostic.java ! src/jdk.management/share/classes/com/sun/management/internal/PlatformMBeanProviderImpl.java ! src/jdk.naming.dns/share/classes/com/sun/jndi/dns/DnsContextFactory.java ! src/jdk.naming.rmi/share/classes/com/sun/jndi/rmi/registry/RegistryContext.java ! src/jdk.net/linux/classes/jdk/net/LinuxSocketOptions.java ! src/jdk.net/macosx/classes/jdk/net/MacOSXSocketOptions.java ! src/jdk.net/share/classes/jdk/net/ExtendedSocketOptions.java ! src/jdk.net/share/classes/jdk/nio/Channels.java ! src/jdk.sctp/unix/classes/sun/nio/ch/sctp/SctpChannelImpl.java ! src/jdk.sctp/unix/classes/sun/nio/ch/sctp/SctpMultiChannelImpl.java ! src/jdk.sctp/unix/classes/sun/nio/ch/sctp/SctpNet.java ! src/jdk.sctp/unix/classes/sun/nio/ch/sctp/SctpServerChannelImpl.java ! src/jdk.security.jgss/share/classes/com/sun/security/jgss/ExtendedGSSContextImpl.java ! src/jdk.security.jgss/share/classes/com/sun/security/sasl/gsskerb/JdkSASL.java ! src/jdk.unsupported/share/classes/sun/reflect/ReflectionFactory.java ! src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java ! src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystemProvider.java ! test/jdk/java/awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java ! test/jdk/java/lang/System/LoggerFinder/internal/LoggerFinderLoaderTest/LoggerFinderLoaderTest.java + test/jdk/java/lang/System/SecurityManagerWarnings.java ! test/jdk/java/lang/invoke/lambda/LogGeneratedClassesTest.java ! test/jdk/java/net/spi/URLStreamHandlerProvider/Basic.java ! test/jdk/java/security/AccessController/DoPrivAccompliceTest.java ! test/lib/jdk/test/lib/Platform.java ! test/lib/jdk/test/lib/process/OutputAnalyzer.java ! test/lib/sun/hotspot/WhiteBox.java ! test/micro/org/openjdk/bench/java/lang/reflect/ClazzWithSecurityManager.java ! test/micro/org/openjdk/bench/java/security/DoPrivileged.java ! test/micro/org/openjdk/bench/java/security/GetContext.java Changeset: 2963c9e6 Author: Severin Gehwolf Date: 2021-06-02 12:18:30 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2963c9e6778b95f5c0fc4298064a21d1e8f31b91 8268103: JNI functions incorrectly return a double after JDK-8265836 Reviewed-by: dholmes ! src/jdk.management/aix/native/libmanagement_ext/UnixOperatingSystem.c ! src/jdk.management/macosx/native/libmanagement_ext/UnixOperatingSystem.c Changeset: dc19baca Author: David Holmes Date: 2021-06-02 12:23:56 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/dc19baca3363a105a5cc1dbc02cbe3ea65e1209e 8268094: Some vmTestbase/nsk tests fail after ACC_STRICT/strictfp changes Reviewed-by: vlivanov, rehn ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses007.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses007/TestDescription.java - test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses007/newclass07/redefineclasses007a.java - test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses007/newclass08/redefineclasses007a.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses008.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses008/TestDescription.java - test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses008/newclass07/redefineclasses008a.java - test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses008/newclass08/redefineclasses008a.java ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassModifiers/getclmdf006/getclmdf006.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassModifiers/getclmdf007/getclmdf007.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetFieldModifiers/getfldmdf004/getfldmdf004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetMethodModifiers/methmod001.java ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetMethodModifiers/methmod001/methmod001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/Injector.h Changeset: 47677580 Author: Stefan Karlsson Date: 2021-06-02 13:33:04 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/476775808f82a4b0d42ac58fdb801812b54e01a1 8267920: Create separate Events buffer for VMOperations Reviewed-by: coleenp, dholmes, tschatzl ! src/hotspot/share/runtime/vmThread.cpp ! src/hotspot/share/utilities/events.cpp ! src/hotspot/share/utilities/events.hpp Changeset: 21a08587 Author: Jorn Vernee Date: 2021-06-02 14:23:32 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/21a0858726d3eaa197dd215e8850075281a416dc Merge Manual merge of jdk/master into panama-foreign/master Changeset: 1a6aa790 Author: J. Duke Committer: Maurizio Cimadamore Date: 2021-06-02 16:06:17 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1a6aa790fee31d31c92e829cdef1a53cac7bb6f2 Merge master ! src/hotspot/share/logging/logTag.hpp ! src/java.base/share/classes/java/lang/ClassLoader.java ! src/java.base/share/classes/java/lang/System.java ! src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/java.base/share/classes/java/lang/invoke/VarHandles.java ! src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java ! src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java ! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java ! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemoryHandles.java ! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/package-info.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/AbstractCLinker.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/ProgrammableUpcallHandler.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/SharedUtils.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/aarch64/AArch64Linker.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/x64/sysv/SysVx64Linker.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/x64/windows/Windowsx64Linker.java ! test/jdk/java/foreign/TestIntrinsics.java ! test/jdk/java/foreign/TestResourceScope.java ! test/jdk/java/foreign/TestUpcall.java ! test/jdk/java/foreign/TestUpcallStructScope.java + test/jdk/java/foreign/handles/invoker_module/handle/invoker/MethodHandleInvoker.java + test/jdk/java/foreign/handles/lookup_module/handle/lookup/MethodHandleLookup.java ! test/micro/org/openjdk/bench/jdk/incubator/foreign/CallOverheadHelper.java ! test/micro/org/openjdk/bench/jdk/incubator/foreign/VaList.java ! src/hotspot/share/logging/logTag.hpp ! src/java.base/share/classes/java/lang/ClassLoader.java ! src/java.base/share/classes/java/lang/System.java ! src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/java.base/share/classes/java/lang/invoke/VarHandles.java ! src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java ! src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java ! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java ! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemoryHandles.java ! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/package-info.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/AbstractCLinker.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/ProgrammableUpcallHandler.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/SharedUtils.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/aarch64/AArch64Linker.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/x64/sysv/SysVx64Linker.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/x64/windows/Windowsx64Linker.java ! test/jdk/java/foreign/TestIntrinsics.java ! test/jdk/java/foreign/TestResourceScope.java ! test/jdk/java/foreign/TestUpcall.java ! test/jdk/java/foreign/TestUpcallStructScope.java ! test/jdk/java/foreign/handles/invoker_module/handle/invoker/MethodHandleInvoker.java ! test/jdk/java/foreign/handles/lookup_module/handle/lookup/MethodHandleLookup.java ! test/micro/org/openjdk/bench/jdk/incubator/foreign/CallOverheadHelper.java ! test/micro/org/openjdk/bench/jdk/incubator/foreign/VaList.java Changeset: 53f348f8 Author: duke Date: 2021-06-02 16:07:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/53f348f8428e8ad13269d738e2f16789c1c0dbf2 Automatic merge of foreign-memaccess+abi into foreign-jextract ! test/jdk/TEST.groups ! test/jdk/tools/launcher/HelpFlagsTest.java ! test/jdk/tools/launcher/VersionCheck.java ! test/jdk/TEST.groups ! test/jdk/tools/launcher/HelpFlagsTest.java ! test/jdk/tools/launcher/VersionCheck.java From duke at openjdk.java.net Wed Jun 2 18:59:47 2021 From: duke at openjdk.java.net (J.Duke) Date: Wed, 2 Jun 2021 18:59:47 GMT Subject: [foreign-memaccess+abi] RFR: Merge master [v2] In-Reply-To: <8inAKVp1NLC1kri0nd35Ri8Efw4s5l5REfBc-cmijPk=.58482dea-c00b-4ac1-8905-afbebdfd34b1@github.com> References: <8inAKVp1NLC1kri0nd35Ri8Efw4s5l5REfBc-cmijPk=.58482dea-c00b-4ac1-8905-afbebdfd34b1@github.com> Message-ID: > Hi all, > > this is an _automatically_ generated pull request to notify you that there are 90 commits from the branch `master`that can **not** be merged into the branch `foreign-memaccess+abi`: > > The following files contains merge conflicts: > > - src/java.base/share/classes/java/lang/Module.java > - src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.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-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 +96:openjdk-bot-96 > $ git checkout openjdk-bot-96 > > # 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-96:96 > > > _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. ------------- Changes: - all: https://git.openjdk.java.net/panama-foreign/pull/542/files - new: https://git.openjdk.java.net/panama-foreign/pull/542/files/d85793d0..d85793d0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=542&range=01 - incr: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=542&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/542.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/542/head:pull/542 PR: https://git.openjdk.java.net/panama-foreign/pull/542 From elect86 at gmail.com Wed Jun 2 22:52:20 2021 From: elect86 at gmail.com (Giuseppe Barbieri) Date: Thu, 3 Jun 2021 00:52:20 +0200 Subject: MethodHandler out of a non-static method Message-ID: Hi, excited from the last development, I came back giving a try to the latest jdk build (the partial 17 available on the site) and I'm trying to update/fix the opengl sample First of all, it looks like `jextract` doesn't accept anymore the option to produce an output jar. I had to manually compress the resulting folder to zip and rename, before importing in the target project. It'd be cool if jextract could output directly the jar (and the sources) Coming back to my issue, how can I retrieve the MethodHandler out of a non-static method? Thanks in advance From gabaden at gmail.com Wed Jun 2 11:04:28 2021 From: gabaden at gmail.com (Denis Gabaydulin) Date: Wed, 2 Jun 2021 14:04:28 +0300 Subject: [ a newby question about vectorized shuffling / permutation ] Message-ID: Hi, folks! Have a newbie question about the API. I'm trying to explore a new and shiny vector API with simple but useful examples. One of that is to build a SIMD version to find any intersection of two sorted lists. E.g. hasIntersection([1, 3, 4, 10], [2, 6, 6, 11]) => false hasIntersection([1, 3, 4, 10], [2, 3, 6, 11]) => true A mental model of this algorithm which I have: 1). to get a part of an array one 2). compare it n-times which corresponding part of an array two. 3). each time we need to compare two parts of arrays we need to shuffle (permutate) a left part by a mask. E.g. 1, 3, 4, 10 -> 10, 1, 3, 4 4). if one of a number is the same, return true, otherwise, move. In SIMD instructions looks like I need two major things. 1). vectorized comparison instruction 2). vectorized shuffle instruction. The first one, I can see in the printed asm. compare in API -> vpcmpeqd The question, which function of the vector API should I use to getting something like _mm_shuffle_epi32 ? From xgong at openjdk.java.net Thu Jun 3 03:16:54 2021 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Thu, 3 Jun 2021 03:16:54 GMT Subject: [vectorIntrinsics] RFR: 8266720: Wrong implementation in LibraryCallKit::inline_vector_shuffle_iota [v3] In-Reply-To: <1YWES0jFg8uA3GLedDyEbUq-jhROJOIDXoml4RZ3zkw=.2bc9a3c9-1d94-4790-8678-f1f0809ea584@github.com> References: <1YWES0jFg8uA3GLedDyEbUq-jhROJOIDXoml4RZ3zkw=.2bc9a3c9-1d94-4790-8678-f1f0809ea584@github.com> Message-ID: On Wed, 2 Jun 2021 08:05:07 GMT, Wang Huang wrote: >> Because JDK-8266317 has not been merged into jdk/jdk. So I fix this bug here. >> * This comparsion should be a unsigned cmp >> * `x86` is not wrong because `x86` does not have 1024-bits vl here. >> ```c++ >> >> ConINode* pred_node = (ConINode*)gvn().makecon(TypeInt::make(BoolTest::ge)); // should BoolTest::ugt >> Node * lane_cnt = gvn().makecon(TypeInt::make(num_elem)); >> Node * bcast_lane_cnt = gvn().transform(VectorNode::scalar2vector(lane_cnt, num_elem, type_bt)); >> // should BoolTest::ugt >> Node* mask = gvn().transform(new VectorMaskCmpNode(BoolTest::ge, bcast_lane_cnt, res, pred_node, vt)); > > Wang Huang has updated the pull request incrementally with one additional commit since the last revision: > > only fix IR src/hotspot/share/opto/vectorIntrinsics.cpp line 467: > 465: } else { > 466: // Currently it works well for vector_length <= 1024-bits. > 467: // for vector_length > 1024, we don't support now Does it need any vector length check or block for vector length >1024? ------------- PR: https://git.openjdk.java.net/panama-vector/pull/81 From whuang at openjdk.java.net Thu Jun 3 03:26:51 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Thu, 3 Jun 2021 03:26:51 GMT Subject: [vectorIntrinsics] RFR: 8266720: Wrong implementation in LibraryCallKit::inline_vector_shuffle_iota [v3] In-Reply-To: References: <1YWES0jFg8uA3GLedDyEbUq-jhROJOIDXoml4RZ3zkw=.2bc9a3c9-1d94-4790-8678-f1f0809ea584@github.com> Message-ID: On Thu, 3 Jun 2021 03:13:39 GMT, Xiaohong Gong wrote: >> Wang Huang has updated the pull request incrementally with one additional commit since the last revision: >> >> only fix IR > > src/hotspot/share/opto/vectorIntrinsics.cpp line 467: > >> 465: } else { >> 466: // Currently it works well for vector_length <= 1024-bits. >> 467: // for vector_length > 1024, we don't support now > > Does it need any vector length check or block for vector length >1024? Thank you for your reviw. It is a problem here. I will do that in next commit. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/81 From sundar at openjdk.java.net Thu Jun 3 06:33:13 2021 From: sundar at openjdk.java.net (Athijegannathan Sundararajan) Date: Thu, 3 Jun 2021 06:33:13 GMT Subject: [foreign-jextract] RFR: 8268160: jextract tool provider should avoid security manager usage Message-ID: jextract is not incubated in JDK as of now. By the time it makes into JDK (if it does), security manager would have been removed. Removing security manager usage in jextract code. ------------- Commit messages: - 8268160: jextract tool provider should avoid security manager usage Changes: https://git.openjdk.java.net/panama-foreign/pull/546/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=546&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268160 Stats: 9 lines in 1 file changed: 0 ins; 9 del; 0 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/546.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/546/head:pull/546 PR: https://git.openjdk.java.net/panama-foreign/pull/546 From xgong at openjdk.java.net Thu Jun 3 09:20:29 2021 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Thu, 3 Jun 2021 09:20:29 GMT Subject: [vectorIntrinsics+mask] RFR: Merge panama-vector:vectorIntrinsics Message-ID: <-CRodaLtIXMf0zpvj2eGdg8GKsnvGFJ1HZ5lw_4cq6c=.8e550d09-f8ea-48ce-86c0-520e317e61ea@github.com> Merge with panama-vector:vectorIntrinsics. Tested tier1 and Vector API tests on both x86 and aarch64. ------------- Commit messages: - Merge panama-vector:vectorIntrinsics - 8266286: Add LoadVectorGather and StoreVectorScatter's partial version - Merge panama-vector:master - 8251392: Consolidate Metaspace Statistics - 8267116: Lanai: Incorrect AlphaComposite for VolatileImage graphics - 8266404: Fatal error report generated with -XX:+CrashOnOutOfMemoryError should not contain suggestion to submit a bug report - 8267112: JVMCI compiler modules should be kept upgradable - 8264777: Overload optimized FileInputStream::readAllBytes - 8266742: Check W^X state on possible safepoint - 8266520: Revert to OpenGL as the default 2D rendering pipeline for macOS - ... and 655 more: https://git.openjdk.java.net/panama-vector/compare/24b52623...b0f95c03 The webrevs contain the adjustments done while merging with regards to each parent branch: - vectorIntrinsics+mask: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=89&range=00.0 - panama-vector:vectorIntrinsics: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=89&range=00.1 Changes: https://git.openjdk.java.net/panama-vector/pull/89/files Stats: 661580 lines in 7192 files changed: 100205 ins; 539586 del; 21789 mod Patch: https://git.openjdk.java.net/panama-vector/pull/89.diff Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/89/head:pull/89 PR: https://git.openjdk.java.net/panama-vector/pull/89 From maurizio.cimadamore at oracle.com Thu Jun 3 09:33:13 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 3 Jun 2021 10:33:13 +0100 Subject: MethodHandler out of a non-static method In-Reply-To: References: Message-ID: Hi Giuseppe On 02/06/2021 23:52, Giuseppe Barbieri wrote: > Hi, > > excited from the last development, I came back giving a try to the latest > jdk build (the partial 17 available on the site) and I'm trying to > update/fix the opengl sample > > First of all, it looks like `jextract` doesn't accept anymore the option to > produce an output jar. I had to manually compress the resulting folder to > zip and rename, before importing in the target project. We decided to simplify jextract and focus on source code generation, which seems to be the mode that most people want to work with, and it's also the "more primitive": you can derive classes (and jars) from it. If you are using it in a project, you might consider directly checking in the extracted sources in your project. If you are using an IDE, it is going to improve your experience a little bit (the classfiles generated by the old jextract were poorly understood by some of the IDEs out there, which led to issues in indexing). > > It'd be cool if jextract could output directly the jar (and the sources) > > Coming back to my issue, how can I retrieve the MethodHandler out of a > non-static method? You mean you want to create a MethodHandle for an instance method? Let's see (I'll use jshell to make sure my code doesn't have any typos :-) ): ``` jshell> class Foo { ?? ...> void greet(String msg) { System.out.println(msg); } ?? ...> } |? created class Foo jshell> import java.lang.invoke.*; jshell> MethodHandle greetMH = MethodHandles.lookup().findVirtual(Foo.class, "greet", MethodType.methodType(void.class, String.class)); greetMH ==> MethodHandle(Foo,String)void jshell> greetMH.invoke(new Foo(), "Panama"); Panama ``` Is this what you were looking for? Cheers Maurizio > > > Thanks in advance From forax at univ-mlv.fr Thu Jun 3 09:47:51 2021 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 3 Jun 2021 11:47:51 +0200 (CEST) Subject: MethodHandler out of a non-static method In-Reply-To: References: Message-ID: <317399504.211657.1622713671678.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Maurizio Cimadamore" > ?: "Giuseppe Barbieri" , "panama-dev at openjdk.java.net'" > Envoy?: Jeudi 3 Juin 2021 11:33:13 > Objet: Re: MethodHandler out of a non-static method > Hi Giuseppe > > On 02/06/2021 23:52, Giuseppe Barbieri wrote: >> Hi, >> >> excited from the last development, I came back giving a try to the latest >> jdk build (the partial 17 available on the site) and I'm trying to >> update/fix the opengl sample >> >> First of all, it looks like `jextract` doesn't accept anymore the option to >> produce an output jar. I had to manually compress the resulting folder to >> zip and rename, before importing in the target project. > > We decided to simplify jextract and focus on source code generation, > which seems to be the mode that most people want to work with, and it's > also the "more primitive": you can derive classes (and jars) from it. > > If you are using it in a project, you might consider directly checking > in the extracted sources in your project. If you are using an IDE, it is > going to improve your experience a little bit (the classfiles generated > by the old jextract were poorly understood by some of the IDEs out > there, which led to issues in indexing). > >> >> It'd be cool if jextract could output directly the jar (and the sources) >> >> Coming back to my issue, how can I retrieve the MethodHandler out of a >> non-static method? > > You mean you want to create a MethodHandle for an instance method? > > Let's see (I'll use jshell to make sure my code doesn't have any typos > :-) ): > > ``` > jshell> class Foo { > ?? ...> void greet(String msg) { System.out.println(msg); } > ?? ...> } >|? created class Foo > > jshell> import java.lang.invoke.*; > > jshell> MethodHandle greetMH = > MethodHandles.lookup().findVirtual(Foo.class, "greet", > MethodType.methodType(void.class, String.class)); > greetMH ==> MethodHandle(Foo,String)void > > jshell> greetMH.invoke(new Foo(), "Panama"); > Panama > ``` > I will add that intelliJ is able to do completion inside Lookup.findStatic, LookupfindVirtual, etc at the point when you write the string corresponding to the name, using Ctrl+Space complete the rest. > Is this what you were looking for? > > Cheers > Maurizio Regards, R?mi From mcimadamore at openjdk.java.net Thu Jun 3 09:47:52 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 3 Jun 2021 09:47:52 GMT Subject: [foreign-jextract] RFR: 8268160: jextract tool provider should avoid security manager usage In-Reply-To: References: Message-ID: On Thu, 3 Jun 2021 06:28:06 GMT, Athijegannathan Sundararajan wrote: > jextract is not incubated in JDK as of now. By the time it makes into JDK (if it does), security > manager would have been removed. Removing security manager usage in jextract code. Looks good ------------- Marked as reviewed by mcimadamore (Committer). PR: https://git.openjdk.java.net/panama-foreign/pull/546 From sundar at openjdk.java.net Thu Jun 3 09:55:44 2021 From: sundar at openjdk.java.net (Athijegannathan Sundararajan) Date: Thu, 3 Jun 2021 09:55:44 GMT Subject: [foreign-jextract] Integrated: 8268160: jextract tool provider should avoid security manager usage In-Reply-To: References: Message-ID: <2R6migwjAh-xVZR8orRDlSIdV_8EXZNB-bvgaDz741M=.564e25e4-5e90-411b-bcff-f0a82950014a@github.com> On Thu, 3 Jun 2021 06:28:06 GMT, Athijegannathan Sundararajan wrote: > jextract is not incubated in JDK as of now. By the time it makes into JDK (if it does), security > manager would have been removed. Removing security manager usage in jextract code. This pull request has now been integrated. Changeset: a7f6fc0e Author: Athijegannathan Sundararajan URL: https://git.openjdk.java.net/panama-foreign/commit/a7f6fc0ebf8eb08af5448db5c1e1dbf065367934 Stats: 9 lines in 1 file changed: 0 ins; 9 del; 0 mod 8268160: jextract tool provider should avoid security manager usage Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/546 From jvernee at openjdk.java.net Thu Jun 3 12:57:14 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 3 Jun 2021 12:57:14 GMT Subject: [foreign-memaccess+abi] RFR: 8268169: The system lookup can not find stdio functions such as printf on Windows 10 Message-ID: Hi, This patch adds a way to look up stdio functions such as printf on Windows 10 through the system lookup. A fallback library is used which forces the generation of these inline functions, and exposes them through a table of function pointers. Thanks, Jorn ------------- Commit messages: - Add fallback lookup library for functions not found in ucrtbase.dll (such as printf) Changes: https://git.openjdk.java.net/panama-foreign/pull/547/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=547&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268169 Stats: 276 lines in 5 files changed: 206 ins; 58 del; 12 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/547.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/547/head:pull/547 PR: https://git.openjdk.java.net/panama-foreign/pull/547 From mcimadamore at openjdk.java.net Thu Jun 3 13:32:57 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 3 Jun 2021 13:32:57 GMT Subject: [foreign-memaccess+abi] RFR: 8268169: The system lookup can not find stdio functions such as printf on Windows 10 In-Reply-To: References: Message-ID: On Thu, 3 Jun 2021 12:50:13 GMT, Jorn Vernee wrote: > Hi, > > This patch adds a way to look up stdio functions such as printf on Windows 10 through the system lookup. A fallback library is used which forces the generation of these inline functions, and exposes them through a table of function pointers. > > Thanks, > Jorn src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/SystemLookup.java line 174: > 172: private static final Map BY_NAME; > 173: > 174: static { Wouldn't Enum.valueOf achieve the same result here? src/jdk.incubator.foreign/windows/native/libWinFallbackLookup/WinFallbackLookup.c line 86: > 84: // time.h > 85: &gmtime > 86: }; Missing newline here test/jdk/java/foreign/StdLibTest.java line 158: > 156: static class StdLibHelper { > 157: > 158: final static SymbolLookup LOOKUP = CLinker.systemLookup(); Nice simplification! ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/547 From sundar at openjdk.java.net Thu Jun 3 15:24:55 2021 From: sundar at openjdk.java.net (Athijegannathan Sundararajan) Date: Thu, 3 Jun 2021 15:24:55 GMT Subject: [foreign-jextract] RFR: 8268183: tools/launcher/VersionCheck.java fails for jextract Message-ID: adding --version option. filtering warning line from -J-version ------------- Commit messages: - 8268183: tools/launcher/VersionCheck.java fails for jextract Changes: https://git.openjdk.java.net/panama-foreign/pull/548/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=548&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268183 Stats: 21 lines in 4 files changed: 21 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/548.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/548/head:pull/548 PR: https://git.openjdk.java.net/panama-foreign/pull/548 From mcimadamore at openjdk.java.net Thu Jun 3 15:47:58 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 3 Jun 2021 15:47:58 GMT Subject: [foreign-jextract] RFR: 8268183: tools/launcher/VersionCheck.java fails for jextract In-Reply-To: References: Message-ID: On Thu, 3 Jun 2021 15:17:00 GMT, Athijegannathan Sundararajan wrote: > adding --version option. filtering warning line from -J-version I'm not sure by this - in the sense that it seems simpler to just exclude jextract from the test. Adding a --version option doesn't seem very useful, at least at this stage? ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/548 From markehammons at gmail.com Thu Jun 3 15:51:29 2021 From: markehammons at gmail.com (Mark Hammons) Date: Thu, 3 Jun 2021 17:51:29 +0200 Subject: Slow Vectors? Message-ID: Hi all, I tried testing the incubator vector api today with the following code in JMH val panamaIntVecAdder = (a: Array[Int], b: Array[Int]) => { > var i = 0 > val nArr = Array.ofDim[Int](a.size) > val species = IntVector.SPECIES_PREFERRED > while i < a.size do > val m = species.indexInRange(i, a.length) > val va = IntVector.fromArray(species, a, i, m) > val vb = IntVector.fromArray(species, b, i, m) > > va.add(vb).intoArray(nArr, i, m) > i += species.length > ArraySeq.unsafeWrapArray(nArr) > } > It works, but it's very slow, averaging about 154.038 ns/op. The simplistic vector addition implementation I wrote beats it very easily, which I found very suprising. My current jdk is # VM version: JDK 16.0.1, OpenJDK 64-Bit Server VM, 16.0.1+9-24. Any idea what I'm doing wrong here? From sundar at openjdk.java.net Thu Jun 3 16:00:13 2021 From: sundar at openjdk.java.net (Athijegannathan Sundararajan) Date: Thu, 3 Jun 2021 16:00:13 GMT Subject: [foreign-jextract] RFR: 8268183: tools/launcher/VersionCheck.java fails for jextract [v2] In-Reply-To: References: Message-ID: > adding --version option. filtering warning line from -J-version Athijegannathan Sundararajan has updated the pull request incrementally with one additional commit since the last revision: removed --version as per code review. ------------- Changes: - all: https://git.openjdk.java.net/panama-foreign/pull/548/files - new: https://git.openjdk.java.net/panama-foreign/pull/548/files/0fe699c0..4e935f84 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=548&range=01 - incr: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=548&range=00-01 Stats: 15 lines in 3 files changed: 0 ins; 15 del; 0 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/548.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/548/head:pull/548 PR: https://git.openjdk.java.net/panama-foreign/pull/548 From mcimadamore at openjdk.java.net Thu Jun 3 16:14:55 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 3 Jun 2021 16:14:55 GMT Subject: [foreign-jextract] RFR: 8268183: tools/launcher/VersionCheck.java fails for jextract [v2] In-Reply-To: References: Message-ID: On Thu, 3 Jun 2021 16:00:13 GMT, Athijegannathan Sundararajan wrote: >> adding --version option. filtering warning line from -J-version > > Athijegannathan Sundararajan has updated the pull request incrementally with one additional commit since the last revision: > > removed --version as per code review. Looks good! ------------- Marked as reviewed by mcimadamore (Committer). PR: https://git.openjdk.java.net/panama-foreign/pull/548 From sundar at openjdk.java.net Thu Jun 3 16:20:50 2021 From: sundar at openjdk.java.net (Athijegannathan Sundararajan) Date: Thu, 3 Jun 2021 16:20:50 GMT Subject: [foreign-jextract] Integrated: 8268183: tools/launcher/VersionCheck.java fails for jextract In-Reply-To: References: Message-ID: On Thu, 3 Jun 2021 15:17:00 GMT, Athijegannathan Sundararajan wrote: > adding --version option. filtering warning line from -J-version This pull request has now been integrated. Changeset: fbdea883 Author: Athijegannathan Sundararajan URL: https://git.openjdk.java.net/panama-foreign/commit/fbdea883130449cbde33ad26f0bf409ba7e3969d Stats: 6 lines in 2 files changed: 6 ins; 0 del; 0 mod 8268183: tools/launcher/VersionCheck.java fails for jextract Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/548 From forax at univ-mlv.fr Thu Jun 3 16:33:33 2021 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 3 Jun 2021 18:33:33 +0200 (CEST) Subject: Slow Vectors? In-Reply-To: References: Message-ID: <232856734.471813.1622738013642.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Mark Hammons" > ?: "panama-dev at openjdk.java.net'" > Envoy?: Jeudi 3 Juin 2021 17:51:29 > Objet: Slow Vectors? > Hi all, > > I tried testing the incubator vector api today with the following code in > JMH > > val panamaIntVecAdder = (a: Array[Int], b: Array[Int]) => { >> var i = 0 >> val nArr = Array.ofDim[Int](a.size) >> val species = IntVector.SPECIES_PREFERRED >> while i < a.size do >> val m = species.indexInRange(i, a.length) >> val va = IntVector.fromArray(species, a, i, m) >> val vb = IntVector.fromArray(species, b, i, m) >> >> va.add(vb).intoArray(nArr, i, m) >> i += species.length >> ArraySeq.unsafeWrapArray(nArr) >> } >> > > It works, but it's very slow, averaging about 154.038 ns/op. The > simplistic vector addition implementation I wrote beats it very easily, > which I found very suprising. My current jdk is # VM version: JDK 16.0.1, > OpenJDK 64-Bit Server VM, 16.0.1+9-24. > > Any idea what I'm doing wrong here? reading and writing from a non constant mask is slow with Java 16, because it uses blend under the cover. using JMH, you can use hsdis [1] + JMH perfasm profiler to get the generated assembly code regards, R?mi [1] https://www.morling.dev/blog/building-hsdis-for-openjdk-15/ From jvernee at openjdk.java.net Thu Jun 3 17:25:46 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 3 Jun 2021 17:25:46 GMT Subject: [foreign-memaccess+abi] RFR: 8268169: The system lookup can not find stdio functions such as printf on Windows 10 In-Reply-To: References: Message-ID: On Thu, 3 Jun 2021 13:27:56 GMT, Maurizio Cimadamore wrote: >> Hi, >> >> This patch adds a way to look up stdio functions such as printf on Windows 10 through the system lookup. A fallback library is used which forces the generation of these inline functions, and exposes them through a table of function pointers. >> >> Thanks, >> Jorn > > src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/SystemLookup.java line 174: > >> 172: private static final Map BY_NAME; >> 173: >> 174: static { > > Wouldn't Enum.valueOf achieve the same result here? Right, I'm so used to the static map idiom for when the key is something else than the name that I didn't really think about using Enum.valueOf. I'll switch to using valueOf. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/547 From jvernee at openjdk.java.net Thu Jun 3 17:36:21 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 3 Jun 2021 17:36:21 GMT Subject: [foreign-memaccess+abi] RFR: 8268169: The system lookup can not find stdio functions such as printf on Windows 10 [v2] In-Reply-To: References: Message-ID: > Hi, > > This patch adds a way to look up stdio functions such as printf on Windows 10 through the system lookup. A fallback library is used which forces the generation of these inline functions, and exposes them through a table of function pointers. > > Thanks, > Jorn Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: Address review comments: - add missing newline at end of file - switch to valueOf instead of a static map ------------- Changes: - all: https://git.openjdk.java.net/panama-foreign/pull/547/files - new: https://git.openjdk.java.net/panama-foreign/pull/547/files/d6d896a8..daa560e7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=547&range=01 - incr: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=547&range=00-01 Stats: 10 lines in 2 files changed: 0 ins; 3 del; 7 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/547.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/547/head:pull/547 PR: https://git.openjdk.java.net/panama-foreign/pull/547 From leerho at gmail.com Thu Jun 3 19:50:19 2021 From: leerho at gmail.com (leerho) Date: Thu, 3 Jun 2021 12:50:19 -0700 Subject: Part 1 Proposal for JDK-8264594 In-Reply-To: References: <3857338c-b4ce-e559-bc75-6f06671989ba@oracle.com> <31fde1e0-7159-afb0-a79c-fa5e320e6844@oracle.com> <49091534-aa0f-81f7-2536-ff788e6377cf@oracle.com> <0b5ac260-4e87-4a92-53ca-b670a451f552@oracle.com> <50605287-4e54-7dde-14e5-d521c19301be@oracle.com> Message-ID: Maurizio, Here is the MemoryCopy class (w/o byte swap) and the TestMemoryCopy class (w/o testing byte swap). I copied from the TestMemoryAccess class in that I noticed that there is no package statement. I am not sure what @SuppressWarnings are allowed in your test environment, I suspect I should remove all of them. When the MemorySegment copyFrom(MemorySegment, MemoryLayout, ByteOrder) becomes available I can add the tests for that. *IMHO* I feel strongly that there is no need to additionally overload these methods with the segment offset specified in array index units. It is so trivial to convert from one to the other and it can be done easily in the method argument with a simple multiply by 2, 4 or 8. This should compile down to a simple shift, which becomes a single cycle CPU instruction. So this is not a performance issue. Furthermore, it is best that the user becomes accustomed to thinking of a segment fundamentally as an array of bytes. Once a segment is loaded with some primitive array, the segment loses the context of the type of the array it was loaded with; in effect, a kind of "type erasure" similar to Java's generics. This is one of the reasons that MemorySegments can be so powerful. I have been programming with the "MemorySegment" concept for a number of years now and find that keeping in mind that segments are just bytes is very useful. Let me know what you think. Lee. On Mon, May 31, 2021 at 6:56 AM Maurizio Cimadamore < maurizio.cimadamore at oracle.com> wrote: > Hi Lee, > this looks good. > > One thing I note is that there's an ambiguity as to whether the segment > index is expressed as a logical index, or a raw byte offset. Your snippet > does the latter. If we want to follow MemoryAccess, perhaps that calls for > 2 overloads (copyFromArrayAtIndex/copyFromArrayAtOffset), as I imagine both > could be useful, depending on the case? > > The javadoc will have to say something when the segment being used is > backed by the very array that is the source/target of the copy (we have > some text like that in MemorySegment::copyFrom). > > I think it would be helpful to progress further with this, add the > remaining templates (w/o ByteOrder, for now) test and see how it works in > practice. > > I will add (or just file a simple PR, so that you can just borrow from it > - should be a single method) something to do the segment copy with swap. > > Thanks! > Maurizio > On 28/05/2021 22:37, leerho wrote: > > Maurizio, > > Again sorry about the delay. > > Attached is a template proposal for the MemoryCopy class. > > I can't complete this without your proposed new copyFrom(...) method in > MemorySegment. As it is written, it should work, but without the byte swap > capability. > > I can complete the rest of the primitives like this template, if you would > like with javadocs. I could also start writing tests, but without the > byte-swap. > > Let me know what would be most helpful. > > Cheers, > > Lee > > > > > > > > > > > On Thu, May 20, 2021 at 11:36 AM leerho wrote: > >> Of course! >> >> On Thu, May 20, 2021 at 9:42 AM Maurizio Cimadamore < >> maurizio.cimadamore at oracle.com> wrote: >> >>> >>> On 20/05/2021 17:13, leerho wrote: >>> >>> I am not sure if the *dstSegSlice* requires the *srcCopyLen*. I would >>> hope that it is smart enough to realize that the input length is smaller >>> than the given offset minus the segment size. >>> >>> asSlice has an overload that just takes an offset and infers the >>> resulting size from there. >>> >>> But that doesn't seem what you want here - as you want the slice to have >>> a specific size (the size of the input array). >>> >>> MemorySegment::copyFrom wants the two segments to have the same size, so >>> I think you need that. >>> >>> In terms of performance, there's no difference between asSlice(offset) >>> and asSlice(offset, size) - you have to create a new segment anyway. >>> >>> Maurizio >>> >>> >>> From maurizio.cimadamore at oracle.com Thu Jun 3 20:25:56 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 3 Jun 2021 21:25:56 +0100 Subject: Part 1 Proposal for JDK-8264594 In-Reply-To: References: <3857338c-b4ce-e559-bc75-6f06671989ba@oracle.com> <31fde1e0-7159-afb0-a79c-fa5e320e6844@oracle.com> <49091534-aa0f-81f7-2536-ff788e6377cf@oracle.com> <0b5ac260-4e87-4a92-53ca-b670a451f552@oracle.com> <50605287-4e54-7dde-14e5-d521c19301be@oracle.com> Message-ID: <95c04a58-4897-0d49-3f13-d8aa6b293006@oracle.com> Thanks. While I agree that a segment is just a bunch of bytes, I think also think that having an API which takes two indices at the same time, one logical and one physical is kind of evil. I bet that a lot of developers will get that wrong, at least the first time. What you say about segments being an array of bytes, and thus not needing index-based overloads can also be said for MemoryAccess class - but I believe that the index-based accessors in the are quite popular. But overall, my worry is not performances, or symmetry with respect to other APIs - my main worry is what I said above: that people will just assume that indices are logical for both the segment and the array - so overloads with clearly different names should help quite a bit IMHO. Maurizio On 03/06/2021 20:50, leerho wrote: > Maurizio, > Here is the MemoryCopy class (w/o byte swap) and the TestMemoryCopy > class (w/o testing byte swap). > > I copied from the TestMemoryAccess class in that I noticed that there > is no package statement.? I am not sure what?@SuppressWarnings are > allowed in your test environment, I suspect I should remove all of them. > > When the MemorySegment?copyFrom(MemorySegment, MemoryLayout, > ByteOrder) becomes available I can add the tests for that. > > *IMHO* > > I feel strongly that there is no need to additionally overload > these methods with the segment offset specified in array index > units.? It is so trivial to convert from one to the other and it > can be done easily in the method argument?with a simple > multiply?by 2, 4 or 8. This should compile down to a simple shift, > which becomes a single cycle CPU instruction.? So this?is not a > performance issue. > > Furthermore, it is best that the user becomes accustomed to > thinking of a segment fundamentally as an array of bytes.? Once a > segment is loaded with some primitive array, the segment loses the > context of the type of the array it was loaded with; in effect, a > kind of "type erasure" similar to Java's generics.? This is one of > the reasons that MemorySegments can be so powerful. > > > I have been programming with the "MemorySegment" concept for a > number of years now and find that keeping in mind that segments > are just bytes is very useful. > > > Let me know what you think. > > Lee. > > > > On Mon, May 31, 2021 at 6:56 AM Maurizio Cimadamore > > wrote: > > Hi Lee, > this looks good. > > One thing I note is that there's an ambiguity as to whether the > segment index is expressed as a logical index, or a raw byte > offset. Your snippet does the latter. If we want to follow > MemoryAccess, perhaps that calls for 2 overloads > (copyFromArrayAtIndex/copyFromArrayAtOffset), as I imagine both > could be useful, depending on the case? > > The javadoc will have to say something when the segment being used > is backed by the very array that is the source/target of the copy > (we have some text like that in MemorySegment::copyFrom). > > I think it would be helpful to progress further with this, add the > remaining templates (w/o ByteOrder, for now) test and see how it > works in practice. > > I will add (or just file a simple PR, so that you can just borrow > from it - should be a single method) something to do the segment > copy with swap. > > Thanks! > Maurizio > > On 28/05/2021 22:37, leerho wrote: >> Maurizio, >> >> Again sorry about the delay. >> >> Attached is a template proposal for the MemoryCopy class. >> >> I can't complete this without your proposed new copyFrom(...) >> method in MemorySegment.?As it is written, it should work, but >> without the byte swap capability. >> >> I can complete the rest of the primitives like this template, if >> you would like with javadocs.? I could also start writing tests, >> but without the byte-swap. >> >> Let me know what would be most?helpful. >> >> Cheers, >> >> Lee >> >> >> >> >> >> >> >> >> >> >> On Thu, May 20, 2021 at 11:36 AM leerho > > wrote: >> >> Of?course! >> >> On Thu, May 20, 2021 at 9:42 AM Maurizio Cimadamore >> > > wrote: >> >> >> On 20/05/2021 17:13, leerho wrote: >>> I am not sure if the /dstSegSlice/ requires the >>> /srcCopyLen/. I would hope that it is smart enough to >>> realize that the input length is smaller than the given >>> offset minus the segment size. >> >> asSlice has an overload that just takes an offset and >> infers the resulting size from there. >> >> But that doesn't seem what you want here - as you want >> the slice to have a specific size (the size of the input >> array). >> >> MemorySegment::copyFrom wants the two segments to have >> the same size, so I think you need that. >> >> In terms of performance, there's no difference between >> asSlice(offset) and asSlice(offset, size) - you have to >> create a new segment anyway. >> >> Maurizio >> >> From paul.sandoz at oracle.com Thu Jun 3 22:50:24 2021 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 3 Jun 2021 22:50:24 +0000 Subject: Slow Vectors? In-Reply-To: <232856734.471813.1622738013642.JavaMail.zimbra@u-pem.fr> References: <232856734.471813.1622738013642.JavaMail.zimbra@u-pem.fr> Message-ID: <9C1B8431-9246-4BB6-94C3-B8A2AEEE0637@oracle.com> Hi Remi, In this case it's not related to blend, it's related to production of the mask, indexInRange, and use of the mask when storing. We have yet to focus on optimizing them, esp within loops. For storing we need to be especially careful when a mask bit is set and if ignored would result in an out-of-bounds array access. There is ongoing work in the branch https://github.com/openjdk/panama-vector/tree/vectorIntrinsics+mask that should bring some improvements, esp. for architectures that support mask registers. Paul. > On Jun 3, 2021, at 9:33 AM, Remi Forax wrote: > > ----- Mail original ----- >> De: "Mark Hammons" >> ?: "panama-dev at openjdk.java.net'" >> Envoy?: Jeudi 3 Juin 2021 17:51:29 >> Objet: Slow Vectors? > >> Hi all, >> >> I tried testing the incubator vector api today with the following code in >> JMH >> >> val panamaIntVecAdder = (a: Array[Int], b: Array[Int]) => { >>> var i = 0 >>> val nArr = Array.ofDim[Int](a.size) >>> val species = IntVector.SPECIES_PREFERRED >>> while i < a.size do >>> val m = species.indexInRange(i, a.length) >>> val va = IntVector.fromArray(species, a, i, m) >>> val vb = IntVector.fromArray(species, b, i, m) >>> >>> va.add(vb).intoArray(nArr, i, m) >>> i += species.length >>> ArraySeq.unsafeWrapArray(nArr) >>> } >>> >> >> It works, but it's very slow, averaging about 154.038 ns/op. The >> simplistic vector addition implementation I wrote beats it very easily, >> which I found very suprising. My current jdk is # VM version: JDK 16.0.1, >> OpenJDK 64-Bit Server VM, 16.0.1+9-24. >> >> Any idea what I'm doing wrong here? > > reading and writing from a non constant mask is slow with Java 16, > because it uses blend under the cover. > > using JMH, you can use hsdis [1] + JMH perfasm profiler to get the generated assembly code > > regards, > R?mi > > [1] https://www.morling.dev/blog/building-hsdis-for-openjdk-15/ From leerho at gmail.com Fri Jun 4 00:32:25 2021 From: leerho at gmail.com (leerho) Date: Thu, 3 Jun 2021 17:32:25 -0700 Subject: Part 1 Proposal for JDK-8264594 In-Reply-To: <95c04a58-4897-0d49-3f13-d8aa6b293006@oracle.com> References: <3857338c-b4ce-e559-bc75-6f06671989ba@oracle.com> <31fde1e0-7159-afb0-a79c-fa5e320e6844@oracle.com> <49091534-aa0f-81f7-2536-ff788e6377cf@oracle.com> <0b5ac260-4e87-4a92-53ca-b670a451f552@oracle.com> <50605287-4e54-7dde-14e5-d521c19301be@oracle.com> <95c04a58-4897-0d49-3f13-d8aa6b293006@oracle.com> Message-ID: When I first saw all the logical index overloads in MemoryAccess I shuddered. It is a lot of API clutter as far as I?m concerned. But just because we made that mistake with MemoryAccess doesn?t mean we have to continue propagating it. Also I have explicitly named the two offsets very differently to try to make it clear that they are very different. I guess I could go further and name the ?srcIndex? -> ?srcIndexLongs? for the long array case, for example. But since ?index? is used elsewhere as the logical index I assumed that this would not be necessary. But I would much rather use longer, more explicit names than propagate API clutter. Lee On Thu, Jun 3, 2021 at 1:26 PM Maurizio Cimadamore < maurizio.cimadamore at oracle.com> wrote: > Thanks. > > While I agree that a segment is just a bunch of bytes, I think also think > that having an API which takes two indices at the same time, one logical > and one physical is kind of evil. I bet that a lot of developers will get > that wrong, at least the first time. > > What you say about segments being an array of bytes, and thus not needing > index-based overloads can also be said for MemoryAccess class - but I > believe that the index-based accessors in the are quite popular. > > But overall, my worry is not performances, or symmetry with respect to > other APIs - my main worry is what I said above: that people will just > assume that indices are logical for both the segment and the array - so > overloads with clearly different names should help quite a bit IMHO. > > > Maurizio > On 03/06/2021 20:50, leerho wrote: > > Maurizio, > Here is the MemoryCopy class (w/o byte swap) and the TestMemoryCopy class > (w/o testing byte swap). > > I copied from the TestMemoryAccess class in that I noticed that there is > no package statement. I am not sure what @SuppressWarnings are allowed in > your test environment, I suspect I should remove all of them. > > When the MemorySegment copyFrom(MemorySegment, MemoryLayout, ByteOrder) > becomes available I can add the tests for that. > > *IMHO* > > I feel strongly that there is no need to additionally overload these > methods with the segment offset specified in array index units. It is so > trivial to convert from one to the other and it can be done easily in the > method argument with a simple multiply by 2, 4 or 8. This should compile > down to a simple shift, which becomes a single cycle CPU instruction. So > this is not a performance issue. > > Furthermore, it is best that the user becomes accustomed to thinking of a > segment fundamentally as an array of bytes. Once a segment is loaded with > some primitive array, the segment loses the context of the type of the > array it was loaded with; in effect, a kind of "type erasure" similar to > Java's generics. This is one of the reasons that MemorySegments can be so > powerful. > > > I have been programming with the "MemorySegment" concept for a number of > years now and find that keeping in mind that segments are just bytes is > very useful. > > > Let me know what you think. > > Lee. > > > > On Mon, May 31, 2021 at 6:56 AM Maurizio Cimadamore < > maurizio.cimadamore at oracle.com> wrote: > >> Hi Lee, >> this looks good. >> >> One thing I note is that there's an ambiguity as to whether the segment >> index is expressed as a logical index, or a raw byte offset. Your snippet >> does the latter. If we want to follow MemoryAccess, perhaps that calls for >> 2 overloads (copyFromArrayAtIndex/copyFromArrayAtOffset), as I imagine both >> could be useful, depending on the case? >> >> The javadoc will have to say something when the segment being used is >> backed by the very array that is the source/target of the copy (we have >> some text like that in MemorySegment::copyFrom). >> >> I think it would be helpful to progress further with this, add the >> remaining templates (w/o ByteOrder, for now) test and see how it works in >> practice. >> >> I will add (or just file a simple PR, so that you can just borrow from it >> - should be a single method) something to do the segment copy with swap. >> >> Thanks! >> Maurizio >> On 28/05/2021 22:37, leerho wrote: >> >> Maurizio, >> >> Again sorry about the delay. >> >> Attached is a template proposal for the MemoryCopy class. >> >> I can't complete this without your proposed new copyFrom(...) method in >> MemorySegment. As it is written, it should work, but without the byte swap >> capability. >> >> I can complete the rest of the primitives like this template, if you >> would like with javadocs. I could also start writing tests, but without >> the byte-swap. >> >> Let me know what would be most helpful. >> >> Cheers, >> >> Lee >> >> >> >> >> >> >> >> >> >> >> On Thu, May 20, 2021 at 11:36 AM leerho wrote: >> >>> Of course! >>> >>> On Thu, May 20, 2021 at 9:42 AM Maurizio Cimadamore < >>> maurizio.cimadamore at oracle.com> wrote: >>> >>>> >>>> On 20/05/2021 17:13, leerho wrote: >>>> >>>> I am not sure if the *dstSegSlice* requires the *srcCopyLen*. I would >>>> hope that it is smart enough to realize that the input length is smaller >>>> than the given offset minus the segment size. >>>> >>>> asSlice has an overload that just takes an offset and infers the >>>> resulting size from there. >>>> >>>> But that doesn't seem what you want here - as you want the slice to >>>> have a specific size (the size of the input array). >>>> >>>> MemorySegment::copyFrom wants the two segments to have the same size, >>>> so I think you need that. >>>> >>>> In terms of performance, there's no difference between asSlice(offset) >>>> and asSlice(offset, size) - you have to create a new segment anyway. >>>> >>>> Maurizio >>>> >>>> >>>> -- >From my cell phone. From njian at openjdk.java.net Fri Jun 4 02:35:14 2021 From: njian at openjdk.java.net (Ningsheng Jian) Date: Fri, 4 Jun 2021 02:35:14 GMT Subject: [vectorIntrinsics+mask] RFR: Merge panama-vector:vectorIntrinsics In-Reply-To: <-CRodaLtIXMf0zpvj2eGdg8GKsnvGFJ1HZ5lw_4cq6c=.8e550d09-f8ea-48ce-86c0-520e317e61ea@github.com> References: <-CRodaLtIXMf0zpvj2eGdg8GKsnvGFJ1HZ5lw_4cq6c=.8e550d09-f8ea-48ce-86c0-520e317e61ea@github.com> Message-ID: On Thu, 3 Jun 2021 09:14:07 GMT, Xiaohong Gong wrote: > Merge with panama-vector:vectorIntrinsics. Tested tier1 and Vector API tests on both x86 and aarch64. I see tier1 and test/jdk/jdk/incubator/vector tests passed in our test system. ------------- Marked as reviewed by njian (Committer). PR: https://git.openjdk.java.net/panama-vector/pull/89 From xgong at openjdk.java.net Fri Jun 4 03:24:29 2021 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Fri, 4 Jun 2021 03:24:29 GMT Subject: [vectorIntrinsics+mask] RFR: Merge panama-vector:vectorIntrinsics [v2] In-Reply-To: <-CRodaLtIXMf0zpvj2eGdg8GKsnvGFJ1HZ5lw_4cq6c=.8e550d09-f8ea-48ce-86c0-520e317e61ea@github.com> References: <-CRodaLtIXMf0zpvj2eGdg8GKsnvGFJ1HZ5lw_4cq6c=.8e550d09-f8ea-48ce-86c0-520e317e61ea@github.com> Message-ID: > Merge with panama-vector:vectorIntrinsics. Tested tier1 and Vector API tests on both x86 and aarch64. Xiaohong Gong has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: - Merge panama-vector:vectorIntrinsics - 8266621: Add masking support for unary/ternary vector intrinsics Reviewed-by: psandoz, vlivanov - 8264563: Add masked vector intrinsics for binary/store operations Co-authored-by: Ningsheng Jian Reviewed-by: jbhateja, sviswanathan, vlivanov, whuang - 8265109: SVE predicate register allocation support for vectorIntrinsics Reviewed-by: sviswanathan - Merge panama-vector:vectorIntrinsics ------------- Changes: https://git.openjdk.java.net/panama-vector/pull/89/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=89&range=01 Stats: 3808 lines in 68 files changed: 2698 ins; 471 del; 639 mod Patch: https://git.openjdk.java.net/panama-vector/pull/89.diff Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/89/head:pull/89 PR: https://git.openjdk.java.net/panama-vector/pull/89 From xgong at openjdk.java.net Fri Jun 4 03:24:35 2021 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Fri, 4 Jun 2021 03:24:35 GMT Subject: [vectorIntrinsics+mask] Integrated: Merge panama-vector:vectorIntrinsics In-Reply-To: <-CRodaLtIXMf0zpvj2eGdg8GKsnvGFJ1HZ5lw_4cq6c=.8e550d09-f8ea-48ce-86c0-520e317e61ea@github.com> References: <-CRodaLtIXMf0zpvj2eGdg8GKsnvGFJ1HZ5lw_4cq6c=.8e550d09-f8ea-48ce-86c0-520e317e61ea@github.com> Message-ID: On Thu, 3 Jun 2021 09:14:07 GMT, Xiaohong Gong wrote: > Merge with panama-vector:vectorIntrinsics. Tested tier1 and Vector API tests on both x86 and aarch64. This pull request has now been integrated. Changeset: 44082753 Author: Xiaohong Gong URL: https://git.openjdk.java.net/panama-vector/commit/440827537d36818d6a9ec55cc9841a98ef09c78e Stats: 661580 lines in 7192 files changed: 100205 ins; 539586 del; 21789 mod Merge panama-vector:vectorIntrinsics Reviewed-by: njian ------------- PR: https://git.openjdk.java.net/panama-vector/pull/89 From whuang at openjdk.java.net Fri Jun 4 07:13:11 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Fri, 4 Jun 2021 07:13:11 GMT Subject: [vectorIntrinsics] RFR: 8266720: Wrong implementation in LibraryCallKit::inline_vector_shuffle_iota [v3] In-Reply-To: References: Message-ID: On Thu, 13 May 2021 15:48:06 GMT, Paul Sandoz wrote: >> Thank you for you review. I think this test is used for any arch which has `ByteVector.SPECIES_MAX == 1024`. > > But we know which arches don't support, x86, PPC etc. > > I am unsure why existing shuffle tests do not catch this problem. In fact i would prefer we focus on that if we can rather than adding a specific test. Would you mind looking to see if see if we can expand on the existing `shuffleTest`? * Q : Why existing shuffle tests do not catch this problem? * A: Because we need `vector_length >= 1024`. However, in x86 we don't have this env because the longest register of x86 is 512 in AVX512. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/81 From xgong at openjdk.java.net Fri Jun 4 07:42:07 2021 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Fri, 4 Jun 2021 07:42:07 GMT Subject: [vectorIntrinsics] RFR: 8266720: Wrong implementation in LibraryCallKit::inline_vector_shuffle_iota [v3] In-Reply-To: References: <1YWES0jFg8uA3GLedDyEbUq-jhROJOIDXoml4RZ3zkw=.2bc9a3c9-1d94-4790-8678-f1f0809ea584@github.com> Message-ID: On Thu, 3 Jun 2021 03:24:06 GMT, Wang Huang wrote: >> src/hotspot/share/opto/vectorIntrinsics.cpp line 467: >> >>> 465: } else { >>> 466: // Currently it works well for vector_length <= 1024-bits. >>> 467: // for vector_length > 1024, we don't support now >> >> Does it need any vector length check or block for vector length >1024? > > Thank you for your review. It is a problem here. I will do that in next commit. As discussed with @nsjian , can we currently make it unsupported as well for 1024-bits? It doesn't need to change any IR if 1024-bits is not supported. We can revisit this issue in future for vector length >= 1024-bits ------------- PR: https://git.openjdk.java.net/panama-vector/pull/81 From maurizio.cimadamore at oracle.com Fri Jun 4 09:33:56 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 4 Jun 2021 10:33:56 +0100 Subject: Part 1 Proposal for JDK-8264594 In-Reply-To: References: <49091534-aa0f-81f7-2536-ff788e6377cf@oracle.com> <0b5ac260-4e87-4a92-53ca-b670a451f552@oracle.com> <50605287-4e54-7dde-14e5-d521c19301be@oracle.com> <95c04a58-4897-0d49-3f13-d8aa6b293006@oracle.com> Message-ID: <87a484de-9cdc-ddc7-ff73-6dad2641d5a4@oracle.com> On 04/06/2021 01:32, leerho wrote: > When I first saw all the logical index overloads in MemoryAccess I > shuddered.? It is a lot of API clutter as far as I?m concerned.? But > just because we made that mistake with MemoryAccess doesn?t mean we > have to continue propagating it. I'm sorry, I just don't see that as being a "mistake". Code like this: ``` for (int i = 0 ; i < limit ; i++) { ?? long val = MemoryAccess.getLongAtIndex(segment, i); ?? ... } ``` Is _extremely_ common. While it's true that memory segment is an unbiased array of bytes, there are times you want to access it in a more structured form - and saying "you can't do that" because it adds overloads doesn't seem like a great solution to me. > > Also I have explicitly named the two offsets very differently to try > to make it clear that they are very different.? I guess I could go > further and name the ?srcIndex? -> ?srcIndexLongs? for the long array > case, for example.? But since ?index? is used elsewhere as the logical > index I assumed that this would not be necessary. > > But I would much rather use longer, more explicit names than propagate > API clutter. I was thinking overnight that, perhaps, the memory copy and the single element cases are different. When you do single access (see above) you do that frequently in a loop - and you often get elements of the same type. As stated above, asking developers to work in terms of offsets seems a bit odd, when they are really accessing a flat array of element type T. In the case of bulk copy, I don't think there's the same degree of pressure - you will probably call the bulk copy at the beginning, or at the end of your computation (or both ends!) - and having an offset shift is more tolerable. So, I'm open to evaluating something more minimal, and see how far we can get with it. Maurizio > > Lee > > On Thu, Jun 3, 2021 at 1:26 PM Maurizio Cimadamore > > wrote: > > Thanks. > > While I agree that a segment is just a bunch of bytes, I think > also think that having an API which takes two indices at the same > time, one logical and one physical is kind of evil. I bet that a > lot of developers will get that wrong, at least the first time. > > What you say about segments being an array of bytes, and thus not > needing index-based overloads can also be said for MemoryAccess > class - but I believe that the index-based accessors in the are > quite popular. > > But overall, my worry is not performances, or symmetry with > respect to other APIs - my main worry is what I said above: that > people will just assume that indices are logical for both the > segment and the array - so overloads with clearly different names > should help quite a bit IMHO. > > > Maurizio > > On 03/06/2021 20:50, leerho wrote: >> Maurizio, >> Here is the MemoryCopy class (w/o byte swap) and the >> TestMemoryCopy class (w/o testing byte swap). >> >> I copied from the TestMemoryAccess class in that I noticed that >> there is no package statement.? I am not sure >> what?@SuppressWarnings are allowed in your test environment, I >> suspect I should remove all of them. >> >> When the MemorySegment?copyFrom(MemorySegment, MemoryLayout, >> ByteOrder) becomes available I can add the tests for that. >> >> *IMHO* >> >> I feel strongly that there is no need to additionally >> overload these methods with the segment offset specified in >> array index units.? It is so trivial to convert from one to >> the other and it can be done easily in the method >> argument?with a simple multiply?by 2, 4 or 8. This should >> compile down to a simple shift, which becomes a single cycle >> CPU instruction.? So this?is not a performance issue. >> >> Furthermore, it is best that the user becomes accustomed to >> thinking of a segment fundamentally as an array of bytes.? >> Once a segment is loaded with some primitive array, the >> segment loses the context of the type of the array it was >> loaded with; in effect, a kind of "type erasure" similar to >> Java's generics.? This is one of the reasons that >> MemorySegments can be so powerful. >> >> >> I have been programming with the "MemorySegment" concept for >> a number of years now and find that keeping in mind that >> segments are just bytes is very useful. >> >> >> Let me know what you think. >> >> Lee. >> >> >> >> On Mon, May 31, 2021 at 6:56 AM Maurizio Cimadamore >> > > wrote: >> >> Hi Lee, >> this looks good. >> >> One thing I note is that there's an ambiguity as to whether >> the segment index is expressed as a logical index, or a raw >> byte offset. Your snippet does the latter. If we want to >> follow MemoryAccess, perhaps that calls for 2 overloads >> (copyFromArrayAtIndex/copyFromArrayAtOffset), as I imagine >> both could be useful, depending on the case? >> >> The javadoc will have to say something when the segment being >> used is backed by the very array that is the source/target of >> the copy (we have some text like that in >> MemorySegment::copyFrom). >> >> I think it would be helpful to progress further with this, >> add the remaining templates (w/o ByteOrder, for now) test and >> see how it works in practice. >> >> I will add (or just file a simple PR, so that you can just >> borrow from it - should be a single method) something to do >> the segment copy with swap. >> >> Thanks! >> Maurizio >> >> On 28/05/2021 22:37, leerho wrote: >>> Maurizio, >>> >>> Again sorry about the delay. >>> >>> Attached is a template proposal for the MemoryCopy class. >>> >>> I can't complete this without your proposed new >>> copyFrom(...) method in MemorySegment.?As it is written, it >>> should work, but without the byte swap capability. >>> >>> I can complete the rest of the primitives like this >>> template, if you would like with javadocs.? I could also >>> start writing tests, but without the byte-swap. >>> >>> Let me know what would be most?helpful. >>> >>> Cheers, >>> >>> Lee >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Thu, May 20, 2021 at 11:36 AM leerho >> > wrote: >>> >>> Of?course! >>> >>> On Thu, May 20, 2021 at 9:42 AM Maurizio Cimadamore >>> >> > wrote: >>> >>> >>> On 20/05/2021 17:13, leerho wrote: >>>> I am not sure if the /dstSegSlice/ requires the >>>> /srcCopyLen/. I would hope that it is smart enough >>>> to realize that the input length is smaller than >>>> the given offset minus the segment size. >>> >>> asSlice has an overload that just takes an offset >>> and infers the resulting size from there. >>> >>> But that doesn't seem what you want here - as you >>> want the slice to have a specific size (the size of >>> the input array). >>> >>> MemorySegment::copyFrom wants the two segments to >>> have the same size, so I think you need that. >>> >>> In terms of performance, there's no difference >>> between asSlice(offset) and asSlice(offset, size) - >>> you have to create a new segment anyway. >>> >>> Maurizio >>> >>> > -- > From my cell phone. From duke at openjdk.java.net Fri Jun 4 11:04:22 2021 From: duke at openjdk.java.net (duke) Date: Fri, 4 Jun 2021 11:04:22 GMT Subject: git: openjdk/panama-foreign: master: 45 new changesets Message-ID: <910f984c-a13b-4bc6-979c-733920808414@openjdk.org> Changeset: 40d23a0c Author: Weijun Wang Date: 2021-06-02 15:47:57 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/40d23a0c0b955ae4636800be183da7a71665f79f 8267543: Post JEP 411 refactoring: security Reviewed-by: mullan ! src/java.base/share/classes/com/sun/crypto/provider/JceKeyStore.java ! src/java.base/share/classes/java/security/KeyStore.java ! src/java.base/share/classes/java/security/Security.java ! src/java.base/share/classes/javax/crypto/ProviderVerifier.java ! src/java.base/share/classes/sun/security/jca/ProviderConfig.java ! src/java.base/share/classes/sun/security/provider/MD4.java ! src/java.base/share/classes/sun/security/provider/SunEntries.java ! src/java.base/share/classes/sun/security/ssl/SSLEngineImpl.java ! src/java.base/share/classes/sun/security/util/AnchorCertificates.java ! src/java.base/share/classes/sun/security/util/KeyStoreDelegator.java ! src/java.base/share/classes/sun/security/util/UntrustedCertificates.java ! src/java.management/share/classes/com/sun/jmx/remote/security/JMXPluggableAuthenticator.java ! src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5Context.java ! src/java.security.jgss/share/classes/sun/security/jgss/wrapper/SunNativeProvider.java ! src/java.security.jgss/share/classes/sun/security/krb5/internal/ccache/FileCredentialsCache.java ! src/java.smartcardio/unix/classes/sun/security/smartcardio/PlatformPCSC.java ! src/java.xml.crypto/share/classes/com/sun/org/slf4j/internal/Logger.java ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java ! src/jdk.crypto.mscapi/windows/classes/sun/security/mscapi/SunMSCAPI.java Changeset: 508cec75 Author: Weijun Wang Date: 2021-06-02 15:48:50 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/508cec7535cd0ad015d566389bc9e5f53ce4103b 8267521: Post JEP 411 refactoring: maximum covering > 50K Reviewed-by: dfuchs, prr ! src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java ! src/java.base/share/classes/sun/net/ftp/impl/FtpClient.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageReader.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageWriter.java ! src/java.desktop/share/classes/java/awt/Component.java ! src/java.desktop/share/classes/java/awt/Container.java ! src/java.desktop/share/classes/java/awt/DefaultKeyboardFocusManager.java ! src/java.desktop/share/classes/java/awt/Toolkit.java ! src/java.desktop/share/classes/java/awt/Window.java ! src/java.desktop/share/classes/javax/swing/RepaintManager.java ! src/java.desktop/share/classes/sun/awt/SunToolkit.java ! src/java.desktop/share/classes/sun/font/SunFontManager.java ! src/java.desktop/share/classes/sun/print/PSPrinterJob.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java ! src/java.logging/share/classes/java/util/logging/LogManager.java ! src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnector.java ! src/jdk.accessibility/windows/classes/com/sun/java/accessibility/internal/AccessBridge.java ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11.java Changeset: 56b65e4a Author: Brian Burkhalter Date: 2021-06-02 16:33:21 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/56b65e4a8d519801d170e16063ccb7dd3069c4be 8267569: java.io.File.equals contains misleading Javadoc Reviewed-by: alanb, dfuchs, bchristi, naoto ! src/java.base/share/classes/java/io/File.java Changeset: e1462e79 Author: Jonathan Gibbons Date: 2021-06-02 16:56:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e1462e79df7c22f3e09fa453c7887b6f51ef3dbb 8267176: StandardDoclet should provide access to Reporter and Locale Reviewed-by: hannesw ! src/jdk.javadoc/share/classes/jdk/javadoc/doclet/StandardDoclet.java ! test/langtools/jdk/javadoc/doclet/testDiagsLineCaret/MyTaglet.java ! test/langtools/jdk/javadoc/doclet/testDiagsLineCaret/TestDiagsLineCaret.java Changeset: b7ac705d Author: Guoxiong Li Committer: Vicente Romero Date: 2021-06-02 17:17:31 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b7ac705dd625c5fb2df714e2faec8d0ffac7301a 8263642: javac emits duplicate checkcast for first bound of intersection type in cast Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransTypes.java + test/langtools/tools/javac/cast/intersection/DuplicatedCheckcastTest.java Changeset: 1ae934e0 Author: Erik Gahlin Date: 2021-06-02 17:25:42 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1ae934e09d1a55bce4079153d3bfccd30657a0ea 8263332: JFR: Dump recording from a recording stream Reviewed-by: mgronlun ! src/hotspot/share/jfr/recorder/repository/jfrChunk.cpp ! src/hotspot/share/jfr/recorder/repository/jfrChunkWriter.cpp ! src/jdk.jfr/share/classes/jdk/jfr/consumer/RecordingStream.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/MetadataRepository.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/PlatformRecorder.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/PlatformRecording.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/Repository.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/RepositoryChunk.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/Utils.java ! src/jdk.management.jfr/share/classes/jdk/management/jfr/DiskRepository.java + src/jdk.management.jfr/share/classes/jdk/management/jfr/FileDump.java ! src/jdk.management.jfr/share/classes/jdk/management/jfr/RemoteRecordingStream.java + test/jdk/jdk/jfr/api/consumer/recordingstream/TestDump.java + test/jdk/jdk/jfr/jmx/streaming/TestRemoteDump.java Changeset: ecf6112a Author: Ioi Lam Date: 2021-06-02 19:05:42 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ecf6112a217e7d5d504a7272111d1ac72745d8f8 8267958: [TESTBUG] cds DynamicLoaderConstraintsTest.java timed out Reviewed-by: ccheung, jiefu ! test/hotspot/jtreg/runtime/cds/appcds/loaderConstraints/DynamicLoaderConstraintsTest.java ! test/hotspot/jtreg/runtime/cds/appcds/loaderConstraints/LoaderConstraintsTest.java Changeset: a8835b9c Author: Ioi Lam Date: 2021-06-02 19:20:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a8835b9c08af1438c80144bad7506fb5700511a3 8267879: ClassLoaderMetaspace destructor asserts on !_frozen Reviewed-by: dholmes, coleenp ! src/hotspot/share/cds/metaspaceShared.cpp ! src/hotspot/share/memory/classLoaderMetaspace.cpp ! src/hotspot/share/memory/metaspace.cpp ! src/hotspot/share/memory/metaspace.hpp Changeset: 375f8f3b Author: Erik Gahlin Date: 2021-06-02 19:43:36 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/375f8f3bffa7bc68a4c355195caa9d633d1cf120 8268138: docs build error after JDK-8263332 integration Reviewed-by: mgronlun ! src/jdk.jfr/share/classes/jdk/jfr/consumer/RecordingStream.java ! src/jdk.management.jfr/share/classes/jdk/management/jfr/RemoteRecordingStream.java Changeset: 3482cb87 Author: Jonathan Gibbons Date: 2021-06-02 21:20:12 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3482cb87fd94e6445ca243722851daa90c00a2c8 8266254: Update to use jtreg 6 8265020: tests must be updated for new TestNG module name Reviewed-by: lancea, erikj, mchung, naoto, alanb, iris, chegar ! make/conf/jib-profiles.js ! test/hotspot/jtreg/TEST.ROOT ! test/jaxp/TEST.ROOT ! test/jdk/TEST.ROOT ! test/jdk/java/lang/ModuleTests/addXXX/test/module-info.java ! test/jdk/java/lang/invoke/MethodHandles/privateLookupIn/test/module-info.java ! test/jdk/java/lang/invoke/modules/m1/module-info.java ! test/jdk/java/lang/invoke/modules/m3/module-info.java ! test/jdk/java/util/ServiceLoader/security/test/module-info.java ! test/langtools/TEST.ROOT ! test/lib-test/TEST.ROOT Changeset: 136badb1 Author: Valerie Peng Date: 2021-06-02 21:31:57 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/136badb1f7b0ba1d16fcf0deca5899e0d0186fc0 8248268: Support KWP in addition to KW Reviewed-by: xuelei + src/java.base/share/classes/com/sun/crypto/provider/AESKeyWrap.java + src/java.base/share/classes/com/sun/crypto/provider/AESKeyWrapPadded.java ! src/java.base/share/classes/com/sun/crypto/provider/AESParameters.java - src/java.base/share/classes/com/sun/crypto/provider/AESWrapCipher.java ! src/java.base/share/classes/com/sun/crypto/provider/BlockCipherParamsCore.java ! src/java.base/share/classes/com/sun/crypto/provider/ConstructKeys.java + src/java.base/share/classes/com/sun/crypto/provider/KWUtil.java + src/java.base/share/classes/com/sun/crypto/provider/KeyWrapCipher.java ! src/java.base/share/classes/com/sun/crypto/provider/SunJCE.java ! src/java.base/share/classes/sun/security/util/KnownOIDs.java ! src/java.base/share/classes/sun/security/util/SecurityProviderConstants.java ! test/jdk/com/sun/crypto/provider/Cipher/KeyWrap/NISTWrapKAT.java ! test/jdk/com/sun/crypto/provider/Cipher/KeyWrap/TestCipherKeyWrapperTest.java + test/jdk/com/sun/crypto/provider/Cipher/KeyWrap/TestGeneral.java + test/jdk/com/sun/crypto/provider/Cipher/KeyWrap/TestKeySizeCheck.java ! test/jdk/com/sun/crypto/provider/NSASuiteB/TestAESWrapOids.java ! test/jdk/javax/crypto/Cipher/TestCipherMode.java + test/micro/org/openjdk/bench/javax/crypto/full/AESKeyWrapBench.java Changeset: 76fdf2c8 Author: Daniel D. Daugherty Date: 2021-06-02 21:50:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/76fdf2c89bb7df9140438fcbaf16ea5fda024551 8268146: fix for JDK-8266254 fails validate-source Reviewed-by: psandoz, wetmore ! test/lib-test/TEST.ROOT Changeset: d46a2c8e Author: Jonathan Gibbons Date: 2021-06-02 22:33:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d46a2c8ecfac785ae2c935a507c3bcae2e76aba9 8268147: need to update reference to testng module for jtreg6 Reviewed-by: dholmes, psandoz, naoto ! test/jdk/java/foreign/handles/lookup_module/module-info.java Changeset: e9f3e325 Author: Jonathan Gibbons Date: 2021-06-02 22:45:58 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e9f3e325c274f19b0f6eceea2367708e3be689e9 8259530: Generated docs contain MIT/GPL-licenced works without reproducing the licence Reviewed-by: prappo ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDoclet.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlOptions.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/util/DocFile.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/DocFileFactory.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/DocPaths.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/StandardDocFileFactory.java + test/langtools/jdk/javadoc/doclet/testLegalNotices/TestLegalNotices.java ! test/langtools/jdk/javadoc/tool/CheckResourceKeys.java ! test/langtools/jdk/javadoc/tool/api/basic/APITest.java Changeset: ef01e478 Author: Jonathan Gibbons Date: 2021-06-03 01:09:49 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ef01e478586c5676747195ea67c1864639305c0f 8268150: tier2: test/jdk/tools/jpackage/junit/junit.java needs updating for jtreg 6 Reviewed-by: almatvee ! test/jdk/tools/jpackage/junit/junit.java Changeset: 06f87cf4 Author: Leonid Mesnik Date: 2021-06-03 04:12:40 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/06f87cf4419be9c1bffe996d5d476d30b0f86bf6 8266337: ThreadTimesClosure doesn't handle exceptions properly Reviewed-by: dholmes, sspitsyn ! src/hotspot/share/services/management.cpp Changeset: bdeaeb47 Author: Sean Coffey Date: 2021-06-03 06:45:06 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bdeaeb47d0155b9f233274cff90334e8dd761aae 8240256: Better resource cleaning for SunPKCS11 Provider Reviewed-by: valeriep ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/Config.java ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/KeyCache.java ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/Session.java ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SessionManager.java ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/Token.java ! test/jdk/sun/security/pkcs11/PKCS11Test.java + test/jdk/sun/security/pkcs11/Provider/MultipleLogins-nss.txt + test/jdk/sun/security/pkcs11/Provider/MultipleLogins.java + test/jdk/sun/security/pkcs11/Provider/MultipleLogins.sh Changeset: 9bf347bc Author: Joel Borggr?n-Franck Date: 2021-06-03 07:51:30 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9bf347bc1f1dc01e27fbf35a05d34e9c5059b63e 8226362: langtools ProblemList file contains more than 1 entry for a test Reviewed-by: jlahoda ! test/langtools/ProblemList.txt Changeset: a52a08d2 Author: Albert Mingkun Yang Date: 2021-06-03 08:21:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a52a08d20be13721fcde65cad3567bbfa04f45cd 8267916: Adopt cast notation for CompilerThread conversions Reviewed-by: kbarrett, iklam, dholmes ! src/hotspot/share/compiler/compileBroker.cpp ! src/hotspot/share/compiler/compileBroker.hpp ! src/hotspot/share/compiler/compilerThread.hpp ! src/hotspot/share/jvmci/jvmci.cpp ! src/hotspot/share/jvmci/jvmciCodeInstaller.cpp ! src/hotspot/share/runtime/thread.hpp Changeset: 17834375 Author: Daniel Fuchs Date: 2021-06-03 08:58:41 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/178343750f8ce51c191d475d2fca6cbe609fd61c 8264975: java/net/DatagramSocket/DatagramSocketMulticasting.java fails infrequently Reviewed-by: alanb, chegar ! test/jdk/java/net/DatagramSocket/DatagramSocketMulticasting.java ! test/jdk/java/net/DatagramSocket/SendReceiveMaxSize.java ! test/lib/jdk/test/lib/NetworkConfiguration.java Changeset: 1296a6c4 Author: Stefan Karlsson Date: 2021-06-03 09:03:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1296a6c425e22e0fdc748a996b886923c602ab3f 8268119: Rename copy_os_cpu.inline.hpp files to copy_os_cpu.hpp Reviewed-by: kbarrett, coleenp ! src/hotspot/cpu/aarch64/copy_aarch64.hpp ! src/hotspot/cpu/arm/copy_arm.hpp ! src/hotspot/cpu/x86/copy_x86.hpp = src/hotspot/os_cpu/bsd_aarch64/copy_bsd_aarch64.hpp = src/hotspot/os_cpu/bsd_x86/copy_bsd_x86.hpp = src/hotspot/os_cpu/linux_aarch64/copy_linux_aarch64.hpp = src/hotspot/os_cpu/linux_arm/copy_linux_arm.hpp = src/hotspot/os_cpu/linux_x86/copy_linux_x86.hpp = src/hotspot/os_cpu/windows_aarch64/copy_windows_aarch64.hpp = src/hotspot/os_cpu/windows_x86/copy_windows_x86.hpp Changeset: c8f4c02b Author: Stefan Karlsson Date: 2021-06-03 09:04:53 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c8f4c02bf005ee1531193535632a5ece768916d0 8268118: Rename bytes_os_cpu.inline.hpp files to bytes_os_cpu.hpp Reviewed-by: coleenp, dholmes ! src/hotspot/cpu/aarch64/bytes_aarch64.hpp ! src/hotspot/cpu/arm/bytes_arm.hpp ! src/hotspot/cpu/ppc/bytes_ppc.hpp ! src/hotspot/cpu/s390/bytes_s390.hpp ! src/hotspot/cpu/x86/bytes_x86.hpp ! src/hotspot/cpu/zero/bytes_zero.hpp + src/hotspot/os_cpu/aix_ppc/bytes_aix_ppc.hpp - src/hotspot/os_cpu/aix_ppc/bytes_aix_ppc.inline.hpp = src/hotspot/os_cpu/bsd_aarch64/bytes_bsd_aarch64.hpp = src/hotspot/os_cpu/bsd_x86/bytes_bsd_x86.hpp = src/hotspot/os_cpu/bsd_zero/bytes_bsd_zero.hpp + src/hotspot/os_cpu/linux_aarch64/bytes_linux_aarch64.hpp - src/hotspot/os_cpu/linux_aarch64/bytes_linux_aarch64.inline.hpp = src/hotspot/os_cpu/linux_arm/bytes_linux_arm.hpp = src/hotspot/os_cpu/linux_ppc/bytes_linux_ppc.hpp + src/hotspot/os_cpu/linux_s390/bytes_linux_s390.hpp - src/hotspot/os_cpu/linux_s390/bytes_linux_s390.inline.hpp = src/hotspot/os_cpu/linux_x86/bytes_linux_x86.hpp + src/hotspot/os_cpu/linux_zero/bytes_linux_zero.hpp - src/hotspot/os_cpu/linux_zero/bytes_linux_zero.inline.hpp + src/hotspot/os_cpu/windows_aarch64/bytes_windows_aarch64.hpp - src/hotspot/os_cpu/windows_aarch64/bytes_windows_aarch64.inline.hpp + src/hotspot/os_cpu/windows_x86/bytes_windows_x86.hpp - src/hotspot/os_cpu/windows_x86/bytes_windows_x86.inline.hpp Changeset: 29ab1628 Author: Maurizio Cimadamore Date: 2021-06-03 09:41:21 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/29ab16284a4f1ac7ed691fd12cb622b0440c04be 8266257: Fix foreign linker build issues for ppc and s390 Reviewed-by: jvernee, vlivanov ! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp ! src/hotspot/cpu/arm/foreign_globals_arm.cpp ! src/hotspot/cpu/arm/universalUpcallHandle_arm.cpp ! src/hotspot/cpu/ppc/foreign_globals_ppc.cpp ! src/hotspot/cpu/ppc/universalUpcallHandle_ppc.cpp ! src/hotspot/cpu/s390/foreign_globals_s390.cpp ! src/hotspot/cpu/s390/universalUpcallHandle_s390.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.hpp ! src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp ! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp ! src/hotspot/cpu/x86/universalUpcallHandler_x86_64.cpp ! src/hotspot/cpu/zero/foreign_globals_zero.cpp ! src/hotspot/cpu/zero/universalUpcallHandle_zero.cpp ! src/hotspot/share/runtime/sharedRuntime.hpp Changeset: 338dae4d Author: Mahendra Chhipa Committer: Mark Sheppard Date: 2021-06-03 12:51:48 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/338dae4d36e848b1e1169c5b1bb2bfe70283e637 8268133: Update java/net/Authenticator tests to eliminate dependency on sun.net.www.MessageHeader and some other internal APIs Reviewed-by: dfuchs ! test/jdk/java/net/Authenticator/B4678055.java ! test/jdk/java/net/Authenticator/B4722333.java ! test/jdk/java/net/Authenticator/B4759514.java ! test/jdk/java/net/Authenticator/B4921848.java ! test/jdk/java/net/Authenticator/B4933582.java ! test/jdk/java/net/Authenticator/B4962064.java Changeset: fbaebd42 Author: Jie Fu Date: 2021-06-03 12:55:21 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fbaebd424310d2704aa8b347fe0f56ff0a038220 8268014: Build failure on SUSE Linux Enterprise Server 11.4 (s390x) due to 'SYS_get_mempolicy' was not declared Reviewed-by: dholmes, mdoerr, mbaesken ! src/hotspot/os/linux/os_linux.cpp Changeset: eb385c0d Author: Sean Coffey Date: 2021-06-03 13:47:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/eb385c0de2026d6b184ce0c98ff421a4da95e1b1 8268167: MultipleLogins.java failure on macosx-aarch64 Reviewed-by: weijun ! test/jdk/sun/security/pkcs11/Provider/MultipleLogins.java Changeset: 5982cfc8 Author: Paul Sandoz Date: 2021-06-03 15:16:58 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5982cfc85602862608fae56adb6041794e8c0d59 8266317: Vector API enhancements Co-authored-by: Paul Sandoz Co-authored-by: Sandhya Viswanathan Reviewed-by: jbhateja, vlivanov ! src/hotspot/cpu/aarch64/matcher_aarch64.hpp ! src/hotspot/cpu/arm/matcher_arm.hpp ! src/hotspot/cpu/ppc/matcher_ppc.hpp ! src/hotspot/cpu/s390/matcher_s390.hpp ! 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/macroAssembler_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.hpp ! src/hotspot/cpu/x86/matcher_x86.hpp ! src/hotspot/cpu/x86/x86.ad ! src/hotspot/share/opto/subnode.hpp ! src/hotspot/share/opto/vectorIntrinsics.cpp ! src/java.base/share/classes/jdk/internal/vm/vector/VectorSupport.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/DoubleMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/DoubleVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/FloatMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/FloatVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/IntMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/IntVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/LongMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/LongVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ShortMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ShortVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorOperators.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-VectorBits.java.template ! test/jdk/jdk/incubator/vector/Byte128VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Byte128VectorTests.java ! test/jdk/jdk/incubator/vector/Byte256VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Byte256VectorTests.java ! test/jdk/jdk/incubator/vector/Byte512VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Byte512VectorTests.java ! test/jdk/jdk/incubator/vector/Byte64VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Byte64VectorTests.java ! test/jdk/jdk/incubator/vector/ByteMaxVectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/ByteMaxVectorTests.java ! test/jdk/jdk/incubator/vector/Double128VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Double128VectorTests.java ! test/jdk/jdk/incubator/vector/Double256VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Double256VectorTests.java ! test/jdk/jdk/incubator/vector/Double512VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Double512VectorTests.java ! test/jdk/jdk/incubator/vector/Double64VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Double64VectorTests.java ! test/jdk/jdk/incubator/vector/DoubleMaxVectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/DoubleMaxVectorTests.java ! test/jdk/jdk/incubator/vector/Float128VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Float128VectorTests.java ! test/jdk/jdk/incubator/vector/Float256VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Float256VectorTests.java ! test/jdk/jdk/incubator/vector/Float512VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Float512VectorTests.java ! test/jdk/jdk/incubator/vector/Float64VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Float64VectorTests.java ! test/jdk/jdk/incubator/vector/FloatMaxVectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/FloatMaxVectorTests.java ! test/jdk/jdk/incubator/vector/Int128VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Int128VectorTests.java ! test/jdk/jdk/incubator/vector/Int256VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Int256VectorTests.java ! test/jdk/jdk/incubator/vector/Int512VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Int512VectorTests.java ! test/jdk/jdk/incubator/vector/Int64VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Int64VectorTests.java ! test/jdk/jdk/incubator/vector/IntMaxVectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/IntMaxVectorTests.java ! test/jdk/jdk/incubator/vector/Long128VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Long128VectorTests.java ! test/jdk/jdk/incubator/vector/Long256VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Long256VectorTests.java ! test/jdk/jdk/incubator/vector/Long512VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Long512VectorTests.java ! test/jdk/jdk/incubator/vector/Long64VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Long64VectorTests.java ! test/jdk/jdk/incubator/vector/LongMaxVectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/LongMaxVectorTests.java ! test/jdk/jdk/incubator/vector/Short128VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Short128VectorTests.java ! test/jdk/jdk/incubator/vector/Short256VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Short256VectorTests.java ! test/jdk/jdk/incubator/vector/Short512VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Short512VectorTests.java ! test/jdk/jdk/incubator/vector/Short64VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Short64VectorTests.java ! test/jdk/jdk/incubator/vector/ShortMaxVectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/ShortMaxVectorTests.java ! test/jdk/jdk/incubator/vector/gen-template.sh ! test/jdk/jdk/incubator/vector/gen-tests.sh ! test/jdk/jdk/incubator/vector/templates/Unit-Compare-Masked.template ! test/jdk/jdk/incubator/vector/templates/Unit-Compare.template ! test/jdk/jdk/incubator/vector/templates/Unit-header.template ! test/jdk/jdk/incubator/vector/templates/X-LoadStoreTest.java.template Changeset: 3aa7062c Author: Fernando Guallini Committer: Rajan Halade Date: 2021-06-03 16:06:31 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3aa7062c3dd41e06df67b46473ee2ef5a9671cf9 8262409: sun/security/ssl/SSLSocketImpl/SSLSocketImplThrowsWrongExceptions. SSL test failures caused by java failed with "Server reported the wrong exception" Reviewed-by: rhalade, xuelei ! test/jdk/ProblemList.txt ! test/jdk/sun/security/ssl/SSLSocketImpl/SSLSocketImplThrowsWrongExceptions.java Changeset: 5405f983 Author: Raffaello Giulietti Committer: Stuart Marks Date: 2021-06-03 16:08:33 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5405f983db7d359bb65c42366541104c5e9ef7c3 8268077: java.util.List missing from Collections Framework Overview Reviewed-by: smarks ! src/java.base/share/classes/java/util/doc-files/coll-overview.html Changeset: 52d8215a Author: Maurizio Cimadamore Date: 2021-06-03 16:19:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/52d8215a1ec42d67217505fe3167c70460f5a639 8268131: 2 java/foreign tests timed out Reviewed-by: dcubed ! test/jdk/java/foreign/TestDowncall.java ! test/jdk/java/foreign/TestResourceScope.java ! test/jdk/java/foreign/TestUpcall.java Changeset: af3df630 Author: Andy Herrick Date: 2021-06-03 19:02:11 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/af3df6300efddc8ba12f095b87205cc2fea1f1e8 8267598: jpackage removes system libraries from java.library.path Reviewed-by: almatvee, asemenyuk ! src/jdk.jpackage/linux/native/libapplauncher/LinuxLauncherLib.cpp ! src/jdk.jpackage/macosx/native/applauncher/MacLauncher.cpp ! src/jdk.jpackage/share/native/applauncher/AppLauncher.cpp ! src/jdk.jpackage/share/native/applauncher/AppLauncher.h ! src/jdk.jpackage/share/native/common/SysInfo.h ! src/jdk.jpackage/unix/native/common/UnixSysInfo.cpp ! src/jdk.jpackage/windows/native/applauncher/WinLauncher.cpp ! src/jdk.jpackage/windows/native/common/WinSysInfo.cpp ! src/jdk.jpackage/windows/native/common/WinSysInfo.h Changeset: 68ac871b Author: Daniel D. Daugherty Date: 2021-06-03 19:32:59 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/68ac871b6254cfb55b9ca9da173c9ca1b05f0020 8268189: ProblemList compiler/intrinsics/bmi/verifycode/BzhiTestI2L.java in -Xcomp mode Reviewed-by: mikael ! test/hotspot/jtreg/ProblemList-Xcomp.txt Changeset: e27c4d46 Author: Jonathan Gibbons Date: 2021-06-03 19:39:28 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e27c4d463d920994b79b8163f063ad74f6ee5d59 8268185: Update GitHub Actions for jtreg 6 Reviewed-by: erikj ! .github/workflows/submit.yml ! make/conf/test-dependencies Changeset: 9f05c411 Author: Sandhya Viswanathan Date: 2021-06-03 20:03:36 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9f05c411e6d6bdf612cf0cf8b9fe4ca9ecde50d1 8265783: Create a separate library for x86 Intel SVML assembly intrinsics Co-authored-by: Sandhya Viswanathan Co-authored-by: Rahul Kandu Co-authored-by: Razvan Lupusoru Co-authored-by: Magnus Ihse Bursie Co-authored-by: Jie Fu Co-authored-by: Ahmet Akkas Co-authored-by: Marius Cornea Reviewed-by: erikj, kvn, psandoz + make/modules/jdk.incubator.vector/Lib.gmk ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp ! src/hotspot/cpu/arm/arm.ad ! src/hotspot/cpu/arm/sharedRuntime_arm.cpp ! src/hotspot/cpu/ppc/ppc.ad ! src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp ! src/hotspot/cpu/s390/s390.ad ! src/hotspot/cpu/s390/sharedRuntime_s390.cpp ! src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp ! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp ! src/hotspot/cpu/x86/stubGenerator_x86_64.cpp ! src/hotspot/cpu/x86/x86.ad ! src/hotspot/cpu/x86/x86_32.ad ! src/hotspot/cpu/x86/x86_64.ad ! src/hotspot/cpu/zero/sharedRuntime_zero.cpp ! src/hotspot/share/adlc/formssel.cpp ! src/hotspot/share/classfile/modules.cpp ! src/hotspot/share/opto/c2_globals.hpp ! src/hotspot/share/opto/callnode.cpp ! src/hotspot/share/opto/callnode.hpp ! src/hotspot/share/opto/classes.hpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/escape.cpp ! src/hotspot/share/opto/graphKit.cpp ! src/hotspot/share/opto/graphKit.hpp ! src/hotspot/share/opto/lcm.cpp ! src/hotspot/share/opto/library_call.hpp ! src/hotspot/share/opto/matcher.cpp ! src/hotspot/share/opto/matcher.hpp ! src/hotspot/share/opto/runtime.cpp ! src/hotspot/share/opto/runtime.hpp ! src/hotspot/share/opto/vectorIntrinsics.cpp ! src/hotspot/share/prims/vectorSupport.cpp ! src/hotspot/share/prims/vectorSupport.hpp ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/sharedRuntime.hpp ! src/hotspot/share/runtime/stubRoutines.cpp ! src/hotspot/share/runtime/stubRoutines.hpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/java.base/share/classes/jdk/internal/vm/vector/VectorSupport.java + src/jdk.incubator.vector/linux/native/libsvml/globals_vectorApiSupport_linux.S.inc + src/jdk.incubator.vector/linux/native/libsvml/svml_d_acos_linux_x86.S + src/jdk.incubator.vector/linux/native/libsvml/svml_d_asin_linux_x86.S + src/jdk.incubator.vector/linux/native/libsvml/svml_d_atan2_linux_x86.S + src/jdk.incubator.vector/linux/native/libsvml/svml_d_atan_linux_x86.S + src/jdk.incubator.vector/linux/native/libsvml/svml_d_cbrt_linux_x86.S + src/jdk.incubator.vector/linux/native/libsvml/svml_d_cos_linux_x86.S + src/jdk.incubator.vector/linux/native/libsvml/svml_d_cosh_linux_x86.S + src/jdk.incubator.vector/linux/native/libsvml/svml_d_exp_linux_x86.S + src/jdk.incubator.vector/linux/native/libsvml/svml_d_expm1_linux_x86.S + src/jdk.incubator.vector/linux/native/libsvml/svml_d_hypot_linux_x86.S + src/jdk.incubator.vector/linux/native/libsvml/svml_d_log10_linux_x86.S + src/jdk.incubator.vector/linux/native/libsvml/svml_d_log1p_linux_x86.S + src/jdk.incubator.vector/linux/native/libsvml/svml_d_log_linux_x86.S + src/jdk.incubator.vector/linux/native/libsvml/svml_d_pow_linux_x86.S + src/jdk.incubator.vector/linux/native/libsvml/svml_d_sin_linux_x86.S + src/jdk.incubator.vector/linux/native/libsvml/svml_d_sinh_linux_x86.S + src/jdk.incubator.vector/linux/native/libsvml/svml_d_tan_linux_x86.S + src/jdk.incubator.vector/linux/native/libsvml/svml_d_tanh_linux_x86.S + src/jdk.incubator.vector/linux/native/libsvml/svml_s_acos_linux_x86.S + src/jdk.incubator.vector/linux/native/libsvml/svml_s_asin_linux_x86.S + src/jdk.incubator.vector/linux/native/libsvml/svml_s_atan2_linux_x86.S + src/jdk.incubator.vector/linux/native/libsvml/svml_s_atan_linux_x86.S + src/jdk.incubator.vector/linux/native/libsvml/svml_s_cbrt_linux_x86.S + src/jdk.incubator.vector/linux/native/libsvml/svml_s_cos_linux_x86.S + src/jdk.incubator.vector/linux/native/libsvml/svml_s_cosh_linux_x86.S + src/jdk.incubator.vector/linux/native/libsvml/svml_s_exp_linux_x86.S + src/jdk.incubator.vector/linux/native/libsvml/svml_s_expm1_linux_x86.S + src/jdk.incubator.vector/linux/native/libsvml/svml_s_hypot_linux_x86.S + src/jdk.incubator.vector/linux/native/libsvml/svml_s_log10_linux_x86.S + src/jdk.incubator.vector/linux/native/libsvml/svml_s_log1p_linux_x86.S + src/jdk.incubator.vector/linux/native/libsvml/svml_s_log_linux_x86.S + src/jdk.incubator.vector/linux/native/libsvml/svml_s_pow_linux_x86.S + src/jdk.incubator.vector/linux/native/libsvml/svml_s_sin_linux_x86.S + src/jdk.incubator.vector/linux/native/libsvml/svml_s_sinh_linux_x86.S + src/jdk.incubator.vector/linux/native/libsvml/svml_s_tan_linux_x86.S + src/jdk.incubator.vector/linux/native/libsvml/svml_s_tanh_linux_x86.S ! 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/VectorOperators.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template + src/jdk.incubator.vector/windows/native/libsvml/globals_vectorApiSupport_windows.S.inc + src/jdk.incubator.vector/windows/native/libsvml/svml_d_acos_windows_x86.S + src/jdk.incubator.vector/windows/native/libsvml/svml_d_asin_windows_x86.S + src/jdk.incubator.vector/windows/native/libsvml/svml_d_atan2_windows_x86.S + src/jdk.incubator.vector/windows/native/libsvml/svml_d_atan_windows_x86.S + src/jdk.incubator.vector/windows/native/libsvml/svml_d_cbrt_windows_x86.S + src/jdk.incubator.vector/windows/native/libsvml/svml_d_cos_windows_x86.S + src/jdk.incubator.vector/windows/native/libsvml/svml_d_cosh_windows_x86.S + src/jdk.incubator.vector/windows/native/libsvml/svml_d_exp_windows_x86.S + src/jdk.incubator.vector/windows/native/libsvml/svml_d_expm1_windows_x86.S + src/jdk.incubator.vector/windows/native/libsvml/svml_d_hypot_windows_x86.S + src/jdk.incubator.vector/windows/native/libsvml/svml_d_log10_windows_x86.S + src/jdk.incubator.vector/windows/native/libsvml/svml_d_log1p_windows_x86.S + src/jdk.incubator.vector/windows/native/libsvml/svml_d_log_windows_x86.S + src/jdk.incubator.vector/windows/native/libsvml/svml_d_pow_windows_x86.S + src/jdk.incubator.vector/windows/native/libsvml/svml_d_sin_windows_x86.S + src/jdk.incubator.vector/windows/native/libsvml/svml_d_sinh_windows_x86.S + src/jdk.incubator.vector/windows/native/libsvml/svml_d_tan_windows_x86.S + src/jdk.incubator.vector/windows/native/libsvml/svml_d_tanh_windows_x86.S + src/jdk.incubator.vector/windows/native/libsvml/svml_s_acos_windows_x86.S + src/jdk.incubator.vector/windows/native/libsvml/svml_s_asin_windows_x86.S + src/jdk.incubator.vector/windows/native/libsvml/svml_s_atan2_windows_x86.S + src/jdk.incubator.vector/windows/native/libsvml/svml_s_atan_windows_x86.S + src/jdk.incubator.vector/windows/native/libsvml/svml_s_cbrt_windows_x86.S + src/jdk.incubator.vector/windows/native/libsvml/svml_s_cos_windows_x86.S + src/jdk.incubator.vector/windows/native/libsvml/svml_s_cosh_windows_x86.S + src/jdk.incubator.vector/windows/native/libsvml/svml_s_exp_windows_x86.S + src/jdk.incubator.vector/windows/native/libsvml/svml_s_expm1_windows_x86.S + src/jdk.incubator.vector/windows/native/libsvml/svml_s_hypot_windows_x86.S + src/jdk.incubator.vector/windows/native/libsvml/svml_s_log10_windows_x86.S + src/jdk.incubator.vector/windows/native/libsvml/svml_s_log1p_windows_x86.S + src/jdk.incubator.vector/windows/native/libsvml/svml_s_log_windows_x86.S + src/jdk.incubator.vector/windows/native/libsvml/svml_s_pow_windows_x86.S + src/jdk.incubator.vector/windows/native/libsvml/svml_s_sin_windows_x86.S + src/jdk.incubator.vector/windows/native/libsvml/svml_s_sinh_windows_x86.S + src/jdk.incubator.vector/windows/native/libsvml/svml_s_tan_windows_x86.S + src/jdk.incubator.vector/windows/native/libsvml/svml_s_tanh_windows_x86.S Changeset: b9558655 Author: Mandy Chung Date: 2021-06-03 20:43:12 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b95586559ca44b040261168cbe5ba90689cab17e 8267995: Add reference to JVMS class file format in Lookup::defineHiddenClass Reviewed-by: darcy ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java Changeset: 460ce555 Author: Joe Wang Date: 2021-06-03 21:26:32 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/460ce5553c587715ef8244bee7e363b3587d2d0f 8266019: StreamResult(File) writes to incorrect file path if # is part of the file path Reviewed-by: dfuchs ! src/java.xml/share/classes/javax/xml/transform/stream/StreamResult.java ! test/jaxp/javax/xml/jaxp/unittest/transform/ResultTest.java Changeset: c1f3094f Author: Paul Sandoz Date: 2021-06-03 22:03:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c1f3094f814a4f3586222aad50ed314906b5bc9c 8267939: Clarify the specification of iterator and spliterator forEachRemaining Reviewed-by: smarks ! src/java.base/share/classes/java/util/PrimitiveIterator.java ! src/java.base/share/classes/java/util/Spliterator.java Changeset: 516e60a7 Author: Calvin Cheung Date: 2021-06-03 22:56:57 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/516e60a7ee3072cb3a311432257fab86dd622a48 8268095: CDS MethodHandle tests should add -XX:-VerifyDependencies Reviewed-by: iklam, minqi ! test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/methodHandles/CDSMHTest_generate.sh ! test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/methodHandles/MethodHandlesAsCollectorTest.java ! test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/methodHandles/MethodHandlesCastFailureTest.java ! test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/methodHandles/MethodHandlesGeneralTest.java ! test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/methodHandles/MethodHandlesInvokersTest.java ! test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/methodHandles/MethodHandlesPermuteArgumentsTest.java ! test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/methodHandles/MethodHandlesSpreadArgumentsTest.java ! test/hotspot/jtreg/runtime/cds/appcds/methodHandles/CDSMHTest_generate.sh ! test/hotspot/jtreg/runtime/cds/appcds/methodHandles/MethodHandlesAsCollectorTest.java ! test/hotspot/jtreg/runtime/cds/appcds/methodHandles/MethodHandlesCastFailureTest.java ! test/hotspot/jtreg/runtime/cds/appcds/methodHandles/MethodHandlesGeneralTest.java ! test/hotspot/jtreg/runtime/cds/appcds/methodHandles/MethodHandlesInvokersTest.java ! test/hotspot/jtreg/runtime/cds/appcds/methodHandles/MethodHandlesPermuteArgumentsTest.java ! test/hotspot/jtreg/runtime/cds/appcds/methodHandles/MethodHandlesSpreadArgumentsTest.java Changeset: 05df1727 Author: Joe Darcy Date: 2021-06-04 02:04:04 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/05df1727b529992aeac666b4984d0681d61ebb31 8268224: Cleanup references to "strictfp" in core lib comments Reviewed-by: jrose ! src/java.base/share/classes/java/lang/Math.java ! src/java.base/share/classes/java/lang/StrictMath.java Changeset: edca245d Author: Igor Ignatyev Date: 2021-06-04 02:21:53 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/edca245d5a5f4b43ac853b0c27551a8da2c20309 8267917: mark hotspot containers tests which ignore external VM flags Reviewed-by: mseledtsov, hseigel ! test/hotspot/jtreg/containers/cgroup/PlainRead.java ! test/hotspot/jtreg/containers/docker/TestJcmdWithSideCar.java Changeset: 1b4378e5 Author: Mikael Vidstedt Date: 2021-06-04 03:14:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1b4378e58e601dae379db851eae2610acf5f3ff7 8268142: Switch to jdk-17+24 for macosx-aarch64 at Oracle Reviewed-by: erikj ! make/conf/jib-profiles.js Changeset: e2d5ff9d Author: Mikael Vidstedt Date: 2021-06-04 04:07:06 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e2d5ff9d456dd339ccd21df2f75c4e34e5784d9a 8268214: Use system zlib and disable dtrace when building linux-aarch64 at Oracle Reviewed-by: dholmes ! make/conf/jib-profiles.js Changeset: 3025f059 Author: Pankaj Bansal Date: 2021-06-04 05:18:33 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3025f05970ede82c6f67a0434e33b27205e10130 8264305: Create implementation for native accessibility peer for Statusbar java role Reviewed-by: kizune ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CommonComponentAccessibility.m = src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/StatusbarAccessibility.h + src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/StatusbarAccessibility.m Changeset: 069f180a Author: Vladimir Ivanov Date: 2021-06-04 10:55:21 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/069f180a85655beba41a32c3ae05eeac31989682 8268174: Move x86-specific stub declarations into stubRoutines_x86.hpp Reviewed-by: kvn ! src/hotspot/cpu/x86/c1_LIRAssembler_x86.cpp ! src/hotspot/cpu/x86/c1_Runtime1_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp ! src/hotspot/cpu/x86/stubGenerator_x86_32.cpp ! src/hotspot/cpu/x86/stubGenerator_x86_64.cpp ! src/hotspot/cpu/x86/stubRoutines_x86.hpp ! src/hotspot/cpu/x86/stubRoutines_x86_32.cpp ! src/hotspot/cpu/x86/stubRoutines_x86_64.cpp ! src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp ! src/hotspot/cpu/x86/universalUpcallHandler_x86_64.cpp ! src/hotspot/cpu/x86/x86_32.ad ! src/hotspot/os/windows/os_windows.cpp ! src/hotspot/os_cpu/linux_x86/os_linux_x86.cpp ! src/hotspot/share/runtime/stubRoutines.cpp ! src/hotspot/share/runtime/stubRoutines.hpp Changeset: 36320414 Author: duke Date: 2021-06-04 11:01:18 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/36320414cf06de58e415126ce1390b8dcd80390f Automatic merge of jdk:master into master From duke at openjdk.java.net Fri Jun 4 11:08:32 2021 From: duke at openjdk.java.net (J.Duke) Date: Fri, 4 Jun 2021 11:08:32 GMT Subject: [foreign-memaccess+abi] RFR: Merge master Message-ID: Hi all, this is an _automatically_ generated pull request to notify you that there are 45 commits from the branch `master`that can **not** be merged into the branch `foreign-memaccess+abi`: The following file contains merge conflicts: - test/jdk/java/foreign/TestUpcall.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-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 +98:openjdk-bot-98 $ git checkout openjdk-bot-98 # 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-98:98 _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 - 8268174: Move x86-specific stub declarations into stubRoutines_x86.hpp - 8264305: Create implementation for native accessibility peer for Statusbar java role - 8268214: Use system zlib and disable dtrace when building linux-aarch64 at Oracle - 8268142: Switch to jdk-17+24 for macosx-aarch64 at Oracle - 8267917: mark hotspot containers tests which ignore external VM flags - 8268224: Cleanup references to "strictfp" in core lib comments - 8268095: CDS MethodHandle tests should add -XX:-VerifyDependencies - 8267939: Clarify the specification of iterator and spliterator forEachRemaining - 8266019: StreamResult(File) writes to incorrect file path if # is part of the file path - ... and 35 more: https://git.openjdk.java.net/panama-foreign/compare/21a08587...36320414 The webrev contains the conflicts with foreign-memaccess+abi: - merge conflicts: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=549&range=00.conflicts Changes: https://git.openjdk.java.net/panama-foreign/pull/549/files Stats: 433158 lines in 461 files changed: 429826 ins; 1713 del; 1619 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/549.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/549/head:pull/549 PR: https://git.openjdk.java.net/panama-foreign/pull/549 From duke at openjdk.java.net Fri Jun 4 11:18:56 2021 From: duke at openjdk.java.net (J.Duke) Date: Fri, 4 Jun 2021 11:18:56 GMT Subject: [foreign-memaccess+abi] 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 45 commits from the branch `master`that can **not** be merged into the branch `foreign-memaccess+abi`: > > The following file contains merge conflicts: > > - test/jdk/java/foreign/TestUpcall.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-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 +98:openjdk-bot-98 > $ git checkout openjdk-bot-98 > > # 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-98:98 > > > _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 789 additional commits since the last revision: - Merge branch 'foreign-memaccess+abi' into 98 - Merge master - 8267989: Exceptions thrown during upcalls should be handled 8268031: VarHandle combinator check for exceptions is too strict Reviewed-by: mcimadamore - Automatic merge of master into foreign-memaccess+abi - 8267240: Bounded arena allocator doesn't work if bounded size > BLOCK_SIZE Reviewed-by: jvernee - Remove printf and vprintf tests Reviewed-by: mcimadamore - Automatic merge of master into foreign-memaccess+abi - 8266911: On Windows the system lookup should load ucrtbase if possible Reviewed-by: mcimadamore - 8266916: Simplify logic for creating libSysLookup Reviewed-by: sundar - 8266814: Improve library loading with SymbolLookup abstraction Reviewed-by: jvernee, sundar - ... and 779 more: https://git.openjdk.java.net/panama-foreign/compare/36320414...ad831c30 ------------- Changes: - all: https://git.openjdk.java.net/panama-foreign/pull/549/files - new: https://git.openjdk.java.net/panama-foreign/pull/549/files/36320414..ad831c30 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=549&range=01 - incr: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=549&range=00-01 Stats: 1706 lines in 59 files changed: 937 ins; 639 del; 130 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/549.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/549/head:pull/549 PR: https://git.openjdk.java.net/panama-foreign/pull/549 From duke at openjdk.java.net Fri Jun 4 11:18:59 2021 From: duke at openjdk.java.net (J.Duke) Date: Fri, 4 Jun 2021 11:18:59 GMT Subject: [foreign-memaccess+abi] Integrated: Merge master In-Reply-To: References: Message-ID: On Fri, 4 Jun 2021 11:01:44 GMT, J. Duke wrote: > Hi all, > > this is an _automatically_ generated pull request to notify you that there are 45 commits from the branch `master`that can **not** be merged into the branch `foreign-memaccess+abi`: > > The following file contains merge conflicts: > > - test/jdk/java/foreign/TestUpcall.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-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 +98:openjdk-bot-98 > $ git checkout openjdk-bot-98 > > # 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-98:98 > > > _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: 3caff916 Author: J. Duke Committer: Jorn Vernee URL: https://git.openjdk.java.net/panama-foreign/commit/3caff916e7aeef7d3888be00b17d9b7e4c38cefb Stats: 433150 lines in 460 files changed: 429819 ins; 1713 del; 1618 mod Merge master ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/549 From duke at openjdk.java.net Fri Jun 4 11:22:47 2021 From: duke at openjdk.java.net (duke) Date: Fri, 4 Jun 2021 11:22:47 GMT Subject: git: openjdk/panama-foreign: foreign-jextract: 47 new changesets Message-ID: <5e4b66c6-ecee-4383-90a5-486d27e5d271@openjdk.org> Changeset: 40d23a0c Author: Weijun Wang Date: 2021-06-02 15:47:57 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/40d23a0c0b955ae4636800be183da7a71665f79f 8267543: Post JEP 411 refactoring: security Reviewed-by: mullan ! src/java.base/share/classes/com/sun/crypto/provider/JceKeyStore.java ! src/java.base/share/classes/java/security/KeyStore.java ! src/java.base/share/classes/java/security/Security.java ! src/java.base/share/classes/javax/crypto/ProviderVerifier.java ! src/java.base/share/classes/sun/security/jca/ProviderConfig.java ! src/java.base/share/classes/sun/security/provider/MD4.java ! src/java.base/share/classes/sun/security/provider/SunEntries.java ! src/java.base/share/classes/sun/security/ssl/SSLEngineImpl.java ! src/java.base/share/classes/sun/security/util/AnchorCertificates.java ! src/java.base/share/classes/sun/security/util/KeyStoreDelegator.java ! src/java.base/share/classes/sun/security/util/UntrustedCertificates.java ! src/java.management/share/classes/com/sun/jmx/remote/security/JMXPluggableAuthenticator.java ! src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5Context.java ! src/java.security.jgss/share/classes/sun/security/jgss/wrapper/SunNativeProvider.java ! src/java.security.jgss/share/classes/sun/security/krb5/internal/ccache/FileCredentialsCache.java ! src/java.smartcardio/unix/classes/sun/security/smartcardio/PlatformPCSC.java ! src/java.xml.crypto/share/classes/com/sun/org/slf4j/internal/Logger.java ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java ! src/jdk.crypto.mscapi/windows/classes/sun/security/mscapi/SunMSCAPI.java Changeset: 508cec75 Author: Weijun Wang Date: 2021-06-02 15:48:50 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/508cec7535cd0ad015d566389bc9e5f53ce4103b 8267521: Post JEP 411 refactoring: maximum covering > 50K Reviewed-by: dfuchs, prr ! src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java ! src/java.base/share/classes/sun/net/ftp/impl/FtpClient.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageReader.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageWriter.java ! src/java.desktop/share/classes/java/awt/Component.java ! src/java.desktop/share/classes/java/awt/Container.java ! src/java.desktop/share/classes/java/awt/DefaultKeyboardFocusManager.java ! src/java.desktop/share/classes/java/awt/Toolkit.java ! src/java.desktop/share/classes/java/awt/Window.java ! src/java.desktop/share/classes/javax/swing/RepaintManager.java ! src/java.desktop/share/classes/sun/awt/SunToolkit.java ! src/java.desktop/share/classes/sun/font/SunFontManager.java ! src/java.desktop/share/classes/sun/print/PSPrinterJob.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java ! src/java.logging/share/classes/java/util/logging/LogManager.java ! src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnector.java ! src/jdk.accessibility/windows/classes/com/sun/java/accessibility/internal/AccessBridge.java ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11.java Changeset: 56b65e4a Author: Brian Burkhalter Date: 2021-06-02 16:33:21 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/56b65e4a8d519801d170e16063ccb7dd3069c4be 8267569: java.io.File.equals contains misleading Javadoc Reviewed-by: alanb, dfuchs, bchristi, naoto ! src/java.base/share/classes/java/io/File.java Changeset: e1462e79 Author: Jonathan Gibbons Date: 2021-06-02 16:56:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e1462e79df7c22f3e09fa453c7887b6f51ef3dbb 8267176: StandardDoclet should provide access to Reporter and Locale Reviewed-by: hannesw ! src/jdk.javadoc/share/classes/jdk/javadoc/doclet/StandardDoclet.java ! test/langtools/jdk/javadoc/doclet/testDiagsLineCaret/MyTaglet.java ! test/langtools/jdk/javadoc/doclet/testDiagsLineCaret/TestDiagsLineCaret.java Changeset: b7ac705d Author: Guoxiong Li Committer: Vicente Romero Date: 2021-06-02 17:17:31 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b7ac705dd625c5fb2df714e2faec8d0ffac7301a 8263642: javac emits duplicate checkcast for first bound of intersection type in cast Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransTypes.java + test/langtools/tools/javac/cast/intersection/DuplicatedCheckcastTest.java Changeset: 1ae934e0 Author: Erik Gahlin Date: 2021-06-02 17:25:42 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1ae934e09d1a55bce4079153d3bfccd30657a0ea 8263332: JFR: Dump recording from a recording stream Reviewed-by: mgronlun ! src/hotspot/share/jfr/recorder/repository/jfrChunk.cpp ! src/hotspot/share/jfr/recorder/repository/jfrChunkWriter.cpp ! src/jdk.jfr/share/classes/jdk/jfr/consumer/RecordingStream.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/MetadataRepository.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/PlatformRecorder.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/PlatformRecording.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/Repository.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/RepositoryChunk.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/Utils.java ! src/jdk.management.jfr/share/classes/jdk/management/jfr/DiskRepository.java + src/jdk.management.jfr/share/classes/jdk/management/jfr/FileDump.java ! src/jdk.management.jfr/share/classes/jdk/management/jfr/RemoteRecordingStream.java + test/jdk/jdk/jfr/api/consumer/recordingstream/TestDump.java + test/jdk/jdk/jfr/jmx/streaming/TestRemoteDump.java Changeset: ecf6112a Author: Ioi Lam Date: 2021-06-02 19:05:42 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ecf6112a217e7d5d504a7272111d1ac72745d8f8 8267958: [TESTBUG] cds DynamicLoaderConstraintsTest.java timed out Reviewed-by: ccheung, jiefu ! test/hotspot/jtreg/runtime/cds/appcds/loaderConstraints/DynamicLoaderConstraintsTest.java ! test/hotspot/jtreg/runtime/cds/appcds/loaderConstraints/LoaderConstraintsTest.java Changeset: a8835b9c Author: Ioi Lam Date: 2021-06-02 19:20:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a8835b9c08af1438c80144bad7506fb5700511a3 8267879: ClassLoaderMetaspace destructor asserts on !_frozen Reviewed-by: dholmes, coleenp ! src/hotspot/share/cds/metaspaceShared.cpp ! src/hotspot/share/memory/classLoaderMetaspace.cpp ! src/hotspot/share/memory/metaspace.cpp ! src/hotspot/share/memory/metaspace.hpp Changeset: 375f8f3b Author: Erik Gahlin Date: 2021-06-02 19:43:36 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/375f8f3bffa7bc68a4c355195caa9d633d1cf120 8268138: docs build error after JDK-8263332 integration Reviewed-by: mgronlun ! src/jdk.jfr/share/classes/jdk/jfr/consumer/RecordingStream.java ! src/jdk.management.jfr/share/classes/jdk/management/jfr/RemoteRecordingStream.java Changeset: 3482cb87 Author: Jonathan Gibbons Date: 2021-06-02 21:20:12 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3482cb87fd94e6445ca243722851daa90c00a2c8 8266254: Update to use jtreg 6 8265020: tests must be updated for new TestNG module name Reviewed-by: lancea, erikj, mchung, naoto, alanb, iris, chegar ! make/conf/jib-profiles.js ! test/hotspot/jtreg/TEST.ROOT ! test/jaxp/TEST.ROOT ! test/jdk/TEST.ROOT ! test/jdk/java/lang/ModuleTests/addXXX/test/module-info.java ! test/jdk/java/lang/invoke/MethodHandles/privateLookupIn/test/module-info.java ! test/jdk/java/lang/invoke/modules/m1/module-info.java ! test/jdk/java/lang/invoke/modules/m3/module-info.java ! test/jdk/java/util/ServiceLoader/security/test/module-info.java ! test/langtools/TEST.ROOT ! test/lib-test/TEST.ROOT Changeset: 136badb1 Author: Valerie Peng Date: 2021-06-02 21:31:57 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/136badb1f7b0ba1d16fcf0deca5899e0d0186fc0 8248268: Support KWP in addition to KW Reviewed-by: xuelei + src/java.base/share/classes/com/sun/crypto/provider/AESKeyWrap.java + src/java.base/share/classes/com/sun/crypto/provider/AESKeyWrapPadded.java ! src/java.base/share/classes/com/sun/crypto/provider/AESParameters.java - src/java.base/share/classes/com/sun/crypto/provider/AESWrapCipher.java ! src/java.base/share/classes/com/sun/crypto/provider/BlockCipherParamsCore.java ! src/java.base/share/classes/com/sun/crypto/provider/ConstructKeys.java + src/java.base/share/classes/com/sun/crypto/provider/KWUtil.java + src/java.base/share/classes/com/sun/crypto/provider/KeyWrapCipher.java ! src/java.base/share/classes/com/sun/crypto/provider/SunJCE.java ! src/java.base/share/classes/sun/security/util/KnownOIDs.java ! src/java.base/share/classes/sun/security/util/SecurityProviderConstants.java ! test/jdk/com/sun/crypto/provider/Cipher/KeyWrap/NISTWrapKAT.java ! test/jdk/com/sun/crypto/provider/Cipher/KeyWrap/TestCipherKeyWrapperTest.java + test/jdk/com/sun/crypto/provider/Cipher/KeyWrap/TestGeneral.java + test/jdk/com/sun/crypto/provider/Cipher/KeyWrap/TestKeySizeCheck.java ! test/jdk/com/sun/crypto/provider/NSASuiteB/TestAESWrapOids.java ! test/jdk/javax/crypto/Cipher/TestCipherMode.java + test/micro/org/openjdk/bench/javax/crypto/full/AESKeyWrapBench.java Changeset: 76fdf2c8 Author: Daniel D. Daugherty Date: 2021-06-02 21:50:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/76fdf2c89bb7df9140438fcbaf16ea5fda024551 8268146: fix for JDK-8266254 fails validate-source Reviewed-by: psandoz, wetmore ! test/lib-test/TEST.ROOT Changeset: d46a2c8e Author: Jonathan Gibbons Date: 2021-06-02 22:33:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d46a2c8ecfac785ae2c935a507c3bcae2e76aba9 8268147: need to update reference to testng module for jtreg6 Reviewed-by: dholmes, psandoz, naoto ! test/jdk/java/foreign/handles/lookup_module/module-info.java Changeset: e9f3e325 Author: Jonathan Gibbons Date: 2021-06-02 22:45:58 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e9f3e325c274f19b0f6eceea2367708e3be689e9 8259530: Generated docs contain MIT/GPL-licenced works without reproducing the licence Reviewed-by: prappo ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDoclet.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlOptions.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/util/DocFile.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/DocFileFactory.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/DocPaths.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/StandardDocFileFactory.java + test/langtools/jdk/javadoc/doclet/testLegalNotices/TestLegalNotices.java ! test/langtools/jdk/javadoc/tool/CheckResourceKeys.java ! test/langtools/jdk/javadoc/tool/api/basic/APITest.java Changeset: ef01e478 Author: Jonathan Gibbons Date: 2021-06-03 01:09:49 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ef01e478586c5676747195ea67c1864639305c0f 8268150: tier2: test/jdk/tools/jpackage/junit/junit.java needs updating for jtreg 6 Reviewed-by: almatvee ! test/jdk/tools/jpackage/junit/junit.java Changeset: 06f87cf4 Author: Leonid Mesnik Date: 2021-06-03 04:12:40 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/06f87cf4419be9c1bffe996d5d476d30b0f86bf6 8266337: ThreadTimesClosure doesn't handle exceptions properly Reviewed-by: dholmes, sspitsyn ! src/hotspot/share/services/management.cpp Changeset: bdeaeb47 Author: Sean Coffey Date: 2021-06-03 06:45:06 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bdeaeb47d0155b9f233274cff90334e8dd761aae 8240256: Better resource cleaning for SunPKCS11 Provider Reviewed-by: valeriep ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/Config.java ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/KeyCache.java ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/Session.java ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SessionManager.java ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/Token.java ! test/jdk/sun/security/pkcs11/PKCS11Test.java + test/jdk/sun/security/pkcs11/Provider/MultipleLogins-nss.txt + test/jdk/sun/security/pkcs11/Provider/MultipleLogins.java + test/jdk/sun/security/pkcs11/Provider/MultipleLogins.sh Changeset: 9bf347bc Author: Joel Borggr?n-Franck Date: 2021-06-03 07:51:30 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9bf347bc1f1dc01e27fbf35a05d34e9c5059b63e 8226362: langtools ProblemList file contains more than 1 entry for a test Reviewed-by: jlahoda ! test/langtools/ProblemList.txt Changeset: a52a08d2 Author: Albert Mingkun Yang Date: 2021-06-03 08:21:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a52a08d20be13721fcde65cad3567bbfa04f45cd 8267916: Adopt cast notation for CompilerThread conversions Reviewed-by: kbarrett, iklam, dholmes ! src/hotspot/share/compiler/compileBroker.cpp ! src/hotspot/share/compiler/compileBroker.hpp ! src/hotspot/share/compiler/compilerThread.hpp ! src/hotspot/share/jvmci/jvmci.cpp ! src/hotspot/share/jvmci/jvmciCodeInstaller.cpp ! src/hotspot/share/runtime/thread.hpp Changeset: 17834375 Author: Daniel Fuchs Date: 2021-06-03 08:58:41 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/178343750f8ce51c191d475d2fca6cbe609fd61c 8264975: java/net/DatagramSocket/DatagramSocketMulticasting.java fails infrequently Reviewed-by: alanb, chegar ! test/jdk/java/net/DatagramSocket/DatagramSocketMulticasting.java ! test/jdk/java/net/DatagramSocket/SendReceiveMaxSize.java ! test/lib/jdk/test/lib/NetworkConfiguration.java Changeset: 1296a6c4 Author: Stefan Karlsson Date: 2021-06-03 09:03:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1296a6c425e22e0fdc748a996b886923c602ab3f 8268119: Rename copy_os_cpu.inline.hpp files to copy_os_cpu.hpp Reviewed-by: kbarrett, coleenp ! src/hotspot/cpu/aarch64/copy_aarch64.hpp ! src/hotspot/cpu/arm/copy_arm.hpp ! src/hotspot/cpu/x86/copy_x86.hpp = src/hotspot/os_cpu/bsd_aarch64/copy_bsd_aarch64.hpp = src/hotspot/os_cpu/bsd_x86/copy_bsd_x86.hpp = src/hotspot/os_cpu/linux_aarch64/copy_linux_aarch64.hpp = src/hotspot/os_cpu/linux_arm/copy_linux_arm.hpp = src/hotspot/os_cpu/linux_x86/copy_linux_x86.hpp = src/hotspot/os_cpu/windows_aarch64/copy_windows_aarch64.hpp = src/hotspot/os_cpu/windows_x86/copy_windows_x86.hpp Changeset: c8f4c02b Author: Stefan Karlsson Date: 2021-06-03 09:04:53 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c8f4c02bf005ee1531193535632a5ece768916d0 8268118: Rename bytes_os_cpu.inline.hpp files to bytes_os_cpu.hpp Reviewed-by: coleenp, dholmes ! src/hotspot/cpu/aarch64/bytes_aarch64.hpp ! src/hotspot/cpu/arm/bytes_arm.hpp ! src/hotspot/cpu/ppc/bytes_ppc.hpp ! src/hotspot/cpu/s390/bytes_s390.hpp ! src/hotspot/cpu/x86/bytes_x86.hpp ! src/hotspot/cpu/zero/bytes_zero.hpp + src/hotspot/os_cpu/aix_ppc/bytes_aix_ppc.hpp - src/hotspot/os_cpu/aix_ppc/bytes_aix_ppc.inline.hpp = src/hotspot/os_cpu/bsd_aarch64/bytes_bsd_aarch64.hpp = src/hotspot/os_cpu/bsd_x86/bytes_bsd_x86.hpp = src/hotspot/os_cpu/bsd_zero/bytes_bsd_zero.hpp + src/hotspot/os_cpu/linux_aarch64/bytes_linux_aarch64.hpp - src/hotspot/os_cpu/linux_aarch64/bytes_linux_aarch64.inline.hpp = src/hotspot/os_cpu/linux_arm/bytes_linux_arm.hpp = src/hotspot/os_cpu/linux_ppc/bytes_linux_ppc.hpp + src/hotspot/os_cpu/linux_s390/bytes_linux_s390.hpp - src/hotspot/os_cpu/linux_s390/bytes_linux_s390.inline.hpp = src/hotspot/os_cpu/linux_x86/bytes_linux_x86.hpp + src/hotspot/os_cpu/linux_zero/bytes_linux_zero.hpp - src/hotspot/os_cpu/linux_zero/bytes_linux_zero.inline.hpp + src/hotspot/os_cpu/windows_aarch64/bytes_windows_aarch64.hpp - src/hotspot/os_cpu/windows_aarch64/bytes_windows_aarch64.inline.hpp + src/hotspot/os_cpu/windows_x86/bytes_windows_x86.hpp - src/hotspot/os_cpu/windows_x86/bytes_windows_x86.inline.hpp Changeset: 29ab1628 Author: Maurizio Cimadamore Date: 2021-06-03 09:41:21 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/29ab16284a4f1ac7ed691fd12cb622b0440c04be 8266257: Fix foreign linker build issues for ppc and s390 Reviewed-by: jvernee, vlivanov ! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp ! src/hotspot/cpu/arm/foreign_globals_arm.cpp ! src/hotspot/cpu/arm/universalUpcallHandle_arm.cpp ! src/hotspot/cpu/ppc/foreign_globals_ppc.cpp ! src/hotspot/cpu/ppc/universalUpcallHandle_ppc.cpp ! src/hotspot/cpu/s390/foreign_globals_s390.cpp ! src/hotspot/cpu/s390/universalUpcallHandle_s390.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.hpp ! src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp ! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp ! src/hotspot/cpu/x86/universalUpcallHandler_x86_64.cpp ! src/hotspot/cpu/zero/foreign_globals_zero.cpp ! src/hotspot/cpu/zero/universalUpcallHandle_zero.cpp ! src/hotspot/share/runtime/sharedRuntime.hpp Changeset: 338dae4d Author: Mahendra Chhipa Committer: Mark Sheppard Date: 2021-06-03 12:51:48 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/338dae4d36e848b1e1169c5b1bb2bfe70283e637 8268133: Update java/net/Authenticator tests to eliminate dependency on sun.net.www.MessageHeader and some other internal APIs Reviewed-by: dfuchs ! test/jdk/java/net/Authenticator/B4678055.java ! test/jdk/java/net/Authenticator/B4722333.java ! test/jdk/java/net/Authenticator/B4759514.java ! test/jdk/java/net/Authenticator/B4921848.java ! test/jdk/java/net/Authenticator/B4933582.java ! test/jdk/java/net/Authenticator/B4962064.java Changeset: fbaebd42 Author: Jie Fu Date: 2021-06-03 12:55:21 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fbaebd424310d2704aa8b347fe0f56ff0a038220 8268014: Build failure on SUSE Linux Enterprise Server 11.4 (s390x) due to 'SYS_get_mempolicy' was not declared Reviewed-by: dholmes, mdoerr, mbaesken ! src/hotspot/os/linux/os_linux.cpp Changeset: eb385c0d Author: Sean Coffey Date: 2021-06-03 13:47:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/eb385c0de2026d6b184ce0c98ff421a4da95e1b1 8268167: MultipleLogins.java failure on macosx-aarch64 Reviewed-by: weijun ! test/jdk/sun/security/pkcs11/Provider/MultipleLogins.java Changeset: 5982cfc8 Author: Paul Sandoz Date: 2021-06-03 15:16:58 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5982cfc85602862608fae56adb6041794e8c0d59 8266317: Vector API enhancements Co-authored-by: Paul Sandoz Co-authored-by: Sandhya Viswanathan Reviewed-by: jbhateja, vlivanov ! src/hotspot/cpu/aarch64/matcher_aarch64.hpp ! src/hotspot/cpu/arm/matcher_arm.hpp ! src/hotspot/cpu/ppc/matcher_ppc.hpp ! src/hotspot/cpu/s390/matcher_s390.hpp ! 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/macroAssembler_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.hpp ! src/hotspot/cpu/x86/matcher_x86.hpp ! src/hotspot/cpu/x86/x86.ad ! src/hotspot/share/opto/subnode.hpp ! src/hotspot/share/opto/vectorIntrinsics.cpp ! src/java.base/share/classes/jdk/internal/vm/vector/VectorSupport.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/DoubleMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/DoubleVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/FloatMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/FloatVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/IntMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/IntVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/LongMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/LongVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ShortMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ShortVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorOperators.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-VectorBits.java.template ! test/jdk/jdk/incubator/vector/Byte128VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Byte128VectorTests.java ! test/jdk/jdk/incubator/vector/Byte256VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Byte256VectorTests.java ! test/jdk/jdk/incubator/vector/Byte512VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Byte512VectorTests.java ! test/jdk/jdk/incubator/vector/Byte64VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Byte64VectorTests.java ! test/jdk/jdk/incubator/vector/ByteMaxVectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/ByteMaxVectorTests.java ! test/jdk/jdk/incubator/vector/Double128VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Double128VectorTests.java ! test/jdk/jdk/incubator/vector/Double256VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Double256VectorTests.java ! test/jdk/jdk/incubator/vector/Double512VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Double512VectorTests.java ! test/jdk/jdk/incubator/vector/Double64VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Double64VectorTests.java ! test/jdk/jdk/incubator/vector/DoubleMaxVectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/DoubleMaxVectorTests.java ! test/jdk/jdk/incubator/vector/Float128VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Float128VectorTests.java ! test/jdk/jdk/incubator/vector/Float256VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Float256VectorTests.java ! test/jdk/jdk/incubator/vector/Float512VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Float512VectorTests.java ! test/jdk/jdk/incubator/vector/Float64VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Float64VectorTests.java ! test/jdk/jdk/incubator/vector/FloatMaxVectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/FloatMaxVectorTests.java ! test/jdk/jdk/incubator/vector/Int128VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Int128VectorTests.java ! test/jdk/jdk/incubator/vector/Int256VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Int256VectorTests.java ! test/jdk/jdk/incubator/vector/Int512VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Int512VectorTests.java ! test/jdk/jdk/incubator/vector/Int64VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Int64VectorTests.java ! test/jdk/jdk/incubator/vector/IntMaxVectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/IntMaxVectorTests.java ! test/jdk/jdk/incubator/vector/Long128VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Long128VectorTests.java ! test/jdk/jdk/incubator/vector/Long256VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Long256VectorTests.java ! test/jdk/jdk/incubator/vector/Long512VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Long512VectorTests.java ! test/jdk/jdk/incubator/vector/Long64VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Long64VectorTests.java ! test/jdk/jdk/incubator/vector/LongMaxVectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/LongMaxVectorTests.java ! test/jdk/jdk/incubator/vector/Short128VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Short128VectorTests.java ! test/jdk/jdk/incubator/vector/Short256VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Short256VectorTests.java ! test/jdk/jdk/incubator/vector/Short512VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Short512VectorTests.java ! test/jdk/jdk/incubator/vector/Short64VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Short64VectorTests.java ! test/jdk/jdk/incubator/vector/ShortMaxVectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/ShortMaxVectorTests.java ! test/jdk/jdk/incubator/vector/gen-template.sh ! test/jdk/jdk/incubator/vector/gen-tests.sh ! test/jdk/jdk/incubator/vector/templates/Unit-Compare-Masked.template ! test/jdk/jdk/incubator/vector/templates/Unit-Compare.template ! test/jdk/jdk/incubator/vector/templates/Unit-header.template ! test/jdk/jdk/incubator/vector/templates/X-LoadStoreTest.java.template Changeset: 3aa7062c Author: Fernando Guallini Committer: Rajan Halade Date: 2021-06-03 16:06:31 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3aa7062c3dd41e06df67b46473ee2ef5a9671cf9 8262409: sun/security/ssl/SSLSocketImpl/SSLSocketImplThrowsWrongExceptions. SSL test failures caused by java failed with "Server reported the wrong exception" Reviewed-by: rhalade, xuelei ! test/jdk/ProblemList.txt ! test/jdk/sun/security/ssl/SSLSocketImpl/SSLSocketImplThrowsWrongExceptions.java Changeset: 5405f983 Author: Raffaello Giulietti Committer: Stuart Marks Date: 2021-06-03 16:08:33 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5405f983db7d359bb65c42366541104c5e9ef7c3 8268077: java.util.List missing from Collections Framework Overview Reviewed-by: smarks ! src/java.base/share/classes/java/util/doc-files/coll-overview.html Changeset: 52d8215a Author: Maurizio Cimadamore Date: 2021-06-03 16:19:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/52d8215a1ec42d67217505fe3167c70460f5a639 8268131: 2 java/foreign tests timed out Reviewed-by: dcubed ! test/jdk/java/foreign/TestDowncall.java ! test/jdk/java/foreign/TestResourceScope.java ! test/jdk/java/foreign/TestUpcall.java Changeset: af3df630 Author: Andy Herrick Date: 2021-06-03 19:02:11 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/af3df6300efddc8ba12f095b87205cc2fea1f1e8 8267598: jpackage removes system libraries from java.library.path Reviewed-by: almatvee, asemenyuk ! src/jdk.jpackage/linux/native/libapplauncher/LinuxLauncherLib.cpp ! src/jdk.jpackage/macosx/native/applauncher/MacLauncher.cpp ! src/jdk.jpackage/share/native/applauncher/AppLauncher.cpp ! src/jdk.jpackage/share/native/applauncher/AppLauncher.h ! src/jdk.jpackage/share/native/common/SysInfo.h ! src/jdk.jpackage/unix/native/common/UnixSysInfo.cpp ! src/jdk.jpackage/windows/native/applauncher/WinLauncher.cpp ! src/jdk.jpackage/windows/native/common/WinSysInfo.cpp ! src/jdk.jpackage/windows/native/common/WinSysInfo.h Changeset: 68ac871b Author: Daniel D. Daugherty Date: 2021-06-03 19:32:59 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/68ac871b6254cfb55b9ca9da173c9ca1b05f0020 8268189: ProblemList compiler/intrinsics/bmi/verifycode/BzhiTestI2L.java in -Xcomp mode Reviewed-by: mikael ! test/hotspot/jtreg/ProblemList-Xcomp.txt Changeset: e27c4d46 Author: Jonathan Gibbons Date: 2021-06-03 19:39:28 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e27c4d463d920994b79b8163f063ad74f6ee5d59 8268185: Update GitHub Actions for jtreg 6 Reviewed-by: erikj ! .github/workflows/submit.yml ! make/conf/test-dependencies Changeset: 9f05c411 Author: Sandhya Viswanathan Date: 2021-06-03 20:03:36 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9f05c411e6d6bdf612cf0cf8b9fe4ca9ecde50d1 8265783: Create a separate library for x86 Intel SVML assembly intrinsics Co-authored-by: Sandhya Viswanathan Co-authored-by: Rahul Kandu Co-authored-by: Razvan Lupusoru Co-authored-by: Magnus Ihse Bursie Co-authored-by: Jie Fu Co-authored-by: Ahmet Akkas Co-authored-by: Marius Cornea Reviewed-by: erikj, kvn, psandoz + make/modules/jdk.incubator.vector/Lib.gmk ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp ! src/hotspot/cpu/arm/arm.ad ! src/hotspot/cpu/arm/sharedRuntime_arm.cpp ! src/hotspot/cpu/ppc/ppc.ad ! src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp ! src/hotspot/cpu/s390/s390.ad ! src/hotspot/cpu/s390/sharedRuntime_s390.cpp ! src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp ! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp ! src/hotspot/cpu/x86/stubGenerator_x86_64.cpp ! src/hotspot/cpu/x86/x86.ad ! src/hotspot/cpu/x86/x86_32.ad ! src/hotspot/cpu/x86/x86_64.ad ! src/hotspot/cpu/zero/sharedRuntime_zero.cpp ! src/hotspot/share/adlc/formssel.cpp ! src/hotspot/share/classfile/modules.cpp ! src/hotspot/share/opto/c2_globals.hpp ! src/hotspot/share/opto/callnode.cpp ! src/hotspot/share/opto/callnode.hpp ! src/hotspot/share/opto/classes.hpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/escape.cpp ! src/hotspot/share/opto/graphKit.cpp ! src/hotspot/share/opto/graphKit.hpp ! src/hotspot/share/opto/lcm.cpp ! src/hotspot/share/opto/library_call.hpp ! src/hotspot/share/opto/matcher.cpp ! src/hotspot/share/opto/matcher.hpp ! src/hotspot/share/opto/runtime.cpp ! src/hotspot/share/opto/runtime.hpp ! src/hotspot/share/opto/vectorIntrinsics.cpp ! src/hotspot/share/prims/vectorSupport.cpp ! src/hotspot/share/prims/vectorSupport.hpp ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/sharedRuntime.hpp ! src/hotspot/share/runtime/stubRoutines.cpp ! src/hotspot/share/runtime/stubRoutines.hpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/java.base/share/classes/jdk/internal/vm/vector/VectorSupport.java + src/jdk.incubator.vector/linux/native/libsvml/globals_vectorApiSupport_linux.S.inc + src/jdk.incubator.vector/linux/native/libsvml/svml_d_acos_linux_x86.S + src/jdk.incubator.vector/linux/native/libsvml/svml_d_asin_linux_x86.S + src/jdk.incubator.vector/linux/native/libsvml/svml_d_atan2_linux_x86.S + src/jdk.incubator.vector/linux/native/libsvml/svml_d_atan_linux_x86.S + src/jdk.incubator.vector/linux/native/libsvml/svml_d_cbrt_linux_x86.S + src/jdk.incubator.vector/linux/native/libsvml/svml_d_cos_linux_x86.S + src/jdk.incubator.vector/linux/native/libsvml/svml_d_cosh_linux_x86.S + src/jdk.incubator.vector/linux/native/libsvml/svml_d_exp_linux_x86.S + src/jdk.incubator.vector/linux/native/libsvml/svml_d_expm1_linux_x86.S + src/jdk.incubator.vector/linux/native/libsvml/svml_d_hypot_linux_x86.S + src/jdk.incubator.vector/linux/native/libsvml/svml_d_log10_linux_x86.S + src/jdk.incubator.vector/linux/native/libsvml/svml_d_log1p_linux_x86.S + src/jdk.incubator.vector/linux/native/libsvml/svml_d_log_linux_x86.S + src/jdk.incubator.vector/linux/native/libsvml/svml_d_pow_linux_x86.S + src/jdk.incubator.vector/linux/native/libsvml/svml_d_sin_linux_x86.S + src/jdk.incubator.vector/linux/native/libsvml/svml_d_sinh_linux_x86.S + src/jdk.incubator.vector/linux/native/libsvml/svml_d_tan_linux_x86.S + src/jdk.incubator.vector/linux/native/libsvml/svml_d_tanh_linux_x86.S + src/jdk.incubator.vector/linux/native/libsvml/svml_s_acos_linux_x86.S + src/jdk.incubator.vector/linux/native/libsvml/svml_s_asin_linux_x86.S + src/jdk.incubator.vector/linux/native/libsvml/svml_s_atan2_linux_x86.S + src/jdk.incubator.vector/linux/native/libsvml/svml_s_atan_linux_x86.S + src/jdk.incubator.vector/linux/native/libsvml/svml_s_cbrt_linux_x86.S + src/jdk.incubator.vector/linux/native/libsvml/svml_s_cos_linux_x86.S + src/jdk.incubator.vector/linux/native/libsvml/svml_s_cosh_linux_x86.S + src/jdk.incubator.vector/linux/native/libsvml/svml_s_exp_linux_x86.S + src/jdk.incubator.vector/linux/native/libsvml/svml_s_expm1_linux_x86.S + src/jdk.incubator.vector/linux/native/libsvml/svml_s_hypot_linux_x86.S + src/jdk.incubator.vector/linux/native/libsvml/svml_s_log10_linux_x86.S + src/jdk.incubator.vector/linux/native/libsvml/svml_s_log1p_linux_x86.S + src/jdk.incubator.vector/linux/native/libsvml/svml_s_log_linux_x86.S + src/jdk.incubator.vector/linux/native/libsvml/svml_s_pow_linux_x86.S + src/jdk.incubator.vector/linux/native/libsvml/svml_s_sin_linux_x86.S + src/jdk.incubator.vector/linux/native/libsvml/svml_s_sinh_linux_x86.S + src/jdk.incubator.vector/linux/native/libsvml/svml_s_tan_linux_x86.S + src/jdk.incubator.vector/linux/native/libsvml/svml_s_tanh_linux_x86.S ! 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/VectorOperators.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template + src/jdk.incubator.vector/windows/native/libsvml/globals_vectorApiSupport_windows.S.inc + src/jdk.incubator.vector/windows/native/libsvml/svml_d_acos_windows_x86.S + src/jdk.incubator.vector/windows/native/libsvml/svml_d_asin_windows_x86.S + src/jdk.incubator.vector/windows/native/libsvml/svml_d_atan2_windows_x86.S + src/jdk.incubator.vector/windows/native/libsvml/svml_d_atan_windows_x86.S + src/jdk.incubator.vector/windows/native/libsvml/svml_d_cbrt_windows_x86.S + src/jdk.incubator.vector/windows/native/libsvml/svml_d_cos_windows_x86.S + src/jdk.incubator.vector/windows/native/libsvml/svml_d_cosh_windows_x86.S + src/jdk.incubator.vector/windows/native/libsvml/svml_d_exp_windows_x86.S + src/jdk.incubator.vector/windows/native/libsvml/svml_d_expm1_windows_x86.S + src/jdk.incubator.vector/windows/native/libsvml/svml_d_hypot_windows_x86.S + src/jdk.incubator.vector/windows/native/libsvml/svml_d_log10_windows_x86.S + src/jdk.incubator.vector/windows/native/libsvml/svml_d_log1p_windows_x86.S + src/jdk.incubator.vector/windows/native/libsvml/svml_d_log_windows_x86.S + src/jdk.incubator.vector/windows/native/libsvml/svml_d_pow_windows_x86.S + src/jdk.incubator.vector/windows/native/libsvml/svml_d_sin_windows_x86.S + src/jdk.incubator.vector/windows/native/libsvml/svml_d_sinh_windows_x86.S + src/jdk.incubator.vector/windows/native/libsvml/svml_d_tan_windows_x86.S + src/jdk.incubator.vector/windows/native/libsvml/svml_d_tanh_windows_x86.S + src/jdk.incubator.vector/windows/native/libsvml/svml_s_acos_windows_x86.S + src/jdk.incubator.vector/windows/native/libsvml/svml_s_asin_windows_x86.S + src/jdk.incubator.vector/windows/native/libsvml/svml_s_atan2_windows_x86.S + src/jdk.incubator.vector/windows/native/libsvml/svml_s_atan_windows_x86.S + src/jdk.incubator.vector/windows/native/libsvml/svml_s_cbrt_windows_x86.S + src/jdk.incubator.vector/windows/native/libsvml/svml_s_cos_windows_x86.S + src/jdk.incubator.vector/windows/native/libsvml/svml_s_cosh_windows_x86.S + src/jdk.incubator.vector/windows/native/libsvml/svml_s_exp_windows_x86.S + src/jdk.incubator.vector/windows/native/libsvml/svml_s_expm1_windows_x86.S + src/jdk.incubator.vector/windows/native/libsvml/svml_s_hypot_windows_x86.S + src/jdk.incubator.vector/windows/native/libsvml/svml_s_log10_windows_x86.S + src/jdk.incubator.vector/windows/native/libsvml/svml_s_log1p_windows_x86.S + src/jdk.incubator.vector/windows/native/libsvml/svml_s_log_windows_x86.S + src/jdk.incubator.vector/windows/native/libsvml/svml_s_pow_windows_x86.S + src/jdk.incubator.vector/windows/native/libsvml/svml_s_sin_windows_x86.S + src/jdk.incubator.vector/windows/native/libsvml/svml_s_sinh_windows_x86.S + src/jdk.incubator.vector/windows/native/libsvml/svml_s_tan_windows_x86.S + src/jdk.incubator.vector/windows/native/libsvml/svml_s_tanh_windows_x86.S Changeset: b9558655 Author: Mandy Chung Date: 2021-06-03 20:43:12 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b95586559ca44b040261168cbe5ba90689cab17e 8267995: Add reference to JVMS class file format in Lookup::defineHiddenClass Reviewed-by: darcy ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java Changeset: 460ce555 Author: Joe Wang Date: 2021-06-03 21:26:32 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/460ce5553c587715ef8244bee7e363b3587d2d0f 8266019: StreamResult(File) writes to incorrect file path if # is part of the file path Reviewed-by: dfuchs ! src/java.xml/share/classes/javax/xml/transform/stream/StreamResult.java ! test/jaxp/javax/xml/jaxp/unittest/transform/ResultTest.java Changeset: c1f3094f Author: Paul Sandoz Date: 2021-06-03 22:03:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c1f3094f814a4f3586222aad50ed314906b5bc9c 8267939: Clarify the specification of iterator and spliterator forEachRemaining Reviewed-by: smarks ! src/java.base/share/classes/java/util/PrimitiveIterator.java ! src/java.base/share/classes/java/util/Spliterator.java Changeset: 516e60a7 Author: Calvin Cheung Date: 2021-06-03 22:56:57 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/516e60a7ee3072cb3a311432257fab86dd622a48 8268095: CDS MethodHandle tests should add -XX:-VerifyDependencies Reviewed-by: iklam, minqi ! test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/methodHandles/CDSMHTest_generate.sh ! test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/methodHandles/MethodHandlesAsCollectorTest.java ! test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/methodHandles/MethodHandlesCastFailureTest.java ! test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/methodHandles/MethodHandlesGeneralTest.java ! test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/methodHandles/MethodHandlesInvokersTest.java ! test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/methodHandles/MethodHandlesPermuteArgumentsTest.java ! test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/methodHandles/MethodHandlesSpreadArgumentsTest.java ! test/hotspot/jtreg/runtime/cds/appcds/methodHandles/CDSMHTest_generate.sh ! test/hotspot/jtreg/runtime/cds/appcds/methodHandles/MethodHandlesAsCollectorTest.java ! test/hotspot/jtreg/runtime/cds/appcds/methodHandles/MethodHandlesCastFailureTest.java ! test/hotspot/jtreg/runtime/cds/appcds/methodHandles/MethodHandlesGeneralTest.java ! test/hotspot/jtreg/runtime/cds/appcds/methodHandles/MethodHandlesInvokersTest.java ! test/hotspot/jtreg/runtime/cds/appcds/methodHandles/MethodHandlesPermuteArgumentsTest.java ! test/hotspot/jtreg/runtime/cds/appcds/methodHandles/MethodHandlesSpreadArgumentsTest.java Changeset: 05df1727 Author: Joe Darcy Date: 2021-06-04 02:04:04 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/05df1727b529992aeac666b4984d0681d61ebb31 8268224: Cleanup references to "strictfp" in core lib comments Reviewed-by: jrose ! src/java.base/share/classes/java/lang/Math.java ! src/java.base/share/classes/java/lang/StrictMath.java Changeset: edca245d Author: Igor Ignatyev Date: 2021-06-04 02:21:53 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/edca245d5a5f4b43ac853b0c27551a8da2c20309 8267917: mark hotspot containers tests which ignore external VM flags Reviewed-by: mseledtsov, hseigel ! test/hotspot/jtreg/containers/cgroup/PlainRead.java ! test/hotspot/jtreg/containers/docker/TestJcmdWithSideCar.java Changeset: 1b4378e5 Author: Mikael Vidstedt Date: 2021-06-04 03:14:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1b4378e58e601dae379db851eae2610acf5f3ff7 8268142: Switch to jdk-17+24 for macosx-aarch64 at Oracle Reviewed-by: erikj ! make/conf/jib-profiles.js Changeset: e2d5ff9d Author: Mikael Vidstedt Date: 2021-06-04 04:07:06 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e2d5ff9d456dd339ccd21df2f75c4e34e5784d9a 8268214: Use system zlib and disable dtrace when building linux-aarch64 at Oracle Reviewed-by: dholmes ! make/conf/jib-profiles.js Changeset: 3025f059 Author: Pankaj Bansal Date: 2021-06-04 05:18:33 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3025f05970ede82c6f67a0434e33b27205e10130 8264305: Create implementation for native accessibility peer for Statusbar java role Reviewed-by: kizune ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CommonComponentAccessibility.m = src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/StatusbarAccessibility.h + src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/StatusbarAccessibility.m Changeset: 069f180a Author: Vladimir Ivanov Date: 2021-06-04 10:55:21 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/069f180a85655beba41a32c3ae05eeac31989682 8268174: Move x86-specific stub declarations into stubRoutines_x86.hpp Reviewed-by: kvn ! src/hotspot/cpu/x86/c1_LIRAssembler_x86.cpp ! src/hotspot/cpu/x86/c1_Runtime1_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp ! src/hotspot/cpu/x86/stubGenerator_x86_32.cpp ! src/hotspot/cpu/x86/stubGenerator_x86_64.cpp ! src/hotspot/cpu/x86/stubRoutines_x86.hpp ! src/hotspot/cpu/x86/stubRoutines_x86_32.cpp ! src/hotspot/cpu/x86/stubRoutines_x86_64.cpp ! src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp ! src/hotspot/cpu/x86/universalUpcallHandler_x86_64.cpp ! src/hotspot/cpu/x86/x86_32.ad ! src/hotspot/os/windows/os_windows.cpp ! src/hotspot/os_cpu/linux_x86/os_linux_x86.cpp ! src/hotspot/share/runtime/stubRoutines.cpp ! src/hotspot/share/runtime/stubRoutines.hpp Changeset: 36320414 Author: duke Date: 2021-06-04 11:01:18 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/36320414cf06de58e415126ce1390b8dcd80390f Automatic merge of jdk:master into master Changeset: 3caff916 Author: J. Duke Committer: Jorn Vernee Date: 2021-06-04 11:15:12 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3caff916e7aeef7d3888be00b17d9b7e4c38cefb Merge master ! test/jdk/java/foreign/TestDowncall.java ! test/jdk/java/foreign/TestUpcall.java ! test/jdk/java/foreign/TestDowncall.java ! test/jdk/java/foreign/TestUpcall.java Changeset: e57af02a Author: duke Date: 2021-06-04 11:16:30 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e57af02aeda4226fe25c779bab8e69e1864f1423 Automatic merge of foreign-memaccess+abi into foreign-jextract ! make/conf/jib-profiles.js ! make/conf/jib-profiles.js From leerho at gmail.com Fri Jun 4 14:09:33 2021 From: leerho at gmail.com (leerho) Date: Fri, 4 Jun 2021 07:09:33 -0700 Subject: Part 1 Proposal for JDK-8264594 In-Reply-To: <87a484de-9cdc-ddc7-ff73-6dad2641d5a4@oracle.com> References: <49091534-aa0f-81f7-2536-ff788e6377cf@oracle.com> <0b5ac260-4e87-4a92-53ca-b670a451f552@oracle.com> <50605287-4e54-7dde-14e5-d521c19301be@oracle.com> <95c04a58-4897-0d49-3f13-d8aa6b293006@oracle.com> <87a484de-9cdc-ddc7-ff73-6dad2641d5a4@oracle.com> Message-ID: Maurizio, Thank you for your reply. I agree with your observation in the difference between the single item case and the bulk copy. I guess I became so familiar with how offsets are handled in Unsafe where the single element and bulk copy cases the references to memory are always in bytes, it seamed so simple and natural. In my experience anyway, reading and writing data to off-heap almost always involves a mix of preamble elements and bulk copy arrays where it was necessary to track the offset in bytes, where the multibyte elements may not be correctly aligned to the base of the allocated segment, or God forbid, the arrays. What is most important is getting this into the JDK, and if I have to add more overloads, I will :) Lee. On Fri, Jun 4, 2021 at 2:34 AM Maurizio Cimadamore < maurizio.cimadamore at oracle.com> wrote: > > On 04/06/2021 01:32, leerho wrote: > > When I first saw all the logical index overloads in MemoryAccess I > shuddered. It is a lot of API clutter as far as I?m concerned. But just > because we made that mistake with MemoryAccess doesn?t mean we have to > continue propagating it. > > I'm sorry, I just don't see that as being a "mistake". Code like this: > > ``` > for (int i = 0 ; i < limit ; i++) { > long val = MemoryAccess.getLongAtIndex(segment, i); > ... > } > ``` > > Is _extremely_ common. While it's true that memory segment is an unbiased > array of bytes, there are times you want to access it in a more structured > form - and saying "you can't do that" because it adds overloads doesn't > seem like a great solution to me. > > > Also I have explicitly named the two offsets very differently to try to > make it clear that they are very different. I guess I could go further and > name the ?srcIndex? -> ?srcIndexLongs? for the long array case, for > example. But since ?index? is used elsewhere as the logical index I > assumed that this would not be necessary. > > But I would much rather use longer, more explicit names than propagate API > clutter. > > I was thinking overnight that, perhaps, the memory copy and the single > element cases are different. When you do single access (see above) you do > that frequently in a loop - and you often get elements of the same type. As > stated above, asking developers to work in terms of offsets seems a bit > odd, when they are really accessing a flat array of element type T. > > In the case of bulk copy, I don't think there's the same degree of > pressure - you will probably call the bulk copy at the beginning, or at the > end of your computation (or both ends!) - and having an offset shift is > more tolerable. > > So, I'm open to evaluating something more minimal, and see how far we can > get with it. > > Maurizio > > > Lee > > On Thu, Jun 3, 2021 at 1:26 PM Maurizio Cimadamore < > maurizio.cimadamore at oracle.com> wrote: > >> Thanks. >> >> While I agree that a segment is just a bunch of bytes, I think also think >> that having an API which takes two indices at the same time, one logical >> and one physical is kind of evil. I bet that a lot of developers will get >> that wrong, at least the first time. >> >> What you say about segments being an array of bytes, and thus not needing >> index-based overloads can also be said for MemoryAccess class - but I >> believe that the index-based accessors in the are quite popular. >> >> But overall, my worry is not performances, or symmetry with respect to >> other APIs - my main worry is what I said above: that people will just >> assume that indices are logical for both the segment and the array - so >> overloads with clearly different names should help quite a bit IMHO. >> >> >> Maurizio >> On 03/06/2021 20:50, leerho wrote: >> >> Maurizio, >> Here is the MemoryCopy class (w/o byte swap) and the TestMemoryCopy class >> (w/o testing byte swap). >> >> I copied from the TestMemoryAccess class in that I noticed that there is >> no package statement. I am not sure what @SuppressWarnings are allowed in >> your test environment, I suspect I should remove all of them. >> >> When the MemorySegment copyFrom(MemorySegment, MemoryLayout, ByteOrder) >> becomes available I can add the tests for that. >> >> *IMHO* >> >> I feel strongly that there is no need to additionally overload these >> methods with the segment offset specified in array index units. It is so >> trivial to convert from one to the other and it can be done easily in the >> method argument with a simple multiply by 2, 4 or 8. This should compile >> down to a simple shift, which becomes a single cycle CPU instruction. So >> this is not a performance issue. >> >> Furthermore, it is best that the user becomes accustomed to thinking of a >> segment fundamentally as an array of bytes. Once a segment is loaded with >> some primitive array, the segment loses the context of the type of the >> array it was loaded with; in effect, a kind of "type erasure" similar to >> Java's generics. This is one of the reasons that MemorySegments can be so >> powerful. >> >> >> I have been programming with the "MemorySegment" concept for a number of >> years now and find that keeping in mind that segments are just bytes is >> very useful. >> >> >> Let me know what you think. >> >> Lee. >> >> >> >> On Mon, May 31, 2021 at 6:56 AM Maurizio Cimadamore < >> maurizio.cimadamore at oracle.com> wrote: >> >>> Hi Lee, >>> this looks good. >>> >>> One thing I note is that there's an ambiguity as to whether the segment >>> index is expressed as a logical index, or a raw byte offset. Your snippet >>> does the latter. If we want to follow MemoryAccess, perhaps that calls for >>> 2 overloads (copyFromArrayAtIndex/copyFromArrayAtOffset), as I imagine both >>> could be useful, depending on the case? >>> >>> The javadoc will have to say something when the segment being used is >>> backed by the very array that is the source/target of the copy (we have >>> some text like that in MemorySegment::copyFrom). >>> >>> I think it would be helpful to progress further with this, add the >>> remaining templates (w/o ByteOrder, for now) test and see how it works in >>> practice. >>> >>> I will add (or just file a simple PR, so that you can just borrow from >>> it - should be a single method) something to do the segment copy with swap. >>> >>> Thanks! >>> Maurizio >>> On 28/05/2021 22:37, leerho wrote: >>> >>> Maurizio, >>> >>> Again sorry about the delay. >>> >>> Attached is a template proposal for the MemoryCopy class. >>> >>> I can't complete this without your proposed new copyFrom(...) method in >>> MemorySegment. As it is written, it should work, but without the byte swap >>> capability. >>> >>> I can complete the rest of the primitives like this template, if you >>> would like with javadocs. I could also start writing tests, but without >>> the byte-swap. >>> >>> Let me know what would be most helpful. >>> >>> Cheers, >>> >>> Lee >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Thu, May 20, 2021 at 11:36 AM leerho wrote: >>> >>>> Of course! >>>> >>>> On Thu, May 20, 2021 at 9:42 AM Maurizio Cimadamore < >>>> maurizio.cimadamore at oracle.com> wrote: >>>> >>>>> >>>>> On 20/05/2021 17:13, leerho wrote: >>>>> >>>>> I am not sure if the *dstSegSlice* requires the *srcCopyLen*. I would >>>>> hope that it is smart enough to realize that the input length is smaller >>>>> than the given offset minus the segment size. >>>>> >>>>> asSlice has an overload that just takes an offset and infers the >>>>> resulting size from there. >>>>> >>>>> But that doesn't seem what you want here - as you want the slice to >>>>> have a specific size (the size of the input array). >>>>> >>>>> MemorySegment::copyFrom wants the two segments to have the same size, >>>>> so I think you need that. >>>>> >>>>> In terms of performance, there's no difference between asSlice(offset) >>>>> and asSlice(offset, size) - you have to create a new segment anyway. >>>>> >>>>> Maurizio >>>>> >>>>> >>>>> -- > From my cell phone. > > -- >From my cell phone. From mcimadamore at openjdk.java.net Fri Jun 4 14:20:16 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 4 Jun 2021 14:20:16 GMT Subject: [foreign-memaccess+abi] RFR: 8268169: The system lookup can not find stdio functions such as printf on Windows 10 [v2] In-Reply-To: References: Message-ID: On Thu, 3 Jun 2021 17:36:21 GMT, Jorn Vernee wrote: >> Hi, >> >> This patch adds a way to look up stdio functions such as printf on Windows 10 through the system lookup. A fallback library is used which forces the generation of these inline functions, and exposes them through a table of function pointers. >> >> Thanks, >> Jorn > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments: > - add missing newline at end of file > - switch to valueOf instead of a static map Marked as reviewed by mcimadamore (Committer). ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/547 From jvernee at openjdk.java.net Fri Jun 4 16:11:18 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Fri, 4 Jun 2021 16:11:18 GMT Subject: RFR: Merge jdk:master Message-ID: Manual merge of jdk/master into panama-foreign/master to pull in 59a539f ------------- Commit messages: - Merge branch 'jdk_master' into merge_jdk_master - 8268129: LibraryLookup::ofDefault leaks symbols from loaded libraries - 8265444: Javadocs: jdk.jshell - small typo The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.java.net/panama-foreign/pull/550/files Stats: 1353 lines in 48 files changed: 626 ins; 621 del; 106 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/550.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/550/head:pull/550 PR: https://git.openjdk.java.net/panama-foreign/pull/550 From jvernee at openjdk.java.net Fri Jun 4 16:21:36 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Fri, 4 Jun 2021 16:21:36 GMT Subject: Integrated: Merge jdk:master In-Reply-To: References: Message-ID: <_xUS5BHPBFtqi7ajHtIGhQS_y5jnIlQwi97Q_zRTobQ=.60ae20e9-331e-496d-a1ce-f90b823e8ba5@github.com> On Fri, 4 Jun 2021 16:03:55 GMT, Jorn Vernee wrote: > Manual merge of jdk/master into panama-foreign/master to pull in 59a539f This pull request has now been integrated. Changeset: 4bcfd54d Author: Jorn Vernee URL: https://git.openjdk.java.net/panama-foreign/commit/4bcfd54d0f921f388137ee32d29739b82399f339 Stats: 1353 lines in 48 files changed: 626 ins; 621 del; 106 mod Merge Manual merge of jdk/master into panama-foreign/master to pull in 59a539f ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/550 From jvernee at openjdk.java.net Fri Jun 4 16:21:34 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Fri, 4 Jun 2021 16:21:34 GMT Subject: RFR: Merge jdk:master [v2] In-Reply-To: References: Message-ID: > Manual merge of jdk/master into panama-foreign/master to pull in 59a539f Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 275 commits: - Merge branch 'jdk_master' into merge_jdk_master - Automatic merge of jdk:master into master - Merge Manual merge of jdk/master into panama-foreign/master - Automatic merge of jdk:master into master - Automatic merge of jdk:master into master - Automatic merge of jdk:master into master - Automatic merge of jdk:master into master - Automatic merge of jdk:master into master - Automatic merge of jdk:master into master - Automatic merge of jdk:master into master - ... and 265 more: https://git.openjdk.java.net/panama-foreign/compare/59a539fe...0ec426cc ------------- Changes: https://git.openjdk.java.net/panama-foreign/pull/550/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=550&range=01 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/550.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/550/head:pull/550 PR: https://git.openjdk.java.net/panama-foreign/pull/550 From duke at openjdk.java.net Fri Jun 4 16:25:30 2021 From: duke at openjdk.java.net (J.Duke) Date: Fri, 4 Jun 2021 16:25:30 GMT Subject: [foreign-memaccess+abi] RFR: Merge master Message-ID: <1LlK4ABYVzSKgOEAc7O9oSkkeCXiIet0jZrIci7iCmI=.42d2d937-3983-46b2-9c11-3f91ee2f6755@github.com> Hi all, this is an _automatically_ generated pull request to notify you that there are 3 commits from the branch `master`that can **not** be merged into the branch `foreign-memaccess+abi`: Over 15 files contains merge conflicts. 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 +99:openjdk-bot-99 $ git checkout openjdk-bot-99 # 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-99:99 _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: - Merge - 8268129: LibraryLookup::ofDefault leaks symbols from loaded libraries - 8265444: Javadocs: jdk.jshell - small typo The webrev contains the conflicts with foreign-memaccess+abi: - merge conflicts: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=551&range=00.conflicts Changes: https://git.openjdk.java.net/panama-foreign/pull/551/files Stats: 1353 lines in 48 files changed: 626 ins; 621 del; 106 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/551.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/551/head:pull/551 PR: https://git.openjdk.java.net/panama-foreign/pull/551 From duke at openjdk.java.net Fri Jun 4 16:39:22 2021 From: duke at openjdk.java.net (J.Duke) Date: Fri, 4 Jun 2021 16:39:22 GMT Subject: [foreign-memaccess+abi] RFR: Merge master [v2] In-Reply-To: <1LlK4ABYVzSKgOEAc7O9oSkkeCXiIet0jZrIci7iCmI=.42d2d937-3983-46b2-9c11-3f91ee2f6755@github.com> References: <1LlK4ABYVzSKgOEAc7O9oSkkeCXiIet0jZrIci7iCmI=.42d2d937-3983-46b2-9c11-3f91ee2f6755@github.com> Message-ID: > Hi all, > > this is an _automatically_ generated pull request to notify you that there are 3 commits from the branch `master`that can **not** be merged into the branch `foreign-memaccess+abi`: > > Over 15 files contains merge conflicts. > > 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 +99:openjdk-bot-99 > $ git checkout openjdk-bot-99 > > # 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-99:99 > > > _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 five commits: - Undo spurious deletion - Merge branch 'foreign-memaccess+abi' into 99 - Merge Manual merge of jdk/master into panama-foreign/master to pull in 59a539f - 8268129: LibraryLookup::ofDefault leaks symbols from loaded libraries Reviewed-by: jvernee, psandoz - 8265444: Javadocs: jdk.jshell - small typo Reviewed-by: sundar ------------- Changes: https://git.openjdk.java.net/panama-foreign/pull/551/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=551&range=01 Stats: 82 lines in 17 files changed: 15 ins; 7 del; 60 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/551.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/551/head:pull/551 PR: https://git.openjdk.java.net/panama-foreign/pull/551 From duke at openjdk.java.net Fri Jun 4 17:38:37 2021 From: duke at openjdk.java.net (duke) Date: Fri, 4 Jun 2021 17:38:37 GMT Subject: git: openjdk/panama-foreign: foreign-jextract: 5 new changesets Message-ID: <9facdaa9-9df2-4152-a19f-559573ad6dff@openjdk.org> Changeset: 40c9e258 Author: Jan Lahoda Date: 2021-06-04 12:35:36 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/40c9e258b58cd1d227d20672a237c8777fd6d45c 8265444: Javadocs: jdk.jshell - small typo Reviewed-by: sundar ! src/jdk.jshell/share/classes/jdk/jshell/package-info.java Changeset: 59a539fe Author: Maurizio Cimadamore Date: 2021-06-04 12:53:17 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/59a539fef12dec6ba8af8a41000829402e7e9b72 8268129: LibraryLookup::ofDefault leaks symbols from loaded libraries Reviewed-by: jvernee, psandoz + make/modules/jdk.incubator.foreign/Lib.gmk ! src/java.base/share/classes/java/lang/ClassLoader.java ! src/java.base/share/classes/java/lang/System.java ! src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java ! src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java ! src/java.base/share/native/libjava/NativeLibraries.c ! src/java.base/share/native/libjava/jni_util.h ! src/java.base/unix/native/libjava/jni_util_md.c ! src/java.base/windows/native/libjava/jni_util_md.c ! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java - src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/LibraryLookup.java ! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemoryAddress.java ! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemorySegment.java + src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/SymbolLookup.java ! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/package-info.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/AbstractCLinker.java - src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/LibrariesHelper.java + src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/SystemLookup.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/ProgrammableInvoker.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/SharedUtils.java + src/jdk.incubator.foreign/share/native/libsyslookup/syslookup.c ! test/jdk/java/foreign/SafeFunctionAccessTest.java ! test/jdk/java/foreign/StdLibTest.java ! test/jdk/java/foreign/TestDowncall.java ! test/jdk/java/foreign/TestIllegalLink.java ! test/jdk/java/foreign/TestIntrinsics.java - test/jdk/java/foreign/TestLibraryLookup.java + test/jdk/java/foreign/TestNULLTarget.java ! test/jdk/java/foreign/TestNulls.java + test/jdk/java/foreign/TestSymbolLookup.java ! test/jdk/java/foreign/TestUpcall.java ! test/jdk/java/foreign/TestUpcallHighArity.java ! test/jdk/java/foreign/TestUpcallStructScope.java ! test/jdk/java/foreign/TestVarArgs.java ! test/jdk/java/foreign/handles/invoker_module/handle/invoker/MethodHandleInvoker.java ! test/jdk/java/foreign/handles/lookup_module/handle/lookup/MethodHandleLookup.java + test/jdk/java/foreign/libStdLib.c + test/jdk/java/foreign/malloc/TestMixedMallocFree.java + test/jdk/java/foreign/malloc/libMalloc.c ! test/jdk/java/foreign/stackwalk/TestStackWalk.java ! test/jdk/java/foreign/valist/VaListTest.java ! test/jdk/java/foreign/virtual/TestVirtualCalls.java ! test/micro/org/openjdk/bench/jdk/incubator/foreign/CallOverheadHelper.java ! test/micro/org/openjdk/bench/jdk/incubator/foreign/StrLenTest.java ! test/micro/org/openjdk/bench/jdk/incubator/foreign/Upcalls.java ! test/micro/org/openjdk/bench/jdk/incubator/foreign/VaList.java ! test/micro/org/openjdk/bench/jdk/incubator/foreign/points/support/PanamaPoint.java Changeset: 4bcfd54d Author: Jorn Vernee Date: 2021-06-04 16:17:55 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4bcfd54d0f921f388137ee32d29739b82399f339 Merge Manual merge of jdk/master into panama-foreign/master to pull in 59a539f Changeset: 9b8046d7 Author: J. Duke Committer: Jorn Vernee Date: 2021-06-04 17:35:48 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9b8046d7f3e579f89b30561b8e533ab2a76d3297 Merge master ! make/modules/jdk.incubator.foreign/Lib.gmk ! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/SharedUtils.java ! make/modules/jdk.incubator.foreign/Lib.gmk ! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/SharedUtils.java Changeset: cb521703 Author: duke Date: 2021-06-04 17:37:26 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/cb521703a967dc1def858ff829ea8e0b032d4a33 Automatic merge of foreign-memaccess+abi into foreign-jextract From duke at openjdk.java.net Fri Jun 4 17:39:24 2021 From: duke at openjdk.java.net (J.Duke) Date: Fri, 4 Jun 2021 17:39:24 GMT Subject: [foreign-memaccess+abi] Integrated: Merge master In-Reply-To: <1LlK4ABYVzSKgOEAc7O9oSkkeCXiIet0jZrIci7iCmI=.42d2d937-3983-46b2-9c11-3f91ee2f6755@github.com> References: <1LlK4ABYVzSKgOEAc7O9oSkkeCXiIet0jZrIci7iCmI=.42d2d937-3983-46b2-9c11-3f91ee2f6755@github.com> Message-ID: On Fri, 4 Jun 2021 16:19:16 GMT, J. Duke wrote: > Hi all, > > this is an _automatically_ generated pull request to notify you that there are 3 commits from the branch `master`that can **not** be merged into the branch `foreign-memaccess+abi`: > > Over 15 files contains merge conflicts. > > 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 +99:openjdk-bot-99 > $ git checkout openjdk-bot-99 > > # 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-99:99 > > > _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: 9b8046d7 Author: J. Duke Committer: Jorn Vernee URL: https://git.openjdk.java.net/panama-foreign/commit/9b8046d7f3e579f89b30561b8e533ab2a76d3297 Stats: 82 lines in 17 files changed: 15 ins; 7 del; 60 mod Merge master ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/551 From duke at openjdk.java.net Fri Jun 4 18:38:36 2021 From: duke at openjdk.java.net (duke) Date: Fri, 4 Jun 2021 18:38:36 GMT Subject: git: openjdk/panama-foreign: foreign-jextract: 2 new changesets Message-ID: <11533e8f-7032-462b-acf2-5a75d7498705@openjdk.org> Changeset: fc80193f Author: Jorn Vernee Date: 2021-06-04 18:36:23 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fc80193ffc6c6dbeab8ef7e98da19e47b4616af8 8268169: The system lookup can not find stdio functions such as printf on Windows 10 Reviewed-by: mcimadamore ! make/modules/jdk.incubator.foreign/Lib.gmk ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/SystemLookup.java + src/jdk.incubator.foreign/windows/native/libWinFallbackLookup/WinFallbackLookup.c ! test/jdk/java/foreign/StdLibTest.java - test/jdk/java/foreign/libStdLib.c Changeset: 59551617 Author: duke Date: 2021-06-04 18:37:28 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/59551617ad36d557aca2d3e564f58ca2d8d0c16b Automatic merge of foreign-memaccess+abi into foreign-jextract From jvernee at openjdk.java.net Fri Jun 4 18:39:27 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Fri, 4 Jun 2021 18:39:27 GMT Subject: [foreign-memaccess+abi] RFR: 8268169: The system lookup can not find stdio functions such as printf on Windows 10 [v3] In-Reply-To: References: Message-ID: > Hi, > > This patch adds a way to look up stdio functions such as printf on Windows 10 through the system lookup. A fallback library is used which forces the generation of these inline functions, and exposes them through a table of function pointers. > > 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-memaccess+abi' into WinFallbackLookup - Merge branch 'foreign-memaccess+abi' into WinFallbackLookup - Address review comments: - add missing newline at end of file - switch to valueOf instead of a static map - Add fallback lookup library for functions not found in ucrtbase.dll (such as printf) ------------- Changes: https://git.openjdk.java.net/panama-foreign/pull/547/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=547&range=02 Stats: 274 lines in 5 files changed: 204 ins; 58 del; 12 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/547.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/547/head:pull/547 PR: https://git.openjdk.java.net/panama-foreign/pull/547 From jvernee at openjdk.java.net Fri Jun 4 18:39:30 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Fri, 4 Jun 2021 18:39:30 GMT Subject: [foreign-memaccess+abi] Integrated: 8268169: The system lookup can not find stdio functions such as printf on Windows 10 In-Reply-To: References: Message-ID: <28jVFb9M-t8SeM5UUDHYt7kSQZU6eYpVtlwLttbMQBY=.73774341-9416-4fa4-80bb-0b54ffe0c227@github.com> On Thu, 3 Jun 2021 12:50:13 GMT, Jorn Vernee wrote: > Hi, > > This patch adds a way to look up stdio functions such as printf on Windows 10 through the system lookup. A fallback library is used which forces the generation of these inline functions, and exposes them through a table of function pointers. > > Thanks, > Jorn This pull request has now been integrated. Changeset: fc80193f Author: Jorn Vernee URL: https://git.openjdk.java.net/panama-foreign/commit/fc80193ffc6c6dbeab8ef7e98da19e47b4616af8 Stats: 274 lines in 5 files changed: 204 ins; 58 del; 12 mod 8268169: The system lookup can not find stdio functions such as printf on Windows 10 Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/547 From xgong at openjdk.java.net Mon Jun 7 09:11:31 2021 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Mon, 7 Jun 2021 09:11:31 GMT Subject: [vectorIntrinsics+mask] RFR: 8268154: Add masking support for vector load intrinsics Message-ID: This patch adds the predicate support for masked load vector operation, including the Vector API java implementation and hotspot intrinsics changes. The main changes contain: - Adding a new hotspot intrinsic method (`loadMasked`), which can transform the vector mask class and value to hotspot. It is called by the masked `"fromArray"` API in JAVA level. The compiler will generate the masked vector load node if the current platform supports the predicate feature and backend has implemented it. Otherwise, the vector blend pattern will be generated like before. - Adding the similar masked support for load/store boolean/char array. Note that the intrinsification when there is the array range bailout is not implemented in this patch. We are considering making it vectorized with predicate feature for SVE/AVX-512 as well, and will create a separate patch for it in future. Also note that this patch doesn't contain any backend changes. ------------- Commit messages: - 8268154: Add masking support for vector load intrinsics Changes: https://git.openjdk.java.net/panama-vector/pull/90/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=90&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268154 Stats: 854 lines in 43 files changed: 798 ins; 30 del; 26 mod Patch: https://git.openjdk.java.net/panama-vector/pull/90.diff Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/90/head:pull/90 PR: https://git.openjdk.java.net/panama-vector/pull/90 From sundar at openjdk.java.net Mon Jun 7 10:46:32 2021 From: sundar at openjdk.java.net (Athijegannathan Sundararajan) Date: Mon, 7 Jun 2021 10:46:32 GMT Subject: [foreign-jextract] RFR: 8268319: VersionCheck test fails for jextract on Windows In-Reply-To: References: Message-ID: On Mon, 7 Jun 2021 10:39:53 GMT, Jorn Vernee wrote: > The test tools/launcher/VersionCheck fails for jextract on Windows, because the filtering logic to filter out warnings in the output checks that the executable file name is "jextract", while on Windows it's "jextract.exe". So, the warnings are never filtered LGTM ------------- Marked as reviewed by sundar (Committer). PR: https://git.openjdk.java.net/panama-foreign/pull/552 From jvernee at openjdk.java.net Mon Jun 7 10:46:31 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Mon, 7 Jun 2021 10:46:31 GMT Subject: [foreign-jextract] RFR: 8268319: VersionCheck test fails for jextract on Windows Message-ID: The test tools/launcher/VersionCheck fails for jextract on Windows, because the filtering logic to filter out warnings in the output checks that the executable file name is "jextract", while on Windows it's "jextract.exe". So, the warnings are never filtered ------------- Commit messages: - Fix VersionCheck test on Windows Changes: https://git.openjdk.java.net/panama-foreign/pull/552/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=552&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268319 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/552.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/552/head:pull/552 PR: https://git.openjdk.java.net/panama-foreign/pull/552 From jvernee at openjdk.java.net Mon Jun 7 12:22:40 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Mon, 7 Jun 2021 12:22:40 GMT Subject: [foreign-jextract] Integrated: 8268319: VersionCheck test fails for jextract on Windows In-Reply-To: References: Message-ID: On Mon, 7 Jun 2021 10:39:53 GMT, Jorn Vernee wrote: > The test tools/launcher/VersionCheck fails for jextract on Windows, because the filtering logic to filter out warnings in the output checks that the executable file name is "jextract", while on Windows it's "jextract.exe". So, the warnings are never filtered This pull request has now been integrated. Changeset: 2a243938 Author: Jorn Vernee URL: https://git.openjdk.java.net/panama-foreign/commit/2a2439389574dbe7ecd70986f90949de74a5e19b Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8268319: VersionCheck test fails for jextract on Windows Reviewed-by: sundar ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/552 From leerho at gmail.com Mon Jun 7 23:55:56 2021 From: leerho at gmail.com (leerho) Date: Mon, 7 Jun 2021 16:55:56 -0700 Subject: Part 1 Proposal for JDK-8264594 In-Reply-To: References: <49091534-aa0f-81f7-2536-ff788e6377cf@oracle.com> <0b5ac260-4e87-4a92-53ca-b670a451f552@oracle.com> <50605287-4e54-7dde-14e5-d521c19301be@oracle.com> <95c04a58-4897-0d49-3f13-d8aa6b293006@oracle.com> <87a484de-9cdc-ddc7-ff73-6dad2641d5a4@oracle.com> Message-ID: Maurizio, I have updated MemoryCopy and TestMemoryCopy by extending the variable names to be even more clear, for example: - srcArr -> srcArray - srcSeg -> srcSegment - srcCopyLen -> srcCopyLengthInts - srcIndex -> srcIndexLongs - Etc. I also added a comment in the class javadoc describing the difference between variables with the word "index" and ones with the word "offset", etc. I have looked at what it would take to add overloads that refer to the segment offset in array element units. It can be done, but the names of these new methods will be kinda ugly or awkward: - copyFromArrayAtIndex -- confusing since the array uses index units already - copyAtIndexFromArray -- not much better - copyFromArrayWithIndex -- nah - copyFromArrayToSegementUsingIndex -- a little more clear, but really awkward If you have any better ideas, I am open. (But IMHO, I don't think we need this :) ) Please let me know what the next step should be :) Thanks! Lee. On Fri, Jun 4, 2021 at 7:09 AM leerho wrote: > Maurizio, > Thank you for your reply. I agree with your observation in the difference > between the single item case and the bulk copy. I guess I became so > familiar with how offsets are handled in Unsafe where the single element > and bulk copy cases the references to memory are always in bytes, it seamed > so simple and natural. > > In my experience anyway, reading and writing data to off-heap almost > always involves a mix of preamble elements and bulk copy arrays where it > was necessary to track the offset in bytes, where the multibyte elements > may not be correctly aligned to the base of the allocated segment, or God > forbid, the arrays. > > What is most important is getting this into the JDK, and if I have to add > more overloads, I will :) > > Lee. > > On Fri, Jun 4, 2021 at 2:34 AM Maurizio Cimadamore < > maurizio.cimadamore at oracle.com> wrote: > >> >> On 04/06/2021 01:32, leerho wrote: >> >> When I first saw all the logical index overloads in MemoryAccess I >> shuddered. It is a lot of API clutter as far as I?m concerned. But just >> because we made that mistake with MemoryAccess doesn?t mean we have to >> continue propagating it. >> >> I'm sorry, I just don't see that as being a "mistake". Code like this: >> >> ``` >> for (int i = 0 ; i < limit ; i++) { >> long val = MemoryAccess.getLongAtIndex(segment, i); >> ... >> } >> ``` >> >> Is _extremely_ common. While it's true that memory segment is an unbiased >> array of bytes, there are times you want to access it in a more structured >> form - and saying "you can't do that" because it adds overloads doesn't >> seem like a great solution to me. >> >> >> Also I have explicitly named the two offsets very differently to try to >> make it clear that they are very different. I guess I could go further and >> name the ?srcIndex? -> ?srcIndexLongs? for the long array case, for >> example. But since ?index? is used elsewhere as the logical index I >> assumed that this would not be necessary. >> >> But I would much rather use longer, more explicit names than propagate >> API clutter. >> >> I was thinking overnight that, perhaps, the memory copy and the single >> element cases are different. When you do single access (see above) you do >> that frequently in a loop - and you often get elements of the same type. As >> stated above, asking developers to work in terms of offsets seems a bit >> odd, when they are really accessing a flat array of element type T. >> >> In the case of bulk copy, I don't think there's the same degree of >> pressure - you will probably call the bulk copy at the beginning, or at the >> end of your computation (or both ends!) - and having an offset shift is >> more tolerable. >> >> So, I'm open to evaluating something more minimal, and see how far we can >> get with it. >> >> Maurizio >> >> >> Lee >> >> On Thu, Jun 3, 2021 at 1:26 PM Maurizio Cimadamore < >> maurizio.cimadamore at oracle.com> wrote: >> >>> Thanks. >>> >>> While I agree that a segment is just a bunch of bytes, I think also >>> think that having an API which takes two indices at the same time, one >>> logical and one physical is kind of evil. I bet that a lot of developers >>> will get that wrong, at least the first time. >>> >>> What you say about segments being an array of bytes, and thus not >>> needing index-based overloads can also be said for MemoryAccess class - but >>> I believe that the index-based accessors in the are quite popular. >>> >>> But overall, my worry is not performances, or symmetry with respect to >>> other APIs - my main worry is what I said above: that people will just >>> assume that indices are logical for both the segment and the array - so >>> overloads with clearly different names should help quite a bit IMHO. >>> >>> >>> Maurizio >>> On 03/06/2021 20:50, leerho wrote: >>> >>> Maurizio, >>> Here is the MemoryCopy class (w/o byte swap) and the TestMemoryCopy >>> class (w/o testing byte swap). >>> >>> I copied from the TestMemoryAccess class in that I noticed that there is >>> no package statement. I am not sure what @SuppressWarnings are allowed in >>> your test environment, I suspect I should remove all of them. >>> >>> When the MemorySegment copyFrom(MemorySegment, MemoryLayout, ByteOrder) >>> becomes available I can add the tests for that. >>> >>> *IMHO* >>> >>> I feel strongly that there is no need to additionally overload these >>> methods with the segment offset specified in array index units. It is so >>> trivial to convert from one to the other and it can be done easily in the >>> method argument with a simple multiply by 2, 4 or 8. This should compile >>> down to a simple shift, which becomes a single cycle CPU instruction. So >>> this is not a performance issue. >>> >>> Furthermore, it is best that the user becomes accustomed to thinking of >>> a segment fundamentally as an array of bytes. Once a segment is loaded >>> with some primitive array, the segment loses the context of the type of the >>> array it was loaded with; in effect, a kind of "type erasure" similar to >>> Java's generics. This is one of the reasons that MemorySegments can be so >>> powerful. >>> >>> >>> I have been programming with the "MemorySegment" concept for a number of >>> years now and find that keeping in mind that segments are just bytes is >>> very useful. >>> >>> >>> Let me know what you think. >>> >>> Lee. >>> >>> >>> >>> On Mon, May 31, 2021 at 6:56 AM Maurizio Cimadamore < >>> maurizio.cimadamore at oracle.com> wrote: >>> >>>> Hi Lee, >>>> this looks good. >>>> >>>> One thing I note is that there's an ambiguity as to whether the segment >>>> index is expressed as a logical index, or a raw byte offset. Your snippet >>>> does the latter. If we want to follow MemoryAccess, perhaps that calls for >>>> 2 overloads (copyFromArrayAtIndex/copyFromArrayAtOffset), as I imagine both >>>> could be useful, depending on the case? >>>> >>>> The javadoc will have to say something when the segment being used is >>>> backed by the very array that is the source/target of the copy (we have >>>> some text like that in MemorySegment::copyFrom). >>>> >>>> I think it would be helpful to progress further with this, add the >>>> remaining templates (w/o ByteOrder, for now) test and see how it works in >>>> practice. >>>> >>>> I will add (or just file a simple PR, so that you can just borrow from >>>> it - should be a single method) something to do the segment copy with swap. >>>> >>>> Thanks! >>>> Maurizio >>>> On 28/05/2021 22:37, leerho wrote: >>>> >>>> Maurizio, >>>> >>>> Again sorry about the delay. >>>> >>>> Attached is a template proposal for the MemoryCopy class. >>>> >>>> I can't complete this without your proposed new copyFrom(...) method in >>>> MemorySegment. As it is written, it should work, but without the byte swap >>>> capability. >>>> >>>> I can complete the rest of the primitives like this template, if you >>>> would like with javadocs. I could also start writing tests, but without >>>> the byte-swap. >>>> >>>> Let me know what would be most helpful. >>>> >>>> Cheers, >>>> >>>> Lee >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Thu, May 20, 2021 at 11:36 AM leerho wrote: >>>> >>>>> Of course! >>>>> >>>>> On Thu, May 20, 2021 at 9:42 AM Maurizio Cimadamore < >>>>> maurizio.cimadamore at oracle.com> wrote: >>>>> >>>>>> >>>>>> On 20/05/2021 17:13, leerho wrote: >>>>>> >>>>>> I am not sure if the *dstSegSlice* requires the *srcCopyLen*. I >>>>>> would hope that it is smart enough to realize that the input length is >>>>>> smaller than the given offset minus the segment size. >>>>>> >>>>>> asSlice has an overload that just takes an offset and infers the >>>>>> resulting size from there. >>>>>> >>>>>> But that doesn't seem what you want here - as you want the slice to >>>>>> have a specific size (the size of the input array). >>>>>> >>>>>> MemorySegment::copyFrom wants the two segments to have the same size, >>>>>> so I think you need that. >>>>>> >>>>>> In terms of performance, there's no difference between >>>>>> asSlice(offset) and asSlice(offset, size) - you have to create a new >>>>>> segment anyway. >>>>>> >>>>>> Maurizio >>>>>> >>>>>> >>>>>> -- >> From my cell phone. >> >> -- > From my cell phone. > From elect86 at gmail.com Tue Jun 8 07:26:15 2021 From: elect86 at gmail.com (Giuseppe Barbieri) Date: Tue, 8 Jun 2021 09:26:15 +0200 Subject: MethodHandler out of a non-static method In-Reply-To: References: Message-ID: Thanks Maurizio and Remi, that helped Playing around I also got it working by using `bind` var displayHandle = MethodHandles.lookup().bind(teapot, "display", MethodType.methodType(void.class)); var displayStub = CLinker.getInstance().upcallStub(displayHandle, FunctionDescriptor.ofVoid(), scope); What's the difference? Because I'd expect for `findVirtual` to be used only on methods in implementation classes of abstract classes Another question, I'm trying to setup a test project with Gradle, but I'm having a lot of issues, mainly because Gradle supports only up to jdk 16. Is possible to run your application with a separate jdk (toolchain) but then you need to use the `application` plugin and cannot rely anymore on the comfortable Idea UI. Unless you switch and run your code using the IDE instead of Gradle, but then I get into some other exceptions. Moreover, some imports remain still unresolved. So, I'd like to skip this trainwreck all at once and ask directly if anybody here has a working base scenario with the latest EA jdk 17 and Gradle Thanks in advance Il giorno gio 3 giu 2021 alle ore 11:33 Maurizio Cimadamore < maurizio.cimadamore at oracle.com> ha scritto: > Hi Giuseppe > > On 02/06/2021 23:52, Giuseppe Barbieri wrote: > > Hi, > > > > excited from the last development, I came back giving a try to the latest > > jdk build (the partial 17 available on the site) and I'm trying to > > update/fix the opengl sample > > > > First of all, it looks like `jextract` doesn't accept anymore the option > to > > produce an output jar. I had to manually compress the resulting folder to > > zip and rename, before importing in the target project. > > We decided to simplify jextract and focus on source code generation, > which seems to be the mode that most people want to work with, and it's > also the "more primitive": you can derive classes (and jars) from it. > > If you are using it in a project, you might consider directly checking > in the extracted sources in your project. If you are using an IDE, it is > going to improve your experience a little bit (the classfiles generated > by the old jextract were poorly understood by some of the IDEs out > there, which led to issues in indexing). > > > > > > It'd be cool if jextract could output directly the jar (and the sources) > > > > Coming back to my issue, how can I retrieve the MethodHandler out of a > > non-static method? > > You mean you want to create a MethodHandle for an instance method? > > Let's see (I'll use jshell to make sure my code doesn't have any typos > :-) ): > > ``` > jshell> class Foo { > ...> void greet(String msg) { System.out.println(msg); } > ...> } > | created class Foo > > jshell> import java.lang.invoke.*; > > jshell> MethodHandle greetMH = > MethodHandles.lookup().findVirtual(Foo.class, "greet", > MethodType.methodType(void.class, String.class)); > greetMH ==> MethodHandle(Foo,String)void > > jshell> greetMH.invoke(new Foo(), "Panama"); > Panama > ``` > > Is this what you were looking for? > > Cheers > Maurizio > > > > > > > Thanks in advance > From forax at univ-mlv.fr Tue Jun 8 08:34:33 2021 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 8 Jun 2021 10:34:33 +0200 (CEST) Subject: MethodHandler out of a non-static method In-Reply-To: References: Message-ID: <243056011.1075978.1623141273942.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Giuseppe Barbieri" > ?: "Maurizio Cimadamore" > Cc: "panama-dev at openjdk.java.net'" > Envoy?: Mardi 8 Juin 2021 09:26:15 > Objet: Re: MethodHandler out of a non-static method > Thanks Maurizio and Remi, that helped > > Playing around I also got it working by using `bind` > > var displayHandle = MethodHandles.lookup().bind(teapot, "display", > MethodType.methodType(void.class)); > var displayStub = CLinker.getInstance().upcallStub(displayHandle, > FunctionDescriptor.ofVoid(), scope); > > > What's the difference? Because I'd expect for `findVirtual` to be used only > on methods in implementation classes of abstract classes A method handle unlike its name suggest is a function pointer, not a method pointer. So when you take a method and ask for a function pointer to it, you have a supplementary first parameter, the one corresponding to this. By example, for class A { void foo(int i) { ... } } findVirtual returns a method handle with the signature: void foo(A this, int i) if you want to call a method handle always on the same instance, you can use bindTo() (or insertArguments), to say that the first argument is always that same var a = new A(); var mh = ... var boundMH = mh.bindTo(a); Here, boundMH is "void foo(A this, int i)" with this = a so it's a function with only one parameter, i of type int. Now what bind() does is findVirtual(getClass(), ...) + bindTo, on your example var mh = lookup.findVirtual(teapot.getClass(), "display", MethodType.methodType(void.class)); mh = mh.bindTo(teapot); This idea that when you want to see a method as a function, you can pass the receiver (the value of 'this') as first argument is something very common in programming language, you have it with method handle but you also have it when using method reference in Java or bound method in Python [1], the method bind in JavaScript [2], etc. Using method reference: // method reference seen as a function BiConsumer consumer = PrintStream::println; // bound method reference PrintStream out = System.out; Consumer consumer = out::println; > > Another question, I'm trying to setup a test project with Gradle, but I'm > having a lot of issues, mainly because Gradle supports only up to jdk 16. Don't use Gradle with a not yet released JDK. Gradle is very smart in the way it incrementally compile things, but it has the price of not working with unreleased JDK. A plain old Maven pom file is usually enough. > > Is possible to run your application with a separate jdk (toolchain) but > then you need to use the `application` plugin and cannot rely anymore on > the comfortable Idea UI. > Unless you switch and run your code using the IDE instead of Gradle, but > then I get into some other exceptions. Moreover, some imports remain still > unresolved. > > So, I'd like to skip this trainwreck all at once and ask directly if > anybody here has a working base scenario with the latest EA jdk 17 and > Gradle > > > Thanks in advance regards, R?mi [1] https://www.quora.com/What-is-a-bound-method-in-Python [2] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Function/bind > > > > Il giorno gio 3 giu 2021 alle ore 11:33 Maurizio Cimadamore < > maurizio.cimadamore at oracle.com> ha scritto: > >> Hi Giuseppe >> >> On 02/06/2021 23:52, Giuseppe Barbieri wrote: >> > Hi, >> > >> > excited from the last development, I came back giving a try to the latest >> > jdk build (the partial 17 available on the site) and I'm trying to >> > update/fix the opengl sample >> > >> > First of all, it looks like `jextract` doesn't accept anymore the option >> to >> > produce an output jar. I had to manually compress the resulting folder to >> > zip and rename, before importing in the target project. >> >> We decided to simplify jextract and focus on source code generation, >> which seems to be the mode that most people want to work with, and it's >> also the "more primitive": you can derive classes (and jars) from it. >> >> If you are using it in a project, you might consider directly checking >> in the extracted sources in your project. If you are using an IDE, it is >> going to improve your experience a little bit (the classfiles generated >> by the old jextract were poorly understood by some of the IDEs out >> there, which led to issues in indexing). >> > > > > > >> >> > >> > It'd be cool if jextract could output directly the jar (and the sources) >> > >> > Coming back to my issue, how can I retrieve the MethodHandler out of a >> > non-static method? >> >> You mean you want to create a MethodHandle for an instance method? >> >> Let's see (I'll use jshell to make sure my code doesn't have any typos >> :-) ): >> >> ``` >> jshell> class Foo { >> ...> void greet(String msg) { System.out.println(msg); } >> ...> } >> | created class Foo >> >> jshell> import java.lang.invoke.*; >> >> jshell> MethodHandle greetMH = >> MethodHandles.lookup().findVirtual(Foo.class, "greet", >> MethodType.methodType(void.class, String.class)); >> greetMH ==> MethodHandle(Foo,String)void >> >> jshell> greetMH.invoke(new Foo(), "Panama"); >> Panama >> ``` >> >> Is this what you were looking for? >> >> Cheers >> Maurizio >> >> > >> > >> > Thanks in advance From maurizio.cimadamore at oracle.com Tue Jun 8 13:59:55 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 8 Jun 2021 14:59:55 +0100 Subject: Part 1 Proposal for JDK-8264594 In-Reply-To: References: <0b5ac260-4e87-4a92-53ca-b670a451f552@oracle.com> <50605287-4e54-7dde-14e5-d521c19301be@oracle.com> <95c04a58-4897-0d49-3f13-d8aa6b293006@oracle.com> <87a484de-9cdc-ddc7-ff73-6dad2641d5a4@oracle.com> Message-ID: <0bd0724a-ce06-bb25-10a9-9f0641b359c1@oracle.com> Hi Lee, thanks for this, I'll try to put together a PR in the next week or so. Re. overloads I was thinking about how the ByteBuffer API goes about them, and, in I see that that API doesn't have the same issues, given that ByteBuffer only provides bulk copy for byte arrays. If you want to bulk copy a double[] you have to convert to a DoubleBuffer first and then copy (and then use logical indices for the buffer too). Question: do you have concrete use cases where you'd like to copy contents of a double[] at non-aligned positions inside a segment? I'm asking because, in principle we could leave the methods in CopyMemory cover the aligned, logical indices only part of the API. And ask the user to fall back to MemorySegment::copyFrom if they really really want unaligned (which should be uncommon?). Cheers Maurizio On 08/06/2021 00:55, leerho wrote: > Maurizio, > I have updated MemoryCopy and TestMemoryCopy by extending the variable > names to be even more clear, for example: > > * srcArr -> srcArray > * srcSeg -> srcSegment > * srcCopyLen -> srcCopyLengthInts > * srcIndex -> srcIndexLongs > * Etc. > > I also added a comment in the class javadoc describing the difference > between variables with the word "index" and ones with the word > "offset", etc. > > I have looked at what it would take to add overloads that refer to the > segment offset in array element units.? It can be done, but the names > of these new methods will be kinda ugly or awkward: > > * copyFromArrayAtIndex -- confusing since the array uses index units > already > * copyAtIndexFromArray -- not much better > * copyFromArrayWithIndex -- nah > * copyFromArrayToSegementUsingIndex -- a little more clear, but > really awkward > > If you have any better ideas, I am open.? (But IMHO, I don't think we > need this :) ) > > Please let me know what the next step should be :) > > Thanks! > > Lee. > > On Fri, Jun 4, 2021 at 7:09 AM leerho > wrote: > > Maurizio, > Thank you for your reply.? I agree with your observation in the > difference between the single item case and the bulk copy.? I > guess I became so familiar with how offsets are handled in Unsafe > where the single element and bulk copy cases the references to > memory are always in bytes, it seamed so simple and natural. > > In my experience anyway, reading and writing data to off-heap > almost always involves a mix of preamble elements and bulk copy > arrays where it was necessary to track the offset in bytes, where > the multibyte elements may not be correctly aligned to the base of > the allocated segment, or God forbid, the arrays. > > What is most important is getting this into the JDK, and if I have > to add more overloads, I will :) > > Lee. > > On Fri, Jun 4, 2021 at 2:34 AM Maurizio Cimadamore > > wrote: > > > On 04/06/2021 01:32, leerho wrote: >> When I first saw all the logical index overloads in >> MemoryAccess I shuddered.? It is a lot of API clutter as far >> as I?m concerned. But just because we made that mistake with >> MemoryAccess doesn?t mean we have to continue propagating it. > > I'm sorry, I just don't see that as being a "mistake". Code > like this: > > ``` > for (int i = 0 ; i < limit ; i++) { > ?? long val = MemoryAccess.getLongAtIndex(segment, i); > ?? ... > } > ``` > > Is _extremely_ common. While it's true that memory segment is > an unbiased array of bytes, there are times you want to access > it in a more structured form - and saying "you can't do that" > because it adds overloads doesn't seem like a great solution > to me. > >> >> Also I have explicitly named the two offsets very differently >> to try to make it clear that they are very different.? I >> guess I could go further and name the ?srcIndex? -> >> ?srcIndexLongs? for the long array case, for example.? But >> since ?index? is used elsewhere as the logical index I >> assumed that this would not be necessary. >> >> But I would much rather use longer, more explicit names than >> propagate API clutter. > > I was thinking overnight that, perhaps, the memory copy and > the single element cases are different. When you do single > access (see above) you do that frequently in a loop - and you > often get elements of the same type. As stated above, asking > developers to work in terms of offsets seems a bit odd, when > they are really accessing a flat array of element type T. > > In the case of bulk copy, I don't think there's the same > degree of pressure - you will probably call the bulk copy at > the beginning, or at the end of your computation (or both > ends!) - and having an offset shift is more tolerable. > > So, I'm open to evaluating something more minimal, and see how > far we can get with it. > > Maurizio > >> >> Lee >> >> On Thu, Jun 3, 2021 at 1:26 PM Maurizio Cimadamore >> > > wrote: >> >> Thanks. >> >> While I agree that a segment is just a bunch of bytes, I >> think also think that having an API which takes two >> indices at the same time, one logical and one physical is >> kind of evil. I bet that a lot of developers will get >> that wrong, at least the first time. >> >> What you say about segments being an array of bytes, and >> thus not needing index-based overloads can also be said >> for MemoryAccess class - but I believe that the >> index-based accessors in the are quite popular. >> >> But overall, my worry is not performances, or symmetry >> with respect to other APIs - my main worry is what I said >> above: that people will just assume that indices are >> logical for both the segment and the array - so overloads >> with clearly different names should help quite a bit IMHO. >> >> >> Maurizio >> >> On 03/06/2021 20:50, leerho wrote: >>> Maurizio, >>> Here is the MemoryCopy class (w/o byte swap) and the >>> TestMemoryCopy class (w/o testing byte swap). >>> >>> I copied from the TestMemoryAccess class in that I >>> noticed that there is no package statement.? I am not >>> sure what?@SuppressWarnings are allowed in your test >>> environment, I suspect I should remove all of them. >>> >>> When the MemorySegment?copyFrom(MemorySegment, >>> MemoryLayout, ByteOrder) becomes available I can add the >>> tests for that. >>> >>> *IMHO* >>> >>> I feel strongly that there is no need to >>> additionally overload these methods with the segment >>> offset specified in array index units.? It is so >>> trivial to convert from one to the other and it can >>> be done easily in the method argument?with a simple >>> multiply?by 2, 4 or 8. This should compile down to a >>> simple shift, which becomes a single cycle CPU >>> instruction.? So this?is not a performance issue. >>> >>> Furthermore, it is best that the user becomes >>> accustomed to thinking of a segment fundamentally as >>> an array of bytes.? Once a segment is loaded with >>> some primitive array, the segment loses the context >>> of the type of the array it was loaded with; in >>> effect, a kind of "type erasure" similar to Java's >>> generics.? This is one of the reasons that >>> MemorySegments can be so powerful. >>> >>> >>> I have been programming with the "MemorySegment" >>> concept for a number of years now and find that >>> keeping in mind that segments are just bytes is very >>> useful. >>> >>> >>> Let me know what you think. >>> >>> Lee. >>> >>> >>> >>> On Mon, May 31, 2021 at 6:56 AM Maurizio Cimadamore >>> >> > wrote: >>> >>> Hi Lee, >>> this looks good. >>> >>> One thing I note is that there's an ambiguity as to >>> whether the segment index is expressed as a logical >>> index, or a raw byte offset. Your snippet does the >>> latter. If we want to follow MemoryAccess, perhaps >>> that calls for 2 overloads >>> (copyFromArrayAtIndex/copyFromArrayAtOffset), as I >>> imagine both could be useful, depending on the case? >>> >>> The javadoc will have to say something when the >>> segment being used is backed by the very array that >>> is the source/target of the copy (we have some text >>> like that in MemorySegment::copyFrom). >>> >>> I think it would be helpful to progress further with >>> this, add the remaining templates (w/o ByteOrder, >>> for now) test and see how it works in practice. >>> >>> I will add (or just file a simple PR, so that you >>> can just borrow from it - should be a single method) >>> something to do the segment copy with swap. >>> >>> Thanks! >>> Maurizio >>> >>> On 28/05/2021 22:37, leerho wrote: >>>> Maurizio, >>>> >>>> Again sorry about the delay. >>>> >>>> Attached is a template proposal for the MemoryCopy >>>> class. >>>> >>>> I can't complete this without your proposed new >>>> copyFrom(...) method in MemorySegment.?As it is >>>> written, it should work, but without the byte swap >>>> capability. >>>> >>>> I can complete the rest of the primitives like this >>>> template, if you would like with javadocs.? I could >>>> also start writing tests, but without the byte-swap. >>>> >>>> Let me know what would be most?helpful. >>>> >>>> Cheers, >>>> >>>> Lee >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Thu, May 20, 2021 at 11:36 AM leerho >>>> > wrote: >>>> >>>> Of?course! >>>> >>>> On Thu, May 20, 2021 at 9:42 AM Maurizio >>>> Cimadamore >>> > wrote: >>>> >>>> >>>> On 20/05/2021 17:13, leerho wrote: >>>>> I am not sure if the /dstSegSlice/ >>>>> requires the /srcCopyLen/. I would hope >>>>> that it is smart enough to realize that >>>>> the input length is smaller than the given >>>>> offset minus the segment size. >>>> >>>> asSlice has an overload that just takes an >>>> offset and infers the resulting size from >>>> there. >>>> >>>> But that doesn't seem what you want here - >>>> as you want the slice to have a specific >>>> size (the size of the input array). >>>> >>>> MemorySegment::copyFrom wants the two >>>> segments to have the same size, so I think >>>> you need that. >>>> >>>> In terms of performance, there's no >>>> difference between asSlice(offset) and >>>> asSlice(offset, size) - you have to create >>>> a new segment anyway. >>>> >>>> Maurizio >>>> >>>> >> -- >> From my cell phone. > > -- > From my cell phone. > From mgkwill at openjdk.java.net Tue Jun 8 15:50:20 2021 From: mgkwill at openjdk.java.net (Marcus G K Williams) Date: Tue, 8 Jun 2021 15:50:20 GMT Subject: [vectorIntrinsics] RFR: 8244490: [vector] Move Vector API micro benchmarks under test/micro [v2] In-Reply-To: References: Message-ID: <-zCHbBXcxWetn2LxDmZpXUytd1HKvfCJJzumW-ljFR4=.3d5be0b9-5738-412f-ba6c-6c5f67068b69@github.com> > Vector API micro benchmarks are currently located under test/jdk/jdk/incubator/vector/benchmark which makes them rather as "dead" code without possibility to built and run. > > The proper location for micro benchmarks is actually test/micro/ directory. > It would be nice to move Vector API benchmarks there so they can be built automatically as part 'test-image' make target. > Once they are built they can be run as > make run-test TEST=micro:BENCHMARK_TEST_NAME Marcus G K Williams has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: - fix test build issues Signed-off-by: Marcus G K Williams - Paul Review Signed-off-by: Marcus G K Williams - Revert "Vector Micro Tests Draft Move" This reverts commit 71b1c1d3513745ccc51fa184af2069215449bc93. - Revert "pom.xml" This reverts commit ef323d7cd8cd083849d36d60598752512db437d7. - add missing readme pom.xml Signed-off-by: Marcus G K Williams - Vector Micro Tests Draft Move Signed-off-by: Marcus G K Williams ------------- Changes: https://git.openjdk.java.net/panama-vector/pull/77/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=77&range=01 Stats: 332 lines in 54 files changed: 10 ins; 198 del; 124 mod Patch: https://git.openjdk.java.net/panama-vector/pull/77.diff Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/77/head:pull/77 PR: https://git.openjdk.java.net/panama-vector/pull/77 From mgkwill at openjdk.java.net Tue Jun 8 15:59:25 2021 From: mgkwill at openjdk.java.net (Marcus G K Williams) Date: Tue, 8 Jun 2021 15:59:25 GMT Subject: [vectorIntrinsics] RFR: 8244490: [vector] Move Vector API micro benchmarks under test/micro [v3] In-Reply-To: References: Message-ID: > Vector API micro benchmarks are currently located under test/jdk/jdk/incubator/vector/benchmark which makes them rather as "dead" code without possibility to built and run. > > The proper location for micro benchmarks is actually test/micro/ directory. > It would be nice to move Vector API benchmarks there so they can be built automatically as part 'test-image' make target. > Once they are built they can be run as > make run-test TEST=micro:BENCHMARK_TEST_NAME Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision: Remove executable from gen-tests.sh Signed-off-by: Marcus G K Williams ------------- Changes: - all: https://git.openjdk.java.net/panama-vector/pull/77/files - new: https://git.openjdk.java.net/panama-vector/pull/77/files/e7c9a1ef..4c31d216 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=77&range=02 - incr: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=77&range=01-02 Stats: 0 lines in 1 file changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/panama-vector/pull/77.diff Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/77/head:pull/77 PR: https://git.openjdk.java.net/panama-vector/pull/77 From mgkwill at openjdk.java.net Tue Jun 8 16:02:34 2021 From: mgkwill at openjdk.java.net (Marcus G K Williams) Date: Tue, 8 Jun 2021 16:02:34 GMT Subject: [vectorIntrinsics] RFR: 8244490: [vector] Move Vector API micro benchmarks under test/micro In-Reply-To: References: Message-ID: On Thu, 6 May 2021 17:54:37 GMT, Paul Sandoz wrote: >> Vector API micro benchmarks are currently located under test/jdk/jdk/incubator/vector/benchmark which makes them rather as "dead" code without possibility to built and run. >> >> The proper location for micro benchmarks is actually test/micro/ directory. >> It would be nice to move Vector API benchmarks there so they can be built automatically as part 'test-image' make target. >> Once they are built they can be run as >> make run-test TEST=micro:BENCHMARK_TEST_NAME > > I looked more in detail, there are some immediate issues, and i think an architectural issue with the split. > > The more immediate issues are: > > 1. Some benchmark tests fail to build via `make`. Some are related to bad ASCII characters in comments, some due to compiler warnings, and others due to external dependencies in the `pom.xml` (namely `org.junit.jupiter:junit-jupiter-api`). I think all those are fixable. (See https://openjdk.java.net/groups/build/doc/testing.html for configuring, compiling, and executing JMH tests.) > 2. The structure under `test/micro` is misleading, and does not follow directory to package name convention. This is also fixable. I think we need to remove the maven project and merge in under `test/micro/org/openjdk/bench/jdk/incubator/vector`. We remove the maven project and place the non-generated benchmark files directly under the aforementioned directory (and fix the ones that fail to compile). Generated benchmarks could be placed under, say, `operation`. > > Initially I thought it was fine that generation scripts were split between unit tests and performance tests, but architecturally, i now think it better to keep one set of bash scripts for generated code, maintained under the `vector` module. These are complex and splitting will cause divergence. These scripts can generate the `operation` performance tests under the `test/micro` directory at the appropriate location. Thanks again for your review @PaulSandoz. I set this aside until now due to priority work for jdk17 freeze. Updated per review. 1. Reverted original draft refactor, to keep perf. test generation code in original location. 2. Changed location of generated perf. tests to `test/micro/org/openjdk/bench/jdk/incubator/vector/operation` 3. Moved non-generated tests and respective directories to `test/micro/org/openjdk/bench/jdk/incubator/vector/`. I.E.: `test/micro/org/openjdk/bench/jdk/incubator/vector/bigdata` `test/micro/org/openjdk/bench/jdk/incubator/vector/crypto` `test/micro/org/openjdk/bench/jdk/incubator/vector/utf8` 4. Fixed broken tests, now all tests build. 4a. Fixed comments that used invalid characters 4b. Refactored to remove junit dependency 4c. Removed static from some `@benchmark` methods to fix `static method should be qualified by type name, VectorDistance, instead of by an expression` compile warning. 5. Updated package location of all moved files and generated files to `org.openjdk.bench.jdk.incubator.vector.` 6. Removed pom.xml and other no longer needed files. I can now build and run all tests using: `make test TEST="micro:org.openjdk.bench.jdk.incubator.vector" MICRO="FORK=2;WARMUP_ITER=5;" CONF=linux-x86_64-server-release` # Run complete. Total time: 04:40:06 Benchmark (ARRAY_LENGTH) (dataSize) (maxBytes) (size) Mode Cnt Score Error Units o.o.b.j.i.v.bigdata.BooleanArrayCheck.filterAll 1024 N/A N/A N/A thrpt 5 3884.266 ? 110.491 ops/ms o.o.b.j.i.v.bigdata.BooleanArrayCheck.filterAll_vec 1024 N/A N/A N/A thrpt 5 16060.256 ? 5485.055 ops/ms o.o.b.j.i.v.bigdata.ValueRangeCheckAndCastL2I.castL2I 1024 N/A N/A N/A thrpt 5 1470.185 ? 87.374 ops/ms o.o.b.j.i.v.bigdata.ValueRangeCheckAndCastL2I.castL2I_vec 1024 N/A N/A N/A thrpt 5 1725.998 ? 763.099 ops/ms o.o.b.j.i.v.bigdata.VectorDistance.cosinesimilOptimizedScalarDouble N/A N/A N/A N/A thrpt 5 3466.435 ? 61.524 ops/ms o.o.b.j.i.v.bigdata.VectorDistance.cosinesimilOptimizedScalarFloat N/A N/A N/A N/A thrpt 5 2949.337 ? 167.843 ops/ms o.o.b.j.i.v.bigdata.VectorDistance.cosinesimilOptimizedVectorDouble128 N/A N/A N/A N/A thrpt 5 3831.298 ? 670.538 ops/ms o.o.b.j.i.v.bigdata.VectorDistance.cosinesimilOptimizedVectorDouble256 N/A N/A N/A N/A thrpt 5 6916.338 ? 1240.536 ops/ms o.o.b.j.i.v.bigdata.VectorDistance.cosinesimilOptimizedVectorDoubleMax N/A N/A N/A N/A thrpt 5 6922.271 ? 1193.232 ops/ms o.o.b.j.i.v.bigdata.VectorDistance.cosinesimilOptimizedVectorFloat128 N/A N/A N/A N/A thrpt 5 7667.293 ? 1627.940 ops/ms o.o.b.j.i.v.bigdata.VectorDistance.cosinesimilOptimizedVectorFloat256 N/A N/A N/A N/A thrpt 5 12881.137 ? 2561.933 ops/ms o.o.b.j.i.v.bigdata.VectorDistance.cosinesimilOptimizedVectorFloatMax N/A N/A N/A N/A thrpt 5 12870.951 ? 2536.147 ops/ms o.o.b.j.i.v.bigdata.VectorDistance.cosinesimilScalarDouble N/A N/A N/A N/A thrpt 5 3357.433 ? 77.093 ops/ms o.o.b.j.i.v.bigdata.VectorDistance.cosinesimilScalarFloat N/A N/A N/A N/A thrpt 5 2812.819 ? 321.380 ops/ms o.o.b.j.i.v.bigdata.VectorDistance.cosinesimilVectorDouble128 N/A N/A N/A N/A thrpt 5 3834.837 ? 865.640 ops/ms o.o.b.j.i.v.bigdata.VectorDistance.cosinesimilVectorDouble256 N/A N/A N/A N/A thrpt 5 6894.900 ? 1743.191 ops/ms o.o.b.j.i.v.bigdata.VectorDistance.cosinesimilVectorDoubleMax N/A N/A N/A N/A thrpt 5 6906.721 ? 1718.390 ops/ms o.o.b.j.i.v.bigdata.VectorDistance.cosinesimilVectorFloat128 N/A N/A N/A N/A thrpt 5 7443.532 ? 1897.726 ops/ms o.o.b.j.i.v.bigdata.VectorDistance.cosinesimilVectorFloat256 N/A N/A N/A N/A thrpt 5 12136.630 ? 2997.062 ops/ms o.o.b.j.i.v.bigdata.VectorDistance.cosinesimilVectorFloatMax N/A N/A N/A N/A thrpt 5 12155.037 ? 2943.135 ops/ms o.o.b.j.i.v.bigdata.VectorDistance.l2SquaredScalar N/A N/A N/A N/A thrpt 5 3615.867 ? 188.036 ops/ms o.o.b.j.i.v.bigdata.VectorDistance.l2SquaredVectorDouble128 N/A N/A N/A N/A thrpt 5 4036.363 ? 1023.672 ops/ms o.o.b.j.i.v.bigdata.VectorDistance.l2SquaredVectorDouble256 N/A N/A N/A N/A thrpt 5 7766.613 ? 2090.510 ops/ms o.o.b.j.i.v.bigdata.VectorDistance.l2SquaredVectorDoubleMax N/A N/A N/A N/A thrpt 5 7758.038 ? 2196.819 ops/ms o.o.b.j.i.v.bigdata.VectorDistance.l2SquaredVectorFloat128 N/A N/A N/A N/A thrpt 5 8603.290 ? 2372.100 ops/ms o.o.b.j.i.v.bigdata.VectorDistance.l2SquaredVectorFloat256 N/A N/A N/A N/A thrpt 5 17002.021 ? 5948.044 ops/ms o.o.b.j.i.v.bigdata.VectorDistance.l2SquaredVectorFloatMax N/A N/A N/A N/A thrpt 5 17027.964 ? 5759.068 ops/ms o.o.b.j.i.v.crypto.ChaChaBench.encrypt128 N/A 16384 N/A N/A thrpt 8 21730.541 ? 5043.050 ops/s o.o.b.j.i.v.crypto.ChaChaBench.encrypt128 N/A 65536 N/A N/A thrpt 8 5496.309 ? 1245.802 ops/s o.o.b.j.i.v.crypto.ChaChaBench.encrypt256 N/A 16384 N/A N/A thrpt 8 40332.908 ? 12166.064 ops/s o.o.b.j.i.v.crypto.ChaChaBench.encrypt256 N/A 65536 N/A N/A thrpt 8 10304.809 ? 2968.075 ops/s o.o.b.j.i.v.crypto.ChaChaBench.encrypt512 N/A 16384 N/A N/A thrpt 8 285.604 ? 82.992 ops/s o.o.b.j.i.v.crypto.ChaChaBench.encrypt512 N/A 65536 N/A N/A thrpt 8 58.590 ? 16.202 ops/s o.o.b.j.i.v.crypto.Poly1305Bench.auth128 N/A 16384 N/A N/A thrpt 8 201.353 ? 67.948 ops/s o.o.b.j.i.v.crypto.Poly1305Bench.auth128 N/A 65536 N/A N/A thrpt 8 49.908 ? 15.856 ops/s o.o.b.j.i.v.crypto.Poly1305Bench.auth256 N/A 16384 N/A N/A thrpt 8 364.051 ? 108.472 ops/s o.o.b.j.i.v.crypto.Poly1305Bench.auth256 N/A 65536 N/A N/A thrpt 8 99.809 ? 33.255 ops/s o.o.b.j.i.v.crypto.Poly1305Bench.auth512 N/A 16384 N/A N/A thrpt 8 472.031 ? 149.266 ops/s o.o.b.j.i.v.crypto.Poly1305Bench.auth512 N/A 65536 N/A N/A thrpt 8 120.617 ? 35.399 ops/s o.o.b.j.i.v.operation.Byte128Vector.ABS N/A N/A N/A 1024 thrpt 5 16498.980 ? 3687.013 ops/ms o.o.b.j.i.v.operation.Byte128Vector.ABSMasked N/A N/A N/A 1024 thrpt 5 13420.584 ? 4553.559 ops/ms o.o.b.j.i.v.operation.Byte128Vector.ADD N/A N/A N/A 1024 thrpt 5 14389.853 ? 2559.982 ops/ms o.o.b.j.i.v.operation.Byte128Vector.ADDLanes N/A N/A N/A 1024 thrpt 5 5408.304 ? 1057.194 ops/ms o.o.b.j.i.v.operation.Byte128Vector.ADDMasked N/A N/A N/A 1024 thrpt 5 12571.391 ? 3170.842 ops/ms o.o.b.j.i.v.operation.Byte128Vector.ADDMaskedLanes N/A N/A N/A 1024 thrpt 5 4300.352 ? 911.484 ops/ms o.o.b.j.i.v.operation.Byte128Vector.AND N/A N/A N/A 1024 thrpt 5 14197.257 ? 2830.585 ops/ms o.o.b.j.i.v.operation.Byte128Vector.ANDLanes N/A N/A N/A 1024 thrpt 5 5437.373 ? 607.144 ops/ms o.o.b.j.i.v.operation.Byte128Vector.ANDMasked N/A N/A N/A 1024 thrpt 5 12535.445 ? 3085.079 ops/ms o.o.b.j.i.v.operation.Byte128Vector.ANDMaskedLanes N/A N/A N/A 1024 thrpt 5 4251.096 ? 1278.371 ops/ms o.o.b.j.i.v.operation.Byte128Vector.AND_NOT N/A N/A N/A 1024 thrpt 5 11770.249 ? 2634.626 ops/ms o.o.b.j.i.v.operation.Byte128Vector.AND_NOTMasked N/A N/A N/A 1024 thrpt 5 10638.213 ? 3156.234 ops/ms o.o.b.j.i.v.operation.Byte128Vector.ASHR N/A N/A N/A 1024 thrpt 5 2698.630 ? 866.569 ops/ms o.o.b.j.i.v.operation.Byte128Vector.ASHRMasked N/A N/A N/A 1024 thrpt 5 2438.774 ? 716.473 ops/ms o.o.b.j.i.v.operation.Byte128Vector.ASHRMaskedShift N/A N/A N/A 1024 thrpt 5 4884.817 ? 1014.613 ops/ms o.o.b.j.i.v.operation.Byte128Vector.ASHRShift N/A N/A N/A 1024 thrpt 5 6436.859 ? 990.331 ops/ms o.o.b.j.i.v.operation.Byte128Vector.BITWISE_BLEND N/A N/A N/A 1024 thrpt 5 11348.187 ? 3386.170 ops/ms o.o.b.j.i.v.operation.Byte128Vector.BITWISE_BLENDMasked N/A N/A N/A 1024 thrpt 5 9926.890 ? 4263.756 ops/ms o.o.b.j.i.v.operation.Byte128Vector.DIV N/A N/A N/A 1024 thrpt 5 169.706 ? 165.121 ops/ms o.o.b.j.i.v.operation.Byte128Vector.DIVMasked N/A N/A N/A 1024 thrpt 5 97.473 ? 77.981 ops/ms o.o.b.j.i.v.operation.Byte128Vector.EQ N/A N/A N/A 1024 thrpt 5 1486.251 ? 2582.369 ops/ms o.o.b.j.i.v.operation.Byte128Vector.FIRST_NONZERO N/A N/A N/A 1024 thrpt 5 491.076 ? 582.534 ops/ms o.o.b.j.i.v.operation.Byte128Vector.FIRST_NONZEROMasked N/A N/A N/A 1024 thrpt 5 396.484 ? 535.547 ops/ms o.o.b.j.i.v.operation.Byte128Vector.GE N/A N/A N/A 1024 thrpt 5 1455.821 ? 2516.670 ops/ms o.o.b.j.i.v.operation.Byte128Vector.GT N/A N/A N/A 1024 thrpt 5 1496.344 ? 2613.716 ops/ms o.o.b.j.i.v.operation.Byte128Vector.IS_DEFAULT N/A N/A N/A 1024 thrpt 5 1447.973 ? 2375.492 ops/ms o.o.b.j.i.v.operation.Byte128Vector.IS_NEGATIVE N/A N/A N/A 1024 thrpt 5 1429.487 ? 2438.604 ops/ms ... o.o.b.j.i.v.operation.ShortScalar.scatter256 N/A N/A N/A 1024 thrpt 5 1348.385 ? 140.870 ops/ms o.o.b.j.i.v.operation.ShortScalar.scatter512 N/A N/A N/A 1024 thrpt 5 1444.297 ? 101.135 ops/ms o.o.b.j.i.v.operation.ShortScalar.scatterBase0 N/A N/A N/A 1024 thrpt 5 1682.814 ? 62.974 ops/ms o.o.b.j.i.v.operation.ShortScalar.zero N/A N/A N/A 1024 thrpt 5 24059.679 ? 2452.079 ops/ms o.o.b.j.i.v.operation.SortVector.sortVectorI128 N/A N/A N/A 64 thrpt 5 124.008 ? 167.291 ops/ms o.o.b.j.i.v.operation.SortVector.sortVectorI128 N/A N/A N/A 1024 thrpt 5 8.291 ? 11.679 ops/ms o.o.b.j.i.v.operation.SortVector.sortVectorI128 N/A N/A N/A 65536 thrpt 5 0.132 ? 0.194 ops/ms o.o.b.j.i.v.operation.SortVector.sortVectorI256 N/A N/A N/A 64 thrpt 5 104.170 ? 149.013 ops/ms o.o.b.j.i.v.operation.SortVector.sortVectorI256 N/A N/A N/A 1024 thrpt 5 5.604 ? 9.367 ops/ms o.o.b.j.i.v.operation.SortVector.sortVectorI256 N/A N/A N/A 65536 thrpt 5 0.094 ? 0.132 ops/ms o.o.b.j.i.v.operation.SortVector.sortVectorI512 N/A N/A N/A 64 thrpt 5 12.467 ? 14.546 ops/ms o.o.b.j.i.v.operation.SortVector.sortVectorI512 N/A N/A N/A 1024 thrpt 5 0.781 ? 0.915 ops/ms o.o.b.j.i.v.operation.SortVector.sortVectorI512 N/A N/A N/A 65536 thrpt 5 0.012 ? 0.014 ops/ms o.o.b.j.i.v.operation.SortVector.sortVectorI64 N/A N/A N/A 64 thrpt 5 41.097 ? 48.712 ops/ms o.o.b.j.i.v.operation.SortVector.sortVectorI64 N/A N/A N/A 1024 thrpt 5 2.555 ? 3.112 ops/ms o.o.b.j.i.v.operation.SortVector.sortVectorI64 N/A N/A N/A 65536 thrpt 5 0.041 ? 0.048 ops/ms o.o.b.j.i.v.operation.SumOfUnsignedBytes.scalar N/A N/A N/A 64 thrpt 5 34764.547 ? 2124.872 ops/ms o.o.b.j.i.v.operation.SumOfUnsignedBytes.scalar N/A N/A N/A 1024 thrpt 5 2604.449 ? 63.086 ops/ms o.o.b.j.i.v.operation.SumOfUnsignedBytes.scalar N/A N/A N/A 4096 thrpt 5 653.640 ? 24.208 ops/ms o.o.b.j.i.v.operation.SumOfUnsignedBytes.vectorInt N/A N/A N/A 64 thrpt 5 68950.388 ? 27430.053 ops/ms o.o.b.j.i.v.operation.SumOfUnsignedBytes.vectorInt N/A N/A N/A 1024 thrpt 5 15432.548 ? 7166.145 ops/ms o.o.b.j.i.v.operation.SumOfUnsignedBytes.vectorInt N/A N/A N/A 4096 thrpt 5 4068.423 ? 1865.103 ops/ms o.o.b.j.i.v.operation.SumOfUnsignedBytes.vectorShort N/A N/A N/A 64 thrpt 5 52088.764 ? 56731.840 ops/ms o.o.b.j.i.v.operation.SumOfUnsignedBytes.vectorShort N/A N/A N/A 1024 thrpt 5 4369.735 ? 7629.283 ops/ms o.o.b.j.i.v.operation.SumOfUnsignedBytes.vectorShort N/A N/A N/A 4096 thrpt 5 2692.982 ? 3791.073 ops/ms o.o.b.j.i.v.utf8.DecodeBench.decodeScalar N/A 32768 1 N/A thrpt 8 54369.096 ? 1063.656 ops/s o.o.b.j.i.v.utf8.DecodeBench.decodeScalar N/A 8388608 1 N/A thrpt 8 151.256 ? 6.312 ops/s o.o.b.j.i.v.utf8.DecodeBench.decodeVector N/A 32768 1 N/A thrpt 8 6452.803 ? 2950.714 ops/s o.o.b.j.i.v.utf8.DecodeBench.decodeVector N/A 8388608 1 N/A thrpt 8 24.918 ? 12.696 ops/s o.o.b.j.i.v.utf8.DecodeBench.decodeVectorASCII N/A 32768 1 N/A thrpt 8 261340.791 ? 102913.900 ops/s o.o.b.j.i.v.utf8.DecodeBench.decodeVectorASCII N/A 8388608 1 N/A thrpt 8 293.033 ? 74.431 ops/s I am getting `java.lang.RuntimeException: Incorrect result` for DecodeBench.java test run: java.lang.RuntimeException: Incorrect result at org.openjdk.bench.jdk.incubator.vector.utf8.DecodeBench.tearDownInvocation(DecodeBench.java:204) at org.openjdk.bench.jdk.incubator.vector.utf8.jmh_generated.DecodeBench_decodeVectorASCII_jmhTest.decodeVectorASCII_thrpt_jmhStub(DecodeBench_decodeVectorASCII_jmhTest.java:127) at org.openjdk.bench.jdk.incubator.vector.utf8.jmh_generated.DecodeBench_decodeVectorASCII_jmhTest.decodeVectorASCII_Throughput(DecodeBench_decodeVectorASCII_jmhTest.java:85) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:568) at org.openjdk.jmh.runner.BenchmarkHandler$BenchmarkTask.call(BenchmarkHandler.java:453) at org.openjdk.jmh.runner.BenchmarkHandler$BenchmarkTask.call(BenchmarkHandler.java:437) at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1135) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) at java.base/java.lang.Thread.run(Thread.java:831) I'm looking into it, I'm not sure if this is a lack of hardware issue, test design, or bug. But it should not be failing https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/jdk/jdk/incubator/vector/benchmark/src/main/java/benchmark/utf8/DecodeBench.java#L201 @TearDown(Level.Invocation) public void tearDownInvocation() { out = new String(dst.array()); if (!in.equals(out)) { System.out.println("in = (" + in.length() + ") "" + arrayToString(in.getBytes()) + """); System.out.println("out = (" + out.length() + ") "" + arrayToString(out.getBytes()) + """); throw new RuntimeException("Incorrect result"); } } Previously I was only running Int64Vector perf test, which hid build issues with other tests. Any more feedback is appreciated. > Separate from moving the location, but related to mainline integration, I have concerns as to the number of benchmarks generated. It may be we have to curate a default smaller set, but enable the ability for someone to generate more for local testing. We could consider that later on. Do you have more thoughts here? Which tests should be included versus excluded? ------------- PR: https://git.openjdk.java.net/panama-vector/pull/77 From mgkwill at openjdk.java.net Tue Jun 8 16:21:27 2021 From: mgkwill at openjdk.java.net (Marcus G K Williams) Date: Tue, 8 Jun 2021 16:21:27 GMT Subject: [vectorIntrinsics] RFR: 8244490: [vector] Move Vector API micro benchmarks under test/micro [v4] In-Reply-To: References: Message-ID: <4KH_XYVB_Lxogdm6gQWGnWuvp-tShlbAW93nfuqxdcc=.9ec57fdc-4a38-4c10-8686-e03b16f3eefa@github.com> > Vector API micro benchmarks are currently located under test/jdk/jdk/incubator/vector/benchmark which makes them rather as "dead" code without possibility to built and run. > > The proper location for micro benchmarks is actually test/micro/ directory. > It would be nice to move Vector API benchmarks there so they can be built automatically as part 'test-image' make target. > Once they are built they can be run as > make run-test TEST=micro:BENCHMARK_TEST_NAME Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision: Fix newline at EOF config.sh Signed-off-by: Marcus G K Williams ------------- Changes: - all: https://git.openjdk.java.net/panama-vector/pull/77/files - new: https://git.openjdk.java.net/panama-vector/pull/77/files/4c31d216..aa7733b6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=77&range=03 - incr: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=77&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/panama-vector/pull/77.diff Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/77/head:pull/77 PR: https://git.openjdk.java.net/panama-vector/pull/77 From mgkwill at openjdk.java.net Tue Jun 8 16:32:25 2021 From: mgkwill at openjdk.java.net (Marcus G K Williams) Date: Tue, 8 Jun 2021 16:32:25 GMT Subject: [vectorIntrinsics] RFR: 8244490: [vector] Move Vector API micro benchmarks under test/micro [v5] In-Reply-To: References: Message-ID: <0Ei6kGZe2NcaaRvnVYYUfgqBo_wDV4B_xwFeWV0z5Ng=.1c02ee00-0d15-427f-885b-4979e82a3f86@github.com> > Vector API micro benchmarks are currently located under test/jdk/jdk/incubator/vector/benchmark which makes them rather as "dead" code without possibility to built and run. > > The proper location for micro benchmarks is actually test/micro/ directory. > It would be nice to move Vector API benchmarks there so they can be built automatically as part 'test-image' make target. > Once they are built they can be run as > make run-test TEST=micro:BENCHMARK_TEST_NAME Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision: Standardize copyright header, add 2021 Signed-off-by: Marcus G K Williams ------------- Changes: - all: https://git.openjdk.java.net/panama-vector/pull/77/files - new: https://git.openjdk.java.net/panama-vector/pull/77/files/aa7733b6..682982d0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=77&range=04 - incr: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=77&range=03-04 Stats: 15 lines in 15 files changed: 0 ins; 0 del; 15 mod Patch: https://git.openjdk.java.net/panama-vector/pull/77.diff Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/77/head:pull/77 PR: https://git.openjdk.java.net/panama-vector/pull/77 From leerho at gmail.com Tue Jun 8 16:54:50 2021 From: leerho at gmail.com (leerho) Date: Tue, 8 Jun 2021 09:54:50 -0700 Subject: Part 1 Proposal for JDK-8264594 In-Reply-To: <0bd0724a-ce06-bb25-10a9-9f0641b359c1@oracle.com> References: <0b5ac260-4e87-4a92-53ca-b670a451f552@oracle.com> <50605287-4e54-7dde-14e5-d521c19301be@oracle.com> <95c04a58-4897-0d49-3f13-d8aa6b293006@oracle.com> <87a484de-9cdc-ddc7-ff73-6dad2641d5a4@oracle.com> <0bd0724a-ce06-bb25-10a9-9f0641b359c1@oracle.com> Message-ID: > > Question: do you have concrete use cases where you'd like to copy contents > of a double[] at non-aligned positions inside a segment? Absolutely! In fact, specifying the offset in bytes is probably the most common. This is because many of our structs start with a preamble of a mix of byte, short, int, and float fields, and then followed by several data array regions. For example an array of ints followed by an array of longs, which in some cases may not be unit aligned with the base of the segment. This can be particularly true of structs that are defined by other users where alignment cannot be guaranteed. In fact, one of our customers has years of historical data (petabytes) that are not at all byte aligned. So to assume that everything is neatly byte aligned would be a big mistake. Unfortunately, many engineers that have created files of data over the years did so without any awareness of the need for byte-alignment. Lee. On Tue, Jun 8, 2021 at 7:00 AM Maurizio Cimadamore < maurizio.cimadamore at oracle.com> wrote: > Hi Lee, > thanks for this, I'll try to put together a PR in the next week or so. > > Re. overloads I was thinking about how the ByteBuffer API goes about them, > and, in I see that that API doesn't have the same issues, given that > ByteBuffer only provides bulk copy for byte arrays. If you want to bulk > copy a double[] you have to convert to a DoubleBuffer first and then copy > (and then use logical indices for the buffer too). > > Question: do you have concrete use cases where you'd like to copy contents > of a double[] at non-aligned positions inside a segment? > > I'm asking because, in principle we could leave the methods in CopyMemory > cover the aligned, logical indices only part of the API. And ask the user > to fall back to MemorySegment::copyFrom if they really really want > unaligned (which should be uncommon?). > > Cheers > Maurizio > On 08/06/2021 00:55, leerho wrote: > > Maurizio, > I have updated MemoryCopy and TestMemoryCopy by extending the variable > names to be even more clear, for example: > > - srcArr -> srcArray > - srcSeg -> srcSegment > - srcCopyLen -> srcCopyLengthInts > - srcIndex -> srcIndexLongs > - Etc. > > I also added a comment in the class javadoc describing the difference > between variables with the word "index" and ones with the word "offset", > etc. > > I have looked at what it would take to add overloads that refer to the > segment offset in array element units. It can be done, but the names of > these new methods will be kinda ugly or awkward: > > - copyFromArrayAtIndex -- confusing since the array uses index units > already > - copyAtIndexFromArray -- not much better > - copyFromArrayWithIndex -- nah > - copyFromArrayToSegementUsingIndex -- a little more clear, but really > awkward > > If you have any better ideas, I am open. (But IMHO, I don't think we need > this :) ) > > Please let me know what the next step should be :) > > Thanks! > > Lee. > > On Fri, Jun 4, 2021 at 7:09 AM leerho wrote: > >> Maurizio, >> Thank you for your reply. I agree with your observation in the >> difference between the single item case and the bulk copy. I guess I >> became so familiar with how offsets are handled in Unsafe where the single >> element and bulk copy cases the references to memory are always in bytes, >> it seamed so simple and natural. >> >> In my experience anyway, reading and writing data to off-heap almost >> always involves a mix of preamble elements and bulk copy arrays where it >> was necessary to track the offset in bytes, where the multibyte elements >> may not be correctly aligned to the base of the allocated segment, or God >> forbid, the arrays. >> >> What is most important is getting this into the JDK, and if I have to add >> more overloads, I will :) >> >> Lee. >> >> On Fri, Jun 4, 2021 at 2:34 AM Maurizio Cimadamore < >> maurizio.cimadamore at oracle.com> wrote: >> >>> >>> On 04/06/2021 01:32, leerho wrote: >>> >>> When I first saw all the logical index overloads in MemoryAccess I >>> shuddered. It is a lot of API clutter as far as I?m concerned. But just >>> because we made that mistake with MemoryAccess doesn?t mean we have to >>> continue propagating it. >>> >>> I'm sorry, I just don't see that as being a "mistake". Code like this: >>> >>> ``` >>> for (int i = 0 ; i < limit ; i++) { >>> long val = MemoryAccess.getLongAtIndex(segment, i); >>> ... >>> } >>> ``` >>> >>> Is _extremely_ common. While it's true that memory segment is an >>> unbiased array of bytes, there are times you want to access it in a more >>> structured form - and saying "you can't do that" because it adds overloads >>> doesn't seem like a great solution to me. >>> >>> >>> Also I have explicitly named the two offsets very differently to try to >>> make it clear that they are very different. I guess I could go further and >>> name the ?srcIndex? -> ?srcIndexLongs? for the long array case, for >>> example. But since ?index? is used elsewhere as the logical index I >>> assumed that this would not be necessary. >>> >>> But I would much rather use longer, more explicit names than propagate >>> API clutter. >>> >>> I was thinking overnight that, perhaps, the memory copy and the single >>> element cases are different. When you do single access (see above) you do >>> that frequently in a loop - and you often get elements of the same type. As >>> stated above, asking developers to work in terms of offsets seems a bit >>> odd, when they are really accessing a flat array of element type T. >>> >>> In the case of bulk copy, I don't think there's the same degree of >>> pressure - you will probably call the bulk copy at the beginning, or at the >>> end of your computation (or both ends!) - and having an offset shift is >>> more tolerable. >>> >>> So, I'm open to evaluating something more minimal, and see how far we >>> can get with it. >>> >>> Maurizio >>> >>> >>> Lee >>> >>> On Thu, Jun 3, 2021 at 1:26 PM Maurizio Cimadamore < >>> maurizio.cimadamore at oracle.com> wrote: >>> >>>> Thanks. >>>> >>>> While I agree that a segment is just a bunch of bytes, I think also >>>> think that having an API which takes two indices at the same time, one >>>> logical and one physical is kind of evil. I bet that a lot of developers >>>> will get that wrong, at least the first time. >>>> >>>> What you say about segments being an array of bytes, and thus not >>>> needing index-based overloads can also be said for MemoryAccess class - but >>>> I believe that the index-based accessors in the are quite popular. >>>> >>>> But overall, my worry is not performances, or symmetry with respect to >>>> other APIs - my main worry is what I said above: that people will just >>>> assume that indices are logical for both the segment and the array - so >>>> overloads with clearly different names should help quite a bit IMHO. >>>> >>>> >>>> Maurizio >>>> On 03/06/2021 20:50, leerho wrote: >>>> >>>> Maurizio, >>>> Here is the MemoryCopy class (w/o byte swap) and the TestMemoryCopy >>>> class (w/o testing byte swap). >>>> >>>> I copied from the TestMemoryAccess class in that I noticed that there >>>> is no package statement. I am not sure what @SuppressWarnings are allowed >>>> in your test environment, I suspect I should remove all of them. >>>> >>>> When the MemorySegment copyFrom(MemorySegment, MemoryLayout, ByteOrder) >>>> becomes available I can add the tests for that. >>>> >>>> *IMHO* >>>> >>>> I feel strongly that there is no need to additionally overload these >>>> methods with the segment offset specified in array index units. It is so >>>> trivial to convert from one to the other and it can be done easily in the >>>> method argument with a simple multiply by 2, 4 or 8. This should compile >>>> down to a simple shift, which becomes a single cycle CPU instruction. So >>>> this is not a performance issue. >>>> >>>> Furthermore, it is best that the user becomes accustomed to thinking of >>>> a segment fundamentally as an array of bytes. Once a segment is loaded >>>> with some primitive array, the segment loses the context of the type of the >>>> array it was loaded with; in effect, a kind of "type erasure" similar to >>>> Java's generics. This is one of the reasons that MemorySegments can be so >>>> powerful. >>>> >>>> >>>> I have been programming with the "MemorySegment" concept for a number >>>> of years now and find that keeping in mind that segments are just bytes is >>>> very useful. >>>> >>>> >>>> Let me know what you think. >>>> >>>> Lee. >>>> >>>> >>>> >>>> On Mon, May 31, 2021 at 6:56 AM Maurizio Cimadamore < >>>> maurizio.cimadamore at oracle.com> wrote: >>>> >>>>> Hi Lee, >>>>> this looks good. >>>>> >>>>> One thing I note is that there's an ambiguity as to whether the >>>>> segment index is expressed as a logical index, or a raw byte offset. Your >>>>> snippet does the latter. If we want to follow MemoryAccess, perhaps that >>>>> calls for 2 overloads (copyFromArrayAtIndex/copyFromArrayAtOffset), as I >>>>> imagine both could be useful, depending on the case? >>>>> >>>>> The javadoc will have to say something when the segment being used is >>>>> backed by the very array that is the source/target of the copy (we have >>>>> some text like that in MemorySegment::copyFrom). >>>>> >>>>> I think it would be helpful to progress further with this, add the >>>>> remaining templates (w/o ByteOrder, for now) test and see how it works in >>>>> practice. >>>>> >>>>> I will add (or just file a simple PR, so that you can just borrow from >>>>> it - should be a single method) something to do the segment copy with swap. >>>>> >>>>> Thanks! >>>>> Maurizio >>>>> On 28/05/2021 22:37, leerho wrote: >>>>> >>>>> Maurizio, >>>>> >>>>> Again sorry about the delay. >>>>> >>>>> Attached is a template proposal for the MemoryCopy class. >>>>> >>>>> I can't complete this without your proposed new copyFrom(...) method >>>>> in MemorySegment. As it is written, it should work, but without the byte >>>>> swap capability. >>>>> >>>>> I can complete the rest of the primitives like this template, if you >>>>> would like with javadocs. I could also start writing tests, but without >>>>> the byte-swap. >>>>> >>>>> Let me know what would be most helpful. >>>>> >>>>> Cheers, >>>>> >>>>> Lee >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Thu, May 20, 2021 at 11:36 AM leerho wrote: >>>>> >>>>>> Of course! >>>>>> >>>>>> On Thu, May 20, 2021 at 9:42 AM Maurizio Cimadamore < >>>>>> maurizio.cimadamore at oracle.com> wrote: >>>>>> >>>>>>> >>>>>>> On 20/05/2021 17:13, leerho wrote: >>>>>>> >>>>>>> I am not sure if the *dstSegSlice* requires the *srcCopyLen*. I >>>>>>> would hope that it is smart enough to realize that the input length is >>>>>>> smaller than the given offset minus the segment size. >>>>>>> >>>>>>> asSlice has an overload that just takes an offset and infers the >>>>>>> resulting size from there. >>>>>>> >>>>>>> But that doesn't seem what you want here - as you want the slice to >>>>>>> have a specific size (the size of the input array). >>>>>>> >>>>>>> MemorySegment::copyFrom wants the two segments to have the same >>>>>>> size, so I think you need that. >>>>>>> >>>>>>> In terms of performance, there's no difference between >>>>>>> asSlice(offset) and asSlice(offset, size) - you have to create a new >>>>>>> segment anyway. >>>>>>> >>>>>>> Maurizio >>>>>>> >>>>>>> >>>>>>> -- >>> From my cell phone. >>> >>> -- >> From my cell phone. >> > From leerho at gmail.com Tue Jun 8 17:14:51 2021 From: leerho at gmail.com (leerho) Date: Tue, 8 Jun 2021 10:14:51 -0700 Subject: Part 1 Proposal for JDK-8264594 In-Reply-To: References: <0b5ac260-4e87-4a92-53ca-b670a451f552@oracle.com> <50605287-4e54-7dde-14e5-d521c19301be@oracle.com> <95c04a58-4897-0d49-3f13-d8aa6b293006@oracle.com> <87a484de-9cdc-ddc7-ff73-6dad2641d5a4@oracle.com> <0bd0724a-ce06-bb25-10a9-9f0641b359c1@oracle.com> Message-ID: Maurizio, Also, as soon as you have an implementation of *MemorySegment::copyFrom(MemorySegment, MemoryLayout, ByteOrder) *in *https://github.com/openjdk/panama-foreign *I can complete the ByteOrder aware part of MemoryCopy as well as the tests to go along with it. Thanks, Lee. On Tue, Jun 8, 2021 at 9:54 AM leerho wrote: > Question: do you have concrete use cases where you'd like to copy contents >> of a double[] at non-aligned positions inside a segment? > > > Absolutely! In fact, specifying the offset in bytes is probably the most > common. This is because many of our structs start with a preamble of a mix > of byte, short, int, and float fields, and then followed by several data > array regions. For example an array of ints followed by an array of longs, > which in some cases may not be unit aligned with the base of the segment. > This can be particularly true of structs that are defined by other users > where alignment cannot be guaranteed. In fact, one of our customers has > years of historical data (petabytes) that are not at all byte aligned. So > to assume that everything is neatly byte aligned would be a big mistake. > Unfortunately, many engineers that have created files of data over the > years did so without any awareness of the need for byte-alignment. > > Lee. > > > On Tue, Jun 8, 2021 at 7:00 AM Maurizio Cimadamore < > maurizio.cimadamore at oracle.com> wrote: > >> Hi Lee, >> thanks for this, I'll try to put together a PR in the next week or so. >> >> Re. overloads I was thinking about how the ByteBuffer API goes about >> them, and, in I see that that API doesn't have the same issues, given that >> ByteBuffer only provides bulk copy for byte arrays. If you want to bulk >> copy a double[] you have to convert to a DoubleBuffer first and then copy >> (and then use logical indices for the buffer too). >> >> Question: do you have concrete use cases where you'd like to copy >> contents of a double[] at non-aligned positions inside a segment? >> >> I'm asking because, in principle we could leave the methods in CopyMemory >> cover the aligned, logical indices only part of the API. And ask the user >> to fall back to MemorySegment::copyFrom if they really really want >> unaligned (which should be uncommon?). >> >> Cheers >> Maurizio >> On 08/06/2021 00:55, leerho wrote: >> >> Maurizio, >> I have updated MemoryCopy and TestMemoryCopy by extending the variable >> names to be even more clear, for example: >> >> - srcArr -> srcArray >> - srcSeg -> srcSegment >> - srcCopyLen -> srcCopyLengthInts >> - srcIndex -> srcIndexLongs >> - Etc. >> >> I also added a comment in the class javadoc describing the difference >> between variables with the word "index" and ones with the word "offset", >> etc. >> >> I have looked at what it would take to add overloads that refer to the >> segment offset in array element units. It can be done, but the names of >> these new methods will be kinda ugly or awkward: >> >> - copyFromArrayAtIndex -- confusing since the array uses index units >> already >> - copyAtIndexFromArray -- not much better >> - copyFromArrayWithIndex -- nah >> - copyFromArrayToSegementUsingIndex -- a little more clear, but >> really awkward >> >> If you have any better ideas, I am open. (But IMHO, I don't think we >> need this :) ) >> >> Please let me know what the next step should be :) >> >> Thanks! >> >> Lee. >> >> On Fri, Jun 4, 2021 at 7:09 AM leerho wrote: >> >>> Maurizio, >>> Thank you for your reply. I agree with your observation in the >>> difference between the single item case and the bulk copy. I guess I >>> became so familiar with how offsets are handled in Unsafe where the single >>> element and bulk copy cases the references to memory are always in bytes, >>> it seamed so simple and natural. >>> >>> In my experience anyway, reading and writing data to off-heap almost >>> always involves a mix of preamble elements and bulk copy arrays where it >>> was necessary to track the offset in bytes, where the multibyte elements >>> may not be correctly aligned to the base of the allocated segment, or God >>> forbid, the arrays. >>> >>> What is most important is getting this into the JDK, and if I have to >>> add more overloads, I will :) >>> >>> Lee. >>> >>> On Fri, Jun 4, 2021 at 2:34 AM Maurizio Cimadamore < >>> maurizio.cimadamore at oracle.com> wrote: >>> >>>> >>>> On 04/06/2021 01:32, leerho wrote: >>>> >>>> When I first saw all the logical index overloads in MemoryAccess I >>>> shuddered. It is a lot of API clutter as far as I?m concerned. But just >>>> because we made that mistake with MemoryAccess doesn?t mean we have to >>>> continue propagating it. >>>> >>>> I'm sorry, I just don't see that as being a "mistake". Code like this: >>>> >>>> ``` >>>> for (int i = 0 ; i < limit ; i++) { >>>> long val = MemoryAccess.getLongAtIndex(segment, i); >>>> ... >>>> } >>>> ``` >>>> >>>> Is _extremely_ common. While it's true that memory segment is an >>>> unbiased array of bytes, there are times you want to access it in a more >>>> structured form - and saying "you can't do that" because it adds overloads >>>> doesn't seem like a great solution to me. >>>> >>>> >>>> Also I have explicitly named the two offsets very differently to try to >>>> make it clear that they are very different. I guess I could go further and >>>> name the ?srcIndex? -> ?srcIndexLongs? for the long array case, for >>>> example. But since ?index? is used elsewhere as the logical index I >>>> assumed that this would not be necessary. >>>> >>>> But I would much rather use longer, more explicit names than propagate >>>> API clutter. >>>> >>>> I was thinking overnight that, perhaps, the memory copy and the single >>>> element cases are different. When you do single access (see above) you do >>>> that frequently in a loop - and you often get elements of the same type. As >>>> stated above, asking developers to work in terms of offsets seems a bit >>>> odd, when they are really accessing a flat array of element type T. >>>> >>>> In the case of bulk copy, I don't think there's the same degree of >>>> pressure - you will probably call the bulk copy at the beginning, or at the >>>> end of your computation (or both ends!) - and having an offset shift is >>>> more tolerable. >>>> >>>> So, I'm open to evaluating something more minimal, and see how far we >>>> can get with it. >>>> >>>> Maurizio >>>> >>>> >>>> Lee >>>> >>>> On Thu, Jun 3, 2021 at 1:26 PM Maurizio Cimadamore < >>>> maurizio.cimadamore at oracle.com> wrote: >>>> >>>>> Thanks. >>>>> >>>>> While I agree that a segment is just a bunch of bytes, I think also >>>>> think that having an API which takes two indices at the same time, one >>>>> logical and one physical is kind of evil. I bet that a lot of developers >>>>> will get that wrong, at least the first time. >>>>> >>>>> What you say about segments being an array of bytes, and thus not >>>>> needing index-based overloads can also be said for MemoryAccess class - but >>>>> I believe that the index-based accessors in the are quite popular. >>>>> >>>>> But overall, my worry is not performances, or symmetry with respect to >>>>> other APIs - my main worry is what I said above: that people will just >>>>> assume that indices are logical for both the segment and the array - so >>>>> overloads with clearly different names should help quite a bit IMHO. >>>>> >>>>> >>>>> Maurizio >>>>> On 03/06/2021 20:50, leerho wrote: >>>>> >>>>> Maurizio, >>>>> Here is the MemoryCopy class (w/o byte swap) and the TestMemoryCopy >>>>> class (w/o testing byte swap). >>>>> >>>>> I copied from the TestMemoryAccess class in that I noticed that there >>>>> is no package statement. I am not sure what @SuppressWarnings are allowed >>>>> in your test environment, I suspect I should remove all of them. >>>>> >>>>> When the MemorySegment copyFrom(MemorySegment, MemoryLayout, >>>>> ByteOrder) becomes available I can add the tests for that. >>>>> >>>>> *IMHO* >>>>> >>>>> I feel strongly that there is no need to additionally overload these >>>>> methods with the segment offset specified in array index units. It is so >>>>> trivial to convert from one to the other and it can be done easily in the >>>>> method argument with a simple multiply by 2, 4 or 8. This should compile >>>>> down to a simple shift, which becomes a single cycle CPU instruction. So >>>>> this is not a performance issue. >>>>> >>>>> Furthermore, it is best that the user becomes accustomed to thinking >>>>> of a segment fundamentally as an array of bytes. Once a segment is loaded >>>>> with some primitive array, the segment loses the context of the type of the >>>>> array it was loaded with; in effect, a kind of "type erasure" similar to >>>>> Java's generics. This is one of the reasons that MemorySegments can be so >>>>> powerful. >>>>> >>>>> >>>>> I have been programming with the "MemorySegment" concept for a number >>>>> of years now and find that keeping in mind that segments are just bytes is >>>>> very useful. >>>>> >>>>> >>>>> Let me know what you think. >>>>> >>>>> Lee. >>>>> >>>>> >>>>> >>>>> On Mon, May 31, 2021 at 6:56 AM Maurizio Cimadamore < >>>>> maurizio.cimadamore at oracle.com> wrote: >>>>> >>>>>> Hi Lee, >>>>>> this looks good. >>>>>> >>>>>> One thing I note is that there's an ambiguity as to whether the >>>>>> segment index is expressed as a logical index, or a raw byte offset. Your >>>>>> snippet does the latter. If we want to follow MemoryAccess, perhaps that >>>>>> calls for 2 overloads (copyFromArrayAtIndex/copyFromArrayAtOffset), as I >>>>>> imagine both could be useful, depending on the case? >>>>>> >>>>>> The javadoc will have to say something when the segment being used is >>>>>> backed by the very array that is the source/target of the copy (we have >>>>>> some text like that in MemorySegment::copyFrom). >>>>>> >>>>>> I think it would be helpful to progress further with this, add the >>>>>> remaining templates (w/o ByteOrder, for now) test and see how it works in >>>>>> practice. >>>>>> >>>>>> I will add (or just file a simple PR, so that you can just borrow >>>>>> from it - should be a single method) something to do the segment copy with >>>>>> swap. >>>>>> >>>>>> Thanks! >>>>>> Maurizio >>>>>> On 28/05/2021 22:37, leerho wrote: >>>>>> >>>>>> Maurizio, >>>>>> >>>>>> Again sorry about the delay. >>>>>> >>>>>> Attached is a template proposal for the MemoryCopy class. >>>>>> >>>>>> I can't complete this without your proposed new copyFrom(...) method >>>>>> in MemorySegment. As it is written, it should work, but without the byte >>>>>> swap capability. >>>>>> >>>>>> I can complete the rest of the primitives like this template, if you >>>>>> would like with javadocs. I could also start writing tests, but without >>>>>> the byte-swap. >>>>>> >>>>>> Let me know what would be most helpful. >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Lee >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Thu, May 20, 2021 at 11:36 AM leerho wrote: >>>>>> >>>>>>> Of course! >>>>>>> >>>>>>> On Thu, May 20, 2021 at 9:42 AM Maurizio Cimadamore < >>>>>>> maurizio.cimadamore at oracle.com> wrote: >>>>>>> >>>>>>>> >>>>>>>> On 20/05/2021 17:13, leerho wrote: >>>>>>>> >>>>>>>> I am not sure if the *dstSegSlice* requires the *srcCopyLen*. I >>>>>>>> would hope that it is smart enough to realize that the input length is >>>>>>>> smaller than the given offset minus the segment size. >>>>>>>> >>>>>>>> asSlice has an overload that just takes an offset and infers the >>>>>>>> resulting size from there. >>>>>>>> >>>>>>>> But that doesn't seem what you want here - as you want the slice to >>>>>>>> have a specific size (the size of the input array). >>>>>>>> >>>>>>>> MemorySegment::copyFrom wants the two segments to have the same >>>>>>>> size, so I think you need that. >>>>>>>> >>>>>>>> In terms of performance, there's no difference between >>>>>>>> asSlice(offset) and asSlice(offset, size) - you have to create a new >>>>>>>> segment anyway. >>>>>>>> >>>>>>>> Maurizio >>>>>>>> >>>>>>>> >>>>>>>> -- >>>> From my cell phone. >>>> >>>> -- >>> From my cell phone. >>> >> From xgong at openjdk.java.net Wed Jun 9 03:34:30 2021 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Wed, 9 Jun 2021 03:34:30 GMT Subject: [vectorIntrinsics+mask] RFR: 8268154: Add masking support for vector load intrinsics In-Reply-To: References: Message-ID: On Mon, 7 Jun 2021 09:05:44 GMT, Xiaohong Gong wrote: > This patch adds the predicate support for masked load vector operation, including the Vector API java implementation and hotspot intrinsics changes. The main changes contain: > - Adding a new hotspot intrinsic method (`loadMasked`), which can transform the vector mask class and value to hotspot. It is called by the masked `"fromArray"` API in JAVA level. The compiler will generate the masked vector load node if the current platform supports the predicate feature and backend has implemented it. Otherwise, the vector blend pattern will be generated like before. > - Adding the similar masked support for load/store boolean/char array. > > Note that the intrinsification when there is the array range bailout is not implemented in this patch. We are considering making it vectorized with predicate feature for SVE/AVX-512 as well, and will create a separate patch for it in future. > > Also note that this patch doesn't contain any backend changes. Hi @PaulSandoz , @sviswa7 , could you please take a look at the java side of this PR? Thanks so much! Hi @iwanowww , could you please take a look at the compiler side of this PR? Thanks so much! Regarding to your feedback! Best Regards, Xiaohong ------------- PR: https://git.openjdk.java.net/panama-vector/pull/90 From xgong at openjdk.java.net Wed Jun 9 03:57:52 2021 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Wed, 9 Jun 2021 03:57:52 GMT Subject: [vectorIntrinsics+mask] RFR: 8267368: Add masking support for reduction vector intrinsics [v2] In-Reply-To: References: Message-ID: > This patch adds the masking support for vector reduction operations, including the Vector API java implementation and hotspot intrinsics changes. It adds the mask information to the reduction intrinsic method. With it: > - Both masked and non-masked reduction operations call the same hotspot intrinsics. The mask value and class are set to `"null"` for non-masked operations. > - Reduction IR with mask as another input will be generated if the platform supports the predicate feature for the op. Otherwise, the vector blend pattern will be generated like before. > > Note that this patch only contains the Vector API java implementation and the hotspot intrinsics changes. No compiler mid-end and backend implementations are included. Xiaohong Gong has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: - Merge panama-vector:vectorIntrinsics+mask into JDK-8267368 - 8267368: Add masking support for reduction vector intrinsics ------------- Changes: https://git.openjdk.java.net/panama-vector/pull/86/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=86&range=01 Stats: 681 lines in 42 files changed: 365 ins; 94 del; 222 mod Patch: https://git.openjdk.java.net/panama-vector/pull/86.diff Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/86/head:pull/86 PR: https://git.openjdk.java.net/panama-vector/pull/86 From xgong at openjdk.java.net Wed Jun 9 03:57:53 2021 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Wed, 9 Jun 2021 03:57:53 GMT Subject: [vectorIntrinsics+mask] RFR: 8267368: Add masking support for reduction vector intrinsics In-Reply-To: References: Message-ID: On Mon, 24 May 2021 06:15:56 GMT, Xiaohong Gong wrote: > This patch adds the masking support for vector reduction operations, including the Vector API java implementation and hotspot intrinsics changes. It adds the mask information to the reduction intrinsic method. With it: > - Both masked and non-masked reduction operations call the same hotspot intrinsics. The mask value and class are set to `"null"` for non-masked operations. > - Reduction IR with mask as another input will be generated if the platform supports the predicate feature for the op. Otherwise, the vector blend pattern will be generated like before. > > Note that this patch only contains the Vector API java implementation and the hotspot intrinsics changes. No compiler mid-end and backend implementations are included. Hi @iwanowww , any feedback to the compiler changes? Thanks so much! ------------- PR: https://git.openjdk.java.net/panama-vector/pull/86 From maurizio.cimadamore at oracle.com Wed Jun 9 11:53:12 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 9 Jun 2021 12:53:12 +0100 Subject: Part 1 Proposal for JDK-8264594 In-Reply-To: References: <50605287-4e54-7dde-14e5-d521c19301be@oracle.com> <95c04a58-4897-0d49-3f13-d8aa6b293006@oracle.com> <87a484de-9cdc-ddc7-ff73-6dad2641d5a4@oracle.com> <0bd0724a-ce06-bb25-10a9-9f0641b359c1@oracle.com> Message-ID: <06429259-99bf-4043-d611-24aa6fb353bd@oracle.com> Thanks for the background. I think my question was ill-posed, as I realize that even in the cases you describe, you could always avoid the need for a bulk copy with raw byte offset by doing slicing and copy. e.g. copyIntoArrayRaw(segment, byteOffset, long[], arrayIndex) can be rewritten as: copyIntoArrayLogical(segment.asSlice(byteOffset), 0, long[], arrayIndex) So, if we find that having a physical (segment offset) vs. logical (array offset) mismatch is too confusing, we *could* fall back to slicing and using logical offsets only. Maurizio On 08/06/2021 17:54, leerho wrote: > > Question: do you have concrete use cases where you'd like to copy > contents of a double[] at non-aligned positions inside a segment? > > > Absolutely!? ?In fact, specifying the?offset in bytes is probably the > most common.? This is because many of our structs start with a > preamble of a mix of byte, short, int, and float fields, and then > followed by several data array regions.? For example an array of ints > followed by an array of longs, which in some cases may not be unit > aligned with the base of the segment.? This can be particularly true > of structs that are defined by other users where alignment cannot be > guaranteed. ?In fact, one of our customers has years of historical > data (petabytes) that are not at all byte aligned.? So to assume that > everything is neatly byte aligned would be a big mistake.? > Unfortunately, many engineers that have created files of data over the > years did so without any awareness of the need for byte-alignment. > > Lee. > > On Tue, Jun 8, 2021 at 7:00 AM Maurizio Cimadamore > > wrote: > > Hi Lee, > thanks for this, I'll try to put together a PR in the next week or so. > > Re. overloads I was thinking about how the ByteBuffer API goes > about them, and, in I see that that API doesn't have the same > issues, given that ByteBuffer only provides bulk copy for byte > arrays. If you want to bulk copy a double[] you have to convert to > a DoubleBuffer first and then copy (and then use logical indices > for the buffer too). > > Question: do you have concrete use cases where you'd like to copy > contents of a double[] at non-aligned positions inside a segment? > > I'm asking because, in principle we could leave the methods in > CopyMemory cover the aligned, logical indices only part of the > API. And ask the user to fall back to MemorySegment::copyFrom if > they really really want unaligned (which should be uncommon?). > > Cheers > Maurizio > > On 08/06/2021 00:55, leerho wrote: >> Maurizio, >> I have updated MemoryCopy and TestMemoryCopy by extending the >> variable names to be even more clear, for example: >> >> * srcArr -> srcArray >> * srcSeg -> srcSegment >> * srcCopyLen -> srcCopyLengthInts >> * srcIndex -> srcIndexLongs >> * Etc. >> >> I also added a comment in the class javadoc describing the >> difference between variables with the word "index" and ones with >> the word "offset", etc. >> >> I have looked at what it would take to add overloads that refer >> to the segment offset in array element units.? It can be done, >> but the names of these new methods will be kinda ugly or awkward: >> >> * copyFromArrayAtIndex -- confusing since the array uses index >> units already >> * copyAtIndexFromArray -- not much better >> * copyFromArrayWithIndex -- nah >> * copyFromArrayToSegementUsingIndex -- a little more clear, but >> really awkward >> >> If you have any better ideas, I am open.? (But IMHO, I don't >> think we need this :) ) >> >> Please let me know what the next step should be :) >> >> Thanks! >> >> Lee. >> >> On Fri, Jun 4, 2021 at 7:09 AM leerho > > wrote: >> >> Maurizio, >> Thank you for your reply.? I agree with your observation in >> the difference between the single item case and the bulk >> copy.? I guess I became so familiar with how offsets are >> handled in Unsafe where the single element and bulk copy >> cases the references to memory are always in bytes, it seamed >> so simple and natural. >> >> In my experience anyway, reading and writing data to off-heap >> almost always involves a mix of preamble elements and bulk >> copy arrays where it was necessary to track the offset in >> bytes, where the multibyte elements may not be correctly >> aligned to the base of the allocated segment, or God forbid, >> the arrays. >> >> What is most important is getting this into the JDK, and if I >> have to add more overloads, I will :) >> >> Lee. >> >> On Fri, Jun 4, 2021 at 2:34 AM Maurizio Cimadamore >> > > wrote: >> >> >> On 04/06/2021 01:32, leerho wrote: >>> When I first saw all the logical index overloads in >>> MemoryAccess I shuddered.? It is a lot of API clutter as >>> far as I?m concerned.? But just because we made that >>> mistake with MemoryAccess doesn?t mean we have to >>> continue propagating it. >> >> I'm sorry, I just don't see that as being a "mistake". >> Code like this: >> >> ``` >> for (int i = 0 ; i < limit ; i++) { >> ?? long val = MemoryAccess.getLongAtIndex(segment, i); >> ?? ... >> } >> ``` >> >> Is _extremely_ common. While it's true that memory >> segment is an unbiased array of bytes, there are times >> you want to access it in a more structured form - and >> saying "you can't do that" because it adds overloads >> doesn't seem like a great solution to me. >> >>> >>> Also I have explicitly named the two offsets very >>> differently to try to make it clear that they are very >>> different.? I guess I could go further and name the >>> ?srcIndex? -> ?srcIndexLongs? for the long array case, >>> for example.? But since ?index? is used elsewhere as the >>> logical index I assumed that this would not be necessary. >>> >>> But I would much rather use longer, more explicit names >>> than propagate API clutter. >> >> I was thinking overnight that, perhaps, the memory copy >> and the single element cases are different. When you do >> single access (see above) you do that frequently in a >> loop - and you often get elements of the same type. As >> stated above, asking developers to work in terms of >> offsets seems a bit odd, when they are really accessing a >> flat array of element type T. >> >> In the case of bulk copy, I don't think there's the same >> degree of pressure - you will probably call the bulk copy >> at the beginning, or at the end of your computation (or >> both ends!) - and having an offset shift is more tolerable. >> >> So, I'm open to evaluating something more minimal, and >> see how far we can get with it. >> >> Maurizio >> >>> >>> Lee >>> >>> On Thu, Jun 3, 2021 at 1:26 PM Maurizio Cimadamore >>> >> > wrote: >>> >>> Thanks. >>> >>> While I agree that a segment is just a bunch of >>> bytes, I think also think that having an API which >>> takes two indices at the same time, one logical and >>> one physical is kind of evil. I bet that a lot of >>> developers will get that wrong, at least the first time. >>> >>> What you say about segments being an array of bytes, >>> and thus not needing index-based overloads can also >>> be said for MemoryAccess class - but I believe that >>> the index-based accessors in the are quite popular. >>> >>> But overall, my worry is not performances, or >>> symmetry with respect to other APIs - my main worry >>> is what I said above: that people will just assume >>> that indices are logical for both the segment and >>> the array - so overloads with clearly different >>> names should help quite a bit IMHO. >>> >>> >>> Maurizio >>> >>> On 03/06/2021 20:50, leerho wrote: >>>> Maurizio, >>>> Here is the MemoryCopy class (w/o byte swap) and >>>> the TestMemoryCopy class (w/o testing byte swap). >>>> >>>> I copied from the TestMemoryAccess class in that I >>>> noticed that there is no package statement.? I am >>>> not sure what?@SuppressWarnings are allowed in your >>>> test environment, I suspect I should remove all of >>>> them. >>>> >>>> When the MemorySegment?copyFrom(MemorySegment, >>>> MemoryLayout, ByteOrder) becomes available I can >>>> add the tests for that. >>>> >>>> *IMHO* >>>> >>>> I feel strongly that there is no need to >>>> additionally overload these methods with the >>>> segment offset specified in array index units.? >>>> It is so trivial to convert from one to the >>>> other and it can be done easily in the method >>>> argument?with a simple multiply?by 2, 4 or 8. >>>> This should compile down to a simple shift, >>>> which becomes a single cycle CPU instruction. >>>> So this?is not a performance issue. >>>> >>>> Furthermore, it is best that the user becomes >>>> accustomed to thinking of a segment >>>> fundamentally as an array of bytes.? Once a >>>> segment is loaded with some primitive array, >>>> the segment loses the context of the type of >>>> the array it was loaded with; in effect, a kind >>>> of "type erasure" similar to Java's generics. >>>> This is one of the reasons that MemorySegments >>>> can be so powerful. >>>> >>>> >>>> I have been programming with the >>>> "MemorySegment" concept for a number of years >>>> now and find that keeping in mind that segments >>>> are just bytes is very useful. >>>> >>>> >>>> Let me know what you think. >>>> >>>> Lee. >>>> >>>> >>>> >>>> On Mon, May 31, 2021 at 6:56 AM Maurizio Cimadamore >>>> >>> > wrote: >>>> >>>> Hi Lee, >>>> this looks good. >>>> >>>> One thing I note is that there's an ambiguity >>>> as to whether the segment index is expressed as >>>> a logical index, or a raw byte offset. Your >>>> snippet does the latter. If we want to follow >>>> MemoryAccess, perhaps that calls for 2 >>>> overloads >>>> (copyFromArrayAtIndex/copyFromArrayAtOffset), >>>> as I imagine both could be useful, depending on >>>> the case? >>>> >>>> The javadoc will have to say something when the >>>> segment being used is backed by the very array >>>> that is the source/target of the copy (we have >>>> some text like that in MemorySegment::copyFrom). >>>> >>>> I think it would be helpful to progress further >>>> with this, add the remaining templates (w/o >>>> ByteOrder, for now) test and see how it works >>>> in practice. >>>> >>>> I will add (or just file a simple PR, so that >>>> you can just borrow from it - should be a >>>> single method) something to do the segment copy >>>> with swap. >>>> >>>> Thanks! >>>> Maurizio >>>> >>>> On 28/05/2021 22:37, leerho wrote: >>>>> Maurizio, >>>>> >>>>> Again sorry about the delay. >>>>> >>>>> Attached is a template proposal for the >>>>> MemoryCopy class. >>>>> >>>>> I can't complete this without your proposed >>>>> new copyFrom(...) method in MemorySegment.?As >>>>> it is written, it should work, but without the >>>>> byte swap capability. >>>>> >>>>> I can complete the rest of the primitives like >>>>> this template, if you would like with >>>>> javadocs.? I could also start writing tests, >>>>> but without the byte-swap. >>>>> >>>>> Let me know what would be most?helpful. >>>>> >>>>> Cheers, >>>>> >>>>> Lee >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Thu, May 20, 2021 at 11:36 AM leerho >>>>> > >>>>> wrote: >>>>> >>>>> Of?course! >>>>> >>>>> On Thu, May 20, 2021 at 9:42 AM Maurizio >>>>> Cimadamore >>>> > >>>>> wrote: >>>>> >>>>> >>>>> On 20/05/2021 17:13, leerho wrote: >>>>>> I am not sure if the /dstSegSlice/ >>>>>> requires the /srcCopyLen/. I would >>>>>> hope that it is smart enough to >>>>>> realize that the input length is >>>>>> smaller than the given offset minus >>>>>> the segment size. >>>>> >>>>> asSlice has an overload that just >>>>> takes an offset and infers the >>>>> resulting size from there. >>>>> >>>>> But that doesn't seem what you want >>>>> here - as you want the slice to have a >>>>> specific size (the size of the input >>>>> array). >>>>> >>>>> MemorySegment::copyFrom wants the two >>>>> segments to have the same size, so I >>>>> think you need that. >>>>> >>>>> In terms of performance, there's no >>>>> difference between asSlice(offset) and >>>>> asSlice(offset, size) - you have to >>>>> create a new segment anyway. >>>>> >>>>> Maurizio >>>>> >>>>> >>> -- >>> From my cell phone. >> >> -- >> From my cell phone. >> From jbhateja at openjdk.java.net Wed Jun 9 12:11:26 2021 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Wed, 9 Jun 2021 12:11:26 GMT Subject: [vectorIntrinsics+mask] RFR: 8268154: Add masking support for vector load intrinsics In-Reply-To: References: Message-ID: On Mon, 7 Jun 2021 09:05:44 GMT, Xiaohong Gong wrote: > This patch adds the predicate support for masked load vector operation, including the Vector API java implementation and hotspot intrinsics changes. The main changes contain: > - Adding a new hotspot intrinsic method (`loadMasked`), which can transform the vector mask class and value to hotspot. It is called by the masked `"fromArray"` API in JAVA level. The compiler will generate the masked vector load node if the current platform supports the predicate feature and backend has implemented it. Otherwise, the vector blend pattern will be generated like before. > - Adding the similar masked support for load/store boolean/char array. > > Note that the intrinsification when there is the array range bailout is not implemented in this patch. We are considering making it vectorized with predicate feature for SVE/AVX-512 as well, and will create a separate patch for it in future. > > Also note that this patch doesn't contain any backend changes. Currently there following assertion check in both LoadVectorMaskedNode and StoreVectorMaskedNode `assert(mask->bottom_type()->is_vectmask(), "sanity");` This should be relaxed since mask argument will be VectorUnboxNode until macro expansion. I added following static routine in VectorNode class to get over it in my local sandbox, and adjusted the assertion to use it. If suitable maybe we can integrate it in this patch. bool VectorNode::is_vector_mask(Node* n) { if (n->bottom_type()->is_vectmask()) { return true; } if (n->Opcode() == Op_VectorUnbox) { const TypeInstPtr* vector_klass_from = n->as_VectorUnbox()->obj()->bottom_type()->isa_instptr(); ciKlass* vbox_klass_from = vector_klass_from->const_oop()->as_instance()->java_lang_Class_klass(); return vbox_klass_from->is_subclass_of(ciEnv::current()->vector_VectorMask_klass()); } return false; } Over all patch looks good to me. src/hotspot/share/opto/vectorIntrinsics.cpp line 956: > 954: bool use_predicate = Matcher::has_predicated_vectors() && > 955: arch_supports_vector(sopc, num_elem, elem_bt, VecMaskUseLoad) && > 956: Matcher::match_rule_supported_vector_masked(sopc, num_elem, elem_bt); Can we push both Matcher::has_predicated_vectors() && Matcher::match_rule_supported_vector_masked() into arch_supports_vector and either add an explicit bool argument to it or a new enum value to be passed i.e. VecMaskUseLoad | VecPredOper under which these checks are enforced. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/90 From psandoz at openjdk.java.net Wed Jun 9 17:17:25 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Wed, 9 Jun 2021 17:17:25 GMT Subject: [vectorIntrinsics] RFR: 8244490: [vector] Move Vector API micro benchmarks under test/micro [v5] In-Reply-To: <0Ei6kGZe2NcaaRvnVYYUfgqBo_wDV4B_xwFeWV0z5Ng=.1c02ee00-0d15-427f-885b-4979e82a3f86@github.com> References: <0Ei6kGZe2NcaaRvnVYYUfgqBo_wDV4B_xwFeWV0z5Ng=.1c02ee00-0d15-427f-885b-4979e82a3f86@github.com> Message-ID: On Tue, 8 Jun 2021 16:32:25 GMT, Marcus G K Williams wrote: >> Vector API micro benchmarks are currently located under test/jdk/jdk/incubator/vector/benchmark which makes them rather as "dead" code without possibility to built and run. >> >> The proper location for micro benchmarks is actually test/micro/ directory. >> It would be nice to move Vector API benchmarks there so they can be built automatically as part 'test-image' make target. >> Once they are built they can be run as >> make run-test TEST=micro:BENCHMARK_TEST_NAME > > Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision: > > Standardize copyright header, add 2021 > > Signed-off-by: Marcus G K Williams Thank you. Looks good. Just fix the license headers before integrating. Now we have the benchmarks integrated into the build system we can consider what it means to "curate". I am wondering if we should package the vector benchmarks as a separate jar to the other benchmarks. It might sound strange to say that given they were separate to begin with! but they were not integrated with the build system. That likely requires changes to the build system and discussion with the maintainers of the build system. We can start that conversation after integration. We can follow up with the `DecodeBench.java` issue after integration. test/jdk/jdk/incubator/vector/BENCHMARKS.md line 1: > 1: Benchmarks generated to test/micro/org/openjdk/bench/jdk/incubator/vector/operation Could you add a link/details on how to configure the build so JMH is included? test/jdk/jdk/incubator/vector/templates/Perf-Scalar-header.template line 2: > 1: /* > 2: * Copyright (c) 2018, 2020, 2021, Oracle and/or its affiliates. All rights reserved. Suggestion: * Copyright (c) 2018, 2021, Oracle and/or its affiliates. All rights reserved. We just use one year or the range. Hopefully not too tedious to change with a global search and replace. ------------- Marked as reviewed by psandoz (Committer). PR: https://git.openjdk.java.net/panama-vector/pull/77 From leerho at gmail.com Wed Jun 9 21:15:29 2021 From: leerho at gmail.com (leerho) Date: Wed, 9 Jun 2021 14:15:29 -0700 Subject: Part 1 Proposal for JDK-8264594 In-Reply-To: <06429259-99bf-4043-d611-24aa6fb353bd@oracle.com> References: <50605287-4e54-7dde-14e5-d521c19301be@oracle.com> <95c04a58-4897-0d49-3f13-d8aa6b293006@oracle.com> <87a484de-9cdc-ddc7-ff73-6dad2641d5a4@oracle.com> <0bd0724a-ce06-bb25-10a9-9f0641b359c1@oracle.com> <06429259-99bf-4043-d611-24aa6fb353bd@oracle.com> Message-ID: I'm sorry, I must be dense :-) I don't understand your previous email. - Why would one want to avoid a bulk copy? If you have to do a copy, a bulk copy is the fastest way to do it. (i.e., by "bulk" I mean a low level copy a la System.arrayCopy(...), which at the lowest level is just moving bytes, and by that criteria, both of your statements above are "bulk" copies ... :-) ). - Your "logical" rewrite is still specifying the offset in bytes as is the "Raw". I thought this whole discussion was to create an overloaded "logical" API that would specify the segment offset in array units (in this case, longs). - Both of your statements are missing a length parameter, which would be in longs. Please, please, don't discard the portion of the API that allows easy copying from/to arrays with a segment offset specified in bytes! I will gladly write the "logical" overload methods, if that is what you feel you need. If they are there I will use them, but only rarely. ***** Because I don't have your new "copyFrom" I'm going to temporarily mock it so I can test the byte-order version as I have the byte-order version of the test code ready to test. (It is a completely different rewrite of the test code I've given you so far.) Lee. On Wed, Jun 9, 2021 at 4:53 AM Maurizio Cimadamore < maurizio.cimadamore at oracle.com> wrote: > Thanks for the background. I think my question was ill-posed, as I realize > that even in the cases you describe, you could always avoid the need for a > bulk copy with raw byte offset by doing slicing and copy. > > e.g. > > copyIntoArrayRaw(segment, byteOffset, long[], arrayIndex) > > can be rewritten as: > > copyIntoArrayLogical(segment.asSlice(byteOffset), 0, long[], arrayIndex) > > > So, if we find that having a physical (segment offset) vs. logical (array > offset) mismatch is too confusing, we *could* fall back to slicing and > using logical offsets only. > > Maurizio > > > On 08/06/2021 17:54, leerho wrote: > > Question: do you have concrete use cases where you'd like to copy contents >> of a double[] at non-aligned positions inside a segment? > > > Absolutely! In fact, specifying the offset in bytes is probably the most > common. This is because many of our structs start with a preamble of a mix > of byte, short, int, and float fields, and then followed by several data > array regions. For example an array of ints followed by an array of longs, > which in some cases may not be unit aligned with the base of the segment. > This can be particularly true of structs that are defined by other users > where alignment cannot be guaranteed. In fact, one of our customers has > years of historical data (petabytes) that are not at all byte aligned. So > to assume that everything is neatly byte aligned would be a big mistake. > Unfortunately, many engineers that have created files of data over the > years did so without any awareness of the need for byte-alignment. > > Lee. > > > On Tue, Jun 8, 2021 at 7:00 AM Maurizio Cimadamore < > maurizio.cimadamore at oracle.com> wrote: > >> Hi Lee, >> thanks for this, I'll try to put together a PR in the next week or so. >> >> Re. overloads I was thinking about how the ByteBuffer API goes about >> them, and, in I see that that API doesn't have the same issues, given that >> ByteBuffer only provides bulk copy for byte arrays. If you want to bulk >> copy a double[] you have to convert to a DoubleBuffer first and then copy >> (and then use logical indices for the buffer too). >> >> Question: do you have concrete use cases where you'd like to copy >> contents of a double[] at non-aligned positions inside a segment? >> >> I'm asking because, in principle we could leave the methods in CopyMemory >> cover the aligned, logical indices only part of the API. And ask the user >> to fall back to MemorySegment::copyFrom if they really really want >> unaligned (which should be uncommon?). >> >> Cheers >> Maurizio >> On 08/06/2021 00:55, leerho wrote: >> >> Maurizio, >> I have updated MemoryCopy and TestMemoryCopy by extending the variable >> names to be even more clear, for example: >> >> - srcArr -> srcArray >> - srcSeg -> srcSegment >> - srcCopyLen -> srcCopyLengthInts >> - srcIndex -> srcIndexLongs >> - Etc. >> >> I also added a comment in the class javadoc describing the difference >> between variables with the word "index" and ones with the word "offset", >> etc. >> >> I have looked at what it would take to add overloads that refer to the >> segment offset in array element units. It can be done, but the names of >> these new methods will be kinda ugly or awkward: >> >> - copyFromArrayAtIndex -- confusing since the array uses index units >> already >> - copyAtIndexFromArray -- not much better >> - copyFromArrayWithIndex -- nah >> - copyFromArrayToSegementUsingIndex -- a little more clear, but >> really awkward >> >> If you have any better ideas, I am open. (But IMHO, I don't think we >> need this :) ) >> >> Please let me know what the next step should be :) >> >> Thanks! >> >> Lee. >> >> On Fri, Jun 4, 2021 at 7:09 AM leerho wrote: >> >>> Maurizio, >>> Thank you for your reply. I agree with your observation in the >>> difference between the single item case and the bulk copy. I guess I >>> became so familiar with how offsets are handled in Unsafe where the single >>> element and bulk copy cases the references to memory are always in bytes, >>> it seamed so simple and natural. >>> >>> In my experience anyway, reading and writing data to off-heap almost >>> always involves a mix of preamble elements and bulk copy arrays where it >>> was necessary to track the offset in bytes, where the multibyte elements >>> may not be correctly aligned to the base of the allocated segment, or God >>> forbid, the arrays. >>> >>> What is most important is getting this into the JDK, and if I have to >>> add more overloads, I will :) >>> >>> Lee. >>> >>> On Fri, Jun 4, 2021 at 2:34 AM Maurizio Cimadamore < >>> maurizio.cimadamore at oracle.com> wrote: >>> >>>> >>>> On 04/06/2021 01:32, leerho wrote: >>>> >>>> When I first saw all the logical index overloads in MemoryAccess I >>>> shuddered. It is a lot of API clutter as far as I?m concerned. But just >>>> because we made that mistake with MemoryAccess doesn?t mean we have to >>>> continue propagating it. >>>> >>>> I'm sorry, I just don't see that as being a "mistake". Code like this: >>>> >>>> ``` >>>> for (int i = 0 ; i < limit ; i++) { >>>> long val = MemoryAccess.getLongAtIndex(segment, i); >>>> ... >>>> } >>>> ``` >>>> >>>> Is _extremely_ common. While it's true that memory segment is an >>>> unbiased array of bytes, there are times you want to access it in a more >>>> structured form - and saying "you can't do that" because it adds overloads >>>> doesn't seem like a great solution to me. >>>> >>>> >>>> Also I have explicitly named the two offsets very differently to try to >>>> make it clear that they are very different. I guess I could go further and >>>> name the ?srcIndex? -> ?srcIndexLongs? for the long array case, for >>>> example. But since ?index? is used elsewhere as the logical index I >>>> assumed that this would not be necessary. >>>> >>>> But I would much rather use longer, more explicit names than propagate >>>> API clutter. >>>> >>>> I was thinking overnight that, perhaps, the memory copy and the single >>>> element cases are different. When you do single access (see above) you do >>>> that frequently in a loop - and you often get elements of the same type. As >>>> stated above, asking developers to work in terms of offsets seems a bit >>>> odd, when they are really accessing a flat array of element type T. >>>> >>>> In the case of bulk copy, I don't think there's the same degree of >>>> pressure - you will probably call the bulk copy at the beginning, or at the >>>> end of your computation (or both ends!) - and having an offset shift is >>>> more tolerable. >>>> >>>> So, I'm open to evaluating something more minimal, and see how far we >>>> can get with it. >>>> >>>> Maurizio >>>> >>>> >>>> Lee >>>> >>>> On Thu, Jun 3, 2021 at 1:26 PM Maurizio Cimadamore < >>>> maurizio.cimadamore at oracle.com> wrote: >>>> >>>>> Thanks. >>>>> >>>>> While I agree that a segment is just a bunch of bytes, I think also >>>>> think that having an API which takes two indices at the same time, one >>>>> logical and one physical is kind of evil. I bet that a lot of developers >>>>> will get that wrong, at least the first time. >>>>> >>>>> What you say about segments being an array of bytes, and thus not >>>>> needing index-based overloads can also be said for MemoryAccess class - but >>>>> I believe that the index-based accessors in the are quite popular. >>>>> >>>>> But overall, my worry is not performances, or symmetry with respect to >>>>> other APIs - my main worry is what I said above: that people will just >>>>> assume that indices are logical for both the segment and the array - so >>>>> overloads with clearly different names should help quite a bit IMHO. >>>>> >>>>> >>>>> Maurizio >>>>> On 03/06/2021 20:50, leerho wrote: >>>>> >>>>> Maurizio, >>>>> Here is the MemoryCopy class (w/o byte swap) and the TestMemoryCopy >>>>> class (w/o testing byte swap). >>>>> >>>>> I copied from the TestMemoryAccess class in that I noticed that there >>>>> is no package statement. I am not sure what @SuppressWarnings are allowed >>>>> in your test environment, I suspect I should remove all of them. >>>>> >>>>> When the MemorySegment copyFrom(MemorySegment, MemoryLayout, >>>>> ByteOrder) becomes available I can add the tests for that. >>>>> >>>>> *IMHO* >>>>> >>>>> I feel strongly that there is no need to additionally overload these >>>>> methods with the segment offset specified in array index units. It is so >>>>> trivial to convert from one to the other and it can be done easily in the >>>>> method argument with a simple multiply by 2, 4 or 8. This should compile >>>>> down to a simple shift, which becomes a single cycle CPU instruction. So >>>>> this is not a performance issue. >>>>> >>>>> Furthermore, it is best that the user becomes accustomed to thinking >>>>> of a segment fundamentally as an array of bytes. Once a segment is loaded >>>>> with some primitive array, the segment loses the context of the type of the >>>>> array it was loaded with; in effect, a kind of "type erasure" similar to >>>>> Java's generics. This is one of the reasons that MemorySegments can be so >>>>> powerful. >>>>> >>>>> >>>>> I have been programming with the "MemorySegment" concept for a number >>>>> of years now and find that keeping in mind that segments are just bytes is >>>>> very useful. >>>>> >>>>> >>>>> Let me know what you think. >>>>> >>>>> Lee. >>>>> >>>>> >>>>> >>>>> On Mon, May 31, 2021 at 6:56 AM Maurizio Cimadamore < >>>>> maurizio.cimadamore at oracle.com> wrote: >>>>> >>>>>> Hi Lee, >>>>>> this looks good. >>>>>> >>>>>> One thing I note is that there's an ambiguity as to whether the >>>>>> segment index is expressed as a logical index, or a raw byte offset. Your >>>>>> snippet does the latter. If we want to follow MemoryAccess, perhaps that >>>>>> calls for 2 overloads (copyFromArrayAtIndex/copyFromArrayAtOffset), as I >>>>>> imagine both could be useful, depending on the case? >>>>>> >>>>>> The javadoc will have to say something when the segment being used is >>>>>> backed by the very array that is the source/target of the copy (we have >>>>>> some text like that in MemorySegment::copyFrom). >>>>>> >>>>>> I think it would be helpful to progress further with this, add the >>>>>> remaining templates (w/o ByteOrder, for now) test and see how it works in >>>>>> practice. >>>>>> >>>>>> I will add (or just file a simple PR, so that you can just borrow >>>>>> from it - should be a single method) something to do the segment copy with >>>>>> swap. >>>>>> >>>>>> Thanks! >>>>>> Maurizio >>>>>> On 28/05/2021 22:37, leerho wrote: >>>>>> >>>>>> Maurizio, >>>>>> >>>>>> Again sorry about the delay. >>>>>> >>>>>> Attached is a template proposal for the MemoryCopy class. >>>>>> >>>>>> I can't complete this without your proposed new copyFrom(...) method >>>>>> in MemorySegment. As it is written, it should work, but without the byte >>>>>> swap capability. >>>>>> >>>>>> I can complete the rest of the primitives like this template, if you >>>>>> would like with javadocs. I could also start writing tests, but without >>>>>> the byte-swap. >>>>>> >>>>>> Let me know what would be most helpful. >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Lee >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Thu, May 20, 2021 at 11:36 AM leerho wrote: >>>>>> >>>>>>> Of course! >>>>>>> >>>>>>> On Thu, May 20, 2021 at 9:42 AM Maurizio Cimadamore < >>>>>>> maurizio.cimadamore at oracle.com> wrote: >>>>>>> >>>>>>>> >>>>>>>> On 20/05/2021 17:13, leerho wrote: >>>>>>>> >>>>>>>> I am not sure if the *dstSegSlice* requires the *srcCopyLen*. I >>>>>>>> would hope that it is smart enough to realize that the input length is >>>>>>>> smaller than the given offset minus the segment size. >>>>>>>> >>>>>>>> asSlice has an overload that just takes an offset and infers the >>>>>>>> resulting size from there. >>>>>>>> >>>>>>>> But that doesn't seem what you want here - as you want the slice to >>>>>>>> have a specific size (the size of the input array). >>>>>>>> >>>>>>>> MemorySegment::copyFrom wants the two segments to have the same >>>>>>>> size, so I think you need that. >>>>>>>> >>>>>>>> In terms of performance, there's no difference between >>>>>>>> asSlice(offset) and asSlice(offset, size) - you have to create a new >>>>>>>> segment anyway. >>>>>>>> >>>>>>>> Maurizio >>>>>>>> >>>>>>>> >>>>>>>> -- >>>> From my cell phone. >>>> >>>> -- >>> From my cell phone. >>> >> From maurizio.cimadamore at oracle.com Wed Jun 9 21:48:01 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 9 Jun 2021 22:48:01 +0100 Subject: Part 1 Proposal for JDK-8264594 In-Reply-To: References: <95c04a58-4897-0d49-3f13-d8aa6b293006@oracle.com> <87a484de-9cdc-ddc7-ff73-6dad2641d5a4@oracle.com> <0bd0724a-ce06-bb25-10a9-9f0641b359c1@oracle.com> <06429259-99bf-4043-d611-24aa6fb353bd@oracle.com> Message-ID: <8785fd57-baf3-cb86-e715-9f8f66c74684@oracle.com> On 09/06/2021 22:15, leerho wrote: > I'm sorry, I must be dense :-)? I don't understand your previous email. > > * Why would one want to avoid a bulk copy? If you have to do a copy, > a bulk copy is the fastest way to do it. > (i.e., by "bulk" I mean a low level copy a la > System.arrayCopy(...), which at the lowest level is just moving > bytes, > and by that criteria, both of your?statements above are "bulk" > copies ... :-)? ?). > Hard to parse sentence "avoid the need bulk copy **with raw byte offset**" E.g. as in: you can use slicing to effectively have a way to support bulk copy with raw offsets even if you just have bulk copy primitives with logical indices. > * Your "logical" rewrite is still specifying the offset in bytes as > is the "Raw".? I thought this whole discussion was to create an > overloaded "logical"?API that would specify the segment offset in > array units (in this case, longs). > No, the logical rewrite is accepting an index, which in my example happened to be zero. But if the example said "1", it would have meant offset of "8" and so forth. > > * Both of your statements are missing a length parameter, which > would be in longs. > ok > Please, please,? don't discard the portion of the API that allows easy > copying from/to arrays with a segment offset specified in bytes! I > will gladly write the "logical" overload methods, if that is what you > feel you need.? If they are there I will use them, but only rarely. I'm not discarding anything - I'm merely considering alternate options for the design of this API. The main point I've been trying to get across in this entire thread, is that there is an issue when it comes to having mismatched logical vs. physical offsets in the same API method. From here, we could go in several ways: * provide only physical offset for segments and live with the mismatch (this is your opening proposal) * provide both logical and physical-accepting overloads (this is what I proposed few weeks ago) * provide only logical indices for segments, and ask users to resort to slicing when they want to copy things at unaligned offsets (this is what I proposed today) As stated elsewhere, I think I'm ok with starting this exploration at the first stop (physical only). But I was mostly trying to proactively shake the design space, to see if some other alternative came up, in case the logical/physical mismatch doesn't work out great in real world use cases. I'd also like others (Uwe?) to weigh in, as I'd expect different frameworks to have different expectations in what a "Right" API for copying arrays would look like. If we are to add something, we should try to find a balanced solution. Maurizio > > ***** > Because?I don't have your new "copyFrom" I'm going to temporarily mock > it so I can test the byte-order version as I have the byte-order > version of the test code ready to test.? (It is a completely different > rewrite of the test code I've given you so far.) > > Lee. > > > On Wed, Jun 9, 2021 at 4:53 AM Maurizio Cimadamore > > wrote: > > Thanks for the background. I think my question was ill-posed, as I > realize that even in the cases you describe, you could always > avoid the need for a bulk copy with raw byte offset by doing > slicing and copy. > > e.g. > > copyIntoArrayRaw(segment, byteOffset, long[], arrayIndex) > > can be rewritten as: > > copyIntoArrayLogical(segment.asSlice(byteOffset), 0, long[], > arrayIndex) > > > So, if we find that having a physical (segment offset) vs. logical > (array offset) mismatch is too confusing, we *could* fall back to > slicing and using logical offsets only. > > Maurizio > > > On 08/06/2021 17:54, leerho wrote: >> >> Question: do you have concrete use cases where you'd like to >> copy contents of a double[] at non-aligned positions inside a >> segment? >> >> >> Absolutely!? ?In fact, specifying the?offset in bytes is probably >> the most common.? This is because many of our structs start with >> a preamble of a mix of byte, short, int, and float fields, and >> then followed by several data array regions.? For example an >> array of ints followed by an array of longs, which in some cases >> may not be unit aligned with the base of the segment.? This can >> be particularly true of structs that are defined by other users >> where alignment cannot be guaranteed.? ?In fact, one of our >> customers has years of historical data (petabytes) that are not >> at all byte aligned.? So to assume that everything is neatly byte >> aligned would be a big mistake. Unfortunately, many engineers >> that have created files of data over the years did so without any >> awareness of the need for byte-alignment. >> >> Lee. >> >> On Tue, Jun 8, 2021 at 7:00 AM Maurizio Cimadamore >> > > wrote: >> >> Hi Lee, >> thanks for this, I'll try to put together a PR in the next >> week or so. >> >> Re. overloads I was thinking about how the ByteBuffer API >> goes about them, and, in I see that that API doesn't have the >> same issues, given that ByteBuffer only provides bulk copy >> for byte arrays. If you want to bulk copy a double[] you have >> to convert to a DoubleBuffer first and then copy (and then >> use logical indices for the buffer too). >> >> Question: do you have concrete use cases where you'd like to >> copy contents of a double[] at non-aligned positions inside a >> segment? >> >> I'm asking because, in principle we could leave the methods >> in CopyMemory cover the aligned, logical indices only part of >> the API. And ask the user to fall back to >> MemorySegment::copyFrom if they really really want unaligned >> (which should be uncommon?). >> >> Cheers >> Maurizio >> >> On 08/06/2021 00:55, leerho wrote: >>> Maurizio, >>> I have updated MemoryCopy and TestMemoryCopy by extending >>> the variable names to be even more clear, for example: >>> >>> * srcArr -> srcArray >>> * srcSeg -> srcSegment >>> * srcCopyLen -> srcCopyLengthInts >>> * srcIndex -> srcIndexLongs >>> * Etc. >>> >>> I also added a comment in the class javadoc describing the >>> difference between variables with the word "index" and ones >>> with the word "offset", etc. >>> >>> I have looked at what it would take to add overloads that >>> refer to the segment offset in array element units.? It can >>> be done, but the names of these new methods will be kinda >>> ugly or awkward: >>> >>> * copyFromArrayAtIndex -- confusing since the array uses >>> index units already >>> * copyAtIndexFromArray -- not much better >>> * copyFromArrayWithIndex -- nah >>> * copyFromArrayToSegementUsingIndex -- a little more >>> clear, but really awkward >>> >>> If you have any better ideas, I am open. (But IMHO, I don't >>> think we need this :) ) >>> >>> Please let me know what the next step should be :) >>> >>> Thanks! >>> >>> Lee. >>> >>> On Fri, Jun 4, 2021 at 7:09 AM leerho >> > wrote: >>> >>> Maurizio, >>> Thank you for your reply.? I agree with your observation >>> in the difference between the single item case and the >>> bulk copy.? I guess I became so familiar with how >>> offsets are handled in Unsafe where the single element >>> and bulk copy cases the references to memory are always >>> in bytes, it seamed so simple and natural. >>> >>> In my experience anyway, reading and writing data to >>> off-heap almost always involves a mix of preamble >>> elements and bulk copy arrays where it was necessary to >>> track the offset in bytes, where the multibyte elements >>> may not be correctly aligned to the base of the >>> allocated segment, or God forbid, the arrays. >>> >>> What is most important is getting this into the JDK, and >>> if I have to add more overloads, I will :) >>> >>> Lee. >>> >>> On Fri, Jun 4, 2021 at 2:34 AM Maurizio Cimadamore >>> >> > wrote: >>> >>> >>> On 04/06/2021 01:32, leerho wrote: >>>> When I first saw all the logical index overloads in >>>> MemoryAccess I shuddered.? It is a lot of API >>>> clutter as far as I?m concerned.? But just because >>>> we made that mistake with MemoryAccess doesn?t mean >>>> we have to continue propagating it. >>> >>> I'm sorry, I just don't see that as being a >>> "mistake". Code like this: >>> >>> ``` >>> for (int i = 0 ; i < limit ; i++) { >>> ?? long val = MemoryAccess.getLongAtIndex(segment, i); >>> ?? ... >>> } >>> ``` >>> >>> Is _extremely_ common. While it's true that memory >>> segment is an unbiased array of bytes, there are >>> times you want to access it in a more structured >>> form - and saying "you can't do that" because it >>> adds overloads doesn't seem like a great solution to me. >>> >>>> >>>> Also I have explicitly named the two offsets very >>>> differently to try to make it clear that they are >>>> very different.? I guess I could go further and >>>> name the ?srcIndex? -> ?srcIndexLongs? for the long >>>> array case, for example.? But since ?index? is used >>>> elsewhere as the logical index I assumed that this >>>> would not be necessary. >>>> >>>> But I would much rather use longer, more explicit >>>> names than propagate API clutter. >>> >>> I was thinking overnight that, perhaps, the memory >>> copy and the single element cases are different. >>> When you do single access (see above) you do that >>> frequently in a loop - and you often get elements of >>> the same type. As stated above, asking developers to >>> work in terms of offsets seems a bit odd, when they >>> are really accessing a flat array of element type T. >>> >>> In the case of bulk copy, I don't think there's the >>> same degree of pressure - you will probably call the >>> bulk copy at the beginning, or at the end of your >>> computation (or both ends!) - and having an offset >>> shift is more tolerable. >>> >>> So, I'm open to evaluating something more minimal, >>> and see how far we can get with it. >>> >>> Maurizio >>> >>>> >>>> Lee >>>> >>>> On Thu, Jun 3, 2021 at 1:26 PM Maurizio Cimadamore >>>> >>> > wrote: >>>> >>>> Thanks. >>>> >>>> While I agree that a segment is just a bunch of >>>> bytes, I think also think that having an API >>>> which takes two indices at the same time, one >>>> logical and one physical is kind of evil. I bet >>>> that a lot of developers will get that wrong, >>>> at least the first time. >>>> >>>> What you say about segments being an array of >>>> bytes, and thus not needing index-based >>>> overloads can also be said for MemoryAccess >>>> class - but I believe that the index-based >>>> accessors in the are quite popular. >>>> >>>> But overall, my worry is not performances, or >>>> symmetry with respect to other APIs - my main >>>> worry is what I said above: that people will >>>> just assume that indices are logical for both >>>> the segment and the array - so overloads with >>>> clearly different names should help quite a bit >>>> IMHO. >>>> >>>> >>>> Maurizio >>>> >>>> On 03/06/2021 20:50, leerho wrote: >>>>> Maurizio, >>>>> Here is the MemoryCopy class (w/o byte swap) >>>>> and the TestMemoryCopy class (w/o testing byte >>>>> swap). >>>>> >>>>> I copied from the TestMemoryAccess class in >>>>> that I noticed that there is no package >>>>> statement.? I am not sure >>>>> what?@SuppressWarnings are allowed in your >>>>> test environment, I suspect I should remove >>>>> all of them. >>>>> >>>>> When the MemorySegment?copyFrom(MemorySegment, >>>>> MemoryLayout, ByteOrder) becomes available I >>>>> can add the tests for that. >>>>> >>>>> *IMHO* >>>>> >>>>> I feel strongly that there is no need to >>>>> additionally overload these methods with >>>>> the segment offset specified in array >>>>> index units.? It is so trivial to convert >>>>> from one to the other and it can be done >>>>> easily in the method argument?with a >>>>> simple multiply?by 2, 4 or 8. This should >>>>> compile down to a simple shift, which >>>>> becomes a single cycle CPU instruction.? >>>>> So this?is not a performance issue. >>>>> >>>>> Furthermore, it is best that the user >>>>> becomes accustomed to thinking of a >>>>> segment fundamentally as an array of >>>>> bytes. Once a segment is loaded with some >>>>> primitive array, the segment loses the >>>>> context of the type of the array it was >>>>> loaded with; in effect, a kind of "type >>>>> erasure" similar to Java's generics.? This >>>>> is one of the reasons that MemorySegments >>>>> can be so powerful. >>>>> >>>>> >>>>> I have been programming with the >>>>> "MemorySegment" concept for a number of >>>>> years now and find that keeping in mind >>>>> that segments are just bytes is very useful. >>>>> >>>>> >>>>> Let me know what you think. >>>>> >>>>> Lee. >>>>> >>>>> >>>>> >>>>> On Mon, May 31, 2021 at 6:56 AM Maurizio >>>>> Cimadamore >>>> > wrote: >>>>> >>>>> Hi Lee, >>>>> this looks good. >>>>> >>>>> One thing I note is that there's an >>>>> ambiguity as to whether the segment index >>>>> is expressed as a logical index, or a raw >>>>> byte offset. Your snippet does the latter. >>>>> If we want to follow MemoryAccess, perhaps >>>>> that calls for 2 overloads >>>>> (copyFromArrayAtIndex/copyFromArrayAtOffset), >>>>> as I imagine both could be useful, >>>>> depending on the case? >>>>> >>>>> The javadoc will have to say something >>>>> when the segment being used is backed by >>>>> the very array that is the source/target >>>>> of the copy (we have some text like that >>>>> in MemorySegment::copyFrom). >>>>> >>>>> I think it would be helpful to progress >>>>> further with this, add the remaining >>>>> templates (w/o ByteOrder, for now) test >>>>> and see how it works in practice. >>>>> >>>>> I will add (or just file a simple PR, so >>>>> that you can just borrow from it - should >>>>> be a single method) something to do the >>>>> segment copy with swap. >>>>> >>>>> Thanks! >>>>> Maurizio >>>>> >>>>> On 28/05/2021 22:37, leerho wrote: >>>>>> Maurizio, >>>>>> >>>>>> Again sorry about the delay. >>>>>> >>>>>> Attached is a template proposal for the >>>>>> MemoryCopy class. >>>>>> >>>>>> I can't complete this without your >>>>>> proposed new copyFrom(...) method in >>>>>> MemorySegment.?As it is written, it >>>>>> should work, but without the byte swap >>>>>> capability. >>>>>> >>>>>> I can complete the rest of the primitives >>>>>> like this template, if you would like >>>>>> with javadocs.? I could also start >>>>>> writing tests, but without the byte-swap. >>>>>> >>>>>> Let me know what would be most?helpful. >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Lee >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Thu, May 20, 2021 at 11:36 AM leerho >>>>>> >>>>> > wrote: >>>>>> >>>>>> Of?course! >>>>>> >>>>>> On Thu, May 20, 2021 at 9:42 AM >>>>>> Maurizio Cimadamore >>>>>> >>>>> > >>>>>> wrote: >>>>>> >>>>>> >>>>>> On 20/05/2021 17:13, leerho wrote: >>>>>>> I am not sure if the >>>>>>> /dstSegSlice/ requires the >>>>>>> /srcCopyLen/. I would hope that >>>>>>> it is smart enough to realize >>>>>>> that the input length is smaller >>>>>>> than the given offset minus the >>>>>>> segment size. >>>>>> >>>>>> asSlice has an overload that just >>>>>> takes an offset and infers the >>>>>> resulting size from there. >>>>>> >>>>>> But that doesn't seem what you >>>>>> want here - as you want the slice >>>>>> to have a specific size (the size >>>>>> of the input array). >>>>>> >>>>>> MemorySegment::copyFrom wants the >>>>>> two segments to have the same >>>>>> size, so I think you need that. >>>>>> >>>>>> In terms of performance, there's >>>>>> no difference between >>>>>> asSlice(offset) and >>>>>> asSlice(offset, size) - you have >>>>>> to create a new segment anyway. >>>>>> >>>>>> Maurizio >>>>>> >>>>>> >>>> -- >>>> From my cell phone. >>> >>> -- >>> From my cell phone. >>> From psandoz at openjdk.java.net Wed Jun 9 22:27:22 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Wed, 9 Jun 2021 22:27:22 GMT Subject: [vectorIntrinsics+mask] RFR: 8268154: Add masking support for vector load intrinsics In-Reply-To: References: Message-ID: On Mon, 7 Jun 2021 09:05:44 GMT, Xiaohong Gong wrote: > This patch adds the predicate support for masked load vector operation, including the Vector API java implementation and hotspot intrinsics changes. The main changes contain: > - Adding a new hotspot intrinsic method (`loadMasked`), which can transform the vector mask class and value to hotspot. It is called by the masked `"fromArray"` API in JAVA level. The compiler will generate the masked vector load node if the current platform supports the predicate feature and backend has implemented it. Otherwise, the vector blend pattern will be generated like before. > - Adding the similar masked support for load/store boolean/char array. > > Note that the intrinsification when there is the array range bailout is not implemented in this patch. We are considering making it vectorized with predicate feature for SVE/AVX-512 as well, and will create a separate patch for it in future. > > Also note that this patch doesn't contain any backend changes. Java changes look good. No need for me to re-review to resolve the comment i made. src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template line 4579: > 4577: a, arrayAddress(a, offset), m, > 4578: a, offset, vsp, > 4579: (arr, off, s, vm) -> s.ldOp(arr, off, (AbstractMask<$Boxtype$>) vm, We can avoid the cast to `AbstractMask<$Boxtype$>` if we update the signature of the species `ldOp` to be e.g on `IntVector`: IntVector ldOp(M memory, int offset, VectorMask m, FLdOp f) { return dummyVector().ldOp(memory, offset, m, f); } In general i think we need to review the generic signatures here and in `VectorSupport`, as they are a bit inconsistent. Something to consider later. ------------- Marked as reviewed by psandoz (Committer). PR: https://git.openjdk.java.net/panama-vector/pull/90 From leerho at gmail.com Wed Jun 9 23:02:57 2021 From: leerho at gmail.com (leerho) Date: Wed, 9 Jun 2021 16:02:57 -0700 Subject: Part 1 Proposal for JDK-8264594 In-Reply-To: <8785fd57-baf3-cb86-e715-9f8f66c74684@oracle.com> References: <95c04a58-4897-0d49-3f13-d8aa6b293006@oracle.com> <87a484de-9cdc-ddc7-ff73-6dad2641d5a4@oracle.com> <0bd0724a-ce06-bb25-10a9-9f0641b359c1@oracle.com> <06429259-99bf-4043-d611-24aa6fb353bd@oracle.com> <8785fd57-baf3-cb86-e715-9f8f66c74684@oracle.com> Message-ID: Thank you for your explanation, and yes, I would like to hear from others as well. If I may rewrite your options with more detail: 1. copyIntoArrayRaw(segment, offsetBytes, long[] dstArray, dstIndexLongs, dstCopyLengthLongs) 2. copyIntoArrayRaw(segment, offsetBytes, long[] dstArray, dstIndexLongs, dstCopyLengthLongs) And copyIntoArrayLogical(segment, srcOffsetLongs, long[] dstArray, dstIndexLongs, dstCopyLengthLongs) 3. copyIntoArrayLogical(segment, srcOffsetLongs, long[] dstArray, dstIndexLongs, dstCopyLengthLongs) //User has option to write compound statement like: copyIntoArrayLogical(segment.asSlice(srcOffsetBytes, copyLengthBytes), 0, long[] dstArray, dstIndexLongs, dstCopyLengthLongs) // I think we discussed a while back that the asSlice would also require a length. For those of us that must deal with complex structs that contain arrays (not always aligned), the 3rd alternative is extra pain. I would certainly be happy with either 1 or 2. Lee. On Wed, Jun 9, 2021 at 2:48 PM Maurizio Cimadamore < maurizio.cimadamore at oracle.com> wrote: > > On 09/06/2021 22:15, leerho wrote: > > I'm sorry, I must be dense :-) I don't understand your previous email. > > - Why would one want to avoid a bulk copy? If you have to do a copy, a > bulk copy is the fastest way to do it. > (i.e., by "bulk" I mean a low level copy a la System.arrayCopy(...), > which at the lowest level is just moving bytes, > and by that criteria, both of your statements above are "bulk" copies > ... :-) ). > > Hard to parse sentence "avoid the need bulk copy **with raw byte offset**" > > E.g. as in: you can use slicing to effectively have a way to support bulk > copy with raw offsets even if you just have bulk copy primitives with > logical indices. > > > - Your "logical" rewrite is still specifying the offset in bytes as is > the "Raw". I thought this whole discussion was to create an overloaded > "logical" API that would specify the segment offset in array units (in this > case, longs). > > No, the logical rewrite is accepting an index, which in my example > happened to be zero. But if the example said "1", it would have meant > offset of "8" and so forth. > > > - Both of your statements are missing a length parameter, which would > be in longs. > > ok > > Please, please, don't discard the portion of the API that allows easy > copying from/to arrays with a segment offset specified in bytes! I will > gladly write the "logical" overload methods, if that is what you feel you > need. If they are there I will use them, but only rarely. > > I'm not discarding anything - I'm merely considering alternate options for > the design of this API. > > The main point I've been trying to get across in this entire thread, is > that there is an issue when it comes to having mismatched logical vs. > physical offsets in the same API method. From here, we could go in several > ways: > > * provide only physical offset for segments and live with the mismatch > (this is your opening proposal) > * provide both logical and physical-accepting overloads (this is what I > proposed few weeks ago) > * provide only logical indices for segments, and ask users to resort to > slicing when they want to copy things at unaligned offsets (this is what I > proposed today) > > As stated elsewhere, I think I'm ok with starting this exploration at the > first stop (physical only). But I was mostly trying to proactively shake > the design space, to see if some other alternative came up, in case the > logical/physical mismatch doesn't work out great in real world use cases. > > I'd also like others (Uwe?) to weigh in, as I'd expect different > frameworks to have different expectations in what a "Right" API for copying > arrays would look like. If we are to add something, we should try to find a > balanced solution. > > Maurizio > > > > > ***** > Because I don't have your new "copyFrom" I'm going to temporarily mock it > so I can test the byte-order version as I have the byte-order version of > the test code ready to test. (It is a completely different rewrite of the > test code I've given you so far.) > > Lee. > > > On Wed, Jun 9, 2021 at 4:53 AM Maurizio Cimadamore < > maurizio.cimadamore at oracle.com> wrote: > >> Thanks for the background. I think my question was ill-posed, as I >> realize that even in the cases you describe, you could always avoid the >> need for a bulk copy with raw byte offset by doing slicing and copy. >> >> e.g. >> >> copyIntoArrayRaw(segment, byteOffset, long[], arrayIndex) >> >> can be rewritten as: >> >> copyIntoArrayLogical(segment.asSlice(byteOffset), 0, long[], arrayIndex) >> >> >> So, if we find that having a physical (segment offset) vs. logical (array >> offset) mismatch is too confusing, we *could* fall back to slicing and >> using logical offsets only. >> >> Maurizio >> >> >> On 08/06/2021 17:54, leerho wrote: >> >> Question: do you have concrete use cases where you'd like to copy >>> contents of a double[] at non-aligned positions inside a segment? >> >> >> Absolutely! In fact, specifying the offset in bytes is probably the >> most common. This is because many of our structs start with a preamble of >> a mix of byte, short, int, and float fields, and then followed by several >> data array regions. For example an array of ints followed by an array of >> longs, which in some cases may not be unit aligned with the base of the >> segment. This can be particularly true of structs that are defined by >> other users where alignment cannot be guaranteed. In fact, one of our >> customers has years of historical data (petabytes) that are not at all byte >> aligned. So to assume that everything is neatly byte aligned would be a >> big mistake. Unfortunately, many engineers that have created files of data >> over the years did so without any awareness of the need for >> byte-alignment. >> >> Lee. >> >> >> On Tue, Jun 8, 2021 at 7:00 AM Maurizio Cimadamore < >> maurizio.cimadamore at oracle.com> wrote: >> >>> Hi Lee, >>> thanks for this, I'll try to put together a PR in the next week or so. >>> >>> Re. overloads I was thinking about how the ByteBuffer API goes about >>> them, and, in I see that that API doesn't have the same issues, given that >>> ByteBuffer only provides bulk copy for byte arrays. If you want to bulk >>> copy a double[] you have to convert to a DoubleBuffer first and then copy >>> (and then use logical indices for the buffer too). >>> >>> Question: do you have concrete use cases where you'd like to copy >>> contents of a double[] at non-aligned positions inside a segment? >>> >>> I'm asking because, in principle we could leave the methods in >>> CopyMemory cover the aligned, logical indices only part of the API. And ask >>> the user to fall back to MemorySegment::copyFrom if they really really want >>> unaligned (which should be uncommon?). >>> >>> Cheers >>> Maurizio >>> On 08/06/2021 00:55, leerho wrote: >>> >>> Maurizio, >>> I have updated MemoryCopy and TestMemoryCopy by extending the variable >>> names to be even more clear, for example: >>> >>> - srcArr -> srcArray >>> - srcSeg -> srcSegment >>> - srcCopyLen -> srcCopyLengthInts >>> - srcIndex -> srcIndexLongs >>> - Etc. >>> >>> I also added a comment in the class javadoc describing the difference >>> between variables with the word "index" and ones with the word "offset", >>> etc. >>> >>> I have looked at what it would take to add overloads that refer to the >>> segment offset in array element units. It can be done, but the names of >>> these new methods will be kinda ugly or awkward: >>> >>> - copyFromArrayAtIndex -- confusing since the array uses index units >>> already >>> - copyAtIndexFromArray -- not much better >>> - copyFromArrayWithIndex -- nah >>> - copyFromArrayToSegementUsingIndex -- a little more clear, but >>> really awkward >>> >>> If you have any better ideas, I am open. (But IMHO, I don't think we >>> need this :) ) >>> >>> Please let me know what the next step should be :) >>> >>> Thanks! >>> >>> Lee. >>> >>> On Fri, Jun 4, 2021 at 7:09 AM leerho wrote: >>> >>>> Maurizio, >>>> Thank you for your reply. I agree with your observation in the >>>> difference between the single item case and the bulk copy. I guess I >>>> became so familiar with how offsets are handled in Unsafe where the single >>>> element and bulk copy cases the references to memory are always in bytes, >>>> it seamed so simple and natural. >>>> >>>> In my experience anyway, reading and writing data to off-heap almost >>>> always involves a mix of preamble elements and bulk copy arrays where it >>>> was necessary to track the offset in bytes, where the multibyte elements >>>> may not be correctly aligned to the base of the allocated segment, or God >>>> forbid, the arrays. >>>> >>>> What is most important is getting this into the JDK, and if I have to >>>> add more overloads, I will :) >>>> >>>> Lee. >>>> >>>> On Fri, Jun 4, 2021 at 2:34 AM Maurizio Cimadamore < >>>> maurizio.cimadamore at oracle.com> wrote: >>>> >>>>> >>>>> On 04/06/2021 01:32, leerho wrote: >>>>> >>>>> When I first saw all the logical index overloads in MemoryAccess I >>>>> shuddered. It is a lot of API clutter as far as I?m concerned. But just >>>>> because we made that mistake with MemoryAccess doesn?t mean we have to >>>>> continue propagating it. >>>>> >>>>> I'm sorry, I just don't see that as being a "mistake". Code like this: >>>>> >>>>> ``` >>>>> for (int i = 0 ; i < limit ; i++) { >>>>> long val = MemoryAccess.getLongAtIndex(segment, i); >>>>> ... >>>>> } >>>>> ``` >>>>> >>>>> Is _extremely_ common. While it's true that memory segment is an >>>>> unbiased array of bytes, there are times you want to access it in a more >>>>> structured form - and saying "you can't do that" because it adds overloads >>>>> doesn't seem like a great solution to me. >>>>> >>>>> >>>>> Also I have explicitly named the two offsets very differently to try >>>>> to make it clear that they are very different. I guess I could go further >>>>> and name the ?srcIndex? -> ?srcIndexLongs? for the long array case, for >>>>> example. But since ?index? is used elsewhere as the logical index I >>>>> assumed that this would not be necessary. >>>>> >>>>> But I would much rather use longer, more explicit names than propagate >>>>> API clutter. >>>>> >>>>> I was thinking overnight that, perhaps, the memory copy and the single >>>>> element cases are different. When you do single access (see above) you do >>>>> that frequently in a loop - and you often get elements of the same type. As >>>>> stated above, asking developers to work in terms of offsets seems a bit >>>>> odd, when they are really accessing a flat array of element type T. >>>>> >>>>> In the case of bulk copy, I don't think there's the same degree of >>>>> pressure - you will probably call the bulk copy at the beginning, or at the >>>>> end of your computation (or both ends!) - and having an offset shift is >>>>> more tolerable. >>>>> >>>>> So, I'm open to evaluating something more minimal, and see how far we >>>>> can get with it. >>>>> >>>>> Maurizio >>>>> >>>>> >>>>> Lee >>>>> >>>>> On Thu, Jun 3, 2021 at 1:26 PM Maurizio Cimadamore < >>>>> maurizio.cimadamore at oracle.com> wrote: >>>>> >>>>>> Thanks. >>>>>> >>>>>> While I agree that a segment is just a bunch of bytes, I think also >>>>>> think that having an API which takes two indices at the same time, one >>>>>> logical and one physical is kind of evil. I bet that a lot of developers >>>>>> will get that wrong, at least the first time. >>>>>> >>>>>> What you say about segments being an array of bytes, and thus not >>>>>> needing index-based overloads can also be said for MemoryAccess class - but >>>>>> I believe that the index-based accessors in the are quite popular. >>>>>> >>>>>> But overall, my worry is not performances, or symmetry with respect >>>>>> to other APIs - my main worry is what I said above: that people will just >>>>>> assume that indices are logical for both the segment and the array - so >>>>>> overloads with clearly different names should help quite a bit IMHO. >>>>>> >>>>>> >>>>>> Maurizio >>>>>> On 03/06/2021 20:50, leerho wrote: >>>>>> >>>>>> Maurizio, >>>>>> Here is the MemoryCopy class (w/o byte swap) and the TestMemoryCopy >>>>>> class (w/o testing byte swap). >>>>>> >>>>>> I copied from the TestMemoryAccess class in that I noticed that there >>>>>> is no package statement. I am not sure what @SuppressWarnings are allowed >>>>>> in your test environment, I suspect I should remove all of them. >>>>>> >>>>>> When the MemorySegment copyFrom(MemorySegment, MemoryLayout, >>>>>> ByteOrder) becomes available I can add the tests for that. >>>>>> >>>>>> *IMHO* >>>>>> >>>>>> I feel strongly that there is no need to additionally overload these >>>>>> methods with the segment offset specified in array index units. It is so >>>>>> trivial to convert from one to the other and it can be done easily in the >>>>>> method argument with a simple multiply by 2, 4 or 8. This should compile >>>>>> down to a simple shift, which becomes a single cycle CPU instruction. So >>>>>> this is not a performance issue. >>>>>> >>>>>> Furthermore, it is best that the user becomes accustomed to thinking >>>>>> of a segment fundamentally as an array of bytes. Once a segment is loaded >>>>>> with some primitive array, the segment loses the context of the type of the >>>>>> array it was loaded with; in effect, a kind of "type erasure" similar to >>>>>> Java's generics. This is one of the reasons that MemorySegments can be so >>>>>> powerful. >>>>>> >>>>>> >>>>>> I have been programming with the "MemorySegment" concept for a number >>>>>> of years now and find that keeping in mind that segments are just bytes is >>>>>> very useful. >>>>>> >>>>>> >>>>>> Let me know what you think. >>>>>> >>>>>> Lee. >>>>>> >>>>>> >>>>>> >>>>>> On Mon, May 31, 2021 at 6:56 AM Maurizio Cimadamore < >>>>>> maurizio.cimadamore at oracle.com> wrote: >>>>>> >>>>>>> Hi Lee, >>>>>>> this looks good. >>>>>>> >>>>>>> One thing I note is that there's an ambiguity as to whether the >>>>>>> segment index is expressed as a logical index, or a raw byte offset. Your >>>>>>> snippet does the latter. If we want to follow MemoryAccess, perhaps that >>>>>>> calls for 2 overloads (copyFromArrayAtIndex/copyFromArrayAtOffset), as I >>>>>>> imagine both could be useful, depending on the case? >>>>>>> >>>>>>> The javadoc will have to say something when the segment being used >>>>>>> is backed by the very array that is the source/target of the copy (we have >>>>>>> some text like that in MemorySegment::copyFrom). >>>>>>> >>>>>>> I think it would be helpful to progress further with this, add the >>>>>>> remaining templates (w/o ByteOrder, for now) test and see how it works in >>>>>>> practice. >>>>>>> >>>>>>> I will add (or just file a simple PR, so that you can just borrow >>>>>>> from it - should be a single method) something to do the segment copy with >>>>>>> swap. >>>>>>> >>>>>>> Thanks! >>>>>>> Maurizio >>>>>>> On 28/05/2021 22:37, leerho wrote: >>>>>>> >>>>>>> Maurizio, >>>>>>> >>>>>>> Again sorry about the delay. >>>>>>> >>>>>>> Attached is a template proposal for the MemoryCopy class. >>>>>>> >>>>>>> I can't complete this without your proposed new copyFrom(...) method >>>>>>> in MemorySegment. As it is written, it should work, but without the byte >>>>>>> swap capability. >>>>>>> >>>>>>> I can complete the rest of the primitives like this template, if you >>>>>>> would like with javadocs. I could also start writing tests, but without >>>>>>> the byte-swap. >>>>>>> >>>>>>> Let me know what would be most helpful. >>>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> Lee >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, May 20, 2021 at 11:36 AM leerho wrote: >>>>>>> >>>>>>>> Of course! >>>>>>>> >>>>>>>> On Thu, May 20, 2021 at 9:42 AM Maurizio Cimadamore < >>>>>>>> maurizio.cimadamore at oracle.com> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> On 20/05/2021 17:13, leerho wrote: >>>>>>>>> >>>>>>>>> I am not sure if the *dstSegSlice* requires the *srcCopyLen*. I >>>>>>>>> would hope that it is smart enough to realize that the input length is >>>>>>>>> smaller than the given offset minus the segment size. >>>>>>>>> >>>>>>>>> asSlice has an overload that just takes an offset and infers the >>>>>>>>> resulting size from there. >>>>>>>>> >>>>>>>>> But that doesn't seem what you want here - as you want the slice >>>>>>>>> to have a specific size (the size of the input array). >>>>>>>>> >>>>>>>>> MemorySegment::copyFrom wants the two segments to have the same >>>>>>>>> size, so I think you need that. >>>>>>>>> >>>>>>>>> In terms of performance, there's no difference between >>>>>>>>> asSlice(offset) and asSlice(offset, size) - you have to create a new >>>>>>>>> segment anyway. >>>>>>>>> >>>>>>>>> Maurizio >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>> From my cell phone. >>>>> >>>>> -- >>>> From my cell phone. >>>> >>> From xgong at openjdk.java.net Thu Jun 10 02:08:34 2021 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Thu, 10 Jun 2021 02:08:34 GMT Subject: [vectorIntrinsics+mask] RFR: 8268154: Add masking support for vector load intrinsics In-Reply-To: References: Message-ID: On Wed, 9 Jun 2021 22:20:55 GMT, Paul Sandoz wrote: >> This patch adds the predicate support for masked load vector operation, including the Vector API java implementation and hotspot intrinsics changes. The main changes contain: >> - Adding a new hotspot intrinsic method (`loadMasked`), which can transform the vector mask class and value to hotspot. It is called by the masked `"fromArray"` API in JAVA level. The compiler will generate the masked vector load node if the current platform supports the predicate feature and backend has implemented it. Otherwise, the vector blend pattern will be generated like before. >> - Adding the similar masked support for load/store boolean/char array. >> >> Note that the intrinsification when there is the array range bailout is not implemented in this patch. We are considering making it vectorized with predicate feature for SVE/AVX-512 as well, and will create a separate patch for it in future. >> >> Also note that this patch doesn't contain any backend changes. > > src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template line 4579: > >> 4577: a, arrayAddress(a, offset), m, >> 4578: a, offset, vsp, >> 4579: (arr, off, s, vm) -> s.ldOp(arr, off, (AbstractMask<$Boxtype$>) vm, > > We can avoid the cast to `AbstractMask<$Boxtype$>` if we update the signature of the species `ldOp` to be e.g on `IntVector`: > > IntVector ldOp(M memory, int offset, > VectorMask m, > FLdOp f) { > return dummyVector().ldOp(memory, offset, m, f); > } > > > In general i think we need to review the generic signatures here and in `VectorSupport`, as they are a bit inconsistent. Something to consider later. Thanks for looking at this PR @PaulSandoz ! This looks ok to me and will change it later. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/90 From xgong at openjdk.java.net Thu Jun 10 02:08:33 2021 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Thu, 10 Jun 2021 02:08:33 GMT Subject: [vectorIntrinsics+mask] RFR: 8268154: Add masking support for vector load intrinsics In-Reply-To: References: Message-ID: On Wed, 9 Jun 2021 12:07:08 GMT, Jatin Bhateja wrote: > Currently there following assertion check in both LoadVectorMaskedNode and StoreVectorMaskedNode > > `assert(mask->bottom_type()->is_vectmask(), "sanity");` > > This should be relaxed since mask argument will be VectorUnboxNode until macro expansion. > > I added following static routine in VectorNode class to get over it in my local sandbox, and adjusted the assertion to use it. If suitable maybe we can integrate it in this patch. > > ``` > bool VectorNode::is_vector_mask(Node* n) { > if (n->bottom_type()->is_vectmask()) { > return true; > } > if (n->Opcode() == Op_VectorUnbox) { > const TypeInstPtr* vector_klass_from = n->as_VectorUnbox()->obj()->bottom_type()->isa_instptr(); > ciKlass* vbox_klass_from = vector_klass_from->const_oop()->as_instance()->java_lang_Class_klass(); > return vbox_klass_from->is_subclass_of(ciEnv::current()->vector_VectorMask_klass()); > } > return false; > } > ``` Thanks so for your suggestion @jatin-bhateja ! This looks ok to me. So that I can also revert the type changes to VectorBox/VectorUnbox in PR https://github.com/openjdk/panama-vector/pull/78. > src/hotspot/share/opto/vectorIntrinsics.cpp line 956: > >> 954: bool use_predicate = Matcher::has_predicated_vectors() && >> 955: arch_supports_vector(sopc, num_elem, elem_bt, VecMaskUseLoad) && >> 956: Matcher::match_rule_supported_vector_masked(sopc, num_elem, elem_bt); > > Can we push both Matcher::has_predicated_vectors() && Matcher::match_rule_supported_vector_masked() into arch_supports_vector and either add an explicit bool argument to it or a new enum value to be passed i.e. VecMaskUseLoad | VecPredOper under which these checks are enforced. Good idea! Will do this later. Thanks so much! ------------- PR: https://git.openjdk.java.net/panama-vector/pull/90 From xgong at openjdk.java.net Thu Jun 10 06:46:21 2021 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Thu, 10 Jun 2021 06:46:21 GMT Subject: [vectorIntrinsics+mask] RFR: 8268154: Add masking support for vector load intrinsics In-Reply-To: References: Message-ID: On Mon, 7 Jun 2021 09:05:44 GMT, Xiaohong Gong wrote: > This patch adds the predicate support for masked load vector operation, including the Vector API java implementation and hotspot intrinsics changes. The main changes contain: > - Adding a new hotspot intrinsic method (`loadMasked`), which can transform the vector mask class and value to hotspot. It is called by the masked `"fromArray"` API in JAVA level. The compiler will generate the masked vector load node if the current platform supports the predicate feature and backend has implemented it. Otherwise, the vector blend pattern will be generated like before. > - Adding the similar masked support for load/store boolean/char array. > > Note that the intrinsification when there is the array range bailout is not implemented in this patch. We are considering making it vectorized with predicate feature for SVE/AVX-512 as well, and will create a separate patch for it in future. > > Also note that this patch doesn't contain any backend changes. > > Currently there following assertion check in both LoadVectorMaskedNode and StoreVectorMaskedNode > > `assert(mask->bottom_type()->is_vectmask(), "sanity");` > > This should be relaxed since mask argument will be VectorUnboxNode until macro expansion. > > I added following static routine in VectorNode class to get over it in my local sandbox, and adjusted the assertion to use it. If suitable maybe we can integrate it in this patch. > > ``` > > bool VectorNode::is_vector_mask(Node* n) { > > if (n->bottom_type()->is_vectmask()) { > > return true; > > } > > if (n->Opcode() == Op_VectorUnbox) { > > const TypeInstPtr* vector_klass_from = n->as_VectorUnbox()->obj()->bottom_type()->isa_instptr(); > > ciKlass* vbox_klass_from = vector_klass_from->const_oop()->as_instance()->java_lang_Class_klass(); > > return vbox_klass_from->is_subclass_of(ciEnv::current()->vector_VectorMask_klass()); > > } > > return false; > > } > > ``` > > Thanks so for your suggestion @jatin-bhateja ! This looks ok to me. So that I can also revert the type changes to VectorBox/VectorUnbox in PR #78. Regarding to merge it, do you think it's better to fix it in https://github.com/openjdk/panama-vector/pull/78 instead of this PR? One reason is that there are other mask IRs that also contains the same assertion, we can update them together. Another one is that I can revert the type changes for `VectorBox/VectorUnbox` and have a test together. Thanks! ------------- PR: https://git.openjdk.java.net/panama-vector/pull/90 From jiefu at openjdk.java.net Thu Jun 10 07:52:41 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Thu, 10 Jun 2021 07:52:41 GMT Subject: [vectorIntrinsics] RFR: 8267294: [vector] Fix unsigned comparison crashes on x86 CPUs with UseAVX=1 Message-ID: Hi all, While I was working on JDK-8267370, Ekaterina Pavlova told me some vector tests crashes in Oracle's CI/CD. According to the hs_err [1], these crashes just happened on a CPU which doesn't support avx2/3. So we can easily reproduce the crashes with `-XX:UseAVX=1` on modern x86 CPUs by running the following tests. jdk/incubator/vector/IntMaxVectorTests.java jdk/incubator/vector/Int128VectorTests.java jdk/incubator/vector/Short128VectorTests.java jdk/incubator/vector/ShortMaxVectorTests.java Let's fix it. Testing: - vector tests on Linux/x64 with UseAVX={3/2/1/0} Thanks. Best regards, Jie [1] https://bugs.openjdk.java.net/secure/attachment/94669/hs_err_bug8267294.log ------------- Commit messages: - 8267294: [vector] Fix unsigned comparison crashes on x86 CPUs with UseAVX=1 Changes: https://git.openjdk.java.net/panama-vector/pull/91/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=91&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267294 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/panama-vector/pull/91.diff Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/91/head:pull/91 PR: https://git.openjdk.java.net/panama-vector/pull/91 From maurizio.cimadamore at oracle.com Thu Jun 10 08:45:07 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 10 Jun 2021 09:45:07 +0100 Subject: Part 1 Proposal for JDK-8264594 In-Reply-To: References: <95c04a58-4897-0d49-3f13-d8aa6b293006@oracle.com> <87a484de-9cdc-ddc7-ff73-6dad2641d5a4@oracle.com> <0bd0724a-ce06-bb25-10a9-9f0641b359c1@oracle.com> <06429259-99bf-4043-d611-24aa6fb353bd@oracle.com> <8785fd57-baf3-cb86-e715-9f8f66c74684@oracle.com> Message-ID: <7ad1c1b1-bc64-ad32-2b5e-eceafae5a8ae@oracle.com> On 10/06/2021 00:02, leerho wrote: > // I think we discussed a while back that the asSlice would also > require a length. Minor correction - with the new API, I don't think you need a length. There is an overload of asSlice which just takes an offset, and recomputes the length automatically. So, if you use that, combined with the static method you provide, I think we should be good? copyIntoArrayLogical(segment.asSlice(srcOffsetBytes), 0, long[] dstArray, dstIndexLongs, dstCopyLengthLongs) Maurizio From njian at openjdk.java.net Thu Jun 10 09:40:36 2021 From: njian at openjdk.java.net (Ningsheng Jian) Date: Thu, 10 Jun 2021 09:40:36 GMT Subject: [vectorIntrinsics] RFR: 8267294: [vector] Fix unsigned comparison crashes on x86 CPUs with UseAVX=1 In-Reply-To: References: Message-ID: On Thu, 10 Jun 2021 07:47:49 GMT, Jie Fu wrote: > Hi all, > > While I was working on JDK-8267370, Ekaterina Pavlova told me some vector tests crashes in Oracle's CI/CD. > According to the hs_err [1], these crashes just happened on a CPU which doesn't support avx2/3. > > So we can easily reproduce the crashes with `-XX:UseAVX=1` on modern x86 CPUs by running the following tests. > > jdk/incubator/vector/IntMaxVectorTests.java > jdk/incubator/vector/Int128VectorTests.java > jdk/incubator/vector/Short128VectorTests.java > jdk/incubator/vector/ShortMaxVectorTests.java > > > Let's fix it. > > Testing: > - vector tests on Linux/x64 with UseAVX={3/2/1/0} > > Thanks. > Best regards, > Jie > > [1] https://bugs.openjdk.java.net/secure/attachment/94669/hs_err_bug8267294.log I think this has been fixed in https://github.com/openjdk/jdk/pull/3803? See: https://github.com/openjdk/jdk/pull/3803/commits/20a9c9cedee019936e3999332b4441671b3c8082 ------------- PR: https://git.openjdk.java.net/panama-vector/pull/91 From jiefu at openjdk.java.net Thu Jun 10 10:04:23 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Thu, 10 Jun 2021 10:04:23 GMT Subject: [vectorIntrinsics] Withdrawn: 8267294: [vector] Fix unsigned comparison crashes on x86 CPUs with UseAVX=1 In-Reply-To: References: Message-ID: On Thu, 10 Jun 2021 07:47:49 GMT, Jie Fu wrote: > Hi all, > > While I was working on JDK-8267370, Ekaterina Pavlova told me some vector tests crashes in Oracle's CI/CD. > According to the hs_err [1], these crashes just happened on a CPU which doesn't support avx2/3. > > So we can easily reproduce the crashes with `-XX:UseAVX=1` on modern x86 CPUs by running the following tests. > > jdk/incubator/vector/IntMaxVectorTests.java > jdk/incubator/vector/Int128VectorTests.java > jdk/incubator/vector/Short128VectorTests.java > jdk/incubator/vector/ShortMaxVectorTests.java > > > Let's fix it. > > Testing: > - vector tests on Linux/x64 with UseAVX={3/2/1/0} > > Thanks. > Best regards, > Jie > > [1] https://bugs.openjdk.java.net/secure/attachment/94669/hs_err_bug8267294.log This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/91 From jiefu at openjdk.java.net Thu Jun 10 10:04:22 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Thu, 10 Jun 2021 10:04:22 GMT Subject: [vectorIntrinsics] RFR: 8267294: [vector] Fix unsigned comparison crashes on x86 CPUs with UseAVX=1 In-Reply-To: References: Message-ID: On Thu, 10 Jun 2021 07:47:49 GMT, Jie Fu wrote: > Hi all, > > While I was working on JDK-8267370, Ekaterina Pavlova told me some vector tests crashes in Oracle's CI/CD. > According to the hs_err [1], these crashes just happened on a CPU which doesn't support avx2/3. > > So we can easily reproduce the crashes with `-XX:UseAVX=1` on modern x86 CPUs by running the following tests. > > jdk/incubator/vector/IntMaxVectorTests.java > jdk/incubator/vector/Int128VectorTests.java > jdk/incubator/vector/Short128VectorTests.java > jdk/incubator/vector/ShortMaxVectorTests.java > > > Let's fix it. > > Testing: > - vector tests on Linux/x64 with UseAVX={3/2/1/0} > > Thanks. > Best regards, > Jie > > [1] https://bugs.openjdk.java.net/secure/attachment/94669/hs_err_bug8267294.log > I think this has been fixed in [openjdk/jdk#3803](https://github.com/openjdk/jdk/pull/3803)? See: [openjdk/jdk at 20a9c9c](https://github.com/openjdk/jdk/commit/20a9c9cedee019936e3999332b4441671b3c8082) Ah, yes. Okay, it's a waste of time to do this. Just close it. Thanks. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/91 From xgong at openjdk.java.net Thu Jun 10 10:08:45 2021 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Thu, 10 Jun 2021 10:08:45 GMT Subject: [vectorIntrinsics+mask] RFR: 8268154: Add masking support for vector load intrinsics [v2] In-Reply-To: References: Message-ID: <6MR0hrjXXUadI1qjkjfeK9BYD6CaUaLXm1WdeZWxJI0=.5c6827a5-c1d0-4b07-926e-614e634f98ac@github.com> On Wed, 9 Jun 2021 22:24:27 GMT, Paul Sandoz wrote: >> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision: >> >> Address review comments > > Java changes look good. No need for me to re-review to resolve the comment i made. Hi @PaulSandoz @jatin-bhateja , the latest commit have addressed your comments. Thanks! ------------- PR: https://git.openjdk.java.net/panama-vector/pull/90 From xgong at openjdk.java.net Thu Jun 10 10:08:45 2021 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Thu, 10 Jun 2021 10:08:45 GMT Subject: [vectorIntrinsics+mask] RFR: 8268154: Add masking support for vector load intrinsics [v2] In-Reply-To: References: Message-ID: > This patch adds the predicate support for masked load vector operation, including the Vector API java implementation and hotspot intrinsics changes. The main changes contain: > - Adding a new hotspot intrinsic method (`loadMasked`), which can transform the vector mask class and value to hotspot. It is called by the masked `"fromArray"` API in JAVA level. The compiler will generate the masked vector load node if the current platform supports the predicate feature and backend has implemented it. Otherwise, the vector blend pattern will be generated like before. > - Adding the similar masked support for load/store boolean/char array. > > Note that the intrinsification when there is the array range bailout is not implemented in this patch. We are considering making it vectorized with predicate feature for SVE/AVX-512 as well, and will create a separate patch for it in future. > > Also note that this patch doesn't contain any backend changes. Xiaohong Gong 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-vector/pull/90/files - new: https://git.openjdk.java.net/panama-vector/pull/90/files/106585f6..0b77c8e3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=90&range=01 - incr: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=90&range=00-01 Stats: 62 lines in 9 files changed: 24 ins; 10 del; 28 mod Patch: https://git.openjdk.java.net/panama-vector/pull/90.diff Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/90/head:pull/90 PR: https://git.openjdk.java.net/panama-vector/pull/90 From jvernee at openjdk.java.net Thu Jun 10 12:12:46 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 10 Jun 2021 12:12:46 GMT Subject: [foreign-memaccess+abi] RFR: 8268230: Foreign Linker API & Windows user32/kernel32: String conversion seems broken Message-ID: <0ZOia1B8PO-j284cRHT3_oVVMyWqCBUJT4emLo3BxZQ=.7b226aa8-d1c9-4a08-9910-18deb4ef0a24@github.com> The problem is that we only add a single 0 byte as a null terminator, regardless of the charset used. For wider char sets, more 0 bytes need to be added. For instance, for UTF_16LE two 0 bytes need to be added. This patch fixes the issue by adding the null terminator to the Java string, and only then encoding it as a `byte[]`. ------------- Commit messages: - Fix toCString for wider character sets Changes: https://git.openjdk.java.net/panama-foreign/pull/554/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=554&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268230 Stats: 85 lines in 2 files changed: 75 ins; 6 del; 4 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/554.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/554/head:pull/554 PR: https://git.openjdk.java.net/panama-foreign/pull/554 From mcimadamore at openjdk.java.net Thu Jun 10 12:36:31 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 10 Jun 2021 12:36:31 GMT Subject: [foreign-memaccess+abi] RFR: 8268230: Foreign Linker API & Windows user32/kernel32: String conversion seems broken In-Reply-To: <0ZOia1B8PO-j284cRHT3_oVVMyWqCBUJT4emLo3BxZQ=.7b226aa8-d1c9-4a08-9910-18deb4ef0a24@github.com> References: <0ZOia1B8PO-j284cRHT3_oVVMyWqCBUJT4emLo3BxZQ=.7b226aa8-d1c9-4a08-9910-18deb4ef0a24@github.com> Message-ID: On Thu, 10 Jun 2021 12:03:59 GMT, Jorn Vernee wrote: > The problem is that we only add a single 0 byte as a null terminator, regardless of the charset used. For wider char sets, more 0 bytes need to be added. For instance, for UTF_16LE two 0 bytes need to be added. > > This patch fixes the issue by adding the null terminator to the Java string, and only then encoding it as a `byte[]`. Good catch - I think the fix can be made slightly more efficient src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java line 302: > 300: } > 301: > 302: private static String addNullTerminator(String str) { This is gonna allocate another string in an already allocation-heavy code. Wouldn't it be better to just add the correct termination sequence in the segment? I suggest running StrLen benchmark before/after to make sure string conversion performance isn't negatively impacted. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/554 From jvernee at openjdk.java.net Thu Jun 10 13:16:32 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 10 Jun 2021 13:16:32 GMT Subject: [foreign-memaccess+abi] RFR: 8268230: Foreign Linker API & Windows user32/kernel32: String conversion seems broken In-Reply-To: References: <0ZOia1B8PO-j284cRHT3_oVVMyWqCBUJT4emLo3BxZQ=.7b226aa8-d1c9-4a08-9910-18deb4ef0a24@github.com> Message-ID: <5RrPoRBx52nGq66WRyt1ZQIQMeVWBuPs9miMYHt58jM=.03d429c9-4eae-4beb-9a2b-06bd947c8329@github.com> On Thu, 10 Jun 2021 12:33:23 GMT, Maurizio Cimadamore wrote: >> The problem is that we only add a single 0 byte as a null terminator, regardless of the charset used. For wider char sets, more 0 bytes need to be added. For instance, for UTF_16LE two 0 bytes need to be added. >> >> This patch fixes the issue by adding the null terminator to the Java string, and only then encoding it as a `byte[]`. > > src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java line 302: > >> 300: } >> 301: >> 302: private static String addNullTerminator(String str) { > > This is gonna allocate another string in an already allocation-heavy code. Wouldn't it be better to just add the correct termination sequence in the segment? I suggest running StrLen benchmark before/after to make sure string conversion performance isn't negatively impacted. I'll check the benchmark. I looked at the CharSet API, and AFAICS the only way to get the number of bytes for the null terminator would be to create a String with the value `"\0"` then encode that and check the resulting `byte[]`. I thought going the string concat route would have better chances of being optimized. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/554 From jvernee at openjdk.java.net Thu Jun 10 14:16:12 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 10 Jun 2021 14:16:12 GMT Subject: [foreign-memaccess+abi] RFR: 8268230: Foreign Linker API & Windows user32/kernel32: String conversion seems broken In-Reply-To: <5RrPoRBx52nGq66WRyt1ZQIQMeVWBuPs9miMYHt58jM=.03d429c9-4eae-4beb-9a2b-06bd947c8329@github.com> References: <0ZOia1B8PO-j284cRHT3_oVVMyWqCBUJT4emLo3BxZQ=.7b226aa8-d1c9-4a08-9910-18deb4ef0a24@github.com> <5RrPoRBx52nGq66WRyt1ZQIQMeVWBuPs9miMYHt58jM=.03d429c9-4eae-4beb-9a2b-06bd947c8329@github.com> Message-ID: On Thu, 10 Jun 2021 13:13:09 GMT, Jorn Vernee wrote: >> src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java line 302: >> >>> 300: } >>> 301: >>> 302: private static String addNullTerminator(String str) { >> >> This is gonna allocate another string in an already allocation-heavy code. Wouldn't it be better to just add the correct termination sequence in the segment? I suggest running StrLen benchmark before/after to make sure string conversion performance isn't negatively impacted. > > I'll check the benchmark. > > I looked at the CharSet API, and AFAICS the only way to get the number of bytes for the null terminator would be to create a String with the value `"\0"` then encode that and check the resulting `byte[]`. I thought going the string concat route would have better chances of being optimized. The benchmark results are as follows: Before: Benchmark (size) Mode Cnt Score Error Units StrLenTest.panama_strlen_prefix 5 avgt 30 124.874 ? 15.751 ns/op StrLenTest.panama_strlen_prefix 20 avgt 30 131.683 ? 6.011 ns/op StrLenTest.panama_strlen_prefix 100 avgt 30 161.046 ? 10.580 ns/op After: Benchmark (size) Mode Cnt Score Error Units StrLenTest.panama_strlen_prefix 5 avgt 30 130.758 ? 5.691 ns/op StrLenTest.panama_strlen_prefix 20 avgt 30 145.012 ? 6.804 ns/op StrLenTest.panama_strlen_prefix 100 avgt 30 179.992 ? 6.457 ns/op I think C2 should be able to eliminate the intermediate string, but there's still a slight regression. > Wouldn't it be better to just add the correct termination sequence in the segment? The problem is finding out how many bytes to add. Looking at Charset again, there really doesn't seem to be a way to get the number of bytes per character. The closest seems to be `charset.newEncoder().averageBytesPerChar()`, which I'm not sure is what we want. I'll ask around as well. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/554 From maurizio.cimadamore at oracle.com Thu Jun 10 14:28:08 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 10 Jun 2021 15:28:08 +0100 Subject: RFC: static bulk copy methods In-Reply-To: <7ad1c1b1-bc64-ad32-2b5e-eceafae5a8ae@oracle.com> References: <95c04a58-4897-0d49-3f13-d8aa6b293006@oracle.com> <87a484de-9cdc-ddc7-ff73-6dad2641d5a4@oracle.com> <0bd0724a-ce06-bb25-10a9-9f0641b359c1@oracle.com> <06429259-99bf-4043-d611-24aa6fb353bd@oracle.com> <8785fd57-baf3-cb86-e715-9f8f66c74684@oracle.com> <7ad1c1b1-bc64-ad32-2b5e-eceafae5a8ae@oracle.com> Message-ID: Hi I've create a draft PR which adds the new MemorySegment method to do the bulk copy (with swap if needed), plus the code that Lee posted in this thread [1]: https://github.com/openjdk/panama-foreign/pull/555 There are a couple of points which deserve a discussion. First, array indices are always expressed as logical indices (e.g. to access the second long in a long[], we use "1", not "16"). This creates some tension when adding the static methods for doing the bulk copy between arrays and segments, as the more natural index to be used with a segment is not a logical index, but just a raw byte offset. In this PR the static methods in MemoryCopy simply accept logical indices for arrays and raw offsets for segments, w/o any further attempt to reconcile the mismatch. In a separate thread [2] we have discussed few options to ameliorate the situation, should this become an issue in real code. Second, to do a "swappy" bulk copy we need to know the size of the elements we're copying. That's because the byte swap will be applied on a per-element basis (of course). There are several options to provide such an API in MemorySegment, listed below: ``` MemorySegment.copyFrom(MemorySegment src, int elemSize, boolean swap) // 1 MemorySegment.copyFrom(MemorySegment src, ValueLayout elemLayout, ByteOrder order) // 2 MemorySegment.copyFrom(MemorySegment src, ValueLayout srcElementLayout, ValueLayout dstElementLayout) // 3 ``` The first is merely a wrapper around unsafe. It's a good fallback, but seems very low level, even for our API; specifically, it seems we could do something to avoid that "swap" parameter. The second option takes a step towards layouts - e.g. if we model elements with a layout, then we can compare the endianness of the layout with the provided order. What I find confusing about this API is that it's not clear to which segment (source or target) does the layout or order arguments apply to. The third option fully embrace layouts and is what is implemented in the PR. We now have a layout for the source elements, and a layout for the destination elements. If their order is different a byte swap occurs. The simpler one-argument copyFrom can be expressed as: ``` copyFrom(src) == copyFrom(src, JAVA_BYTE, JAVA_BYTE) ``` To perform a swappy copy between short elements, a client would probably do: ``` copyFrom(src, BITS_16_LE, BITS_16_BE) ``` The method will also check alignment constraints in the source and target segments, so if clients want to use this enhanced copyFrom to copy elements at unaligned addresses, the alignment constraints should be removed from the target layout: ``` copyFrom(src, BITS_16_LE, BITS_16_BE.withBitAlignment(8)) ``` This check adds extra safety belts, and does not affect expressiveness, since we can always create "unaligned" layouts to bulk copy at arbitrary addresses --- and I imagine that the routines in MemoryCopy will want to do something along these lines. Comments welcome. Maurizio [1] - https://mail.openjdk.java.net/pipermail/panama-dev/2021-April/013518.html [2] - https://mail.openjdk.java.net/pipermail/panama-dev/2021-June/014047.html From leerho at gmail.com Thu Jun 10 16:33:27 2021 From: leerho at gmail.com (leerho) Date: Thu, 10 Jun 2021 09:33:27 -0700 Subject: Part 1 Proposal for JDK-8264594 In-Reply-To: <7ad1c1b1-bc64-ad32-2b5e-eceafae5a8ae@oracle.com> References: <95c04a58-4897-0d49-3f13-d8aa6b293006@oracle.com> <87a484de-9cdc-ddc7-ff73-6dad2641d5a4@oracle.com> <0bd0724a-ce06-bb25-10a9-9f0641b359c1@oracle.com> <06429259-99bf-4043-d611-24aa6fb353bd@oracle.com> <8785fd57-baf3-cb86-e715-9f8f66c74684@oracle.com> <7ad1c1b1-bc64-ad32-2b5e-eceafae5a8ae@oracle.com> Message-ID: Also, to make the comparison more fair, we should add the user ability to compute the logical offset for option 1. Restating the options: 1. copyIntoArrayRaw(segment, srcOffsetBytes, long[] dstArray, dstIndexLongs, dstCopyLengthLongs) //For the "Logical" case, user has the option to write: copyIntoArrayRaw(segment, srcOffsetLongs * 8L, long[] dstArray, dstIndexLongs, dstCopyLengthLongs) 2. copyIntoArrayRaw(segment, srcOffsetBytes, long[] dstArray, dstIndexLongs, dstCopyLengthLongs) And copyIntoArrayLogical(segment, srcOffsetLongs, long[] dstArray, dstIndexLongs, dstCopyLengthLongs) 3. copyIntoArrayLogical(segment, srcOffsetLongs, long[] dstArray, dstIndexLongs, dstCopyLengthLongs) //For the "Raw" case, user has the option to write a compound statement like: copyIntoArrayLogical(segment.asSlice(srcOffsetBytes), 0, long[] dstArray, dstIndexLongs, dstCopyLengthLongs) Lee. On Thu, Jun 10, 2021 at 1:45 AM Maurizio Cimadamore < maurizio.cimadamore at oracle.com> wrote: > > On 10/06/2021 00:02, leerho wrote: > > // I think we discussed a while back that the asSlice would also > > require a length. > > Minor correction - with the new API, I don't think you need a length. > > There is an overload of asSlice which just takes an offset, and > recomputes the length automatically. > > So, if you use that, combined with the static method you provide, I > think we should be good? > > copyIntoArrayLogical(segment.asSlice(srcOffsetBytes), 0, long[] > dstArray, dstIndexLongs, dstCopyLengthLongs) > > Maurizio > > From leerho at gmail.com Thu Jun 10 17:12:57 2021 From: leerho at gmail.com (leerho) Date: Thu, 10 Jun 2021 10:12:57 -0700 Subject: Part 1 Proposal for JDK-8264594 In-Reply-To: References: <95c04a58-4897-0d49-3f13-d8aa6b293006@oracle.com> <87a484de-9cdc-ddc7-ff73-6dad2641d5a4@oracle.com> <0bd0724a-ce06-bb25-10a9-9f0641b359c1@oracle.com> <06429259-99bf-4043-d611-24aa6fb353bd@oracle.com> <8785fd57-baf3-cb86-e715-9f8f66c74684@oracle.com> <7ad1c1b1-bc64-ad32-2b5e-eceafae5a8ae@oracle.com> Message-ID: Maurizio, Now that you have submitted the draft PR ( https://github.com/openjdk/panama-foreign/pull/555), should I make the changes necessary to the MemoryCopy class to call the *MemorySegment.copyFrom(MemorySegment src, ValueLayout srcElementLayout,* *ValueLayout dstElementLayout)* implemented in the PR? -- Or should I wait until it is at least in a branch? Also, as I mentioned earlier, the TestMemoryCopy will have to be rewritten to also test the byte swaps. (and fix some of the extra space errors found ). I will have to relay these changes through you as I don't have permission to submit changes directly. Lee. On Thu, Jun 10, 2021 at 9:33 AM leerho wrote: > Also, to make the comparison more fair, we should add the user ability to > compute the logical offset for option 1. > Restating the options: > > 1. copyIntoArrayRaw(segment, srcOffsetBytes, long[] dstArray, > dstIndexLongs, dstCopyLengthLongs) > //For the "Logical" case, user has the option to write: > copyIntoArrayRaw(segment, srcOffsetLongs * 8L, long[] dstArray, > dstIndexLongs, dstCopyLengthLongs) > > 2. copyIntoArrayRaw(segment, srcOffsetBytes, long[] dstArray, > dstIndexLongs, dstCopyLengthLongs) > And > copyIntoArrayLogical(segment, srcOffsetLongs, long[] dstArray, > dstIndexLongs, dstCopyLengthLongs) > > 3. copyIntoArrayLogical(segment, srcOffsetLongs, long[] dstArray, > dstIndexLongs, dstCopyLengthLongs) > //For the "Raw" case, user has the option to write a compound > statement like: > copyIntoArrayLogical(segment.asSlice(srcOffsetBytes), 0, long[] > dstArray, dstIndexLongs, dstCopyLengthLongs) > > Lee. > > On Thu, Jun 10, 2021 at 1:45 AM Maurizio Cimadamore < > maurizio.cimadamore at oracle.com> wrote: > >> >> On 10/06/2021 00:02, leerho wrote: >> > // I think we discussed a while back that the asSlice would also >> > require a length. >> >> Minor correction - with the new API, I don't think you need a length. >> >> There is an overload of asSlice which just takes an offset, and >> recomputes the length automatically. >> >> So, if you use that, combined with the static method you provide, I >> think we should be good? >> >> copyIntoArrayLogical(segment.asSlice(srcOffsetBytes), 0, long[] >> dstArray, dstIndexLongs, dstCopyLengthLongs) >> >> Maurizio >> >> From maurizio.cimadamore at oracle.com Thu Jun 10 17:28:32 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 10 Jun 2021 18:28:32 +0100 Subject: Part 1 Proposal for JDK-8264594 In-Reply-To: References: <95c04a58-4897-0d49-3f13-d8aa6b293006@oracle.com> <87a484de-9cdc-ddc7-ff73-6dad2641d5a4@oracle.com> <0bd0724a-ce06-bb25-10a9-9f0641b359c1@oracle.com> <06429259-99bf-4043-d611-24aa6fb353bd@oracle.com> <8785fd57-baf3-cb86-e715-9f8f66c74684@oracle.com> <7ad1c1b1-bc64-ad32-2b5e-eceafae5a8ae@oracle.com> Message-ID: <78f0c378-bbca-8e5a-e4bd-98528070d86c@oracle.com> On 10/06/2021 18:12, leerho wrote: > Maurizio, > Now that you have submitted the draft PR > (https://github.com/openjdk/panama-foreign/pull/555 > ), > should I make the changes necessary to the MemoryCopy class to call > the /MemorySegment.copyFrom(MemorySegment src, ValueLayout > srcElementLayout,/ > /ValueLayout dstElementLayout)/?implemented in the PR?? ?-- Or should > I wait until it is at least in a branch? You can go ahead and work on the changes. I will update the PR accordingly. > > Also, as I mentioned earlier, the TestMemoryCopy will have to be > rewritten to also test the byte swaps.? (and fix some of the extra > space errors found ). Ok > > I will have to relay these changes through you as I don't have > permission to submit changes directly. That's absolutely fine, no worries - as long as everything is visible on this list :-) Thanks Maurizio > > Lee. > > > > On Thu, Jun 10, 2021 at 9:33 AM leerho > wrote: > > Also, to make the comparison more fair, we should add the user > ability to compute the logical offset for option 1. > Restating the options: > > 1. copyIntoArrayRaw(segment, srcOffsetBytes, long[] dstArray, > dstIndexLongs, dstCopyLengthLongs) > //For the "Logical" case, user has the option to write: > copyIntoArrayRaw(segment, srcOffsetLongs * 8L, long[] > dstArray, dstIndexLongs, dstCopyLengthLongs) > > 2. copyIntoArrayRaw(segment, srcOffsetBytes, long[] dstArray, > dstIndexLongs, dstCopyLengthLongs) > And > copyIntoArrayLogical(segment, srcOffsetLongs, long[] dstArray, > dstIndexLongs, dstCopyLengthLongs) > > 3. copyIntoArrayLogical(segment, srcOffsetLongs, long[] dstArray, > dstIndexLongs, dstCopyLengthLongs) > //For the "Raw" case, user has the option to write a compound > statement like: > copyIntoArrayLogical(segment.asSlice(srcOffsetBytes), 0, > long[] dstArray, dstIndexLongs, dstCopyLengthLongs) > > Lee. > > On Thu, Jun 10, 2021 at 1:45 AM Maurizio Cimadamore > > wrote: > > > On 10/06/2021 00:02, leerho wrote: > > // I think we discussed a while back that the asSlice would > also > > require a length. > > Minor correction - with the new API, I don't think you need a > length. > > There is an overload of asSlice which just takes an offset, and > recomputes the length automatically. > > So, if you use that, combined with the static method you > provide, I > think we should be good? > > copyIntoArrayLogical(segment.asSlice(srcOffsetBytes), 0, long[] > dstArray, dstIndexLongs, dstCopyLengthLongs) > > Maurizio > From leerho at gmail.com Thu Jun 10 17:35:55 2021 From: leerho at gmail.com (leerho) Date: Thu, 10 Jun 2021 10:35:55 -0700 Subject: Part 1 Proposal for JDK-8264594 In-Reply-To: <78f0c378-bbca-8e5a-e4bd-98528070d86c@oracle.com> References: <95c04a58-4897-0d49-3f13-d8aa6b293006@oracle.com> <87a484de-9cdc-ddc7-ff73-6dad2641d5a4@oracle.com> <0bd0724a-ce06-bb25-10a9-9f0641b359c1@oracle.com> <06429259-99bf-4043-d611-24aa6fb353bd@oracle.com> <8785fd57-baf3-cb86-e715-9f8f66c74684@oracle.com> <7ad1c1b1-bc64-ad32-2b5e-eceafae5a8ae@oracle.com> <78f0c378-bbca-8e5a-e4bd-98528070d86c@oracle.com> Message-ID: I am wondering what would be easiest for you: to submit code via email as I have been doing, or create a branch in my public GitHub account with the changes: https://github.com/leerho/panama-foreign. Lee. On Thu, Jun 10, 2021 at 10:28 AM Maurizio Cimadamore < maurizio.cimadamore at oracle.com> wrote: > > On 10/06/2021 18:12, leerho wrote: > > Maurizio, > Now that you have submitted the draft PR ( > https://github.com/openjdk/panama-foreign/pull/555 > ), > should I make the changes necessary to the MemoryCopy class to call the *MemorySegment.copyFrom(MemorySegment > src, ValueLayout srcElementLayout,* > *ValueLayout dstElementLayout)* implemented in the PR? -- Or should I > wait until it is at least in a branch? > > You can go ahead and work on the changes. I will update the PR accordingly. > > > Also, as I mentioned earlier, the TestMemoryCopy will have to be rewritten > to also test the byte swaps. (and fix some of the extra space errors found > ). > > Ok > > > I will have to relay these changes through you as I don't have permission > to submit changes directly. > > That's absolutely fine, no worries - as long as everything is visible on > this list :-) > > Thanks > Maurizio > > > Lee. > > > > On Thu, Jun 10, 2021 at 9:33 AM leerho wrote: > >> Also, to make the comparison more fair, we should add the user ability to >> compute the logical offset for option 1. >> Restating the options: >> >> 1. copyIntoArrayRaw(segment, srcOffsetBytes, long[] dstArray, >> dstIndexLongs, dstCopyLengthLongs) >> //For the "Logical" case, user has the option to write: >> copyIntoArrayRaw(segment, srcOffsetLongs * 8L, long[] dstArray, >> dstIndexLongs, dstCopyLengthLongs) >> >> 2. copyIntoArrayRaw(segment, srcOffsetBytes, long[] dstArray, >> dstIndexLongs, dstCopyLengthLongs) >> And >> copyIntoArrayLogical(segment, srcOffsetLongs, long[] dstArray, >> dstIndexLongs, dstCopyLengthLongs) >> >> 3. copyIntoArrayLogical(segment, srcOffsetLongs, long[] dstArray, >> dstIndexLongs, dstCopyLengthLongs) >> //For the "Raw" case, user has the option to write a compound >> statement like: >> copyIntoArrayLogical(segment.asSlice(srcOffsetBytes), 0, long[] >> dstArray, dstIndexLongs, dstCopyLengthLongs) >> >> Lee. >> >> On Thu, Jun 10, 2021 at 1:45 AM Maurizio Cimadamore < >> maurizio.cimadamore at oracle.com> wrote: >> >>> >>> On 10/06/2021 00:02, leerho wrote: >>> > // I think we discussed a while back that the asSlice would also >>> > require a length. >>> >>> Minor correction - with the new API, I don't think you need a length. >>> >>> There is an overload of asSlice which just takes an offset, and >>> recomputes the length automatically. >>> >>> So, if you use that, combined with the static method you provide, I >>> think we should be good? >>> >>> copyIntoArrayLogical(segment.asSlice(srcOffsetBytes), 0, long[] >>> dstArray, dstIndexLongs, dstCopyLengthLongs) >>> >>> Maurizio >>> >>> From mgkwill at openjdk.java.net Thu Jun 10 17:54:33 2021 From: mgkwill at openjdk.java.net (Marcus G K Williams) Date: Thu, 10 Jun 2021 17:54:33 GMT Subject: [vectorIntrinsics] RFR: 8244490: [vector] Move Vector API micro benchmarks under test/micro [v6] In-Reply-To: References: Message-ID: > Vector API micro benchmarks are currently located under test/jdk/jdk/incubator/vector/benchmark which makes them rather as "dead" code without possibility to built and run. > > The proper location for micro benchmarks is actually test/micro/ directory. > It would be nice to move Vector API benchmarks there so they can be built automatically as part 'test-image' make target. > Once they are built they can be run as > make run-test TEST=micro:BENCHMARK_TEST_NAME Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision: PaulSandoz review Signed-off-by: Marcus G K Williams ------------- Changes: - all: https://git.openjdk.java.net/panama-vector/pull/77/files - new: https://git.openjdk.java.net/panama-vector/pull/77/files/682982d0..a2c7ed8a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=77&range=05 - incr: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=77&range=04-05 Stats: 68 lines in 46 files changed: 18 ins; 0 del; 50 mod Patch: https://git.openjdk.java.net/panama-vector/pull/77.diff Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/77/head:pull/77 PR: https://git.openjdk.java.net/panama-vector/pull/77 From mgkwill at openjdk.java.net Thu Jun 10 17:54:38 2021 From: mgkwill at openjdk.java.net (Marcus G K Williams) Date: Thu, 10 Jun 2021 17:54:38 GMT Subject: [vectorIntrinsics] RFR: 8244490: [vector] Move Vector API micro benchmarks under test/micro [v5] In-Reply-To: References: <0Ei6kGZe2NcaaRvnVYYUfgqBo_wDV4B_xwFeWV0z5Ng=.1c02ee00-0d15-427f-885b-4979e82a3f86@github.com> Message-ID: On Wed, 9 Jun 2021 17:01:57 GMT, Paul Sandoz wrote: >> Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision: >> >> Standardize copyright header, add 2021 >> >> Signed-off-by: Marcus G K Williams > > test/jdk/jdk/incubator/vector/templates/Perf-Scalar-header.template line 2: > >> 1: /* >> 2: * Copyright (c) 2018, 2020, 2021, Oracle and/or its affiliates. All rights reserved. > > Suggestion: > > * Copyright (c) 2018, 2021, Oracle and/or its affiliates. All rights reserved. > > > We just use one year or the range. Hopefully not too tedious to change with a global search and replace. No worries. Done. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/77 From mgkwill at openjdk.java.net Thu Jun 10 17:55:22 2021 From: mgkwill at openjdk.java.net (Marcus G K Williams) Date: Thu, 10 Jun 2021 17:55:22 GMT Subject: [vectorIntrinsics] RFR: 8244490: [vector] Move Vector API micro benchmarks under test/micro [v5] In-Reply-To: References: <0Ei6kGZe2NcaaRvnVYYUfgqBo_wDV4B_xwFeWV0z5Ng=.1c02ee00-0d15-427f-885b-4979e82a3f86@github.com> Message-ID: <0XG21FfJT5CoA6QdIGVb5reMY4mBnqkbdX0LTLDWWzo=.5ecfb468-7cda-430a-8504-67c10f752694@github.com> On Wed, 9 Jun 2021 17:13:58 GMT, Paul Sandoz wrote: > Thank you. Looks good. Just fix the license headers before integrating. > > Now we have the benchmarks integrated into the build system we can consider what it means to "curate". > Agreed. Perhaps a conversation for the mailing list. > I am wondering if we should package the vector benchmarks as a separate jar to the other benchmarks. It might sound strange to say that given they were separate to begin with! but they were not integrated with the build system. That likely requires changes to the build system and discussion with the maintainers of the build system. We can start that conversation after integration. > +1 > We can follow up with the `DecodeBench.java` issue after integration. +1 ------------- PR: https://git.openjdk.java.net/panama-vector/pull/77 From mgkwill at openjdk.java.net Thu Jun 10 18:09:17 2021 From: mgkwill at openjdk.java.net (Marcus G K Williams) Date: Thu, 10 Jun 2021 18:09:17 GMT Subject: [vectorIntrinsics] Integrated: 8244490: [vector] Move Vector API micro benchmarks under test/micro In-Reply-To: References: Message-ID: On Mon, 3 May 2021 20:52:50 GMT, Marcus G K Williams wrote: > Vector API micro benchmarks are currently located under test/jdk/jdk/incubator/vector/benchmark which makes them rather as "dead" code without possibility to built and run. > > The proper location for micro benchmarks is actually test/micro/ directory. > It would be nice to move Vector API benchmarks there so they can be built automatically as part 'test-image' make target. > Once they are built they can be run as > make run-test TEST=micro:BENCHMARK_TEST_NAME This pull request has now been integrated. Changeset: 86a8d382 Author: Marcus G K Williams Committer: Paul Sandoz URL: https://git.openjdk.java.net/panama-vector/commit/86a8d382758915aa2ef44cfff8902b2f3dea0d7e Stats: 352 lines in 54 files changed: 28 ins; 198 del; 126 mod 8244490: [vector] Move Vector API micro benchmarks under test/micro Reviewed-by: psandoz ------------- PR: https://git.openjdk.java.net/panama-vector/pull/77 From john.r.rose at oracle.com Thu Jun 10 18:10:16 2021 From: john.r.rose at oracle.com (John Rose) Date: Thu, 10 Jun 2021 18:10:16 +0000 Subject: RFC: static bulk copy methods In-Reply-To: References: <95c04a58-4897-0d49-3f13-d8aa6b293006@oracle.com> <87a484de-9cdc-ddc7-ff73-6dad2641d5a4@oracle.com> <0bd0724a-ce06-bb25-10a9-9f0641b359c1@oracle.com> <06429259-99bf-4043-d611-24aa6fb353bd@oracle.com> <8785fd57-baf3-cb86-e715-9f8f66c74684@oracle.com> <7ad1c1b1-bc64-ad32-2b5e-eceafae5a8ae@oracle.com> Message-ID: <96881B59-E6A4-4B96-A797-97CAB16AB4F3@oracle.com> On Jun 10, 2021, at 7:28 AM, Maurizio Cimadamore > wrote: ``` MemorySegment.copyFrom(MemorySegment src, int elemSize, boolean swap) // 1 MemorySegment.copyFrom(MemorySegment src, ValueLayout elemLayout, ByteOrder order) // 2 MemorySegment.copyFrom(MemorySegment src, ValueLayout srcElementLayout, ValueLayout dstElementLayout) // 3 ``` The first is merely a wrapper around unsafe. It's a good fallback, but seems very low level, even for our API; specifically, it seems we could do something to avoid that "swap" parameter. Just to state the obvious: ?swap? parameters all by themselves are dangerous because they pertain to the operation but are not derived directly from the source alone or the destination alone, but rather from an XOR of properties of the source and destination. But when reading code a maintainer will usually mentally assign the swap to either the source or destination. This leads to maintenance problems in larger systems where chains of copies, each with its own swap parameter, are ?fixed? by flipping a coin (in effect) and complementing one of the swap parameters, hoping for success. It sounds silly, but that?s how byte-order bugs get fixed, if the copy operations are gated by swap booleans, rather than by properties of the data chunks being copies. We chased swap bugs in HotSpot like this, across various modules written by people with different mental models of byte order, literally for years back in the day. I suspect there is still a latent bug or two, masked by ?tweaks? that put the right (odd or even) number of swap operations in each chain that actually executes. The road to sanity is through the option where both source and destination get to declare their ?polarity? and the actual operation just XORs those polarities on the fly. That?s my take, based on painful memories! ? John P.S. While I prefer #3, I find it odd that the two ?polarity? descriptors are bundled together at the end of the argument list, and *in the reverse order* of the main arguments they describe. That seems to be a different kind of bug-attractor, since it?s hard to see in the code if the order has been reversed. I like to break up such ?dancing pairs? of similar arguments if I can. Maybe: MemorySegment.copyWithLayoutsFrom(ValueLayout dstElementLayout, MemorySegment src, ValueLayout srcElementLayout) From jvernee at openjdk.java.net Thu Jun 10 18:55:37 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 10 Jun 2021 18:55:37 GMT Subject: [foreign-memaccess+abi] RFR: 8268266: Investigate way to lazily customize upcall lambda forms Message-ID: Hi, This patch makes upcall method handle customization lazy, which helps a lot in reducing the number of lambda form classes generated during for intstance the TestUpcall test, making it complete a lot faster. This adds a very slight overhead per call, since there's another indirection, but I think the tradeoff is acceptable. Since the patch was otherwise really small, this also adds a qsort benchmark that is also used the measure the cost of the extra indirection. Results are as follows: QSort without lazy customization: Benchmark Mode Cnt Score Error Units QSort.jni_upcall_qsort_naive avgt 30 21096.871 ? 299.669 ns/op QSort.jni_upcall_qsort_optimized avgt 30 3603.495 ? 16.464 ns/op QSort.native_qsort avgt 30 96.236 ? 0.713 ns/op QSort.panama_upcall_qsort avgt 30 937.675 ? 26.160 ns/op QSort with lazy customization: Benchmark Mode Cnt Score Error Units QSort.jni_upcall_qsort_naive avgt 30 21454.476 ? 306.135 ns/op QSort.jni_upcall_qsort_optimized avgt 30 3691.395 ? 35.671 ns/op QSort.native_qsort avgt 30 97.440 ? 0.894 ns/op QSort.panama_upcall_qsort avgt 30 1072.929 ? 14.948 ns/op So, while there is some regression from this change, it's not super bad (not integer factor), and I think the tradeoff is worth it to generate fewer lambda form classes, which of course has it's own overhead not visible in this benchmark. Thanks, Jorn ------------- Commit messages: - Add QSort benchmark - Lazily customize upcall method handles Changes: https://git.openjdk.java.net/panama-foreign/pull/553/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=553&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268266 Stats: 446 lines in 11 files changed: 387 ins; 52 del; 7 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/553.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/553/head:pull/553 PR: https://git.openjdk.java.net/panama-foreign/pull/553 From mail at smogura.eu Thu Jun 10 19:05:07 2021 From: mail at smogura.eu (=?utf-8?B?UmFkb3PFgmF3IFNtb2d1cmE=?=) Date: Thu, 10 Jun 2021 19:05:07 +0000 Subject: RFC: static bulk copy methods In-Reply-To: References: <95c04a58-4897-0d49-3f13-d8aa6b293006@oracle.com> <87a484de-9cdc-ddc7-ff73-6dad2641d5a4@oracle.com> <0bd0724a-ce06-bb25-10a9-9f0641b359c1@oracle.com> <06429259-99bf-4043-d611-24aa6fb353bd@oracle.com> <8785fd57-baf3-cb86-e715-9f8f66c74684@oracle.com> <7ad1c1b1-bc64-ad32-2b5e-eceafae5a8ae@oracle.com>, Message-ID: Hi all, Let me add my two cents, I wonder if some transformations with bulk copy can?t be achieved by vector operations on memory segments? What do you think? Kind regards, Rado > On Jun 10, 2021, at 4:30 PM, Maurizio Cimadamore wrote: > > ?Hi > I've create a draft PR which adds the new MemorySegment method to do the bulk copy (with swap if needed), plus the code that Lee posted in this thread [1]: > > https://github.com/openjdk/panama-foreign/pull/555 > > There are a couple of points which deserve a discussion. > > First, array indices are always expressed as logical indices (e.g. to access the second long in a long[], we use "1", not "16"). This creates some tension when adding the static methods for doing the bulk copy between arrays and segments, as the more natural index to be used with a segment is not a logical index, but just a raw byte offset. In this PR the static methods in MemoryCopy simply accept logical indices for arrays and raw offsets for segments, w/o any further attempt to reconcile the mismatch. In a separate thread [2] we have discussed few options to ameliorate the situation, should this become an issue in real code. > > Second, to do a "swappy" bulk copy we need to know the size of the elements we're copying. That's because the byte swap will be applied on a per-element basis (of course). There are several options to provide such an API in MemorySegment, listed below: > > ``` > MemorySegment.copyFrom(MemorySegment src, int elemSize, boolean swap) // 1 > MemorySegment.copyFrom(MemorySegment src, ValueLayout elemLayout, ByteOrder order) // 2 > MemorySegment.copyFrom(MemorySegment src, ValueLayout srcElementLayout, ValueLayout dstElementLayout) // 3 > ``` > > The first is merely a wrapper around unsafe. It's a good fallback, but seems very low level, even for our API; specifically, it seems we could do something to avoid that "swap" parameter. > > The second option takes a step towards layouts - e.g. if we model elements with a layout, then we can compare the endianness of the layout with the provided order. What I find confusing about this API is that it's not clear to which segment (source or target) does the layout or order arguments apply to. > > The third option fully embrace layouts and is what is implemented in the PR. We now have a layout for the source elements, and a layout for the destination elements. If their order is different a byte swap occurs. The simpler one-argument copyFrom can be expressed as: > > ``` > copyFrom(src) == copyFrom(src, JAVA_BYTE, JAVA_BYTE) > ``` > > To perform a swappy copy between short elements, a client would probably do: > > ``` > copyFrom(src, BITS_16_LE, BITS_16_BE) > ``` > > The method will also check alignment constraints in the source and target segments, so if clients want to use this enhanced copyFrom to copy elements at unaligned addresses, the alignment constraints should be removed from the target layout: > > ``` > copyFrom(src, BITS_16_LE, BITS_16_BE.withBitAlignment(8)) > ``` > > This check adds extra safety belts, and does not affect expressiveness, since we can always create "unaligned" layouts to bulk copy at arbitrary addresses --- and I imagine that the routines in MemoryCopy will want to do something along these lines. > > Comments welcome. > > Maurizio > > [1] - https://mail.openjdk.java.net/pipermail/panama-dev/2021-April/013518.html > [2] - https://mail.openjdk.java.net/pipermail/panama-dev/2021-June/014047.html From douglas.surber at oracle.com Thu Jun 10 19:38:08 2021 From: douglas.surber at oracle.com (Douglas Surber) Date: Thu, 10 Jun 2021 19:38:08 +0000 Subject: compose MemorySegments In-Reply-To: <9fc0ae1c-acf0-b064-9749-ec4cba84342a@oracle.com> References: <2433173C-34FE-430C-9751-5BF4209064DB@oracle.com> <18df1d1b-ed73-e8a8-968e-aeb6d36f0e2e@oracle.com> <9A1FC972-20B2-4718-8AFC-157DC91C8A37@oracle.com> <0d06bfe5-6d56-7859-8ad7-48fa0682c740@oracle.com> <77a9ec6d-1292-b301-8c9f-7dcf1185a65c@oracle.com> <9fc0ae1c-acf0-b064-9749-ec4cba84342a@oracle.com> Message-ID: I'm a newcomer to Panama. My use case seems a little different from what Panama currently supports. While Panama has most of what I need, there's one thing missing, the ability to compose MemorySegments into a single composite MemorySegment that seamlessly spans all the components. My code reads data from a network. The size and number of fields can be large so the total amount of data read at one time can be large. The code does not know the length of the data in advance, finding it only by reading all the data. Also the code does not fully interpret the data as it reads it. That's too expensive. Instead the code copies the data from the network into a sequence of fixed size blocks, byte[]s. When the user application needs a field the code uses the metadata included in the data to locate the desired field and extract it from the blocks. Currently the code has to manipulate the bytes individually to construct the Java object the app requested. Keep in mind that a field value can begin at any offset in a block and can span block boundaries. This byte manipulation is relatively expensive. With the existing Panama API I can create a MemorySegment for an individual block, offset it to the start of a field and extract a value so long as it does not span a block boundary. But if the field spans a block boundary that no longer works. What I need is a way to compose MemorySegments, one for each block, into a single MemorySegment that spans them all hiding the block boundaries. public static MemorySegment of(MemorySegment ... subsegments); I also would like to append a MemorySegment to an existing composite MemorySegment. public MemorySegment append(MemorySegment tail); Given this I could compose all the blocks into a single MemorySegment and then ignore the block boundaries. List blocks = ... ; MemorySegment[] individualBlocks = new MemorySegment[blocks.length()]; int i = 0; for (byte[] b : blocks) individualBlocks[i++] = MemorySegment.ofArray(b); MemorySegment allBlocks = MemorySegment.of(individualBlocks); protected String getString(long byteOffset, int charLength) { MemorySegment dataPointer = allBlocks.asSlice(byteOffset, charLength * 2); System.out.println(new String(dataPointer.toCharArray())); } Naively toCharArray would allocate a new char[] and copy the bits into that array then the String constructor would copy the bits from the char[] into its internal byte[]. At least one copy is necessary but it would be nice if this could be optimized to avoid allocation of the temporary char[] and the copy into it. I do have a question on the toXxxArray methods. How is endianness accounted for? The data I get from the network may have a different endianness from the platform. Also, it would be convenient to add methods such as getInt to MemorySegment analogous to toIntArray. I know this can be done with a VarHandle but getting a single primitive value is likely to be such a common use case that encapsulating it into a method would be helpful. Douglas From maurizio.cimadamore at oracle.com Thu Jun 10 20:04:54 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 10 Jun 2021 21:04:54 +0100 Subject: Part 1 Proposal for JDK-8264594 In-Reply-To: References: <87a484de-9cdc-ddc7-ff73-6dad2641d5a4@oracle.com> <0bd0724a-ce06-bb25-10a9-9f0641b359c1@oracle.com> <06429259-99bf-4043-d611-24aa6fb353bd@oracle.com> <8785fd57-baf3-cb86-e715-9f8f66c74684@oracle.com> <7ad1c1b1-bc64-ad32-2b5e-eceafae5a8ae@oracle.com> <78f0c378-bbca-8e5a-e4bd-98528070d86c@oracle.com> Message-ID: <6e1b8ef7-ad06-6511-7ea3-c2aebd7dd5a7@oracle.com> On 10/06/2021 18:35, leerho wrote: > I am wondering what would be easiest for you:? to submit code via > email as I have been doing, or create a branch in my public GitHub > account with the changes: https://github.com/leerho/panama-foreign > . > If you do that, note that you can create a "fork" of my personal repo: https://github.com/mcimadamore/panama-foreign And then submit a PR against the draft PR branch I'm using. That should work too :-) Maurizio > > Lee. > > On Thu, Jun 10, 2021 at 10:28 AM Maurizio Cimadamore > > wrote: > > > On 10/06/2021 18:12, leerho wrote: >> Maurizio, >> Now that you have submitted the draft PR >> (https://github.com/openjdk/panama-foreign/pull/555 >> ), >> should I make the changes necessary to the MemoryCopy class to >> call the /MemorySegment.copyFrom(MemorySegment src, ValueLayout >> srcElementLayout,/ >> /ValueLayout dstElementLayout)/?implemented in the PR?? ?-- Or >> should I wait until it is at least in a branch? > You can go ahead and work on the changes. I will update the PR > accordingly. >> >> Also, as I mentioned earlier, the TestMemoryCopy will have to be >> rewritten to also test the byte swaps.? (and fix some of the >> extra space errors found ). > Ok >> >> I will have to relay these changes through you as I don't have >> permission to submit changes directly. > > That's absolutely fine, no worries - as long as everything is > visible on this list :-) > > Thanks > Maurizio > >> >> Lee. >> >> >> >> On Thu, Jun 10, 2021 at 9:33 AM leerho > > wrote: >> >> Also, to make the comparison more fair, we should add the >> user ability to compute the logical offset for option 1. >> Restating the options: >> >> 1. copyIntoArrayRaw(segment, srcOffsetBytes, long[] >> dstArray, dstIndexLongs, dstCopyLengthLongs) >> //For the "Logical" case, user has the option to write: >> copyIntoArrayRaw(segment, srcOffsetLongs * 8L, long[] >> dstArray, dstIndexLongs, dstCopyLengthLongs) >> >> 2. copyIntoArrayRaw(segment, srcOffsetBytes, long[] >> dstArray, dstIndexLongs, dstCopyLengthLongs) >> And >> copyIntoArrayLogical(segment, srcOffsetLongs, long[] >> dstArray, dstIndexLongs, dstCopyLengthLongs) >> >> 3. copyIntoArrayLogical(segment, srcOffsetLongs, long[] >> dstArray, dstIndexLongs, dstCopyLengthLongs) >> //For the "Raw" case, user has the option to write a >> compound statement like: >> copyIntoArrayLogical(segment.asSlice(srcOffsetBytes), 0, >> long[] dstArray, dstIndexLongs, dstCopyLengthLongs) >> >> Lee. >> >> On Thu, Jun 10, 2021 at 1:45 AM Maurizio Cimadamore >> > > wrote: >> >> >> On 10/06/2021 00:02, leerho wrote: >> > // I think we discussed a while back that the asSlice >> would also >> > require a length. >> >> Minor correction - with the new API, I don't think you >> need a length. >> >> There is an overload of asSlice which just takes an >> offset, and >> recomputes the length automatically. >> >> So, if you use that, combined with the static method you >> provide, I >> think we should be good? >> >> copyIntoArrayLogical(segment.asSlice(srcOffsetBytes), 0, >> long[] >> dstArray, dstIndexLongs, dstCopyLengthLongs) >> >> Maurizio >> From maurizio.cimadamore at oracle.com Thu Jun 10 20:06:32 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 10 Jun 2021 21:06:32 +0100 Subject: RFC: static bulk copy methods In-Reply-To: <96881B59-E6A4-4B96-A797-97CAB16AB4F3@oracle.com> References: <95c04a58-4897-0d49-3f13-d8aa6b293006@oracle.com> <87a484de-9cdc-ddc7-ff73-6dad2641d5a4@oracle.com> <0bd0724a-ce06-bb25-10a9-9f0641b359c1@oracle.com> <06429259-99bf-4043-d611-24aa6fb353bd@oracle.com> <8785fd57-baf3-cb86-e715-9f8f66c74684@oracle.com> <7ad1c1b1-bc64-ad32-2b5e-eceafae5a8ae@oracle.com> <96881B59-E6A4-4B96-A797-97CAB16AB4F3@oracle.com> Message-ID: <6fc995a4-126e-7ef3-a5a9-2ceebcbaec25@oracle.com> On 10/06/2021 19:10, John Rose wrote: > I like to break up such ?dancing pairs? > of similar arguments if I can. ?Maybe: > > MemorySegment.copyWithLayoutsFrom(ValueLayout dstElementLayout, > MemorySegment src, ValueLayout srcElementLayout) > Sure, that's a reasonable move - this is all experimental, but I think we agree on the general direction (more layouts, less "swappy" parameters). Maurizio From maurizio.cimadamore at oracle.com Thu Jun 10 20:08:26 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 10 Jun 2021 21:08:26 +0100 Subject: RFC: static bulk copy methods In-Reply-To: References: <95c04a58-4897-0d49-3f13-d8aa6b293006@oracle.com> <87a484de-9cdc-ddc7-ff73-6dad2641d5a4@oracle.com> <0bd0724a-ce06-bb25-10a9-9f0641b359c1@oracle.com> <06429259-99bf-4043-d611-24aa6fb353bd@oracle.com> <8785fd57-baf3-cb86-e715-9f8f66c74684@oracle.com> <7ad1c1b1-bc64-ad32-2b5e-eceafae5a8ae@oracle.com> Message-ID: <900857d2-4885-6c5b-ee92-6dba624b0d48@oracle.com> On 10/06/2021 20:05, Rados?aw Smogura wrote: > Hi all, > > Let me add my two cents, I wonder if some transformations with bulk copy can?t be achieved by vector operations on memory segments? I believe there is a big overlap here - I was asking Paul something similar yesterday. For instance, given a layout and a select (e.g.? a layout path) only copy "certain" fields from source segment into target segments. These all seems in the realm of possibility if we get to a world where vector API and memory access API are more closely connected together, which we can't really do at the moment because of incubation (but we'll get there). Maurizio > > What do you think? > > Kind regards, > Rado > >> On Jun 10, 2021, at 4:30 PM, Maurizio Cimadamore wrote: >> >> ?Hi >> I've create a draft PR which adds the new MemorySegment method to do the bulk copy (with swap if needed), plus the code that Lee posted in this thread [1]: >> >> https://urldefense.com/v3/__https://github.com/openjdk/panama-foreign/pull/555__;!!GqivPVa7Brio!PQVXKBjgvkvT2CcE5WLS0zZlSVqZYjiSUdB3x3wfZSoRVsOlSue311OWb-Ya5tf0Qjs7zyw$ >> >> There are a couple of points which deserve a discussion. >> >> First, array indices are always expressed as logical indices (e.g. to access the second long in a long[], we use "1", not "16"). This creates some tension when adding the static methods for doing the bulk copy between arrays and segments, as the more natural index to be used with a segment is not a logical index, but just a raw byte offset. In this PR the static methods in MemoryCopy simply accept logical indices for arrays and raw offsets for segments, w/o any further attempt to reconcile the mismatch. In a separate thread [2] we have discussed few options to ameliorate the situation, should this become an issue in real code. >> >> Second, to do a "swappy" bulk copy we need to know the size of the elements we're copying. That's because the byte swap will be applied on a per-element basis (of course). There are several options to provide such an API in MemorySegment, listed below: >> >> ``` >> MemorySegment.copyFrom(MemorySegment src, int elemSize, boolean swap) // 1 >> MemorySegment.copyFrom(MemorySegment src, ValueLayout elemLayout, ByteOrder order) // 2 >> MemorySegment.copyFrom(MemorySegment src, ValueLayout srcElementLayout, ValueLayout dstElementLayout) // 3 >> ``` >> >> The first is merely a wrapper around unsafe. It's a good fallback, but seems very low level, even for our API; specifically, it seems we could do something to avoid that "swap" parameter. >> >> The second option takes a step towards layouts - e.g. if we model elements with a layout, then we can compare the endianness of the layout with the provided order. What I find confusing about this API is that it's not clear to which segment (source or target) does the layout or order arguments apply to. >> >> The third option fully embrace layouts and is what is implemented in the PR. We now have a layout for the source elements, and a layout for the destination elements. If their order is different a byte swap occurs. The simpler one-argument copyFrom can be expressed as: >> >> ``` >> copyFrom(src) == copyFrom(src, JAVA_BYTE, JAVA_BYTE) >> ``` >> >> To perform a swappy copy between short elements, a client would probably do: >> >> ``` >> copyFrom(src, BITS_16_LE, BITS_16_BE) >> ``` >> >> The method will also check alignment constraints in the source and target segments, so if clients want to use this enhanced copyFrom to copy elements at unaligned addresses, the alignment constraints should be removed from the target layout: >> >> ``` >> copyFrom(src, BITS_16_LE, BITS_16_BE.withBitAlignment(8)) >> ``` >> >> This check adds extra safety belts, and does not affect expressiveness, since we can always create "unaligned" layouts to bulk copy at arbitrary addresses --- and I imagine that the routines in MemoryCopy will want to do something along these lines. >> >> Comments welcome. >> >> Maurizio >> >> [1] - https://mail.openjdk.java.net/pipermail/panama-dev/2021-April/013518.html >> [2] - https://mail.openjdk.java.net/pipermail/panama-dev/2021-June/014047.html From maurizio.cimadamore at oracle.com Thu Jun 10 21:29:27 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 10 Jun 2021 22:29:27 +0100 Subject: compose MemorySegments In-Reply-To: References: <2433173C-34FE-430C-9751-5BF4209064DB@oracle.com> <18df1d1b-ed73-e8a8-968e-aeb6d36f0e2e@oracle.com> <9A1FC972-20B2-4718-8AFC-157DC91C8A37@oracle.com> <0d06bfe5-6d56-7859-8ad7-48fa0682c740@oracle.com> <77a9ec6d-1292-b301-8c9f-7dcf1185a65c@oracle.com> <9fc0ae1c-acf0-b064-9749-ec4cba84342a@oracle.com> Message-ID: Hi Douglas I think the point you raise re. compisition is a valid one, but I'm also afraid that what you are looking for is higher-level than what memory segments have been created for. A MemorySegment models a _contiguous_ memory region, with a start and an end. Then we have dereference primitives that allow you to peek and poke at this contiguous memory region. A memory dereference operation is designed to be fast - e.g. it should boil down to, ideally, a single machine instruction (or better, a SIMD instruction for vectorized loops). I get that, in your case, you want to work with a superposition of multiple segments - and have dereference operations "just work" (probably by dynamically selecting the right underlying segment based on the offset). But, your case is also pretty distant from what the API was designed for. While it's technically possible for the API to create a "multi-segment", the performance model of these things would be so different from that of plain segments that it will just be confusing. A bit like asking for an API which allowed us to combine Java arrays into a single logical array which, in reality is scattered in multiple places - and then passing these arrays around to clients which expects just "plain arrays". So, I'm afraid that the thing you identify as "missing" is kind of missing _by design_: what you describe is simply not a segment, in the way the API describes what a segment is (sorry!). On 10/06/2021 20:38, Douglas Surber wrote: > I do have a question on the toXxxArray methods. How is endianness accounted for? The data I get from the network may have a different endianness from the platform. Good point - for now toXyzArray methods just use native endianness. We are in the process of adding other ways to bulk copy data from arrays into segments and viceversa (see https://github.com/openjdk/panama-foreign/pull/555), I'm sure there's something in there that you could use to enforce right endianness. > > Also, it would be convenient to add methods such as getInt to MemorySegment analogous to toIntArray. I know this can be done with a VarHandle but getting a single primitive value is likely to be such a common use case that encapsulating it into a method would be helpful. Look at the MemoryAccess class. That class contains a lot of static methods which remove the need, for simple cases, to tinker with var handles. Maurizio > > Douglas > > From youngty1997 at gmail.com Thu Jun 10 22:07:17 2021 From: youngty1997 at gmail.com (Ty Young) Date: Thu, 10 Jun 2021 17:07:17 -0500 Subject: compose MemorySegments In-Reply-To: References: <2433173C-34FE-430C-9751-5BF4209064DB@oracle.com> <18df1d1b-ed73-e8a8-968e-aeb6d36f0e2e@oracle.com> <9A1FC972-20B2-4718-8AFC-157DC91C8A37@oracle.com> <0d06bfe5-6d56-7859-8ad7-48fa0682c740@oracle.com> <77a9ec6d-1292-b301-8c9f-7dcf1185a65c@oracle.com> <9fc0ae1c-acf0-b064-9749-ec4cba84342a@oracle.com> Message-ID: <853b522d-43c6-013b-7d6b-d8c0e73d39e5@gmail.com> Would a mapped MemorySegment work for you? On 6/10/21 2:38 PM, Douglas Surber wrote: > I'm a newcomer to Panama. My use case seems a little different from what Panama currently supports. While Panama has most of what I need, there's one thing missing, the ability to compose MemorySegments into a single composite MemorySegment that seamlessly spans all the components. > > My code reads data from a network. The size and number of fields can be large so the total amount of data read at one time can be large. The code does not know the length of the data in advance, finding it only by reading all the data. Also the code does not fully interpret the data as it reads it. That's too expensive. Instead the code copies the data from the network into a sequence of fixed size blocks, byte[]s. When the user application needs a field the code uses the metadata included in the data to locate the desired field and extract it from the blocks. > > Currently the code has to manipulate the bytes individually to construct the Java object the app requested. Keep in mind that a field value can begin at any offset in a block and can span block boundaries. This byte manipulation is relatively expensive. > > With the existing Panama API I can create a MemorySegment for an individual block, offset it to the start of a field and extract a value so long as it does not span a block boundary. But if the field spans a block boundary that no longer works. > > What I need is a way to compose MemorySegments, one for each block, into a single MemorySegment that spans them all hiding the block boundaries. > > public static MemorySegment of(MemorySegment ... subsegments); > > I also would like to append a MemorySegment to an existing composite MemorySegment. > > public MemorySegment append(MemorySegment tail); > > Given this I could compose all the blocks into a single MemorySegment and then ignore the block boundaries. > > List blocks = ... ; > > MemorySegment[] individualBlocks = new MemorySegment[blocks.length()]; > int i = 0; > for (byte[] b : blocks) individualBlocks[i++] = MemorySegment.ofArray(b); > MemorySegment allBlocks = MemorySegment.of(individualBlocks); > > protected String getString(long byteOffset, int charLength) { > MemorySegment dataPointer = allBlocks.asSlice(byteOffset, charLength * 2); > System.out.println(new String(dataPointer.toCharArray())); > } > > Naively toCharArray would allocate a new char[] and copy the bits into that array then the String constructor would copy the bits from the char[] into its internal byte[]. At least one copy is necessary but it would be nice if this could be optimized to avoid allocation of the temporary char[] and the copy into it. > > I do have a question on the toXxxArray methods. How is endianness accounted for? The data I get from the network may have a different endianness from the platform. > > Also, it would be convenient to add methods such as getInt to MemorySegment analogous to toIntArray. I know this can be done with a VarHandle but getting a single primitive value is likely to be such a common use case that encapsulating it into a method would be helpful. > > Douglas > > From douglas.surber at oracle.com Thu Jun 10 23:24:31 2021 From: douglas.surber at oracle.com (Douglas Surber) Date: Thu, 10 Jun 2021 23:24:31 +0000 Subject: compose MemorySegments In-Reply-To: References: <2433173C-34FE-430C-9751-5BF4209064DB@oracle.com> <18df1d1b-ed73-e8a8-968e-aeb6d36f0e2e@oracle.com> <9A1FC972-20B2-4718-8AFC-157DC91C8A37@oracle.com> <0d06bfe5-6d56-7859-8ad7-48fa0682c740@oracle.com> <77a9ec6d-1292-b301-8c9f-7dcf1185a65c@oracle.com> <9fc0ae1c-acf0-b064-9749-ec4cba84342a@oracle.com> Message-ID: <7165F10B-D8B5-4558-A291-D64DF6DDE761@oracle.com> Maurizio, I can certainly respect a decision that composing multiple MemorySegments might be out of scope. Without composition I would write something like this. MemorySegment.ofArray(dest) .asSlice(destOffset, firstPartLength) .copyFrom(MemorySegment.ofArray(src0).asSlice(srcOffset, firstPartLength); MemorySegment.ofArray(dest) .asSlice(destOffset + firstPartLength, destOffset + firstPartLength + secondPartLength) .copyFrom(MemorySegment.ofArray(src1).asSlice(0L, secondPartLength)); This would copy the bits from the end of src0 into the first part of dest and the bits from the beginning of src1 into the second part of dest. Would all this result in just two SIMD instructions modulo bounds checking? And no allocations? Douglas From douglas.surber at oracle.com Thu Jun 10 23:41:32 2021 From: douglas.surber at oracle.com (Douglas Surber) Date: Thu, 10 Jun 2021 23:41:32 +0000 Subject: compose MemorySegments In-Reply-To: References: Message-ID: <106FE1E7-8CEE-4151-A882-C588F7A12AC1@oracle.com> As I understand them, no a mapped MemorySegment wouldn't work. The data is not in a file. It is in byte[]s. My code has to look at the bits as it gets them from the network to deal with metadata. Based on that it copies the data bits from the network buffer into byte[]s with no additional processing. Douglas On Jun 10, 2021, at 4:24 PM, panama-dev-request at openjdk.java.net wrote: Would a mapped MemorySegment work for you? From leerho at gmail.com Fri Jun 11 03:15:36 2021 From: leerho at gmail.com (leerho) Date: Thu, 10 Jun 2021 20:15:36 -0700 Subject: compose MemorySegments In-Reply-To: <7165F10B-D8B5-4558-A291-D64DF6DDE761@oracle.com> References: <2433173C-34FE-430C-9751-5BF4209064DB@oracle.com> <18df1d1b-ed73-e8a8-968e-aeb6d36f0e2e@oracle.com> <9A1FC972-20B2-4718-8AFC-157DC91C8A37@oracle.com> <0d06bfe5-6d56-7859-8ad7-48fa0682c740@oracle.com> <77a9ec6d-1292-b301-8c9f-7dcf1185a65c@oracle.com> <9fc0ae1c-acf0-b064-9749-ec4cba84342a@oracle.com> <7165F10B-D8B5-4558-A291-D64DF6DDE761@oracle.com> Message-ID: Hi Douglas, This is an interesting problem and a difficult one to do efficiently without copies or additional allocations. I think the OS does similar tricks when it maps virtual memory addresses into CPU caches or main memory. To the user's program it appears as a contiguous memory space but in reality could be broken into many separate physical chunks. I'm sure there are some ways one could do this in C++, but probably not as efficient as the OS could do it. In looking at your code above I am guessing you may be trying to create a 1:1 association between fields (which may cross block boundaries) and MemorySegments as a preprocessing step, so that when a user requests a field it is already in a segment? I'm not sure, but from what you have described there are statistical techniques that could possibly be of help. If your field sizes vary over a wide dynamic range and your data is large, it is likely that the distribution of field sizes roughly follow a power-law distribution. In other words, the number of fields that are large enough to actually cross block boundaries are orders-of-magnitude fewer than the smaller fields that are always contained in a single block. This means that the expensive copy/slice operation you describe above really only needs to be performed on the big fields, so amortized across all fields becomes much less expensive, on average. But perhaps there is more. There are streaming algorithms (called "sketches") for computing the shape of your field size distribution on-the-fly. Perhaps you could use this real-time information to partition off to another processing element or memory space those fields that are likely to split across blocks. This would allow some parallelization of the expensive composition operation. This is clearly whimsical speculation because I can only guess at what your application is actually doing, but perhaps it might trigger something for you :) Cheers, Lee. On Thu, Jun 10, 2021 at 4:25 PM Douglas Surber wrote: > > Maurizio, > > I can certainly respect a decision that composing multiple MemorySegments > might be out of scope. Without composition I would write something like > this. > > MemorySegment.ofArray(dest) > .asSlice(destOffset, firstPartLength) > .copyFrom(MemorySegment.ofArray(src0).asSlice(srcOffset, firstPartLength); > MemorySegment.ofArray(dest) > .asSlice(destOffset + firstPartLength, destOffset + firstPartLength + > secondPartLength) > .copyFrom(MemorySegment.ofArray(src1).asSlice(0L, secondPartLength)); > > This would copy the bits from the end of src0 into the first part of dest > and the bits from the beginning of src1 into the second part of dest. Would > all this result in just two SIMD instructions modulo bounds checking? And > no allocations? > > Douglas > From leerho at gmail.com Fri Jun 11 04:30:58 2021 From: leerho at gmail.com (leerho) Date: Thu, 10 Jun 2021 21:30:58 -0700 Subject: Configure error Message-ID: Maurizio, I forked your mcimadamore/panama-foreign into my GitHub.com/leerho/mcimadamore_panama-foreign as you suggested, and then cloned it to my computer. I have special copies of clang+llvm-9.0.1-x86_64-apple-darwin and jtreg in a separate local directory. But when I run bash configure bash configure --with-libclang=/Users/lrhodes/dev/git/Oracle/local/clang+llvm-9.0.1-x86_64-apple-darwin/ --with-jtreg=/Users/lrhodes/dev/git/Oracle/local/jtreg/ I get the error: configure: error: unrecognized options: --with-libclang Has something changed recently? Thanks in advance :) Lee. From sundararajan.athijegannathan at oracle.com Fri Jun 11 05:13:45 2021 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Fri, 11 Jun 2021 05:13:45 +0000 Subject: Configure error In-Reply-To: References: Message-ID: Hi, I just git cloned your repo git clone https://github.com/leerho/panama-foreign.git and ran configure with --with-libclang option. It worked fine.. You may want to make sure foreign-jextract branch is checked out. -Sundar ________________________________ From: panama-dev on behalf of leerho Sent: 11 June 2021 10:00 To: panama-dev at openjdk.java.net' ; Maurizio Cimadamore Subject: Configure error Maurizio, I forked your mcimadamore/panama-foreign into my GitHub.com/leerho/mcimadamore_panama-foreign as you suggested, and then cloned it to my computer. I have special copies of clang+llvm-9.0.1-x86_64-apple-darwin and jtreg in a separate local directory. But when I run bash configure bash configure --with-libclang=/Users/lrhodes/dev/git/Oracle/local/clang+llvm-9.0.1-x86_64-apple-darwin/ --with-jtreg=/Users/lrhodes/dev/git/Oracle/local/jtreg/ I get the error: configure: error: unrecognized options: --with-libclang Has something changed recently? Thanks in advance :) Lee. From jbhateja at openjdk.java.net Fri Jun 11 09:05:07 2021 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Fri, 11 Jun 2021 09:05:07 GMT Subject: [vectorIntrinsics+mask] RFR: 8268154: Add masking support for vector load intrinsics [v2] In-Reply-To: References: Message-ID: On Thu, 10 Jun 2021 10:08:45 GMT, Xiaohong Gong wrote: >> This patch adds the predicate support for masked load vector operation, including the Vector API java implementation and hotspot intrinsics changes. The main changes contain: >> - Adding a new hotspot intrinsic method (`loadMasked`), which can transform the vector mask class and value to hotspot. It is called by the masked `"fromArray"` API in JAVA level. The compiler will generate the masked vector load node if the current platform supports the predicate feature and backend has implemented it. Otherwise, the vector blend pattern will be generated like before. >> - Adding the similar masked support for load/store boolean/char array. >> >> Note that the intrinsification when there is the array range bailout is not implemented in this patch. We are considering making it vectorized with predicate feature for SVE/AVX-512 as well, and will create a separate patch for it in future. >> >> Also note that this patch doesn't contain any backend changes. > > Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments Marked as reviewed by jbhateja (Committer). Thanks!, changes looks good to me. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/90 From xgong at openjdk.java.net Fri Jun 11 09:40:37 2021 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Fri, 11 Jun 2021 09:40:37 GMT Subject: [vectorIntrinsics+mask] RFR: 8268154: Add masking support for vector load intrinsics [v3] In-Reply-To: References: Message-ID: > This patch adds the predicate support for masked load vector operation, including the Vector API java implementation and hotspot intrinsics changes. The main changes contain: > - Adding a new hotspot intrinsic method (`loadMasked`), which can transform the vector mask class and value to hotspot. It is called by the masked `"fromArray"` API in JAVA level. The compiler will generate the masked vector load node if the current platform supports the predicate feature and backend has implemented it. Otherwise, the vector blend pattern will be generated like before. > - Adding the similar masked support for load/store boolean/char array. > > Note that the intrinsification when there is the array range bailout is not implemented in this patch. We are considering making it vectorized with predicate feature for SVE/AVX-512 as well, and will create a separate patch for it in future. > > Also note that this patch doesn't contain any backend changes. Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision: Minor fixes to code style ------------- Changes: - all: https://git.openjdk.java.net/panama-vector/pull/90/files - new: https://git.openjdk.java.net/panama-vector/pull/90/files/0b77c8e3..0dd310e3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=90&range=02 - incr: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=90&range=01-02 Stats: 5 lines in 4 files changed: 0 ins; 4 del; 1 mod Patch: https://git.openjdk.java.net/panama-vector/pull/90.diff Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/90/head:pull/90 PR: https://git.openjdk.java.net/panama-vector/pull/90 From xgong at openjdk.java.net Fri Jun 11 09:40:38 2021 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Fri, 11 Jun 2021 09:40:38 GMT Subject: [vectorIntrinsics+mask] RFR: 8268154: Add masking support for vector load intrinsics [v2] In-Reply-To: References: Message-ID: On Fri, 11 Jun 2021 09:01:13 GMT, Jatin Bhateja wrote: >> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision: >> >> Address review comments > > Thanks!, changes looks good to me. Thanks for the review @jatin-bhateja @PaulSandoz ! ------------- PR: https://git.openjdk.java.net/panama-vector/pull/90 From maurizio.cimadamore at oracle.com Fri Jun 11 10:40:19 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 11 Jun 2021 11:40:19 +0100 Subject: Configure error In-Reply-To: References: Message-ID: <5c294def-666f-3811-01ba-b7a9070eb2d0@oracle.com> Another option, since you are not really working with jextract, is to work on top of the foreign-memaccess+abi branch - which contains everything _but_ jextract, and can be built like any other regular JDKs. Maurizio On 11/06/2021 06:13, Sundararajan Athijegannathan wrote: > Hi, > > I just git cloned your repo > > git clone https://github.com/leerho/panama-foreign.git > > > > and ran configure with --with-libclang option. It worked fine.. > > You may want to make sure foreign-jextract branch is checked out. > > -Sundar > ------------------------------------------------------------------------ > *From:* panama-dev on behalf of > leerho > *Sent:* 11 June 2021 10:00 > *To:* panama-dev at openjdk.java.net' ; > Maurizio Cimadamore > *Subject:* Configure error > Maurizio, > I forked your mcimadamore/panama-foreign into my > GitHub.com/leerho/mcimadamore_panama-foreign as you suggested, and then > cloned it to my computer.? I have special copies of > clang+llvm-9.0.1-x86_64-apple-darwin and jtreg in a separate local > directory. > > But when I run bash configure > > bash configure > --with-libclang=/Users/lrhodes/dev/git/Oracle/local/clang+llvm-9.0.1-x86_64-apple-darwin/ > --with-jtreg=/Users/lrhodes/dev/git/Oracle/local/jtreg/ > > > I get the error: > > > configure: error: unrecognized options: --with-libclang > > > Has something changed recently? > > > Thanks in advance :) > > > Lee. From maurizio.cimadamore at oracle.com Fri Jun 11 10:47:11 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 11 Jun 2021 11:47:11 +0100 Subject: compose MemorySegments In-Reply-To: <7165F10B-D8B5-4558-A291-D64DF6DDE761@oracle.com> References: <2433173C-34FE-430C-9751-5BF4209064DB@oracle.com> <18df1d1b-ed73-e8a8-968e-aeb6d36f0e2e@oracle.com> <9A1FC972-20B2-4718-8AFC-157DC91C8A37@oracle.com> <0d06bfe5-6d56-7859-8ad7-48fa0682c740@oracle.com> <77a9ec6d-1292-b301-8c9f-7dcf1185a65c@oracle.com> <9fc0ae1c-acf0-b064-9749-ec4cba84342a@oracle.com> <7165F10B-D8B5-4558-A291-D64DF6DDE761@oracle.com> Message-ID: <49e6f643-2503-3f08-3c4c-d71b404b57e7@oracle.com> On 11/06/2021 00:24, Douglas Surber wrote: > > Maurizio, > > I can certainly respect a decision that composing multiple > MemorySegments might be out of scope. Without composition I would > write something like this. > > MemorySegment.ofArray(dest) > .asSlice(destOffset,?firstPartLength) > .copyFrom(MemorySegment.ofArray(src0).asSlice(srcOffset, > firstPartLength); > MemorySegment.ofArray(dest) > .asSlice(destOffset + firstPartLength,?destOffset + > firstPartLength + secondPartLength) > .copyFrom(MemorySegment.ofArray(src1).asSlice(0L, secondPartLength)); > > > This would copy the bits from the end of src0 into the first part of > dest and the bits from the beginning of src1 into the second part of > dest. Would all this?result in just two SIMD instructions modulo > bounds checking? And no allocations? Short answer is, yes, possibly. Slightly longer answer - as I mentioned we're working to offer different helpers to copy data from segments to arrays and viceversa, so that the code above can be made significantly more readable. Looking a bit further down the road, memory segments are effectively immutable (the bit of mutable state which tells whether a resource is released or not is in the so called "resource scope", not in a MemorySegment). So, right now, we can sometimes take advantage of escape analysis to eliminate allocation of segment slices (e.g. if a segment doesn't "escape", it can often be scalarized into registers). Of course escape analysis doesn't always work, especially when a method contains control flow. But Valhalla will give us the ability to implement the MemorySegment interface with a true "primitive class" - for which allocation behavior could be much more predictable. So, if the Java code surrounding the bulk copy is optimized enough, you do get a pretty optimized bulk copy. In your specific case, there's no control flow, and the temporary slices you create are only used inside the copy method - which makes me think that stuff like this should already perform decently, assuming the code above gets inlined by C2. Here's a benchmark I've tweaked in the past to show the (non) cost of slicing prior to a bulk op: https://mail.openjdk.java.net/pipermail/panama-dev/2021-April/012889.html and https://mail.openjdk.java.net/pipermail/panama-dev/2021-April/012897.html The first shows throughput, the latter allocation rate, which is zero for both unsafe and the memory segment APIs. This doesn't mean that in _all_ cases allocations will be eliminated (see above), but we're in relatively good shape, and we have plans to make allocations even less expensive as new VM features are rolled out. Maurizio > > Douglas From maurizio.cimadamore at oracle.com Fri Jun 11 11:07:48 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 11 Jun 2021 12:07:48 +0100 Subject: compose MemorySegments In-Reply-To: <106FE1E7-8CEE-4151-A882-C588F7A12AC1@oracle.com> References: <106FE1E7-8CEE-4151-A882-C588F7A12AC1@oracle.com> Message-ID: <7740eb08-58d5-6a7f-d391-5da3b0b9f44a@oracle.com> One thing I saw which is very similar to what you want is this: https://netty.io/4.0/api/io/netty/buffer/CompositeByteBuf.html Perhaps Chris Vest or some other folks in Netty can comment more on that API. Netty is also doing some exploratory work to validate use of memory segments within Netty itself [1]. Maurizio [1] - https://github.com/netty/netty-incubator-buffer-api On 11/06/2021 00:41, Douglas Surber wrote: > As I understand them, no a mapped MemorySegment wouldn't work. The data is not in a file. It is in byte[]s. My code has to look at the bits as it gets them from the network to deal with metadata. Based on that it copies the data bits from the network buffer into byte[]s with no additional processing. > > Douglas > > On Jun 10, 2021, at 4:24 PM, panama-dev-request at openjdk.java.net wrote: > > Would a mapped MemorySegment work for you? > From duke at openjdk.java.net Fri Jun 11 11:08:34 2021 From: duke at openjdk.java.net (J.Duke) Date: Fri, 11 Jun 2021 11:08:34 GMT Subject: [foreign-memaccess+abi] RFR: Merge master Message-ID: <6kQYH0G20x-RRsm0Wnoz6kxqojOS3kNnhezWdHo6CTY=.d6ee4399-8a23-4089-8e32-a364843bb91f@github.com> Hi all, this is an _automatically_ generated pull request to notify you that there are 141 commits from the branch `master`that can **not** be merged into the branch `foreign-memaccess+abi`: The following files contains merge conflicts: - src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java - src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/SystemLookup.java - src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/SharedUtils.java - test/jdk/java/foreign/TestUpcallException.java - test/jdk/java/foreign/ThrowingUpcall.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-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 +100:openjdk-bot-100 $ git checkout openjdk-bot-100 # 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-100:100 _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 - 8268565: runtime/records/RedefineRecord.java should be run in driver mode - 8267930: Refine code for loading hsdis library - 8268574: ProblemList tests failing due to UseBiasedLocking going away - 8267556: Enhance class paths check during runtime - 8267893: Improve jtreg test failure handler do get native/mixed stack traces for cores and live processes - 8268223: Problemlist vmTestbase/nsk/jdi/HiddenClass/events/events001.java - 8268539: several serviceability/sa tests should be run in driver mode - 8268361: Fix the infinite loop in next_line - 8267630: Start of release updates for JDK 18 - ... and 131 more: https://git.openjdk.java.net/panama-foreign/compare/4bcfd54d...37791a84 The webrev contains the conflicts with foreign-memaccess+abi: - merge conflicts: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=556&range=00.conflicts Changes: https://git.openjdk.java.net/panama-foreign/pull/556/files Stats: 50423 lines in 846 files changed: 40376 ins; 5696 del; 4351 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/556.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/556/head:pull/556 PR: https://git.openjdk.java.net/panama-foreign/pull/556 From duke at openjdk.java.net Fri Jun 11 11:10:28 2021 From: duke at openjdk.java.net (duke) Date: Fri, 11 Jun 2021 11:10:28 GMT Subject: git: openjdk/panama-foreign: master: 141 new changesets Message-ID: <78496f7a-ac90-4ece-8227-daa5a1d20537@openjdk.org> Changeset: b27599b3 Author: Joe Wang Date: 2021-06-04 16:31:59 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b27599b3ec3fd344fa9fa97b7ecde85d5662ca6c 8268222: javax/xml/jaxp/unittest/transform/Bug6216226Test.java failed, cannot delete file Reviewed-by: dfuchs ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerImpl.java ! src/java.xml/share/classes/javax/xml/transform/stream/StreamResult.java Changeset: cd0678fc Author: Stuart Marks Date: 2021-06-04 17:13:05 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/cd0678fcf6bc00ecda3e61d959617c67d02dba3c 8199318: add idempotent copy operation for Map.Entry Reviewed-by: alanb, psandoz, dfuchs ! src/java.base/share/classes/java/util/AbstractMap.java ! src/java.base/share/classes/java/util/Map.java ! test/jdk/java/util/Map/MapFactories.java Changeset: 64ec8b3e Author: Leonid Mesnik Date: 2021-06-04 17:22:01 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/64ec8b3e5c8a8d44c92591710d73b833f13c1500 8212155: Race condition when posting dynamic_code_generated event leads to JVM crash Reviewed-by: sspitsyn, dcubed ! src/hotspot/share/prims/jvmtiExport.cpp + test/hotspot/jtreg/serviceability/jvmti/DynamicCodeGenerated/DynamicCodeGeneratedTest.java + test/hotspot/jtreg/serviceability/jvmti/DynamicCodeGenerated/libDynamicCodeGenerated.cpp Changeset: 20b63127 Author: Sandhya Viswanathan Date: 2021-06-04 18:16:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/20b631278c0c89ccd9c16f2a29d47eb8414aacd5 8268151: Vector API toShuffle optimization Reviewed-by: psandoz, vlivanov ! src/hotspot/share/opto/vector.cpp ! src/hotspot/share/opto/vectorIntrinsics.cpp ! src/hotspot/share/opto/vectornode.cpp ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/DoubleMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/DoubleVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/FloatMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/FloatVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/IntMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/IntVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/LongMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/LongVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ShortMaxVector.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 ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-VectorBits.java.template Changeset: 48dc72b7 Author: Vladimir Kozlov Date: 2021-06-04 20:10:59 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/48dc72b74d6b4b7b8fb605b62fc0057b5f4652e1 8268272: Remove JDK-8264874 changes because Graal was removed. Reviewed-by: erikj ! make/Main.gmk Changeset: 4e6748c5 Author: Yi Yang Date: 2021-06-04 23:29:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4e6748c543fae89b5f5f42bb0345b4b4f97d817a 8267687: ModXNode::Ideal optimization is better than Parse::do_irem Reviewed-by: neliasso, kvn ! src/hotspot/share/opto/parse.hpp ! src/hotspot/share/opto/parse2.cpp + test/micro/org/openjdk/bench/vm/compiler/ModPowerOf2.java Changeset: 76b54a19 Author: Nick Gasson Date: 2021-06-04 23:55:12 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/76b54a19955cd93f071cf1fb45c6d01bb57b84eb 8263512: [macos_aarch64] issues with calling va_args functions from invoke_native Reviewed-by: jvernee ! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/CABI.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/PlatformLayouts.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/SystemLookup.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/SharedUtils.java - src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/aarch64/AArch64Linker.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/aarch64/CallArranger.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/aarch64/TypeClass.java + src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/aarch64/linux/LinuxAArch64Linker.java = src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/aarch64/linux/LinuxAArch64VaList.java + src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/aarch64/macos/MacOsAArch64Linker.java + src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/aarch64/macos/MacOsAArch64VaList.java ! test/jdk/ProblemList.txt ! test/jdk/java/foreign/valist/VaListTest.java ! test/jdk/java/foreign/valist/libVaList.c Changeset: 6ff978ac Author: Jonathan Gibbons Date: 2021-06-05 00:05:17 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6ff978ac16e631ebded7964d89ac42fd0452b1d3 8267204: Expose access to underlying streams in Reporter Reviewed-by: prappo ! src/jdk.javadoc/share/classes/jdk/javadoc/doclet/Reporter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/Messages.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/Messager.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/Start.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/ToolEnvironment.java ! test/langtools/jdk/javadoc/doclet/testDiagsLineCaret/TestDiagsLineCaret.java + test/langtools/jdk/javadoc/doclet/testReporterStreams/TestReporterStreams.java ! test/langtools/jdk/javadoc/lib/javadoc/tester/JavadocTester.java ! test/langtools/jdk/javadoc/tool/EnsureNewOldDoclet.java ! test/langtools/jdk/javadoc/tool/api/basic/GetTask_DiagListenerTest.java Changeset: 7e41ca3d Author: Yasumasa Suenaga Date: 2021-06-05 00:07:04 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7e41ca3da820650e16d9ca7f5b188628cd666419 8266957: SA has not followed JDK-8220587 and JDK-8224965 Reviewed-by: cjplummer, sspitsyn ! src/hotspot/share/gc/z/vmStructs_z.cpp ! src/hotspot/share/gc/z/vmStructs_z.hpp ! src/hotspot/share/gc/z/zAttachedArray.hpp ! src/hotspot/share/gc/z/zForwardingEntry.hpp ! src/hotspot/share/gc/z/zForwardingTable.hpp ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZAddress.java + src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZAttachedArrayForForwarding.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZBarrier.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZCollectedHeap.java + src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZForwarding.java + src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZForwardingEntry.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZForwardingTable.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZGlobals.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZGlobalsForVMStructs.java + src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZGranuleMapForForwarding.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZHash.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZHeap.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZOop.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZPage.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZPageTable.java + src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZRelocate.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZUtils.java ! test/hotspot/jtreg/ProblemList-zgc.txt Changeset: 7f55dc15 Author: Sibabrata Sahoo Date: 2021-06-05 07:56:14 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7f55dc15769bbab59024aa49671bced633de40ed 8179880: Refactor javax/security shell tests to plain java tests Reviewed-by: weijun ! test/jdk/javax/security/auth/Subject/doAs/Test.java - test/jdk/javax/security/auth/Subject/doAs/Test.sh Changeset: 6c838c56 Author: Stephen Colebourne Committer: Roger Riggs Date: 2021-06-05 13:26:52 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6c838c568c2c99145fd0ae8059de2b2865b65863 8266846: Add java.time.InstantSource Reviewed-by: rriggs, naoto, darcy ! src/java.base/share/classes/java/time/Clock.java ! src/java.base/share/classes/java/time/Instant.java + src/java.base/share/classes/java/time/InstantSource.java ! test/jdk/java/time/test/TEST.properties ! test/jdk/java/time/test/java/time/TestClock_System.java + test/jdk/java/time/test/java/time/TestInstantSource.java Changeset: 36bff6f9 Author: Andrey Turbanov Committer: Jim Laskey Date: 2021-06-05 14:44:25 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/36bff6f945a1eb6b1bbe21070a345df50095e918 8066694: Strange code in JavacParser.java Reviewed-by: vromero, iris ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java Changeset: 91f9adc5 Author: Ioi Lam Date: 2021-06-05 15:22:38 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/91f9adc5f55b42d30e46d99e22a8d0567fa5c146 8268139: CDS ArchiveBuilder may reference unloaded classes Reviewed-by: coleenp, ccheung ! src/hotspot/share/cds/dynamicArchive.cpp ! src/hotspot/share/cds/metaspaceShared.cpp ! src/hotspot/share/classfile/systemDictionaryShared.cpp ! src/hotspot/share/classfile/systemDictionaryShared.hpp Changeset: b2e9eb9e Author: Sergey Bylokhov Date: 2021-06-05 15:41:04 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b2e9eb9e47beb5148e3b9f86f25fad352ed4a236 8268087: Update documentation of the JPasswordField Reviewed-by: trebari, azvegint, prr ! src/java.desktop/share/classes/javax/swing/JPasswordField.java Changeset: f768fbf7 Author: Daniel D. Daugherty Date: 2021-06-05 15:50:18 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f768fbf7a9df6eae10298ba6bd1b4ae438ca298d 8268286: ProblemList serviceability/sa/TestJmapCore.java on linux-aarch64 with ZGC Reviewed-by: rriggs ! test/hotspot/jtreg/ProblemList-zgc.txt Changeset: b05c40ca Author: Jatin Bhateja Date: 2021-06-05 18:07:14 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b05c40ca3b5fd34cbbc7a9479b108a4ff2c099f1 8266951: Partial in-lining for vectorized mismatch operation using AVX512 masked instructions Reviewed-by: psandoz, vlivanov ! 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/vm_version_x86.cpp ! src/hotspot/cpu/x86/x86.ad ! src/hotspot/share/adlc/formssel.cpp ! src/hotspot/share/opto/arraycopynode.cpp ! src/hotspot/share/opto/c2_globals.hpp ! src/hotspot/share/opto/castnode.hpp ! src/hotspot/share/opto/classes.hpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/opto/macroArrayCopy.cpp ! src/hotspot/share/opto/matcher.cpp ! src/hotspot/share/opto/vectornode.cpp ! src/hotspot/share/opto/vectornode.hpp ! test/hotspot/jtreg/compiler/arraycopy/TestArrayCopyConjoint.java ! test/hotspot/jtreg/compiler/arraycopy/TestArrayCopyDisjoint.java + test/hotspot/jtreg/compiler/intrinsics/VectorizedMismatchTest.java ! test/jtreg-ext/requires/VMProps.java + test/micro/org/openjdk/bench/java/util/ArraysMismatchPartialInlining.java Changeset: 8abf36c6 Author: Jatin Bhateja Date: 2021-06-06 02:31:18 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8abf36c6484bca20d1c31476f4d6f553aeeadb27 8268289: build failure due to missing signed flag in x86 evcmpb instruction Reviewed-by: vlivanov, jiefu ! src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp Changeset: 042f0bdb Author: Tejpal Rebari Date: 2021-06-06 04:08:05 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/042f0bdb3568edab4f96b9f7c83cbb0f90db7f18 8256465: [macos] Java frame and dialog presented full screen freeze application Reviewed-by: kcr, serb, prr ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/java.desktop/macosx/native/libawt_lwawt/awt/AWTWindow.m + test/jdk/java/awt/Window/TestAppFreeze.java Changeset: 52d88ee1 Author: Jie Fu Date: 2021-06-06 13:53:29 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/52d88ee1d1e0f6b9927db03a2b0bff75e4be03a2 8268292: compiler/intrinsics/VectorizedMismatchTest.java fails with release VMs Reviewed-by: dcubed ! test/hotspot/jtreg/compiler/intrinsics/VectorizedMismatchTest.java Changeset: 95ddf7d6 Author: Hamlin Li Date: 2021-06-07 01:19:32 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/95ddf7d6ada599e57feefca7fa9c6379e6a23523 8267839: trivial mem leak in numa Co-authored-by: Shoubing Ma Reviewed-by: tschatzl, sjohanss ! src/hotspot/os/linux/os_linux.hpp Changeset: b05fa02e Author: Hui Shi Committer: Jie Fu Date: 2021-06-07 01:34:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b05fa02e7413fdcc40969645309e3e9d4442c78d 8267904: C2 crash when compile negative Arrays.copyOf length after loop Reviewed-by: roland, kvn ! src/hotspot/share/opto/callnode.cpp ! src/hotspot/share/opto/graphKit.cpp ! src/hotspot/share/opto/library_call.cpp + test/hotspot/jtreg/compiler/c2/TestNegativeArrayCopyAfterLoop.java Changeset: 2aeeeb40 Author: Xin Liu Committer: Jie Fu Date: 2021-06-07 06:12:04 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2aeeeb40a06c0c71537ce7de2e00bab9faf817a9 8268279: gc/shenandoah/compiler/TestLinkToNativeRBP.java fails after LibraryLookup is gone Reviewed-by: zgu, jiefu ! test/hotspot/jtreg/gc/shenandoah/compiler/TestLinkToNativeRBP.java Changeset: 204b4929 Author: Stefan Johansson Date: 2021-06-07 06:22:11 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/204b4929f7251feec6736aed9489ff82cd5dd744 8267703: runtime/cds/appcds/cacheObject/HeapFragmentationTest.java crashed with OutOfMemory Reviewed-by: tschatzl, kbarrett ! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp ! src/hotspot/share/gc/g1/g1FullCollector.cpp Changeset: 3e482440 Author: Hui Shi Committer: Jie Fu Date: 2021-06-07 06:26:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3e48244084ef90fb7f46cdfd691ae9f0ecb2de41 8268301: Closed test: compiler/c2/6371167/Test.java fails after JDK-8267904 Reviewed-by: kvn, dlong ! src/hotspot/share/opto/callnode.cpp ! src/hotspot/share/opto/graphKit.cpp ! src/hotspot/share/opto/library_call.cpp - test/hotspot/jtreg/compiler/c2/TestNegativeArrayCopyAfterLoop.java Changeset: 908aca29 Author: Jan Lahoda Date: 2021-06-07 07:01:30 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/908aca29ca60f5f251df8c6a31b2543929be12fc 8262891: Compiler implementation for Pattern Matching for switch (Preview) Co-authored-by: Brian Goetz Co-authored-by: Mandy Chung Co-authored-by: Jan Lahoda Reviewed-by: mcimadamore, forax, godin, psandoz, mchung ! make/CompileInterimLangtools.gmk + src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java + src/java.base/share/classes/jdk/internal/javac/NoPreview.java ! src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java + src/jdk.compiler/share/classes/com/sun/source/tree/CaseLabelTree.java ! src/jdk.compiler/share/classes/com/sun/source/tree/CaseTree.java + src/jdk.compiler/share/classes/com/sun/source/tree/DefaultCaseLabelTree.java ! src/jdk.compiler/share/classes/com/sun/source/tree/ExpressionTree.java + src/jdk.compiler/share/classes/com/sun/source/tree/GuardedPatternTree.java + src/jdk.compiler/share/classes/com/sun/source/tree/ParenthesizedPatternTree.java ! src/jdk.compiler/share/classes/com/sun/source/tree/PatternTree.java ! src/jdk.compiler/share/classes/com/sun/source/tree/Tree.java ! src/jdk.compiler/share/classes/com/sun/source/tree/TreeVisitor.java ! src/jdk.compiler/share/classes/com/sun/source/util/SimpleTreeVisitor.java ! src/jdk.compiler/share/classes/com/sun/source/util/TreeScanner.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Preview.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/MatchBindingsComputer.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransTypes.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TreeDiffer.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/CRTable.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeCopier.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeScanner.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeTranslator.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java + test/jdk/java/lang/runtime/SwitchBootstrapsTest.java ! test/langtools/tools/javac/classfiles/attributes/LineNumberTable/LineNumberTestBase.java + test/langtools/tools/javac/classfiles/attributes/LineNumberTable/RuleSwitchBreaks.java ! test/langtools/tools/javac/classfiles/attributes/LineNumberTable/TestCase.java ! test/langtools/tools/javac/diags/examples/CantRefNonEffectivelyFinalVar.java + test/langtools/tools/javac/diags/examples/CaseNull.java + test/langtools/tools/javac/diags/examples/ConstantLabelNotCompatible.java + test/langtools/tools/javac/diags/examples/DuplicateTotalPattern.java + test/langtools/tools/javac/diags/examples/FlowsThroughFromPattern.java + test/langtools/tools/javac/diags/examples/FlowsThroughToPattern.java + test/langtools/tools/javac/diags/examples/NotExhaustiveStatement.java + test/langtools/tools/javac/diags/examples/PatternDominated.java + test/langtools/tools/javac/diags/examples/PatternSwitch.java - test/langtools/tools/javac/diags/examples/SwitchNullNotAllowed.java + test/langtools/tools/javac/diags/examples/TotalPatternAndDefault.java ! test/langtools/tools/javac/lib/DPrinter.java + test/langtools/tools/javac/patterns/CaseDefault.java + test/langtools/tools/javac/patterns/CaseDefault.out + test/langtools/tools/javac/patterns/DisambiguateParenthesizedPattern.java + test/langtools/tools/javac/patterns/Domination.java + test/langtools/tools/javac/patterns/Domination.out + test/langtools/tools/javac/patterns/Exhaustiveness.java + test/langtools/tools/javac/patterns/Guards.java + test/langtools/tools/javac/patterns/GuardsErrors.java + test/langtools/tools/javac/patterns/GuardsErrors.out + test/langtools/tools/javac/patterns/NullSwitch.java + test/langtools/tools/javac/patterns/Parenthesized.java + test/langtools/tools/javac/patterns/SealedTypeChanges.java + test/langtools/tools/javac/patterns/SealedTypeChanges2.java + test/langtools/tools/javac/patterns/SimpleAndGuardPattern.java + test/langtools/tools/javac/patterns/SwitchErrors.java + test/langtools/tools/javac/patterns/SwitchErrors.out + test/langtools/tools/javac/patterns/Switches.java + test/langtools/tools/javac/stackmap/OrdinarySwitchStackMapTest.java ! test/langtools/tools/javac/switchextra/SwitchNoExtraTypes.out ! test/langtools/tools/javac/switchextra/SwitchObject.out + test/langtools/tools/javac/switchnull/SwitchNull.java + test/langtools/tools/javac/switchnull/SwitchNullDisabled-preview.out ! test/langtools/tools/javac/switchnull/SwitchNullDisabled.java ! test/langtools/tools/javac/switchnull/SwitchNullDisabled.out ! test/langtools/tools/javac/tree/SourceTreeScannerTest.java ! test/langtools/tools/jdeps/listdeps/ListModuleDeps.java Changeset: 9fc914b9 Author: Leo Korinth Date: 2021-06-07 08:02:26 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9fc914b96321c24e14f1b52246df0b816cb7dafa 8204686: Dynamic parallel reference processing support for Parallel GC Reviewed-by: ayang, tschatzl, kbarrett ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/parallel/parallelArguments.cpp ! src/hotspot/share/gc/parallel/psScavenge.cpp ! src/hotspot/share/gc/shared/referenceProcessor.cpp ! src/hotspot/share/gc/shared/referenceProcessor.hpp ! test/hotspot/jtreg/gc/arguments/TestParallelRefProc.java Changeset: 58bdabcd Author: Albert Mingkun Yang Date: 2021-06-07 08:20:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/58bdabcd40cc8895d5fd829ad3515ab418245c16 8268164: Adopt cast notation for WorkerThread conversions Reviewed-by: stefank, dholmes ! src/hotspot/share/gc/shared/referenceProcessor.cpp ! src/hotspot/share/runtime/nonJavaThread.hpp ! src/hotspot/share/runtime/thread.hpp ! src/hotspot/share/runtime/thread.inline.hpp Changeset: 6d1f3ac7 Author: Hannes Walln?fer Date: 2021-06-07 08:43:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6d1f3ac74914db662d2a39a5b69d8b8143d2f3ef 8149138: [javadoc] Fix SerialFormBuilder eliminate String bashing Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlSerialFieldWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/SerializedFormWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/SerializedFormBuilder.java ! test/langtools/jdk/javadoc/doclet/testSerializedForm/SerializedForm.java ! test/langtools/jdk/javadoc/doclet/testSerializedForm/TestSerializedForm.java Changeset: 5ebd4199 Author: Erik ?sterlund Date: 2021-06-07 09:44:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5ebd4199cc57b60ab7345a019d000c0017a90fc3 8267972: Inline cache cleaning is not monotonic Reviewed-by: vlivanov, kvn ! src/hotspot/share/code/compiledIC.cpp Changeset: b09d8b98 Author: Xin Liu Committer: David Holmes Date: 2021-06-07 10:19:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b09d8b9800329f946df80026d61cd4abf41cff37 8267926: AsyncLogGtest.java fails on assert with: decorator was not part of the decorator set specified at creation. Reviewed-by: dholmes, phh ! src/hotspot/share/logging/logDecorations.hpp ! test/hotspot/jtreg/ProblemList.txt Changeset: 8130be56 Author: David Holmes Date: 2021-06-07 10:23:12 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8130be561b76906be660e6d779839eb197bd7486 8268318: Missing comma in copyright header Reviewed-by: stefank ! test/langtools/jdk/javadoc/doclet/testSerializedForm/SerializedForm.java Changeset: e4d04540 Author: Jan Lahoda Date: 2021-06-07 11:13:13 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e4d045402fa1992a1d91586bd4f67362d07f543c 8267832: SimpleVisitors and Scanners in jdk.compiler should use @implSpec Reviewed-by: prappo, darcy ! src/jdk.compiler/share/classes/com/sun/source/util/DocTreeScanner.java ! src/jdk.compiler/share/classes/com/sun/source/util/SimpleDocTreeVisitor.java ! src/jdk.compiler/share/classes/com/sun/source/util/SimpleTreeVisitor.java ! src/jdk.compiler/share/classes/com/sun/source/util/TreeScanner.java Changeset: 15715a89 Author: Thomas Schatzl Date: 2021-06-07 13:18:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/15715a8984e3e346c2a65e5a0c7b48c4dee21d3e 8267924: Misleading G1 eager reclaim detail logging Reviewed-by: ayang, sjohanss ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.cpp ! test/hotspot/jtreg/gc/g1/TestG1TraceEagerReclaimHumongousObjects.java Changeset: 728a411a Author: Hamlin Li Date: 2021-06-07 13:41:44 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/728a411a541f93121bbd7db4258859196bcf6cdf 8268018: remove dead code in commitLimitter Reviewed-by: zgu ! src/hotspot/share/memory/metaspace/commitLimiter.hpp Changeset: 4f9d6b7d Author: Vicente Romero Date: 2021-06-07 13:57:15 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4f9d6b7d68312860d3e184a1f33687e1693d7d87 8267465: remove superfluous preview related annotations and test options Reviewed-by: jlahoda ! src/jdk.compiler/share/classes/com/sun/source/util/TreeScanner.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacRoundEnvironment.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/processing/PrintingProcessor.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/comp/PubapiVisitor.java ! test/langtools/jdk/jshell/SealedClassesTest.java ! test/langtools/tools/javac/annotations/repeatingAnnotations/NoTargetOnContainer.java ! test/langtools/tools/javac/annotations/repeatingAnnotations/NoTargetOnContainer2.java ! test/langtools/tools/javac/annotations/typeAnnotations/classfile/CombinationsTargetTest2.java ! test/langtools/tools/javac/annotations/typeAnnotations/classfile/Patterns.java ! test/langtools/tools/javac/api/TestGetElementReference.java ! test/langtools/tools/javac/api/TestGetScopeResult.java ! test/langtools/tools/javac/api/lambdaErrorRecovery/TestGetTypeMirrorReference.java ! test/langtools/tools/javac/diags/examples/IllegalStartOfStmt.java ! test/langtools/tools/javac/lambda/deduplication/DeduplicationTest.java ! test/langtools/tools/javac/parser/JavacParserTest.java ! test/langtools/tools/javac/processing/model/element/AnnoProcessorOnRecordsTest.java ! test/langtools/tools/javac/processing/model/element/CheckingTypeAnnotationsOnRecords.java ! test/langtools/tools/javac/processing/model/element/ErrorOnAnnoWithTargetMethod.java ! test/langtools/tools/javac/processing/model/element/RecordNotPreservingNestedTypeAnnotationsTest.java ! test/langtools/tools/javac/processing/model/element/TestBindingVariable.java ! test/langtools/tools/javac/processing/model/element/TestRecord.java ! test/langtools/tools/javac/processing/model/element/TestRecordDesugar.java ! test/langtools/tools/javac/processing/model/element/repeatingAnnotations/RepeatingAnnotationsOnRecords.java ! test/langtools/tools/javac/sealed/BinaryCompatibilityTests.java ! test/langtools/tools/javac/sealed/CheckSubtypesOfSealedTest.java ! test/langtools/tools/javac/sealed/SealedCompilationTests.java ! test/langtools/tools/javac/sealed/T8258662/T8258662.java ! test/langtools/tools/javac/warnings/DefaultCtor/NoWarningRecord.java Changeset: a91f9712 Author: Weijun Wang Date: 2021-06-07 13:58:49 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a91f97126646f89d8c5b81cfd40820338c769acd 8268267: Remove -Djavatest.security.noSecurityManager=true from jtreg runs Reviewed-by: lancea, jjg, erikj ! make/RunTests.gmk ! test/langtools/ProblemList.txt Changeset: ea8274fb Author: Zhengyu Gu Date: 2021-06-07 14:00:19 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ea8274fbf07d7308bcef5aacbe553dc7b37887e3 8267875: Shenandoah: Duplicated code in ShenandoahBarrierSetC2::ideal_node() Reviewed-by: rkennke, roland ! src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.cpp Changeset: 270ec975 Author: Thomas Schatzl Date: 2021-06-07 14:09:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/270ec975b69d4e9a73571c4ba21b705e48d3e1b4 8268331: Fix crash in humongous object eager reclaim logging Reviewed-by: sjohanss ! src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.cpp Changeset: 3396b69f Author: Christian Hagedorn Date: 2021-06-07 14:11:50 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3396b69fc91db4a9e29806562215f92179ba4757 8254129: IR Test Framework to support regex-based matching on the IR in JTreg compiler tests Co-authored-by: Christian Hagedorn Co-authored-by: Tobias Hartmann Reviewed-by: iignatyev + test/hotspot/jtreg/compiler/lib/ir_framework/AbstractInfo.java + test/hotspot/jtreg/compiler/lib/ir_framework/Argument.java + test/hotspot/jtreg/compiler/lib/ir_framework/Arguments.java + test/hotspot/jtreg/compiler/lib/ir_framework/Check.java + test/hotspot/jtreg/compiler/lib/ir_framework/CheckAt.java + test/hotspot/jtreg/compiler/lib/ir_framework/CompLevel.java + test/hotspot/jtreg/compiler/lib/ir_framework/Compiler.java + test/hotspot/jtreg/compiler/lib/ir_framework/DontCompile.java + test/hotspot/jtreg/compiler/lib/ir_framework/DontInline.java + test/hotspot/jtreg/compiler/lib/ir_framework/ForceCompile.java + test/hotspot/jtreg/compiler/lib/ir_framework/ForceCompileClassInitializer.java + test/hotspot/jtreg/compiler/lib/ir_framework/ForceInline.java + test/hotspot/jtreg/compiler/lib/ir_framework/IR.java + test/hotspot/jtreg/compiler/lib/ir_framework/IRNode.java + test/hotspot/jtreg/compiler/lib/ir_framework/IRs.java + test/hotspot/jtreg/compiler/lib/ir_framework/README.md + test/hotspot/jtreg/compiler/lib/ir_framework/Run.java + test/hotspot/jtreg/compiler/lib/ir_framework/RunInfo.java + test/hotspot/jtreg/compiler/lib/ir_framework/RunMode.java + test/hotspot/jtreg/compiler/lib/ir_framework/Scenario.java + test/hotspot/jtreg/compiler/lib/ir_framework/Test.java + test/hotspot/jtreg/compiler/lib/ir_framework/TestFramework.java + test/hotspot/jtreg/compiler/lib/ir_framework/TestInfo.java + test/hotspot/jtreg/compiler/lib/ir_framework/Warmup.java + test/hotspot/jtreg/compiler/lib/ir_framework/driver/FlagVMProcess.java + test/hotspot/jtreg/compiler/lib/ir_framework/driver/IRMatcher.java + test/hotspot/jtreg/compiler/lib/ir_framework/driver/IRMethod.java + test/hotspot/jtreg/compiler/lib/ir_framework/driver/IRViolationException.java + test/hotspot/jtreg/compiler/lib/ir_framework/driver/TestVMException.java + test/hotspot/jtreg/compiler/lib/ir_framework/driver/TestVMProcess.java + test/hotspot/jtreg/compiler/lib/ir_framework/flag/FlagVM.java + test/hotspot/jtreg/compiler/lib/ir_framework/shared/CheckedTestFrameworkException.java + test/hotspot/jtreg/compiler/lib/ir_framework/shared/NoTestsRunException.java + test/hotspot/jtreg/compiler/lib/ir_framework/shared/ParsedComparator.java + test/hotspot/jtreg/compiler/lib/ir_framework/shared/TestFormat.java + test/hotspot/jtreg/compiler/lib/ir_framework/shared/TestFormatException.java + test/hotspot/jtreg/compiler/lib/ir_framework/shared/TestFrameworkException.java + test/hotspot/jtreg/compiler/lib/ir_framework/shared/TestFrameworkSocket.java + test/hotspot/jtreg/compiler/lib/ir_framework/shared/TestRun.java + test/hotspot/jtreg/compiler/lib/ir_framework/shared/TestRunException.java + test/hotspot/jtreg/compiler/lib/ir_framework/test/AbstractTest.java + test/hotspot/jtreg/compiler/lib/ir_framework/test/ArgumentValue.java + test/hotspot/jtreg/compiler/lib/ir_framework/test/BaseTest.java + test/hotspot/jtreg/compiler/lib/ir_framework/test/CheckedTest.java + test/hotspot/jtreg/compiler/lib/ir_framework/test/CustomRunTest.java + test/hotspot/jtreg/compiler/lib/ir_framework/test/DeclaredTest.java + test/hotspot/jtreg/compiler/lib/ir_framework/test/IREncodingPrinter.java + test/hotspot/jtreg/compiler/lib/ir_framework/test/TestVM.java + test/hotspot/jtreg/testlibrary_tests/ir_framework/examples/BaseTestExample.java + test/hotspot/jtreg/testlibrary_tests/ir_framework/examples/CheckedTestExample.java + test/hotspot/jtreg/testlibrary_tests/ir_framework/examples/CustomRunTestExample.java + test/hotspot/jtreg/testlibrary_tests/ir_framework/examples/IRExample.java + test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/README.md + test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestAccessModifiers.java + test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestBadFormat.java + test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestBasics.java + test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestCompLevels.java + test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestControls.java + test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestDFlags.java + test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestDIgnoreCompilerControls.java + test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestDScenarios.java + test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestDTestAndExclude.java + test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestIRMatching.java + test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestRunTests.java + test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestSanity.java + test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestScenarios.java + test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestWithHelperClasses.java Changeset: e663ba96 Author: Joe Darcy Date: 2021-06-07 17:03:50 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e663ba961f25c83758815bbfce97a58d9560c7a2 8268299: jvms tag produces incorrect URL Reviewed-by: iris, erikj, jjg ! make/jdk/src/classes/build/tools/taglet/JSpec.java Changeset: 7e55569e Author: Alexey Ushakov Date: 2021-06-07 17:36:52 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7e55569edee84dcae63fbdf1f89fefa554360736 8261549: Adjust memory size in MTLTexurePool.m Reviewed-by: prr ! src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLTexurePool.m Changeset: 81600dce Author: Roger Riggs Date: 2021-06-07 17:41:09 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/81600dce24903cbd3476830e302c9f182c85efb3 8191441: (Process) add Readers and Writer access to java.lang.Process streams Reviewed-by: naoto, alanb ! src/java.base/share/classes/java/lang/Process.java + test/jdk/java/lang/ProcessBuilder/ReaderWriterTest.java Changeset: e546ae27 Author: Liam Miller-Cushon Date: 2021-06-07 17:58:57 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e546ae27ffc6c19ae078a41ab6e1741a104958c1 8268296: ScopedMemoryAccess build error with readonly filesystems Reviewed-by: erikj ! make/modules/java.base/gensrc/GensrcScopedMemoryAccess.gmk Changeset: c7c77fd3 Author: Anthony Scarpino Date: 2021-06-07 22:22:28 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c7c77fd32b1b1bc736ef3523456a2968447fc627 8255557: Decouple GCM from CipherCore Reviewed-by: valeriep ! src/java.base/share/classes/com/sun/crypto/provider/AESCipher.java ! src/java.base/share/classes/com/sun/crypto/provider/CipherCore.java ! src/java.base/share/classes/com/sun/crypto/provider/FeedbackCipher.java + src/java.base/share/classes/com/sun/crypto/provider/GCM.java ! src/java.base/share/classes/com/sun/crypto/provider/GCTR.java ! src/java.base/share/classes/com/sun/crypto/provider/GHASH.java ! src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java ! src/java.base/share/classes/com/sun/crypto/provider/SunJCE.java ! src/java.base/share/classes/sun/security/util/SecurityProviderConstants.java ! test/jdk/com/sun/crypto/provider/Cipher/AEAD/Encrypt.java ! test/jdk/com/sun/crypto/provider/Cipher/AEAD/GCMBufferTest.java + test/jdk/com/sun/crypto/provider/Cipher/AEAD/GCMShortBuffer.java ! test/jdk/com/sun/crypto/provider/Cipher/AEAD/OverlapByteBuffer.java ! test/jdk/com/sun/crypto/provider/Cipher/AES/TestAESCipher.java ! test/jdk/com/sun/crypto/provider/Cipher/AES/TestSameBuffer.java Changeset: 5e557d86 Author: Kevin Walls Date: 2021-06-07 22:26:13 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5e557d8650d81f9f81938892de28a6dd8fea98b0 8266967: debug.cpp utility find() should print Java Object fields. Reviewed-by: sspitsyn, coleenp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/instanceKlass.hpp ! src/hotspot/share/runtime/fieldDescriptor.cpp ! src/hotspot/share/runtime/fieldDescriptor.hpp Changeset: fc08af58 Author: Dan Smith Date: 2021-06-07 23:21:24 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fc08af58cb0571ed375a7937aac7a951ba224644 8174222: LambdaMetafactory: validate inputs and improve documentation Reviewed-by: mchung ! src/hotspot/share/include/jvm.h ! src/hotspot/share/prims/jvm.cpp ! src/java.base/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java ! src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java ! src/java.base/share/classes/java/lang/invoke/LambdaMetafactory.java ! src/java.base/share/classes/java/lang/invoke/LambdaProxyClassArchive.java ! src/java.base/share/native/libjava/LambdaProxyClassArchive.c + test/jdk/java/lang/invoke/lambda/MetafactoryArgValidationTest.java Changeset: 36c4e5f2 Author: Jonathan Gibbons Date: 2021-06-08 02:16:56 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/36c4e5f26477ed6bd17ac565d5301eba7d424058 8267187: Remove deprecated constructor for Log Reviewed-by: darcy, iris ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/Log.java Changeset: ae986bc8 Author: Alan Hayward Committer: Ningsheng Jian Date: 2021-06-08 02:24:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ae986bc8dff92a77e91e6ee640aa27c68abb8def 8266749: AArch64: Backtracing broken on PAC enabled systems Reviewed-by: gziemski, aph ! src/hotspot/cpu/aarch64/frame_aarch64.cpp ! src/hotspot/cpu/aarch64/frame_aarch64.hpp ! src/hotspot/cpu/aarch64/frame_aarch64.inline.hpp + src/hotspot/cpu/aarch64/pauth_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/windows_aarch64/pauth_windows_aarch64.inline.hpp Changeset: f40c89e8 Author: Thomas Stuefe Date: 2021-06-08 03:57:38 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f40c89e8e9fae26da53b5d820d8e64d9b30faf8c 8267209: Child threads should defer logging to after child-parent handshake Reviewed-by: dholmes, coleenp ! src/hotspot/os/bsd/os_bsd.cpp ! src/hotspot/os/linux/os_linux.cpp Changeset: 341f6760 Author: David Holmes Date: 2021-06-08 04:53:02 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/341f676066ab807d433f0f0b6c8356d2ad0e1cc9 8267908: linux: thread_native_entry can scribble on stack frame Reviewed-by: ysuenaga ! src/hotspot/os/linux/os_linux.cpp Changeset: 81bad590 Author: Aditya Mandaleeka Committer: Stefan Johansson Date: 2021-06-08 06:55:20 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/81bad5904284a251c65c8c86cc373d29974d0686 8257774: G1: Trigger collect when free region count drops below threshold to prevent evacuation failures Reviewed-by: sjohanss, tschatzl ! src/hotspot/share/gc/g1/g1AllocRegion.hpp ! src/hotspot/share/gc/g1/g1AllocRegion.inline.hpp ! src/hotspot/share/gc/g1/g1Allocator.hpp ! src/hotspot/share/gc/g1/g1Allocator.inline.hpp ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1CollectionSet.cpp ! src/hotspot/share/gc/g1/g1CollectionSet.hpp ! src/hotspot/share/gc/g1/g1Policy.cpp ! src/hotspot/share/gc/g1/g1Policy.hpp ! src/hotspot/share/gc/g1/g1VMOperations.cpp ! src/hotspot/share/gc/g1/g1VMOperations.hpp ! src/hotspot/share/gc/g1/g1_globals.hpp ! src/hotspot/share/gc/shared/gcCause.cpp ! src/hotspot/share/gc/shared/gcCause.hpp ! test/hotspot/jtreg/gc/g1/TestGCLogMessages.java Changeset: fd91b2aa Author: Koichi Sakata Committer: Christian Hagedorn Date: 2021-06-08 07:14:42 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fd91b2aa57e0b621d195a5ae025b84c858583251 8265440: IGV: make node selection more visible Reviewed-by: chagedorn, neliasso ! src/utils/IdealGraphVisualizer/View/src/main/java/com/sun/hotspot/igv/view/widgets/FigureWidget.java ! src/utils/IdealGraphVisualizer/View/src/main/java/com/sun/hotspot/igv/view/widgets/SlotWidget.java Changeset: 81054789 Author: Xin Liu Committer: Yasumasa Suenaga Date: 2021-06-08 07:20:13 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/81054789a32f29b06f0804e09aabd7cf17464778 8268165: AsyncLogging will crash if rotate() fails LogFileOutput::rotate() may leave _stream NULL because os::fopen() may return NULL due to space or inode limitations. AsyncLogWriter::write() calls LogFileOutput::write_blocking() without null check. Null check is added to prevent from crashing. Reviewed-by: ysuenaga ! src/hotspot/share/logging/logFileOutput.cpp Changeset: 00c88f79 Author: Matthias Baesken Date: 2021-06-08 07:22:03 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/00c88f79b30d7867be4a66317b90b9ba7e947f4f 8266918: merge_stack in check_code.c add NULL check Reviewed-by: rschmelter, clanger ! src/java.base/share/native/libverify/check_code.c Changeset: 61ab4b9d Author: Michael McMahon Date: 2021-06-08 07:58:54 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/61ab4b9d18e7c2eee6691f3ee00e5fecb866fdcd 8267564: JDK-8252971 causes SPECjbb2015 socket exceptions on Windows when MKS is installed Reviewed-by: alanb ! src/java.base/share/classes/sun/nio/ch/UnixDomainSockets.java ! src/java.base/unix/native/libnio/ch/UnixDomainSockets.c ! src/java.base/windows/native/libnio/ch/UnixDomainSockets.c Changeset: 89da2021 Author: Ajit Ghaisas Date: 2021-06-08 09:45:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/89da2021ee194efd70f367f8fec16994335c38aa 8266159: macOS ARM + Metal pipeline shows artifacts on Swing Menu with Java L&F Reviewed-by: jdv, prr ! src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/shaders.metal + test/jdk/java/awt/Graphics/DrawOvalTest.java Changeset: 2717fcb1 Author: Joel Borggr?n-Franck Date: 2021-06-08 10:51:19 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2717fcb1345379d9856a33148d548eccb7b708f4 8232948: javac -h should mangle the overload argument signature Reviewed-by: jjg ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/JNIWriter.java + test/langtools/tools/javac/nativeHeaders/EncodeInnerClassNameTest.java Changeset: 6843576c Author: Maurizio Cimadamore Date: 2021-06-08 14:02:28 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6843576c95a70bffad95df278d5f5be29371bca4 8268227: java/foreign/TestUpcall.java still times out Reviewed-by: dcubed ! test/jdk/java/foreign/TestDowncall.java ! test/jdk/java/foreign/TestUpcall.java Changeset: 8158b822 Author: Jorn Vernee Date: 2021-06-08 14:20:31 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8158b82269513a60c13bb10a6edfa82f806e8efc 8268327: Upstream: 8268169: The system lookup can not find stdio functions such as printf on Windows 10 Reviewed-by: erikj, sundar ! make/modules/jdk.incubator.foreign/Lib.gmk ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/SystemLookup.java + src/jdk.incubator.foreign/windows/native/libWinFallbackLookup/WinFallbackLookup.c ! test/jdk/java/foreign/StdLibTest.java - test/jdk/java/foreign/libStdLib.c Changeset: 159cb6fa Author: Nikita Gubarkov Committer: Alexey Ushakov Date: 2021-06-08 14:35:58 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/159cb6facc668acc30552665e46b18edf58c3a91 8268083: JDK-8267706 breaks bin/idea.sh on a Mac Reviewed-by: erikj ! bin/idea.sh ! make/common/Utils.gmk ! make/ide/idea/jdk/idea.gmk ! make/ide/idea/jdk/template/compiler.xml ! make/ide/idea/jdk/template/jdk.iml ! make/ide/idea/jdk/template/misc.xml ! make/ide/idea/jdk/template/module.iml ! make/ide/idea/jdk/template/test.iml ! make/ide/idea/jdk/template/vcs.xml ! make/ide/idea/jdk/template/workspace.xml ! test/make/TestMakeBase.gmk Changeset: c21cc932 Author: Ioi Lam Date: 2021-06-08 16:47:38 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c21cc932f0a217299689df6c2abcdbc629a668bf 8248877: Document API contract for MetaspaceObj subtypes Reviewed-by: coleenp, minqi ! src/hotspot/share/memory/allocation.hpp Changeset: b568e879 Author: Alex Menkov Date: 2021-06-08 17:05:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b568e87947a5d7f1d8c20e3e8a8b2b7f77265c8b 8237388: serviceability/dcmd/framework/VMVersionTest.java fails with connection refused error. Reviewed-by: cjplummer, sspitsyn ! test/hotspot/jtreg/serviceability/dcmd/framework/TestProcessLauncher.java ! test/hotspot/jtreg/serviceability/dcmd/framework/process/TestJavaProcess.java ! test/hotspot/jtreg/vmTestbase/nsk/share/jpda/IOPipe.java ! test/hotspot/jtreg/vmTestbase/nsk/share/jpda/SocketConnection.java ! test/hotspot/jtreg/vmTestbase/nsk/share/jpda/SocketIOPipe.java Changeset: fafc4d97 Author: Jonathan Gibbons Date: 2021-06-08 17:23:17 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fafc4d976434c196c16b652c859073c5888b992e 8268352: Rename javadoc Messager class to JavadocLog Reviewed-by: prappo ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/ElementsTable.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/JavadocEnter.java = src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/JavadocLog.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/JavadocTool.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/Start.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/ToolEnvironment.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/ToolOptions.java ! test/langtools/jdk/javadoc/tool/CheckResourceKeys.java ! test/langtools/jdk/javadoc/tool/api/basic/JavadocTaskImplTest.java Changeset: dc6c96bb Author: Hannes Walln?fer Date: 2021-06-08 18:22:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/dc6c96bbaf1c0af3eacaa2e59646ed7c5bb0767d 8263468: New page for "recent" new API Reviewed-by: erikj, jjg ! make/Docs.gmk ! make/autoconf/jdk-version.m4 ! make/autoconf/spec.gmk.in ! make/conf/version-numbers.conf ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Contents.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/DeprecatedListWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HelpWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlConfiguration.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDoclet.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/Navigation.java + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/NewAPIListWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PreviewListWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SummaryListWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Table.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlStyle.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 ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/DeprecatedAPIListBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/DocPaths.java + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/NewAPIBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/PreviewAPIListBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/SummaryAPIListBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java ! test/langtools/jdk/javadoc/doclet/testDeprecatedDocs/TestDeprecatedDocs.java ! test/langtools/jdk/javadoc/doclet/testHtmlTableStyles/TestHtmlTableStyles.java ! test/langtools/jdk/javadoc/doclet/testHtmlTableTags/TestHtmlTableTags.java ! test/langtools/jdk/javadoc/doclet/testModules/TestModules.java + test/langtools/jdk/javadoc/doclet/testNewApiList/TestNewApiList.java + test/langtools/jdk/javadoc/doclet/testNewApiList/mdl/module-info.java + test/langtools/jdk/javadoc/doclet/testNewApiList/mdl/pkg/TestAnnotation.java + test/langtools/jdk/javadoc/doclet/testNewApiList/mdl/pkg/TestClass.java + test/langtools/jdk/javadoc/doclet/testNewApiList/mdl/pkg/TestEnum.java + test/langtools/jdk/javadoc/doclet/testNewApiList/mdl/pkg/TestError.java + test/langtools/jdk/javadoc/doclet/testNewApiList/mdl/pkg/TestException.java + test/langtools/jdk/javadoc/doclet/testNewApiList/mdl/pkg/TestInterface.java + test/langtools/jdk/javadoc/doclet/testNewApiList/mdl/pkg/TestRecord.java + test/langtools/jdk/javadoc/doclet/testNewApiList/mdl/pkg/package-info.java + test/langtools/jdk/javadoc/doclet/testNewApiList/pkg/TestClass.java ! test/langtools/jdk/javadoc/doclet/testRecordTypes/TestRecordTypes.java Changeset: 4dd0e7e7 Author: Hannes Walln?fer Date: 2021-06-08 18:49:31 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4dd0e7e78aab23e5c98f3457dd6c14788780becd 8259806: Clean up terminology on the "All Classes" page Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AllClassesIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Contents.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HelpWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlIndexBuilder.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/resources/doclets.properties ! test/langtools/jdk/javadoc/doclet/testModules/TestModules.java ! test/langtools/jdk/javadoc/doclet/testPackagePage/TestPackagePage.java ! test/langtools/jdk/javadoc/doclet/testSearch/TestSearch.java ! test/langtools/jdk/javadoc/doclet/testUnnamedPackage/TestUnnamedPackage.java Changeset: f9b593d6 Author: Hannes Walln?fer Date: 2021-06-08 19:21:21 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f9b593d668147979a16e743fe138d4e447e8232b 8266748: Move modifiers code to Signatures.java Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Signatures.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/ClassWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/ClassBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java Changeset: 51e8201e Author: Andy Herrick Date: 2021-06-08 19:46:40 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/51e8201eb5a66a8fbbff21194fd35389343baee1 8267764: jpackage cannot handle window screensaver files when EXE renamed as SCR Reviewed-by: asemenyuk, almatvee ! src/jdk.jpackage/windows/native/common/WinFileUtils.cpp + test/jdk/tools/jpackage/windows/WinRenameTest.java Changeset: 7a378165 Author: Joe Darcy Date: 2021-06-08 20:21:26 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7a37816548b913494b9671df9469b159cc62ae73 8264866: Remove unneeded WorkArounds.isAutomaticModule Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/WorkArounds.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Extern.java Changeset: 5ad4a91c Author: Zhengyu Gu Date: 2021-06-08 20:31:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5ad4a91c3d89f7118a99e5bd56fc86a9a6d57abf 8268127: Shenandoah: Heap size may be too small for region to align to large page size Reviewed-by: rkennke, shade ! src/hotspot/share/gc/shenandoah/shenandoahArguments.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.hpp Changeset: ae160529 Author: Jiangli Zhou Date: 2021-06-08 20:35:40 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ae16052951fbff21abf02271b761055cd2eed14b 8268088: Clarify Method::clear_jmethod_ids() related comments in ClassLoaderData::~ClassLoaderData() Reviewed-by: iklam ! src/hotspot/share/classfile/classLoaderData.cpp Changeset: bcaa2cb1 Author: Alexey Semenyuk Date: 2021-06-08 22:21:40 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bcaa2cb154ae5d23a067f6e38a19a21eef8fe8e8 8264144: Add handling of "--about-url" CLI parameter for RPM/DEB packages Reviewed-by: herrick, almatvee ! src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxDebBundler.java ! src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxRpmBundler.java ! src/jdk.jpackage/linux/classes/jdk/jpackage/internal/resources/template.control ! src/jdk.jpackage/linux/classes/jdk/jpackage/internal/resources/template.spec + test/jdk/tools/jpackage/linux/AppAboutUrlTest.java Changeset: f6f82c31 Author: Sergey Bylokhov Date: 2021-06-09 00:14:40 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f6f82c31689e68f4263bbbe2314033d69f9049f5 8266421: Deadlock in Sound System Reviewed-by: prr, azvegint ! src/java.desktop/share/classes/com/sun/media/sound/AbstractDataLine.java ! src/java.desktop/share/classes/com/sun/media/sound/AbstractLine.java ! src/java.desktop/share/classes/com/sun/media/sound/DirectAudioDevice.java + test/jdk/javax/sound/sampled/Clip/SetPositionHang.java Changeset: 1c3932f3 Author: Joe Wang Date: 2021-06-09 00:34:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1c3932f3d5ec47678f55769cb6a9f657ace411c6 8264766: ClassCastException during template compilation (Variable cannot be cast to Param) Reviewed-by: naoto ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/SymbolTable.java + test/jaxp/javax/xml/jaxp/unittest/transform/SymbolTableTest.java Changeset: 58a59e3d Author: Jack Hartstein Committer: Jamil Nimeh Date: 2021-06-09 02:12:25 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/58a59e3dcb830211e1eef8122c9f7113c00ded4c 8240997: Remove more "hack" word in security codes Reviewed-by: xuelei ! src/java.base/share/classes/sun/security/rsa/RSAPSSSignature.java ! src/java.base/share/classes/sun/security/ssl/SSLTransport.java ! src/java.base/share/classes/sun/security/util/CurveDB.java ! src/jdk.crypto.mscapi/windows/classes/sun/security/mscapi/CSignature.java Changeset: 2cc1977a Author: Jie Fu Date: 2021-06-09 02:22:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2cc1977a9698af9538101a5842c311659521a0aa 8268424: JFR tests fail due to GC cause 'G1 Preventive Collection' not in the valid causes after JDK-8257774 Reviewed-by: dholmes ! test/jdk/jdk/jfr/event/gc/collection/TestGCCauseWithG1ConcurrentMark.java ! test/jdk/jdk/jfr/event/gc/collection/TestGCCauseWithG1FullCollection.java Changeset: c9dbc4f0 Author: Thomas Stuefe Date: 2021-06-09 04:05:46 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c9dbc4f034c765627a2f2f80bb184746be1f2657 8266891: Provide a switch to force the class space to a specific location Reviewed-by: iklam, coleenp ! src/hotspot/share/memory/metaspace.cpp ! src/hotspot/share/runtime/globals.hpp Changeset: 07108c91 Author: Serguei Spitsyn Date: 2021-06-09 05:38:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/07108c916263896fa6c5dbacfedf5b4c2f5bf97a 8268241: deprecate JVM TI Heap functions 1.0 Reviewed-by: alanb, iris, kevinw ! src/hotspot/share/prims/jvmti.xml Changeset: 4d1cf51b Author: Athijegannathan Sundararajan Date: 2021-06-09 06:35:20 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4d1cf51b1d4a5e812c9f78b0104e40fbc4883a6c 8240349: jlink should not leave partial image output directory on failure Reviewed-by: jlaskey, alanb ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImageFileCreator.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/TaskHelper.java ! test/jdk/tools/jlink/JLinkNegativeTest.java ! test/jdk/tools/jlink/JLinkTest.java Changeset: 2bfd708e Author: Robbin Ehn Date: 2021-06-09 07:21:37 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2bfd708e9276bd9a6d4cf493e1af3a8e5b8026d2 8266557: assert(SafepointMechanism::local_poll_armed(_handshakee)) failed: Must be Reviewed-by: pchilanomate, dcubed ! src/hotspot/share/runtime/handshake.cpp ! src/hotspot/share/runtime/handshake.hpp ! src/hotspot/share/runtime/safepointMechanism.cpp ! src/hotspot/share/utilities/filterQueue.hpp ! src/hotspot/share/utilities/filterQueue.inline.hpp ! test/hotspot/gtest/utilities/test_filterQueue.cpp Changeset: 4413142e Author: Roland Westrelin Date: 2021-06-09 07:58:17 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4413142eca1712f9a78c5683083eb01908397bb0 8268017: C2: assert(phi_type->isa_int() || phi_type->isa_ptr() || phi_type->isa_long()) failed: bad phi type Reviewed-by: vlivanov, chagedorn, whuang ! src/hotspot/share/opto/castnode.cpp ! src/hotspot/share/opto/castnode.hpp ! src/hotspot/share/opto/cfgnode.cpp ! src/hotspot/share/opto/loopopts.cpp + test/hotspot/jtreg/compiler/loopopts/TestCastFFAtPhi.java Changeset: 9cfd560b Author: Eric Liu Committer: Pengfei Li Date: 2021-06-09 09:30:09 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9cfd560bb113b630e0ca28f9204afc079a87017b 8267663: [vector] Add unsigned comparison operators on AArch64 Reviewed-by: aph ! src/hotspot/cpu/aarch64/aarch64_neon.ad ! src/hotspot/cpu/aarch64/aarch64_neon_ad.m4 ! src/hotspot/cpu/aarch64/assembler_aarch64.cpp ! src/hotspot/cpu/aarch64/assembler_aarch64.hpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp ! src/hotspot/cpu/aarch64/matcher_aarch64.hpp ! test/hotspot/gtest/aarch64/aarch64-asmtest.py ! test/hotspot/gtest/aarch64/asmtest.out.h Changeset: 43889590 Author: Patrick Concannon Date: 2021-06-09 10:13:25 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/438895903b1de71b88951a4117c240baf410fd5d 8268056: Update java.net and java.nio to use switch expressions Reviewed-by: dfuchs, michaelm, chegar, iris, alanb ! src/java.base/share/classes/java/net/SocksSocketImpl.java ! src/java.base/share/classes/java/nio/file/Files.java Changeset: dd34a4c2 Author: Albert Mingkun Yang Date: 2021-06-09 10:37:33 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/dd34a4c28da73c798e021c7473ac57ead56c9903 8268372: ZGC: dynamically select the number of concurrent GC threads used Co-authored-by: Per Liden Reviewed-by: pliden, eosterlund ! src/hotspot/share/gc/z/zArguments.cpp ! src/hotspot/share/gc/z/zCollectedHeap.cpp ! src/hotspot/share/gc/z/zCollectedHeap.hpp ! src/hotspot/share/gc/z/zDirector.cpp ! src/hotspot/share/gc/z/zDirector.hpp ! src/hotspot/share/gc/z/zDriver.cpp ! src/hotspot/share/gc/z/zDriver.hpp ! src/hotspot/share/gc/z/zHeap.cpp ! src/hotspot/share/gc/z/zHeap.hpp ! src/hotspot/share/gc/z/zHeap.inline.hpp ! src/hotspot/share/gc/z/zHeuristics.cpp ! src/hotspot/share/gc/z/zMark.cpp ! src/hotspot/share/gc/z/zMessagePort.hpp ! src/hotspot/share/gc/z/zMessagePort.inline.hpp ! src/hotspot/share/gc/z/zNMethod.cpp ! src/hotspot/share/gc/z/zPageAllocator.cpp ! src/hotspot/share/gc/z/zPageAllocator.hpp ! src/hotspot/share/gc/z/zReferenceProcessor.cpp ! src/hotspot/share/gc/z/zRelocate.cpp ! src/hotspot/share/gc/z/zRelocationSet.cpp ! src/hotspot/share/gc/z/zRuntimeWorkers.cpp ! src/hotspot/share/gc/z/zRuntimeWorkers.hpp ! src/hotspot/share/gc/z/zStat.cpp ! src/hotspot/share/gc/z/zStat.hpp ! src/hotspot/share/gc/z/zValue.inline.hpp ! src/hotspot/share/gc/z/zWeakRootsProcessor.cpp ! src/hotspot/share/gc/z/zWorkers.cpp ! src/hotspot/share/gc/z/zWorkers.hpp - src/hotspot/share/gc/z/zWorkers.inline.hpp Changeset: 13d61804 Author: Roger Riggs Date: 2021-06-09 12:30:07 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/13d618042112aa761ef256aa35ec0a8b808cd78b 8264859: Implement Context-Specific Deserialization Filters Reviewed-by: bchristi, dfuchs, chegar ! src/java.base/share/classes/java/io/ObjectInputFilter.java ! src/java.base/share/classes/java/io/ObjectInputStream.java ! src/java.base/share/classes/jdk/internal/util/StaticProperty.java ! src/java.base/share/conf/security/java.security + test/jdk/java/io/Serializable/serialFilter/SerialFactoryExample.java + test/jdk/java/io/Serializable/serialFilter/SerialFilterFactoryTest.java + test/jdk/java/io/Serializable/serialFilter/SerialFilterFunctionTest.java ! test/jdk/java/io/Serializable/serialFilter/SerialFilterTest.java + test/jdk/java/io/Serializable/serialFilter/java.security-extra-factory Changeset: 7b1e4024 Author: Rafael Winterhalter Committer: Joel Borggr?n-Franck Date: 2021-06-09 13:21:32 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7b1e4024c02e6e831502e20cdbf54efb6240d12b 8266598: Exception values for AnnotationTypeMismatchException are not always informative Reviewed-by: jfranck ! src/java.base/share/classes/sun/reflect/annotation/AnnotationParser.java ! test/jdk/java/lang/annotation/AnnotationTypeMismatchException/AnnotationTypeMismatchTest.java ! test/jdk/java/lang/annotation/AnnotationTypeMismatchException/EnumTypeMismatchTest.java Changeset: 5fbb62c7 Author: Stefan Johansson Date: 2021-06-09 13:43:48 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5fbb62c74186417eaeff808ea070b35e5e95267a 8268163: Change the order of fallback full GCs in G1 Reviewed-by: kbarrett, tschatzl ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1CollectedHeap.hpp ! src/hotspot/share/gc/g1/g1VMOperations.cpp Changeset: 43e38a18 Author: Matthias Baesken Date: 2021-06-09 14:09:41 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/43e38a18b83a69242d1991f435d23d8799f06fe6 8268377: Windows 32bit build fails after JDK-8268174 Reviewed-by: jiefu, mdoerr ! src/hotspot/os/windows/os_windows.cpp ! src/hotspot/os_cpu/windows_x86/os_windows_x86.cpp Changeset: caf7f498 Author: Stefan Johansson Date: 2021-06-09 14:31:15 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/caf7f49887db3ea26ee302f37941f196b3a76f3f 8268122: Add specific gc cause for G1 full collections Reviewed-by: tschatzl, kbarrett ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/shared/gcCause.cpp ! src/hotspot/share/gc/shared/gcCause.hpp ! test/jdk/jdk/jfr/event/gc/collection/TestGCCauseWithG1ConcurrentMark.java ! test/jdk/jdk/jfr/event/gc/collection/TestGCCauseWithG1FullCollection.java Changeset: 81fdeb57 Author: Vladimir Kozlov Date: 2021-06-09 15:15:15 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/81fdeb579adffa45c3adcc28732c69f396d732ce 8268417: Add test from JDK-8268360 Reviewed-by: roland, chagedorn + test/hotspot/jtreg/compiler/loopopts/TestInfLoopNearUsePlacement.java Changeset: bb3d226a Author: Vicente Romero Date: 2021-06-09 15:56:55 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bb3d226a4eedb3d3ef73ef91683f45f1db43a74e 8238213: Method resolution should stop on static error Reviewed-by: jlahoda ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java + test/langtools/tools/javac/static_error/ShouldStopOnStaticError.java + test/langtools/tools/javac/static_error/ShouldStopOnStaticError.out Changeset: db45ff09 Author: Tom Rodriguez Date: 2021-06-09 17:34:17 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/db45ff09acbf4f2d824c5c23093d46c048427368 8268052: [JVMCI] non-default installed code must be marked as in_use Reviewed-by: kvn, dnsimon ! src/hotspot/share/jvmci/jvmci.hpp ! src/hotspot/share/jvmci/jvmciCodeInstaller.cpp ! src/hotspot/share/jvmci/jvmciCodeInstaller.hpp ! src/hotspot/share/jvmci/jvmciCompilerToVM.cpp ! src/hotspot/share/jvmci/jvmciRuntime.cpp ! src/hotspot/share/jvmci/jvmciRuntime.hpp ! src/hotspot/share/jvmci/vmStructs_jvmci.cpp ! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotCodeCacheProvider.java ! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotVMConfig.java Changeset: 79010f22 Author: Jorn Vernee Date: 2021-06-09 18:15:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/79010f2254aee8459523800d6049f396b055f123 8266835: Add a --validate option to the jar tool Reviewed-by: lancea ! src/jdk.jartool/share/classes/sun/tools/jar/GNUStyleOptions.java ! 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/multiRelease/ApiValidatorTest.java Changeset: 33d34c6b Author: Chris Plummer Date: 2021-06-09 19:03:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/33d34c6b670e83778479a2a11ae23229bf959752 8263323: Debug Agent help output includes invalid URL Reviewed-by: kevinw, alanb ! src/jdk.jdwp.agent/share/native/libjdwp/debugInit.c Changeset: bbd0313a Author: Chris Plummer Date: 2021-06-09 19:04:11 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bbd0313ac12c062f02400342a87c283b7578062a 8263203: jconsole Online User Guide has wrong URL Reviewed-by: mchung, dholmes ! src/jdk.jconsole/share/classes/sun/tools/jconsole/resources/messages.properties ! src/jdk.jconsole/share/classes/sun/tools/jconsole/resources/messages_ja.properties ! src/jdk.jconsole/share/classes/sun/tools/jconsole/resources/messages_zh_CN.properties Changeset: 408e0a9c Author: Evan Whelan Committer: Sean Mullan Date: 2021-06-09 20:38:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/408e0a9c696888d41809e35bf252869f09f735db 8255148: Confusing log output: SSLSocket duplex close failed Reviewed-by: mullan ! src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java + test/jdk/sun/security/ssl/SSLSocketImpl/IgnorableExceptionMessages.java Changeset: bf29a011 Author: Kevin Walls Date: 2021-06-09 20:45:44 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bf29a0115cc67ed2926b135b6b6ade5ff5ee84f6 8228343: JCMD and attach fail to work across Linux Container boundary Reviewed-by: ysuenaga, sspitsyn ! src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java ! src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java Changeset: 991ca142 Author: Phil Race Date: 2021-06-09 20:52:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/991ca14279faa7db5d0afe023e666844f5b3b75b 8267430: GraphicsDevice.setDisplayMode(REFRESH_RATE_UNKNOWN) throws IAE: Unable to set display mode! Reviewed-by: serb ! src/java.desktop/macosx/classes/sun/awt/CGraphicsDevice.java ! src/java.desktop/macosx/native/libawt_lwawt/awt/CGraphicsDevice.m + test/jdk/java/awt/GraphicsDevice/DisplayModes/UnknownRefrshRateTest.java Changeset: 7ff6e7b2 Author: Yumin Qi Date: 2021-06-09 21:33:28 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7ff6e7b2b1be088c37f50756b6822be01b4c657d 8267954: Shared classes that failed to load should not be loaded again Reviewed-by: iklam, ccheung ! src/hotspot/share/classfile/systemDictionary.cpp ! src/hotspot/share/classfile/systemDictionary.hpp ! src/hotspot/share/classfile/systemDictionaryShared.cpp ! src/hotspot/share/classfile/systemDictionaryShared.hpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/instanceKlass.hpp ! test/hotspot/jtreg/ProblemList-Xcomp.txt Changeset: b41f3f8e Author: Tom Rodriguez Date: 2021-06-09 23:04:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b41f3f8ed512117fc3677f2c5e9ee5d28116bfeb 8268478: JVMCI tests failing after JDK-8268052 Reviewed-by: kvn, eosterlund ! src/hotspot/share/jvmci/jvmciRuntime.cpp Changeset: 58ba48b7 Author: Dan Smith Date: 2021-06-09 23:57:41 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/58ba48b7b88eff359683aa3271c48b18f1973282 8268192: LambdaMetafactory with invokespecial causes VerificationError Reviewed-by: psandoz, mchung ! src/java.base/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java ! src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java ! test/jdk/java/lang/invoke/lambda/MetafactoryArgValidationTest.java Changeset: f839308e Author: Chris Plummer Date: 2021-06-10 02:49:58 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f839308efac0f5d8cb7cce165695ef24041fd621 8268407: ProblemList sun/tools/jstat/jstatLineCountsX.sh on linux-aarch64 due to JDK-8268211 Reviewed-by: amenkov ! test/jdk/ProblemList.txt Changeset: 2623b0bf Author: Igor Ignatyev Date: 2021-06-10 03:18:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2623b0bf3954df43504ca531cb2ab33b2363929a 8268475: execute runtime/InvocationTests w/ -UseVtableBasedCHA Reviewed-by: mseledtsov, kvn = test/hotspot/jtreg/runtime/InvocationTests/invocationOldCHATests.java Changeset: ece3ae3c Author: Stefan Johansson Date: 2021-06-10 05:32:56 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ece3ae3cc4cc1d45b65253a9bfafdefe2656afb8 8268388: Update large pages information in Java manpage Reviewed-by: tschatzl, lkorinth, stuefe ! src/java.base/share/man/java.1 Changeset: dd1cbadc Author: Serguei Spitsyn Date: 2021-06-10 06:03:19 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/dd1cbadc82bcecf718b96c833a5845fde79db061 8268285: vmTestbase/nsk/jvmti/GetThreadState/thrstat002 failed with "Wrong thread "thr1" (...) state after SuspendThread" Reviewed-by: lmesnik, amenkov, dholmes ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetThreadState/thrstat002.java ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetThreadState/thrstat002/thrstat002.cpp Changeset: d4377afb Author: Roland Westrelin Date: 2021-06-10 06:56:04 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d4377afb999f4f03d384ded97771c83ea1c1f513 8263303: C2 compilation fails with assert(found_sfpt) failed: no node in loop that's not input to safepoint Reviewed-by: chagedorn, kvn ! src/hotspot/share/opto/loopnode.cpp ! src/hotspot/share/opto/loopopts.cpp + test/hotspot/jtreg/compiler/loopstripmining/TestPinnedUseInOuterLSMUnusedBySfpt.java Changeset: 5a666282 Author: Kim Barrett Date: 2021-06-10 07:27:53 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5a666282a9e5b5748d85f4c012b36e5c8f7eab56 8263107: PSPromotionManager::copy_and_push_safe_barrier needs acquire memory barrier Reviewed-by: iwalulya, tschatzl, mdoerr ! src/hotspot/share/gc/parallel/psClosure.inline.hpp ! src/hotspot/share/gc/parallel/psPromotionManager.hpp ! src/hotspot/share/gc/parallel/psPromotionManager.inline.hpp ! src/hotspot/share/gc/parallel/psScavenge.hpp ! src/hotspot/share/oops/oop.hpp ! src/hotspot/share/oops/oop.inline.hpp Changeset: 78b09ab0 Author: Matthias Baesken Date: 2021-06-10 08:08:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/78b09ab04929871605abba3026ce9833c6e75789 8268463: Windows 32bit build fails in DynamicCodeGenerated\libDynamicCodeGenerated.cpp Reviewed-by: sspitsyn, cjplummer ! test/hotspot/jtreg/serviceability/jvmti/DynamicCodeGenerated/libDynamicCodeGenerated.cpp Changeset: 1fd81464 Author: Christoph G?ttschkes Committer: Jie Fu Date: 2021-06-10 08:27:54 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1fd81464ec0054f7843fba3490b7f33955717077 8268461: ARM32: vector intrinsics reaches ShouldNotReachHere Reviewed-by: jiefu, njian ! src/hotspot/cpu/arm/arm.ad Changeset: ab01cb54 Author: Jorn Vernee Date: 2021-06-10 08:44:28 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ab01cb547dd87f76017e9b079ab68495c38ffc90 8268339: Upstream: 8267989: Exceptions thrown during upcalls should be handled Reviewed-by: psandoz, mcimadamore ! src/java.base/share/classes/java/lang/System.java ! src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java ! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/CABI.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/ProgrammableUpcallHandler.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/SharedUtils.java + test/jdk/java/foreign/TestUpcallException.java + test/jdk/java/foreign/ThrowingUpcall.java Changeset: f271eb8b Author: Markus Gr?nlund Date: 2021-06-10 08:58:03 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f271eb8b846692bb45f069cd39ff107231c2812d 8268303: Incorrect casts in JfrWriterHost::write for Ticks and Tickspan Reviewed-by: egahlin ! src/hotspot/share/jfr/writers/jfrWriterHost.inline.hpp Changeset: ea19b044 Author: Sergey Bylokhov Date: 2021-06-10 09:08:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ea19b0447cf1ec97c0b0a817542ce7ead4f53176 8268481: Delete JAWT test files for mac Reviewed-by: prr, pbansal - test/jdk/java/awt/JAWT/MyMacCanvas.java - test/jdk/java/awt/JAWT/jawt-mac-buildrun.sh - test/jdk/java/awt/JAWT/myfile.m Changeset: ae29f9ca Author: Igor Ignatyev Date: 2021-06-10 09:42:26 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ae29f9cacdac8bfe7fc1d287edbfb21c81686d4c 8268530: resourcehogs/serviceability/jvmti/GetObjectSizeOverflow.java should be run in driver mode Reviewed-by: sspitsyn ! test/hotspot/jtreg/resourcehogs/serviceability/jvmti/GetObjectSizeOverflow.java Changeset: 05090fc8 Author: Igor Ignatyev Date: 2021-06-10 09:48:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/05090fc8fdef3c02c91cbd79e661f763893580c2 8268536: mark hotspot serviceability/dcmd tests which ignore external VM flags Reviewed-by: sspitsyn ! test/hotspot/jtreg/serviceability/dcmd/compiler/CodeHeapAnalyticsParams.java ! test/hotspot/jtreg/serviceability/dcmd/gc/RunFinalizationTest.java Changeset: 964118f7 Author: Igor Ignatyev Date: 2021-06-10 09:49:23 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/964118f7fd49786cfe60e1144800a02afc0fdb56 8268538: mark hotspot serviceability/logging tests which ignore external VM flags Reviewed-by: sspitsyn ! test/hotspot/jtreg/serviceability/logging/TestBasicLogOutput.java ! test/hotspot/jtreg/serviceability/logging/TestDefaultLogOutput.java ! test/hotspot/jtreg/serviceability/logging/TestFullNames.java ! test/hotspot/jtreg/serviceability/logging/TestMultipleXlogArgs.java ! test/hotspot/jtreg/serviceability/logging/TestQuotedLogOutputs.java Changeset: 92f0b6d4 Author: Igor Ignatyev Date: 2021-06-10 09:51:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/92f0b6d49e5a4dbdd6c95b8d526187adb33aa827 8268532: several serviceability/attach tests should be run in driver mode Reviewed-by: sspitsyn ! test/hotspot/jtreg/serviceability/attach/AttachNegativePidTest.java ! test/hotspot/jtreg/serviceability/attach/AttachSetGetFlag.java ! test/hotspot/jtreg/serviceability/attach/AttachWithStalePidFile.java ! test/hotspot/jtreg/serviceability/attach/RemovingUnixDomainSocketTest.java Changeset: e0c0b139 Author: Igor Ignatyev Date: 2021-06-10 09:52:07 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e0c0b139d335cd818468db115dd18f1cedf21675 8268534: some serviceability/jvmti tests should be run in driver mode Reviewed-by: sspitsyn ! test/hotspot/jtreg/serviceability/jvmti/GetObjectSizeClass.java ! test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineLeak.java ! test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/TestLambdaFormRetransformation.java ! test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/TestRedefineWithUnresolvedClass.java Changeset: f770f771 Author: Stefan Johansson Date: 2021-06-10 10:21:13 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f770f771f86db7d4878b71137cd5a72c7c40cb2e 8268390: G1 concurrent gc upgrade to full gc not working Reviewed-by: kbarrett, tschatzl ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1CollectedHeap.hpp ! src/hotspot/share/gc/g1/g1VMOperations.cpp Changeset: a187fcc3 Author: Markus Gr?nlund Date: 2021-06-10 10:26:49 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a187fcc3ec1ca360ad1d7d1f78bf5ccd9d1c2b7b 8238197: JFR: Rework setting and getting EventHandler Reviewed-by: egahlin, jbachorik ! src/hotspot/share/jfr/jni/jfrJavaSupport.cpp ! src/jdk.jfr/share/classes/jdk/jfr/internal/Utils.java Changeset: d43c8a74 Author: Patrick Concannon Date: 2021-06-10 11:12:37 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d43c8a74b33692b3628c3c9c6c472ab1cf1fdeac 8268124: Update java.lang to use switch expressions Reviewed-by: naoto, darcy, mchung, iris, lancea, dfuchs ! src/java.base/share/classes/java/lang/CharacterData.java ! src/java.base/share/classes/java/lang/ConditionalSpecialCasing.java ! src/java.base/share/classes/java/lang/Long.java ! src/java.base/share/classes/java/lang/Math.java ! src/java.base/share/classes/java/lang/constant/DirectMethodHandleDescImpl.java ! src/java.base/share/classes/java/lang/constant/MethodHandleDesc.java ! src/java.base/share/classes/java/lang/invoke/BoundMethodHandle.java ! src/java.base/share/classes/java/lang/invoke/ClassSpecializer.java ! src/java.base/share/classes/java/lang/invoke/DelegatingMethodHandle.java ! src/java.base/share/classes/java/lang/invoke/DirectMethodHandle.java ! src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java ! src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java ! src/java.base/share/classes/java/lang/invoke/Invokers.java ! src/java.base/share/classes/java/lang/invoke/LambdaForm.java ! src/java.base/share/classes/java/lang/invoke/MemberName.java ! src/java.base/share/classes/java/lang/invoke/MethodHandle.java ! src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/java.base/share/classes/java/lang/invoke/MethodHandleNatives.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/lang/invoke/VarHandle.java ! src/java.base/share/classes/java/lang/runtime/ObjectMethods.java Changeset: 09243822 Author: Rafael Winterhalter Committer: Joel Borggr?n-Franck Date: 2021-06-10 12:02:53 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/09243822ebcca611b04f94ece5afba183723cf74 8266766: Arrays of types that cannot be an annotation member do not yield exceptions Reviewed-by: darcy, jfranck ! src/java.base/share/classes/sun/reflect/annotation/AnnotationParser.java + test/jdk/java/lang/annotation/AnnotationTypeMismatchException/ArrayTypeMismatchTest.java Changeset: 6b6ff536 Author: Igor Ignatyev Date: 2021-06-10 12:29:44 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6b6ff5360a2813354735ef9eda6729c853696702 8268543: some runtime/verifier tests should be run in driver mode Reviewed-by: hseigel ! test/hotspot/jtreg/runtime/verifier/OverriderMsg.java ! test/hotspot/jtreg/runtime/verifier/TestANewArray.java ! test/hotspot/jtreg/runtime/verifier/TestMultiANewArray.java Changeset: f4b31701 Author: Maurizio Cimadamore Date: 2021-06-10 12:52:04 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f4b3170197ca517b4816f863af053f019ce0f181 8268428: Test java/foreign/TestResourceScope.java fails: expected [M] but found [N] Reviewed-by: dfuchs ! test/jdk/java/foreign/TestResourceScope.java Changeset: 6c552a7b Author: Igor Ignatyev Date: 2021-06-10 13:03:29 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6c552a7b42e73174343280d46bd72d730c42b5c5 8268544: some runtime/sealedClasses tests should be run in driver mode Reviewed-by: hseigel ! test/hotspot/jtreg/runtime/sealedClasses/RedefinePermittedSubclass.java ! test/hotspot/jtreg/runtime/sealedClasses/RedefineSealedClass.java Changeset: f677163b Author: Daniel D. Daugherty Date: 2021-06-10 13:09:26 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f677163b8aad13781be51839f27742c2213896d1 8266130: convert Thread-SMR stress tests from counter based to time based Reviewed-by: cjplummer, dholmes ! test/hotspot/jtreg/ProblemList.txt ! test/hotspot/jtreg/runtime/Thread/InterruptAtExit.java ! test/hotspot/jtreg/runtime/Thread/IsInterruptedAtExit.java - test/hotspot/jtreg/runtime/Thread/ResumeAtExit.java ! test/hotspot/jtreg/runtime/Thread/SetNameAtExit.java ! test/hotspot/jtreg/runtime/Thread/SetPriorityAtExit.java ! test/hotspot/jtreg/runtime/Thread/StopAtExit.java ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage006.java ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage006/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/InterruptThread/intrpthrd003.java ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/InterruptThread/intrpthrd003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/InterruptThread/intrpthrd003/intrpthrd003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/PopFrame/popframe011.java ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/PopFrame/popframe011/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SuspendThread/suspendthrd003.java ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SuspendThread/suspendthrd003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SuspendThread/suspendthrd003/suspendthrd003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/monitoring/ThreadInfo/isSuspended/issuspended002.java ! test/hotspot/jtreg/vmTestbase/nsk/monitoring/ThreadInfo/isSuspended/issuspended002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/monitoring/ThreadMXBean/findMonitorDeadlockedThreads/find006.java ! test/hotspot/jtreg/vmTestbase/nsk/monitoring/ThreadMXBean/findMonitorDeadlockedThreads/find006/TestDescription.java Changeset: f716711c Author: Erik Gahlin Date: 2021-06-10 13:18:54 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f716711c7b5f442653fcd5402bb9ad9fa8a6501b 8265271: JFR: Allow use of .jfc options when starting JFR Reviewed-by: mgronlun ! src/hotspot/share/jfr/dcmd/jfrDcmds.cpp ! src/hotspot/share/jfr/dcmd/jfrDcmds.hpp ! src/hotspot/share/jfr/jni/jfrJavaSupport.cpp ! src/hotspot/share/jfr/jni/jfrJavaSupport.hpp ! src/hotspot/share/jfr/utilities/jfrLogTagSets.hpp ! src/java.base/share/man/java.1 ! src/jdk.jcmd/share/man/jcmd.1 ! src/jdk.jfr/share/classes/jdk/jfr/internal/LogTag.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/dcmd/AbstractDCmd.java + src/jdk.jfr/share/classes/jdk/jfr/internal/dcmd/Argument.java + src/jdk.jfr/share/classes/jdk/jfr/internal/dcmd/ArgumentParser.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/dcmd/DCmdCheck.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/dcmd/DCmdConfigure.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/dcmd/DCmdDump.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/dcmd/DCmdStart.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/dcmd/DCmdStop.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/jfc/JFC.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/jfc/model/JFCModel.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/tool/Configure.java ! test/jdk/jdk/jfr/startupargs/TestBadOptionValues.java + test/jdk/jdk/jfr/startupargs/TestEventSettings.java + test/jdk/jdk/jfr/startupargs/TestJFCWarnings.java Changeset: 7cd5a6e7 Author: Leo Korinth Date: 2021-06-10 13:19:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7cd5a6e7b52687e80b1aad9f550c2637f501c414 8268537: (Temporary) Disable ParallelRefProcEnabled for Parallel GC Reviewed-by: stefank, sjohanss ! src/hotspot/share/gc/parallel/parallelArguments.cpp ! test/hotspot/jtreg/gc/arguments/TestParallelRefProc.java Changeset: 2b41459e Author: Thomas Schatzl Date: 2021-06-10 13:28:55 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2b41459e95e8d6c4ea4c25e8f1d851907d65ef73 8267073: Race between Card Redirtying and Freeing Collection Set regions results in missing remembered set entries with G1 Reviewed-by: kbarrett, sjohanss ! 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/g1EvacFailure.cpp ! src/hotspot/share/gc/g1/g1ParScanThreadState.cpp ! src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.cpp ! src/hotspot/share/gc/g1/heapRegion.cpp ! src/hotspot/share/gc/g1/heapRegion.hpp ! src/hotspot/share/gc/g1/heapRegion.inline.hpp Changeset: e11f70ae Author: Erik Gahlin Date: 2021-06-10 14:10:51 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e11f70aeb6a38ad05f7035461a6094320b03fc40 8003216: Add JFR event indicating explicit System.gc() call Reviewed-by: jbachorik, mgronlun, tschatzl ! src/hotspot/share/jfr/metadata/metadata.xml ! src/hotspot/share/prims/jvm.cpp ! src/jdk.jfr/share/conf/jfr/default.jfc ! src/jdk.jfr/share/conf/jfr/profile.jfc + test/jdk/jdk/jfr/event/gc/collection/TestSystemGc.java ! test/lib/jdk/test/lib/jfr/EventNames.java Changeset: 0a6c7d8a Author: Igor Veresov Date: 2021-06-10 14:18:04 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0a6c7d8a4b6560d3917b9faf66ccf5fc15a891db 8267424: CTW: C1 fails with "State must not be null" Reviewed-by: kvn, roland ! src/hotspot/share/c1/c1_GraphBuilder.cpp Changeset: a95e64cc Author: Albert Mingkun Yang Date: 2021-06-10 14:32:46 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a95e64ccc1ebe74e8b4b8e0729183ee6c4e772ac 8268443: ParallelGC Full GC should use parallel WeakProcessor Co-authored-by: Kim Barrett Reviewed-by: kbarrett, sjohanss, tschatzl ! src/hotspot/share/gc/parallel/psParallelCompact.cpp Changeset: 74007890 Author: Igor Ignatyev Date: 2021-06-10 14:43:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/74007890bb9a3fa3a65683a3f480e399f2b1a0b6 8268542: serviceability/logging/TestFullNames.java tests only 1st test case Reviewed-by: sspitsyn ! test/hotspot/jtreg/serviceability/logging/TestFullNames.java Changeset: b018c450 Author: Joe Darcy Date: 2021-06-10 16:22:14 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b018c450e5e4737ccd08ed505fd06cee16c42648 8267630: Start of release updates for JDK 18 8267632: Add source 18 and target 18 to javac 8267631: Add SourceVersion.RELEASE_18 Reviewed-by: iris, erikj, dholmes ! make/conf/version-numbers.conf + make/data/symbols/java.base-H.sym.txt + make/data/symbols/java.compiler-H.sym.txt + make/data/symbols/java.datatransfer-H.sym.txt + make/data/symbols/java.desktop-H.sym.txt + make/data/symbols/java.instrument-H.sym.txt + make/data/symbols/java.logging-H.sym.txt + make/data/symbols/java.management-H.sym.txt + make/data/symbols/java.management.rmi-H.sym.txt + make/data/symbols/java.naming-H.sym.txt + make/data/symbols/java.rmi-H.sym.txt + make/data/symbols/java.scripting-H.sym.txt + make/data/symbols/java.security.jgss-H.sym.txt + make/data/symbols/java.security.sasl-H.sym.txt + make/data/symbols/java.smartcardio-H.sym.txt + make/data/symbols/java.sql-H.sym.txt + make/data/symbols/java.sql.rowset-H.sym.txt + make/data/symbols/java.xml-H.sym.txt + make/data/symbols/java.xml.crypto-H.sym.txt + make/data/symbols/jdk.accessibility-H.sym.txt + make/data/symbols/jdk.attach-H.sym.txt + make/data/symbols/jdk.compiler-H.sym.txt + make/data/symbols/jdk.dynalink-H.sym.txt + make/data/symbols/jdk.httpserver-H.sym.txt + make/data/symbols/jdk.incubator.foreign-H.sym.txt + make/data/symbols/jdk.jartool-H.sym.txt + make/data/symbols/jdk.javadoc-H.sym.txt + make/data/symbols/jdk.jconsole-H.sym.txt + make/data/symbols/jdk.jdi-H.sym.txt + make/data/symbols/jdk.jshell-H.sym.txt + make/data/symbols/jdk.jsobject-H.sym.txt + make/data/symbols/jdk.management-H.sym.txt + make/data/symbols/jdk.net-H.sym.txt + make/data/symbols/jdk.sctp-H.sym.txt + make/data/symbols/jdk.security.auth-H.sym.txt + make/data/symbols/jdk.security.jgss-H.sym.txt + make/data/symbols/jdk.unsupported-H.sym.txt + make/data/symbols/jdk.xml.dom-H.sym.txt ! make/data/symbols/symbols ! src/hotspot/share/classfile/classFileParser.cpp ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/ClassReader.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/Opcodes.java ! src/java.compiler/share/classes/javax/lang/model/SourceVersion.java ! src/java.compiler/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor14.java ! src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor14.java ! src/java.compiler/share/classes/javax/lang/model/util/AbstractTypeVisitor14.java ! src/java.compiler/share/classes/javax/lang/model/util/ElementKindVisitor14.java ! src/java.compiler/share/classes/javax/lang/model/util/ElementScanner14.java ! src/java.compiler/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitor14.java ! src/java.compiler/share/classes/javax/lang/model/util/SimpleElementVisitor14.java ! src/java.compiler/share/classes/javax/lang/model/util/SimpleTypeVisitor14.java ! src/java.compiler/share/classes/javax/lang/model/util/TypeKindVisitor14.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassFile.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Target.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/processing/PrintingProcessor.java ! test/jdk/java/lang/module/ClassFileVersionsTest.java ! test/langtools/tools/javac/api/TestGetSourceVersions.java ! test/langtools/tools/javac/classfiles/ClassVersionChecker.java ! test/langtools/tools/javac/lib/JavacTestingAbstractProcessor.java ! test/langtools/tools/javac/preview/classReaderTest/Client.nopreview.out ! test/langtools/tools/javac/preview/classReaderTest/Client.preview.out ! test/langtools/tools/javac/versions/Versions.java Changeset: 72672277 Author: UncleNine Committer: Severin Gehwolf Date: 2021-06-10 16:40:29 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/72672277e4dddf8e72f1c705cd5f57de40745635 8268361: Fix the infinite loop in next_line Reviewed-by: dholmes, sgehwolf, sspitsyn ! src/jdk.management/linux/native/libmanagement_ext/UnixOperatingSystem.c Changeset: 78cb6776 Author: Igor Ignatyev Date: 2021-06-10 17:06:19 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/78cb6776b6d43b67457993a109719b36ee892d60 8268539: several serviceability/sa tests should be run in driver mode Reviewed-by: sspitsyn ! test/hotspot/jtreg/serviceability/sa/CDSJMapClstats.java ! test/hotspot/jtreg/serviceability/sa/ClhsdbDumpclass.java ! test/hotspot/jtreg/serviceability/sa/ClhsdbFlags.java ! test/hotspot/jtreg/serviceability/sa/ClhsdbJstackXcompStress.java ! test/hotspot/jtreg/serviceability/sa/DeadlockDetectionTest.java ! test/hotspot/jtreg/serviceability/sa/JhsdbThreadInfoTest.java ! test/hotspot/jtreg/serviceability/sa/TestCpoolForInvokeDynamic.java ! test/hotspot/jtreg/serviceability/sa/TestDefaultMethods.java ! test/hotspot/jtreg/serviceability/sa/TestHeapDumpForInvokeDynamic.java ! test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackLineNumbers.java ! test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackLock.java ! test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackMixed.java ! test/hotspot/jtreg/serviceability/sa/TestObjectMonitorIterate.java ! test/hotspot/jtreg/serviceability/sa/TestRevPtrsForInvokeDynamic.java ! test/hotspot/jtreg/serviceability/sa/TestSysProps.java ! test/hotspot/jtreg/serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java ! test/hotspot/jtreg/serviceability/sa/sadebugd/ClhsdbAttachToDebugServer.java ! test/hotspot/jtreg/serviceability/sa/sadebugd/ClhsdbTestConnectArgument.java ! test/hotspot/jtreg/serviceability/sa/sadebugd/DebugdConnectTest.java ! test/hotspot/jtreg/serviceability/sa/sadebugd/DisableRegistryTest.java ! test/hotspot/jtreg/serviceability/sa/sadebugd/PmapOnDebugdTest.java ! test/hotspot/jtreg/serviceability/sa/sadebugd/RunCommandOnServerTest.java ! test/hotspot/jtreg/serviceability/sa/sadebugd/SADebugDTest.java Changeset: 1e1039a7 Author: Leonid Mesnik Date: 2021-06-10 17:41:11 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1e1039a7c8bbd745cb23fd91e548dc20ac7d1d9d 8268223: Problemlist vmTestbase/nsk/jdi/HiddenClass/events/events001.java Reviewed-by: amenkov, sspitsyn ! test/hotspot/jtreg/ProblemList.txt Changeset: 8c8422e0 Author: Leonid Mesnik Date: 2021-06-10 17:45:53 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8c8422e0f8886d9bbfca29fd228368f88bf46f2c 8267893: Improve jtreg test failure handler do get native/mixed stack traces for cores and live processes Reviewed-by: iignatyev ! test/failure_handler/Makefile ! test/failure_handler/README + test/failure_handler/src/share/classes/jdk/test/failurehandler/CoreInfoGatherer.java ! test/failure_handler/src/share/classes/jdk/test/failurehandler/GathererFactory.java ! test/failure_handler/src/share/classes/jdk/test/failurehandler/ToolKit.java ! test/failure_handler/src/share/classes/jdk/test/failurehandler/action/ActionHelper.java ! test/failure_handler/src/share/classes/jdk/test/failurehandler/action/ActionSet.java ! test/failure_handler/src/share/classes/jdk/test/failurehandler/action/PatternAction.java ! test/failure_handler/src/share/classes/jdk/test/failurehandler/jtreg/GatherDiagnosticInfoObserver.java ! test/failure_handler/src/share/conf/common.properties ! test/failure_handler/src/share/conf/linux.properties ! test/failure_handler/src/share/conf/mac.properties Changeset: 4fd2a149 Author: Calvin Cheung Date: 2021-06-10 19:50:44 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4fd2a149977b05eb6e4b28d147ab9c043a7934ec 8267556: Enhance class paths check during runtime Reviewed-by: minqi, iklam ! src/hotspot/share/cds/filemap.cpp ! src/hotspot/share/cds/filemap.hpp ! src/hotspot/share/classfile/classLoader.cpp ! src/hotspot/share/classfile/classLoader.hpp ! src/hotspot/share/classfile/classLoaderExt.cpp ! src/hotspot/share/classfile/classLoaderExt.hpp + test/hotspot/jtreg/runtime/cds/appcds/NonJarInClasspath.java Changeset: 2e900da5 Author: Daniel D. Daugherty Date: 2021-06-10 23:08:56 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2e900da5f70105c153500908c693b2601fa30477 8268574: ProblemList tests failing due to UseBiasedLocking going away Reviewed-by: cjplummer ! test/hotspot/jtreg/ProblemList.txt Changeset: df65237b Author: Hamlin Li Date: 2021-06-11 01:20:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/df65237b9a55aec4374ef63dcc9ab13d3eda8408 8267930: Refine code for loading hsdis library Reviewed-by: whuang, neliasso, ysuenaga ! src/hotspot/share/compiler/disassembler.cpp ! src/hotspot/share/compiler/disassembler.hpp Changeset: 94d0b0f9 Author: Igor Ignatyev Date: 2021-06-11 02:44:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/94d0b0f9810bd1a8da06ec267a1c7589d6cb756b 8268565: runtime/records/RedefineRecord.java should be run in driver mode Reviewed-by: hseigel ! test/hotspot/jtreg/runtime/records/RedefineRecord.java Changeset: 37791a84 Author: duke Date: 2021-06-11 11:01:00 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/37791a84901685edc03a1b49d7b2aca3fe86d45b Automatic merge of jdk:master into master From mcimadamore at openjdk.java.net Fri Jun 11 11:47:05 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 11 Jun 2021 11:47:05 GMT Subject: [foreign-memaccess+abi] RFR: 8268266: Investigate way to lazily customize upcall lambda forms In-Reply-To: References: Message-ID: On Thu, 10 Jun 2021 10:02:48 GMT, Jorn Vernee wrote: > Hi, > > This patch makes upcall method handle customization lazy, which helps a lot in reducing the number of lambda form classes generated during for intstance the TestUpcall test, making it complete a lot faster. > > This adds a very slight overhead per call, since there's another indirection, but I think the tradeoff is acceptable. > > Since the patch was otherwise really small, this also adds a qsort benchmark that is also used the measure the cost of the extra indirection. Results are as follows: > > > QSort without lazy customization: > > Benchmark Mode Cnt Score Error Units > QSort.jni_upcall_qsort_naive avgt 30 21096.871 ? 299.669 ns/op > QSort.jni_upcall_qsort_optimized avgt 30 3603.495 ? 16.464 ns/op > QSort.native_qsort avgt 30 96.236 ? 0.713 ns/op > QSort.panama_upcall_qsort avgt 30 937.675 ? 26.160 ns/op > > QSort with lazy customization: > > Benchmark Mode Cnt Score Error Units > QSort.jni_upcall_qsort_naive avgt 30 21454.476 ? 306.135 ns/op > QSort.jni_upcall_qsort_optimized avgt 30 3691.395 ? 35.671 ns/op > QSort.native_qsort avgt 30 97.440 ? 0.894 ns/op > QSort.panama_upcall_qsort avgt 30 1072.929 ? 14.948 ns/op > > > So, while there is some regression from this change, it's not super bad (not integer factor), and I think the tradeoff is worth it to generate fewer lambda form classes, which of course has it's own overhead not visible in this benchmark. > > Thanks, > Jorn Looks good - what is the cost for downcalls? ------------- Marked as reviewed by mcimadamore (Committer). PR: https://git.openjdk.java.net/panama-foreign/pull/553 From jvernee at openjdk.java.net Fri Jun 11 11:52:58 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Fri, 11 Jun 2021 11:52:58 GMT Subject: [foreign-memaccess+abi] RFR: 8268266: Investigate way to lazily customize upcall lambda forms In-Reply-To: References: Message-ID: On Fri, 11 Jun 2021 11:43:36 GMT, Maurizio Cimadamore wrote: > Looks good - what is the cost for downcalls? Nothing, only upcalls were eagerly customized. So, there's no change for downcalls ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/553 From duncan.gittins at gmail.com Fri Jun 11 12:54:11 2021 From: duncan.gittins at gmail.com (Duncan Gittins) Date: Fri, 11 Jun 2021 13:54:11 +0100 Subject: [foreign-memaccess+abi] RFR: 8268230: Foreign Linker API & Windows user32/kernel32: String conversion seems broken In-Reply-To: <0ZOia1B8PO-j284cRHT3_oVVMyWqCBUJT4emLo3BxZQ=.7b226aa8-d1c9-4a08-9910-18deb4ef0a24@github.com> References: <0ZOia1B8PO-j284cRHT3_oVVMyWqCBUJT4emLo3BxZQ=.7b226aa8-d1c9-4a08-9910-18deb4ef0a24@github.com> Message-ID: <4b78b2bf-7a4e-2937-2049-e2f9828f42e5@gmail.com> I've had problems with Windows String conversions to/from wide string using Clinker toCString / toJavaString so switched to using kernel32.dll MultiByteToWideChar / WideCharToMultiByte. Hopefully your fix will address the issue with toCString(s, UTF_16LE). I don't think reverse conversion works using Clinker.toJavaString. It may help to verify by changing "test/jdk/java/foreign/TestToCStringWide.java.testStrings()" to handled input array of strings: ??? for (String testString : new String[] {"", "x", "testing"} ) { ... .. and also checked the reverse operation returns the original: ?????? String outString = CLinker.toJavaString(text, charset); ?????? assertEquals(testString, outString); Kind regards Duncan On 10/06/2021 13:12, Jorn Vernee wrote: > The problem is that we only add a single 0 byte as a null terminator, regardless of the charset used. For wider char sets, more 0 bytes need to be added. For instance, for UTF_16LE two 0 bytes need to be added. > > This patch fixes the issue by adding the null terminator to the Java string, and only then encoding it as a `byte[]`. > > ------------- > > Commit messages: > - Fix toCString for wider character sets > > Changes: https://git.openjdk.java.net/panama-foreign/pull/554/files > Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=554&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8268230 > Stats: 85 lines in 2 files changed: 75 ins; 6 del; 4 mod > Patch: https://git.openjdk.java.net/panama-foreign/pull/554.diff > Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/554/head:pull/554 > > PR: https://git.openjdk.java.net/panama-foreign/pull/554 > . From mr.chrisvest at gmail.com Fri Jun 11 13:40:35 2021 From: mr.chrisvest at gmail.com (Chris Vest) Date: Fri, 11 Jun 2021 15:40:35 +0200 Subject: compose MemorySegments In-Reply-To: <7740eb08-58d5-6a7f-d391-5da3b0b9f44a@oracle.com> References: <106FE1E7-8CEE-4151-A882-C588F7A12AC1@oracle.com> <7740eb08-58d5-6a7f-d391-5da3b0b9f44a@oracle.com> Message-ID: In Netty we have a handler called ByteToMessageDecoder which I think implements Douglas's use case. Bytes come in, in chunks determined by IO, get collected, and then leave in chunks of one whole message per chunk, whatever that means for the implemented protocol in question. Our ByteToMessageDecoder can use the CompositeByteBuf as Douglas described, when collecting the incoming bytes. However, the extra indirections on every memory access, introduced by the CompositeByteBuf, turns out to be expensive in practice, so we actually use copying by default. The ByteToMessageDecoder can be configured to operate in either mode. Cheers, Chris On Fri, 11 Jun 2021 at 13:09, Maurizio Cimadamore < maurizio.cimadamore at oracle.com> wrote: > One thing I saw which is very similar to what you want is this: > > https://netty.io/4.0/api/io/netty/buffer/CompositeByteBuf.html > > Perhaps Chris Vest or some other folks in Netty can comment more on that > API. Netty is also doing some exploratory work to validate use of memory > segments within Netty itself [1]. > > Maurizio > > [1] - https://github.com/netty/netty-incubator-buffer-api > > On 11/06/2021 00:41, Douglas Surber wrote: > > As I understand them, no a mapped MemorySegment wouldn't work. The data > is not in a file. It is in byte[]s. My code has to look at the bits as it > gets them from the network to deal with metadata. Based on that it copies > the data bits from the network buffer into byte[]s with no additional > processing. > > > > Douglas > > > > On Jun 10, 2021, at 4:24 PM, panama-dev-request at openjdk.java.net panama-dev-request at openjdk.java.net> wrote: > > > > Would a mapped MemorySegment work for you? > > > From pedro.lamarao at prodist.com.br Fri Jun 11 13:52:27 2021 From: pedro.lamarao at prodist.com.br (=?UTF-8?Q?Pedro_Lamar=C3=A3o?=) Date: Fri, 11 Jun 2021 10:52:27 -0300 Subject: compose MemorySegments In-Reply-To: References: <2433173C-34FE-430C-9751-5BF4209064DB@oracle.com> <18df1d1b-ed73-e8a8-968e-aeb6d36f0e2e@oracle.com> <9A1FC972-20B2-4718-8AFC-157DC91C8A37@oracle.com> <0d06bfe5-6d56-7859-8ad7-48fa0682c740@oracle.com> <77a9ec6d-1292-b301-8c9f-7dcf1185a65c@oracle.com> <9fc0ae1c-acf0-b064-9749-ec4cba84342a@oracle.com> <7165F10B-D8B5-4558-A291-D64DF6DDE761@oracle.com> Message-ID: Em sex., 11 de jun. de 2021 ?s 00:17, leerho escreveu: > This is an interesting problem and a difficult one to do efficiently > without copies or additional allocations. I think the OS does similar > tricks when it maps virtual memory addresses into CPU caches or main > memory. To the user's program it appears as a contiguous memory space but > in reality could be broken into many separate physical chunks. I'm sure > there are some ways one could do this in C++, but probably not as efficient > as the OS could do it. > Virtual memory is "accelerated" by the hardware's MMU; that would be a very hard performance target to replicate in userspace. -- Pedro Lamar?o https://www.prodist.com.br Securing Critical Systems Tel: +55 11 4380-6585 Antes de imprimir esta mensagem e seus anexos, certifique-se que seja realmente necess?rio. Proteger o meio ambiente ? nosso dever. Before printing this e-mail or attachments, be sure it is necessary. It is in our hands to protect the environment. From sebastian.stenzel at gmail.com Fri Jun 11 14:32:30 2021 From: sebastian.stenzel at gmail.com (Sebastian Stenzel) Date: Fri, 11 Jun 2021 16:32:30 +0200 Subject: Mapping List to char ** Message-ID: Hi, imagine you want to invoke a native method with (among others) these params: int argc, char **argv On the Java side I have a `List`. Currently, ... 1. I create a new SequenceLayout of type MemoryLayouts.ADDRESS and of size `argc` 2. I allocate a new MemorySegment `argv` using aforementioned layout 3. For each of my elements, I call CLinker.toCString and fill in the address of the returned segment into `argv` I feel like there should be an easier way to achieve this. Is there some utility to create a MemorySegment from an array of addresses? (I know I can create an array of longs, but I don't want to rely on a 64 bit architecture). Thanks, Sebastian From mr.chrisvest at gmail.com Fri Jun 11 14:47:57 2021 From: mr.chrisvest at gmail.com (Chris Vest) Date: Fri, 11 Jun 2021 16:47:57 +0200 Subject: compose MemorySegments In-Reply-To: References: <2433173C-34FE-430C-9751-5BF4209064DB@oracle.com> <18df1d1b-ed73-e8a8-968e-aeb6d36f0e2e@oracle.com> <9A1FC972-20B2-4718-8AFC-157DC91C8A37@oracle.com> <0d06bfe5-6d56-7859-8ad7-48fa0682c740@oracle.com> <77a9ec6d-1292-b301-8c9f-7dcf1185a65c@oracle.com> <9fc0ae1c-acf0-b064-9749-ec4cba84342a@oracle.com> <7165F10B-D8B5-4558-A291-D64DF6DDE761@oracle.com> Message-ID: On Fri, 11 Jun 2021 at 15:53, Pedro Lamar?o wrote: > Em sex., 11 de jun. de 2021 ?s 00:17, leerho escreveu: > > > This is an interesting problem and a difficult one to do efficiently > > without copies or additional allocations. I think the OS does similar > > tricks when it maps virtual memory addresses into CPU caches or main > > memory. To the user's program it appears as a contiguous memory space > but > > in reality could be broken into many separate physical chunks. I'm sure > > there are some ways one could do this in C++, but probably not as > efficient > > as the OS could do it. > > > > Virtual memory is "accelerated" by the hardware's MMU; > that would be a very hard performance target to replicate in userspace. > The tricks we'd need to play (if we can assume aligned, whole-page chunks, anyway) are available to us in user-space via the mmap(2) system call. The RUMA paper shows how you can build dynamic data structures on top of this: http://www.vldb.org/pvldb/vol9/p768-schuhknecht.pdf > -- > Pedro Lamar?o > https://www.prodist.com.br > Securing Critical Systems > Tel: +55 11 4380-6585 > > Antes de imprimir esta mensagem e seus anexos, certifique-se que seja > realmente necess?rio. > Proteger o meio ambiente ? nosso dever. > Before printing this e-mail or attachments, be sure it is necessary. > It is in our hands to protect the environment. > From maurizio.cimadamore at oracle.com Fri Jun 11 14:50:10 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 11 Jun 2021 15:50:10 +0100 Subject: Mapping List to char ** In-Reply-To: References: Message-ID: <962dc380-d893-1702-64b4-5c3fe4a4a382@oracle.com> Hi, The API we have in 17 has the ability to create a so called SegmentAllocator: https://download.java.net/java/early_access/jdk17/docs/api/jdk.incubator.foreign/jdk/incubator/foreign/SegmentAllocator.html A SegmentAllocator has a method to allocate a contiguous array of addresses: https://download.java.net/java/early_access/jdk17/docs/api/jdk.incubator.foreign/jdk/incubator/foreign/SegmentAllocator.html#allocateArray(jdk.incubator.foreign.ValueLayout,jdk.incubator.foreign.Addressable%5B%5D) I believe that by combining these bits you should be able to do what you want - e.g. ``` jshell> import jdk.incubator.foreign.*; jshell> List strings = List.of("a", "b", "c"); strings ==> [a, b, c] jshell> var scope = ResourceScope.newConfinedScope(); scope ==> jdk.internal.foreign.ConfinedScope at 37f8bb67 jshell> var allocator = SegmentAllocator.ofScope(scope); allocator ==> jdk.internal.foreign.ConfinedScope at 37f8bb67 jshell> var cstrings = allocator.allocateArray(CLinker.C_POINTER, strings.stream().map(s -> CLinker.toCString(s, scope)).toArray(Addressable[]::new)); cstrings ==> MemorySegment{ id=0x72ee5071 limit: 24 } jshell> CLinker.toJavaString(MemoryAccess.getAddressAtIndex(cstrings, 0)); $6 ==> "a" jshell> CLinker.toJavaString(MemoryAccess.getAddressAtIndex(cstrings, 1)); $7 ==> "b" jshell> CLinker.toJavaString(MemoryAccess.getAddressAtIndex(cstrings, 2)); $8 ==> "c" ``` I hope this helps. Maurizio On 11/06/2021 15:32, Sebastian Stenzel wrote: > Hi, > > imagine you want to invoke a native method with (among others) these params: > > int argc, char **argv > > On the Java side I have a `List`. > > Currently, ... > > 1. I create a new SequenceLayout of type MemoryLayouts.ADDRESS and of size `argc` > 2. I allocate a new MemorySegment `argv` using aforementioned layout > 3. For each of my elements, I call CLinker.toCString and fill in the address of the returned segment into `argv` > > I feel like there should be an easier way to achieve this. Is there some utility to create a MemorySegment from an array of addresses? (I know I can create an array of longs, but I don't want to rely on a 64 bit architecture). > > Thanks, > Sebastian From maurizio.cimadamore at oracle.com Fri Jun 11 15:04:06 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 11 Jun 2021 16:04:06 +0100 Subject: compose MemorySegments In-Reply-To: References: <2433173C-34FE-430C-9751-5BF4209064DB@oracle.com> <18df1d1b-ed73-e8a8-968e-aeb6d36f0e2e@oracle.com> <9A1FC972-20B2-4718-8AFC-157DC91C8A37@oracle.com> <0d06bfe5-6d56-7859-8ad7-48fa0682c740@oracle.com> <77a9ec6d-1292-b301-8c9f-7dcf1185a65c@oracle.com> <9fc0ae1c-acf0-b064-9749-ec4cba84342a@oracle.com> <7165F10B-D8B5-4558-A291-D64DF6DDE761@oracle.com> Message-ID: <64f4f7cc-0a03-b2eb-8e36-52b09e11ae54@oracle.com> On 11/06/2021 15:47, Chris Vest wrote: > > On Fri, 11 Jun 2021 at 15:53, Pedro Lamar?o > > > wrote: > > Em sex., 11 de jun. de 2021 ?s 00:17, leerho > escreveu: > > > This is an interesting problem and a difficult one to do efficiently > > without copies or additional allocations. I think the OS does > similar > > tricks when it maps virtual memory addresses into CPU caches or main > > memory.? To the user's program it appears as a contiguous memory > space but > > in reality could be broken into many separate physical chunks.? > I'm sure > > there are some ways one could do this in C++, but probably not > as efficient > > as the OS could do it. > > > > Virtual memory is "accelerated" by the hardware's MMU; > that would be a very hard performance target to replicate in > userspace. > > The tricks we'd need to play (if we can assume aligned, whole-page > chunks, anyway) are available to us in user-space via the mmap(2) > system call. > The RUMA paper shows how you can build dynamic data structures on top > of this: > http://www.vldb.org/pvldb/vol9/p768-schuhknecht.pdf > > Thanks for sharing - very interesting application of mmap indeed. I presume it should be possible to build something on top of the memory access API and linker API which takes two - or more segments (assuming each segment is a whole-page chunks), and return a _new_ segment with new size, after having rewired the pages of the various segments so that they end up in contiguous virtual addresses. This should effectively create a segment which can probably support the full segment API (including bulk copy, vectorized mismatch and what's not). Maurizio > > -- > Pedro Lamar?o > https://www.prodist.com.br > > Securing Critical Systems > Tel: +55 11 4380-6585 > > Antes de imprimir esta mensagem e seus anexos, certifique-se que seja > realmente necess?rio. > Proteger o meio ambiente ? nosso dever. > Before printing this e-mail or attachments, be sure it is necessary. > It is in our hands to protect the environment. > From sebastian.stenzel at gmail.com Fri Jun 11 15:21:50 2021 From: sebastian.stenzel at gmail.com (Sebastian Stenzel) Date: Fri, 11 Jun 2021 17:21:50 +0200 Subject: Mapping List to char ** In-Reply-To: <962dc380-d893-1702-64b4-5c3fe4a4a382@oracle.com> References: <962dc380-d893-1702-64b4-5c3fe4a4a382@oracle.com> Message-ID: <5FB431B9-687C-4BCC-885D-B6F14A645175@gmail.com> Awesome, thank you! > On 11. Jun 2021, at 16:50, Maurizio Cimadamore wrote: > > Hi, > The API we have in 17 has the ability to create a so called SegmentAllocator: > > https://download.java.net/java/early_access/jdk17/docs/api/jdk.incubator.foreign/jdk/incubator/foreign/SegmentAllocator.html > > A SegmentAllocator has a method to allocate a contiguous array of addresses: > > https://download.java.net/java/early_access/jdk17/docs/api/jdk.incubator.foreign/jdk/incubator/foreign/SegmentAllocator.html#allocateArray(jdk.incubator.foreign.ValueLayout,jdk.incubator.foreign.Addressable%5B%5D) > > I believe that by combining these bits you should be able to do what you want - e.g. > > ``` > jshell> import jdk.incubator.foreign.*; > > jshell> List strings = List.of("a", "b", "c"); > strings ==> [a, b, c] > > jshell> var scope = ResourceScope.newConfinedScope(); > scope ==> jdk.internal.foreign.ConfinedScope at 37f8bb67 > > jshell> var allocator = SegmentAllocator.ofScope(scope); > allocator ==> jdk.internal.foreign.ConfinedScope at 37f8bb67 > > jshell> var cstrings = allocator.allocateArray(CLinker.C_POINTER, strings.stream().map(s -> CLinker.toCString(s, scope)).toArray(Addressable[]::new)); > cstrings ==> MemorySegment{ id=0x72ee5071 limit: 24 } > > jshell> CLinker.toJavaString(MemoryAccess.getAddressAtIndex(cstrings, 0)); > $6 ==> "a" > > jshell> CLinker.toJavaString(MemoryAccess.getAddressAtIndex(cstrings, 1)); > $7 ==> "b" > > jshell> CLinker.toJavaString(MemoryAccess.getAddressAtIndex(cstrings, 2)); > $8 ==> "c" > ``` > > I hope this helps. > > Maurizio > > On 11/06/2021 15:32, Sebastian Stenzel wrote: >> Hi, >> >> imagine you want to invoke a native method with (among others) these params: >> >> int argc, char **argv >> >> On the Java side I have a `List`. >> >> Currently, ... >> >> 1. I create a new SequenceLayout of type MemoryLayouts.ADDRESS and of size `argc` >> 2. I allocate a new MemorySegment `argv` using aforementioned layout >> 3. For each of my elements, I call CLinker.toCString and fill in the address of the returned segment into `argv` >> >> I feel like there should be an easier way to achieve this. Is there some utility to create a MemorySegment from an array of addresses? (I know I can create an array of longs, but I don't want to rely on a 64 bit architecture). >> >> Thanks, >> Sebastian From chris.hegarty at oracle.com Fri Jun 11 15:59:03 2021 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 11 Jun 2021 15:59:03 +0000 Subject: compose MemorySegments In-Reply-To: References: <106FE1E7-8CEE-4151-A882-C588F7A12AC1@oracle.com> <7740eb08-58d5-6a7f-d391-5da3b0b9f44a@oracle.com> Message-ID: <0EDA0A95-6C6A-49B9-BA7B-44DCE1815AF3@oracle.com> Only tangentially related... While decoding HTTP/2 frames, the Java HTTP Client has a threshold whereby it decides to either copy-accumulate or parse-in-place. Mainly to avoid slow or pathological inbound network data, where the cost of aggregation can vastly outweigh the cost of a simple copy. Response body data is represented as an aggregate of ByteBuffers (there is no composite ByteBuffer). As with any scatter/gather or aggregation, the options mostly boil down to somthing like an array or List (the HTTP Client uses the latter). While this is less friendly to consumers of said data, at least they know what they get. We've not had any real issues arise from this in practice. -Chris H > On 11 Jun 2021, at 14:40, Chris Vest wrote: > > In Netty we have a handler called ByteToMessageDecoder which I think > implements Douglas's use case. > Bytes come in, in chunks determined by IO, get collected, and then leave in > chunks of one whole message per chunk, whatever that means for the > implemented protocol in question. > Our ByteToMessageDecoder can use the CompositeByteBuf as Douglas described, > when collecting the incoming bytes. > However, the extra indirections on every memory access, introduced by the > CompositeByteBuf, turns out to be expensive in practice, so we actually use > copying by default. > The ByteToMessageDecoder can be configured to operate in either mode. > > Cheers, > Chris > > On Fri, 11 Jun 2021 at 13:09, Maurizio Cimadamore < > maurizio.cimadamore at oracle.com> wrote: > >> One thing I saw which is very similar to what you want is this: >> >> https://netty.io/4.0/api/io/netty/buffer/CompositeByteBuf.html >> >> Perhaps Chris Vest or some other folks in Netty can comment more on that >> API. Netty is also doing some exploratory work to validate use of memory >> segments within Netty itself [1]. >> >> Maurizio >> >> [1] - https://github.com/netty/netty-incubator-buffer-api >> >> On 11/06/2021 00:41, Douglas Surber wrote: >>> As I understand them, no a mapped MemorySegment wouldn't work. The data >> is not in a file. It is in byte[]s. My code has to look at the bits as it >> gets them from the network to deal with metadata. Based on that it copies >> the data bits from the network buffer into byte[]s with no additional >> processing. >>> >>> Douglas >>> >>> On Jun 10, 2021, at 4:24 PM, panama-dev-request at openjdk.java.net> panama-dev-request at openjdk.java.net> wrote: >>> >>> Would a mapped MemorySegment work for you? >>> >> From pedro.lamarao at prodist.com.br Fri Jun 11 16:27:39 2021 From: pedro.lamarao at prodist.com.br (=?UTF-8?Q?Pedro_Lamar=C3=A3o?=) Date: Fri, 11 Jun 2021 13:27:39 -0300 Subject: compose MemorySegments In-Reply-To: References: <2433173C-34FE-430C-9751-5BF4209064DB@oracle.com> <18df1d1b-ed73-e8a8-968e-aeb6d36f0e2e@oracle.com> <9A1FC972-20B2-4718-8AFC-157DC91C8A37@oracle.com> <0d06bfe5-6d56-7859-8ad7-48fa0682c740@oracle.com> <77a9ec6d-1292-b301-8c9f-7dcf1185a65c@oracle.com> <9fc0ae1c-acf0-b064-9749-ec4cba84342a@oracle.com> <7165F10B-D8B5-4558-A291-D64DF6DDE761@oracle.com> Message-ID: Em sex., 11 de jun. de 2021 ?s 11:48, Chris Vest escreveu: > > On Fri, 11 Jun 2021 at 15:53, Pedro Lamar?o > wrote: > >> Em sex., 11 de jun. de 2021 ?s 00:17, leerho escreveu: >> >> > This is an interesting problem and a difficult one to do efficiently >> > without copies or additional allocations. I think the OS does similar >> > tricks when it maps virtual memory addresses into CPU caches or main >> > memory. To the user's program it appears as a contiguous memory space >> but >> > in reality could be broken into many separate physical chunks. I'm sure >> > there are some ways one could do this in C++, but probably not as >> efficient >> > as the OS could do it. >> > >> >> Virtual memory is "accelerated" by the hardware's MMU; >> that would be a very hard performance target to replicate in userspace. >> > > The tricks we'd need to play (if we can assume aligned, whole-page chunks, > anyway) are available to us in user-space via the mmap(2) system call. > The RUMA paper shows how you can build dynamic data structures on top of > this: > http://www.vldb.org/pvldb/vol9/p768-schuhknecht.pdf > Very interesting, thanks for sharing! I was assuming arbitrary buffers based on my reading of the OP. Requiring allocations in page units seems very reasonable nowadays with 4 KB pages. I suppose a specialized page-allocator capable of "merge" and "swap" would be an incredible API. -- Pedro Lamar?o https://www.prodist.com.br Securing Critical Systems Tel: +55 11 4380-6585 Antes de imprimir esta mensagem e seus anexos, certifique-se que seja realmente necess?rio. Proteger o meio ambiente ? nosso dever. Before printing this e-mail or attachments, be sure it is necessary. It is in our hands to protect the environment. From duncan.gittins at gmail.com Fri Jun 11 16:41:46 2021 From: duncan.gittins at gmail.com (Duncan Gittins) Date: Fri, 11 Jun 2021 17:41:46 +0100 Subject: [foreign-memaccess+abi] RFR: 8268230: Foreign Linker API & Windows user32/kernel32: String conversion seems broken In-Reply-To: <4b78b2bf-7a4e-2937-2049-e2f9828f42e5@gmail.com> References: <0ZOia1B8PO-j284cRHT3_oVVMyWqCBUJT4emLo3BxZQ=.7b226aa8-d1c9-4a08-9910-18deb4ef0a24@github.com> <4b78b2bf-7a4e-2937-2049-e2f9828f42e5@gmail.com> Message-ID: A better range of test strings for Windows <=> wide char conversions and back using CLinker.toCString / CLinker.toJavaString might be: private static final String [] STRINGS = { "","X","12345","testing".repeat(5) ,"euro \u20AC" ,"yen \u00a5" ,"Small-Omega \u03C9" ,"umlaut \u00FC".repeat(2000) }; Kind regards Duncan On Fri, 11 Jun 2021 at 13:54, Duncan Gittins wrote: > I've had problems with Windows String conversions to/from wide string > using Clinker toCString / toJavaString so switched to using kernel32.dll > MultiByteToWideChar / WideCharToMultiByte. Hopefully your fix will > address the issue with toCString(s, UTF_16LE). > > I don't think reverse conversion works using Clinker.toJavaString. It > may help to verify by changing > "test/jdk/java/foreign/TestToCStringWide.java.testStrings()" to handled > input array of strings: > > for (String testString : new String[] {"", "x", "testing"} ) { ... > > .. and also checked the reverse operation returns the original: > > String outString = CLinker.toJavaString(text, charset); > assertEquals(testString, outString); > > Kind regards > > Duncan > > > On 10/06/2021 13:12, Jorn Vernee wrote: > > The problem is that we only add a single 0 byte as a null terminator, > regardless of the charset used. For wider char sets, more 0 bytes need to > be added. For instance, for UTF_16LE two 0 bytes need to be added. > > > > This patch fixes the issue by adding the null terminator to the Java > string, and only then encoding it as a `byte[]`. > > > > ------------- > > > > Commit messages: > > - Fix toCString for wider character sets > > > > Changes: https://git.openjdk.java.net/panama-foreign/pull/554/files > > Webrev: > https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=554&range=00 > > Issue: https://bugs.openjdk.java.net/browse/JDK-8268230 > > Stats: 85 lines in 2 files changed: 75 ins; 6 del; 4 mod > > Patch: https://git.openjdk.java.net/panama-foreign/pull/554.diff > > Fetch: git fetch https://git.openjdk.java.net/panama-foreign > pull/554/head:pull/554 > > > > PR: https://git.openjdk.java.net/panama-foreign/pull/554 > > . > > > From leerho at gmail.com Fri Jun 11 16:43:01 2021 From: leerho at gmail.com (leerho) Date: Fri, 11 Jun 2021 09:43:01 -0700 Subject: Configure error In-Reply-To: <5c294def-666f-3811-01ba-b7a9070eb2d0@oracle.com> References: <5c294def-666f-3811-01ba-b7a9070eb2d0@oracle.com> Message-ID: Maurizio, Thank you! Sundar's hint was the problem, I was sitting on master, not foreign-jextract! I have updated my notes so this won't happen again! Lee. On Fri, Jun 11, 2021 at 3:40 AM Maurizio Cimadamore < maurizio.cimadamore at oracle.com> wrote: > Another option, since you are not really working with jextract, is to work > on top of the foreign-memaccess+abi branch - which contains everything > _but_ jextract, and can be built like any other regular JDKs. > > > Maurizio > > > On 11/06/2021 06:13, Sundararajan Athijegannathan wrote: > > Hi, > > I just git cloned your repo > > git clone https://github.com/leerho/panama-foreign.git > > > and ran configure with --with-libclang option. It worked fine.. > > You may want to make sure foreign-jextract branch is checked out. > > -Sundar > ------------------------------ > *From:* panama-dev > on behalf of leerho > > *Sent:* 11 June 2021 10:00 > *To:* panama-dev at openjdk.java.net' > ; Maurizio Cimadamore > > *Subject:* Configure error > > Maurizio, > I forked your mcimadamore/panama-foreign into my > GitHub.com/leerho/mcimadamore_panama-foreign as you suggested, and then > cloned it to my computer. I have special copies of > clang+llvm-9.0.1-x86_64-apple-darwin and jtreg in a separate local > directory. > > But when I run bash configure > > bash configure > > --with-libclang=/Users/lrhodes/dev/git/Oracle/local/clang+llvm-9.0.1-x86_64-apple-darwin/ > --with-jtreg=/Users/lrhodes/dev/git/Oracle/local/jtreg/ > > > I get the error: > > > configure: error: unrecognized options: --with-libclang > > > Has something changed recently? > > > Thanks in advance :) > > > Lee. > > From douglas.surber at oracle.com Fri Jun 11 16:47:17 2021 From: douglas.surber at oracle.com (Douglas Surber) Date: Fri, 11 Jun 2021 16:47:17 +0000 Subject: compose MemorySegments In-Reply-To: References: Message-ID: <4C963D29-F257-426A-A5E4-F18C9EEC3002@oracle.com> I could use something that worked for whole-page chunks. My current block size is arbitrary. It was chosen (as Lee suggested) to minimize the number of fields that span boundaries while still being reasonably small. I don't have statistics to prove it's optimum, but we haven't seen any evidence suggesting its way wrong. If 4k pages were supported I could just as easily choose that as my block size if the generated code efficiently spanned block boundaries. This assumes that allocating and releasing pages is reasonably efficient. We avoid both (that's the point of this whole mechanism) but it does matter some. Douglas On Jun 11, 2021, at 9:28 AM, panama-dev-request at openjdk.java.net wrote: The tricks we'd need to play (if we can assume aligned, whole-page chunks, anyway) are available to us in user-space via the mmap(2) system call. The RUMA paper shows how you can build dynamic data structures on top of this: http://www.vldb.org/pvldb/vol9/p768-schuhknecht.pdf Very interesting, thanks for sharing! I was assuming arbitrary buffers based on my reading of the OP. Requiring allocations in page units seems very reasonable nowadays with 4 KB pages. I suppose a specialized page-allocator capable of "merge" and "swap" would be an incredible API. -- Pedro Lamar?o https://www.prodist.com.br Securing Critical Systems Tel: +55 11 4380-6585 Antes de imprimir esta mensagem e seus anexos, certifique-se que seja realmente necess?rio. Proteger o meio ambiente ? nosso dever. Before printing this e-mail or attachments, be sure it is necessary. It is in our hands to protect the environment. From sviswanathan at openjdk.java.net Fri Jun 11 17:44:35 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Fri, 11 Jun 2021 17:44:35 GMT Subject: [vectorIntrinsics] RFR: Merge panama-vector:master Message-ID: This pull request merges master changes into vectorIntrinsics. @nsjian Need your help to merge test/hotspot/gtest/aarch64/asmtest.out.h (I have left the git merge markers in place for asmtest.out.h). Best Regards, Sandhya ------------- Commit messages: - Merge - 8267930: Refine code for loading hsdis library - 8268574: ProblemList tests failing due to UseBiasedLocking going away - 8267556: Enhance class paths check during runtime - 8267893: Improve jtreg test failure handler do get native/mixed stack traces for cores and live processes - 8268223: Problemlist vmTestbase/nsk/jdi/HiddenClass/events/events001.java - 8268539: several serviceability/sa tests should be run in driver mode - 8268361: Fix the infinite loop in next_line - 8267630: Start of release updates for JDK 18 - 8268542: serviceability/logging/TestFullNames.java tests only 1st test case - ... and 397 more: https://git.openjdk.java.net/panama-vector/compare/86a8d382...95fd30ba The webrevs contain the adjustments done while merging with regards to each parent branch: - vectorIntrinsics: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=92&range=00.0 - panama-vector:master: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=92&range=00.1 Changes: https://git.openjdk.java.net/panama-vector/pull/92/files Stats: 159098 lines in 4623 files changed: 79420 ins; 65866 del; 13812 mod Patch: https://git.openjdk.java.net/panama-vector/pull/92.diff Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/92/head:pull/92 PR: https://git.openjdk.java.net/panama-vector/pull/92 From duke at openjdk.java.net Fri Jun 11 18:29:15 2021 From: duke at openjdk.java.net (duke) Date: Fri, 11 Jun 2021 18:29:15 GMT Subject: git: openjdk/panama-foreign: foreign-jextract: 2 new changesets Message-ID: <7669a0f9-f905-4674-a1c3-7ca5981ca1d8@openjdk.org> Changeset: ef8327da Author: Jorn Vernee Date: 2021-06-11 18:27:29 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ef8327da2198b60be51e575a38503992ce63a727 8268266: Investigate way to lazily customize upcall lambda forms Reviewed-by: mcimadamore ! src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/java.base/share/classes/jdk/internal/access/JavaLangInvokeAccess.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/ProgrammableUpcallHandler.java + test/micro/org/openjdk/bench/jdk/incubator/foreign/JNICB.h + test/micro/org/openjdk/bench/jdk/incubator/foreign/JNICB.java + test/micro/org/openjdk/bench/jdk/incubator/foreign/QSort.java ! test/micro/org/openjdk/bench/jdk/incubator/foreign/Upcalls.java + test/micro/org/openjdk/bench/jdk/incubator/foreign/libJNICB.c + test/micro/org/openjdk/bench/jdk/incubator/foreign/libQSort.c + test/micro/org/openjdk/bench/jdk/incubator/foreign/libQSortJNI.c ! test/micro/org/openjdk/bench/jdk/incubator/foreign/libUpcallsJNI.c Changeset: 6dd812ff Author: duke Date: 2021-06-11 18:28:55 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6dd812ffb57d37d4ac44f9f24f9016b0bd52b96e Automatic merge of foreign-memaccess+abi into foreign-jextract From jvernee at openjdk.java.net Fri Jun 11 18:31:10 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Fri, 11 Jun 2021 18:31:10 GMT Subject: [foreign-memaccess+abi] Integrated: 8268266: Investigate way to lazily customize upcall lambda forms In-Reply-To: References: Message-ID: On Thu, 10 Jun 2021 10:02:48 GMT, Jorn Vernee wrote: > Hi, > > This patch makes upcall method handle customization lazy, which helps a lot in reducing the number of lambda form classes generated during for intstance the TestUpcall test, making it complete a lot faster. > > This adds a very slight overhead per call, since there's another indirection, but I think the tradeoff is acceptable. > > Since the patch was otherwise really small, this also adds a qsort benchmark that is also used the measure the cost of the extra indirection. Results are as follows: > > > QSort without lazy customization: > > Benchmark Mode Cnt Score Error Units > QSort.jni_upcall_qsort_naive avgt 30 21096.871 ? 299.669 ns/op > QSort.jni_upcall_qsort_optimized avgt 30 3603.495 ? 16.464 ns/op > QSort.native_qsort avgt 30 96.236 ? 0.713 ns/op > QSort.panama_upcall_qsort avgt 30 937.675 ? 26.160 ns/op > > QSort with lazy customization: > > Benchmark Mode Cnt Score Error Units > QSort.jni_upcall_qsort_naive avgt 30 21454.476 ? 306.135 ns/op > QSort.jni_upcall_qsort_optimized avgt 30 3691.395 ? 35.671 ns/op > QSort.native_qsort avgt 30 97.440 ? 0.894 ns/op > QSort.panama_upcall_qsort avgt 30 1072.929 ? 14.948 ns/op > > > So, while there is some regression from this change, it's not super bad (not integer factor), and I think the tradeoff is worth it to generate fewer lambda form classes, which of course has it's own overhead not visible in this benchmark. > > Thanks, > Jorn This pull request has now been integrated. Changeset: ef8327da Author: Jorn Vernee URL: https://git.openjdk.java.net/panama-foreign/commit/ef8327da2198b60be51e575a38503992ce63a727 Stats: 446 lines in 11 files changed: 387 ins; 52 del; 7 mod 8268266: Investigate way to lazily customize upcall lambda forms Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/553 From jvernee at openjdk.java.net Fri Jun 11 19:53:57 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Fri, 11 Jun 2021 19:53:57 GMT Subject: [foreign-memaccess+abi] RFR: 8268230: Foreign Linker API & Windows user32/kernel32: String conversion seems broken In-Reply-To: References: <0ZOia1B8PO-j284cRHT3_oVVMyWqCBUJT4emLo3BxZQ=.7b226aa8-d1c9-4a08-9910-18deb4ef0a24@github.com> Message-ID: On Fri, 11 Jun 2021 16:43:35 GMT, Duncan Gittins wrote: > I don't think reverse conversion works using Clinker.toJavaString. Good catch, the `toJavaString` version also looks broken, since it looks for the first 0 byte, but that might just be the high-order byte of a character, which just happens to be 0, for wider char sets (for some reason I had assumed this was okay when thinking about it before). Though we use Charset to do the encoding, it's probably not a bad idea to test a couple different strings as well. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/554 From john.r.rose at oracle.com Fri Jun 11 20:52:15 2021 From: john.r.rose at oracle.com (John Rose) Date: Fri, 11 Jun 2021 20:52:15 +0000 Subject: Mapping List to char ** In-Reply-To: <962dc380-d893-1702-64b4-5c3fe4a4a382@oracle.com> References: <962dc380-d893-1702-64b4-5c3fe4a4a382@oracle.com> Message-ID: I reproduced this result in the following script, FTR: http://cr.openjdk.java.net/~jrose/panama/argv-example.jshell I had to invoke shell with `-R--enable-native-access` and `-RALL-UNNAMED argv-example.jshell` options, apparently. Is there a better way to do that? Also, Sebastian?s use case often requires an extra null pointer at the end of the args, so I added that in with Stream.concat: var argv = allocator.allocateArray(CLinker.C_POINTER, Stream.concat(strings.stream().map(s -> CLinker.toCString(s, scope)), Stream.of(MemoryAddress.NULL)).toArray(Addressable[]::new)); var argc = IntStream.range(0,Integer.MAX_VALUE).filter( i->MemoryAccess.getAddressAtIndex(argv,i)==MemoryAddress.NULL ).findFirst().getAsInt(); IntStream.range(0,argc).mapToObj( i->CLinker.toJavaString(MemoryAccess.getAddressAtIndex(argv,i)) ).toList(); ? John P.S. It might be worth having a version of allocator.allocateArray that will *always* add a word or two of all-zero bits to the end of every block. That would help with null termination of all sorts of data structures. It?s a terrible hack, but I?ve seen it used in C libraries. P.P.S. Changing the argv stream to use rangeClosed crashed my JVM, naturally: IntStream.rangeClosed(0,argc).mapToObj( i->CLinker.toJavaString(MemoryAccess.getAddressAtIndex(argv,i)) ).toList(); The problem there was that I fed CLinker.toJavaString with a null native pointer. Oops! It did (for me) raise the question of whether or how to make the Java/C conversion routines more null-friendly. From maurizio.cimadamore at oracle.com Fri Jun 11 21:29:57 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 11 Jun 2021 22:29:57 +0100 Subject: Mapping List to char ** In-Reply-To: References: <962dc380-d893-1702-64b4-5c3fe4a4a382@oracle.com> Message-ID: On 11/06/2021 21:52, John Rose wrote: > I reproduced this result in the following script, FTR: > > http://cr.openjdk.java.net/~jrose/panama/argv-example.jshell > > > I had to invoke shell with `-R--enable-native-access` > and `-RALL-UNNAMED argv-example.jshell` options, > apparently. ?Is there a better way to do that? What I did was jshell --add-modules jdk.incubator.foreign -R--enable-native-access=ALL-UNNAMED Which seems similar. For now that's the best way, we will plan better integration with tools such as jshell in the upcoming releases, so that you can just specify --enable-native-access (and that will be propagated to the runtime). > > Also, Sebastian?s use case often requires an extra null > pointer at the end of the args, so I added that in with > Stream.concat: Whoops yes! > > var argv = allocator.allocateArray(CLinker.C_POINTER, > Stream.concat(strings.stream().map(s -> CLinker.toCString(s, scope)), > Stream.of(MemoryAddress.NULL)).toArray(Addressable[]::new)); > > var argc = IntStream.range(0,Integer.MAX_VALUE).filter( > i->MemoryAccess.getAddressAtIndex(argv,i)==MemoryAddress.NULL > ).findFirst().getAsInt(); > > IntStream.range(0,argc).mapToObj( > i->CLinker.toJavaString(MemoryAccess.getAddressAtIndex(argv,i)) > ).toList(); > > ? John > > P.S. It might be worth having a version of allocator.allocateArray > that will *always* add a word or two of all-zero bits to the > end of every block. ?That would help with null termination > of all sorts of data structures. ?It?s a terrible hack, but I?ve > seen it used in C libraries. Yeah - I think at some point I was pondering about something like that for strings - but are right in that it is more general than just strings. > > P.P.S. ?Changing the argv stream to use rangeClosed crashed > my JVM, naturally: > > IntStream.rangeClosed(0,argc).mapToObj( > i->CLinker.toJavaString(MemoryAccess.getAddressAtIndex(argv,i)) > ).toList(); > > The problem there was that I fed CLinker.toJavaString > with a null native pointer. ?Oops! ?It did (for me) raise the > question of whether or how to make the Java/C conversion > routines more null-friendly. Seems like a case of a missed check in the implementation. We tried to check for MemoryAddress.NULL in various places (for instance, NULL is not a valid target address for a downcall method handle), but the check in the unsafe string conversion method seems to be missing. Filed: https://bugs.openjdk.java.net/browse/JDK-8268633 Thanks Maurizio From john.r.rose at oracle.com Sat Jun 12 03:30:08 2021 From: john.r.rose at oracle.com (John Rose) Date: Fri, 11 Jun 2021 20:30:08 -0700 Subject: Mapping List to char ** In-Reply-To: References: Message-ID: <241A887F-D2F8-4340-B95B-775E47C8AACC@oracle.com> Jshell supports the add-modules option internally via the /env command so I put that in the script. Clearly the /env command and jshell CLI should accept the native-access option as well. > On Jun 11, 2021, at 2:30 PM, Maurizio Cimadamore wrote: > > What I did was > > jshell --add-modules jdk.incubator.foreign -R--enable-native-access=ALL-UNNAMED From elect86 at gmail.com Sun Jun 13 08:31:29 2021 From: elect86 at gmail.com (Giuseppe Barbieri) Date: Sun, 13 Jun 2021 10:31:29 +0200 Subject: problems with libclang Message-ID: Hi, I'm giving a shot at building this myself, but I'm having issue with the clang step Recalling Maurizio's previous suggestion about using pre-compiled llvm instead of the distro ones (btw is this still recommended?), I downloaded from https://releases.llvm.org/download.html the llvm 9.0.0, by using Ubuntu 19.04 (since I'm on Ubuntu 21.04) However, it still complains: https://gist.github.com/elect86/57835001c8e991ff2a98acda4e58b833 Any idea why? Thanks in advance Giuseppe From elect86 at gmail.com Sun Jun 13 12:15:29 2021 From: elect86 at gmail.com (Giuseppe Barbieri) Date: Sun, 13 Jun 2021 14:15:29 +0200 Subject: problems with libclang In-Reply-To: References: Message-ID: It's funny because also the github action script fails at the exactly same point https://github.com/elect86/panama-foreign/runs/2813599221?check_suite_focus=true#step:9:277 Il giorno dom 13 giu 2021 alle ore 10:31 Giuseppe Barbieri < elect86 at gmail.com> ha scritto: > Hi, > > I'm giving a shot at building this myself, but I'm having issue with the > clang step > > Recalling Maurizio's previous suggestion about using pre-compiled llvm > instead of the distro ones (btw is this still recommended?), I downloaded > from > > https://releases.llvm.org/download.html > > the llvm 9.0.0, by using > > Ubuntu 19.04 > > (since I'm on Ubuntu 21.04) > > However, it still complains: > https://gist.github.com/elect86/57835001c8e991ff2a98acda4e58b833 > > Any idea why? > > Thanks in advance > Giuseppe > From elect86 at gmail.com Sun Jun 13 16:52:35 2021 From: elect86 at gmail.com (Giuseppe Barbieri) Date: Sun, 13 Jun 2021 18:52:35 +0200 Subject: problems with libclang In-Reply-To: References: Message-ID: Forget it, fixed with elect at 5800x:~/IdeaProjects/panama-foreign$ bash configure --with-boot-jdk=/home/elect/.jdks/openjdk-16.0.1 --with-libclang=/home/elect/Documents/clang+llvm-12.0.0-x86_64-linux-gnu-ubuntu-20.04 --with-libclang-version=12 Also, I'd add to the readme to specify it works with the latest version, 12, but you have to specify it explicitly Ps: if locations are coherent between distros, I'd still prefer system clang though, just my 2c from a profane :) Giuseppe Il giorno dom 13 giu 2021 alle ore 14:15 Giuseppe Barbieri < elect86 at gmail.com> ha scritto: > It's funny because also the github action script fails at the exactly same > point > > > https://github.com/elect86/panama-foreign/runs/2813599221?check_suite_focus=true#step:9:277 > > Il giorno dom 13 giu 2021 alle ore 10:31 Giuseppe Barbieri < > elect86 at gmail.com> ha scritto: > >> Hi, >> >> I'm giving a shot at building this myself, but I'm having issue with the >> clang step >> >> Recalling Maurizio's previous suggestion about using pre-compiled llvm >> instead of the distro ones (btw is this still recommended?), I downloaded >> from >> >> https://releases.llvm.org/download.html >> >> the llvm 9.0.0, by using >> >> Ubuntu 19.04 >> >> (since I'm on Ubuntu 21.04) >> >> However, it still complains: >> https://gist.github.com/elect86/57835001c8e991ff2a98acda4e58b833 >> >> Any idea why? >> >> Thanks in advance >> Giuseppe >> > From sebastian.stenzel at gmail.com Sun Jun 13 19:04:05 2021 From: sebastian.stenzel at gmail.com (Sebastian Stenzel) Date: Sun, 13 Jun 2021 21:04:05 +0200 Subject: JVM crashes when trying to resolve a "new" method from within an upcall Message-ID: <1FD670FF-C8AC-4350-8270-8FCBC78BA46D@gmail.com> I experience a weird error which might be a regression, as it used to work on a previous EA build (before the introduction of ResourceScopes): I'm still experimenting with a FUSE binding for Java, which involves a lot of upcalls. During these experiments, I noticed that when CLinker.toJavaString() gets called for the _first_ time during an upcall, the JVM crashes (seems to be some kind of NoSuchMethodError, see [1]). However, if the first invocation happens in my "regular" Java context [2], any subsequent invocations [3] succeed as well. Apparently there is no longer any need to look up the method (that's my only explanation so far). The same problems occurs for _any_ method that is used for the first time during an upcall. It is not always possible to do some "dummy invocations" beforehand. Is there anything I need to know about reduced JVM capabilities during upcalls? Or is this a bug? You can reproduce the issue with my project by simply commenting out [2] and then run `HelloPanamaFileSystem.main()`. The first getattr()-call will reliably crash the JVM unless you add [2] back in again. [1] hs_err_pidxyz.log: https://gist.github.com/overheadhunter/320e89c69b48ab6a446c0bfb391ae5d0 [2] fuseMain() invoked on main thread: https://github.com/skymatic/fuse-panama/blob/17369e82ac8ccfadaa068daa3d97635eaf53a9cc/src/main/java/de/skymatic/fusepanama/Fuse.java#L103 [3] e.g. during getAttr() invoked on FUSE worker thread: https://github.com/skymatic/fuse-panama/blob/update-panama/src/main/java/de/skymatic/fusepanama/Fuse.java#L71 From maurizio.cimadamore at oracle.com Mon Jun 14 09:53:27 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 14 Jun 2021 10:53:27 +0100 Subject: JVM crashes when trying to resolve a "new" method from within an upcall In-Reply-To: <1FD670FF-C8AC-4350-8270-8FCBC78BA46D@gmail.com> References: <1FD670FF-C8AC-4350-8270-8FCBC78BA46D@gmail.com> Message-ID: <437ff8e5-02f6-5d2c-ebb3-8a3715b9d4ef@oracle.com> This is odd, our jextract is using the API and it is regularly doing things like the one you describe (e.g. calling CLinker methods inside upcalls). That said, toJavaString is a restricted method, so there might well be something in the support for restricted method that doesn't play well with upcalls (but that's also odd, given there should be a caller class in there somewhere). We'll look more into this. Thanks Maurizio On 13/06/2021 20:04, Sebastian Stenzel wrote: > I experience a weird error which might be a regression, as it used to work on a previous EA build (before the introduction of ResourceScopes): > > I'm still experimenting with a FUSE binding for Java, which involves a lot of upcalls. During these experiments, I noticed that when CLinker.toJavaString() gets called for the _first_ time during an upcall, the JVM crashes (seems to be some kind of NoSuchMethodError, see [1]). > > However, if the first invocation happens in my "regular" Java context [2], any subsequent invocations [3] succeed as well. Apparently there is no longer any need to look up the method (that's my only explanation so far). > > The same problems occurs for _any_ method that is used for the first time during an upcall. It is not always possible to do some "dummy invocations" beforehand. > > Is there anything I need to know about reduced JVM capabilities during upcalls? Or is this a bug? You can reproduce the issue with my project by simply commenting out [2] and then run `HelloPanamaFileSystem.main()`. The first getattr()-call will reliably crash the JVM unless you add [2] back in again. > > [1] hs_err_pidxyz.log: https://gist.github.com/overheadhunter/320e89c69b48ab6a446c0bfb391ae5d0 > [2] fuseMain() invoked on main thread: https://github.com/skymatic/fuse-panama/blob/17369e82ac8ccfadaa068daa3d97635eaf53a9cc/src/main/java/de/skymatic/fusepanama/Fuse.java#L103 > [3] e.g. during getAttr() invoked on FUSE worker thread: https://github.com/skymatic/fuse-panama/blob/update-panama/src/main/java/de/skymatic/fusepanama/Fuse.java#L71 > From maurizio.cimadamore at oracle.com Mon Jun 14 09:58:36 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 14 Jun 2021 10:58:36 +0100 Subject: problems with libclang In-Reply-To: References: Message-ID: <93d79a39-8023-81e0-ae48-8cdc0606b3cd@oracle.com> My $0.02 is that the first LLVM bundle you tried was not correct. I had this problem myself on 20.04 - e.g. the llvm for 19.04 does not work, as it's probably compiled against different libraries. My recommendation is that you always try, after downloading the pre-built binary, to run bin/clang on the downloaded distribution and see if that works. In my case that 19.04 download did *not* work. So, like, you, I had to use a newer one and override the libclang-version. Maurizio On 13/06/2021 17:52, Giuseppe Barbieri wrote: > Forget it, fixed with > > elect at 5800x:~/IdeaProjects/panama-foreign$ bash configure > --with-boot-jdk=/home/elect/.jdks/openjdk-16.0.1 > --with-libclang=/home/elect/Documents/clang+llvm-12.0.0-x86_64-linux-gnu-ubuntu-20.04 > --with-libclang-version=12 > > Also, I'd add to the readme to specify it works with the latest version, > 12, but you have to specify it explicitly > > Ps: if locations are coherent between distros, I'd still prefer system > clang though, just my 2c from a profane :) > > Giuseppe > > Il giorno dom 13 giu 2021 alle ore 14:15 Giuseppe Barbieri < > elect86 at gmail.com> ha scritto: > >> It's funny because also the github action script fails at the exactly same >> point >> >> >> https://github.com/elect86/panama-foreign/runs/2813599221?check_suite_focus=true#step:9:277 >> >> Il giorno dom 13 giu 2021 alle ore 10:31 Giuseppe Barbieri < >> elect86 at gmail.com> ha scritto: >> >>> Hi, >>> >>> I'm giving a shot at building this myself, but I'm having issue with the >>> clang step >>> >>> Recalling Maurizio's previous suggestion about using pre-compiled llvm >>> instead of the distro ones (btw is this still recommended?), I downloaded >>> from >>> >>> https://releases.llvm.org/download.html >>> >>> the llvm 9.0.0, by using >>> >>> Ubuntu 19.04 >>> >>> (since I'm on Ubuntu 21.04) >>> >>> However, it still complains: >>> https://gist.github.com/elect86/57835001c8e991ff2a98acda4e58b833 >>> >>> Any idea why? >>> >>> Thanks in advance >>> Giuseppe >>> From maurizio.cimadamore at oracle.com Mon Jun 14 11:01:17 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 14 Jun 2021 12:01:17 +0100 Subject: JVM crashes when trying to resolve a "new" method from within an upcall In-Reply-To: <437ff8e5-02f6-5d2c-ebb3-8a3715b9d4ef@oracle.com> References: <1FD670FF-C8AC-4350-8270-8FCBC78BA46D@gmail.com> <437ff8e5-02f6-5d2c-ebb3-8a3715b9d4ef@oracle.com> Message-ID: <5fbb62ad-1dc8-bb4f-3a67-2fe48f71ca5f@oracle.com> Hi, it seems a problem with upcall optimization not working correctly when upcall is called from a "fresh" thread created in native code. We'll work on a fix (Jorn tells me that JNI already correctly handles these cases), in the meanwhile, you can obtain the "old" behavior by disabling upcall optimizations, by passing the following flag: -Djdk.internal.foreign.ProgrammableUpcallHandler.USE_INTRINSICS=false Cheers Maurizio On 14/06/2021 10:53, Maurizio Cimadamore wrote: > This is odd, our jextract is using the API and it is regularly doing > things like the one you describe (e.g. calling CLinker methods inside > upcalls). > > That said, toJavaString is a restricted method, so there might well be > something in the support for restricted method that doesn't play well > with upcalls (but that's also odd, given there should be a caller > class in there somewhere). > > We'll look more into this. > > Thanks > Maurizio > > On 13/06/2021 20:04, Sebastian Stenzel wrote: >> I experience a weird error which might be a regression, as it used to >> work on a previous EA build (before the introduction of ResourceScopes): >> >> I'm still experimenting with a FUSE binding for Java, which involves >> a lot of upcalls. During these experiments, I noticed that when >> CLinker.toJavaString() gets called for the _first_ time during an >> upcall, the JVM crashes (seems to be some kind of NoSuchMethodError, >> see [1]). >> >> However, if the first invocation happens in my "regular" Java context >> [2], any subsequent invocations [3] succeed as well. Apparently there >> is no longer any need to look up the method (that's my only >> explanation so far). >> >> The same problems occurs for _any_ method that is used for the first >> time during an upcall. It is not always possible to do some "dummy >> invocations" beforehand. >> >> Is there anything I need to know about reduced JVM capabilities >> during upcalls? Or is this a bug? You can reproduce the issue with my >> project by simply commenting out [2] and then run >> `HelloPanamaFileSystem.main()`. The first getattr()-call will >> reliably crash the JVM unless you add [2] back in again. >> >> [1] hs_err_pidxyz.log: >> https://gist.github.com/overheadhunter/320e89c69b48ab6a446c0bfb391ae5d0 >> >> >> [2] fuseMain() invoked on main thread: >> https://github.com/skymatic/fuse-panama/blob/17369e82ac8ccfadaa068daa3d97635eaf53a9cc/src/main/java/de/skymatic/fusepanama/Fuse.java#L103 >> >> >> [3] e.g. during getAttr() invoked on FUSE worker thread: >> https://github.com/skymatic/fuse-panama/blob/update-panama/src/main/java/de/skymatic/fusepanama/Fuse.java#L71 >> >> >> From sebastian.stenzel at gmail.com Mon Jun 14 11:11:11 2021 From: sebastian.stenzel at gmail.com (Sebastian Stenzel) Date: Mon, 14 Jun 2021 13:11:11 +0200 Subject: JVM crashes when trying to resolve a "new" method from within an upcall In-Reply-To: <5fbb62ad-1dc8-bb4f-3a67-2fe48f71ca5f@oracle.com> References: <1FD670FF-C8AC-4350-8270-8FCBC78BA46D@gmail.com> <437ff8e5-02f6-5d2c-ebb3-8a3715b9d4ef@oracle.com> <5fbb62ad-1dc8-bb4f-3a67-2fe48f71ca5f@oracle.com> Message-ID: <49D483A8-3C1D-4EF8-9FBD-476E0E5736E3@gmail.com> Thanks for replying that fast (again), I can confirm the flag works! Looking forward to a fix. :-) > On 14. Jun 2021, at 13:01, Maurizio Cimadamore wrote: > > Hi, > it seems a problem with upcall optimization not working correctly when upcall is called from a "fresh" thread created in native code. > > We'll work on a fix (Jorn tells me that JNI already correctly handles these cases), in the meanwhile, you can obtain the "old" behavior by disabling upcall optimizations, by passing the following flag: > > -Djdk.internal.foreign.ProgrammableUpcallHandler.USE_INTRINSICS=false > > Cheers > Maurizio > > On 14/06/2021 10:53, Maurizio Cimadamore wrote: >> This is odd, our jextract is using the API and it is regularly doing things like the one you describe (e.g. calling CLinker methods inside upcalls). >> >> That said, toJavaString is a restricted method, so there might well be something in the support for restricted method that doesn't play well with upcalls (but that's also odd, given there should be a caller class in there somewhere). >> >> We'll look more into this. >> >> Thanks >> Maurizio >> >> On 13/06/2021 20:04, Sebastian Stenzel wrote: >>> I experience a weird error which might be a regression, as it used to work on a previous EA build (before the introduction of ResourceScopes): >>> >>> I'm still experimenting with a FUSE binding for Java, which involves a lot of upcalls. During these experiments, I noticed that when CLinker.toJavaString() gets called for the _first_ time during an upcall, the JVM crashes (seems to be some kind of NoSuchMethodError, see [1]). >>> >>> However, if the first invocation happens in my "regular" Java context [2], any subsequent invocations [3] succeed as well. Apparently there is no longer any need to look up the method (that's my only explanation so far). >>> >>> The same problems occurs for _any_ method that is used for the first time during an upcall. It is not always possible to do some "dummy invocations" beforehand. >>> >>> Is there anything I need to know about reduced JVM capabilities during upcalls? Or is this a bug? You can reproduce the issue with my project by simply commenting out [2] and then run `HelloPanamaFileSystem.main()`. The first getattr()-call will reliably crash the JVM unless you add [2] back in again. >>> >>> [1] hs_err_pidxyz.log: https://gist.github.com/overheadhunter/320e89c69b48ab6a446c0bfb391ae5d0 >>> [2] fuseMain() invoked on main thread: https://github.com/skymatic/fuse-panama/blob/17369e82ac8ccfadaa068daa3d97635eaf53a9cc/src/main/java/de/skymatic/fusepanama/Fuse.java#L103 >>> [3] e.g. during getAttr() invoked on FUSE worker thread: https://github.com/skymatic/fuse-panama/blob/update-panama/src/main/java/de/skymatic/fusepanama/Fuse.java#L71 >>> From elect86 at gmail.com Mon Jun 14 11:46:08 2021 From: elect86 at gmail.com (Giuseppe Barbieri) Date: Mon, 14 Jun 2021 13:46:08 +0200 Subject: MethodHandler out of a non-static method In-Reply-To: <243056011.1075978.1623141273942.JavaMail.zimbra@u-pem.fr> References: <243056011.1075978.1623141273942.JavaMail.zimbra@u-pem.fr> Message-ID: Ok, I'm giving a try and use `::findVirtual` instead MethodHandle displayHandle = MethodHandles.lookup().findVirtual(teapot.getClass(), "display", MethodType.methodType(void.class)); MemoryAddress displayStub = CLinker.getInstance().upcallStub(displayHandle, FunctionDescriptor.ofVoid(), scope); this fires: Exception in thread "main" java.lang.IllegalArgumentException: Arity mismatch: (Teapot)void != ()v at jdk.incubator.foreign/jdk.internal.foreign.abi.SharedUtils.checkFunctionTypes(SharedUtils.java:237) at jdk.incubator.foreign/jdk.internal.foreign.abi.x64.sysv.CallArranger.getBindings(CallArranger.java:89) at jdk.incubator.foreign/jdk.internal.foreign.abi.x64.sysv.CallArranger.arrangeUpcall(CallArranger.java:138) at jdk.incubator.foreign/jdk.internal.foreign.abi.x64.sysv.SysVx64Linker.upcallStub(SysVx64Linker.java:111) at Teapot.main(Teapot.java:61) I can see the signature coherent with what you said. `::findVirtual` does return signature of (Teapot)void So the problems seems to be inside FunctionDescriptor.ofVoid() or? Just for context, this is the signature of the function expecting `displayStub` glutDisplayFunc(Addressable var0) And I also have MethodHandle glutDisplayFunc$MH() but I have no idea if this might play a role in this Il giorno mar 8 giu 2021 alle ore 10:34 Remi Forax ha scritto: > > > > Another question, I'm trying to setup a test project with Gradle, but I'm > > having a lot of issues, mainly because Gradle supports only up to jdk 16. > > Don't use Gradle with a not yet released JDK. > Gradle is very smart in the way it incrementally compile things, but it > has the price of not working with unreleased JDK. > A plain old Maven pom file is usually enough. > This is quite a pity, because other than I'm used to relying on Gradle, it actually can automate a lot and make the lives of us devs much nicer. I'm actually working in this sense on the existing jextract plugin, enhancing it. Also, just to say, Gradle actually works with the latest panama 17 build on the website, I managed to get the opengl example running under Java (with the modification above regarding callbacks) The only problem I got so far, it's that I can't get it to work with Kotlin, I keep getting errors on the imports, such as import jdk.incubator.ResourceScope I wonder if anyone here had success with it Giuseppe Il giorno mar 8 giu 2021 alle ore 10:34 Remi Forax ha scritto: > ----- Mail original ----- > > De: "Giuseppe Barbieri" > > ?: "Maurizio Cimadamore" > > Cc: "panama-dev at openjdk.java.net'" > > Envoy?: Mardi 8 Juin 2021 09:26:15 > > Objet: Re: MethodHandler out of a non-static method > > > Thanks Maurizio and Remi, that helped > > > > Playing around I also got it working by using `bind` > > > > var displayHandle = MethodHandles.lookup().bind(teapot, "display", > > MethodType.methodType(void.class)); > > var displayStub = CLinker.getInstance().upcallStub(displayHandle, > > FunctionDescriptor.ofVoid(), scope); > > > > > > What's the difference? Because I'd expect for `findVirtual` to be used > only > > on methods in implementation classes of abstract classes > > A method handle unlike its name suggest is a function pointer, not a > method pointer. > So when you take a method and ask for a function pointer to it, you have a > supplementary first parameter, the one corresponding to this. > > By example, for > class A { > void foo(int i) { ... } > } > > findVirtual returns a method handle with the signature: void foo(A this, > int i) > > if you want to call a method handle always on the same instance, you can > use bindTo() (or insertArguments), > to say that the first argument is always that same > > var a = new A(); > var mh = ... > var boundMH = mh.bindTo(a); > > Here, boundMH is "void foo(A this, int i)" with this = a > so it's a function with only one parameter, i of type int. > > Now what bind() does is findVirtual(getClass(), ...) + bindTo, > on your example > var mh = lookup.findVirtual(teapot.getClass(), "display", > MethodType.methodType(void.class)); > mh = mh.bindTo(teapot); > > This idea that when you want to see a method as a function, you can pass > the receiver (the value of 'this') as first argument is something very > common in programming language, > you have it with method handle but you also have it when using method > reference in Java or bound method in Python [1], the method bind in > JavaScript [2], etc. > > Using method reference: > // method reference seen as a function > BiConsumer consumer = PrintStream::println; > > // bound method reference > PrintStream out = System.out; > Consumer consumer = out::println; > > > > > > Another question, I'm trying to setup a test project with Gradle, but I'm > > having a lot of issues, mainly because Gradle supports only up to jdk 16. > > Don't use Gradle with a not yet released JDK. > Gradle is very smart in the way it incrementally compile things, but it > has the price of not working with unreleased JDK. > A plain old Maven pom file is usually enough. > > > > > Is possible to run your application with a separate jdk (toolchain) but > > then you need to use the `application` plugin and cannot rely anymore on > > the comfortable Idea UI. > > Unless you switch and run your code using the IDE instead of Gradle, but > > then I get into some other exceptions. Moreover, some imports remain > still > > unresolved. > > > > So, I'd like to skip this trainwreck all at once and ask directly if > > anybody here has a working base scenario with the latest EA jdk 17 and > > Gradle > > > > > > Thanks in advance > > regards, > R?mi > > [1] https://www.quora.com/What-is-a-bound-method-in-Python > [2] > https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Function/bind > > > > > > > > > Il giorno gio 3 giu 2021 alle ore 11:33 Maurizio Cimadamore < > > maurizio.cimadamore at oracle.com> ha scritto: > > > >> Hi Giuseppe > >> > >> On 02/06/2021 23:52, Giuseppe Barbieri wrote: > >> > Hi, > >> > > >> > excited from the last development, I came back giving a try to the > latest > >> > jdk build (the partial 17 available on the site) and I'm trying to > >> > update/fix the opengl sample > >> > > >> > First of all, it looks like `jextract` doesn't accept anymore the > option > >> to > >> > produce an output jar. I had to manually compress the resulting > folder to > >> > zip and rename, before importing in the target project. > >> > >> We decided to simplify jextract and focus on source code generation, > >> which seems to be the mode that most people want to work with, and it's > >> also the "more primitive": you can derive classes (and jars) from it. > >> > >> If you are using it in a project, you might consider directly checking > >> in the extracted sources in your project. If you are using an IDE, it is > >> going to improve your experience a little bit (the classfiles generated > >> by the old jextract were poorly understood by some of the IDEs out > >> there, which led to issues in indexing). > >> > > > > > > > > > > > >> > >> > > >> > It'd be cool if jextract could output directly the jar (and the > sources) > >> > > >> > Coming back to my issue, how can I retrieve the MethodHandler out of a > >> > non-static method? > >> > >> You mean you want to create a MethodHandle for an instance method? > >> > >> Let's see (I'll use jshell to make sure my code doesn't have any typos > >> :-) ): > >> > >> ``` > >> jshell> class Foo { > >> ...> void greet(String msg) { System.out.println(msg); } > >> ...> } > >> | created class Foo > >> > >> jshell> import java.lang.invoke.*; > >> > >> jshell> MethodHandle greetMH = > >> MethodHandles.lookup().findVirtual(Foo.class, "greet", > >> MethodType.methodType(void.class, String.class)); > >> greetMH ==> MethodHandle(Foo,String)void > >> > >> jshell> greetMH.invoke(new Foo(), "Panama"); > >> Panama > >> ``` > >> > >> Is this what you were looking for? > >> > >> Cheers > >> Maurizio > >> > >> > > >> > > >> > Thanks in advance > From maurizio.cimadamore at oracle.com Mon Jun 14 11:59:33 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 14 Jun 2021 12:59:33 +0100 Subject: MethodHandler out of a non-static method In-Reply-To: References: <243056011.1075978.1623141273942.JavaMail.zimbra@u-pem.fr> Message-ID: Hi Giuseppe, since you use a "virtual" method handle, you should first "bind it" to the receiver instance you want (using MethodHandle::bindTo). E.g. CLinker.getInstance().upcallStub(displayHandle.bindTo(teapotInstance),FunctionDescriptor.ofVoid(), scope); Maurizio On 14/06/2021 12:46, Giuseppe Barbieri wrote: > Ok, I'm giving a try and use `::findVirtual` instead > MethodHandle displayHandle =MethodHandles.lookup().findVirtual(teapot.getClass(),"display",MethodType.methodType(void.class)); > MemoryAddress displayStub =CLinker.getInstance().upcallStub(displayHandle,FunctionDescriptor.ofVoid(), scope); > this fires: > Exception in thread "main" java.lang.IllegalArgumentException: Arity > mismatch: (Teapot)void != ()v > at > jdk.incubator.foreign/jdk.internal.foreign.abi.SharedUtils.checkFunctionTypes(SharedUtils.java:237) > at > jdk.incubator.foreign/jdk.internal.foreign.abi.x64.sysv.CallArranger.getBindings(CallArranger.java:89) > at > jdk.incubator.foreign/jdk.internal.foreign.abi.x64.sysv.CallArranger.arrangeUpcall(CallArranger.java:138) > at > jdk.incubator.foreign/jdk.internal.foreign.abi.x64.sysv.SysVx64Linker.upcallStub(SysVx64Linker.java:111) > at Teapot.main(Teapot.java:61) > > I can see the signature coherent with what you said. `::findVirtual` > does return signature of (Teapot)void > > So the problems seems to be inside > FunctionDescriptor.ofVoid() > or? > > Just for context, this is the signature of the function expecting > `displayStub` > glutDisplayFunc(Addressable var0) > And I also have > MethodHandle glutDisplayFunc$MH() > but I have no idea if this might play a role in this > > > Il giorno mar 8 giu 2021 alle ore 10:34 Remi Forax > ha scritto: > > > > > Another question, I'm trying to setup a test project with > Gradle, but I'm > > having a lot of issues, mainly because Gradle supports only up > to jdk 16. > > Don't use Gradle with a not yet released JDK. > Gradle is very smart in the way it incrementally compile things, > but it has the price of not working with unreleased JDK. > A plain old Maven pom file is usually enough. > > > This is quite a pity, because other than I'm used to relying on > Gradle, it actually can automate a lot and make the lives of us devs > much nicer. > I'm actually working in this sense on the existing jextract plugin, > enhancing it. > > Also, just to say, Gradle actually works with the latest panama 17 > build on the website, I managed to get the opengl example running > under Java (with the modification above regarding callbacks) > > The only problem I got so far, it's that I can't get it to work with > Kotlin, I keep getting errors on the imports, such as > import jdk.incubator.ResourceScope > I wonder if anyone here had success with it > > > Giuseppe > > Il giorno mar 8 giu 2021 alle ore 10:34 Remi Forax > ha scritto: > > ----- Mail original ----- > > De: "Giuseppe Barbieri" > > > ?: "Maurizio Cimadamore" > > > Cc: "panama-dev at openjdk.java.net > '" > > > > Envoy?: Mardi 8 Juin 2021 09:26:15 > > Objet: Re: MethodHandler out of a non-static method > > > Thanks Maurizio and Remi, that helped > > > > Playing around I also got it working by using `bind` > > > > var displayHandle = MethodHandles.lookup().bind(teapot, "display", > > MethodType.methodType(void.class)); > > var displayStub = CLinker.getInstance().upcallStub(displayHandle, > > FunctionDescriptor.ofVoid(), scope); > > > > > > What's the difference? Because I'd expect for `findVirtual` to > be used only > > on methods in implementation classes of abstract classes > > A method handle unlike its name suggest is a function pointer, not > a method pointer. > So when you take a method and ask for a function pointer to it, > you have a supplementary first parameter, the one corresponding to > this. > > By example, for > ?class A { > ? ?void foo(int i) { ... } > ?} > > findVirtual returns a method handle with the signature: void foo(A > this, int i) > > if you want to call a method handle always on the same instance, > you can use bindTo() (or insertArguments), > to say that the first argument is always that same > > ? var a = new A(); > ? var mh = ... > ? var boundMH = mh.bindTo(a); > > Here, boundMH is "void foo(A this, int i)" with this = a > so it's a function with only one parameter, i of type int. > > Now what bind() does is findVirtual(getClass(), ...) + bindTo, > on your example > ? var mh = lookup.findVirtual(teapot.getClass(), "display", > MethodType.methodType(void.class)); > ? mh = mh.bindTo(teapot); > > This idea that when you want to see a method as a function, you > can pass the receiver (the value of 'this') as first argument is > something very common in programming language, > you have it with method handle but you also have it when using > method reference in Java or bound method in Python [1], the method > bind in JavaScript [2], etc. > > Using method reference: > ? // method reference seen as a function > ? BiConsumer consumer = PrintStream::println; > > ? // bound method reference > ? PrintStream out = System.out; > ? Consumer consumer = out::println; > > > > > > Another question, I'm trying to setup a test project with > Gradle, but I'm > > having a lot of issues, mainly because Gradle supports only up > to jdk 16. > > Don't use Gradle with a not yet released JDK. > Gradle is very smart in the way it incrementally compile things, > but it has the price of not working with unreleased JDK. > A plain old Maven pom file is usually enough. > > > > > Is possible to run your application with a separate jdk > (toolchain) but > > then you need to use the `application` plugin and cannot rely > anymore on > > the comfortable Idea UI. > > Unless you switch and run your code using the IDE instead of > Gradle, but > > then I get into some other exceptions. Moreover, some imports > remain still > > unresolved. > > > > So, I'd like to skip this trainwreck all at once and ask directly if > > anybody here has a working base scenario with the latest EA jdk > 17 and > > Gradle > > > > > > Thanks in advance > > regards, > R?mi > > [1] https://www.quora.com/What-is-a-bound-method-in-Python > > [2] > https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Function/bind > > > > > > > > > > Il giorno gio 3 giu 2021 alle ore 11:33 Maurizio Cimadamore < > > maurizio.cimadamore at oracle.com > > ha scritto: > > > >> Hi Giuseppe > >> > >> On 02/06/2021 23:52, Giuseppe Barbieri wrote: > >> > Hi, > >> > > >> > excited from the last development, I came back giving a try > to the latest > >> > jdk build (the partial 17 available on the site) and I'm > trying to > >> > update/fix the opengl sample > >> > > >> > First of all, it looks like `jextract` doesn't accept anymore > the option > >> to > >> > produce an output jar. I had to manually compress the > resulting folder to > >> > zip and rename, before importing in the target project. > >> > >> We decided to simplify jextract and focus on source code > generation, > >> which seems to be the mode that most people want to work with, > and it's > >> also the "more primitive": you can derive classes (and jars) > from it. > >> > >> If you are using it in a project, you might consider directly > checking > >> in the extracted sources in your project. If you are using an > IDE, it is > >> going to improve your experience a little bit (the classfiles > generated > >> by the old jextract were poorly understood by some of the IDEs out > >> there, which led to issues in indexing). > >> > > > > > > > > > > > >> > >> > > >> > It'd be cool if jextract could output directly the jar (and > the sources) > >> > > >> > Coming back to my issue, how can I retrieve the MethodHandler > out of a > >> > non-static method? > >> > >> You mean you want to create a MethodHandle for an instance method? > >> > >> Let's see (I'll use jshell to make sure my code doesn't have > any typos > >> :-) ): > >> > >> ``` > >> jshell> class Foo { > >>? ? ?...> void greet(String msg) { System.out.println(msg); } > >>? ? ?...> } > >> |? created class Foo > >> > >> jshell> import java.lang.invoke.*; > >> > >> jshell> MethodHandle greetMH = > >> MethodHandles.lookup().findVirtual(Foo.class, "greet", > >> MethodType.methodType(void.class, String.class)); > >> greetMH ==> MethodHandle(Foo,String)void > >> > >> jshell> greetMH.invoke(new Foo(), "Panama"); > >> Panama > >> ``` > >> > >> Is this what you were looking for? > >> > >> Cheers > >> Maurizio > >> > >> > > >> > > >> > Thanks in advance > From jvernee at openjdk.java.net Mon Jun 14 12:20:01 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Mon, 14 Jun 2021 12:20:01 GMT Subject: [foreign-memaccess+abi] RFR: 8268673: Stack walk across optimized entry frame on fresh native thread fails Message-ID: Hi, When native code creates a new thread and calls a Panama upcall, and during that upcall a stack walk is triggered, getting the sender frame for the entry frame is not possible, and should not be attempted. For JNI this case is handled already by indicating the end of the stack frame stream, but for Panama upcalls it is not, and the VM will either hit an assert or crash when trying to find the last Java frame before the entry frame (which does not exist in this case). This patch adds handling for panama upcalls frames to `frame::is_first_frame`, which is used by the stack walking code to determine when to stop walking. Thanks, Jorn ------------- Commit messages: - Fix async stack walks Changes: https://git.openjdk.java.net/panama-foreign/pull/558/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=558&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268673 Stats: 194 lines in 11 files changed: 193 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/558.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/558/head:pull/558 PR: https://git.openjdk.java.net/panama-foreign/pull/558 From jvernee at openjdk.java.net Mon Jun 14 12:20:02 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Mon, 14 Jun 2021 12:20:02 GMT Subject: [foreign-memaccess+abi] RFR: 8268673: Stack walk across optimized entry frame on fresh native thread fails In-Reply-To: References: Message-ID: On Mon, 14 Jun 2021 12:13:52 GMT, Jorn Vernee wrote: > Hi, > > When native code creates a new thread and calls a Panama upcall, and during that upcall a stack walk is triggered, getting the sender frame for the entry frame is not possible, and should not be attempted. > > For JNI this case is handled already by indicating the end of the stack frame stream, but for Panama upcalls it is not, and the VM will either hit an assert or crash when trying to find the last Java frame before the entry frame (which does not exist in this case). > > This patch adds handling for panama upcalls frames to `frame::is_first_frame`, which is used by the stack walking code to determine when to stop walking. > > Thanks, > Jorn src/hotspot/share/prims/whitebox.cpp line 2309: > 2307: tty->print_cr("[WhiteBox::VerifyFrames] Walking Frames"); > 2308: } > 2309: ResourceMark rm; // for verify Ran into an assert when testing because of a missing resource mark here, so I've added that as well. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/558 From jvernee at openjdk.java.net Mon Jun 14 12:38:03 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Mon, 14 Jun 2021 12:38:03 GMT Subject: [foreign-memaccess+abi] RFR: 8268673: Stack walk across optimized entry frame on fresh native thread fails [v2] In-Reply-To: References: Message-ID: <7EpAkMVsdQ-gKH6bK8BvhUWS5GFFiQef2txcM7IT5Qs=.4cb3c0c1-4e87-46a7-8293-9238f0bd9787@github.com> > Hi, > > When native code creates a new thread and calls a Panama upcall, and during that upcall a stack walk is triggered, getting the sender frame for the entry frame is not possible, and should not be attempted. > > For JNI this case is handled already by indicating the end of the stack frame stream, but for Panama upcalls it is not, and the VM will either hit an assert or crash when trying to find the last Java frame before the entry frame (which does not exist in this case). > > This patch adds handling for panama upcalls frames to `frame::is_first_frame`, which is used by the stack walking code to determine when to stop walking. > > Thanks, > Jorn Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: Missing from previous commit ------------- Changes: - all: https://git.openjdk.java.net/panama-foreign/pull/558/files - new: https://git.openjdk.java.net/panama-foreign/pull/558/files/a34d088c..50fd53c2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=558&range=01 - incr: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=558&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/558.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/558/head:pull/558 PR: https://git.openjdk.java.net/panama-foreign/pull/558 From mcimadamore at openjdk.java.net Mon Jun 14 12:46:13 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 14 Jun 2021 12:46:13 GMT Subject: [foreign-memaccess+abi] RFR: 8268673: Stack walk across optimized entry frame on fresh native thread fails [v2] In-Reply-To: <7EpAkMVsdQ-gKH6bK8BvhUWS5GFFiQef2txcM7IT5Qs=.4cb3c0c1-4e87-46a7-8293-9238f0bd9787@github.com> References: <7EpAkMVsdQ-gKH6bK8BvhUWS5GFFiQef2txcM7IT5Qs=.4cb3c0c1-4e87-46a7-8293-9238f0bd9787@github.com> Message-ID: On Mon, 14 Jun 2021 12:38:03 GMT, Jorn Vernee wrote: >> Hi, >> >> When native code creates a new thread and calls a Panama upcall, and during that upcall a stack walk is triggered, getting the sender frame for the entry frame is not possible, and should not be attempted. >> >> For JNI this case is handled already by indicating the end of the stack frame stream, but for Panama upcalls it is not, and the VM will either hit an assert or crash when trying to find the last Java frame before the entry frame (which does not exist in this case). >> >> This patch adds handling for panama upcalls frames to `frame::is_first_frame`, which is used by the stack walking code to determine when to stop walking. >> >> Thanks, >> Jorn > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > Missing from previous commit Looks good ------------- Marked as reviewed by mcimadamore (Committer). PR: https://git.openjdk.java.net/panama-foreign/pull/558 From duke at openjdk.java.net Mon Jun 14 15:07:21 2021 From: duke at openjdk.java.net (duke) Date: Mon, 14 Jun 2021 15:07:21 GMT Subject: git: openjdk/panama-foreign: foreign-jextract: 2 new changesets Message-ID: <3e1c6fa5-6463-40d1-ad3b-6a473dec935a@openjdk.org> Changeset: 2287ca5a Author: Jorn Vernee Date: 2021-06-14 15:04:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2287ca5a530c348bc4ec7c0c6774e8ed9101dffa 8268673: Stack walk across optimized entry frame on fresh native thread fails Reviewed-by: mcimadamore ! src/hotspot/cpu/aarch64/frame_aarch64.cpp ! src/hotspot/cpu/arm/frame_arm.cpp ! src/hotspot/cpu/ppc/frame_ppc.cpp ! src/hotspot/cpu/s390/frame_s390.cpp ! src/hotspot/cpu/x86/frame_x86.cpp ! src/hotspot/cpu/zero/frame_zero.cpp ! src/hotspot/share/prims/whitebox.cpp ! src/hotspot/share/runtime/frame.hpp ! src/hotspot/share/runtime/frame.inline.hpp + test/jdk/java/foreign/stackwalk/TestAsyncStackWalk.java + test/jdk/java/foreign/stackwalk/libAsyncStackWalk.cpp Changeset: 835497ba Author: duke Date: 2021-06-14 15:06:00 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/835497bae8f08f0ee104c4850bb385b64be100b8 Automatic merge of foreign-memaccess+abi into foreign-jextract From jvernee at openjdk.java.net Mon Jun 14 15:09:48 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Mon, 14 Jun 2021 15:09:48 GMT Subject: [foreign-memaccess+abi] RFR: 8268673: Stack walk across optimized entry frame on fresh native thread fails [v2] In-Reply-To: <7EpAkMVsdQ-gKH6bK8BvhUWS5GFFiQef2txcM7IT5Qs=.4cb3c0c1-4e87-46a7-8293-9238f0bd9787@github.com> References: <7EpAkMVsdQ-gKH6bK8BvhUWS5GFFiQef2txcM7IT5Qs=.4cb3c0c1-4e87-46a7-8293-9238f0bd9787@github.com> Message-ID: On Mon, 14 Jun 2021 12:38:03 GMT, Jorn Vernee wrote: >> Hi, >> >> When native code creates a new thread and calls a Panama upcall, and during that upcall a stack walk is triggered, getting the sender frame for the entry frame is not possible, and should not be attempted. >> >> For JNI this case is handled already by indicating the end of the stack frame stream, but for Panama upcalls it is not, and the VM will either hit an assert or crash when trying to find the last Java frame before the entry frame (which does not exist in this case). >> >> This patch adds handling for panama upcalls frames to `frame::is_first_frame`, which is used by the stack walking code to determine when to stop walking. >> >> Thanks, >> Jorn > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > Missing from previous commit test/jdk/java/foreign/stackwalk/TestAsyncStackWalk.java line 2: > 1: /* > 2: * Copyright (c) 2020, 2021, Oracle and/or its affiliates. All rights reserved. Suggestion: * Copyright (c) 2021, Oracle and/or its affiliates. All rights reserved. test/jdk/java/foreign/stackwalk/libAsyncStackWalk.cpp line 2: > 1: /* > 2: * Copyright (c) 2020, Oracle and/or its affiliates. All rights reserved. Suggestion: * Copyright (c) 2021, Oracle and/or its affiliates. All rights reserved. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/558 From jvernee at openjdk.java.net Mon Jun 14 15:09:44 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Mon, 14 Jun 2021 15:09:44 GMT Subject: [foreign-memaccess+abi] RFR: 8268673: Stack walk across optimized entry frame on fresh native thread fails [v3] In-Reply-To: References: Message-ID: > Hi, > > When native code creates a new thread and calls a Panama upcall, and during that upcall a stack walk is triggered, getting the sender frame for the entry frame is not possible, and should not be attempted. > > For JNI this case is handled already by indicating the end of the stack frame stream, but for Panama upcalls it is not, and the VM will either hit an assert or crash when trying to find the last Java frame before the entry frame (which does not exist in this case). > > This patch adds handling for panama upcalls frames to `frame::is_first_frame`, which is used by the stack walking code to determine when to stop walking. > > Thanks, > Jorn Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: Fix copyright years ------------- Changes: - all: https://git.openjdk.java.net/panama-foreign/pull/558/files - new: https://git.openjdk.java.net/panama-foreign/pull/558/files/50fd53c2..e0bfd8c0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=558&range=02 - incr: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=558&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/558.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/558/head:pull/558 PR: https://git.openjdk.java.net/panama-foreign/pull/558 From jvernee at openjdk.java.net Mon Jun 14 15:09:52 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Mon, 14 Jun 2021 15:09:52 GMT Subject: [foreign-memaccess+abi] Integrated: 8268673: Stack walk across optimized entry frame on fresh native thread fails In-Reply-To: References: Message-ID: On Mon, 14 Jun 2021 12:13:52 GMT, Jorn Vernee wrote: > Hi, > > When native code creates a new thread and calls a Panama upcall, and during that upcall a stack walk is triggered, getting the sender frame for the entry frame is not possible, and should not be attempted. > > For JNI this case is handled already by indicating the end of the stack frame stream, but for Panama upcalls it is not, and the VM will either hit an assert or crash when trying to find the last Java frame before the entry frame (which does not exist in this case). > > This patch adds handling for panama upcalls frames to `frame::is_first_frame`, which is used by the stack walking code to determine when to stop walking. > > Thanks, > Jorn This pull request has now been integrated. Changeset: 2287ca5a Author: Jorn Vernee URL: https://git.openjdk.java.net/panama-foreign/commit/2287ca5a530c348bc4ec7c0c6774e8ed9101dffa Stats: 194 lines in 11 files changed: 193 ins; 0 del; 1 mod 8268673: Stack walk across optimized entry frame on fresh native thread fails Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/558 From mcimadamore at openjdk.java.net Mon Jun 14 17:36:30 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 14 Jun 2021 17:36:30 GMT Subject: [foreign-memaccess+abi] RFR: 8268633: CLinker::toJavaString doesn't check for NULL address Message-ID: As the subject says, a couple of function in CLinker do not check for NULL addresses passed as arguments. ------------- Commit messages: - Initial push Changes: https://git.openjdk.java.net/panama-foreign/pull/559/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=559&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268633 Stats: 154 lines in 4 files changed: 88 ins; 61 del; 5 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/559.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/559/head:pull/559 PR: https://git.openjdk.java.net/panama-foreign/pull/559 From jvernee at openjdk.java.net Mon Jun 14 17:36:31 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Mon, 14 Jun 2021 17:36:31 GMT Subject: [foreign-memaccess+abi] RFR: 8268633: CLinker::toJavaString doesn't check for NULL address In-Reply-To: References: Message-ID: On Mon, 14 Jun 2021 17:26:02 GMT, Maurizio Cimadamore wrote: > As the subject says, a couple of function in CLinker do not check for NULL addresses passed as arguments. LGTM! ------------- Marked as reviewed by jvernee (Committer). PR: https://git.openjdk.java.net/panama-foreign/pull/559 From duke at openjdk.java.net Mon Jun 14 18:02:19 2021 From: duke at openjdk.java.net (duke) Date: Mon, 14 Jun 2021 18:02:19 GMT Subject: git: openjdk/panama-foreign: foreign-jextract: 2 new changesets Message-ID: <9d84755c-9b8f-42fb-a095-7d4840ffa7a6@openjdk.org> Changeset: 3cc47de0 Author: Maurizio Cimadamore Date: 2021-06-14 18:00:18 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3cc47de0a6e3e2b29aa663478b2072f6ed40b054 8268633: CLinker::toJavaString doesn't check for NULL address Reviewed-by: jvernee ! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/SharedUtils.java + test/jdk/java/foreign/TestNULLAddress.java - test/jdk/java/foreign/TestNULLTarget.java Changeset: e4f89d7b Author: duke Date: 2021-06-14 18:00:58 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e4f89d7b0f85cc707de26f560d7a5ee44743071b Automatic merge of foreign-memaccess+abi into foreign-jextract From mcimadamore at openjdk.java.net Mon Jun 14 18:03:08 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 14 Jun 2021 18:03:08 GMT Subject: [foreign-memaccess+abi] Integrated: 8268633: CLinker::toJavaString doesn't check for NULL address In-Reply-To: References: Message-ID: On Mon, 14 Jun 2021 17:26:02 GMT, Maurizio Cimadamore wrote: > As the subject says, a couple of function in CLinker do not check for NULL addresses passed as arguments. This pull request has now been integrated. Changeset: 3cc47de0 Author: Maurizio Cimadamore URL: https://git.openjdk.java.net/panama-foreign/commit/3cc47de0a6e3e2b29aa663478b2072f6ed40b054 Stats: 154 lines in 4 files changed: 88 ins; 61 del; 5 mod 8268633: CLinker::toJavaString doesn't check for NULL address Reviewed-by: jvernee ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/559 From njian at openjdk.java.net Tue Jun 15 02:42:06 2021 From: njian at openjdk.java.net (Ningsheng Jian) Date: Tue, 15 Jun 2021 02:42:06 GMT Subject: [vectorIntrinsics] RFR: Merge panama-vector:master In-Reply-To: References: Message-ID: On Fri, 11 Jun 2021 17:37:44 GMT, Sandhya Viswanathan wrote: > This pull request merges master changes into vectorIntrinsics. > > @nsjian Need your help to merge test/hotspot/gtest/aarch64/asmtest.out.h (I have left the git merge markers in place for asmtest.out.h). > > Best Regards, > Sandhya Hi @sviswa7, Thanks for your effort. I have regenerated that file and sent to you. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/92 From uschindler at apache.org Tue Jun 15 09:25:36 2021 From: uschindler at apache.org (Uwe Schindler) Date: Tue, 15 Jun 2021 11:25:36 +0200 Subject: Memory Segment efficient array handling In-Reply-To: References: <08a001d726ec$f3bd0f30$db372d90$@apache.org> <5d67aba5-e7c8-620c-41ec-0daf396f0d96@oracle.com> Message-ID: <04e101d761c8$67896510$369c2f30$@apache.org> Hi Maurizio, I spend a lot of time to analyze the problem. It is indeed related to the wrapping of heap arrays, slicing and so on. I opened a bug report: https://bugs.openjdk.java.net/browse/JDK-8268743 So please think about adding an API which is highly optimized to bulk copy slices between classical on-heap arrays and MemorySegments! It looks like escape analysis does not work and during our test and the heap was filled with millions of HeapMemorySegment#OfByte slices! Performance degraded significantly, especially due to garbage collection. Long indexes in for-loops seem to be not the issue here. We proved hat replacing the wrap-byte-array, slice, copyFrom code with Unsafe.copyMemory solves the issue and we have Lucene's new memory mapping implementation behave similar to the old MappedByteBuffer code. (Mapped)ByteBuffer has getByte(byte[], offset, count) which is missing for memory segments and that?s reason for our pain! You can see the discussion on our latest pull request for JDK 17: https://github.com/apache/lucene/pull/177 Uwe ----- Uwe Schindler uschindler at apache.org ASF Member, Member of PMC and Committer of Apache Lucene and Apache Solr Bremen, Germany https://lucene.apache.org/ https://solr.apache.org/ > -----Original Message----- > From: Maurizio Cimadamore > Sent: Thursday, April 1, 2021 2:36 PM > To: Uwe Schindler ; 'leerho' ; > panama-dev at openjdk.java.net > Subject: Re: Memory Segment efficient array handling > > I re-read the Lucene/Solr patch to support segments, and one thing > jumped out: in routines like readLEFloats/Longs, it seems like we do a > bulk copy if endianness match, but we do a loop copy if endianness > doesn't match. > > Reading from the ByteBufferInput impl, it doesn't seem to me that the > impl is ever falling back onto a regular loop. > > https://github.com/apache/lucene- > solr/blob/d2c0be5a83f8a985710e1ffbadabc70e82c54fb1/lucene/core/src/java > /org/apache/lucene/store/ByteBufferIndexInput.java#L168 > > E.g. it seems you adjust the endianness on the buffer and then use a > bulk copy. > > In other words, there might be a performance advantage in having the > bulk copy methods in MemoryAccess - which is we can take an endianness > parameter, and copy in bulk with swap (memory segment, internally, has > the ability to copy bulk with swap, like Unsafe.copySwapMemory). > > That said, I don't think this is the root cause of the perf issues you > are seeing, since readLongs is always doing a loop (even in the buffer > world), and readLELongs should do bulk copy most of the times (I assume > you ran the bench on a LE platform). > > Maurizio > > > On 01/04/2021 13:05, Maurizio Cimadamore wrote: > > > > On 01/04/2021 12:48, Uwe Schindler wrote: > >> In our investigations, we also see some slowdown in contrast to our > >> ByteBuffer implementation. It is not yet clear if it comes from loops > >> over long instead of ints or if it is caused by the number of object > >> allocations. > > > > It would be helpful if we could narrow this down. I suppose you refer > > to the benchmark regressions here: > > > > https://github.com/apache/lucene-solr/pull/2176#issuecomment-758175143 > > > > Which are probably not related to the issue of bulk copying. > > > > See my other email: having better MemoryAccess routines for bulk > > copying is mostly an usability thing. There's nothing to suggest that > > a straight unsafe call is faster than slicing and calling copyFrom, so > > I wouldn't look there to explain performance differences. > > > > Maurizio > > From maurizio.cimadamore at oracle.com Tue Jun 15 09:55:34 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 15 Jun 2021 10:55:34 +0100 Subject: Memory Segment efficient array handling In-Reply-To: <04e101d761c8$67896510$369c2f30$@apache.org> References: <08a001d726ec$f3bd0f30$db372d90$@apache.org> <5d67aba5-e7c8-620c-41ec-0daf396f0d96@oracle.com> <04e101d761c8$67896510$369c2f30$@apache.org> Message-ID: <265ceecd-941a-127b-e2e7-5462f190291c@oracle.com> Hi Uwe, I have been keeping an eye on that. You report that there's lots of heap allocation - but that's with JFR enabled, which also instantiates its own events. Do you have a run w/o JFR - is the allocation rate the same w/ and w/o JFR? I was about to ask if replacing the memory segment copy with a plain Unsafe::copyMemory call worked, but it seems you have done that. The problem could be caused by lack of inlining (as you suggest) - or profile pollution (in case same copy routine is called with a byte[] memory segment and an int[] memory segment, or an off-heap memory segment), or both. Have you tried using the wrapper methods we're experimenting with in: https://github.com/openjdk/panama-foreign/pull/555 It's still raw, and I have not added in the bits which take care of profile pollution - but all the copy routines are wrapped with @ForceInline - can you please verify that this helps (or provide a JMH benchmark which we can try on our end) ? Maurizio On 15/06/2021 10:25, Uwe Schindler wrote: > Hi Maurizio, > > I spend a lot of time to analyze the problem. It is indeed related to the wrapping of heap arrays, slicing and so on. I opened a bug report: > https://bugs.openjdk.java.net/browse/JDK-8268743 > > So please think about adding an API which is highly optimized to bulk copy slices between classical on-heap arrays and MemorySegments! It looks like escape analysis does not work and during our test and the heap was filled with millions of HeapMemorySegment#OfByte slices! Performance degraded significantly, especially due to garbage collection. > > Long indexes in for-loops seem to be not the issue here. We proved hat replacing the wrap-byte-array, slice, copyFrom code with Unsafe.copyMemory solves the issue and we have Lucene's new memory mapping implementation behave similar to the old MappedByteBuffer code. (Mapped)ByteBuffer has getByte(byte[], offset, count) which is missing for memory segments and that?s reason for our pain! > > You can see the discussion on our latest pull request for JDK 17: https://urldefense.com/v3/__https://github.com/apache/lucene/pull/177__;!!GqivPVa7Brio!LHph3VUPiAkTLYY0J9EGarZ8JCdW5uOOekM2xprUEK_KLUIPmLyCyhxRmsJh5viv9TMmgFI$ > > Uwe > > ----- > Uwe Schindler > uschindler at apache.org > ASF Member, Member of PMC and Committer of Apache Lucene and Apache Solr > Bremen, Germany > https://urldefense.com/v3/__https://lucene.apache.org/__;!!GqivPVa7Brio!LHph3VUPiAkTLYY0J9EGarZ8JCdW5uOOekM2xprUEK_KLUIPmLyCyhxRmsJh5viv78SJz9E$ > https://urldefense.com/v3/__https://solr.apache.org/__;!!GqivPVa7Brio!LHph3VUPiAkTLYY0J9EGarZ8JCdW5uOOekM2xprUEK_KLUIPmLyCyhxRmsJh5vivenmaLYI$ > >> -----Original Message----- >> From: Maurizio Cimadamore >> Sent: Thursday, April 1, 2021 2:36 PM >> To: Uwe Schindler ; 'leerho' ; >> panama-dev at openjdk.java.net >> Subject: Re: Memory Segment efficient array handling >> >> I re-read the Lucene/Solr patch to support segments, and one thing >> jumped out: in routines like readLEFloats/Longs, it seems like we do a >> bulk copy if endianness match, but we do a loop copy if endianness >> doesn't match. >> >> Reading from the ByteBufferInput impl, it doesn't seem to me that the >> impl is ever falling back onto a regular loop. >> >> https://urldefense.com/v3/__https://github.com/apache/lucene-__;!!GqivPVa7Brio!LHph3VUPiAkTLYY0J9EGarZ8JCdW5uOOekM2xprUEK_KLUIPmLyCyhxRmsJh5vivqhwc_nk$ >> solr/blob/d2c0be5a83f8a985710e1ffbadabc70e82c54fb1/lucene/core/src/java >> /org/apache/lucene/store/ByteBufferIndexInput.java#L168 >> >> E.g. it seems you adjust the endianness on the buffer and then use a >> bulk copy. >> >> In other words, there might be a performance advantage in having the >> bulk copy methods in MemoryAccess - which is we can take an endianness >> parameter, and copy in bulk with swap (memory segment, internally, has >> the ability to copy bulk with swap, like Unsafe.copySwapMemory). >> >> That said, I don't think this is the root cause of the perf issues you >> are seeing, since readLongs is always doing a loop (even in the buffer >> world), and readLELongs should do bulk copy most of the times (I assume >> you ran the bench on a LE platform). >> >> Maurizio >> >> >> On 01/04/2021 13:05, Maurizio Cimadamore wrote: >>> On 01/04/2021 12:48, Uwe Schindler wrote: >>>> In our investigations, we also see some slowdown in contrast to our >>>> ByteBuffer implementation. It is not yet clear if it comes from loops >>>> over long instead of ints or if it is caused by the number of object >>>> allocations. >>> It would be helpful if we could narrow this down. I suppose you refer >>> to the benchmark regressions here: >>> >>> https://urldefense.com/v3/__https://github.com/apache/lucene-solr/pull/2176*issuecomment-758175143__;Iw!!GqivPVa7Brio!LHph3VUPiAkTLYY0J9EGarZ8JCdW5uOOekM2xprUEK_KLUIPmLyCyhxRmsJh5vivjSTNCYk$ >>> >>> Which are probably not related to the issue of bulk copying. >>> >>> See my other email: having better MemoryAccess routines for bulk >>> copying is mostly an usability thing. There's nothing to suggest that >>> a straight unsafe call is faster than slicing and calling copyFrom, so >>> I wouldn't look there to explain performance differences. >>> >>> Maurizio >>> From uschindler at apache.org Tue Jun 15 10:28:05 2021 From: uschindler at apache.org (Uwe Schindler) Date: Tue, 15 Jun 2021 12:28:05 +0200 Subject: Memory Segment efficient array handling In-Reply-To: <265ceecd-941a-127b-e2e7-5462f190291c@oracle.com> References: <08a001d726ec$f3bd0f30$db372d90$@apache.org> <5d67aba5-e7c8-620c-41ec-0daf396f0d96@oracle.com> <04e101d761c8$67896510$369c2f30$@apache.org> <265ceecd-941a-127b-e2e7-5462f190291c@oracle.com> Message-ID: <06d701d761d1$21bb6f70$65324e50$@apache.org> Hi, > I have been keeping an eye on that. Thanks ?? > You report that there's lots of heap allocation - but that's with JFR > enabled, which also instantiates its own events. Do you have a run w/o > JFR - is the allocation rate the same w/ and w/o JFR? I don't know the heap allocation rate without JFR, but if you look at the statistics printed out in the issue, the top of the allocations are in the HeapMemorySegment$OfByte code, also MemorySegment#dup() -- which is of course related to the slices we have to create in our copy between heap/off-heap method. The JFR feature was only recently added to Mike McCandless' Lucene benchmark framework (which is unfortunately not yet using JMH behind the scenes). It is very complicated to create an independent benchmark showing our problem with profile pollution, because it ay have to do with the complexity of code paths that call those I/O methods (which are the hotspot in Lucene anyways): Every single query execution calls the MemorySegmentIndexInput methods millions of times, sometimes sequential reads of different data types, then bulk reads of byte[], long[] or recently also float[] for vector stuff. This is why I'd like to suggest to provide those "easy-use" memory copy method in MemoryAccess (looking similar to mine), but hardly enforced to inlining. The ack of memory copy methods from/to plain java arrays like you have them in nio.*Buffer classes is really missing. > I was about to ask if replacing the memory segment copy with a plain > Unsafe::copyMemory call worked, but it seems you have done that. Yes, this made the problem go away completely, after that the heap statistics looked identical to our previous code - With and without JFR! I spend yesterday evening with that. I will update the pull request to have the used code inside, too. > The problem could be caused by lack of inlining (as you suggest) - or > profile pollution (in case same copy routine is called with a byte[] > memory segment and an int[] memory segment, or an off-heap memory > segment), or both. In our case, we always pass a MappedMemorySegment to the above method. I also tried reshuffling the methods, but no success: whenever MemorySegment#ofArray() was involved, the heap allocations happened. For byte[] and long[] and float[] we have separate code paths all with sharp types. > Have you tried using the wrapper methods we're experimenting with in: > > https://github.com/openjdk/panama-foreign/pull/555 > > It's still raw, and I have not added in the bits which take care of > profile pollution - but all the copy routines are wrapped with > @ForceInline - can you please verify that this helps (or provide a JMH > benchmark which we can try on our end) ? Hi, no I havent't done because I had no time to compile a custom JDK yet (I am undertime pressure, because I will present the results tomorrow in a talk at BerinBuzzwords conference: https://2021.berlinbuzzwords.de/session/future-lucenes-mmapdirectory-why-use-it-and-whats-coming-java-16-and-later But what I don't understand in this pull request: How to pass in plain byte/long/float arrays without slicing and wrapping? Or is this just about our byte order issue? So we define a memory layout for the MemorySegment that uses e.g. little endian and then we call the new copy method, which makes sure that on a big endian platform all bytes are swapped? Thanks, Uwe > On 15/06/2021 10:25, Uwe Schindler wrote: > > Hi Maurizio, > > > > I spend a lot of time to analyze the problem. It is indeed related to the > wrapping of heap arrays, slicing and so on. I opened a bug report: > > https://bugs.openjdk.java.net/browse/JDK-8268743 > > > > So please think about adding an API which is highly optimized to bulk copy > slices between classical on-heap arrays and MemorySegments! It looks like > escape analysis does not work and during our test and the heap was filled with > millions of HeapMemorySegment#OfByte slices! Performance degraded > significantly, especially due to garbage collection. > > > > Long indexes in for-loops seem to be not the issue here. We proved hat > replacing the wrap-byte-array, slice, copyFrom code with Unsafe.copyMemory > solves the issue and we have Lucene's new memory mapping implementation > behave similar to the old MappedByteBuffer code. (Mapped)ByteBuffer has > getByte(byte[], offset, count) which is missing for memory segments and that?s > reason for our pain! > > > > You can see the discussion on our latest pull request for JDK 17: > https://urldefense.com/v3/__https://github.com/apache/lucene/pull/177__;!!G > qivPVa7Brio!LHph3VUPiAkTLYY0J9EGarZ8JCdW5uOOekM2xprUEK_KLUIPmLyCy > hxRmsJh5viv9TMmgFI$ > > > > Uwe > > > > ----- > > Uwe Schindler > > uschindler at apache.org > > ASF Member, Member of PMC and Committer of Apache Lucene and Apache > Solr > > Bremen, Germany > > > https://urldefense.com/v3/__https://lucene.apache.org/__;!!GqivPVa7Brio!LHp > h3VUPiAkTLYY0J9EGarZ8JCdW5uOOekM2xprUEK_KLUIPmLyCyhxRmsJh5viv78S > Jz9E$ > > > https://urldefense.com/v3/__https://solr.apache.org/__;!!GqivPVa7Brio!LHph3 > VUPiAkTLYY0J9EGarZ8JCdW5uOOekM2xprUEK_KLUIPmLyCyhxRmsJh5vivenmaL > YI$ > > > >> -----Original Message----- > >> From: Maurizio Cimadamore > >> Sent: Thursday, April 1, 2021 2:36 PM > >> To: Uwe Schindler ; 'leerho' ; > >> panama-dev at openjdk.java.net > >> Subject: Re: Memory Segment efficient array handling > >> > >> I re-read the Lucene/Solr patch to support segments, and one thing > >> jumped out: in routines like readLEFloats/Longs, it seems like we do a > >> bulk copy if endianness match, but we do a loop copy if endianness > >> doesn't match. > >> > >> Reading from the ByteBufferInput impl, it doesn't seem to me that the > >> impl is ever falling back onto a regular loop. > >> > >> https://urldefense.com/v3/__https://github.com/apache/lucene- > __;!!GqivPVa7Brio!LHph3VUPiAkTLYY0J9EGarZ8JCdW5uOOekM2xprUEK_KLUIP > mLyCyhxRmsJh5vivqhwc_nk$ > >> > solr/blob/d2c0be5a83f8a985710e1ffbadabc70e82c54fb1/lucene/core/src/java > >> /org/apache/lucene/store/ByteBufferIndexInput.java#L168 > >> > >> E.g. it seems you adjust the endianness on the buffer and then use a > >> bulk copy. > >> > >> In other words, there might be a performance advantage in having the > >> bulk copy methods in MemoryAccess - which is we can take an endianness > >> parameter, and copy in bulk with swap (memory segment, internally, has > >> the ability to copy bulk with swap, like Unsafe.copySwapMemory). > >> > >> That said, I don't think this is the root cause of the perf issues you > >> are seeing, since readLongs is always doing a loop (even in the buffer > >> world), and readLELongs should do bulk copy most of the times (I assume > >> you ran the bench on a LE platform). > >> > >> Maurizio > >> > >> > >> On 01/04/2021 13:05, Maurizio Cimadamore wrote: > >>> On 01/04/2021 12:48, Uwe Schindler wrote: > >>>> In our investigations, we also see some slowdown in contrast to our > >>>> ByteBuffer implementation. It is not yet clear if it comes from loops > >>>> over long instead of ints or if it is caused by the number of object > >>>> allocations. > >>> It would be helpful if we could narrow this down. I suppose you refer > >>> to the benchmark regressions here: > >>> > >>> https://urldefense.com/v3/__https://github.com/apache/lucene- > solr/pull/2176*issuecomment- > 758175143__;Iw!!GqivPVa7Brio!LHph3VUPiAkTLYY0J9EGarZ8JCdW5uOOekM2 > xprUEK_KLUIPmLyCyhxRmsJh5vivjSTNCYk$ > >>> > >>> Which are probably not related to the issue of bulk copying. > >>> > >>> See my other email: having better MemoryAccess routines for bulk > >>> copying is mostly an usability thing. There's nothing to suggest that > >>> a straight unsafe call is faster than slicing and calling copyFrom, so > >>> I wouldn't look there to explain performance differences. > >>> > >>> Maurizio > >>> From maurizio.cimadamore at oracle.com Tue Jun 15 11:19:44 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 15 Jun 2021 12:19:44 +0100 Subject: Memory Segment efficient array handling In-Reply-To: <06d701d761d1$21bb6f70$65324e50$@apache.org> References: <08a001d726ec$f3bd0f30$db372d90$@apache.org> <5d67aba5-e7c8-620c-41ec-0daf396f0d96@oracle.com> <04e101d761c8$67896510$369c2f30$@apache.org> <265ceecd-941a-127b-e2e7-5462f190291c@oracle.com> <06d701d761d1$21bb6f70$65324e50$@apache.org> Message-ID: <7659efda-ed64-093b-c69b-b5af767768c1@oracle.com> Hi Uwe, I'm doing other benchmark and, while I see that for _small_ segments (~50 elements), the bulk copy is slower than unsafe, I don't see the allocation, even if I disable inlining in JMH. The reason why copying is slower for small segments is that, I think, my benchmark iterations run in 4-5ns and, at these levels, you are sensitive to the cost of the liveness checks. There's not a lot we can do to eliminate that - it's the price of safety. Now, while benchmarking, I realized that all the benchmark I have tried so far were of the kind: ``` segment.asSlice(srcOffset, nbytes).copyFrom(bytesSegment.asSlice(targetOffset, nbytes)); ``` In your case though, you create the heap segment on the fly, something like this: ``` segment.asSlice(srcOffset, nbytes).copyFrom(MemorySegment.ofArray(bytes).asSlice(targetOffset, nbytes)); ``` And I can indeed see that the allocation profile for the two cases is different - in the former (segment_small_copy) there's no allocation, while in the latter (segment_small_copy_fresh) I can see some. ``` TestSmallCopy.segment_small_copy avgt?? 30?? 7.039 ?? 0.268?? ns/op TestSmallCopy.segment_small_copy:?gc.alloc.rate avgt?? 30? ? 10???????????? MB/sec TestSmallCopy.segment_small_copy:?gc.alloc.rate.norm avgt?? 30? ? 10?????????????? B/op TestSmallCopy.segment_small_copy:?gc.count avgt?? 30???? ? 0?????????? counts TestSmallCopy.segment_small_copy_fresh avgt?? 30?? 6.870 ?? 0.469?? ns/op TestSmallCopy.segment_small_copy_fresh:?gc.alloc.rate avgt?? 30?? 0.366 ?? 1.337? MB/sec TestSmallCopy.segment_small_copy_fresh:?gc.alloc.rate.norm avgt?? 30?? 0.003 ?? 0.010??? B/op TestSmallCopy.segment_small_copy_fresh:?gc.churn.G1_Eden_Space avgt?? 30?? 0.799 ?? 2.925? MB/sec TestSmallCopy.segment_small_copy_fresh:?gc.churn.G1_Eden_Space.norm avgt?? 30?? 0.006 ?? 0.022??? B/op TestSmallCopy.segment_small_copy_fresh:?gc.count avgt?? 30?? 1.000?????????? counts TestSmallCopy.segment_small_copy_fresh:?gc.time avgt?? 30?? 1.000?????????????? ms ``` After looking at this I immediately realized what the issue could be - and it is, albeit indirectly, related to long loop optimizations (again). To speed up "small" segments (whose size fits in an integer) we check the segment size at creation and set a flag, using this method: ``` static int defaultAccessModes(long size) { ??????? return (enableSmallSegments && size < Integer.MAX_VALUE) ? ??????????????? SMALL : 0; ??? } ``` Now, doing this in the middle of code where you expect escape analysis to kick in is plain evil: escape analysis is super sensitive to control flow. And, sadly, the above code uses control flow. This means that escape analysis would be disabled in this particular case. The good news is that in the case of heap segment wrappers, we know exactly that the size is gonna fit inside an int (it's an array after all!), so we can remove the check. If we remove the flag check, and just set the segment to always be treated as "SMALL", we get the following results: ``` Benchmark?????????????????????????????????????????????????? Mode Cnt?? Score??? Error?? Units TestSmallCopy.segment_small_copy_fresh????????????????????? avgt 30?? 7.039 ?? 0.264?? ns/op TestSmallCopy.segment_small_copy_fresh:?gc.alloc.rate?????? avgt 30? ? 10???????????? MB/sec TestSmallCopy.segment_small_copy_fresh:?gc.alloc.rate.norm? avgt 30? ? 10?????????????? B/op TestSmallCopy.segment_small_copy_fresh:?gc.count??????????? avgt 30???? ? 0?????????? counts ``` Where allocation profile is back to normal. Note that all the above benchmarks use `@CompilerControl(DONT_INLINE)`, so the results should be pretty independent on whether the method doing the copy is inlined or not (e.g. with @ForceInline). I will file a PR for Panama soon - if you could test that directly it would be great and we could even integrate into 17. Of course this doesn't remove the need for "easier to use" bulk copy methods, but I think we need to make sure that wrapping segments like your code does should not add any unwanted costs. Also note: even with the allocation fix, performance of the bulk copy with segments with few elements is still somewhat inferior compared with unsafe (because of the extra bound and liveness checks). If you are only copying a dozen of elements you might be better off with a loop (the byte buffer API had such an internal threshold, the memory segment API doesn't). What I'm saying is: as horrible the allocation stats might look, we shouldn't jump to the conclusion that the slowdown is caused by additional allocation. At least in the benchmark I have, fixing allocation does NOT bring segment bulk copy performance 100% on par with unsafe: ``` Benchmark?????????????????????????????? Mode? Cnt? Score?? Error Units TestSmallCopy.segment_small_copy??????? avgt?? 30? 5.464 ? 0.374 ns/op TestSmallCopy.segment_small_copy_fresh? avgt?? 30? 5.600 ? 0.366 ns/op TestSmallCopy.unsafe_small_copy???????? avgt?? 30? 4.468 ? 0.322 ns/op ``` So, while we will try to fix the code in a way that rectifies the escape analysis woes, I think there might still be homeworks left to do :-) Some other comments inline below. On 15/06/2021 11:28, Uwe Schindler wrote: > Hi, > >> I have been keeping an eye on that. > Thanks ?? > >> You report that there's lots of heap allocation - but that's with JFR >> enabled, which also instantiates its own events. Do you have a run w/o >> JFR - is the allocation rate the same w/ and w/o JFR? > I don't know the heap allocation rate without JFR, but if you look at the statistics printed out in the issue, the top of the allocations are in the HeapMemorySegment$OfByte code, also MemorySegment#dup() -- which is of course related to the slices we have to create in our copy between heap/off-heap method. > > The JFR feature was only recently added to Mike McCandless' Lucene benchmark framework (which is unfortunately not yet using JMH behind the scenes). It is very complicated to create an independent benchmark showing our problem with profile pollution, because it ay have to do with the complexity of code paths that call those I/O methods (which are the hotspot in Lucene anyways): Every single query execution calls the MemorySegmentIndexInput methods millions of times, sometimes sequential reads of different data types, then bulk reads of byte[], long[] or recently also float[] for vector stuff. > > This is why I'd like to suggest to provide those "easy-use" memory copy method in MemoryAccess (looking similar to mine), but hardly enforced to inlining. The ack of memory copy methods from/to plain java arrays like you have them in nio.*Buffer classes is really missing. This is what the PR I linked does, see the MemoryCopy class it introduces > Hi, no I havent't done because I had no time to compile a custom JDK yet (I am undertime pressure, because I will present the results tomorrow in a talk at BerinBuzzwords conference: https://urldefense.com/v3/__https://2021.berlinbuzzwords.de/session/future-lucenes-mmapdirectory-why-use-it-and-whats-coming-java-16-and-later__;!!GqivPVa7Brio!N8KPr7fbMvwJpJDUHq4gBHKUGtIK3ZPE1zPJzB_atozEZii_1dn6-zsPb08k2qg_L_UfzOE$ > > But what I don't understand in this pull request: How to pass in plain byte/long/float arrays without slicing and wrapping? Or is this just about our byte order issue? So we define a memory layout for the MemorySegment that uses e.g. little endian and then we call the new copy method, which makes sure that on a big endian platform all bytes are swapped? There is a new class called MemoryCopy, with several static methods whose signature is vaguely similar to that of the bulk methods in the ByteBuffer API. So, instead of calling MemorySegment::copyFrom, you should call MemoryCopy:copyXYZ, which is a static method annotated with @ForceInline (at least to test that it works as expected). Maurizio > > Thanks, > Uwe > >> On 15/06/2021 10:25, Uwe Schindler wrote: >>> Hi Maurizio, >>> >>> I spend a lot of time to analyze the problem. It is indeed related to the >> wrapping of heap arrays, slicing and so on. I opened a bug report: >>> https://bugs.openjdk.java.net/browse/JDK-8268743 >>> >>> So please think about adding an API which is highly optimized to bulk copy >> slices between classical on-heap arrays and MemorySegments! It looks like >> escape analysis does not work and during our test and the heap was filled with >> millions of HeapMemorySegment#OfByte slices! Performance degraded >> significantly, especially due to garbage collection. >>> Long indexes in for-loops seem to be not the issue here. We proved hat >> replacing the wrap-byte-array, slice, copyFrom code with Unsafe.copyMemory >> solves the issue and we have Lucene's new memory mapping implementation >> behave similar to the old MappedByteBuffer code. (Mapped)ByteBuffer has >> getByte(byte[], offset, count) which is missing for memory segments and that?s >> reason for our pain! >>> You can see the discussion on our latest pull request for JDK 17: >> https://urldefense.com/v3/__https://github.com/apache/lucene/pull/177__;!!G >> qivPVa7Brio!LHph3VUPiAkTLYY0J9EGarZ8JCdW5uOOekM2xprUEK_KLUIPmLyCy >> hxRmsJh5viv9TMmgFI$ >>> Uwe >>> >>> ----- >>> Uwe Schindler >>> uschindler at apache.org >>> ASF Member, Member of PMC and Committer of Apache Lucene and Apache >> Solr >>> Bremen, Germany >>> >> https://urldefense.com/v3/__https://lucene.apache.org/__;!!GqivPVa7Brio!LHp >> h3VUPiAkTLYY0J9EGarZ8JCdW5uOOekM2xprUEK_KLUIPmLyCyhxRmsJh5viv78S >> Jz9E$ >> https://urldefense.com/v3/__https://solr.apache.org/__;!!GqivPVa7Brio!LHph3 >> VUPiAkTLYY0J9EGarZ8JCdW5uOOekM2xprUEK_KLUIPmLyCyhxRmsJh5vivenmaL >> YI$ >>>> -----Original Message----- >>>> From: Maurizio Cimadamore >>>> Sent: Thursday, April 1, 2021 2:36 PM >>>> To: Uwe Schindler ; 'leerho' ; >>>> panama-dev at openjdk.java.net >>>> Subject: Re: Memory Segment efficient array handling >>>> >>>> I re-read the Lucene/Solr patch to support segments, and one thing >>>> jumped out: in routines like readLEFloats/Longs, it seems like we do a >>>> bulk copy if endianness match, but we do a loop copy if endianness >>>> doesn't match. >>>> >>>> Reading from the ByteBufferInput impl, it doesn't seem to me that the >>>> impl is ever falling back onto a regular loop. >>>> >>>> https://urldefense.com/v3/__https://github.com/apache/lucene- >> __;!!GqivPVa7Brio!LHph3VUPiAkTLYY0J9EGarZ8JCdW5uOOekM2xprUEK_KLUIP >> mLyCyhxRmsJh5vivqhwc_nk$ >> solr/blob/d2c0be5a83f8a985710e1ffbadabc70e82c54fb1/lucene/core/src/java >>>> /org/apache/lucene/store/ByteBufferIndexInput.java#L168 >>>> >>>> E.g. it seems you adjust the endianness on the buffer and then use a >>>> bulk copy. >>>> >>>> In other words, there might be a performance advantage in having the >>>> bulk copy methods in MemoryAccess - which is we can take an endianness >>>> parameter, and copy in bulk with swap (memory segment, internally, has >>>> the ability to copy bulk with swap, like Unsafe.copySwapMemory). >>>> >>>> That said, I don't think this is the root cause of the perf issues you >>>> are seeing, since readLongs is always doing a loop (even in the buffer >>>> world), and readLELongs should do bulk copy most of the times (I assume >>>> you ran the bench on a LE platform). >>>> >>>> Maurizio >>>> >>>> >>>> On 01/04/2021 13:05, Maurizio Cimadamore wrote: >>>>> On 01/04/2021 12:48, Uwe Schindler wrote: >>>>>> In our investigations, we also see some slowdown in contrast to our >>>>>> ByteBuffer implementation. It is not yet clear if it comes from loops >>>>>> over long instead of ints or if it is caused by the number of object >>>>>> allocations. >>>>> It would be helpful if we could narrow this down. I suppose you refer >>>>> to the benchmark regressions here: >>>>> >>>>> https://urldefense.com/v3/__https://github.com/apache/lucene- >> solr/pull/2176*issuecomment- >> 758175143__;Iw!!GqivPVa7Brio!LHph3VUPiAkTLYY0J9EGarZ8JCdW5uOOekM2 >> xprUEK_KLUIPmLyCyhxRmsJh5vivjSTNCYk$ >>>>> Which are probably not related to the issue of bulk copying. >>>>> >>>>> See my other email: having better MemoryAccess routines for bulk >>>>> copying is mostly an usability thing. There's nothing to suggest that >>>>> a straight unsafe call is faster than slicing and calling copyFrom, so >>>>> I wouldn't look there to explain performance differences. >>>>> >>>>> Maurizio >>>>> From uschindler at apache.org Tue Jun 15 12:06:40 2021 From: uschindler at apache.org (Uwe Schindler) Date: Tue, 15 Jun 2021 14:06:40 +0200 Subject: Memory Segment efficient array handling In-Reply-To: <7659efda-ed64-093b-c69b-b5af767768c1@oracle.com> References: <08a001d726ec$f3bd0f30$db372d90$@apache.org> <5d67aba5-e7c8-620c-41ec-0daf396f0d96@oracle.com> <04e101d761c8$67896510$369c2f30$@apache.org> <265ceecd-941a-127b-e2e7-5462f190291c@oracle.com> <06d701d761d1$21bb6f70$65324e50$@apache.org> <7659efda-ed64-093b-c69b-b5af767768c1@oracle.com> Message-ID: <073701d761de$e8317bb0$b8947310$@apache.org> Hi Maurizio, > Hi Uwe, > I'm doing other benchmark and, while I see that for _small_ segments > (~50 elements), the bulk copy is slower than unsafe, I don't see the > allocation, even if I disable inlining in JMH. > > The reason why copying is slower for small segments is that, I think, my > benchmark iterations run in 4-5ns and, at these levels, you are > sensitive to the cost of the liveness checks. There's not a lot we can > do to eliminate that - it's the price of safety. OK that's true. But in my own Unsafe.copyMemory code wasn't doing MemorySegment.address().toRawLongValue() not also doing the liveness check? > Now, while benchmarking, I realized that all the benchmark I have tried > so far were of the kind: > > ``` > segment.asSlice(srcOffset, > nbytes).copyFrom(bytesSegment.asSlice(targetOffset, nbytes)); > ``` > > In your case though, you create the heap segment on the fly, something > like this: > > ``` > segment.asSlice(srcOffset, > nbytes).copyFrom(MemorySegment.ofArray(bytes).asSlice(targetOffset, > nbytes)); > ``` > > And I can indeed see that the allocation profile for the two cases is > different - in the former (segment_small_copy) there's no allocation, > while in the latter (segment_small_copy_fresh) I can see some. > > ``` > TestSmallCopy.segment_small_copy avgt 30 7.039 ? 0.268 ns/op > TestSmallCopy.segment_small_copy:?gc.alloc.rate avgt 30 ? > 10?? MB/sec > TestSmallCopy.segment_small_copy:?gc.alloc.rate.norm avgt 30 ? > 10?? B/op > TestSmallCopy.segment_small_copy:?gc.count avgt 30 ? 0 > counts > TestSmallCopy.segment_small_copy_fresh avgt 30 6.870 ? 0.469 ns/op > TestSmallCopy.segment_small_copy_fresh:?gc.alloc.rate avgt 30 0.366 > ? 1.337 MB/sec > TestSmallCopy.segment_small_copy_fresh:?gc.alloc.rate.norm avgt 30 > 0.003 ? 0.010 B/op > TestSmallCopy.segment_small_copy_fresh:?gc.churn.G1_Eden_Space avgt > 30 0.799 ? 2.925 MB/sec > TestSmallCopy.segment_small_copy_fresh:?gc.churn.G1_Eden_Space.norm > avgt 30 0.006 ? 0.022 B/op > TestSmallCopy.segment_small_copy_fresh:?gc.count avgt 30 > 1.000 counts > TestSmallCopy.segment_small_copy_fresh:?gc.time avgt 30 > 1.000 ms > ``` > > After looking at this I immediately realized what the issue could be - > and it is, albeit indirectly, related to long loop optimizations > (again). To speed up "small" segments (whose size fits in an integer) we > check the segment size at creation and set a flag, using this method: > > ``` > static int defaultAccessModes(long size) { > return (enableSmallSegments && size < Integer.MAX_VALUE) ? > SMALL : 0; > } > ``` > > Now, doing this in the middle of code where you expect escape analysis > to kick in is plain evil: escape analysis is super sensitive to control > flow. And, sadly, the above code uses control flow. This means that > escape analysis would be disabled in this particular case. Thanks for this. I was stumbling on the SMALL segment stuff already (see my comment below). This explains why I only see memory allocations of those array wrappers and not many slice dupes! > The good news is that in the case of heap segment wrappers, we know > exactly that the size is gonna fit inside an int (it's an array after > all!), so we can remove the check. If we remove the flag check, and just > set the segment to always be treated as "SMALL", we get the following > results: Is this really true? What about a huge long[] array, that could be (2^31-8 maximum index) * 8 bytesPerLong = 16 gigabytes? (or are those limited by the Java standard in maximum array size?) > > ``` > Benchmark Mode Cnt > Score Error Units > TestSmallCopy.segment_small_copy_fresh avgt 30 > 7.039 ? 0.264 ns/op > TestSmallCopy.segment_small_copy_fresh:?gc.alloc.rate avgt 30 ? > 10?? MB/sec > TestSmallCopy.segment_small_copy_fresh:?gc.alloc.rate.norm avgt 30 ? > 10?? B/op > TestSmallCopy.segment_small_copy_fresh:?gc.count avgt 30 > ? 0 counts > ``` > > Where allocation profile is back to normal. Note that all the above > benchmarks use `@CompilerControl(DONT_INLINE)`, so the results should be > pretty independent on whether the method doing the copy is inlined or > not (e.g. with @ForceInline). > > I will file a PR for Panama soon - if you could test that directly it > would be great and we could even integrate into 17. Thanks, this is great! > Of course this doesn't remove the need for "easier to use" bulk copy > methods, but I think we need to make sure that wrapping segments like > your code does should not add any unwanted costs. > > Also note: even with the allocation fix, performance of the bulk copy > with segments with few elements is still somewhat inferior compared with > unsafe (because of the extra bound and liveness checks). If you are only > copying a dozen of elements you might be better off with a loop (the > byte buffer API had such an internal threshold, the memory segment API > doesn't). What I'm saying is: as horrible the allocation stats might > look, we shouldn't jump to the conclusion that the slowdown is caused by > additional allocation. At least in the benchmark I have, fixing > allocation does NOT bring segment bulk copy performance 100% on par with > unsafe: > > ``` > Benchmark Mode Cnt Score Error Units > TestSmallCopy.segment_small_copy avgt 30 5.464 ? 0.374 ns/op > TestSmallCopy.segment_small_copy_fresh avgt 30 5.600 ? 0.366 ns/op > TestSmallCopy.unsafe_small_copy avgt 30 4.468 ? 0.322 ns/op > ``` > > So, while we will try to fix the code in a way that rectifies the escape > analysis woes, I think there might still be homeworks left to do :-) Yes thanks. But this would also be some task for the MemoryCopy class in your recent pull request! > There is a new class called MemoryCopy, with several static methods > whose signature is vaguely similar to that of the bulk methods in the > ByteBuffer API. So, instead of calling MemorySegment::copyFrom, you > should call MemoryCopy:copyXYZ, which is a static method annotated with > @ForceInline (at least to test that it works as expected). Sorry, I missed that class. I was opening the pull request and only looked at the red/green changes in MemorySegment. I missed the first class. The methods provided there exactly replace my three shapes in the code. And on top they allow to swap. Side note: MemoryCopy in the current PR has the swapping code commented out. Last question: why does https://bugs.openjdk.java.net/browse/JDK-8223051 not help for the integer vs. long loop variables? Does this not allow to remove the small vs. large segment distinction? I thought this change in hotspot was added to support long loops, if it is in fact "small". Uwe From mcimadamore at openjdk.java.net Tue Jun 15 12:06:36 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 15 Jun 2021 12:06:36 GMT Subject: [foreign-memaccess+abi] RFR: 8268743: Require a better way for copying data between MemorySegments and on-heap arrays Message-ID: After some investigation, it seems that escape analysis is defeated in cases where a new heap segment is created fresh just before performing a bulk copy. This is caused by the fact that, on segment creation, we perform this test: static int defaultAccessModes(long size) { return (enableSmallSegments && size < Integer.MAX_VALUE) ? SMALL : 0; } To make sure that segments whose size fits in an `int` do not incur in penalties associated with lack of optimizations over long loop bound check optimizations. Unfortunately, this logic is control flow logic, and control flow disables escape analysis optimizations. For segment wrappers around byte arrays we can workaround by removing the check (all byte segments are small by definition, since there's a 1-1 mapping between logical elements and physical bytes). For other segment kinds we cannot do much. While it would be possible, in principle, to resort to more complex bound checks for heap segments, we believe the way forward is to eliminate the need for "small" segments, which will be possible once the PR below is completed: https://github.com/openjdk/jdk/pull/2045 ------------- Commit messages: - Make all byte heap segment "small" by default Changes: https://git.openjdk.java.net/panama-foreign/pull/560/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=560&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268743 Stats: 115 lines in 2 files changed: 114 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/560.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/560/head:pull/560 PR: https://git.openjdk.java.net/panama-foreign/pull/560 From uschindler at openjdk.java.net Tue Jun 15 12:34:47 2021 From: uschindler at openjdk.java.net (Uwe Schindler) Date: Tue, 15 Jun 2021 12:34:47 GMT Subject: [foreign-memaccess+abi] RFR: 8268743: Require a better way for copying data between MemorySegments and on-heap arrays In-Reply-To: References: Message-ID: On Tue, 15 Jun 2021 11:56:26 GMT, Maurizio Cimadamore wrote: > After some investigation, it seems that escape analysis is defeated in cases where a new heap segment is created fresh just before performing a bulk copy. > > This is caused by the fact that, on segment creation, we perform this test: > > > static int defaultAccessModes(long size) { > return (enableSmallSegments && size < Integer.MAX_VALUE) ? > SMALL : 0; > } > > > To make sure that segments whose size fits in an `int` do not incur in penalties associated with lack of optimizations over long loop bound check optimizations. > > Unfortunately, this logic is control flow logic, and control flow disables escape analysis optimizations. > > For segment wrappers around byte arrays we can workaround by removing the check (all byte segments are small by definition, since there's a 1-1 mapping between logical elements and physical bytes). For other segment kinds we cannot do much. > > While it would be possible, in principle, to resort to more complex bound checks for heap segments, we believe the way forward is to eliminate the need for "small" segments, which will be possible once the PR below is completed: > > https://github.com/openjdk/jdk/pull/2045 But we have no solution for larger sizes like float[] or long[] arrays? ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/560 From maurizio.cimadamore at oracle.com Tue Jun 15 12:43:43 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 15 Jun 2021 13:43:43 +0100 Subject: Memory Segment efficient array handling In-Reply-To: <073701d761de$e8317bb0$b8947310$@apache.org> References: <08a001d726ec$f3bd0f30$db372d90$@apache.org> <5d67aba5-e7c8-620c-41ec-0daf396f0d96@oracle.com> <04e101d761c8$67896510$369c2f30$@apache.org> <265ceecd-941a-127b-e2e7-5462f190291c@oracle.com> <06d701d761d1$21bb6f70$65324e50$@apache.org> <7659efda-ed64-093b-c69b-b5af767768c1@oracle.com> <073701d761de$e8317bb0$b8947310$@apache.org> Message-ID: >> The reason why copying is slower for small segments is that, I think, my >> benchmark iterations run in 4-5ns and, at these levels, you are >> sensitive to the cost of the liveness checks. There's not a lot we can >> do to eliminate that - it's the price of safety. > OK that's true. But in my own Unsafe.copyMemory code wasn't doing MemorySegment.address().toRawLongValue() not also doing the liveness check? True - so the liveness check probably that won't make a lot of difference in your case. But note that the bound checks are still applied in MemorySegment::copyMemory. > >> The good news is that in the case of heap segment wrappers, we know >> exactly that the size is gonna fit inside an int (it's an array after >> all!), so we can remove the check. If we remove the flag check, and just >> set the segment to always be treated as "SMALL", we get the following >> results: > Is this really true? What about a huge long[] array, that could be (2^31-8 maximum index) * 8 bytesPerLong = 16 gigabytes? (or are those limited by the Java standard in maximum array size?) in the PR I've submitted I only tweaked byte segment wrappers. We could resort to more complex internal representation for other heap segments, but I believe the true way forward is to wait for the long optimizations, and to completely remove the SMALL segment hacks. > > Sorry, I missed that class. I was opening the pull request and only looked at the red/green changes in MemorySegment. I missed the first class. > > The methods provided there exactly replace my three shapes in the code. And on top they allow to swap. Side note: MemoryCopy in the current PR has the swapping code commented out. Yeah - Lee is working on that MemoryCopy class (and associated test). I have provided the "swappy" copyFrom overload in MemorySegment, I believe Lee will add support for that soon. > > Last question: why does https://bugs.openjdk.java.net/browse/JDK-8223051 not help for the integer vs. long loop variables? Does this not allow to remove the small vs. large segment distinction? I thought this change in hotspot was added to support long loops, if it is in fact "small". My understanding is that the change has been split in multiple chunks. The chunk we mostly depend on is this: https://bugs.openjdk.java.net/browse/JDK-8259609 (in fact I'm coordinating with Roland, the author of that work, and he's testing the patch against a version of panama which doesn't have workarounds for small segments). I did run all Panama benchmarks after JDK-8223051 was pushed, and removed various workarounds, but? there was still a performance gap. Roland reassured me that the gap should disappear once JDK-8259609 is pushed. Maurizio > > Uwe > From mcimadamore at openjdk.java.net Tue Jun 15 12:52:06 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 15 Jun 2021 12:52:06 GMT Subject: [foreign-memaccess+abi] RFR: 8268743: Require a better way for copying data between MemorySegments and on-heap arrays In-Reply-To: References: Message-ID: On Tue, 15 Jun 2021 12:31:42 GMT, Uwe Schindler wrote: > But we have no solution for larger sizes like float[] or long[] arrays? Not for now - the real solution is to fix the performance woes which makes the implementation do all these workarounds for longs vs. ints. That said, I'd be curious, once this is integrated, if you could do a quick validation and re-run that benchmark where you were seeing lots of byte segment wrappers in the heap and make sure at least that behaves as expected. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/560 From uschindler at openjdk.java.net Tue Jun 15 13:11:02 2021 From: uschindler at openjdk.java.net (Uwe Schindler) Date: Tue, 15 Jun 2021 13:11:02 GMT Subject: [foreign-memaccess+abi] RFR: 8268743: Require a better way for copying data between MemorySegments and on-heap arrays In-Reply-To: References: Message-ID: On Tue, 15 Jun 2021 12:48:48 GMT, Maurizio Cimadamore wrote: > > But we have no solution for larger sizes like float[] or long[] arrays? > > Not for now - the real solution is to fix the performance woes which makes the implementation do all these workarounds for longs vs. ints. That said, I'd be curious, once this is integrated, if you could do a quick validation and re-run that benchmark where you were seeing lots of byte segment wrappers in the heap and make sure at least that behaves as expected. For sure. @rmuir and I already discussed about that. From what we understand: `readLong(long[], offset, count)` in our case is never reading more than 64 longs because of the limitations of PFOR algorithm inside Lucene. So we would remove the specialization in MemorySegmentIndexinput and the superclass will use a loop of readLong() instead. This also goes in line with your hint to copyMemory liveness check overhead. The readFloat variant we have is reading a maximum of 1024 float dimensions for our vector suppotr, I will do some quick investigations later, but I tend to remove the specialization, too. In future we will use FloatVector from vector API and that should possibly be wrapped over the memory segment (see also https://github.com/apache/lucene/pull/18 for some quick investigations). For the longs and the PFOR algorithm we may also use a vectorized approach in future, so readFloat() and readLongs() will go away and be replaced to return a FloatVector/LongVector view on the memory segmen t (using ByteBuffer view or directly once panama and vector can share APIs). The biggest problem on our side is our implementation of `readBytes(byte[], offset, count)` which is fixed here. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/560 From uschindler at openjdk.java.net Tue Jun 15 13:17:08 2021 From: uschindler at openjdk.java.net (Uwe Schindler) Date: Tue, 15 Jun 2021 13:17:08 GMT Subject: [foreign-memaccess+abi] RFR: 8268743: Require a better way for copying data between MemorySegments and on-heap arrays In-Reply-To: References: Message-ID: On Tue, 15 Jun 2021 11:56:26 GMT, Maurizio Cimadamore wrote: > After some investigation, it seems that escape analysis is defeated in cases where a new heap segment is created fresh just before performing a bulk copy. > > This is caused by the fact that, on segment creation, we perform this test: > > > static int defaultAccessModes(long size) { > return (enableSmallSegments && size < Integer.MAX_VALUE) ? > SMALL : 0; > } > > > To make sure that segments whose size fits in an `int` do not incur in penalties associated with lack of optimizations over long loop bound check optimizations. > > Unfortunately, this logic is control flow logic, and control flow disables escape analysis optimizations. > > For segment wrappers around byte arrays we can workaround by removing the check (all byte segments are small by definition, since there's a 1-1 mapping between logical elements and physical bytes). For other segment kinds we cannot do much. > > While it would be possible, in principle, to resort to more complex bound checks for heap segments, we believe the way forward is to eliminate the need for "small" segments, which will be possible once the PR below is completed: > > https://github.com/openjdk/jdk/pull/2045 Marked as reviewed by uschindler (no project role). test/micro/org/openjdk/bench/jdk/incubator/foreign/TestSmallCopy.java line 111: > 109: @OutputTimeUnit(TimeUnit.NANOSECONDS) > 110: public void segment_small_copy_fresh() { > 111: segment.asSlice(srcOffset, nbytes).copyFrom(MemorySegment.ofArray(bytes).asSlice(targetOffset, nbytes)); in our code we have the copy the other way round. Maybe add another memory segment -> heap array, too ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/560 From jvernee at openjdk.java.net Tue Jun 15 13:33:04 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Tue, 15 Jun 2021 13:33:04 GMT Subject: [foreign-memaccess+abi] RFR: 8268230: Foreign Linker API & Windows user32/kernel32: String conversion seems broken [v2] In-Reply-To: <0ZOia1B8PO-j284cRHT3_oVVMyWqCBUJT4emLo3BxZQ=.7b226aa8-d1c9-4a08-9910-18deb4ef0a24@github.com> References: <0ZOia1B8PO-j284cRHT3_oVVMyWqCBUJT4emLo3BxZQ=.7b226aa8-d1c9-4a08-9910-18deb4ef0a24@github.com> Message-ID: > The problem is that we only add a single 0 byte as a null terminator, regardless of the charset used. For wider char sets, more 0 bytes need to be added. For instance, for UTF_16LE two 0 bytes need to be added. > > This patch fixes the issue by adding the null terminator to the Java string, and only then encoding it as a `byte[]`. Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: - Merge branch 'foreign-memaccess+abi' into Windows_String_Encoding - Alternative fix: limit char set used to UTF-8 only. ------------- Changes: https://git.openjdk.java.net/panama-foreign/pull/554/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=554&range=01 Stats: 169 lines in 4 files changed: 65 ins; 94 del; 10 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/554.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/554/head:pull/554 PR: https://git.openjdk.java.net/panama-foreign/pull/554 From sebastian.stenzel at gmail.com Tue Jun 15 13:48:36 2021 From: sebastian.stenzel at gmail.com (Sebastian Stenzel) Date: Tue, 15 Jun 2021 15:48:36 +0200 Subject: [foreign-memaccess+abi] Integrated: 8268673: Stack walk across optimized entry frame on fresh native thread fails In-Reply-To: References: Message-ID: <867E09AC-6EB6-4B00-9FA3-94B5840375C6@gmail.com> Hi, I have pulled this fix (foreign-jextract commit e4f89d7b0f8) and can confirm that the crashes are gone. However, copying bytes from heap to native buffers still is a little odd. Take this code: [1]; [2] If I run the project with `-Djdk.internal.foreign.ProgrammableUpcallHandler.USE_INTRINSICS=false`, it copies the contents of HELLO_STR to the segment. Without the flag it copies 13 null-bytes, though. 13 being the correct length of the source buffer. I guess this is not related to the stack walking problem. The only thing I can tell is that said flag has some influence on the behaviour. Cheers! Sebastian [1] my upcall method: https://github.com/skymatic/fuse-panama/blob/3e5dc43ec7a6ba7e2c39fcce0db48d4350fdc0b3/src/main/java/de/skymatic/fusepanama/FuseOperations.java#L222-L227 [2] method invoked during upcall, which copies bytes to the specified segment: https://github.com/skymatic/fuse-panama/blob/3e5dc43ec7a6ba7e2c39fcce0db48d4350fdc0b3/src/test/java/de/skymatic/fusepanama/examples/HelloPanamaFileSystem.java#L109-L112 > On 14. Jun 2021, at 17:09, Jorn Vernee wrote: > > On Mon, 14 Jun 2021 12:13:52 GMT, Jorn Vernee wrote: > >> Hi, >> >> When native code creates a new thread and calls a Panama upcall, and during that upcall a stack walk is triggered, getting the sender frame for the entry frame is not possible, and should not be attempted. >> >> For JNI this case is handled already by indicating the end of the stack frame stream, but for Panama upcalls it is not, and the VM will either hit an assert or crash when trying to find the last Java frame before the entry frame (which does not exist in this case). >> >> This patch adds handling for panama upcalls frames to `frame::is_first_frame`, which is used by the stack walking code to determine when to stop walking. >> >> Thanks, >> Jorn > > This pull request has now been integrated. > > Changeset: 2287ca5a > Author: Jorn Vernee > URL: https://git.openjdk.java.net/panama-foreign/commit/2287ca5a530c348bc4ec7c0c6774e8ed9101dffa > Stats: 194 lines in 11 files changed: 193 ins; 0 del; 1 mod > > 8268673: Stack walk across optimized entry frame on fresh native thread fails > > Reviewed-by: mcimadamore > > ------------- > > PR: https://git.openjdk.java.net/panama-foreign/pull/558 From mcimadamore at openjdk.java.net Tue Jun 15 14:47:57 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 15 Jun 2021 14:47:57 GMT Subject: [foreign-memaccess+abi] RFR: 8268743: Require a better way for copying data between MemorySegments and on-heap arrays In-Reply-To: References: Message-ID: On Tue, 15 Jun 2021 11:56:26 GMT, Maurizio Cimadamore wrote: > After some investigation, it seems that escape analysis is defeated in cases where a new heap segment is created fresh just before performing a bulk copy. > > This is caused by the fact that, on segment creation, we perform this test: > > > static int defaultAccessModes(long size) { > return (enableSmallSegments && size < Integer.MAX_VALUE) ? > SMALL : 0; > } > > > To make sure that segments whose size fits in an `int` do not incur in penalties associated with lack of optimizations over long loop bound check optimizations. > > Unfortunately, this logic is control flow logic, and control flow disables escape analysis optimizations. > > For segment wrappers around byte arrays we can workaround by removing the check (all byte segments are small by definition, since there's a 1-1 mapping between logical elements and physical bytes). For other segment kinds we cannot do much. > > While it would be possible, in principle, to resort to more complex bound checks for heap segments, we believe the way forward is to eliminate the need for "small" segments, which will be possible once the PR below is completed: > > https://github.com/openjdk/jdk/pull/2045 I'm no longer too sure this will make an actual difference. While jmh shows _something_, digging deeper reveals that, in most iterations there's absolutely no allocation: # Run progress: 0.00% complete, ETA 00:00:22 # Fork: 1 of 3 WARNING: Using incubator modules: jdk.incubator.foreign # Warmup Iteration 1: 8.009 ns/op # Warmup Iteration 2: 6.775 ns/op # Warmup Iteration 3: 3.475 ns/op # Warmup Iteration 4: 6.647 ns/op # Warmup Iteration 5: 6.924 ns/op Iteration 1: 7.389 ns/op ?gc.alloc.rate: ? 10?? MB/sec ?gc.alloc.rate.norm: ? 10?? B/op ?gc.count: ? 0 counts Iteration 2: 6.593 ns/op ?gc.alloc.rate: ? 10?? MB/sec ?gc.alloc.rate.norm: ? 10?? B/op ?gc.count: ? 0 counts Iteration 3: 6.472 ns/op ?gc.alloc.rate: ? 10?? MB/sec ?gc.alloc.rate.norm: ? 10?? B/op ?gc.count: ? 0 counts Iteration 4: 7.103 ns/op ?gc.alloc.rate: ? 10?? MB/sec ?gc.alloc.rate.norm: ? 10?? B/op ?gc.count: ? 0 counts Iteration 5: 6.287 ns/op ?gc.alloc.rate: ? 10?? MB/sec ?gc.alloc.rate.norm: ? 10?? B/op ?gc.count: ? 0 counts Iteration 6: 6.976 ns/op ?gc.alloc.rate: ? 10?? MB/sec ?gc.alloc.rate.norm: ? 10?? B/op ?gc.count: ? 0 counts Iteration 7: 6.503 ns/op ?gc.alloc.rate: ? 10?? MB/sec ?gc.alloc.rate.norm: ? 10?? B/op ?gc.count: ? 0 counts Iteration 8: 7.057 ns/op ?gc.alloc.rate: ? 10?? MB/sec ?gc.alloc.rate.norm: ? 10?? B/op ?gc.count: ? 0 counts Iteration 9: 6.554 ns/op ?gc.alloc.rate: ? 10?? MB/sec ?gc.alloc.rate.norm: ? 10?? B/op ?gc.count: ? 0 counts Iteration 10: 6.654 ns/op ?gc.alloc.rate: ? 10?? MB/sec ?gc.alloc.rate.norm: ? 10?? B/op ?gc.count: ? 0 counts # Run progress: 33.33% complete, ETA 00:00:30 # Fork: 2 of 3 WARNING: Using incubator modules: jdk.incubator.foreign # Warmup Iteration 1: 7.538 ns/op # Warmup Iteration 2: 7.192 ns/op # Warmup Iteration 3: 7.222 ns/op # Warmup Iteration 4: 7.712 ns/op # Warmup Iteration 5: 6.882 ns/op Iteration 1: 7.016 ns/op ?gc.alloc.rate: ? 10?? MB/sec ?gc.alloc.rate.norm: ? 10?? B/op ?gc.count: ? 0 counts Iteration 2: 7.009 ns/op ?gc.alloc.rate: ? 10?? MB/sec ?gc.alloc.rate.norm: ? 10?? B/op ?gc.count: ? 0 counts Iteration 3: 6.958 ns/op ?gc.alloc.rate: ? 10?? MB/sec ?gc.alloc.rate.norm: ? 10?? B/op ?gc.count: ? 0 counts Iteration 4: 7.210 ns/op ?gc.alloc.rate: ? 10?? MB/sec ?gc.alloc.rate.norm: ? 10?? B/op ?gc.count: ? 0 counts Iteration 5: 7.860 ns/op ?gc.alloc.rate: ? 10?? MB/sec ?gc.alloc.rate.norm: ? 10?? B/op ?gc.count: ? 0 counts Iteration 6: 7.700 ns/op ?gc.alloc.rate: ? 10?? MB/sec ?gc.alloc.rate.norm: ? 10?? B/op ?gc.count: ? 0 counts Iteration 7: 3.655 ns/op // <------------------------------------------------------------------------------------ ?gc.alloc.rate: 21.009 MB/sec ?gc.alloc.rate.norm: 0.161 B/op ?gc.churn.G1_Eden_Space: 23.975 MB/sec ?gc.churn.G1_Eden_Space.norm: 0.184 B/op ?gc.churn.G1_Survivor_Space: 2.673 MB/sec ?gc.churn.G1_Survivor_Space.norm: 0.021 B/op ?gc.count: 1.000 counts ?gc.time: 2.000 ms Iteration 8: 7.049 ns/op ?gc.alloc.rate: ? 10?? MB/sec ?gc.alloc.rate.norm: ? 10?? B/op ?gc.count: ? 0 counts Iteration 9: 6.910 ns/op ?gc.alloc.rate: ? 10?? MB/sec ?gc.alloc.rate.norm: ? 10?? B/op ?gc.count: ? 0 counts Iteration 10: 7.325 ns/op ?gc.alloc.rate: ? 10?? MB/sec ?gc.alloc.rate.norm: ? 10?? B/op ?gc.count: ? 0 counts # Run progress: 66.67% complete, ETA 00:00:15 # Fork: 3 of 3 WARNING: Using incubator modules: jdk.incubator.foreign # Warmup Iteration 1: 7.798 ns/op # Warmup Iteration 2: 7.576 ns/op # Warmup Iteration 3: 7.088 ns/op # Warmup Iteration 4: 7.099 ns/op # Warmup Iteration 5: 7.232 ns/op Iteration 1: 7.368 ns/op ?gc.alloc.rate: ? 10?? MB/sec ?gc.alloc.rate.norm: ? 10?? B/op ?gc.count: ? 0 counts Iteration 2: 7.193 ns/op ?gc.alloc.rate: ? 10?? MB/sec ?gc.alloc.rate.norm: ? 10?? B/op ?gc.count: ? 0 counts Iteration 3: 6.731 ns/op ?gc.alloc.rate: ? 10?? MB/sec ?gc.alloc.rate.norm: ? 10?? B/op ?gc.count: ? 0 counts Iteration 4: 7.656 ns/op ?gc.alloc.rate: ? 10?? MB/sec ?gc.alloc.rate.norm: ? 10?? B/op ?gc.count: ? 0 counts Iteration 5: 7.626 ns/op ?gc.alloc.rate: ? 10?? MB/sec ?gc.alloc.rate.norm: ? 10?? B/op ?gc.count: ? 0 counts Iteration 6: 7.232 ns/op ?gc.alloc.rate: ? 10?? MB/sec ?gc.alloc.rate.norm: ? 10?? B/op ?gc.count: ? 0 counts Iteration 7: 7.276 ns/op ?gc.alloc.rate: ? 10?? MB/sec ?gc.alloc.rate.norm: ? 10?? B/op ?gc.count: ? 0 counts Iteration 8: 7.521 ns/op ?gc.alloc.rate: ? 10?? MB/sec ?gc.alloc.rate.norm: ? 10?? B/op ?gc.count: ? 0 counts Iteration 9: 6.777 ns/op ?gc.alloc.rate: ? 10?? MB/sec ?gc.alloc.rate.norm: ? 10?? B/op ?gc.count: ? 0 counts Iteration 10: 7.298 ns/op ?gc.alloc.rate: ? 10?? MB/sec ?gc.alloc.rate.norm: ? 10?? B/op ?gc.count: ? 0 counts (this benchmark test the copy in the same order as Lucene is doing it). Only _one_ iteration has non-zero allocation - presumably some kind of race between C2 and GC. But for the most part there's already no allocation here... at least according to JMH. We need a benchmark which reproduces the issue more precisely before attempting any fix, I think. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/560 From jorn.vernee at oracle.com Tue Jun 15 14:52:47 2021 From: jorn.vernee at oracle.com (Jorn Vernee) Date: Tue, 15 Jun 2021 16:52:47 +0200 Subject: [foreign-memaccess+abi] Integrated: 8268673: Stack walk across optimized entry frame on fresh native thread fails In-Reply-To: <867E09AC-6EB6-4B00-9FA3-94B5840375C6@gmail.com> References: <867E09AC-6EB6-4B00-9FA3-94B5840375C6@gmail.com> Message-ID: <9217bd50-e73d-d697-6021-2d35faef3901@oracle.com> Hi Sebastian, This sounds very odd, as the code you link to doesn't seem to use upcalls? The ProgrammableUpcallHandler.USE_INTRINSICS flag is only used to control the invocation mode of upcalls. May I ask how exactly you're diagnosing this problem? Jorn On 15/06/2021 15:48, Sebastian Stenzel wrote: > Hi, > > I have pulled this fix (foreign-jextract commit?e4f89d7b0f8) and can > confirm that the crashes are gone. However, copying bytes from heap to > native buffers still is a little odd. Take this code: [1]; [2] > > If I run the project with > `-Djdk.internal.foreign.ProgrammableUpcallHandler.USE_INTRINSICS=false`, > it copies the contents of?HELLO_STR to the segment. Without the flag > it copies 13 null-bytes, though. 13 being the correct length of the > source buffer. > > I guess this is not related to the stack walking problem. The only > thing I can tell is that said flag has some influence on the behaviour. > > Cheers! > Sebastian > > > [1] my upcall method: > https://github.com/skymatic/fuse-panama/blob/3e5dc43ec7a6ba7e2c39fcce0db48d4350fdc0b3/src/main/java/de/skymatic/fusepanama/FuseOperations.java#L222-L227 > > [2] method invoked during upcall, which copies bytes to the specified > segment: > https://github.com/skymatic/fuse-panama/blob/3e5dc43ec7a6ba7e2c39fcce0db48d4350fdc0b3/src/test/java/de/skymatic/fusepanama/examples/HelloPanamaFileSystem.java#L109-L112 > > > >> On 14. Jun 2021, at 17:09, Jorn Vernee > > wrote: >> >> On Mon, 14 Jun 2021 12:13:52 GMT, Jorn Vernee > > wrote: >> >>> Hi, >>> >>> When native code creates a new thread and calls a Panama upcall, and >>> during that upcall a stack walk is triggered, getting the sender >>> frame for the entry frame is not possible, and should not be attempted. >>> >>> For JNI this case is handled already by indicating the end of the >>> stack frame stream, but for Panama upcalls it is not, and the VM >>> will either hit an assert or crash when trying to find the last Java >>> frame before the entry frame (which does not exist in this case). >>> >>> This patch adds handling for panama upcalls frames to >>> `frame::is_first_frame`, which is used by the stack walking code to >>> determine when to stop walking. >>> >>> Thanks, >>> Jorn >> >> This pull request has now been integrated. >> >> Changeset: 2287ca5a >> Author: ???Jorn Vernee > >> URL: >> https://git.openjdk.java.net/panama-foreign/commit/2287ca5a530c348bc4ec7c0c6774e8ed9101dffa >> >> Stats: ????194 lines in 11 files changed: 193 ins; 0 del; 1 mod >> >> 8268673: Stack walk across optimized entry frame on fresh native >> thread fails >> >> Reviewed-by: mcimadamore >> >> ------------- >> >> PR: https://git.openjdk.java.net/panama-foreign/pull/558 >> > From sebastian.stenzel at gmail.com Tue Jun 15 15:10:26 2021 From: sebastian.stenzel at gmail.com (Sebastian Stenzel) Date: Tue, 15 Jun 2021 17:10:26 +0200 Subject: [foreign-memaccess+abi] Integrated: 8268673: Stack walk across optimized entry frame on fresh native thread fails In-Reply-To: <9217bd50-e73d-d697-6021-2d35faef3901@oracle.com> References: <867E09AC-6EB6-4B00-9FA3-94B5840375C6@gmail.com> <9217bd50-e73d-d697-6021-2d35faef3901@oracle.com> Message-ID: <9A957674-4160-4D88-9CB8-6E3A4F5F60DA@gmail.com> A reference to the first mentioned method is stored in a struct [1] (defined in fuse_operations.h) right here [2], which then gets passed to FUSE. FUSE then decides to call some of these methods when a corresponding file system access happens. [1]: https://github.com/skymatic/fuse-panama/blob/3e5dc43ec7a6ba7e2c39fcce0db48d4350fdc0b3/src/main/java/de/skymatic/fusepanama/lowlevel/fuse_operations.java#L28 [2]: https://github.com/skymatic/fuse-panama/blob/3e5dc43ec7a6ba7e2c39fcce0db48d4350fdc0b3/src/main/java/de/skymatic/fusepanama/FuseOperations.java#L25 > On 15. Jun 2021, at 16:52, Jorn Vernee wrote: > > Hi Sebastian, > > This sounds very odd, as the code you link to doesn't seem to use upcalls? The ProgrammableUpcallHandler.USE_INTRINSICS flag is only used to control the invocation mode of upcalls. > > May I ask how exactly you're diagnosing this problem? > > Jorn > > On 15/06/2021 15:48, Sebastian Stenzel wrote: >> Hi, >> >> I have pulled this fix (foreign-jextract commit e4f89d7b0f8) and can confirm that the crashes are gone. However, copying bytes from heap to native buffers still is a little odd. Take this code: [1]; [2] >> >> If I run the project with `-Djdk.internal.foreign.ProgrammableUpcallHandler.USE_INTRINSICS=false`, it copies the contents of HELLO_STR to the segment. Without the flag it copies 13 null-bytes, though. 13 being the correct length of the source buffer. >> >> I guess this is not related to the stack walking problem. The only thing I can tell is that said flag has some influence on the behaviour. >> >> Cheers! >> Sebastian >> >> >> [1] my upcall method: https://github.com/skymatic/fuse-panama/blob/3e5dc43ec7a6ba7e2c39fcce0db48d4350fdc0b3/src/main/java/de/skymatic/fusepanama/FuseOperations.java#L222-L227 >> [2] method invoked during upcall, which copies bytes to the specified segment: https://github.com/skymatic/fuse-panama/blob/3e5dc43ec7a6ba7e2c39fcce0db48d4350fdc0b3/src/test/java/de/skymatic/fusepanama/examples/HelloPanamaFileSystem.java#L109-L112 >> >>> On 14. Jun 2021, at 17:09, Jorn Vernee > wrote: >>> >>> On Mon, 14 Jun 2021 12:13:52 GMT, Jorn Vernee > wrote: >>> >>>> Hi, >>>> >>>> When native code creates a new thread and calls a Panama upcall, and during that upcall a stack walk is triggered, getting the sender frame for the entry frame is not possible, and should not be attempted. >>>> >>>> For JNI this case is handled already by indicating the end of the stack frame stream, but for Panama upcalls it is not, and the VM will either hit an assert or crash when trying to find the last Java frame before the entry frame (which does not exist in this case). >>>> >>>> This patch adds handling for panama upcalls frames to `frame::is_first_frame`, which is used by the stack walking code to determine when to stop walking. >>>> >>>> Thanks, >>>> Jorn >>> >>> This pull request has now been integrated. >>> >>> Changeset: 2287ca5a >>> Author: Jorn Vernee > >>> URL: https://git.openjdk.java.net/panama-foreign/commit/2287ca5a530c348bc4ec7c0c6774e8ed9101dffa >>> Stats: 194 lines in 11 files changed: 193 ins; 0 del; 1 mod >>> >>> 8268673: Stack walk across optimized entry frame on fresh native thread fails >>> >>> Reviewed-by: mcimadamore >>> >>> ------------- >>> >>> PR: https://git.openjdk.java.net/panama-foreign/pull/558 >> From jvernee at openjdk.java.net Tue Jun 15 15:12:16 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Tue, 15 Jun 2021 15:12:16 GMT Subject: [foreign-memaccess+abi] RFR: 8268230: Foreign Linker API & Windows user32/kernel32: String conversion seems broken [v3] In-Reply-To: <0ZOia1B8PO-j284cRHT3_oVVMyWqCBUJT4emLo3BxZQ=.7b226aa8-d1c9-4a08-9910-18deb4ef0a24@github.com> References: <0ZOia1B8PO-j284cRHT3_oVVMyWqCBUJT4emLo3BxZQ=.7b226aa8-d1c9-4a08-9910-18deb4ef0a24@github.com> Message-ID: <3_1mtSLk93iD0VBTmR62vwDV2AWxQPLCLIlc4whu2Xw=.a22367f4-e0ce-4429-8cf4-135fb06fd3d1@github.com> > The problem is that we only add a single 0 byte as a null terminator, regardless of the charset used. For wider char sets, more 0 bytes need to be added. For instance, for UTF_16LE two 0 bytes need to be added. > > This patch fixes the issue by adding the null terminator to the Java string, and only then encoding it as a `byte[]`. Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: Fix tests after merge ------------- Changes: - all: https://git.openjdk.java.net/panama-foreign/pull/554/files - new: https://git.openjdk.java.net/panama-foreign/pull/554/files/9df822a7..aba2b1a1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=554&range=02 - incr: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=554&range=01-02 Stats: 5 lines in 1 file changed: 0 ins; 5 del; 0 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/554.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/554/head:pull/554 PR: https://git.openjdk.java.net/panama-foreign/pull/554 From jvernee at openjdk.java.net Tue Jun 15 15:33:20 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Tue, 15 Jun 2021 15:33:20 GMT Subject: [foreign-memaccess+abi] RFR: 8268230: Foreign Linker API & Windows user32/kernel32: String conversion seems broken [v3] In-Reply-To: <3_1mtSLk93iD0VBTmR62vwDV2AWxQPLCLIlc4whu2Xw=.a22367f4-e0ce-4429-8cf4-135fb06fd3d1@github.com> References: <0ZOia1B8PO-j284cRHT3_oVVMyWqCBUJT4emLo3BxZQ=.7b226aa8-d1c9-4a08-9910-18deb4ef0a24@github.com> <3_1mtSLk93iD0VBTmR62vwDV2AWxQPLCLIlc4whu2Xw=.a22367f4-e0ce-4429-8cf4-135fb06fd3d1@github.com> Message-ID: On Tue, 15 Jun 2021 15:12:16 GMT, Jorn Vernee wrote: >> The problem is that we only add a single 0 byte as a null terminator, regardless of the charset used. For wider char sets, more 0 bytes need to be added. For instance, for UTF_16LE two 0 bytes need to be added. >> >> This patch fixes the issue by adding the null terminator to the Java string, and only then encoding it as a `byte[]`. > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > Fix tests after merge When looking into toJavaString, the problems turned out to be much greater. The problem essentially boils down to not having a `strlen` function for any arbitrary `Charset`, so we can only support a certain subset of `Charsets` for which we know our current way of determining the native string's length works. We discussed this at length among the team members, and arrived at the intermediate conclusion to only support the 'platform native' Charset. Though, this turns out to be tricky as well, as this charset, which is also called the 'execution character set' in C lingo, is determined based on a compiler setting at build time of the native code. With GCC and Clang the default is UTF-8, while on Windows it depends on the current code page. While there is a way to get the current code page of the runtime system and determine the character set from that, we would not be able to avoid issues with code page mismatches between the build environment and runtime environment on Windows, While it would still technically be possible to support different character sets as long as they work with `strlen`, at present there is no way to detect this for an arbitrary character set. So, if we kept the `Charset` parameter, we would not be able to sanity check it, which doesn't seem great either. As a result of all this, for now we have arrived at the decision to only support the UTF-8 Charset for the toCString and toJavaString methods, and to leave encoding and decoding using other character sets (including determining the length of a native string) to be implemented manually. I've updated this PR to remove the overloads that accept a `Charset`, and updated the implementation to always use UTF-8. I've added several test cases as well that test Unicode characters that get encoded with different amounts of bytes in UTF-8. Notice that the prime focus for this patch is stabilization (for JDK 17 as well). Perhaps in the future these APIs could be expanded to support more character sets again. test/jdk/java/foreign/TestStringEncoding.java line 60: > 58: { "yen \u00A5", 7 }, // in UTF-8 2 bytes: 0xC2 0xA5 > 59: { "snowman \u26C4", 12 }, // in UTF-8 three bytes: 0xE2 0x9B 0x84 > 60: { "rainbow \uD83C\uDF08", 13 } // int UTF-8 four bytes: 0xF0 0x9F 0x8C 0x88 Suggestion: { "rainbow \uD83C\uDF08", 13 } // in UTF-8 four bytes: 0xF0 0x9F 0x8C 0x88 ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/554 From jvernee at openjdk.java.net Tue Jun 15 15:33:18 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Tue, 15 Jun 2021 15:33:18 GMT Subject: [foreign-memaccess+abi] RFR: 8268230: Foreign Linker API & Windows user32/kernel32: String conversion seems broken [v4] In-Reply-To: <0ZOia1B8PO-j284cRHT3_oVVMyWqCBUJT4emLo3BxZQ=.7b226aa8-d1c9-4a08-9910-18deb4ef0a24@github.com> References: <0ZOia1B8PO-j284cRHT3_oVVMyWqCBUJT4emLo3BxZQ=.7b226aa8-d1c9-4a08-9910-18deb4ef0a24@github.com> Message-ID: > The problem is that we only add a single 0 byte as a null terminator, regardless of the charset used. For wider char sets, more 0 bytes need to be added. For instance, for UTF_16LE two 0 bytes need to be added. > > This patch fixes the issue by adding the null terminator to the Java string, and only then encoding it as a `byte[]`. Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: Typo in comment ------------- Changes: - all: https://git.openjdk.java.net/panama-foreign/pull/554/files - new: https://git.openjdk.java.net/panama-foreign/pull/554/files/aba2b1a1..273acec0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=554&range=03 - incr: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=554&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/554.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/554/head:pull/554 PR: https://git.openjdk.java.net/panama-foreign/pull/554 From elect86 at gmail.com Tue Jun 15 15:42:12 2021 From: elect86 at gmail.com (Giuseppe Barbieri) Date: Tue, 15 Jun 2021 17:42:12 +0200 Subject: Gihub Action, CI pipeline Message-ID: Hi, I'm looking at the `.github/workflows/submit.yml` file and it looks quite interesting and complete. I'm trying to fix/enhance it. I'd like to automatically publish a build if all tests pass. In this way, the jextract plugin may be able to just grab and use the latest available build. Would you be interested in a PR in this direction? Ps: I already fixed the linux-64 and macos x64 builds, I have no idea how to do the rest though, linux32 is build from 64, but if I pass the same LLVM I use in linux-64, it still complains: configure: error: Cannot locate libclang or headers at the specified locations: /home/runner/work/panama-foreign/panama-foreign/clang+llvm-12.0.0-x86_64-linux-gnu-ubuntu-20.04/lib /home/runner/work/panama-foreign/panama-foreign/clang+llvm-12.0.0-x86_64-linux-gnu-ubuntu-20.04/include configure exiting with result code 1 https://github.com/elect86/panama-foreign/runs/2830854989?check_suite_focus=true#step:11:282 For Windows, the LLVM release page has only .exe, so I'm unsure how to continue there, while for macOS arm there is no LLVM build.. However one single test fails: TestLinkToNativeRBP /home/runner/work/panama-foreign/panama-foreign/test/hotspot/jtreg/gc/shenandoah/compiler/TestLinkToNativeRBP.java:51: error: cannot find symbol static final LibraryLookup lookup = LibraryLookup.ofLibrary("LinkToNativeRBP"); And indeed there is no LibraryLookup in the current snapshot, shall this be removed or? Giuseppe From jorn.vernee at oracle.com Tue Jun 15 15:46:16 2021 From: jorn.vernee at oracle.com (Jorn Vernee) Date: Tue, 15 Jun 2021 17:46:16 +0200 Subject: [External] : Re: [foreign-memaccess+abi] Integrated: 8268673: Stack walk across optimized entry frame on fresh native thread fails In-Reply-To: <9A957674-4160-4D88-9CB8-6E3A4F5F60DA@gmail.com> References: <867E09AC-6EB6-4B00-9FA3-94B5840375C6@gmail.com> <9217bd50-e73d-d697-6021-2d35faef3901@oracle.com> <9A957674-4160-4D88-9CB8-6E3A4F5F60DA@gmail.com> Message-ID: Ok thanks, If upcalls are involved it makes sense then that the ProgrammableUpcallHandler.USE_INTRINSICS has an effect. Both invocation modes should behave the same, but the implementations are completely separate, so if setting the flag to false makes a difference there might be a problem when passing one of the arguments when USE_INTRINSICS=true. Thanks for testing, I'll try and reproduce the issue here as well. Jorn On 15/06/2021 17:10, Sebastian Stenzel wrote: > A reference to the first mentioned method is stored in a struct [1] > (defined in fuse_operations.h) right here [2], which then gets passed > to FUSE. FUSE then decides to call some of these methods when a > corresponding file system access happens. > > [1]: > https://github.com/skymatic/fuse-panama/blob/3e5dc43ec7a6ba7e2c39fcce0db48d4350fdc0b3/src/main/java/de/skymatic/fusepanama/lowlevel/fuse_operations.java#L28 > > [2]: > https://github.com/skymatic/fuse-panama/blob/3e5dc43ec7a6ba7e2c39fcce0db48d4350fdc0b3/src/main/java/de/skymatic/fusepanama/FuseOperations.java#L25 > > > >> On 15. Jun 2021, at 16:52, Jorn Vernee > > wrote: >> >> Hi Sebastian, >> >> This sounds very odd, as the code you link to doesn't seem to use >> upcalls? The ProgrammableUpcallHandler.USE_INTRINSICS flag is only >> used to control the invocation mode of upcalls. >> >> May I ask how exactly you're diagnosing this problem? >> >> Jorn >> >> On 15/06/2021 15:48, Sebastian Stenzel wrote: >>> Hi, >>> >>> I have pulled this fix (foreign-jextract commit?e4f89d7b0f8) and can >>> confirm that the crashes are gone. However, copying bytes from heap >>> to native buffers still is a little odd. Take this code: [1]; [2] >>> >>> If I run the project with >>> `-Djdk.internal.foreign.ProgrammableUpcallHandler.USE_INTRINSICS=false`, >>> it copies the contents of?HELLO_STR to the segment. Without the flag >>> it copies 13 null-bytes, though. 13 being the correct length of the >>> source buffer. >>> >>> I guess this is not related to the stack walking problem. The only >>> thing I can tell is that said flag has some influence on the behaviour. >>> >>> Cheers! >>> Sebastian >>> >>> >>> [1] my upcall method: >>> https://github.com/skymatic/fuse-panama/blob/3e5dc43ec7a6ba7e2c39fcce0db48d4350fdc0b3/src/main/java/de/skymatic/fusepanama/FuseOperations.java#L222-L227 >>> >>> [2] method invoked during upcall, which copies bytes to the >>> specified segment: >>> https://github.com/skymatic/fuse-panama/blob/3e5dc43ec7a6ba7e2c39fcce0db48d4350fdc0b3/src/test/java/de/skymatic/fusepanama/examples/HelloPanamaFileSystem.java#L109-L112 >>> >>> >>> >>>> On 14. Jun 2021, at 17:09, Jorn Vernee >>> > wrote: >>>> >>>> On Mon, 14 Jun 2021 12:13:52 GMT, Jorn Vernee >>> > wrote: >>>> >>>>> Hi, >>>>> >>>>> When native code creates a new thread and calls a Panama upcall, >>>>> and during that upcall a stack walk is triggered, getting the >>>>> sender frame for the entry frame is not possible, and should not >>>>> be attempted. >>>>> >>>>> For JNI this case is handled already by indicating the end of the >>>>> stack frame stream, but for Panama upcalls it is not, and the VM >>>>> will either hit an assert or crash when trying to find the last >>>>> Java frame before the entry frame (which does not exist in this case). >>>>> >>>>> This patch adds handling for panama upcalls frames to >>>>> `frame::is_first_frame`, which is used by the stack walking code >>>>> to determine when to stop walking. >>>>> >>>>> Thanks, >>>>> Jorn >>>> >>>> This pull request has now been integrated. >>>> >>>> Changeset: 2287ca5a >>>> Author: ???Jorn Vernee >>> > >>>> URL: >>>> https://git.openjdk.java.net/panama-foreign/commit/2287ca5a530c348bc4ec7c0c6774e8ed9101dffa >>>> >>>> Stats: ????194 lines in 11 files changed: 193 ins; 0 del; 1 mod >>>> >>>> 8268673: Stack walk across optimized entry frame on fresh native >>>> thread fails >>>> >>>> Reviewed-by: mcimadamore >>>> >>>> ------------- >>>> >>>> PR: https://git.openjdk.java.net/panama-foreign/pull/558 >>>> >>> > From sviswanathan at openjdk.java.net Tue Jun 15 16:20:23 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Tue, 15 Jun 2021 16:20:23 GMT Subject: [vectorIntrinsics] RFR: Merge panama-vector:master [v2] In-Reply-To: References: Message-ID: > This pull request merges master changes into vectorIntrinsics. > > @nsjian Need your help to merge test/hotspot/gtest/aarch64/asmtest.out.h (I have left the git merge markers in place for asmtest.out.h). > > Best Regards, > Sandhya Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision: asmtest.out.h from Ningsheng ------------- Changes: - all: https://git.openjdk.java.net/panama-vector/pull/92/files - new: https://git.openjdk.java.net/panama-vector/pull/92/files/95fd30ba..446f6e14 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=92&range=01 - incr: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=92&range=00-01 Stats: 270 lines in 1 file changed: 19 ins; 171 del; 80 mod Patch: https://git.openjdk.java.net/panama-vector/pull/92.diff Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/92/head:pull/92 PR: https://git.openjdk.java.net/panama-vector/pull/92 From sviswanathan at openjdk.java.net Tue Jun 15 16:23:11 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Tue, 15 Jun 2021 16:23:11 GMT Subject: [vectorIntrinsics] Integrated: Merge panama-vector:master In-Reply-To: References: Message-ID: On Fri, 11 Jun 2021 17:37:44 GMT, Sandhya Viswanathan wrote: > This pull request merges master changes into vectorIntrinsics. > > @nsjian Need your help to merge test/hotspot/gtest/aarch64/asmtest.out.h (I have left the git merge markers in place for asmtest.out.h). > > Best Regards, > Sandhya This pull request has now been integrated. Changeset: d353bd93 Author: Sandhya Viswanathan URL: https://git.openjdk.java.net/panama-vector/commit/d353bd93982689302a33e2008c33c5465f2cc001 Stats: 159101 lines in 4623 files changed: 79268 ins; 65866 del; 13967 mod Merge panama-vector:master Co-authored-by: Ningsheng Jian ------------- PR: https://git.openjdk.java.net/panama-vector/pull/92 From mcimadamore at openjdk.java.net Tue Jun 15 18:00:52 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 15 Jun 2021 18:00:52 GMT Subject: [foreign-memaccess+abi] RFR: 8268743: Require a better way for copying data between MemorySegments and on-heap arrays In-Reply-To: References: Message-ID: On Tue, 15 Jun 2021 13:05:28 GMT, Uwe Schindler wrote: >>> But we have no solution for larger sizes like float[] or long[] arrays? >> >> Not for now - the real solution is to fix the performance woes which makes the implementation do all these workarounds for longs vs. ints. That said, I'd be curious, once this is integrated, if you could do a quick validation and re-run that benchmark where you were seeing lots of byte segment wrappers in the heap and make sure at least that behaves as expected. > >> > But we have no solution for larger sizes like float[] or long[] arrays? >> >> Not for now - the real solution is to fix the performance woes which makes the implementation do all these workarounds for longs vs. ints. That said, I'd be curious, once this is integrated, if you could do a quick validation and re-run that benchmark where you were seeing lots of byte segment wrappers in the heap and make sure at least that behaves as expected. > > For sure. > > @rmuir and I already discussed about that. From what we understand: `readLong(long[], offset, count)` in our case is never reading more than 64 longs because of the limitations of PFOR algorithm inside Lucene. So we would remove the specialization in MemorySegmentIndexinput and the superclass will use a loop of readLong() instead. This also goes in line with your hint to copyMemory liveness check overhead. The readFloat variant we have is reading a maximum of 1024 float dimensions for our vector suppotr, I will do some quick investigations later, but I tend to remove the specialization, too. In future we will use FloatVector from vector API and that should possibly be wrapped over the memory segment (see also https://github.com/apache/lucene/pull/18 for some quick investigations). For the longs and the PFOR algorithm we may also use a vectorized approach in future, so readFloat() and readLongs() will go away and be replaced to return a FloatVector/LongVector view on the memory segm ent (using ByteBuffer view or directly once panama and vector can share APIs). > > The biggest problem on our side is our implementation of `readBytes(byte[], offset, count)` which is fixed here. Adding a static method which avoids all the slicing doesn't seem to help performance-wise. It is still slower than an Unsafe call (20-25%). If that would help narrow things down, we could try adding such a static method at least in the Panama repo and maybe we could test that with Lucene? At least we would have removed allocations out of the equation (but I suspect that allocation is not where the performance slowdown is coming from). @uschindler let me know what would be the easiest for you to try. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/560 From duke at openjdk.java.net Tue Jun 15 18:07:33 2021 From: duke at openjdk.java.net (J.Duke) Date: Tue, 15 Jun 2021 18:07:33 GMT Subject: [foreign-memaccess+abi] RFR: Merge master [v2] In-Reply-To: <6kQYH0G20x-RRsm0Wnoz6kxqojOS3kNnhezWdHo6CTY=.d6ee4399-8a23-4089-8e32-a364843bb91f@github.com> References: <6kQYH0G20x-RRsm0Wnoz6kxqojOS3kNnhezWdHo6CTY=.d6ee4399-8a23-4089-8e32-a364843bb91f@github.com> Message-ID: > Hi all, > > this is an _automatically_ generated pull request to notify you that there are 141 commits from the branch `master`that can **not** be merged into the branch `foreign-memaccess+abi`: > > The following files contains merge conflicts: > > - src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java > - src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/SystemLookup.java > - src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/SharedUtils.java > - test/jdk/java/foreign/TestUpcallException.java > - test/jdk/java/foreign/ThrowingUpcall.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-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 +100:openjdk-bot-100 > $ git checkout openjdk-bot-100 > > # 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-100:100 > > > _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 142 commits: - Merge branch 'foreign-memaccess+abi' into openjdk-bot-100 - Automatic merge of jdk:master into master - 8268565: runtime/records/RedefineRecord.java should be run in driver mode Reviewed-by: hseigel - 8267930: Refine code for loading hsdis library Reviewed-by: whuang, neliasso, ysuenaga - 8268574: ProblemList tests failing due to UseBiasedLocking going away Reviewed-by: cjplummer - 8267556: Enhance class paths check during runtime Reviewed-by: minqi, iklam - 8267893: Improve jtreg test failure handler do get native/mixed stack traces for cores and live processes Reviewed-by: iignatyev - 8268223: Problemlist vmTestbase/nsk/jdi/HiddenClass/events/events001.java Reviewed-by: amenkov, sspitsyn - 8268539: several serviceability/sa tests should be run in driver mode Reviewed-by: sspitsyn - 8268361: Fix the infinite loop in next_line Reviewed-by: dholmes, sgehwolf, sspitsyn - ... and 132 more: https://git.openjdk.java.net/panama-foreign/compare/3cc47de0...c74525ac ------------- Changes: https://git.openjdk.java.net/panama-foreign/pull/556/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=556&range=01 Stats: 49958 lines in 839 files changed: 39954 ins; 5667 del; 4337 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/556.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/556/head:pull/556 PR: https://git.openjdk.java.net/panama-foreign/pull/556 From duke at openjdk.java.net Tue Jun 15 18:12:01 2021 From: duke at openjdk.java.net (J.Duke) Date: Tue, 15 Jun 2021 18:12:01 GMT Subject: [foreign-memaccess+abi] Integrated: Merge master In-Reply-To: <6kQYH0G20x-RRsm0Wnoz6kxqojOS3kNnhezWdHo6CTY=.d6ee4399-8a23-4089-8e32-a364843bb91f@github.com> References: <6kQYH0G20x-RRsm0Wnoz6kxqojOS3kNnhezWdHo6CTY=.d6ee4399-8a23-4089-8e32-a364843bb91f@github.com> Message-ID: <15qTzl1dM0-C2O3ilYSz5lJkXGM0dp1-8z0ikKQdkNE=.7547b0a6-1079-44ba-94e3-b08768c6c79b@github.com> On Fri, 11 Jun 2021 11:01:27 GMT, J. Duke wrote: > Hi all, > > this is an _automatically_ generated pull request to notify you that there are 141 commits from the branch `master`that can **not** be merged into the branch `foreign-memaccess+abi`: > > The following files contains merge conflicts: > > - src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java > - src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/SystemLookup.java > - src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/SharedUtils.java > - test/jdk/java/foreign/TestUpcallException.java > - test/jdk/java/foreign/ThrowingUpcall.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-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 +100:openjdk-bot-100 > $ git checkout openjdk-bot-100 > > # 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-100:100 > > > _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: 599b146e Author: J. Duke Committer: Jorn Vernee URL: https://git.openjdk.java.net/panama-foreign/commit/599b146ee5c679b618d616edc4e855877a12b822 Stats: 49958 lines in 839 files changed: 39954 ins; 5667 del; 4337 mod Merge master ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/556 From mcimadamore at openjdk.java.net Tue Jun 15 18:13:51 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 15 Jun 2021 18:13:51 GMT Subject: [foreign-memaccess+abi] RFR: 8268230: Foreign Linker API & Windows user32/kernel32: String conversion seems broken [v4] In-Reply-To: References: <0ZOia1B8PO-j284cRHT3_oVVMyWqCBUJT4emLo3BxZQ=.7b226aa8-d1c9-4a08-9910-18deb4ef0a24@github.com> Message-ID: On Tue, 15 Jun 2021 15:33:18 GMT, Jorn Vernee wrote: >> The problem is that we only add a single 0 byte as a null terminator, regardless of the charset used. For wider char sets, more 0 bytes need to be added. For instance, for UTF_16LE two 0 bytes need to be added. >> >> This patch fixes the issue by adding the null terminator to the Java string, and only then encoding it as a `byte[]`. > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > Typo in comment Looks sensible! ------------- Marked as reviewed by mcimadamore (Committer). PR: https://git.openjdk.java.net/panama-foreign/pull/554 From duke at openjdk.java.net Tue Jun 15 18:27:21 2021 From: duke at openjdk.java.net (duke) Date: Tue, 15 Jun 2021 18:27:21 GMT Subject: git: openjdk/panama-foreign: foreign-jextract: 143 new changesets Message-ID: <77ceac96-34ee-4a47-8648-ca97685e5baf@openjdk.org> Changeset: b27599b3 Author: Joe Wang Date: 2021-06-04 16:31:59 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b27599b3ec3fd344fa9fa97b7ecde85d5662ca6c 8268222: javax/xml/jaxp/unittest/transform/Bug6216226Test.java failed, cannot delete file Reviewed-by: dfuchs ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerImpl.java ! src/java.xml/share/classes/javax/xml/transform/stream/StreamResult.java Changeset: cd0678fc Author: Stuart Marks Date: 2021-06-04 17:13:05 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/cd0678fcf6bc00ecda3e61d959617c67d02dba3c 8199318: add idempotent copy operation for Map.Entry Reviewed-by: alanb, psandoz, dfuchs ! src/java.base/share/classes/java/util/AbstractMap.java ! src/java.base/share/classes/java/util/Map.java ! test/jdk/java/util/Map/MapFactories.java Changeset: 64ec8b3e Author: Leonid Mesnik Date: 2021-06-04 17:22:01 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/64ec8b3e5c8a8d44c92591710d73b833f13c1500 8212155: Race condition when posting dynamic_code_generated event leads to JVM crash Reviewed-by: sspitsyn, dcubed ! src/hotspot/share/prims/jvmtiExport.cpp + test/hotspot/jtreg/serviceability/jvmti/DynamicCodeGenerated/DynamicCodeGeneratedTest.java + test/hotspot/jtreg/serviceability/jvmti/DynamicCodeGenerated/libDynamicCodeGenerated.cpp Changeset: 20b63127 Author: Sandhya Viswanathan Date: 2021-06-04 18:16:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/20b631278c0c89ccd9c16f2a29d47eb8414aacd5 8268151: Vector API toShuffle optimization Reviewed-by: psandoz, vlivanov ! src/hotspot/share/opto/vector.cpp ! src/hotspot/share/opto/vectorIntrinsics.cpp ! src/hotspot/share/opto/vectornode.cpp ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/DoubleMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/DoubleVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/FloatMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/FloatVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/IntMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/IntVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/LongMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/LongVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ShortMaxVector.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 ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-VectorBits.java.template Changeset: 48dc72b7 Author: Vladimir Kozlov Date: 2021-06-04 20:10:59 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/48dc72b74d6b4b7b8fb605b62fc0057b5f4652e1 8268272: Remove JDK-8264874 changes because Graal was removed. Reviewed-by: erikj ! make/Main.gmk Changeset: 4e6748c5 Author: Yi Yang Date: 2021-06-04 23:29:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4e6748c543fae89b5f5f42bb0345b4b4f97d817a 8267687: ModXNode::Ideal optimization is better than Parse::do_irem Reviewed-by: neliasso, kvn ! src/hotspot/share/opto/parse.hpp ! src/hotspot/share/opto/parse2.cpp + test/micro/org/openjdk/bench/vm/compiler/ModPowerOf2.java Changeset: 76b54a19 Author: Nick Gasson Date: 2021-06-04 23:55:12 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/76b54a19955cd93f071cf1fb45c6d01bb57b84eb 8263512: [macos_aarch64] issues with calling va_args functions from invoke_native Reviewed-by: jvernee ! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/CABI.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/PlatformLayouts.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/SystemLookup.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/SharedUtils.java - src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/aarch64/AArch64Linker.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/aarch64/CallArranger.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/aarch64/TypeClass.java + src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/aarch64/linux/LinuxAArch64Linker.java = src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/aarch64/linux/LinuxAArch64VaList.java + src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/aarch64/macos/MacOsAArch64Linker.java + src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/aarch64/macos/MacOsAArch64VaList.java ! test/jdk/ProblemList.txt ! test/jdk/java/foreign/valist/VaListTest.java ! test/jdk/java/foreign/valist/libVaList.c Changeset: 6ff978ac Author: Jonathan Gibbons Date: 2021-06-05 00:05:17 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6ff978ac16e631ebded7964d89ac42fd0452b1d3 8267204: Expose access to underlying streams in Reporter Reviewed-by: prappo ! src/jdk.javadoc/share/classes/jdk/javadoc/doclet/Reporter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/Messages.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/Messager.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/Start.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/ToolEnvironment.java ! test/langtools/jdk/javadoc/doclet/testDiagsLineCaret/TestDiagsLineCaret.java + test/langtools/jdk/javadoc/doclet/testReporterStreams/TestReporterStreams.java ! test/langtools/jdk/javadoc/lib/javadoc/tester/JavadocTester.java ! test/langtools/jdk/javadoc/tool/EnsureNewOldDoclet.java ! test/langtools/jdk/javadoc/tool/api/basic/GetTask_DiagListenerTest.java Changeset: 7e41ca3d Author: Yasumasa Suenaga Date: 2021-06-05 00:07:04 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7e41ca3da820650e16d9ca7f5b188628cd666419 8266957: SA has not followed JDK-8220587 and JDK-8224965 Reviewed-by: cjplummer, sspitsyn ! src/hotspot/share/gc/z/vmStructs_z.cpp ! src/hotspot/share/gc/z/vmStructs_z.hpp ! src/hotspot/share/gc/z/zAttachedArray.hpp ! src/hotspot/share/gc/z/zForwardingEntry.hpp ! src/hotspot/share/gc/z/zForwardingTable.hpp ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZAddress.java + src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZAttachedArrayForForwarding.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZBarrier.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZCollectedHeap.java + src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZForwarding.java + src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZForwardingEntry.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZForwardingTable.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZGlobals.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZGlobalsForVMStructs.java + src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZGranuleMapForForwarding.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZHash.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZHeap.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZOop.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZPage.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZPageTable.java + src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZRelocate.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZUtils.java ! test/hotspot/jtreg/ProblemList-zgc.txt Changeset: 7f55dc15 Author: Sibabrata Sahoo Date: 2021-06-05 07:56:14 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7f55dc15769bbab59024aa49671bced633de40ed 8179880: Refactor javax/security shell tests to plain java tests Reviewed-by: weijun ! test/jdk/javax/security/auth/Subject/doAs/Test.java - test/jdk/javax/security/auth/Subject/doAs/Test.sh Changeset: 6c838c56 Author: Stephen Colebourne Committer: Roger Riggs Date: 2021-06-05 13:26:52 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6c838c568c2c99145fd0ae8059de2b2865b65863 8266846: Add java.time.InstantSource Reviewed-by: rriggs, naoto, darcy ! src/java.base/share/classes/java/time/Clock.java ! src/java.base/share/classes/java/time/Instant.java + src/java.base/share/classes/java/time/InstantSource.java ! test/jdk/java/time/test/TEST.properties ! test/jdk/java/time/test/java/time/TestClock_System.java + test/jdk/java/time/test/java/time/TestInstantSource.java Changeset: 36bff6f9 Author: Andrey Turbanov Committer: Jim Laskey Date: 2021-06-05 14:44:25 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/36bff6f945a1eb6b1bbe21070a345df50095e918 8066694: Strange code in JavacParser.java Reviewed-by: vromero, iris ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java Changeset: 91f9adc5 Author: Ioi Lam Date: 2021-06-05 15:22:38 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/91f9adc5f55b42d30e46d99e22a8d0567fa5c146 8268139: CDS ArchiveBuilder may reference unloaded classes Reviewed-by: coleenp, ccheung ! src/hotspot/share/cds/dynamicArchive.cpp ! src/hotspot/share/cds/metaspaceShared.cpp ! src/hotspot/share/classfile/systemDictionaryShared.cpp ! src/hotspot/share/classfile/systemDictionaryShared.hpp Changeset: b2e9eb9e Author: Sergey Bylokhov Date: 2021-06-05 15:41:04 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b2e9eb9e47beb5148e3b9f86f25fad352ed4a236 8268087: Update documentation of the JPasswordField Reviewed-by: trebari, azvegint, prr ! src/java.desktop/share/classes/javax/swing/JPasswordField.java Changeset: f768fbf7 Author: Daniel D. Daugherty Date: 2021-06-05 15:50:18 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f768fbf7a9df6eae10298ba6bd1b4ae438ca298d 8268286: ProblemList serviceability/sa/TestJmapCore.java on linux-aarch64 with ZGC Reviewed-by: rriggs ! test/hotspot/jtreg/ProblemList-zgc.txt Changeset: b05c40ca Author: Jatin Bhateja Date: 2021-06-05 18:07:14 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b05c40ca3b5fd34cbbc7a9479b108a4ff2c099f1 8266951: Partial in-lining for vectorized mismatch operation using AVX512 masked instructions Reviewed-by: psandoz, vlivanov ! 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/vm_version_x86.cpp ! src/hotspot/cpu/x86/x86.ad ! src/hotspot/share/adlc/formssel.cpp ! src/hotspot/share/opto/arraycopynode.cpp ! src/hotspot/share/opto/c2_globals.hpp ! src/hotspot/share/opto/castnode.hpp ! src/hotspot/share/opto/classes.hpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/opto/macroArrayCopy.cpp ! src/hotspot/share/opto/matcher.cpp ! src/hotspot/share/opto/vectornode.cpp ! src/hotspot/share/opto/vectornode.hpp ! test/hotspot/jtreg/compiler/arraycopy/TestArrayCopyConjoint.java ! test/hotspot/jtreg/compiler/arraycopy/TestArrayCopyDisjoint.java + test/hotspot/jtreg/compiler/intrinsics/VectorizedMismatchTest.java ! test/jtreg-ext/requires/VMProps.java + test/micro/org/openjdk/bench/java/util/ArraysMismatchPartialInlining.java Changeset: 8abf36c6 Author: Jatin Bhateja Date: 2021-06-06 02:31:18 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8abf36c6484bca20d1c31476f4d6f553aeeadb27 8268289: build failure due to missing signed flag in x86 evcmpb instruction Reviewed-by: vlivanov, jiefu ! src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp Changeset: 042f0bdb Author: Tejpal Rebari Date: 2021-06-06 04:08:05 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/042f0bdb3568edab4f96b9f7c83cbb0f90db7f18 8256465: [macos] Java frame and dialog presented full screen freeze application Reviewed-by: kcr, serb, prr ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/java.desktop/macosx/native/libawt_lwawt/awt/AWTWindow.m + test/jdk/java/awt/Window/TestAppFreeze.java Changeset: 52d88ee1 Author: Jie Fu Date: 2021-06-06 13:53:29 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/52d88ee1d1e0f6b9927db03a2b0bff75e4be03a2 8268292: compiler/intrinsics/VectorizedMismatchTest.java fails with release VMs Reviewed-by: dcubed ! test/hotspot/jtreg/compiler/intrinsics/VectorizedMismatchTest.java Changeset: 95ddf7d6 Author: Hamlin Li Date: 2021-06-07 01:19:32 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/95ddf7d6ada599e57feefca7fa9c6379e6a23523 8267839: trivial mem leak in numa Co-authored-by: Shoubing Ma Reviewed-by: tschatzl, sjohanss ! src/hotspot/os/linux/os_linux.hpp Changeset: b05fa02e Author: Hui Shi Committer: Jie Fu Date: 2021-06-07 01:34:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b05fa02e7413fdcc40969645309e3e9d4442c78d 8267904: C2 crash when compile negative Arrays.copyOf length after loop Reviewed-by: roland, kvn ! src/hotspot/share/opto/callnode.cpp ! src/hotspot/share/opto/graphKit.cpp ! src/hotspot/share/opto/library_call.cpp + test/hotspot/jtreg/compiler/c2/TestNegativeArrayCopyAfterLoop.java Changeset: 2aeeeb40 Author: Xin Liu Committer: Jie Fu Date: 2021-06-07 06:12:04 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2aeeeb40a06c0c71537ce7de2e00bab9faf817a9 8268279: gc/shenandoah/compiler/TestLinkToNativeRBP.java fails after LibraryLookup is gone Reviewed-by: zgu, jiefu ! test/hotspot/jtreg/gc/shenandoah/compiler/TestLinkToNativeRBP.java Changeset: 204b4929 Author: Stefan Johansson Date: 2021-06-07 06:22:11 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/204b4929f7251feec6736aed9489ff82cd5dd744 8267703: runtime/cds/appcds/cacheObject/HeapFragmentationTest.java crashed with OutOfMemory Reviewed-by: tschatzl, kbarrett ! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp ! src/hotspot/share/gc/g1/g1FullCollector.cpp Changeset: 3e482440 Author: Hui Shi Committer: Jie Fu Date: 2021-06-07 06:26:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3e48244084ef90fb7f46cdfd691ae9f0ecb2de41 8268301: Closed test: compiler/c2/6371167/Test.java fails after JDK-8267904 Reviewed-by: kvn, dlong ! src/hotspot/share/opto/callnode.cpp ! src/hotspot/share/opto/graphKit.cpp ! src/hotspot/share/opto/library_call.cpp - test/hotspot/jtreg/compiler/c2/TestNegativeArrayCopyAfterLoop.java Changeset: 908aca29 Author: Jan Lahoda Date: 2021-06-07 07:01:30 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/908aca29ca60f5f251df8c6a31b2543929be12fc 8262891: Compiler implementation for Pattern Matching for switch (Preview) Co-authored-by: Brian Goetz Co-authored-by: Mandy Chung Co-authored-by: Jan Lahoda Reviewed-by: mcimadamore, forax, godin, psandoz, mchung ! make/CompileInterimLangtools.gmk + src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java + src/java.base/share/classes/jdk/internal/javac/NoPreview.java ! src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java + src/jdk.compiler/share/classes/com/sun/source/tree/CaseLabelTree.java ! src/jdk.compiler/share/classes/com/sun/source/tree/CaseTree.java + src/jdk.compiler/share/classes/com/sun/source/tree/DefaultCaseLabelTree.java ! src/jdk.compiler/share/classes/com/sun/source/tree/ExpressionTree.java + src/jdk.compiler/share/classes/com/sun/source/tree/GuardedPatternTree.java + src/jdk.compiler/share/classes/com/sun/source/tree/ParenthesizedPatternTree.java ! src/jdk.compiler/share/classes/com/sun/source/tree/PatternTree.java ! src/jdk.compiler/share/classes/com/sun/source/tree/Tree.java ! src/jdk.compiler/share/classes/com/sun/source/tree/TreeVisitor.java ! src/jdk.compiler/share/classes/com/sun/source/util/SimpleTreeVisitor.java ! src/jdk.compiler/share/classes/com/sun/source/util/TreeScanner.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Preview.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/MatchBindingsComputer.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransTypes.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TreeDiffer.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/CRTable.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeCopier.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeScanner.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeTranslator.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java + test/jdk/java/lang/runtime/SwitchBootstrapsTest.java ! test/langtools/tools/javac/classfiles/attributes/LineNumberTable/LineNumberTestBase.java + test/langtools/tools/javac/classfiles/attributes/LineNumberTable/RuleSwitchBreaks.java ! test/langtools/tools/javac/classfiles/attributes/LineNumberTable/TestCase.java ! test/langtools/tools/javac/diags/examples/CantRefNonEffectivelyFinalVar.java + test/langtools/tools/javac/diags/examples/CaseNull.java + test/langtools/tools/javac/diags/examples/ConstantLabelNotCompatible.java + test/langtools/tools/javac/diags/examples/DuplicateTotalPattern.java + test/langtools/tools/javac/diags/examples/FlowsThroughFromPattern.java + test/langtools/tools/javac/diags/examples/FlowsThroughToPattern.java + test/langtools/tools/javac/diags/examples/NotExhaustiveStatement.java + test/langtools/tools/javac/diags/examples/PatternDominated.java + test/langtools/tools/javac/diags/examples/PatternSwitch.java - test/langtools/tools/javac/diags/examples/SwitchNullNotAllowed.java + test/langtools/tools/javac/diags/examples/TotalPatternAndDefault.java ! test/langtools/tools/javac/lib/DPrinter.java + test/langtools/tools/javac/patterns/CaseDefault.java + test/langtools/tools/javac/patterns/CaseDefault.out + test/langtools/tools/javac/patterns/DisambiguateParenthesizedPattern.java + test/langtools/tools/javac/patterns/Domination.java + test/langtools/tools/javac/patterns/Domination.out + test/langtools/tools/javac/patterns/Exhaustiveness.java + test/langtools/tools/javac/patterns/Guards.java + test/langtools/tools/javac/patterns/GuardsErrors.java + test/langtools/tools/javac/patterns/GuardsErrors.out + test/langtools/tools/javac/patterns/NullSwitch.java + test/langtools/tools/javac/patterns/Parenthesized.java + test/langtools/tools/javac/patterns/SealedTypeChanges.java + test/langtools/tools/javac/patterns/SealedTypeChanges2.java + test/langtools/tools/javac/patterns/SimpleAndGuardPattern.java + test/langtools/tools/javac/patterns/SwitchErrors.java + test/langtools/tools/javac/patterns/SwitchErrors.out + test/langtools/tools/javac/patterns/Switches.java + test/langtools/tools/javac/stackmap/OrdinarySwitchStackMapTest.java ! test/langtools/tools/javac/switchextra/SwitchNoExtraTypes.out ! test/langtools/tools/javac/switchextra/SwitchObject.out + test/langtools/tools/javac/switchnull/SwitchNull.java + test/langtools/tools/javac/switchnull/SwitchNullDisabled-preview.out ! test/langtools/tools/javac/switchnull/SwitchNullDisabled.java ! test/langtools/tools/javac/switchnull/SwitchNullDisabled.out ! test/langtools/tools/javac/tree/SourceTreeScannerTest.java ! test/langtools/tools/jdeps/listdeps/ListModuleDeps.java Changeset: 9fc914b9 Author: Leo Korinth Date: 2021-06-07 08:02:26 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9fc914b96321c24e14f1b52246df0b816cb7dafa 8204686: Dynamic parallel reference processing support for Parallel GC Reviewed-by: ayang, tschatzl, kbarrett ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/parallel/parallelArguments.cpp ! src/hotspot/share/gc/parallel/psScavenge.cpp ! src/hotspot/share/gc/shared/referenceProcessor.cpp ! src/hotspot/share/gc/shared/referenceProcessor.hpp ! test/hotspot/jtreg/gc/arguments/TestParallelRefProc.java Changeset: 58bdabcd Author: Albert Mingkun Yang Date: 2021-06-07 08:20:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/58bdabcd40cc8895d5fd829ad3515ab418245c16 8268164: Adopt cast notation for WorkerThread conversions Reviewed-by: stefank, dholmes ! src/hotspot/share/gc/shared/referenceProcessor.cpp ! src/hotspot/share/runtime/nonJavaThread.hpp ! src/hotspot/share/runtime/thread.hpp ! src/hotspot/share/runtime/thread.inline.hpp Changeset: 6d1f3ac7 Author: Hannes Walln?fer Date: 2021-06-07 08:43:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6d1f3ac74914db662d2a39a5b69d8b8143d2f3ef 8149138: [javadoc] Fix SerialFormBuilder eliminate String bashing Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlSerialFieldWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/SerializedFormWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/SerializedFormBuilder.java ! test/langtools/jdk/javadoc/doclet/testSerializedForm/SerializedForm.java ! test/langtools/jdk/javadoc/doclet/testSerializedForm/TestSerializedForm.java Changeset: 5ebd4199 Author: Erik ?sterlund Date: 2021-06-07 09:44:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5ebd4199cc57b60ab7345a019d000c0017a90fc3 8267972: Inline cache cleaning is not monotonic Reviewed-by: vlivanov, kvn ! src/hotspot/share/code/compiledIC.cpp Changeset: b09d8b98 Author: Xin Liu Committer: David Holmes Date: 2021-06-07 10:19:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b09d8b9800329f946df80026d61cd4abf41cff37 8267926: AsyncLogGtest.java fails on assert with: decorator was not part of the decorator set specified at creation. Reviewed-by: dholmes, phh ! src/hotspot/share/logging/logDecorations.hpp ! test/hotspot/jtreg/ProblemList.txt Changeset: 8130be56 Author: David Holmes Date: 2021-06-07 10:23:12 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8130be561b76906be660e6d779839eb197bd7486 8268318: Missing comma in copyright header Reviewed-by: stefank ! test/langtools/jdk/javadoc/doclet/testSerializedForm/SerializedForm.java Changeset: e4d04540 Author: Jan Lahoda Date: 2021-06-07 11:13:13 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e4d045402fa1992a1d91586bd4f67362d07f543c 8267832: SimpleVisitors and Scanners in jdk.compiler should use @implSpec Reviewed-by: prappo, darcy ! src/jdk.compiler/share/classes/com/sun/source/util/DocTreeScanner.java ! src/jdk.compiler/share/classes/com/sun/source/util/SimpleDocTreeVisitor.java ! src/jdk.compiler/share/classes/com/sun/source/util/SimpleTreeVisitor.java ! src/jdk.compiler/share/classes/com/sun/source/util/TreeScanner.java Changeset: 15715a89 Author: Thomas Schatzl Date: 2021-06-07 13:18:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/15715a8984e3e346c2a65e5a0c7b48c4dee21d3e 8267924: Misleading G1 eager reclaim detail logging Reviewed-by: ayang, sjohanss ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.cpp ! test/hotspot/jtreg/gc/g1/TestG1TraceEagerReclaimHumongousObjects.java Changeset: 728a411a Author: Hamlin Li Date: 2021-06-07 13:41:44 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/728a411a541f93121bbd7db4258859196bcf6cdf 8268018: remove dead code in commitLimitter Reviewed-by: zgu ! src/hotspot/share/memory/metaspace/commitLimiter.hpp Changeset: 4f9d6b7d Author: Vicente Romero Date: 2021-06-07 13:57:15 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4f9d6b7d68312860d3e184a1f33687e1693d7d87 8267465: remove superfluous preview related annotations and test options Reviewed-by: jlahoda ! src/jdk.compiler/share/classes/com/sun/source/util/TreeScanner.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacRoundEnvironment.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/processing/PrintingProcessor.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/comp/PubapiVisitor.java ! test/langtools/jdk/jshell/SealedClassesTest.java ! test/langtools/tools/javac/annotations/repeatingAnnotations/NoTargetOnContainer.java ! test/langtools/tools/javac/annotations/repeatingAnnotations/NoTargetOnContainer2.java ! test/langtools/tools/javac/annotations/typeAnnotations/classfile/CombinationsTargetTest2.java ! test/langtools/tools/javac/annotations/typeAnnotations/classfile/Patterns.java ! test/langtools/tools/javac/api/TestGetElementReference.java ! test/langtools/tools/javac/api/TestGetScopeResult.java ! test/langtools/tools/javac/api/lambdaErrorRecovery/TestGetTypeMirrorReference.java ! test/langtools/tools/javac/diags/examples/IllegalStartOfStmt.java ! test/langtools/tools/javac/lambda/deduplication/DeduplicationTest.java ! test/langtools/tools/javac/parser/JavacParserTest.java ! test/langtools/tools/javac/processing/model/element/AnnoProcessorOnRecordsTest.java ! test/langtools/tools/javac/processing/model/element/CheckingTypeAnnotationsOnRecords.java ! test/langtools/tools/javac/processing/model/element/ErrorOnAnnoWithTargetMethod.java ! test/langtools/tools/javac/processing/model/element/RecordNotPreservingNestedTypeAnnotationsTest.java ! test/langtools/tools/javac/processing/model/element/TestBindingVariable.java ! test/langtools/tools/javac/processing/model/element/TestRecord.java ! test/langtools/tools/javac/processing/model/element/TestRecordDesugar.java ! test/langtools/tools/javac/processing/model/element/repeatingAnnotations/RepeatingAnnotationsOnRecords.java ! test/langtools/tools/javac/sealed/BinaryCompatibilityTests.java ! test/langtools/tools/javac/sealed/CheckSubtypesOfSealedTest.java ! test/langtools/tools/javac/sealed/SealedCompilationTests.java ! test/langtools/tools/javac/sealed/T8258662/T8258662.java ! test/langtools/tools/javac/warnings/DefaultCtor/NoWarningRecord.java Changeset: a91f9712 Author: Weijun Wang Date: 2021-06-07 13:58:49 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a91f97126646f89d8c5b81cfd40820338c769acd 8268267: Remove -Djavatest.security.noSecurityManager=true from jtreg runs Reviewed-by: lancea, jjg, erikj ! make/RunTests.gmk ! test/langtools/ProblemList.txt Changeset: ea8274fb Author: Zhengyu Gu Date: 2021-06-07 14:00:19 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ea8274fbf07d7308bcef5aacbe553dc7b37887e3 8267875: Shenandoah: Duplicated code in ShenandoahBarrierSetC2::ideal_node() Reviewed-by: rkennke, roland ! src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.cpp Changeset: 270ec975 Author: Thomas Schatzl Date: 2021-06-07 14:09:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/270ec975b69d4e9a73571c4ba21b705e48d3e1b4 8268331: Fix crash in humongous object eager reclaim logging Reviewed-by: sjohanss ! src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.cpp Changeset: 3396b69f Author: Christian Hagedorn Date: 2021-06-07 14:11:50 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3396b69fc91db4a9e29806562215f92179ba4757 8254129: IR Test Framework to support regex-based matching on the IR in JTreg compiler tests Co-authored-by: Christian Hagedorn Co-authored-by: Tobias Hartmann Reviewed-by: iignatyev + test/hotspot/jtreg/compiler/lib/ir_framework/AbstractInfo.java + test/hotspot/jtreg/compiler/lib/ir_framework/Argument.java + test/hotspot/jtreg/compiler/lib/ir_framework/Arguments.java + test/hotspot/jtreg/compiler/lib/ir_framework/Check.java + test/hotspot/jtreg/compiler/lib/ir_framework/CheckAt.java + test/hotspot/jtreg/compiler/lib/ir_framework/CompLevel.java + test/hotspot/jtreg/compiler/lib/ir_framework/Compiler.java + test/hotspot/jtreg/compiler/lib/ir_framework/DontCompile.java + test/hotspot/jtreg/compiler/lib/ir_framework/DontInline.java + test/hotspot/jtreg/compiler/lib/ir_framework/ForceCompile.java + test/hotspot/jtreg/compiler/lib/ir_framework/ForceCompileClassInitializer.java + test/hotspot/jtreg/compiler/lib/ir_framework/ForceInline.java + test/hotspot/jtreg/compiler/lib/ir_framework/IR.java + test/hotspot/jtreg/compiler/lib/ir_framework/IRNode.java + test/hotspot/jtreg/compiler/lib/ir_framework/IRs.java + test/hotspot/jtreg/compiler/lib/ir_framework/README.md + test/hotspot/jtreg/compiler/lib/ir_framework/Run.java + test/hotspot/jtreg/compiler/lib/ir_framework/RunInfo.java + test/hotspot/jtreg/compiler/lib/ir_framework/RunMode.java + test/hotspot/jtreg/compiler/lib/ir_framework/Scenario.java + test/hotspot/jtreg/compiler/lib/ir_framework/Test.java + test/hotspot/jtreg/compiler/lib/ir_framework/TestFramework.java + test/hotspot/jtreg/compiler/lib/ir_framework/TestInfo.java + test/hotspot/jtreg/compiler/lib/ir_framework/Warmup.java + test/hotspot/jtreg/compiler/lib/ir_framework/driver/FlagVMProcess.java + test/hotspot/jtreg/compiler/lib/ir_framework/driver/IRMatcher.java + test/hotspot/jtreg/compiler/lib/ir_framework/driver/IRMethod.java + test/hotspot/jtreg/compiler/lib/ir_framework/driver/IRViolationException.java + test/hotspot/jtreg/compiler/lib/ir_framework/driver/TestVMException.java + test/hotspot/jtreg/compiler/lib/ir_framework/driver/TestVMProcess.java + test/hotspot/jtreg/compiler/lib/ir_framework/flag/FlagVM.java + test/hotspot/jtreg/compiler/lib/ir_framework/shared/CheckedTestFrameworkException.java + test/hotspot/jtreg/compiler/lib/ir_framework/shared/NoTestsRunException.java + test/hotspot/jtreg/compiler/lib/ir_framework/shared/ParsedComparator.java + test/hotspot/jtreg/compiler/lib/ir_framework/shared/TestFormat.java + test/hotspot/jtreg/compiler/lib/ir_framework/shared/TestFormatException.java + test/hotspot/jtreg/compiler/lib/ir_framework/shared/TestFrameworkException.java + test/hotspot/jtreg/compiler/lib/ir_framework/shared/TestFrameworkSocket.java + test/hotspot/jtreg/compiler/lib/ir_framework/shared/TestRun.java + test/hotspot/jtreg/compiler/lib/ir_framework/shared/TestRunException.java + test/hotspot/jtreg/compiler/lib/ir_framework/test/AbstractTest.java + test/hotspot/jtreg/compiler/lib/ir_framework/test/ArgumentValue.java + test/hotspot/jtreg/compiler/lib/ir_framework/test/BaseTest.java + test/hotspot/jtreg/compiler/lib/ir_framework/test/CheckedTest.java + test/hotspot/jtreg/compiler/lib/ir_framework/test/CustomRunTest.java + test/hotspot/jtreg/compiler/lib/ir_framework/test/DeclaredTest.java + test/hotspot/jtreg/compiler/lib/ir_framework/test/IREncodingPrinter.java + test/hotspot/jtreg/compiler/lib/ir_framework/test/TestVM.java + test/hotspot/jtreg/testlibrary_tests/ir_framework/examples/BaseTestExample.java + test/hotspot/jtreg/testlibrary_tests/ir_framework/examples/CheckedTestExample.java + test/hotspot/jtreg/testlibrary_tests/ir_framework/examples/CustomRunTestExample.java + test/hotspot/jtreg/testlibrary_tests/ir_framework/examples/IRExample.java + test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/README.md + test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestAccessModifiers.java + test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestBadFormat.java + test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestBasics.java + test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestCompLevels.java + test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestControls.java + test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestDFlags.java + test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestDIgnoreCompilerControls.java + test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestDScenarios.java + test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestDTestAndExclude.java + test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestIRMatching.java + test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestRunTests.java + test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestSanity.java + test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestScenarios.java + test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestWithHelperClasses.java Changeset: e663ba96 Author: Joe Darcy Date: 2021-06-07 17:03:50 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e663ba961f25c83758815bbfce97a58d9560c7a2 8268299: jvms tag produces incorrect URL Reviewed-by: iris, erikj, jjg ! make/jdk/src/classes/build/tools/taglet/JSpec.java Changeset: 7e55569e Author: Alexey Ushakov Date: 2021-06-07 17:36:52 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7e55569edee84dcae63fbdf1f89fefa554360736 8261549: Adjust memory size in MTLTexurePool.m Reviewed-by: prr ! src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLTexurePool.m Changeset: 81600dce Author: Roger Riggs Date: 2021-06-07 17:41:09 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/81600dce24903cbd3476830e302c9f182c85efb3 8191441: (Process) add Readers and Writer access to java.lang.Process streams Reviewed-by: naoto, alanb ! src/java.base/share/classes/java/lang/Process.java + test/jdk/java/lang/ProcessBuilder/ReaderWriterTest.java Changeset: e546ae27 Author: Liam Miller-Cushon Date: 2021-06-07 17:58:57 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e546ae27ffc6c19ae078a41ab6e1741a104958c1 8268296: ScopedMemoryAccess build error with readonly filesystems Reviewed-by: erikj ! make/modules/java.base/gensrc/GensrcScopedMemoryAccess.gmk Changeset: c7c77fd3 Author: Anthony Scarpino Date: 2021-06-07 22:22:28 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c7c77fd32b1b1bc736ef3523456a2968447fc627 8255557: Decouple GCM from CipherCore Reviewed-by: valeriep ! src/java.base/share/classes/com/sun/crypto/provider/AESCipher.java ! src/java.base/share/classes/com/sun/crypto/provider/CipherCore.java ! src/java.base/share/classes/com/sun/crypto/provider/FeedbackCipher.java + src/java.base/share/classes/com/sun/crypto/provider/GCM.java ! src/java.base/share/classes/com/sun/crypto/provider/GCTR.java ! src/java.base/share/classes/com/sun/crypto/provider/GHASH.java ! src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java ! src/java.base/share/classes/com/sun/crypto/provider/SunJCE.java ! src/java.base/share/classes/sun/security/util/SecurityProviderConstants.java ! test/jdk/com/sun/crypto/provider/Cipher/AEAD/Encrypt.java ! test/jdk/com/sun/crypto/provider/Cipher/AEAD/GCMBufferTest.java + test/jdk/com/sun/crypto/provider/Cipher/AEAD/GCMShortBuffer.java ! test/jdk/com/sun/crypto/provider/Cipher/AEAD/OverlapByteBuffer.java ! test/jdk/com/sun/crypto/provider/Cipher/AES/TestAESCipher.java ! test/jdk/com/sun/crypto/provider/Cipher/AES/TestSameBuffer.java Changeset: 5e557d86 Author: Kevin Walls Date: 2021-06-07 22:26:13 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5e557d8650d81f9f81938892de28a6dd8fea98b0 8266967: debug.cpp utility find() should print Java Object fields. Reviewed-by: sspitsyn, coleenp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/instanceKlass.hpp ! src/hotspot/share/runtime/fieldDescriptor.cpp ! src/hotspot/share/runtime/fieldDescriptor.hpp Changeset: fc08af58 Author: Dan Smith Date: 2021-06-07 23:21:24 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fc08af58cb0571ed375a7937aac7a951ba224644 8174222: LambdaMetafactory: validate inputs and improve documentation Reviewed-by: mchung ! src/hotspot/share/include/jvm.h ! src/hotspot/share/prims/jvm.cpp ! src/java.base/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java ! src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java ! src/java.base/share/classes/java/lang/invoke/LambdaMetafactory.java ! src/java.base/share/classes/java/lang/invoke/LambdaProxyClassArchive.java ! src/java.base/share/native/libjava/LambdaProxyClassArchive.c + test/jdk/java/lang/invoke/lambda/MetafactoryArgValidationTest.java Changeset: 36c4e5f2 Author: Jonathan Gibbons Date: 2021-06-08 02:16:56 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/36c4e5f26477ed6bd17ac565d5301eba7d424058 8267187: Remove deprecated constructor for Log Reviewed-by: darcy, iris ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/Log.java Changeset: ae986bc8 Author: Alan Hayward Committer: Ningsheng Jian Date: 2021-06-08 02:24:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ae986bc8dff92a77e91e6ee640aa27c68abb8def 8266749: AArch64: Backtracing broken on PAC enabled systems Reviewed-by: gziemski, aph ! src/hotspot/cpu/aarch64/frame_aarch64.cpp ! src/hotspot/cpu/aarch64/frame_aarch64.hpp ! src/hotspot/cpu/aarch64/frame_aarch64.inline.hpp + src/hotspot/cpu/aarch64/pauth_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/windows_aarch64/pauth_windows_aarch64.inline.hpp Changeset: f40c89e8 Author: Thomas Stuefe Date: 2021-06-08 03:57:38 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f40c89e8e9fae26da53b5d820d8e64d9b30faf8c 8267209: Child threads should defer logging to after child-parent handshake Reviewed-by: dholmes, coleenp ! src/hotspot/os/bsd/os_bsd.cpp ! src/hotspot/os/linux/os_linux.cpp Changeset: 341f6760 Author: David Holmes Date: 2021-06-08 04:53:02 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/341f676066ab807d433f0f0b6c8356d2ad0e1cc9 8267908: linux: thread_native_entry can scribble on stack frame Reviewed-by: ysuenaga ! src/hotspot/os/linux/os_linux.cpp Changeset: 81bad590 Author: Aditya Mandaleeka Committer: Stefan Johansson Date: 2021-06-08 06:55:20 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/81bad5904284a251c65c8c86cc373d29974d0686 8257774: G1: Trigger collect when free region count drops below threshold to prevent evacuation failures Reviewed-by: sjohanss, tschatzl ! src/hotspot/share/gc/g1/g1AllocRegion.hpp ! src/hotspot/share/gc/g1/g1AllocRegion.inline.hpp ! src/hotspot/share/gc/g1/g1Allocator.hpp ! src/hotspot/share/gc/g1/g1Allocator.inline.hpp ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1CollectionSet.cpp ! src/hotspot/share/gc/g1/g1CollectionSet.hpp ! src/hotspot/share/gc/g1/g1Policy.cpp ! src/hotspot/share/gc/g1/g1Policy.hpp ! src/hotspot/share/gc/g1/g1VMOperations.cpp ! src/hotspot/share/gc/g1/g1VMOperations.hpp ! src/hotspot/share/gc/g1/g1_globals.hpp ! src/hotspot/share/gc/shared/gcCause.cpp ! src/hotspot/share/gc/shared/gcCause.hpp ! test/hotspot/jtreg/gc/g1/TestGCLogMessages.java Changeset: fd91b2aa Author: Koichi Sakata Committer: Christian Hagedorn Date: 2021-06-08 07:14:42 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fd91b2aa57e0b621d195a5ae025b84c858583251 8265440: IGV: make node selection more visible Reviewed-by: chagedorn, neliasso ! src/utils/IdealGraphVisualizer/View/src/main/java/com/sun/hotspot/igv/view/widgets/FigureWidget.java ! src/utils/IdealGraphVisualizer/View/src/main/java/com/sun/hotspot/igv/view/widgets/SlotWidget.java Changeset: 81054789 Author: Xin Liu Committer: Yasumasa Suenaga Date: 2021-06-08 07:20:13 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/81054789a32f29b06f0804e09aabd7cf17464778 8268165: AsyncLogging will crash if rotate() fails LogFileOutput::rotate() may leave _stream NULL because os::fopen() may return NULL due to space or inode limitations. AsyncLogWriter::write() calls LogFileOutput::write_blocking() without null check. Null check is added to prevent from crashing. Reviewed-by: ysuenaga ! src/hotspot/share/logging/logFileOutput.cpp Changeset: 00c88f79 Author: Matthias Baesken Date: 2021-06-08 07:22:03 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/00c88f79b30d7867be4a66317b90b9ba7e947f4f 8266918: merge_stack in check_code.c add NULL check Reviewed-by: rschmelter, clanger ! src/java.base/share/native/libverify/check_code.c Changeset: 61ab4b9d Author: Michael McMahon Date: 2021-06-08 07:58:54 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/61ab4b9d18e7c2eee6691f3ee00e5fecb866fdcd 8267564: JDK-8252971 causes SPECjbb2015 socket exceptions on Windows when MKS is installed Reviewed-by: alanb ! src/java.base/share/classes/sun/nio/ch/UnixDomainSockets.java ! src/java.base/unix/native/libnio/ch/UnixDomainSockets.c ! src/java.base/windows/native/libnio/ch/UnixDomainSockets.c Changeset: 89da2021 Author: Ajit Ghaisas Date: 2021-06-08 09:45:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/89da2021ee194efd70f367f8fec16994335c38aa 8266159: macOS ARM + Metal pipeline shows artifacts on Swing Menu with Java L&F Reviewed-by: jdv, prr ! src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/shaders.metal + test/jdk/java/awt/Graphics/DrawOvalTest.java Changeset: 2717fcb1 Author: Joel Borggr?n-Franck Date: 2021-06-08 10:51:19 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2717fcb1345379d9856a33148d548eccb7b708f4 8232948: javac -h should mangle the overload argument signature Reviewed-by: jjg ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/JNIWriter.java + test/langtools/tools/javac/nativeHeaders/EncodeInnerClassNameTest.java Changeset: 6843576c Author: Maurizio Cimadamore Date: 2021-06-08 14:02:28 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6843576c95a70bffad95df278d5f5be29371bca4 8268227: java/foreign/TestUpcall.java still times out Reviewed-by: dcubed ! test/jdk/java/foreign/TestDowncall.java ! test/jdk/java/foreign/TestUpcall.java Changeset: 8158b822 Author: Jorn Vernee Date: 2021-06-08 14:20:31 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8158b82269513a60c13bb10a6edfa82f806e8efc 8268327: Upstream: 8268169: The system lookup can not find stdio functions such as printf on Windows 10 Reviewed-by: erikj, sundar ! make/modules/jdk.incubator.foreign/Lib.gmk ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/SystemLookup.java + src/jdk.incubator.foreign/windows/native/libWinFallbackLookup/WinFallbackLookup.c ! test/jdk/java/foreign/StdLibTest.java - test/jdk/java/foreign/libStdLib.c Changeset: 159cb6fa Author: Nikita Gubarkov Committer: Alexey Ushakov Date: 2021-06-08 14:35:58 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/159cb6facc668acc30552665e46b18edf58c3a91 8268083: JDK-8267706 breaks bin/idea.sh on a Mac Reviewed-by: erikj ! bin/idea.sh ! make/common/Utils.gmk ! make/ide/idea/jdk/idea.gmk ! make/ide/idea/jdk/template/compiler.xml ! make/ide/idea/jdk/template/jdk.iml ! make/ide/idea/jdk/template/misc.xml ! make/ide/idea/jdk/template/module.iml ! make/ide/idea/jdk/template/test.iml ! make/ide/idea/jdk/template/vcs.xml ! make/ide/idea/jdk/template/workspace.xml ! test/make/TestMakeBase.gmk Changeset: c21cc932 Author: Ioi Lam Date: 2021-06-08 16:47:38 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c21cc932f0a217299689df6c2abcdbc629a668bf 8248877: Document API contract for MetaspaceObj subtypes Reviewed-by: coleenp, minqi ! src/hotspot/share/memory/allocation.hpp Changeset: b568e879 Author: Alex Menkov Date: 2021-06-08 17:05:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b568e87947a5d7f1d8c20e3e8a8b2b7f77265c8b 8237388: serviceability/dcmd/framework/VMVersionTest.java fails with connection refused error. Reviewed-by: cjplummer, sspitsyn ! test/hotspot/jtreg/serviceability/dcmd/framework/TestProcessLauncher.java ! test/hotspot/jtreg/serviceability/dcmd/framework/process/TestJavaProcess.java ! test/hotspot/jtreg/vmTestbase/nsk/share/jpda/IOPipe.java ! test/hotspot/jtreg/vmTestbase/nsk/share/jpda/SocketConnection.java ! test/hotspot/jtreg/vmTestbase/nsk/share/jpda/SocketIOPipe.java Changeset: fafc4d97 Author: Jonathan Gibbons Date: 2021-06-08 17:23:17 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fafc4d976434c196c16b652c859073c5888b992e 8268352: Rename javadoc Messager class to JavadocLog Reviewed-by: prappo ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/ElementsTable.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/JavadocEnter.java = src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/JavadocLog.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/JavadocTool.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/Start.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/ToolEnvironment.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/ToolOptions.java ! test/langtools/jdk/javadoc/tool/CheckResourceKeys.java ! test/langtools/jdk/javadoc/tool/api/basic/JavadocTaskImplTest.java Changeset: dc6c96bb Author: Hannes Walln?fer Date: 2021-06-08 18:22:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/dc6c96bbaf1c0af3eacaa2e59646ed7c5bb0767d 8263468: New page for "recent" new API Reviewed-by: erikj, jjg ! make/Docs.gmk ! make/autoconf/jdk-version.m4 ! make/autoconf/spec.gmk.in ! make/conf/version-numbers.conf ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Contents.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/DeprecatedListWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HelpWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlConfiguration.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDoclet.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/Navigation.java + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/NewAPIListWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PreviewListWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SummaryListWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Table.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlStyle.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 ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/DeprecatedAPIListBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/DocPaths.java + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/NewAPIBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/PreviewAPIListBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/SummaryAPIListBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java ! test/langtools/jdk/javadoc/doclet/testDeprecatedDocs/TestDeprecatedDocs.java ! test/langtools/jdk/javadoc/doclet/testHtmlTableStyles/TestHtmlTableStyles.java ! test/langtools/jdk/javadoc/doclet/testHtmlTableTags/TestHtmlTableTags.java ! test/langtools/jdk/javadoc/doclet/testModules/TestModules.java + test/langtools/jdk/javadoc/doclet/testNewApiList/TestNewApiList.java + test/langtools/jdk/javadoc/doclet/testNewApiList/mdl/module-info.java + test/langtools/jdk/javadoc/doclet/testNewApiList/mdl/pkg/TestAnnotation.java + test/langtools/jdk/javadoc/doclet/testNewApiList/mdl/pkg/TestClass.java + test/langtools/jdk/javadoc/doclet/testNewApiList/mdl/pkg/TestEnum.java + test/langtools/jdk/javadoc/doclet/testNewApiList/mdl/pkg/TestError.java + test/langtools/jdk/javadoc/doclet/testNewApiList/mdl/pkg/TestException.java + test/langtools/jdk/javadoc/doclet/testNewApiList/mdl/pkg/TestInterface.java + test/langtools/jdk/javadoc/doclet/testNewApiList/mdl/pkg/TestRecord.java + test/langtools/jdk/javadoc/doclet/testNewApiList/mdl/pkg/package-info.java + test/langtools/jdk/javadoc/doclet/testNewApiList/pkg/TestClass.java ! test/langtools/jdk/javadoc/doclet/testRecordTypes/TestRecordTypes.java Changeset: 4dd0e7e7 Author: Hannes Walln?fer Date: 2021-06-08 18:49:31 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4dd0e7e78aab23e5c98f3457dd6c14788780becd 8259806: Clean up terminology on the "All Classes" page Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AllClassesIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Contents.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HelpWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlIndexBuilder.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/resources/doclets.properties ! test/langtools/jdk/javadoc/doclet/testModules/TestModules.java ! test/langtools/jdk/javadoc/doclet/testPackagePage/TestPackagePage.java ! test/langtools/jdk/javadoc/doclet/testSearch/TestSearch.java ! test/langtools/jdk/javadoc/doclet/testUnnamedPackage/TestUnnamedPackage.java Changeset: f9b593d6 Author: Hannes Walln?fer Date: 2021-06-08 19:21:21 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f9b593d668147979a16e743fe138d4e447e8232b 8266748: Move modifiers code to Signatures.java Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Signatures.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/ClassWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/ClassBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java Changeset: 51e8201e Author: Andy Herrick Date: 2021-06-08 19:46:40 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/51e8201eb5a66a8fbbff21194fd35389343baee1 8267764: jpackage cannot handle window screensaver files when EXE renamed as SCR Reviewed-by: asemenyuk, almatvee ! src/jdk.jpackage/windows/native/common/WinFileUtils.cpp + test/jdk/tools/jpackage/windows/WinRenameTest.java Changeset: 7a378165 Author: Joe Darcy Date: 2021-06-08 20:21:26 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7a37816548b913494b9671df9469b159cc62ae73 8264866: Remove unneeded WorkArounds.isAutomaticModule Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/WorkArounds.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Extern.java Changeset: 5ad4a91c Author: Zhengyu Gu Date: 2021-06-08 20:31:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5ad4a91c3d89f7118a99e5bd56fc86a9a6d57abf 8268127: Shenandoah: Heap size may be too small for region to align to large page size Reviewed-by: rkennke, shade ! src/hotspot/share/gc/shenandoah/shenandoahArguments.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.hpp Changeset: ae160529 Author: Jiangli Zhou Date: 2021-06-08 20:35:40 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ae16052951fbff21abf02271b761055cd2eed14b 8268088: Clarify Method::clear_jmethod_ids() related comments in ClassLoaderData::~ClassLoaderData() Reviewed-by: iklam ! src/hotspot/share/classfile/classLoaderData.cpp Changeset: bcaa2cb1 Author: Alexey Semenyuk Date: 2021-06-08 22:21:40 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bcaa2cb154ae5d23a067f6e38a19a21eef8fe8e8 8264144: Add handling of "--about-url" CLI parameter for RPM/DEB packages Reviewed-by: herrick, almatvee ! src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxDebBundler.java ! src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxRpmBundler.java ! src/jdk.jpackage/linux/classes/jdk/jpackage/internal/resources/template.control ! src/jdk.jpackage/linux/classes/jdk/jpackage/internal/resources/template.spec + test/jdk/tools/jpackage/linux/AppAboutUrlTest.java Changeset: f6f82c31 Author: Sergey Bylokhov Date: 2021-06-09 00:14:40 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f6f82c31689e68f4263bbbe2314033d69f9049f5 8266421: Deadlock in Sound System Reviewed-by: prr, azvegint ! src/java.desktop/share/classes/com/sun/media/sound/AbstractDataLine.java ! src/java.desktop/share/classes/com/sun/media/sound/AbstractLine.java ! src/java.desktop/share/classes/com/sun/media/sound/DirectAudioDevice.java + test/jdk/javax/sound/sampled/Clip/SetPositionHang.java Changeset: 1c3932f3 Author: Joe Wang Date: 2021-06-09 00:34:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1c3932f3d5ec47678f55769cb6a9f657ace411c6 8264766: ClassCastException during template compilation (Variable cannot be cast to Param) Reviewed-by: naoto ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/SymbolTable.java + test/jaxp/javax/xml/jaxp/unittest/transform/SymbolTableTest.java Changeset: 58a59e3d Author: Jack Hartstein Committer: Jamil Nimeh Date: 2021-06-09 02:12:25 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/58a59e3dcb830211e1eef8122c9f7113c00ded4c 8240997: Remove more "hack" word in security codes Reviewed-by: xuelei ! src/java.base/share/classes/sun/security/rsa/RSAPSSSignature.java ! src/java.base/share/classes/sun/security/ssl/SSLTransport.java ! src/java.base/share/classes/sun/security/util/CurveDB.java ! src/jdk.crypto.mscapi/windows/classes/sun/security/mscapi/CSignature.java Changeset: 2cc1977a Author: Jie Fu Date: 2021-06-09 02:22:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2cc1977a9698af9538101a5842c311659521a0aa 8268424: JFR tests fail due to GC cause 'G1 Preventive Collection' not in the valid causes after JDK-8257774 Reviewed-by: dholmes ! test/jdk/jdk/jfr/event/gc/collection/TestGCCauseWithG1ConcurrentMark.java ! test/jdk/jdk/jfr/event/gc/collection/TestGCCauseWithG1FullCollection.java Changeset: c9dbc4f0 Author: Thomas Stuefe Date: 2021-06-09 04:05:46 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c9dbc4f034c765627a2f2f80bb184746be1f2657 8266891: Provide a switch to force the class space to a specific location Reviewed-by: iklam, coleenp ! src/hotspot/share/memory/metaspace.cpp ! src/hotspot/share/runtime/globals.hpp Changeset: 07108c91 Author: Serguei Spitsyn Date: 2021-06-09 05:38:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/07108c916263896fa6c5dbacfedf5b4c2f5bf97a 8268241: deprecate JVM TI Heap functions 1.0 Reviewed-by: alanb, iris, kevinw ! src/hotspot/share/prims/jvmti.xml Changeset: 4d1cf51b Author: Athijegannathan Sundararajan Date: 2021-06-09 06:35:20 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4d1cf51b1d4a5e812c9f78b0104e40fbc4883a6c 8240349: jlink should not leave partial image output directory on failure Reviewed-by: jlaskey, alanb ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImageFileCreator.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/TaskHelper.java ! test/jdk/tools/jlink/JLinkNegativeTest.java ! test/jdk/tools/jlink/JLinkTest.java Changeset: 2bfd708e Author: Robbin Ehn Date: 2021-06-09 07:21:37 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2bfd708e9276bd9a6d4cf493e1af3a8e5b8026d2 8266557: assert(SafepointMechanism::local_poll_armed(_handshakee)) failed: Must be Reviewed-by: pchilanomate, dcubed ! src/hotspot/share/runtime/handshake.cpp ! src/hotspot/share/runtime/handshake.hpp ! src/hotspot/share/runtime/safepointMechanism.cpp ! src/hotspot/share/utilities/filterQueue.hpp ! src/hotspot/share/utilities/filterQueue.inline.hpp ! test/hotspot/gtest/utilities/test_filterQueue.cpp Changeset: 4413142e Author: Roland Westrelin Date: 2021-06-09 07:58:17 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4413142eca1712f9a78c5683083eb01908397bb0 8268017: C2: assert(phi_type->isa_int() || phi_type->isa_ptr() || phi_type->isa_long()) failed: bad phi type Reviewed-by: vlivanov, chagedorn, whuang ! src/hotspot/share/opto/castnode.cpp ! src/hotspot/share/opto/castnode.hpp ! src/hotspot/share/opto/cfgnode.cpp ! src/hotspot/share/opto/loopopts.cpp + test/hotspot/jtreg/compiler/loopopts/TestCastFFAtPhi.java Changeset: 9cfd560b Author: Eric Liu Committer: Pengfei Li Date: 2021-06-09 09:30:09 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9cfd560bb113b630e0ca28f9204afc079a87017b 8267663: [vector] Add unsigned comparison operators on AArch64 Reviewed-by: aph ! src/hotspot/cpu/aarch64/aarch64_neon.ad ! src/hotspot/cpu/aarch64/aarch64_neon_ad.m4 ! src/hotspot/cpu/aarch64/assembler_aarch64.cpp ! src/hotspot/cpu/aarch64/assembler_aarch64.hpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp ! src/hotspot/cpu/aarch64/matcher_aarch64.hpp ! test/hotspot/gtest/aarch64/aarch64-asmtest.py ! test/hotspot/gtest/aarch64/asmtest.out.h Changeset: 43889590 Author: Patrick Concannon Date: 2021-06-09 10:13:25 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/438895903b1de71b88951a4117c240baf410fd5d 8268056: Update java.net and java.nio to use switch expressions Reviewed-by: dfuchs, michaelm, chegar, iris, alanb ! src/java.base/share/classes/java/net/SocksSocketImpl.java ! src/java.base/share/classes/java/nio/file/Files.java Changeset: dd34a4c2 Author: Albert Mingkun Yang Date: 2021-06-09 10:37:33 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/dd34a4c28da73c798e021c7473ac57ead56c9903 8268372: ZGC: dynamically select the number of concurrent GC threads used Co-authored-by: Per Liden Reviewed-by: pliden, eosterlund ! src/hotspot/share/gc/z/zArguments.cpp ! src/hotspot/share/gc/z/zCollectedHeap.cpp ! src/hotspot/share/gc/z/zCollectedHeap.hpp ! src/hotspot/share/gc/z/zDirector.cpp ! src/hotspot/share/gc/z/zDirector.hpp ! src/hotspot/share/gc/z/zDriver.cpp ! src/hotspot/share/gc/z/zDriver.hpp ! src/hotspot/share/gc/z/zHeap.cpp ! src/hotspot/share/gc/z/zHeap.hpp ! src/hotspot/share/gc/z/zHeap.inline.hpp ! src/hotspot/share/gc/z/zHeuristics.cpp ! src/hotspot/share/gc/z/zMark.cpp ! src/hotspot/share/gc/z/zMessagePort.hpp ! src/hotspot/share/gc/z/zMessagePort.inline.hpp ! src/hotspot/share/gc/z/zNMethod.cpp ! src/hotspot/share/gc/z/zPageAllocator.cpp ! src/hotspot/share/gc/z/zPageAllocator.hpp ! src/hotspot/share/gc/z/zReferenceProcessor.cpp ! src/hotspot/share/gc/z/zRelocate.cpp ! src/hotspot/share/gc/z/zRelocationSet.cpp ! src/hotspot/share/gc/z/zRuntimeWorkers.cpp ! src/hotspot/share/gc/z/zRuntimeWorkers.hpp ! src/hotspot/share/gc/z/zStat.cpp ! src/hotspot/share/gc/z/zStat.hpp ! src/hotspot/share/gc/z/zValue.inline.hpp ! src/hotspot/share/gc/z/zWeakRootsProcessor.cpp ! src/hotspot/share/gc/z/zWorkers.cpp ! src/hotspot/share/gc/z/zWorkers.hpp - src/hotspot/share/gc/z/zWorkers.inline.hpp Changeset: 13d61804 Author: Roger Riggs Date: 2021-06-09 12:30:07 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/13d618042112aa761ef256aa35ec0a8b808cd78b 8264859: Implement Context-Specific Deserialization Filters Reviewed-by: bchristi, dfuchs, chegar ! src/java.base/share/classes/java/io/ObjectInputFilter.java ! src/java.base/share/classes/java/io/ObjectInputStream.java ! src/java.base/share/classes/jdk/internal/util/StaticProperty.java ! src/java.base/share/conf/security/java.security + test/jdk/java/io/Serializable/serialFilter/SerialFactoryExample.java + test/jdk/java/io/Serializable/serialFilter/SerialFilterFactoryTest.java + test/jdk/java/io/Serializable/serialFilter/SerialFilterFunctionTest.java ! test/jdk/java/io/Serializable/serialFilter/SerialFilterTest.java + test/jdk/java/io/Serializable/serialFilter/java.security-extra-factory Changeset: 7b1e4024 Author: Rafael Winterhalter Committer: Joel Borggr?n-Franck Date: 2021-06-09 13:21:32 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7b1e4024c02e6e831502e20cdbf54efb6240d12b 8266598: Exception values for AnnotationTypeMismatchException are not always informative Reviewed-by: jfranck ! src/java.base/share/classes/sun/reflect/annotation/AnnotationParser.java ! test/jdk/java/lang/annotation/AnnotationTypeMismatchException/AnnotationTypeMismatchTest.java ! test/jdk/java/lang/annotation/AnnotationTypeMismatchException/EnumTypeMismatchTest.java Changeset: 5fbb62c7 Author: Stefan Johansson Date: 2021-06-09 13:43:48 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5fbb62c74186417eaeff808ea070b35e5e95267a 8268163: Change the order of fallback full GCs in G1 Reviewed-by: kbarrett, tschatzl ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1CollectedHeap.hpp ! src/hotspot/share/gc/g1/g1VMOperations.cpp Changeset: 43e38a18 Author: Matthias Baesken Date: 2021-06-09 14:09:41 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/43e38a18b83a69242d1991f435d23d8799f06fe6 8268377: Windows 32bit build fails after JDK-8268174 Reviewed-by: jiefu, mdoerr ! src/hotspot/os/windows/os_windows.cpp ! src/hotspot/os_cpu/windows_x86/os_windows_x86.cpp Changeset: caf7f498 Author: Stefan Johansson Date: 2021-06-09 14:31:15 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/caf7f49887db3ea26ee302f37941f196b3a76f3f 8268122: Add specific gc cause for G1 full collections Reviewed-by: tschatzl, kbarrett ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/shared/gcCause.cpp ! src/hotspot/share/gc/shared/gcCause.hpp ! test/jdk/jdk/jfr/event/gc/collection/TestGCCauseWithG1ConcurrentMark.java ! test/jdk/jdk/jfr/event/gc/collection/TestGCCauseWithG1FullCollection.java Changeset: 81fdeb57 Author: Vladimir Kozlov Date: 2021-06-09 15:15:15 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/81fdeb579adffa45c3adcc28732c69f396d732ce 8268417: Add test from JDK-8268360 Reviewed-by: roland, chagedorn + test/hotspot/jtreg/compiler/loopopts/TestInfLoopNearUsePlacement.java Changeset: bb3d226a Author: Vicente Romero Date: 2021-06-09 15:56:55 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bb3d226a4eedb3d3ef73ef91683f45f1db43a74e 8238213: Method resolution should stop on static error Reviewed-by: jlahoda ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java + test/langtools/tools/javac/static_error/ShouldStopOnStaticError.java + test/langtools/tools/javac/static_error/ShouldStopOnStaticError.out Changeset: db45ff09 Author: Tom Rodriguez Date: 2021-06-09 17:34:17 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/db45ff09acbf4f2d824c5c23093d46c048427368 8268052: [JVMCI] non-default installed code must be marked as in_use Reviewed-by: kvn, dnsimon ! src/hotspot/share/jvmci/jvmci.hpp ! src/hotspot/share/jvmci/jvmciCodeInstaller.cpp ! src/hotspot/share/jvmci/jvmciCodeInstaller.hpp ! src/hotspot/share/jvmci/jvmciCompilerToVM.cpp ! src/hotspot/share/jvmci/jvmciRuntime.cpp ! src/hotspot/share/jvmci/jvmciRuntime.hpp ! src/hotspot/share/jvmci/vmStructs_jvmci.cpp ! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotCodeCacheProvider.java ! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotVMConfig.java Changeset: 79010f22 Author: Jorn Vernee Date: 2021-06-09 18:15:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/79010f2254aee8459523800d6049f396b055f123 8266835: Add a --validate option to the jar tool Reviewed-by: lancea ! src/jdk.jartool/share/classes/sun/tools/jar/GNUStyleOptions.java ! 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/multiRelease/ApiValidatorTest.java Changeset: 33d34c6b Author: Chris Plummer Date: 2021-06-09 19:03:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/33d34c6b670e83778479a2a11ae23229bf959752 8263323: Debug Agent help output includes invalid URL Reviewed-by: kevinw, alanb ! src/jdk.jdwp.agent/share/native/libjdwp/debugInit.c Changeset: bbd0313a Author: Chris Plummer Date: 2021-06-09 19:04:11 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bbd0313ac12c062f02400342a87c283b7578062a 8263203: jconsole Online User Guide has wrong URL Reviewed-by: mchung, dholmes ! src/jdk.jconsole/share/classes/sun/tools/jconsole/resources/messages.properties ! src/jdk.jconsole/share/classes/sun/tools/jconsole/resources/messages_ja.properties ! src/jdk.jconsole/share/classes/sun/tools/jconsole/resources/messages_zh_CN.properties Changeset: 408e0a9c Author: Evan Whelan Committer: Sean Mullan Date: 2021-06-09 20:38:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/408e0a9c696888d41809e35bf252869f09f735db 8255148: Confusing log output: SSLSocket duplex close failed Reviewed-by: mullan ! src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java + test/jdk/sun/security/ssl/SSLSocketImpl/IgnorableExceptionMessages.java Changeset: bf29a011 Author: Kevin Walls Date: 2021-06-09 20:45:44 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bf29a0115cc67ed2926b135b6b6ade5ff5ee84f6 8228343: JCMD and attach fail to work across Linux Container boundary Reviewed-by: ysuenaga, sspitsyn ! src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java ! src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java Changeset: 991ca142 Author: Phil Race Date: 2021-06-09 20:52:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/991ca14279faa7db5d0afe023e666844f5b3b75b 8267430: GraphicsDevice.setDisplayMode(REFRESH_RATE_UNKNOWN) throws IAE: Unable to set display mode! Reviewed-by: serb ! src/java.desktop/macosx/classes/sun/awt/CGraphicsDevice.java ! src/java.desktop/macosx/native/libawt_lwawt/awt/CGraphicsDevice.m + test/jdk/java/awt/GraphicsDevice/DisplayModes/UnknownRefrshRateTest.java Changeset: 7ff6e7b2 Author: Yumin Qi Date: 2021-06-09 21:33:28 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7ff6e7b2b1be088c37f50756b6822be01b4c657d 8267954: Shared classes that failed to load should not be loaded again Reviewed-by: iklam, ccheung ! src/hotspot/share/classfile/systemDictionary.cpp ! src/hotspot/share/classfile/systemDictionary.hpp ! src/hotspot/share/classfile/systemDictionaryShared.cpp ! src/hotspot/share/classfile/systemDictionaryShared.hpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/instanceKlass.hpp ! test/hotspot/jtreg/ProblemList-Xcomp.txt Changeset: b41f3f8e Author: Tom Rodriguez Date: 2021-06-09 23:04:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b41f3f8ed512117fc3677f2c5e9ee5d28116bfeb 8268478: JVMCI tests failing after JDK-8268052 Reviewed-by: kvn, eosterlund ! src/hotspot/share/jvmci/jvmciRuntime.cpp Changeset: 58ba48b7 Author: Dan Smith Date: 2021-06-09 23:57:41 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/58ba48b7b88eff359683aa3271c48b18f1973282 8268192: LambdaMetafactory with invokespecial causes VerificationError Reviewed-by: psandoz, mchung ! src/java.base/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java ! src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java ! test/jdk/java/lang/invoke/lambda/MetafactoryArgValidationTest.java Changeset: f839308e Author: Chris Plummer Date: 2021-06-10 02:49:58 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f839308efac0f5d8cb7cce165695ef24041fd621 8268407: ProblemList sun/tools/jstat/jstatLineCountsX.sh on linux-aarch64 due to JDK-8268211 Reviewed-by: amenkov ! test/jdk/ProblemList.txt Changeset: 2623b0bf Author: Igor Ignatyev Date: 2021-06-10 03:18:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2623b0bf3954df43504ca531cb2ab33b2363929a 8268475: execute runtime/InvocationTests w/ -UseVtableBasedCHA Reviewed-by: mseledtsov, kvn = test/hotspot/jtreg/runtime/InvocationTests/invocationOldCHATests.java Changeset: ece3ae3c Author: Stefan Johansson Date: 2021-06-10 05:32:56 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ece3ae3cc4cc1d45b65253a9bfafdefe2656afb8 8268388: Update large pages information in Java manpage Reviewed-by: tschatzl, lkorinth, stuefe ! src/java.base/share/man/java.1 Changeset: dd1cbadc Author: Serguei Spitsyn Date: 2021-06-10 06:03:19 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/dd1cbadc82bcecf718b96c833a5845fde79db061 8268285: vmTestbase/nsk/jvmti/GetThreadState/thrstat002 failed with "Wrong thread "thr1" (...) state after SuspendThread" Reviewed-by: lmesnik, amenkov, dholmes ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetThreadState/thrstat002.java ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetThreadState/thrstat002/thrstat002.cpp Changeset: d4377afb Author: Roland Westrelin Date: 2021-06-10 06:56:04 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d4377afb999f4f03d384ded97771c83ea1c1f513 8263303: C2 compilation fails with assert(found_sfpt) failed: no node in loop that's not input to safepoint Reviewed-by: chagedorn, kvn ! src/hotspot/share/opto/loopnode.cpp ! src/hotspot/share/opto/loopopts.cpp + test/hotspot/jtreg/compiler/loopstripmining/TestPinnedUseInOuterLSMUnusedBySfpt.java Changeset: 5a666282 Author: Kim Barrett Date: 2021-06-10 07:27:53 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5a666282a9e5b5748d85f4c012b36e5c8f7eab56 8263107: PSPromotionManager::copy_and_push_safe_barrier needs acquire memory barrier Reviewed-by: iwalulya, tschatzl, mdoerr ! src/hotspot/share/gc/parallel/psClosure.inline.hpp ! src/hotspot/share/gc/parallel/psPromotionManager.hpp ! src/hotspot/share/gc/parallel/psPromotionManager.inline.hpp ! src/hotspot/share/gc/parallel/psScavenge.hpp ! src/hotspot/share/oops/oop.hpp ! src/hotspot/share/oops/oop.inline.hpp Changeset: 78b09ab0 Author: Matthias Baesken Date: 2021-06-10 08:08:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/78b09ab04929871605abba3026ce9833c6e75789 8268463: Windows 32bit build fails in DynamicCodeGenerated\libDynamicCodeGenerated.cpp Reviewed-by: sspitsyn, cjplummer ! test/hotspot/jtreg/serviceability/jvmti/DynamicCodeGenerated/libDynamicCodeGenerated.cpp Changeset: 1fd81464 Author: Christoph G?ttschkes Committer: Jie Fu Date: 2021-06-10 08:27:54 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1fd81464ec0054f7843fba3490b7f33955717077 8268461: ARM32: vector intrinsics reaches ShouldNotReachHere Reviewed-by: jiefu, njian ! src/hotspot/cpu/arm/arm.ad Changeset: ab01cb54 Author: Jorn Vernee Date: 2021-06-10 08:44:28 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ab01cb547dd87f76017e9b079ab68495c38ffc90 8268339: Upstream: 8267989: Exceptions thrown during upcalls should be handled Reviewed-by: psandoz, mcimadamore ! src/java.base/share/classes/java/lang/System.java ! src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java ! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/CABI.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/ProgrammableUpcallHandler.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/SharedUtils.java + test/jdk/java/foreign/TestUpcallException.java + test/jdk/java/foreign/ThrowingUpcall.java Changeset: f271eb8b Author: Markus Gr?nlund Date: 2021-06-10 08:58:03 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f271eb8b846692bb45f069cd39ff107231c2812d 8268303: Incorrect casts in JfrWriterHost::write for Ticks and Tickspan Reviewed-by: egahlin ! src/hotspot/share/jfr/writers/jfrWriterHost.inline.hpp Changeset: ea19b044 Author: Sergey Bylokhov Date: 2021-06-10 09:08:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ea19b0447cf1ec97c0b0a817542ce7ead4f53176 8268481: Delete JAWT test files for mac Reviewed-by: prr, pbansal - test/jdk/java/awt/JAWT/MyMacCanvas.java - test/jdk/java/awt/JAWT/jawt-mac-buildrun.sh - test/jdk/java/awt/JAWT/myfile.m Changeset: ae29f9ca Author: Igor Ignatyev Date: 2021-06-10 09:42:26 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ae29f9cacdac8bfe7fc1d287edbfb21c81686d4c 8268530: resourcehogs/serviceability/jvmti/GetObjectSizeOverflow.java should be run in driver mode Reviewed-by: sspitsyn ! test/hotspot/jtreg/resourcehogs/serviceability/jvmti/GetObjectSizeOverflow.java Changeset: 05090fc8 Author: Igor Ignatyev Date: 2021-06-10 09:48:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/05090fc8fdef3c02c91cbd79e661f763893580c2 8268536: mark hotspot serviceability/dcmd tests which ignore external VM flags Reviewed-by: sspitsyn ! test/hotspot/jtreg/serviceability/dcmd/compiler/CodeHeapAnalyticsParams.java ! test/hotspot/jtreg/serviceability/dcmd/gc/RunFinalizationTest.java Changeset: 964118f7 Author: Igor Ignatyev Date: 2021-06-10 09:49:23 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/964118f7fd49786cfe60e1144800a02afc0fdb56 8268538: mark hotspot serviceability/logging tests which ignore external VM flags Reviewed-by: sspitsyn ! test/hotspot/jtreg/serviceability/logging/TestBasicLogOutput.java ! test/hotspot/jtreg/serviceability/logging/TestDefaultLogOutput.java ! test/hotspot/jtreg/serviceability/logging/TestFullNames.java ! test/hotspot/jtreg/serviceability/logging/TestMultipleXlogArgs.java ! test/hotspot/jtreg/serviceability/logging/TestQuotedLogOutputs.java Changeset: 92f0b6d4 Author: Igor Ignatyev Date: 2021-06-10 09:51:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/92f0b6d49e5a4dbdd6c95b8d526187adb33aa827 8268532: several serviceability/attach tests should be run in driver mode Reviewed-by: sspitsyn ! test/hotspot/jtreg/serviceability/attach/AttachNegativePidTest.java ! test/hotspot/jtreg/serviceability/attach/AttachSetGetFlag.java ! test/hotspot/jtreg/serviceability/attach/AttachWithStalePidFile.java ! test/hotspot/jtreg/serviceability/attach/RemovingUnixDomainSocketTest.java Changeset: e0c0b139 Author: Igor Ignatyev Date: 2021-06-10 09:52:07 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e0c0b139d335cd818468db115dd18f1cedf21675 8268534: some serviceability/jvmti tests should be run in driver mode Reviewed-by: sspitsyn ! test/hotspot/jtreg/serviceability/jvmti/GetObjectSizeClass.java ! test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineLeak.java ! test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/TestLambdaFormRetransformation.java ! test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/TestRedefineWithUnresolvedClass.java Changeset: f770f771 Author: Stefan Johansson Date: 2021-06-10 10:21:13 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f770f771f86db7d4878b71137cd5a72c7c40cb2e 8268390: G1 concurrent gc upgrade to full gc not working Reviewed-by: kbarrett, tschatzl ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1CollectedHeap.hpp ! src/hotspot/share/gc/g1/g1VMOperations.cpp Changeset: a187fcc3 Author: Markus Gr?nlund Date: 2021-06-10 10:26:49 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a187fcc3ec1ca360ad1d7d1f78bf5ccd9d1c2b7b 8238197: JFR: Rework setting and getting EventHandler Reviewed-by: egahlin, jbachorik ! src/hotspot/share/jfr/jni/jfrJavaSupport.cpp ! src/jdk.jfr/share/classes/jdk/jfr/internal/Utils.java Changeset: d43c8a74 Author: Patrick Concannon Date: 2021-06-10 11:12:37 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d43c8a74b33692b3628c3c9c6c472ab1cf1fdeac 8268124: Update java.lang to use switch expressions Reviewed-by: naoto, darcy, mchung, iris, lancea, dfuchs ! src/java.base/share/classes/java/lang/CharacterData.java ! src/java.base/share/classes/java/lang/ConditionalSpecialCasing.java ! src/java.base/share/classes/java/lang/Long.java ! src/java.base/share/classes/java/lang/Math.java ! src/java.base/share/classes/java/lang/constant/DirectMethodHandleDescImpl.java ! src/java.base/share/classes/java/lang/constant/MethodHandleDesc.java ! src/java.base/share/classes/java/lang/invoke/BoundMethodHandle.java ! src/java.base/share/classes/java/lang/invoke/ClassSpecializer.java ! src/java.base/share/classes/java/lang/invoke/DelegatingMethodHandle.java ! src/java.base/share/classes/java/lang/invoke/DirectMethodHandle.java ! src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java ! src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java ! src/java.base/share/classes/java/lang/invoke/Invokers.java ! src/java.base/share/classes/java/lang/invoke/LambdaForm.java ! src/java.base/share/classes/java/lang/invoke/MemberName.java ! src/java.base/share/classes/java/lang/invoke/MethodHandle.java ! src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/java.base/share/classes/java/lang/invoke/MethodHandleNatives.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/lang/invoke/VarHandle.java ! src/java.base/share/classes/java/lang/runtime/ObjectMethods.java Changeset: 09243822 Author: Rafael Winterhalter Committer: Joel Borggr?n-Franck Date: 2021-06-10 12:02:53 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/09243822ebcca611b04f94ece5afba183723cf74 8266766: Arrays of types that cannot be an annotation member do not yield exceptions Reviewed-by: darcy, jfranck ! src/java.base/share/classes/sun/reflect/annotation/AnnotationParser.java + test/jdk/java/lang/annotation/AnnotationTypeMismatchException/ArrayTypeMismatchTest.java Changeset: 6b6ff536 Author: Igor Ignatyev Date: 2021-06-10 12:29:44 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6b6ff5360a2813354735ef9eda6729c853696702 8268543: some runtime/verifier tests should be run in driver mode Reviewed-by: hseigel ! test/hotspot/jtreg/runtime/verifier/OverriderMsg.java ! test/hotspot/jtreg/runtime/verifier/TestANewArray.java ! test/hotspot/jtreg/runtime/verifier/TestMultiANewArray.java Changeset: f4b31701 Author: Maurizio Cimadamore Date: 2021-06-10 12:52:04 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f4b3170197ca517b4816f863af053f019ce0f181 8268428: Test java/foreign/TestResourceScope.java fails: expected [M] but found [N] Reviewed-by: dfuchs ! test/jdk/java/foreign/TestResourceScope.java Changeset: 6c552a7b Author: Igor Ignatyev Date: 2021-06-10 13:03:29 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6c552a7b42e73174343280d46bd72d730c42b5c5 8268544: some runtime/sealedClasses tests should be run in driver mode Reviewed-by: hseigel ! test/hotspot/jtreg/runtime/sealedClasses/RedefinePermittedSubclass.java ! test/hotspot/jtreg/runtime/sealedClasses/RedefineSealedClass.java Changeset: f677163b Author: Daniel D. Daugherty Date: 2021-06-10 13:09:26 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f677163b8aad13781be51839f27742c2213896d1 8266130: convert Thread-SMR stress tests from counter based to time based Reviewed-by: cjplummer, dholmes ! test/hotspot/jtreg/ProblemList.txt ! test/hotspot/jtreg/runtime/Thread/InterruptAtExit.java ! test/hotspot/jtreg/runtime/Thread/IsInterruptedAtExit.java - test/hotspot/jtreg/runtime/Thread/ResumeAtExit.java ! test/hotspot/jtreg/runtime/Thread/SetNameAtExit.java ! test/hotspot/jtreg/runtime/Thread/SetPriorityAtExit.java ! test/hotspot/jtreg/runtime/Thread/StopAtExit.java ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage006.java ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage006/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/InterruptThread/intrpthrd003.java ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/InterruptThread/intrpthrd003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/InterruptThread/intrpthrd003/intrpthrd003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/PopFrame/popframe011.java ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/PopFrame/popframe011/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SuspendThread/suspendthrd003.java ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SuspendThread/suspendthrd003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SuspendThread/suspendthrd003/suspendthrd003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/monitoring/ThreadInfo/isSuspended/issuspended002.java ! test/hotspot/jtreg/vmTestbase/nsk/monitoring/ThreadInfo/isSuspended/issuspended002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/monitoring/ThreadMXBean/findMonitorDeadlockedThreads/find006.java ! test/hotspot/jtreg/vmTestbase/nsk/monitoring/ThreadMXBean/findMonitorDeadlockedThreads/find006/TestDescription.java Changeset: f716711c Author: Erik Gahlin Date: 2021-06-10 13:18:54 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f716711c7b5f442653fcd5402bb9ad9fa8a6501b 8265271: JFR: Allow use of .jfc options when starting JFR Reviewed-by: mgronlun ! src/hotspot/share/jfr/dcmd/jfrDcmds.cpp ! src/hotspot/share/jfr/dcmd/jfrDcmds.hpp ! src/hotspot/share/jfr/jni/jfrJavaSupport.cpp ! src/hotspot/share/jfr/jni/jfrJavaSupport.hpp ! src/hotspot/share/jfr/utilities/jfrLogTagSets.hpp ! src/java.base/share/man/java.1 ! src/jdk.jcmd/share/man/jcmd.1 ! src/jdk.jfr/share/classes/jdk/jfr/internal/LogTag.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/dcmd/AbstractDCmd.java + src/jdk.jfr/share/classes/jdk/jfr/internal/dcmd/Argument.java + src/jdk.jfr/share/classes/jdk/jfr/internal/dcmd/ArgumentParser.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/dcmd/DCmdCheck.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/dcmd/DCmdConfigure.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/dcmd/DCmdDump.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/dcmd/DCmdStart.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/dcmd/DCmdStop.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/jfc/JFC.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/jfc/model/JFCModel.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/tool/Configure.java ! test/jdk/jdk/jfr/startupargs/TestBadOptionValues.java + test/jdk/jdk/jfr/startupargs/TestEventSettings.java + test/jdk/jdk/jfr/startupargs/TestJFCWarnings.java Changeset: 7cd5a6e7 Author: Leo Korinth Date: 2021-06-10 13:19:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7cd5a6e7b52687e80b1aad9f550c2637f501c414 8268537: (Temporary) Disable ParallelRefProcEnabled for Parallel GC Reviewed-by: stefank, sjohanss ! src/hotspot/share/gc/parallel/parallelArguments.cpp ! test/hotspot/jtreg/gc/arguments/TestParallelRefProc.java Changeset: 2b41459e Author: Thomas Schatzl Date: 2021-06-10 13:28:55 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2b41459e95e8d6c4ea4c25e8f1d851907d65ef73 8267073: Race between Card Redirtying and Freeing Collection Set regions results in missing remembered set entries with G1 Reviewed-by: kbarrett, sjohanss ! 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/g1EvacFailure.cpp ! src/hotspot/share/gc/g1/g1ParScanThreadState.cpp ! src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.cpp ! src/hotspot/share/gc/g1/heapRegion.cpp ! src/hotspot/share/gc/g1/heapRegion.hpp ! src/hotspot/share/gc/g1/heapRegion.inline.hpp Changeset: e11f70ae Author: Erik Gahlin Date: 2021-06-10 14:10:51 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e11f70aeb6a38ad05f7035461a6094320b03fc40 8003216: Add JFR event indicating explicit System.gc() call Reviewed-by: jbachorik, mgronlun, tschatzl ! src/hotspot/share/jfr/metadata/metadata.xml ! src/hotspot/share/prims/jvm.cpp ! src/jdk.jfr/share/conf/jfr/default.jfc ! src/jdk.jfr/share/conf/jfr/profile.jfc + test/jdk/jdk/jfr/event/gc/collection/TestSystemGc.java ! test/lib/jdk/test/lib/jfr/EventNames.java Changeset: 0a6c7d8a Author: Igor Veresov Date: 2021-06-10 14:18:04 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0a6c7d8a4b6560d3917b9faf66ccf5fc15a891db 8267424: CTW: C1 fails with "State must not be null" Reviewed-by: kvn, roland ! src/hotspot/share/c1/c1_GraphBuilder.cpp Changeset: a95e64cc Author: Albert Mingkun Yang Date: 2021-06-10 14:32:46 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a95e64ccc1ebe74e8b4b8e0729183ee6c4e772ac 8268443: ParallelGC Full GC should use parallel WeakProcessor Co-authored-by: Kim Barrett Reviewed-by: kbarrett, sjohanss, tschatzl ! src/hotspot/share/gc/parallel/psParallelCompact.cpp Changeset: 74007890 Author: Igor Ignatyev Date: 2021-06-10 14:43:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/74007890bb9a3fa3a65683a3f480e399f2b1a0b6 8268542: serviceability/logging/TestFullNames.java tests only 1st test case Reviewed-by: sspitsyn ! test/hotspot/jtreg/serviceability/logging/TestFullNames.java Changeset: b018c450 Author: Joe Darcy Date: 2021-06-10 16:22:14 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b018c450e5e4737ccd08ed505fd06cee16c42648 8267630: Start of release updates for JDK 18 8267632: Add source 18 and target 18 to javac 8267631: Add SourceVersion.RELEASE_18 Reviewed-by: iris, erikj, dholmes ! make/conf/version-numbers.conf + make/data/symbols/java.base-H.sym.txt + make/data/symbols/java.compiler-H.sym.txt + make/data/symbols/java.datatransfer-H.sym.txt + make/data/symbols/java.desktop-H.sym.txt + make/data/symbols/java.instrument-H.sym.txt + make/data/symbols/java.logging-H.sym.txt + make/data/symbols/java.management-H.sym.txt + make/data/symbols/java.management.rmi-H.sym.txt + make/data/symbols/java.naming-H.sym.txt + make/data/symbols/java.rmi-H.sym.txt + make/data/symbols/java.scripting-H.sym.txt + make/data/symbols/java.security.jgss-H.sym.txt + make/data/symbols/java.security.sasl-H.sym.txt + make/data/symbols/java.smartcardio-H.sym.txt + make/data/symbols/java.sql-H.sym.txt + make/data/symbols/java.sql.rowset-H.sym.txt + make/data/symbols/java.xml-H.sym.txt + make/data/symbols/java.xml.crypto-H.sym.txt + make/data/symbols/jdk.accessibility-H.sym.txt + make/data/symbols/jdk.attach-H.sym.txt + make/data/symbols/jdk.compiler-H.sym.txt + make/data/symbols/jdk.dynalink-H.sym.txt + make/data/symbols/jdk.httpserver-H.sym.txt + make/data/symbols/jdk.incubator.foreign-H.sym.txt + make/data/symbols/jdk.jartool-H.sym.txt + make/data/symbols/jdk.javadoc-H.sym.txt + make/data/symbols/jdk.jconsole-H.sym.txt + make/data/symbols/jdk.jdi-H.sym.txt + make/data/symbols/jdk.jshell-H.sym.txt + make/data/symbols/jdk.jsobject-H.sym.txt + make/data/symbols/jdk.management-H.sym.txt + make/data/symbols/jdk.net-H.sym.txt + make/data/symbols/jdk.sctp-H.sym.txt + make/data/symbols/jdk.security.auth-H.sym.txt + make/data/symbols/jdk.security.jgss-H.sym.txt + make/data/symbols/jdk.unsupported-H.sym.txt + make/data/symbols/jdk.xml.dom-H.sym.txt ! make/data/symbols/symbols ! src/hotspot/share/classfile/classFileParser.cpp ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/ClassReader.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/Opcodes.java ! src/java.compiler/share/classes/javax/lang/model/SourceVersion.java ! src/java.compiler/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor14.java ! src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor14.java ! src/java.compiler/share/classes/javax/lang/model/util/AbstractTypeVisitor14.java ! src/java.compiler/share/classes/javax/lang/model/util/ElementKindVisitor14.java ! src/java.compiler/share/classes/javax/lang/model/util/ElementScanner14.java ! src/java.compiler/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitor14.java ! src/java.compiler/share/classes/javax/lang/model/util/SimpleElementVisitor14.java ! src/java.compiler/share/classes/javax/lang/model/util/SimpleTypeVisitor14.java ! src/java.compiler/share/classes/javax/lang/model/util/TypeKindVisitor14.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassFile.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Target.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/processing/PrintingProcessor.java ! test/jdk/java/lang/module/ClassFileVersionsTest.java ! test/langtools/tools/javac/api/TestGetSourceVersions.java ! test/langtools/tools/javac/classfiles/ClassVersionChecker.java ! test/langtools/tools/javac/lib/JavacTestingAbstractProcessor.java ! test/langtools/tools/javac/preview/classReaderTest/Client.nopreview.out ! test/langtools/tools/javac/preview/classReaderTest/Client.preview.out ! test/langtools/tools/javac/versions/Versions.java Changeset: 72672277 Author: UncleNine Committer: Severin Gehwolf Date: 2021-06-10 16:40:29 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/72672277e4dddf8e72f1c705cd5f57de40745635 8268361: Fix the infinite loop in next_line Reviewed-by: dholmes, sgehwolf, sspitsyn ! src/jdk.management/linux/native/libmanagement_ext/UnixOperatingSystem.c Changeset: 78cb6776 Author: Igor Ignatyev Date: 2021-06-10 17:06:19 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/78cb6776b6d43b67457993a109719b36ee892d60 8268539: several serviceability/sa tests should be run in driver mode Reviewed-by: sspitsyn ! test/hotspot/jtreg/serviceability/sa/CDSJMapClstats.java ! test/hotspot/jtreg/serviceability/sa/ClhsdbDumpclass.java ! test/hotspot/jtreg/serviceability/sa/ClhsdbFlags.java ! test/hotspot/jtreg/serviceability/sa/ClhsdbJstackXcompStress.java ! test/hotspot/jtreg/serviceability/sa/DeadlockDetectionTest.java ! test/hotspot/jtreg/serviceability/sa/JhsdbThreadInfoTest.java ! test/hotspot/jtreg/serviceability/sa/TestCpoolForInvokeDynamic.java ! test/hotspot/jtreg/serviceability/sa/TestDefaultMethods.java ! test/hotspot/jtreg/serviceability/sa/TestHeapDumpForInvokeDynamic.java ! test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackLineNumbers.java ! test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackLock.java ! test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackMixed.java ! test/hotspot/jtreg/serviceability/sa/TestObjectMonitorIterate.java ! test/hotspot/jtreg/serviceability/sa/TestRevPtrsForInvokeDynamic.java ! test/hotspot/jtreg/serviceability/sa/TestSysProps.java ! test/hotspot/jtreg/serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java ! test/hotspot/jtreg/serviceability/sa/sadebugd/ClhsdbAttachToDebugServer.java ! test/hotspot/jtreg/serviceability/sa/sadebugd/ClhsdbTestConnectArgument.java ! test/hotspot/jtreg/serviceability/sa/sadebugd/DebugdConnectTest.java ! test/hotspot/jtreg/serviceability/sa/sadebugd/DisableRegistryTest.java ! test/hotspot/jtreg/serviceability/sa/sadebugd/PmapOnDebugdTest.java ! test/hotspot/jtreg/serviceability/sa/sadebugd/RunCommandOnServerTest.java ! test/hotspot/jtreg/serviceability/sa/sadebugd/SADebugDTest.java Changeset: 1e1039a7 Author: Leonid Mesnik Date: 2021-06-10 17:41:11 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1e1039a7c8bbd745cb23fd91e548dc20ac7d1d9d 8268223: Problemlist vmTestbase/nsk/jdi/HiddenClass/events/events001.java Reviewed-by: amenkov, sspitsyn ! test/hotspot/jtreg/ProblemList.txt Changeset: 8c8422e0 Author: Leonid Mesnik Date: 2021-06-10 17:45:53 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8c8422e0f8886d9bbfca29fd228368f88bf46f2c 8267893: Improve jtreg test failure handler do get native/mixed stack traces for cores and live processes Reviewed-by: iignatyev ! test/failure_handler/Makefile ! test/failure_handler/README + test/failure_handler/src/share/classes/jdk/test/failurehandler/CoreInfoGatherer.java ! test/failure_handler/src/share/classes/jdk/test/failurehandler/GathererFactory.java ! test/failure_handler/src/share/classes/jdk/test/failurehandler/ToolKit.java ! test/failure_handler/src/share/classes/jdk/test/failurehandler/action/ActionHelper.java ! test/failure_handler/src/share/classes/jdk/test/failurehandler/action/ActionSet.java ! test/failure_handler/src/share/classes/jdk/test/failurehandler/action/PatternAction.java ! test/failure_handler/src/share/classes/jdk/test/failurehandler/jtreg/GatherDiagnosticInfoObserver.java ! test/failure_handler/src/share/conf/common.properties ! test/failure_handler/src/share/conf/linux.properties ! test/failure_handler/src/share/conf/mac.properties Changeset: 4fd2a149 Author: Calvin Cheung Date: 2021-06-10 19:50:44 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4fd2a149977b05eb6e4b28d147ab9c043a7934ec 8267556: Enhance class paths check during runtime Reviewed-by: minqi, iklam ! src/hotspot/share/cds/filemap.cpp ! src/hotspot/share/cds/filemap.hpp ! src/hotspot/share/classfile/classLoader.cpp ! src/hotspot/share/classfile/classLoader.hpp ! src/hotspot/share/classfile/classLoaderExt.cpp ! src/hotspot/share/classfile/classLoaderExt.hpp + test/hotspot/jtreg/runtime/cds/appcds/NonJarInClasspath.java Changeset: 2e900da5 Author: Daniel D. Daugherty Date: 2021-06-10 23:08:56 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2e900da5f70105c153500908c693b2601fa30477 8268574: ProblemList tests failing due to UseBiasedLocking going away Reviewed-by: cjplummer ! test/hotspot/jtreg/ProblemList.txt Changeset: df65237b Author: Hamlin Li Date: 2021-06-11 01:20:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/df65237b9a55aec4374ef63dcc9ab13d3eda8408 8267930: Refine code for loading hsdis library Reviewed-by: whuang, neliasso, ysuenaga ! src/hotspot/share/compiler/disassembler.cpp ! src/hotspot/share/compiler/disassembler.hpp Changeset: 94d0b0f9 Author: Igor Ignatyev Date: 2021-06-11 02:44:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/94d0b0f9810bd1a8da06ec267a1c7589d6cb756b 8268565: runtime/records/RedefineRecord.java should be run in driver mode Reviewed-by: hseigel ! test/hotspot/jtreg/runtime/records/RedefineRecord.java Changeset: 37791a84 Author: duke Date: 2021-06-11 11:01:00 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/37791a84901685edc03a1b49d7b2aca3fe86d45b Automatic merge of jdk:master into master Changeset: 599b146e Author: J. Duke Committer: Jorn Vernee Date: 2021-06-15 18:08:31 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/599b146ee5c679b618d616edc4e855877a12b822 Merge master ! src/hotspot/cpu/aarch64/frame_aarch64.cpp ! src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/SharedUtils.java + src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/aarch64/linux/LinuxAArch64Linker.java ! src/hotspot/cpu/aarch64/frame_aarch64.cpp ! src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/SharedUtils.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/aarch64/linux/LinuxAArch64Linker.java Changeset: 96bd9362 Author: duke Date: 2021-06-15 18:09:46 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/96bd93628806e88a78185e9bb0a5a5db1a4e3ef9 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 Tue Jun 15 18:41:53 2021 From: duke at openjdk.java.net (duke) Date: Tue, 15 Jun 2021 18:41:53 GMT Subject: git: openjdk/panama-foreign: foreign-jextract: 2 new changesets Message-ID: <99cee5c7-cb6b-461b-a37e-8d8aa3df128b@openjdk.org> Changeset: 782aeb49 Author: Jorn Vernee Date: 2021-06-15 18:39:56 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/782aeb49a5114fa64d729b1ad06271d70b82e698 8268230: Foreign Linker API & Windows user32/kernel32: String conversion seems broken Reviewed-by: mcimadamore ! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/SharedUtils.java ! test/jdk/java/foreign/TestNULLAddress.java + test/jdk/java/foreign/TestStringEncoding.java ! test/jdk/java/foreign/handles/lookup_module/handle/lookup/MethodHandleLookup.java Changeset: d79cf934 Author: duke Date: 2021-06-15 18:40:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d79cf934038307bb54e8836bc1f9a68fd3dedf53 Automatic merge of foreign-memaccess+abi into foreign-jextract From jvernee at openjdk.java.net Tue Jun 15 18:42:55 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Tue, 15 Jun 2021 18:42:55 GMT Subject: [foreign-memaccess+abi] Integrated: 8268230: Foreign Linker API & Windows user32/kernel32: String conversion seems broken In-Reply-To: <0ZOia1B8PO-j284cRHT3_oVVMyWqCBUJT4emLo3BxZQ=.7b226aa8-d1c9-4a08-9910-18deb4ef0a24@github.com> References: <0ZOia1B8PO-j284cRHT3_oVVMyWqCBUJT4emLo3BxZQ=.7b226aa8-d1c9-4a08-9910-18deb4ef0a24@github.com> Message-ID: On Thu, 10 Jun 2021 12:03:59 GMT, Jorn Vernee wrote: > The problem is that we only add a single 0 byte as a null terminator, regardless of the charset used. For wider char sets, more 0 bytes need to be added. For instance, for UTF_16LE two 0 bytes need to be added. > > This patch fixes the issue by adding the null terminator to the Java string, and only then encoding it as a `byte[]`. This pull request has now been integrated. Changeset: 782aeb49 Author: Jorn Vernee URL: https://git.openjdk.java.net/panama-foreign/commit/782aeb49a5114fa64d729b1ad06271d70b82e698 Stats: 174 lines in 5 files changed: 65 ins; 99 del; 10 mod 8268230: Foreign Linker API & Windows user32/kernel32: String conversion seems broken Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/554 From leerho at gmail.com Tue Jun 15 19:06:17 2021 From: leerho at gmail.com (leerho) Date: Tue, 15 Jun 2021 12:06:17 -0700 Subject: Memory Segment efficient array handling In-Reply-To: References: <08a001d726ec$f3bd0f30$db372d90$@apache.org> <5d67aba5-e7c8-620c-41ec-0daf396f0d96@oracle.com> <04e101d761c8$67896510$369c2f30$@apache.org> <265ceecd-941a-127b-e2e7-5462f190291c@oracle.com> <06d701d761d1$21bb6f70$65324e50$@apache.org> <7659efda-ed64-093b-c69b-b5af767768c1@oracle.com> <073701d761de$e8317bb0$b8947310$@apache.org> Message-ID: Maurizio, I have updated the *MemoryCopy* and *TestMemoryCopy* to include references to the new *MemorySegment::CopyFrom(...)* and with byte swap capabilities. I have been able to test the code in my local environment using a mock substitute for the new CopyFrom(), but alas, I could not get Jtreg to work, so i am sending you the code as updated in https://github.com/leerho/mcimadamore_panama-foreign Please test it, when you have a chance. Lee. On Tue, Jun 15, 2021 at 5:43 AM Maurizio Cimadamore < maurizio.cimadamore at oracle.com> wrote: > > >> The reason why copying is slower for small segments is that, I think, my > >> benchmark iterations run in 4-5ns and, at these levels, you are > >> sensitive to the cost of the liveness checks. There's not a lot we can > >> do to eliminate that - it's the price of safety. > > OK that's true. But in my own Unsafe.copyMemory code wasn't doing > MemorySegment.address().toRawLongValue() not also doing the liveness check? > True - so the liveness check probably that won't make a lot of > difference in your case. But note that the bound checks are still > applied in MemorySegment::copyMemory. > > > >> The good news is that in the case of heap segment wrappers, we know > >> exactly that the size is gonna fit inside an int (it's an array after > >> all!), so we can remove the check. If we remove the flag check, and just > >> set the segment to always be treated as "SMALL", we get the following > >> results: > > Is this really true? What about a huge long[] array, that could be > (2^31-8 maximum index) * 8 bytesPerLong = 16 gigabytes? (or are those > limited by the Java standard in maximum array size?) > in the PR I've submitted I only tweaked byte segment wrappers. We could > resort to more complex internal representation for other heap segments, > but I believe the true way forward is to wait for the long > optimizations, and to completely remove the SMALL segment hacks. > > > > Sorry, I missed that class. I was opening the pull request and only > looked at the red/green changes in MemorySegment. I missed the first class. > > > > The methods provided there exactly replace my three shapes in the code. > And on top they allow to swap. Side note: MemoryCopy in the current PR has > the swapping code commented out. > Yeah - Lee is working on that MemoryCopy class (and associated test). I > have provided the "swappy" copyFrom overload in MemorySegment, I believe > Lee will add support for that soon. > > > > Last question: why does https://bugs.openjdk.java.net/browse/JDK-8223051 > not help for the integer vs. long loop variables? Does this not allow to > remove the small vs. large segment distinction? I thought this change in > hotspot was added to support long loops, if it is in fact "small". > > My understanding is that the change has been split in multiple chunks. > The chunk we mostly depend on is this: > > https://bugs.openjdk.java.net/browse/JDK-8259609 > > (in fact I'm coordinating with Roland, the author of that work, and he's > testing the patch against a version of panama which doesn't have > workarounds for small segments). > > I did run all Panama benchmarks after JDK-8223051 was pushed, and > removed various workarounds, but there was still a performance gap. > Roland reassured me that the gap should disappear once JDK-8259609 is > pushed. > > Maurizio > > > > > Uwe > > > From maurizio.cimadamore at oracle.com Tue Jun 15 20:09:25 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 15 Jun 2021 21:09:25 +0100 Subject: Memory Segment efficient array handling In-Reply-To: References: <08a001d726ec$f3bd0f30$db372d90$@apache.org> <5d67aba5-e7c8-620c-41ec-0daf396f0d96@oracle.com> <04e101d761c8$67896510$369c2f30$@apache.org> <265ceecd-941a-127b-e2e7-5462f190291c@oracle.com> <06d701d761d1$21bb6f70$65324e50$@apache.org> <7659efda-ed64-093b-c69b-b5af767768c1@oracle.com> <073701d761de$e8317bb0$b8947310$@apache.org> Message-ID: <49690d39-656a-80ed-794e-d2174c71b8f4@oracle.com> Thanks - I'll add this on my radar Maurizio On 15/06/2021 20:06, leerho wrote: > Maurizio, > I have updated the *MemoryCopy* and *TestMemoryCopy* to include > references to the new *MemorySegment::CopyFrom(...)* and with byte > swap capabilities. > > I have been able to test the code in my local environment using a mock > substitute for the new CopyFrom(), but alas, I could not get Jtreg to > work, so i am sending you the code as updated in > https://github.com/leerho/mcimadamore_panama-foreign > > > Please test it, when you have a chance. > > Lee. > > > On Tue, Jun 15, 2021 at 5:43 AM Maurizio Cimadamore > > wrote: > > > >> The reason why copying is slower for small segments is that, I > think, my > >> benchmark iterations run in 4-5ns and, at these levels, you are > >> sensitive to the cost of the liveness checks. There's not a lot > we can > >> do to eliminate that - it's the price of safety. > > OK that's true. But in my own Unsafe.copyMemory code wasn't > doing MemorySegment.address().toRawLongValue() not also doing the > liveness check? > True - so the liveness check probably that won't make a lot of > difference in your case. But note that the bound checks are still > applied in MemorySegment::copyMemory. > > > >> The good news is that in the case of heap segment wrappers, we know > >> exactly that the size is gonna fit inside an int (it's an array > after > >> all!), so we can remove the check. If we remove the flag check, > and just > >> set the segment to always be treated as "SMALL", we get the > following > >> results: > > Is this really true? What about a huge long[] array, that could > be (2^31-8 maximum index) * 8 bytesPerLong = 16 gigabytes? (or are > those limited by the Java standard in maximum array size?) > in the PR I've submitted I only tweaked byte segment wrappers. We > could > resort to more complex internal representation for other heap > segments, > but I believe the true way forward is to wait for the long > optimizations, and to completely remove the SMALL segment hacks. > > > > Sorry, I missed that class. I was opening the pull request and > only looked at the red/green changes in MemorySegment. I missed > the first class. > > > > The methods provided there exactly replace my three shapes in > the code. And on top they allow to swap. Side note: MemoryCopy in > the current PR has the swapping code commented out. > Yeah - Lee is working on that MemoryCopy class (and associated > test). I > have provided the "swappy" copyFrom overload in MemorySegment, I > believe > Lee will add support for that soon. > > > > Last question: why does > https://bugs.openjdk.java.net/browse/JDK-8223051 > not help for > the integer vs. long loop variables? Does this not allow to remove > the small vs. large segment distinction? I thought this change in > hotspot was added to support long loops, if it is in fact "small". > > My understanding is that the change has been split in multiple > chunks. > The chunk we mostly depend on is this: > > https://bugs.openjdk.java.net/browse/JDK-8259609 > > > (in fact I'm coordinating with Roland, the author of that work, > and he's > testing the patch against a version of panama which doesn't have > workarounds for small segments). > > I did run all Panama benchmarks after JDK-8223051 was pushed, and > removed various workarounds, but? there was still a performance gap. > Roland reassured me that the gap should disappear once JDK-8259609 is > pushed. > > Maurizio > > > > > Uwe > > > From maurizio.cimadamore at oracle.com Tue Jun 15 20:11:46 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 15 Jun 2021 21:11:46 +0100 Subject: Gihub Action, CI pipeline In-Reply-To: References: Message-ID: <3bc9f966-00bd-5280-3fab-53784480ba66@oracle.com> On 15/06/2021 16:42, Giuseppe Barbieri wrote: > Hi, > > I'm looking at the `.github/workflows/submit.yml` file and it looks quite > interesting and complete. > > I'm trying to fix/enhance it. I'd like to automatically publish a build if > all tests pass. > In this way, the jextract plugin may be able to just grab and use the > latest available build. This is not possible - we do not publish builds using GitHub actions. This is not a panama decision, but a JDK-wide one. If you want to discuss that I'd suggest to redirect your question to a more general forum like jdk-dev or build-dev. > > Would you be interested in a PR in this direction? > > Ps: I already fixed the linux-64 and macos x64 builds, I have no idea how > to do the rest though, linux32 is build from 64, but if I pass the same > LLVM I use in linux-64, it still complains: > > configure: error: Cannot locate libclang or headers at the specified > locations: > /home/runner/work/panama-foreign/panama-foreign/clang+llvm-12.0.0-x86_64-linux-gnu-ubuntu-20.04/lib > > /home/runner/work/panama-foreign/panama-foreign/clang+llvm-12.0.0-x86_64-linux-gnu-ubuntu-20.04/include > > configure exiting with result code 1 > > https://github.com/elect86/panama-foreign/runs/2830854989?check_suite_focus=true#step:11:282 > > For Windows, the LLVM release page has only .exe, so I'm unsure how to > continue there, while for macOS arm there is no LLVM build.. > > However one single test fails: TestLinkToNativeRBP > > /home/runner/work/panama-foreign/panama-foreign/test/hotspot/jtreg/gc/shenandoah/compiler/TestLinkToNativeRBP.java:51: > error: cannot find symbol > static final LibraryLookup lookup = > LibraryLookup.ofLibrary("LinkToNativeRBP"); > > And indeed there is no LibraryLookup in the current snapshot, shall this be > removed or? I believe this has been fixed upstream - butt there were merge issues which we have rectified today. So perhaps it should be ok now? Maurizio > > Giuseppe From elect86 at gmail.com Tue Jun 15 20:26:03 2021 From: elect86 at gmail.com (Giuseppe Barbieri) Date: Tue, 15 Jun 2021 22:26:03 +0200 Subject: Gihub Action, CI pipeline In-Reply-To: <3bc9f966-00bd-5280-3fab-53784480ba66@oracle.com> References: <3bc9f966-00bd-5280-3fab-53784480ba66@oracle.com> Message-ID: > This is not possible - we do not publish builds using GitHub actions. > This is not a panama decision, but a JDK-wide one. > > If you want to discuss that I'd suggest to redirect your question to a > more general forum like jdk-dev or build-dev. > Ok, I'll propose maybe something over there then I believe this has been fixed upstream - butt there were merge issues > which we have rectified today. So perhaps it should be ok now? > > Maurizio > Yes, it's, thanks Giuseppe From mcimadamore at openjdk.java.net Tue Jun 15 21:00:42 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 15 Jun 2021 21:00:42 GMT Subject: [foreign-memaccess+abi] RFR: 8268743: Require a better way for copying data between MemorySegments and on-heap arrays In-Reply-To: References: Message-ID: <5vcJ8LeCaOH_-6hUZ2TCrKsDSYHfNB3gMAqVI_fR1uM=.a79f309e-a809-4c0b-881d-b102d659853f@github.com> On Tue, 15 Jun 2021 13:05:28 GMT, Uwe Schindler wrote: >>> But we have no solution for larger sizes like float[] or long[] arrays? >> >> Not for now - the real solution is to fix the performance woes which makes the implementation do all these workarounds for longs vs. ints. That said, I'd be curious, once this is integrated, if you could do a quick validation and re-run that benchmark where you were seeing lots of byte segment wrappers in the heap and make sure at least that behaves as expected. > >> > But we have no solution for larger sizes like float[] or long[] arrays? >> >> Not for now - the real solution is to fix the performance woes which makes the implementation do all these workarounds for longs vs. ints. That said, I'd be curious, once this is integrated, if you could do a quick validation and re-run that benchmark where you were seeing lots of byte segment wrappers in the heap and make sure at least that behaves as expected. > > For sure. > > @rmuir and I already discussed about that. From what we understand: `readLong(long[], offset, count)` in our case is never reading more than 64 longs because of the limitations of PFOR algorithm inside Lucene. So we would remove the specialization in MemorySegmentIndexinput and the superclass will use a loop of readLong() instead. This also goes in line with your hint to copyMemory liveness check overhead. The readFloat variant we have is reading a maximum of 1024 float dimensions for our vector suppotr, I will do some quick investigations later, but I tend to remove the specialization, too. In future we will use FloatVector from vector API and that should possibly be wrapped over the memory segment (see also https://github.com/apache/lucene/pull/18 for some quick investigations). For the longs and the PFOR algorithm we may also use a vectorized approach in future, so readFloat() and readLongs() will go away and be replaced to return a FloatVector/LongVector view on the memory segm ent (using ByteBuffer view or directly once panama and vector can share APIs). > > The biggest problem on our side is our implementation of `readBytes(byte[], offset, count)` which is fixed here. > Adding a static method which avoids all the slicing doesn't seem to help performance-wise. It is still slower than an Unsafe call (20-25%). If that would help narrow things down, we could try adding such a static method at least in the Panama repo and maybe we could test that with Lucene? At least we would have removed allocations out of the equation (but I suspect that allocation is not where the performance slowdown is coming from). @uschindler let me know what would be the easiest for you to try. Actually, it's even worse if the benchmark is tweaked to use non-static segments/buffers: Benchmark Mode Cnt Score Error Units TestSmallCopy.buffer_small_copy avgt 30 5.163 ? 0.146 ns/op TestSmallCopy.segment_small_copy_slice avgt 30 7.176 ? 0.082 ns/op TestSmallCopy.segment_small_copy_static avgt 30 8.091 ? 0.155 ns/op TestSmallCopy.unsafe_small_copy avgt 30 4.778 ? 0.052 ns/op The benchmark code can be found here: https://github.com/mcimadamore/panama-foreign/blob/small_copy_benchmark/test/micro/org/openjdk/bench/jdk/incubator/foreign/TestSmallCopy.java Despite absence of allocation in this benchmark (which can be seen by running benchmark with `-prof gc`) performance of bulk copy is not great. Slicing is actually faster than using a static method, presumably because the slice instance is getting scalarized (while the segment stashed in the field is not), which is an effect we have seen other times. I can't, on top of my head, explain the difference, especially with the buffer API - so I filed this: https://bugs.openjdk.java.net/browse/JDK-8268822 ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/560 From sviswanathan at openjdk.java.net Wed Jun 16 00:07:41 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Wed, 16 Jun 2021 00:07:41 GMT Subject: [vectorIntrinsics+mask] RFR: Merge panama-vector:vectorIntrinsics Message-ID: Bringing vectorIntrinsics changes to vectorIntrinsics+mask. ------------- Commit messages: - Merge vectorIntrinsics - Merge panama-vector:master - 8267930: Refine code for loading hsdis library - 8268574: ProblemList tests failing due to UseBiasedLocking going away - 8267556: Enhance class paths check during runtime - 8267893: Improve jtreg test failure handler do get native/mixed stack traces for cores and live processes - 8268223: Problemlist vmTestbase/nsk/jdi/HiddenClass/events/events001.java - 8268539: several serviceability/sa tests should be run in driver mode - 8268361: Fix the infinite loop in next_line - 8267630: Start of release updates for JDK 18 - ... and 400 more: https://git.openjdk.java.net/panama-vector/compare/44082753...b6c89aa8 The webrevs contain the adjustments done while merging with regards to each parent branch: - vectorIntrinsics+mask: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=93&range=00.0 - panama-vector:vectorIntrinsics: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=93&range=00.1 Changes: https://git.openjdk.java.net/panama-vector/pull/93/files Stats: 291804 lines in 4724 files changed: 145534 ins; 132296 del; 13974 mod Patch: https://git.openjdk.java.net/panama-vector/pull/93.diff Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/93/head:pull/93 PR: https://git.openjdk.java.net/panama-vector/pull/93 From leerho at gmail.com Wed Jun 16 01:37:17 2021 From: leerho at gmail.com (leerho) Date: Tue, 15 Jun 2021 18:37:17 -0700 Subject: Propose 2 new methods for MemorySegment Message-ID: In working on https://github.com/openjdk/panama-foreign/pull/555, which is the PR for Memory Segment Efficient Array Handling, I discovered that there are two methods that would be very useful beyond copying arrays, but useful in other types of data movement operations between MemorySegments. I'd like to draw attention to the opening Javadoc of the *MemorySegment::copyFrom(MemorySegment)* method: 1. Performs a bulk copy from given source segment to this segment. More > specifically, the bytes at offset 0 through src.byteSize() - 1 in the > source segment are copied into this segment at offset 0 through src.byteSize() > - 1. If the source segment overlaps with this segment, then the copying > is performed as if the bytes at offset 0 through src.byteSize() - 1 in > the source segment were first copied into a temporary segment with size > bytes, and then the contents of the temporary segment were copied into > this segment at offset 0 through src.byteSize() - 1. > > 2. The result of a bulk copy is unspecified if, in the uncommon case, the > source segment and this segment do not overlap, but refer to overlapping > regions of the same backing storage using different addresses. For example, > this may occur if the same file is mapped > <#mapFile(java.nio.file.Path,long,long,java.nio.channels.FileChannel.MapMode,jdk.incubator.foreign.ResourceScope)> to > two segments. > The first paragraph is a guarantee that even if two descendant segments have an overlapping region with a parent segment that the copy operation will work properly. This is similar to the guarantee of System.arrayCopy() The second paragraph refers to memory-mapped files. However, let's examine the following scenario: - A hierarchy of Memory Segments where two descendant segments may overlap a region of the parent segment. - The elements of the segments are more complex than Java primitives (thus, PR 555 doesn't apply). - The user wishes to copy a region of elements from one of the descendant segments to the other descendant segment. - The user only has the two descendant segments in hand and does not have access to the parent segment. With the current MemorySegment API, the descendant segments are blind to the overlap, to wit: - The user cannot determine if an overlap exists. - Or, if an overlap exists where the overlap is with respect to the two segments in hand. In order to ensure that corruption doesn't occur during the copy, the user must create a temporary duplicate of the destination segment, copy the data into the duplicate, then copy the duplicate into the original destination segment. This can be expensive in time and space. If, however, the user can determine that an overlap exists, and where the overlap occurs, the copy operation can be done safely, with no additional storage, by properly choosing the direction of the iterative copy. To solve this, the user doesn't need access to the parent segment (this could be for security reasons), but could use these two methods: - MemorySegment::boolean isSameBaseResource(MemorySegment other); The intent is to reveal if *this* segment and the *other* segment share a common ancestor segment. It could also be extended to determine if the two segments share the same memory-mapped file (a true resource), thus possibly removing the caveat in paragraph 2 above. - MemorySegment::long baseResourceOffsetBytes(); This would return the offset in bytes of the start of this segment from the start of the highest common segment (or resource). With this information, the user can easily design a safe, efficient, and fast data copy method for moving arbitrary elements from one segment to another with the same guarantee as System.arrayCopy(). *Evidence* See (copySwap(...) ). Before I had access to the new MemorySegment::void copyFrom(MemorySegment, MemoryLayout, MemoryLayout), I had to design a proxy routine that would do the copy (with swap) correctly, especially in the case where the two segments overlapped. Note lines 682, 683 where I create a temporary segment. If I had the above two methods, this extra copy operation would not be needed. For exactly the above reasons, some years ago we implemented similar methods in our DataSketches Memory Component . Specifically, in the class *WritableMemory*, the methods *getRegionOffset()* and *isSameResource(that).* Lee. From sviswanathan at openjdk.java.net Wed Jun 16 04:09:04 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Wed, 16 Jun 2021 04:09:04 GMT Subject: [vectorIntrinsics+mask] Integrated: Merge panama-vector:vectorIntrinsics In-Reply-To: References: Message-ID: On Tue, 15 Jun 2021 22:40:41 GMT, Sandhya Viswanathan wrote: > Bringing vectorIntrinsics changes to vectorIntrinsics+mask. This pull request has now been integrated. Changeset: 14ed85b5 Author: Sandhya Viswanathan URL: https://git.openjdk.java.net/panama-vector/commit/14ed85b5136fbebe75b2f150892486b0319bee6c Stats: 291804 lines in 4724 files changed: 145534 ins; 132296 del; 13974 mod Merge panama-vector:vectorIntrinsics ------------- PR: https://git.openjdk.java.net/panama-vector/pull/93 From sviswanathan at openjdk.java.net Wed Jun 16 04:08:59 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Wed, 16 Jun 2021 04:08:59 GMT Subject: [vectorIntrinsics+mask] RFR: Merge panama-vector:vectorIntrinsics [v2] In-Reply-To: References: Message-ID: > Bringing vectorIntrinsics changes to vectorIntrinsics+mask. Sandhya Viswanathan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: - Merge vectorIntrinsics - Merge branch 'vectorIntrinsics' into vectorIntrinsics+mask branch - Merge panama-vector:vectorIntrinsics Reviewed-by: njian - 8266621: Add masking support for unary/ternary vector intrinsics Reviewed-by: psandoz, vlivanov - 8264563: Add masked vector intrinsics for binary/store operations Co-authored-by: Ningsheng Jian Reviewed-by: jbhateja, sviswanathan, vlivanov, whuang - 8265109: SVE predicate register allocation support for vectorIntrinsics Reviewed-by: sviswanathan - Merge panama-vector:vectorIntrinsics ------------- Changes: https://git.openjdk.java.net/panama-vector/pull/93/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=93&range=01 Stats: 3802 lines in 68 files changed: 2698 ins; 465 del; 639 mod Patch: https://git.openjdk.java.net/panama-vector/pull/93.diff Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/93/head:pull/93 PR: https://git.openjdk.java.net/panama-vector/pull/93 From uschindler at openjdk.java.net Wed Jun 16 07:49:46 2021 From: uschindler at openjdk.java.net (Uwe Schindler) Date: Wed, 16 Jun 2021 07:49:46 GMT Subject: [foreign-memaccess+abi] RFR: 8268743: Require a better way for copying data between MemorySegments and on-heap arrays In-Reply-To: References: Message-ID: On Tue, 15 Jun 2021 11:56:26 GMT, Maurizio Cimadamore wrote: > After some investigation, it seems that escape analysis is defeated in cases where a new heap segment is created fresh just before performing a bulk copy. > > This is caused by the fact that, on segment creation, we perform this test: > > > static int defaultAccessModes(long size) { > return (enableSmallSegments && size < Integer.MAX_VALUE) ? > SMALL : 0; > } > > > To make sure that segments whose size fits in an `int` do not incur in penalties associated with lack of optimizations over long loop bound check optimizations. > > Unfortunately, this logic is control flow logic, and control flow disables escape analysis optimizations. > > For segment wrappers around byte arrays we can workaround by removing the check (all byte segments are small by definition, since there's a 1-1 mapping between logical elements and physical bytes). For other segment kinds we cannot do much. > > While it would be possible, in principle, to resort to more complex bound checks for heap segments, we believe the way forward is to eliminate the need for "small" segments, which will be possible once the PR below is completed: > > https://github.com/openjdk/jdk/pull/2045 Hi, we have clearly seen the allocation, but maybe bring some other part into the game: our segments are in a shared ResourceScope. When comparing the benchmarks (which contain a lot of more code than just the segment copy, because we were testing query performance) there was one thing which I have seen: With our patch that used the slicing/copyFrom variant, it was also obvious from the outside that something was wrong: each iteration of the whole Lucene benchmark was like 20 % slower in total runtime (from startup till end of each iteration) in combination with garbage collection activity (which was also seen by JFR). So something in our case was triggering the allocations. The difference in runtime between unpatched and patched lucene benchmark was worse with tiered compilation disabled (for historical reasons the Lucene benchmark runs with tiered off and -Xbatch on). See outputs on https://github.com/apache/lucene/pull/177 >From your latest benchmarks it looks like in addition to the allocation we have seen, there is some other slowdown when doing the segment memorycopy. From my understanding this mostly affects small segments, because the overhead of liveness check overweighs. But isn't the liveness check not also done for varhandle access (although optimized away after some time), so rewriting to a loop would not bring much - as the lifeness check needs to be done at least at start of loop after optimizations kicking in? What is the difference in the lifeness check (on the shared memory segment) between copyMemory and a single varhandle call? > If that would help narrow things down, we could try adding such a static method at least in the Panama repo and maybe we could test that with Lucene? At least we would have removed allocations out of the equation (but I suspect that allocation is not where the performance slowdown is coming from). @uschindler let me know what would be the easiest for you to try. Sure, I can run the benchmarks with a Linux build of Panama! I can compile my own on this machine (not today or tomorrow), but if you have some tar.gz file with a prebuilt binary available it would be great. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/560 From elect86 at gmail.com Wed Jun 16 08:18:53 2021 From: elect86 at gmail.com (Giuseppe Barbieri) Date: Wed, 16 Jun 2021 10:18:53 +0200 Subject: [foreign-memaccess+abi] RFR: 8268743: Require a better way for copying data between MemorySegments and on-heap arrays Message-ID: > Sure, I can run the benchmarks with a Linux build of Panama! I can compile my own on this machine (not today or tomorrow), but if you have some tar.gz file with a prebuilt binary available it would be great. Hey Uwe, sorry for the intrusion, but I think this might be interesting for you I'm in the process of setting up a CI pipeline (on a fork at the very moment), but a couple of nightly builds are already available: https://github.com/elect86/panama-foreign/releases Giuseppe From maurizio.cimadamore at oracle.com Wed Jun 16 08:43:19 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 16 Jun 2021 09:43:19 +0100 Subject: Propose 2 new methods for MemorySegment In-Reply-To: References: Message-ID: I see what you mean. I wonder if this use case isn't already partially covered by MemoryAddress::segmentOffset. E.g. can you do: long otherOffset = segment.address().segmentOffset(otherSegment); Then it should be easy to check if the offset is within the bounds of "otherSegment" ? (Note that the method already throws if you try to compare addresses and segments that are mismatched - e.g. on-heap vs. off-heap). Not saying a more direct API is ruled out, just pointing out what we have to see if it can be used. Maurizio On 16/06/2021 02:37, leerho wrote: > In working on https://github.com/openjdk/panama-foreign/pull/555, which is > the PR for Memory Segment Efficient Array Handling, I discovered that there > are two methods that would be very useful beyond copying arrays, but useful > in other types of data movement operations between MemorySegments. > > I'd like to draw attention to the opening Javadoc of the > *MemorySegment::copyFrom(MemorySegment)* method: > > 1. Performs a bulk copy from given source segment to this segment. More >> specifically, the bytes at offset 0 through src.byteSize() - 1 in the >> source segment are copied into this segment at offset 0 through src.byteSize() >> - 1. If the source segment overlaps with this segment, then the copying >> is performed as if the bytes at offset 0 through src.byteSize() - 1 in >> the source segment were first copied into a temporary segment with size >> bytes, and then the contents of the temporary segment were copied into >> this segment at offset 0 through src.byteSize() - 1. >> >> 2. The result of a bulk copy is unspecified if, in the uncommon case, the >> source segment and this segment do not overlap, but refer to overlapping >> regions of the same backing storage using different addresses. For example, >> this may occur if the same file is mapped >> <#mapFile(java.nio.file.Path,long,long,java.nio.channels.FileChannel.MapMode,jdk.incubator.foreign.ResourceScope)> to >> two segments. >> > The first paragraph is a guarantee that even if two descendant segments > have an overlapping region with a parent segment that the copy operation > will work properly. This is similar to the guarantee of System.arrayCopy() > > The second paragraph refers to memory-mapped files. However, let's examine > the following scenario: > > - A hierarchy of Memory Segments where two descendant segments may > overlap a region of the parent segment. > - The elements of the segments are more complex than Java primitives > (thus, PR 555 doesn't apply). > - The user wishes to copy a region of elements from one of the > descendant segments to the other descendant segment. > - The user only has the two descendant segments in hand and does not > have access to the parent segment. > > With the current MemorySegment API, the descendant segments are blind to > the overlap, to wit: > > - The user cannot determine if an overlap exists. > - Or, if an overlap exists where the overlap is with respect to the two > segments in hand. > > In order to ensure that corruption doesn't occur during the copy, the user > must create a temporary duplicate of the destination segment, copy the data > into the duplicate, then copy the duplicate into the original destination > segment. This can be expensive in time and space. > > If, however, the user can determine that an overlap exists, and where the > overlap occurs, the copy operation can be done safely, with no additional > storage, by properly choosing the direction of the iterative copy. > > To solve this, the user doesn't need access to the parent segment (this > could be for security reasons), but could use these two methods: > > - MemorySegment::boolean isSameBaseResource(MemorySegment other); > The intent is to reveal if *this* segment and the *other* segment share > a common ancestor segment. It could also be extended to determine if the > two segments share the same memory-mapped file (a true resource), thus > possibly removing the caveat in paragraph 2 above. > > > - MemorySegment::long baseResourceOffsetBytes(); > This would return the offset in bytes of the start of this segment from > the start of the highest common segment (or resource). > > With this information, the user can easily design a safe, efficient, and > fast data copy method for moving arbitrary elements from one segment to > another with the same guarantee as System.arrayCopy(). > > *Evidence* > See (copySwap(...) > ). > Before I had access to the new MemorySegment::void copyFrom(MemorySegment, > MemoryLayout, MemoryLayout), I had to design a proxy routine that would do > the copy (with swap) correctly, especially in the case where the two > segments overlapped. Note lines 682, 683 where I create a temporary > segment. If I had the above two methods, this extra copy operation would > not be needed. > > For exactly the above reasons, some years ago we implemented similar > methods in our DataSketches Memory Component > . > Specifically, in the class *WritableMemory*, the methods *getRegionOffset()* > and *isSameResource(that).* > > Lee. From maurizio.cimadamore at oracle.com Wed Jun 16 08:57:20 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 16 Jun 2021 09:57:20 +0100 Subject: [foreign-memaccess+abi] RFR: 8268743: Require a better way for copying data between MemorySegments and on-heap arrays In-Reply-To: References: Message-ID: <6583cbef-c26e-9ad0-bb97-9743af3b41e4@oracle.com> On 16/06/2021 08:49, Uwe Schindler wrote: > On Tue, 15 Jun 2021 11:56:26 GMT, Maurizio Cimadamore wrote: > >> After some investigation, it seems that escape analysis is defeated in cases where a new heap segment is created fresh just before performing a bulk copy. >> >> This is caused by the fact that, on segment creation, we perform this test: >> >> >> static int defaultAccessModes(long size) { >> return (enableSmallSegments && size < Integer.MAX_VALUE) ? >> SMALL : 0; >> } >> >> >> To make sure that segments whose size fits in an `int` do not incur in penalties associated with lack of optimizations over long loop bound check optimizations. >> >> Unfortunately, this logic is control flow logic, and control flow disables escape analysis optimizations. >> >> For segment wrappers around byte arrays we can workaround by removing the check (all byte segments are small by definition, since there's a 1-1 mapping between logical elements and physical bytes). For other segment kinds we cannot do much. >> >> While it would be possible, in principle, to resort to more complex bound checks for heap segments, we believe the way forward is to eliminate the need for "small" segments, which will be possible once the PR below is completed: >> >> https://github.com/openjdk/jdk/pull/2045 > Hi, > > we have clearly seen the allocation, but maybe bring some other part into the game: our segments are in a shared ResourceScope. Shared scope shouldn't affect allocation profile. And slicing with shared scopes doesn't cost extra, only closing shared scope costs extra. So I think we can rule this out. > > When comparing the benchmarks (which contain a lot of more code than just the segment copy, because we were testing query performance) there was one thing which I have seen: With our patch that used the slicing/copyFrom variant, it was also obvious from the outside that something was wrong: each iteration of the whole Lucene benchmark was like 20 % slower in total runtime (from startup till end of each iteration) in combination with garbage collection activity (which was also seen by JFR). So something in our case was triggering the allocations. The difference in runtime between unpatched and patched lucene benchmark was worse with tiered compilation disabled (for historical reasons the Lucene benchmark runs with tiered off and -Xbatch on). See outputs on https://github.com/apache/lucene/pull/177 > > From your latest benchmarks it looks like in addition to the allocation we have seen, there is some other slowdown when doing the segment memorycopy. From my understanding this mostly affects small segments, because the overhead of liveness check overweighs. But isn't the liveness check not also done for varhandle access (although optimized away after some time), so rewriting to a loop would not bring much - as the lifeness check needs to be done at least at start of loop after optimizations kicking in? What is the difference in the lifeness check (on the shared memory segment) between copyMemory and a single varhandle call? So, in part this is known: the extra checks (liveness and bounds) prior to memory access cost inevitably more than a plain, unchecked unsafe access. So, if you do a _single_ var handle access, and you benchmark it against a _single_ Unsafe access, it is slower - we have benchmark for this stuff. In reality (1) there's not much we can do (we can't compete with _all belts off_ mode) and (2) the use case of a single "hot" memory access is not very realistic. Typically you will access memory in loops. And in these cases the memory API can take advantage of C2 optimizations, checks are hoisted, and no extra price is paid in the end. This is the same deal the ByteBuffer API does. The issue with memory copy is that memory copy _is_ typically used in a standalone fashion, e.g. outside of a loop. I'm pretty sure that if I repeat the benchmark by wrapping it in a loop and do like 100 iterations, the difference with unsafe will disappear. But that's _not_ how users will use `copyFrom`. What remains to be seen is as to whether this extra cost (even compared with other APIs like ByteBuffer) is something which looks like a missing C2 optimization, or something not optimal on our implementation. We plan to investigate more and try to narrow this down. > >> If that would help narrow things down, we could try adding such a static method at least in the Panama repo and maybe we could test that with Lucene? At least we would have removed allocations out of the equation (but I suspect that allocation is not where the performance slowdown is coming from). @uschindler let me know what would be the easiest for you to try. > Sure, I can run the benchmarks with a Linux build of Panama! I can compile my own on this machine (not today or tomorrow), but if you have some tar.gz file with a prebuilt binary available it would be great. I believe the thing that would make the most sense would be for you to build the bits in this branch: https://github.com/mcimadamore/panama-foreign/tree/small_copy_benchmark/ This is like Panama repo, but it has a new static method to do the copy, in MemorySegment. If using the static method instead of the slicing-based copyFrom removes all the allocation AND it makes benchmark return back to where they were, we can consider doing something like this. The benchmark I have in that branch doesn't seem to suggest that the static method is any faster than the other one, but it is always hard to generalize microbenchmarks results - for instance, it might be that your copy code is "cold" and is never touched by C2, or maybe it is touched only by one of the first compiler tiers. So, let's rule out allocation and GC cost first - if you use the static method, you should no longer slice and dice before a copy. This should at least remove the allocation you see: let's see if that's enough to bring Lucene performance back to where it was. Maurizio > > ------------- > > PR: https://git.openjdk.java.net/panama-foreign/pull/560 From maurizio.cimadamore at oracle.com Wed Jun 16 09:08:05 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 16 Jun 2021 10:08:05 +0100 Subject: [foreign-memaccess+abi] RFR: 8268743: Require a better way for copying data between MemorySegments and on-heap arrays In-Reply-To: References: Message-ID: Hey Giuseppe - how hard would it be to set up a build for this branch too: https://github.com/mcimadamore/panama-foreign/tree/small_copy_benchmark/ I believe that would be the most useful for Uwe to play with. After we're done with the experiment we can drop it of course. Thanks (and sorry for the inconvenience). Maurizio On 16/06/2021 09:18, Giuseppe Barbieri wrote: >> Sure, I can run the benchmarks with a Linux build of Panama! I can > compile my own on this machine (not today or tomorrow), but if you have > some tar.gz file with a prebuilt binary available it would be great. > > > Hey Uwe, > > sorry for the intrusion, but I think this might be interesting for you > > I'm in the process of setting up a CI pipeline (on a fork at the very > moment), but a couple of nightly builds are already available: > https://github.com/elect86/panama-foreign/releases > > > Giuseppe From elect86 at gmail.com Wed Jun 16 09:19:49 2021 From: elect86 at gmail.com (Giuseppe Barbieri) Date: Wed, 16 Jun 2021 11:19:49 +0200 Subject: [foreign-memaccess+abi] RFR: 8268743: Require a better way for copying data between MemorySegments and on-heap arrays In-Reply-To: References: Message-ID: Il giorno mer 16 giu 2021 alle ore 11:08 Maurizio Cimadamore < maurizio.cimadamore at oracle.com> ha scritto: > Hey Giuseppe - how hard would it be to set up a build for this branch too: > > https://github.com/mcimadamore/panama-foreign/tree/small_copy_benchmark/ > > I believe that would be the most useful for Uwe to play with. After > we're done with the experiment we can drop it of course. > > Thanks (and sorry for the inconvenience). > > Maurizio > You should first enable github action on the repo (browse to the github repo webpage, click on "Actions" and you should see the option to enable it, if it has not been done yet) Then, just add something like this - name: ??? Create release if: strategy.job-index == 0 uses: ncipollo/release-action at v1 with: artifacts: ~/jdk-linux-x64${{ matrix.artifact }}/jdk-${{ env.JDK_VERSION }}-internal+0_linux-x64_bin${{ matrix.artifact }}.tar.gz token: ${{ secrets.GITHUB_TOKEN }} tag: $GITHUB_ACTOR-$GITHUB_SHA body: $GITHUB_ACTOR-$GITHUB_SHA draft: true after name: Check that all tests executed successfully in the following task linux_x64_test It still needs to be polished though (properly retrieving GITHUB_ACTOR and GITHUB_SHA to say), but for a quick & dirty build should be sufficient Ps: I still don't have a signed OCA, so I can't do that myself Giuseppe From xgong at openjdk.java.net Wed Jun 16 09:38:13 2021 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Wed, 16 Jun 2021 09:38:13 GMT Subject: [vectorIntrinsics+mask] RFR: 8266287: Basic mask IR implementation for the Vector API masking feature support [v2] In-Reply-To: References: Message-ID: On Wed, 12 May 2021 10:50:30 GMT, Jatin Bhateja wrote: >> Xiaohong Gong has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: >> >> - Use "Flag_is_predicated_vector" for masked vector nodes >> - Merge branch 'vectorIntrinsics+mask' >> - 8266287: Basic mask IR implementation for the Vector API masking feature support > > src/hotspot/share/opto/vectorIntrinsics.cpp line 84: > >> 82: assert(check_vbox(vbox_type), ""); >> 83: const TypeVect* vt = is_vector_mask(vbox_type->klass()) ? >> 84: TypeVect::makemask(elem_bt, num_elem) : TypeVect::make(elem_bt, num_elem); > > Box type which is an envelope type should still be the same e.g. Int256VectorMask. Value contained in the Masked Box should be of type vectmask. Hi @jatin-bhateja , it seems the type of `VectorBox/VectorUnbox` should be exactly matched with the `value` boxed. For such an optimization `// VectorUnbox (VectorBox v) ==> v`, if the type of `v` is a vector mask type while the `VectorUnbox` type is expected to be a vector type, the final result of this optimization would change the result type of `VectorUnbox` to be a mask type. Some type checks or assertion will fail. I met the following issue when I run the jtreg tests after changing type of `VectorBox/VectorUnbox` back to vector type: # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/home/ent-user/panama-vector/src/hotspot/share/opto/type.cpp:2412), pid=433543, tid=433698 # Error: assert(base() == v->base()) failed # # JRE version: OpenJDK Runtime Environment (17.0) (fastdebug build 17-internal+0-git-8123588d66) # Java VM: OpenJDK 64-Bit Server VM (fastdebug 17-internal+0-git-8123588d66, mixed mode, sharing, compressed oops, compressed class ptrs, g1 gc, linux-aarch64) # Problematic frame: # V [libjvm.so+0x19f3108] TypeVect::xmeet(Type const*) const+0x138 # # Core dump will be written. Default location: Core dumps may be processed with "/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h %e" (or dumping to /home/ent-user/jtreg/jtreg-hg/build/images/jtreg/jtwork/scratch/2/core.433543) # # If you would like to submit a bug report, please visit: # https://bugreport.java.com/bugreport/crash.jsp Do you have any strong reason that we must define a vector type for `VectorBox/VectorUnbox`? ------------- PR: https://git.openjdk.java.net/panama-vector/pull/78 From mcimadamore at openjdk.java.net Wed Jun 16 09:44:59 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 16 Jun 2021 09:44:59 GMT Subject: [foreign-memaccess+abi] RFR: 8268743: Require a better way for copying data between MemorySegments and on-heap arrays In-Reply-To: References: Message-ID: On Tue, 15 Jun 2021 11:56:26 GMT, Maurizio Cimadamore wrote: > After some investigation, it seems that escape analysis is defeated in cases where a new heap segment is created fresh just before performing a bulk copy. > > This is caused by the fact that, on segment creation, we perform this test: > > > static int defaultAccessModes(long size) { > return (enableSmallSegments && size < Integer.MAX_VALUE) ? > SMALL : 0; > } > > > To make sure that segments whose size fits in an `int` do not incur in penalties associated with lack of optimizations over long loop bound check optimizations. > > Unfortunately, this logic is control flow logic, and control flow disables escape analysis optimizations. > > For segment wrappers around byte arrays we can workaround by removing the check (all byte segments are small by definition, since there's a 1-1 mapping between logical elements and physical bytes). For other segment kinds we cannot do much. > > While it would be possible, in principle, to resort to more complex bound checks for heap segments, we believe the way forward is to eliminate the need for "small" segments, which will be possible once the PR below is completed: > > https://github.com/openjdk/jdk/pull/2045 Minor breakthrough. I explored more the assumption that the copy code in Lucene is not hot enough for C2 to kick in - and started to play with JMH's `@CompilerControl(EXCLUDE)` directive. Performance dips significantly (~10x), but what's striking is that I finally see lots of allocations when using slicing and no allocations when using the static copy method: Benchmark Mode Cnt Score Error Units TestSmallCopy.segment_small_copy_slice avgt 30 157.831 ? 4.524 ns/op TestSmallCopy.segment_small_copy_slice:?gc.alloc.rate avgt 30 241.978 ? 7.438 MB/sec TestSmallCopy.segment_small_copy_slice:?gc.alloc.rate.norm avgt 30 80.007 ? 0.002 B/op TestSmallCopy.segment_small_copy_slice:?gc.churn.G1_Eden_Space avgt 30 246.372 ? 74.872 MB/sec TestSmallCopy.segment_small_copy_slice:?gc.churn.G1_Eden_Space.norm avgt 30 81.763 ? 24.998 B/op TestSmallCopy.segment_small_copy_slice:?gc.churn.G1_Survivor_Space avgt 30 0.001 ? 0.002 MB/sec TestSmallCopy.segment_small_copy_slice:?gc.churn.G1_Survivor_Space.norm avgt 30 ? 10?? B/op TestSmallCopy.segment_small_copy_slice:?gc.count avgt 30 25.000 counts TestSmallCopy.segment_small_copy_slice:?gc.time avgt 30 23.000 ms vs: Benchmark Mode Cnt Score Error Units TestSmallCopy.segment_small_copy_static avgt 30 100.394 ? 7.448 ns/op TestSmallCopy.segment_small_copy_static:?gc.alloc.rate avgt 30 ? 10?? MB/sec TestSmallCopy.segment_small_copy_static:?gc.alloc.rate.norm avgt 30 ? 10?? B/op TestSmallCopy.segment_small_copy_static:?gc.count avgt 30 ? 0 counts This might well explain what @uschindler is seeing. If the code is not hot, EA won't even run, which would explain the allocation. So, if this is the case, we're far less concerned with the cost of single liveness checks, but we'd be more worried about the cost of introducing that many allocations. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/560 From uschindler at openjdk.java.net Wed Jun 16 09:44:59 2021 From: uschindler at openjdk.java.net (Uwe Schindler) Date: Wed, 16 Jun 2021 09:44:59 GMT Subject: [foreign-memaccess+abi] RFR: 8268743: Require a better way for copying data between MemorySegments and on-heap arrays In-Reply-To: References: Message-ID: On Tue, 15 Jun 2021 11:56:26 GMT, Maurizio Cimadamore wrote: > After some investigation, it seems that escape analysis is defeated in cases where a new heap segment is created fresh just before performing a bulk copy. > > This is caused by the fact that, on segment creation, we perform this test: > > > static int defaultAccessModes(long size) { > return (enableSmallSegments && size < Integer.MAX_VALUE) ? > SMALL : 0; > } > > > To make sure that segments whose size fits in an `int` do not incur in penalties associated with lack of optimizations over long loop bound check optimizations. > > Unfortunately, this logic is control flow logic, and control flow disables escape analysis optimizations. > > For segment wrappers around byte arrays we can workaround by removing the check (all byte segments are small by definition, since there's a 1-1 mapping between logical elements and physical bytes). For other segment kinds we cannot do much. > > While it would be possible, in principle, to resort to more complex bound checks for heap segments, we believe the way forward is to eliminate the need for "small" segments, which will be possible once the PR below is completed: > > https://github.com/openjdk/jdk/pull/2045 Hi Maurizio, it's not possible today, because I have a talk at a conference later, but tomorrrow, I can for sure test the repo provided by you. To call the new static MemorySegment.copy() method, I still need to wrap the byte[] array, so I should merge in THIS pull request? From looking at your repository it does not seem to have the HeapMemorySegment SMALL change. Maybe you can also add this small change from this PR also to your benchmark repo. About the liveness check: In my unsafe copy implementation, I called `segment.address().toRawLongAddress()`, so it was also doing the liveness checks. This had no effect on the performance. The only difference is the additional fencing after the whole copyMemory operation in ScopedMemoryAccess. > The issue with memory copy is that memory copy _is_ typically used in a > standalone fashion, e.g. outside of a loop. I'm pretty sure that if I > repeat the benchmark by wrapping it in a loop and do like 100 > iterations, the difference with unsafe will disappear. But that's _not_ > how users will use `copyFrom`. In most cases this is true. Actually we have sometimes a loop, but very seldom: We only use mmap when reading index files, but not for writing new index files, which are just streamed to a classical OutputStream. Sometimes we have to copy data to an OutputStream that was previously read from a MMapped InputStream (happens when merging Lucene index segments). In that case the code will call IndexInput.readBytes(...) and pass the byte array to OutputStream in the usual and well-known copy-loop. But that's of course not the usual case (especially not in our benchmark, because it does not build new indexes); it just executes queries. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/560 From uschindler at openjdk.java.net Wed Jun 16 09:47:49 2021 From: uschindler at openjdk.java.net (Uwe Schindler) Date: Wed, 16 Jun 2021 09:47:49 GMT Subject: [foreign-memaccess+abi] RFR: 8268743: Require a better way for copying data between MemorySegments and on-heap arrays In-Reply-To: References: Message-ID: <79Ij2pJ-_mcLONXIzJl0WawXay879oqlmmMVTb1256I=.4dcef0e4-0ce5-43a9-a2a5-34d551fd6cb8@github.com> On Wed, 16 Jun 2021 09:42:14 GMT, Uwe Schindler wrote: >> After some investigation, it seems that escape analysis is defeated in cases where a new heap segment is created fresh just before performing a bulk copy. >> >> This is caused by the fact that, on segment creation, we perform this test: >> >> >> static int defaultAccessModes(long size) { >> return (enableSmallSegments && size < Integer.MAX_VALUE) ? >> SMALL : 0; >> } >> >> >> To make sure that segments whose size fits in an `int` do not incur in penalties associated with lack of optimizations over long loop bound check optimizations. >> >> Unfortunately, this logic is control flow logic, and control flow disables escape analysis optimizations. >> >> For segment wrappers around byte arrays we can workaround by removing the check (all byte segments are small by definition, since there's a 1-1 mapping between logical elements and physical bytes). For other segment kinds we cannot do much. >> >> While it would be possible, in principle, to resort to more complex bound checks for heap segments, we believe the way forward is to eliminate the need for "small" segments, which will be possible once the PR below is completed: >> >> https://github.com/openjdk/jdk/pull/2045 > > Hi Maurizio, > it's not possible today, because I have a talk at a conference later, but tomorrrow, I can for sure test the repo provided by you. > > To call the new static MemorySegment.copy() method, I still need to wrap the byte[] array, so I should merge in THIS pull request? From looking at your repository it does not seem to have the HeapMemorySegment SMALL change. > > Maybe you can also add this small change from this PR also to your benchmark repo. > > About the liveness check: In my unsafe copy implementation, I called `segment.address().toRawLongAddress()`, so it was also doing the liveness checks. This had no effect on the performance. The only difference is the additional fencing after the whole copyMemory operation in ScopedMemoryAccess. > >> The issue with memory copy is that memory copy _is_ typically used in a >> standalone fashion, e.g. outside of a loop. I'm pretty sure that if I >> repeat the benchmark by wrapping it in a loop and do like 100 >> iterations, the difference with unsafe will disappear. But that's _not_ >> how users will use `copyFrom`. > > In most cases this is true. Actually we have sometimes a loop, but very seldom: We only use mmap when reading index files, but not for writing new index files, which are just streamed to a classical OutputStream. Sometimes we have to copy data to an OutputStream that was previously read from a MMapped InputStream (happens when merging Lucene index segments). In that case the code will call IndexInput.readBytes(...) and pass the byte array to OutputStream in the usual and well-known copy-loop. But that's of course not the usual case (especially not in our benchmark, because it does not build new indexes); it just executes queries. > This might well explain what @uschindler is seeing. If the code is not hot, EA won't even run, which would explain the allocation. So, if this is the case, we're far less concerned with the cost of single liveness checks, but we'd be more worried about the cost of introducing that many allocations. So would the new MemoryCopy class from the other pull request help, because it has `@ForceInline`? ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/560 From mcimadamore at openjdk.java.net Wed Jun 16 10:05:52 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 16 Jun 2021 10:05:52 GMT Subject: [foreign-memaccess+abi] RFR: 8268743: Require a better way for copying data between MemorySegments and on-heap arrays In-Reply-To: References: Message-ID: On Wed, 16 Jun 2021 09:42:14 GMT, Uwe Schindler wrote: > To call the new static MemorySegment.copy() method, I still need to wrap the byte[] array, so I should merge in THIS pull request? From looking at your repository it does not seem to have the HeapMemorySegment SMALL change. Leave alone this pull request, and just work off the branch I pointed out, which contains the static method. The static method just takes two segments, two offsets (in bytes) and a length, it's like System.arrayCopy. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/560 From mcimadamore at openjdk.java.net Wed Jun 16 10:09:46 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 16 Jun 2021 10:09:46 GMT Subject: [foreign-memaccess+abi] RFR: 8268743: Require a better way for copying data between MemorySegments and on-heap arrays In-Reply-To: <79Ij2pJ-_mcLONXIzJl0WawXay879oqlmmMVTb1256I=.4dcef0e4-0ce5-43a9-a2a5-34d551fd6cb8@github.com> References: <79Ij2pJ-_mcLONXIzJl0WawXay879oqlmmMVTb1256I=.4dcef0e4-0ce5-43a9-a2a5-34d551fd6cb8@github.com> Message-ID: <4SkgZDGUYylkOamKEwQxT_zqcpuEtASRCNg8osWXYXE=.a2267d0d-1364-452e-bff9-fb1a9f11af44@github.com> On Wed, 16 Jun 2021 09:44:55 GMT, Uwe Schindler wrote: > So would the new MemoryCopy class from the other pull request help, because it has `@ForceInline`? Possibly, although our philosophy behind adding static helpers is that they should be just "helpers", not a way to get more performant code. That is, you get same performance with a VarHandle call than you get with MemoryAccess::get. But if the basic `copyFrom` does not always offer the expected performance model, then I'd claim it's a bug in that the API exposes the "wrong" primitive (because use cases for scalar memory access are very different from bulk memory access, for the reasons mentioned above). But let's first verify that this is indeed what's causing the degradation for Lucene. You mentioned that the copy method were called "millions of times" which makes it unlikely for them to be completely "cold" and unoptimized. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/560 From uschindler at openjdk.java.net Wed Jun 16 10:55:51 2021 From: uschindler at openjdk.java.net (Uwe Schindler) Date: Wed, 16 Jun 2021 10:55:51 GMT Subject: [foreign-memaccess+abi] RFR: 8268743: Require a better way for copying data between MemorySegments and on-heap arrays In-Reply-To: References: Message-ID: On Wed, 16 Jun 2021 10:02:39 GMT, Maurizio Cimadamore wrote: > > To call the new static MemorySegment.copy() method, I still need to wrap the byte[] array, so I should merge in THIS pull request? From looking at your repository it does not seem to have the HeapMemorySegment SMALL change. > > Leave alone this pull request, and just work off the branch I pointed out, which contains the static method. The static method just takes two segments, two offsets (in bytes) and a length, it's like System.arrayCopy. I will just check both branches separately. First this pull request, if it makes the allocations go away (which looks like it won't). Then the other one. Give me a few days, will work on this after the conference. > But let's first verify that this is indeed what's causing the degradation for Lucene. You mentioned that the copy method were called "millions of times" which makes it unlikely for them to be completely "cold" and unoptimized. That was meant "symbolic". Not sure how often it is called in reality. But from the number of allocations on heap, it seems often. We found similar issues in the past, too: Sometimes Hotspot refuses to optimize a method for unknown reasons. It seems to have to do with how it is called. Sometimes the complexity of code inside Lucene is dramatic. Internals are looking very "C like". Huge methods with complex spaghetti-like logic, randomly calling methods from MemorySegmentIndexInput (previously ByteBufferIndexInput). Most of the logic uses the "iterator/enum" aproach. Search thread gets new document hits by consuming some enum, which itsself calls IndexInput. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/560 From jvernee at openjdk.java.net Wed Jun 16 11:12:09 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 16 Jun 2021 11:12:09 GMT Subject: [foreign-memaccess+abi] RFR: Fix a couple of CI build problems Message-ID: <3lCljtwBXqawUbzr6nnfIi6RSMV2KBI-XfmE6q9lSfM=.4e1b7fbb-8560-4e7d-92a7-4fc36d3346f5@github.com> - Statically link the C++ standard library into libTestAsyncStackWalk to avoid linking error when running. - Specify exception handling semantics for libTestAsyncStackWalk on Windows to avoid warning. ------------- Commit messages: - Statically link the C++ standard library into libTestAsyncStackWalk Changes: https://git.openjdk.java.net/panama-foreign/pull/561/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=561&range=00 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/561.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/561/head:pull/561 PR: https://git.openjdk.java.net/panama-foreign/pull/561 From mcimadamore at openjdk.java.net Wed Jun 16 11:12:10 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 16 Jun 2021 11:12:10 GMT Subject: [foreign-memaccess+abi] RFR: Fix a couple of CI build problems In-Reply-To: <3lCljtwBXqawUbzr6nnfIi6RSMV2KBI-XfmE6q9lSfM=.4e1b7fbb-8560-4e7d-92a7-4fc36d3346f5@github.com> References: <3lCljtwBXqawUbzr6nnfIi6RSMV2KBI-XfmE6q9lSfM=.4e1b7fbb-8560-4e7d-92a7-4fc36d3346f5@github.com> Message-ID: On Wed, 16 Jun 2021 11:04:41 GMT, Jorn Vernee wrote: > - Statically link the C++ standard library into libTestAsyncStackWalk to avoid linking error when running. > - Specify exception handling semantics for libTestAsyncStackWalk on Windows to avoid warning. Looks good ------------- Marked as reviewed by mcimadamore (Committer). PR: https://git.openjdk.java.net/panama-foreign/pull/561 From duke at openjdk.java.net Wed Jun 16 11:14:30 2021 From: duke at openjdk.java.net (duke) Date: Wed, 16 Jun 2021 11:14:30 GMT Subject: git: openjdk/panama-foreign: foreign-jextract: 2 new changesets Message-ID: Changeset: b4cde2e8 Author: Jorn Vernee Date: 2021-06-16 11:12:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b4cde2e8147c02be482c97706d676ef61e0ee065 Fix a couple of CI build problems Reviewed-by: mcimadamore ! make/test/JtregNativeJdk.gmk Changeset: 0d035626 Author: duke Date: 2021-06-16 11:13:42 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0d0356266f2124f80eb5e1d82733994e14737e88 Automatic merge of foreign-memaccess+abi into foreign-jextract From jvernee at openjdk.java.net Wed Jun 16 11:15:46 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 16 Jun 2021 11:15:46 GMT Subject: [foreign-memaccess+abi] Integrated: Fix a couple of CI build problems In-Reply-To: <3lCljtwBXqawUbzr6nnfIi6RSMV2KBI-XfmE6q9lSfM=.4e1b7fbb-8560-4e7d-92a7-4fc36d3346f5@github.com> References: <3lCljtwBXqawUbzr6nnfIi6RSMV2KBI-XfmE6q9lSfM=.4e1b7fbb-8560-4e7d-92a7-4fc36d3346f5@github.com> Message-ID: On Wed, 16 Jun 2021 11:04:41 GMT, Jorn Vernee wrote: > - Statically link the C++ standard library into libTestAsyncStackWalk to avoid linking error when running. > - Specify exception handling semantics for libTestAsyncStackWalk on Windows to avoid warning. This pull request has now been integrated. Changeset: b4cde2e8 Author: Jorn Vernee URL: https://git.openjdk.java.net/panama-foreign/commit/b4cde2e8147c02be482c97706d676ef61e0ee065 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Fix a couple of CI build problems Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/561 From mcimadamore at openjdk.java.net Wed Jun 16 11:16:57 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 16 Jun 2021 11:16:57 GMT Subject: [foreign-memaccess+abi] RFR: 8268743: Require a better way for copying data between MemorySegments and on-heap arrays In-Reply-To: References: Message-ID: On Wed, 16 Jun 2021 10:53:19 GMT, Uwe Schindler wrote: > I will just check both branches separately. First this pull request, if it makes the allocations go away (which looks like it won't). Then the other one. You might also wanna try the one in: https://github.com/openjdk/panama-foreign/pull/555 As you said, the fact that the copy is wrapped in a `@ForceInline` might help. Also, I realized (and that's probably what you were referring to) that the single static copy method would still require wrapping the array in a segment. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/560 From jvernee at openjdk.java.net Wed Jun 16 11:17:49 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 16 Jun 2021 11:17:49 GMT Subject: RFR: Merge jdk:master Message-ID: Manual marge of jdk/master into panama-foreign/master ------------- Commit messages: - Merge branch 'jdk_master' into manual_merge_master - 8268078: ClassListParser::_interfaces should be freed - 8268780: Use 'print_cr' instead of 'print' for the message 'eliminated ' - Merge - 8268768: idea.sh has been updated in surprising and incompatible ways - 8268828: ProblemList compiler/intrinsics/VectorizedMismatchTest.java on win-x64 - 8268723: Problem list SA core file tests on OSX when using ZGC - 8268736: Use apiNote in AutoCloseable.close javadoc - 8263321: Regression 8% in javadoc-steady in 17-b11 - 8268125: ZGC: Clone oop array gets wrong acopy stub - ... and 39 more: https://git.openjdk.java.net/panama-foreign/compare/37791a84...4c996f33 The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.java.net/panama-foreign/pull/562/files Stats: 3848 lines in 141 files changed: 2977 ins; 482 del; 389 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/562.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/562/head:pull/562 PR: https://git.openjdk.java.net/panama-foreign/pull/562 From jvernee at openjdk.java.net Wed Jun 16 11:22:10 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 16 Jun 2021 11:22:10 GMT Subject: RFR: Merge jdk:master [v2] In-Reply-To: References: Message-ID: > Manual marge of jdk/master into panama-foreign/master Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 277 commits: - Merge branch 'jdk_master' into manual_merge_master - Automatic merge of jdk:master into master - Merge Manual merge of jdk/master into panama-foreign/master to pull in 59a539f - Automatic merge of jdk:master into master - Merge Manual merge of jdk/master into panama-foreign/master - Automatic merge of jdk:master into master - Automatic merge of jdk:master into master - Automatic merge of jdk:master into master - Automatic merge of jdk:master into master - Automatic merge of jdk:master into master - ... and 267 more: https://git.openjdk.java.net/panama-foreign/compare/3ad65867...4c996f33 ------------- Changes: https://git.openjdk.java.net/panama-foreign/pull/562/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=562&range=01 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/562.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/562/head:pull/562 PR: https://git.openjdk.java.net/panama-foreign/pull/562 From jvernee at openjdk.java.net Wed Jun 16 11:22:12 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 16 Jun 2021 11:22:12 GMT Subject: Integrated: Merge jdk:master In-Reply-To: References: Message-ID: On Wed, 16 Jun 2021 11:09:48 GMT, Jorn Vernee wrote: > Manual marge of jdk/master into panama-foreign/master This pull request has now been integrated. Changeset: b9e46010 Author: Jorn Vernee URL: https://git.openjdk.java.net/panama-foreign/commit/b9e4601073168a0ddd855def818c7cbf1bf9b1f4 Stats: 3848 lines in 141 files changed: 2977 ins; 482 del; 389 mod Merge manual for of jdk:master -> master ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/562 From duke at openjdk.java.net Wed Jun 16 11:23:00 2021 From: duke at openjdk.java.net (duke) Date: Wed, 16 Jun 2021 11:23:00 GMT Subject: git: openjdk/panama-foreign: foreign-memaccess+abi: 50 new changesets Message-ID: <0ca48319-9a4b-47d8-a4cb-37539c91e105@openjdk.org> Changeset: 49112fa5 Author: ScientificWare Committer: Erik Joelsson Date: 2021-06-11 12:25:37 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/49112fa5752174a77fb5cd276fdd4240bf76bf82 8265909: build.tools.dtdbuilder.DTDBuilder.java failed detecting missing path of dtd_home Reviewed-by: erikj ! make/jdk/src/classes/build/tools/dtdbuilder/DTDBuilder.java Changeset: a466b49e Author: Joe Darcy Date: 2021-06-11 23:10:00 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a466b49e71b0d235294e17faba47ed4fd3fb8f6e 8267634: Update --release 17 symbol information for JDK 17 build 26 Reviewed-by: jjg, iris ! make/data/symbols/java.base-H.sym.txt ! make/data/symbols/jdk.compiler-H.sym.txt ! make/data/symbols/jdk.incubator.foreign-H.sym.txt + make/data/symbols/jdk.incubator.vector-H.sym.txt ! make/data/symbols/jdk.javadoc-H.sym.txt + make/data/symbols/jdk.jfr-H.sym.txt + make/data/symbols/jdk.management.jfr-H.sym.txt ! make/data/symbols/symbols Changeset: 5cee23a9 Author: Yi Yang Date: 2021-06-12 01:03:50 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5cee23a9ed0b7fe2657be7492d9c1f78fcd02ebf 8265518: C1: Intrinsic support for Preconditions.checkIndex Reviewed-by: dfuchs, iveresov ! src/hotspot/share/c1/c1_Compiler.cpp ! src/hotspot/share/c1/c1_LIRGenerator.cpp ! src/hotspot/share/c1/c1_LIRGenerator.hpp ! src/hotspot/share/c1/c1_globals.hpp ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/classfile/javaClasses.hpp ! src/hotspot/share/classfile/vmIntrinsics.cpp ! src/hotspot/share/classfile/vmIntrinsics.hpp ! src/hotspot/share/classfile/vmSymbols.hpp ! src/java.base/share/classes/java/nio/Buffer.java + test/hotspot/jtreg/compiler/c1/TestCheckIndexC1Intrinsic.java Changeset: 90c1034c Author: Daniel D. Daugherty Date: 2021-06-12 13:53:07 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/90c1034cd4077e63afc0aad53191a04699a816ce 8268644: ProblemList serviceability/sa/ClhsdbJstackXcompStress.java in -Xcomp mode Reviewed-by: azvegint ! test/hotspot/jtreg/ProblemList-Xcomp.txt Changeset: 1ba4e0ca Author: David Holmes Date: 2021-06-13 22:16:12 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1ba4e0cada031407a17a665cf24b03bacb59cdbb 8257038: Remove expired flags in JDK 18 Reviewed-by: kbarrett, ccheung ! src/hotspot/share/runtime/arguments.cpp Changeset: ba601b84 Author: Ioi Lam Date: 2021-06-14 05:55:20 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ba601b8407c6d56e48b57a9524a11bb275e08adc 8268520: VirtualSpace::print_on() should be const Reviewed-by: kbarrett, stuefe, tschatzl ! src/hotspot/share/gc/epsilon/epsilonHeap.cpp ! src/hotspot/share/memory/virtualspace.cpp ! src/hotspot/share/memory/virtualspace.hpp Changeset: 51f3427e Author: Rafael Winterhalter Committer: Joel Borggr?n-Franck Date: 2021-06-14 08:24:24 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/51f3427e9bb4a3924a8178338316b9ea30304182 8266791: Annotation property which is compiled as an array property but changed to a single element throws NullPointerException Reviewed-by: darcy, jfranck ! src/java.base/share/classes/sun/reflect/annotation/AnnotationParser.java + test/jdk/java/lang/annotation/AnnotationTypeMismatchException/ArityTypeMismatchTest.java Changeset: c4207355 Author: Markus Gr?nlund Date: 2021-06-14 10:41:00 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c4207355d3fc19687c72f47edf21611ffed7efaf 8267579: Thread::cooked_allocated_bytes() hits assert(left >= right) failed: avoid underflow Reviewed-by: dcubed, stefank, kbarrett ! src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp ! src/hotspot/share/gc/shared/threadLocalAllocBuffer.hpp ! src/hotspot/share/runtime/thread.inline.hpp Changeset: c0b4407d Author: Anton Litvinov Date: 2021-06-14 13:27:59 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c0b4407d09a7bf9f15553dc5344b1e354b150d57 8262731: [macOS] Exception from "Printable.print" is swallowed during "PrinterJob.print" Reviewed-by: prr ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CPrinterJob.java + test/jdk/java/awt/print/PrinterJob/ExceptionFromPrintableIsIgnoredTest.java Changeset: 5b8c51f5 Author: Igor Ignatyev Date: 2021-06-10 17:19:37 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5b8c51f59a5f23930ee43bea30201c1ff88c44cd 8268539: several serviceability/sa tests should be run in driver mode Backport-of: 78cb6776b6d43b67457993a109719b36ee892d60 ! test/hotspot/jtreg/serviceability/sa/CDSJMapClstats.java ! test/hotspot/jtreg/serviceability/sa/ClhsdbDumpclass.java ! test/hotspot/jtreg/serviceability/sa/ClhsdbFlags.java ! test/hotspot/jtreg/serviceability/sa/ClhsdbJstackXcompStress.java ! test/hotspot/jtreg/serviceability/sa/DeadlockDetectionTest.java ! test/hotspot/jtreg/serviceability/sa/JhsdbThreadInfoTest.java ! test/hotspot/jtreg/serviceability/sa/TestCpoolForInvokeDynamic.java ! test/hotspot/jtreg/serviceability/sa/TestDefaultMethods.java ! test/hotspot/jtreg/serviceability/sa/TestHeapDumpForInvokeDynamic.java ! test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackLineNumbers.java ! test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackLock.java ! test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackMixed.java ! test/hotspot/jtreg/serviceability/sa/TestObjectMonitorIterate.java ! test/hotspot/jtreg/serviceability/sa/TestRevPtrsForInvokeDynamic.java ! test/hotspot/jtreg/serviceability/sa/TestSysProps.java ! test/hotspot/jtreg/serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java ! test/hotspot/jtreg/serviceability/sa/sadebugd/ClhsdbAttachToDebugServer.java ! test/hotspot/jtreg/serviceability/sa/sadebugd/ClhsdbTestConnectArgument.java ! test/hotspot/jtreg/serviceability/sa/sadebugd/DebugdConnectTest.java ! test/hotspot/jtreg/serviceability/sa/sadebugd/DisableRegistryTest.java ! test/hotspot/jtreg/serviceability/sa/sadebugd/PmapOnDebugdTest.java ! test/hotspot/jtreg/serviceability/sa/sadebugd/RunCommandOnServerTest.java ! test/hotspot/jtreg/serviceability/sa/sadebugd/SADebugDTest.java Changeset: 53b6e2c8 Author: Igor Ignatyev Date: 2021-06-10 18:05:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/53b6e2c85cab251362d27a1cd0cd37bc7d380360 8267448: Add "ulimit -a" to environment.html Reviewed-by: cjplummer ! test/failure_handler/src/share/conf/linux.properties ! test/failure_handler/src/share/conf/mac.properties ! test/failure_handler/src/share/conf/windows.properties Changeset: 7b2e7d8b Author: Weijun Wang Date: 2021-06-10 22:18:38 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7b2e7d8bab890bd655093976cc9c3b0b6d00c034 8268525: Some new memory leak after JDK-8248268 and JDK-8255557 Reviewed-by: valeriep, ascarpino ! src/java.base/share/classes/com/sun/crypto/provider/CipherCore.java ! src/java.base/share/classes/com/sun/crypto/provider/ConstructKeys.java ! src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java ! src/java.base/share/classes/com/sun/crypto/provider/KWUtil.java ! src/java.base/share/classes/com/sun/crypto/provider/KeyWrapCipher.java Changeset: e3eef3b4 Author: Jie Fu Date: 2021-06-11 02:47:42 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e3eef3b41ab22b3fb1e4ee33ce4a3d3457d35ff1 8268576: jdk/jfr/event/gc/collection/TestSystemGc.java fails Reviewed-by: egahlin, dholmes = test/jdk/jdk/jfr/event/gc/collection/TestSystemGC.java Changeset: bd9c2fa7 Author: Igor Ignatyev Date: 2021-06-11 03:12:50 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bd9c2fa73b61d2461fc44b6056437aee294c9082 8268565: runtime/records/RedefineRecord.java should be run in driver mode Backport-of: 94d0b0f9810bd1a8da06ec267a1c7589d6cb756b ! test/hotspot/jtreg/runtime/records/RedefineRecord.java Changeset: a437ce83 Author: Igor Ignatyev Date: 2021-06-11 05:05:23 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a437ce839f749dab8c42611e0190ece5bea5d255 8268580: runtime/memory/LargePages/TestLargePagesFlags.java should be run in driver mode Reviewed-by: dholmes ! test/hotspot/jtreg/runtime/memory/LargePages/TestLargePagesFlags.java Changeset: da043e99 Author: Daniel Fuchs Date: 2021-06-11 08:42:14 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/da043e99b830fa4fcbfdbdbed182abc394ba6fb1 8268555: Update HttpClient tests that use ITestContext to jtreg 6+1 Reviewed-by: chegar ! test/jdk/java/net/httpclient/AbstractThrowingPublishers.java ! test/jdk/java/net/httpclient/AbstractThrowingPushPromises.java ! test/jdk/java/net/httpclient/AbstractThrowingSubscribers.java ! test/jdk/java/net/httpclient/AggregateRequestBodyTest.java ! test/jdk/java/net/httpclient/CancelRequestTest.java ! test/jdk/java/net/httpclient/ForbiddenHeadTest.java ! test/jdk/java/net/httpclient/ISO_8859_1_Test.java ! test/jdk/java/net/httpclient/ProxySelectorTest.java ! test/jdk/java/net/httpclient/Response204V2Test.java ! test/jdk/java/net/httpclient/ShortResponseBody.java Changeset: cce8da2c Author: Igor Ignatyev Date: 2021-06-11 12:40:44 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/cce8da2c60812873b63de4e65bc992bc6d825fe1 8268602: a couple runtime/os tests don't check exit code Reviewed-by: dholmes ! test/hotspot/jtreg/runtime/os/AvailableProcessors.java ! test/hotspot/jtreg/runtime/os/TestUseCpuAllocPath.java Changeset: e39346e7 Author: Weijun Wang Date: 2021-06-11 15:12:11 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e39346e708a06cdee2b9a096f08c1cfe2e21dfc2 8268093: Manual Testcase: "sun/security/krb5/config/native/TestDynamicStore.java" Fails with NPE Reviewed-by: mullan ! test/jdk/sun/security/krb5/config/native/TestDynamicStore.java ! test/jdk/sun/security/krb5/config/native/libTestDynamicStore.m Changeset: 01054e6f Author: Calvin Cheung Date: 2021-06-11 16:08:18 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/01054e6f5ab75dd1b7d3e82be0eb83f14a7add15 8268470: CDS dynamic dump asserts with JFR RecordingStream Reviewed-by: minqi, iklam ! src/hotspot/share/classfile/systemDictionaryShared.cpp ! src/hotspot/share/classfile/systemDictionaryShared.hpp + test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/JFRDynamicCDS.java + test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/test-classes/JFRDynamicCDSApp.java Changeset: 6171ae45 Author: Daniel D. Daugherty Date: 2021-06-11 20:24:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6171ae455288a74c4c3dcec6983515db04bdc360 8268630: ProblemList serviceability/jvmti/CompiledMethodLoad/Zombie.java on linux-aarch64 Reviewed-by: erikj ! test/hotspot/jtreg/ProblemList.txt Changeset: fe48ea9d Author: Chris Hegarty Date: 2021-06-14 08:29:49 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fe48ea9d7975188853bc165ce29789753f4758f2 8268342: java/foreign/channels/TestAsyncSocketChannels.java fails with "IllegalStateException: This segment is already closed" Reviewed-by: dfuchs ! test/jdk/java/foreign/channels/TestAsyncSocketChannels.java Changeset: b3185354 Author: Markus Gr?nlund Date: 2021-06-14 13:11:33 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b318535452bc0dbc7f8a111a71bb0881833495e1 8267579: Thread::cooked_allocated_bytes() hits assert(left >= right) failed: avoid underflow Backport-of: c4207355d3fc19687c72f47edf21611ffed7efaf ! src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp ! src/hotspot/share/gc/shared/threadLocalAllocBuffer.hpp ! src/hotspot/share/runtime/thread.inline.hpp Changeset: 17295b1b Author: Jesper Wilhelmsson Date: 2021-06-14 15:55:57 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/17295b1bb02b2121978f1459b2e75c5e1031e7ea Merge Reviewed-by: dcubed ! test/failure_handler/src/share/conf/linux.properties ! test/failure_handler/src/share/conf/mac.properties ! test/hotspot/jtreg/ProblemList.txt ! test/failure_handler/src/share/conf/linux.properties ! test/failure_handler/src/share/conf/mac.properties ! test/hotspot/jtreg/ProblemList.txt Changeset: e59acd98 Author: Zhengyu Gu Date: 2021-06-14 18:07:34 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e59acd9860ca9e50c91472f8215f73c17d2099b6 8268699: Shenandoah: Add test for JDK-8268127 Reviewed-by: rkennke + test/hotspot/jtreg/gc/shenandoah/options/TestLargePagesWithSmallHeap.java Changeset: 2e70bc35 Author: Leonid Mesnik Date: 2021-06-14 19:35:24 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2e70bc35dffce47e85f5ca4eaa4c9bdba5afb95b 8268626: Remove native pre-jdk9 support for jtreg failure handler Reviewed-by: erikj ! make/test/BuildFailureHandler.gmk ! test/failure_handler/Makefile ! test/failure_handler/src/share/classes/jdk/test/failurehandler/jtreg/GatherProcessInfoTimeoutHandler.java - test/failure_handler/src/windows/native/libtimeoutHandler/GatherProcessInfoTimeoutHandler.c Changeset: 9f3c7e74 Author: David Holmes Date: 2021-06-15 02:12:57 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9f3c7e74ff00a7550742ed8b9d6671c2d4bb6041 8238649: Call new Win32 API SetThreadDescription in os::set_native_thread_name Co-authored-by: Markus GaisBauer Reviewed-by: stuefe, luhenry ! src/hotspot/os/windows/os_windows.cpp ! test/hotspot/jtreg/runtime/logging/ThreadLoggingTest.java Changeset: d3840932 Author: Nils Eliasson Date: 2021-06-15 08:53:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d384093289561015c69b684a9e21a8c4c1851c4c 8268125: ZGC: Clone oop array gets wrong acopy stub Reviewed-by: kvn, vlivanov ! src/hotspot/share/gc/shared/c2/barrierSetC2.cpp ! src/hotspot/share/gc/z/c2/zBarrierSetC2.cpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/opto/macroArrayCopy.cpp ! test/hotspot/jtreg/compiler/arraycopy/TestObjectArrayClone.java Changeset: 0b09129f Author: Sergey Bylokhov Date: 2021-06-15 15:29:33 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0b09129faefb945c2f2c35dab2731961216d054e 8268620: InfiniteLoopException test may fail on x86 platforms Reviewed-by: prr, trebari, azvegint ! test/jdk/java/awt/Robot/InfiniteLoopException.java Changeset: 00e33a45 Author: Kim Barrett Date: 2021-06-15 22:05:15 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/00e33a45feee1544a9d5be8b2fd1e0987ef1dfc5 8268647: Generation::expand_and_allocate has unused "parallel" argument Reviewed-by: ayang, tschatzl ! src/hotspot/share/gc/serial/defNewGeneration.cpp ! src/hotspot/share/gc/serial/defNewGeneration.hpp ! src/hotspot/share/gc/serial/tenuredGeneration.cpp ! src/hotspot/share/gc/serial/tenuredGeneration.hpp ! src/hotspot/share/gc/shared/generation.hpp Changeset: abe20c18 Author: Jan Lahoda Date: 2021-06-14 14:25:32 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/abe20c188c67a85176f1f1ea530184ce0ec4fe29 8268333: javac crashes when pattern matching switch contains default case which is not last Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java ! test/langtools/tools/javac/patterns/Switches.java Changeset: c088d093 Author: Calvin Cheung Date: 2021-06-14 15:02:55 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c088d093e2e73fd0739d9e96f9f5ea67a01ae06c 8268522: InstanceKlass::can_be_verified_at_dumptime() returns opposite value Reviewed-by: dholmes, minqi, iklam ! src/hotspot/share/cds/metaspaceShared.cpp ! src/hotspot/share/classfile/systemDictionaryShared.cpp ! src/hotspot/share/interpreter/rewriter.cpp ! src/hotspot/share/oops/constantPool.cpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/klass.hpp ! src/hotspot/share/oops/klassVtable.cpp ! src/hotspot/share/oops/method.cpp Changeset: bca914b2 Author: Guoxiong Li Committer: Vicente Romero Date: 2021-06-14 19:02:23 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bca914b29e4cec918d4648fd048139b2c429c27d 8268670: yield statements doesn't allow ~ or ! unary operators in expression Reviewed-by: vromero, jlahoda ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java ! test/langtools/tools/javac/switchexpr/ExpressionSwitch.java Changeset: 702e3ff0 Author: Dean Long Date: 2021-06-14 19:25:49 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/702e3ff05472e35140b38fd5a4d1266f4efdd7bb 8268366: Incorrect calculation of has_fpu_registers in C1 linear scan Reviewed-by: kvn, chagedorn ! src/hotspot/share/c1/c1_LinearScan.cpp + test/hotspot/jtreg/compiler/c1/TestLinearScanHasFPURegisters.java Changeset: ee301596 Author: Valerie Peng Date: 2021-06-14 20:34:44 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ee3015968d56ed6179b6bfbde3f004500dce2ce3 8268621: SunJCE provider may throw unexpected NPE for un-initialized AES KW/KWP Ciphers Reviewed-by: xuelei ! src/java.base/share/classes/com/sun/crypto/provider/AESKeyWrap.java ! src/java.base/share/classes/com/sun/crypto/provider/AESKeyWrapPadded.java ! src/java.base/share/classes/com/sun/crypto/provider/KeyWrapCipher.java ! test/jdk/com/sun/crypto/provider/Cipher/KeyWrap/TestGeneral.java Changeset: f69e2d56 Author: Valerie Peng Date: 2021-06-14 20:40:26 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f69e2d5651f239209543bc1daf707a1c1114f6e5 8267397: AlgorithmId's OID cache is never refreshed Reviewed-by: xuelei ! src/java.base/share/classes/sun/security/jca/Providers.java ! src/java.base/share/classes/sun/security/x509/AlgorithmId.java ! test/jdk/sun/security/x509/AlgorithmId/ExtensibleAlgorithmId.java Changeset: a5bf5e0e Author: David Holmes Date: 2021-06-14 23:02:38 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a5bf5e0e5f6c18b51e398ab81ed9d0a29bf31b6f 8266614: update manpage for -Xlog:async Reviewed-by: hseigel, xliu ! src/java.base/share/man/java.1 Changeset: 4a6da99f Author: Jie Fu Date: 2021-06-14 23:39:41 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4a6da99f28af6bdb8fbb66093ce4386623c77ae2 8268643: SVML lib shouldn't be generated when C2 is absent Reviewed-by: erikj ! make/autoconf/jvm-features.m4 ! make/autoconf/spec.gmk.in ! make/modules/jdk.incubator.vector/Lib.gmk Changeset: 4d8b5c70 Author: Vladimir Kozlov Date: 2021-06-14 23:41:50 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4d8b5c70dff51470210a0ca93b932af1b27c9f27 8268347: C2: nested locks optimization may create unbalanced monitor enter/exit code Reviewed-by: roland, vlivanov, dcubed ! src/hotspot/share/opto/c2compiler.cpp ! src/hotspot/share/opto/c2compiler.hpp ! src/hotspot/share/opto/callnode.cpp ! src/hotspot/share/opto/callnode.hpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/compile.hpp ! src/hotspot/share/opto/locknode.cpp ! src/hotspot/share/opto/locknode.hpp ! src/hotspot/share/opto/macro.cpp ! test/hotspot/jtreg/TEST.groups + test/hotspot/jtreg/compiler/locks/TestNestedLocksElimination.java Changeset: 35d867df Author: Jan Lahoda Date: 2021-06-15 09:04:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/35d867df1f2064e867dcf1030c498bfa23568054 8268663: Crash when guards contain boolean expression Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java ! test/langtools/tools/javac/patterns/Guards.java ! test/langtools/tools/javac/patterns/SwitchErrors.java ! test/langtools/tools/javac/patterns/SwitchErrors.out Changeset: e36136fa Author: Nils Eliasson Date: 2021-06-15 11:33:12 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e36136fa934505fdf7d80ed415ebf009050dac28 8268125: ZGC: Clone oop array gets wrong acopy stub Reviewed-by: vlivanov ! src/hotspot/share/gc/shared/c2/barrierSetC2.cpp ! src/hotspot/share/gc/z/c2/zBarrierSetC2.cpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/opto/macroArrayCopy.cpp ! test/hotspot/jtreg/compiler/arraycopy/TestObjectArrayClone.java Changeset: 76cad4b1 Author: Hannes Walln?fer Date: 2021-06-15 15:56:28 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/76cad4b1ae76c6cc854f7a901736bf108639f8f2 8263321: Regression 8% in javadoc-steady in 17-b11 Reviewed-by: prappo, vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.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/HtmlIds.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/Entity.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/Text.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/CommentHelper.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java Changeset: 31a055e6 Author: Joe Darcy Date: 2021-06-15 18:52:54 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/31a055e67a9a579a6b6ab26519271202da53a295 8268736: Use apiNote in AutoCloseable.close javadoc Reviewed-by: bpb, naoto ! src/java.base/share/classes/java/lang/AutoCloseable.java Changeset: fe7a44de Author: Chris Plummer Date: 2021-06-15 18:59:04 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fe7a44de63f19921e373ff336be26f9165ac6977 8268723: Problem list SA core file tests on OSX when using ZGC Reviewed-by: dholmes, dcubed, sspitsyn ! test/hotspot/jtreg/ProblemList-zgc.txt Changeset: 9ac0609e Author: Daniel D. Daugherty Date: 2021-06-15 20:36:38 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9ac0609ed1513a5c7484ccc2c219fe6cd9c9d6d6 8268828: ProblemList compiler/intrinsics/VectorizedMismatchTest.java on win-x64 Reviewed-by: ccheung ! test/hotspot/jtreg/ProblemList.txt Changeset: 788b3095 Author: Maurizio Cimadamore Date: 2021-06-15 20:37:20 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/788b309563610b690306211790af17954f7556cb 8268768: idea.sh has been updated in surprising and incompatible ways Reviewed-by: erikj ! bin/idea.sh + make/ide/idea/jdk/build.xml ! make/ide/idea/jdk/idea.gmk + make/ide/idea/jdk/template/ant.xml ! make/ide/idea/jdk/template/compiler.xml ! make/ide/idea/jdk/template/jdk.iml ! make/ide/idea/jdk/template/misc.xml ! make/ide/idea/jdk/template/modules.xml + make/ide/idea/jdk/template/src/idea/IdeaLoggerWrapper.java + make/ide/idea/jdk/template/src/idea/JdkIdeaAntLogger.java ! make/ide/idea/jdk/template/vcs.xml ! make/ide/idea/jdk/template/workspace.xml Changeset: e0f6f70d Author: Jesper Wilhelmsson Date: 2021-06-15 22:45:28 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e0f6f70d3f9e748d2bc53f371beca487e9343d4a Merge ! test/hotspot/jtreg/ProblemList.txt ! test/hotspot/jtreg/ProblemList.txt Changeset: 48d45628 Author: Denghui Dong Committer: Yi Yang Date: 2021-06-16 02:08:37 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/48d456281ea73e22eaaae6a082bb43610647d660 8268780: Use 'print_cr' instead of 'print' for the message 'eliminated ' Reviewed-by: cjplummer, zgu, dcubed ! src/hotspot/share/runtime/vframe.cpp Changeset: 3ad65867 Author: Calvin Cheung Date: 2021-06-16 02:17:41 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3ad658677b1ad2ea15d75ec7f1fe71e37f3913b9 8268078: ClassListParser::_interfaces should be freed Reviewed-by: minqi, iklam, coleenp ! src/hotspot/share/cds/classListParser.cpp Changeset: b9e46010 Author: Jorn Vernee Date: 2021-06-16 11:18:26 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b9e4601073168a0ddd855def818c7cbf1bf9b1f4 Merge manual for of jdk:master -> master Changeset: 0d9d64da Author: duke Date: 2021-06-16 11:19:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0d9d64da3f9e2a7a3fb7ed714ae89d6d0a3c9c87 Automatic merge of master into foreign-memaccess+abi From duke at openjdk.java.net Wed Jun 16 11:30:11 2021 From: duke at openjdk.java.net (duke) Date: Wed, 16 Jun 2021 11:30:11 GMT Subject: git: openjdk/panama-foreign: foreign-jextract: 51 new changesets Message-ID: Changeset: 49112fa5 Author: ScientificWare Committer: Erik Joelsson Date: 2021-06-11 12:25:37 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/49112fa5752174a77fb5cd276fdd4240bf76bf82 8265909: build.tools.dtdbuilder.DTDBuilder.java failed detecting missing path of dtd_home Reviewed-by: erikj ! make/jdk/src/classes/build/tools/dtdbuilder/DTDBuilder.java Changeset: a466b49e Author: Joe Darcy Date: 2021-06-11 23:10:00 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a466b49e71b0d235294e17faba47ed4fd3fb8f6e 8267634: Update --release 17 symbol information for JDK 17 build 26 Reviewed-by: jjg, iris ! make/data/symbols/java.base-H.sym.txt ! make/data/symbols/jdk.compiler-H.sym.txt ! make/data/symbols/jdk.incubator.foreign-H.sym.txt + make/data/symbols/jdk.incubator.vector-H.sym.txt ! make/data/symbols/jdk.javadoc-H.sym.txt + make/data/symbols/jdk.jfr-H.sym.txt + make/data/symbols/jdk.management.jfr-H.sym.txt ! make/data/symbols/symbols Changeset: 5cee23a9 Author: Yi Yang Date: 2021-06-12 01:03:50 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5cee23a9ed0b7fe2657be7492d9c1f78fcd02ebf 8265518: C1: Intrinsic support for Preconditions.checkIndex Reviewed-by: dfuchs, iveresov ! src/hotspot/share/c1/c1_Compiler.cpp ! src/hotspot/share/c1/c1_LIRGenerator.cpp ! src/hotspot/share/c1/c1_LIRGenerator.hpp ! src/hotspot/share/c1/c1_globals.hpp ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/classfile/javaClasses.hpp ! src/hotspot/share/classfile/vmIntrinsics.cpp ! src/hotspot/share/classfile/vmIntrinsics.hpp ! src/hotspot/share/classfile/vmSymbols.hpp ! src/java.base/share/classes/java/nio/Buffer.java + test/hotspot/jtreg/compiler/c1/TestCheckIndexC1Intrinsic.java Changeset: 90c1034c Author: Daniel D. Daugherty Date: 2021-06-12 13:53:07 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/90c1034cd4077e63afc0aad53191a04699a816ce 8268644: ProblemList serviceability/sa/ClhsdbJstackXcompStress.java in -Xcomp mode Reviewed-by: azvegint ! test/hotspot/jtreg/ProblemList-Xcomp.txt Changeset: 1ba4e0ca Author: David Holmes Date: 2021-06-13 22:16:12 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1ba4e0cada031407a17a665cf24b03bacb59cdbb 8257038: Remove expired flags in JDK 18 Reviewed-by: kbarrett, ccheung ! src/hotspot/share/runtime/arguments.cpp Changeset: ba601b84 Author: Ioi Lam Date: 2021-06-14 05:55:20 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ba601b8407c6d56e48b57a9524a11bb275e08adc 8268520: VirtualSpace::print_on() should be const Reviewed-by: kbarrett, stuefe, tschatzl ! src/hotspot/share/gc/epsilon/epsilonHeap.cpp ! src/hotspot/share/memory/virtualspace.cpp ! src/hotspot/share/memory/virtualspace.hpp Changeset: 51f3427e Author: Rafael Winterhalter Committer: Joel Borggr?n-Franck Date: 2021-06-14 08:24:24 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/51f3427e9bb4a3924a8178338316b9ea30304182 8266791: Annotation property which is compiled as an array property but changed to a single element throws NullPointerException Reviewed-by: darcy, jfranck ! src/java.base/share/classes/sun/reflect/annotation/AnnotationParser.java + test/jdk/java/lang/annotation/AnnotationTypeMismatchException/ArityTypeMismatchTest.java Changeset: c4207355 Author: Markus Gr?nlund Date: 2021-06-14 10:41:00 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c4207355d3fc19687c72f47edf21611ffed7efaf 8267579: Thread::cooked_allocated_bytes() hits assert(left >= right) failed: avoid underflow Reviewed-by: dcubed, stefank, kbarrett ! src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp ! src/hotspot/share/gc/shared/threadLocalAllocBuffer.hpp ! src/hotspot/share/runtime/thread.inline.hpp Changeset: c0b4407d Author: Anton Litvinov Date: 2021-06-14 13:27:59 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c0b4407d09a7bf9f15553dc5344b1e354b150d57 8262731: [macOS] Exception from "Printable.print" is swallowed during "PrinterJob.print" Reviewed-by: prr ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CPrinterJob.java + test/jdk/java/awt/print/PrinterJob/ExceptionFromPrintableIsIgnoredTest.java Changeset: 5b8c51f5 Author: Igor Ignatyev Date: 2021-06-10 17:19:37 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5b8c51f59a5f23930ee43bea30201c1ff88c44cd 8268539: several serviceability/sa tests should be run in driver mode Backport-of: 78cb6776b6d43b67457993a109719b36ee892d60 ! test/hotspot/jtreg/serviceability/sa/CDSJMapClstats.java ! test/hotspot/jtreg/serviceability/sa/ClhsdbDumpclass.java ! test/hotspot/jtreg/serviceability/sa/ClhsdbFlags.java ! test/hotspot/jtreg/serviceability/sa/ClhsdbJstackXcompStress.java ! test/hotspot/jtreg/serviceability/sa/DeadlockDetectionTest.java ! test/hotspot/jtreg/serviceability/sa/JhsdbThreadInfoTest.java ! test/hotspot/jtreg/serviceability/sa/TestCpoolForInvokeDynamic.java ! test/hotspot/jtreg/serviceability/sa/TestDefaultMethods.java ! test/hotspot/jtreg/serviceability/sa/TestHeapDumpForInvokeDynamic.java ! test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackLineNumbers.java ! test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackLock.java ! test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackMixed.java ! test/hotspot/jtreg/serviceability/sa/TestObjectMonitorIterate.java ! test/hotspot/jtreg/serviceability/sa/TestRevPtrsForInvokeDynamic.java ! test/hotspot/jtreg/serviceability/sa/TestSysProps.java ! test/hotspot/jtreg/serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java ! test/hotspot/jtreg/serviceability/sa/sadebugd/ClhsdbAttachToDebugServer.java ! test/hotspot/jtreg/serviceability/sa/sadebugd/ClhsdbTestConnectArgument.java ! test/hotspot/jtreg/serviceability/sa/sadebugd/DebugdConnectTest.java ! test/hotspot/jtreg/serviceability/sa/sadebugd/DisableRegistryTest.java ! test/hotspot/jtreg/serviceability/sa/sadebugd/PmapOnDebugdTest.java ! test/hotspot/jtreg/serviceability/sa/sadebugd/RunCommandOnServerTest.java ! test/hotspot/jtreg/serviceability/sa/sadebugd/SADebugDTest.java Changeset: 53b6e2c8 Author: Igor Ignatyev Date: 2021-06-10 18:05:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/53b6e2c85cab251362d27a1cd0cd37bc7d380360 8267448: Add "ulimit -a" to environment.html Reviewed-by: cjplummer ! test/failure_handler/src/share/conf/linux.properties ! test/failure_handler/src/share/conf/mac.properties ! test/failure_handler/src/share/conf/windows.properties Changeset: 7b2e7d8b Author: Weijun Wang Date: 2021-06-10 22:18:38 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7b2e7d8bab890bd655093976cc9c3b0b6d00c034 8268525: Some new memory leak after JDK-8248268 and JDK-8255557 Reviewed-by: valeriep, ascarpino ! src/java.base/share/classes/com/sun/crypto/provider/CipherCore.java ! src/java.base/share/classes/com/sun/crypto/provider/ConstructKeys.java ! src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java ! src/java.base/share/classes/com/sun/crypto/provider/KWUtil.java ! src/java.base/share/classes/com/sun/crypto/provider/KeyWrapCipher.java Changeset: e3eef3b4 Author: Jie Fu Date: 2021-06-11 02:47:42 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e3eef3b41ab22b3fb1e4ee33ce4a3d3457d35ff1 8268576: jdk/jfr/event/gc/collection/TestSystemGc.java fails Reviewed-by: egahlin, dholmes = test/jdk/jdk/jfr/event/gc/collection/TestSystemGC.java Changeset: bd9c2fa7 Author: Igor Ignatyev Date: 2021-06-11 03:12:50 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bd9c2fa73b61d2461fc44b6056437aee294c9082 8268565: runtime/records/RedefineRecord.java should be run in driver mode Backport-of: 94d0b0f9810bd1a8da06ec267a1c7589d6cb756b ! test/hotspot/jtreg/runtime/records/RedefineRecord.java Changeset: a437ce83 Author: Igor Ignatyev Date: 2021-06-11 05:05:23 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a437ce839f749dab8c42611e0190ece5bea5d255 8268580: runtime/memory/LargePages/TestLargePagesFlags.java should be run in driver mode Reviewed-by: dholmes ! test/hotspot/jtreg/runtime/memory/LargePages/TestLargePagesFlags.java Changeset: da043e99 Author: Daniel Fuchs Date: 2021-06-11 08:42:14 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/da043e99b830fa4fcbfdbdbed182abc394ba6fb1 8268555: Update HttpClient tests that use ITestContext to jtreg 6+1 Reviewed-by: chegar ! test/jdk/java/net/httpclient/AbstractThrowingPublishers.java ! test/jdk/java/net/httpclient/AbstractThrowingPushPromises.java ! test/jdk/java/net/httpclient/AbstractThrowingSubscribers.java ! test/jdk/java/net/httpclient/AggregateRequestBodyTest.java ! test/jdk/java/net/httpclient/CancelRequestTest.java ! test/jdk/java/net/httpclient/ForbiddenHeadTest.java ! test/jdk/java/net/httpclient/ISO_8859_1_Test.java ! test/jdk/java/net/httpclient/ProxySelectorTest.java ! test/jdk/java/net/httpclient/Response204V2Test.java ! test/jdk/java/net/httpclient/ShortResponseBody.java Changeset: cce8da2c Author: Igor Ignatyev Date: 2021-06-11 12:40:44 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/cce8da2c60812873b63de4e65bc992bc6d825fe1 8268602: a couple runtime/os tests don't check exit code Reviewed-by: dholmes ! test/hotspot/jtreg/runtime/os/AvailableProcessors.java ! test/hotspot/jtreg/runtime/os/TestUseCpuAllocPath.java Changeset: e39346e7 Author: Weijun Wang Date: 2021-06-11 15:12:11 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e39346e708a06cdee2b9a096f08c1cfe2e21dfc2 8268093: Manual Testcase: "sun/security/krb5/config/native/TestDynamicStore.java" Fails with NPE Reviewed-by: mullan ! test/jdk/sun/security/krb5/config/native/TestDynamicStore.java ! test/jdk/sun/security/krb5/config/native/libTestDynamicStore.m Changeset: 01054e6f Author: Calvin Cheung Date: 2021-06-11 16:08:18 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/01054e6f5ab75dd1b7d3e82be0eb83f14a7add15 8268470: CDS dynamic dump asserts with JFR RecordingStream Reviewed-by: minqi, iklam ! src/hotspot/share/classfile/systemDictionaryShared.cpp ! src/hotspot/share/classfile/systemDictionaryShared.hpp + test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/JFRDynamicCDS.java + test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/test-classes/JFRDynamicCDSApp.java Changeset: 6171ae45 Author: Daniel D. Daugherty Date: 2021-06-11 20:24:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6171ae455288a74c4c3dcec6983515db04bdc360 8268630: ProblemList serviceability/jvmti/CompiledMethodLoad/Zombie.java on linux-aarch64 Reviewed-by: erikj ! test/hotspot/jtreg/ProblemList.txt Changeset: fe48ea9d Author: Chris Hegarty Date: 2021-06-14 08:29:49 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fe48ea9d7975188853bc165ce29789753f4758f2 8268342: java/foreign/channels/TestAsyncSocketChannels.java fails with "IllegalStateException: This segment is already closed" Reviewed-by: dfuchs ! test/jdk/java/foreign/channels/TestAsyncSocketChannels.java Changeset: b3185354 Author: Markus Gr?nlund Date: 2021-06-14 13:11:33 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b318535452bc0dbc7f8a111a71bb0881833495e1 8267579: Thread::cooked_allocated_bytes() hits assert(left >= right) failed: avoid underflow Backport-of: c4207355d3fc19687c72f47edf21611ffed7efaf ! src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp ! src/hotspot/share/gc/shared/threadLocalAllocBuffer.hpp ! src/hotspot/share/runtime/thread.inline.hpp Changeset: 17295b1b Author: Jesper Wilhelmsson Date: 2021-06-14 15:55:57 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/17295b1bb02b2121978f1459b2e75c5e1031e7ea Merge Reviewed-by: dcubed ! test/failure_handler/src/share/conf/linux.properties ! test/failure_handler/src/share/conf/mac.properties ! test/hotspot/jtreg/ProblemList.txt ! test/failure_handler/src/share/conf/linux.properties ! test/failure_handler/src/share/conf/mac.properties ! test/hotspot/jtreg/ProblemList.txt Changeset: e59acd98 Author: Zhengyu Gu Date: 2021-06-14 18:07:34 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e59acd9860ca9e50c91472f8215f73c17d2099b6 8268699: Shenandoah: Add test for JDK-8268127 Reviewed-by: rkennke + test/hotspot/jtreg/gc/shenandoah/options/TestLargePagesWithSmallHeap.java Changeset: 2e70bc35 Author: Leonid Mesnik Date: 2021-06-14 19:35:24 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2e70bc35dffce47e85f5ca4eaa4c9bdba5afb95b 8268626: Remove native pre-jdk9 support for jtreg failure handler Reviewed-by: erikj ! make/test/BuildFailureHandler.gmk ! test/failure_handler/Makefile ! test/failure_handler/src/share/classes/jdk/test/failurehandler/jtreg/GatherProcessInfoTimeoutHandler.java - test/failure_handler/src/windows/native/libtimeoutHandler/GatherProcessInfoTimeoutHandler.c Changeset: 9f3c7e74 Author: David Holmes Date: 2021-06-15 02:12:57 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9f3c7e74ff00a7550742ed8b9d6671c2d4bb6041 8238649: Call new Win32 API SetThreadDescription in os::set_native_thread_name Co-authored-by: Markus GaisBauer Reviewed-by: stuefe, luhenry ! src/hotspot/os/windows/os_windows.cpp ! test/hotspot/jtreg/runtime/logging/ThreadLoggingTest.java Changeset: d3840932 Author: Nils Eliasson Date: 2021-06-15 08:53:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d384093289561015c69b684a9e21a8c4c1851c4c 8268125: ZGC: Clone oop array gets wrong acopy stub Reviewed-by: kvn, vlivanov ! src/hotspot/share/gc/shared/c2/barrierSetC2.cpp ! src/hotspot/share/gc/z/c2/zBarrierSetC2.cpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/opto/macroArrayCopy.cpp ! test/hotspot/jtreg/compiler/arraycopy/TestObjectArrayClone.java Changeset: 0b09129f Author: Sergey Bylokhov Date: 2021-06-15 15:29:33 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0b09129faefb945c2f2c35dab2731961216d054e 8268620: InfiniteLoopException test may fail on x86 platforms Reviewed-by: prr, trebari, azvegint ! test/jdk/java/awt/Robot/InfiniteLoopException.java Changeset: 00e33a45 Author: Kim Barrett Date: 2021-06-15 22:05:15 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/00e33a45feee1544a9d5be8b2fd1e0987ef1dfc5 8268647: Generation::expand_and_allocate has unused "parallel" argument Reviewed-by: ayang, tschatzl ! src/hotspot/share/gc/serial/defNewGeneration.cpp ! src/hotspot/share/gc/serial/defNewGeneration.hpp ! src/hotspot/share/gc/serial/tenuredGeneration.cpp ! src/hotspot/share/gc/serial/tenuredGeneration.hpp ! src/hotspot/share/gc/shared/generation.hpp Changeset: abe20c18 Author: Jan Lahoda Date: 2021-06-14 14:25:32 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/abe20c188c67a85176f1f1ea530184ce0ec4fe29 8268333: javac crashes when pattern matching switch contains default case which is not last Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java ! test/langtools/tools/javac/patterns/Switches.java Changeset: c088d093 Author: Calvin Cheung Date: 2021-06-14 15:02:55 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c088d093e2e73fd0739d9e96f9f5ea67a01ae06c 8268522: InstanceKlass::can_be_verified_at_dumptime() returns opposite value Reviewed-by: dholmes, minqi, iklam ! src/hotspot/share/cds/metaspaceShared.cpp ! src/hotspot/share/classfile/systemDictionaryShared.cpp ! src/hotspot/share/interpreter/rewriter.cpp ! src/hotspot/share/oops/constantPool.cpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/klass.hpp ! src/hotspot/share/oops/klassVtable.cpp ! src/hotspot/share/oops/method.cpp Changeset: bca914b2 Author: Guoxiong Li Committer: Vicente Romero Date: 2021-06-14 19:02:23 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bca914b29e4cec918d4648fd048139b2c429c27d 8268670: yield statements doesn't allow ~ or ! unary operators in expression Reviewed-by: vromero, jlahoda ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java ! test/langtools/tools/javac/switchexpr/ExpressionSwitch.java Changeset: 702e3ff0 Author: Dean Long Date: 2021-06-14 19:25:49 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/702e3ff05472e35140b38fd5a4d1266f4efdd7bb 8268366: Incorrect calculation of has_fpu_registers in C1 linear scan Reviewed-by: kvn, chagedorn ! src/hotspot/share/c1/c1_LinearScan.cpp + test/hotspot/jtreg/compiler/c1/TestLinearScanHasFPURegisters.java Changeset: ee301596 Author: Valerie Peng Date: 2021-06-14 20:34:44 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ee3015968d56ed6179b6bfbde3f004500dce2ce3 8268621: SunJCE provider may throw unexpected NPE for un-initialized AES KW/KWP Ciphers Reviewed-by: xuelei ! src/java.base/share/classes/com/sun/crypto/provider/AESKeyWrap.java ! src/java.base/share/classes/com/sun/crypto/provider/AESKeyWrapPadded.java ! src/java.base/share/classes/com/sun/crypto/provider/KeyWrapCipher.java ! test/jdk/com/sun/crypto/provider/Cipher/KeyWrap/TestGeneral.java Changeset: f69e2d56 Author: Valerie Peng Date: 2021-06-14 20:40:26 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f69e2d5651f239209543bc1daf707a1c1114f6e5 8267397: AlgorithmId's OID cache is never refreshed Reviewed-by: xuelei ! src/java.base/share/classes/sun/security/jca/Providers.java ! src/java.base/share/classes/sun/security/x509/AlgorithmId.java ! test/jdk/sun/security/x509/AlgorithmId/ExtensibleAlgorithmId.java Changeset: a5bf5e0e Author: David Holmes Date: 2021-06-14 23:02:38 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a5bf5e0e5f6c18b51e398ab81ed9d0a29bf31b6f 8266614: update manpage for -Xlog:async Reviewed-by: hseigel, xliu ! src/java.base/share/man/java.1 Changeset: 4a6da99f Author: Jie Fu Date: 2021-06-14 23:39:41 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4a6da99f28af6bdb8fbb66093ce4386623c77ae2 8268643: SVML lib shouldn't be generated when C2 is absent Reviewed-by: erikj ! make/autoconf/jvm-features.m4 ! make/autoconf/spec.gmk.in ! make/modules/jdk.incubator.vector/Lib.gmk Changeset: 4d8b5c70 Author: Vladimir Kozlov Date: 2021-06-14 23:41:50 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4d8b5c70dff51470210a0ca93b932af1b27c9f27 8268347: C2: nested locks optimization may create unbalanced monitor enter/exit code Reviewed-by: roland, vlivanov, dcubed ! src/hotspot/share/opto/c2compiler.cpp ! src/hotspot/share/opto/c2compiler.hpp ! src/hotspot/share/opto/callnode.cpp ! src/hotspot/share/opto/callnode.hpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/compile.hpp ! src/hotspot/share/opto/locknode.cpp ! src/hotspot/share/opto/locknode.hpp ! src/hotspot/share/opto/macro.cpp ! test/hotspot/jtreg/TEST.groups + test/hotspot/jtreg/compiler/locks/TestNestedLocksElimination.java Changeset: 35d867df Author: Jan Lahoda Date: 2021-06-15 09:04:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/35d867df1f2064e867dcf1030c498bfa23568054 8268663: Crash when guards contain boolean expression Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java ! test/langtools/tools/javac/patterns/Guards.java ! test/langtools/tools/javac/patterns/SwitchErrors.java ! test/langtools/tools/javac/patterns/SwitchErrors.out Changeset: e36136fa Author: Nils Eliasson Date: 2021-06-15 11:33:12 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e36136fa934505fdf7d80ed415ebf009050dac28 8268125: ZGC: Clone oop array gets wrong acopy stub Reviewed-by: vlivanov ! src/hotspot/share/gc/shared/c2/barrierSetC2.cpp ! src/hotspot/share/gc/z/c2/zBarrierSetC2.cpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/opto/macroArrayCopy.cpp ! test/hotspot/jtreg/compiler/arraycopy/TestObjectArrayClone.java Changeset: 76cad4b1 Author: Hannes Walln?fer Date: 2021-06-15 15:56:28 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/76cad4b1ae76c6cc854f7a901736bf108639f8f2 8263321: Regression 8% in javadoc-steady in 17-b11 Reviewed-by: prappo, vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.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/HtmlIds.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/Entity.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/Text.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/CommentHelper.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java Changeset: 31a055e6 Author: Joe Darcy Date: 2021-06-15 18:52:54 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/31a055e67a9a579a6b6ab26519271202da53a295 8268736: Use apiNote in AutoCloseable.close javadoc Reviewed-by: bpb, naoto ! src/java.base/share/classes/java/lang/AutoCloseable.java Changeset: fe7a44de Author: Chris Plummer Date: 2021-06-15 18:59:04 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fe7a44de63f19921e373ff336be26f9165ac6977 8268723: Problem list SA core file tests on OSX when using ZGC Reviewed-by: dholmes, dcubed, sspitsyn ! test/hotspot/jtreg/ProblemList-zgc.txt Changeset: 9ac0609e Author: Daniel D. Daugherty Date: 2021-06-15 20:36:38 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9ac0609ed1513a5c7484ccc2c219fe6cd9c9d6d6 8268828: ProblemList compiler/intrinsics/VectorizedMismatchTest.java on win-x64 Reviewed-by: ccheung ! test/hotspot/jtreg/ProblemList.txt Changeset: 788b3095 Author: Maurizio Cimadamore Date: 2021-06-15 20:37:20 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/788b309563610b690306211790af17954f7556cb 8268768: idea.sh has been updated in surprising and incompatible ways Reviewed-by: erikj ! bin/idea.sh + make/ide/idea/jdk/build.xml ! make/ide/idea/jdk/idea.gmk + make/ide/idea/jdk/template/ant.xml ! make/ide/idea/jdk/template/compiler.xml ! make/ide/idea/jdk/template/jdk.iml ! make/ide/idea/jdk/template/misc.xml ! make/ide/idea/jdk/template/modules.xml + make/ide/idea/jdk/template/src/idea/IdeaLoggerWrapper.java + make/ide/idea/jdk/template/src/idea/JdkIdeaAntLogger.java ! make/ide/idea/jdk/template/vcs.xml ! make/ide/idea/jdk/template/workspace.xml Changeset: e0f6f70d Author: Jesper Wilhelmsson Date: 2021-06-15 22:45:28 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e0f6f70d3f9e748d2bc53f371beca487e9343d4a Merge ! test/hotspot/jtreg/ProblemList.txt ! test/hotspot/jtreg/ProblemList.txt Changeset: 48d45628 Author: Denghui Dong Committer: Yi Yang Date: 2021-06-16 02:08:37 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/48d456281ea73e22eaaae6a082bb43610647d660 8268780: Use 'print_cr' instead of 'print' for the message 'eliminated ' Reviewed-by: cjplummer, zgu, dcubed ! src/hotspot/share/runtime/vframe.cpp Changeset: 3ad65867 Author: Calvin Cheung Date: 2021-06-16 02:17:41 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3ad658677b1ad2ea15d75ec7f1fe71e37f3913b9 8268078: ClassListParser::_interfaces should be freed Reviewed-by: minqi, iklam, coleenp ! src/hotspot/share/cds/classListParser.cpp Changeset: b9e46010 Author: Jorn Vernee Date: 2021-06-16 11:18:26 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b9e4601073168a0ddd855def818c7cbf1bf9b1f4 Merge manual for of jdk:master -> master Changeset: 0d9d64da Author: duke Date: 2021-06-16 11:19:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0d9d64da3f9e2a7a3fb7ed714ae89d6d0a3c9c87 Automatic merge of master into foreign-memaccess+abi Changeset: 985a77af Author: duke Date: 2021-06-16 11:20:02 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/985a77afa045336ccc0c658aa43b6017234114f2 Automatic merge of foreign-memaccess+abi into foreign-jextract ! make/autoconf/spec.gmk.in ! make/autoconf/spec.gmk.in From maurizio.cimadamore at oracle.com Wed Jun 16 15:56:12 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 16 Jun 2021 16:56:12 +0100 Subject: Memory Segment efficient array handling In-Reply-To: References: <08a001d726ec$f3bd0f30$db372d90$@apache.org> <5d67aba5-e7c8-620c-41ec-0daf396f0d96@oracle.com> <04e101d761c8$67896510$369c2f30$@apache.org> <265ceecd-941a-127b-e2e7-5462f190291c@oracle.com> <06d701d761d1$21bb6f70$65324e50$@apache.org> <7659efda-ed64-093b-c69b-b5af767768c1@oracle.com> <073701d761de$e8317bb0$b8947310$@apache.org> Message-ID: Hi Lee, I've updated the PR with your latest changes. Everything works fine - there were some trailing whitespaces that I fixed, other than that the test works ok. Maurizio On 15/06/2021 20:06, leerho wrote: > Maurizio, > I have updated the *MemoryCopy* and *TestMemoryCopy* to include > references to the new *MemorySegment::CopyFrom(...)* and with byte > swap capabilities. > > I have been able to test the code in my local environment using a mock > substitute for the new CopyFrom(), but alas, I could not get Jtreg to > work, so i am sending you the code as updated in > https://github.com/leerho/mcimadamore_panama-foreign > > > Please test it, when you have a chance. > > Lee. > > > On Tue, Jun 15, 2021 at 5:43 AM Maurizio Cimadamore > > wrote: > > > >> The reason why copying is slower for small segments is that, I > think, my > >> benchmark iterations run in 4-5ns and, at these levels, you are > >> sensitive to the cost of the liveness checks. There's not a lot > we can > >> do to eliminate that - it's the price of safety. > > OK that's true. But in my own Unsafe.copyMemory code wasn't > doing MemorySegment.address().toRawLongValue() not also doing the > liveness check? > True - so the liveness check probably that won't make a lot of > difference in your case. But note that the bound checks are still > applied in MemorySegment::copyMemory. > > > >> The good news is that in the case of heap segment wrappers, we know > >> exactly that the size is gonna fit inside an int (it's an array > after > >> all!), so we can remove the check. If we remove the flag check, > and just > >> set the segment to always be treated as "SMALL", we get the > following > >> results: > > Is this really true? What about a huge long[] array, that could > be (2^31-8 maximum index) * 8 bytesPerLong = 16 gigabytes? (or are > those limited by the Java standard in maximum array size?) > in the PR I've submitted I only tweaked byte segment wrappers. We > could > resort to more complex internal representation for other heap > segments, > but I believe the true way forward is to wait for the long > optimizations, and to completely remove the SMALL segment hacks. > > > > Sorry, I missed that class. I was opening the pull request and > only looked at the red/green changes in MemorySegment. I missed > the first class. > > > > The methods provided there exactly replace my three shapes in > the code. And on top they allow to swap. Side note: MemoryCopy in > the current PR has the swapping code commented out. > Yeah - Lee is working on that MemoryCopy class (and associated > test). I > have provided the "swappy" copyFrom overload in MemorySegment, I > believe > Lee will add support for that soon. > > > > Last question: why does > https://bugs.openjdk.java.net/browse/JDK-8223051 > not help for > the integer vs. long loop variables? Does this not allow to remove > the small vs. large segment distinction? I thought this change in > hotspot was added to support long loops, if it is in fact "small". > > My understanding is that the change has been split in multiple > chunks. > The chunk we mostly depend on is this: > > https://bugs.openjdk.java.net/browse/JDK-8259609 > > > (in fact I'm coordinating with Roland, the author of that work, > and he's > testing the patch against a version of panama which doesn't have > workarounds for small segments). > > I did run all Panama benchmarks after JDK-8223051 was pushed, and > removed various workarounds, but? there was still a performance gap. > Roland reassured me that the gap should disappear once JDK-8259609 is > pushed. > > Maurizio > > > > > Uwe > > > From leerho at gmail.com Wed Jun 16 19:06:10 2021 From: leerho at gmail.com (leerho) Date: Wed, 16 Jun 2021 12:06:10 -0700 Subject: Propose 2 new methods for MemorySegment In-Reply-To: References: Message-ID: Maurizio, Well, I learned yet another corner of the API I hadn't found: *MemoryAddress::segmentOffset()* :) However, having the boolean i*sSameBaseResource(MemorySegment other)* would still be very useful! Having to catch exceptions in order to understand some basic properties of a segment (or a pair of them) is a real nuisance. As the API stands currently, given two segments: 1. If they are both independently allocated on-heap the segmentOffset() throws an exception. 2. If one is on-heap and the other off-heap segmentOffset() throws an exception. 3. If they are both independently allocated *off-heap* segmentOffset *does not* throw an exception! If you had the method i*sSameBaseResource(MemorySegment other)*: 1. would return false 2. would return false 3. would return true (since the segmentOffset works in this case). 4. Also, if both segments are descendants of a common ancestor segment, it would return true This would make handling of moving data between segments so much more straightforward. I revise my request to just add the first method: - MemorySegment::boolean isSameBaseResource(MemorySegment other); The intent is to reveal if *this* segment and the *other* segment share a common ancestor segment. ["It could also be extended to determine if the two segments share the same memory-mapped file (a true resource), thus possibly removing the caveat in paragraph 2 above". -- this may not be possible ] Now whether this removes your paragraph 2 caveat (at the top), I'm not sure. Perhaps the caveat is because memory regions of a memory-mapped file can be swapped out at any time, making any assumptions about sub-regions and offsets rather meaningless? Are there other reasons? Lee. On Wed, Jun 16, 2021 at 1:43 AM Maurizio Cimadamore < maurizio.cimadamore at oracle.com> wrote: > I see what you mean. > > I wonder if this use case isn't already partially covered by > MemoryAddress::segmentOffset. > > E.g. can you do: > > long otherOffset = segment.address().segmentOffset(otherSegment); > > Then it should be easy to check if the offset is within the bounds of > "otherSegment" ? > > (Note that the method already throws if you try to compare addresses and > segments that are mismatched - e.g. on-heap vs. off-heap). > > Not saying a more direct API is ruled out, just pointing out what we > have to see if it can be used. > > Maurizio > > > On 16/06/2021 02:37, leerho wrote: > > In working on https://github.com/openjdk/panama-foreign/pull/555, which > is > > the PR for Memory Segment Efficient Array Handling, I discovered that > there > > are two methods that would be very useful beyond copying arrays, but > useful > > in other types of data movement operations between MemorySegments. > > > > I'd like to draw attention to the opening Javadoc of the > > *MemorySegment::copyFrom(MemorySegment)* method: > > > > 1. Performs a bulk copy from given source segment to this segment. More > >> specifically, the bytes at offset 0 through src.byteSize() - 1 in the > >> source segment are copied into this segment at offset 0 through > src.byteSize() > >> - 1. If the source segment overlaps with this segment, then the copying > >> is performed as if the bytes at offset 0 through src.byteSize() - 1 in > >> the source segment were first copied into a temporary segment with size > >> bytes, and then the contents of the temporary segment were copied into > >> this segment at offset 0 through src.byteSize() - 1. > >> > >> 2. The result of a bulk copy is unspecified if, in the uncommon case, > the > >> source segment and this segment do not overlap, but refer to overlapping > >> regions of the same backing storage using different addresses. For > example, > >> this may occur if the same file is mapped > >> > <#mapFile(java.nio.file.Path,long,long,java.nio.channels.FileChannel.MapMode,jdk.incubator.foreign.ResourceScope)> > to > >> two segments. > >> > > The first paragraph is a guarantee that even if two descendant segments > > have an overlapping region with a parent segment that the copy operation > > will work properly. This is similar to the guarantee of > System.arrayCopy() > > > > The second paragraph refers to memory-mapped files. However, let's > examine > > the following scenario: > > > > - A hierarchy of Memory Segments where two descendant segments may > > overlap a region of the parent segment. > > - The elements of the segments are more complex than Java primitives > > (thus, PR 555 doesn't apply). > > - The user wishes to copy a region of elements from one of the > > descendant segments to the other descendant segment. > > - The user only has the two descendant segments in hand and does not > > have access to the parent segment. > > > > With the current MemorySegment API, the descendant segments are blind to > > the overlap, to wit: > > > > - The user cannot determine if an overlap exists. > > - Or, if an overlap exists where the overlap is with respect to the > two > > segments in hand. > > > > In order to ensure that corruption doesn't occur during the copy, the > user > > must create a temporary duplicate of the destination segment, copy the > data > > into the duplicate, then copy the duplicate into the original destination > > segment. This can be expensive in time and space. > > > > If, however, the user can determine that an overlap exists, and where the > > overlap occurs, the copy operation can be done safely, with no additional > > storage, by properly choosing the direction of the iterative copy. > > > > To solve this, the user doesn't need access to the parent segment (this > > could be for security reasons), but could use these two methods: > > > > - MemorySegment::boolean isSameBaseResource(MemorySegment other); > > The intent is to reveal if *this* segment and the *other* segment > share > > a common ancestor segment. It could also be extended to determine > if the > > two segments share the same memory-mapped file (a true resource), > thus > > possibly removing the caveat in paragraph 2 above. > > > > > > - MemorySegment::long baseResourceOffsetBytes(); > > This would return the offset in bytes of the start of this segment > from > > the start of the highest common segment (or resource). > > > > With this information, the user can easily design a safe, efficient, and > > fast data copy method for moving arbitrary elements from one segment to > > another with the same guarantee as System.arrayCopy(). > > > > *Evidence* > > See (copySwap(...) > > < > https://github.com/leerho/PanamaLocal/blob/main/src/main/java/org/apache/datasketches/panama/MemoryCopy.java#L667-L703 > >). > > Before I had access to the new MemorySegment::void > copyFrom(MemorySegment, > > MemoryLayout, MemoryLayout), I had to design a proxy routine that would > do > > the copy (with swap) correctly, especially in the case where the two > > segments overlapped. Note lines 682, 683 where I create a temporary > > segment. If I had the above two methods, this extra copy operation would > > not be needed. > > > > For exactly the above reasons, some years ago we implemented similar > > methods in our DataSketches Memory Component > > >. > > Specifically, in the class *WritableMemory*, the methods > *getRegionOffset()* > > and *isSameResource(that).* > > > > Lee. > From maurizio.cimadamore at oracle.com Wed Jun 16 21:06:55 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 16 Jun 2021 22:06:55 +0100 Subject: Propose 2 new methods for MemorySegment In-Reply-To: References: Message-ID: <23272683-0442-9cd2-f891-5e760766f6ba@oracle.com> Few observation: * I think there is space to add a method which checks if two segments _overlap_ * This doesn't mean reasoning in terms of structure, like you are suggesting (e.g. two slices of the same parent), but merely checking for address overlap * I don't think that, in the general case we carry around the mapped file on which a segment/buffer is based from. And even if we did, with symbolic links etc. it would be pretty hard to uniformly detect these issues Given the above, the complexity vs. benefit of the proposed API seems rather slim. If the general feeling is that a _simple_ address overlap test would be useful, we can add that - but compared with other things we're discussing seems like low priority. Cheers Maurizio On 16/06/2021 20:06, leerho wrote: > Maurizio, > ? Well, I learned yet another corner of the API I hadn't found: > /MemoryAddress::segmentOffset()/?:) > > However, having the boolean i/sSameBaseResource(MemorySegment > other)/?would still be very useful! > > Having to catch exceptions in order to understand some basic > properties of a segment (or a pair of them) is a real nuisance.? As > the API stands currently, given two segments: > > 1. If they are both independently allocated on-heap the > segmentOffset() throws an exception. > 2. If one is on-heap and the other off-heap segmentOffset() throws an > exception. > 3. If they are both independently allocated */off-heap/* > segmentOffset */does not/* throw an exception! > > If you had the method i/sSameBaseResource(MemorySegment other)/: > > 1. would return false > 2. would return false > 3. would return true (since the segmentOffset works in this case). > 4. Also, if both segments are descendants of a common ancestor > segment, it would return true > > This would make handling of moving data between segments so much more > straightforward. > > I revise my request to just add the first method: > > * MemorySegment::boolean isSameBaseResource(MemorySegment other); > The intent is to reveal if /*this*/?segment and the > */other/*?segment share a common ancestor segment. > ["It could also be extended to determine if the two segments share > the same memory-mapped file (a true resource), thus possibly > removing the caveat in paragraph 2 above". -- this may not be > possible ] > > Now whether this removes your paragraph 2 caveat (at the top), I'm not > sure.? Perhaps the caveat is because memory regions of a memory-mapped > file can be swapped out at any time, making any assumptions about > sub-regions and offsets rather meaningless?? Are there other reasons? > > Lee. > > On Wed, Jun 16, 2021 at 1:43 AM Maurizio Cimadamore > > wrote: > > I see what you mean. > > I wonder if this use case isn't already partially covered by > MemoryAddress::segmentOffset. > > E.g. can you do: > > long otherOffset = segment.address().segmentOffset(otherSegment); > > Then it should be easy to check if the offset is within the bounds of > "otherSegment" ? > > (Note that the method already throws if you try to compare > addresses and > segments that are mismatched - e.g. on-heap vs. off-heap). > > Not saying a more direct API is ruled out, just pointing out what we > have to see if it can be used. > > Maurizio > > > On 16/06/2021 02:37, leerho wrote: > > In working on https://github.com/openjdk/panama-foreign/pull/555 > , > which is > > the PR for Memory Segment Efficient Array Handling, I discovered > that there > > are two methods that would be very useful beyond copying arrays, > but useful > > in other types of data movement operations between MemorySegments. > > > > I'd like to draw attention to the opening Javadoc of the > > *MemorySegment::copyFrom(MemorySegment)* method: > > > > 1. Performs a bulk copy from given source segment to this > segment. More > >> specifically, the bytes at offset 0 through src.byteSize() - 1 > in the > >> source segment are copied into this segment at offset 0 through > src.byteSize() > >> - 1. If the source segment overlaps with this segment, then the > copying > >> is performed as if the bytes at offset 0 through src.byteSize() > - 1 in > >> the source segment were first copied into a temporary segment > with size > >> bytes, and then the contents of the temporary segment were > copied into > >> this segment at offset 0 through src.byteSize() - 1. > >> > >> 2. The result of a bulk copy is unspecified if, in the uncommon > case, the > >> source segment and this segment do not overlap, but refer to > overlapping > >> regions of the same backing storage using different addresses. > For example, > >> this may occur if the same file is mapped > >> > <#mapFile(java.nio.file.Path,long,long,java.nio.channels.FileChannel.MapMode,jdk.incubator.foreign.ResourceScope)> > to > >> two segments. > >> > > The first paragraph is a guarantee that even if two descendant > segments > > have an overlapping region with a parent segment that the copy > operation > > will work properly.? This is similar to the guarantee of > System.arrayCopy() > > > > The second paragraph refers to memory-mapped files. However, > let's examine > > the following scenario: > > > >? ? ?- A hierarchy of Memory Segments where two descendant > segments may > >? ? ?overlap a region of the parent segment. > >? ? ?- The elements of the segments are more complex than Java > primitives > >? ? ?(thus, PR 555 doesn't apply). > >? ? ?- The user wishes to copy a region of elements from one of the > >? ? ?descendant segments to the other descendant segment. > >? ? ?- The user only has the two descendant segments in hand and > does not > >? ? ?have access to the parent segment. > > > > With the current MemorySegment API, the descendant segments are > blind to > > the overlap, to wit: > > > >? ? ?- The user cannot determine if an overlap exists. > >? ? ?- Or, if an overlap exists where the overlap is with respect > to the two > >? ? ?segments in hand. > > > > In order to ensure that corruption doesn't occur during the > copy, the user > > must create a temporary duplicate of the destination segment, > copy the data > > into the duplicate, then copy the duplicate into the original > destination > > segment.? This can be expensive in time and space. > > > > If, however, the user can determine that an overlap exists, and > where the > > overlap occurs, the copy operation can be done safely, with no > additional > > storage, by properly choosing the direction of the iterative copy. > > > > To solve this, the user doesn't need access to the parent > segment (this > > could be for security reasons), but could use these two methods: > > > >? ? ?- MemorySegment::boolean isSameBaseResource(MemorySegment > other); > >? ? ?The intent is to reveal if *this* segment and the *other* > segment share > >? ? ?a common ancestor segment.? It could also be extended to > determine if the > >? ? ?two segments share the same memory-mapped file (a true > resource), thus > >? ? ?possibly removing the caveat in paragraph 2 above. > > > > > >? ? ?- MemorySegment::long baseResourceOffsetBytes(); > >? ? ?This would return the offset in bytes of the start of this > segment from > >? ? ?the start of the highest common segment (or resource). > > > > With this information, the user can easily design a safe, > efficient, and > > fast data copy method for moving arbitrary elements from one > segment to > > another with the same guarantee as System.arrayCopy(). > > > > *Evidence* > > See (copySwap(...) > > > >). > > Before I had access to the new MemorySegment::void > copyFrom(MemorySegment, > > MemoryLayout, MemoryLayout), I had to design a proxy routine > that would do > > the copy (with swap) correctly, especially in the case where the two > > segments overlapped. Note lines 682, 683 where I create a temporary > > segment. If I had the above two methods, this extra copy > operation would > > not be needed. > > > > For exactly the above reasons, some years ago we implemented similar > > methods in our DataSketches Memory Component > > > >. > > Specifically, in the class *WritableMemory*, the methods > *getRegionOffset()* > > and *isSameResource(that).* > > > > Lee. > From leerho at gmail.com Wed Jun 16 21:36:37 2021 From: leerho at gmail.com (leerho) Date: Wed, 16 Jun 2021 14:36:37 -0700 Subject: Propose 2 new methods for MemorySegment In-Reply-To: <23272683-0442-9cd2-f891-5e760766f6ba@oracle.com> References: <23272683-0442-9cd2-f891-5e760766f6ba@oracle.com> Message-ID: I think that will work and it does more than i wanted. If two segments overlap (either 2 segments on-heap or 2 segments off-heap) and then using the segmentOffset() I can figure out how to do a direct copy without having to create an extra buffer --- without having to catch exceptions. I assume this would work even if the two segments are buried in a deep hierarchy, i.e., two great-grandchildren of a parent segment. Lee. On Wed, Jun 16, 2021 at 2:07 PM Maurizio Cimadamore < maurizio.cimadamore at oracle.com> wrote: > Few observation: > > * I think there is space to add a method which checks if two segments > _overlap_ > > * This doesn't mean reasoning in terms of structure, like you are > suggesting (e.g. two slices of the same parent), but merely checking for > address overlap > > * I don't think that, in the general case we carry around the mapped file > on which a segment/buffer is based from. And even if we did, with symbolic > links etc. it would be pretty hard to uniformly detect these issues > > Given the above, the complexity vs. benefit of the proposed API seems > rather slim. > > If the general feeling is that a _simple_ address overlap test would be > useful, we can add that - but compared with other things we're discussing > seems like low priority. > > Cheers > Maurizio > > > On 16/06/2021 20:06, leerho wrote: > > Maurizio, > Well, I learned yet another corner of the API I hadn't found: > *MemoryAddress::segmentOffset()* :) > > However, having the boolean i*sSameBaseResource(MemorySegment other)* would > still be very useful! > > Having to catch exceptions in order to understand some basic properties of > a segment (or a pair of them) is a real nuisance. As the API stands > currently, given two segments: > > 1. If they are both independently allocated on-heap the > segmentOffset() throws an exception. > 2. If one is on-heap and the other off-heap segmentOffset() throws an > exception. > 3. If they are both independently allocated *off-heap* segmentOffset *does > not* throw an exception! > > If you had the method i*sSameBaseResource(MemorySegment other)*: > > 1. would return false > 2. would return false > 3. would return true (since the segmentOffset works in this case). > 4. Also, if both segments are descendants of a common ancestor > segment, it would return true > > This would make handling of moving data between segments so much more > straightforward. > > I revise my request to just add the first method: > > - MemorySegment::boolean isSameBaseResource(MemorySegment other); > The intent is to reveal if *this* segment and the *other* segment > share a common ancestor segment. > ["It could also be extended to determine if the two segments share the > same memory-mapped file (a true resource), thus possibly removing the > caveat in paragraph 2 above". -- this may not be possible ] > > Now whether this removes your paragraph 2 caveat (at the top), I'm not > sure. Perhaps the caveat is because memory regions of a memory-mapped file > can be swapped out at any time, making any assumptions about sub-regions > and offsets rather meaningless? Are there other reasons? > > Lee. > > On Wed, Jun 16, 2021 at 1:43 AM Maurizio Cimadamore < > maurizio.cimadamore at oracle.com> wrote: > >> I see what you mean. >> >> I wonder if this use case isn't already partially covered by >> MemoryAddress::segmentOffset. >> >> E.g. can you do: >> >> long otherOffset = segment.address().segmentOffset(otherSegment); >> >> Then it should be easy to check if the offset is within the bounds of >> "otherSegment" ? >> >> (Note that the method already throws if you try to compare addresses and >> segments that are mismatched - e.g. on-heap vs. off-heap). >> >> Not saying a more direct API is ruled out, just pointing out what we >> have to see if it can be used. >> >> Maurizio >> >> >> On 16/06/2021 02:37, leerho wrote: >> > In working on https://github.com/openjdk/panama-foreign/pull/555 >> , >> which is >> > the PR for Memory Segment Efficient Array Handling, I discovered that >> there >> > are two methods that would be very useful beyond copying arrays, but >> useful >> > in other types of data movement operations between MemorySegments. >> > >> > I'd like to draw attention to the opening Javadoc of the >> > *MemorySegment::copyFrom(MemorySegment)* method: >> > >> > 1. Performs a bulk copy from given source segment to this segment. More >> >> specifically, the bytes at offset 0 through src.byteSize() - 1 in the >> >> source segment are copied into this segment at offset 0 through >> src.byteSize() >> >> - 1. If the source segment overlaps with this segment, then the copying >> >> is performed as if the bytes at offset 0 through src.byteSize() - 1 in >> >> the source segment were first copied into a temporary segment with size >> >> bytes, and then the contents of the temporary segment were copied into >> >> this segment at offset 0 through src.byteSize() - 1. >> >> >> >> 2. The result of a bulk copy is unspecified if, in the uncommon case, >> the >> >> source segment and this segment do not overlap, but refer to >> overlapping >> >> regions of the same backing storage using different addresses. For >> example, >> >> this may occur if the same file is mapped >> >> >> <#mapFile(java.nio.file.Path,long,long,java.nio.channels.FileChannel.MapMode,jdk.incubator.foreign.ResourceScope)> >> to >> >> two segments. >> >> >> > The first paragraph is a guarantee that even if two descendant segments >> > have an overlapping region with a parent segment that the copy operation >> > will work properly. This is similar to the guarantee of >> System.arrayCopy() >> > >> > The second paragraph refers to memory-mapped files. However, let's >> examine >> > the following scenario: >> > >> > - A hierarchy of Memory Segments where two descendant segments may >> > overlap a region of the parent segment. >> > - The elements of the segments are more complex than Java primitives >> > (thus, PR 555 doesn't apply). >> > - The user wishes to copy a region of elements from one of the >> > descendant segments to the other descendant segment. >> > - The user only has the two descendant segments in hand and does not >> > have access to the parent segment. >> > >> > With the current MemorySegment API, the descendant segments are blind to >> > the overlap, to wit: >> > >> > - The user cannot determine if an overlap exists. >> > - Or, if an overlap exists where the overlap is with respect to the >> two >> > segments in hand. >> > >> > In order to ensure that corruption doesn't occur during the copy, the >> user >> > must create a temporary duplicate of the destination segment, copy the >> data >> > into the duplicate, then copy the duplicate into the original >> destination >> > segment. This can be expensive in time and space. >> > >> > If, however, the user can determine that an overlap exists, and where >> the >> > overlap occurs, the copy operation can be done safely, with no >> additional >> > storage, by properly choosing the direction of the iterative copy. >> > >> > To solve this, the user doesn't need access to the parent segment (this >> > could be for security reasons), but could use these two methods: >> > >> > - MemorySegment::boolean isSameBaseResource(MemorySegment other); >> > The intent is to reveal if *this* segment and the *other* segment >> share >> > a common ancestor segment. It could also be extended to determine >> if the >> > two segments share the same memory-mapped file (a true resource), >> thus >> > possibly removing the caveat in paragraph 2 above. >> > >> > >> > - MemorySegment::long baseResourceOffsetBytes(); >> > This would return the offset in bytes of the start of this segment >> from >> > the start of the highest common segment (or resource). >> > >> > With this information, the user can easily design a safe, efficient, and >> > fast data copy method for moving arbitrary elements from one segment to >> > another with the same guarantee as System.arrayCopy(). >> > >> > *Evidence* >> > See (copySwap(...) >> > < >> https://github.com/leerho/PanamaLocal/blob/main/src/main/java/org/apache/datasketches/panama/MemoryCopy.java#L667-L703 >> >> >). >> > Before I had access to the new MemorySegment::void >> copyFrom(MemorySegment, >> > MemoryLayout, MemoryLayout), I had to design a proxy routine that would >> do >> > the copy (with swap) correctly, especially in the case where the two >> > segments overlapped. Note lines 682, 683 where I create a temporary >> > segment. If I had the above two methods, this extra copy operation would >> > not be needed. >> > >> > For exactly the above reasons, some years ago we implemented similar >> > methods in our DataSketches Memory Component >> > > >> >. >> > Specifically, in the class *WritableMemory*, the methods >> *getRegionOffset()* >> > and *isSameResource(that).* >> > >> > Lee. >> > From mail at smogura.eu Thu Jun 17 00:15:49 2021 From: mail at smogura.eu (=?iso-8859-2?Q?Rados=B3aw_Smogura?=) Date: Thu, 17 Jun 2021 00:15:49 +0000 Subject: Foreign + Vectors - benchmarks for copying and swapping Message-ID: Hi all, I could not stop my self, from this simple experiment of glueing together foreign with vectors, at least via byte buffers for now. Results are not the best, but still could be interesting, as there was some interest with this. Below please find results, and the link to benchmark: Benchmark Mode Cnt Score Error Units VectorCopySegments.copyWithNative avgt 10 20.987 ? 1.819 ns/op VectorCopySegments.copyWithNativeShared avgt 10 12.528 ? 0.183 ns/op VectorCopySegments.copyWithNativeToArray avgt 10 19.800 ? 3.985 ns/op VectorCopySegments.copyWithVector avgt 10 31.151 ? 1.929 ns/op VectorCopySegments.copyWithVectorShared avgt 10 56.752 ? 1.754 ns/op VectorCopySegments.copyWithVectorShuffle avgt 10 52.409 ? 0.390 ns/op VectorCopySegments.copyWithVectorToArray avgt 10 29.573 ? 0.485 ns/op https://github.com/rsmogura/panama-foreign/blob/foreign_and_vectors/test/micro/org/openjdk/bench/jdk/incubator/foreign/VectorCopySegments.java Feedback is welcome. Kind regards, Rado From maurizio.cimadamore at oracle.com Thu Jun 17 09:43:00 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 17 Jun 2021 10:43:00 +0100 Subject: Propose 2 new methods for MemorySegment In-Reply-To: References: <23272683-0442-9cd2-f891-5e760766f6ba@oracle.com> Message-ID: On 16/06/2021 22:36, leerho wrote: > I think that will work and it does more than i wanted.? If two > segments overlap (either 2 segments on-heap or 2 segments off-heap) > and then using the segmentOffset() I can figure out how to do a direct > copy without having to create an extra buffer --- without having to > catch exceptions. > > I assume this would work even if the two segments are buried?in a deep > hierarchy, i.e., two great-grandchildren of a parent segment. I believe so - after you check that base object is the same (either same array object, or null, for native), you just need to do a range check. Typically these amount at checking if either the start _or_ the end address of a segment is contained in the other. But this would do nothing for the memory mapped case (second paragraph of the copyFrom javadoc) - although, as I said, I don't think we can realistically do much for that. Maurizio > > Lee. > > > On Wed, Jun 16, 2021 at 2:07 PM Maurizio Cimadamore > > wrote: > > Few observation: > > * I think there is space to add a method which checks if two > segments _overlap_ > > * This doesn't mean reasoning in terms of structure, like you are > suggesting (e.g. two slices of the same parent), but merely > checking for address overlap > > * I don't think that, in the general case we carry around the > mapped file on which a segment/buffer is based from. And even if > we did, with symbolic links etc. it would be pretty hard to > uniformly detect these issues > > Given the above, the complexity vs. benefit of the proposed API > seems rather slim. > > If the general feeling is that a _simple_ address overlap test > would be useful, we can add that - but compared with other things > we're discussing seems like low priority. > > Cheers > Maurizio > > > On 16/06/2021 20:06, leerho wrote: >> Maurizio, >> ? Well, I learned yet another corner of the API I hadn't found: >> /MemoryAddress::segmentOffset()/?:) >> >> However, having the boolean i/sSameBaseResource(MemorySegment >> other)/?would still be very useful! >> >> Having to catch exceptions in order to understand some basic >> properties of a segment (or a pair of them) is a real nuisance.? >> As the API stands currently, given two segments: >> >> 1. If they are both independently allocated on-heap the >> segmentOffset() throws an exception. >> 2. If one is on-heap and the other off-heap segmentOffset() >> throws an exception. >> 3. If they are both independently allocated */off-heap/* >> segmentOffset */does not/* throw an exception! >> >> If you had the method i/sSameBaseResource(MemorySegment other)/: >> >> 1. would return false >> 2. would return false >> 3. would return true (since the segmentOffset works in this case). >> 4. Also, if both segments are descendants of a common ancestor >> segment, it would return true >> >> This would make handling of moving data between segments so much >> more straightforward. >> >> I revise my request to just add the first method: >> >> * MemorySegment::boolean isSameBaseResource(MemorySegment other); >> The intent is to reveal if /*this*/?segment and the >> */other/*?segment share a common ancestor segment. >> ["It could also be extended to determine if the two segments >> share the same memory-mapped file (a true resource), thus >> possibly removing the caveat in paragraph 2 above". -- this >> may not be possible ] >> >> Now whether this removes your paragraph 2 caveat (at the top), >> I'm not sure.? Perhaps the caveat is because memory regions of a >> memory-mapped file can be swapped out at any time, making any >> assumptions about sub-regions and offsets rather meaningless?? >> Are there other reasons? >> >> Lee. >> >> On Wed, Jun 16, 2021 at 1:43 AM Maurizio Cimadamore >> > > wrote: >> >> I see what you mean. >> >> I wonder if this use case isn't already partially covered by >> MemoryAddress::segmentOffset. >> >> E.g. can you do: >> >> long otherOffset = segment.address().segmentOffset(otherSegment); >> >> Then it should be easy to check if the offset is within the >> bounds of >> "otherSegment" ? >> >> (Note that the method already throws if you try to compare >> addresses and >> segments that are mismatched - e.g. on-heap vs. off-heap). >> >> Not saying a more direct API is ruled out, just pointing out >> what we >> have to see if it can be used. >> >> Maurizio >> >> >> On 16/06/2021 02:37, leerho wrote: >> > In working on >> https://github.com/openjdk/panama-foreign/pull/555 >> , >> which is >> > the PR for Memory Segment Efficient Array Handling, I >> discovered that there >> > are two methods that would be very useful beyond copying >> arrays, but useful >> > in other types of data movement operations between >> MemorySegments. >> > >> > I'd like to draw attention to the opening Javadoc of the >> > *MemorySegment::copyFrom(MemorySegment)* method: >> > >> > 1. Performs a bulk copy from given source segment to this >> segment. More >> >> specifically, the bytes at offset 0 through src.byteSize() >> - 1 in the >> >> source segment are copied into this segment at offset 0 >> through src.byteSize() >> >> - 1. If the source segment overlaps with this segment, >> then the copying >> >> is performed as if the bytes at offset 0 through >> src.byteSize() - 1 in >> >> the source segment were first copied into a temporary >> segment with size >> >> bytes, and then the contents of the temporary segment were >> copied into >> >> this segment at offset 0 through src.byteSize() - 1. >> >> >> >> 2. The result of a bulk copy is unspecified if, in the >> uncommon case, the >> >> source segment and this segment do not overlap, but refer >> to overlapping >> >> regions of the same backing storage using different >> addresses. For example, >> >> this may occur if the same file is mapped >> >> >> <#mapFile(java.nio.file.Path,long,long,java.nio.channels.FileChannel.MapMode,jdk.incubator.foreign.ResourceScope)> >> to >> >> two segments. >> >> >> > The first paragraph is a guarantee that even if two >> descendant segments >> > have an overlapping region with a parent segment that the >> copy operation >> > will work properly.? This is similar to the guarantee of >> System.arrayCopy() >> > >> > The second paragraph refers to memory-mapped files.? >> However, let's examine >> > the following scenario: >> > >> >? ? ?- A hierarchy of Memory Segments where two descendant >> segments may >> >? ? ?overlap a region of the parent segment. >> >? ? ?- The elements of the segments are more complex than >> Java primitives >> >? ? ?(thus, PR 555 doesn't apply). >> >? ? ?- The user wishes to copy a region of elements from one >> of the >> >? ? ?descendant segments to the other descendant segment. >> >? ? ?- The user only has the two descendant segments in hand >> and does not >> >? ? ?have access to the parent segment. >> > >> > With the current MemorySegment API, the descendant segments >> are blind to >> > the overlap, to wit: >> > >> >? ? ?- The user cannot determine if an overlap exists. >> >? ? ?- Or, if an overlap exists where the overlap is with >> respect to the two >> >? ? ?segments in hand. >> > >> > In order to ensure that corruption doesn't occur during the >> copy, the user >> > must create a temporary duplicate of the destination >> segment, copy the data >> > into the duplicate, then copy the duplicate into the >> original destination >> > segment.? This can be expensive in time and space. >> > >> > If, however, the user can determine that an overlap exists, >> and where the >> > overlap occurs, the copy operation can be done safely, with >> no additional >> > storage, by properly choosing the direction of the >> iterative copy. >> > >> > To solve this, the user doesn't need access to the parent >> segment (this >> > could be for security reasons), but could use these two >> methods: >> > >> >? ? ?- MemorySegment::boolean >> isSameBaseResource(MemorySegment other); >> >? ? ?The intent is to reveal if *this* segment and the >> *other* segment share >> >? ? ?a common ancestor segment.? It could also be extended >> to determine if the >> >? ? ?two segments share the same memory-mapped file (a true >> resource), thus >> >? ? ?possibly removing the caveat in paragraph 2 above. >> > >> > >> >? ? ?- MemorySegment::long baseResourceOffsetBytes(); >> >? ? ?This would return the offset in bytes of the start of >> this segment from >> >? ? ?the start of the highest common segment (or resource). >> > >> > With this information, the user can easily design a safe, >> efficient, and >> > fast data copy method for moving arbitrary elements from >> one segment to >> > another with the same guarantee as System.arrayCopy(). >> > >> > *Evidence* >> > See (copySwap(...) >> > >> > >). >> > Before I had access to the new MemorySegment::void >> copyFrom(MemorySegment, >> > MemoryLayout, MemoryLayout), I had to design a proxy >> routine that would do >> > the copy (with swap) correctly, especially in the case >> where the two >> > segments overlapped. Note lines 682, 683 where I create a >> temporary >> > segment. If I had the above two methods, this extra copy >> operation would >> > not be needed. >> > >> > For exactly the above reasons, some years ago we >> implemented similar >> > methods in our DataSketches Memory Component >> > >> > >. >> > Specifically, in the class *WritableMemory*, the methods >> *getRegionOffset()* >> > and *isSameResource(that).* >> > >> > Lee. >> From maurizio.cimadamore at oracle.com Thu Jun 17 15:44:39 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 17 Jun 2021 16:44:39 +0100 Subject: Memory Segment efficient array handling In-Reply-To: References: <08a001d726ec$f3bd0f30$db372d90$@apache.org> <5d67aba5-e7c8-620c-41ec-0daf396f0d96@oracle.com> <04e101d761c8$67896510$369c2f30$@apache.org> <265ceecd-941a-127b-e2e7-5462f190291c@oracle.com> <06d701d761d1$21bb6f70$65324e50$@apache.org> <7659efda-ed64-093b-c69b-b5af767768c1@oracle.com> <073701d761de$e8317bb0$b8947310$@apache.org> Message-ID: <9cd30ea5-2be3-5bf4-b487-d4ef15c93a3c@oracle.com> I've finalized the PR, it is now a full PR which is ready for review. I did some passes over the code and fix some things here and there, hopefully nothing too controversial. Cheers Maurizio On 16/06/2021 16:56, Maurizio Cimadamore wrote: > Hi Lee, > I've updated the PR with your latest changes. Everything works fine - > there were some trailing whitespaces that I fixed, other than that the > test works ok. > > Maurizio > > On 15/06/2021 20:06, leerho wrote: >> Maurizio, >> I have updated the *MemoryCopy* and *TestMemoryCopy* to include >> references to the new *MemorySegment::CopyFrom(...)* and with byte >> swap capabilities. >> >> I have been able to test the code in my local environment using a >> mock substitute for the new CopyFrom(), but alas, I could not get >> Jtreg to work, so i am sending you the code as updated in >> https://github.com/leerho/mcimadamore_panama-foreign >> >> >> Please test it, when you have a chance. >> >> Lee. >> >> >> On Tue, Jun 15, 2021 at 5:43 AM Maurizio Cimadamore >> > > wrote: >> >> >> ??? >> The reason why copying is slower for small segments is that, I >> ??? think, my >> ??? >> benchmark iterations run in 4-5ns and, at these levels, you are >> ??? >> sensitive to the cost of the liveness checks. There's not a lot >> ??? we can >> ??? >> do to eliminate that - it's the price of safety. >> ??? > OK that's true. But in my own Unsafe.copyMemory code wasn't >> ??? doing MemorySegment.address().toRawLongValue() not also doing the >> ??? liveness check? >> ??? True - so the liveness check probably that won't make a lot of >> ??? difference in your case. But note that the bound checks are still >> ??? applied in MemorySegment::copyMemory. >> ??? > >> ??? >> The good news is that in the case of heap segment wrappers, we >> know >> ??? >> exactly that the size is gonna fit inside an int (it's an array >> ??? after >> ??? >> all!), so we can remove the check. If we remove the flag check, >> ??? and just >> ??? >> set the segment to always be treated as "SMALL", we get the >> ??? following >> ??? >> results: >> ??? > Is this really true? What about a huge long[] array, that could >> ??? be (2^31-8 maximum index) * 8 bytesPerLong = 16 gigabytes? (or are >> ??? those limited by the Java standard in maximum array size?) >> ??? in the PR I've submitted I only tweaked byte segment wrappers. We >> ??? could >> ??? resort to more complex internal representation for other heap >> ??? segments, >> ??? but I believe the true way forward is to wait for the long >> ??? optimizations, and to completely remove the SMALL segment hacks. >> ??? > >> ??? > Sorry, I missed that class. I was opening the pull request and >> ??? only looked at the red/green changes in MemorySegment. I missed >> ??? the first class. >> ??? > >> ??? > The methods provided there exactly replace my three shapes in >> ??? the code. And on top they allow to swap. Side note: MemoryCopy in >> ??? the current PR has the swapping code commented out. >> ??? Yeah - Lee is working on that MemoryCopy class (and associated >> ??? test). I >> ??? have provided the "swappy" copyFrom overload in MemorySegment, I >> ??? believe >> ??? Lee will add support for that soon. >> ??? > >> ??? > Last question: why does >> ??? https://bugs.openjdk.java.net/browse/JDK-8223051 >> ??? not help for >> ??? the integer vs. long loop variables? Does this not allow to remove >> ??? the small vs. large segment distinction? I thought this change in >> ??? hotspot was added to support long loops, if it is in fact "small". >> >> ??? My understanding is that the change has been split in multiple >> ??? chunks. >> ??? The chunk we mostly depend on is this: >> >> ??? https://bugs.openjdk.java.net/browse/JDK-8259609 >> ??? >> >> ??? (in fact I'm coordinating with Roland, the author of that work, >> ??? and he's >> ??? testing the patch against a version of panama which doesn't have >> ??? workarounds for small segments). >> >> ??? I did run all Panama benchmarks after JDK-8223051 was pushed, and >> ??? removed various workarounds, but? there was still a performance gap. >> ??? Roland reassured me that the gap should disappear once >> JDK-8259609 is >> ??? pushed. >> >> ??? Maurizio >> >> ??? > >> ??? > Uwe >> ??? > >> From mcimadamore at openjdk.java.net Thu Jun 17 15:48:04 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 17 Jun 2021 15:48:04 GMT Subject: [foreign-memaccess+abi] RFR: Add suppoort for high-level functions to copy to and from Java arrays Message-ID: This patch includes some of the changes from Lee to support a set of static functions to allow bulk copy from Java arrays to segments (and viceversa) in a more succint fashion (so that the user doesn't have to create a temporary heap segment to do the copy). I've added a new public method to `MemorySegment` which performs an *element-wise* bulk copy; it takes a source segment and a couple of element layouts: the source element layout and the destination element layout. The two layouts must have same size, but can have different alignments (which will be checked against the corresponding segments) and byte orders. If the byte order differs, a bulk copy with swap will be performed. As such, this method generalizes the previous `copyFrom` - as follows: copyFrom(srcSegment) -> copyFrom(JAVA_BYTE, srcSegment, JAVA_BYTE) I've added support for argument type profiling for MemoryCopy static methods to avoid type pollution in cases where same metod is called with different memory segment types. I've done a pass over the javadoc, and make it more consistent with the rest of the API. I've also reworked the test a bit to use the data provider functionality of TestNG, since all the test cases were similar, except for the carrier type. There are other cosmetic changes as well, compared to original code from Lee, such as naming of static fields which is now capitalized. Everything else is the same. ------------- Commit messages: - Further streamline test, and use a data provider - Streamline test - Add jtreg test header to TestMemoryCopy - Merge branch 'foreign-memaccess+abi' into copyMemory+8264594 - Merge branch 'foreign-memaccess+abi' into copyMemory+8264594 - * Indent test file - Add support for argument type profiling for MemoryCopy statics - * Fix javadoc in MemorySegment::copyFrom - * Streamline implementation of swappy copy methods - Fix whitespaces - ... and 4 more: https://git.openjdk.java.net/panama-foreign/compare/0d9d64da...2c6fa450 Changes: https://git.openjdk.java.net/panama-foreign/pull/555/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=555&range=00 Stats: 1212 lines in 8 files changed: 1132 ins; 24 del; 56 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/555.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/555/head:pull/555 PR: https://git.openjdk.java.net/panama-foreign/pull/555 From uschindler at openjdk.java.net Thu Jun 17 15:48:04 2021 From: uschindler at openjdk.java.net (Uwe Schindler) Date: Thu, 17 Jun 2021 15:48:04 GMT Subject: [foreign-memaccess+abi] RFR: Add suppoort for high-level functions to copy to and from Java arrays In-Reply-To: References: Message-ID: On Thu, 10 Jun 2021 13:03:09 GMT, Maurizio Cimadamore wrote: > This patch includes some of the changes from Lee to support a set of static functions to allow bulk copy from Java arrays to segments (and viceversa) in a more succint fashion (so that the user doesn't have to create a temporary heap segment to do the copy). > > I've added a new public method to `MemorySegment` which performs an *element-wise* bulk copy; it takes a source segment and a couple of element layouts: the source element layout and the destination element layout. The two layouts must have same size, but can have different alignments (which will be checked against the corresponding segments) and byte orders. If the byte order differs, a bulk copy with swap will be performed. As such, this method generalizes the previous `copyFrom` - as follows: > > > copyFrom(srcSegment) -> copyFrom(JAVA_BYTE, srcSegment, JAVA_BYTE) > > I've added support for argument type profiling for MemoryCopy static methods to avoid type pollution in cases where same metod is called with different memory segment types. > > I've done a pass over the javadoc, and make it more consistent with the rest of the API. I've also reworked the test a bit to use the data provider functionality of TestNG, since all the test cases were similar, except for the carrier type. > > There are other cosmetic changes as well, compared to original code from Lee, such as naming of static fields which is now capitalized. Everything else is the same. Hi, the byte-swap code is still commented out in MemoryCopy class, although the method was implemented in MemorySegment. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/555 From paul.sandoz at oracle.com Thu Jun 17 16:00:44 2021 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 17 Jun 2021 16:00:44 +0000 Subject: Foreign + Vectors - benchmarks for copying and swapping In-Reply-To: References: Message-ID: Hi Rado, Thanks, an interesting experiment. We would need to look the generated code to spot issues. Hard to compete with a specialized and highly optimized intrinsic copy. Still, it seems we should be able to do better. I suspect there might be some un-hoisted bounds checks, or non-optimal addressing of loads/stores. Something odd going on with shared access. I doubt the use of shuffle can compete in general with the byte swapping in the intrinsic copy, but we are still ironing out performance issues with shuffle so maybe there is some room for improvement. (Further, we don?t do anything special with for certain constant shuffle patterns from which we might be able to select more optimal instructions.) Paul. > On Jun 16, 2021, at 5:15 PM, Rados?aw Smogura wrote: > > Hi all, > > I could not stop my self, from this simple experiment of glueing together foreign with vectors, at least via byte buffers for now. > > Results are not the best, but still could be interesting, as there was some interest with this. > > Below please find results, and the link to benchmark: > > Benchmark Mode Cnt Score Error Units > VectorCopySegments.copyWithNative avgt 10 20.987 ? 1.819 ns/op > VectorCopySegments.copyWithNativeShared avgt 10 12.528 ? 0.183 ns/op > VectorCopySegments.copyWithNativeToArray avgt 10 19.800 ? 3.985 ns/op > VectorCopySegments.copyWithVector avgt 10 31.151 ? 1.929 ns/op > VectorCopySegments.copyWithVectorShared avgt 10 56.752 ? 1.754 ns/op > VectorCopySegments.copyWithVectorShuffle avgt 10 52.409 ? 0.390 ns/op > VectorCopySegments.copyWithVectorToArray avgt 10 29.573 ? 0.485 ns/op > > https://github.com/rsmogura/panama-foreign/blob/foreign_and_vectors/test/micro/org/openjdk/bench/jdk/incubator/foreign/VectorCopySegments.java > > Feedback is welcome. > > Kind regards, > Rado From maurizio.cimadamore at oracle.com Thu Jun 17 16:12:22 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 17 Jun 2021 17:12:22 +0100 Subject: Foreign + Vectors - benchmarks for copying and swapping In-Reply-To: References: Message-ID: <5290e44a-7c67-6ee6-57dc-9af646604082@oracle.com> Would be interesting to see if passing in regular byte buffers (e.g. not derived from segments) improve things. A regular byte buffer should not have any liveness check, so the overhead might be somewhat lower, although it seems, as Paul says, that the benchmark is affected by non-optimized bound checks. Also - maybe it's a silly comment - but did you double check the endianness of the returned buffer? The memory segment API returns BIG_ENDIAN buffers (as it's the case for buffers allocated with ByteBuffer.allocateDirect). Is it possible you are using mismatched endiannes? Maurizio On 17/06/2021 17:00, Paul Sandoz wrote: > Hi Rado, > > Thanks, an interesting experiment. > > We would need to look the generated code to spot issues. Hard to compete with a specialized and highly optimized intrinsic copy. Still, it seems we should be able to do better. > > I suspect there might be some un-hoisted bounds checks, or non-optimal addressing of loads/stores. > > Something odd going on with shared access. > > I doubt the use of shuffle can compete in general with the byte swapping in the intrinsic copy, but we are still ironing out performance issues with shuffle so maybe there is some room for improvement. (Further, we don?t do anything special with for certain constant shuffle patterns from which we might be able to select more optimal instructions.) > > Paul. > >> On Jun 16, 2021, at 5:15 PM, Rados?aw Smogura wrote: >> >> Hi all, >> >> I could not stop my self, from this simple experiment of glueing together foreign with vectors, at least via byte buffers for now. >> >> Results are not the best, but still could be interesting, as there was some interest with this. >> >> Below please find results, and the link to benchmark: >> >> Benchmark Mode Cnt Score Error Units >> VectorCopySegments.copyWithNative avgt 10 20.987 ? 1.819 ns/op >> VectorCopySegments.copyWithNativeShared avgt 10 12.528 ? 0.183 ns/op >> VectorCopySegments.copyWithNativeToArray avgt 10 19.800 ? 3.985 ns/op >> VectorCopySegments.copyWithVector avgt 10 31.151 ? 1.929 ns/op >> VectorCopySegments.copyWithVectorShared avgt 10 56.752 ? 1.754 ns/op >> VectorCopySegments.copyWithVectorShuffle avgt 10 52.409 ? 0.390 ns/op >> VectorCopySegments.copyWithVectorToArray avgt 10 29.573 ? 0.485 ns/op >> >> https://github.com/rsmogura/panama-foreign/blob/foreign_and_vectors/test/micro/org/openjdk/bench/jdk/incubator/foreign/VectorCopySegments.java >> >> Feedback is welcome. >> >> Kind regards, >> Rado From leerho at gmail.com Thu Jun 17 17:26:19 2021 From: leerho at gmail.com (leerho) Date: Thu, 17 Jun 2021 10:26:19 -0700 Subject: Propose 2 new methods for MemorySegment In-Reply-To: References: <23272683-0442-9cd2-f891-5e760766f6ba@oracle.com> Message-ID: This is super! Thank you for this. Is there a chance this can make it into 17? Lee. On Thu, Jun 17, 2021 at 2:43 AM Maurizio Cimadamore < maurizio.cimadamore at oracle.com> wrote: > > On 16/06/2021 22:36, leerho wrote: > > I think that will work and it does more than i wanted. If two segments > overlap (either 2 segments on-heap or 2 segments off-heap) and then using > the segmentOffset() I can figure out how to do a direct copy without having > to create an extra buffer --- without having to catch exceptions. > > I assume this would work even if the two segments are buried in a deep > hierarchy, i.e., two great-grandchildren of a parent segment. > > I believe so - after you check that base object is the same (either same > array object, or null, for native), you just need to do a range check. > Typically these amount at checking if either the start _or_ the end address > of a segment is contained in the other. > > But this would do nothing for the memory mapped case (second paragraph of > the copyFrom javadoc) - although, as I said, I don't think we can > realistically do much for that. > > Maurizio > > > Lee. > > > On Wed, Jun 16, 2021 at 2:07 PM Maurizio Cimadamore < > maurizio.cimadamore at oracle.com> wrote: > >> Few observation: >> >> * I think there is space to add a method which checks if two segments >> _overlap_ >> >> * This doesn't mean reasoning in terms of structure, like you are >> suggesting (e.g. two slices of the same parent), but merely checking for >> address overlap >> >> * I don't think that, in the general case we carry around the mapped file >> on which a segment/buffer is based from. And even if we did, with symbolic >> links etc. it would be pretty hard to uniformly detect these issues >> >> Given the above, the complexity vs. benefit of the proposed API seems >> rather slim. >> >> If the general feeling is that a _simple_ address overlap test would be >> useful, we can add that - but compared with other things we're discussing >> seems like low priority. >> >> Cheers >> Maurizio >> >> >> On 16/06/2021 20:06, leerho wrote: >> >> Maurizio, >> Well, I learned yet another corner of the API I hadn't found: >> *MemoryAddress::segmentOffset()* :) >> >> However, having the boolean i*sSameBaseResource(MemorySegment other)* would >> still be very useful! >> >> Having to catch exceptions in order to understand some basic properties >> of a segment (or a pair of them) is a real nuisance. As the API stands >> currently, given two segments: >> >> 1. If they are both independently allocated on-heap the >> segmentOffset() throws an exception. >> 2. If one is on-heap and the other off-heap segmentOffset() throws an >> exception. >> 3. If they are both independently allocated *off-heap* segmentOffset *does >> not* throw an exception! >> >> If you had the method i*sSameBaseResource(MemorySegment other)*: >> >> 1. would return false >> 2. would return false >> 3. would return true (since the segmentOffset works in this case). >> 4. Also, if both segments are descendants of a common ancestor >> segment, it would return true >> >> This would make handling of moving data between segments so much more >> straightforward. >> >> I revise my request to just add the first method: >> >> - MemorySegment::boolean isSameBaseResource(MemorySegment other); >> The intent is to reveal if *this* segment and the *other* segment >> share a common ancestor segment. >> ["It could also be extended to determine if the two segments share >> the same memory-mapped file (a true resource), thus possibly removing the >> caveat in paragraph 2 above". -- this may not be possible ] >> >> Now whether this removes your paragraph 2 caveat (at the top), I'm not >> sure. Perhaps the caveat is because memory regions of a memory-mapped file >> can be swapped out at any time, making any assumptions about sub-regions >> and offsets rather meaningless? Are there other reasons? >> >> Lee. >> >> On Wed, Jun 16, 2021 at 1:43 AM Maurizio Cimadamore < >> maurizio.cimadamore at oracle.com> wrote: >> >>> I see what you mean. >>> >>> I wonder if this use case isn't already partially covered by >>> MemoryAddress::segmentOffset. >>> >>> E.g. can you do: >>> >>> long otherOffset = segment.address().segmentOffset(otherSegment); >>> >>> Then it should be easy to check if the offset is within the bounds of >>> "otherSegment" ? >>> >>> (Note that the method already throws if you try to compare addresses and >>> segments that are mismatched - e.g. on-heap vs. off-heap). >>> >>> Not saying a more direct API is ruled out, just pointing out what we >>> have to see if it can be used. >>> >>> Maurizio >>> >>> >>> On 16/06/2021 02:37, leerho wrote: >>> > In working on https://github.com/openjdk/panama-foreign/pull/555 >>> , >>> which is >>> > the PR for Memory Segment Efficient Array Handling, I discovered that >>> there >>> > are two methods that would be very useful beyond copying arrays, but >>> useful >>> > in other types of data movement operations between MemorySegments. >>> > >>> > I'd like to draw attention to the opening Javadoc of the >>> > *MemorySegment::copyFrom(MemorySegment)* method: >>> > >>> > 1. Performs a bulk copy from given source segment to this segment. More >>> >> specifically, the bytes at offset 0 through src.byteSize() - 1 in the >>> >> source segment are copied into this segment at offset 0 through >>> src.byteSize() >>> >> - 1. If the source segment overlaps with this segment, then the >>> copying >>> >> is performed as if the bytes at offset 0 through src.byteSize() - 1 in >>> >> the source segment were first copied into a temporary segment with >>> size >>> >> bytes, and then the contents of the temporary segment were copied into >>> >> this segment at offset 0 through src.byteSize() - 1. >>> >> >>> >> 2. The result of a bulk copy is unspecified if, in the uncommon case, >>> the >>> >> source segment and this segment do not overlap, but refer to >>> overlapping >>> >> regions of the same backing storage using different addresses. For >>> example, >>> >> this may occur if the same file is mapped >>> >> >>> <#mapFile(java.nio.file.Path,long,long,java.nio.channels.FileChannel.MapMode,jdk.incubator.foreign.ResourceScope)> >>> to >>> >> two segments. >>> >> >>> > The first paragraph is a guarantee that even if two descendant segments >>> > have an overlapping region with a parent segment that the copy >>> operation >>> > will work properly. This is similar to the guarantee of >>> System.arrayCopy() >>> > >>> > The second paragraph refers to memory-mapped files. However, let's >>> examine >>> > the following scenario: >>> > >>> > - A hierarchy of Memory Segments where two descendant segments may >>> > overlap a region of the parent segment. >>> > - The elements of the segments are more complex than Java >>> primitives >>> > (thus, PR 555 doesn't apply). >>> > - The user wishes to copy a region of elements from one of the >>> > descendant segments to the other descendant segment. >>> > - The user only has the two descendant segments in hand and does >>> not >>> > have access to the parent segment. >>> > >>> > With the current MemorySegment API, the descendant segments are blind >>> to >>> > the overlap, to wit: >>> > >>> > - The user cannot determine if an overlap exists. >>> > - Or, if an overlap exists where the overlap is with respect to >>> the two >>> > segments in hand. >>> > >>> > In order to ensure that corruption doesn't occur during the copy, the >>> user >>> > must create a temporary duplicate of the destination segment, copy the >>> data >>> > into the duplicate, then copy the duplicate into the original >>> destination >>> > segment. This can be expensive in time and space. >>> > >>> > If, however, the user can determine that an overlap exists, and where >>> the >>> > overlap occurs, the copy operation can be done safely, with no >>> additional >>> > storage, by properly choosing the direction of the iterative copy. >>> > >>> > To solve this, the user doesn't need access to the parent segment (this >>> > could be for security reasons), but could use these two methods: >>> > >>> > - MemorySegment::boolean isSameBaseResource(MemorySegment other); >>> > The intent is to reveal if *this* segment and the *other* segment >>> share >>> > a common ancestor segment. It could also be extended to determine >>> if the >>> > two segments share the same memory-mapped file (a true resource), >>> thus >>> > possibly removing the caveat in paragraph 2 above. >>> > >>> > >>> > - MemorySegment::long baseResourceOffsetBytes(); >>> > This would return the offset in bytes of the start of this segment >>> from >>> > the start of the highest common segment (or resource). >>> > >>> > With this information, the user can easily design a safe, efficient, >>> and >>> > fast data copy method for moving arbitrary elements from one segment to >>> > another with the same guarantee as System.arrayCopy(). >>> > >>> > *Evidence* >>> > See (copySwap(...) >>> > < >>> https://github.com/leerho/PanamaLocal/blob/main/src/main/java/org/apache/datasketches/panama/MemoryCopy.java#L667-L703 >>> >>> >). >>> > Before I had access to the new MemorySegment::void >>> copyFrom(MemorySegment, >>> > MemoryLayout, MemoryLayout), I had to design a proxy routine that >>> would do >>> > the copy (with swap) correctly, especially in the case where the two >>> > segments overlapped. Note lines 682, 683 where I create a temporary >>> > segment. If I had the above two methods, this extra copy operation >>> would >>> > not be needed. >>> > >>> > For exactly the above reasons, some years ago we implemented similar >>> > methods in our DataSketches Memory Component >>> > < >>> https://datasketches.apache.org/api/memory/snapshot/apidocs/index.html >>> >>> >. >>> > Specifically, in the class *WritableMemory*, the methods >>> *getRegionOffset()* >>> > and *isSameResource(that).* >>> > >>> > Lee. >>> >> From maurizio.cimadamore at oracle.com Thu Jun 17 17:34:45 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 17 Jun 2021 18:34:45 +0100 Subject: Propose 2 new methods for MemorySegment In-Reply-To: References: <23272683-0442-9cd2-f891-5e760766f6ba@oracle.com> Message-ID: On 17/06/2021 18:26, leerho wrote: > This is super! Thank you for this.? Is there a chance this can make it > into 17? No, Java 17 is in finalization stage [1], only high priority requests (e.g. broken stuff) can be accommodated at this point in time. Cheers Maurizio [1] - https://mail.openjdk.java.net/pipermail/jdk-dev/2021-June/005690.html > > Lee. > > On Thu, Jun 17, 2021 at 2:43 AM Maurizio Cimadamore > > wrote: > > > On 16/06/2021 22:36, leerho wrote: >> I think that will work and it does more than i wanted.? If two >> segments overlap (either 2 segments on-heap or 2 segments >> off-heap) and then using the segmentOffset() I can figure out how >> to do a direct copy without having to create an extra buffer --- >> without having to catch exceptions. >> >> I assume this would work even if the two segments are buried?in a >> deep hierarchy, i.e., two great-grandchildren of a parent segment. > > I believe so - after you check that base object is the same > (either same array object, or null, for native), you just need to > do a range check. Typically these amount at checking if either the > start _or_ the end address of a segment is contained in the other. > > But this would do nothing for the memory mapped case (second > paragraph of the copyFrom javadoc) - although, as I said, I don't > think we can realistically do much for that. > > Maurizio > >> >> Lee. >> >> >> On Wed, Jun 16, 2021 at 2:07 PM Maurizio Cimadamore >> > > wrote: >> >> Few observation: >> >> * I think there is space to add a method which checks if two >> segments _overlap_ >> >> * This doesn't mean reasoning in terms of structure, like you >> are suggesting (e.g. two slices of the same parent), but >> merely checking for address overlap >> >> * I don't think that, in the general case we carry around the >> mapped file on which a segment/buffer is based from. And even >> if we did, with symbolic links etc. it would be pretty hard >> to uniformly detect these issues >> >> Given the above, the complexity vs. benefit of the proposed >> API seems rather slim. >> >> If the general feeling is that a _simple_ address overlap >> test would be useful, we can add that - but compared with >> other things we're discussing seems like low priority. >> >> Cheers >> Maurizio >> >> >> On 16/06/2021 20:06, leerho wrote: >>> Maurizio, >>> ? Well, I learned yet another corner of the API I hadn't >>> found: /MemoryAddress::segmentOffset()/?:) >>> >>> However, having the boolean >>> i/sSameBaseResource(MemorySegment other)/?would still be >>> very useful! >>> >>> Having to catch exceptions in order to understand some basic >>> properties of a segment (or a pair of them) is a real >>> nuisance.? As the API stands currently, given two segments: >>> >>> 1. If they are both independently allocated on-heap the >>> segmentOffset() throws an exception. >>> 2. If one is on-heap and the other off-heap segmentOffset() >>> throws an exception. >>> 3. If they are both independently allocated */off-heap/* >>> segmentOffset */does not/* throw an exception! >>> >>> If you had the method i/sSameBaseResource(MemorySegment other)/: >>> >>> 1. would return false >>> 2. would return false >>> 3. would return true (since the segmentOffset works in this >>> case). >>> 4. Also, if both segments are descendants of a common >>> ancestor segment, it would return true >>> >>> This would make handling of moving data between segments so >>> much more straightforward. >>> >>> I revise my request to just add the first method: >>> >>> * MemorySegment::boolean isSameBaseResource(MemorySegment >>> other); >>> The intent is to reveal if /*this*/?segment and the >>> */other/*?segment share a common ancestor segment. >>> ["It could also be extended to determine if the two >>> segments share the same memory-mapped file (a true >>> resource), thus possibly removing the caveat in >>> paragraph 2 above". -- this may not be possible ] >>> >>> Now whether this removes your paragraph 2 caveat (at the >>> top), I'm not sure.? Perhaps the caveat is because memory >>> regions of a memory-mapped file can be swapped out at any >>> time, making any assumptions about sub-regions and offsets >>> rather meaningless?? Are there other reasons? >>> >>> Lee. >>> >>> On Wed, Jun 16, 2021 at 1:43 AM Maurizio Cimadamore >>> >> > wrote: >>> >>> I see what you mean. >>> >>> I wonder if this use case isn't already partially >>> covered by >>> MemoryAddress::segmentOffset. >>> >>> E.g. can you do: >>> >>> long otherOffset = >>> segment.address().segmentOffset(otherSegment); >>> >>> Then it should be easy to check if the offset is within >>> the bounds of >>> "otherSegment" ? >>> >>> (Note that the method already throws if you try to >>> compare addresses and >>> segments that are mismatched - e.g. on-heap vs. off-heap). >>> >>> Not saying a more direct API is ruled out, just pointing >>> out what we >>> have to see if it can be used. >>> >>> Maurizio >>> >>> >>> On 16/06/2021 02:37, leerho wrote: >>> > In working on >>> https://github.com/openjdk/panama-foreign/pull/555 >>> , >>> which is >>> > the PR for Memory Segment Efficient Array Handling, I >>> discovered that there >>> > are two methods that would be very useful beyond >>> copying arrays, but useful >>> > in other types of data movement operations between >>> MemorySegments. >>> > >>> > I'd like to draw attention to the opening Javadoc of the >>> > *MemorySegment::copyFrom(MemorySegment)* method: >>> > >>> > 1. Performs a bulk copy from given source segment to >>> this segment. More >>> >> specifically, the bytes at offset 0 through >>> src.byteSize() - 1 in the >>> >> source segment are copied into this segment at offset >>> 0 through src.byteSize() >>> >> - 1. If the source segment overlaps with this >>> segment, then the copying >>> >> is performed as if the bytes at offset 0 through >>> src.byteSize() - 1 in >>> >> the source segment were first copied into a temporary >>> segment with size >>> >> bytes, and then the contents of the temporary segment >>> were copied into >>> >> this segment at offset 0 through src.byteSize() - 1. >>> >> >>> >> 2. The result of a bulk copy is unspecified if, in >>> the uncommon case, the >>> >> source segment and this segment do not overlap, but >>> refer to overlapping >>> >> regions of the same backing storage using different >>> addresses. For example, >>> >> this may occur if the same file is mapped >>> >> >>> <#mapFile(java.nio.file.Path,long,long,java.nio.channels.FileChannel.MapMode,jdk.incubator.foreign.ResourceScope)> >>> to >>> >> two segments. >>> >> >>> > The first paragraph is a guarantee that even if two >>> descendant segments >>> > have an overlapping region with a parent segment that >>> the copy operation >>> > will work properly.? This is similar to the guarantee >>> of System.arrayCopy() >>> > >>> > The second paragraph refers to memory-mapped files.? >>> However, let's examine >>> > the following scenario: >>> > >>> >? ? ?- A hierarchy of Memory Segments where two >>> descendant segments may >>> >? ? ?overlap a region of the parent segment. >>> >? ? ?- The elements of the segments are more complex >>> than Java primitives >>> >? ? ?(thus, PR 555 doesn't apply). >>> >? ? ?- The user wishes to copy a region of elements >>> from one of the >>> >? ? ?descendant segments to the other descendant segment. >>> >? ? ?- The user only has the two descendant segments in >>> hand and does not >>> >? ? ?have access to the parent segment. >>> > >>> > With the current MemorySegment API, the descendant >>> segments are blind to >>> > the overlap, to wit: >>> > >>> >? ? ?- The user cannot determine if an overlap exists. >>> >? ? ?- Or, if an overlap exists where the overlap is >>> with respect to the two >>> >? ? ?segments in hand. >>> > >>> > In order to ensure that corruption doesn't occur >>> during the copy, the user >>> > must create a temporary duplicate of the destination >>> segment, copy the data >>> > into the duplicate, then copy the duplicate into the >>> original destination >>> > segment.? This can be expensive in time and space. >>> > >>> > If, however, the user can determine that an overlap >>> exists, and where the >>> > overlap occurs, the copy operation can be done safely, >>> with no additional >>> > storage, by properly choosing the direction of the >>> iterative copy. >>> > >>> > To solve this, the user doesn't need access to the >>> parent segment (this >>> > could be for security reasons), but could use these >>> two methods: >>> > >>> >? ? ?- MemorySegment::boolean >>> isSameBaseResource(MemorySegment other); >>> >? ? ?The intent is to reveal if *this* segment and the >>> *other* segment share >>> >? ? ?a common ancestor segment.? It could also be >>> extended to determine if the >>> >? ? ?two segments share the same memory-mapped file (a >>> true resource), thus >>> >? ? ?possibly removing the caveat in paragraph 2 above. >>> > >>> > >>> >? ? ?- MemorySegment::long baseResourceOffsetBytes(); >>> >? ? ?This would return the offset in bytes of the start >>> of this segment from >>> >? ? ?the start of the highest common segment (or resource). >>> > >>> > With this information, the user can easily design a >>> safe, efficient, and >>> > fast data copy method for moving arbitrary elements >>> from one segment to >>> > another with the same guarantee as System.arrayCopy(). >>> > >>> > *Evidence* >>> > See (copySwap(...) >>> > >>> >> >). >>> > Before I had access to the new MemorySegment::void >>> copyFrom(MemorySegment, >>> > MemoryLayout, MemoryLayout), I had to design a proxy >>> routine that would do >>> > the copy (with swap) correctly, especially in the case >>> where the two >>> > segments overlapped. Note lines 682, 683 where I >>> create a temporary >>> > segment. If I had the above two methods, this extra >>> copy operation would >>> > not be needed. >>> > >>> > For exactly the above reasons, some years ago we >>> implemented similar >>> > methods in our DataSketches Memory Component >>> > >>> >> >. >>> > Specifically, in the class *WritableMemory*, the >>> methods *getRegionOffset()* >>> > and *isSameResource(that).* >>> > >>> > Lee. >>> From leerho at gmail.com Thu Jun 17 17:56:37 2021 From: leerho at gmail.com (leerho) Date: Thu, 17 Jun 2021 10:56:37 -0700 Subject: Memory Segment efficient array handling In-Reply-To: <9cd30ea5-2be3-5bf4-b487-d4ef15c93a3c@oracle.com> References: <08a001d726ec$f3bd0f30$db372d90$@apache.org> <5d67aba5-e7c8-620c-41ec-0daf396f0d96@oracle.com> <04e101d761c8$67896510$369c2f30$@apache.org> <265ceecd-941a-127b-e2e7-5462f190291c@oracle.com> <06d701d761d1$21bb6f70$65324e50$@apache.org> <7659efda-ed64-093b-c69b-b5af767768c1@oracle.com> <073701d761de$e8317bb0$b8947310$@apache.org> <9cd30ea5-2be3-5bf4-b487-d4ef15c93a3c@oracle.com> Message-ID: Maurizio, Wow! Thanks! You clearly put a lot of work into these changes! You completely rewrote the test class using tools that I was not aware of as well as simplifications of the ultimate code. I was pleased that at least the basic concept of the tests survived. I am very grateful for the time you spent on this! Cheers, Lee. On Thu, Jun 17, 2021 at 8:44 AM Maurizio Cimadamore < maurizio.cimadamore at oracle.com> wrote: > I've finalized the PR, it is now a full PR which is ready for review. I > did some passes over the code and fix some things here and there, > hopefully nothing too controversial. > > Cheers > Maurizio > > On 16/06/2021 16:56, Maurizio Cimadamore wrote: > > Hi Lee, > > I've updated the PR with your latest changes. Everything works fine - > > there were some trailing whitespaces that I fixed, other than that the > > test works ok. > > > > Maurizio > > > > On 15/06/2021 20:06, leerho wrote: > >> Maurizio, > >> I have updated the *MemoryCopy* and *TestMemoryCopy* to include > >> references to the new *MemorySegment::CopyFrom(...)* and with byte > >> swap capabilities. > >> > >> I have been able to test the code in my local environment using a > >> mock substitute for the new CopyFrom(), but alas, I could not get > >> Jtreg to work, so i am sending you the code as updated in > >> https://github.com/leerho/mcimadamore_panama-foreign > >> < > https://urldefense.com/v3/__https://github.com/leerho/mcimadamore_panama-foreign__;!!GqivPVa7Brio!MZMNJXVSSBqQxv9G2nXnY-wpuBdgPpwIvBCl6CuzkZLWKaRjEAPnl1FHib5FeUyX3rF3rRU$ > > > >> > >> Please test it, when you have a chance. > >> > >> Lee. > >> > >> > >> On Tue, Jun 15, 2021 at 5:43 AM Maurizio Cimadamore > >> >> > wrote: > >> > >> > >> >> The reason why copying is slower for small segments is that, I > >> think, my > >> >> benchmark iterations run in 4-5ns and, at these levels, you are > >> >> sensitive to the cost of the liveness checks. There's not a lot > >> we can > >> >> do to eliminate that - it's the price of safety. > >> > OK that's true. But in my own Unsafe.copyMemory code wasn't > >> doing MemorySegment.address().toRawLongValue() not also doing the > >> liveness check? > >> True - so the liveness check probably that won't make a lot of > >> difference in your case. But note that the bound checks are still > >> applied in MemorySegment::copyMemory. > >> > > >> >> The good news is that in the case of heap segment wrappers, we > >> know > >> >> exactly that the size is gonna fit inside an int (it's an array > >> after > >> >> all!), so we can remove the check. If we remove the flag check, > >> and just > >> >> set the segment to always be treated as "SMALL", we get the > >> following > >> >> results: > >> > Is this really true? What about a huge long[] array, that could > >> be (2^31-8 maximum index) * 8 bytesPerLong = 16 gigabytes? (or are > >> those limited by the Java standard in maximum array size?) > >> in the PR I've submitted I only tweaked byte segment wrappers. We > >> could > >> resort to more complex internal representation for other heap > >> segments, > >> but I believe the true way forward is to wait for the long > >> optimizations, and to completely remove the SMALL segment hacks. > >> > > >> > Sorry, I missed that class. I was opening the pull request and > >> only looked at the red/green changes in MemorySegment. I missed > >> the first class. > >> > > >> > The methods provided there exactly replace my three shapes in > >> the code. And on top they allow to swap. Side note: MemoryCopy in > >> the current PR has the swapping code commented out. > >> Yeah - Lee is working on that MemoryCopy class (and associated > >> test). I > >> have provided the "swappy" copyFrom overload in MemorySegment, I > >> believe > >> Lee will add support for that soon. > >> > > >> > Last question: why does > >> https://bugs.openjdk.java.net/browse/JDK-8223051 > >> not help for > >> the integer vs. long loop variables? Does this not allow to remove > >> the small vs. large segment distinction? I thought this change in > >> hotspot was added to support long loops, if it is in fact "small". > >> > >> My understanding is that the change has been split in multiple > >> chunks. > >> The chunk we mostly depend on is this: > >> > >> https://bugs.openjdk.java.net/browse/JDK-8259609 > >> > >> > >> (in fact I'm coordinating with Roland, the author of that work, > >> and he's > >> testing the patch against a version of panama which doesn't have > >> workarounds for small segments). > >> > >> I did run all Panama benchmarks after JDK-8223051 was pushed, and > >> removed various workarounds, but there was still a performance gap. > >> Roland reassured me that the gap should disappear once > >> JDK-8259609 is > >> pushed. > >> > >> Maurizio > >> > >> > > >> > Uwe > >> > > >> > From maurizio.cimadamore at oracle.com Thu Jun 17 17:59:20 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 17 Jun 2021 18:59:20 +0100 Subject: Memory Segment efficient array handling In-Reply-To: References: <08a001d726ec$f3bd0f30$db372d90$@apache.org> <5d67aba5-e7c8-620c-41ec-0daf396f0d96@oracle.com> <04e101d761c8$67896510$369c2f30$@apache.org> <265ceecd-941a-127b-e2e7-5462f190291c@oracle.com> <06d701d761d1$21bb6f70$65324e50$@apache.org> <7659efda-ed64-093b-c69b-b5af767768c1@oracle.com> <073701d761de$e8317bb0$b8947310$@apache.org> <9cd30ea5-2be3-5bf4-b487-d4ef15c93a3c@oracle.com> Message-ID: On 17/06/2021 18:56, leerho wrote: > Maurizio, > Wow! Thanks! > > You clearly put a lot of work into these changes!? You completely > rewrote the test class using tools that I was not aware of as well as > simplifications of the ultimate code.? I was pleased that at least the > basic concept of the tests survived. Hopefully the test logic should be the same. The only think in the test which did not survive was the fact that for float and doubles, the old logic started the segment with Math.PI. The new logic just works in bytes and always starts at 0. We could tweak that if required, but IMHO initializing segment with bytes should always be good enough? > > I am very grateful for the time you spent on this! You're welcome - thanks a lot for the help on this one! Maurizio > > Cheers, > Lee. > > > > On Thu, Jun 17, 2021 at 8:44 AM Maurizio Cimadamore > > wrote: > > I've finalized the PR, it is now a full PR which is ready for > review. I > did some passes over the code and fix some things here and there, > hopefully nothing too controversial. > > Cheers > Maurizio > > On 16/06/2021 16:56, Maurizio Cimadamore wrote: > > Hi Lee, > > I've updated the PR with your latest changes. Everything works > fine - > > there were some trailing whitespaces that I fixed, other than > that the > > test works ok. > > > > Maurizio > > > > On 15/06/2021 20:06, leerho wrote: > >> Maurizio, > >> I have updated the *MemoryCopy* and *TestMemoryCopy* to include > >> references to the new *MemorySegment::CopyFrom(...)* and with byte > >> swap capabilities. > >> > >> I have been able to test the code in my local environment using a > >> mock substitute for the new CopyFrom(), but alas, I could not get > >> Jtreg to work, so i am sending you the code as updated in > >> https://github.com/leerho/mcimadamore_panama-foreign > > > >> > > > >> > >> Please test it, when you have a chance. > >> > >> Lee. > >> > >> > >> On Tue, Jun 15, 2021 at 5:43 AM Maurizio Cimadamore > >> > >> >> wrote: > >> > >> > >> ??? >> The reason why copying is slower for small segments is > that, I > >> ??? think, my > >> ??? >> benchmark iterations run in 4-5ns and, at these levels, > you are > >> ??? >> sensitive to the cost of the liveness checks. There's > not a lot > >> ??? we can > >> ??? >> do to eliminate that - it's the price of safety. > >> ??? > OK that's true. But in my own Unsafe.copyMemory code wasn't > >> ??? doing MemorySegment.address().toRawLongValue() not also > doing the > >> ??? liveness check? > >> ??? True - so the liveness check probably that won't make a lot of > >> ??? difference in your case. But note that the bound checks are > still > >> ??? applied in MemorySegment::copyMemory. > >> ??? > > >> ??? >> The good news is that in the case of heap segment > wrappers, we > >> know > >> ??? >> exactly that the size is gonna fit inside an int (it's > an array > >> ??? after > >> ??? >> all!), so we can remove the check. If we remove the flag > check, > >> ??? and just > >> ??? >> set the segment to always be treated as "SMALL", we get the > >> ??? following > >> ??? >> results: > >> ??? > Is this really true? What about a huge long[] array, that > could > >> ??? be (2^31-8 maximum index) * 8 bytesPerLong = 16 gigabytes? > (or are > >> ??? those limited by the Java standard in maximum array size?) > >> ??? in the PR I've submitted I only tweaked byte segment > wrappers. We > >> ??? could > >> ??? resort to more complex internal representation for other heap > >> ??? segments, > >> ??? but I believe the true way forward is to wait for the long > >> ??? optimizations, and to completely remove the SMALL segment > hacks. > >> ??? > > >> ??? > Sorry, I missed that class. I was opening the pull > request and > >> ??? only looked at the red/green changes in MemorySegment. I missed > >> ??? the first class. > >> ??? > > >> ??? > The methods provided there exactly replace my three shapes in > >> ??? the code. And on top they allow to swap. Side note: > MemoryCopy in > >> ??? the current PR has the swapping code commented out. > >> ??? Yeah - Lee is working on that MemoryCopy class (and associated > >> ??? test). I > >> ??? have provided the "swappy" copyFrom overload in > MemorySegment, I > >> ??? believe > >> ??? Lee will add support for that soon. > >> ??? > > >> ??? > Last question: why does > >> https://bugs.openjdk.java.net/browse/JDK-8223051 > > >> ??? > not help for > >> ??? the integer vs. long loop variables? Does this not allow to > remove > >> ??? the small vs. large segment distinction? I thought this > change in > >> ??? hotspot was added to support long loops, if it is in fact > "small". > >> > >> ??? My understanding is that the change has been split in multiple > >> ??? chunks. > >> ??? The chunk we mostly depend on is this: > >> > >> https://bugs.openjdk.java.net/browse/JDK-8259609 > > >> ??? > > >> > >> ??? (in fact I'm coordinating with Roland, the author of that work, > >> ??? and he's > >> ??? testing the patch against a version of panama which doesn't > have > >> ??? workarounds for small segments). > >> > >> ??? I did run all Panama benchmarks after JDK-8223051 was > pushed, and > >> ??? removed various workarounds, but? there was still a > performance gap. > >> ??? Roland reassured me that the gap should disappear once > >> JDK-8259609 is > >> ??? pushed. > >> > >> ??? Maurizio > >> > >> ??? > > >> ??? > Uwe > >> ??? > > >> > From leerho at gmail.com Thu Jun 17 18:51:40 2021 From: leerho at gmail.com (leerho) Date: Thu, 17 Jun 2021 11:51:40 -0700 Subject: Memory Segment efficient array handling In-Reply-To: References: <08a001d726ec$f3bd0f30$db372d90$@apache.org> <5d67aba5-e7c8-620c-41ec-0daf396f0d96@oracle.com> <04e101d761c8$67896510$369c2f30$@apache.org> <265ceecd-941a-127b-e2e7-5462f190291c@oracle.com> <06d701d761d1$21bb6f70$65324e50$@apache.org> <7659efda-ed64-093b-c69b-b5af767768c1@oracle.com> <073701d761de$e8317bb0$b8947310$@apache.org> <9cd30ea5-2be3-5bf4-b487-d4ef15c93a3c@oracle.com> Message-ID: Initializing the float and double segments with integers {0,1,...} is OK. My only thought was to have at least one test where all the bytes had values other than zero -- to make sure all the bytes were being swapped correctly. Swapping bytes of zero is hard to determine correctness :-) What you did allows leverage of the same code for all the primitives, which simplifies things a lot. Lee. On Thu, Jun 17, 2021 at 10:59 AM Maurizio Cimadamore < maurizio.cimadamore at oracle.com> wrote: > > On 17/06/2021 18:56, leerho wrote: > > Maurizio, > Wow! Thanks! > > > You clearly put a lot of work into these changes! You completely rewrote > the test class using tools that I was not aware of as well as > simplifications of the ultimate code. I was pleased that at least the > basic concept of the tests survived. > > Hopefully the test logic should be the same. The only think in the test > which did not survive was the fact that for float and doubles, the old > logic started the segment with Math.PI. The new logic just works in bytes > and always starts at 0. > > We could tweak that if required, but IMHO initializing segment with bytes > should always be good enough? > > > I am very grateful for the time you spent on this! > > You're welcome - thanks a lot for the help on this one! > > Maurizio > > > Cheers, > Lee. > > > > On Thu, Jun 17, 2021 at 8:44 AM Maurizio Cimadamore < > maurizio.cimadamore at oracle.com> wrote: > >> I've finalized the PR, it is now a full PR which is ready for review. I >> did some passes over the code and fix some things here and there, >> hopefully nothing too controversial. >> >> Cheers >> Maurizio >> >> On 16/06/2021 16:56, Maurizio Cimadamore wrote: >> > Hi Lee, >> > I've updated the PR with your latest changes. Everything works fine - >> > there were some trailing whitespaces that I fixed, other than that the >> > test works ok. >> > >> > Maurizio >> > >> > On 15/06/2021 20:06, leerho wrote: >> >> Maurizio, >> >> I have updated the *MemoryCopy* and *TestMemoryCopy* to include >> >> references to the new *MemorySegment::CopyFrom(...)* and with byte >> >> swap capabilities. >> >> >> >> I have been able to test the code in my local environment using a >> >> mock substitute for the new CopyFrom(), but alas, I could not get >> >> Jtreg to work, so i am sending you the code as updated in >> >> https://github.com/leerho/mcimadamore_panama-foreign >> >> >> < >> https://urldefense.com/v3/__https://github.com/leerho/mcimadamore_panama-foreign__;!!GqivPVa7Brio!MZMNJXVSSBqQxv9G2nXnY-wpuBdgPpwIvBCl6CuzkZLWKaRjEAPnl1FHib5FeUyX3rF3rRU$ >> > >> >> >> >> Please test it, when you have a chance. >> >> >> >> Lee. >> >> >> >> >> >> On Tue, Jun 15, 2021 at 5:43 AM Maurizio Cimadamore >> >> > >> > wrote: >> >> >> >> >> >> >> The reason why copying is slower for small segments is that, I >> >> think, my >> >> >> benchmark iterations run in 4-5ns and, at these levels, you are >> >> >> sensitive to the cost of the liveness checks. There's not a lot >> >> we can >> >> >> do to eliminate that - it's the price of safety. >> >> > OK that's true. But in my own Unsafe.copyMemory code wasn't >> >> doing MemorySegment.address().toRawLongValue() not also doing the >> >> liveness check? >> >> True - so the liveness check probably that won't make a lot of >> >> difference in your case. But note that the bound checks are still >> >> applied in MemorySegment::copyMemory. >> >> > >> >> >> The good news is that in the case of heap segment wrappers, we >> >> know >> >> >> exactly that the size is gonna fit inside an int (it's an array >> >> after >> >> >> all!), so we can remove the check. If we remove the flag check, >> >> and just >> >> >> set the segment to always be treated as "SMALL", we get the >> >> following >> >> >> results: >> >> > Is this really true? What about a huge long[] array, that could >> >> be (2^31-8 maximum index) * 8 bytesPerLong = 16 gigabytes? (or are >> >> those limited by the Java standard in maximum array size?) >> >> in the PR I've submitted I only tweaked byte segment wrappers. We >> >> could >> >> resort to more complex internal representation for other heap >> >> segments, >> >> but I believe the true way forward is to wait for the long >> >> optimizations, and to completely remove the SMALL segment hacks. >> >> > >> >> > Sorry, I missed that class. I was opening the pull request and >> >> only looked at the red/green changes in MemorySegment. I missed >> >> the first class. >> >> > >> >> > The methods provided there exactly replace my three shapes in >> >> the code. And on top they allow to swap. Side note: MemoryCopy in >> >> the current PR has the swapping code commented out. >> >> Yeah - Lee is working on that MemoryCopy class (and associated >> >> test). I >> >> have provided the "swappy" copyFrom overload in MemorySegment, I >> >> believe >> >> Lee will add support for that soon. >> >> > >> >> > Last question: why does >> >> https://bugs.openjdk.java.net/browse/JDK-8223051 >> >> not help for >> >> the integer vs. long loop variables? Does this not allow to remove >> >> the small vs. large segment distinction? I thought this change in >> >> hotspot was added to support long loops, if it is in fact "small". >> >> >> >> My understanding is that the change has been split in multiple >> >> chunks. >> >> The chunk we mostly depend on is this: >> >> >> >> https://bugs.openjdk.java.net/browse/JDK-8259609 >> >> >> >> >> >> (in fact I'm coordinating with Roland, the author of that work, >> >> and he's >> >> testing the patch against a version of panama which doesn't have >> >> workarounds for small segments). >> >> >> >> I did run all Panama benchmarks after JDK-8223051 was pushed, and >> >> removed various workarounds, but there was still a performance >> gap. >> >> Roland reassured me that the gap should disappear once >> >> JDK-8259609 is >> >> pushed. >> >> >> >> Maurizio >> >> >> >> > >> >> > Uwe >> >> > >> >> >> > From jbhateja at openjdk.java.net Thu Jun 17 19:32:43 2021 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Thu, 17 Jun 2021 19:32:43 GMT Subject: [vectorIntrinsics+mask] RFR: 8266287: Basic mask IR implementation for the Vector API masking feature support [v2] In-Reply-To: References: Message-ID: On Wed, 16 Jun 2021 09:34:46 GMT, Xiaohong Gong wrote: >> src/hotspot/share/opto/vectorIntrinsics.cpp line 84: >> >>> 82: assert(check_vbox(vbox_type), ""); >>> 83: const TypeVect* vt = is_vector_mask(vbox_type->klass()) ? >>> 84: TypeVect::makemask(elem_bt, num_elem) : TypeVect::make(elem_bt, num_elem); >> >> Box type which is an envelope type should still be the same e.g. Int256VectorMask. Value contained in the Masked Box should be of type vectmask. > > Hi @jatin-bhateja , it seems the type of `VectorBox/VectorUnbox` should be exactly matched with the `value` boxed. For such an optimization `// VectorUnbox (VectorBox v) ==> v`, if the type of `v` is a vector mask type while the `VectorUnbox` type is expected to be a vector type, the final result of this optimization would change the result type of `VectorUnbox` to be a mask type. Some type checks or assertion will fail. I met the following issue when I run the jtreg tests after changing type of `VectorBox/VectorUnbox` back to vector type: > > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (/home/ent-user/panama-vector/src/hotspot/share/opto/type.cpp:2412), pid=433543, tid=433698 > # Error: assert(base() == v->base()) failed > # > # JRE version: OpenJDK Runtime Environment (17.0) (fastdebug build 17-internal+0-git-8123588d66) > # Java VM: OpenJDK 64-Bit Server VM (fastdebug 17-internal+0-git-8123588d66, mixed mode, sharing, compressed oops, compressed class ptrs, g1 gc, linux-aarch64) > # Problematic frame: > # V [libjvm.so+0x19f3108] TypeVect::xmeet(Type const*) const+0x138 > # > # Core dump will be written. Default location: Core dumps may be processed with "/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h %e" (or dumping to /home/ent-user/jtreg/jtreg-hg/build/images/jtreg/jtwork/scratch/2/core.433543) > # > # If you would like to submit a bug report, please visit: > # https://bugreport.java.com/bugreport/crash.jsp > > Do you have any strong reason that we must define a vector type for `VectorBox/VectorUnbox`? VectorBoxNode and VectorUnboxNode are macro nodes and carry the vector type which comply with the species i.e. for IntVector.SPECIES_256, vector type of Box/Unbox should be TypeVect(T_INT,8), both these nodes needs to be expanded as per following expansion rules:- a) VectorBox mask(TypeVectMask) ====> VectorStoreMask + StoreVector. b) VectorUnbox mask =====> LoadVector + VectorLoadMask (TypeVectMask) c) VectorUnbox (VectorBox mask) ====> VectorStoreMask(TypeVectMask) + StoreVector + LoadVector + VectorLoadMask(TypeVectMask) An optimization over VectorUnboxNode should consult the type of VectorBoxNode and vice-versa, similarly any optimization involving VectorLoadMaskNode should comply with type of VectoStoreMaskNode, there cannot be a mix-match, if there is any such case it needs to be fixed like the following handling https://github.com/openjdk/panama-vector/pull/90#pullrequestreview-679559503 Can you kindly share the tests which failed. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/78 From mail at smogura.eu Thu Jun 17 22:14:34 2021 From: mail at smogura.eu (=?windows-1250?Q?Rados=B3aw_Smogura?=) Date: Thu, 17 Jun 2021 22:14:34 +0000 Subject: ODP: Foreign + Vectors - benchmarks for copying and swapping In-Reply-To: <5290e44a-7c67-6ee6-57dc-9af646604082@oracle.com> References: , <5290e44a-7c67-6ee6-57dc-9af646604082@oracle.com> Message-ID: Hi Maurizio & Paul, I pushed the changed benchmarks, and added tests with different copy sizes. Direct byte buffer gives bigger times (I guess size is not compile time constant) - I can't find good way to make tests simillar. I think shared buffer higher times can be a same case. For endianess, I'm not sure how to check it, but it may not be a case, I try to use native order, and operate on bytes. Additonally, In test copyWithVectorUnroller when I uncomment this lines before entering loop final var v = ByteVector.fromByteBuffer(BYTE_VECTOR_SPECIES, src, i + 0 * lanes, ByteOrder.nativeOrder()); v.intoByteBuffer(dst, i + 0 * lanes, ByteOrder.nativeOrder()); results are much better for 1M data copy case Benchmark (size) Mode Cnt Score Error Units VectorCopySegments.copyWithVectorUnroller 1024 avgt 10 168.602 ? 1.260 ns/op VectorCopySegments.copyWithVectorUnroller 1048576 avgt 10 60381.901 ? 374.981 ns/op (missed loop peeling due to too big loop?) And that's pitty that shuffle can't reverse bytes order in int in performant way... --- Benchmark (size) Mode Cnt Score Error Units VectorCopySegments.copyWithNative 1024 avgt 10 20.098 ? 0.392 ns/op VectorCopySegments.copyWithNative 1048576 avgt 10 22211.497 ? 257.794 ns/op VectorCopySegments.copyWithNativeShared 1024 avgt 10 15.728 ? 0.133 ns/op VectorCopySegments.copyWithNativeShared 1048576 avgt 10 22066.399 ? 214.858 ns/op VectorCopySegments.copyWithNativeToArray 1024 avgt 10 20.298 ? 0.110 ns/op VectorCopySegments.copyWithNativeToArray 1048576 avgt 10 21862.090 ? 268.311 ns/op VectorCopySegments.copyWithVector 1024 avgt 10 30.841 ? 0.119 ns/op VectorCopySegments.copyWithVector 1048576 avgt 10 44834.639 ? 746.965 ns/op VectorCopySegments.copyWithVectorDirectBuffer 1024 avgt 10 44.977 ? 0.571 ns/op VectorCopySegments.copyWithVectorDirectBuffer 1048576 avgt 10 49211.524 ? 2602.650 ns/op VectorCopySegments.copyWithVectorShared 1024 avgt 10 56.082 ? 0.619 ns/op VectorCopySegments.copyWithVectorShared 1048576 avgt 10 62226.674 ? 1690.624 ns/op VectorCopySegments.copyWithVectorShuffle 1024 avgt 10 47.797 ? 0.672 ns/op VectorCopySegments.copyWithVectorShuffle 1048576 avgt 10 61171.416 ? 5656.479 ns/op VectorCopySegments.copyWithVectorToArray 1024 avgt 10 31.070 ? 0.736 ns/op VectorCopySegments.copyWithVectorToArray 1048576 avgt 10 38653.328 ? 489.896 ns/op VectorCopySegments.copyWithVectorUnroller 1024 avgt 10 49.522 ? 1.027 ns/op VectorCopySegments.copyWithVectorUnroller 1048576 avgt 10 72145.653 ? 987.111 ns/op Kind regards, Rado ________________________________ Od: Maurizio Cimadamore Wys?ane: czwartek, 17 czerwca 2021 18:12 Do: Paul Sandoz ; Rados?aw Smogura DW: panama-dev at openjdk.java.net Temat: Re: Foreign + Vectors - benchmarks for copying and swapping Would be interesting to see if passing in regular byte buffers (e.g. not derived from segments) improve things. A regular byte buffer should not have any liveness check, so the overhead might be somewhat lower, although it seems, as Paul says, that the benchmark is affected by non-optimized bound checks. Also - maybe it's a silly comment - but did you double check the endianness of the returned buffer? The memory segment API returns BIG_ENDIAN buffers (as it's the case for buffers allocated with ByteBuffer.allocateDirect). Is it possible you are using mismatched endiannes? Maurizio On 17/06/2021 17:00, Paul Sandoz wrote: > Hi Rado, > > Thanks, an interesting experiment. > > We would need to look the generated code to spot issues. Hard to compete with a specialized and highly optimized intrinsic copy. Still, it seems we should be able to do better. > > I suspect there might be some un-hoisted bounds checks, or non-optimal addressing of loads/stores. > > Something odd going on with shared access. > > I doubt the use of shuffle can compete in general with the byte swapping in the intrinsic copy, but we are still ironing out performance issues with shuffle so maybe there is some room for improvement. (Further, we don?t do anything special with for certain constant shuffle patterns from which we might be able to select more optimal instructions.) > > Paul. > >> On Jun 16, 2021, at 5:15 PM, Rados?aw Smogura wrote: >> >> Hi all, >> >> I could not stop my self, from this simple experiment of glueing together foreign with vectors, at least via byte buffers for now. >> >> Results are not the best, but still could be interesting, as there was some interest with this. >> >> Below please find results, and the link to benchmark: >> >> Benchmark Mode Cnt Score Error Units >> VectorCopySegments.copyWithNative avgt 10 20.987 ? 1.819 ns/op >> VectorCopySegments.copyWithNativeShared avgt 10 12.528 ? 0.183 ns/op >> VectorCopySegments.copyWithNativeToArray avgt 10 19.800 ? 3.985 ns/op >> VectorCopySegments.copyWithVector avgt 10 31.151 ? 1.929 ns/op >> VectorCopySegments.copyWithVectorShared avgt 10 56.752 ? 1.754 ns/op >> VectorCopySegments.copyWithVectorShuffle avgt 10 52.409 ? 0.390 ns/op >> VectorCopySegments.copyWithVectorToArray avgt 10 29.573 ? 0.485 ns/op >> >> https://github.com/rsmogura/panama-foreign/blob/foreign_and_vectors/test/micro/org/openjdk/bench/jdk/incubator/foreign/VectorCopySegments.java >> >> Feedback is welcome. >> >> Kind regards, >> Rado From elect86 at gmail.com Fri Jun 18 07:59:59 2021 From: elect86 at gmail.com (Giuseppe Barbieri) Date: Fri, 18 Jun 2021 09:59:59 +0200 Subject: jdk18? Message-ID: Has panama just moved on jdk18? I see today that the jdk building is producing Creating jdk-18-internal+0_linux-x64_bin.tar.gz Creating jdk-18-internal+0_linux-x64_bin-symbols.tar.gz Creating jdk-18-internal+0_linux-x64_bin-tests-demos.tar.gz Just wondering if I messed up something or this is fine Giuseppe From maurizio.cimadamore at oracle.com Fri Jun 18 08:09:10 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 18 Jun 2021 09:09:10 +0100 Subject: ODP: Foreign + Vectors - benchmarks for copying and swapping In-Reply-To: References: <5290e44a-7c67-6ee6-57dc-9af646604082@oracle.com> Message-ID: <1a23ee05-f187-e6d8-900e-62e77cd73dc9@oracle.com> On 17/06/2021 23:14, Rados?aw Smogura wrote: > For endianess, I'm not sure how to check it, but it may not be a case, > I try to use native order, and operate on bytes. I guess what I mean is: https://github.com/rsmogura/panama-foreign/blob/foreign_and_vectors/test/micro/org/openjdk/bench/jdk/incubator/foreign/VectorCopySegments.java#L91 Should this be: ``` final var src = srcAddress.asSegment(size, scope).asByteBuffer().order(ByteOrder.nativeOrder()); ``` And same for other derived buffers? You then use it as this: ``` final var srcVector = ByteVector.fromByteBuffer(BYTE_VECTOR_SPECIES, src, i, ByteOrder.nativeOrder()); ``` Which does smell like mismatched access? Cheers Maurizio From maurizio.cimadamore at oracle.com Fri Jun 18 08:13:41 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 18 Jun 2021 09:13:41 +0100 Subject: jdk18? In-Reply-To: References: Message-ID: <4d552804-946a-7481-9165-bace2544b14b@oracle.com> Panama tracks jdk/jdk - since jdk/jdk recently received a version bump, the panama repo picked that up too. I think this is to be expected. Cheers Maurizio On 18/06/2021 08:59, Giuseppe Barbieri wrote: > Has panama just moved on jdk18? > > I see today that the jdk building is producing > > Creating jdk-18-internal+0_linux-x64_bin.tar.gz > Creating jdk-18-internal+0_linux-x64_bin-symbols.tar.gz > Creating jdk-18-internal+0_linux-x64_bin-tests-demos.tar.gz > > Just wondering if I messed up something or this is fine > > > Giuseppe From xgong at openjdk.java.net Fri Jun 18 08:21:05 2021 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Fri, 18 Jun 2021 08:21:05 GMT Subject: [vectorIntrinsics+mask] RFR: 8266287: Basic mask IR implementation for the Vector API masking feature support [v2] In-Reply-To: References: Message-ID: On Thu, 17 Jun 2021 19:29:28 GMT, Jatin Bhateja wrote: >> Hi @jatin-bhateja , it seems the type of `VectorBox/VectorUnbox` should be exactly matched with the `value` boxed. For such an optimization `// VectorUnbox (VectorBox v) ==> v`, if the type of `v` is a vector mask type while the `VectorUnbox` type is expected to be a vector type, the final result of this optimization would change the result type of `VectorUnbox` to be a mask type. Some type checks or assertion will fail. I met the following issue when I run the jtreg tests after changing type of `VectorBox/VectorUnbox` back to vector type: >> >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # Internal Error (/home/ent-user/panama-vector/src/hotspot/share/opto/type.cpp:2412), pid=433543, tid=433698 >> # Error: assert(base() == v->base()) failed >> # >> # JRE version: OpenJDK Runtime Environment (17.0) (fastdebug build 17-internal+0-git-8123588d66) >> # Java VM: OpenJDK 64-Bit Server VM (fastdebug 17-internal+0-git-8123588d66, mixed mode, sharing, compressed oops, compressed class ptrs, g1 gc, linux-aarch64) >> # Problematic frame: >> # V [libjvm.so+0x19f3108] TypeVect::xmeet(Type const*) const+0x138 >> # >> # Core dump will be written. Default location: Core dumps may be processed with "/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h %e" (or dumping to /home/ent-user/jtreg/jtreg-hg/build/images/jtreg/jtwork/scratch/2/core.433543) >> # >> # If you would like to submit a bug report, please visit: >> # https://bugreport.java.com/bugreport/crash.jsp >> >> Do you have any strong reason that we must define a vector type for `VectorBox/VectorUnbox`? > > VectorBoxNode and VectorUnboxNode are macro nodes and carry the vector type which comply with the species i.e. for IntVector.SPECIES_256, vector type of Box/Unbox should be TypeVect(T_INT,8), both these nodes needs to be expanded as per following expansion rules:- > > a) VectorBox mask(TypeVectMask) ====> VectorStoreMask + StoreVector. > b) VectorUnbox mask =====> LoadVector + VectorLoadMask (TypeVectMask) > c) VectorUnbox (VectorBox mask) ====> VectorStoreMask(TypeVectMask) + StoreVector + LoadVector + VectorLoadMask(TypeVectMask) > > An optimization over VectorUnboxNode should consult the type of VectorBoxNode and vice-versa, similarly any optimization involving VectorLoadMaskNode should comply with type of VectoStoreMaskNode, there cannot be a mix-match, if there is any such case it needs to be fixed like the following handling > https://github.com/openjdk/panama-vector/pull/90#pullrequestreview-679559503 > > Can you kindly share the tests which failed. Hi @jatin-bhateja , sorry for my late replying! I didn't save the log and tests. It needs some time for me now. I will try to show you the cases new Monday. OK for you? Thanks! ------------- PR: https://git.openjdk.java.net/panama-vector/pull/78 From xgong at openjdk.java.net Fri Jun 18 08:21:02 2021 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Fri, 18 Jun 2021 08:21:02 GMT Subject: [vectorIntrinsics+mask] RFR: 8266287: Basic mask IR implementation for the Vector API masking feature support [v2] In-Reply-To: <-H3L1H_i6wkKkWsHNLnZUSnirwYNdwXfcVV8VCrFsic=.e96337d8-d361-4d71-902e-156d2ea46d5b@github.com> References: <-H3L1H_i6wkKkWsHNLnZUSnirwYNdwXfcVV8VCrFsic=.e96337d8-d361-4d71-902e-156d2ea46d5b@github.com> Message-ID: On Fri, 14 May 2021 16:20:02 GMT, Vladimir Ivanov wrote: >> Xiaohong Gong has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: >> >> - Use "Flag_is_predicated_vector" for masked vector nodes >> - Merge branch 'vectorIntrinsics+mask' >> - 8266287: Basic mask IR implementation for the Vector API masking feature support > > Can you elaborate, please, what's the purpose of new nodes? > > There's some duplication with existing vector nodes and I'd like to understand how do you intend to merge them. > > `LoadVectorMask`/`StoreVectorMask` duplicate `VectorLoadMask (LoadVector)`/`StoreVector (VectorStoreMask)`. What kind of benefits do you expect from exposing the operation as a single node? > > Depending on how `MaskToVector`/`VectorToMask` are specified, they can duplicate `VectorStoreMask`/`VectorLoadMask`. > > If mask value always has a vector type,`AndVMask`/`OrVMask`/`XorVMask` can be replaced by `AndV`/`OrV`/`XorV` and special implementations for 2 representations (canonical and native). Same considerations apply to `VectorCmpMaskGen` (compared to `VectorMaskCmp`). > > What is left is `MaskAll`, but its purpose is not evident to me. Broadcast, but for masks? Hi @iwanowww @jatin-bhateja , Regarding to the mask IRs for SVE/AVX-512, it's ok for me to reuse most of the existing IRs both for SVE/AVX-512 and other platforms. I agree that it can work well by defining different types for different platforms (i.e. `TypeVectMask` for SVE/AVX-512 while `TypeVect` for others). The benefit is that it doesn't need to add more new IRs. And the compiler can define the right register for vector mask according to its bottom type. So some mask related IRs (`VectorLoadMask, VectorMaskCmp, VectorMaskCast`) can be reused. However, to separate the vector and vector mask operations for SVE/AVX-512, we think it's better to define new IRs for vector mask for nodes that could be both vector and vector mask like (AndV/OrV/XorV/Replicate). So the following new IRs will be added for mask? AndVMask, OrVMask, XorVMask, MaskAll These IRs can also be used for other platforms that do not support predicate features. Further more, considering the performance of vector mask loading/storing with SVE, the following optimizations are also needed: fromArray: LoadVector + VectorLoadMask ==> LoadVectorMask (load + type extending) intoArray: VectorStoreMask + StoreVector ==> StoreVectorMask (type narrowing + store) Does this solution make sense to you? Any feedback from you are helpful and welcome, and hope we can have a conclusion for the mask IR definition part. Thanks so much! Best Regards, Xiaohong ------------- PR: https://git.openjdk.java.net/panama-vector/pull/78 From duke at openjdk.java.net Fri Jun 18 11:03:22 2021 From: duke at openjdk.java.net (duke) Date: Fri, 18 Jun 2021 11:03:22 GMT Subject: git: openjdk/panama-foreign: master: 41 new changesets Message-ID: <46e87c5f-d33d-4280-b075-ac4a78c30ff1@openjdk.org> Changeset: af13fe11 Author: Coleen Phillimore Date: 2021-06-16 12:41:51 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/af13fe110720ff20ccea0a01fe088707208c3dd8 8267870: Remove unnecessary char_converter during class loading Reviewed-by: dholmes, iklam ! src/hotspot/share/cds/classListParser.cpp ! src/hotspot/share/classfile/javaAssertions.cpp ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/classfile/javaClasses.hpp ! src/hotspot/share/classfile/systemDictionary.cpp Changeset: 72b3b0af Author: Coleen Phillimore Date: 2021-06-16 12:43:11 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/72b3b0af08136342e54e1cdea0c48d64172e8870 8267752: KVHashtable doesn't deallocate entries Reviewed-by: iklam, stuefe ! src/hotspot/share/utilities/hashtable.hpp Changeset: e4908a43 Author: Ioi Lam Date: 2021-06-16 16:05:19 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e4908a439a235ee437c0e6e39341e1d67904f49e 8268778: CDS check_excluded_classes needs DumpTimeTable_lock Reviewed-by: ccheung, minqi ! src/hotspot/share/cds/dynamicArchive.cpp ! src/hotspot/share/cds/metaspaceShared.cpp ! src/hotspot/share/classfile/systemDictionaryShared.cpp Changeset: c20f80a4 Author: Coleen Phillimore Date: 2021-06-16 16:34:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c20f80a4d2e8d0f5995ad44a38e838adbff6068d 8259066: Obsolete -XX:+AlwaysLockClassLoader Reviewed-by: hseigel ! src/hotspot/share/classfile/systemDictionary.cpp ! src/hotspot/share/runtime/globals.hpp Changeset: b836b83b Author: Rajan Halade Date: 2021-06-16 17:10:40 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b836b83b2aefbc87b0cf26990ddbab4479c42b71 8259338: Add expiry exception for identrustdstx3 alias to VerifyCACerts.java test Reviewed-by: xuelei ! test/jdk/sun/security/lib/cacerts/VerifyCACerts.java Changeset: 02c9bf08 Author: Xin Liu Committer: David Holmes Date: 2021-06-16 23:54:21 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/02c9bf087e50885bbc8028415c4e674947ee7a16 8268852: AsyncLogWriter should not overide is_Named_thread() Reviewed-by: dholmes, ysuenaga ! src/hotspot/share/logging/logAsyncWriter.hpp ! src/hotspot/share/runtime/thread.cpp Changeset: 10068c1b Author: Daniel D. Daugherty Date: 2021-06-15 21:48:36 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/10068c1bace0ea650bda3e2234a44cbf401afc7d 8268830: ProblemList 3 serviceability/dcmd/framework tests with ZGC on win-x64 Reviewed-by: kbarrett ! test/hotspot/jtreg/ProblemList-zgc.txt Changeset: b18de6cf Author: Daniel D. Daugherty Date: 2021-06-15 23:50:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b18de6cf79e0195736d94b08be67f10ca7c3cd08 8268851: ProblemList jdk/jfr/event/gc/detailed/TestEvacuationFailedEvent.java on linux-X64 Reviewed-by: bpb ! test/jdk/ProblemList.txt Changeset: 4d545a1f Author: Roland Westrelin Date: 2021-06-16 07:36:07 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4d545a1f86325140ed268c5437d776ceb8e21077 8267988: C2: assert(!addp->is_AddP() || addp->in(AddPNode::Base)->is_top() || addp->in(AddPNode::Base) == n->in(AddPNode::Base)) failed: Base pointers must match (addp 1301) Reviewed-by: chagedorn, vlivanov, kvn ! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp ! src/hotspot/share/opto/castnode.cpp ! src/hotspot/share/opto/castnode.hpp ! src/hotspot/share/opto/cfgnode.cpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/loopTransform.cpp ! src/hotspot/share/opto/loopopts.cpp + test/hotspot/jtreg/compiler/loopopts/TestAddPChainWithDifferentBase.java Changeset: 59de99d1 Author: Stefan Johansson Date: 2021-06-16 08:59:07 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/59de99d11988b7f1ab20e323f3dc4d0d49e3b7a3 8267271: Fix gc/arguments/TestNewRatioFlag.java expectedNewSize calculation Reviewed-by: tschatzl, kbarrett ! test/hotspot/jtreg/gc/arguments/TestNewRatioFlag.java Changeset: 19f5fab1 Author: David Holmes Date: 2021-06-16 11:59:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/19f5fab175e308e2ab90d6d3efc2335fe751009e 8268861: Disable Windows-Aarch64 build in GitHub Actions Reviewed-by: mikael, sjohanss ! .github/workflows/submit.yml Changeset: 9ad19f78 Author: Christian Hagedorn Date: 2021-06-16 13:02:51 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9ad19f7838e6f6e128583c191c5507c1e2bd5083 8256934: C2: assert(C->live_nodes() <= C->max_node_limit()) failed: Live Node limit exceeded limit Reviewed-by: roland, vlivanov ! src/hotspot/share/opto/loopopts.cpp + test/hotspot/jtreg/compiler/loopopts/TestPartialPeelingSinkNodes.java Changeset: 38dbe05e Author: Bradford Wetmore Date: 2021-06-16 16:59:02 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/38dbe05e004a018c810e3acaae4660c69dd982da 8268901: JDK-8268768 missed removing two files Reviewed-by: mcimadamore - make/ide/idea/jdk/template/module.iml - make/ide/idea/jdk/template/test.iml Changeset: 8ea0606a Author: Daniel Fuchs Date: 2021-06-16 17:24:06 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8ea0606aba15911f5bfe2c81a83b42288d97095f 8268714: [macos-aarch64] 7 java/net/httpclient/websocket tests failed Reviewed-by: chegar, michaelm ! test/jdk/java/net/httpclient/ISO_8859_1_Test.java ! test/jdk/java/net/httpclient/websocket/DummyWebSocketServer.java ! test/jdk/java/net/httpclient/websocket/PendingBinaryPingClose.java ! test/jdk/java/net/httpclient/websocket/PendingBinaryPongClose.java ! test/jdk/java/net/httpclient/websocket/PendingPingBinaryClose.java ! test/jdk/java/net/httpclient/websocket/PendingPingTextClose.java ! test/jdk/java/net/httpclient/websocket/PendingPongBinaryClose.java ! test/jdk/java/net/httpclient/websocket/PendingPongTextClose.java ! test/jdk/java/net/httpclient/websocket/PendingTextPongClose.java ! test/jdk/java/net/httpclient/websocket/Support.java ! test/jdk/java/net/httpclient/websocket/WSHandshakeExceptionTest.java ! test/jdk/java/net/httpclient/websocket/WebSocketProxyTest.java Changeset: 2c7e47e1 Author: Jonathan Gibbons Date: 2021-06-16 18:03:48 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2c7e47e12b8a772bcebcdf0b15d6a4d3f92e2267 8268774: Residual logging output written to STDOUT, not STDERR Reviewed-by: prappo, hannesw ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/Start.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/ToolEnvironment.java ! test/langtools/jdk/javadoc/tool/ToolProviderTest.java ! test/langtools/jdk/javadoc/tool/testLocaleOption/TestLocaleOption.java + test/langtools/jdk/javadoc/tool/testToolStreams/TestToolStreams.java Changeset: 54f5ffea Author: Rajan Halade Date: 2021-06-16 18:53:37 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/54f5ffeaad9da7cc77d9b6c0339758340c42ea2e 8259338: Add expiry exception for identrustdstx3 alias to VerifyCACerts.java test Backport-of: b836b83b2aefbc87b0cf26990ddbab4479c42b71 ! test/jdk/sun/security/lib/cacerts/VerifyCACerts.java Changeset: f0f21788 Author: Daniel D. Daugherty Date: 2021-06-16 19:19:00 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f0f2178876813cca070db01ce37ea7a04b712923 8268909: ProblemList jdk/jfr/api/consumer/streaming/TestLatestEvent.java on win-x64 Reviewed-by: mikael, dfuchs ! test/jdk/ProblemList.txt Changeset: ee03bc6d Author: Yasumasa Suenaga Date: 2021-06-16 23:21:51 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ee03bc6d0aad4b0d07bbe792c8cc77f986c617e1 8268863: ProblemList serviceability/sa/TestJmapCoreMetaspace.java on linux-x64 with ZGC Reviewed-by: dcubed ! test/hotspot/jtreg/ProblemList-zgc.txt Changeset: 9f7851b5 Author: David Holmes Date: 2021-06-16 23:58:24 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9f7851b5f5220132fce8556269851e33ac06ef31 8260194: Update the documentation for -Xcheck:jni Reviewed-by: coleenp, hseigel ! src/java.base/share/man/java.1 Changeset: 3637e50b Author: Jesper Wilhelmsson Date: 2021-06-17 01:05:54 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3637e50b30e92538510c1a8e8893cedc3bd4ccd5 Merge Changeset: e8446107 Author: David Holmes Date: 2021-06-17 07:02:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e84461072af9cdb2ee83f5c0747ea5881a0ae805 8268927: Windows: link error: unresolved external symbol "int __cdecl convert_to_unicode(char const *,wchar_t * *)" Reviewed-by: stuefe ! src/hotspot/os/windows/os_windows.cpp Changeset: 2d088fa9 Author: Michael McMahon Date: 2021-06-17 07:13:59 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2d088fa91d18252a801db3b84ff87e261d63ebd4 8268294: Reusing HttpClient in a WebSocket.Listener hangs. Reviewed-by: dfuchs ! src/java.net.http/share/classes/jdk/internal/net/http/HttpClientFacade.java ! src/java.net.http/share/classes/jdk/internal/net/http/websocket/MessageDecoder.java ! src/java.net.http/share/classes/jdk/internal/net/http/websocket/MessageEncoder.java ! src/java.net.http/share/classes/jdk/internal/net/http/websocket/WebSocketImpl.java + test/jdk/java/net/httpclient/websocket/WebSocketServerDriver.java + test/jdk/java/net/httpclient/websocket/java.net.http/jdk/internal/net/http/websocket/DefaultMessageStreamHandler.java + test/jdk/java/net/httpclient/websocket/java.net.http/jdk/internal/net/http/websocket/MessageStreamHandler.java + test/jdk/java/net/httpclient/websocket/java.net.http/jdk/internal/net/http/websocket/MessageStreamResponder.java + test/jdk/java/net/httpclient/websocket/java.net.http/jdk/internal/net/http/websocket/WebSocketAndHttpClient.java + test/jdk/java/net/httpclient/websocket/java.net.http/jdk/internal/net/http/websocket/WebSocketAndHttpTest.java + test/jdk/java/net/httpclient/websocket/java.net.http/jdk/internal/net/http/websocket/WebSocketResponder.java + test/jdk/java/net/httpclient/websocket/java.net.http/jdk/internal/net/http/websocket/WebSocketServer.java Changeset: f2afe0a5 Author: Thomas Schatzl Date: 2021-06-17 17:22:09 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f2afe0a5130fd3162403ecc18c827bcf56e9c883 8268556: Use bitmap for storing regions that failed evacuation Reviewed-by: kbarrett, iwalulya, sjohanss ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1CollectedHeap.hpp ! src/hotspot/share/gc/g1/g1CollectedHeap.inline.hpp Changeset: fa3b44d4 Author: Xin Liu Committer: Paul Hohensee Date: 2021-06-17 20:27:14 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fa3b44d43811dca8c609d6c61a58680835abf8e3 8268638: semaphores of AsyncLogWriter may be broken when JVM is exiting. Reviewed-by: dholmes, phh ! src/hotspot/share/logging/logAsyncWriter.cpp ! src/hotspot/share/logging/logAsyncWriter.hpp Changeset: bb24fa65 Author: Ioi Lam Date: 2021-06-17 22:19:23 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bb24fa652aa1edc8ece8713f559be2fe3437d666 8267189: Remove duplicated unregistered classes from dynamic archive Reviewed-by: ccheung, minqi ! src/hotspot/share/cds/classListParser.cpp ! src/hotspot/share/classfile/systemDictionaryShared.cpp ! src/hotspot/share/classfile/systemDictionaryShared.hpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/runtime/mutexLocker.cpp ! src/hotspot/share/runtime/mutexLocker.hpp + test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/DuplicatedCustomTest.java + test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/test-classes/DuplicatedCustomApp.java Changeset: 58e6e6d9 Author: Rajan Halade Date: 2021-06-18 00:49:40 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/58e6e6d919cb15559a61a67805da263be3c9d693 8268678: LetsEncryptCA.java test fails as Let?s Encrypt Authority X3 is retired Reviewed-by: xuelei ! test/jdk/security/infra/java/security/cert/CertPathValidator/certification/LetsEncryptCA.java Changeset: 112ddb76 Author: Jie Fu Date: 2021-06-17 02:10:52 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/112ddb7633d8794d5c85e1b2cf0369ee2e0e349a 8268641: [foreign] assert(allocates2(pc)) failed: not in CodeBuffer memory with ShenandoahGC Reviewed-by: rbackman, kvn ! src/hotspot/cpu/x86/universalUpcallHandler_x86_64.cpp Changeset: 4c9aefdb Author: Eric Liu Committer: Pengfei Li Date: 2021-06-17 02:47:00 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4c9aefdb6193f754bfac3ae022f08a76b0cae718 8268739: AArch64: Build failure after JDK-8267663 Reviewed-by: aph, dholmes ! src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.hpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp Changeset: 344e3edf Author: Julia Boes Date: 2021-06-17 09:10:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/344e3edf7602d8b788334bd103e9a63a8d74a6f8 8268080: java/util/concurrent/forkjoin/AsyncShutdownNow.java fails with java.util.concurrent.RejectedExecutionException Co-authored-by: Doug Lea
Reviewed-by: chegar, dfuchs ! test/jdk/java/util/concurrent/forkjoin/AsyncShutdownNow.java ! test/jdk/java/util/concurrent/forkjoin/AsyncShutdownNowInvokeAny.java Changeset: 7d7bdbe1 Author: Patrick Concannon Date: 2021-06-17 09:35:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7d7bdbe135018f1452fa133b294575014e3e871b 8268776: Test `ADatagramSocket.java` missing /othervm from @run tag Reviewed-by: dfuchs ! test/jdk/java/net/DatagramSocket/SetDatagramSocketImplFactory/ADatagramSocket.java Changeset: 69d01b6b Author: Jonathan Gibbons Date: 2021-06-17 14:09:11 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/69d01b6bcabda177f5e27f6c7b141be57cd00619 8249899: jdk/javadoc/tool/InlineTagsWithBraces.java uses @ignore w/o bug-id 8249897: jdk/javadoc/tool/LangVers.java uses @ignore w/o bug-id 8249898: jdk/javadoc/tool/6176978/T6176978.java uses @ignore w/o bug-id Reviewed-by: hannesw - test/langtools/jdk/javadoc/tool/6176978/T6176978.java - test/langtools/jdk/javadoc/tool/6176978/X.java - test/langtools/jdk/javadoc/tool/InlineTagsWithBraces.java - test/langtools/jdk/javadoc/tool/LangVers.java Changeset: 091bc4a1 Author: Paul Sandoz Date: 2021-06-17 14:55:18 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/091bc4a1a6ca687aab0c9064f11408b93511a520 8268353: Test libsvml.so is and is not present in jdk image Reviewed-by: sviswanathan, jiefu + test/jdk/jdk/incubator/vector/ImageTest.java ! test/lib/jdk/test/lib/Platform.java Changeset: 2047da7d Author: Fernando Guallini Committer: Rajan Halade Date: 2021-06-17 16:23:56 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2047da7dccacb1adb7f811639a58b8fbe1aa3546 8265297: javax/net/ssl/SSLSession/TestEnabledProtocols.java failed with "RuntimeException: java.net.SocketException: Connection reset" Reviewed-by: xuelei, rhalade ! test/jdk/javax/net/ssl/SSLSession/TestEnabledProtocols.java Changeset: 0011b52e Author: Jonathan Gibbons Date: 2021-06-17 16:37:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0011b52ee81d88b023f771432abc079c64266578 8264843: Javac crashes with NullPointerException when finding unencoded XML in 
 tag

Reviewed-by: hannesw

! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java
+ test/langtools/tools/doclint/html/UnknownTagTest.java
+ test/langtools/tools/doclint/html/UnknownTagTest.out

Changeset: b66001a5
Author:    Daniel D. Daugherty 
Date:      2021-06-17 16:53:22 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/b66001a5946252b621bab27d6ee32006a4d7bab5

8268971: ProblemList tools/jpackage/windows/WinInstallerIconTest.java on win-x64

Reviewed-by: herrick

! test/jdk/ProblemList.txt

Changeset: c98d5084
Author:    Kim Barrett 
Date:      2021-06-17 19:05:10 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/c98d50848ba2811d2f08b3fbc57ac9674c63a943

8268265: MutableSpaceUsedHelper::take_sample() hits assert(left >= right) failed: avoid overflow

Reviewed-by: tschatzl, iwalulya

! src/hotspot/share/gc/parallel/spaceCounters.cpp
! src/hotspot/share/gc/parallel/spaceCounters.hpp
! src/hotspot/share/gc/serial/cSpaceCounters.cpp
! src/hotspot/share/gc/serial/cSpaceCounters.hpp

Changeset: 85452692
Author:    Vladimir Ivanov 
Date:      2021-06-17 21:17:48 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/8545269268ff34a5c6b8a8cc6aff69fff2a7b507

8268676: assert(!ik->is_interface() && !ik->has_subklass()) failed: inconsistent klass hierarchy

Reviewed-by: kvn, roland, neliasso

! src/hotspot/share/opto/arraycopynode.cpp

Changeset: 9130b8a9
Author:    Vladimir Ivanov 
Date:      2021-06-17 21:25:46 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/9130b8a9d7ebd943108f01d41ed777e080f34c4d

8268371: C2: assert(_gvn.type(obj)->higher_equal(tjp)) failed: cast_up is no longer needed

Reviewed-by: roland, kvn

! src/hotspot/share/opto/graphKit.cpp
+ test/hotspot/jtreg/compiler/c2/UpcastTest.java

Changeset: a051e735
Author:    Jesper Wilhelmsson 
Date:      2021-06-18 00:53:09 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/a051e735cda0d5ee5cb6ce0738aa549a7319a28c

Merge


Changeset: f4d20b21
Author:    Julia Boes 
Date:      2021-06-18 09:35:48 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/f4d20b215eb3c90ca28bf973e7614486226692b5

8268900: com/sun/net/httpserver/Headers.java: Fix indentation and whitespace

Reviewed-by: dfuchs, chegar, michaelm

! src/jdk.httpserver/share/classes/com/sun/net/httpserver/Headers.java

Changeset: 54cdd073
Author:    duke 
Date:      2021-06-18 11:00:31 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/54cdd0736379b86a75d89d135af0bb0e226cf912

Automatic merge of jdk:master into master



From duke at openjdk.java.net  Fri Jun 18 11:06:59 2021
From: duke at openjdk.java.net (duke)
Date: Fri, 18 Jun 2021 11:06:59 GMT
Subject: git: openjdk/panama-foreign: foreign-jextract: 43 new changesets
Message-ID: 

Changeset: af13fe11
Author:    Coleen Phillimore 
Date:      2021-06-16 12:41:51 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/af13fe110720ff20ccea0a01fe088707208c3dd8

8267870: Remove unnecessary char_converter during class loading

Reviewed-by: dholmes, iklam

! src/hotspot/share/cds/classListParser.cpp
! src/hotspot/share/classfile/javaAssertions.cpp
! src/hotspot/share/classfile/javaClasses.cpp
! src/hotspot/share/classfile/javaClasses.hpp
! src/hotspot/share/classfile/systemDictionary.cpp

Changeset: 72b3b0af
Author:    Coleen Phillimore 
Date:      2021-06-16 12:43:11 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/72b3b0af08136342e54e1cdea0c48d64172e8870

8267752: KVHashtable doesn't deallocate entries

Reviewed-by: iklam, stuefe

! src/hotspot/share/utilities/hashtable.hpp

Changeset: e4908a43
Author:    Ioi Lam 
Date:      2021-06-16 16:05:19 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/e4908a439a235ee437c0e6e39341e1d67904f49e

8268778: CDS check_excluded_classes needs DumpTimeTable_lock

Reviewed-by: ccheung, minqi

! src/hotspot/share/cds/dynamicArchive.cpp
! src/hotspot/share/cds/metaspaceShared.cpp
! src/hotspot/share/classfile/systemDictionaryShared.cpp

Changeset: c20f80a4
Author:    Coleen Phillimore 
Date:      2021-06-16 16:34:08 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/c20f80a4d2e8d0f5995ad44a38e838adbff6068d

8259066: Obsolete -XX:+AlwaysLockClassLoader

Reviewed-by: hseigel

! src/hotspot/share/classfile/systemDictionary.cpp
! src/hotspot/share/runtime/globals.hpp

Changeset: b836b83b
Author:    Rajan Halade 
Date:      2021-06-16 17:10:40 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/b836b83b2aefbc87b0cf26990ddbab4479c42b71

8259338: Add expiry exception for identrustdstx3 alias to VerifyCACerts.java test

Reviewed-by: xuelei

! test/jdk/sun/security/lib/cacerts/VerifyCACerts.java

Changeset: 02c9bf08
Author:    Xin Liu 
Committer: David Holmes 
Date:      2021-06-16 23:54:21 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/02c9bf087e50885bbc8028415c4e674947ee7a16

8268852: AsyncLogWriter should not overide is_Named_thread()

Reviewed-by: dholmes, ysuenaga

! src/hotspot/share/logging/logAsyncWriter.hpp
! src/hotspot/share/runtime/thread.cpp

Changeset: 10068c1b
Author:    Daniel D. Daugherty 
Date:      2021-06-15 21:48:36 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/10068c1bace0ea650bda3e2234a44cbf401afc7d

8268830: ProblemList 3 serviceability/dcmd/framework tests with ZGC on win-x64

Reviewed-by: kbarrett

! test/hotspot/jtreg/ProblemList-zgc.txt

Changeset: b18de6cf
Author:    Daniel D. Daugherty 
Date:      2021-06-15 23:50:08 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/b18de6cf79e0195736d94b08be67f10ca7c3cd08

8268851: ProblemList jdk/jfr/event/gc/detailed/TestEvacuationFailedEvent.java on linux-X64

Reviewed-by: bpb

! test/jdk/ProblemList.txt

Changeset: 4d545a1f
Author:    Roland Westrelin 
Date:      2021-06-16 07:36:07 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/4d545a1f86325140ed268c5437d776ceb8e21077

8267988: C2: assert(!addp->is_AddP() || addp->in(AddPNode::Base)->is_top() || addp->in(AddPNode::Base) == n->in(AddPNode::Base)) failed: Base pointers must match (addp 1301)

Reviewed-by: chagedorn, vlivanov, kvn

! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp
! src/hotspot/share/opto/castnode.cpp
! src/hotspot/share/opto/castnode.hpp
! src/hotspot/share/opto/cfgnode.cpp
! src/hotspot/share/opto/compile.cpp
! src/hotspot/share/opto/loopTransform.cpp
! src/hotspot/share/opto/loopopts.cpp
+ test/hotspot/jtreg/compiler/loopopts/TestAddPChainWithDifferentBase.java

Changeset: 59de99d1
Author:    Stefan Johansson 
Date:      2021-06-16 08:59:07 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/59de99d11988b7f1ab20e323f3dc4d0d49e3b7a3

8267271: Fix gc/arguments/TestNewRatioFlag.java expectedNewSize calculation

Reviewed-by: tschatzl, kbarrett

! test/hotspot/jtreg/gc/arguments/TestNewRatioFlag.java

Changeset: 19f5fab1
Author:    David Holmes 
Date:      2021-06-16 11:59:43 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/19f5fab175e308e2ab90d6d3efc2335fe751009e

8268861: Disable Windows-Aarch64 build in GitHub Actions

Reviewed-by: mikael, sjohanss

! .github/workflows/submit.yml

Changeset: 9ad19f78
Author:    Christian Hagedorn 
Date:      2021-06-16 13:02:51 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/9ad19f7838e6f6e128583c191c5507c1e2bd5083

8256934: C2: assert(C->live_nodes() <= C->max_node_limit()) failed: Live Node limit exceeded limit

Reviewed-by: roland, vlivanov

! src/hotspot/share/opto/loopopts.cpp
+ test/hotspot/jtreg/compiler/loopopts/TestPartialPeelingSinkNodes.java

Changeset: 38dbe05e
Author:    Bradford Wetmore 
Date:      2021-06-16 16:59:02 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/38dbe05e004a018c810e3acaae4660c69dd982da

8268901: JDK-8268768 missed removing two files

Reviewed-by: mcimadamore

- make/ide/idea/jdk/template/module.iml
- make/ide/idea/jdk/template/test.iml

Changeset: 8ea0606a
Author:    Daniel Fuchs 
Date:      2021-06-16 17:24:06 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/8ea0606aba15911f5bfe2c81a83b42288d97095f

8268714: [macos-aarch64] 7 java/net/httpclient/websocket tests failed

Reviewed-by: chegar, michaelm

! test/jdk/java/net/httpclient/ISO_8859_1_Test.java
! test/jdk/java/net/httpclient/websocket/DummyWebSocketServer.java
! test/jdk/java/net/httpclient/websocket/PendingBinaryPingClose.java
! test/jdk/java/net/httpclient/websocket/PendingBinaryPongClose.java
! test/jdk/java/net/httpclient/websocket/PendingPingBinaryClose.java
! test/jdk/java/net/httpclient/websocket/PendingPingTextClose.java
! test/jdk/java/net/httpclient/websocket/PendingPongBinaryClose.java
! test/jdk/java/net/httpclient/websocket/PendingPongTextClose.java
! test/jdk/java/net/httpclient/websocket/PendingTextPongClose.java
! test/jdk/java/net/httpclient/websocket/Support.java
! test/jdk/java/net/httpclient/websocket/WSHandshakeExceptionTest.java
! test/jdk/java/net/httpclient/websocket/WebSocketProxyTest.java

Changeset: 2c7e47e1
Author:    Jonathan Gibbons 
Date:      2021-06-16 18:03:48 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/2c7e47e12b8a772bcebcdf0b15d6a4d3f92e2267

8268774: Residual logging output written to STDOUT, not STDERR

Reviewed-by: prappo, hannesw

! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/Start.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/ToolEnvironment.java
! test/langtools/jdk/javadoc/tool/ToolProviderTest.java
! test/langtools/jdk/javadoc/tool/testLocaleOption/TestLocaleOption.java
+ test/langtools/jdk/javadoc/tool/testToolStreams/TestToolStreams.java

Changeset: 54f5ffea
Author:    Rajan Halade 
Date:      2021-06-16 18:53:37 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/54f5ffeaad9da7cc77d9b6c0339758340c42ea2e

8259338: Add expiry exception for identrustdstx3 alias to VerifyCACerts.java test

Backport-of: b836b83b2aefbc87b0cf26990ddbab4479c42b71

! test/jdk/sun/security/lib/cacerts/VerifyCACerts.java

Changeset: f0f21788
Author:    Daniel D. Daugherty 
Date:      2021-06-16 19:19:00 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/f0f2178876813cca070db01ce37ea7a04b712923

8268909: ProblemList jdk/jfr/api/consumer/streaming/TestLatestEvent.java on win-x64

Reviewed-by: mikael, dfuchs

! test/jdk/ProblemList.txt

Changeset: ee03bc6d
Author:    Yasumasa Suenaga 
Date:      2021-06-16 23:21:51 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/ee03bc6d0aad4b0d07bbe792c8cc77f986c617e1

8268863: ProblemList serviceability/sa/TestJmapCoreMetaspace.java on linux-x64 with ZGC

Reviewed-by: dcubed

! test/hotspot/jtreg/ProblemList-zgc.txt

Changeset: 9f7851b5
Author:    David Holmes 
Date:      2021-06-16 23:58:24 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/9f7851b5f5220132fce8556269851e33ac06ef31

8260194: Update the documentation for -Xcheck:jni

Reviewed-by: coleenp, hseigel

! src/java.base/share/man/java.1

Changeset: 3637e50b
Author:    Jesper Wilhelmsson 
Date:      2021-06-17 01:05:54 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/3637e50b30e92538510c1a8e8893cedc3bd4ccd5

Merge


Changeset: e8446107
Author:    David Holmes 
Date:      2021-06-17 07:02:47 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/e84461072af9cdb2ee83f5c0747ea5881a0ae805

8268927: Windows: link error: unresolved external symbol "int __cdecl convert_to_unicode(char const *,wchar_t * *)"

Reviewed-by: stuefe

! src/hotspot/os/windows/os_windows.cpp

Changeset: 2d088fa9
Author:    Michael McMahon 
Date:      2021-06-17 07:13:59 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/2d088fa91d18252a801db3b84ff87e261d63ebd4

8268294: Reusing HttpClient in a WebSocket.Listener hangs.

Reviewed-by: dfuchs

! src/java.net.http/share/classes/jdk/internal/net/http/HttpClientFacade.java
! src/java.net.http/share/classes/jdk/internal/net/http/websocket/MessageDecoder.java
! src/java.net.http/share/classes/jdk/internal/net/http/websocket/MessageEncoder.java
! src/java.net.http/share/classes/jdk/internal/net/http/websocket/WebSocketImpl.java
+ test/jdk/java/net/httpclient/websocket/WebSocketServerDriver.java
+ test/jdk/java/net/httpclient/websocket/java.net.http/jdk/internal/net/http/websocket/DefaultMessageStreamHandler.java
+ test/jdk/java/net/httpclient/websocket/java.net.http/jdk/internal/net/http/websocket/MessageStreamHandler.java
+ test/jdk/java/net/httpclient/websocket/java.net.http/jdk/internal/net/http/websocket/MessageStreamResponder.java
+ test/jdk/java/net/httpclient/websocket/java.net.http/jdk/internal/net/http/websocket/WebSocketAndHttpClient.java
+ test/jdk/java/net/httpclient/websocket/java.net.http/jdk/internal/net/http/websocket/WebSocketAndHttpTest.java
+ test/jdk/java/net/httpclient/websocket/java.net.http/jdk/internal/net/http/websocket/WebSocketResponder.java
+ test/jdk/java/net/httpclient/websocket/java.net.http/jdk/internal/net/http/websocket/WebSocketServer.java

Changeset: f2afe0a5
Author:    Thomas Schatzl 
Date:      2021-06-17 17:22:09 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/f2afe0a5130fd3162403ecc18c827bcf56e9c883

8268556: Use bitmap for storing regions that failed evacuation

Reviewed-by: kbarrett, iwalulya, sjohanss

! src/hotspot/share/gc/g1/g1CollectedHeap.cpp
! src/hotspot/share/gc/g1/g1CollectedHeap.hpp
! src/hotspot/share/gc/g1/g1CollectedHeap.inline.hpp

Changeset: fa3b44d4
Author:    Xin Liu 
Committer: Paul Hohensee 
Date:      2021-06-17 20:27:14 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/fa3b44d43811dca8c609d6c61a58680835abf8e3

8268638: semaphores of AsyncLogWriter may be broken when JVM is exiting.

Reviewed-by: dholmes, phh

! src/hotspot/share/logging/logAsyncWriter.cpp
! src/hotspot/share/logging/logAsyncWriter.hpp

Changeset: bb24fa65
Author:    Ioi Lam 
Date:      2021-06-17 22:19:23 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/bb24fa652aa1edc8ece8713f559be2fe3437d666

8267189: Remove duplicated unregistered classes from dynamic archive

Reviewed-by: ccheung, minqi

! src/hotspot/share/cds/classListParser.cpp
! src/hotspot/share/classfile/systemDictionaryShared.cpp
! src/hotspot/share/classfile/systemDictionaryShared.hpp
! src/hotspot/share/oops/instanceKlass.cpp
! src/hotspot/share/runtime/mutexLocker.cpp
! src/hotspot/share/runtime/mutexLocker.hpp
+ test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/DuplicatedCustomTest.java
+ test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/test-classes/DuplicatedCustomApp.java

Changeset: 58e6e6d9
Author:    Rajan Halade 
Date:      2021-06-18 00:49:40 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/58e6e6d919cb15559a61a67805da263be3c9d693

8268678: LetsEncryptCA.java test fails as Let?s Encrypt Authority X3 is retired

Reviewed-by: xuelei

! test/jdk/security/infra/java/security/cert/CertPathValidator/certification/LetsEncryptCA.java

Changeset: 112ddb76
Author:    Jie Fu 
Date:      2021-06-17 02:10:52 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/112ddb7633d8794d5c85e1b2cf0369ee2e0e349a

8268641: [foreign] assert(allocates2(pc)) failed: not in CodeBuffer memory with ShenandoahGC

Reviewed-by: rbackman, kvn

! src/hotspot/cpu/x86/universalUpcallHandler_x86_64.cpp

Changeset: 4c9aefdb
Author:    Eric Liu 
Committer: Pengfei Li 
Date:      2021-06-17 02:47:00 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/4c9aefdb6193f754bfac3ae022f08a76b0cae718

8268739: AArch64: Build failure after JDK-8267663

Reviewed-by: aph, dholmes

! src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.hpp
! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp

Changeset: 344e3edf
Author:    Julia Boes 
Date:      2021-06-17 09:10:27 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/344e3edf7602d8b788334bd103e9a63a8d74a6f8

8268080: java/util/concurrent/forkjoin/AsyncShutdownNow.java fails with java.util.concurrent.RejectedExecutionException

Co-authored-by: Doug Lea 

Reviewed-by: chegar, dfuchs

! test/jdk/java/util/concurrent/forkjoin/AsyncShutdownNow.java
! test/jdk/java/util/concurrent/forkjoin/AsyncShutdownNowInvokeAny.java

Changeset: 7d7bdbe1
Author:    Patrick Concannon 
Date:      2021-06-17 09:35:08 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/7d7bdbe135018f1452fa133b294575014e3e871b

8268776: Test `ADatagramSocket.java` missing /othervm from @run tag

Reviewed-by: dfuchs

! test/jdk/java/net/DatagramSocket/SetDatagramSocketImplFactory/ADatagramSocket.java

Changeset: 69d01b6b
Author:    Jonathan Gibbons 
Date:      2021-06-17 14:09:11 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/69d01b6bcabda177f5e27f6c7b141be57cd00619

8249899: jdk/javadoc/tool/InlineTagsWithBraces.java uses @ignore w/o bug-id
8249897: jdk/javadoc/tool/LangVers.java uses @ignore w/o bug-id
8249898: jdk/javadoc/tool/6176978/T6176978.java uses @ignore w/o bug-id

Reviewed-by: hannesw

- test/langtools/jdk/javadoc/tool/6176978/T6176978.java
- test/langtools/jdk/javadoc/tool/6176978/X.java
- test/langtools/jdk/javadoc/tool/InlineTagsWithBraces.java
- test/langtools/jdk/javadoc/tool/LangVers.java

Changeset: 091bc4a1
Author:    Paul Sandoz 
Date:      2021-06-17 14:55:18 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/091bc4a1a6ca687aab0c9064f11408b93511a520

8268353: Test libsvml.so is and is not present in jdk image

Reviewed-by: sviswanathan, jiefu

+ test/jdk/jdk/incubator/vector/ImageTest.java
! test/lib/jdk/test/lib/Platform.java

Changeset: 2047da7d
Author:    Fernando Guallini 
Committer: Rajan Halade 
Date:      2021-06-17 16:23:56 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/2047da7dccacb1adb7f811639a58b8fbe1aa3546

8265297: javax/net/ssl/SSLSession/TestEnabledProtocols.java failed with "RuntimeException: java.net.SocketException: Connection reset"

Reviewed-by: xuelei, rhalade

! test/jdk/javax/net/ssl/SSLSession/TestEnabledProtocols.java

Changeset: 0011b52e
Author:    Jonathan Gibbons 
Date:      2021-06-17 16:37:35 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/0011b52ee81d88b023f771432abc079c64266578

8264843: Javac crashes with NullPointerException when finding unencoded XML in 
 tag

Reviewed-by: hannesw

! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java
+ test/langtools/tools/doclint/html/UnknownTagTest.java
+ test/langtools/tools/doclint/html/UnknownTagTest.out

Changeset: b66001a5
Author:    Daniel D. Daugherty 
Date:      2021-06-17 16:53:22 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/b66001a5946252b621bab27d6ee32006a4d7bab5

8268971: ProblemList tools/jpackage/windows/WinInstallerIconTest.java on win-x64

Reviewed-by: herrick

! test/jdk/ProblemList.txt

Changeset: c98d5084
Author:    Kim Barrett 
Date:      2021-06-17 19:05:10 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/c98d50848ba2811d2f08b3fbc57ac9674c63a943

8268265: MutableSpaceUsedHelper::take_sample() hits assert(left >= right) failed: avoid overflow

Reviewed-by: tschatzl, iwalulya

! src/hotspot/share/gc/parallel/spaceCounters.cpp
! src/hotspot/share/gc/parallel/spaceCounters.hpp
! src/hotspot/share/gc/serial/cSpaceCounters.cpp
! src/hotspot/share/gc/serial/cSpaceCounters.hpp

Changeset: 85452692
Author:    Vladimir Ivanov 
Date:      2021-06-17 21:17:48 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/8545269268ff34a5c6b8a8cc6aff69fff2a7b507

8268676: assert(!ik->is_interface() && !ik->has_subklass()) failed: inconsistent klass hierarchy

Reviewed-by: kvn, roland, neliasso

! src/hotspot/share/opto/arraycopynode.cpp

Changeset: 9130b8a9
Author:    Vladimir Ivanov 
Date:      2021-06-17 21:25:46 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/9130b8a9d7ebd943108f01d41ed777e080f34c4d

8268371: C2: assert(_gvn.type(obj)->higher_equal(tjp)) failed: cast_up is no longer needed

Reviewed-by: roland, kvn

! src/hotspot/share/opto/graphKit.cpp
+ test/hotspot/jtreg/compiler/c2/UpcastTest.java

Changeset: a051e735
Author:    Jesper Wilhelmsson 
Date:      2021-06-18 00:53:09 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/a051e735cda0d5ee5cb6ce0738aa549a7319a28c

Merge


Changeset: f4d20b21
Author:    Julia Boes 
Date:      2021-06-18 09:35:48 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/f4d20b215eb3c90ca28bf973e7614486226692b5

8268900: com/sun/net/httpserver/Headers.java: Fix indentation and whitespace

Reviewed-by: dfuchs, chegar, michaelm

! src/jdk.httpserver/share/classes/com/sun/net/httpserver/Headers.java

Changeset: 54cdd073
Author:    duke 
Date:      2021-06-18 11:00:31 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/54cdd0736379b86a75d89d135af0bb0e226cf912

Automatic merge of jdk:master into master


Changeset: 7c94f63f
Author:    duke 
Date:      2021-06-18 11:00:52 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/7c94f63f1265fd27567c33c41395953516e2b40a

Automatic merge of master into foreign-memaccess+abi


Changeset: 3b311410
Author:    duke 
Date:      2021-06-18 11:01:11 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/3b311410f9535be977d400ba113886b8e34d3067

Automatic merge of foreign-memaccess+abi into foreign-jextract



From duke at openjdk.java.net  Fri Jun 18 11:09:39 2021
From: duke at openjdk.java.net (duke)
Date: Fri, 18 Jun 2021 11:09:39 GMT
Subject: git: openjdk/panama-foreign: foreign-memaccess+abi: 42 new changesets
Message-ID: 

Changeset: af13fe11
Author:    Coleen Phillimore 
Date:      2021-06-16 12:41:51 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/af13fe110720ff20ccea0a01fe088707208c3dd8

8267870: Remove unnecessary char_converter during class loading

Reviewed-by: dholmes, iklam

! src/hotspot/share/cds/classListParser.cpp
! src/hotspot/share/classfile/javaAssertions.cpp
! src/hotspot/share/classfile/javaClasses.cpp
! src/hotspot/share/classfile/javaClasses.hpp
! src/hotspot/share/classfile/systemDictionary.cpp

Changeset: 72b3b0af
Author:    Coleen Phillimore 
Date:      2021-06-16 12:43:11 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/72b3b0af08136342e54e1cdea0c48d64172e8870

8267752: KVHashtable doesn't deallocate entries

Reviewed-by: iklam, stuefe

! src/hotspot/share/utilities/hashtable.hpp

Changeset: e4908a43
Author:    Ioi Lam 
Date:      2021-06-16 16:05:19 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/e4908a439a235ee437c0e6e39341e1d67904f49e

8268778: CDS check_excluded_classes needs DumpTimeTable_lock

Reviewed-by: ccheung, minqi

! src/hotspot/share/cds/dynamicArchive.cpp
! src/hotspot/share/cds/metaspaceShared.cpp
! src/hotspot/share/classfile/systemDictionaryShared.cpp

Changeset: c20f80a4
Author:    Coleen Phillimore 
Date:      2021-06-16 16:34:08 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/c20f80a4d2e8d0f5995ad44a38e838adbff6068d

8259066: Obsolete -XX:+AlwaysLockClassLoader

Reviewed-by: hseigel

! src/hotspot/share/classfile/systemDictionary.cpp
! src/hotspot/share/runtime/globals.hpp

Changeset: b836b83b
Author:    Rajan Halade 
Date:      2021-06-16 17:10:40 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/b836b83b2aefbc87b0cf26990ddbab4479c42b71

8259338: Add expiry exception for identrustdstx3 alias to VerifyCACerts.java test

Reviewed-by: xuelei

! test/jdk/sun/security/lib/cacerts/VerifyCACerts.java

Changeset: 02c9bf08
Author:    Xin Liu 
Committer: David Holmes 
Date:      2021-06-16 23:54:21 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/02c9bf087e50885bbc8028415c4e674947ee7a16

8268852: AsyncLogWriter should not overide is_Named_thread()

Reviewed-by: dholmes, ysuenaga

! src/hotspot/share/logging/logAsyncWriter.hpp
! src/hotspot/share/runtime/thread.cpp

Changeset: 10068c1b
Author:    Daniel D. Daugherty 
Date:      2021-06-15 21:48:36 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/10068c1bace0ea650bda3e2234a44cbf401afc7d

8268830: ProblemList 3 serviceability/dcmd/framework tests with ZGC on win-x64

Reviewed-by: kbarrett

! test/hotspot/jtreg/ProblemList-zgc.txt

Changeset: b18de6cf
Author:    Daniel D. Daugherty 
Date:      2021-06-15 23:50:08 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/b18de6cf79e0195736d94b08be67f10ca7c3cd08

8268851: ProblemList jdk/jfr/event/gc/detailed/TestEvacuationFailedEvent.java on linux-X64

Reviewed-by: bpb

! test/jdk/ProblemList.txt

Changeset: 4d545a1f
Author:    Roland Westrelin 
Date:      2021-06-16 07:36:07 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/4d545a1f86325140ed268c5437d776ceb8e21077

8267988: C2: assert(!addp->is_AddP() || addp->in(AddPNode::Base)->is_top() || addp->in(AddPNode::Base) == n->in(AddPNode::Base)) failed: Base pointers must match (addp 1301)

Reviewed-by: chagedorn, vlivanov, kvn

! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp
! src/hotspot/share/opto/castnode.cpp
! src/hotspot/share/opto/castnode.hpp
! src/hotspot/share/opto/cfgnode.cpp
! src/hotspot/share/opto/compile.cpp
! src/hotspot/share/opto/loopTransform.cpp
! src/hotspot/share/opto/loopopts.cpp
+ test/hotspot/jtreg/compiler/loopopts/TestAddPChainWithDifferentBase.java

Changeset: 59de99d1
Author:    Stefan Johansson 
Date:      2021-06-16 08:59:07 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/59de99d11988b7f1ab20e323f3dc4d0d49e3b7a3

8267271: Fix gc/arguments/TestNewRatioFlag.java expectedNewSize calculation

Reviewed-by: tschatzl, kbarrett

! test/hotspot/jtreg/gc/arguments/TestNewRatioFlag.java

Changeset: 19f5fab1
Author:    David Holmes 
Date:      2021-06-16 11:59:43 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/19f5fab175e308e2ab90d6d3efc2335fe751009e

8268861: Disable Windows-Aarch64 build in GitHub Actions

Reviewed-by: mikael, sjohanss

! .github/workflows/submit.yml

Changeset: 9ad19f78
Author:    Christian Hagedorn 
Date:      2021-06-16 13:02:51 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/9ad19f7838e6f6e128583c191c5507c1e2bd5083

8256934: C2: assert(C->live_nodes() <= C->max_node_limit()) failed: Live Node limit exceeded limit

Reviewed-by: roland, vlivanov

! src/hotspot/share/opto/loopopts.cpp
+ test/hotspot/jtreg/compiler/loopopts/TestPartialPeelingSinkNodes.java

Changeset: 38dbe05e
Author:    Bradford Wetmore 
Date:      2021-06-16 16:59:02 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/38dbe05e004a018c810e3acaae4660c69dd982da

8268901: JDK-8268768 missed removing two files

Reviewed-by: mcimadamore

- make/ide/idea/jdk/template/module.iml
- make/ide/idea/jdk/template/test.iml

Changeset: 8ea0606a
Author:    Daniel Fuchs 
Date:      2021-06-16 17:24:06 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/8ea0606aba15911f5bfe2c81a83b42288d97095f

8268714: [macos-aarch64] 7 java/net/httpclient/websocket tests failed

Reviewed-by: chegar, michaelm

! test/jdk/java/net/httpclient/ISO_8859_1_Test.java
! test/jdk/java/net/httpclient/websocket/DummyWebSocketServer.java
! test/jdk/java/net/httpclient/websocket/PendingBinaryPingClose.java
! test/jdk/java/net/httpclient/websocket/PendingBinaryPongClose.java
! test/jdk/java/net/httpclient/websocket/PendingPingBinaryClose.java
! test/jdk/java/net/httpclient/websocket/PendingPingTextClose.java
! test/jdk/java/net/httpclient/websocket/PendingPongBinaryClose.java
! test/jdk/java/net/httpclient/websocket/PendingPongTextClose.java
! test/jdk/java/net/httpclient/websocket/PendingTextPongClose.java
! test/jdk/java/net/httpclient/websocket/Support.java
! test/jdk/java/net/httpclient/websocket/WSHandshakeExceptionTest.java
! test/jdk/java/net/httpclient/websocket/WebSocketProxyTest.java

Changeset: 2c7e47e1
Author:    Jonathan Gibbons 
Date:      2021-06-16 18:03:48 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/2c7e47e12b8a772bcebcdf0b15d6a4d3f92e2267

8268774: Residual logging output written to STDOUT, not STDERR

Reviewed-by: prappo, hannesw

! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/Start.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/ToolEnvironment.java
! test/langtools/jdk/javadoc/tool/ToolProviderTest.java
! test/langtools/jdk/javadoc/tool/testLocaleOption/TestLocaleOption.java
+ test/langtools/jdk/javadoc/tool/testToolStreams/TestToolStreams.java

Changeset: 54f5ffea
Author:    Rajan Halade 
Date:      2021-06-16 18:53:37 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/54f5ffeaad9da7cc77d9b6c0339758340c42ea2e

8259338: Add expiry exception for identrustdstx3 alias to VerifyCACerts.java test

Backport-of: b836b83b2aefbc87b0cf26990ddbab4479c42b71

! test/jdk/sun/security/lib/cacerts/VerifyCACerts.java

Changeset: f0f21788
Author:    Daniel D. Daugherty 
Date:      2021-06-16 19:19:00 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/f0f2178876813cca070db01ce37ea7a04b712923

8268909: ProblemList jdk/jfr/api/consumer/streaming/TestLatestEvent.java on win-x64

Reviewed-by: mikael, dfuchs

! test/jdk/ProblemList.txt

Changeset: ee03bc6d
Author:    Yasumasa Suenaga 
Date:      2021-06-16 23:21:51 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/ee03bc6d0aad4b0d07bbe792c8cc77f986c617e1

8268863: ProblemList serviceability/sa/TestJmapCoreMetaspace.java on linux-x64 with ZGC

Reviewed-by: dcubed

! test/hotspot/jtreg/ProblemList-zgc.txt

Changeset: 9f7851b5
Author:    David Holmes 
Date:      2021-06-16 23:58:24 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/9f7851b5f5220132fce8556269851e33ac06ef31

8260194: Update the documentation for -Xcheck:jni

Reviewed-by: coleenp, hseigel

! src/java.base/share/man/java.1

Changeset: 3637e50b
Author:    Jesper Wilhelmsson 
Date:      2021-06-17 01:05:54 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/3637e50b30e92538510c1a8e8893cedc3bd4ccd5

Merge


Changeset: e8446107
Author:    David Holmes 
Date:      2021-06-17 07:02:47 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/e84461072af9cdb2ee83f5c0747ea5881a0ae805

8268927: Windows: link error: unresolved external symbol "int __cdecl convert_to_unicode(char const *,wchar_t * *)"

Reviewed-by: stuefe

! src/hotspot/os/windows/os_windows.cpp

Changeset: 2d088fa9
Author:    Michael McMahon 
Date:      2021-06-17 07:13:59 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/2d088fa91d18252a801db3b84ff87e261d63ebd4

8268294: Reusing HttpClient in a WebSocket.Listener hangs.

Reviewed-by: dfuchs

! src/java.net.http/share/classes/jdk/internal/net/http/HttpClientFacade.java
! src/java.net.http/share/classes/jdk/internal/net/http/websocket/MessageDecoder.java
! src/java.net.http/share/classes/jdk/internal/net/http/websocket/MessageEncoder.java
! src/java.net.http/share/classes/jdk/internal/net/http/websocket/WebSocketImpl.java
+ test/jdk/java/net/httpclient/websocket/WebSocketServerDriver.java
+ test/jdk/java/net/httpclient/websocket/java.net.http/jdk/internal/net/http/websocket/DefaultMessageStreamHandler.java
+ test/jdk/java/net/httpclient/websocket/java.net.http/jdk/internal/net/http/websocket/MessageStreamHandler.java
+ test/jdk/java/net/httpclient/websocket/java.net.http/jdk/internal/net/http/websocket/MessageStreamResponder.java
+ test/jdk/java/net/httpclient/websocket/java.net.http/jdk/internal/net/http/websocket/WebSocketAndHttpClient.java
+ test/jdk/java/net/httpclient/websocket/java.net.http/jdk/internal/net/http/websocket/WebSocketAndHttpTest.java
+ test/jdk/java/net/httpclient/websocket/java.net.http/jdk/internal/net/http/websocket/WebSocketResponder.java
+ test/jdk/java/net/httpclient/websocket/java.net.http/jdk/internal/net/http/websocket/WebSocketServer.java

Changeset: f2afe0a5
Author:    Thomas Schatzl 
Date:      2021-06-17 17:22:09 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/f2afe0a5130fd3162403ecc18c827bcf56e9c883

8268556: Use bitmap for storing regions that failed evacuation

Reviewed-by: kbarrett, iwalulya, sjohanss

! src/hotspot/share/gc/g1/g1CollectedHeap.cpp
! src/hotspot/share/gc/g1/g1CollectedHeap.hpp
! src/hotspot/share/gc/g1/g1CollectedHeap.inline.hpp

Changeset: fa3b44d4
Author:    Xin Liu 
Committer: Paul Hohensee 
Date:      2021-06-17 20:27:14 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/fa3b44d43811dca8c609d6c61a58680835abf8e3

8268638: semaphores of AsyncLogWriter may be broken when JVM is exiting.

Reviewed-by: dholmes, phh

! src/hotspot/share/logging/logAsyncWriter.cpp
! src/hotspot/share/logging/logAsyncWriter.hpp

Changeset: bb24fa65
Author:    Ioi Lam 
Date:      2021-06-17 22:19:23 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/bb24fa652aa1edc8ece8713f559be2fe3437d666

8267189: Remove duplicated unregistered classes from dynamic archive

Reviewed-by: ccheung, minqi

! src/hotspot/share/cds/classListParser.cpp
! src/hotspot/share/classfile/systemDictionaryShared.cpp
! src/hotspot/share/classfile/systemDictionaryShared.hpp
! src/hotspot/share/oops/instanceKlass.cpp
! src/hotspot/share/runtime/mutexLocker.cpp
! src/hotspot/share/runtime/mutexLocker.hpp
+ test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/DuplicatedCustomTest.java
+ test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/test-classes/DuplicatedCustomApp.java

Changeset: 58e6e6d9
Author:    Rajan Halade 
Date:      2021-06-18 00:49:40 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/58e6e6d919cb15559a61a67805da263be3c9d693

8268678: LetsEncryptCA.java test fails as Let?s Encrypt Authority X3 is retired

Reviewed-by: xuelei

! test/jdk/security/infra/java/security/cert/CertPathValidator/certification/LetsEncryptCA.java

Changeset: 112ddb76
Author:    Jie Fu 
Date:      2021-06-17 02:10:52 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/112ddb7633d8794d5c85e1b2cf0369ee2e0e349a

8268641: [foreign] assert(allocates2(pc)) failed: not in CodeBuffer memory with ShenandoahGC

Reviewed-by: rbackman, kvn

! src/hotspot/cpu/x86/universalUpcallHandler_x86_64.cpp

Changeset: 4c9aefdb
Author:    Eric Liu 
Committer: Pengfei Li 
Date:      2021-06-17 02:47:00 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/4c9aefdb6193f754bfac3ae022f08a76b0cae718

8268739: AArch64: Build failure after JDK-8267663

Reviewed-by: aph, dholmes

! src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.hpp
! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp

Changeset: 344e3edf
Author:    Julia Boes 
Date:      2021-06-17 09:10:27 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/344e3edf7602d8b788334bd103e9a63a8d74a6f8

8268080: java/util/concurrent/forkjoin/AsyncShutdownNow.java fails with java.util.concurrent.RejectedExecutionException

Co-authored-by: Doug Lea 

Reviewed-by: chegar, dfuchs

! test/jdk/java/util/concurrent/forkjoin/AsyncShutdownNow.java
! test/jdk/java/util/concurrent/forkjoin/AsyncShutdownNowInvokeAny.java

Changeset: 7d7bdbe1
Author:    Patrick Concannon 
Date:      2021-06-17 09:35:08 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/7d7bdbe135018f1452fa133b294575014e3e871b

8268776: Test `ADatagramSocket.java` missing /othervm from @run tag

Reviewed-by: dfuchs

! test/jdk/java/net/DatagramSocket/SetDatagramSocketImplFactory/ADatagramSocket.java

Changeset: 69d01b6b
Author:    Jonathan Gibbons 
Date:      2021-06-17 14:09:11 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/69d01b6bcabda177f5e27f6c7b141be57cd00619

8249899: jdk/javadoc/tool/InlineTagsWithBraces.java uses @ignore w/o bug-id
8249897: jdk/javadoc/tool/LangVers.java uses @ignore w/o bug-id
8249898: jdk/javadoc/tool/6176978/T6176978.java uses @ignore w/o bug-id

Reviewed-by: hannesw

- test/langtools/jdk/javadoc/tool/6176978/T6176978.java
- test/langtools/jdk/javadoc/tool/6176978/X.java
- test/langtools/jdk/javadoc/tool/InlineTagsWithBraces.java
- test/langtools/jdk/javadoc/tool/LangVers.java

Changeset: 091bc4a1
Author:    Paul Sandoz 
Date:      2021-06-17 14:55:18 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/091bc4a1a6ca687aab0c9064f11408b93511a520

8268353: Test libsvml.so is and is not present in jdk image

Reviewed-by: sviswanathan, jiefu

+ test/jdk/jdk/incubator/vector/ImageTest.java
! test/lib/jdk/test/lib/Platform.java

Changeset: 2047da7d
Author:    Fernando Guallini 
Committer: Rajan Halade 
Date:      2021-06-17 16:23:56 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/2047da7dccacb1adb7f811639a58b8fbe1aa3546

8265297: javax/net/ssl/SSLSession/TestEnabledProtocols.java failed with "RuntimeException: java.net.SocketException: Connection reset"

Reviewed-by: xuelei, rhalade

! test/jdk/javax/net/ssl/SSLSession/TestEnabledProtocols.java

Changeset: 0011b52e
Author:    Jonathan Gibbons 
Date:      2021-06-17 16:37:35 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/0011b52ee81d88b023f771432abc079c64266578

8264843: Javac crashes with NullPointerException when finding unencoded XML in 
 tag

Reviewed-by: hannesw

! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java
+ test/langtools/tools/doclint/html/UnknownTagTest.java
+ test/langtools/tools/doclint/html/UnknownTagTest.out

Changeset: b66001a5
Author:    Daniel D. Daugherty 
Date:      2021-06-17 16:53:22 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/b66001a5946252b621bab27d6ee32006a4d7bab5

8268971: ProblemList tools/jpackage/windows/WinInstallerIconTest.java on win-x64

Reviewed-by: herrick

! test/jdk/ProblemList.txt

Changeset: c98d5084
Author:    Kim Barrett 
Date:      2021-06-17 19:05:10 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/c98d50848ba2811d2f08b3fbc57ac9674c63a943

8268265: MutableSpaceUsedHelper::take_sample() hits assert(left >= right) failed: avoid overflow

Reviewed-by: tschatzl, iwalulya

! src/hotspot/share/gc/parallel/spaceCounters.cpp
! src/hotspot/share/gc/parallel/spaceCounters.hpp
! src/hotspot/share/gc/serial/cSpaceCounters.cpp
! src/hotspot/share/gc/serial/cSpaceCounters.hpp

Changeset: 85452692
Author:    Vladimir Ivanov 
Date:      2021-06-17 21:17:48 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/8545269268ff34a5c6b8a8cc6aff69fff2a7b507

8268676: assert(!ik->is_interface() && !ik->has_subklass()) failed: inconsistent klass hierarchy

Reviewed-by: kvn, roland, neliasso

! src/hotspot/share/opto/arraycopynode.cpp

Changeset: 9130b8a9
Author:    Vladimir Ivanov 
Date:      2021-06-17 21:25:46 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/9130b8a9d7ebd943108f01d41ed777e080f34c4d

8268371: C2: assert(_gvn.type(obj)->higher_equal(tjp)) failed: cast_up is no longer needed

Reviewed-by: roland, kvn

! src/hotspot/share/opto/graphKit.cpp
+ test/hotspot/jtreg/compiler/c2/UpcastTest.java

Changeset: a051e735
Author:    Jesper Wilhelmsson 
Date:      2021-06-18 00:53:09 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/a051e735cda0d5ee5cb6ce0738aa549a7319a28c

Merge


Changeset: f4d20b21
Author:    Julia Boes 
Date:      2021-06-18 09:35:48 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/f4d20b215eb3c90ca28bf973e7614486226692b5

8268900: com/sun/net/httpserver/Headers.java: Fix indentation and whitespace

Reviewed-by: dfuchs, chegar, michaelm

! src/jdk.httpserver/share/classes/com/sun/net/httpserver/Headers.java

Changeset: 54cdd073
Author:    duke 
Date:      2021-06-18 11:00:31 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/54cdd0736379b86a75d89d135af0bb0e226cf912

Automatic merge of jdk:master into master


Changeset: 7c94f63f
Author:    duke 
Date:      2021-06-18 11:00:52 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/7c94f63f1265fd27567c33c41395953516e2b40a

Automatic merge of master into foreign-memaccess+abi



From paul.sandoz at oracle.com  Fri Jun 18 19:55:11 2021
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 18 Jun 2021 19:55:11 +0000
Subject: Foreign + Vectors - benchmarks for copying and swapping
In-Reply-To: <1a23ee05-f187-e6d8-900e-62e77cd73dc9@oracle.com>
References: 
 
 <5290e44a-7c67-6ee6-57dc-9af646604082@oracle.com>
 
 <1a23ee05-f187-e6d8-900e-62e77cd73dc9@oracle.com>
Message-ID: <0DE3B831-2C2C-475B-94FC-867039D6AFC4@oracle.com>

The order declared in the vector load/store overrides any order declared on the buffer (should make the specification clearer in that respect). (In this case in the source is bytes, so there is no swapping).

?

There is something odd going on when tiered compilation is switched off, the result for copyWithVector is much worse for smaller sizes.

With larger sizes with and without tiered, similar result are observed with similar generated code (of less quality than with tiered for smaller sizes, oddly enough).

Whether tiered is enabled or not there is no loop unrolling.

I think something may have regressed, although we have previously focused more on array access than buffer access. 

This needs a more focused investigation comparing vector array access with buffer access. 

Paul.

> On Jun 18, 2021, at 1:09 AM, Maurizio Cimadamore  wrote:
> 
> 
> 
> On 17/06/2021 23:14, Rados?aw Smogura wrote:
>> For endianess, I'm not sure how to check it, but it may not be a case, I try to use native order, and operate on bytes.
> I guess what I mean is:
> 
> https://github.com/rsmogura/panama-foreign/blob/foreign_and_vectors/test/micro/org/openjdk/bench/jdk/incubator/foreign/VectorCopySegments.java#L91
> 
> Should this be:
> 
> ```
> final var src = srcAddress.asSegment(size, scope).asByteBuffer().order(ByteOrder.nativeOrder());
> 
> ```
> 
> And same for other derived buffers? You then use it as this:
> 
> ```
> final var srcVector = ByteVector.fromByteBuffer(BYTE_VECTOR_SPECIES, src, i, ByteOrder.nativeOrder());
> 
> ```
> 
> Which does smell like mismatched access?
> 
> Cheers
> Maurizio
> 
> 
> 
> 
> 


From maurizio.cimadamore at oracle.com  Fri Jun 18 21:03:20 2021
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Fri, 18 Jun 2021 22:03:20 +0100
Subject: Foreign + Vectors - benchmarks for copying and swapping
In-Reply-To: <0DE3B831-2C2C-475B-94FC-867039D6AFC4@oracle.com>
References: 
 
 <5290e44a-7c67-6ee6-57dc-9af646604082@oracle.com>
 
 <1a23ee05-f187-e6d8-900e-62e77cd73dc9@oracle.com>
 <0DE3B831-2C2C-475B-94FC-867039D6AFC4@oracle.com>
Message-ID: <07ccd69f-d218-15da-1b71-7dcaa767a7be@oracle.com>


On 18/06/2021 20:55, Paul Sandoz wrote:
> The order declared in the vector load/store overrides any order declared on the buffer (should make the specification clearer in that respect). (In this case in the source is bytes, so there is no swapping).
Doh - right!
>
> ?
>
> There is something odd going on when tiered compilation is switched off, the result for copyWithVector is much worse for smaller sizes.

Is this what Uwe is seeing I wonder?

https://github.com/apache/lucene/pull/177#issuecomment-861265227

>
> With larger sizes with and without tiered, similar result are observed with similar generated code (of less quality than with tiered for smaller sizes, oddly enough).
>
> Whether tiered is enabled or not there is no loop unrolling.
>
> I think something may have regressed, although we have previously focused more on array access than buffer access.
Is the vector implementation performing a bulk copy into a byte array 
IIRC? If so, maybe there's an issue with bulk copy - which would be the 
same issue we're seeing on the memory access front?
>
> This needs a more focused investigation comparing vector array access with buffer access.
Maurizio
>
> Paul.
>
>> On Jun 18, 2021, at 1:09 AM, Maurizio Cimadamore  wrote:
>>
>>
>>
>> On 17/06/2021 23:14, Rados?aw Smogura wrote:
>>> For endianess, I'm not sure how to check it, but it may not be a case, I try to use native order, and operate on bytes.
>> I guess what I mean is:
>>
>> https://github.com/rsmogura/panama-foreign/blob/foreign_and_vectors/test/micro/org/openjdk/bench/jdk/incubator/foreign/VectorCopySegments.java#L91
>>
>> Should this be:
>>
>> ```
>> final var src = srcAddress.asSegment(size, scope).asByteBuffer().order(ByteOrder.nativeOrder());
>>
>> ```
>>
>> And same for other derived buffers? You then use it as this:
>>
>> ```
>> final var srcVector = ByteVector.fromByteBuffer(BYTE_VECTOR_SPECIES, src, i, ByteOrder.nativeOrder());
>>
>> ```
>>
>> Which does smell like mismatched access?
>>
>> Cheers
>> Maurizio
>>
>>
>>
>>
>>

From paul.sandoz at oracle.com  Fri Jun 18 21:37:11 2021
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 18 Jun 2021 21:37:11 +0000
Subject: Foreign + Vectors - benchmarks for copying and swapping
In-Reply-To: <07ccd69f-d218-15da-1b71-7dcaa767a7be@oracle.com>
References: 
 
 <5290e44a-7c67-6ee6-57dc-9af646604082@oracle.com>
 
 <1a23ee05-f187-e6d8-900e-62e77cd73dc9@oracle.com>
 <0DE3B831-2C2C-475B-94FC-867039D6AFC4@oracle.com>
 <07ccd69f-d218-15da-1b71-7dcaa767a7be@oracle.com>
Message-ID: <9989FFC5-6D13-4114-B32D-A08D427925D4@oracle.com>



> On Jun 18, 2021, at 2:03 PM, Maurizio Cimadamore  wrote:
> 
> 
> On 18/06/2021 20:55, Paul Sandoz wrote:
>> The order declared in the vector load/store overrides any order declared on the buffer (should make the specification clearer in that respect). (In this case in the source is bytes, so there is no swapping).
> Doh - right!
>> 
>> ?
>> 
>> There is something odd going on when tiered compilation is switched off, the result for copyWithVector is much worse for smaller sizes.
> 
> Is this what Uwe is seeing I wonder?
> 
> https://github.com/apache/lucene/pull/177#issuecomment-861265227
> 

Possibly.


>> 
>> With larger sizes with and without tiered, similar result are observed with similar generated code (of less quality than with tiered for smaller sizes, oddly enough).
>> 
>> Whether tiered is enabled or not there is no loop unrolling.
>> 
>> I think something may have regressed, although we have previously focused more on array access than buffer access.
> Is the vector implementation performing a bulk copy into a byte array IIRC? If so, maybe there's an issue with bulk copy - which would be the same issue we're seeing on the memory access front?


No, the intrinsic byte vector access to a byte buffer works similarly to intrinsic byte vector access to a byte array, using the buffer?s base and offset (to calculate the address relative to the base).

Paul.

From mail at smogura.eu  Fri Jun 18 23:12:34 2021
From: mail at smogura.eu (=?windows-1250?Q?Rados=B3aw_Smogura?=)
Date: Fri, 18 Jun 2021 23:12:34 +0000
Subject: ODP: Foreign + Vectors - benchmarks for copying and swapping
In-Reply-To: <9989FFC5-6D13-4114-B32D-A08D427925D4@oracle.com>
References: 
 
 <5290e44a-7c67-6ee6-57dc-9af646604082@oracle.com>
 
 <1a23ee05-f187-e6d8-900e-62e77cd73dc9@oracle.com>
 <0DE3B831-2C2C-475B-94FC-867039D6AFC4@oracle.com>
 <07ccd69f-d218-15da-1b71-7dcaa767a7be@oracle.com>,
 <9989FFC5-6D13-4114-B32D-A08D427925D4@oracle.com>
Message-ID: 

Hi all,

So I have one more interesting thing, when I change loopBound to
VectorIntrinsics.roundDown(length, laneCount) - (laneCount - 1)
(I think it's better optimization)
I have such results (please take a look at drop down in avg time) - that's for 1m size

# Warmup Iteration   2: 47990.588 ns/op
# Warmup Iteration   3: 46073.341 ns/op
# Warmup Iteration   4: 45593.405 ns/op
# Warmup Iteration   5: 45525.001 ns/op
Iteration   1: 45921.159 ns/op
Iteration   2: 46542.631 ns/op
Iteration   3: 45532.379 ns/op
Iteration   4: 46862.923 ns/op
Iteration   5: 49324.919 ns/op
Iteration   6: 34099.454 ns/op
Iteration   7: 22315.402 ns/op
Iteration   8: 22495.426 ns/op
Iteration   9: 22702.834 ns/op
Iteration  10: 22675.853 ns/op


Result "org.openjdk.bench.jdk.incubator.foreign.VectorCopySegments.copyWithVectorBuff":
  35847.298 ?(99.9%) 18332.841 ns/op [Average]
  (min, avg, max) = (22315.402, 35847.298, 49324.919), stdev = 12126.039
  CI (99.9%): [17514.457, 54180.139] (assumes normal distribution)

Kind regards,
Rado
________________________________
Od: Paul Sandoz 
Wys?ane: pi?tek, 18 czerwca 2021 23:37
Do: Maurizio Cimadamore 
DW: Rados?aw Smogura ; panama-dev at openjdk.java.net 
Temat: Re: Foreign + Vectors - benchmarks for copying and swapping



> On Jun 18, 2021, at 2:03 PM, Maurizio Cimadamore  wrote:
>
>
> On 18/06/2021 20:55, Paul Sandoz wrote:
>> The order declared in the vector load/store overrides any order declared on the buffer (should make the specification clearer in that respect). (In this case in the source is bytes, so there is no swapping).
> Doh - right!
>>
>> ?
>>
>> There is something odd going on when tiered compilation is switched off, the result for copyWithVector is much worse for smaller sizes.
>
> Is this what Uwe is seeing I wonder?
>
> https://github.com/apache/lucene/pull/177#issuecomment-861265227
>

Possibly.


>>
>> With larger sizes with and without tiered, similar result are observed with similar generated code (of less quality than with tiered for smaller sizes, oddly enough).
>>
>> Whether tiered is enabled or not there is no loop unrolling.
>>
>> I think something may have regressed, although we have previously focused more on array access than buffer access.
> Is the vector implementation performing a bulk copy into a byte array IIRC? If so, maybe there's an issue with bulk copy - which would be the same issue we're seeing on the memory access front?


No, the intrinsic byte vector access to a byte buffer works similarly to intrinsic byte vector access to a byte array, using the buffer?s base and offset (to calculate the address relative to the base).

Paul.

From gabaden at gmail.com  Sun Jun 20 21:26:39 2021
From: gabaden at gmail.com (Denis Gabaydulin)
Date: Mon, 21 Jun 2021 00:26:39 +0300
Subject: [ a newby question about vectorized shuffling / permutation ]
In-Reply-To: 
References: 
Message-ID: 

If somebody is interested in the result, here's my solution (which is
twice faster on SPECIES_128).

https://gist.github.com/sherman/6d8a4103ba5bb3d2911684b8c842647f

Benchmark with the intersection in the middle of arrays.

Benchmark                                    Mode Cnt Score  Error  Units
IntersectionBenchmark.hasIntersectionScalar thrpt  10 3.785 ? 0.095 ops/us
IntersectionBenchmark.hasIntersectionVector thrpt  10 7.008 ? 0.795 ops/us

What I do:
Changed the shuffling op by the broadcast op.

Here's the most significant part in the asm:

https://gist.github.com/sherman/7788e37b667940f31531ce74cb53b4e5

Would be very appreciated any suggestions and comments on how it can
be improved in terms of throughput?

On Wed, Jun 2, 2021 at 2:04 PM Denis Gabaydulin  wrote:
>
> Hi, folks!
>
> Have a newbie question about the API.
> I'm trying to explore a new and shiny vector API with simple but useful examples.
>
> One of that is to build a SIMD version to find any intersection of two sorted lists.
>
> E.g.
> hasIntersection([1, 3, 4, 10],  [2, 6, 6, 11]) => false
> hasIntersection([1, 3, 4, 10],  [2, 3, 6, 11]) => true
>
> A mental model of this algorithm which I have:
>
> 1). to get a part of an array one
> 2). compare it n-times which corresponding part of an array two.
> 3). each time we need to compare two parts of arrays we need to shuffle (permutate) a left part by a mask. E.g. 1, 3, 4, 10 -> 10, 1, 3, 4
> 4). if one of a number is the same, return true, otherwise, move.
> In SIMD instructions looks like I need two major things.
>
> 1). vectorized comparison instruction
> 2). vectorized shuffle instruction.
>
> The first one, I can see in the printed asm.
> compare in API -> vpcmpeqd
>
> The question, which function of the vector API should I use to getting something like _mm_shuffle_epi32 ?
>
>
>
>

On Wed, Jun 2, 2021 at 2:04 PM Denis Gabaydulin  wrote:
>
> Hi, folks!
>
> Have a newbie question about the API.
> I'm trying to explore a new and shiny vector API with simple but useful examples.
>
> One of that is to build a SIMD version to find any intersection of two sorted lists.
>
> E.g.
> hasIntersection([1, 3, 4, 10],  [2, 6, 6, 11]) => false
> hasIntersection([1, 3, 4, 10],  [2, 3, 6, 11]) => true
>
> A mental model of this algorithm which I have:
>
> 1). to get a part of an array one
> 2). compare it n-times which corresponding part of an array two.
> 3). each time we need to compare two parts of arrays we need to shuffle (permutate) a left part by a mask. E.g. 1, 3, 4, 10 -> 10, 1, 3, 4
> 4). if one of a number is the same, return true, otherwise, move.
> In SIMD instructions looks like I need two major things.
>
> 1). vectorized comparison instruction
> 2). vectorized shuffle instruction.
>
> The first one, I can see in the printed asm.
> compare in API -> vpcmpeqd
>
> The question, which function of the vector API should I use to getting something like _mm_shuffle_epi32 ?
>
>
>
>

From mail at smogura.eu  Mon Jun 21 01:48:59 2021
From: mail at smogura.eu (=?utf-8?B?UmFkb3PFgmF3IFNtb2d1cmE=?=)
Date: Mon, 21 Jun 2021 01:48:59 +0000
Subject: ODP: Foreign + Vectors - benchmarks for copying and swapping
In-Reply-To: 
References: 
 
 <5290e44a-7c67-6ee6-57dc-9af646604082@oracle.com>
 
 <1a23ee05-f187-e6d8-900e-62e77cd73dc9@oracle.com>
 <0DE3B831-2C2C-475B-94FC-867039D6AFC4@oracle.com>
 <07ccd69f-d218-15da-1b71-7dcaa767a7be@oracle.com>,
 <9989FFC5-6D13-4114-B32D-A08D427925D4@oracle.com>,
 
Message-ID: 

Hi,

I think I found what's going on.

https://github.com/rsmogura/panama-foreign/commit/64bf7a66a6c3cf5c4ee4f3d0b0e29128bc8e1321
[https://opengraph.githubassets.com/fbd69fd61e8db93b4a70ce6baee936b84348a65b3e899b3e5d7591322aded370/rsmogura/panama-foreign/commit/64bf7a66a6c3cf5c4ee4f3d0b0e29128bc8e1321]
Remove mem barriers after vector ops to increase performance ? rsmogura/panama-foreign at 64bf7a6
Removing mem barriers increase performance by allowing loop to unroll. Other possible solution: allow traversal through mem barriers, and projections when finding loop back control. After ``` Ben...
github.com
?
Other approach would be to modify loop optimizations to find back control through chain of projections and mem barriersa (or maybe both?)

This idea makes copy much better (and even faster then native one in unrolled


VectorCopySegments.copyWithNative                 1024  avgt   10     20.293 ?    0.436  ns/op
VectorCopySegments.copyWithNative              1048576  avgt   10  22270.840 ?  579.533  ns/op
VectorCopySegments.copyWithNativeShared           1024  avgt   10     15.854 ?    0.061  ns/op
VectorCopySegments.copyWithNativeShared        1048576  avgt   10  21948.236 ?   43.981  ns/op
VectorCopySegments.copyWithNativeToArray          1024  avgt   10     20.318 ?    0.347  ns/op
VectorCopySegments.copyWithNativeToArray       1048576  avgt   10  22142.499 ?  305.501  ns/op
VectorCopySegments.copyWithVector                 1024  avgt   10     31.240 ?    0.333  ns/op
VectorCopySegments.copyWithVector              1048576  avgt   10  25320.898 ?  118.397  ns/op
VectorCopySegments.copyWithVectorDirectBuffer     1024  avgt   10     21.605 ?    0.210  ns/op
VectorCopySegments.copyWithVectorDirectBuffer  1048576  avgt   10  23613.272 ? 1030.153  ns/op
VectorCopySegments.copyWithVectorShared           1024  avgt   10     19.897 ?    0.485  ns/op
VectorCopySegments.copyWithVectorShared        1048576  avgt   10  24719.767 ?  453.725  ns/op
VectorCopySegments.copyWithVectorShuffle          1024  avgt   10     36.364 ?    0.669  ns/op
VectorCopySegments.copyWithVectorShuffle       1048576  avgt   10  29730.528 ?  339.100  ns/op
VectorCopySegments.copyWithVectorToArray          1024  avgt   10     29.282 ?    0.338  ns/op
VectorCopySegments.copyWithVectorToArray       1048576  avgt   10  28502.004 ?  593.347  ns/op
VectorCopySegments.copyWithVectorUnroller         1024  avgt   10     36.368 ?    0.092  ns/op
VectorCopySegments.copyWithVectorUnroller      1048576  avgt   10  21528.433 ?  303.141  ns/op

Kind regards,
Rado

________________________________
Od: panama-dev  w imieniu u?ytkownika Rados?aw Smogura 
Wys?ane: sobota, 19 czerwca 2021 01:12
Do: Paul Sandoz ; Maurizio Cimadamore 
DW: panama-dev at openjdk.java.net 
Temat: ODP: Foreign + Vectors - benchmarks for copying and swapping

Hi all,

So I have one more interesting thing, when I change loopBound to
VectorIntrinsics.roundDown(length, laneCount) - (laneCount - 1)
(I think it's better optimization)
I have such results (please take a look at drop down in avg time) - that's for 1m size

# Warmup Iteration   2: 47990.588 ns/op
# Warmup Iteration   3: 46073.341 ns/op
# Warmup Iteration   4: 45593.405 ns/op
# Warmup Iteration   5: 45525.001 ns/op
Iteration   1: 45921.159 ns/op
Iteration   2: 46542.631 ns/op
Iteration   3: 45532.379 ns/op
Iteration   4: 46862.923 ns/op
Iteration   5: 49324.919 ns/op
Iteration   6: 34099.454 ns/op
Iteration   7: 22315.402 ns/op
Iteration   8: 22495.426 ns/op
Iteration   9: 22702.834 ns/op
Iteration  10: 22675.853 ns/op


Result "org.openjdk.bench.jdk.incubator.foreign.VectorCopySegments.copyWithVectorBuff":
  35847.298 ?(99.9%) 18332.841 ns/op [Average]
  (min, avg, max) = (22315.402, 35847.298, 49324.919), stdev = 12126.039
  CI (99.9%): [17514.457, 54180.139] (assumes normal distribution)

Kind regards,
Rado
________________________________
Od: Paul Sandoz 
Wys?ane: pi?tek, 18 czerwca 2021 23:37
Do: Maurizio Cimadamore 
DW: Rados?aw Smogura ; panama-dev at openjdk.java.net 
Temat: Re: Foreign + Vectors - benchmarks for copying and swapping



> On Jun 18, 2021, at 2:03 PM, Maurizio Cimadamore  wrote:
>
>
> On 18/06/2021 20:55, Paul Sandoz wrote:
>> The order declared in the vector load/store overrides any order declared on the buffer (should make the specification clearer in that respect). (In this case in the source is bytes, so there is no swapping).
> Doh - right!
>>
>> ?
>>
>> There is something odd going on when tiered compilation is switched off, the result for copyWithVector is much worse for smaller sizes.
>
> Is this what Uwe is seeing I wonder?
>
> https://github.com/apache/lucene/pull/177#issuecomment-861265227
>

Possibly.


>>
>> With larger sizes with and without tiered, similar result are observed with similar generated code (of less quality than with tiered for smaller sizes, oddly enough).
>>
>> Whether tiered is enabled or not there is no loop unrolling.
>>
>> I think something may have regressed, although we have previously focused more on array access than buffer access.
> Is the vector implementation performing a bulk copy into a byte array IIRC? If so, maybe there's an issue with bulk copy - which would be the same issue we're seeing on the memory access front?


No, the intrinsic byte vector access to a byte buffer works similarly to intrinsic byte vector access to a byte array, using the buffer?s base and offset (to calculate the address relative to the base).

Paul.

From xgong at openjdk.java.net  Mon Jun 21 03:31:53 2021
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Mon, 21 Jun 2021 03:31:53 GMT
Subject: [vectorIntrinsics+mask] RFR: 8266287: Basic mask IR
 implementation for the Vector API masking feature support [v2]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Thu, 17 Jun 2021 19:29:28 GMT, Jatin Bhateja  wrote:

>> Hi @jatin-bhateja , it seems the type of `VectorBox/VectorUnbox` should be exactly matched with the `value` boxed. For such an optimization `// VectorUnbox (VectorBox v) ==> v`, if the type of `v` is a vector mask type while the `VectorUnbox` type is expected to be a vector type, the final result of this optimization would change the result type of `VectorUnbox` to be a mask type. Some type checks or assertion will fail. I met the following issue when I run the jtreg tests after changing type of `VectorBox/VectorUnbox` back to vector type:
>> 
>> # A fatal error has been detected by the Java Runtime Environment:
>> #
>> #  Internal Error (/home/ent-user/panama-vector/src/hotspot/share/opto/type.cpp:2412), pid=433543, tid=433698
>> #  Error: assert(base() == v->base()) failed
>> #
>> # JRE version: OpenJDK Runtime Environment (17.0) (fastdebug build 17-internal+0-git-8123588d66)
>> # Java VM: OpenJDK 64-Bit Server VM (fastdebug 17-internal+0-git-8123588d66, mixed mode, sharing, compressed oops, compressed class ptrs, g1 gc, linux-aarch64)
>> # Problematic frame:
>> # V  [libjvm.so+0x19f3108]  TypeVect::xmeet(Type const*) const+0x138
>> #
>> # Core dump will be written. Default location: Core dumps may be processed with "/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h %e" (or dumping to /home/ent-user/jtreg/jtreg-hg/build/images/jtreg/jtwork/scratch/2/core.433543)
>> #
>> # If you would like to submit a bug report, please visit:
>> #   https://bugreport.java.com/bugreport/crash.jsp
>> 
>> Do you have any strong reason that we must define a vector type for `VectorBox/VectorUnbox`?
>
> VectorBoxNode and VectorUnboxNode are macro nodes and carry the vector type which comply with the species i.e. for IntVector.SPECIES_256, vector type of Box/Unbox should be TypeVect(T_INT,8), both these nodes needs to be expanded as per following expansion rules:- 
> 
> a) VectorBox mask(TypeVectMask) ====>   VectorStoreMask + StoreVector.
> b) VectorUnbox mask =====>  LoadVector  + VectorLoadMask (TypeVectMask)
> c) VectorUnbox (VectorBox mask) ====> VectorStoreMask(TypeVectMask) + StoreVector + LoadVector + VectorLoadMask(TypeVectMask)
> 
> An optimization over VectorUnboxNode should consult the type of VectorBoxNode and vice-versa,  similarly any optimization involving VectorLoadMaskNode should comply with type of VectoStoreMaskNode, there cannot be a mix-match, if there is any such case it needs to be fixed like the following handling
> https://github.com/openjdk/panama-vector/pull/90#pullrequestreview-679559503
> 
> Can you kindly share the tests which failed.

Hi @jatin-bhateja , too much Vector API jtreg tests crashes due to this change. Please see one of the jvm crash log here: http://cr.openjdk.java.net/~xgong/rfr/mask/crashes.

BTW, I remember @iwanowww said that the vector type should match for `VectorUnbox ` and its `obj ` when I fixed the type mismatching issue for vector mask with floating point type before. Please see the comment here: https://github.com/openjdk/jdk/pull/3238#issuecomment-815036103

-------------

PR: https://git.openjdk.java.net/panama-vector/pull/78

From xgong at openjdk.java.net  Mon Jun 21 09:56:40 2021
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Mon, 21 Jun 2021 09:56:40 GMT
Subject: [vectorIntrinsics+mask] RFR: 8266287: Basic mask IR
 implementation for the Vector API masking feature support [v3]
In-Reply-To: 
References: 
Message-ID: 

> Based on [1], this patch adds the C2 compiler mid-end changes for the masking feature support. It mainly contains:
>  1) Generation of the mask IRs for vector mask, including:
>     - Mask generations, e.g. load/compare/maskAll
>     - Mask operations, e.g. and/or/xor
>  2) Conversions between vector and mask after loading mask values from memory and before storing mask values into memory
>  3) Generation of the vector IRs which need the mask value as the control
>     - The mask value is appended to the original vector node's input list
> 
> With this change, the bottom type of the vector mask will be set to `"TypeVectMask"` if the platform supports the masking feature and the backend implementations are added.
> 
> Note that this patch only contains the compiler mid-end changes. The backend implementations for SVE/AVX-512 will be in the
> followed-up patches.
> 
> [1] https://github.com/openjdk/panama-vector/pull/57

Xiaohong Gong has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:

 - Try to reuse the same vector mask IRs
 - Merge branch panama-vector:vectorIntrinsics+mask' into JDK-8266287
 - Use "Flag_is_predicated_vector" for masked vector nodes
 - Merge branch 'vectorIntrinsics+mask'
 - 8266287: Basic mask IR implementation for the Vector API masking feature support

-------------

Changes: https://git.openjdk.java.net/panama-vector/pull/78/files
 Webrev: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=78&range=02
  Stats: 307 lines in 15 files changed: 237 ins; 21 del; 49 mod
  Patch: https://git.openjdk.java.net/panama-vector/pull/78.diff
  Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/78/head:pull/78

PR: https://git.openjdk.java.net/panama-vector/pull/78

From xgong at openjdk.java.net  Mon Jun 21 09:56:42 2021
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Mon, 21 Jun 2021 09:56:42 GMT
Subject: [vectorIntrinsics+mask] RFR: 8266287: Basic mask IR
 implementation for the Vector API masking feature support [v2]
In-Reply-To: <0SyBueY0IDncXtoZ8Pc88k-C0-xuqf6_ITo5P_sF1q4=.cffb7d2f-8179-4eda-afb2-e55aa15c148d@github.com>
References: 
 <0SyBueY0IDncXtoZ8Pc88k-C0-xuqf6_ITo5P_sF1q4=.cffb7d2f-8179-4eda-afb2-e55aa15c148d@github.com>
Message-ID: 

On Mon, 24 May 2021 07:56:38 GMT, Xiaohong Gong  wrote:

>> Based on [1], this patch adds the C2 compiler mid-end changes for the masking feature support. It mainly contains:
>>  1) Generation of the mask IRs for vector mask, including:
>>     - Mask generations, e.g. load/compare/maskAll
>>     - Mask operations, e.g. and/or/xor
>>  2) Conversions between vector and mask after loading mask values from memory and before storing mask values into memory
>>  3) Generation of the vector IRs which need the mask value as the control
>>     - The mask value is appended to the original vector node's input list
>> 
>> With this change, the bottom type of the vector mask will be set to `"TypeVectMask"` if the platform supports the masking feature and the backend implementations are added.
>> 
>> Note that this patch only contains the compiler mid-end changes. The backend implementations for SVE/AVX-512 will be in the
>> followed-up patches.
>> 
>> [1] https://github.com/openjdk/panama-vector/pull/57
>
> Xiaohong Gong has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Use "Flag_is_predicated_vector" for masked vector nodes
>  - Merge branch 'vectorIntrinsics+mask'
>  - 8266287: Basic mask IR implementation for the Vector API masking feature support

Hi there, the new commit refines the C2 compiler IRs for vector mask. The main idea is trying to use the same nodes but with
different types (i.e. use `"TypeVectMask"` for SVE/AVX-512, while `"TypeVect"` for others). It doesn't need to create new IRs specially for SVE/AVX-512 predicate type. The `"idea_reg"` is decided by the type of the node, so that the compiler can choose the right register for vector mask during codegen.

For more details, the following existed IRs are kept to use normally:

 - fromArray: LoadVector + VectorLoadMask
 - compare:   VectorMaskCmp
 - others:    VectorMaskCast

And to spearate the IRs for vector and vector mask, the following mask IRs are added:

 - maskAll:    MaskAll
 - and/or/xor: AndVMask/OrVMask/XorVMask

Further more, to improve the performance of vector mask loading/storing with SVE, the following transformations are also kept:

 - fromArray:
     LoadVector + VectorLoadMask    ==>  LoadVectorMask
 - intoArray:
     VectorStoreMask + StoreVector  ==>  StoreVectorMask


Any feedback is welcome! Thanks so much!

Best Regards,
Xiaohong

-------------

PR: https://git.openjdk.java.net/panama-vector/pull/78

From elect86 at gmail.com  Mon Jun 21 14:22:50 2021
From: elect86 at gmail.com (Giuseppe Barbieri)
Date: Mon, 21 Jun 2021 16:22:50 +0200
Subject: Gihub Action, CI pipeline
In-Reply-To: 
References: 
 <3bc9f966-00bd-5280-3fab-53784480ba66@oracle.com>
 
Message-ID: 

Hi,


Erik replied that it's up to the people/devs working on panama to decide
whether to use Github Actions or not

https://mail.openjdk.java.net/pipermail/build-dev/2021-June/031568.html

So, in case you guys are interested, I fixed the linux64 and macos64
builds: now the clang llvm 12.0 binaries will be downloaded (and cached)

https://github.com/elect86/panama-foreign/actions/runs/956676104

I'm publishing everything, every kind of builds plus all the test results
and supports

https://github.com/elect86/panama-foreign/releases

Right now there is an additional workflow which check every 10m if there
are any new commits upstream, but this of course won't be needed if the
whole gets merged

There is just some minor polishing left regarding the release text to do,
but this is minor stuff


Giuseppe

Il giorno mar 15 giu 2021 alle ore 22:26 Giuseppe Barbieri <
elect86 at gmail.com> ha scritto:

> This is not possible - we do not publish builds using GitHub actions.
>> This is not a panama decision, but a JDK-wide one.
>>
>> If you want to discuss that I'd suggest to redirect your question to a
>> more general forum like jdk-dev or build-dev.
>>
>
> Ok, I'll propose maybe something over there then
>
> I believe this has been fixed upstream - butt there were merge issues
>> which we have rectified today. So perhaps it should be ok now?
>>
>> Maurizio
>>
>
> Yes, it's, thanks
>
> Giuseppe
>

From uschindler at openjdk.java.net  Mon Jun 21 14:25:10 2021
From: uschindler at openjdk.java.net (Uwe Schindler)
Date: Mon, 21 Jun 2021 14:25:10 GMT
Subject: [foreign-memaccess+abi] RFR: 8268743: Require a better way for
 copying data between MemorySegments and on-heap arrays
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

On Wed, 16 Jun 2021 11:13:41 GMT, Maurizio Cimadamore  wrote:

>>> > To call the new static MemorySegment.copy() method, I still need to wrap the byte[] array, so I should merge in THIS pull request? From looking at your repository it does not seem to have the HeapMemorySegment SMALL change.
>>> 
>>> Leave alone this pull request, and just work off the branch I pointed out, which contains the static method. The static method just takes two segments, two offsets (in bytes) and a length, it's like System.arrayCopy.
>> 
>> I will just check both branches separately. First this pull request, if it makes the allocations go away (which looks like it won't). Then the other one.
>> 
>> Give me a few days, will work on this after the conference.
>> 
>>> But let's first verify that this is indeed what's causing the degradation for Lucene. You mentioned that the copy method were called "millions of times" which makes it unlikely for them to be completely "cold" and unoptimized.
>> 
>> That was meant "symbolic". Not sure how often it is called in reality. But from the number of allocations on heap, it seems often. We found similar issues in the past, too: Sometimes Hotspot refuses to optimize a method for unknown reasons. It seems to have to do with how it is called. Sometimes the complexity of code inside Lucene is dramatic. Internals are looking very "C like". Huge methods with complex spaghetti-like logic, randomly calling methods from MemorySegmentIndexInput (previously ByteBufferIndexInput). Most of the logic uses the "iterator/enum" aproach. Search thread gets new document hits by consuming some enum, which itsself calls IndexInput.
>
>> I will just check both branches separately. First this pull request, if it makes the allocations go away (which looks like it won't). Then the other one.
> 
> You might also wanna try the one in:
> https://github.com/openjdk/panama-foreign/pull/555
> 
> As you said, the fact that the copy is wrapped in a `@ForceInline` might help. Also, I realized (and that's probably what you were referring to) that the single static copy method would still require wrapping the array in a segment.

Hi @mcimadamore, 
this pull request helps nothing. The garbage is still created. I compiled a JDK with exactly this branch and ran the benchmark against it:


thetaphi at serv1:~/panama-foreign$ git remote -v
mcimadamore     https://github.com/mcimadamore/panama-foreign.git (fetch)
mcimadamore     https://github.com/mcimadamore/panama-foreign.git (push)
origin  https://github.com/openjdk/panama-foreign.git (fetch)
origin  https://github.com/openjdk/panama-foreign.git (push)
thetaphi at serv1:~/panama-foreign$ git status
On branch copy-bench-lucene
Your branch is up to date with 'mcimadamore/copy-bench-lucene'.

nothing to commit, working tree clean
thetaphi at serv1:~/panama-foreign$


JFR output looks identical. Again it is worse with `-Xbatch` and `-XX:-TieredCompilation` from the total runtime.

I will now try #555 as an alternative. To me it looks like Hotspot does not try to optimize the methods at all because maybe the complex structure of our code.

-------------

PR: https://git.openjdk.java.net/panama-foreign/pull/560

From uschindler at openjdk.java.net  Mon Jun 21 14:29:37 2021
From: uschindler at openjdk.java.net (Uwe Schindler)
Date: Mon, 21 Jun 2021 14:29:37 GMT
Subject: [foreign-memaccess+abi] RFR: 8268743: Require a better way for
 copying data between MemorySegments and on-heap arrays
In-Reply-To: 
References: 
Message-ID: 

On Tue, 15 Jun 2021 11:56:26 GMT, Maurizio Cimadamore  wrote:

> After some investigation, it seems that escape analysis is defeated in cases where a new heap segment is created fresh just before performing a bulk copy.
> 
> This is caused by the fact that, on segment creation, we perform this test:
> 
> 
> static int defaultAccessModes(long size) {
>         return (enableSmallSegments && size < Integer.MAX_VALUE) ?
>                 SMALL : 0;
>     }
> 
> 
> To make sure that segments whose size fits in an `int` do not incur in penalties associated with lack of optimizations over long loop bound check optimizations.
> 
> Unfortunately, this logic is control flow logic, and control flow disables escape analysis optimizations.
> 
> For segment wrappers around byte arrays we can workaround by removing the check (all byte segments are small by definition, since there's a 1-1 mapping between logical elements and physical bytes). For other segment kinds we cannot do much.
> 
> While it would be possible, in principle, to resort to more complex bound checks for heap segments, we believe the way forward is to eliminate the need for "small" segments, which will be possible once the PR below is completed:
> 
> https://github.com/openjdk/jdk/pull/2045

I think this one can be closed.

-------------

PR: https://git.openjdk.java.net/panama-foreign/pull/560

From maurizio.cimadamore at oracle.com  Mon Jun 21 14:41:24 2021
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 21 Jun 2021 15:41:24 +0100
Subject: Gihub Action, CI pipeline
In-Reply-To: 
References: 
 <3bc9f966-00bd-5280-3fab-53784480ba66@oracle.com>
 
 
Message-ID: <00f6a5e4-1481-54ee-7ed5-3feba821f4cb@oracle.com>

Thanks Giuseppe,
while we *could* enable GitHub actions as a why to have some CI (like we 
have in upstream JDK) it would not be ok for us to use GitHub actions to 
publish binaries. The binaries we publish end up in jdk.java.net [1] and 
we have no plans to change that.

Maurizio

[1] - https://jdk.java.net/panama/

On 21/06/2021 15:22, Giuseppe Barbieri wrote:
> Hi,
>
>
> Erik replied that it's up to the people/devs working on panama to 
> decide whether to use Github Actions or not
>
> https://mail.openjdk.java.net/pipermail/build-dev/2021-June/031568.html 
> 
>
> So, in case you guys are interested, I fixed the linux64 and macos64 
> builds: now the clang llvm 12.0 binaries will be downloaded (and cached)
>
> https://github.com/elect86/panama-foreign/actions/runs/956676104 
> 
>
> I'm publishing everything, every kind of builds plus all the test 
> results and supports
>
> https://github.com/elect86/panama-foreign/releases 
> 
>
> Right now there is an additional workflow which check every 10m if 
> there are any new commits upstream, but this of course won't be needed 
> if the whole gets merged
>
> There is just some minor polishing left regarding the release text to 
> do, but this is minor stuff
>
>
> Giuseppe
>
> Il giorno mar 15 giu 2021 alle ore 22:26 Giuseppe Barbieri 
> > ha scritto:
>
>         This is not possible - we do not publish builds using GitHub
>         actions.
>         This is not a panama decision, but a JDK-wide one.
>
>         If you want to discuss that I'd suggest to redirect your
>         question to a
>         more general forum like jdk-dev or build-dev.
>
>
>     Ok, I'll propose maybe something over there then
>
>         I believe this has been fixed upstream - butt there were merge
>         issues
>         which we have rectified today. So perhaps it should be ok now?
>
>         Maurizio
>
>
>     Yes, it's, thanks
>
>     Giuseppe
>

From mcimadamore at openjdk.java.net  Mon Jun 21 14:41:08 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 21 Jun 2021 14:41:08 GMT
Subject: [foreign-memaccess+abi] RFR: 8268743: Require a better way for
 copying data between MemorySegments and on-heap arrays
In-Reply-To: 
References: 
Message-ID: 

On Tue, 15 Jun 2021 11:56:26 GMT, Maurizio Cimadamore  wrote:

> After some investigation, it seems that escape analysis is defeated in cases where a new heap segment is created fresh just before performing a bulk copy.
> 
> This is caused by the fact that, on segment creation, we perform this test:
> 
> 
> static int defaultAccessModes(long size) {
>         return (enableSmallSegments && size < Integer.MAX_VALUE) ?
>                 SMALL : 0;
>     }
> 
> 
> To make sure that segments whose size fits in an `int` do not incur in penalties associated with lack of optimizations over long loop bound check optimizations.
> 
> Unfortunately, this logic is control flow logic, and control flow disables escape analysis optimizations.
> 
> For segment wrappers around byte arrays we can workaround by removing the check (all byte segments are small by definition, since there's a 1-1 mapping between logical elements and physical bytes). For other segment kinds we cannot do much.
> 
> While it would be possible, in principle, to resort to more complex bound checks for heap segments, we believe the way forward is to eliminate the need for "small" segments, which will be possible once the PR below is completed:
> 
> https://github.com/openjdk/jdk/pull/2045

Closing as it does not address the original problem.

-------------

PR: https://git.openjdk.java.net/panama-foreign/pull/560

From mcimadamore at openjdk.java.net  Mon Jun 21 14:41:09 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 21 Jun 2021 14:41:09 GMT
Subject: [foreign-memaccess+abi] Withdrawn: 8268743: Require a better way for
 copying data between MemorySegments and on-heap arrays
In-Reply-To: 
References: 
Message-ID: 

On Tue, 15 Jun 2021 11:56:26 GMT, Maurizio Cimadamore  wrote:

> After some investigation, it seems that escape analysis is defeated in cases where a new heap segment is created fresh just before performing a bulk copy.
> 
> This is caused by the fact that, on segment creation, we perform this test:
> 
> 
> static int defaultAccessModes(long size) {
>         return (enableSmallSegments && size < Integer.MAX_VALUE) ?
>                 SMALL : 0;
>     }
> 
> 
> To make sure that segments whose size fits in an `int` do not incur in penalties associated with lack of optimizations over long loop bound check optimizations.
> 
> Unfortunately, this logic is control flow logic, and control flow disables escape analysis optimizations.
> 
> For segment wrappers around byte arrays we can workaround by removing the check (all byte segments are small by definition, since there's a 1-1 mapping between logical elements and physical bytes). For other segment kinds we cannot do much.
> 
> While it would be possible, in principle, to resort to more complex bound checks for heap segments, we believe the way forward is to eliminate the need for "small" segments, which will be possible once the PR below is completed:
> 
> https://github.com/openjdk/jdk/pull/2045

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/panama-foreign/pull/560

From uschindler at openjdk.java.net  Mon Jun 21 15:16:55 2021
From: uschindler at openjdk.java.net (Uwe Schindler)
Date: Mon, 21 Jun 2021 15:16:55 GMT
Subject: [foreign-memaccess+abi] RFR: Add support for high-level functions
 to copy to and from Java arrays
In-Reply-To: 
References: 
Message-ID: 

On Thu, 10 Jun 2021 13:03:09 GMT, Maurizio Cimadamore  wrote:

> This patch includes some of the changes from Lee to support a set of static functions to allow bulk copy from Java arrays to segments (and viceversa) in a more succint fashion (so that the user doesn't have to create a temporary heap segment to do the copy).
> 
> I've added a new public method to `MemorySegment` which performs an *element-wise* bulk copy; it takes a source segment and a couple of element layouts: the source element layout and the destination element layout. The two layouts must have same size, but can have different alignments (which will be checked against the corresponding segments) and byte orders. If the byte order differs, a bulk copy with swap will be performed. As such, this method generalizes the previous `copyFrom` - as follows:
> 
> 
> copyFrom(srcSegment) -> copyFrom(JAVA_BYTE, srcSegment, JAVA_BYTE)
> 
> I've added support for argument type profiling for MemoryCopy static methods to avoid type pollution in cases where same metod is called with different memory segment types.
> 
> I've done a pass over the javadoc, and make it more consistent with the rest of the API. I've also reworked the test a bit to use the data provider functionality of TestNG, since all the test cases were similar, except for the carrier type.
> 
> There are other cosmetic changes as well, compared to original code from Lee, such as naming of static fields which is now capitalized. Everything else is the same.

Hi,
when testing this with Lucene, Irecognized the following:


org.apache.lucene.store.TestMultiMMap > test suite's output saved to /home/thetaphi/benchmark/lucene_candidate/lucene/core/build/test-results/test/outputs/OUTPUT-org.apache.lucene.store.TestMultiMMap.txt, copied below:
   >     java.lang.IllegalArgumentException: Source segment incompatible with alignment constraints
   >         at __randomizedtesting.SeedInfo.seed([90A99875BABA30A6:B162CD10DB95DFC]:0)
   >         at jdk.incubator.foreign/jdk.internal.foreign.AbstractMemorySegmentImpl.copyFrom(AbstractMemorySegmentImpl.java:158)
   >         at jdk.incubator.foreign/jdk.incubator.foreign.MemoryCopy.copyToArray(MemoryCopy.java:493)
   >         at org.apache.lucene.store.MemorySegmentIndexInput.readLongs(MemorySegmentIndexInput.java:204)


So it is impossible to copy stuff if the source segment is not at an aligned position. Unfortunately, with data inside a memory mapped file it may often happen that data is not properly aligned, but you still need to copy them (including swapping).

-------------

PR: https://git.openjdk.java.net/panama-foreign/pull/555

From mcimadamore at openjdk.java.net  Mon Jun 21 15:25:11 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 21 Jun 2021 15:25:11 GMT
Subject: [foreign-memaccess+abi] RFR: Add support for high-level functions
 to copy to and from Java arrays
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 21 Jun 2021 15:14:04 GMT, Uwe Schindler  wrote:

> Hi,
> when testing this with Lucene, Irecognized the following:
> 
> ```
> org.apache.lucene.store.TestMultiMMap > test suite's output saved to /home/thetaphi/benchmark/lucene_candidate/lucene/core/build/test-results/test/outputs/OUTPUT-org.apache.lucene.store.TestMultiMMap.txt, copied below:
>    >     java.lang.IllegalArgumentException: Source segment incompatible with alignment constraints
>    >         at __randomizedtesting.SeedInfo.seed([90A99875BABA30A6:B162CD10DB95DFC]:0)
>    >         at jdk.incubator.foreign/jdk.internal.foreign.AbstractMemorySegmentImpl.copyFrom(AbstractMemorySegmentImpl.java:158)
>    >         at jdk.incubator.foreign/jdk.incubator.foreign.MemoryCopy.copyToArray(MemoryCopy.java:493)
>    >         at org.apache.lucene.store.MemorySegmentIndexInput.readLongs(MemorySegmentIndexInput.java:204)
> ```
> 
> So it is impossible to copy stuff if the source segment is not at an aligned position. Unfortunately, with data inside a memory mapped file it may often happen that data is not properly aligned, but you still need to copy them (including swapping).

This is an issue in the layouts used by the MemoryCopy class. I meant to drop all alignment constraints from them when doing another pass on the code, but it seems like I forgot.

-------------

PR: https://git.openjdk.java.net/panama-foreign/pull/555

From uschindler at openjdk.java.net  Mon Jun 21 15:32:53 2021
From: uschindler at openjdk.java.net (Uwe Schindler)
Date: Mon, 21 Jun 2021 15:32:53 GMT
Subject: [foreign-memaccess+abi] RFR: Add support for high-level functions
 to copy to and from Java arrays
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 21 Jun 2021 15:21:43 GMT, Maurizio Cimadamore  wrote:

> > Hi,
> > when testing this with Lucene, Irecognized the following:
> > ```
> > org.apache.lucene.store.TestMultiMMap > test suite's output saved to /home/thetaphi/benchmark/lucene_candidate/lucene/core/build/test-results/test/outputs/OUTPUT-org.apache.lucene.store.TestMultiMMap.txt, copied below:
> >    >     java.lang.IllegalArgumentException: Source segment incompatible with alignment constraints
> >    >         at __randomizedtesting.SeedInfo.seed([90A99875BABA30A6:B162CD10DB95DFC]:0)
> >    >         at jdk.incubator.foreign/jdk.internal.foreign.AbstractMemorySegmentImpl.copyFrom(AbstractMemorySegmentImpl.java:158)
> >    >         at jdk.incubator.foreign/jdk.incubator.foreign.MemoryCopy.copyToArray(MemoryCopy.java:493)
> >    >         at org.apache.lucene.store.MemorySegmentIndexInput.readLongs(MemorySegmentIndexInput.java:204)
> > ```
> > 
> > 
> >     
> >       
> >     
> > 
> >       
> >     
> > 
> >     
> >   
> > So it is impossible to copy stuff if the source segment is not at an aligned position. Unfortunately, with data inside a memory mapped file it may often happen that data is not properly aligned, but you still need to copy them (including swapping).
> 
> This is an issue in the layouts used by the MemoryCopy class. I meant to drop all alignment constraints from them when doing another pass on the code, but it seems like I forgot.

No problem, I just commented out the long/float methods and the tests were passing. I am now benchmarking, but again it looks not so well with the garbage created... (see #560). But I have to wait for the benchmark to finish.

-------------

PR: https://git.openjdk.java.net/panama-foreign/pull/555

From mcimadamore at openjdk.java.net  Mon Jun 21 15:38:35 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 21 Jun 2021 15:38:35 GMT
Subject: [foreign-memaccess+abi] RFR: Add support for high-level functions
 to copy to and from Java arrays
In-Reply-To: 
References: 
Message-ID: 

On Thu, 10 Jun 2021 13:03:09 GMT, Maurizio Cimadamore  wrote:

> This patch includes some of the changes from Lee to support a set of static functions to allow bulk copy from Java arrays to segments (and viceversa) in a more succint fashion (so that the user doesn't have to create a temporary heap segment to do the copy).
> 
> I've added a new public method to `MemorySegment` which performs an *element-wise* bulk copy; it takes a source segment and a couple of element layouts: the source element layout and the destination element layout. The two layouts must have same size, but can have different alignments (which will be checked against the corresponding segments) and byte orders. If the byte order differs, a bulk copy with swap will be performed. As such, this method generalizes the previous `copyFrom` - as follows:
> 
> 
> copyFrom(srcSegment) -> copyFrom(JAVA_BYTE, srcSegment, JAVA_BYTE)
> 
> I've added support for argument type profiling for MemoryCopy static methods to avoid type pollution in cases where same metod is called with different memory segment types.
> 
> I've done a pass over the javadoc, and make it more consistent with the rest of the API. I've also reworked the test a bit to use the data provider functionality of TestNG, since all the test cases were similar, except for the carrier type.
> 
> There are other cosmetic changes as well, compared to original code from Lee, such as naming of static fields which is now capitalized. Everything else is the same.

I've fixed the alignment issue and uploaded a new revision.

-------------

PR: https://git.openjdk.java.net/panama-foreign/pull/555

From mcimadamore at openjdk.java.net  Mon Jun 21 15:38:35 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 21 Jun 2021 15:38:35 GMT
Subject: [foreign-memaccess+abi] RFR: Add support for high-level functions
 to copy to and from Java arrays [v2]
In-Reply-To: 
References: 
Message-ID: 

> This patch includes some of the changes from Lee to support a set of static functions to allow bulk copy from Java arrays to segments (and viceversa) in a more succint fashion (so that the user doesn't have to create a temporary heap segment to do the copy).
> 
> I've added a new public method to `MemorySegment` which performs an *element-wise* bulk copy; it takes a source segment and a couple of element layouts: the source element layout and the destination element layout. The two layouts must have same size, but can have different alignments (which will be checked against the corresponding segments) and byte orders. If the byte order differs, a bulk copy with swap will be performed. As such, this method generalizes the previous `copyFrom` - as follows:
> 
> 
> copyFrom(srcSegment) -> copyFrom(JAVA_BYTE, srcSegment, JAVA_BYTE)
> 
> I've added support for argument type profiling for MemoryCopy static methods to avoid type pollution in cases where same metod is called with different memory segment types.
> 
> I've done a pass over the javadoc, and make it more consistent with the rest of the API. I've also reworked the test a bit to use the data provider functionality of TestNG, since all the test cases were similar, except for the carrier type.
> 
> There are other cosmetic changes as well, compared to original code from Lee, such as naming of static fields which is now capitalized. Everything else is the same.

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Remove alignment constraints from MemoryCopy layouts

-------------

Changes:
  - all: https://git.openjdk.java.net/panama-foreign/pull/555/files
  - new: https://git.openjdk.java.net/panama-foreign/pull/555/files/2c6fa450..85a9786a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=555&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=555&range=00-01

  Stats: 28 lines in 2 files changed: 22 ins; 0 del; 6 mod
  Patch: https://git.openjdk.java.net/panama-foreign/pull/555.diff
  Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/555/head:pull/555

PR: https://git.openjdk.java.net/panama-foreign/pull/555

From uschindler at openjdk.java.net  Mon Jun 21 15:50:51 2021
From: uschindler at openjdk.java.net (Uwe Schindler)
Date: Mon, 21 Jun 2021 15:50:51 GMT
Subject: [foreign-memaccess+abi] RFR: Add support for high-level functions
 to copy to and from Java arrays [v2]
In-Reply-To: 
References: 
 
Message-ID: <2yJqTDzEribd6T24dUzMhJePZZOuXgWfVJ2twpzDXY0=.494ae07a-0c23-4829-a106-d42126caefaf@github.com>

On Mon, 21 Jun 2021 15:38:35 GMT, Maurizio Cimadamore  wrote:

>> This patch includes some of the changes from Lee to support a set of static functions to allow bulk copy from Java arrays to segments (and viceversa) in a more succint fashion (so that the user doesn't have to create a temporary heap segment to do the copy).
>> 
>> I've added a new public method to `MemorySegment` which performs an *element-wise* bulk copy; it takes a source segment and a couple of element layouts: the source element layout and the destination element layout. The two layouts must have same size, but can have different alignments (which will be checked against the corresponding segments) and byte orders. If the byte order differs, a bulk copy with swap will be performed. As such, this method generalizes the previous `copyFrom` - as follows:
>> 
>> 
>> copyFrom(srcSegment) -> copyFrom(JAVA_BYTE, srcSegment, JAVA_BYTE)
>> 
>> I've added support for argument type profiling for MemoryCopy static methods to avoid type pollution in cases where same metod is called with different memory segment types.
>> 
>> I've done a pass over the javadoc, and make it more consistent with the rest of the API. I've also reworked the test a bit to use the data provider functionality of TestNG, since all the test cases were similar, except for the carrier type.
>> 
>> There are other cosmetic changes as well, compared to original code from Lee, such as naming of static fields which is now capitalized. Everything else is the same.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove alignment constraints from MemoryCopy layouts

If you're interested, here's my branch and modification to use this PR in Lucene - as you see the new `MemoryCopy` fits our needs perfectly: https://github.com/uschindler/lucene/blob/048434b9e3cb8aa515d9c1d7f57b44182704ab09/lucene/core/src/java/org/apache/lucene/store/MemorySegmentIndexInput.java#L164-L176

Scroll down to see the long/float versions, currently commented out.

-------------

PR: https://git.openjdk.java.net/panama-foreign/pull/555

From uschindler at openjdk.java.net  Mon Jun 21 16:06:38 2021
From: uschindler at openjdk.java.net (Uwe Schindler)
Date: Mon, 21 Jun 2021 16:06:38 GMT
Subject: [foreign-memaccess+abi] RFR: Add support for high-level functions
 to copy to and from Java arrays [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 21 Jun 2021 15:38:35 GMT, Maurizio Cimadamore  wrote:

>> This patch includes some of the changes from Lee to support a set of static functions to allow bulk copy from Java arrays to segments (and viceversa) in a more succint fashion (so that the user doesn't have to create a temporary heap segment to do the copy).
>> 
>> I've added a new public method to `MemorySegment` which performs an *element-wise* bulk copy; it takes a source segment and a couple of element layouts: the source element layout and the destination element layout. The two layouts must have same size, but can have different alignments (which will be checked against the corresponding segments) and byte orders. If the byte order differs, a bulk copy with swap will be performed. As such, this method generalizes the previous `copyFrom` - as follows:
>> 
>> 
>> copyFrom(srcSegment) -> copyFrom(JAVA_BYTE, srcSegment, JAVA_BYTE)
>> 
>> I've added support for argument type profiling for MemoryCopy static methods to avoid type pollution in cases where same metod is called with different memory segment types.
>> 
>> I've done a pass over the javadoc, and make it more consistent with the rest of the API. I've also reworked the test a bit to use the data provider functionality of TestNG, since all the test cases were similar, except for the carrier type.
>> 
>> There are other cosmetic changes as well, compared to original code from Lee, such as naming of static fields which is now capitalized. Everything else is the same.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove alignment constraints from MemoryCopy layouts

I don't want to post too much in this issue as it is not fully related, but it looks this is also affected by the same garbage problem described in https://bugs.openjdk.java.net/browse/JDK-8268743:


PROFILE SUMMARY from 14119950 events (total: 4897631M)
  tests.profile.mode=heap
  tests.profile.count=30
  tests.profile.stacksize=1
  tests.profile.linenumbers=false
PERCENT       HEAP SAMPLES  STACK
49.63%        2430891M      jdk.internal.foreign.MappedMemorySegmentImpl#dup()
28.37%        1389691M      jdk.internal.foreign.HeapMemorySegmentImpl$OfByte#fromArray()
21.43%        1049362M      jdk.internal.foreign.HeapMemorySegmentImpl$OfByte#dup()
0.09%         4624M         org.apache.lucene.util.FixedBitSet#()


See the number of heap samples, this cannot be! The only difference to the JFR heap profile in https://bugs.openjdk.java.net/browse/JDK-8268743 is the order (here we have more dups of the MappedMemorySegment (source from where it is copied).

-------------

PR: https://git.openjdk.java.net/panama-foreign/pull/555

From uschindler at openjdk.java.net  Mon Jun 21 16:11:55 2021
From: uschindler at openjdk.java.net (Uwe Schindler)
Date: Mon, 21 Jun 2021 16:11:55 GMT
Subject: [foreign-memaccess+abi] RFR: Add support for high-level functions
 to copy to and from Java arrays [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 21 Jun 2021 15:38:35 GMT, Maurizio Cimadamore  wrote:

>> This patch includes some of the changes from Lee to support a set of static functions to allow bulk copy from Java arrays to segments (and viceversa) in a more succint fashion (so that the user doesn't have to create a temporary heap segment to do the copy).
>> 
>> I've added a new public method to `MemorySegment` which performs an *element-wise* bulk copy; it takes a source segment and a couple of element layouts: the source element layout and the destination element layout. The two layouts must have same size, but can have different alignments (which will be checked against the corresponding segments) and byte orders. If the byte order differs, a bulk copy with swap will be performed. As such, this method generalizes the previous `copyFrom` - as follows:
>> 
>> 
>> copyFrom(srcSegment) -> copyFrom(JAVA_BYTE, srcSegment, JAVA_BYTE)
>> 
>> I've added support for argument type profiling for MemoryCopy static methods to avoid type pollution in cases where same metod is called with different memory segment types.
>> 
>> I've done a pass over the javadoc, and make it more consistent with the rest of the API. I've also reworked the test a bit to use the data provider functionality of TestNG, since all the test cases were similar, except for the carrier type.
>> 
>> There are other cosmetic changes as well, compared to original code from Lee, such as naming of static fields which is now capitalized. Everything else is the same.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove alignment constraints from MemoryCopy layouts

Good news: I can confirm after a quick test that memory copy now works with unaligned offsets! ??

-------------

PR: https://git.openjdk.java.net/panama-foreign/pull/555

From mcimadamore at openjdk.java.net  Mon Jun 21 16:23:35 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 21 Jun 2021 16:23:35 GMT
Subject: [foreign-memaccess+abi] RFR: Add support for high-level functions
 to copy to and from Java arrays [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 21 Jun 2021 16:03:34 GMT, Uwe Schindler  wrote:

> I don't want to post too much in this issue as it is not fully related, but it looks this is also affected by the same garbage problem described in https://bugs.openjdk.java.net/browse/JDK-8268743:
> 
> ```
> PROFILE SUMMARY from 14119950 events (total: 4897631M)
>   tests.profile.mode=heap
>   tests.profile.count=30
>   tests.profile.stacksize=1
>   tests.profile.linenumbers=false
> PERCENT       HEAP SAMPLES  STACK
> 49.63%        2430891M      jdk.internal.foreign.MappedMemorySegmentImpl#dup()
> 28.37%        1389691M      jdk.internal.foreign.HeapMemorySegmentImpl$OfByte#fromArray()
> 21.43%        1049362M      jdk.internal.foreign.HeapMemorySegmentImpl$OfByte#dup()
> 0.09%         4624M         org.apache.lucene.util.FixedBitSet#()
> ```
> 
> See the number of heap samples, this cannot be! The only difference to the JFR heap profile in https://bugs.openjdk.java.net/browse/JDK-8268743 is the order (here we have more dups of the MappedMemorySegment (source from where it is copied).

This is strange. All the copy methods are now forced inlined, so I can't understand why you would observe allocation coming from there (I would expect C2 to just optimize that method regardless of its context). The only thing left for you to try is this:

https://github.com/mcimadamore/panama-foreign/tree/small_copy_benchmark/

Which contains a static method `copy` in MemorySegment which takes offsets. This method avoids the slices (but you would still need to wrap arrays) - it would be interesting to see if the allocation profile on Lucene changes at all.

-------------

PR: https://git.openjdk.java.net/panama-foreign/pull/555

From mcimadamore at openjdk.java.net  Mon Jun 21 16:55:49 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 21 Jun 2021 16:55:49 GMT
Subject: [foreign-memaccess+abi] RFR: Add support for high-level functions
 to copy to and from Java arrays [v2]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Mon, 21 Jun 2021 16:20:56 GMT, Maurizio Cimadamore  wrote:

> > I don't want to post too much in this issue as it is not fully related, but it looks this is also affected by the same garbage problem described in https://bugs.openjdk.java.net/browse/JDK-8268743:
> > ```
> > PROFILE SUMMARY from 14119950 events (total: 4897631M)
> >   tests.profile.mode=heap
> >   tests.profile.count=30
> >   tests.profile.stacksize=1
> >   tests.profile.linenumbers=false
> > PERCENT       HEAP SAMPLES  STACK
> > 49.63%        2430891M      jdk.internal.foreign.MappedMemorySegmentImpl#dup()
> > 28.37%        1389691M      jdk.internal.foreign.HeapMemorySegmentImpl$OfByte#fromArray()
> > 21.43%        1049362M      jdk.internal.foreign.HeapMemorySegmentImpl$OfByte#dup()
> > 0.09%         4624M         org.apache.lucene.util.FixedBitSet#()
> > ```
> > 
> > 
> >     
> >       
> >     
> > 
> >       
> >     
> > 
> >     
> >   
> > See the number of heap samples, this cannot be! The only difference to the JFR heap profile in https://bugs.openjdk.java.net/browse/JDK-8268743 is the order (here we have more dups of the MappedMemorySegment (source from where it is copied).
> 
> This is strange. All the copy methods are now forced inlined, so I can't understand why you would observe allocation coming from there (I would expect C2 to just optimize that method regardless of its context). The only thing left for you to try is this:
> 
> https://github.com/mcimadamore/panama-foreign/tree/small_copy_benchmark/
> 
> Which contains a static method `copy` in MemorySegment which takes offsets. This method avoids the slices (but you would still need to wrap arrays) - it would be interesting to see if the allocation profile on Lucene changes at all.

Also, would it be possible for you to check if the methods in MemoryCopy are compiled at all? `@ForceInline` won't do much if the method that caller is not compiled, it seems.

-------------

PR: https://git.openjdk.java.net/panama-foreign/pull/555

From uschindler at openjdk.java.net  Mon Jun 21 17:10:38 2021
From: uschindler at openjdk.java.net (Uwe Schindler)
Date: Mon, 21 Jun 2021 17:10:38 GMT
Subject: [foreign-memaccess+abi] RFR: Add support for high-level functions
 to copy to and from Java arrays [v2]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: <8Vt_NqVmzU7pMk3bqT2DGljVKrtDX78wGNMeaeTnJ-Q=.a2c14ff4-ae57-490c-9d04-938e2131af6a@github.com>

On Mon, 21 Jun 2021 16:53:31 GMT, Maurizio Cimadamore  wrote:

> Also, would it be possible for you to check if the methods in MemoryCopy are compiled at all? @ForceInline won't do much if the method that caller is not compiled, it seems.

Will do once I figured out how to change this in our benchmark tool. But I think I can just pass the correct command line options to print compilations inside the class.

Let me check your other branch first!

-------------

PR: https://git.openjdk.java.net/panama-foreign/pull/555

From uschindler at openjdk.java.net  Mon Jun 21 17:23:03 2021
From: uschindler at openjdk.java.net (Uwe Schindler)
Date: Mon, 21 Jun 2021 17:23:03 GMT
Subject: [foreign-memaccess+abi] RFR: Add support for high-level functions
 to copy to and from Java arrays [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 21 Jun 2021 15:38:35 GMT, Maurizio Cimadamore  wrote:

>> This patch includes some of the changes from Lee to support a set of static functions to allow bulk copy from Java arrays to segments (and viceversa) in a more succint fashion (so that the user doesn't have to create a temporary heap segment to do the copy).
>> 
>> I've added a new public method to `MemorySegment` which performs an *element-wise* bulk copy; it takes a source segment and a couple of element layouts: the source element layout and the destination element layout. The two layouts must have same size, but can have different alignments (which will be checked against the corresponding segments) and byte orders. If the byte order differs, a bulk copy with swap will be performed. As such, this method generalizes the previous `copyFrom` - as follows:
>> 
>> 
>> copyFrom(srcSegment) -> copyFrom(JAVA_BYTE, srcSegment, JAVA_BYTE)
>> 
>> I've added support for argument type profiling for MemoryCopy static methods to avoid type pollution in cases where same metod is called with different memory segment types.
>> 
>> I've done a pass over the javadoc, and make it more consistent with the rest of the API. I've also reworked the test a bit to use the data provider functionality of TestNG, since all the test cases were similar, except for the carrier type.
>> 
>> There are other cosmetic changes as well, compared to original code from Lee, such as naming of static fields which is now capitalized. Everything else is the same.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove alignment constraints from MemoryCopy layouts

I am testing now this change with your branch: https://github.com/apache/lucene/commit/02738d8140bde23dfcd22eeca1ca1acb16e8b15e

-------------

PR: https://git.openjdk.java.net/panama-foreign/pull/555

From uschindler at openjdk.java.net  Mon Jun 21 18:18:38 2021
From: uschindler at openjdk.java.net (Uwe Schindler)
Date: Mon, 21 Jun 2021 18:18:38 GMT
Subject: [foreign-memaccess+abi] RFR: Add support for high-level functions
 to copy to and from Java arrays [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 21 Jun 2021 15:38:35 GMT, Maurizio Cimadamore  wrote:

>> This patch includes some of the changes from Lee to support a set of static functions to allow bulk copy from Java arrays to segments (and viceversa) in a more succint fashion (so that the user doesn't have to create a temporary heap segment to do the copy).
>> 
>> I've added a new public method to `MemorySegment` which performs an *element-wise* bulk copy; it takes a source segment and a couple of element layouts: the source element layout and the destination element layout. The two layouts must have same size, but can have different alignments (which will be checked against the corresponding segments) and byte orders. If the byte order differs, a bulk copy with swap will be performed. As such, this method generalizes the previous `copyFrom` - as follows:
>> 
>> 
>> copyFrom(srcSegment) -> copyFrom(JAVA_BYTE, srcSegment, JAVA_BYTE)
>> 
>> I've added support for argument type profiling for MemoryCopy static methods to avoid type pollution in cases where same metod is called with different memory segment types.
>> 
>> I've done a pass over the javadoc, and make it more consistent with the rest of the API. I've also reworked the test a bit to use the data provider functionality of TestNG, since all the test cases were similar, except for the carrier type.
>> 
>> There are other cosmetic changes as well, compared to original code from Lee, such as naming of static fields which is now capitalized. Everything else is the same.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove alignment constraints from MemoryCopy layouts

With this variant, profile looks like this:

PROFILE SUMMARY from 316771 events (total: 112007M)
  tests.profile.mode=heap
  tests.profile.count=30
  tests.profile.stacksize=1
  tests.profile.linenumbers=false
PERCENT       HEAP SAMPLES  STACK
72.60%        81319M        jdk.internal.foreign.HeapMemorySegmentImpl$OfByte#fromArray()
4.23%         4738M         org.apache.lucene.util.FixedBitSet#()
3.14%         3516M         org.apache.lucene.search.ExactPhraseMatcher$1$1#getImpacts()
2.77%         3105M         org.apache.lucene.search.ExactPhraseMatcher$1#getImpacts()


Performance is much better, but not yet ideal!

Maybe you should really think about implementing all those copy methods between arrays and segments without slicing and ideally also without 

Wouldn't it be so complicated to just implement all the MemoryCopy methods like that?

-------------

PR: https://git.openjdk.java.net/panama-foreign/pull/555

From jvernee at openjdk.java.net  Mon Jun 21 18:31:39 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Mon, 21 Jun 2021 18:31:39 GMT
Subject: [foreign-memaccess+abi] RFR: Add support for high-level functions
 to copy to and from Java arrays [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 21 Jun 2021 15:38:35 GMT, Maurizio Cimadamore  wrote:

>> This patch includes some of the changes from Lee to support a set of static functions to allow bulk copy from Java arrays to segments (and viceversa) in a more succint fashion (so that the user doesn't have to create a temporary heap segment to do the copy).
>> 
>> I've added a new public method to `MemorySegment` which performs an *element-wise* bulk copy; it takes a source segment and a couple of element layouts: the source element layout and the destination element layout. The two layouts must have same size, but can have different alignments (which will be checked against the corresponding segments) and byte orders. If the byte order differs, a bulk copy with swap will be performed. As such, this method generalizes the previous `copyFrom` - as follows:
>> 
>> 
>> copyFrom(srcSegment) -> copyFrom(JAVA_BYTE, srcSegment, JAVA_BYTE)
>> 
>> I've added support for argument type profiling for MemoryCopy static methods to avoid type pollution in cases where same metod is called with different memory segment types.
>> 
>> I've done a pass over the javadoc, and make it more consistent with the rest of the API. I've also reworked the test a bit to use the data provider functionality of TestNG, since all the test cases were similar, except for the carrier type.
>> 
>> There are other cosmetic changes as well, compared to original code from Lee, such as naming of static fields which is now capitalized. Everything else is the same.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove alignment constraints from MemoryCopy layouts

I guess this is still ongoing, but for now some comments inline.

src/hotspot/share/oops/methodData.cpp line 1598:

> 1596:         return true;
> 1597:       }
> 1598:     }

Tbh, I'm a little skeptical about (the need for) adding argument type profiling at this point:
- Only the first 2 arguments to a method are profiled by default (controlled by `TypeProfileArgsLimit`) and if we care about the MemorySegment args, there will be no profiling of those for the `copyFromArray` methods.
- AFAICS, `Unsafe::copyMemory` is far less susceptible to changes in the type of the base pointers, which IIRC was the main reason why we added type profiling in the past for the MemoryAccess.* methods. The C2 intrinsic for copyMemory just always generates an out of line call with memory barriers [1].

[1] : https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/library_call.cpp#L4071-L4118

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemoryCopy.java line 40:

> 38:  * 

> 39:  * Copy operations defined in this class accept a byte order parameter. If the specified byte order is different
> 40:  * from the native byte order, a byte swap operation is performed on each array elements

This seems somewhat roundabout. Why not accept a `boolean swap` instead?

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemoryCopy.java line 137:

> 135:         MemorySegment srcSegmentSlice =
> 136:                 MemorySegment.ofArray(srcArray).asSlice(srcIndexChars * 2L, srcCopyLengthChars * 2L);
> 137:         MemorySegment dstSegmentSlice = dstSegment.asSlice(dstOffsetBytes, srcCopyLengthChars * 2L);

Little weird to see `srcCopyLengthChars` being used for the destination slice. But the length is the same for both of course. Maybe just drop the `src` prefix? (it's a nit though).

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemorySegment.java line 405:

> 403:      * @param src the source segment.
> 404:      * @param srcElementLayout the element layout associated with the source segment.
> 405:      * @throws IndexOutOfBoundsException if {@code src.byteSize() > this.byteSize()}.

Maybe this should be strengthened to require both segments to be the same size? (Otherwise I guess there's quickly a question of 'why can't I specify a destination offset here').

test/jdk/java/foreign/TestMemoryCopy.java line 49:

> 47:  * These tests exercise the MemoryCopy copyFromArray(...) and copyToArray(...).
> 48:  * To make these tests more challenging the segment is a view of the given array,
> 49:  * which makes the copy operations overlapping self-copies.  Thus, this checks the claim:

I'm not sure I understand this claim; it seems to me that the test sets up an array view segment, but then copies the contents into a new array (using toArray) as src/dst to do the actual copying? i.e. the source and destination seem disjoint.

test/jdk/java/foreign/TestMemoryCopy.java line 387:

> 385: 
> 386:     @DataProvider
> 387:     Object[][] copyModes() {

Seems unused.

-------------

PR: https://git.openjdk.java.net/panama-foreign/pull/555

From jorn.vernee at oracle.com  Mon Jun 21 18:52:01 2021
From: jorn.vernee at oracle.com (Jorn Vernee)
Date: Mon, 21 Jun 2021 20:52:01 +0200
Subject: Gihub Action, CI pipeline
In-Reply-To: 
References: 
Message-ID: <54503a2a-d115-329b-d159-53fa41ad3f9e@oracle.com>

On 15/06/2021 17:42, Giuseppe Barbieri wrote:
> For Windows, the LLVM release page has only .exe, so I'm unsure how to
> continue there, while for macOS arm there is no LLVM build..
FWIW, on Windows you can also get the LLVM package through scoop [1] 
(just `scoop install llvm`), or 7zip can also unpack the .exe you 
download from the LLVM download page (after changing the extension to .7z).

Cheers,
Jorn

[1] : https://scoop.sh/

From paul.sandoz at oracle.com  Mon Jun 21 19:33:30 2021
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 21 Jun 2021 19:33:30 +0000
Subject: Foreign + Vectors - benchmarks for copying and swapping
In-Reply-To: 
References: 
 
 <5290e44a-7c67-6ee6-57dc-9af646604082@oracle.com>
 
 <1a23ee05-f187-e6d8-900e-62e77cd73dc9@oracle.com>
 <0DE3B831-2C2C-475B-94FC-867039D6AFC4@oracle.com>
 <07ccd69f-d218-15da-1b71-7dcaa767a7be@oracle.com>
 <9989FFC5-6D13-4114-B32D-A08D427925D4@oracle.com>
 
 
Message-ID: <086778CB-EAC3-4A72-A7B5-E5D70522386F@oracle.com>

Ah! Nice find, I forgot about those barriers. We need to discuss with Vladimir, there are some subtle issues here (similar to that for Unsafe access).

I wrote my own benchmark to explore this is more detail:

  https://gist.github.com/PaulSandoz/b8b72e9c837cf6462d3b744a264f23c4

Results are in comments. Run against a recent build of github.com/openjdk/jdk/.

Some points of note:

- ByteBuffer and segment with vector access is penalized, I think due to the placement of CPU barriers, as you have found.
Disabling CPU barriers in vectorIntrinsics.cpp improves the performance, but, it?s still slower than array vector access as the address calculations are not as efficient.

- Array vector access does not result in unrolling, which is why for large inputs `array` is slower that `arrayScalar`.

- Segment scalar access is penalized compared to ByteBuffer (from allocate or allocateDirect) scalar access.

- There is some odd interaction going with tiered compilation and confined segment access, which is faster than non-tiered access.


?

Separately, I suspect we need to enhance the Vector API byte buffer access to ensure the access is scoped?

Paul.

[1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shared/c2/barrierSetC2.cpp#L64

> On Jun 20, 2021, at 6:48 PM, Rados?aw Smogura  wrote:
> 
> Hi,
> 
> I think I found what's going on.
> 
> https://github.com/rsmogura/panama-foreign/commit/64bf7a66a6c3cf5c4ee4f3d0b0e29128bc8e1321
> 
> Remove mem barriers after vector ops to increase performance ? rsmogura/panama-foreign at 64bf7a6
> Removing mem barriers increase performance by allowing loop to unroll. Other possible solution: allow traversal through mem barriers, and projections when finding loop back control. After ``` Ben...
> github.com
> ?
> Other approach would be to modify loop optimizations to find back control through chain of projections and mem barriersa (or maybe both?)
> 
> This idea makes copy much better (and even faster then native one in unrolled
> 
> VectorCopySegments.copyWithNative                 1024  avgt   10     20.293 ?    0.436  ns/op
> VectorCopySegments.copyWithNative              1048576  avgt   10  22270.840 ?  579.533  ns/op
> VectorCopySegments.copyWithNativeShared           1024  avgt   10     15.854 ?    0.061  ns/op
> VectorCopySegments.copyWithNativeShared        1048576  avgt   10  21948.236 ?   43.981  ns/op
> VectorCopySegments.copyWithNativeToArray          1024  avgt   10     20.318 ?    0.347  ns/op
> VectorCopySegments.copyWithNativeToArray       1048576  avgt   10  22142.499 ?  305.501  ns/op
> VectorCopySegments.copyWithVector                 1024  avgt   10     31.240 ?    0.333  ns/op
> VectorCopySegments.copyWithVector              1048576  avgt   10  25320.898 ?  118.397  ns/op
> VectorCopySegments.copyWithVectorDirectBuffer     1024  avgt   10     21.605 ?    0.210  ns/op
> VectorCopySegments.copyWithVectorDirectBuffer  1048576  avgt   10  23613.272 ? 1030.153  ns/op
> VectorCopySegments.copyWithVectorShared           1024  avgt   10     19.897 ?    0.485  ns/op
> VectorCopySegments.copyWithVectorShared        1048576  avgt   10  24719.767 ?  453.725  ns/op
> VectorCopySegments.copyWithVectorShuffle          1024  avgt   10     36.364 ?    0.669  ns/op
> VectorCopySegments.copyWithVectorShuffle       1048576  avgt   10  29730.528 ?  339.100  ns/op
> VectorCopySegments.copyWithVectorToArray          1024  avgt   10     29.282 ?    0.338  ns/op
> VectorCopySegments.copyWithVectorToArray       1048576  avgt   10  28502.004 ?  593.347  ns/op
> VectorCopySegments.copyWithVectorUnroller         1024  avgt   10     36.368 ?    0.092  ns/op
> VectorCopySegments.copyWithVectorUnroller      1048576  avgt   10  21528.433 ?  303.141  ns/op
> 
> 
> Kind regards,
> Rado
> 
> Od: panama-dev  w imieniu u?ytkownika Rados?aw Smogura 
> Wys?ane: sobota, 19 czerwca 2021 01:12
> Do: Paul Sandoz ; Maurizio Cimadamore 
> DW: panama-dev at openjdk.java.net 
> Temat: ODP: Foreign + Vectors - benchmarks for copying and swapping
>  
> Hi all,
> 
> So I have one more interesting thing, when I change loopBound to
> VectorIntrinsics.roundDown(length, laneCount) - (laneCount - 1)
> (I think it's better optimization)
> I have such results (please take a look at drop down in avg time) - that's for 1m size
> 
> # Warmup Iteration   2: 47990.588 ns/op
> # Warmup Iteration   3: 46073.341 ns/op
> # Warmup Iteration   4: 45593.405 ns/op
> # Warmup Iteration   5: 45525.001 ns/op
> Iteration   1: 45921.159 ns/op
> Iteration   2: 46542.631 ns/op
> Iteration   3: 45532.379 ns/op
> Iteration   4: 46862.923 ns/op
> Iteration   5: 49324.919 ns/op
> Iteration   6: 34099.454 ns/op
> Iteration   7: 22315.402 ns/op
> Iteration   8: 22495.426 ns/op
> Iteration   9: 22702.834 ns/op
> Iteration  10: 22675.853 ns/op
> 
> 
> Result "org.openjdk.bench.jdk.incubator.foreign.VectorCopySegments.copyWithVectorBuff":
>   35847.298 ?(99.9%) 18332.841 ns/op [Average]
>   (min, avg, max) = (22315.402, 35847.298, 49324.919), stdev = 12126.039
>   CI (99.9%): [17514.457, 54180.139] (assumes normal distribution)
> 
> Kind regards,
> Rado
> ________________________________
> Od: Paul Sandoz 
> Wys?ane: pi?tek, 18 czerwca 2021 23:37
> Do: Maurizio Cimadamore 
> DW: Rados?aw Smogura ; panama-dev at openjdk.java.net 
> Temat: Re: Foreign + Vectors - benchmarks for copying and swapping
> 
> 
> 
> > On Jun 18, 2021, at 2:03 PM, Maurizio Cimadamore  wrote:
> >
> >
> > On 18/06/2021 20:55, Paul Sandoz wrote:
> >> The order declared in the vector load/store overrides any order declared on the buffer (should make the specification clearer in that respect). (In this case in the source is bytes, so there is no swapping).
> > Doh - right!
> >>
> >> ?
> >>
> >> There is something odd going on when tiered compilation is switched off, the result for copyWithVector is much worse for smaller sizes.
> >
> > Is this what Uwe is seeing I wonder?
> >
> > https://github.com/apache/lucene/pull/177#issuecomment-861265227
> >
> 
> Possibly.
> 
> 
> >>
> >> With larger sizes with and without tiered, similar result are observed with similar generated code (of less quality than with tiered for smaller sizes, oddly enough).
> >>
> >> Whether tiered is enabled or not there is no loop unrolling.
> >>
> >> I think something may have regressed, although we have previously focused more on array access than buffer access.
> > Is the vector implementation performing a bulk copy into a byte array IIRC? If so, maybe there's an issue with bulk copy - which would be the same issue we're seeing on the memory access front?
> 
> 
> No, the intrinsic byte vector access to a byte buffer works similarly to intrinsic byte vector access to a byte array, using the buffer?s base and offset (to calculate the address relative to the base).
> 
> Paul.


From mcimadamore at openjdk.java.net  Mon Jun 21 20:48:41 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 21 Jun 2021 20:48:41 GMT
Subject: [foreign-memaccess+abi] RFR: Add support for high-level functions
 to copy to and from Java arrays [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 21 Jun 2021 18:15:58 GMT, Uwe Schindler  wrote:

> Performance is much better, but not yet ideal!
> 
> Maybe you should really think about implementing all those copy methods between arrays and segments without slicing and ideally also without wrapped segments.
> 
> Wouldn't it be so complicated to just implement all the MemoryCopy methods like that?

As you say, it is fairly easy to re-implement the various methods using unsafe directly. It does create a bit of a problem in terms of API stacking, in the sense that the `MemorySegment::copyFrom` method, while in principle is a "primitive" in reality cannot act like one because of performance-related concerns. But perhaps this is just a transient concern: eventually we'll get primitive classes and we'll be able to avoid allocation w/o having to rely on escape analysis.

I'll work to re-implement the various methods tomorrow.

-------------

PR: https://git.openjdk.java.net/panama-foreign/pull/555

From mcimadamore at openjdk.java.net  Mon Jun 21 20:48:43 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 21 Jun 2021 20:48:43 GMT
Subject: [foreign-memaccess+abi] RFR: Add support for high-level functions
 to copy to and from Java arrays [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 21 Jun 2021 17:39:47 GMT, Jorn Vernee  wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove alignment constraints from MemoryCopy layouts
>
> src/hotspot/share/oops/methodData.cpp line 1598:
> 
>> 1596:         return true;
>> 1597:       }
>> 1598:     }
> 
> Tbh, I'm a little skeptical about (the need for) adding argument type profiling at this point:
> - Only the first 2 arguments to a method are profiled by default (controlled by `TypeProfileArgsLimit`) and if we care about the MemorySegment args, there will be no profiling of those for the `copyFromArray` methods.
> - AFAICS, `Unsafe::copyMemory` is far less susceptible to changes in the type of the base pointers, which IIRC was the main reason why we added type profiling in the past for the MemoryAccess.* methods. The C2 intrinsic for copyMemory just always generates an out of line call with memory barriers [1].
> 
> [1] : https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/library_call.cpp#L4071-L4118

Ok, I can revert that - IMHO, the fact that a memory barrier is always added is a peformance issue that should be addressed, as that would impact things like liveness checks - but we can get there when we get there.

> src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemoryCopy.java line 40:
> 
>> 38:  * 

>> 39:  * Copy operations defined in this class accept a byte order parameter. If the specified byte order is different
>> 40:  * from the native byte order, a byte swap operation is performed on each array elements
> 
> This seems somewhat roundabout. Why not accept a `boolean swap` instead?

That seems consistent with MemoryAccess, to be honest. And with every other access operation which touches segments in the API.

> src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemorySegment.java line 405:
> 
>> 403:      * @param src the source segment.
>> 404:      * @param srcElementLayout the element layout associated with the source segment.
>> 405:      * @throws IndexOutOfBoundsException if {@code src.byteSize() > this.byteSize()}.
> 
> Maybe this should be strengthened to require both segments to be the same size? (Otherwise I guess there's quickly a question of 'why can't I specify a destination offset here').

For now, that is consistent with what the other `MemorySegment::copyFrom` does.

> test/jdk/java/foreign/TestMemoryCopy.java line 49:
> 
>> 47:  * These tests exercise the MemoryCopy copyFromArray(...) and copyToArray(...).
>> 48:  * To make these tests more challenging the segment is a view of the given array,
>> 49:  * which makes the copy operations overlapping self-copies.  Thus, this checks the claim:
> 
> I'm not sure I understand this claim; it seems to me that the test sets up an array view segment, but then copies the contents into a new array (using toArray) as src/dst to do the actual copying? i.e. the source and destination seem disjoint.

This comment was in the original patch - I'll fix or drop it.

-------------

PR: https://git.openjdk.java.net/panama-foreign/pull/555

From maurizio.cimadamore at oracle.com  Mon Jun 21 20:56:36 2021
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 21 Jun 2021 21:56:36 +0100
Subject: Foreign + Vectors - benchmarks for copying and swapping
In-Reply-To: <086778CB-EAC3-4A72-A7B5-E5D70522386F@oracle.com>
References: 
 
 <5290e44a-7c67-6ee6-57dc-9af646604082@oracle.com>
 
 <1a23ee05-f187-e6d8-900e-62e77cd73dc9@oracle.com>
 <0DE3B831-2C2C-475B-94FC-867039D6AFC4@oracle.com>
 <07ccd69f-d218-15da-1b71-7dcaa767a7be@oracle.com>
 <9989FFC5-6D13-4114-B32D-A08D427925D4@oracle.com>
 
 
 <086778CB-EAC3-4A72-A7B5-E5D70522386F@oracle.com>
Message-ID: <20caf67a-7a73-426b-d1be-39945757c4dc@oracle.com>


On 21/06/2021 20:33, Paul Sandoz wrote:
> - Segment scalar access is penalized compared to ByteBuffer (from allocate or allocateDirect) scalar access.

Odd

We have many benchmarks similar to this (see LoopOverNonConstant) and 
they seem to offer same level of performance compared with ByteBuffers.

I wonder if the loop limit being "SPECIES.loopBound(srcArray.length)" 
plays a role? Have you tried replacing that expression with a constant?

Maurizio


From paul.sandoz at oracle.com  Mon Jun 21 21:25:08 2021
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 21 Jun 2021 21:25:08 +0000
Subject: Foreign + Vectors - benchmarks for copying and swapping
In-Reply-To: <20caf67a-7a73-426b-d1be-39945757c4dc@oracle.com>
References: 
 
 <5290e44a-7c67-6ee6-57dc-9af646604082@oracle.com>
 
 <1a23ee05-f187-e6d8-900e-62e77cd73dc9@oracle.com>
 <0DE3B831-2C2C-475B-94FC-867039D6AFC4@oracle.com>
 <07ccd69f-d218-15da-1b71-7dcaa767a7be@oracle.com>
 <9989FFC5-6D13-4114-B32D-A08D427925D4@oracle.com>
 
 
 <086778CB-EAC3-4A72-A7B5-E5D70522386F@oracle.com>
 <20caf67a-7a73-426b-d1be-39945757c4dc@oracle.com>
Message-ID: 

Replacing the upper bound in `segmentImplicitScalar` with a constant (1024 say) results in a similar time to `bufferNativeScalar` without a constant bound, both of which (alas) are still slower that scalar array access (which benefits greatly from auto-vectorization).

I wonder if the segment subrange checking for int value ranges is having an impact on bounds checking?

Paul.

> On Jun 21, 2021, at 1:56 PM, Maurizio Cimadamore  wrote:
> 
> 
> On 21/06/2021 20:33, Paul Sandoz wrote:
>> - Segment scalar access is penalized compared to ByteBuffer (from allocate or allocateDirect) scalar access.
> 
> Odd
> 
> We have many benchmarks similar to this (see LoopOverNonConstant) and they seem to offer same level of performance compared with ByteBuffers.
> 
> I wonder if the loop limit being "SPECIES.loopBound(srcArray.length)" plays a role? Have you tried replacing that expression with a constant?
> 
> Maurizio
> 


From github.com+12941506+leerho at openjdk.java.net  Mon Jun 21 22:15:39 2021
From: github.com+12941506+leerho at openjdk.java.net (Lee Rhodes)
Date: Mon, 21 Jun 2021 22:15:39 GMT
Subject: [foreign-memaccess+abi] RFR: Add support for high-level functions
 to copy to and from Java arrays [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 21 Jun 2021 16:54:26 GMT, Jorn Vernee  wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove alignment constraints from MemoryCopy layouts
>
> src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemoryCopy.java line 137:
> 
>> 135:         MemorySegment srcSegmentSlice =
>> 136:                 MemorySegment.ofArray(srcArray).asSlice(srcIndexChars * 2L, srcCopyLengthChars * 2L);
>> 137:         MemorySegment dstSegmentSlice = dstSegment.asSlice(dstOffsetBytes, srcCopyLengthChars * 2L);
> 
> Little weird to see `srcCopyLengthChars` being used for the destination slice. But the length is the same for both of course. Maybe just drop the `src` prefix? (it's a nit though).

The variable name `srcCopyLengthChars` is for clarity to the user of the API, who does not see the implementation code. Because there are two different types of units in the method call, one in Chars and one in Bytes, it is important to clarify the units of the measure as well as which of source or destination it is associated with.

-------------

PR: https://git.openjdk.java.net/panama-foreign/pull/555

From github.com+12941506+leerho at openjdk.java.net  Mon Jun 21 22:15:40 2021
From: github.com+12941506+leerho at openjdk.java.net (Lee Rhodes)
Date: Mon, 21 Jun 2021 22:15:40 GMT
Subject: [foreign-memaccess+abi] RFR: Add support for high-level functions
 to copy to and from Java arrays [v2]
In-Reply-To: 
References: 
 
 
 
Message-ID: <10cvYVltDoxt70qJCjJr17EotPPGBY8Wiytk6GFV2Gk=.3a027fcb-b851-4b97-afa9-91d964d6b848@github.com>

On Mon, 21 Jun 2021 20:42:40 GMT, Maurizio Cimadamore  wrote:

>> test/jdk/java/foreign/TestMemoryCopy.java line 49:
>> 
>>> 47:  * These tests exercise the MemoryCopy copyFromArray(...) and copyToArray(...).
>>> 48:  * To make these tests more challenging the segment is a view of the given array,
>>> 49:  * which makes the copy operations overlapping self-copies.  Thus, this checks the claim:
>> 
>> I'm not sure I understand this claim; it seems to me that the test sets up an array view segment, but then copies the contents into a new array (using toArray) as src/dst to do the actual copying? i.e. the source and destination seem disjoint.
>
> This comment was in the original patch - I'll fix or drop it.

I think what you are seeing the extra copy is in the creation of the `truthSegment`, where an extra copy had to be used because there is no API (yet), to help the code determine which direction the copy should be performed in a self-copy scenario.  If the call to the MemoryCopy API does not perform the self-copy correctly, comparing its result with the `truthSegment` will definitely reveal an error.

-------------

PR: https://git.openjdk.java.net/panama-foreign/pull/555

From uschindler at openjdk.java.net  Mon Jun 21 22:43:37 2021
From: uschindler at openjdk.java.net (Uwe Schindler)
Date: Mon, 21 Jun 2021 22:43:37 GMT
Subject: [foreign-memaccess+abi] RFR: Add support for high-level functions
 to copy to and from Java arrays [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 21 Jun 2021 15:38:35 GMT, Maurizio Cimadamore  wrote:

>> This patch includes some of the changes from Lee to support a set of static functions to allow bulk copy from Java arrays to segments (and viceversa) in a more succint fashion (so that the user doesn't have to create a temporary heap segment to do the copy).
>> 
>> I've added a new public method to `MemorySegment` which performs an *element-wise* bulk copy; it takes a source segment and a couple of element layouts: the source element layout and the destination element layout. The two layouts must have same size, but can have different alignments (which will be checked against the corresponding segments) and byte orders. If the byte order differs, a bulk copy with swap will be performed. As such, this method generalizes the previous `copyFrom` - as follows:
>> 
>> 
>> copyFrom(srcSegment) -> copyFrom(JAVA_BYTE, srcSegment, JAVA_BYTE)
>> 
>> I've added support for argument type profiling for MemoryCopy static methods to avoid type pollution in cases where same metod is called with different memory segment types.
>> 
>> I've done a pass over the javadoc, and make it more consistent with the rest of the API. I've also reworked the test a bit to use the data provider functionality of TestNG, since all the test cases were similar, except for the carrier type.
>> 
>> There are other cosmetic changes as well, compared to original code from Lee, such as naming of static fields which is now capitalized. Everything else is the same.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove alignment constraints from MemoryCopy layouts

I ran the benchmark on this pull request again (non-tiered batch compilation). Here is the output of PrintCompilation, grepped on `MemorySegmentIndexInput`, our impl. As you see our `readBytes()` and `readLongs()` (both calling `MemoryCopy#copyToArray()`) appears:

thetaphi at serv1:~/benchmark/util$ fgrep MemorySegmentIndexInput ../logs/baseline_vs_patch.my_modified_version.0.stdout
   3010  824   !b        org.apache.lucene.store.MemorySegmentIndexInput::readByte (130 bytes)
   3035  845    b        org.apache.lucene.store.MemorySegmentIndexInput::length (5 bytes)
   6117 1414   !b        org.apache.lucene.store.MemorySegmentIndexInput$SingleSegmentImpl::readByte (28 bytes)
   6182 1453   !b        org.apache.lucene.store.MemorySegmentIndexInput::readBytes (50 bytes)
   6281 1489   !b        org.apache.lucene.store.MemorySegmentIndexInput::readLongs (57 bytes)
   6596 1570   !b        org.apache.lucene.store.MemorySegmentIndexInput$SingleSegmentImpl::readShort (28 bytes)
   6694 1588    b        org.apache.lucene.store.MemorySegmentIndexInput::ensureOpen (13 bytes)
   6966 1622   !b        org.apache.lucene.store.MemorySegmentIndexInput$SingleSegmentImpl::seek (31 bytes)
   6975 1627    b        org.apache.lucene.store.MemorySegmentIndexInput$SingleSegmentImpl::getFilePointer (9 bytes)
  11819 2091    b        org.apache.lucene.store.MemorySegmentIndexInput$SingleSegmentImpl:: (26 bytes)
  11823 2092    b        org.apache.lucene.store.MemorySegmentIndexInput:: (103 bytes)
  11883 2095    b        org.apache.lucene.store.MemorySegmentIndexInput::buildSlice (154 bytes)
  12122 2120   !b        org.apache.lucene.store.MemorySegmentIndexInput::readLong (42 bytes)
  15710 2204    b        org.apache.lucene.store.MemorySegmentIndexInput$SingleSegmentImpl::slice (9 bytes)
  15711 2205    b        org.apache.lucene.store.MemorySegmentIndexInput::slice (56 bytes)
  15731 2219   !b        org.apache.lucene.store.MemorySegmentIndexInput::clone (37 bytes)
  16198 2242    b        org.apache.lucene.store.MemorySegmentIndexInput$SingleSegmentImpl::clone (5 bytes)


MemoryCopy is also compiled:


thetaphi at serv1:~/benchmark/util$ fgrep MemoryCopy ../logs/baseline_vs_patch.my_modified_version.0.stdout
   6187 1454    b        jdk.incubator.foreign.MemoryCopy::copyToArray (44 bytes)
   6286 1490    b        jdk.incubator.foreign.MemoryCopy::copyToArray (76 bytes)


Not sure why escape analysis does not work. Seems to be a bug or it is again the SMALL segments.

-------------

PR: https://git.openjdk.java.net/panama-foreign/pull/555

From uschindler at openjdk.java.net  Mon Jun 21 22:56:37 2021
From: uschindler at openjdk.java.net (Uwe Schindler)
Date: Mon, 21 Jun 2021 22:56:37 GMT
Subject: [foreign-memaccess+abi] RFR: Add support for high-level functions
 to copy to and from Java arrays [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 21 Jun 2021 15:38:35 GMT, Maurizio Cimadamore  wrote:

>> This patch includes some of the changes from Lee to support a set of static functions to allow bulk copy from Java arrays to segments (and viceversa) in a more succint fashion (so that the user doesn't have to create a temporary heap segment to do the copy).
>> 
>> I've added a new public method to `MemorySegment` which performs an *element-wise* bulk copy; it takes a source segment and a couple of element layouts: the source element layout and the destination element layout. The two layouts must have same size, but can have different alignments (which will be checked against the corresponding segments) and byte orders. If the byte order differs, a bulk copy with swap will be performed. As such, this method generalizes the previous `copyFrom` - as follows:
>> 
>> 
>> copyFrom(srcSegment) -> copyFrom(JAVA_BYTE, srcSegment, JAVA_BYTE)
>> 
>> I've added support for argument type profiling for MemoryCopy static methods to avoid type pollution in cases where same metod is called with different memory segment types.
>> 
>> I've done a pass over the javadoc, and make it more consistent with the rest of the API. I've also reworked the test a bit to use the data provider functionality of TestNG, since all the test cases were similar, except for the carrier type.
>> 
>> There are other cosmetic changes as well, compared to original code from Lee, such as naming of static fields which is now capitalized. Everything else is the same.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove alignment constraints from MemoryCopy layouts

With tiered compilation (all defaults):


thetaphi at serv1:~/benchmark/util$ egrep '(MemorySegmentIndexInput::readBytes|MemorySegmentIndexInput::readLongs|MemoryCopy)' ../logs/
baseline_vs_patch.my_modified_version.0.stdout
    575 2580   !   3       org.apache.lucene.store.MemorySegmentIndexInput::readBytes (50 bytes)
    575 2581       3       jdk.incubator.foreign.MemoryCopy::copyToArray (44 bytes)
   1132 4188   !   3       org.apache.lucene.store.MemorySegmentIndexInput::readLongs (57 bytes)
   1132 4193       3       jdk.incubator.foreign.MemoryCopy::copyToArray (76 bytes)
   1200 4316   !   4       org.apache.lucene.store.MemorySegmentIndexInput::readBytes (50 bytes)
   1209 2580   !   3       org.apache.lucene.store.MemorySegmentIndexInput::readBytes (50 bytes)   made not entrant
   1209 4343   !   4       org.apache.lucene.store.MemorySegmentIndexInput::readLongs (57 bytes)
   1220 4188   !   3       org.apache.lucene.store.MemorySegmentIndexInput::readLongs (57 bytes)   made not entrant
   3324 2580   !   3       org.apache.lucene.store.MemorySegmentIndexInput::readBytes (50 bytes)   made zombie
   3328 4188   !   3       org.apache.lucene.store.MemorySegmentIndexInput::readLongs (57 bytes)   made zombie

-------------

PR: https://git.openjdk.java.net/panama-foreign/pull/555

From mail at smogura.eu  Mon Jun 21 23:28:41 2021
From: mail at smogura.eu (=?iso-8859-2?Q?Rados=B3aw_Smogura?=)
Date: Mon, 21 Jun 2021 23:28:41 +0000
Subject: ODP: Foreign + Vectors - benchmarks for copying and swapping
In-Reply-To: 
References: 
 
 <5290e44a-7c67-6ee6-57dc-9af646604082@oracle.com>
 
 <1a23ee05-f187-e6d8-900e-62e77cd73dc9@oracle.com>
 <0DE3B831-2C2C-475B-94FC-867039D6AFC4@oracle.com>
 <07ccd69f-d218-15da-1b71-7dcaa767a7be@oracle.com>
 <9989FFC5-6D13-4114-B32D-A08D427925D4@oracle.com>
 
 
 <086778CB-EAC3-4A72-A7B5-E5D70522386F@oracle.com>
 <20caf67a-7a73-426b-d1be-39945757c4dc@oracle.com>,
 
Message-ID: 

Hi,

I think why the copy case may fail with unrolling, because

  *   loop unroll takes the range check from intoByteBuffer as the loop exit condition
  *   the range check uses unsigned compare, which is not supported by loop unroll

I think in this code
        for (int i = 0; i < bound; i += lanes) {
          final var srcVector = ByteVector
              .fromByteBuffer(BYTE_VECTOR_SPECIES, src, i, ByteOrder.nativeOrder());

          srcVector.intoByteBuffer(dst, i, ByteOrder.nativeOrder());
        }
exit condition should be i < bound, not a range check from intoByteBuffer.

Kind regards,
Rado

________________________________
Od: Paul Sandoz 
Wys?ane: poniedzia?ek, 21 czerwca 2021 23:25
Do: Maurizio Cimadamore 
DW: Rados?aw Smogura ; Vladimir Ivanov ; panama-dev at openjdk.java.net 
Temat: Re: Foreign + Vectors - benchmarks for copying and swapping

Replacing the upper bound in `segmentImplicitScalar` with a constant (1024 say) results in a similar time to `bufferNativeScalar` without a constant bound, both of which (alas) are still slower that scalar array access (which benefits greatly from auto-vectorization).

I wonder if the segment subrange checking for int value ranges is having an impact on bounds checking?

Paul.

> On Jun 21, 2021, at 1:56 PM, Maurizio Cimadamore  wrote:
>
>
> On 21/06/2021 20:33, Paul Sandoz wrote:
>> - Segment scalar access is penalized compared to ByteBuffer (from allocate or allocateDirect) scalar access.
>
> Odd
>
> We have many benchmarks similar to this (see LoopOverNonConstant) and they seem to offer same level of performance compared with ByteBuffers.
>
> I wonder if the loop limit being "SPECIES.loopBound(srcArray.length)" plays a role? Have you tried replacing that expression with a constant?
>
> Maurizio
>


From mail at smogura.eu  Tue Jun 22 00:04:24 2021
From: mail at smogura.eu (=?iso-8859-2?Q?Rados=B3aw_Smogura?=)
Date: Tue, 22 Jun 2021 00:04:24 +0000
Subject: ODP: Foreign + Vectors - benchmarks for copying and swapping
In-Reply-To: 
References: 
 
 <5290e44a-7c67-6ee6-57dc-9af646604082@oracle.com>
 
 <1a23ee05-f187-e6d8-900e-62e77cd73dc9@oracle.com>
 <0DE3B831-2C2C-475B-94FC-867039D6AFC4@oracle.com>
 <07ccd69f-d218-15da-1b71-7dcaa767a7be@oracle.com>
 <9989FFC5-6D13-4114-B32D-A08D427925D4@oracle.com>
 
 
 <086778CB-EAC3-4A72-A7B5-E5D70522386F@oracle.com>
 <20caf67a-7a73-426b-d1be-39945757c4dc@oracle.com>,
 ,
 
Message-ID: 

Hi,

And small clarification, I made this check on the version with  mem barriers removed from the code, so the one I sent before.

However, even with range checks disabled i could not unroll.

Kind regards,
Rado
________________________________
Od: panama-dev  w imieniu u?ytkownika Rados?aw Smogura 
Wys?ane: wtorek, 22 czerwca 2021 01:28
Do: Paul Sandoz ; Maurizio Cimadamore 
DW: Vladimir Ivanov ; panama-dev at openjdk.java.net 
Temat: ODP: Foreign + Vectors - benchmarks for copying and swapping

Hi,

I think why the copy case may fail with unrolling, because

  *   loop unroll takes the range check from intoByteBuffer as the loop exit condition
  *   the range check uses unsigned compare, which is not supported by loop unroll

I think in this code
        for (int i = 0; i < bound; i += lanes) {
          final var srcVector = ByteVector
              .fromByteBuffer(BYTE_VECTOR_SPECIES, src, i, ByteOrder.nativeOrder());

          srcVector.intoByteBuffer(dst, i, ByteOrder.nativeOrder());
        }
exit condition should be i < bound, not a range check from intoByteBuffer.

Kind regards,
Rado

________________________________
Od: Paul Sandoz 
Wys?ane: poniedzia?ek, 21 czerwca 2021 23:25
Do: Maurizio Cimadamore 
DW: Rados?aw Smogura ; Vladimir Ivanov ; panama-dev at openjdk.java.net 
Temat: Re: Foreign + Vectors - benchmarks for copying and swapping

Replacing the upper bound in `segmentImplicitScalar` with a constant (1024 say) results in a similar time to `bufferNativeScalar` without a constant bound, both of which (alas) are still slower that scalar array access (which benefits greatly from auto-vectorization).

I wonder if the segment subrange checking for int value ranges is having an impact on bounds checking?

Paul.

> On Jun 21, 2021, at 1:56 PM, Maurizio Cimadamore  wrote:
>
>
> On 21/06/2021 20:33, Paul Sandoz wrote:
>> - Segment scalar access is penalized compared to ByteBuffer (from allocate or allocateDirect) scalar access.
>
> Odd
>
> We have many benchmarks similar to this (see LoopOverNonConstant) and they seem to offer same level of performance compared with ByteBuffers.
>
> I wonder if the loop limit being "SPECIES.loopBound(srcArray.length)" plays a role? Have you tried replacing that expression with a constant?
>
> Maurizio
>


From paul.sandoz at oracle.com  Tue Jun 22 00:35:38 2021
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 22 Jun 2021 00:35:38 +0000
Subject: Foreign + Vectors - benchmarks for copying and swapping
In-Reply-To: 
References: 
 
 <5290e44a-7c67-6ee6-57dc-9af646604082@oracle.com>
 
 <1a23ee05-f187-e6d8-900e-62e77cd73dc9@oracle.com>
 <0DE3B831-2C2C-475B-94FC-867039D6AFC4@oracle.com>
 <07ccd69f-d218-15da-1b71-7dcaa767a7be@oracle.com>
 <9989FFC5-6D13-4114-B32D-A08D427925D4@oracle.com>
 
 
 <086778CB-EAC3-4A72-A7B5-E5D70522386F@oracle.com>
 <20caf67a-7a73-426b-d1be-39945757c4dc@oracle.com>
 
Message-ID: 

AFAICT the generated code for `segmentImplicitScalar` with and without a constant bound is similar. In both cases there is a core loop that is efficiently unrolled 32x but not vectorized. 

However, perfasm shows that with the non-constant upper bound, most of the time is being spent in the inner post loop, implying there might be a bug in C2?s strip mining code gen.

Paul.

> On Jun 21, 2021, at 2:25 PM, Paul Sandoz  wrote:
> 
> Replacing the upper bound in `segmentImplicitScalar` with a constant (1024 say) results in a similar time to `bufferNativeScalar` without a constant bound, both of which (alas) are still slower that scalar array access (which benefits greatly from auto-vectorization).
> 
> I wonder if the segment subrange checking for int value ranges is having an impact on bounds checking?
> 
> Paul.
> 
>> On Jun 21, 2021, at 1:56 PM, Maurizio Cimadamore  wrote:
>> 
>> 
>> On 21/06/2021 20:33, Paul Sandoz wrote:
>>> - Segment scalar access is penalized compared to ByteBuffer (from allocate or allocateDirect) scalar access.
>> 
>> Odd
>> 
>> We have many benchmarks similar to this (see LoopOverNonConstant) and they seem to offer same level of performance compared with ByteBuffers.
>> 
>> I wonder if the loop limit being "SPECIES.loopBound(srcArray.length)" plays a role? Have you tried replacing that expression with a constant?
>> 
>> Maurizio
>> 
> 


From david.holmes at oracle.com  Tue Jun 22 01:11:48 2021
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 22 Jun 2021 11:11:48 +1000
Subject: Gihub Action, CI pipeline
In-Reply-To: 
References: 
 <3bc9f966-00bd-5280-3fab-53784480ba66@oracle.com>
 
 
Message-ID: 

On 22/06/2021 12:22 am, Giuseppe Barbieri wrote:
> Hi,
> 
> 
> Erik replied that it's up to the people/devs working on panama to decide
> whether to use Github Actions or not
> 
> https://mail.openjdk.java.net/pipermail/build-dev/2021-June/031568.html

I think you misunderstood what Erik was saying. OpenJDK projects do not 
publish binaries via github actions - period.

OpenJDK projects may choose to use Github actions for pre-integration 
testing.

Cheers,
David

> So, in case you guys are interested, I fixed the linux64 and macos64
> builds: now the clang llvm 12.0 binaries will be downloaded (and cached)
> 
> https://github.com/elect86/panama-foreign/actions/runs/956676104
> 
> I'm publishing everything, every kind of builds plus all the test results
> and supports
> 
> https://github.com/elect86/panama-foreign/releases
> 
> Right now there is an additional workflow which check every 10m if there
> are any new commits upstream, but this of course won't be needed if the
> whole gets merged
> 
> There is just some minor polishing left regarding the release text to do,
> but this is minor stuff
> 
> 
> Giuseppe
> 
> Il giorno mar 15 giu 2021 alle ore 22:26 Giuseppe Barbieri <
> elect86 at gmail.com> ha scritto:
> 
>> This is not possible - we do not publish builds using GitHub actions.
>>> This is not a panama decision, but a JDK-wide one.
>>>
>>> If you want to discuss that I'd suggest to redirect your question to a
>>> more general forum like jdk-dev or build-dev.
>>>
>>
>> Ok, I'll propose maybe something over there then
>>
>> I believe this has been fixed upstream - butt there were merge issues
>>> which we have rectified today. So perhaps it should be ok now?
>>>
>>> Maurizio
>>>
>>
>> Yes, it's, thanks
>>
>> Giuseppe
>>

From jvernee at openjdk.java.net  Tue Jun 22 02:34:35 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Tue, 22 Jun 2021 02:34:35 GMT
Subject: [foreign-memaccess+abi] RFR: Add support for high-level functions
 to copy to and from Java arrays [v2]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Mon, 21 Jun 2021 20:44:44 GMT, Maurizio Cimadamore  wrote:

>> src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemoryCopy.java line 40:
>> 
>>> 38:  * 

>>> 39:  * Copy operations defined in this class accept a byte order parameter. If the specified byte order is different
>>> 40:  * from the native byte order, a byte swap operation is performed on each array elements
>> 
>> This seems somewhat roundabout. Why not accept a `boolean swap` instead?
>
> That seems consistent with MemoryAccess, to be honest. And with every other access operation which touches segments in the API.

True. Ok, that actually makes sense now that I compare it with what memaccess var handles do. i.e. the byte order always corresponds to the memory segment, since the array is of course in native order. So, in practice this means a swap occurs when the specified or is non-native. Thanks.

>> src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemorySegment.java line 405:
>> 
>>> 403:      * @param src the source segment.
>>> 404:      * @param srcElementLayout the element layout associated with the source segment.
>>> 405:      * @throws IndexOutOfBoundsException if {@code src.byteSize() > this.byteSize()}.
>> 
>> Maybe this should be strengthened to require both segments to be the same size? (Otherwise I guess there's quickly a question of 'why can't I specify a destination offset here').
>
> For now, that is consistent with what the other `MemorySegment::copyFrom` does.

Ok, makes sense.

-------------

PR: https://git.openjdk.java.net/panama-foreign/pull/555

From jvernee at openjdk.java.net  Tue Jun 22 02:39:36 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Tue, 22 Jun 2021 02:39:36 GMT
Subject: [foreign-memaccess+abi] RFR: Add support for high-level functions
 to copy to and from Java arrays [v2]
In-Reply-To: <10cvYVltDoxt70qJCjJr17EotPPGBY8Wiytk6GFV2Gk=.3a027fcb-b851-4b97-afa9-91d964d6b848@github.com>
References: 
 
 
 
 <10cvYVltDoxt70qJCjJr17EotPPGBY8Wiytk6GFV2Gk=.3a027fcb-b851-4b97-afa9-91d964d6b848@github.com>
Message-ID: <4bYiuoYZ-y77NBW0oVjeuiFRpuPe8vbPbOvnC7uNpDU=.3a994259-bee5-4701-aa8c-3850677515d2@github.com>

On Mon, 21 Jun 2021 22:10:32 GMT, Lee Rhodes  wrote:

>> This comment was in the original patch - I'll fix or drop it.
>
> I think what you are seeing the extra copy is in the creation of the `truthSegment`, where an extra copy had to be used because there is no API (yet), to help the code determine which direction the copy should be performed in a self-copy scenario.  If the call to the MemoryCopy API does not perform the self-copy correctly, comparing its result with the `truthSegment` will definitely reveal an error.

Actually, I'm talking about the call to toArray here (as well as for CopyTo): 


ByteOrder bo = mode.swap ? NON_NATIVE_ORDER : NATIVE_ORDER;
//CopyFrom
Object srcArr = helper.toArray(base); // <---------------------
int srcIndex = mode.direction ? 0 : indexShifts;
int srcCopyLen = helper.length(srcArr) - indexShifts;


This call to `toArray` ends of calling one of the `MemorySegment::to*Array` methods, which always copy the contents of the segment.

-------------

PR: https://git.openjdk.java.net/panama-foreign/pull/555

From uschindler at openjdk.java.net  Tue Jun 22 07:36:59 2021
From: uschindler at openjdk.java.net (Uwe Schindler)
Date: Tue, 22 Jun 2021 07:36:59 GMT
Subject: [foreign-memaccess+abi] RFR: Add support for high-level functions
 to copy to and from Java arrays [v2]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Mon, 21 Jun 2021 20:40:05 GMT, Maurizio Cimadamore  wrote:

>> With this variant, profile looks like this:
>> 
>> PROFILE SUMMARY from 316771 events (total: 112007M)
>>   tests.profile.mode=heap
>>   tests.profile.count=30
>>   tests.profile.stacksize=1
>>   tests.profile.linenumbers=false
>> PERCENT       HEAP SAMPLES  STACK
>> 72.60%        81319M        jdk.internal.foreign.HeapMemorySegmentImpl$OfByte#fromArray()
>> 4.23%         4738M         org.apache.lucene.util.FixedBitSet#()
>> 3.14%         3516M         org.apache.lucene.search.ExactPhraseMatcher$1$1#getImpacts()
>> 2.77%         3105M         org.apache.lucene.search.ExactPhraseMatcher$1#getImpacts()
>> 
>> 
>> Performance is much better, but not yet ideal!
>> 
>> Maybe you should really think about implementing all those copy methods between arrays and segments without slicing and ideally also without wrapped segments.
>> 
>> Wouldn't it be so complicated to just implement all the MemoryCopy methods like that?
>
>> Performance is much better, but not yet ideal!
>> 
>> Maybe you should really think about implementing all those copy methods between arrays and segments without slicing and ideally also without wrapped segments.
>> 
>> Wouldn't it be so complicated to just implement all the MemoryCopy methods like that?
> 
> As you say, it is fairly easy to re-implement the various methods using unsafe directly. It does create a bit of a problem in terms of API stacking, in the sense that the `MemorySegment::copyFrom` method, while in principle is a "primitive" in reality cannot act like one because of performance-related concerns. But perhaps this is just a transient concern: eventually we'll get primitive classes and we'll be able to avoid allocation w/o having to rely on escape analysis.
> 
> I'll work to re-implement the various methods tomorrow.

Hi @mcimadamore, 

I was thinking about that last night ant I think I know what the issue and why it affects Lucene: As you remember, I mentioned that without tiered compilation and batch compilation enabled (the default for our benchmark to get more predictable result), the garbage produced and its collection is horrible. These are the first results above. As you see the copy methods are optimized only after 6 seconds. The total runtime of the benchmark was 73 seconds (50 seconds with our old code). So it looks like for the first 6 seconds the benchmark is hammering with many parallel queries the lucene index, creating incredible amounts of garbage (3 object instances for each memory copy), until the compilation kicks in. This is completely new to lucene, because the very low level code is carefully written to not produce any object instances, because from our experience, escape analysis kicks in way too late. The readBytes() method is not called in a loop, but it is still called quite often in a very
  complex code path making it hard for the optimizer to kick in. What happens now: In our benchmark, we use many threads to execute fulltext queries and without the optimization kicking in, it creates millions of objects and those have to be garbage collected. Due to the high load (many threads and expensive low level query execution), GC has less CPU resources and then fails to kick in early enough and wastes at end like 23 seconds extra in cleaning up the useless garbage, possibly with stop-the-world phases.

With tiered compilation enabled, the compilation kicks in much earlier (after half a second already for C1) and after 1.2 seconds for C2.  This avoids a lot of garbage, (about 1/6s also in the output at end). The total runtime of the benchmark goes down from 73 seconds to approx 55 seconds). So garbage collector does not go crazy, but we still see a slowdown.

IMHO, inside Panama internals you should not rely on escape analysis to kick in early enough and implement stuff like copy methods without producing too much garbage by default.

> It does create a bit of a problem in terms of API stacking, in the sense that the MemorySegment::copyFrom method, while in principle is a "primitive" in reality cannot act like one because of performance-related concerns. 

Maybe document in the API of MemoryCopy, that those methods behave like the slicing code, but are much more efficient.

But I agree you should really work on letting the escape analysis kick in earlier, especially if code is not used in loops (like memory copy).

Thanks,
Uwe

-------------

PR: https://git.openjdk.java.net/panama-foreign/pull/555

From jbhateja at openjdk.java.net  Tue Jun 22 09:41:44 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Tue, 22 Jun 2021 09:41:44 GMT
Subject: [vectorIntrinsics+mask] RFR: 8266287: Basic mask IR
 implementation for the Vector API masking feature support [v3]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

On Mon, 21 Jun 2021 03:28:19 GMT, Xiaohong Gong  wrote:

>> VectorBoxNode and VectorUnboxNode are macro nodes and carry the vector type which comply with the species i.e. for IntVector.SPECIES_256, vector type of Box/Unbox should be TypeVect(T_INT,8), both these nodes needs to be expanded as per following expansion rules:- 
>> 
>> a) VectorBox mask(TypeVectMask) ====>   VectorStoreMask + StoreVector.
>> b) VectorUnbox mask =====>  LoadVector  + VectorLoadMask (TypeVectMask)
>> c) VectorUnbox (VectorBox mask) ====> VectorStoreMask(TypeVectMask) + StoreVector + LoadVector + VectorLoadMask(TypeVectMask)
>> 
>> An optimization over VectorUnboxNode should consult the type of VectorBoxNode and vice-versa,  similarly any optimization involving VectorLoadMaskNode should comply with type of VectoStoreMaskNode, there cannot be a mix-match, if there is any such case it needs to be fixed like the following handling
>> https://github.com/openjdk/panama-vector/pull/90#pullrequestreview-679559503
>> 
>> Can you kindly share the tests which failed.
>
> Hi @jatin-bhateja , too much Vector API jtreg tests crashes due to this change. Please see one of the jvm crash log here: http://cr.openjdk.java.net/~xgong/rfr/mask/crashes.
> 
> BTW, I remember @iwanowww said that the vector type should match for `VectorUnbox ` and its `obj ` when I fixed the type mismatching issue for vector mask with floating point type before. Please see the comment here: https://github.com/openjdk/jdk/pull/3238#issuecomment-815036103

Hi @XiaohongGong ,

I made following changes in unbox and box creation routines and did not find any crashes as reposted in any of VectorAPI jtreg over AVX-512 platform.


diff --git a/src/hotspot/share/opto/vectorIntrinsics.cpp b/src/hotspot/share/opto/vectorIntrinsics.cpp
index 21e238afb5b..76553c9f2c9 100644
--- a/src/hotspot/share/opto/vectorIntrinsics.cpp
+++ b/src/hotspot/share/opto/vectorIntrinsics.cpp
@@ -81,7 +81,7 @@ Node* GraphKit::box_vector(Node* vector, const TypeInstPtr* vbox_type, BasicType
   Node* ret = gvn().transform(new ProjNode(alloc, TypeFunc::Parms));

   assert(check_vbox(vbox_type), "");
-  const TypeVect* vt = TypeVect::make(elem_bt, num_elem, is_vector_mask(vbox_type->klass()));
+  const TypeVect* vt = TypeVect::make(elem_bt, num_elem);
   VectorBoxNode* vbox = new VectorBoxNode(C, ret, vector, vbox_type, vt);
   return gvn().transform(vbox);
 }
@@ -96,7 +96,7 @@ Node* GraphKit::unbox_vector(Node* v, const TypeInstPtr* vbox_type, BasicType el
     return NULL; // no nulls are allowed
   }
   assert(check_vbox(vbox_type), "");
-  const TypeVect* vt = TypeVect::make(elem_bt, num_elem, is_vector_mask(vbox_type->klass()));
+  const TypeVect* vt = TypeVect::make(elem_bt, num_elem);
   Node* unbox = gvn().transform(new VectorUnboxNode(C, vt, v, merged_memory(), shuffle_to_vector));
   return unbox;
 }

Can you kindly share a exact re-producer.

-------------

PR: https://git.openjdk.java.net/panama-vector/pull/78

From jbhateja at openjdk.java.net  Tue Jun 22 09:45:46 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Tue, 22 Jun 2021 09:45:46 GMT
Subject: [vectorIntrinsics+mask] RFR: 8266287: Basic mask IR
 implementation for the Vector API masking feature support [v3]
In-Reply-To: 
References: 
 
 
 
 
 
Message-ID: 

On Tue, 22 Jun 2021 09:38:56 GMT, Jatin Bhateja  wrote:

>> Hi @jatin-bhateja , too much Vector API jtreg tests crashes due to this change. Please see one of the jvm crash log here: http://cr.openjdk.java.net/~xgong/rfr/mask/crashes.
>> 
>> BTW, I remember @iwanowww said that the vector type should match for `VectorUnbox ` and its `obj ` when I fixed the type mismatching issue for vector mask with floating point type before. Please see the comment here: https://github.com/openjdk/jdk/pull/3238#issuecomment-815036103
>
> Hi @XiaohongGong ,
> 
> I made following changes in unbox and box creation routines and did not find any crashes as reported in any of VectorAPI jtreg over AVX-512 platform.
> 
> 
> diff --git a/src/hotspot/share/opto/vectorIntrinsics.cpp b/src/hotspot/share/opto/vectorIntrinsics.cpp
> index 21e238afb5b..76553c9f2c9 100644
> --- a/src/hotspot/share/opto/vectorIntrinsics.cpp
> +++ b/src/hotspot/share/opto/vectorIntrinsics.cpp
> @@ -81,7 +81,7 @@ Node* GraphKit::box_vector(Node* vector, const TypeInstPtr* vbox_type, BasicType
>    Node* ret = gvn().transform(new ProjNode(alloc, TypeFunc::Parms));
> 
>    assert(check_vbox(vbox_type), "");
> -  const TypeVect* vt = TypeVect::make(elem_bt, num_elem, is_vector_mask(vbox_type->klass()));
> +  const TypeVect* vt = TypeVect::make(elem_bt, num_elem);
>    VectorBoxNode* vbox = new VectorBoxNode(C, ret, vector, vbox_type, vt);
>    return gvn().transform(vbox);
>  }
> @@ -96,7 +96,7 @@ Node* GraphKit::unbox_vector(Node* v, const TypeInstPtr* vbox_type, BasicType el
>      return NULL; // no nulls are allowed
>    }
>    assert(check_vbox(vbox_type), "");
> -  const TypeVect* vt = TypeVect::make(elem_bt, num_elem, is_vector_mask(vbox_type->klass()));
> +  const TypeVect* vt = TypeVect::make(elem_bt, num_elem);
>    Node* unbox = gvn().transform(new VectorUnboxNode(C, vt, v, merged_memory(), shuffle_to_vector));
>    return unbox;
>  }
> 
> Can you kindly share a exact re-producer.

Box/Unbox are macro nodes which encapsulates value, in this case the mask value is contained either in  a a vector or a predicate register. This should ideally not be disturbing the box's vector type() I think.

-------------

PR: https://git.openjdk.java.net/panama-vector/pull/78

From mcimadamore at openjdk.java.net  Tue Jun 22 10:19:41 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 22 Jun 2021 10:19:41 GMT
Subject: [foreign-memaccess+abi] RFR: Add support for high-level functions
 to copy to and from Java arrays [v2]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Mon, 21 Jun 2021 20:40:05 GMT, Maurizio Cimadamore  wrote:

>> With this variant, profile looks like this:
>> 
>> PROFILE SUMMARY from 316771 events (total: 112007M)
>>   tests.profile.mode=heap
>>   tests.profile.count=30
>>   tests.profile.stacksize=1
>>   tests.profile.linenumbers=false
>> PERCENT       HEAP SAMPLES  STACK
>> 72.60%        81319M        jdk.internal.foreign.HeapMemorySegmentImpl$OfByte#fromArray()
>> 4.23%         4738M         org.apache.lucene.util.FixedBitSet#()
>> 3.14%         3516M         org.apache.lucene.search.ExactPhraseMatcher$1$1#getImpacts()
>> 2.77%         3105M         org.apache.lucene.search.ExactPhraseMatcher$1#getImpacts()
>> 
>> 
>> Performance is much better, but not yet ideal!
>> 
>> Maybe you should really think about implementing all those copy methods between arrays and segments without slicing and ideally also without wrapped segments.
>> 
>> Wouldn't it be so complicated to just implement all the MemoryCopy methods like that?
>
>> Performance is much better, but not yet ideal!
>> 
>> Maybe you should really think about implementing all those copy methods between arrays and segments without slicing and ideally also without wrapped segments.
>> 
>> Wouldn't it be so complicated to just implement all the MemoryCopy methods like that?
> 
> As you say, it is fairly easy to re-implement the various methods using unsafe directly. It does create a bit of a problem in terms of API stacking, in the sense that the `MemorySegment::copyFrom` method, while in principle is a "primitive" in reality cannot act like one because of performance-related concerns. But perhaps this is just a transient concern: eventually we'll get primitive classes and we'll be able to avoid allocation w/o having to rely on escape analysis.
> 
> I'll work to re-implement the various methods tomorrow.

> Hi @mcimadamore,
> 
> I was thinking about that last night ant I think I know what the issue and why it affects Lucene: As you remember, I mentioned that without tiered compilation and batch compilation enabled (the default for our benchmark to get more predictable result), the garbage produced and its collection is horrible. These are the first results above. As you see the copy methods are optimized only after 6 seconds. The total runtime of the benchmark was 73 seconds (50 seconds with our old code). So it looks like for the first 6 seconds the benchmark is hammering with many parallel queries the lucene index, creating incredible amounts of garbage (3 object instances for each memory copy), until the compilation kicks in. This is completely new to lucene, because the very low level code is carefully written to not produce any object instances, because from our experience, escape analysis kicks in way too late. The readBytes() method is not called in a loop, but it is still called quite often in a ve
 ry complex code path making it hard for the optimizer to kick in. What happens now: In our benchmark, we use many threads to execute fulltext queries and without the optimization kicking in, it creates millions of objects and those have to be garbage collected. Due to the high load (many threads and expensive low level query execution), GC has less CPU resources and then fails to kick in early enough and wastes at end like 23 seconds extra in cleaning up the useless garbage, possibly with stop-the-world phases.
> 
> With tiered compilation enabled, the compilation kicks in much earlier (after half a second already for C1) and after 1.2 seconds for C2. This avoids a lot of garbage, (about 1/6s also in the output at end). The total runtime of the benchmark goes down from 73 seconds to approx 55 seconds). So garbage collector does not go crazy, but we still see a slowdown of 10% for some queries, but not 40% slowdown for queries like in the non-tiered case.
> 
> IMHO, inside Panama internals you should not rely on escape analysis to kick in early enough and implement stuff like copy methods without producing too much garbage by default.
> 
> > It does create a bit of a problem in terms of API stacking, in the sense that the MemorySegment::copyFrom method, while in principle is a "primitive" in reality cannot act like one because of performance-related concerns.
> 
> Maybe document in the API of MemoryCopy, that those methods behave like the slicing code, but are much more efficient.
> 
> But I agree you should really work on letting the escape analysis kick in earlier, especially if code is not used in loops (like memory copy).
> 
> Thanks,
> Uwe

I think I agree with the conclusion - code that is doing memory copy will typically not sit inside a loop (although sometimes it might) and will get optimized late. If we rely on compilation/escape analysis to get rid of slicing in such cases we might never get there, or get there after the horses have left the proverbial barn. While I think Lucene is especially sensitive in this direction (I'm not aware of other similar reports), it is a real world scenario, which means we have to readjust our strategy here.

Your results (thanks for spending time in validating the various patch) are pretty clear: there is a direct correlation between the amount of garbage that is generated and the overall throughput of the benchmark (I was mildly afraid we were dealing with _two_ issues here). The solution is relatively straightforward - and maybe at some point in the future Valhalla will help allowing us to express the code in terms of higher-level APIs, w/o sacrificing on the allocation cost.

-------------

PR: https://git.openjdk.java.net/panama-foreign/pull/555

From mcimadamore at openjdk.java.net  Tue Jun 22 11:01:17 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 22 Jun 2021 11:01:17 GMT
Subject: [foreign-memaccess+abi] RFR: Add support for high-level functions
 to copy to and from Java arrays [v3]
In-Reply-To: 
References: 
Message-ID: 

> This patch includes some of the changes from Lee to support a set of static functions to allow bulk copy from Java arrays to segments (and viceversa) in a more succint fashion (so that the user doesn't have to create a temporary heap segment to do the copy).
> 
> I've added a new public method to `MemorySegment` which performs an *element-wise* bulk copy; it takes a source segment and a couple of element layouts: the source element layout and the destination element layout. The two layouts must have same size, but can have different alignments (which will be checked against the corresponding segments) and byte orders. If the byte order differs, a bulk copy with swap will be performed. As such, this method generalizes the previous `copyFrom` - as follows:
> 
> 
> copyFrom(srcSegment) -> copyFrom(JAVA_BYTE, srcSegment, JAVA_BYTE)
> 
> I've added support for argument type profiling for MemoryCopy static methods to avoid type pollution in cases where same metod is called with different memory segment types.
> 
> I've done a pass over the javadoc, and make it more consistent with the rest of the API. I've also reworked the test a bit to use the data provider functionality of TestNG, since all the test cases were similar, except for the carrier type.
> 
> There are other cosmetic changes as well, compared to original code from Lee, such as naming of static fields which is now capitalized. Everything else is the same.

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Use ScopedMemoryAccess directly inside MemoryCopy implementations

-------------

Changes:
  - all: https://git.openjdk.java.net/panama-foreign/pull/555/files
  - new: https://git.openjdk.java.net/panama-foreign/pull/555/files/85a9786a..d8ceea6e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=555&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=555&range=01-02

  Stats: 185 lines in 1 file changed: 122 ins; 0 del; 63 mod
  Patch: https://git.openjdk.java.net/panama-foreign/pull/555.diff
  Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/555/head:pull/555

PR: https://git.openjdk.java.net/panama-foreign/pull/555

From mcimadamore at openjdk.java.net  Tue Jun 22 11:01:19 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 22 Jun 2021 11:01:19 GMT
Subject: [foreign-memaccess+abi] RFR: Add support for high-level functions
 to copy to and from Java arrays [v2]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

On Tue, 22 Jun 2021 07:33:34 GMT, Uwe Schindler  wrote:

>>> Performance is much better, but not yet ideal!
>>> 
>>> Maybe you should really think about implementing all those copy methods between arrays and segments without slicing and ideally also without wrapped segments.
>>> 
>>> Wouldn't it be so complicated to just implement all the MemoryCopy methods like that?
>> 
>> As you say, it is fairly easy to re-implement the various methods using unsafe directly. It does create a bit of a problem in terms of API stacking, in the sense that the `MemorySegment::copyFrom` method, while in principle is a "primitive" in reality cannot act like one because of performance-related concerns. But perhaps this is just a transient concern: eventually we'll get primitive classes and we'll be able to avoid allocation w/o having to rely on escape analysis.
>> 
>> I'll work to re-implement the various methods tomorrow.
>
> Hi @mcimadamore, 
> 
> I was thinking about that last night ant I think I know what the issue and why it affects Lucene: As you remember, I mentioned that without tiered compilation and batch compilation enabled (the default for our benchmark to get more predictable result), the garbage produced and its collection is horrible. These are the first results above. As you see the copy methods are optimized only after 6 seconds. The total runtime of the benchmark was 73 seconds (50 seconds with our old code). So it looks like for the first 6 seconds the benchmark is hammering with many parallel queries the lucene index, creating incredible amounts of garbage (3 object instances for each memory copy), until the compilation kicks in. This is completely new to lucene, because the very low level code is carefully written to not produce any object instances, because from our experience, escape analysis kicks in way too late. The readBytes() method is not called in a loop, but it is still called quite often in a ve
 ry complex code path making it hard for the optimizer to kick in. What happens now: In our benchmark, we use many threads to execute fulltext queries and without the optimization kicking in, it creates millions of objects and those have to be garbage collected. Due to the high load (many threads and expensive low level query execution), GC has less CPU resources and then fails to kick in early enough and wastes at end like 23 seconds extra in cleaning up the useless garbage, possibly with stop-the-world phases.
> 
> With tiered compilation enabled, the compilation kicks in much earlier (after half a second already for C1) and after 1.2 seconds for C2.  This avoids a lot of garbage, (about 1/6s also in the output at end). The total runtime of the benchmark goes down from 73 seconds to approx 55 seconds). So garbage collector does not go crazy, but we still see a slowdown of 10% for some queries, but not 40% slowdown for queries like in the non-tiered case.
> 
> IMHO, inside Panama internals you should not rely on escape analysis to kick in early enough and implement stuff like copy methods without producing too much garbage by default.
> 
>> It does create a bit of a problem in terms of API stacking, in the sense that the MemorySegment::copyFrom method, while in principle is a "primitive" in reality cannot act like one because of performance-related concerns. 
> 
> Maybe document in the API of MemoryCopy, that those methods behave like the slicing code, but are much more efficient.
> 
> But I agree you should really work on letting the escape analysis kick in earlier, especially if code is not used in loops (like memory copy).
> 
> Thanks,
> Uwe

@uschindler I've just pushed a new iteration which uses unsafe directly when copying to/from arrays. Please give that a try - if numbers look good we will finalize this version.

-------------

PR: https://git.openjdk.java.net/panama-foreign/pull/555

From maurizio.cimadamore at oracle.com  Tue Jun 22 11:09:53 2021
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 22 Jun 2021 12:09:53 +0100
Subject: Foreign + Vectors - benchmarks for copying and swapping
In-Reply-To: 
References: 
 
 <5290e44a-7c67-6ee6-57dc-9af646604082@oracle.com>
 
 <1a23ee05-f187-e6d8-900e-62e77cd73dc9@oracle.com>
 <0DE3B831-2C2C-475B-94FC-867039D6AFC4@oracle.com>
 <07ccd69f-d218-15da-1b71-7dcaa767a7be@oracle.com>
 <9989FFC5-6D13-4114-B32D-A08D427925D4@oracle.com>
 
 
 <086778CB-EAC3-4A72-A7B5-E5D70522386F@oracle.com>
 <20caf67a-7a73-426b-d1be-39945757c4dc@oracle.com>
 
Message-ID: <92fe2f59-3436-6e83-d831-e4bf7e9192d5@oracle.com>

Thanks for the test - I'll also give your benchmark a try.

Maurizio

On 21/06/2021 22:25, Paul Sandoz wrote:
> Replacing the upper bound in `segmentImplicitScalar` with a constant (1024 say) results in a similar time to `bufferNativeScalar` without a constant bound, both of which (alas) are still slower that scalar array access (which benefits greatly from auto-vectorization).
>
> I wonder if the segment subrange checking for int value ranges is having an impact on bounds checking?
>
> Paul.
>
>> On Jun 21, 2021, at 1:56 PM, Maurizio Cimadamore  wrote:
>>
>>
>> On 21/06/2021 20:33, Paul Sandoz wrote:
>>> - Segment scalar access is penalized compared to ByteBuffer (from allocate or allocateDirect) scalar access.
>> Odd
>>
>> We have many benchmarks similar to this (see LoopOverNonConstant) and they seem to offer same level of performance compared with ByteBuffers.
>>
>> I wonder if the loop limit being "SPECIES.loopBound(srcArray.length)" plays a role? Have you tried replacing that expression with a constant?
>>
>> Maurizio
>>

From uschindler at openjdk.java.net  Tue Jun 22 11:25:40 2021
From: uschindler at openjdk.java.net (Uwe Schindler)
Date: Tue, 22 Jun 2021 11:25:40 GMT
Subject: [foreign-memaccess+abi] RFR: Add support for high-level functions
 to copy to and from Java arrays [v2]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

On Tue, 22 Jun 2021 07:33:34 GMT, Uwe Schindler  wrote:

>>> Performance is much better, but not yet ideal!
>>> 
>>> Maybe you should really think about implementing all those copy methods between arrays and segments without slicing and ideally also without wrapped segments.
>>> 
>>> Wouldn't it be so complicated to just implement all the MemoryCopy methods like that?
>> 
>> As you say, it is fairly easy to re-implement the various methods using unsafe directly. It does create a bit of a problem in terms of API stacking, in the sense that the `MemorySegment::copyFrom` method, while in principle is a "primitive" in reality cannot act like one because of performance-related concerns. But perhaps this is just a transient concern: eventually we'll get primitive classes and we'll be able to avoid allocation w/o having to rely on escape analysis.
>> 
>> I'll work to re-implement the various methods tomorrow.
>
> Hi @mcimadamore, 
> 
> I was thinking about that last night ant I think I know what the issue and why it affects Lucene: As you remember, I mentioned that without tiered compilation and batch compilation enabled (the default for our benchmark to get more predictable result), the garbage produced and its collection is horrible. These are the first results above. As you see the copy methods are optimized only after 6 seconds. The total runtime of the benchmark was 73 seconds (50 seconds with our old code). So it looks like for the first 6 seconds the benchmark is hammering with many parallel queries the lucene index, creating incredible amounts of garbage (3 object instances for each memory copy), until the compilation kicks in. This is completely new to lucene, because the very low level code is carefully written to not produce any object instances, because from our experience, escape analysis kicks in way too late. The readBytes() method is not called in a loop, but it is still called quite often in a ve
 ry complex code path making it hard for the optimizer to kick in. What happens now: In our benchmark, we use many threads to execute fulltext queries and without the optimization kicking in, it creates millions of objects and those have to be garbage collected. Due to the high load (many threads and expensive low level query execution), GC has less CPU resources and then fails to kick in early enough and wastes at end like 23 seconds extra in cleaning up the useless garbage, possibly with stop-the-world phases.
> 
> With tiered compilation enabled, the compilation kicks in much earlier (after half a second already for C1) and after 1.2 seconds for C2.  This avoids a lot of garbage, (about 1/6s also in the output at end). The total runtime of the benchmark goes down from 73 seconds to approx 55 seconds). So garbage collector does not go crazy, but we still see a slowdown of 10% for some queries, but not 40% slowdown for queries like in the non-tiered case.
> 
> IMHO, inside Panama internals you should not rely on escape analysis to kick in early enough and implement stuff like copy methods without producing too much garbage by default.
> 
>> It does create a bit of a problem in terms of API stacking, in the sense that the MemorySegment::copyFrom method, while in principle is a "primitive" in reality cannot act like one because of performance-related concerns. 
> 
> Maybe document in the API of MemoryCopy, that those methods behave like the slicing code, but are much more efficient.
> 
> But I agree you should really work on letting the escape analysis kick in earlier, especially if code is not used in loops (like memory copy).
> 
> Thanks,
> Uwe

> @uschindler I've just pushed a new iteration which uses unsafe directly when copying to/from arrays. Please give that a try - if numbers look good we will finalize this version.

There's something fishy:


Exception in thread "main" java.lang.UnsupportedOperationException: Attempt to write a read-only segment
        at jdk.incubator.foreign/jdk.internal.foreign.AbstractMemorySegmentImpl.checkAccess(AbstractMemorySegmentImpl.java:359)
        at jdk.incubator.foreign/jdk.incubator.foreign.MemoryCopy.copyToArray(MemoryCopy.java:108)
        at org.apache.lucene.store.MemorySegmentIndexInput.readBytes(MemorySegmentIndexInput.java:151)

-------------

PR: https://git.openjdk.java.net/panama-foreign/pull/555

From uschindler at openjdk.java.net  Tue Jun 22 11:49:41 2021
From: uschindler at openjdk.java.net (Uwe Schindler)
Date: Tue, 22 Jun 2021 11:49:41 GMT
Subject: [foreign-memaccess+abi] RFR: Add support for high-level functions
 to copy to and from Java arrays [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 22 Jun 2021 11:01:17 GMT, Maurizio Cimadamore  wrote:

>> This patch includes some of the changes from Lee to support a set of static functions to allow bulk copy from Java arrays to segments (and viceversa) in a more succint fashion (so that the user doesn't have to create a temporary heap segment to do the copy).
>> 
>> I've added a new public method to `MemorySegment` which performs an *element-wise* bulk copy; it takes a source segment and a couple of element layouts: the source element layout and the destination element layout. The two layouts must have same size, but can have different alignments (which will be checked against the corresponding segments) and byte orders. If the byte order differs, a bulk copy with swap will be performed. As such, this method generalizes the previous `copyFrom` - as follows:
>> 
>> 
>> copyFrom(srcSegment) -> copyFrom(JAVA_BYTE, srcSegment, JAVA_BYTE)
>> 
>> I've added support for argument type profiling for MemoryCopy static methods to avoid type pollution in cases where same metod is called with different memory segment types.
>> 
>> I've done a pass over the javadoc, and make it more consistent with the rest of the API. I've also reworked the test a bit to use the data provider functionality of TestNG, since all the test cases were similar, except for the carrier type.
>> 
>> There are other cosmetic changes as well, compared to original code from Lee, such as naming of static fields which is now capitalized. Everything else is the same.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use ScopedMemoryAccess directly inside MemoryCopy implementations

Looks like a copy-paste error:


srcImpl.checkAccess(srcOffsetBytes, dstCopyLengthBytes, false);


this should pass `true`, because the source check is readonly.

Maybe change the test to make the source segment read only. We catched it as we use a memory mapped file mapped read only.

-------------

PR: https://git.openjdk.java.net/panama-foreign/pull/555

From mcimadamore at openjdk.java.net  Tue Jun 22 12:37:17 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 22 Jun 2021 12:37:17 GMT
Subject: [foreign-memaccess+abi] RFR: Add support for high-level functions
 to copy to and from Java arrays [v4]
In-Reply-To: 
References: 
Message-ID: 

> This patch includes some of the changes from Lee to support a set of static functions to allow bulk copy from Java arrays to segments (and viceversa) in a more succint fashion (so that the user doesn't have to create a temporary heap segment to do the copy).
> 
> I've added a new public method to `MemorySegment` which performs an *element-wise* bulk copy; it takes a source segment and a couple of element layouts: the source element layout and the destination element layout. The two layouts must have same size, but can have different alignments (which will be checked against the corresponding segments) and byte orders. If the byte order differs, a bulk copy with swap will be performed. As such, this method generalizes the previous `copyFrom` - as follows:
> 
> 
> copyFrom(srcSegment) -> copyFrom(JAVA_BYTE, srcSegment, JAVA_BYTE)
> 
> I've added support for argument type profiling for MemoryCopy static methods to avoid type pollution in cases where same metod is called with different memory segment types.
> 
> I've done a pass over the javadoc, and make it more consistent with the rest of the API. I've also reworked the test a bit to use the data provider functionality of TestNG, since all the test cases were similar, except for the carrier type.
> 
> There are other cosmetic changes as well, compared to original code from Lee, such as naming of static fields which is now capitalized. Everything else is the same.

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Fix wrong polarity of readOnly in copyTo methods

-------------

Changes:
  - all: https://git.openjdk.java.net/panama-foreign/pull/555/files
  - new: https://git.openjdk.java.net/panama-foreign/pull/555/files/d8ceea6e..393ddddc

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=555&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=555&range=02-03

  Stats: 7 lines in 1 file changed: 0 ins; 0 del; 7 mod
  Patch: https://git.openjdk.java.net/panama-foreign/pull/555.diff
  Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/555/head:pull/555

PR: https://git.openjdk.java.net/panama-foreign/pull/555

From mcimadamore at openjdk.java.net  Tue Jun 22 12:37:20 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 22 Jun 2021 12:37:20 GMT
Subject: [foreign-memaccess+abi] RFR: Add support for high-level functions
 to copy to and from Java arrays [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 22 Jun 2021 11:01:17 GMT, Maurizio Cimadamore  wrote:

>> This patch includes some of the changes from Lee to support a set of static functions to allow bulk copy from Java arrays to segments (and viceversa) in a more succint fashion (so that the user doesn't have to create a temporary heap segment to do the copy).
>> 
>> I've added a new public method to `MemorySegment` which performs an *element-wise* bulk copy; it takes a source segment and a couple of element layouts: the source element layout and the destination element layout. The two layouts must have same size, but can have different alignments (which will be checked against the corresponding segments) and byte orders. If the byte order differs, a bulk copy with swap will be performed. As such, this method generalizes the previous `copyFrom` - as follows:
>> 
>> 
>> copyFrom(srcSegment) -> copyFrom(JAVA_BYTE, srcSegment, JAVA_BYTE)
>> 
>> I've added support for argument type profiling for MemoryCopy static methods to avoid type pollution in cases where same metod is called with different memory segment types.
>> 
>> I've done a pass over the javadoc, and make it more consistent with the rest of the API. I've also reworked the test a bit to use the data provider functionality of TestNG, since all the test cases were similar, except for the carrier type.
>> 
>> There are other cosmetic changes as well, compared to original code from Lee, such as naming of static fields which is now capitalized. Everything else is the same.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use ScopedMemoryAccess directly inside MemoryCopy implementations

> Looks like a copy-paste error:
> 
> ```java
> srcImpl.checkAccess(srcOffsetBytes, dstCopyLengthBytes, false);
> ```
> 
> this should pass `true`, because the source check is readonly.
> 
> Maybe change the test to make the source segment read only. We catched it as we use a memory mapped file mapped read only.

Fixed now, apologizes for the inconvenience!

-------------

PR: https://git.openjdk.java.net/panama-foreign/pull/555

From brian.goetz at oracle.com  Tue Jun 22 12:56:23 2021
From: brian.goetz at oracle.com (Brian Goetz)
Date: Tue, 22 Jun 2021 08:56:23 -0400
Subject: Gihub Action, CI pipeline
In-Reply-To: 
References: 
 <3bc9f966-00bd-5280-3fab-53784480ba66@oracle.com>
 
 
 
Message-ID: <665de923-3100-4f1d-d8bd-d1ac2c00eb21@oracle.com>


> OpenJDK projects may choose to use Github actions for pre-integration 
> testing.

This is not my understanding.? The CI cycles across the JDK project are 
extremely limited, and so we've been advised to avoid all use of GH 
actions for testing.

From uschindler at openjdk.java.net  Tue Jun 22 14:19:45 2021
From: uschindler at openjdk.java.net (Uwe Schindler)
Date: Tue, 22 Jun 2021 14:19:45 GMT
Subject: [foreign-memaccess+abi] RFR: Add support for high-level functions
 to copy to and from Java arrays [v4]
In-Reply-To: 
References: 
 
Message-ID: <2fNfmuzGBDKJF7bemdS3GJnKfpPGyQRRBaaMKqRw1uI=.a05243f0-bce2-4e8c-9eb8-534232f6b598@github.com>

On Tue, 22 Jun 2021 12:37:17 GMT, Maurizio Cimadamore  wrote:

>> This patch includes some of the changes from Lee to support a set of static functions to allow bulk copy from Java arrays to segments (and viceversa) in a more succint fashion (so that the user doesn't have to create a temporary heap segment to do the copy).
>> 
>> I've added a new public method to `MemorySegment` which performs an *element-wise* bulk copy; it takes a source segment and a couple of element layouts: the source element layout and the destination element layout. The two layouts must have same size, but can have different alignments (which will be checked against the corresponding segments) and byte orders. If the byte order differs, a bulk copy with swap will be performed. As such, this method generalizes the previous `copyFrom` - as follows:
>> 
>> 
>> copyFrom(srcSegment) -> copyFrom(JAVA_BYTE, srcSegment, JAVA_BYTE)
>> 
>> I've added support for argument type profiling for MemoryCopy static methods to avoid type pollution in cases where same metod is called with different memory segment types.
>> 
>> I've done a pass over the javadoc, and make it more consistent with the rest of the API. I've also reworked the test a bit to use the data provider functionality of TestNG, since all the test cases were similar, except for the carrier type.
>> 
>> There are other cosmetic changes as well, compared to original code from Lee, such as naming of static fields which is now capitalized. Everything else is the same.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix wrong polarity of readOnly in copyTo methods

Hi,

I can confirm. The garbage collection issues are gone. The heap profile of Lucene looks identical to our old ByteBuffer-based implementation:


PERCENT       HEAP SAMPLES  STACK
16.78%        4781M         org.apache.lucene.util.FixedBitSet#()
10.17%        2897M         org.apache.lucene.search.ExactPhraseMatcher$1$1#getImpacts()
8.51%         2424M         java.util.AbstractList#iterator()
7.67%         2184M         org.apache.lucene.search.ExactPhraseMatcher$1#getImpacts()
4.37%         1245M         org.apache.lucene.codecs.lucene90.blocktree.SegmentTermsEnumFrame#()
3.46%         985M          org.apache.lucene.queryparser.charstream.FastCharStream#refill()
3.11%         885M          org.apache.lucene.util.ArrayUtil#growExact()
2.93%         834M          java.util.ArrayList#grow()
2.37%         675M          org.apache.lucene.codecs.lucene90.Lucene90PostingsReader$BlockDocsEnum#()
2.14%         609M          org.apache.lucene.util.BytesRef#()
1.76%         502M          java.util.ArrayList#iterator()
1.73%         491M          org.apache.lucene.util.fst.ByteSequenceOutputs#read()
1.52%         432M          org.apache.lucene.util.PriorityQueue#()
1.49%         425M          jdk.internal.misc.Unsafe#allocateUninitializedArray()
1.30%         369M          org.apache.lucene.codecs.lucene90.blocktree.IntersectTermsEnumFrame#load()
1.27%         362M          org.apache.lucene.codecs.lucene90.Lucene90PostingsReader#newTermState()
1.26%         359M          org.apache.lucene.codecs.lucene90.blocktree.SegmentTermsEnum#getFrame()
1.20%         342M          org.apache.lucene.codecs.lucene90.Lucene90PostingsReader$BlockImpactsDocsEnum#()
1.10%         312M          org.apache.lucene.codecs.lucene90.blocktree.SegmentTermsEnum#()
1.03%         292M          org.apache.lucene.store.MemorySegmentIndexInput#buildSlice()
0.99%         283M          org.apache.lucene.queryparser.charstream.FastCharStream#GetImage()
0.98%         279M          org.apache.lucene.codecs.lucene90.Lucene90PostingsReader$BlockImpactsPostingsEnum#()
0.98%         279M          org.apache.lucene.codecs.lucene90.ForUtil#()
0.94%         267M          org.apache.lucene.util.DocIdSetBuilder$Buffer#()
0.90%         257M          java.util.AbstractList#listIterator()
0.88%         250M          org.apache.lucene.codecs.lucene90.blocktree.IntersectTermsEnumFrame#()
0.81%         231M          jdk.internal.foreign.MappedMemorySegmentImpl#dup()
0.80%         229M          org.apache.lucene.codecs.lucene90.compressing.Lucene90CompressingStoredFieldsReader$BlockState#document()
0.77%         219M          java.util.Arrays#copyOfRange()
0.69%         198M          java.util.Arrays#asList()


ByteBuffer profile:


PERCENT       HEAP SAMPLES  STACK
16.44%        4774M         org.apache.lucene.util.FixedBitSet#()
9.88%         2870M         org.apache.lucene.search.ExactPhraseMatcher$1$1#getImpacts()
8.34%         2421M         java.util.AbstractList#iterator()
7.42%         2155M         org.apache.lucene.search.ExactPhraseMatcher$1#getImpacts()
4.40%         1278M         org.apache.lucene.codecs.lucene90.blocktree.SegmentTermsEnumFrame#()
3.30%         959M          org.apache.lucene.util.ArrayUtil#growExact()
3.09%         896M          java.util.ArrayList#grow()
2.89%         839M          org.apache.lucene.queryparser.charstream.FastCharStream#refill()
2.26%         655M          org.apache.lucene.codecs.lucene90.Lucene90PostingsReader$BlockDocsEnum#()
1.98%         573M          org.apache.lucene.util.BytesRef#()
1.91%         553M          java.util.ArrayList#iterator()
1.69%         490M          org.apache.lucene.util.fst.ByteSequenceOutputs#read()
1.54%         448M          jdk.internal.misc.Unsafe#allocateUninitializedArray()
1.53%         444M          java.nio.DirectByteBufferR#duplicate()
1.52%         440M          org.apache.lucene.util.PriorityQueue#()
1.42%         411M          org.apache.lucene.codecs.lucene90.blocktree.IntersectTermsEnumFrame#load()
1.28%         371M          org.apache.lucene.codecs.lucene90.blocktree.SegmentTermsEnum#getFrame()
1.25%         362M          org.apache.lucene.codecs.lucene90.Lucene90PostingsReader#newTermState()
1.23%         356M          org.apache.lucene.queryparser.charstream.FastCharStream#GetImage()
1.20%         348M          org.apache.lucene.codecs.lucene90.Lucene90PostingsReader$BlockImpactsDocsEnum#()
1.00%         289M          org.apache.lucene.codecs.lucene90.blocktree.SegmentTermsEnum#()
0.92%         268M          java.util.AbstractList#listIterator()
0.91%         265M          org.apache.lucene.codecs.lucene90.blocktree.IntersectTermsEnumFrame#()
0.91%         264M          org.apache.lucene.codecs.lucene90.ForUtil#()
0.89%         257M          java.util.Arrays#copyOf()
0.82%         238M          org.apache.lucene.util.DocIdSetBuilder$Buffer#()
0.82%         237M          org.apache.lucene.codecs.lucene90.Lucene90PostingsReader$BlockImpactsPostingsEnum#()
0.79%         230M          org.apache.lucene.codecs.lucene90.compressing.Lucene90CompressingStoredFieldsReader$BlockState#document()
0.77%         224M          java.nio.DirectByteBufferR#slice()
0.70%         202M          java.util.Arrays#asList()


As you see we have a few segment slices/dups, but similar for MappedByteBuffers (this comes from the fact that Lucene sometimes opens views on compound files.

The performance is still a little bit slower for some query types (mainly facets), but I have the feeling this comes from the overhead when coyping small arrays, as well as scoping checks.

@mcimadamore: You mentioned that for small arrays, copy-loops may fit better. Do you have any suggestions what loop sizes we are talking about. Lucene's `long[]` are safely sizes <= 64 and `float[]` of sizes <= 1024 elements, so maybe it's a good idea to just use the default read loop and not specialize it to do bulk copy.

Here are Lucene's results:


                    TaskQPS baseline      StdDevQPS my_modified_version      StdDev                Pct diff p-value
   BrowseMonthTaxoFacets        1.17      (5.7%)        1.07      (6.4%)   -8.6% ( -19% -    3%) 0.000
BrowseDayOfYearTaxoFacets        1.13      (7.1%)        1.04      (7.8%)   -7.9% ( -21% -    7%) 0.001
    BrowseDateTaxoFacets        1.13      (7.1%)        1.04      (8.0%)   -7.7% ( -21% -    7%) 0.001
    HighTermTitleBDVSort       54.84     (20.1%)       50.84     (15.8%)   -7.3% ( -35% -   35%) 0.202
                PKLookup      188.75      (2.2%)      181.26      (1.4%)   -4.0% (  -7% -    0%) 0.000
             AndHighHigh       61.16      (6.1%)       59.56      (5.6%)   -2.6% ( -13% -    9%) 0.158
   HighTermDayOfYearSort       63.43     (10.8%)       62.28     (14.2%)   -1.8% ( -24% -   26%) 0.650
                  Fuzzy2       57.80      (5.1%)       56.81      (5.1%)   -1.7% ( -11% -    8%) 0.288
       HighTermMonthSort       66.31     (11.8%)       65.22     (17.0%)   -1.7% ( -27% -   30%) 0.720
                 Respell       68.71      (2.4%)       67.71      (2.1%)   -1.5% (  -5% -    3%) 0.041
              HighPhrase       10.97      (4.8%)       10.83      (6.2%)   -1.3% ( -11% -   10%) 0.468
              AndHighMed       44.63      (4.4%)       44.09      (4.2%)   -1.2% (  -9% -    7%) 0.370
              TermDTSort      105.50     (17.0%)      104.58     (19.8%)   -0.9% ( -32% -   43%) 0.880
               OrHighMed       34.38      (3.5%)       34.14      (3.9%)   -0.7% (  -7% -    6%) 0.556
               OrHighLow      337.44      (3.1%)      335.46      (4.6%)   -0.6% (  -8% -    7%) 0.634
               MedPhrase      179.30      (2.7%)      178.40      (4.1%)   -0.5% (  -7% -    6%) 0.646
              AndHighLow      369.54      (2.9%)      367.78      (3.3%)   -0.5% (  -6% -    5%) 0.628
                  Fuzzy1       52.74      (9.8%)       52.49      (9.2%)   -0.5% ( -17% -   20%) 0.874
              OrHighHigh       12.03      (3.8%)       11.97      (3.7%)   -0.4% (  -7% -    7%) 0.717
                  IntNRQ       73.05      (1.5%)       72.78      (2.5%)   -0.4% (  -4% -    3%) 0.569
         MedSloppyPhrase       25.01      (1.9%)       24.98      (1.7%)   -0.1% (  -3% -    3%) 0.856
                Wildcard       76.65     (21.9%)       76.60     (21.5%)   -0.1% ( -35% -   55%) 0.993
    HighIntervalsOrdered       10.04      (4.3%)       10.03      (5.5%)   -0.0% (  -9% -   10%) 0.979
         LowSloppyPhrase       39.07      (2.3%)       39.08      (2.3%)    0.0% (  -4% -    4%) 0.970
BrowseDayOfYearSSDVFacets        4.00      (4.6%)        4.00      (5.6%)    0.1% (  -9% -   10%) 0.972
             LowSpanNear       51.01      (2.0%)       51.09      (1.6%)    0.2% (  -3% -    3%) 0.784
               LowPhrase      265.84      (2.0%)      266.25      (2.9%)    0.2% (  -4% -    5%) 0.845
                 MedTerm     1532.72      (4.0%)     1535.72      (4.5%)    0.2% (  -7% -    9%) 0.884
                HighTerm     1382.84      (5.2%)     1388.91      (4.9%)    0.4% (  -9% -   11%) 0.784
            OrHighNotMed      851.21      (3.9%)      856.51      (3.6%)    0.6% (  -6% -    8%) 0.599
            OrNotHighLow      772.85      (3.2%)      778.22      (3.6%)    0.7% (  -5% -    7%) 0.522
   BrowseMonthSSDVFacets        4.06      (6.3%)        4.09      (6.5%)    0.8% ( -11% -   14%) 0.692
            OrHighNotLow      726.91      (4.7%)      732.78      (5.0%)    0.8% (  -8% -   10%) 0.596
             MedSpanNear      101.32      (3.0%)      102.16      (2.7%)    0.8% (  -4% -    6%) 0.354
            HighSpanNear        0.90      (3.0%)        0.91      (2.9%)    0.9% (  -4% -    6%) 0.364
        HighSloppyPhrase       13.89      (4.6%)       14.02      (4.4%)    0.9% (  -7% -   10%) 0.509
            OrNotHighMed      597.86      (3.0%)      604.63      (3.8%)    1.1% (  -5% -    8%) 0.298
                 LowTerm     1874.30      (3.2%)     1898.96      (4.5%)    1.3% (  -6% -    9%) 0.287
                 Prefix3       38.02      (8.6%)       38.53     (10.1%)    1.3% ( -15% -   21%) 0.655
           OrNotHighHigh      719.81      (3.8%)      731.82      (5.3%)    1.7% (  -7% -   11%) 0.252
           OrHighNotHigh      723.65      (4.0%)      736.28      (3.7%)    1.7% (  -5% -    9%) 0.153

-------------

PR: https://git.openjdk.java.net/panama-foreign/pull/555

From uschindler at openjdk.java.net  Tue Jun 22 14:33:46 2021
From: uschindler at openjdk.java.net (Uwe Schindler)
Date: Tue, 22 Jun 2021 14:33:46 GMT
Subject: [foreign-memaccess+abi] RFR: Add support for high-level functions
 to copy to and from Java arrays [v4]
In-Reply-To: 
References: 
 
Message-ID: <8QjsynVVn9RDlQVN4-vODETiAVEXgRhsxCti2XyvziA=.65043518-8596-4ec8-99f9-46f60106a397@github.com>

On Tue, 22 Jun 2021 12:37:17 GMT, Maurizio Cimadamore  wrote:

>> This patch includes some of the changes from Lee to support a set of static functions to allow bulk copy from Java arrays to segments (and viceversa) in a more succint fashion (so that the user doesn't have to create a temporary heap segment to do the copy).
>> 
>> I've added a new public method to `MemorySegment` which performs an *element-wise* bulk copy; it takes a source segment and a couple of element layouts: the source element layout and the destination element layout. The two layouts must have same size, but can have different alignments (which will be checked against the corresponding segments) and byte orders. If the byte order differs, a bulk copy with swap will be performed. As such, this method generalizes the previous `copyFrom` - as follows:
>> 
>> 
>> copyFrom(srcSegment) -> copyFrom(JAVA_BYTE, srcSegment, JAVA_BYTE)
>> 
>> I've added support for argument type profiling for MemoryCopy static methods to avoid type pollution in cases where same metod is called with different memory segment types.
>> 
>> I've done a pass over the javadoc, and make it more consistent with the rest of the API. I've also reworked the test a bit to use the data provider functionality of TestNG, since all the test cases were similar, except for the carrier type.
>> 
>> There are other cosmetic changes as well, compared to original code from Lee, such as naming of static fields which is now capitalized. Everything else is the same.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix wrong polarity of readOnly in copyTo methods

Hi,
to me this looks good now.

I like the new code much more, because the previous version of this pull request was a bit strange:
- In MemoryCopy the code checked if native order equals parameter order and then used ValueLayout (one instance for each valuecsize) to call MemorySegment.copyFrom()
- MemorySegment.copyFrom() took the ValueLayout and then compared it again to determine if it is different from native byte order; just to convert it back to a boolean at end: swap yes/no.

All this was so much code and I was always afraid that there is some case where the ValueLayouts were used wrongly.

So much better! I love it!

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemoryCopy.java line 58:

> 56:     private static final Unsafe unsafe = Unsafe.getUnsafe();
> 57: 
> 58:     private static final int BYTE_BASE = unsafe.arrayBaseOffset(byte[].class);

Are there not constants for this already in `jdk.internal.misc.Unsafe`?

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemoryCopy.java line 153:

> 151:         AbstractMemorySegmentImpl destImpl = (AbstractMemorySegmentImpl)dstSegment;
> 152:         destImpl.checkAccess(dstOffsetBytes, srcCopyLengthChars << 1, false);
> 153:         if (order == ByteOrder.nativeOrder()) {

I like this code much more than the previous one, as it makes clear: swap tru or false, just a boolean! The Usage of MemorySegment.copyFrom() was very complicated as it used ValueLayouts, one for each size.

test/jdk/java/foreign/TestMemoryCopy.java line 119:

> 117:             arr[i] = (byte)i;
> 118:         }
> 119:         return MemorySegment.ofArray(arr);

This segment should be made readonly, to assert all checkAccess() calls.

-------------

Marked as reviewed by uschindler (no project role).

PR: https://git.openjdk.java.net/panama-foreign/pull/555

From mcimadamore at openjdk.java.net  Tue Jun 22 14:58:41 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 22 Jun 2021 14:58:41 GMT
Subject: [foreign-memaccess+abi] RFR: Add support for high-level functions
 to copy to and from Java arrays [v4]
In-Reply-To: <2fNfmuzGBDKJF7bemdS3GJnKfpPGyQRRBaaMKqRw1uI=.a05243f0-bce2-4e8c-9eb8-534232f6b598@github.com>
References: 
 
 <2fNfmuzGBDKJF7bemdS3GJnKfpPGyQRRBaaMKqRw1uI=.a05243f0-bce2-4e8c-9eb8-534232f6b598@github.com>
Message-ID: 

On Tue, 22 Jun 2021 14:16:56 GMT, Uwe Schindler  wrote:

> The performance is still a little bit slower for some query types (mainly facets), but I have the feeling this comes from the overhead when coyping small arrays, as well as scoping checks.
> 
> @mcimadamore: You mentioned that for small arrays, copy-loops may fit better. Do you have any suggestions what loop sizes we are talking about. Lucene's `long[]` are safely sizes <= 64 and `float[]` of sizes <= 1024 elements, so maybe it's a good idea to just use the default read loop and not specialize it to do bulk copy.

This does indeed look a lot better, thanks for testing. The issue with memory copy is that it adds unconditional memory barriers - so, in some circumstances it can cause performance degradation. If you copy in a loop, you use Unsafe::get/put and those will only add barriers if access is on-heap.

We have a bug to track this issue:
https://bugs.openjdk.java.net/browse/JDK-8269119

In terms of sizes, I think the ByteBuffer API used to avoid copying for extremely small sizes, (6 logical elements, if I'm correct).

I also think that there are other performance potholes around bound checking (as we speak, we're investigating one mentioned here [1]) and some of those will not be even addressable until we get proper support for long loop optimizations [2].

So, we know that, performance-wise, we're still not 100% there, but it seems like we're getting closer.

[1] - https://mail.openjdk.java.net/pipermail/panama-dev/2021-June/014260.html
[2] - https://github.com/openjdk/jdk/pull/2045

-------------

PR: https://git.openjdk.java.net/panama-foreign/pull/555

From uschindler at openjdk.java.net  Tue Jun 22 16:43:46 2021
From: uschindler at openjdk.java.net (Uwe Schindler)
Date: Tue, 22 Jun 2021 16:43:46 GMT
Subject: [foreign-memaccess+abi] RFR: Add support for high-level functions
 to copy to and from Java arrays [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 22 Jun 2021 12:37:17 GMT, Maurizio Cimadamore  wrote:

>> This patch includes some of the changes from Lee to support a set of static functions to allow bulk copy from Java arrays to segments (and viceversa) in a more succint fashion (so that the user doesn't have to create a temporary heap segment to do the copy).
>> 
>> I've added a new public method to `MemorySegment` which performs an *element-wise* bulk copy; it takes a source segment and a couple of element layouts: the source element layout and the destination element layout. The two layouts must have same size, but can have different alignments (which will be checked against the corresponding segments) and byte orders. If the byte order differs, a bulk copy with swap will be performed. As such, this method generalizes the previous `copyFrom` - as follows:
>> 
>> 
>> copyFrom(srcSegment) -> copyFrom(JAVA_BYTE, srcSegment, JAVA_BYTE)
>> 
>> I've added support for argument type profiling for MemoryCopy static methods to avoid type pollution in cases where same metod is called with different memory segment types.
>> 
>> I've done a pass over the javadoc, and make it more consistent with the rest of the API. I've also reworked the test a bit to use the data provider functionality of TestNG, since all the test cases were similar, except for the carrier type.
>> 
>> There are other cosmetic changes as well, compared to original code from Lee, such as naming of static fields which is now capitalized. Everything else is the same.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix wrong polarity of readOnly in copyTo methods

Small update: With tiered compilation enabled, perf numbers are getting closer to ByteBuffer API. The difference is now smaller than std deviation. Some queries are 8% faster, other 8% slower.

-------------

PR: https://git.openjdk.java.net/panama-foreign/pull/555

From paul.sandoz at oracle.com  Tue Jun 22 20:29:45 2021
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 22 Jun 2021 20:29:45 +0000
Subject: Foreign + Vectors - benchmarks for copying and swapping
In-Reply-To: 
References: 
 
 <5290e44a-7c67-6ee6-57dc-9af646604082@oracle.com>
 
 <1a23ee05-f187-e6d8-900e-62e77cd73dc9@oracle.com>
 <0DE3B831-2C2C-475B-94FC-867039D6AFC4@oracle.com>
 <07ccd69f-d218-15da-1b71-7dcaa767a7be@oracle.com>
 <9989FFC5-6D13-4114-B32D-A08D427925D4@oracle.com>
 
 
 <086778CB-EAC3-4A72-A7B5-E5D70522386F@oracle.com>
 <20caf67a-7a73-426b-d1be-39945757c4dc@oracle.com>
 
 
Message-ID: <5E9D6923-BFF9-4D29-B721-97D56A6BF031@oracle.com>

In general that should be ok. Try using IntVector instead and it will unroll (with your patch removing CPU barriers)

I wonder if this may be a limitation specific to bytes. 

Paul.

> On Jun 21, 2021, at 4:28 PM, Rados?aw Smogura  wrote:
> 
> Hi,
> 
> I think why the copy case may fail with unrolling, because
> 	? loop unroll takes the range check from intoByteBuffer as the loop exit condition
> 	? the range check uses unsigned compare, which is not supported by loop unroll
> 
> I think in this code
>         for (int i = 0; i < bound; i += lanes) {
>           final var srcVector = ByteVector
>               .fromByteBuffer(BYTE_VECTOR_SPECIES, src, i, ByteOrder.nativeOrder());
> 
>           srcVector.intoByteBuffer(dst, i, ByteOrder.nativeOrder());
>         }
> exit condition should be i < bound, not a range check from intoByteBuffer.
> 
> Kind regards,
> Rado
> 
> Od: Paul Sandoz 
> Wys?ane: poniedzia?ek, 21 czerwca 2021 23:25
> Do: Maurizio Cimadamore 
> DW: Rados?aw Smogura ; Vladimir Ivanov ; panama-dev at openjdk.java.net 
> Temat: Re: Foreign + Vectors - benchmarks for copying and swapping
>  
> Replacing the upper bound in `segmentImplicitScalar` with a constant (1024 say) results in a similar time to `bufferNativeScalar` without a constant bound, both of which (alas) are still slower that scalar array access (which benefits greatly from auto-vectorization).
> 
> I wonder if the segment subrange checking for int value ranges is having an impact on bounds checking?
> 
> Paul.
> 
> > On Jun 21, 2021, at 1:56 PM, Maurizio Cimadamore  wrote:
> > 
> > 
> > On 21/06/2021 20:33, Paul Sandoz wrote:
> >> - Segment scalar access is penalized compared to ByteBuffer (from allocate or allocateDirect) scalar access.
> > 
> > Odd
> > 
> > We have many benchmarks similar to this (see LoopOverNonConstant) and they seem to offer same level of performance compared with ByteBuffers.
> > 
> > I wonder if the loop limit being "SPECIES.loopBound(srcArray.length)" plays a role? Have you tried replacing that expression with a constant?
> > 
> > Maurizio
> > 


From paul.sandoz at oracle.com  Tue Jun 22 22:47:46 2021
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 22 Jun 2021 22:47:46 +0000
Subject: [ a newby question about vectorized shuffling / permutation ]
In-Reply-To: 
References: 
 
Message-ID: <4B487585-47CD-43A1-8E2B-DF55F79F60AA@oracle.com>

Hi Denis,

Thanks for sharing, perhaps you can share the complete JMH benchmark?

In your current approach there may be no benefit to using a vector for the right side, since you unpack the lane elements, just use the array elements directly as input to the broadcast eq.

I would be interested in seeing the shuffle version, if you have it. Some Shuffle/Mask stuff is still work in progress, but it could still be a good test case.

Paul.


> On Jun 20, 2021, at 2:26 PM, Denis Gabaydulin  wrote:
> 
> If somebody is interested in the result, here's my solution (which is
> twice faster on SPECIES_128).
> 
> https://gist.github.com/sherman/6d8a4103ba5bb3d2911684b8c842647f
> 
> Benchmark with the intersection in the middle of arrays.
> 
> Benchmark                                    Mode Cnt Score  Error  Units
> IntersectionBenchmark.hasIntersectionScalar thrpt  10 3.785 ? 0.095 ops/us
> IntersectionBenchmark.hasIntersectionVector thrpt  10 7.008 ? 0.795 ops/us
> 
> What I do:
> Changed the shuffling op by the broadcast op.
> 
> Here's the most significant part in the asm:
> 
> https://gist.github.com/sherman/7788e37b667940f31531ce74cb53b4e5
> 
> Would be very appreciated any suggestions and comments on how it can
> be improved in terms of throughput?
> 
> On Wed, Jun 2, 2021 at 2:04 PM Denis Gabaydulin  wrote:
>> 
>> Hi, folks!
>> 
>> Have a newbie question about the API.
>> I'm trying to explore a new and shiny vector API with simple but useful examples.
>> 
>> One of that is to build a SIMD version to find any intersection of two sorted lists.
>> 
>> E.g.
>> hasIntersection([1, 3, 4, 10],  [2, 6, 6, 11]) => false
>> hasIntersection([1, 3, 4, 10],  [2, 3, 6, 11]) => true
>> 
>> A mental model of this algorithm which I have:
>> 
>> 1). to get a part of an array one
>> 2). compare it n-times which corresponding part of an array two.
>> 3). each time we need to compare two parts of arrays we need to shuffle (permutate) a left part by a mask. E.g. 1, 3, 4, 10 -> 10, 1, 3, 4
>> 4). if one of a number is the same, return true, otherwise, move.
>> In SIMD instructions looks like I need two major things.
>> 
>> 1). vectorized comparison instruction
>> 2). vectorized shuffle instruction.
>> 
>> The first one, I can see in the printed asm.
>> compare in API -> vpcmpeqd
>> 
>> The question, which function of the vector API should I use to getting something like _mm_shuffle_epi32 ?
>> 
>> 
>> 
>> 
> 
> On Wed, Jun 2, 2021 at 2:04 PM Denis Gabaydulin  wrote:
>> 
>> Hi, folks!
>> 
>> Have a newbie question about the API.
>> I'm trying to explore a new and shiny vector API with simple but useful examples.
>> 
>> One of that is to build a SIMD version to find any intersection of two sorted lists.
>> 
>> E.g.
>> hasIntersection([1, 3, 4, 10],  [2, 6, 6, 11]) => false
>> hasIntersection([1, 3, 4, 10],  [2, 3, 6, 11]) => true
>> 
>> A mental model of this algorithm which I have:
>> 
>> 1). to get a part of an array one
>> 2). compare it n-times which corresponding part of an array two.
>> 3). each time we need to compare two parts of arrays we need to shuffle (permutate) a left part by a mask. E.g. 1, 3, 4, 10 -> 10, 1, 3, 4
>> 4). if one of a number is the same, return true, otherwise, move.
>> In SIMD instructions looks like I need two major things.
>> 
>> 1). vectorized comparison instruction
>> 2). vectorized shuffle instruction.
>> 
>> The first one, I can see in the printed asm.
>> compare in API -> vpcmpeqd
>> 
>> The question, which function of the vector API should I use to getting something like _mm_shuffle_epi32 ?
>> 
>> 
>> 
>> 


From xgong at openjdk.java.net  Wed Jun 23 02:08:52 2021
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Wed, 23 Jun 2021 02:08:52 GMT
Subject: [vectorIntrinsics+mask] RFR: 8266287: Basic mask IR
 implementation for the Vector API masking feature support [v3]
In-Reply-To: 
References: 
 
 
 
 
 
 
Message-ID: <8-pvCxVmC9fKfFFDOXuyFYvNRigJklNhyUhYrOsaHq0=.38973d62-9199-4881-ae4b-1eb3bfd9d2dd@github.com>

On Tue, 22 Jun 2021 09:43:07 GMT, Jatin Bhateja  wrote:

>> Hi @XiaohongGong ,
>> 
>> I made following changes in unbox and box creation routines and did not find any crashes as reported in any of VectorAPI jtreg over AVX-512 platform.
>> 
>> 
>> diff --git a/src/hotspot/share/opto/vectorIntrinsics.cpp b/src/hotspot/share/opto/vectorIntrinsics.cpp
>> index 21e238afb5b..76553c9f2c9 100644
>> --- a/src/hotspot/share/opto/vectorIntrinsics.cpp
>> +++ b/src/hotspot/share/opto/vectorIntrinsics.cpp
>> @@ -81,7 +81,7 @@ Node* GraphKit::box_vector(Node* vector, const TypeInstPtr* vbox_type, BasicType
>>    Node* ret = gvn().transform(new ProjNode(alloc, TypeFunc::Parms));
>> 
>>    assert(check_vbox(vbox_type), "");
>> -  const TypeVect* vt = TypeVect::make(elem_bt, num_elem, is_vector_mask(vbox_type->klass()));
>> +  const TypeVect* vt = TypeVect::make(elem_bt, num_elem);
>>    VectorBoxNode* vbox = new VectorBoxNode(C, ret, vector, vbox_type, vt);
>>    return gvn().transform(vbox);
>>  }
>> @@ -96,7 +96,7 @@ Node* GraphKit::unbox_vector(Node* v, const TypeInstPtr* vbox_type, BasicType el
>>      return NULL; // no nulls are allowed
>>    }
>>    assert(check_vbox(vbox_type), "");
>> -  const TypeVect* vt = TypeVect::make(elem_bt, num_elem, is_vector_mask(vbox_type->klass()));
>> +  const TypeVect* vt = TypeVect::make(elem_bt, num_elem);
>>    Node* unbox = gvn().transform(new VectorUnboxNode(C, vt, v, merged_memory(), shuffle_to_vector));
>>    return unbox;
>>  }
>> 
>> Can you kindly share a exact re-producer.
>
> Box/Unbox are macro nodes which encapsulates value, in this case the mask value is contained either in  a a vector or a predicate register. This should ideally not be disturbing the box's vector type() I think.

Did you implement the vector mask IRs with `TypeVectMask` type in backend? I made a workaround to make sure the tests can pass with this patch but without any backend implementation for AVX-512/SVE. Please see the change in `type.cpp`:

const TypeVect *TypeVect::makemask(const Type* elem, uint length) {
  if (Matcher::has_predicated_vectors() &&
      // TODO: remove this condition once the backend is supported.
      // Workround to make tests pass on AVX-512/SVE when predicate is not supported.
      // Could be removed once the backend is supported.
      Matcher::match_rule_supported_vector_masked(Op_StoreVectorMasked, MaxVectorSize, T_BOOLEAN)) {
    const TypeVect* mtype = Matcher::predicate_reg_type(elem, length);
    return (TypeVect*)(const_cast(mtype))->hashcons();
  } else {

The `TypeVectMask` can only be made successfully when the backend has implemented masked `Op_StoreVectorMasked`. This is just a workaround that would be removed once the AVX-512 add the backend implementation for all mask/masked IRs.

-------------

PR: https://git.openjdk.java.net/panama-vector/pull/78

From xgong at openjdk.java.net  Wed Jun 23 02:11:56 2021
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Wed, 23 Jun 2021 02:11:56 GMT
Subject: [vectorIntrinsics+mask] RFR: 8266287: Basic mask IR
 implementation for the Vector API masking feature support [v3]
In-Reply-To: <8-pvCxVmC9fKfFFDOXuyFYvNRigJklNhyUhYrOsaHq0=.38973d62-9199-4881-ae4b-1eb3bfd9d2dd@github.com>
References: 
 
 
 
 
 
 
 <8-pvCxVmC9fKfFFDOXuyFYvNRigJklNhyUhYrOsaHq0=.38973d62-9199-4881-ae4b-1eb3bfd9d2dd@github.com>
Message-ID: <-72e7vhhu1yU2U9b6Ft2j7nwRFc6egbjxXRu3pJVees=.048de98a-0da1-4701-8964-868e88a2f715@github.com>

On Wed, 23 Jun 2021 02:05:16 GMT, Xiaohong Gong  wrote:

>> Box/Unbox are macro nodes which encapsulates value, in this case the mask value is contained either in  a a vector or a predicate register. This should ideally not be disturbing the box's vector type() I think.
>
> Did you implement the vector mask IRs with `TypeVectMask` type in backend? I made a workaround to make sure the tests can pass with this patch but without any backend implementation for AVX-512/SVE. Please see the change in `type.cpp`:
> 
> const TypeVect *TypeVect::makemask(const Type* elem, uint length) {
>   if (Matcher::has_predicated_vectors() &&
>       // TODO: remove this condition once the backend is supported.
>       // Workround to make tests pass on AVX-512/SVE when predicate is not supported.
>       // Could be removed once the backend is supported.
>       Matcher::match_rule_supported_vector_masked(Op_StoreVectorMasked, MaxVectorSize, T_BOOLEAN)) {
>     const TypeVect* mtype = Matcher::predicate_reg_type(elem, length);
>     return (TypeVect*)(const_cast(mtype))->hashcons();
>   } else {
> 
> The `TypeVectMask` can only be made successfully when the backend has implemented masked `Op_StoreVectorMasked`. This is just a workaround that would be removed once the AVX-512 add the backend implementation for all mask/masked IRs.

>From the crash log, I guess the issue happens for a `PhiNode` with vector masks as its values. Assume one of its value is a `VectorUnboxNode` with `TypeVect` while others are mask nodes with `TypeVectMask`, then the crash can happen when the compiler try to decide the final type of the `PhiNode`. Please correct me if I misunderstand it. Thanks!

-------------

PR: https://git.openjdk.java.net/panama-vector/pull/78

From jbhateja at openjdk.java.net  Wed Jun 23 12:57:57 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Wed, 23 Jun 2021 12:57:57 GMT
Subject: [vectorIntrinsics+mask] RFR: 8266287: Basic mask IR
 implementation for the Vector API masking feature support [v3]
In-Reply-To: <-72e7vhhu1yU2U9b6Ft2j7nwRFc6egbjxXRu3pJVees=.048de98a-0da1-4701-8964-868e88a2f715@github.com>
References: 
 
 
 
 
 
 
 <8-pvCxVmC9fKfFFDOXuyFYvNRigJklNhyUhYrOsaHq0=.38973d62-9199-4881-ae4b-1eb3bfd9d2dd@github.com>
 <-72e7vhhu1yU2U9b6Ft2j7nwRFc6egbjxXRu3pJVees=.048de98a-0da1-4701-8964-868e88a2f715@github.com>
Message-ID: <0sl3asXrMktJnN-KWK3FBrdfdzKajBSXxam8NS-W5Pc=.feebc515-d2b5-4b80-8998-382d0c3f188e@github.com>

On Wed, 23 Jun 2021 02:08:57 GMT, Xiaohong Gong  wrote:

>> Did you implement the vector mask IRs with `TypeVectMask` type in backend? I made a workaround to make sure the tests can pass with this patch but without any backend implementation for AVX-512/SVE. Please see the change in `type.cpp`:
>> 
>> const TypeVect *TypeVect::makemask(const Type* elem, uint length) {
>>   if (Matcher::has_predicated_vectors() &&
>>       // TODO: remove this condition once the backend is supported.
>>       // Workround to make tests pass on AVX-512/SVE when predicate is not supported.
>>       // Could be removed once the backend is supported.
>>       Matcher::match_rule_supported_vector_masked(Op_StoreVectorMasked, MaxVectorSize, T_BOOLEAN)) {
>>     const TypeVect* mtype = Matcher::predicate_reg_type(elem, length);
>>     return (TypeVect*)(const_cast(mtype))->hashcons();
>>   } else {
>> 
>> The `TypeVectMask` can only be made successfully when the backend has implemented masked `Op_StoreVectorMasked`. This is just a workaround that would be removed once the AVX-512 add the backend implementation for all mask/masked IRs.
>
> From the crash log, I guess the issue happens for a `PhiNode` with vector masks as its values. Assume one of its value is a `VectorUnboxNode` with `TypeVect` while others are mask nodes with `TypeVectMask`, then the crash can happen when the compiler try to decide the final type of the `PhiNode`. Please correct me if I misunderstand it. Thanks!

Hi @XiaohongGong,

There could be a problem during scalarize_vbox_node if vector type of mask VectorBoxNode is made as TypeVectMask
https://github.com/jatin-bhateja/panama-vector/blob/628dc716b3f171e1b7b62fd1ec452a3d14a04af9/src/hotspot/share/opto/vector.cpp#L212

There is an ideal transformation which re-associates the Phi node having all its inputs as VectorBoxes of same type.
https://github.com/openjdk/panama-vector/blob/vectorIntrinsics%2Bmask/src/hotspot/share/opto/cfgnode.cpp#L2413

This can lead to a situation where PhiNode is created with TypeVect and inputs are of TypeVectMask, as a workaround I added another transformation which adjusts to bottom type of PhiNode to match with the bottom type of its inputs (TypeVectMask). This change is in my local repo having other masking changes.
https://github.com/jatin-bhateja/panama-vector/blob/JDK-8262356_vectorIntrinsics%2Bmask/src/hotspot/share/opto/cfgnode.cpp#L2433

-------------

PR: https://git.openjdk.java.net/panama-vector/pull/78

From github.com+12941506+leerho at openjdk.java.net  Wed Jun 23 16:25:49 2021
From: github.com+12941506+leerho at openjdk.java.net (Lee Rhodes)
Date: Wed, 23 Jun 2021 16:25:49 GMT
Subject: [foreign-memaccess+abi] RFR: Add support for high-level functions
 to copy to and from Java arrays [v2]
In-Reply-To: <4bYiuoYZ-y77NBW0oVjeuiFRpuPe8vbPbOvnC7uNpDU=.3a994259-bee5-4701-aa8c-3850677515d2@github.com>
References: 
 
 
 
 <10cvYVltDoxt70qJCjJr17EotPPGBY8Wiytk6GFV2Gk=.3a027fcb-b851-4b97-afa9-91d964d6b848@github.com>
 <4bYiuoYZ-y77NBW0oVjeuiFRpuPe8vbPbOvnC7uNpDU=.3a994259-bee5-4701-aa8c-3850677515d2@github.com>
Message-ID: <9JMcM6WzJlUPJF96Kw1-1vyC7_33p2nnDHddwsTe2_g=.40dff81f-140b-40dd-bc88-96f38c07f591@github.com>

On Tue, 22 Jun 2021 02:37:00 GMT, Jorn Vernee  wrote:

>> I think what you are seeing the extra copy is in the creation of the `truthSegment`, where an extra copy had to be used because there is no API (yet), to help the code determine which direction the copy should be performed in a self-copy scenario.  If the call to the MemoryCopy API does not perform the self-copy correctly, comparing its result with the `truthSegment` will definitely reveal an error.
>
> Actually, I'm talking about the call to toArray here (as well as for CopyTo): 
> 
> 
> ByteOrder bo = mode.swap ? NON_NATIVE_ORDER : NATIVE_ORDER;
> //CopyFrom
> Object srcArr = helper.toArray(base); // <---------------------
> int srcIndex = mode.direction ? 0 : indexShifts;
> int srcCopyLen = helper.length(srcArr) - indexShifts;
> 
> 
> This call to `toArray` ends of calling one of the `MemorySegment::to*Array` methods, which always copy the contents of the segment into a new array.

The claim (wrt overlapping copies) is critical for successful use of the MemoryCopy methods and must be tested.  The claim is similar to the one for System.arrayCopy(...) and to the current MemorySegment.copyFrom(...).   If executed correctly the overlapping copy operation can be done without having to create an additional buffer.  This is important for performance and memory utilization.  

The design of the test for this claim involves a self-copy of a small segment of 32 bytes to itself.  

First, a copy UP operation copies the first 24 bytes to the last 24 bytes, which is a shift up of 8 bytes.  The result is tested against a manually created "truth" segment, which is what the result should look like.  

Second, a copy DOWN operation copies the last 24 bytes to the first 24 bytes, which is a shift down of 8 bytes.  The result is tested against a "truth" segment for this test.

These basic two tests are then repeated for all the variations of primitive type, copyToArray(), copyFromArray(), and additionally with non aligned shifts of 7 bytes instead of 8.

With respect to your concern that these tests are not actually self-copies but copies between disjoint segments, I would posit that these are actually self-copies.  

In the "CopyFrom" tests, a `srcArr` is created with a sequence of values. The `dstSeg` is created from the `srcArr` using `MemorySegment.ofArray(srcArr)`, which is a just a view of the `srcArr`.  Since any change in `dstSeg` also changes `srcArr` and visa versa, they cannot be disjoint.

The test then calls MemoryCopy.copyFromArray(srcArr,...,..., dstSeg, ...), followed by an assertion.

The "CopyTo" tests are very similar and also disjoint. 

I hope this addresses your concern.

-------------

PR: https://git.openjdk.java.net/panama-foreign/pull/555

From github.com+12941506+leerho at openjdk.java.net  Wed Jun 23 16:25:49 2021
From: github.com+12941506+leerho at openjdk.java.net (Lee Rhodes)
Date: Wed, 23 Jun 2021 16:25:49 GMT
Subject: [foreign-memaccess+abi] RFR: Add support for high-level functions
 to copy to and from Java arrays [v2]
In-Reply-To: 
References: 
 
Message-ID: <_ZWrkebANNfY0VjtNbaS8Vb-VpcJ-ivOFKq_1Rm1LUs=.e1674ef9-d0d4-4057-882b-5ca70a03f7be@github.com>

On Mon, 21 Jun 2021 15:38:35 GMT, Maurizio Cimadamore  wrote:

>> This patch includes some of the changes from Lee to support a set of static functions to allow bulk copy from Java arrays to segments (and viceversa) in a more succint fashion (so that the user doesn't have to create a temporary heap segment to do the copy).
>> 
>> I've added a new public method to `MemorySegment` which performs an *element-wise* bulk copy; it takes a source segment and a couple of element layouts: the source element layout and the destination element layout. The two layouts must have same size, but can have different alignments (which will be checked against the corresponding segments) and byte orders. If the byte order differs, a bulk copy with swap will be performed. As such, this method generalizes the previous `copyFrom` - as follows:
>> 
>> 
>> copyFrom(srcSegment) -> copyFrom(JAVA_BYTE, srcSegment, JAVA_BYTE)
>> 
>> I've added support for argument type profiling for MemoryCopy static methods to avoid type pollution in cases where same metod is called with different memory segment types.
>> 
>> I've done a pass over the javadoc, and make it more consistent with the rest of the API. I've also reworked the test a bit to use the data provider functionality of TestNG, since all the test cases were similar, except for the carrier type.
>> 
>> There are other cosmetic changes as well, compared to original code from Lee, such as naming of static fields which is now capitalized. Everything else is the same.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove alignment constraints from MemoryCopy layouts

Marked as reviewed by leerho at github.com (no known OpenJDK username).

-------------

PR: https://git.openjdk.java.net/panama-foreign/pull/555

From github.com+12941506+leerho at openjdk.java.net  Wed Jun 23 16:25:50 2021
From: github.com+12941506+leerho at openjdk.java.net (Lee Rhodes)
Date: Wed, 23 Jun 2021 16:25:50 GMT
Subject: [foreign-memaccess+abi] RFR: Add support for high-level functions
 to copy to and from Java arrays [v2]
In-Reply-To: <9JMcM6WzJlUPJF96Kw1-1vyC7_33p2nnDHddwsTe2_g=.40dff81f-140b-40dd-bc88-96f38c07f591@github.com>
References: 
 
 
 
 <10cvYVltDoxt70qJCjJr17EotPPGBY8Wiytk6GFV2Gk=.3a027fcb-b851-4b97-afa9-91d964d6b848@github.com>
 <4bYiuoYZ-y77NBW0oVjeuiFRpuPe8vbPbOvnC7uNpDU=.3a994259-bee5-4701-aa8c-3850677515d2@github.com>
 <9JMcM6WzJlUPJF96Kw1-1vyC7_33p2nnDHddwsTe2_g=.40dff81f-140b-40dd-bc88-96f38c07f591@github.com>
Message-ID: 

On Tue, 22 Jun 2021 18:18:43 GMT, Lee Rhodes  wrote:

>> Actually, I'm talking about the call to toArray here (as well as for CopyTo): 
>> 
>> 
>> ByteOrder bo = mode.swap ? NON_NATIVE_ORDER : NATIVE_ORDER;
>> //CopyFrom
>> Object srcArr = helper.toArray(base); // <---------------------
>> int srcIndex = mode.direction ? 0 : indexShifts;
>> int srcCopyLen = helper.length(srcArr) - indexShifts;
>> 
>> 
>> This call to `toArray` ends of calling one of the `MemorySegment::to*Array` methods, which always copy the contents of the segment into a new array.
>
> The claim (wrt overlapping copies) is critical for successful use of the MemoryCopy methods and must be tested.  The claim is similar to the one for System.arrayCopy(...) and to the current MemorySegment.copyFrom(...).   If executed correctly the overlapping copy operation can be done without having to create an additional buffer.  This is important for performance and memory utilization.  
> 
> The design of the test for this claim involves a self-copy of a small segment of 32 bytes to itself.  
> 
> First, a copy UP operation copies the first 24 bytes to the last 24 bytes, which is a shift up of 8 bytes.  The result is tested against a manually created "truth" segment, which is what the result should look like.  
> 
> Second, a copy DOWN operation copies the last 24 bytes to the first 24 bytes, which is a shift down of 8 bytes.  The result is tested against a "truth" segment for this test.
> 
> These basic two tests are then repeated for all the variations of primitive type, copyToArray(), copyFromArray(), and additionally with non aligned shifts of 7 bytes instead of 8.
> 
> With respect to your concern that these tests are not actually self-copies but copies between disjoint segments, I would posit that these are actually self-copies.  
> 
> In the "CopyFrom" tests, a `srcArr` is created with a sequence of values. The `dstSeg` is created from the `srcArr` using `MemorySegment.ofArray(srcArr)`, which is a just a view of the `srcArr`.  Since any change in `dstSeg` also changes `srcArr` and visa versa, they cannot be disjoint.
> 
> The test then calls MemoryCopy.copyFromArray(srcArr,...,..., dstSeg, ...), followed by an assertion.
> 
> The "CopyTo" tests are very similar and also disjoint. 
> 
> I hope this addresses your concern.

Typo: "The "CopyTo" tests are very similar and also self copies.  :)

-------------

PR: https://git.openjdk.java.net/panama-foreign/pull/555

From mail at smogura.eu  Wed Jun 23 18:41:20 2021
From: mail at smogura.eu (=?windows-1250?Q?Rados=B3aw_Smogura?=)
Date: Wed, 23 Jun 2021 18:41:20 +0000
Subject: Foreign + Vectors - benchmarks for copying and swapping
In-Reply-To: <5E9D6923-BFF9-4D29-B721-97D56A6BF031@oracle.com>
References: 
 
 <5290e44a-7c67-6ee6-57dc-9af646604082@oracle.com>
 
 <1a23ee05-f187-e6d8-900e-62e77cd73dc9@oracle.com>
 <0DE3B831-2C2C-475B-94FC-867039D6AFC4@oracle.com>
 <07ccd69f-d218-15da-1b71-7dcaa767a7be@oracle.com>
 <9989FFC5-6D13-4114-B32D-A08D427925D4@oracle.com>
 
 
 <086778CB-EAC3-4A72-A7B5-E5D70522386F@oracle.com>
 <20caf67a-7a73-426b-d1be-39945757c4dc@oracle.com>
 
 ,
 <5E9D6923-BFF9-4D29-B721-97D56A6BF031@oracle.com>
Message-ID: 

Hi Paul,

Can you share a code, I could not unroll loop. I can only eliminate range checks and that's all.

In fact it's bit odd, as the code for loading int and byte vectors looks like same.

I've got few suspicions why ByteBuffer vectors can be harder to optimize:

  *   array length is taken from constant memory
  *   array length is non-negative

Kind regards,
Rado

________________________________
Od: Paul Sandoz 
Wys?ane: wtorek, 22 czerwca 2021 22:29
Do: Rados?aw Smogura 
DW: Maurizio Cimadamore ; Vladimir Ivanov ; panama-dev at openjdk.java.net 
Temat: Re: Foreign + Vectors - benchmarks for copying and swapping

In general that should be ok. Try using IntVector instead and it will unroll (with your patch removing CPU barriers)

I wonder if this may be a limitation specific to bytes.

Paul.

> On Jun 21, 2021, at 4:28 PM, Rados?aw Smogura  wrote:
>
> Hi,
>
> I think why the copy case may fail with unrolling, because
>        ? loop unroll takes the range check from intoByteBuffer as the loop exit condition
>        ? the range check uses unsigned compare, which is not supported by loop unroll
>
> I think in this code
>         for (int i = 0; i < bound; i += lanes) {
>           final var srcVector = ByteVector
>               .fromByteBuffer(BYTE_VECTOR_SPECIES, src, i, ByteOrder.nativeOrder());
>
>           srcVector.intoByteBuffer(dst, i, ByteOrder.nativeOrder());
>         }
> exit condition should be i < bound, not a range check from intoByteBuffer.
>
> Kind regards,
> Rado
>
> Od: Paul Sandoz 
> Wys?ane: poniedzia?ek, 21 czerwca 2021 23:25
> Do: Maurizio Cimadamore 
> DW: Rados?aw Smogura ; Vladimir Ivanov ; panama-dev at openjdk.java.net 
> Temat: Re: Foreign + Vectors - benchmarks for copying and swapping
>
> Replacing the upper bound in `segmentImplicitScalar` with a constant (1024 say) results in a similar time to `bufferNativeScalar` without a constant bound, both of which (alas) are still slower that scalar array access (which benefits greatly from auto-vectorization).
>
> I wonder if the segment subrange checking for int value ranges is having an impact on bounds checking?
>
> Paul.
>
> > On Jun 21, 2021, at 1:56 PM, Maurizio Cimadamore  wrote:
> >
> >
> > On 21/06/2021 20:33, Paul Sandoz wrote:
> >> - Segment scalar access is penalized compared to ByteBuffer (from allocate or allocateDirect) scalar access.
> >
> > Odd
> >
> > We have many benchmarks similar to this (see LoopOverNonConstant) and they seem to offer same level of performance compared with ByteBuffers.
> >
> > I wonder if the loop limit being "SPECIES.loopBound(srcArray.length)" plays a role? Have you tried replacing that expression with a constant?
> >
> > Maurizio
> >


From jvernee at openjdk.java.net  Wed Jun 23 19:42:48 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 23 Jun 2021 19:42:48 GMT
Subject: [foreign-memaccess+abi] RFR: Add support for high-level functions
 to copy to and from Java arrays [v2]
In-Reply-To: 
References: 
 
 
 
 <10cvYVltDoxt70qJCjJr17EotPPGBY8Wiytk6GFV2Gk=.3a027fcb-b851-4b97-afa9-91d964d6b848@github.com>
 <4bYiuoYZ-y77NBW0oVjeuiFRpuPe8vbPbOvnC7uNpDU=.3a994259-bee5-4701-aa8c-3850677515d2@github.com>
 <9JMcM6WzJlUPJF96Kw1-1vyC7_33p2nnDHddwsTe2_g=.40dff81f-140b-40dd-bc88-96f38c07f591@github.com>
 
Message-ID: 

On Tue, 22 Jun 2021 21:57:48 GMT, Lee Rhodes  wrote:

>> The claim (wrt overlapping copies) is critical for successful use of the MemoryCopy methods and must be tested.  The claim is similar to the one for System.arrayCopy(...) and to the current MemorySegment.copyFrom(...).   If executed correctly the overlapping copy operation can be done without having to create an additional buffer.  This is important for performance and memory utilization.  
>> 
>> The design of the test for this claim involves a self-copy of a small segment of 32 bytes to itself.  
>> 
>> First, a copy UP operation copies the first 24 bytes to the last 24 bytes, which is a shift up of 8 bytes.  The result is tested against a manually created "truth" segment, which is what the result should look like.  
>> 
>> Second, a copy DOWN operation copies the last 24 bytes to the first 24 bytes, which is a shift down of 8 bytes.  The result is tested against a "truth" segment for this test.
>> 
>> These basic two tests are then repeated for all the variations of primitive type, copyToArray(), copyFromArray(), and additionally with non aligned shifts of 7 bytes instead of 8.
>> 
>> With respect to your concern that these tests are not actually self-copies but copies between disjoint segments, I would posit that these are actually self-copies.  
>> 
>> In the "CopyFrom" tests, a `srcArr` is created with a sequence of values. The `dstSeg` is created from the `srcArr` using `MemorySegment.ofArray(srcArr)`, which is a just a view of the `srcArr`.  Since any change in `dstSeg` also changes `srcArr` and visa versa, they cannot be disjoint.
>> 
>> The test then calls MemoryCopy.copyFromArray(srcArr,...,..., dstSeg, ...), followed by an assertion.
>> 
>> The "CopyTo" tests are very similar and also disjoint. 
>> 
>> I hope this addresses your concern.
>
> Typo: "The "CopyTo" tests are very similar and also self copies.  :)

You're right, I seem to have misread the code earlier. For some reason I thought a copy to/from the `srcArr` to/from the `base` segment was happening, but looking at it now, I can see it's doing as you describe. Sorry.

-------------

PR: https://git.openjdk.java.net/panama-foreign/pull/555

From paul.sandoz at oracle.com  Wed Jun 23 20:32:09 2021
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 23 Jun 2021 20:32:09 +0000
Subject: Foreign + Vectors - benchmarks for copying and swapping
In-Reply-To: 
References: 
 
 <5290e44a-7c67-6ee6-57dc-9af646604082@oracle.com>
 
 <1a23ee05-f187-e6d8-900e-62e77cd73dc9@oracle.com>
 <0DE3B831-2C2C-475B-94FC-867039D6AFC4@oracle.com>
 <07ccd69f-d218-15da-1b71-7dcaa767a7be@oracle.com>
 <9989FFC5-6D13-4114-B32D-A08D427925D4@oracle.com>
 
 
 <086778CB-EAC3-4A72-A7B5-E5D70522386F@oracle.com>
 <20caf67a-7a73-426b-d1be-39945757c4dc@oracle.com>
 
 
 <5E9D6923-BFF9-4D29-B721-97D56A6BF031@oracle.com>
 
Message-ID: <68D8C805-A982-4C4D-9274-E128A6ED1206@oracle.com>

Here you go:

https://gist.github.com/PaulSandoz/7d95a4d9b99b5f9f9c6326f65a4d77c8

Details in comments at the end.

Paul.

> On Jun 23, 2021, at 11:41 AM, Rados?aw Smogura  wrote:
> 
> Hi Paul,
> 
> Can you share a code, I could not unroll loop. I can only eliminate range checks and that's all.
> 
> In fact it's bit odd, as the code for loading int and byte vectors looks like same.
> 
> I've got few suspicions why ByteBuffer vectors can be harder to optimize:
> 	? array length is taken from constant memory
> 	? array length is non-negative
> 
> Kind regards,
> Rado
> 
> Od: Paul Sandoz 
> Wys?ane: wtorek, 22 czerwca 2021 22:29
> Do: Rados?aw Smogura 
> DW: Maurizio Cimadamore ; Vladimir Ivanov ; panama-dev at openjdk.java.net 
> Temat: Re: Foreign + Vectors - benchmarks for copying and swapping
>  
> In general that should be ok. Try using IntVector instead and it will unroll (with your patch removing CPU barriers)
> 
> I wonder if this may be a limitation specific to bytes. 
> 
> Paul.
> 
> > On Jun 21, 2021, at 4:28 PM, Rados?aw Smogura  wrote:
> > 
> > Hi,
> > 
> > I think why the copy case may fail with unrolling, because
> >        ? loop unroll takes the range check from intoByteBuffer as the loop exit condition
> >        ? the range check uses unsigned compare, which is not supported by loop unroll
> > 
> > I think in this code
> >         for (int i = 0; i < bound; i += lanes) {
> >           final var srcVector = ByteVector
> >               .fromByteBuffer(BYTE_VECTOR_SPECIES, src, i, ByteOrder.nativeOrder());
> > 
> >           srcVector.intoByteBuffer(dst, i, ByteOrder.nativeOrder());
> >         }
> > exit condition should be i < bound, not a range check from intoByteBuffer.
> > 
> > Kind regards,
> > Rado
> > 
> > Od: Paul Sandoz 
> > Wys?ane: poniedzia?ek, 21 czerwca 2021 23:25
> > Do: Maurizio Cimadamore 
> > DW: Rados?aw Smogura ; Vladimir Ivanov ; panama-dev at openjdk.java.net 
> > Temat: Re: Foreign + Vectors - benchmarks for copying and swapping
> >  
> > Replacing the upper bound in `segmentImplicitScalar` with a constant (1024 say) results in a similar time to `bufferNativeScalar` without a constant bound, both of which (alas) are still slower that scalar array access (which benefits greatly from auto-vectorization).
> > 
> > I wonder if the segment subrange checking for int value ranges is having an impact on bounds checking?
> > 
> > Paul.
> > 
> > > On Jun 21, 2021, at 1:56 PM, Maurizio Cimadamore  wrote:
> > > 
> > > 
> > > On 21/06/2021 20:33, Paul Sandoz wrote:
> > >> - Segment scalar access is penalized compared to ByteBuffer (from allocate or allocateDirect) scalar access.
> > > 
> > > Odd
> > > 
> > > We have many benchmarks similar to this (see LoopOverNonConstant) and they seem to offer same level of performance compared with ByteBuffers.
> > > 
> > > I wonder if the loop limit being "SPECIES.loopBound(srcArray.length)" plays a role? Have you tried replacing that expression with a constant?
> > > 
> > > Maurizio
> > > 


From mail at smogura.eu  Wed Jun 23 22:23:11 2021
From: mail at smogura.eu (=?windows-1250?Q?Rados=B3aw_Smogura?=)
Date: Wed, 23 Jun 2021 22:23:11 +0000
Subject: ODP: Foreign + Vectors - benchmarks for copying and swapping
In-Reply-To: <68D8C805-A982-4C4D-9274-E128A6ED1206@oracle.com>
References: 
 
 <5290e44a-7c67-6ee6-57dc-9af646604082@oracle.com>
 
 <1a23ee05-f187-e6d8-900e-62e77cd73dc9@oracle.com>
 <0DE3B831-2C2C-475B-94FC-867039D6AFC4@oracle.com>
 <07ccd69f-d218-15da-1b71-7dcaa767a7be@oracle.com>
 <9989FFC5-6D13-4114-B32D-A08D427925D4@oracle.com>
 
 
 <086778CB-EAC3-4A72-A7B5-E5D70522386F@oracle.com>
 <20caf67a-7a73-426b-d1be-39945757c4dc@oracle.com>
 
 
 <5E9D6923-BFF9-4D29-B721-97D56A6BF031@oracle.com>
 ,
 <68D8C805-A982-4C4D-9274-E128A6ED1206@oracle.com>
Message-ID: 

Hi Paul,

Thank you.

I checked with LongVector and got same results as int (4x loop unroll). With short vector I could not unroll. I only focused on method bufferHeap.

Kind regards,
Rado

________________________________
Od: Paul Sandoz 
Wys?ane: ?roda, 23 czerwca 2021 22:32
Do: Rados?aw Smogura 
DW: Maurizio Cimadamore ; Vladimir Ivanov ; panama-dev at openjdk.java.net 
Temat: Re: Foreign + Vectors - benchmarks for copying and swapping

Here you go:

https://gist.github.com/PaulSandoz/7d95a4d9b99b5f9f9c6326f65a4d77c8

Details in comments at the end.

Paul.

> On Jun 23, 2021, at 11:41 AM, Rados?aw Smogura  wrote:
>
> Hi Paul,
>
> Can you share a code, I could not unroll loop. I can only eliminate range checks and that's all.
>
> In fact it's bit odd, as the code for loading int and byte vectors looks like same.
>
> I've got few suspicions why ByteBuffer vectors can be harder to optimize:
>        ? array length is taken from constant memory
>        ? array length is non-negative
>
> Kind regards,
> Rado
>
> Od: Paul Sandoz 
> Wys?ane: wtorek, 22 czerwca 2021 22:29
> Do: Rados?aw Smogura 
> DW: Maurizio Cimadamore ; Vladimir Ivanov ; panama-dev at openjdk.java.net 
> Temat: Re: Foreign + Vectors - benchmarks for copying and swapping
>
> In general that should be ok. Try using IntVector instead and it will unroll (with your patch removing CPU barriers)
>
> I wonder if this may be a limitation specific to bytes.
>
> Paul.
>
> > On Jun 21, 2021, at 4:28 PM, Rados?aw Smogura  wrote:
> >
> > Hi,
> >
> > I think why the copy case may fail with unrolling, because
> >        ? loop unroll takes the range check from intoByteBuffer as the loop exit condition
> >        ? the range check uses unsigned compare, which is not supported by loop unroll
> >
> > I think in this code
> >         for (int i = 0; i < bound; i += lanes) {
> >           final var srcVector = ByteVector
> >               .fromByteBuffer(BYTE_VECTOR_SPECIES, src, i, ByteOrder.nativeOrder());
> >
> >           srcVector.intoByteBuffer(dst, i, ByteOrder.nativeOrder());
> >         }
> > exit condition should be i < bound, not a range check from intoByteBuffer.
> >
> > Kind regards,
> > Rado
> >
> > Od: Paul Sandoz 
> > Wys?ane: poniedzia?ek, 21 czerwca 2021 23:25
> > Do: Maurizio Cimadamore 
> > DW: Rados?aw Smogura ; Vladimir Ivanov ; panama-dev at openjdk.java.net 
> > Temat: Re: Foreign + Vectors - benchmarks for copying and swapping
> >
> > Replacing the upper bound in `segmentImplicitScalar` with a constant (1024 say) results in a similar time to `bufferNativeScalar` without a constant bound, both of which (alas) are still slower that scalar array access (which benefits greatly from auto-vectorization).
> >
> > I wonder if the segment subrange checking for int value ranges is having an impact on bounds checking?
> >
> > Paul.
> >
> > > On Jun 21, 2021, at 1:56 PM, Maurizio Cimadamore  wrote:
> > >
> > >
> > > On 21/06/2021 20:33, Paul Sandoz wrote:
> > >> - Segment scalar access is penalized compared to ByteBuffer (from allocate or allocateDirect) scalar access.
> > >
> > > Odd
> > >
> > > We have many benchmarks similar to this (see LoopOverNonConstant) and they seem to offer same level of performance compared with ByteBuffers.
> > >
> > > I wonder if the loop limit being "SPECIES.loopBound(srcArray.length)" plays a role? Have you tried replacing that expression with a constant?
> > >
> > > Maurizio
> > >


From xgong at openjdk.java.net  Thu Jun 24 02:32:49 2021
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Thu, 24 Jun 2021 02:32:49 GMT
Subject: [vectorIntrinsics+mask] RFR: 8266287: Basic mask IR
 implementation for the Vector API masking feature support [v3]
In-Reply-To: <0sl3asXrMktJnN-KWK3FBrdfdzKajBSXxam8NS-W5Pc=.feebc515-d2b5-4b80-8998-382d0c3f188e@github.com>
References: 
 
 
 
 
 
 
 <8-pvCxVmC9fKfFFDOXuyFYvNRigJklNhyUhYrOsaHq0=.38973d62-9199-4881-ae4b-1eb3bfd9d2dd@github.com>
 <-72e7vhhu1yU2U9b6Ft2j7nwRFc6egbjxXRu3pJVees=.048de98a-0da1-4701-8964-868e88a2f715@github.com>
 <0sl3asXrMktJnN-KWK3FBrdfdzKajBSXxam8NS-W5Pc=.feebc515-d2b5-4b80-8998-382d0c3f188e@github.com>
Message-ID: <9iQ2qYidA4YnP74ghLiik18CZ3xmkWUvGEeFUUxk7JU=.31418490-7bd6-49ed-873b-01c5f62e10ca@github.com>

On Wed, 23 Jun 2021 12:55:02 GMT, Jatin Bhateja  wrote:

> There could be a problem during scalarize_vbox_node if vector type of mask VectorBoxNode is made as TypeVectMask
https://github.com/jatin-bhateja/panama-vector/blob/628dc716b3f171e1b7b62fd1ec452a3d14a04af9/src/hotspot/share/opto/vector.cpp#L212

I think the main issues that I met are related to `VectorUnboxNode` while not `VectorBoxNode`.  BTW, the bottom type of `VectorBoxNode` is the box type while not the vector type. I'm sorry that I cannot see the influence whether the vector type is a `TypeVect` or `TypeVectMask` for it. Could you please kindly elaborate more about this? 

>From my side, setting the `TypeVect` to `VectorBoxNode` might be ok, but how about the `VectorUnboxNode` ? I think they should keep the same with each other?

-------------

PR: https://git.openjdk.java.net/panama-vector/pull/78

From njian at openjdk.java.net  Thu Jun 24 02:34:56 2021
From: njian at openjdk.java.net (Ningsheng Jian)
Date: Thu, 24 Jun 2021 02:34:56 GMT
Subject: [vectorIntrinsics] RFR: 8269264: Some more cleanups for Vector API
 SVE support
Message-ID: 

Some more vectorIntrinsics SVE codegen cleanups for preparing a further
review patch in jdk mainline. This change includes:

1. Incorporate changes while preparing jdk mainline PR [1], which
includes some minor style changes and extending SVE vector size to
support 8 bytes to achieve better performance for *64Vector operations
and shuffles.
2. Fix register effects in some VectorCast rules, spotted by @XiaohongGong,
to avoid register reuse problem.
3. Merge reduction rules, as of what have been done for partial sizes.
4. Sort VectorCast rules by types/names for easier review.
5. Move sve_compare() from ad file to c2_MacroAssembler just as
recently added neon_compare().

[1] https://github.com/openjdk/jdk/pull/4122

-------------

Commit messages:
 - 8269264: Some more cleanups for Vector API SVE support

Changes: https://git.openjdk.java.net/panama-vector/pull/94/files
 Webrev: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=94&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269264
  Stats: 1942 lines in 7 files changed: 492 ins; 923 del; 527 mod
  Patch: https://git.openjdk.java.net/panama-vector/pull/94.diff
  Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/94/head:pull/94

PR: https://git.openjdk.java.net/panama-vector/pull/94

From jbhateja at openjdk.java.net  Thu Jun 24 05:12:47 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Thu, 24 Jun 2021 05:12:47 GMT
Subject: [vectorIntrinsics+mask] RFR: 8266287: Basic mask IR
 implementation for the Vector API masking feature support [v3]
In-Reply-To: 
References: 
 <-H3L1H_i6wkKkWsHNLnZUSnirwYNdwXfcVV8VCrFsic=.e96337d8-d361-4d71-902e-156d2ea46d5b@github.com>
 
Message-ID: 

On Mon, 17 May 2021 04:04:03 GMT, Xiaohong Gong  wrote:

> > Can you elaborate, please, what's the purpose of new nodes?
> > There's some duplication with existing vector nodes and I'd like to understand how do you intend to merge them.
> 
> Sure. I added some new nodes for the vector mask generations and operations. Their bottom type are the new added mask type `TypeVectMask`. These nodes are created only for platforms that support predicate feature. For other platforms, it still uses the existing vector nodes (with `TypeVect `as the bottom type) for masks. An alternative solution for the mask IRs is to use the same vector nodes by setting different bottom types for platforms that support predicate feature and others. To make it not mixture with the vector operations, we choose to separate the mask with vectors by adding new nodes.
> 
> > `LoadVectorMask`/`StoreVectorMask` duplicate `VectorLoadMask (LoadVector)`/`StoreVector (VectorStoreMask)`. What kind of benefits do you expect from exposing the operation as a single node?
> > Depending on how `MaskToVector`/`VectorToMask` are specified, they can duplicate `VectorStoreMask`/`VectorLoadMask`.
> 
> We added the transformation for mask loading/storing: `VectorLoadMask (LoadVector)`/`StoreVector (VectorStoreMask)` ==> `LoadVectorMask`/`StoreVectorMask`. To be honest, this seems only benefit Arm SVE. Different with AVX-512, SVE predicate works based on the basic element type. Since the memory type for mask is `boolean`, while the vector data type might be `byte, short, int, long, float, double`, we always need to unpack the boolean values to the relative data types when converting vector mask to predicate. So the SVE codes for `VectorLoadMask (LoadVector)` with int type is:
> 
> ```
>   mov x0, #64
>   whilelo p0.b, zr, x0
>   ld1b  z16.b, p0, [address]   // LoadVector  (since the mask vector length is less than the max vector length,
>                                // we need the predicate to implement the partial loading)
> 
>   uunpklo z16.h, z16.h
>   uunpklo z16.s, z16.s         // VectorLoadMask
>   cmpne  p0.s, z16.s, #0       // VectorToMask
> ```
> 
> Since SVE supports the load extended instruction, we can use one node `LoadVectorMask` to load the mask values from memory and extend the values to the data type. The above codes could be optimized to:
> 
> ```
>   ld1b  z16.s, p7, [address]   // LoadVectorMask  (load mask values from boolean type memory, and extends the values to int type)
>   cmpne p0.s, z16.s, #0        // VectorToMask
> ```
> 
> Note that `MaskToVector`/`VectorToMask` are different with `VectorStoreMask`/`VectorLoadMask`, which only simply do the convertions between mask and vector with the same element type, while `VectorStoreMask`/`VectorLoadMask` must contain the type casting between mask and vector which is also needed for SVE.
> 
> Although the existing pattern can work well for AVX-512. Is it possible to use the same optimized pattern for it as well @jatin-bhateja ?
> 

Hi @XiaohongGong , I just missed noticing this query earlier,  apologies!,   I think VectorLoadMask and VectorStoreMask serves the purpose to load/store a raw mask (boolean array)  from/to a vector/predicated register.  An explicit mask casting IR (VectorMaskCastNode) has been introduced recently which can be plugged after loading mask value if casting is needed.

As you mentioned there is a little  use for LoadVectorMask/StoreVectorMask from X86 prespective.

> > If mask value always has a vector type,`AndVMask`/`OrVMask`/`XorVMask` can be replaced by `AndV`/`OrV`/`XorV` and special implementations for 2 representations (canonical and native). Same considerations apply to `VectorCmpMaskGen` (compared to `VectorMaskCmp`).
> 
> We added `AndVMask`/`OrVMask`/`XorVMask` for mask logical operations finally to separate with the vector logical operations. It might be confusing if `AndV`/`OrV`/`XorV` could might be `TypeVect ` or `TypeMaskVect ` for the same plaftform.
> 
> As a conclusion, actually we are not sure what is the best optimal way to represent the mask operations, but we prefer to new mask IRs (definitely with `TypeVectMask`) for all mask operations while not just change the bottom type of the existing vector nodes. Any ideas about it? It will be absolutely helpful if you could give us more advice. Thanks so much!

-------------

PR: https://git.openjdk.java.net/panama-vector/pull/78

From jbhateja at openjdk.java.net  Thu Jun 24 05:17:37 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Thu, 24 Jun 2021 05:17:37 GMT
Subject: [vectorIntrinsics+mask] RFR: 8268154: Add masking support for
 vector load intrinsics [v2]
In-Reply-To: 
References: 
 
 
 
Message-ID: <8pC-fFZArqVo2xwJa5AdkLk0EerlknXWv4fJgGpRGZc=.9d711656-b992-4b98-92c8-617aa6d590f3@github.com>

On Fri, 11 Jun 2021 09:36:31 GMT, Xiaohong Gong  wrote:

>> Thanks!, changes looks good to me.
>
> Thanks for the review @jatin-bhateja @PaulSandoz !

Hi @XiaohongGong , can you kindly push these common IR changes

-------------

PR: https://git.openjdk.java.net/panama-vector/pull/90

From xgong at openjdk.java.net  Thu Jun 24 06:08:53 2021
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Thu, 24 Jun 2021 06:08:53 GMT
Subject: [vectorIntrinsics+mask] RFR: 8268154: Add masking support for
 vector load intrinsics [v2]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Fri, 11 Jun 2021 09:36:31 GMT, Xiaohong Gong  wrote:

>> Thanks!, changes looks good to me.
>
> Thanks for the review @jatin-bhateja @PaulSandoz !

> Hi @XiaohongGong , can you kindly push these common IR changes

Sure. I was intending to wait for the feedback from @iwanowww . Maybe it's better to integrate these changes first to make sure the masking feature support is not blocked. Thanks so much for the advice and review!

@iwanowww , I'd like to integrate this PR first. If there are any comments or feedback, please feel free to contact me and we can revisit them with a followed-up patch. Thanks so much!

-------------

PR: https://git.openjdk.java.net/panama-vector/pull/90

From xgong at openjdk.java.net  Thu Jun 24 06:08:54 2021
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Thu, 24 Jun 2021 06:08:54 GMT
Subject: [vectorIntrinsics+mask] Integrated: 8268154: Add masking support for
 vector load intrinsics
In-Reply-To: 
References: 
Message-ID: 

On Mon, 7 Jun 2021 09:05:44 GMT, Xiaohong Gong  wrote:

> This patch adds the predicate support for masked load vector operation, including the Vector API java implementation and hotspot intrinsics changes. The main changes contain:
>   - Adding a new hotspot intrinsic method (`loadMasked`), which can transform the vector mask class and value to hotspot. It is called by the masked `"fromArray"` API in JAVA level. The compiler will generate the masked vector load node if the current platform supports the predicate feature and backend has implemented it. Otherwise, the vector blend pattern will be generated like before.
>   - Adding the similar masked support for load/store boolean/char array.
> 
> Note that the intrinsification when there is the array range bailout is not implemented in this patch. We are considering making it vectorized with predicate feature for SVE/AVX-512 as well, and will create a separate patch for it in future.
> 
> Also note that this patch doesn't contain any backend changes.

This pull request has now been integrated.

Changeset: 1c913048
Author:    Xiaohong Gong 
URL:       https://git.openjdk.java.net/panama-vector/commit/1c913048a9150e8e8d43844349157a10199311be
Stats:     904 lines in 44 files changed: 820 ins; 42 del; 42 mod

8268154: Add masking support for vector load intrinsics

Reviewed-by: jbhateja, psandoz

-------------

PR: https://git.openjdk.java.net/panama-vector/pull/90

From xgong at openjdk.java.net  Thu Jun 24 06:13:43 2021
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Thu, 24 Jun 2021 06:13:43 GMT
Subject: [vectorIntrinsics+mask] RFR: 8266287: Basic mask IR
 implementation for the Vector API masking feature support [v2]
In-Reply-To: 
References: 
 <0SyBueY0IDncXtoZ8Pc88k-C0-xuqf6_ITo5P_sF1q4=.cffb7d2f-8179-4eda-afb2-e55aa15c148d@github.com>
 
Message-ID: 

On Mon, 21 Jun 2021 09:53:49 GMT, Xiaohong Gong  wrote:

>> Xiaohong Gong has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
>> 
>>  - Use "Flag_is_predicated_vector" for masked vector nodes
>>  - Merge branch 'vectorIntrinsics+mask'
>>  - 8266287: Basic mask IR implementation for the Vector API masking feature support
>
> Hi there, the new commit refines the C2 compiler IRs for vector mask. The main idea is trying to use the same nodes but with
> different types (i.e. use `"TypeVectMask"` for SVE/AVX-512, while `"TypeVect"` for others). It doesn't need to create new IRs specially for SVE/AVX-512 predicate type. The `"idea_reg"` is decided by the type of the node, so that the compiler can choose the right register for vector mask during codegen.
> 
> For more details, the following existed IRs are kept to use normally:
> 
>  - fromArray: LoadVector + VectorLoadMask
>  - compare:   VectorMaskCmp
>  - others:    VectorMaskCast
> 
> And to spearate the IRs for vector and vector mask, the following mask IRs are added:
> 
>  - maskAll:    MaskAll
>  - and/or/xor: AndVMask/OrVMask/XorVMask
> 
> Further more, to improve the performance of vector mask loading/storing with SVE, the following transformations are also kept:
> 
>  - fromArray:
>      LoadVector + VectorLoadMask    ==>  LoadVectorMask
>  - intoArray:
>      VectorStoreMask + StoreVector  ==>  StoreVectorMask
> 
> 
> Any feedback is welcome! Thanks so much!
> 
> Best Regards,
> Xiaohong

> Hi @XiaohongGong , I just missed noticing this query earlier, apologies!, I think VectorLoadMask and VectorStoreMask serves the purpose to load/store a raw mask (boolean array) from/to a vector/predicated register. An explicit mask casting IR (VectorMaskCastNode) has been introduced recently which can be plugged after loading mask value if casting is needed.

It's ok. I think it's ok to use `VectorMaskCastNode` (actually we think this node is more reasonable instead of `VectorLoadMask/VectorStoreMask`). It needs a further consideration for it since we'd better to revisit its usage for all platforms while not only SVE.

-------------

PR: https://git.openjdk.java.net/panama-vector/pull/78

From xgong at openjdk.java.net  Thu Jun 24 06:18:46 2021
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Thu, 24 Jun 2021 06:18:46 GMT
Subject: [vectorIntrinsics] RFR: 8269264: Some more cleanups for Vector
 API SVE support
In-Reply-To: 
References: 
Message-ID: <3cAUXIXNEfco0Xjagrtjbi-MWTQdOcGrF2vK5HgyxW8=.fcef7510-f6f6-48ab-bb04-2073e618c6dd@github.com>

On Thu, 24 Jun 2021 02:29:02 GMT, Ningsheng Jian  wrote:

> Some more vectorIntrinsics SVE codegen cleanups for preparing a further
> review patch in jdk mainline. This change includes:
> 
> 1. Incorporate changes while preparing jdk mainline PR [1], which
> includes some minor style changes and extending SVE vector size to
> support 8 bytes to achieve better performance for *64Vector operations
> and shuffles.
> 2. Fix register effects in some VectorCast rules, spotted by @XiaohongGong,
> to avoid register reuse problem.
> 3. Merge reduction rules, as of what have been done for partial sizes.
> 4. Sort VectorCast rules by types/names for easier review.
> 5. Move sve_compare() from ad file to c2_MacroAssembler just as
> recently added neon_compare().
> 
> [1] https://github.com/openjdk/jdk/pull/4122

Marked as reviewed by xgong (Committer).

LGTM! We have an internal review and all tests pass. Thanks!

-------------

PR: https://git.openjdk.java.net/panama-vector/pull/94

From jbhateja at openjdk.java.net  Thu Jun 24 09:42:41 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Thu, 24 Jun 2021 09:42:41 GMT
Subject: [vectorIntrinsics+mask] RFR: 8266287: Basic mask IR
 implementation for the Vector API masking feature support [v3]
In-Reply-To: <9iQ2qYidA4YnP74ghLiik18CZ3xmkWUvGEeFUUxk7JU=.31418490-7bd6-49ed-873b-01c5f62e10ca@github.com>
References: 
 
 
 
 
 
 
 <8-pvCxVmC9fKfFFDOXuyFYvNRigJklNhyUhYrOsaHq0=.38973d62-9199-4881-ae4b-1eb3bfd9d2dd@github.com>
 <-72e7vhhu1yU2U9b6Ft2j7nwRFc6egbjxXRu3pJVees=.048de98a-0da1-4701-8964-868e88a2f715@github.com>
 <0sl3asXrMktJnN-KWK3FBrdfdzKajBSXxam8NS-W5Pc=.feebc515-d2b5-4b80-8998-382d0c3f188e@github.com>
 <9iQ2qYidA4YnP74ghLiik18CZ3xmkWUvGEe
 FUUxk7JU=.31418490-7bd6-49ed-873b-01c5f62e10ca@github.com>
Message-ID: 

On Thu, 24 Jun 2021 02:29:11 GMT, Xiaohong Gong  wrote:

>> Hi @XiaohongGong,
>> 
>> There could be a problem during scalarize_vbox_node if vector type of mask VectorBoxNode is made as TypeVectMask
>> https://github.com/jatin-bhateja/panama-vector/blob/628dc716b3f171e1b7b62fd1ec452a3d14a04af9/src/hotspot/share/opto/vector.cpp#L212
>> 
>> There is an ideal transformation which re-associates the Phi node having all its inputs as VectorBoxes of same type.
>> https://github.com/openjdk/panama-vector/blob/vectorIntrinsics%2Bmask/src/hotspot/share/opto/cfgnode.cpp#L2413
>> 
>> This can lead to a situation where PhiNode is created with TypeVect and inputs are of TypeVectMask, as a workaround I added another transformation which adjusts to bottom type of PhiNode to match with the bottom type of its inputs (TypeVectMask). This change is in my local repo having other masking changes.
>> https://github.com/jatin-bhateja/panama-vector/blob/JDK-8262356_vectorIntrinsics%2Bmask/src/hotspot/share/opto/cfgnode.cpp#L2433
>
>> There could be a problem during scalarize_vbox_node if vector type of mask VectorBoxNode is made as TypeVectMask
> https://github.com/jatin-bhateja/panama-vector/blob/628dc716b3f171e1b7b62fd1ec452a3d14a04af9/src/hotspot/share/opto/vector.cpp#L212
> 
> I think the main issues that I met are related to `VectorUnboxNode` while not `VectorBoxNode`.  BTW, the bottom type of `VectorBoxNode` is the box type while not the vector type. I'm sorry that I cannot see the influence whether the vector type is a `TypeVect` or `TypeVectMask` for it. Could you please kindly elaborate more about this? 
> 
> From my side, setting the `TypeVect` to `VectorBoxNode` might be ok, but how about the `VectorUnboxNode` ? I think they should keep the same with each other?

Following changes is also altering the vect_type of mask VectorBoxNode.
https://github.com/openjdk/panama-vector/pull/78/files#diff-33d0866101d899687e04303fb2232574f2cb796ce060528a243ebdc9903b01b1R84

-------------

PR: https://git.openjdk.java.net/panama-vector/pull/78

From mcimadamore at openjdk.java.net  Thu Jun 24 09:47:55 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 24 Jun 2021 09:47:55 GMT
Subject: [foreign-memaccess+abi] RFR: Add support for high-level functions
 to copy to and from Java arrays [v2]
In-Reply-To: 
References: 
 
 
 
Message-ID: <_95lPbXeUP08u4iYh0foBDgOGqWGqSbuaJ_fqw8Qbs4=.d547101b-7d2f-4e0d-aac2-8d039c605dbf@github.com>

On Mon, 21 Jun 2021 21:52:18 GMT, Lee Rhodes  wrote:

>> src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemoryCopy.java line 137:
>> 
>>> 135:         MemorySegment srcSegmentSlice =
>>> 136:                 MemorySegment.ofArray(srcArray).asSlice(srcIndexChars * 2L, srcCopyLengthChars * 2L);
>>> 137:         MemorySegment dstSegmentSlice = dstSegment.asSlice(dstOffsetBytes, srcCopyLengthChars * 2L);
>> 
>> Little weird to see `srcCopyLengthChars` being used for the destination slice. But the length is the same for both of course. Maybe just drop the `src` prefix? (it's a nit though).
>
> The variable name `srcCopyLengthChars` is for clarity to the user of the API, who does not see the implementation code. Because there are two different types of units in the method call, one in Chars and one in Bytes, it is important to clarify the units of the measure as well as which of source or destination it is associated with.

Honestly, I tend to agree with Jorn here. In a copy, there is:
* a source (either an array or a segment)
* a source offset (expressed either as element index, or as byte offset)
* a destination (either an array or a segment)
* a destination offset (expressed either as element index, or as byte offset)
* a length (expressed either as number of elements, or as number of bytes)

There's only one length - it's important to distinguish between Chars vs. Bytes - e.g. copyLengthChars vs. copyLengthBytes. But adding the `src` seems confusing because the `length` parameter is, IMHO neutral, and just indicates how many "things" have to be bulk-copied.

In fact, I'll go further and say that, when editing this patch I kept finding the placement of the length argument confusing. Having it as the trailing argument would be clearer IMHO.

-------------

PR: https://git.openjdk.java.net/panama-foreign/pull/555

From mcimadamore at openjdk.java.net  Thu Jun 24 10:07:23 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 24 Jun 2021 10:07:23 GMT
Subject: [foreign-memaccess+abi] RFR: Add support for high-level functions
 to copy to and from Java arrays [v5]
In-Reply-To: 
References: 
Message-ID: 

> This patch includes some of the changes from Lee to support a set of static functions to allow bulk copy from Java arrays to segments (and viceversa) in a more succint fashion (so that the user doesn't have to create a temporary heap segment to do the copy).
> 
> I've added a new public method to `MemorySegment` which performs an *element-wise* bulk copy; it takes a source segment and a couple of element layouts: the source element layout and the destination element layout. The two layouts must have same size, but can have different alignments (which will be checked against the corresponding segments) and byte orders. If the byte order differs, a bulk copy with swap will be performed. As such, this method generalizes the previous `copyFrom` - as follows:
> 
> 
> copyFrom(srcSegment) -> copyFrom(JAVA_BYTE, srcSegment, JAVA_BYTE)
> 
> I've added support for argument type profiling for MemoryCopy static methods to avoid type pollution in cases where same metod is called with different memory segment types.
> 
> I've done a pass over the javadoc, and make it more consistent with the rest of the API. I've also reworked the test a bit to use the data provider functionality of TestNG, since all the test cases were similar, except for the carrier type.
> 
> There are other cosmetic changes as well, compared to original code from Lee, such as naming of static fields which is now capitalized. Everything else is the same.

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  * Add null checks for ByteOrder
  * Beef up test to check for various OOB conditions

-------------

Changes:
  - all: https://git.openjdk.java.net/panama-foreign/pull/555/files
  - new: https://git.openjdk.java.net/panama-foreign/pull/555/files/393ddddc..6c5082a8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=555&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=555&range=03-04

  Stats: 145 lines in 3 files changed: 134 ins; 8 del; 3 mod
  Patch: https://git.openjdk.java.net/panama-foreign/pull/555.diff
  Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/555/head:pull/555

PR: https://git.openjdk.java.net/panama-foreign/pull/555

From paul.sandoz at oracle.com  Thu Jun 24 15:26:50 2021
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 24 Jun 2021 15:26:50 +0000
Subject: Foreign + Vectors - benchmarks for copying and swapping
In-Reply-To: 
References: 
 
 <5290e44a-7c67-6ee6-57dc-9af646604082@oracle.com>
 
 <1a23ee05-f187-e6d8-900e-62e77cd73dc9@oracle.com>
 <0DE3B831-2C2C-475B-94FC-867039D6AFC4@oracle.com>
 <07ccd69f-d218-15da-1b71-7dcaa767a7be@oracle.com>
 <9989FFC5-6D13-4114-B32D-A08D427925D4@oracle.com>
 
 
 <086778CB-EAC3-4A72-A7B5-E5D70522386F@oracle.com>
 <20caf67a-7a73-426b-d1be-39945757c4dc@oracle.com>
 
 
 <5E9D6923-BFF9-4D29-B721-97D56A6BF031@oracle.com>
 
 <68D8C805-A982-4C4D-9274-E128A6ED1206@oracle.com>
 
Message-ID: <56554605-5C3D-42EF-AB5E-DA7D59915540@oracle.com>

Thanks for checking other types. A curious restriction! Perhaps we can gain more insight by tracing with a fast debug build? e.g. see trace usages in src/hotspot/share/opto/loopTransform.cpp

Paul.

> On Jun 23, 2021, at 3:23 PM, Rados?aw Smogura  wrote:
> 
> Hi Paul,
> 
> Thank you. 
> 
> I checked with LongVector and got same results as int (4x loop unroll). With short vector I could not unroll. I only focused on method bufferHeap.
> 
> Kind regards,
> Rado
> 
> Od: Paul Sandoz 
> Wys?ane: ?roda, 23 czerwca 2021 22:32
> Do: Rados?aw Smogura 
> DW: Maurizio Cimadamore ; Vladimir Ivanov ; panama-dev at openjdk.java.net 
> Temat: Re: Foreign + Vectors - benchmarks for copying and swapping
>  
> Here you go:
> 
> https://gist.github.com/PaulSandoz/7d95a4d9b99b5f9f9c6326f65a4d77c8
> 
> Details in comments at the end.
> 
> Paul.
> 
> > On Jun 23, 2021, at 11:41 AM, Rados?aw Smogura  wrote:
> > 
> > Hi Paul,
> > 
> > Can you share a code, I could not unroll loop. I can only eliminate range checks and that's all.
> > 
> > In fact it's bit odd, as the code for loading int and byte vectors looks like same.
> > 
> > I've got few suspicions why ByteBuffer vectors can be harder to optimize:
> >        ? array length is taken from constant memory
> >        ? array length is non-negative
> > 
> > Kind regards,
> > Rado
> > 
> > Od: Paul Sandoz 
> > Wys?ane: wtorek, 22 czerwca 2021 22:29
> > Do: Rados?aw Smogura 
> > DW: Maurizio Cimadamore ; Vladimir Ivanov ; panama-dev at openjdk.java.net 
> > Temat: Re: Foreign + Vectors - benchmarks for copying and swapping
> >  
> > In general that should be ok. Try using IntVector instead and it will unroll (with your patch removing CPU barriers)
> > 
> > I wonder if this may be a limitation specific to bytes. 
> > 
> > Paul.
> > 
> > > On Jun 21, 2021, at 4:28 PM, Rados?aw Smogura  wrote:
> > > 
> > > Hi,
> > > 
> > > I think why the copy case may fail with unrolling, because
> > >        ? loop unroll takes the range check from intoByteBuffer as the loop exit condition
> > >        ? the range check uses unsigned compare, which is not supported by loop unroll
> > > 
> > > I think in this code
> > >         for (int i = 0; i < bound; i += lanes) {
> > >           final var srcVector = ByteVector
> > >               .fromByteBuffer(BYTE_VECTOR_SPECIES, src, i, ByteOrder.nativeOrder());
> > > 
> > >           srcVector.intoByteBuffer(dst, i, ByteOrder.nativeOrder());
> > >         }
> > > exit condition should be i < bound, not a range check from intoByteBuffer.
> > > 
> > > Kind regards,
> > > Rado
> > > 
> > > Od: Paul Sandoz 
> > > Wys?ane: poniedzia?ek, 21 czerwca 2021 23:25
> > > Do: Maurizio Cimadamore 
> > > DW: Rados?aw Smogura ; Vladimir Ivanov ; panama-dev at openjdk.java.net 
> > > Temat: Re: Foreign + Vectors - benchmarks for copying and swapping
> > >  
> > > Replacing the upper bound in `segmentImplicitScalar` with a constant (1024 say) results in a similar time to `bufferNativeScalar` without a constant bound, both of which (alas) are still slower that scalar array access (which benefits greatly from auto-vectorization).
> > > 
> > > I wonder if the segment subrange checking for int value ranges is having an impact on bounds checking?
> > > 
> > > Paul.
> > > 
> > > > On Jun 21, 2021, at 1:56 PM, Maurizio Cimadamore  wrote:
> > > > 
> > > > 
> > > > On 21/06/2021 20:33, Paul Sandoz wrote:
> > > >> - Segment scalar access is penalized compared to ByteBuffer (from allocate or allocateDirect) scalar access.
> > > > 
> > > > Odd
> > > > 
> > > > We have many benchmarks similar to this (see LoopOverNonConstant) and they seem to offer same level of performance compared with ByteBuffers.
> > > > 
> > > > I wonder if the loop limit being "SPECIES.loopBound(srcArray.length)" plays a role? Have you tried replacing that expression with a constant?
> > > > 
> > > > Maurizio
> > > > 


From john.r.rose at oracle.com  Thu Jun 24 18:19:38 2021
From: john.r.rose at oracle.com (John Rose)
Date: Thu, 24 Jun 2021 18:19:38 +0000
Subject: [foreign-memaccess+abi] RFR: Add support for high-level functions
 to copy to and from Java arrays [v2]
In-Reply-To: <_95lPbXeUP08u4iYh0foBDgOGqWGqSbuaJ_fqw8Qbs4=.d547101b-7d2f-4e0d-aac2-8d039c605dbf@github.com>
References: 
 
 
 
 <_95lPbXeUP08u4iYh0foBDgOGqWGqSbuaJ_fqw8Qbs4=.d547101b-7d2f-4e0d-aac2-8d039c605dbf@github.com>
Message-ID: 

On Jun 24, 2021, at 2:47 AM, Maurizio Cimadamore > wrote:

There's only one length - it's important to distinguish between Chars vs. Bytes - e.g. copyLengthChars vs. copyLengthBytes. But adding the `src` seems confusing because the `length` parameter is, IMHO neutral, and just indicates how many "things" have to be bulk-copied.

In fact, I'll go further and say that, when editing this patch I kept finding the placement of the length argument confusing. Having it as the trailing argument would be clearer IMHO.

Totally agree.  The length parameter applies equally
to source and destination.  Perhaps also rename length
as ?count? to make it more clear that we are counting items,
not measuring memory spans.

Putting length/count last is coherent with System.arraycopy.
That?s not a beautiful API but it is one that everybody knows.

From github.com+12941506+leerho at openjdk.java.net  Thu Jun 24 18:52:49 2021
From: github.com+12941506+leerho at openjdk.java.net (Lee Rhodes)
Date: Thu, 24 Jun 2021 18:52:49 GMT
Subject: [foreign-memaccess+abi] RFR: Add support for high-level functions
 to copy to and from Java arrays [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 24 Jun 2021 10:07:23 GMT, Maurizio Cimadamore  wrote:

>> This patch includes some of the changes from Lee to support a set of static functions to allow bulk copy from Java arrays to segments (and viceversa) in a more succint fashion (so that the user doesn't have to create a temporary heap segment to do the copy).
>> 
>> I've added a new public method to `MemorySegment` which performs an *element-wise* bulk copy; it takes a source segment and a couple of element layouts: the source element layout and the destination element layout. The two layouts must have same size, but can have different alignments (which will be checked against the corresponding segments) and byte orders. If the byte order differs, a bulk copy with swap will be performed. As such, this method generalizes the previous `copyFrom` - as follows:
>> 
>> 
>> copyFrom(srcSegment) -> copyFrom(JAVA_BYTE, srcSegment, JAVA_BYTE)
>> 
>> I've added support for argument type profiling for MemoryCopy static methods to avoid type pollution in cases where same metod is called with different memory segment types.
>> 
>> I've done a pass over the javadoc, and make it more consistent with the rest of the API. I've also reworked the test a bit to use the data provider functionality of TestNG, since all the test cases were similar, except for the carrier type.
>> 
>> There are other cosmetic changes as well, compared to original code from Lee, such as naming of static fields which is now capitalized. Everything else is the same.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   * Add null checks for ByteOrder
>   * Beef up test to check for various OOB conditions

The conceptual model I had in mind when I proposed this API was that it seemed sensible to order the parameters first by the data flow: {source parameters, destination parameters}, then by {Object, offset, length} with ByteOrder stuck at the end. Thus:

- copyToArray(srcSegment, srcOffsetBytes, dstArray, dstIndexChars, dstCopyLengthChars, order);
- copyFromArray(srcArray, srcIndexChars, srcCopyLengthChars, dstSegment, dstOffsetBytes, order);

But this is by no means the only mental model we could use as this {source, destination} flow model is not consistently followed even within the current FMA API.

As an alternative, we could use the conceptual model of {segment parameters, array parameters}. Thus:

- copyToArray(srcSegment, srcOffsetBytes, dstArray, dstIndexChars, dstCopyLengthChars, order);
- copyFromArray(dstSegment, dstOffsetBytes, srcArray, srcIndexChars, srcCopyLengthChars, order);

For the user, this model has the parameters by type always in the same order, the length (and order) are at the end, and because of that the prefixes for the copy length could probably be dropped.  But I would prefer to keep the other prefixes as they are as additional cues to the user of the flow direction as well as association.

-------------

PR: https://git.openjdk.java.net/panama-foreign/pull/555

From maurizio.cimadamore at oracle.com  Thu Jun 24 20:38:49 2021
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 24 Jun 2021 21:38:49 +0100
Subject: [foreign-memaccess+abi] RFR: Add support for high-level functions
 to copy to and from Java arrays [v5]
In-Reply-To: 
References: 
 
 
Message-ID: <3860bc72-51cf-ee5f-99ff-12bf285b34d0@oracle.com>


On 24/06/2021 19:52, Lee Rhodes wrote:
> The conceptual model I had in mind when I proposed this API was that it seemed sensible to order the parameters first by the data flow: {source parameters, destination parameters}, then by {Object, offset, length} with ByteOrder stuck at the end. Thus:
>
> - copyToArray(srcSegment, srcOffsetBytes, dstArray, dstIndexChars, dstCopyLengthChars, order);
> - copyFromArray(srcArray, srcIndexChars, srcCopyLengthChars, dstSegment, dstOffsetBytes, order);
>
> But this is by no means the only mental model we could use as this {source, destination} flow model is not consistently followed even within the current FMA API.
>
> As an alternative, we could use the conceptual model of {segment parameters, array parameters}. Thus:
>
> - copyToArray(srcSegment, srcOffsetBytes, dstArray, dstIndexChars, dstCopyLengthChars, order);
> - copyFromArray(dstSegment, dstOffsetBytes, srcArray, srcIndexChars, srcCopyLengthChars, order);
>
> For the user, this model has the parameters by type always in the same order, the length (and order) are at the end, and because of that the prefixes for the copy length could probably be dropped.  But I would prefer to keep the other prefixes as they are as additional cues to the user of the flow direction as well as association.

Honestly, it's not clear to me how the conceptual model is affecting 
where the length parameter goes. What I object to (and John and Jorn 
seems to agree) is that the "length" is not associated with either 
inputs - it's just a length, which can be expressed in bytes or in elements.

So:

- copyToArray(srcSegment, srcOffsetBytes, dstArray, dstIndexChars, numChars, order);
- copyFromArray(srcArray, srcIndexChars, dstSegment, dstOffsetBytes, numChars, order);

or

- copyToArray(srcSegment, srcOffsetBytes, dstArray, dstIndexChars, numChars, order);
- copyFromArray(dstSegment, dstOffsetBytes, srcArray, srcIndexChars, numChars, order);

Depending on how the other parameters should be sorted. I personally prefer:

* source first
* destination second
* length last (and order after that)

(which means the first of the two proposal above).

As John says, that's how System::arrayCopy (and many other libs) do it, 
I don't think I see the need for going down another path.

Is there a specific concern you have against that?

Cheers
Maurizio


From john.r.rose at oracle.com  Thu Jun 24 20:50:49 2021
From: john.r.rose at oracle.com (John Rose)
Date: Thu, 24 Jun 2021 20:50:49 +0000
Subject: [foreign-memaccess+abi] RFR: Add support for high-level functions
 to copy to and from Java arrays [v5]
In-Reply-To: <3860bc72-51cf-ee5f-99ff-12bf285b34d0@oracle.com>
References: 
 
 
 <3860bc72-51cf-ee5f-99ff-12bf285b34d0@oracle.com>
Message-ID: 



On Jun 24, 2021, at 1:38 PM, Maurizio Cimadamore > wrote:

So:

- copyToArray(srcSegment, srcOffsetBytes, dstArray, dstIndexChars, numChars, order);
- copyFromArray(srcArray, srcIndexChars, dstSegment, dstOffsetBytes, numChars, order);

or

- copyToArray(srcSegment, srcOffsetBytes, dstArray, dstIndexChars, numChars, order);
- copyFromArray(dstSegment, dstOffsetBytes, srcArray, srcIndexChars, numChars, order);

Depending on how the other parameters should be sorted. I personally prefer:

* source first
* destination second
* length last (and order after that)

(which means the first of the two proposal above).

As John says, that's how System::arrayCopy (and many other libs) do it, I don't think I see the need for going down another path.

Is there a specific concern you have against that?

It feels like violent agreement here:  System::arraycopy
has left-to-right data flow (yay, also Lee?s point!), and
ends with the common length value.

(Plus the byte order at the end too.  I?d sort that at
the very last, because it is the most neglect-able.)

You know, you could almost name this primitive
?arraycopy? and just rely on overloads.  The ?From?
and ?To? words are a little noisy, and they may
distract readers into thinking that they affect
argument order.  I think we agree they shouldn?t;
it?s simpler to have a left-to-right rule.

I was recently working on a non-static version of
a similar API (bulk copies!), and in that case the
receiver object was always the non-array.  That
requires help from the name, in the form of
?In? and ?Out? words which tell whether data
is entering or leaving the receiver object:

interface Words {
    // bulk copy
    default long copyIn(long destPos, long[] src, int srcStart, int srcEnd) {
        for (int i = srcStart; i < srcEnd; i++)
            set(destPos++, src[i]);
        return destPos;
    }
    default int copyOut(long start, long end, long[] dest, int destPos) {
        for (long i = start; i < end; i++)
            dest[destPos++] = get(i);
        return destPos;
    }

    long length();
    long get(long index);
    void set(long index, long value);
    ?
}

But for a static method, it?s better to have a static
ordering of arguments!




From mail at smogura.eu  Thu Jun 24 21:38:32 2021
From: mail at smogura.eu (=?windows-1250?Q?Rados=B3aw_Smogura?=)
Date: Thu, 24 Jun 2021 21:38:32 +0000
Subject: ODP: Foreign + Vectors - benchmarks for copying and swapping
In-Reply-To: <56554605-5C3D-42EF-AB5E-DA7D59915540@oracle.com>
References: 
 
 <5290e44a-7c67-6ee6-57dc-9af646604082@oracle.com>
 
 <1a23ee05-f187-e6d8-900e-62e77cd73dc9@oracle.com>
 <0DE3B831-2C2C-475B-94FC-867039D6AFC4@oracle.com>
 <07ccd69f-d218-15da-1b71-7dcaa767a7be@oracle.com>
 <9989FFC5-6D13-4114-B32D-A08D427925D4@oracle.com>
 
 
 <086778CB-EAC3-4A72-A7B5-E5D70522386F@oracle.com>
 <20caf67a-7a73-426b-d1be-39945757c4dc@oracle.com>
 
 
 <5E9D6923-BFF9-4D29-B721-97D56A6BF031@oracle.com>
 
 <68D8C805-A982-4C4D-9274-E128A6ED1206@oracle.com>
 ,
 <56554605-5C3D-42EF-AB5E-DA7D59915540@oracle.com>
Message-ID: 

Hi,

That's a good point - worth checking.

For now I found with debugger may not be the best due to OSR

For TestLoadStoreInts running it with -XX:-UseOnStackReplacement -jvmArgs=-XX:-UseLoopCounter does not give significant changes. For smaller regions it's even slower (but this can be due to benchamrk logic in JMH it self - I guess there's some loop which will not get compiled).

However for tests VectorCopySegments.copyWithVector there's change  25521.137 -> 23148.839 ns/op. I guess it's because the method gets fully compiled.

BR,
Rado
________________________________
Od: Paul Sandoz 
Wys?ane: czwartek, 24 czerwca 2021 17:26
Do: Rados?aw Smogura 
DW: Maurizio Cimadamore ; Vladimir Ivanov ; panama-dev at openjdk.java.net 
Temat: Re: Foreign + Vectors - benchmarks for copying and swapping

Thanks for checking other types. A curious restriction! Perhaps we can gain more insight by tracing with a fast debug build? e.g. see trace usages in src/hotspot/share/opto/loopTransform.cpp

Paul.

> On Jun 23, 2021, at 3:23 PM, Rados?aw Smogura  wrote:
>
> Hi Paul,
>
> Thank you.
>
> I checked with LongVector and got same results as int (4x loop unroll). With short vector I could not unroll. I only focused on method bufferHeap.
>
> Kind regards,
> Rado
>
> Od: Paul Sandoz 
> Wys?ane: ?roda, 23 czerwca 2021 22:32
> Do: Rados?aw Smogura 
> DW: Maurizio Cimadamore ; Vladimir Ivanov ; panama-dev at openjdk.java.net 
> Temat: Re: Foreign + Vectors - benchmarks for copying and swapping
>
> Here you go:
>
> https://gist.github.com/PaulSandoz/7d95a4d9b99b5f9f9c6326f65a4d77c8
>
> Details in comments at the end.
>
> Paul.
>
> > On Jun 23, 2021, at 11:41 AM, Rados?aw Smogura  wrote:
> >
> > Hi Paul,
> >
> > Can you share a code, I could not unroll loop. I can only eliminate range checks and that's all.
> >
> > In fact it's bit odd, as the code for loading int and byte vectors looks like same.
> >
> > I've got few suspicions why ByteBuffer vectors can be harder to optimize:
> >        ? array length is taken from constant memory
> >        ? array length is non-negative
> >
> > Kind regards,
> > Rado
> >
> > Od: Paul Sandoz 
> > Wys?ane: wtorek, 22 czerwca 2021 22:29
> > Do: Rados?aw Smogura 
> > DW: Maurizio Cimadamore ; Vladimir Ivanov ; panama-dev at openjdk.java.net 
> > Temat: Re: Foreign + Vectors - benchmarks for copying and swapping
> >
> > In general that should be ok. Try using IntVector instead and it will unroll (with your patch removing CPU barriers)
> >
> > I wonder if this may be a limitation specific to bytes.
> >
> > Paul.
> >
> > > On Jun 21, 2021, at 4:28 PM, Rados?aw Smogura  wrote:
> > >
> > > Hi,
> > >
> > > I think why the copy case may fail with unrolling, because
> > >        ? loop unroll takes the range check from intoByteBuffer as the loop exit condition
> > >        ? the range check uses unsigned compare, which is not supported by loop unroll
> > >
> > > I think in this code
> > >         for (int i = 0; i < bound; i += lanes) {
> > >           final var srcVector = ByteVector
> > >               .fromByteBuffer(BYTE_VECTOR_SPECIES, src, i, ByteOrder.nativeOrder());
> > >
> > >           srcVector.intoByteBuffer(dst, i, ByteOrder.nativeOrder());
> > >         }
> > > exit condition should be i < bound, not a range check from intoByteBuffer.
> > >
> > > Kind regards,
> > > Rado
> > >
> > > Od: Paul Sandoz 
> > > Wys?ane: poniedzia?ek, 21 czerwca 2021 23:25
> > > Do: Maurizio Cimadamore 
> > > DW: Rados?aw Smogura ; Vladimir Ivanov ; panama-dev at openjdk.java.net 
> > > Temat: Re: Foreign + Vectors - benchmarks for copying and swapping
> > >
> > > Replacing the upper bound in `segmentImplicitScalar` with a constant (1024 say) results in a similar time to `bufferNativeScalar` without a constant bound, both of which (alas) are still slower that scalar array access (which benefits greatly from auto-vectorization).
> > >
> > > I wonder if the segment subrange checking for int value ranges is having an impact on bounds checking?
> > >
> > > Paul.
> > >
> > > > On Jun 21, 2021, at 1:56 PM, Maurizio Cimadamore  wrote:
> > > >
> > > >
> > > > On 21/06/2021 20:33, Paul Sandoz wrote:
> > > >> - Segment scalar access is penalized compared to ByteBuffer (from allocate or allocateDirect) scalar access.
> > > >
> > > > Odd
> > > >
> > > > We have many benchmarks similar to this (see LoopOverNonConstant) and they seem to offer same level of performance compared with ByteBuffers.
> > > >
> > > > I wonder if the loop limit being "SPECIES.loopBound(srcArray.length)" plays a role? Have you tried replacing that expression with a constant?
> > > >
> > > > Maurizio
> > > >


From leerho at gmail.com  Fri Jun 25 00:50:59 2021
From: leerho at gmail.com (leerho)
Date: Thu, 24 Jun 2021 17:50:59 -0700
Subject: [foreign-memaccess+abi] RFR: Add support for high-level functions
 to copy to and from Java arrays [v5]
In-Reply-To: 
References: 
 
 
 <3860bc72-51cf-ee5f-99ff-12bf285b34d0@oracle.com>
 
Message-ID: 

Yes, it bothers me a little, although I clearly could live with whatever
you decide to do.
For your consideration, here are some of my thoughts :)

Variable naming is tough, but I could argue that the length specification
is hardly neutral.  Under the covers, a char[] length gets converted into a
length in bytes, which are the units for segments, and of course, defines
the length of the transfer.  In our minds as developers of the
implementations of this API it appears neutral, because we know it
ultimately ends up in units of bytes. To the user, however, the length
specification parameter in the API call has at least two properties that
make it closely associated with the heap primitive array as opposed to an
association with the segment:

   - It is specified in the units of the array, e.g. chars for a char[].
   The user will contrast this with other parts of the FMA API where the
   length units of segments are always bytes.
   - The carrier for the value is an int, while the carrier for a segment
   length specification is always a long.

If we spell out the current parameters just moving the length to the end it
would look like:

   - copyFromArray(char[] srcArray, int srcIndexChars, dstSegment, long
   dstOffsetBytes, int copyLengthChars, order).
   Note the alternation of units and carriers: {char[], int chars, segment,
   long bytes, int chars).  So the parameters associated with the source
   char[] are split up.  I find this awkward.
   - copyToArray(srcSegment, long srcOffsetBytes, char[] dstArray, int
   dstIndexChars, int copyLengthChars, order).
   Here, at least, the 3 parameters that the user would specify while
   contemplating the dstArray are together.

I'm sure I would have to refer to the javadoc almost every time I used
these methods to keep the units and carriers straight.

System.arrayCopy(...) is a nice model, which I like, but note that srcPos,
dstPos and length all are in the same units (the elements units of src and
dest) and with the same carrier: int.  It is a much simpler model than what
we are trying to do here.

What I like about the original proposed {source, destination] flow model is
that the 3 parameters that are associated with the heap array are always
together and it is highly likely that the user has those 3 parameters in
mind at the same time when constructing the call. The alternative model of
{segment parameters, array parameters} also has the 3 parameters of the
array together and it has the length at the end (with order), and would be
very easy to remember.

There is no perfect solution here.

Cheers,
Lee.


On Thu, Jun 24, 2021 at 1:51 PM John Rose  wrote:

>
>
> On Jun 24, 2021, at 1:38 PM, Maurizio Cimadamore <
> maurizio.cimadamore at oracle.com>
> wrote:
>
> So:
>
> - copyToArray(srcSegment, srcOffsetBytes, dstArray, dstIndexChars,
> numChars, order);
> - copyFromArray(srcArray, srcIndexChars, dstSegment, dstOffsetBytes,
> numChars, order);
>
> or
>
> - copyToArray(srcSegment, srcOffsetBytes, dstArray, dstIndexChars,
> numChars, order);
> - copyFromArray(dstSegment, dstOffsetBytes, srcArray, srcIndexChars,
> numChars, order);
>
> Depending on how the other parameters should be sorted. I personally
> prefer:
>
> * source first
> * destination second
> * length last (and order after that)
>
> (which means the first of the two proposal above).
>
> As John says, that's how System::arrayCopy (and many other libs) do it, I
> don't think I see the need for going down another path.
>
> Is there a specific concern you have against that?
>
> It feels like violent agreement here:  System::arraycopy
> has left-to-right data flow (yay, also Lee?s point!), and
> ends with the common length value.
>
> (Plus the byte order at the end too.  I?d sort that at
> the very last, because it is the most neglect-able.)
>
> You know, you could almost name this primitive
> ?arraycopy? and just rely on overloads.  The ?From?
> and ?To? words are a little noisy, and they may
> distract readers into thinking that they affect
> argument order.  I think we agree they shouldn?t;
> it?s simpler to have a left-to-right rule.
>
> I was recently working on a non-static version of
> a similar API (bulk copies!), and in that case the
> receiver object was always the non-array.  That
> requires help from the name, in the form of
> ?In? and ?Out? words which tell whether data
> is entering or leaving the receiver object:
>
> interface Words {
>     // bulk copy
>     default long copyIn(long destPos, long[] src, int srcStart, int
> srcEnd) {
>         for (int i = srcStart; i < srcEnd; i++)
>             set(destPos++, src[i]);
>         return destPos;
>     }
>     default int copyOut(long start, long end, long[] dest, int destPos) {
>         for (long i = start; i < end; i++)
>             dest[destPos++] = get(i);
>         return destPos;
>     }
>
>     long length();
>     long get(long index);
>     void set(long index, long value);
>     ?
> }
>
> But for a static method, it?s better to have a static
> ordering of arguments!
>
>
>
>

From xgong at openjdk.java.net  Fri Jun 25 01:48:45 2021
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Fri, 25 Jun 2021 01:48:45 GMT
Subject: [vectorIntrinsics+mask] RFR: 8267368: Add masking support for
 reduction vector intrinsics [v3]
In-Reply-To: 
References: 
Message-ID: 

> This patch adds the masking support for vector reduction operations, including the Vector API java implementation and hotspot intrinsics changes. It adds the mask information to the reduction intrinsic method. With it:
>   - Both masked and non-masked reduction operations call the same hotspot intrinsics. The mask value and class are set to `"null"` for non-masked operations.
>   - Reduction IR with mask as another input will be generated if the platform supports the predicate feature for the op. Otherwise, the vector blend pattern will be generated like before.
> 
> Note that this patch only contains the Vector API java implementation and the hotspot intrinsics changes. No compiler mid-end and backend implementations are included.

Xiaohong Gong has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:

 - Use "VecMaskUsePred" to check whether predicate is supported
 - Merge panama-vector:vectorIntrinsics+mask into JDK-8267368
 - Merge panama-vector:vectorIntrinsics+mask into JDK-8267368
 - 8267368: Add masking support for reduction vector intrinsics

-------------

Changes: https://git.openjdk.java.net/panama-vector/pull/86/files
 Webrev: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=86&range=02
  Stats: 684 lines in 42 files changed: 367 ins; 94 del; 223 mod
  Patch: https://git.openjdk.java.net/panama-vector/pull/86.diff
  Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/86/head:pull/86

PR: https://git.openjdk.java.net/panama-vector/pull/86

From mail at smogura.eu  Fri Jun 25 01:51:53 2021
From: mail at smogura.eu (=?windows-1250?Q?Rados=B3aw_Smogura?=)
Date: Fri, 25 Jun 2021 01:51:53 +0000
Subject: ODP: Foreign + Vectors - benchmarks for copying and swapping
In-Reply-To: 
References: 
 
 <5290e44a-7c67-6ee6-57dc-9af646604082@oracle.com>
 
 <1a23ee05-f187-e6d8-900e-62e77cd73dc9@oracle.com>
 <0DE3B831-2C2C-475B-94FC-867039D6AFC4@oracle.com>
 <07ccd69f-d218-15da-1b71-7dcaa767a7be@oracle.com>
 <9989FFC5-6D13-4114-B32D-A08D427925D4@oracle.com>
 
 
 <086778CB-EAC3-4A72-A7B5-E5D70522386F@oracle.com>
 <20caf67a-7a73-426b-d1be-39945757c4dc@oracle.com>
 
 
 <5E9D6923-BFF9-4D29-B721-97D56A6BF031@oracle.com>
 
 <68D8C805-A982-4C4D-9274-E128A6ED1206@oracle.com>
 ,
 <56554605-5C3D-42EF-AB5E-DA7D59915540@oracle.com>,
 
Message-ID: 

Hi,

I think I've found this condition. Loops limits unroll based on stride size.

Made small change for fun

https://github.com/rsmogura/panama-foreign/commit/0b991797a1e647a2f4a960cf6253708139d57975

Before
Benchmark                       (size)  Mode  Cnt      Score     Error  Units
TestLoadStoreShort.bufferHeap  1048576  avgt   10  22010.657 ? 127.671  ns/op

After MICRO="OPTIONS=-f 1 -p size=1048576 -jvmArgs=-XX:+UnlockExperimentalVMOptions -jvmArgs=-XX:+LoopUnrollAggressiveStrideLimit"
Benchmark                       (size)  Mode  Cnt      Score     Error  Units
TestLoadStoreShort.bufferHeap  1048576  avgt   10  22000.258 ? 482.501  ns/op

I'm not sure why there's limit for stride size. I only found [1] related to this code, which made stride limit more tight, but I'm not sure what stands behind this limit.

[1] https://github.com/openjdk/panama-foreign/commit/2683d5390bd58683ae13bdd8582127c308d8fd04


BR,
Rado
________________________________
Od: panama-dev  w imieniu u?ytkownika Rados?aw Smogura 
Wys?ane: czwartek, 24 czerwca 2021 23:38
Do: Paul Sandoz 
DW: Maurizio Cimadamore ; Vladimir Ivanov ; panama-dev at openjdk.java.net 
Temat: ODP: Foreign + Vectors - benchmarks for copying and swapping

Hi,

That's a good point - worth checking.

For now I found with debugger may not be the best due to OSR

For TestLoadStoreInts running it with -XX:-UseOnStackReplacement -jvmArgs=-XX:-UseLoopCounter does not give significant changes. For smaller regions it's even slower (but this can be due to benchamrk logic in JMH it self - I guess there's some loop which will not get compiled).

However for tests VectorCopySegments.copyWithVector there's change  25521.137 -> 23148.839 ns/op. I guess it's because the method gets fully compiled.

BR,
Rado
________________________________
Od: Paul Sandoz 
Wys?ane: czwartek, 24 czerwca 2021 17:26
Do: Rados?aw Smogura 
DW: Maurizio Cimadamore ; Vladimir Ivanov ; panama-dev at openjdk.java.net 
Temat: Re: Foreign + Vectors - benchmarks for copying and swapping

Thanks for checking other types. A curious restriction! Perhaps we can gain more insight by tracing with a fast debug build? e.g. see trace usages in src/hotspot/share/opto/loopTransform.cpp

Paul.

> On Jun 23, 2021, at 3:23 PM, Rados?aw Smogura  wrote:
>
> Hi Paul,
>
> Thank you.
>
> I checked with LongVector and got same results as int (4x loop unroll). With short vector I could not unroll. I only focused on method bufferHeap.
>
> Kind regards,
> Rado
>
> Od: Paul Sandoz 
> Wys?ane: ?roda, 23 czerwca 2021 22:32
> Do: Rados?aw Smogura 
> DW: Maurizio Cimadamore ; Vladimir Ivanov ; panama-dev at openjdk.java.net 
> Temat: Re: Foreign + Vectors - benchmarks for copying and swapping
>
> Here you go:
>
> https://gist.github.com/PaulSandoz/7d95a4d9b99b5f9f9c6326f65a4d77c8
>
> Details in comments at the end.
>
> Paul.
>
> > On Jun 23, 2021, at 11:41 AM, Rados?aw Smogura  wrote:
> >
> > Hi Paul,
> >
> > Can you share a code, I could not unroll loop. I can only eliminate range checks and that's all.
> >
> > In fact it's bit odd, as the code for loading int and byte vectors looks like same.
> >
> > I've got few suspicions why ByteBuffer vectors can be harder to optimize:
> >        ? array length is taken from constant memory
> >        ? array length is non-negative
> >
> > Kind regards,
> > Rado
> >
> > Od: Paul Sandoz 
> > Wys?ane: wtorek, 22 czerwca 2021 22:29
> > Do: Rados?aw Smogura 
> > DW: Maurizio Cimadamore ; Vladimir Ivanov ; panama-dev at openjdk.java.net 
> > Temat: Re: Foreign + Vectors - benchmarks for copying and swapping
> >
> > In general that should be ok. Try using IntVector instead and it will unroll (with your patch removing CPU barriers)
> >
> > I wonder if this may be a limitation specific to bytes.
> >
> > Paul.
> >
> > > On Jun 21, 2021, at 4:28 PM, Rados?aw Smogura  wrote:
> > >
> > > Hi,
> > >
> > > I think why the copy case may fail with unrolling, because
> > >        ? loop unroll takes the range check from intoByteBuffer as the loop exit condition
> > >        ? the range check uses unsigned compare, which is not supported by loop unroll
> > >
> > > I think in this code
> > >         for (int i = 0; i < bound; i += lanes) {
> > >           final var srcVector = ByteVector
> > >               .fromByteBuffer(BYTE_VECTOR_SPECIES, src, i, ByteOrder.nativeOrder());
> > >
> > >           srcVector.intoByteBuffer(dst, i, ByteOrder.nativeOrder());
> > >         }
> > > exit condition should be i < bound, not a range check from intoByteBuffer.
> > >
> > > Kind regards,
> > > Rado
> > >
> > > Od: Paul Sandoz 
> > > Wys?ane: poniedzia?ek, 21 czerwca 2021 23:25
> > > Do: Maurizio Cimadamore 
> > > DW: Rados?aw Smogura ; Vladimir Ivanov ; panama-dev at openjdk.java.net 
> > > Temat: Re: Foreign + Vectors - benchmarks for copying and swapping
> > >
> > > Replacing the upper bound in `segmentImplicitScalar` with a constant (1024 say) results in a similar time to `bufferNativeScalar` without a constant bound, both of which (alas) are still slower that scalar array access (which benefits greatly from auto-vectorization).
> > >
> > > I wonder if the segment subrange checking for int value ranges is having an impact on bounds checking?
> > >
> > > Paul.
> > >
> > > > On Jun 21, 2021, at 1:56 PM, Maurizio Cimadamore  wrote:
> > > >
> > > >
> > > > On 21/06/2021 20:33, Paul Sandoz wrote:
> > > >> - Segment scalar access is penalized compared to ByteBuffer (from allocate or allocateDirect) scalar access.
> > > >
> > > > Odd
> > > >
> > > > We have many benchmarks similar to this (see LoopOverNonConstant) and they seem to offer same level of performance compared with ByteBuffers.
> > > >
> > > > I wonder if the loop limit being "SPECIES.loopBound(srcArray.length)" plays a role? Have you tried replacing that expression with a constant?
> > > >
> > > > Maurizio
> > > >


From xgong at openjdk.java.net  Fri Jun 25 02:42:48 2021
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Fri, 25 Jun 2021 02:42:48 GMT
Subject: [vectorIntrinsics+mask] RFR: 8267368: Add masking support for
 reduction vector intrinsics [v3]
In-Reply-To: 
References: 
 
Message-ID: <7MuIIiW1hl05UhpUY3g3IM-n3GFbaqXStBx5imeXoD4=.069a7889-0378-4310-87dc-254b6233e3df@github.com>

On Fri, 25 Jun 2021 01:48:45 GMT, Xiaohong Gong  wrote:

>> This patch adds the masking support for vector reduction operations, including the Vector API java implementation and hotspot intrinsics changes. It adds the mask information to the reduction intrinsic method. With it:
>>   - Both masked and non-masked reduction operations call the same hotspot intrinsics. The mask value and class are set to `"null"` for non-masked operations.
>>   - Reduction IR with mask as another input will be generated if the platform supports the predicate feature for the op. Otherwise, the vector blend pattern will be generated like before.
>> 
>> Note that this patch only contains the Vector API java implementation and the hotspot intrinsics changes. No compiler mid-end and backend implementations are included.
>
> Xiaohong Gong has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
> 
>  - Use "VecMaskUsePred" to check whether predicate is supported
>  - Merge panama-vector:vectorIntrinsics+mask into JDK-8267368
>  - Merge panama-vector:vectorIntrinsics+mask into JDK-8267368
>  - 8267368: Add masking support for reduction vector intrinsics

Hi @iwanowww , we'd like to integrate this PR first to promote the further masking feature development. Any comments and feedback are still welcome! And we can revisit them in future. Thanks so much!

Best Regards,
Xiaohong

-------------

PR: https://git.openjdk.java.net/panama-vector/pull/86

From xgong at openjdk.java.net  Fri Jun 25 02:42:49 2021
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Fri, 25 Jun 2021 02:42:49 GMT
Subject: [vectorIntrinsics+mask] Integrated: 8267368: Add masking support for
 reduction vector intrinsics
In-Reply-To: 
References: 
Message-ID: 

On Mon, 24 May 2021 06:15:56 GMT, Xiaohong Gong  wrote:

> This patch adds the masking support for vector reduction operations, including the Vector API java implementation and hotspot intrinsics changes. It adds the mask information to the reduction intrinsic method. With it:
>   - Both masked and non-masked reduction operations call the same hotspot intrinsics. The mask value and class are set to `"null"` for non-masked operations.
>   - Reduction IR with mask as another input will be generated if the platform supports the predicate feature for the op. Otherwise, the vector blend pattern will be generated like before.
> 
> Note that this patch only contains the Vector API java implementation and the hotspot intrinsics changes. No compiler mid-end and backend implementations are included.

This pull request has now been integrated.

Changeset: aff1e3d9
Author:    Xiaohong Gong 
URL:       https://git.openjdk.java.net/panama-vector/commit/aff1e3d900057dd5dea21c73aac70b4e1c2de1c2
Stats:     684 lines in 42 files changed: 367 ins; 94 del; 223 mod

8267368: Add masking support for reduction vector intrinsics

Reviewed-by: psandoz

-------------

PR: https://git.openjdk.java.net/panama-vector/pull/86

From xgong at openjdk.java.net  Fri Jun 25 04:17:27 2021
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Fri, 25 Jun 2021 04:17:27 GMT
Subject: [vectorIntrinsics+mask] RFR: 8269282: Add masking support for vector
 gather_load/scatter_store
Message-ID: 

This patch adds the masking support for masked vector gather load and scatter store, including:
  1) The Vector API java implementation and hotspot intrinsics changes:
    - Add masking information to the `loadWithMap/storeWithMap` intrinsics.
    - Both masked and non-masked gather_load/scatter_store call the same intrinsics. The mask value and class are set to `"null"` for non-masked operations.
  2) The C2 compiler changes:
    - Add two new IRs for the masked gather_load/scatter_store. The new masked IR will be generated for masked operation if the platform supports the predicate feature and the backend has implemented it.  Otherwise, the compiler will go back to the default java implementation.

-------------

Commit messages:
 - 8269282: Add masking support for vector gather_load/scatter_store

Changes: https://git.openjdk.java.net/panama-vector/pull/95/files
 Webrev: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=95&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269282
  Stats: 1062 lines in 48 files changed: 924 ins; 36 del; 102 mod
  Patch: https://git.openjdk.java.net/panama-vector/pull/95.diff
  Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/95/head:pull/95

PR: https://git.openjdk.java.net/panama-vector/pull/95

From xgong at openjdk.java.net  Fri Jun 25 06:29:39 2021
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Fri, 25 Jun 2021 06:29:39 GMT
Subject: [vectorIntrinsics+mask] RFR: 8266287: Basic mask IR
 implementation for the Vector API masking feature support [v4]
In-Reply-To: 
References: 
Message-ID: 

> Based on [1], this patch adds the C2 compiler mid-end changes for the masking feature support. It mainly contains:
>  1) Generation of the mask IRs for vector mask, including:
>     - Mask generations, e.g. load/compare/maskAll
>     - Mask operations, e.g. and/or/xor
>  2) Conversions between vector and mask after loading mask values from memory and before storing mask values into memory
>  3) Generation of the vector IRs which need the mask value as the control
>     - The mask value is appended to the original vector node's input list
> 
> With this change, the bottom type of the vector mask will be set to `"TypeVectMask"` if the platform supports the masking feature and the backend implementations are added.
> 
> Note that this patch only contains the compiler mid-end changes. The backend implementations for SVE/AVX-512 will be in the
> followed-up patches.
> 
> [1] https://github.com/openjdk/panama-vector/pull/57

Xiaohong Gong has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:

 - Merge panama-vector:vectorIntrinsics+mask into JDK-8266287
 - Try to reuse the same vector mask IRs
 - Merge branch panama-vector:vectorIntrinsics+mask' into JDK-8266287
 - Use "Flag_is_predicated_vector" for masked vector nodes
 - Merge branch 'vectorIntrinsics+mask'
 - 8266287: Basic mask IR implementation for the Vector API masking feature support

-------------

Changes: https://git.openjdk.java.net/panama-vector/pull/78/files
 Webrev: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=78&range=03
  Stats: 311 lines in 15 files changed: 237 ins; 22 del; 52 mod
  Patch: https://git.openjdk.java.net/panama-vector/pull/78.diff
  Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/78/head:pull/78

PR: https://git.openjdk.java.net/panama-vector/pull/78

From njian at openjdk.java.net  Fri Jun 25 06:48:12 2021
From: njian at openjdk.java.net (Ningsheng Jian)
Date: Fri, 25 Jun 2021 06:48:12 GMT
Subject: [vectorIntrinsics] Integrated: 8269264: Some more cleanups for Vector
 API SVE support
In-Reply-To: 
References: 
Message-ID: 

On Thu, 24 Jun 2021 02:29:02 GMT, Ningsheng Jian  wrote:

> Some more vectorIntrinsics SVE codegen cleanups for preparing a further
> review patch in jdk mainline. This change includes:
> 
> 1. Incorporate changes while preparing jdk mainline PR [1], which
> includes some minor style changes and extending SVE vector size to
> support 8 bytes to achieve better performance for *64Vector operations
> and shuffles.
> 2. Fix register effects in some VectorCast rules, spotted by @XiaohongGong,
> to avoid register reuse problem.
> 3. Merge reduction rules, as of what have been done for partial sizes.
> 4. Sort VectorCast rules by types/names for easier review.
> 5. Move sve_compare() from ad file to c2_MacroAssembler just as
> recently added neon_compare().
> 
> [1] https://github.com/openjdk/jdk/pull/4122

This pull request has now been integrated.

Changeset: e8e72698
Author:    Ningsheng Jian 
URL:       https://git.openjdk.java.net/panama-vector/commit/e8e72698338e2d434adf9ec49c749be93dcee083
Stats:     1942 lines in 7 files changed: 492 ins; 923 del; 527 mod

8269264: Some more cleanups for Vector API SVE support

Reviewed-by: xgong

-------------

PR: https://git.openjdk.java.net/panama-vector/pull/94

From xgong at openjdk.java.net  Fri Jun 25 09:36:47 2021
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Fri, 25 Jun 2021 09:36:47 GMT
Subject: [vectorIntrinsics+mask] RFR: 8269343: Masked vector arithmetic
 intrinsics failed to be inlined randomly
Message-ID: 

The masked `"lanewise/reduceLanes"` failed to be intrinsified randomly. The main reason is the hotspot c2 compiler cannot
unbox the mask value due to the expected vector box type being mismatched with the class of the mask value. The vector box type is the` "mask class"` which is specified in Java level and saved in the intrinsic argument list. It is the class of the instance
of the vector mask (i.e. `"IntMaxMask.class"`), while the type of mask value is the super class (i.e. `"jdk.incubator.vector.VectorMask"`).

Casting the mask value to the same subclass before calling the intrinsics can solve this issue.

-------------

Commit messages:
 - 8269343: Masked vector arithmetic intrinsics failed to be inlined randomly

Changes: https://git.openjdk.java.net/panama-vector/pull/96/files
 Webrev: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=96&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269343
  Stats: 155 lines in 31 files changed: 0 ins; 0 del; 155 mod
  Patch: https://git.openjdk.java.net/panama-vector/pull/96.diff
  Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/96/head:pull/96

PR: https://git.openjdk.java.net/panama-vector/pull/96

From maurizio.cimadamore at oracle.com  Fri Jun 25 09:52:44 2021
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Fri, 25 Jun 2021 10:52:44 +0100
Subject: [foreign-memaccess+abi] RFR: Add support for high-level functions
 to copy to and from Java arrays [v5]
In-Reply-To: 
References: 
 
 
 <3860bc72-51cf-ee5f-99ff-12bf285b34d0@oracle.com>
 
 
Message-ID: <1875d0a8-b333-9fba-d07e-111796605b9a@oracle.com>


On 25/06/2021 01:50, leerho wrote:
> There is no perfect solution here.

I agree? that there's no silver bullet, however:

* When thinking a bit how the API might work, I think at some point it 
becomes obvious that the length of the copy _must_ be specified in 
elements - that's the only sensible choice, otherwise you end up with 
either partial element copies or exceptions (in case we want to defend 
against partial copy). So, I found myself that, after working with the 
API for few days, I internalized what the API was trying to do, and 
after that point I was constantly fighting with the positioning of the 
length parameter (for which, by then, couldn't see any other alternative 
than expressing it in elements).

* Diverging from similarly looking APIs has a cost too. Yes, it's not 
exactly similar to System.arrayCopy - there are more issues here for 
sure - but I think it depends on how you look at things, and on how much 
you want the differences to "pop out" in the new signature. The 
signatures we have now are screaming for "I'm new and different!" while 
I think at least some users will not find them _too_ different.

I think the key observation is the one you made few weeks ago: the 
natural offset for segments is expressed in bytes, while for arrays we 
work with element indices. That's a good summary which should probably 
be captured somewhere in the javadoc. Once the user internalizes that, I 
believe it is safe to go back to the src/dst model w/o worrying too much 
about unit mismatches: given that length has to apply to _both_ 
parameters, and given that some parameters are offset-able and others 
are index-able, the only possible choice for the length parameter is to 
work off indices/elements (to avoid the problem mentioned above).

I think for now I'll just integrate what we have - but I believe that 
this needs to be rediscussed.

Another thing worth considering is whether MemoryCopy should have a 
static method for copying segments into segments:

copy(MemorySegment src, long srcOffset, ValueLayout srcLayout, 
MemorySegment dst, long dstOffset, ValueLayout dstLayout, long bytes)

and, maybe, an overload for simple cases where no swapping is desired:

copy(MemorySegment src, long srcOffset, MemorySegment dst, long 
dstOffset, long bytes)

I think these would be useful. MemorySegment::copyFrom is a fluent 
version of the copy methods, which I'm sure is handy if you already 
happen to have the right segments in your hands. But I believe that 
slicing and offseting just in preparation of a copy is, as we have 
learned in this thread, a conceptual overhead that we'd like to leave to 
the API implementation, so that, when reading the code, the intent is 
made clearer.

Maurizio



From mcimadamore at openjdk.java.net  Fri Jun 25 10:41:44 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 25 Jun 2021 10:41:44 GMT
Subject: [foreign-memaccess+abi] RFR: Add support for high-level functions
 to copy to and from Java arrays [v6]
In-Reply-To: 
References: 
Message-ID: 

> This patch includes some of the changes from Lee to support a set of static functions to allow bulk copy from Java arrays to segments (and viceversa) in a more succint fashion (so that the user doesn't have to create a temporary heap segment to do the copy).
> 
> I've added a new public method to `MemorySegment` which performs an *element-wise* bulk copy; it takes a source segment and a couple of element layouts: the source element layout and the destination element layout. The two layouts must have same size, but can have different alignments (which will be checked against the corresponding segments) and byte orders. If the byte order differs, a bulk copy with swap will be performed. As such, this method generalizes the previous `copyFrom` - as follows:
> 
> 
> copyFrom(srcSegment) -> copyFrom(JAVA_BYTE, srcSegment, JAVA_BYTE)
> 
> I've added support for argument type profiling for MemoryCopy static methods to avoid type pollution in cases where same metod is called with different memory segment types.
> 
> I've done a pass over the javadoc, and make it more consistent with the rest of the API. I've also reworked the test a bit to use the data provider functionality of TestNG, since all the test cases were similar, except for the carrier type.
> 
> There are other cosmetic changes as well, compared to original code from Lee, such as naming of static fields which is now capitalized. Everything else is the same.

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Add javadoc text for exceptions which might be thrown by MemoryAccess/MemoryCopy

-------------

Changes:
  - all: https://git.openjdk.java.net/panama-foreign/pull/555/files
  - new: https://git.openjdk.java.net/panama-foreign/pull/555/files/6c5082a8..e66008dc

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=555&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=555&range=04-05

  Stats: 14 lines in 2 files changed: 10 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/panama-foreign/pull/555.diff
  Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/555/head:pull/555

PR: https://git.openjdk.java.net/panama-foreign/pull/555

From duke at openjdk.java.net  Fri Jun 25 11:07:07 2021
From: duke at openjdk.java.net (duke)
Date: Fri, 25 Jun 2021 11:07:07 GMT
Subject: git: openjdk/panama-foreign: master: 81 new changesets
Message-ID: <3ca9ca6e-ab46-4819-a185-541430f5049e@openjdk.org>

Changeset: 5ae9a128
Author:    Albert Mingkun Yang 
Date:      2021-06-18 11:48:59 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/5ae9a12858a20361c163e1dfe6b67970f27e4e40

8268964: Remove unused ReferenceProcessorAtomicMutator

Reviewed-by: tschatzl, pliden

! src/hotspot/share/gc/shared/referenceProcessor.hpp

Changeset: 8f2456e5
Author:    Boris Ulasevich 
Date:      2021-06-18 16:25:25 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/8f2456e5b058a88730ec383d88634737849afdfb

8267042: bug in monitor locking/unlocking on ARM32 C1 due to uninitialized BasicObjectLock::_displaced_header

Co-authored-by: Chris Cole 
Reviewed-by: dsamersoff

! src/hotspot/cpu/arm/c1_MacroAssembler_arm.cpp
! src/hotspot/cpu/arm/sharedRuntime_arm.cpp
+ test/hotspot/jtreg/compiler/c1/Test8267042.java

Changeset: 80dc262e
Author:    Valerie Peng 
Date:      2021-06-17 23:27:54 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/80dc262e8132204d70b184b32978e6c456460fb0

8265500: Some impls of javax.crypto.Cipher.init() do not throw UnsupportedOperationExc for unsupported modes

Reviewed-by: xuelei

! src/java.base/share/classes/com/sun/crypto/provider/ARCFOURCipher.java
! src/java.base/share/classes/com/sun/crypto/provider/ChaCha20Cipher.java
! src/java.base/share/classes/com/sun/crypto/provider/RSACipher.java
! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11AEADCipher.java
! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java
! src/jdk.crypto.mscapi/windows/classes/sun/security/mscapi/CRSACipher.java
! test/jdk/javax/crypto/Cipher/TestCipherMode.java
+ test/jdk/sun/security/pkcs11/Cipher/TestCipherMode.java

Changeset: 483f1ee2
Author:    Rajan Halade 
Date:      2021-06-18 00:59:29 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/483f1ee211bc0e37b486eb9d38d283ff02f0bdcc

8268678: LetsEncryptCA.java test fails as Let?s Encrypt Authority X3 is retired

Backport-of: 58e6e6d919cb15559a61a67805da263be3c9d693

! test/jdk/security/infra/java/security/cert/CertPathValidator/certification/LetsEncryptCA.java

Changeset: 7ed3634d
Author:    Vladimir Ivanov 
Date:      2021-06-18 07:50:22 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/7ed3634da81b53135c89aa82a1a5d2f4de2c6c5e

8268405: Several regressions 4-17% after CHA changes

Reviewed-by: kvn, dlong

! src/hotspot/share/opto/c2_globals.hpp
! src/hotspot/share/opto/callGenerator.cpp
! src/hotspot/share/opto/doCall.cpp
! src/hotspot/share/opto/graphKit.cpp
! src/hotspot/share/opto/parse1.cpp
! src/hotspot/share/opto/type.hpp
! src/hotspot/share/runtime/deoptimization.cpp
! src/hotspot/share/runtime/deoptimization.hpp
! src/hotspot/share/runtime/vmStructs.cpp

Changeset: 59d84787
Author:    Igor Ignatyev 
Date:      2021-06-18 09:56:36 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/59d84787e91e85dba4df45e99aa376f484e6ddff

8268591: a few runtime/jni tests don't need `/othervm`

Reviewed-by: dholmes, mseledtsov

! test/hotspot/jtreg/runtime/jni/atExit/TestAtExit.java
! test/hotspot/jtreg/runtime/jni/checked/TestCheckedEnsureLocalCapacity.java
! test/hotspot/jtreg/runtime/jni/registerNativesWarning/TestRegisterNativesWarning.java

Changeset: 8ccb76eb
Author:    Igor Ignatyev 
Date:      2021-06-18 09:57:44 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/8ccb76eb135c33349860f503745fdff49f158066

8268601: mark hotspot runtime/records tests which ignore external VM flags

Reviewed-by: dholmes, mseledtsov

! test/hotspot/jtreg/runtime/records/RedefineRecord.java

Changeset: 4006fe73
Author:    Igor Ignatyev 
Date:      2021-06-18 09:58:34 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/4006fe735af70b01b2c254264b816fc067bfbd0d

8268597: mark hotspot runtime/symboltable tests which ignore external VM flags

Reviewed-by: dholmes, mseledtsov

! test/hotspot/jtreg/runtime/symboltable/ShortLivedSymbolCleanup.java

Changeset: 9f4f0392
Author:    Igor Ignatyev 
Date:      2021-06-18 09:59:34 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/9f4f039231895f04bcdae4b25e1861f2070f1d8b

8268596: mark hotspot runtime/verifier tests which ignore external VM flags

Reviewed-by: hseigel, mseledtsov

! test/hotspot/jtreg/runtime/verifier/TraceClassRes.java

Changeset: 58eddc81
Author:    Igor Ignatyev 
Date:      2021-06-18 10:00:21 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/58eddc81102c233061de67a1deaa8d8fee8d5857

8268594: runtime/handshake tests don't need WhiteBox after AOT removal

Reviewed-by: dholmes, mseledtsov

! test/hotspot/jtreg/runtime/handshake/HandshakeTimeoutTest.java
! test/hotspot/jtreg/runtime/handshake/HandshakeTransitionTest.java

Changeset: 3e1dc0a7
Author:    Igor Ignatyev 
Date:      2021-06-18 10:01:03 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/3e1dc0a7655f26ad38b5179f720eb4431bcd4cc3

8268598: mark hotspot runtime/stringtable tests which ignore external VM flags

Reviewed-by: hseigel, mseledtsov

! test/hotspot/jtreg/runtime/stringtable/StringTableVerifyTest.java

Changeset: 2f65d402
Author:    Igor Ignatyev 
Date:      2021-06-18 10:01:58 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/2f65d4021f3f51a342419a61bc934863e421f952

8268599: mark hotspot runtime/sealedClasses tests which ignore external VM flags

Reviewed-by: dholmes, mseledtsov

! test/hotspot/jtreg/runtime/sealedClasses/RedefinePermittedSubclass.java
! test/hotspot/jtreg/runtime/sealedClasses/RedefineSealedClass.java

Changeset: 5b198986
Author:    Igor Ignatyev 
Date:      2021-06-18 10:03:21 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/5b198986cef4fa0e77d02136212ecc01ec9b22c0

8268563: mark hotspot serviceability/jvmti tests which ignore external VM flags

Reviewed-by: sspitsyn

! test/hotspot/jtreg/serviceability/jvmti/CanGenerateAllClassHook/CanGenerateAllClassHook.java
! test/hotspot/jtreg/serviceability/jvmti/GetObjectSizeClass.java
! test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineLeak.java
! test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefinePreviousVersions.java
! test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RetransformClassesZeroLength.java
! test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/TransformerDeadlockTest.java

Changeset: 8366c693
Author:    Igor Ignatyev 
Date:      2021-06-18 10:04:25 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/8366c6936eaad411082ec6a9e569da07c5f3f0cd

8268541: mark hotspot serviceability/sa tests which ignore external VM flags

Reviewed-by: sspitsyn

! test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackLineNumbers.java

Changeset: f83c6b8a
Author:    Igor Ignatyev 
Date:      2021-06-18 10:05:15 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/f83c6b8a6a92a37197a3b83ba093f26e820c4ac9

8268531: mark SDTProbesGNULinuxTest as ignoring external VM flags

Reviewed-by: sspitsyn

! test/hotspot/jtreg/serviceability/7170638/SDTProbesGNULinuxTest.java

Changeset: 21abcc4a
Author:    Igor Ignatyev 
Date:      2021-06-18 10:06:12 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/21abcc4a5a539644be93726436ed4454ad9aaf18

8268564: mark hotspot serviceability/attach tests which ignore external VM flags

Reviewed-by: sspitsyn

! test/hotspot/jtreg/serviceability/attach/AttachSetGetFlag.java
! test/hotspot/jtreg/serviceability/attach/AttachWithStalePidFile.java

Changeset: d8a0582a
Author:    Mark Sheppard 
Date:      2021-06-18 10:54:23 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/d8a0582a36340bcc65910f3a34132ec6e04e5d01

8265369: [macos-aarch64] java/net/MulticastSocket/Promiscuous.java failed with "SocketException: Cannot allocate memory"

Reviewed-by: dfuchs, michaelm, chegar

! src/java.base/unix/native/libnet/PlainDatagramSocketImpl.c
! test/jdk/ProblemList.txt

Changeset: f9c8c1c3
Author:    Erik Gahlin 
Date:      2021-06-18 13:51:57 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/f9c8c1c38612abf0f3286c9f353f11788f58ac70

8268903: JFR: RecordingStream::dump is missing @since

Reviewed-by: mgronlun

! src/jdk.jfr/share/classes/jdk/jfr/consumer/RecordingStream.java
! src/jdk.management.jfr/share/classes/jdk/management/jfr/RemoteRecordingStream.java

Changeset: dab00ee5
Author:    Paul Sandoz 
Date:      2021-06-18 14:22:16 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/dab00ee59b73bcd5b8632d127b3d0a324e48e4e5

8266518: Refactor and expand scatter/gather tests

Reviewed-by: sviswanathan

! test/jdk/jdk/incubator/vector/AbstractVectorTest.java
! test/jdk/jdk/incubator/vector/Byte128VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Byte128VectorTests.java
! test/jdk/jdk/incubator/vector/Byte256VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Byte256VectorTests.java
! test/jdk/jdk/incubator/vector/Byte512VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Byte512VectorTests.java
! test/jdk/jdk/incubator/vector/Byte64VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Byte64VectorTests.java
! test/jdk/jdk/incubator/vector/ByteMaxVectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/ByteMaxVectorTests.java
! test/jdk/jdk/incubator/vector/Double128VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Double128VectorTests.java
! test/jdk/jdk/incubator/vector/Double256VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Double256VectorTests.java
! test/jdk/jdk/incubator/vector/Double512VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Double512VectorTests.java
! test/jdk/jdk/incubator/vector/Double64VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Double64VectorTests.java
! test/jdk/jdk/incubator/vector/DoubleMaxVectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/DoubleMaxVectorTests.java
! test/jdk/jdk/incubator/vector/Float128VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Float128VectorTests.java
! test/jdk/jdk/incubator/vector/Float256VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Float256VectorTests.java
! test/jdk/jdk/incubator/vector/Float512VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Float512VectorTests.java
! test/jdk/jdk/incubator/vector/Float64VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Float64VectorTests.java
! test/jdk/jdk/incubator/vector/FloatMaxVectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/FloatMaxVectorTests.java
! test/jdk/jdk/incubator/vector/Int128VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Int128VectorTests.java
! test/jdk/jdk/incubator/vector/Int256VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Int256VectorTests.java
! test/jdk/jdk/incubator/vector/Int512VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Int512VectorTests.java
! test/jdk/jdk/incubator/vector/Int64VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Int64VectorTests.java
! test/jdk/jdk/incubator/vector/IntMaxVectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/IntMaxVectorTests.java
! test/jdk/jdk/incubator/vector/Long128VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Long128VectorTests.java
! test/jdk/jdk/incubator/vector/Long256VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Long256VectorTests.java
! test/jdk/jdk/incubator/vector/Long512VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Long512VectorTests.java
! test/jdk/jdk/incubator/vector/Long64VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Long64VectorTests.java
! test/jdk/jdk/incubator/vector/LongMaxVectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/LongMaxVectorTests.java
! test/jdk/jdk/incubator/vector/Short128VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Short128VectorTests.java
! test/jdk/jdk/incubator/vector/Short256VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Short256VectorTests.java
! test/jdk/jdk/incubator/vector/Short512VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Short512VectorTests.java
! test/jdk/jdk/incubator/vector/Short64VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Short64VectorTests.java
! test/jdk/jdk/incubator/vector/ShortMaxVectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/ShortMaxVectorTests.java
! test/jdk/jdk/incubator/vector/gen-template.sh
- test/jdk/jdk/incubator/vector/templates/Kernel-Gather-Masked-op.template
- test/jdk/jdk/incubator/vector/templates/Kernel-Gather-op.template
- test/jdk/jdk/incubator/vector/templates/Kernel-Scatter-Masked-op.template
- test/jdk/jdk/incubator/vector/templates/Kernel-Scatter-op.template
- test/jdk/jdk/incubator/vector/templates/Unit-Gather-Masked-op.template
- test/jdk/jdk/incubator/vector/templates/Unit-Gather-op.template
- test/jdk/jdk/incubator/vector/templates/Unit-Scatter-Masked-op.template
- test/jdk/jdk/incubator/vector/templates/Unit-Scatter-op.template
! test/jdk/jdk/incubator/vector/templates/Unit-header.template
! test/jdk/jdk/incubator/vector/templates/X-LoadStoreTest.java.template

Changeset: 60389eed
Author:    Igor Ignatyev 
Date:      2021-06-18 15:25:25 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/60389eedb3c9932de57aca740a8116db83302ffa

8269025: jsig/Testjsig.java doesn't check exit code

Reviewed-by: hseigel

! test/hotspot/jtreg/runtime/jsig/Testjsig.java

Changeset: 7e03cf29
Author:    Joe Wang 
Date:      2021-06-18 16:03:30 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/7e03cf2916a69f947c46ac85b222ee7a99f68ad8

8265073: XML transformation and indentation when using xml:space

Reviewed-by: naoto, lancea, iris

! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/ToStream.java
! test/jaxp/javax/xml/jaxp/unittest/common/prettyprint/PrettyPrintTest.java

Changeset: 8caeca00
Author:    Chris Plummer 
Date:      2021-06-18 20:27:30 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/8caeca003e621dd523eb27ef7e7fea0765ceacb6

8264775: ClhsdbFindPC still fails with java.lang.RuntimeException: 'In java stack' missing from stdout/stderr

Reviewed-by: dcubed

! test/hotspot/jtreg/serviceability/sa/ClhsdbFindPC.java

Changeset: b9d73376
Author:    Xin Liu 
Committer: Paul Hohensee 
Date:      2021-06-18 21:29:55 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/b9d7337697bd1aa5581b1a28efb3a78c221f6592

8268638: semaphores of AsyncLogWriter may be broken when JVM is exiting.

Backport-of: fa3b44d43811dca8c609d6c61a58680835abf8e3

! src/hotspot/share/logging/logAsyncWriter.cpp
! src/hotspot/share/logging/logAsyncWriter.hpp

Changeset: b8f073be
Author:    Erik Gahlin 
Date:      2021-06-18 22:05:52 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/b8f073be84b6bf2f83e2a65d20b7eb8c03120dce

8268316: Typo in JFR jdk.Deserialization event

Reviewed-by: iignatyev

! src/jdk.jfr/share/classes/jdk/jfr/events/DeserializationEvent.java

Changeset: b7d78a5b
Author:    Jesper Wilhelmsson 
Date:      2021-06-18 23:04:20 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/b7d78a5b661e2b00f271298db3b6cc873cf754e7

Merge


Changeset: 0b8a0e2b
Author:    Joel Borggr?n-Franck 
Date:      2021-06-21 08:39:35 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/0b8a0e2b58dbdd5c9553e502212d32c033a5efb5

8266082: AssertionError in Annotate.fromAnnotations with -Xdoclint

Reviewed-by: vromero

! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/ReferenceParser.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties
+ test/langtools/tools/doclint/CrashInAnnotateTest.java
+ test/langtools/tools/doclint/CrashInAnnotateTest.out
+ test/langtools/tools/javac/diags/examples/NoAnnotationsInLink.java

Changeset: 1692fd2e
Author:    Thomas Schatzl 
Date:      2021-06-21 10:06:05 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/1692fd2eba7164ebd11fce1c02696a9053d131af

8017163: G1: Refactor remembered sets
8048504: G1: Investigate replacing the coarse and fine grained data structures in the remembered sets
6949259: G1: Merge sparse and fine remembered set hash tables

Co-authored-by: Ivan Walulya 
Co-authored-by: Thomas Schatzl 
Reviewed-by: sjohanss, iwalulya

! src/hotspot/share/gc/g1/g1Arguments.cpp
! src/hotspot/share/gc/g1/g1Arguments.hpp
+ src/hotspot/share/gc/g1/g1CardSet.cpp
+ src/hotspot/share/gc/g1/g1CardSet.hpp
+ src/hotspot/share/gc/g1/g1CardSet.inline.hpp
+ src/hotspot/share/gc/g1/g1CardSetContainers.hpp
+ src/hotspot/share/gc/g1/g1CardSetContainers.inline.hpp
+ src/hotspot/share/gc/g1/g1CardSetFreeMemoryTask.cpp
+ src/hotspot/share/gc/g1/g1CardSetFreeMemoryTask.hpp
+ src/hotspot/share/gc/g1/g1CardSetMemory.cpp
+ src/hotspot/share/gc/g1/g1CardSetMemory.hpp
+ src/hotspot/share/gc/g1/g1CardSetMemory.inline.hpp
! src/hotspot/share/gc/g1/g1CardTable.hpp
! src/hotspot/share/gc/g1/g1CardTable.inline.hpp
! 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/g1CollectionSet.cpp
! src/hotspot/share/gc/g1/g1CollectionSetChooser.cpp
! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp
! src/hotspot/share/gc/g1/g1ConcurrentMark.inline.hpp
! src/hotspot/share/gc/g1/g1DirtyCardQueue.cpp
! src/hotspot/share/gc/g1/g1EvacFailure.cpp
! src/hotspot/share/gc/g1/g1FullGCOopClosures.inline.hpp
! src/hotspot/share/gc/g1/g1GCPhaseTimes.cpp
! src/hotspot/share/gc/g1/g1GCPhaseTimes.hpp
! src/hotspot/share/gc/g1/g1OopClosures.inline.hpp
! src/hotspot/share/gc/g1/g1ParScanThreadState.hpp
! src/hotspot/share/gc/g1/g1Policy.cpp
! src/hotspot/share/gc/g1/g1RemSet.cpp
! src/hotspot/share/gc/g1/g1RemSet.hpp
! src/hotspot/share/gc/g1/g1RemSetSummary.cpp
! src/hotspot/share/gc/g1/g1RemSetSummary.hpp
! src/hotspot/share/gc/g1/g1RemSetTrackingPolicy.cpp
! src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.cpp
! src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.hpp
! src/hotspot/share/gc/g1/g1_globals.hpp
! 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
! src/hotspot/share/gc/g1/heapRegionRemSet.inline.hpp
! src/hotspot/share/gc/g1/heapRegionSet.cpp
! src/hotspot/share/gc/g1/jvmFlagConstraintsG1.cpp
! src/hotspot/share/gc/g1/jvmFlagConstraintsG1.hpp
- src/hotspot/share/gc/g1/sparsePRT.cpp
- src/hotspot/share/gc/g1/sparsePRT.hpp
! src/hotspot/share/gc/shared/cardTable.hpp
! src/hotspot/share/gc/shared/workerDataArray.hpp
! src/hotspot/share/memory/allocation.hpp
! src/hotspot/share/prims/whitebox.cpp
! src/hotspot/share/runtime/arguments.cpp
! src/hotspot/share/utilities/concurrentHashTable.hpp
! src/hotspot/share/utilities/concurrentHashTable.inline.hpp
! test/hotspot/gtest/gc/g1/test_freeRegionList.cpp
+ test/hotspot/gtest/gc/g1/test_g1CardSet.cpp
+ test/hotspot/gtest/gc/g1/test_g1CardSetContainers.cpp
+ test/hotspot/jtreg/gc/arguments/TestG1RemSetFlags.java
! test/hotspot/jtreg/gc/g1/TestGCLogMessages.java
! test/hotspot/jtreg/gc/g1/TestNoEagerReclaimOfHumongousRegions.java
! test/hotspot/jtreg/gc/stress/TestStressRSetCoarsening.java
! test/hotspot/jtreg/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java
! test/hotspot/jtreg/runtime/NMT/MallocSiteTypeChange.java
! test/jdk/jdk/jfr/event/gc/collection/TestG1ParallelPhases.java

Changeset: cbec37d4
Author:    Christoph G?ttschkes 
Committer: Jie Fu 
Date:      2021-06-21 11:08:33 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/cbec37d45d77533081c27b3fc649098dfcca0425

8269029: compiler/codegen/TestCharVect2.java fails for client VMs

Reviewed-by: kvn, jiefu

! test/hotspot/jtreg/compiler/codegen/TestCharVect2.java

Changeset: a58c477c
Author:    Thomas Schatzl 
Date:      2021-06-21 11:11:14 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/a58c477c49ca595c65f7a2fca2512ff2adea99be

8268952: Automatically update heap sizes in G1MonitoringScope

Reviewed-by: kbarrett, iwalulya

! src/hotspot/share/gc/g1/g1CollectedHeap.cpp
! src/hotspot/share/gc/g1/g1FullGCScope.cpp
! src/hotspot/share/gc/g1/g1MonitoringSupport.cpp
! src/hotspot/share/gc/g1/g1MonitoringSupport.hpp

Changeset: cd20c019
Author:    Thomas Schatzl 
Date:      2021-06-21 11:12:29 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/cd20c01942dd8559a31e51ef2a595c6eba44b8ad

8268458: Add verification type for evacuation failures

Reviewed-by: kbarrett, iwalulya

! src/hotspot/share/gc/g1/g1Arguments.cpp
! src/hotspot/share/gc/g1/g1CollectedHeap.cpp
! src/hotspot/share/gc/g1/g1HeapVerifier.cpp
! src/hotspot/share/gc/g1/g1HeapVerifier.hpp
! test/hotspot/gtest/gc/g1/test_g1HeapVerifier.cpp
! test/hotspot/jtreg/gc/g1/TestVerifyGCType.java

Changeset: b358b54c
Author:    Jie Fu 
Date:      2021-06-20 22:55:49 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/b358b54c4fb515be519ad631c0ae7c58f49fdc5b

8269063: Build failure due to VerifyReceiverTypes was not declared after JDK-8268405

Reviewed-by: kvn

! src/hotspot/share/runtime/deoptimization.cpp

Changeset: c294ae4f
Author:    Boris Ulasevich 
Date:      2021-06-21 06:04:57 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/c294ae4fed59c7e303416346cc4b189a48bc1ab1

8267042: bug in monitor locking/unlocking on ARM32 C1 due to uninitialized BasicObjectLock::_displaced_header

Co-authored-by: Chris Cole 
Reviewed-by: dsamersoff

! src/hotspot/cpu/arm/c1_MacroAssembler_arm.cpp
! src/hotspot/cpu/arm/sharedRuntime_arm.cpp
+ test/hotspot/jtreg/compiler/c1/Test8267042.java

Changeset: f8df953e
Author:    Markus Gr?nlund 
Date:      2021-06-21 11:16:41 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/f8df953e61372b396f351403ff6ba165720881bb

8268702: JFR diagnostic commands lack argument descriptors when viewed using Platform MBean Server

Reviewed-by: egahlin

! src/hotspot/share/jfr/dcmd/jfrDcmds.cpp
! src/hotspot/share/jfr/dcmd/jfrDcmds.hpp
! src/jdk.jfr/share/classes/jdk/jfr/internal/dcmd/AbstractDCmd.java

Changeset: 22ebd192
Author:    Hui Shi 
Date:      2021-06-21 11:59:00 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/22ebd1926d4510cbe40cb186edf16cbd44a29347

8268362: [REDO] C2 crash when compile negative Arrays.copyOf length after loop

Reviewed-by: kvn, roland

! src/hotspot/share/opto/callnode.cpp
! src/hotspot/share/opto/graphKit.cpp
! src/hotspot/share/opto/graphKit.hpp
! src/hotspot/share/opto/library_call.cpp
+ test/hotspot/jtreg/compiler/arraycopy/TestNegArrayLengthAsIndex1.java
+ test/hotspot/jtreg/compiler/arraycopy/TestNegArrayLengthAsIndex2.java
+ test/hotspot/jtreg/compiler/arraycopy/TestNegativeArrayCopyAfterLoop.java

Changeset: f25e7197
Author:    Jorn Vernee 
Date:      2021-06-21 12:06:51 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/f25e7197fef76cc87a15da7cc96a42b84d69bbfe

8268717: Upstream: 8268673: Stack walk across optimized entry frame on fresh native thread fails

Reviewed-by: mcimadamore, erikj

! make/test/JtregNativeJdk.gmk
! src/hotspot/cpu/aarch64/frame_aarch64.cpp
! src/hotspot/cpu/arm/frame_arm.cpp
! src/hotspot/cpu/ppc/frame_ppc.cpp
! src/hotspot/cpu/s390/frame_s390.cpp
! src/hotspot/cpu/x86/frame_x86.cpp
! src/hotspot/cpu/zero/frame_zero.cpp
! src/hotspot/share/prims/whitebox.cpp
! src/hotspot/share/runtime/frame.hpp
! src/hotspot/share/runtime/frame.inline.hpp
+ test/jdk/java/foreign/stackwalk/TestAsyncStackWalk.java
+ test/jdk/java/foreign/stackwalk/libAsyncStackWalk.cpp

Changeset: d3ad8cd3
Author:    Roland Westrelin 
Date:      2021-06-21 14:16:54 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/d3ad8cd344681fe8442f821f97f05996bb972abe

8268672: C2: assert(!loop->is_member(u_loop)) failed: can be in outer loop or out of both loops only

Reviewed-by: kvn, neliasso

! src/hotspot/share/opto/loopopts.cpp
+ test/hotspot/jtreg/compiler/loopstripmining/TestPinnedNodeInInnerLoop.java

Changeset: 0458113c
Author:    Jesper Wilhelmsson 
Date:      2021-06-21 23:09:01 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/0458113c6b1cf500ffdf049c1e3a698b16ce12ce

Merge

! src/hotspot/share/prims/whitebox.cpp
! src/hotspot/share/prims/whitebox.cpp

Changeset: 1a818154
Author:    Stefan Karlsson 
Date:      2021-06-22 07:44:25 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/1a818154cfe852a680070c5c07f2df33109e5b54

8269077: TestSystemGC uses "require vm.gc.G1" for large pages subtest

Reviewed-by: tschatzl, kbarrett

! test/hotspot/jtreg/gc/TestSystemGC.java

Changeset: 1f0ea7c3
Author:    Denghui Dong 
Committer: Yi Yang 
Date:      2021-06-22 08:28:18 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/1f0ea7c3d62221405de982ba484c0ee985fa9d7b

8268857: Merge VM_PrintJNI and VM_PrintThreads and remove the unused field 'is_deadlock' of DeadlockCycle

Reviewed-by: dholmes

! src/hotspot/share/runtime/os.cpp
! src/hotspot/share/runtime/vmOperation.hpp
! src/hotspot/share/runtime/vmOperations.cpp
! src/hotspot/share/runtime/vmOperations.hpp
! src/hotspot/share/services/attachListener.cpp
! src/hotspot/share/services/diagnosticCommand.cpp
! src/hotspot/share/services/threadService.cpp
! src/hotspot/share/services/threadService.hpp

Changeset: 2e639dd3
Author:    Yi Yang 
Date:      2021-06-22 08:30:08 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/2e639dd34a4342de6e1b9470448d66ef89c4bd52

8267657: Add missing PrintC1Statistics before incrementing counters

Reviewed-by: iveresov

! src/hotspot/cpu/aarch64/c1_CodeStubs_aarch64.cpp
! src/hotspot/cpu/ppc/c1_CodeStubs_ppc.cpp
! src/hotspot/cpu/s390/c1_CodeStubs_s390.cpp
! src/hotspot/cpu/x86/c1_CodeStubs_x86.cpp
! src/hotspot/share/c1/c1_Runtime1.cpp
! src/hotspot/share/runtime/sharedRuntime.cpp
! src/hotspot/share/runtime/sharedRuntime.hpp

Changeset: 18a1dd26
Author:    Matthias Baesken 
Date:      2021-06-22 13:28:41 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/18a1dd261cec6fa1c5820dce2df47d488417afff

8269031: linux x86_64 check for binutils 2.25 or higher after 8265783

Reviewed-by: ihse, erikj

! make/autoconf/toolchain.m4

Changeset: 33c23a1c
Author:    Coleen Phillimore 
Date:      2021-06-22 16:09:17 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/33c23a1cf2aa81551eee4a2acf271edf573558aa

8264941: Remove CodeCache::mark_for_evol_deoptimization() method

Reviewed-by: kvn, vlivanov, sspitsyn

! src/hotspot/share/code/codeCache.cpp
! src/hotspot/share/code/codeCache.hpp
! src/hotspot/share/prims/jvmtiExport.cpp
! src/hotspot/share/prims/jvmtiExport.hpp
! src/hotspot/share/prims/jvmtiManageCapabilities.cpp
! src/hotspot/share/prims/jvmtiRedefineClasses.cpp
! src/hotspot/share/prims/jvmtiRedefineClasses.hpp

Changeset: 0c693e2f
Author:    Kim Barrett 
Date:      2021-06-22 17:43:59 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/0c693e2f03b1adef0e946ebc32827ac09192f5f0

8268290: Improve LockFreeQueue<> utility

Reviewed-by: iwalulya, tschatzl

! src/hotspot/share/gc/g1/g1DirtyCardQueue.cpp
! src/hotspot/share/gc/g1/g1DirtyCardQueue.hpp
- src/hotspot/share/utilities/lockFreeQueue.hpp
- src/hotspot/share/utilities/lockFreeQueue.inline.hpp
+ src/hotspot/share/utilities/nonblockingQueue.hpp
+ src/hotspot/share/utilities/nonblockingQueue.inline.hpp
- test/hotspot/gtest/utilities/test_lockFreeQueue.cpp
+ test/hotspot/gtest/utilities/test_nonblockingQueue.cpp

Changeset: e2d7ec38
Author:    Weijun Wang 
Date:      2021-06-22 00:41:45 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/e2d7ec38af4e13cfbd303fa37e766aa2071cfd1f

8267100: [BACKOUT] JDK-8196415 Disable SHA-1 Signed JARs

Co-authored-by: Sean Mullan 
Reviewed-by: hchao, xuelei

! src/java.base/share/conf/security/java.security

Changeset: 4099810b
Author:    Jatin Bhateja 
Date:      2021-06-22 01:31:48 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/4099810b290d90c4c928e66c601744911b770f24

8268293: VectorAPI cast operation on mask and shuffle is broken

Reviewed-by: psandoz, sviswanathan

! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte128Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte256Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte512Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte64Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteMaxVector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double128Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double256Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double512Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double64Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/DoubleMaxVector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float128Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float256Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float512Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float64Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/FloatMaxVector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int128Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int256Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int512Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int64Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/IntMaxVector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long128Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long256Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long512Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long64Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/LongMaxVector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short128Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short256Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short512Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short64Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ShortMaxVector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-VectorBits.java.template
! test/jdk/jdk/incubator/vector/AbstractVectorConversionTest.java
! test/jdk/jdk/incubator/vector/Vector128ConversionTests.java
! test/jdk/jdk/incubator/vector/Vector256ConversionTests.java
! test/jdk/jdk/incubator/vector/Vector512ConversionTests.java
! test/jdk/jdk/incubator/vector/Vector64ConversionTests.java
! test/jdk/jdk/incubator/vector/VectorMaxConversionTests.java

Changeset: ef4ba224
Author:    Weijun Wang 
Date:      2021-06-22 02:06:59 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/ef4ba224c4887b2e307937754064d3623a2d3de5

8268349: Provide clear run-time warnings about Security Manager deprecation

Reviewed-by: lancea, mullan, alanb

! src/java.base/share/classes/java/lang/System.java
! test/jdk/java/lang/System/LoggerFinder/internal/LoggerFinderLoaderTest/LoggerFinderLoaderTest.java
! test/jdk/java/lang/System/SecurityManagerWarnings.java
! test/jdk/java/lang/invoke/lambda/LogGeneratedClassesTest.java
! test/jdk/java/net/spi/URLStreamHandlerProvider/Basic.java
! test/jdk/java/security/ProtectionDomain/RecursionDebug.java

Changeset: 6b14c8a1
Author:    Vicente Romero 
Date:      2021-06-22 02:08:15 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/6b14c8a1e5316b6c8584e93ee7a94d9eaec676cf

8267421: j.l.constant.DirectMethodHandleDesc.Kind.valueOf(int) implementation doesn't conform to the spec regarding REF_invokeInterface handling

Reviewed-by: mchung

! src/java.base/share/classes/java/lang/constant/DirectMethodHandleDesc.java
! test/jdk/java/lang/constant/MethodHandleDescTest.java

Changeset: 01f12fba
Author:    Jan Lahoda 
Date:      2021-06-22 07:34:30 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/01f12fba648b8c0cb64870b00e6f0f3a7f0ba4c9

8266631: StandardJavaFileManager: getJavaFileObjects() impl violates the spec
8266596: StandardJavaFileManager: default impls of setLocationFromPaths(), getJavaFileObjectsFromPaths() methods don't throw IllegalArgumentException as specified
8266591: StandardJavaFileManager::getJavaFileObjectsFromPaths() methods contain a typo in their spec
8266590: StandardJavaFileManager::setLocationFromPaths() spec contains an error

Reviewed-by: vromero, jjg

! src/java.compiler/share/classes/javax/tools/StandardJavaFileManager.java

Changeset: 9ec7180f
Author:    Erik ?sterlund 
Date:      2021-06-22 15:20:10 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/9ec7180f1ebf2ff19b0735f7b1c4fc9b97d632be

8268524: nmethod::post_compiled_method_load_event racingly called on zombie

Reviewed-by: kvn, neliasso, coleenp

! src/hotspot/share/code/nmethod.cpp
! src/hotspot/share/prims/jvmtiCodeBlobEvents.cpp

Changeset: 8fa25208
Author:    Jorn Vernee 
Date:      2021-06-22 15:27:43 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/8fa2520803c9b9be41b26b4b34b7d2040a7b1dfb

8268888: Upstream 8268230: Foreign Linker API & Windows user32/kernel32: String conversion seems broken

Reviewed-by: mcimadamore

! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java
! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/SharedUtils.java
+ test/jdk/java/foreign/TestNULLAddress.java
- test/jdk/java/foreign/TestNULLTarget.java
+ test/jdk/java/foreign/TestStringEncoding.java
! test/jdk/java/foreign/handles/lookup_module/handle/lookup/MethodHandleLookup.java

Changeset: 578c55bb
Author:    Roland Westrelin 
Date:      2021-06-22 15:46:44 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/578c55bbe65baec733bb633afbc1423010fa6aed

8267399: C2: java/text/Normalizer/ConformanceTest.java test failed with assertion

Reviewed-by: kvn, neliasso

! src/hotspot/share/opto/loopTransform.cpp
+ test/hotspot/jtreg/compiler/loopopts/TestDeadCountedLoop.java

Changeset: dc12cb78
Author:    Nils Eliasson 
Date:      2021-06-22 16:21:35 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/dc12cb78b81f56e9d4b282cf7cad5faa9a9886bf

8267652: c2 loop unrolling by 8 results in reading memory past array

Reviewed-by: sviswanathan, kvn, vlivanov

! src/hotspot/cpu/x86/x86.ad

Changeset: 35e4c272
Author:    Andy Herrick 
Date:      2021-06-22 19:08:58 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/35e4c2720df64ea6cb68ba8fb62aeeb0562c2907

8268404: [TESTBUG] tools/jpackage/windows/WinInstallerIconTest.java failed "AssertionError: Failed: Check icon"

Reviewed-by: asemenyuk

! test/jdk/ProblemList.txt
! test/jdk/tools/jpackage/windows/WinInstallerIconTest.java

Changeset: b6cfca8a
Author:    Jesper Wilhelmsson 
Date:      2021-06-23 01:05:44 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/b6cfca8a89810c7ed63ebc34ed9855b66ebcb5d9

Merge


Changeset: cd678a38
Author:    Guoxiong Li 
Committer: David Holmes 
Date:      2021-06-23 02:21:24 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/cd678a383f7b23ea40132b207ddfc041394ba4c1

8268368: Adopt cast notation for JavaThread conversions

Reviewed-by: dholmes, stefank

! src/hotspot/cpu/zero/frame_zero.cpp
! src/hotspot/os/windows/os_windows.cpp
! src/hotspot/share/code/dependencies.cpp
! src/hotspot/share/compiler/compileBroker.cpp
! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp
! src/hotspot/share/gc/shared/cardTableBarrierSet.cpp
! src/hotspot/share/gc/shared/memAllocator.cpp
! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.cpp
! src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp
! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.cpp
! src/hotspot/share/gc/z/zBarrierSet.cpp
! src/hotspot/share/gc/z/zFuture.inline.hpp
! src/hotspot/share/gc/z/zMark.cpp
! src/hotspot/share/gc/z/zObjArrayAllocator.cpp
! src/hotspot/share/gc/z/zVerify.cpp
! src/hotspot/share/jfr/jni/jfrJavaSupport.cpp
! src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp
! src/hotspot/share/jfr/recorder/checkpoint/jfrCheckpointManager.cpp
! src/hotspot/share/jfr/recorder/checkpoint/types/jfrThreadState.cpp
! src/hotspot/share/jfr/recorder/checkpoint/types/jfrType.cpp
! src/hotspot/share/jfr/recorder/repository/jfrEmergencyDump.cpp
! src/hotspot/share/jfr/recorder/service/jfrPostBox.cpp
! src/hotspot/share/jfr/recorder/stacktrace/jfrStackTraceRepository.cpp
! src/hotspot/share/jfr/support/jfrThreadLocal.cpp
! src/hotspot/share/jfr/writers/jfrJavaEventWriter.cpp
! src/hotspot/share/jvmci/jvmciCompilerToVM.cpp
! src/hotspot/share/jvmci/jvmciEnv.cpp
! src/hotspot/share/oops/constantPool.cpp
! src/hotspot/share/oops/generateOopMap.cpp
! src/hotspot/share/oops/instanceKlass.cpp
! src/hotspot/share/oops/method.cpp
! src/hotspot/share/prims/jni.cpp
! src/hotspot/share/prims/jniCheck.cpp
! src/hotspot/share/prims/jvmtiEnter.xsl
! src/hotspot/share/prims/jvmtiEnvBase.cpp
! src/hotspot/share/prims/jvmtiEnvThreadState.cpp
! src/hotspot/share/prims/jvmtiEventController.cpp
! src/hotspot/share/prims/jvmtiExport.cpp
! src/hotspot/share/prims/jvmtiRawMonitor.cpp
! src/hotspot/share/prims/jvmtiTrace.cpp
! src/hotspot/share/prims/universalUpcallHandler.cpp
! src/hotspot/share/prims/whitebox.cpp
! src/hotspot/share/runtime/deoptimization.cpp
! src/hotspot/share/runtime/handshake.cpp
! src/hotspot/share/runtime/interfaceSupport.cpp
! src/hotspot/share/runtime/interfaceSupport.inline.hpp
! src/hotspot/share/runtime/java.cpp
! src/hotspot/share/runtime/jniHandles.cpp
! src/hotspot/share/runtime/mutex.cpp
! src/hotspot/share/runtime/objectMonitor.cpp
! src/hotspot/share/runtime/os.cpp
! src/hotspot/share/runtime/safepoint.cpp
! src/hotspot/share/runtime/safepointVerifiers.cpp
! src/hotspot/share/runtime/sharedRuntime.cpp
! src/hotspot/share/runtime/stackWatermarkSet.cpp
! src/hotspot/share/runtime/sweeper.cpp
! src/hotspot/share/runtime/synchronizer.cpp
! src/hotspot/share/runtime/thread.cpp
! src/hotspot/share/runtime/thread.hpp
! src/hotspot/share/runtime/vmOperations.cpp
! src/hotspot/share/runtime/vmThread.cpp
! src/hotspot/share/services/threadService.cpp
! src/hotspot/share/utilities/vmError.cpp

Changeset: ae3eedce
Author:    miao zheng 
Committer: Hui Shi 
Date:      2021-06-23 02:45:58 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/ae3eedce9d17324f89daccf488e00d8c7858521e

8268727: Remove unused slowpath locking method in OptoRuntime

Reviewed-by: dlong

! src/hotspot/share/opto/runtime.hpp

Changeset: 36d82b6e
Author:    Joshua Zhu 
Committer: Yi Yang 
Date:      2021-06-23 03:54:00 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/36d82b6ef18d8add5f97fad507b7d86d702bdf13

8268858: Determine register pressure automatically by the number of available registers for allocation

Reviewed-by: kvn, dlong

! src/hotspot/cpu/aarch64/aarch64.ad
! src/hotspot/cpu/aarch64/c2_globals_aarch64.hpp
! src/hotspot/cpu/arm/arm.ad
! src/hotspot/cpu/arm/c2_globals_arm.hpp
! src/hotspot/cpu/ppc/c2_globals_ppc.hpp
! src/hotspot/cpu/ppc/ppc.ad
! src/hotspot/cpu/s390/c2_globals_s390.hpp
! src/hotspot/cpu/s390/s390.ad
! src/hotspot/cpu/x86/c2_globals_x86.hpp
! src/hotspot/cpu/x86/x86.ad
! src/hotspot/cpu/x86/x86_32.ad
! src/hotspot/cpu/x86/x86_64.ad
! src/hotspot/share/opto/c2_globals.hpp
! src/hotspot/share/opto/chaitin.cpp
! src/hotspot/share/opto/ifg.cpp
! src/hotspot/share/opto/lcm.cpp
! src/hotspot/share/opto/matcher.hpp
! src/hotspot/share/opto/reg_split.cpp
! src/hotspot/share/opto/superword.cpp
+ test/hotspot/jtreg/compiler/regalloc/TestC2IntPressure.java

Changeset: 17daf32a
Author:    Aleksey Shipilev 
Date:      2021-06-23 06:27:40 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/17daf32a073bc4f12602b4872ce708e09c453ced

8269138: Move typeArrayOop.inline.hpp include to vectorSupport.cpp

Reviewed-by: stefank, vlivanov

! src/hotspot/share/prims/vectorSupport.cpp
! src/hotspot/share/prims/vectorSupport.hpp

Changeset: a5e43070
Author:    Thomas Schatzl 
Date:      2021-06-23 06:51:53 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/a5e4307050d19c842c08ad96b3a0c36e7dee1951

8269134: Remove sparsePRT.inline.hpp after JDK-8017163

Reviewed-by: iwalulya, kbarrett

- src/hotspot/share/gc/g1/sparsePRT.inline.hpp

Changeset: 62376306
Author:    Aleksey Shipilev 
Date:      2021-06-23 07:03:51 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/6237630664fd956aa6025a181e9cb874806dcecf

8269120: Build failure with GCC 6.3.0 after JDK-8017163

Reviewed-by: iwalulya, tschatzl, kbarrett

! src/hotspot/share/gc/g1/g1CardSetMemory.hpp

Changeset: 2c29d790
Author:    miao zheng 
Committer: Hui Shi 
Date:      2021-06-23 08:51:35 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/2c29d790cac0525130ade6caf10a60ba5a1320a9

8269206: A small typo in comment in test/lib/sun/hotspot/WhiteBox.java

Reviewed-by: dholmes

! test/lib/sun/hotspot/WhiteBox.java

Changeset: f2e690e0
Author:    Harold Seigel 
Date:      2021-06-23 12:11:37 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/f2e690e0ee503794cb50740170912697640d70ff

8268720: Unspecified checks on NameAndType constants should not be performed

Reviewed-by: dholmes, lfoltan

! src/hotspot/share/classfile/classFileParser.cpp
! src/hotspot/share/classfile/classFileParser.hpp
+ test/hotspot/jtreg/runtime/classFileParserBug/NameAndTypeSig.java
+ test/hotspot/jtreg/runtime/classFileParserBug/nonVoidInitSig.jcod

Changeset: 52d5d1b3
Author:    Coleen Phillimore 
Date:      2021-06-23 14:26:30 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/52d5d1b3617731bf312aa5813bf7e78ca4dacb00

8269188: [BACKOUT] Remove CodeCache::mark_for_evol_deoptimization() method

Reviewed-by: dholmes, sspitsyn

! src/hotspot/share/code/codeCache.cpp
! src/hotspot/share/code/codeCache.hpp
! src/hotspot/share/prims/jvmtiExport.cpp
! src/hotspot/share/prims/jvmtiExport.hpp
! src/hotspot/share/prims/jvmtiManageCapabilities.cpp
! src/hotspot/share/prims/jvmtiRedefineClasses.cpp
! src/hotspot/share/prims/jvmtiRedefineClasses.hpp

Changeset: f3ba2690
Author:    Coleen Phillimore 
Date:      2021-06-23 14:27:31 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/f3ba2690c5b34673ebf6836c87e45477e1ff91c3

8256306: ObjectMonitor::_contentions field should not be 'jint'

Reviewed-by: dholmes, stuefe, dcubed

! src/hotspot/share/runtime/objectMonitor.cpp
! src/hotspot/share/runtime/objectMonitor.hpp
! src/hotspot/share/runtime/objectMonitor.inline.hpp
! src/hotspot/share/runtime/vmStructs.cpp
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/ObjectMonitor.java

Changeset: 7621fa37
Author:    Mahendra Chhipa 
Committer: Michael McMahon 
Date:      2021-06-23 15:19:10 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/7621fa37efb2739b953da1cda87dca4762b5bd0c

8268464: Remove dependancy of TestHttpsServer, HttpTransaction, HttpCallback from open/test/jdk/sun/net/www/protocol/https/ tests

Reviewed-by: dfuchs, michaelm

- test/jdk/sun/net/www/protocol/https/AbstractCallback.java
! test/jdk/sun/net/www/protocol/https/ChunkedOutputStream.java
- test/jdk/sun/net/www/protocol/https/HttpCallback.java
- test/jdk/sun/net/www/protocol/https/HttpTransaction.java
! test/jdk/sun/net/www/protocol/https/HttpsURLConnection/B6216082.java
! test/jdk/sun/net/www/protocol/https/HttpsURLConnection/TunnelProxy.java
- test/jdk/sun/net/www/protocol/https/TestHttpsServer.java

Changeset: f3759164
Author:    Coleen Phillimore 
Date:      2021-06-23 21:11:06 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/f3759164179b2471d34df1225085deaf6c0f8fed

8269186: [REDO] Remove CodeCache::mark_for_evol_deoptimization() method

Reviewed-by: hseigel, lfoltan, sspitsyn

! src/hotspot/share/code/codeCache.cpp
! src/hotspot/share/code/codeCache.hpp
! src/hotspot/share/prims/jvmtiRedefineClasses.cpp
! src/hotspot/share/prims/jvmtiRedefineClasses.hpp

Changeset: 280f2d57
Author:    Alex Menkov 
Date:      2021-06-24 00:28:45 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/280f2d57d1f78b3d15dd98e726267a100eb0b5db

8268433: serviceability/dcmd/framework/VMVersionTest.java fails with Unable to send object throw not established PipeIO Listener Thread connection

Reviewed-by: sspitsyn, cjplummer

! test/hotspot/jtreg/ProblemList-zgc.txt
! test/hotspot/jtreg/serviceability/dcmd/framework/TestProcessLauncher.java

Changeset: 51d91597
Author:    Alex Menkov 
Date:      2021-06-24 00:29:36 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/51d915979cec4f4d7f20df8e5d3394025d7a3dc7

8236212: CompiledMethodLoad and CompiledMethodUnload events can be posted in START phase

Reviewed-by: sspitsyn, cjplummer

! test/hotspot/jtreg/vmTestbase/nsk/jvmti/CompiledMethodLoad/compmethload001/compmethload001.cpp
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/CompiledMethodUnload/compmethunload001/compmethunload001.cpp

Changeset: e515873f
Author:    Aleksey Shipilev 
Date:      2021-06-24 06:36:30 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/e515873f887ce4071ab4878a4bafca8eea67afea

8269216: Useless initialization in com/sun/crypto/provider/PBES2Parameters.java

Reviewed-by: valeriep

! src/java.base/share/classes/com/sun/crypto/provider/PBES2Parameters.java

Changeset: 7c31903d
Author:    Yumin Qi 
Date:      2021-06-24 14:52:47 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/7c31903dd3f2f27de1c352294558a4c1bd6c51e7

8267075: jcmd VM.cds should print directory of the output files

Reviewed-by: ccheung

! src/java.base/share/classes/jdk/internal/misc/CDS.java
! test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTestDumpBase.java
! test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTestFileSafety.java

Changeset: 595446bf
Author:    Christoph G?ttschkes 
Committer: Igor Veresov 
Date:      2021-06-24 16:49:45 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/595446bff4af65a30fc88470f20baec2199cd139

8269087: CheckSegmentedCodeCache test fails in an emulated-client VM

Reviewed-by: iveresov, kvn

! test/hotspot/jtreg/compiler/codecache/CheckSegmentedCodeCache.java

Changeset: 2fd7943e
Author:    Patricio Chilano Mateo 
Date:      2021-06-24 18:54:41 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/2fd7943ec191559bfb2778305daf82bcc4422028

8256425: Obsolete Biased Locking in JDK 18

Reviewed-by: kvn, dholmes, dcubed, rrich

! make/hotspot/lib/JvmFeatures.gmk
! src/hotspot/cpu/aarch64/aarch64.ad
! src/hotspot/cpu/aarch64/assembler_aarch64.hpp
! src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/c1_LIRGenerator_aarch64.cpp
! src/hotspot/cpu/aarch64/c1_MacroAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/c1_MacroAssembler_aarch64.hpp
! src/hotspot/cpu/aarch64/interp_masm_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/cpu/aarch64/templateTable_aarch64.cpp
! src/hotspot/cpu/arm/arm.ad
! src/hotspot/cpu/arm/assembler_arm.cpp
! src/hotspot/cpu/arm/assembler_arm_32.cpp
! src/hotspot/cpu/arm/c1_LIRAssembler_arm.cpp
! src/hotspot/cpu/arm/c1_LIRGenerator_arm.cpp
! src/hotspot/cpu/arm/c1_MacroAssembler_arm.cpp
! src/hotspot/cpu/arm/c1_MacroAssembler_arm.hpp
! src/hotspot/cpu/arm/c2_MacroAssembler_arm.cpp
! src/hotspot/cpu/arm/c2_MacroAssembler_arm.hpp
! src/hotspot/cpu/arm/interp_masm_arm.cpp
! src/hotspot/cpu/arm/macroAssembler_arm.cpp
! src/hotspot/cpu/arm/macroAssembler_arm.hpp
! src/hotspot/cpu/arm/sharedRuntime_arm.cpp
! src/hotspot/cpu/arm/templateTable_arm.cpp
! src/hotspot/cpu/arm/vm_version_arm.hpp
! src/hotspot/cpu/arm/vm_version_arm_32.cpp
! src/hotspot/cpu/ppc/assembler_ppc.cpp
! src/hotspot/cpu/ppc/c1_MacroAssembler_ppc.cpp
! src/hotspot/cpu/ppc/interp_masm_ppc_64.cpp
! src/hotspot/cpu/ppc/macroAssembler_ppc.cpp
! src/hotspot/cpu/ppc/macroAssembler_ppc.hpp
! src/hotspot/cpu/ppc/ppc.ad
! src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp
! src/hotspot/cpu/ppc/templateTable_ppc_64.cpp
! src/hotspot/cpu/ppc/vm_version_ppc.cpp
! src/hotspot/cpu/ppc/vm_version_ppc.hpp
! src/hotspot/cpu/s390/assembler_s390.cpp
! src/hotspot/cpu/s390/c1_MacroAssembler_s390.cpp
! src/hotspot/cpu/s390/interp_masm_s390.cpp
! src/hotspot/cpu/s390/macroAssembler_s390.cpp
! src/hotspot/cpu/s390/macroAssembler_s390.hpp
! src/hotspot/cpu/s390/s390.ad
! src/hotspot/cpu/s390/sharedRuntime_s390.cpp
! src/hotspot/cpu/s390/templateTable_s390.cpp
! src/hotspot/cpu/x86/assembler_x86.cpp
! src/hotspot/cpu/x86/assembler_x86.hpp
! src/hotspot/cpu/x86/c1_LIRAssembler_x86.cpp
! src/hotspot/cpu/x86/c1_LIRGenerator_x86.cpp
! src/hotspot/cpu/x86/c1_MacroAssembler_x86.cpp
! src/hotspot/cpu/x86/c1_MacroAssembler_x86.hpp
! src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp
! src/hotspot/cpu/x86/c2_MacroAssembler_x86.hpp
! src/hotspot/cpu/x86/interp_masm_x86.cpp
! src/hotspot/cpu/x86/macroAssembler_x86.cpp
! src/hotspot/cpu/x86/macroAssembler_x86.hpp
! src/hotspot/cpu/x86/sharedRuntime_x86.cpp
! src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp
! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp
! src/hotspot/cpu/x86/templateTable_x86.cpp
! src/hotspot/cpu/x86/vm_version_x86.cpp
! src/hotspot/cpu/x86/vm_version_x86.hpp
! src/hotspot/cpu/x86/x86_32.ad
! src/hotspot/cpu/x86/x86_64.ad
! src/hotspot/cpu/zero/assembler_zero.cpp
! src/hotspot/share/adlc/main.cpp
! src/hotspot/share/adlc/output_c.cpp
! src/hotspot/share/c1/c1_Runtime1.cpp
! src/hotspot/share/cds/heapShared.cpp
! src/hotspot/share/classfile/classFileParser.cpp
! src/hotspot/share/classfile/systemDictionary.cpp
! src/hotspot/share/code/nmethod.hpp
! src/hotspot/share/gc/g1/g1FullCollector.cpp
! src/hotspot/share/gc/g1/g1FullGCCompactionPoint.cpp
! src/hotspot/share/gc/g1/g1FullGCOopClosures.inline.hpp
! src/hotspot/share/gc/parallel/psScavenge.cpp
! src/hotspot/share/gc/serial/markSweep.inline.hpp
! src/hotspot/share/gc/shared/genCollectedHeap.cpp
! src/hotspot/share/gc/shared/genCollectedHeap.hpp
! src/hotspot/share/gc/shared/memAllocator.cpp
! src/hotspot/share/gc/shenandoah/shenandoahForwarding.inline.hpp
! src/hotspot/share/gc/shenandoah/shenandoahFullGC.cpp
! src/hotspot/share/interpreter/interpreterRuntime.cpp
! src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp
! src/hotspot/share/jfr/metadata/metadata.xml
! src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp
! src/hotspot/share/jvmci/jvmciRuntime.cpp
! src/hotspot/share/jvmci/vmStructs_jvmci.cpp
! src/hotspot/share/logging/logTag.hpp
! src/hotspot/share/oops/instanceKlass.cpp
! src/hotspot/share/oops/klass.cpp
! src/hotspot/share/oops/klass.hpp
! src/hotspot/share/oops/klass.inline.hpp
! src/hotspot/share/oops/markWord.cpp
! src/hotspot/share/oops/markWord.hpp
- src/hotspot/share/oops/markWord.inline.hpp
! src/hotspot/share/oops/oop.hpp
! src/hotspot/share/oops/oop.inline.hpp
! src/hotspot/share/opto/c2_globals.hpp
! src/hotspot/share/opto/callnode.cpp
! src/hotspot/share/opto/graphKit.cpp
! src/hotspot/share/opto/library_call.cpp
! src/hotspot/share/opto/locknode.cpp
! src/hotspot/share/opto/locknode.hpp
! src/hotspot/share/opto/machnode.hpp
! src/hotspot/share/opto/macro.cpp
! src/hotspot/share/opto/matcher.cpp
! src/hotspot/share/opto/memnode.cpp
! src/hotspot/share/opto/runtime.cpp
! src/hotspot/share/opto/runtime.hpp
! src/hotspot/share/opto/type.hpp
! src/hotspot/share/prims/jvmtiEnvBase.cpp
! src/hotspot/share/prims/jvmtiTagMap.cpp
! src/hotspot/share/prims/whitebox.cpp
! src/hotspot/share/runtime/abstract_vm_version.hpp
! src/hotspot/share/runtime/arguments.cpp
- src/hotspot/share/runtime/biasedLocking.cpp
- src/hotspot/share/runtime/biasedLocking.hpp
! src/hotspot/share/runtime/deoptimization.cpp
! src/hotspot/share/runtime/deoptimization.hpp
! src/hotspot/share/runtime/flags/jvmFlagConstraintsRuntime.cpp
! src/hotspot/share/runtime/flags/jvmFlagConstraintsRuntime.hpp
! src/hotspot/share/runtime/frame.hpp
! src/hotspot/share/runtime/globals.hpp
! src/hotspot/share/runtime/java.cpp
! src/hotspot/share/runtime/sharedRuntime.cpp
! src/hotspot/share/runtime/synchronizer.cpp
! src/hotspot/share/runtime/thread.cpp
! src/hotspot/share/runtime/thread.hpp
! src/hotspot/share/runtime/vframeArray.cpp
! src/hotspot/share/runtime/vframe_hp.cpp
! src/hotspot/share/runtime/vmOperation.hpp
! src/hotspot/share/runtime/vmStructs.cpp
! src/java.base/share/man/java.1
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/Mark.java
! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotResolvedObjectTypeImpl.java
! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotVMConfig.java
! src/jdk.jfr/share/conf/jfr/default.jfc
! src/jdk.jfr/share/conf/jfr/profile.jfc
! test/hotspot/gtest/gc/shared/test_preservedMarks.cpp
! test/hotspot/gtest/oops/test_markWord.cpp
! test/hotspot/jtreg/ProblemList-Xcomp.txt
! test/hotspot/jtreg/ProblemList.txt
- test/hotspot/jtreg/compiler/c2/Test8062950.java
- test/hotspot/jtreg/compiler/c2/TestUseOptoBiasInliningWithoutEliminateLocks.java
! test/hotspot/jtreg/compiler/loopstripmining/CheckLoopStripMining.java
! test/hotspot/jtreg/compiler/rtm/cli/RTMGenericCommandLineOptionTest.java
- test/hotspot/jtreg/compiler/rtm/cli/TestUseRTMLockingOptionWithBiasedLocking.java
- test/hotspot/jtreg/compiler/uncommontrap/TestLockEliminatedAtDeopt.java
! test/hotspot/jtreg/gc/TestFullGCALot.java
! test/hotspot/jtreg/runtime/7167069/PrintAsFlag.java
! test/hotspot/jtreg/runtime/Monitor/SyncOnValueBasedClassTest.java
! test/hotspot/jtreg/runtime/cds/appcds/javaldr/LockDuringDump.java
! test/hotspot/jtreg/runtime/handshake/HandshakeDirectTest.java
- test/hotspot/jtreg/runtime/logging/BiasedLockingTest.java
! test/hotspot/jtreg/serviceability/jvmti/GetOwnedMonitorInfo/GetOwnedMonitorInfoWithEATest.java
! test/hotspot/jtreg/serviceability/jvmti/GetOwnedMonitorStackDepthInfo/GetOwnedMonitorStackDepthInfoWithEATest.java
! test/hotspot/jtreg/serviceability/jvmti/Heap/IterateHeapWithEscapeAnalysisEnabled.java
! test/hotspot/jtreg/serviceability/sa/ClhsdbLongConstant.java
! test/jdk/com/sun/jdi/EATests.java
- test/jdk/jdk/jfr/event/runtime/TestBiasedLockRevocationEvents.java
! test/lib/jdk/test/lib/jfr/EventNames.java
! test/lib/sun/hotspot/WhiteBox.java
! test/micro/org/openjdk/bench/vm/lang/LockUnlock.java

Changeset: 42968db1
Author:    Coleen Phillimore 
Date:      2021-06-24 19:34:17 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/42968db173b3caa53b6ad403f1891c41bcc6fb75

8269293: ObjectMonitor thread id fields should be 64 bits.

Reviewed-by: mgronlun, dcubed

! src/hotspot/share/runtime/objectMonitor.cpp
! src/hotspot/share/runtime/objectMonitor.hpp

Changeset: c79034e0
Author:    Zhengyu Gu 
Date:      2021-06-24 21:02:16 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/c79034e0c94a21a0ef3655e0d7da7629d7b40d8c

8269303: Remove unnecessary forward declaration of PSPromotionManager in cpCache.hpp

Reviewed-by: kbarrett

! src/hotspot/share/oops/cpCache.hpp

Changeset: 08ee7ae6
Author:    David Holmes 
Date:      2021-06-24 23:58:32 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/08ee7ae67246b45be9684a4a283f0103f5f1c0c4

8268855: Cleanup name handling in the Thread class and subclasses

Reviewed-by: lfoltan, coleenp

! src/hotspot/cpu/aarch64/gc/shared/barrierSetNMethod_aarch64.cpp
! src/hotspot/cpu/x86/gc/shared/barrierSetNMethod_x86.cpp
! src/hotspot/share/compiler/compileBroker.cpp
! src/hotspot/share/gc/shared/concurrentGCThread.hpp
! src/hotspot/share/gc/shared/workgroup.hpp
! src/hotspot/share/gc/shenandoah/shenandoahControlThread.hpp
! src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp
! src/hotspot/share/jvmci/jvmciCompilerToVM.cpp
! src/hotspot/share/jvmci/jvmciEnv.cpp
! src/hotspot/share/logging/logAsyncWriter.hpp
! src/hotspot/share/prims/jni.cpp
! src/hotspot/share/runtime/nonJavaThread.hpp
! src/hotspot/share/runtime/thread.cpp
! src/hotspot/share/runtime/thread.hpp
! src/hotspot/share/runtime/vmThread.hpp
! src/hotspot/share/services/threadService.cpp

Changeset: c37988d0
Author:    Scott Gibbons 
Committer: Sandhya Viswanathan 
Date:      2021-06-25 03:19:48 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/c37988d0793b24d98d285530dfda69999a227937

8268276: Base64 Decoding optimization for x86 using AVX-512

Reviewed-by: erikj, sviswanathan, kvn

! .gitignore
! src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp
! src/hotspot/cpu/ppc/stubGenerator_ppc.cpp
! src/hotspot/cpu/x86/assembler_x86.cpp
! src/hotspot/cpu/x86/assembler_x86.hpp
! src/hotspot/cpu/x86/stubGenerator_x86_64.cpp
! src/hotspot/cpu/x86/stubRoutines_x86.cpp
! src/hotspot/cpu/x86/stubRoutines_x86.hpp
! src/hotspot/share/classfile/vmIntrinsics.hpp
! src/hotspot/share/opto/library_call.cpp
! src/hotspot/share/opto/runtime.cpp
! src/java.base/share/classes/java/util/Base64.java

Changeset: 3a8f3d6c
Author:    Aleksey Shipilev 
Date:      2021-06-25 08:08:10 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/3a8f3d6cac0ab859704db533bf1f63431fbd9253

8269280: (bf) Replace StringBuffer in *Buffer.toString()

Reviewed-by: alanb, chegar, bpb

! src/java.base/share/classes/java/nio/X-Buffer.java.template
! test/jdk/java/nio/Buffer/Basic-X.java.template
! test/jdk/java/nio/Buffer/BasicByte.java
! test/jdk/java/nio/Buffer/BasicChar.java
! test/jdk/java/nio/Buffer/BasicDouble.java
! test/jdk/java/nio/Buffer/BasicFloat.java
! test/jdk/java/nio/Buffer/BasicInt.java
! test/jdk/java/nio/Buffer/BasicLong.java
! test/jdk/java/nio/Buffer/BasicShort.java

Changeset: fd43d9cb
Author:    Denghui Dong 
Committer: Yi Yang 
Date:      2021-06-25 08:15:34 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/fd43d9cb40f7e4b0f5ebc490e0490a222b8f2770

8269225: JFR.stop misses the written info when the filename is only specified by JFR.start

Reviewed-by: egahlin

! src/jdk.jfr/share/classes/jdk/jfr/internal/dcmd/DCmdStop.java
+ test/jdk/jdk/jfr/jcmd/TestJcmdStopWithoutFilename.java

Changeset: fdcae665
Author:    Ludovic Henry 
Committer: Jaroslav Bachorik 
Date:      2021-06-25 08:30:30 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/fdcae6653c215646c83e19721a18508f6e667eb4

8269092: Add OldObjectSampleEvent.allocationSize field

Reviewed-by: egahlin, jbachorik

! src/hotspot/share/jfr/leakprofiler/checkpoint/eventEmitter.cpp
! src/hotspot/share/jfr/metadata/metadata.xml
+ test/jdk/jdk/jfr/event/oldobject/TestObjectSize.java

Changeset: ffa34ed4
Author:    Markus Gr?nlund 
Date:      2021-06-25 09:41:23 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/ffa34ed429079827c9b0acb843288fde4b7fa53d

8265919: RunThese30M fails "assert((!(((((JfrTraceIdBits::load(value)) & ((1 << 4) << 8)) != 0))))) failed: invariant"

Reviewed-by: egahlin

! src/hotspot/share/jfr/recorder/checkpoint/types/jfrTypeSet.cpp

Changeset: 7c87d69c
Author:    duke 
Date:      2021-06-25 11:01:08 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/7c87d69ce90c5b214af8ce4d2a1e989b69de2e01

Automatic merge of jdk:master into master



From duke at openjdk.java.net  Fri Jun 25 11:06:50 2021
From: duke at openjdk.java.net (J.Duke)
Date: Fri, 25 Jun 2021 11:06:50 GMT
Subject: [foreign-memaccess+abi] RFR: Merge master
Message-ID: 

Hi all,

this is an _automatically_ generated pull request to notify you that there are 81 commits from the branch `master`that can **not** be merged into the branch `foreign-memaccess+abi`:

The following files contains merge conflicts:

- src/hotspot/share/runtime/frame.inline.hpp
- test/jdk/java/foreign/TestStringEncoding.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-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 +101:openjdk-bot-101
$ git checkout openjdk-bot-101

# 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-101:101


_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
 - 8265919: RunThese30M fails "assert((!(((((JfrTraceIdBits::load(value)) & ((1 << 4) << 8)) != 0))))) failed: invariant"
 - 8269092: Add OldObjectSampleEvent.allocationSize field
 - 8269225: JFR.stop misses the written info when the filename is only specified by JFR.start
 - 8269280: (bf) Replace StringBuffer in *Buffer.toString()
 - 8268276: Base64 Decoding optimization for x86 using AVX-512
 - 8268855: Cleanup name handling in the Thread class and subclasses
 - 8269303: Remove unnecessary forward declaration of PSPromotionManager in cpCache.hpp
 - 8269293: ObjectMonitor thread id fields should be 64 bits.
 - 8256425: Obsolete Biased Locking in JDK 18
 - ... and 71 more: https://git.openjdk.java.net/panama-foreign/compare/54cdd073...7c87d69c

The webrev contains the conflicts with foreign-memaccess+abi:
 - merge conflicts: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=563&range=00.conflicts

Changes: https://git.openjdk.java.net/panama-foreign/pull/563/files
  Stats: 32405 lines in 574 files changed: 16013 ins; 15123 del; 1269 mod
  Patch: https://git.openjdk.java.net/panama-foreign/pull/563.diff
  Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/563/head:pull/563

PR: https://git.openjdk.java.net/panama-foreign/pull/563

From jvernee at openjdk.java.net  Fri Jun 25 11:10:19 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 25 Jun 2021 11:10:19 GMT
Subject: [foreign-memaccess+abi] RFR: Add support for high-level functions
 to copy to and from Java arrays [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 25 Jun 2021 10:41:44 GMT, Maurizio Cimadamore  wrote:

>> This patch includes some of the changes from Lee to support a set of static functions to allow bulk copy from Java arrays to segments (and viceversa) in a more succint fashion (so that the user doesn't have to create a temporary heap segment to do the copy).
>> 
>> I've added a new public method to `MemorySegment` which performs an *element-wise* bulk copy; it takes a source segment and a couple of element layouts: the source element layout and the destination element layout. The two layouts must have same size, but can have different alignments (which will be checked against the corresponding segments) and byte orders. If the byte order differs, a bulk copy with swap will be performed. As such, this method generalizes the previous `copyFrom` - as follows:
>> 
>> 
>> copyFrom(srcSegment) -> copyFrom(JAVA_BYTE, srcSegment, JAVA_BYTE)
>> 
>> I've added support for argument type profiling for MemoryCopy static methods to avoid type pollution in cases where same metod is called with different memory segment types.
>> 
>> I've done a pass over the javadoc, and make it more consistent with the rest of the API. I've also reworked the test a bit to use the data provider functionality of TestNG, since all the test cases were similar, except for the carrier type.
>> 
>> There are other cosmetic changes as well, compared to original code from Lee, such as naming of static fields which is now capitalized. Everything else is the same.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add javadoc text for exceptions which might be thrown by MemoryAccess/MemoryCopy

Marked as reviewed by jvernee (Committer).

-------------

PR: https://git.openjdk.java.net/panama-foreign/pull/555

From mcimadamore at openjdk.java.net  Fri Jun 25 11:15:39 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 25 Jun 2021 11:15:39 GMT
Subject: [foreign-memaccess+abi] RFR: Add support for high-level functions
 to copy to and from Java arrays [v7]
In-Reply-To: 
References: 
Message-ID: <9i1kyGGgfDL13489oNPK2GHBYOLo7r2jaEhilwukois=.d46e47cb-9309-428c-8be1-e0ae8ee6fc1b@github.com>

> This patch includes some of the changes from Lee to support a set of static functions to allow bulk copy from Java arrays to segments (and viceversa) in a more succint fashion (so that the user doesn't have to create a temporary heap segment to do the copy).
> 
> I've added a new public method to `MemorySegment` which performs an *element-wise* bulk copy; it takes a source segment and a couple of element layouts: the source element layout and the destination element layout. The two layouts must have same size, but can have different alignments (which will be checked against the corresponding segments) and byte orders. If the byte order differs, a bulk copy with swap will be performed. As such, this method generalizes the previous `copyFrom` - as follows:
> 
> 
> copyFrom(srcSegment) -> copyFrom(JAVA_BYTE, srcSegment, JAVA_BYTE)
> 
> I've added support for argument type profiling for MemoryCopy static methods to avoid type pollution in cases where same metod is called with different memory segment types.
> 
> I've done a pass over the javadoc, and make it more consistent with the rest of the API. I've also reworked the test a bit to use the data provider functionality of TestNG, since all the test cases were similar, except for the carrier type.
> 
> There are other cosmetic changes as well, compared to original code from Lee, such as naming of static fields which is now capitalized. Everything else is the same.

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Remove argument type profiling for MemoryCopy methods

-------------

Changes:
  - all: https://git.openjdk.java.net/panama-foreign/pull/555/files
  - new: https://git.openjdk.java.net/panama-foreign/pull/555/files/e66008dc..572d46f3

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=555&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=555&range=05-06

  Stats: 6 lines in 2 files changed: 0 ins; 6 del; 0 mod
  Patch: https://git.openjdk.java.net/panama-foreign/pull/555.diff
  Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/555/head:pull/555

PR: https://git.openjdk.java.net/panama-foreign/pull/555

From duke at openjdk.java.net  Fri Jun 25 11:19:09 2021
From: duke at openjdk.java.net (J.Duke)
Date: Fri, 25 Jun 2021 11:19:09 GMT
Subject: [foreign-memaccess+abi] RFR: Merge master [v2]
In-Reply-To: 
References: 
Message-ID: <2_14U6TWJg2vDg4bl4kP6J9M6CMsspp2XYtePjMdCms=.125d4d46-7703-4ba5-9e0e-900a98ce0fae@github.com>

> Hi all,
> 
> this is an _automatically_ generated pull request to notify you that there are 81 commits from the branch `master`that can **not** be merged into the branch `foreign-memaccess+abi`:
> 
> The following files contains merge conflicts:
> 
> - src/hotspot/share/runtime/frame.inline.hpp
> - test/jdk/java/foreign/TestStringEncoding.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-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 +101:openjdk-bot-101
> $ git checkout openjdk-bot-101
> 
> # 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-101:101
> 
> 
> _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 82 commits:

 - Merge branch 'foreign-memaccess+abi' into 101
 - Automatic merge of jdk:master into master
 - 8265919: RunThese30M fails "assert((!(((((JfrTraceIdBits::load(value)) & ((1 << 4) << 8)) != 0))))) failed: invariant"
   
   Reviewed-by: egahlin
 - 8269092: Add OldObjectSampleEvent.allocationSize field
   
   Reviewed-by: egahlin, jbachorik
 - 8269225: JFR.stop misses the written info when the filename is only specified by JFR.start
   
   Reviewed-by: egahlin
 - 8269280: (bf) Replace StringBuffer in *Buffer.toString()
   
   Reviewed-by: alanb, chegar, bpb
 - 8268276: Base64 Decoding optimization for x86 using AVX-512
   
   Reviewed-by: erikj, sviswanathan, kvn
 - 8268855: Cleanup name handling in the Thread class and subclasses
   
   Reviewed-by: lfoltan, coleenp
 - 8269303: Remove unnecessary forward declaration of PSPromotionManager in cpCache.hpp
   
   Reviewed-by: kbarrett
 - 8269293: ObjectMonitor thread id fields should be 64 bits.
   
   Reviewed-by: mgronlun, dcubed
 - ... and 72 more: https://git.openjdk.java.net/panama-foreign/compare/7c94f63f...54aeee47

-------------

Changes: https://git.openjdk.java.net/panama-foreign/pull/563/files
 Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=563&range=01
  Stats: 31893 lines in 561 files changed: 15669 ins; 14969 del; 1255 mod
  Patch: https://git.openjdk.java.net/panama-foreign/pull/563.diff
  Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/563/head:pull/563

PR: https://git.openjdk.java.net/panama-foreign/pull/563

From duke at openjdk.java.net  Fri Jun 25 11:29:23 2021
From: duke at openjdk.java.net (J.Duke)
Date: Fri, 25 Jun 2021 11:29:23 GMT
Subject: [foreign-memaccess+abi] Integrated: Merge master
In-Reply-To: 
References: 
Message-ID: 

On Fri, 25 Jun 2021 11:01:35 GMT, J. Duke  wrote:

> Hi all,
> 
> this is an _automatically_ generated pull request to notify you that there are 81 commits from the branch `master`that can **not** be merged into the branch `foreign-memaccess+abi`:
> 
> The following files contains merge conflicts:
> 
> - src/hotspot/share/runtime/frame.inline.hpp
> - test/jdk/java/foreign/TestStringEncoding.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-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 +101:openjdk-bot-101
> $ git checkout openjdk-bot-101
> 
> # 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-101:101
> 
> 
> _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: 347a5a71
Author:    J. Duke 
Committer: Jorn Vernee 
URL:       https://git.openjdk.java.net/panama-foreign/commit/347a5a71a6560e121e6873c213cecf51900754bb
Stats:     31893 lines in 561 files changed: 15669 ins; 14969 del; 1255 mod

Merge master

-------------

PR: https://git.openjdk.java.net/panama-foreign/pull/563

From uschindler at openjdk.java.net  Fri Jun 25 11:31:13 2021
From: uschindler at openjdk.java.net (Uwe Schindler)
Date: Fri, 25 Jun 2021 11:31:13 GMT
Subject: [foreign-memaccess+abi] RFR: Add support for high-level functions
 to copy to and from Java arrays [v7]
In-Reply-To: <9i1kyGGgfDL13489oNPK2GHBYOLo7r2jaEhilwukois=.d46e47cb-9309-428c-8be1-e0ae8ee6fc1b@github.com>
References: 
 <9i1kyGGgfDL13489oNPK2GHBYOLo7r2jaEhilwukois=.d46e47cb-9309-428c-8be1-e0ae8ee6fc1b@github.com>
Message-ID: 

On Fri, 25 Jun 2021 11:15:39 GMT, Maurizio Cimadamore  wrote:

>> This patch includes some of the changes from Lee to support a set of static functions to allow bulk copy from Java arrays to segments (and viceversa) in a more succint fashion (so that the user doesn't have to create a temporary heap segment to do the copy).
>> 
>> I've added a new public method to `MemorySegment` which performs an *element-wise* bulk copy; it takes a source segment and a couple of element layouts: the source element layout and the destination element layout. The two layouts must have same size, but can have different alignments (which will be checked against the corresponding segments) and byte orders. If the byte order differs, a bulk copy with swap will be performed. As such, this method generalizes the previous `copyFrom` - as follows:
>> 
>> 
>> copyFrom(srcSegment) -> copyFrom(JAVA_BYTE, srcSegment, JAVA_BYTE)
>> 
>> I've added support for argument type profiling for MemoryCopy static methods to avoid type pollution in cases where same metod is called with different memory segment types.
>> 
>> I've done a pass over the javadoc, and make it more consistent with the rest of the API. I've also reworked the test a bit to use the data provider functionality of TestNG, since all the test cases were similar, except for the carrier type.
>> 
>> There are other cosmetic changes as well, compared to original code from Lee, such as naming of static fields which is now capitalized. Everything else is the same.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove argument type profiling for MemoryCopy methods

Hi,
Wouldn't it make sense to change MemoryCopy test to use a read-only source segment, so we ensure that the access checks are correct? The first bug I found was that it tried to check for write access on the copy source.

I left a comment where the check could be integrated into the test.

Otherwise, looks fine to me. I have no strong preference on the parameter order, but I would prefer System.arrayCopy style.

-------------

PR: https://git.openjdk.java.net/panama-foreign/pull/555

From duke at openjdk.java.net  Fri Jun 25 11:38:38 2021
From: duke at openjdk.java.net (duke)
Date: Fri, 25 Jun 2021 11:38:38 GMT
Subject: git: openjdk/panama-foreign: foreign-jextract: 83 new changesets
Message-ID: <60db9e8a-ed98-4175-a218-b5a56f7dce22@openjdk.org>

Changeset: 5ae9a128
Author:    Albert Mingkun Yang 
Date:      2021-06-18 11:48:59 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/5ae9a12858a20361c163e1dfe6b67970f27e4e40

8268964: Remove unused ReferenceProcessorAtomicMutator

Reviewed-by: tschatzl, pliden

! src/hotspot/share/gc/shared/referenceProcessor.hpp

Changeset: 8f2456e5
Author:    Boris Ulasevich 
Date:      2021-06-18 16:25:25 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/8f2456e5b058a88730ec383d88634737849afdfb

8267042: bug in monitor locking/unlocking on ARM32 C1 due to uninitialized BasicObjectLock::_displaced_header

Co-authored-by: Chris Cole 
Reviewed-by: dsamersoff

! src/hotspot/cpu/arm/c1_MacroAssembler_arm.cpp
! src/hotspot/cpu/arm/sharedRuntime_arm.cpp
+ test/hotspot/jtreg/compiler/c1/Test8267042.java

Changeset: 80dc262e
Author:    Valerie Peng 
Date:      2021-06-17 23:27:54 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/80dc262e8132204d70b184b32978e6c456460fb0

8265500: Some impls of javax.crypto.Cipher.init() do not throw UnsupportedOperationExc for unsupported modes

Reviewed-by: xuelei

! src/java.base/share/classes/com/sun/crypto/provider/ARCFOURCipher.java
! src/java.base/share/classes/com/sun/crypto/provider/ChaCha20Cipher.java
! src/java.base/share/classes/com/sun/crypto/provider/RSACipher.java
! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11AEADCipher.java
! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java
! src/jdk.crypto.mscapi/windows/classes/sun/security/mscapi/CRSACipher.java
! test/jdk/javax/crypto/Cipher/TestCipherMode.java
+ test/jdk/sun/security/pkcs11/Cipher/TestCipherMode.java

Changeset: 483f1ee2
Author:    Rajan Halade 
Date:      2021-06-18 00:59:29 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/483f1ee211bc0e37b486eb9d38d283ff02f0bdcc

8268678: LetsEncryptCA.java test fails as Let?s Encrypt Authority X3 is retired

Backport-of: 58e6e6d919cb15559a61a67805da263be3c9d693

! test/jdk/security/infra/java/security/cert/CertPathValidator/certification/LetsEncryptCA.java

Changeset: 7ed3634d
Author:    Vladimir Ivanov 
Date:      2021-06-18 07:50:22 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/7ed3634da81b53135c89aa82a1a5d2f4de2c6c5e

8268405: Several regressions 4-17% after CHA changes

Reviewed-by: kvn, dlong

! src/hotspot/share/opto/c2_globals.hpp
! src/hotspot/share/opto/callGenerator.cpp
! src/hotspot/share/opto/doCall.cpp
! src/hotspot/share/opto/graphKit.cpp
! src/hotspot/share/opto/parse1.cpp
! src/hotspot/share/opto/type.hpp
! src/hotspot/share/runtime/deoptimization.cpp
! src/hotspot/share/runtime/deoptimization.hpp
! src/hotspot/share/runtime/vmStructs.cpp

Changeset: 59d84787
Author:    Igor Ignatyev 
Date:      2021-06-18 09:56:36 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/59d84787e91e85dba4df45e99aa376f484e6ddff

8268591: a few runtime/jni tests don't need `/othervm`

Reviewed-by: dholmes, mseledtsov

! test/hotspot/jtreg/runtime/jni/atExit/TestAtExit.java
! test/hotspot/jtreg/runtime/jni/checked/TestCheckedEnsureLocalCapacity.java
! test/hotspot/jtreg/runtime/jni/registerNativesWarning/TestRegisterNativesWarning.java

Changeset: 8ccb76eb
Author:    Igor Ignatyev 
Date:      2021-06-18 09:57:44 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/8ccb76eb135c33349860f503745fdff49f158066

8268601: mark hotspot runtime/records tests which ignore external VM flags

Reviewed-by: dholmes, mseledtsov

! test/hotspot/jtreg/runtime/records/RedefineRecord.java

Changeset: 4006fe73
Author:    Igor Ignatyev 
Date:      2021-06-18 09:58:34 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/4006fe735af70b01b2c254264b816fc067bfbd0d

8268597: mark hotspot runtime/symboltable tests which ignore external VM flags

Reviewed-by: dholmes, mseledtsov

! test/hotspot/jtreg/runtime/symboltable/ShortLivedSymbolCleanup.java

Changeset: 9f4f0392
Author:    Igor Ignatyev 
Date:      2021-06-18 09:59:34 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/9f4f039231895f04bcdae4b25e1861f2070f1d8b

8268596: mark hotspot runtime/verifier tests which ignore external VM flags

Reviewed-by: hseigel, mseledtsov

! test/hotspot/jtreg/runtime/verifier/TraceClassRes.java

Changeset: 58eddc81
Author:    Igor Ignatyev 
Date:      2021-06-18 10:00:21 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/58eddc81102c233061de67a1deaa8d8fee8d5857

8268594: runtime/handshake tests don't need WhiteBox after AOT removal

Reviewed-by: dholmes, mseledtsov

! test/hotspot/jtreg/runtime/handshake/HandshakeTimeoutTest.java
! test/hotspot/jtreg/runtime/handshake/HandshakeTransitionTest.java

Changeset: 3e1dc0a7
Author:    Igor Ignatyev 
Date:      2021-06-18 10:01:03 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/3e1dc0a7655f26ad38b5179f720eb4431bcd4cc3

8268598: mark hotspot runtime/stringtable tests which ignore external VM flags

Reviewed-by: hseigel, mseledtsov

! test/hotspot/jtreg/runtime/stringtable/StringTableVerifyTest.java

Changeset: 2f65d402
Author:    Igor Ignatyev 
Date:      2021-06-18 10:01:58 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/2f65d4021f3f51a342419a61bc934863e421f952

8268599: mark hotspot runtime/sealedClasses tests which ignore external VM flags

Reviewed-by: dholmes, mseledtsov

! test/hotspot/jtreg/runtime/sealedClasses/RedefinePermittedSubclass.java
! test/hotspot/jtreg/runtime/sealedClasses/RedefineSealedClass.java

Changeset: 5b198986
Author:    Igor Ignatyev 
Date:      2021-06-18 10:03:21 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/5b198986cef4fa0e77d02136212ecc01ec9b22c0

8268563: mark hotspot serviceability/jvmti tests which ignore external VM flags

Reviewed-by: sspitsyn

! test/hotspot/jtreg/serviceability/jvmti/CanGenerateAllClassHook/CanGenerateAllClassHook.java
! test/hotspot/jtreg/serviceability/jvmti/GetObjectSizeClass.java
! test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineLeak.java
! test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefinePreviousVersions.java
! test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RetransformClassesZeroLength.java
! test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/TransformerDeadlockTest.java

Changeset: 8366c693
Author:    Igor Ignatyev 
Date:      2021-06-18 10:04:25 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/8366c6936eaad411082ec6a9e569da07c5f3f0cd

8268541: mark hotspot serviceability/sa tests which ignore external VM flags

Reviewed-by: sspitsyn

! test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackLineNumbers.java

Changeset: f83c6b8a
Author:    Igor Ignatyev 
Date:      2021-06-18 10:05:15 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/f83c6b8a6a92a37197a3b83ba093f26e820c4ac9

8268531: mark SDTProbesGNULinuxTest as ignoring external VM flags

Reviewed-by: sspitsyn

! test/hotspot/jtreg/serviceability/7170638/SDTProbesGNULinuxTest.java

Changeset: 21abcc4a
Author:    Igor Ignatyev 
Date:      2021-06-18 10:06:12 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/21abcc4a5a539644be93726436ed4454ad9aaf18

8268564: mark hotspot serviceability/attach tests which ignore external VM flags

Reviewed-by: sspitsyn

! test/hotspot/jtreg/serviceability/attach/AttachSetGetFlag.java
! test/hotspot/jtreg/serviceability/attach/AttachWithStalePidFile.java

Changeset: d8a0582a
Author:    Mark Sheppard 
Date:      2021-06-18 10:54:23 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/d8a0582a36340bcc65910f3a34132ec6e04e5d01

8265369: [macos-aarch64] java/net/MulticastSocket/Promiscuous.java failed with "SocketException: Cannot allocate memory"

Reviewed-by: dfuchs, michaelm, chegar

! src/java.base/unix/native/libnet/PlainDatagramSocketImpl.c
! test/jdk/ProblemList.txt

Changeset: f9c8c1c3
Author:    Erik Gahlin 
Date:      2021-06-18 13:51:57 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/f9c8c1c38612abf0f3286c9f353f11788f58ac70

8268903: JFR: RecordingStream::dump is missing @since

Reviewed-by: mgronlun

! src/jdk.jfr/share/classes/jdk/jfr/consumer/RecordingStream.java
! src/jdk.management.jfr/share/classes/jdk/management/jfr/RemoteRecordingStream.java

Changeset: dab00ee5
Author:    Paul Sandoz 
Date:      2021-06-18 14:22:16 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/dab00ee59b73bcd5b8632d127b3d0a324e48e4e5

8266518: Refactor and expand scatter/gather tests

Reviewed-by: sviswanathan

! test/jdk/jdk/incubator/vector/AbstractVectorTest.java
! test/jdk/jdk/incubator/vector/Byte128VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Byte128VectorTests.java
! test/jdk/jdk/incubator/vector/Byte256VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Byte256VectorTests.java
! test/jdk/jdk/incubator/vector/Byte512VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Byte512VectorTests.java
! test/jdk/jdk/incubator/vector/Byte64VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Byte64VectorTests.java
! test/jdk/jdk/incubator/vector/ByteMaxVectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/ByteMaxVectorTests.java
! test/jdk/jdk/incubator/vector/Double128VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Double128VectorTests.java
! test/jdk/jdk/incubator/vector/Double256VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Double256VectorTests.java
! test/jdk/jdk/incubator/vector/Double512VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Double512VectorTests.java
! test/jdk/jdk/incubator/vector/Double64VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Double64VectorTests.java
! test/jdk/jdk/incubator/vector/DoubleMaxVectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/DoubleMaxVectorTests.java
! test/jdk/jdk/incubator/vector/Float128VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Float128VectorTests.java
! test/jdk/jdk/incubator/vector/Float256VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Float256VectorTests.java
! test/jdk/jdk/incubator/vector/Float512VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Float512VectorTests.java
! test/jdk/jdk/incubator/vector/Float64VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Float64VectorTests.java
! test/jdk/jdk/incubator/vector/FloatMaxVectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/FloatMaxVectorTests.java
! test/jdk/jdk/incubator/vector/Int128VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Int128VectorTests.java
! test/jdk/jdk/incubator/vector/Int256VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Int256VectorTests.java
! test/jdk/jdk/incubator/vector/Int512VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Int512VectorTests.java
! test/jdk/jdk/incubator/vector/Int64VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Int64VectorTests.java
! test/jdk/jdk/incubator/vector/IntMaxVectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/IntMaxVectorTests.java
! test/jdk/jdk/incubator/vector/Long128VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Long128VectorTests.java
! test/jdk/jdk/incubator/vector/Long256VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Long256VectorTests.java
! test/jdk/jdk/incubator/vector/Long512VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Long512VectorTests.java
! test/jdk/jdk/incubator/vector/Long64VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Long64VectorTests.java
! test/jdk/jdk/incubator/vector/LongMaxVectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/LongMaxVectorTests.java
! test/jdk/jdk/incubator/vector/Short128VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Short128VectorTests.java
! test/jdk/jdk/incubator/vector/Short256VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Short256VectorTests.java
! test/jdk/jdk/incubator/vector/Short512VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Short512VectorTests.java
! test/jdk/jdk/incubator/vector/Short64VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Short64VectorTests.java
! test/jdk/jdk/incubator/vector/ShortMaxVectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/ShortMaxVectorTests.java
! test/jdk/jdk/incubator/vector/gen-template.sh
- test/jdk/jdk/incubator/vector/templates/Kernel-Gather-Masked-op.template
- test/jdk/jdk/incubator/vector/templates/Kernel-Gather-op.template
- test/jdk/jdk/incubator/vector/templates/Kernel-Scatter-Masked-op.template
- test/jdk/jdk/incubator/vector/templates/Kernel-Scatter-op.template
- test/jdk/jdk/incubator/vector/templates/Unit-Gather-Masked-op.template
- test/jdk/jdk/incubator/vector/templates/Unit-Gather-op.template
- test/jdk/jdk/incubator/vector/templates/Unit-Scatter-Masked-op.template
- test/jdk/jdk/incubator/vector/templates/Unit-Scatter-op.template
! test/jdk/jdk/incubator/vector/templates/Unit-header.template
! test/jdk/jdk/incubator/vector/templates/X-LoadStoreTest.java.template

Changeset: 60389eed
Author:    Igor Ignatyev 
Date:      2021-06-18 15:25:25 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/60389eedb3c9932de57aca740a8116db83302ffa

8269025: jsig/Testjsig.java doesn't check exit code

Reviewed-by: hseigel

! test/hotspot/jtreg/runtime/jsig/Testjsig.java

Changeset: 7e03cf29
Author:    Joe Wang 
Date:      2021-06-18 16:03:30 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/7e03cf2916a69f947c46ac85b222ee7a99f68ad8

8265073: XML transformation and indentation when using xml:space

Reviewed-by: naoto, lancea, iris

! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/ToStream.java
! test/jaxp/javax/xml/jaxp/unittest/common/prettyprint/PrettyPrintTest.java

Changeset: 8caeca00
Author:    Chris Plummer 
Date:      2021-06-18 20:27:30 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/8caeca003e621dd523eb27ef7e7fea0765ceacb6

8264775: ClhsdbFindPC still fails with java.lang.RuntimeException: 'In java stack' missing from stdout/stderr

Reviewed-by: dcubed

! test/hotspot/jtreg/serviceability/sa/ClhsdbFindPC.java

Changeset: b9d73376
Author:    Xin Liu 
Committer: Paul Hohensee 
Date:      2021-06-18 21:29:55 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/b9d7337697bd1aa5581b1a28efb3a78c221f6592

8268638: semaphores of AsyncLogWriter may be broken when JVM is exiting.

Backport-of: fa3b44d43811dca8c609d6c61a58680835abf8e3

! src/hotspot/share/logging/logAsyncWriter.cpp
! src/hotspot/share/logging/logAsyncWriter.hpp

Changeset: b8f073be
Author:    Erik Gahlin 
Date:      2021-06-18 22:05:52 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/b8f073be84b6bf2f83e2a65d20b7eb8c03120dce

8268316: Typo in JFR jdk.Deserialization event

Reviewed-by: iignatyev

! src/jdk.jfr/share/classes/jdk/jfr/events/DeserializationEvent.java

Changeset: b7d78a5b
Author:    Jesper Wilhelmsson 
Date:      2021-06-18 23:04:20 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/b7d78a5b661e2b00f271298db3b6cc873cf754e7

Merge


Changeset: 0b8a0e2b
Author:    Joel Borggr?n-Franck 
Date:      2021-06-21 08:39:35 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/0b8a0e2b58dbdd5c9553e502212d32c033a5efb5

8266082: AssertionError in Annotate.fromAnnotations with -Xdoclint

Reviewed-by: vromero

! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/ReferenceParser.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties
+ test/langtools/tools/doclint/CrashInAnnotateTest.java
+ test/langtools/tools/doclint/CrashInAnnotateTest.out
+ test/langtools/tools/javac/diags/examples/NoAnnotationsInLink.java

Changeset: 1692fd2e
Author:    Thomas Schatzl 
Date:      2021-06-21 10:06:05 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/1692fd2eba7164ebd11fce1c02696a9053d131af

8017163: G1: Refactor remembered sets
8048504: G1: Investigate replacing the coarse and fine grained data structures in the remembered sets
6949259: G1: Merge sparse and fine remembered set hash tables

Co-authored-by: Ivan Walulya 
Co-authored-by: Thomas Schatzl 
Reviewed-by: sjohanss, iwalulya

! src/hotspot/share/gc/g1/g1Arguments.cpp
! src/hotspot/share/gc/g1/g1Arguments.hpp
+ src/hotspot/share/gc/g1/g1CardSet.cpp
+ src/hotspot/share/gc/g1/g1CardSet.hpp
+ src/hotspot/share/gc/g1/g1CardSet.inline.hpp
+ src/hotspot/share/gc/g1/g1CardSetContainers.hpp
+ src/hotspot/share/gc/g1/g1CardSetContainers.inline.hpp
+ src/hotspot/share/gc/g1/g1CardSetFreeMemoryTask.cpp
+ src/hotspot/share/gc/g1/g1CardSetFreeMemoryTask.hpp
+ src/hotspot/share/gc/g1/g1CardSetMemory.cpp
+ src/hotspot/share/gc/g1/g1CardSetMemory.hpp
+ src/hotspot/share/gc/g1/g1CardSetMemory.inline.hpp
! src/hotspot/share/gc/g1/g1CardTable.hpp
! src/hotspot/share/gc/g1/g1CardTable.inline.hpp
! 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/g1CollectionSet.cpp
! src/hotspot/share/gc/g1/g1CollectionSetChooser.cpp
! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp
! src/hotspot/share/gc/g1/g1ConcurrentMark.inline.hpp
! src/hotspot/share/gc/g1/g1DirtyCardQueue.cpp
! src/hotspot/share/gc/g1/g1EvacFailure.cpp
! src/hotspot/share/gc/g1/g1FullGCOopClosures.inline.hpp
! src/hotspot/share/gc/g1/g1GCPhaseTimes.cpp
! src/hotspot/share/gc/g1/g1GCPhaseTimes.hpp
! src/hotspot/share/gc/g1/g1OopClosures.inline.hpp
! src/hotspot/share/gc/g1/g1ParScanThreadState.hpp
! src/hotspot/share/gc/g1/g1Policy.cpp
! src/hotspot/share/gc/g1/g1RemSet.cpp
! src/hotspot/share/gc/g1/g1RemSet.hpp
! src/hotspot/share/gc/g1/g1RemSetSummary.cpp
! src/hotspot/share/gc/g1/g1RemSetSummary.hpp
! src/hotspot/share/gc/g1/g1RemSetTrackingPolicy.cpp
! src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.cpp
! src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.hpp
! src/hotspot/share/gc/g1/g1_globals.hpp
! 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
! src/hotspot/share/gc/g1/heapRegionRemSet.inline.hpp
! src/hotspot/share/gc/g1/heapRegionSet.cpp
! src/hotspot/share/gc/g1/jvmFlagConstraintsG1.cpp
! src/hotspot/share/gc/g1/jvmFlagConstraintsG1.hpp
- src/hotspot/share/gc/g1/sparsePRT.cpp
- src/hotspot/share/gc/g1/sparsePRT.hpp
! src/hotspot/share/gc/shared/cardTable.hpp
! src/hotspot/share/gc/shared/workerDataArray.hpp
! src/hotspot/share/memory/allocation.hpp
! src/hotspot/share/prims/whitebox.cpp
! src/hotspot/share/runtime/arguments.cpp
! src/hotspot/share/utilities/concurrentHashTable.hpp
! src/hotspot/share/utilities/concurrentHashTable.inline.hpp
! test/hotspot/gtest/gc/g1/test_freeRegionList.cpp
+ test/hotspot/gtest/gc/g1/test_g1CardSet.cpp
+ test/hotspot/gtest/gc/g1/test_g1CardSetContainers.cpp
+ test/hotspot/jtreg/gc/arguments/TestG1RemSetFlags.java
! test/hotspot/jtreg/gc/g1/TestGCLogMessages.java
! test/hotspot/jtreg/gc/g1/TestNoEagerReclaimOfHumongousRegions.java
! test/hotspot/jtreg/gc/stress/TestStressRSetCoarsening.java
! test/hotspot/jtreg/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java
! test/hotspot/jtreg/runtime/NMT/MallocSiteTypeChange.java
! test/jdk/jdk/jfr/event/gc/collection/TestG1ParallelPhases.java

Changeset: cbec37d4
Author:    Christoph G?ttschkes 
Committer: Jie Fu 
Date:      2021-06-21 11:08:33 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/cbec37d45d77533081c27b3fc649098dfcca0425

8269029: compiler/codegen/TestCharVect2.java fails for client VMs

Reviewed-by: kvn, jiefu

! test/hotspot/jtreg/compiler/codegen/TestCharVect2.java

Changeset: a58c477c
Author:    Thomas Schatzl 
Date:      2021-06-21 11:11:14 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/a58c477c49ca595c65f7a2fca2512ff2adea99be

8268952: Automatically update heap sizes in G1MonitoringScope

Reviewed-by: kbarrett, iwalulya

! src/hotspot/share/gc/g1/g1CollectedHeap.cpp
! src/hotspot/share/gc/g1/g1FullGCScope.cpp
! src/hotspot/share/gc/g1/g1MonitoringSupport.cpp
! src/hotspot/share/gc/g1/g1MonitoringSupport.hpp

Changeset: cd20c019
Author:    Thomas Schatzl 
Date:      2021-06-21 11:12:29 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/cd20c01942dd8559a31e51ef2a595c6eba44b8ad

8268458: Add verification type for evacuation failures

Reviewed-by: kbarrett, iwalulya

! src/hotspot/share/gc/g1/g1Arguments.cpp
! src/hotspot/share/gc/g1/g1CollectedHeap.cpp
! src/hotspot/share/gc/g1/g1HeapVerifier.cpp
! src/hotspot/share/gc/g1/g1HeapVerifier.hpp
! test/hotspot/gtest/gc/g1/test_g1HeapVerifier.cpp
! test/hotspot/jtreg/gc/g1/TestVerifyGCType.java

Changeset: b358b54c
Author:    Jie Fu 
Date:      2021-06-20 22:55:49 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/b358b54c4fb515be519ad631c0ae7c58f49fdc5b

8269063: Build failure due to VerifyReceiverTypes was not declared after JDK-8268405

Reviewed-by: kvn

! src/hotspot/share/runtime/deoptimization.cpp

Changeset: c294ae4f
Author:    Boris Ulasevich 
Date:      2021-06-21 06:04:57 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/c294ae4fed59c7e303416346cc4b189a48bc1ab1

8267042: bug in monitor locking/unlocking on ARM32 C1 due to uninitialized BasicObjectLock::_displaced_header

Co-authored-by: Chris Cole 
Reviewed-by: dsamersoff

! src/hotspot/cpu/arm/c1_MacroAssembler_arm.cpp
! src/hotspot/cpu/arm/sharedRuntime_arm.cpp
+ test/hotspot/jtreg/compiler/c1/Test8267042.java

Changeset: f8df953e
Author:    Markus Gr?nlund 
Date:      2021-06-21 11:16:41 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/f8df953e61372b396f351403ff6ba165720881bb

8268702: JFR diagnostic commands lack argument descriptors when viewed using Platform MBean Server

Reviewed-by: egahlin

! src/hotspot/share/jfr/dcmd/jfrDcmds.cpp
! src/hotspot/share/jfr/dcmd/jfrDcmds.hpp
! src/jdk.jfr/share/classes/jdk/jfr/internal/dcmd/AbstractDCmd.java

Changeset: 22ebd192
Author:    Hui Shi 
Date:      2021-06-21 11:59:00 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/22ebd1926d4510cbe40cb186edf16cbd44a29347

8268362: [REDO] C2 crash when compile negative Arrays.copyOf length after loop

Reviewed-by: kvn, roland

! src/hotspot/share/opto/callnode.cpp
! src/hotspot/share/opto/graphKit.cpp
! src/hotspot/share/opto/graphKit.hpp
! src/hotspot/share/opto/library_call.cpp
+ test/hotspot/jtreg/compiler/arraycopy/TestNegArrayLengthAsIndex1.java
+ test/hotspot/jtreg/compiler/arraycopy/TestNegArrayLengthAsIndex2.java
+ test/hotspot/jtreg/compiler/arraycopy/TestNegativeArrayCopyAfterLoop.java

Changeset: f25e7197
Author:    Jorn Vernee 
Date:      2021-06-21 12:06:51 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/f25e7197fef76cc87a15da7cc96a42b84d69bbfe

8268717: Upstream: 8268673: Stack walk across optimized entry frame on fresh native thread fails

Reviewed-by: mcimadamore, erikj

! make/test/JtregNativeJdk.gmk
! src/hotspot/cpu/aarch64/frame_aarch64.cpp
! src/hotspot/cpu/arm/frame_arm.cpp
! src/hotspot/cpu/ppc/frame_ppc.cpp
! src/hotspot/cpu/s390/frame_s390.cpp
! src/hotspot/cpu/x86/frame_x86.cpp
! src/hotspot/cpu/zero/frame_zero.cpp
! src/hotspot/share/prims/whitebox.cpp
! src/hotspot/share/runtime/frame.hpp
! src/hotspot/share/runtime/frame.inline.hpp
+ test/jdk/java/foreign/stackwalk/TestAsyncStackWalk.java
+ test/jdk/java/foreign/stackwalk/libAsyncStackWalk.cpp

Changeset: d3ad8cd3
Author:    Roland Westrelin 
Date:      2021-06-21 14:16:54 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/d3ad8cd344681fe8442f821f97f05996bb972abe

8268672: C2: assert(!loop->is_member(u_loop)) failed: can be in outer loop or out of both loops only

Reviewed-by: kvn, neliasso

! src/hotspot/share/opto/loopopts.cpp
+ test/hotspot/jtreg/compiler/loopstripmining/TestPinnedNodeInInnerLoop.java

Changeset: 0458113c
Author:    Jesper Wilhelmsson 
Date:      2021-06-21 23:09:01 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/0458113c6b1cf500ffdf049c1e3a698b16ce12ce

Merge

! src/hotspot/share/prims/whitebox.cpp
! src/hotspot/share/prims/whitebox.cpp

Changeset: 1a818154
Author:    Stefan Karlsson 
Date:      2021-06-22 07:44:25 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/1a818154cfe852a680070c5c07f2df33109e5b54

8269077: TestSystemGC uses "require vm.gc.G1" for large pages subtest

Reviewed-by: tschatzl, kbarrett

! test/hotspot/jtreg/gc/TestSystemGC.java

Changeset: 1f0ea7c3
Author:    Denghui Dong 
Committer: Yi Yang 
Date:      2021-06-22 08:28:18 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/1f0ea7c3d62221405de982ba484c0ee985fa9d7b

8268857: Merge VM_PrintJNI and VM_PrintThreads and remove the unused field 'is_deadlock' of DeadlockCycle

Reviewed-by: dholmes

! src/hotspot/share/runtime/os.cpp
! src/hotspot/share/runtime/vmOperation.hpp
! src/hotspot/share/runtime/vmOperations.cpp
! src/hotspot/share/runtime/vmOperations.hpp
! src/hotspot/share/services/attachListener.cpp
! src/hotspot/share/services/diagnosticCommand.cpp
! src/hotspot/share/services/threadService.cpp
! src/hotspot/share/services/threadService.hpp

Changeset: 2e639dd3
Author:    Yi Yang 
Date:      2021-06-22 08:30:08 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/2e639dd34a4342de6e1b9470448d66ef89c4bd52

8267657: Add missing PrintC1Statistics before incrementing counters

Reviewed-by: iveresov

! src/hotspot/cpu/aarch64/c1_CodeStubs_aarch64.cpp
! src/hotspot/cpu/ppc/c1_CodeStubs_ppc.cpp
! src/hotspot/cpu/s390/c1_CodeStubs_s390.cpp
! src/hotspot/cpu/x86/c1_CodeStubs_x86.cpp
! src/hotspot/share/c1/c1_Runtime1.cpp
! src/hotspot/share/runtime/sharedRuntime.cpp
! src/hotspot/share/runtime/sharedRuntime.hpp

Changeset: 18a1dd26
Author:    Matthias Baesken 
Date:      2021-06-22 13:28:41 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/18a1dd261cec6fa1c5820dce2df47d488417afff

8269031: linux x86_64 check for binutils 2.25 or higher after 8265783

Reviewed-by: ihse, erikj

! make/autoconf/toolchain.m4

Changeset: 33c23a1c
Author:    Coleen Phillimore 
Date:      2021-06-22 16:09:17 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/33c23a1cf2aa81551eee4a2acf271edf573558aa

8264941: Remove CodeCache::mark_for_evol_deoptimization() method

Reviewed-by: kvn, vlivanov, sspitsyn

! src/hotspot/share/code/codeCache.cpp
! src/hotspot/share/code/codeCache.hpp
! src/hotspot/share/prims/jvmtiExport.cpp
! src/hotspot/share/prims/jvmtiExport.hpp
! src/hotspot/share/prims/jvmtiManageCapabilities.cpp
! src/hotspot/share/prims/jvmtiRedefineClasses.cpp
! src/hotspot/share/prims/jvmtiRedefineClasses.hpp

Changeset: 0c693e2f
Author:    Kim Barrett 
Date:      2021-06-22 17:43:59 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/0c693e2f03b1adef0e946ebc32827ac09192f5f0

8268290: Improve LockFreeQueue<> utility

Reviewed-by: iwalulya, tschatzl

! src/hotspot/share/gc/g1/g1DirtyCardQueue.cpp
! src/hotspot/share/gc/g1/g1DirtyCardQueue.hpp
- src/hotspot/share/utilities/lockFreeQueue.hpp
- src/hotspot/share/utilities/lockFreeQueue.inline.hpp
+ src/hotspot/share/utilities/nonblockingQueue.hpp
+ src/hotspot/share/utilities/nonblockingQueue.inline.hpp
- test/hotspot/gtest/utilities/test_lockFreeQueue.cpp
+ test/hotspot/gtest/utilities/test_nonblockingQueue.cpp

Changeset: e2d7ec38
Author:    Weijun Wang 
Date:      2021-06-22 00:41:45 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/e2d7ec38af4e13cfbd303fa37e766aa2071cfd1f

8267100: [BACKOUT] JDK-8196415 Disable SHA-1 Signed JARs

Co-authored-by: Sean Mullan 
Reviewed-by: hchao, xuelei

! src/java.base/share/conf/security/java.security

Changeset: 4099810b
Author:    Jatin Bhateja 
Date:      2021-06-22 01:31:48 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/4099810b290d90c4c928e66c601744911b770f24

8268293: VectorAPI cast operation on mask and shuffle is broken

Reviewed-by: psandoz, sviswanathan

! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte128Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte256Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte512Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte64Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteMaxVector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double128Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double256Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double512Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double64Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/DoubleMaxVector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float128Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float256Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float512Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float64Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/FloatMaxVector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int128Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int256Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int512Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int64Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/IntMaxVector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long128Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long256Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long512Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long64Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/LongMaxVector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short128Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short256Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short512Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short64Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ShortMaxVector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-VectorBits.java.template
! test/jdk/jdk/incubator/vector/AbstractVectorConversionTest.java
! test/jdk/jdk/incubator/vector/Vector128ConversionTests.java
! test/jdk/jdk/incubator/vector/Vector256ConversionTests.java
! test/jdk/jdk/incubator/vector/Vector512ConversionTests.java
! test/jdk/jdk/incubator/vector/Vector64ConversionTests.java
! test/jdk/jdk/incubator/vector/VectorMaxConversionTests.java

Changeset: ef4ba224
Author:    Weijun Wang 
Date:      2021-06-22 02:06:59 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/ef4ba224c4887b2e307937754064d3623a2d3de5

8268349: Provide clear run-time warnings about Security Manager deprecation

Reviewed-by: lancea, mullan, alanb

! src/java.base/share/classes/java/lang/System.java
! test/jdk/java/lang/System/LoggerFinder/internal/LoggerFinderLoaderTest/LoggerFinderLoaderTest.java
! test/jdk/java/lang/System/SecurityManagerWarnings.java
! test/jdk/java/lang/invoke/lambda/LogGeneratedClassesTest.java
! test/jdk/java/net/spi/URLStreamHandlerProvider/Basic.java
! test/jdk/java/security/ProtectionDomain/RecursionDebug.java

Changeset: 6b14c8a1
Author:    Vicente Romero 
Date:      2021-06-22 02:08:15 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/6b14c8a1e5316b6c8584e93ee7a94d9eaec676cf

8267421: j.l.constant.DirectMethodHandleDesc.Kind.valueOf(int) implementation doesn't conform to the spec regarding REF_invokeInterface handling

Reviewed-by: mchung

! src/java.base/share/classes/java/lang/constant/DirectMethodHandleDesc.java
! test/jdk/java/lang/constant/MethodHandleDescTest.java

Changeset: 01f12fba
Author:    Jan Lahoda 
Date:      2021-06-22 07:34:30 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/01f12fba648b8c0cb64870b00e6f0f3a7f0ba4c9

8266631: StandardJavaFileManager: getJavaFileObjects() impl violates the spec
8266596: StandardJavaFileManager: default impls of setLocationFromPaths(), getJavaFileObjectsFromPaths() methods don't throw IllegalArgumentException as specified
8266591: StandardJavaFileManager::getJavaFileObjectsFromPaths() methods contain a typo in their spec
8266590: StandardJavaFileManager::setLocationFromPaths() spec contains an error

Reviewed-by: vromero, jjg

! src/java.compiler/share/classes/javax/tools/StandardJavaFileManager.java

Changeset: 9ec7180f
Author:    Erik ?sterlund 
Date:      2021-06-22 15:20:10 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/9ec7180f1ebf2ff19b0735f7b1c4fc9b97d632be

8268524: nmethod::post_compiled_method_load_event racingly called on zombie

Reviewed-by: kvn, neliasso, coleenp

! src/hotspot/share/code/nmethod.cpp
! src/hotspot/share/prims/jvmtiCodeBlobEvents.cpp

Changeset: 8fa25208
Author:    Jorn Vernee 
Date:      2021-06-22 15:27:43 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/8fa2520803c9b9be41b26b4b34b7d2040a7b1dfb

8268888: Upstream 8268230: Foreign Linker API & Windows user32/kernel32: String conversion seems broken

Reviewed-by: mcimadamore

! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java
! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/SharedUtils.java
+ test/jdk/java/foreign/TestNULLAddress.java
- test/jdk/java/foreign/TestNULLTarget.java
+ test/jdk/java/foreign/TestStringEncoding.java
! test/jdk/java/foreign/handles/lookup_module/handle/lookup/MethodHandleLookup.java

Changeset: 578c55bb
Author:    Roland Westrelin 
Date:      2021-06-22 15:46:44 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/578c55bbe65baec733bb633afbc1423010fa6aed

8267399: C2: java/text/Normalizer/ConformanceTest.java test failed with assertion

Reviewed-by: kvn, neliasso

! src/hotspot/share/opto/loopTransform.cpp
+ test/hotspot/jtreg/compiler/loopopts/TestDeadCountedLoop.java

Changeset: dc12cb78
Author:    Nils Eliasson 
Date:      2021-06-22 16:21:35 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/dc12cb78b81f56e9d4b282cf7cad5faa9a9886bf

8267652: c2 loop unrolling by 8 results in reading memory past array

Reviewed-by: sviswanathan, kvn, vlivanov

! src/hotspot/cpu/x86/x86.ad

Changeset: 35e4c272
Author:    Andy Herrick 
Date:      2021-06-22 19:08:58 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/35e4c2720df64ea6cb68ba8fb62aeeb0562c2907

8268404: [TESTBUG] tools/jpackage/windows/WinInstallerIconTest.java failed "AssertionError: Failed: Check icon"

Reviewed-by: asemenyuk

! test/jdk/ProblemList.txt
! test/jdk/tools/jpackage/windows/WinInstallerIconTest.java

Changeset: b6cfca8a
Author:    Jesper Wilhelmsson 
Date:      2021-06-23 01:05:44 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/b6cfca8a89810c7ed63ebc34ed9855b66ebcb5d9

Merge


Changeset: cd678a38
Author:    Guoxiong Li 
Committer: David Holmes 
Date:      2021-06-23 02:21:24 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/cd678a383f7b23ea40132b207ddfc041394ba4c1

8268368: Adopt cast notation for JavaThread conversions

Reviewed-by: dholmes, stefank

! src/hotspot/cpu/zero/frame_zero.cpp
! src/hotspot/os/windows/os_windows.cpp
! src/hotspot/share/code/dependencies.cpp
! src/hotspot/share/compiler/compileBroker.cpp
! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp
! src/hotspot/share/gc/shared/cardTableBarrierSet.cpp
! src/hotspot/share/gc/shared/memAllocator.cpp
! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.cpp
! src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp
! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.cpp
! src/hotspot/share/gc/z/zBarrierSet.cpp
! src/hotspot/share/gc/z/zFuture.inline.hpp
! src/hotspot/share/gc/z/zMark.cpp
! src/hotspot/share/gc/z/zObjArrayAllocator.cpp
! src/hotspot/share/gc/z/zVerify.cpp
! src/hotspot/share/jfr/jni/jfrJavaSupport.cpp
! src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp
! src/hotspot/share/jfr/recorder/checkpoint/jfrCheckpointManager.cpp
! src/hotspot/share/jfr/recorder/checkpoint/types/jfrThreadState.cpp
! src/hotspot/share/jfr/recorder/checkpoint/types/jfrType.cpp
! src/hotspot/share/jfr/recorder/repository/jfrEmergencyDump.cpp
! src/hotspot/share/jfr/recorder/service/jfrPostBox.cpp
! src/hotspot/share/jfr/recorder/stacktrace/jfrStackTraceRepository.cpp
! src/hotspot/share/jfr/support/jfrThreadLocal.cpp
! src/hotspot/share/jfr/writers/jfrJavaEventWriter.cpp
! src/hotspot/share/jvmci/jvmciCompilerToVM.cpp
! src/hotspot/share/jvmci/jvmciEnv.cpp
! src/hotspot/share/oops/constantPool.cpp
! src/hotspot/share/oops/generateOopMap.cpp
! src/hotspot/share/oops/instanceKlass.cpp
! src/hotspot/share/oops/method.cpp
! src/hotspot/share/prims/jni.cpp
! src/hotspot/share/prims/jniCheck.cpp
! src/hotspot/share/prims/jvmtiEnter.xsl
! src/hotspot/share/prims/jvmtiEnvBase.cpp
! src/hotspot/share/prims/jvmtiEnvThreadState.cpp
! src/hotspot/share/prims/jvmtiEventController.cpp
! src/hotspot/share/prims/jvmtiExport.cpp
! src/hotspot/share/prims/jvmtiRawMonitor.cpp
! src/hotspot/share/prims/jvmtiTrace.cpp
! src/hotspot/share/prims/universalUpcallHandler.cpp
! src/hotspot/share/prims/whitebox.cpp
! src/hotspot/share/runtime/deoptimization.cpp
! src/hotspot/share/runtime/handshake.cpp
! src/hotspot/share/runtime/interfaceSupport.cpp
! src/hotspot/share/runtime/interfaceSupport.inline.hpp
! src/hotspot/share/runtime/java.cpp
! src/hotspot/share/runtime/jniHandles.cpp
! src/hotspot/share/runtime/mutex.cpp
! src/hotspot/share/runtime/objectMonitor.cpp
! src/hotspot/share/runtime/os.cpp
! src/hotspot/share/runtime/safepoint.cpp
! src/hotspot/share/runtime/safepointVerifiers.cpp
! src/hotspot/share/runtime/sharedRuntime.cpp
! src/hotspot/share/runtime/stackWatermarkSet.cpp
! src/hotspot/share/runtime/sweeper.cpp
! src/hotspot/share/runtime/synchronizer.cpp
! src/hotspot/share/runtime/thread.cpp
! src/hotspot/share/runtime/thread.hpp
! src/hotspot/share/runtime/vmOperations.cpp
! src/hotspot/share/runtime/vmThread.cpp
! src/hotspot/share/services/threadService.cpp
! src/hotspot/share/utilities/vmError.cpp

Changeset: ae3eedce
Author:    miao zheng 
Committer: Hui Shi 
Date:      2021-06-23 02:45:58 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/ae3eedce9d17324f89daccf488e00d8c7858521e

8268727: Remove unused slowpath locking method in OptoRuntime

Reviewed-by: dlong

! src/hotspot/share/opto/runtime.hpp

Changeset: 36d82b6e
Author:    Joshua Zhu 
Committer: Yi Yang 
Date:      2021-06-23 03:54:00 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/36d82b6ef18d8add5f97fad507b7d86d702bdf13

8268858: Determine register pressure automatically by the number of available registers for allocation

Reviewed-by: kvn, dlong

! src/hotspot/cpu/aarch64/aarch64.ad
! src/hotspot/cpu/aarch64/c2_globals_aarch64.hpp
! src/hotspot/cpu/arm/arm.ad
! src/hotspot/cpu/arm/c2_globals_arm.hpp
! src/hotspot/cpu/ppc/c2_globals_ppc.hpp
! src/hotspot/cpu/ppc/ppc.ad
! src/hotspot/cpu/s390/c2_globals_s390.hpp
! src/hotspot/cpu/s390/s390.ad
! src/hotspot/cpu/x86/c2_globals_x86.hpp
! src/hotspot/cpu/x86/x86.ad
! src/hotspot/cpu/x86/x86_32.ad
! src/hotspot/cpu/x86/x86_64.ad
! src/hotspot/share/opto/c2_globals.hpp
! src/hotspot/share/opto/chaitin.cpp
! src/hotspot/share/opto/ifg.cpp
! src/hotspot/share/opto/lcm.cpp
! src/hotspot/share/opto/matcher.hpp
! src/hotspot/share/opto/reg_split.cpp
! src/hotspot/share/opto/superword.cpp
+ test/hotspot/jtreg/compiler/regalloc/TestC2IntPressure.java

Changeset: 17daf32a
Author:    Aleksey Shipilev 
Date:      2021-06-23 06:27:40 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/17daf32a073bc4f12602b4872ce708e09c453ced

8269138: Move typeArrayOop.inline.hpp include to vectorSupport.cpp

Reviewed-by: stefank, vlivanov

! src/hotspot/share/prims/vectorSupport.cpp
! src/hotspot/share/prims/vectorSupport.hpp

Changeset: a5e43070
Author:    Thomas Schatzl 
Date:      2021-06-23 06:51:53 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/a5e4307050d19c842c08ad96b3a0c36e7dee1951

8269134: Remove sparsePRT.inline.hpp after JDK-8017163

Reviewed-by: iwalulya, kbarrett

- src/hotspot/share/gc/g1/sparsePRT.inline.hpp

Changeset: 62376306
Author:    Aleksey Shipilev 
Date:      2021-06-23 07:03:51 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/6237630664fd956aa6025a181e9cb874806dcecf

8269120: Build failure with GCC 6.3.0 after JDK-8017163

Reviewed-by: iwalulya, tschatzl, kbarrett

! src/hotspot/share/gc/g1/g1CardSetMemory.hpp

Changeset: 2c29d790
Author:    miao zheng 
Committer: Hui Shi 
Date:      2021-06-23 08:51:35 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/2c29d790cac0525130ade6caf10a60ba5a1320a9

8269206: A small typo in comment in test/lib/sun/hotspot/WhiteBox.java

Reviewed-by: dholmes

! test/lib/sun/hotspot/WhiteBox.java

Changeset: f2e690e0
Author:    Harold Seigel 
Date:      2021-06-23 12:11:37 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/f2e690e0ee503794cb50740170912697640d70ff

8268720: Unspecified checks on NameAndType constants should not be performed

Reviewed-by: dholmes, lfoltan

! src/hotspot/share/classfile/classFileParser.cpp
! src/hotspot/share/classfile/classFileParser.hpp
+ test/hotspot/jtreg/runtime/classFileParserBug/NameAndTypeSig.java
+ test/hotspot/jtreg/runtime/classFileParserBug/nonVoidInitSig.jcod

Changeset: 52d5d1b3
Author:    Coleen Phillimore 
Date:      2021-06-23 14:26:30 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/52d5d1b3617731bf312aa5813bf7e78ca4dacb00

8269188: [BACKOUT] Remove CodeCache::mark_for_evol_deoptimization() method

Reviewed-by: dholmes, sspitsyn

! src/hotspot/share/code/codeCache.cpp
! src/hotspot/share/code/codeCache.hpp
! src/hotspot/share/prims/jvmtiExport.cpp
! src/hotspot/share/prims/jvmtiExport.hpp
! src/hotspot/share/prims/jvmtiManageCapabilities.cpp
! src/hotspot/share/prims/jvmtiRedefineClasses.cpp
! src/hotspot/share/prims/jvmtiRedefineClasses.hpp

Changeset: f3ba2690
Author:    Coleen Phillimore 
Date:      2021-06-23 14:27:31 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/f3ba2690c5b34673ebf6836c87e45477e1ff91c3

8256306: ObjectMonitor::_contentions field should not be 'jint'

Reviewed-by: dholmes, stuefe, dcubed

! src/hotspot/share/runtime/objectMonitor.cpp
! src/hotspot/share/runtime/objectMonitor.hpp
! src/hotspot/share/runtime/objectMonitor.inline.hpp
! src/hotspot/share/runtime/vmStructs.cpp
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/ObjectMonitor.java

Changeset: 7621fa37
Author:    Mahendra Chhipa 
Committer: Michael McMahon 
Date:      2021-06-23 15:19:10 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/7621fa37efb2739b953da1cda87dca4762b5bd0c

8268464: Remove dependancy of TestHttpsServer, HttpTransaction, HttpCallback from open/test/jdk/sun/net/www/protocol/https/ tests

Reviewed-by: dfuchs, michaelm

- test/jdk/sun/net/www/protocol/https/AbstractCallback.java
! test/jdk/sun/net/www/protocol/https/ChunkedOutputStream.java
- test/jdk/sun/net/www/protocol/https/HttpCallback.java
- test/jdk/sun/net/www/protocol/https/HttpTransaction.java
! test/jdk/sun/net/www/protocol/https/HttpsURLConnection/B6216082.java
! test/jdk/sun/net/www/protocol/https/HttpsURLConnection/TunnelProxy.java
- test/jdk/sun/net/www/protocol/https/TestHttpsServer.java

Changeset: f3759164
Author:    Coleen Phillimore 
Date:      2021-06-23 21:11:06 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/f3759164179b2471d34df1225085deaf6c0f8fed

8269186: [REDO] Remove CodeCache::mark_for_evol_deoptimization() method

Reviewed-by: hseigel, lfoltan, sspitsyn

! src/hotspot/share/code/codeCache.cpp
! src/hotspot/share/code/codeCache.hpp
! src/hotspot/share/prims/jvmtiRedefineClasses.cpp
! src/hotspot/share/prims/jvmtiRedefineClasses.hpp

Changeset: 280f2d57
Author:    Alex Menkov 
Date:      2021-06-24 00:28:45 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/280f2d57d1f78b3d15dd98e726267a100eb0b5db

8268433: serviceability/dcmd/framework/VMVersionTest.java fails with Unable to send object throw not established PipeIO Listener Thread connection

Reviewed-by: sspitsyn, cjplummer

! test/hotspot/jtreg/ProblemList-zgc.txt
! test/hotspot/jtreg/serviceability/dcmd/framework/TestProcessLauncher.java

Changeset: 51d91597
Author:    Alex Menkov 
Date:      2021-06-24 00:29:36 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/51d915979cec4f4d7f20df8e5d3394025d7a3dc7

8236212: CompiledMethodLoad and CompiledMethodUnload events can be posted in START phase

Reviewed-by: sspitsyn, cjplummer

! test/hotspot/jtreg/vmTestbase/nsk/jvmti/CompiledMethodLoad/compmethload001/compmethload001.cpp
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/CompiledMethodUnload/compmethunload001/compmethunload001.cpp

Changeset: e515873f
Author:    Aleksey Shipilev 
Date:      2021-06-24 06:36:30 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/e515873f887ce4071ab4878a4bafca8eea67afea

8269216: Useless initialization in com/sun/crypto/provider/PBES2Parameters.java

Reviewed-by: valeriep

! src/java.base/share/classes/com/sun/crypto/provider/PBES2Parameters.java

Changeset: 7c31903d
Author:    Yumin Qi 
Date:      2021-06-24 14:52:47 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/7c31903dd3f2f27de1c352294558a4c1bd6c51e7

8267075: jcmd VM.cds should print directory of the output files

Reviewed-by: ccheung

! src/java.base/share/classes/jdk/internal/misc/CDS.java
! test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTestDumpBase.java
! test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTestFileSafety.java

Changeset: 595446bf
Author:    Christoph G?ttschkes 
Committer: Igor Veresov 
Date:      2021-06-24 16:49:45 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/595446bff4af65a30fc88470f20baec2199cd139

8269087: CheckSegmentedCodeCache test fails in an emulated-client VM

Reviewed-by: iveresov, kvn

! test/hotspot/jtreg/compiler/codecache/CheckSegmentedCodeCache.java

Changeset: 2fd7943e
Author:    Patricio Chilano Mateo 
Date:      2021-06-24 18:54:41 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/2fd7943ec191559bfb2778305daf82bcc4422028

8256425: Obsolete Biased Locking in JDK 18

Reviewed-by: kvn, dholmes, dcubed, rrich

! make/hotspot/lib/JvmFeatures.gmk
! src/hotspot/cpu/aarch64/aarch64.ad
! src/hotspot/cpu/aarch64/assembler_aarch64.hpp
! src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/c1_LIRGenerator_aarch64.cpp
! src/hotspot/cpu/aarch64/c1_MacroAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/c1_MacroAssembler_aarch64.hpp
! src/hotspot/cpu/aarch64/interp_masm_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/cpu/aarch64/templateTable_aarch64.cpp
! src/hotspot/cpu/arm/arm.ad
! src/hotspot/cpu/arm/assembler_arm.cpp
! src/hotspot/cpu/arm/assembler_arm_32.cpp
! src/hotspot/cpu/arm/c1_LIRAssembler_arm.cpp
! src/hotspot/cpu/arm/c1_LIRGenerator_arm.cpp
! src/hotspot/cpu/arm/c1_MacroAssembler_arm.cpp
! src/hotspot/cpu/arm/c1_MacroAssembler_arm.hpp
! src/hotspot/cpu/arm/c2_MacroAssembler_arm.cpp
! src/hotspot/cpu/arm/c2_MacroAssembler_arm.hpp
! src/hotspot/cpu/arm/interp_masm_arm.cpp
! src/hotspot/cpu/arm/macroAssembler_arm.cpp
! src/hotspot/cpu/arm/macroAssembler_arm.hpp
! src/hotspot/cpu/arm/sharedRuntime_arm.cpp
! src/hotspot/cpu/arm/templateTable_arm.cpp
! src/hotspot/cpu/arm/vm_version_arm.hpp
! src/hotspot/cpu/arm/vm_version_arm_32.cpp
! src/hotspot/cpu/ppc/assembler_ppc.cpp
! src/hotspot/cpu/ppc/c1_MacroAssembler_ppc.cpp
! src/hotspot/cpu/ppc/interp_masm_ppc_64.cpp
! src/hotspot/cpu/ppc/macroAssembler_ppc.cpp
! src/hotspot/cpu/ppc/macroAssembler_ppc.hpp
! src/hotspot/cpu/ppc/ppc.ad
! src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp
! src/hotspot/cpu/ppc/templateTable_ppc_64.cpp
! src/hotspot/cpu/ppc/vm_version_ppc.cpp
! src/hotspot/cpu/ppc/vm_version_ppc.hpp
! src/hotspot/cpu/s390/assembler_s390.cpp
! src/hotspot/cpu/s390/c1_MacroAssembler_s390.cpp
! src/hotspot/cpu/s390/interp_masm_s390.cpp
! src/hotspot/cpu/s390/macroAssembler_s390.cpp
! src/hotspot/cpu/s390/macroAssembler_s390.hpp
! src/hotspot/cpu/s390/s390.ad
! src/hotspot/cpu/s390/sharedRuntime_s390.cpp
! src/hotspot/cpu/s390/templateTable_s390.cpp
! src/hotspot/cpu/x86/assembler_x86.cpp
! src/hotspot/cpu/x86/assembler_x86.hpp
! src/hotspot/cpu/x86/c1_LIRAssembler_x86.cpp
! src/hotspot/cpu/x86/c1_LIRGenerator_x86.cpp
! src/hotspot/cpu/x86/c1_MacroAssembler_x86.cpp
! src/hotspot/cpu/x86/c1_MacroAssembler_x86.hpp
! src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp
! src/hotspot/cpu/x86/c2_MacroAssembler_x86.hpp
! src/hotspot/cpu/x86/interp_masm_x86.cpp
! src/hotspot/cpu/x86/macroAssembler_x86.cpp
! src/hotspot/cpu/x86/macroAssembler_x86.hpp
! src/hotspot/cpu/x86/sharedRuntime_x86.cpp
! src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp
! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp
! src/hotspot/cpu/x86/templateTable_x86.cpp
! src/hotspot/cpu/x86/vm_version_x86.cpp
! src/hotspot/cpu/x86/vm_version_x86.hpp
! src/hotspot/cpu/x86/x86_32.ad
! src/hotspot/cpu/x86/x86_64.ad
! src/hotspot/cpu/zero/assembler_zero.cpp
! src/hotspot/share/adlc/main.cpp
! src/hotspot/share/adlc/output_c.cpp
! src/hotspot/share/c1/c1_Runtime1.cpp
! src/hotspot/share/cds/heapShared.cpp
! src/hotspot/share/classfile/classFileParser.cpp
! src/hotspot/share/classfile/systemDictionary.cpp
! src/hotspot/share/code/nmethod.hpp
! src/hotspot/share/gc/g1/g1FullCollector.cpp
! src/hotspot/share/gc/g1/g1FullGCCompactionPoint.cpp
! src/hotspot/share/gc/g1/g1FullGCOopClosures.inline.hpp
! src/hotspot/share/gc/parallel/psScavenge.cpp
! src/hotspot/share/gc/serial/markSweep.inline.hpp
! src/hotspot/share/gc/shared/genCollectedHeap.cpp
! src/hotspot/share/gc/shared/genCollectedHeap.hpp
! src/hotspot/share/gc/shared/memAllocator.cpp
! src/hotspot/share/gc/shenandoah/shenandoahForwarding.inline.hpp
! src/hotspot/share/gc/shenandoah/shenandoahFullGC.cpp
! src/hotspot/share/interpreter/interpreterRuntime.cpp
! src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp
! src/hotspot/share/jfr/metadata/metadata.xml
! src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp
! src/hotspot/share/jvmci/jvmciRuntime.cpp
! src/hotspot/share/jvmci/vmStructs_jvmci.cpp
! src/hotspot/share/logging/logTag.hpp
! src/hotspot/share/oops/instanceKlass.cpp
! src/hotspot/share/oops/klass.cpp
! src/hotspot/share/oops/klass.hpp
! src/hotspot/share/oops/klass.inline.hpp
! src/hotspot/share/oops/markWord.cpp
! src/hotspot/share/oops/markWord.hpp
- src/hotspot/share/oops/markWord.inline.hpp
! src/hotspot/share/oops/oop.hpp
! src/hotspot/share/oops/oop.inline.hpp
! src/hotspot/share/opto/c2_globals.hpp
! src/hotspot/share/opto/callnode.cpp
! src/hotspot/share/opto/graphKit.cpp
! src/hotspot/share/opto/library_call.cpp
! src/hotspot/share/opto/locknode.cpp
! src/hotspot/share/opto/locknode.hpp
! src/hotspot/share/opto/machnode.hpp
! src/hotspot/share/opto/macro.cpp
! src/hotspot/share/opto/matcher.cpp
! src/hotspot/share/opto/memnode.cpp
! src/hotspot/share/opto/runtime.cpp
! src/hotspot/share/opto/runtime.hpp
! src/hotspot/share/opto/type.hpp
! src/hotspot/share/prims/jvmtiEnvBase.cpp
! src/hotspot/share/prims/jvmtiTagMap.cpp
! src/hotspot/share/prims/whitebox.cpp
! src/hotspot/share/runtime/abstract_vm_version.hpp
! src/hotspot/share/runtime/arguments.cpp
- src/hotspot/share/runtime/biasedLocking.cpp
- src/hotspot/share/runtime/biasedLocking.hpp
! src/hotspot/share/runtime/deoptimization.cpp
! src/hotspot/share/runtime/deoptimization.hpp
! src/hotspot/share/runtime/flags/jvmFlagConstraintsRuntime.cpp
! src/hotspot/share/runtime/flags/jvmFlagConstraintsRuntime.hpp
! src/hotspot/share/runtime/frame.hpp
! src/hotspot/share/runtime/globals.hpp
! src/hotspot/share/runtime/java.cpp
! src/hotspot/share/runtime/sharedRuntime.cpp
! src/hotspot/share/runtime/synchronizer.cpp
! src/hotspot/share/runtime/thread.cpp
! src/hotspot/share/runtime/thread.hpp
! src/hotspot/share/runtime/vframeArray.cpp
! src/hotspot/share/runtime/vframe_hp.cpp
! src/hotspot/share/runtime/vmOperation.hpp
! src/hotspot/share/runtime/vmStructs.cpp
! src/java.base/share/man/java.1
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/Mark.java
! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotResolvedObjectTypeImpl.java
! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotVMConfig.java
! src/jdk.jfr/share/conf/jfr/default.jfc
! src/jdk.jfr/share/conf/jfr/profile.jfc
! test/hotspot/gtest/gc/shared/test_preservedMarks.cpp
! test/hotspot/gtest/oops/test_markWord.cpp
! test/hotspot/jtreg/ProblemList-Xcomp.txt
! test/hotspot/jtreg/ProblemList.txt
- test/hotspot/jtreg/compiler/c2/Test8062950.java
- test/hotspot/jtreg/compiler/c2/TestUseOptoBiasInliningWithoutEliminateLocks.java
! test/hotspot/jtreg/compiler/loopstripmining/CheckLoopStripMining.java
! test/hotspot/jtreg/compiler/rtm/cli/RTMGenericCommandLineOptionTest.java
- test/hotspot/jtreg/compiler/rtm/cli/TestUseRTMLockingOptionWithBiasedLocking.java
- test/hotspot/jtreg/compiler/uncommontrap/TestLockEliminatedAtDeopt.java
! test/hotspot/jtreg/gc/TestFullGCALot.java
! test/hotspot/jtreg/runtime/7167069/PrintAsFlag.java
! test/hotspot/jtreg/runtime/Monitor/SyncOnValueBasedClassTest.java
! test/hotspot/jtreg/runtime/cds/appcds/javaldr/LockDuringDump.java
! test/hotspot/jtreg/runtime/handshake/HandshakeDirectTest.java
- test/hotspot/jtreg/runtime/logging/BiasedLockingTest.java
! test/hotspot/jtreg/serviceability/jvmti/GetOwnedMonitorInfo/GetOwnedMonitorInfoWithEATest.java
! test/hotspot/jtreg/serviceability/jvmti/GetOwnedMonitorStackDepthInfo/GetOwnedMonitorStackDepthInfoWithEATest.java
! test/hotspot/jtreg/serviceability/jvmti/Heap/IterateHeapWithEscapeAnalysisEnabled.java
! test/hotspot/jtreg/serviceability/sa/ClhsdbLongConstant.java
! test/jdk/com/sun/jdi/EATests.java
- test/jdk/jdk/jfr/event/runtime/TestBiasedLockRevocationEvents.java
! test/lib/jdk/test/lib/jfr/EventNames.java
! test/lib/sun/hotspot/WhiteBox.java
! test/micro/org/openjdk/bench/vm/lang/LockUnlock.java

Changeset: 42968db1
Author:    Coleen Phillimore 
Date:      2021-06-24 19:34:17 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/42968db173b3caa53b6ad403f1891c41bcc6fb75

8269293: ObjectMonitor thread id fields should be 64 bits.

Reviewed-by: mgronlun, dcubed

! src/hotspot/share/runtime/objectMonitor.cpp
! src/hotspot/share/runtime/objectMonitor.hpp

Changeset: c79034e0
Author:    Zhengyu Gu 
Date:      2021-06-24 21:02:16 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/c79034e0c94a21a0ef3655e0d7da7629d7b40d8c

8269303: Remove unnecessary forward declaration of PSPromotionManager in cpCache.hpp

Reviewed-by: kbarrett

! src/hotspot/share/oops/cpCache.hpp

Changeset: 08ee7ae6
Author:    David Holmes 
Date:      2021-06-24 23:58:32 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/08ee7ae67246b45be9684a4a283f0103f5f1c0c4

8268855: Cleanup name handling in the Thread class and subclasses

Reviewed-by: lfoltan, coleenp

! src/hotspot/cpu/aarch64/gc/shared/barrierSetNMethod_aarch64.cpp
! src/hotspot/cpu/x86/gc/shared/barrierSetNMethod_x86.cpp
! src/hotspot/share/compiler/compileBroker.cpp
! src/hotspot/share/gc/shared/concurrentGCThread.hpp
! src/hotspot/share/gc/shared/workgroup.hpp
! src/hotspot/share/gc/shenandoah/shenandoahControlThread.hpp
! src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp
! src/hotspot/share/jvmci/jvmciCompilerToVM.cpp
! src/hotspot/share/jvmci/jvmciEnv.cpp
! src/hotspot/share/logging/logAsyncWriter.hpp
! src/hotspot/share/prims/jni.cpp
! src/hotspot/share/runtime/nonJavaThread.hpp
! src/hotspot/share/runtime/thread.cpp
! src/hotspot/share/runtime/thread.hpp
! src/hotspot/share/runtime/vmThread.hpp
! src/hotspot/share/services/threadService.cpp

Changeset: c37988d0
Author:    Scott Gibbons 
Committer: Sandhya Viswanathan 
Date:      2021-06-25 03:19:48 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/c37988d0793b24d98d285530dfda69999a227937

8268276: Base64 Decoding optimization for x86 using AVX-512

Reviewed-by: erikj, sviswanathan, kvn

! .gitignore
! src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp
! src/hotspot/cpu/ppc/stubGenerator_ppc.cpp
! src/hotspot/cpu/x86/assembler_x86.cpp
! src/hotspot/cpu/x86/assembler_x86.hpp
! src/hotspot/cpu/x86/stubGenerator_x86_64.cpp
! src/hotspot/cpu/x86/stubRoutines_x86.cpp
! src/hotspot/cpu/x86/stubRoutines_x86.hpp
! src/hotspot/share/classfile/vmIntrinsics.hpp
! src/hotspot/share/opto/library_call.cpp
! src/hotspot/share/opto/runtime.cpp
! src/java.base/share/classes/java/util/Base64.java

Changeset: 3a8f3d6c
Author:    Aleksey Shipilev 
Date:      2021-06-25 08:08:10 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/3a8f3d6cac0ab859704db533bf1f63431fbd9253

8269280: (bf) Replace StringBuffer in *Buffer.toString()

Reviewed-by: alanb, chegar, bpb

! src/java.base/share/classes/java/nio/X-Buffer.java.template
! test/jdk/java/nio/Buffer/Basic-X.java.template
! test/jdk/java/nio/Buffer/BasicByte.java
! test/jdk/java/nio/Buffer/BasicChar.java
! test/jdk/java/nio/Buffer/BasicDouble.java
! test/jdk/java/nio/Buffer/BasicFloat.java
! test/jdk/java/nio/Buffer/BasicInt.java
! test/jdk/java/nio/Buffer/BasicLong.java
! test/jdk/java/nio/Buffer/BasicShort.java

Changeset: fd43d9cb
Author:    Denghui Dong 
Committer: Yi Yang 
Date:      2021-06-25 08:15:34 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/fd43d9cb40f7e4b0f5ebc490e0490a222b8f2770

8269225: JFR.stop misses the written info when the filename is only specified by JFR.start

Reviewed-by: egahlin

! src/jdk.jfr/share/classes/jdk/jfr/internal/dcmd/DCmdStop.java
+ test/jdk/jdk/jfr/jcmd/TestJcmdStopWithoutFilename.java

Changeset: fdcae665
Author:    Ludovic Henry 
Committer: Jaroslav Bachorik 
Date:      2021-06-25 08:30:30 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/fdcae6653c215646c83e19721a18508f6e667eb4

8269092: Add OldObjectSampleEvent.allocationSize field

Reviewed-by: egahlin, jbachorik

! src/hotspot/share/jfr/leakprofiler/checkpoint/eventEmitter.cpp
! src/hotspot/share/jfr/metadata/metadata.xml
+ test/jdk/jdk/jfr/event/oldobject/TestObjectSize.java

Changeset: ffa34ed4
Author:    Markus Gr?nlund 
Date:      2021-06-25 09:41:23 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/ffa34ed429079827c9b0acb843288fde4b7fa53d

8265919: RunThese30M fails "assert((!(((((JfrTraceIdBits::load(value)) & ((1 << 4) << 8)) != 0))))) failed: invariant"

Reviewed-by: egahlin

! src/hotspot/share/jfr/recorder/checkpoint/types/jfrTypeSet.cpp

Changeset: 7c87d69c
Author:    duke 
Date:      2021-06-25 11:01:08 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/7c87d69ce90c5b214af8ce4d2a1e989b69de2e01

Automatic merge of jdk:master into master


Changeset: 347a5a71
Author:    J. Duke 
Committer: Jorn Vernee 
Date:      2021-06-25 11:26:04 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/347a5a71a6560e121e6873c213cecf51900754bb

Merge master

! src/hotspot/share/logging/logTag.hpp
! src/hotspot/share/logging/logTag.hpp

Changeset: d02c50ad
Author:    duke 
Date:      2021-06-25 11:27:23 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/d02c50ada21e000f6e7c442fc17eb9fd66f0604d

Automatic merge of foreign-memaccess+abi into foreign-jextract



From mcimadamore at openjdk.java.net  Fri Jun 25 12:09:12 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 25 Jun 2021 12:09:12 GMT
Subject: [foreign-memaccess+abi] RFR: Add support for high-level functions
 to copy to and from Java arrays [v7]
In-Reply-To: 
References: 
 <9i1kyGGgfDL13489oNPK2GHBYOLo7r2jaEhilwukois=.d46e47cb-9309-428c-8be1-e0ae8ee6fc1b@github.com>
 
Message-ID: 

On Fri, 25 Jun 2021 11:28:06 GMT, Uwe Schindler  wrote:

> Hi,
> Wouldn't it make sense to change MemoryCopy test to use a read-only source segment, so we ensure that the access checks are correct? The first bug I found was that it tried to check for write access on the copy source.

I think this has been addressed?
> 
> I left a comment where the check could be integrated into the test.
> 
> Otherwise, looks fine to me. I have no strong preference on the parameter order, but I would prefer System.arrayCopy style.

-------------

PR: https://git.openjdk.java.net/panama-foreign/pull/555

From mcimadamore at openjdk.java.net  Fri Jun 25 12:09:12 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 25 Jun 2021 12:09:12 GMT
Subject: [foreign-memaccess+abi] RFR: Add support for high-level functions
 to copy to and from Java arrays [v7]
In-Reply-To: 
References: 
 <9i1kyGGgfDL13489oNPK2GHBYOLo7r2jaEhilwukois=.d46e47cb-9309-428c-8be1-e0ae8ee6fc1b@github.com>
 
 
Message-ID: <7ffL3EWOMYpMJd5GQC8-ipRBf6GOfOkiRTCDJ8ohskQ=.6e84a639-04bb-4589-988f-74bb18b5ce0d@github.com>

On Fri, 25 Jun 2021 12:04:07 GMT, Maurizio Cimadamore  wrote:

> > Hi,
> > Wouldn't it make sense to change MemoryCopy test to use a read-only source segment, so we ensure that the access checks are correct? The first bug I found was that it tried to check for write access on the copy source.
> 
> I think this has been addressed?
> 
> > I left a comment where the check could be integrated into the test.
> > Otherwise, looks fine to me. I have no strong preference on the parameter order, but I would prefer System.arrayCopy style.

Note that I couldn't just add asReadOnly() to the source segment, as we're copying bits from segment to itself. What I did instead was to turn as read only the "source slice" which is used by the test.

-------------

PR: https://git.openjdk.java.net/panama-foreign/pull/555

From uschindler at openjdk.java.net  Fri Jun 25 12:56:20 2021
From: uschindler at openjdk.java.net (Uwe Schindler)
Date: Fri, 25 Jun 2021 12:56:20 GMT
Subject: [foreign-memaccess+abi] RFR: Add support for high-level functions
 to copy to and from Java arrays [v7]
In-Reply-To: <7ffL3EWOMYpMJd5GQC8-ipRBf6GOfOkiRTCDJ8ohskQ=.6e84a639-04bb-4589-988f-74bb18b5ce0d@github.com>
References: 
 <9i1kyGGgfDL13489oNPK2GHBYOLo7r2jaEhilwukois=.d46e47cb-9309-428c-8be1-e0ae8ee6fc1b@github.com>
 
 
 <7ffL3EWOMYpMJd5GQC8-ipRBf6GOfOkiRTCDJ8ohskQ=.6e84a639-04bb-4589-988f-74bb18b5ce0d@github.com>
Message-ID: 

On Fri, 25 Jun 2021 12:06:04 GMT, Maurizio Cimadamore  wrote:

> Note that I couldn't just add asReadOnly() to the source segment, as we're copying bits from segment to itself. What I did instead was to turn as read only the "source slice" which is used by the test.

Ok, missed this. When I looked at you patch after you fixed it, I may have overseen it. Sorry for this.

-------------

PR: https://git.openjdk.java.net/panama-foreign/pull/555

From uschindler at openjdk.java.net  Fri Jun 25 12:59:09 2021
From: uschindler at openjdk.java.net (Uwe Schindler)
Date: Fri, 25 Jun 2021 12:59:09 GMT
Subject: [foreign-memaccess+abi] RFR: Add support for high-level functions
 to copy to and from Java arrays [v7]
In-Reply-To: <9i1kyGGgfDL13489oNPK2GHBYOLo7r2jaEhilwukois=.d46e47cb-9309-428c-8be1-e0ae8ee6fc1b@github.com>
References: 
 <9i1kyGGgfDL13489oNPK2GHBYOLo7r2jaEhilwukois=.d46e47cb-9309-428c-8be1-e0ae8ee6fc1b@github.com>
Message-ID: 

On Fri, 25 Jun 2021 11:15:39 GMT, Maurizio Cimadamore  wrote:

>> This patch includes some of the changes from Lee to support a set of static functions to allow bulk copy from Java arrays to segments (and viceversa) in a more succint fashion (so that the user doesn't have to create a temporary heap segment to do the copy).
>> 
>> I've added a new public method to `MemorySegment` which performs an *element-wise* bulk copy; it takes a source segment and a couple of element layouts: the source element layout and the destination element layout. The two layouts must have same size, but can have different alignments (which will be checked against the corresponding segments) and byte orders. If the byte order differs, a bulk copy with swap will be performed. As such, this method generalizes the previous `copyFrom` - as follows:
>> 
>> 
>> copyFrom(srcSegment) -> copyFrom(JAVA_BYTE, srcSegment, JAVA_BYTE)
>> 
>> I've added support for argument type profiling for MemoryCopy static methods to avoid type pollution in cases where same metod is called with different memory segment types.
>> 
>> I've done a pass over the javadoc, and make it more consistent with the rest of the API. I've also reworked the test a bit to use the data provider functionality of TestNG, since all the test cases were similar, except for the carrier type.
>> 
>> There are other cosmetic changes as well, compared to original code from Lee, such as naming of static fields which is now capitalized. Everything else is the same.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove argument type profiling for MemoryCopy methods

Looks fine! Performance tested.

-------------

Marked as reviewed by uschindler (no project role).

PR: https://git.openjdk.java.net/panama-foreign/pull/555

From uschindler at openjdk.java.net  Fri Jun 25 12:59:10 2021
From: uschindler at openjdk.java.net (Uwe Schindler)
Date: Fri, 25 Jun 2021 12:59:10 GMT
Subject: [foreign-memaccess+abi] RFR: Add support for high-level functions
 to copy to and from Java arrays [v4]
In-Reply-To: <8QjsynVVn9RDlQVN4-vODETiAVEXgRhsxCti2XyvziA=.65043518-8596-4ec8-99f9-46f60106a397@github.com>
References: 
 
 <8QjsynVVn9RDlQVN4-vODETiAVEXgRhsxCti2XyvziA=.65043518-8596-4ec8-99f9-46f60106a397@github.com>
Message-ID: 

On Tue, 22 Jun 2021 14:23:08 GMT, Uwe Schindler  wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix wrong polarity of readOnly in copyTo methods
>
> test/jdk/java/foreign/TestMemoryCopy.java line 119:
> 
>> 117:             arr[i] = (byte)i;
>> 118:         }
>> 119:         return MemorySegment.ofArray(arr);
> 
> This segment should be made readonly, to assert all checkAccess() calls.

Ok - you added this to slice, e.g. here. I have overseen this! https://github.com/openjdk/panama-foreign/pull/555/files#diff-cf69e75a9e792b2f93dec150609654fe2dc3b4f3b45a8fbdca1b5b450d52173bR82

-------------

PR: https://git.openjdk.java.net/panama-foreign/pull/555

From duke at openjdk.java.net  Fri Jun 25 13:22:37 2021
From: duke at openjdk.java.net (duke)
Date: Fri, 25 Jun 2021 13:22:37 GMT
Subject: git: openjdk/panama-foreign: foreign-jextract: 2 new changesets
Message-ID: 

Changeset: e3a68dbf
Author:    Maurizio Cimadamore 
Date:      2021-06-25 13:20:31 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/e3a68dbfb261252835e6f429053f97f8abd9334c

Add support for high-level functions to copy to and from Java arrays

Reviewed-by: jvernee, uschindler

! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemoryAccess.java
+ src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemoryCopy.java
! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemorySegment.java
! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/SegmentAllocator.java
! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java
+ test/jdk/java/foreign/TestCopyFrom.java
! test/jdk/java/foreign/TestMemoryCopy.java
! test/jdk/java/foreign/TestNulls.java

Changeset: 2acaae1d
Author:    duke 
Date:      2021-06-25 13:21:18 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/2acaae1de5cb023620a399edbaf8da7d8051b4a3

Automatic merge of foreign-memaccess+abi into foreign-jextract



From mcimadamore at openjdk.java.net  Fri Jun 25 13:24:15 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 25 Jun 2021 13:24:15 GMT
Subject: [foreign-memaccess+abi] RFR: Add support for high-level functions
 to copy to and from Java arrays [v7]
In-Reply-To: <9i1kyGGgfDL13489oNPK2GHBYOLo7r2jaEhilwukois=.d46e47cb-9309-428c-8be1-e0ae8ee6fc1b@github.com>
References: 
 <9i1kyGGgfDL13489oNPK2GHBYOLo7r2jaEhilwukois=.d46e47cb-9309-428c-8be1-e0ae8ee6fc1b@github.com>
Message-ID: 

On Fri, 25 Jun 2021 11:15:39 GMT, Maurizio Cimadamore  wrote:

>> This patch includes some of the changes from Lee to support a set of static functions to allow bulk copy from Java arrays to segments (and viceversa) in a more succint fashion (so that the user doesn't have to create a temporary heap segment to do the copy).
>> 
>> I've added a new public method to `MemorySegment` which performs an *element-wise* bulk copy; it takes a source segment and a couple of element layouts: the source element layout and the destination element layout. The two layouts must have same size, but can have different alignments (which will be checked against the corresponding segments) and byte orders. If the byte order differs, a bulk copy with swap will be performed. As such, this method generalizes the previous `copyFrom` - as follows:
>> 
>> 
>> copyFrom(srcSegment) -> copyFrom(JAVA_BYTE, srcSegment, JAVA_BYTE)
>> 
>> I've added support for argument type profiling for MemoryCopy static methods to avoid type pollution in cases where same metod is called with different memory segment types.
>> 
>> I've done a pass over the javadoc, and make it more consistent with the rest of the API. I've also reworked the test a bit to use the data provider functionality of TestNG, since all the test cases were similar, except for the carrier type.
>> 
>> There are other cosmetic changes as well, compared to original code from Lee, such as naming of static fields which is now capitalized. Everything else is the same.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove argument type profiling for MemoryCopy methods

I'll integrate for now - we'll come back to decide how to fix the signatures at a later point. Thanks!

-------------

PR: https://git.openjdk.java.net/panama-foreign/pull/555

From mcimadamore at openjdk.java.net  Fri Jun 25 13:24:19 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 25 Jun 2021 13:24:19 GMT
Subject: [foreign-memaccess+abi] Integrated: Add support for high-level
 functions to copy to and from Java arrays
In-Reply-To: 
References: 
Message-ID: 

On Thu, 10 Jun 2021 13:03:09 GMT, Maurizio Cimadamore  wrote:

> This patch includes some of the changes from Lee to support a set of static functions to allow bulk copy from Java arrays to segments (and viceversa) in a more succint fashion (so that the user doesn't have to create a temporary heap segment to do the copy).
> 
> I've added a new public method to `MemorySegment` which performs an *element-wise* bulk copy; it takes a source segment and a couple of element layouts: the source element layout and the destination element layout. The two layouts must have same size, but can have different alignments (which will be checked against the corresponding segments) and byte orders. If the byte order differs, a bulk copy with swap will be performed. As such, this method generalizes the previous `copyFrom` - as follows:
> 
> 
> copyFrom(srcSegment) -> copyFrom(JAVA_BYTE, srcSegment, JAVA_BYTE)
> 
> I've added support for argument type profiling for MemoryCopy static methods to avoid type pollution in cases where same metod is called with different memory segment types.
> 
> I've done a pass over the javadoc, and make it more consistent with the rest of the API. I've also reworked the test a bit to use the data provider functionality of TestNG, since all the test cases were similar, except for the carrier type.
> 
> There are other cosmetic changes as well, compared to original code from Lee, such as naming of static fields which is now capitalized. Everything else is the same.

This pull request has now been integrated.

Changeset: e3a68dbf
Author:    Maurizio Cimadamore 
URL:       https://git.openjdk.java.net/panama-foreign/commit/e3a68dbfb261252835e6f429053f97f8abd9334c
Stats:     1483 lines in 8 files changed: 1403 ins; 21 del; 59 mod

Add support for high-level functions to copy to and from Java arrays

Reviewed-by: jvernee, uschindler

-------------

PR: https://git.openjdk.java.net/panama-foreign/pull/555

From gabaden at gmail.com  Sat Jun 26 13:46:07 2021
From: gabaden at gmail.com (Denis Gabaydulin)
Date: Sat, 26 Jun 2021 16:46:07 +0300
Subject: [ a newby question about vectorized shuffling / permutation ]
In-Reply-To: <4B487585-47CD-43A1-8E2B-DF55F79F60AA@oracle.com>
References: 
 
 <4B487585-47CD-43A1-8E2B-DF55F79F60AA@oracle.com>
Message-ID: 

Hi, Paul!

I made a repository with the code and benchmarks.
Also, I attached full information about my hardware/os.

https://github.com/sherman/simd

On Wed, Jun 23, 2021 at 1:47 AM Paul Sandoz  wrote:
>
> Hi Denis,
>
> Thanks for sharing, perhaps you can share the complete JMH benchmark?
>
> In your current approach there may be no benefit to using a vector for the right side, since you unpack the lane elements, just use the array elements directly as input to the broadcast eq.
>
> I would be interested in seeing the shuffle version, if you have it. Some Shuffle/Mask stuff is still work in progress, but it could still be a good test case.
>
> Paul.
>
>
> > On Jun 20, 2021, at 2:26 PM, Denis Gabaydulin  wrote:
> >
> > If somebody is interested in the result, here's my solution (which is
> > twice faster on SPECIES_128).
> >
> > https://gist.github.com/sherman/6d8a4103ba5bb3d2911684b8c842647f
> >
> > Benchmark with the intersection in the middle of arrays.
> >
> > Benchmark                                    Mode Cnt Score  Error  Units
> > IntersectionBenchmark.hasIntersectionScalar thrpt  10 3.785 ? 0.095 ops/us
> > IntersectionBenchmark.hasIntersectionVector thrpt  10 7.008 ? 0.795 ops/us
> >
> > What I do:
> > Changed the shuffling op by the broadcast op.
> >
> > Here's the most significant part in the asm:
> >
> > https://gist.github.com/sherman/7788e37b667940f31531ce74cb53b4e5
> >
> > Would be very appreciated any suggestions and comments on how it can
> > be improved in terms of throughput?
> >
> > On Wed, Jun 2, 2021 at 2:04 PM Denis Gabaydulin  wrote:
> >>
> >> Hi, folks!
> >>
> >> Have a newbie question about the API.
> >> I'm trying to explore a new and shiny vector API with simple but useful examples.
> >>
> >> One of that is to build a SIMD version to find any intersection of two sorted lists.
> >>
> >> E.g.
> >> hasIntersection([1, 3, 4, 10],  [2, 6, 6, 11]) => false
> >> hasIntersection([1, 3, 4, 10],  [2, 3, 6, 11]) => true
> >>
> >> A mental model of this algorithm which I have:
> >>
> >> 1). to get a part of an array one
> >> 2). compare it n-times which corresponding part of an array two.
> >> 3). each time we need to compare two parts of arrays we need to shuffle (permutate) a left part by a mask. E.g. 1, 3, 4, 10 -> 10, 1, 3, 4
> >> 4). if one of a number is the same, return true, otherwise, move.
> >> In SIMD instructions looks like I need two major things.
> >>
> >> 1). vectorized comparison instruction
> >> 2). vectorized shuffle instruction.
> >>
> >> The first one, I can see in the printed asm.
> >> compare in API -> vpcmpeqd
> >>
> >> The question, which function of the vector API should I use to getting something like _mm_shuffle_epi32 ?
> >>
> >>
> >>
> >>
> >
> > On Wed, Jun 2, 2021 at 2:04 PM Denis Gabaydulin  wrote:
> >>
> >> Hi, folks!
> >>
> >> Have a newbie question about the API.
> >> I'm trying to explore a new and shiny vector API with simple but useful examples.
> >>
> >> One of that is to build a SIMD version to find any intersection of two sorted lists.
> >>
> >> E.g.
> >> hasIntersection([1, 3, 4, 10],  [2, 6, 6, 11]) => false
> >> hasIntersection([1, 3, 4, 10],  [2, 3, 6, 11]) => true
> >>
> >> A mental model of this algorithm which I have:
> >>
> >> 1). to get a part of an array one
> >> 2). compare it n-times which corresponding part of an array two.
> >> 3). each time we need to compare two parts of arrays we need to shuffle (permutate) a left part by a mask. E.g. 1, 3, 4, 10 -> 10, 1, 3, 4
> >> 4). if one of a number is the same, return true, otherwise, move.
> >> In SIMD instructions looks like I need two major things.
> >>
> >> 1). vectorized comparison instruction
> >> 2). vectorized shuffle instruction.
> >>
> >> The first one, I can see in the printed asm.
> >> compare in API -> vpcmpeqd
> >>
> >> The question, which function of the vector API should I use to getting something like _mm_shuffle_epi32 ?
> >>
> >>
> >>
> >>
>

From xgong at openjdk.java.net  Mon Jun 28 01:57:38 2021
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Mon, 28 Jun 2021 01:57:38 GMT
Subject: [vectorIntrinsics+mask] RFR: 8269343: Masked vector arithmetic
 intrinsics failed to be inlined randomly
In-Reply-To: 
References: 
Message-ID: 

On Fri, 25 Jun 2021 09:29:58 GMT, Xiaohong Gong  wrote:

> The masked `"lanewise/reduceLanes"` failed to be intrinsified randomly. The main reason is the hotspot c2 compiler cannot
> unbox the mask value due to the expected vector box type being mismatched with the class of the mask value. The vector box type is the` "mask class"` which is specified in Java level and saved in the intrinsic argument list. It is the class of the instance
> of the vector mask (i.e. `"IntMaxMask.class"`), while the type of mask value is the super class (i.e. `"jdk.incubator.vector.VectorMask"`).
> 
> Casting the mask value to the same subclass before calling the intrinsics can solve this issue.

@PaulSandoz , could you please take a look at this PR? Thanks so much!

-------------

PR: https://git.openjdk.java.net/panama-vector/pull/96

From xgong at openjdk.java.net  Mon Jun 28 01:59:21 2021
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Mon, 28 Jun 2021 01:59:21 GMT
Subject: [vectorIntrinsics+mask] RFR: 8269282: Add masking support for
 vector gather_load/scatter_store
In-Reply-To: 
References: 
Message-ID: 

On Fri, 25 Jun 2021 04:11:53 GMT, Xiaohong Gong  wrote:

> This patch adds the masking support for masked vector gather load and scatter store, including:
>   1) The Vector API java implementation and hotspot intrinsics changes:
>     - Add masking information to the `loadWithMap/storeWithMap` intrinsics.
>     - Both masked and non-masked gather_load/scatter_store call the same intrinsics. The mask value and class are set to `"null"` for non-masked operations.
>   2) The C2 compiler changes:
>     - Add two new IRs for the masked gather_load/scatter_store. The new masked IR will be generated for masked operation if the platform supports the predicate feature and the backend has implemented it.  Otherwise, the compiler will go back to the default java implementation.

Hi @PaulSandoz , could you please take a look at the JAVA side of this PR? Thanks so much!

@iwanowww @jatin-bhateja , could you please take a look at the compiler side of this PR? Thanks so much!

Thanks,
Xiaohong

-------------

PR: https://git.openjdk.java.net/panama-vector/pull/95

From psandoz at openjdk.java.net  Mon Jun 28 18:58:56 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Mon, 28 Jun 2021 18:58:56 GMT
Subject: [vectorIntrinsics+mask] RFR: 8269343: Masked vector arithmetic
 intrinsics failed to be inlined randomly
In-Reply-To: 
References: 
Message-ID: 

On Fri, 25 Jun 2021 09:29:58 GMT, Xiaohong Gong  wrote:

> The masked `"lanewise/reduceLanes"` failed to be intrinsified randomly. The main reason is the hotspot c2 compiler cannot
> unbox the mask value due to the expected vector box type being mismatched with the class of the mask value. The vector box type is the` "mask class"` which is specified in Java level and saved in the intrinsic argument list. It is the class of the instance
> of the vector mask (i.e. `"IntMaxMask.class"`), while the type of mask value is the super class (i.e. `"jdk.incubator.vector.VectorMask"`).
> 
> Casting the mask value to the same subclass before calling the intrinsics can solve this issue.

Looks good.

I am wondering why its not needed on the vector arguments, is that because there is a cast to `{T}Vector` for vector arguments in templates is sufficient in those cases? Or does the `that.check(this);` help as well?

-------------

Marked as reviewed by psandoz (Committer).

PR: https://git.openjdk.java.net/panama-vector/pull/96

From psandoz at openjdk.java.net  Mon Jun 28 19:36:30 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Mon, 28 Jun 2021 19:36:30 GMT
Subject: [vectorIntrinsics+mask] RFR: 8269282: Add masking support for
 vector gather_load/scatter_store
In-Reply-To: 
References: 
Message-ID: 

On Fri, 25 Jun 2021 04:11:53 GMT, Xiaohong Gong  wrote:

> This patch adds the masking support for masked vector gather load and scatter store, including:
>   1) The Vector API java implementation and hotspot intrinsics changes:
>     - Add masking information to the `loadWithMap/storeWithMap` intrinsics.
>     - Both masked and non-masked gather_load/scatter_store call the same intrinsics. The mask value and class are set to `"null"` for non-masked operations.
>   2) The C2 compiler changes:
>     - Add two new IRs for the masked gather_load/scatter_store. The new masked IR will be generated for masked operation if the platform supports the predicate feature and the backend has implemented it.  Otherwise, the compiler will go back to the default java implementation.

Java changes look good, but i cannot verify due to compilation errors (enabled warnings as errors), i think unrelated to this patch, can you fix at the same time?

-------------

PR: https://git.openjdk.java.net/panama-vector/pull/95

From xgong at openjdk.java.net  Tue Jun 29 00:50:38 2021
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Tue, 29 Jun 2021 00:50:38 GMT
Subject: [vectorIntrinsics+mask] RFR: 8269282: Add masking support for
 vector gather_load/scatter_store
In-Reply-To: 
References: 
Message-ID: 

On Fri, 25 Jun 2021 04:11:53 GMT, Xiaohong Gong  wrote:

> This patch adds the masking support for masked vector gather load and scatter store, including:
>   1) The Vector API java implementation and hotspot intrinsics changes:
>     - Add masking information to the `loadWithMap/storeWithMap` intrinsics.
>     - Both masked and non-masked gather_load/scatter_store call the same intrinsics. The mask value and class are set to `"null"` for non-masked operations.
>   2) The C2 compiler changes:
>     - Add two new IRs for the masked gather_load/scatter_store. The new masked IR will be generated for masked operation if the platform supports the predicate feature and the backend has implemented it.  Otherwise, the compiler will go back to the default java implementation.

> Java changes look good, but i cannot verify due to compilation errors (enabled warnings as errors), i think unrelated to this patch, can you fix at the same time?
> 
> ```
> /Users/sandoz/Projects/jdk/panama-vector/src/hotspot/share/opto/chaitin.cpp:642:38: error: '&&' within '||' [-Werror,-Wlogical-op-parentheses]
>       } else if (lrg.num_regs() == 1 && !lrg.is_scalable() ||
>                  ~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~ ~~
> /Users/sandoz/Projects/jdk/panama-vector/src/hotspot/share/opto/chaitin.cpp:642:38: note: place parentheses around the '&&' expression to silence this warning
>       } else if (lrg.num_regs() == 1 && !lrg.is_scalable() ||
>                                      ^
>                  (                                        )
> /Users/sandoz/Projects/jdk/panama-vector/src/hotspot/share/opto/chaitin.cpp:643:36: error: '&&' within '||' [-Werror,-Wlogical-op-parentheses]
>                  lrg.is_scalable() && lrg.scalable_reg_slots() == 1) {
>                  ~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> /Users/sandoz/Projects/jdk/panama-vector/src/hotspot/share/opto/chaitin.cpp:643:36: note: place parentheses around the '&&' expression to silence this warning
>                  lrg.is_scalable() && lrg.scalable_reg_slots() == 1) {
>                                    ^
>                  (                                                 )
> 2 errors generated.
> ```

Thanks for your review! Yes, this issue is related to the previous register allocation patch. I will fix it at the same time. Thanks for reminding!

-------------

PR: https://git.openjdk.java.net/panama-vector/pull/95

From xgong at openjdk.java.net  Tue Jun 29 01:54:51 2021
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Tue, 29 Jun 2021 01:54:51 GMT
Subject: [vectorIntrinsics+mask] RFR: 8269282: Add masking support for
 vector gather_load/scatter_store [v2]
In-Reply-To: 
References: 
Message-ID: 

> This patch adds the masking support for masked vector gather load and scatter store, including:
>   1) The Vector API java implementation and hotspot intrinsics changes:
>     - Add masking information to the `loadWithMap/storeWithMap` intrinsics.
>     - Both masked and non-masked gather_load/scatter_store call the same intrinsics. The mask value and class are set to `"null"` for non-masked operations.
>   2) The C2 compiler changes:
>     - Add two new IRs for the masked gather_load/scatter_store. The new masked IR will be generated for masked operation if the platform supports the predicate feature and the backend has implemented it.  Otherwise, the compiler will go back to the default java implementation.

Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:

  Fix MacOS x64 build failure issue

-------------

Changes:
  - all: https://git.openjdk.java.net/panama-vector/pull/95/files
  - new: https://git.openjdk.java.net/panama-vector/pull/95/files/c300783c..5ccb0c51

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=95&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=95&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/panama-vector/pull/95.diff
  Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/95/head:pull/95

PR: https://git.openjdk.java.net/panama-vector/pull/95

From xgong at openjdk.java.net  Tue Jun 29 02:27:53 2021
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Tue, 29 Jun 2021 02:27:53 GMT
Subject: [vectorIntrinsics+mask] RFR: 8269343: Masked vector arithmetic
 intrinsics failed to be inlined randomly
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 28 Jun 2021 18:54:56 GMT, Paul Sandoz  wrote:

> Looks good.
> 
Thanks for your review @PaulSandoz !

> I am wondering why its not needed on the vector arguments, is that because there is a cast to `{T}Vector` for vector arguments in templates is sufficient in those cases? Or does the `that.check(this);` help as well?
>
I think one reason is the vector class is transfered by calling `this.getClass()` when calling the intrinsic method. And  `that.check(this);` also helps since there is the vector class equalling check inside this method.

I also tried to get the mask class by calling `m.getClass()` like the vector class, but the compiler cannot guarantee the class is a constant which could also make the intrinsic fail to inline. As a reference to the existing `blend` API, it also explicitly set the mask class to the instance of the subclass which is sure to be a constant.

-------------

PR: https://git.openjdk.java.net/panama-vector/pull/96

From jbhateja at openjdk.java.net  Tue Jun 29 07:46:13 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Tue, 29 Jun 2021 07:46:13 GMT
Subject: [vectorIntrinsics+mask] RFR: 8269282: Add masking support for
 vector gather_load/scatter_store [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 29 Jun 2021 01:54:51 GMT, Xiaohong Gong  wrote:

>> This patch adds the masking support for masked vector gather load and scatter store, including:
>>   1) The Vector API java implementation and hotspot intrinsics changes:
>>     - Add masking information to the `loadWithMap/storeWithMap` intrinsics.
>>     - Both masked and non-masked gather_load/scatter_store call the same intrinsics. The mask value and class are set to `"null"` for non-masked operations.
>>   2) The C2 compiler changes:
>>     - Add two new IRs for the masked gather_load/scatter_store. The new masked IR will be generated for masked operation if the platform supports the predicate feature and the backend has implemented it.  Otherwise, the compiler will go back to the default java implementation.
>
> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix MacOS x64 build failure issue

Your changes looks good to me.

src/hotspot/share/opto/vectornode.hpp line 869:

> 867:    StoreVectorScatterMaskedNode(Node* c, Node* mem, Node* adr, const TypePtr* at, Node* val, Node* indices, Node* mask)
> 868:      : StoreVectorNode(c, mem, adr, at, val) {
> 869:      init_class_id(Class_StoreVector);

Same as above.

-------------

Marked as reviewed by jbhateja (Committer).

PR: https://git.openjdk.java.net/panama-vector/pull/95

From jbhateja at openjdk.java.net  Tue Jun 29 07:50:15 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Tue, 29 Jun 2021 07:50:15 GMT
Subject: [vectorIntrinsics+mask] RFR: 8269282: Add masking support for
 vector gather_load/scatter_store [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 29 Jun 2021 01:54:51 GMT, Xiaohong Gong  wrote:

>> This patch adds the masking support for masked vector gather load and scatter store, including:
>>   1) The Vector API java implementation and hotspot intrinsics changes:
>>     - Add masking information to the `loadWithMap/storeWithMap` intrinsics.
>>     - Both masked and non-masked gather_load/scatter_store call the same intrinsics. The mask value and class are set to `"null"` for non-masked operations.
>>   2) The C2 compiler changes:
>>     - Add two new IRs for the masked gather_load/scatter_store. The new masked IR will be generated for masked operation if the platform supports the predicate feature and the backend has implemented it.  Otherwise, the compiler will go back to the default java implementation.
>
> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix MacOS x64 build failure issue

src/hotspot/share/opto/vectornode.hpp line 849:

> 847:   LoadVectorGatherMaskedNode(Node* c, Node* mem, Node* adr, const TypePtr* at, const TypeVect* vt, Node* indices, Node* mask)
> 848:     : LoadVectorNode(c, mem, adr, at, vt) {
> 849:     init_class_id(Class_LoadVector);

class ID set at Class_LoadVector will prevent usage of [is/isa/as]_LoadVectorGatherMasked. it should be set as Class_LoadVectorGatherMasked with appropriate changes in node.hpp, but we can defer it for now till actual usages of such APIs are needed in code base.

-------------

PR: https://git.openjdk.java.net/panama-vector/pull/95

From xgong at openjdk.java.net  Tue Jun 29 08:44:16 2021
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Tue, 29 Jun 2021 08:44:16 GMT
Subject: [vectorIntrinsics+mask] RFR: 8269282: Add masking support for
 vector gather_load/scatter_store [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 28 Jun 2021 19:33:19 GMT, Paul Sandoz  wrote:

>> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix MacOS x64 build failure issue
>
> Java changes look good, but i cannot verify due to compilation errors (enabled warnings as errors), i think unrelated to this patch, can you fix at the same time?

@PaulSandoz , the build issue is fixed by the latest commit! Thanks for the review!

-------------

PR: https://git.openjdk.java.net/panama-vector/pull/95

From xgong at openjdk.java.net  Tue Jun 29 08:44:17 2021
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Tue, 29 Jun 2021 08:44:17 GMT
Subject: [vectorIntrinsics+mask] RFR: 8269282: Add masking support for
 vector gather_load/scatter_store [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 29 Jun 2021 07:47:06 GMT, Jatin Bhateja  wrote:

>> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix MacOS x64 build failure issue
>
> src/hotspot/share/opto/vectornode.hpp line 849:
> 
>> 847:   LoadVectorGatherMaskedNode(Node* c, Node* mem, Node* adr, const TypePtr* at, const TypeVect* vt, Node* indices, Node* mask)
>> 848:     : LoadVectorNode(c, mem, adr, at, vt) {
>> 849:     init_class_id(Class_LoadVector);
> 
> class ID set at Class_LoadVector will prevent usage of [is/isa/as]_LoadVectorGatherMasked. it should be set as Class_LoadVectorGatherMasked with appropriate changes in node.hpp, but we can defer it for now till actual usages of such APIs are needed in code base.

Yes, absolutely! I used `class_LoadVector` mainly because currently we doesn't need any usage of s/isa/as]_LoadVectorGatherMasked. This could be updated in future if needed! Thanks for you review @jatin-bhateja !

-------------

PR: https://git.openjdk.java.net/panama-vector/pull/95

From jbhateja at openjdk.java.net  Tue Jun 29 10:10:28 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Tue, 29 Jun 2021 10:10:28 GMT
Subject: [vectorIntrinsics+mask] RFR: 8266287: Basic mask IR
 implementation for the Vector API masking feature support [v4]
In-Reply-To: <9iQ2qYidA4YnP74ghLiik18CZ3xmkWUvGEeFUUxk7JU=.31418490-7bd6-49ed-873b-01c5f62e10ca@github.com>
References: 
 
 
 
 
 
 
 <8-pvCxVmC9fKfFFDOXuyFYvNRigJklNhyUhYrOsaHq0=.38973d62-9199-4881-ae4b-1eb3bfd9d2dd@github.com>
 <-72e7vhhu1yU2U9b6Ft2j7nwRFc6egbjxXRu3pJVees=.048de98a-0da1-4701-8964-868e88a2f715@github.com>
 <0sl3asXrMktJnN-KWK3FBrdfdzKajBSXxam8NS-W5Pc=.feebc515-d2b5-4b80-8998-382d0c3f188e@github.com>
 <9iQ2qYidA4YnP74ghLiik18CZ3xmkWUvGEe
 FUUxk7JU=.31418490-7bd6-49ed-873b-01c5f62e10ca@github.com>
Message-ID: 

On Thu, 24 Jun 2021 02:29:11 GMT, Xiaohong Gong  wrote:

>> Hi @XiaohongGong,
>> 
>> There could be a problem during scalarize_vbox_node if vector type of mask VectorBoxNode is made as TypeVectMask
>> https://github.com/jatin-bhateja/panama-vector/blob/628dc716b3f171e1b7b62fd1ec452a3d14a04af9/src/hotspot/share/opto/vector.cpp#L212
>> 
>> There is an ideal transformation which re-associates the Phi node having all its inputs as VectorBoxes of same type.
>> https://github.com/openjdk/panama-vector/blob/vectorIntrinsics%2Bmask/src/hotspot/share/opto/cfgnode.cpp#L2413
>> 
>> This can lead to a situation where PhiNode is created with TypeVect and inputs are of TypeVectMask, as a workaround I added another transformation which adjusts to bottom type of PhiNode to match with the bottom type of its inputs (TypeVectMask). This change is in my local repo having other masking changes.
>> https://github.com/jatin-bhateja/panama-vector/blob/JDK-8262356_vectorIntrinsics%2Bmask/src/hotspot/share/opto/cfgnode.cpp#L2433
>
>> There could be a problem during scalarize_vbox_node if vector type of mask VectorBoxNode is made as TypeVectMask
> https://github.com/jatin-bhateja/panama-vector/blob/628dc716b3f171e1b7b62fd1ec452a3d14a04af9/src/hotspot/share/opto/vector.cpp#L212
> 
> I think the main issues that I met are related to `VectorUnboxNode` while not `VectorBoxNode`.  BTW, the bottom type of `VectorBoxNode` is the box type while not the vector type. I'm sorry that I cannot see the influence whether the vector type is a `TypeVect` or `TypeVectMask` for it. Could you please kindly elaborate more about this? 
> 
> From my side, setting the `TypeVect` to `VectorBoxNode` might be ok, but how about the `VectorUnboxNode` ? I think they should keep the same with each other?

I agree with you on this. It seems that as long as both vector_type of VectorBoxNode and type of VectorUnboxNode comply it should not lead to any issue. 
May be one can directly pass the type of the vector being boxed instead of creating a new type during box creation.


diff --git a/src/hotspot/share/opto/vectorIntrinsics.cpp b/src/hotspot/share/opto/vectorIntrinsics.cpp
index 940e87b97ad..d1d0e6f5f24 100644
--- a/src/hotspot/share/opto/vectorIntrinsics.cpp
+++ b/src/hotspot/share/opto/vectorIntrinsics.cpp
@@ -73,8 +73,7 @@ Node* GraphKit::box_vector(Node* vector, const TypeInstPtr* vbox_type, BasicType
   Node* ret = gvn().transform(new ProjNode(alloc, TypeFunc::Parms));

   assert(check_vbox(vbox_type), "");
-  const TypeVect* vt = TypeVect::make(elem_bt, num_elem);
-  VectorBoxNode* vbox = new VectorBoxNode(C, ret, vector, vbox_type, vt);
+  VectorBoxNode* vbox = new VectorBoxNode(C, ret, vector, vbox_type, vector->bottom_type()->is_vect());
   return gvn().transform(vbox);
 }

-------------

PR: https://git.openjdk.java.net/panama-vector/pull/78

From psandoz at openjdk.java.net  Tue Jun 29 15:18:17 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Tue, 29 Jun 2021 15:18:17 GMT
Subject: [vectorIntrinsics+mask] RFR: 8269282: Add masking support for
 vector gather_load/scatter_store [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 28 Jun 2021 19:33:19 GMT, Paul Sandoz  wrote:

>> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix MacOS x64 build failure issue
>
> Java changes look good, but i cannot verify due to compilation errors (enabled warnings as errors), i think unrelated to this patch, can you fix at the same time?

> @PaulSandoz , the build issue is fixed by the latest commit! Thanks for the review!

Thanks, all good, compiled and ran load/store without failure.

-------------

PR: https://git.openjdk.java.net/panama-vector/pull/95

From xgong at openjdk.java.net  Wed Jun 30 00:52:25 2021
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Wed, 30 Jun 2021 00:52:25 GMT
Subject: [vectorIntrinsics+mask] Integrated: 8269343: Masked vector arithmetic
 intrinsics failed to be inlined randomly
In-Reply-To: 
References: 
Message-ID: 

On Fri, 25 Jun 2021 09:29:58 GMT, Xiaohong Gong  wrote:

> The masked `"lanewise/reduceLanes"` failed to be intrinsified randomly. The main reason is the hotspot c2 compiler cannot
> unbox the mask value due to the expected vector box type being mismatched with the class of the mask value. The vector box type is the` "mask class"` which is specified in Java level and saved in the intrinsic argument list. It is the class of the instance
> of the vector mask (i.e. `"IntMaxMask.class"`), while the type of mask value is the super class (i.e. `"jdk.incubator.vector.VectorMask"`).
> 
> Casting the mask value to the same subclass before calling the intrinsics can solve this issue.

This pull request has now been integrated.

Changeset: 14075353
Author:    Xiaohong Gong 
URL:       https://git.openjdk.java.net/panama-vector/commit/14075353a7ed48e9f2de2e0beb59d8731ddc1daf
Stats:     155 lines in 31 files changed: 0 ins; 0 del; 155 mod

8269343: Masked vector arithmetic intrinsics failed to be inlined randomly

Reviewed-by: psandoz

-------------

PR: https://git.openjdk.java.net/panama-vector/pull/96

From mike.ennen at gmail.com  Wed Jun 30 06:20:27 2021
From: mike.ennen at gmail.com (Michael Ennen)
Date: Tue, 29 Jun 2021 23:20:27 -0700
Subject: Replicating __mm256_shuffle_epi8 Intrinsic
Message-ID: 

 I am trying to implement SHA-256 using the new Java Vector API.

I have read the API docs but crossing the large mental gap of SIMD
instructions to the API for someone who knows very little SIMD has been
insurmountable for me.

My question has been asked on Stack Overflow:

https://stackoverflow.com/questions/68135596/replicating-mm256-shuffle-epi8-intrinsic-with-java-vector-api-shuffle

It is quite a simple (to ask anyway) question, which is, how to replicate
the _mm256_shuffle_epi8 intrinsic with the Java Vector API?

Thanks very much.

-- 
Michael Ennen

From jbhateja at openjdk.java.net  Wed Jun 30 10:36:26 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Wed, 30 Jun 2021 10:36:26 GMT
Subject: [vectorIntrinsics+mask] RFR: 8269282: Add masking support for
 vector gather_load/scatter_store [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 29 Jun 2021 08:42:15 GMT, Xiaohong Gong  wrote:

>> Java changes look good, but i cannot verify due to compilation errors (enabled warnings as errors), i think unrelated to this patch, can you fix at the same time?
>
> @PaulSandoz , the build issue is fixed by the latest commit! Thanks for the review!

Hi @XiaohongGong , If there is no more query/comment on this, can you kindly check-in this common IR change. Thanks!

-------------

PR: https://git.openjdk.java.net/panama-vector/pull/95

From jbhateja at openjdk.java.net  Wed Jun 30 16:54:25 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Wed, 30 Jun 2021 16:54:25 GMT
Subject: [vectorIntrinsics+mask] RFR: 8266287: Basic mask IR
 implementation for the Vector API masking feature support [v2]
In-Reply-To: 
References: 
 <0SyBueY0IDncXtoZ8Pc88k-C0-xuqf6_ITo5P_sF1q4=.cffb7d2f-8179-4eda-afb2-e55aa15c148d@github.com>
 
 
Message-ID: 

On Thu, 24 Jun 2021 06:11:07 GMT, Xiaohong Gong  wrote:

>> Hi there, the new commit refines the C2 compiler IRs for vector mask. The main idea is trying to use the same nodes but with
>> different types (i.e. use `"TypeVectMask"` for SVE/AVX-512, while `"TypeVect"` for others). It doesn't need to create new IRs specially for SVE/AVX-512 predicate type. The `"idea_reg"` is decided by the type of the node, so that the compiler can choose the right register for vector mask during codegen.
>> 
>> For more details, the following existed IRs are kept to use normally:
>> 
>>  - fromArray: LoadVector + VectorLoadMask
>>  - compare:   VectorMaskCmp
>>  - others:    VectorMaskCast
>> 
>> And to spearate the IRs for vector and vector mask, the following mask IRs are added:
>> 
>>  - maskAll:    MaskAll
>>  - and/or/xor: AndVMask/OrVMask/XorVMask
>> 
>> Further more, to improve the performance of vector mask loading/storing with SVE, the following transformations are also kept:
>> 
>>  - fromArray:
>>      LoadVector + VectorLoadMask    ==>  LoadVectorMask
>>  - intoArray:
>>      VectorStoreMask + StoreVector  ==>  StoreVectorMask
>> 
>> 
>> Any feedback is welcome! Thanks so much!
>> 
>> Best Regards,
>> Xiaohong
>
>> Hi @XiaohongGong , I just missed noticing this query earlier, apologies!, I think VectorLoadMask and VectorStoreMask serves the purpose to load/store a raw mask (boolean array) from/to a vector/predicated register. An explicit mask casting IR (VectorMaskCastNode) has been introduced recently which can be plugged after loading mask value if casting is needed.
> 
> It's ok. I think it's ok to use `VectorMaskCastNode` (actually we think this node is more reasonable instead of `VectorLoadMask/VectorStoreMask`). It needs a further consideration for it since we'd better to revisit its usage for all platforms while not only SVE.

Hi @XiaohongGong ,  I think there are still few opens like StoreVectorMask/LoadVectorMask which may be specific for ARM or creation of different nodes for logic mask operation (OrVMask/AndVMask/XorVMask) etc, since we are anyways working on a forked branch from vectorIntrinsics any further tuning can be done later and it will give us an opportunity to start the backend work using common IR.

Hi @PaulSandoz , @sviswa7 , what are your thougths.

-------------

PR: https://git.openjdk.java.net/panama-vector/pull/78

From sviswanathan at openjdk.java.net  Wed Jun 30 17:06:31 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Wed, 30 Jun 2021 17:06:31 GMT
Subject: [vectorIntrinsics+mask] RFR: 8266287: Basic mask IR
 implementation for the Vector API masking feature support [v2]
In-Reply-To: 
References: 
 <0SyBueY0IDncXtoZ8Pc88k-C0-xuqf6_ITo5P_sF1q4=.cffb7d2f-8179-4eda-afb2-e55aa15c148d@github.com>
 
 
Message-ID: 

On Thu, 24 Jun 2021 06:11:07 GMT, Xiaohong Gong  wrote:

>> Hi there, the new commit refines the C2 compiler IRs for vector mask. The main idea is trying to use the same nodes but with
>> different types (i.e. use `"TypeVectMask"` for SVE/AVX-512, while `"TypeVect"` for others). It doesn't need to create new IRs specially for SVE/AVX-512 predicate type. The `"idea_reg"` is decided by the type of the node, so that the compiler can choose the right register for vector mask during codegen.
>> 
>> For more details, the following existed IRs are kept to use normally:
>> 
>>  - fromArray: LoadVector + VectorLoadMask
>>  - compare:   VectorMaskCmp
>>  - others:    VectorMaskCast
>> 
>> And to spearate the IRs for vector and vector mask, the following mask IRs are added:
>> 
>>  - maskAll:    MaskAll
>>  - and/or/xor: AndVMask/OrVMask/XorVMask
>> 
>> Further more, to improve the performance of vector mask loading/storing with SVE, the following transformations are also kept:
>> 
>>  - fromArray:
>>      LoadVector + VectorLoadMask    ==>  LoadVectorMask
>>  - intoArray:
>>      VectorStoreMask + StoreVector  ==>  StoreVectorMask
>> 
>> 
>> Any feedback is welcome! Thanks so much!
>> 
>> Best Regards,
>> Xiaohong
>
>> Hi @XiaohongGong , I just missed noticing this query earlier, apologies!, I think VectorLoadMask and VectorStoreMask serves the purpose to load/store a raw mask (boolean array) from/to a vector/predicated register. An explicit mask casting IR (VectorMaskCastNode) has been introduced recently which can be plugged after loading mask value if casting is needed.
> 
> It's ok. I think it's ok to use `VectorMaskCastNode` (actually we think this node is more reasonable instead of `VectorLoadMask/VectorStoreMask`). It needs a further consideration for it since we'd better to revisit its usage for all platforms while not only SVE.

@XiaohongGong Please go ahead and integrate the code so we can proceed with the work.
It will be good to file JBS entries to revisit StoreVectorMask/LoadVectorMask and OrVMask/AndVMask/XorVMask creation.

-------------

PR: https://git.openjdk.java.net/panama-vector/pull/78

From psandoz at openjdk.java.net  Wed Jun 30 17:06:31 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Wed, 30 Jun 2021 17:06:31 GMT
Subject: [vectorIntrinsics+mask] RFR: 8266287: Basic mask IR
 implementation for the Vector API masking feature support [v2]
In-Reply-To: 
References: 
 <0SyBueY0IDncXtoZ8Pc88k-C0-xuqf6_ITo5P_sF1q4=.cffb7d2f-8179-4eda-afb2-e55aa15c148d@github.com>
 
 
 
Message-ID: 

On Wed, 30 Jun 2021 16:49:10 GMT, Jatin Bhateja  wrote:

>
> Hi @PaulSandoz , @sviswa7 , what are your thoughts.

It's ok if its not perfect (most importantly it has to build), if there is rough consensus via approval lets iterate on the branch and make incremental improvements.

-------------

PR: https://git.openjdk.java.net/panama-vector/pull/78