From eliu at openjdk.java.net Wed Sep 1 01:09:04 2021 From: eliu at openjdk.java.net (Eric Liu) Date: Wed, 1 Sep 2021 01:09:04 GMT Subject: [vectorIntrinsics+mask] RFR: 8273159: Remove LoadVectorMaskNode/StoreVectorMaskNode In-Reply-To: <9ELk1ezV6ccAGvsGlOd87FWLMT8RLkL7XJWXPwB1C_E=.9c5d050e-b287-45ae-8898-7d452c6d017f@github.com> References: <9ELk1ezV6ccAGvsGlOd87FWLMT8RLkL7XJWXPwB1C_E=.9c5d050e-b287-45ae-8898-7d452c6d017f@github.com> Message-ID: On Tue, 31 Aug 2021 07:42:08 GMT, Ningsheng Jian wrote: > Removed the nodes and related code. Try to generate the SVE ld1b/st1b extend/narrow instructions by matching specific rules. LGTM. ------------- Marked as reviewed by eliu (Committer). PR: https://git.openjdk.java.net/panama-vector/pull/116 From eliu at openjdk.java.net Wed Sep 1 01:32:25 2021 From: eliu at openjdk.java.net (Eric Liu) Date: Wed, 1 Sep 2021 01:32:25 GMT Subject: [vectorIntrinsics+mask] RFR: 8272745: VectorAPI: Vector/Mask type cleanup for masked vector intrinsics Message-ID: Some of the VectorAPIs were inconsistent with their intrinsic declarations, and some of the type arguments were not precise enough as well.?E.g.,?The return type of "unaryOp" should be a subtype of "Vector" instead of an?all-purpose "Object" [1][2]. The imprecise declarations and type arguments would not effect the correctness but bring bad readability and make the code hard to maintain. This patch is a cleanup for those mismatched declarations of VectorAPIs. [1] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics%2Bmask/src/java.base/share/classes/jdk/internal/vm/vector/VectorSupport.java#L269 [2] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics%2Bmask/src/hotspot/share/classfile/vmIntrinsics.hpp#L812 ------------- Commit messages: - 8272745: VectorAPI: Vector/Mask type cleanup for masked vector intrinsics Changes: https://git.openjdk.java.net/panama-vector/pull/117/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=117&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272745 Stats: 250 lines in 4 files changed: 89 ins; 12 del; 149 mod Patch: https://git.openjdk.java.net/panama-vector/pull/117.diff Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/117/head:pull/117 PR: https://git.openjdk.java.net/panama-vector/pull/117 From eliu at openjdk.java.net Wed Sep 1 01:54:10 2021 From: eliu at openjdk.java.net (Eric Liu) Date: Wed, 1 Sep 2021 01:54:10 GMT Subject: [vectorIntrinsics+mask] RFR: 8272869: AArch64: Mark masked rearrange operation as unsupported Message-ID: This patch marks masked rearrange operation as unsupported for AArch64, the reasons are as follows: 1. AArch64 dose not have predicated 'tbl' instruction 2. Mid-end has transformed masked VectorRearrange into VectorBlend[1] for those platforms which are missing corresponding instructions. Given by this, there's no need to add backend support for masked VectorRearrange, and the final generated code as below: tbl z16.s, {z20.s}, z16.s mov z17.s, #0 sel z16.s, p2, z16.s, z17.s [1] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics%2Bmask/src/hotspot/share/opto/vectorIntrinsics.cpp#L2016 ------------- Commit messages: - 8272869: AArch64: Mark masked rearrange operation as unsupported Changes: https://git.openjdk.java.net/panama-vector/pull/118/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=118&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272869 Stats: 16 lines in 2 files changed: 4 ins; 8 del; 4 mod Patch: https://git.openjdk.java.net/panama-vector/pull/118.diff Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/118/head:pull/118 PR: https://git.openjdk.java.net/panama-vector/pull/118 From njian at openjdk.java.net Wed Sep 1 04:10:08 2021 From: njian at openjdk.java.net (Ningsheng Jian) Date: Wed, 1 Sep 2021 04:10:08 GMT Subject: [vectorIntrinsics+mask] RFR: 8273159: Remove LoadVectorMaskNode/StoreVectorMaskNode In-Reply-To: References: <9ELk1ezV6ccAGvsGlOd87FWLMT8RLkL7XJWXPwB1C_E=.9c5d050e-b287-45ae-8898-7d452c6d017f@github.com> Message-ID: <98GeJ7ltCBxDY0feDx4xC7-cF4NI02oKGS8qYu7vgGY=.01888e03-0a8d-46ba-8839-e4ac534b1d6c@github.com> On Wed, 1 Sep 2021 01:06:11 GMT, Eric Liu wrote: >> Removed the nodes and related code. Try to generate the SVE ld1b/st1b extend/narrow instructions by matching specific rules. > > LGTM. Thank you @theRealELiu for the review! Hi @jatin-bhateja @sviswa7 , could you please help to take a look at shared code changes? ------------- PR: https://git.openjdk.java.net/panama-vector/pull/116 From njian at openjdk.java.net Wed Sep 1 04:10:56 2021 From: njian at openjdk.java.net (Ningsheng Jian) Date: Wed, 1 Sep 2021 04:10:56 GMT Subject: [vectorIntrinsics+mask] RFR: 8272869: AArch64: Mark masked rearrange operation as unsupported In-Reply-To: References: Message-ID: On Wed, 1 Sep 2021 01:47:53 GMT, Eric Liu wrote: > This patch marks masked rearrange operation as unsupported for AArch64, > the reasons are as follows: > > 1. AArch64 dose not have predicated 'tbl' instruction > 2. Mid-end has transformed masked VectorRearrange into VectorBlend[1] > for those platforms which are missing corresponding instructions. > > Given by this, there's no need to add backend support for masked > VectorRearrange, and the final generated code as below: > > > tbl z16.s, {z20.s}, z16.s > mov z17.s, #0 > sel z16.s, p2, z16.s, z17.s > > > [1] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics%2Bmask/src/hotspot/share/opto/vectorIntrinsics.cpp#L2016 Looks good. Thanks for the patch! ------------- Marked as reviewed by njian (Committer). PR: https://git.openjdk.java.net/panama-vector/pull/118 From eliu at openjdk.java.net Wed Sep 1 05:17:08 2021 From: eliu at openjdk.java.net (Eric Liu) Date: Wed, 1 Sep 2021 05:17:08 GMT Subject: [vectorIntrinsics+mask] RFR: 8272745: VectorAPI: Vector/Mask type cleanup for masked vector intrinsics In-Reply-To: References: Message-ID: On Wed, 1 Sep 2021 01:26:11 GMT, Eric Liu wrote: > Some of the VectorAPIs were inconsistent with their intrinsic > declarations, and some of the type arguments were not precise enough as > well.?E.g.,?The return type of "unaryOp" should be a subtype of "Vector" > instead of an?all-purpose "Object" [1][2]. > > The imprecise declarations and type arguments would not effect the > correctness but bring bad readability and make the code hard to > maintain. This patch is a cleanup for those mismatched declarations of > VectorAPIs. > > [1] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics%2Bmask/src/java.base/share/classes/jdk/internal/vm/vector/VectorSupport.java#L269 > [2] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics%2Bmask/src/hotspot/share/classfile/vmIntrinsics.hpp#L812 @PaulSandoz Could you help to review this patch? ------------- PR: https://git.openjdk.java.net/panama-vector/pull/117 From eliu at openjdk.java.net Wed Sep 1 09:08:06 2021 From: eliu at openjdk.java.net (Eric Liu) Date: Wed, 1 Sep 2021 09:08:06 GMT Subject: [vectorIntrinsics+mask] Integrated: 8272869: AArch64: Mark masked rearrange operation as unsupported In-Reply-To: References: Message-ID: On Wed, 1 Sep 2021 01:47:53 GMT, Eric Liu wrote: > This patch marks masked rearrange operation as unsupported for AArch64, > the reasons are as follows: > > 1. AArch64 dose not have predicated 'tbl' instruction > 2. Mid-end has transformed masked VectorRearrange into VectorBlend[1] > for those platforms which are missing corresponding instructions. > > Given by this, there's no need to add backend support for masked > VectorRearrange, and the final generated code as below: > > > tbl z16.s, {z20.s}, z16.s > mov z17.s, #0 > sel z16.s, p2, z16.s, z17.s > > > [1] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics%2Bmask/src/hotspot/share/opto/vectorIntrinsics.cpp#L2016 This pull request has now been integrated. Changeset: ef694cdc Author: Eric Liu URL: https://git.openjdk.java.net/panama-vector/commit/ef694cdcc36be03ef386244656993fdf59b25cda Stats: 16 lines in 2 files changed: 4 ins; 8 del; 4 mod 8272869: AArch64: Mark masked rearrange operation as unsupported Reviewed-by: njian ------------- PR: https://git.openjdk.java.net/panama-vector/pull/118 From jzhu at openjdk.java.net Wed Sep 1 11:55:05 2021 From: jzhu at openjdk.java.net (Joshua Zhu) Date: Wed, 1 Sep 2021 11:55:05 GMT Subject: [vectorIntrinsics+mask] RFR: 8273057: [vector] New VectorAPI "SelectiveStore" In-Reply-To: References: Message-ID: On Fri, 27 Aug 2021 09:47:10 GMT, Joshua Zhu wrote: > Hi, > > I want to propose a new VectorAPI "Selective Store/Load" and share my > implementation. Currently Alibaba's internal databases are in the > process of applying VectorAPI and they have requirements on "Selective > Store" for acceleration. > > My proposed VectorAPI is declared as below [1]: > > int selectiveIntoArray($type$[] a, int offset, VectorMask<$Boxtype$> m); > > The active elements (with their respective bit set in mask) are > contiguously stored into the array "a". Assume N is the true count of > mask, the elements starting from a[offset+N] till a[offset+laneCount] > are left unchanged. The return value represents the number of elements > store into the array and "offset + return value" is the new offset of > the next iteration. > ![image](https://user-images.githubusercontent.com/70769035/131108509-3dcb61f3-e8d0-4b4e-9b49-a72c077aaba6.png) > This API will be used like the following manner [2]: > > tld.conflict_cnt = 0; > for (int i = 0; i < ARRAY_LENGTH; i += INT_PREFERRED_SPECIES.length()) { > IntVector av = IntVector.fromArray(INT_PREFERRED_SPECIES, tld.int_input1, i); > IntVector bv = IntVector.fromArray(INT_PREFERRED_SPECIES, tld.int_input2, i); > IntVector cv = IntVector.fromArray(INT_PREFERRED_SPECIES, tld.int_index, i); > VectorMask mask = av.compare(VectorOperators.NE, bv); > tld.conflict_cnt += cv.selectiveIntoArray(tld.conflict_array, tld.conflict_cnt, mask); > } > > My patch includes the following changes: >   * Selective Store VectorAPI for Long & Int >   * Assembler: add x86 instruction "VPCOMPRESSD" and "VPCOMPRESSQ" >   * Instruction selection: vselective_store; kmask_truecount (true count of kregister) >   * Add node "StoreVectorSelective" >   * Add a new parameter "is_selective" in inline_vector_mem_masked_operation() >     in order to distinguish Masked version or Selective version >   * jtreg cases >   * JMH benchmark > > TODO parts I will implement: >   * Selective Store for other types >   * Selective Load >   * Some potential optimization. Such as: when mask is allTrue, SelectiveIntoArray() -> IntoArray() > > Test: >   * Passed VectorAPI jtreg cases. >   * Result of JMH benchmark to evaluate API's performance in Alibaba's real scenario. >       UseAVX=3; thread number = 8; conflict data percentage: 20% (that means 20% of mask bits are true) >       http://cr.openjdk.java.net/~jzhu/8273057/jmh_benchmark_result.pdf > > [1] https://github.com/JoshuaZhuwj/panama-vector/commit/69623f7d6a1eae532576359328b96162d8e16837#diff-13cc2d6ec18e487ddae05cda671bdb6bb7ffd42ff7bc51a2e00c8c5e622bd55dR4667 > [2] https://github.com/JoshuaZhuwj/panama-vector/commit/69623f7d6a1eae532576359328b96162d8e16837#diff-951d02bd72a931ac34bc85d1d4e656a14f8943e143fc9282b36b9c76c1893c0cR144 > [3] failed to inline (intrinsic) by https://github.com/openjdk/panama-vector/blob/60aa8ca6dc0b3f1a3ee517db167f9660012858cd/src/hotspot/cpu/x86/x86.ad#L1769 > > Best Regards, > Joshua Thank Paul, John Rose and Ningsheng for your comments. A vector-to-vector compress operation is the more friendly primitive. Both Intel AVX3 instruction "COMPRESS" and Arm SVE instruction "COMPACT" provide the capability. Hence selective store could be implemented by VectorMask mask = ...; IntVector bv = av.compress(mask); VectorMask prefixMask = prefix(mask.trueCount()); bv.intoArray(array, offset, prefixMask); offset += mask.trueCount(); The vector-to-vector compress primitive together with a store and prefix mask could be optimized further into memory destination version of compress on supported architecture. Once architectures do not support vector-to-vector compress natively, the intrinsic bailed out and then java path is taken. Java path could be composed by "mask -> shuffle -> rearrange" and C2 will then try to inline intrinsics again for these API calls. In this way, we are also able to implement scatter/gather store/load in the same composition manner to keep design consistency. Best Regards, Joshua ------------- PR: https://git.openjdk.java.net/panama-vector/pull/115 From vladimir.x.ivanov at oracle.com Wed Sep 1 13:22:15 2021 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 1 Sep 2021 16:22:15 +0300 Subject: [External] : Re: Issues with loop unrolling: better pinned node In-Reply-To: References: <9F21B2BF-E94F-4332-A5A4-DEDA05D1802C@oracle.com> <19C617EE-6745-4DA3-A5AE-674E92F7DAA4@oracle.com> <14e30959-d990-2180-f23d-a05c88ec7899@smogura.eu> Message-ID: <3f7dd833-f632-9b3d-0713-37e78f5de928@oracle.com> Interesting idea, Rado! Representing memory effects of mixed/mismatched accesses with TypePtr::BOTTOM does look promising. Regarding the preferred IR shapes, I'd try to teach alias analysis (Compile::find_alias_type()) and PhaseCFG::insert_anti_dependences() about loads/stores on wide memory (TypePtr::BOTTOM) and see what kind of problems arise to decide how to proceed. I hope there's a way to avoid dummy nodes when representing desired effects. Best regards, Vladimir Ivanov On 30.08.2021 18:12, Rado Smogura wrote: > Hi all, > > > I added one missing thing. I want to build something like this. Would it > make sense? > > > ?? STORE > > > ?????????????????????????????? addr > ???????????????????????????????? ? > ???????????????????????????????? ? > ???????? reset_memory()????????? ? > ??????????? ???? ?????????????????????????? > ??????????? ???? ? CheckCastPP (-> BOT)?? ? > ??????????? ???? ?????????????????????????? > ??????????? ??????????? ? > ??????????? ??????????? ? > ??????????? ??????? ??? ? > ??????????? ??????? ??? ? > ??????????? ?? ????????????????????????????????????? > ??????????? ?? ???????????? StoreVector??????????? ? > ??????????? ?? ????????????????????????????????????? > ??????????? ?????? ??????????????????????????? ? > ??????????? ?????? ??????????????????????????? ? > ?????????????????????????????????????????????????????????????????? > ?????????? ? BOT? RAW byte[]????????????????????????? ? > ?????????? ? MergeMem??????????????????????????????????????? ? > ?????????????????????????????????????????????????????????????????? > > > > ??? LOAD > > ???????????? ? > ???????????? ? > ???????????? ??????????? > ???????????? ????????? ? > ???????????? ? > ??????????????????????????????????????????????????????????????? > ???????????? ? ? LoadVector > (BOT)??????????????????????????????????????????? ? > ???????????? ? > ??????????????????????????????????????????????????????????????? > ???????????? ????????????????????????? ? ? > ???????????? ????? addr base -> raw ????????????????????????? ???? addr > base -> byte[] > ???????????? ????????????????????????? ? ? > ???????????? ??????????? ????????????????????????? > ????????????????????????? > ???????????? ??????????? ?DummyStoreV (raw)????? ? ?DummyStoreV > (byte[])?? ? //No-op stores > ???????????? ??????????? ????????????????????????? > ????????????????????????? > ???????????? ?????????????????? ??????????????????????? ? > ???????????? ????? ?????????????????????????? ??????????? > ???????????? ????? ?????????????????????????? ? > ??????????????????????????????????????????????????????????????????? > ?????????? ? BOT? RAW byte[]?????????????????????????? ? > ?????????? ? MergeMem???????????????????????????????????????? ? > ??????????????????????????????????????????????????????????????????? > > > DummyStore is "virtual" node inserted after load, intended to emulate > store, and prevent writes / reads to go on the side of load vector (it > fact it more prevents store / load to see through mem-memrge). > > I did test it with following code. > > public static void copyMemoryBytes3(ByteBuffer in, ByteBuffer out, > ByteBuffer out2,byte[] arr) { > ??? for (int i=0; i +=SPECIES_BYTE.vectorByteSize()) { > ??????? var v1 = ByteVector.fromByteBuffer(SPECIES_BYTE, in, i, > ByteOrder.nativeOrder()); > ??????? arr[i] = (byte) i; > ??????? var v2 = ByteVector.fromByteBuffer(SPECIES_BYTE, out, i, > ByteOrder.nativeOrder()); > ??????? v1.intoByteBuffer(out, i, ByteOrder.nativeOrder()); > ??? } > } > > Kind regards, > > Rado > > On 27.08.2021 20:16, Rado Smogura wrote: >> Hi all, >> >> >> I experimented a little bit, and I wonder if this is reasonable, the >> outcome on graphs is as expected, and operations looks like properly >> ordered (but this is my private opinion). >> >> https://urldefense.com/v3/__https://github.com/rsmogura/panama-vector/commit/755b62823aaed0cddf78e8ccfc60c063bb40779a__;!!ACWV5N9M2RV99hQ!ceve5Eoh01VSiAxgPOSMpL_oQpz6MJI6KeGEcvULButhjMZGdxMq2SB02arX5hxVvmWp1wY$ >> >> >> Kind regards, >> >> Rado >> >> On 19.08.2021 22:26, Rado Smogura wrote: >>> I think I answered this question quite simply... it will not work. >>> >>> On 19.08.2021 18:39, Rado Smogura wrote: >>>> Hi all, >>>> >>>> >>>> I hope you have a good day. >>>> >>>> >>>> As still optimizing loops would be good approach, I thought about >>>> optimizing a mixed access with this approach: >>>> >>>> >>>> 1. When mixed access is detected set flag "raw / byte array" mixed >>>> access. >>>> >>>> 2. Bail out and restart compilation (will happen during first >>>> phases, and only for few methods). >>>> >>>> 3. Pass a flag to compiler. >>>> >>>> 4. Modify find_alias_type / flatten_alias_type, so that if byte >>>> array will be queried for alias, raw ptr and raw alias will be used. >>>> >>>> >>>> Kind regards, >>>> >>>> Rado >>>> >>>> On 18.08.2021 09:17, Rado Smogura wrote: >>>>> Hi Vladimir, >>>>> >>>>> >>>>> Thank you for answer. >>>>> >>>>> >>>>> In fact, it is was an attempt to confirm that memory flow can be a >>>>> cause why loop opts do not work. That's very fair point. I'll think >>>>> about it and maybe I'll be able to come out idea how this can be >>>>> generalized. >>>>> >>>>> >>>>> Kind regards, >>>>> >>>>> Rado >>>>> >>>>> On 16.08.2021 15:41, Vladimir Ivanov wrote: >>>>>>> I wonder what do you think about something like this [1] - it's >>>>>>> virtually small single class change >>>>>> >>>>>> Very interesting experiment, Rado! It's encouraging to hear that >>>>>> loop opts immediately benefit from it. >>>>>> >>>>>> From a architectural perspective, a separate pass to optimize >>>>>> memory graph brings excessive complexity: >>>>>> >>>>>> ? (1) yet another pass over the graph and susceptible to pass >>>>>> ordering issues; >>>>>> >>>>>> ? (2) separate from GVN: you either have to duplicate GVN-based >>>>>> memory optimizations or run new pass with IGVN in a loop until it >>>>>> stabilizes. >>>>>> >>>>>> IMO the problem you noticed illustrates a general weakness in GVN >>>>>> implementation and that's the place where it should be fixed >>>>>> (ideally). >>>>>> >>>>>> Best regards, >>>>>> Vladimir Ivanov >>>>>> >>>>>>> >>>>>>> This change tries to find unique memory for load node. I >>>>>>> implemented it as separate phase, as optimization may not run in >>>>>>> Ideal method. I think it's ligher than phi split out. >>>>>>> >>>>>>> Loops has been transformed. RCE started. >>>>>>> >>>>>>> Kind regards, >>>>>>> Rado >>>>>>> >>>>>>> [1] - >>>>>>> https://urldefense.com/v3/__https://github.com/rsmogura/panama-vector/commit/a44f515890d2c4df3fd0e0ced76545a7664926c3__;!!ACWV5N9M2RV99hQ!ceve5Eoh01VSiAxgPOSMpL_oQpz6MJI6KeGEcvULButhjMZGdxMq2SB02arX5hxVLT5AsEE$ >>>>>>> >>>>>>> >>>>>>> [2] - >>>>>>> https://urldefense.com/v3/__https://github.com/rsmogura/panama-vector/tree/housekeeping-load-memory-optimiziation__;!!ACWV5N9M2RV99hQ!ceve5Eoh01VSiAxgPOSMpL_oQpz6MJI6KeGEcvULButhjMZGdxMq2SB02arX5hxVcBkmVi0$ >>>>>>> >>>>>>> (full test case) >>>>>>> >>>>>>> ------------------------------------------------------------------------ >>>>>>> >>>>>>> *From:* Rados?aw Smogura on behalf of Rados?aw Smogura >>>>>>> >>>>>>> *Sent:* Friday, August 6, 2021 22:43 >>>>>>> *To:* Rados?aw Smogura ; Paul Sandoz >>>>>>> ; Vladimir Ivanov >>>>>>> >>>>>>> *Cc:* panama-dev at openjdk.java.net >>>>>>> *Subject:* Re: Issues with loop unrolling: better pinned node >>>>>>> Hi all, >>>>>>> >>>>>>> Now when I checked it again. it works as expected, and it's the >>>>>>> same code. >>>>>>> >>>>>>> In draft code I check if the buffer is direct by using type >>>>>>> checking to unswitch loop, as unswitching over ByteBuffer.hb did >>>>>>> not work (the graph was quite similar). However, I thought that >>>>>>> this unswitch actually helped to build correct loops, and any >>>>>>> kind of improvement around it would be rather for the purpose of >>>>>>> better-looking code. >>>>>>> >>>>>>> But it looks like that sometimes (but only sometimes) loop still >>>>>>> can not be correctly built, or maybe the full optimization kicks >>>>>>> in very, very late. >>>>>>> >>>>>>> Kind regards, >>>>>>> Rado >>>>>>> ------------------------------------------------------------------------ >>>>>>> >>>>>>> *From:* panama-dev on behalf >>>>>>> of Rados?aw Smogura >>>>>>> *Sent:* Friday, August 6, 2021 20:22 >>>>>>> *To:* Paul Sandoz >>>>>>> *Cc:* panama-dev at openjdk.java.net >>>>>>> *Subject:* Re: Issues with loop unrolling: better pinned node >>>>>>> Yes, >>>>>>> >>>>>>> The normal case looks, good. It's all about polluted cases [1] >>>>>>> >>>>>>> BR, >>>>>>> Rado >>>>>>> >>>>>>> [1] >>>>>>> https://urldefense.com/v3/__https://github.com/openjdk/panama-vector/pull/109__;!!ACWV5N9M2RV99hQ!ceve5Eoh01VSiAxgPOSMpL_oQpz6MJI6KeGEcvULButhjMZGdxMq2SB02arX5hxVfxQRu38$ >>>>>>> >>>>>>> >>>>>>> [https://urldefense.com/v3/__https://opengraph.githubassets.com/daf8e3b93dd4c25e04d1ce6ae2a91e1b725625bfd85b5027c61fb78ae3a6a361/openjdk/panama-vector/pull/109__;!!ACWV5N9M2RV99hQ!ceve5Eoh01VSiAxgPOSMpL_oQpz6MJI6KeGEcvULButhjMZGdxMq2SB02arX5hxVmHZKrgY$ >>>>>>> ]>>>>>> > >>>>>>> >>>>>>> (Draft) Perofrmance improvements for polluted cases by rsmogura ? >>>>>>> Pull Request #109 ? >>>>>>> openjdk/panama-vector>>>>>> > >>>>>>> >>>>>>> >>>>>>> Hi all, I would like to submit this piece of work, for byte >>>>>>> buffers and polluted cases. It resolves some performance issues >>>>>>> related to mem barriers when in scope are both on- and off-heap >>>>>>> buffer. T... >>>>>>> github.com >>>>>>> >>>>>>> [https://urldefense.com/v3/__https://opengraph.githubassets.com/5fde12f89c012a2abef1542ed59c7272429fa7556f6e82a5e617a293d3a5bee1/openjdk/panama-vector__;!!ACWV5N9M2RV99hQ!ceve5Eoh01VSiAxgPOSMpL_oQpz6MJI6KeGEcvULButhjMZGdxMq2SB02arX5hxVLW0LAx0$ >>>>>>> ]>>>>>> > >>>>>>> >>>>>>> Comparing >>>>>>> openjdk:vectorIntrinsics...rsmogura:vectors-polluted-cases ? >>>>>>> openjdk/panama-vector>>>>>> > >>>>>>> >>>>>>> >>>>>>> Panama vector. Contribute to openjdk/panama-vector development by >>>>>>> creating an account on GitHub. >>>>>>> github.com >>>>>>> >>>>>>> ________________________________ >>>>>>> From: Paul Sandoz >>>>>>> Sent: Friday, August 6, 2021 20:04 >>>>>>> To: Rados?aw Smogura >>>>>>> Cc: panama-dev at openjdk.java.net >>>>>>> Subject: Re: Issues with loop unrolling: better pinned node >>>>>>> >>>>>>> I am confused as to the case under test. In your initial email of >>>>>>> this thread were you also referring implicitly to polluted cases? >>>>>>> >>>>>>> Paul. >>>>>>> >>>>>>>> On Aug 6, 2021, at 10:56 AM, Rados?aw Smogura >>>>>>>> wrote: >>>>>>>> >>>>>>>> Hi Paul, >>>>>>>> >>>>>>>> There's a performance improvement, but. I still can't unroll >>>>>>>> polluted cases (I cherry-picked loop unrolling). The graph still >>>>>>>> has few nodes taking buffer limit from phi, and on IR I don't >>>>>>>> see vectors nodes cascading. >>>>>>>> >>>>>>>> make test TEST='micro:ByteBufferVectorAccess.p' >>>>>>>> MICRO="OPTIONS=-f 1 -prof perfasm >>>>>>>> -jvmArgsPrepend=-Djdk.incubator.vector.VECTOR_ACCESS_OOB_CHECK=0" JOBS=12 >>>>>>>> >>>>>>>> Benchmark???????????????????????????????????? (size) Mode Cnt >>>>>>>> Score?? Error? Units >>>>>>>> ByteBufferVectorAccess.pollutedBuffers2???????? 1024 avgt 30 >>>>>>>> 40.472 ? 1.055? ns/op >>>>>>>> ByteBufferVectorAccess.pollutedBuffers2:?asm??? 1024 >>>>>>>> avgt????????? NaN??????????? --- >>>>>>>> ByteBufferVectorAccess.pollutedBuffers3???????? 1024 avgt 30 >>>>>>>> 79.251 ? 0.786? ns/op >>>>>>>> ByteBufferVectorAccess.pollutedBuffers3:?asm??? 1024 >>>>>>>> avgt????????? NaN??????????? --- >>>>>>>> ByteBufferVectorAccess.pollutedBuffers4???????? 1024 avgt 30 >>>>>>>> 83.627 ? 2.140? ns/op >>>>>>>> ByteBufferVectorAccess.pollutedBuffers4:?asm??? 1024 >>>>>>>> avgt????????? NaN??????????? --- >>>>>>>> ByteBufferVectorAccess.pollutedBuffers5???????? 1024 avgt 30 >>>>>>>> 85.561 ? 1.156? ns/op >>>>>>>> ByteBufferVectorAccess.pollutedBuffers5:?asm??? 1024 >>>>>>>> avgt????????? NaN >>>>>>>> >>>>>>>> make test TEST='micro:ByteBufferVectorAccess.p' >>>>>>>> MICRO="OPTIONS=-f 1 -prof perfasm" >>>>>>>> Benchmark???????????????????????????????????? (size) Mode Cnt >>>>>>>> Score?? Error? Units >>>>>>>> ByteBufferVectorAccess.pollutedBuffers2???????? 1024 avgt 10 >>>>>>>> 49.326 ? 0.843? ns/op >>>>>>>> ByteBufferVectorAccess.pollutedBuffers2:?asm??? 1024 >>>>>>>> avgt?????????? NaN??????????? --- >>>>>>>> ByteBufferVectorAccess.pollutedBuffers3???????? 1024 avgt 10 >>>>>>>> 100.291 ? 1.271? ns/op >>>>>>>> ByteBufferVectorAccess.pollutedBuffers3:?asm??? 1024 >>>>>>>> avgt?????????? NaN??????????? --- >>>>>>>> ByteBufferVectorAccess.pollutedBuffers4???????? 1024 avgt 10 >>>>>>>> 101.494 ? 1.027? ns/op >>>>>>>> ByteBufferVectorAccess.pollutedBuffers4:?asm??? 1024 >>>>>>>> avgt?????????? NaN??????????? --- >>>>>>>> ByteBufferVectorAccess.pollutedBuffers5???????? 1024 avgt 10 >>>>>>>> 94.606 ? 1.522? ns/op >>>>>>>> ByteBufferVectorAccess.pollutedBuffers5:?asm??? 1024 >>>>>>>> avgt?????????? NaN >>>>>>>> >>>>>>>> >>>>>>>> BR, >>>>>>>> Rado >>>>>>>> From: Paul Sandoz >>>>>>>> Sent: Friday, August 6, 2021 18:04 >>>>>>>> To: Rados?aw Smogura >>>>>>>> Cc: panama-dev at openjdk.java.net >>>>>>>> Subject: Re: Issues with loop unrolling: better pinned node >>>>>>>> >>>>>>>> Hi Rado, >>>>>>>> >>>>>>>> It?s good you are looking at the IR >>>>>>>> >>>>>>>> Out of curiosity, what happens if you turn off bounds checking [*]? >>>>>>>> >>>>>>>> Paul. >>>>>>>> >>>>>>>> [*] >>>>>>>> -Djdk.incubator.vector.VECTOR_ACCESS_OOB_CHECK=0 >>>>>>>> >>>>>>>> > On Aug 6, 2021, at 8:39 AM, Rados?aw Smogura >>>>>>>> wrote: >>>>>>>> > >>>>>>>> > Hi all, >>>>>>>> > >>>>>>>> > I've found that even if we get rid of barriers, the loop can't >>>>>>>> get unrolled, and not needed code is inside it. >>>>>>>> > >>>>>>>> > I've found this graph, I wonder if it's most optimal, in a >>>>>>>> partiucalry Load of ByteBuffer index / hb is from phi, could it >>>>>>>> be attached to initial memory? >>>>>>>> > >>>>>>>> > Here's a picture >>>>>>>> https://urldefense.com/v3/__https://drive.google.com/file/d/1G7ZN0xHOVIVHmZ_5TTIUdm3F30okAzvO/view?usp=sharing__;!!ACWV5N9M2RV99hQ!ceve5Eoh01VSiAxgPOSMpL_oQpz6MJI6KeGEcvULButhjMZGdxMq2SB02arX5hxVkhhZ0w8$ >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> > >>>>>>>> [https://urldefense.com/v3/__https://lh6.googleusercontent.com/SKgGZgfVWFpG8w4mWqguLSU4DVfa1MKYPSQhxv8EoX04XzVz8U8Kc4zHP0iwdR26Suc=w1200-h630-p__;!!ACWV5N9M2RV99hQ!ceve5Eoh01VSiAxgPOSMpL_oQpz6MJI6KeGEcvULButhjMZGdxMq2SB02arX5hxVgkskdP0$ >>>>>>>> ]>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> > >>>>>>> >>>>>>>> > >>>>>>>> bb_issues.png>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> > >>>>>>> >>>>>>>> > drive.google.com >>>>>>>> > >>>>>>>> > >>>>>>>> > And sample code >>>>>>>> > >>>>>>>> > protected void copyMemory(ByteBuffer in, ByteBuffer out) { >>>>>>>> >? var limit = SPECIES.loopBound(in.limit()); >>>>>>>> >? for (int i=0; i < limit; i += SPECIES.vectorByteSize()) { >>>>>>>> >??? final var v = ByteVector.fromByteBuffer(SPECIES, in, i, >>>>>>>> ByteOrder.nativeOrder()); >>>>>>>> >??? v.intoByteBuffer(out, i, ByteOrder.nativeOrder()); >>>>>>>> >? } >>>>>>>> > } >>>>>>>> > >>>>>>>> > Kind regards, >>>>>>>> > Rado >>>>>>> From sviswanathan at openjdk.java.net Wed Sep 1 17:10:15 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Wed, 1 Sep 2021 17:10:15 GMT Subject: [vectorIntrinsics+mask] RFR: 8273159: Remove LoadVectorMaskNode/StoreVectorMaskNode In-Reply-To: <9ELk1ezV6ccAGvsGlOd87FWLMT8RLkL7XJWXPwB1C_E=.9c5d050e-b287-45ae-8898-7d452c6d017f@github.com> References: <9ELk1ezV6ccAGvsGlOd87FWLMT8RLkL7XJWXPwB1C_E=.9c5d050e-b287-45ae-8898-7d452c6d017f@github.com> Message-ID: On Tue, 31 Aug 2021 07:42:08 GMT, Ningsheng Jian wrote: > Removed the nodes and related code. Try to generate the SVE ld1b/st1b extend/narrow instructions by matching specific rules. Shared code changes look good to me. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/116 From psandoz at openjdk.java.net Wed Sep 1 22:14:47 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Wed, 1 Sep 2021 22:14:47 GMT Subject: [vectorIntrinsics+mask] RFR: 8272745: VectorAPI: Vector/Mask type cleanup for masked vector intrinsics In-Reply-To: References: Message-ID: On Wed, 1 Sep 2021 01:26:11 GMT, Eric Liu wrote: > Some of the VectorAPIs were inconsistent with their intrinsic > declarations, and some of the type arguments were not precise enough as > well.?E.g.,?The return type of "unaryOp" should be a subtype of "Vector" > instead of an?all-purpose "Object" [1][2]. > > The imprecise declarations and type arguments would not effect the > correctness but bring bad readability and make the code hard to > maintain. This patch is a cleanup for those mismatched declarations of > VectorAPIs. > > [1] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics%2Bmask/src/java.base/share/classes/jdk/internal/vm/vector/VectorSupport.java#L269 > [2] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics%2Bmask/src/hotspot/share/classfile/vmIntrinsics.hpp#L812 That's a good start. As I looked more deeply i figured it was worth doing a more thorough cleanup for readability and maintainability. So I did some changes on top of your PR, see the following patch which should apply cleanly to your PR: https://gist.github.com/PaulSandoz/329e0e61b6d0ed5f4d6b5ddc03fa9105 (Sorry i did not clone your branch and issue a PR to that, let me know if that is more preferable.) ------------- PR: https://git.openjdk.java.net/panama-vector/pull/117 From njian at openjdk.java.net Thu Sep 2 01:26:49 2021 From: njian at openjdk.java.net (Ningsheng Jian) Date: Thu, 2 Sep 2021 01:26:49 GMT Subject: [vectorIntrinsics+mask] Integrated: 8273159: Remove LoadVectorMaskNode/StoreVectorMaskNode In-Reply-To: <9ELk1ezV6ccAGvsGlOd87FWLMT8RLkL7XJWXPwB1C_E=.9c5d050e-b287-45ae-8898-7d452c6d017f@github.com> References: <9ELk1ezV6ccAGvsGlOd87FWLMT8RLkL7XJWXPwB1C_E=.9c5d050e-b287-45ae-8898-7d452c6d017f@github.com> Message-ID: On Tue, 31 Aug 2021 07:42:08 GMT, Ningsheng Jian wrote: > Removed the nodes and related code. Try to generate the SVE ld1b/st1b extend/narrow instructions by matching specific rules. This pull request has now been integrated. Changeset: 5aa3a72c Author: Ningsheng Jian URL: https://git.openjdk.java.net/panama-vector/commit/5aa3a72ceb8f65b4643b8dca6024d7779fee381a Stats: 308 lines in 12 files changed: 29 ins; 227 del; 52 mod 8273159: Remove LoadVectorMaskNode/StoreVectorMaskNode Co-authored-by: Xiaohong Gong Co-authored-by: Ningsheng Jian Reviewed-by: eliu, sviswanathan ------------- PR: https://git.openjdk.java.net/panama-vector/pull/116 From njian at openjdk.java.net Thu Sep 2 01:26:48 2021 From: njian at openjdk.java.net (Ningsheng Jian) Date: Thu, 2 Sep 2021 01:26:48 GMT Subject: [vectorIntrinsics+mask] RFR: 8273159: Remove LoadVectorMaskNode/StoreVectorMaskNode In-Reply-To: References: <9ELk1ezV6ccAGvsGlOd87FWLMT8RLkL7XJWXPwB1C_E=.9c5d050e-b287-45ae-8898-7d452c6d017f@github.com> Message-ID: On Wed, 1 Sep 2021 17:06:45 GMT, Sandhya Viswanathan wrote: >> Removed the nodes and related code. Try to generate the SVE ld1b/st1b extend/narrow instructions by matching specific rules. > > Shared code changes look good to me. Thank you @sviswa7! ------------- PR: https://git.openjdk.java.net/panama-vector/pull/116 From mike.ennen at gmail.com Thu Sep 2 05:35:12 2021 From: mike.ennen at gmail.com (Michael Ennen) Date: Wed, 1 Sep 2021 22:35:12 -0700 Subject: How To Create Array of Structs? Message-ID: I have been doing more exploring with the panama-foreign, ffi, and jextract branches - this time messing around with seeing if I can get a rainbow triangle to be rendered on the screen with Vulkan. I am really close. There is one problem I am having which is how to create an array of structs? See this, for example: https://github.com/brcolow/java-vulkan/blob/master/src/main/java/com/brcolow/game/Vulkan.java#L581 If I set the stageCount to 2, then I get a validation exception about the second shader module having bogus values. I believe this is caused by me creating the array of structs incorrectly. I am trying to set the pStages element of this struct: https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VkGraphicsPipelineCreateInfo.html to an array containing pVertShaderStageInfo and pFragShaderStageInfo. My attempt (I have tried other ways that also fail) to do that is: MemorySegment pStages = SegmentAllocator.ofScope(scope).allocateArray( C_POINTER, new Addressable[]{ pVertShaderStageInfo, pFragShaderStageInfo}); VkGraphicsPipelineCreateInfo.pStages$set(pPipelineCreateInfo, MemoryAccess.getAddress(pStages)); If anyone could assist me with the proper way to create the VkPipelineShaderStageCreateInfo* array containing pVertShaderStageInfoand pFragShaderStageInfo - it would be greatly appreciated! -- Michael Ennen From eliu at openjdk.java.net Thu Sep 2 09:55:16 2021 From: eliu at openjdk.java.net (Eric Liu) Date: Thu, 2 Sep 2021 09:55:16 GMT Subject: [vectorIntrinsics+mask] RFR: 8272745: VectorAPI: Vector/Mask type cleanup for masked vector intrinsics [v2] In-Reply-To: References: Message-ID: > Some of the VectorAPIs were inconsistent with their intrinsic > declarations, and some of the type arguments were not precise enough as > well.?E.g.,?The return type of "unaryOp" should be a subtype of "Vector" > instead of an?all-purpose "Object" [1][2]. > > The imprecise declarations and type arguments would not effect the > correctness but bring bad readability and make the code hard to > maintain. This patch is a cleanup for those mismatched declarations of > VectorAPIs. > > [1] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics%2Bmask/src/java.base/share/classes/jdk/internal/vm/vector/VectorSupport.java#L269 > [2] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics%2Bmask/src/hotspot/share/classfile/vmIntrinsics.hpp#L812 Eric Liu has updated the pull request incrementally with one additional commit since the last revision: more thorough cleanup Change-Id: I22387cb5ae843cbf61104c3e01003d8e89b311a2 ------------- Changes: - all: https://git.openjdk.java.net/panama-vector/pull/117/files - new: https://git.openjdk.java.net/panama-vector/pull/117/files/7e0b0e51..82f323a8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=117&range=01 - incr: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=117&range=00-01 Stats: 400 lines in 3 files changed: 208 ins; 13 del; 179 mod Patch: https://git.openjdk.java.net/panama-vector/pull/117.diff Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/117/head:pull/117 PR: https://git.openjdk.java.net/panama-vector/pull/117 From maurizio.cimadamore at oracle.com Thu Sep 2 09:56:19 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 2 Sep 2021 10:56:19 +0100 Subject: How To Create Array of Structs? In-Reply-To: References: Message-ID: <0c6361f3-2879-02dd-0b26-e26a5b268602@oracle.com> Hi Michael, very interesting experiments - thanks for reaching out. Eyeballing your code, I zoomed into this line: https://github.com/brcolow/java-vulkan/blob/master/src/main/java/com/brcolow/game/Vulkan.java#L593 Here you want to set the `pStages` pointer, a pointer to a memory region which presumably has to contain exactly `stageCount` structs of type `VkPipelineShaderStageCreateInfo`. I believe there's an extra getAddress in there; this: ``` VkGraphicsPipelineCreateInfo.pStages$set(pPipelineCreateInfo, MemoryAccess.getAddress(pStages)); ``` should be: ``` VkGraphicsPipelineCreateInfo.pStages$set(pPipelineCreateInfo, pStages); ``` That is, you want to pass the pointer to the `pStages` region you just created, so that Vulkan will be able to see all elements. If you call "MemoryAccess::getAddress" your code will read the first 64 bits from the `pStages` region, turn those into a MemoryAddress, and set that into the enclosing `pPipelineCreateInfo` struct. Which I don't think is what you want? Let me know if this works. Cheers Maurizio On 02/09/2021 06:35, Michael Ennen wrote: > I have been doing more exploring with the panama-foreign, ffi, and jextract > branches - this time messing around with seeing if I can get a rainbow > triangle to be rendered on the screen with Vulkan. > > I am really close. There is one problem I am having which is how to create > an array of structs? > > See this, for example: > > https://github.com/brcolow/java-vulkan/blob/master/src/main/java/com/brcolow/game/Vulkan.java#L581 > > If I set the stageCount to 2, then I get a validation exception about the > second shader module having bogus values. I believe this is caused by me > creating the array of structs incorrectly. > > I am trying to set the pStages element of this struct: > https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VkGraphicsPipelineCreateInfo.html > > to an array containing pVertShaderStageInfo and pFragShaderStageInfo. > > My attempt (I have tried other ways that also fail) to do that is: > > MemorySegment pStages = SegmentAllocator.ofScope(scope).allocateArray( > C_POINTER, new Addressable[]{ > pVertShaderStageInfo, pFragShaderStageInfo}); > VkGraphicsPipelineCreateInfo.pStages$set(pPipelineCreateInfo, > MemoryAccess.getAddress(pStages)); > > > If anyone could assist me with the proper way to create the > VkPipelineShaderStageCreateInfo* array containing pVertShaderStageInfoand > pFragShaderStageInfo - it would be greatly appreciated! > From eliu at openjdk.java.net Thu Sep 2 09:57:41 2021 From: eliu at openjdk.java.net (Eric Liu) Date: Thu, 2 Sep 2021 09:57:41 GMT Subject: [vectorIntrinsics+mask] RFR: 8272745: VectorAPI: Vector/Mask type cleanup for masked vector intrinsics In-Reply-To: References: Message-ID: <16CoizVrjhgcJmcLWGt-z5lGC79ouTPZQsZwNsWBrxE=.49681108-1ffc-475d-a274-f4444d0641f2@github.com> On Wed, 1 Sep 2021 22:11:54 GMT, Paul Sandoz wrote: >> Some of the VectorAPIs were inconsistent with their intrinsic >> declarations, and some of the type arguments were not precise enough as >> well.?E.g.,?The return type of "unaryOp" should be a subtype of "Vector" >> instead of an?all-purpose "Object" [1][2]. >> >> The imprecise declarations and type arguments would not effect the >> correctness but bring bad readability and make the code hard to >> maintain. This patch is a cleanup for those mismatched declarations of >> VectorAPIs. >> >> [1] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics%2Bmask/src/java.base/share/classes/jdk/internal/vm/vector/VectorSupport.java#L269 >> [2] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics%2Bmask/src/hotspot/share/classfile/vmIntrinsics.hpp#L812 > > That's a good start. As I looked more deeply i figured it was worth doing a more thorough cleanup for readability and maintainability. > > So I did some changes on top of your PR, see the following patch which should apply cleanly to your PR: > > https://gist.github.com/PaulSandoz/329e0e61b6d0ed5f4d6b5ddc03fa9105 > > (Sorry i did not clone your branch and issue a PR to that, let me know if that is more preferable.) @PaulSandoz Thanks for your kindly review. I patched your changes and tested it on both x86 and aarch64. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/117 From jorn.vernee at oracle.com Thu Sep 2 11:54:27 2021 From: jorn.vernee at oracle.com (Jorn Vernee) Date: Thu, 2 Sep 2021 13:54:27 +0200 Subject: How To Create Array of Structs? In-Reply-To: <0c6361f3-2879-02dd-0b26-e26a5b268602@oracle.com> References: <0c6361f3-2879-02dd-0b26-e26a5b268602@oracle.com> Message-ID: <4bb60084-2958-45f9-511d-638b85770040@oracle.com> Additionally, it looks like you're allocating an array of pointers for pStages, and it looks like the API expects an array of structs. Instead of allocating the different VkPipelineShaderStageCreateInfo individually, you should allocate the array of struct upfront, and then fill in the different structs in-place. Like: diff --git a/src/main/java/com/brcolow/game/Vulkan.java b/src/main/java/com/brcolow/game/Vulkan.java index f0cd278..520513b 100644 --- a/src/main/java/com/brcolow/game/Vulkan.java +++ b/src/main/java/com/brcolow/game/Vulkan.java @@ -429,17 +429,17 @@ public class Vulkan { ???????????? var pVertShaderModule = getShaderModule(MemoryAccess.getAddress(pVkDevice), vertShaderBytes, scope); ???????????? var pFragShaderModule = getShaderModule(MemoryAccess.getAddress(pVkDevice), fragShaderBytes, scope); -??????????? var pVertShaderStageInfo = VkPipelineShaderStageCreateInfo.allocate(scope); - VkPipelineShaderStageCreateInfo.sType$set(pVertShaderStageInfo, vulkan_h.VK_STRUCTURE_TYPE_PIPELINE_SHADER_STAGE_CREATE_INFO()); - VkPipelineShaderStageCreateInfo.stage$set(pVertShaderStageInfo, vulkan_h.VK_SHADER_STAGE_VERTEX_BIT()); - VkPipelineShaderStageCreateInfo.module$set(pVertShaderStageInfo, MemoryAccess.getAddress(pVertShaderModule)); - VkPipelineShaderStageCreateInfo.pName$set(pVertShaderStageInfo, CLinker.toCString("main", scope).address()); - -??????????? var pFragShaderStageInfo = VkPipelineShaderStageCreateInfo.allocate(scope); - VkPipelineShaderStageCreateInfo.sType$set(pFragShaderStageInfo, vulkan_h.VK_STRUCTURE_TYPE_PIPELINE_SHADER_STAGE_CREATE_INFO()); - VkPipelineShaderStageCreateInfo.stage$set(pFragShaderStageInfo, vulkan_h.VK_SHADER_STAGE_FRAGMENT_BIT()); - VkPipelineShaderStageCreateInfo.module$set(pFragShaderStageInfo, MemoryAccess.getAddress(pFragShaderModule)); - VkPipelineShaderStageCreateInfo.pName$set(pFragShaderStageInfo, CLinker.toCString("main", scope).address()); +??????????? MemorySegment pStages = SegmentAllocator.ofScope(scope).allocateArray(VkPipelineShaderStageCreateInfo.$LAYOUT(), 2); + +??????????? VkPipelineShaderStageCreateInfo.sType$set(pStages, 0, vulkan_h.VK_STRUCTURE_TYPE_PIPELINE_SHADER_STAGE_CREATE_INFO()); +??????????? VkPipelineShaderStageCreateInfo.stage$set(pStages, 0, vulkan_h.VK_SHADER_STAGE_VERTEX_BIT()); +??????????? VkPipelineShaderStageCreateInfo.module$set(pStages, 0, MemoryAccess.getAddress(pVertShaderModule)); +??????????? VkPipelineShaderStageCreateInfo.pName$set(pStages, 0, CLinker.toCString("main", scope).address()); + +??????????? VkPipelineShaderStageCreateInfo.sType$set(pStages, 1, vulkan_h.VK_STRUCTURE_TYPE_PIPELINE_SHADER_STAGE_CREATE_INFO()); +??????????? VkPipelineShaderStageCreateInfo.stage$set(pStages, 1, vulkan_h.VK_SHADER_STAGE_FRAGMENT_BIT()); +??????????? VkPipelineShaderStageCreateInfo.module$set(pStages, 1, MemoryAccess.getAddress(pFragShaderModule)); +??????????? VkPipelineShaderStageCreateInfo.pName$set(pStages, 1, CLinker.toCString("main", scope).address()); ???????????? var pVertexInputStateInfo = VkPipelineVertexInputStateCreateInfo.allocate(scope); VkPipelineVertexInputStateCreateInfo.sType$set(pVertexInputStateInfo, vulkan_h.VK_STRUCTURE_TYPE_PIPELINE_VERTEX_INPUT_STATE_CREATE_INFO()); @@ -581,16 +581,14 @@ public class Vulkan { ???????????? // If we change stageCount to 2 we get a crash.... ???????????? // I think we are creating the pStages array incorrectly. This is also manifesting further down when trying ???????????? // to create arrays pWaitSemaphores, pSignalSemaphores, etc. - VkGraphicsPipelineCreateInfo.stageCount$set(pPipelineCreateInfo, 1); -??????????? MemorySegment pStages = SegmentAllocator.ofScope(scope).allocateArray(C_POINTER, new Addressable[]{ -??????????????????? pVertShaderStageInfo, pFragShaderStageInfo}); -??????????? System.out.println("pStages: " + pStages); -??????????? System.out.println("pStages[0]: " + VkPipelineShaderStageCreateInfo.ofAddress(MemoryAccess.getAddressAtIndex(pStages, 0), scope)); -??????????? System.out.println("pStages[0].sType: " + VkPipelineShaderStageCreateInfo.sType$get(VkPipelineShaderStageCreateInfo.ofAddress(MemoryAccess.getAddressAtIndex(pStages, 0), scope))); -??????????? System.out.println("pStages[1]: " + VkPipelineShaderStageCreateInfo.ofAddress(MemoryAccess.getAddressAtIndex(pStages, 1), scope)); -??????????? System.out.println("pStages[1].sType: " + VkPipelineShaderStageCreateInfo.sType$get(VkPipelineShaderStageCreateInfo.ofAddress(MemoryAccess.getAddressAtIndex(pStages, 1), scope))); - - VkGraphicsPipelineCreateInfo.pStages$set(pPipelineCreateInfo, MemoryAccess.getAddress(pStages)); + VkGraphicsPipelineCreateInfo.stageCount$set(pPipelineCreateInfo, 2); +??????????? System.out.println("pStages: " + pStages.address()); +??????????? System.out.println("pStages[0]: " + pStages.asSlice(0, VkPipelineShaderStageCreateInfo.$LAYOUT().byteSize())); +??????????? System.out.println("pStages[0].sType: " + VkPipelineShaderStageCreateInfo.sType$get(pStages, 0)); +??????????? System.out.println("pStages[1]: " + pStages.asSlice(VkPipelineShaderStageCreateInfo.$LAYOUT().byteSize(), VkPipelineShaderStageCreateInfo.$LAYOUT().byteSize())); +??????????? System.out.println("pStages[1].sType: " + VkPipelineShaderStageCreateInfo.sType$get(pStages, 1)); + + VkGraphicsPipelineCreateInfo.pStages$set(pPipelineCreateInfo, pStages.address()); VkGraphicsPipelineCreateInfo.pVertexInputState$set(pPipelineCreateInfo, pVertexInputStateInfo.address()); VkGraphicsPipelineCreateInfo.pInputAssemblyState$set(pPipelineCreateInfo, pPipelineInputAssemblyStateInfo.address()); VkGraphicsPipelineCreateInfo.pViewportState$set(pPipelineCreateInfo, pPipelineViewportStateInfo.address()); HTH, Jorn On 02/09/2021 11:56, Maurizio Cimadamore wrote: > Hi Michael, > very interesting experiments - thanks for reaching out. > > Eyeballing your code, I zoomed into this line: > > https://github.com/brcolow/java-vulkan/blob/master/src/main/java/com/brcolow/game/Vulkan.java#L593 > > > Here you want to set the `pStages` pointer, a pointer to a memory > region which presumably has to contain exactly `stageCount` structs of > type `VkPipelineShaderStageCreateInfo`. > > I believe there's an extra getAddress in there; this: > > ``` > VkGraphicsPipelineCreateInfo.pStages$set(pPipelineCreateInfo, > MemoryAccess.getAddress(pStages)); > ``` > > should be: > > ``` > VkGraphicsPipelineCreateInfo.pStages$set(pPipelineCreateInfo, pStages); > ``` > > That is, you want to pass the pointer to the `pStages` region you just > created, so that Vulkan will be able to see all elements. If you call > "MemoryAccess::getAddress" your code will read the first 64 bits from > the `pStages` region, turn those into a MemoryAddress, and set that > into the enclosing `pPipelineCreateInfo` struct. Which I don't think > is what you want? > > Let me know if this works. > > Cheers > Maurizio > > > On 02/09/2021 06:35, Michael Ennen wrote: >> I have been doing more exploring with the panama-foreign, ffi, and >> jextract >> branches - this time messing around with seeing if I can get a rainbow >> triangle to be rendered on the screen with Vulkan. >> >> I am really close. There is one problem I am having which is how to >> create >> an array of structs? >> >> See this, for example: >> >> https://github.com/brcolow/java-vulkan/blob/master/src/main/java/com/brcolow/game/Vulkan.java#L581 >> >> >> If I set the stageCount to 2, then I get a validation exception about >> the >> second shader module having bogus values. I believe this is caused by me >> creating the array of structs incorrectly. >> >> I am trying to set the pStages element of this struct: >> https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VkGraphicsPipelineCreateInfo.html >> >> >> to an array containing pVertShaderStageInfo and pFragShaderStageInfo. >> >> My attempt (I have tried other ways that also fail) to do that is: >> >> MemorySegment pStages = SegmentAllocator.ofScope(scope).allocateArray( >> C_POINTER, new Addressable[]{ >> pVertShaderStageInfo, pFragShaderStageInfo}); >> VkGraphicsPipelineCreateInfo.pStages$set(pPipelineCreateInfo, >> MemoryAccess.getAddress(pStages)); >> >> >> If anyone could assist me with the proper way to create the >> VkPipelineShaderStageCreateInfo* array containing >> pVertShaderStageInfoand >> pFragShaderStageInfo - it would be greatly appreciated! >> From psandoz at openjdk.java.net Thu Sep 2 14:46:17 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Thu, 2 Sep 2021 14:46:17 GMT Subject: [vectorIntrinsics+mask] RFR: 8272745: VectorAPI: Vector/Mask type cleanup for masked vector intrinsics [v2] In-Reply-To: References: Message-ID: <8kaphkWcaNvrIg-BGrf0BdBWjr-qBn4HfSc2h3GfNSM=.09abb72e-ca7b-4eba-b1eb-8d127676c549@github.com> On Thu, 2 Sep 2021 09:55:16 GMT, Eric Liu wrote: >> Some of the VectorAPIs were inconsistent with their intrinsic >> declarations, and some of the type arguments were not precise enough as >> well.?E.g.,?The return type of "unaryOp" should be a subtype of "Vector" >> instead of an?all-purpose "Object" [1][2]. >> >> The imprecise declarations and type arguments would not effect the >> correctness but bring bad readability and make the code hard to >> maintain. This patch is a cleanup for those mismatched declarations of >> VectorAPIs. >> >> [1] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics%2Bmask/src/java.base/share/classes/jdk/internal/vm/vector/VectorSupport.java#L269 >> [2] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics%2Bmask/src/hotspot/share/classfile/vmIntrinsics.hpp#L812 > > Eric Liu has updated the pull request incrementally with one additional commit since the last revision: > > more thorough cleanup > > Change-Id: I22387cb5ae843cbf61104c3e01003d8e89b311a2 Thanks for applying the patch. ------------- Marked as reviewed by psandoz (Committer). PR: https://git.openjdk.java.net/panama-vector/pull/117 From paul.sandoz at oracle.com Thu Sep 2 16:50:10 2021 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 2 Sep 2021 16:50:10 +0000 Subject: [vectorIntrinsics+mask] RFR: 8273057: [vector] New VectorAPI "SelectiveStore" In-Reply-To: References: Message-ID: <4556C43C-6DB8-4DFE-BA9F-0725D7939189@oracle.com> Hi Joshua, I think we still have some exploring to do on the design, and for others to comment esp. with regards to C2 capabilities. Here is another design alternative between the spectrum of a partitioning/compressing a shuffle from mask [*] and a compress method: VectorMask mask = ...; IntVector bv = av.rearrange(VectorOperator.COMPRESS, mask); VectorMask prefixMask = prefix(mask.trueCount()); bv.intoArray(array, offset, prefixMask); offset += mask.trueCount(); We introduce a new kind of operator, Rearrange, and constants, such as VectorOperator.COMPRESS that specifies behavior of the non-mask and mask accepting rearrange methods. COMPRESS specifies that: 1) the non-mask rearrange is an identity operation; and 2) the mask accepting rearrange describes mask-based cross-lane movement: It should be possible to create a shuffle from a Rearrange operator, with and without a mask so the equivalent functionality can be applied to a shuffle accepting rearrange e.g, for COMPRESS: rearrange(Shuffle.fromRearrangeOp(COMPRESS, mask), mask.prefix()) Or rearrange(Shuffle.fromRearrangeOp(COMPRESS, mask), zero()) // Postfix of exceptional lanes in the shuffle, representing unset lanes For this to be of benefit we would need to come up with other realistic Rearrange operators, even if we do not add them right now e.g. IOTA, REVERSE, PARTITION_TRUE, PARTITION_FALSE, INTERLEAVE. However, the design is a little awkward since the mask may or may not contribute to cross-lane movement, and so the operator needs to state the equivalence. In effect the Rearrange operator is a mechanism to refer to certain kinds of shuffle as a constant. Ideally I would still prefer if we could implicitly identify what would otherwise be rearrange operators based on the creation of shuffles with known content e.g. can C2 somehow tag a shuffle instance with an ID of COMPRESS with a dependency on the mask used for its creation? ? FWIW another way to think about a partitioning/compression shuffle: SPECIES.iota().compress(m); Which is just specific way of shuffling a shuffle. We could actually track the kinds of shuffle as final fields of the VectorShuffle implementation. Paul. [*] We could consider this independently > On Sep 1, 2021, at 4:55 AM, Joshua Zhu wrote: > > On Fri, 27 Aug 2021 09:47:10 GMT, Joshua Zhu wrote: > >> Hi, >> >> I want to propose a new VectorAPI "Selective Store/Load" and share my >> implementation. Currently Alibaba's internal databases are in the >> process of applying VectorAPI and they have requirements on "Selective >> Store" for acceleration. >> >> My proposed VectorAPI is declared as below [1]: >> >> int selectiveIntoArray($type$[] a, int offset, VectorMask<$Boxtype$> m); >> >> The active elements (with their respective bit set in mask) are >> contiguously stored into the array "a". Assume N is the true count of >> mask, the elements starting from a[offset+N] till a[offset+laneCount] >> are left unchanged. The return value represents the number of elements >> store into the array and "offset + return value" is the new offset of >> the next iteration. >> ![image](https://user-images.githubusercontent.com/70769035/131108509-3dcb61f3-e8d0-4b4e-9b49-a72c077aaba6.png) >> This API will be used like the following manner [2]: >> >> tld.conflict_cnt = 0; >> for (int i = 0; i < ARRAY_LENGTH; i += INT_PREFERRED_SPECIES.length()) { >> IntVector av = IntVector.fromArray(INT_PREFERRED_SPECIES, tld.int_input1, i); >> IntVector bv = IntVector.fromArray(INT_PREFERRED_SPECIES, tld.int_input2, i); >> IntVector cv = IntVector.fromArray(INT_PREFERRED_SPECIES, tld.int_index, i); >> VectorMask mask = av.compare(VectorOperators.NE, bv); >> tld.conflict_cnt += cv.selectiveIntoArray(tld.conflict_array, tld.conflict_cnt, mask); >> } >> >> My patch includes the following changes: >>   * Selective Store VectorAPI for Long & Int >>   * Assembler: add x86 instruction "VPCOMPRESSD" and "VPCOMPRESSQ" >>   * Instruction selection: vselective_store; kmask_truecount (true count of kregister) >>   * Add node "StoreVectorSelective" >>   * Add a new parameter "is_selective" in inline_vector_mem_masked_operation() >>     in order to distinguish Masked version or Selective version >>   * jtreg cases >>   * JMH benchmark >> >> TODO parts I will implement: >>   * Selective Store for other types >>   * Selective Load >>   * Some potential optimization. Such as: when mask is allTrue, SelectiveIntoArray() -> IntoArray() >> >> Test: >>   * Passed VectorAPI jtreg cases. >>   * Result of JMH benchmark to evaluate API's performance in Alibaba's real scenario. >>       UseAVX=3; thread number = 8; conflict data percentage: 20% (that means 20% of mask bits are true) >>       http://cr.openjdk.java.net/~jzhu/8273057/jmh_benchmark_result.pdf >> >> [1] https://github.com/JoshuaZhuwj/panama-vector/commit/69623f7d6a1eae532576359328b96162d8e16837#diff-13cc2d6ec18e487ddae05cda671bdb6bb7ffd42ff7bc51a2e00c8c5e622bd55dR4667 >> [2] https://github.com/JoshuaZhuwj/panama-vector/commit/69623f7d6a1eae532576359328b96162d8e16837#diff-951d02bd72a931ac34bc85d1d4e656a14f8943e143fc9282b36b9c76c1893c0cR144 >> [3] failed to inline (intrinsic) by https://github.com/openjdk/panama-vector/blob/60aa8ca6dc0b3f1a3ee517db167f9660012858cd/src/hotspot/cpu/x86/x86.ad#L1769 >> >> Best Regards, >> Joshua > > Thank Paul, John Rose and Ningsheng for your comments. > > A vector-to-vector compress operation is the more friendly primitive. > Both Intel AVX3 instruction "COMPRESS" and Arm SVE instruction "COMPACT" provide the capability. > Hence selective store could be implemented by > > VectorMask mask = ...; > IntVector bv = av.compress(mask); > VectorMask prefixMask = prefix(mask.trueCount()); > bv.intoArray(array, offset, prefixMask); > offset += mask.trueCount(); > > The vector-to-vector compress primitive together with a store and prefix mask could be optimized further into memory destination version of compress on supported architecture. > > Once architectures do not support vector-to-vector compress natively, > the intrinsic bailed out and then java path is taken. > Java path could be composed by "mask -> shuffle -> rearrange" and C2 will then try to inline intrinsics again for these API calls. > In this way, we are also able to implement scatter/gather store/load in the same composition manner to keep design consistency. > > Best Regards, > Joshua > > ------------- > > PR: https://git.openjdk.java.net/panama-vector/pull/115 From eliu at openjdk.java.net Thu Sep 2 17:06:15 2021 From: eliu at openjdk.java.net (Eric Liu) Date: Thu, 2 Sep 2021 17:06:15 GMT Subject: [vectorIntrinsics+mask] Integrated: 8272745: VectorAPI: Vector/Mask type cleanup for masked vector intrinsics In-Reply-To: References: Message-ID: On Wed, 1 Sep 2021 01:26:11 GMT, Eric Liu wrote: > Some of the VectorAPIs were inconsistent with their intrinsic > declarations, and some of the type arguments were not precise enough as > well.?E.g.,?The return type of "unaryOp" should be a subtype of "Vector" > instead of an?all-purpose "Object" [1][2]. > > The imprecise declarations and type arguments would not effect the > correctness but bring bad readability and make the code hard to > maintain. This patch is a cleanup for those mismatched declarations of > VectorAPIs. > > [1] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics%2Bmask/src/java.base/share/classes/jdk/internal/vm/vector/VectorSupport.java#L269 > [2] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics%2Bmask/src/hotspot/share/classfile/vmIntrinsics.hpp#L812 This pull request has now been integrated. Changeset: 859a7572 Author: Eric Liu URL: https://git.openjdk.java.net/panama-vector/commit/859a75726d6b0b818cf45ba82eb6c3b42d7252cd Stats: 581 lines in 4 files changed: 296 ins; 24 del; 261 mod 8272745: VectorAPI: Vector/Mask type cleanup for masked vector intrinsics Co-authored-by: Paul Sandoz Reviewed-by: psandoz ------------- PR: https://git.openjdk.java.net/panama-vector/pull/117 From mike.ennen at gmail.com Thu Sep 2 18:06:41 2021 From: mike.ennen at gmail.com (Michael Ennen) Date: Thu, 2 Sep 2021 11:06:41 -0700 Subject: How To Create Array of Structs? In-Reply-To: <4bb60084-2958-45f9-511d-638b85770040@oracle.com> References: <0c6361f3-2879-02dd-0b26-e26a5b268602@oracle.com> <4bb60084-2958-45f9-511d-638b85770040@oracle.com> Message-ID: Jorn, Thank you so much - that was exactly what I was looking for. I don't know why I had such trouble trying to create an array of structs rather than an array of points to structs. Thank you both. On Thu, Sep 2, 2021 at 4:54 AM Jorn Vernee wrote: > Additionally, it looks like you're allocating an array of pointers for > pStages, and it looks like the API expects an array of structs. > > Instead of allocating the different VkPipelineShaderStageCreateInfo > individually, you should allocate the array of struct upfront, and then > fill in the different structs in-place. > > Like: > > diff --git a/src/main/java/com/brcolow/game/Vulkan.java > b/src/main/java/com/brcolow/game/Vulkan.java > index f0cd278..520513b 100644 > --- a/src/main/java/com/brcolow/game/Vulkan.java > +++ b/src/main/java/com/brcolow/game/Vulkan.java > @@ -429,17 +429,17 @@ public class Vulkan { > var pVertShaderModule = > getShaderModule(MemoryAccess.getAddress(pVkDevice), vertShaderBytes, > scope); > var pFragShaderModule = > getShaderModule(MemoryAccess.getAddress(pVkDevice), fragShaderBytes, > scope); > > - var pVertShaderStageInfo = > VkPipelineShaderStageCreateInfo.allocate(scope); > - VkPipelineShaderStageCreateInfo.sType$set(pVertShaderStageInfo, > vulkan_h.VK_STRUCTURE_TYPE_PIPELINE_SHADER_STAGE_CREATE_INFO()); > - VkPipelineShaderStageCreateInfo.stage$set(pVertShaderStageInfo, > vulkan_h.VK_SHADER_STAGE_VERTEX_BIT()); > - VkPipelineShaderStageCreateInfo.module$set(pVertShaderStageInfo, > MemoryAccess.getAddress(pVertShaderModule)); > - VkPipelineShaderStageCreateInfo.pName$set(pVertShaderStageInfo, > CLinker.toCString("main", scope).address()); > - > - var pFragShaderStageInfo = > VkPipelineShaderStageCreateInfo.allocate(scope); > - VkPipelineShaderStageCreateInfo.sType$set(pFragShaderStageInfo, > vulkan_h.VK_STRUCTURE_TYPE_PIPELINE_SHADER_STAGE_CREATE_INFO()); > - VkPipelineShaderStageCreateInfo.stage$set(pFragShaderStageInfo, > vulkan_h.VK_SHADER_STAGE_FRAGMENT_BIT()); > - VkPipelineShaderStageCreateInfo.module$set(pFragShaderStageInfo, > MemoryAccess.getAddress(pFragShaderModule)); > - VkPipelineShaderStageCreateInfo.pName$set(pFragShaderStageInfo, > CLinker.toCString("main", scope).address()); > + MemorySegment pStages = > SegmentAllocator.ofScope(scope).allocateArray(VkPipelineShaderStageCreateInfo.$LAYOUT(), > > 2); > + > + VkPipelineShaderStageCreateInfo.sType$set(pStages, 0, > vulkan_h.VK_STRUCTURE_TYPE_PIPELINE_SHADER_STAGE_CREATE_INFO()); > + VkPipelineShaderStageCreateInfo.stage$set(pStages, 0, > vulkan_h.VK_SHADER_STAGE_VERTEX_BIT()); > + VkPipelineShaderStageCreateInfo.module$set(pStages, 0, > MemoryAccess.getAddress(pVertShaderModule)); > + VkPipelineShaderStageCreateInfo.pName$set(pStages, 0, > CLinker.toCString("main", scope).address()); > + > + VkPipelineShaderStageCreateInfo.sType$set(pStages, 1, > vulkan_h.VK_STRUCTURE_TYPE_PIPELINE_SHADER_STAGE_CREATE_INFO()); > + VkPipelineShaderStageCreateInfo.stage$set(pStages, 1, > vulkan_h.VK_SHADER_STAGE_FRAGMENT_BIT()); > + VkPipelineShaderStageCreateInfo.module$set(pStages, 1, > MemoryAccess.getAddress(pFragShaderModule)); > + VkPipelineShaderStageCreateInfo.pName$set(pStages, 1, > CLinker.toCString("main", scope).address()); > > var pVertexInputStateInfo = > VkPipelineVertexInputStateCreateInfo.allocate(scope); > VkPipelineVertexInputStateCreateInfo.sType$set(pVertexInputStateInfo, > vulkan_h.VK_STRUCTURE_TYPE_PIPELINE_VERTEX_INPUT_STATE_CREATE_INFO()); > @@ -581,16 +581,14 @@ public class Vulkan { > // If we change stageCount to 2 we get a crash.... > // I think we are creating the pStages array incorrectly. > This is also manifesting further down when trying > // to create arrays pWaitSemaphores, pSignalSemaphores, etc. > - VkGraphicsPipelineCreateInfo.stageCount$set(pPipelineCreateInfo, 1); > - MemorySegment pStages = > SegmentAllocator.ofScope(scope).allocateArray(C_POINTER, new Addressable[]{ > - pVertShaderStageInfo, pFragShaderStageInfo}); > - System.out.println("pStages: " + pStages); > - System.out.println("pStages[0]: " + > VkPipelineShaderStageCreateInfo.ofAddress(MemoryAccess.getAddressAtIndex(pStages, > > 0), scope)); > - System.out.println("pStages[0].sType: " + > VkPipelineShaderStageCreateInfo.sType$get(VkPipelineShaderStageCreateInfo.ofAddress(MemoryAccess.getAddressAtIndex(pStages, > > 0), scope))); > - System.out.println("pStages[1]: " + > VkPipelineShaderStageCreateInfo.ofAddress(MemoryAccess.getAddressAtIndex(pStages, > > 1), scope)); > - System.out.println("pStages[1].sType: " + > VkPipelineShaderStageCreateInfo.sType$get(VkPipelineShaderStageCreateInfo.ofAddress(MemoryAccess.getAddressAtIndex(pStages, > > 1), scope))); > - > - VkGraphicsPipelineCreateInfo.pStages$set(pPipelineCreateInfo, > MemoryAccess.getAddress(pStages)); > + VkGraphicsPipelineCreateInfo.stageCount$set(pPipelineCreateInfo, 2); > + System.out.println("pStages: " + pStages.address()); > + System.out.println("pStages[0]: " + pStages.asSlice(0, > VkPipelineShaderStageCreateInfo.$LAYOUT().byteSize())); > + System.out.println("pStages[0].sType: " + > VkPipelineShaderStageCreateInfo.sType$get(pStages, 0)); > + System.out.println("pStages[1]: " + > pStages.asSlice(VkPipelineShaderStageCreateInfo.$LAYOUT().byteSize(), > VkPipelineShaderStageCreateInfo.$LAYOUT().byteSize())); > + System.out.println("pStages[1].sType: " + > VkPipelineShaderStageCreateInfo.sType$get(pStages, 1)); > + > + VkGraphicsPipelineCreateInfo.pStages$set(pPipelineCreateInfo, > pStages.address()); > VkGraphicsPipelineCreateInfo.pVertexInputState$set(pPipelineCreateInfo, > pVertexInputStateInfo.address()); > VkGraphicsPipelineCreateInfo.pInputAssemblyState$set(pPipelineCreateInfo, > pPipelineInputAssemblyStateInfo.address()); > VkGraphicsPipelineCreateInfo.pViewportState$set(pPipelineCreateInfo, > pPipelineViewportStateInfo.address()); > > HTH, > Jorn > > On 02/09/2021 11:56, Maurizio Cimadamore wrote: > > Hi Michael, > > very interesting experiments - thanks for reaching out. > > > > Eyeballing your code, I zoomed into this line: > > > > > https://github.com/brcolow/java-vulkan/blob/master/src/main/java/com/brcolow/game/Vulkan.java#L593 > > > > > > Here you want to set the `pStages` pointer, a pointer to a memory > > region which presumably has to contain exactly `stageCount` structs of > > type `VkPipelineShaderStageCreateInfo`. > > > > I believe there's an extra getAddress in there; this: > > > > ``` > > VkGraphicsPipelineCreateInfo.pStages$set(pPipelineCreateInfo, > > MemoryAccess.getAddress(pStages)); > > ``` > > > > should be: > > > > ``` > > VkGraphicsPipelineCreateInfo.pStages$set(pPipelineCreateInfo, pStages); > > ``` > > > > That is, you want to pass the pointer to the `pStages` region you just > > created, so that Vulkan will be able to see all elements. If you call > > "MemoryAccess::getAddress" your code will read the first 64 bits from > > the `pStages` region, turn those into a MemoryAddress, and set that > > into the enclosing `pPipelineCreateInfo` struct. Which I don't think > > is what you want? > > > > Let me know if this works. > > > > Cheers > > Maurizio > > > > > > On 02/09/2021 06:35, Michael Ennen wrote: > >> I have been doing more exploring with the panama-foreign, ffi, and > >> jextract > >> branches - this time messing around with seeing if I can get a rainbow > >> triangle to be rendered on the screen with Vulkan. > >> > >> I am really close. There is one problem I am having which is how to > >> create > >> an array of structs? > >> > >> See this, for example: > >> > >> > https://github.com/brcolow/java-vulkan/blob/master/src/main/java/com/brcolow/game/Vulkan.java#L581 > >> > >> > >> If I set the stageCount to 2, then I get a validation exception about > >> the > >> second shader module having bogus values. I believe this is caused by me > >> creating the array of structs incorrectly. > >> > >> I am trying to set the pStages element of this struct: > >> > https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VkGraphicsPipelineCreateInfo.html > >> > >> > >> to an array containing pVertShaderStageInfo and pFragShaderStageInfo. > >> > >> My attempt (I have tried other ways that also fail) to do that is: > >> > >> MemorySegment pStages = SegmentAllocator.ofScope(scope).allocateArray( > >> C_POINTER, new Addressable[]{ > >> pVertShaderStageInfo, pFragShaderStageInfo}); > >> VkGraphicsPipelineCreateInfo.pStages$set(pPipelineCreateInfo, > >> MemoryAccess.getAddress(pStages)); > >> > >> > >> If anyone could assist me with the proper way to create the > >> VkPipelineShaderStageCreateInfo* array containing > >> pVertShaderStageInfoand > >> pFragShaderStageInfo - it would be greatly appreciated! > >> > -- Michael Ennen From mike.ennen at gmail.com Thu Sep 2 18:16:16 2021 From: mike.ennen at gmail.com (Michael Ennen) Date: Thu, 2 Sep 2021 11:16:16 -0700 Subject: How To Create Array of Structs? In-Reply-To: References: <0c6361f3-2879-02dd-0b26-e26a5b268602@oracle.com> <4bb60084-2958-45f9-511d-638b85770040@oracle.com> Message-ID: Quick question that is now happening while trying to replicate the fix when I don't have an explicit struct handle like in the case of VkSemaphore: https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VkSemaphore.html For those types I don't have a struct layout to work with so I have been just declaring a double pointer: var pVkPipeline = SegmentAllocator.ofScope(scope).allocate(C_POINTER.byteSize()); and then using MemoryAccess.getAddress(pVkPipeline). So in this case how can I create an array of VkSemaphore structs without knowing anything about the struct (it is an opaque handle?). Hope that makes sense. On Thu, Sep 2, 2021 at 11:06 AM Michael Ennen wrote: > Jorn, > > Thank you so much - that was exactly what I was looking for. I don't know > why I had such trouble trying to create an array of structs rather than an > array of points to structs. > > Thank you both. > > On Thu, Sep 2, 2021 at 4:54 AM Jorn Vernee wrote: > >> Additionally, it looks like you're allocating an array of pointers for >> pStages, and it looks like the API expects an array of structs. >> >> Instead of allocating the different VkPipelineShaderStageCreateInfo >> individually, you should allocate the array of struct upfront, and then >> fill in the different structs in-place. >> >> Like: >> >> diff --git a/src/main/java/com/brcolow/game/Vulkan.java >> b/src/main/java/com/brcolow/game/Vulkan.java >> index f0cd278..520513b 100644 >> --- a/src/main/java/com/brcolow/game/Vulkan.java >> +++ b/src/main/java/com/brcolow/game/Vulkan.java >> @@ -429,17 +429,17 @@ public class Vulkan { >> var pVertShaderModule = >> getShaderModule(MemoryAccess.getAddress(pVkDevice), vertShaderBytes, >> scope); >> var pFragShaderModule = >> getShaderModule(MemoryAccess.getAddress(pVkDevice), fragShaderBytes, >> scope); >> >> - var pVertShaderStageInfo = >> VkPipelineShaderStageCreateInfo.allocate(scope); >> - VkPipelineShaderStageCreateInfo.sType$set(pVertShaderStageInfo, >> vulkan_h.VK_STRUCTURE_TYPE_PIPELINE_SHADER_STAGE_CREATE_INFO()); >> - VkPipelineShaderStageCreateInfo.stage$set(pVertShaderStageInfo, >> vulkan_h.VK_SHADER_STAGE_VERTEX_BIT()); >> - VkPipelineShaderStageCreateInfo.module$set(pVertShaderStageInfo, >> MemoryAccess.getAddress(pVertShaderModule)); >> - VkPipelineShaderStageCreateInfo.pName$set(pVertShaderStageInfo, >> CLinker.toCString("main", scope).address()); >> - >> - var pFragShaderStageInfo = >> VkPipelineShaderStageCreateInfo.allocate(scope); >> - VkPipelineShaderStageCreateInfo.sType$set(pFragShaderStageInfo, >> vulkan_h.VK_STRUCTURE_TYPE_PIPELINE_SHADER_STAGE_CREATE_INFO()); >> - VkPipelineShaderStageCreateInfo.stage$set(pFragShaderStageInfo, >> vulkan_h.VK_SHADER_STAGE_FRAGMENT_BIT()); >> - VkPipelineShaderStageCreateInfo.module$set(pFragShaderStageInfo, >> MemoryAccess.getAddress(pFragShaderModule)); >> - VkPipelineShaderStageCreateInfo.pName$set(pFragShaderStageInfo, >> CLinker.toCString("main", scope).address()); >> + MemorySegment pStages = >> SegmentAllocator.ofScope(scope).allocateArray(VkPipelineShaderStageCreateInfo.$LAYOUT(), >> >> 2); >> + >> + VkPipelineShaderStageCreateInfo.sType$set(pStages, 0, >> vulkan_h.VK_STRUCTURE_TYPE_PIPELINE_SHADER_STAGE_CREATE_INFO()); >> + VkPipelineShaderStageCreateInfo.stage$set(pStages, 0, >> vulkan_h.VK_SHADER_STAGE_VERTEX_BIT()); >> + VkPipelineShaderStageCreateInfo.module$set(pStages, 0, >> MemoryAccess.getAddress(pVertShaderModule)); >> + VkPipelineShaderStageCreateInfo.pName$set(pStages, 0, >> CLinker.toCString("main", scope).address()); >> + >> + VkPipelineShaderStageCreateInfo.sType$set(pStages, 1, >> vulkan_h.VK_STRUCTURE_TYPE_PIPELINE_SHADER_STAGE_CREATE_INFO()); >> + VkPipelineShaderStageCreateInfo.stage$set(pStages, 1, >> vulkan_h.VK_SHADER_STAGE_FRAGMENT_BIT()); >> + VkPipelineShaderStageCreateInfo.module$set(pStages, 1, >> MemoryAccess.getAddress(pFragShaderModule)); >> + VkPipelineShaderStageCreateInfo.pName$set(pStages, 1, >> CLinker.toCString("main", scope).address()); >> >> var pVertexInputStateInfo = >> VkPipelineVertexInputStateCreateInfo.allocate(scope); >> VkPipelineVertexInputStateCreateInfo.sType$set(pVertexInputStateInfo, >> vulkan_h.VK_STRUCTURE_TYPE_PIPELINE_VERTEX_INPUT_STATE_CREATE_INFO()); >> @@ -581,16 +581,14 @@ public class Vulkan { >> // If we change stageCount to 2 we get a crash.... >> // I think we are creating the pStages array incorrectly. >> This is also manifesting further down when trying >> // to create arrays pWaitSemaphores, pSignalSemaphores, etc. >> - VkGraphicsPipelineCreateInfo.stageCount$set(pPipelineCreateInfo, 1); >> - MemorySegment pStages = >> SegmentAllocator.ofScope(scope).allocateArray(C_POINTER, new >> Addressable[]{ >> - pVertShaderStageInfo, pFragShaderStageInfo}); >> - System.out.println("pStages: " + pStages); >> - System.out.println("pStages[0]: " + >> VkPipelineShaderStageCreateInfo.ofAddress(MemoryAccess.getAddressAtIndex(pStages, >> >> 0), scope)); >> - System.out.println("pStages[0].sType: " + >> VkPipelineShaderStageCreateInfo.sType$get(VkPipelineShaderStageCreateInfo.ofAddress(MemoryAccess.getAddressAtIndex(pStages, >> >> 0), scope))); >> - System.out.println("pStages[1]: " + >> VkPipelineShaderStageCreateInfo.ofAddress(MemoryAccess.getAddressAtIndex(pStages, >> >> 1), scope)); >> - System.out.println("pStages[1].sType: " + >> VkPipelineShaderStageCreateInfo.sType$get(VkPipelineShaderStageCreateInfo.ofAddress(MemoryAccess.getAddressAtIndex(pStages, >> >> 1), scope))); >> - >> - VkGraphicsPipelineCreateInfo.pStages$set(pPipelineCreateInfo, >> MemoryAccess.getAddress(pStages)); >> + VkGraphicsPipelineCreateInfo.stageCount$set(pPipelineCreateInfo, 2); >> + System.out.println("pStages: " + pStages.address()); >> + System.out.println("pStages[0]: " + pStages.asSlice(0, >> VkPipelineShaderStageCreateInfo.$LAYOUT().byteSize())); >> + System.out.println("pStages[0].sType: " + >> VkPipelineShaderStageCreateInfo.sType$get(pStages, 0)); >> + System.out.println("pStages[1]: " + >> pStages.asSlice(VkPipelineShaderStageCreateInfo.$LAYOUT().byteSize(), >> VkPipelineShaderStageCreateInfo.$LAYOUT().byteSize())); >> + System.out.println("pStages[1].sType: " + >> VkPipelineShaderStageCreateInfo.sType$get(pStages, 1)); >> + >> + VkGraphicsPipelineCreateInfo.pStages$set(pPipelineCreateInfo, >> pStages.address()); >> VkGraphicsPipelineCreateInfo.pVertexInputState$set(pPipelineCreateInfo, >> pVertexInputStateInfo.address()); >> VkGraphicsPipelineCreateInfo.pInputAssemblyState$set(pPipelineCreateInfo, >> pPipelineInputAssemblyStateInfo.address()); >> VkGraphicsPipelineCreateInfo.pViewportState$set(pPipelineCreateInfo, >> pPipelineViewportStateInfo.address()); >> >> HTH, >> Jorn >> >> On 02/09/2021 11:56, Maurizio Cimadamore wrote: >> > Hi Michael, >> > very interesting experiments - thanks for reaching out. >> > >> > Eyeballing your code, I zoomed into this line: >> > >> > >> https://github.com/brcolow/java-vulkan/blob/master/src/main/java/com/brcolow/game/Vulkan.java#L593 >> > >> > >> > Here you want to set the `pStages` pointer, a pointer to a memory >> > region which presumably has to contain exactly `stageCount` structs of >> > type `VkPipelineShaderStageCreateInfo`. >> > >> > I believe there's an extra getAddress in there; this: >> > >> > ``` >> > VkGraphicsPipelineCreateInfo.pStages$set(pPipelineCreateInfo, >> > MemoryAccess.getAddress(pStages)); >> > ``` >> > >> > should be: >> > >> > ``` >> > VkGraphicsPipelineCreateInfo.pStages$set(pPipelineCreateInfo, pStages); >> > ``` >> > >> > That is, you want to pass the pointer to the `pStages` region you just >> > created, so that Vulkan will be able to see all elements. If you call >> > "MemoryAccess::getAddress" your code will read the first 64 bits from >> > the `pStages` region, turn those into a MemoryAddress, and set that >> > into the enclosing `pPipelineCreateInfo` struct. Which I don't think >> > is what you want? >> > >> > Let me know if this works. >> > >> > Cheers >> > Maurizio >> > >> > >> > On 02/09/2021 06:35, Michael Ennen wrote: >> >> I have been doing more exploring with the panama-foreign, ffi, and >> >> jextract >> >> branches - this time messing around with seeing if I can get a rainbow >> >> triangle to be rendered on the screen with Vulkan. >> >> >> >> I am really close. There is one problem I am having which is how to >> >> create >> >> an array of structs? >> >> >> >> See this, for example: >> >> >> >> >> https://github.com/brcolow/java-vulkan/blob/master/src/main/java/com/brcolow/game/Vulkan.java#L581 >> >> >> >> >> >> If I set the stageCount to 2, then I get a validation exception about >> >> the >> >> second shader module having bogus values. I believe this is caused by >> me >> >> creating the array of structs incorrectly. >> >> >> >> I am trying to set the pStages element of this struct: >> >> >> https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VkGraphicsPipelineCreateInfo.html >> >> >> >> >> >> to an array containing pVertShaderStageInfo and pFragShaderStageInfo. >> >> >> >> My attempt (I have tried other ways that also fail) to do that is: >> >> >> >> MemorySegment pStages = SegmentAllocator.ofScope(scope).allocateArray( >> >> C_POINTER, new Addressable[]{ >> >> pVertShaderStageInfo, pFragShaderStageInfo}); >> >> VkGraphicsPipelineCreateInfo.pStages$set(pPipelineCreateInfo, >> >> MemoryAccess.getAddress(pStages)); >> >> >> >> >> >> If anyone could assist me with the proper way to create the >> >> VkPipelineShaderStageCreateInfo* array containing >> >> pVertShaderStageInfoand >> >> pFragShaderStageInfo - it would be greatly appreciated! >> >> >> > > > -- > Michael Ennen > -- Michael Ennen From john.r.rose at oracle.com Thu Sep 2 18:33:14 2021 From: john.r.rose at oracle.com (John Rose) Date: Thu, 2 Sep 2021 18:33:14 +0000 Subject: [vectorIntrinsics+mask] RFR: 8273057: [vector] New VectorAPI "SelectiveStore" In-Reply-To: <4556C43C-6DB8-4DFE-BA9F-0725D7939189@oracle.com> References: <4556C43C-6DB8-4DFE-BA9F-0725D7939189@oracle.com> Message-ID: On Sep 2, 2021, at 9:50 AM, Paul Sandoz wrote: > > Hi Joshua, > > I think we still have some exploring to do on the design, and for others to comment esp. with regards to C2 capabilities. > > > Here is another design alternative between the spectrum of a partitioning/compressing a shuffle from mask [*] and a compress method: > > VectorMask mask = ...; > IntVector bv = av.rearrange(VectorOperator.COMPRESS, mask); > VectorMask prefixMask = prefix(mask.trueCount()); > bv.intoArray(array, offset, prefixMask); > offset += mask.trueCount(); > > We introduce a new kind of operator, Rearrange, and constants, such as VectorOperator.COMPRESS that specifies behavior of the non-mask and mask accepting rearrange methods. COMPRESS specifies that: > > 1) the non-mask rearrange is an identity operation; and > 2) the mask accepting rearrange describes mask-based cross-lane movement: Be careful with adding bulk operations to VectorOperations. Those are supposed to be only lanewise (scalar). It?s not clear to me what COMPRESS could mean, as a lanewise operation. One very interesting potential interaction between lanewise ops and masked operations is reduction of a subset of lanes. This feels a little like compress, although the lateral data motion is absent. I?m thinking that generalized shuffle, lateral compression/expansion, and segmented scan/reduce may be the interesting primitives here. The FIRST_NONZERO operation is the closest thing we have to lateral motion today: The idea is that non-zero lane values propagate from higher to lower positions, skipping over zero lane values. We might try to get from FIRST_NONZERO to compress by defining an enhanced segmented reduction operation which takes into a account masking (to define segments that are to be individually reduced), and then take additional wins from using other VOs such as MAX, ADD, etc. I?m throwing this out as brainstorming; what I get from this line of thought is that segmented scans naturally deliver results in expanded form, while segmented reductions have two natural forms of output, expanded and compressed. So we need a compress primitive, and/or an expand/compress mode bit for segmented reduction. (Matters of terminology: scan(op) produces the vector of partial results that would be obtained if a reduction(op) operation proceeded linearly from lane 0 to lane VLENGTH-1, recording an intermediate result in each lane, often before lane value is accumulated. The scan can take a carry-in and carry-out lane value to allow multiple vectors to compose. Both reductions and scans can be usefully be segmented, again with carry-in and carry-out. Segmented operations are useful for fast group-by modes of operation, and also for vectorized parsing, such as var-ints or even text. Compress and expand are independent primitives, both driven by masks; such masks can as noted above be related to segmentation masks.) > > It should be possible to create a shuffle from a Rearrange operator, with and without a mask so the equivalent functionality can be applied to a shuffle accepting rearrange e.g, for COMPRESS: > > rearrange(Shuffle.fromRearrangeOp(COMPRESS, mask), mask.prefix()) > Or > rearrange(Shuffle.fromRearrangeOp(COMPRESS, mask), zero()) > // Postfix of exceptional lanes in the shuffle, representing unset lanes I?m not following this, because I?m having trouble imagining ops like ADD and MAX here, as well as imagining COMPRESS as a VO. (I must be missing something crucial here.) > > For this to be of benefit we would need to come up with other realistic Rearrange operators, even if we do not add them right now e.g. IOTA, REVERSE, PARTITION_TRUE, PARTITION_FALSE, INTERLEAVE. I guess what I?m missing is this is a whole new kind of OP, not a lanewise one. Probably should live on Shuffle, since VOs is documented to be about lanewise ops only. > However, the design is a little awkward since the mask may or may not contribute to cross-lane movement, and so the operator needs to state the equivalence. > > In effect the Rearrange operator is a mechanism to refer to certain kinds of shuffle as a constant. Yes, and you are exploring the space of plausible constants. I think they (or at least some of them) could also factorized as *families* of constants, indexed by masks. > Ideally I would still prefer if we could implicitly identify what would otherwise be rearrange operators based on the creation of shuffles with known content e.g. can C2 somehow tag a shuffle instance with an ID of COMPRESS with a dependency on the mask used for its creation? Siting the compress (and expand!) functionality on shuffle instead of vector is a nice story, but I think it?s better to site it on general vectors, as distinct from shuffling, because of its relation to segmented data-parallel operations (which are distinct from permutations, since they never swap the order of selected lanes). So, I see three primitive notions: Segmentation, compress/expand, and permutation. You can bridge to and from permutation simply by working with index vectors like iota, and perhaps (as sugar) lifting selected vector operations to shuffles. > > ? > > FWIW another way to think about a partitioning/compression shuffle: > > SPECIES.iota().compress(m); Yes, that?s the bridging I just mentioned. Some applications would expand as well as compress. (I know it?s a one-way street for SVE and maybe others but fear not; expand is easier to implement than compress, using a plain permutation.) For example, if parsing a file of var-ints does segmentation (based on (lane&0x80)=0x80 masking) and subsequent compression to 32-bit integer lanes, the reverse operation of un-parsing would use an expansion of 32-bit integer lanes, to be reduced to bytes and stored to the var-int file. > > Which is just specific way of shuffling a shuffle. We could actually track the kinds of shuffle as final fields of the VectorShuffle implementation. Yes. If a machine lacks a compress and/or expand operation, we?d want Java paths that would compute appropriate shuffles and then apply them, with constant folding when appropriate. (Although masks are usually not constant.) Sketch of algorithm to derive a compression shuffle from a mask: Take VLENGTH=5 just for example and suppose we want to compress <4:v, 3:w, 2:x, 1:y, 0:z> with mask 0b01001. The desired output is then <0,0,0,w,z>. 1. For each masked lane (in a fresh index vector) compute the number of masked lanes at lower indexes. For example, <2, 1, 1, 1, 0> from 0b01001. This can be done in log time, and hardware can sometimes help. The operation naturally yields popcnt(m) (2 in the example) as a carry-out from a log-scan. Note that the lowest lane always gets zero. Variants of this algorithm might use a carry-in to put something other than zero there. Note also that the resulting index vector, used to shuffle the input vector, performs an *expand* which is the inverse of the compress we are seeking. 2. (Optional but useful.) Compute a complementary second fresh index vector from the inverted mask, added to the bit-count of the first mask. For example, <2, 2, 1, 0, 0> from 0x10110 (~0b01001), and then (adding the bitcount 2) <4, 4, 3, 2, 2>. Note that this index vector would perform an expand, to the left-hand (high) side of the vector, of the vector we are trying to compress. 3. Under the mask, blend the index vector from step 1 with that of step 2, or with a constant vector of value VLENGTH-1. For example, blending from 0b01001, either <4, 1, 3, 2, 0> or (lacking step 2) <4, 1, 4, 4, 0>. 4. Create an in-memory buffer of the same size and shape as the vector to be reduced. Use the blended index to perform an indexed store from the input vector to the memory buffer. This uses the hardware memory store operation, on a temp buffer, to create the desired compress. (It should be done in the VPU not in the MU, of course, but sometimes this might be the best way.) 5. Load the buffer back into a vector register, and set the unselected lanes to whatever value is desired, either zero, or (perhaps) a left-packed set of the non-compressed values. (This is called the SAG or ?sheep and goats? operation, when applied to a bit-vector, and it is very useful for other vectors as well.) Step 2 may be desirable even if you are not doing a SAG, if the indexed store hardware will go slower due to collisions on the last lane (index 4 in the example; note that only that index gets repeated). Note that steps 1 and 2 can be done in superscalar parallel. If step 2 is done with a from-left scan, there is no need to add in the correction value, of popcnt(m). I don?t know a great way to avoid a trip to a memory buffer, if the hardware does not supply a compress operation in the VPU. But here?s an almost-great way: 4b. Having computed the non-colliding permutation vector E (in steps 2 and 3, as if for SAG), use math to compute the inverse permutation vector C. E is an expansion as noted above while its inverse C is the corresponding compression. In the running example, E is <4, 1, 3, 2, 0> and its inverse C will be <4, 2, 1, 3, 0>. 5b. Use the standard shuffle (permutation) operation to reorder the input vector. Adjust uncompressed fields appropriately if SAG is not desired (zero them using the mask or whatever). 4b. Math details: Sort the merged E so as to transform it into the iota vector, while performing *exactly the same* swaps and reorderings on an iota vector. As E sorts to iota, the other copy of iota reorders to C. Perhaps the easiest way to do this is to create an index vector A with double-width lanes, and pack each lane A[i] with (E[i] * VLENGTH + i). (The ?+i? is ?+iota[i]?.) The double-width lanes of A are ?packets? to be ?routed? to the ?addresses? in the high half of the lane, and the ?payload? of each packet is the eventual index in C. Butterfly network, aka binary radix sort, will do the job in log time. (Hey hardware vendors, wouldn?t it be nice to supply us users with a keyed sort operation, which takes a vector of ?addresses? and a different vector of ?values? and reorders the ?values? according to the sorted order of the ?addresses?? That is the proper inverse to shuffle/permute primitives. You?d build a keyed routing network in silicon much like the ones that implement shuffle/permute.) 5c. The step 5a can be merged into 4b in some cases, if the original input vector lanes are small enough to fit into the ?packets? in the A vector being sorted in 4b. In that case, there?s no need to finish with a shuffle/permutation, since the actual data has already been moved where it belongs. All you need to do is strip off the ?address headers? of the ?packets?, by means of a reshaping truncation. This shows that a possible primitive is the anti-shuffle. (Anti-permutation.) Anti-shuffle is to shuffle as store is to load. Store is harder than load because where load has duplications store has collisions. Collisions probably want to be handled with reduction operations. (This takes me back to my Connection Machine and C* days? The C* operation p->n += x causes each processor?s x value to be applied as an increment to the n value on each friend processor p, where p is basically a pointer as in C. The operations take place in an indeterminate order but all x values are summed into each distinct n variable. Also, ?int y = p->n += x? captures partial sums, so it?s a scan. It?s all ?as if? executed sequentially, but in fact executes in log time, like vector reductions and permutations.) An anti-shuffle is really a 1-1 permutation (to the expanded ?collision buckets? in order), followed by a segmented reduction, followed by a compress. So (this is brainstorming!) the anti-shuffle is really another way to dress up the other primitives I?m discussing. Ideas of the morning; HTH? :-) From john.r.rose at oracle.com Thu Sep 2 18:36:17 2021 From: john.r.rose at oracle.com (John Rose) Date: Thu, 2 Sep 2021 18:36:17 +0000 Subject: [vectorIntrinsics+mask] RFR: 8273057: [vector] New VectorAPI "SelectiveStore" In-Reply-To: <052037EA-7C1F-4105-B14D-EC8212EC29C8@oracle.com> References: <0A62FA43-000C-4033-96DD-EB153826D2DF@oracle.com> <052037EA-7C1F-4105-B14D-EC8212EC29C8@oracle.com> Message-ID: <4994CF72-5CBD-4691-B9A4-FC361B287E52@oracle.com> On Aug 31, 2021, at 9:44 AM, Paul Sandoz > wrote: Yes, my suggestion is that a vector-to-vector compress might be a composition of mask -> partitioning shuffle -> rearrange, such that on supported architectures it reduces down to a single instruction. In combination with a store and prefix mask it may be possible to reduce further to single instruction accepting the source vector, mask, and a memory location. As I argued in my previous, it may be just as well to think of compress as its own primitive, even if under the covers it is implemented using shuffle. I think it?s worth thinking more about anti-shuffle, what that would be like. Mathematical permutations do not come in two kinds, but shuffles and anti-shuffles are distinct because only the former duplicate and only the latter collide. From john.r.rose at oracle.com Thu Sep 2 18:41:18 2021 From: john.r.rose at oracle.com (John Rose) Date: Thu, 2 Sep 2021 18:41:18 +0000 Subject: [vectorIntrinsics+mask] RFR: 8273057: [vector] New VectorAPI "SelectiveStore" In-Reply-To: References: <4556C43C-6DB8-4DFE-BA9F-0725D7939189@oracle.com> Message-ID: <694CDA27-D713-4ECF-AFA6-D854B6B73FA3@oracle.com> On Sep 2, 2021, at 11:33 AM, John Rose > wrote: The double-width lanes of A are ?packets? to be ?routed? to the ?addresses? in the high half of the lane, and the ?payload? of each packet is the eventual index in C. Butterfly network, aka binary radix sort, will do the job in log time. I forgot to point out that some hardware has min/max operations which can perform the conditional swap efficiently. So log(VLENGTH) mix/max swaps, plus classic butterfly-like shuffles to bring the pairs into proximity as needed, does the job as well. Also, these ?packets? were, back in the day, literal bit-serial packets on the Connection Machine, with up to 16-bit addresses. The microcode would worm the data around simultaneously through a hypercube network, getting the job done in log time. The weakness of the scheme is, of course, implementing the binary N-cube network in 3-space. Eventually you run out of places to put the wires. From mail at smogura.eu Thu Sep 2 18:45:17 2021 From: mail at smogura.eu (Rado Smogura) Date: Thu, 2 Sep 2021 20:45:17 +0200 Subject: How To Create Array of Structs? In-Reply-To: References: <0c6361f3-2879-02dd-0b26-e26a5b268602@oracle.com> <4bb60084-2958-45f9-511d-638b85770040@oracle.com> Message-ID: Hi Michael, That's a great question. Looking at Vulkan docs and source code [1] the VK_DEFINE_NON_DISPATCHABLE_HANDLE is typedef to semaphore struct pointer, so VkSemaphore is already pointer. In order to create semaphore you should call vkCreateSemaphore ([2]) and pass the pointer to this pointer. So, you have to allocate pointer type from Java and pass an address to vkCreateSemaphore. I guess vkCreateSemaphore does memory allocation on its own, and as well initializes memory behind pointer (that's quite common approach). I've found C example here [3] - I guess you already have seen it. I hope I could help, Rado [1] https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_DEFINE_NON_DISPATCHABLE_HANDLE.html [2] https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/vkCreateSemaphore.html [3] https://vulkan-tutorial.com/Drawing_a_triangle/Drawing/Rendering_and_presentation On 02.09.2021 20:16, Michael Ennen wrote: > Quick question that is now happening while trying to replicate the fix when > I don't have an explicit struct handle like in the case of VkSemaphore: > > https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VkSemaphore.html > > For those types I don't have a struct layout to work with so I have been > just declaring a double pointer: > > var pVkPipeline = > SegmentAllocator.ofScope(scope).allocate(C_POINTER.byteSize()); > > and then using MemoryAccess.getAddress(pVkPipeline). > > So in this case how can I create an array of VkSemaphore structs without > knowing anything about the struct (it is an opaque handle?). > > Hope that makes sense. > > On Thu, Sep 2, 2021 at 11:06 AM Michael Ennen wrote: > >> Jorn, >> >> Thank you so much - that was exactly what I was looking for. I don't know >> why I had such trouble trying to create an array of structs rather than an >> array of points to structs. >> >> Thank you both. >> >> On Thu, Sep 2, 2021 at 4:54 AM Jorn Vernee wrote: >> >>> Additionally, it looks like you're allocating an array of pointers for >>> pStages, and it looks like the API expects an array of structs. >>> >>> Instead of allocating the different VkPipelineShaderStageCreateInfo >>> individually, you should allocate the array of struct upfront, and then >>> fill in the different structs in-place. >>> >>> Like: >>> >>> diff --git a/src/main/java/com/brcolow/game/Vulkan.java >>> b/src/main/java/com/brcolow/game/Vulkan.java >>> index f0cd278..520513b 100644 >>> --- a/src/main/java/com/brcolow/game/Vulkan.java >>> +++ b/src/main/java/com/brcolow/game/Vulkan.java >>> @@ -429,17 +429,17 @@ public class Vulkan { >>> var pVertShaderModule = >>> getShaderModule(MemoryAccess.getAddress(pVkDevice), vertShaderBytes, >>> scope); >>> var pFragShaderModule = >>> getShaderModule(MemoryAccess.getAddress(pVkDevice), fragShaderBytes, >>> scope); >>> >>> - var pVertShaderStageInfo = >>> VkPipelineShaderStageCreateInfo.allocate(scope); >>> - VkPipelineShaderStageCreateInfo.sType$set(pVertShaderStageInfo, >>> vulkan_h.VK_STRUCTURE_TYPE_PIPELINE_SHADER_STAGE_CREATE_INFO()); >>> - VkPipelineShaderStageCreateInfo.stage$set(pVertShaderStageInfo, >>> vulkan_h.VK_SHADER_STAGE_VERTEX_BIT()); >>> - VkPipelineShaderStageCreateInfo.module$set(pVertShaderStageInfo, >>> MemoryAccess.getAddress(pVertShaderModule)); >>> - VkPipelineShaderStageCreateInfo.pName$set(pVertShaderStageInfo, >>> CLinker.toCString("main", scope).address()); >>> - >>> - var pFragShaderStageInfo = >>> VkPipelineShaderStageCreateInfo.allocate(scope); >>> - VkPipelineShaderStageCreateInfo.sType$set(pFragShaderStageInfo, >>> vulkan_h.VK_STRUCTURE_TYPE_PIPELINE_SHADER_STAGE_CREATE_INFO()); >>> - VkPipelineShaderStageCreateInfo.stage$set(pFragShaderStageInfo, >>> vulkan_h.VK_SHADER_STAGE_FRAGMENT_BIT()); >>> - VkPipelineShaderStageCreateInfo.module$set(pFragShaderStageInfo, >>> MemoryAccess.getAddress(pFragShaderModule)); >>> - VkPipelineShaderStageCreateInfo.pName$set(pFragShaderStageInfo, >>> CLinker.toCString("main", scope).address()); >>> + MemorySegment pStages = >>> SegmentAllocator.ofScope(scope).allocateArray(VkPipelineShaderStageCreateInfo.$LAYOUT(), >>> >>> 2); >>> + >>> + VkPipelineShaderStageCreateInfo.sType$set(pStages, 0, >>> vulkan_h.VK_STRUCTURE_TYPE_PIPELINE_SHADER_STAGE_CREATE_INFO()); >>> + VkPipelineShaderStageCreateInfo.stage$set(pStages, 0, >>> vulkan_h.VK_SHADER_STAGE_VERTEX_BIT()); >>> + VkPipelineShaderStageCreateInfo.module$set(pStages, 0, >>> MemoryAccess.getAddress(pVertShaderModule)); >>> + VkPipelineShaderStageCreateInfo.pName$set(pStages, 0, >>> CLinker.toCString("main", scope).address()); >>> + >>> + VkPipelineShaderStageCreateInfo.sType$set(pStages, 1, >>> vulkan_h.VK_STRUCTURE_TYPE_PIPELINE_SHADER_STAGE_CREATE_INFO()); >>> + VkPipelineShaderStageCreateInfo.stage$set(pStages, 1, >>> vulkan_h.VK_SHADER_STAGE_FRAGMENT_BIT()); >>> + VkPipelineShaderStageCreateInfo.module$set(pStages, 1, >>> MemoryAccess.getAddress(pFragShaderModule)); >>> + VkPipelineShaderStageCreateInfo.pName$set(pStages, 1, >>> CLinker.toCString("main", scope).address()); >>> >>> var pVertexInputStateInfo = >>> VkPipelineVertexInputStateCreateInfo.allocate(scope); >>> VkPipelineVertexInputStateCreateInfo.sType$set(pVertexInputStateInfo, >>> vulkan_h.VK_STRUCTURE_TYPE_PIPELINE_VERTEX_INPUT_STATE_CREATE_INFO()); >>> @@ -581,16 +581,14 @@ public class Vulkan { >>> // If we change stageCount to 2 we get a crash.... >>> // I think we are creating the pStages array incorrectly. >>> This is also manifesting further down when trying >>> // to create arrays pWaitSemaphores, pSignalSemaphores, etc. >>> - VkGraphicsPipelineCreateInfo.stageCount$set(pPipelineCreateInfo, 1); >>> - MemorySegment pStages = >>> SegmentAllocator.ofScope(scope).allocateArray(C_POINTER, new >>> Addressable[]{ >>> - pVertShaderStageInfo, pFragShaderStageInfo}); >>> - System.out.println("pStages: " + pStages); >>> - System.out.println("pStages[0]: " + >>> VkPipelineShaderStageCreateInfo.ofAddress(MemoryAccess.getAddressAtIndex(pStages, >>> >>> 0), scope)); >>> - System.out.println("pStages[0].sType: " + >>> VkPipelineShaderStageCreateInfo.sType$get(VkPipelineShaderStageCreateInfo.ofAddress(MemoryAccess.getAddressAtIndex(pStages, >>> >>> 0), scope))); >>> - System.out.println("pStages[1]: " + >>> VkPipelineShaderStageCreateInfo.ofAddress(MemoryAccess.getAddressAtIndex(pStages, >>> >>> 1), scope)); >>> - System.out.println("pStages[1].sType: " + >>> VkPipelineShaderStageCreateInfo.sType$get(VkPipelineShaderStageCreateInfo.ofAddress(MemoryAccess.getAddressAtIndex(pStages, >>> >>> 1), scope))); >>> - >>> - VkGraphicsPipelineCreateInfo.pStages$set(pPipelineCreateInfo, >>> MemoryAccess.getAddress(pStages)); >>> + VkGraphicsPipelineCreateInfo.stageCount$set(pPipelineCreateInfo, 2); >>> + System.out.println("pStages: " + pStages.address()); >>> + System.out.println("pStages[0]: " + pStages.asSlice(0, >>> VkPipelineShaderStageCreateInfo.$LAYOUT().byteSize())); >>> + System.out.println("pStages[0].sType: " + >>> VkPipelineShaderStageCreateInfo.sType$get(pStages, 0)); >>> + System.out.println("pStages[1]: " + >>> pStages.asSlice(VkPipelineShaderStageCreateInfo.$LAYOUT().byteSize(), >>> VkPipelineShaderStageCreateInfo.$LAYOUT().byteSize())); >>> + System.out.println("pStages[1].sType: " + >>> VkPipelineShaderStageCreateInfo.sType$get(pStages, 1)); >>> + >>> + VkGraphicsPipelineCreateInfo.pStages$set(pPipelineCreateInfo, >>> pStages.address()); >>> VkGraphicsPipelineCreateInfo.pVertexInputState$set(pPipelineCreateInfo, >>> pVertexInputStateInfo.address()); >>> VkGraphicsPipelineCreateInfo.pInputAssemblyState$set(pPipelineCreateInfo, >>> pPipelineInputAssemblyStateInfo.address()); >>> VkGraphicsPipelineCreateInfo.pViewportState$set(pPipelineCreateInfo, >>> pPipelineViewportStateInfo.address()); >>> >>> HTH, >>> Jorn >>> >>> On 02/09/2021 11:56, Maurizio Cimadamore wrote: >>>> Hi Michael, >>>> very interesting experiments - thanks for reaching out. >>>> >>>> Eyeballing your code, I zoomed into this line: >>>> >>>> >>> https://github.com/brcolow/java-vulkan/blob/master/src/main/java/com/brcolow/game/Vulkan.java#L593 >>>> >>>> Here you want to set the `pStages` pointer, a pointer to a memory >>>> region which presumably has to contain exactly `stageCount` structs of >>>> type `VkPipelineShaderStageCreateInfo`. >>>> >>>> I believe there's an extra getAddress in there; this: >>>> >>>> ``` >>>> VkGraphicsPipelineCreateInfo.pStages$set(pPipelineCreateInfo, >>>> MemoryAccess.getAddress(pStages)); >>>> ``` >>>> >>>> should be: >>>> >>>> ``` >>>> VkGraphicsPipelineCreateInfo.pStages$set(pPipelineCreateInfo, pStages); >>>> ``` >>>> >>>> That is, you want to pass the pointer to the `pStages` region you just >>>> created, so that Vulkan will be able to see all elements. If you call >>>> "MemoryAccess::getAddress" your code will read the first 64 bits from >>>> the `pStages` region, turn those into a MemoryAddress, and set that >>>> into the enclosing `pPipelineCreateInfo` struct. Which I don't think >>>> is what you want? >>>> >>>> Let me know if this works. >>>> >>>> Cheers >>>> Maurizio >>>> >>>> >>>> On 02/09/2021 06:35, Michael Ennen wrote: >>>>> I have been doing more exploring with the panama-foreign, ffi, and >>>>> jextract >>>>> branches - this time messing around with seeing if I can get a rainbow >>>>> triangle to be rendered on the screen with Vulkan. >>>>> >>>>> I am really close. There is one problem I am having which is how to >>>>> create >>>>> an array of structs? >>>>> >>>>> See this, for example: >>>>> >>>>> >>> https://github.com/brcolow/java-vulkan/blob/master/src/main/java/com/brcolow/game/Vulkan.java#L581 >>>>> >>>>> If I set the stageCount to 2, then I get a validation exception about >>>>> the >>>>> second shader module having bogus values. I believe this is caused by >>> me >>>>> creating the array of structs incorrectly. >>>>> >>>>> I am trying to set the pStages element of this struct: >>>>> >>> https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VkGraphicsPipelineCreateInfo.html >>>>> >>>>> to an array containing pVertShaderStageInfo and pFragShaderStageInfo. >>>>> >>>>> My attempt (I have tried other ways that also fail) to do that is: >>>>> >>>>> MemorySegment pStages = SegmentAllocator.ofScope(scope).allocateArray( >>>>> C_POINTER, new Addressable[]{ >>>>> pVertShaderStageInfo, pFragShaderStageInfo}); >>>>> VkGraphicsPipelineCreateInfo.pStages$set(pPipelineCreateInfo, >>>>> MemoryAccess.getAddress(pStages)); >>>>> >>>>> >>>>> If anyone could assist me with the proper way to create the >>>>> VkPipelineShaderStageCreateInfo* array containing >>>>> pVertShaderStageInfoand >>>>> pFragShaderStageInfo - it would be greatly appreciated! >>>>> >> >> -- >> Michael Ennen >> > From mail at smogura.eu Thu Sep 2 19:53:38 2021 From: mail at smogura.eu (Rado Smogura) Date: Thu, 2 Sep 2021 21:53:38 +0200 Subject: [External] : Re: Issues with loop unrolling: better pinned node In-Reply-To: <3f7dd833-f632-9b3d-0713-37e78f5de928@oracle.com> References: <9F21B2BF-E94F-4332-A5A4-DEDA05D1802C@oracle.com> <19C617EE-6745-4DA3-A5AE-674E92F7DAA4@oracle.com> <14e30959-d990-2180-f23d-a05c88ec7899@smogura.eu> <3f7dd833-f632-9b3d-0713-37e78f5de928@oracle.com> Message-ID: Hi Vladimir, Thank you for feedback. There was one idea I had previously and I added it here (I surprised it works): * add additional filed TypeTuple _multi_load_adr to Node and set it in mixed mode, * in anti-deps add external loop to do analysis for every address from this tuple Minor changes: * pass this field to mach node; * in anti-deps load node has to traverse memory chain (normally this is done in Ideal). I checked it with mixed "mode" operating on int and byte vectors and I see storeV (raw / byte[]) gets anit-dep to loadV (raw/int[]), and same for storeV(raw/byte[]) - so that's good - as there's interference over raw. https://github.com/openjdk/panama-vector/compare/vectorIntrinsics+mask...rsmogura:mixed-mode-use-bot-mem-opt-antideps?expand=1 Kind regards, Rado On 01.09.2021 15:22, Vladimir Ivanov wrote: > Interesting idea, Rado! Representing memory effects of > mixed/mismatched accesses with TypePtr::BOTTOM does look promising. > > Regarding the preferred IR shapes, I'd try to teach alias analysis > (Compile::find_alias_type()) and PhaseCFG::insert_anti_dependences() > about loads/stores on wide memory (TypePtr::BOTTOM) and see what kind > of problems arise to decide how to proceed. I hope there's a way to > avoid dummy nodes when representing desired effects. > > Best regards, > Vladimir Ivanov > > On 30.08.2021 18:12, Rado Smogura wrote: >> Hi all, >> >> >> I added one missing thing. I want to build something like this. Would >> it make sense? >> >> >> ??? STORE >> >> >> ??????????????????????????????? addr >> ????????????????????????????????? ? >> ????????????????????????????????? ? >> ????????? reset_memory()????????? ? >> ???????????? ???? ?????????????????????????? >> ???????????? ???? ? CheckCastPP (-> BOT)?? ? >> ???????????? ???? ?????????????????????????? >> ???????????? ??????????? ? >> ???????????? ??????????? ? >> ???????????? ??????? ??? ? >> ???????????? ??????? ??? ? >> ???????????? ?? ????????????????????????????????????? >> ???????????? ?? ???????????? StoreVector??????????? ? >> ???????????? ?? ????????????????????????????????????? >> ???????????? ?????? ??????????????????????????? ? >> ???????????? ?????? ??????????????????????????? ? >> ?????????????????????????????????????????????????????????????????? >> ??????????? ? BOT? RAW byte[]????????????????????????? ? >> ??????????? ? MergeMem??????????????????????????????????????? ? >> ?????????????????????????????????????????????????????????????????? >> >> >> >> ???? LOAD >> >> ????????????? ? >> ????????????? ? >> ????????????? ??????????? >> ????????????? ????????? ? >> ????????????? ? >> ??????????????????????????????????????????????????????????????? >> ????????????? ? ? LoadVector >> (BOT)??????????????????????????????????????????? ? >> ????????????? ? >> ??????????????????????????????????????????????????????????????? >> ????????????? ????????????????????????? ? ? >> ????????????? ????? addr base -> raw ????????????????????????? ???? >> addr base -> byte[] >> ????????????? ????????????????????????? ? ? >> ????????????? ??????????? ????????????????????????? >> ????????????????????????? >> ????????????? ??????????? ?DummyStoreV (raw)????? ? ?DummyStoreV >> (byte[])?? ? //No-op stores >> ????????????? ??????????? ????????????????????????? >> ????????????????????????? >> ????????????? ?????????????????? ??????????????????????? ? >> ????????????? ????? ?????????????????????????? ??????????? >> ????????????? ????? ?????????????????????????? ? >> ??????????????????????????????????????????????????????????????????? >> ??????????? ? BOT? RAW byte[]?????????????????????????? ? >> ??????????? ? MergeMem???????????????????????????????????????? ? >> ??????????????????????????????????????????????????????????????????? >> >> >> DummyStore is "virtual" node inserted after load, intended to emulate >> store, and prevent writes / reads to go on the side of load vector >> (it fact it more prevents store / load to see through mem-memrge). >> >> I did test it with following code. >> >> public static void copyMemoryBytes3(ByteBuffer in, ByteBuffer out, >> ByteBuffer out2,byte[] arr) { >> ???? for (int i=0; i > +=SPECIES_BYTE.vectorByteSize()) { >> ???????? var v1 = ByteVector.fromByteBuffer(SPECIES_BYTE, in, i, >> ByteOrder.nativeOrder()); >> ???????? arr[i] = (byte) i; >> ???????? var v2 = ByteVector.fromByteBuffer(SPECIES_BYTE, out, i, >> ByteOrder.nativeOrder()); >> ???????? v1.intoByteBuffer(out, i, ByteOrder.nativeOrder()); >> ???? } >> } >> >> Kind regards, >> >> Rado >> >> On 27.08.2021 20:16, Rado Smogura wrote: >>> Hi all, >>> >>> >>> I experimented a little bit, and I wonder if this is reasonable, the >>> outcome on graphs is as expected, and operations looks like properly >>> ordered (but this is my private opinion). >>> >>> https://urldefense.com/v3/__https://github.com/rsmogura/panama-vector/commit/755b62823aaed0cddf78e8ccfc60c063bb40779a__;!!ACWV5N9M2RV99hQ!ceve5Eoh01VSiAxgPOSMpL_oQpz6MJI6KeGEcvULButhjMZGdxMq2SB02arX5hxVvmWp1wY$ >>> >>> >>> Kind regards, >>> >>> Rado >>> >>> On 19.08.2021 22:26, Rado Smogura wrote: >>>> I think I answered this question quite simply... it will not work. >>>> >>>> On 19.08.2021 18:39, Rado Smogura wrote: >>>>> Hi all, >>>>> >>>>> >>>>> I hope you have a good day. >>>>> >>>>> >>>>> As still optimizing loops would be good approach, I thought about >>>>> optimizing a mixed access with this approach: >>>>> >>>>> >>>>> 1. When mixed access is detected set flag "raw / byte array" mixed >>>>> access. >>>>> >>>>> 2. Bail out and restart compilation (will happen during first >>>>> phases, and only for few methods). >>>>> >>>>> 3. Pass a flag to compiler. >>>>> >>>>> 4. Modify find_alias_type / flatten_alias_type, so that if byte >>>>> array will be queried for alias, raw ptr and raw alias will be used. >>>>> >>>>> >>>>> Kind regards, >>>>> >>>>> Rado >>>>> >>>>> On 18.08.2021 09:17, Rado Smogura wrote: >>>>>> Hi Vladimir, >>>>>> >>>>>> >>>>>> Thank you for answer. >>>>>> >>>>>> >>>>>> In fact, it is was an attempt to confirm that memory flow can be >>>>>> a cause why loop opts do not work. That's very fair point. I'll >>>>>> think about it and maybe I'll be able to come out idea how this >>>>>> can be generalized. >>>>>> >>>>>> >>>>>> Kind regards, >>>>>> >>>>>> Rado >>>>>> >>>>>> On 16.08.2021 15:41, Vladimir Ivanov wrote: >>>>>>>> I wonder what do you think about something like this [1] - it's >>>>>>>> virtually small single class change >>>>>>> >>>>>>> Very interesting experiment, Rado! It's encouraging to hear that >>>>>>> loop opts immediately benefit from it. >>>>>>> >>>>>>> From a architectural perspective, a separate pass to optimize >>>>>>> memory graph brings excessive complexity: >>>>>>> >>>>>>> ? (1) yet another pass over the graph and susceptible to pass >>>>>>> ordering issues; >>>>>>> >>>>>>> ? (2) separate from GVN: you either have to duplicate GVN-based >>>>>>> memory optimizations or run new pass with IGVN in a loop until >>>>>>> it stabilizes. >>>>>>> >>>>>>> IMO the problem you noticed illustrates a general weakness in >>>>>>> GVN implementation and that's the place where it should be fixed >>>>>>> (ideally). >>>>>>> >>>>>>> Best regards, >>>>>>> Vladimir Ivanov >>>>>>> >>>>>>>> >>>>>>>> This change tries to find unique memory for load node. I >>>>>>>> implemented it as separate phase, as optimization may not run >>>>>>>> in Ideal method. I think it's ligher than phi split out. >>>>>>>> >>>>>>>> Loops has been transformed. RCE started. >>>>>>>> >>>>>>>> Kind regards, >>>>>>>> Rado >>>>>>>> >>>>>>>> [1] - >>>>>>>> https://urldefense.com/v3/__https://github.com/rsmogura/panama-vector/commit/a44f515890d2c4df3fd0e0ced76545a7664926c3__;!!ACWV5N9M2RV99hQ!ceve5Eoh01VSiAxgPOSMpL_oQpz6MJI6KeGEcvULButhjMZGdxMq2SB02arX5hxVLT5AsEE$ >>>>>>>> >>>>>>>> >>>>>>>> [2] - >>>>>>>> https://urldefense.com/v3/__https://github.com/rsmogura/panama-vector/tree/housekeeping-load-memory-optimiziation__;!!ACWV5N9M2RV99hQ!ceve5Eoh01VSiAxgPOSMpL_oQpz6MJI6KeGEcvULButhjMZGdxMq2SB02arX5hxVcBkmVi0$ >>>>>>>> >>>>>>>> (full test case) >>>>>>>> >>>>>>>> ------------------------------------------------------------------------ >>>>>>>> >>>>>>>> *From:* Rados?aw Smogura on behalf of Rados?aw Smogura >>>>>>>> >>>>>>>> *Sent:* Friday, August 6, 2021 22:43 >>>>>>>> *To:* Rados?aw Smogura ; Paul Sandoz >>>>>>>> ; Vladimir Ivanov >>>>>>>> >>>>>>>> *Cc:* panama-dev at openjdk.java.net >>>>>>>> *Subject:* Re: Issues with loop unrolling: better pinned node >>>>>>>> Hi all, >>>>>>>> >>>>>>>> Now when I checked it again. it works as expected, and it's the >>>>>>>> same code. >>>>>>>> >>>>>>>> In draft code I check if the buffer is direct by using type >>>>>>>> checking to unswitch loop, as unswitching over ByteBuffer.hb >>>>>>>> did not work (the graph was quite similar). However, I thought >>>>>>>> that this unswitch actually helped to build correct loops, and >>>>>>>> any kind of improvement around it would be rather for the >>>>>>>> purpose of better-looking code. >>>>>>>> >>>>>>>> But it looks like that sometimes (but only sometimes) loop >>>>>>>> still can not be correctly built, or maybe the full >>>>>>>> optimization kicks in very, very late. >>>>>>>> >>>>>>>> Kind regards, >>>>>>>> Rado >>>>>>>> ------------------------------------------------------------------------ >>>>>>>> >>>>>>>> *From:* panama-dev on behalf >>>>>>>> of Rados?aw Smogura >>>>>>>> *Sent:* Friday, August 6, 2021 20:22 >>>>>>>> *To:* Paul Sandoz >>>>>>>> *Cc:* panama-dev at openjdk.java.net >>>>>>>> *Subject:* Re: Issues with loop unrolling: better pinned node >>>>>>>> Yes, >>>>>>>> >>>>>>>> The normal case looks, good. It's all about polluted cases [1] >>>>>>>> >>>>>>>> BR, >>>>>>>> Rado >>>>>>>> >>>>>>>> [1] >>>>>>>> https://urldefense.com/v3/__https://github.com/openjdk/panama-vector/pull/109__;!!ACWV5N9M2RV99hQ!ceve5Eoh01VSiAxgPOSMpL_oQpz6MJI6KeGEcvULButhjMZGdxMq2SB02arX5hxVfxQRu38$ >>>>>>>> >>>>>>>> >>>>>>>> [https://urldefense.com/v3/__https://opengraph.githubassets.com/daf8e3b93dd4c25e04d1ce6ae2a91e1b725625bfd85b5027c61fb78ae3a6a361/openjdk/panama-vector/pull/109__;!!ACWV5N9M2RV99hQ!ceve5Eoh01VSiAxgPOSMpL_oQpz6MJI6KeGEcvULButhjMZGdxMq2SB02arX5hxVmHZKrgY$ >>>>>>>> ]>>>>>>> > >>>>>>>> >>>>>>>> (Draft) Perofrmance improvements for polluted cases by rsmogura >>>>>>>> ? Pull Request #109 ? >>>>>>>> openjdk/panama-vector>>>>>>> > >>>>>>>> >>>>>>>> >>>>>>>> Hi all, I would like to submit this piece of work, for byte >>>>>>>> buffers and polluted cases. It resolves some performance issues >>>>>>>> related to mem barriers when in scope are both on- and off-heap >>>>>>>> buffer. T... >>>>>>>> github.com >>>>>>>> >>>>>>>> [https://urldefense.com/v3/__https://opengraph.githubassets.com/5fde12f89c012a2abef1542ed59c7272429fa7556f6e82a5e617a293d3a5bee1/openjdk/panama-vector__;!!ACWV5N9M2RV99hQ!ceve5Eoh01VSiAxgPOSMpL_oQpz6MJI6KeGEcvULButhjMZGdxMq2SB02arX5hxVLW0LAx0$ >>>>>>>> ]>>>>>>> > >>>>>>>> >>>>>>>> Comparing >>>>>>>> openjdk:vectorIntrinsics...rsmogura:vectors-polluted-cases ? >>>>>>>> openjdk/panama-vector>>>>>>> > >>>>>>>> >>>>>>>> >>>>>>>> Panama vector. Contribute to openjdk/panama-vector development >>>>>>>> by creating an account on GitHub. >>>>>>>> github.com >>>>>>>> >>>>>>>> ________________________________ >>>>>>>> From: Paul Sandoz >>>>>>>> Sent: Friday, August 6, 2021 20:04 >>>>>>>> To: Rados?aw Smogura >>>>>>>> Cc: panama-dev at openjdk.java.net >>>>>>>> Subject: Re: Issues with loop unrolling: better pinned node >>>>>>>> >>>>>>>> I am confused as to the case under test. In your initial email >>>>>>>> of this thread were you also referring implicitly to polluted >>>>>>>> cases? >>>>>>>> >>>>>>>> Paul. >>>>>>>> >>>>>>>>> On Aug 6, 2021, at 10:56 AM, Rados?aw Smogura >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Hi Paul, >>>>>>>>> >>>>>>>>> There's a performance improvement, but. I still can't unroll >>>>>>>>> polluted cases (I cherry-picked loop unrolling). The graph >>>>>>>>> still has few nodes taking buffer limit from phi, and on IR I >>>>>>>>> don't see vectors nodes cascading. >>>>>>>>> >>>>>>>>> make test TEST='micro:ByteBufferVectorAccess.p' >>>>>>>>> MICRO="OPTIONS=-f 1 -prof perfasm >>>>>>>>> -jvmArgsPrepend=-Djdk.incubator.vector.VECTOR_ACCESS_OOB_CHECK=0" >>>>>>>>> JOBS=12 >>>>>>>>> Benchmark (size) Mode Cnt Score?? Error? Units >>>>>>>>> ByteBufferVectorAccess.pollutedBuffers2 1024 avgt 30 40.472 ? >>>>>>>>> 1.055? ns/op >>>>>>>>> ByteBufferVectorAccess.pollutedBuffers2:?asm 1024 >>>>>>>>> avgt????????? NaN??????????? --- >>>>>>>>> ByteBufferVectorAccess.pollutedBuffers3 1024 avgt 30 79.251 ? >>>>>>>>> 0.786? ns/op >>>>>>>>> ByteBufferVectorAccess.pollutedBuffers3:?asm 1024 >>>>>>>>> avgt????????? NaN??????????? --- >>>>>>>>> ByteBufferVectorAccess.pollutedBuffers4 1024 avgt 30 83.627 ? >>>>>>>>> 2.140? ns/op >>>>>>>>> ByteBufferVectorAccess.pollutedBuffers4:?asm 1024 >>>>>>>>> avgt????????? NaN??????????? --- >>>>>>>>> ByteBufferVectorAccess.pollutedBuffers5 1024 avgt 30 85.561 ? >>>>>>>>> 1.156? ns/op >>>>>>>>> ByteBufferVectorAccess.pollutedBuffers5:?asm 1024 >>>>>>>>> avgt????????? NaN >>>>>>>>> >>>>>>>>> make test TEST='micro:ByteBufferVectorAccess.p' >>>>>>>>> MICRO="OPTIONS=-f 1 -prof perfasm" >>>>>>>>> Benchmark (size) Mode Cnt Score?? Error? Units >>>>>>>>> ByteBufferVectorAccess.pollutedBuffers2 1024 avgt 10 49.326 ? >>>>>>>>> 0.843? ns/op >>>>>>>>> ByteBufferVectorAccess.pollutedBuffers2:?asm 1024 >>>>>>>>> avgt?????????? NaN??????????? --- >>>>>>>>> ByteBufferVectorAccess.pollutedBuffers3 1024 avgt 10 100.291 ? >>>>>>>>> 1.271? ns/op >>>>>>>>> ByteBufferVectorAccess.pollutedBuffers3:?asm 1024 >>>>>>>>> avgt?????????? NaN??????????? --- >>>>>>>>> ByteBufferVectorAccess.pollutedBuffers4 1024 avgt 10 101.494 ? >>>>>>>>> 1.027? ns/op >>>>>>>>> ByteBufferVectorAccess.pollutedBuffers4:?asm 1024 >>>>>>>>> avgt?????????? NaN??????????? --- >>>>>>>>> ByteBufferVectorAccess.pollutedBuffers5 1024 avgt 10 94.606 ? >>>>>>>>> 1.522? ns/op >>>>>>>>> ByteBufferVectorAccess.pollutedBuffers5:?asm 1024 >>>>>>>>> avgt?????????? NaN >>>>>>>>> >>>>>>>>> >>>>>>>>> BR, >>>>>>>>> Rado >>>>>>>>> From: Paul Sandoz >>>>>>>>> Sent: Friday, August 6, 2021 18:04 >>>>>>>>> To: Rados?aw Smogura >>>>>>>>> Cc: panama-dev at openjdk.java.net >>>>>>>>> Subject: Re: Issues with loop unrolling: better pinned node >>>>>>>>> >>>>>>>>> Hi Rado, >>>>>>>>> >>>>>>>>> It?s good you are looking at the IR >>>>>>>>> >>>>>>>>> Out of curiosity, what happens if you turn off bounds checking >>>>>>>>> [*]? >>>>>>>>> >>>>>>>>> Paul. >>>>>>>>> >>>>>>>>> [*] >>>>>>>>> -Djdk.incubator.vector.VECTOR_ACCESS_OOB_CHECK=0 >>>>>>>>> >>>>>>>>> > On Aug 6, 2021, at 8:39 AM, Rados?aw Smogura >>>>>>>>> wrote: >>>>>>>>> > >>>>>>>>> > Hi all, >>>>>>>>> > >>>>>>>>> > I've found that even if we get rid of barriers, the loop >>>>>>>>> can't get unrolled, and not needed code is inside it. >>>>>>>>> > >>>>>>>>> > I've found this graph, I wonder if it's most optimal, in a >>>>>>>>> partiucalry Load of ByteBuffer index / hb is from phi, could >>>>>>>>> it be attached to initial memory? >>>>>>>>> > >>>>>>>>> > Here's a picture >>>>>>>>> https://urldefense.com/v3/__https://drive.google.com/file/d/1G7ZN0xHOVIVHmZ_5TTIUdm3F30okAzvO/view?usp=sharing__;!!ACWV5N9M2RV99hQ!ceve5Eoh01VSiAxgPOSMpL_oQpz6MJI6KeGEcvULButhjMZGdxMq2SB02arX5hxVkhhZ0w8$ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> > >>>>>>>>> [https://urldefense.com/v3/__https://lh6.googleusercontent.com/SKgGZgfVWFpG8w4mWqguLSU4DVfa1MKYPSQhxv8EoX04XzVz8U8Kc4zHP0iwdR26Suc=w1200-h630-p__;!!ACWV5N9M2RV99hQ!ceve5Eoh01VSiAxgPOSMpL_oQpz6MJI6KeGEcvULButhjMZGdxMq2SB02arX5hxVgkskdP0$ >>>>>>>>> ]>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> > >>>>>>>> >>>>>>>>> > >>>>>>>>> bb_issues.png>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> > >>>>>>>> >>>>>>>>> > drive.google.com >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > And sample code >>>>>>>>> > >>>>>>>>> > protected void copyMemory(ByteBuffer in, ByteBuffer out) { >>>>>>>>> >? var limit = SPECIES.loopBound(in.limit()); >>>>>>>>> >? for (int i=0; i < limit; i += SPECIES.vectorByteSize()) { >>>>>>>>> >??? final var v = ByteVector.fromByteBuffer(SPECIES, in, i, >>>>>>>>> ByteOrder.nativeOrder()); >>>>>>>>> >??? v.intoByteBuffer(out, i, ByteOrder.nativeOrder()); >>>>>>>>> >? } >>>>>>>>> > } >>>>>>>>> > >>>>>>>>> > Kind regards, >>>>>>>>> > Rado >>>>>>>> From maurizio.cimadamore at oracle.com Thu Sep 2 20:46:21 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 2 Sep 2021 21:46:21 +0100 Subject: How To Create Array of Structs? In-Reply-To: References: <0c6361f3-2879-02dd-0b26-e26a5b268602@oracle.com> <4bb60084-2958-45f9-511d-638b85770040@oracle.com> Message-ID: This is good info, thanks Rado. On a sidenote, it's a bit sad that jextract does not generate a layout for VkSemaphore - we will look into that. Cheers Maurizio On 02/09/2021 19:45, Rado Smogura wrote: > Hi Michael, > > > That's a great question. > > > Looking at Vulkan docs and source code [1] the > VK_DEFINE_NON_DISPATCHABLE_HANDLE is typedef to semaphore struct > pointer, so > > VkSemaphore is already pointer. In order to create semaphore you > should call vkCreateSemaphore ([2]) and pass the pointer to this pointer. > > > So, you have to allocate pointer type from Java and pass an address to > vkCreateSemaphore. I guess vkCreateSemaphore does memory allocation on > its own, and as well initializes memory behind pointer (that's quite > common approach). > > I've found C example here [3] - I guess you already have seen it. > > > I hope I could help, > > Rado > > > [1] > https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_DEFINE_NON_DISPATCHABLE_HANDLE.html > > [2] > https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/vkCreateSemaphore.html > > [3] > https://vulkan-tutorial.com/Drawing_a_triangle/Drawing/Rendering_and_presentation > > On 02.09.2021 20:16, Michael Ennen wrote: >> Quick question that is now happening while trying to replicate the >> fix when >> I don't have an explicit struct handle like in the case of VkSemaphore: >> >> https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VkSemaphore.html >> >> >> For those types I don't have a struct layout to work with so I have been >> just declaring a double pointer: >> >> var pVkPipeline = >> SegmentAllocator.ofScope(scope).allocate(C_POINTER.byteSize()); >> >> and then using MemoryAccess.getAddress(pVkPipeline). >> >> So in this case how can I create an array of VkSemaphore structs without >> knowing anything about the struct (it is an opaque handle?). >> >> Hope that makes sense. >> >> On Thu, Sep 2, 2021 at 11:06 AM Michael Ennen >> wrote: >> >>> Jorn, >>> >>> Thank you so much - that was exactly what I was looking for. I don't >>> know >>> why I had such trouble trying to create an array of structs rather >>> than an >>> array of points to structs. >>> >>> Thank you both. >>> >>> On Thu, Sep 2, 2021 at 4:54 AM Jorn Vernee >>> wrote: >>> >>>> Additionally, it looks like you're allocating an array of pointers for >>>> pStages, and it looks like the API expects an array of structs. >>>> >>>> Instead of allocating the different VkPipelineShaderStageCreateInfo >>>> individually, you should allocate the array of struct upfront, and >>>> then >>>> fill in the different structs in-place. >>>> >>>> Like: >>>> >>>> diff --git a/src/main/java/com/brcolow/game/Vulkan.java >>>> b/src/main/java/com/brcolow/game/Vulkan.java >>>> index f0cd278..520513b 100644 >>>> --- a/src/main/java/com/brcolow/game/Vulkan.java >>>> +++ b/src/main/java/com/brcolow/game/Vulkan.java >>>> @@ -429,17 +429,17 @@ public class Vulkan { >>>> ?????????????? var pVertShaderModule = >>>> getShaderModule(MemoryAccess.getAddress(pVkDevice), vertShaderBytes, >>>> scope); >>>> ?????????????? var pFragShaderModule = >>>> getShaderModule(MemoryAccess.getAddress(pVkDevice), fragShaderBytes, >>>> scope); >>>> >>>> -??????????? var pVertShaderStageInfo = >>>> VkPipelineShaderStageCreateInfo.allocate(scope); >>>> - VkPipelineShaderStageCreateInfo.sType$set(pVertShaderStageInfo, >>>> vulkan_h.VK_STRUCTURE_TYPE_PIPELINE_SHADER_STAGE_CREATE_INFO()); >>>> - VkPipelineShaderStageCreateInfo.stage$set(pVertShaderStageInfo, >>>> vulkan_h.VK_SHADER_STAGE_VERTEX_BIT()); >>>> - VkPipelineShaderStageCreateInfo.module$set(pVertShaderStageInfo, >>>> MemoryAccess.getAddress(pVertShaderModule)); >>>> - VkPipelineShaderStageCreateInfo.pName$set(pVertShaderStageInfo, >>>> CLinker.toCString("main", scope).address()); >>>> - >>>> -??????????? var pFragShaderStageInfo = >>>> VkPipelineShaderStageCreateInfo.allocate(scope); >>>> - VkPipelineShaderStageCreateInfo.sType$set(pFragShaderStageInfo, >>>> vulkan_h.VK_STRUCTURE_TYPE_PIPELINE_SHADER_STAGE_CREATE_INFO()); >>>> - VkPipelineShaderStageCreateInfo.stage$set(pFragShaderStageInfo, >>>> vulkan_h.VK_SHADER_STAGE_FRAGMENT_BIT()); >>>> - VkPipelineShaderStageCreateInfo.module$set(pFragShaderStageInfo, >>>> MemoryAccess.getAddress(pFragShaderModule)); >>>> - VkPipelineShaderStageCreateInfo.pName$set(pFragShaderStageInfo, >>>> CLinker.toCString("main", scope).address()); >>>> +??????????? MemorySegment pStages = >>>> SegmentAllocator.ofScope(scope).allocateArray(VkPipelineShaderStageCreateInfo.$LAYOUT(), >>>> >>>> >>>> 2); >>>> + >>>> + VkPipelineShaderStageCreateInfo.sType$set(pStages, 0, >>>> vulkan_h.VK_STRUCTURE_TYPE_PIPELINE_SHADER_STAGE_CREATE_INFO()); >>>> + VkPipelineShaderStageCreateInfo.stage$set(pStages, 0, >>>> vulkan_h.VK_SHADER_STAGE_VERTEX_BIT()); >>>> + VkPipelineShaderStageCreateInfo.module$set(pStages, 0, >>>> MemoryAccess.getAddress(pVertShaderModule)); >>>> + VkPipelineShaderStageCreateInfo.pName$set(pStages, 0, >>>> CLinker.toCString("main", scope).address()); >>>> + >>>> + VkPipelineShaderStageCreateInfo.sType$set(pStages, 1, >>>> vulkan_h.VK_STRUCTURE_TYPE_PIPELINE_SHADER_STAGE_CREATE_INFO()); >>>> + VkPipelineShaderStageCreateInfo.stage$set(pStages, 1, >>>> vulkan_h.VK_SHADER_STAGE_FRAGMENT_BIT()); >>>> + VkPipelineShaderStageCreateInfo.module$set(pStages, 1, >>>> MemoryAccess.getAddress(pFragShaderModule)); >>>> + VkPipelineShaderStageCreateInfo.pName$set(pStages, 1, >>>> CLinker.toCString("main", scope).address()); >>>> >>>> ?????????????? var pVertexInputStateInfo = >>>> VkPipelineVertexInputStateCreateInfo.allocate(scope); >>>> VkPipelineVertexInputStateCreateInfo.sType$set(pVertexInputStateInfo, >>>> vulkan_h.VK_STRUCTURE_TYPE_PIPELINE_VERTEX_INPUT_STATE_CREATE_INFO()); >>>> @@ -581,16 +581,14 @@ public class Vulkan { >>>> ?????????????? // If we change stageCount to 2 we get a crash.... >>>> ?????????????? // I think we are creating the pStages array >>>> incorrectly. >>>> This is also manifesting further down when trying >>>> ?????????????? // to create arrays pWaitSemaphores, >>>> pSignalSemaphores, etc. >>>> - VkGraphicsPipelineCreateInfo.stageCount$set(pPipelineCreateInfo, 1); >>>> -??????????? MemorySegment pStages = >>>> SegmentAllocator.ofScope(scope).allocateArray(C_POINTER, new >>>> Addressable[]{ >>>> -??????????????????? pVertShaderStageInfo, pFragShaderStageInfo}); >>>> -??????????? System.out.println("pStages: " + pStages); >>>> -??????????? System.out.println("pStages[0]: " + >>>> VkPipelineShaderStageCreateInfo.ofAddress(MemoryAccess.getAddressAtIndex(pStages, >>>> >>>> >>>> 0), scope)); >>>> -??????????? System.out.println("pStages[0].sType: " + >>>> VkPipelineShaderStageCreateInfo.sType$get(VkPipelineShaderStageCreateInfo.ofAddress(MemoryAccess.getAddressAtIndex(pStages, >>>> >>>> >>>> 0), scope))); >>>> -??????????? System.out.println("pStages[1]: " + >>>> VkPipelineShaderStageCreateInfo.ofAddress(MemoryAccess.getAddressAtIndex(pStages, >>>> >>>> >>>> 1), scope)); >>>> -??????????? System.out.println("pStages[1].sType: " + >>>> VkPipelineShaderStageCreateInfo.sType$get(VkPipelineShaderStageCreateInfo.ofAddress(MemoryAccess.getAddressAtIndex(pStages, >>>> >>>> >>>> 1), scope))); >>>> - >>>> - VkGraphicsPipelineCreateInfo.pStages$set(pPipelineCreateInfo, >>>> MemoryAccess.getAddress(pStages)); >>>> + VkGraphicsPipelineCreateInfo.stageCount$set(pPipelineCreateInfo, 2); >>>> +??????????? System.out.println("pStages: " + pStages.address()); >>>> +??????????? System.out.println("pStages[0]: " + pStages.asSlice(0, >>>> VkPipelineShaderStageCreateInfo.$LAYOUT().byteSize())); >>>> +??????????? System.out.println("pStages[0].sType: " + >>>> VkPipelineShaderStageCreateInfo.sType$get(pStages, 0)); >>>> +??????????? System.out.println("pStages[1]: " + >>>> pStages.asSlice(VkPipelineShaderStageCreateInfo.$LAYOUT().byteSize(), >>>> VkPipelineShaderStageCreateInfo.$LAYOUT().byteSize())); >>>> +??????????? System.out.println("pStages[1].sType: " + >>>> VkPipelineShaderStageCreateInfo.sType$get(pStages, 1)); >>>> + >>>> + VkGraphicsPipelineCreateInfo.pStages$set(pPipelineCreateInfo, >>>> pStages.address()); >>>> VkGraphicsPipelineCreateInfo.pVertexInputState$set(pPipelineCreateInfo, >>>> >>>> pVertexInputStateInfo.address()); >>>> VkGraphicsPipelineCreateInfo.pInputAssemblyState$set(pPipelineCreateInfo, >>>> >>>> pPipelineInputAssemblyStateInfo.address()); >>>> VkGraphicsPipelineCreateInfo.pViewportState$set(pPipelineCreateInfo, >>>> pPipelineViewportStateInfo.address()); >>>> >>>> HTH, >>>> Jorn >>>> >>>> On 02/09/2021 11:56, Maurizio Cimadamore wrote: >>>>> Hi Michael, >>>>> very interesting experiments - thanks for reaching out. >>>>> >>>>> Eyeballing your code, I zoomed into this line: >>>>> >>>>> >>>> https://github.com/brcolow/java-vulkan/blob/master/src/main/java/com/brcolow/game/Vulkan.java#L593 >>>> >>>>> >>>>> Here you want to set the `pStages` pointer, a pointer to a memory >>>>> region which presumably has to contain exactly `stageCount` >>>>> structs of >>>>> type `VkPipelineShaderStageCreateInfo`. >>>>> >>>>> I believe there's an extra getAddress in there; this: >>>>> >>>>> ``` >>>>> VkGraphicsPipelineCreateInfo.pStages$set(pPipelineCreateInfo, >>>>> MemoryAccess.getAddress(pStages)); >>>>> ``` >>>>> >>>>> should be: >>>>> >>>>> ``` >>>>> VkGraphicsPipelineCreateInfo.pStages$set(pPipelineCreateInfo, >>>>> pStages); >>>>> ``` >>>>> >>>>> That is, you want to pass the pointer to the `pStages` region you >>>>> just >>>>> created, so that Vulkan will be able to see all elements. If you call >>>>> "MemoryAccess::getAddress" your code will read the first 64 bits from >>>>> the `pStages` region, turn those into a MemoryAddress, and set that >>>>> into the enclosing `pPipelineCreateInfo` struct. Which I don't think >>>>> is what you want? >>>>> >>>>> Let me know if this works. >>>>> >>>>> Cheers >>>>> Maurizio >>>>> >>>>> >>>>> On 02/09/2021 06:35, Michael Ennen wrote: >>>>>> I have been doing more exploring with the panama-foreign, ffi, and >>>>>> jextract >>>>>> branches - this time messing around with seeing if I can get a >>>>>> rainbow >>>>>> triangle to be rendered on the screen with Vulkan. >>>>>> >>>>>> I am really close. There is one problem I am having which is how to >>>>>> create >>>>>> an array of structs? >>>>>> >>>>>> See this, for example: >>>>>> >>>>>> >>>> https://github.com/brcolow/java-vulkan/blob/master/src/main/java/com/brcolow/game/Vulkan.java#L581 >>>> >>>>>> >>>>>> If I set the stageCount to 2, then I get a validation exception >>>>>> about >>>>>> the >>>>>> second shader module having bogus values. I believe this is >>>>>> caused by >>>> me >>>>>> creating the array of structs incorrectly. >>>>>> >>>>>> I am trying to set the pStages element of this struct: >>>>>> >>>> https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VkGraphicsPipelineCreateInfo.html >>>> >>>>>> >>>>>> to an array containing pVertShaderStageInfo and >>>>>> pFragShaderStageInfo. >>>>>> >>>>>> My attempt (I have tried other ways that also fail) to do that is: >>>>>> >>>>>> MemorySegment pStages = >>>>>> SegmentAllocator.ofScope(scope).allocateArray( >>>>>> C_POINTER, new Addressable[]{ >>>>>> pVertShaderStageInfo, pFragShaderStageInfo}); >>>>>> VkGraphicsPipelineCreateInfo.pStages$set(pPipelineCreateInfo, >>>>>> MemoryAccess.getAddress(pStages)); >>>>>> >>>>>> >>>>>> If anyone could assist me with the proper way to create the >>>>>> VkPipelineShaderStageCreateInfo* array containing >>>>>> pVertShaderStageInfoand >>>>>> pFragShaderStageInfo - it would be greatly appreciated! >>>>>> >>> >>> -- >>> Michael Ennen >>> >> From paul.sandoz at oracle.com Thu Sep 2 22:11:23 2021 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 2 Sep 2021 22:11:23 +0000 Subject: Arrays.mismatch intrinsic and Vector API comparision In-Reply-To: References: Message-ID: <71444AEA-0386-417D-B6CB-0ABF957E107A@oracle.com> Hi Kartik, Thank you. It is useful. I am glad we are reaching the point where the Vector API is getting competitive with the mismatch stub. If you would like to contribute the benchmark I would be happy to review a PR. We could also measure int, float and long, in addition to small sizes, just above or below the vector length (not dissimilar to a mismatch on the the first or lower index of an array). When we wrote Arrays.mismatch we were very careful to measure the impact on small array sizes, since that method is also used to support Arrays.equals and we did not want to introduce a performance regression. Some of the difference might be explained by alignment of the arrays, some perhaps due to loop unrolling. I think there might be an issue with loop unrolling. It seems too aggressive, resulting larger than necessary nmethod sizes. We should look into that. Unsure if it's possible to to reduce [*]: vpcmpeqb %ymm1,%ymm0,%ymm0 vpxor -0x7ad507d(%rip),%ymm0,%ymm0 to: vpxor %ymm1,%ymm0,%ymm0 Since the latter will not produce a valid mask representation, which could affect later use of the mask value (firstTrue). Paul. [*] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/macroAssembler_x86.cpp#L3211 > On Aug 29, 2021, at 11:36 AM, Kartik Ohri wrote: > > Hi! > > I have started experimenting with the Vector API recently. Currently, I am > playing with the API and trying to gauge its potential by comparing its > performance with vectorized intrinsics implemented inside the JDK. I know > that Arrays.mismatch has a vectorized intrinsic so I started with it. I was > able to come up with a simple implementation for it using the Vector API. > The results of the JMH benchmark look quite promising, the Vector API is > able to come quite close to the intrinsic. This is awesome!! > > The benchmark code is available here > > and > the complete benchmark logs are here > . > I also did another run to check the assembly generated which is also > available here > . > It would be nice to get a sanity check on the benchmark before I proceed > further. > > Both versions perform more or less the same (difference is less than 5%, in > some cases the Vector API even outperforms the intrinsic). There is one > outlier where the Vector API is almost 35% slower than the intrinsic (when > prefix is 1 and size is 10000). > except for when the prefix is 1 i.e. both input arrays are equal. I see > that the assembly emitted by Vector API > > contains a *vpcmpeqb* but the JDK intrinsic > > does not. Looking at the implementation > > of the intrinsic in the JDK, The AVX 512 version uses *vpcmpeqb* but the > AVX2 version does not (my machine does not have AVX 512 so it makes that it > was not emitted in the case of the intrinsic). Secondly, from the assembly > it seems that the Vector API version was unrolled but the intrinsic was > not. If I am right, in general loop unrolling is better so the API seems to > be doing the right thing. Hence, I am not sure why this particular case is > an outlier. > > Further, Is analysing/comparing intrinsics within the JDK to the Vector API > useful? > > Also, any other suggestions regarding contributing to the Project are > welcome. > > Regards, > Kartik From sandhya.viswanathan at intel.com Fri Sep 3 01:43:06 2021 From: sandhya.viswanathan at intel.com (Viswanathan, Sandhya) Date: Fri, 3 Sep 2021 01:43:06 +0000 Subject: [vectorIntrinsics+mask] RFR: 8273057: [vector] New VectorAPI "SelectiveStore" In-Reply-To: <4994CF72-5CBD-4691-B9A4-FC361B287E52@oracle.com> References: <0A62FA43-000C-4033-96DD-EB153826D2DF@oracle.com> <052037EA-7C1F-4105-B14D-EC8212EC29C8@oracle.com> <4994CF72-5CBD-4691-B9A4-FC361B287E52@oracle.com> Message-ID: Today we have rearrange, slice and unslice methods to do cross lane movements. It looks to me that best way is to extend this and provide compress and expand as a primitive. It seems more natural from programmer's perspective as well as easy to do good code gen. Doing it as a special purpose rearrange with mask could be confusing as in the current API rearrange with mask has a different meaning. Backend implementation is also not clear on how then to achieve the desired single instruction code gen. As John suggests, on architectures that doesn?t support compress/expand, underlying compress/expand could be implemented in terms of mask->partition shuffle -> rearrange. Best Regards, Sandhya -----Original Message----- From: panama-dev On Behalf Of John Rose Sent: Thursday, September 02, 2021 11:36 AM To: Paul Sandoz Cc: Ningsheng Jian ; panama-dev Subject: Re: [vectorIntrinsics+mask] RFR: 8273057: [vector] New VectorAPI "SelectiveStore" On Aug 31, 2021, at 9:44 AM, Paul Sandoz > wrote: Yes, my suggestion is that a vector-to-vector compress might be a composition of mask -> partitioning shuffle -> rearrange, such that on supported architectures it reduces down to a single instruction. In combination with a store and prefix mask it may be possible to reduce further to single instruction accepting the source vector, mask, and a memory location. As I argued in my previous, it may be just as well to think of compress as its own primitive, even if under the covers it is implemented using shuffle. I think it?s worth thinking more about anti-shuffle, what that would be like. Mathematical permutations do not come in two kinds, but shuffles and anti-shuffles are distinct because only the former duplicate and only the latter collide. From duke at openjdk.java.net Fri Sep 3 11:05:58 2021 From: duke at openjdk.java.net (duke) Date: Fri, 3 Sep 2021 11:05:58 GMT Subject: git: openjdk/panama-foreign: foreign-jextract: 73 new changesets Message-ID: <3715aa3d-0ff6-463e-89ad-d60450a91038@openjdk.org> Changeset: 596b0755 Author: Magnus Ihse Bursie Date: 2021-08-27 13:13:36 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/596b075591c4b2fe01bee7142f4d0a5f892647ed 8258465: Headless build fails due to missing X11 headers on linux Reviewed-by: shade ! make/autoconf/libraries.m4 Changeset: b92214a8 Author: Coleen Phillimore Date: 2021-08-27 13:51:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b92214a8d0ca6ed2a51e4286c258b4ddd0ca3a51 8272480: Remove Mutex::access rank Reviewed-by: dholmes, eosterlund ! src/hotspot/share/runtime/mutex.cpp ! src/hotspot/share/runtime/mutex.hpp ! src/hotspot/share/runtime/mutexLocker.cpp ! src/hotspot/share/runtime/stackWatermark.cpp ! test/hotspot/gtest/runtime/test_mutex.cpp Changeset: a033aa5a Author: Magnus Ihse Bursie Date: 2021-08-27 13:53:33 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a033aa5a3d9c63d72d11af218b9896b037fbd8de 8273072: Avoid using += in configure Reviewed-by: dholmes, jiefu ! make/autoconf/flags-cflags.m4 ! make/autoconf/flags-other.m4 ! make/autoconf/jdk-version.m4 ! make/devkit/createMacosxDevkit.sh Changeset: dfeb4132 Author: Brian Burkhalter Date: 2021-08-27 16:08:29 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/dfeb4132e402c0466740a029c3b1d2d213955822 8272964: java/nio/file/Files/InterruptCopy.java fails with java.lang.RuntimeException: Copy was not interrupted Reviewed-by: dfuchs ! test/jdk/java/nio/file/Files/InterruptCopy.java Changeset: d1aeca11 Author: Brian Burkhalter Date: 2021-08-27 16:09:28 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d1aeca117ccc4334d67b2692ff087a9f8d808a59 8272541: Incorrect overflow test in Toom-Cook branch of BigInteger multiplication Reviewed-by: darcy ! src/java.base/share/classes/java/math/BigInteger.java ! test/jdk/java/math/BigInteger/BitLengthOverflow.java Changeset: e66c8afb Author: Jim Laskey Date: 2021-08-27 18:45:52 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e66c8afb59b57c4546656efa97f723f084964330 8272866: java.util.random package summary contains incorrect mixing function in table Reviewed-by: rriggs ! src/java.base/share/classes/java/util/random/package-info.java Changeset: 51167846 Author: Raffaello Giulietti Committer: Brian Burkhalter Date: 2021-08-27 22:48:52 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/51167846cb5a60dfb31b4f8dfa214ba26640175c 8273091: Doc of [Strict]Math.floorDiv(long,int) erroneously documents int in @return tag Reviewed-by: darcy, bpb ! src/java.base/share/classes/java/lang/Math.java ! src/java.base/share/classes/java/lang/StrictMath.java Changeset: 1fb798d3 Author: Bradford Wetmore Date: 2021-08-27 23:01:51 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1fb798d320c708dfcbc0bb157511a2937fafb9e6 8272915: (doc) package-info typo in extLink Reviewed-by: xuelei ! src/java.base/share/classes/java/security/interfaces/package-info.java Changeset: a9188f23 Author: Guoxiong Li Date: 2021-08-29 07:26:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a9188f237ec23d4ca2a172e9a7897cb6e2b69857 8268894: forged ASTs can provoke an AIOOBE at com.sun.tools.javac.jvm.ClassWriter::writePosition Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/TypeAnnotationPosition.java + test/langtools/tools/javac/annotations/typeAnnotations/position/TypeAnnotationPositionProcessor.java + test/langtools/tools/javac/annotations/typeAnnotations/position/TypeAnnotationPositionTest.java Changeset: f55d5ab5 Author: Aleksey Shipilev Date: 2021-08-30 06:41:40 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f55d5ab5177b6e08e8499abc181a320a98b28a5f 8272838: Move CriticalJNI tests out of tier1 Reviewed-by: dholmes ! test/hotspot/jtreg/TEST.groups Changeset: 16e83058 Author: Michael McMahon Date: 2021-08-30 08:57:17 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/16e83058cab4dd4d4a3fba812c8fe50e4286bd22 8273059: Redundant Math.min call in Http2ClientImpl#getConnectionWindowSize Reviewed-by: dfuchs ! src/java.net.http/share/classes/jdk/internal/net/http/Http2ClientImpl.java ! src/java.net.http/share/classes/jdk/internal/net/http/ResponseContent.java Changeset: 9ede41bf Author: Magnus Ihse Bursie Date: 2021-08-30 11:37:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9ede41bf894867b6d80982d7dc6ec54229a0ecb1 8229031: Exporting CLASSPATH from shell can result in build failures Reviewed-by: erikj ! make/autoconf/boot-jdk.m4 ! make/autoconf/spec.gmk.in Changeset: bb7aa1c6 Author: Thomas Schatzl Date: 2021-08-30 12:08:12 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bb7aa1c6a4856827cf05e976215699725b56b87a 8272161: Make evacuation failure data structures local to collection Reviewed-by: iwalulya, sjohanss ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1CollectedHeap.hpp ! src/hotspot/share/gc/g1/g1ParScanThreadState.cpp ! src/hotspot/share/gc/g1/g1ParScanThreadState.hpp ! src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.cpp ! src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.hpp Changeset: 276b07b3 Author: Lutz Schmidt Date: 2021-08-30 12:31:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/276b07b36af01d339e48baada7a512451fe34afe 8271490: [ppc] [s390]: Crash in JavaThread::pd_get_top_frame_for_profiling Reviewed-by: stuefe, mbaesken ! src/hotspot/cpu/ppc/frame_ppc.cpp ! src/hotspot/cpu/s390/frame_s390.cpp ! src/hotspot/os_cpu/linux_ppc/thread_linux_ppc.cpp ! src/hotspot/os_cpu/linux_s390/thread_linux_s390.cpp Changeset: 5185dbde Author: Andrey Turbanov Committer: Aleksei Efimov Date: 2021-08-30 13:12:42 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5185dbde67f07ff876305a9568bb5cebb7a7b384 8273098: Unnecessary Vector usage in java.naming Reviewed-by: aefimov, dfuchs ! src/java.naming/share/classes/com/sun/jndi/ldap/LdapSchemaParser.java ! src/java.naming/share/classes/com/sun/jndi/ldap/Obj.java ! src/java.naming/share/classes/com/sun/jndi/ldap/sasl/LdapSasl.java Changeset: fbffa54e Author: Magnus Ihse Bursie Date: 2021-08-30 13:41:54 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fbffa54efe447a4c911af2be1d7774a8c60d6ede 8270438: "Cores to use" output in configure is misleading Reviewed-by: erikj ! make/autoconf/help.m4 Changeset: f11e099a Author: Stefan Johansson Date: 2021-08-30 14:37:03 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f11e099a149adfecc474ba37276ec8672067d090 8272651: G1 heap region info print order changed by JDK-8269914 Reviewed-by: tschatzl, iwalulya, ayang ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1FullCollector.hpp ! src/hotspot/share/gc/g1/g1FullGCScope.cpp ! src/hotspot/share/gc/g1/g1FullGCScope.hpp ! test/hotspot/jtreg/gc/g1/TestEagerReclaimHumongousRegionsLog.java Changeset: 98b9d980 Author: Coleen Phillimore Date: 2021-08-30 14:47:24 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/98b9d98032a700490cda72f645dad505164ec699 8272797: Mutex with rank safepoint_check_never imply allow_vm_block Reviewed-by: dholmes, pchilanomate ! src/hotspot/os/aix/osThread_aix.cpp ! src/hotspot/os/bsd/osThread_bsd.cpp ! src/hotspot/os/linux/osThread_linux.cpp ! src/hotspot/share/classfile/classLoaderData.cpp ! src/hotspot/share/compiler/compileTask.hpp ! src/hotspot/share/gc/g1/g1RegionToSpaceMapper.cpp ! src/hotspot/share/gc/g1/g1ServiceThread.cpp ! src/hotspot/share/gc/g1/heapRegion.cpp ! src/hotspot/share/gc/g1/heapRegionRemSet.cpp ! src/hotspot/share/gc/parallel/psCompactionManager.cpp ! src/hotspot/share/gc/shared/gcLogPrecious.cpp ! src/hotspot/share/gc/shared/oopStorage.cpp ! src/hotspot/share/gc/shared/space.cpp ! src/hotspot/share/gc/shared/taskTerminator.cpp ! src/hotspot/share/gc/shared/workgroup.cpp ! src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp ! src/hotspot/share/gc/shenandoah/shenandoahPacer.hpp ! src/hotspot/share/gc/z/zMessagePort.inline.hpp ! src/hotspot/share/gc/z/zMetronome.cpp ! src/hotspot/share/memory/heapInspection.hpp ! src/hotspot/share/memory/metaspace/testHelpers.cpp ! src/hotspot/share/oops/methodData.cpp ! src/hotspot/share/prims/jvmtiTagMap.cpp ! src/hotspot/share/runtime/handshake.cpp ! src/hotspot/share/runtime/mutex.cpp ! src/hotspot/share/runtime/mutex.hpp ! src/hotspot/share/runtime/mutexLocker.cpp ! src/hotspot/share/runtime/stackWatermark.cpp ! src/hotspot/share/runtime/vmOperations.cpp ! src/hotspot/share/runtime/vmThread.cpp ! src/hotspot/share/services/heapDumperCompression.cpp ! src/hotspot/share/services/memoryManager.cpp ! src/hotspot/share/utilities/concurrentHashTable.inline.hpp ! src/hotspot/share/utilities/events.hpp ! test/hotspot/gtest/metaspace/test_is_metaspace_obj.cpp ! test/hotspot/gtest/metaspace/test_metaspacearena.cpp ! test/hotspot/gtest/metaspace/test_metaspacearena_stress.cpp ! test/hotspot/gtest/runtime/test_mutex.cpp ! test/hotspot/gtest/runtime/test_safepoint_locks.cpp ! test/hotspot/gtest/utilities/test_filterQueue.cpp Changeset: 7a01ba65 Author: Thomas Schatzl Date: 2021-08-30 15:54:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7a01ba6528923569c5e8d2e9d138d38e95aa4faf 8272093: Extract evacuation failure injection from G1CollectedHeap Reviewed-by: ayang, 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/g1ParScanThreadState.cpp + src/hotspot/share/gc/g1/g1YoungGCEvacFailureInjector.cpp + src/hotspot/share/gc/g1/g1YoungGCEvacFailureInjector.hpp + src/hotspot/share/gc/g1/g1YoungGCEvacFailureInjector.inline.hpp Changeset: 5aaa20f8 Author: Sandhya Viswanathan Date: 2021-08-30 16:48:28 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5aaa20f898e8679ef1c2c36bd01d48c17be0aacf 8272861: Add a micro benchmark for vector api Reviewed-by: psandoz + test/micro/org/openjdk/bench/jdk/incubator/vector/BlackScholes.java Changeset: f18c0fac Author: Fernando Guallini Committer: Rajan Halade Date: 2021-08-30 17:28:49 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f18c0fac11aac833edfdc484e221518c55daa9a7 8271560: sun/security/ssl/DHKeyExchange/LegacyDHEKeyExchange.java still fails due to "An established connection was aborted by the software in your host machine" Reviewed-by: xuelei, rhalade ! test/jdk/sun/security/ssl/DHKeyExchange/LegacyDHEKeyExchange.java Changeset: fecefb85 Author: Ian Graves Date: 2021-08-30 17:37:29 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fecefb8541d5056b1a8b105126ac9c566875e056 8271302: Regex Test Refresh Reviewed-by: bchristi, smarks ! test/jdk/java/util/regex/GraphemeTest.java ! test/jdk/java/util/regex/NegativeArraySize.java ! test/jdk/java/util/regex/RegExTest.java Changeset: 32048536 Author: Ioi Lam Date: 2021-08-30 21:06:26 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/32048536e9ea9245437eb37308e905435cce6305 8272343: Remove MetaspaceClosure::FLAG_MASK Reviewed-by: ccheung, minqi ! src/hotspot/share/cds/archiveBuilder.cpp ! src/hotspot/share/memory/metaspaceClosure.cpp ! src/hotspot/share/memory/metaspaceClosure.hpp Changeset: 7fc85409 Author: Naoto Sato Date: 2021-08-30 21:13:59 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7fc8540907e8e7483ad5729ea416167810aa8747 8260265: UTF-8 by Default Reviewed-by: alanb, rriggs ! make/data/charsetmapping/charsets ! src/java.base/share/classes/java/io/ByteArrayOutputStream.java ! src/java.base/share/classes/java/io/Console.java ! src/java.base/share/classes/java/io/FileReader.java ! src/java.base/share/classes/java/io/FileWriter.java ! src/java.base/share/classes/java/io/InputStreamReader.java ! src/java.base/share/classes/java/io/OutputStreamWriter.java ! src/java.base/share/classes/java/io/PrintStream.java ! src/java.base/share/classes/java/io/PrintWriter.java ! src/java.base/share/classes/java/lang/System.java ! src/java.base/share/classes/java/net/URLDecoder.java ! src/java.base/share/classes/java/net/URLEncoder.java ! src/java.base/share/classes/java/nio/charset/Charset.java ! src/java.base/share/classes/java/util/Scanner.java ! src/java.base/share/classes/jdk/internal/util/StaticProperty.java ! src/java.base/share/classes/jdk/internal/util/SystemProps.java + test/jdk/java/lang/System/FileEncodingTest.java ! test/jdk/java/lang/System/MacEncoding/MacJNUEncoding.java ! test/jdk/java/lang/System/MacEncoding/TestFileEncoding.java ! test/jdk/java/nio/charset/Charset/RegisteredCharsets.java ! test/jdk/java/nio/charset/RemovingSunIO/SunioAlias.java ! test/jdk/tools/launcher/UnicodeTest.java Changeset: 0609421d Author: Vicente Romero Date: 2021-08-30 21:16:46 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0609421d4b824c5642ca75d525bad3edd72cd23a 8272347: ObjectMethods::bootstrap should specify NPE if any argument except lookup is null Reviewed-by: mchung, chegar ! src/java.base/share/classes/java/lang/runtime/ObjectMethods.java ! test/jdk/java/lang/runtime/ObjectMethodsTest.java Changeset: 9732fbe4 Author: Yumin Qi Date: 2021-08-31 00:24:05 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9732fbe428c3b6a5422cc94e7295ba5482d1a7a9 8273153: Consolidate file_exists into os:file_exists Reviewed-by: iklam, ccheung ! src/hotspot/os/linux/os_linux.cpp ! src/hotspot/share/logging/logFileOutput.cpp ! src/hotspot/share/runtime/os.cpp ! src/hotspot/share/runtime/os.hpp Changeset: 98fa5335 Author: Claes Redestad Date: 2021-08-31 11:32:33 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/98fa53357a66f474090304e53959be5d433d5e5f 8273100: Improve AbstractStringBuilder.append(String) when using CompactStrings Reviewed-by: rriggs, alanb ! src/java.base/share/classes/java/lang/AbstractStringBuilder.java Changeset: 841e3943 Author: Ivan Walulya Date: 2021-08-31 12:30:14 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/841e3943c480c95409446bb35fb9a56d7fc48c8a 8159979: During initial mark, preparing all regions for marking may take a significant amount of time Reviewed-by: tschatzl, ayang ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp ! src/hotspot/share/gc/g1/g1ConcurrentMark.hpp ! src/hotspot/share/gc/g1/g1GCPhaseTimes.cpp ! src/hotspot/share/gc/g1/g1GCPhaseTimes.hpp Changeset: 9bc7cc56 Author: Albert Mingkun Yang Date: 2021-08-31 12:51:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9bc7cc56513adb9d2e39cd286d2a229c9c285e2d 8273033: SerialGC: remove obsolete comments Reviewed-by: sjohanss, tschatzl ! src/hotspot/share/gc/serial/genMarkSweep.cpp Changeset: e6712551 Author: Ivan Walulya Date: 2021-08-31 13:32:31 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e67125512f585c8efad2e7685b9bc409c96563d7 8237567: Refactor G1-specific code in shared VM_CollectForMetadataAllocation Reviewed-by: ayang, tschatzl ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1CollectedHeap.hpp ! src/hotspot/share/gc/shared/gcVMOperations.cpp ! src/hotspot/share/gc/shared/gcVMOperations.hpp Changeset: e5518528 Author: Brian Burkhalter Date: 2021-08-31 14:42:14 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e55185280126e450e31eb65aa8342aebe6f31606 8271225: Add floorDivExact() method to java.lang.[Strict]Math Reviewed-by: darcy ! src/java.base/share/classes/java/lang/Math.java ! src/java.base/share/classes/java/lang/StrictMath.java ! test/jdk/java/lang/Math/ExactArithTests.java Changeset: 75d987a0 Author: Vicente Romero Date: 2021-08-31 15:40:17 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/75d987a0dd6f8cc41808f7ba566e914817e465dc 8262095: NPE in Flow$FlowAnalyzer.visitApply: Cannot invoke getThrownTypes because tree.meth.type is null Co-authored-by: Jan Lahoda Co-authored-by: Vicente Romero Reviewed-by: jlahoda ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java + test/langtools/tools/javac/lambda/8262095/T8262095.java + test/langtools/tools/javac/lambda/8262095/T8262095.out Changeset: ba3587e5 Author: Thomas Schatzl Date: 2021-08-31 15:45:56 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ba3587e524aeec43a0c4174ddd96b8890a34fa36 8273144: Remove unused top level "Sample Collection Set Candidates" logging Reviewed-by: iwalulya, ayang ! src/hotspot/share/gc/g1/g1GCPhaseTimes.cpp ! src/hotspot/share/gc/g1/g1GCPhaseTimes.hpp ! test/hotspot/jtreg/gc/g1/TestGCLogMessages.java Changeset: 1996f649 Author: Ioi Lam Date: 2021-08-31 16:33:02 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1996f649a3a30b7ac4b547a762417f807f5fa414 8273092: Sort classlist in JDK image Reviewed-by: redestad, ihse, dfuchs ! make/GenerateLinkOptData.gmk + make/jdk/src/classes/build/tools/classlist/SortClasslist.java ! make/scripts/compare.sh Changeset: 683e30db Author: bobpengxie Committer: Sergey Bylokhov Date: 2021-08-31 17:31:03 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/683e30db79789ee44b3cc0b44c085de4615bca7b 8273169: java/util/regex/NegativeArraySize.java failed after JDK-8271302 Reviewed-by: jiefu, serb ! test/jdk/java/util/regex/NegativeArraySize.java Changeset: c1e0aac8 Author: Thomas Schatzl Date: 2021-08-31 19:46:55 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c1e0aac846861f9bd8a23818a21670a2f649631b 8273186: Remove leftover comment about sparse remembered set in G1 HeapRegionRemSet Reviewed-by: ayang ! src/hotspot/share/gc/g1/heapRegionRemSet.hpp Changeset: 3d657eb0 Author: Weijun Wang Date: 2021-08-31 20:07:02 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3d657eb0a626e33995af5d5ddf12b26d06317962 8262186: Call X509KeyManager.chooseClientAlias once for all key types Reviewed-by: xuelei ! src/java.base/share/classes/sun/security/ssl/CertificateMessage.java ! src/java.base/share/classes/sun/security/ssl/CertificateRequest.java ! src/java.base/share/classes/sun/security/ssl/X509Authentication.java + test/jdk/sun/security/ssl/SSLContextImpl/MultipleChooseAlias.java Changeset: 9c392d00 Author: Daniel D. Daugherty Date: 2021-08-31 20:12:19 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9c392d008a5a34cdc2ed6339a63f1a0d06efe619 8273197: ProblemList 2 jtools tests due to JDK-8273187 8273198: ProblemList java/lang/instrument/BootClassPath/BootClassPathTest.sh due to JDK-8273188 Reviewed-by: naoto ! test/jdk/ProblemList.txt Changeset: 18a731a3 Author: Alex Menkov Date: 2021-08-31 22:43:12 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/18a731a3e4ec85f0f3e8d6ff619b539c0daaf320 8269770: nsk tests should start IOPipe channel before launch debuggee - Debugee.prepareDebugee Reviewed-by: sspitsyn, kevinw ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Accessible/isPackagePrivate/accipp001.java ! test/hotspot/jtreg/vmTestbase/nsk/share/jpda/DebugeeProcess.java ! test/hotspot/jtreg/vmTestbase/nsk/share/jpda/IOPipe.java Changeset: 2fce7cb4 Author: David Holmes Date: 2021-08-31 23:51:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2fce7cb4d21e4e2c234c22a1a150f7fe113d4d16 8272963: Update the java manpage markdown source Reviewed-by: ysuenaga ! src/java.base/share/man/java.1 Changeset: e600fe1a Author: Jan Lahoda Date: 2021-09-01 06:06:17 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e600fe1a1a57d7e4060b3a1b9a8ecdb65664a506 8272618: Unnecessary Attr.visitIdent.noOuterThisPath Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java Changeset: f1c5e26e Author: Jie Fu Date: 2021-09-01 07:55:20 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f1c5e26e48ca2db0fc2b7ad2cf1bda4853bdeea9 8273206: jdk/jfr/event/gc/collection/TestG1ParallelPhases.java fails after JDK-8159979 Reviewed-by: dholmes, ayang ! test/jdk/jdk/jfr/event/gc/collection/TestG1ParallelPhases.java Changeset: 0e14bf70 Author: Matthias Baesken Date: 2021-09-01 07:59:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0e14bf70cf6e482a2ec7d13ed37df0bee911740d 8273176: handle latest VS2019 in abstract_vm_version Reviewed-by: kevinw, dholmes ! src/hotspot/share/runtime/abstract_vm_version.cpp Changeset: a58cf165 Author: Fairoz Matte Committer: Tobias Hartmann Date: 2021-09-01 10:12:25 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a58cf16509f3120d69fc18bd4c2c49e9ad590f73 8272563: assert(is_double_stack() && !is_virtual()) failed: type check Reviewed-by: thartmann, iveresov ! src/hotspot/share/gc/shared/c1/cardTableBarrierSetC1.cpp Changeset: 02822e13 Author: Yi Yang Date: 2021-09-01 10:41:03 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/02822e1398d6015f0ed26edd440db8e0d50bf152 8272377: assert preconditions that are ensured when created in add_final_edges Reviewed-by: thartmann, kvn ! src/hotspot/share/opto/escape.cpp ! src/hotspot/share/opto/escape.hpp Changeset: dacd1978 Author: Coleen Phillimore Date: 2021-09-01 16:48:06 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/dacd1978972b46510049086c8431bb12e5f3722f 8273217: Make ParHeapInspectTask _safepoint_check_never Reviewed-by: dholmes, pchilanomate ! src/hotspot/share/memory/heapInspection.cpp ! src/hotspot/share/memory/heapInspection.hpp Changeset: 655ea6d4 Author: Ioi Lam Date: 2021-09-01 16:50:11 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/655ea6d42ae94d96a03b1f008aad264a1ee4f173 8270489: Support archived heap objects in EpsilonGC Reviewed-by: shade, ccheung ! src/hotspot/share/cds/archiveBuilder.cpp ! src/hotspot/share/cds/archiveUtils.cpp ! src/hotspot/share/cds/filemap.cpp ! src/hotspot/share/cds/filemap.hpp ! src/hotspot/share/cds/heapShared.cpp ! src/hotspot/share/cds/heapShared.hpp ! src/hotspot/share/cds/heapShared.inline.hpp ! src/hotspot/share/cds/metaspaceShared.cpp ! src/hotspot/share/cds/metaspaceShared.hpp ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/classfile/stringTable.cpp ! src/hotspot/share/classfile/stringTable.hpp ! src/hotspot/share/classfile/systemDictionaryShared.cpp ! src/hotspot/share/classfile/vmClasses.cpp ! src/hotspot/share/gc/epsilon/epsilonHeap.cpp ! src/hotspot/share/gc/epsilon/epsilonHeap.hpp ! src/hotspot/share/gc/shared/collectedHeap.hpp ! src/hotspot/share/memory/universe.cpp ! src/hotspot/share/oops/constantPool.cpp ! src/hotspot/share/oops/klass.cpp ! src/hotspot/share/prims/whitebox.cpp ! test/hotspot/jtreg/TEST.groups ! test/hotspot/jtreg/runtime/cds/appcds/TestCommon.java + test/hotspot/jtreg/runtime/cds/appcds/TestEpsilonGCWithCDS.java ! test/hotspot/jtreg/runtime/cds/appcds/customLoader/HelloCustom.java ! test/hotspot/jtreg/runtime/cds/appcds/customLoader/UnloadUnregisteredLoaderTest.java ! test/hotspot/jtreg/runtime/cds/appcds/javaldr/GCSharedStringsDuringDump.java ! test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/SharedStringsStress.java ! test/jtreg-ext/requires/VMProps.java ! test/lib/jdk/test/lib/cds/CDSOptions.java ! test/lib/jdk/test/lib/cds/CDSTestUtils.java Changeset: 4ee0dace Author: Daniel D. Daugherty Date: 2021-09-01 17:45:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4ee0dacecd5afc5876ea839ffbb5df962ff6cd08 8273248: ProblemList java/lang/instrument/BootClassPath/BootClassPathTest.sh on all configs Reviewed-by: naoto ! test/jdk/ProblemList.txt Changeset: 9689f615 Author: Coleen Phillimore Date: 2021-09-01 18:39:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9689f615206e96f17ffc1fe7a8efeee0a90c904b 8272788: Nonleaf ranked locks should not be safepoint_check_never Reviewed-by: eosterlund, pchilanomate ! src/hotspot/share/prims/jvmtiTagMap.cpp ! src/hotspot/share/runtime/mutex.cpp ! src/hotspot/share/runtime/mutexLocker.cpp ! src/hotspot/share/runtime/mutexLocker.hpp Changeset: 2f01a6f8 Author: Joe Darcy Date: 2021-09-01 20:28:05 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2f01a6f8b6c0bc08c6e3b7ea279d3826f451607f 8273157: Add convenience methods to Messager Reviewed-by: jjg ! src/java.compiler/share/classes/javax/annotation/processing/Messager.java ! test/langtools/tools/javac/7129225/AnnoProcessor.java ! test/langtools/tools/javac/MethodParameters/ClassReaderTest/MethodParameterProcessor.java ! test/langtools/tools/javac/T6406771.java ! test/langtools/tools/javac/T6458823/MyProcessor.java ! test/langtools/tools/javac/T7159016.java ! test/langtools/tools/javac/T8170667/ParameterProcessor.java ! test/langtools/tools/javac/api/T6412669.java ! test/langtools/tools/javac/api/TestClientCodeWrapper.java ! test/langtools/tools/javac/api/TestGetElement.java ! test/langtools/tools/javac/api/TestOperators.java ! test/langtools/tools/javac/api/TestTrees.java ! test/langtools/tools/javac/classreader/T7031108.java ! test/langtools/tools/javac/diags/DocCommentProcessor.java ! test/langtools/tools/javac/diags/examples/ErrProcMessager/processors/AnnoProc.java ! test/langtools/tools/javac/diags/examples/NoteProcMessager/processors/AnnoProc.java ! test/langtools/tools/javac/diags/examples/ProcFileCreateLastRound/processors/AnnoProc.java ! test/langtools/tools/javac/diags/examples/ProcFileReopening/processors/AnnoProc.java ! test/langtools/tools/javac/diags/examples/ProcIllegalFileName/processors/AnnoProc.java ! test/langtools/tools/javac/diags/examples/ProcSuspiciousClassName/processors/AnnoProc.java ! test/langtools/tools/javac/diags/examples/ProcTypeRecreate/processors/AnnoProc.java ! test/langtools/tools/javac/diags/examples/ProcUnclosedTypeFiles/processors/AnnoProc.java ! test/langtools/tools/javac/diags/examples/ProcUseImplicit/processors/AnnoProc.java ! test/langtools/tools/javac/diags/examples/ProcUseProcOrImplicit/processors/AnnoProc.java ! test/langtools/tools/javac/diags/examples/WarnProcMessager/processors/AnnoProc.java ! test/langtools/tools/javac/enum/6424358/T6424358.java ! test/langtools/tools/javac/file/T7018098.java ! test/langtools/tools/javac/file/T7068437.java ! test/langtools/tools/javac/file/T7068451.java ! test/langtools/tools/javac/modules/AnnotationProcessing.java ! test/langtools/tools/javac/patterns/PatternMatchPosTest.java ! test/langtools/tools/javac/processing/6350124/HelloWorldAP.java ! test/langtools/tools/javac/processing/6365040/ProcBar.java ! test/langtools/tools/javac/processing/6365040/ProcFoo.java ! test/langtools/tools/javac/processing/6365040/T6365040.java ! test/langtools/tools/javac/processing/6414633/A.java ! test/langtools/tools/javac/processing/6430209/b6341534.java ! test/langtools/tools/javac/processing/6499119/ClassProcessor.java ! test/langtools/tools/javac/processing/6994946/TestProcessor.java ! test/langtools/tools/javac/processing/GenerateAndError.java ! test/langtools/tools/javac/processing/StopAfterError/StopAfterError.java ! test/langtools/tools/javac/processing/T6439826.java ! test/langtools/tools/javac/processing/T6920317.java ! test/langtools/tools/javac/processing/TestWarnErrorCount.java ! test/langtools/tools/javac/processing/environment/round/TestContext.java ! test/langtools/tools/javac/processing/errors/TestErrorCount.java ! test/langtools/tools/javac/processing/errors/TestReturnCode.java ! test/langtools/tools/javac/processing/errors/TestSuppression.java ! test/langtools/tools/javac/processing/filer/TestGetResource2.java ! test/langtools/tools/javac/processing/filer/TestInvalidRelativeNames.java ! test/langtools/tools/javac/processing/filer/TestValidRelativeNames.java ! test/langtools/tools/javac/processing/loader/testClose/TestClose2.java ! test/langtools/tools/javac/processing/messager/MessagerDiags.java ! test/langtools/tools/javac/processing/model/6341534/T6341534.java ! test/langtools/tools/javac/processing/model/element/CheckingAccessorsOnLoadedRecordClasses.java ! test/langtools/tools/javac/processing/model/element/CheckingTypeAnnotationsOnRecords.java ! test/langtools/tools/javac/processing/model/element/JavaxLangModelForRecords.java ! test/langtools/tools/javac/processing/model/element/TestAnonSourceNames.java ! test/langtools/tools/javac/processing/model/element/TestExecutableElement.java ! test/langtools/tools/javac/processing/model/element/TestExecutableReceiverType.java ! test/langtools/tools/javac/processing/model/element/TestMissingElement/TestMissingElement.java ! test/langtools/tools/javac/processing/model/element/TestMissingElement2/Generator.java ! test/langtools/tools/javac/processing/model/element/TestSealed.java ! test/langtools/tools/javac/processing/model/element/TestTypeElement.java ! test/langtools/tools/javac/processing/model/element/TestTypeParameter.java ! test/langtools/tools/javac/processing/model/element/TestTypeParameterAnnotations.java ! test/langtools/tools/javac/processing/model/util/deprecation/TestDeprecation.java ! test/langtools/tools/javac/processing/model/util/elements/TestIsFunctionalInterface.java ! test/langtools/tools/javac/processing/model/util/elements/doccomments/TestDocComments.java ! test/langtools/tools/javac/processing/model/util/elements/doccomments/TestPackageInfoComments.java ! test/langtools/tools/javac/processing/options/testCommandLineClasses/Test.java ! test/langtools/tools/javac/processing/options/testPrintProcessorInfo/Test.java ! test/langtools/tools/javac/processing/rounds/BaseClassesNotReRead.java ! test/langtools/tools/javac/processing/rounds/ClassDependingOnGenerated.java ! test/langtools/tools/javac/processing/rounds/ErrClassSymbolTypeFixed.java ! test/langtools/tools/javac/processing/rounds/GenerateAnonymousClass.java ! test/langtools/tools/javac/processing/rounds/OverwriteBetweenCompilations.java ! test/langtools/tools/javac/processing/warnings/TestSourceVersionWarnings.java ! test/langtools/tools/javac/processing/warnings/UseImplicit/TestProcUseImplicitWarning.java ! test/langtools/tools/javac/processing/werror/WError1.java ! test/langtools/tools/javac/processing/werror/WErrorLast.java ! test/langtools/tools/javac/tree/ArrayTypeToString.java ! test/langtools/tools/javac/tree/NoPrivateTypesExported.java ! test/langtools/tools/javac/tree/TreePosRoundsTest.java ! test/langtools/tools/javac/treeannotests/TestProcessor.java ! test/langtools/tools/javac/util/NewlineOnlyDiagnostic.java ! test/langtools/tools/javac/util/T6597678.java Changeset: 1a5a2b6b Author: Valerie Peng Date: 2021-09-01 22:17:49 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1a5a2b6b15e22b21343244e3a2b649d00eef5ffa 8271745: Correct block size for KW,KWP mode and use fixed IV for KWP mode for SunJCE Reviewed-by: xuelei, mullan ! 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: a9a83b24 Author: Jie Fu Date: 2021-09-02 04:10:46 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a9a83b248e4a575e3d22541c122b27246a52dc7b 8273256: runtime/cds/appcds/TestEpsilonGCWithCDS.java fails due to Unrecognized VM option 'ObjectAlignmentInBytes=64' on x86_32 Reviewed-by: dholmes, iklam ! test/hotspot/jtreg/runtime/cds/appcds/TestEpsilonGCWithCDS.java Changeset: 6cfe3142 Author: Aleksey Shipilev Date: 2021-09-02 07:56:56 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6cfe314262dacd6ca1a74c000d045b1cabd374db 8272970: Parallelize runtime/InvocationTests/ Reviewed-by: dholmes, iignatyev ! test/hotspot/jtreg/ProblemList.txt ! test/hotspot/jtreg/runtime/InvocationTests/invocationC1Tests.java ! test/hotspot/jtreg/runtime/InvocationTests/invocationOldCHATests.java ! test/hotspot/jtreg/runtime/InvocationTests/invokeinterfaceTests.java ! test/hotspot/jtreg/runtime/InvocationTests/invokespecialTests.java ! test/hotspot/jtreg/runtime/InvocationTests/invokevirtualTests.java Changeset: 857a930b Author: Aleksey Shipilev Date: 2021-09-02 08:00:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/857a930bde8b53f77a23737f4ca6ff8f3da2af66 8263375: Support stack watermarks in Zero VM Reviewed-by: eosterlund ! src/hotspot/cpu/zero/frame_zero.cpp ! src/hotspot/cpu/zero/vm_version_zero.hpp ! src/hotspot/cpu/zero/zeroInterpreter_zero.cpp ! src/hotspot/cpu/zero/zeroInterpreter_zero.hpp ! src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp Changeset: 152e6692 Author: Sergey Tsypanov Committer: Thomas Schatzl Date: 2021-09-02 08:10:40 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/152e66923dc36cfd83cdfe18e96631abc06b9199 8273140: Replace usages of Enum.class.getEnumConstants() with Enum.values() where possible Reviewed-by: tschatzl ! src/java.desktop/share/classes/sun/font/AttributeValues.java ! src/java.desktop/share/classes/sun/font/EAttribute.java ! src/java.sql/share/classes/java/sql/JDBCType.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/bytecode/SourceGenerator.java Changeset: 0c1b16b7 Author: Aleksei Efimov Date: 2021-09-02 10:36:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0c1b16b75a2361431cbf9f4112dcd6049e981a78 8273243: Fix indentations in java.net.InetAddress methods Reviewed-by: dfuchs, bpb ! src/java.base/share/classes/java/net/InetAddress.java Changeset: c2e015c3 Author: Matthias Baesken Date: 2021-09-02 11:22:49 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c2e015c3c1a2274112bb8e6671a85bc7fb624fde 8273229: Update OS detection code to recognize Windows Server 2022 Reviewed-by: alanb, dholmes ! src/hotspot/os/windows/os_windows.cpp ! src/java.base/windows/native/libjava/java_props_md.c Changeset: 632a7e08 Author: Vladimir Ivanov Date: 2021-09-02 11:46:19 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/632a7e0885596b70d34be319bd09d4df8e151d12 8273165: GraphKit::combine_exception_states fails with "matching stack sizes" assert Reviewed-by: thartmann, kvn ! src/hotspot/share/opto/callGenerator.cpp Changeset: 5245c1cf Author: Thomas Schatzl Date: 2021-09-02 11:57:55 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5245c1cf0260a78ca5f8ab4e7d13107f21faf071 8273147: Update and restructure TestGCLogMessages log message list Reviewed-by: iwalulya, ayang ! test/hotspot/jtreg/gc/g1/TestGCLogMessages.java Changeset: 5ee5dd9b Author: Aleksey Shipilev Date: 2021-09-02 15:43:21 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5ee5dd9b18fb5adc563a65bd1a29779eda675d61 8272914: Create hotspot:tier2 and hotspot:tier3 test groups Reviewed-by: dholmes, coleenp, iignatyev ! test/hotspot/jtreg/TEST.groups Changeset: aaa6f696 Author: Lance Andersen Date: 2021-09-02 16:06:55 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/aaa6f696b06b335f81efccf0966612b086dd2e73 8273250: Address javadoc issues in Deflater::setDictionationary Reviewed-by: rriggs, naoto, iris, bpb ! src/java.base/share/classes/java/util/zip/Deflater.java Changeset: 29e0f138 Author: Jamil Nimeh Date: 2021-09-02 17:54:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/29e0f1386d247731e8733f6fdd1307642b2b9f96 8272385: Enforce ECPrivateKey d value to be in the range [1, n-1] for SunEC provider Reviewed-by: ascarpino, weijun ! src/java.base/share/classes/sun/security/util/ECUtil.java ! src/jdk.crypto.ec/share/classes/sun/security/ec/ECDHKeyAgreement.java ! src/jdk.crypto.ec/share/classes/sun/security/ec/ECDSASignature.java + test/jdk/sun/security/ec/ECDSAPrvGreaterThanOrder.java Changeset: 92b05fe0 Author: Patricio Chilano Mateo Date: 2021-09-02 21:22:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/92b05fe0f41b91aa88e77473725ae92ee13b052f 8273251: Call check_possible_safepoint() from SafepointMechanism::process_if_requested() Reviewed-by: coleenp, dholmes ! src/hotspot/share/runtime/interfaceSupport.inline.hpp ! src/hotspot/share/runtime/safepointMechanism.inline.hpp ! src/hotspot/share/runtime/thread.cpp Changeset: 7fff22af Author: Sergey Bylokhov Date: 2021-09-02 22:56:20 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7fff22afe711c8c04dbf4cf5b4938d40632e4987 8272805: Avoid looking up standard charsets Reviewed-by: weijun, naoto, dfuchs, azvegint, erikj ! make/jdk/src/classes/build/tools/generatelsrequivmaps/EquivMapsGenerator.java ! src/demo/share/jfc/Font2DTest/Font2DTest.java ! src/demo/share/jfc/Font2DTest/FontPanel.java ! src/demo/share/jfc/SwingSet2/DemoModule.java ! src/demo/share/jfc/SwingSet2/TreeDemo.java ! src/java.base/share/classes/sun/security/util/DerOutputStream.java ! src/java.base/share/classes/sun/security/util/DerValue.java ! src/java.datatransfer/share/classes/sun/datatransfer/DataFlavorUtil.java ! src/java.desktop/macosx/classes/sun/font/CFontConfiguration.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/png/PNGImageReader.java ! src/java.desktop/unix/classes/sun/font/FcFontConfiguration.java ! src/java.desktop/unix/classes/sun/font/MFontConfiguration.java ! src/java.security.jgss/share/classes/sun/security/krb5/internal/PAData.java ! src/java.security.jgss/share/classes/sun/security/krb5/internal/crypto/dk/DkCrypto.java ! src/java.security.jgss/share/classes/sun/security/krb5/internal/util/KerberosString.java ! src/java.security.sasl/share/classes/com/sun/security/sasl/digest/DigestMD5Base.java ! src/java.security.sasl/share/classes/com/sun/security/sasl/digest/DigestMD5Server.java ! src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java ! src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java ! src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/platform/JDKPlatformProvider.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/processing/ServiceProxy.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/client/SjavacClient.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/InputLexer.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/posix/elf/ELFFileParser.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/win32/coff/COFFFileParser.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/HeapHprofBinWriter.java ! src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java ! src/jdk.internal.ed/share/classes/jdk/internal/editor/external/ExternalEditor.java ! src/jdk.internal.jvmstat/linux/classes/sun/jvmstat/PlatformSupportImpl.java ! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.services/src/jdk/vm/ci/services/Services.java ! src/jdk.jcmd/share/classes/sun/tools/common/PrintStreamPrinter.java ! src/jdk.jcmd/share/classes/sun/tools/jmap/JMap.java ! src/jdk.jdeps/share/classes/com/sun/tools/classfile/SourceDebugExtension_attribute.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/PacketStream.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/SocketTransportService.java ! src/jdk.jdi/windows/classes/com/sun/tools/jdi/SharedMemoryConnection.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/StringParser.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/jfc/model/JFCModel.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/jfc/model/Parser.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/tool/Metadata.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/tool/Print.java ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/ConsoleIOContext.java ! src/jdk.jshell/share/classes/jdk/jshell/execution/DemultiplexInput.java ! src/jdk.jshell/share/classes/jdk/jshell/execution/MultiplexingOutputStream.java ! src/jdk.jshell/share/classes/jdk/jshell/execution/Util.java ! src/jdk.management.agent/share/classes/sun/management/jdp/JdpPacketReader.java ! src/jdk.security.auth/share/classes/com/sun/security/auth/module/Crypt.java ! src/jdk.security.auth/share/classes/com/sun/security/auth/module/JndiLoginModule.java ! src/utils/IdealGraphVisualizer/Data/src/main/java/com/sun/hotspot/igv/data/serialization/BinaryParser.java ! src/utils/IdealGraphVisualizer/Data/src/test/java/com/sun/hotspot/igv/data/serialization/ParserTest.java ! src/utils/IdealGraphVisualizer/View/src/main/java/com/sun/hotspot/igv/view/EditorTopComponent.java Changeset: dd871819 Author: Ian Graves Date: 2021-09-03 00:50:11 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/dd871819a05886ee09fc00c7c778268440ebedb7 8214761: Bug in parallel Kahan summation implementation Reviewed-by: darcy ! src/java.base/share/classes/java/util/DoubleSummaryStatistics.java ! src/java.base/share/classes/java/util/stream/Collectors.java ! src/java.base/share/classes/java/util/stream/DoublePipeline.java + test/jdk/java/util/DoubleStreamSums/CompensatedSums.java + test/jdk/java/util/DoubleSummaryStatistics/NegativeCompensation.java Changeset: fa9c8657 Author: Xiaowei Lu Committer: David Holmes Date: 2021-09-03 05:29:02 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fa9c8657dfaa2018f501de1a8aa62f004342c245 8273112: -Xloggc: should override -verbose:gc Reviewed-by: iklam, dholmes ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/arguments.hpp Changeset: f17ee0c5 Author: Jan Lahoda Date: 2021-09-03 09:29:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f17ee0c5c796951801c2026a2acac895a5c0af73 8273263: Incorrect recovery attribution of record component type when j.l.Record is unavailable Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java ! test/langtools/tools/javac/api/TestGetElementReference.java + test/langtools/tools/javac/api/TestGetElementReferenceDataWithRecord.java Changeset: 7b023a3f Author: Jan Lahoda Date: 2021-09-03 09:30:56 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7b023a3f607f44da1b13bc9d2884a5f13723d524 8273257: jshell doesn't compile a sealed hierarchy with a sealed interface and a non-sealed leaf Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! test/langtools/jdk/jshell/SealedClassesTest.java ! test/langtools/tools/javac/sealed/SealedCompilationTests.java Changeset: 93eec9a1 Author: Jan Lahoda Date: 2021-09-03 09:31:54 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/93eec9a103de7f4d9a87eac5b295c9a50702ee94 8272776: NullPointerException not reported Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java ! test/langtools/tools/javac/patterns/NullSwitch.java Changeset: d05494f9 Author: Guoxiong Li Date: 2021-09-03 09:33:17 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d05494f98bad351532cdb769c9da6b6e2359b16e 8266239: Some duplicated javac command-line options have repeated effect Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.java ! test/langtools/tools/javac/options/modes/InfoOptsTest.java ! test/langtools/tools/javac/options/modes/OptionModesTester.java Changeset: 0ed9424c Author: duke Date: 2021-09-03 11:00:29 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0ed9424c7ee505c6e11ec680383aa8aae7b2d2d6 Automatic merge of jdk:master into master Changeset: c3d9643e Author: duke Date: 2021-09-03 11:00:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c3d9643e8e95c8daf2d0a93bf15395c9d57e1468 Automatic merge of master into foreign-memaccess+abi Changeset: 9a6de2b4 Author: duke Date: 2021-09-03 11:01:03 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9a6de2b4ddc3e7f0f8a9abfc571e7d6aa2a27129 Automatic merge of foreign-memaccess+abi into foreign-jextract ! make/autoconf/libraries.m4 ! make/autoconf/spec.gmk.in ! make/autoconf/libraries.m4 ! make/autoconf/spec.gmk.in From duke at openjdk.java.net Fri Sep 3 11:10:10 2021 From: duke at openjdk.java.net (duke) Date: Fri, 3 Sep 2021 11:10:10 GMT Subject: git: openjdk/panama-foreign: foreign-memaccess+abi: 72 new changesets Message-ID: <6cd63278-ebf4-4b6f-a68d-183e417066cc@openjdk.org> Changeset: 596b0755 Author: Magnus Ihse Bursie Date: 2021-08-27 13:13:36 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/596b075591c4b2fe01bee7142f4d0a5f892647ed 8258465: Headless build fails due to missing X11 headers on linux Reviewed-by: shade ! make/autoconf/libraries.m4 Changeset: b92214a8 Author: Coleen Phillimore Date: 2021-08-27 13:51:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b92214a8d0ca6ed2a51e4286c258b4ddd0ca3a51 8272480: Remove Mutex::access rank Reviewed-by: dholmes, eosterlund ! src/hotspot/share/runtime/mutex.cpp ! src/hotspot/share/runtime/mutex.hpp ! src/hotspot/share/runtime/mutexLocker.cpp ! src/hotspot/share/runtime/stackWatermark.cpp ! test/hotspot/gtest/runtime/test_mutex.cpp Changeset: a033aa5a Author: Magnus Ihse Bursie Date: 2021-08-27 13:53:33 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a033aa5a3d9c63d72d11af218b9896b037fbd8de 8273072: Avoid using += in configure Reviewed-by: dholmes, jiefu ! make/autoconf/flags-cflags.m4 ! make/autoconf/flags-other.m4 ! make/autoconf/jdk-version.m4 ! make/devkit/createMacosxDevkit.sh Changeset: dfeb4132 Author: Brian Burkhalter Date: 2021-08-27 16:08:29 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/dfeb4132e402c0466740a029c3b1d2d213955822 8272964: java/nio/file/Files/InterruptCopy.java fails with java.lang.RuntimeException: Copy was not interrupted Reviewed-by: dfuchs ! test/jdk/java/nio/file/Files/InterruptCopy.java Changeset: d1aeca11 Author: Brian Burkhalter Date: 2021-08-27 16:09:28 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d1aeca117ccc4334d67b2692ff087a9f8d808a59 8272541: Incorrect overflow test in Toom-Cook branch of BigInteger multiplication Reviewed-by: darcy ! src/java.base/share/classes/java/math/BigInteger.java ! test/jdk/java/math/BigInteger/BitLengthOverflow.java Changeset: e66c8afb Author: Jim Laskey Date: 2021-08-27 18:45:52 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e66c8afb59b57c4546656efa97f723f084964330 8272866: java.util.random package summary contains incorrect mixing function in table Reviewed-by: rriggs ! src/java.base/share/classes/java/util/random/package-info.java Changeset: 51167846 Author: Raffaello Giulietti Committer: Brian Burkhalter Date: 2021-08-27 22:48:52 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/51167846cb5a60dfb31b4f8dfa214ba26640175c 8273091: Doc of [Strict]Math.floorDiv(long,int) erroneously documents int in @return tag Reviewed-by: darcy, bpb ! src/java.base/share/classes/java/lang/Math.java ! src/java.base/share/classes/java/lang/StrictMath.java Changeset: 1fb798d3 Author: Bradford Wetmore Date: 2021-08-27 23:01:51 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1fb798d320c708dfcbc0bb157511a2937fafb9e6 8272915: (doc) package-info typo in extLink Reviewed-by: xuelei ! src/java.base/share/classes/java/security/interfaces/package-info.java Changeset: a9188f23 Author: Guoxiong Li Date: 2021-08-29 07:26:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a9188f237ec23d4ca2a172e9a7897cb6e2b69857 8268894: forged ASTs can provoke an AIOOBE at com.sun.tools.javac.jvm.ClassWriter::writePosition Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/TypeAnnotationPosition.java + test/langtools/tools/javac/annotations/typeAnnotations/position/TypeAnnotationPositionProcessor.java + test/langtools/tools/javac/annotations/typeAnnotations/position/TypeAnnotationPositionTest.java Changeset: f55d5ab5 Author: Aleksey Shipilev Date: 2021-08-30 06:41:40 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f55d5ab5177b6e08e8499abc181a320a98b28a5f 8272838: Move CriticalJNI tests out of tier1 Reviewed-by: dholmes ! test/hotspot/jtreg/TEST.groups Changeset: 16e83058 Author: Michael McMahon Date: 2021-08-30 08:57:17 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/16e83058cab4dd4d4a3fba812c8fe50e4286bd22 8273059: Redundant Math.min call in Http2ClientImpl#getConnectionWindowSize Reviewed-by: dfuchs ! src/java.net.http/share/classes/jdk/internal/net/http/Http2ClientImpl.java ! src/java.net.http/share/classes/jdk/internal/net/http/ResponseContent.java Changeset: 9ede41bf Author: Magnus Ihse Bursie Date: 2021-08-30 11:37:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9ede41bf894867b6d80982d7dc6ec54229a0ecb1 8229031: Exporting CLASSPATH from shell can result in build failures Reviewed-by: erikj ! make/autoconf/boot-jdk.m4 ! make/autoconf/spec.gmk.in Changeset: bb7aa1c6 Author: Thomas Schatzl Date: 2021-08-30 12:08:12 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bb7aa1c6a4856827cf05e976215699725b56b87a 8272161: Make evacuation failure data structures local to collection Reviewed-by: iwalulya, sjohanss ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1CollectedHeap.hpp ! src/hotspot/share/gc/g1/g1ParScanThreadState.cpp ! src/hotspot/share/gc/g1/g1ParScanThreadState.hpp ! src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.cpp ! src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.hpp Changeset: 276b07b3 Author: Lutz Schmidt Date: 2021-08-30 12:31:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/276b07b36af01d339e48baada7a512451fe34afe 8271490: [ppc] [s390]: Crash in JavaThread::pd_get_top_frame_for_profiling Reviewed-by: stuefe, mbaesken ! src/hotspot/cpu/ppc/frame_ppc.cpp ! src/hotspot/cpu/s390/frame_s390.cpp ! src/hotspot/os_cpu/linux_ppc/thread_linux_ppc.cpp ! src/hotspot/os_cpu/linux_s390/thread_linux_s390.cpp Changeset: 5185dbde Author: Andrey Turbanov Committer: Aleksei Efimov Date: 2021-08-30 13:12:42 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5185dbde67f07ff876305a9568bb5cebb7a7b384 8273098: Unnecessary Vector usage in java.naming Reviewed-by: aefimov, dfuchs ! src/java.naming/share/classes/com/sun/jndi/ldap/LdapSchemaParser.java ! src/java.naming/share/classes/com/sun/jndi/ldap/Obj.java ! src/java.naming/share/classes/com/sun/jndi/ldap/sasl/LdapSasl.java Changeset: fbffa54e Author: Magnus Ihse Bursie Date: 2021-08-30 13:41:54 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fbffa54efe447a4c911af2be1d7774a8c60d6ede 8270438: "Cores to use" output in configure is misleading Reviewed-by: erikj ! make/autoconf/help.m4 Changeset: f11e099a Author: Stefan Johansson Date: 2021-08-30 14:37:03 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f11e099a149adfecc474ba37276ec8672067d090 8272651: G1 heap region info print order changed by JDK-8269914 Reviewed-by: tschatzl, iwalulya, ayang ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1FullCollector.hpp ! src/hotspot/share/gc/g1/g1FullGCScope.cpp ! src/hotspot/share/gc/g1/g1FullGCScope.hpp ! test/hotspot/jtreg/gc/g1/TestEagerReclaimHumongousRegionsLog.java Changeset: 98b9d980 Author: Coleen Phillimore Date: 2021-08-30 14:47:24 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/98b9d98032a700490cda72f645dad505164ec699 8272797: Mutex with rank safepoint_check_never imply allow_vm_block Reviewed-by: dholmes, pchilanomate ! src/hotspot/os/aix/osThread_aix.cpp ! src/hotspot/os/bsd/osThread_bsd.cpp ! src/hotspot/os/linux/osThread_linux.cpp ! src/hotspot/share/classfile/classLoaderData.cpp ! src/hotspot/share/compiler/compileTask.hpp ! src/hotspot/share/gc/g1/g1RegionToSpaceMapper.cpp ! src/hotspot/share/gc/g1/g1ServiceThread.cpp ! src/hotspot/share/gc/g1/heapRegion.cpp ! src/hotspot/share/gc/g1/heapRegionRemSet.cpp ! src/hotspot/share/gc/parallel/psCompactionManager.cpp ! src/hotspot/share/gc/shared/gcLogPrecious.cpp ! src/hotspot/share/gc/shared/oopStorage.cpp ! src/hotspot/share/gc/shared/space.cpp ! src/hotspot/share/gc/shared/taskTerminator.cpp ! src/hotspot/share/gc/shared/workgroup.cpp ! src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp ! src/hotspot/share/gc/shenandoah/shenandoahPacer.hpp ! src/hotspot/share/gc/z/zMessagePort.inline.hpp ! src/hotspot/share/gc/z/zMetronome.cpp ! src/hotspot/share/memory/heapInspection.hpp ! src/hotspot/share/memory/metaspace/testHelpers.cpp ! src/hotspot/share/oops/methodData.cpp ! src/hotspot/share/prims/jvmtiTagMap.cpp ! src/hotspot/share/runtime/handshake.cpp ! src/hotspot/share/runtime/mutex.cpp ! src/hotspot/share/runtime/mutex.hpp ! src/hotspot/share/runtime/mutexLocker.cpp ! src/hotspot/share/runtime/stackWatermark.cpp ! src/hotspot/share/runtime/vmOperations.cpp ! src/hotspot/share/runtime/vmThread.cpp ! src/hotspot/share/services/heapDumperCompression.cpp ! src/hotspot/share/services/memoryManager.cpp ! src/hotspot/share/utilities/concurrentHashTable.inline.hpp ! src/hotspot/share/utilities/events.hpp ! test/hotspot/gtest/metaspace/test_is_metaspace_obj.cpp ! test/hotspot/gtest/metaspace/test_metaspacearena.cpp ! test/hotspot/gtest/metaspace/test_metaspacearena_stress.cpp ! test/hotspot/gtest/runtime/test_mutex.cpp ! test/hotspot/gtest/runtime/test_safepoint_locks.cpp ! test/hotspot/gtest/utilities/test_filterQueue.cpp Changeset: 7a01ba65 Author: Thomas Schatzl Date: 2021-08-30 15:54:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7a01ba6528923569c5e8d2e9d138d38e95aa4faf 8272093: Extract evacuation failure injection from G1CollectedHeap Reviewed-by: ayang, 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/g1ParScanThreadState.cpp + src/hotspot/share/gc/g1/g1YoungGCEvacFailureInjector.cpp + src/hotspot/share/gc/g1/g1YoungGCEvacFailureInjector.hpp + src/hotspot/share/gc/g1/g1YoungGCEvacFailureInjector.inline.hpp Changeset: 5aaa20f8 Author: Sandhya Viswanathan Date: 2021-08-30 16:48:28 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5aaa20f898e8679ef1c2c36bd01d48c17be0aacf 8272861: Add a micro benchmark for vector api Reviewed-by: psandoz + test/micro/org/openjdk/bench/jdk/incubator/vector/BlackScholes.java Changeset: f18c0fac Author: Fernando Guallini Committer: Rajan Halade Date: 2021-08-30 17:28:49 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f18c0fac11aac833edfdc484e221518c55daa9a7 8271560: sun/security/ssl/DHKeyExchange/LegacyDHEKeyExchange.java still fails due to "An established connection was aborted by the software in your host machine" Reviewed-by: xuelei, rhalade ! test/jdk/sun/security/ssl/DHKeyExchange/LegacyDHEKeyExchange.java Changeset: fecefb85 Author: Ian Graves Date: 2021-08-30 17:37:29 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fecefb8541d5056b1a8b105126ac9c566875e056 8271302: Regex Test Refresh Reviewed-by: bchristi, smarks ! test/jdk/java/util/regex/GraphemeTest.java ! test/jdk/java/util/regex/NegativeArraySize.java ! test/jdk/java/util/regex/RegExTest.java Changeset: 32048536 Author: Ioi Lam Date: 2021-08-30 21:06:26 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/32048536e9ea9245437eb37308e905435cce6305 8272343: Remove MetaspaceClosure::FLAG_MASK Reviewed-by: ccheung, minqi ! src/hotspot/share/cds/archiveBuilder.cpp ! src/hotspot/share/memory/metaspaceClosure.cpp ! src/hotspot/share/memory/metaspaceClosure.hpp Changeset: 7fc85409 Author: Naoto Sato Date: 2021-08-30 21:13:59 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7fc8540907e8e7483ad5729ea416167810aa8747 8260265: UTF-8 by Default Reviewed-by: alanb, rriggs ! make/data/charsetmapping/charsets ! src/java.base/share/classes/java/io/ByteArrayOutputStream.java ! src/java.base/share/classes/java/io/Console.java ! src/java.base/share/classes/java/io/FileReader.java ! src/java.base/share/classes/java/io/FileWriter.java ! src/java.base/share/classes/java/io/InputStreamReader.java ! src/java.base/share/classes/java/io/OutputStreamWriter.java ! src/java.base/share/classes/java/io/PrintStream.java ! src/java.base/share/classes/java/io/PrintWriter.java ! src/java.base/share/classes/java/lang/System.java ! src/java.base/share/classes/java/net/URLDecoder.java ! src/java.base/share/classes/java/net/URLEncoder.java ! src/java.base/share/classes/java/nio/charset/Charset.java ! src/java.base/share/classes/java/util/Scanner.java ! src/java.base/share/classes/jdk/internal/util/StaticProperty.java ! src/java.base/share/classes/jdk/internal/util/SystemProps.java + test/jdk/java/lang/System/FileEncodingTest.java ! test/jdk/java/lang/System/MacEncoding/MacJNUEncoding.java ! test/jdk/java/lang/System/MacEncoding/TestFileEncoding.java ! test/jdk/java/nio/charset/Charset/RegisteredCharsets.java ! test/jdk/java/nio/charset/RemovingSunIO/SunioAlias.java ! test/jdk/tools/launcher/UnicodeTest.java Changeset: 0609421d Author: Vicente Romero Date: 2021-08-30 21:16:46 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0609421d4b824c5642ca75d525bad3edd72cd23a 8272347: ObjectMethods::bootstrap should specify NPE if any argument except lookup is null Reviewed-by: mchung, chegar ! src/java.base/share/classes/java/lang/runtime/ObjectMethods.java ! test/jdk/java/lang/runtime/ObjectMethodsTest.java Changeset: 9732fbe4 Author: Yumin Qi Date: 2021-08-31 00:24:05 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9732fbe428c3b6a5422cc94e7295ba5482d1a7a9 8273153: Consolidate file_exists into os:file_exists Reviewed-by: iklam, ccheung ! src/hotspot/os/linux/os_linux.cpp ! src/hotspot/share/logging/logFileOutput.cpp ! src/hotspot/share/runtime/os.cpp ! src/hotspot/share/runtime/os.hpp Changeset: 98fa5335 Author: Claes Redestad Date: 2021-08-31 11:32:33 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/98fa53357a66f474090304e53959be5d433d5e5f 8273100: Improve AbstractStringBuilder.append(String) when using CompactStrings Reviewed-by: rriggs, alanb ! src/java.base/share/classes/java/lang/AbstractStringBuilder.java Changeset: 841e3943 Author: Ivan Walulya Date: 2021-08-31 12:30:14 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/841e3943c480c95409446bb35fb9a56d7fc48c8a 8159979: During initial mark, preparing all regions for marking may take a significant amount of time Reviewed-by: tschatzl, ayang ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp ! src/hotspot/share/gc/g1/g1ConcurrentMark.hpp ! src/hotspot/share/gc/g1/g1GCPhaseTimes.cpp ! src/hotspot/share/gc/g1/g1GCPhaseTimes.hpp Changeset: 9bc7cc56 Author: Albert Mingkun Yang Date: 2021-08-31 12:51:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9bc7cc56513adb9d2e39cd286d2a229c9c285e2d 8273033: SerialGC: remove obsolete comments Reviewed-by: sjohanss, tschatzl ! src/hotspot/share/gc/serial/genMarkSweep.cpp Changeset: e6712551 Author: Ivan Walulya Date: 2021-08-31 13:32:31 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e67125512f585c8efad2e7685b9bc409c96563d7 8237567: Refactor G1-specific code in shared VM_CollectForMetadataAllocation Reviewed-by: ayang, tschatzl ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1CollectedHeap.hpp ! src/hotspot/share/gc/shared/gcVMOperations.cpp ! src/hotspot/share/gc/shared/gcVMOperations.hpp Changeset: e5518528 Author: Brian Burkhalter Date: 2021-08-31 14:42:14 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e55185280126e450e31eb65aa8342aebe6f31606 8271225: Add floorDivExact() method to java.lang.[Strict]Math Reviewed-by: darcy ! src/java.base/share/classes/java/lang/Math.java ! src/java.base/share/classes/java/lang/StrictMath.java ! test/jdk/java/lang/Math/ExactArithTests.java Changeset: 75d987a0 Author: Vicente Romero Date: 2021-08-31 15:40:17 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/75d987a0dd6f8cc41808f7ba566e914817e465dc 8262095: NPE in Flow$FlowAnalyzer.visitApply: Cannot invoke getThrownTypes because tree.meth.type is null Co-authored-by: Jan Lahoda Co-authored-by: Vicente Romero Reviewed-by: jlahoda ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java + test/langtools/tools/javac/lambda/8262095/T8262095.java + test/langtools/tools/javac/lambda/8262095/T8262095.out Changeset: ba3587e5 Author: Thomas Schatzl Date: 2021-08-31 15:45:56 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ba3587e524aeec43a0c4174ddd96b8890a34fa36 8273144: Remove unused top level "Sample Collection Set Candidates" logging Reviewed-by: iwalulya, ayang ! src/hotspot/share/gc/g1/g1GCPhaseTimes.cpp ! src/hotspot/share/gc/g1/g1GCPhaseTimes.hpp ! test/hotspot/jtreg/gc/g1/TestGCLogMessages.java Changeset: 1996f649 Author: Ioi Lam Date: 2021-08-31 16:33:02 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1996f649a3a30b7ac4b547a762417f807f5fa414 8273092: Sort classlist in JDK image Reviewed-by: redestad, ihse, dfuchs ! make/GenerateLinkOptData.gmk + make/jdk/src/classes/build/tools/classlist/SortClasslist.java ! make/scripts/compare.sh Changeset: 683e30db Author: bobpengxie Committer: Sergey Bylokhov Date: 2021-08-31 17:31:03 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/683e30db79789ee44b3cc0b44c085de4615bca7b 8273169: java/util/regex/NegativeArraySize.java failed after JDK-8271302 Reviewed-by: jiefu, serb ! test/jdk/java/util/regex/NegativeArraySize.java Changeset: c1e0aac8 Author: Thomas Schatzl Date: 2021-08-31 19:46:55 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c1e0aac846861f9bd8a23818a21670a2f649631b 8273186: Remove leftover comment about sparse remembered set in G1 HeapRegionRemSet Reviewed-by: ayang ! src/hotspot/share/gc/g1/heapRegionRemSet.hpp Changeset: 3d657eb0 Author: Weijun Wang Date: 2021-08-31 20:07:02 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3d657eb0a626e33995af5d5ddf12b26d06317962 8262186: Call X509KeyManager.chooseClientAlias once for all key types Reviewed-by: xuelei ! src/java.base/share/classes/sun/security/ssl/CertificateMessage.java ! src/java.base/share/classes/sun/security/ssl/CertificateRequest.java ! src/java.base/share/classes/sun/security/ssl/X509Authentication.java + test/jdk/sun/security/ssl/SSLContextImpl/MultipleChooseAlias.java Changeset: 9c392d00 Author: Daniel D. Daugherty Date: 2021-08-31 20:12:19 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9c392d008a5a34cdc2ed6339a63f1a0d06efe619 8273197: ProblemList 2 jtools tests due to JDK-8273187 8273198: ProblemList java/lang/instrument/BootClassPath/BootClassPathTest.sh due to JDK-8273188 Reviewed-by: naoto ! test/jdk/ProblemList.txt Changeset: 18a731a3 Author: Alex Menkov Date: 2021-08-31 22:43:12 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/18a731a3e4ec85f0f3e8d6ff619b539c0daaf320 8269770: nsk tests should start IOPipe channel before launch debuggee - Debugee.prepareDebugee Reviewed-by: sspitsyn, kevinw ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Accessible/isPackagePrivate/accipp001.java ! test/hotspot/jtreg/vmTestbase/nsk/share/jpda/DebugeeProcess.java ! test/hotspot/jtreg/vmTestbase/nsk/share/jpda/IOPipe.java Changeset: 2fce7cb4 Author: David Holmes Date: 2021-08-31 23:51:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2fce7cb4d21e4e2c234c22a1a150f7fe113d4d16 8272963: Update the java manpage markdown source Reviewed-by: ysuenaga ! src/java.base/share/man/java.1 Changeset: e600fe1a Author: Jan Lahoda Date: 2021-09-01 06:06:17 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e600fe1a1a57d7e4060b3a1b9a8ecdb65664a506 8272618: Unnecessary Attr.visitIdent.noOuterThisPath Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java Changeset: f1c5e26e Author: Jie Fu Date: 2021-09-01 07:55:20 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f1c5e26e48ca2db0fc2b7ad2cf1bda4853bdeea9 8273206: jdk/jfr/event/gc/collection/TestG1ParallelPhases.java fails after JDK-8159979 Reviewed-by: dholmes, ayang ! test/jdk/jdk/jfr/event/gc/collection/TestG1ParallelPhases.java Changeset: 0e14bf70 Author: Matthias Baesken Date: 2021-09-01 07:59:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0e14bf70cf6e482a2ec7d13ed37df0bee911740d 8273176: handle latest VS2019 in abstract_vm_version Reviewed-by: kevinw, dholmes ! src/hotspot/share/runtime/abstract_vm_version.cpp Changeset: a58cf165 Author: Fairoz Matte Committer: Tobias Hartmann Date: 2021-09-01 10:12:25 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a58cf16509f3120d69fc18bd4c2c49e9ad590f73 8272563: assert(is_double_stack() && !is_virtual()) failed: type check Reviewed-by: thartmann, iveresov ! src/hotspot/share/gc/shared/c1/cardTableBarrierSetC1.cpp Changeset: 02822e13 Author: Yi Yang Date: 2021-09-01 10:41:03 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/02822e1398d6015f0ed26edd440db8e0d50bf152 8272377: assert preconditions that are ensured when created in add_final_edges Reviewed-by: thartmann, kvn ! src/hotspot/share/opto/escape.cpp ! src/hotspot/share/opto/escape.hpp Changeset: dacd1978 Author: Coleen Phillimore Date: 2021-09-01 16:48:06 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/dacd1978972b46510049086c8431bb12e5f3722f 8273217: Make ParHeapInspectTask _safepoint_check_never Reviewed-by: dholmes, pchilanomate ! src/hotspot/share/memory/heapInspection.cpp ! src/hotspot/share/memory/heapInspection.hpp Changeset: 655ea6d4 Author: Ioi Lam Date: 2021-09-01 16:50:11 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/655ea6d42ae94d96a03b1f008aad264a1ee4f173 8270489: Support archived heap objects in EpsilonGC Reviewed-by: shade, ccheung ! src/hotspot/share/cds/archiveBuilder.cpp ! src/hotspot/share/cds/archiveUtils.cpp ! src/hotspot/share/cds/filemap.cpp ! src/hotspot/share/cds/filemap.hpp ! src/hotspot/share/cds/heapShared.cpp ! src/hotspot/share/cds/heapShared.hpp ! src/hotspot/share/cds/heapShared.inline.hpp ! src/hotspot/share/cds/metaspaceShared.cpp ! src/hotspot/share/cds/metaspaceShared.hpp ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/classfile/stringTable.cpp ! src/hotspot/share/classfile/stringTable.hpp ! src/hotspot/share/classfile/systemDictionaryShared.cpp ! src/hotspot/share/classfile/vmClasses.cpp ! src/hotspot/share/gc/epsilon/epsilonHeap.cpp ! src/hotspot/share/gc/epsilon/epsilonHeap.hpp ! src/hotspot/share/gc/shared/collectedHeap.hpp ! src/hotspot/share/memory/universe.cpp ! src/hotspot/share/oops/constantPool.cpp ! src/hotspot/share/oops/klass.cpp ! src/hotspot/share/prims/whitebox.cpp ! test/hotspot/jtreg/TEST.groups ! test/hotspot/jtreg/runtime/cds/appcds/TestCommon.java + test/hotspot/jtreg/runtime/cds/appcds/TestEpsilonGCWithCDS.java ! test/hotspot/jtreg/runtime/cds/appcds/customLoader/HelloCustom.java ! test/hotspot/jtreg/runtime/cds/appcds/customLoader/UnloadUnregisteredLoaderTest.java ! test/hotspot/jtreg/runtime/cds/appcds/javaldr/GCSharedStringsDuringDump.java ! test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/SharedStringsStress.java ! test/jtreg-ext/requires/VMProps.java ! test/lib/jdk/test/lib/cds/CDSOptions.java ! test/lib/jdk/test/lib/cds/CDSTestUtils.java Changeset: 4ee0dace Author: Daniel D. Daugherty Date: 2021-09-01 17:45:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4ee0dacecd5afc5876ea839ffbb5df962ff6cd08 8273248: ProblemList java/lang/instrument/BootClassPath/BootClassPathTest.sh on all configs Reviewed-by: naoto ! test/jdk/ProblemList.txt Changeset: 9689f615 Author: Coleen Phillimore Date: 2021-09-01 18:39:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9689f615206e96f17ffc1fe7a8efeee0a90c904b 8272788: Nonleaf ranked locks should not be safepoint_check_never Reviewed-by: eosterlund, pchilanomate ! src/hotspot/share/prims/jvmtiTagMap.cpp ! src/hotspot/share/runtime/mutex.cpp ! src/hotspot/share/runtime/mutexLocker.cpp ! src/hotspot/share/runtime/mutexLocker.hpp Changeset: 2f01a6f8 Author: Joe Darcy Date: 2021-09-01 20:28:05 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2f01a6f8b6c0bc08c6e3b7ea279d3826f451607f 8273157: Add convenience methods to Messager Reviewed-by: jjg ! src/java.compiler/share/classes/javax/annotation/processing/Messager.java ! test/langtools/tools/javac/7129225/AnnoProcessor.java ! test/langtools/tools/javac/MethodParameters/ClassReaderTest/MethodParameterProcessor.java ! test/langtools/tools/javac/T6406771.java ! test/langtools/tools/javac/T6458823/MyProcessor.java ! test/langtools/tools/javac/T7159016.java ! test/langtools/tools/javac/T8170667/ParameterProcessor.java ! test/langtools/tools/javac/api/T6412669.java ! test/langtools/tools/javac/api/TestClientCodeWrapper.java ! test/langtools/tools/javac/api/TestGetElement.java ! test/langtools/tools/javac/api/TestOperators.java ! test/langtools/tools/javac/api/TestTrees.java ! test/langtools/tools/javac/classreader/T7031108.java ! test/langtools/tools/javac/diags/DocCommentProcessor.java ! test/langtools/tools/javac/diags/examples/ErrProcMessager/processors/AnnoProc.java ! test/langtools/tools/javac/diags/examples/NoteProcMessager/processors/AnnoProc.java ! test/langtools/tools/javac/diags/examples/ProcFileCreateLastRound/processors/AnnoProc.java ! test/langtools/tools/javac/diags/examples/ProcFileReopening/processors/AnnoProc.java ! test/langtools/tools/javac/diags/examples/ProcIllegalFileName/processors/AnnoProc.java ! test/langtools/tools/javac/diags/examples/ProcSuspiciousClassName/processors/AnnoProc.java ! test/langtools/tools/javac/diags/examples/ProcTypeRecreate/processors/AnnoProc.java ! test/langtools/tools/javac/diags/examples/ProcUnclosedTypeFiles/processors/AnnoProc.java ! test/langtools/tools/javac/diags/examples/ProcUseImplicit/processors/AnnoProc.java ! test/langtools/tools/javac/diags/examples/ProcUseProcOrImplicit/processors/AnnoProc.java ! test/langtools/tools/javac/diags/examples/WarnProcMessager/processors/AnnoProc.java ! test/langtools/tools/javac/enum/6424358/T6424358.java ! test/langtools/tools/javac/file/T7018098.java ! test/langtools/tools/javac/file/T7068437.java ! test/langtools/tools/javac/file/T7068451.java ! test/langtools/tools/javac/modules/AnnotationProcessing.java ! test/langtools/tools/javac/patterns/PatternMatchPosTest.java ! test/langtools/tools/javac/processing/6350124/HelloWorldAP.java ! test/langtools/tools/javac/processing/6365040/ProcBar.java ! test/langtools/tools/javac/processing/6365040/ProcFoo.java ! test/langtools/tools/javac/processing/6365040/T6365040.java ! test/langtools/tools/javac/processing/6414633/A.java ! test/langtools/tools/javac/processing/6430209/b6341534.java ! test/langtools/tools/javac/processing/6499119/ClassProcessor.java ! test/langtools/tools/javac/processing/6994946/TestProcessor.java ! test/langtools/tools/javac/processing/GenerateAndError.java ! test/langtools/tools/javac/processing/StopAfterError/StopAfterError.java ! test/langtools/tools/javac/processing/T6439826.java ! test/langtools/tools/javac/processing/T6920317.java ! test/langtools/tools/javac/processing/TestWarnErrorCount.java ! test/langtools/tools/javac/processing/environment/round/TestContext.java ! test/langtools/tools/javac/processing/errors/TestErrorCount.java ! test/langtools/tools/javac/processing/errors/TestReturnCode.java ! test/langtools/tools/javac/processing/errors/TestSuppression.java ! test/langtools/tools/javac/processing/filer/TestGetResource2.java ! test/langtools/tools/javac/processing/filer/TestInvalidRelativeNames.java ! test/langtools/tools/javac/processing/filer/TestValidRelativeNames.java ! test/langtools/tools/javac/processing/loader/testClose/TestClose2.java ! test/langtools/tools/javac/processing/messager/MessagerDiags.java ! test/langtools/tools/javac/processing/model/6341534/T6341534.java ! test/langtools/tools/javac/processing/model/element/CheckingAccessorsOnLoadedRecordClasses.java ! test/langtools/tools/javac/processing/model/element/CheckingTypeAnnotationsOnRecords.java ! test/langtools/tools/javac/processing/model/element/JavaxLangModelForRecords.java ! test/langtools/tools/javac/processing/model/element/TestAnonSourceNames.java ! test/langtools/tools/javac/processing/model/element/TestExecutableElement.java ! test/langtools/tools/javac/processing/model/element/TestExecutableReceiverType.java ! test/langtools/tools/javac/processing/model/element/TestMissingElement/TestMissingElement.java ! test/langtools/tools/javac/processing/model/element/TestMissingElement2/Generator.java ! test/langtools/tools/javac/processing/model/element/TestSealed.java ! test/langtools/tools/javac/processing/model/element/TestTypeElement.java ! test/langtools/tools/javac/processing/model/element/TestTypeParameter.java ! test/langtools/tools/javac/processing/model/element/TestTypeParameterAnnotations.java ! test/langtools/tools/javac/processing/model/util/deprecation/TestDeprecation.java ! test/langtools/tools/javac/processing/model/util/elements/TestIsFunctionalInterface.java ! test/langtools/tools/javac/processing/model/util/elements/doccomments/TestDocComments.java ! test/langtools/tools/javac/processing/model/util/elements/doccomments/TestPackageInfoComments.java ! test/langtools/tools/javac/processing/options/testCommandLineClasses/Test.java ! test/langtools/tools/javac/processing/options/testPrintProcessorInfo/Test.java ! test/langtools/tools/javac/processing/rounds/BaseClassesNotReRead.java ! test/langtools/tools/javac/processing/rounds/ClassDependingOnGenerated.java ! test/langtools/tools/javac/processing/rounds/ErrClassSymbolTypeFixed.java ! test/langtools/tools/javac/processing/rounds/GenerateAnonymousClass.java ! test/langtools/tools/javac/processing/rounds/OverwriteBetweenCompilations.java ! test/langtools/tools/javac/processing/warnings/TestSourceVersionWarnings.java ! test/langtools/tools/javac/processing/warnings/UseImplicit/TestProcUseImplicitWarning.java ! test/langtools/tools/javac/processing/werror/WError1.java ! test/langtools/tools/javac/processing/werror/WErrorLast.java ! test/langtools/tools/javac/tree/ArrayTypeToString.java ! test/langtools/tools/javac/tree/NoPrivateTypesExported.java ! test/langtools/tools/javac/tree/TreePosRoundsTest.java ! test/langtools/tools/javac/treeannotests/TestProcessor.java ! test/langtools/tools/javac/util/NewlineOnlyDiagnostic.java ! test/langtools/tools/javac/util/T6597678.java Changeset: 1a5a2b6b Author: Valerie Peng Date: 2021-09-01 22:17:49 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1a5a2b6b15e22b21343244e3a2b649d00eef5ffa 8271745: Correct block size for KW,KWP mode and use fixed IV for KWP mode for SunJCE Reviewed-by: xuelei, mullan ! 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: a9a83b24 Author: Jie Fu Date: 2021-09-02 04:10:46 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a9a83b248e4a575e3d22541c122b27246a52dc7b 8273256: runtime/cds/appcds/TestEpsilonGCWithCDS.java fails due to Unrecognized VM option 'ObjectAlignmentInBytes=64' on x86_32 Reviewed-by: dholmes, iklam ! test/hotspot/jtreg/runtime/cds/appcds/TestEpsilonGCWithCDS.java Changeset: 6cfe3142 Author: Aleksey Shipilev Date: 2021-09-02 07:56:56 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6cfe314262dacd6ca1a74c000d045b1cabd374db 8272970: Parallelize runtime/InvocationTests/ Reviewed-by: dholmes, iignatyev ! test/hotspot/jtreg/ProblemList.txt ! test/hotspot/jtreg/runtime/InvocationTests/invocationC1Tests.java ! test/hotspot/jtreg/runtime/InvocationTests/invocationOldCHATests.java ! test/hotspot/jtreg/runtime/InvocationTests/invokeinterfaceTests.java ! test/hotspot/jtreg/runtime/InvocationTests/invokespecialTests.java ! test/hotspot/jtreg/runtime/InvocationTests/invokevirtualTests.java Changeset: 857a930b Author: Aleksey Shipilev Date: 2021-09-02 08:00:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/857a930bde8b53f77a23737f4ca6ff8f3da2af66 8263375: Support stack watermarks in Zero VM Reviewed-by: eosterlund ! src/hotspot/cpu/zero/frame_zero.cpp ! src/hotspot/cpu/zero/vm_version_zero.hpp ! src/hotspot/cpu/zero/zeroInterpreter_zero.cpp ! src/hotspot/cpu/zero/zeroInterpreter_zero.hpp ! src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp Changeset: 152e6692 Author: Sergey Tsypanov Committer: Thomas Schatzl Date: 2021-09-02 08:10:40 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/152e66923dc36cfd83cdfe18e96631abc06b9199 8273140: Replace usages of Enum.class.getEnumConstants() with Enum.values() where possible Reviewed-by: tschatzl ! src/java.desktop/share/classes/sun/font/AttributeValues.java ! src/java.desktop/share/classes/sun/font/EAttribute.java ! src/java.sql/share/classes/java/sql/JDBCType.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/bytecode/SourceGenerator.java Changeset: 0c1b16b7 Author: Aleksei Efimov Date: 2021-09-02 10:36:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0c1b16b75a2361431cbf9f4112dcd6049e981a78 8273243: Fix indentations in java.net.InetAddress methods Reviewed-by: dfuchs, bpb ! src/java.base/share/classes/java/net/InetAddress.java Changeset: c2e015c3 Author: Matthias Baesken Date: 2021-09-02 11:22:49 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c2e015c3c1a2274112bb8e6671a85bc7fb624fde 8273229: Update OS detection code to recognize Windows Server 2022 Reviewed-by: alanb, dholmes ! src/hotspot/os/windows/os_windows.cpp ! src/java.base/windows/native/libjava/java_props_md.c Changeset: 632a7e08 Author: Vladimir Ivanov Date: 2021-09-02 11:46:19 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/632a7e0885596b70d34be319bd09d4df8e151d12 8273165: GraphKit::combine_exception_states fails with "matching stack sizes" assert Reviewed-by: thartmann, kvn ! src/hotspot/share/opto/callGenerator.cpp Changeset: 5245c1cf Author: Thomas Schatzl Date: 2021-09-02 11:57:55 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5245c1cf0260a78ca5f8ab4e7d13107f21faf071 8273147: Update and restructure TestGCLogMessages log message list Reviewed-by: iwalulya, ayang ! test/hotspot/jtreg/gc/g1/TestGCLogMessages.java Changeset: 5ee5dd9b Author: Aleksey Shipilev Date: 2021-09-02 15:43:21 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5ee5dd9b18fb5adc563a65bd1a29779eda675d61 8272914: Create hotspot:tier2 and hotspot:tier3 test groups Reviewed-by: dholmes, coleenp, iignatyev ! test/hotspot/jtreg/TEST.groups Changeset: aaa6f696 Author: Lance Andersen Date: 2021-09-02 16:06:55 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/aaa6f696b06b335f81efccf0966612b086dd2e73 8273250: Address javadoc issues in Deflater::setDictionationary Reviewed-by: rriggs, naoto, iris, bpb ! src/java.base/share/classes/java/util/zip/Deflater.java Changeset: 29e0f138 Author: Jamil Nimeh Date: 2021-09-02 17:54:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/29e0f1386d247731e8733f6fdd1307642b2b9f96 8272385: Enforce ECPrivateKey d value to be in the range [1, n-1] for SunEC provider Reviewed-by: ascarpino, weijun ! src/java.base/share/classes/sun/security/util/ECUtil.java ! src/jdk.crypto.ec/share/classes/sun/security/ec/ECDHKeyAgreement.java ! src/jdk.crypto.ec/share/classes/sun/security/ec/ECDSASignature.java + test/jdk/sun/security/ec/ECDSAPrvGreaterThanOrder.java Changeset: 92b05fe0 Author: Patricio Chilano Mateo Date: 2021-09-02 21:22:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/92b05fe0f41b91aa88e77473725ae92ee13b052f 8273251: Call check_possible_safepoint() from SafepointMechanism::process_if_requested() Reviewed-by: coleenp, dholmes ! src/hotspot/share/runtime/interfaceSupport.inline.hpp ! src/hotspot/share/runtime/safepointMechanism.inline.hpp ! src/hotspot/share/runtime/thread.cpp Changeset: 7fff22af Author: Sergey Bylokhov Date: 2021-09-02 22:56:20 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7fff22afe711c8c04dbf4cf5b4938d40632e4987 8272805: Avoid looking up standard charsets Reviewed-by: weijun, naoto, dfuchs, azvegint, erikj ! make/jdk/src/classes/build/tools/generatelsrequivmaps/EquivMapsGenerator.java ! src/demo/share/jfc/Font2DTest/Font2DTest.java ! src/demo/share/jfc/Font2DTest/FontPanel.java ! src/demo/share/jfc/SwingSet2/DemoModule.java ! src/demo/share/jfc/SwingSet2/TreeDemo.java ! src/java.base/share/classes/sun/security/util/DerOutputStream.java ! src/java.base/share/classes/sun/security/util/DerValue.java ! src/java.datatransfer/share/classes/sun/datatransfer/DataFlavorUtil.java ! src/java.desktop/macosx/classes/sun/font/CFontConfiguration.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/png/PNGImageReader.java ! src/java.desktop/unix/classes/sun/font/FcFontConfiguration.java ! src/java.desktop/unix/classes/sun/font/MFontConfiguration.java ! src/java.security.jgss/share/classes/sun/security/krb5/internal/PAData.java ! src/java.security.jgss/share/classes/sun/security/krb5/internal/crypto/dk/DkCrypto.java ! src/java.security.jgss/share/classes/sun/security/krb5/internal/util/KerberosString.java ! src/java.security.sasl/share/classes/com/sun/security/sasl/digest/DigestMD5Base.java ! src/java.security.sasl/share/classes/com/sun/security/sasl/digest/DigestMD5Server.java ! src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java ! src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java ! src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/platform/JDKPlatformProvider.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/processing/ServiceProxy.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/client/SjavacClient.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/InputLexer.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/posix/elf/ELFFileParser.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/win32/coff/COFFFileParser.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/HeapHprofBinWriter.java ! src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java ! src/jdk.internal.ed/share/classes/jdk/internal/editor/external/ExternalEditor.java ! src/jdk.internal.jvmstat/linux/classes/sun/jvmstat/PlatformSupportImpl.java ! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.services/src/jdk/vm/ci/services/Services.java ! src/jdk.jcmd/share/classes/sun/tools/common/PrintStreamPrinter.java ! src/jdk.jcmd/share/classes/sun/tools/jmap/JMap.java ! src/jdk.jdeps/share/classes/com/sun/tools/classfile/SourceDebugExtension_attribute.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/PacketStream.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/SocketTransportService.java ! src/jdk.jdi/windows/classes/com/sun/tools/jdi/SharedMemoryConnection.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/StringParser.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/jfc/model/JFCModel.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/jfc/model/Parser.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/tool/Metadata.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/tool/Print.java ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/ConsoleIOContext.java ! src/jdk.jshell/share/classes/jdk/jshell/execution/DemultiplexInput.java ! src/jdk.jshell/share/classes/jdk/jshell/execution/MultiplexingOutputStream.java ! src/jdk.jshell/share/classes/jdk/jshell/execution/Util.java ! src/jdk.management.agent/share/classes/sun/management/jdp/JdpPacketReader.java ! src/jdk.security.auth/share/classes/com/sun/security/auth/module/Crypt.java ! src/jdk.security.auth/share/classes/com/sun/security/auth/module/JndiLoginModule.java ! src/utils/IdealGraphVisualizer/Data/src/main/java/com/sun/hotspot/igv/data/serialization/BinaryParser.java ! src/utils/IdealGraphVisualizer/Data/src/test/java/com/sun/hotspot/igv/data/serialization/ParserTest.java ! src/utils/IdealGraphVisualizer/View/src/main/java/com/sun/hotspot/igv/view/EditorTopComponent.java Changeset: dd871819 Author: Ian Graves Date: 2021-09-03 00:50:11 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/dd871819a05886ee09fc00c7c778268440ebedb7 8214761: Bug in parallel Kahan summation implementation Reviewed-by: darcy ! src/java.base/share/classes/java/util/DoubleSummaryStatistics.java ! src/java.base/share/classes/java/util/stream/Collectors.java ! src/java.base/share/classes/java/util/stream/DoublePipeline.java + test/jdk/java/util/DoubleStreamSums/CompensatedSums.java + test/jdk/java/util/DoubleSummaryStatistics/NegativeCompensation.java Changeset: fa9c8657 Author: Xiaowei Lu Committer: David Holmes Date: 2021-09-03 05:29:02 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fa9c8657dfaa2018f501de1a8aa62f004342c245 8273112: -Xloggc: should override -verbose:gc Reviewed-by: iklam, dholmes ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/arguments.hpp Changeset: f17ee0c5 Author: Jan Lahoda Date: 2021-09-03 09:29:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f17ee0c5c796951801c2026a2acac895a5c0af73 8273263: Incorrect recovery attribution of record component type when j.l.Record is unavailable Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java ! test/langtools/tools/javac/api/TestGetElementReference.java + test/langtools/tools/javac/api/TestGetElementReferenceDataWithRecord.java Changeset: 7b023a3f Author: Jan Lahoda Date: 2021-09-03 09:30:56 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7b023a3f607f44da1b13bc9d2884a5f13723d524 8273257: jshell doesn't compile a sealed hierarchy with a sealed interface and a non-sealed leaf Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! test/langtools/jdk/jshell/SealedClassesTest.java ! test/langtools/tools/javac/sealed/SealedCompilationTests.java Changeset: 93eec9a1 Author: Jan Lahoda Date: 2021-09-03 09:31:54 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/93eec9a103de7f4d9a87eac5b295c9a50702ee94 8272776: NullPointerException not reported Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java ! test/langtools/tools/javac/patterns/NullSwitch.java Changeset: d05494f9 Author: Guoxiong Li Date: 2021-09-03 09:33:17 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d05494f98bad351532cdb769c9da6b6e2359b16e 8266239: Some duplicated javac command-line options have repeated effect Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.java ! test/langtools/tools/javac/options/modes/InfoOptsTest.java ! test/langtools/tools/javac/options/modes/OptionModesTester.java Changeset: 0ed9424c Author: duke Date: 2021-09-03 11:00:29 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0ed9424c7ee505c6e11ec680383aa8aae7b2d2d6 Automatic merge of jdk:master into master Changeset: c3d9643e Author: duke Date: 2021-09-03 11:00:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c3d9643e8e95c8daf2d0a93bf15395c9d57e1468 Automatic merge of master into foreign-memaccess+abi From duke at openjdk.java.net Fri Sep 3 11:14:20 2021 From: duke at openjdk.java.net (duke) Date: Fri, 3 Sep 2021 11:14:20 GMT Subject: git: openjdk/panama-foreign: master: 71 new changesets Message-ID: Changeset: 596b0755 Author: Magnus Ihse Bursie Date: 2021-08-27 13:13:36 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/596b075591c4b2fe01bee7142f4d0a5f892647ed 8258465: Headless build fails due to missing X11 headers on linux Reviewed-by: shade ! make/autoconf/libraries.m4 Changeset: b92214a8 Author: Coleen Phillimore Date: 2021-08-27 13:51:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b92214a8d0ca6ed2a51e4286c258b4ddd0ca3a51 8272480: Remove Mutex::access rank Reviewed-by: dholmes, eosterlund ! src/hotspot/share/runtime/mutex.cpp ! src/hotspot/share/runtime/mutex.hpp ! src/hotspot/share/runtime/mutexLocker.cpp ! src/hotspot/share/runtime/stackWatermark.cpp ! test/hotspot/gtest/runtime/test_mutex.cpp Changeset: a033aa5a Author: Magnus Ihse Bursie Date: 2021-08-27 13:53:33 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a033aa5a3d9c63d72d11af218b9896b037fbd8de 8273072: Avoid using += in configure Reviewed-by: dholmes, jiefu ! make/autoconf/flags-cflags.m4 ! make/autoconf/flags-other.m4 ! make/autoconf/jdk-version.m4 ! make/devkit/createMacosxDevkit.sh Changeset: dfeb4132 Author: Brian Burkhalter Date: 2021-08-27 16:08:29 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/dfeb4132e402c0466740a029c3b1d2d213955822 8272964: java/nio/file/Files/InterruptCopy.java fails with java.lang.RuntimeException: Copy was not interrupted Reviewed-by: dfuchs ! test/jdk/java/nio/file/Files/InterruptCopy.java Changeset: d1aeca11 Author: Brian Burkhalter Date: 2021-08-27 16:09:28 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d1aeca117ccc4334d67b2692ff087a9f8d808a59 8272541: Incorrect overflow test in Toom-Cook branch of BigInteger multiplication Reviewed-by: darcy ! src/java.base/share/classes/java/math/BigInteger.java ! test/jdk/java/math/BigInteger/BitLengthOverflow.java Changeset: e66c8afb Author: Jim Laskey Date: 2021-08-27 18:45:52 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e66c8afb59b57c4546656efa97f723f084964330 8272866: java.util.random package summary contains incorrect mixing function in table Reviewed-by: rriggs ! src/java.base/share/classes/java/util/random/package-info.java Changeset: 51167846 Author: Raffaello Giulietti Committer: Brian Burkhalter Date: 2021-08-27 22:48:52 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/51167846cb5a60dfb31b4f8dfa214ba26640175c 8273091: Doc of [Strict]Math.floorDiv(long,int) erroneously documents int in @return tag Reviewed-by: darcy, bpb ! src/java.base/share/classes/java/lang/Math.java ! src/java.base/share/classes/java/lang/StrictMath.java Changeset: 1fb798d3 Author: Bradford Wetmore Date: 2021-08-27 23:01:51 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1fb798d320c708dfcbc0bb157511a2937fafb9e6 8272915: (doc) package-info typo in extLink Reviewed-by: xuelei ! src/java.base/share/classes/java/security/interfaces/package-info.java Changeset: a9188f23 Author: Guoxiong Li Date: 2021-08-29 07:26:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a9188f237ec23d4ca2a172e9a7897cb6e2b69857 8268894: forged ASTs can provoke an AIOOBE at com.sun.tools.javac.jvm.ClassWriter::writePosition Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/TypeAnnotationPosition.java + test/langtools/tools/javac/annotations/typeAnnotations/position/TypeAnnotationPositionProcessor.java + test/langtools/tools/javac/annotations/typeAnnotations/position/TypeAnnotationPositionTest.java Changeset: f55d5ab5 Author: Aleksey Shipilev Date: 2021-08-30 06:41:40 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f55d5ab5177b6e08e8499abc181a320a98b28a5f 8272838: Move CriticalJNI tests out of tier1 Reviewed-by: dholmes ! test/hotspot/jtreg/TEST.groups Changeset: 16e83058 Author: Michael McMahon Date: 2021-08-30 08:57:17 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/16e83058cab4dd4d4a3fba812c8fe50e4286bd22 8273059: Redundant Math.min call in Http2ClientImpl#getConnectionWindowSize Reviewed-by: dfuchs ! src/java.net.http/share/classes/jdk/internal/net/http/Http2ClientImpl.java ! src/java.net.http/share/classes/jdk/internal/net/http/ResponseContent.java Changeset: 9ede41bf Author: Magnus Ihse Bursie Date: 2021-08-30 11:37:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9ede41bf894867b6d80982d7dc6ec54229a0ecb1 8229031: Exporting CLASSPATH from shell can result in build failures Reviewed-by: erikj ! make/autoconf/boot-jdk.m4 ! make/autoconf/spec.gmk.in Changeset: bb7aa1c6 Author: Thomas Schatzl Date: 2021-08-30 12:08:12 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bb7aa1c6a4856827cf05e976215699725b56b87a 8272161: Make evacuation failure data structures local to collection Reviewed-by: iwalulya, sjohanss ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1CollectedHeap.hpp ! src/hotspot/share/gc/g1/g1ParScanThreadState.cpp ! src/hotspot/share/gc/g1/g1ParScanThreadState.hpp ! src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.cpp ! src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.hpp Changeset: 276b07b3 Author: Lutz Schmidt Date: 2021-08-30 12:31:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/276b07b36af01d339e48baada7a512451fe34afe 8271490: [ppc] [s390]: Crash in JavaThread::pd_get_top_frame_for_profiling Reviewed-by: stuefe, mbaesken ! src/hotspot/cpu/ppc/frame_ppc.cpp ! src/hotspot/cpu/s390/frame_s390.cpp ! src/hotspot/os_cpu/linux_ppc/thread_linux_ppc.cpp ! src/hotspot/os_cpu/linux_s390/thread_linux_s390.cpp Changeset: 5185dbde Author: Andrey Turbanov Committer: Aleksei Efimov Date: 2021-08-30 13:12:42 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5185dbde67f07ff876305a9568bb5cebb7a7b384 8273098: Unnecessary Vector usage in java.naming Reviewed-by: aefimov, dfuchs ! src/java.naming/share/classes/com/sun/jndi/ldap/LdapSchemaParser.java ! src/java.naming/share/classes/com/sun/jndi/ldap/Obj.java ! src/java.naming/share/classes/com/sun/jndi/ldap/sasl/LdapSasl.java Changeset: fbffa54e Author: Magnus Ihse Bursie Date: 2021-08-30 13:41:54 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fbffa54efe447a4c911af2be1d7774a8c60d6ede 8270438: "Cores to use" output in configure is misleading Reviewed-by: erikj ! make/autoconf/help.m4 Changeset: f11e099a Author: Stefan Johansson Date: 2021-08-30 14:37:03 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f11e099a149adfecc474ba37276ec8672067d090 8272651: G1 heap region info print order changed by JDK-8269914 Reviewed-by: tschatzl, iwalulya, ayang ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1FullCollector.hpp ! src/hotspot/share/gc/g1/g1FullGCScope.cpp ! src/hotspot/share/gc/g1/g1FullGCScope.hpp ! test/hotspot/jtreg/gc/g1/TestEagerReclaimHumongousRegionsLog.java Changeset: 98b9d980 Author: Coleen Phillimore Date: 2021-08-30 14:47:24 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/98b9d98032a700490cda72f645dad505164ec699 8272797: Mutex with rank safepoint_check_never imply allow_vm_block Reviewed-by: dholmes, pchilanomate ! src/hotspot/os/aix/osThread_aix.cpp ! src/hotspot/os/bsd/osThread_bsd.cpp ! src/hotspot/os/linux/osThread_linux.cpp ! src/hotspot/share/classfile/classLoaderData.cpp ! src/hotspot/share/compiler/compileTask.hpp ! src/hotspot/share/gc/g1/g1RegionToSpaceMapper.cpp ! src/hotspot/share/gc/g1/g1ServiceThread.cpp ! src/hotspot/share/gc/g1/heapRegion.cpp ! src/hotspot/share/gc/g1/heapRegionRemSet.cpp ! src/hotspot/share/gc/parallel/psCompactionManager.cpp ! src/hotspot/share/gc/shared/gcLogPrecious.cpp ! src/hotspot/share/gc/shared/oopStorage.cpp ! src/hotspot/share/gc/shared/space.cpp ! src/hotspot/share/gc/shared/taskTerminator.cpp ! src/hotspot/share/gc/shared/workgroup.cpp ! src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp ! src/hotspot/share/gc/shenandoah/shenandoahPacer.hpp ! src/hotspot/share/gc/z/zMessagePort.inline.hpp ! src/hotspot/share/gc/z/zMetronome.cpp ! src/hotspot/share/memory/heapInspection.hpp ! src/hotspot/share/memory/metaspace/testHelpers.cpp ! src/hotspot/share/oops/methodData.cpp ! src/hotspot/share/prims/jvmtiTagMap.cpp ! src/hotspot/share/runtime/handshake.cpp ! src/hotspot/share/runtime/mutex.cpp ! src/hotspot/share/runtime/mutex.hpp ! src/hotspot/share/runtime/mutexLocker.cpp ! src/hotspot/share/runtime/stackWatermark.cpp ! src/hotspot/share/runtime/vmOperations.cpp ! src/hotspot/share/runtime/vmThread.cpp ! src/hotspot/share/services/heapDumperCompression.cpp ! src/hotspot/share/services/memoryManager.cpp ! src/hotspot/share/utilities/concurrentHashTable.inline.hpp ! src/hotspot/share/utilities/events.hpp ! test/hotspot/gtest/metaspace/test_is_metaspace_obj.cpp ! test/hotspot/gtest/metaspace/test_metaspacearena.cpp ! test/hotspot/gtest/metaspace/test_metaspacearena_stress.cpp ! test/hotspot/gtest/runtime/test_mutex.cpp ! test/hotspot/gtest/runtime/test_safepoint_locks.cpp ! test/hotspot/gtest/utilities/test_filterQueue.cpp Changeset: 7a01ba65 Author: Thomas Schatzl Date: 2021-08-30 15:54:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7a01ba6528923569c5e8d2e9d138d38e95aa4faf 8272093: Extract evacuation failure injection from G1CollectedHeap Reviewed-by: ayang, 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/g1ParScanThreadState.cpp + src/hotspot/share/gc/g1/g1YoungGCEvacFailureInjector.cpp + src/hotspot/share/gc/g1/g1YoungGCEvacFailureInjector.hpp + src/hotspot/share/gc/g1/g1YoungGCEvacFailureInjector.inline.hpp Changeset: 5aaa20f8 Author: Sandhya Viswanathan Date: 2021-08-30 16:48:28 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5aaa20f898e8679ef1c2c36bd01d48c17be0aacf 8272861: Add a micro benchmark for vector api Reviewed-by: psandoz + test/micro/org/openjdk/bench/jdk/incubator/vector/BlackScholes.java Changeset: f18c0fac Author: Fernando Guallini Committer: Rajan Halade Date: 2021-08-30 17:28:49 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f18c0fac11aac833edfdc484e221518c55daa9a7 8271560: sun/security/ssl/DHKeyExchange/LegacyDHEKeyExchange.java still fails due to "An established connection was aborted by the software in your host machine" Reviewed-by: xuelei, rhalade ! test/jdk/sun/security/ssl/DHKeyExchange/LegacyDHEKeyExchange.java Changeset: fecefb85 Author: Ian Graves Date: 2021-08-30 17:37:29 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fecefb8541d5056b1a8b105126ac9c566875e056 8271302: Regex Test Refresh Reviewed-by: bchristi, smarks ! test/jdk/java/util/regex/GraphemeTest.java ! test/jdk/java/util/regex/NegativeArraySize.java ! test/jdk/java/util/regex/RegExTest.java Changeset: 32048536 Author: Ioi Lam Date: 2021-08-30 21:06:26 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/32048536e9ea9245437eb37308e905435cce6305 8272343: Remove MetaspaceClosure::FLAG_MASK Reviewed-by: ccheung, minqi ! src/hotspot/share/cds/archiveBuilder.cpp ! src/hotspot/share/memory/metaspaceClosure.cpp ! src/hotspot/share/memory/metaspaceClosure.hpp Changeset: 7fc85409 Author: Naoto Sato Date: 2021-08-30 21:13:59 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7fc8540907e8e7483ad5729ea416167810aa8747 8260265: UTF-8 by Default Reviewed-by: alanb, rriggs ! make/data/charsetmapping/charsets ! src/java.base/share/classes/java/io/ByteArrayOutputStream.java ! src/java.base/share/classes/java/io/Console.java ! src/java.base/share/classes/java/io/FileReader.java ! src/java.base/share/classes/java/io/FileWriter.java ! src/java.base/share/classes/java/io/InputStreamReader.java ! src/java.base/share/classes/java/io/OutputStreamWriter.java ! src/java.base/share/classes/java/io/PrintStream.java ! src/java.base/share/classes/java/io/PrintWriter.java ! src/java.base/share/classes/java/lang/System.java ! src/java.base/share/classes/java/net/URLDecoder.java ! src/java.base/share/classes/java/net/URLEncoder.java ! src/java.base/share/classes/java/nio/charset/Charset.java ! src/java.base/share/classes/java/util/Scanner.java ! src/java.base/share/classes/jdk/internal/util/StaticProperty.java ! src/java.base/share/classes/jdk/internal/util/SystemProps.java + test/jdk/java/lang/System/FileEncodingTest.java ! test/jdk/java/lang/System/MacEncoding/MacJNUEncoding.java ! test/jdk/java/lang/System/MacEncoding/TestFileEncoding.java ! test/jdk/java/nio/charset/Charset/RegisteredCharsets.java ! test/jdk/java/nio/charset/RemovingSunIO/SunioAlias.java ! test/jdk/tools/launcher/UnicodeTest.java Changeset: 0609421d Author: Vicente Romero Date: 2021-08-30 21:16:46 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0609421d4b824c5642ca75d525bad3edd72cd23a 8272347: ObjectMethods::bootstrap should specify NPE if any argument except lookup is null Reviewed-by: mchung, chegar ! src/java.base/share/classes/java/lang/runtime/ObjectMethods.java ! test/jdk/java/lang/runtime/ObjectMethodsTest.java Changeset: 9732fbe4 Author: Yumin Qi Date: 2021-08-31 00:24:05 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9732fbe428c3b6a5422cc94e7295ba5482d1a7a9 8273153: Consolidate file_exists into os:file_exists Reviewed-by: iklam, ccheung ! src/hotspot/os/linux/os_linux.cpp ! src/hotspot/share/logging/logFileOutput.cpp ! src/hotspot/share/runtime/os.cpp ! src/hotspot/share/runtime/os.hpp Changeset: 98fa5335 Author: Claes Redestad Date: 2021-08-31 11:32:33 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/98fa53357a66f474090304e53959be5d433d5e5f 8273100: Improve AbstractStringBuilder.append(String) when using CompactStrings Reviewed-by: rriggs, alanb ! src/java.base/share/classes/java/lang/AbstractStringBuilder.java Changeset: 841e3943 Author: Ivan Walulya Date: 2021-08-31 12:30:14 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/841e3943c480c95409446bb35fb9a56d7fc48c8a 8159979: During initial mark, preparing all regions for marking may take a significant amount of time Reviewed-by: tschatzl, ayang ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp ! src/hotspot/share/gc/g1/g1ConcurrentMark.hpp ! src/hotspot/share/gc/g1/g1GCPhaseTimes.cpp ! src/hotspot/share/gc/g1/g1GCPhaseTimes.hpp Changeset: 9bc7cc56 Author: Albert Mingkun Yang Date: 2021-08-31 12:51:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9bc7cc56513adb9d2e39cd286d2a229c9c285e2d 8273033: SerialGC: remove obsolete comments Reviewed-by: sjohanss, tschatzl ! src/hotspot/share/gc/serial/genMarkSweep.cpp Changeset: e6712551 Author: Ivan Walulya Date: 2021-08-31 13:32:31 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e67125512f585c8efad2e7685b9bc409c96563d7 8237567: Refactor G1-specific code in shared VM_CollectForMetadataAllocation Reviewed-by: ayang, tschatzl ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1CollectedHeap.hpp ! src/hotspot/share/gc/shared/gcVMOperations.cpp ! src/hotspot/share/gc/shared/gcVMOperations.hpp Changeset: e5518528 Author: Brian Burkhalter Date: 2021-08-31 14:42:14 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e55185280126e450e31eb65aa8342aebe6f31606 8271225: Add floorDivExact() method to java.lang.[Strict]Math Reviewed-by: darcy ! src/java.base/share/classes/java/lang/Math.java ! src/java.base/share/classes/java/lang/StrictMath.java ! test/jdk/java/lang/Math/ExactArithTests.java Changeset: 75d987a0 Author: Vicente Romero Date: 2021-08-31 15:40:17 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/75d987a0dd6f8cc41808f7ba566e914817e465dc 8262095: NPE in Flow$FlowAnalyzer.visitApply: Cannot invoke getThrownTypes because tree.meth.type is null Co-authored-by: Jan Lahoda Co-authored-by: Vicente Romero Reviewed-by: jlahoda ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java + test/langtools/tools/javac/lambda/8262095/T8262095.java + test/langtools/tools/javac/lambda/8262095/T8262095.out Changeset: ba3587e5 Author: Thomas Schatzl Date: 2021-08-31 15:45:56 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ba3587e524aeec43a0c4174ddd96b8890a34fa36 8273144: Remove unused top level "Sample Collection Set Candidates" logging Reviewed-by: iwalulya, ayang ! src/hotspot/share/gc/g1/g1GCPhaseTimes.cpp ! src/hotspot/share/gc/g1/g1GCPhaseTimes.hpp ! test/hotspot/jtreg/gc/g1/TestGCLogMessages.java Changeset: 1996f649 Author: Ioi Lam Date: 2021-08-31 16:33:02 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1996f649a3a30b7ac4b547a762417f807f5fa414 8273092: Sort classlist in JDK image Reviewed-by: redestad, ihse, dfuchs ! make/GenerateLinkOptData.gmk + make/jdk/src/classes/build/tools/classlist/SortClasslist.java ! make/scripts/compare.sh Changeset: 683e30db Author: bobpengxie Committer: Sergey Bylokhov Date: 2021-08-31 17:31:03 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/683e30db79789ee44b3cc0b44c085de4615bca7b 8273169: java/util/regex/NegativeArraySize.java failed after JDK-8271302 Reviewed-by: jiefu, serb ! test/jdk/java/util/regex/NegativeArraySize.java Changeset: c1e0aac8 Author: Thomas Schatzl Date: 2021-08-31 19:46:55 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c1e0aac846861f9bd8a23818a21670a2f649631b 8273186: Remove leftover comment about sparse remembered set in G1 HeapRegionRemSet Reviewed-by: ayang ! src/hotspot/share/gc/g1/heapRegionRemSet.hpp Changeset: 3d657eb0 Author: Weijun Wang Date: 2021-08-31 20:07:02 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3d657eb0a626e33995af5d5ddf12b26d06317962 8262186: Call X509KeyManager.chooseClientAlias once for all key types Reviewed-by: xuelei ! src/java.base/share/classes/sun/security/ssl/CertificateMessage.java ! src/java.base/share/classes/sun/security/ssl/CertificateRequest.java ! src/java.base/share/classes/sun/security/ssl/X509Authentication.java + test/jdk/sun/security/ssl/SSLContextImpl/MultipleChooseAlias.java Changeset: 9c392d00 Author: Daniel D. Daugherty Date: 2021-08-31 20:12:19 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9c392d008a5a34cdc2ed6339a63f1a0d06efe619 8273197: ProblemList 2 jtools tests due to JDK-8273187 8273198: ProblemList java/lang/instrument/BootClassPath/BootClassPathTest.sh due to JDK-8273188 Reviewed-by: naoto ! test/jdk/ProblemList.txt Changeset: 18a731a3 Author: Alex Menkov Date: 2021-08-31 22:43:12 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/18a731a3e4ec85f0f3e8d6ff619b539c0daaf320 8269770: nsk tests should start IOPipe channel before launch debuggee - Debugee.prepareDebugee Reviewed-by: sspitsyn, kevinw ! test/hotspot/jtreg/vmTestbase/nsk/jdi/Accessible/isPackagePrivate/accipp001.java ! test/hotspot/jtreg/vmTestbase/nsk/share/jpda/DebugeeProcess.java ! test/hotspot/jtreg/vmTestbase/nsk/share/jpda/IOPipe.java Changeset: 2fce7cb4 Author: David Holmes Date: 2021-08-31 23:51:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2fce7cb4d21e4e2c234c22a1a150f7fe113d4d16 8272963: Update the java manpage markdown source Reviewed-by: ysuenaga ! src/java.base/share/man/java.1 Changeset: e600fe1a Author: Jan Lahoda Date: 2021-09-01 06:06:17 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e600fe1a1a57d7e4060b3a1b9a8ecdb65664a506 8272618: Unnecessary Attr.visitIdent.noOuterThisPath Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java Changeset: f1c5e26e Author: Jie Fu Date: 2021-09-01 07:55:20 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f1c5e26e48ca2db0fc2b7ad2cf1bda4853bdeea9 8273206: jdk/jfr/event/gc/collection/TestG1ParallelPhases.java fails after JDK-8159979 Reviewed-by: dholmes, ayang ! test/jdk/jdk/jfr/event/gc/collection/TestG1ParallelPhases.java Changeset: 0e14bf70 Author: Matthias Baesken Date: 2021-09-01 07:59:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0e14bf70cf6e482a2ec7d13ed37df0bee911740d 8273176: handle latest VS2019 in abstract_vm_version Reviewed-by: kevinw, dholmes ! src/hotspot/share/runtime/abstract_vm_version.cpp Changeset: a58cf165 Author: Fairoz Matte Committer: Tobias Hartmann Date: 2021-09-01 10:12:25 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a58cf16509f3120d69fc18bd4c2c49e9ad590f73 8272563: assert(is_double_stack() && !is_virtual()) failed: type check Reviewed-by: thartmann, iveresov ! src/hotspot/share/gc/shared/c1/cardTableBarrierSetC1.cpp Changeset: 02822e13 Author: Yi Yang Date: 2021-09-01 10:41:03 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/02822e1398d6015f0ed26edd440db8e0d50bf152 8272377: assert preconditions that are ensured when created in add_final_edges Reviewed-by: thartmann, kvn ! src/hotspot/share/opto/escape.cpp ! src/hotspot/share/opto/escape.hpp Changeset: dacd1978 Author: Coleen Phillimore Date: 2021-09-01 16:48:06 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/dacd1978972b46510049086c8431bb12e5f3722f 8273217: Make ParHeapInspectTask _safepoint_check_never Reviewed-by: dholmes, pchilanomate ! src/hotspot/share/memory/heapInspection.cpp ! src/hotspot/share/memory/heapInspection.hpp Changeset: 655ea6d4 Author: Ioi Lam Date: 2021-09-01 16:50:11 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/655ea6d42ae94d96a03b1f008aad264a1ee4f173 8270489: Support archived heap objects in EpsilonGC Reviewed-by: shade, ccheung ! src/hotspot/share/cds/archiveBuilder.cpp ! src/hotspot/share/cds/archiveUtils.cpp ! src/hotspot/share/cds/filemap.cpp ! src/hotspot/share/cds/filemap.hpp ! src/hotspot/share/cds/heapShared.cpp ! src/hotspot/share/cds/heapShared.hpp ! src/hotspot/share/cds/heapShared.inline.hpp ! src/hotspot/share/cds/metaspaceShared.cpp ! src/hotspot/share/cds/metaspaceShared.hpp ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/classfile/stringTable.cpp ! src/hotspot/share/classfile/stringTable.hpp ! src/hotspot/share/classfile/systemDictionaryShared.cpp ! src/hotspot/share/classfile/vmClasses.cpp ! src/hotspot/share/gc/epsilon/epsilonHeap.cpp ! src/hotspot/share/gc/epsilon/epsilonHeap.hpp ! src/hotspot/share/gc/shared/collectedHeap.hpp ! src/hotspot/share/memory/universe.cpp ! src/hotspot/share/oops/constantPool.cpp ! src/hotspot/share/oops/klass.cpp ! src/hotspot/share/prims/whitebox.cpp ! test/hotspot/jtreg/TEST.groups ! test/hotspot/jtreg/runtime/cds/appcds/TestCommon.java + test/hotspot/jtreg/runtime/cds/appcds/TestEpsilonGCWithCDS.java ! test/hotspot/jtreg/runtime/cds/appcds/customLoader/HelloCustom.java ! test/hotspot/jtreg/runtime/cds/appcds/customLoader/UnloadUnregisteredLoaderTest.java ! test/hotspot/jtreg/runtime/cds/appcds/javaldr/GCSharedStringsDuringDump.java ! test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/SharedStringsStress.java ! test/jtreg-ext/requires/VMProps.java ! test/lib/jdk/test/lib/cds/CDSOptions.java ! test/lib/jdk/test/lib/cds/CDSTestUtils.java Changeset: 4ee0dace Author: Daniel D. Daugherty Date: 2021-09-01 17:45:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4ee0dacecd5afc5876ea839ffbb5df962ff6cd08 8273248: ProblemList java/lang/instrument/BootClassPath/BootClassPathTest.sh on all configs Reviewed-by: naoto ! test/jdk/ProblemList.txt Changeset: 9689f615 Author: Coleen Phillimore Date: 2021-09-01 18:39:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9689f615206e96f17ffc1fe7a8efeee0a90c904b 8272788: Nonleaf ranked locks should not be safepoint_check_never Reviewed-by: eosterlund, pchilanomate ! src/hotspot/share/prims/jvmtiTagMap.cpp ! src/hotspot/share/runtime/mutex.cpp ! src/hotspot/share/runtime/mutexLocker.cpp ! src/hotspot/share/runtime/mutexLocker.hpp Changeset: 2f01a6f8 Author: Joe Darcy Date: 2021-09-01 20:28:05 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2f01a6f8b6c0bc08c6e3b7ea279d3826f451607f 8273157: Add convenience methods to Messager Reviewed-by: jjg ! src/java.compiler/share/classes/javax/annotation/processing/Messager.java ! test/langtools/tools/javac/7129225/AnnoProcessor.java ! test/langtools/tools/javac/MethodParameters/ClassReaderTest/MethodParameterProcessor.java ! test/langtools/tools/javac/T6406771.java ! test/langtools/tools/javac/T6458823/MyProcessor.java ! test/langtools/tools/javac/T7159016.java ! test/langtools/tools/javac/T8170667/ParameterProcessor.java ! test/langtools/tools/javac/api/T6412669.java ! test/langtools/tools/javac/api/TestClientCodeWrapper.java ! test/langtools/tools/javac/api/TestGetElement.java ! test/langtools/tools/javac/api/TestOperators.java ! test/langtools/tools/javac/api/TestTrees.java ! test/langtools/tools/javac/classreader/T7031108.java ! test/langtools/tools/javac/diags/DocCommentProcessor.java ! test/langtools/tools/javac/diags/examples/ErrProcMessager/processors/AnnoProc.java ! test/langtools/tools/javac/diags/examples/NoteProcMessager/processors/AnnoProc.java ! test/langtools/tools/javac/diags/examples/ProcFileCreateLastRound/processors/AnnoProc.java ! test/langtools/tools/javac/diags/examples/ProcFileReopening/processors/AnnoProc.java ! test/langtools/tools/javac/diags/examples/ProcIllegalFileName/processors/AnnoProc.java ! test/langtools/tools/javac/diags/examples/ProcSuspiciousClassName/processors/AnnoProc.java ! test/langtools/tools/javac/diags/examples/ProcTypeRecreate/processors/AnnoProc.java ! test/langtools/tools/javac/diags/examples/ProcUnclosedTypeFiles/processors/AnnoProc.java ! test/langtools/tools/javac/diags/examples/ProcUseImplicit/processors/AnnoProc.java ! test/langtools/tools/javac/diags/examples/ProcUseProcOrImplicit/processors/AnnoProc.java ! test/langtools/tools/javac/diags/examples/WarnProcMessager/processors/AnnoProc.java ! test/langtools/tools/javac/enum/6424358/T6424358.java ! test/langtools/tools/javac/file/T7018098.java ! test/langtools/tools/javac/file/T7068437.java ! test/langtools/tools/javac/file/T7068451.java ! test/langtools/tools/javac/modules/AnnotationProcessing.java ! test/langtools/tools/javac/patterns/PatternMatchPosTest.java ! test/langtools/tools/javac/processing/6350124/HelloWorldAP.java ! test/langtools/tools/javac/processing/6365040/ProcBar.java ! test/langtools/tools/javac/processing/6365040/ProcFoo.java ! test/langtools/tools/javac/processing/6365040/T6365040.java ! test/langtools/tools/javac/processing/6414633/A.java ! test/langtools/tools/javac/processing/6430209/b6341534.java ! test/langtools/tools/javac/processing/6499119/ClassProcessor.java ! test/langtools/tools/javac/processing/6994946/TestProcessor.java ! test/langtools/tools/javac/processing/GenerateAndError.java ! test/langtools/tools/javac/processing/StopAfterError/StopAfterError.java ! test/langtools/tools/javac/processing/T6439826.java ! test/langtools/tools/javac/processing/T6920317.java ! test/langtools/tools/javac/processing/TestWarnErrorCount.java ! test/langtools/tools/javac/processing/environment/round/TestContext.java ! test/langtools/tools/javac/processing/errors/TestErrorCount.java ! test/langtools/tools/javac/processing/errors/TestReturnCode.java ! test/langtools/tools/javac/processing/errors/TestSuppression.java ! test/langtools/tools/javac/processing/filer/TestGetResource2.java ! test/langtools/tools/javac/processing/filer/TestInvalidRelativeNames.java ! test/langtools/tools/javac/processing/filer/TestValidRelativeNames.java ! test/langtools/tools/javac/processing/loader/testClose/TestClose2.java ! test/langtools/tools/javac/processing/messager/MessagerDiags.java ! test/langtools/tools/javac/processing/model/6341534/T6341534.java ! test/langtools/tools/javac/processing/model/element/CheckingAccessorsOnLoadedRecordClasses.java ! test/langtools/tools/javac/processing/model/element/CheckingTypeAnnotationsOnRecords.java ! test/langtools/tools/javac/processing/model/element/JavaxLangModelForRecords.java ! test/langtools/tools/javac/processing/model/element/TestAnonSourceNames.java ! test/langtools/tools/javac/processing/model/element/TestExecutableElement.java ! test/langtools/tools/javac/processing/model/element/TestExecutableReceiverType.java ! test/langtools/tools/javac/processing/model/element/TestMissingElement/TestMissingElement.java ! test/langtools/tools/javac/processing/model/element/TestMissingElement2/Generator.java ! test/langtools/tools/javac/processing/model/element/TestSealed.java ! test/langtools/tools/javac/processing/model/element/TestTypeElement.java ! test/langtools/tools/javac/processing/model/element/TestTypeParameter.java ! test/langtools/tools/javac/processing/model/element/TestTypeParameterAnnotations.java ! test/langtools/tools/javac/processing/model/util/deprecation/TestDeprecation.java ! test/langtools/tools/javac/processing/model/util/elements/TestIsFunctionalInterface.java ! test/langtools/tools/javac/processing/model/util/elements/doccomments/TestDocComments.java ! test/langtools/tools/javac/processing/model/util/elements/doccomments/TestPackageInfoComments.java ! test/langtools/tools/javac/processing/options/testCommandLineClasses/Test.java ! test/langtools/tools/javac/processing/options/testPrintProcessorInfo/Test.java ! test/langtools/tools/javac/processing/rounds/BaseClassesNotReRead.java ! test/langtools/tools/javac/processing/rounds/ClassDependingOnGenerated.java ! test/langtools/tools/javac/processing/rounds/ErrClassSymbolTypeFixed.java ! test/langtools/tools/javac/processing/rounds/GenerateAnonymousClass.java ! test/langtools/tools/javac/processing/rounds/OverwriteBetweenCompilations.java ! test/langtools/tools/javac/processing/warnings/TestSourceVersionWarnings.java ! test/langtools/tools/javac/processing/warnings/UseImplicit/TestProcUseImplicitWarning.java ! test/langtools/tools/javac/processing/werror/WError1.java ! test/langtools/tools/javac/processing/werror/WErrorLast.java ! test/langtools/tools/javac/tree/ArrayTypeToString.java ! test/langtools/tools/javac/tree/NoPrivateTypesExported.java ! test/langtools/tools/javac/tree/TreePosRoundsTest.java ! test/langtools/tools/javac/treeannotests/TestProcessor.java ! test/langtools/tools/javac/util/NewlineOnlyDiagnostic.java ! test/langtools/tools/javac/util/T6597678.java Changeset: 1a5a2b6b Author: Valerie Peng Date: 2021-09-01 22:17:49 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1a5a2b6b15e22b21343244e3a2b649d00eef5ffa 8271745: Correct block size for KW,KWP mode and use fixed IV for KWP mode for SunJCE Reviewed-by: xuelei, mullan ! 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: a9a83b24 Author: Jie Fu Date: 2021-09-02 04:10:46 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a9a83b248e4a575e3d22541c122b27246a52dc7b 8273256: runtime/cds/appcds/TestEpsilonGCWithCDS.java fails due to Unrecognized VM option 'ObjectAlignmentInBytes=64' on x86_32 Reviewed-by: dholmes, iklam ! test/hotspot/jtreg/runtime/cds/appcds/TestEpsilonGCWithCDS.java Changeset: 6cfe3142 Author: Aleksey Shipilev Date: 2021-09-02 07:56:56 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6cfe314262dacd6ca1a74c000d045b1cabd374db 8272970: Parallelize runtime/InvocationTests/ Reviewed-by: dholmes, iignatyev ! test/hotspot/jtreg/ProblemList.txt ! test/hotspot/jtreg/runtime/InvocationTests/invocationC1Tests.java ! test/hotspot/jtreg/runtime/InvocationTests/invocationOldCHATests.java ! test/hotspot/jtreg/runtime/InvocationTests/invokeinterfaceTests.java ! test/hotspot/jtreg/runtime/InvocationTests/invokespecialTests.java ! test/hotspot/jtreg/runtime/InvocationTests/invokevirtualTests.java Changeset: 857a930b Author: Aleksey Shipilev Date: 2021-09-02 08:00:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/857a930bde8b53f77a23737f4ca6ff8f3da2af66 8263375: Support stack watermarks in Zero VM Reviewed-by: eosterlund ! src/hotspot/cpu/zero/frame_zero.cpp ! src/hotspot/cpu/zero/vm_version_zero.hpp ! src/hotspot/cpu/zero/zeroInterpreter_zero.cpp ! src/hotspot/cpu/zero/zeroInterpreter_zero.hpp ! src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp Changeset: 152e6692 Author: Sergey Tsypanov Committer: Thomas Schatzl Date: 2021-09-02 08:10:40 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/152e66923dc36cfd83cdfe18e96631abc06b9199 8273140: Replace usages of Enum.class.getEnumConstants() with Enum.values() where possible Reviewed-by: tschatzl ! src/java.desktop/share/classes/sun/font/AttributeValues.java ! src/java.desktop/share/classes/sun/font/EAttribute.java ! src/java.sql/share/classes/java/sql/JDBCType.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/bytecode/SourceGenerator.java Changeset: 0c1b16b7 Author: Aleksei Efimov Date: 2021-09-02 10:36:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0c1b16b75a2361431cbf9f4112dcd6049e981a78 8273243: Fix indentations in java.net.InetAddress methods Reviewed-by: dfuchs, bpb ! src/java.base/share/classes/java/net/InetAddress.java Changeset: c2e015c3 Author: Matthias Baesken Date: 2021-09-02 11:22:49 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c2e015c3c1a2274112bb8e6671a85bc7fb624fde 8273229: Update OS detection code to recognize Windows Server 2022 Reviewed-by: alanb, dholmes ! src/hotspot/os/windows/os_windows.cpp ! src/java.base/windows/native/libjava/java_props_md.c Changeset: 632a7e08 Author: Vladimir Ivanov Date: 2021-09-02 11:46:19 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/632a7e0885596b70d34be319bd09d4df8e151d12 8273165: GraphKit::combine_exception_states fails with "matching stack sizes" assert Reviewed-by: thartmann, kvn ! src/hotspot/share/opto/callGenerator.cpp Changeset: 5245c1cf Author: Thomas Schatzl Date: 2021-09-02 11:57:55 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5245c1cf0260a78ca5f8ab4e7d13107f21faf071 8273147: Update and restructure TestGCLogMessages log message list Reviewed-by: iwalulya, ayang ! test/hotspot/jtreg/gc/g1/TestGCLogMessages.java Changeset: 5ee5dd9b Author: Aleksey Shipilev Date: 2021-09-02 15:43:21 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5ee5dd9b18fb5adc563a65bd1a29779eda675d61 8272914: Create hotspot:tier2 and hotspot:tier3 test groups Reviewed-by: dholmes, coleenp, iignatyev ! test/hotspot/jtreg/TEST.groups Changeset: aaa6f696 Author: Lance Andersen Date: 2021-09-02 16:06:55 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/aaa6f696b06b335f81efccf0966612b086dd2e73 8273250: Address javadoc issues in Deflater::setDictionationary Reviewed-by: rriggs, naoto, iris, bpb ! src/java.base/share/classes/java/util/zip/Deflater.java Changeset: 29e0f138 Author: Jamil Nimeh Date: 2021-09-02 17:54:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/29e0f1386d247731e8733f6fdd1307642b2b9f96 8272385: Enforce ECPrivateKey d value to be in the range [1, n-1] for SunEC provider Reviewed-by: ascarpino, weijun ! src/java.base/share/classes/sun/security/util/ECUtil.java ! src/jdk.crypto.ec/share/classes/sun/security/ec/ECDHKeyAgreement.java ! src/jdk.crypto.ec/share/classes/sun/security/ec/ECDSASignature.java + test/jdk/sun/security/ec/ECDSAPrvGreaterThanOrder.java Changeset: 92b05fe0 Author: Patricio Chilano Mateo Date: 2021-09-02 21:22:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/92b05fe0f41b91aa88e77473725ae92ee13b052f 8273251: Call check_possible_safepoint() from SafepointMechanism::process_if_requested() Reviewed-by: coleenp, dholmes ! src/hotspot/share/runtime/interfaceSupport.inline.hpp ! src/hotspot/share/runtime/safepointMechanism.inline.hpp ! src/hotspot/share/runtime/thread.cpp Changeset: 7fff22af Author: Sergey Bylokhov Date: 2021-09-02 22:56:20 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7fff22afe711c8c04dbf4cf5b4938d40632e4987 8272805: Avoid looking up standard charsets Reviewed-by: weijun, naoto, dfuchs, azvegint, erikj ! make/jdk/src/classes/build/tools/generatelsrequivmaps/EquivMapsGenerator.java ! src/demo/share/jfc/Font2DTest/Font2DTest.java ! src/demo/share/jfc/Font2DTest/FontPanel.java ! src/demo/share/jfc/SwingSet2/DemoModule.java ! src/demo/share/jfc/SwingSet2/TreeDemo.java ! src/java.base/share/classes/sun/security/util/DerOutputStream.java ! src/java.base/share/classes/sun/security/util/DerValue.java ! src/java.datatransfer/share/classes/sun/datatransfer/DataFlavorUtil.java ! src/java.desktop/macosx/classes/sun/font/CFontConfiguration.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/png/PNGImageReader.java ! src/java.desktop/unix/classes/sun/font/FcFontConfiguration.java ! src/java.desktop/unix/classes/sun/font/MFontConfiguration.java ! src/java.security.jgss/share/classes/sun/security/krb5/internal/PAData.java ! src/java.security.jgss/share/classes/sun/security/krb5/internal/crypto/dk/DkCrypto.java ! src/java.security.jgss/share/classes/sun/security/krb5/internal/util/KerberosString.java ! src/java.security.sasl/share/classes/com/sun/security/sasl/digest/DigestMD5Base.java ! src/java.security.sasl/share/classes/com/sun/security/sasl/digest/DigestMD5Server.java ! src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java ! src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java ! src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/platform/JDKPlatformProvider.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/processing/ServiceProxy.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/client/SjavacClient.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/InputLexer.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/posix/elf/ELFFileParser.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/win32/coff/COFFFileParser.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/HeapHprofBinWriter.java ! src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java ! src/jdk.internal.ed/share/classes/jdk/internal/editor/external/ExternalEditor.java ! src/jdk.internal.jvmstat/linux/classes/sun/jvmstat/PlatformSupportImpl.java ! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.services/src/jdk/vm/ci/services/Services.java ! src/jdk.jcmd/share/classes/sun/tools/common/PrintStreamPrinter.java ! src/jdk.jcmd/share/classes/sun/tools/jmap/JMap.java ! src/jdk.jdeps/share/classes/com/sun/tools/classfile/SourceDebugExtension_attribute.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/PacketStream.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/SocketTransportService.java ! src/jdk.jdi/windows/classes/com/sun/tools/jdi/SharedMemoryConnection.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/StringParser.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/jfc/model/JFCModel.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/jfc/model/Parser.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/tool/Metadata.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/tool/Print.java ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/ConsoleIOContext.java ! src/jdk.jshell/share/classes/jdk/jshell/execution/DemultiplexInput.java ! src/jdk.jshell/share/classes/jdk/jshell/execution/MultiplexingOutputStream.java ! src/jdk.jshell/share/classes/jdk/jshell/execution/Util.java ! src/jdk.management.agent/share/classes/sun/management/jdp/JdpPacketReader.java ! src/jdk.security.auth/share/classes/com/sun/security/auth/module/Crypt.java ! src/jdk.security.auth/share/classes/com/sun/security/auth/module/JndiLoginModule.java ! src/utils/IdealGraphVisualizer/Data/src/main/java/com/sun/hotspot/igv/data/serialization/BinaryParser.java ! src/utils/IdealGraphVisualizer/Data/src/test/java/com/sun/hotspot/igv/data/serialization/ParserTest.java ! src/utils/IdealGraphVisualizer/View/src/main/java/com/sun/hotspot/igv/view/EditorTopComponent.java Changeset: dd871819 Author: Ian Graves Date: 2021-09-03 00:50:11 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/dd871819a05886ee09fc00c7c778268440ebedb7 8214761: Bug in parallel Kahan summation implementation Reviewed-by: darcy ! src/java.base/share/classes/java/util/DoubleSummaryStatistics.java ! src/java.base/share/classes/java/util/stream/Collectors.java ! src/java.base/share/classes/java/util/stream/DoublePipeline.java + test/jdk/java/util/DoubleStreamSums/CompensatedSums.java + test/jdk/java/util/DoubleSummaryStatistics/NegativeCompensation.java Changeset: fa9c8657 Author: Xiaowei Lu Committer: David Holmes Date: 2021-09-03 05:29:02 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fa9c8657dfaa2018f501de1a8aa62f004342c245 8273112: -Xloggc: should override -verbose:gc Reviewed-by: iklam, dholmes ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/arguments.hpp Changeset: f17ee0c5 Author: Jan Lahoda Date: 2021-09-03 09:29:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f17ee0c5c796951801c2026a2acac895a5c0af73 8273263: Incorrect recovery attribution of record component type when j.l.Record is unavailable Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java ! test/langtools/tools/javac/api/TestGetElementReference.java + test/langtools/tools/javac/api/TestGetElementReferenceDataWithRecord.java Changeset: 7b023a3f Author: Jan Lahoda Date: 2021-09-03 09:30:56 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7b023a3f607f44da1b13bc9d2884a5f13723d524 8273257: jshell doesn't compile a sealed hierarchy with a sealed interface and a non-sealed leaf Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! test/langtools/jdk/jshell/SealedClassesTest.java ! test/langtools/tools/javac/sealed/SealedCompilationTests.java Changeset: 93eec9a1 Author: Jan Lahoda Date: 2021-09-03 09:31:54 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/93eec9a103de7f4d9a87eac5b295c9a50702ee94 8272776: NullPointerException not reported Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java ! test/langtools/tools/javac/patterns/NullSwitch.java Changeset: d05494f9 Author: Guoxiong Li Date: 2021-09-03 09:33:17 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d05494f98bad351532cdb769c9da6b6e2359b16e 8266239: Some duplicated javac command-line options have repeated effect Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.java ! test/langtools/tools/javac/options/modes/InfoOptsTest.java ! test/langtools/tools/javac/options/modes/OptionModesTester.java Changeset: 0ed9424c Author: duke Date: 2021-09-03 11:00:29 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0ed9424c7ee505c6e11ec680383aa8aae7b2d2d6 Automatic merge of jdk:master into master From jiefu at openjdk.java.net Fri Sep 3 14:08:08 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Fri, 3 Sep 2021 14:08:08 GMT Subject: [vectorIntrinsics+mask] RFR: 8273205: [vector] Crash in C2_MacroAssembler::vprotate_var after JDK-8271366 Message-ID: <2PM0lqpC20oqtHrIow2TDNb2zcauuGTRrlMtfoQF_h4=.001b5773-0928-403e-9e96-d995a2fa90b8@github.com> Hi all, After JDK-8271366, `arch_supports_vector()` fails to check whether the rotate operation is directly supported by the target ISA. So `Matcher::match_rule_supported_vector` should be added in `inline_vector_broadcast_int()` and `inline_vector_nary_operation()` to prevent generation of unsupported rotate operation IR patterns. Thanks. Best regards, Jie ------------- Commit messages: - 8273205: [vector] Crash in C2_MacroAssembler::vprotate_var after JDK-8271366 Changes: https://git.openjdk.java.net/panama-vector/pull/119/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=119&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273205 Stats: 9 lines in 1 file changed: 9 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/panama-vector/pull/119.diff Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/119/head:pull/119 PR: https://git.openjdk.java.net/panama-vector/pull/119 From psandoz at openjdk.java.net Fri Sep 3 14:40:48 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Fri, 3 Sep 2021 14:40:48 GMT Subject: [vectorIntrinsics+mask] RFR: 8273205: [vector] Crash in C2_MacroAssembler::vprotate_var after JDK-8271366 In-Reply-To: <2PM0lqpC20oqtHrIow2TDNb2zcauuGTRrlMtfoQF_h4=.001b5773-0928-403e-9e96-d995a2fa90b8@github.com> References: <2PM0lqpC20oqtHrIow2TDNb2zcauuGTRrlMtfoQF_h4=.001b5773-0928-403e-9e96-d995a2fa90b8@github.com> Message-ID: On Fri, 3 Sep 2021 14:01:25 GMT, Jie Fu wrote: > Hi all, > > After JDK-8271366, `arch_supports_vector()` fails to check whether the rotate operation is directly supported by the target ISA. > > So `Matcher::match_rule_supported_vector` should be added in `inline_vector_broadcast_int()` and `inline_vector_nary_operation()` to prevent generation of unsupported rotate operation IR patterns. > > Thanks. > Best regards, > Jie Should this be first fixed in https://github.com/openjdk/jdk/ ? ------------- PR: https://git.openjdk.java.net/panama-vector/pull/119 From jiefu at openjdk.java.net Fri Sep 3 14:55:51 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Fri, 3 Sep 2021 14:55:51 GMT Subject: [vectorIntrinsics+mask] RFR: 8273205: [vector] Crash in C2_MacroAssembler::vprotate_var after JDK-8271366 In-Reply-To: References: <2PM0lqpC20oqtHrIow2TDNb2zcauuGTRrlMtfoQF_h4=.001b5773-0928-403e-9e96-d995a2fa90b8@github.com> Message-ID: On Fri, 3 Sep 2021 14:37:13 GMT, Paul Sandoz wrote: > Should this be first fixed in https://github.com/openjdk/jdk/ ? Ah, yes. Although it doesn't reproduce in the jdk repo, the bug still be there in theory. Will do it soon. Thanks. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/119 From jiefu at openjdk.java.net Fri Sep 3 15:44:48 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Fri, 3 Sep 2021 15:44:48 GMT Subject: [vectorIntrinsics+mask] RFR: 8273205: [vector] Crash in C2_MacroAssembler::vprotate_var after JDK-8271366 In-Reply-To: References: <2PM0lqpC20oqtHrIow2TDNb2zcauuGTRrlMtfoQF_h4=.001b5773-0928-403e-9e96-d995a2fa90b8@github.com> Message-ID: On Fri, 3 Sep 2021 14:52:58 GMT, Jie Fu wrote: > Should this be first fixed in https://github.com/openjdk/jdk/ ? Let's fix it in https://github.com/openjdk/jdk/pull/5364 . So just close this one. Thanks. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/119 From jiefu at openjdk.java.net Fri Sep 3 15:44:49 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Fri, 3 Sep 2021 15:44:49 GMT Subject: [vectorIntrinsics+mask] Withdrawn: 8273205: [vector] Crash in C2_MacroAssembler::vprotate_var after JDK-8271366 In-Reply-To: <2PM0lqpC20oqtHrIow2TDNb2zcauuGTRrlMtfoQF_h4=.001b5773-0928-403e-9e96-d995a2fa90b8@github.com> References: <2PM0lqpC20oqtHrIow2TDNb2zcauuGTRrlMtfoQF_h4=.001b5773-0928-403e-9e96-d995a2fa90b8@github.com> Message-ID: On Fri, 3 Sep 2021 14:01:25 GMT, Jie Fu wrote: > Hi all, > > After JDK-8271366, `arch_supports_vector()` fails to check whether the rotate operation is directly supported by the target ISA. > > So `Matcher::match_rule_supported_vector` should be added in `inline_vector_broadcast_int()` and `inline_vector_nary_operation()` to prevent generation of unsupported rotate operation IR patterns. > > Thanks. > Best regards, > Jie This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/119 From paul.sandoz at oracle.com Fri Sep 3 20:11:37 2021 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 3 Sep 2021 20:11:37 +0000 Subject: [vectorIntrinsics+mask] RFR: 8273057: [vector] New VectorAPI "SelectiveStore" In-Reply-To: References: <4556C43C-6DB8-4DFE-BA9F-0725D7939189@oracle.com> Message-ID: <61F91394-25CE-4D37-AB02-3B2093C1629D@oracle.com> Thanks John, and Sandhya for also commenting. You both rightly pointed out the weakness using operators and rearrange :-) it does fit right. John, your observation on order really stood out to me. I can see how a prefix-sum might behave with a mask describing the selection of lanes *and* compression of the result (no intermediate values, either from the input or zero). In summary, from the discussion, compress/expand are: - important conceptually, even if the same functionality could be composed from shuffles (such as used by an implementation); and - at the right level to reliably optimize on supporting hardware. So specification-wise we introduce expanding/compressing cross-lane operations. API-wise I prefer two distinct methods rather that one that accepts boolean indicating expansion or compression. We can declare one intrinsic method in VectorSupport. Paul. > On Sep 2, 2021, at 11:33 AM, John Rose wrote: > > On Sep 2, 2021, at 9:50 AM, Paul Sandoz wrote: >> >> Hi Joshua, >> >> I think we still have some exploring to do on the design, and for others to comment esp. with regards to C2 capabilities. >> >> >> Here is another design alternative between the spectrum of a partitioning/compressing a shuffle from mask [*] and a compress method: >> >> VectorMask mask = ...; >> IntVector bv = av.rearrange(VectorOperator.COMPRESS, mask); >> VectorMask prefixMask = prefix(mask.trueCount()); >> bv.intoArray(array, offset, prefixMask); >> offset += mask.trueCount(); >> >> We introduce a new kind of operator, Rearrange, and constants, such as VectorOperator.COMPRESS that specifies behavior of the non-mask and mask accepting rearrange methods. COMPRESS specifies that: >> >> 1) the non-mask rearrange is an identity operation; and >> 2) the mask accepting rearrange describes mask-based cross-lane movement: > > Be careful with adding bulk operations to VectorOperations. > Those are supposed to be only lanewise (scalar). It?s not > clear to me what COMPRESS could mean, as a lanewise > operation. > > One very interesting potential interaction between lanewise > ops and masked operations is reduction of a subset of lanes. > This feels a little like compress, although the lateral data > motion is absent. I?m thinking that generalized shuffle, > lateral compression/expansion, and segmented scan/reduce > may be the interesting primitives here. > > The FIRST_NONZERO operation is the closest thing we have > to lateral motion today: The idea is that non-zero lane values > propagate from higher to lower positions, skipping over zero > lane values. We might try to get from FIRST_NONZERO to > compress by defining an enhanced segmented reduction > operation which takes into a account masking (to define > segments that are to be individually reduced), and then > take additional wins from using other VOs such as MAX, > ADD, etc. I?m throwing this out as brainstorming; what > I get from this line of thought is that segmented scans > naturally deliver results in expanded form, while > segmented reductions have two natural forms of > output, expanded and compressed. So we need a > compress primitive, and/or an expand/compress > mode bit for segmented reduction. > > (Matters of terminology: scan(op) produces the > vector of partial results that would be obtained > if a reduction(op) operation proceeded linearly > from lane 0 to lane VLENGTH-1, recording > an intermediate result in each lane, often > before lane value is accumulated. The scan > can take a carry-in and carry-out lane value > to allow multiple vectors to compose. > Both reductions and scans can be usefully > be segmented, again with carry-in and carry-out. > Segmented operations are useful for fast > group-by modes of operation, and also for > vectorized parsing, such as var-ints or > even text. Compress and expand are independent > primitives, both driven by masks; such masks > can as noted above be related to segmentation > masks.) > >> >> It should be possible to create a shuffle from a Rearrange operator, with and without a mask so the equivalent functionality can be applied to a shuffle accepting rearrange e.g, for COMPRESS: >> >> rearrange(Shuffle.fromRearrangeOp(COMPRESS, mask), mask.prefix()) >> Or >> rearrange(Shuffle.fromRearrangeOp(COMPRESS, mask), zero()) >> // Postfix of exceptional lanes in the shuffle, representing unset lanes > > I?m not following this, because I?m having trouble imagining > ops like ADD and MAX here, as well as imagining COMPRESS > as a VO. (I must be missing something crucial here.) > >> >> For this to be of benefit we would need to come up with other realistic Rearrange operators, even if we do not add them right now e.g. IOTA, REVERSE, PARTITION_TRUE, PARTITION_FALSE, INTERLEAVE. > > I guess what I?m missing is this is a whole new kind of OP, > not a lanewise one. Probably should live on Shuffle, since > VOs is documented to be about lanewise ops only. > >> However, the design is a little awkward since the mask may or may not contribute to cross-lane movement, and so the operator needs to state the equivalence. >> >> In effect the Rearrange operator is a mechanism to refer to certain kinds of shuffle as a constant. > > Yes, and you are exploring the space of plausible constants. > I think they (or at least some of them) could also factorized > as *families* of constants, indexed by masks. > >> Ideally I would still prefer if we could implicitly identify what would otherwise be rearrange operators based on the creation of shuffles with known content e.g. can C2 somehow tag a shuffle instance with an ID of COMPRESS with a dependency on the mask used for its creation? > > Siting the compress (and expand!) functionality on shuffle instead > of vector is a nice story, but I think it?s better to site it on general > vectors, as distinct from shuffling, because of its relation to > segmented data-parallel operations (which are distinct from > permutations, since they never swap the order of selected > lanes). > > So, I see three primitive notions: Segmentation, compress/expand, > and permutation. You can bridge to and from permutation simply > by working with index vectors like iota, and perhaps (as sugar) lifting > selected vector operations to shuffles. > >> >> ? >> >> FWIW another way to think about a partitioning/compression shuffle: >> >> SPECIES.iota().compress(m); > > Yes, that?s the bridging I just mentioned. Some applications > would expand as well as compress. (I know it?s a one-way > street for SVE and maybe others but fear not; expand is > easier to implement than compress, using a plain > permutation.) > > For example, if parsing a file of var-ints does > segmentation (based on (lane&0x80)=0x80 masking) > and subsequent compression to 32-bit integer lanes, the > reverse operation of un-parsing would use an expansion > of 32-bit integer lanes, to be reduced to bytes and stored > to the var-int file. > >> >> Which is just specific way of shuffling a shuffle. We could actually track the kinds of shuffle as final fields of the VectorShuffle implementation. > > Yes. > > If a machine lacks a compress and/or expand operation, > we?d want Java paths that would compute appropriate > shuffles and then apply them, with constant folding > when appropriate. (Although masks are usually not > constant.) > > Sketch of algorithm to derive a compression shuffle > from a mask: > > Take VLENGTH=5 just for example and suppose we > want to compress <4:v, 3:w, 2:x, 1:y, 0:z> with mask > 0b01001. The desired output is then <0,0,0,w,z>. > > 1. For each masked lane (in a fresh index vector) > compute the number of masked lanes at lower > indexes. For example, <2, 1, 1, 1, 0> from 0b01001. > This can be done in log time, and hardware can > sometimes help. The operation naturally yields > popcnt(m) (2 in the example) as a carry-out from > a log-scan. Note that the lowest lane always gets > zero. Variants of this algorithm might use a carry-in > to put something other than zero there. Note also > that the resulting index vector, used to shuffle > the input vector, performs an *expand* which is > the inverse of the compress we are seeking. > > 2. (Optional but useful.) Compute a complementary > second fresh index vector from the inverted mask, > added to the bit-count of the first mask. For example, > <2, 2, 1, 0, 0> from 0x10110 (~0b01001), and then > (adding the bitcount 2) <4, 4, 3, 2, 2>. Note that > this index vector would perform an expand, to > the left-hand (high) side of the vector, of the vector > we are trying to compress. > > 3. Under the mask, blend the index vector from step 1 > with that of step 2, or with a constant vector of value > VLENGTH-1. For example, blending from 0b01001, > either <4, 1, 3, 2, 0> or (lacking step 2) <4, 1, 4, 4, 0>. > > 4. Create an in-memory buffer of the same size and > shape as the vector to be reduced. Use the blended > index to perform an indexed store from the input > vector to the memory buffer. This uses the hardware > memory store operation, on a temp buffer, to create > the desired compress. (It should be done in the VPU > not in the MU, of course, but sometimes this might > be the best way.) > > 5. Load the buffer back into a vector register, and > set the unselected lanes to whatever value is desired, > either zero, or (perhaps) a left-packed set of the > non-compressed values. (This is called the SAG > or ?sheep and goats? operation, when applied to > a bit-vector, and it is very useful for other vectors > as well.) > > Step 2 may be desirable even if you are not doing a SAG, > if the indexed store hardware will go slower due > to collisions on the last lane (index 4 in the example; > note that only that index gets repeated). > > Note that steps 1 and 2 can be done in superscalar parallel. > If step 2 is done with a from-left scan, there is no need to > add in the correction value, of popcnt(m). > > I don?t know a great way to avoid a trip to a memory > buffer, if the hardware does not supply a compress > operation in the VPU. But here?s an almost-great > way: > > 4b. Having computed the non-colliding permutation > vector E (in steps 2 and 3, as if for SAG), use math to > compute the inverse permutation vector C. E is an > expansion as noted above while its inverse C is the > corresponding compression. In the running example, > E is <4, 1, 3, 2, 0> and its inverse C will be <4, 2, 1, 3, 0>. > > 5b. Use the standard shuffle (permutation) operation > to reorder the input vector. Adjust uncompressed > fields appropriately if SAG is not desired (zero them > using the mask or whatever). > > 4b. Math details: Sort the merged E so as to transform > it into the iota vector, while performing *exactly the > same* swaps and reorderings on an iota vector. As > E sorts to iota, the other copy of iota reorders to C. > Perhaps the easiest way to do this is to create an index > vector A with double-width lanes, and pack each lane > A[i] with (E[i] * VLENGTH + i). (The ?+i? is ?+iota[i]?.) > The double-width lanes of A are ?packets? to be ?routed? > to the ?addresses? in the high half of the lane, and the > ?payload? of each packet is the eventual index in C. > Butterfly network, aka binary radix sort, will do the job > in log time. > > (Hey hardware vendors, wouldn?t it be nice to supply > us users with a keyed sort operation, which takes a > vector of ?addresses? and a different vector of ?values? > and reorders the ?values? according to the sorted > order of the ?addresses?? That is the proper inverse > to shuffle/permute primitives. You?d build a keyed > routing network in silicon much like the ones that > implement shuffle/permute.) > > 5c. The step 5a can be merged into 4b in some cases, > if the original input vector lanes are small enough to > fit into the ?packets? in the A vector being sorted in > 4b. In that case, there?s no need to finish with a > shuffle/permutation, since the actual data has already > been moved where it belongs. All you need to do > is strip off the ?address headers? of the ?packets?, > by means of a reshaping truncation. > > This shows that a possible primitive is the anti-shuffle. > (Anti-permutation.) Anti-shuffle is to shuffle as > store is to load. Store is harder than load because > where load has duplications store has collisions. > Collisions probably want to be handled with > reduction operations. (This takes me back to > my Connection Machine and C* days? The > C* operation p->n += x causes each processor?s > x value to be applied as an increment to the n > value on each friend processor p, where p is > basically a pointer as in C. The operations > take place in an indeterminate order but > all x values are summed into each distinct n > variable. Also, ?int y = p->n += x? captures > partial sums, so it?s a scan. It?s all ?as if? > executed sequentially, but in fact executes > in log time, like vector reductions and > permutations.) An anti-shuffle is really > a 1-1 permutation (to the expanded ?collision > buckets? in order), followed by a segmented > reduction, followed by a compress. So > (this is brainstorming!) the anti-shuffle > is really another way to dress up the other > primitives I?m discussing. > > Ideas of the morning; HTH? :-) From paul.sandoz at oracle.com Fri Sep 3 20:16:16 2021 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 3 Sep 2021 20:16:16 +0000 Subject: [vectorIntrinsics+mask] RFR: 8273057: [vector] New VectorAPI "SelectiveStore" In-Reply-To: <61F91394-25CE-4D37-AB02-3B2093C1629D@oracle.com> References: <4556C43C-6DB8-4DFE-BA9F-0725D7939189@oracle.com> <61F91394-25CE-4D37-AB02-3B2093C1629D@oracle.com> Message-ID: > On Sep 3, 2021, at 1:11 PM, Paul Sandoz wrote: > > Thanks John, and Sandhya for also commenting. > > You both rightly pointed out the weakness using operators and rearrange :-) it does fit right. > ^ ? It does *not* fit right. From mike.ennen at gmail.com Fri Sep 3 21:50:08 2021 From: mike.ennen at gmail.com (Michael Ennen) Date: Fri, 3 Sep 2021 14:50:08 -0700 Subject: How To Create Array of Structs? In-Reply-To: References: <0c6361f3-2879-02dd-0b26-e26a5b268602@oracle.com> <4bb60084-2958-45f9-511d-638b85770040@oracle.com> Message-ID: Let me try and expand upon what I was attempting to communicate yesterday: I know that jextract does not currently support function-like macros so the handles like VkSemaphore are not exposed. That's why I tried to first declare it (the array of VkSemaphores) as a pointer to a pointer. But then I cannot get the size of VkSemaphore (really VkSemaphore_T) so I am unsure how to use the technique you described which does work in the case of the VkPipelineShaderStageCreateInfo struct - because it is not an "opaque" handle. Vulkan uses these a lot, things like VkInstance, VkDevice, etc. Specifically: VkSemaphore is defined by this macro: VK_DEFINE_NON_DISPATCHABLE_HANDLE(VkSemaphore) Which is how Vulkan does opaque handles (so one cannot inspect the contents of the VkSemaphore struct and/or rely on it). If jextract did support function-like macros then it would expand to the typedef: typedef struct VkSemaphore_T *VkSemaphore; and then one could possibly just do VkSemaphore.$LAYOUT() ? Or even still that may not work because of the "opaque"ness. Thanks for any assistance. On Thu, Sep 2, 2021 at 11:16 AM Michael Ennen wrote: > Quick question that is now happening while trying to replicate the fix > when I don't have an explicit struct handle like in the case of VkSemaphore: > > > https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VkSemaphore.html > > For those types I don't have a struct layout to work with so I have been > just declaring a double pointer: > > var pVkPipeline = > SegmentAllocator.ofScope(scope).allocate(C_POINTER.byteSize()); > > and then using MemoryAccess.getAddress(pVkPipeline). > > So in this case how can I create an array of VkSemaphore structs without > knowing anything about the struct (it is an opaque handle?). > > Hope that makes sense. > > On Thu, Sep 2, 2021 at 11:06 AM Michael Ennen > wrote: > >> Jorn, >> >> Thank you so much - that was exactly what I was looking for. I don't know >> why I had such trouble trying to create an array of structs rather than an >> array of points to structs. >> >> Thank you both. >> >> On Thu, Sep 2, 2021 at 4:54 AM Jorn Vernee >> wrote: >> >>> Additionally, it looks like you're allocating an array of pointers for >>> pStages, and it looks like the API expects an array of structs. >>> >>> Instead of allocating the different VkPipelineShaderStageCreateInfo >>> individually, you should allocate the array of struct upfront, and then >>> fill in the different structs in-place. >>> >>> Like: >>> >>> diff --git a/src/main/java/com/brcolow/game/Vulkan.java >>> b/src/main/java/com/brcolow/game/Vulkan.java >>> index f0cd278..520513b 100644 >>> --- a/src/main/java/com/brcolow/game/Vulkan.java >>> +++ b/src/main/java/com/brcolow/game/Vulkan.java >>> @@ -429,17 +429,17 @@ public class Vulkan { >>> var pVertShaderModule = >>> getShaderModule(MemoryAccess.getAddress(pVkDevice), vertShaderBytes, >>> scope); >>> var pFragShaderModule = >>> getShaderModule(MemoryAccess.getAddress(pVkDevice), fragShaderBytes, >>> scope); >>> >>> - var pVertShaderStageInfo = >>> VkPipelineShaderStageCreateInfo.allocate(scope); >>> - VkPipelineShaderStageCreateInfo.sType$set(pVertShaderStageInfo, >>> vulkan_h.VK_STRUCTURE_TYPE_PIPELINE_SHADER_STAGE_CREATE_INFO()); >>> - VkPipelineShaderStageCreateInfo.stage$set(pVertShaderStageInfo, >>> vulkan_h.VK_SHADER_STAGE_VERTEX_BIT()); >>> - VkPipelineShaderStageCreateInfo.module$set(pVertShaderStageInfo, >>> MemoryAccess.getAddress(pVertShaderModule)); >>> - VkPipelineShaderStageCreateInfo.pName$set(pVertShaderStageInfo, >>> CLinker.toCString("main", scope).address()); >>> - >>> - var pFragShaderStageInfo = >>> VkPipelineShaderStageCreateInfo.allocate(scope); >>> - VkPipelineShaderStageCreateInfo.sType$set(pFragShaderStageInfo, >>> vulkan_h.VK_STRUCTURE_TYPE_PIPELINE_SHADER_STAGE_CREATE_INFO()); >>> - VkPipelineShaderStageCreateInfo.stage$set(pFragShaderStageInfo, >>> vulkan_h.VK_SHADER_STAGE_FRAGMENT_BIT()); >>> - VkPipelineShaderStageCreateInfo.module$set(pFragShaderStageInfo, >>> MemoryAccess.getAddress(pFragShaderModule)); >>> - VkPipelineShaderStageCreateInfo.pName$set(pFragShaderStageInfo, >>> CLinker.toCString("main", scope).address()); >>> + MemorySegment pStages = >>> SegmentAllocator.ofScope(scope).allocateArray(VkPipelineShaderStageCreateInfo.$LAYOUT(), >>> >>> 2); >>> + >>> + VkPipelineShaderStageCreateInfo.sType$set(pStages, 0, >>> vulkan_h.VK_STRUCTURE_TYPE_PIPELINE_SHADER_STAGE_CREATE_INFO()); >>> + VkPipelineShaderStageCreateInfo.stage$set(pStages, 0, >>> vulkan_h.VK_SHADER_STAGE_VERTEX_BIT()); >>> + VkPipelineShaderStageCreateInfo.module$set(pStages, 0, >>> MemoryAccess.getAddress(pVertShaderModule)); >>> + VkPipelineShaderStageCreateInfo.pName$set(pStages, 0, >>> CLinker.toCString("main", scope).address()); >>> + >>> + VkPipelineShaderStageCreateInfo.sType$set(pStages, 1, >>> vulkan_h.VK_STRUCTURE_TYPE_PIPELINE_SHADER_STAGE_CREATE_INFO()); >>> + VkPipelineShaderStageCreateInfo.stage$set(pStages, 1, >>> vulkan_h.VK_SHADER_STAGE_FRAGMENT_BIT()); >>> + VkPipelineShaderStageCreateInfo.module$set(pStages, 1, >>> MemoryAccess.getAddress(pFragShaderModule)); >>> + VkPipelineShaderStageCreateInfo.pName$set(pStages, 1, >>> CLinker.toCString("main", scope).address()); >>> >>> var pVertexInputStateInfo = >>> VkPipelineVertexInputStateCreateInfo.allocate(scope); >>> VkPipelineVertexInputStateCreateInfo.sType$set(pVertexInputStateInfo, >>> vulkan_h.VK_STRUCTURE_TYPE_PIPELINE_VERTEX_INPUT_STATE_CREATE_INFO()); >>> @@ -581,16 +581,14 @@ public class Vulkan { >>> // If we change stageCount to 2 we get a crash.... >>> // I think we are creating the pStages array incorrectly. >>> This is also manifesting further down when trying >>> // to create arrays pWaitSemaphores, pSignalSemaphores, >>> etc. >>> - VkGraphicsPipelineCreateInfo.stageCount$set(pPipelineCreateInfo, 1); >>> - MemorySegment pStages = >>> SegmentAllocator.ofScope(scope).allocateArray(C_POINTER, new >>> Addressable[]{ >>> - pVertShaderStageInfo, pFragShaderStageInfo}); >>> - System.out.println("pStages: " + pStages); >>> - System.out.println("pStages[0]: " + >>> VkPipelineShaderStageCreateInfo.ofAddress(MemoryAccess.getAddressAtIndex(pStages, >>> >>> 0), scope)); >>> - System.out.println("pStages[0].sType: " + >>> VkPipelineShaderStageCreateInfo.sType$get(VkPipelineShaderStageCreateInfo.ofAddress(MemoryAccess.getAddressAtIndex(pStages, >>> >>> 0), scope))); >>> - System.out.println("pStages[1]: " + >>> VkPipelineShaderStageCreateInfo.ofAddress(MemoryAccess.getAddressAtIndex(pStages, >>> >>> 1), scope)); >>> - System.out.println("pStages[1].sType: " + >>> VkPipelineShaderStageCreateInfo.sType$get(VkPipelineShaderStageCreateInfo.ofAddress(MemoryAccess.getAddressAtIndex(pStages, >>> >>> 1), scope))); >>> - >>> - VkGraphicsPipelineCreateInfo.pStages$set(pPipelineCreateInfo, >>> MemoryAccess.getAddress(pStages)); >>> + VkGraphicsPipelineCreateInfo.stageCount$set(pPipelineCreateInfo, 2); >>> + System.out.println("pStages: " + pStages.address()); >>> + System.out.println("pStages[0]: " + pStages.asSlice(0, >>> VkPipelineShaderStageCreateInfo.$LAYOUT().byteSize())); >>> + System.out.println("pStages[0].sType: " + >>> VkPipelineShaderStageCreateInfo.sType$get(pStages, 0)); >>> + System.out.println("pStages[1]: " + >>> pStages.asSlice(VkPipelineShaderStageCreateInfo.$LAYOUT().byteSize(), >>> VkPipelineShaderStageCreateInfo.$LAYOUT().byteSize())); >>> + System.out.println("pStages[1].sType: " + >>> VkPipelineShaderStageCreateInfo.sType$get(pStages, 1)); >>> + >>> + VkGraphicsPipelineCreateInfo.pStages$set(pPipelineCreateInfo, >>> pStages.address()); >>> VkGraphicsPipelineCreateInfo.pVertexInputState$set(pPipelineCreateInfo, >>> pVertexInputStateInfo.address()); >>> VkGraphicsPipelineCreateInfo.pInputAssemblyState$set(pPipelineCreateInfo, >>> >>> pPipelineInputAssemblyStateInfo.address()); >>> VkGraphicsPipelineCreateInfo.pViewportState$set(pPipelineCreateInfo, >>> pPipelineViewportStateInfo.address()); >>> >>> HTH, >>> Jorn >>> >>> On 02/09/2021 11:56, Maurizio Cimadamore wrote: >>> > Hi Michael, >>> > very interesting experiments - thanks for reaching out. >>> > >>> > Eyeballing your code, I zoomed into this line: >>> > >>> > >>> https://github.com/brcolow/java-vulkan/blob/master/src/main/java/com/brcolow/game/Vulkan.java#L593 >>> > >>> > >>> > Here you want to set the `pStages` pointer, a pointer to a memory >>> > region which presumably has to contain exactly `stageCount` structs of >>> > type `VkPipelineShaderStageCreateInfo`. >>> > >>> > I believe there's an extra getAddress in there; this: >>> > >>> > ``` >>> > VkGraphicsPipelineCreateInfo.pStages$set(pPipelineCreateInfo, >>> > MemoryAccess.getAddress(pStages)); >>> > ``` >>> > >>> > should be: >>> > >>> > ``` >>> > VkGraphicsPipelineCreateInfo.pStages$set(pPipelineCreateInfo, pStages); >>> > ``` >>> > >>> > That is, you want to pass the pointer to the `pStages` region you just >>> > created, so that Vulkan will be able to see all elements. If you call >>> > "MemoryAccess::getAddress" your code will read the first 64 bits from >>> > the `pStages` region, turn those into a MemoryAddress, and set that >>> > into the enclosing `pPipelineCreateInfo` struct. Which I don't think >>> > is what you want? >>> > >>> > Let me know if this works. >>> > >>> > Cheers >>> > Maurizio >>> > >>> > >>> > On 02/09/2021 06:35, Michael Ennen wrote: >>> >> I have been doing more exploring with the panama-foreign, ffi, and >>> >> jextract >>> >> branches - this time messing around with seeing if I can get a rainbow >>> >> triangle to be rendered on the screen with Vulkan. >>> >> >>> >> I am really close. There is one problem I am having which is how to >>> >> create >>> >> an array of structs? >>> >> >>> >> See this, for example: >>> >> >>> >> >>> https://github.com/brcolow/java-vulkan/blob/master/src/main/java/com/brcolow/game/Vulkan.java#L581 >>> >> >>> >> >>> >> If I set the stageCount to 2, then I get a validation exception about >>> >> the >>> >> second shader module having bogus values. I believe this is caused by >>> me >>> >> creating the array of structs incorrectly. >>> >> >>> >> I am trying to set the pStages element of this struct: >>> >> >>> https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VkGraphicsPipelineCreateInfo.html >>> >> >>> >> >>> >> to an array containing pVertShaderStageInfo and pFragShaderStageInfo. >>> >> >>> >> My attempt (I have tried other ways that also fail) to do that is: >>> >> >>> >> MemorySegment pStages = SegmentAllocator.ofScope(scope).allocateArray( >>> >> C_POINTER, new Addressable[]{ >>> >> pVertShaderStageInfo, pFragShaderStageInfo}); >>> >> VkGraphicsPipelineCreateInfo.pStages$set(pPipelineCreateInfo, >>> >> MemoryAccess.getAddress(pStages)); >>> >> >>> >> >>> >> If anyone could assist me with the proper way to create the >>> >> VkPipelineShaderStageCreateInfo* array containing >>> >> pVertShaderStageInfoand >>> >> pFragShaderStageInfo - it would be greatly appreciated! >>> >> >>> >> >> >> -- >> Michael Ennen >> > > > -- > Michael Ennen > -- Michael Ennen From maurizio.cimadamore at oracle.com Fri Sep 3 22:12:15 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 3 Sep 2021 23:12:15 +0100 Subject: How To Create Array of Structs? In-Reply-To: References: <0c6361f3-2879-02dd-0b26-e26a5b268602@oracle.com> <4bb60084-2958-45f9-511d-638b85770040@oracle.com> Message-ID: <3b5cdab7-e807-a728-7476-6d6d349c9fe2@oracle.com> Hi Michael, I don't think the problem is lack of support for function-like macro. Yes, VK_DEFINE_NON_DISPATCHABLE_HANDLE is a function-like macro, but this declaration: ``` VK_DEFINE_NON_DISPATCHABLE_HANDLE(VkSemaphore) ``` is contained in the header, and preprocessed, so libclang sees something like what you describe: ``` typedef struct VkSemaphore_T *VkSemaphore; ``` The only problem is that jextract is (because of an issue we're investigating) not generating the layout for that typedef. That said, layout or no layout, things are not too different - for all intents and purposes, you can assume that the layout of the handle is just C_POINTER. But you are never supposed to _dereference_ that handle - instead you are supposed to use other functions to create and use semaphores, such as: https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/vkSignalSemaphore.html https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/vkWaitSemaphores.html https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/vkCreateSemaphore.html https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/vkDestroySemaphore.html etc. In other words, inside the handle there's an opaque pointer to memory that is managed by the vulkan library. You are not supposed to know what's inside that memory. Nor you need to know what the size of VkSemaphore_T is. So, if you want to create an array of N semaphores, you just do this ``` MemorySegment semaphores = allocator.allocateArray(C_POINTER, N); ``` Then you will probably have to initialize the pointers in the array, possibly using vkCreateSemaphore. As Radu pointed out, the vkCreateSemaphore API wants you to pass a pointer to a VkSemaphore (which is already a pointer). So, something like this: ``` for (int i = 0 ; i < N ; i++) { ? ? vkCreateSemaphore( ... , semaphores.asSlice(C_POINTER.byteSize() * i) , ...); } ``` This effectively iterates over the semaphore array, gets a slice of the "semaphores" array which starts at the element which needs to be initialized (hence you get a pointer to a VkSemaphore - e.g. a pointer to a pointer), and passes this slice pointer to the vkCreateSemaphore routine. By the time the routine finishes, it should have written something in the array element (the opaque handle). Hope this helps. Maurizio On 03/09/2021 22:50, Michael Ennen wrote: > Let me try and expand upon what I was attempting to communicate yesterday: > > I know that jextract does not currently support function-like macros > so the handles like VkSemaphore are not exposed. > > That's why I tried to first declare it (the array of VkSemaphores) as > a pointer to a pointer. > > But then I cannot get the size of VkSemaphore (really VkSemaphore_T) > so I am unsure how to use the technique you described which does work > in the case > of the VkPipelineShaderStageCreateInfo struct - because it is not an > "opaque" handle. Vulkan uses these a lot, things like VkInstance, > VkDevice, etc. Specifically: > > VkSemaphore is defined by this macro: > > VK_DEFINE_NON_DISPATCHABLE_HANDLE(VkSemaphore) > > Which is how Vulkan does opaque handles (so one cannot inspect the > contents of the VkSemaphore struct and/or rely on it). > > If jextract did support function-like macros then it would expand to > the typedef: > > typedef struct VkSemaphore_T *VkSemaphore; > > and then one could possibly just do VkSemaphore.$LAYOUT() ? Or even > still that may not work because of the "opaque"ness. > > Thanks for any assistance. > > On Thu, Sep 2, 2021 at 11:16 AM Michael Ennen > wrote: > > Quick question that is now happening while trying to replicate the > fix when I don't have an explicit struct handle like in the case > of VkSemaphore: > > https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VkSemaphore.html > > > For those types I don't have a struct layout to work with so I > have been just declaring a double pointer: > > var pVkPipeline = > SegmentAllocator.ofScope(scope).allocate(C_POINTER.byteSize()); > > and then using MemoryAccess.getAddress(pVkPipeline). > > So in this case how can I create an array of VkSemaphore structs > without knowing anything about the struct (it is an opaque handle?). > > Hope that makes sense. > > On Thu, Sep 2, 2021 at 11:06 AM Michael Ennen > > wrote: > > Jorn, > > Thank you so much - that was exactly what I was looking for. I > don't know why I had such trouble trying to create an array of > structs rather than an array of points to structs. > > Thank you both. > > On Thu, Sep 2, 2021 at 4:54 AM Jorn Vernee > > wrote: > > Additionally, it looks like you're allocating an array of > pointers for > pStages, and it looks like the API expects an array of > structs. > > Instead of allocating the different > VkPipelineShaderStageCreateInfo > individually, you should allocate the array of struct > upfront, and then > fill in the different structs in-place. > > Like: > > diff --git a/src/main/java/com/brcolow/game/Vulkan.java > b/src/main/java/com/brcolow/game/Vulkan.java > index f0cd278..520513b 100644 > --- a/src/main/java/com/brcolow/game/Vulkan.java > +++ b/src/main/java/com/brcolow/game/Vulkan.java > @@ -429,17 +429,17 @@ public class Vulkan { > ????????????? var pVertShaderModule = > getShaderModule(MemoryAccess.getAddress(pVkDevice), > vertShaderBytes, scope); > ????????????? var pFragShaderModule = > getShaderModule(MemoryAccess.getAddress(pVkDevice), > fragShaderBytes, scope); > > -??????????? var pVertShaderStageInfo = > VkPipelineShaderStageCreateInfo.allocate(scope); > - > VkPipelineShaderStageCreateInfo.sType$set(pVertShaderStageInfo, > > vulkan_h.VK_STRUCTURE_TYPE_PIPELINE_SHADER_STAGE_CREATE_INFO()); > - > VkPipelineShaderStageCreateInfo.stage$set(pVertShaderStageInfo, > > vulkan_h.VK_SHADER_STAGE_VERTEX_BIT()); > - > VkPipelineShaderStageCreateInfo.module$set(pVertShaderStageInfo, > > MemoryAccess.getAddress(pVertShaderModule)); > - > VkPipelineShaderStageCreateInfo.pName$set(pVertShaderStageInfo, > > CLinker.toCString("main", scope).address()); > - > -??????????? var pFragShaderStageInfo = > VkPipelineShaderStageCreateInfo.allocate(scope); > - > VkPipelineShaderStageCreateInfo.sType$set(pFragShaderStageInfo, > > vulkan_h.VK_STRUCTURE_TYPE_PIPELINE_SHADER_STAGE_CREATE_INFO()); > - > VkPipelineShaderStageCreateInfo.stage$set(pFragShaderStageInfo, > > vulkan_h.VK_SHADER_STAGE_FRAGMENT_BIT()); > - > VkPipelineShaderStageCreateInfo.module$set(pFragShaderStageInfo, > > MemoryAccess.getAddress(pFragShaderModule)); > - > VkPipelineShaderStageCreateInfo.pName$set(pFragShaderStageInfo, > > CLinker.toCString("main", scope).address()); > +??????????? MemorySegment pStages = > SegmentAllocator.ofScope(scope).allocateArray(VkPipelineShaderStageCreateInfo.$LAYOUT(), > > 2); > + > + VkPipelineShaderStageCreateInfo.sType$set(pStages, 0, > vulkan_h.VK_STRUCTURE_TYPE_PIPELINE_SHADER_STAGE_CREATE_INFO()); > + VkPipelineShaderStageCreateInfo.stage$set(pStages, 0, > vulkan_h.VK_SHADER_STAGE_VERTEX_BIT()); > + VkPipelineShaderStageCreateInfo.module$set(pStages, 0, > MemoryAccess.getAddress(pVertShaderModule)); > + VkPipelineShaderStageCreateInfo.pName$set(pStages, 0, > CLinker.toCString("main", scope).address()); > + > + VkPipelineShaderStageCreateInfo.sType$set(pStages, 1, > vulkan_h.VK_STRUCTURE_TYPE_PIPELINE_SHADER_STAGE_CREATE_INFO()); > + VkPipelineShaderStageCreateInfo.stage$set(pStages, 1, > vulkan_h.VK_SHADER_STAGE_FRAGMENT_BIT()); > + VkPipelineShaderStageCreateInfo.module$set(pStages, 1, > MemoryAccess.getAddress(pFragShaderModule)); > + VkPipelineShaderStageCreateInfo.pName$set(pStages, 1, > CLinker.toCString("main", scope).address()); > > ????????????? var pVertexInputStateInfo = > VkPipelineVertexInputStateCreateInfo.allocate(scope); > VkPipelineVertexInputStateCreateInfo.sType$set(pVertexInputStateInfo, > > vulkan_h.VK_STRUCTURE_TYPE_PIPELINE_VERTEX_INPUT_STATE_CREATE_INFO()); > @@ -581,16 +581,14 @@ public class Vulkan { > ????????????? // If we change stageCount to 2 we get a > crash.... > ????????????? // I think we are creating the pStages array > incorrectly. > This is also manifesting further down when trying > ????????????? // to create arrays pWaitSemaphores, > pSignalSemaphores, etc. > - > VkGraphicsPipelineCreateInfo.stageCount$set(pPipelineCreateInfo, > 1); > -??????????? MemorySegment pStages = > SegmentAllocator.ofScope(scope).allocateArray(C_POINTER, > new Addressable[]{ > -??????????????????? pVertShaderStageInfo, > pFragShaderStageInfo}); > -??????????? System.out.println("pStages: " + pStages); > -??????????? System.out.println("pStages[0]: " + > VkPipelineShaderStageCreateInfo.ofAddress(MemoryAccess.getAddressAtIndex(pStages, > > 0), scope)); > -??????????? System.out.println("pStages[0].sType: " + > VkPipelineShaderStageCreateInfo.sType$get(VkPipelineShaderStageCreateInfo.ofAddress(MemoryAccess.getAddressAtIndex(pStages, > > 0), scope))); > -??????????? System.out.println("pStages[1]: " + > VkPipelineShaderStageCreateInfo.ofAddress(MemoryAccess.getAddressAtIndex(pStages, > > 1), scope)); > -??????????? System.out.println("pStages[1].sType: " + > VkPipelineShaderStageCreateInfo.sType$get(VkPipelineShaderStageCreateInfo.ofAddress(MemoryAccess.getAddressAtIndex(pStages, > > 1), scope))); > - > - > VkGraphicsPipelineCreateInfo.pStages$set(pPipelineCreateInfo, > MemoryAccess.getAddress(pStages)); > + > VkGraphicsPipelineCreateInfo.stageCount$set(pPipelineCreateInfo, > 2); > +??????????? System.out.println("pStages: " + > pStages.address()); > +??????????? System.out.println("pStages[0]: " + > pStages.asSlice(0, > VkPipelineShaderStageCreateInfo.$LAYOUT().byteSize())); > +??????????? System.out.println("pStages[0].sType: " + > VkPipelineShaderStageCreateInfo.sType$get(pStages, 0)); > +??????????? System.out.println("pStages[1]: " + > pStages.asSlice(VkPipelineShaderStageCreateInfo.$LAYOUT().byteSize(), > > VkPipelineShaderStageCreateInfo.$LAYOUT().byteSize())); > +??????????? System.out.println("pStages[1].sType: " + > VkPipelineShaderStageCreateInfo.sType$get(pStages, 1)); > + > + > VkGraphicsPipelineCreateInfo.pStages$set(pPipelineCreateInfo, > pStages.address()); > VkGraphicsPipelineCreateInfo.pVertexInputState$set(pPipelineCreateInfo, > > pVertexInputStateInfo.address()); > VkGraphicsPipelineCreateInfo.pInputAssemblyState$set(pPipelineCreateInfo, > > pPipelineInputAssemblyStateInfo.address()); > VkGraphicsPipelineCreateInfo.pViewportState$set(pPipelineCreateInfo, > > pPipelineViewportStateInfo.address()); > > HTH, > Jorn > > On 02/09/2021 11:56, Maurizio Cimadamore wrote: > > Hi Michael, > > very interesting experiments - thanks for reaching out. > > > > Eyeballing your code, I zoomed into this line: > > > > > https://github.com/brcolow/java-vulkan/blob/master/src/main/java/com/brcolow/game/Vulkan.java#L593 > > > > > > > > Here you want to set the `pStages` pointer, a pointer to > a memory > > region which presumably has to contain exactly > `stageCount` structs of > > type `VkPipelineShaderStageCreateInfo`. > > > > I believe there's an extra getAddress in there; this: > > > > ``` > > > VkGraphicsPipelineCreateInfo.pStages$set(pPipelineCreateInfo, > > MemoryAccess.getAddress(pStages)); > > ``` > > > > should be: > > > > ``` > > > VkGraphicsPipelineCreateInfo.pStages$set(pPipelineCreateInfo, > pStages); > > ``` > > > > That is, you want to pass the pointer to the `pStages` > region you just > > created, so that Vulkan will be able to see all > elements. If you call > > "MemoryAccess::getAddress" your code will read the first > 64 bits from > > the `pStages` region, turn those into a MemoryAddress, > and set that > > into the enclosing `pPipelineCreateInfo` struct. Which I > don't think > > is what you want? > > > > Let me know if this works. > > > > Cheers > > Maurizio > > > > > > On 02/09/2021 06:35, Michael Ennen wrote: > >> I have been doing more exploring with the > panama-foreign, ffi, and > >> jextract > >> branches - this time messing around with seeing if I > can get a rainbow > >> triangle to be rendered on the screen with Vulkan. > >> > >> I am really close. There is one problem I am having > which is how to > >> create > >> an array of structs? > >> > >> See this, for example: > >> > >> > https://github.com/brcolow/java-vulkan/blob/master/src/main/java/com/brcolow/game/Vulkan.java#L581 > > > >> > >> > >> If I set the stageCount to 2, then I get a validation > exception about > >> the > >> second shader module having bogus values. I believe > this is caused by me > >> creating the array of structs incorrectly. > >> > >> I am trying to set the pStages element of this struct: > >> > https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VkGraphicsPipelineCreateInfo.html > > > >> > >> > >> to an array containing pVertShaderStageInfo and > pFragShaderStageInfo. > >> > >> My attempt (I have tried other ways that also fail) to > do that is: > >> > >> MemorySegment pStages = > SegmentAllocator.ofScope(scope).allocateArray( > >> C_POINTER, new Addressable[]{ > >> pVertShaderStageInfo, pFragShaderStageInfo}); > >> > VkGraphicsPipelineCreateInfo.pStages$set(pPipelineCreateInfo, > >> MemoryAccess.getAddress(pStages)); > >> > >> > >> If anyone could assist me with the proper way to create the > >> VkPipelineShaderStageCreateInfo* array containing > >> pVertShaderStageInfoand > >> pFragShaderStageInfo - it would be greatly appreciated! > >> > > > > -- > Michael Ennen > > > > -- > Michael Ennen > > > > -- > Michael Ennen From kartikohri13 at gmail.com Sat Sep 4 12:53:46 2021 From: kartikohri13 at gmail.com (Kartik Ohri) Date: Sat, 4 Sep 2021 18:23:46 +0530 Subject: Arrays.mismatch intrinsic and Vector API comparision In-Reply-To: <71444AEA-0386-417D-B6CB-0ABF957E107A@oracle.com> References: <71444AEA-0386-417D-B6CB-0ABF957E107A@oracle.com> Message-ID: Hi Paul, Thanks for the feedback! I'll add more cases as you suggested and submit a PR. Regards, Kartik On Fri, Sep 3, 2021 at 3:41 AM Paul Sandoz wrote: > Hi Kartik, > > Thank you. It is useful. I am glad we are reaching the point where the > Vector API is getting competitive with the mismatch stub. > > If you would like to contribute the benchmark I would be happy to review a > PR. > We could also measure int, float and long, in addition to small sizes, > just above or below the vector length (not dissimilar to a mismatch on the > the first or lower index of an array). > When we wrote Arrays.mismatch we were very careful to measure the impact > on small array sizes, since that method is also used to support > Arrays.equals and we did not want to introduce a performance regression. > > > Some of the difference might be explained by alignment of the arrays, some > perhaps due to loop unrolling. > > I think there might be an issue with loop unrolling. It seems too > aggressive, resulting larger than necessary nmethod sizes. We should look > into that. > > > Unsure if it's possible to to reduce [*]: > > vpcmpeqb %ymm1,%ymm0,%ymm0 > vpxor -0x7ad507d(%rip),%ymm0,%ymm0 > > to: > > vpxor %ymm1,%ymm0,%ymm0 > > Since the latter will not produce a valid mask representation, which could > affect later use of the mask value (firstTrue). > > Paul. > > [*] > https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/macroAssembler_x86.cpp#L3211 > > > On Aug 29, 2021, at 11:36 AM, Kartik Ohri > wrote: > > > > Hi! > > > > I have started experimenting with the Vector API recently. Currently, I > am > > playing with the API and trying to gauge its potential by comparing its > > performance with vectorized intrinsics implemented inside the JDK. I know > > that Arrays.mismatch has a vectorized intrinsic so I started with it. I > was > > able to come up with a simple implementation for it using the Vector API. > > The results of the JMH benchmark look quite promising, the Vector API is > > able to come quite close to the intrinsic. This is awesome!! > > > > The benchmark code is available here > > < > https://github.com/amCap1712/curly-computing-machine/blob/main/src/main/java/dev/lucifer/benchmarks/ArrayMismatchBenchmark.java > > > > and > > the complete benchmark logs are here > > < > https://github.com/amCap1712/curly-computing-machine/blob/main/results/array-mismatch.csv > >. > > I also did another run to check the assembly generated which is also > > available here > > < > https://github.com/amCap1712/curly-computing-machine/blob/main/results/benchmarks.asm.log > >. > > It would be nice to get a sanity check on the benchmark before I proceed > > further. > > > > Both versions perform more or less the same (difference is less than 5%, > in > > some cases the Vector API even outperforms the intrinsic). There is one > > outlier where the Vector API is almost 35% slower than the intrinsic > (when > > prefix is 1 and size is 10000). > > except for when the prefix is 1 i.e. both input arrays are equal. I see > > that the assembly emitted by Vector API > > < > https://github.com/amCap1712/curly-computing-machine/blob/main/results/benchmarks.asm.log#L7436 > > > > contains a *vpcmpeqb* but the JDK intrinsic > > < > https://github.com/amCap1712/curly-computing-machine/blob/main/results/benchmarks.asm.log#L2064 > > > > does not. Looking at the implementation > > < > https://github.com/openjdk/panama-vector/blob/2fd7943ec191559bfb2778305daf82bcc4422028/src/hotspot/cpu/x86/macroAssembler_x86.cpp#L6088-L6125 > > > > of the intrinsic in the JDK, The AVX 512 version uses *vpcmpeqb* but the > > AVX2 version does not (my machine does not have AVX 512 so it makes that > it > > was not emitted in the case of the intrinsic). Secondly, from the > assembly > > it seems that the Vector API version was unrolled but the intrinsic was > > not. If I am right, in general loop unrolling is better so the API seems > to > > be doing the right thing. Hence, I am not sure why this particular case > is > > an outlier. > > > > Further, Is analysing/comparing intrinsics within the JDK to the Vector > API > > useful? > > > > Also, any other suggestions regarding contributing to the Project are > > welcome. > > > > Regards, > > Kartik > > From mail at smogura.eu Sat Sep 4 15:00:47 2021 From: mail at smogura.eu (Rado Smogura) Date: Sat, 4 Sep 2021 17:00:47 +0200 Subject: Arrays.mismatch intrinsic and Vector API comparision In-Reply-To: References: <71444AEA-0386-417D-B6CB-0ABF957E107A@oracle.com> Message-ID: Hi all, Interesting topic. In context of too aggressive unrolling. I think I know what could be a reason. There's standard unroll limit, however vectorization can increase it - https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/loopTransform.cpp#L998 On my machine the new limit is 32, I guess for AVX-512 it could be 64. Kind regards, Rado On 04.09.2021 14:53, Kartik Ohri wrote: > Hi Paul, > > Thanks for the feedback! I'll add more cases as you suggested and submit a > PR. > > Regards, > Kartik > > On Fri, Sep 3, 2021 at 3:41 AM Paul Sandoz wrote: > >> Hi Kartik, >> >> Thank you. It is useful. I am glad we are reaching the point where the >> Vector API is getting competitive with the mismatch stub. >> >> If you would like to contribute the benchmark I would be happy to review a >> PR. >> We could also measure int, float and long, in addition to small sizes, >> just above or below the vector length (not dissimilar to a mismatch on the >> the first or lower index of an array). >> When we wrote Arrays.mismatch we were very careful to measure the impact >> on small array sizes, since that method is also used to support >> Arrays.equals and we did not want to introduce a performance regression. >> >> >> Some of the difference might be explained by alignment of the arrays, some >> perhaps due to loop unrolling. >> >> I think there might be an issue with loop unrolling. It seems too >> aggressive, resulting larger than necessary nmethod sizes. We should look >> into that. >> >> >> Unsure if it's possible to to reduce [*]: >> >> vpcmpeqb %ymm1,%ymm0,%ymm0 >> vpxor -0x7ad507d(%rip),%ymm0,%ymm0 >> >> to: >> >> vpxor %ymm1,%ymm0,%ymm0 >> >> Since the latter will not produce a valid mask representation, which could >> affect later use of the mask value (firstTrue). >> >> Paul. >> >> [*] >> https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/macroAssembler_x86.cpp#L3211 >> >>> On Aug 29, 2021, at 11:36 AM, Kartik Ohri >> wrote: >>> Hi! >>> >>> I have started experimenting with the Vector API recently. Currently, I >> am >>> playing with the API and trying to gauge its potential by comparing its >>> performance with vectorized intrinsics implemented inside the JDK. I know >>> that Arrays.mismatch has a vectorized intrinsic so I started with it. I >> was >>> able to come up with a simple implementation for it using the Vector API. >>> The results of the JMH benchmark look quite promising, the Vector API is >>> able to come quite close to the intrinsic. This is awesome!! >>> >>> The benchmark code is available here >>> < >> https://github.com/amCap1712/curly-computing-machine/blob/main/src/main/java/dev/lucifer/benchmarks/ArrayMismatchBenchmark.java >>> and >>> the complete benchmark logs are here >>> < >> https://github.com/amCap1712/curly-computing-machine/blob/main/results/array-mismatch.csv >>> . >>> I also did another run to check the assembly generated which is also >>> available here >>> < >> https://github.com/amCap1712/curly-computing-machine/blob/main/results/benchmarks.asm.log >>> . >>> It would be nice to get a sanity check on the benchmark before I proceed >>> further. >>> >>> Both versions perform more or less the same (difference is less than 5%, >> in >>> some cases the Vector API even outperforms the intrinsic). There is one >>> outlier where the Vector API is almost 35% slower than the intrinsic >> (when >>> prefix is 1 and size is 10000). >>> except for when the prefix is 1 i.e. both input arrays are equal. I see >>> that the assembly emitted by Vector API >>> < >> https://github.com/amCap1712/curly-computing-machine/blob/main/results/benchmarks.asm.log#L7436 >>> contains a *vpcmpeqb* but the JDK intrinsic >>> < >> https://github.com/amCap1712/curly-computing-machine/blob/main/results/benchmarks.asm.log#L2064 >>> does not. Looking at the implementation >>> < >> https://github.com/openjdk/panama-vector/blob/2fd7943ec191559bfb2778305daf82bcc4422028/src/hotspot/cpu/x86/macroAssembler_x86.cpp#L6088-L6125 >>> of the intrinsic in the JDK, The AVX 512 version uses *vpcmpeqb* but the >>> AVX2 version does not (my machine does not have AVX 512 so it makes that >> it >>> was not emitted in the case of the intrinsic). Secondly, from the >> assembly >>> it seems that the Vector API version was unrolled but the intrinsic was >>> not. If I am right, in general loop unrolling is better so the API seems >> to >>> be doing the right thing. Hence, I am not sure why this particular case >> is >>> an outlier. >>> >>> Further, Is analysing/comparing intrinsics within the JDK to the Vector >> API >>> useful? >>> >>> Also, any other suggestions regarding contributing to the Project are >>> welcome. >>> >>> Regards, >>> Kartik From john.r.rose at oracle.com Sat Sep 4 18:17:30 2021 From: john.r.rose at oracle.com (John Rose) Date: Sat, 4 Sep 2021 18:17:30 +0000 Subject: [vectorIntrinsics+mask] RFR: 8273057: [vector] New VectorAPI "SelectiveStore" In-Reply-To: <61F91394-25CE-4D37-AB02-3B2093C1629D@oracle.com> References: <4556C43C-6DB8-4DFE-BA9F-0725D7939189@oracle.com> <61F91394-25CE-4D37-AB02-3B2093C1629D@oracle.com> Message-ID: <0F100AD7-EC3E-42DA-8BF7-05C412CF623B@oracle.com> On Sep 3, 2021, at 1:11 PM, Paul Sandoz > wrote: ... John, your observation on order really stood out to me. I can see how a prefix-sum might behave with a mask describing the selection of lanes *and* compression of the result (no intermediate values, either from the input or zero). Yes, this whole thread is a very good exercise in what we call ?find the primitive?. Which means taking some use cases, and some hardware capabilities, and some known optimization techniques, and deciding how to factor down the use cases into uses of the latter capabilities and techniques, such that (a) the use cases are well optimized and (b) a naturally wide set of future use cases are supported. (And by ?naturally? I mean the chose primitives directly give access to the capabilities and techniques, so that it is new use cases ?grow out of? the existing primitives without additional deep insights.) In summary, from the discussion, compress/expand are: - important conceptually, even if the same functionality could be composed from shuffles (such as used by an implementation); and Compression can be composed from *colliding* shuffles, which are a special kind of thing I call an anti-shuffle. I suspect *that* is the really interesting primitive here. - at the right level to reliably optimize on supporting hardware. So specification-wise we introduce expanding/compressing cross-lane operations. API-wise I prefer two distinct methods rather that one that accepts boolean indicating expansion or compression. We can declare one intrinsic method in VectorSupport. Yes, a function and its inverse are usually not best accessed by a boolean option that says ?select the inverse?. Partly this is because the edge effects and exceptions (such as collisions for anti-shuffle but not shuffle) make the types of the function and its inverse subtly different. From john.r.rose at oracle.com Sat Sep 4 18:48:19 2021 From: john.r.rose at oracle.com (John Rose) Date: Sat, 4 Sep 2021 18:48:19 +0000 Subject: [vectorIntrinsics+mask] RFR: 8273057: [vector] New VectorAPI "SelectiveStore" In-Reply-To: <61F91394-25CE-4D37-AB02-3B2093C1629D@oracle.com> References: <4556C43C-6DB8-4DFE-BA9F-0725D7939189@oracle.com> <61F91394-25CE-4D37-AB02-3B2093C1629D@oracle.com> Message-ID: <7CCEE419-80A2-4D94-A7FA-EB36D9A7B309@oracle.com> On Sep 3, 2021, at 1:11 PM, Paul Sandoz > wrote: I can see how a prefix-sum might behave with a mask describing the selection of lanes *and* compression of the result (no intermediate values, either from the input or zero). Prefix sums (aka scans) are surprisingly powerful. - scans can use any associative operator (not just sum: min, max, first-non-zero, etc.) - scans can be implemented in log time (reduction ?up-sweep? and computation ?down-sweep? on lane spanning tree) - come in ?inclusive? and ?exclusive? form (aka Hillis/Steele and Blelloch; Blelloch calls his a ?prescan?) - scale naturally to arbitrary lengths - partition naturally into vectorizable sub-lengths (N.B. requires carry-in and carry-out feature!) - provide a good primitive for ?nested SIMD? [1] - often provide useful ?steering? information for subsequent loads/stores or shuffles/anti-shuffles [2] [1] To perform a data-parallel/SIMD operation simultaneously on N SIMD data sets {S[i]}, first concatenate them all into a single SIMD data set G (unravel an array into a stream of values, for example), keeping elements in the same original data set contiguous in the new data set, and add a new boolean vector, a ?boundary mask? which marks boundaries of the original data sets within the new data set. (This does not need a group field in [1..N], just a boolean, because groups are contiguous in the big set.) Do SIMD on the whole thing. When performing scans or reduces, use the segmented variation of the scan or reduce, which consults the boundary mask and prevents carry-ins and carry-outs across boundaries. Reductions and carry-outs from up-sweeps go into sparse SIMD data sets which can be quickly compressed to N-vectors, carrying the per-group results. Collecting per-group results is where compress shines. The procedure outlined here is very robust across group sizes: It basically works the same, and with the same efficiency, whether you N=1 or N=|G| and regardless of the statistics of the group sizes |S[i]|. [2] When you have an ordering problem, like vectorized sort or compress, look first for a scan pre-pass that could use to steer a data-movement pass. I find this often clarifies the problem and suggests new vectorization opportunities. From john.r.rose at oracle.com Sat Sep 4 18:56:11 2021 From: john.r.rose at oracle.com (John Rose) Date: Sat, 4 Sep 2021 18:56:11 +0000 Subject: [vectorIntrinsics+mask] RFR: 8273057: [vector] New VectorAPI "SelectiveStore" In-Reply-To: <7CCEE419-80A2-4D94-A7FA-EB36D9A7B309@oracle.com> References: <4556C43C-6DB8-4DFE-BA9F-0725D7939189@oracle.com> <61F91394-25CE-4D37-AB02-3B2093C1629D@oracle.com> <7CCEE419-80A2-4D94-A7FA-EB36D9A7B309@oracle.com> Message-ID: <0E80890B-94A6-42F2-87CE-15D296729644@oracle.com> P.S. Some googly references that seem useful for me: https://en.wikipedia.org/wiki/Prefix_sum https://www.cs.princeton.edu/courses/archive/fall21/cos326/lec/21-02-parallel-prefix-scan.pdf https://www.cs.cmu.edu/~guyb/papers/Ble93.pdf (from Connection Machine days, still relevant if you translate terms) You can find your own easily, of course. I suppose there are plenty of GPU people who have rediscovered this stuff recently. Appel traces the basics back to 1977. So here?s a basic tool for our toolkit: Watch out for segmented scans and reductions, even in disguise (say, as nested or grouped parallelism). Use them to turn brute-force iteration into log-N data parallel operations. (Will the hardware reward your rewrite of the algorithm? One may hope? Sometimes it does.) From jiefu at openjdk.java.net Sun Sep 5 14:10:28 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Sun, 5 Sep 2021 14:10:28 GMT Subject: [vectorIntrinsics+mask] RFR: 8273205: [vector] Crash in C2_MacroAssembler::vprotate_var after JDK-8271366 In-Reply-To: <2PM0lqpC20oqtHrIow2TDNb2zcauuGTRrlMtfoQF_h4=.001b5773-0928-403e-9e96-d995a2fa90b8@github.com> References: <2PM0lqpC20oqtHrIow2TDNb2zcauuGTRrlMtfoQF_h4=.001b5773-0928-403e-9e96-d995a2fa90b8@github.com> Message-ID: On Fri, 3 Sep 2021 14:01:25 GMT, Jie Fu wrote: > Hi all, > > After JDK-8271366, `arch_supports_vector()` fails to check whether the rotate operation is directly supported by the target ISA. > > So `Matcher::match_rule_supported_vector` should be added in `inline_vector_broadcast_int()` and `inline_vector_nary_operation()` to prevent generation of unsupported rotate operation IR patterns. > > Thanks. > Best regards, > Jie After more investigation, this bug won't reproduce in jdk repo and can be fixed like this. diff --git a/src/hotspot/share/opto/vectorIntrinsics.cpp b/src/hotspot/share/opto/vectorIntrinsics.cpp index 3019cb8..ae4035c 100644 --- a/src/hotspot/share/opto/vectorIntrinsics.cpp +++ b/src/hotspot/share/opto/vectorIntrinsics.cpp @@ -536,6 +536,7 @@ bool LibraryCallKit::inline_vector_nary_operation(int n) { operation->add_req(mask); operation->add_flag(Node::Flag_is_predicated_vector); } else { + operation = gvn().transform(operation); operation = new VectorBlendNode(opd1, operation, mask); } } @@ -2237,6 +2238,7 @@ bool LibraryCallKit::inline_vector_broadcast_int() { operation->add_req(mask); operation->add_flag(Node::Flag_is_predicated_vector); } else { + operation = gvn().transform(operation); operation = new VectorBlendNode(opd1, operation, mask); } } ------------- PR: https://git.openjdk.java.net/panama-vector/pull/119 From jiefu at openjdk.java.net Sun Sep 5 14:17:17 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Sun, 5 Sep 2021 14:17:17 GMT Subject: [vectorIntrinsics+mask] RFR: 8273205: [vector] Crash in C2_MacroAssembler::vprotate_var after JDK-8271366 [v2] In-Reply-To: <2PM0lqpC20oqtHrIow2TDNb2zcauuGTRrlMtfoQF_h4=.001b5773-0928-403e-9e96-d995a2fa90b8@github.com> References: <2PM0lqpC20oqtHrIow2TDNb2zcauuGTRrlMtfoQF_h4=.001b5773-0928-403e-9e96-d995a2fa90b8@github.com> Message-ID: > Hi all, > > After JDK-8271366, `arch_supports_vector()` fails to check whether the rotate operation is directly supported by the target ISA. > > So `Matcher::match_rule_supported_vector` should be added in `inline_vector_broadcast_int()` and `inline_vector_nary_operation()` to prevent generation of unsupported rotate operation IR patterns. > > Thanks. > Best regards, > Jie Jie Fu has updated the pull request incrementally with one additional commit since the last revision: Add gvn().transform for rotate operation ------------- Changes: - all: https://git.openjdk.java.net/panama-vector/pull/119/files - new: https://git.openjdk.java.net/panama-vector/pull/119/files/1bfc8154..630b4d02 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=119&range=01 - incr: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=119&range=00-01 Stats: 11 lines in 1 file changed: 2 ins; 9 del; 0 mod Patch: https://git.openjdk.java.net/panama-vector/pull/119.diff Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/119/head:pull/119 PR: https://git.openjdk.java.net/panama-vector/pull/119 From jiefu at openjdk.java.net Sun Sep 5 14:31:00 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Sun, 5 Sep 2021 14:31:00 GMT Subject: [vectorIntrinsics+mask] RFR: 8273205: [vector] Crash in C2_MacroAssembler::vprotate_var after JDK-8271366 [v2] In-Reply-To: References: <2PM0lqpC20oqtHrIow2TDNb2zcauuGTRrlMtfoQF_h4=.001b5773-0928-403e-9e96-d995a2fa90b8@github.com> Message-ID: On Sun, 5 Sep 2021 14:17:17 GMT, Jie Fu wrote: >> Hi all, >> >> After JDK-8271366, `arch_supports_vector()` fails to check whether the rotate operation is directly supported by the target ISA. >> >> So `Matcher::match_rule_supported_vector` should be added in `inline_vector_broadcast_int()` and `inline_vector_nary_operation()` to prevent generation of unsupported rotate operation IR patterns. >> >> Thanks. >> Best regards, >> Jie > > Jie Fu has updated the pull request incrementally with one additional commit since the last revision: > > Add gvn().transform for rotate operation The reason for the crash is that rotate operation fails to degenerate_vector_rotate when `use_predicate=false` on unsupported platforms. To call `VectorNode::degenerate_vector_rotate`, `gvn().transform(operation)` should be added. More testing is in progress. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/119 From swpalmer at gmail.com Sun Sep 5 20:09:07 2021 From: swpalmer at gmail.com (Scott Palmer) Date: Sun, 5 Sep 2021 16:09:07 -0400 Subject: Vector API Questions Message-ID: Is this list appropriate for questions involving the Vector API? (I scanned the list at https://mail.openjdk.java.net/mailman/listinfo but didn?t see anything) E.g. questions such as, Are there plans to support operation XXX? I?m looking for something like: https://www.felixcloutier.com/x86/punpcklbw:punpcklwd:punpckldq:punpcklqdq Or performance related queries? I tried to convert this simple operation to use the Vector API (on 2MB source buffers) and the result iI got was 15x slower than this byte-wise loop: void widen(ByteBuffer srcBuff , ByteBuffer dstBuff ) { while (srcBuff.hasRemaining()) { dstBuff.putShort((short) (srcBuff.get() << 8)); } } My attempt using JDK 16 on macOS (Intel) looked like: final int BYTE_PREFERRED_SPECIES_LENGTH = ByteVector.SPECIES_PREFERRED.length(); final int loopBound = ByteVector.SPECIES_PREFERRED.loopBound(srcBuff.remaining()); int si = 0; int di = 0; for (; si < loopBound; si += BYTE_PREFERRED_SPECIES_LENGTH) { ByteVector srcVec = ByteVector.fromByteBuffer(ByteVector.SPECIES_PREFERRED, srcBuff, si, NATIVE_ORDER); srcVec.convert(VectorOperators.B2S, 0) .lanewise(VectorOperators.LSHL, 8) .intoByteBuffer(dstBuff, di, NATIVE_ORDER); di += BYTE_PREFERRED_SPECIES_LENGTH; srcVec.convert(VectorOperators.B2S, 1) .lanewise(VectorOperators.LSHL, 8) .intoByteBuffer(dstBuff, PD_di, NATIVE_ORDER); di += BYTE_PREFERRED_SPECIES_LENGTH; } If this is the wrong place for these kinds of questions, please point me in the right direction. Thanks, Scott From john.r.rose at oracle.com Sun Sep 5 22:27:22 2021 From: john.r.rose at oracle.com (John Rose) Date: Sun, 5 Sep 2021 22:27:22 +0000 Subject: Vector API Questions In-Reply-To: References: Message-ID: I think those are hardware specialized shuffles, right? So try a shuffle. We should try to recognize fixed shuffles that can be handled by special instructions. That?s the basic approach. It doesn?t need a new primitive but maybe some convenience functions and better instruction selection. > On Sep 5, 2021, at 1:09 PM, Scott Palmer wrote: > > ?Is this list appropriate for questions involving the Vector API? (I scanned the list at https://mail.openjdk.java.net/mailman/listinfo but didn?t see anything) > > E.g. questions such as, > > Are there plans to support operation XXX? > > I?m looking for something like: https://www.felixcloutier.com/x86/punpcklbw:punpcklwd:punpckldq:punpcklqdq > > Or performance related queries? > > I tried to convert this simple operation to use the Vector API (on 2MB source buffers) and the result iI got was 15x slower than this byte-wise loop: > > void widen(ByteBuffer srcBuff , ByteBuffer dstBuff ) { > while (srcBuff.hasRemaining()) { > dstBuff.putShort((short) (srcBuff.get() << 8)); > } > } > > > My attempt using JDK 16 on macOS (Intel) looked like: > > final int BYTE_PREFERRED_SPECIES_LENGTH = ByteVector.SPECIES_PREFERRED.length(); > final int loopBound = ByteVector.SPECIES_PREFERRED.loopBound(srcBuff.remaining()); > int si = 0; > int di = 0; > for (; si < loopBound; si += BYTE_PREFERRED_SPECIES_LENGTH) { > ByteVector srcVec = ByteVector.fromByteBuffer(ByteVector.SPECIES_PREFERRED, srcBuff, si, NATIVE_ORDER); > srcVec.convert(VectorOperators.B2S, 0) > .lanewise(VectorOperators.LSHL, 8) > .intoByteBuffer(dstBuff, di, NATIVE_ORDER); > di += BYTE_PREFERRED_SPECIES_LENGTH; > > srcVec.convert(VectorOperators.B2S, 1) > .lanewise(VectorOperators.LSHL, 8) > .intoByteBuffer(dstBuff, PD_di, NATIVE_ORDER); > di += BYTE_PREFERRED_SPECIES_LENGTH; > } > > If this is the wrong place for these kinds of questions, please point me in the right direction. > > Thanks, > > Scott From swpalmer at gmail.com Mon Sep 6 00:20:27 2021 From: swpalmer at gmail.com (Scott Palmer) Date: Sun, 5 Sep 2021 20:20:27 -0400 Subject: Vector API Questions In-Reply-To: References: Message-ID: <4831F458-9418-47AC-9353-17F94882E487@gmail.com> Yes, a shuffle works for the operation I was looking for. Though my attempt at implementing the basic 8 bit -> 16 bit conversion loop in my original email is even slower when I tried a version using a shuffle instead of converting to shorts and shifting. My basic loop to convert from bytes to shorts by shifting byte values to the high byte of the short is 70 times faster without using the Vector API in that case! I have to wonder if I?m doing something horribly wrong. It should be possible for this simple loop: void widen(ByteBuffer srcBuff , ByteBuffer dstBuff ) { while (srcBuff.hasRemaining()) { dstBuff.putShort((short) (srcBuff.get() << 8)); } } to go much faster when using vector instructions that operator on 32 bytes at a time. But this is 70x slower: int si = 0; int di = 0; final int loopBound = ByteVector.SPECIES_PREFERRED.loopBound(srcBuff.remaining()); for (; si < loopBound; si += BYTE_SPECIES_LENGTH) { ByteVector srcVec = ByteVector.fromByteBuffer(ByteVector.SPECIES_PREFERRED, srcBuff, si, NATIVE_ORDER); srcVec.rearrange(EXPANDING_SHUFFLE_LO, ZERO).intoByteBuffer(dstBuff, di, NATIVE_ORDER); di += BYTE_SPECIES_LENGTH; srcVec.rearrange(EXPANDING_SHUFFLE_HI, ZERO).intoByteBuffer(dstBuff, di, NATIVE_ORDER); di += BYTE_SPECIES_LENGTH; } Both vector versions I?ve tried are at least an order of magnitude slower than the scalar code. I?m I doing something wrong? Thanks, Scott > On Sep 5, 2021, at 6:27 PM, John Rose wrote: > > I think those are hardware specialized shuffles, right? So try a shuffle. We should try to recognize fixed shuffles that can be handled by special instructions. That?s the basic approach. It doesn?t need a new primitive but maybe some convenience functions and better instruction selection. > >> On Sep 5, 2021, at 1:09 PM, Scott Palmer wrote: >> >> ?Is this list appropriate for questions involving the Vector API? (I scanned the list at https://mail.openjdk.java.net/mailman/listinfo but didn?t see anything) >> >> E.g. questions such as, >> >> Are there plans to support operation XXX? >> >> I?m looking for something like: https://www.felixcloutier.com/x86/punpcklbw:punpcklwd:punpckldq:punpcklqdq >> >> Or performance related queries? >> >> I tried to convert this simple operation to use the Vector API (on 2MB source buffers) and the result iI got was 15x slower than this byte-wise loop: >> >> void widen(ByteBuffer srcBuff , ByteBuffer dstBuff ) { >> while (srcBuff.hasRemaining()) { >> dstBuff.putShort((short) (srcBuff.get() << 8)); >> } >> } >> >> >> My attempt using JDK 16 on macOS (Intel) looked like: >> >> final int BYTE_PREFERRED_SPECIES_LENGTH = ByteVector.SPECIES_PREFERRED.length(); >> final int loopBound = ByteVector.SPECIES_PREFERRED.loopBound(srcBuff.remaining()); >> int si = 0; >> int di = 0; >> for (; si < loopBound; si += BYTE_PREFERRED_SPECIES_LENGTH) { >> ByteVector srcVec = ByteVector.fromByteBuffer(ByteVector.SPECIES_PREFERRED, srcBuff, si, NATIVE_ORDER); >> srcVec.convert(VectorOperators.B2S, 0) >> .lanewise(VectorOperators.LSHL, 8) >> .intoByteBuffer(dstBuff, di, NATIVE_ORDER); >> di += BYTE_PREFERRED_SPECIES_LENGTH; >> >> srcVec.convert(VectorOperators.B2S, 1) >> .lanewise(VectorOperators.LSHL, 8) >> .intoByteBuffer(dstBuff, PD_di, NATIVE_ORDER); >> di += BYTE_PREFERRED_SPECIES_LENGTH; >> } >> >> If this is the wrong place for these kinds of questions, please point me in the right direction. >> >> Thanks, >> >> Scott From jiefu at openjdk.java.net Mon Sep 6 02:49:33 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Mon, 6 Sep 2021 02:49:33 GMT Subject: [vectorIntrinsics+mask] RFR: 8272479: Fix a regression of rearrange intrinsic after JDK-8272479 Message-ID: Hi all, After JDK-8272479, the following crash was observed on x86 with `-ea -esa -Xcomp -XX:CompileThreshold=100` test Double256VectorTests.RearrangeDouble256VectorTests(double[-i * 5], shuffle[random]): success test Double256VectorTests.RearrangeDouble256VectorTests(double[i * 5], shuffle[random]): success test Double256VectorTests.RearrangeDouble256VectorTests(double[i + 1], shuffle[random]): success test Double256VectorTests.RearrangeDouble256VectorTests(double[cornerCaseValue(i)], shuffle[random]): success o114 ReplicateD === _ o73 [[o340 ]] #vectory[4]:{double} --N: o114 ReplicateD === _ o73 [[o340 ]] #vectory[4]:{double} --N: o73 ConI === o0 [[o166 o173 o114 ]] #int:0 IMMI 10 IMMI IMMI_0 0 IMMI_0 IMMI2 0 IMMI2 IMMU7 5 IMMU7 IMMI8 5 IMMI8 IMMU8 5 IMMU8 IMMI16 10 IMMI16 IMMU31 0 IMMU31 RREGI 50 loadConI0 RAX_REGI 50 loadConI0 RBX_REGI 50 loadConI0 RCX_REGI 50 loadConI0 RDX_REGI 50 loadConI0 RDI_REGI 50 loadConI0 NO_RAX_RDX_REGI 50 loadConI0 STACKSLOTI 150 storeSSI This is because the type of broadcasted ZERO is incorrect. Other affected tests include jdk/incubator/vector/DoubleMaxVectorTests.java jdk/incubator/vector/Float128VectorTests.java jdk/incubator/vector/Float256VectorTests.java jdk/incubator/vector/FloatMaxVectorTests.java jdk/incubator/vector/Long256VectorTests.java jdk/incubator/vector/LongMaxVectorTests.java Let's fix it. Thanks. Best regards, Jie ------------- Commit messages: - 8272479: Fix a regression of rearrange intrinsic after JDK-8272479 Changes: https://git.openjdk.java.net/panama-vector/pull/120/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=120&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272479 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/panama-vector/pull/120.diff Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/120/head:pull/120 PR: https://git.openjdk.java.net/panama-vector/pull/120 From jiefu at openjdk.java.net Mon Sep 6 03:36:03 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Mon, 6 Sep 2021 03:36:03 GMT Subject: [vectorIntrinsics+mask] RFR: 8273205: [vector] Crash in C2_MacroAssembler::vprotate_var after JDK-8271366 [v2] In-Reply-To: References: <2PM0lqpC20oqtHrIow2TDNb2zcauuGTRrlMtfoQF_h4=.001b5773-0928-403e-9e96-d995a2fa90b8@github.com> Message-ID: On Sun, 5 Sep 2021 14:27:37 GMT, Jie Fu wrote: > The reason for the crash is that rotate operation fails to degenerate_vector_rotate when `use_predicate=false` on unsupported platforms. > To call `VectorNode::degenerate_vector_rotate`, `gvn().transform(operation)` should be added. > > More testing is in progress. Catch and fix another regression caused by JDK-8272479: https://github.com/openjdk/panama-vector/pull/120. Now jdk/incubator/vector all passed with `-ea -esa -ea -esa -Xcomp -XX:CompileThreshold=100` on my machine. Thanks. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/119 From sundararajan.athijegannathan at oracle.com Mon Sep 6 04:50:05 2021 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 6 Sep 2021 04:50:05 +0000 Subject: How To Create Array of Structs? In-Reply-To: <3b5cdab7-e807-a728-7476-6d6d349c9fe2@oracle.com> References: <0c6361f3-2879-02dd-0b26-e26a5b268602@oracle.com> <4bb60084-2958-45f9-511d-638b85770040@oracle.com> <3b5cdab7-e807-a728-7476-6d6d349c9fe2@oracle.com> Message-ID: Hi, jextract does not seem to generate layout for any pointer type. Only non-point typedefs are handled. Example: typedef int* intptr; struct Point { int x, y; }; typedef struct Point* pointptr; Nothing generated for both intptr and pointptr; -Sundar ________________________________ From: panama-dev on behalf of Maurizio Cimadamore Sent: 04 September 2021 03:42 To: Michael Ennen ; Jorn Vernee Cc: panama-dev at openjdk.java.net Subject: Re: How To Create Array of Structs? Hi Michael, I don't think the problem is lack of support for function-like macro. Yes, VK_DEFINE_NON_DISPATCHABLE_HANDLE is a function-like macro, but this declaration: ``` VK_DEFINE_NON_DISPATCHABLE_HANDLE(VkSemaphore) ``` is contained in the header, and preprocessed, so libclang sees something like what you describe: ``` typedef struct VkSemaphore_T *VkSemaphore; ``` The only problem is that jextract is (because of an issue we're investigating) not generating the layout for that typedef. That said, layout or no layout, things are not too different - for all intents and purposes, you can assume that the layout of the handle is just C_POINTER. But you are never supposed to _dereference_ that handle - instead you are supposed to use other functions to create and use semaphores, such as: https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/vkSignalSemaphore.html https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/vkWaitSemaphores.html https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/vkCreateSemaphore.html https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/vkDestroySemaphore.html etc. In other words, inside the handle there's an opaque pointer to memory that is managed by the vulkan library. You are not supposed to know what's inside that memory. Nor you need to know what the size of VkSemaphore_T is. So, if you want to create an array of N semaphores, you just do this ``` MemorySegment semaphores = allocator.allocateArray(C_POINTER, N); ``` Then you will probably have to initialize the pointers in the array, possibly using vkCreateSemaphore. As Radu pointed out, the vkCreateSemaphore API wants you to pass a pointer to a VkSemaphore (which is already a pointer). So, something like this: ``` for (int i = 0 ; i < N ; i++) { vkCreateSemaphore( ... , semaphores.asSlice(C_POINTER.byteSize() * i) , ...); } ``` This effectively iterates over the semaphore array, gets a slice of the "semaphores" array which starts at the element which needs to be initialized (hence you get a pointer to a VkSemaphore - e.g. a pointer to a pointer), and passes this slice pointer to the vkCreateSemaphore routine. By the time the routine finishes, it should have written something in the array element (the opaque handle). Hope this helps. Maurizio On 03/09/2021 22:50, Michael Ennen wrote: > Let me try and expand upon what I was attempting to communicate yesterday: > > I know that jextract does not currently support function-like macros > so the handles like VkSemaphore are not exposed. > > That's why I tried to first declare it (the array of VkSemaphores) as > a pointer to a pointer. > > But then I cannot get the size of VkSemaphore (really VkSemaphore_T) > so I am unsure how to use the technique you described which does work > in the case > of the VkPipelineShaderStageCreateInfo struct - because it is not an > "opaque" handle. Vulkan uses these a lot, things like VkInstance, > VkDevice, etc. Specifically: > > VkSemaphore is defined by this macro: > > VK_DEFINE_NON_DISPATCHABLE_HANDLE(VkSemaphore) > > Which is how Vulkan does opaque handles (so one cannot inspect the > contents of the VkSemaphore struct and/or rely on it). > > If jextract did support function-like macros then it would expand to > the typedef: > > typedef struct VkSemaphore_T *VkSemaphore; > > and then one could possibly just do VkSemaphore.$LAYOUT() ? Or even > still that may not work because of the "opaque"ness. > > Thanks for any assistance. > > On Thu, Sep 2, 2021 at 11:16 AM Michael Ennen > wrote: > > Quick question that is now happening while trying to replicate the > fix when I don't have an explicit struct handle like in the case > of VkSemaphore: > > https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VkSemaphore.html > > > For those types I don't have a struct layout to work with so I > have been just declaring a double pointer: > > var pVkPipeline = > SegmentAllocator.ofScope(scope).allocate(C_POINTER.byteSize()); > > and then using MemoryAccess.getAddress(pVkPipeline). > > So in this case how can I create an array of VkSemaphore structs > without knowing anything about the struct (it is an opaque handle?). > > Hope that makes sense. > > On Thu, Sep 2, 2021 at 11:06 AM Michael Ennen > > wrote: > > Jorn, > > Thank you so much - that was exactly what I was looking for. I > don't know why I had such trouble trying to create an array of > structs rather than an array of points to structs. > > Thank you both. > > On Thu, Sep 2, 2021 at 4:54 AM Jorn Vernee > > wrote: > > Additionally, it looks like you're allocating an array of > pointers for > pStages, and it looks like the API expects an array of > structs. > > Instead of allocating the different > VkPipelineShaderStageCreateInfo > individually, you should allocate the array of struct > upfront, and then > fill in the different structs in-place. > > Like: > > diff --git a/src/main/java/com/brcolow/game/Vulkan.java > b/src/main/java/com/brcolow/game/Vulkan.java > index f0cd278..520513b 100644 > --- a/src/main/java/com/brcolow/game/Vulkan.java > +++ b/src/main/java/com/brcolow/game/Vulkan.java > @@ -429,17 +429,17 @@ public class Vulkan { > var pVertShaderModule = > getShaderModule(MemoryAccess.getAddress(pVkDevice), > vertShaderBytes, scope); > var pFragShaderModule = > getShaderModule(MemoryAccess.getAddress(pVkDevice), > fragShaderBytes, scope); > > - var pVertShaderStageInfo = > VkPipelineShaderStageCreateInfo.allocate(scope); > - > VkPipelineShaderStageCreateInfo.sType$set(pVertShaderStageInfo, > > vulkan_h.VK_STRUCTURE_TYPE_PIPELINE_SHADER_STAGE_CREATE_INFO()); > - > VkPipelineShaderStageCreateInfo.stage$set(pVertShaderStageInfo, > > vulkan_h.VK_SHADER_STAGE_VERTEX_BIT()); > - > VkPipelineShaderStageCreateInfo.module$set(pVertShaderStageInfo, > > MemoryAccess.getAddress(pVertShaderModule)); > - > VkPipelineShaderStageCreateInfo.pName$set(pVertShaderStageInfo, > > CLinker.toCString("main", scope).address()); > - > - var pFragShaderStageInfo = > VkPipelineShaderStageCreateInfo.allocate(scope); > - > VkPipelineShaderStageCreateInfo.sType$set(pFragShaderStageInfo, > > vulkan_h.VK_STRUCTURE_TYPE_PIPELINE_SHADER_STAGE_CREATE_INFO()); > - > VkPipelineShaderStageCreateInfo.stage$set(pFragShaderStageInfo, > > vulkan_h.VK_SHADER_STAGE_FRAGMENT_BIT()); > - > VkPipelineShaderStageCreateInfo.module$set(pFragShaderStageInfo, > > MemoryAccess.getAddress(pFragShaderModule)); > - > VkPipelineShaderStageCreateInfo.pName$set(pFragShaderStageInfo, > > CLinker.toCString("main", scope).address()); > + MemorySegment pStages = > SegmentAllocator.ofScope(scope).allocateArray(VkPipelineShaderStageCreateInfo.$LAYOUT(), > > 2); > + > + VkPipelineShaderStageCreateInfo.sType$set(pStages, 0, > vulkan_h.VK_STRUCTURE_TYPE_PIPELINE_SHADER_STAGE_CREATE_INFO()); > + VkPipelineShaderStageCreateInfo.stage$set(pStages, 0, > vulkan_h.VK_SHADER_STAGE_VERTEX_BIT()); > + VkPipelineShaderStageCreateInfo.module$set(pStages, 0, > MemoryAccess.getAddress(pVertShaderModule)); > + VkPipelineShaderStageCreateInfo.pName$set(pStages, 0, > CLinker.toCString("main", scope).address()); > + > + VkPipelineShaderStageCreateInfo.sType$set(pStages, 1, > vulkan_h.VK_STRUCTURE_TYPE_PIPELINE_SHADER_STAGE_CREATE_INFO()); > + VkPipelineShaderStageCreateInfo.stage$set(pStages, 1, > vulkan_h.VK_SHADER_STAGE_FRAGMENT_BIT()); > + VkPipelineShaderStageCreateInfo.module$set(pStages, 1, > MemoryAccess.getAddress(pFragShaderModule)); > + VkPipelineShaderStageCreateInfo.pName$set(pStages, 1, > CLinker.toCString("main", scope).address()); > > var pVertexInputStateInfo = > VkPipelineVertexInputStateCreateInfo.allocate(scope); > VkPipelineVertexInputStateCreateInfo.sType$set(pVertexInputStateInfo, > > vulkan_h.VK_STRUCTURE_TYPE_PIPELINE_VERTEX_INPUT_STATE_CREATE_INFO()); > @@ -581,16 +581,14 @@ public class Vulkan { > // If we change stageCount to 2 we get a > crash.... > // I think we are creating the pStages array > incorrectly. > This is also manifesting further down when trying > // to create arrays pWaitSemaphores, > pSignalSemaphores, etc. > - > VkGraphicsPipelineCreateInfo.stageCount$set(pPipelineCreateInfo, > 1); > - MemorySegment pStages = > SegmentAllocator.ofScope(scope).allocateArray(C_POINTER, > new Addressable[]{ > - pVertShaderStageInfo, > pFragShaderStageInfo}); > - System.out.println("pStages: " + pStages); > - System.out.println("pStages[0]: " + > VkPipelineShaderStageCreateInfo.ofAddress(MemoryAccess.getAddressAtIndex(pStages, > > 0), scope)); > - System.out.println("pStages[0].sType: " + > VkPipelineShaderStageCreateInfo.sType$get(VkPipelineShaderStageCreateInfo.ofAddress(MemoryAccess.getAddressAtIndex(pStages, > > 0), scope))); > - System.out.println("pStages[1]: " + > VkPipelineShaderStageCreateInfo.ofAddress(MemoryAccess.getAddressAtIndex(pStages, > > 1), scope)); > - System.out.println("pStages[1].sType: " + > VkPipelineShaderStageCreateInfo.sType$get(VkPipelineShaderStageCreateInfo.ofAddress(MemoryAccess.getAddressAtIndex(pStages, > > 1), scope))); > - > - > VkGraphicsPipelineCreateInfo.pStages$set(pPipelineCreateInfo, > MemoryAccess.getAddress(pStages)); > + > VkGraphicsPipelineCreateInfo.stageCount$set(pPipelineCreateInfo, > 2); > + System.out.println("pStages: " + > pStages.address()); > + System.out.println("pStages[0]: " + > pStages.asSlice(0, > VkPipelineShaderStageCreateInfo.$LAYOUT().byteSize())); > + System.out.println("pStages[0].sType: " + > VkPipelineShaderStageCreateInfo.sType$get(pStages, 0)); > + System.out.println("pStages[1]: " + > pStages.asSlice(VkPipelineShaderStageCreateInfo.$LAYOUT().byteSize(), > > VkPipelineShaderStageCreateInfo.$LAYOUT().byteSize())); > + System.out.println("pStages[1].sType: " + > VkPipelineShaderStageCreateInfo.sType$get(pStages, 1)); > + > + > VkGraphicsPipelineCreateInfo.pStages$set(pPipelineCreateInfo, > pStages.address()); > VkGraphicsPipelineCreateInfo.pVertexInputState$set(pPipelineCreateInfo, > > pVertexInputStateInfo.address()); > VkGraphicsPipelineCreateInfo.pInputAssemblyState$set(pPipelineCreateInfo, > > pPipelineInputAssemblyStateInfo.address()); > VkGraphicsPipelineCreateInfo.pViewportState$set(pPipelineCreateInfo, > > pPipelineViewportStateInfo.address()); > > HTH, > Jorn > > On 02/09/2021 11:56, Maurizio Cimadamore wrote: > > Hi Michael, > > very interesting experiments - thanks for reaching out. > > > > Eyeballing your code, I zoomed into this line: > > > > > https://github.com/brcolow/java-vulkan/blob/master/src/main/java/com/brcolow/game/Vulkan.java#L593 > > > > > > > > Here you want to set the `pStages` pointer, a pointer to > a memory > > region which presumably has to contain exactly > `stageCount` structs of > > type `VkPipelineShaderStageCreateInfo`. > > > > I believe there's an extra getAddress in there; this: > > > > ``` > > > VkGraphicsPipelineCreateInfo.pStages$set(pPipelineCreateInfo, > > MemoryAccess.getAddress(pStages)); > > ``` > > > > should be: > > > > ``` > > > VkGraphicsPipelineCreateInfo.pStages$set(pPipelineCreateInfo, > pStages); > > ``` > > > > That is, you want to pass the pointer to the `pStages` > region you just > > created, so that Vulkan will be able to see all > elements. If you call > > "MemoryAccess::getAddress" your code will read the first > 64 bits from > > the `pStages` region, turn those into a MemoryAddress, > and set that > > into the enclosing `pPipelineCreateInfo` struct. Which I > don't think > > is what you want? > > > > Let me know if this works. > > > > Cheers > > Maurizio > > > > > > On 02/09/2021 06:35, Michael Ennen wrote: > >> I have been doing more exploring with the > panama-foreign, ffi, and > >> jextract > >> branches - this time messing around with seeing if I > can get a rainbow > >> triangle to be rendered on the screen with Vulkan. > >> > >> I am really close. There is one problem I am having > which is how to > >> create > >> an array of structs? > >> > >> See this, for example: > >> > >> > https://github.com/brcolow/java-vulkan/blob/master/src/main/java/com/brcolow/game/Vulkan.java#L581 > > > >> > >> > >> If I set the stageCount to 2, then I get a validation > exception about > >> the > >> second shader module having bogus values. I believe > this is caused by me > >> creating the array of structs incorrectly. > >> > >> I am trying to set the pStages element of this struct: > >> > https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VkGraphicsPipelineCreateInfo.html > > > >> > >> > >> to an array containing pVertShaderStageInfo and > pFragShaderStageInfo. > >> > >> My attempt (I have tried other ways that also fail) to > do that is: > >> > >> MemorySegment pStages = > SegmentAllocator.ofScope(scope).allocateArray( > >> C_POINTER, new Addressable[]{ > >> pVertShaderStageInfo, pFragShaderStageInfo}); > >> > VkGraphicsPipelineCreateInfo.pStages$set(pPipelineCreateInfo, > >> MemoryAccess.getAddress(pStages)); > >> > >> > >> If anyone could assist me with the proper way to create the > >> VkPipelineShaderStageCreateInfo* array containing > >> pVertShaderStageInfoand > >> pFragShaderStageInfo - it would be greatly appreciated! > >> > > > > -- > Michael Ennen > > > > -- > Michael Ennen > > > > -- > Michael Ennen From jzhu at openjdk.java.net Mon Sep 6 07:18:57 2021 From: jzhu at openjdk.java.net (Joshua Zhu) Date: Mon, 6 Sep 2021 07:18:57 GMT Subject: [vectorIntrinsics+mask] RFR: 8273057: [vector] New VectorAPI "SelectiveStore" In-Reply-To: <61F91394-25CE-4D37-AB02-3B2093C1629D@oracle.com> References: <61F91394-25CE-4D37-AB02-3B2093C1629D@oracle.com> Message-ID: On Fri, 3 Sep 2021 20:13:46 GMT, Paul Sandoz wrote: > In summary, from the discussion, compress/expand are: > > - important conceptually, even if the same functionality could be composed from shuffles (such as used by an implementation); and > > - at the right level to reliably optimize on supporting hardware. > > So specification-wise we introduce expanding/compressing cross-lane operations. API-wise I prefer two distinct methods rather that one that accepts boolean indicating expansion or compression. We can declare one intrinsic method in VectorSupport. Thanks Paul for bringing the deep design thinking. John Rose's encompassing knowledge impresses me a lot. Also thank Sandhya and Ningsheng for comments. I will refactor my codes and implement these two cross-lane data movement primitives: mask-based compression & expansion. They will work on general vectors and be declared: $abstractvectortype$ compress(VectorMask<$Boxtype$> m); $abstractvectortype$ expand(VectorMask<$Boxtype$> m); These two vector-to-vector operations together with a store/load and prefix mask could be optimized further into single memory version instruction on supported architecture. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/115 From jiefu at openjdk.java.net Mon Sep 6 08:34:15 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Mon, 6 Sep 2021 08:34:15 GMT Subject: [vectorIntrinsics+mask] RFR: 8273371: [Vector API] Crash in Assembler::evpermd when code-gen for masked rearrange operation on AVX512 Message-ID: Hi all, I'd like to fix the crash in Assembler::evpermd when code-gen for masked int/float rearrange operation on AVX512. This is because evpermd can be only used for vector-size-in-bits > 128 [1]. The fix is disabling the code-gen for int/float if vector-size-in-bits < 256. Thanks. Best regards, Jie [1] https://www.felixcloutier.com/x86/vpermd:vpermw ------------- Commit messages: - 8273371: [Vector API] Crash in Assembler::evpermd when code-gen for masked rearrange operation on AVX512 Changes: https://git.openjdk.java.net/panama-vector/pull/121/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=121&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273371 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/panama-vector/pull/121.diff Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/121/head:pull/121 PR: https://git.openjdk.java.net/panama-vector/pull/121 From sundararajan.athijegannathan at oracle.com Mon Sep 6 12:03:55 2021 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 6 Sep 2021 12:03:55 +0000 Subject: How To Create Array of Structs? In-Reply-To: References: <0c6361f3-2879-02dd-0b26-e26a5b268602@oracle.com> <4bb60084-2958-45f9-511d-638b85770040@oracle.com> <3b5cdab7-e807-a728-7476-6d6d349c9fe2@oracle.com> Message-ID: Filed: https://bugs.openjdk.java.net/browse/JDK-8273382 -Sundar ________________________________ From: panama-dev on behalf of Sundararajan Athijegannathan Sent: 06 September 2021 10:20 To: Maurizio Cimadamore ; Michael Ennen ; Jorn Vernee Cc: panama-dev at openjdk.java.net Subject: Re: How To Create Array of Structs? Hi, jextract does not seem to generate layout for any pointer type. Only non-point typedefs are handled. Example: typedef int* intptr; struct Point { int x, y; }; typedef struct Point* pointptr; Nothing generated for both intptr and pointptr; -Sundar ________________________________ From: panama-dev on behalf of Maurizio Cimadamore Sent: 04 September 2021 03:42 To: Michael Ennen ; Jorn Vernee Cc: panama-dev at openjdk.java.net Subject: Re: How To Create Array of Structs? Hi Michael, I don't think the problem is lack of support for function-like macro. Yes, VK_DEFINE_NON_DISPATCHABLE_HANDLE is a function-like macro, but this declaration: ``` VK_DEFINE_NON_DISPATCHABLE_HANDLE(VkSemaphore) ``` is contained in the header, and preprocessed, so libclang sees something like what you describe: ``` typedef struct VkSemaphore_T *VkSemaphore; ``` The only problem is that jextract is (because of an issue we're investigating) not generating the layout for that typedef. That said, layout or no layout, things are not too different - for all intents and purposes, you can assume that the layout of the handle is just C_POINTER. But you are never supposed to _dereference_ that handle - instead you are supposed to use other functions to create and use semaphores, such as: https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/vkSignalSemaphore.html https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/vkWaitSemaphores.html https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/vkCreateSemaphore.html https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/vkDestroySemaphore.html etc. In other words, inside the handle there's an opaque pointer to memory that is managed by the vulkan library. You are not supposed to know what's inside that memory. Nor you need to know what the size of VkSemaphore_T is. So, if you want to create an array of N semaphores, you just do this ``` MemorySegment semaphores = allocator.allocateArray(C_POINTER, N); ``` Then you will probably have to initialize the pointers in the array, possibly using vkCreateSemaphore. As Radu pointed out, the vkCreateSemaphore API wants you to pass a pointer to a VkSemaphore (which is already a pointer). So, something like this: ``` for (int i = 0 ; i < N ; i++) { vkCreateSemaphore( ... , semaphores.asSlice(C_POINTER.byteSize() * i) , ...); } ``` This effectively iterates over the semaphore array, gets a slice of the "semaphores" array which starts at the element which needs to be initialized (hence you get a pointer to a VkSemaphore - e.g. a pointer to a pointer), and passes this slice pointer to the vkCreateSemaphore routine. By the time the routine finishes, it should have written something in the array element (the opaque handle). Hope this helps. Maurizio On 03/09/2021 22:50, Michael Ennen wrote: > Let me try and expand upon what I was attempting to communicate yesterday: > > I know that jextract does not currently support function-like macros > so the handles like VkSemaphore are not exposed. > > That's why I tried to first declare it (the array of VkSemaphores) as > a pointer to a pointer. > > But then I cannot get the size of VkSemaphore (really VkSemaphore_T) > so I am unsure how to use the technique you described which does work > in the case > of the VkPipelineShaderStageCreateInfo struct - because it is not an > "opaque" handle. Vulkan uses these a lot, things like VkInstance, > VkDevice, etc. Specifically: > > VkSemaphore is defined by this macro: > > VK_DEFINE_NON_DISPATCHABLE_HANDLE(VkSemaphore) > > Which is how Vulkan does opaque handles (so one cannot inspect the > contents of the VkSemaphore struct and/or rely on it). > > If jextract did support function-like macros then it would expand to > the typedef: > > typedef struct VkSemaphore_T *VkSemaphore; > > and then one could possibly just do VkSemaphore.$LAYOUT() ? Or even > still that may not work because of the "opaque"ness. > > Thanks for any assistance. > > On Thu, Sep 2, 2021 at 11:16 AM Michael Ennen > wrote: > > Quick question that is now happening while trying to replicate the > fix when I don't have an explicit struct handle like in the case > of VkSemaphore: > > https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VkSemaphore.html > > > For those types I don't have a struct layout to work with so I > have been just declaring a double pointer: > > var pVkPipeline = > SegmentAllocator.ofScope(scope).allocate(C_POINTER.byteSize()); > > and then using MemoryAccess.getAddress(pVkPipeline). > > So in this case how can I create an array of VkSemaphore structs > without knowing anything about the struct (it is an opaque handle?). > > Hope that makes sense. > > On Thu, Sep 2, 2021 at 11:06 AM Michael Ennen > > wrote: > > Jorn, > > Thank you so much - that was exactly what I was looking for. I > don't know why I had such trouble trying to create an array of > structs rather than an array of points to structs. > > Thank you both. > > On Thu, Sep 2, 2021 at 4:54 AM Jorn Vernee > > wrote: > > Additionally, it looks like you're allocating an array of > pointers for > pStages, and it looks like the API expects an array of > structs. > > Instead of allocating the different > VkPipelineShaderStageCreateInfo > individually, you should allocate the array of struct > upfront, and then > fill in the different structs in-place. > > Like: > > diff --git a/src/main/java/com/brcolow/game/Vulkan.java > b/src/main/java/com/brcolow/game/Vulkan.java > index f0cd278..520513b 100644 > --- a/src/main/java/com/brcolow/game/Vulkan.java > +++ b/src/main/java/com/brcolow/game/Vulkan.java > @@ -429,17 +429,17 @@ public class Vulkan { > var pVertShaderModule = > getShaderModule(MemoryAccess.getAddress(pVkDevice), > vertShaderBytes, scope); > var pFragShaderModule = > getShaderModule(MemoryAccess.getAddress(pVkDevice), > fragShaderBytes, scope); > > - var pVertShaderStageInfo = > VkPipelineShaderStageCreateInfo.allocate(scope); > - > VkPipelineShaderStageCreateInfo.sType$set(pVertShaderStageInfo, > > vulkan_h.VK_STRUCTURE_TYPE_PIPELINE_SHADER_STAGE_CREATE_INFO()); > - > VkPipelineShaderStageCreateInfo.stage$set(pVertShaderStageInfo, > > vulkan_h.VK_SHADER_STAGE_VERTEX_BIT()); > - > VkPipelineShaderStageCreateInfo.module$set(pVertShaderStageInfo, > > MemoryAccess.getAddress(pVertShaderModule)); > - > VkPipelineShaderStageCreateInfo.pName$set(pVertShaderStageInfo, > > CLinker.toCString("main", scope).address()); > - > - var pFragShaderStageInfo = > VkPipelineShaderStageCreateInfo.allocate(scope); > - > VkPipelineShaderStageCreateInfo.sType$set(pFragShaderStageInfo, > > vulkan_h.VK_STRUCTURE_TYPE_PIPELINE_SHADER_STAGE_CREATE_INFO()); > - > VkPipelineShaderStageCreateInfo.stage$set(pFragShaderStageInfo, > > vulkan_h.VK_SHADER_STAGE_FRAGMENT_BIT()); > - > VkPipelineShaderStageCreateInfo.module$set(pFragShaderStageInfo, > > MemoryAccess.getAddress(pFragShaderModule)); > - > VkPipelineShaderStageCreateInfo.pName$set(pFragShaderStageInfo, > > CLinker.toCString("main", scope).address()); > + MemorySegment pStages = > SegmentAllocator.ofScope(scope).allocateArray(VkPipelineShaderStageCreateInfo.$LAYOUT(), > > 2); > + > + VkPipelineShaderStageCreateInfo.sType$set(pStages, 0, > vulkan_h.VK_STRUCTURE_TYPE_PIPELINE_SHADER_STAGE_CREATE_INFO()); > + VkPipelineShaderStageCreateInfo.stage$set(pStages, 0, > vulkan_h.VK_SHADER_STAGE_VERTEX_BIT()); > + VkPipelineShaderStageCreateInfo.module$set(pStages, 0, > MemoryAccess.getAddress(pVertShaderModule)); > + VkPipelineShaderStageCreateInfo.pName$set(pStages, 0, > CLinker.toCString("main", scope).address()); > + > + VkPipelineShaderStageCreateInfo.sType$set(pStages, 1, > vulkan_h.VK_STRUCTURE_TYPE_PIPELINE_SHADER_STAGE_CREATE_INFO()); > + VkPipelineShaderStageCreateInfo.stage$set(pStages, 1, > vulkan_h.VK_SHADER_STAGE_FRAGMENT_BIT()); > + VkPipelineShaderStageCreateInfo.module$set(pStages, 1, > MemoryAccess.getAddress(pFragShaderModule)); > + VkPipelineShaderStageCreateInfo.pName$set(pStages, 1, > CLinker.toCString("main", scope).address()); > > var pVertexInputStateInfo = > VkPipelineVertexInputStateCreateInfo.allocate(scope); > VkPipelineVertexInputStateCreateInfo.sType$set(pVertexInputStateInfo, > > vulkan_h.VK_STRUCTURE_TYPE_PIPELINE_VERTEX_INPUT_STATE_CREATE_INFO()); > @@ -581,16 +581,14 @@ public class Vulkan { > // If we change stageCount to 2 we get a > crash.... > // I think we are creating the pStages array > incorrectly. > This is also manifesting further down when trying > // to create arrays pWaitSemaphores, > pSignalSemaphores, etc. > - > VkGraphicsPipelineCreateInfo.stageCount$set(pPipelineCreateInfo, > 1); > - MemorySegment pStages = > SegmentAllocator.ofScope(scope).allocateArray(C_POINTER, > new Addressable[]{ > - pVertShaderStageInfo, > pFragShaderStageInfo}); > - System.out.println("pStages: " + pStages); > - System.out.println("pStages[0]: " + > VkPipelineShaderStageCreateInfo.ofAddress(MemoryAccess.getAddressAtIndex(pStages, > > 0), scope)); > - System.out.println("pStages[0].sType: " + > VkPipelineShaderStageCreateInfo.sType$get(VkPipelineShaderStageCreateInfo.ofAddress(MemoryAccess.getAddressAtIndex(pStages, > > 0), scope))); > - System.out.println("pStages[1]: " + > VkPipelineShaderStageCreateInfo.ofAddress(MemoryAccess.getAddressAtIndex(pStages, > > 1), scope)); > - System.out.println("pStages[1].sType: " + > VkPipelineShaderStageCreateInfo.sType$get(VkPipelineShaderStageCreateInfo.ofAddress(MemoryAccess.getAddressAtIndex(pStages, > > 1), scope))); > - > - > VkGraphicsPipelineCreateInfo.pStages$set(pPipelineCreateInfo, > MemoryAccess.getAddress(pStages)); > + > VkGraphicsPipelineCreateInfo.stageCount$set(pPipelineCreateInfo, > 2); > + System.out.println("pStages: " + > pStages.address()); > + System.out.println("pStages[0]: " + > pStages.asSlice(0, > VkPipelineShaderStageCreateInfo.$LAYOUT().byteSize())); > + System.out.println("pStages[0].sType: " + > VkPipelineShaderStageCreateInfo.sType$get(pStages, 0)); > + System.out.println("pStages[1]: " + > pStages.asSlice(VkPipelineShaderStageCreateInfo.$LAYOUT().byteSize(), > > VkPipelineShaderStageCreateInfo.$LAYOUT().byteSize())); > + System.out.println("pStages[1].sType: " + > VkPipelineShaderStageCreateInfo.sType$get(pStages, 1)); > + > + > VkGraphicsPipelineCreateInfo.pStages$set(pPipelineCreateInfo, > pStages.address()); > VkGraphicsPipelineCreateInfo.pVertexInputState$set(pPipelineCreateInfo, > > pVertexInputStateInfo.address()); > VkGraphicsPipelineCreateInfo.pInputAssemblyState$set(pPipelineCreateInfo, > > pPipelineInputAssemblyStateInfo.address()); > VkGraphicsPipelineCreateInfo.pViewportState$set(pPipelineCreateInfo, > > pPipelineViewportStateInfo.address()); > > HTH, > Jorn > > On 02/09/2021 11:56, Maurizio Cimadamore wrote: > > Hi Michael, > > very interesting experiments - thanks for reaching out. > > > > Eyeballing your code, I zoomed into this line: > > > > > https://github.com/brcolow/java-vulkan/blob/master/src/main/java/com/brcolow/game/Vulkan.java#L593 > > > > > > > > Here you want to set the `pStages` pointer, a pointer to > a memory > > region which presumably has to contain exactly > `stageCount` structs of > > type `VkPipelineShaderStageCreateInfo`. > > > > I believe there's an extra getAddress in there; this: > > > > ``` > > > VkGraphicsPipelineCreateInfo.pStages$set(pPipelineCreateInfo, > > MemoryAccess.getAddress(pStages)); > > ``` > > > > should be: > > > > ``` > > > VkGraphicsPipelineCreateInfo.pStages$set(pPipelineCreateInfo, > pStages); > > ``` > > > > That is, you want to pass the pointer to the `pStages` > region you just > > created, so that Vulkan will be able to see all > elements. If you call > > "MemoryAccess::getAddress" your code will read the first > 64 bits from > > the `pStages` region, turn those into a MemoryAddress, > and set that > > into the enclosing `pPipelineCreateInfo` struct. Which I > don't think > > is what you want? > > > > Let me know if this works. > > > > Cheers > > Maurizio > > > > > > On 02/09/2021 06:35, Michael Ennen wrote: > >> I have been doing more exploring with the > panama-foreign, ffi, and > >> jextract > >> branches - this time messing around with seeing if I > can get a rainbow > >> triangle to be rendered on the screen with Vulkan. > >> > >> I am really close. There is one problem I am having > which is how to > >> create > >> an array of structs? > >> > >> See this, for example: > >> > >> > https://github.com/brcolow/java-vulkan/blob/master/src/main/java/com/brcolow/game/Vulkan.java#L581 > > > >> > >> > >> If I set the stageCount to 2, then I get a validation > exception about > >> the > >> second shader module having bogus values. I believe > this is caused by me > >> creating the array of structs incorrectly. > >> > >> I am trying to set the pStages element of this struct: > >> > https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VkGraphicsPipelineCreateInfo.html > > > >> > >> > >> to an array containing pVertShaderStageInfo and > pFragShaderStageInfo. > >> > >> My attempt (I have tried other ways that also fail) to > do that is: > >> > >> MemorySegment pStages = > SegmentAllocator.ofScope(scope).allocateArray( > >> C_POINTER, new Addressable[]{ > >> pVertShaderStageInfo, pFragShaderStageInfo}); > >> > VkGraphicsPipelineCreateInfo.pStages$set(pPipelineCreateInfo, > >> MemoryAccess.getAddress(pStages)); > >> > >> > >> If anyone could assist me with the proper way to create the > >> VkPipelineShaderStageCreateInfo* array containing > >> pVertShaderStageInfoand > >> pFragShaderStageInfo - it would be greatly appreciated! > >> > > > > -- > Michael Ennen > > > > -- > Michael Ennen > > > > -- > Michael Ennen From jbhateja at openjdk.java.net Tue Sep 7 04:25:54 2021 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Tue, 7 Sep 2021 04:25:54 GMT Subject: [vectorIntrinsics+mask] RFR: 8273205: [Vector API] Crash in C2_MacroAssembler::vprotate_var after JDK-8271366 [v2] In-Reply-To: References: <2PM0lqpC20oqtHrIow2TDNb2zcauuGTRrlMtfoQF_h4=.001b5773-0928-403e-9e96-d995a2fa90b8@github.com> Message-ID: <0NxUO2Rhc5n4HDj0-ngDnKaKa0Nz8tInjan9UNmcANQ=.da135a42-d7a5-471f-b488-0c9b0591f14a@github.com> On Sun, 5 Sep 2021 14:17:17 GMT, Jie Fu wrote: >> Hi all, >> >> After JDK-8271366, `arch_supports_vector()` fails to check whether the rotate operation is directly supported by the target ISA. >> >> So `Matcher::match_rule_supported_vector` should be added in `inline_vector_broadcast_int()` and `inline_vector_nary_operation()` to prevent generation of unsupported rotate operation IR patterns. >> >> Thanks. >> Best regards, >> Jie > > Jie Fu has updated the pull request incrementally with one additional commit since the last revision: > > Add gvn().transform for rotate operation Marked as reviewed by jbhateja (Committer). LGTM ------------- PR: https://git.openjdk.java.net/panama-vector/pull/119 From jiefu at openjdk.java.net Tue Sep 7 04:28:51 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Tue, 7 Sep 2021 04:28:51 GMT Subject: [vectorIntrinsics+mask] Integrated: 8273205: [Vector API] Crash in C2_MacroAssembler::vprotate_var after JDK-8271366 In-Reply-To: <2PM0lqpC20oqtHrIow2TDNb2zcauuGTRrlMtfoQF_h4=.001b5773-0928-403e-9e96-d995a2fa90b8@github.com> References: <2PM0lqpC20oqtHrIow2TDNb2zcauuGTRrlMtfoQF_h4=.001b5773-0928-403e-9e96-d995a2fa90b8@github.com> Message-ID: On Fri, 3 Sep 2021 14:01:25 GMT, Jie Fu wrote: > Hi all, > > After JDK-8271366, `arch_supports_vector()` fails to check whether the rotate operation is directly supported by the target ISA. > > So `Matcher::match_rule_supported_vector` should be added in `inline_vector_broadcast_int()` and `inline_vector_nary_operation()` to prevent generation of unsupported rotate operation IR patterns. > > Thanks. > Best regards, > Jie This pull request has now been integrated. Changeset: 31e21b60 Author: Jie Fu Committer: Jatin Bhateja URL: https://git.openjdk.java.net/panama-vector/commit/31e21b60c08e30f54d7c0d7ee7369f3a28dd6eae Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod 8273205: [Vector API] Crash in C2_MacroAssembler::vprotate_var after JDK-8271366 Reviewed-by: njian, jbhateja ------------- PR: https://git.openjdk.java.net/panama-vector/pull/119 From jbhateja at openjdk.java.net Tue Sep 7 04:55:01 2021 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Tue, 7 Sep 2021 04:55:01 GMT Subject: [vectorIntrinsics+mask] RFR: 8273371: [Vector API] Crash in Assembler::evpermd when code-gen for masked rearrange operation on AVX512 In-Reply-To: References: Message-ID: On Mon, 6 Sep 2021 08:28:34 GMT, Jie Fu wrote: > Hi all, > > I'd like to fix the crash in Assembler::evpermd when code-gen for masked int/float rearrange operation on AVX512. > This is because evpermd can be only used for vector-size-in-bits > 128 [1]. > The fix is disabling the code-gen for int/float if vector-size-in-bits < 256. > > Thanks. > Best regards, > Jie > > [1] https://www.felixcloutier.com/x86/vpermd:vpermw LGTM ------------- PR: https://git.openjdk.java.net/panama-vector/pull/121 From jiefu at openjdk.java.net Tue Sep 7 04:55:01 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Tue, 7 Sep 2021 04:55:01 GMT Subject: [vectorIntrinsics+mask] RFR: 8273371: [Vector API] Crash in Assembler::evpermd when code-gen for masked rearrange operation on AVX512 In-Reply-To: References: Message-ID: On Tue, 7 Sep 2021 04:51:40 GMT, Jatin Bhateja wrote: >> Hi all, >> >> I'd like to fix the crash in Assembler::evpermd when code-gen for masked int/float rearrange operation on AVX512. >> This is because evpermd can be only used for vector-size-in-bits > 128 [1]. >> The fix is disabling the code-gen for int/float if vector-size-in-bits < 256. >> >> Thanks. >> Best regards, >> Jie >> >> [1] https://www.felixcloutier.com/x86/vpermd:vpermw > > LGTM Thanks @jatin-bhateja ------------- PR: https://git.openjdk.java.net/panama-vector/pull/121 From jiefu at openjdk.java.net Tue Sep 7 05:07:53 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Tue, 7 Sep 2021 05:07:53 GMT Subject: [vectorIntrinsics+mask] RFR: 8273371: [Vector API] Crash in Assembler::evpermd when code-gen for masked rearrange operation on AVX512 In-Reply-To: References: Message-ID: On Tue, 7 Sep 2021 04:51:40 GMT, Jatin Bhateja wrote: > LGTM Hi @jatin-bhateja, you didn't mark this pr as reviewed. So it's still not ready for integration. Thanks. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/121 From jbhateja at openjdk.java.net Tue Sep 7 05:14:49 2021 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Tue, 7 Sep 2021 05:14:49 GMT Subject: [vectorIntrinsics+mask] RFR: 8273371: [Vector API] Crash in Assembler::evpermd when code-gen for masked rearrange operation on AVX512 In-Reply-To: References: Message-ID: <1Hntr4uUXW3HhE0ywFXAbBSYTQxG0GWoD-qsJ3QbvYc=.4fda43d5-6b36-41f7-8338-ee27aff0ed0c@github.com> On Mon, 6 Sep 2021 08:28:34 GMT, Jie Fu wrote: > Hi all, > > I'd like to fix the crash in Assembler::evpermd when code-gen for masked int/float rearrange operation on AVX512. > This is because evpermd can be only used for vector-size-in-bits > 128 [1]. > The fix is disabling the code-gen for int/float if vector-size-in-bits < 256. > > Thanks. > Best regards, > Jie > > [1] https://www.felixcloutier.com/x86/vpermd:vpermw Marked as reviewed by jbhateja (Committer). ------------- PR: https://git.openjdk.java.net/panama-vector/pull/121 From jiefu at openjdk.java.net Tue Sep 7 05:18:45 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Tue, 7 Sep 2021 05:18:45 GMT Subject: [vectorIntrinsics+mask] RFR: 8273367: [Vector API] Fix a regression of rearrange intrinsic after JDK-8272479 In-Reply-To: References: Message-ID: On Mon, 6 Sep 2021 02:43:48 GMT, Jie Fu wrote: > Hi all, > > After JDK-8272479, the following crash was observed on x86 with `-ea -esa -Xcomp -XX:CompileThreshold=100` > > > test Double256VectorTests.RearrangeDouble256VectorTests(double[-i * 5], shuffle[random]): success > test Double256VectorTests.RearrangeDouble256VectorTests(double[i * 5], shuffle[random]): success > test Double256VectorTests.RearrangeDouble256VectorTests(double[i + 1], shuffle[random]): success > test Double256VectorTests.RearrangeDouble256VectorTests(double[cornerCaseValue(i)], shuffle[random]): success > o114 ReplicateD === _ o73 [[o340 ]] #vectory[4]:{double} > > --N: o114 ReplicateD === _ o73 [[o340 ]] #vectory[4]:{double} > > --N: o73 ConI === o0 [[o166 o173 o114 ]] #int:0 > IMMI 10 IMMI > IMMI_0 0 IMMI_0 > IMMI2 0 IMMI2 > IMMU7 5 IMMU7 > IMMI8 5 IMMI8 > IMMU8 5 IMMU8 > IMMI16 10 IMMI16 > IMMU31 0 IMMU31 > RREGI 50 loadConI0 > RAX_REGI 50 loadConI0 > RBX_REGI 50 loadConI0 > RCX_REGI 50 loadConI0 > RDX_REGI 50 loadConI0 > RDI_REGI 50 loadConI0 > NO_RAX_RDX_REGI 50 loadConI0 > STACKSLOTI 150 storeSSI > > > This is because the type of broadcasted ZERO is incorrect. > > Other affected tests include > > jdk/incubator/vector/DoubleMaxVectorTests.java > jdk/incubator/vector/Float128VectorTests.java > jdk/incubator/vector/Float256VectorTests.java > jdk/incubator/vector/FloatMaxVectorTests.java > jdk/incubator/vector/Long256VectorTests.java > jdk/incubator/vector/LongMaxVectorTests.java > > > Let's fix it. > > Thanks. > Best regards, > Jie @jatin-bhateja there is one more fix. Thanks. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/120 From jbhateja at openjdk.java.net Tue Sep 7 06:26:52 2021 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Tue, 7 Sep 2021 06:26:52 GMT Subject: [vectorIntrinsics+mask] RFR: 8273057: [vector] New VectorAPI "SelectiveStore" In-Reply-To: References: <61F91394-25CE-4D37-AB02-3B2093C1629D@oracle.com> Message-ID: On Mon, 6 Sep 2021 07:15:37 GMT, Joshua Zhu wrote: > > In summary, from the discussion, compress/expand are: > > > > * important conceptually, even if the same functionality could be composed from shuffles (such as used by an implementation); and > > * at the right level to reliably optimize on supporting hardware. > > > > So specification-wise we introduce expanding/compressing cross-lane operations. API-wise I prefer two distinct methods rather that one that accepts boolean indicating expansion or compression. We can declare one intrinsic method in VectorSupport. > > Thanks Paul for bringing the deep design thinking. > John Rose's encompassing knowledge impresses me a lot. > Also thank Sandhya and Ningsheng for comments. > > I will refactor my codes and implement these two cross-lane data movement primitives: mask-based compression & expansion. > They will work on general vectors and be declared: > > ``` > $abstractvectortype$ compress(VectorMask<$Boxtype$> m); > $abstractvectortype$ expand(VectorMask<$Boxtype$> m); > ``` > > These two vector-to-vector operations together with a store/load and prefix mask could be optimized further into single memory version instruction on supported architecture. Hi @JoshuaZhuwj , While adding new macro level APIs is appealing, we can also extend following existing vectorAPIs to accept another boolean flag "is_selective" under which compression/expansion triggers. In this use case its difficult to infer COMPRESSION through Auto-vectorizer though we made attempts in past to infer complex loop patterns for VNNI instruction. ``` public static IntVector fromArray?(VectorSpecies species, int[] a, int offset, VectorMask m) public final void intoArray?(int[] a, int offset, VectorMask m) This way we can also share common optimizations as you suggested earlier to convert masked COMPRESS to unmasked vector move for ALLTRUE mask, some work[1][2] is already in place on this front. Best Regards, Jatin [1] https://github.com/openjdk/panama-vector/blob/master/src/hotspot/share/opto/vectornode.cpp#L752 [2] https://github.com/openjdk/panama-vector/blob/master/src/hotspot/share/opto/vectornode.cpp#L771 ------------- PR: https://git.openjdk.java.net/panama-vector/pull/115 From jiefu at openjdk.java.net Tue Sep 7 06:57:58 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Tue, 7 Sep 2021 06:57:58 GMT Subject: [vectorIntrinsics+mask] Integrated: 8273371: [Vector API] Crash in Assembler::evpermd when code-gen for masked rearrange operation on AVX512 In-Reply-To: References: Message-ID: <0jYbd9-tczizVUFzNG-cN_-26HUsmflzhGagU93b9gg=.be594f30-ccda-418c-9b1c-4c5a535c6126@github.com> On Mon, 6 Sep 2021 08:28:34 GMT, Jie Fu wrote: > Hi all, > > I'd like to fix the crash in Assembler::evpermd when code-gen for masked int/float rearrange operation on AVX512. > This is because evpermd can be only used for vector-size-in-bits > 128 [1]. > The fix is disabling the code-gen for int/float if vector-size-in-bits < 256. > > Thanks. > Best regards, > Jie > > [1] https://www.felixcloutier.com/x86/vpermd:vpermw This pull request has now been integrated. Changeset: 4d66ded4 Author: Jie Fu Committer: Jatin Bhateja URL: https://git.openjdk.java.net/panama-vector/commit/4d66ded490265bd4165d0256dfd5c7540f8074ac Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod 8273371: [Vector API] Crash in Assembler::evpermd when code-gen for masked rearrange operation on AVX512 Reviewed-by: jbhateja ------------- PR: https://git.openjdk.java.net/panama-vector/pull/121 From jzhu at openjdk.java.net Tue Sep 7 09:41:54 2021 From: jzhu at openjdk.java.net (Joshua Zhu) Date: Tue, 7 Sep 2021 09:41:54 GMT Subject: [vectorIntrinsics+mask] RFR: 8273057: [vector] New VectorAPI "SelectiveStore" In-Reply-To: References: Message-ID: On Fri, 27 Aug 2021 09:47:10 GMT, Joshua Zhu wrote: > Hi, > > I want to propose a new VectorAPI "Selective Store/Load" and share my > implementation. Currently Alibaba's internal databases are in the > process of applying VectorAPI and they have requirements on "Selective > Store" for acceleration. > > My proposed VectorAPI is declared as below [1]: > > int selectiveIntoArray($type$[] a, int offset, VectorMask<$Boxtype$> m); > > The active elements (with their respective bit set in mask) are > contiguously stored into the array "a". Assume N is the true count of > mask, the elements starting from a[offset+N] till a[offset+laneCount] > are left unchanged. The return value represents the number of elements > store into the array and "offset + return value" is the new offset of > the next iteration. > ![image](https://user-images.githubusercontent.com/70769035/131108509-3dcb61f3-e8d0-4b4e-9b49-a72c077aaba6.png) > This API will be used like the following manner [2]: > > tld.conflict_cnt = 0; > for (int i = 0; i < ARRAY_LENGTH; i += INT_PREFERRED_SPECIES.length()) { > IntVector av = IntVector.fromArray(INT_PREFERRED_SPECIES, tld.int_input1, i); > IntVector bv = IntVector.fromArray(INT_PREFERRED_SPECIES, tld.int_input2, i); > IntVector cv = IntVector.fromArray(INT_PREFERRED_SPECIES, tld.int_index, i); > VectorMask mask = av.compare(VectorOperators.NE, bv); > tld.conflict_cnt += cv.selectiveIntoArray(tld.conflict_array, tld.conflict_cnt, mask); > } > > My patch includes the following changes: >   * Selective Store VectorAPI for Long & Int >   * Assembler: add x86 instruction "VPCOMPRESSD" and "VPCOMPRESSQ" >   * Instruction selection: vselective_store; kmask_truecount (true count of kregister) >   * Add node "StoreVectorSelective" >   * Add a new parameter "is_selective" in inline_vector_mem_masked_operation() >     in order to distinguish Masked version or Selective version >   * jtreg cases >   * JMH benchmark > > TODO parts I will implement: >   * Selective Store for other types >   * Selective Load >   * Some potential optimization. Such as: when mask is allTrue, SelectiveIntoArray() -> IntoArray() > > Test: >   * Passed VectorAPI jtreg cases. >   * Result of JMH benchmark to evaluate API's performance in Alibaba's real scenario. >       UseAVX=3; thread number = 8; conflict data percentage: 20% (that means 20% of mask bits are true) >       http://cr.openjdk.java.net/~jzhu/8273057/jmh_benchmark_result.pdf > > [1] https://github.com/JoshuaZhuwj/panama-vector/commit/69623f7d6a1eae532576359328b96162d8e16837#diff-13cc2d6ec18e487ddae05cda671bdb6bb7ffd42ff7bc51a2e00c8c5e622bd55dR4667 > [2] https://github.com/JoshuaZhuwj/panama-vector/commit/69623f7d6a1eae532576359328b96162d8e16837#diff-951d02bd72a931ac34bc85d1d4e656a14f8943e143fc9282b36b9c76c1893c0cR144 > [3] failed to inline (intrinsic) by https://github.com/openjdk/panama-vector/blob/60aa8ca6dc0b3f1a3ee517db167f9660012858cd/src/hotspot/cpu/x86/x86.ad#L1769 > > Best Regards, > Joshua > While adding new macro level APIs is appealing, we can also extend following existing vectorAPIs to accept another boolean flag "is_selective" under which compression/expansion triggers. > > ``` > public static IntVector fromArray?(VectorSpecies species, > int[] a, > int offset, > VectorMask m) > > > public final void intoArray?(int[] a, > int offset, > VectorMask m) > ``` Per design discussion in this thread, compared to vector-to-memory operation, vector-to-vector compress/expand operation is the more friendly primitive. It can also be used to "bridge to and from permutation simply by working with index vectors like iota, and perhaps (as sugar) lifting selected vector operations to shuffles." For different architectures, like SVE, memory destination version is also not supported natively. > In this use case its difficult to infer COMPRESSION through Auto-vectorizer though we made attempts in past to infer complex loop patterns for VNNI instruction. Could you elaborate on it please? I do not follow this. > This way we can also share common optimizations as you suggested earlier to convert masked COMPRESS to unmasked vector move for ALLTRUE mask, some work[1][2] is already in place on this front. > > [1] https://github.com/openjdk/panama-vector/blob/master/src/hotspot/share/opto/vectornode.cpp#L752 > [2] https://github.com/openjdk/panama-vector/blob/master/src/hotspot/share/opto/vectornode.cpp#L771 Yes. Since compress/expand op is also mask-based, this piece of optimization is common. Maybe we can think of one way to share this optimization for different kinds of masked operations? ------------- PR: https://git.openjdk.java.net/panama-vector/pull/115 From jiefu at openjdk.java.net Tue Sep 7 11:44:49 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Tue, 7 Sep 2021 11:44:49 GMT Subject: [vectorIntrinsics+mask] RFR: 8273367: [Vector API] Fix a regression of rearrange intrinsic after JDK-8272479 In-Reply-To: References: Message-ID: On Mon, 6 Sep 2021 07:58:37 GMT, Ningsheng Jian wrote: >> Hi all, >> >> After JDK-8272479, the following crash was observed on x86 with `-ea -esa -Xcomp -XX:CompileThreshold=100` >> >> >> test Double256VectorTests.RearrangeDouble256VectorTests(double[-i * 5], shuffle[random]): success >> test Double256VectorTests.RearrangeDouble256VectorTests(double[i * 5], shuffle[random]): success >> test Double256VectorTests.RearrangeDouble256VectorTests(double[i + 1], shuffle[random]): success >> test Double256VectorTests.RearrangeDouble256VectorTests(double[cornerCaseValue(i)], shuffle[random]): success >> o114 ReplicateD === _ o73 [[o340 ]] #vectory[4]:{double} >> >> --N: o114 ReplicateD === _ o73 [[o340 ]] #vectory[4]:{double} >> >> --N: o73 ConI === o0 [[o166 o173 o114 ]] #int:0 >> IMMI 10 IMMI >> IMMI_0 0 IMMI_0 >> IMMI2 0 IMMI2 >> IMMU7 5 IMMU7 >> IMMI8 5 IMMI8 >> IMMU8 5 IMMU8 >> IMMI16 10 IMMI16 >> IMMU31 0 IMMU31 >> RREGI 50 loadConI0 >> RAX_REGI 50 loadConI0 >> RBX_REGI 50 loadConI0 >> RCX_REGI 50 loadConI0 >> RDX_REGI 50 loadConI0 >> RDI_REGI 50 loadConI0 >> NO_RAX_RDX_REGI 50 loadConI0 >> STACKSLOTI 150 storeSSI >> >> >> This is because the type of broadcasted ZERO is incorrect. >> >> Other affected tests include >> >> jdk/incubator/vector/DoubleMaxVectorTests.java >> jdk/incubator/vector/Float128VectorTests.java >> jdk/incubator/vector/Float256VectorTests.java >> jdk/incubator/vector/FloatMaxVectorTests.java >> jdk/incubator/vector/Long256VectorTests.java >> jdk/incubator/vector/LongMaxVectorTests.java >> >> >> Let's fix it. >> >> Thanks. >> Best regards, >> Jie > > Marked as reviewed by njian (Committer). @nsjian and @jatin-bhateja , need your help to sponsor it. Thanks. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/120 From jbhateja at openjdk.java.net Tue Sep 7 14:59:04 2021 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Tue, 7 Sep 2021 14:59:04 GMT Subject: [vectorIntrinsics+mask] RFR: 8273406: Optimize various masked vector operations for AVX512 target. Message-ID: This patch is in continuation to X86 backend support for optimizing masked operations over AVX-512 targets (JDK-8262356). Summary of changes: 1) Support for masked rotate left and right operations over integer/long vectors. 2) Support for masked square root operation over float/double vectors. 3) Support for masked logical shiftleft and logical/arithmetic shiftright operation with constant shift count. 4) Optimized VectorMask.not operation by emitting direct KNOT instruction. 5) Extended masking optimization support for X86 KNL target which has limited set of AVX-512 features. - Currently vector type associated with VectorLoadMask operation is created during parsing stage. For targets supporting opmask registers, lane type is explicitly set to BOOLEAN irrespective of the primitive type of species i.e. for Int512 species ideal type TypeVectMask(16,BOOL) represent vector of 16 BOOLEAN elements each of which represent a mask bit for corresponding vector lane. This type information is also associated with respective mask boxes (Int512Mask). - During macro expansion vbox/vunbox nodes are broken down into granular target mappable ideal nodes. ``` VectorBoxNode -> VectorStoreMask + StoreVector VectorUnboxNode -> LoadVector + VectorLoadMask ``` At this stage vector type (TypeVectMask(16,BOOL)) earlier associated with vunbox node is used to create the type for VectorLoadMask operation. - Masks can be propagated either though a vector (non-AVX512 targets) or using opmask registers (K1-K7). Decision to create correct ideal type based on the target features is delegated to low level type creation routine TypeVect::makemask. - This creates problem for targets like KNL which support limited set of AVX-512 features i.e. do no support AVX512VL and AVX512BW feature. - For Int512 species initial ideal type constructed during parsing is based on primitive type and lane count associated with species, but during macro expansion type creation decision is based on vector type associated with v[u]box nodes i.e. TypeVectoMask(16,BOOL), thus for KNL target incorrect vector mask type TypeVectX(16,BOOL) gets created since it does not support vector length extension(128,256 bit operation over EVEX encoded instruction). - There are multiple ways to fix this discrepancy, cleanest approach is to create ideal type TypeVectoMask based on the primitive lane type of the species, instead of always setting the lane type as BOOLEAN. This will also preserve the original lane type information which was needed in some cases e.g. reinterpretation operation over mask. To circumvent such issue explicit src/dst primitive types were added to ideal nodes. - Also this does not disturbs the register mask and spilling behavior associated with opmask registers thus the change is transparent to backend passes. Validation: Patch regressed through tier1-3 tests at AVX Level=0,1,2,3 and UseKNLSetting ------------- Commit messages: - 8273406: Optimize various masked vector operations for AVX512 target. Changes: https://git.openjdk.java.net/panama-vector/pull/122/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=122&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273406 Stats: 736 lines in 14 files changed: 666 ins; 26 del; 44 mod Patch: https://git.openjdk.java.net/panama-vector/pull/122.diff Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/122/head:pull/122 PR: https://git.openjdk.java.net/panama-vector/pull/122 From jbhateja at openjdk.java.net Tue Sep 7 15:41:49 2021 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Tue, 7 Sep 2021 15:41:49 GMT Subject: [vectorIntrinsics+mask] RFR: 8273057: [vector] New VectorAPI "SelectiveStore" In-Reply-To: References: Message-ID: On Tue, 7 Sep 2021 09:38:29 GMT, Joshua Zhu wrote: > > While adding new macro level APIs is appealing, we can also extend following existing vectorAPIs to accept another boolean flag "is_selective" under which compression/expansion triggers. > > ``` > > public static IntVector fromArray?(VectorSpecies species, > > int[] a, > > int offset, > > VectorMask m) > > > > > > public final void intoArray?(int[] a, > > int offset, > > VectorMask m) > > ``` > > Per design discussion in this thread, compared to vector-to-memory operation, vector-to-vector compress/expand operation is the more friendly primitive. > It can also be used to "bridge to and from permutation simply by working with index vectors like iota, and perhaps (as sugar) lifting selected vector operations to shuffles." > For different architectures, like SVE, memory destination version is also not supported natively. > > > In this use case its difficult to infer COMPRESSION through Auto-vectorizer though we made attempts in past to infer complex loop patterns for VNNI instruction. > > Could you elaborate on it please? I do not follow this. > I meant auto-vectorizing following loop which mimic compression semantics could be tricky if its difficult to ascertain the independence between memory references. Like in following case 'j' could be a middle index in array and thus if the distance between memory references is less than chosen vector width it may result into incorrect overwrite. for ( int i = 0; i < n ; i++ ) { if ( mask[i] > 1 ) { a[j++] = a[i]; } } > > This way we can also share common optimizations as you suggested earlier to convert masked COMPRESS to unmasked vector move for ALLTRUE mask, some work[1][2] is already in place on this front. > > [1] https://github.com/openjdk/panama-vector/blob/master/src/hotspot/share/opto/vectornode.cpp#L752 > > [2] https://github.com/openjdk/panama-vector/blob/master/src/hotspot/share/opto/vectornode.cpp#L771 > > Yes. Since compress/expand op is also mask-based, this piece of optimization is common. Maybe we can think of one way to share this optimization for different kinds of masked operations? Yes, agree. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/115 From paul.sandoz at oracle.com Tue Sep 7 16:33:58 2021 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 7 Sep 2021 16:33:58 +0000 Subject: [vectorIntrinsics+mask] RFR: 8273057: [vector] New VectorAPI "SelectiveStore" In-Reply-To: References: <61F91394-25CE-4D37-AB02-3B2093C1629D@oracle.com> Message-ID: <23BA299B-BA4A-4607-AF49-DD20003BBE2A@oracle.com> Hi Joshua, Thank you for your patience as we went through deeper design thinking. Would it be possible for you to target this work to a new branch? e.g. vectorIntrinsics+compress. I want to avoid complicating review and integration of the masking work for JEP 417. We are close to merging vectorIntrinsics+mask into vectorIntrinsics and then starting reviews of the masking support. It may be possible that compress/expand become part of JEP 417, if we can get it ready in time. If so I can update the JEP accordingly and help do CSRs. Otherwise, we can target to the next round of incubation. Paul. > On Sep 6, 2021, at 12:18 AM, Joshua Zhu wrote: > > On Fri, 3 Sep 2021 20:13:46 GMT, Paul Sandoz wrote: > >> In summary, from the discussion, compress/expand are: >> >> - important conceptually, even if the same functionality could be composed from shuffles (such as used by an implementation); and >> >> - at the right level to reliably optimize on supporting hardware. >> >> So specification-wise we introduce expanding/compressing cross-lane operations. API-wise I prefer two distinct methods rather that one that accepts boolean indicating expansion or compression. We can declare one intrinsic method in VectorSupport. > > Thanks Paul for bringing the deep design thinking. > John Rose's encompassing knowledge impresses me a lot. > Also thank Sandhya and Ningsheng for comments. > > I will refactor my codes and implement these two cross-lane data movement primitives: mask-based compression & expansion. > They will work on general vectors and be declared: > > $abstractvectortype$ compress(VectorMask<$Boxtype$> m); > $abstractvectortype$ expand(VectorMask<$Boxtype$> m); > > These two vector-to-vector operations together with a store/load and prefix mask could be optimized further into single memory version instruction on supported architecture. > > ------------- > > PR: https://git.openjdk.java.net/panama-vector/pull/115 From paul.sandoz at oracle.com Tue Sep 7 16:46:56 2021 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 7 Sep 2021 16:46:56 +0000 Subject: Arrays.mismatch intrinsic and Vector API comparision In-Reply-To: References: <71444AEA-0386-417D-B6CB-0ABF957E107A@oracle.com> Message-ID: <746E4CC5-9521-4435-A3B3-78A1C444F0BD@oracle.com> Rado, do think the recent changes to stride size [1] perturbed this area? I don?t recall seeing such aggressive unrolling before. Paul. [1] https://github.com/openjdk/jdk/pull/4658 > On Sep 4, 2021, at 8:00 AM, Rado Smogura wrote: > > Hi all, > > > Interesting topic. > > > In context of too aggressive unrolling. I think I know what could be a reason. There's standard unroll limit, however vectorization can increase it - https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/loopTransform.cpp*L998__;Iw!!ACWV5N9M2RV99hQ!aRm01M_jzh0OqlNCGAjbLaIMmLvv95-1NoWdvVVSn6iIGsoZypYmct6_PtP7dfJf9Q$ > > On my machine the new limit is 32, I guess for AVX-512 it could be 64. > > > Kind regards, > > Rado > > On 04.09.2021 14:53, Kartik Ohri wrote: >> Hi Paul, >> >> Thanks for the feedback! I'll add more cases as you suggested and submit a >> PR. >> >> Regards, >> Kartik >> >> On Fri, Sep 3, 2021 at 3:41 AM Paul Sandoz wrote: >> >>> Hi Kartik, >>> >>> Thank you. It is useful. I am glad we are reaching the point where the >>> Vector API is getting competitive with the mismatch stub. >>> >>> If you would like to contribute the benchmark I would be happy to review a >>> PR. >>> We could also measure int, float and long, in addition to small sizes, >>> just above or below the vector length (not dissimilar to a mismatch on the >>> the first or lower index of an array). >>> When we wrote Arrays.mismatch we were very careful to measure the impact >>> on small array sizes, since that method is also used to support >>> Arrays.equals and we did not want to introduce a performance regression. >>> >>> >>> Some of the difference might be explained by alignment of the arrays, some >>> perhaps due to loop unrolling. >>> >>> I think there might be an issue with loop unrolling. It seems too >>> aggressive, resulting larger than necessary nmethod sizes. We should look >>> into that. >>> >>> >>> Unsure if it's possible to to reduce [*]: >>> >>> vpcmpeqb %ymm1,%ymm0,%ymm0 >>> vpxor -0x7ad507d(%rip),%ymm0,%ymm0 >>> >>> to: >>> >>> vpxor %ymm1,%ymm0,%ymm0 >>> >>> Since the latter will not produce a valid mask representation, which could >>> affect later use of the mask value (firstTrue). >>> >>> Paul. >>> >>> [*] >>> https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/macroAssembler_x86.cpp*L3211__;Iw!!ACWV5N9M2RV99hQ!aRm01M_jzh0OqlNCGAjbLaIMmLvv95-1NoWdvVVSn6iIGsoZypYmct6_PtMBfj1FBQ$ >>>> On Aug 29, 2021, at 11:36 AM, Kartik Ohri >>> wrote: >>>> Hi! >>>> >>>> I have started experimenting with the Vector API recently. Currently, I >>> am >>>> playing with the API and trying to gauge its potential by comparing its >>>> performance with vectorized intrinsics implemented inside the JDK. I know >>>> that Arrays.mismatch has a vectorized intrinsic so I started with it. I >>> was >>>> able to come up with a simple implementation for it using the Vector API. >>>> The results of the JMH benchmark look quite promising, the Vector API is >>>> able to come quite close to the intrinsic. This is awesome!! >>>> >>>> The benchmark code is available here >>>> < >>> https://urldefense.com/v3/__https://github.com/amCap1712/curly-computing-machine/blob/main/src/main/java/dev/lucifer/benchmarks/ArrayMismatchBenchmark.java__;!!ACWV5N9M2RV99hQ!aRm01M_jzh0OqlNCGAjbLaIMmLvv95-1NoWdvVVSn6iIGsoZypYmct6_PtPovnwOrw$ >>>> and >>>> the complete benchmark logs are here >>>> < >>> https://urldefense.com/v3/__https://github.com/amCap1712/curly-computing-machine/blob/main/results/array-mismatch.csv__;!!ACWV5N9M2RV99hQ!aRm01M_jzh0OqlNCGAjbLaIMmLvv95-1NoWdvVVSn6iIGsoZypYmct6_PtM7ccQAFQ$ >>>> . >>>> I also did another run to check the assembly generated which is also >>>> available here >>>> < >>> https://urldefense.com/v3/__https://github.com/amCap1712/curly-computing-machine/blob/main/results/benchmarks.asm.log__;!!ACWV5N9M2RV99hQ!aRm01M_jzh0OqlNCGAjbLaIMmLvv95-1NoWdvVVSn6iIGsoZypYmct6_PtPPLp8e6w$ >>>> . >>>> It would be nice to get a sanity check on the benchmark before I proceed >>>> further. >>>> >>>> Both versions perform more or less the same (difference is less than 5%, >>> in >>>> some cases the Vector API even outperforms the intrinsic). There is one >>>> outlier where the Vector API is almost 35% slower than the intrinsic >>> (when >>>> prefix is 1 and size is 10000). >>>> except for when the prefix is 1 i.e. both input arrays are equal. I see >>>> that the assembly emitted by Vector API >>>> < >>> https://urldefense.com/v3/__https://github.com/amCap1712/curly-computing-machine/blob/main/results/benchmarks.asm.log*L7436__;Iw!!ACWV5N9M2RV99hQ!aRm01M_jzh0OqlNCGAjbLaIMmLvv95-1NoWdvVVSn6iIGsoZypYmct6_PtOiZElBVA$ >>>> contains a *vpcmpeqb* but the JDK intrinsic >>>> < >>> https://urldefense.com/v3/__https://github.com/amCap1712/curly-computing-machine/blob/main/results/benchmarks.asm.log*L2064__;Iw!!ACWV5N9M2RV99hQ!aRm01M_jzh0OqlNCGAjbLaIMmLvv95-1NoWdvVVSn6iIGsoZypYmct6_PtOepQLVQA$ >>>> does not. Looking at the implementation >>>> < >>> https://urldefense.com/v3/__https://github.com/openjdk/panama-vector/blob/2fd7943ec191559bfb2778305daf82bcc4422028/src/hotspot/cpu/x86/macroAssembler_x86.cpp*L6088-L6125__;Iw!!ACWV5N9M2RV99hQ!aRm01M_jzh0OqlNCGAjbLaIMmLvv95-1NoWdvVVSn6iIGsoZypYmct6_PtNJS-xo5A$ >>>> of the intrinsic in the JDK, The AVX 512 version uses *vpcmpeqb* but the >>>> AVX2 version does not (my machine does not have AVX 512 so it makes that >>> it >>>> was not emitted in the case of the intrinsic). Secondly, from the >>> assembly >>>> it seems that the Vector API version was unrolled but the intrinsic was >>>> not. If I am right, in general loop unrolling is better so the API seems >>> to >>>> be doing the right thing. Hence, I am not sure why this particular case >>> is >>>> an outlier. >>>> >>>> Further, Is analysing/comparing intrinsics within the JDK to the Vector >>> API >>>> useful? >>>> >>>> Also, any other suggestions regarding contributing to the Project are >>>> welcome. >>>> >>>> Regards, >>>> Kartik From psandoz at openjdk.java.net Tue Sep 7 17:46:51 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Tue, 7 Sep 2021 17:46:51 GMT Subject: [vectorIntrinsics+mask] RFR: 8273406: Optimize various masked vector operations for AVX512 target. In-Reply-To: References: Message-ID: <6kCpmxefYaZUAbKSS65LzJwwiLMTp4IR0KKi53SSVD0=.c11e2264-6168-4204-881a-42ecb26992b9@github.com> On Tue, 7 Sep 2021 14:53:25 GMT, Jatin Bhateja wrote: > This patch is in continuation to X86 backend support for optimizing masked operations over AVX-512 targets (JDK-8262356). > > Summary of changes: > > 1) Support for masked rotate left and right operations over integer/long vectors. > > 2) Support for masked square root operation over float/double vectors. > > 3) Support for masked logical shiftleft and logical/arithmetic shiftright operation with constant shift count. > > 4) Optimized VectorMask.not operation by emitting direct KNOT instruction. > > 5) Extended masking optimization support for X86 KNL target which has limited set of AVX-512 features. > > - Currently vector type associated with VectorLoadMask operation is created during parsing stage. > For targets supporting opmask registers, lane type is explicitly set to BOOLEAN irrespective of the primitive > type of species i.e. for Int512 species ideal type TypeVectMask(16,BOOL) represent vector of 16 BOOLEAN elements > each of which represent a mask bit for corresponding vector lane. > This type information is also associated with respective mask boxes (Int512Mask). > > - During macro expansion vbox/vunbox nodes are broken down into granular target mappable ideal nodes. > > ``` > VectorBoxNode -> VectorStoreMask + StoreVector > > VectorUnboxNode -> LoadVector + VectorLoadMask > ``` > > At this stage vector type (TypeVectMask(16,BOOL)) earlier associated with vunbox node is used to create the > type for VectorLoadMask operation. > > - Masks can be propagated either though a vector (non-AVX512 targets) or using opmask registers (K1-K7). > Decision to create correct ideal type based on the target features is delegated to low level > type creation routine TypeVect::makemask. > > - This creates problem for targets like KNL which support limited set of AVX-512 features i.e. do > no support AVX512VL and AVX512BW feature. > > - For Int512 species initial ideal type constructed during parsing is based on primitive type and > lane count associated with species, but during macro expansion type creation > decision is based on vector type associated with v[u]box nodes i.e. TypeVectoMask(16,BOOL), > thus for KNL target incorrect vector mask type TypeVectX(16,BOOL) gets created since it does not > support vector length extension(128,256 bit operation over EVEX encoded instruction). > > - There are multiple ways to fix this discrepancy, cleanest approach is to create ideal type TypeVectoMask > based on the primitive lane type of the species, instead of always setting the lane type as BOOLEAN. > This will also preserve the original lane type information which was needed in some cases e.g. > reinterpretation operation over mask. To circumvent such issue explicit src/dst primitive types > were added to ideal nodes. > > - Also this does not disturbs the register mask and spilling behavior associated with opmask registers > thus the change is transparent to backend passes. > > Validation: > Patch regressed through tier1-3 tests at AVX Level=0,1,2,3 and UseKNLSetting @jatin-bhateja is [JDK-8262356](https://bugs.openjdk.java.net/browse/JDK-8262356) mostly a duplicate of the sub-task [JDK-8272359](https://bugs.openjdk.java.net/browse/JDK-8272359)? ------------- PR: https://git.openjdk.java.net/panama-vector/pull/122 From vladimir.x.ivanov at oracle.com Tue Sep 7 18:01:31 2021 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 7 Sep 2021 21:01:31 +0300 Subject: [External] : Re: Issues with loop unrolling: better pinned node In-Reply-To: References: <19C617EE-6745-4DA3-A5AE-674E92F7DAA4@oracle.com> <14e30959-d990-2180-f23d-a05c88ec7899@smogura.eu> <3f7dd833-f632-9b3d-0713-37e78f5de928@oracle.com> Message-ID: <4cead9e6-87c2-2498-b7e6-2d378dd1f0a2@oracle.com> Thanks for giving it a try, Rado. It feels like a lot of complexity comes from attempting to support multiple slices per memory operation. How would it look like if you give up on them and use the TypePtr::BOTTOM/AliasIdxBot? Such memory operations won't be amenable for further memory-related optimizations (since they alias with any other memory operation), but it should significantly simplify their support, shouldn't it? Best regards, Vladimir Ivanov On 02.09.2021 22:53, Rado Smogura wrote: > Hi Vladimir, > > > Thank you for feedback. > > > There was one idea I had previously and I added it here (I surprised it > works): > > * add additional filed TypeTuple _multi_load_adr to Node and set it in > mixed mode, > > * in anti-deps add external loop to do analysis for every address from > this tuple > > Minor changes: > > * pass this field to mach node; > > * in anti-deps load node has to traverse memory chain (normally this is > done in Ideal). > > > I checked it with mixed "mode" operating on int and byte vectors and I > see storeV (raw / byte[]) gets anit-dep to loadV (raw/int[]), and same > for storeV(raw/byte[]) - so that's good - as there's interference over raw. > > > https://urldefense.com/v3/__https://github.com/openjdk/panama-vector/compare/vectorIntrinsics*mask...rsmogura:mixed-mode-use-bot-mem-opt-antideps?expand=1__;Kw!!ACWV5N9M2RV99hQ!ZnX5KqhoIDbUbqdEBiwN3v2aGgLQLfRteZuZKx0RmLzqhfMhcKrMedWCzfG8mBggvHhJ2R8$ > > > Kind regards, > > Rado > > On 01.09.2021 15:22, Vladimir Ivanov wrote: >> Interesting idea, Rado! Representing memory effects of >> mixed/mismatched accesses with TypePtr::BOTTOM does look promising. >> >> Regarding the preferred IR shapes, I'd try to teach alias analysis >> (Compile::find_alias_type()) and PhaseCFG::insert_anti_dependences() >> about loads/stores on wide memory (TypePtr::BOTTOM) and see what kind >> of problems arise to decide how to proceed. I hope there's a way to >> avoid dummy nodes when representing desired effects. >> >> Best regards, >> Vladimir Ivanov >> >> On 30.08.2021 18:12, Rado Smogura wrote: >>> Hi all, >>> >>> >>> I added one missing thing. I want to build something like this. Would >>> it make sense? >>> >>> >>> ??? STORE >>> >>> >>> ??????????????????????????????? addr >>> ????????????????????????????????? ? >>> ????????????????????????????????? ? >>> ????????? reset_memory()????????? ? >>> ???????????? ???? ?????????????????????????? >>> ???????????? ???? ? CheckCastPP (-> BOT)?? ? >>> ???????????? ???? ?????????????????????????? >>> ???????????? ??????????? ? >>> ???????????? ??????????? ? >>> ???????????? ??????? ??? ? >>> ???????????? ??????? ??? ? >>> ???????????? ?? ????????????????????????????????????? >>> ???????????? ?? ???????????? StoreVector??????????? ? >>> ???????????? ?? ????????????????????????????????????? >>> ???????????? ?????? ??????????????????????????? ? >>> ???????????? ?????? ??????????????????????????? ? >>> ?????????????????????????????????????????????????????????????????? >>> ??????????? ? BOT? RAW byte[]????????????????????????? ? >>> ??????????? ? MergeMem??????????????????????????????????????? ? >>> ?????????????????????????????????????????????????????????????????? >>> >>> >>> >>> ???? LOAD >>> >>> ????????????? ? >>> ????????????? ? >>> ????????????? ??????????? >>> ????????????? ????????? ? >>> ????????????? ? >>> ??????????????????????????????????????????????????????????????? >>> ????????????? ? ? LoadVector >>> (BOT)??????????????????????????????????????????? ? >>> ????????????? ? >>> ??????????????????????????????????????????????????????????????? >>> ????????????? ????????????????????????? ? ? >>> ????????????? ????? addr base -> raw ????????????????????????? ? addr >>> base -> byte[] >>> ????????????? ????????????????????????? ? ? >>> ????????????? ??????????? ????????????????????????? >>> ????????????????????????? >>> ????????????? ??????????? ?DummyStoreV (raw)????? ? ?DummyStoreV >>> (byte[])?? ? //No-op stores >>> ????????????? ??????????? ????????????????????????? >>> ????????????????????????? >>> ????????????? ?????????????????? ??????????????????????? ? >>> ????????????? ????? ?????????????????????????? ??????????? >>> ????????????? ????? ?????????????????????????? ? >>> ??????????????????????????????????????????????????????????????????? >>> ??????????? ? BOT? RAW byte[]?????????????????????????? ? >>> ??????????? ? MergeMem???????????????????????????????????????? ? >>> ??????????????????????????????????????????????????????????????????? >>> >>> >>> DummyStore is "virtual" node inserted after load, intended to emulate >>> store, and prevent writes / reads to go on the side of load vector >>> (it fact it more prevents store / load to see through mem-memrge). >>> >>> I did test it with following code. >>> >>> public static void copyMemoryBytes3(ByteBuffer in, ByteBuffer out, >>> ByteBuffer out2,byte[] arr) { >>> ???? for (int i=0; i >> +=SPECIES_BYTE.vectorByteSize()) { >>> ???????? var v1 = ByteVector.fromByteBuffer(SPECIES_BYTE, in, i, >>> ByteOrder.nativeOrder()); >>> ???????? arr[i] = (byte) i; >>> ???????? var v2 = ByteVector.fromByteBuffer(SPECIES_BYTE, out, i, >>> ByteOrder.nativeOrder()); >>> ???????? v1.intoByteBuffer(out, i, ByteOrder.nativeOrder()); >>> ???? } >>> } >>> >>> Kind regards, >>> >>> Rado >>> >>> On 27.08.2021 20:16, Rado Smogura wrote: >>>> Hi all, >>>> >>>> >>>> I experimented a little bit, and I wonder if this is reasonable, the >>>> outcome on graphs is as expected, and operations looks like properly >>>> ordered (but this is my private opinion). >>>> >>>> https://urldefense.com/v3/__https://github.com/rsmogura/panama-vector/commit/755b62823aaed0cddf78e8ccfc60c063bb40779a__;!!ACWV5N9M2RV99hQ!ceve5Eoh01VSiAxgPOSMpL_oQpz6MJI6KeGEcvULButhjMZGdxMq2SB02arX5hxVvmWp1wY$ >>>> >>>> >>>> Kind regards, >>>> >>>> Rado >>>> >>>> On 19.08.2021 22:26, Rado Smogura wrote: >>>>> I think I answered this question quite simply... it will not work. >>>>> >>>>> On 19.08.2021 18:39, Rado Smogura wrote: >>>>>> Hi all, >>>>>> >>>>>> >>>>>> I hope you have a good day. >>>>>> >>>>>> >>>>>> As still optimizing loops would be good approach, I thought about >>>>>> optimizing a mixed access with this approach: >>>>>> >>>>>> >>>>>> 1. When mixed access is detected set flag "raw / byte array" mixed >>>>>> access. >>>>>> >>>>>> 2. Bail out and restart compilation (will happen during first >>>>>> phases, and only for few methods). >>>>>> >>>>>> 3. Pass a flag to compiler. >>>>>> >>>>>> 4. Modify find_alias_type / flatten_alias_type, so that if byte >>>>>> array will be queried for alias, raw ptr and raw alias will be used. >>>>>> >>>>>> >>>>>> Kind regards, >>>>>> >>>>>> Rado >>>>>> >>>>>> On 18.08.2021 09:17, Rado Smogura wrote: >>>>>>> Hi Vladimir, >>>>>>> >>>>>>> >>>>>>> Thank you for answer. >>>>>>> >>>>>>> >>>>>>> In fact, it is was an attempt to confirm that memory flow can be >>>>>>> a cause why loop opts do not work. That's very fair point. I'll >>>>>>> think about it and maybe I'll be able to come out idea how this >>>>>>> can be generalized. >>>>>>> >>>>>>> >>>>>>> Kind regards, >>>>>>> >>>>>>> Rado >>>>>>> >>>>>>> On 16.08.2021 15:41, Vladimir Ivanov wrote: >>>>>>>>> I wonder what do you think about something like this [1] - it's >>>>>>>>> virtually small single class change >>>>>>>> >>>>>>>> Very interesting experiment, Rado! It's encouraging to hear that >>>>>>>> loop opts immediately benefit from it. >>>>>>>> >>>>>>>> From a architectural perspective, a separate pass to optimize >>>>>>>> memory graph brings excessive complexity: >>>>>>>> >>>>>>>> ? (1) yet another pass over the graph and susceptible to pass >>>>>>>> ordering issues; >>>>>>>> >>>>>>>> ? (2) separate from GVN: you either have to duplicate GVN-based >>>>>>>> memory optimizations or run new pass with IGVN in a loop until >>>>>>>> it stabilizes. >>>>>>>> >>>>>>>> IMO the problem you noticed illustrates a general weakness in >>>>>>>> GVN implementation and that's the place where it should be fixed >>>>>>>> (ideally). >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Vladimir Ivanov >>>>>>>> >>>>>>>>> >>>>>>>>> This change tries to find unique memory for load node. I >>>>>>>>> implemented it as separate phase, as optimization may not run >>>>>>>>> in Ideal method. I think it's ligher than phi split out. >>>>>>>>> >>>>>>>>> Loops has been transformed. RCE started. >>>>>>>>> >>>>>>>>> Kind regards, >>>>>>>>> Rado >>>>>>>>> >>>>>>>>> [1] - >>>>>>>>> https://urldefense.com/v3/__https://github.com/rsmogura/panama-vector/commit/a44f515890d2c4df3fd0e0ced76545a7664926c3__;!!ACWV5N9M2RV99hQ!ceve5Eoh01VSiAxgPOSMpL_oQpz6MJI6KeGEcvULButhjMZGdxMq2SB02arX5hxVLT5AsEE$ >>>>>>>>> >>>>>>>>> >>>>>>>>> [2] - >>>>>>>>> https://urldefense.com/v3/__https://github.com/rsmogura/panama-vector/tree/housekeeping-load-memory-optimiziation__;!!ACWV5N9M2RV99hQ!ceve5Eoh01VSiAxgPOSMpL_oQpz6MJI6KeGEcvULButhjMZGdxMq2SB02arX5hxVcBkmVi0$ >>>>>>>>> >>>>>>>>> (full test case) >>>>>>>>> >>>>>>>>> ------------------------------------------------------------------------ >>>>>>>>> >>>>>>>>> *From:* Rados?aw Smogura on behalf of Rados?aw Smogura >>>>>>>>> >>>>>>>>> *Sent:* Friday, August 6, 2021 22:43 >>>>>>>>> *To:* Rados?aw Smogura ; Paul Sandoz >>>>>>>>> ; Vladimir Ivanov >>>>>>>>> >>>>>>>>> *Cc:* panama-dev at openjdk.java.net >>>>>>>>> *Subject:* Re: Issues with loop unrolling: better pinned node >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> Now when I checked it again. it works as expected, and it's the >>>>>>>>> same code. >>>>>>>>> >>>>>>>>> In draft code I check if the buffer is direct by using type >>>>>>>>> checking to unswitch loop, as unswitching over ByteBuffer.hb >>>>>>>>> did not work (the graph was quite similar). However, I thought >>>>>>>>> that this unswitch actually helped to build correct loops, and >>>>>>>>> any kind of improvement around it would be rather for the >>>>>>>>> purpose of better-looking code. >>>>>>>>> >>>>>>>>> But it looks like that sometimes (but only sometimes) loop >>>>>>>>> still can not be correctly built, or maybe the full >>>>>>>>> optimization kicks in very, very late. >>>>>>>>> >>>>>>>>> Kind regards, >>>>>>>>> Rado >>>>>>>>> ------------------------------------------------------------------------ >>>>>>>>> >>>>>>>>> *From:* panama-dev on behalf >>>>>>>>> of Rados?aw Smogura >>>>>>>>> *Sent:* Friday, August 6, 2021 20:22 >>>>>>>>> *To:* Paul Sandoz >>>>>>>>> *Cc:* panama-dev at openjdk.java.net >>>>>>>>> *Subject:* Re: Issues with loop unrolling: better pinned node >>>>>>>>> Yes, >>>>>>>>> >>>>>>>>> The normal case looks, good. It's all about polluted cases [1] >>>>>>>>> >>>>>>>>> BR, >>>>>>>>> Rado >>>>>>>>> >>>>>>>>> [1] >>>>>>>>> https://urldefense.com/v3/__https://github.com/openjdk/panama-vector/pull/109__;!!ACWV5N9M2RV99hQ!ceve5Eoh01VSiAxgPOSMpL_oQpz6MJI6KeGEcvULButhjMZGdxMq2SB02arX5hxVfxQRu38$ >>>>>>>>> >>>>>>>>> >>>>>>>>> [https://urldefense.com/v3/__https://opengraph.githubassets.com/daf8e3b93dd4c25e04d1ce6ae2a91e1b725625bfd85b5027c61fb78ae3a6a361/openjdk/panama-vector/pull/109__;!!ACWV5N9M2RV99hQ!ceve5Eoh01VSiAxgPOSMpL_oQpz6MJI6KeGEcvULButhjMZGdxMq2SB02arX5hxVmHZKrgY$ >>>>>>>>> ]>>>>>>>> > >>>>>>>>> >>>>>>>>> (Draft) Perofrmance improvements for polluted cases by rsmogura >>>>>>>>> ? Pull Request #109 ? >>>>>>>>> openjdk/panama-vector>>>>>>>> > >>>>>>>>> >>>>>>>>> >>>>>>>>> Hi all, I would like to submit this piece of work, for byte >>>>>>>>> buffers and polluted cases. It resolves some performance issues >>>>>>>>> related to mem barriers when in scope are both on- and off-heap >>>>>>>>> buffer. T... >>>>>>>>> github.com >>>>>>>>> >>>>>>>>> [https://urldefense.com/v3/__https://opengraph.githubassets.com/5fde12f89c012a2abef1542ed59c7272429fa7556f6e82a5e617a293d3a5bee1/openjdk/panama-vector__;!!ACWV5N9M2RV99hQ!ceve5Eoh01VSiAxgPOSMpL_oQpz6MJI6KeGEcvULButhjMZGdxMq2SB02arX5hxVLW0LAx0$ >>>>>>>>> ]>>>>>>>> > >>>>>>>>> >>>>>>>>> Comparing >>>>>>>>> openjdk:vectorIntrinsics...rsmogura:vectors-polluted-cases ? >>>>>>>>> openjdk/panama-vector>>>>>>>> > >>>>>>>>> >>>>>>>>> >>>>>>>>> Panama vector. Contribute to openjdk/panama-vector development >>>>>>>>> by creating an account on GitHub. >>>>>>>>> github.com >>>>>>>>> >>>>>>>>> ________________________________ >>>>>>>>> From: Paul Sandoz >>>>>>>>> Sent: Friday, August 6, 2021 20:04 >>>>>>>>> To: Rados?aw Smogura >>>>>>>>> Cc: panama-dev at openjdk.java.net >>>>>>>>> Subject: Re: Issues with loop unrolling: better pinned node >>>>>>>>> >>>>>>>>> I am confused as to the case under test. In your initial email >>>>>>>>> of this thread were you also referring implicitly to polluted >>>>>>>>> cases? >>>>>>>>> >>>>>>>>> Paul. >>>>>>>>> >>>>>>>>>> On Aug 6, 2021, at 10:56 AM, Rados?aw Smogura >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Hi Paul, >>>>>>>>>> >>>>>>>>>> There's a performance improvement, but. I still can't unroll >>>>>>>>>> polluted cases (I cherry-picked loop unrolling). The graph >>>>>>>>>> still has few nodes taking buffer limit from phi, and on IR I >>>>>>>>>> don't see vectors nodes cascading. >>>>>>>>>> >>>>>>>>>> make test TEST='micro:ByteBufferVectorAccess.p' >>>>>>>>>> MICRO="OPTIONS=-f 1 -prof perfasm >>>>>>>>>> -jvmArgsPrepend=-Djdk.incubator.vector.VECTOR_ACCESS_OOB_CHECK=0" >>>>>>>>>> JOBS=12 >>>>>>>>>> Benchmark (size) Mode Cnt Score?? Error? Units >>>>>>>>>> ByteBufferVectorAccess.pollutedBuffers2 1024 avgt 30 40.472 ? >>>>>>>>>> 1.055? ns/op >>>>>>>>>> ByteBufferVectorAccess.pollutedBuffers2:?asm 1024 >>>>>>>>>> avgt????????? NaN??????????? --- >>>>>>>>>> ByteBufferVectorAccess.pollutedBuffers3 1024 avgt 30 79.251 ? >>>>>>>>>> 0.786? ns/op >>>>>>>>>> ByteBufferVectorAccess.pollutedBuffers3:?asm 1024 >>>>>>>>>> avgt????????? NaN??????????? --- >>>>>>>>>> ByteBufferVectorAccess.pollutedBuffers4 1024 avgt 30 83.627 ? >>>>>>>>>> 2.140? ns/op >>>>>>>>>> ByteBufferVectorAccess.pollutedBuffers4:?asm 1024 >>>>>>>>>> avgt????????? NaN??????????? --- >>>>>>>>>> ByteBufferVectorAccess.pollutedBuffers5 1024 avgt 30 85.561 ? >>>>>>>>>> 1.156? ns/op >>>>>>>>>> ByteBufferVectorAccess.pollutedBuffers5:?asm 1024 >>>>>>>>>> avgt????????? NaN >>>>>>>>>> >>>>>>>>>> make test TEST='micro:ByteBufferVectorAccess.p' >>>>>>>>>> MICRO="OPTIONS=-f 1 -prof perfasm" >>>>>>>>>> Benchmark (size) Mode Cnt Score?? Error? Units >>>>>>>>>> ByteBufferVectorAccess.pollutedBuffers2 1024 avgt 10 49.326 ? >>>>>>>>>> 0.843? ns/op >>>>>>>>>> ByteBufferVectorAccess.pollutedBuffers2:?asm 1024 >>>>>>>>>> avgt?????????? NaN??????????? --- >>>>>>>>>> ByteBufferVectorAccess.pollutedBuffers3 1024 avgt 10 100.291 ? >>>>>>>>>> 1.271? ns/op >>>>>>>>>> ByteBufferVectorAccess.pollutedBuffers3:?asm 1024 >>>>>>>>>> avgt?????????? NaN??????????? --- >>>>>>>>>> ByteBufferVectorAccess.pollutedBuffers4 1024 avgt 10 101.494 ? >>>>>>>>>> 1.027? ns/op >>>>>>>>>> ByteBufferVectorAccess.pollutedBuffers4:?asm 1024 >>>>>>>>>> avgt?????????? NaN??????????? --- >>>>>>>>>> ByteBufferVectorAccess.pollutedBuffers5 1024 avgt 10 94.606 ? >>>>>>>>>> 1.522? ns/op >>>>>>>>>> ByteBufferVectorAccess.pollutedBuffers5:?asm 1024 >>>>>>>>>> avgt?????????? NaN >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> BR, >>>>>>>>>> Rado >>>>>>>>>> From: Paul Sandoz >>>>>>>>>> Sent: Friday, August 6, 2021 18:04 >>>>>>>>>> To: Rados?aw Smogura >>>>>>>>>> Cc: panama-dev at openjdk.java.net >>>>>>>>>> Subject: Re: Issues with loop unrolling: better pinned node >>>>>>>>>> >>>>>>>>>> Hi Rado, >>>>>>>>>> >>>>>>>>>> It?s good you are looking at the IR >>>>>>>>>> >>>>>>>>>> Out of curiosity, what happens if you turn off bounds checking >>>>>>>>>> [*]? >>>>>>>>>> >>>>>>>>>> Paul. >>>>>>>>>> >>>>>>>>>> [*] >>>>>>>>>> -Djdk.incubator.vector.VECTOR_ACCESS_OOB_CHECK=0 >>>>>>>>>> >>>>>>>>>> > On Aug 6, 2021, at 8:39 AM, Rados?aw Smogura >>>>>>>>>> wrote: >>>>>>>>>> > >>>>>>>>>> > Hi all, >>>>>>>>>> > >>>>>>>>>> > I've found that even if we get rid of barriers, the loop >>>>>>>>>> can't get unrolled, and not needed code is inside it. >>>>>>>>>> > >>>>>>>>>> > I've found this graph, I wonder if it's most optimal, in a >>>>>>>>>> partiucalry Load of ByteBuffer index / hb is from phi, could >>>>>>>>>> it be attached to initial memory? >>>>>>>>>> > >>>>>>>>>> > Here's a picture >>>>>>>>>> https://urldefense.com/v3/__https://drive.google.com/file/d/1G7ZN0xHOVIVHmZ_5TTIUdm3F30okAzvO/view?usp=sharing__;!!ACWV5N9M2RV99hQ!ceve5Eoh01VSiAxgPOSMpL_oQpz6MJI6KeGEcvULButhjMZGdxMq2SB02arX5hxVkhhZ0w8$ >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> > >>>>>>>>>> [https://urldefense.com/v3/__https://lh6.googleusercontent.com/SKgGZgfVWFpG8w4mWqguLSU4DVfa1MKYPSQhxv8EoX04XzVz8U8Kc4zHP0iwdR26Suc=w1200-h630-p__;!!ACWV5N9M2RV99hQ!ceve5Eoh01VSiAxgPOSMpL_oQpz6MJI6KeGEcvULButhjMZGdxMq2SB02arX5hxVgkskdP0$ >>>>>>>>>> ]>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> > >>>>>>>>> >>>>>>>>>> > >>>>>>>>>> bb_issues.png>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> > >>>>>>>>> >>>>>>>>>> > drive.google.com >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > And sample code >>>>>>>>>> > >>>>>>>>>> > protected void copyMemory(ByteBuffer in, ByteBuffer out) { >>>>>>>>>> >? var limit = SPECIES.loopBound(in.limit()); >>>>>>>>>> >? for (int i=0; i < limit; i += SPECIES.vectorByteSize()) { >>>>>>>>>> >??? final var v = ByteVector.fromByteBuffer(SPECIES, in, i, >>>>>>>>>> ByteOrder.nativeOrder()); >>>>>>>>>> >??? v.intoByteBuffer(out, i, ByteOrder.nativeOrder()); >>>>>>>>>> >? } >>>>>>>>>> > } >>>>>>>>>> > >>>>>>>>>> > Kind regards, >>>>>>>>>> > Rado >>>>>>>>> From paul.sandoz at oracle.com Tue Sep 7 18:07:04 2021 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 7 Sep 2021 18:07:04 +0000 Subject: Arrays.mismatch intrinsic and Vector API comparision In-Reply-To: References: <71444AEA-0386-417D-B6CB-0ABF957E107A@oracle.com> Message-ID: Hi Kartik, Thanks. You can target your PR against https://github.com/openjdk/jdk/ e.g. we recently added another benchmark https://github.com/openjdk/jdk/pull/5234 Paul. > On Sep 4, 2021, at 5:53 AM, Kartik Ohri wrote: > > Hi Paul, > > Thanks for the feedback! I'll add more cases as you suggested and submit a PR. > > Regards, > Kartik > > On Fri, Sep 3, 2021 at 3:41 AM Paul Sandoz wrote: > Hi Kartik, > > Thank you. It is useful. I am glad we are reaching the point where the Vector API is getting competitive with the mismatch stub. > > If you would like to contribute the benchmark I would be happy to review a PR. > We could also measure int, float and long, in addition to small sizes, just above or below the vector length (not dissimilar to a mismatch on the the first or lower index of an array). > When we wrote Arrays.mismatch we were very careful to measure the impact on small array sizes, since that method is also used to support Arrays.equals and we did not want to introduce a performance regression. > > > Some of the difference might be explained by alignment of the arrays, some perhaps due to loop unrolling. > > I think there might be an issue with loop unrolling. It seems too aggressive, resulting larger than necessary nmethod sizes. We should look into that. > > > Unsure if it's possible to to reduce [*]: > > vpcmpeqb %ymm1,%ymm0,%ymm0 > vpxor -0x7ad507d(%rip),%ymm0,%ymm0 > > to: > > vpxor %ymm1,%ymm0,%ymm0 > > Since the latter will not produce a valid mask representation, which could affect later use of the mask value (firstTrue). > > Paul. > > [*] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/macroAssembler_x86.cpp#L3211 > > > On Aug 29, 2021, at 11:36 AM, Kartik Ohri wrote: > > > > Hi! > > > > I have started experimenting with the Vector API recently. Currently, I am > > playing with the API and trying to gauge its potential by comparing its > > performance with vectorized intrinsics implemented inside the JDK. I know > > that Arrays.mismatch has a vectorized intrinsic so I started with it. I was > > able to come up with a simple implementation for it using the Vector API. > > The results of the JMH benchmark look quite promising, the Vector API is > > able to come quite close to the intrinsic. This is awesome!! > > > > The benchmark code is available here > > > > and > > the complete benchmark logs are here > > . > > I also did another run to check the assembly generated which is also > > available here > > . > > It would be nice to get a sanity check on the benchmark before I proceed > > further. > > > > Both versions perform more or less the same (difference is less than 5%, in > > some cases the Vector API even outperforms the intrinsic). There is one > > outlier where the Vector API is almost 35% slower than the intrinsic (when > > prefix is 1 and size is 10000). > > except for when the prefix is 1 i.e. both input arrays are equal. I see > > that the assembly emitted by Vector API > > > > contains a *vpcmpeqb* but the JDK intrinsic > > > > does not. Looking at the implementation > > > > of the intrinsic in the JDK, The AVX 512 version uses *vpcmpeqb* but the > > AVX2 version does not (my machine does not have AVX 512 so it makes that it > > was not emitted in the case of the intrinsic). Secondly, from the assembly > > it seems that the Vector API version was unrolled but the intrinsic was > > not. If I am right, in general loop unrolling is better so the API seems to > > be doing the right thing. Hence, I am not sure why this particular case is > > an outlier. > > > > Further, Is analysing/comparing intrinsics within the JDK to the Vector API > > useful? > > > > Also, any other suggestions regarding contributing to the Project are > > welcome. > > > > Regards, > > Kartik > From paul.sandoz at oracle.com Tue Sep 7 19:39:59 2021 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 7 Sep 2021 19:39:59 +0000 Subject: Vector API Questions In-Reply-To: <4831F458-9418-47AC-9353-17F94882E487@gmail.com> References: <4831F458-9418-47AC-9353-17F94882E487@gmail.com> Message-ID: <2E0D36BF-30A5-4FD7-B914-A14137D33F2D@oracle.com> Hi Scott, Many of the more ?exotic" vector operations (conversions and rearranges) were not optimized in 16, but we made great progress for the soon to be released 17. I wrote a benchmark based on your code and ran it against a build of https://github.com/openjdk/panama-vector/tree/vectorIntrinsics: https://gist.github.com/PaulSandoz/1da0b1fefd177eb4bdcb743b70851059 Benchmark (size) Mode Cnt Score Error Units BufferByteToShort.scalarAbsolute 1024 avgt 10 676.276 ? 2.455 ns/op BufferByteToShort.scalarRelative 1024 avgt 10 1896.754 ? 40.293 ns/op BufferByteToShort.vectorConvert 1024 avgt 10 108.458 ? 0.622 ns/op BufferByteToShort.vectorShuffleMask 1024 avgt 10 154.176 ? 0.592 ns/op BufferByteToShort.vectorShuffleZero 1024 avgt 10 1572.366 ? 8.717 ns/op I wrote this very quickly so I hope I got it right. There is still some work required to optimize shuffles with exceptional indexes, but overall we are making good progress. Paul. > On Sep 5, 2021, at 5:20 PM, Scott Palmer wrote: > > Yes, a shuffle works for the operation I was looking for. Though my attempt at implementing the basic 8 bit -> 16 bit conversion loop in my original email is even slower when I tried a version using a shuffle instead of converting to shorts and shifting. > > My basic loop to convert from bytes to shorts by shifting byte values to the high byte of the short is 70 times faster without using the Vector API in that case! > > I have to wonder if I?m doing something horribly wrong. > > It should be possible for this simple loop: > > void widen(ByteBuffer srcBuff , ByteBuffer dstBuff ) { > while (srcBuff.hasRemaining()) { > dstBuff.putShort((short) (srcBuff.get() << 8)); > } > } > > to go much faster when using vector instructions that operator on 32 bytes at a time. > > But this is 70x slower: > > int si = 0; > int di = 0; > final int loopBound = ByteVector.SPECIES_PREFERRED.loopBound(srcBuff.remaining()); > for (; si < loopBound; si += BYTE_SPECIES_LENGTH) { > ByteVector srcVec = ByteVector.fromByteBuffer(ByteVector.SPECIES_PREFERRED, srcBuff, si, NATIVE_ORDER); > srcVec.rearrange(EXPANDING_SHUFFLE_LO, ZERO).intoByteBuffer(dstBuff, di, NATIVE_ORDER); > di += BYTE_SPECIES_LENGTH; > srcVec.rearrange(EXPANDING_SHUFFLE_HI, ZERO).intoByteBuffer(dstBuff, di, NATIVE_ORDER); > di += BYTE_SPECIES_LENGTH; > } > > > Both vector versions I?ve tried are at least an order of magnitude slower than the scalar code. I?m I doing something wrong? > > Thanks, > > Scott > >> On Sep 5, 2021, at 6:27 PM, John Rose wrote: >> >> I think those are hardware specialized shuffles, right? So try a shuffle. We should try to recognize fixed shuffles that can be handled by special instructions. That?s the basic approach. It doesn?t need a new primitive but maybe some convenience functions and better instruction selection. >> >>> On Sep 5, 2021, at 1:09 PM, Scott Palmer wrote: >>> >>> ?Is this list appropriate for questions involving the Vector API? (I scanned the list at https://mail.openjdk.java.net/mailman/listinfo but didn?t see anything) >>> >>> E.g. questions such as, >>> >>> Are there plans to support operation XXX? >>> >>> I?m looking for something like: https://www.felixcloutier.com/x86/punpcklbw:punpcklwd:punpckldq:punpcklqdq >>> >>> Or performance related queries? >>> >>> I tried to convert this simple operation to use the Vector API (on 2MB source buffers) and the result iI got was 15x slower than this byte-wise loop: >>> >>> void widen(ByteBuffer srcBuff , ByteBuffer dstBuff ) { >>> while (srcBuff.hasRemaining()) { >>> dstBuff.putShort((short) (srcBuff.get() << 8)); >>> } >>> } >>> >>> >>> My attempt using JDK 16 on macOS (Intel) looked like: >>> >>> final int BYTE_PREFERRED_SPECIES_LENGTH = ByteVector.SPECIES_PREFERRED.length(); >>> final int loopBound = ByteVector.SPECIES_PREFERRED.loopBound(srcBuff.remaining()); >>> int si = 0; >>> int di = 0; >>> for (; si < loopBound; si += BYTE_PREFERRED_SPECIES_LENGTH) { >>> ByteVector srcVec = ByteVector.fromByteBuffer(ByteVector.SPECIES_PREFERRED, srcBuff, si, NATIVE_ORDER); >>> srcVec.convert(VectorOperators.B2S, 0) >>> .lanewise(VectorOperators.LSHL, 8) >>> .intoByteBuffer(dstBuff, di, NATIVE_ORDER); >>> di += BYTE_PREFERRED_SPECIES_LENGTH; >>> >>> srcVec.convert(VectorOperators.B2S, 1) >>> .lanewise(VectorOperators.LSHL, 8) >>> .intoByteBuffer(dstBuff, PD_di, NATIVE_ORDER); >>> di += BYTE_PREFERRED_SPECIES_LENGTH; >>> } >>> >>> If this is the wrong place for these kinds of questions, please point me in the right direction. >>> >>> Thanks, >>> >>> Scott > From swpalmer at gmail.com Tue Sep 7 22:47:34 2021 From: swpalmer at gmail.com (Scott Palmer) Date: Tue, 7 Sep 2021 18:47:34 -0400 Subject: Vector API Questions In-Reply-To: <2E0D36BF-30A5-4FD7-B914-A14137D33F2D@oracle.com> References: <4831F458-9418-47AC-9353-17F94882E487@gmail.com> <2E0D36BF-30A5-4FD7-B914-A14137D33F2D@oracle.com> Message-ID: <5892ED34-57E5-4479-B71D-11814AF7EF58@gmail.com> Thanks for the response. I just tried my code with the 17-ea+35 build and the world makes sense again. The vector code is about 10x faster than the simple byte-wise loop. Are there any VM flags that will help me know if I?m using an operation that isn?t optimized? As my algorithms get more complicated a step in the middle may be unoptimized but the faster operations around it may make that harder to detect. Regards, Scott > On Sep 7, 2021, at 3:39 PM, Paul Sandoz wrote: > > Hi Scott, > > Many of the more ?exotic" vector operations (conversions and rearranges) were not optimized in 16, but we made great progress for the soon to be released 17. > > I wrote a benchmark based on your code and ran it against a build of https://github.com/openjdk/panama-vector/tree/vectorIntrinsics: > > https://gist.github.com/PaulSandoz/1da0b1fefd177eb4bdcb743b70851059 > > Benchmark (size) Mode Cnt Score Error Units > BufferByteToShort.scalarAbsolute 1024 avgt 10 676.276 ? 2.455 ns/op > BufferByteToShort.scalarRelative 1024 avgt 10 1896.754 ? 40.293 ns/op > BufferByteToShort.vectorConvert 1024 avgt 10 108.458 ? 0.622 ns/op > BufferByteToShort.vectorShuffleMask 1024 avgt 10 154.176 ? 0.592 ns/op > BufferByteToShort.vectorShuffleZero 1024 avgt 10 1572.366 ? 8.717 ns/op > > I wrote this very quickly so I hope I got it right. > > There is still some work required to optimize shuffles with exceptional indexes, but overall we are making good progress. > > Paul. > >> On Sep 5, 2021, at 5:20 PM, Scott Palmer wrote: >> >> Yes, a shuffle works for the operation I was looking for. Though my attempt at implementing the basic 8 bit -> 16 bit conversion loop in my original email is even slower when I tried a version using a shuffle instead of converting to shorts and shifting. >> >> My basic loop to convert from bytes to shorts by shifting byte values to the high byte of the short is 70 times faster without using the Vector API in that case! >> >> I have to wonder if I?m doing something horribly wrong. >> >> It should be possible for this simple loop: >> >> void widen(ByteBuffer srcBuff , ByteBuffer dstBuff ) { >> while (srcBuff.hasRemaining()) { >> dstBuff.putShort((short) (srcBuff.get() << 8)); >> } >> } >> >> to go much faster when using vector instructions that operator on 32 bytes at a time. >> >> But this is 70x slower: >> >> int si = 0; >> int di = 0; >> final int loopBound = ByteVector.SPECIES_PREFERRED.loopBound(srcBuff.remaining()); >> for (; si < loopBound; si += BYTE_SPECIES_LENGTH) { >> ByteVector srcVec = ByteVector.fromByteBuffer(ByteVector.SPECIES_PREFERRED, srcBuff, si, NATIVE_ORDER); >> srcVec.rearrange(EXPANDING_SHUFFLE_LO, ZERO).intoByteBuffer(dstBuff, di, NATIVE_ORDER); >> di += BYTE_SPECIES_LENGTH; >> srcVec.rearrange(EXPANDING_SHUFFLE_HI, ZERO).intoByteBuffer(dstBuff, di, NATIVE_ORDER); >> di += BYTE_SPECIES_LENGTH; >> } >> >> >> Both vector versions I?ve tried are at least an order of magnitude slower than the scalar code. I?m I doing something wrong? >> >> Thanks, >> >> Scott >> >>> On Sep 5, 2021, at 6:27 PM, John Rose wrote: >>> >>> I think those are hardware specialized shuffles, right? So try a shuffle. We should try to recognize fixed shuffles that can be handled by special instructions. That?s the basic approach. It doesn?t need a new primitive but maybe some convenience functions and better instruction selection. >>> >>>> On Sep 5, 2021, at 1:09 PM, Scott Palmer wrote: >>>> >>>> ?Is this list appropriate for questions involving the Vector API? (I scanned the list at https://mail.openjdk.java.net/mailman/listinfo but didn?t see anything) >>>> >>>> E.g. questions such as, >>>> >>>> Are there plans to support operation XXX? >>>> >>>> I?m looking for something like: https://www.felixcloutier.com/x86/punpcklbw:punpcklwd:punpckldq:punpcklqdq >>>> >>>> Or performance related queries? >>>> >>>> I tried to convert this simple operation to use the Vector API (on 2MB source buffers) and the result iI got was 15x slower than this byte-wise loop: >>>> >>>> void widen(ByteBuffer srcBuff , ByteBuffer dstBuff ) { >>>> while (srcBuff.hasRemaining()) { >>>> dstBuff.putShort((short) (srcBuff.get() << 8)); >>>> } >>>> } >>>> >>>> >>>> My attempt using JDK 16 on macOS (Intel) looked like: >>>> >>>> final int BYTE_PREFERRED_SPECIES_LENGTH = ByteVector.SPECIES_PREFERRED.length(); >>>> final int loopBound = ByteVector.SPECIES_PREFERRED.loopBound(srcBuff.remaining()); >>>> int si = 0; >>>> int di = 0; >>>> for (; si < loopBound; si += BYTE_PREFERRED_SPECIES_LENGTH) { >>>> ByteVector srcVec = ByteVector.fromByteBuffer(ByteVector.SPECIES_PREFERRED, srcBuff, si, NATIVE_ORDER); >>>> srcVec.convert(VectorOperators.B2S, 0) >>>> .lanewise(VectorOperators.LSHL, 8) >>>> .intoByteBuffer(dstBuff, di, NATIVE_ORDER); >>>> di += BYTE_PREFERRED_SPECIES_LENGTH; >>>> >>>> srcVec.convert(VectorOperators.B2S, 1) >>>> .lanewise(VectorOperators.LSHL, 8) >>>> .intoByteBuffer(dstBuff, PD_di, NATIVE_ORDER); >>>> di += BYTE_PREFERRED_SPECIES_LENGTH; >>>> } >>>> >>>> If this is the wrong place for these kinds of questions, please point me in the right direction. >>>> >>>> Thanks, >>>> >>>> Scott >> > From njian at openjdk.java.net Wed Sep 8 01:19:30 2021 From: njian at openjdk.java.net (Ningsheng Jian) Date: Wed, 8 Sep 2021 01:19:30 GMT Subject: git: openjdk/panama-vector: vectorIntrinsics+mask: 8273367: [Vector API] Fix a regression of rearrange intrinsic after JDK-8272479 Message-ID: Changeset: d65687c0 Author: Jie Fu Committer: Ningsheng Jian Date: 2021-09-08 01:18:54 +0000 URL: https://git.openjdk.java.net/panama-vector/commit/d65687c0fb62f4b64897b928fdf22dc97e985bc9 8273367: [Vector API] Fix a regression of rearrange intrinsic after JDK-8272479 Reviewed-by: njian ! src/hotspot/share/opto/vectorIntrinsics.cpp From jiefu at openjdk.java.net Wed Sep 8 01:23:21 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Wed, 8 Sep 2021 01:23:21 GMT Subject: [vectorIntrinsics+mask] RFR: 8273367: [Vector API] Fix a regression of rearrange intrinsic after JDK-8272479 In-Reply-To: References: Message-ID: On Mon, 6 Sep 2021 07:58:37 GMT, Ningsheng Jian wrote: >> Hi all, >> >> After JDK-8272479, the following crash was observed on x86 with `-ea -esa -Xcomp -XX:CompileThreshold=100` >> >> >> test Double256VectorTests.RearrangeDouble256VectorTests(double[-i * 5], shuffle[random]): success >> test Double256VectorTests.RearrangeDouble256VectorTests(double[i * 5], shuffle[random]): success >> test Double256VectorTests.RearrangeDouble256VectorTests(double[i + 1], shuffle[random]): success >> test Double256VectorTests.RearrangeDouble256VectorTests(double[cornerCaseValue(i)], shuffle[random]): success >> o114 ReplicateD === _ o73 [[o340 ]] #vectory[4]:{double} >> >> --N: o114 ReplicateD === _ o73 [[o340 ]] #vectory[4]:{double} >> >> --N: o73 ConI === o0 [[o166 o173 o114 ]] #int:0 >> IMMI 10 IMMI >> IMMI_0 0 IMMI_0 >> IMMI2 0 IMMI2 >> IMMU7 5 IMMU7 >> IMMI8 5 IMMI8 >> IMMU8 5 IMMU8 >> IMMI16 10 IMMI16 >> IMMU31 0 IMMU31 >> RREGI 50 loadConI0 >> RAX_REGI 50 loadConI0 >> RBX_REGI 50 loadConI0 >> RCX_REGI 50 loadConI0 >> RDX_REGI 50 loadConI0 >> RDI_REGI 50 loadConI0 >> NO_RAX_RDX_REGI 50 loadConI0 >> STACKSLOTI 150 storeSSI >> >> >> This is because the type of broadcasted ZERO is incorrect. >> >> Other affected tests include >> >> jdk/incubator/vector/DoubleMaxVectorTests.java >> jdk/incubator/vector/Float128VectorTests.java >> jdk/incubator/vector/Float256VectorTests.java >> jdk/incubator/vector/FloatMaxVectorTests.java >> jdk/incubator/vector/Long256VectorTests.java >> jdk/incubator/vector/LongMaxVectorTests.java >> >> >> Let's fix it. >> >> Thanks. >> Best regards, >> Jie > > Marked as reviewed by njian (Committer). Thanks @nsjian for your sponsoring. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/120 From jiefu at openjdk.java.net Wed Sep 8 01:23:22 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Wed, 8 Sep 2021 01:23:22 GMT Subject: [vectorIntrinsics+mask] Integrated: 8273367: [Vector API] Fix a regression of rearrange intrinsic after JDK-8272479 In-Reply-To: References: Message-ID: On Mon, 6 Sep 2021 02:43:48 GMT, Jie Fu wrote: > Hi all, > > After JDK-8272479, the following crash was observed on x86 with `-ea -esa -Xcomp -XX:CompileThreshold=100` > > > test Double256VectorTests.RearrangeDouble256VectorTests(double[-i * 5], shuffle[random]): success > test Double256VectorTests.RearrangeDouble256VectorTests(double[i * 5], shuffle[random]): success > test Double256VectorTests.RearrangeDouble256VectorTests(double[i + 1], shuffle[random]): success > test Double256VectorTests.RearrangeDouble256VectorTests(double[cornerCaseValue(i)], shuffle[random]): success > o114 ReplicateD === _ o73 [[o340 ]] #vectory[4]:{double} > > --N: o114 ReplicateD === _ o73 [[o340 ]] #vectory[4]:{double} > > --N: o73 ConI === o0 [[o166 o173 o114 ]] #int:0 > IMMI 10 IMMI > IMMI_0 0 IMMI_0 > IMMI2 0 IMMI2 > IMMU7 5 IMMU7 > IMMI8 5 IMMI8 > IMMU8 5 IMMU8 > IMMI16 10 IMMI16 > IMMU31 0 IMMU31 > RREGI 50 loadConI0 > RAX_REGI 50 loadConI0 > RBX_REGI 50 loadConI0 > RCX_REGI 50 loadConI0 > RDX_REGI 50 loadConI0 > RDI_REGI 50 loadConI0 > NO_RAX_RDX_REGI 50 loadConI0 > STACKSLOTI 150 storeSSI > > > This is because the type of broadcasted ZERO is incorrect. > > Other affected tests include > > jdk/incubator/vector/DoubleMaxVectorTests.java > jdk/incubator/vector/Float128VectorTests.java > jdk/incubator/vector/Float256VectorTests.java > jdk/incubator/vector/FloatMaxVectorTests.java > jdk/incubator/vector/Long256VectorTests.java > jdk/incubator/vector/LongMaxVectorTests.java > > > Let's fix it. > > Thanks. > Best regards, > Jie This pull request has now been integrated. Changeset: d65687c0 Author: Jie Fu Committer: Ningsheng Jian URL: https://git.openjdk.java.net/panama-vector/commit/d65687c0fb62f4b64897b928fdf22dc97e985bc9 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8273367: [Vector API] Fix a regression of rearrange intrinsic after JDK-8272479 Reviewed-by: njian ------------- PR: https://git.openjdk.java.net/panama-vector/pull/120 From jbhateja at openjdk.java.net Wed Sep 8 06:53:16 2021 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Wed, 8 Sep 2021 06:53:16 GMT Subject: [vectorIntrinsics+mask] RFR: 8273406: Optimize various masked vector operations for AVX512 target. In-Reply-To: <6kCpmxefYaZUAbKSS65LzJwwiLMTp4IR0KKi53SSVD0=.c11e2264-6168-4204-881a-42ecb26992b9@github.com> References: <6kCpmxefYaZUAbKSS65LzJwwiLMTp4IR0KKi53SSVD0=.c11e2264-6168-4204-881a-42ecb26992b9@github.com> Message-ID: On Tue, 7 Sep 2021 17:43:08 GMT, Paul Sandoz wrote: > @jatin-bhateja is [JDK-8262356](https://bugs.openjdk.java.net/browse/JDK-8262356) mostly a duplicate of the sub-task [JDK-8272359](https://bugs.openjdk.java.net/browse/JDK-8272359)? Yes, I have linked JDK-8262356 to sub-task JDK-8272359. Also linked other related issues with JDK-8262356 ------------- PR: https://git.openjdk.java.net/panama-vector/pull/122 From jzhu at openjdk.java.net Wed Sep 8 07:03:18 2021 From: jzhu at openjdk.java.net (Joshua Zhu) Date: Wed, 8 Sep 2021 07:03:18 GMT Subject: [vectorIntrinsics+mask] RFR: 8273057: [vector] New VectorAPI "SelectiveStore" In-Reply-To: <23BA299B-BA4A-4607-AF49-DD20003BBE2A@oracle.com> References: <23BA299B-BA4A-4607-AF49-DD20003BBE2A@oracle.com> Message-ID: <-eE-WLIXMacbrSVZtlGZBVia1VpXPejcL4HxUIdMvyI=.fee8bc80-d837-41d4-ac54-e3731d27eac4@github.com> On Tue, 7 Sep 2021 16:35:19 GMT, Paul Sandoz wrote: > Would it be possible for you to target this work to a new branch? e.g. vectorIntrinsics+compress. > > I want to avoid complicating review and integration of the masking work for JEP 417. We are close to merging vectorIntrinsics+mask into vectorIntrinsics and then starting reviews of the masking support. Yes, of course. Thank you, Paul. Hence could you please help me checkout a new branch based on "vectorIntrinsics+mask" or "vectorIntrinsics" after merging? > It may be possible that compress/expand become part of JEP 417, if we can get it ready in time. If so I can update the JEP accordingly and help do CSRs. Otherwise, we can target to the next round of incubation. I'm fine with the plan to place compress/expand in the next round of incubation. I'm afraid I cannot catch the last bus before the review of masking support while I have other works at hand. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/115 From jzhu at openjdk.java.net Wed Sep 8 08:55:28 2021 From: jzhu at openjdk.java.net (Joshua Zhu) Date: Wed, 8 Sep 2021 08:55:28 GMT Subject: [vectorIntrinsics+mask] RFR: 8273057: [vector] New VectorAPI "SelectiveStore" In-Reply-To: References: Message-ID: <78fFUAtJpSkwVqjUuq8iisR2YWDKWZNS6UFbrgc65ro=.1f03fe57-bd0f-47f1-a73a-33184f41df5c@github.com> On Tue, 7 Sep 2021 15:39:07 GMT, Jatin Bhateja wrote: > > > In this use case its difficult to infer COMPRESSION through Auto-vectorizer though we made attempts in past to infer complex loop patterns for VNNI instruction. > > > > Could you elaborate on it please? I do not follow this. > > I meant auto-vectorizing following loop which mimic compression semantics could be tricky if its difficult to ascertain the independence between memory references. Like in following case 'j' could be a middle index in array and thus if the distance between memory references is less than chosen vector width it may result into incorrect overwrite. > > ``` > for ( int i = 0; i < n ; i++ ) { > if ( mask[i] > 1 ) { > a[j++] = a[i]; > } > } > ``` Agree. I think current SWPointer compare (used to detect possible same address) does not apply to this pattern. In this case, besides SWPointer comparison, "j" cannot be inferred by induction varaible "i" is more critical for auto-vectorization. Do you have plan to support masked operations in SLP optimization? ------------- PR: https://git.openjdk.java.net/panama-vector/pull/115 From sundar at openjdk.java.net Wed Sep 8 11:45:56 2021 From: sundar at openjdk.java.net (Athijegannathan Sundararajan) Date: Wed, 8 Sep 2021 11:45:56 GMT Subject: [foreign-jextract] RFR: 8273382: jextract should generete alias layout for pointer typedefs Message-ID: <368IzOqnQI3orxgtjSZnVy1O2NCWbnlI9xoRqjmJXUw=.c58013cf-eb03-4ac2-ac84-93d3b35890f0@github.com> Generating C_POINTER layout variables for pointer typedefs in the header ------------- Commit messages: - whitespace removed in TypeImpl.java - 8273382: jextract should generete alias layout for pointer typedefs Changes: https://git.openjdk.java.net/panama-foreign/pull/575/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=575&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273382 Stats: 78 lines in 6 files changed: 73 ins; 1 del; 4 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/575.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/575/head:pull/575 PR: https://git.openjdk.java.net/panama-foreign/pull/575 From mcimadamore at openjdk.java.net Wed Sep 8 12:39:28 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 8 Sep 2021 12:39:28 GMT Subject: [foreign-jextract] RFR: 8273382: jextract should generete alias layout for pointer typedefs In-Reply-To: <368IzOqnQI3orxgtjSZnVy1O2NCWbnlI9xoRqjmJXUw=.c58013cf-eb03-4ac2-ac84-93d3b35890f0@github.com> References: <368IzOqnQI3orxgtjSZnVy1O2NCWbnlI9xoRqjmJXUw=.c58013cf-eb03-4ac2-ac84-93d3b35890f0@github.com> Message-ID: On Wed, 8 Sep 2021 10:11:57 GMT, Athijegannathan Sundararajan wrote: > Generating C_POINTER layout variables for pointer typedefs in the header Very nice! ------------- Marked as reviewed by mcimadamore (Committer). PR: https://git.openjdk.java.net/panama-foreign/pull/575 From sundar at openjdk.java.net Wed Sep 8 12:47:24 2021 From: sundar at openjdk.java.net (Athijegannathan Sundararajan) Date: Wed, 8 Sep 2021 12:47:24 GMT Subject: [foreign-jextract] Integrated: 8273382: jextract should generete alias layout for pointer typedefs In-Reply-To: <368IzOqnQI3orxgtjSZnVy1O2NCWbnlI9xoRqjmJXUw=.c58013cf-eb03-4ac2-ac84-93d3b35890f0@github.com> References: <368IzOqnQI3orxgtjSZnVy1O2NCWbnlI9xoRqjmJXUw=.c58013cf-eb03-4ac2-ac84-93d3b35890f0@github.com> Message-ID: On Wed, 8 Sep 2021 10:11:57 GMT, Athijegannathan Sundararajan wrote: > Generating C_POINTER layout variables for pointer typedefs in the header This pull request has now been integrated. Changeset: 2142785e Author: Athijegannathan Sundararajan URL: https://git.openjdk.java.net/panama-foreign/commit/2142785ee46541c85bb11713479ea76916c392f9 Stats: 78 lines in 6 files changed: 73 ins; 1 del; 4 mod 8273382: jextract should generete alias layout for pointer typedefs Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/575 From maurizio.cimadamore at oracle.com Wed Sep 8 13:28:47 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 8 Sep 2021 14:28:47 +0100 Subject: How To Create Array of Structs? In-Reply-To: References: <0c6361f3-2879-02dd-0b26-e26a5b268602@oracle.com> <4bb60084-2958-45f9-511d-638b85770040@oracle.com> <3b5cdab7-e807-a728-7476-6d6d349c9fe2@oracle.com> Message-ID: <75cf4b45-b1af-b1de-c96c-cb1f312f89e7@oracle.com> This fix for this issue has been integrated. If you are able to build the Panama repo manually, you should be able to re-extract Vulkan, and hopefully you should see the layout for VkSemaphore in there. Cheers Maurizio On 06/09/2021 13:03, Sundararajan Athijegannathan wrote: > Filed: https://bugs.openjdk.java.net/browse/JDK-8273382 > > > -Sundar > ------------------------------------------------------------------------ > *From:* panama-dev on behalf of > Sundararajan Athijegannathan > *Sent:* 06 September 2021 10:20 > *To:* Maurizio Cimadamore ; Michael > Ennen ; Jorn Vernee > *Cc:* panama-dev at openjdk.java.net > *Subject:* Re: How To Create Array of Structs? > Hi, > > jextract does not seem to generate layout for any pointer type. Only > non-point typedefs are handled. > > > Example: > > > typedef int* intptr; > > > > struct Point { > > ??? int x, y; > > }; > > > typedef struct Point* pointptr; > > > Nothing generated for both intptr and pointptr; > > > -Sundar > ________________________________ > From: panama-dev on behalf of > Maurizio Cimadamore > Sent: 04 September 2021 03:42 > To: Michael Ennen ; Jorn Vernee > > Cc: panama-dev at openjdk.java.net > Subject: Re: How To Create Array of Structs? > > Hi Michael, > I don't think the problem is lack of support for function-like macro. > > Yes, VK_DEFINE_NON_DISPATCHABLE_HANDLE is a function-like macro, but > this declaration: > > ``` > VK_DEFINE_NON_DISPATCHABLE_HANDLE(VkSemaphore) > ``` > > is contained in the header, and preprocessed, so libclang sees something > like what you describe: > > ``` > typedef struct VkSemaphore_T *VkSemaphore; > ``` > > The only problem is that jextract is (because of an issue we're > investigating) not generating the layout for that typedef. > > That said, layout or no layout, things are not too different - for all > intents and purposes, you can assume that the layout of the handle is > just C_POINTER. > > But you are never supposed to _dereference_ that handle - instead you > are supposed to use other functions to create and use semaphores, such as: > > https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/vkSignalSemaphore.html > > https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/vkWaitSemaphores.html > > https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/vkCreateSemaphore.html > > https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/vkDestroySemaphore.html > > > etc. > > In other words, inside the handle there's an opaque pointer to memory > that is managed by the vulkan library. You are not supposed to know > what's inside that memory. Nor you need to know what the size of > VkSemaphore_T is. > > So, if you want to create an array of N semaphores, you just do this > > ``` > MemorySegment semaphores = allocator.allocateArray(C_POINTER, N); > ``` > > Then you will probably have to initialize the pointers in the array, > possibly using vkCreateSemaphore. As Radu pointed out, the > vkCreateSemaphore API wants you to pass a pointer to a VkSemaphore > (which is already a pointer). So, something like this: > > ``` > for (int i = 0 ; i < N ; i++) { > ???? vkCreateSemaphore( ... , semaphores.asSlice(C_POINTER.byteSize() * > i) , ...); > } > ``` > > This effectively iterates over the semaphore array, gets a slice of the > "semaphores" array which starts at the element which needs to be > initialized (hence you get a pointer to a VkSemaphore - e.g. a pointer > to a pointer), and passes this slice pointer to the vkCreateSemaphore > routine. By the time the routine finishes, it should have written > something in the array element (the opaque handle). > > Hope this helps. > > Maurizio > > > > On 03/09/2021 22:50, Michael Ennen wrote: > > Let me try and expand upon what I was attempting to communicate > yesterday: > > > > I know that jextract does not currently support function-like macros > > so the handles like VkSemaphore are not exposed. > > > > That's why I tried to first declare it (the array of VkSemaphores) as > > a pointer to a pointer. > > > > But then I cannot get the size of VkSemaphore (really VkSemaphore_T) > > so I am unsure how to use the technique you described which does work > > in the case > > of the VkPipelineShaderStageCreateInfo struct - because it is not an > > "opaque" handle. Vulkan uses these a lot, things like VkInstance, > > VkDevice, etc. Specifically: > > > > VkSemaphore is defined by this macro: > > > > VK_DEFINE_NON_DISPATCHABLE_HANDLE(VkSemaphore) > > > > Which is how Vulkan does opaque handles (so one cannot inspect the > > contents of the VkSemaphore struct and/or rely on it). > > > > If jextract did support function-like macros then it would expand to > > the typedef: > > > > typedef struct VkSemaphore_T *VkSemaphore; > > > > and then one could possibly just do VkSemaphore.$LAYOUT() ? Or even > > still that may not work because of the "opaque"ness. > > > > Thanks for any assistance. > > > > On Thu, Sep 2, 2021 at 11:16 AM Michael Ennen > >> wrote: > > > >???? Quick question that is now happening while trying to replicate the > >???? fix when I don't have an explicit struct handle like in the case > >???? of VkSemaphore: > > > > > https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VkSemaphore.html > > >???? > > > > > >???? For those types I don't have a struct layout to work with so I > >???? have been just declaring a double pointer: > > > >???? var pVkPipeline = > > SegmentAllocator.ofScope(scope).allocate(C_POINTER.byteSize()); > > > >???? and then using MemoryAccess.getAddress(pVkPipeline). > > > >???? So in this case how can I create an array of VkSemaphore structs > >???? without knowing anything about the struct (it is an opaque handle?). > > > >???? Hope that makes sense. > > > >???? On Thu, Sep 2, 2021 at 11:06 AM Michael Ennen > >???? >> wrote: > > > >???????? Jorn, > > > >???????? Thank you so much - that was exactly what I was looking for. I > >???????? don't know why I had such trouble trying to create an array of > >???????? structs rather than an array of points to structs. > > > >???????? Thank you both. > > > >???????? On Thu, Sep 2, 2021 at 4:54 AM Jorn Vernee > >???????? >> wrote: > > > >???????????? Additionally, it looks like you're allocating an array of > >???????????? pointers for > >???????????? pStages, and it looks like the API expects an array of > >???????????? structs. > > > >???????????? Instead of allocating the different > >???????????? VkPipelineShaderStageCreateInfo > >???????????? individually, you should allocate the array of struct > >???????????? upfront, and then > >???????????? fill in the different structs in-place. > > > >???????????? Like: > > > >???????????? diff --git a/src/main/java/com/brcolow/game/Vulkan.java > > b/src/main/java/com/brcolow/game/Vulkan.java > >???????????? index f0cd278..520513b 100644 > >???????????? --- a/src/main/java/com/brcolow/game/Vulkan.java > >???????????? +++ b/src/main/java/com/brcolow/game/Vulkan.java > >???????????? @@ -429,17 +429,17 @@ public class Vulkan { > >?????????????????????????? var pVertShaderModule = > > getShaderModule(MemoryAccess.getAddress(pVkDevice), > >???????????? vertShaderBytes, scope); > >?????????????????????????? var pFragShaderModule = > > getShaderModule(MemoryAccess.getAddress(pVkDevice), > >???????????? fragShaderBytes, scope); > > > >???????????? -??????????? var pVertShaderStageInfo = > > VkPipelineShaderStageCreateInfo.allocate(scope); > >???????????? - > > VkPipelineShaderStageCreateInfo.sType$set(pVertShaderStageInfo, > > > > vulkan_h.VK_STRUCTURE_TYPE_PIPELINE_SHADER_STAGE_CREATE_INFO()); > >???????????? - > > VkPipelineShaderStageCreateInfo.stage$set(pVertShaderStageInfo, > > > >???????????? vulkan_h.VK_SHADER_STAGE_VERTEX_BIT()); > >???????????? - > > VkPipelineShaderStageCreateInfo.module$set(pVertShaderStageInfo, > > > > MemoryAccess.getAddress(pVertShaderModule)); > >???????????? - > > VkPipelineShaderStageCreateInfo.pName$set(pVertShaderStageInfo, > > > >???????????? CLinker.toCString("main", scope).address()); > >???????????? - > >???????????? -??????????? var pFragShaderStageInfo = > > VkPipelineShaderStageCreateInfo.allocate(scope); > >???????????? - > > VkPipelineShaderStageCreateInfo.sType$set(pFragShaderStageInfo, > > > > vulkan_h.VK_STRUCTURE_TYPE_PIPELINE_SHADER_STAGE_CREATE_INFO()); > >???????????? - > > VkPipelineShaderStageCreateInfo.stage$set(pFragShaderStageInfo, > > > >???????????? vulkan_h.VK_SHADER_STAGE_FRAGMENT_BIT()); > >???????????? - > > VkPipelineShaderStageCreateInfo.module$set(pFragShaderStageInfo, > > > > MemoryAccess.getAddress(pFragShaderModule)); > >???????????? - > > VkPipelineShaderStageCreateInfo.pName$set(pFragShaderStageInfo, > > > >???????????? CLinker.toCString("main", scope).address()); > >???????????? +??????????? MemorySegment pStages = > > > SegmentAllocator.ofScope(scope).allocateArray(VkPipelineShaderStageCreateInfo.$LAYOUT(), > > > >???????????? 2); > >???????????? + > >???????????? + VkPipelineShaderStageCreateInfo.sType$set(pStages, 0, > > vulkan_h.VK_STRUCTURE_TYPE_PIPELINE_SHADER_STAGE_CREATE_INFO()); > >???????????? + VkPipelineShaderStageCreateInfo.stage$set(pStages, 0, > >???????????? vulkan_h.VK_SHADER_STAGE_VERTEX_BIT()); > >???????????? + VkPipelineShaderStageCreateInfo.module$set(pStages, 0, > > MemoryAccess.getAddress(pVertShaderModule)); > >???????????? + VkPipelineShaderStageCreateInfo.pName$set(pStages, 0, > >???????????? CLinker.toCString("main", scope).address()); > >???????????? + > >???????????? + VkPipelineShaderStageCreateInfo.sType$set(pStages, 1, > > vulkan_h.VK_STRUCTURE_TYPE_PIPELINE_SHADER_STAGE_CREATE_INFO()); > >???????????? + VkPipelineShaderStageCreateInfo.stage$set(pStages, 1, > >???????????? vulkan_h.VK_SHADER_STAGE_FRAGMENT_BIT()); > >???????????? + VkPipelineShaderStageCreateInfo.module$set(pStages, 1, > > MemoryAccess.getAddress(pFragShaderModule)); > >???????????? + VkPipelineShaderStageCreateInfo.pName$set(pStages, 1, > >???????????? CLinker.toCString("main", scope).address()); > > > >?????????????????????????? var pVertexInputStateInfo = > > VkPipelineVertexInputStateCreateInfo.allocate(scope); > > VkPipelineVertexInputStateCreateInfo.sType$set(pVertexInputStateInfo, > > > > vulkan_h.VK_STRUCTURE_TYPE_PIPELINE_VERTEX_INPUT_STATE_CREATE_INFO()); > >???????????? @@ -581,16 +581,14 @@ public class Vulkan { > >?????????????????????????? // If we change stageCount to 2 we get a > >???????????? crash.... > >?????????????????????????? // I think we are creating the pStages array > >???????????? incorrectly. > >???????????? This is also manifesting further down when trying > >?????????????????????????? // to create arrays pWaitSemaphores, > >???????????? pSignalSemaphores, etc. > >???????????? - > > VkGraphicsPipelineCreateInfo.stageCount$set(pPipelineCreateInfo, > >???????????? 1); > >???????????? -??????????? MemorySegment pStages = > > SegmentAllocator.ofScope(scope).allocateArray(C_POINTER, > >???????????? new Addressable[]{ > >???????????? - pVertShaderStageInfo, > >???????????? pFragShaderStageInfo}); > >???????????? -??????????? System.out.println("pStages: " + pStages); > >???????????? - System.out.println("pStages[0]: " + > > > VkPipelineShaderStageCreateInfo.ofAddress(MemoryAccess.getAddressAtIndex(pStages, > > > >???????????? 0), scope)); > >???????????? - System.out.println("pStages[0].sType: " + > > > VkPipelineShaderStageCreateInfo.sType$get(VkPipelineShaderStageCreateInfo.ofAddress(MemoryAccess.getAddressAtIndex(pStages, > > > >???????????? 0), scope))); > >???????????? - System.out.println("pStages[1]: " + > > > VkPipelineShaderStageCreateInfo.ofAddress(MemoryAccess.getAddressAtIndex(pStages, > > > >???????????? 1), scope)); > >???????????? - System.out.println("pStages[1].sType: " + > > > VkPipelineShaderStageCreateInfo.sType$get(VkPipelineShaderStageCreateInfo.ofAddress(MemoryAccess.getAddressAtIndex(pStages, > > > >???????????? 1), scope))); > >???????????? - > >???????????? - > > VkGraphicsPipelineCreateInfo.pStages$set(pPipelineCreateInfo, > >???????????? MemoryAccess.getAddress(pStages)); > >???????????? + > > VkGraphicsPipelineCreateInfo.stageCount$set(pPipelineCreateInfo, > >???????????? 2); > >???????????? +??????????? System.out.println("pStages: " + > >???????????? pStages.address()); > >???????????? + System.out.println("pStages[0]: " + > >???????????? pStages.asSlice(0, > > VkPipelineShaderStageCreateInfo.$LAYOUT().byteSize())); > >???????????? + System.out.println("pStages[0].sType: " + > > VkPipelineShaderStageCreateInfo.sType$get(pStages, 0)); > >???????????? + System.out.println("pStages[1]: " + > > pStages.asSlice(VkPipelineShaderStageCreateInfo.$LAYOUT().byteSize(), > > > > VkPipelineShaderStageCreateInfo.$LAYOUT().byteSize())); > >???????????? + System.out.println("pStages[1].sType: " + > > VkPipelineShaderStageCreateInfo.sType$get(pStages, 1)); > >???????????? + > >???????????? + > > VkGraphicsPipelineCreateInfo.pStages$set(pPipelineCreateInfo, > >???????????? pStages.address()); > > VkGraphicsPipelineCreateInfo.pVertexInputState$set(pPipelineCreateInfo, > > > >???????????? pVertexInputStateInfo.address()); > > > VkGraphicsPipelineCreateInfo.pInputAssemblyState$set(pPipelineCreateInfo, > > > > pPipelineInputAssemblyStateInfo.address()); > > VkGraphicsPipelineCreateInfo.pViewportState$set(pPipelineCreateInfo, > > > >???????????? pPipelineViewportStateInfo.address()); > > > >???????????? HTH, > >???????????? Jorn > > > >???????????? On 02/09/2021 11:56, Maurizio Cimadamore wrote: > >???????????? > Hi Michael, > >???????????? > very interesting experiments - thanks for reaching out. > >???????????? > > >???????????? > Eyeballing your code, I zoomed into this line: > >???????????? > > >???????????? > > > > https://github.com/brcolow/java-vulkan/blob/master/src/main/java/com/brcolow/game/Vulkan.java#L593 > > >???????????? > > > > > >???????????? > > >???????????? > > >???????????? > Here you want to set the `pStages` pointer, a pointer to > >???????????? a memory > >???????????? > region which presumably has to contain exactly > >???????????? `stageCount` structs of > >???????????? > type `VkPipelineShaderStageCreateInfo`. > >???????????? > > >???????????? > I believe there's an extra getAddress in there; this: > >???????????? > > >???????????? > ``` > >???????????? > > > VkGraphicsPipelineCreateInfo.pStages$set(pPipelineCreateInfo, > >???????????? > MemoryAccess.getAddress(pStages)); > >???????????? > ``` > >???????????? > > >???????????? > should be: > >???????????? > > >???????????? > ``` > >???????????? > > > VkGraphicsPipelineCreateInfo.pStages$set(pPipelineCreateInfo, > >???????????? pStages); > >???????????? > ``` > >???????????? > > >???????????? > That is, you want to pass the pointer to the `pStages` > >???????????? region you just > >???????????? > created, so that Vulkan will be able to see all > >???????????? elements. If you call > >???????????? > "MemoryAccess::getAddress" your code will read the first > >???????????? 64 bits from > >???????????? > the `pStages` region, turn those into a MemoryAddress, > >???????????? and set that > >???????????? > into the enclosing `pPipelineCreateInfo` struct. Which I > >???????????? don't think > >???????????? > is what you want? > >???????????? > > >???????????? > Let me know if this works. > >???????????? > > >???????????? > Cheers > >???????????? > Maurizio > >???????????? > > >???????????? > > >???????????? > On 02/09/2021 06:35, Michael Ennen wrote: > >???????????? >> I have been doing more exploring with the > >???????????? panama-foreign, ffi, and > >???????????? >> jextract > >???????????? >> branches - this time messing around with seeing if I > >???????????? can get a rainbow > >???????????? >> triangle to be rendered on the screen with Vulkan. > >???????????? >> > >???????????? >> I am really close. There is one problem I am having > >???????????? which is how to > >???????????? >> create > >???????????? >> an array of structs? > >???????????? >> > >???????????? >> See this, for example: > >???????????? >> > >???????????? >> > > > https://github.com/brcolow/java-vulkan/blob/master/src/main/java/com/brcolow/game/Vulkan.java#L581 > > >???????????? > > > > > >???????????? >> > >???????????? >> > >???????????? >> If I set the stageCount to 2, then I get a validation > >???????????? exception about > >???????????? >> the > >???????????? >> second shader module having bogus values. I believe > >???????????? this is caused by me > >???????????? >> creating the array of structs incorrectly. > >???????????? >> > >???????????? >> I am trying to set the pStages element of this struct: > >???????????? >> > > > https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VkGraphicsPipelineCreateInfo.html > > >???????????? > > > > > >???????????? >> > >???????????? >> > >???????????? >> to an array containing pVertShaderStageInfo and > >???????????? pFragShaderStageInfo. > >???????????? >> > >???????????? >> My attempt (I have tried other ways that also fail) to > >???????????? do that is: > >???????????? >> > >???????????? >> MemorySegment pStages = > > SegmentAllocator.ofScope(scope).allocateArray( > >???????????? >> C_POINTER, new Addressable[]{ > >???????????? >> pVertShaderStageInfo, pFragShaderStageInfo}); > >???????????? >> > > VkGraphicsPipelineCreateInfo.pStages$set(pPipelineCreateInfo, > >???????????? >> MemoryAccess.getAddress(pStages)); > >???????????? >> > >???????????? >> > >???????????? >> If anyone could assist me with the proper way to > create the > >???????????? >> VkPipelineShaderStageCreateInfo* array containing > >???????????? >> pVertShaderStageInfoand > >???????????? >> pFragShaderStageInfo - it would be greatly appreciated! > >???????????? >> > > > > > > > >???????? -- > >???????? Michael Ennen > > > > > > > >???? -- > >???? Michael Ennen > > > > > > > > -- > > Michael Ennen From paul.sandoz at oracle.com Wed Sep 8 16:30:06 2021 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 8 Sep 2021 16:30:06 +0000 Subject: Vector API Questions In-Reply-To: <5892ED34-57E5-4479-B71D-11814AF7EF58@gmail.com> References: <4831F458-9418-47AC-9353-17F94882E487@gmail.com> <2E0D36BF-30A5-4FD7-B914-A14137D33F2D@oracle.com> <5892ED34-57E5-4479-B71D-11814AF7EF58@gmail.com> Message-ID: <2254A93C-B131-48F5-BA66-AD0B5966B4C7@oracle.com> The approach I often use is JMH with the perfasm or dtraceasm profiling option. If you are running a debug build you can use -XX:+TraceNewVectors or -XX:+PrintIntrinsics (the latter will show failures to make intrinsic vector operations). Ideally developers should not need to ask the question you are asking, assuming hardware support. But it's a common one because we are stilling working on the implementation, filling in the performance gaps (apart of optimizing vector operations we need to look at inlining and vector calling conventions). In the absence of hardware support it would be helpful if we could somehow more reliably inform. Paul. > On Sep 7, 2021, at 3:47 PM, Scott Palmer wrote: > > Thanks for the response. I just tried my code with the 17-ea+35 build and the world makes sense again. The vector code is about 10x faster than the simple byte-wise loop. > > Are there any VM flags that will help me know if I?m using an operation that isn?t optimized? As my algorithms get more complicated a step in the middle may be unoptimized but the faster operations around it may make that harder to detect. > > Regards, > > Scott > > >> On Sep 7, 2021, at 3:39 PM, Paul Sandoz wrote: >> >> Hi Scott, >> >> Many of the more ?exotic" vector operations (conversions and rearranges) were not optimized in 16, but we made great progress for the soon to be released 17. >> >> I wrote a benchmark based on your code and ran it against a build of https://urldefense.com/v3/__https://github.com/openjdk/panama-vector/tree/vectorIntrinsics__;!!ACWV5N9M2RV99hQ!dqqvOA1SwTJDru_FwfrA5tnvu69RLnL0RxW-ZSlceWn0P4Gk6XIjlOmEvhUMudTshg$ : >> >> https://urldefense.com/v3/__https://gist.github.com/PaulSandoz/1da0b1fefd177eb4bdcb743b70851059__;!!ACWV5N9M2RV99hQ!dqqvOA1SwTJDru_FwfrA5tnvu69RLnL0RxW-ZSlceWn0P4Gk6XIjlOmEvhVF1GOgbQ$ >> >> Benchmark (size) Mode Cnt Score Error Units >> BufferByteToShort.scalarAbsolute 1024 avgt 10 676.276 ? 2.455 ns/op >> BufferByteToShort.scalarRelative 1024 avgt 10 1896.754 ? 40.293 ns/op >> BufferByteToShort.vectorConvert 1024 avgt 10 108.458 ? 0.622 ns/op >> BufferByteToShort.vectorShuffleMask 1024 avgt 10 154.176 ? 0.592 ns/op >> BufferByteToShort.vectorShuffleZero 1024 avgt 10 1572.366 ? 8.717 ns/op >> >> I wrote this very quickly so I hope I got it right. >> >> There is still some work required to optimize shuffles with exceptional indexes, but overall we are making good progress. >> >> Paul. >> >>> On Sep 5, 2021, at 5:20 PM, Scott Palmer wrote: >>> >>> Yes, a shuffle works for the operation I was looking for. Though my attempt at implementing the basic 8 bit -> 16 bit conversion loop in my original email is even slower when I tried a version using a shuffle instead of converting to shorts and shifting. >>> >>> My basic loop to convert from bytes to shorts by shifting byte values to the high byte of the short is 70 times faster without using the Vector API in that case! >>> >>> I have to wonder if I?m doing something horribly wrong. >>> >>> It should be possible for this simple loop: >>> >>> void widen(ByteBuffer srcBuff , ByteBuffer dstBuff ) { >>> while (srcBuff.hasRemaining()) { >>> dstBuff.putShort((short) (srcBuff.get() << 8)); >>> } >>> } >>> >>> to go much faster when using vector instructions that operator on 32 bytes at a time. >>> >>> But this is 70x slower: >>> >>> int si = 0; >>> int di = 0; >>> final int loopBound = ByteVector.SPECIES_PREFERRED.loopBound(srcBuff.remaining()); >>> for (; si < loopBound; si += BYTE_SPECIES_LENGTH) { >>> ByteVector srcVec = ByteVector.fromByteBuffer(ByteVector.SPECIES_PREFERRED, srcBuff, si, NATIVE_ORDER); >>> srcVec.rearrange(EXPANDING_SHUFFLE_LO, ZERO).intoByteBuffer(dstBuff, di, NATIVE_ORDER); >>> di += BYTE_SPECIES_LENGTH; >>> srcVec.rearrange(EXPANDING_SHUFFLE_HI, ZERO).intoByteBuffer(dstBuff, di, NATIVE_ORDER); >>> di += BYTE_SPECIES_LENGTH; >>> } >>> >>> >>> Both vector versions I?ve tried are at least an order of magnitude slower than the scalar code. I?m I doing something wrong? >>> >>> Thanks, >>> >>> Scott >>> >>>> On Sep 5, 2021, at 6:27 PM, John Rose wrote: >>>> >>>> I think those are hardware specialized shuffles, right? So try a shuffle. We should try to recognize fixed shuffles that can be handled by special instructions. That?s the basic approach. It doesn?t need a new primitive but maybe some convenience functions and better instruction selection. >>>> >>>>> On Sep 5, 2021, at 1:09 PM, Scott Palmer wrote: >>>>> >>>>> ?Is this list appropriate for questions involving the Vector API? (I scanned the list at https://mail.openjdk.java.net/mailman/listinfo but didn?t see anything) >>>>> >>>>> E.g. questions such as, >>>>> >>>>> Are there plans to support operation XXX? >>>>> >>>>> I?m looking for something like: https://urldefense.com/v3/__https://www.felixcloutier.com/x86/punpcklbw:punpcklwd:punpckldq:punpcklqdq__;!!ACWV5N9M2RV99hQ!dqqvOA1SwTJDru_FwfrA5tnvu69RLnL0RxW-ZSlceWn0P4Gk6XIjlOmEvhUDpZwFzg$ >>>>> >>>>> Or performance related queries? >>>>> >>>>> I tried to convert this simple operation to use the Vector API (on 2MB source buffers) and the result iI got was 15x slower than this byte-wise loop: >>>>> >>>>> void widen(ByteBuffer srcBuff , ByteBuffer dstBuff ) { >>>>> while (srcBuff.hasRemaining()) { >>>>> dstBuff.putShort((short) (srcBuff.get() << 8)); >>>>> } >>>>> } >>>>> >>>>> >>>>> My attempt using JDK 16 on macOS (Intel) looked like: >>>>> >>>>> final int BYTE_PREFERRED_SPECIES_LENGTH = ByteVector.SPECIES_PREFERRED.length(); >>>>> final int loopBound = ByteVector.SPECIES_PREFERRED.loopBound(srcBuff.remaining()); >>>>> int si = 0; >>>>> int di = 0; >>>>> for (; si < loopBound; si += BYTE_PREFERRED_SPECIES_LENGTH) { >>>>> ByteVector srcVec = ByteVector.fromByteBuffer(ByteVector.SPECIES_PREFERRED, srcBuff, si, NATIVE_ORDER); >>>>> srcVec.convert(VectorOperators.B2S, 0) >>>>> .lanewise(VectorOperators.LSHL, 8) >>>>> .intoByteBuffer(dstBuff, di, NATIVE_ORDER); >>>>> di += BYTE_PREFERRED_SPECIES_LENGTH; >>>>> >>>>> srcVec.convert(VectorOperators.B2S, 1) >>>>> .lanewise(VectorOperators.LSHL, 8) >>>>> .intoByteBuffer(dstBuff, PD_di, NATIVE_ORDER); >>>>> di += BYTE_PREFERRED_SPECIES_LENGTH; >>>>> } >>>>> >>>>> If this is the wrong place for these kinds of questions, please point me in the right direction. >>>>> >>>>> Thanks, >>>>> >>>>> Scott >>> >> > From org.openjdk at io7m.com Wed Sep 8 16:40:01 2021 From: org.openjdk at io7m.com (Mark Raynsford) Date: Wed, 8 Sep 2021 16:40:01 +0000 Subject: How To Create Array of Structs? In-Reply-To: <75cf4b45-b1af-b1de-c96c-cb1f312f89e7@oracle.com> References: <0c6361f3-2879-02dd-0b26-e26a5b268602@oracle.com> <4bb60084-2958-45f9-511d-638b85770040@oracle.com> <3b5cdab7-e807-a728-7476-6d6d349c9fe2@oracle.com> <75cf4b45-b1af-b1de-c96c-cb1f312f89e7@oracle.com> Message-ID: <20210908164001.665cfe57@sunflower.int.arc7.info> On 2021-09-08T14:28:47 +0100 Maurizio Cimadamore wrote: > This fix for this issue has been integrated. > > > If you are able to build the Panama repo manually, you should be able to > re-extract Vulkan, and hopefully you should see the layout for > VkSemaphore in there. As a Vulkan user, I'm actually (morbidly) curious to see what the resulting definition is... :) -- Mark Raynsford | https://www.io7m.com From paul.sandoz at oracle.com Wed Sep 8 16:47:05 2021 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 8 Sep 2021 16:47:05 +0000 Subject: [vectorIntrinsics+mask] RFR: 8273057: [vector] New VectorAPI "SelectiveStore" In-Reply-To: <-eE-WLIXMacbrSVZtlGZBVia1VpXPejcL4HxUIdMvyI=.fee8bc80-d837-41d4-ac54-e3731d27eac4@github.com> References: <23BA299B-BA4A-4607-AF49-DD20003BBE2A@oracle.com> <-eE-WLIXMacbrSVZtlGZBVia1VpXPejcL4HxUIdMvyI=.fee8bc80-d837-41d4-ac54-e3731d27eac4@github.com> Message-ID: <4577C05F-0187-4D91-B31A-4685C9AF3339@oracle.com> > On Sep 8, 2021, at 12:03 AM, Joshua Zhu wrote: > > On Tue, 7 Sep 2021 16:35:19 GMT, Paul Sandoz wrote: > >> Would it be possible for you to target this work to a new branch? e.g. vectorIntrinsics+compress. >> >> I want to avoid complicating review and integration of the masking work for JEP 417. We are close to merging vectorIntrinsics+mask into vectorIntrinsics and then starting reviews of the masking support. > > Yes, of course. Thank you, Paul. Hence could you please help me checkout a new branch based on "vectorIntrinsics+mask" or "vectorIntrinsics" after merging? > Yes, once vectorIntrinsics+mask is merged into vectorIntrinsics I will create the branch vectorIntrinsics+compress off vectorIntrinsics. >> It may be possible that compress/expand become part of JEP 417, if we can get it ready in time. If so I can update the JEP accordingly and help do CSRs. Otherwise, we can target to the next round of incubation. > > I'm fine with the plan to place compress/expand in the next round of incubation. I'm afraid I cannot catch the last bus before the review of masking support while I have other works at hand. > Ok. Paul. From maurizio.cimadamore at oracle.com Wed Sep 8 16:55:08 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 8 Sep 2021 17:55:08 +0100 Subject: How To Create Array of Structs? In-Reply-To: <20210908164001.665cfe57@sunflower.int.arc7.info> References: <0c6361f3-2879-02dd-0b26-e26a5b268602@oracle.com> <4bb60084-2958-45f9-511d-638b85770040@oracle.com> <3b5cdab7-e807-a728-7476-6d6d349c9fe2@oracle.com> <75cf4b45-b1af-b1de-c96c-cb1f312f89e7@oracle.com> <20210908164001.665cfe57@sunflower.int.arc7.info> Message-ID: <34747e3f-21c2-92d5-ae02-519dfc7b6530@oracle.com> On 08/09/2021 17:40, Mark Raynsford wrote: > On 2021-09-08T14:28:47 +0100 > Maurizio Cimadamore wrote: > >> This fix for this issue has been integrated. >> >> >> If you are able to build the Panama repo manually, you should be able to >> re-extract Vulkan, and hopefully you should see the layout for >> VkSemaphore in there. > As a Vulkan user, I'm actually (morbidly) curious to see what the > resulting definition is... :) > I believe you will be disappointed - in the sense that jextract will simply emit an alias for C_POINTER (as the definition is a pointer to something) :-) Maurizio From mail at smogura.eu Wed Sep 8 17:36:03 2021 From: mail at smogura.eu (Rado Smogura) Date: Wed, 8 Sep 2021 19:36:03 +0200 Subject: Arrays.mismatch intrinsic and Vector API comparision In-Reply-To: <746E4CC5-9521-4435-A3B3-78A1C444F0BD@oracle.com> References: <71444AEA-0386-417D-B6CB-0ABF957E107A@oracle.com> <746E4CC5-9521-4435-A3B3-78A1C444F0BD@oracle.com> Message-ID: Hi, I double checked it. I think previously loops could not be unrolled too much, as the stride size was too small (I guess int vector loop could not be unrolled on AVX-512). For other cases it works same: // Normal stride size ?;; B18: #??? out( B18 B19 ) <- in( B17 B18 ) Loop( B18-B18 inner main of N138 strip mined) Freq: 16514 ? 0x00007fa8d8f042c0:?? vmovdqu 0x10(%rdx,%r11,4),%ymm0 ? 0x00007fa8d8f042c7:?? vmovdqu %ymm0,0x10(%rsi,%r11,4) ? 0x00007fa8d8f042ce:?? vmovdqu 0x30(%rdx,%r11,4),%ymm0 ? 0x00007fa8d8f042d5:?? vmovdqu %ymm0,0x30(%rsi,%r11,4) ? 0x00007fa8d8f042dc:?? vmovdqu 0x50(%rdx,%r11,4),%ymm0 ? 0x00007fa8d8f042e3:?? vmovdqu %ymm0,0x50(%rsi,%r11,4) ? 0x00007fa8d8f042ea:?? vmovdqu 0x70(%rdx,%r11,4),%ymm0 ? 0x00007fa8d8f042f1:?? vmovdqu %ymm0,0x70(%rsi,%r11,4) ;*invokestatic store {reexecute=0 rethrow=0 return_oop=0} // Updated stride size ?;; B18: #??? out( B18 B19 ) <- in( B17 B18 ) Loop( B18-B18 inner main of N138 strip mined) Freq: 16516.1 ? 0x00007f854cefe940:?? vmovdqu 0x10(%rdx,%r11,4),%ymm0 ? 0x00007f854cefe947:?? vmovdqu %ymm0,0x10(%rsi,%r11,4) ? 0x00007f854cefe94e:?? vmovdqu 0x30(%rdx,%r11,4),%ymm0 ? 0x00007f854cefe955:?? vmovdqu %ymm0,0x30(%rsi,%r11,4) ? 0x00007f854cefe95c:?? vmovdqu 0x50(%rdx,%r11,4),%ymm0 ? 0x00007f854cefe963:?? vmovdqu %ymm0,0x50(%rsi,%r11,4) ? 0x00007f854cefe96a:?? vmovdqu 0x70(%rdx,%r11,4),%ymm0 ? 0x00007f854cefe971:?? vmovdqu %ymm0,0x70(%rsi,%r11,4) ;*invokestatic store {reexecute=0 rethrow=0 return_oop=0} I would check the loop assembly with -XX:-UseSuperWord, if it increased or decreased. Kind regards, Rado On 07.09.2021 18:46, Paul Sandoz wrote: > Rado, do think the recent changes to stride size [1] perturbed this area? I don?t recall seeing such aggressive unrolling before. > > Paul. > > [1] https://github.com/openjdk/jdk/pull/4658 > >> On Sep 4, 2021, at 8:00 AM, Rado Smogura wrote: >> >> Hi all, >> >> >> Interesting topic. >> >> >> In context of too aggressive unrolling. I think I know what could be a reason. There's standard unroll limit, however vectorization can increase it - https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/loopTransform.cpp*L998__;Iw!!ACWV5N9M2RV99hQ!aRm01M_jzh0OqlNCGAjbLaIMmLvv95-1NoWdvVVSn6iIGsoZypYmct6_PtP7dfJf9Q$ >> >> On my machine the new limit is 32, I guess for AVX-512 it could be 64. >> >> >> Kind regards, >> >> Rado >> >> On 04.09.2021 14:53, Kartik Ohri wrote: >>> Hi Paul, >>> >>> Thanks for the feedback! I'll add more cases as you suggested and submit a >>> PR. >>> >>> Regards, >>> Kartik >>> >>> On Fri, Sep 3, 2021 at 3:41 AM Paul Sandoz wrote: >>> >>>> Hi Kartik, >>>> >>>> Thank you. It is useful. I am glad we are reaching the point where the >>>> Vector API is getting competitive with the mismatch stub. >>>> >>>> If you would like to contribute the benchmark I would be happy to review a >>>> PR. >>>> We could also measure int, float and long, in addition to small sizes, >>>> just above or below the vector length (not dissimilar to a mismatch on the >>>> the first or lower index of an array). >>>> When we wrote Arrays.mismatch we were very careful to measure the impact >>>> on small array sizes, since that method is also used to support >>>> Arrays.equals and we did not want to introduce a performance regression. >>>> >>>> >>>> Some of the difference might be explained by alignment of the arrays, some >>>> perhaps due to loop unrolling. >>>> >>>> I think there might be an issue with loop unrolling. It seems too >>>> aggressive, resulting larger than necessary nmethod sizes. We should look >>>> into that. >>>> >>>> >>>> Unsure if it's possible to to reduce [*]: >>>> >>>> vpcmpeqb %ymm1,%ymm0,%ymm0 >>>> vpxor -0x7ad507d(%rip),%ymm0,%ymm0 >>>> >>>> to: >>>> >>>> vpxor %ymm1,%ymm0,%ymm0 >>>> >>>> Since the latter will not produce a valid mask representation, which could >>>> affect later use of the mask value (firstTrue). >>>> >>>> Paul. >>>> >>>> [*] >>>> https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/macroAssembler_x86.cpp*L3211__;Iw!!ACWV5N9M2RV99hQ!aRm01M_jzh0OqlNCGAjbLaIMmLvv95-1NoWdvVVSn6iIGsoZypYmct6_PtMBfj1FBQ$ >>>>> On Aug 29, 2021, at 11:36 AM, Kartik Ohri >>>> wrote: >>>>> Hi! >>>>> >>>>> I have started experimenting with the Vector API recently. Currently, I >>>> am >>>>> playing with the API and trying to gauge its potential by comparing its >>>>> performance with vectorized intrinsics implemented inside the JDK. I know >>>>> that Arrays.mismatch has a vectorized intrinsic so I started with it. I >>>> was >>>>> able to come up with a simple implementation for it using the Vector API. >>>>> The results of the JMH benchmark look quite promising, the Vector API is >>>>> able to come quite close to the intrinsic. This is awesome!! >>>>> >>>>> The benchmark code is available here >>>>> < >>>> https://urldefense.com/v3/__https://github.com/amCap1712/curly-computing-machine/blob/main/src/main/java/dev/lucifer/benchmarks/ArrayMismatchBenchmark.java__;!!ACWV5N9M2RV99hQ!aRm01M_jzh0OqlNCGAjbLaIMmLvv95-1NoWdvVVSn6iIGsoZypYmct6_PtPovnwOrw$ >>>>> and >>>>> the complete benchmark logs are here >>>>> < >>>> https://urldefense.com/v3/__https://github.com/amCap1712/curly-computing-machine/blob/main/results/array-mismatch.csv__;!!ACWV5N9M2RV99hQ!aRm01M_jzh0OqlNCGAjbLaIMmLvv95-1NoWdvVVSn6iIGsoZypYmct6_PtM7ccQAFQ$ >>>>> . >>>>> I also did another run to check the assembly generated which is also >>>>> available here >>>>> < >>>> https://urldefense.com/v3/__https://github.com/amCap1712/curly-computing-machine/blob/main/results/benchmarks.asm.log__;!!ACWV5N9M2RV99hQ!aRm01M_jzh0OqlNCGAjbLaIMmLvv95-1NoWdvVVSn6iIGsoZypYmct6_PtPPLp8e6w$ >>>>> . >>>>> It would be nice to get a sanity check on the benchmark before I proceed >>>>> further. >>>>> >>>>> Both versions perform more or less the same (difference is less than 5%, >>>> in >>>>> some cases the Vector API even outperforms the intrinsic). There is one >>>>> outlier where the Vector API is almost 35% slower than the intrinsic >>>> (when >>>>> prefix is 1 and size is 10000). >>>>> except for when the prefix is 1 i.e. both input arrays are equal. I see >>>>> that the assembly emitted by Vector API >>>>> < >>>> https://urldefense.com/v3/__https://github.com/amCap1712/curly-computing-machine/blob/main/results/benchmarks.asm.log*L7436__;Iw!!ACWV5N9M2RV99hQ!aRm01M_jzh0OqlNCGAjbLaIMmLvv95-1NoWdvVVSn6iIGsoZypYmct6_PtOiZElBVA$ >>>>> contains a *vpcmpeqb* but the JDK intrinsic >>>>> < >>>> https://urldefense.com/v3/__https://github.com/amCap1712/curly-computing-machine/blob/main/results/benchmarks.asm.log*L2064__;Iw!!ACWV5N9M2RV99hQ!aRm01M_jzh0OqlNCGAjbLaIMmLvv95-1NoWdvVVSn6iIGsoZypYmct6_PtOepQLVQA$ >>>>> does not. Looking at the implementation >>>>> < >>>> https://urldefense.com/v3/__https://github.com/openjdk/panama-vector/blob/2fd7943ec191559bfb2778305daf82bcc4422028/src/hotspot/cpu/x86/macroAssembler_x86.cpp*L6088-L6125__;Iw!!ACWV5N9M2RV99hQ!aRm01M_jzh0OqlNCGAjbLaIMmLvv95-1NoWdvVVSn6iIGsoZypYmct6_PtNJS-xo5A$ >>>>> of the intrinsic in the JDK, The AVX 512 version uses *vpcmpeqb* but the >>>>> AVX2 version does not (my machine does not have AVX 512 so it makes that >>>> it >>>>> was not emitted in the case of the intrinsic). Secondly, from the >>>> assembly >>>>> it seems that the Vector API version was unrolled but the intrinsic was >>>>> not. If I am right, in general loop unrolling is better so the API seems >>>> to >>>>> be doing the right thing. Hence, I am not sure why this particular case >>>> is >>>>> an outlier. >>>>> >>>>> Further, Is analysing/comparing intrinsics within the JDK to the Vector >>>> API >>>>> useful? >>>>> >>>>> Also, any other suggestions regarding contributing to the Project are >>>>> welcome. >>>>> >>>>> Regards, >>>>> Kartik From sviswanathan at openjdk.java.net Thu Sep 9 00:10:11 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Thu, 9 Sep 2021 00:10:11 GMT Subject: [vectorIntrinsics+mask] RFR: 8273406: Optimize various masked vector operations for AVX512 target. In-Reply-To: References: Message-ID: On Tue, 7 Sep 2021 14:53:25 GMT, Jatin Bhateja wrote: > This patch is in continuation to X86 backend support for optimizing masked operations over AVX-512 targets (JDK-8262356). > > Summary of changes: > > 1) Support for masked rotate left and right operations over integer/long vectors. > > 2) Support for masked square root operation over float/double vectors. > > 3) Support for masked logical shiftleft and logical/arithmetic shiftright operation with constant shift count. > > 4) Optimized VectorMask.not operation by emitting direct KNOT instruction. > > 5) Extended masking optimization support for X86 KNL target which has limited set of AVX-512 features. > > - Currently vector type associated with VectorLoadMask operation is created during parsing stage. > For targets supporting opmask registers, lane type is explicitly set to BOOLEAN irrespective of the primitive > type of species i.e. for Int512 species ideal type TypeVectMask(16,BOOL) represent vector of 16 BOOLEAN elements > each of which represent a mask bit for corresponding vector lane. > This type information is also associated with respective mask boxes (Int512Mask). > > - During macro expansion vbox/vunbox nodes are broken down into granular target mappable ideal nodes. > > ``` > VectorBoxNode -> VectorStoreMask + StoreVector > > VectorUnboxNode -> LoadVector + VectorLoadMask > ``` > > At this stage vector type (TypeVectMask(16,BOOL)) earlier associated with vunbox node is used to create the > type for VectorLoadMask operation. > > - Masks can be propagated either though a vector (non-AVX512 targets) or using opmask registers (K1-K7). > Decision to create correct ideal type based on the target features is delegated to low level > type creation routine TypeVect::makemask. > > - This creates problem for targets like KNL which support limited set of AVX-512 features i.e. do > no support AVX512VL and AVX512BW feature. > > - For Int512 species initial ideal type constructed during parsing is based on primitive type and > lane count associated with species, but during macro expansion type creation > decision is based on vector type associated with v[u]box nodes i.e. TypeVectoMask(16,BOOL), > thus for KNL target incorrect vector mask type TypeVectX(16,BOOL) gets created since it does not > support vector length extension(128,256 bit operation over EVEX encoded instruction). > > - There are multiple ways to fix this discrepancy, cleanest approach is to create ideal type TypeVectoMask > based on the primitive lane type of the species, instead of always setting the lane type as BOOLEAN. > This will also preserve the original lane type information which was needed in some cases e.g. > reinterpretation operation over mask. To circumvent such issue explicit src/dst primitive types > were added to ideal nodes. > > - Also this does not disturbs the register mask and spilling behavior associated with opmask registers > thus the change is transparent to backend passes. > > Validation: > Patch regressed through tier1-3 tests at AVX Level=0,1,2,3 and UseKNLSetting src/hotspot/cpu/x86/assembler_x86.cpp line 8704: > 8702: > 8703: void Assembler::evsqrtps(XMMRegister dst, KRegister mask, XMMRegister nds, XMMRegister src, bool merge, int vector_len) { > 8704: assert(vector_len == AVX_512bit || VM_Version::supports_avx512vl(), ""); The check for UseAVX>2 is missing here and other places when vector_len == AVX_512bit. src/hotspot/cpu/x86/assembler_x86.cpp line 9086: > 9084: } > 9085: > 9086: void Assembler::evpsllw(XMMRegister dst, KRegister mask, int shift, XMMRegister src, bool merge, int vector_len) { For all the shift and rotate instructions operand order could be dst, mask, src, shift, merge, vector_len. src/hotspot/cpu/x86/assembler_x86.cpp line 9112: > 9110: void Assembler::evpsllq(XMMRegister dst, KRegister mask, int shift, XMMRegister src, bool merge, int vector_len) { > 9111: assert(vector_len == AVX_512bit || VM_Version::supports_avx512vl(), ""); > 9112: InstructionAttr attributes(vector_len, /* vex_w */ false, /* legacy_mode */ false, /* no_mask_reg */ false, /* uses_vl */ true); vex_w should be true here. src/hotspot/cpu/x86/assembler_x86.cpp line 9148: > 9146: void Assembler::evpsrlq(XMMRegister dst, KRegister mask, int shift, XMMRegister src, bool merge, int vector_len) { > 9147: assert(vector_len == AVX_512bit || VM_Version::supports_avx512vl(), ""); > 9148: InstructionAttr attributes(vector_len, /* vex_w */ false, /* legacy_mode */ false, /* no_mask_reg */ false, /* uses_vl */ true); vex_w should be true here. src/hotspot/cpu/x86/assembler_x86.cpp line 9184: > 9182: void Assembler::evpsraq(XMMRegister dst, KRegister mask, int shift, XMMRegister src, bool merge, int vector_len) { > 9183: assert(vector_len == AVX_512bit || VM_Version::supports_avx512vl(), ""); > 9184: InstructionAttr attributes(vector_len, /* vex_w */ false, /* legacy_mode */ false, /* no_mask_reg */ false, /* uses_vl */ true); vex_w should be true here. src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 3856: > 3854: Assembler::evpsrad(dst, mask, imm8, src1, merge, vlen_enc); break; > 3855: case Op_URShiftVL: > 3856: Assembler::evpsraq(dst, mask, imm8, src1, merge, vlen_enc); break; Unsigned shift should be evpsrl and signed shift should be evpsra. src/hotspot/share/opto/vectornode.hpp line 1397: > 1395: : VectorNode(in, dst_vt), _src_vt(src_vt) { > 1396: assert((!dst_vt->isa_vectmask() && !src_vt->isa_vectmask()) || > 1397: (type2aelembytes(src_vt->element_basic_type()) >= type2aelembytes(dst_vt->element_basic_type())), Why this addition limitation for vectmask only? Some comments here please. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/122 From jbhateja at openjdk.java.net Thu Sep 9 06:43:13 2021 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Thu, 9 Sep 2021 06:43:13 GMT Subject: [vectorIntrinsics+mask] RFR: 8273057: [vector] New VectorAPI "SelectiveStore" In-Reply-To: <78fFUAtJpSkwVqjUuq8iisR2YWDKWZNS6UFbrgc65ro=.1f03fe57-bd0f-47f1-a73a-33184f41df5c@github.com> References: <78fFUAtJpSkwVqjUuq8iisR2YWDKWZNS6UFbrgc65ro=.1f03fe57-bd0f-47f1-a73a-33184f41df5c@github.com> Message-ID: On Wed, 8 Sep 2021 08:51:53 GMT, Joshua Zhu wrote: > > > > In this use case its difficult to infer COMPRESSION through Auto-vectorizer though we made attempts in past to infer complex loop patterns for VNNI instruction. > > > > > > > > > Could you elaborate on it please? I do not follow this. > > > > > > I meant auto-vectorizing following loop which mimic compression semantics could be tricky if its difficult to ascertain the independence between memory references. Like in following case 'j' could be a middle index in array and thus if the distance between memory references is less than chosen vector width it may result into incorrect overwrite. > > ``` > > for ( int i = 0; i < n ; i++ ) { > > if ( mask[i] > 1 ) { > > a[j++] = a[i]; > > } > > } > > ``` > > Agree. I think current SWPointer compare (used to detect possible same address) does not apply to this pattern. > In this case, besides SWPointer comparison, "j" cannot be inferred by induction varaible "i" is more critical for auto-vectorization. A PhiNode will be created for j for sure, and it's indeed an induction variable since with each iteration its value is getting incremented. Yes, its not a secondary induction variable in this case and which makes any dependency analysis between array references indexed by different subscripts 'i' or 'j' difficult. > > Do you have plan to support masked operations in SLP optimization? Given that SLP algorithm does not works across basic blocks a simplified approach will be to add ideal transformation post SLP to replace VectorBlend + VectorOperation to a masked operation where ever applicable ------------- PR: https://git.openjdk.java.net/panama-vector/pull/115 From njian at openjdk.java.net Thu Sep 9 09:54:45 2021 From: njian at openjdk.java.net (Ningsheng Jian) Date: Thu, 9 Sep 2021 09:54:45 GMT Subject: [vectorIntrinsics] RFR: Merge panama-vector:master Message-ID: A clean merge. Verified on aarch64 and x86. ------------- Commit messages: - Merge 'panama-vector/master' into vectorIntrinsics - 8273218: G1: Rename g1EvacuationInfo to g1EvacInfo - 8273516: ProblemList compiler/c2/Test7179138_1.java in -Xcomp mode on win-X64 - 8273242: (test) Refactor to use TestNG for RuntimeTests ExecCommand tests - 8265489: Stress test times out because of long ObjectSynchronizer::monitors_iterate(...) operation - 8273451: Remove unreachable return in mutexLocker::wait - 8273185: Rename the term "atomic" in ReferenceProcessor - 8273109: runtime/cds/appcds/loaderConstraints/DynamicLoaderConstraintsTest times out - 8272375: Improve phrasing of synthesized descriptions in JavaFX docs - 8273361: InfoOptsTest is failing in tier1 - ... and 224 more: https://git.openjdk.java.net/panama-vector/compare/dca538de...652ac237 The webrevs contain the adjustments done while merging with regards to each parent branch: - vectorIntrinsics: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=123&range=00.0 - panama-vector:master: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=123&range=00.1 Changes: https://git.openjdk.java.net/panama-vector/pull/123/files Stats: 25501 lines in 1045 files changed: 15066 ins; 5489 del; 4946 mod Patch: https://git.openjdk.java.net/panama-vector/pull/123.diff Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/123/head:pull/123 PR: https://git.openjdk.java.net/panama-vector/pull/123 From jbhateja at openjdk.java.net Thu Sep 9 14:56:22 2021 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Thu, 9 Sep 2021 14:56:22 GMT Subject: [vectorIntrinsics] RFR: Merge panama-vector:master In-Reply-To: References: Message-ID: On Thu, 9 Sep 2021 09:44:05 GMT, Ningsheng Jian wrote: > A clean merge. Verified on aarch64 and x86. Marked as reviewed by jbhateja (Committer). ------------- PR: https://git.openjdk.java.net/panama-vector/pull/123 From mail at smogura.eu Thu Sep 9 16:14:34 2021 From: mail at smogura.eu (Rado Smogura) Date: Thu, 9 Sep 2021 18:14:34 +0200 Subject: [External] : Re: Issues with loop unrolling: better pinned node In-Reply-To: <4cead9e6-87c2-2498-b7e6-2d378dd1f0a2@oracle.com> References: <19C617EE-6745-4DA3-A5AE-674E92F7DAA4@oracle.com> <14e30959-d990-2180-f23d-a05c88ec7899@smogura.eu> <3f7dd833-f632-9b3d-0713-37e78f5de928@oracle.com> <4cead9e6-87c2-2498-b7e6-2d378dd1f0a2@oracle.com> Message-ID: Hi Vladimir, Here I'm not the expert. For following code public static int test2(ByteBuffer in,ByteBuffer out,ByteBuffer out2,byte[] arr) { for (int i =0; i Thanks for giving it a try, Rado. > > It feels like a lot of complexity comes from attempting to support > multiple slices per memory operation. > > How would it look like if you give up on them and use the > TypePtr::BOTTOM/AliasIdxBot? Such memory operations won't be amenable > for further memory-related optimizations (since they alias with any > other memory operation), but it should significantly simplify their > support, shouldn't it? > > Best regards, > Vladimir Ivanov > > On 02.09.2021 22:53, Rado Smogura wrote: >> Hi Vladimir, >> >> >> Thank you for feedback. >> >> >> There was one idea I had previously and I added it here (I surprised >> it works): >> >> * add additional filed TypeTuple _multi_load_adr to Node and set it >> in mixed mode, >> >> * in anti-deps add external loop to do analysis for every address >> from this tuple >> >> Minor changes: >> >> * pass this field to mach node; >> >> * in anti-deps load node has to traverse memory chain (normally this >> is done in Ideal). >> >> >> I checked it with mixed "mode" operating on int and byte vectors and >> I see storeV (raw / byte[]) gets anit-dep to loadV (raw/int[]), and >> same for storeV(raw/byte[]) - so that's good - as there's >> interference over raw. >> >> >> https://urldefense.com/v3/__https://github.com/openjdk/panama-vector/compare/vectorIntrinsics*mask...rsmogura:mixed-mode-use-bot-mem-opt-antideps?expand=1__;Kw!!ACWV5N9M2RV99hQ!ZnX5KqhoIDbUbqdEBiwN3v2aGgLQLfRteZuZKx0RmLzqhfMhcKrMedWCzfG8mBggvHhJ2R8$ >> >> >> Kind regards, >> >> Rado >> >> On 01.09.2021 15:22, Vladimir Ivanov wrote: >>> Interesting idea, Rado! Representing memory effects of >>> mixed/mismatched accesses with TypePtr::BOTTOM does look promising. >>> >>> Regarding the preferred IR shapes, I'd try to teach alias analysis >>> (Compile::find_alias_type()) and PhaseCFG::insert_anti_dependences() >>> about loads/stores on wide memory (TypePtr::BOTTOM) and see what >>> kind of problems arise to decide how to proceed. I hope there's a >>> way to avoid dummy nodes when representing desired effects. >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> On 30.08.2021 18:12, Rado Smogura wrote: >>>> Hi all, >>>> >>>> >>>> I added one missing thing. I want to build something like this. >>>> Would it make sense? >>>> >>>> >>>> ??? STORE >>>> >>>> >>>> ??????????????????????????????? addr >>>> ????????????????????????????????? ? >>>> ????????????????????????????????? ? >>>> ????????? reset_memory()????????? ? >>>> ???????????? ???? ?????????????????????????? >>>> ???????????? ???? ? CheckCastPP (-> BOT)?? ? >>>> ???????????? ???? ?????????????????????????? >>>> ???????????? ??????????? ? >>>> ???????????? ??????????? ? >>>> ???????????? ??????? ??? ? >>>> ???????????? ??????? ??? ? >>>> ???????????? ?? ????????????????????????????????????? >>>> ???????????? ?? ???????????? StoreVector??????????? ? >>>> ???????????? ?? ????????????????????????????????????? >>>> ???????????? ?????? ??????????????????????????? ? >>>> ???????????? ?????? ??????????????????????????? ? >>>> ?????????????????????????????????????????????????????????????????? >>>> ??????????? ? BOT? RAW byte[]????????????????????????? ? >>>> ??????????? ? MergeMem??????????????????????????????????????? ? >>>> ?????????????????????????????????????????????????????????????????? >>>> >>>> >>>> >>>> ???? LOAD >>>> >>>> ????????????? ? >>>> ????????????? ? >>>> ????????????? ??????????? >>>> ????????????? ????????? ? >>>> ????????????? ? >>>> ??????????????????????????????????????????????????????????????? >>>> ????????????? ? ? LoadVector >>>> (BOT)??????????????????????????????????????????? ? >>>> ????????????? ? >>>> ??????????????????????????????????????????????????????????????? >>>> ????????????? ????????????????????????? ? ? >>>> ????????????? ????? addr base -> raw ????????????????????????? ? >>>> addr base -> byte[] >>>> ????????????? ????????????????????????? ? ? >>>> ????????????? ??????????? ????????????????????????? >>>> ????????????????????????? >>>> ????????????? ??????????? ?DummyStoreV (raw)????? ? ?DummyStoreV >>>> (byte[])?? ? //No-op stores >>>> ????????????? ??????????? ????????????????????????? >>>> ????????????????????????? >>>> ????????????? ?????????????????? ??????????????????????? ? >>>> ????????????? ????? ?????????????????????????? ??????????? >>>> ????????????? ????? ?????????????????????????? ? >>>> ??????????????????????????????????????????????????????????????????? >>>> ??????????? ? BOT? RAW byte[]?????????????????????????? ? >>>> ??????????? ? MergeMem???????????????????????????????????????? ? >>>> ??????????????????????????????????????????????????????????????????? >>>> >>>> >>>> DummyStore is "virtual" node inserted after load, intended to >>>> emulate store, and prevent writes / reads to go on the side of load >>>> vector (it fact it more prevents store / load to see through >>>> mem-memrge). >>>> >>>> I did test it with following code. >>>> >>>> public static void copyMemoryBytes3(ByteBuffer in, ByteBuffer out, >>>> ByteBuffer out2,byte[] arr) { >>>> ???? for (int i=0; i >>> +=SPECIES_BYTE.vectorByteSize()) { >>>> ???????? var v1 = ByteVector.fromByteBuffer(SPECIES_BYTE, in, i, >>>> ByteOrder.nativeOrder()); >>>> ???????? arr[i] = (byte) i; >>>> ???????? var v2 = ByteVector.fromByteBuffer(SPECIES_BYTE, out, i, >>>> ByteOrder.nativeOrder()); >>>> ???????? v1.intoByteBuffer(out, i, ByteOrder.nativeOrder()); >>>> ???? } >>>> } >>>> >>>> Kind regards, >>>> >>>> Rado >>>> >>>> On 27.08.2021 20:16, Rado Smogura wrote: >>>>> Hi all, >>>>> >>>>> >>>>> I experimented a little bit, and I wonder if this is reasonable, >>>>> the outcome on graphs is as expected, and operations looks like >>>>> properly ordered (but this is my private opinion). >>>>> >>>>> https://urldefense.com/v3/__https://github.com/rsmogura/panama-vector/commit/755b62823aaed0cddf78e8ccfc60c063bb40779a__;!!ACWV5N9M2RV99hQ!ceve5Eoh01VSiAxgPOSMpL_oQpz6MJI6KeGEcvULButhjMZGdxMq2SB02arX5hxVvmWp1wY$ >>>>> >>>>> >>>>> Kind regards, >>>>> >>>>> Rado >>>>> >>>>> On 19.08.2021 22:26, Rado Smogura wrote: >>>>>> I think I answered this question quite simply... it will not work. >>>>>> >>>>>> On 19.08.2021 18:39, Rado Smogura wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> >>>>>>> I hope you have a good day. >>>>>>> >>>>>>> >>>>>>> As still optimizing loops would be good approach, I thought >>>>>>> about optimizing a mixed access with this approach: >>>>>>> >>>>>>> >>>>>>> 1. When mixed access is detected set flag "raw / byte array" >>>>>>> mixed access. >>>>>>> >>>>>>> 2. Bail out and restart compilation (will happen during first >>>>>>> phases, and only for few methods). >>>>>>> >>>>>>> 3. Pass a flag to compiler. >>>>>>> >>>>>>> 4. Modify find_alias_type / flatten_alias_type, so that if byte >>>>>>> array will be queried for alias, raw ptr and raw alias will be >>>>>>> used. >>>>>>> >>>>>>> >>>>>>> Kind regards, >>>>>>> >>>>>>> Rado >>>>>>> >>>>>>> On 18.08.2021 09:17, Rado Smogura wrote: >>>>>>>> Hi Vladimir, >>>>>>>> >>>>>>>> >>>>>>>> Thank you for answer. >>>>>>>> >>>>>>>> >>>>>>>> In fact, it is was an attempt to confirm that memory flow can >>>>>>>> be a cause why loop opts do not work. That's very fair point. >>>>>>>> I'll think about it and maybe I'll be able to come out idea how >>>>>>>> this can be generalized. >>>>>>>> >>>>>>>> >>>>>>>> Kind regards, >>>>>>>> >>>>>>>> Rado >>>>>>>> >>>>>>>> On 16.08.2021 15:41, Vladimir Ivanov wrote: >>>>>>>>>> I wonder what do you think about something like this [1] - >>>>>>>>>> it's virtually small single class change >>>>>>>>> >>>>>>>>> Very interesting experiment, Rado! It's encouraging to hear >>>>>>>>> that loop opts immediately benefit from it. >>>>>>>>> >>>>>>>>> From a architectural perspective, a separate pass to optimize >>>>>>>>> memory graph brings excessive complexity: >>>>>>>>> >>>>>>>>> ? (1) yet another pass over the graph and susceptible to pass >>>>>>>>> ordering issues; >>>>>>>>> >>>>>>>>> ? (2) separate from GVN: you either have to duplicate >>>>>>>>> GVN-based memory optimizations or run new pass with IGVN in a >>>>>>>>> loop until it stabilizes. >>>>>>>>> >>>>>>>>> IMO the problem you noticed illustrates a general weakness in >>>>>>>>> GVN implementation and that's the place where it should be >>>>>>>>> fixed (ideally). >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Vladimir Ivanov >>>>>>>>> >>>>>>>>>> >>>>>>>>>> This change tries to find unique memory for load node. I >>>>>>>>>> implemented it as separate phase, as optimization may not run >>>>>>>>>> in Ideal method. I think it's ligher than phi split out. >>>>>>>>>> >>>>>>>>>> Loops has been transformed. RCE started. >>>>>>>>>> >>>>>>>>>> Kind regards, >>>>>>>>>> Rado >>>>>>>>>> >>>>>>>>>> [1] - >>>>>>>>>> https://urldefense.com/v3/__https://github.com/rsmogura/panama-vector/commit/a44f515890d2c4df3fd0e0ced76545a7664926c3__;!!ACWV5N9M2RV99hQ!ceve5Eoh01VSiAxgPOSMpL_oQpz6MJI6KeGEcvULButhjMZGdxMq2SB02arX5hxVLT5AsEE$ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> [2] - >>>>>>>>>> https://urldefense.com/v3/__https://github.com/rsmogura/panama-vector/tree/housekeeping-load-memory-optimiziation__;!!ACWV5N9M2RV99hQ!ceve5Eoh01VSiAxgPOSMpL_oQpz6MJI6KeGEcvULButhjMZGdxMq2SB02arX5hxVcBkmVi0$ >>>>>>>>>> >>>>>>>>>> (full test case) >>>>>>>>>> >>>>>>>>>> ------------------------------------------------------------------------ >>>>>>>>>> >>>>>>>>>> *From:* Rados?aw Smogura on behalf of Rados?aw Smogura >>>>>>>>>> >>>>>>>>>> *Sent:* Friday, August 6, 2021 22:43 >>>>>>>>>> *To:* Rados?aw Smogura ; Paul Sandoz >>>>>>>>>> ; Vladimir Ivanov >>>>>>>>>> >>>>>>>>>> *Cc:* panama-dev at openjdk.java.net >>>>>>>>>> *Subject:* Re: Issues with loop unrolling: better pinned node >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> Now when I checked it again. it works as expected, and it's >>>>>>>>>> the same code. >>>>>>>>>> >>>>>>>>>> In draft code I check if the buffer is direct by using type >>>>>>>>>> checking to unswitch loop, as unswitching over ByteBuffer.hb >>>>>>>>>> did not work (the graph was quite similar). However, I >>>>>>>>>> thought that this unswitch actually helped to build correct >>>>>>>>>> loops, and any kind of improvement around it would be rather >>>>>>>>>> for the purpose of better-looking code. >>>>>>>>>> >>>>>>>>>> But it looks like that sometimes (but only sometimes) loop >>>>>>>>>> still can not be correctly built, or maybe the full >>>>>>>>>> optimization kicks in very, very late. >>>>>>>>>> >>>>>>>>>> Kind regards, >>>>>>>>>> Rado >>>>>>>>>> ------------------------------------------------------------------------ >>>>>>>>>> >>>>>>>>>> *From:* panama-dev on >>>>>>>>>> behalf of Rados?aw Smogura >>>>>>>>>> *Sent:* Friday, August 6, 2021 20:22 >>>>>>>>>> *To:* Paul Sandoz >>>>>>>>>> *Cc:* panama-dev at openjdk.java.net >>>>>>>>>> *Subject:* Re: Issues with loop unrolling: better pinned node >>>>>>>>>> Yes, >>>>>>>>>> >>>>>>>>>> The normal case looks, good. It's all about polluted cases [1] >>>>>>>>>> >>>>>>>>>> BR, >>>>>>>>>> Rado >>>>>>>>>> >>>>>>>>>> [1] >>>>>>>>>> https://urldefense.com/v3/__https://github.com/openjdk/panama-vector/pull/109__;!!ACWV5N9M2RV99hQ!ceve5Eoh01VSiAxgPOSMpL_oQpz6MJI6KeGEcvULButhjMZGdxMq2SB02arX5hxVfxQRu38$ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> [https://urldefense.com/v3/__https://opengraph.githubassets.com/daf8e3b93dd4c25e04d1ce6ae2a91e1b725625bfd85b5027c61fb78ae3a6a361/openjdk/panama-vector/pull/109__;!!ACWV5N9M2RV99hQ!ceve5Eoh01VSiAxgPOSMpL_oQpz6MJI6KeGEcvULButhjMZGdxMq2SB02arX5hxVmHZKrgY$ >>>>>>>>>> ]>>>>>>>>> > >>>>>>>>>> >>>>>>>>>> (Draft) Perofrmance improvements for polluted cases by >>>>>>>>>> rsmogura ? Pull Request #109 ? >>>>>>>>>> openjdk/panama-vector>>>>>>>>> > >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Hi all, I would like to submit this piece of work, for byte >>>>>>>>>> buffers and polluted cases. It resolves some performance >>>>>>>>>> issues related to mem barriers when in scope are both on- and >>>>>>>>>> off-heap buffer. T... >>>>>>>>>> github.com >>>>>>>>>> >>>>>>>>>> [https://urldefense.com/v3/__https://opengraph.githubassets.com/5fde12f89c012a2abef1542ed59c7272429fa7556f6e82a5e617a293d3a5bee1/openjdk/panama-vector__;!!ACWV5N9M2RV99hQ!ceve5Eoh01VSiAxgPOSMpL_oQpz6MJI6KeGEcvULButhjMZGdxMq2SB02arX5hxVLW0LAx0$ >>>>>>>>>> ]>>>>>>>>> > >>>>>>>>>> >>>>>>>>>> Comparing >>>>>>>>>> openjdk:vectorIntrinsics...rsmogura:vectors-polluted-cases ? >>>>>>>>>> openjdk/panama-vector>>>>>>>>> > >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Panama vector. Contribute to openjdk/panama-vector >>>>>>>>>> development by creating an account on GitHub. >>>>>>>>>> github.com >>>>>>>>>> >>>>>>>>>> ________________________________ >>>>>>>>>> From: Paul Sandoz >>>>>>>>>> Sent: Friday, August 6, 2021 20:04 >>>>>>>>>> To: Rados?aw Smogura >>>>>>>>>> Cc: panama-dev at openjdk.java.net >>>>>>>>>> Subject: Re: Issues with loop unrolling: better pinned node >>>>>>>>>> >>>>>>>>>> I am confused as to the case under test. In your initial >>>>>>>>>> email of this thread were you also referring implicitly to >>>>>>>>>> polluted cases? >>>>>>>>>> >>>>>>>>>> Paul. >>>>>>>>>> >>>>>>>>>>> On Aug 6, 2021, at 10:56 AM, Rados?aw Smogura >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> Hi Paul, >>>>>>>>>>> >>>>>>>>>>> There's a performance improvement, but. I still can't unroll >>>>>>>>>>> polluted cases (I cherry-picked loop unrolling). The graph >>>>>>>>>>> still has few nodes taking buffer limit from phi, and on IR >>>>>>>>>>> I don't see vectors nodes cascading. >>>>>>>>>>> >>>>>>>>>>> make test TEST='micro:ByteBufferVectorAccess.p' >>>>>>>>>>> MICRO="OPTIONS=-f 1 -prof perfasm >>>>>>>>>>> -jvmArgsPrepend=-Djdk.incubator.vector.VECTOR_ACCESS_OOB_CHECK=0" >>>>>>>>>>> JOBS=12 >>>>>>>>>>> Benchmark (size) Mode Cnt Score?? Error? Units >>>>>>>>>>> ByteBufferVectorAccess.pollutedBuffers2 1024 avgt 30 40.472 >>>>>>>>>>> ? 1.055? ns/op >>>>>>>>>>> ByteBufferVectorAccess.pollutedBuffers2:?asm 1024 >>>>>>>>>>> avgt????????? NaN??????????? --- >>>>>>>>>>> ByteBufferVectorAccess.pollutedBuffers3 1024 avgt 30 79.251 >>>>>>>>>>> ? 0.786? ns/op >>>>>>>>>>> ByteBufferVectorAccess.pollutedBuffers3:?asm 1024 >>>>>>>>>>> avgt????????? NaN??????????? --- >>>>>>>>>>> ByteBufferVectorAccess.pollutedBuffers4 1024 avgt 30 83.627 >>>>>>>>>>> ? 2.140? ns/op >>>>>>>>>>> ByteBufferVectorAccess.pollutedBuffers4:?asm 1024 >>>>>>>>>>> avgt????????? NaN??????????? --- >>>>>>>>>>> ByteBufferVectorAccess.pollutedBuffers5 1024 avgt 30 85.561 >>>>>>>>>>> ? 1.156? ns/op >>>>>>>>>>> ByteBufferVectorAccess.pollutedBuffers5:?asm 1024 >>>>>>>>>>> avgt????????? NaN >>>>>>>>>>> >>>>>>>>>>> make test TEST='micro:ByteBufferVectorAccess.p' >>>>>>>>>>> MICRO="OPTIONS=-f 1 -prof perfasm" >>>>>>>>>>> Benchmark (size) Mode Cnt Score?? Error? Units >>>>>>>>>>> ByteBufferVectorAccess.pollutedBuffers2 1024 avgt 10 49.326 >>>>>>>>>>> ? 0.843? ns/op >>>>>>>>>>> ByteBufferVectorAccess.pollutedBuffers2:?asm 1024 >>>>>>>>>>> avgt?????????? NaN??????????? --- >>>>>>>>>>> ByteBufferVectorAccess.pollutedBuffers3 1024 avgt 10 100.291 >>>>>>>>>>> ? 1.271? ns/op >>>>>>>>>>> ByteBufferVectorAccess.pollutedBuffers3:?asm 1024 >>>>>>>>>>> avgt?????????? NaN??????????? --- >>>>>>>>>>> ByteBufferVectorAccess.pollutedBuffers4 1024 avgt 10 101.494 >>>>>>>>>>> ? 1.027? ns/op >>>>>>>>>>> ByteBufferVectorAccess.pollutedBuffers4:?asm 1024 >>>>>>>>>>> avgt?????????? NaN??????????? --- >>>>>>>>>>> ByteBufferVectorAccess.pollutedBuffers5 1024 avgt 10 94.606 >>>>>>>>>>> ? 1.522? ns/op >>>>>>>>>>> ByteBufferVectorAccess.pollutedBuffers5:?asm 1024 >>>>>>>>>>> avgt?????????? NaN >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> BR, >>>>>>>>>>> Rado >>>>>>>>>>> From: Paul Sandoz >>>>>>>>>>> Sent: Friday, August 6, 2021 18:04 >>>>>>>>>>> To: Rados?aw Smogura >>>>>>>>>>> Cc: panama-dev at openjdk.java.net >>>>>>>>>>> Subject: Re: Issues with loop unrolling: better pinned node >>>>>>>>>>> >>>>>>>>>>> Hi Rado, >>>>>>>>>>> >>>>>>>>>>> It?s good you are looking at the IR >>>>>>>>>>> >>>>>>>>>>> Out of curiosity, what happens if you turn off bounds >>>>>>>>>>> checking [*]? >>>>>>>>>>> >>>>>>>>>>> Paul. >>>>>>>>>>> >>>>>>>>>>> [*] >>>>>>>>>>> -Djdk.incubator.vector.VECTOR_ACCESS_OOB_CHECK=0 >>>>>>>>>>> >>>>>>>>>>> > On Aug 6, 2021, at 8:39 AM, Rados?aw Smogura >>>>>>>>>>> wrote: >>>>>>>>>>> > >>>>>>>>>>> > Hi all, >>>>>>>>>>> > >>>>>>>>>>> > I've found that even if we get rid of barriers, the loop >>>>>>>>>>> can't get unrolled, and not needed code is inside it. >>>>>>>>>>> > >>>>>>>>>>> > I've found this graph, I wonder if it's most optimal, in a >>>>>>>>>>> partiucalry Load of ByteBuffer index / hb is from phi, could >>>>>>>>>>> it be attached to initial memory? >>>>>>>>>>> > >>>>>>>>>>> > Here's a picture >>>>>>>>>>> https://urldefense.com/v3/__https://drive.google.com/file/d/1G7ZN0xHOVIVHmZ_5TTIUdm3F30okAzvO/view?usp=sharing__;!!ACWV5N9M2RV99hQ!ceve5Eoh01VSiAxgPOSMpL_oQpz6MJI6KeGEcvULButhjMZGdxMq2SB02arX5hxVkhhZ0w8$ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> > >>>>>>>>>>> [https://urldefense.com/v3/__https://lh6.googleusercontent.com/SKgGZgfVWFpG8w4mWqguLSU4DVfa1MKYPSQhxv8EoX04XzVz8U8Kc4zHP0iwdR26Suc=w1200-h630-p__;!!ACWV5N9M2RV99hQ!ceve5Eoh01VSiAxgPOSMpL_oQpz6MJI6KeGEcvULButhjMZGdxMq2SB02arX5hxVgkskdP0$ >>>>>>>>>>> ]>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> > >>>>>>>>>> >>>>>>>>>>> > >>>>>>>>>>> bb_issues.png>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> > >>>>>>>>>> >>>>>>>>>>> > drive.google.com >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > And sample code >>>>>>>>>>> > >>>>>>>>>>> > protected void copyMemory(ByteBuffer in, ByteBuffer out) { >>>>>>>>>>> >? var limit = SPECIES.loopBound(in.limit()); >>>>>>>>>>> >? for (int i=0; i < limit; i += SPECIES.vectorByteSize()) { >>>>>>>>>>> >??? final var v = ByteVector.fromByteBuffer(SPECIES, in, i, >>>>>>>>>>> ByteOrder.nativeOrder()); >>>>>>>>>>> >??? v.intoByteBuffer(out, i, ByteOrder.nativeOrder()); >>>>>>>>>>> >? } >>>>>>>>>>> > } >>>>>>>>>>> > >>>>>>>>>>> > Kind regards, >>>>>>>>>>> > Rado >>>>>>>>>> From paul.sandoz at oracle.com Thu Sep 9 16:47:09 2021 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 9 Sep 2021 16:47:09 +0000 Subject: CFV: New Panama Committer: Jie Fu Message-ID: <45B1ED7D-7A97-4F1E-8F4F-BDD15004EF49@oracle.com> I hereby nominate Jie Fu (OpenJDK ID: jiefu, GitHub ID: DamonFool) [0] to Panama Committer. Jie has contributed many patches to the Vector API and has been really helpful battle testing the implementation, reporting issues and proposing fixies for them in panama-vector [3] and jdk [4] repositories. Votes are due by September 23rd, 2021. Only current Panama Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Paul. [0] https://openjdk.java.net/census#jiefu [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#reviewer-vote [3] https://github.com/openjdk/panama-vector/pulls?q=is%3Apr+author%3ADamonFool [4] https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3ADamonFool+%22Vector+API%22+in%3Atitle+ From psandoz at openjdk.java.net Thu Sep 9 17:01:26 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Thu, 9 Sep 2021 17:01:26 GMT Subject: [vectorIntrinsics] RFR: Merge panama-vector:master In-Reply-To: References: Message-ID: On Thu, 9 Sep 2021 09:44:05 GMT, Ningsheng Jian wrote: > A clean merge. Verified on aarch64 and x86. Marked as reviewed by psandoz (Committer). ------------- PR: https://git.openjdk.java.net/panama-vector/pull/123 From mail at smogura.eu Thu Sep 9 18:54:27 2021 From: mail at smogura.eu (Rado Smogura) Date: Thu, 9 Sep 2021 20:54:27 +0200 Subject: [External] : Re: Issues with loop unrolling: better pinned node In-Reply-To: References: <14e30959-d990-2180-f23d-a05c88ec7899@smogura.eu> <3f7dd833-f632-9b3d-0713-37e78f5de928@oracle.com> <4cead9e6-87c2-2498-b7e6-2d378dd1f0a2@oracle.com> Message-ID: I'm sorry, I think I attached wrong screenshot this one could better describe my concern [1]. This is part of preloop [1] https://drive.google.com/file/d/1dKJL6Dqu8bFluiIz63LxFisQ1i_XT_W_/view?usp=sharing On 09.09.2021 18:14, Rado Smogura wrote: > Hi Vladimir, > > Here I'm not the expert. For following code > > public static int test2(ByteBuffer in,ByteBuffer out,ByteBuffer > out2,byte[] arr) { > ??? for (int i =0; i +=SPECIES_BYTE.vectorByteSize()) { > ??????? var v1 =ByteVector.fromByteBuffer(SPECIES_BYTE, in, > i,ByteOrder.nativeOrder()); > ??????? arr[i] = (byte) i; > ??????? v1.intoByteBuffer(out, i,ByteOrder.nativeOrder()); > ??? } > > ??? return 0; > } > > I think there's missing dependency between loadV and storeB - I put > graph here [1]. > > My understanding is, initially and for short period of time, storeB is > anchored to same memory as loadV. However storeB as it's "normal" > store optimizes own memory chain, and later phi split happens. > > Finally storeB and loadV are anchored to different memory, so > anti-dependencies can't find interference. Not sure if there's a > possibility to separate such loads and stores in terms of blocks > precedence. > > Kind regards, > Rado > > [1] > https://drive.google.com/file/d/1_Q7LUmmQqbVnH9pdJmSkjrRsfDyekrbo/view?usp=sharing > > On 07.09.2021 20:01, Vladimir Ivanov wrote: >> Thanks for giving it a try, Rado. >> >> It feels like a lot of complexity comes from attempting to support >> multiple slices per memory operation. >> >> How would it look like if you give up on them and use the >> TypePtr::BOTTOM/AliasIdxBot? Such memory operations won't be amenable >> for further memory-related optimizations (since they alias with any >> other memory operation), but it should significantly simplify their >> support, shouldn't it? >> >> Best regards, >> Vladimir Ivanov >> >> On 02.09.2021 22:53, Rado Smogura wrote: >>> Hi Vladimir, >>> >>> >>> Thank you for feedback. >>> >>> >>> There was one idea I had previously and I added it here (I surprised >>> it works): >>> >>> * add additional filed TypeTuple _multi_load_adr to Node and set it >>> in mixed mode, >>> >>> * in anti-deps add external loop to do analysis for every address >>> from this tuple >>> >>> Minor changes: >>> >>> * pass this field to mach node; >>> >>> * in anti-deps load node has to traverse memory chain (normally this >>> is done in Ideal). >>> >>> >>> I checked it with mixed "mode" operating on int and byte vectors and >>> I see storeV (raw / byte[]) gets anit-dep to loadV (raw/int[]), and >>> same for storeV(raw/byte[]) - so that's good - as there's >>> interference over raw. >>> >>> >>> https://urldefense.com/v3/__https://github.com/openjdk/panama-vector/compare/vectorIntrinsics*mask...rsmogura:mixed-mode-use-bot-mem-opt-antideps?expand=1__;Kw!!ACWV5N9M2RV99hQ!ZnX5KqhoIDbUbqdEBiwN3v2aGgLQLfRteZuZKx0RmLzqhfMhcKrMedWCzfG8mBggvHhJ2R8$ >>> >>> >>> Kind regards, >>> >>> Rado >>> >>> On 01.09.2021 15:22, Vladimir Ivanov wrote: >>>> Interesting idea, Rado! Representing memory effects of >>>> mixed/mismatched accesses with TypePtr::BOTTOM does look promising. >>>> >>>> Regarding the preferred IR shapes, I'd try to teach alias analysis >>>> (Compile::find_alias_type()) and >>>> PhaseCFG::insert_anti_dependences() about loads/stores on wide >>>> memory (TypePtr::BOTTOM) and see what kind of problems arise to >>>> decide how to proceed. I hope there's a way to avoid dummy nodes >>>> when representing desired effects. >>>> >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>> On 30.08.2021 18:12, Rado Smogura wrote: >>>>> Hi all, >>>>> >>>>> >>>>> I added one missing thing. I want to build something like this. >>>>> Would it make sense? >>>>> >>>>> >>>>> ??? STORE >>>>> >>>>> >>>>> ??????????????????????????????? addr >>>>> ????????????????????????????????? ? >>>>> ????????????????????????????????? ? >>>>> ????????? reset_memory()????????? ? >>>>> ???????????? ???? ?????????????????????????? >>>>> ???????????? ???? ? CheckCastPP (-> BOT)?? ? >>>>> ???????????? ???? ?????????????????????????? >>>>> ???????????? ??????????? ? >>>>> ???????????? ??????????? ? >>>>> ???????????? ??????? ??? ? >>>>> ???????????? ??????? ??? ? >>>>> ???????????? ?? ????????????????????????????????????? >>>>> ???????????? ?? ???????????? StoreVector??????????? ? >>>>> ???????????? ?? ????????????????????????????????????? >>>>> ???????????? ?????? ??????????????????????????? ? >>>>> ???????????? ?????? ??????????????????????????? ? >>>>> ?????????????????????????????????????????????????????????????????? >>>>> ??????????? ? BOT? RAW byte[]????????????????????????? ? >>>>> ??????????? ? MergeMem??????????????????????????????????????? ? >>>>> ?????????????????????????????????????????????????????????????????? >>>>> >>>>> >>>>> >>>>> ???? LOAD >>>>> >>>>> ????????????? ? >>>>> ????????????? ? >>>>> ????????????? ??????????? >>>>> ????????????? ????????? ? >>>>> ????????????? ? >>>>> ??????????????????????????????????????????????????????????????? >>>>> ????????????? ? ? LoadVector >>>>> (BOT)??????????????????????????????????????????? ? >>>>> ????????????? ? >>>>> ??????????????????????????????????????????????????????????????? >>>>> ????????????? ????????????????????????? ? ? >>>>> ????????????? ????? addr base -> raw ????????????????????????? ? >>>>> addr base -> byte[] >>>>> ????????????? ????????????????????????? ? ? >>>>> ????????????? ??????????? ????????????????????????? >>>>> ????????????????????????? >>>>> ????????????? ??????????? ?DummyStoreV (raw)????? ? ?DummyStoreV >>>>> (byte[])?? ? //No-op stores >>>>> ????????????? ??????????? ????????????????????????? >>>>> ????????????????????????? >>>>> ????????????? ?????????????????? ??????????????????????? ? >>>>> ????????????? ????? ?????????????????????????? ??????????? >>>>> ????????????? ????? ?????????????????????????? ? >>>>> ??????????????????????????????????????????????????????????????????? >>>>> ??????????? ? BOT? RAW byte[]?????????????????????????? ? >>>>> ??????????? ? MergeMem???????????????????????????????????????? ? >>>>> ??????????????????????????????????????????????????????????????????? >>>>> >>>>> >>>>> DummyStore is "virtual" node inserted after load, intended to >>>>> emulate store, and prevent writes / reads to go on the side of >>>>> load vector (it fact it more prevents store / load to see through >>>>> mem-memrge). >>>>> >>>>> I did test it with following code. >>>>> >>>>> public static void copyMemoryBytes3(ByteBuffer in, ByteBuffer out, >>>>> ByteBuffer out2,byte[] arr) { >>>>> ???? for (int i=0; i >>>> +=SPECIES_BYTE.vectorByteSize()) { >>>>> ???????? var v1 = ByteVector.fromByteBuffer(SPECIES_BYTE, in, i, >>>>> ByteOrder.nativeOrder()); >>>>> ???????? arr[i] = (byte) i; >>>>> ???????? var v2 = ByteVector.fromByteBuffer(SPECIES_BYTE, out, i, >>>>> ByteOrder.nativeOrder()); >>>>> ???????? v1.intoByteBuffer(out, i, ByteOrder.nativeOrder()); >>>>> ???? } >>>>> } >>>>> >>>>> Kind regards, >>>>> >>>>> Rado >>>>> >>>>> On 27.08.2021 20:16, Rado Smogura wrote: >>>>>> Hi all, >>>>>> >>>>>> >>>>>> I experimented a little bit, and I wonder if this is reasonable, >>>>>> the outcome on graphs is as expected, and operations looks like >>>>>> properly ordered (but this is my private opinion). >>>>>> >>>>>> https://urldefense.com/v3/__https://github.com/rsmogura/panama-vector/commit/755b62823aaed0cddf78e8ccfc60c063bb40779a__;!!ACWV5N9M2RV99hQ!ceve5Eoh01VSiAxgPOSMpL_oQpz6MJI6KeGEcvULButhjMZGdxMq2SB02arX5hxVvmWp1wY$ >>>>>> >>>>>> >>>>>> Kind regards, >>>>>> >>>>>> Rado >>>>>> >>>>>> On 19.08.2021 22:26, Rado Smogura wrote: >>>>>>> I think I answered this question quite simply... it will not work. >>>>>>> >>>>>>> On 19.08.2021 18:39, Rado Smogura wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> >>>>>>>> I hope you have a good day. >>>>>>>> >>>>>>>> >>>>>>>> As still optimizing loops would be good approach, I thought >>>>>>>> about optimizing a mixed access with this approach: >>>>>>>> >>>>>>>> >>>>>>>> 1. When mixed access is detected set flag "raw / byte array" >>>>>>>> mixed access. >>>>>>>> >>>>>>>> 2. Bail out and restart compilation (will happen during first >>>>>>>> phases, and only for few methods). >>>>>>>> >>>>>>>> 3. Pass a flag to compiler. >>>>>>>> >>>>>>>> 4. Modify find_alias_type / flatten_alias_type, so that if byte >>>>>>>> array will be queried for alias, raw ptr and raw alias will be >>>>>>>> used. >>>>>>>> >>>>>>>> >>>>>>>> Kind regards, >>>>>>>> >>>>>>>> Rado >>>>>>>> >>>>>>>> On 18.08.2021 09:17, Rado Smogura wrote: >>>>>>>>> Hi Vladimir, >>>>>>>>> >>>>>>>>> >>>>>>>>> Thank you for answer. >>>>>>>>> >>>>>>>>> >>>>>>>>> In fact, it is was an attempt to confirm that memory flow can >>>>>>>>> be a cause why loop opts do not work. That's very fair point. >>>>>>>>> I'll think about it and maybe I'll be able to come out idea >>>>>>>>> how this can be generalized. >>>>>>>>> >>>>>>>>> >>>>>>>>> Kind regards, >>>>>>>>> >>>>>>>>> Rado >>>>>>>>> >>>>>>>>> On 16.08.2021 15:41, Vladimir Ivanov wrote: >>>>>>>>>>> I wonder what do you think about something like this [1] - >>>>>>>>>>> it's virtually small single class change >>>>>>>>>> >>>>>>>>>> Very interesting experiment, Rado! It's encouraging to hear >>>>>>>>>> that loop opts immediately benefit from it. >>>>>>>>>> >>>>>>>>>> From a architectural perspective, a separate pass to optimize >>>>>>>>>> memory graph brings excessive complexity: >>>>>>>>>> >>>>>>>>>> ? (1) yet another pass over the graph and susceptible to pass >>>>>>>>>> ordering issues; >>>>>>>>>> >>>>>>>>>> ? (2) separate from GVN: you either have to duplicate >>>>>>>>>> GVN-based memory optimizations or run new pass with IGVN in a >>>>>>>>>> loop until it stabilizes. >>>>>>>>>> >>>>>>>>>> IMO the problem you noticed illustrates a general weakness in >>>>>>>>>> GVN implementation and that's the place where it should be >>>>>>>>>> fixed (ideally). >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Vladimir Ivanov >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> This change tries to find unique memory for load node. I >>>>>>>>>>> implemented it as separate phase, as optimization may not >>>>>>>>>>> run in Ideal method. I think it's ligher than phi split out. >>>>>>>>>>> >>>>>>>>>>> Loops has been transformed. RCE started. >>>>>>>>>>> >>>>>>>>>>> Kind regards, >>>>>>>>>>> Rado >>>>>>>>>>> >>>>>>>>>>> [1] - >>>>>>>>>>> https://urldefense.com/v3/__https://github.com/rsmogura/panama-vector/commit/a44f515890d2c4df3fd0e0ced76545a7664926c3__;!!ACWV5N9M2RV99hQ!ceve5Eoh01VSiAxgPOSMpL_oQpz6MJI6KeGEcvULButhjMZGdxMq2SB02arX5hxVLT5AsEE$ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> [2] - >>>>>>>>>>> https://urldefense.com/v3/__https://github.com/rsmogura/panama-vector/tree/housekeeping-load-memory-optimiziation__;!!ACWV5N9M2RV99hQ!ceve5Eoh01VSiAxgPOSMpL_oQpz6MJI6KeGEcvULButhjMZGdxMq2SB02arX5hxVcBkmVi0$ >>>>>>>>>>> >>>>>>>>>>> (full test case) >>>>>>>>>>> >>>>>>>>>>> ------------------------------------------------------------------------ >>>>>>>>>>> >>>>>>>>>>> *From:* Rados?aw Smogura on behalf of Rados?aw Smogura >>>>>>>>>>> >>>>>>>>>>> *Sent:* Friday, August 6, 2021 22:43 >>>>>>>>>>> *To:* Rados?aw Smogura ; Paul Sandoz >>>>>>>>>>> ; Vladimir Ivanov >>>>>>>>>>> >>>>>>>>>>> *Cc:* panama-dev at openjdk.java.net >>>>>>>>>>> *Subject:* Re: Issues with loop unrolling: better pinned node >>>>>>>>>>> Hi all, >>>>>>>>>>> >>>>>>>>>>> Now when I checked it again. it works as expected, and it's >>>>>>>>>>> the same code. >>>>>>>>>>> >>>>>>>>>>> In draft code I check if the buffer is direct by using type >>>>>>>>>>> checking to unswitch loop, as unswitching over ByteBuffer.hb >>>>>>>>>>> did not work (the graph was quite similar). However, I >>>>>>>>>>> thought that this unswitch actually helped to build correct >>>>>>>>>>> loops, and any kind of improvement around it would be rather >>>>>>>>>>> for the purpose of better-looking code. >>>>>>>>>>> >>>>>>>>>>> But it looks like that sometimes (but only sometimes) loop >>>>>>>>>>> still can not be correctly built, or maybe the full >>>>>>>>>>> optimization kicks in very, very late. >>>>>>>>>>> >>>>>>>>>>> Kind regards, >>>>>>>>>>> Rado >>>>>>>>>>> ------------------------------------------------------------------------ >>>>>>>>>>> >>>>>>>>>>> *From:* panama-dev on >>>>>>>>>>> behalf of Rados?aw Smogura >>>>>>>>>>> *Sent:* Friday, August 6, 2021 20:22 >>>>>>>>>>> *To:* Paul Sandoz >>>>>>>>>>> *Cc:* panama-dev at openjdk.java.net >>>>>>>>>>> *Subject:* Re: Issues with loop unrolling: better pinned node >>>>>>>>>>> Yes, >>>>>>>>>>> >>>>>>>>>>> The normal case looks, good. It's all about polluted cases [1] >>>>>>>>>>> >>>>>>>>>>> BR, >>>>>>>>>>> Rado >>>>>>>>>>> >>>>>>>>>>> [1] >>>>>>>>>>> https://urldefense.com/v3/__https://github.com/openjdk/panama-vector/pull/109__;!!ACWV5N9M2RV99hQ!ceve5Eoh01VSiAxgPOSMpL_oQpz6MJI6KeGEcvULButhjMZGdxMq2SB02arX5hxVfxQRu38$ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> [https://urldefense.com/v3/__https://opengraph.githubassets.com/daf8e3b93dd4c25e04d1ce6ae2a91e1b725625bfd85b5027c61fb78ae3a6a361/openjdk/panama-vector/pull/109__;!!ACWV5N9M2RV99hQ!ceve5Eoh01VSiAxgPOSMpL_oQpz6MJI6KeGEcvULButhjMZGdxMq2SB02arX5hxVmHZKrgY$ >>>>>>>>>>> ]>>>>>>>>>> > >>>>>>>>>>> >>>>>>>>>>> (Draft) Perofrmance improvements for polluted cases by >>>>>>>>>>> rsmogura ? Pull Request #109 ? >>>>>>>>>>> openjdk/panama-vector>>>>>>>>>> > >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Hi all, I would like to submit this piece of work, for byte >>>>>>>>>>> buffers and polluted cases. It resolves some performance >>>>>>>>>>> issues related to mem barriers when in scope are both on- >>>>>>>>>>> and off-heap buffer. T... >>>>>>>>>>> github.com >>>>>>>>>>> >>>>>>>>>>> [https://urldefense.com/v3/__https://opengraph.githubassets.com/5fde12f89c012a2abef1542ed59c7272429fa7556f6e82a5e617a293d3a5bee1/openjdk/panama-vector__;!!ACWV5N9M2RV99hQ!ceve5Eoh01VSiAxgPOSMpL_oQpz6MJI6KeGEcvULButhjMZGdxMq2SB02arX5hxVLW0LAx0$ >>>>>>>>>>> ]>>>>>>>>>> > >>>>>>>>>>> >>>>>>>>>>> Comparing >>>>>>>>>>> openjdk:vectorIntrinsics...rsmogura:vectors-polluted-cases ? >>>>>>>>>>> openjdk/panama-vector>>>>>>>>>> > >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Panama vector. Contribute to openjdk/panama-vector >>>>>>>>>>> development by creating an account on GitHub. >>>>>>>>>>> github.com >>>>>>>>>>> >>>>>>>>>>> ________________________________ >>>>>>>>>>> From: Paul Sandoz >>>>>>>>>>> Sent: Friday, August 6, 2021 20:04 >>>>>>>>>>> To: Rados?aw Smogura >>>>>>>>>>> Cc: panama-dev at openjdk.java.net >>>>>>>>>>> Subject: Re: Issues with loop unrolling: better pinned node >>>>>>>>>>> >>>>>>>>>>> I am confused as to the case under test. In your initial >>>>>>>>>>> email of this thread were you also referring implicitly to >>>>>>>>>>> polluted cases? >>>>>>>>>>> >>>>>>>>>>> Paul. >>>>>>>>>>> >>>>>>>>>>>> On Aug 6, 2021, at 10:56 AM, Rados?aw Smogura >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hi Paul, >>>>>>>>>>>> >>>>>>>>>>>> There's a performance improvement, but. I still can't >>>>>>>>>>>> unroll polluted cases (I cherry-picked loop unrolling). The >>>>>>>>>>>> graph still has few nodes taking buffer limit from phi, and >>>>>>>>>>>> on IR I don't see vectors nodes cascading. >>>>>>>>>>>> >>>>>>>>>>>> make test TEST='micro:ByteBufferVectorAccess.p' >>>>>>>>>>>> MICRO="OPTIONS=-f 1 -prof perfasm >>>>>>>>>>>> -jvmArgsPrepend=-Djdk.incubator.vector.VECTOR_ACCESS_OOB_CHECK=0" >>>>>>>>>>>> JOBS=12 >>>>>>>>>>>> Benchmark (size) Mode Cnt Score?? Error Units >>>>>>>>>>>> ByteBufferVectorAccess.pollutedBuffers2 1024 avgt 30 40.472 >>>>>>>>>>>> ? 1.055? ns/op >>>>>>>>>>>> ByteBufferVectorAccess.pollutedBuffers2:?asm 1024 >>>>>>>>>>>> avgt????????? NaN??????????? --- >>>>>>>>>>>> ByteBufferVectorAccess.pollutedBuffers3 1024 avgt 30 79.251 >>>>>>>>>>>> ? 0.786? ns/op >>>>>>>>>>>> ByteBufferVectorAccess.pollutedBuffers3:?asm 1024 >>>>>>>>>>>> avgt????????? NaN??????????? --- >>>>>>>>>>>> ByteBufferVectorAccess.pollutedBuffers4 1024 avgt 30 83.627 >>>>>>>>>>>> ? 2.140? ns/op >>>>>>>>>>>> ByteBufferVectorAccess.pollutedBuffers4:?asm 1024 >>>>>>>>>>>> avgt????????? NaN??????????? --- >>>>>>>>>>>> ByteBufferVectorAccess.pollutedBuffers5 1024 avgt 30 85.561 >>>>>>>>>>>> ? 1.156? ns/op >>>>>>>>>>>> ByteBufferVectorAccess.pollutedBuffers5:?asm 1024 >>>>>>>>>>>> avgt????????? NaN >>>>>>>>>>>> >>>>>>>>>>>> make test TEST='micro:ByteBufferVectorAccess.p' >>>>>>>>>>>> MICRO="OPTIONS=-f 1 -prof perfasm" >>>>>>>>>>>> Benchmark (size) Mode Cnt Score?? Error Units >>>>>>>>>>>> ByteBufferVectorAccess.pollutedBuffers2 1024 avgt 10 49.326 >>>>>>>>>>>> ? 0.843? ns/op >>>>>>>>>>>> ByteBufferVectorAccess.pollutedBuffers2:?asm 1024 >>>>>>>>>>>> avgt?????????? NaN??????????? --- >>>>>>>>>>>> ByteBufferVectorAccess.pollutedBuffers3 1024 avgt 10 >>>>>>>>>>>> 100.291 ? 1.271? ns/op >>>>>>>>>>>> ByteBufferVectorAccess.pollutedBuffers3:?asm 1024 >>>>>>>>>>>> avgt?????????? NaN??????????? --- >>>>>>>>>>>> ByteBufferVectorAccess.pollutedBuffers4 1024 avgt 10 >>>>>>>>>>>> 101.494 ? 1.027? ns/op >>>>>>>>>>>> ByteBufferVectorAccess.pollutedBuffers4:?asm 1024 >>>>>>>>>>>> avgt?????????? NaN??????????? --- >>>>>>>>>>>> ByteBufferVectorAccess.pollutedBuffers5 1024 avgt 10 94.606 >>>>>>>>>>>> ? 1.522? ns/op >>>>>>>>>>>> ByteBufferVectorAccess.pollutedBuffers5:?asm 1024 >>>>>>>>>>>> avgt?????????? NaN >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> BR, >>>>>>>>>>>> Rado >>>>>>>>>>>> From: Paul Sandoz >>>>>>>>>>>> Sent: Friday, August 6, 2021 18:04 >>>>>>>>>>>> To: Rados?aw Smogura >>>>>>>>>>>> Cc: panama-dev at openjdk.java.net >>>>>>>>>>>> Subject: Re: Issues with loop unrolling: better pinned node >>>>>>>>>>>> >>>>>>>>>>>> Hi Rado, >>>>>>>>>>>> >>>>>>>>>>>> It?s good you are looking at the IR >>>>>>>>>>>> >>>>>>>>>>>> Out of curiosity, what happens if you turn off bounds >>>>>>>>>>>> checking [*]? >>>>>>>>>>>> >>>>>>>>>>>> Paul. >>>>>>>>>>>> >>>>>>>>>>>> [*] >>>>>>>>>>>> -Djdk.incubator.vector.VECTOR_ACCESS_OOB_CHECK=0 >>>>>>>>>>>> >>>>>>>>>>>> > On Aug 6, 2021, at 8:39 AM, Rados?aw Smogura >>>>>>>>>>>> wrote: >>>>>>>>>>>> > >>>>>>>>>>>> > Hi all, >>>>>>>>>>>> > >>>>>>>>>>>> > I've found that even if we get rid of barriers, the loop >>>>>>>>>>>> can't get unrolled, and not needed code is inside it. >>>>>>>>>>>> > >>>>>>>>>>>> > I've found this graph, I wonder if it's most optimal, in >>>>>>>>>>>> a partiucalry Load of ByteBuffer index / hb is from phi, >>>>>>>>>>>> could it be attached to initial memory? >>>>>>>>>>>> > >>>>>>>>>>>> > Here's a picture >>>>>>>>>>>> https://urldefense.com/v3/__https://drive.google.com/file/d/1G7ZN0xHOVIVHmZ_5TTIUdm3F30okAzvO/view?usp=sharing__;!!ACWV5N9M2RV99hQ!ceve5Eoh01VSiAxgPOSMpL_oQpz6MJI6KeGEcvULButhjMZGdxMq2SB02arX5hxVkhhZ0w8$ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> > >>>>>>>>>>>> [https://urldefense.com/v3/__https://lh6.googleusercontent.com/SKgGZgfVWFpG8w4mWqguLSU4DVfa1MKYPSQhxv8EoX04XzVz8U8Kc4zHP0iwdR26Suc=w1200-h630-p__;!!ACWV5N9M2RV99hQ!ceve5Eoh01VSiAxgPOSMpL_oQpz6MJI6KeGEcvULButhjMZGdxMq2SB02arX5hxVgkskdP0$ >>>>>>>>>>>> ]>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> > >>>>>>>>>>> >>>>>>>>>>>> > >>>>>>>>>>>> bb_issues.png>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> > >>>>>>>>>>> >>>>>>>>>>>> > drive.google.com >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > And sample code >>>>>>>>>>>> > >>>>>>>>>>>> > protected void copyMemory(ByteBuffer in, ByteBuffer out) { >>>>>>>>>>>> >? var limit = SPECIES.loopBound(in.limit()); >>>>>>>>>>>> >? for (int i=0; i < limit; i += SPECIES.vectorByteSize()) { >>>>>>>>>>>> >??? final var v = ByteVector.fromByteBuffer(SPECIES, in, >>>>>>>>>>>> i, ByteOrder.nativeOrder()); >>>>>>>>>>>> >??? v.intoByteBuffer(out, i, ByteOrder.nativeOrder()); >>>>>>>>>>>> >? } >>>>>>>>>>>> > } >>>>>>>>>>>> > >>>>>>>>>>>> > Kind regards, >>>>>>>>>>>> > Rado >>>>>>>>>>> From sviswanathan at openjdk.java.net Thu Sep 9 22:58:19 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Thu, 9 Sep 2021 22:58:19 GMT Subject: [vectorIntrinsics+mask] RFR: 8273406: Optimize various masked vector operations for AVX512 target. In-Reply-To: References: Message-ID: <1oKY4bwtUvKHnUBE-bkzuy-h9DtBO--W73CBYCKtEWs=.a272d9b5-b778-4420-ac6b-6a2a6c0797c7@github.com> On Tue, 7 Sep 2021 14:53:25 GMT, Jatin Bhateja wrote: > This patch is in continuation to X86 backend support for optimizing masked operations over AVX-512 targets (JDK-8262356). > > Summary of changes: > > 1) Support for masked rotate left and right operations over integer/long vectors. > > 2) Support for masked square root operation over float/double vectors. > > 3) Support for masked logical shiftleft and logical/arithmetic shiftright operation with constant shift count. > > 4) Optimized VectorMask.not operation by emitting direct KNOT instruction. > > 5) Extended masking optimization support for X86 KNL target which has limited set of AVX-512 features. > > - Currently vector type associated with VectorLoadMask operation is created during parsing stage. > For targets supporting opmask registers, lane type is explicitly set to BOOLEAN irrespective of the primitive > type of species i.e. for Int512 species ideal type TypeVectMask(16,BOOL) represent vector of 16 BOOLEAN elements > each of which represent a mask bit for corresponding vector lane. > This type information is also associated with respective mask boxes (Int512Mask). > > - During macro expansion vbox/vunbox nodes are broken down into granular target mappable ideal nodes. > > ``` > VectorBoxNode -> VectorStoreMask + StoreVector > > VectorUnboxNode -> LoadVector + VectorLoadMask > ``` > > At this stage vector type (TypeVectMask(16,BOOL)) earlier associated with vunbox node is used to create the > type for VectorLoadMask operation. > > - Masks can be propagated either though a vector (non-AVX512 targets) or using opmask registers (K1-K7). > Decision to create correct ideal type based on the target features is delegated to low level > type creation routine TypeVect::makemask. > > - This creates problem for targets like KNL which support limited set of AVX-512 features i.e. do > no support AVX512VL and AVX512BW feature. > > - For Int512 species initial ideal type constructed during parsing is based on primitive type and > lane count associated with species, but during macro expansion type creation > decision is based on vector type associated with v[u]box nodes i.e. TypeVectoMask(16,BOOL), > thus for KNL target incorrect vector mask type TypeVectX(16,BOOL) gets created since it does not > support vector length extension(128,256 bit operation over EVEX encoded instruction). > > - There are multiple ways to fix this discrepancy, cleanest approach is to create ideal type TypeVectoMask > based on the primitive lane type of the species, instead of always setting the lane type as BOOLEAN. > This will also preserve the original lane type information which was needed in some cases e.g. > reinterpretation operation over mask. To circumvent such issue explicit src/dst primitive types > were added to ideal nodes. > > - Also this does not disturbs the register mask and spilling behavior associated with opmask registers > thus the change is transparent to backend passes. > > Validation: > Patch regressed through tier1-3 tests at AVX Level=0,1,2,3 and UseKNLSetting src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 3947: > 3945: evrold(eType, dst, mask, src1, src2, merge, vlen_enc); break; > 3946: case Op_RotateRightV: > 3947: evrord(eType, dst, mask, src1, src2, merge, vlen_enc); break; is_varshift is not passed to evrold/evrord here. But x86.ad is sending is_varshift for rotates. src/hotspot/cpu/x86/x86.ad line 1970: > 1968: case Op_OrVMask: > 1969: case Op_XorVMask: > 1970: if (vlen > 16 && !VM_Version::supports_avx512bw()) { Isn't there a limitation as well for vlen 8 and DQ support? src/hotspot/cpu/x86/x86.ad line 7201: > 7199: > 7200: instruct evcmpFD64(vec dst, vec src1, vec src2, immI8 cond, rRegP scratch, kReg ktmp) %{ > 7201: predicate(!VM_Version::supports_avx512vl() && Why check for !avx512vl here in evcmpFD64 when the avx512vl is removed from evcmpFD. Likewise for vcmpu64. src/hotspot/cpu/x86/x86.ad line 7336: > 7334: instruct evcmp(kReg dst, vec src1, vec src2, immI8 cond) %{ > 7335: predicate(UseAVX > 2 && > 7336: n->bottom_type()->isa_vectmask() && // src1 why does the comment say src1? src/hotspot/cpu/x86/x86.ad line 8991: > 8989: match(Set dst (RotateLeftV (Binary dst src2) mask)); > 8990: match(Set dst (RotateRightV (Binary dst src2) mask)); > 8991: format %{ "vrotate_masked $dst, $dst, $src2\t! rotate masked operation" %} No mask register shown in format. src/hotspot/cpu/x86/x86.ad line 8998: > 8996: bool is_varshift = !VectorNode::is_vshift_cnt_opcode(in(2)->isa_Mach()->ideal_Opcode()); > 8997: __ evmasked_op(opc, bt, $mask$$KRegister, $dst$$XMMRegister, > 8998: $dst$$XMMRegister, $src2$$XMMRegister, true, vlen_enc, is_varshift); x86.ad is sending is_varshift for rotates but is_varshift is not passed to evrold/evrord in evmasked_op. src/hotspot/cpu/x86/x86.ad line 9007: > 9005: match(Set dst (LShiftVI (Binary dst (LShiftCntV shift)) mask)); > 9006: match(Set dst (LShiftVL (Binary dst (LShiftCntV shift)) mask)); > 9007: format %{ "vplshift_imm_masked $dst, $dst, $shift\t! lshift masked operation" %} No mask register shown in format. src/hotspot/cpu/x86/x86.ad line 9053: > 9051: match(Set dst (RShiftVI (Binary dst (RShiftCntV shift)) mask)); > 9052: match(Set dst (RShiftVL (Binary dst (RShiftCntV shift)) mask)); > 9053: format %{ "vprshift_imm_masked $dst, $dst, $shift\t! rshift masked operation" %} No mask register shown in format. src/hotspot/cpu/x86/x86.ad line 9099: > 9097: match(Set dst (URShiftVI (Binary dst (RShiftCntV shift)) mask)); > 9098: match(Set dst (URShiftVL (Binary dst (RShiftCntV shift)) mask)); > 9099: format %{ "vpurshift_imm_masked $dst, $dst, $shift\t! urshift masked operation" %} No mask register shown in format. src/hotspot/cpu/x86/x86.ad line 9306: > 9304: match(Set dst (MaskAll cnt)); > 9305: effect(TEMP_DEF dst, TEMP tmp); > 9306: format %{ "mask_all_evexI $dst, $cnt \t! mask all operation" %} No need to say TEMP_DEF for dst. Also good to show tmp register in format. src/hotspot/cpu/x86/x86.ad line 9326: > 9324: match(Set dst (MaskAll src)); > 9325: effect(TEMP_DEF dst, TEMP tmp); > 9326: format %{ "mask_all_evexI $dst, $src \t! mask all operation" %} No need to say TEMP_DEF for dst. Also good to show tmp register in format. src/hotspot/cpu/x86/x86.ad line 9360: > 9358: %} > 9359: > 9360: instruct mask_not_immLT8(kReg dst, kReg src, rRegI rtmp, kReg ktmp, immI_M1 cnt) %{ What happens to not operation if vector_length < 8 and it is a !avx512dq platform? src/hotspot/cpu/x86/x86.ad line 9364: > 9362: match(Set dst (XorVMask src (MaskAll cnt))); > 9363: effect(TEMP_DEF dst, TEMP rtmp, TEMP ktmp); > 9364: format %{ "mask_not_LT8 $dst, $src, $cnt \t! mask not operation" %} Good to show temp registers in format, helps in debugging. src/hotspot/cpu/x86/x86.ad line 9375: > 9373: predicate((Matcher::vector_length(n) == 8 && VM_Version::supports_avx512dq()) || > 9374: (Matcher::vector_length(n) == 16) || > 9375: (Matcher::vector_length(n) > 16 && VM_Version::supports_avx512bw())); What happens to not operation if vector_length == 8 and it is a !avx512dq platform? src/hotspot/cpu/x86/x86.ad line 9397: > 9395: assert(0 == Type::cmp(mask1->bottom_type(), mask2->bottom_type()), ""); > 9396: uint masklen = Matcher::vector_length(this); > 9397: masklen = masklen < 16 && !VM_Version::supports_avx512dq() ? 16 : masklen; Good to add parenthesis here: (masklen < 16 && !VM_Version::supports_avx512dq()) ------------- PR: https://git.openjdk.java.net/panama-vector/pull/122 From sviswanathan at openjdk.java.net Thu Sep 9 22:58:15 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Thu, 9 Sep 2021 22:58:15 GMT Subject: [vectorIntrinsics+mask] RFR: 8273406: Optimize various masked vector operations for AVX512 target. In-Reply-To: References: <6kCpmxefYaZUAbKSS65LzJwwiLMTp4IR0KKi53SSVD0=.c11e2264-6168-4204-881a-42ecb26992b9@github.com> Message-ID: On Wed, 8 Sep 2021 06:50:41 GMT, Jatin Bhateja wrote: >> @jatin-bhateja is [JDK-8262356](https://bugs.openjdk.java.net/browse/JDK-8262356) mostly a duplicate of the sub-task [JDK-8272359](https://bugs.openjdk.java.net/browse/JDK-8272359)? > >> @jatin-bhateja is [JDK-8262356](https://bugs.openjdk.java.net/browse/JDK-8262356) mostly a duplicate of the sub-task [JDK-8272359](https://bugs.openjdk.java.net/browse/JDK-8272359)? > > Yes, I have linked JDK-8262356 to sub-task JDK-8272359. > Also linked other related issues with JDK-8262356 @jatin-bhateja I have completed the first pass review. I will look forward to an update. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/122 From njian at openjdk.java.net Fri Sep 10 01:15:29 2021 From: njian at openjdk.java.net (Ningsheng Jian) Date: Fri, 10 Sep 2021 01:15:29 GMT Subject: [vectorIntrinsics] RFR: Merge panama-vector:master [v2] In-Reply-To: References: Message-ID: > A clean merge. Verified on aarch64 and x86. Ningsheng Jian has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 736 commits: - Merge 'panama-vector/master' into vectorIntrinsics - 8263532: C2: Improve vector box elimination for Phi nodes Reviewed-by: psandoz - Merge panama-vector:master Co-authored-by: Ningsheng Jian - Optimize mem barriers for ByteBuffer cases Reviewed-by: psandoz, vlivanov - 8271009: AArch64: Wrap duplicated SVE instructions into a single method Reviewed-by: njian, xgong - 8271005: AArch64: Add SVE codegen for VectorMask reduction nodes Reviewed-by: njian, eliu - Merge panama-vector:master Reviewed-by: xgong, sviswanathan - 8269264: Some more cleanups for Vector API SVE support Reviewed-by: xgong - Merge panama-vector:master Co-authored-by: Ningsheng Jian - 8244490: [vector] Move Vector API micro benchmarks under test/micro Reviewed-by: psandoz - ... and 726 more: https://git.openjdk.java.net/panama-vector/compare/5df26480...652ac237 ------------- Changes: https://git.openjdk.java.net/panama-vector/pull/123/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=123&range=01 Stats: 73376 lines in 122 files changed: 72140 ins; 213 del; 1023 mod Patch: https://git.openjdk.java.net/panama-vector/pull/123.diff Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/123/head:pull/123 PR: https://git.openjdk.java.net/panama-vector/pull/123 From njian at openjdk.java.net Fri Sep 10 01:15:32 2021 From: njian at openjdk.java.net (Ningsheng Jian) Date: Fri, 10 Sep 2021 01:15:32 GMT Subject: [vectorIntrinsics] Integrated: Merge panama-vector:master In-Reply-To: References: Message-ID: <9GvvQvKonLCQkTCj6Pn9qLd9BrQEtzh25cgaRahwTmg=.199c2476-bb90-4d35-9f63-9f510b9d8708@github.com> On Thu, 9 Sep 2021 09:44:05 GMT, Ningsheng Jian wrote: > A clean merge. Verified on aarch64 and x86. This pull request has now been integrated. Changeset: beed6675 Author: Ningsheng Jian URL: https://git.openjdk.java.net/panama-vector/commit/beed6675d95fe71ee30f6e2adc4f708b57fa55fd Stats: 25501 lines in 1045 files changed: 15066 ins; 5489 del; 4946 mod Merge panama-vector:master Reviewed-by: jbhateja, psandoz ------------- PR: https://git.openjdk.java.net/panama-vector/pull/123 From ningsheng.jian at arm.com Fri Sep 10 01:18:16 2021 From: ningsheng.jian at arm.com (Ningsheng Jian) Date: Fri, 10 Sep 2021 09:18:16 +0800 Subject: CFV: New Panama Committer: Jie Fu In-Reply-To: <45B1ED7D-7A97-4F1E-8F4F-BDD15004EF49@oracle.com> References: <45B1ED7D-7A97-4F1E-8F4F-BDD15004EF49@oracle.com> Message-ID: Vote: yes -Ningsheng On 9/10/21 12:47 AM, Paul Sandoz wrote: > I hereby nominate Jie Fu (OpenJDK ID: jiefu, GitHub ID: DamonFool) [0] to Panama Committer. > > Jie has contributed many patches to the Vector API and has been really helpful battle testing the implementation, reporting issues and proposing fixies for them in panama-vector [3] and jdk [4] repositories. > > Votes are due by September 23rd, 2021. > > Only current Panama Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Paul. > > [0] https://openjdk.java.net/census#jiefu > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] > https://github.com/openjdk/panama-vector/pulls?q=is%3Apr+author%3ADamonFool > [4] > https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3ADamonFool+%22Vector+API%22+in%3Atitle+ > From jatin.bhateja at intel.com Fri Sep 10 01:42:10 2021 From: jatin.bhateja at intel.com (Bhateja, Jatin) Date: Fri, 10 Sep 2021 01:42:10 +0000 Subject: CFV: New Panama Committer: Jie Fu In-Reply-To: <45B1ED7D-7A97-4F1E-8F4F-BDD15004EF49@oracle.com> References: <45B1ED7D-7A97-4F1E-8F4F-BDD15004EF49@oracle.com> Message-ID: Vote: yes ________________________________ From: panama-dev on behalf of Paul Sandoz Sent: Thursday, September 9, 2021 10:17:09 PM To: panama-dev Subject: CFV: New Panama Committer: Jie Fu I hereby nominate Jie Fu (OpenJDK ID: jiefu, GitHub ID: DamonFool) [0] to Panama Committer. Jie has contributed many patches to the Vector API and has been really helpful battle testing the implementation, reporting issues and proposing fixies for them in panama-vector [3] and jdk [4] repositories. Votes are due by September 23rd, 2021. Only current Panama Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Paul. [0] https://openjdk.java.net/census#jiefu [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#reviewer-vote [3] https://github.com/openjdk/panama-vector/pulls?q=is%3Apr+author%3ADamonFool [4] https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3ADamonFool+%22Vector+API%22+in%3Atitle+ From Xiaohong.Gong at arm.com Fri Sep 10 08:13:49 2021 From: Xiaohong.Gong at arm.com (Xiaohong Gong) Date: Fri, 10 Sep 2021 08:13:49 +0000 Subject: CFV: New Panama Committer: Jie Fu Message-ID: Vote: yes -Xiaohong On 9/10/21 12:47 AM, Paul Sandoz wrote: > I hereby nominate Jie Fu (OpenJDK ID: jiefu, GitHub ID: DamonFool) [0] to Panama Committer. > > Jie has contributed many patches to the Vector API and has been really helpful battle testing the implementation, reporting issues and proposing fixies for them in panama-vector [3] and jdk [4] repositories. > > Votes are due by September 23rd, 2021. > > Only current Panama Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Paul. > > [0] https://openjdk.java.net/census#jiefu > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] > https://github.com/openjdk/panama-vector/pulls?q=is%3Apr+author%3ADamonFool > [4] > https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3ADamonFool+%22Vector+API%22+in%3Atitle+ > From kartikohri13 at gmail.com Fri Sep 10 08:38:08 2021 From: kartikohri13 at gmail.com (Kartik Ohri) Date: Fri, 10 Sep 2021 14:08:08 +0530 Subject: Arrays.mismatch intrinsic and Vector API comparision In-Reply-To: <71444AEA-0386-417D-B6CB-0ABF957E107A@oracle.com> References: <71444AEA-0386-417D-B6CB-0ABF957E107A@oracle.com> Message-ID: Hi! I have submitted a PR for this benchmark to openjdk/jdk. Can you please create a JBS issue and review the PR ? Thanks. Regards, Kartik On Fri, Sep 3, 2021 at 3:41 AM Paul Sandoz wrote: > Hi Kartik, > > Thank you. It is useful. I am glad we are reaching the point where the > Vector API is getting competitive with the mismatch stub. > > If you would like to contribute the benchmark I would be happy to review a > PR. > We could also measure int, float and long, in addition to small sizes, > just above or below the vector length (not dissimilar to a mismatch on the > the first or lower index of an array). > When we wrote Arrays.mismatch we were very careful to measure the impact > on small array sizes, since that method is also used to support > Arrays.equals and we did not want to introduce a performance regression. > > > Some of the difference might be explained by alignment of the arrays, some > perhaps due to loop unrolling. > > I think there might be an issue with loop unrolling. It seems too > aggressive, resulting larger than necessary nmethod sizes. We should look > into that. > > > Unsure if it's possible to to reduce [*]: > > vpcmpeqb %ymm1,%ymm0,%ymm0 > vpxor -0x7ad507d(%rip),%ymm0,%ymm0 > > to: > > vpxor %ymm1,%ymm0,%ymm0 > > Since the latter will not produce a valid mask representation, which could > affect later use of the mask value (firstTrue). > > Paul. > > [*] > https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/macroAssembler_x86.cpp#L3211 > > > On Aug 29, 2021, at 11:36 AM, Kartik Ohri > wrote: > > > > Hi! > > > > I have started experimenting with the Vector API recently. Currently, I > am > > playing with the API and trying to gauge its potential by comparing its > > performance with vectorized intrinsics implemented inside the JDK. I know > > that Arrays.mismatch has a vectorized intrinsic so I started with it. I > was > > able to come up with a simple implementation for it using the Vector API. > > The results of the JMH benchmark look quite promising, the Vector API is > > able to come quite close to the intrinsic. This is awesome!! > > > > The benchmark code is available here > > < > https://github.com/amCap1712/curly-computing-machine/blob/main/src/main/java/dev/lucifer/benchmarks/ArrayMismatchBenchmark.java > > > > and > > the complete benchmark logs are here > > < > https://github.com/amCap1712/curly-computing-machine/blob/main/results/array-mismatch.csv > >. > > I also did another run to check the assembly generated which is also > > available here > > < > https://github.com/amCap1712/curly-computing-machine/blob/main/results/benchmarks.asm.log > >. > > It would be nice to get a sanity check on the benchmark before I proceed > > further. > > > > Both versions perform more or less the same (difference is less than 5%, > in > > some cases the Vector API even outperforms the intrinsic). There is one > > outlier where the Vector API is almost 35% slower than the intrinsic > (when > > prefix is 1 and size is 10000). > > except for when the prefix is 1 i.e. both input arrays are equal. I see > > that the assembly emitted by Vector API > > < > https://github.com/amCap1712/curly-computing-machine/blob/main/results/benchmarks.asm.log#L7436 > > > > contains a *vpcmpeqb* but the JDK intrinsic > > < > https://github.com/amCap1712/curly-computing-machine/blob/main/results/benchmarks.asm.log#L2064 > > > > does not. Looking at the implementation > > < > https://github.com/openjdk/panama-vector/blob/2fd7943ec191559bfb2778305daf82bcc4422028/src/hotspot/cpu/x86/macroAssembler_x86.cpp#L6088-L6125 > > > > of the intrinsic in the JDK, The AVX 512 version uses *vpcmpeqb* but the > > AVX2 version does not (my machine does not have AVX 512 so it makes that > it > > was not emitted in the case of the intrinsic). Secondly, from the > assembly > > it seems that the Vector API version was unrolled but the intrinsic was > > not. If I am right, in general loop unrolling is better so the API seems > to > > be doing the right thing. Hence, I am not sure why this particular case > is > > an outlier. > > > > Further, Is analysing/comparing intrinsics within the JDK to the Vector > API > > useful? > > > > Also, any other suggestions regarding contributing to the Project are > > welcome. > > > > Regards, > > Kartik > > From vladimir.x.ivanov at oracle.com Fri Sep 10 10:34:31 2021 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 10 Sep 2021 13:34:31 +0300 Subject: CFV: New Panama Committer: Jie Fu In-Reply-To: <45B1ED7D-7A97-4F1E-8F4F-BDD15004EF49@oracle.com> References: <45B1ED7D-7A97-4F1E-8F4F-BDD15004EF49@oracle.com> Message-ID: <7a98432a-23d7-03c0-9be1-75388cddeb7b@oracle.com> Vote: yes Best regards, Vladimir Ivanov On 09.09.2021 19:47, Paul Sandoz wrote: > I hereby nominate Jie Fu (OpenJDK ID: jiefu, GitHub ID: DamonFool) [0] to Panama Committer. From duke at openjdk.java.net Fri Sep 10 11:06:15 2021 From: duke at openjdk.java.net (duke) Date: Fri, 10 Sep 2021 11:06:15 GMT Subject: git: openjdk/panama-foreign: master: 84 new changesets Message-ID: Changeset: 28ba78e6 Author: Vladimir Ivanov Date: 2021-09-03 12:05:00 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/28ba78e64721529fd764a7c09a7142a96c245f05 8244675: assert(IncrementalInline || (_late_inlines.length() == 0 && !has_mh_late_inlines())) Reviewed-by: dlong ! src/hotspot/share/opto/callGenerator.cpp ! src/hotspot/share/opto/doCall.cpp + test/hotspot/jtreg/compiler/vectorapi/TestNoInline.java Changeset: 8c379092 Author: Vicente Romero Date: 2021-09-03 13:11:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8c379092747301de70db1ef8e441cbe09fd742e7 8273234: extended 'for' with expression of type tvar causes the compiler to crash Reviewed-by: jlahoda ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java + test/langtools/tools/javac/foreach/ExprTypeIsTypeVariableTest.java Changeset: ff4018bc Author: Vicente Romero Date: 2021-09-03 15:20:23 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ff4018bc867841b566d619029fb637a128bc39a7 8268148: unchecked warnings handle ? and ? extends Object differently Reviewed-by: jlahoda ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java ! test/langtools/tools/javac/generics/inference/8176534/T8176534.out + test/langtools/tools/javac/warnings/UnboundAndBoundByObjectTest.java Changeset: 23fa0dcf Author: Albert Mingkun Yang Date: 2021-09-03 16:53:53 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/23fa0dcff062803d249c863b90a00744e3477656 8272905: Consolidate discovered lists processing Reviewed-by: tschatzl, kbarrett ! src/hotspot/share/gc/shared/referenceProcessor.cpp ! src/hotspot/share/gc/shared/referenceProcessor.hpp ! src/hotspot/share/gc/shared/referenceProcessorPhaseTimes.cpp Changeset: d414a88d Author: Yumin Qi Date: 2021-09-03 20:36:48 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d414a88d88a5734d6c431e74d735a780a90d60cf 8273240: Dynamic test ArchiveConsistency.java should use CDSArchiveUtils Reviewed-by: iklam ! test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/ArchiveConsistency.java ! test/lib/jdk/test/lib/cds/CDSArchiveUtils.java Changeset: 14a3ac09 Author: Dean Long Date: 2021-09-03 23:23:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/14a3ac09fe504ea97d269b78872bef6021c976fd 8271911: replay compilations of methods which use JSR292 (easy cases) 8012267: ciReplay: fails to resolve @SignaturePolymorphic methods in replay data 8012268: ciReplay: process_ciInstanceKlass: JVM_CONSTANT_MethodHandle not supported Reviewed-by: kvn, vlivanov ! src/hotspot/share/ci/ciEnv.cpp ! src/hotspot/share/ci/ciEnv.hpp ! src/hotspot/share/ci/ciInstanceKlass.cpp ! src/hotspot/share/ci/ciInstanceKlass.hpp ! src/hotspot/share/ci/ciMethod.cpp ! src/hotspot/share/ci/ciMethod.hpp ! src/hotspot/share/ci/ciMethodData.cpp ! src/hotspot/share/ci/ciReplay.cpp ! src/hotspot/share/ci/ciReplay.hpp ! test/hotspot/jtreg/compiler/ciReplay/CiReplayBase.java ! test/hotspot/jtreg/compiler/ciReplay/TestInlining.java Changeset: cec6c068 Author: Prasanta Sadhukhan Date: 2021-09-04 11:04:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/cec6c068b03d890312e50b448fbc26102c635249 8272232: javax/swing/JTable/4275046/bug4275046.java failed with "Expected value in the cell: 'rededited' but found 'redEDITED'." 8257540: javax/swing/JFileChooser/8041694/bug8041694.java failed with "RuntimeException: The selected directory name is not the expected 'd ' but 'D '." Reviewed-by: serb ! test/jdk/java/awt/List/ActionEventTest/ActionEventTest.java ! test/jdk/java/awt/dnd/RecognizedActionTest/RecognizedActionTest.java ! test/jdk/javax/swing/JFileChooser/8041694/bug8041694.java ! test/jdk/javax/swing/JRadioButton/8033699/bug8033699.java ! test/jdk/javax/swing/JTable/4275046/bug4275046.java Changeset: c640fe42 Author: lawrence.andrews Committer: Sergey Bylokhov Date: 2021-09-05 09:15:38 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c640fe42c2b5e6668a2a875678be44443942c868 7188098: TEST_BUG: closed/javax/sound/midi/Synthesizer/Receiver/bug6186488.java fails Reviewed-by: serb ! test/jdk/javax/sound/midi/Synthesizer/Receiver/bug6186488.java Changeset: 4d25e6f6 Author: Aleksey Shipilev Date: 2021-09-06 08:08:05 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4d25e6f6c7ee855771ab9c05ae85a9d92c866941 8273335: compiler/blackhole tests should not run with interpreter-only VMs Reviewed-by: kvn ! test/hotspot/jtreg/compiler/blackhole/BlackholeExistingIntrinsicWarningTest.java ! test/hotspot/jtreg/compiler/blackhole/BlackholeExperimentalUnlockTest.java ! test/hotspot/jtreg/compiler/blackhole/BlackholeIntrinsicTest.java ! test/hotspot/jtreg/compiler/blackhole/BlackholeNonEmptyWarningTest.java ! test/hotspot/jtreg/compiler/blackhole/BlackholeNonStaticWarningTest.java ! test/hotspot/jtreg/compiler/blackhole/BlackholeNonVoidWarningTest.java Changeset: b4e5b28b Author: Albert Mingkun Yang Date: 2021-09-06 08:11:34 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b4e5b28b860f10d3e028a2ab042d452db289064f 8273221: Guard GCIdMark against nested calls Reviewed-by: tschatzl, kbarrett ! src/hotspot/share/gc/shared/gcId.cpp ! src/hotspot/share/gc/shared/gcId.hpp Changeset: 70ed6c5b Author: Daniel Gredler Committer: Jayathirth D V Date: 2021-09-06 08:13:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/70ed6c5b8c52dc1c1c25967a09164a013bdb4bdd 8272878: JEP 381 cleanup: Remove unused Solaris code in sun.font.TrueTypeGlyphMapper Reviewed-by: prr, jdv ! src/java.desktop/share/classes/sun/font/TrueTypeGlyphMapper.java Changeset: fb5b144e Author: Thomas Schatzl Date: 2021-09-06 09:07:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fb5b144eca761d4b4c667efe05ca638536c065ac 8272985: Reference discovery is confused about atomicity and degree of parallelism Reviewed-by: ayang, kbarrett ! src/hotspot/share/gc/shared/referenceProcessor.cpp ! src/hotspot/share/gc/shared/referenceProcessor.hpp ! src/hotspot/share/gc/shared/referenceProcessor.inline.hpp Changeset: 1bf5bda2 Author: Markus Gr?nlund Date: 2021-09-06 09:13:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1bf5bda2919b3236040bf12c51eba552c6309cf7 8269418: jdk/jfr/event/oldobject/TestObjectSize.java failed with "RuntimeException: No events: expected false, was true" Reviewed-by: jbachorik ! test/jdk/ProblemList.txt ! test/jdk/jdk/jfr/event/oldobject/TestObjectSize.java Changeset: 44c5c23b Author: Dan Heidinga Committer: Aleksey Shipilev Date: 2021-09-06 13:39:03 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/44c5c23b96adf071339b39cfaea08c2d3a19d839 8272164: DumpAllocStats shouldn't subclass from ResourceObj Reviewed-by: shade, iklam, dholmes ! src/hotspot/share/cds/dumpAllocStats.hpp Changeset: 2cabec8d Author: Thomas Schatzl Date: 2021-09-06 14:28:54 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2cabec8ddc19dd66495957e7ef553990a502e993 8253343: Extract G1 Young GC algorithm related code from G1CollectedHeap Reviewed-by: ayang, 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/g1YoungCollector.cpp + src/hotspot/share/gc/g1/g1YoungCollector.hpp ! src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.cpp Changeset: 7bd4f496 Author: Patric Hedlin Date: 2021-09-06 14:43:54 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7bd4f496b493b804990615f6ce2cb1b4abd29a86 8264207: CodeStrings does not honour fixed address assumption. Reviewed-by: redestad, neliasso ! src/hotspot/share/asm/codeBuffer.cpp ! src/hotspot/share/asm/codeBuffer.hpp ! src/hotspot/share/code/codeBlob.cpp ! src/hotspot/share/code/codeBlob.hpp ! src/hotspot/share/code/icBuffer.hpp ! src/hotspot/share/code/stubs.cpp ! src/hotspot/share/code/stubs.hpp ! src/hotspot/share/compiler/disassembler.cpp ! src/hotspot/share/compiler/disassembler.hpp ! src/hotspot/share/interpreter/interpreter.cpp ! src/hotspot/share/interpreter/interpreter.hpp ! src/hotspot/share/interpreter/interpreterRuntime.cpp ! src/hotspot/share/runtime/sharedRuntime.cpp ! src/hotspot/share/runtime/stubCodeGenerator.cpp ! src/hotspot/share/runtime/stubCodeGenerator.hpp + test/hotspot/gtest/code/test_codestrings.cpp Changeset: fc546d6d Author: Aleksey Shipilev Date: 2021-09-06 16:00:12 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fc546d6de9a3ed33cf4b04e24e62714332b069cb 8273378: Shenandoah: Remove the remaining uses of os::is_MP Reviewed-by: aph, zgu ! src/hotspot/cpu/x86/gc/shenandoah/shenandoahBarrierSetAssembler_x86.cpp Changeset: eb221812 Author: Kim Barrett Date: 2021-09-06 18:19:58 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/eb221812b28c1c6da2e442292a4f7cb5226b62ba 8273386: Remove duplicated code in G1DCQS::abandon_completed_buffers Reviewed-by: tschatzl ! src/hotspot/share/gc/g1/g1DirtyCardQueue.cpp Changeset: 649c22c5 Author: Wang Huang Committer: Nick Gasson Date: 2021-09-07 01:40:24 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/649c22c5b17efbc3116ac34739b8d1be39de01be 8270832: Aarch64: Update algorithm annotations for MacroAssembler::fill_words Co-authored-by: Wang Huang Co-authored-by: Miu Zhuojun Co-authored-by: Wu Yan Reviewed-by: ngasson, aph ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp Changeset: 81c719be Author: Aleksey Shipilev Date: 2021-09-07 07:35:23 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/81c719be3995fa54974e8b8826ad81bf07bd012f 8273333: Zero should warn about unimplemented -XX:+LogTouchedMethods Reviewed-by: minqi, dholmes ! src/hotspot/share/runtime/arguments.cpp ! test/hotspot/jtreg/runtime/CommandLine/PrintTouchedMethods.java Changeset: 3cd95a29 Author: Leo Korinth Date: 2021-09-07 08:23:32 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3cd95a2932ab6a2cb39322354f7ad181de8bfc9e 8231356: Fix broken ResourceObj::operator new[] in debug builds Reviewed-by: kbarrett, iklam ! src/hotspot/share/memory/allocation.cpp ! src/hotspot/share/memory/allocation.hpp Changeset: a522d6b5 Author: Aleksey Shipilev Date: 2021-09-07 08:52:53 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a522d6b53cd841b4bfe87eac5778c9e5cdf5e90f 8273376: Zero: Disable vtable/itableStub gtests Reviewed-by: jiefu, stuefe ! test/hotspot/gtest/code/test_vtableStub.cpp Changeset: 5caa77b0 Author: Ivan ?ipka Committer: Daniel Fuchs Date: 2021-09-07 09:46:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5caa77b043ae490c3d7d56d181d0e07e6b859b9e 8263364: sun/net/www/http/KeepAliveStream/KeepAliveStreamCloseWithWrongContentLength.java wedged in getInputStream Reviewed-by: dfuchs ! test/jdk/sun/net/www/http/KeepAliveStream/KeepAliveStreamCloseWithWrongContentLength.java Changeset: 70157c78 Author: Jan Lahoda Date: 2021-09-07 09:50:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/70157c78a838126bb29c91a410d9158763bfa2ad 8272135: jshell: Method cannot use its overloaded version Reviewed-by: vromero ! src/jdk.jshell/share/classes/jdk/jshell/Eval.java ! src/jdk.jshell/share/classes/jdk/jshell/TaskFactory.java ! src/jdk.jshell/share/classes/jdk/jshell/TreeDissector.java ! test/langtools/jdk/jshell/MethodsTest.java Changeset: 377b1867 Author: Vladimir Ivanov Date: 2021-09-07 11:35:31 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/377b186724473475480b834d99c38b8161bf6917 8269119: C2: Avoid redundant memory barriers in Unsafe.copyMemory0 intrinsic Reviewed-by: thartmann, roland ! src/hotspot/share/opto/library_call.cpp + test/hotspot/jtreg/compiler/unsafe/UnsafeCopyMemory.java Changeset: 041ae20b Author: Fernando Guallini Committer: Rajan Halade Date: 2021-09-07 14:36:15 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/041ae20b10e11381415e8f61fd39e9e19aa8d4f2 8268558: [TESTBUG] Case 2 in TestP11KeyFactoryGetRSAKeySpec is skipped Reviewed-by: mullan, rhalade ! test/jdk/sun/security/pkcs11/rsa/TestP11KeyFactoryGetRSAKeySpec.java Changeset: 99fb12c7 Author: Roland Westrelin Date: 2021-09-07 15:13:12 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/99fb12c798ad24cc4a671a666930ba42c3cd10c9 8271341: Opcode() != Op_If && Opcode() != Op_RangeCheck) || outcnt() == 2 assert failure with Test7179138_1.java Reviewed-by: kvn, thartmann ! src/hotspot/share/opto/stringopts.cpp ! test/hotspot/jtreg/compiler/c2/Test7179138_1.java Changeset: 2abf3b3b Author: Roland Westrelin Date: 2021-09-07 15:15:17 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2abf3b3b2743947282300ee8416611559e49fca0 8271340: Crash PhaseIdealLoop::clone_outer_loop Reviewed-by: kvn, thartmann ! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp ! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.hpp ! src/hotspot/share/opto/cfgnode.cpp + test/hotspot/jtreg/compiler/loopopts/TestInfiniteLoopCCP.java Changeset: df05b4d1 Author: Prasanta Sadhukhan Date: 2021-09-07 15:50:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/df05b4d1a13e55755107695ad9ea7a8a1084901a 8271923: [macos] the text color on the selected disabled tabbed pane button remains white making text unreadable Reviewed-by: jdv ! src/java.desktop/macosx/classes/com/apple/laf/AquaLookAndFeel.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaTabbedPaneContrastUI.java Changeset: 270a9d92 Author: Alexey Ivanov Date: 2021-09-07 19:05:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/270a9d929307dce52e6961e57492c03a633ed044 8273043: [TEST_BUG] Automate NimbusJTreeSelTextColor.java Reviewed-by: serb ! test/jdk/javax/swing/plaf/nimbus/NimbusJTreeSelTextColor.java Changeset: 708407ed Author: Andrey Turbanov Committer: Alexey Ivanov Date: 2021-09-07 21:12:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/708407eddc9d52c01de02e3986c05e1c6225fa85 8273168: Remove superfluous use of boxing in java.desktop Reviewed-by: aivanov ! src/java.desktop/share/classes/com/sun/imageio/plugins/png/PNGMetadata.java ! src/java.desktop/share/classes/java/awt/Font.java ! src/java.desktop/share/classes/javax/swing/text/html/CSS.java ! src/java.desktop/share/classes/javax/swing/text/html/HTML.java ! src/java.desktop/share/classes/sun/awt/datatransfer/DataTransferer.java ! src/java.desktop/unix/classes/sun/print/PrintServiceLookupProvider.java ! src/java.desktop/windows/classes/sun/awt/windows/WPathGraphics.java Changeset: d6d6c069 Author: Mark Sheppard Date: 2021-09-07 22:18:23 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d6d6c0692bff77bd18127ed61455aac39370a089 8273246: Amend the test java/nio/channels/DatagramChannel/ManySourcesAndTargets.java to execute in othervm mode Reviewed-by: alanb ! test/failure_handler/src/share/conf/mac.properties ! test/jdk/java/nio/channels/DatagramChannel/ManySourcesAndTargets.java Changeset: 8884d2f8 Author: Daniel D. Daugherty Date: 2021-09-08 00:34:11 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8884d2f854fafdc5f775fce557053d072e4a882c 8273462: ProblemList vmTestbase/vm/mlvm/anonloader/stress/oome/heap/Test.java in -Xcomp mode Reviewed-by: dholmes ! test/hotspot/jtreg/ProblemList-Xcomp.txt Changeset: 4eacdb38 Author: Yasumasa Suenaga Date: 2021-09-08 01:27:13 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4eacdb38a83b545603928392eccb116c744ef3b3 8273104: Refactoring option parser for UL Reviewed-by: iklam, dholmes ! src/hotspot/share/logging/logFileOutput.cpp ! src/hotspot/share/logging/logFileOutput.hpp ! src/hotspot/share/logging/logFileStreamOutput.cpp ! src/hotspot/share/logging/logFileStreamOutput.hpp ! src/hotspot/share/logging/logOutput.cpp ! src/hotspot/share/logging/logOutput.hpp ! test/hotspot/jtreg/runtime/logging/FoldMultilinesTest.java Changeset: ea4907a8 Author: Daniel D. Daugherty Date: 2021-09-08 02:13:41 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ea4907a8789e00f9ec8d4175241246b8cf53f3f6 8273047: test jfr/api/consumer/TestRecordedFrame.java timing out Reviewed-by: dholmes ! test/jdk/jdk/jfr/api/consumer/TestRecordedFrame.java Changeset: 1513dc7a Author: Andrey Turbanov Committer: Sergey Bylokhov Date: 2021-09-08 04:36:41 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1513dc7afc33386106439ccb9b7b16956b3c534a 8271603: Unnecessary Vector usage in java.desktop Reviewed-by: prr, serb ! src/java.desktop/macosx/classes/com/apple/laf/AquaFileChooserUI.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/common/SimpleRenderedImage.java ! src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKFileChooserUI.java ! src/java.desktop/share/classes/com/sun/media/sound/AbstractMixer.java ! src/java.desktop/share/classes/com/sun/media/sound/AlawCodec.java ! src/java.desktop/share/classes/com/sun/media/sound/PCMtoPCMCodec.java ! src/java.desktop/share/classes/com/sun/media/sound/UlawCodec.java ! src/java.desktop/share/classes/java/awt/Menu.java ! src/java.desktop/share/classes/java/awt/Window.java ! src/java.desktop/share/classes/javax/print/MimeType.java ! src/java.desktop/share/classes/javax/sound/sampled/AudioSystem.java ! src/java.desktop/share/classes/javax/swing/JFileChooser.java ! src/java.desktop/share/classes/javax/swing/JMenu.java ! src/java.desktop/share/classes/javax/swing/JMenuBar.java ! src/java.desktop/share/classes/javax/swing/JOptionPane.java ! src/java.desktop/share/classes/javax/swing/JPopupMenu.java ! src/java.desktop/share/classes/javax/swing/UIManager.java ! src/java.desktop/share/classes/javax/swing/plaf/metal/MetalFileChooserUI.java ! src/java.desktop/share/classes/javax/swing/text/AbstractDocument.java ! src/java.desktop/share/classes/javax/swing/text/DefaultStyledDocument.java ! src/java.desktop/share/classes/javax/swing/text/JTextComponent.java ! src/java.desktop/share/classes/javax/swing/text/ZoneView.java ! src/java.desktop/share/classes/javax/swing/text/html/AccessibleHTML.java ! src/java.desktop/share/classes/javax/swing/text/html/CSS.java ! src/java.desktop/share/classes/javax/swing/text/rtf/RTFAttributes.java ! src/java.desktop/share/classes/javax/swing/text/rtf/RTFGenerator.java ! src/java.desktop/share/classes/javax/swing/undo/StateEdit.java ! src/java.desktop/share/classes/sun/awt/PlatformFont.java ! src/java.desktop/share/classes/sun/awt/shell/ShellFolder.java ! src/java.desktop/share/classes/sun/swing/plaf/synth/SynthFileChooserUIImpl.java ! src/java.desktop/unix/classes/sun/awt/X11/XWindowPeer.java ! src/java.desktop/unix/classes/sun/print/PrintServiceLookupProvider.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsFileChooserUI.java ! src/java.desktop/windows/classes/sun/awt/Win32GraphicsDevice.java Changeset: 7d24a334 Author: Aleksey Shipilev Date: 2021-09-08 07:43:28 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7d24a3342129d4c71fad0d8d50d20758291d64b7 8273318: Some containers/docker/TestJFREvents.java configs are running out of memory Reviewed-by: ngasson, sgehwolf, mseledtsov ! test/hotspot/jtreg/containers/docker/TestJFREvents.java Changeset: 286a1f6b Author: Aleksey Shipilev Date: 2021-09-08 07:44:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/286a1f6b7c6d7c598ced456f1a5f63cac1be8539 8273440: Zero: Disable runtime/Unsafe/InternalErrorTest.java Reviewed-by: dholmes ! test/hotspot/jtreg/runtime/Unsafe/InternalErrorTest.java Changeset: a66629a4 Author: Hamlin Li Date: 2021-09-08 08:01:18 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a66629a464b97176bcdc2ca1150d12df6241dc1c 8254167: G1: Record regions where evacuation failed to provide targeted iteration Reviewed-by: tschatzl, ayang ! 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/g1CollectionSet.cpp ! src/hotspot/share/gc/g1/g1CollectionSet.hpp ! src/hotspot/share/gc/g1/g1EvacFailure.cpp ! src/hotspot/share/gc/g1/g1EvacFailure.hpp + src/hotspot/share/gc/g1/g1EvacFailureRegions.cpp + src/hotspot/share/gc/g1/g1EvacFailureRegions.hpp + src/hotspot/share/gc/g1/g1EvacFailureRegions.inline.hpp ! src/hotspot/share/gc/g1/g1ParScanThreadState.cpp ! src/hotspot/share/gc/g1/g1ParScanThreadState.hpp ! src/hotspot/share/gc/g1/g1YoungCollector.cpp ! src/hotspot/share/gc/g1/g1YoungCollector.hpp ! src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.cpp ! src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.hpp Changeset: 6750c34c Author: Andrew Haley Date: 2021-09-08 10:08:30 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6750c34c92b5f28bba4a88ac798b800fce380d32 8270533: AArch64: size_fits_all_mem_uses should return false if its output is a CAS Reviewed-by: adinn, ngasson ! src/hotspot/cpu/aarch64/aarch64.ad Changeset: 18555742 Author: Markus Karg Committer: Alan Bateman Date: 2021-09-08 11:22:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/185557423d3069d627daecdf87315a49d6597b67 8273038: ChannelInputStream.transferTo() uses FileChannel.transferTo(FileChannel) Reviewed-by: alanb ! src/java.base/share/classes/java/nio/channels/Channels.java ! src/java.base/share/classes/sun/nio/ch/ChannelInputStream.java + src/java.base/share/classes/sun/nio/ch/ChannelOutputStream.java + test/jdk/java/nio/channels/Channels/TransferTo.java Changeset: 21012f2b Author: Vladimir Ivanov Date: 2021-09-08 11:27:14 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/21012f2bbe214955d05f8bc583dcdceb0949b601 8078641: MethodHandle.asTypeCache can retain classes from unloading Co-authored-by: Peter Levart Co-authored-by: Vladimir Ivanov Reviewed-by: psandoz, mchung, plevart ! src/java.base/share/classes/java/lang/invoke/MethodHandle.java ! src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java Changeset: faa942c8 Author: Vladimir Ivanov Date: 2021-09-08 11:28:17 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/faa942c8ba8ad778b6be20ff6d98a5040a9079e9 8273000: Remove WeakReference-based class initialisation barrier implementation Reviewed-by: psandoz, mchung ! src/java.base/share/classes/java/lang/invoke/DirectMethodHandle.java ! src/java.base/share/classes/jdk/internal/misc/Unsafe.java Changeset: 59c9f750 Author: Andrey Turbanov Committer: Alexey Ivanov Date: 2021-09-08 14:28:07 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/59c9f750414e4f131c906a5bc20f32f2f9cfe9ec 8273375: Remove redundant 'new String' calls after concatenation in java.desktop Reviewed-by: aivanov ! src/java.desktop/macosx/classes/com/apple/laf/AquaTabbedPaneCopyFromBasicUI.java ! src/java.desktop/macosx/classes/sun/java2d/IntegerNIORaster.java ! src/java.desktop/share/classes/java/awt/image/ColorModel.java ! src/java.desktop/share/classes/java/awt/image/DirectColorModel.java ! src/java.desktop/share/classes/java/awt/image/IndexColorModel.java ! src/java.desktop/share/classes/sun/awt/image/ByteBandedRaster.java ! src/java.desktop/share/classes/sun/awt/image/ByteComponentRaster.java ! src/java.desktop/share/classes/sun/awt/image/ByteInterleavedRaster.java ! src/java.desktop/share/classes/sun/awt/image/BytePackedRaster.java ! src/java.desktop/share/classes/sun/awt/image/IntegerComponentRaster.java ! src/java.desktop/share/classes/sun/awt/image/IntegerInterleavedRaster.java ! src/java.desktop/share/classes/sun/awt/image/ShortBandedRaster.java ! src/java.desktop/share/classes/sun/awt/image/ShortComponentRaster.java ! src/java.desktop/share/classes/sun/awt/image/ShortInterleavedRaster.java ! src/java.desktop/unix/classes/sun/awt/X11/InfoWindow.java Changeset: f2f8136c Author: jtfuller111 Committer: Tobias Hartmann Date: 2021-09-08 14:38:21 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f2f8136cc9f5a3f554f704024748a09cb80bd037 8265443: IGV: disambiguate groups by emiting additional properties Reviewed-by: thartmann ! src/hotspot/share/opto/idealGraphPrinter.cpp ! src/hotspot/share/opto/idealGraphPrinter.hpp Changeset: 7e662e7b Author: Wang Huang Committer: Tobias Hartmann Date: 2021-09-08 14:39:23 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7e662e7b9d7ea5113f568418e0acac4234ebfb88 8272413: Incorrect num of element count calculation for vector cast Co-authored-by: Wang Huang Co-authored-by: Miu Zhuojun Co-authored-by: Wu Yan Reviewed-by: eliu, kvn ! src/hotspot/share/opto/vectorIntrinsics.cpp Changeset: cb112aff Author: Masanori Yano Committer: Naoto Sato Date: 2021-09-08 15:46:33 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/cb112affd6061e8ace6dad4e92c7b394a413e37f 8269373: some tests in jdk/tools/launcher/ fails on localized Windows platform Reviewed-by: naoto ! test/jdk/tools/launcher/FXLauncherTest.java ! test/jdk/tools/launcher/SourceMode.java Changeset: e5f298a7 Author: Sergey Tsypanov Committer: Naoto Sato Date: 2021-09-08 15:54:36 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e5f298a7f1f3106b72e43c152c090af1657485f0 8273329: Remove redundant null check from String.getBytes(String charsetName) Reviewed-by: rriggs, iris, naoto ! src/java.base/share/classes/java/lang/String.java Changeset: d7efd0e8 Author: Sandhya Viswanathan Date: 2021-09-08 16:07:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d7efd0e8cf14c732427d2c1363b60278bebdc06a 8273450: Fix the copyright header of SVML files Reviewed-by: dholmes, psandoz ! 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/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: f7e9f56e Author: Vladimir Ivanov Date: 2021-09-08 16:17:56 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f7e9f56e235dc50daae0a85c9790d5b04c9c60f0 8273359: CI: ciInstanceKlass::get_canonical_holder() doesn't respect instance size Reviewed-by: kvn ! src/hotspot/share/c1/c1_LIRGenerator.cpp ! src/hotspot/share/ci/ciInstanceKlass.cpp ! src/hotspot/share/ci/ciInstanceKlass.hpp ! src/hotspot/share/opto/compile.cpp + test/hotspot/jtreg/compiler/unsafe/AlignmentGapAccess.java Changeset: 267c61a1 Author: Aleksey Shipilev Date: 2021-09-08 16:36:31 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/267c61a16a916e35762e8df5737ec74b06defae8 8273361: InfoOptsTest is failing in tier1 Reviewed-by: jpai, ihse, jlahoda ! test/langtools/tools/javac/options/modes/InfoOptsTest.java ! test/langtools/tools/javac/options/modes/OptionModesTester.java Changeset: 4d5e1ed9 Author: Jonathan Gibbons Date: 2021-09-08 17:38:05 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4d5e1ed9589713bdae5ebe659e657b9c6b833c3f 8272375: Improve phrasing of synthesized descriptions in JavaFX docs Reviewed-by: kcr, prappo ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties ! test/langtools/jdk/javadoc/doclet/testJavaFX/TestJavaFX.java ! test/langtools/jdk/javadoc/doclet/testJavaFX/TestJavaFXCombo.java ! test/langtools/jdk/javadoc/doclet/testJavaFX/TestJavaFXMissingPropComments.java Changeset: ba31eee4 Author: Daniel D. Daugherty Date: 2021-09-08 18:33:04 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ba31eee4fc92bba3657e5f3fec2b85f55120d7a1 8273109: runtime/cds/appcds/loaderConstraints/DynamicLoaderConstraintsTest times out Reviewed-by: bpb ! test/hotspot/jtreg/runtime/cds/appcds/loaderConstraints/DynamicLoaderConstraintsTest.java Changeset: e6805032 Author: Thomas Schatzl Date: 2021-09-08 19:02:49 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e6805032ff328773eafe8b94e9f1b3b196f52196 8273185: Rename the term "atomic" in ReferenceProcessor Reviewed-by: ayang, shade ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/parallel/psScavenge.cpp ! src/hotspot/share/gc/shared/referenceProcessor.cpp ! src/hotspot/share/gc/shared/referenceProcessor.hpp Changeset: 9b5991e8 Author: Leonid Mesnik Date: 2021-09-08 19:30:17 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9b5991e811b789fe8b60701657c2f0dd2c222c2e 8273451: Remove unreachable return in mutexLocker::wait Reviewed-by: minqi, coleenp ! src/hotspot/share/runtime/mutexLocker.hpp Changeset: a5e4def5 Author: Leonid Mesnik Date: 2021-09-08 19:31:18 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a5e4def526697d88ff31a5fdb41d823b899372f2 8265489: Stress test times out because of long ObjectSynchronizer::monitors_iterate(...) operation Reviewed-by: dcubed ! src/hotspot/share/prims/jvmtiEnvBase.cpp ! src/hotspot/share/prims/jvmtiEnvBase.hpp ! src/hotspot/share/runtime/synchronizer.cpp ! src/hotspot/share/runtime/synchronizer.hpp ! src/hotspot/share/services/threadService.cpp Changeset: 7fd6b0bf Author: Roger Riggs Date: 2021-09-08 20:53:25 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7fd6b0bfd8ab3c64b374c71010bdfa369f0c67e8 8273242: (test) Refactor to use TestNG for RuntimeTests ExecCommand tests Reviewed-by: naoto, lancea ! test/jdk/java/lang/RuntimeTests/exec/ExecCommand.java Changeset: 12f0b771 Author: Daniel D. Daugherty Date: 2021-09-09 00:39:40 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/12f0b771791614b8a41fc2c62d34481f911109b0 8273516: ProblemList compiler/c2/Test7179138_1.java in -Xcomp mode on win-X64 Reviewed-by: dholmes ! test/hotspot/jtreg/ProblemList-Xcomp.txt Changeset: 5df26480 Author: Hamlin Li Date: 2021-09-09 00:41:28 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5df26480864f1efd16eb5800833bf7106371b97a 8273218: G1: Rename g1EvacuationInfo to g1EvacInfo Reviewed-by: tschatzl, ayang ! src/hotspot/share/gc/g1/g1Allocator.cpp ! src/hotspot/share/gc/g1/g1Allocator.hpp = src/hotspot/share/gc/g1/g1EvacInfo.hpp ! src/hotspot/share/gc/g1/g1Trace.cpp ! src/hotspot/share/gc/g1/g1Trace.hpp ! src/hotspot/share/gc/g1/g1YoungCollector.cpp ! src/hotspot/share/gc/g1/g1YoungCollector.hpp ! src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.cpp ! src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.hpp Changeset: 6eba4434 Author: Matthias Baesken Date: 2021-09-09 06:15:15 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6eba443428ff7abe7c0509047ec76432affebe65 8273387: remove some unreferenced gtk-related functions Reviewed-by: pbansal, clanger ! src/java.desktop/unix/native/libawt_xawt/awt/gtk2_interface.c ! src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.c Changeset: 5b1dfe4e Author: Thomas Schatzl Date: 2021-09-09 07:28:23 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5b1dfe4e358d249aef9330e39b6404a13b4ebc0e 8273439: Fix G1CollectedHeap includes and forward declarations Reviewed-by: ayang, kbarrett ! src/hotspot/share/gc/g1/g1CollectedHeap.hpp Changeset: dc33bd8b Author: Aleksey Shipilev Date: 2021-09-09 07:43:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/dc33bd8b6cfa9a9cd71d7065d284a807774750a2 8273315: Parallelize and increase timeouts for java/foreign/TestMatrix.java test Reviewed-by: mcimadamore ! test/jdk/java/foreign/TestMatrix.java Changeset: 8c16f485 Author: Aleksey Shipilev Date: 2021-09-09 08:07:00 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8c16f485b341ee3071c91df39dfb9ba8b9caa44d 8273487: Zero: Handle "zero" variant in runtime tests Reviewed-by: alanb, dholmes ! test/lib/jdk/test/lib/Platform.java Changeset: aa931118 Author: Aleksey Shipilev Date: 2021-09-09 09:46:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/aa9311182ae88312a70b18afd85939718415b77c 8273483: Zero: Clear pending JNI exception check in native method handler Reviewed-by: aph ! src/hotspot/cpu/zero/zeroInterpreter_zero.cpp Changeset: 00e059dd Author: Evan Whelan Committer: Daniel Fuchs Date: 2021-09-09 10:23:12 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/00e059ddb34b5f2d6ba1ea0f38308c5b382a8e4d 8133686: HttpURLConnection.getHeaderFields and URLConnection.getRequestProperties methods return field values in reverse order Reviewed-by: dfuchs ! src/java.base/share/classes/java/net/URLConnection.java ! src/java.base/share/classes/sun/net/www/MessageHeader.java + test/jdk/java/net/HttpURLConnection/HttpURLConnectionHeadersOrder.java ! test/jdk/java/net/URLConnection/RequestPropertyValues.java ! test/jdk/java/net/URLConnection/URLConnectionHeaders.java + test/jdk/java/net/URLConnection/URLConnectionHeadersOrder.java ! test/jdk/sun/net/www/MessageHeaderTest.java Changeset: 9690df7f Author: Hamlin Li Date: 2021-09-09 10:41:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9690df7fb9843bdc4775a34d94b2ca81f40aea0a 8273476: G1: refine G1CollectedHeap::par_iterate_regions_array_part_from Reviewed-by: ayang, tschatzl ! 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/g1EvacFailureRegions.cpp Changeset: f6cc1732 Author: Martin Doerr Date: 2021-09-09 10:48:02 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f6cc1732f47672cea413fa842c4f106c1314c626 8273539: [PPC64] gtest build error after JDK-8264207 Reviewed-by: shade, stuefe ! test/hotspot/gtest/code/test_codestrings.cpp Changeset: 5ca26cbd Author: Aleksey Shipilev Date: 2021-09-09 13:41:46 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5ca26cbddbdd47a73cc141a6215dc89c53841d4a 8273433: Enable parallelism in vmTestbase_nsk_sysdict tests Reviewed-by: mseledtsov, dholmes - test/hotspot/jtreg/vmTestbase/nsk/sysdict/vm/stress/btree/btree001/TEST.properties - test/hotspot/jtreg/vmTestbase/nsk/sysdict/vm/stress/btree/btree002/TEST.properties - test/hotspot/jtreg/vmTestbase/nsk/sysdict/vm/stress/btree/btree003/TEST.properties - test/hotspot/jtreg/vmTestbase/nsk/sysdict/vm/stress/btree/btree004/TEST.properties - test/hotspot/jtreg/vmTestbase/nsk/sysdict/vm/stress/btree/btree005/TEST.properties - test/hotspot/jtreg/vmTestbase/nsk/sysdict/vm/stress/btree/btree006/TEST.properties - test/hotspot/jtreg/vmTestbase/nsk/sysdict/vm/stress/btree/btree007/TEST.properties - test/hotspot/jtreg/vmTestbase/nsk/sysdict/vm/stress/btree/btree008/TEST.properties - test/hotspot/jtreg/vmTestbase/nsk/sysdict/vm/stress/btree/btree009/TEST.properties - test/hotspot/jtreg/vmTestbase/nsk/sysdict/vm/stress/btree/btree010/TEST.properties - test/hotspot/jtreg/vmTestbase/nsk/sysdict/vm/stress/btree/btree011/TEST.properties - test/hotspot/jtreg/vmTestbase/nsk/sysdict/vm/stress/btree/btree012/TEST.properties - test/hotspot/jtreg/vmTestbase/nsk/sysdict/vm/stress/chain/chain001/TEST.properties - test/hotspot/jtreg/vmTestbase/nsk/sysdict/vm/stress/chain/chain002/TEST.properties - test/hotspot/jtreg/vmTestbase/nsk/sysdict/vm/stress/chain/chain003/TEST.properties - test/hotspot/jtreg/vmTestbase/nsk/sysdict/vm/stress/chain/chain004/TEST.properties - test/hotspot/jtreg/vmTestbase/nsk/sysdict/vm/stress/chain/chain005/TEST.properties - test/hotspot/jtreg/vmTestbase/nsk/sysdict/vm/stress/chain/chain006/TEST.properties - test/hotspot/jtreg/vmTestbase/nsk/sysdict/vm/stress/chain/chain007/TEST.properties - test/hotspot/jtreg/vmTestbase/nsk/sysdict/vm/stress/chain/chain008/TEST.properties Changeset: 4866eaa9 Author: Tobias Hartmann Date: 2021-09-09 13:44:05 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4866eaa997b2ee2a47bdcd0d96202f220fb2774d 8273409: Receiver type narrowed by CCP does not always trigger post-parse call devirtualization Reviewed-by: vlivanov, neliasso ! src/hotspot/share/opto/phaseX.cpp + test/hotspot/jtreg/compiler/c2/irTests/TestPostParseCallDevirtualization.java ! test/hotspot/jtreg/compiler/lib/ir_framework/IRNode.java Changeset: c81690d7 Author: Tobias Hartmann Date: 2021-09-09 13:54:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c81690d7166c32caff6ef3a55fe9b157049e2b56 8273498: compiler/c2/Test7179138_1.java timed out Reviewed-by: roland ! test/hotspot/jtreg/ProblemList-Xcomp.txt ! test/hotspot/jtreg/compiler/c2/Test7179138_1.java Changeset: e3bda63c Author: Aleksey Shipilev Date: 2021-09-09 17:19:14 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e3bda63ce29bac0eaea520d42f4927dda77f83f2 8273489: Zero: Handle UseHeavyMonitors on all monitorenter paths Reviewed-by: coleenp ! src/hotspot/cpu/zero/zeroInterpreter_zero.cpp Changeset: 96614da0 Author: Maurizio Cimadamore Date: 2021-09-09 17:28:06 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/96614da0254e7fd4ac9dd3c3059bf23c1aaf37ff 8272903: Missing license header in ArenaAllocator.java Reviewed-by: bpb, lancea ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/ArenaAllocator.java Changeset: ef4a5328 Author: Saravana Kumar Vijayasekaran Committer: Erik Joelsson Date: 2021-09-09 18:24:26 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ef4a532802096f3958567c2ed22c1b317ac21fbe 8263773: Reenable German localization for builds at Oracle Reviewed-by: erikj, ihse ! make/conf/jib-profiles.js ! test/jdk/build/translations/VerifyTranslations.java Changeset: dd1209e4 Author: Vicente Romero Date: 2021-09-09 18:36:17 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/dd1209e4ae3c8e42d121329639ec4bd359d0a456 8268885: duplicate checkcast when destination type is not first type of intersection type Reviewed-by: jlahoda ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransTypes.java ! test/langtools/tools/javac/cast/intersection/DuplicatedCheckcastTest.java Changeset: 185eacac Author: Per Liden Date: 2021-09-09 19:19:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/185eacacdde9de12936520a1cda847f7e541c62f 8273545: Remove Thread::is_GC_task_thread() Reviewed-by: stefank, coleenp, shade ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp ! src/hotspot/share/gc/parallel/parallelScavengeHeap.hpp ! src/hotspot/share/gc/parallel/psParallelCompact.cpp ! src/hotspot/share/gc/shared/workgroup.cpp ! src/hotspot/share/gc/shared/workgroup.hpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoahWorkGroup.hpp ! src/hotspot/share/gc/z/zCollectedHeap.cpp ! src/hotspot/share/gc/z/zRuntimeWorkers.cpp ! src/hotspot/share/gc/z/zWorkers.cpp ! src/hotspot/share/runtime/thread.hpp ! test/hotspot/gtest/gc/g1/test_g1BatchedGangTask.cpp ! test/hotspot/gtest/gc/g1/test_g1CardSet.cpp ! test/hotspot/gtest/gc/g1/test_stressCommitUncommit.cpp ! test/hotspot/gtest/gc/shared/test_oopStorage.cpp ! test/hotspot/gtest/gc/shared/test_oopStorage_parperf.cpp Changeset: 4020a60c Author: Per Liden Date: 2021-09-09 19:21:55 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4020a60cbb3db0458262212d46515c8c11492a5b 8273550: Replace os::cgc_thread/pgc_thread with os::gc_thread Reviewed-by: stefank, coleenp ! src/hotspot/os/posix/os_posix.cpp ! src/hotspot/os/windows/os_windows.cpp ! src/hotspot/share/gc/shared/concurrentGCThread.cpp ! src/hotspot/share/gc/shared/workgroup.cpp ! src/hotspot/share/runtime/os.hpp Changeset: 54dee132 Author: Naoto Sato Date: 2021-09-09 19:41:56 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/54dee132d1a149165e7478b29b740d086c18c424 8273188: java/lang/instrument/BootClassPath/BootClassPathTest.sh fails with "FATAL ERROR in native method: processing of -javaagent failed, processJavaStart failed" Reviewed-by: dholmes, alanb ! src/java.instrument/share/native/libinstrument/EncodingSupport.h ! src/java.instrument/share/native/libinstrument/InvocationAdapter.c ! src/java.instrument/share/native/libinstrument/JPLISAgent.c ! src/java.instrument/unix/native/libinstrument/EncodingSupport_md.c ! src/java.instrument/windows/native/libinstrument/EncodingSupport_md.c ! test/jdk/ProblemList.txt ! test/jdk/java/lang/instrument/BootClassPath/BootClassPathTest.sh ! test/jdk/java/lang/instrument/BootClassPath/Setup.java Changeset: 2e321dc7 Author: Andrey Turbanov Committer: Sergey Bylokhov Date: 2021-09-09 21:47:59 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2e321dc782e0de9995b1772e4cee9c0304bc183d 8273528: Avoid ByteArrayOutputStream.toByteArray when converting stream to String Reviewed-by: bpb, xuelei, serb, aivanov ! src/java.base/share/classes/sun/security/util/BitArray.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/png/PNGImageReader.java ! src/java.desktop/share/classes/sun/awt/DebugSettings.java ! src/java.desktop/share/classes/sun/awt/datatransfer/DataTransferer.java Changeset: 08f0be83 Author: matias9927 Committer: Coleen Phillimore Date: 2021-09-10 01:05:37 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/08f0be8388914901ac40525ed995136ce020f432 8272608: java_lang_System::allow_security_manager() doesn't set its initialization flag Reviewed-by: coleenp, dholmes ! src/hotspot/share/classfile/javaClasses.cpp Changeset: 70c9e026 Author: Pankaj Bansal Date: 2021-09-10 06:13:32 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/70c9e026b63aadf9a2bfcbda45c2b9ea866afafa 8272148: JDesktopPane:getComponentCount() returns one extra than expected with GTKLookAndFeel Reviewed-by: prr, serb ! src/java.desktop/share/classes/javax/swing/JComponent.java Changeset: 792281d5 Author: Tobias Holenstein Committer: Tobias Hartmann Date: 2021-09-10 07:43:15 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/792281d559ca1f01493775fdfc2a6ed09b3b883d 8264517: C2: make MachCallNode::return_value_is_used() only available for x86 Reviewed-by: kvn, thartmann ! src/hotspot/share/opto/machnode.cpp ! src/hotspot/share/opto/machnode.hpp Changeset: 2eaf374c Author: Tobias Holenstein Committer: Tobias Hartmann Date: 2021-09-10 07:44:12 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2eaf374c5ce08287311cfac8145f97bf839365a7 8272698: LoadNode::pin is unused Reviewed-by: roland, thartmann ! src/hotspot/share/opto/memnode.hpp Changeset: c1e39faa Author: Per Liden Date: 2021-09-10 09:49:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c1e39faaa99ee62ff626ffec9f978ed0f8ffaca1 8273482: Remove "foreground work" concept from WorkGang Reviewed-by: tschatzl, kbarrett ! src/hotspot/share/gc/shared/workgroup.cpp ! src/hotspot/share/gc/shared/workgroup.hpp ! src/hotspot/share/gc/shenandoah/shenandoahCodeRoots.cpp ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.cpp ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.inline.hpp ! src/hotspot/share/services/heapDumper.cpp Changeset: 0985887f Author: duke Date: 2021-09-10 11:00:57 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0985887fa38b7a5e6a37012042e7a00b67a9f025 Automatic merge of jdk:master into master From duke at openjdk.java.net Fri Sep 10 11:12:56 2021 From: duke at openjdk.java.net (duke) Date: Fri, 10 Sep 2021 11:12:56 GMT Subject: git: openjdk/panama-foreign: foreign-jextract: 86 new changesets Message-ID: <1c78a88a-570b-498c-a88b-c33532cfa893@openjdk.org> Changeset: 28ba78e6 Author: Vladimir Ivanov Date: 2021-09-03 12:05:00 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/28ba78e64721529fd764a7c09a7142a96c245f05 8244675: assert(IncrementalInline || (_late_inlines.length() == 0 && !has_mh_late_inlines())) Reviewed-by: dlong ! src/hotspot/share/opto/callGenerator.cpp ! src/hotspot/share/opto/doCall.cpp + test/hotspot/jtreg/compiler/vectorapi/TestNoInline.java Changeset: 8c379092 Author: Vicente Romero Date: 2021-09-03 13:11:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8c379092747301de70db1ef8e441cbe09fd742e7 8273234: extended 'for' with expression of type tvar causes the compiler to crash Reviewed-by: jlahoda ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java + test/langtools/tools/javac/foreach/ExprTypeIsTypeVariableTest.java Changeset: ff4018bc Author: Vicente Romero Date: 2021-09-03 15:20:23 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ff4018bc867841b566d619029fb637a128bc39a7 8268148: unchecked warnings handle ? and ? extends Object differently Reviewed-by: jlahoda ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java ! test/langtools/tools/javac/generics/inference/8176534/T8176534.out + test/langtools/tools/javac/warnings/UnboundAndBoundByObjectTest.java Changeset: 23fa0dcf Author: Albert Mingkun Yang Date: 2021-09-03 16:53:53 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/23fa0dcff062803d249c863b90a00744e3477656 8272905: Consolidate discovered lists processing Reviewed-by: tschatzl, kbarrett ! src/hotspot/share/gc/shared/referenceProcessor.cpp ! src/hotspot/share/gc/shared/referenceProcessor.hpp ! src/hotspot/share/gc/shared/referenceProcessorPhaseTimes.cpp Changeset: d414a88d Author: Yumin Qi Date: 2021-09-03 20:36:48 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d414a88d88a5734d6c431e74d735a780a90d60cf 8273240: Dynamic test ArchiveConsistency.java should use CDSArchiveUtils Reviewed-by: iklam ! test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/ArchiveConsistency.java ! test/lib/jdk/test/lib/cds/CDSArchiveUtils.java Changeset: 14a3ac09 Author: Dean Long Date: 2021-09-03 23:23:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/14a3ac09fe504ea97d269b78872bef6021c976fd 8271911: replay compilations of methods which use JSR292 (easy cases) 8012267: ciReplay: fails to resolve @SignaturePolymorphic methods in replay data 8012268: ciReplay: process_ciInstanceKlass: JVM_CONSTANT_MethodHandle not supported Reviewed-by: kvn, vlivanov ! src/hotspot/share/ci/ciEnv.cpp ! src/hotspot/share/ci/ciEnv.hpp ! src/hotspot/share/ci/ciInstanceKlass.cpp ! src/hotspot/share/ci/ciInstanceKlass.hpp ! src/hotspot/share/ci/ciMethod.cpp ! src/hotspot/share/ci/ciMethod.hpp ! src/hotspot/share/ci/ciMethodData.cpp ! src/hotspot/share/ci/ciReplay.cpp ! src/hotspot/share/ci/ciReplay.hpp ! test/hotspot/jtreg/compiler/ciReplay/CiReplayBase.java ! test/hotspot/jtreg/compiler/ciReplay/TestInlining.java Changeset: cec6c068 Author: Prasanta Sadhukhan Date: 2021-09-04 11:04:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/cec6c068b03d890312e50b448fbc26102c635249 8272232: javax/swing/JTable/4275046/bug4275046.java failed with "Expected value in the cell: 'rededited' but found 'redEDITED'." 8257540: javax/swing/JFileChooser/8041694/bug8041694.java failed with "RuntimeException: The selected directory name is not the expected 'd ' but 'D '." Reviewed-by: serb ! test/jdk/java/awt/List/ActionEventTest/ActionEventTest.java ! test/jdk/java/awt/dnd/RecognizedActionTest/RecognizedActionTest.java ! test/jdk/javax/swing/JFileChooser/8041694/bug8041694.java ! test/jdk/javax/swing/JRadioButton/8033699/bug8033699.java ! test/jdk/javax/swing/JTable/4275046/bug4275046.java Changeset: c640fe42 Author: lawrence.andrews Committer: Sergey Bylokhov Date: 2021-09-05 09:15:38 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c640fe42c2b5e6668a2a875678be44443942c868 7188098: TEST_BUG: closed/javax/sound/midi/Synthesizer/Receiver/bug6186488.java fails Reviewed-by: serb ! test/jdk/javax/sound/midi/Synthesizer/Receiver/bug6186488.java Changeset: 4d25e6f6 Author: Aleksey Shipilev Date: 2021-09-06 08:08:05 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4d25e6f6c7ee855771ab9c05ae85a9d92c866941 8273335: compiler/blackhole tests should not run with interpreter-only VMs Reviewed-by: kvn ! test/hotspot/jtreg/compiler/blackhole/BlackholeExistingIntrinsicWarningTest.java ! test/hotspot/jtreg/compiler/blackhole/BlackholeExperimentalUnlockTest.java ! test/hotspot/jtreg/compiler/blackhole/BlackholeIntrinsicTest.java ! test/hotspot/jtreg/compiler/blackhole/BlackholeNonEmptyWarningTest.java ! test/hotspot/jtreg/compiler/blackhole/BlackholeNonStaticWarningTest.java ! test/hotspot/jtreg/compiler/blackhole/BlackholeNonVoidWarningTest.java Changeset: b4e5b28b Author: Albert Mingkun Yang Date: 2021-09-06 08:11:34 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b4e5b28b860f10d3e028a2ab042d452db289064f 8273221: Guard GCIdMark against nested calls Reviewed-by: tschatzl, kbarrett ! src/hotspot/share/gc/shared/gcId.cpp ! src/hotspot/share/gc/shared/gcId.hpp Changeset: 70ed6c5b Author: Daniel Gredler Committer: Jayathirth D V Date: 2021-09-06 08:13:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/70ed6c5b8c52dc1c1c25967a09164a013bdb4bdd 8272878: JEP 381 cleanup: Remove unused Solaris code in sun.font.TrueTypeGlyphMapper Reviewed-by: prr, jdv ! src/java.desktop/share/classes/sun/font/TrueTypeGlyphMapper.java Changeset: fb5b144e Author: Thomas Schatzl Date: 2021-09-06 09:07:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fb5b144eca761d4b4c667efe05ca638536c065ac 8272985: Reference discovery is confused about atomicity and degree of parallelism Reviewed-by: ayang, kbarrett ! src/hotspot/share/gc/shared/referenceProcessor.cpp ! src/hotspot/share/gc/shared/referenceProcessor.hpp ! src/hotspot/share/gc/shared/referenceProcessor.inline.hpp Changeset: 1bf5bda2 Author: Markus Gr?nlund Date: 2021-09-06 09:13:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1bf5bda2919b3236040bf12c51eba552c6309cf7 8269418: jdk/jfr/event/oldobject/TestObjectSize.java failed with "RuntimeException: No events: expected false, was true" Reviewed-by: jbachorik ! test/jdk/ProblemList.txt ! test/jdk/jdk/jfr/event/oldobject/TestObjectSize.java Changeset: 44c5c23b Author: Dan Heidinga Committer: Aleksey Shipilev Date: 2021-09-06 13:39:03 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/44c5c23b96adf071339b39cfaea08c2d3a19d839 8272164: DumpAllocStats shouldn't subclass from ResourceObj Reviewed-by: shade, iklam, dholmes ! src/hotspot/share/cds/dumpAllocStats.hpp Changeset: 2cabec8d Author: Thomas Schatzl Date: 2021-09-06 14:28:54 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2cabec8ddc19dd66495957e7ef553990a502e993 8253343: Extract G1 Young GC algorithm related code from G1CollectedHeap Reviewed-by: ayang, 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/g1YoungCollector.cpp + src/hotspot/share/gc/g1/g1YoungCollector.hpp ! src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.cpp Changeset: 7bd4f496 Author: Patric Hedlin Date: 2021-09-06 14:43:54 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7bd4f496b493b804990615f6ce2cb1b4abd29a86 8264207: CodeStrings does not honour fixed address assumption. Reviewed-by: redestad, neliasso ! src/hotspot/share/asm/codeBuffer.cpp ! src/hotspot/share/asm/codeBuffer.hpp ! src/hotspot/share/code/codeBlob.cpp ! src/hotspot/share/code/codeBlob.hpp ! src/hotspot/share/code/icBuffer.hpp ! src/hotspot/share/code/stubs.cpp ! src/hotspot/share/code/stubs.hpp ! src/hotspot/share/compiler/disassembler.cpp ! src/hotspot/share/compiler/disassembler.hpp ! src/hotspot/share/interpreter/interpreter.cpp ! src/hotspot/share/interpreter/interpreter.hpp ! src/hotspot/share/interpreter/interpreterRuntime.cpp ! src/hotspot/share/runtime/sharedRuntime.cpp ! src/hotspot/share/runtime/stubCodeGenerator.cpp ! src/hotspot/share/runtime/stubCodeGenerator.hpp + test/hotspot/gtest/code/test_codestrings.cpp Changeset: fc546d6d Author: Aleksey Shipilev Date: 2021-09-06 16:00:12 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fc546d6de9a3ed33cf4b04e24e62714332b069cb 8273378: Shenandoah: Remove the remaining uses of os::is_MP Reviewed-by: aph, zgu ! src/hotspot/cpu/x86/gc/shenandoah/shenandoahBarrierSetAssembler_x86.cpp Changeset: eb221812 Author: Kim Barrett Date: 2021-09-06 18:19:58 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/eb221812b28c1c6da2e442292a4f7cb5226b62ba 8273386: Remove duplicated code in G1DCQS::abandon_completed_buffers Reviewed-by: tschatzl ! src/hotspot/share/gc/g1/g1DirtyCardQueue.cpp Changeset: 649c22c5 Author: Wang Huang Committer: Nick Gasson Date: 2021-09-07 01:40:24 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/649c22c5b17efbc3116ac34739b8d1be39de01be 8270832: Aarch64: Update algorithm annotations for MacroAssembler::fill_words Co-authored-by: Wang Huang Co-authored-by: Miu Zhuojun Co-authored-by: Wu Yan Reviewed-by: ngasson, aph ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp Changeset: 81c719be Author: Aleksey Shipilev Date: 2021-09-07 07:35:23 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/81c719be3995fa54974e8b8826ad81bf07bd012f 8273333: Zero should warn about unimplemented -XX:+LogTouchedMethods Reviewed-by: minqi, dholmes ! src/hotspot/share/runtime/arguments.cpp ! test/hotspot/jtreg/runtime/CommandLine/PrintTouchedMethods.java Changeset: 3cd95a29 Author: Leo Korinth Date: 2021-09-07 08:23:32 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3cd95a2932ab6a2cb39322354f7ad181de8bfc9e 8231356: Fix broken ResourceObj::operator new[] in debug builds Reviewed-by: kbarrett, iklam ! src/hotspot/share/memory/allocation.cpp ! src/hotspot/share/memory/allocation.hpp Changeset: a522d6b5 Author: Aleksey Shipilev Date: 2021-09-07 08:52:53 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a522d6b53cd841b4bfe87eac5778c9e5cdf5e90f 8273376: Zero: Disable vtable/itableStub gtests Reviewed-by: jiefu, stuefe ! test/hotspot/gtest/code/test_vtableStub.cpp Changeset: 5caa77b0 Author: Ivan ?ipka Committer: Daniel Fuchs Date: 2021-09-07 09:46:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5caa77b043ae490c3d7d56d181d0e07e6b859b9e 8263364: sun/net/www/http/KeepAliveStream/KeepAliveStreamCloseWithWrongContentLength.java wedged in getInputStream Reviewed-by: dfuchs ! test/jdk/sun/net/www/http/KeepAliveStream/KeepAliveStreamCloseWithWrongContentLength.java Changeset: 70157c78 Author: Jan Lahoda Date: 2021-09-07 09:50:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/70157c78a838126bb29c91a410d9158763bfa2ad 8272135: jshell: Method cannot use its overloaded version Reviewed-by: vromero ! src/jdk.jshell/share/classes/jdk/jshell/Eval.java ! src/jdk.jshell/share/classes/jdk/jshell/TaskFactory.java ! src/jdk.jshell/share/classes/jdk/jshell/TreeDissector.java ! test/langtools/jdk/jshell/MethodsTest.java Changeset: 377b1867 Author: Vladimir Ivanov Date: 2021-09-07 11:35:31 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/377b186724473475480b834d99c38b8161bf6917 8269119: C2: Avoid redundant memory barriers in Unsafe.copyMemory0 intrinsic Reviewed-by: thartmann, roland ! src/hotspot/share/opto/library_call.cpp + test/hotspot/jtreg/compiler/unsafe/UnsafeCopyMemory.java Changeset: 041ae20b Author: Fernando Guallini Committer: Rajan Halade Date: 2021-09-07 14:36:15 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/041ae20b10e11381415e8f61fd39e9e19aa8d4f2 8268558: [TESTBUG] Case 2 in TestP11KeyFactoryGetRSAKeySpec is skipped Reviewed-by: mullan, rhalade ! test/jdk/sun/security/pkcs11/rsa/TestP11KeyFactoryGetRSAKeySpec.java Changeset: 99fb12c7 Author: Roland Westrelin Date: 2021-09-07 15:13:12 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/99fb12c798ad24cc4a671a666930ba42c3cd10c9 8271341: Opcode() != Op_If && Opcode() != Op_RangeCheck) || outcnt() == 2 assert failure with Test7179138_1.java Reviewed-by: kvn, thartmann ! src/hotspot/share/opto/stringopts.cpp ! test/hotspot/jtreg/compiler/c2/Test7179138_1.java Changeset: 2abf3b3b Author: Roland Westrelin Date: 2021-09-07 15:15:17 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2abf3b3b2743947282300ee8416611559e49fca0 8271340: Crash PhaseIdealLoop::clone_outer_loop Reviewed-by: kvn, thartmann ! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp ! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.hpp ! src/hotspot/share/opto/cfgnode.cpp + test/hotspot/jtreg/compiler/loopopts/TestInfiniteLoopCCP.java Changeset: df05b4d1 Author: Prasanta Sadhukhan Date: 2021-09-07 15:50:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/df05b4d1a13e55755107695ad9ea7a8a1084901a 8271923: [macos] the text color on the selected disabled tabbed pane button remains white making text unreadable Reviewed-by: jdv ! src/java.desktop/macosx/classes/com/apple/laf/AquaLookAndFeel.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaTabbedPaneContrastUI.java Changeset: 270a9d92 Author: Alexey Ivanov Date: 2021-09-07 19:05:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/270a9d929307dce52e6961e57492c03a633ed044 8273043: [TEST_BUG] Automate NimbusJTreeSelTextColor.java Reviewed-by: serb ! test/jdk/javax/swing/plaf/nimbus/NimbusJTreeSelTextColor.java Changeset: 708407ed Author: Andrey Turbanov Committer: Alexey Ivanov Date: 2021-09-07 21:12:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/708407eddc9d52c01de02e3986c05e1c6225fa85 8273168: Remove superfluous use of boxing in java.desktop Reviewed-by: aivanov ! src/java.desktop/share/classes/com/sun/imageio/plugins/png/PNGMetadata.java ! src/java.desktop/share/classes/java/awt/Font.java ! src/java.desktop/share/classes/javax/swing/text/html/CSS.java ! src/java.desktop/share/classes/javax/swing/text/html/HTML.java ! src/java.desktop/share/classes/sun/awt/datatransfer/DataTransferer.java ! src/java.desktop/unix/classes/sun/print/PrintServiceLookupProvider.java ! src/java.desktop/windows/classes/sun/awt/windows/WPathGraphics.java Changeset: d6d6c069 Author: Mark Sheppard Date: 2021-09-07 22:18:23 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d6d6c0692bff77bd18127ed61455aac39370a089 8273246: Amend the test java/nio/channels/DatagramChannel/ManySourcesAndTargets.java to execute in othervm mode Reviewed-by: alanb ! test/failure_handler/src/share/conf/mac.properties ! test/jdk/java/nio/channels/DatagramChannel/ManySourcesAndTargets.java Changeset: 8884d2f8 Author: Daniel D. Daugherty Date: 2021-09-08 00:34:11 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8884d2f854fafdc5f775fce557053d072e4a882c 8273462: ProblemList vmTestbase/vm/mlvm/anonloader/stress/oome/heap/Test.java in -Xcomp mode Reviewed-by: dholmes ! test/hotspot/jtreg/ProblemList-Xcomp.txt Changeset: 4eacdb38 Author: Yasumasa Suenaga Date: 2021-09-08 01:27:13 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4eacdb38a83b545603928392eccb116c744ef3b3 8273104: Refactoring option parser for UL Reviewed-by: iklam, dholmes ! src/hotspot/share/logging/logFileOutput.cpp ! src/hotspot/share/logging/logFileOutput.hpp ! src/hotspot/share/logging/logFileStreamOutput.cpp ! src/hotspot/share/logging/logFileStreamOutput.hpp ! src/hotspot/share/logging/logOutput.cpp ! src/hotspot/share/logging/logOutput.hpp ! test/hotspot/jtreg/runtime/logging/FoldMultilinesTest.java Changeset: ea4907a8 Author: Daniel D. Daugherty Date: 2021-09-08 02:13:41 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ea4907a8789e00f9ec8d4175241246b8cf53f3f6 8273047: test jfr/api/consumer/TestRecordedFrame.java timing out Reviewed-by: dholmes ! test/jdk/jdk/jfr/api/consumer/TestRecordedFrame.java Changeset: 1513dc7a Author: Andrey Turbanov Committer: Sergey Bylokhov Date: 2021-09-08 04:36:41 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1513dc7afc33386106439ccb9b7b16956b3c534a 8271603: Unnecessary Vector usage in java.desktop Reviewed-by: prr, serb ! src/java.desktop/macosx/classes/com/apple/laf/AquaFileChooserUI.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/common/SimpleRenderedImage.java ! src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKFileChooserUI.java ! src/java.desktop/share/classes/com/sun/media/sound/AbstractMixer.java ! src/java.desktop/share/classes/com/sun/media/sound/AlawCodec.java ! src/java.desktop/share/classes/com/sun/media/sound/PCMtoPCMCodec.java ! src/java.desktop/share/classes/com/sun/media/sound/UlawCodec.java ! src/java.desktop/share/classes/java/awt/Menu.java ! src/java.desktop/share/classes/java/awt/Window.java ! src/java.desktop/share/classes/javax/print/MimeType.java ! src/java.desktop/share/classes/javax/sound/sampled/AudioSystem.java ! src/java.desktop/share/classes/javax/swing/JFileChooser.java ! src/java.desktop/share/classes/javax/swing/JMenu.java ! src/java.desktop/share/classes/javax/swing/JMenuBar.java ! src/java.desktop/share/classes/javax/swing/JOptionPane.java ! src/java.desktop/share/classes/javax/swing/JPopupMenu.java ! src/java.desktop/share/classes/javax/swing/UIManager.java ! src/java.desktop/share/classes/javax/swing/plaf/metal/MetalFileChooserUI.java ! src/java.desktop/share/classes/javax/swing/text/AbstractDocument.java ! src/java.desktop/share/classes/javax/swing/text/DefaultStyledDocument.java ! src/java.desktop/share/classes/javax/swing/text/JTextComponent.java ! src/java.desktop/share/classes/javax/swing/text/ZoneView.java ! src/java.desktop/share/classes/javax/swing/text/html/AccessibleHTML.java ! src/java.desktop/share/classes/javax/swing/text/html/CSS.java ! src/java.desktop/share/classes/javax/swing/text/rtf/RTFAttributes.java ! src/java.desktop/share/classes/javax/swing/text/rtf/RTFGenerator.java ! src/java.desktop/share/classes/javax/swing/undo/StateEdit.java ! src/java.desktop/share/classes/sun/awt/PlatformFont.java ! src/java.desktop/share/classes/sun/awt/shell/ShellFolder.java ! src/java.desktop/share/classes/sun/swing/plaf/synth/SynthFileChooserUIImpl.java ! src/java.desktop/unix/classes/sun/awt/X11/XWindowPeer.java ! src/java.desktop/unix/classes/sun/print/PrintServiceLookupProvider.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsFileChooserUI.java ! src/java.desktop/windows/classes/sun/awt/Win32GraphicsDevice.java Changeset: 7d24a334 Author: Aleksey Shipilev Date: 2021-09-08 07:43:28 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7d24a3342129d4c71fad0d8d50d20758291d64b7 8273318: Some containers/docker/TestJFREvents.java configs are running out of memory Reviewed-by: ngasson, sgehwolf, mseledtsov ! test/hotspot/jtreg/containers/docker/TestJFREvents.java Changeset: 286a1f6b Author: Aleksey Shipilev Date: 2021-09-08 07:44:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/286a1f6b7c6d7c598ced456f1a5f63cac1be8539 8273440: Zero: Disable runtime/Unsafe/InternalErrorTest.java Reviewed-by: dholmes ! test/hotspot/jtreg/runtime/Unsafe/InternalErrorTest.java Changeset: a66629a4 Author: Hamlin Li Date: 2021-09-08 08:01:18 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a66629a464b97176bcdc2ca1150d12df6241dc1c 8254167: G1: Record regions where evacuation failed to provide targeted iteration Reviewed-by: tschatzl, ayang ! 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/g1CollectionSet.cpp ! src/hotspot/share/gc/g1/g1CollectionSet.hpp ! src/hotspot/share/gc/g1/g1EvacFailure.cpp ! src/hotspot/share/gc/g1/g1EvacFailure.hpp + src/hotspot/share/gc/g1/g1EvacFailureRegions.cpp + src/hotspot/share/gc/g1/g1EvacFailureRegions.hpp + src/hotspot/share/gc/g1/g1EvacFailureRegions.inline.hpp ! src/hotspot/share/gc/g1/g1ParScanThreadState.cpp ! src/hotspot/share/gc/g1/g1ParScanThreadState.hpp ! src/hotspot/share/gc/g1/g1YoungCollector.cpp ! src/hotspot/share/gc/g1/g1YoungCollector.hpp ! src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.cpp ! src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.hpp Changeset: 6750c34c Author: Andrew Haley Date: 2021-09-08 10:08:30 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6750c34c92b5f28bba4a88ac798b800fce380d32 8270533: AArch64: size_fits_all_mem_uses should return false if its output is a CAS Reviewed-by: adinn, ngasson ! src/hotspot/cpu/aarch64/aarch64.ad Changeset: 18555742 Author: Markus Karg Committer: Alan Bateman Date: 2021-09-08 11:22:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/185557423d3069d627daecdf87315a49d6597b67 8273038: ChannelInputStream.transferTo() uses FileChannel.transferTo(FileChannel) Reviewed-by: alanb ! src/java.base/share/classes/java/nio/channels/Channels.java ! src/java.base/share/classes/sun/nio/ch/ChannelInputStream.java + src/java.base/share/classes/sun/nio/ch/ChannelOutputStream.java + test/jdk/java/nio/channels/Channels/TransferTo.java Changeset: 21012f2b Author: Vladimir Ivanov Date: 2021-09-08 11:27:14 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/21012f2bbe214955d05f8bc583dcdceb0949b601 8078641: MethodHandle.asTypeCache can retain classes from unloading Co-authored-by: Peter Levart Co-authored-by: Vladimir Ivanov Reviewed-by: psandoz, mchung, plevart ! src/java.base/share/classes/java/lang/invoke/MethodHandle.java ! src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java Changeset: faa942c8 Author: Vladimir Ivanov Date: 2021-09-08 11:28:17 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/faa942c8ba8ad778b6be20ff6d98a5040a9079e9 8273000: Remove WeakReference-based class initialisation barrier implementation Reviewed-by: psandoz, mchung ! src/java.base/share/classes/java/lang/invoke/DirectMethodHandle.java ! src/java.base/share/classes/jdk/internal/misc/Unsafe.java Changeset: 59c9f750 Author: Andrey Turbanov Committer: Alexey Ivanov Date: 2021-09-08 14:28:07 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/59c9f750414e4f131c906a5bc20f32f2f9cfe9ec 8273375: Remove redundant 'new String' calls after concatenation in java.desktop Reviewed-by: aivanov ! src/java.desktop/macosx/classes/com/apple/laf/AquaTabbedPaneCopyFromBasicUI.java ! src/java.desktop/macosx/classes/sun/java2d/IntegerNIORaster.java ! src/java.desktop/share/classes/java/awt/image/ColorModel.java ! src/java.desktop/share/classes/java/awt/image/DirectColorModel.java ! src/java.desktop/share/classes/java/awt/image/IndexColorModel.java ! src/java.desktop/share/classes/sun/awt/image/ByteBandedRaster.java ! src/java.desktop/share/classes/sun/awt/image/ByteComponentRaster.java ! src/java.desktop/share/classes/sun/awt/image/ByteInterleavedRaster.java ! src/java.desktop/share/classes/sun/awt/image/BytePackedRaster.java ! src/java.desktop/share/classes/sun/awt/image/IntegerComponentRaster.java ! src/java.desktop/share/classes/sun/awt/image/IntegerInterleavedRaster.java ! src/java.desktop/share/classes/sun/awt/image/ShortBandedRaster.java ! src/java.desktop/share/classes/sun/awt/image/ShortComponentRaster.java ! src/java.desktop/share/classes/sun/awt/image/ShortInterleavedRaster.java ! src/java.desktop/unix/classes/sun/awt/X11/InfoWindow.java Changeset: f2f8136c Author: jtfuller111 Committer: Tobias Hartmann Date: 2021-09-08 14:38:21 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f2f8136cc9f5a3f554f704024748a09cb80bd037 8265443: IGV: disambiguate groups by emiting additional properties Reviewed-by: thartmann ! src/hotspot/share/opto/idealGraphPrinter.cpp ! src/hotspot/share/opto/idealGraphPrinter.hpp Changeset: 7e662e7b Author: Wang Huang Committer: Tobias Hartmann Date: 2021-09-08 14:39:23 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7e662e7b9d7ea5113f568418e0acac4234ebfb88 8272413: Incorrect num of element count calculation for vector cast Co-authored-by: Wang Huang Co-authored-by: Miu Zhuojun Co-authored-by: Wu Yan Reviewed-by: eliu, kvn ! src/hotspot/share/opto/vectorIntrinsics.cpp Changeset: cb112aff Author: Masanori Yano Committer: Naoto Sato Date: 2021-09-08 15:46:33 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/cb112affd6061e8ace6dad4e92c7b394a413e37f 8269373: some tests in jdk/tools/launcher/ fails on localized Windows platform Reviewed-by: naoto ! test/jdk/tools/launcher/FXLauncherTest.java ! test/jdk/tools/launcher/SourceMode.java Changeset: e5f298a7 Author: Sergey Tsypanov Committer: Naoto Sato Date: 2021-09-08 15:54:36 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e5f298a7f1f3106b72e43c152c090af1657485f0 8273329: Remove redundant null check from String.getBytes(String charsetName) Reviewed-by: rriggs, iris, naoto ! src/java.base/share/classes/java/lang/String.java Changeset: d7efd0e8 Author: Sandhya Viswanathan Date: 2021-09-08 16:07:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d7efd0e8cf14c732427d2c1363b60278bebdc06a 8273450: Fix the copyright header of SVML files Reviewed-by: dholmes, psandoz ! 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/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: f7e9f56e Author: Vladimir Ivanov Date: 2021-09-08 16:17:56 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f7e9f56e235dc50daae0a85c9790d5b04c9c60f0 8273359: CI: ciInstanceKlass::get_canonical_holder() doesn't respect instance size Reviewed-by: kvn ! src/hotspot/share/c1/c1_LIRGenerator.cpp ! src/hotspot/share/ci/ciInstanceKlass.cpp ! src/hotspot/share/ci/ciInstanceKlass.hpp ! src/hotspot/share/opto/compile.cpp + test/hotspot/jtreg/compiler/unsafe/AlignmentGapAccess.java Changeset: 267c61a1 Author: Aleksey Shipilev Date: 2021-09-08 16:36:31 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/267c61a16a916e35762e8df5737ec74b06defae8 8273361: InfoOptsTest is failing in tier1 Reviewed-by: jpai, ihse, jlahoda ! test/langtools/tools/javac/options/modes/InfoOptsTest.java ! test/langtools/tools/javac/options/modes/OptionModesTester.java Changeset: 4d5e1ed9 Author: Jonathan Gibbons Date: 2021-09-08 17:38:05 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4d5e1ed9589713bdae5ebe659e657b9c6b833c3f 8272375: Improve phrasing of synthesized descriptions in JavaFX docs Reviewed-by: kcr, prappo ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties ! test/langtools/jdk/javadoc/doclet/testJavaFX/TestJavaFX.java ! test/langtools/jdk/javadoc/doclet/testJavaFX/TestJavaFXCombo.java ! test/langtools/jdk/javadoc/doclet/testJavaFX/TestJavaFXMissingPropComments.java Changeset: ba31eee4 Author: Daniel D. Daugherty Date: 2021-09-08 18:33:04 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ba31eee4fc92bba3657e5f3fec2b85f55120d7a1 8273109: runtime/cds/appcds/loaderConstraints/DynamicLoaderConstraintsTest times out Reviewed-by: bpb ! test/hotspot/jtreg/runtime/cds/appcds/loaderConstraints/DynamicLoaderConstraintsTest.java Changeset: e6805032 Author: Thomas Schatzl Date: 2021-09-08 19:02:49 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e6805032ff328773eafe8b94e9f1b3b196f52196 8273185: Rename the term "atomic" in ReferenceProcessor Reviewed-by: ayang, shade ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/parallel/psScavenge.cpp ! src/hotspot/share/gc/shared/referenceProcessor.cpp ! src/hotspot/share/gc/shared/referenceProcessor.hpp Changeset: 9b5991e8 Author: Leonid Mesnik Date: 2021-09-08 19:30:17 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9b5991e811b789fe8b60701657c2f0dd2c222c2e 8273451: Remove unreachable return in mutexLocker::wait Reviewed-by: minqi, coleenp ! src/hotspot/share/runtime/mutexLocker.hpp Changeset: a5e4def5 Author: Leonid Mesnik Date: 2021-09-08 19:31:18 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a5e4def526697d88ff31a5fdb41d823b899372f2 8265489: Stress test times out because of long ObjectSynchronizer::monitors_iterate(...) operation Reviewed-by: dcubed ! src/hotspot/share/prims/jvmtiEnvBase.cpp ! src/hotspot/share/prims/jvmtiEnvBase.hpp ! src/hotspot/share/runtime/synchronizer.cpp ! src/hotspot/share/runtime/synchronizer.hpp ! src/hotspot/share/services/threadService.cpp Changeset: 7fd6b0bf Author: Roger Riggs Date: 2021-09-08 20:53:25 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7fd6b0bfd8ab3c64b374c71010bdfa369f0c67e8 8273242: (test) Refactor to use TestNG for RuntimeTests ExecCommand tests Reviewed-by: naoto, lancea ! test/jdk/java/lang/RuntimeTests/exec/ExecCommand.java Changeset: 12f0b771 Author: Daniel D. Daugherty Date: 2021-09-09 00:39:40 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/12f0b771791614b8a41fc2c62d34481f911109b0 8273516: ProblemList compiler/c2/Test7179138_1.java in -Xcomp mode on win-X64 Reviewed-by: dholmes ! test/hotspot/jtreg/ProblemList-Xcomp.txt Changeset: 5df26480 Author: Hamlin Li Date: 2021-09-09 00:41:28 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5df26480864f1efd16eb5800833bf7106371b97a 8273218: G1: Rename g1EvacuationInfo to g1EvacInfo Reviewed-by: tschatzl, ayang ! src/hotspot/share/gc/g1/g1Allocator.cpp ! src/hotspot/share/gc/g1/g1Allocator.hpp = src/hotspot/share/gc/g1/g1EvacInfo.hpp ! src/hotspot/share/gc/g1/g1Trace.cpp ! src/hotspot/share/gc/g1/g1Trace.hpp ! src/hotspot/share/gc/g1/g1YoungCollector.cpp ! src/hotspot/share/gc/g1/g1YoungCollector.hpp ! src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.cpp ! src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.hpp Changeset: 6eba4434 Author: Matthias Baesken Date: 2021-09-09 06:15:15 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6eba443428ff7abe7c0509047ec76432affebe65 8273387: remove some unreferenced gtk-related functions Reviewed-by: pbansal, clanger ! src/java.desktop/unix/native/libawt_xawt/awt/gtk2_interface.c ! src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.c Changeset: 5b1dfe4e Author: Thomas Schatzl Date: 2021-09-09 07:28:23 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5b1dfe4e358d249aef9330e39b6404a13b4ebc0e 8273439: Fix G1CollectedHeap includes and forward declarations Reviewed-by: ayang, kbarrett ! src/hotspot/share/gc/g1/g1CollectedHeap.hpp Changeset: dc33bd8b Author: Aleksey Shipilev Date: 2021-09-09 07:43:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/dc33bd8b6cfa9a9cd71d7065d284a807774750a2 8273315: Parallelize and increase timeouts for java/foreign/TestMatrix.java test Reviewed-by: mcimadamore ! test/jdk/java/foreign/TestMatrix.java Changeset: 8c16f485 Author: Aleksey Shipilev Date: 2021-09-09 08:07:00 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8c16f485b341ee3071c91df39dfb9ba8b9caa44d 8273487: Zero: Handle "zero" variant in runtime tests Reviewed-by: alanb, dholmes ! test/lib/jdk/test/lib/Platform.java Changeset: aa931118 Author: Aleksey Shipilev Date: 2021-09-09 09:46:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/aa9311182ae88312a70b18afd85939718415b77c 8273483: Zero: Clear pending JNI exception check in native method handler Reviewed-by: aph ! src/hotspot/cpu/zero/zeroInterpreter_zero.cpp Changeset: 00e059dd Author: Evan Whelan Committer: Daniel Fuchs Date: 2021-09-09 10:23:12 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/00e059ddb34b5f2d6ba1ea0f38308c5b382a8e4d 8133686: HttpURLConnection.getHeaderFields and URLConnection.getRequestProperties methods return field values in reverse order Reviewed-by: dfuchs ! src/java.base/share/classes/java/net/URLConnection.java ! src/java.base/share/classes/sun/net/www/MessageHeader.java + test/jdk/java/net/HttpURLConnection/HttpURLConnectionHeadersOrder.java ! test/jdk/java/net/URLConnection/RequestPropertyValues.java ! test/jdk/java/net/URLConnection/URLConnectionHeaders.java + test/jdk/java/net/URLConnection/URLConnectionHeadersOrder.java ! test/jdk/sun/net/www/MessageHeaderTest.java Changeset: 9690df7f Author: Hamlin Li Date: 2021-09-09 10:41:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9690df7fb9843bdc4775a34d94b2ca81f40aea0a 8273476: G1: refine G1CollectedHeap::par_iterate_regions_array_part_from Reviewed-by: ayang, tschatzl ! 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/g1EvacFailureRegions.cpp Changeset: f6cc1732 Author: Martin Doerr Date: 2021-09-09 10:48:02 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f6cc1732f47672cea413fa842c4f106c1314c626 8273539: [PPC64] gtest build error after JDK-8264207 Reviewed-by: shade, stuefe ! test/hotspot/gtest/code/test_codestrings.cpp Changeset: 5ca26cbd Author: Aleksey Shipilev Date: 2021-09-09 13:41:46 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5ca26cbddbdd47a73cc141a6215dc89c53841d4a 8273433: Enable parallelism in vmTestbase_nsk_sysdict tests Reviewed-by: mseledtsov, dholmes - test/hotspot/jtreg/vmTestbase/nsk/sysdict/vm/stress/btree/btree001/TEST.properties - test/hotspot/jtreg/vmTestbase/nsk/sysdict/vm/stress/btree/btree002/TEST.properties - test/hotspot/jtreg/vmTestbase/nsk/sysdict/vm/stress/btree/btree003/TEST.properties - test/hotspot/jtreg/vmTestbase/nsk/sysdict/vm/stress/btree/btree004/TEST.properties - test/hotspot/jtreg/vmTestbase/nsk/sysdict/vm/stress/btree/btree005/TEST.properties - test/hotspot/jtreg/vmTestbase/nsk/sysdict/vm/stress/btree/btree006/TEST.properties - test/hotspot/jtreg/vmTestbase/nsk/sysdict/vm/stress/btree/btree007/TEST.properties - test/hotspot/jtreg/vmTestbase/nsk/sysdict/vm/stress/btree/btree008/TEST.properties - test/hotspot/jtreg/vmTestbase/nsk/sysdict/vm/stress/btree/btree009/TEST.properties - test/hotspot/jtreg/vmTestbase/nsk/sysdict/vm/stress/btree/btree010/TEST.properties - test/hotspot/jtreg/vmTestbase/nsk/sysdict/vm/stress/btree/btree011/TEST.properties - test/hotspot/jtreg/vmTestbase/nsk/sysdict/vm/stress/btree/btree012/TEST.properties - test/hotspot/jtreg/vmTestbase/nsk/sysdict/vm/stress/chain/chain001/TEST.properties - test/hotspot/jtreg/vmTestbase/nsk/sysdict/vm/stress/chain/chain002/TEST.properties - test/hotspot/jtreg/vmTestbase/nsk/sysdict/vm/stress/chain/chain003/TEST.properties - test/hotspot/jtreg/vmTestbase/nsk/sysdict/vm/stress/chain/chain004/TEST.properties - test/hotspot/jtreg/vmTestbase/nsk/sysdict/vm/stress/chain/chain005/TEST.properties - test/hotspot/jtreg/vmTestbase/nsk/sysdict/vm/stress/chain/chain006/TEST.properties - test/hotspot/jtreg/vmTestbase/nsk/sysdict/vm/stress/chain/chain007/TEST.properties - test/hotspot/jtreg/vmTestbase/nsk/sysdict/vm/stress/chain/chain008/TEST.properties Changeset: 4866eaa9 Author: Tobias Hartmann Date: 2021-09-09 13:44:05 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4866eaa997b2ee2a47bdcd0d96202f220fb2774d 8273409: Receiver type narrowed by CCP does not always trigger post-parse call devirtualization Reviewed-by: vlivanov, neliasso ! src/hotspot/share/opto/phaseX.cpp + test/hotspot/jtreg/compiler/c2/irTests/TestPostParseCallDevirtualization.java ! test/hotspot/jtreg/compiler/lib/ir_framework/IRNode.java Changeset: c81690d7 Author: Tobias Hartmann Date: 2021-09-09 13:54:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c81690d7166c32caff6ef3a55fe9b157049e2b56 8273498: compiler/c2/Test7179138_1.java timed out Reviewed-by: roland ! test/hotspot/jtreg/ProblemList-Xcomp.txt ! test/hotspot/jtreg/compiler/c2/Test7179138_1.java Changeset: e3bda63c Author: Aleksey Shipilev Date: 2021-09-09 17:19:14 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e3bda63ce29bac0eaea520d42f4927dda77f83f2 8273489: Zero: Handle UseHeavyMonitors on all monitorenter paths Reviewed-by: coleenp ! src/hotspot/cpu/zero/zeroInterpreter_zero.cpp Changeset: 96614da0 Author: Maurizio Cimadamore Date: 2021-09-09 17:28:06 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/96614da0254e7fd4ac9dd3c3059bf23c1aaf37ff 8272903: Missing license header in ArenaAllocator.java Reviewed-by: bpb, lancea ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/ArenaAllocator.java Changeset: ef4a5328 Author: Saravana Kumar Vijayasekaran Committer: Erik Joelsson Date: 2021-09-09 18:24:26 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ef4a532802096f3958567c2ed22c1b317ac21fbe 8263773: Reenable German localization for builds at Oracle Reviewed-by: erikj, ihse ! make/conf/jib-profiles.js ! test/jdk/build/translations/VerifyTranslations.java Changeset: dd1209e4 Author: Vicente Romero Date: 2021-09-09 18:36:17 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/dd1209e4ae3c8e42d121329639ec4bd359d0a456 8268885: duplicate checkcast when destination type is not first type of intersection type Reviewed-by: jlahoda ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransTypes.java ! test/langtools/tools/javac/cast/intersection/DuplicatedCheckcastTest.java Changeset: 185eacac Author: Per Liden Date: 2021-09-09 19:19:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/185eacacdde9de12936520a1cda847f7e541c62f 8273545: Remove Thread::is_GC_task_thread() Reviewed-by: stefank, coleenp, shade ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp ! src/hotspot/share/gc/parallel/parallelScavengeHeap.hpp ! src/hotspot/share/gc/parallel/psParallelCompact.cpp ! src/hotspot/share/gc/shared/workgroup.cpp ! src/hotspot/share/gc/shared/workgroup.hpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoahWorkGroup.hpp ! src/hotspot/share/gc/z/zCollectedHeap.cpp ! src/hotspot/share/gc/z/zRuntimeWorkers.cpp ! src/hotspot/share/gc/z/zWorkers.cpp ! src/hotspot/share/runtime/thread.hpp ! test/hotspot/gtest/gc/g1/test_g1BatchedGangTask.cpp ! test/hotspot/gtest/gc/g1/test_g1CardSet.cpp ! test/hotspot/gtest/gc/g1/test_stressCommitUncommit.cpp ! test/hotspot/gtest/gc/shared/test_oopStorage.cpp ! test/hotspot/gtest/gc/shared/test_oopStorage_parperf.cpp Changeset: 4020a60c Author: Per Liden Date: 2021-09-09 19:21:55 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4020a60cbb3db0458262212d46515c8c11492a5b 8273550: Replace os::cgc_thread/pgc_thread with os::gc_thread Reviewed-by: stefank, coleenp ! src/hotspot/os/posix/os_posix.cpp ! src/hotspot/os/windows/os_windows.cpp ! src/hotspot/share/gc/shared/concurrentGCThread.cpp ! src/hotspot/share/gc/shared/workgroup.cpp ! src/hotspot/share/runtime/os.hpp Changeset: 54dee132 Author: Naoto Sato Date: 2021-09-09 19:41:56 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/54dee132d1a149165e7478b29b740d086c18c424 8273188: java/lang/instrument/BootClassPath/BootClassPathTest.sh fails with "FATAL ERROR in native method: processing of -javaagent failed, processJavaStart failed" Reviewed-by: dholmes, alanb ! src/java.instrument/share/native/libinstrument/EncodingSupport.h ! src/java.instrument/share/native/libinstrument/InvocationAdapter.c ! src/java.instrument/share/native/libinstrument/JPLISAgent.c ! src/java.instrument/unix/native/libinstrument/EncodingSupport_md.c ! src/java.instrument/windows/native/libinstrument/EncodingSupport_md.c ! test/jdk/ProblemList.txt ! test/jdk/java/lang/instrument/BootClassPath/BootClassPathTest.sh ! test/jdk/java/lang/instrument/BootClassPath/Setup.java Changeset: 2e321dc7 Author: Andrey Turbanov Committer: Sergey Bylokhov Date: 2021-09-09 21:47:59 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2e321dc782e0de9995b1772e4cee9c0304bc183d 8273528: Avoid ByteArrayOutputStream.toByteArray when converting stream to String Reviewed-by: bpb, xuelei, serb, aivanov ! src/java.base/share/classes/sun/security/util/BitArray.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/png/PNGImageReader.java ! src/java.desktop/share/classes/sun/awt/DebugSettings.java ! src/java.desktop/share/classes/sun/awt/datatransfer/DataTransferer.java Changeset: 08f0be83 Author: matias9927 Committer: Coleen Phillimore Date: 2021-09-10 01:05:37 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/08f0be8388914901ac40525ed995136ce020f432 8272608: java_lang_System::allow_security_manager() doesn't set its initialization flag Reviewed-by: coleenp, dholmes ! src/hotspot/share/classfile/javaClasses.cpp Changeset: 70c9e026 Author: Pankaj Bansal Date: 2021-09-10 06:13:32 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/70c9e026b63aadf9a2bfcbda45c2b9ea866afafa 8272148: JDesktopPane:getComponentCount() returns one extra than expected with GTKLookAndFeel Reviewed-by: prr, serb ! src/java.desktop/share/classes/javax/swing/JComponent.java Changeset: 792281d5 Author: Tobias Holenstein Committer: Tobias Hartmann Date: 2021-09-10 07:43:15 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/792281d559ca1f01493775fdfc2a6ed09b3b883d 8264517: C2: make MachCallNode::return_value_is_used() only available for x86 Reviewed-by: kvn, thartmann ! src/hotspot/share/opto/machnode.cpp ! src/hotspot/share/opto/machnode.hpp Changeset: 2eaf374c Author: Tobias Holenstein Committer: Tobias Hartmann Date: 2021-09-10 07:44:12 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2eaf374c5ce08287311cfac8145f97bf839365a7 8272698: LoadNode::pin is unused Reviewed-by: roland, thartmann ! src/hotspot/share/opto/memnode.hpp Changeset: c1e39faa Author: Per Liden Date: 2021-09-10 09:49:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c1e39faaa99ee62ff626ffec9f978ed0f8ffaca1 8273482: Remove "foreground work" concept from WorkGang Reviewed-by: tschatzl, kbarrett ! src/hotspot/share/gc/shared/workgroup.cpp ! src/hotspot/share/gc/shared/workgroup.hpp ! src/hotspot/share/gc/shenandoah/shenandoahCodeRoots.cpp ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.cpp ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.inline.hpp ! src/hotspot/share/services/heapDumper.cpp Changeset: 0985887f Author: duke Date: 2021-09-10 11:00:57 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0985887fa38b7a5e6a37012042e7a00b67a9f025 Automatic merge of jdk:master into master Changeset: b29641ad Author: duke Date: 2021-09-10 11:01:21 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b29641ad0d86f4494d56f79fc6b72c111764922b Automatic merge of master into foreign-memaccess+abi ! src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java Changeset: f65c0092 Author: duke Date: 2021-09-10 11:01:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f65c0092f939501ba7d5e2fabf30ec474848e0b3 Automatic merge of foreign-memaccess+abi into foreign-jextract ! make/conf/jib-profiles.js ! make/conf/jib-profiles.js From duke at openjdk.java.net Fri Sep 10 11:18:01 2021 From: duke at openjdk.java.net (duke) Date: Fri, 10 Sep 2021 11:18:01 GMT Subject: git: openjdk/panama-foreign: foreign-memaccess+abi: 85 new changesets Message-ID: <380a268b-e010-4026-bbf4-0b2baac4cdf4@openjdk.org> Changeset: 28ba78e6 Author: Vladimir Ivanov Date: 2021-09-03 12:05:00 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/28ba78e64721529fd764a7c09a7142a96c245f05 8244675: assert(IncrementalInline || (_late_inlines.length() == 0 && !has_mh_late_inlines())) Reviewed-by: dlong ! src/hotspot/share/opto/callGenerator.cpp ! src/hotspot/share/opto/doCall.cpp + test/hotspot/jtreg/compiler/vectorapi/TestNoInline.java Changeset: 8c379092 Author: Vicente Romero Date: 2021-09-03 13:11:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8c379092747301de70db1ef8e441cbe09fd742e7 8273234: extended 'for' with expression of type tvar causes the compiler to crash Reviewed-by: jlahoda ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java + test/langtools/tools/javac/foreach/ExprTypeIsTypeVariableTest.java Changeset: ff4018bc Author: Vicente Romero Date: 2021-09-03 15:20:23 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ff4018bc867841b566d619029fb637a128bc39a7 8268148: unchecked warnings handle ? and ? extends Object differently Reviewed-by: jlahoda ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java ! test/langtools/tools/javac/generics/inference/8176534/T8176534.out + test/langtools/tools/javac/warnings/UnboundAndBoundByObjectTest.java Changeset: 23fa0dcf Author: Albert Mingkun Yang Date: 2021-09-03 16:53:53 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/23fa0dcff062803d249c863b90a00744e3477656 8272905: Consolidate discovered lists processing Reviewed-by: tschatzl, kbarrett ! src/hotspot/share/gc/shared/referenceProcessor.cpp ! src/hotspot/share/gc/shared/referenceProcessor.hpp ! src/hotspot/share/gc/shared/referenceProcessorPhaseTimes.cpp Changeset: d414a88d Author: Yumin Qi Date: 2021-09-03 20:36:48 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d414a88d88a5734d6c431e74d735a780a90d60cf 8273240: Dynamic test ArchiveConsistency.java should use CDSArchiveUtils Reviewed-by: iklam ! test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/ArchiveConsistency.java ! test/lib/jdk/test/lib/cds/CDSArchiveUtils.java Changeset: 14a3ac09 Author: Dean Long Date: 2021-09-03 23:23:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/14a3ac09fe504ea97d269b78872bef6021c976fd 8271911: replay compilations of methods which use JSR292 (easy cases) 8012267: ciReplay: fails to resolve @SignaturePolymorphic methods in replay data 8012268: ciReplay: process_ciInstanceKlass: JVM_CONSTANT_MethodHandle not supported Reviewed-by: kvn, vlivanov ! src/hotspot/share/ci/ciEnv.cpp ! src/hotspot/share/ci/ciEnv.hpp ! src/hotspot/share/ci/ciInstanceKlass.cpp ! src/hotspot/share/ci/ciInstanceKlass.hpp ! src/hotspot/share/ci/ciMethod.cpp ! src/hotspot/share/ci/ciMethod.hpp ! src/hotspot/share/ci/ciMethodData.cpp ! src/hotspot/share/ci/ciReplay.cpp ! src/hotspot/share/ci/ciReplay.hpp ! test/hotspot/jtreg/compiler/ciReplay/CiReplayBase.java ! test/hotspot/jtreg/compiler/ciReplay/TestInlining.java Changeset: cec6c068 Author: Prasanta Sadhukhan Date: 2021-09-04 11:04:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/cec6c068b03d890312e50b448fbc26102c635249 8272232: javax/swing/JTable/4275046/bug4275046.java failed with "Expected value in the cell: 'rededited' but found 'redEDITED'." 8257540: javax/swing/JFileChooser/8041694/bug8041694.java failed with "RuntimeException: The selected directory name is not the expected 'd ' but 'D '." Reviewed-by: serb ! test/jdk/java/awt/List/ActionEventTest/ActionEventTest.java ! test/jdk/java/awt/dnd/RecognizedActionTest/RecognizedActionTest.java ! test/jdk/javax/swing/JFileChooser/8041694/bug8041694.java ! test/jdk/javax/swing/JRadioButton/8033699/bug8033699.java ! test/jdk/javax/swing/JTable/4275046/bug4275046.java Changeset: c640fe42 Author: lawrence.andrews Committer: Sergey Bylokhov Date: 2021-09-05 09:15:38 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c640fe42c2b5e6668a2a875678be44443942c868 7188098: TEST_BUG: closed/javax/sound/midi/Synthesizer/Receiver/bug6186488.java fails Reviewed-by: serb ! test/jdk/javax/sound/midi/Synthesizer/Receiver/bug6186488.java Changeset: 4d25e6f6 Author: Aleksey Shipilev Date: 2021-09-06 08:08:05 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4d25e6f6c7ee855771ab9c05ae85a9d92c866941 8273335: compiler/blackhole tests should not run with interpreter-only VMs Reviewed-by: kvn ! test/hotspot/jtreg/compiler/blackhole/BlackholeExistingIntrinsicWarningTest.java ! test/hotspot/jtreg/compiler/blackhole/BlackholeExperimentalUnlockTest.java ! test/hotspot/jtreg/compiler/blackhole/BlackholeIntrinsicTest.java ! test/hotspot/jtreg/compiler/blackhole/BlackholeNonEmptyWarningTest.java ! test/hotspot/jtreg/compiler/blackhole/BlackholeNonStaticWarningTest.java ! test/hotspot/jtreg/compiler/blackhole/BlackholeNonVoidWarningTest.java Changeset: b4e5b28b Author: Albert Mingkun Yang Date: 2021-09-06 08:11:34 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b4e5b28b860f10d3e028a2ab042d452db289064f 8273221: Guard GCIdMark against nested calls Reviewed-by: tschatzl, kbarrett ! src/hotspot/share/gc/shared/gcId.cpp ! src/hotspot/share/gc/shared/gcId.hpp Changeset: 70ed6c5b Author: Daniel Gredler Committer: Jayathirth D V Date: 2021-09-06 08:13:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/70ed6c5b8c52dc1c1c25967a09164a013bdb4bdd 8272878: JEP 381 cleanup: Remove unused Solaris code in sun.font.TrueTypeGlyphMapper Reviewed-by: prr, jdv ! src/java.desktop/share/classes/sun/font/TrueTypeGlyphMapper.java Changeset: fb5b144e Author: Thomas Schatzl Date: 2021-09-06 09:07:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fb5b144eca761d4b4c667efe05ca638536c065ac 8272985: Reference discovery is confused about atomicity and degree of parallelism Reviewed-by: ayang, kbarrett ! src/hotspot/share/gc/shared/referenceProcessor.cpp ! src/hotspot/share/gc/shared/referenceProcessor.hpp ! src/hotspot/share/gc/shared/referenceProcessor.inline.hpp Changeset: 1bf5bda2 Author: Markus Gr?nlund Date: 2021-09-06 09:13:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1bf5bda2919b3236040bf12c51eba552c6309cf7 8269418: jdk/jfr/event/oldobject/TestObjectSize.java failed with "RuntimeException: No events: expected false, was true" Reviewed-by: jbachorik ! test/jdk/ProblemList.txt ! test/jdk/jdk/jfr/event/oldobject/TestObjectSize.java Changeset: 44c5c23b Author: Dan Heidinga Committer: Aleksey Shipilev Date: 2021-09-06 13:39:03 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/44c5c23b96adf071339b39cfaea08c2d3a19d839 8272164: DumpAllocStats shouldn't subclass from ResourceObj Reviewed-by: shade, iklam, dholmes ! src/hotspot/share/cds/dumpAllocStats.hpp Changeset: 2cabec8d Author: Thomas Schatzl Date: 2021-09-06 14:28:54 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2cabec8ddc19dd66495957e7ef553990a502e993 8253343: Extract G1 Young GC algorithm related code from G1CollectedHeap Reviewed-by: ayang, 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/g1YoungCollector.cpp + src/hotspot/share/gc/g1/g1YoungCollector.hpp ! src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.cpp Changeset: 7bd4f496 Author: Patric Hedlin Date: 2021-09-06 14:43:54 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7bd4f496b493b804990615f6ce2cb1b4abd29a86 8264207: CodeStrings does not honour fixed address assumption. Reviewed-by: redestad, neliasso ! src/hotspot/share/asm/codeBuffer.cpp ! src/hotspot/share/asm/codeBuffer.hpp ! src/hotspot/share/code/codeBlob.cpp ! src/hotspot/share/code/codeBlob.hpp ! src/hotspot/share/code/icBuffer.hpp ! src/hotspot/share/code/stubs.cpp ! src/hotspot/share/code/stubs.hpp ! src/hotspot/share/compiler/disassembler.cpp ! src/hotspot/share/compiler/disassembler.hpp ! src/hotspot/share/interpreter/interpreter.cpp ! src/hotspot/share/interpreter/interpreter.hpp ! src/hotspot/share/interpreter/interpreterRuntime.cpp ! src/hotspot/share/runtime/sharedRuntime.cpp ! src/hotspot/share/runtime/stubCodeGenerator.cpp ! src/hotspot/share/runtime/stubCodeGenerator.hpp + test/hotspot/gtest/code/test_codestrings.cpp Changeset: fc546d6d Author: Aleksey Shipilev Date: 2021-09-06 16:00:12 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fc546d6de9a3ed33cf4b04e24e62714332b069cb 8273378: Shenandoah: Remove the remaining uses of os::is_MP Reviewed-by: aph, zgu ! src/hotspot/cpu/x86/gc/shenandoah/shenandoahBarrierSetAssembler_x86.cpp Changeset: eb221812 Author: Kim Barrett Date: 2021-09-06 18:19:58 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/eb221812b28c1c6da2e442292a4f7cb5226b62ba 8273386: Remove duplicated code in G1DCQS::abandon_completed_buffers Reviewed-by: tschatzl ! src/hotspot/share/gc/g1/g1DirtyCardQueue.cpp Changeset: 649c22c5 Author: Wang Huang Committer: Nick Gasson Date: 2021-09-07 01:40:24 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/649c22c5b17efbc3116ac34739b8d1be39de01be 8270832: Aarch64: Update algorithm annotations for MacroAssembler::fill_words Co-authored-by: Wang Huang Co-authored-by: Miu Zhuojun Co-authored-by: Wu Yan Reviewed-by: ngasson, aph ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp Changeset: 81c719be Author: Aleksey Shipilev Date: 2021-09-07 07:35:23 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/81c719be3995fa54974e8b8826ad81bf07bd012f 8273333: Zero should warn about unimplemented -XX:+LogTouchedMethods Reviewed-by: minqi, dholmes ! src/hotspot/share/runtime/arguments.cpp ! test/hotspot/jtreg/runtime/CommandLine/PrintTouchedMethods.java Changeset: 3cd95a29 Author: Leo Korinth Date: 2021-09-07 08:23:32 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3cd95a2932ab6a2cb39322354f7ad181de8bfc9e 8231356: Fix broken ResourceObj::operator new[] in debug builds Reviewed-by: kbarrett, iklam ! src/hotspot/share/memory/allocation.cpp ! src/hotspot/share/memory/allocation.hpp Changeset: a522d6b5 Author: Aleksey Shipilev Date: 2021-09-07 08:52:53 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a522d6b53cd841b4bfe87eac5778c9e5cdf5e90f 8273376: Zero: Disable vtable/itableStub gtests Reviewed-by: jiefu, stuefe ! test/hotspot/gtest/code/test_vtableStub.cpp Changeset: 5caa77b0 Author: Ivan ?ipka Committer: Daniel Fuchs Date: 2021-09-07 09:46:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5caa77b043ae490c3d7d56d181d0e07e6b859b9e 8263364: sun/net/www/http/KeepAliveStream/KeepAliveStreamCloseWithWrongContentLength.java wedged in getInputStream Reviewed-by: dfuchs ! test/jdk/sun/net/www/http/KeepAliveStream/KeepAliveStreamCloseWithWrongContentLength.java Changeset: 70157c78 Author: Jan Lahoda Date: 2021-09-07 09:50:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/70157c78a838126bb29c91a410d9158763bfa2ad 8272135: jshell: Method cannot use its overloaded version Reviewed-by: vromero ! src/jdk.jshell/share/classes/jdk/jshell/Eval.java ! src/jdk.jshell/share/classes/jdk/jshell/TaskFactory.java ! src/jdk.jshell/share/classes/jdk/jshell/TreeDissector.java ! test/langtools/jdk/jshell/MethodsTest.java Changeset: 377b1867 Author: Vladimir Ivanov Date: 2021-09-07 11:35:31 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/377b186724473475480b834d99c38b8161bf6917 8269119: C2: Avoid redundant memory barriers in Unsafe.copyMemory0 intrinsic Reviewed-by: thartmann, roland ! src/hotspot/share/opto/library_call.cpp + test/hotspot/jtreg/compiler/unsafe/UnsafeCopyMemory.java Changeset: 041ae20b Author: Fernando Guallini Committer: Rajan Halade Date: 2021-09-07 14:36:15 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/041ae20b10e11381415e8f61fd39e9e19aa8d4f2 8268558: [TESTBUG] Case 2 in TestP11KeyFactoryGetRSAKeySpec is skipped Reviewed-by: mullan, rhalade ! test/jdk/sun/security/pkcs11/rsa/TestP11KeyFactoryGetRSAKeySpec.java Changeset: 99fb12c7 Author: Roland Westrelin Date: 2021-09-07 15:13:12 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/99fb12c798ad24cc4a671a666930ba42c3cd10c9 8271341: Opcode() != Op_If && Opcode() != Op_RangeCheck) || outcnt() == 2 assert failure with Test7179138_1.java Reviewed-by: kvn, thartmann ! src/hotspot/share/opto/stringopts.cpp ! test/hotspot/jtreg/compiler/c2/Test7179138_1.java Changeset: 2abf3b3b Author: Roland Westrelin Date: 2021-09-07 15:15:17 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2abf3b3b2743947282300ee8416611559e49fca0 8271340: Crash PhaseIdealLoop::clone_outer_loop Reviewed-by: kvn, thartmann ! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp ! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.hpp ! src/hotspot/share/opto/cfgnode.cpp + test/hotspot/jtreg/compiler/loopopts/TestInfiniteLoopCCP.java Changeset: df05b4d1 Author: Prasanta Sadhukhan Date: 2021-09-07 15:50:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/df05b4d1a13e55755107695ad9ea7a8a1084901a 8271923: [macos] the text color on the selected disabled tabbed pane button remains white making text unreadable Reviewed-by: jdv ! src/java.desktop/macosx/classes/com/apple/laf/AquaLookAndFeel.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaTabbedPaneContrastUI.java Changeset: 270a9d92 Author: Alexey Ivanov Date: 2021-09-07 19:05:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/270a9d929307dce52e6961e57492c03a633ed044 8273043: [TEST_BUG] Automate NimbusJTreeSelTextColor.java Reviewed-by: serb ! test/jdk/javax/swing/plaf/nimbus/NimbusJTreeSelTextColor.java Changeset: 708407ed Author: Andrey Turbanov Committer: Alexey Ivanov Date: 2021-09-07 21:12:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/708407eddc9d52c01de02e3986c05e1c6225fa85 8273168: Remove superfluous use of boxing in java.desktop Reviewed-by: aivanov ! src/java.desktop/share/classes/com/sun/imageio/plugins/png/PNGMetadata.java ! src/java.desktop/share/classes/java/awt/Font.java ! src/java.desktop/share/classes/javax/swing/text/html/CSS.java ! src/java.desktop/share/classes/javax/swing/text/html/HTML.java ! src/java.desktop/share/classes/sun/awt/datatransfer/DataTransferer.java ! src/java.desktop/unix/classes/sun/print/PrintServiceLookupProvider.java ! src/java.desktop/windows/classes/sun/awt/windows/WPathGraphics.java Changeset: d6d6c069 Author: Mark Sheppard Date: 2021-09-07 22:18:23 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d6d6c0692bff77bd18127ed61455aac39370a089 8273246: Amend the test java/nio/channels/DatagramChannel/ManySourcesAndTargets.java to execute in othervm mode Reviewed-by: alanb ! test/failure_handler/src/share/conf/mac.properties ! test/jdk/java/nio/channels/DatagramChannel/ManySourcesAndTargets.java Changeset: 8884d2f8 Author: Daniel D. Daugherty Date: 2021-09-08 00:34:11 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8884d2f854fafdc5f775fce557053d072e4a882c 8273462: ProblemList vmTestbase/vm/mlvm/anonloader/stress/oome/heap/Test.java in -Xcomp mode Reviewed-by: dholmes ! test/hotspot/jtreg/ProblemList-Xcomp.txt Changeset: 4eacdb38 Author: Yasumasa Suenaga Date: 2021-09-08 01:27:13 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4eacdb38a83b545603928392eccb116c744ef3b3 8273104: Refactoring option parser for UL Reviewed-by: iklam, dholmes ! src/hotspot/share/logging/logFileOutput.cpp ! src/hotspot/share/logging/logFileOutput.hpp ! src/hotspot/share/logging/logFileStreamOutput.cpp ! src/hotspot/share/logging/logFileStreamOutput.hpp ! src/hotspot/share/logging/logOutput.cpp ! src/hotspot/share/logging/logOutput.hpp ! test/hotspot/jtreg/runtime/logging/FoldMultilinesTest.java Changeset: ea4907a8 Author: Daniel D. Daugherty Date: 2021-09-08 02:13:41 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ea4907a8789e00f9ec8d4175241246b8cf53f3f6 8273047: test jfr/api/consumer/TestRecordedFrame.java timing out Reviewed-by: dholmes ! test/jdk/jdk/jfr/api/consumer/TestRecordedFrame.java Changeset: 1513dc7a Author: Andrey Turbanov Committer: Sergey Bylokhov Date: 2021-09-08 04:36:41 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1513dc7afc33386106439ccb9b7b16956b3c534a 8271603: Unnecessary Vector usage in java.desktop Reviewed-by: prr, serb ! src/java.desktop/macosx/classes/com/apple/laf/AquaFileChooserUI.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/common/SimpleRenderedImage.java ! src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKFileChooserUI.java ! src/java.desktop/share/classes/com/sun/media/sound/AbstractMixer.java ! src/java.desktop/share/classes/com/sun/media/sound/AlawCodec.java ! src/java.desktop/share/classes/com/sun/media/sound/PCMtoPCMCodec.java ! src/java.desktop/share/classes/com/sun/media/sound/UlawCodec.java ! src/java.desktop/share/classes/java/awt/Menu.java ! src/java.desktop/share/classes/java/awt/Window.java ! src/java.desktop/share/classes/javax/print/MimeType.java ! src/java.desktop/share/classes/javax/sound/sampled/AudioSystem.java ! src/java.desktop/share/classes/javax/swing/JFileChooser.java ! src/java.desktop/share/classes/javax/swing/JMenu.java ! src/java.desktop/share/classes/javax/swing/JMenuBar.java ! src/java.desktop/share/classes/javax/swing/JOptionPane.java ! src/java.desktop/share/classes/javax/swing/JPopupMenu.java ! src/java.desktop/share/classes/javax/swing/UIManager.java ! src/java.desktop/share/classes/javax/swing/plaf/metal/MetalFileChooserUI.java ! src/java.desktop/share/classes/javax/swing/text/AbstractDocument.java ! src/java.desktop/share/classes/javax/swing/text/DefaultStyledDocument.java ! src/java.desktop/share/classes/javax/swing/text/JTextComponent.java ! src/java.desktop/share/classes/javax/swing/text/ZoneView.java ! src/java.desktop/share/classes/javax/swing/text/html/AccessibleHTML.java ! src/java.desktop/share/classes/javax/swing/text/html/CSS.java ! src/java.desktop/share/classes/javax/swing/text/rtf/RTFAttributes.java ! src/java.desktop/share/classes/javax/swing/text/rtf/RTFGenerator.java ! src/java.desktop/share/classes/javax/swing/undo/StateEdit.java ! src/java.desktop/share/classes/sun/awt/PlatformFont.java ! src/java.desktop/share/classes/sun/awt/shell/ShellFolder.java ! src/java.desktop/share/classes/sun/swing/plaf/synth/SynthFileChooserUIImpl.java ! src/java.desktop/unix/classes/sun/awt/X11/XWindowPeer.java ! src/java.desktop/unix/classes/sun/print/PrintServiceLookupProvider.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsFileChooserUI.java ! src/java.desktop/windows/classes/sun/awt/Win32GraphicsDevice.java Changeset: 7d24a334 Author: Aleksey Shipilev Date: 2021-09-08 07:43:28 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7d24a3342129d4c71fad0d8d50d20758291d64b7 8273318: Some containers/docker/TestJFREvents.java configs are running out of memory Reviewed-by: ngasson, sgehwolf, mseledtsov ! test/hotspot/jtreg/containers/docker/TestJFREvents.java Changeset: 286a1f6b Author: Aleksey Shipilev Date: 2021-09-08 07:44:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/286a1f6b7c6d7c598ced456f1a5f63cac1be8539 8273440: Zero: Disable runtime/Unsafe/InternalErrorTest.java Reviewed-by: dholmes ! test/hotspot/jtreg/runtime/Unsafe/InternalErrorTest.java Changeset: a66629a4 Author: Hamlin Li Date: 2021-09-08 08:01:18 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a66629a464b97176bcdc2ca1150d12df6241dc1c 8254167: G1: Record regions where evacuation failed to provide targeted iteration Reviewed-by: tschatzl, ayang ! 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/g1CollectionSet.cpp ! src/hotspot/share/gc/g1/g1CollectionSet.hpp ! src/hotspot/share/gc/g1/g1EvacFailure.cpp ! src/hotspot/share/gc/g1/g1EvacFailure.hpp + src/hotspot/share/gc/g1/g1EvacFailureRegions.cpp + src/hotspot/share/gc/g1/g1EvacFailureRegions.hpp + src/hotspot/share/gc/g1/g1EvacFailureRegions.inline.hpp ! src/hotspot/share/gc/g1/g1ParScanThreadState.cpp ! src/hotspot/share/gc/g1/g1ParScanThreadState.hpp ! src/hotspot/share/gc/g1/g1YoungCollector.cpp ! src/hotspot/share/gc/g1/g1YoungCollector.hpp ! src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.cpp ! src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.hpp Changeset: 6750c34c Author: Andrew Haley Date: 2021-09-08 10:08:30 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6750c34c92b5f28bba4a88ac798b800fce380d32 8270533: AArch64: size_fits_all_mem_uses should return false if its output is a CAS Reviewed-by: adinn, ngasson ! src/hotspot/cpu/aarch64/aarch64.ad Changeset: 18555742 Author: Markus Karg Committer: Alan Bateman Date: 2021-09-08 11:22:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/185557423d3069d627daecdf87315a49d6597b67 8273038: ChannelInputStream.transferTo() uses FileChannel.transferTo(FileChannel) Reviewed-by: alanb ! src/java.base/share/classes/java/nio/channels/Channels.java ! src/java.base/share/classes/sun/nio/ch/ChannelInputStream.java + src/java.base/share/classes/sun/nio/ch/ChannelOutputStream.java + test/jdk/java/nio/channels/Channels/TransferTo.java Changeset: 21012f2b Author: Vladimir Ivanov Date: 2021-09-08 11:27:14 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/21012f2bbe214955d05f8bc583dcdceb0949b601 8078641: MethodHandle.asTypeCache can retain classes from unloading Co-authored-by: Peter Levart Co-authored-by: Vladimir Ivanov Reviewed-by: psandoz, mchung, plevart ! src/java.base/share/classes/java/lang/invoke/MethodHandle.java ! src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java Changeset: faa942c8 Author: Vladimir Ivanov Date: 2021-09-08 11:28:17 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/faa942c8ba8ad778b6be20ff6d98a5040a9079e9 8273000: Remove WeakReference-based class initialisation barrier implementation Reviewed-by: psandoz, mchung ! src/java.base/share/classes/java/lang/invoke/DirectMethodHandle.java ! src/java.base/share/classes/jdk/internal/misc/Unsafe.java Changeset: 59c9f750 Author: Andrey Turbanov Committer: Alexey Ivanov Date: 2021-09-08 14:28:07 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/59c9f750414e4f131c906a5bc20f32f2f9cfe9ec 8273375: Remove redundant 'new String' calls after concatenation in java.desktop Reviewed-by: aivanov ! src/java.desktop/macosx/classes/com/apple/laf/AquaTabbedPaneCopyFromBasicUI.java ! src/java.desktop/macosx/classes/sun/java2d/IntegerNIORaster.java ! src/java.desktop/share/classes/java/awt/image/ColorModel.java ! src/java.desktop/share/classes/java/awt/image/DirectColorModel.java ! src/java.desktop/share/classes/java/awt/image/IndexColorModel.java ! src/java.desktop/share/classes/sun/awt/image/ByteBandedRaster.java ! src/java.desktop/share/classes/sun/awt/image/ByteComponentRaster.java ! src/java.desktop/share/classes/sun/awt/image/ByteInterleavedRaster.java ! src/java.desktop/share/classes/sun/awt/image/BytePackedRaster.java ! src/java.desktop/share/classes/sun/awt/image/IntegerComponentRaster.java ! src/java.desktop/share/classes/sun/awt/image/IntegerInterleavedRaster.java ! src/java.desktop/share/classes/sun/awt/image/ShortBandedRaster.java ! src/java.desktop/share/classes/sun/awt/image/ShortComponentRaster.java ! src/java.desktop/share/classes/sun/awt/image/ShortInterleavedRaster.java ! src/java.desktop/unix/classes/sun/awt/X11/InfoWindow.java Changeset: f2f8136c Author: jtfuller111 Committer: Tobias Hartmann Date: 2021-09-08 14:38:21 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f2f8136cc9f5a3f554f704024748a09cb80bd037 8265443: IGV: disambiguate groups by emiting additional properties Reviewed-by: thartmann ! src/hotspot/share/opto/idealGraphPrinter.cpp ! src/hotspot/share/opto/idealGraphPrinter.hpp Changeset: 7e662e7b Author: Wang Huang Committer: Tobias Hartmann Date: 2021-09-08 14:39:23 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7e662e7b9d7ea5113f568418e0acac4234ebfb88 8272413: Incorrect num of element count calculation for vector cast Co-authored-by: Wang Huang Co-authored-by: Miu Zhuojun Co-authored-by: Wu Yan Reviewed-by: eliu, kvn ! src/hotspot/share/opto/vectorIntrinsics.cpp Changeset: cb112aff Author: Masanori Yano Committer: Naoto Sato Date: 2021-09-08 15:46:33 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/cb112affd6061e8ace6dad4e92c7b394a413e37f 8269373: some tests in jdk/tools/launcher/ fails on localized Windows platform Reviewed-by: naoto ! test/jdk/tools/launcher/FXLauncherTest.java ! test/jdk/tools/launcher/SourceMode.java Changeset: e5f298a7 Author: Sergey Tsypanov Committer: Naoto Sato Date: 2021-09-08 15:54:36 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e5f298a7f1f3106b72e43c152c090af1657485f0 8273329: Remove redundant null check from String.getBytes(String charsetName) Reviewed-by: rriggs, iris, naoto ! src/java.base/share/classes/java/lang/String.java Changeset: d7efd0e8 Author: Sandhya Viswanathan Date: 2021-09-08 16:07:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d7efd0e8cf14c732427d2c1363b60278bebdc06a 8273450: Fix the copyright header of SVML files Reviewed-by: dholmes, psandoz ! 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/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: f7e9f56e Author: Vladimir Ivanov Date: 2021-09-08 16:17:56 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f7e9f56e235dc50daae0a85c9790d5b04c9c60f0 8273359: CI: ciInstanceKlass::get_canonical_holder() doesn't respect instance size Reviewed-by: kvn ! src/hotspot/share/c1/c1_LIRGenerator.cpp ! src/hotspot/share/ci/ciInstanceKlass.cpp ! src/hotspot/share/ci/ciInstanceKlass.hpp ! src/hotspot/share/opto/compile.cpp + test/hotspot/jtreg/compiler/unsafe/AlignmentGapAccess.java Changeset: 267c61a1 Author: Aleksey Shipilev Date: 2021-09-08 16:36:31 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/267c61a16a916e35762e8df5737ec74b06defae8 8273361: InfoOptsTest is failing in tier1 Reviewed-by: jpai, ihse, jlahoda ! test/langtools/tools/javac/options/modes/InfoOptsTest.java ! test/langtools/tools/javac/options/modes/OptionModesTester.java Changeset: 4d5e1ed9 Author: Jonathan Gibbons Date: 2021-09-08 17:38:05 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4d5e1ed9589713bdae5ebe659e657b9c6b833c3f 8272375: Improve phrasing of synthesized descriptions in JavaFX docs Reviewed-by: kcr, prappo ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties ! test/langtools/jdk/javadoc/doclet/testJavaFX/TestJavaFX.java ! test/langtools/jdk/javadoc/doclet/testJavaFX/TestJavaFXCombo.java ! test/langtools/jdk/javadoc/doclet/testJavaFX/TestJavaFXMissingPropComments.java Changeset: ba31eee4 Author: Daniel D. Daugherty Date: 2021-09-08 18:33:04 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ba31eee4fc92bba3657e5f3fec2b85f55120d7a1 8273109: runtime/cds/appcds/loaderConstraints/DynamicLoaderConstraintsTest times out Reviewed-by: bpb ! test/hotspot/jtreg/runtime/cds/appcds/loaderConstraints/DynamicLoaderConstraintsTest.java Changeset: e6805032 Author: Thomas Schatzl Date: 2021-09-08 19:02:49 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e6805032ff328773eafe8b94e9f1b3b196f52196 8273185: Rename the term "atomic" in ReferenceProcessor Reviewed-by: ayang, shade ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/parallel/psScavenge.cpp ! src/hotspot/share/gc/shared/referenceProcessor.cpp ! src/hotspot/share/gc/shared/referenceProcessor.hpp Changeset: 9b5991e8 Author: Leonid Mesnik Date: 2021-09-08 19:30:17 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9b5991e811b789fe8b60701657c2f0dd2c222c2e 8273451: Remove unreachable return in mutexLocker::wait Reviewed-by: minqi, coleenp ! src/hotspot/share/runtime/mutexLocker.hpp Changeset: a5e4def5 Author: Leonid Mesnik Date: 2021-09-08 19:31:18 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a5e4def526697d88ff31a5fdb41d823b899372f2 8265489: Stress test times out because of long ObjectSynchronizer::monitors_iterate(...) operation Reviewed-by: dcubed ! src/hotspot/share/prims/jvmtiEnvBase.cpp ! src/hotspot/share/prims/jvmtiEnvBase.hpp ! src/hotspot/share/runtime/synchronizer.cpp ! src/hotspot/share/runtime/synchronizer.hpp ! src/hotspot/share/services/threadService.cpp Changeset: 7fd6b0bf Author: Roger Riggs Date: 2021-09-08 20:53:25 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7fd6b0bfd8ab3c64b374c71010bdfa369f0c67e8 8273242: (test) Refactor to use TestNG for RuntimeTests ExecCommand tests Reviewed-by: naoto, lancea ! test/jdk/java/lang/RuntimeTests/exec/ExecCommand.java Changeset: 12f0b771 Author: Daniel D. Daugherty Date: 2021-09-09 00:39:40 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/12f0b771791614b8a41fc2c62d34481f911109b0 8273516: ProblemList compiler/c2/Test7179138_1.java in -Xcomp mode on win-X64 Reviewed-by: dholmes ! test/hotspot/jtreg/ProblemList-Xcomp.txt Changeset: 5df26480 Author: Hamlin Li Date: 2021-09-09 00:41:28 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5df26480864f1efd16eb5800833bf7106371b97a 8273218: G1: Rename g1EvacuationInfo to g1EvacInfo Reviewed-by: tschatzl, ayang ! src/hotspot/share/gc/g1/g1Allocator.cpp ! src/hotspot/share/gc/g1/g1Allocator.hpp = src/hotspot/share/gc/g1/g1EvacInfo.hpp ! src/hotspot/share/gc/g1/g1Trace.cpp ! src/hotspot/share/gc/g1/g1Trace.hpp ! src/hotspot/share/gc/g1/g1YoungCollector.cpp ! src/hotspot/share/gc/g1/g1YoungCollector.hpp ! src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.cpp ! src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.hpp Changeset: 6eba4434 Author: Matthias Baesken Date: 2021-09-09 06:15:15 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6eba443428ff7abe7c0509047ec76432affebe65 8273387: remove some unreferenced gtk-related functions Reviewed-by: pbansal, clanger ! src/java.desktop/unix/native/libawt_xawt/awt/gtk2_interface.c ! src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.c Changeset: 5b1dfe4e Author: Thomas Schatzl Date: 2021-09-09 07:28:23 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5b1dfe4e358d249aef9330e39b6404a13b4ebc0e 8273439: Fix G1CollectedHeap includes and forward declarations Reviewed-by: ayang, kbarrett ! src/hotspot/share/gc/g1/g1CollectedHeap.hpp Changeset: dc33bd8b Author: Aleksey Shipilev Date: 2021-09-09 07:43:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/dc33bd8b6cfa9a9cd71d7065d284a807774750a2 8273315: Parallelize and increase timeouts for java/foreign/TestMatrix.java test Reviewed-by: mcimadamore ! test/jdk/java/foreign/TestMatrix.java Changeset: 8c16f485 Author: Aleksey Shipilev Date: 2021-09-09 08:07:00 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8c16f485b341ee3071c91df39dfb9ba8b9caa44d 8273487: Zero: Handle "zero" variant in runtime tests Reviewed-by: alanb, dholmes ! test/lib/jdk/test/lib/Platform.java Changeset: aa931118 Author: Aleksey Shipilev Date: 2021-09-09 09:46:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/aa9311182ae88312a70b18afd85939718415b77c 8273483: Zero: Clear pending JNI exception check in native method handler Reviewed-by: aph ! src/hotspot/cpu/zero/zeroInterpreter_zero.cpp Changeset: 00e059dd Author: Evan Whelan Committer: Daniel Fuchs Date: 2021-09-09 10:23:12 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/00e059ddb34b5f2d6ba1ea0f38308c5b382a8e4d 8133686: HttpURLConnection.getHeaderFields and URLConnection.getRequestProperties methods return field values in reverse order Reviewed-by: dfuchs ! src/java.base/share/classes/java/net/URLConnection.java ! src/java.base/share/classes/sun/net/www/MessageHeader.java + test/jdk/java/net/HttpURLConnection/HttpURLConnectionHeadersOrder.java ! test/jdk/java/net/URLConnection/RequestPropertyValues.java ! test/jdk/java/net/URLConnection/URLConnectionHeaders.java + test/jdk/java/net/URLConnection/URLConnectionHeadersOrder.java ! test/jdk/sun/net/www/MessageHeaderTest.java Changeset: 9690df7f Author: Hamlin Li Date: 2021-09-09 10:41:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9690df7fb9843bdc4775a34d94b2ca81f40aea0a 8273476: G1: refine G1CollectedHeap::par_iterate_regions_array_part_from Reviewed-by: ayang, tschatzl ! 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/g1EvacFailureRegions.cpp Changeset: f6cc1732 Author: Martin Doerr Date: 2021-09-09 10:48:02 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f6cc1732f47672cea413fa842c4f106c1314c626 8273539: [PPC64] gtest build error after JDK-8264207 Reviewed-by: shade, stuefe ! test/hotspot/gtest/code/test_codestrings.cpp Changeset: 5ca26cbd Author: Aleksey Shipilev Date: 2021-09-09 13:41:46 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5ca26cbddbdd47a73cc141a6215dc89c53841d4a 8273433: Enable parallelism in vmTestbase_nsk_sysdict tests Reviewed-by: mseledtsov, dholmes - test/hotspot/jtreg/vmTestbase/nsk/sysdict/vm/stress/btree/btree001/TEST.properties - test/hotspot/jtreg/vmTestbase/nsk/sysdict/vm/stress/btree/btree002/TEST.properties - test/hotspot/jtreg/vmTestbase/nsk/sysdict/vm/stress/btree/btree003/TEST.properties - test/hotspot/jtreg/vmTestbase/nsk/sysdict/vm/stress/btree/btree004/TEST.properties - test/hotspot/jtreg/vmTestbase/nsk/sysdict/vm/stress/btree/btree005/TEST.properties - test/hotspot/jtreg/vmTestbase/nsk/sysdict/vm/stress/btree/btree006/TEST.properties - test/hotspot/jtreg/vmTestbase/nsk/sysdict/vm/stress/btree/btree007/TEST.properties - test/hotspot/jtreg/vmTestbase/nsk/sysdict/vm/stress/btree/btree008/TEST.properties - test/hotspot/jtreg/vmTestbase/nsk/sysdict/vm/stress/btree/btree009/TEST.properties - test/hotspot/jtreg/vmTestbase/nsk/sysdict/vm/stress/btree/btree010/TEST.properties - test/hotspot/jtreg/vmTestbase/nsk/sysdict/vm/stress/btree/btree011/TEST.properties - test/hotspot/jtreg/vmTestbase/nsk/sysdict/vm/stress/btree/btree012/TEST.properties - test/hotspot/jtreg/vmTestbase/nsk/sysdict/vm/stress/chain/chain001/TEST.properties - test/hotspot/jtreg/vmTestbase/nsk/sysdict/vm/stress/chain/chain002/TEST.properties - test/hotspot/jtreg/vmTestbase/nsk/sysdict/vm/stress/chain/chain003/TEST.properties - test/hotspot/jtreg/vmTestbase/nsk/sysdict/vm/stress/chain/chain004/TEST.properties - test/hotspot/jtreg/vmTestbase/nsk/sysdict/vm/stress/chain/chain005/TEST.properties - test/hotspot/jtreg/vmTestbase/nsk/sysdict/vm/stress/chain/chain006/TEST.properties - test/hotspot/jtreg/vmTestbase/nsk/sysdict/vm/stress/chain/chain007/TEST.properties - test/hotspot/jtreg/vmTestbase/nsk/sysdict/vm/stress/chain/chain008/TEST.properties Changeset: 4866eaa9 Author: Tobias Hartmann Date: 2021-09-09 13:44:05 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4866eaa997b2ee2a47bdcd0d96202f220fb2774d 8273409: Receiver type narrowed by CCP does not always trigger post-parse call devirtualization Reviewed-by: vlivanov, neliasso ! src/hotspot/share/opto/phaseX.cpp + test/hotspot/jtreg/compiler/c2/irTests/TestPostParseCallDevirtualization.java ! test/hotspot/jtreg/compiler/lib/ir_framework/IRNode.java Changeset: c81690d7 Author: Tobias Hartmann Date: 2021-09-09 13:54:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c81690d7166c32caff6ef3a55fe9b157049e2b56 8273498: compiler/c2/Test7179138_1.java timed out Reviewed-by: roland ! test/hotspot/jtreg/ProblemList-Xcomp.txt ! test/hotspot/jtreg/compiler/c2/Test7179138_1.java Changeset: e3bda63c Author: Aleksey Shipilev Date: 2021-09-09 17:19:14 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e3bda63ce29bac0eaea520d42f4927dda77f83f2 8273489: Zero: Handle UseHeavyMonitors on all monitorenter paths Reviewed-by: coleenp ! src/hotspot/cpu/zero/zeroInterpreter_zero.cpp Changeset: 96614da0 Author: Maurizio Cimadamore Date: 2021-09-09 17:28:06 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/96614da0254e7fd4ac9dd3c3059bf23c1aaf37ff 8272903: Missing license header in ArenaAllocator.java Reviewed-by: bpb, lancea ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/ArenaAllocator.java Changeset: ef4a5328 Author: Saravana Kumar Vijayasekaran Committer: Erik Joelsson Date: 2021-09-09 18:24:26 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ef4a532802096f3958567c2ed22c1b317ac21fbe 8263773: Reenable German localization for builds at Oracle Reviewed-by: erikj, ihse ! make/conf/jib-profiles.js ! test/jdk/build/translations/VerifyTranslations.java Changeset: dd1209e4 Author: Vicente Romero Date: 2021-09-09 18:36:17 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/dd1209e4ae3c8e42d121329639ec4bd359d0a456 8268885: duplicate checkcast when destination type is not first type of intersection type Reviewed-by: jlahoda ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransTypes.java ! test/langtools/tools/javac/cast/intersection/DuplicatedCheckcastTest.java Changeset: 185eacac Author: Per Liden Date: 2021-09-09 19:19:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/185eacacdde9de12936520a1cda847f7e541c62f 8273545: Remove Thread::is_GC_task_thread() Reviewed-by: stefank, coleenp, shade ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp ! src/hotspot/share/gc/parallel/parallelScavengeHeap.hpp ! src/hotspot/share/gc/parallel/psParallelCompact.cpp ! src/hotspot/share/gc/shared/workgroup.cpp ! src/hotspot/share/gc/shared/workgroup.hpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoahWorkGroup.hpp ! src/hotspot/share/gc/z/zCollectedHeap.cpp ! src/hotspot/share/gc/z/zRuntimeWorkers.cpp ! src/hotspot/share/gc/z/zWorkers.cpp ! src/hotspot/share/runtime/thread.hpp ! test/hotspot/gtest/gc/g1/test_g1BatchedGangTask.cpp ! test/hotspot/gtest/gc/g1/test_g1CardSet.cpp ! test/hotspot/gtest/gc/g1/test_stressCommitUncommit.cpp ! test/hotspot/gtest/gc/shared/test_oopStorage.cpp ! test/hotspot/gtest/gc/shared/test_oopStorage_parperf.cpp Changeset: 4020a60c Author: Per Liden Date: 2021-09-09 19:21:55 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4020a60cbb3db0458262212d46515c8c11492a5b 8273550: Replace os::cgc_thread/pgc_thread with os::gc_thread Reviewed-by: stefank, coleenp ! src/hotspot/os/posix/os_posix.cpp ! src/hotspot/os/windows/os_windows.cpp ! src/hotspot/share/gc/shared/concurrentGCThread.cpp ! src/hotspot/share/gc/shared/workgroup.cpp ! src/hotspot/share/runtime/os.hpp Changeset: 54dee132 Author: Naoto Sato Date: 2021-09-09 19:41:56 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/54dee132d1a149165e7478b29b740d086c18c424 8273188: java/lang/instrument/BootClassPath/BootClassPathTest.sh fails with "FATAL ERROR in native method: processing of -javaagent failed, processJavaStart failed" Reviewed-by: dholmes, alanb ! src/java.instrument/share/native/libinstrument/EncodingSupport.h ! src/java.instrument/share/native/libinstrument/InvocationAdapter.c ! src/java.instrument/share/native/libinstrument/JPLISAgent.c ! src/java.instrument/unix/native/libinstrument/EncodingSupport_md.c ! src/java.instrument/windows/native/libinstrument/EncodingSupport_md.c ! test/jdk/ProblemList.txt ! test/jdk/java/lang/instrument/BootClassPath/BootClassPathTest.sh ! test/jdk/java/lang/instrument/BootClassPath/Setup.java Changeset: 2e321dc7 Author: Andrey Turbanov Committer: Sergey Bylokhov Date: 2021-09-09 21:47:59 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2e321dc782e0de9995b1772e4cee9c0304bc183d 8273528: Avoid ByteArrayOutputStream.toByteArray when converting stream to String Reviewed-by: bpb, xuelei, serb, aivanov ! src/java.base/share/classes/sun/security/util/BitArray.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/png/PNGImageReader.java ! src/java.desktop/share/classes/sun/awt/DebugSettings.java ! src/java.desktop/share/classes/sun/awt/datatransfer/DataTransferer.java Changeset: 08f0be83 Author: matias9927 Committer: Coleen Phillimore Date: 2021-09-10 01:05:37 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/08f0be8388914901ac40525ed995136ce020f432 8272608: java_lang_System::allow_security_manager() doesn't set its initialization flag Reviewed-by: coleenp, dholmes ! src/hotspot/share/classfile/javaClasses.cpp Changeset: 70c9e026 Author: Pankaj Bansal Date: 2021-09-10 06:13:32 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/70c9e026b63aadf9a2bfcbda45c2b9ea866afafa 8272148: JDesktopPane:getComponentCount() returns one extra than expected with GTKLookAndFeel Reviewed-by: prr, serb ! src/java.desktop/share/classes/javax/swing/JComponent.java Changeset: 792281d5 Author: Tobias Holenstein Committer: Tobias Hartmann Date: 2021-09-10 07:43:15 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/792281d559ca1f01493775fdfc2a6ed09b3b883d 8264517: C2: make MachCallNode::return_value_is_used() only available for x86 Reviewed-by: kvn, thartmann ! src/hotspot/share/opto/machnode.cpp ! src/hotspot/share/opto/machnode.hpp Changeset: 2eaf374c Author: Tobias Holenstein Committer: Tobias Hartmann Date: 2021-09-10 07:44:12 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2eaf374c5ce08287311cfac8145f97bf839365a7 8272698: LoadNode::pin is unused Reviewed-by: roland, thartmann ! src/hotspot/share/opto/memnode.hpp Changeset: c1e39faa Author: Per Liden Date: 2021-09-10 09:49:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c1e39faaa99ee62ff626ffec9f978ed0f8ffaca1 8273482: Remove "foreground work" concept from WorkGang Reviewed-by: tschatzl, kbarrett ! src/hotspot/share/gc/shared/workgroup.cpp ! src/hotspot/share/gc/shared/workgroup.hpp ! src/hotspot/share/gc/shenandoah/shenandoahCodeRoots.cpp ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.cpp ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.inline.hpp ! src/hotspot/share/services/heapDumper.cpp Changeset: 0985887f Author: duke Date: 2021-09-10 11:00:57 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0985887fa38b7a5e6a37012042e7a00b67a9f025 Automatic merge of jdk:master into master Changeset: b29641ad Author: duke Date: 2021-09-10 11:01:21 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b29641ad0d86f4494d56f79fc6b72c111764922b Automatic merge of master into foreign-memaccess+abi ! src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java From paul.sandoz at oracle.com Fri Sep 10 15:05:34 2021 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 10 Sep 2021 15:05:34 +0000 Subject: CFV: New Panama Committer: Jie Fu In-Reply-To: <45B1ED7D-7A97-4F1E-8F4F-BDD15004EF49@oracle.com> References: <45B1ED7D-7A97-4F1E-8F4F-BDD15004EF49@oracle.com> Message-ID: Vote: yes From eric.c.liu at arm.com Fri Sep 10 09:03:52 2021 From: eric.c.liu at arm.com (Eric Liu) Date: Fri, 10 Sep 2021 09:03:52 +0000 Subject: CFV: New Panama Committer: Jie Fu In-Reply-To: <45B1ED7D-7A97-4F1E-8F4F-BDD15004EF49@oracle.com> References: <45B1ED7D-7A97-4F1E-8F4F-BDD15004EF49@oracle.com> Message-ID: Vote: yes - Eric Liu -----Original Message----- From: panama-dev On Behalf Of Paul Sandoz Sent: Friday, September 10, 2021 12:47 AM To: panama-dev Subject: CFV: New Panama Committer: Jie Fu I hereby nominate Jie Fu (OpenJDK ID: jiefu, GitHub ID: DamonFool) [0] to Panama Committer. Jie has contributed many patches to the Vector API and has been really helpful battle testing the implementation, reporting issues and proposing fixies for them in panama-vector [3] and jdk [4] repositories. Votes are due by September 23rd, 2021. Only current Panama Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Paul. [0] https://openjdk.java.net/census#jiefu [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#reviewer-vote [3] https://github.com/openjdk/panama-vector/pulls?q=is%3Apr+author%3ADamonFool [4] https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3ADamonFool+%22Vector+API%22+in%3Atitle+ From jbhateja at openjdk.java.net Mon Sep 13 06:14:29 2021 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Mon, 13 Sep 2021 06:14:29 GMT Subject: [vectorIntrinsics+mask] RFR: 8273406: Optimize various masked vector operations for AVX512 target. In-Reply-To: <1oKY4bwtUvKHnUBE-bkzuy-h9DtBO--W73CBYCKtEWs=.a272d9b5-b778-4420-ac6b-6a2a6c0797c7@github.com> References: <1oKY4bwtUvKHnUBE-bkzuy-h9DtBO--W73CBYCKtEWs=.a272d9b5-b778-4420-ac6b-6a2a6c0797c7@github.com> Message-ID: On Thu, 9 Sep 2021 22:52:59 GMT, Sandhya Viswanathan wrote: >> This patch is in continuation to X86 backend support for optimizing masked operations over AVX-512 targets (JDK-8262356). >> >> Summary of changes: >> >> 1) Support for masked rotate left and right operations over integer/long vectors. >> >> 2) Support for masked square root operation over float/double vectors. >> >> 3) Support for masked logical shiftleft and logical/arithmetic shiftright operation with constant shift count. >> >> 4) Optimized VectorMask.not operation by emitting direct KNOT instruction. >> >> 5) Extended masking optimization support for X86 KNL target which has limited set of AVX-512 features. >> >> - Currently vector type associated with VectorLoadMask operation is created during parsing stage. >> For targets supporting opmask registers, lane type is explicitly set to BOOLEAN irrespective of the primitive >> type of species i.e. for Int512 species ideal type TypeVectMask(16,BOOL) represent vector of 16 BOOLEAN elements >> each of which represent a mask bit for corresponding vector lane. >> This type information is also associated with respective mask boxes (Int512Mask). >> >> - During macro expansion vbox/vunbox nodes are broken down into granular target mappable ideal nodes. >> >> ``` >> VectorBoxNode -> VectorStoreMask + StoreVector >> >> VectorUnboxNode -> LoadVector + VectorLoadMask >> ``` >> >> At this stage vector type (TypeVectMask(16,BOOL)) earlier associated with vunbox node is used to create the >> type for VectorLoadMask operation. >> >> - Masks can be propagated either though a vector (non-AVX512 targets) or using opmask registers (K1-K7). >> Decision to create correct ideal type based on the target features is delegated to low level >> type creation routine TypeVect::makemask. >> >> - This creates problem for targets like KNL which support limited set of AVX-512 features i.e. do >> no support AVX512VL and AVX512BW feature. >> >> - For Int512 species initial ideal type constructed during parsing is based on primitive type and >> lane count associated with species, but during macro expansion type creation >> decision is based on vector type associated with v[u]box nodes i.e. TypeVectoMask(16,BOOL), >> thus for KNL target incorrect vector mask type TypeVectX(16,BOOL) gets created since it does not >> support vector length extension(128,256 bit operation over EVEX encoded instruction). >> >> - There are multiple ways to fix this discrepancy, cleanest approach is to create ideal type TypeVectoMask >> based on the primitive lane type of the species, instead of always setting the lane type as BOOLEAN. >> This will also preserve the original lane type information which was needed in some cases e.g. >> reinterpretation operation over mask. To circumvent such issue explicit src/dst primitive types >> were added to ideal nodes. >> >> - Also this does not disturbs the register mask and spilling behavior associated with opmask registers >> thus the change is transparent to backend passes. >> >> Validation: >> Patch regressed through tier1-3 tests at AVX Level=0,1,2,3 and UseKNLSetting > > src/hotspot/cpu/x86/x86.ad line 1970: > >> 1968: case Op_OrVMask: >> 1969: case Op_XorVMask: >> 1970: if (vlen > 16 && !VM_Version::supports_avx512bw()) { > > Isn't there a limitation as well for vlen 8 and DQ support? That is being taken care in the instruction pattern where we pick masklength to be 16 if target does not support DQ. > src/hotspot/cpu/x86/x86.ad line 9360: > >> 9358: %} >> 9359: >> 9360: instruct mask_not_immLT8(kReg dst, kReg src, rRegI rtmp, kReg ktmp, immI_M1 cnt) %{ > > What happens to not operation if vector_length < 8 and it is a !avx512dq platform? In that case this pattern will not get matched since instruction sequence will still be same. Following two implementations are possible for targets without DQ: A) XorVMask SRC (MaskAll -1): Instruction sequence KMOV -1 SRC1 KSHIFTRL 16-masklen, SRC1 KXOR SRC1, DST B) New instruction for NOT operation. In this case following will be generated instruction sequence KNOTW SRC1 KMOV FILTER 3/15 KAND SRC FILTER Apparently there is not much difference in the two implementations. > src/hotspot/cpu/x86/x86.ad line 9375: > >> 9373: predicate((Matcher::vector_length(n) == 8 && VM_Version::supports_avx512dq()) || >> 9374: (Matcher::vector_length(n) == 16) || >> 9375: (Matcher::vector_length(n) > 16 && VM_Version::supports_avx512bw())); > > What happens to not operation if vector_length == 8 and it is a !avx512dq platform? Same as above ------------- PR: https://git.openjdk.java.net/panama-vector/pull/122 From jbhateja at openjdk.java.net Mon Sep 13 06:42:05 2021 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Mon, 13 Sep 2021 06:42:05 GMT Subject: [vectorIntrinsics+mask] RFR: 8273406: Optimize various masked vector operations for AVX512 target. [v2] In-Reply-To: References: Message-ID: > This patch is in continuation to X86 backend support for optimizing masked operations over AVX-512 targets (JDK-8262356). > > Summary of changes: > > 1) Support for masked rotate left and right operations over integer/long vectors. > > 2) Support for masked square root operation over float/double vectors. > > 3) Support for masked logical shiftleft and logical/arithmetic shiftright operation with constant shift count. > > 4) Optimized VectorMask.not operation by emitting direct KNOT instruction. > > 5) Extended masking optimization support for X86 KNL target which has limited set of AVX-512 features. > > - Currently vector type associated with VectorLoadMask operation is created during parsing stage. > For targets supporting opmask registers, lane type is explicitly set to BOOLEAN irrespective of the primitive > type of species i.e. for Int512 species ideal type TypeVectMask(16,BOOL) represent vector of 16 BOOLEAN elements > each of which represent a mask bit for corresponding vector lane. > This type information is also associated with respective mask boxes (Int512Mask). > > - During macro expansion vbox/vunbox nodes are broken down into granular target mappable ideal nodes. > > ``` > VectorBoxNode -> VectorStoreMask + StoreVector > > VectorUnboxNode -> LoadVector + VectorLoadMask > ``` > > At this stage vector type (TypeVectMask(16,BOOL)) earlier associated with vunbox node is used to create the > type for VectorLoadMask operation. > > - Masks can be propagated either though a vector (non-AVX512 targets) or using opmask registers (K1-K7). > Decision to create correct ideal type based on the target features is delegated to low level > type creation routine TypeVect::makemask. > > - This creates problem for targets like KNL which support limited set of AVX-512 features i.e. do > no support AVX512VL and AVX512BW feature. > > - For Int512 species initial ideal type constructed during parsing is based on primitive type and > lane count associated with species, but during macro expansion type creation > decision is based on vector type associated with v[u]box nodes i.e. TypeVectoMask(16,BOOL), > thus for KNL target incorrect vector mask type TypeVectX(16,BOOL) gets created since it does not > support vector length extension(128,256 bit operation over EVEX encoded instruction). > > - There are multiple ways to fix this discrepancy, cleanest approach is to create ideal type TypeVectoMask > based on the primitive lane type of the species, instead of always setting the lane type as BOOLEAN. > This will also preserve the original lane type information which was needed in some cases e.g. > reinterpretation operation over mask. To circumvent such issue explicit src/dst primitive types > were added to ideal nodes. > > - Also this does not disturbs the register mask and spilling behavior associated with opmask registers > thus the change is transparent to backend passes. > > Validation: > Patch regressed through tier1-3 tests at AVX Level=0,1,2,3 and UseKNLSetting Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: 8273406: Review comments resolution. ------------- Changes: - all: https://git.openjdk.java.net/panama-vector/pull/122/files - new: https://git.openjdk.java.net/panama-vector/pull/122/files/b3788974..ed976c7f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=122&range=01 - incr: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=122&range=00-01 Stats: 165 lines in 6 files changed: 66 ins; 5 del; 94 mod Patch: https://git.openjdk.java.net/panama-vector/pull/122.diff Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/122/head:pull/122 PR: https://git.openjdk.java.net/panama-vector/pull/122 From jbhateja at openjdk.java.net Mon Sep 13 06:42:05 2021 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Mon, 13 Sep 2021 06:42:05 GMT Subject: [vectorIntrinsics+mask] RFR: 8273406: Optimize various masked vector operations for AVX512 target. In-Reply-To: References: <6kCpmxefYaZUAbKSS65LzJwwiLMTp4IR0KKi53SSVD0=.c11e2264-6168-4204-881a-42ecb26992b9@github.com> Message-ID: <2602CJb3sXnW6FEFTB5cb16KyYF5ukjM9gqY3faP-ug=.26a9c030-0968-4c2a-a56e-fa6756a71b3e@github.com> On Wed, 8 Sep 2021 06:50:41 GMT, Jatin Bhateja wrote: >> @jatin-bhateja is [JDK-8262356](https://bugs.openjdk.java.net/browse/JDK-8262356) mostly a duplicate of the sub-task [JDK-8272359](https://bugs.openjdk.java.net/browse/JDK-8272359)? > >> @jatin-bhateja is [JDK-8262356](https://bugs.openjdk.java.net/browse/JDK-8262356) mostly a duplicate of the sub-task [JDK-8272359](https://bugs.openjdk.java.net/browse/JDK-8272359)? > > Yes, I have linked JDK-8262356 to sub-task JDK-8272359. > Also linked other related issues with JDK-8262356 > @jatin-bhateja I have completed the first pass review. I will look forward to an update. @sviswa7 , I have addressed your comments. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/122 From jbhateja at openjdk.java.net Mon Sep 13 06:42:08 2021 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Mon, 13 Sep 2021 06:42:08 GMT Subject: [vectorIntrinsics+mask] RFR: 8273406: Optimize various masked vector operations for AVX512 target. [v2] In-Reply-To: References: Message-ID: On Wed, 8 Sep 2021 23:34:33 GMT, Sandhya Viswanathan wrote: >> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: >> >> 8273406: Review comments resolution. > > src/hotspot/cpu/x86/assembler_x86.cpp line 9086: > >> 9084: } >> 9085: >> 9086: void Assembler::evpsllw(XMMRegister dst, KRegister mask, int shift, XMMRegister src, bool merge, int vector_len) { > > For all the shift and rotate instructions operand order could be dst, mask, src, shift, merge, vector_len. DONE > src/hotspot/cpu/x86/x86.ad line 8998: > >> 8996: bool is_varshift = !VectorNode::is_vshift_cnt_opcode(in(2)->isa_Mach()->ideal_Opcode()); >> 8997: __ evmasked_op(opc, bt, $mask$$KRegister, $dst$$XMMRegister, >> 8998: $dst$$XMMRegister, $src2$$XMMRegister, true, vlen_enc, is_varshift); > > x86.ad is sending is_varshift for rotates but is_varshift is not passed to evrold/evrord in evmasked_op. Its not needed, unlike vector shifts, rotate always consume shift either as an immediate value or though a vector of same shape as source vector. Removing it. > src/hotspot/share/opto/vectornode.hpp line 1397: > >> 1395: : VectorNode(in, dst_vt), _src_vt(src_vt) { >> 1396: assert((!dst_vt->isa_vectmask() && !src_vt->isa_vectmask()) || >> 1397: (type2aelembytes(src_vt->element_basic_type()) >= type2aelembytes(dst_vt->element_basic_type())), > > Why this addition limitation for vectmask only? Some comments here please. Only narrowing re-interpretation is supported if source and destinations are mask type operands i.e. If Int512Mask is reinterpreted as Byte512Mask each true bit of Int species will correspond to 4 true bits of Byte species, but reverse re-interpretation is not straight forwards, since not all 4 bits of byte species may be true and thus cannot be directly reinterpreted as 1 true mask bit for integer species. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/122 From jbhateja at openjdk.java.net Mon Sep 13 08:27:53 2021 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Mon, 13 Sep 2021 08:27:53 GMT Subject: [vectorIntrinsics+mask] RFR: 8273406: Optimize various masked vector operations for AVX512 target. [v3] In-Reply-To: References: Message-ID: > This patch is in continuation to X86 backend support for optimizing masked operations over AVX-512 targets (JDK-8262356). > > Summary of changes: > > 1) Support for masked rotate left and right operations over integer/long vectors. > > 2) Support for masked square root operation over float/double vectors. > > 3) Support for masked logical shiftleft and logical/arithmetic shiftright operation with constant shift count. > > 4) Optimized VectorMask.not operation by emitting direct KNOT instruction. > > 5) Extended masking optimization support for X86 KNL target which has limited set of AVX-512 features. > > - Currently vector type associated with VectorLoadMask operation is created during parsing stage. > For targets supporting opmask registers, lane type is explicitly set to BOOLEAN irrespective of the primitive > type of species i.e. for Int512 species ideal type TypeVectMask(16,BOOL) represent vector of 16 BOOLEAN elements > each of which represent a mask bit for corresponding vector lane. > This type information is also associated with respective mask boxes (Int512Mask). > > - During macro expansion vbox/vunbox nodes are broken down into granular target mappable ideal nodes. > > ``` > VectorBoxNode -> VectorStoreMask + StoreVector > > VectorUnboxNode -> LoadVector + VectorLoadMask > ``` > > At this stage vector type (TypeVectMask(16,BOOL)) earlier associated with vunbox node is used to create the > type for VectorLoadMask operation. > > - Masks can be propagated either though a vector (non-AVX512 targets) or using opmask registers (K1-K7). > Decision to create correct ideal type based on the target features is delegated to low level > type creation routine TypeVect::makemask. > > - This creates problem for targets like KNL which support limited set of AVX-512 features i.e. do > no support AVX512VL and AVX512BW feature. > > - For Int512 species initial ideal type constructed during parsing is based on primitive type and > lane count associated with species, but during macro expansion type creation > decision is based on vector type associated with v[u]box nodes i.e. TypeVectoMask(16,BOOL), > thus for KNL target incorrect vector mask type TypeVectX(16,BOOL) gets created since it does not > support vector length extension(128,256 bit operation over EVEX encoded instruction). > > - There are multiple ways to fix this discrepancy, cleanest approach is to create ideal type TypeVectoMask > based on the primitive lane type of the species, instead of always setting the lane type as BOOLEAN. > This will also preserve the original lane type information which was needed in some cases e.g. > reinterpretation operation over mask. To circumvent such issue explicit src/dst primitive types > were added to ideal nodes. > > - Also this does not disturbs the register mask and spilling behavior associated with opmask registers > thus the change is transparent to backend passes. > > Validation: > Patch regressed through tier1-3 tests at AVX Level=0,1,2,3 and UseKNLSetting Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: 8273406: Removing duplicate case statement added in previous commit. ------------- Changes: - all: https://git.openjdk.java.net/panama-vector/pull/122/files - new: https://git.openjdk.java.net/panama-vector/pull/122/files/ed976c7f..f497b51c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=122&range=02 - incr: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=122&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.java.net/panama-vector/pull/122.diff Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/122/head:pull/122 PR: https://git.openjdk.java.net/panama-vector/pull/122 From eliu at openjdk.java.net Mon Sep 13 10:56:06 2021 From: eliu at openjdk.java.net (Eric Liu) Date: Mon, 13 Sep 2021 10:56:06 GMT Subject: [vectorIntrinsics+mask] RFR: 8273264: AArch64: [vector] Add missing rules for VectorMaskCast Message-ID: This patch 1. Adds missing rules for VectorMaskCast for compatible species, E.g. ByteVector.SPECIES_64 --> ShortVector.SPECIES_128 2. Fixes a matching failure on AArch64. The performance improves about 60% compared with the unintrinsified version. ------------- Commit messages: - 8273264: AArch64: [vector] Add missing rules for VectorMaskCast Changes: https://git.openjdk.java.net/panama-vector/pull/124/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=124&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273264 Stats: 693 lines in 9 files changed: 625 ins; 0 del; 68 mod Patch: https://git.openjdk.java.net/panama-vector/pull/124.diff Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/124/head:pull/124 PR: https://git.openjdk.java.net/panama-vector/pull/124 From psandoz at openjdk.java.net Mon Sep 13 15:33:42 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Mon, 13 Sep 2021 15:33:42 GMT Subject: [vectorIntrinsics+mask] RFR: 8273264: AArch64: [vector] Add missing rules for VectorMaskCast In-Reply-To: References: Message-ID: On Mon, 13 Sep 2021 10:48:40 GMT, Eric Liu wrote: > This patch > 1. Adds missing rules for VectorMaskCast for compatible species, E.g. > ByteVector.SPECIES_64 --> ShortVector.SPECIES_128 > 2. Fixes a matching failure on AArch64. > > The performance improves about 60% compared with the unintrinsified > version. test/hotspot/jtreg/compiler/vectorapi/VectorMaskCastTest.java line 52: > 50: > 51: > 52: public class VectorMaskCastTest{ Do we need to add such a test? We already have conversions tests, see sub-classes of `AbstractVectorConversionTest`. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/124 From sviswanathan at openjdk.java.net Mon Sep 13 18:42:09 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Mon, 13 Sep 2021 18:42:09 GMT Subject: [vectorIntrinsics+mask] RFR: 8273406: Optimize various masked vector operations for AVX512 target. [v3] In-Reply-To: References: Message-ID: On Mon, 13 Sep 2021 08:27:53 GMT, Jatin Bhateja wrote: >> This patch is in continuation to X86 backend support for optimizing masked operations over AVX-512 targets (JDK-8262356). >> >> Summary of changes: >> >> 1) Support for masked rotate left and right operations over integer/long vectors. >> >> 2) Support for masked square root operation over float/double vectors. >> >> 3) Support for masked logical shiftleft and logical/arithmetic shiftright operation with constant shift count. >> >> 4) Optimized VectorMask.not operation by emitting direct KNOT instruction. >> >> 5) Extended masking optimization support for X86 KNL target which has limited set of AVX-512 features. >> >> - Currently vector type associated with VectorLoadMask operation is created during parsing stage. >> For targets supporting opmask registers, lane type is explicitly set to BOOLEAN irrespective of the primitive >> type of species i.e. for Int512 species ideal type TypeVectMask(16,BOOL) represent vector of 16 BOOLEAN elements >> each of which represent a mask bit for corresponding vector lane. >> This type information is also associated with respective mask boxes (Int512Mask). >> >> - During macro expansion vbox/vunbox nodes are broken down into granular target mappable ideal nodes. >> >> ``` >> VectorBoxNode -> VectorStoreMask + StoreVector >> >> VectorUnboxNode -> LoadVector + VectorLoadMask >> ``` >> >> At this stage vector type (TypeVectMask(16,BOOL)) earlier associated with vunbox node is used to create the >> type for VectorLoadMask operation. >> >> - Masks can be propagated either though a vector (non-AVX512 targets) or using opmask registers (K1-K7). >> Decision to create correct ideal type based on the target features is delegated to low level >> type creation routine TypeVect::makemask. >> >> - This creates problem for targets like KNL which support limited set of AVX-512 features i.e. do >> no support AVX512VL and AVX512BW feature. >> >> - For Int512 species initial ideal type constructed during parsing is based on primitive type and >> lane count associated with species, but during macro expansion type creation >> decision is based on vector type associated with v[u]box nodes i.e. TypeVectoMask(16,BOOL), >> thus for KNL target incorrect vector mask type TypeVectX(16,BOOL) gets created since it does not >> support vector length extension(128,256 bit operation over EVEX encoded instruction). >> >> - There are multiple ways to fix this discrepancy, cleanest approach is to create ideal type TypeVectoMask >> based on the primitive lane type of the species, instead of always setting the lane type as BOOLEAN. >> This will also preserve the original lane type information which was needed in some cases e.g. >> reinterpretation operation over mask. To circumvent such issue explicit src/dst primitive types >> were added to ideal nodes. >> >> - Also this does not disturbs the register mask and spilling behavior associated with opmask registers >> thus the change is transparent to backend passes. >> >> Validation: >> Patch regressed through tier1-3 tests at AVX Level=0,1,2,3 and UseKNLSetting > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > 8273406: Removing duplicate case statement added in previous commit. Marked as reviewed by sviswanathan (Committer). The patch looks good to me. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/122 From sandhya.viswanathan at intel.com Mon Sep 13 20:11:58 2021 From: sandhya.viswanathan at intel.com (Viswanathan, Sandhya) Date: Mon, 13 Sep 2021 20:11:58 +0000 Subject: CFV: New Panama Committer: Jie Fu In-Reply-To: <45B1ED7D-7A97-4F1E-8F4F-BDD15004EF49@oracle.com> References: <45B1ED7D-7A97-4F1E-8F4F-BDD15004EF49@oracle.com> Message-ID: Vote: yes Best Regards, Sandhya -----Original Message----- From: panama-dev On Behalf Of Paul Sandoz Sent: Thursday, September 09, 2021 9:47 AM To: panama-dev Subject: CFV: New Panama Committer: Jie Fu I hereby nominate Jie Fu (OpenJDK ID: jiefu, GitHub ID: DamonFool) [0] to Panama Committer. Jie has contributed many patches to the Vector API and has been really helpful battle testing the implementation, reporting issues and proposing fixies for them in panama-vector [3] and jdk [4] repositories. Votes are due by September 23rd, 2021. Only current Panama Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Paul. [0] https://openjdk.java.net/census#jiefu [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#reviewer-vote [3] https://github.com/openjdk/panama-vector/pulls?q=is%3Apr+author%3ADamonFool [4] https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3ADamonFool+%22Vector+API%22+in%3Atitle+ From jbhateja at openjdk.java.net Tue Sep 14 04:58:41 2021 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Tue, 14 Sep 2021 04:58:41 GMT Subject: [vectorIntrinsics+mask] RFR: 8273406: Optimize various masked vector operations for AVX512 target. [v3] In-Reply-To: References: Message-ID: On Mon, 13 Sep 2021 18:38:31 GMT, Sandhya Viswanathan wrote: > The patch looks good to me. Thanks @sviswa7 ------------- PR: https://git.openjdk.java.net/panama-vector/pull/122 From jbhateja at openjdk.java.net Tue Sep 14 05:00:29 2021 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Tue, 14 Sep 2021 05:00:29 GMT Subject: git: openjdk/panama-vector: vectorIntrinsics+mask: 8273406: Optimize various masked vector operations for AVX512 target. Message-ID: <069f7008-d20a-485e-8a8e-b9490f563c3e@openjdk.org> Changeset: ce330956 Author: Jatin Bhateja Date: 2021-09-14 04:59:46 +0000 URL: https://git.openjdk.java.net/panama-vector/commit/ce330956ee226efd263306ed6beba3c722e375f5 8273406: Optimize various masked vector operations for AVX512 target. Reviewed-by: sviswanathan ! src/hotspot/cpu/x86/assembler_x86.cpp ! src/hotspot/cpu/x86/assembler_x86.hpp ! src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp ! src/hotspot/cpu/x86/c2_MacroAssembler_x86.hpp ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.hpp ! src/hotspot/cpu/x86/stubGenerator_x86_32.cpp ! src/hotspot/cpu/x86/stubGenerator_x86_64.cpp ! src/hotspot/cpu/x86/stubRoutines_x86.cpp ! src/hotspot/cpu/x86/stubRoutines_x86.hpp ! src/hotspot/cpu/x86/x86.ad ! src/hotspot/share/opto/type.cpp ! src/hotspot/share/opto/vectorIntrinsics.cpp ! src/hotspot/share/opto/vectornode.hpp From jbhateja at openjdk.java.net Tue Sep 14 05:03:21 2021 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Tue, 14 Sep 2021 05:03:21 GMT Subject: [vectorIntrinsics+mask] Integrated: 8273406: Optimize various masked vector operations for AVX512 target. In-Reply-To: References: Message-ID: On Tue, 7 Sep 2021 14:53:25 GMT, Jatin Bhateja wrote: > This patch is in continuation to X86 backend support for optimizing masked operations over AVX-512 targets (JDK-8262356). > > Summary of changes: > > 1) Support for masked rotate left and right operations over integer/long vectors. > > 2) Support for masked square root operation over float/double vectors. > > 3) Support for masked logical shiftleft and logical/arithmetic shiftright operation with constant shift count. > > 4) Optimized VectorMask.not operation by emitting direct KNOT instruction. > > 5) Extended masking optimization support for X86 KNL target which has limited set of AVX-512 features. > > - Currently vector type associated with VectorLoadMask operation is created during parsing stage. > For targets supporting opmask registers, lane type is explicitly set to BOOLEAN irrespective of the primitive > type of species i.e. for Int512 species ideal type TypeVectMask(16,BOOL) represent vector of 16 BOOLEAN elements > each of which represent a mask bit for corresponding vector lane. > This type information is also associated with respective mask boxes (Int512Mask). > > - During macro expansion vbox/vunbox nodes are broken down into granular target mappable ideal nodes. > > ``` > VectorBoxNode -> VectorStoreMask + StoreVector > > VectorUnboxNode -> LoadVector + VectorLoadMask > ``` > > At this stage vector type (TypeVectMask(16,BOOL)) earlier associated with vunbox node is used to create the > type for VectorLoadMask operation. > > - Masks can be propagated either though a vector (non-AVX512 targets) or using opmask registers (K1-K7). > Decision to create correct ideal type based on the target features is delegated to low level > type creation routine TypeVect::makemask. > > - This creates problem for targets like KNL which support limited set of AVX-512 features i.e. do > no support AVX512VL and AVX512BW feature. > > - For Int512 species initial ideal type constructed during parsing is based on primitive type and > lane count associated with species, but during macro expansion type creation > decision is based on vector type associated with v[u]box nodes i.e. TypeVectoMask(16,BOOL), > thus for KNL target incorrect vector mask type TypeVectX(16,BOOL) gets created since it does not > support vector length extension(128,256 bit operation over EVEX encoded instruction). > > - There are multiple ways to fix this discrepancy, cleanest approach is to create ideal type TypeVectoMask > based on the primitive lane type of the species, instead of always setting the lane type as BOOLEAN. > This will also preserve the original lane type information which was needed in some cases e.g. > reinterpretation operation over mask. To circumvent such issue explicit src/dst primitive types > were added to ideal nodes. > > - Also this does not disturbs the register mask and spilling behavior associated with opmask registers > thus the change is transparent to backend passes. > > Validation: > Patch regressed through tier1-3 tests at AVX Level=0,1,2,3 and UseKNLSetting This pull request has now been integrated. Changeset: ce330956 Author: Jatin Bhateja URL: https://git.openjdk.java.net/panama-vector/commit/ce330956ee226efd263306ed6beba3c722e375f5 Stats: 837 lines in 14 files changed: 727 ins; 28 del; 82 mod 8273406: Optimize various masked vector operations for AVX512 target. Reviewed-by: sviswanathan ------------- PR: https://git.openjdk.java.net/panama-vector/pull/122 From eliu at openjdk.java.net Tue Sep 14 10:34:32 2021 From: eliu at openjdk.java.net (Eric Liu) Date: Tue, 14 Sep 2021 10:34:32 GMT Subject: [vectorIntrinsics+mask] RFR: 8273264: AArch64: [vector] Add missing rules for VectorMaskCast [v2] In-Reply-To: References: Message-ID: > This patch > 1. Adds missing rules for VectorMaskCast for compatible species, E.g. > ByteVector.SPECIES_64 --> ShortVector.SPECIES_128 > 2. Fixes a matching failure on AArch64. > > The performance improves about 60% compared with the unintrinsified > version. Eric Liu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - small fix Change-Id: I4f5b75c498a3daadf9938e64be5021c43068af67 - Merge remote-tracking branch 'upstream/vectorIntrinsics+mask' into masked-cast Change-Id: I5f9e0f627090bb914d496b757091461dbd6a7f72 - 8273264: AArch64: [vector] Add missing rules for VectorMaskCast This patch 1. Adds missing rules for VectorMaskCast for compatible species, E.g. ByteVector.SPECIES_64 --> ShortVector.SPECIES_128 2. Fixes a matching failure on AArch64. The performance improves about 60% compared with the unintrinsified version. Change-Id: I1bcfc5a09b93c5f4625f39bd3b6a146154f69ad7 ------------- Changes: - all: https://git.openjdk.java.net/panama-vector/pull/124/files - new: https://git.openjdk.java.net/panama-vector/pull/124/files/9e3ef6bd..84761ce0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=124&range=01 - incr: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=124&range=00-01 Stats: 845 lines in 16 files changed: 731 ins; 29 del; 85 mod Patch: https://git.openjdk.java.net/panama-vector/pull/124.diff Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/124/head:pull/124 PR: https://git.openjdk.java.net/panama-vector/pull/124 From eliu at openjdk.java.net Tue Sep 14 11:01:36 2021 From: eliu at openjdk.java.net (Eric Liu) Date: Tue, 14 Sep 2021 11:01:36 GMT Subject: [vectorIntrinsics+mask] RFR: 8273264: AArch64: [vector] Add missing rules for VectorMaskCast [v2] In-Reply-To: References: Message-ID: <3GwCgL--SIHHN4_211f64yEHRoj9qYkWR0DJwPOpIAw=.5a48caf3-f888-43d7-bb55-f962ae2ac179@github.com> On Mon, 13 Sep 2021 15:31:29 GMT, Paul Sandoz wrote: >> Eric Liu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - small fix >> >> Change-Id: I4f5b75c498a3daadf9938e64be5021c43068af67 >> - Merge remote-tracking branch 'upstream/vectorIntrinsics+mask' into masked-cast >> >> Change-Id: I5f9e0f627090bb914d496b757091461dbd6a7f72 >> - 8273264: AArch64: [vector] Add missing rules for VectorMaskCast >> >> This patch >> 1. Adds missing rules for VectorMaskCast for compatible species, E.g. >> ByteVector.SPECIES_64 --> ShortVector.SPECIES_128 >> 2. Fixes a matching failure on AArch64. >> >> The performance improves about 60% compared with the unintrinsified >> version. >> >> Change-Id: I1bcfc5a09b93c5f4625f39bd3b6a146154f69ad7 > > test/hotspot/jtreg/compiler/vectorapi/VectorMaskCastTest.java line 52: > >> 50: >> 51: >> 52: public class VectorMaskCastTest{ > > Do we need to add such a test? We already have conversions tests, see sub-classes of `AbstractVectorConversionTest`. I tested with those conversion tests before, but the method could not be intrinsified. I checked generated code and the new test cases could work. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/124 From psandoz at openjdk.java.net Tue Sep 14 15:10:43 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Tue, 14 Sep 2021 15:10:43 GMT Subject: [vectorIntrinsics+mask] RFR: 8273264: AArch64: [vector] Add missing rules for VectorMaskCast [v2] In-Reply-To: <3GwCgL--SIHHN4_211f64yEHRoj9qYkWR0DJwPOpIAw=.5a48caf3-f888-43d7-bb55-f962ae2ac179@github.com> References: <3GwCgL--SIHHN4_211f64yEHRoj9qYkWR0DJwPOpIAw=.5a48caf3-f888-43d7-bb55-f962ae2ac179@github.com> Message-ID: On Tue, 14 Sep 2021 10:58:07 GMT, Eric Liu wrote: >> test/hotspot/jtreg/compiler/vectorapi/VectorMaskCastTest.java line 52: >> >>> 50: >>> 51: >>> 52: public class VectorMaskCastTest{ >> >> Do we need to add such a test? We already have conversions tests, see sub-classes of `AbstractVectorConversionTest`. > > I tested with those conversion tests before, but the method could not be intrinsified. I checked generated code and the new test cases could work. Do you have any indicates as to why? Is it because the invocation count is too low? ------------- PR: https://git.openjdk.java.net/panama-vector/pull/124 From jbhateja at openjdk.java.net Tue Sep 14 17:45:59 2021 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Tue, 14 Sep 2021 17:45:59 GMT Subject: [vectorIntrinsics+mask] RFR: 8273322: Enhance macro logic optimization for masked logic operations. Message-ID: Patch extends existing macrologic inferencing algorithm to handle masked logic operations. Existing algorithm: 1) Identify logic cone roots. 2) Packs parent and logic child nodes into a MacroLogic node in bottom up traversal if input constraint are met. i.e. maximum number of inputs which a macro logic node can have. 3) Perform symbolic evaluation of logic expression tree by assigning value corresponding to a truth table column to each input. 4) Inputs along with encoded function together represents a macro logic node which mimics a truth table. Modification: Extended the packing algorithm to operate on both predicated or non-predicated logic nodes. Following rules define the criteria under which nodes gets packed into a macro logic node:- 1) Parent and both child nodes are all unmasked or masked with same predicates. 2) Masked parent can be packed with left child if it is predicated and both have same prediates. 3) Masked parent can be packed with right child if its un-predicated or has matching predication condition. 4) An unmasked parent can be packed with an unmasked child. New jtreg test case added with the patch exhaustively covers all the different combinations of predications of parent and child nodes. Following are the performance number for JMH benchmark included with the patch. Machine Configuration: Intel(R) Xeon(R) Platinum 8280 CPU @ 2.70GHz (Cascadelake Server 28C 2S) Benchmark | SPECIES | VECLEN | Baseline Score (ops/ms) | With Opt Score (ops/ms) | Gain Ratio -- | -- | -- | -- | -- | -- MaskedLogicOpts.bitwiseBlendOperationInt | 128 | 256 | 594.425 | 616.74 | 1.03754048 MaskedLogicOpts.bitwiseBlendOperationInt | 128 | 512 | 596.433 | 616.405 | 1.033485739 MaskedLogicOpts.bitwiseBlendOperationInt | 128 | 1024 | 586.716 | 618.718 | 1.054544277 MaskedLogicOpts.bitwiseBlendOperationInt | 128 | 2048 | 594.68 | 618.235 | 1.039609538 MaskedLogicOpts.bitwiseBlendOperationInt | 128 | 4096 | 595.357 | 617.803 | 1.037701749 MaskedLogicOpts.bitwiseBlendOperationInt | 256 | 256 | 503.396 | 602.252 | 1.196378199 MaskedLogicOpts.bitwiseBlendOperationInt | 256 | 512 | 529.454 | 572.485 | 1.081274294 MaskedLogicOpts.bitwiseBlendOperationInt | 256 | 1024 | 560.688 | 587.143 | 1.047183104 MaskedLogicOpts.bitwiseBlendOperationInt | 256 | 2048 | 539.919 | 586.473 | 1.086224045 MaskedLogicOpts.bitwiseBlendOperationInt | 256 | 4096 | 542.102 | 586.694 | 1.082257583 MaskedLogicOpts.bitwiseBlendOperationInt | 512 | 256 | 401.552 | 474.281 | 1.181119755 MaskedLogicOpts.bitwiseBlendOperationInt | 512 | 512 | 371.352 | 520.497 | 1.401627028 MaskedLogicOpts.bitwiseBlendOperationInt | 512 | 1024 | 403.174 | 514.51 | 1.27614876 MaskedLogicOpts.bitwiseBlendOperationInt | 512 | 2048 | 386.124 | 511.22 | 1.323978825 MaskedLogicOpts.maskedLogicOperationsInt | 512 | 256 | 316.054 | 654.797 | 2.071788365 MaskedLogicOpts.maskedLogicOperationsInt | 512 | 512 | 312.912 | 600.227 | 1.918197448 MaskedLogicOpts.maskedLogicOperationsInt | 512 | 1024 | 305.86 | 614.129 | 2.007876152 MaskedLogicOpts.maskedLogicOperationsInt | 512 | 2048 | 306.589 | 617.645 | 2.014569994 MaskedLogicOpts.maskedLogicOperationsInt | 512 | 4096 | 314.896 | 619.618 | 1.96769092 MaskedLogicOpts.maskedLogicOperationsLong | 128 | 256 | 12.32 | 17.629 | 1.430925325 MaskedLogicOpts.maskedLogicOperationsLong | 128 | 512 | 12.296 | 17.632 | 1.433962264 MaskedLogicOpts.maskedLogicOperationsLong | 128 | 1024 | 12.027 | 17.663 | 1.468612289 MaskedLogicOpts.maskedLogicOperationsLong | 128 | 2048 | 12.33 | 17.601 | 1.427493917 MaskedLogicOpts.maskedLogicOperationsLong | 128 | 4096 | 12.329 | 17.65 | 1.43158407 MaskedLogicOpts.maskedLogicOperationsLong | 256 | 256 | 413.078 | 1184.616 | 2.867777998 MaskedLogicOpts.maskedLogicOperationsLong | 256 | 512 | 431.578 | 1069.109 | 2.477209218 MaskedLogicOpts.maskedLogicOperationsLong | 256 | 1024 | 430.099 | 1089.835 | 2.53391661 MaskedLogicOpts.maskedLogicOperationsLong | 256 | 2048 | 420.341 | 1204.934 | 2.8665631 MaskedLogicOpts.maskedLogicOperationsLong | 256 | 4096 | 431.571 | 1069.704 | 2.478628082 MaskedLogicOpts.maskedLogicOperationsLong | 512 | 256 | 311.43 | 599.982 | 1.926538869 MaskedLogicOpts.maskedLogicOperationsLong | 512 | 512 | 305.459 | 620.418 | 2.031100737 MaskedLogicOpts.maskedLogicOperationsLong | 512 | 1024 | 304.885 | 611.37 | 2.00524788 MaskedLogicOpts.maskedLogicOperationsLong | 512 | 2048 | 305.198 | 619.347 | 2.029328501 MaskedLogicOpts.maskedLogicOperationsLong | 512 | 4096 | 305.317 | 615.882 | 2.017188692 MaskedLogicOpts.partiallyMaskedLogicOperationsInt | 128 | 256 | 781.922 | 856.605 | 1.095512084 MaskedLogicOpts.partiallyMaskedLogicOperationsInt | 128 | 512 | 752.428 | 856.559 | 1.138393308 MaskedLogicOpts.partiallyMaskedLogicOperationsInt | 128 | 1024 | 764.4 | 837.68 | 1.095866039 MaskedLogicOpts.partiallyMaskedLogicOperationsInt | 128 | 2048 | 780.311 | 857.797 | 1.099301432 MaskedLogicOpts.partiallyMaskedLogicOperationsInt | 128 | 4096 | 780.489 | 837.536 | 1.073091357 MaskedLogicOpts.partiallyMaskedLogicOperationsInt | 256 | 256 | 703.881 | 820.539 | 1.165735401 MaskedLogicOpts.partiallyMaskedLogicOperationsInt | 256 | 512 | 698.958 | 822.174 | 1.17628527 MaskedLogicOpts.partiallyMaskedLogicOperationsInt | 256 | 1024 | 715.533 | 806.71 | 1.12742529 MaskedLogicOpts.partiallyMaskedLogicOperationsInt | 256 | 2048 | 678.087 | 797.53 | 1.176147014 MaskedLogicOpts.partiallyMaskedLogicOperationsInt | 256 | 4096 | 714.427 | 824.008 | 1.153383061 MaskedLogicOpts.partiallyMaskedLogicOperationsInt | 512 | 256 | 400.801 | 547.414 | 1.365799986 MaskedLogicOpts.partiallyMaskedLogicOperationsInt | 512 | 512 | 453.713 | 602.492 | 1.327914342 MaskedLogicOpts.partiallyMaskedLogicOperationsInt | 512 | 1024 | 467.685 | 612.172 | 1.308940847 MaskedLogicOpts.partiallyMaskedLogicOperationsInt | 512 | 2048 | 467.286 | 612.659 | 1.311100696 MaskedLogicOpts.partiallyMaskedLogicOperationsInt | 512 | 4096 | 465.71 | 671.911 | 1.442766958 MaskedLogicOpts.partiallyMaskedLogicOperationsLong | 128 | 256 | 18.25 | 24.524 | 1.343780822 MaskedLogicOpts.partiallyMaskedLogicOperationsLong | 128 | 512 | 18.634 | 24.408 | 1.30986369 MaskedLogicOpts.partiallyMaskedLogicOperationsLong | 128 | 1024 | 18.566 | 24.839 | 1.337875687 MaskedLogicOpts.partiallyMaskedLogicOperationsLong | 128 | 2048 | 18.568 | 24.65 | 1.327552779 MaskedLogicOpts.partiallyMaskedLogicOperationsLong | 128 | 4096 | 18.685 | 24.448 | 1.308429221 MaskedLogicOpts.partiallyMaskedLogicOperationsLong | 256 | 256 | 658.381 | 788.086 | 1.197005989 MaskedLogicOpts.partiallyMaskedLogicOperationsLong | 256 | 512 | 679.09 | 780.808 | 1.149785743 MaskedLogicOpts.partiallyMaskedLogicOperationsLong | 256 | 1024 | 675.793 | 783.304 | 1.159088656 MaskedLogicOpts.partiallyMaskedLogicOperationsLong | 256 | 2048 | 679.09 | 823.756 | 1.213029201 MaskedLogicOpts.partiallyMaskedLogicOperationsLong | 256 | 4096 | 677.724 | 782.655 | 1.154828514 MaskedLogicOpts.partiallyMaskedLogicOperationsLong | 512 | 256 | 456.231 | 620.547 | 1.360159656 MaskedLogicOpts.partiallyMaskedLogicOperationsLong | 512 | 512 | 468.07 | 604.75 | 1.292007606 MaskedLogicOpts.partiallyMaskedLogicOperationsLong | 512 | 1024 | 467.188 | 605.256 | 1.295529851 MaskedLogicOpts.partiallyMaskedLogicOperationsLong | 512 | 2048 | 468.52 | 605.854 | 1.293123026 MaskedLogicOpts.partiallyMaskedLogicOperationsLong | 512 | 4096 | 467.954 | 605.996 | 1.294990533 ------------- Commit messages: - 8273322: Enhance macro logic optimization for masked logic operations. Changes: https://git.openjdk.java.net/panama-vector/pull/125/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=125&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273322 Stats: 943 lines in 9 files changed: 904 ins; 6 del; 33 mod Patch: https://git.openjdk.java.net/panama-vector/pull/125.diff Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/125/head:pull/125 PR: https://git.openjdk.java.net/panama-vector/pull/125 From eliu at openjdk.java.net Wed Sep 15 07:15:18 2021 From: eliu at openjdk.java.net (Eric Liu) Date: Wed, 15 Sep 2021 07:15:18 GMT Subject: [vectorIntrinsics+mask] RFR: 8273264: AArch64: [vector] Add missing rules for VectorMaskCast [v2] In-Reply-To: References: <3GwCgL--SIHHN4_211f64yEHRoj9qYkWR0DJwPOpIAw=.5a48caf3-f888-43d7-bb55-f962ae2ac179@github.com> Message-ID: On Tue, 14 Sep 2021 15:07:09 GMT, Paul Sandoz wrote: >> I tested with those conversion tests before, but the method could not be intrinsified. I checked generated code and the new test cases could work. > > Do you have any indicates as to why? Is it because the invocation count is too low? The reason maybe the same as https://bugs.openjdk.java.net/browse/JDK-8259610, but I didn't pay too much time in the details. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/124 From eliu at openjdk.java.net Wed Sep 15 08:59:56 2021 From: eliu at openjdk.java.net (Eric Liu) Date: Wed, 15 Sep 2021 08:59:56 GMT Subject: [vectorIntrinsics+mask] RFR: 8273322: Enhance macro logic optimization for masked logic operations. In-Reply-To: References: Message-ID: <8fYWaLKE9Ke1sVXMURFpynYIQyxS5ZelaI8G1U7MBpo=.736f6a93-f0a3-444d-9f06-e6a403022128@github.com> On Tue, 14 Sep 2021 16:06:14 GMT, Jatin Bhateja wrote: > Patch extends existing macrologic inferencing algorithm to handle masked logic operations. > > Existing algorithm: > 1) Identify logic cone roots. > 2) Packs parent and logic child nodes into a MacroLogic node in bottom up traversal if input constraint are met. > i.e. maximum number of inputs which a macro logic node can have. > 3) Perform symbolic evaluation of logic expression tree by assigning value corresponding to a truth table column > to each input. > 4) Inputs along with encoded function together represents a macro logic node which mimics a truth table. > > Modification: > Extended the packing algorithm to operate on both predicated or non-predicated logic nodes. Following > rules define the criteria under which nodes gets packed into a macro logic node:- > 1) Parent and both child nodes are all unmasked or masked with same predicates. > 2) Masked parent can be packed with left child if it is predicated and both have same prediates. > 3) Masked parent can be packed with right child if its un-predicated or has matching predication condition. > 4) An unmasked parent can be packed with an unmasked child. > > New jtreg test case added with the patch exhaustively covers all the different combinations of predications of parent and > child nodes. > > Following are the performance number for JMH benchmark included with the patch. > > Machine Configuration: Intel(R) Xeon(R) Platinum 8280 CPU @ 2.70GHz (Cascadelake Server 28C 2S) > > > Benchmark | SPECIES | VECLEN | Baseline Score (ops/ms) | With Opt Score (ops/ms) | Gain Ratio > -- | -- | -- | -- | -- | -- > MaskedLogicOpts.bitwiseBlendOperationInt | 128 | 256 | 594.425 | 616.74 | 1.03754048 > MaskedLogicOpts.bitwiseBlendOperationInt | 128 | 512 | 596.433 | 616.405 | 1.033485739 > MaskedLogicOpts.bitwiseBlendOperationInt | 128 | 1024 | 586.716 | 618.718 | 1.054544277 > MaskedLogicOpts.bitwiseBlendOperationInt | 128 | 2048 | 594.68 | 618.235 | 1.039609538 > MaskedLogicOpts.bitwiseBlendOperationInt | 128 | 4096 | 595.357 | 617.803 | 1.037701749 > MaskedLogicOpts.bitwiseBlendOperationInt | 256 | 256 | 503.396 | 602.252 | 1.196378199 > MaskedLogicOpts.bitwiseBlendOperationInt | 256 | 512 | 529.454 | 572.485 | 1.081274294 > MaskedLogicOpts.bitwiseBlendOperationInt | 256 | 1024 | 560.688 | 587.143 | 1.047183104 > MaskedLogicOpts.bitwiseBlendOperationInt | 256 | 2048 | 539.919 | 586.473 | 1.086224045 > MaskedLogicOpts.bitwiseBlendOperationInt | 256 | 4096 | 542.102 | 586.694 | 1.082257583 > MaskedLogicOpts.bitwiseBlendOperationInt | 512 | 256 | 401.552 | 474.281 | 1.181119755 > MaskedLogicOpts.bitwiseBlendOperationInt | 512 | 512 | 371.352 | 520.497 | 1.401627028 > MaskedLogicOpts.bitwiseBlendOperationInt | 512 | 1024 | 403.174 | 514.51 | 1.27614876 > MaskedLogicOpts.bitwiseBlendOperationInt | 512 | 2048 | 386.124 | 511.22 | 1.323978825 > MaskedLogicOpts.maskedLogicOperationsInt | 512 | 256 | 316.054 | 654.797 | 2.071788365 > MaskedLogicOpts.maskedLogicOperationsInt | 512 | 512 | 312.912 | 600.227 | 1.918197448 > MaskedLogicOpts.maskedLogicOperationsInt | 512 | 1024 | 305.86 | 614.129 | 2.007876152 > MaskedLogicOpts.maskedLogicOperationsInt | 512 | 2048 | 306.589 | 617.645 | 2.014569994 > MaskedLogicOpts.maskedLogicOperationsInt | 512 | 4096 | 314.896 | 619.618 | 1.96769092 > MaskedLogicOpts.maskedLogicOperationsLong | 128 | 256 | 12.32 | 17.629 | 1.430925325 > MaskedLogicOpts.maskedLogicOperationsLong | 128 | 512 | 12.296 | 17.632 | 1.433962264 > MaskedLogicOpts.maskedLogicOperationsLong | 128 | 1024 | 12.027 | 17.663 | 1.468612289 > MaskedLogicOpts.maskedLogicOperationsLong | 128 | 2048 | 12.33 | 17.601 | 1.427493917 > MaskedLogicOpts.maskedLogicOperationsLong | 128 | 4096 | 12.329 | 17.65 | 1.43158407 > MaskedLogicOpts.maskedLogicOperationsLong | 256 | 256 | 413.078 | 1184.616 | 2.867777998 > MaskedLogicOpts.maskedLogicOperationsLong | 256 | 512 | 431.578 | 1069.109 | 2.477209218 > MaskedLogicOpts.maskedLogicOperationsLong | 256 | 1024 | 430.099 | 1089.835 | 2.53391661 > MaskedLogicOpts.maskedLogicOperationsLong | 256 | 2048 | 420.341 | 1204.934 | 2.8665631 > MaskedLogicOpts.maskedLogicOperationsLong | 256 | 4096 | 431.571 | 1069.704 | 2.478628082 > MaskedLogicOpts.maskedLogicOperationsLong | 512 | 256 | 311.43 | 599.982 | 1.926538869 > MaskedLogicOpts.maskedLogicOperationsLong | 512 | 512 | 305.459 | 620.418 | 2.031100737 > MaskedLogicOpts.maskedLogicOperationsLong | 512 | 1024 | 304.885 | 611.37 | 2.00524788 > MaskedLogicOpts.maskedLogicOperationsLong | 512 | 2048 | 305.198 | 619.347 | 2.029328501 > MaskedLogicOpts.maskedLogicOperationsLong | 512 | 4096 | 305.317 | 615.882 | 2.017188692 > MaskedLogicOpts.partiallyMaskedLogicOperationsInt | 128 | 256 | 781.922 | 856.605 | 1.095512084 > MaskedLogicOpts.partiallyMaskedLogicOperationsInt | 128 | 512 | 752.428 | 856.559 | 1.138393308 > MaskedLogicOpts.partiallyMaskedLogicOperationsInt | 128 | 1024 | 764.4 | 837.68 | 1.095866039 > MaskedLogicOpts.partiallyMaskedLogicOperationsInt | 128 | 2048 | 780.311 | 857.797 | 1.099301432 > MaskedLogicOpts.partiallyMaskedLogicOperationsInt | 128 | 4096 | 780.489 | 837.536 | 1.073091357 > MaskedLogicOpts.partiallyMaskedLogicOperationsInt | 256 | 256 | 703.881 | 820.539 | 1.165735401 > MaskedLogicOpts.partiallyMaskedLogicOperationsInt | 256 | 512 | 698.958 | 822.174 | 1.17628527 > MaskedLogicOpts.partiallyMaskedLogicOperationsInt | 256 | 1024 | 715.533 | 806.71 | 1.12742529 > MaskedLogicOpts.partiallyMaskedLogicOperationsInt | 256 | 2048 | 678.087 | 797.53 | 1.176147014 > MaskedLogicOpts.partiallyMaskedLogicOperationsInt | 256 | 4096 | 714.427 | 824.008 | 1.153383061 > MaskedLogicOpts.partiallyMaskedLogicOperationsInt | 512 | 256 | 400.801 | 547.414 | 1.365799986 > MaskedLogicOpts.partiallyMaskedLogicOperationsInt | 512 | 512 | 453.713 | 602.492 | 1.327914342 > MaskedLogicOpts.partiallyMaskedLogicOperationsInt | 512 | 1024 | 467.685 | 612.172 | 1.308940847 > MaskedLogicOpts.partiallyMaskedLogicOperationsInt | 512 | 2048 | 467.286 | 612.659 | 1.311100696 > MaskedLogicOpts.partiallyMaskedLogicOperationsInt | 512 | 4096 | 465.71 | 671.911 | 1.442766958 > MaskedLogicOpts.partiallyMaskedLogicOperationsLong | 128 | 256 | 18.25 | 24.524 | 1.343780822 > MaskedLogicOpts.partiallyMaskedLogicOperationsLong | 128 | 512 | 18.634 | 24.408 | 1.30986369 > MaskedLogicOpts.partiallyMaskedLogicOperationsLong | 128 | 1024 | 18.566 | 24.839 | 1.337875687 > MaskedLogicOpts.partiallyMaskedLogicOperationsLong | 128 | 2048 | 18.568 | 24.65 | 1.327552779 > MaskedLogicOpts.partiallyMaskedLogicOperationsLong | 128 | 4096 | 18.685 | 24.448 | 1.308429221 > MaskedLogicOpts.partiallyMaskedLogicOperationsLong | 256 | 256 | 658.381 | 788.086 | 1.197005989 > MaskedLogicOpts.partiallyMaskedLogicOperationsLong | 256 | 512 | 679.09 | 780.808 | 1.149785743 > MaskedLogicOpts.partiallyMaskedLogicOperationsLong | 256 | 1024 | 675.793 | 783.304 | 1.159088656 > MaskedLogicOpts.partiallyMaskedLogicOperationsLong | 256 | 2048 | 679.09 | 823.756 | 1.213029201 > MaskedLogicOpts.partiallyMaskedLogicOperationsLong | 256 | 4096 | 677.724 | 782.655 | 1.154828514 > MaskedLogicOpts.partiallyMaskedLogicOperationsLong | 512 | 256 | 456.231 | 620.547 | 1.360159656 > MaskedLogicOpts.partiallyMaskedLogicOperationsLong | 512 | 512 | 468.07 | 604.75 | 1.292007606 > MaskedLogicOpts.partiallyMaskedLogicOperationsLong | 512 | 1024 | 467.188 | 605.256 | 1.295529851 > MaskedLogicOpts.partiallyMaskedLogicOperationsLong | 512 | 2048 | 468.52 | 605.854 | 1.293123026 > MaskedLogicOpts.partiallyMaskedLogicOperationsLong | 512 | 4096 | 467.954 | 605.996 | 1.294990533 test/jdk/jdk/incubator/vector/TestMaskedMacroLogicVector.java line 31: > 29: * @library /test/lib > 30: * @run main/othervm -XX:+IgnoreUnrecognizedVMOptions > 31: * -Xbatch -XX:-TieredCompilation -XX:CICompilerCount=1 -XX:UseAVX=3 How about using `os.arch` to specify those platform-dependent options instead of `-XX:+IgnoreUnrecognizedVMOptions`? Mix them up makes code hard to maintain. test/jdk/jdk/incubator/vector/TestMaskedMacroLogicVector.java line 93: > 91: > 92: static void testInt1(VectorSpecies SPECIES, int[] r, int[] a, int[] b, int[] c) { > 93: for (int i = 0; i < SPECIES.loopBound(r.length); i+=SPECIES.length()) { needs space on both sides of `+=` test/jdk/jdk/incubator/vector/TestMaskedMacroLogicVector.java line 369: > 367: // ===================================================== // > 368: > 369: private static final Random R = new Random(1024); It would be better to use Utils.getRandomInstance() from jdk.test.lib.Utils to ensure that the seed is printed for reproducibility. https://github.com/openjdk/jdk/blob/master/test/lib/jdk/test/lib/Utils.java#L503 ------------- PR: https://git.openjdk.java.net/panama-vector/pull/125 From psandoz at openjdk.java.net Wed Sep 15 15:23:58 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Wed, 15 Sep 2021 15:23:58 GMT Subject: [vectorIntrinsics+mask] RFR: 8273322: Enhance macro logic optimization for masked logic operations. In-Reply-To: References: Message-ID: On Tue, 14 Sep 2021 16:06:14 GMT, Jatin Bhateja wrote: > Patch extends existing macrologic inferencing algorithm to handle masked logic operations. > > Existing algorithm: > 1) Identify logic cone roots. > 2) Packs parent and logic child nodes into a MacroLogic node in bottom up traversal if input constraint are met. > i.e. maximum number of inputs which a macro logic node can have. > 3) Perform symbolic evaluation of logic expression tree by assigning value corresponding to a truth table column > to each input. > 4) Inputs along with encoded function together represents a macro logic node which mimics a truth table. > > Modification: > Extended the packing algorithm to operate on both predicated or non-predicated logic nodes. Following > rules define the criteria under which nodes gets packed into a macro logic node:- > 1) Parent and both child nodes are all unmasked or masked with same predicates. > 2) Masked parent can be packed with left child if it is predicated and both have same prediates. > 3) Masked parent can be packed with right child if its un-predicated or has matching predication condition. > 4) An unmasked parent can be packed with an unmasked child. > > New jtreg test case added with the patch exhaustively covers all the different combinations of predications of parent and > child nodes. > > Following are the performance number for JMH benchmark included with the patch. > > Machine Configuration: Intel(R) Xeon(R) Platinum 8280 CPU @ 2.70GHz (Cascadelake Server 28C 2S) > > > Benchmark | SPECIES | VECLEN | Baseline Score (ops/ms) | With Opt Score (ops/ms) | Gain Ratio > -- | -- | -- | -- | -- | -- > MaskedLogicOpts.bitwiseBlendOperationInt | 128 | 256 | 594.425 | 616.74 | 1.03754048 > MaskedLogicOpts.bitwiseBlendOperationInt | 128 | 512 | 596.433 | 616.405 | 1.033485739 > MaskedLogicOpts.bitwiseBlendOperationInt | 128 | 1024 | 586.716 | 618.718 | 1.054544277 > MaskedLogicOpts.bitwiseBlendOperationInt | 128 | 2048 | 594.68 | 618.235 | 1.039609538 > MaskedLogicOpts.bitwiseBlendOperationInt | 128 | 4096 | 595.357 | 617.803 | 1.037701749 > MaskedLogicOpts.bitwiseBlendOperationInt | 256 | 256 | 503.396 | 602.252 | 1.196378199 > MaskedLogicOpts.bitwiseBlendOperationInt | 256 | 512 | 529.454 | 572.485 | 1.081274294 > MaskedLogicOpts.bitwiseBlendOperationInt | 256 | 1024 | 560.688 | 587.143 | 1.047183104 > MaskedLogicOpts.bitwiseBlendOperationInt | 256 | 2048 | 539.919 | 586.473 | 1.086224045 > MaskedLogicOpts.bitwiseBlendOperationInt | 256 | 4096 | 542.102 | 586.694 | 1.082257583 > MaskedLogicOpts.bitwiseBlendOperationInt | 512 | 256 | 401.552 | 474.281 | 1.181119755 > MaskedLogicOpts.bitwiseBlendOperationInt | 512 | 512 | 371.352 | 520.497 | 1.401627028 > MaskedLogicOpts.bitwiseBlendOperationInt | 512 | 1024 | 403.174 | 514.51 | 1.27614876 > MaskedLogicOpts.bitwiseBlendOperationInt | 512 | 2048 | 386.124 | 511.22 | 1.323978825 > MaskedLogicOpts.maskedLogicOperationsInt | 512 | 256 | 316.054 | 654.797 | 2.071788365 > MaskedLogicOpts.maskedLogicOperationsInt | 512 | 512 | 312.912 | 600.227 | 1.918197448 > MaskedLogicOpts.maskedLogicOperationsInt | 512 | 1024 | 305.86 | 614.129 | 2.007876152 > MaskedLogicOpts.maskedLogicOperationsInt | 512 | 2048 | 306.589 | 617.645 | 2.014569994 > MaskedLogicOpts.maskedLogicOperationsInt | 512 | 4096 | 314.896 | 619.618 | 1.96769092 > MaskedLogicOpts.maskedLogicOperationsLong | 128 | 256 | 12.32 | 17.629 | 1.430925325 > MaskedLogicOpts.maskedLogicOperationsLong | 128 | 512 | 12.296 | 17.632 | 1.433962264 > MaskedLogicOpts.maskedLogicOperationsLong | 128 | 1024 | 12.027 | 17.663 | 1.468612289 > MaskedLogicOpts.maskedLogicOperationsLong | 128 | 2048 | 12.33 | 17.601 | 1.427493917 > MaskedLogicOpts.maskedLogicOperationsLong | 128 | 4096 | 12.329 | 17.65 | 1.43158407 > MaskedLogicOpts.maskedLogicOperationsLong | 256 | 256 | 413.078 | 1184.616 | 2.867777998 > MaskedLogicOpts.maskedLogicOperationsLong | 256 | 512 | 431.578 | 1069.109 | 2.477209218 > MaskedLogicOpts.maskedLogicOperationsLong | 256 | 1024 | 430.099 | 1089.835 | 2.53391661 > MaskedLogicOpts.maskedLogicOperationsLong | 256 | 2048 | 420.341 | 1204.934 | 2.8665631 > MaskedLogicOpts.maskedLogicOperationsLong | 256 | 4096 | 431.571 | 1069.704 | 2.478628082 > MaskedLogicOpts.maskedLogicOperationsLong | 512 | 256 | 311.43 | 599.982 | 1.926538869 > MaskedLogicOpts.maskedLogicOperationsLong | 512 | 512 | 305.459 | 620.418 | 2.031100737 > MaskedLogicOpts.maskedLogicOperationsLong | 512 | 1024 | 304.885 | 611.37 | 2.00524788 > MaskedLogicOpts.maskedLogicOperationsLong | 512 | 2048 | 305.198 | 619.347 | 2.029328501 > MaskedLogicOpts.maskedLogicOperationsLong | 512 | 4096 | 305.317 | 615.882 | 2.017188692 > MaskedLogicOpts.partiallyMaskedLogicOperationsInt | 128 | 256 | 781.922 | 856.605 | 1.095512084 > MaskedLogicOpts.partiallyMaskedLogicOperationsInt | 128 | 512 | 752.428 | 856.559 | 1.138393308 > MaskedLogicOpts.partiallyMaskedLogicOperationsInt | 128 | 1024 | 764.4 | 837.68 | 1.095866039 > MaskedLogicOpts.partiallyMaskedLogicOperationsInt | 128 | 2048 | 780.311 | 857.797 | 1.099301432 > MaskedLogicOpts.partiallyMaskedLogicOperationsInt | 128 | 4096 | 780.489 | 837.536 | 1.073091357 > MaskedLogicOpts.partiallyMaskedLogicOperationsInt | 256 | 256 | 703.881 | 820.539 | 1.165735401 > MaskedLogicOpts.partiallyMaskedLogicOperationsInt | 256 | 512 | 698.958 | 822.174 | 1.17628527 > MaskedLogicOpts.partiallyMaskedLogicOperationsInt | 256 | 1024 | 715.533 | 806.71 | 1.12742529 > MaskedLogicOpts.partiallyMaskedLogicOperationsInt | 256 | 2048 | 678.087 | 797.53 | 1.176147014 > MaskedLogicOpts.partiallyMaskedLogicOperationsInt | 256 | 4096 | 714.427 | 824.008 | 1.153383061 > MaskedLogicOpts.partiallyMaskedLogicOperationsInt | 512 | 256 | 400.801 | 547.414 | 1.365799986 > MaskedLogicOpts.partiallyMaskedLogicOperationsInt | 512 | 512 | 453.713 | 602.492 | 1.327914342 > MaskedLogicOpts.partiallyMaskedLogicOperationsInt | 512 | 1024 | 467.685 | 612.172 | 1.308940847 > MaskedLogicOpts.partiallyMaskedLogicOperationsInt | 512 | 2048 | 467.286 | 612.659 | 1.311100696 > MaskedLogicOpts.partiallyMaskedLogicOperationsInt | 512 | 4096 | 465.71 | 671.911 | 1.442766958 > MaskedLogicOpts.partiallyMaskedLogicOperationsLong | 128 | 256 | 18.25 | 24.524 | 1.343780822 > MaskedLogicOpts.partiallyMaskedLogicOperationsLong | 128 | 512 | 18.634 | 24.408 | 1.30986369 > MaskedLogicOpts.partiallyMaskedLogicOperationsLong | 128 | 1024 | 18.566 | 24.839 | 1.337875687 > MaskedLogicOpts.partiallyMaskedLogicOperationsLong | 128 | 2048 | 18.568 | 24.65 | 1.327552779 > MaskedLogicOpts.partiallyMaskedLogicOperationsLong | 128 | 4096 | 18.685 | 24.448 | 1.308429221 > MaskedLogicOpts.partiallyMaskedLogicOperationsLong | 256 | 256 | 658.381 | 788.086 | 1.197005989 > MaskedLogicOpts.partiallyMaskedLogicOperationsLong | 256 | 512 | 679.09 | 780.808 | 1.149785743 > MaskedLogicOpts.partiallyMaskedLogicOperationsLong | 256 | 1024 | 675.793 | 783.304 | 1.159088656 > MaskedLogicOpts.partiallyMaskedLogicOperationsLong | 256 | 2048 | 679.09 | 823.756 | 1.213029201 > MaskedLogicOpts.partiallyMaskedLogicOperationsLong | 256 | 4096 | 677.724 | 782.655 | 1.154828514 > MaskedLogicOpts.partiallyMaskedLogicOperationsLong | 512 | 256 | 456.231 | 620.547 | 1.360159656 > MaskedLogicOpts.partiallyMaskedLogicOperationsLong | 512 | 512 | 468.07 | 604.75 | 1.292007606 > MaskedLogicOpts.partiallyMaskedLogicOperationsLong | 512 | 1024 | 467.188 | 605.256 | 1.295529851 > MaskedLogicOpts.partiallyMaskedLogicOperationsLong | 512 | 2048 | 468.52 | 605.854 | 1.293123026 > MaskedLogicOpts.partiallyMaskedLogicOperationsLong | 512 | 4096 | 467.954 | 605.996 | 1.294990533 test/jdk/jdk/incubator/vector/TestMaskedMacroLogicVector.java line 42: > 40: import jdk.incubator.vector.*; > 41: > 42: public class TestMaskedMacroLogicVector { This test looks a strong a candidate to use the IR test framework. https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/compiler/lib/ir_framework/README.md Can we use that? IIUC this PR is an additional optimization rather than fundamental support for masking. In that case I think we have more time to explore better testing, and this could be a follow on PR from the main masking that will soon be under review. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/125 From maurizio.cimadamore at oracle.com Thu Sep 16 14:59:13 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 16 Sep 2021 15:59:13 +0100 Subject: [foreign] thoughts on finalizing foreign APIs Message-ID: Hi, we have spent the last few weeks looking at the foreign APIs more holistically, to see what we could do to improve them, in order to get them preview/finalization ready. The resulting changes are described in the following write up: https://inside.java/2021/09/16/finalizing-the-foreign-apis/ We think the proposed API [2, 3] is much simpler, tighter and safer - while retaining the same expressiveness of the existing API. Moving forward, we would like to start integrating the proposed changes into the panama repo, and incubate those changes in 18. We will then (finger crossed!) move towards finalizing the API, by making it a preview API in 19 (the document describes some basic shuffling moves on how we might want to do that). While we could technically preview things in 18, we believe that the extra steps required to move the API into java.base would push us too close to the code freeze deadline; besides there are still outstanding performance issues (such as [1]) which we'd like to have addressed, so that user experience can be as smooth as possible. For these reasons, incubating in 18 and previewing in 19 seems like the most sensible option at this point in time. Cheers Maurizio [1] - https://bugs.openjdk.java.net/browse/JDK-8259609 [2] - http://cr.openjdk.java.net/~mcimadamore/panama/foreign-finalize-javadoc/javadoc/jdk/incubator/foreign/package-summary.html [3] - https://github.com/mcimadamore/panama-foreign/tree/foreign-finalize%2Bjextract From mcimadamore at openjdk.java.net Thu Sep 16 16:38:30 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 16 Sep 2021 16:38:30 GMT Subject: [foreign-memaccess+abi] RFR: 8270376: Finalize API for memory copy [v14] In-Reply-To: References: Message-ID: <6AHrRfyHEDUY0ivsrUF8Ey2LnZxEbTDlDSy7Oru7SNU=.4735620d-15cb-42e3-bc97-d5f109404c84@github.com> On Tue, 10 Aug 2021 09:32:09 GMT, Maurizio Cimadamore wrote: >> This patch ties up some loose ends with the MemoryCopy API, and it also prepares the ground for some other related refactorings in this area. >> >> The meat of this patch is represented by the various changes in MemoryCopy, where all methods were renamed to simply `copy`, and the length parameter (now called `elementCount`) is always moved to the end. >> >> I've also simplified naming of parameters, as I think distinguishing between `index` and `offset` is enough (e.g. an array has an index, a segment has an offset). >> >> You will see that, at the very end of the class, three more copy methods have been added, which deal fully in terms of segments. I have also moved the complex layout-based memory segment copy operation (which does the swap) as a static method in this class, as I believe the static form makes the method more regular and usable. >> >> I've made some changes to our uses of `copyFrom` in the linker, to use the new methods in `MemoryCopy` when the copy operation was performing slicing in the source/target segment, which I think makes the code more readable. Of course these changes are completely optional and could be omitted as well. > > Maurizio Cimadamore has updated the pull request incrementally with two additional commits since the last revision: > > - Tweak micro benchmarks > - Improve performance of generic copy methods I will close this PR. Some of the issues discussed here have resulted in a much bigger API restructuring which is described here: https://mail.openjdk.java.net/pipermail/panama-dev/2021-September/014946.html Among the changes described in the writeup linked in the above email, there is a proposal which makes the segment dereference API much tighter and integrated with the rest of the MemorySegment and MemoryLayout APIs. We believe that API is the way forward, and that `MemoryAccess` and `MemoryCopy` were, in the end, (useful) intermediate steps along the way. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/568 From mcimadamore at openjdk.java.net Thu Sep 16 16:38:32 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 16 Sep 2021 16:38:32 GMT Subject: [foreign-memaccess+abi] Withdrawn: 8270376: Finalize API for memory copy In-Reply-To: References: Message-ID: On Tue, 13 Jul 2021 16:49:06 GMT, Maurizio Cimadamore wrote: > This patch ties up some loose ends with the MemoryCopy API, and it also prepares the ground for some other related refactorings in this area. > > The meat of this patch is represented by the various changes in MemoryCopy, where all methods were renamed to simply `copy`, and the length parameter (now called `elementCount`) is always moved to the end. > > I've also simplified naming of parameters, as I think distinguishing between `index` and `offset` is enough (e.g. an array has an index, a segment has an offset). > > You will see that, at the very end of the class, three more copy methods have been added, which deal fully in terms of segments. I have also moved the complex layout-based memory segment copy operation (which does the swap) as a static method in this class, as I believe the static form makes the method more regular and usable. > > I've made some changes to our uses of `copyFrom` in the linker, to use the new methods in `MemoryCopy` when the copy operation was performing slicing in the source/target segment, which I think makes the code more readable. Of course these changes are completely optional and could be omitted as well. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/568 From sebastian.stenzel at gmail.com Thu Sep 16 17:19:40 2021 From: sebastian.stenzel at gmail.com (Sebastian Stenzel) Date: Thu, 16 Sep 2021 19:19:40 +0200 Subject: [foreign] thoughts on finalizing foreign APIs In-Reply-To: References: Message-ID: <8A394507-B2D6-4E3B-9BB4-CB11EB1D76D9@gmail.com> Hi Maurizio, very interesting article. I love all the thoughts that go into designing such a beautiful API! Just one question regarding the following: > we plan to move all the classes in the jdk.incubator.foreignpackage under the java.lang.foreignpackage [3] in the java.base module. Is there any reason to place it in java.base? Just asking to avoid the need to jigsaw 2.0 java.base with JDK 32 ;-) Best regards Sebastian > Am 16.09.2021 um 16:59 schrieb Maurizio Cimadamore : > > ?Hi, > we have spent the last few weeks looking at the foreign APIs more holistically, to see what we could do to improve them, in order to get them preview/finalization ready. The resulting changes are described in the following write up: > > https://inside.java/2021/09/16/finalizing-the-foreign-apis/ > > We think the proposed API [2, 3] is much simpler, tighter and safer - while retaining the same expressiveness of the existing API. > > Moving forward, we would like to start integrating the proposed changes into the panama repo, and incubate those changes in 18. We will then (finger crossed!) move towards finalizing the API, by making it a preview API in 19 (the document describes some basic shuffling moves on how we might want to do that). While we could technically preview things in 18, we believe that the extra steps required to move the API into java.base would push us too close to the code freeze deadline; besides there are still outstanding performance issues (such as [1]) which we'd like to have addressed, so that user experience can be as smooth as possible. For these reasons, incubating in 18 and previewing in 19 seems like the most sensible option at this point in time. > > Cheers > Maurizio > > [1] - https://bugs.openjdk.java.net/browse/JDK-8259609 > [2] - http://cr.openjdk.java.net/~mcimadamore/panama/foreign-finalize-javadoc/javadoc/jdk/incubator/foreign/package-summary.html > [3] - https://github.com/mcimadamore/panama-foreign/tree/foreign-finalize%2Bjextract > > From maurizio.cimadamore at oracle.com Thu Sep 16 17:46:25 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 16 Sep 2021 18:46:25 +0100 Subject: [foreign] thoughts on finalizing foreign APIs In-Reply-To: <8A394507-B2D6-4E3B-9BB4-CB11EB1D76D9@gmail.com> References: <8A394507-B2D6-4E3B-9BB4-CB11EB1D76D9@gmail.com> Message-ID: <5b8fb277-c39c-ead6-eee4-c0857376a8bf@oracle.com> On 16/09/2021 18:19, Sebastian Stenzel wrote: > Hi Maurizio, > > very interesting article. I love all the thoughts that go into > designing such a beautiful API! Thanks for reading! > > Just one question regarding the following: > >> we plan to move all the classes in the |jdk.incubator.foreign|package >> under the |java.lang.foreign|package [3 >> ] >> in the |java.base|?module. > > Is there any reason to place it in java.base? Just asking to avoid the > need to jigsaw 2.0 java.base with JDK 32 ;-) The API is rather small-ish - and I think it also has very deep connection to the core of the platform. One main example: the implementations for the memory access var handle *have* to be defined in java.base. But if the API lives somewhere else (as it does now), it becomes very difficult to deal with these, as we have to introduce an intermediate interface (e.g. `MemorySegmentProxy`) which is used by java.base and implemented by the other module. Doing this has interesting ramifications: we need first to adapt all the var handles back to take a `MemorySegment`, not a `MemorySegmentProxy` otherwise the type mismatch will cause the var handle to be called with the `invoke` semantics, not with the `invokeExact`; secondly, we have seen cases where the introduction of these intermediate types was severely limiting C2 abilities to speculate on whether access was on- or off- heap (this is why at some point `MemorySegmentProxy` was changed from an interface to an abstract class). There's just too many things to fight against if you move outside java.base; on top of that, add that we might want, in the future, to perhaps use Panama more in the JDK itself (e.g. to implement NIO), and maybe use segments to implement byte buffers. If we want to have a shot at doing any of these things, then I think it's clear(er?) that this API belongs in java.base. Cheers Maurizio > > Best regards > Sebastian > >> Am 16.09.2021 um 16:59 schrieb Maurizio Cimadamore >> : >> >> ?Hi, >> we have spent the last few weeks looking at the foreign APIs more >> holistically, to see what we could do to improve them, in order to >> get them preview/finalization ready. The resulting changes are >> described in the following write up: >> >> https://inside.java/2021/09/16/finalizing-the-foreign-apis/ >> >> >> We think the proposed API [2, 3] is much simpler, tighter and safer - >> while retaining the same expressiveness of the existing API. >> >> Moving forward, we would like to start integrating the proposed >> changes into the panama repo, and incubate those changes in 18. We >> will then (finger crossed!) move towards finalizing the API, by >> making it a preview API in 19 (the document describes some basic >> shuffling moves on how we might want to do that). While we could >> technically preview things in 18, we believe that the extra steps >> required to move the API into java.base would push us too close to >> the code freeze deadline; besides there are still outstanding >> performance issues (such as [1]) which we'd like to have addressed, >> so that user experience can be as smooth as possible. For these >> reasons, incubating in 18 and previewing in 19 seems like the most >> sensible option at this point in time. >> >> Cheers >> Maurizio >> >> [1] - https://bugs.openjdk.java.net/browse/JDK-8259609 >> [2] - >> http://cr.openjdk.java.net/~mcimadamore/panama/foreign-finalize-javadoc/javadoc/jdk/incubator/foreign/package-summary.html >> [3] - >> https://github.com/mcimadamore/panama-foreign/tree/foreign-finalize%2Bjextract >> >> >> From mcimadamore at openjdk.java.net Thu Sep 16 17:56:10 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 16 Sep 2021 17:56:10 GMT Subject: [foreign-memaccess+abi] RFR: 8273905: Foreign API refresh Message-ID: As outlined in [1], there are areas of the foreign API we'd like to improve upon, such as: * dereference: there is a mismatch between API points which create segments (which take a layout) and dereference API points, which do not take layouts * role of `MemoryAddress`: in Java 17, `MemoryAddress` has become a stateful carrier, which is attached to a scope. This is inconvenient, as in most cases, a memory address is just a raw pointer that arises when interacting with native code. * resource scopes: the API for scopes has too many flavors to pick from, many of which overlap. The fact that scopes and segment allocators are unrelated forces clients to introduce ad hoc conversions from scopes to allocators, and library developers to add overloads. Finally, the API for acquiring scopes doesn't work well with try-with-resources, and could also be simplified. I will add separate comments to explain how the API has changed to resolve the above issues. [1] - https://mail.openjdk.java.net/pipermail/panama-dev/2021-September/014946.html ------------- Commit messages: - Changes to finalize the foreign memory access/linker APIs. Changes: https://git.openjdk.java.net/panama-foreign/pull/576/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=576&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273905 Stats: 13220 lines in 165 files changed: 4729 ins; 6259 del; 2232 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/576.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/576/head:pull/576 PR: https://git.openjdk.java.net/panama-foreign/pull/576 From mcimadamore at openjdk.java.net Thu Sep 16 17:56:10 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 16 Sep 2021 17:56:10 GMT Subject: [foreign-memaccess+abi] RFR: 8273905: Foreign API refresh In-Reply-To: References: Message-ID: <_Z4VANGZ2sJbI_0exwK5Id921QlCL8OGhgv7l1DMk2g=.dee12906-b31f-425d-8062-61002e59584d@github.com> On Thu, 16 Sep 2021 16:39:11 GMT, Maurizio Cimadamore wrote: > As outlined in [1], there are areas of the foreign API we'd like to improve upon, such as: > > * dereference: there is a mismatch between API points which create segments (which take a layout) and dereference API points, which do not take layouts > > * role of `MemoryAddress`: in Java 17, `MemoryAddress` has become a stateful carrier, which is attached to a scope. This is inconvenient, as in most cases, a memory address is just a raw pointer that arises when interacting with native code. > > * resource scopes: the API for scopes has too many flavors to pick from, many of which overlap. The fact that scopes and segment allocators are unrelated forces clients to introduce ad hoc conversions from scopes to allocators, and library developers to add overloads. Finally, the API for acquiring scopes doesn't work well with try-with-resources, and could also be simplified. > > I will add separate comments to explain how the API has changed to resolve the above issues. > > [1] - https://mail.openjdk.java.net/pipermail/panama-dev/2021-September/014946.html Disclaimer: the proposed changes touch several areas of the APIs (in deep ways) which makes it hard (if not impossible) to break the changes apart into multiple PRs. Below is an attempt to describe the main areas affected by this PR. ### Memory dereference The main change in this area is to attach carriers to `ValueLayout`. Because of this, we have defined several subclasses of `ValueLayout` (one per carrier), such as `ValueLayout.OfInt`, `ValueLayout.OfFloat` and so forth. Attaching layouts to carriers allows expressing deference method elegantly - e.g. instead of: `MemoryAccess.getIntAtOffset(segment, offset)` simply: segment.get(JAVA_INT, offset); The new dereference methods are statically safe: it is not possible for clients to pass values to setters of the *wrong* type. We have used the same trick in different parts of the API, to make it more uniform and safer (see changes in `SegmentAllocator` and `VaList`). As a result, `MemoryAccess` and `MemoryCopy` go away, as the same operations are now available as instance (or static, in the case of copy) methods in `MemorySegment`. Since the new dereference API points are parameterized by a layout, it is always possible to e.g. create a layout with desired endianness and use that instead. The only caveat is that, for performance to be optimal, the layout using during dereference should be a VM constant (e.g. static final field). ### CLinker First, we have moved most of the `CLinker` helper methods away from `CLinker`. For instance, to allocate an Utf8 string, there is now a method in `SegmentAllocator`, as well as a pair of getter/setter in `MemorySegment`. This makes the code easier to follow. Since carriers are attached to value layout, passing a `MethodType` to `CLinker::downcallHandle` is no longer necessary, so the API for obtaining downcall method handles has been simplified. Some things have been removed as well; most notably, the platform-dependent layout constants, such as `C_INT` are gone. This is because we cannot type these constants sharply - given that their type would vary across platforms (is `C_LONG` a `ValueLayout.OfInt` or a `ValueLayout.OfLong` ?). Ultimately, it is the role of a tool (such as jextract) to generate a set of layout constants which work on a given platform, so we have made the API more neutral. It is still possible to use layouts such as `JAVA_INT` and `JAVA_LONG` to link downcall method handles, and that is not too different from using JNI types such as `jint` and `jlong` (that is, they should be used with care, making sure they match the underlying platform types). Another thing we removed was the `freeMemory` and `allocateMemory` API points. These were just shortcuts for commonly used downcall method handles, which in most of the cases will be included in a jextraction unit anyway. There seems to be little value in including such methods in the `CLinker` API. ### Layouts The main change to memory layouts is the removal of the layout attribute mechanism. This mechanism was powerful, but also very prone to misuse; it was unfortunate that the whole linker classification story depended on it as well, as that meant that linker-related attributes were mixed in with user-defined ones. If needed, we might well re-introduce some form of user-defined attribute in the future (e.g. a `Map` which can be attached to a layout, which will be preserved by the immutable withers). But for now we would like to keep the API minimal, as we think that (bar few exceptions) most of the use cases for the attribute API were internal. It is also possible that now that layouts are associated with carriers, some of the things previously stored in attributes might be stored in a `ClassValue` instead. A minor change/simplification to the layout API is that obtaining a memory access var handle from a layout no longer requires a `Class` parameter, as that parameter is now inferred from the layout. Internally, all value layouts now keep a `@Stable` var handle cached field, so that dereferencing through them can happen at optimal speed. ### Memory address `MemoryAddress` goes back to being a dumb wrapper around a `long`. In fact, we have dropped support for heap-based `MemoryAddress` and made `MemoryAddress` a native-only concept, since addresses are only really used when interacting with native code (in all other use cases, using a segment is the best option). You will notice that the `Addressable` interface has been enhanced slightly, to include a scope. This allows us to open up the `Addressable` API, so that clients can define custom `Addressable` subclasses, and so that the `CLinker` would be able to keep addressable parameters alive in the context of a native call. In fact, the linker no longer erases address layouts down to `MemoryAddress`, but it erases them to `Addressable` instead, so that the scope is preserved. `MemoryAddress` is now an implementation of `Addressable` whose scope is always the global scope. ### Resource scopes We decided to drop the concept of implicit scopes. After all, we already had the notion of confined/shared explicit scopes which were also backed by a cleaner. This is sufficient to cover the implicit cases too. Another simplification we have done is in the acquire/release mechanism; you will notice that there's only one method now, called `keepAlive`, which takes a target scope. This method will essentially acquire the target scope, which will only be released when the receiver scope is closed. Finally, we have tweaked the `ResourceScope` interface to extend `SegmentAllocator`. There are many instances where an allocator is required where a client only has a scope. This subtyping allows clients to get rid of redundant conversion (e.g. `SegmentAllocator.ofScope(scope)`) and just pass a scope where an allocator is expected. Combined with other changes in the dereference API, we believe this makes the API a lot more fluent. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/576 From psandoz at openjdk.java.net Thu Sep 16 22:45:08 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Thu, 16 Sep 2021 22:45:08 GMT Subject: [vectorIntrinsics+mask] RFR: 8273264: AArch64: [vector] Add missing rules for VectorMaskCast [v2] In-Reply-To: References: <3GwCgL--SIHHN4_211f64yEHRoj9qYkWR0DJwPOpIAw=.5a48caf3-f888-43d7-bb55-f962ae2ac179@github.com> Message-ID: <5sb10EQdqc2DnikYw4TXge65wJPAvM12G-6co3bMWek=.0f3c11af-a489-4fc1-bfe8-5b217e058b6f@github.com> On Wed, 15 Sep 2021 07:11:56 GMT, Eric Liu wrote: >> Do you have any indicates as to why? Is it because the invocation count is too low? > > The reason maybe the same as https://bugs.openjdk.java.net/browse/JDK-8259610, but I didn't pay too much time in the details. Ok. I don't wanna block this PR. Could you add some comment to the test providing some rational as to why it is currently needed, making reference to the vector conversions tests, and that we need to eventually resolve such issues and avoid the duplication? ------------- PR: https://git.openjdk.java.net/panama-vector/pull/124 From psandoz at openjdk.java.net Fri Sep 17 01:01:55 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Fri, 17 Sep 2021 01:01:55 GMT Subject: [foreign-memaccess+abi] RFR: 8273905: Foreign API refresh In-Reply-To: References: Message-ID: <-5PZVUWaqANzeLTJE06qc49u941z-gQ__mSUxcnQVaw=.9fe67b3f-cb24-4046-9962-a79376d9abd5@github.com> On Thu, 16 Sep 2021 16:39:11 GMT, Maurizio Cimadamore wrote: > As outlined in [1], there are areas of the foreign API we'd like to improve upon, such as: > > * dereference: there is a mismatch between API points which create segments (which take a layout) and dereference API points, which do not take layouts > > * role of `MemoryAddress`: in Java 17, `MemoryAddress` has become a stateful carrier, which is attached to a scope. This is inconvenient, as in most cases, a memory address is just a raw pointer that arises when interacting with native code. > > * resource scopes: the API for scopes has too many flavors to pick from, many of which overlap. The fact that scopes and segment allocators are unrelated forces clients to introduce ad hoc conversions from scopes to allocators, and library developers to add overloads. Finally, the API for acquiring scopes doesn't work well with try-with-resources, and could also be simplified. > > I will add separate comments to explain how the API has changed to resolve the above issues. > > [1] - https://mail.openjdk.java.net/pipermail/panama-dev/2021-September/014946.html src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/AbstractLayout.java line 238: > 236: * Attribute name used to specify the name property of a memory layout (see {@link #name()} and {@link #withName(String)}). > 237: */ > 238: String LAYOUT_NAME = "layout/name"; Unused, except referenced in JavaDoc of `MemoryLayout` src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java line 46: > 44: * follow the JVM's target platform C ABI. A C linker provides two main capabilities: first, it allows Java code > 45: * to link foreign functions into a so called downcall method handle; secondly, it allows to > 46: * generate an upcalls stub which can be used to call Java method handle from a native function. Suggestion: * to link foreign functions into a so called downcall method handle; secondly, it allows * native code to call Java method handles via the generation of upcall stubs. src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/FunctionDescriptor.java line 212: > 210: } > 211: > 212: final static class VariadicFunction extends FunctionDescriptor { Suggestion: static final class VariadicFunction extends FunctionDescriptor { src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemorySegment.java line 98: > 96: *

> 97: * Contents of mapped memory segments can be {@linkplain #force() persisted} and {@linkplain #load() loaded} to and from the underlying file; > 98: * these capabilities are suitable replacements for some functionalities in the {@link java.nio.MappedByteBuffer} class. Suggestion: * these capabilities are suitable replacements for some capabilities in the {@link java.nio.MappedByteBuffer} class. src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemorySegment.java line 114: > 112: * a native segment unsafely from a give memory address, by providing the segment size, as well as the segment {@linkplain ResourceScope scope}. > 113: * This is a restricted operation and should be used with > 114: * caution: for instance, an incorrect segment size correctly could result in a VM crash when attempting to dereference Suggestion: * caution: for instance, an incorrect segment size could result in a VM crash when attempting to dereference src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemorySegment.java line 135: > 133: * } > 134: * > 135: * For more complex dereference operation (e.g. structured memory access), clients can obtain a memory access var handle, Suggestion: * For more complex dereference operations (e.g. structured memory access), clients can obtain a memory access var handle, src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemorySegment.java line 387: > 385: * the length of the common prefix, and it follows that there is a mismatch > 386: * between the two segments at that offset within the respective segments. > 387: * If one segment is a proper prefix of the other than the returned offset is Suggestion: * If one segment is a proper prefix of the other then the returned offset is src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemorySegment.java line 612: > 610: * {@code ALL-UNNAMED} in case {@code M} is an unnamed module. > 611: */ > 612: Suggestion: src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemorySegment.java line 626: > 624: * @throws IllegalArgumentException if the size of the native string is greater than the largest string supported by the platform. > 625: * @throws IllegalStateException if the size of the native string is greater than the size of the segment > 626: * associated with {@code addr}, or if {@code addr} is associated with a segment that is not alive. Referral to unknown parameter `addr` src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/ResourceScope.java line 66: > 64: * Resource scopes are also closed automatically once the scope instance becomes > 65: * unreachable. This can be useful to allow for predictable, > 66: * deterministic resource deallocation, while still prevent accidental native memory leaks. In case a managed resource scope Suggestion: * deterministic resource deallocation, while still preventing accidental native memory leaks. In case a managed resource scope src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/package-info.java line 86: > 84: * try-with-resources construct: this idiom ensures that all the memory resources associated with the segment will be released > 85: * at the end of the block, according to the semantics described in Section {@jls 14.20.3} of The Java Language Specification. > 86: * Since a resource scope act as a {@link jdk.incubator.foreign.SegmentAllocator segment allocators}, we can also Suggestion: * Since a resource scope acts as a {@link jdk.incubator.foreign.SegmentAllocator segment allocator}, we can also test/jdk/java/foreign/TestArrays.java line 62: > 60: > 61: static SequenceLayout chars = MemoryLayout.sequenceLayout(100, > 62: ValueLayout.JAVA_CHAR Suggestion: JAVA_CHAR And for other usages. test/jdk/java/foreign/TestByteBuffer.java line 128: > 126: > 127: static SequenceLayout ints = MemoryLayout.sequenceLayout(100, > 128: ValueLayout.JAVA_INT.withOrder(ByteOrder.BIG_ENDIAN) Suggestion: JAVA_INT.withOrder(ByteOrder.BIG_ENDIAN) ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/576 From eliu at openjdk.java.net Fri Sep 17 06:49:39 2021 From: eliu at openjdk.java.net (Eric Liu) Date: Fri, 17 Sep 2021 06:49:39 GMT Subject: [vectorIntrinsics+mask] RFR: 8273264: AArch64: [vector] Add missing rules for VectorMaskCast [v3] In-Reply-To: References: Message-ID: <0VNeTEwxOzfagBPwDN0Cuc8XzbBjVdjy5T05qkXy3i0=.23538da2-886f-4115-874e-6a8d088c3b83@github.com> > This patch > 1. Adds missing rules for VectorMaskCast for compatible species, E.g. > ByteVector.SPECIES_64 --> ShortVector.SPECIES_128 > 2. Fixes a matching failure on AArch64. > > The performance improves about 60% compared with the unintrinsified > version. Eric Liu has updated the pull request incrementally with two additional commits since the last revision: - add comment to test case Change-Id: I9db7b5c3a263cc21bfd06aeff91f45873201e1ed - Fix a predicate register allocation issue When a predicate live range has a predicate register mask chosen, we create a map between node and opto reg. For scalable register, when it is allocated at stack, we need to record the real hi/lo opto reg pair to indicate the size of stack it occupied. But for a physical register allocated, we just mask the whole reg mask slots, e.g. only one slot for predicate register. This patch fixes the issue for predicate register handling. When predicate is allocated as a physical register, e.g. 335 (P15), we should not call set2(), which will assign both 335 and 336 for this live range. Also move idealreg2spillmask[Op_RegVectMask] initialization code into scalable vector handling block to align with the handling for Op_VecA. Change-Id: I64b42f654a158c2f40a0b6792740678d07aac933 ------------- Changes: - all: https://git.openjdk.java.net/panama-vector/pull/124/files - new: https://git.openjdk.java.net/panama-vector/pull/124/files/84761ce0..624e7239 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=124&range=02 - incr: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=124&range=01-02 Stats: 23 lines in 3 files changed: 13 ins; 1 del; 9 mod Patch: https://git.openjdk.java.net/panama-vector/pull/124.diff Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/124/head:pull/124 PR: https://git.openjdk.java.net/panama-vector/pull/124 From eliu at openjdk.java.net Fri Sep 17 06:57:11 2021 From: eliu at openjdk.java.net (Eric Liu) Date: Fri, 17 Sep 2021 06:57:11 GMT Subject: [vectorIntrinsics+mask] RFR: 8273264: AArch64: [vector] Add missing rules for VectorMaskCast [v3] In-Reply-To: <5sb10EQdqc2DnikYw4TXge65wJPAvM12G-6co3bMWek=.0f3c11af-a489-4fc1-bfe8-5b217e058b6f@github.com> References: <3GwCgL--SIHHN4_211f64yEHRoj9qYkWR0DJwPOpIAw=.5a48caf3-f888-43d7-bb55-f962ae2ac179@github.com> <5sb10EQdqc2DnikYw4TXge65wJPAvM12G-6co3bMWek=.0f3c11af-a489-4fc1-bfe8-5b217e058b6f@github.com> Message-ID: On Thu, 16 Sep 2021 22:41:31 GMT, Paul Sandoz wrote: >> The reason maybe the same as https://bugs.openjdk.java.net/browse/JDK-8259610, but I didn't pay too much time in the details. > > Ok. I don't wanna block this PR. Could you add some comment to the test providing some rational as to why it is currently needed, making reference to the vector conversions tests, and that we need to eventually resolve such issues and avoid the duplication? Yes, it's been added in the new commit. Thanks for your kindly review. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/124 From eliu at openjdk.java.net Fri Sep 17 07:38:28 2021 From: eliu at openjdk.java.net (Eric Liu) Date: Fri, 17 Sep 2021 07:38:28 GMT Subject: [vectorIntrinsics+mask] RFR: 8273264: AArch64: [vector] Add missing rules for VectorMaskCast [v4] In-Reply-To: References: Message-ID: <8KamhXt9bDj4Oys63C_RIAZ0dQzsbswGMEPZ1FNmhE0=.7a86ee49-0fe1-418b-b02c-ccd5521a79af@github.com> > This patch > 1. Adds missing rules for VectorMaskCast for compatible species, E.g. > ByteVector.SPECIES_64 --> ShortVector.SPECIES_128 > 2. Fixes a matching failure on AArch64. > > The performance improves about 60% compared with the unintrinsified > version. Eric Liu has updated the pull request incrementally with one additional commit since the last revision: fix comment Change-Id: I01670a0e4a8df4f3a9a62b779ca5659863ec05d9 ------------- Changes: - all: https://git.openjdk.java.net/panama-vector/pull/124/files - new: https://git.openjdk.java.net/panama-vector/pull/124/files/624e7239..14cecf97 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=124&range=03 - incr: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=124&range=02-03 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/panama-vector/pull/124.diff Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/124/head:pull/124 PR: https://git.openjdk.java.net/panama-vector/pull/124 From njian at openjdk.java.net Fri Sep 17 07:44:10 2021 From: njian at openjdk.java.net (Ningsheng Jian) Date: Fri, 17 Sep 2021 07:44:10 GMT Subject: [vectorIntrinsics+mask] RFR: 8273264: AArch64: [vector] Add missing rules for VectorMaskCast [v4] In-Reply-To: <8KamhXt9bDj4Oys63C_RIAZ0dQzsbswGMEPZ1FNmhE0=.7a86ee49-0fe1-418b-b02c-ccd5521a79af@github.com> References: <8KamhXt9bDj4Oys63C_RIAZ0dQzsbswGMEPZ1FNmhE0=.7a86ee49-0fe1-418b-b02c-ccd5521a79af@github.com> Message-ID: On Fri, 17 Sep 2021 07:38:28 GMT, Eric Liu wrote: >> This patch >> 1. Adds missing rules for VectorMaskCast for compatible species, E.g. >> ByteVector.SPECIES_64 --> ShortVector.SPECIES_128 >> 2. Fixes a matching failure on AArch64. >> >> The performance improves about 60% compared with the unintrinsified >> version. > > Eric Liu has updated the pull request incrementally with one additional commit since the last revision: > > fix comment > > Change-Id: I01670a0e4a8df4f3a9a62b779ca5659863ec05d9 Thanks to incorporate aarch64 predicate register allocation fix. Other aarch64 part looks good to me. ------------- Marked as reviewed by njian (Committer). PR: https://git.openjdk.java.net/panama-vector/pull/124 From mcimadamore at openjdk.java.net Fri Sep 17 10:25:45 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 17 Sep 2021 10:25:45 GMT Subject: [foreign-memaccess+abi] RFR: 8273905: Foreign API refresh [v2] In-Reply-To: References: Message-ID: > As outlined in [1], there are areas of the foreign API we'd like to improve upon, such as: > > * dereference: there is a mismatch between API points which create segments (which take a layout) and dereference API points, which do not take layouts > > * role of `MemoryAddress`: in Java 17, `MemoryAddress` has become a stateful carrier, which is attached to a scope. This is inconvenient, as in most cases, a memory address is just a raw pointer that arises when interacting with native code. > > * resource scopes: the API for scopes has too many flavors to pick from, many of which overlap. The fact that scopes and segment allocators are unrelated forces clients to introduce ad hoc conversions from scopes to allocators, and library developers to add overloads. Finally, the API for acquiring scopes doesn't work well with try-with-resources, and could also be simplified. > > I will add separate comments to explain how the API has changed to resolve the above issues. > > [1] - https://mail.openjdk.java.net/pipermail/panama-dev/2021-September/014946.html Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Address review comments ------------- Changes: - all: https://git.openjdk.java.net/panama-foreign/pull/576/files - new: https://git.openjdk.java.net/panama-foreign/pull/576/files/7a745a21..0cbda30b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=576&range=01 - incr: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=576&range=00-01 Stats: 76 lines in 10 files changed: 1 ins; 40 del; 35 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/576.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/576/head:pull/576 PR: https://git.openjdk.java.net/panama-foreign/pull/576 From duke at openjdk.java.net Fri Sep 17 11:06:54 2021 From: duke at openjdk.java.net (duke) Date: Fri, 17 Sep 2021 11:06:54 GMT Subject: git: openjdk/panama-foreign: foreign-jextract: 89 new changesets Message-ID: <2728997d-71d4-4f01-8879-011cc5f15511@openjdk.org> Changeset: 4e6de5f9 Author: kabutz Committer: Claes Redestad Date: 2021-09-10 14:13:59 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4e6de5f9defc031158e027bcbbaf6232b8c03d60 8273541: Cleaner Thread creates with normal priority instead of MAX_PRIORITY - 2 Reviewed-by: shade, alanb, lancea ! src/java.base/share/classes/jdk/internal/ref/CleanerImpl.java Changeset: c464f090 Author: Aleksei Efimov Date: 2021-09-10 14:15:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c464f09056c239f701b400a5c59c54646f840391 8273402: Use derived NamingExceptions in com.sun.jndi.ldap.Connection#readReply Reviewed-by: dfuchs ! src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java ! src/java.naming/share/classes/com/sun/jndi/ldap/LdapRequest.java ! test/jdk/com/sun/jndi/ldap/NamingExceptionMessageTest.java Changeset: a37254c7 Author: Andy Herrick Date: 2021-09-09 19:31:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a37254c79fa5973465d90f4b52ab88fe68016c9f 8271868: Warn user when using mac-sign option with unsigned app-image. Reviewed-by: asemenyuk ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacAppBundler.java ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacAppImageBuilder.java ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacBaseInstallerBundler.java ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacPkgBundler.java ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources.properties ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources_ja.properties ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources_zh_CN.properties ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/AppImageFile.java ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/StandardBundlerParam.java Changeset: 4afbcaf5 Author: Andy Herrick Date: 2021-09-10 14:17:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4afbcaf55383ec2f5da53282a1547bac3d099e9d 8273592: Backout JDK-8271868 Reviewed-by: kcr, asemenyuk ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacAppBundler.java ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacAppImageBuilder.java ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacBaseInstallerBundler.java ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacPkgBundler.java ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources.properties ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources_ja.properties ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources_zh_CN.properties ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/AppImageFile.java ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/StandardBundlerParam.java Changeset: 695b434b Author: Daniel D. Daugherty Date: 2021-09-10 14:34:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/695b434b442cd616aa598f3a2bb3b69535488d5e Merge Changeset: 461a467f Author: Coleen Phillimore Date: 2021-09-10 14:54:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/461a467f91ba19ae35d7833b7d3e74f62f52e19c 8273456: Do not hold ttyLock around stack walking Reviewed-by: dholmes, eosterlund ! src/hotspot/share/prims/whitebox.cpp ! src/hotspot/share/runtime/deoptimization.cpp ! src/hotspot/share/runtime/deoptimization.hpp ! src/hotspot/share/runtime/mutex.hpp ! test/hotspot/jtreg/compiler/uncommontrap/TestDeoptOOM.java Changeset: e58c12e6 Author: Sandhya Viswanathan Date: 2021-09-10 15:39:48 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e58c12e61828485bfffbc9d1b865302b93a94158 8273512: Fix the copyright header of x86 macroAssembler files Reviewed-by: dholmes, thartmann ! src/hotspot/cpu/aarch64/macroAssembler_aarch64_log.cpp ! src/hotspot/cpu/x86/macroAssembler_x86_adler.cpp ! src/hotspot/cpu/x86/macroAssembler_x86_aes.cpp ! src/hotspot/cpu/x86/macroAssembler_x86_arrayCopy_avx3.cpp ! src/hotspot/cpu/x86/macroAssembler_x86_cos.cpp ! src/hotspot/cpu/x86/macroAssembler_x86_exp.cpp ! src/hotspot/cpu/x86/macroAssembler_x86_log.cpp ! src/hotspot/cpu/x86/macroAssembler_x86_log10.cpp ! src/hotspot/cpu/x86/macroAssembler_x86_pow.cpp ! src/hotspot/cpu/x86/macroAssembler_x86_sha.cpp ! src/hotspot/cpu/x86/macroAssembler_x86_sin.cpp ! src/hotspot/cpu/x86/macroAssembler_x86_tan.cpp Changeset: efe3ed1e Author: Phil Race Date: 2021-09-10 16:36:06 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/efe3ed1e705a6f3785761e64f7187de809daa731 8273358: macOS Monterey does not have the font Times needed by Serif Reviewed-by: kizune, aivanov ! src/java.desktop/macosx/classes/sun/font/CFontManager.java + test/jdk/java/awt/FontClass/LogicalFontsTest.java Changeset: 81d2acee Author: Naoto Sato Date: 2021-09-10 16:36:57 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/81d2acee57188a4507c798b46b0bd129dc302fec 8273369: Computing micros between two instants unexpectedly overflows for some cases Reviewed-by: lancea, rriggs, joehw ! src/java.base/share/classes/java/time/Instant.java ! src/java.base/share/classes/java/time/LocalTime.java ! test/jdk/java/time/test/java/time/TestInstant.java Changeset: ec9d1beb Author: Mandy Chung Date: 2021-09-10 17:17:31 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ec9d1bebd772b3ca4ad3e0654cb4833c72ee238a 8273194: Document the two possible cases when Lookup::ensureInitialized returns Reviewed-by: alanb ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java Changeset: d4177a98 Author: Jim Laskey Date: 2021-09-10 17:58:33 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d4177a98c1a3d331033f4cbad8c7af184cd5d486 8273351: bad tag in jdk.random module-info.java Reviewed-by: rriggs, bpb ! src/jdk.random/share/classes/module-info.java Changeset: 5e1df2c7 Author: Jim Laskey Date: 2021-09-10 18:03:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5e1df2c7d71e9393beaa4fd2d8812b065d053392 8273162: AbstractSplittableWithBrineGenerator does not create a random salt Reviewed-by: rriggs, bpb ! src/java.base/share/classes/jdk/internal/util/random/RandomSupport.java Changeset: f690a01f Author: jovanstevanovic Committer: Joe Wang Date: 2021-09-10 19:13:20 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f690a01f1e5de4ace39aefad656cb7c99f9ec4e1 8273278: Support XSLT on GraalVM Native Image--deterministic bytecode generation in XSLT Reviewed-by: joehw ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/LiteralElement.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Mode.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Number.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/MethodGenerator.java Changeset: e4cd2097 Author: Coleen Phillimore Date: 2021-09-10 19:23:58 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e4cd2097a56df20da07a2b5c70838431b42c9a73 8273611: Remove unused ProfilePrint_lock Reviewed-by: iklam ! src/hotspot/share/runtime/mutexLocker.cpp ! src/hotspot/share/runtime/mutexLocker.hpp Changeset: f42b9279 Author: Pavel Rappo Date: 2021-09-10 19:33:54 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f42b92790a6977ff17869762cd90a58cddccb8be 8273609: Fix trivial doc typos in the compiler area Reviewed-by: rriggs, vromero, iris ! src/java.compiler/share/classes/javax/annotation/processing/ProcessingEnvironment.java ! src/java.compiler/share/classes/javax/lang/model/util/Elements.java ! src/java.compiler/share/classes/javax/tools/JavaFileManager.java ! src/jdk.compiler/share/classes/com/sun/source/doctree/DocTree.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/tools/javac/launcher/Main.java Changeset: 922e86f4 Author: Ioi Lam Date: 2021-09-10 22:45:26 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/922e86f4ff28c7b17af8e7b5867a40fc76b7fdd7 8273522: Rename test property vm.cds.archived.java.heap to vm.cds.write.archived.java.heap Reviewed-by: minqi, ccheung, mseledtsov ! src/hotspot/share/cds/heapShared.hpp ! src/hotspot/share/prims/whitebox.cpp ! test/hotspot/jtreg/TEST.ROOT ! test/hotspot/jtreg/runtime/cds/SharedStrings.java ! test/hotspot/jtreg/runtime/cds/SharedStringsDedup.java ! test/hotspot/jtreg/runtime/cds/SharedStringsRunAuto.java ! test/hotspot/jtreg/runtime/cds/appcds/CommandLineFlagCombo.java ! test/hotspot/jtreg/runtime/cds/appcds/cacheObject/ArchivedIntegerCacheTest.java ! test/hotspot/jtreg/runtime/cds/appcds/cacheObject/ArchivedModuleComboTest.java ! test/hotspot/jtreg/runtime/cds/appcds/cacheObject/ArchivedModuleCompareTest.java ! test/hotspot/jtreg/runtime/cds/appcds/cacheObject/ArchivedModuleWithCustomImageTest.java ! test/hotspot/jtreg/runtime/cds/appcds/cacheObject/CheckCachedMirrorTest.java ! test/hotspot/jtreg/runtime/cds/appcds/cacheObject/DifferentHeapSizes.java ! test/hotspot/jtreg/runtime/cds/appcds/cacheObject/DumpTimeVerifyFailure.java ! test/hotspot/jtreg/runtime/cds/appcds/cacheObject/GCStressTest.java ! test/hotspot/jtreg/runtime/cds/appcds/cacheObject/HeapFragmentationTest.java ! test/hotspot/jtreg/runtime/cds/appcds/cacheObject/MirrorWithReferenceFieldsTest.java ! test/hotspot/jtreg/runtime/cds/appcds/cacheObject/OpenArchiveRegion.java ! test/hotspot/jtreg/runtime/cds/appcds/cacheObject/PrimitiveTypesTest.java ! test/hotspot/jtreg/runtime/cds/appcds/cacheObject/RedefineClassTest.java ! test/hotspot/jtreg/runtime/cds/appcds/javaldr/ExceptionDuringDumpAtObjectsInitPhase.java ! test/hotspot/jtreg/runtime/cds/appcds/javaldr/GCSharedStringsDuringDump.java ! test/hotspot/jtreg/runtime/cds/appcds/javaldr/HumongousDuringDump.java ! test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/ExerciseGC.java ! test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/FlagCombo.java ! test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/IncompatibleOptions.java ! test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/InternSharedString.java ! test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/InvalidFileFormat.java ! test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/LargePages.java ! test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/LockSharedStrings.java ! test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/SharedStringsBasic.java ! test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/SharedStringsBasicPlus.java ! test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/SharedStringsHumongous.java ! test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/SharedStringsStress.java ! test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/SharedStringsWbTest.java ! test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/SysDictCrash.java ! test/hotspot/jtreg/runtime/cds/serviceability/ReplaceCriticalClassesForSubgraphs.java ! test/jtreg-ext/requires/VMProps.java ! test/lib/jdk/test/whitebox/WhiteBox.java ! test/lib/sun/hotspot/WhiteBox.java Changeset: f189dff5 Author: Ao Qi Committer: Jie Fu Date: 2021-09-10 23:13:18 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f189dff5cbd4d47e1b2f3c0e5f2c866a7effccdf 8273595: tools/jpackage tests do not work on apt-based Linux distros like Debian Co-authored-by: Sun Xu Reviewed-by: asemenyuk, herrick ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/PackageType.java ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/TKit.java Changeset: 2ee1f96c Author: Andrey Turbanov Committer: Aleksei Efimov Date: 2021-09-12 13:48:24 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2ee1f96c14b80b63a29445629b1f2e1caf88e075 8273484: Cleanup unnecessary null comparison before instanceof check in java.naming Reviewed-by: aefimov, dfuchs ! src/java.naming/share/classes/com/sun/jndi/ldap/LdapReferralContext.java ! src/java.naming/share/classes/com/sun/jndi/ldap/SimpleClientId.java ! src/java.naming/share/classes/com/sun/jndi/ldap/pool/ConnectionDesc.java ! src/java.naming/share/classes/com/sun/jndi/toolkit/ctx/AtomicContext.java ! src/java.naming/share/classes/javax/naming/BinaryRefAddr.java ! src/java.naming/share/classes/javax/naming/CompositeName.java ! src/java.naming/share/classes/javax/naming/CompoundName.java ! src/java.naming/share/classes/javax/naming/LinkRef.java ! src/java.naming/share/classes/javax/naming/NameImpl.java ! src/java.naming/share/classes/javax/naming/RefAddr.java ! src/java.naming/share/classes/javax/naming/Reference.java ! src/java.naming/share/classes/javax/naming/directory/BasicAttribute.java ! src/java.naming/share/classes/javax/naming/directory/BasicAttributes.java Changeset: 9f86082f Author: Ioi Lam Date: 2021-09-13 01:57:04 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9f86082fd5174b4543eb6abc0879690430208ba0 8273610: LogTestFixture::restore_config() should not restore options Reviewed-by: ysuenaga, dholmes ! test/hotspot/gtest/logging/logTestFixture.cpp Changeset: a73c06de Author: Yi Yang Date: 2021-09-13 02:10:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a73c06de2ac47033503189140c0f8ee61fcbceae 8273021: C2: Improve Add and Xor ideal optimizations Co-authored-by: yulei Reviewed-by: thartmann, kvn ! src/hotspot/share/opto/addnode.cpp ! src/hotspot/share/opto/addnode.hpp + test/hotspot/jtreg/compiler/c2/TestAddXorIdeal.java Changeset: 4efcd200 Author: Prasanta Sadhukhan Date: 2021-09-13 04:44:01 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4efcd2006f00a6347987ecdacd6e09d59a0006f4 8273478: [macos11] JTabbedPane selected and pressed tab is not legible Reviewed-by: kizune, aivanov, serb ! src/java.desktop/macosx/classes/com/apple/laf/AquaLookAndFeel.java Changeset: b0d04976 Author: Jan Lahoda Date: 2021-09-13 09:24:06 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b0d04976bd334f840cb91e3f6dfa2ea680948a39 8273584: TypeElement.getSuperclass crashes for a record TypeElement when j.l.Record is not available Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java + test/langtools/tools/javac/records/RecordsErrorRecovery.java Changeset: 261cb44b Author: Jie Fu Date: 2021-09-13 12:10:56 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/261cb44b13e5910180a2599ca756eb7ae6f9c443 8273629: compiler/uncommontrap/TestDeoptOOM.java fails with release VMs Reviewed-by: shade ! test/hotspot/jtreg/compiler/uncommontrap/TestDeoptOOM.java Changeset: f9b2507f Author: Zhengyu Gu Date: 2021-09-13 12:23:12 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f9b2507f3e86bcb91e8ccfd0a84f31712fd535c2 8271834: TestStringDeduplicationAgeThreshold intermittent failures on Shenandoah Reviewed-by: shade, pliden ! test/hotspot/jtreg/gc/stringdedup/TestStringDeduplicationTools.java Changeset: 4cfa230e Author: Naoto Sato Date: 2021-09-13 16:06:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4cfa230e2daac118f21c7d8996d48a1a15d87a62 8273259: Character.getName doesn't follow Unicode spec for ideographs Reviewed-by: bpb, lancea, iris, darcy ! src/java.base/share/classes/java/lang/Character.java Changeset: 7c26ddb5 Author: Mikhailo Seledtsov Date: 2021-09-13 17:36:23 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7c26ddb575bb6f1161850c31a933d154ae8b96e3 8195809: [TESTBUG] jps and jcmd -l support for containers is not tested Reviewed-by: hseigel, kevinw + test/hotspot/jtreg/containers/docker/TestJcmd.java ! test/hotspot/jtreg/containers/docker/TestJcmdWithSideCar.java ! test/lib/jdk/test/lib/containers/docker/DockerfileConfig.java Changeset: b4b12101 Author: Pavel Rappo Date: 2021-09-13 17:46:13 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b4b121018d16e531f3a51ff75ae37fdc374d530b 8273616: Fix trivial doc typos in the java.base module Reviewed-by: jrose, iris, lancea, dfuchs, rriggs ! src/java.base/share/classes/java/io/CharArrayReader.java ! src/java.base/share/classes/java/io/CharArrayWriter.java ! src/java.base/share/classes/java/io/File.java ! src/java.base/share/classes/java/io/FileCleanable.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/lang/AbstractStringBuilder.java ! src/java.base/share/classes/java/lang/Character.java ! src/java.base/share/classes/java/lang/ClassLoader.java ! src/java.base/share/classes/java/lang/Process.java ! src/java.base/share/classes/java/lang/Throwable.java ! src/java.base/share/classes/java/lang/invoke/BootstrapCallInfo.java ! src/java.base/share/classes/java/lang/invoke/MethodHandle.java ! src/java.base/share/classes/java/lang/invoke/SerializedLambda.java ! src/java.base/share/classes/java/lang/invoke/VarHandle.java ! src/java.base/share/classes/java/net/ContentHandler.java ! src/java.base/share/classes/java/net/CookieManager.java ! src/java.base/share/classes/java/net/DatagramSocket.java ! src/java.base/share/classes/java/net/HttpCookie.java ! src/java.base/share/classes/java/net/Inet4Address.java ! src/java.base/share/classes/java/net/Inet6Address.java ! src/java.base/share/classes/java/net/InetAddress.java ! src/java.base/share/classes/java/net/Proxy.java ! src/java.base/share/classes/java/net/ProxySelector.java ! src/java.base/share/classes/java/net/SocketPermission.java ! src/java.base/share/classes/java/nio/charset/CoderResult.java ! src/java.base/share/classes/java/nio/file/FileSystem.java ! src/java.base/share/classes/java/nio/file/Files.java ! src/java.base/share/classes/java/nio/file/SecureDirectoryStream.java ! src/java.base/share/classes/java/nio/file/attribute/UserDefinedFileAttributeView.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/util/Currency.java ! src/java.base/share/classes/java/util/Properties.java Changeset: 6cf5079d Author: Brian Burkhalter Date: 2021-09-13 17:50:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6cf5079d8e789c82646a3e16b1763e2c7646d400 8273513: Make java.io.FilterInputStream specification more precise about overrides Reviewed-by: dfuchs, naoto ! src/java.base/share/classes/java/io/FilterInputStream.java Changeset: fc0f8542 Author: Weijun Wang Date: 2021-09-13 18:05:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fc0f8542c387e7f25992cc7eaa2bb45aeace3c39 8246797: A convenient method to read OPTIONAL element Reviewed-by: jnimeh, valeriep ! src/java.base/share/classes/com/sun/crypto/provider/OAEPParameters.java ! src/java.base/share/classes/com/sun/crypto/provider/PBES2Parameters.java ! src/java.base/share/classes/sun/security/pkcs/PKCS7.java ! src/java.base/share/classes/sun/security/util/DerInputStream.java ! src/java.base/share/classes/sun/security/util/DerValue.java + test/jdk/com/sun/crypto/provider/AlgorithmParameters/OAEPOrder.java Changeset: 5095068d Author: Coleen Phillimore Date: 2021-09-13 20:35:19 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5095068d3ba411c56752716df8e35e4215885e1d 8273675: Remove unused Universe::_verify_in_progress flag Reviewed-by: hseigel ! src/hotspot/share/memory/universe.cpp ! src/hotspot/share/memory/universe.hpp Changeset: 3d9dc8f8 Author: Ian Graves Date: 2021-09-13 21:48:28 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3d9dc8f824abf597d9b28f456cfeb5af927221b8 8273430: Suspicious duplicate condition in java.util.regex.Grapheme#isExcludedSpacingMark Reviewed-by: naoto ! src/java.base/share/classes/java/util/regex/Grapheme.java - test/jdk/java/util/regex/GraphemeTest.java + test/jdk/java/util/regex/whitebox/GraphemeTest.java + test/jdk/java/util/regex/whitebox/java.base/java/util/regex/GraphemeTestAccessor.java Changeset: c54a918a Author: David Holmes Date: 2021-09-14 01:01:07 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c54a918a0e526403a395ad76c1dd0519be136ac7 8273691: Missing comma after 2021 in GraphemeTestAccessor.java copyright notice Reviewed-by: psandoz ! test/jdk/java/util/regex/whitebox/java.base/java/util/regex/GraphemeTestAccessor.java Changeset: 8d73ee68 Author: Yasumasa Suenaga Date: 2021-09-14 05:12:36 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8d73ee684a47fa6a10995a19a431062b54c7eb27 8273471: Add foldmultilines to UL for stdout/err Reviewed-by: dholmes, iklam ! src/hotspot/share/logging/logConfiguration.cpp ! src/hotspot/share/logging/logFileOutput.cpp ! src/hotspot/share/logging/logFileStreamOutput.cpp ! src/hotspot/share/logging/logFileStreamOutput.hpp ! src/java.base/share/man/java.1 ! test/hotspot/gtest/logging/test_logConfiguration.cpp ! test/hotspot/jtreg/runtime/logging/FoldMultilinesTest.java Changeset: 86a8e552 Author: Aleksey Shipilev Date: 2021-09-14 08:14:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/86a8e5524ddb5e25dab54b4f56cc1b9c27d0a4a6 8273486: Zero: Handle DiagnoseSyncOnValueBasedClasses VM option Reviewed-by: dholmes ! src/hotspot/cpu/zero/vm_version_zero.cpp Changeset: a1433728 Author: Aleksey Shipilev Date: 2021-09-14 08:18:21 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a143372818ffab635b0e97208be53569b159a98b 8273438: Enable parallelism in vmTestbase/metaspace/stressHierarchy tests Reviewed-by: mseledtsov, iignatyev - test/hotspot/jtreg/vmTestbase/metaspace/stressHierarchy/stressHierarchy001/TEST.properties - test/hotspot/jtreg/vmTestbase/metaspace/stressHierarchy/stressHierarchy002/TEST.properties - test/hotspot/jtreg/vmTestbase/metaspace/stressHierarchy/stressHierarchy003/TEST.properties - test/hotspot/jtreg/vmTestbase/metaspace/stressHierarchy/stressHierarchy004/TEST.properties - test/hotspot/jtreg/vmTestbase/metaspace/stressHierarchy/stressHierarchy005/TEST.properties - test/hotspot/jtreg/vmTestbase/metaspace/stressHierarchy/stressHierarchy006/TEST.properties - test/hotspot/jtreg/vmTestbase/metaspace/stressHierarchy/stressHierarchy007/TEST.properties - test/hotspot/jtreg/vmTestbase/metaspace/stressHierarchy/stressHierarchy008/TEST.properties - test/hotspot/jtreg/vmTestbase/metaspace/stressHierarchy/stressHierarchy009/TEST.properties - test/hotspot/jtreg/vmTestbase/metaspace/stressHierarchy/stressHierarchy010/TEST.properties - test/hotspot/jtreg/vmTestbase/metaspace/stressHierarchy/stressHierarchy011/TEST.properties - test/hotspot/jtreg/vmTestbase/metaspace/stressHierarchy/stressHierarchy012/TEST.properties - test/hotspot/jtreg/vmTestbase/metaspace/stressHierarchy/stressHierarchy013/TEST.properties - test/hotspot/jtreg/vmTestbase/metaspace/stressHierarchy/stressHierarchy014/TEST.properties - test/hotspot/jtreg/vmTestbase/metaspace/stressHierarchy/stressHierarchy015/TEST.properties Changeset: 1d2458db Author: Roland Westrelin Date: 2021-09-14 08:35:09 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1d2458db34ed6acdd20bb8c165b7619cdbc32f47 8266550: C2: mirror TypeOopPtr/TypeInstPtr/TypeAryPtr with TypeKlassPtr/TypeInstKlassPtr/TypeAryKlassPtr Reviewed-by: vlivanov, thartmann ! src/hotspot/share/oops/arrayKlass.cpp ! src/hotspot/share/opto/callnode.cpp ! src/hotspot/share/opto/cfgnode.cpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/doCall.cpp ! src/hotspot/share/opto/escape.cpp ! src/hotspot/share/opto/graphKit.cpp ! src/hotspot/share/opto/idealGraphPrinter.cpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/opto/memnode.cpp ! src/hotspot/share/opto/memnode.hpp ! src/hotspot/share/opto/parseHelper.cpp ! src/hotspot/share/opto/subtypenode.cpp ! src/hotspot/share/opto/type.cpp ! src/hotspot/share/opto/type.hpp ! src/hotspot/share/utilities/growableArray.hpp ! test/hotspot/jtreg/compiler/lib/ir_framework/IRNode.java ! test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestIRMatching.java Changeset: f5272899 Author: Per Liden Date: 2021-09-14 08:36:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f52728993dc8f61a537b899ed0c47d83ca594738 8273639: tests fail with "assert(_handle_mark_nesting > 1) failed: memory leak: allocating handle outside HandleMark" Reviewed-by: coleenp, dholmes ! src/hotspot/share/services/heapDumper.cpp Changeset: 38845805 Author: Per Liden Date: 2021-09-14 10:28:31 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3884580591e932536a078f4f138920dcc8139c1a 8273597: Rectify Thread::is_ConcurrentGC_thread() Reviewed-by: stefank, coleenp ! src/hotspot/share/code/nmethod.cpp ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp ! src/hotspot/share/gc/parallel/parallelScavengeHeap.hpp ! src/hotspot/share/gc/shared/concurrentGCThread.hpp ! src/hotspot/share/gc/shared/workgroup.cpp ! src/hotspot/share/gc/shared/workgroup.hpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoahUtils.cpp ! src/hotspot/share/gc/shenandoah/shenandoahWorkGroup.hpp ! src/hotspot/share/gc/z/zCollectedHeap.cpp ! src/hotspot/share/gc/z/zRuntimeWorkers.cpp ! src/hotspot/share/gc/z/zWorkers.cpp ! test/hotspot/gtest/gc/g1/test_g1BatchedGangTask.cpp ! test/hotspot/gtest/gc/g1/test_g1CardSet.cpp ! test/hotspot/gtest/gc/g1/test_stressCommitUncommit.cpp ! test/hotspot/gtest/gc/shared/test_oopStorage.cpp ! test/hotspot/gtest/gc/shared/test_oopStorage_parperf.cpp Changeset: 5bfd043e Author: Magnus Ihse Bursie Date: 2021-09-14 11:28:19 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5bfd043e16fa79a101a1bee38c59d42d4cd69a48 8273497: building.md should link to both md and html Reviewed-by: erikj, shade ! doc/building.html ! doc/building.md Changeset: ed7789d6 Author: Magnus Ihse Bursie Date: 2021-09-14 11:29:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ed7789d6a08bcf5e49907389c6c36a09e88e852a 8256977: Bump minimum GCC from 5.x to 6 for JDK Reviewed-by: erikj, shade ! make/autoconf/toolchain.m4 ! test/hotspot/gtest/unittest.hpp Changeset: 31667daa Author: Naoto Sato Date: 2021-09-14 12:46:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/31667daa50b2faf82943821ee02071d222e38268 8273491: java.util.spi.LocaleServiceProvider spec contains statement that is too strict Reviewed-by: joehw, lancea ! src/java.base/share/classes/java/util/spi/LocaleServiceProvider.java Changeset: 1d3eb147 Author: Coleen Phillimore Date: 2021-09-14 13:09:46 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1d3eb147ee7dd9b237d3cf633a5792544f8cac30 8273635: Attempting to acquire lock StackWatermark_lock/9 out of order with lock tty_lock/3 Reviewed-by: dholmes, eosterlund ! src/hotspot/share/runtime/mutex.hpp ! test/hotspot/jtreg/compiler/uncommontrap/TestDeoptOOM.java Changeset: 8974b958 Author: Coleen Phillimore Date: 2021-09-14 13:17:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8974b958866bf43d2639114b764bccbae941943f 8273730: WorkGangBarrierSync constructor unused Reviewed-by: tschatzl, eosterlund ! src/hotspot/share/gc/shared/workgroup.cpp ! src/hotspot/share/gc/shared/workgroup.hpp Changeset: fe89dd3b Author: Guoxiong Li Date: 2021-09-14 14:46:21 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fe89dd3b0d47807c7dbfe24d17f6aca152fc8908 8271254: javac generates unreachable code when using empty semicolon statement Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java ! test/langtools/tools/javac/T8022186/DeadCodeGeneratedForEmptyTryTest.java Changeset: 0f31d0fb Author: Aleksey Shipilev Date: 2021-09-14 15:49:00 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0f31d0fb2c0d5db305e75e1d61bcc44de3e77839 8273373: Zero: Cannot invoke JVM in primordial threads on Zero Reviewed-by: stuefe ! src/hotspot/os/linux/os_linux.cpp ! src/hotspot/os_cpu/linux_zero/os_linux_zero.cpp Changeset: 394ebc86 Author: Jonathan Dowland Committer: Daniel Fuchs Date: 2021-09-14 17:12:49 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/394ebc8642366bc16aedde0d7f09fe4214f14cdd 8270553: Tests should not use (real, in-use, routable) 1.1.1.1 as dummy IP value Reviewed-by: shade, dfuchs ! test/jdk/java/net/HttpURLConnection/HttpURLConWithProxy.java Changeset: 22a7191f Author: Andy Herrick Date: 2021-09-14 17:45:49 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/22a7191f700c6966c59dcd12476f01452243542b 8273040: Turning off JpAllowDowngrades (or Upgrades) Reviewed-by: asemenyuk ! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WinMsiBundler.java ! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/main.wxs ! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/overrides.wxi Changeset: e7ab3724 Author: Brian Burkhalter Date: 2021-09-14 19:12:53 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e7ab3724e79312cf76c7a8fa6befc92e9c960607 8273641: (bf) Buffer subclasses documentation contains template strings Reviewed-by: rriggs, alanb ! src/java.base/share/classes/java/nio/X-Buffer.java.template Changeset: 16c3ad1f Author: casparcwang Committer: Jie Fu Date: 2021-09-14 20:55:01 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/16c3ad1ff4d9a0e21f15656c73a96a6c143c811a 8272574: C2: assert(false) failed: Bad graph detected in build_loop_late Co-authored-by: Hui Shi Co-authored-by: Christian Hagedorn Reviewed-by: thartmann, chagedorn, kvn ! src/hotspot/share/opto/loopPredicate.cpp ! src/hotspot/share/opto/loopnode.hpp ! src/hotspot/share/opto/memnode.cpp + test/hotspot/jtreg/compiler/loopopts/TestLoopPredicateDep.java Changeset: e66bf472 Author: Leo Korinth Date: 2021-09-14 21:17:59 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e66bf472484f6873faf45d634f17b68777fdcfa6 8273414: ResourceObj::operator delete should handle nullptr in debug builds Reviewed-by: stuefe ! src/hotspot/share/memory/allocation.cpp Changeset: 6cf70f5f Author: Sergey Bylokhov Date: 2021-09-15 05:15:44 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6cf70f5f0809276904094bf8eba8786892bf034e 8273638: javax/swing/JTable/4235420/bug4235420.java fails in GTK L&F Reviewed-by: pbansal, psadhukhan, azvegint ! test/jdk/javax/swing/JTable/4235420/bug4235420.java Changeset: 1017a2c2 Author: Sergey Bylokhov Date: 2021-09-15 05:18:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1017a2c2d7ae99e0076abcfaf5e730fec3cb9c6c 8273135: java/awt/color/ICC_ColorSpace/MTTransformReplacedProfile.java crashes in liblcms.dylib with NULLSeek+0x7 Reviewed-by: aivanov, azvegint ! src/java.desktop/share/native/liblcms/cmsio0.c ! test/jdk/java/awt/color/ICC_ColorSpace/MTTransformReplacedProfile.java Changeset: febcc72a Author: Prasanta Sadhukhan Date: 2021-09-15 05:43:03 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/febcc72a549e973de4649503fc686fc520e3b3cd 8273366: [testbug] javax/swing/UIDefaults/6302464/bug6302464.java fails on macOS12 Reviewed-by: aivanov, serb ! test/jdk/javax/swing/UIDefaults/6302464/bug6302464.java Changeset: 02af541b Author: Thomas Schatzl Date: 2021-09-15 08:27:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/02af541b7427a4b74eecab9513a770026d1a8426 8273605: VM Exit does not abort concurrent mark Reviewed-by: kbarrett, sjohanss ! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp ! src/hotspot/share/gc/g1/g1ConcurrentMark.hpp ! src/hotspot/share/gc/g1/g1ConcurrentMarkThread.cpp Changeset: 92c30c94 Author: Thomas Schatzl Date: 2021-09-15 08:28:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/92c30c941be09cd43ca794b180b8a1b6f7f952e1 8273599: Remove cross_threshold method usage around GC Reviewed-by: sjohanss, ayang ! src/hotspot/share/gc/g1/g1BlockOffsetTable.cpp ! src/hotspot/share/gc/g1/g1BlockOffsetTable.hpp ! src/hotspot/share/gc/g1/g1EvacFailure.cpp ! src/hotspot/share/gc/g1/g1FullGCCompactionPoint.cpp ! src/hotspot/share/gc/g1/g1FullGCCompactionPoint.hpp ! src/hotspot/share/gc/g1/heapRegion.cpp ! src/hotspot/share/gc/g1/heapRegion.hpp ! src/hotspot/share/gc/shared/blockOffsetTable.cpp ! src/hotspot/share/gc/shared/blockOffsetTable.hpp ! src/hotspot/share/gc/shared/space.cpp ! src/hotspot/share/gc/shared/space.hpp Changeset: 8fbcc823 Author: Aleksey Shipilev Date: 2021-09-15 08:56:53 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8fbcc8239a3fc04e56ebbd287c7bb5db731977b7 8273494: Zero: Put libjvm.so into "zero" folder, not "server" Reviewed-by: ihse, sgehwolf ! make/autoconf/flags-ldflags.m4 ! make/autoconf/hotspot.m4 ! make/hotspot/HotspotCommon.gmk ! make/modules/java.base/Copy.gmk ! make/modules/java.base/Lib.gmk ! test/lib/jdk/test/lib/Platform.java Changeset: 4c673df3 Author: Sergey Tsypanov Committer: Jorn Vernee Date: 2021-09-15 11:11:15 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4c673df31e46644b21fefa51e0ea01f7d9b94856 8273656: Improve java.lang.invoke.MethodType.parameterList() and its usage Reviewed-by: jvernee, vlivanov, mchung ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java ! src/java.base/share/classes/java/lang/invoke/MethodType.java Changeset: f531b5c7 Author: Ian Graves Date: 2021-09-15 13:08:15 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f531b5c79633a12efa56c55366e0b7196350e896 8273514: java/util/DoubleStreamSums/CompensatedSums.java failure Reviewed-by: rriggs, darcy ! test/jdk/java/util/DoubleStreamSums/CompensatedSums.java Changeset: 8132bfd2 Author: Zhengyu Gu Date: 2021-09-15 13:10:13 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8132bfd23f2f7fb52e502a3e6fe488fbdb537df0 8273559: Shenandoah: Shenandoah should support multi-threaded heap dump Reviewed-by: shade, rkennke, sgehwolf ! 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/shenandoah/shenandoahRootProcessor.hpp ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.inline.hpp + test/hotspot/jtreg/gc/shenandoah/TestJcmdHeapDump.java Changeset: a3ca7702 Author: Alexey Semenyuk Date: 2021-09-15 13:22:26 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a3ca770227065aecc2df9f9c711687fd8ec5d34e 8272815: jpackage --type rpm produces an error: Invalid or unsupported type: [null] Reviewed-by: herrick, almatvee ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/Arguments.java ! test/jdk/tools/jpackage/share/jdk/jpackage/tests/ErrorTest.java Changeset: 82904246 Author: Tobias Holenstein Committer: Tobias Hartmann Date: 2021-09-15 13:58:28 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/82904246cd5af69eda96b0382b471d339bd9e204 8272771: frame::pd_ps() is not implemented on any platform Reviewed-by: shade, dholmes, thartmann ! 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/runtime/frame.hpp ! src/hotspot/share/utilities/debug.cpp Changeset: 7b2beb6b Author: Thomas Schatzl Date: 2021-09-15 15:49:15 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7b2beb6ba6df868fa8e44701f906c40bb7c407bb 8273823: Problemlist gc/stringdedup tests timing out on ZGC Reviewed-by: zgu, lkorinth ! test/hotspot/jtreg/ProblemList.txt Changeset: cbffecc6 Author: Thomas Schatzl Date: 2021-09-15 17:21:44 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/cbffecc61e4a9ac1172926ef4f20d918d73adde9 8273832: gc/shenandoah/TestJcmdHeapDump.java does not have a @requires vm.gc.shenandoah Reviewed-by: zgu ! test/hotspot/jtreg/gc/shenandoah/TestJcmdHeapDump.java Changeset: 74ffe122 Author: Serguei Spitsyn Date: 2021-09-15 20:00:21 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/74ffe12267cb3ae63072a06f50083fd0352d8049 8273575: memory leak in appendBootClassPath(), paths must be deallocated Reviewed-by: dholmes, amenkov ! src/java.instrument/share/native/libinstrument/InvocationAdapter.c Changeset: d4546b6b Author: Matthias Baesken Date: 2021-09-16 07:08:19 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d4546b6b36f9dc9ff3d626f8cfe62b62daa0de01 8273526: Extend the OSContainer API pids controller with pids.current Reviewed-by: sgehwolf, iklam ! src/hotspot/os/linux/cgroupSubsystem_linux.hpp ! src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp ! src/hotspot/os/linux/cgroupV1Subsystem_linux.hpp ! src/hotspot/os/linux/cgroupV2Subsystem_linux.cpp ! src/hotspot/os/linux/cgroupV2Subsystem_linux.hpp ! src/hotspot/os/linux/osContainer_linux.cpp ! src/hotspot/os/linux/osContainer_linux.hpp ! src/hotspot/os/linux/os_linux.cpp ! src/java.base/linux/classes/jdk/internal/platform/CgroupMetrics.java ! src/java.base/linux/classes/jdk/internal/platform/cgroupv1/CgroupV1Subsystem.java ! src/java.base/linux/classes/jdk/internal/platform/cgroupv2/CgroupV2Subsystem.java ! src/java.base/share/classes/jdk/internal/platform/Metrics.java ! test/hotspot/jtreg/containers/docker/TestMisc.java ! test/hotspot/jtreg/containers/docker/TestPids.java Changeset: 2d13fb21 Author: Aleksey Shipilev Date: 2021-09-16 07:51:17 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2d13fb21af783ebbe3dd5c2632aea11347317026 8273803: Zero: Handle "zero" variant in CommandLineOptionTest.java Reviewed-by: dholmes ! test/lib/jdk/test/lib/cli/CommandLineOptionTest.java Changeset: 46af82e5 Author: Aleksey Shipilev Date: 2021-09-16 07:52:24 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/46af82e5b0d176e340f46125f8a3bb17e56bd7b3 8273804: Platform.isTieredSupported should handle the no-compiler case Reviewed-by: dholmes ! test/lib/jdk/test/lib/Platform.java Changeset: 1c5de8b8 Author: Aleksey Shipilev Date: 2021-09-16 08:12:31 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1c5de8b86b038f5d5c313c504a8868e36fc80bde 8273807: Zero: Drop incorrect test block from compiler/startup/NumCompilerThreadsCheck.java Reviewed-by: thartmann ! test/hotspot/jtreg/compiler/startup/NumCompilerThreadsCheck.java Changeset: 99cfc160 Author: Aleksey Shipilev Date: 2021-09-16 08:22:48 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/99cfc160af119ab70fa3549711cf6948402c4df8 8273805: gc/g1/TestGCLogMessages.java test should handle non-JFR configs Reviewed-by: tschatzl, ayang ! test/hotspot/jtreg/gc/g1/TestGCLogMessages.java Changeset: 09ecb119 Author: Aleksey Shipilev Date: 2021-09-16 08:23:55 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/09ecb11927f0042ddc0c5c23d747b275ab70b36b 8273806: compiler/cpuflags/TestSSE4Disabled.java should test for CPU feature explicitly Reviewed-by: thartmann ! test/hotspot/jtreg/compiler/cpuflags/TestSSE4Disabled.java Changeset: 181292d4 Author: Aleksey Shipilev Date: 2021-09-16 08:25:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/181292d48c989e3206354cea73bec015c13a986b 8273801: Handle VMTYPE for "core" VM variant Reviewed-by: dholmes, erikj ! make/hotspot/lib/JvmFeatures.gmk Changeset: 241ac89f Author: Aleksey Shipilev Date: 2021-09-16 08:53:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/241ac89f120f9bcfef65962aa05b51b9f847c4ce 8273606: Zero: SPARC64 build fails with si_band type mismatch Reviewed-by: stuefe ! src/hotspot/os/posix/signals_posix.cpp Changeset: 14dc5178 Author: Albert Mingkun Yang Date: 2021-09-16 11:41:15 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/14dc5178cf28c60a791502b9922879371493e925 8273372: Remove scavenge trace message in psPromotionManager Reviewed-by: tschatzl, lkorinth ! src/hotspot/share/gc/parallel/psPromotionManager.cpp ! src/hotspot/share/gc/parallel/psPromotionManager.inline.hpp ! src/hotspot/share/gc/shared/referenceProcessor.cpp Changeset: c86e24d4 Author: Christian Hagedorn Date: 2021-09-16 11:57:30 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c86e24d4be1e1a26a2a8323ef7ddbab6326bbf3a 8271954: C2: assert(false) failed: Bad graph detected in build_loop_late Reviewed-by: roland, kvn ! src/hotspot/share/opto/loopPredicate.cpp ! src/hotspot/share/opto/loopnode.hpp + test/hotspot/jtreg/compiler/loopopts/TestUnswitchWithSunkNodes.java Changeset: 5e4d09c2 Author: Coleen Phillimore Date: 2021-09-16 12:01:49 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5e4d09c22921f2980f84f849eb600d2e524d0733 8273300: Check Mutex ranking during a safepoint Reviewed-by: eosterlund, dholmes, pchilanomate ! src/hotspot/share/classfile/classLoaderData.cpp ! src/hotspot/share/gc/g1/g1RegionToSpaceMapper.cpp ! src/hotspot/share/gc/g1/heapRegion.cpp ! src/hotspot/share/gc/g1/heapRegion.inline.hpp ! src/hotspot/share/gc/g1/heapRegionRemSet.cpp ! src/hotspot/share/gc/shenandoah/shenandoahCodeRoots.cpp ! src/hotspot/share/gc/shenandoah/shenandoahNMethod.inline.hpp ! src/hotspot/share/memory/universe.cpp ! src/hotspot/share/runtime/mutex.cpp ! src/hotspot/share/runtime/mutex.hpp ! src/hotspot/share/runtime/mutexLocker.cpp ! src/hotspot/share/utilities/concurrentHashTable.inline.hpp Changeset: 59b2478a Author: Roland Westrelin Date: 2021-09-16 12:02:46 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/59b2478abd7f233531262b0fa190e027a785da79 8273659: Replay compilation crashes with SIGSEGV since 8271911 Reviewed-by: kvn, dlong ! src/hotspot/share/ci/ciReplay.cpp Changeset: 7e92abe7 Author: Andrey Turbanov Committer: Aleksey Shipilev Date: 2021-09-16 15:17:28 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7e92abe7a4bd2840fed19826fbff0285732f1765 8273710: Remove redundant stream() call before forEach in jdk.jdeps Reviewed-by: dfuchs, shade ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/DepsAnalyzer.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/Graph.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/InverseDepsAnalyzer.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/JdepsConfiguration.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/JdepsTask.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/Module.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModuleAnalyzer.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModuleDotGraph.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModuleExportsAnalyzer.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModuleGraphBuilder.java Changeset: 12fa7073 Author: Calvin Cheung Date: 2021-09-16 17:32:02 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/12fa7073c58eb9f204bb60ab6192738f8aece626 8261941: Use ClassLoader for unregistered classes during -Xshare:dump Reviewed-by: iklam, minqi ! src/hotspot/share/cds/classListParser.cpp + src/hotspot/share/cds/unregisteredClasses.cpp + src/hotspot/share/cds/unregisteredClasses.hpp ! src/hotspot/share/classfile/classLoaderExt.cpp ! src/hotspot/share/classfile/classLoaderExt.hpp ! src/hotspot/share/classfile/systemDictionaryShared.cpp ! src/hotspot/share/classfile/systemDictionaryShared.hpp ! src/hotspot/share/classfile/vmClassMacros.hpp ! src/hotspot/share/classfile/vmSymbols.hpp ! src/hotspot/share/oops/instanceKlass.hpp Changeset: 9c5441c9 Author: Yumin Qi Date: 2021-09-16 17:56:07 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9c5441c9c4eea2ea4ba78ee426729bf646dc042d 8271569: Clean up the use of CDS constants and field offsets Reviewed-by: iklam, dholmes + src/hotspot/share/cds/cdsConstants.cpp + src/hotspot/share/cds/cdsConstants.hpp - src/hotspot/share/cds/cdsoffsets.cpp - src/hotspot/share/cds/cdsoffsets.hpp ! src/hotspot/share/cds/dynamicArchive.hpp ! src/hotspot/share/cds/filemap.hpp ! src/hotspot/share/include/cds.h ! src/hotspot/share/prims/whitebox.cpp ! test/lib/jdk/test/lib/cds/CDSArchiveUtils.java ! test/lib/jdk/test/whitebox/WhiteBox.java ! test/lib/sun/hotspot/WhiteBox.java Changeset: bc48a0ac Author: Volker Simonis Date: 2021-09-16 19:56:12 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bc48a0ac297b99a997482dcb59f85acc1cdb0c47 8273902: Memory leak in OopStorage due to bug in OopHandle::release() Reviewed-by: sspitsyn, coleenp ! src/hotspot/share/oops/oopHandle.inline.hpp ! src/hotspot/share/prims/jvmtiImpl.cpp Changeset: b9829044 Author: Ioi Lam Date: 2021-09-16 23:26:55 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b98290444a4594d0164d6f313c506287282d1929 8271073: Improve testing with VM option VerifyArchivedFields Reviewed-by: ccheung, minqi ! src/hotspot/share/cds/heapShared.cpp ! src/hotspot/share/gc/shared/gc_globals.hpp ! test/hotspot/jtreg/runtime/cds/appcds/TestCommon.java + test/hotspot/jtreg/runtime/cds/appcds/cacheObject/VerifyArchivedFields.java ! test/lib/jdk/test/lib/cds/CDSTestUtils.java Changeset: 8c022e2c Author: Alex Menkov Date: 2021-09-16 23:45:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8c022e2c174cca2b03e8fdf4fadad42bc11c65f1 8270434: JDI+UT: Unexpected event in JDI tests Reviewed-by: sspitsyn, kevinw ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventIterator/nextEvent/nextevent001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/methodEntryRequests/methentreq002.java ! test/hotspot/jtreg/vmTestbase/nsk/share/jdi/JDIBase.java Changeset: e07ab82e Author: Guoxiong Li Date: 2021-09-17 05:34:25 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e07ab82ee555f27921287a871ba582e0906ad45c 8273408: java.lang.AssertionError: typeSig ERROR on generated class property of record Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java + test/langtools/tools/javac/records/recordComponent/GenerateTypeProcessor.java + test/langtools/tools/javac/records/recordComponent/RecordComponentTypeTest.java Changeset: 54b45676 Author: Aleksey Shipilev Date: 2021-09-17 06:44:18 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/54b456764bedb53adb7ae3c25f64d44dd8322ada 8273880: Zero: Print warnings when unsupported intrinsics are enabled Reviewed-by: dholmes ! src/hotspot/cpu/zero/vm_version_zero.cpp Changeset: 1890d85c Author: Per Liden Date: 2021-09-17 07:51:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1890d85c0e647d3f890e3c7152f8cd2e60dfd826 8273872: ZGC: Explicitly use 2M large pages Reviewed-by: eosterlund, tschatzl, stefank ! src/hotspot/os/linux/gc/z/zPhysicalMemoryBacking_linux.cpp ! src/hotspot/share/gc/z/zArguments.cpp Changeset: 35f6f1d6 Author: Matthias Baesken Date: 2021-09-17 08:20:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/35f6f1d69f4238f16595b9b8f1d11db9e49d4cc9 8273808: Cleanup AddFontsToX11FontPath Reviewed-by: pbansal, lucy ! src/java.desktop/unix/native/common/awt/fontpath.c Changeset: e22212ca Author: duke Date: 2021-09-17 11:00:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e22212ca6a9c0deb9e8eaf3cbcc3e1a705bc3cee Automatic merge of jdk:master into master Changeset: b0283a4c Author: duke Date: 2021-09-17 11:01:04 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b0283a4c4f196ef20ea7b6f2c59cf529d6ef6bb8 Automatic merge of master into foreign-memaccess+abi Changeset: 0db1ed3f Author: duke Date: 2021-09-17 11:01:20 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0db1ed3feac2b45bac724bf400fef25c015f1913 Automatic merge of foreign-memaccess+abi into foreign-jextract From uschindler at apache.org Fri Sep 17 11:12:11 2021 From: uschindler at apache.org (Uwe Schindler) Date: Fri, 17 Sep 2021 13:12:11 +0200 Subject: [foreign] thoughts on finalizing foreign APIs In-Reply-To: <5b8fb277-c39c-ead6-eee4-c0857376a8bf@oracle.com> References: <8A394507-B2D6-4E3B-9BB4-CB11EB1D76D9@gmail.com> <5b8fb277-c39c-ead6-eee4-c0857376a8bf@oracle.com> Message-ID: <09a401d7abb4$dd2a9f60$977fde20$@apache.org> Hi, > > very interesting article. I love all the thoughts that go into > > designing such a beautiful API! > Thanks for reading! > > > > Just one question regarding the following: > > > >> we plan to move all the classes in the |jdk.incubator.foreign|package > >> under the |java.lang.foreign|package [3 > >> the-foreign- > apis/*fn:3__;Iw!!ACWV5N9M2RV99hQ!bKUfgIRJ5EkYGF5QRQKOAL_XTjMISOp > WqvUHfZGEhPJVp1yfqbIzKmxBmxyHxkTZq3EuLQE$>] > >> in the |java.base| module. > > > > Is there any reason to place it in java.base? Just asking to avoid the > > need to jigsaw 2.0 java.base with JDK 32 ;-) > > The API is rather small-ish - and I think it also has very deep > connection to the core of the platform. One main example: the > implementations for the memory access var handle *have* to be defined in > java.base. But if the API lives somewhere else (as it does now), it > becomes very difficult to deal with these, as we have to introduce an > intermediate interface (e.g. `MemorySegmentProxy`) which is used by > java.base and implemented by the other module. Doing this has > interesting ramifications: we need first to adapt all the var handles > back to take a `MemorySegment`, not a `MemorySegmentProxy` otherwise the > type mismatch will cause the var handle to be called with the `invoke` > semantics, not with the `invokeExact`; secondly, we have seen cases > where the introduction of these intermediate types was severely limiting > C2 abilities to speculate on whether access was on- or off- heap (this > is why at some point `MemorySegmentProxy` was changed from an interface > to an abstract class). > > There's just too many things to fight against if you move outside > java.base; on top of that, add that we might want, in the future, to > perhaps use Panama more in the JDK itself (e.g. to implement NIO), and > maybe use segments to implement byte buffers. If we want to have a shot > at doing any of these things, then I think it's clear(er?) that this API > belongs in java.base. I was thinking about that, too. From my previous performance tests done by Maurizio and myself, we had often the problem that it was very hard to figure out where some problems are coming from. E.g., nowadays also in JDK 17, the ResourceScope is used also inside the ByteBuffer API, so there is a lot of proxying done. Those functionalities like the scopes are so important and also affect java.base APIs (because there's changes in memory model behind it) that its really hard to put this into a separate package without wrappers and proxies everywhere. Try to read the current code around ResourceScope and how it is used in Panama, ByteBuffers or even Vector API! You could for sure implement all that stuff in java.base and only add higher level APIs in a module (like the foreign linker), but this is not much on top of the base. So I agree with Maurizio: It's for sure java.base! My final comment: Great progress in API, I am very happy... - it fits Lucene's use cases perfectly - although I am very unhappy that the migration to java.base will take until Java 19! Uwe From duke at openjdk.java.net Fri Sep 17 11:12:19 2021 From: duke at openjdk.java.net (duke) Date: Fri, 17 Sep 2021 11:12:19 GMT Subject: git: openjdk/panama-foreign: foreign-memaccess+abi: 88 new changesets Message-ID: Changeset: 4e6de5f9 Author: kabutz Committer: Claes Redestad Date: 2021-09-10 14:13:59 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4e6de5f9defc031158e027bcbbaf6232b8c03d60 8273541: Cleaner Thread creates with normal priority instead of MAX_PRIORITY - 2 Reviewed-by: shade, alanb, lancea ! src/java.base/share/classes/jdk/internal/ref/CleanerImpl.java Changeset: c464f090 Author: Aleksei Efimov Date: 2021-09-10 14:15:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c464f09056c239f701b400a5c59c54646f840391 8273402: Use derived NamingExceptions in com.sun.jndi.ldap.Connection#readReply Reviewed-by: dfuchs ! src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java ! src/java.naming/share/classes/com/sun/jndi/ldap/LdapRequest.java ! test/jdk/com/sun/jndi/ldap/NamingExceptionMessageTest.java Changeset: a37254c7 Author: Andy Herrick Date: 2021-09-09 19:31:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a37254c79fa5973465d90f4b52ab88fe68016c9f 8271868: Warn user when using mac-sign option with unsigned app-image. Reviewed-by: asemenyuk ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacAppBundler.java ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacAppImageBuilder.java ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacBaseInstallerBundler.java ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacPkgBundler.java ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources.properties ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources_ja.properties ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources_zh_CN.properties ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/AppImageFile.java ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/StandardBundlerParam.java Changeset: 4afbcaf5 Author: Andy Herrick Date: 2021-09-10 14:17:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4afbcaf55383ec2f5da53282a1547bac3d099e9d 8273592: Backout JDK-8271868 Reviewed-by: kcr, asemenyuk ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacAppBundler.java ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacAppImageBuilder.java ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacBaseInstallerBundler.java ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacPkgBundler.java ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources.properties ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources_ja.properties ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources_zh_CN.properties ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/AppImageFile.java ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/StandardBundlerParam.java Changeset: 695b434b Author: Daniel D. Daugherty Date: 2021-09-10 14:34:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/695b434b442cd616aa598f3a2bb3b69535488d5e Merge Changeset: 461a467f Author: Coleen Phillimore Date: 2021-09-10 14:54:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/461a467f91ba19ae35d7833b7d3e74f62f52e19c 8273456: Do not hold ttyLock around stack walking Reviewed-by: dholmes, eosterlund ! src/hotspot/share/prims/whitebox.cpp ! src/hotspot/share/runtime/deoptimization.cpp ! src/hotspot/share/runtime/deoptimization.hpp ! src/hotspot/share/runtime/mutex.hpp ! test/hotspot/jtreg/compiler/uncommontrap/TestDeoptOOM.java Changeset: e58c12e6 Author: Sandhya Viswanathan Date: 2021-09-10 15:39:48 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e58c12e61828485bfffbc9d1b865302b93a94158 8273512: Fix the copyright header of x86 macroAssembler files Reviewed-by: dholmes, thartmann ! src/hotspot/cpu/aarch64/macroAssembler_aarch64_log.cpp ! src/hotspot/cpu/x86/macroAssembler_x86_adler.cpp ! src/hotspot/cpu/x86/macroAssembler_x86_aes.cpp ! src/hotspot/cpu/x86/macroAssembler_x86_arrayCopy_avx3.cpp ! src/hotspot/cpu/x86/macroAssembler_x86_cos.cpp ! src/hotspot/cpu/x86/macroAssembler_x86_exp.cpp ! src/hotspot/cpu/x86/macroAssembler_x86_log.cpp ! src/hotspot/cpu/x86/macroAssembler_x86_log10.cpp ! src/hotspot/cpu/x86/macroAssembler_x86_pow.cpp ! src/hotspot/cpu/x86/macroAssembler_x86_sha.cpp ! src/hotspot/cpu/x86/macroAssembler_x86_sin.cpp ! src/hotspot/cpu/x86/macroAssembler_x86_tan.cpp Changeset: efe3ed1e Author: Phil Race Date: 2021-09-10 16:36:06 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/efe3ed1e705a6f3785761e64f7187de809daa731 8273358: macOS Monterey does not have the font Times needed by Serif Reviewed-by: kizune, aivanov ! src/java.desktop/macosx/classes/sun/font/CFontManager.java + test/jdk/java/awt/FontClass/LogicalFontsTest.java Changeset: 81d2acee Author: Naoto Sato Date: 2021-09-10 16:36:57 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/81d2acee57188a4507c798b46b0bd129dc302fec 8273369: Computing micros between two instants unexpectedly overflows for some cases Reviewed-by: lancea, rriggs, joehw ! src/java.base/share/classes/java/time/Instant.java ! src/java.base/share/classes/java/time/LocalTime.java ! test/jdk/java/time/test/java/time/TestInstant.java Changeset: ec9d1beb Author: Mandy Chung Date: 2021-09-10 17:17:31 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ec9d1bebd772b3ca4ad3e0654cb4833c72ee238a 8273194: Document the two possible cases when Lookup::ensureInitialized returns Reviewed-by: alanb ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java Changeset: d4177a98 Author: Jim Laskey Date: 2021-09-10 17:58:33 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d4177a98c1a3d331033f4cbad8c7af184cd5d486 8273351: bad tag in jdk.random module-info.java Reviewed-by: rriggs, bpb ! src/jdk.random/share/classes/module-info.java Changeset: 5e1df2c7 Author: Jim Laskey Date: 2021-09-10 18:03:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5e1df2c7d71e9393beaa4fd2d8812b065d053392 8273162: AbstractSplittableWithBrineGenerator does not create a random salt Reviewed-by: rriggs, bpb ! src/java.base/share/classes/jdk/internal/util/random/RandomSupport.java Changeset: f690a01f Author: jovanstevanovic Committer: Joe Wang Date: 2021-09-10 19:13:20 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f690a01f1e5de4ace39aefad656cb7c99f9ec4e1 8273278: Support XSLT on GraalVM Native Image--deterministic bytecode generation in XSLT Reviewed-by: joehw ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/LiteralElement.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Mode.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Number.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/MethodGenerator.java Changeset: e4cd2097 Author: Coleen Phillimore Date: 2021-09-10 19:23:58 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e4cd2097a56df20da07a2b5c70838431b42c9a73 8273611: Remove unused ProfilePrint_lock Reviewed-by: iklam ! src/hotspot/share/runtime/mutexLocker.cpp ! src/hotspot/share/runtime/mutexLocker.hpp Changeset: f42b9279 Author: Pavel Rappo Date: 2021-09-10 19:33:54 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f42b92790a6977ff17869762cd90a58cddccb8be 8273609: Fix trivial doc typos in the compiler area Reviewed-by: rriggs, vromero, iris ! src/java.compiler/share/classes/javax/annotation/processing/ProcessingEnvironment.java ! src/java.compiler/share/classes/javax/lang/model/util/Elements.java ! src/java.compiler/share/classes/javax/tools/JavaFileManager.java ! src/jdk.compiler/share/classes/com/sun/source/doctree/DocTree.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/tools/javac/launcher/Main.java Changeset: 922e86f4 Author: Ioi Lam Date: 2021-09-10 22:45:26 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/922e86f4ff28c7b17af8e7b5867a40fc76b7fdd7 8273522: Rename test property vm.cds.archived.java.heap to vm.cds.write.archived.java.heap Reviewed-by: minqi, ccheung, mseledtsov ! src/hotspot/share/cds/heapShared.hpp ! src/hotspot/share/prims/whitebox.cpp ! test/hotspot/jtreg/TEST.ROOT ! test/hotspot/jtreg/runtime/cds/SharedStrings.java ! test/hotspot/jtreg/runtime/cds/SharedStringsDedup.java ! test/hotspot/jtreg/runtime/cds/SharedStringsRunAuto.java ! test/hotspot/jtreg/runtime/cds/appcds/CommandLineFlagCombo.java ! test/hotspot/jtreg/runtime/cds/appcds/cacheObject/ArchivedIntegerCacheTest.java ! test/hotspot/jtreg/runtime/cds/appcds/cacheObject/ArchivedModuleComboTest.java ! test/hotspot/jtreg/runtime/cds/appcds/cacheObject/ArchivedModuleCompareTest.java ! test/hotspot/jtreg/runtime/cds/appcds/cacheObject/ArchivedModuleWithCustomImageTest.java ! test/hotspot/jtreg/runtime/cds/appcds/cacheObject/CheckCachedMirrorTest.java ! test/hotspot/jtreg/runtime/cds/appcds/cacheObject/DifferentHeapSizes.java ! test/hotspot/jtreg/runtime/cds/appcds/cacheObject/DumpTimeVerifyFailure.java ! test/hotspot/jtreg/runtime/cds/appcds/cacheObject/GCStressTest.java ! test/hotspot/jtreg/runtime/cds/appcds/cacheObject/HeapFragmentationTest.java ! test/hotspot/jtreg/runtime/cds/appcds/cacheObject/MirrorWithReferenceFieldsTest.java ! test/hotspot/jtreg/runtime/cds/appcds/cacheObject/OpenArchiveRegion.java ! test/hotspot/jtreg/runtime/cds/appcds/cacheObject/PrimitiveTypesTest.java ! test/hotspot/jtreg/runtime/cds/appcds/cacheObject/RedefineClassTest.java ! test/hotspot/jtreg/runtime/cds/appcds/javaldr/ExceptionDuringDumpAtObjectsInitPhase.java ! test/hotspot/jtreg/runtime/cds/appcds/javaldr/GCSharedStringsDuringDump.java ! test/hotspot/jtreg/runtime/cds/appcds/javaldr/HumongousDuringDump.java ! test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/ExerciseGC.java ! test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/FlagCombo.java ! test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/IncompatibleOptions.java ! test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/InternSharedString.java ! test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/InvalidFileFormat.java ! test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/LargePages.java ! test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/LockSharedStrings.java ! test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/SharedStringsBasic.java ! test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/SharedStringsBasicPlus.java ! test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/SharedStringsHumongous.java ! test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/SharedStringsStress.java ! test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/SharedStringsWbTest.java ! test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/SysDictCrash.java ! test/hotspot/jtreg/runtime/cds/serviceability/ReplaceCriticalClassesForSubgraphs.java ! test/jtreg-ext/requires/VMProps.java ! test/lib/jdk/test/whitebox/WhiteBox.java ! test/lib/sun/hotspot/WhiteBox.java Changeset: f189dff5 Author: Ao Qi Committer: Jie Fu Date: 2021-09-10 23:13:18 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f189dff5cbd4d47e1b2f3c0e5f2c866a7effccdf 8273595: tools/jpackage tests do not work on apt-based Linux distros like Debian Co-authored-by: Sun Xu Reviewed-by: asemenyuk, herrick ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/PackageType.java ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/TKit.java Changeset: 2ee1f96c Author: Andrey Turbanov Committer: Aleksei Efimov Date: 2021-09-12 13:48:24 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2ee1f96c14b80b63a29445629b1f2e1caf88e075 8273484: Cleanup unnecessary null comparison before instanceof check in java.naming Reviewed-by: aefimov, dfuchs ! src/java.naming/share/classes/com/sun/jndi/ldap/LdapReferralContext.java ! src/java.naming/share/classes/com/sun/jndi/ldap/SimpleClientId.java ! src/java.naming/share/classes/com/sun/jndi/ldap/pool/ConnectionDesc.java ! src/java.naming/share/classes/com/sun/jndi/toolkit/ctx/AtomicContext.java ! src/java.naming/share/classes/javax/naming/BinaryRefAddr.java ! src/java.naming/share/classes/javax/naming/CompositeName.java ! src/java.naming/share/classes/javax/naming/CompoundName.java ! src/java.naming/share/classes/javax/naming/LinkRef.java ! src/java.naming/share/classes/javax/naming/NameImpl.java ! src/java.naming/share/classes/javax/naming/RefAddr.java ! src/java.naming/share/classes/javax/naming/Reference.java ! src/java.naming/share/classes/javax/naming/directory/BasicAttribute.java ! src/java.naming/share/classes/javax/naming/directory/BasicAttributes.java Changeset: 9f86082f Author: Ioi Lam Date: 2021-09-13 01:57:04 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9f86082fd5174b4543eb6abc0879690430208ba0 8273610: LogTestFixture::restore_config() should not restore options Reviewed-by: ysuenaga, dholmes ! test/hotspot/gtest/logging/logTestFixture.cpp Changeset: a73c06de Author: Yi Yang Date: 2021-09-13 02:10:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a73c06de2ac47033503189140c0f8ee61fcbceae 8273021: C2: Improve Add and Xor ideal optimizations Co-authored-by: yulei Reviewed-by: thartmann, kvn ! src/hotspot/share/opto/addnode.cpp ! src/hotspot/share/opto/addnode.hpp + test/hotspot/jtreg/compiler/c2/TestAddXorIdeal.java Changeset: 4efcd200 Author: Prasanta Sadhukhan Date: 2021-09-13 04:44:01 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4efcd2006f00a6347987ecdacd6e09d59a0006f4 8273478: [macos11] JTabbedPane selected and pressed tab is not legible Reviewed-by: kizune, aivanov, serb ! src/java.desktop/macosx/classes/com/apple/laf/AquaLookAndFeel.java Changeset: b0d04976 Author: Jan Lahoda Date: 2021-09-13 09:24:06 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b0d04976bd334f840cb91e3f6dfa2ea680948a39 8273584: TypeElement.getSuperclass crashes for a record TypeElement when j.l.Record is not available Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java + test/langtools/tools/javac/records/RecordsErrorRecovery.java Changeset: 261cb44b Author: Jie Fu Date: 2021-09-13 12:10:56 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/261cb44b13e5910180a2599ca756eb7ae6f9c443 8273629: compiler/uncommontrap/TestDeoptOOM.java fails with release VMs Reviewed-by: shade ! test/hotspot/jtreg/compiler/uncommontrap/TestDeoptOOM.java Changeset: f9b2507f Author: Zhengyu Gu Date: 2021-09-13 12:23:12 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f9b2507f3e86bcb91e8ccfd0a84f31712fd535c2 8271834: TestStringDeduplicationAgeThreshold intermittent failures on Shenandoah Reviewed-by: shade, pliden ! test/hotspot/jtreg/gc/stringdedup/TestStringDeduplicationTools.java Changeset: 4cfa230e Author: Naoto Sato Date: 2021-09-13 16:06:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4cfa230e2daac118f21c7d8996d48a1a15d87a62 8273259: Character.getName doesn't follow Unicode spec for ideographs Reviewed-by: bpb, lancea, iris, darcy ! src/java.base/share/classes/java/lang/Character.java Changeset: 7c26ddb5 Author: Mikhailo Seledtsov Date: 2021-09-13 17:36:23 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7c26ddb575bb6f1161850c31a933d154ae8b96e3 8195809: [TESTBUG] jps and jcmd -l support for containers is not tested Reviewed-by: hseigel, kevinw + test/hotspot/jtreg/containers/docker/TestJcmd.java ! test/hotspot/jtreg/containers/docker/TestJcmdWithSideCar.java ! test/lib/jdk/test/lib/containers/docker/DockerfileConfig.java Changeset: b4b12101 Author: Pavel Rappo Date: 2021-09-13 17:46:13 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b4b121018d16e531f3a51ff75ae37fdc374d530b 8273616: Fix trivial doc typos in the java.base module Reviewed-by: jrose, iris, lancea, dfuchs, rriggs ! src/java.base/share/classes/java/io/CharArrayReader.java ! src/java.base/share/classes/java/io/CharArrayWriter.java ! src/java.base/share/classes/java/io/File.java ! src/java.base/share/classes/java/io/FileCleanable.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/lang/AbstractStringBuilder.java ! src/java.base/share/classes/java/lang/Character.java ! src/java.base/share/classes/java/lang/ClassLoader.java ! src/java.base/share/classes/java/lang/Process.java ! src/java.base/share/classes/java/lang/Throwable.java ! src/java.base/share/classes/java/lang/invoke/BootstrapCallInfo.java ! src/java.base/share/classes/java/lang/invoke/MethodHandle.java ! src/java.base/share/classes/java/lang/invoke/SerializedLambda.java ! src/java.base/share/classes/java/lang/invoke/VarHandle.java ! src/java.base/share/classes/java/net/ContentHandler.java ! src/java.base/share/classes/java/net/CookieManager.java ! src/java.base/share/classes/java/net/DatagramSocket.java ! src/java.base/share/classes/java/net/HttpCookie.java ! src/java.base/share/classes/java/net/Inet4Address.java ! src/java.base/share/classes/java/net/Inet6Address.java ! src/java.base/share/classes/java/net/InetAddress.java ! src/java.base/share/classes/java/net/Proxy.java ! src/java.base/share/classes/java/net/ProxySelector.java ! src/java.base/share/classes/java/net/SocketPermission.java ! src/java.base/share/classes/java/nio/charset/CoderResult.java ! src/java.base/share/classes/java/nio/file/FileSystem.java ! src/java.base/share/classes/java/nio/file/Files.java ! src/java.base/share/classes/java/nio/file/SecureDirectoryStream.java ! src/java.base/share/classes/java/nio/file/attribute/UserDefinedFileAttributeView.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/util/Currency.java ! src/java.base/share/classes/java/util/Properties.java Changeset: 6cf5079d Author: Brian Burkhalter Date: 2021-09-13 17:50:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6cf5079d8e789c82646a3e16b1763e2c7646d400 8273513: Make java.io.FilterInputStream specification more precise about overrides Reviewed-by: dfuchs, naoto ! src/java.base/share/classes/java/io/FilterInputStream.java Changeset: fc0f8542 Author: Weijun Wang Date: 2021-09-13 18:05:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fc0f8542c387e7f25992cc7eaa2bb45aeace3c39 8246797: A convenient method to read OPTIONAL element Reviewed-by: jnimeh, valeriep ! src/java.base/share/classes/com/sun/crypto/provider/OAEPParameters.java ! src/java.base/share/classes/com/sun/crypto/provider/PBES2Parameters.java ! src/java.base/share/classes/sun/security/pkcs/PKCS7.java ! src/java.base/share/classes/sun/security/util/DerInputStream.java ! src/java.base/share/classes/sun/security/util/DerValue.java + test/jdk/com/sun/crypto/provider/AlgorithmParameters/OAEPOrder.java Changeset: 5095068d Author: Coleen Phillimore Date: 2021-09-13 20:35:19 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5095068d3ba411c56752716df8e35e4215885e1d 8273675: Remove unused Universe::_verify_in_progress flag Reviewed-by: hseigel ! src/hotspot/share/memory/universe.cpp ! src/hotspot/share/memory/universe.hpp Changeset: 3d9dc8f8 Author: Ian Graves Date: 2021-09-13 21:48:28 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3d9dc8f824abf597d9b28f456cfeb5af927221b8 8273430: Suspicious duplicate condition in java.util.regex.Grapheme#isExcludedSpacingMark Reviewed-by: naoto ! src/java.base/share/classes/java/util/regex/Grapheme.java - test/jdk/java/util/regex/GraphemeTest.java + test/jdk/java/util/regex/whitebox/GraphemeTest.java + test/jdk/java/util/regex/whitebox/java.base/java/util/regex/GraphemeTestAccessor.java Changeset: c54a918a Author: David Holmes Date: 2021-09-14 01:01:07 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c54a918a0e526403a395ad76c1dd0519be136ac7 8273691: Missing comma after 2021 in GraphemeTestAccessor.java copyright notice Reviewed-by: psandoz ! test/jdk/java/util/regex/whitebox/java.base/java/util/regex/GraphemeTestAccessor.java Changeset: 8d73ee68 Author: Yasumasa Suenaga Date: 2021-09-14 05:12:36 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8d73ee684a47fa6a10995a19a431062b54c7eb27 8273471: Add foldmultilines to UL for stdout/err Reviewed-by: dholmes, iklam ! src/hotspot/share/logging/logConfiguration.cpp ! src/hotspot/share/logging/logFileOutput.cpp ! src/hotspot/share/logging/logFileStreamOutput.cpp ! src/hotspot/share/logging/logFileStreamOutput.hpp ! src/java.base/share/man/java.1 ! test/hotspot/gtest/logging/test_logConfiguration.cpp ! test/hotspot/jtreg/runtime/logging/FoldMultilinesTest.java Changeset: 86a8e552 Author: Aleksey Shipilev Date: 2021-09-14 08:14:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/86a8e5524ddb5e25dab54b4f56cc1b9c27d0a4a6 8273486: Zero: Handle DiagnoseSyncOnValueBasedClasses VM option Reviewed-by: dholmes ! src/hotspot/cpu/zero/vm_version_zero.cpp Changeset: a1433728 Author: Aleksey Shipilev Date: 2021-09-14 08:18:21 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a143372818ffab635b0e97208be53569b159a98b 8273438: Enable parallelism in vmTestbase/metaspace/stressHierarchy tests Reviewed-by: mseledtsov, iignatyev - test/hotspot/jtreg/vmTestbase/metaspace/stressHierarchy/stressHierarchy001/TEST.properties - test/hotspot/jtreg/vmTestbase/metaspace/stressHierarchy/stressHierarchy002/TEST.properties - test/hotspot/jtreg/vmTestbase/metaspace/stressHierarchy/stressHierarchy003/TEST.properties - test/hotspot/jtreg/vmTestbase/metaspace/stressHierarchy/stressHierarchy004/TEST.properties - test/hotspot/jtreg/vmTestbase/metaspace/stressHierarchy/stressHierarchy005/TEST.properties - test/hotspot/jtreg/vmTestbase/metaspace/stressHierarchy/stressHierarchy006/TEST.properties - test/hotspot/jtreg/vmTestbase/metaspace/stressHierarchy/stressHierarchy007/TEST.properties - test/hotspot/jtreg/vmTestbase/metaspace/stressHierarchy/stressHierarchy008/TEST.properties - test/hotspot/jtreg/vmTestbase/metaspace/stressHierarchy/stressHierarchy009/TEST.properties - test/hotspot/jtreg/vmTestbase/metaspace/stressHierarchy/stressHierarchy010/TEST.properties - test/hotspot/jtreg/vmTestbase/metaspace/stressHierarchy/stressHierarchy011/TEST.properties - test/hotspot/jtreg/vmTestbase/metaspace/stressHierarchy/stressHierarchy012/TEST.properties - test/hotspot/jtreg/vmTestbase/metaspace/stressHierarchy/stressHierarchy013/TEST.properties - test/hotspot/jtreg/vmTestbase/metaspace/stressHierarchy/stressHierarchy014/TEST.properties - test/hotspot/jtreg/vmTestbase/metaspace/stressHierarchy/stressHierarchy015/TEST.properties Changeset: 1d2458db Author: Roland Westrelin Date: 2021-09-14 08:35:09 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1d2458db34ed6acdd20bb8c165b7619cdbc32f47 8266550: C2: mirror TypeOopPtr/TypeInstPtr/TypeAryPtr with TypeKlassPtr/TypeInstKlassPtr/TypeAryKlassPtr Reviewed-by: vlivanov, thartmann ! src/hotspot/share/oops/arrayKlass.cpp ! src/hotspot/share/opto/callnode.cpp ! src/hotspot/share/opto/cfgnode.cpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/doCall.cpp ! src/hotspot/share/opto/escape.cpp ! src/hotspot/share/opto/graphKit.cpp ! src/hotspot/share/opto/idealGraphPrinter.cpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/opto/memnode.cpp ! src/hotspot/share/opto/memnode.hpp ! src/hotspot/share/opto/parseHelper.cpp ! src/hotspot/share/opto/subtypenode.cpp ! src/hotspot/share/opto/type.cpp ! src/hotspot/share/opto/type.hpp ! src/hotspot/share/utilities/growableArray.hpp ! test/hotspot/jtreg/compiler/lib/ir_framework/IRNode.java ! test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestIRMatching.java Changeset: f5272899 Author: Per Liden Date: 2021-09-14 08:36:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f52728993dc8f61a537b899ed0c47d83ca594738 8273639: tests fail with "assert(_handle_mark_nesting > 1) failed: memory leak: allocating handle outside HandleMark" Reviewed-by: coleenp, dholmes ! src/hotspot/share/services/heapDumper.cpp Changeset: 38845805 Author: Per Liden Date: 2021-09-14 10:28:31 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3884580591e932536a078f4f138920dcc8139c1a 8273597: Rectify Thread::is_ConcurrentGC_thread() Reviewed-by: stefank, coleenp ! src/hotspot/share/code/nmethod.cpp ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp ! src/hotspot/share/gc/parallel/parallelScavengeHeap.hpp ! src/hotspot/share/gc/shared/concurrentGCThread.hpp ! src/hotspot/share/gc/shared/workgroup.cpp ! src/hotspot/share/gc/shared/workgroup.hpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoahUtils.cpp ! src/hotspot/share/gc/shenandoah/shenandoahWorkGroup.hpp ! src/hotspot/share/gc/z/zCollectedHeap.cpp ! src/hotspot/share/gc/z/zRuntimeWorkers.cpp ! src/hotspot/share/gc/z/zWorkers.cpp ! test/hotspot/gtest/gc/g1/test_g1BatchedGangTask.cpp ! test/hotspot/gtest/gc/g1/test_g1CardSet.cpp ! test/hotspot/gtest/gc/g1/test_stressCommitUncommit.cpp ! test/hotspot/gtest/gc/shared/test_oopStorage.cpp ! test/hotspot/gtest/gc/shared/test_oopStorage_parperf.cpp Changeset: 5bfd043e Author: Magnus Ihse Bursie Date: 2021-09-14 11:28:19 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5bfd043e16fa79a101a1bee38c59d42d4cd69a48 8273497: building.md should link to both md and html Reviewed-by: erikj, shade ! doc/building.html ! doc/building.md Changeset: ed7789d6 Author: Magnus Ihse Bursie Date: 2021-09-14 11:29:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ed7789d6a08bcf5e49907389c6c36a09e88e852a 8256977: Bump minimum GCC from 5.x to 6 for JDK Reviewed-by: erikj, shade ! make/autoconf/toolchain.m4 ! test/hotspot/gtest/unittest.hpp Changeset: 31667daa Author: Naoto Sato Date: 2021-09-14 12:46:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/31667daa50b2faf82943821ee02071d222e38268 8273491: java.util.spi.LocaleServiceProvider spec contains statement that is too strict Reviewed-by: joehw, lancea ! src/java.base/share/classes/java/util/spi/LocaleServiceProvider.java Changeset: 1d3eb147 Author: Coleen Phillimore Date: 2021-09-14 13:09:46 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1d3eb147ee7dd9b237d3cf633a5792544f8cac30 8273635: Attempting to acquire lock StackWatermark_lock/9 out of order with lock tty_lock/3 Reviewed-by: dholmes, eosterlund ! src/hotspot/share/runtime/mutex.hpp ! test/hotspot/jtreg/compiler/uncommontrap/TestDeoptOOM.java Changeset: 8974b958 Author: Coleen Phillimore Date: 2021-09-14 13:17:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8974b958866bf43d2639114b764bccbae941943f 8273730: WorkGangBarrierSync constructor unused Reviewed-by: tschatzl, eosterlund ! src/hotspot/share/gc/shared/workgroup.cpp ! src/hotspot/share/gc/shared/workgroup.hpp Changeset: fe89dd3b Author: Guoxiong Li Date: 2021-09-14 14:46:21 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fe89dd3b0d47807c7dbfe24d17f6aca152fc8908 8271254: javac generates unreachable code when using empty semicolon statement Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java ! test/langtools/tools/javac/T8022186/DeadCodeGeneratedForEmptyTryTest.java Changeset: 0f31d0fb Author: Aleksey Shipilev Date: 2021-09-14 15:49:00 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0f31d0fb2c0d5db305e75e1d61bcc44de3e77839 8273373: Zero: Cannot invoke JVM in primordial threads on Zero Reviewed-by: stuefe ! src/hotspot/os/linux/os_linux.cpp ! src/hotspot/os_cpu/linux_zero/os_linux_zero.cpp Changeset: 394ebc86 Author: Jonathan Dowland Committer: Daniel Fuchs Date: 2021-09-14 17:12:49 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/394ebc8642366bc16aedde0d7f09fe4214f14cdd 8270553: Tests should not use (real, in-use, routable) 1.1.1.1 as dummy IP value Reviewed-by: shade, dfuchs ! test/jdk/java/net/HttpURLConnection/HttpURLConWithProxy.java Changeset: 22a7191f Author: Andy Herrick Date: 2021-09-14 17:45:49 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/22a7191f700c6966c59dcd12476f01452243542b 8273040: Turning off JpAllowDowngrades (or Upgrades) Reviewed-by: asemenyuk ! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WinMsiBundler.java ! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/main.wxs ! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/overrides.wxi Changeset: e7ab3724 Author: Brian Burkhalter Date: 2021-09-14 19:12:53 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e7ab3724e79312cf76c7a8fa6befc92e9c960607 8273641: (bf) Buffer subclasses documentation contains template strings Reviewed-by: rriggs, alanb ! src/java.base/share/classes/java/nio/X-Buffer.java.template Changeset: 16c3ad1f Author: casparcwang Committer: Jie Fu Date: 2021-09-14 20:55:01 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/16c3ad1ff4d9a0e21f15656c73a96a6c143c811a 8272574: C2: assert(false) failed: Bad graph detected in build_loop_late Co-authored-by: Hui Shi Co-authored-by: Christian Hagedorn Reviewed-by: thartmann, chagedorn, kvn ! src/hotspot/share/opto/loopPredicate.cpp ! src/hotspot/share/opto/loopnode.hpp ! src/hotspot/share/opto/memnode.cpp + test/hotspot/jtreg/compiler/loopopts/TestLoopPredicateDep.java Changeset: e66bf472 Author: Leo Korinth Date: 2021-09-14 21:17:59 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e66bf472484f6873faf45d634f17b68777fdcfa6 8273414: ResourceObj::operator delete should handle nullptr in debug builds Reviewed-by: stuefe ! src/hotspot/share/memory/allocation.cpp Changeset: 6cf70f5f Author: Sergey Bylokhov Date: 2021-09-15 05:15:44 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6cf70f5f0809276904094bf8eba8786892bf034e 8273638: javax/swing/JTable/4235420/bug4235420.java fails in GTK L&F Reviewed-by: pbansal, psadhukhan, azvegint ! test/jdk/javax/swing/JTable/4235420/bug4235420.java Changeset: 1017a2c2 Author: Sergey Bylokhov Date: 2021-09-15 05:18:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1017a2c2d7ae99e0076abcfaf5e730fec3cb9c6c 8273135: java/awt/color/ICC_ColorSpace/MTTransformReplacedProfile.java crashes in liblcms.dylib with NULLSeek+0x7 Reviewed-by: aivanov, azvegint ! src/java.desktop/share/native/liblcms/cmsio0.c ! test/jdk/java/awt/color/ICC_ColorSpace/MTTransformReplacedProfile.java Changeset: febcc72a Author: Prasanta Sadhukhan Date: 2021-09-15 05:43:03 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/febcc72a549e973de4649503fc686fc520e3b3cd 8273366: [testbug] javax/swing/UIDefaults/6302464/bug6302464.java fails on macOS12 Reviewed-by: aivanov, serb ! test/jdk/javax/swing/UIDefaults/6302464/bug6302464.java Changeset: 02af541b Author: Thomas Schatzl Date: 2021-09-15 08:27:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/02af541b7427a4b74eecab9513a770026d1a8426 8273605: VM Exit does not abort concurrent mark Reviewed-by: kbarrett, sjohanss ! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp ! src/hotspot/share/gc/g1/g1ConcurrentMark.hpp ! src/hotspot/share/gc/g1/g1ConcurrentMarkThread.cpp Changeset: 92c30c94 Author: Thomas Schatzl Date: 2021-09-15 08:28:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/92c30c941be09cd43ca794b180b8a1b6f7f952e1 8273599: Remove cross_threshold method usage around GC Reviewed-by: sjohanss, ayang ! src/hotspot/share/gc/g1/g1BlockOffsetTable.cpp ! src/hotspot/share/gc/g1/g1BlockOffsetTable.hpp ! src/hotspot/share/gc/g1/g1EvacFailure.cpp ! src/hotspot/share/gc/g1/g1FullGCCompactionPoint.cpp ! src/hotspot/share/gc/g1/g1FullGCCompactionPoint.hpp ! src/hotspot/share/gc/g1/heapRegion.cpp ! src/hotspot/share/gc/g1/heapRegion.hpp ! src/hotspot/share/gc/shared/blockOffsetTable.cpp ! src/hotspot/share/gc/shared/blockOffsetTable.hpp ! src/hotspot/share/gc/shared/space.cpp ! src/hotspot/share/gc/shared/space.hpp Changeset: 8fbcc823 Author: Aleksey Shipilev Date: 2021-09-15 08:56:53 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8fbcc8239a3fc04e56ebbd287c7bb5db731977b7 8273494: Zero: Put libjvm.so into "zero" folder, not "server" Reviewed-by: ihse, sgehwolf ! make/autoconf/flags-ldflags.m4 ! make/autoconf/hotspot.m4 ! make/hotspot/HotspotCommon.gmk ! make/modules/java.base/Copy.gmk ! make/modules/java.base/Lib.gmk ! test/lib/jdk/test/lib/Platform.java Changeset: 4c673df3 Author: Sergey Tsypanov Committer: Jorn Vernee Date: 2021-09-15 11:11:15 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4c673df31e46644b21fefa51e0ea01f7d9b94856 8273656: Improve java.lang.invoke.MethodType.parameterList() and its usage Reviewed-by: jvernee, vlivanov, mchung ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java ! src/java.base/share/classes/java/lang/invoke/MethodType.java Changeset: f531b5c7 Author: Ian Graves Date: 2021-09-15 13:08:15 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f531b5c79633a12efa56c55366e0b7196350e896 8273514: java/util/DoubleStreamSums/CompensatedSums.java failure Reviewed-by: rriggs, darcy ! test/jdk/java/util/DoubleStreamSums/CompensatedSums.java Changeset: 8132bfd2 Author: Zhengyu Gu Date: 2021-09-15 13:10:13 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8132bfd23f2f7fb52e502a3e6fe488fbdb537df0 8273559: Shenandoah: Shenandoah should support multi-threaded heap dump Reviewed-by: shade, rkennke, sgehwolf ! 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/shenandoah/shenandoahRootProcessor.hpp ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.inline.hpp + test/hotspot/jtreg/gc/shenandoah/TestJcmdHeapDump.java Changeset: a3ca7702 Author: Alexey Semenyuk Date: 2021-09-15 13:22:26 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a3ca770227065aecc2df9f9c711687fd8ec5d34e 8272815: jpackage --type rpm produces an error: Invalid or unsupported type: [null] Reviewed-by: herrick, almatvee ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/Arguments.java ! test/jdk/tools/jpackage/share/jdk/jpackage/tests/ErrorTest.java Changeset: 82904246 Author: Tobias Holenstein Committer: Tobias Hartmann Date: 2021-09-15 13:58:28 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/82904246cd5af69eda96b0382b471d339bd9e204 8272771: frame::pd_ps() is not implemented on any platform Reviewed-by: shade, dholmes, thartmann ! 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/runtime/frame.hpp ! src/hotspot/share/utilities/debug.cpp Changeset: 7b2beb6b Author: Thomas Schatzl Date: 2021-09-15 15:49:15 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7b2beb6ba6df868fa8e44701f906c40bb7c407bb 8273823: Problemlist gc/stringdedup tests timing out on ZGC Reviewed-by: zgu, lkorinth ! test/hotspot/jtreg/ProblemList.txt Changeset: cbffecc6 Author: Thomas Schatzl Date: 2021-09-15 17:21:44 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/cbffecc61e4a9ac1172926ef4f20d918d73adde9 8273832: gc/shenandoah/TestJcmdHeapDump.java does not have a @requires vm.gc.shenandoah Reviewed-by: zgu ! test/hotspot/jtreg/gc/shenandoah/TestJcmdHeapDump.java Changeset: 74ffe122 Author: Serguei Spitsyn Date: 2021-09-15 20:00:21 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/74ffe12267cb3ae63072a06f50083fd0352d8049 8273575: memory leak in appendBootClassPath(), paths must be deallocated Reviewed-by: dholmes, amenkov ! src/java.instrument/share/native/libinstrument/InvocationAdapter.c Changeset: d4546b6b Author: Matthias Baesken Date: 2021-09-16 07:08:19 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d4546b6b36f9dc9ff3d626f8cfe62b62daa0de01 8273526: Extend the OSContainer API pids controller with pids.current Reviewed-by: sgehwolf, iklam ! src/hotspot/os/linux/cgroupSubsystem_linux.hpp ! src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp ! src/hotspot/os/linux/cgroupV1Subsystem_linux.hpp ! src/hotspot/os/linux/cgroupV2Subsystem_linux.cpp ! src/hotspot/os/linux/cgroupV2Subsystem_linux.hpp ! src/hotspot/os/linux/osContainer_linux.cpp ! src/hotspot/os/linux/osContainer_linux.hpp ! src/hotspot/os/linux/os_linux.cpp ! src/java.base/linux/classes/jdk/internal/platform/CgroupMetrics.java ! src/java.base/linux/classes/jdk/internal/platform/cgroupv1/CgroupV1Subsystem.java ! src/java.base/linux/classes/jdk/internal/platform/cgroupv2/CgroupV2Subsystem.java ! src/java.base/share/classes/jdk/internal/platform/Metrics.java ! test/hotspot/jtreg/containers/docker/TestMisc.java ! test/hotspot/jtreg/containers/docker/TestPids.java Changeset: 2d13fb21 Author: Aleksey Shipilev Date: 2021-09-16 07:51:17 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2d13fb21af783ebbe3dd5c2632aea11347317026 8273803: Zero: Handle "zero" variant in CommandLineOptionTest.java Reviewed-by: dholmes ! test/lib/jdk/test/lib/cli/CommandLineOptionTest.java Changeset: 46af82e5 Author: Aleksey Shipilev Date: 2021-09-16 07:52:24 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/46af82e5b0d176e340f46125f8a3bb17e56bd7b3 8273804: Platform.isTieredSupported should handle the no-compiler case Reviewed-by: dholmes ! test/lib/jdk/test/lib/Platform.java Changeset: 1c5de8b8 Author: Aleksey Shipilev Date: 2021-09-16 08:12:31 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1c5de8b86b038f5d5c313c504a8868e36fc80bde 8273807: Zero: Drop incorrect test block from compiler/startup/NumCompilerThreadsCheck.java Reviewed-by: thartmann ! test/hotspot/jtreg/compiler/startup/NumCompilerThreadsCheck.java Changeset: 99cfc160 Author: Aleksey Shipilev Date: 2021-09-16 08:22:48 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/99cfc160af119ab70fa3549711cf6948402c4df8 8273805: gc/g1/TestGCLogMessages.java test should handle non-JFR configs Reviewed-by: tschatzl, ayang ! test/hotspot/jtreg/gc/g1/TestGCLogMessages.java Changeset: 09ecb119 Author: Aleksey Shipilev Date: 2021-09-16 08:23:55 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/09ecb11927f0042ddc0c5c23d747b275ab70b36b 8273806: compiler/cpuflags/TestSSE4Disabled.java should test for CPU feature explicitly Reviewed-by: thartmann ! test/hotspot/jtreg/compiler/cpuflags/TestSSE4Disabled.java Changeset: 181292d4 Author: Aleksey Shipilev Date: 2021-09-16 08:25:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/181292d48c989e3206354cea73bec015c13a986b 8273801: Handle VMTYPE for "core" VM variant Reviewed-by: dholmes, erikj ! make/hotspot/lib/JvmFeatures.gmk Changeset: 241ac89f Author: Aleksey Shipilev Date: 2021-09-16 08:53:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/241ac89f120f9bcfef65962aa05b51b9f847c4ce 8273606: Zero: SPARC64 build fails with si_band type mismatch Reviewed-by: stuefe ! src/hotspot/os/posix/signals_posix.cpp Changeset: 14dc5178 Author: Albert Mingkun Yang Date: 2021-09-16 11:41:15 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/14dc5178cf28c60a791502b9922879371493e925 8273372: Remove scavenge trace message in psPromotionManager Reviewed-by: tschatzl, lkorinth ! src/hotspot/share/gc/parallel/psPromotionManager.cpp ! src/hotspot/share/gc/parallel/psPromotionManager.inline.hpp ! src/hotspot/share/gc/shared/referenceProcessor.cpp Changeset: c86e24d4 Author: Christian Hagedorn Date: 2021-09-16 11:57:30 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c86e24d4be1e1a26a2a8323ef7ddbab6326bbf3a 8271954: C2: assert(false) failed: Bad graph detected in build_loop_late Reviewed-by: roland, kvn ! src/hotspot/share/opto/loopPredicate.cpp ! src/hotspot/share/opto/loopnode.hpp + test/hotspot/jtreg/compiler/loopopts/TestUnswitchWithSunkNodes.java Changeset: 5e4d09c2 Author: Coleen Phillimore Date: 2021-09-16 12:01:49 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5e4d09c22921f2980f84f849eb600d2e524d0733 8273300: Check Mutex ranking during a safepoint Reviewed-by: eosterlund, dholmes, pchilanomate ! src/hotspot/share/classfile/classLoaderData.cpp ! src/hotspot/share/gc/g1/g1RegionToSpaceMapper.cpp ! src/hotspot/share/gc/g1/heapRegion.cpp ! src/hotspot/share/gc/g1/heapRegion.inline.hpp ! src/hotspot/share/gc/g1/heapRegionRemSet.cpp ! src/hotspot/share/gc/shenandoah/shenandoahCodeRoots.cpp ! src/hotspot/share/gc/shenandoah/shenandoahNMethod.inline.hpp ! src/hotspot/share/memory/universe.cpp ! src/hotspot/share/runtime/mutex.cpp ! src/hotspot/share/runtime/mutex.hpp ! src/hotspot/share/runtime/mutexLocker.cpp ! src/hotspot/share/utilities/concurrentHashTable.inline.hpp Changeset: 59b2478a Author: Roland Westrelin Date: 2021-09-16 12:02:46 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/59b2478abd7f233531262b0fa190e027a785da79 8273659: Replay compilation crashes with SIGSEGV since 8271911 Reviewed-by: kvn, dlong ! src/hotspot/share/ci/ciReplay.cpp Changeset: 7e92abe7 Author: Andrey Turbanov Committer: Aleksey Shipilev Date: 2021-09-16 15:17:28 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7e92abe7a4bd2840fed19826fbff0285732f1765 8273710: Remove redundant stream() call before forEach in jdk.jdeps Reviewed-by: dfuchs, shade ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/DepsAnalyzer.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/Graph.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/InverseDepsAnalyzer.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/JdepsConfiguration.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/JdepsTask.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/Module.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModuleAnalyzer.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModuleDotGraph.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModuleExportsAnalyzer.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModuleGraphBuilder.java Changeset: 12fa7073 Author: Calvin Cheung Date: 2021-09-16 17:32:02 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/12fa7073c58eb9f204bb60ab6192738f8aece626 8261941: Use ClassLoader for unregistered classes during -Xshare:dump Reviewed-by: iklam, minqi ! src/hotspot/share/cds/classListParser.cpp + src/hotspot/share/cds/unregisteredClasses.cpp + src/hotspot/share/cds/unregisteredClasses.hpp ! src/hotspot/share/classfile/classLoaderExt.cpp ! src/hotspot/share/classfile/classLoaderExt.hpp ! src/hotspot/share/classfile/systemDictionaryShared.cpp ! src/hotspot/share/classfile/systemDictionaryShared.hpp ! src/hotspot/share/classfile/vmClassMacros.hpp ! src/hotspot/share/classfile/vmSymbols.hpp ! src/hotspot/share/oops/instanceKlass.hpp Changeset: 9c5441c9 Author: Yumin Qi Date: 2021-09-16 17:56:07 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9c5441c9c4eea2ea4ba78ee426729bf646dc042d 8271569: Clean up the use of CDS constants and field offsets Reviewed-by: iklam, dholmes + src/hotspot/share/cds/cdsConstants.cpp + src/hotspot/share/cds/cdsConstants.hpp - src/hotspot/share/cds/cdsoffsets.cpp - src/hotspot/share/cds/cdsoffsets.hpp ! src/hotspot/share/cds/dynamicArchive.hpp ! src/hotspot/share/cds/filemap.hpp ! src/hotspot/share/include/cds.h ! src/hotspot/share/prims/whitebox.cpp ! test/lib/jdk/test/lib/cds/CDSArchiveUtils.java ! test/lib/jdk/test/whitebox/WhiteBox.java ! test/lib/sun/hotspot/WhiteBox.java Changeset: bc48a0ac Author: Volker Simonis Date: 2021-09-16 19:56:12 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bc48a0ac297b99a997482dcb59f85acc1cdb0c47 8273902: Memory leak in OopStorage due to bug in OopHandle::release() Reviewed-by: sspitsyn, coleenp ! src/hotspot/share/oops/oopHandle.inline.hpp ! src/hotspot/share/prims/jvmtiImpl.cpp Changeset: b9829044 Author: Ioi Lam Date: 2021-09-16 23:26:55 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b98290444a4594d0164d6f313c506287282d1929 8271073: Improve testing with VM option VerifyArchivedFields Reviewed-by: ccheung, minqi ! src/hotspot/share/cds/heapShared.cpp ! src/hotspot/share/gc/shared/gc_globals.hpp ! test/hotspot/jtreg/runtime/cds/appcds/TestCommon.java + test/hotspot/jtreg/runtime/cds/appcds/cacheObject/VerifyArchivedFields.java ! test/lib/jdk/test/lib/cds/CDSTestUtils.java Changeset: 8c022e2c Author: Alex Menkov Date: 2021-09-16 23:45:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8c022e2c174cca2b03e8fdf4fadad42bc11c65f1 8270434: JDI+UT: Unexpected event in JDI tests Reviewed-by: sspitsyn, kevinw ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventIterator/nextEvent/nextevent001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/methodEntryRequests/methentreq002.java ! test/hotspot/jtreg/vmTestbase/nsk/share/jdi/JDIBase.java Changeset: e07ab82e Author: Guoxiong Li Date: 2021-09-17 05:34:25 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e07ab82ee555f27921287a871ba582e0906ad45c 8273408: java.lang.AssertionError: typeSig ERROR on generated class property of record Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java + test/langtools/tools/javac/records/recordComponent/GenerateTypeProcessor.java + test/langtools/tools/javac/records/recordComponent/RecordComponentTypeTest.java Changeset: 54b45676 Author: Aleksey Shipilev Date: 2021-09-17 06:44:18 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/54b456764bedb53adb7ae3c25f64d44dd8322ada 8273880: Zero: Print warnings when unsupported intrinsics are enabled Reviewed-by: dholmes ! src/hotspot/cpu/zero/vm_version_zero.cpp Changeset: 1890d85c Author: Per Liden Date: 2021-09-17 07:51:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1890d85c0e647d3f890e3c7152f8cd2e60dfd826 8273872: ZGC: Explicitly use 2M large pages Reviewed-by: eosterlund, tschatzl, stefank ! src/hotspot/os/linux/gc/z/zPhysicalMemoryBacking_linux.cpp ! src/hotspot/share/gc/z/zArguments.cpp Changeset: 35f6f1d6 Author: Matthias Baesken Date: 2021-09-17 08:20:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/35f6f1d69f4238f16595b9b8f1d11db9e49d4cc9 8273808: Cleanup AddFontsToX11FontPath Reviewed-by: pbansal, lucy ! src/java.desktop/unix/native/common/awt/fontpath.c Changeset: e22212ca Author: duke Date: 2021-09-17 11:00:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e22212ca6a9c0deb9e8eaf3cbcc3e1a705bc3cee Automatic merge of jdk:master into master Changeset: b0283a4c Author: duke Date: 2021-09-17 11:01:04 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b0283a4c4f196ef20ea7b6f2c59cf529d6ef6bb8 Automatic merge of master into foreign-memaccess+abi From duke at openjdk.java.net Fri Sep 17 11:17:55 2021 From: duke at openjdk.java.net (duke) Date: Fri, 17 Sep 2021 11:17:55 GMT Subject: git: openjdk/panama-foreign: master: 87 new changesets Message-ID: Changeset: 4e6de5f9 Author: kabutz Committer: Claes Redestad Date: 2021-09-10 14:13:59 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4e6de5f9defc031158e027bcbbaf6232b8c03d60 8273541: Cleaner Thread creates with normal priority instead of MAX_PRIORITY - 2 Reviewed-by: shade, alanb, lancea ! src/java.base/share/classes/jdk/internal/ref/CleanerImpl.java Changeset: c464f090 Author: Aleksei Efimov Date: 2021-09-10 14:15:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c464f09056c239f701b400a5c59c54646f840391 8273402: Use derived NamingExceptions in com.sun.jndi.ldap.Connection#readReply Reviewed-by: dfuchs ! src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java ! src/java.naming/share/classes/com/sun/jndi/ldap/LdapRequest.java ! test/jdk/com/sun/jndi/ldap/NamingExceptionMessageTest.java Changeset: a37254c7 Author: Andy Herrick Date: 2021-09-09 19:31:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a37254c79fa5973465d90f4b52ab88fe68016c9f 8271868: Warn user when using mac-sign option with unsigned app-image. Reviewed-by: asemenyuk ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacAppBundler.java ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacAppImageBuilder.java ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacBaseInstallerBundler.java ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacPkgBundler.java ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources.properties ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources_ja.properties ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources_zh_CN.properties ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/AppImageFile.java ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/StandardBundlerParam.java Changeset: 4afbcaf5 Author: Andy Herrick Date: 2021-09-10 14:17:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4afbcaf55383ec2f5da53282a1547bac3d099e9d 8273592: Backout JDK-8271868 Reviewed-by: kcr, asemenyuk ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacAppBundler.java ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacAppImageBuilder.java ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacBaseInstallerBundler.java ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacPkgBundler.java ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources.properties ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources_ja.properties ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources_zh_CN.properties ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/AppImageFile.java ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/StandardBundlerParam.java Changeset: 695b434b Author: Daniel D. Daugherty Date: 2021-09-10 14:34:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/695b434b442cd616aa598f3a2bb3b69535488d5e Merge Changeset: 461a467f Author: Coleen Phillimore Date: 2021-09-10 14:54:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/461a467f91ba19ae35d7833b7d3e74f62f52e19c 8273456: Do not hold ttyLock around stack walking Reviewed-by: dholmes, eosterlund ! src/hotspot/share/prims/whitebox.cpp ! src/hotspot/share/runtime/deoptimization.cpp ! src/hotspot/share/runtime/deoptimization.hpp ! src/hotspot/share/runtime/mutex.hpp ! test/hotspot/jtreg/compiler/uncommontrap/TestDeoptOOM.java Changeset: e58c12e6 Author: Sandhya Viswanathan Date: 2021-09-10 15:39:48 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e58c12e61828485bfffbc9d1b865302b93a94158 8273512: Fix the copyright header of x86 macroAssembler files Reviewed-by: dholmes, thartmann ! src/hotspot/cpu/aarch64/macroAssembler_aarch64_log.cpp ! src/hotspot/cpu/x86/macroAssembler_x86_adler.cpp ! src/hotspot/cpu/x86/macroAssembler_x86_aes.cpp ! src/hotspot/cpu/x86/macroAssembler_x86_arrayCopy_avx3.cpp ! src/hotspot/cpu/x86/macroAssembler_x86_cos.cpp ! src/hotspot/cpu/x86/macroAssembler_x86_exp.cpp ! src/hotspot/cpu/x86/macroAssembler_x86_log.cpp ! src/hotspot/cpu/x86/macroAssembler_x86_log10.cpp ! src/hotspot/cpu/x86/macroAssembler_x86_pow.cpp ! src/hotspot/cpu/x86/macroAssembler_x86_sha.cpp ! src/hotspot/cpu/x86/macroAssembler_x86_sin.cpp ! src/hotspot/cpu/x86/macroAssembler_x86_tan.cpp Changeset: efe3ed1e Author: Phil Race Date: 2021-09-10 16:36:06 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/efe3ed1e705a6f3785761e64f7187de809daa731 8273358: macOS Monterey does not have the font Times needed by Serif Reviewed-by: kizune, aivanov ! src/java.desktop/macosx/classes/sun/font/CFontManager.java + test/jdk/java/awt/FontClass/LogicalFontsTest.java Changeset: 81d2acee Author: Naoto Sato Date: 2021-09-10 16:36:57 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/81d2acee57188a4507c798b46b0bd129dc302fec 8273369: Computing micros between two instants unexpectedly overflows for some cases Reviewed-by: lancea, rriggs, joehw ! src/java.base/share/classes/java/time/Instant.java ! src/java.base/share/classes/java/time/LocalTime.java ! test/jdk/java/time/test/java/time/TestInstant.java Changeset: ec9d1beb Author: Mandy Chung Date: 2021-09-10 17:17:31 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ec9d1bebd772b3ca4ad3e0654cb4833c72ee238a 8273194: Document the two possible cases when Lookup::ensureInitialized returns Reviewed-by: alanb ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java Changeset: d4177a98 Author: Jim Laskey Date: 2021-09-10 17:58:33 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d4177a98c1a3d331033f4cbad8c7af184cd5d486 8273351: bad tag in jdk.random module-info.java Reviewed-by: rriggs, bpb ! src/jdk.random/share/classes/module-info.java Changeset: 5e1df2c7 Author: Jim Laskey Date: 2021-09-10 18:03:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5e1df2c7d71e9393beaa4fd2d8812b065d053392 8273162: AbstractSplittableWithBrineGenerator does not create a random salt Reviewed-by: rriggs, bpb ! src/java.base/share/classes/jdk/internal/util/random/RandomSupport.java Changeset: f690a01f Author: jovanstevanovic Committer: Joe Wang Date: 2021-09-10 19:13:20 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f690a01f1e5de4ace39aefad656cb7c99f9ec4e1 8273278: Support XSLT on GraalVM Native Image--deterministic bytecode generation in XSLT Reviewed-by: joehw ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/LiteralElement.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Mode.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Number.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/MethodGenerator.java Changeset: e4cd2097 Author: Coleen Phillimore Date: 2021-09-10 19:23:58 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e4cd2097a56df20da07a2b5c70838431b42c9a73 8273611: Remove unused ProfilePrint_lock Reviewed-by: iklam ! src/hotspot/share/runtime/mutexLocker.cpp ! src/hotspot/share/runtime/mutexLocker.hpp Changeset: f42b9279 Author: Pavel Rappo Date: 2021-09-10 19:33:54 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f42b92790a6977ff17869762cd90a58cddccb8be 8273609: Fix trivial doc typos in the compiler area Reviewed-by: rriggs, vromero, iris ! src/java.compiler/share/classes/javax/annotation/processing/ProcessingEnvironment.java ! src/java.compiler/share/classes/javax/lang/model/util/Elements.java ! src/java.compiler/share/classes/javax/tools/JavaFileManager.java ! src/jdk.compiler/share/classes/com/sun/source/doctree/DocTree.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/tools/javac/launcher/Main.java Changeset: 922e86f4 Author: Ioi Lam Date: 2021-09-10 22:45:26 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/922e86f4ff28c7b17af8e7b5867a40fc76b7fdd7 8273522: Rename test property vm.cds.archived.java.heap to vm.cds.write.archived.java.heap Reviewed-by: minqi, ccheung, mseledtsov ! src/hotspot/share/cds/heapShared.hpp ! src/hotspot/share/prims/whitebox.cpp ! test/hotspot/jtreg/TEST.ROOT ! test/hotspot/jtreg/runtime/cds/SharedStrings.java ! test/hotspot/jtreg/runtime/cds/SharedStringsDedup.java ! test/hotspot/jtreg/runtime/cds/SharedStringsRunAuto.java ! test/hotspot/jtreg/runtime/cds/appcds/CommandLineFlagCombo.java ! test/hotspot/jtreg/runtime/cds/appcds/cacheObject/ArchivedIntegerCacheTest.java ! test/hotspot/jtreg/runtime/cds/appcds/cacheObject/ArchivedModuleComboTest.java ! test/hotspot/jtreg/runtime/cds/appcds/cacheObject/ArchivedModuleCompareTest.java ! test/hotspot/jtreg/runtime/cds/appcds/cacheObject/ArchivedModuleWithCustomImageTest.java ! test/hotspot/jtreg/runtime/cds/appcds/cacheObject/CheckCachedMirrorTest.java ! test/hotspot/jtreg/runtime/cds/appcds/cacheObject/DifferentHeapSizes.java ! test/hotspot/jtreg/runtime/cds/appcds/cacheObject/DumpTimeVerifyFailure.java ! test/hotspot/jtreg/runtime/cds/appcds/cacheObject/GCStressTest.java ! test/hotspot/jtreg/runtime/cds/appcds/cacheObject/HeapFragmentationTest.java ! test/hotspot/jtreg/runtime/cds/appcds/cacheObject/MirrorWithReferenceFieldsTest.java ! test/hotspot/jtreg/runtime/cds/appcds/cacheObject/OpenArchiveRegion.java ! test/hotspot/jtreg/runtime/cds/appcds/cacheObject/PrimitiveTypesTest.java ! test/hotspot/jtreg/runtime/cds/appcds/cacheObject/RedefineClassTest.java ! test/hotspot/jtreg/runtime/cds/appcds/javaldr/ExceptionDuringDumpAtObjectsInitPhase.java ! test/hotspot/jtreg/runtime/cds/appcds/javaldr/GCSharedStringsDuringDump.java ! test/hotspot/jtreg/runtime/cds/appcds/javaldr/HumongousDuringDump.java ! test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/ExerciseGC.java ! test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/FlagCombo.java ! test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/IncompatibleOptions.java ! test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/InternSharedString.java ! test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/InvalidFileFormat.java ! test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/LargePages.java ! test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/LockSharedStrings.java ! test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/SharedStringsBasic.java ! test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/SharedStringsBasicPlus.java ! test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/SharedStringsHumongous.java ! test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/SharedStringsStress.java ! test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/SharedStringsWbTest.java ! test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/SysDictCrash.java ! test/hotspot/jtreg/runtime/cds/serviceability/ReplaceCriticalClassesForSubgraphs.java ! test/jtreg-ext/requires/VMProps.java ! test/lib/jdk/test/whitebox/WhiteBox.java ! test/lib/sun/hotspot/WhiteBox.java Changeset: f189dff5 Author: Ao Qi Committer: Jie Fu Date: 2021-09-10 23:13:18 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f189dff5cbd4d47e1b2f3c0e5f2c866a7effccdf 8273595: tools/jpackage tests do not work on apt-based Linux distros like Debian Co-authored-by: Sun Xu Reviewed-by: asemenyuk, herrick ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/PackageType.java ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/TKit.java Changeset: 2ee1f96c Author: Andrey Turbanov Committer: Aleksei Efimov Date: 2021-09-12 13:48:24 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2ee1f96c14b80b63a29445629b1f2e1caf88e075 8273484: Cleanup unnecessary null comparison before instanceof check in java.naming Reviewed-by: aefimov, dfuchs ! src/java.naming/share/classes/com/sun/jndi/ldap/LdapReferralContext.java ! src/java.naming/share/classes/com/sun/jndi/ldap/SimpleClientId.java ! src/java.naming/share/classes/com/sun/jndi/ldap/pool/ConnectionDesc.java ! src/java.naming/share/classes/com/sun/jndi/toolkit/ctx/AtomicContext.java ! src/java.naming/share/classes/javax/naming/BinaryRefAddr.java ! src/java.naming/share/classes/javax/naming/CompositeName.java ! src/java.naming/share/classes/javax/naming/CompoundName.java ! src/java.naming/share/classes/javax/naming/LinkRef.java ! src/java.naming/share/classes/javax/naming/NameImpl.java ! src/java.naming/share/classes/javax/naming/RefAddr.java ! src/java.naming/share/classes/javax/naming/Reference.java ! src/java.naming/share/classes/javax/naming/directory/BasicAttribute.java ! src/java.naming/share/classes/javax/naming/directory/BasicAttributes.java Changeset: 9f86082f Author: Ioi Lam Date: 2021-09-13 01:57:04 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9f86082fd5174b4543eb6abc0879690430208ba0 8273610: LogTestFixture::restore_config() should not restore options Reviewed-by: ysuenaga, dholmes ! test/hotspot/gtest/logging/logTestFixture.cpp Changeset: a73c06de Author: Yi Yang Date: 2021-09-13 02:10:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a73c06de2ac47033503189140c0f8ee61fcbceae 8273021: C2: Improve Add and Xor ideal optimizations Co-authored-by: yulei Reviewed-by: thartmann, kvn ! src/hotspot/share/opto/addnode.cpp ! src/hotspot/share/opto/addnode.hpp + test/hotspot/jtreg/compiler/c2/TestAddXorIdeal.java Changeset: 4efcd200 Author: Prasanta Sadhukhan Date: 2021-09-13 04:44:01 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4efcd2006f00a6347987ecdacd6e09d59a0006f4 8273478: [macos11] JTabbedPane selected and pressed tab is not legible Reviewed-by: kizune, aivanov, serb ! src/java.desktop/macosx/classes/com/apple/laf/AquaLookAndFeel.java Changeset: b0d04976 Author: Jan Lahoda Date: 2021-09-13 09:24:06 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b0d04976bd334f840cb91e3f6dfa2ea680948a39 8273584: TypeElement.getSuperclass crashes for a record TypeElement when j.l.Record is not available Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java + test/langtools/tools/javac/records/RecordsErrorRecovery.java Changeset: 261cb44b Author: Jie Fu Date: 2021-09-13 12:10:56 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/261cb44b13e5910180a2599ca756eb7ae6f9c443 8273629: compiler/uncommontrap/TestDeoptOOM.java fails with release VMs Reviewed-by: shade ! test/hotspot/jtreg/compiler/uncommontrap/TestDeoptOOM.java Changeset: f9b2507f Author: Zhengyu Gu Date: 2021-09-13 12:23:12 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f9b2507f3e86bcb91e8ccfd0a84f31712fd535c2 8271834: TestStringDeduplicationAgeThreshold intermittent failures on Shenandoah Reviewed-by: shade, pliden ! test/hotspot/jtreg/gc/stringdedup/TestStringDeduplicationTools.java Changeset: 4cfa230e Author: Naoto Sato Date: 2021-09-13 16:06:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4cfa230e2daac118f21c7d8996d48a1a15d87a62 8273259: Character.getName doesn't follow Unicode spec for ideographs Reviewed-by: bpb, lancea, iris, darcy ! src/java.base/share/classes/java/lang/Character.java Changeset: 7c26ddb5 Author: Mikhailo Seledtsov Date: 2021-09-13 17:36:23 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7c26ddb575bb6f1161850c31a933d154ae8b96e3 8195809: [TESTBUG] jps and jcmd -l support for containers is not tested Reviewed-by: hseigel, kevinw + test/hotspot/jtreg/containers/docker/TestJcmd.java ! test/hotspot/jtreg/containers/docker/TestJcmdWithSideCar.java ! test/lib/jdk/test/lib/containers/docker/DockerfileConfig.java Changeset: b4b12101 Author: Pavel Rappo Date: 2021-09-13 17:46:13 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b4b121018d16e531f3a51ff75ae37fdc374d530b 8273616: Fix trivial doc typos in the java.base module Reviewed-by: jrose, iris, lancea, dfuchs, rriggs ! src/java.base/share/classes/java/io/CharArrayReader.java ! src/java.base/share/classes/java/io/CharArrayWriter.java ! src/java.base/share/classes/java/io/File.java ! src/java.base/share/classes/java/io/FileCleanable.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/lang/AbstractStringBuilder.java ! src/java.base/share/classes/java/lang/Character.java ! src/java.base/share/classes/java/lang/ClassLoader.java ! src/java.base/share/classes/java/lang/Process.java ! src/java.base/share/classes/java/lang/Throwable.java ! src/java.base/share/classes/java/lang/invoke/BootstrapCallInfo.java ! src/java.base/share/classes/java/lang/invoke/MethodHandle.java ! src/java.base/share/classes/java/lang/invoke/SerializedLambda.java ! src/java.base/share/classes/java/lang/invoke/VarHandle.java ! src/java.base/share/classes/java/net/ContentHandler.java ! src/java.base/share/classes/java/net/CookieManager.java ! src/java.base/share/classes/java/net/DatagramSocket.java ! src/java.base/share/classes/java/net/HttpCookie.java ! src/java.base/share/classes/java/net/Inet4Address.java ! src/java.base/share/classes/java/net/Inet6Address.java ! src/java.base/share/classes/java/net/InetAddress.java ! src/java.base/share/classes/java/net/Proxy.java ! src/java.base/share/classes/java/net/ProxySelector.java ! src/java.base/share/classes/java/net/SocketPermission.java ! src/java.base/share/classes/java/nio/charset/CoderResult.java ! src/java.base/share/classes/java/nio/file/FileSystem.java ! src/java.base/share/classes/java/nio/file/Files.java ! src/java.base/share/classes/java/nio/file/SecureDirectoryStream.java ! src/java.base/share/classes/java/nio/file/attribute/UserDefinedFileAttributeView.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/util/Currency.java ! src/java.base/share/classes/java/util/Properties.java Changeset: 6cf5079d Author: Brian Burkhalter Date: 2021-09-13 17:50:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6cf5079d8e789c82646a3e16b1763e2c7646d400 8273513: Make java.io.FilterInputStream specification more precise about overrides Reviewed-by: dfuchs, naoto ! src/java.base/share/classes/java/io/FilterInputStream.java Changeset: fc0f8542 Author: Weijun Wang Date: 2021-09-13 18:05:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fc0f8542c387e7f25992cc7eaa2bb45aeace3c39 8246797: A convenient method to read OPTIONAL element Reviewed-by: jnimeh, valeriep ! src/java.base/share/classes/com/sun/crypto/provider/OAEPParameters.java ! src/java.base/share/classes/com/sun/crypto/provider/PBES2Parameters.java ! src/java.base/share/classes/sun/security/pkcs/PKCS7.java ! src/java.base/share/classes/sun/security/util/DerInputStream.java ! src/java.base/share/classes/sun/security/util/DerValue.java + test/jdk/com/sun/crypto/provider/AlgorithmParameters/OAEPOrder.java Changeset: 5095068d Author: Coleen Phillimore Date: 2021-09-13 20:35:19 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5095068d3ba411c56752716df8e35e4215885e1d 8273675: Remove unused Universe::_verify_in_progress flag Reviewed-by: hseigel ! src/hotspot/share/memory/universe.cpp ! src/hotspot/share/memory/universe.hpp Changeset: 3d9dc8f8 Author: Ian Graves Date: 2021-09-13 21:48:28 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3d9dc8f824abf597d9b28f456cfeb5af927221b8 8273430: Suspicious duplicate condition in java.util.regex.Grapheme#isExcludedSpacingMark Reviewed-by: naoto ! src/java.base/share/classes/java/util/regex/Grapheme.java - test/jdk/java/util/regex/GraphemeTest.java + test/jdk/java/util/regex/whitebox/GraphemeTest.java + test/jdk/java/util/regex/whitebox/java.base/java/util/regex/GraphemeTestAccessor.java Changeset: c54a918a Author: David Holmes Date: 2021-09-14 01:01:07 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c54a918a0e526403a395ad76c1dd0519be136ac7 8273691: Missing comma after 2021 in GraphemeTestAccessor.java copyright notice Reviewed-by: psandoz ! test/jdk/java/util/regex/whitebox/java.base/java/util/regex/GraphemeTestAccessor.java Changeset: 8d73ee68 Author: Yasumasa Suenaga Date: 2021-09-14 05:12:36 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8d73ee684a47fa6a10995a19a431062b54c7eb27 8273471: Add foldmultilines to UL for stdout/err Reviewed-by: dholmes, iklam ! src/hotspot/share/logging/logConfiguration.cpp ! src/hotspot/share/logging/logFileOutput.cpp ! src/hotspot/share/logging/logFileStreamOutput.cpp ! src/hotspot/share/logging/logFileStreamOutput.hpp ! src/java.base/share/man/java.1 ! test/hotspot/gtest/logging/test_logConfiguration.cpp ! test/hotspot/jtreg/runtime/logging/FoldMultilinesTest.java Changeset: 86a8e552 Author: Aleksey Shipilev Date: 2021-09-14 08:14:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/86a8e5524ddb5e25dab54b4f56cc1b9c27d0a4a6 8273486: Zero: Handle DiagnoseSyncOnValueBasedClasses VM option Reviewed-by: dholmes ! src/hotspot/cpu/zero/vm_version_zero.cpp Changeset: a1433728 Author: Aleksey Shipilev Date: 2021-09-14 08:18:21 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a143372818ffab635b0e97208be53569b159a98b 8273438: Enable parallelism in vmTestbase/metaspace/stressHierarchy tests Reviewed-by: mseledtsov, iignatyev - test/hotspot/jtreg/vmTestbase/metaspace/stressHierarchy/stressHierarchy001/TEST.properties - test/hotspot/jtreg/vmTestbase/metaspace/stressHierarchy/stressHierarchy002/TEST.properties - test/hotspot/jtreg/vmTestbase/metaspace/stressHierarchy/stressHierarchy003/TEST.properties - test/hotspot/jtreg/vmTestbase/metaspace/stressHierarchy/stressHierarchy004/TEST.properties - test/hotspot/jtreg/vmTestbase/metaspace/stressHierarchy/stressHierarchy005/TEST.properties - test/hotspot/jtreg/vmTestbase/metaspace/stressHierarchy/stressHierarchy006/TEST.properties - test/hotspot/jtreg/vmTestbase/metaspace/stressHierarchy/stressHierarchy007/TEST.properties - test/hotspot/jtreg/vmTestbase/metaspace/stressHierarchy/stressHierarchy008/TEST.properties - test/hotspot/jtreg/vmTestbase/metaspace/stressHierarchy/stressHierarchy009/TEST.properties - test/hotspot/jtreg/vmTestbase/metaspace/stressHierarchy/stressHierarchy010/TEST.properties - test/hotspot/jtreg/vmTestbase/metaspace/stressHierarchy/stressHierarchy011/TEST.properties - test/hotspot/jtreg/vmTestbase/metaspace/stressHierarchy/stressHierarchy012/TEST.properties - test/hotspot/jtreg/vmTestbase/metaspace/stressHierarchy/stressHierarchy013/TEST.properties - test/hotspot/jtreg/vmTestbase/metaspace/stressHierarchy/stressHierarchy014/TEST.properties - test/hotspot/jtreg/vmTestbase/metaspace/stressHierarchy/stressHierarchy015/TEST.properties Changeset: 1d2458db Author: Roland Westrelin Date: 2021-09-14 08:35:09 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1d2458db34ed6acdd20bb8c165b7619cdbc32f47 8266550: C2: mirror TypeOopPtr/TypeInstPtr/TypeAryPtr with TypeKlassPtr/TypeInstKlassPtr/TypeAryKlassPtr Reviewed-by: vlivanov, thartmann ! src/hotspot/share/oops/arrayKlass.cpp ! src/hotspot/share/opto/callnode.cpp ! src/hotspot/share/opto/cfgnode.cpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/doCall.cpp ! src/hotspot/share/opto/escape.cpp ! src/hotspot/share/opto/graphKit.cpp ! src/hotspot/share/opto/idealGraphPrinter.cpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/opto/memnode.cpp ! src/hotspot/share/opto/memnode.hpp ! src/hotspot/share/opto/parseHelper.cpp ! src/hotspot/share/opto/subtypenode.cpp ! src/hotspot/share/opto/type.cpp ! src/hotspot/share/opto/type.hpp ! src/hotspot/share/utilities/growableArray.hpp ! test/hotspot/jtreg/compiler/lib/ir_framework/IRNode.java ! test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestIRMatching.java Changeset: f5272899 Author: Per Liden Date: 2021-09-14 08:36:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f52728993dc8f61a537b899ed0c47d83ca594738 8273639: tests fail with "assert(_handle_mark_nesting > 1) failed: memory leak: allocating handle outside HandleMark" Reviewed-by: coleenp, dholmes ! src/hotspot/share/services/heapDumper.cpp Changeset: 38845805 Author: Per Liden Date: 2021-09-14 10:28:31 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3884580591e932536a078f4f138920dcc8139c1a 8273597: Rectify Thread::is_ConcurrentGC_thread() Reviewed-by: stefank, coleenp ! src/hotspot/share/code/nmethod.cpp ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp ! src/hotspot/share/gc/parallel/parallelScavengeHeap.hpp ! src/hotspot/share/gc/shared/concurrentGCThread.hpp ! src/hotspot/share/gc/shared/workgroup.cpp ! src/hotspot/share/gc/shared/workgroup.hpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoahUtils.cpp ! src/hotspot/share/gc/shenandoah/shenandoahWorkGroup.hpp ! src/hotspot/share/gc/z/zCollectedHeap.cpp ! src/hotspot/share/gc/z/zRuntimeWorkers.cpp ! src/hotspot/share/gc/z/zWorkers.cpp ! test/hotspot/gtest/gc/g1/test_g1BatchedGangTask.cpp ! test/hotspot/gtest/gc/g1/test_g1CardSet.cpp ! test/hotspot/gtest/gc/g1/test_stressCommitUncommit.cpp ! test/hotspot/gtest/gc/shared/test_oopStorage.cpp ! test/hotspot/gtest/gc/shared/test_oopStorage_parperf.cpp Changeset: 5bfd043e Author: Magnus Ihse Bursie Date: 2021-09-14 11:28:19 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5bfd043e16fa79a101a1bee38c59d42d4cd69a48 8273497: building.md should link to both md and html Reviewed-by: erikj, shade ! doc/building.html ! doc/building.md Changeset: ed7789d6 Author: Magnus Ihse Bursie Date: 2021-09-14 11:29:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ed7789d6a08bcf5e49907389c6c36a09e88e852a 8256977: Bump minimum GCC from 5.x to 6 for JDK Reviewed-by: erikj, shade ! make/autoconf/toolchain.m4 ! test/hotspot/gtest/unittest.hpp Changeset: 31667daa Author: Naoto Sato Date: 2021-09-14 12:46:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/31667daa50b2faf82943821ee02071d222e38268 8273491: java.util.spi.LocaleServiceProvider spec contains statement that is too strict Reviewed-by: joehw, lancea ! src/java.base/share/classes/java/util/spi/LocaleServiceProvider.java Changeset: 1d3eb147 Author: Coleen Phillimore Date: 2021-09-14 13:09:46 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1d3eb147ee7dd9b237d3cf633a5792544f8cac30 8273635: Attempting to acquire lock StackWatermark_lock/9 out of order with lock tty_lock/3 Reviewed-by: dholmes, eosterlund ! src/hotspot/share/runtime/mutex.hpp ! test/hotspot/jtreg/compiler/uncommontrap/TestDeoptOOM.java Changeset: 8974b958 Author: Coleen Phillimore Date: 2021-09-14 13:17:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8974b958866bf43d2639114b764bccbae941943f 8273730: WorkGangBarrierSync constructor unused Reviewed-by: tschatzl, eosterlund ! src/hotspot/share/gc/shared/workgroup.cpp ! src/hotspot/share/gc/shared/workgroup.hpp Changeset: fe89dd3b Author: Guoxiong Li Date: 2021-09-14 14:46:21 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fe89dd3b0d47807c7dbfe24d17f6aca152fc8908 8271254: javac generates unreachable code when using empty semicolon statement Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java ! test/langtools/tools/javac/T8022186/DeadCodeGeneratedForEmptyTryTest.java Changeset: 0f31d0fb Author: Aleksey Shipilev Date: 2021-09-14 15:49:00 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0f31d0fb2c0d5db305e75e1d61bcc44de3e77839 8273373: Zero: Cannot invoke JVM in primordial threads on Zero Reviewed-by: stuefe ! src/hotspot/os/linux/os_linux.cpp ! src/hotspot/os_cpu/linux_zero/os_linux_zero.cpp Changeset: 394ebc86 Author: Jonathan Dowland Committer: Daniel Fuchs Date: 2021-09-14 17:12:49 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/394ebc8642366bc16aedde0d7f09fe4214f14cdd 8270553: Tests should not use (real, in-use, routable) 1.1.1.1 as dummy IP value Reviewed-by: shade, dfuchs ! test/jdk/java/net/HttpURLConnection/HttpURLConWithProxy.java Changeset: 22a7191f Author: Andy Herrick Date: 2021-09-14 17:45:49 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/22a7191f700c6966c59dcd12476f01452243542b 8273040: Turning off JpAllowDowngrades (or Upgrades) Reviewed-by: asemenyuk ! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WinMsiBundler.java ! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/main.wxs ! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/overrides.wxi Changeset: e7ab3724 Author: Brian Burkhalter Date: 2021-09-14 19:12:53 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e7ab3724e79312cf76c7a8fa6befc92e9c960607 8273641: (bf) Buffer subclasses documentation contains template strings Reviewed-by: rriggs, alanb ! src/java.base/share/classes/java/nio/X-Buffer.java.template Changeset: 16c3ad1f Author: casparcwang Committer: Jie Fu Date: 2021-09-14 20:55:01 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/16c3ad1ff4d9a0e21f15656c73a96a6c143c811a 8272574: C2: assert(false) failed: Bad graph detected in build_loop_late Co-authored-by: Hui Shi Co-authored-by: Christian Hagedorn Reviewed-by: thartmann, chagedorn, kvn ! src/hotspot/share/opto/loopPredicate.cpp ! src/hotspot/share/opto/loopnode.hpp ! src/hotspot/share/opto/memnode.cpp + test/hotspot/jtreg/compiler/loopopts/TestLoopPredicateDep.java Changeset: e66bf472 Author: Leo Korinth Date: 2021-09-14 21:17:59 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e66bf472484f6873faf45d634f17b68777fdcfa6 8273414: ResourceObj::operator delete should handle nullptr in debug builds Reviewed-by: stuefe ! src/hotspot/share/memory/allocation.cpp Changeset: 6cf70f5f Author: Sergey Bylokhov Date: 2021-09-15 05:15:44 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6cf70f5f0809276904094bf8eba8786892bf034e 8273638: javax/swing/JTable/4235420/bug4235420.java fails in GTK L&F Reviewed-by: pbansal, psadhukhan, azvegint ! test/jdk/javax/swing/JTable/4235420/bug4235420.java Changeset: 1017a2c2 Author: Sergey Bylokhov Date: 2021-09-15 05:18:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1017a2c2d7ae99e0076abcfaf5e730fec3cb9c6c 8273135: java/awt/color/ICC_ColorSpace/MTTransformReplacedProfile.java crashes in liblcms.dylib with NULLSeek+0x7 Reviewed-by: aivanov, azvegint ! src/java.desktop/share/native/liblcms/cmsio0.c ! test/jdk/java/awt/color/ICC_ColorSpace/MTTransformReplacedProfile.java Changeset: febcc72a Author: Prasanta Sadhukhan Date: 2021-09-15 05:43:03 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/febcc72a549e973de4649503fc686fc520e3b3cd 8273366: [testbug] javax/swing/UIDefaults/6302464/bug6302464.java fails on macOS12 Reviewed-by: aivanov, serb ! test/jdk/javax/swing/UIDefaults/6302464/bug6302464.java Changeset: 02af541b Author: Thomas Schatzl Date: 2021-09-15 08:27:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/02af541b7427a4b74eecab9513a770026d1a8426 8273605: VM Exit does not abort concurrent mark Reviewed-by: kbarrett, sjohanss ! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp ! src/hotspot/share/gc/g1/g1ConcurrentMark.hpp ! src/hotspot/share/gc/g1/g1ConcurrentMarkThread.cpp Changeset: 92c30c94 Author: Thomas Schatzl Date: 2021-09-15 08:28:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/92c30c941be09cd43ca794b180b8a1b6f7f952e1 8273599: Remove cross_threshold method usage around GC Reviewed-by: sjohanss, ayang ! src/hotspot/share/gc/g1/g1BlockOffsetTable.cpp ! src/hotspot/share/gc/g1/g1BlockOffsetTable.hpp ! src/hotspot/share/gc/g1/g1EvacFailure.cpp ! src/hotspot/share/gc/g1/g1FullGCCompactionPoint.cpp ! src/hotspot/share/gc/g1/g1FullGCCompactionPoint.hpp ! src/hotspot/share/gc/g1/heapRegion.cpp ! src/hotspot/share/gc/g1/heapRegion.hpp ! src/hotspot/share/gc/shared/blockOffsetTable.cpp ! src/hotspot/share/gc/shared/blockOffsetTable.hpp ! src/hotspot/share/gc/shared/space.cpp ! src/hotspot/share/gc/shared/space.hpp Changeset: 8fbcc823 Author: Aleksey Shipilev Date: 2021-09-15 08:56:53 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8fbcc8239a3fc04e56ebbd287c7bb5db731977b7 8273494: Zero: Put libjvm.so into "zero" folder, not "server" Reviewed-by: ihse, sgehwolf ! make/autoconf/flags-ldflags.m4 ! make/autoconf/hotspot.m4 ! make/hotspot/HotspotCommon.gmk ! make/modules/java.base/Copy.gmk ! make/modules/java.base/Lib.gmk ! test/lib/jdk/test/lib/Platform.java Changeset: 4c673df3 Author: Sergey Tsypanov Committer: Jorn Vernee Date: 2021-09-15 11:11:15 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4c673df31e46644b21fefa51e0ea01f7d9b94856 8273656: Improve java.lang.invoke.MethodType.parameterList() and its usage Reviewed-by: jvernee, vlivanov, mchung ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java ! src/java.base/share/classes/java/lang/invoke/MethodType.java Changeset: f531b5c7 Author: Ian Graves Date: 2021-09-15 13:08:15 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f531b5c79633a12efa56c55366e0b7196350e896 8273514: java/util/DoubleStreamSums/CompensatedSums.java failure Reviewed-by: rriggs, darcy ! test/jdk/java/util/DoubleStreamSums/CompensatedSums.java Changeset: 8132bfd2 Author: Zhengyu Gu Date: 2021-09-15 13:10:13 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8132bfd23f2f7fb52e502a3e6fe488fbdb537df0 8273559: Shenandoah: Shenandoah should support multi-threaded heap dump Reviewed-by: shade, rkennke, sgehwolf ! 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/shenandoah/shenandoahRootProcessor.hpp ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.inline.hpp + test/hotspot/jtreg/gc/shenandoah/TestJcmdHeapDump.java Changeset: a3ca7702 Author: Alexey Semenyuk Date: 2021-09-15 13:22:26 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a3ca770227065aecc2df9f9c711687fd8ec5d34e 8272815: jpackage --type rpm produces an error: Invalid or unsupported type: [null] Reviewed-by: herrick, almatvee ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/Arguments.java ! test/jdk/tools/jpackage/share/jdk/jpackage/tests/ErrorTest.java Changeset: 82904246 Author: Tobias Holenstein Committer: Tobias Hartmann Date: 2021-09-15 13:58:28 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/82904246cd5af69eda96b0382b471d339bd9e204 8272771: frame::pd_ps() is not implemented on any platform Reviewed-by: shade, dholmes, thartmann ! 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/runtime/frame.hpp ! src/hotspot/share/utilities/debug.cpp Changeset: 7b2beb6b Author: Thomas Schatzl Date: 2021-09-15 15:49:15 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7b2beb6ba6df868fa8e44701f906c40bb7c407bb 8273823: Problemlist gc/stringdedup tests timing out on ZGC Reviewed-by: zgu, lkorinth ! test/hotspot/jtreg/ProblemList.txt Changeset: cbffecc6 Author: Thomas Schatzl Date: 2021-09-15 17:21:44 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/cbffecc61e4a9ac1172926ef4f20d918d73adde9 8273832: gc/shenandoah/TestJcmdHeapDump.java does not have a @requires vm.gc.shenandoah Reviewed-by: zgu ! test/hotspot/jtreg/gc/shenandoah/TestJcmdHeapDump.java Changeset: 74ffe122 Author: Serguei Spitsyn Date: 2021-09-15 20:00:21 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/74ffe12267cb3ae63072a06f50083fd0352d8049 8273575: memory leak in appendBootClassPath(), paths must be deallocated Reviewed-by: dholmes, amenkov ! src/java.instrument/share/native/libinstrument/InvocationAdapter.c Changeset: d4546b6b Author: Matthias Baesken Date: 2021-09-16 07:08:19 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d4546b6b36f9dc9ff3d626f8cfe62b62daa0de01 8273526: Extend the OSContainer API pids controller with pids.current Reviewed-by: sgehwolf, iklam ! src/hotspot/os/linux/cgroupSubsystem_linux.hpp ! src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp ! src/hotspot/os/linux/cgroupV1Subsystem_linux.hpp ! src/hotspot/os/linux/cgroupV2Subsystem_linux.cpp ! src/hotspot/os/linux/cgroupV2Subsystem_linux.hpp ! src/hotspot/os/linux/osContainer_linux.cpp ! src/hotspot/os/linux/osContainer_linux.hpp ! src/hotspot/os/linux/os_linux.cpp ! src/java.base/linux/classes/jdk/internal/platform/CgroupMetrics.java ! src/java.base/linux/classes/jdk/internal/platform/cgroupv1/CgroupV1Subsystem.java ! src/java.base/linux/classes/jdk/internal/platform/cgroupv2/CgroupV2Subsystem.java ! src/java.base/share/classes/jdk/internal/platform/Metrics.java ! test/hotspot/jtreg/containers/docker/TestMisc.java ! test/hotspot/jtreg/containers/docker/TestPids.java Changeset: 2d13fb21 Author: Aleksey Shipilev Date: 2021-09-16 07:51:17 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2d13fb21af783ebbe3dd5c2632aea11347317026 8273803: Zero: Handle "zero" variant in CommandLineOptionTest.java Reviewed-by: dholmes ! test/lib/jdk/test/lib/cli/CommandLineOptionTest.java Changeset: 46af82e5 Author: Aleksey Shipilev Date: 2021-09-16 07:52:24 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/46af82e5b0d176e340f46125f8a3bb17e56bd7b3 8273804: Platform.isTieredSupported should handle the no-compiler case Reviewed-by: dholmes ! test/lib/jdk/test/lib/Platform.java Changeset: 1c5de8b8 Author: Aleksey Shipilev Date: 2021-09-16 08:12:31 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1c5de8b86b038f5d5c313c504a8868e36fc80bde 8273807: Zero: Drop incorrect test block from compiler/startup/NumCompilerThreadsCheck.java Reviewed-by: thartmann ! test/hotspot/jtreg/compiler/startup/NumCompilerThreadsCheck.java Changeset: 99cfc160 Author: Aleksey Shipilev Date: 2021-09-16 08:22:48 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/99cfc160af119ab70fa3549711cf6948402c4df8 8273805: gc/g1/TestGCLogMessages.java test should handle non-JFR configs Reviewed-by: tschatzl, ayang ! test/hotspot/jtreg/gc/g1/TestGCLogMessages.java Changeset: 09ecb119 Author: Aleksey Shipilev Date: 2021-09-16 08:23:55 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/09ecb11927f0042ddc0c5c23d747b275ab70b36b 8273806: compiler/cpuflags/TestSSE4Disabled.java should test for CPU feature explicitly Reviewed-by: thartmann ! test/hotspot/jtreg/compiler/cpuflags/TestSSE4Disabled.java Changeset: 181292d4 Author: Aleksey Shipilev Date: 2021-09-16 08:25:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/181292d48c989e3206354cea73bec015c13a986b 8273801: Handle VMTYPE for "core" VM variant Reviewed-by: dholmes, erikj ! make/hotspot/lib/JvmFeatures.gmk Changeset: 241ac89f Author: Aleksey Shipilev Date: 2021-09-16 08:53:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/241ac89f120f9bcfef65962aa05b51b9f847c4ce 8273606: Zero: SPARC64 build fails with si_band type mismatch Reviewed-by: stuefe ! src/hotspot/os/posix/signals_posix.cpp Changeset: 14dc5178 Author: Albert Mingkun Yang Date: 2021-09-16 11:41:15 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/14dc5178cf28c60a791502b9922879371493e925 8273372: Remove scavenge trace message in psPromotionManager Reviewed-by: tschatzl, lkorinth ! src/hotspot/share/gc/parallel/psPromotionManager.cpp ! src/hotspot/share/gc/parallel/psPromotionManager.inline.hpp ! src/hotspot/share/gc/shared/referenceProcessor.cpp Changeset: c86e24d4 Author: Christian Hagedorn Date: 2021-09-16 11:57:30 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c86e24d4be1e1a26a2a8323ef7ddbab6326bbf3a 8271954: C2: assert(false) failed: Bad graph detected in build_loop_late Reviewed-by: roland, kvn ! src/hotspot/share/opto/loopPredicate.cpp ! src/hotspot/share/opto/loopnode.hpp + test/hotspot/jtreg/compiler/loopopts/TestUnswitchWithSunkNodes.java Changeset: 5e4d09c2 Author: Coleen Phillimore Date: 2021-09-16 12:01:49 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5e4d09c22921f2980f84f849eb600d2e524d0733 8273300: Check Mutex ranking during a safepoint Reviewed-by: eosterlund, dholmes, pchilanomate ! src/hotspot/share/classfile/classLoaderData.cpp ! src/hotspot/share/gc/g1/g1RegionToSpaceMapper.cpp ! src/hotspot/share/gc/g1/heapRegion.cpp ! src/hotspot/share/gc/g1/heapRegion.inline.hpp ! src/hotspot/share/gc/g1/heapRegionRemSet.cpp ! src/hotspot/share/gc/shenandoah/shenandoahCodeRoots.cpp ! src/hotspot/share/gc/shenandoah/shenandoahNMethod.inline.hpp ! src/hotspot/share/memory/universe.cpp ! src/hotspot/share/runtime/mutex.cpp ! src/hotspot/share/runtime/mutex.hpp ! src/hotspot/share/runtime/mutexLocker.cpp ! src/hotspot/share/utilities/concurrentHashTable.inline.hpp Changeset: 59b2478a Author: Roland Westrelin Date: 2021-09-16 12:02:46 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/59b2478abd7f233531262b0fa190e027a785da79 8273659: Replay compilation crashes with SIGSEGV since 8271911 Reviewed-by: kvn, dlong ! src/hotspot/share/ci/ciReplay.cpp Changeset: 7e92abe7 Author: Andrey Turbanov Committer: Aleksey Shipilev Date: 2021-09-16 15:17:28 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7e92abe7a4bd2840fed19826fbff0285732f1765 8273710: Remove redundant stream() call before forEach in jdk.jdeps Reviewed-by: dfuchs, shade ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/DepsAnalyzer.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/Graph.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/InverseDepsAnalyzer.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/JdepsConfiguration.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/JdepsTask.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/Module.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModuleAnalyzer.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModuleDotGraph.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModuleExportsAnalyzer.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModuleGraphBuilder.java Changeset: 12fa7073 Author: Calvin Cheung Date: 2021-09-16 17:32:02 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/12fa7073c58eb9f204bb60ab6192738f8aece626 8261941: Use ClassLoader for unregistered classes during -Xshare:dump Reviewed-by: iklam, minqi ! src/hotspot/share/cds/classListParser.cpp + src/hotspot/share/cds/unregisteredClasses.cpp + src/hotspot/share/cds/unregisteredClasses.hpp ! src/hotspot/share/classfile/classLoaderExt.cpp ! src/hotspot/share/classfile/classLoaderExt.hpp ! src/hotspot/share/classfile/systemDictionaryShared.cpp ! src/hotspot/share/classfile/systemDictionaryShared.hpp ! src/hotspot/share/classfile/vmClassMacros.hpp ! src/hotspot/share/classfile/vmSymbols.hpp ! src/hotspot/share/oops/instanceKlass.hpp Changeset: 9c5441c9 Author: Yumin Qi Date: 2021-09-16 17:56:07 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9c5441c9c4eea2ea4ba78ee426729bf646dc042d 8271569: Clean up the use of CDS constants and field offsets Reviewed-by: iklam, dholmes + src/hotspot/share/cds/cdsConstants.cpp + src/hotspot/share/cds/cdsConstants.hpp - src/hotspot/share/cds/cdsoffsets.cpp - src/hotspot/share/cds/cdsoffsets.hpp ! src/hotspot/share/cds/dynamicArchive.hpp ! src/hotspot/share/cds/filemap.hpp ! src/hotspot/share/include/cds.h ! src/hotspot/share/prims/whitebox.cpp ! test/lib/jdk/test/lib/cds/CDSArchiveUtils.java ! test/lib/jdk/test/whitebox/WhiteBox.java ! test/lib/sun/hotspot/WhiteBox.java Changeset: bc48a0ac Author: Volker Simonis Date: 2021-09-16 19:56:12 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bc48a0ac297b99a997482dcb59f85acc1cdb0c47 8273902: Memory leak in OopStorage due to bug in OopHandle::release() Reviewed-by: sspitsyn, coleenp ! src/hotspot/share/oops/oopHandle.inline.hpp ! src/hotspot/share/prims/jvmtiImpl.cpp Changeset: b9829044 Author: Ioi Lam Date: 2021-09-16 23:26:55 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b98290444a4594d0164d6f313c506287282d1929 8271073: Improve testing with VM option VerifyArchivedFields Reviewed-by: ccheung, minqi ! src/hotspot/share/cds/heapShared.cpp ! src/hotspot/share/gc/shared/gc_globals.hpp ! test/hotspot/jtreg/runtime/cds/appcds/TestCommon.java + test/hotspot/jtreg/runtime/cds/appcds/cacheObject/VerifyArchivedFields.java ! test/lib/jdk/test/lib/cds/CDSTestUtils.java Changeset: 8c022e2c Author: Alex Menkov Date: 2021-09-16 23:45:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8c022e2c174cca2b03e8fdf4fadad42bc11c65f1 8270434: JDI+UT: Unexpected event in JDI tests Reviewed-by: sspitsyn, kevinw ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventIterator/nextEvent/nextevent001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/methodEntryRequests/methentreq002.java ! test/hotspot/jtreg/vmTestbase/nsk/share/jdi/JDIBase.java Changeset: e07ab82e Author: Guoxiong Li Date: 2021-09-17 05:34:25 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e07ab82ee555f27921287a871ba582e0906ad45c 8273408: java.lang.AssertionError: typeSig ERROR on generated class property of record Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java + test/langtools/tools/javac/records/recordComponent/GenerateTypeProcessor.java + test/langtools/tools/javac/records/recordComponent/RecordComponentTypeTest.java Changeset: 54b45676 Author: Aleksey Shipilev Date: 2021-09-17 06:44:18 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/54b456764bedb53adb7ae3c25f64d44dd8322ada 8273880: Zero: Print warnings when unsupported intrinsics are enabled Reviewed-by: dholmes ! src/hotspot/cpu/zero/vm_version_zero.cpp Changeset: 1890d85c Author: Per Liden Date: 2021-09-17 07:51:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1890d85c0e647d3f890e3c7152f8cd2e60dfd826 8273872: ZGC: Explicitly use 2M large pages Reviewed-by: eosterlund, tschatzl, stefank ! src/hotspot/os/linux/gc/z/zPhysicalMemoryBacking_linux.cpp ! src/hotspot/share/gc/z/zArguments.cpp Changeset: 35f6f1d6 Author: Matthias Baesken Date: 2021-09-17 08:20:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/35f6f1d69f4238f16595b9b8f1d11db9e49d4cc9 8273808: Cleanup AddFontsToX11FontPath Reviewed-by: pbansal, lucy ! src/java.desktop/unix/native/common/awt/fontpath.c Changeset: e22212ca Author: duke Date: 2021-09-17 11:00:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e22212ca6a9c0deb9e8eaf3cbcc3e1a705bc3cee Automatic merge of jdk:master into master From sundar at openjdk.java.net Fri Sep 17 11:23:05 2021 From: sundar at openjdk.java.net (Athijegannathan Sundararajan) Date: Fri, 17 Sep 2021 11:23:05 GMT Subject: [foreign-memaccess+abi] RFR: 8273905: Foreign API refresh [v2] In-Reply-To: References: Message-ID: On Fri, 17 Sep 2021 10:25:45 GMT, Maurizio Cimadamore wrote: >> As outlined in [1], there are areas of the foreign API we'd like to improve upon, such as: >> >> * dereference: there is a mismatch between API points which create segments (which take a layout) and dereference API points, which do not take layouts >> >> * role of `MemoryAddress`: in Java 17, `MemoryAddress` has become a stateful carrier, which is attached to a scope. This is inconvenient, as in most cases, a memory address is just a raw pointer that arises when interacting with native code. >> >> * resource scopes: the API for scopes has too many flavors to pick from, many of which overlap. The fact that scopes and segment allocators are unrelated forces clients to introduce ad hoc conversions from scopes to allocators, and library developers to add overloads. Finally, the API for acquiring scopes doesn't work well with try-with-resources, and could also be simplified. >> >> I will add separate comments to explain how the API has changed to resolve the above issues. >> >> [1] - https://mail.openjdk.java.net/pipermail/panama-dev/2021-September/014946.html > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments src/java.base/share/classes/jdk/internal/access/foreign/MemorySegmentProxy.java line 30: > 28: > 29: import jdk.internal.misc.ScopedMemoryAccess; > 30: import jdk.internal.vm.annotation.ForceInline; Is this import needed? ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/576 From mcimadamore at openjdk.java.net Fri Sep 17 11:27:02 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 17 Sep 2021 11:27:02 GMT Subject: [foreign-memaccess+abi] RFR: 8273905: Foreign API refresh [v2] In-Reply-To: References: Message-ID: <01-3ReuRdcrMz_3oiD2CynMTWfcnajQPJdAaBu09PXA=.fd7c6b9d-0476-4b50-b8ca-e17641605d7c@github.com> On Fri, 17 Sep 2021 11:20:05 GMT, Athijegannathan Sundararajan wrote: >> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: >> >> Address review comments > > src/java.base/share/classes/jdk/internal/access/foreign/MemorySegmentProxy.java line 30: > >> 28: >> 29: import jdk.internal.misc.ScopedMemoryAccess; >> 30: import jdk.internal.vm.annotation.ForceInline; > > Is this import needed? Leftover form past experiments - good catch! ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/576 From uschindler at apache.org Fri Sep 17 11:32:36 2021 From: uschindler at apache.org (Uwe Schindler) Date: Fri, 17 Sep 2021 13:32:36 +0200 Subject: [foreign] thoughts on finalizing foreign APIs In-Reply-To: References: Message-ID: <09bb01d7abb7$b7a92740$26fb75c0$@apache.org> Hi Maurizio, Thanks, great new API. I fully agree (see also other response in this thread)! When reviewing the API, I found a small problem (I think it already exists in JDK 17): The return value of method "MemorySegment#mapFile(...)" has a wrong description of the @return value: It says that the scope is "confined", which is wrong. It uses the scope given as parameter! The @return should possibly be copied over from the other static "allocate" methods taking a ResourceScope. 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: panama-dev On Behalf Of > Maurizio Cimadamore > Sent: Thursday, September 16, 2021 4:59 PM > To: panama-dev at openjdk.java.net > Subject: [foreign] thoughts on finalizing foreign APIs > > Hi, > we have spent the last few weeks looking at the foreign APIs more > holistically, to see what we could do to improve them, in order to get > them preview/finalization ready. The resulting changes are described in > the following write up: > > https://inside.java/2021/09/16/finalizing-the-foreign-apis/ > > We think the proposed API [2, 3] is much simpler, tighter and safer - > while retaining the same expressiveness of the existing API. > > Moving forward, we would like to start integrating the proposed changes > into the panama repo, and incubate those changes in 18. We will then > (finger crossed!) move towards finalizing the API, by making it a > preview API in 19 (the document describes some basic shuffling moves on > how we might want to do that). While we could technically preview things > in 18, we believe that the extra steps required to move the API into > java.base would push us too close to the code freeze deadline; besides > there are still outstanding performance issues (such as [1]) which we'd > like to have addressed, so that user experience can be as smooth as > possible. For these reasons, incubating in 18 and previewing in 19 seems > like the most sensible option at this point in time. > > Cheers > Maurizio > > [1] - https://bugs.openjdk.java.net/browse/JDK-8259609 > [2] - > http://cr.openjdk.java.net/~mcimadamore/panama/foreign-finalize- > javadoc/javadoc/jdk/incubator/foreign/package-summary.html > [3] - > https://github.com/mcimadamore/panama-foreign/tree/foreign- > finalize%2Bjextract From maurizio.cimadamore at oracle.com Fri Sep 17 11:35:28 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 17 Sep 2021 12:35:28 +0100 Subject: [foreign] thoughts on finalizing foreign APIs In-Reply-To: <09bb01d7abb7$b7a92740$26fb75c0$@apache.org> References: <09bb01d7abb7$b7a92740$26fb75c0$@apache.org> Message-ID: <88dd6320-3ec2-50f5-9083-507c8d4791a2@oracle.com> Thanks for the comment - I will fix in the PR! Cheers Maurizio On 17/09/2021 12:32, Uwe Schindler wrote: > Hi Maurizio, > > Thanks, great new API. I fully agree (see also other response in this thread)! > > When reviewing the API, I found a small problem (I think it already exists in JDK 17): The return value of method "MemorySegment#mapFile(...)" has a wrong description of the @return value: It says that the scope is "confined", which is wrong. It uses the scope given as parameter! The @return should possibly be copied over from the other static "allocate" methods taking a ResourceScope. > > 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/__;!!ACWV5N9M2RV99hQ!c1P6c9-690NCzI4q5XZdBH_cpPs6aPqyux2bp9egMSXE5tTCK6-fDhPU3J3BJKbxAdbvR88$ > https://urldefense.com/v3/__https://solr.apache.org/__;!!ACWV5N9M2RV99hQ!c1P6c9-690NCzI4q5XZdBH_cpPs6aPqyux2bp9egMSXE5tTCK6-fDhPU3J3BJKbxpwO-Z7w$ > >> -----Original Message----- >> From: panama-dev On Behalf Of >> Maurizio Cimadamore >> Sent: Thursday, September 16, 2021 4:59 PM >> To: panama-dev at openjdk.java.net >> Subject: [foreign] thoughts on finalizing foreign APIs >> >> Hi, >> we have spent the last few weeks looking at the foreign APIs more >> holistically, to see what we could do to improve them, in order to get >> them preview/finalization ready. The resulting changes are described in >> the following write up: >> >> https://urldefense.com/v3/__https://inside.java/2021/09/16/finalizing-the-foreign-apis/__;!!ACWV5N9M2RV99hQ!c1P6c9-690NCzI4q5XZdBH_cpPs6aPqyux2bp9egMSXE5tTCK6-fDhPU3J3BJKbxmXotFRA$ >> >> We think the proposed API [2, 3] is much simpler, tighter and safer - >> while retaining the same expressiveness of the existing API. >> >> Moving forward, we would like to start integrating the proposed changes >> into the panama repo, and incubate those changes in 18. We will then >> (finger crossed!) move towards finalizing the API, by making it a >> preview API in 19 (the document describes some basic shuffling moves on >> how we might want to do that). While we could technically preview things >> in 18, we believe that the extra steps required to move the API into >> java.base would push us too close to the code freeze deadline; besides >> there are still outstanding performance issues (such as [1]) which we'd >> like to have addressed, so that user experience can be as smooth as >> possible. For these reasons, incubating in 18 and previewing in 19 seems >> like the most sensible option at this point in time. >> >> Cheers >> Maurizio >> >> [1] - https://bugs.openjdk.java.net/browse/JDK-8259609 >> [2] - >> http://cr.openjdk.java.net/~mcimadamore/panama/foreign-finalize- >> javadoc/javadoc/jdk/incubator/foreign/package-summary.html >> [3] - >> https://urldefense.com/v3/__https://github.com/mcimadamore/panama-foreign/tree/foreign-__;!!ACWV5N9M2RV99hQ!c1P6c9-690NCzI4q5XZdBH_cpPs6aPqyux2bp9egMSXE5tTCK6-fDhPU3J3BJKbxGs--Xbc$ >> finalize%2Bjextract > From kburjack at googlemail.com Fri Sep 17 15:12:32 2021 From: kburjack at googlemail.com (Kai Burjack) Date: Fri, 17 Sep 2021 17:12:32 +0200 Subject: Performance of two-vector shuffles/rearranges Message-ID: Hi, I'd like to get some news about how the performance optimizations for two-vector shuffles/rearrange are going or whether there are any plans to improve the performance of these. What I am talking about is code like: ```C // pick lane 0 and 1 from row0 and lane 0 and 1 from row1 _mm_shuffle_ps(row0, row1, 0x44) // pick lane 2 and 3 from row0 and lane 2 and 3 from row1 _mm_shuffle_ps(row0, row1, 0xEE); ``` which I translated to Vector API like this: ```Java // pick lane 0 and 1 from row0 and lane 0 and 1 from row1 row0.rearrange(s0145, row1, SPECIES_128.shuffleFromValues(0, 1, 4, 5)); // pick lane 2 and 3 from row0 and lane 2 and 3 from row1 row0.rearrange(s0145, row1, SPECIES_128.shuffleFromValues(2, 3, 6, 7)); ``` The C compiler generates optimal SSE instructions for the above intrinsics while the Java translation of mine is about two orders of magnitudes slower. Also, putting the result of the SPECIES_128.shuffleFromValues() calls into private static final variables and using these variables in the rearrange calls gives a performance increase of ~30%, which is rather odd, since I would have assumed that everything is nicely inlined and optimized. My actual use-case for the vector shuffles is computing 4x4 matrix inverse and transpose. I've also written some benchmarks in https://github.com/JOML-CI/panama-vector-bench to reflect my use-cases. I am constantly testing against the current git tip of the vectorIntrinsics and vectorIntrinsics+mask branches in the GitHub repo. Are the rearrange patterns planned to be optimized in the future? Thanks! Kai From kburjack at googlemail.com Fri Sep 17 15:15:28 2021 From: kburjack at googlemail.com (Kai Burjack) Date: Fri, 17 Sep 2021 17:15:28 +0200 Subject: Performance of two-vector shuffles/rearranges In-Reply-To: References: Message-ID: Sorry, the Java code from the previous mail: ```Java // pick lane 0 and 1 from row0 and lane 0 and 1 from row1 row0.rearrange(s0145, row1, SPECIES_128.shuffleFromValues(0, 1, 4, 5)); // pick lane 2 and 3 from row0 and lane 2 and 3 from row1 row0.rearrange(s0145, row1, SPECIES_128.shuffleFromValues(2, 3, 6, 7)); ``` should read as: ```Java // pick lane 0 and 1 from row0 and lane 0 and 1 from row1 col0.rearrange(SPECIES_128.shuffleFromValues(0, 1, 4, 5), row1); // pick lane 2 and 3 from row0 and lane 2 and 3 from row1 col0.rearrange(SPECIES_128.shuffleFromValues(2, 3, 6, 7), row1); ``` This is the actual code (also in the benchmark repo). On Fri, Sep 17, 2021 at 5:12 PM Kai Burjack wrote: > Hi, > > I'd like to get some news about how the performance optimizations for > two-vector shuffles/rearrange are going or whether there are any plans > to improve the performance of these. > > What I am talking about is code like: > ```C > // pick lane 0 and 1 from row0 and lane 0 and 1 from row1 > _mm_shuffle_ps(row0, row1, 0x44) > // pick lane 2 and 3 from row0 and lane 2 and 3 from row1 > _mm_shuffle_ps(row0, row1, 0xEE); > ``` > > which I translated to Vector API like this: > ```Java > // pick lane 0 and 1 from row0 and lane 0 and 1 from row1 > row0.rearrange(s0145, row1, SPECIES_128.shuffleFromValues(0, 1, 4, 5)); > // pick lane 2 and 3 from row0 and lane 2 and 3 from row1 > row0.rearrange(s0145, row1, SPECIES_128.shuffleFromValues(2, 3, 6, 7)); > ``` > > The C compiler generates optimal SSE instructions for the above intrinsics > while the Java translation of mine is about two orders of magnitudes > slower. Also, putting the result of the SPECIES_128.shuffleFromValues() > calls into private static final variables and using these variables in the > rearrange calls gives a performance increase of ~30%, which is rather odd, > since I would have assumed that everything is nicely inlined and optimized. > > My actual use-case for the vector shuffles is computing 4x4 matrix inverse > and transpose. > > I've also written some benchmarks in > https://github.com/JOML-CI/panama-vector-bench to reflect my use-cases. > > I am constantly testing against the current git tip of the > vectorIntrinsics and vectorIntrinsics+mask branches in the GitHub repo. > > Are the rearrange patterns planned to be optimized in the future? > > Thanks! > Kai > From psandoz at openjdk.java.net Fri Sep 17 15:21:00 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Fri, 17 Sep 2021 15:21:00 GMT Subject: [vectorIntrinsics+mask] RFR: 8273264: AArch64: [vector] Add missing rules for VectorMaskCast [v4] In-Reply-To: <8KamhXt9bDj4Oys63C_RIAZ0dQzsbswGMEPZ1FNmhE0=.7a86ee49-0fe1-418b-b02c-ccd5521a79af@github.com> References: <8KamhXt9bDj4Oys63C_RIAZ0dQzsbswGMEPZ1FNmhE0=.7a86ee49-0fe1-418b-b02c-ccd5521a79af@github.com> Message-ID: On Fri, 17 Sep 2021 07:38:28 GMT, Eric Liu wrote: >> This patch >> 1. Adds missing rules for VectorMaskCast for compatible species, E.g. >> ByteVector.SPECIES_64 --> ShortVector.SPECIES_128 >> 2. Fixes a matching failure on AArch64. >> >> The performance improves about 60% compared with the unintrinsified >> version. > > Eric Liu has updated the pull request incrementally with one additional commit since the last revision: > > fix comment > > Change-Id: I01670a0e4a8df4f3a9a62b779ca5659863ec05d9 Comment in test looks good. ------------- Marked as reviewed by psandoz (Committer). PR: https://git.openjdk.java.net/panama-vector/pull/124 From martin.pernollet at protonmail.com Fri Sep 17 11:54:16 2021 From: martin.pernollet at protonmail.com (Martin Pernollet) Date: Fri, 17 Sep 2021 11:54:16 +0000 Subject: JEP-412 & OpenGL Message-ID: Hi, I actively maintain Jzy3D [1], a framework for drawing 3D charts in Java. It uses JOGL which access native OpenGL with the help of GlueGen, a tool to generate JNI bindings. Jzy3D has an additional OpenGL pure Java CPU renderer [2] to circumvent compatibility limitations of JOGL, mainly for MacOS. Will JEP-412 close the doors to bindings relying on JNI? In other word will JOGL be able to continue working with GlueGen and JNI? Are there known plans in OpenJDK for enabling OpenGL (+Metal?) consistently across OS and hardwares via a unified API? II have seen an OpenGL example based on JEP-412 here [3]. I would be interested to assist on that topic and may help making Jzy3D compatible to such API. Jzy3D indeed offers a IPainter interface [4] that allows pluging multiple implementations of OpenGL for Java, hence helping to compare JOGL, EmulGL or any other OpenGL java API. Thanks in advance, Martin [1] http://jzy3d.org/ [2] https://github.com/jzy3d/jzy3d-api/tree/69a14166096a46bfb6e74cd3ab02e11d41c09024/jzy3d-emul-gl [3] https://github.com/sundararajana/panama-jextract-samples/tree/master/opengl [4] https://github.com/jzy3d/jzy3d-api/blob/69a14166096a46bfb6e74cd3ab02e11d41c09024/jzy3d-core/src/main/java/org/jzy3d/painters/IPainter.java From paul.sandoz at oracle.com Fri Sep 17 15:57:20 2021 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 17 Sep 2021 15:57:20 +0000 Subject: [foreign] thoughts on finalizing foreign APIs In-Reply-To: References: Message-ID: <29CA9756-527B-45BA-B3EC-5DBB0D8CDAB2@oracle.com> Very nice. The end-game for FML is in play :-) after the first round play in JDK 14 one and a half years ago. I prefer we get the API we think is right and we can support for decades. Taking an extra release cycle is a small cost in comparison to that. With regards to being in java.base, I would like to emphasize the very important use-case of using FML within java.base for new APIs or for implementations. The java.base module is where many of the foundational innovations occur in harmony with the language and runtime. Paul. > On Sep 16, 2021, at 7:59 AM, Maurizio Cimadamore wrote: > > Hi, > we have spent the last few weeks looking at the foreign APIs more holistically, to see what we could do to improve them, in order to get them preview/finalization ready. The resulting changes are described in the following write up: > > https://inside.java/2021/09/16/finalizing-the-foreign-apis/ > > We think the proposed API [2, 3] is much simpler, tighter and safer - while retaining the same expressiveness of the existing API. > > Moving forward, we would like to start integrating the proposed changes into the panama repo, and incubate those changes in 18. We will then (finger crossed!) move towards finalizing the API, by making it a preview API in 19 (the document describes some basic shuffling moves on how we might want to do that). While we could technically preview things in 18, we believe that the extra steps required to move the API into java.base would push us too close to the code freeze deadline; besides there are still outstanding performance issues (such as [1]) which we'd like to have addressed, so that user experience can be as smooth as possible. For these reasons, incubating in 18 and previewing in 19 seems like the most sensible option at this point in time. > > Cheers > Maurizio > > [1] - https://bugs.openjdk.java.net/browse/JDK-8259609 > [2] - http://cr.openjdk.java.net/~mcimadamore/panama/foreign-finalize-javadoc/javadoc/jdk/incubator/foreign/package-summary.html > [3] - https://github.com/mcimadamore/panama-foreign/tree/foreign-finalize%2Bjextract > > From maurizio.cimadamore at oracle.com Fri Sep 17 16:26:10 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 17 Sep 2021 17:26:10 +0100 Subject: JEP-412 & OpenGL In-Reply-To: References: Message-ID: <44916ce4-1174-28d0-6cff-28ee6ac7b487@oracle.com> Hi Martin, We have no plans to drop support for JNI. JEP 412 offers a replacement which allows libraries to express bindings purely in Java code. In most cases, this is desirable, but I understand that frameworks written prior that JEP might have little to no appetite to rewrite everyting to use MethodHandle/VarHandle and/or jextract. As you noted, OpenGL works well with the new foreign APIs, and we have written various samples using OpenGL bindings generated by jextract. That said, it is beyond the goal of JEP 412 (and its succesors) to provide an uniform OpenGL API _within the JDK_ - but I think the foreign APIs and the tools (jextract) are now reaching a level of maturity which would allow for such experiments to occur outside the JDK, and we'd be pleased to hear some feedback in the panama-dev mailing list! Hope this answers your question Maurizio On 17/09/2021 12:54, Martin Pernollet wrote: > Hi, > > I actively maintain Jzy3D [1], a framework for drawing 3D charts in Java. It uses JOGL which access native OpenGL with the help of GlueGen, a tool to generate JNI bindings. Jzy3D has an additional OpenGL pure Java CPU renderer [2] to circumvent compatibility limitations of JOGL, mainly for MacOS. > > Will JEP-412 close the doors to bindings relying on JNI? In other word will JOGL be able to continue working with GlueGen and JNI? > > Are there known plans in OpenJDK for enabling OpenGL (+Metal?) consistently across OS and hardwares via a unified API? II have seen an OpenGL example based on JEP-412 here [3]. I would be interested to assist on that topic and may help making Jzy3D compatible to such API. Jzy3D indeed offers a IPainter interface [4] that allows pluging multiple implementations of OpenGL for Java, hence helping to compare JOGL, EmulGL or any other OpenGL java API. > > Thanks in advance, > > Martin > > [1] http://jzy3d.org/ > > [2] https://github.com/jzy3d/jzy3d-api/tree/69a14166096a46bfb6e74cd3ab02e11d41c09024/jzy3d-emul-gl > [3] https://github.com/sundararajana/panama-jextract-samples/tree/master/opengl > [4] https://github.com/jzy3d/jzy3d-api/blob/69a14166096a46bfb6e74cd3ab02e11d41c09024/jzy3d-core/src/main/java/org/jzy3d/painters/IPainter.java From psandoz at openjdk.java.net Fri Sep 17 16:47:59 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Fri, 17 Sep 2021 16:47:59 GMT Subject: [foreign-memaccess+abi] RFR: 8273905: Foreign API refresh [v2] In-Reply-To: References: Message-ID: On Fri, 17 Sep 2021 10:25:45 GMT, Maurizio Cimadamore wrote: >> As outlined in [1], there are areas of the foreign API we'd like to improve upon, such as: >> >> * dereference: there is a mismatch between API points which create segments (which take a layout) and dereference API points, which do not take layouts >> >> * role of `MemoryAddress`: in Java 17, `MemoryAddress` has become a stateful carrier, which is attached to a scope. This is inconvenient, as in most cases, a memory address is just a raw pointer that arises when interacting with native code. >> >> * resource scopes: the API for scopes has too many flavors to pick from, many of which overlap. The fact that scopes and segment allocators are unrelated forces clients to introduce ad hoc conversions from scopes to allocators, and library developers to add overloads. Finally, the API for acquiring scopes doesn't work well with try-with-resources, and could also be simplified. >> >> I will add separate comments to explain how the API has changed to resolve the above issues. >> >> [1] - https://mail.openjdk.java.net/pipermail/panama-dev/2021-September/014946.html > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments I recommend running IntelliJ analysis over the code before integrating. It often finds small problems, typos, Java doc issues. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/576 From mcimadamore at openjdk.java.net Fri Sep 17 16:54:43 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 17 Sep 2021 16:54:43 GMT Subject: [foreign-memaccess+abi] RFR: 8273905: Foreign API refresh [v2] In-Reply-To: References: Message-ID: On Fri, 17 Sep 2021 16:44:51 GMT, Paul Sandoz wrote: > I recommend running IntelliJ analysis over the code before integrating. It often finds small problems, typos, Java doc issues. I've ran the typos and grammar analyses already (so what you see should be already relatively polished). I will run some more to catch code issues. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/576 From mcimadamore at openjdk.java.net Fri Sep 17 16:59:04 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 17 Sep 2021 16:59:04 GMT Subject: [foreign-memaccess+abi] RFR: 8273905: Foreign API refresh [v3] In-Reply-To: References: Message-ID: > As outlined in [1], there are areas of the foreign API we'd like to improve upon, such as: > > * dereference: there is a mismatch between API points which create segments (which take a layout) and dereference API points, which do not take layouts > > * role of `MemoryAddress`: in Java 17, `MemoryAddress` has become a stateful carrier, which is attached to a scope. This is inconvenient, as in most cases, a memory address is just a raw pointer that arises when interacting with native code. > > * resource scopes: the API for scopes has too many flavors to pick from, many of which overlap. The fact that scopes and segment allocators are unrelated forces clients to introduce ad hoc conversions from scopes to allocators, and library developers to add overloads. Finally, the API for acquiring scopes doesn't work well with try-with-resources, and could also be simplified. > > I will add separate comments to explain how the API has changed to resolve the above issues. > > [1] - https://mail.openjdk.java.net/pipermail/panama-dev/2021-September/014946.html Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Fix javadoc issues with `confined` and an unused import in `MemorySegmentProxy`. ------------- Changes: - all: https://git.openjdk.java.net/panama-foreign/pull/576/files - new: https://git.openjdk.java.net/panama-foreign/pull/576/files/0cbda30b..3396e401 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=576&range=02 - incr: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=576&range=01-02 Stats: 7 lines in 2 files changed: 0 ins; 1 del; 6 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/576.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/576/head:pull/576 PR: https://git.openjdk.java.net/panama-foreign/pull/576 From psandoz at openjdk.java.net Fri Sep 17 20:34:58 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Fri, 17 Sep 2021 20:34:58 GMT Subject: [vectorIntrinsics+mask] RFR: 8273949: Intrinsic creation for VectorMask.toLong operation. In-Reply-To: References: Message-ID: On Fri, 17 Sep 2021 19:50:37 GMT, Jatin Bhateja wrote: > Summary of changes: > - Intrinsification of VectorMask.toLong() API. > - Supports inline expansion for both AVX512 and non-AVX512 targets. > - Used toLong() API to optimize existing Java API implementation of VectorMask.laneIsSet() operation. > > Following performance number are generated using JMH benchmark modification included with the patch. > > System: Intel(R) Xeon(R) Platinum 8280 CPU @ 2.70GHz (Cascade Lake Server 28C 2S) > > Benchmark | VECSIZE | Baseline Score (ops/ms) | With Opt (ops/ms) | Gain Ratio > -- | -- | -- | -- | -- > MaskQueryOperationsBenchmark.testToLongByte | 128 | 90451.424 | 346941.379 | 3.835665196 > MaskQueryOperationsBenchmark.testToLongByte | 256 | 63127.764 | 338331.425 | 5.359471072 > MaskQueryOperationsBenchmark.testToLongByte | 512 | 40543.264 | 313836.333 | 7.740776199 > MaskQueryOperationsBenchmark.testToLongLong | 128 | 171989.714 | 152872.758 | 0.88884826 > MaskQueryOperationsBenchmark.testToLongLong | 256 | 164702.273 | 324794.578 | 1.972010295 > MaskQueryOperationsBenchmark.testToLongLong | 512 | 122667.916 | 318060.096 | 2.59285481 > MaskQueryOperationsBenchmark.testToLongShort | 128 | 122656.408 | 346691.082 | 2.826522378 > MaskQueryOperationsBenchmark.testToLongShort | 256 | 96838.555 | 360909.28 | 3.726917239 > MaskQueryOperationsBenchmark.testToLongShort | 512 | 63119.009 | 313075.159 | 4.960077225 > MaskQueryOperationsBenchmark.testToLonglong | 128 | 180855.623 | 324620.433 | 1.794914792 > MaskQueryOperationsBenchmark.testToLonglong | 256 | 122705.631 | 324315.916 | 2.643040204 > MaskQueryOperationsBenchmark.testToLonglong | 512 | 90396.687 | 324318.095 | 3.58772103 src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractMask.java line 66: > 64: @Override > 65: public boolean laneIsSet(int i) { > 66: if (length() <= Long.SIZE) { We need to check that `i > 0 && i < length()` and if not throw `IllegalArgumentException`. Currently the behavior is unspecified, can you please add the following to the documentation of `VectorMask.laneIsSet`. (I will handle any CSR related tasks.) * @throws IllegalArgumentException if the index is is out of range * ({@code < 0 || >= length()}) src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte128Vector.java line 712: > 710: public int trueCount() { > 711: return (int) VectorSupport.maskReductionCoerced(VECTOR_OP_MASK_TRUECOUNT, Byte128Mask.class, byte.class, VLENGTH, this, > 712: (m) -> (long)trueCountHelper(((Byte128Mask)m).getBits())); Suggestion: return (int) VectorSupport.maskReductionCoerced(VECTOR_OP_MASK_TRUECOUNT, Byte128Mask.class, byte.class, VLENGTH, this, (m) -> trueCountHelper(m.getBits())); We don't need the cast to `long` for the return from the lambda expression. And I think the cast of the mask is redundant too. Same applies to the other three methods. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/126 From paul.sandoz at oracle.com Fri Sep 17 21:13:03 2021 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 17 Sep 2021 21:13:03 +0000 Subject: Performance of two-vector shuffles/rearranges In-Reply-To: References: Message-ID: <2FAC3AC8-2C4A-4FC8-BD09-C34DFC35E678@oracle.com> Hi Kai, We made some progress in 17 but there are still some gaps that we will eventually need to fill. Current priority is completing mask support. - As noted you have to place the shuffle in a static final field to be a constant shuffle. There is no intrinsic shuffle creation and further to determine a constant shuffle we would need to ensure all the shuffle elements are constant too. - VectorShuffle.wrapIndexes is not fully optimized if there are any exceptional values, that?s the main weakness. I think we can eventually get close to what you want, but it might be tricky to it down to two instructions. The implementation is currently composed of two rearranges and a blend. Paul. > On Sep 17, 2021, at 8:15 AM, Kai Burjack wrote: > > Sorry, the Java code from the previous mail: > ```Java > // pick lane 0 and 1 from row0 and lane 0 and 1 from row1 > row0.rearrange(s0145, row1, SPECIES_128.shuffleFromValues(0, 1, 4, 5)); > // pick lane 2 and 3 from row0 and lane 2 and 3 from row1 > row0.rearrange(s0145, row1, SPECIES_128.shuffleFromValues(2, 3, 6, 7)); > ``` > should read as: > ```Java > // pick lane 0 and 1 from row0 and lane 0 and 1 from row1 > col0.rearrange(SPECIES_128.shuffleFromValues(0, 1, 4, 5), row1); > // pick lane 2 and 3 from row0 and lane 2 and 3 from row1 > col0.rearrange(SPECIES_128.shuffleFromValues(2, 3, 6, 7), row1); > ``` > This is the actual code (also in the benchmark repo). > > On Fri, Sep 17, 2021 at 5:12 PM Kai Burjack wrote: > >> Hi, >> >> I'd like to get some news about how the performance optimizations for >> two-vector shuffles/rearrange are going or whether there are any plans >> to improve the performance of these. >> >> What I am talking about is code like: >> ```C >> // pick lane 0 and 1 from row0 and lane 0 and 1 from row1 >> _mm_shuffle_ps(row0, row1, 0x44) >> // pick lane 2 and 3 from row0 and lane 2 and 3 from row1 >> _mm_shuffle_ps(row0, row1, 0xEE); >> ``` >> >> which I translated to Vector API like this: >> ```Java >> // pick lane 0 and 1 from row0 and lane 0 and 1 from row1 >> row0.rearrange(s0145, row1, SPECIES_128.shuffleFromValues(0, 1, 4, 5)); >> // pick lane 2 and 3 from row0 and lane 2 and 3 from row1 >> row0.rearrange(s0145, row1, SPECIES_128.shuffleFromValues(2, 3, 6, 7)); >> ``` >> >> The C compiler generates optimal SSE instructions for the above intrinsics >> while the Java translation of mine is about two orders of magnitudes >> slower. Also, putting the result of the SPECIES_128.shuffleFromValues() >> calls into private static final variables and using these variables in the >> rearrange calls gives a performance increase of ~30%, which is rather odd, >> since I would have assumed that everything is nicely inlined and optimized. >> >> My actual use-case for the vector shuffles is computing 4x4 matrix inverse >> and transpose. >> >> I've also written some benchmarks in >> https://github.com/JOML-CI/panama-vector-bench to reflect my use-cases. >> >> I am constantly testing against the current git tip of the >> vectorIntrinsics and vectorIntrinsics+mask branches in the GitHub repo. >> >> Are the rearrange patterns planned to be optimized in the future? >> >> Thanks! >> Kai >> From mcimadamore at openjdk.java.net Fri Sep 17 17:16:58 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 17 Sep 2021 17:16:58 GMT Subject: [foreign-memaccess+abi] RFR: 8273905: Foreign API refresh [v4] In-Reply-To: References: Message-ID: > As outlined in [1], there are areas of the foreign API we'd like to improve upon, such as: > > * dereference: there is a mismatch between API points which create segments (which take a layout) and dereference API points, which do not take layouts > > * role of `MemoryAddress`: in Java 17, `MemoryAddress` has become a stateful carrier, which is attached to a scope. This is inconvenient, as in most cases, a memory address is just a raw pointer that arises when interacting with native code. > > * resource scopes: the API for scopes has too many flavors to pick from, many of which overlap. The fact that scopes and segment allocators are unrelated forces clients to introduce ad hoc conversions from scopes to allocators, and library developers to add overloads. Finally, the API for acquiring scopes doesn't work well with try-with-resources, and could also be simplified. > > I will add separate comments to explain how the API has changed to resolve the above issues. > > [1] - https://mail.openjdk.java.net/pipermail/panama-dev/2021-September/014946.html Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Cleanup up code, following some IDEA suggestions. * unused imports * suggestions for new language features * drop unused impl declarations * removed size constructor parameter in value layout subclasses (except `OfAddress`) ------------- Changes: - all: https://git.openjdk.java.net/panama-foreign/pull/576/files - new: https://git.openjdk.java.net/panama-foreign/pull/576/files/3396e401..c4bf5b4b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=576&range=03 - incr: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=576&range=02-03 Stats: 116 lines in 12 files changed: 0 ins; 48 del; 68 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/576.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/576/head:pull/576 PR: https://git.openjdk.java.net/panama-foreign/pull/576 From eliu at openjdk.java.net Sat Sep 18 01:24:01 2021 From: eliu at openjdk.java.net (Eric Liu) Date: Sat, 18 Sep 2021 01:24:01 GMT Subject: [vectorIntrinsics+mask] Integrated: 8273264: AArch64: [vector] Add missing rules for VectorMaskCast In-Reply-To: References: Message-ID: On Mon, 13 Sep 2021 10:48:40 GMT, Eric Liu wrote: > This patch > 1. Adds missing rules for VectorMaskCast for compatible species, E.g. > ByteVector.SPECIES_64 --> ShortVector.SPECIES_128 > 2. Fixes a matching failure on AArch64. > > The performance improves about 60% compared with the unintrinsified > version. This pull request has now been integrated. Changeset: b44662ab Author: Eric Liu URL: https://git.openjdk.java.net/panama-vector/commit/b44662abce715e9a669144ecd515b3cef04ae923 Stats: 714 lines in 12 files changed: 636 ins; 0 del; 78 mod 8273264: AArch64: [vector] Add missing rules for VectorMaskCast Co-authored-by: Ningsheng Jian Reviewed-by: njian, psandoz ------------- PR: https://git.openjdk.java.net/panama-vector/pull/124 From njian at openjdk.java.net Sat Sep 18 02:39:49 2021 From: njian at openjdk.java.net (Ningsheng Jian) Date: Sat, 18 Sep 2021 02:39:49 GMT Subject: [vectorIntrinsics] RFR: Merge panama-vector:master Message-ID: Another clean merge. Verified on aarch64 and x86. ------------- Commit messages: - Merge jdk/master into vectorIntrinsics - 8273880: Zero: Print warnings when unsupported intrinsics are enabled - 8273408: java.lang.AssertionError: typeSig ERROR on generated class property of record - 8270434: JDI+UT: Unexpected event in JDI tests - 8271073: Improve testing with VM option VerifyArchivedFields - 8273902: Memory leak in OopStorage due to bug in OopHandle::release() - 8271569: Clean up the use of CDS constants and field offsets - 8261941: Use ClassLoader for unregistered classes during -Xshare:dump - 8273710: Remove redundant stream() call before forEach in jdk.jdeps - 8273659: Replay compilation crashes with SIGSEGV since 8271911 - ... and 99 more: https://git.openjdk.java.net/panama-vector/compare/beed6675...3022e376 The webrevs contain the adjustments done while merging with regards to each parent branch: - vectorIntrinsics: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=127&range=00.0 - panama-vector:master: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=127&range=00.1 Changes: https://git.openjdk.java.net/panama-vector/pull/127/files Stats: 6994 lines in 412 files changed: 4529 ins; 1415 del; 1050 mod Patch: https://git.openjdk.java.net/panama-vector/pull/127.diff Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/127/head:pull/127 PR: https://git.openjdk.java.net/panama-vector/pull/127 From eliu at openjdk.java.net Sat Sep 18 04:27:17 2021 From: eliu at openjdk.java.net (Eric Liu) Date: Sat, 18 Sep 2021 04:27:17 GMT Subject: [vectorIntrinsics] RFR: Merge panama-vector:master In-Reply-To: References: Message-ID: On Sat, 18 Sep 2021 02:32:21 GMT, Ningsheng Jian wrote: > Another clean merge. Verified on aarch64 and x86. Thanks for your work! ------------- Marked as reviewed by eliu (Committer). PR: https://git.openjdk.java.net/panama-vector/pull/127 From njian at openjdk.java.net Sat Sep 18 06:16:21 2021 From: njian at openjdk.java.net (Ningsheng Jian) Date: Sat, 18 Sep 2021 06:16:21 GMT Subject: [vectorIntrinsics] RFR: Merge panama-vector:master [v2] In-Reply-To: References: Message-ID: > Another clean merge. Verified on aarch64 and x86. Ningsheng Jian has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 737 commits: - Merge jdk/master into vectorIntrinsics - Merge panama-vector:master Reviewed-by: jbhateja, psandoz - 8263532: C2: Improve vector box elimination for Phi nodes Reviewed-by: psandoz - Merge panama-vector:master Co-authored-by: Ningsheng Jian - Optimize mem barriers for ByteBuffer cases Reviewed-by: psandoz, vlivanov - 8271009: AArch64: Wrap duplicated SVE instructions into a single method Reviewed-by: njian, xgong - 8271005: AArch64: Add SVE codegen for VectorMask reduction nodes Reviewed-by: njian, eliu - Merge panama-vector:master Reviewed-by: xgong, sviswanathan - 8269264: Some more cleanups for Vector API SVE support Reviewed-by: xgong - Merge panama-vector:master Co-authored-by: Ningsheng Jian - ... and 727 more: https://git.openjdk.java.net/panama-vector/compare/54b45676...3022e376 ------------- Changes: https://git.openjdk.java.net/panama-vector/pull/127/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=127&range=01 Stats: 73376 lines in 122 files changed: 72140 ins; 213 del; 1023 mod Patch: https://git.openjdk.java.net/panama-vector/pull/127.diff Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/127/head:pull/127 PR: https://git.openjdk.java.net/panama-vector/pull/127 From njian at openjdk.java.net Sat Sep 18 06:16:23 2021 From: njian at openjdk.java.net (Ningsheng Jian) Date: Sat, 18 Sep 2021 06:16:23 GMT Subject: [vectorIntrinsics] Integrated: Merge panama-vector:master In-Reply-To: References: Message-ID: On Sat, 18 Sep 2021 02:32:21 GMT, Ningsheng Jian wrote: > Another clean merge. Verified on aarch64 and x86. This pull request has now been integrated. Changeset: 4e318de1 Author: Ningsheng Jian URL: https://git.openjdk.java.net/panama-vector/commit/4e318de158f001f0aae31e1547488cf12034b281 Stats: 6994 lines in 412 files changed: 4529 ins; 1415 del; 1050 mod Merge panama-vector:master Reviewed-by: eliu ------------- PR: https://git.openjdk.java.net/panama-vector/pull/127 From uschindler at apache.org Sat Sep 18 10:24:37 2021 From: uschindler at apache.org (Uwe Schindler) Date: Sat, 18 Sep 2021 12:24:37 +0200 Subject: [foreign] thoughts on finalizing foreign APIs In-Reply-To: <88dd6320-3ec2-50f5-9083-507c8d4791a2@oracle.com> References: <09bb01d7abb7$b7a92740$26fb75c0$@apache.org> <88dd6320-3ec2-50f5-9083-507c8d4791a2@oracle.com> Message-ID: <0b7401d7ac77$626a5360$273efa20$@apache.org> Hi Maurizio, I did not find the PR yesterday, otherwise I would have commented there, but now I am aware of it. I will check it out and test later and report any issues with performance or other API issues back. 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: Friday, September 17, 2021 1:35 PM > To: Uwe Schindler ; panama-dev at openjdk.java.net > Subject: Re: [foreign] thoughts on finalizing foreign APIs > > Thanks for the comment - I will fix in the PR! > > Cheers > Maurizio > > On 17/09/2021 12:32, Uwe Schindler wrote: > > Hi Maurizio, > > > > Thanks, great new API. I fully agree (see also other response in this thread)! > > > > When reviewing the API, I found a small problem (I think it already exists in > JDK 17): The return value of method "MemorySegment#mapFile(...)" has a > wrong description of the @return value: It says that the scope is "confined", > which is wrong. It uses the scope given as parameter! The @return should > possibly be copied over from the other static "allocate" methods taking a > ResourceScope. > > > > 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/__;!!ACWV5N9M2RV9 > 9hQ!c1P6c9-690NCzI4q5XZdBH_cpPs6aPqyux2bp9egMSXE5tTCK6- > fDhPU3J3BJKbxAdbvR88$ > > > https://urldefense.com/v3/__https://solr.apache.org/__;!!ACWV5N9M2RV99h > Q!c1P6c9-690NCzI4q5XZdBH_cpPs6aPqyux2bp9egMSXE5tTCK6- > fDhPU3J3BJKbxpwO-Z7w$ > > > >> -----Original Message----- > >> From: panama-dev On Behalf Of > >> Maurizio Cimadamore > >> Sent: Thursday, September 16, 2021 4:59 PM > >> To: panama-dev at openjdk.java.net > >> Subject: [foreign] thoughts on finalizing foreign APIs > >> > >> Hi, > >> we have spent the last few weeks looking at the foreign APIs more > >> holistically, to see what we could do to improve them, in order to get > >> them preview/finalization ready. The resulting changes are described in > >> the following write up: > >> > >> https://urldefense.com/v3/__https://inside.java/2021/09/16/finalizing-the- > foreign-apis/__;!!ACWV5N9M2RV99hQ!c1P6c9- > 690NCzI4q5XZdBH_cpPs6aPqyux2bp9egMSXE5tTCK6- > fDhPU3J3BJKbxmXotFRA$ > >> > >> We think the proposed API [2, 3] is much simpler, tighter and safer - > >> while retaining the same expressiveness of the existing API. > >> > >> Moving forward, we would like to start integrating the proposed changes > >> into the panama repo, and incubate those changes in 18. We will then > >> (finger crossed!) move towards finalizing the API, by making it a > >> preview API in 19 (the document describes some basic shuffling moves on > >> how we might want to do that). While we could technically preview things > >> in 18, we believe that the extra steps required to move the API into > >> java.base would push us too close to the code freeze deadline; besides > >> there are still outstanding performance issues (such as [1]) which we'd > >> like to have addressed, so that user experience can be as smooth as > >> possible. For these reasons, incubating in 18 and previewing in 19 seems > >> like the most sensible option at this point in time. > >> > >> Cheers > >> Maurizio > >> > >> [1] - https://bugs.openjdk.java.net/browse/JDK-8259609 > >> [2] - > >> http://cr.openjdk.java.net/~mcimadamore/panama/foreign-finalize- > >> javadoc/javadoc/jdk/incubator/foreign/package-summary.html > >> [3] - > >> https://urldefense.com/v3/__https://github.com/mcimadamore/panama- > foreign/tree/foreign-__;!!ACWV5N9M2RV99hQ!c1P6c9- > 690NCzI4q5XZdBH_cpPs6aPqyux2bp9egMSXE5tTCK6-fDhPU3J3BJKbxGs--Xbc$ > >> finalize%2Bjextract > > From john.r.rose at oracle.com Sat Sep 18 10:56:24 2021 From: john.r.rose at oracle.com (John Rose) Date: Sat, 18 Sep 2021 10:56:24 +0000 Subject: JEP-412 & OpenGL In-Reply-To: <44916ce4-1174-28d0-6cff-28ee6ac7b487@oracle.com> References: <44916ce4-1174-28d0-6cff-28ee6ac7b487@oracle.com> Message-ID: <91EE3A16-B5E3-4DAA-A299-6B332178B5A0@oracle.com> Actually the JOGL work is one of the old inspirations for Panama. The idea that we could use declarative schema information (instead of imperatives coded C wrappers) to transition between Java and native libraries is found in SWIG, JOGL, Panama, JNR, and many other places. (I did a tech. like that in the mid ?90s for a pre-Java VM.) That said, surely even a JNI code generation tool is worse than something that just runs out of a JAR or jshell session. Eventually, I hope, we will tease apart the aspects of JNI into a proper set of primitives that allows, but does not require, hand written or tool written JNI C code. The primitives I am thinking of these days are: Panama native lookup accesses nearly all native entry point. These are optimizable by the JIT and/or AOT to be equivalent with today?s ad hoc JVM native transition wrappers. And then, a way to program any native method not only via JNI but via an Indy-style bootstrap method. This would lazily generate the body of the native method (driven by declarative information, typically) to a Panama wrapper or some other thing. The endgame is that native methods are fully meta programmable, not losing any JNI use cases (because Panama), but adding other ones, with suitable BSMs. In a world where native methods have BMMs, a JAR file can contain thousands of method definitions and zero byte codes. Each method will be elaborated just in time by a declarative BSM recipe. An AOT compiler can generate the equivalent of JNI stubs if requested but it?s not needed because the (Panama based) runtime knows how to generate the stubs as early or as late as needed. JOGL can stay as it is until it is ready to retool into the more powerful framework. > On Sep 17, 2021, at 9:26 AM, Maurizio Cimadamore wrote: > > ?Hi Martin, > We have no plans to drop support for JNI. JEP 412 offers a replacement which allows libraries to express bindings purely in Java code. In most cases, this is desirable, but I understand that frameworks written prior that JEP might have little to no appetite to rewrite everyting to use MethodHandle/VarHandle and/or jextract. > > As you noted, OpenGL works well with the new foreign APIs, and we have written various samples using OpenGL bindings generated by jextract. > > That said, it is beyond the goal of JEP 412 (and its succesors) to provide an uniform OpenGL API _within the JDK_ - but I think the foreign APIs and the tools (jextract) are now reaching a level of maturity which would allow for such experiments to occur outside the JDK, and we'd be pleased to hear some feedback in the panama-dev mailing list! > > Hope this answers your question > Maurizio > >> On 17/09/2021 12:54, Martin Pernollet wrote: >> Hi, >> >> I actively maintain Jzy3D [1], a framework for drawing 3D charts in Java. It uses JOGL which access native OpenGL with the help of GlueGen, a tool to generate JNI bindings. Jzy3D has an additional OpenGL pure Java CPU renderer [2] to circumvent compatibility limitations of JOGL, mainly for MacOS. >> >> Will JEP-412 close the doors to bindings relying on JNI? In other word will JOGL be able to continue working with GlueGen and JNI? >> >> Are there known plans in OpenJDK for enabling OpenGL (+Metal?) consistently across OS and hardwares via a unified API? II have seen an OpenGL example based on JEP-412 here [3]. I would be interested to assist on that topic and may help making Jzy3D compatible to such API. Jzy3D indeed offers a IPainter interface [4] that allows pluging multiple implementations of OpenGL for Java, hence helping to compare JOGL, EmulGL or any other OpenGL java API. >> >> Thanks in advance, >> >> Martin >> >> [1] http://jzy3d.org/ >> >> [2] https://github.com/jzy3d/jzy3d-api/tree/69a14166096a46bfb6e74cd3ab02e11d41c09024/jzy3d-emul-gl >> [3] https://github.com/sundararajana/panama-jextract-samples/tree/master/opengl >> [4] https://github.com/jzy3d/jzy3d-api/blob/69a14166096a46bfb6e74cd3ab02e11d41c09024/jzy3d-core/src/main/java/org/jzy3d/painters/IPainter.java From uschindler at openjdk.java.net Sat Sep 18 21:11:21 2021 From: uschindler at openjdk.java.net (Uwe Schindler) Date: Sat, 18 Sep 2021 21:11:21 GMT Subject: [foreign-memaccess+abi] RFR: 8273905: Foreign API refresh [v4] In-Reply-To: References: Message-ID: On Fri, 17 Sep 2021 17:16:58 GMT, Maurizio Cimadamore wrote: >> As outlined in [1], there are areas of the foreign API we'd like to improve upon, such as: >> >> * dereference: there is a mismatch between API points which create segments (which take a layout) and dereference API points, which do not take layouts >> >> * role of `MemoryAddress`: in Java 17, `MemoryAddress` has become a stateful carrier, which is attached to a scope. This is inconvenient, as in most cases, a memory address is just a raw pointer that arises when interacting with native code. >> >> * resource scopes: the API for scopes has too many flavors to pick from, many of which overlap. The fact that scopes and segment allocators are unrelated forces clients to introduce ad hoc conversions from scopes to allocators, and library developers to add overloads. Finally, the API for acquiring scopes doesn't work well with try-with-resources, and could also be simplified. >> >> I will add separate comments to explain how the API has changed to resolve the above issues. >> >> [1] - https://mail.openjdk.java.net/pipermail/panama-dev/2021-September/014946.html > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Cleanup up code, following some IDEA suggestions. > * unused imports > * suggestions for new language features > * drop unused impl declarations > * removed size constructor parameter in value layout subclasses (except `OfAddress`) I found some minor javadoc things (just by looking at it and searching for defintiions, so there may be other problems). I did some testing in Apache Lucene with a build of your branch: https://github.com/uschindler/lucene/tree/draft/jdk-foreign-mmap-jdk18 (the relevant change to previous version using the old MemoryCopy stuff is this commit: https://github.com/uschindler/lucene/commit/2de65069a7419edd43f5fc3b63e6e9fa077e2235 The new API looks really good. I also removed all usage of `VarHandle` in the Lucene implementation and just used the versions of `MemorySegment#get(ValueLayout.Xxx,...)` for our positional reads. Interestingly the performance seemed to get a bit better without direct use of VarHandles (maybe because you use `@ForceInline`), but not significant (inside the benchmark's std dev). The most interesting code for you is here: https://github.com/uschindler/lucene/blob/draft/jdk-foreign-mmap-jdk18/lucene/core/src/java/org/apache/lucene/store/MemorySegmentIndexInput.java src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemoryHandles.java line 183: > 181: * 

{@code
> 182:     MemorySegment segment = MemorySegment.allocateNative(2, ResourceScope.newConfinedScope());
> 183:     VarHandle SHORT_VH = ValueLayout.JAVA_SHORT.varHandle(short.class);

The parameter `short.class` in this example is obsolete with new API.

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

> 871:      *                might affect the behavior of the returned memory mapped segment (see {@link #force()}).
> 872:      * @param scope the segment scope.
> 873:      * @return a new mapped memory segment.

Thanks for this change (and the others around the returned segment scope)!

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

Marked as reviewed by uschindler (no project role).

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

From uschindler at openjdk.java.net  Sat Sep 18 21:18:32 2021
From: uschindler at openjdk.java.net (Uwe Schindler)
Date: Sat, 18 Sep 2021 21:18:32 GMT
Subject: [foreign-memaccess+abi] RFR: 8273905: Foreign API refresh [v4]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Sat, 18 Sep 2021 17:20:11 GMT, Uwe Schindler  wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Cleanup up code, following some IDEA suggestions.
>>   * unused imports
>>   * suggestions for new language features
>>   * drop unused impl declarations
>>   * removed size constructor parameter in value layout subclasses (except `OfAddress`)
>
> src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemoryHandles.java line 183:
> 
>> 181:      * 
{@code
>> 182:     MemorySegment segment = MemorySegment.allocateNative(2, ResourceScope.newConfinedScope());
>> 183:     VarHandle SHORT_VH = ValueLayout.JAVA_SHORT.varHandle(short.class);
> 
> The parameter `short.class` in this example is obsolete with new API.

There may be other similar problems at other places!

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

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

From uschindler at openjdk.java.net  Sat Sep 18 21:30:55 2021
From: uschindler at openjdk.java.net (Uwe Schindler)
Date: Sat, 18 Sep 2021 21:30:55 GMT
Subject: [foreign-memaccess+abi] RFR: 8273905: Foreign API refresh [v4]
In-Reply-To: 
References: 
 
Message-ID: <7uO_kUv2kY4rstE6Tleed0lgEa_uyXZd_YZEUbymVGs=.c0e6e909-9af2-48ff-882e-3068f5910169@github.com>

On Fri, 17 Sep 2021 17:16:58 GMT, Maurizio Cimadamore  wrote:

>> As outlined in [1], there are areas of the foreign API we'd like to improve upon, such as:
>> 
>> * dereference: there is a mismatch between API points which create segments (which take a layout) and dereference API points, which do not take layouts
>> 
>> * role of `MemoryAddress`: in Java 17, `MemoryAddress` has become a stateful carrier, which is attached to a scope. This is inconvenient, as in most cases, a memory address is just a raw pointer that arises when interacting with native code.
>> 
>> * resource scopes: the API for scopes has too many flavors to pick from, many of which overlap. The fact that scopes and segment allocators are unrelated forces clients to introduce ad hoc conversions from scopes to allocators, and library developers to add overloads. Finally, the API for acquiring scopes doesn't work well with try-with-resources, and could also be simplified. 
>> 
>> I will add separate comments to explain how the API has changed to resolve the above issues.
>> 
>> [1] - https://mail.openjdk.java.net/pipermail/panama-dev/2021-September/014946.html
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup up code, following some IDEA suggestions.
>   * unused imports
>   * suggestions for new language features
>   * drop unused impl declarations
>   * removed size constructor parameter in value layout subclasses (except `OfAddress`)

Changes requested by uschindler (no project role).

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

> 1542:         Objects.requireNonNull(dstArray);
> 1543:         Objects.requireNonNull(srcLayout);
> 1544:         long baseAndScale = getBaseAndScale(dstArray.getClass());

Should we not add a check that the srcLayout's carrier type fits the dstArray type?

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

> 1578:         Objects.requireNonNull(srcArray);
> 1579:         Objects.requireNonNull(dstSegment);
> 1580:         Objects.requireNonNull(dstLayout);

same here: dstLayout's carrier type should be srcArray's type.

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

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

From zjx001202 at gmail.com  Sun Sep 19 11:11:38 2021
From: zjx001202 at gmail.com (Glavo)
Date: Sun, 19 Sep 2021 19:11:38 +0800
Subject: Will we need to use the --enable-native-access option to enable JNI
 in the future?
Message-ID: 

At present, it seems that JNI will not be restricted. Will the state be
modified in the future?

From jbhateja at openjdk.java.net  Mon Sep 20 04:19:02 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Mon, 20 Sep 2021 04:19:02 GMT
Subject: [vectorIntrinsics+mask] RFR: 8273949: Intrinsic creation for
 VectorMask.toLong operation. [v2]
In-Reply-To: 
References: 
Message-ID: <815z4CBsNPaXEFc_Lpktm41QxtMNWBZA-lf_F6mP75A=.ba97a5ec-b359-4eda-8b54-7d40c52a390f@github.com>

> Summary of changes:
> - Intrinsification of VectorMask.toLong() API.
> - Supports inline expansion for both AVX512 and non-AVX512 targets.
> - Used toLong() API to optimize existing Java API implementation of VectorMask.laneIsSet() operation.
> 
> Following performance number are generated using JMH benchmark modification included with the patch.
> 
> System:  Intel(R) Xeon(R) Platinum 8280 CPU @ 2.70GHz (Cascade Lake Server 28C 2S)
> 
> Benchmark | VECSIZE | Baseline Score (ops/ms) | With Opt (ops/ms) | Gain Ratio
> -- | -- | -- | -- | --
> MaskQueryOperationsBenchmark.testToLongByte | 128 | 90451.424 | 346941.379 | 3.835665196
> MaskQueryOperationsBenchmark.testToLongByte | 256 | 63127.764 | 338331.425 | 5.359471072
> MaskQueryOperationsBenchmark.testToLongByte | 512 | 40543.264 | 313836.333 | 7.740776199
> MaskQueryOperationsBenchmark.testToLongLong | 128 | 171989.714 | 152872.758 | 0.88884826
> MaskQueryOperationsBenchmark.testToLongLong | 256 | 164702.273 | 324794.578 | 1.972010295
> MaskQueryOperationsBenchmark.testToLongLong | 512 | 122667.916 | 318060.096 | 2.59285481
> MaskQueryOperationsBenchmark.testToLongShort | 128 | 122656.408 | 346691.082 | 2.826522378
> MaskQueryOperationsBenchmark.testToLongShort | 256 | 96838.555 | 360909.28 | 3.726917239
> MaskQueryOperationsBenchmark.testToLongShort | 512 | 63119.009 | 313075.159 | 4.960077225
> MaskQueryOperationsBenchmark.testToLonglong | 128 | 180855.623 | 324620.433 | 1.794914792
> MaskQueryOperationsBenchmark.testToLonglong | 256 | 122705.631 | 324315.916 | 2.643040204
> MaskQueryOperationsBenchmark.testToLonglong | 512 | 90396.687 | 324318.095 | 3.58772103

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  8273949: Review comments resolution

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

Changes:
  - all: https://git.openjdk.java.net/panama-vector/pull/126/files
  - new: https://git.openjdk.java.net/panama-vector/pull/126/files/c9110344..f7e689ef

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

  Stats: 129 lines in 33 files changed: 5 ins; 0 del; 124 mod
  Patch: https://git.openjdk.java.net/panama-vector/pull/126.diff
  Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/126/head:pull/126

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

From maurizio.cimadamore at oracle.com  Mon Sep 20 10:17:01 2021
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 20 Sep 2021 11:17:01 +0100
Subject: Will we need to use the --enable-native-access option to enable
 JNI in the future?
In-Reply-To: 
References: 
Message-ID: 

Hi,
While we do not any plan to require so now, many of the reasons as to 
why the flag is added for the foreign Panama API hold true for JNI code. 
As such, It would be not unreasonable, some day, to use the same 
mechanism to restricted access to both (since, after all, there is no 
way for the static compiler, or the JVM, to prove that a program using 
JNI is sound). If we go down this path, it is very likely that it won't 
be a flag-day, where, say, JDK 30 does not require the flag, but JDK 31 
does. It is more likely that we will go through a number of intermediate 
releases where the lack of a flag will result in a runtime warning (not 
unlike to what has been done with illegal reflective access violation 
for modules).

Maurizio


On 19/09/2021 12:11, Glavo wrote:
> At present, it seems that JNI will not be restricted. Will the state be
> modified in the future?

From mcimadamore at openjdk.java.net  Mon Sep 20 10:26:54 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 20 Sep 2021 10:26:54 GMT
Subject: [foreign-memaccess+abi] RFR: 8273905: Foreign API refresh [v4]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Sat, 18 Sep 2021 21:15:26 GMT, Uwe Schindler  wrote:

>> src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemoryHandles.java line 183:
>> 
>>> 181:      * 
{@code
>>> 182:     MemorySegment segment = MemorySegment.allocateNative(2, ResourceScope.newConfinedScope());
>>> 183:     VarHandle SHORT_VH = ValueLayout.JAVA_SHORT.varHandle(short.class);
>> 
>> The parameter `short.class` in this example is obsolete with new API.
>
> There may be other similar problems at other places!

True - always hard to keep samples up to date with API changes - hopefully javadoc snippets will fix this issue :-)

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

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

From mcimadamore at openjdk.java.net  Mon Sep 20 10:26:56 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 20 Sep 2021 10:26:56 GMT
Subject: [foreign-memaccess+abi] RFR: 8273905: Foreign API refresh [v4]
In-Reply-To: <7uO_kUv2kY4rstE6Tleed0lgEa_uyXZd_YZEUbymVGs=.c0e6e909-9af2-48ff-882e-3068f5910169@github.com>
References: 
 
 <7uO_kUv2kY4rstE6Tleed0lgEa_uyXZd_YZEUbymVGs=.c0e6e909-9af2-48ff-882e-3068f5910169@github.com>
Message-ID: 

On Sat, 18 Sep 2021 21:28:08 GMT, Uwe Schindler  wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Cleanup up code, following some IDEA suggestions.
>>   * unused imports
>>   * suggestions for new language features
>>   * drop unused impl declarations
>>   * removed size constructor parameter in value layout subclasses (except `OfAddress`)
>
> src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemorySegment.java line 1580:
> 
>> 1578:         Objects.requireNonNull(srcArray);
>> 1579:         Objects.requireNonNull(dstSegment);
>> 1580:         Objects.requireNonNull(dstLayout);
> 
> same here: dstLayout's carrier type should be srcArray's type.

Good point(s) - I will fix.

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

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

From mcimadamore at openjdk.java.net  Mon Sep 20 10:48:13 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 20 Sep 2021 10:48:13 GMT
Subject: [foreign-memaccess+abi] RFR: 8273905: Foreign API refresh [v5]
In-Reply-To: 
References: 
Message-ID: <4Vxo2gSDg1T89AHLV64rLsx88oPwd5m_4oP51H1u0v0=.05b937ce-6005-400a-843d-bb4d9c157036@github.com>

> As outlined in [1], there are areas of the foreign API we'd like to improve upon, such as:
> 
> * dereference: there is a mismatch between API points which create segments (which take a layout) and dereference API points, which do not take layouts
> 
> * role of `MemoryAddress`: in Java 17, `MemoryAddress` has become a stateful carrier, which is attached to a scope. This is inconvenient, as in most cases, a memory address is just a raw pointer that arises when interacting with native code.
> 
> * resource scopes: the API for scopes has too many flavors to pick from, many of which overlap. The fact that scopes and segment allocators are unrelated forces clients to introduce ad hoc conversions from scopes to allocators, and library developers to add overloads. Finally, the API for acquiring scopes doesn't work well with try-with-resources, and could also be simplified. 
> 
> I will add separate comments to explain how the API has changed to resolve the above issues.
> 
> [1] - https://mail.openjdk.java.net/pipermail/panama-dev/2021-September/014946.html

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

  Address review comments:
  * Fix spurious javadoc references to `MemoryLayouts`
  * Drop one more unused import
  * Add checks to `MemorySegment::copy`: array component should match layout carrier
  * Tweak exception thrown by `MemorySegment::copy` when an unsupported array is passed
  * Add simple negative tests to `TestArrayCopy`

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

Changes:
  - all: https://git.openjdk.java.net/panama-foreign/pull/576/files
  - new: https://git.openjdk.java.net/panama-foreign/pull/576/files/c4bf5b4b..fd58e930

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

  Stats: 40 lines in 3 files changed: 33 ins; 1 del; 6 mod
  Patch: https://git.openjdk.java.net/panama-foreign/pull/576.diff
  Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/576/head:pull/576

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

From mcimadamore at openjdk.java.net  Mon Sep 20 11:04:01 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 20 Sep 2021 11:04:01 GMT
Subject: [foreign-memaccess+abi] RFR: 8273905: Foreign API refresh [v6]
In-Reply-To: 
References: 
Message-ID: 

> As outlined in [1], there are areas of the foreign API we'd like to improve upon, such as:
> 
> * dereference: there is a mismatch between API points which create segments (which take a layout) and dereference API points, which do not take layouts
> 
> * role of `MemoryAddress`: in Java 17, `MemoryAddress` has become a stateful carrier, which is attached to a scope. This is inconvenient, as in most cases, a memory address is just a raw pointer that arises when interacting with native code.
> 
> * resource scopes: the API for scopes has too many flavors to pick from, many of which overlap. The fact that scopes and segment allocators are unrelated forces clients to introduce ad hoc conversions from scopes to allocators, and library developers to add overloads. Finally, the API for acquiring scopes doesn't work well with try-with-resources, and could also be simplified. 
> 
> I will add separate comments to explain how the API has changed to resolve the above issues.
> 
> [1] - https://mail.openjdk.java.net/pipermail/panama-dev/2021-September/014946.html

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

  Clarify javadoc of indexed getters/setters in `MemorySegment`/`MemoryAddress`

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

Changes:
  - all: https://git.openjdk.java.net/panama-foreign/pull/576/files
  - new: https://git.openjdk.java.net/panama-foreign/pull/576/files/fd58e930..0892e92e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=576&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=576&range=04-05

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

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

From sundar at openjdk.java.net  Mon Sep 20 11:05:34 2021
From: sundar at openjdk.java.net (Athijegannathan Sundararajan)
Date: Mon, 20 Sep 2021 11:05:34 GMT
Subject: [foreign-memaccess+abi] RFR: 8273905: Foreign API refresh [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 20 Sep 2021 11:04:01 GMT, Maurizio Cimadamore  wrote:

>> As outlined in [1], there are areas of the foreign API we'd like to improve upon, such as:
>> 
>> * dereference: there is a mismatch between API points which create segments (which take a layout) and dereference API points, which do not take layouts
>> 
>> * role of `MemoryAddress`: in Java 17, `MemoryAddress` has become a stateful carrier, which is attached to a scope. This is inconvenient, as in most cases, a memory address is just a raw pointer that arises when interacting with native code.
>> 
>> * resource scopes: the API for scopes has too many flavors to pick from, many of which overlap. The fact that scopes and segment allocators are unrelated forces clients to introduce ad hoc conversions from scopes to allocators, and library developers to add overloads. Finally, the API for acquiring scopes doesn't work well with try-with-resources, and could also be simplified. 
>> 
>> I will add separate comments to explain how the API has changed to resolve the above issues.
>> 
>> [1] - https://mail.openjdk.java.net/pipermail/panama-dev/2021-September/014946.html
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clarify javadoc of indexed getters/setters in `MemorySegment`/`MemoryAddress`

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemoryAddress.java line 193:

> 191:         }
> 192:     }
> 193: 

Do we still need this?

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

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

From sundar at openjdk.java.net  Mon Sep 20 11:13:13 2021
From: sundar at openjdk.java.net (Athijegannathan Sundararajan)
Date: Mon, 20 Sep 2021 11:13:13 GMT
Subject: [foreign-memaccess+abi] RFR: 8273905: Foreign API refresh [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 20 Sep 2021 11:04:01 GMT, Maurizio Cimadamore  wrote:

>> As outlined in [1], there are areas of the foreign API we'd like to improve upon, such as:
>> 
>> * dereference: there is a mismatch between API points which create segments (which take a layout) and dereference API points, which do not take layouts
>> 
>> * role of `MemoryAddress`: in Java 17, `MemoryAddress` has become a stateful carrier, which is attached to a scope. This is inconvenient, as in most cases, a memory address is just a raw pointer that arises when interacting with native code.
>> 
>> * resource scopes: the API for scopes has too many flavors to pick from, many of which overlap. The fact that scopes and segment allocators are unrelated forces clients to introduce ad hoc conversions from scopes to allocators, and library developers to add overloads. Finally, the API for acquiring scopes doesn't work well with try-with-resources, and could also be simplified. 
>> 
>> I will add separate comments to explain how the API has changed to resolve the above issues.
>> 
>> [1] - https://mail.openjdk.java.net/pipermail/panama-dev/2021-September/014946.html
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clarify javadoc of indexed getters/setters in `MemorySegment`/`MemoryAddress`

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

> 596:      * over the decoding process is required.
> 597:      * @param offset offset in bytes (relative to this segment). For instance, if this segment is a {@link #isNative()} segment,
> 598:      *               the final address of this read operation can be expressed as {@code address().toRowLongValue() + offset}.

Mention of isNative() which is removed.

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

> 614:      * java.nio.charset.CharsetDecoder} class should be used when more control
> 615:      * over the decoding process is required.
> 616:      * @param offset offset in bytes (relative to this segment). For instance, if this segment is a {@link #isNative()} segment,

Mention of ofNative()

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

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

From mcimadamore at openjdk.java.net  Mon Sep 20 11:37:26 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 20 Sep 2021 11:37:26 GMT
Subject: [foreign-memaccess+abi] RFR: 8273905: Foreign API refresh [v7]
In-Reply-To: 
References: 
Message-ID: 

> As outlined in [1], there are areas of the foreign API we'd like to improve upon, such as:
> 
> * dereference: there is a mismatch between API points which create segments (which take a layout) and dereference API points, which do not take layouts
> 
> * role of `MemoryAddress`: in Java 17, `MemoryAddress` has become a stateful carrier, which is attached to a scope. This is inconvenient, as in most cases, a memory address is just a raw pointer that arises when interacting with native code.
> 
> * resource scopes: the API for scopes has too many flavors to pick from, many of which overlap. The fact that scopes and segment allocators are unrelated forces clients to introduce ad hoc conversions from scopes to allocators, and library developers to add overloads. Finally, the API for acquiring scopes doesn't work well with try-with-resources, and could also be simplified. 
> 
> I will add separate comments to explain how the API has changed to resolve the above issues.
> 
> [1] - https://mail.openjdk.java.net/pipermail/panama-dev/2021-September/014946.html

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

  Drop `MemoryAddress::freeMemory`/`MemoryAddress::allocateMemory` leftovers

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

Changes:
  - all: https://git.openjdk.java.net/panama-foreign/pull/576/files
  - new: https://git.openjdk.java.net/panama-foreign/pull/576/files/0892e92e..e648aef6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=576&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=576&range=05-06

  Stats: 140 lines in 13 files changed: 61 ins; 44 del; 35 mod
  Patch: https://git.openjdk.java.net/panama-foreign/pull/576.diff
  Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/576/head:pull/576

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

From mcimadamore at openjdk.java.net  Mon Sep 20 11:40:02 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 20 Sep 2021 11:40:02 GMT
Subject: [foreign-memaccess+abi] RFR: 8273905: Foreign API refresh [v8]
In-Reply-To: 
References: 
Message-ID: 

> As outlined in [1], there are areas of the foreign API we'd like to improve upon, such as:
> 
> * dereference: there is a mismatch between API points which create segments (which take a layout) and dereference API points, which do not take layouts
> 
> * role of `MemoryAddress`: in Java 17, `MemoryAddress` has become a stateful carrier, which is attached to a scope. This is inconvenient, as in most cases, a memory address is just a raw pointer that arises when interacting with native code.
> 
> * resource scopes: the API for scopes has too many flavors to pick from, many of which overlap. The fact that scopes and segment allocators are unrelated forces clients to introduce ad hoc conversions from scopes to allocators, and library developers to add overloads. Finally, the API for acquiring scopes doesn't work well with try-with-resources, and could also be simplified. 
> 
> I will add separate comments to explain how the API has changed to resolve the above issues.
> 
> [1] - https://mail.openjdk.java.net/pipermail/panama-dev/2021-September/014946.html

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

  Fix javadoc for `MemoryAddress::setUtf8String`

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

Changes:
  - all: https://git.openjdk.java.net/panama-foreign/pull/576/files
  - new: https://git.openjdk.java.net/panama-foreign/pull/576/files/e648aef6..dac6c6e8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=576&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=576&range=06-07

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

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

From mcimadamore at openjdk.java.net  Mon Sep 20 12:19:34 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 20 Sep 2021 12:19:34 GMT
Subject: [foreign-memaccess+abi] RFR: 8273905: Foreign API refresh [v9]
In-Reply-To: 
References: 
Message-ID: <_nWQha6wNaHRnELQX4QEhloSXy07Nb_D2rPgDAQ0wV0=.bdc8f966-7969-40da-9919-cf96c98a1563@github.com>

> As outlined in [1], there are areas of the foreign API we'd like to improve upon, such as:
> 
> * dereference: there is a mismatch between API points which create segments (which take a layout) and dereference API points, which do not take layouts
> 
> * role of `MemoryAddress`: in Java 17, `MemoryAddress` has become a stateful carrier, which is attached to a scope. This is inconvenient, as in most cases, a memory address is just a raw pointer that arises when interacting with native code.
> 
> * resource scopes: the API for scopes has too many flavors to pick from, many of which overlap. The fact that scopes and segment allocators are unrelated forces clients to introduce ad hoc conversions from scopes to allocators, and library developers to add overloads. Finally, the API for acquiring scopes doesn't work well with try-with-resources, and could also be simplified. 
> 
> I will add separate comments to explain how the API has changed to resolve the above issues.
> 
> [1] - https://mail.openjdk.java.net/pipermail/panama-dev/2021-September/014946.html

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

  * Drop more unused imports
  * Fix javadoc of `UpcallStub` so that summary does not contain link.
  * Add `@throws IllegalArgumentException` on `ResourceScope::keepAlive`
  * Add `@throws IllegalStateException` on `ResourceScope::keepAlive`
  * Add resource scope test to check that keeping alive self is not allowed

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

Changes:
  - all: https://git.openjdk.java.net/panama-foreign/pull/576/files
  - new: https://git.openjdk.java.net/panama-foreign/pull/576/files/dac6c6e8..a7541361

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=576&range=08
 - incr: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=576&range=07-08

  Stats: 21 lines in 5 files changed: 13 ins; 4 del; 4 mod
  Patch: https://git.openjdk.java.net/panama-foreign/pull/576.diff
  Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/576/head:pull/576

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

From zjx001202 at gmail.com  Mon Sep 20 13:07:13 2021
From: zjx001202 at gmail.com (Glavo)
Date: Mon, 20 Sep 2021 21:07:13 +0800
Subject: Will we need to use the --enable-native-access option to enable
 JNI in the future?
In-Reply-To: 
References: 
 
Message-ID: 

Honestly, as the author of the library, I am extremely disappointed
with this answer. I will choose to give up my expectation of Panama
until 2031 (Java 8 and 17 are out of support).

I think that under the current situation, it is extremely stupid to
restrict Panama by default. Its only significance at present is to
recommend users to use JNI/JNA/JNR instead of Panama.

At present, --enable-native-access option has nothing to do with
safety at all: Because of the existence of JNI, a module can do
anything without it. Since it can't provide any safety guarantee
at all, and at the same time it brings some additional usability
issues, it will only limit the promotion of Panama.

The usability issues brought about by this option have been complained
by other people a long time ago, and I have not seen anyone around
me who are satisfied with this option. I don't want to repeat all these
questions here, because I believe you have heard them many times.
And I think some of these issues  can be alleviated by improving other
features of the OpenJDK, e.g. adding an alternative to MANIFEST.MF
for modular programs, allow options such as --add-opens and
--enable-native-access to be written into it.

Now what I want to emphasize here is that as a more restricted alternative
to existing features, there is a lot of resistance to migrating to Panama.
Before restricting JNI, the so-called safety is just a fig leaf,
it?s just self-deception. This meaningless constraint will not restrict
the user's behavior at all, but will only hinder the user from choosing
this road - because there is an unobstructed road nearby.

I would like to give a proposal here, which I think will minimize the
obstacles to the promotion of Panama:

  While providing the --enable-native-access option, it also provides
  a --illegal-native-access=(*silent*|*warn*|*deny*) option.

  At first, the default value is *silent*, and there are no restrictions on
  the use of Panama.

  When you are ready to limit JNI, apply this option to JNI at the same
time,
  and adjust the default value to *warn *to warn the use of JNI and Panama,
  and use --enable-native-access to eliminate the warning for a module.

  After several versions, adjust it to *deny *by default to prevent
unauthorized
  native operations, and completely remove this option in a later version.


I like the work of Panama very much, but I am very disappointed by
the current restrictions. For the last time, I want to emphasize that
restricting Panama alone will only refuse users to use it.
If you insist on this choice, I will tell you:

  Thank you for your contributions to the Java 8 ecosystem.
  And I sincerely thank you, because my library users don't have to
  ask me why they need to upgrade to Java 21.

(This email is written by Google translation. Please forgive me for the
syntax error)

Maurizio Cimadamore  ?2021?9?20??? ??6:17???

> Hi,
> While we do not any plan to require so now, many of the reasons as to
> why the flag is added for the foreign Panama API hold true for JNI code.
> As such, It would be not unreasonable, some day, to use the same
> mechanism to restricted access to both (since, after all, there is no
> way for the static compiler, or the JVM, to prove that a program using
> JNI is sound). If we go down this path, it is very likely that it won't
> be a flag-day, where, say, JDK 30 does not require the flag, but JDK 31
> does. It is more likely that we will go through a number of intermediate
> releases where the lack of a flag will result in a runtime warning (not
> unlike to what has been done with illegal reflective access violation
> for modules).
>
> Maurizio
>
>
> On 19/09/2021 12:11, Glavo wrote:
> > At present, it seems that JNI will not be restricted. Will the state be
> > modified in the future?
>

From mcimadamore at openjdk.java.net  Mon Sep 20 13:16:07 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 20 Sep 2021 13:16:07 GMT
Subject: [foreign-memaccess+abi] RFR: 8273905: Foreign API refresh [v10]
In-Reply-To: 
References: 
Message-ID: 

> As outlined in [1], there are areas of the foreign API we'd like to improve upon, such as:
> 
> * dereference: there is a mismatch between API points which create segments (which take a layout) and dereference API points, which do not take layouts
> 
> * role of `MemoryAddress`: in Java 17, `MemoryAddress` has become a stateful carrier, which is attached to a scope. This is inconvenient, as in most cases, a memory address is just a raw pointer that arises when interacting with native code.
> 
> * resource scopes: the API for scopes has too many flavors to pick from, many of which overlap. The fact that scopes and segment allocators are unrelated forces clients to introduce ad hoc conversions from scopes to allocators, and library developers to add overloads. Finally, the API for acquiring scopes doesn't work well with try-with-resources, and could also be simplified. 
> 
> I will add separate comments to explain how the API has changed to resolve the above issues.
> 
> [1] - https://mail.openjdk.java.net/pipermail/panama-dev/2021-September/014946.html

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

  * Add implNote on `ResourceScope#keepAlive` documenting the maximum number of keep alive requests
  * Make sure that the keep alive limit is also enforced in confined scope implementations

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

Changes:
  - all: https://git.openjdk.java.net/panama-foreign/pull/576/files
  - new: https://git.openjdk.java.net/panama-foreign/pull/576/files/a7541361..162cb936

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=576&range=09
 - incr: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=576&range=08-09

  Stats: 12 lines in 5 files changed: 6 ins; 1 del; 5 mod
  Patch: https://git.openjdk.java.net/panama-foreign/pull/576.diff
  Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/576/head:pull/576

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

From maurizio.cimadamore at oracle.com  Mon Sep 20 13:44:48 2021
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 20 Sep 2021 14:44:48 +0100
Subject: Will we need to use the --enable-native-access option to enable
 JNI in the future?
In-Reply-To: 
References: 
 
 
Message-ID: 


On 20/09/2021 14:07, Glavo wrote:
> Honestly, as the author of the library, I am extremely disappointed
> with this answer. I will choose to give up my expectation of Panama
> until 2031 (Java 8 and 17 are out of support).
>
> I think that under the current situation, it is extremely stupid to
> restrict Panama by default. Its only significance at present is to
> recommend users to use JNI/JNA/JNR instead of Panama.

I note that the word "extremely stupid" might have come from the 
automatic Google translation - it is a bit on the offsensive, side, but 
I'll ignore, given the circumstances.

What I'm more intersted in is - what make you think that adding extra 
command line flags would be perceived as such a blocker? Do you have 
examples in mind where this might turn out to be problematic in practice?

>
> At present, --enable-native-access option has nothing to do with
> safety at all: Because of the existence of JNI, a module can do
> anything without it. Since it can't provide any safety guarantee
> at all, and at the same time it brings some additional usability
> issues, it will only limit the promotion of Panama.

Saying that, since JNI is unsafe and enabled-by-default, then Panama 
should just follow suit, seems like an ill-conceived argument. Because 
something else is not great (for historical reasons - modules weren't 
there when JNI was born), doesn't, in my opinion, justify making 
everything else bad too, just because of that precedent.

It is true that JNI is a permanent safety hole in the JDK, but it would 
be naive to assume we can turn it off overnight; at the same time, since 
Panama is a new API, I think we have an opportunity to make at least the 
new usages of native code safer.

Note also that, in JNI, most of the unsafety comes from within JNI C 
glue code (e.g. the so called JNI functions). This glue code is no 
longer there in Panama - since it can be simply expressed as Java code. 
So, the Panama API faces a risk which was much less real with JNI: 
having seemingly innocent, pure Java code crashing the JVM. All this 
reasoning is explained, in greated details, in JEP 412.

>
> The usability issues brought about by this option have been complained
> by other people a long time ago, and I have not seen anyone around
> me who are satisfied with this option. I don't want to repeat all these
> questions here, because I believe you have heard them many times.
> And I think some of these issues? can be alleviated by improving other
> features of the OpenJDK, e.g. adding an alternative to MANIFEST.MF
> for modular programs, allow options such as --add-opens and
> --enable-native-access to be written into it.
I think adding better support for this in manifest is probably a good 
thing to explore, yes. At the same time your premise (many complains, no 
one likes it), seems at fault; the rationale behind guarding some unsafe 
corners of the Panama API behind a flag were discussed, and considered 
better than the alternatives (e.g. at some point we experimented with an 
unsafe module, which users had to enable manually - which was worse, 
both for usability and API discoverability). Of course in a mailing list 
such as this one (but this is true of many internet media), you will be 
more likely to find negative feedback on any given topic than positive 
feedback - but one shouldn't assume too much from that. To be honest, 
since we moved to the new command line option, this issue has not even 
been brought up again, which makes me think that, in reality, most 
developers understand where the option is coming from.
>
> Now what I want to emphasize here is that as a more restricted 
> alternative
> to existing features, there is a lot of resistance to migrating to 
> Panama.
> Before restricting JNI, the so-called safety is just a fig leaf,
> it?s just self-deception. This meaningless constraint will not restrict
> the user's behavior at all, but will only hinder the user from choosing
> this road - because there is an unobstructed road nearby.
Again, your argument seems to be "since w/o restricting JNI we can't 
make the platform fully safe, why even try" - but the same argument 
would apply to a lot of other stuff too. We have to start somewhere - 
note that even if JNI would be restricted we'd still have Unsafe around. 
`--enable-native-access` is an attempt to draw a path, where we'd like 
to move the platform in the next N years. Of course I understand that, 
if you pick this particular point in time (e.g. 2021), the picture is 
not perfect, but I think that we have a path to get there. If Panama was 
just unrestricted from the start, it would be much harder to restrict it 
later on (which is why we have to be careful with JNI).
>
> I would like to give a proposal here, which I think will minimize the
> obstacles to the promotion of Panama:
>
> ? While providing the --enable-native-access option, it also provides
> ? a --illegal-native-access=(*silent*|*warn*|*deny*) option.
>
> ? At first, the default value is *silent*, and there are no 
> restrictions on
> ? the use of Panama.
>
> ? When you are ready to limit JNI, apply this option to JNI at the 
> same time,
> ? and adjust the default value to *warn *to warn the use of JNI and 
> Panama,
> ? and use --enable-native-access to eliminate the warning for a module.
>
> ? After several versions, adjust it to *deny *by default to prevent 
> unauthorized
> ? native operations, and completely remove this option in a later version.

This plan is good on paper, except that if the default is silent for 
both Panama and JNI there is no incentive for people using Panama (which 
is a new API) to get the act together.

Overall, the arguments in this email are a mixture of:

* since JNI is unsafe anyway, what's the point of restricting Panama
* restricting Panama will hinder adoption in some way

Now, I think both arguments can be turned on their heads; let's not 
think about existing code that wants to migrate from JNI to Panama - 
let's focus on _new_ code instead. If you write bindings for a C library 
post Java 17, it is much more likely that you will find that JEP 412 (+ 
jextract) gives you all you want. Will you be put off by extra command 
line flags? I don't think so - if your application requires native 
libraries, you will likely need flags (e.g. java.library.path) anyway. 
Will you be put off by the fact that JNI doesn't share the same 
restriction? Well, no - since you opted into Panama from the beginning, 
so JNI is most likely in your rearview mirror.

Let's also think of users of the Panama API who couldn't care less about 
native interop (there are some in this mailing list) - e.g. developers 
who only use the foreign API to allocate, access and free memory off 
heap. Very likely, these developer would like to take advantage of the 
extra protection provided by the --enable-native-access flag, to make 
sure they don't accidentally depend on unsafe functionalities they do 
not require.

>
>
> I like the work of Panama very much, but I am very disappointed by
> the current restrictions. For the last time, I want to emphasize that
> restricting Panama alone will only refuse users to use it.
> If you insist on this choice, I will tell you:

Again, "users" is very vague here. There are "users" who have existing 
code bases, who made lots of investments in JNI. I believe for these 
users the decision whether or not to use the new API has to consider a 
lot more factors than just "how many flags will I need with the new 
API". Then there are "users" writing new applications, or frameworks 
from scratch. These users will likely use Panam instead, not because 
it's newer, or shinier, but simply because it reduces the number of 
pieces they have to maintain going forward (e.g. no more JNI 
intermediate goop). For these users, the presence of the new flag is 
probably not very disruptive - from their perspective that's just how 
things are in Panama.

Thanks for the comments - I think you raise some valid points regarding 
safety and JNI - but I think that ultimately, picking a worse solution 
just because there are other broken areas which won't be fixed 
immediately is not a great decision, and is probably one which will just 
regret later.

Maurizio

>
> ? Thank you for your contributions to the Java 8 ecosystem.
> ? And I sincerely thank you, because my library users don't have to
> ? ask me why they need to upgrade to Java 21.
> (This email is written by Google translation. Please forgive me for 
> the syntax error)
>
> Maurizio Cimadamore  > ?2021?9?20??? 
> ??6:17???
>
>     Hi,
>     While we do not any plan to require so now, many of the reasons as to
>     why the flag is added for the foreign Panama API hold true for JNI
>     code.
>     As such, It would be not unreasonable, some day, to use the same
>     mechanism to restricted access to both (since, after all, there is no
>     way for the static compiler, or the JVM, to prove that a program
>     using
>     JNI is sound). If we go down this path, it is very likely that it
>     won't
>     be a flag-day, where, say, JDK 30 does not require the flag, but
>     JDK 31
>     does. It is more likely that we will go through a number of
>     intermediate
>     releases where the lack of a flag will result in a runtime warning
>     (not
>     unlike to what has been done with illegal reflective access violation
>     for modules).
>
>     Maurizio
>
>
>     On 19/09/2021 12:11, Glavo wrote:
>     > At present, it seems that JNI will not be restricted. Will the
>     state be
>     > modified in the future?
>

From maurizio.cimadamore at oracle.com  Mon Sep 20 14:35:18 2021
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 20 Sep 2021 15:35:18 +0100
Subject: [foreign-memaccess+abi] RFR: 8273905: Foreign API refresh [v4]
In-Reply-To: 
References: 
 
 
Message-ID: <5cebb718-92d3-3204-b480-0687806ec2a9@oracle.com>

Many thanks for testing this and confirming that there are no regressions!

Maurizio

On 18/09/2021 22:11, Uwe Schindler wrote:
> I did some testing in Apache Lucene with a build of your branch:https://github.com/uschindler/lucene/tree/draft/jdk-foreign-mmap-jdk18  (the relevant change to previous version using the old MemoryCopy stuff is this commit:https://github.com/uschindler/lucene/commit/2de65069a7419edd43f5fc3b63e6e9fa077e2235
>
> The new API looks really good. I also removed all usage of `VarHandle` in the Lucene implementation and just used the versions of `MemorySegment#get(ValueLayout.Xxx,...)` for our positional reads. Interestingly the performance seemed to get a bit better without direct use of VarHandles (maybe because you use `@ForceInline`), but not significant (inside the benchmark's std dev).
>
> The most interesting code for you is here:https://github.com/uschindler/lucene/blob/draft/jdk-foreign-mmap-jdk18/lucene/core/src/java/org/apache/lucene/store/MemorySegmentIndexInput.java

From brian.goetz at oracle.com  Mon Sep 20 14:39:45 2021
From: brian.goetz at oracle.com (Brian Goetz)
Date: Mon, 20 Sep 2021 10:39:45 -0400
Subject: Will we need to use the --enable-native-access option to enable
 JNI in the future?
In-Reply-To: 
References: 
 
 
 
Message-ID: <88b4d488-97c5-31d1-5d4f-b249e924771d@oracle.com>


> Overall, the arguments in this email are a mixture of:
>
> * since JNI is unsafe anyway, what's the point of restricting Panama
> * restricting Panama will hinder adoption in some way 

Developers frequently make these arguments with the mistaken assumption 
they are arguing *against* the restrictions.? But these arguments could 
be equally well applied to "so let's lock down JNI as soon as 
possible!"? And if it is in fact either-or (which it isn't, as Maurizio 
points out), we have to ask ourselves which approach gets us to a better 
place in the long run.? And that is clearly "lock down unsafe native 
code so that the application assembler has to consent".

Now, it isn't either-or, which is what makes the current path the 
pragmatic choice -- make Panama safe from day 1, and follow up with 
making JNI safer later.



From pedro.lamarao at prodist.com.br  Mon Sep 20 15:12:31 2021
From: pedro.lamarao at prodist.com.br (=?UTF-8?Q?Pedro_Lamar=C3=A3o?=)
Date: Mon, 20 Sep 2021 12:12:31 -0300
Subject: Will we need to use the --enable-native-access option to enable
 JNI in the future?
In-Reply-To: 
References: 
 
 
 
Message-ID: 

Em seg., 20 de set. de 2021 ?s 10:45, Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> escreveu:


> Now, I think both arguments can be turned on their heads; let's not
> think about existing code that wants to migrate from JNI to Panama -
> let's focus on _new_ code instead. If you write bindings for a C library
> post Java 17, it is much more likely that you will find that JEP 412 (+
> jextract) gives you all you want. Will you be put off by extra command
> line flags? I don't think so - if your application requires native
> libraries, you will likely need flags (e.g. java.library.path) anyway.
> Will you be put off by the fact that JNI doesn't share the same
> restriction? Well, no - since you opted into Panama from the beginning,
> so JNI is most likely in your rearview mirror.
>

Let me offset the balance by contributing my expectation, which fits the
above description.
Our shop does "security" in the sense of operating security modules, in
particular hardware security modules.
Currently, the value we obtain from Java's superior tooling is diminished
by the cost of maintaining JNI code.
The "other choice" would be to use a language that, albeit with inferior
tooling, offers improved "native interop".
This equation is going to change significantly, in our perception, when
Panama is complete.
The inconvenience of some command line option which must be put in some
runtime configuration file is negligible in our engineering equation.

-- 
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 martin.pernollet at protonmail.com  Mon Sep 20 12:24:34 2021
From: martin.pernollet at protonmail.com (Martin Pernollet)
Date: Mon, 20 Sep 2021 12:24:34 +0000
Subject: JEP-412 & OpenGL
In-Reply-To: <91EE3A16-B5E3-4DAA-A299-6B332178B5A0@oracle.com>
References: 
 <44916ce4-1174-28d0-6cff-28ee6ac7b487@oracle.com>
 <91EE3A16-B5E3-4DAA-A299-6B332178B5A0@oracle.com>
Message-ID: <20IAXMh_D5CwrlzRuub4xeEQVgsdy_SG-PGZ_mFzrEPcaCOUWu2_6lwXTxR10bHTJmUQW8Xaq0xnen8Fmp65kBkg3Nikf1y-h2zDL-80-lI=@protonmail.com>

Thank you all for your answers.

I'll give a try in the coming weeks and will tell you how this works.

Martin

Sent with ProtonMail Secure Email.

??????? Original Message ???????

Le samedi 18 septembre 2021 ? 12:56, John Rose  a ?crit :

> Actually the JOGL work is one of the old inspirations for Panama.
>
> The idea that we could use declarative schema information (instead of imperatives coded C wrappers) to transition between Java and native libraries is found in SWIG, JOGL, Panama, JNR, and many other places. (I did a tech. like that in the mid ?90s for a pre-Java VM.)
>
> That said, surely even a JNI code generation tool is worse than something that just runs out of a JAR or jshell session. Eventually, I hope, we will tease apart the aspects of JNI into a proper set of primitives that allows, but does not require, hand written or tool written JNI C code.
>
> The primitives I am thinking of these days are:
>
> Panama native lookup accesses nearly all native entry point.
>
> These are optimizable by the JIT and/or AOT to be equivalent with today?s ad hoc JVM native transition wrappers.
>
> And then, a way to program any native method not only via JNI but via an Indy-style bootstrap method. This would lazily generate the body of the native method (driven by declarative information, typically) to a Panama wrapper or some other thing.
>
> The endgame is that native methods are fully meta programmable, not losing any JNI use cases (because Panama), but adding other ones, with suitable BSMs.
>
> In a world where native methods have BMMs, a JAR file can contain thousands of method definitions and zero byte codes. Each method will be elaborated just in time by a declarative BSM recipe. An AOT compiler can generate the equivalent of JNI stubs if requested but it?s not needed because the (Panama based) runtime knows how to generate the stubs as early or as late as needed.
>
> JOGL can stay as it is until it is ready to retool into the more powerful framework.
>
> > On Sep 17, 2021, at 9:26 AM, Maurizio Cimadamore Maurizio.Cimadamore at oracle.com wrote:
> >
> > Hi Martin,
> >
> > We have no plans to drop support for JNI. JEP 412 offers a replacement which allows libraries to express bindings purely in Java code. In most cases, this is desirable, but I understand that frameworks written prior that JEP might have little to no appetite to rewrite everyting to use MethodHandle/VarHandle and/or jextract.
> >
> > As you noted, OpenGL works well with the new foreign APIs, and we have written various samples using OpenGL bindings generated by jextract.
> >
> > That said, it is beyond the goal of JEP 412 (and its succesors) to provide an uniform OpenGL API within the JDK - but I think the foreign APIs and the tools (jextract) are now reaching a level of maturity which would allow for such experiments to occur outside the JDK, and we'd be pleased to hear some feedback in the panama-dev mailing list!
> >
> > Hope this answers your question
> >
> > Maurizio
> >
> > > On 17/09/2021 12:54, Martin Pernollet wrote:
> > >
> > > Hi,
> > >
> > > I actively maintain Jzy3D [1], a framework for drawing 3D charts in Java. It uses JOGL which access native OpenGL with the help of GlueGen, a tool to generate JNI bindings. Jzy3D has an additional OpenGL pure Java CPU renderer [2] to circumvent compatibility limitations of JOGL, mainly for MacOS.
> > >
> > > Will JEP-412 close the doors to bindings relying on JNI? In other word will JOGL be able to continue working with GlueGen and JNI?
> > >
> > > Are there known plans in OpenJDK for enabling OpenGL (+Metal?) consistently across OS and hardwares via a unified API? II have seen an OpenGL example based on JEP-412 here [3]. I would be interested to assist on that topic and may help making Jzy3D compatible to such API. Jzy3D indeed offers a IPainter interface [4] that allows pluging multiple implementations of OpenGL for Java, hence helping to compare JOGL, EmulGL or any other OpenGL java API.
> > >
> > > Thanks in advance,
> > >
> > > Martin
> > >
> > > [1] http://jzy3d.org/
> > >
> > > [2] https://github.com/jzy3d/jzy3d-api/tree/69a14166096a46bfb6e74cd3ab02e11d41c09024/jzy3d-emul-gl
> > >
> > > [3] https://github.com/sundararajana/panama-jextract-samples/tree/master/opengl
> > >
> > > [4] https://github.com/jzy3d/jzy3d-api/blob/69a14166096a46bfb6e74cd3ab02e11d41c09024/jzy3d-core/src/main/java/org/jzy3d/painters/IPainter.java

From psandoz at openjdk.java.net  Mon Sep 20 15:43:36 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Mon, 20 Sep 2021 15:43:36 GMT
Subject: [vectorIntrinsics+mask] RFR: 8273949: Intrinsic creation for
 VectorMask.toLong operation. [v2]
In-Reply-To: <815z4CBsNPaXEFc_Lpktm41QxtMNWBZA-lf_F6mP75A=.ba97a5ec-b359-4eda-8b54-7d40c52a390f@github.com>
References: 
 <815z4CBsNPaXEFc_Lpktm41QxtMNWBZA-lf_F6mP75A=.ba97a5ec-b359-4eda-8b54-7d40c52a390f@github.com>
Message-ID: 

On Mon, 20 Sep 2021 04:19:02 GMT, Jatin Bhateja  wrote:

>> Summary of changes:
>> - Intrinsification of VectorMask.toLong() API.
>> - Supports inline expansion for both AVX512 and non-AVX512 targets.
>> - Used toLong() API to optimize existing Java API implementation of VectorMask.laneIsSet() operation.
>> 
>> Following performance number are generated using JMH benchmark modification included with the patch.
>> 
>> System:  Intel(R) Xeon(R) Platinum 8280 CPU @ 2.70GHz (Cascade Lake Server 28C 2S)
>> 
>> Benchmark | VECSIZE | Baseline Score (ops/ms) | With Opt (ops/ms) | Gain Ratio
>> -- | -- | -- | -- | --
>> MaskQueryOperationsBenchmark.testToLongByte | 128 | 90451.424 | 346941.379 | 3.835665196
>> MaskQueryOperationsBenchmark.testToLongByte | 256 | 63127.764 | 338331.425 | 5.359471072
>> MaskQueryOperationsBenchmark.testToLongByte | 512 | 40543.264 | 313836.333 | 7.740776199
>> MaskQueryOperationsBenchmark.testToLongLong | 128 | 171989.714 | 152872.758 | 0.88884826
>> MaskQueryOperationsBenchmark.testToLongLong | 256 | 164702.273 | 324794.578 | 1.972010295
>> MaskQueryOperationsBenchmark.testToLongLong | 512 | 122667.916 | 318060.096 | 2.59285481
>> MaskQueryOperationsBenchmark.testToLongShort | 128 | 122656.408 | 346691.082 | 2.826522378
>> MaskQueryOperationsBenchmark.testToLongShort | 256 | 96838.555 | 360909.28 | 3.726917239
>> MaskQueryOperationsBenchmark.testToLongShort | 512 | 63119.009 | 313075.159 | 4.960077225
>> MaskQueryOperationsBenchmark.testToLonglong | 128 | 180855.623 | 324620.433 | 1.794914792
>> MaskQueryOperationsBenchmark.testToLonglong | 256 | 122705.631 | 324315.916 | 2.643040204
>> MaskQueryOperationsBenchmark.testToLonglong | 512 | 90396.687 | 324318.095 | 3.58772103
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8273949: Review comments resolution

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractMask.java line 68:

> 66:         if (i < 0 || i >= length()) {
> 67:             throw new IllegalArgumentException("Index " + i + " must be zero or positive, and less than " + length());
> 68:         }

Apologies i should have previously said use `Objects.checkIndex(i, length())`. In fact lets call `length` once:

    int length = length();
    Objects.checkIndex(i, length);
    if (length <= Long.SIZE) {
    ...


Separately i wonder if the second bounds check should be `if i <= Long.SIZE`, since the first bounds check should dominate in many cases?

(I know there are other areas where we should `Objects.checkIndex` e.g. `*MaxVector.lane/withLane` but we can fix those later.)

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

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

From zjx001202 at gmail.com  Mon Sep 20 17:06:10 2021
From: zjx001202 at gmail.com (Glavo)
Date: Tue, 21 Sep 2021 01:06:10 +0800
Subject: Will we need to use the --enable-native-access option to enable
 JNI in the future?
In-Reply-To: 
References: 
 
 
 
Message-ID: 

Because my English is very poor, I may not know enough about the
exact meaning of words. If my words are too offensive, I apologize.

What I'm more intersted in is - what make you think that adding extra
> command line flags would be perceived as such a blocker? Do you have
> examples in mind where this might turn out to be problematic in practice?


I think there are a lot of possible blockers:

  * Most obviously, we have lost the ability to simply execute with java
-m.
    Now we can only go back to the classpath and describe it in MANIFEST.MF
(if supported in the future).
    If it is not supported, we even lose the ability to double-click to
open the jar on windows.
    We can only consider wrapping the jar with a third-party solution.
  * Maybe I missed something. I remember there were relevant discussions
before,
    but there still seems to be no way to enable native access for modules
at runtime in Java 17.
    If so, how to enable a module defined at run time using custom
ModuleLayer to use Panama?
    If not, it will be a devastating blow to any dynamic plugin mechanism,
e.g. Minecraft mods.
  * This assumes that I always know all the modules when I start the
program,
    but this is not necessarily the case. For example, the most typical is
the ServiceLoader.
    Some components expect to work only by putting them on the module path,
    such as a implementation of FileSystem or a ScriptEngine.
  * Windows cmd limits the maximum length of a single command to 8192.
    We have some use cases to export a single bat script file that can be
started
    by double clicking for novice users. We are often close to this
boundary, and continuing
    to increase the length of the command line will exacerbate this problem.
  * and more...

Saying that, since JNI is unsafe and enabled-by-default, then Panama should
> just follow suit, seems like an ill-conceived argument. Because something
> else is not great (for historical reasons - modules weren't there when JNI
> was born), doesn't, in my opinion, justify making everything else bad too,
> just because of that precedent.
>

In fact, I am not entirely opposed to restricting native access.
However, the premise is that this option, like its name, really needs
to enable native access. However, at present, even without it,
it does not mean that the module cannot to native access.
This naming is extremely misleading. It can't bring real security to users.

Note also that, in JNI, most of the unsafety comes from within JNI C glue
> code (e.g. the so called JNI functions). This glue code is no longer there
> in Panama - since it can be simply expressed as Java code. So, the Panama
> API faces a risk which was much less real with JNI: having seemingly
> innocent, pure Java code crashing the JVM. All this reasoning is explained,
> in greated details, in JEP 412.
>

I understand this, which is the only reason I can partially agree.
If it just block me at compile time, need me to explicitly enable it
with annotations or compiler parameters, and I'd like to see that.
But why do my end users need to confirm my choice?
Does TA need to be clearly aware that my library, as a third-party library,
is using java code instead of native code to implement binding?

I think adding better support for this in manifest is probably a good thing
> to explore, yes. At the same time your premise (many complains, no one
> likes it), seems at fault; the rationale behind guarding some unsafe
> corners of the Panama API behind a flag were discussed, and considered
> better than the alternatives (e.g. at some point we experimented with an
> unsafe module, which users had to enable manually - which was worse, both
> for usability and API discoverability). Of course in a mailing list such as
> this one (but this is true of many internet media), you will be more likely
> to find negative feedback on any given topic than positive feedback - but
> one shouldn't assume too much from that. To be honest, since we moved to
> the new command line option, this issue has not even been brought up again,
> which makes me think that, in reality, most developers understand where the
> option is coming from.

The premise of my sentence is among the people around me,
among those who have daily close communication with me.
Among these people, game developers, game engine developers
and other types of native binding library authors pay attention to Panama.
They are concerned about the development of JDK, but prefer to
communicate in private groups rather than mailing lists.
At least among these people, I have never received any positive
feedback for these restrictions, not at all. The best attitude is just
indifference,
and most of them complain about it.

Now, I think both arguments can be turned on their heads; let's not think
> about existing code that wants to migrate from JNI to Panama - let's focus
> on _new_ code instead. If you write bindings for a C library post Java 17,
> it is much more likely that you will find that JEP 412 (+ jextract) gives
> you all you want. Will you be put off by extra command line flags? I don't
> think so - if your application requires native libraries, you will likely
> need flags (e.g. java.library.path) anyway. Will you be put off by the fact
> that JNI doesn't share the same restriction? Well, no - since you opted
> into Panama from the beginning, so JNI is most likely in your rearview
> mirror.
>

 I won't talk about how realistic it is for JNI to migrate to Panama.
How to define the _new_? Do you think this is the era of Java 17?
No, this is the era of Java 8, 11 and 17. Before 2031, in these nine years,
there is no reason to support Java 8, but only reason to give up.
In these nine years, any blocker will have a significant impact on
the promotion of an alternative without introducing new capabilities.

Let's also think of users of the Panama API who couldn't care less about
> native interop (there are some in this mailing list) - e.g. developers who
> only use the foreign API to allocate, access and free memory off heap. Very
> likely, these developer would like to take advantage of the extra
> protection provided by the --enable-native-access flag, to make sure they
> don't accidentally depend on unsafe functionalities they do not require.
>

 The same as above, why can't you restrict it at compile time and put it at
run time?

Maurizio Cimadamore  ?2021?9?20??? ??9:45???

>
> On 20/09/2021 14:07, Glavo wrote:
>
> Honestly, as the author of the library, I am extremely disappointed
> with this answer. I will choose to give up my expectation of Panama
> until 2031 (Java 8 and 17 are out of support).
>
> I think that under the current situation, it is extremely stupid to
> restrict Panama by default. Its only significance at present is to
> recommend users to use JNI/JNA/JNR instead of Panama.
>
> I note that the word "extremely stupid" might have come from the automatic
> Google translation - it is a bit on the offsensive, side, but I'll ignore,
> given the circumstances.
>
> What I'm more intersted in is - what make you think that adding extra
> command line flags would be perceived as such a blocker? Do you have
> examples in mind where this might turn out to be problematic in practice?
>
>
> At present, --enable-native-access option has nothing to do with
> safety at all: Because of the existence of JNI, a module can do
> anything without it. Since it can't provide any safety guarantee
> at all, and at the same time it brings some additional usability
> issues, it will only limit the promotion of Panama.
>
> Saying that, since JNI is unsafe and enabled-by-default, then Panama
> should just follow suit, seems like an ill-conceived argument. Because
> something else is not great (for historical reasons - modules weren't there
> when JNI was born), doesn't, in my opinion, justify making everything else
> bad too, just because of that precedent.
>
> It is true that JNI is a permanent safety hole in the JDK, but it would be
> naive to assume we can turn it off overnight; at the same time, since
> Panama is a new API, I think we have an opportunity to make at least the
> new usages of native code safer.
>
> Note also that, in JNI, most of the unsafety comes from within JNI C glue
> code (e.g. the so called JNI functions). This glue code is no longer there
> in Panama - since it can be simply expressed as Java code. So, the Panama
> API faces a risk which was much less real with JNI: having seemingly
> innocent, pure Java code crashing the JVM. All this reasoning is explained,
> in greated details, in JEP 412.
>
>
> The usability issues brought about by this option have been complained
> by other people a long time ago, and I have not seen anyone around
> me who are satisfied with this option. I don't want to repeat all these
> questions here, because I believe you have heard them many times.
> And I think some of these issues  can be alleviated by improving other
> features of the OpenJDK, e.g. adding an alternative to MANIFEST.MF
> for modular programs, allow options such as --add-opens and
> --enable-native-access to be written into it.
>
> I think adding better support for this in manifest is probably a good
> thing to explore, yes. At the same time your premise (many complains, no
> one likes it), seems at fault; the rationale behind guarding some unsafe
> corners of the Panama API behind a flag were discussed, and considered
> better than the alternatives (e.g. at some point we experimented with an
> unsafe module, which users had to enable manually - which was worse, both
> for usability and API discoverability). Of course in a mailing list such as
> this one (but this is true of many internet media), you will be more likely
> to find negative feedback on any given topic than positive feedback - but
> one shouldn't assume too much from that. To be honest, since we moved to
> the new command line option, this issue has not even been brought up again,
> which makes me think that, in reality, most developers understand where the
> option is coming from.
>
>
> Now what I want to emphasize here is that as a more restricted alternative
> to existing features, there is a lot of resistance to migrating to Panama.
> Before restricting JNI, the so-called safety is just a fig leaf,
> it?s just self-deception. This meaningless constraint will not restrict
> the user's behavior at all, but will only hinder the user from choosing
> this road - because there is an unobstructed road nearby.
>
> Again, your argument seems to be "since w/o restricting JNI we can't make
> the platform fully safe, why even try" - but the same argument would apply
> to a lot of other stuff too. We have to start somewhere - note that even if
> JNI would be restricted we'd still have Unsafe around.
> `--enable-native-access` is an attempt to draw a path, where we'd like to
> move the platform in the next N years. Of course I understand that, if you
> pick this particular point in time (e.g. 2021), the picture is not perfect,
> but I think that we have a path to get there. If Panama was just
> unrestricted from the start, it would be much harder to restrict it later
> on (which is why we have to be careful with JNI).
>
>
> I would like to give a proposal here, which I think will minimize the
> obstacles to the promotion of Panama:
>
>   While providing the --enable-native-access option, it also provides
>   a --illegal-native-access=(*silent*|*warn*|*deny*) option.
>
>   At first, the default value is *silent*, and there are no restrictions
> on
>   the use of Panama.
>
>   When you are ready to limit JNI, apply this option to JNI at the same
> time,
>   and adjust the default value to *warn *to warn the use of JNI and
> Panama,
>   and use --enable-native-access to eliminate the warning for a module.
>
>   After several versions, adjust it to *deny *by default to prevent
> unauthorized
>   native operations, and completely remove this option in a later version.
>
> This plan is good on paper, except that if the default is silent for both
> Panama and JNI there is no incentive for people using Panama (which is a
> new API) to get the act together.
>
> Overall, the arguments in this email are a mixture of:
>
> * since JNI is unsafe anyway, what's the point of restricting Panama
> * restricting Panama will hinder adoption in some way
>
> Now, I think both arguments can be turned on their heads; let's not think
> about existing code that wants to migrate from JNI to Panama - let's focus
> on _new_ code instead. If you write bindings for a C library post Java 17,
> it is much more likely that you will find that JEP 412 (+ jextract) gives
> you all you want. Will you be put off by extra command line flags? I don't
> think so - if your application requires native libraries, you will likely
> need flags (e.g. java.library.path) anyway. Will you be put off by the fact
> that JNI doesn't share the same restriction? Well, no - since you opted
> into Panama from the beginning, so JNI is most likely in your rearview
> mirror.
>
> Let's also think of users of the Panama API who couldn't care less about
> native interop (there are some in this mailing list) - e.g. developers who
> only use the foreign API to allocate, access and free memory off heap. Very
> likely, these developer would like to take advantage of the extra
> protection provided by the --enable-native-access flag, to make sure they
> don't accidentally depend on unsafe functionalities they do not require.
>
>
>
> I like the work of Panama very much, but I am very disappointed by
> the current restrictions. For the last time, I want to emphasize that
> restricting Panama alone will only refuse users to use it.
> If you insist on this choice, I will tell you:
>
> Again, "users" is very vague here. There are "users" who have existing
> code bases, who made lots of investments in JNI. I believe for these users
> the decision whether or not to use the new API has to consider a lot more
> factors than just "how many flags will I need with the new API". Then there
> are "users" writing new applications, or frameworks from scratch. These
> users will likely use Panam instead, not because it's newer, or shinier,
> but simply because it reduces the number of pieces they have to maintain
> going forward (e.g. no more JNI intermediate goop). For these users, the
> presence of the new flag is probably not very disruptive - from their
> perspective that's just how things are in Panama.
>
> Thanks for the comments - I think you raise some valid points regarding
> safety and JNI - but I think that ultimately, picking a worse solution just
> because there are other broken areas which won't be fixed immediately is
> not a great decision, and is probably one which will just regret later.
>
> Maurizio
>
>
>   Thank you for your contributions to the Java 8 ecosystem.
>   And I sincerely thank you, because my library users don't have to
>   ask me why they need to upgrade to Java 21.
>
> (This email is written by Google translation. Please forgive me for the
> syntax error)
>
> Maurizio Cimadamore  ?2021?9?20???
> ??6:17???
>
>> Hi,
>> While we do not any plan to require so now, many of the reasons as to
>> why the flag is added for the foreign Panama API hold true for JNI code.
>> As such, It would be not unreasonable, some day, to use the same
>> mechanism to restricted access to both (since, after all, there is no
>> way for the static compiler, or the JVM, to prove that a program using
>> JNI is sound). If we go down this path, it is very likely that it won't
>> be a flag-day, where, say, JDK 30 does not require the flag, but JDK 31
>> does. It is more likely that we will go through a number of intermediate
>> releases where the lack of a flag will result in a runtime warning (not
>> unlike to what has been done with illegal reflective access violation
>> for modules).
>>
>> Maurizio
>>
>>
>> On 19/09/2021 12:11, Glavo wrote:
>> > At present, it seems that JNI will not be restricted. Will the state be
>> > modified in the future?
>>
>

From zjx001202 at gmail.com  Mon Sep 20 17:17:36 2021
From: zjx001202 at gmail.com (Glavo)
Date: Tue, 21 Sep 2021 01:17:36 +0800
Subject: Will we need to use the --enable-native-access option to enable
 JNI in the future?
In-Reply-To: 
References: 
 
 
Message-ID: 

I thought for a long time and summed up the main reasons for
my dissatisfaction: It deprives me of my ability to take responsibility.

First, it should not be confused that there are now three levels of
personnel:

  * Library developer: They develop modules that are dependent on
    other libraries or programs, and may also dependent on other modules.
  * Program developer: They develop programs for execution.
    The program depends on the library and are distributed to users.
  * Users: People who use programs may not understand development.

Now, this restriction makes developers unable to be responsible for
themselves:

First, the library developers cannot be responsible for his own library.
Even if they know exactly what they need and completely encapsulate unsafe
operations inside the module, he still needs to inform its users (program
developer or other library developer)
that it is unsafe.

Second, library developers cannot be responsible for their dependent
libraries.
Even if his own library module has --enable-native-access, and he knows
that all his dependent libraries are safely, he still has to inform all
those
who depend on his library of the library he depends on.

Finally, there is no way for program developers to be directly responsible
for their own programs. If he does not use third-party solutions (such as
bash script),
he must notify the user of all modules requiring native access, even if the
user
does not understand what this means.

The first one may be acceptable, and the third one may be solved by
improving JPMS,
but the second issue is very troublesome. If you think these restrictions
are necessary, I think this needs to be solved. For example, add support
for
declarations such as `require native` in module-info.java, to allow the
--enable-native-access of a module to be passed to the module it depends on.

(I don't know if the content of e-mail after machine translation is
difficult
to understand. If it's really difficult to understand, I will ask my friend
to translate again.)

Glavo  ?2021?9?20??? ??9:07???

> Honestly, as the author of the library, I am extremely disappointed
> with this answer. I will choose to give up my expectation of Panama
> until 2031 (Java 8 and 17 are out of support).
>
> I think that under the current situation, it is extremely stupid to
> restrict Panama by default. Its only significance at present is to
> recommend users to use JNI/JNA/JNR instead of Panama.
>
> At present, --enable-native-access option has nothing to do with
> safety at all: Because of the existence of JNI, a module can do
> anything without it. Since it can't provide any safety guarantee
> at all, and at the same time it brings some additional usability
> issues, it will only limit the promotion of Panama.
>
> The usability issues brought about by this option have been complained
> by other people a long time ago, and I have not seen anyone around
> me who are satisfied with this option. I don't want to repeat all these
> questions here, because I believe you have heard them many times.
> And I think some of these issues  can be alleviated by improving other
> features of the OpenJDK, e.g. adding an alternative to MANIFEST.MF
> for modular programs, allow options such as --add-opens and
> --enable-native-access to be written into it.
>
> Now what I want to emphasize here is that as a more restricted alternative
> to existing features, there is a lot of resistance to migrating to Panama.
> Before restricting JNI, the so-called safety is just a fig leaf,
> it?s just self-deception. This meaningless constraint will not restrict
> the user's behavior at all, but will only hinder the user from choosing
> this road - because there is an unobstructed road nearby.
>
> I would like to give a proposal here, which I think will minimize the
> obstacles to the promotion of Panama:
>
>   While providing the --enable-native-access option, it also provides
>   a --illegal-native-access=(*silent*|*warn*|*deny*) option.
>
>   At first, the default value is *silent*, and there are no restrictions
> on
>   the use of Panama.
>
>   When you are ready to limit JNI, apply this option to JNI at the same
> time,
>   and adjust the default value to *warn *to warn the use of JNI and
> Panama,
>   and use --enable-native-access to eliminate the warning for a module.
>
>   After several versions, adjust it to *deny *by default to prevent
> unauthorized
>   native operations, and completely remove this option in a later version.
>
>
> I like the work of Panama very much, but I am very disappointed by
> the current restrictions. For the last time, I want to emphasize that
> restricting Panama alone will only refuse users to use it.
> If you insist on this choice, I will tell you:
>
>   Thank you for your contributions to the Java 8 ecosystem.
>   And I sincerely thank you, because my library users don't have to
>   ask me why they need to upgrade to Java 21.
>
> (This email is written by Google translation. Please forgive me for the
> syntax error)
>
> Maurizio Cimadamore  ?2021?9?20???
> ??6:17???
>
>> Hi,
>> While we do not any plan to require so now, many of the reasons as to
>> why the flag is added for the foreign Panama API hold true for JNI code.
>> As such, It would be not unreasonable, some day, to use the same
>> mechanism to restricted access to both (since, after all, there is no
>> way for the static compiler, or the JVM, to prove that a program using
>> JNI is sound). If we go down this path, it is very likely that it won't
>> be a flag-day, where, say, JDK 30 does not require the flag, but JDK 31
>> does. It is more likely that we will go through a number of intermediate
>> releases where the lack of a flag will result in a runtime warning (not
>> unlike to what has been done with illegal reflective access violation
>> for modules).
>>
>> Maurizio
>>
>>
>> On 19/09/2021 12:11, Glavo wrote:
>> > At present, it seems that JNI will not be restricted. Will the state be
>> > modified in the future?
>>
>

From maurizio.cimadamore at oracle.com  Mon Sep 20 17:28:28 2021
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 20 Sep 2021 18:28:28 +0100
Subject: Will we need to use the --enable-native-access option to enable
 JNI in the future?
In-Reply-To: 
References: 
 
 
 
 
Message-ID: <18b80809-54b1-1b40-e5f2-a2b1a4e10711@oracle.com>


On 20/09/2021 18:06, Glavo wrote:
> Because my English is very poor, I may not know enough about the
> exact meaning of words. If my words are too offensive, I apologize.
>
>     What I'm more intersted in is - what make you think that adding
>     extra command line flags would be perceived as such a blocker? Do
>     you have examples in mind where this might turn out to be
>     problematic in practice?
>
> I think there are a lot of possible blockers:
>
> ? * Most obviously, we have lost the ability to simply execute with 
> java -m.
> ? ? Now we can only go back to the classpath and describe it in 
> MANIFEST.MF (if supported in the future).
> ? ? If it is not supported, we even lose the ability to double-click 
> to open the jar on windows.
> ? ? We can only consider wrapping the jar with a third-party solution.
I believe that to be the case in most applications requiring native 
libraries? How do you express native library dependency only using -m ?
> ? * Maybe I missed something. I remember there were relevant 
> discussions before,
> ? ? but there still seems to be no way to enable native access for 
> modules at runtime in Java 17.
> ? ? If so, how to enable a module defined at run time using custom 
> ModuleLayer to?use Panama?
> ? ??If not, it will be a devastating blow to any dynamic plugin 
> mechanism, e.g. Minecraft mods.
There is no way now, given the mechanism is in its infancy, no reason it 
couldn't be added in the future, when working with module layers.
> ? *?This assumes that I always know all the modules when I start the 
> program,
> ? ??but this is not necessarily the case.?For example, the most 
> typical is the ServiceLoader.
> ? ??Some components expect to work only by putting them on the module 
> path,
> ? ? such as a implementation of FileSystem or a?ScriptEngine.
See above.
> ? *?Windows cmd limits the maximum length of a single command to 8192.
> ? ? We have some use cases to export a single bat script file that can 
> be started
> ? ? by double clicking for novice users. We are often close to this 
> boundary, and continuing
> ? ? to increase the length of the command line will exacerbate this 
> problem.
This is true of any new command line flag, picking on this specific one 
for that limit seems a bit harsh.
> ? * and more...
>
>     Saying that, since JNI is unsafe and enabled-by-default, then
>     Panama should just follow suit, seems like an ill-conceived
>     argument. Because something else is not great (for historical
>     reasons - modules weren't there when JNI was born), doesn't, in my
>     opinion, justify making everything else bad too, just because of
>     that precedent.
>
> In fact, I am not entirely opposed to restricting native access.
> However, the premise is that this option, like its name, really needs
> to enable native access.?However, at present, even without it,
> it does not mean that the module cannot to native access.
> This naming is extremely misleading. It can't bring real security to 
> users.
>
>     Note also that, in JNI, most of the unsafety comes from within JNI
>     C glue code (e.g. the so called JNI functions). This glue code is
>     no longer there in Panama - since it can be simply expressed as
>     Java code. So, the Panama API faces a risk which was much less
>     real with JNI: having seemingly innocent, pure Java code crashing
>     the JVM. All this reasoning is explained, in greated details, in
>     JEP 412.
>
>
> I understand this, which is the only reason I can partially agree.
> If it just block me at compile time, need me to explicitly enable it
> with annotations or compiler parameters, and I'd like to see that.
> But why do my end users need to confirm my choice?
> Does TA need to be clearly aware that my library, as a third-party 
> library,
> is using java code instead of native code to implement binding?
I think that, if your library is implemented using native code, who uses 
your library has to have a shot at deciding whether that's ok or not 
(given the safety issues that can arise). Of course, as already 
discussed, the provided safety guarantees can't be absolute, because of 
JNI and Unsafe, but hopefully we'll get there.
>
>
> ?I won't talk about how realistic it is for JNI to migrate to Panama.
> How to define the _new_??Do you think this is the era of Java 17?
> No, this is the era?of Java 8, 11 and 17.?Before 2031, in these nine 
> years,
> there is no reason to support Java 8, but only reason to give up.
> In these nine years, any blocker will have a significant impact on
> the promotion of an alternative without introducing new capabilities.
By new I mean new. Developers that are ok having dependencies on the 
latest version. I don't see how the fact that there are multiple LTS out 
there affects the way in which the --enable-native-access option will be 
perceived, frankly.
>
>     Let's also think of users of the Panama API who couldn't care less
>     about native interop (there are some in this mailing list) - e.g.
>     developers who only use the foreign API to allocate, access and
>     free memory off heap. Very likely, these developer would like to
>     take advantage of the extra protection provided by the
>     --enable-native-access flag, to make sure they don't accidentally
>     depend on unsafe functionalities they do not require.
>
>
> ?The same as above, why can't you restrict it at compile time and put 
> it at run time?
>
The same as above - because if it's compile-time then it becomes a 
choice of the developer of the library, and the application packager, 
which assembles many libraries, doesn't have a say of which can and 
cannot access native features of the Java platform.

Honestly, calling any of the issues above "blockers" seems harsh - some 
of these can be figured out (such as having a story for granting native 
access to modules in dynamic layers), others such as command line limit, 
surely cannot be put down on Panama alone.

The only remark which is worth pointing out is your general feeling that 
enabling native access is a compile-time only business; of course we 
thought about this at the very beginning when we started thinking about 
enabling native access explicitly, but we found this solution not 
satisfactory; it would be the equivalent of enforcing module boundaries 
only at compile-time - because then, if the library developer has opted 
to break some boundaries, why should that decision be forced on 3rd 
parties? But module boundaries are enforced _both_ at compile time _and_ 
at run time. So, in my view, while at some point we might have a static 
story too (e.g. javac might start barking about native access, and a 
flag will be added there too to match the runtime flag), having some 
sort of runtime flag is an integral part of the safety feature we're 
after here.

Maurizio



From maurizio.cimadamore at oracle.com  Mon Sep 20 17:39:51 2021
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 20 Sep 2021 18:39:51 +0100
Subject: Will we need to use the --enable-native-access option to enable
 JNI in the future?
In-Reply-To: 
References: 
 
 
 
Message-ID: 


On 20/09/2021 18:17, Glavo wrote:
> I thought for a long time and summed up the main reasons for
> my dissatisfaction: It deprives me of my ability to take responsibility.
I think this is getting closer to it (as noted in the response I've just 
sent)
>
> First, it should not be confused that there are now three levels of
> personnel:
>
> ? * Library developer: They develop modules that are dependent on
> ? ? other libraries or programs, and may also dependent on other modules.
I believe this is where the friction is
> ? * Program developer: They develop programs for execution.
> ? ? The program depends on the library and are distributed to users.
The friction here is just imagined. When you package up an application 
(e.g. think of an IDE) you know what your dependencies are - and which 
command line options to pass. Doing this using e.g. `jpackage` is trivial.
> ? * Users: People who use programs may not understand development.
This category is ill specified. Who is an user? An user is either 
(recursively) a library developer (as library A can depend on library 
B). In such case a library doesn't have to concern about giving 
permissions. A user can also be a program developer, e.g. a program 
using library A - in which case the user needs to decide whether to 
grant A access or not.
> Now, this restriction makes developers unable to be responsible for 
> themselves:
No, this restriction makes _library developers_ unable to *cheat* on 
program developers. If a program developer grants native access to only 
3 modules, and another one pops up and starts using native access out of 
nowhere, it is a legitimate question, from the perspective of that 
program developer, as to whether that other module has been updated in a 
way that is consistent with the program/application. Maybe this will 
result in an extra command line option - or maybe this will result in 
the extra dependency being eliminated. It is ultimately a choice up to 
the application developer.
>
> First, the library developers cannot be responsible for his own library.
> Even if they know exactly what they need and completely encapsulate 
> unsafe
> operations inside the module, he still needs to inform its users 
> (program developer or other library developer)
> that it is unsafe.

>
> Second, library developers cannot be responsible for their dependent 
> libraries.
> Even if his own library module has --enable-native-access, and he knows
> that all his dependent libraries are safely, he still has to inform 
> all those
> who depend on his library of the library he depends on.
> Finally, there is no way for program developers to be directly 
> responsible
> for their own programs. If he does not use third-party solutions (such 
> as bash script),
> he must notify the user of all modules requiring native access, even 
> if the user
> does not understand what this means.

Isn't this the case even for a library that wants to use functionalities 
that are closed off by the module system? (e.g. access to JDK internals)

Note that I'm not entirely oblivious to the problem that we might need, 
at some point, a better way to "reify" native dependencies between 
modules. E.g. say that module A is a native module, and uses native 
modules B and C. This would open up ability to grant access only to A, 
which will then be propagated to B and C, so you would be back in a 
world where users are shielded from the internals of your module.

These things are in the range of things we'd like to explore at some 
point, which might (or might not!) relieve some of the (real of 
perceived) friction.

>
> The first one may be acceptable, and the third one may be solved by 
> improving JPMS,
> but the second issue is very troublesome. If you think these restrictions
> are necessary, I think this needs to be solved. For example, add 
> support for
> declarations such as `require native` in module-info.java, to allow the
> --enable-native-access of a module to be passed to the module it 
> depends on.

Yes, see above.

Cheers
Maurizio

>
> (I don't know if the content of e-mail after machine translation is 
> difficult
> to understand. If it's really difficult to understand, I will ask my 
> friend to translate again.)

It's readable enough - don't worry :-)

>
> Glavo > 
> ?2021?9?20??? ??9:07???
>
>     Honestly, as the author of the library, I am extremely disappointed
>     with this answer. I will choose to give up my expectation of Panama
>     until 2031 (Java 8 and 17 are out of support).
>
>     I think that under the current situation, it is extremely stupid to
>     restrict Panama by default. Its only significance at present is to
>     recommend users to use JNI/JNA/JNR instead of Panama.
>
>     At present, --enable-native-access option has nothing to do with
>     safety at all: Because of the existence of JNI, a module can do
>     anything without it. Since it can't provide any safety guarantee
>     at all, and at the same time it brings some additional usability
>     issues, it will only limit the promotion of Panama.
>
>     The usability issues brought about by this option have been
>     complained
>     by other people a long time ago, and I have not seen anyone around
>     me who are satisfied with this option. I don't want to repeat all
>     these
>     questions here, because I believe you have heard them many times.
>     And I think some of these issues? can be alleviated by improving
>     other
>     features of the OpenJDK, e.g. adding an alternative to MANIFEST.MF
>     for modular programs, allow options such as --add-opens and
>     --enable-native-access to be written into it.
>
>     Now what I want to emphasize here is that as a more restricted
>     alternative
>     to existing features, there is a lot of resistance to migrating to
>     Panama.
>     Before restricting JNI, the so-called safety is just a fig leaf,
>     it?s just self-deception. This meaningless constraint will not
>     restrict
>     the user's behavior at all, but will only hinder the user from
>     choosing
>     this road - because there is an unobstructed road nearby.
>
>     I would like to give a proposal here, which I think will minimize the
>     obstacles to the promotion of Panama:
>
>     ? While providing the --enable-native-access option, it also provides
>     ? a --illegal-native-access=(*silent*|*warn*|*deny*) option.
>
>     ? At first, the default value is *silent*, and there are no
>     restrictions on
>     ? the use of Panama.
>
>     ? When you are ready to limit JNI, apply this option to JNI at the
>     same time,
>     ? and adjust the default value to *warn *to warn the use of JNI
>     and Panama,
>     ? and use --enable-native-access to eliminate the warning for a
>     module.
>
>     ? After several versions, adjust it to *deny *by default to
>     prevent unauthorized
>     ? native operations, and completely remove this option in a later
>     version.
>
>
>     I like the work of Panama very much, but I am very disappointed by
>     the current restrictions. For the last time, I want to emphasize that
>     restricting Panama alone will only refuse users to use it.
>     If you insist on this choice, I will tell you:
>
>     ? Thank you for your contributions to the Java 8 ecosystem.
>     ? And I sincerely thank you, because my library users don't have to
>     ? ask me why they need to upgrade to Java 21.
>     (This email is written by Google translation. Please forgive me
>     for the syntax error)
>
>     Maurizio Cimadamore      > ?2021?9?20???
>     ??6:17???
>
>         Hi,
>         While we do not any plan to require so now, many of the
>         reasons as to
>         why the flag is added for the foreign Panama API hold true for
>         JNI code.
>         As such, It would be not unreasonable, some day, to use the same
>         mechanism to restricted access to both (since, after all,
>         there is no
>         way for the static compiler, or the JVM, to prove that a
>         program using
>         JNI is sound). If we go down this path, it is very likely that
>         it won't
>         be a flag-day, where, say, JDK 30 does not require the flag,
>         but JDK 31
>         does. It is more likely that we will go through a number of
>         intermediate
>         releases where the lack of a flag will result in a runtime
>         warning (not
>         unlike to what has been done with illegal reflective access
>         violation
>         for modules).
>
>         Maurizio
>
>
>         On 19/09/2021 12:11, Glavo wrote:
>         > At present, it seems that JNI will not be restricted. Will
>         the state be
>         > modified in the future?
>

From jbhateja at openjdk.java.net  Mon Sep 20 19:28:40 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Mon, 20 Sep 2021 19:28:40 GMT
Subject: [vectorIntrinsics+mask] RFR: 8273949: Intrinsic creation for
 VectorMask.toLong operation. [v3]
In-Reply-To: 
References: 
Message-ID: <6BV8s5FyH0GDcaUreJfsaFuGcvcZZmcFSZ1-HujLgIo=.e981bc14-143e-4c2b-9dd0-a7cfb941d6f5@github.com>

> Summary of changes:
> - Intrinsification of VectorMask.toLong() API.
> - Supports inline expansion for both AVX512 and non-AVX512 targets.
> - Used toLong() API to optimize existing Java API implementation of VectorMask.laneIsSet() operation.
> 
> Following performance number are generated using JMH benchmark modification included with the patch.
> 
> System:  Intel(R) Xeon(R) Platinum 8280 CPU @ 2.70GHz (Cascade Lake Server 28C 2S)
> 
> Benchmark | VECSIZE | Baseline Score (ops/ms) | With Opt (ops/ms) | Gain Ratio
> -- | -- | -- | -- | --
> MaskQueryOperationsBenchmark.testToLongByte | 128 | 90451.424 | 346941.379 | 3.835665196
> MaskQueryOperationsBenchmark.testToLongByte | 256 | 63127.764 | 338331.425 | 5.359471072
> MaskQueryOperationsBenchmark.testToLongByte | 512 | 40543.264 | 313836.333 | 7.740776199
> MaskQueryOperationsBenchmark.testToLongLong | 128 | 171989.714 | 152872.758 | 0.88884826
> MaskQueryOperationsBenchmark.testToLongLong | 256 | 164702.273 | 324794.578 | 1.972010295
> MaskQueryOperationsBenchmark.testToLongLong | 512 | 122667.916 | 318060.096 | 2.59285481
> MaskQueryOperationsBenchmark.testToLongShort | 128 | 122656.408 | 346691.082 | 2.826522378
> MaskQueryOperationsBenchmark.testToLongShort | 256 | 96838.555 | 360909.28 | 3.726917239
> MaskQueryOperationsBenchmark.testToLongShort | 512 | 63119.009 | 313075.159 | 4.960077225
> MaskQueryOperationsBenchmark.testToLonglong | 128 | 180855.623 | 324620.433 | 1.794914792
> MaskQueryOperationsBenchmark.testToLonglong | 256 | 122705.631 | 324315.916 | 2.643040204
> MaskQueryOperationsBenchmark.testToLonglong | 512 | 90396.687 | 324318.095 | 3.58772103

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  8273949: Review comments resolution.

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

Changes:
  - all: https://git.openjdk.java.net/panama-vector/pull/126/files
  - new: https://git.openjdk.java.net/panama-vector/pull/126/files/f7e689ef..6b38d057

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

  Stats: 7 lines in 2 files changed: 2 ins; 1 del; 4 mod
  Patch: https://git.openjdk.java.net/panama-vector/pull/126.diff
  Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/126/head:pull/126

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

From jbhateja at openjdk.java.net  Mon Sep 20 19:28:41 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Mon, 20 Sep 2021 19:28:41 GMT
Subject: [vectorIntrinsics+mask] RFR: 8273949: Intrinsic creation for
 VectorMask.toLong operation. [v2]
In-Reply-To: 
References: 
 <815z4CBsNPaXEFc_Lpktm41QxtMNWBZA-lf_F6mP75A=.ba97a5ec-b359-4eda-8b54-7d40c52a390f@github.com>
 
Message-ID: 

On Mon, 20 Sep 2021 15:41:04 GMT, Paul Sandoz  wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8273949: Review comments resolution
>
> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractMask.java line 68:
> 
>> 66:         if (i < 0 || i >= length()) {
>> 67:             throw new IllegalArgumentException("Index " + i + " must be zero or positive, and less than " + length());
>> 68:         }
> 
> Apologies i should have previously said use `Objects.checkIndex(i, length())`. In fact lets call `length` once:
> 
>     int length = length();
>     Objects.checkIndex(i, length);
>     if (length <= Long.SIZE) {
>     ...
> 
> 
> Separately i wonder if the second bounds check should be `if i <= Long.SIZE`, since the first bounds check should dominate in many cases?
> 
> (I know there are other areas where we should `Objects.checkIndex` e.g. `*MaxVector.lane/withLane` but we can fix those later.)

With length <= Long.SIZE there is a better possibility of optimizing out else part and thus only fast path gets generated. length is final static values and hence in most of the cases due to in-lining this constant may get propagated.

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

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

From psandoz at openjdk.java.net  Mon Sep 20 19:37:57 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Mon, 20 Sep 2021 19:37:57 GMT
Subject: [vectorIntrinsics+mask] RFR: 8273949: Intrinsic creation for
 VectorMask.toLong operation. [v3]
In-Reply-To: <6BV8s5FyH0GDcaUreJfsaFuGcvcZZmcFSZ1-HujLgIo=.e981bc14-143e-4c2b-9dd0-a7cfb941d6f5@github.com>
References: 
 <6BV8s5FyH0GDcaUreJfsaFuGcvcZZmcFSZ1-HujLgIo=.e981bc14-143e-4c2b-9dd0-a7cfb941d6f5@github.com>
Message-ID: 

On Mon, 20 Sep 2021 19:28:40 GMT, Jatin Bhateja  wrote:

>> Summary of changes:
>> - Intrinsification of VectorMask.toLong() API.
>> - Supports inline expansion for both AVX512 and non-AVX512 targets.
>> - Used toLong() API to optimize existing Java API implementation of VectorMask.laneIsSet() operation.
>> 
>> Following performance number are generated using JMH benchmark modification included with the patch.
>> 
>> System:  Intel(R) Xeon(R) Platinum 8280 CPU @ 2.70GHz (Cascade Lake Server 28C 2S)
>> 
>> Benchmark | VECSIZE | Baseline Score (ops/ms) | With Opt (ops/ms) | Gain Ratio
>> -- | -- | -- | -- | --
>> MaskQueryOperationsBenchmark.testToLongByte | 128 | 90451.424 | 346941.379 | 3.835665196
>> MaskQueryOperationsBenchmark.testToLongByte | 256 | 63127.764 | 338331.425 | 5.359471072
>> MaskQueryOperationsBenchmark.testToLongByte | 512 | 40543.264 | 313836.333 | 7.740776199
>> MaskQueryOperationsBenchmark.testToLongLong | 128 | 171989.714 | 152872.758 | 0.88884826
>> MaskQueryOperationsBenchmark.testToLongLong | 256 | 164702.273 | 324794.578 | 1.972010295
>> MaskQueryOperationsBenchmark.testToLongLong | 512 | 122667.916 | 318060.096 | 2.59285481
>> MaskQueryOperationsBenchmark.testToLongShort | 128 | 122656.408 | 346691.082 | 2.826522378
>> MaskQueryOperationsBenchmark.testToLongShort | 256 | 96838.555 | 360909.28 | 3.726917239
>> MaskQueryOperationsBenchmark.testToLongShort | 512 | 63119.009 | 313075.159 | 4.960077225
>> MaskQueryOperationsBenchmark.testToLonglong | 128 | 180855.623 | 324620.433 | 1.794914792
>> MaskQueryOperationsBenchmark.testToLonglong | 256 | 122705.631 | 324315.916 | 2.643040204
>> MaskQueryOperationsBenchmark.testToLonglong | 512 | 90396.687 | 324318.095 | 3.58772103
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8273949: Review comments resolution.

Java changes are good.

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

Marked as reviewed by psandoz (Committer).

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

From zjx001202 at gmail.com  Tue Sep 21 02:51:37 2021
From: zjx001202 at gmail.com (Glavo)
Date: Tue, 21 Sep 2021 10:51:37 +0800
Subject: Will we need to use the --enable-native-access option to enable
 JNI in the future?
In-Reply-To: <18b80809-54b1-1b40-e5f2-a2b1a4e10711@oracle.com>
References: 
 
 
 
 
 <18b80809-54b1-1b40-e5f2-a2b1a4e10711@oracle.com>
Message-ID: 

Thank you for your patience and tolerance.


> How do you express native library dependency only using -m ?
>

Just like the most common usage now: The dynamic library is put
into jar as a resource, which is extracted and loaded by the program
at run time. Frankly, I'm very surprised by your question, because most
third-party native libraries are doing this at present. I don't understand
why you wonder about it.

This is true of any new command line flag, picking on this specific one for
> that limit seems a bit harsh.
>

Yes, so I am dissatisfied with any command line parameters that
force me to use. I think in addition to the necessary module path
and module name, other necessary options at runtime require
careful consideration.

I guess Panama is an attempt to use a modular system for security
management. But the current state is that he has not entered the
module system well. But the current state is that he has not entered
the module system well. It seems that he has been forcibly mixed
with the module system. I can't tell users in a modular way that my
module needs native access. At the same time, users cannot grant
native access to other modules in a modular manner. It's like if you
can't declare opens and exports to in module-info.java, but can only
add runtime options.

Think over JPMS, in my opinion, the purpose of the --add-opens
command line options is to make this feature more difficult to use
and force users to use modular means to solve it. Unfortunately,
Panama does not have a modular solution,

I think that, if your library is implemented using native code, who uses
> your library has to have a shot at deciding whether that's ok or not (given
> the safety issues that can arise). Of course, as already discussed, the
> provided safety guarantees can't be absolute, because of JNI and Unsafe,
> but hopefully we'll get there.
>

No, this restriction makes _library developers_ unable to *cheat* on
> program developers. If a program developer grants native access to only 3
> modules, and another one pops up and starts using native access out of
> nowhere, it is a legitimate question, from the perspective of that program
> developer, as to whether that other module has been updated in a way that
> is consistent with the program/application. Maybe this will result in an
> extra command line option - or maybe this will result in the extra
> dependency being eliminated. It is ultimately a choice up to the
> application developer.
>
> I think you are always using the so-called safety of castles in the air
to escape from real problems, and use workaround to escape design
issues.

At least for now, --enable-native-access brings only greater
safety risks. I don't put important things in a room that needs to go in
and out of a big hole, but you put another security door in this room,
this creates an unrealistic sense of security, like this:

No, this restriction makes _library developers_ unable to *cheat* on
> program developers. If a program developer grants native access to only 3
> modules, and another one pops up and starts using native access out of
> nowhere, it is a legitimate question, from the perspective of that program
> developer, as to whether that other module has been updated in a way that
> is consistent with the program/application. Maybe this will result in an
> extra command line option - or maybe this will result in the extra
> dependency being eliminated. It is ultimately a choice up to the
> application developer.\


You and this option are cheating us. It has made guarantees beyond
its ability. No one trusts in anything unsafe, but it try to bring a false
sense of safety with fraud. Static warnings at compile time are enough
to make library developers aware of what they are doing, and for the
users of the library, it only provides a fraudulent guarantee, which
makes the users have the illusion that they can only have native access
if they are allowed, which is the source of danger.

If there is a big hole in the wall until the wall is repaired, I will tell
the
user to take the key out. But I won't lock the door, so as to alert users
to the hidden insecurity behind it.

It may be useful to allow users to use this security mechanism, but it
should not provide false protection by default until it has the ability to
guarantee.

By new I mean new. Developers that are ok having dependencies on the latest
> version. I don't see how the fact that there are multiple LTS out there
> affects the way in which the --enable-native-access option will be
> perceived, frankly.
>

 I have some programs that use Java 8. They need to use JNI to call
a few system APIs.

In my original plan, I would convert it into a multi-release jar.
On the Java platform available to Panama, I will use Panama to call
the system API. This will allow me to adapt to more platforms (e.g.
mips64el).
Panama's restrictions made me abandon this scheme. Because
I can't execute it on any version of Java platform with a unified command.

It is possible to use different loading schemes on different versions of
Java platforms through multi-release jar or different modules, which
may be a good migration scheme. In this way, users can enjoy the
progress brought by Panama as long as they upgrade to Java 21
without modifying anything. Additional restrictions can hinder this
migration. Note: JNI may not be used originally, but JNA/JNR may be
used. Panama has a significant performance advantage over them,
while being able to reduce dependence.

I don't understand why you value new code and despise the migration
of old code. Before 2031, or conservatively, for at least five years,
programs that can only work on the new version of Java will not be the
mainstream, ensuring that there is less difference between new and
old schemes is conducive to migration.

Thank you again for your patience.

Maurizio Cimadamore  ?2021?9?21??? ??1:28???

>
> On 20/09/2021 18:06, Glavo wrote:
>
> Because my English is very poor, I may not know enough about the
> exact meaning of words. If my words are too offensive, I apologize.
>
> What I'm more intersted in is - what make you think that adding extra
>> command line flags would be perceived as such a blocker? Do you have
>> examples in mind where this might turn out to be problematic in practice?
>
>
> I think there are a lot of possible blockers:
>
>   * Most obviously, we have lost the ability to simply execute with java
> -m.
>     Now we can only go back to the classpath and describe it in
> MANIFEST.MF (if supported in the future).
>     If it is not supported, we even lose the ability to double-click to
> open the jar on windows.
>     We can only consider wrapping the jar with a third-party solution.
>
> I believe that to be the case in most applications requiring native
> libraries? How do you express native library dependency only using -m ?
>
>   * Maybe I missed something. I remember there were relevant discussions
> before,
>     but there still seems to be no way to enable native access for modules
> at runtime in Java 17.
>     If so, how to enable a module defined at run time using custom
> ModuleLayer to use Panama?
>     If not, it will be a devastating blow to any dynamic plugin mechanism,
> e.g. Minecraft mods.
>
> There is no way now, given the mechanism is in its infancy, no reason it
> couldn't be added in the future, when working with module layers.
>
>   * This assumes that I always know all the modules when I start the
> program,
>     but this is not necessarily the case. For example, the most typical is
> the ServiceLoader.
>     Some components expect to work only by putting them on the module
> path,
>     such as a implementation of FileSystem or a ScriptEngine.
>
> See above.
>
>   * Windows cmd limits the maximum length of a single command to 8192.
>     We have some use cases to export a single bat script file that can be
> started
>     by double clicking for novice users. We are often close to this
> boundary, and continuing
>     to increase the length of the command line will exacerbate this
> problem.
>
> This is true of any new command line flag, picking on this specific one
> for that limit seems a bit harsh.
>
>   * and more...
>
> Saying that, since JNI is unsafe and enabled-by-default, then Panama
>> should just follow suit, seems like an ill-conceived argument. Because
>> something else is not great (for historical reasons - modules weren't there
>> when JNI was born), doesn't, in my opinion, justify making everything else
>> bad too, just because of that precedent.
>>
>
> In fact, I am not entirely opposed to restricting native access.
> However, the premise is that this option, like its name, really needs
> to enable native access. However, at present, even without it,
> it does not mean that the module cannot to native access.
> This naming is extremely misleading. It can't bring real security to users.
>
> Note also that, in JNI, most of the unsafety comes from within JNI C glue
>> code (e.g. the so called JNI functions). This glue code is no longer there
>> in Panama - since it can be simply expressed as Java code. So, the Panama
>> API faces a risk which was much less real with JNI: having seemingly
>> innocent, pure Java code crashing the JVM. All this reasoning is explained,
>> in greated details, in JEP 412.
>>
>
> I understand this, which is the only reason I can partially agree.
> If it just block me at compile time, need me to explicitly enable it
> with annotations or compiler parameters, and I'd like to see that.
> But why do my end users need to confirm my choice?
> Does TA need to be clearly aware that my library, as a third-party library,
> is using java code instead of native code to implement binding?
>
> I think that, if your library is implemented using native code, who uses
> your library has to have a shot at deciding whether that's ok or not (given
> the safety issues that can arise). Of course, as already discussed, the
> provided safety guarantees can't be absolute, because of JNI and Unsafe,
> but hopefully we'll get there.
>
>
>
>  I won't talk about how realistic it is for JNI to migrate to Panama.
> How to define the _new_? Do you think this is the era of Java 17?
> No, this is the era of Java 8, 11 and 17. Before 2031, in these nine
> years,
> there is no reason to support Java 8, but only reason to give up.
> In these nine years, any blocker will have a significant impact on
> the promotion of an alternative without introducing new capabilities.
>
> By new I mean new. Developers that are ok having dependencies on the
> latest version. I don't see how the fact that there are multiple LTS out
> there affects the way in which the --enable-native-access option will be
> perceived, frankly.
>
>
> Let's also think of users of the Panama API who couldn't care less about
>> native interop (there are some in this mailing list) - e.g. developers who
>> only use the foreign API to allocate, access and free memory off heap. Very
>> likely, these developer would like to take advantage of the extra
>> protection provided by the --enable-native-access flag, to make sure they
>> don't accidentally depend on unsafe functionalities they do not require.
>>
>
>  The same as above, why can't you restrict it at compile time and put it
> at run time?
>
> The same as above - because if it's compile-time then it becomes a choice
> of the developer of the library, and the application packager, which
> assembles many libraries, doesn't have a say of which can and cannot access
> native features of the Java platform.
>
> Honestly, calling any of the issues above "blockers" seems harsh - some of
> these can be figured out (such as having a story for granting native access
> to modules in dynamic layers), others such as command line limit, surely
> cannot be put down on Panama alone.
>
> The only remark which is worth pointing out is your general feeling that
> enabling native access is a compile-time only business; of course we
> thought about this at the very beginning when we started thinking about
> enabling native access explicitly, but we found this solution not
> satisfactory; it would be the equivalent of enforcing module boundaries
> only at compile-time - because then, if the library developer has opted to
> break some boundaries, why should that decision be forced on 3rd parties?
> But module boundaries are enforced _both_ at compile time _and_ at run
> time. So, in my view, while at some point we might have a static story too
> (e.g. javac might start barking about native access, and a flag will be
> added there too to match the runtime flag), having some sort of runtime
> flag is an integral part of the safety feature we're after here.
>
> Maurizio
>
>
>

From maurizio.cimadamore at oracle.com  Tue Sep 21 10:20:10 2021
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 21 Sep 2021 11:20:10 +0100
Subject: Will we need to use the --enable-native-access option to enable
 JNI in the future?
In-Reply-To: 
References: 
 
 
 
 
 <18b80809-54b1-1b40-e5f2-a2b1a4e10711@oracle.com>
 
Message-ID: <2eb43d4c-6eee-39f7-877b-d98681773520@oracle.com>

I'll zoom in on this issue, because I think it's the one we need to 
understand the most. For the record, I don't despise all code at all - 
but I also think that the position of "must be run with a clean `java 
-jar`, no extra arguments" is (while a good goal) a bit unrealistic. 
Most of the real world Java application I've seen all need to drop in 
some extra command line option (e.g. -Xmx), but I think your problem 
here is more specific than "just add a command line option" - the 
problem is adding an option that is only supported on _some_ JDKs (see 
below).

On 21/09/2021 03:51, Glavo wrote:
> In my original plan, I would convert it into a multi-release jar.
> On the Java platform available to Panama, I will use Panama to call
> the system API.?This will allow me to adapt to more platforms (e.g. 
> mips64el).
> Panama's restrictions made me abandon this scheme.?Because
> I can't execute it on any version of Java platform with a unified?command.

I think this is the real important point here. I'd like to understand 
more about this use case. Do you have an executable AND multi-release 
JAR? Is it an application that you are developing? Do you want that 
application to be just executed using `java -jar foo.jar`? Does your 
application have a launcher to trigger the `java -jar` command?

Please walk me through your use case a bit, and please let's keep the 
conversation focussed - arguing over general safety principles is not 
very helpful, when the real problem is, I suspect, driven by something 
much more concrete.

Thanks
Maurizio



From uschindler at openjdk.java.net  Tue Sep 21 11:02:15 2021
From: uschindler at openjdk.java.net (Uwe Schindler)
Date: Tue, 21 Sep 2021 11:02:15 GMT
Subject: [foreign-memaccess+abi] RFR: 8273905: Foreign API refresh [v10]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 20 Sep 2021 13:16:07 GMT, Maurizio Cimadamore  wrote:

>> As outlined in [1], there are areas of the foreign API we'd like to improve upon, such as:
>> 
>> * dereference: there is a mismatch between API points which create segments (which take a layout) and dereference API points, which do not take layouts
>> 
>> * role of `MemoryAddress`: in Java 17, `MemoryAddress` has become a stateful carrier, which is attached to a scope. This is inconvenient, as in most cases, a memory address is just a raw pointer that arises when interacting with native code.
>> 
>> * resource scopes: the API for scopes has too many flavors to pick from, many of which overlap. The fact that scopes and segment allocators are unrelated forces clients to introduce ad hoc conversions from scopes to allocators, and library developers to add overloads. Finally, the API for acquiring scopes doesn't work well with try-with-resources, and could also be simplified. 
>> 
>> I will add separate comments to explain how the API has changed to resolve the above issues.
>> 
>> [1] - https://mail.openjdk.java.net/pipermail/panama-dev/2021-September/014946.html
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   * Add implNote on `ResourceScope#keepAlive` documenting the maximum number of keep alive requests
>   * Make sure that the keep alive limit is also enforced in confined scope implementations

Marked as reviewed by uschindler (no project role).

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

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

From samuel.audet at gmail.com  Tue Sep 21 11:59:17 2021
From: samuel.audet at gmail.com (Samuel Audet)
Date: Tue, 21 Sep 2021 20:59:17 +0900
Subject: Will we need to use the --enable-native-access option to enable
 JNI in the future?
In-Reply-To: <2eb43d4c-6eee-39f7-877b-d98681773520@oracle.com>
References: 
 
 
 
 
 <18b80809-54b1-1b40-e5f2-a2b1a4e10711@oracle.com>
 
 <2eb43d4c-6eee-39f7-877b-d98681773520@oracle.com>
Message-ID: 

FWIW, I think the core issue comes from the fact that the Java platform is
unable to take responsibility for any of the native code, so what about a
way to define some sort of "environment", for the lack of a better word.
For example, when the code gets loaded on Android, iOS, or WebAssembly, we
already know that the native code is going to run in a sandbox, so we
shouldn't have to specify any flags because executing any native code is
already considered as "safe" by the native platform. Maybe not as "safe" as
Java code, but that's not the point, the point is that maybe the decision
should be deferred to the underlying platform? Thoughts?

Samuel

On Tue, Sep 21, 2021, 19:20 Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> I'll zoom in on this issue, because I think it's the one we need to
> understand the most. For the record, I don't despise all code at all -
> but I also think that the position of "must be run with a clean `java
> -jar`, no extra arguments" is (while a good goal) a bit unrealistic.
> Most of the real world Java application I've seen all need to drop in
> some extra command line option (e.g. -Xmx), but I think your problem
> here is more specific than "just add a command line option" - the
> problem is adding an option that is only supported on _some_ JDKs (see
> below).
>
> On 21/09/2021 03:51, Glavo wrote:
> > In my original plan, I would convert it into a multi-release jar.
> > On the Java platform available to Panama, I will use Panama to call
> > the system API. This will allow me to adapt to more platforms (e.g.
> > mips64el).
> > Panama's restrictions made me abandon this scheme. Because
> > I can't execute it on any version of Java platform with a
> unified command.
>
> I think this is the real important point here. I'd like to understand
> more about this use case. Do you have an executable AND multi-release
> JAR? Is it an application that you are developing? Do you want that
> application to be just executed using `java -jar foo.jar`? Does your
> application have a launcher to trigger the `java -jar` command?
>
> Please walk me through your use case a bit, and please let's keep the
> conversation focussed - arguing over general safety principles is not
> very helpful, when the real problem is, I suspect, driven by something
> much more concrete.
>
> Thanks
> Maurizio
>
>
>

From maurizio.cimadamore at oracle.com  Tue Sep 21 12:41:26 2021
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 21 Sep 2021 13:41:26 +0100
Subject: JEP-412 & OpenGL
In-Reply-To: 
References: 
 <44916ce4-1174-28d0-6cff-28ee6ac7b487@oracle.com>
 <91EE3A16-B5E3-4DAA-A299-6B332178B5A0@oracle.com>
 <20IAXMh_D5CwrlzRuub4xeEQVgsdy_SG-PGZ_mFzrEPcaCOUWu2_6lwXTxR10bHTJmUQW8Xaq0xnen8Fmp65kBkg3Nikf1y-h2zDL-80-lI=@protonmail.com>
 
Message-ID: 

Hi Martin,
I think the compilation setup looks correct. The question is how do you 
run the application? The --add-modules option has to be added both at 
compile-time (which you are doing) *and* at run-time.

Maurizio

On 21/09/2021 13:15, Martin Pernollet wrote:
> Hi everyone,
>
> I followed the steps of the OpenGL tutorial and mentioned them here [1]. I got stuck with the below error when running the JAR - which I create with Maven + Shade plugin to later use Jzy3D and Panama together.
>
> Error: Unable to initialize main class Teapot
> Caused by: java.lang.NoClassDefFoundError: jdk/incubator/foreign/Addressable
>
> Do you have a suggestion for this? I already tried building by passing the --add-modules in three different ways :
>
> (1) mvn install -D--add-modules=jdk.incubator.foreign
> (2) mvn install --add-modules jdk.incubator.foreign
> (3) mvn install without arguments by relying on maven compiler plugin setup as follow
>
> 
> 	maven-compiler-plugin
> 	2.3.2
> 	
> 		17
> 		17
> 		UTF-8
> 		
> 			--add-modules
> 			jdk.incubator.foreign
> 			--add-exports
> 			jdk.incubator.foreign
> 		
> 	
> 
>
>
> I'll gladly bundled the Q&A in the above readme for other developers.
>
> Thanks in advance,
>
> Martin
>
> [1] https://urldefense.com/v3/__https://github.com/jzy3d/panama-gl__;!!ACWV5N9M2RV99hQ!bD8kYg-yxOkAx3K51U-h3dQqyLInU20XCvH8O8KiyWJ-qrZS3rxRah14L9c_Rhlt8SNQYGs$
> [2] https://urldefense.com/v3/__https://github.com/sundararajana/panama-jextract-samples/issues__;!!ACWV5N9M2RV99hQ!bD8kYg-yxOkAx3K51U-h3dQqyLInU20XCvH8O8KiyWJ-qrZS3rxRah14L9c_Rhlt2ft10UE$
>
> Sent with ProtonMail Secure Email.
>
> ??????? Original Message ???????
>
> Le lundi 20 septembre 2021 ? 14:24, Martin Pernollet  a ?crit :
>
>> Thank you all for your answers.
>>
>> I'll give a try in the coming weeks and will tell you how this works.
>>
>> Martin
>>
>> Sent with ProtonMail Secure Email.
>>
>> ??????? Original Message ???????
>>
>> Le samedi 18 septembre 2021 ? 12:56, John Rose john.r.rose at oracle.com a ?crit :
>>
>>> Actually the JOGL work is one of the old inspirations for Panama.
>>>
>>> The idea that we could use declarative schema information (instead of imperatives coded C wrappers) to transition between Java and native libraries is found in SWIG, JOGL, Panama, JNR, and many other places. (I did a tech. like that in the mid ?90s for a pre-Java VM.)
>>>
>>> That said, surely even a JNI code generation tool is worse than something that just runs out of a JAR or jshell session. Eventually, I hope, we will tease apart the aspects of JNI into a proper set of primitives that allows, but does not require, hand written or tool written JNI C code.
>>>
>>> The primitives I am thinking of these days are:
>>>
>>> Panama native lookup accesses nearly all native entry point.
>>>
>>> These are optimizable by the JIT and/or AOT to be equivalent with today?s ad hoc JVM native transition wrappers.
>>>
>>> And then, a way to program any native method not only via JNI but via an Indy-style bootstrap method. This would lazily generate the body of the native method (driven by declarative information, typically) to a Panama wrapper or some other thing.
>>>
>>> The endgame is that native methods are fully meta programmable, not losing any JNI use cases (because Panama), but adding other ones, with suitable BSMs.
>>>
>>> In a world where native methods have BMMs, a JAR file can contain thousands of method definitions and zero byte codes. Each method will be elaborated just in time by a declarative BSM recipe. An AOT compiler can generate the equivalent of JNI stubs if requested but it?s not needed because the (Panama based) runtime knows how to generate the stubs as early or as late as needed.
>>>
>>> JOGL can stay as it is until it is ready to retool into the more powerful framework.
>>>
>>>> On Sep 17, 2021, at 9:26 AM, Maurizio Cimadamore Maurizio.Cimadamore at oracle.com wrote:
>>>>
>>>> Hi Martin,
>>>>
>>>> We have no plans to drop support for JNI. JEP 412 offers a replacement which allows libraries to express bindings purely in Java code. In most cases, this is desirable, but I understand that frameworks written prior that JEP might have little to no appetite to rewrite everyting to use MethodHandle/VarHandle and/or jextract.
>>>>
>>>> As you noted, OpenGL works well with the new foreign APIs, and we have written various samples using OpenGL bindings generated by jextract.
>>>>
>>>> That said, it is beyond the goal of JEP 412 (and its succesors) to provide an uniform OpenGL API within the JDK - but I think the foreign APIs and the tools (jextract) are now reaching a level of maturity which would allow for such experiments to occur outside the JDK, and we'd be pleased to hear some feedback in the panama-dev mailing list!
>>>>
>>>> Hope this answers your question
>>>>
>>>> Maurizio
>>>>
>>>>> On 17/09/2021 12:54, Martin Pernollet wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> I actively maintain Jzy3D [1], a framework for drawing 3D charts in Java. It uses JOGL which access native OpenGL with the help of GlueGen, a tool to generate JNI bindings. Jzy3D has an additional OpenGL pure Java CPU renderer [2] to circumvent compatibility limitations of JOGL, mainly for MacOS.
>>>>>
>>>>> Will JEP-412 close the doors to bindings relying on JNI? In other word will JOGL be able to continue working with GlueGen and JNI?
>>>>>
>>>>> Are there known plans in OpenJDK for enabling OpenGL (+Metal?) consistently across OS and hardwares via a unified API? II have seen an OpenGL example based on JEP-412 here [3]. I would be interested to assist on that topic and may help making Jzy3D compatible to such API. Jzy3D indeed offers a IPainter interface [4] that allows pluging multiple implementations of OpenGL for Java, hence helping to compare JOGL, EmulGL or any other OpenGL java API.
>>>>>
>>>>> Thanks in advance,
>>>>>
>>>>> Martin
>>>>>
>>>>> [1] https://urldefense.com/v3/__http://jzy3d.org/__;!!ACWV5N9M2RV99hQ!bD8kYg-yxOkAx3K51U-h3dQqyLInU20XCvH8O8KiyWJ-qrZS3rxRah14L9c_RhltGULw2_M$
>>>>>
>>>>> [2] https://urldefense.com/v3/__https://github.com/jzy3d/jzy3d-api/tree/69a14166096a46bfb6e74cd3ab02e11d41c09024/jzy3d-emul-gl__;!!ACWV5N9M2RV99hQ!bD8kYg-yxOkAx3K51U-h3dQqyLInU20XCvH8O8KiyWJ-qrZS3rxRah14L9c_Rhlt1e2WRMw$
>>>>>
>>>>> [3] https://urldefense.com/v3/__https://github.com/sundararajana/panama-jextract-samples/tree/master/opengl__;!!ACWV5N9M2RV99hQ!bD8kYg-yxOkAx3K51U-h3dQqyLInU20XCvH8O8KiyWJ-qrZS3rxRah14L9c_RhltTdkbjNo$
>>>>>
>>>>> [4] https://urldefense.com/v3/__https://github.com/jzy3d/jzy3d-api/blob/69a14166096a46bfb6e74cd3ab02e11d41c09024/jzy3d-core/src/main/java/org/jzy3d/painters/IPainter.java__;!!ACWV5N9M2RV99hQ!bD8kYg-yxOkAx3K51U-h3dQqyLInU20XCvH8O8KiyWJ-qrZS3rxRah14L9c_RhltwLuRJOg$

From maurizio.cimadamore at oracle.com  Tue Sep 21 13:03:07 2021
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 21 Sep 2021 14:03:07 +0100
Subject: Will we need to use the --enable-native-access option to enable
 JNI in the future?
In-Reply-To: 
References: 
 
 
 
 
 <18b80809-54b1-1b40-e5f2-a2b1a4e10711@oracle.com>
 
 <2eb43d4c-6eee-39f7-877b-d98681773520@oracle.com>
 
Message-ID: <089050e0-0551-a2b5-7e2b-ba3d4b302161@oracle.com>

Without diving into the specifics of Android etc. I believe the 
"environment" concept kicks the can down the road. What is an 
environment? It's probably a Java runtime with certain properties set. 
How do you set these properties? This is, fundamentally, the same 
problem we're tackling with --enable-native-access. In a way you can 
think of these options as a way to define an execution "environment" 
that is tailored for your application's needs (e.g. a client can even 
define its own JDK image using jlink, and inject all required 
--enable-native-access options into the resulting image - which is 
probably the closest concept we have in OpenJDK of your "environment").

So, I think we're tackling the problem at the right level (at least for 
OpenJDK) - but there are questions Glavo raises on whether the 
simplistic mechanism we provide now is enough for real world use; more 
specifically:

* lack of a way to mark native modules in the source code
* lack of a way to propagate native access between dependent modules
* lack of a way to dynamically grant native access to module in a layer

All these things contribute, I think, to make the command-line somewhat 
unstable - e.g. whenever the internals of some module change (e.g. 
module B depends on module C which starts to use Panama), the 
application command line will have to change to reflect that. There is a 
precedent for this, which is "--add-opens" - the question is as to 
whether that precedent is a good one for Panama or not.

Maurizio


On 21/09/2021 12:59, Samuel Audet wrote:
> FWIW, I think the core issue comes from the fact that the Java 
> platform is unable to take responsibility for any of the native code, 
> so what about a way to define some sort of "environment", for the lack 
> of a better word. For example, when the code gets loaded on Android, 
> iOS, or WebAssembly, we already know that the native code is going to 
> run in a sandbox, so we shouldn't have to specify any flags because 
> executing any native code is already considered as "safe" by the 
> native platform. Maybe not as "safe" as Java code, but that's not the 
> point, the point is that maybe the decision should be deferred to the 
> underlying platform? Thoughts?
>
> Samuel
>
> On Tue, Sep 21, 2021, 19:20 Maurizio Cimadamore 
>  > wrote:
>
>     I'll zoom in on this issue, because I think it's the one we need to
>     understand the most. For the record, I don't despise all code at
>     all -
>     but I also think that the position of "must be run with a clean `java
>     -jar`, no extra arguments" is (while a good goal) a bit unrealistic.
>     Most of the real world Java application I've seen all need to drop in
>     some extra command line option (e.g. -Xmx), but I think your problem
>     here is more specific than "just add a command line option" - the
>     problem is adding an option that is only supported on _some_ JDKs
>     (see
>     below).
>
>     On 21/09/2021 03:51, Glavo wrote:
>     > In my original plan, I would convert it into a multi-release jar.
>     > On the Java platform available to Panama, I will use Panama to call
>     > the system API.?This will allow me to adapt to more platforms (e.g.
>     > mips64el).
>     > Panama's restrictions made me abandon this scheme.?Because
>     > I can't execute it on any version of Java platform with a
>     unified?command.
>
>     I think this is the real important point here. I'd like to understand
>     more about this use case. Do you have an executable AND multi-release
>     JAR? Is it an application that you are developing? Do you want that
>     application to be just executed using `java -jar foo.jar`? Does your
>     application have a launcher to trigger the `java -jar` command?
>
>     Please walk me through your use case a bit, and please let's keep the
>     conversation focussed - arguing over general safety principles is not
>     very helpful, when the real problem is, I suspect, driven by
>     something
>     much more concrete.
>
>     Thanks
>     Maurizio
>
>

From martin.pernollet at protonmail.com  Tue Sep 21 14:41:43 2021
From: martin.pernollet at protonmail.com (Martin Pernollet)
Date: Tue, 21 Sep 2021 14:41:43 +0000
Subject: JEP-412 & OpenGL
In-Reply-To: 
References: 
 <44916ce4-1174-28d0-6cff-28ee6ac7b487@oracle.com>
 <91EE3A16-B5E3-4DAA-A299-6B332178B5A0@oracle.com>
 <20IAXMh_D5CwrlzRuub4xeEQVgsdy_SG-PGZ_mFzrEPcaCOUWu2_6lwXTxR10bHTJmUQW8Xaq0xnen8Fmp65kBkg3Nikf1y-h2zDL-80-lI=@protonmail.com>
 
 
Message-ID: 

Yes, I also added it at runtime as follow

java -jar target/panama-gl-2.0.1-SNAPSHOT.jar -XstartOnFirstThread     --enable-native-access=ALL-UNNAMED --add-modules jdk.incubator.foreign     -Djava.library.path=.:/System/Library/Frameworks/OpenGL.framework/Versions/Current/Libraries/

But the error was coming from the position of the -jar argument. I can go (just a little) further by putting the -jar argument at the end as follow

java  -XstartOnFirstThread --enable-native-access=ALL-UNNAMED     --add-modules jdk.incubator.foreign     -Djava.library.path=.:/System/Library/Frameworks/OpenGL.framework/Versions/Current/Libraries/ -jar target/panama-gl-2.0.1-SNAPSHOT.jar

WARNING: Using incubator modules: jdk.incubator.foreign
Exception in thread "main" java.lang.IllegalAccessError: failed to access class opengl.glut_h_3 from class Teapot (opengl.glut_h_3 and Teapot are in unnamed module of loader 'app')
	at Teapot.main(Teapot.java:80)

Still have to learn a few things about modules :)

Sent with ProtonMail Secure Email.

??????? Original Message ???????

Le mardi 21 septembre 2021 ? 14:41, Maurizio Cimadamore  a ?crit :

> Hi Martin,
>
> I think the compilation setup looks correct. The question is how do you
>
> run the application? The --add-modules option has to be added both at
>
> compile-time (which you are doing) and at run-time.
>
> Maurizio
>
> On 21/09/2021 13:15, Martin Pernollet wrote:
>
> > Hi everyone,
> >
> > I followed the steps of the OpenGL tutorial and mentioned them here [1]. I got stuck with the below error when running the JAR - which I create with Maven + Shade plugin to later use Jzy3D and Panama together.
> >
> > Error: Unable to initialize main class Teapot
> >
> > Caused by: java.lang.NoClassDefFoundError: jdk/incubator/foreign/Addressable
> >
> > Do you have a suggestion for this? I already tried building by passing the --add-modules in three different ways :
> >
> > (1) mvn install -D--add-modules=jdk.incubator.foreign
> >
> > (2) mvn install --add-modules jdk.incubator.foreign
> >
> > (3) mvn install without arguments by relying on maven compiler plugin setup as follow
> >
> > 
> >
> > maven-compiler-plugin
> >
> > 2.3.2
> >
> > 
> >
> > 17
> >
> > 17
> >
> > UTF-8
> >
> > 
> >
> > --add-modules
> >
> > jdk.incubator.foreign
> >
> > --add-exports
> >
> > jdk.incubator.foreign
> >
> > 
> >
> > 
> >
> > 
> >
> > I'll gladly bundled the Q&A in the above readme for other developers.
> >
> > Thanks in advance,
> >
> > Martin
> >
> > [1] https://urldefense.com/v3/https://github.com/jzy3d/panama-gl;!!ACWV5N9M2RV99hQ!bD8kYg-yxOkAx3K51U-h3dQqyLInU20XCvH8O8KiyWJ-qrZS3rxRah14L9c_Rhlt8SNQYGs$
> >
> > [2] https://urldefense.com/v3/https://github.com/sundararajana/panama-jextract-samples/issues;!!ACWV5N9M2RV99hQ!bD8kYg-yxOkAx3K51U-h3dQqyLInU20XCvH8O8KiyWJ-qrZS3rxRah14L9c_Rhlt2ft10UE$
> >
> > Sent with ProtonMail Secure Email.
> >
> > ??????? Original Message ???????
> >
> > Le lundi 20 septembre 2021 ? 14:24, Martin Pernollet martin.pernollet at protonmail.com a ?crit :
> >
> > > Thank you all for your answers.
> > >
> > > I'll give a try in the coming weeks and will tell you how this works.
> > >
> > > Martin
> > >
> > > Sent with ProtonMail Secure Email.
> > >
> > > ??????? Original Message ???????
> > >
> > > Le samedi 18 septembre 2021 ? 12:56, John Rose john.r.rose at oracle.com a ?crit :
> > >
> > > > Actually the JOGL work is one of the old inspirations for Panama.
> > > >
> > > > The idea that we could use declarative schema information (instead of imperatives coded C wrappers) to transition between Java and native libraries is found in SWIG, JOGL, Panama, JNR, and many other places. (I did a tech. like that in the mid ?90s for a pre-Java VM.)
> > > >
> > > > That said, surely even a JNI code generation tool is worse than something that just runs out of a JAR or jshell session. Eventually, I hope, we will tease apart the aspects of JNI into a proper set of primitives that allows, but does not require, hand written or tool written JNI C code.
> > > >
> > > > The primitives I am thinking of these days are:
> > > >
> > > > Panama native lookup accesses nearly all native entry point.
> > > >
> > > > These are optimizable by the JIT and/or AOT to be equivalent with today?s ad hoc JVM native transition wrappers.
> > > >
> > > > And then, a way to program any native method not only via JNI but via an Indy-style bootstrap method. This would lazily generate the body of the native method (driven by declarative information, typically) to a Panama wrapper or some other thing.
> > > >
> > > > The endgame is that native methods are fully meta programmable, not losing any JNI use cases (because Panama), but adding other ones, with suitable BSMs.
> > > >
> > > > In a world where native methods have BMMs, a JAR file can contain thousands of method definitions and zero byte codes. Each method will be elaborated just in time by a declarative BSM recipe. An AOT compiler can generate the equivalent of JNI stubs if requested but it?s not needed because the (Panama based) runtime knows how to generate the stubs as early or as late as needed.
> > > >
> > > > JOGL can stay as it is until it is ready to retool into the more powerful framework.
> > > >
> > > > > On Sep 17, 2021, at 9:26 AM, Maurizio Cimadamore Maurizio.Cimadamore at oracle.com wrote:
> > > > >
> > > > > Hi Martin,
> > > > >
> > > > > We have no plans to drop support for JNI. JEP 412 offers a replacement which allows libraries to express bindings purely in Java code. In most cases, this is desirable, but I understand that frameworks written prior that JEP might have little to no appetite to rewrite everyting to use MethodHandle/VarHandle and/or jextract.
> > > > >
> > > > > As you noted, OpenGL works well with the new foreign APIs, and we have written various samples using OpenGL bindings generated by jextract.
> > > > >
> > > > > That said, it is beyond the goal of JEP 412 (and its succesors) to provide an uniform OpenGL API within the JDK - but I think the foreign APIs and the tools (jextract) are now reaching a level of maturity which would allow for such experiments to occur outside the JDK, and we'd be pleased to hear some feedback in the panama-dev mailing list!
> > > > >
> > > > > Hope this answers your question
> > > > >
> > > > > Maurizio
> > > > >
> > > > > > On 17/09/2021 12:54, Martin Pernollet wrote:
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > I actively maintain Jzy3D [1], a framework for drawing 3D charts in Java. It uses JOGL which access native OpenGL with the help of GlueGen, a tool to generate JNI bindings. Jzy3D has an additional OpenGL pure Java CPU renderer [2] to circumvent compatibility limitations of JOGL, mainly for MacOS.
> > > > > >
> > > > > > Will JEP-412 close the doors to bindings relying on JNI? In other word will JOGL be able to continue working with GlueGen and JNI?
> > > > > >
> > > > > > Are there known plans in OpenJDK for enabling OpenGL (+Metal?) consistently across OS and hardwares via a unified API? II have seen an OpenGL example based on JEP-412 here [3]. I would be interested to assist on that topic and may help making Jzy3D compatible to such API. Jzy3D indeed offers a IPainter interface [4] that allows pluging multiple implementations of OpenGL for Java, hence helping to compare JOGL, EmulGL or any other OpenGL java API.
> > > > > >
> > > > > > Thanks in advance,
> > > > > >
> > > > > > Martin
> > > > > >
> > > > > > [1] https://urldefense.com/v3/http://jzy3d.org/;!!ACWV5N9M2RV99hQ!bD8kYg-yxOkAx3K51U-h3dQqyLInU20XCvH8O8KiyWJ-qrZS3rxRah14L9c_RhltGULw2_M$
> > > > > >
> > > > > > [2] https://urldefense.com/v3/https://github.com/jzy3d/jzy3d-api/tree/69a14166096a46bfb6e74cd3ab02e11d41c09024/jzy3d-emul-gl;!!ACWV5N9M2RV99hQ!bD8kYg-yxOkAx3K51U-h3dQqyLInU20XCvH8O8KiyWJ-qrZS3rxRah14L9c_Rhlt1e2WRMw$
> > > > > >
> > > > > > [3] https://urldefense.com/v3/https://github.com/sundararajana/panama-jextract-samples/tree/master/opengl;!!ACWV5N9M2RV99hQ!bD8kYg-yxOkAx3K51U-h3dQqyLInU20XCvH8O8KiyWJ-qrZS3rxRah14L9c_RhltTdkbjNo$
> > > > > >
> > > > > > [4] https://urldefense.com/v3/https://github.com/jzy3d/jzy3d-api/blob/69a14166096a46bfb6e74cd3ab02e11d41c09024/jzy3d-core/src/main/java/org/jzy3d/painters/IPainter.java;!!ACWV5N9M2RV99hQ!bD8kYg-yxOkAx3K51U-h3dQqyLInU20XCvH8O8KiyWJ-qrZS3rxRah14L9c_RhltwLuRJOg$

From zjx001202 at gmail.com  Tue Sep 21 16:09:38 2021
From: zjx001202 at gmail.com (Glavo)
Date: Wed, 22 Sep 2021 00:09:38 +0800
Subject: Will we need to use the --enable-native-access option to enable
 JNI in the future?
In-Reply-To: <2eb43d4c-6eee-39f7-877b-d98681773520@oracle.com>
References: 
 
 
 
 
 <18b80809-54b1-1b40-e5f2-a2b1a4e10711@oracle.com>
 
 <2eb43d4c-6eee-39f7-877b-d98681773520@oracle.com>
Message-ID: 

>
> I think this is the real important point here. I'd like to understand
> more about this use case. Do you have an executable AND multi-release
> JAR? Is it an application that you are developing? Do you want that
> application to be just executed using `java -jar foo.jar`? Does your
> application have a launcher to trigger the `java -jar` command?
>

Yes, even more than one of my programs are looking forward to introducing
Panama to improve some corner features, even if they don't use native
methods at present: Although using native access can improve the user
experience, it is not necessary. If JNI is introduced, the build and
testing process will be extremely complex, and it is difficult to support
some niche platforms (e.g. Linux MIPS64el). JNA or JNR will significantly
expand the size of small programs. I expect to use Panama as an alternative
to JNA to implement some optional functions, enable it on Java 21, and
gracefully fallback in earlier versions.


Using a more specific example, there is a JavaFX GUI application that
I am involved in developing. It's a popular program. We have more than
*one hundred thousand users*. This is a program for ordinary users. Most
of them are not developers.

It is always distributed as a fatJar (~3.6MB) and is expected to be
out of the box except (Only need Java environment). In order to make it
out of the box, it will automatically download OpenJFX at runtime and
put it into module path by dirty way (Use BuiltinClassLoader::loadModule).

It has a launcher, but not always available. We splice an exe in front
of the contents of the jar file (It is still a JAR, which is allowed
by the ZIP format). The launcher will look for java.exe in several
places and start the program with CreateProcess. However, our program
is cross platform, and there are many users who do not use Windows,
and our launcher is only effective on the Windows platform.
On other platforms, we simply distribute the fatJar. Fortunately, it
works well because the double-click action of jar on the Mac OS is
open it with java -jar. For Linux users, the most common usage is to
start it with java -jar. Moreover, many of our windows users will use
jar instead of exe version, because the double-click action of jar will
also be associated when installing JRE, so they often do not need to
rely on launcher.

We have no plans to provide launchers on platforms other than windows,
We won't give up Java 8 for a long time (maybe before 2031, but maybe
later). Bundling JRE and distributing it is absolutely unacceptable.
It will expand our application distribution by more than seven times,
and expand the volume after decompression by more than 20 times!
It is acceptable for us to recommend users to install Java by themselves,
because the program is related to minecraft, and users always need a
JRE. We want to keep the form of distributing a single jar. Being clean
and portable software is one of its selling points.

For the record, I don't despise all code at all -
> but I also think that the position of "must be run with a clean `java
> -jar`, no extra arguments" is (while a good goal) a bit unrealistic.
> Most of the real world Java application I've seen all need to drop in
> some extra command line option (e.g. -Xmx), but I think your problem
> here is more specific than "just add a command line option" - the
> problem is adding an option that is only supported on _some_ JDKs (see
> below).
>

I don't think this is unrealistic. Java's default options are good
enough for most small programs, and I have noticed that Java has been
improving out of box availability. I believe that Java's default options
will be good enough for most client applications in the future.

Please walk me through your use case a bit, and please let's keep the
> conversation focussed - arguing over general safety principles is not
> very helpful, when the real problem is, I suspect, driven by something
> much more concrete.
>

I know you have your point of view, and I don't want to keep pestering
on it. But I want to remind you one last time: This option is currently
very confusing to users, at least the name is problematic. At present,
it cannot restrict native access, but it implies that it has this
ability. This is a security risk. I insist that for the time being,
Panama should not force the check of native access execution by default.
It needs to prepare the security mechanism and remind the user to use
it, but it should not start to execute by default until it is ready
to restrict JNI (and deprecated sun.misc.Unsafe).

Of course, real-world safety problems often come from dynamically
loaded code, but it also reduces the value of this option. I hope that
Panama will pay more attention to dynamic safety management rather
than static safety.


Here I would like to add another question:
Is it too coarse-grained to always manage native access permissions
based on modules? This seems appropriate for a binding library or a
library that often uses foreign memory. However, for some modules with
only a few methods that require native access, can't I grant temporary
permissions? Just like:

  doWithNativeAccess(() -> {
      someUnsafeMethod(); // ok
  });
  someUnsafeMethod(); // IllegalCallerException

Maurizio Cimadamore  ?2021?9?21??? ??6:20???

> I'll zoom in on this issue, because I think it's the one we need to
> understand the most. For the record, I don't despise all code at all -
> but I also think that the position of "must be run with a clean `java
> -jar`, no extra arguments" is (while a good goal) a bit unrealistic.
> Most of the real world Java application I've seen all need to drop in
> some extra command line option (e.g. -Xmx), but I think your problem
> here is more specific than "just add a command line option" - the
> problem is adding an option that is only supported on _some_ JDKs (see
> below).
>
> On 21/09/2021 03:51, Glavo wrote:
> > In my original plan, I would convert it into a multi-release jar.
> > On the Java platform available to Panama, I will use Panama to call
> > the system API. This will allow me to adapt to more platforms (e.g.
> > mips64el).
> > Panama's restrictions made me abandon this scheme. Because
> > I can't execute it on any version of Java platform with a
> unified command.
>
> I think this is the real important point here. I'd like to understand
> more about this use case. Do you have an executable AND multi-release
> JAR? Is it an application that you are developing? Do you want that
> application to be just executed using `java -jar foo.jar`? Does your
> application have a launcher to trigger the `java -jar` command?
>
> Please walk me through your use case a bit, and please let's keep the
> conversation focussed - arguing over general safety principles is not
> very helpful, when the real problem is, I suspect, driven by something
> much more concrete.
>
> Thanks
> Maurizio
>
>
>

From martin.pernollet at protonmail.com  Tue Sep 21 12:15:02 2021
From: martin.pernollet at protonmail.com (Martin Pernollet)
Date: Tue, 21 Sep 2021 12:15:02 +0000
Subject: JEP-412 & OpenGL
In-Reply-To: <20IAXMh_D5CwrlzRuub4xeEQVgsdy_SG-PGZ_mFzrEPcaCOUWu2_6lwXTxR10bHTJmUQW8Xaq0xnen8Fmp65kBkg3Nikf1y-h2zDL-80-lI=@protonmail.com>
References: 
 <44916ce4-1174-28d0-6cff-28ee6ac7b487@oracle.com>
 <91EE3A16-B5E3-4DAA-A299-6B332178B5A0@oracle.com>
 <20IAXMh_D5CwrlzRuub4xeEQVgsdy_SG-PGZ_mFzrEPcaCOUWu2_6lwXTxR10bHTJmUQW8Xaq0xnen8Fmp65kBkg3Nikf1y-h2zDL-80-lI=@protonmail.com>
Message-ID: 

Hi everyone,

I followed the steps of the OpenGL tutorial and mentioned them here [1]. I got stuck with the below error when running the JAR - which I create with Maven + Shade plugin to later use Jzy3D and Panama together.

Error: Unable to initialize main class Teapot
Caused by: java.lang.NoClassDefFoundError: jdk/incubator/foreign/Addressable

Do you have a suggestion for this? I already tried building by passing the --add-modules in three different ways :

(1) mvn install -D--add-modules=jdk.incubator.foreign
(2) mvn install --add-modules jdk.incubator.foreign
(3) mvn install without arguments by relying on maven compiler plugin setup as follow


	maven-compiler-plugin
	2.3.2
	
		17
		17
		UTF-8
		
			--add-modules
			jdk.incubator.foreign
			--add-exports
			jdk.incubator.foreign
		
	



I'll gladly bundled the Q&A in the above readme for other developers.

Thanks in advance,

Martin

[1] https://github.com/jzy3d/panama-gl
[2] https://github.com/sundararajana/panama-jextract-samples/issues

Sent with ProtonMail Secure Email.

??????? Original Message ???????

Le lundi 20 septembre 2021 ? 14:24, Martin Pernollet  a ?crit :

> Thank you all for your answers.
>
> I'll give a try in the coming weeks and will tell you how this works.
>
> Martin
>
> Sent with ProtonMail Secure Email.
>
> ??????? Original Message ???????
>
> Le samedi 18 septembre 2021 ? 12:56, John Rose john.r.rose at oracle.com a ?crit :
>
> > Actually the JOGL work is one of the old inspirations for Panama.
> >
> > The idea that we could use declarative schema information (instead of imperatives coded C wrappers) to transition between Java and native libraries is found in SWIG, JOGL, Panama, JNR, and many other places. (I did a tech. like that in the mid ?90s for a pre-Java VM.)
> >
> > That said, surely even a JNI code generation tool is worse than something that just runs out of a JAR or jshell session. Eventually, I hope, we will tease apart the aspects of JNI into a proper set of primitives that allows, but does not require, hand written or tool written JNI C code.
> >
> > The primitives I am thinking of these days are:
> >
> > Panama native lookup accesses nearly all native entry point.
> >
> > These are optimizable by the JIT and/or AOT to be equivalent with today?s ad hoc JVM native transition wrappers.
> >
> > And then, a way to program any native method not only via JNI but via an Indy-style bootstrap method. This would lazily generate the body of the native method (driven by declarative information, typically) to a Panama wrapper or some other thing.
> >
> > The endgame is that native methods are fully meta programmable, not losing any JNI use cases (because Panama), but adding other ones, with suitable BSMs.
> >
> > In a world where native methods have BMMs, a JAR file can contain thousands of method definitions and zero byte codes. Each method will be elaborated just in time by a declarative BSM recipe. An AOT compiler can generate the equivalent of JNI stubs if requested but it?s not needed because the (Panama based) runtime knows how to generate the stubs as early or as late as needed.
> >
> > JOGL can stay as it is until it is ready to retool into the more powerful framework.
> >
> > > On Sep 17, 2021, at 9:26 AM, Maurizio Cimadamore Maurizio.Cimadamore at oracle.com wrote:
> > >
> > > Hi Martin,
> > >
> > > We have no plans to drop support for JNI. JEP 412 offers a replacement which allows libraries to express bindings purely in Java code. In most cases, this is desirable, but I understand that frameworks written prior that JEP might have little to no appetite to rewrite everyting to use MethodHandle/VarHandle and/or jextract.
> > >
> > > As you noted, OpenGL works well with the new foreign APIs, and we have written various samples using OpenGL bindings generated by jextract.
> > >
> > > That said, it is beyond the goal of JEP 412 (and its succesors) to provide an uniform OpenGL API within the JDK - but I think the foreign APIs and the tools (jextract) are now reaching a level of maturity which would allow for such experiments to occur outside the JDK, and we'd be pleased to hear some feedback in the panama-dev mailing list!
> > >
> > > Hope this answers your question
> > >
> > > Maurizio
> > >
> > > > On 17/09/2021 12:54, Martin Pernollet wrote:
> > > >
> > > > Hi,
> > > >
> > > > I actively maintain Jzy3D [1], a framework for drawing 3D charts in Java. It uses JOGL which access native OpenGL with the help of GlueGen, a tool to generate JNI bindings. Jzy3D has an additional OpenGL pure Java CPU renderer [2] to circumvent compatibility limitations of JOGL, mainly for MacOS.
> > > >
> > > > Will JEP-412 close the doors to bindings relying on JNI? In other word will JOGL be able to continue working with GlueGen and JNI?
> > > >
> > > > Are there known plans in OpenJDK for enabling OpenGL (+Metal?) consistently across OS and hardwares via a unified API? II have seen an OpenGL example based on JEP-412 here [3]. I would be interested to assist on that topic and may help making Jzy3D compatible to such API. Jzy3D indeed offers a IPainter interface [4] that allows pluging multiple implementations of OpenGL for Java, hence helping to compare JOGL, EmulGL or any other OpenGL java API.
> > > >
> > > > Thanks in advance,
> > > >
> > > > Martin
> > > >
> > > > [1] http://jzy3d.org/
> > > >
> > > > [2] https://github.com/jzy3d/jzy3d-api/tree/69a14166096a46bfb6e74cd3ab02e11d41c09024/jzy3d-emul-gl
> > > >
> > > > [3] https://github.com/sundararajana/panama-jextract-samples/tree/master/opengl
> > > >
> > > > [4] https://github.com/jzy3d/jzy3d-api/blob/69a14166096a46bfb6e74cd3ab02e11d41c09024/jzy3d-core/src/main/java/org/jzy3d/painters/IPainter.java

From maurizio.cimadamore at oracle.com  Tue Sep 21 16:40:13 2021
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 21 Sep 2021 17:40:13 +0100
Subject: JEP-412 & OpenGL
In-Reply-To: 
References: 
 <44916ce4-1174-28d0-6cff-28ee6ac7b487@oracle.com>
 <91EE3A16-B5E3-4DAA-A299-6B332178B5A0@oracle.com>
 <20IAXMh_D5CwrlzRuub4xeEQVgsdy_SG-PGZ_mFzrEPcaCOUWu2_6lwXTxR10bHTJmUQW8Xaq0xnen8Fmp65kBkg3Nikf1y-h2zDL-80-lI=@protonmail.com>
 
 
 
Message-ID: <629d4e7f-4e6c-dffe-f13a-25362db05b65@oracle.com>

Can you do a quick experiment and remove the shade plugin from the 
picture? E.g. just build the classes and run?

I have a feeling that shade is rewriting the classes in a slightly 
incompatible way.

Thanks
Maurizio

On 21/09/2021 15:41, Martin Pernollet wrote:
> Yes, I also added it at runtime as follow
>
> java -jar target/panama-gl-2.0.1-SNAPSHOT.jar -XstartOnFirstThread     --enable-native-access=ALL-UNNAMED --add-modules jdk.incubator.foreign     -Djava.library.path=.:/System/Library/Frameworks/OpenGL.framework/Versions/Current/Libraries/
>
> But the error was coming from the position of the -jar argument. I can go (just a little) further by putting the -jar argument at the end as follow
>
> java  -XstartOnFirstThread --enable-native-access=ALL-UNNAMED     --add-modules jdk.incubator.foreign     -Djava.library.path=.:/System/Library/Frameworks/OpenGL.framework/Versions/Current/Libraries/ -jar target/panama-gl-2.0.1-SNAPSHOT.jar
>
> WARNING: Using incubator modules: jdk.incubator.foreign
> Exception in thread "main" java.lang.IllegalAccessError: failed to access class opengl.glut_h_3 from class Teapot (opengl.glut_h_3 and Teapot are in unnamed module of loader 'app')
> 	at Teapot.main(Teapot.java:80)
>
> Still have to learn a few things about modules :)
>
> Sent with ProtonMail Secure Email.
>
> ??????? Original Message ???????
>
> Le mardi 21 septembre 2021 ? 14:41, Maurizio Cimadamore  a ?crit :
>
>> Hi Martin,
>>
>> I think the compilation setup looks correct. The question is how do you
>>
>> run the application? The --add-modules option has to be added both at
>>
>> compile-time (which you are doing) and at run-time.
>>
>> Maurizio
>>
>> On 21/09/2021 13:15, Martin Pernollet wrote:
>>
>>> Hi everyone,
>>>
>>> I followed the steps of the OpenGL tutorial and mentioned them here [1]. I got stuck with the below error when running the JAR - which I create with Maven + Shade plugin to later use Jzy3D and Panama together.
>>>
>>> Error: Unable to initialize main class Teapot
>>>
>>> Caused by: java.lang.NoClassDefFoundError: jdk/incubator/foreign/Addressable
>>>
>>> Do you have a suggestion for this? I already tried building by passing the --add-modules in three different ways :
>>>
>>> (1) mvn install -D--add-modules=jdk.incubator.foreign
>>>
>>> (2) mvn install --add-modules jdk.incubator.foreign
>>>
>>> (3) mvn install without arguments by relying on maven compiler plugin setup as follow
>>>
>>> 
>>>
>>> maven-compiler-plugin
>>>
>>> 2.3.2
>>>
>>> 
>>>
>>> 17
>>>
>>> 17
>>>
>>> UTF-8
>>>
>>> 
>>>
>>> --add-modules
>>>
>>> jdk.incubator.foreign
>>>
>>> --add-exports
>>>
>>> jdk.incubator.foreign
>>>
>>> 
>>>
>>> 
>>>
>>> 
>>>
>>> I'll gladly bundled the Q&A in the above readme for other developers.
>>>
>>> Thanks in advance,
>>>
>>> Martin
>>>
>>> [1] https://urldefense.com/v3/https://github.com/jzy3d/panama-gl;!!ACWV5N9M2RV99hQ!bD8kYg-yxOkAx3K51U-h3dQqyLInU20XCvH8O8KiyWJ-qrZS3rxRah14L9c_Rhlt8SNQYGs$
>>>
>>> [2] https://urldefense.com/v3/https://github.com/sundararajana/panama-jextract-samples/issues;!!ACWV5N9M2RV99hQ!bD8kYg-yxOkAx3K51U-h3dQqyLInU20XCvH8O8KiyWJ-qrZS3rxRah14L9c_Rhlt2ft10UE$
>>>
>>> Sent with ProtonMail Secure Email.
>>>
>>> ??????? Original Message ???????
>>>
>>> Le lundi 20 septembre 2021 ? 14:24, Martin Pernollet martin.pernollet at protonmail.com a ?crit :
>>>
>>>> Thank you all for your answers.
>>>>
>>>> I'll give a try in the coming weeks and will tell you how this works.
>>>>
>>>> Martin
>>>>
>>>> Sent with ProtonMail Secure Email.
>>>>
>>>> ??????? Original Message ???????
>>>>
>>>> Le samedi 18 septembre 2021 ? 12:56, John Rose john.r.rose at oracle.com a ?crit :
>>>>
>>>>> Actually the JOGL work is one of the old inspirations for Panama.
>>>>>
>>>>> The idea that we could use declarative schema information (instead of imperatives coded C wrappers) to transition between Java and native libraries is found in SWIG, JOGL, Panama, JNR, and many other places. (I did a tech. like that in the mid ?90s for a pre-Java VM.)
>>>>>
>>>>> That said, surely even a JNI code generation tool is worse than something that just runs out of a JAR or jshell session. Eventually, I hope, we will tease apart the aspects of JNI into a proper set of primitives that allows, but does not require, hand written or tool written JNI C code.
>>>>>
>>>>> The primitives I am thinking of these days are:
>>>>>
>>>>> Panama native lookup accesses nearly all native entry point.
>>>>>
>>>>> These are optimizable by the JIT and/or AOT to be equivalent with today?s ad hoc JVM native transition wrappers.
>>>>>
>>>>> And then, a way to program any native method not only via JNI but via an Indy-style bootstrap method. This would lazily generate the body of the native method (driven by declarative information, typically) to a Panama wrapper or some other thing.
>>>>>
>>>>> The endgame is that native methods are fully meta programmable, not losing any JNI use cases (because Panama), but adding other ones, with suitable BSMs.
>>>>>
>>>>> In a world where native methods have BMMs, a JAR file can contain thousands of method definitions and zero byte codes. Each method will be elaborated just in time by a declarative BSM recipe. An AOT compiler can generate the equivalent of JNI stubs if requested but it?s not needed because the (Panama based) runtime knows how to generate the stubs as early or as late as needed.
>>>>>
>>>>> JOGL can stay as it is until it is ready to retool into the more powerful framework.
>>>>>
>>>>>> On Sep 17, 2021, at 9:26 AM, Maurizio Cimadamore Maurizio.Cimadamore at oracle.com wrote:
>>>>>>
>>>>>> Hi Martin,
>>>>>>
>>>>>> We have no plans to drop support for JNI. JEP 412 offers a replacement which allows libraries to express bindings purely in Java code. In most cases, this is desirable, but I understand that frameworks written prior that JEP might have little to no appetite to rewrite everyting to use MethodHandle/VarHandle and/or jextract.
>>>>>>
>>>>>> As you noted, OpenGL works well with the new foreign APIs, and we have written various samples using OpenGL bindings generated by jextract.
>>>>>>
>>>>>> That said, it is beyond the goal of JEP 412 (and its succesors) to provide an uniform OpenGL API within the JDK - but I think the foreign APIs and the tools (jextract) are now reaching a level of maturity which would allow for such experiments to occur outside the JDK, and we'd be pleased to hear some feedback in the panama-dev mailing list!
>>>>>>
>>>>>> Hope this answers your question
>>>>>>
>>>>>> Maurizio
>>>>>>
>>>>>>> On 17/09/2021 12:54, Martin Pernollet wrote:
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I actively maintain Jzy3D [1], a framework for drawing 3D charts in Java. It uses JOGL which access native OpenGL with the help of GlueGen, a tool to generate JNI bindings. Jzy3D has an additional OpenGL pure Java CPU renderer [2] to circumvent compatibility limitations of JOGL, mainly for MacOS.
>>>>>>>
>>>>>>> Will JEP-412 close the doors to bindings relying on JNI? In other word will JOGL be able to continue working with GlueGen and JNI?
>>>>>>>
>>>>>>> Are there known plans in OpenJDK for enabling OpenGL (+Metal?) consistently across OS and hardwares via a unified API? II have seen an OpenGL example based on JEP-412 here [3]. I would be interested to assist on that topic and may help making Jzy3D compatible to such API. Jzy3D indeed offers a IPainter interface [4] that allows pluging multiple implementations of OpenGL for Java, hence helping to compare JOGL, EmulGL or any other OpenGL java API.
>>>>>>>
>>>>>>> Thanks in advance,
>>>>>>>
>>>>>>> Martin
>>>>>>>
>>>>>>> [1] https://urldefense.com/v3/http://jzy3d.org/;!!ACWV5N9M2RV99hQ!bD8kYg-yxOkAx3K51U-h3dQqyLInU20XCvH8O8KiyWJ-qrZS3rxRah14L9c_RhltGULw2_M$
>>>>>>>
>>>>>>> [2] https://urldefense.com/v3/https://github.com/jzy3d/jzy3d-api/tree/69a14166096a46bfb6e74cd3ab02e11d41c09024/jzy3d-emul-gl;!!ACWV5N9M2RV99hQ!bD8kYg-yxOkAx3K51U-h3dQqyLInU20XCvH8O8KiyWJ-qrZS3rxRah14L9c_Rhlt1e2WRMw$
>>>>>>>
>>>>>>> [3] https://urldefense.com/v3/https://github.com/sundararajana/panama-jextract-samples/tree/master/opengl;!!ACWV5N9M2RV99hQ!bD8kYg-yxOkAx3K51U-h3dQqyLInU20XCvH8O8KiyWJ-qrZS3rxRah14L9c_RhltTdkbjNo$
>>>>>>>
>>>>>>> [4] https://urldefense.com/v3/https://github.com/jzy3d/jzy3d-api/blob/69a14166096a46bfb6e74cd3ab02e11d41c09024/jzy3d-core/src/main/java/org/jzy3d/painters/IPainter.java;!!ACWV5N9M2RV99hQ!bD8kYg-yxOkAx3K51U-h3dQqyLInU20XCvH8O8KiyWJ-qrZS3rxRah14L9c_RhltwLuRJOg$

From jorn.vernee at oracle.com  Tue Sep 21 16:42:01 2021
From: jorn.vernee at oracle.com (Jorn Vernee)
Date: Tue, 21 Sep 2021 18:42:01 +0200
Subject: JEP-412 & OpenGL
In-Reply-To: 
References: 
 <44916ce4-1174-28d0-6cff-28ee6ac7b487@oracle.com>
 <91EE3A16-B5E3-4DAA-A299-6B332178B5A0@oracle.com>
 <20IAXMh_D5CwrlzRuub4xeEQVgsdy_SG-PGZ_mFzrEPcaCOUWu2_6lwXTxR10bHTJmUQW8Xaq0xnen8Fmp65kBkg3Nikf1y-h2zDL-80-lI=@protonmail.com>
 
 
 
Message-ID: <7e4389ad-1a15-d480-72af-e92c507ffe49@oracle.com>

Hi Martin,

Note that anything passed after the `-jar ` argument is a program 
argument, passing all the flags before `-jar` passes them as VM 
arguments, which is correct.

The second error message you are getting is a bit puzzling. It seems 
that somehow your Teapot class is directly trying to access an internal 
binding class.

Note that the generated bindings should be accessed through 
opengl.glut_h, which is public [1], instead of opengl.glut_h_3, which is 
package-private [2].

HTH,
Jorn

[1] : 
https://github.com/jzy3d/panama-gl/blob/main/src/main/java/opengl/glut_h.java
[2] : 
https://github.com/jzy3d/panama-gl/blob/main/src/main/java/opengl/glut_h_3.java

On 21/09/2021 16:41, Martin Pernollet wrote:
> Yes, I also added it at runtime as follow
>
> java -jar target/panama-gl-2.0.1-SNAPSHOT.jar -XstartOnFirstThread     --enable-native-access=ALL-UNNAMED --add-modules jdk.incubator.foreign     -Djava.library.path=.:/System/Library/Frameworks/OpenGL.framework/Versions/Current/Libraries/
>
> But the error was coming from the position of the -jar argument. I can go (just a little) further by putting the -jar argument at the end as follow
>
> java  -XstartOnFirstThread --enable-native-access=ALL-UNNAMED     --add-modules jdk.incubator.foreign     -Djava.library.path=.:/System/Library/Frameworks/OpenGL.framework/Versions/Current/Libraries/ -jar target/panama-gl-2.0.1-SNAPSHOT.jar
>
> WARNING: Using incubator modules: jdk.incubator.foreign
> Exception in thread "main" java.lang.IllegalAccessError: failed to access class opengl.glut_h_3 from class Teapot (opengl.glut_h_3 and Teapot are in unnamed module of loader 'app')
> 	at Teapot.main(Teapot.java:80)
>
> Still have to learn a few things about modules :)
>
> Sent with ProtonMail Secure Email.
>
> ??????? Original Message ???????
>
> Le mardi 21 septembre 2021 ? 14:41, Maurizio Cimadamore  a ?crit :
>
>> Hi Martin,
>>
>> I think the compilation setup looks correct. The question is how do you
>>
>> run the application? The --add-modules option has to be added both at
>>
>> compile-time (which you are doing) and at run-time.
>>
>> Maurizio
>>
>> On 21/09/2021 13:15, Martin Pernollet wrote:
>>
>>> Hi everyone,
>>>
>>> I followed the steps of the OpenGL tutorial and mentioned them here [1]. I got stuck with the below error when running the JAR - which I create with Maven + Shade plugin to later use Jzy3D and Panama together.
>>>
>>> Error: Unable to initialize main class Teapot
>>>
>>> Caused by: java.lang.NoClassDefFoundError: jdk/incubator/foreign/Addressable
>>>
>>> Do you have a suggestion for this? I already tried building by passing the --add-modules in three different ways :
>>>
>>> (1) mvn install -D--add-modules=jdk.incubator.foreign
>>>
>>> (2) mvn install --add-modules jdk.incubator.foreign
>>>
>>> (3) mvn install without arguments by relying on maven compiler plugin setup as follow
>>>
>>> 
>>>
>>> maven-compiler-plugin
>>>
>>> 2.3.2
>>>
>>> 
>>>
>>> 17
>>>
>>> 17
>>>
>>> UTF-8
>>>
>>> 
>>>
>>> --add-modules
>>>
>>> jdk.incubator.foreign
>>>
>>> --add-exports
>>>
>>> jdk.incubator.foreign
>>>
>>> 
>>>
>>> 
>>>
>>> 
>>>
>>> I'll gladly bundled the Q&A in the above readme for other developers.
>>>
>>> Thanks in advance,
>>>
>>> Martin
>>>
>>> [1] https://urldefense.com/v3/https://github.com/jzy3d/panama-gl;!!ACWV5N9M2RV99hQ!bD8kYg-yxOkAx3K51U-h3dQqyLInU20XCvH8O8KiyWJ-qrZS3rxRah14L9c_Rhlt8SNQYGs$
>>>
>>> [2] https://urldefense.com/v3/https://github.com/sundararajana/panama-jextract-samples/issues;!!ACWV5N9M2RV99hQ!bD8kYg-yxOkAx3K51U-h3dQqyLInU20XCvH8O8KiyWJ-qrZS3rxRah14L9c_Rhlt2ft10UE$
>>>
>>> Sent with ProtonMail Secure Email.
>>>
>>> ??????? Original Message ???????
>>>
>>> Le lundi 20 septembre 2021 ? 14:24, Martin Pernollet martin.pernollet at protonmail.com a ?crit :
>>>
>>>> Thank you all for your answers.
>>>>
>>>> I'll give a try in the coming weeks and will tell you how this works.
>>>>
>>>> Martin
>>>>
>>>> Sent with ProtonMail Secure Email.
>>>>
>>>> ??????? Original Message ???????
>>>>
>>>> Le samedi 18 septembre 2021 ? 12:56, John Rose john.r.rose at oracle.com a ?crit :
>>>>
>>>>> Actually the JOGL work is one of the old inspirations for Panama.
>>>>>
>>>>> The idea that we could use declarative schema information (instead of imperatives coded C wrappers) to transition between Java and native libraries is found in SWIG, JOGL, Panama, JNR, and many other places. (I did a tech. like that in the mid ?90s for a pre-Java VM.)
>>>>>
>>>>> That said, surely even a JNI code generation tool is worse than something that just runs out of a JAR or jshell session. Eventually, I hope, we will tease apart the aspects of JNI into a proper set of primitives that allows, but does not require, hand written or tool written JNI C code.
>>>>>
>>>>> The primitives I am thinking of these days are:
>>>>>
>>>>> Panama native lookup accesses nearly all native entry point.
>>>>>
>>>>> These are optimizable by the JIT and/or AOT to be equivalent with today?s ad hoc JVM native transition wrappers.
>>>>>
>>>>> And then, a way to program any native method not only via JNI but via an Indy-style bootstrap method. This would lazily generate the body of the native method (driven by declarative information, typically) to a Panama wrapper or some other thing.
>>>>>
>>>>> The endgame is that native methods are fully meta programmable, not losing any JNI use cases (because Panama), but adding other ones, with suitable BSMs.
>>>>>
>>>>> In a world where native methods have BMMs, a JAR file can contain thousands of method definitions and zero byte codes. Each method will be elaborated just in time by a declarative BSM recipe. An AOT compiler can generate the equivalent of JNI stubs if requested but it?s not needed because the (Panama based) runtime knows how to generate the stubs as early or as late as needed.
>>>>>
>>>>> JOGL can stay as it is until it is ready to retool into the more powerful framework.
>>>>>
>>>>>> On Sep 17, 2021, at 9:26 AM, Maurizio Cimadamore Maurizio.Cimadamore at oracle.com wrote:
>>>>>>
>>>>>> Hi Martin,
>>>>>>
>>>>>> We have no plans to drop support for JNI. JEP 412 offers a replacement which allows libraries to express bindings purely in Java code. In most cases, this is desirable, but I understand that frameworks written prior that JEP might have little to no appetite to rewrite everyting to use MethodHandle/VarHandle and/or jextract.
>>>>>>
>>>>>> As you noted, OpenGL works well with the new foreign APIs, and we have written various samples using OpenGL bindings generated by jextract.
>>>>>>
>>>>>> That said, it is beyond the goal of JEP 412 (and its succesors) to provide an uniform OpenGL API within the JDK - but I think the foreign APIs and the tools (jextract) are now reaching a level of maturity which would allow for such experiments to occur outside the JDK, and we'd be pleased to hear some feedback in the panama-dev mailing list!
>>>>>>
>>>>>> Hope this answers your question
>>>>>>
>>>>>> Maurizio
>>>>>>
>>>>>>> On 17/09/2021 12:54, Martin Pernollet wrote:
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I actively maintain Jzy3D [1], a framework for drawing 3D charts in Java. It uses JOGL which access native OpenGL with the help of GlueGen, a tool to generate JNI bindings. Jzy3D has an additional OpenGL pure Java CPU renderer [2] to circumvent compatibility limitations of JOGL, mainly for MacOS.
>>>>>>>
>>>>>>> Will JEP-412 close the doors to bindings relying on JNI? In other word will JOGL be able to continue working with GlueGen and JNI?
>>>>>>>
>>>>>>> Are there known plans in OpenJDK for enabling OpenGL (+Metal?) consistently across OS and hardwares via a unified API? II have seen an OpenGL example based on JEP-412 here [3]. I would be interested to assist on that topic and may help making Jzy3D compatible to such API. Jzy3D indeed offers a IPainter interface [4] that allows pluging multiple implementations of OpenGL for Java, hence helping to compare JOGL, EmulGL or any other OpenGL java API.
>>>>>>>
>>>>>>> Thanks in advance,
>>>>>>>
>>>>>>> Martin
>>>>>>>
>>>>>>> [1] https://urldefense.com/v3/http://jzy3d.org/;!!ACWV5N9M2RV99hQ!bD8kYg-yxOkAx3K51U-h3dQqyLInU20XCvH8O8KiyWJ-qrZS3rxRah14L9c_RhltGULw2_M$
>>>>>>>
>>>>>>> [2] https://urldefense.com/v3/https://github.com/jzy3d/jzy3d-api/tree/69a14166096a46bfb6e74cd3ab02e11d41c09024/jzy3d-emul-gl;!!ACWV5N9M2RV99hQ!bD8kYg-yxOkAx3K51U-h3dQqyLInU20XCvH8O8KiyWJ-qrZS3rxRah14L9c_Rhlt1e2WRMw$
>>>>>>>
>>>>>>> [3] https://urldefense.com/v3/https://github.com/sundararajana/panama-jextract-samples/tree/master/opengl;!!ACWV5N9M2RV99hQ!bD8kYg-yxOkAx3K51U-h3dQqyLInU20XCvH8O8KiyWJ-qrZS3rxRah14L9c_RhltTdkbjNo$
>>>>>>>
>>>>>>> [4] https://urldefense.com/v3/https://github.com/jzy3d/jzy3d-api/blob/69a14166096a46bfb6e74cd3ab02e11d41c09024/jzy3d-core/src/main/java/org/jzy3d/painters/IPainter.java;!!ACWV5N9M2RV99hQ!bD8kYg-yxOkAx3K51U-h3dQqyLInU20XCvH8O8KiyWJ-qrZS3rxRah14L9c_RhltwLuRJOg$

From martin.pernollet at protonmail.com  Tue Sep 21 17:38:13 2021
From: martin.pernollet at protonmail.com (Martin Pernollet)
Date: Tue, 21 Sep 2021 17:38:13 +0000
Subject: JEP-412 & OpenGL
In-Reply-To: <7e4389ad-1a15-d480-72af-e92c507ffe49@oracle.com>
References: 
 <44916ce4-1174-28d0-6cff-28ee6ac7b487@oracle.com>
 <91EE3A16-B5E3-4DAA-A299-6B332178B5A0@oracle.com>
 <20IAXMh_D5CwrlzRuub4xeEQVgsdy_SG-PGZ_mFzrEPcaCOUWu2_6lwXTxR10bHTJmUQW8Xaq0xnen8Fmp65kBkg3Nikf1y-h2zDL-80-lI=@protonmail.com>
 
 
 
 <7e4389ad-1a15-d480-72af-e92c507ffe49@oracle.com>
Message-ID: 

Hi,

Thanks for the jar option clarification.

Teapot [0] indeed imports opengl.glut_h.* but opengl.glut_h extends opengl.glut_h_3 (and cascading to h2 and then h1). All the GL primitives called by Teapot are methods defined in glut_h_*, e.g. as glShadeModel(). Does this look normal then?

[0] https://github.com/jzy3d/panama-gl/blob/main/src/main/java/Teapot.java can be nicely browsed on Github that provides an IDE like ability to navigate in code.



??????? Original Message ???????

Le mardi 21 septembre 2021 ? 18:42, Jorn Vernee  a ?crit :

> Hi Martin,
>
> Note that anything passed after the `-jar ` argument is a program
>
> argument, passing all the flags before `-jar` passes them as VM
>
> arguments, which is correct.
>
> The second error message you are getting is a bit puzzling. It seems
>
> that somehow your Teapot class is directly trying to access an internal
>
> binding class.
>
> Note that the generated bindings should be accessed through
>
> opengl.glut_h, which is public [1], instead of opengl.glut_h_3, which is
>
> package-private [2].
>
> HTH,
>
> Jorn
>
> [1] :
>
> https://github.com/jzy3d/panama-gl/blob/main/src/main/java/opengl/glut_h.java
>
> [2] :
>
> https://github.com/jzy3d/panama-gl/blob/main/src/main/java/opengl/glut_h_3.java
>
> On 21/09/2021 16:41, Martin Pernollet wrote:
>
> > Yes, I also added it at runtime as follow
> >
> > java -jar target/panama-gl-2.0.1-SNAPSHOT.jar -XstartOnFirstThread --enable-native-access=ALL-UNNAMED --add-modules jdk.incubator.foreign -Djava.library.path=.:/System/Library/Frameworks/OpenGL.framework/Versions/Current/Libraries/
> >
> > But the error was coming from the position of the -jar argument. I can go (just a little) further by putting the -jar argument at the end as follow
> >
> > java -XstartOnFirstThread --enable-native-access=ALL-UNNAMED --add-modules jdk.incubator.foreign -Djava.library.path=.:/System/Library/Frameworks/OpenGL.framework/Versions/Current/Libraries/ -jar target/panama-gl-2.0.1-SNAPSHOT.jar
> >
> > WARNING: Using incubator modules: jdk.incubator.foreign
> >
> > Exception in thread "main" java.lang.IllegalAccessError: failed to access class opengl.glut_h_3 from class Teapot (opengl.glut_h_3 and Teapot are in unnamed module of loader 'app')
> >
> > at Teapot.main(Teapot.java:80)
> >
> > Still have to learn a few things about modules :)
> >
> > Sent with ProtonMail Secure Email.
> >
> > ??????? Original Message ???????
> >
> > Le mardi 21 septembre 2021 ? 14:41, Maurizio Cimadamore maurizio.cimadamore at oracle.com a ?crit :
> >
> > > Hi Martin,
> > >
> > > I think the compilation setup looks correct. The question is how do you
> > >
> > > run the application? The --add-modules option has to be added both at
> > >
> > > compile-time (which you are doing) and at run-time.
> > >
> > > Maurizio
> > >
> > > On 21/09/2021 13:15, Martin Pernollet wrote:
> > >
> > > > Hi everyone,
> > > >
> > > > I followed the steps of the OpenGL tutorial and mentioned them here [1]. I got stuck with the below error when running the JAR - which I create with Maven + Shade plugin to later use Jzy3D and Panama together.
> > > >
> > > > Error: Unable to initialize main class Teapot
> > > >
> > > > Caused by: java.lang.NoClassDefFoundError: jdk/incubator/foreign/Addressable
> > > >
> > > > Do you have a suggestion for this? I already tried building by passing the --add-modules in three different ways :
> > > >
> > > > (1) mvn install -D--add-modules=jdk.incubator.foreign
> > > >
> > > > (2) mvn install --add-modules jdk.incubator.foreign
> > > >
> > > > (3) mvn install without arguments by relying on maven compiler plugin setup as follow
> > > >
> > > > 
> > > >
> > > > maven-compiler-plugin
> > > >
> > > > 2.3.2
> > > >
> > > > 
> > > >
> > > > 17
> > > >
> > > > 17
> > > >
> > > > UTF-8
> > > >
> > > > 
> > > >
> > > > --add-modules
> > > >
> > > > jdk.incubator.foreign
> > > >
> > > > --add-exports
> > > >
> > > > jdk.incubator.foreign
> > > >
> > > > 
> > > >
> > > > 
> > > >
> > > > 
> > > >
> > > > I'll gladly bundled the Q&A in the above readme for other developers.
> > > >
> > > > Thanks in advance,
> > > >
> > > > Martin
> > > >
> > > > [1] https://urldefense.com/v3/https://github.com/jzy3d/panama-gl;!!ACWV5N9M2RV99hQ!bD8kYg-yxOkAx3K51U-h3dQqyLInU20XCvH8O8KiyWJ-qrZS3rxRah14L9c_Rhlt8SNQYGs$
> > > >
> > > > [2] https://urldefense.com/v3/https://github.com/sundararajana/panama-jextract-samples/issues;!!ACWV5N9M2RV99hQ!bD8kYg-yxOkAx3K51U-h3dQqyLInU20XCvH8O8KiyWJ-qrZS3rxRah14L9c_Rhlt2ft10UE$
> > > >
> > > > Sent with ProtonMail Secure Email.
> > > >
> > > > ??????? Original Message ???????
> > > >
> > > > Le lundi 20 septembre 2021 ? 14:24, Martin Pernollet martin.pernollet at protonmail.com a ?crit :
> > > >
> > > > > Thank you all for your answers.
> > > > >
> > > > > I'll give a try in the coming weeks and will tell you how this works.
> > > > >
> > > > > Martin
> > > > >
> > > > > Sent with ProtonMail Secure Email.
> > > > >
> > > > > ??????? Original Message ???????
> > > > >
> > > > > Le samedi 18 septembre 2021 ? 12:56, John Rose john.r.rose at oracle.com a ?crit :
> > > > >
> > > > > > Actually the JOGL work is one of the old inspirations for Panama.
> > > > > >
> > > > > > The idea that we could use declarative schema information (instead of imperatives coded C wrappers) to transition between Java and native libraries is found in SWIG, JOGL, Panama, JNR, and many other places. (I did a tech. like that in the mid ?90s for a pre-Java VM.)
> > > > > >
> > > > > > That said, surely even a JNI code generation tool is worse than something that just runs out of a JAR or jshell session. Eventually, I hope, we will tease apart the aspects of JNI into a proper set of primitives that allows, but does not require, hand written or tool written JNI C code.
> > > > > >
> > > > > > The primitives I am thinking of these days are:
> > > > > >
> > > > > > Panama native lookup accesses nearly all native entry point.
> > > > > >
> > > > > > These are optimizable by the JIT and/or AOT to be equivalent with today?s ad hoc JVM native transition wrappers.
> > > > > >
> > > > > > And then, a way to program any native method not only via JNI but via an Indy-style bootstrap method. This would lazily generate the body of the native method (driven by declarative information, typically) to a Panama wrapper or some other thing.
> > > > > >
> > > > > > The endgame is that native methods are fully meta programmable, not losing any JNI use cases (because Panama), but adding other ones, with suitable BSMs.
> > > > > >
> > > > > > In a world where native methods have BMMs, a JAR file can contain thousands of method definitions and zero byte codes. Each method will be elaborated just in time by a declarative BSM recipe. An AOT compiler can generate the equivalent of JNI stubs if requested but it?s not needed because the (Panama based) runtime knows how to generate the stubs as early or as late as needed.
> > > > > >
> > > > > > JOGL can stay as it is until it is ready to retool into the more powerful framework.
> > > > > >
> > > > > > > On Sep 17, 2021, at 9:26 AM, Maurizio Cimadamore Maurizio.Cimadamore at oracle.com wrote:
> > > > > > >
> > > > > > > Hi Martin,
> > > > > > >
> > > > > > > We have no plans to drop support for JNI. JEP 412 offers a replacement which allows libraries to express bindings purely in Java code. In most cases, this is desirable, but I understand that frameworks written prior that JEP might have little to no appetite to rewrite everyting to use MethodHandle/VarHandle and/or jextract.
> > > > > > >
> > > > > > > As you noted, OpenGL works well with the new foreign APIs, and we have written various samples using OpenGL bindings generated by jextract.
> > > > > > >
> > > > > > > That said, it is beyond the goal of JEP 412 (and its succesors) to provide an uniform OpenGL API within the JDK - but I think the foreign APIs and the tools (jextract) are now reaching a level of maturity which would allow for such experiments to occur outside the JDK, and we'd be pleased to hear some feedback in the panama-dev mailing list!
> > > > > > >
> > > > > > > Hope this answers your question
> > > > > > >
> > > > > > > Maurizio
> > > > > > >
> > > > > > > > On 17/09/2021 12:54, Martin Pernollet wrote:
> > > > > > > >
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > I actively maintain Jzy3D [1], a framework for drawing 3D charts in Java. It uses JOGL which access native OpenGL with the help of GlueGen, a tool to generate JNI bindings. Jzy3D has an additional OpenGL pure Java CPU renderer [2] to circumvent compatibility limitations of JOGL, mainly for MacOS.
> > > > > > > >
> > > > > > > > Will JEP-412 close the doors to bindings relying on JNI? In other word will JOGL be able to continue working with GlueGen and JNI?
> > > > > > > >
> > > > > > > > Are there known plans in OpenJDK for enabling OpenGL (+Metal?) consistently across OS and hardwares via a unified API? II have seen an OpenGL example based on JEP-412 here [3]. I would be interested to assist on that topic and may help making Jzy3D compatible to such API. Jzy3D indeed offers a IPainter interface [4] that allows pluging multiple implementations of OpenGL for Java, hence helping to compare JOGL, EmulGL or any other OpenGL java API.
> > > > > > > >
> > > > > > > > Thanks in advance,
> > > > > > > >
> > > > > > > > Martin
> > > > > > > >
> > > > > > > > [1] https://urldefense.com/v3/http://jzy3d.org/;!!ACWV5N9M2RV99hQ!bD8kYg-yxOkAx3K51U-h3dQqyLInU20XCvH8O8KiyWJ-qrZS3rxRah14L9c_RhltGULw2_M$
> > > > > > > >
> > > > > > > > [2] https://urldefense.com/v3/https://github.com/jzy3d/jzy3d-api/tree/69a14166096a46bfb6e74cd3ab02e11d41c09024/jzy3d-emul-gl;!!ACWV5N9M2RV99hQ!bD8kYg-yxOkAx3K51U-h3dQqyLInU20XCvH8O8KiyWJ-qrZS3rxRah14L9c_Rhlt1e2WRMw$
> > > > > > > >
> > > > > > > > [3] https://urldefense.com/v3/https://github.com/sundararajana/panama-jextract-samples/tree/master/opengl;!!ACWV5N9M2RV99hQ!bD8kYg-yxOkAx3K51U-h3dQqyLInU20XCvH8O8KiyWJ-qrZS3rxRah14L9c_RhltTdkbjNo$
> > > > > > > >
> > > > > > > > [4] https://urldefense.com/v3/https://github.com/jzy3d/jzy3d-api/blob/69a14166096a46bfb6e74cd3ab02e11d41c09024/jzy3d-core/src/main/java/org/jzy3d/painters/IPainter.java;!!ACWV5N9M2RV99hQ!bD8kYg-yxOkAx3K51U-h3dQqyLInU20XCvH8O8KiyWJ-qrZS3rxRah14L9c_RhltwLuRJOg$

From maurizio.cimadamore at oracle.com  Tue Sep 21 17:50:25 2021
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 21 Sep 2021 18:50:25 +0100
Subject: JEP-412 & OpenGL
In-Reply-To: 
References: 
 <44916ce4-1174-28d0-6cff-28ee6ac7b487@oracle.com>
 <91EE3A16-B5E3-4DAA-A299-6B332178B5A0@oracle.com>
 <20IAXMh_D5CwrlzRuub4xeEQVgsdy_SG-PGZ_mFzrEPcaCOUWu2_6lwXTxR10bHTJmUQW8Xaq0xnen8Fmp65kBkg3Nikf1y-h2zDL-80-lI=@protonmail.com>
 
 
 
 <7e4389ad-1a15-d480-72af-e92c507ffe49@oracle.com>
 
Message-ID: 


On 21/09/2021 18:38, Martin Pernollet wrote:
> Hi,
>
> Thanks for the jar option clarification.
>
> Teapot [0] indeed imports opengl.glut_h.* but opengl.glut_h extends opengl.glut_h_3 (and cascading to h2 and then h1). All the GL primitives called by Teapot are methods defined in glut_h_*, e.g. as glShadeModel(). Does this look normal then?

This is normal.

Btw, I tried your build script, and the only way for me to make it work 
was to update the compiler plugin to a more recent version (3.8.1). 
After that, it installed correctly, and your launcher command line 
displayed the dear opengl pot :-)

Maurizio

>
> [0] https://urldefense.com/v3/__https://github.com/jzy3d/panama-gl/blob/main/src/main/java/Teapot.java__;!!ACWV5N9M2RV99hQ!fY9N1h6iHmy-0_pM6R44m56wO4D3kXkp-aE_ARyGv4xQBeJCdOsvvSqvH7ive-TAgsYRXl0$  can be nicely browsed on Github that provides an IDE like ability to navigate in code.
>
>
>
> ??????? Original Message ???????
>
> Le mardi 21 septembre 2021 ? 18:42, Jorn Vernee  a ?crit :
>
>> Hi Martin,
>>
>> Note that anything passed after the `-jar ` argument is a program
>>
>> argument, passing all the flags before `-jar` passes them as VM
>>
>> arguments, which is correct.
>>
>> The second error message you are getting is a bit puzzling. It seems
>>
>> that somehow your Teapot class is directly trying to access an internal
>>
>> binding class.
>>
>> Note that the generated bindings should be accessed through
>>
>> opengl.glut_h, which is public [1], instead of opengl.glut_h_3, which is
>>
>> package-private [2].
>>
>> HTH,
>>
>> Jorn
>>
>> [1] :
>>
>> https://urldefense.com/v3/__https://github.com/jzy3d/panama-gl/blob/main/src/main/java/opengl/glut_h.java__;!!ACWV5N9M2RV99hQ!fY9N1h6iHmy-0_pM6R44m56wO4D3kXkp-aE_ARyGv4xQBeJCdOsvvSqvH7ive-TA4zEEkdU$
>>
>> [2] :
>>
>> https://urldefense.com/v3/__https://github.com/jzy3d/panama-gl/blob/main/src/main/java/opengl/glut_h_3.java__;!!ACWV5N9M2RV99hQ!fY9N1h6iHmy-0_pM6R44m56wO4D3kXkp-aE_ARyGv4xQBeJCdOsvvSqvH7ive-TAUBj4EaU$
>>
>> On 21/09/2021 16:41, Martin Pernollet wrote:
>>
>>> Yes, I also added it at runtime as follow
>>>
>>> java -jar target/panama-gl-2.0.1-SNAPSHOT.jar -XstartOnFirstThread --enable-native-access=ALL-UNNAMED --add-modules jdk.incubator.foreign -Djava.library.path=.:/System/Library/Frameworks/OpenGL.framework/Versions/Current/Libraries/
>>>
>>> But the error was coming from the position of the -jar argument. I can go (just a little) further by putting the -jar argument at the end as follow
>>>
>>> java -XstartOnFirstThread --enable-native-access=ALL-UNNAMED --add-modules jdk.incubator.foreign -Djava.library.path=.:/System/Library/Frameworks/OpenGL.framework/Versions/Current/Libraries/ -jar target/panama-gl-2.0.1-SNAPSHOT.jar
>>>
>>> WARNING: Using incubator modules: jdk.incubator.foreign
>>>
>>> Exception in thread "main" java.lang.IllegalAccessError: failed to access class opengl.glut_h_3 from class Teapot (opengl.glut_h_3 and Teapot are in unnamed module of loader 'app')
>>>
>>> at Teapot.main(Teapot.java:80)
>>>
>>> Still have to learn a few things about modules :)
>>>
>>> Sent with ProtonMail Secure Email.
>>>
>>> ??????? Original Message ???????
>>>
>>> Le mardi 21 septembre 2021 ? 14:41, Maurizio Cimadamore maurizio.cimadamore at oracle.com a ?crit :
>>>
>>>> Hi Martin,
>>>>
>>>> I think the compilation setup looks correct. The question is how do you
>>>>
>>>> run the application? The --add-modules option has to be added both at
>>>>
>>>> compile-time (which you are doing) and at run-time.
>>>>
>>>> Maurizio
>>>>
>>>> On 21/09/2021 13:15, Martin Pernollet wrote:
>>>>
>>>>> Hi everyone,
>>>>>
>>>>> I followed the steps of the OpenGL tutorial and mentioned them here [1]. I got stuck with the below error when running the JAR - which I create with Maven + Shade plugin to later use Jzy3D and Panama together.
>>>>>
>>>>> Error: Unable to initialize main class Teapot
>>>>>
>>>>> Caused by: java.lang.NoClassDefFoundError: jdk/incubator/foreign/Addressable
>>>>>
>>>>> Do you have a suggestion for this? I already tried building by passing the --add-modules in three different ways :
>>>>>
>>>>> (1) mvn install -D--add-modules=jdk.incubator.foreign
>>>>>
>>>>> (2) mvn install --add-modules jdk.incubator.foreign
>>>>>
>>>>> (3) mvn install without arguments by relying on maven compiler plugin setup as follow
>>>>>
>>>>> 
>>>>>
>>>>> maven-compiler-plugin
>>>>>
>>>>> 2.3.2
>>>>>
>>>>> 
>>>>>
>>>>> 17
>>>>>
>>>>> 17
>>>>>
>>>>> UTF-8
>>>>>
>>>>> 
>>>>>
>>>>> --add-modules
>>>>>
>>>>> jdk.incubator.foreign
>>>>>
>>>>> --add-exports
>>>>>
>>>>> jdk.incubator.foreign
>>>>>
>>>>> 
>>>>>
>>>>> 
>>>>>
>>>>> 
>>>>>
>>>>> I'll gladly bundled the Q&A in the above readme for other developers.
>>>>>
>>>>> Thanks in advance,
>>>>>
>>>>> Martin
>>>>>
>>>>> [1] https://urldefense.com/v3/https://github.com/jzy3d/panama-gl;!!ACWV5N9M2RV99hQ!bD8kYg-yxOkAx3K51U-h3dQqyLInU20XCvH8O8KiyWJ-qrZS3rxRah14L9c_Rhlt8SNQYGs$
>>>>>
>>>>> [2] https://urldefense.com/v3/https://github.com/sundararajana/panama-jextract-samples/issues;!!ACWV5N9M2RV99hQ!bD8kYg-yxOkAx3K51U-h3dQqyLInU20XCvH8O8KiyWJ-qrZS3rxRah14L9c_Rhlt2ft10UE$
>>>>>
>>>>> Sent with ProtonMail Secure Email.
>>>>>
>>>>> ??????? Original Message ???????
>>>>>
>>>>> Le lundi 20 septembre 2021 ? 14:24, Martin Pernollet martin.pernollet at protonmail.com a ?crit :
>>>>>
>>>>>> Thank you all for your answers.
>>>>>>
>>>>>> I'll give a try in the coming weeks and will tell you how this works.
>>>>>>
>>>>>> Martin
>>>>>>
>>>>>> Sent with ProtonMail Secure Email.
>>>>>>
>>>>>> ??????? Original Message ???????
>>>>>>
>>>>>> Le samedi 18 septembre 2021 ? 12:56, John Rose john.r.rose at oracle.com a ?crit :
>>>>>>
>>>>>>> Actually the JOGL work is one of the old inspirations for Panama.
>>>>>>>
>>>>>>> The idea that we could use declarative schema information (instead of imperatives coded C wrappers) to transition between Java and native libraries is found in SWIG, JOGL, Panama, JNR, and many other places. (I did a tech. like that in the mid ?90s for a pre-Java VM.)
>>>>>>>
>>>>>>> That said, surely even a JNI code generation tool is worse than something that just runs out of a JAR or jshell session. Eventually, I hope, we will tease apart the aspects of JNI into a proper set of primitives that allows, but does not require, hand written or tool written JNI C code.
>>>>>>>
>>>>>>> The primitives I am thinking of these days are:
>>>>>>>
>>>>>>> Panama native lookup accesses nearly all native entry point.
>>>>>>>
>>>>>>> These are optimizable by the JIT and/or AOT to be equivalent with today?s ad hoc JVM native transition wrappers.
>>>>>>>
>>>>>>> And then, a way to program any native method not only via JNI but via an Indy-style bootstrap method. This would lazily generate the body of the native method (driven by declarative information, typically) to a Panama wrapper or some other thing.
>>>>>>>
>>>>>>> The endgame is that native methods are fully meta programmable, not losing any JNI use cases (because Panama), but adding other ones, with suitable BSMs.
>>>>>>>
>>>>>>> In a world where native methods have BMMs, a JAR file can contain thousands of method definitions and zero byte codes. Each method will be elaborated just in time by a declarative BSM recipe. An AOT compiler can generate the equivalent of JNI stubs if requested but it?s not needed because the (Panama based) runtime knows how to generate the stubs as early or as late as needed.
>>>>>>>
>>>>>>> JOGL can stay as it is until it is ready to retool into the more powerful framework.
>>>>>>>
>>>>>>>> On Sep 17, 2021, at 9:26 AM, Maurizio Cimadamore Maurizio.Cimadamore at oracle.com wrote:
>>>>>>>>
>>>>>>>> Hi Martin,
>>>>>>>>
>>>>>>>> We have no plans to drop support for JNI. JEP 412 offers a replacement which allows libraries to express bindings purely in Java code. In most cases, this is desirable, but I understand that frameworks written prior that JEP might have little to no appetite to rewrite everyting to use MethodHandle/VarHandle and/or jextract.
>>>>>>>>
>>>>>>>> As you noted, OpenGL works well with the new foreign APIs, and we have written various samples using OpenGL bindings generated by jextract.
>>>>>>>>
>>>>>>>> That said, it is beyond the goal of JEP 412 (and its succesors) to provide an uniform OpenGL API within the JDK - but I think the foreign APIs and the tools (jextract) are now reaching a level of maturity which would allow for such experiments to occur outside the JDK, and we'd be pleased to hear some feedback in the panama-dev mailing list!
>>>>>>>>
>>>>>>>> Hope this answers your question
>>>>>>>>
>>>>>>>> Maurizio
>>>>>>>>
>>>>>>>>> On 17/09/2021 12:54, Martin Pernollet wrote:
>>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I actively maintain Jzy3D [1], a framework for drawing 3D charts in Java. It uses JOGL which access native OpenGL with the help of GlueGen, a tool to generate JNI bindings. Jzy3D has an additional OpenGL pure Java CPU renderer [2] to circumvent compatibility limitations of JOGL, mainly for MacOS.
>>>>>>>>>
>>>>>>>>> Will JEP-412 close the doors to bindings relying on JNI? In other word will JOGL be able to continue working with GlueGen and JNI?
>>>>>>>>>
>>>>>>>>> Are there known plans in OpenJDK for enabling OpenGL (+Metal?) consistently across OS and hardwares via a unified API? II have seen an OpenGL example based on JEP-412 here [3]. I would be interested to assist on that topic and may help making Jzy3D compatible to such API. Jzy3D indeed offers a IPainter interface [4] that allows pluging multiple implementations of OpenGL for Java, hence helping to compare JOGL, EmulGL or any other OpenGL java API.
>>>>>>>>>
>>>>>>>>> Thanks in advance,
>>>>>>>>>
>>>>>>>>> Martin
>>>>>>>>>
>>>>>>>>> [1] https://urldefense.com/v3/http://jzy3d.org/;!!ACWV5N9M2RV99hQ!bD8kYg-yxOkAx3K51U-h3dQqyLInU20XCvH8O8KiyWJ-qrZS3rxRah14L9c_RhltGULw2_M$
>>>>>>>>>
>>>>>>>>> [2] https://urldefense.com/v3/https://github.com/jzy3d/jzy3d-api/tree/69a14166096a46bfb6e74cd3ab02e11d41c09024/jzy3d-emul-gl;!!ACWV5N9M2RV99hQ!bD8kYg-yxOkAx3K51U-h3dQqyLInU20XCvH8O8KiyWJ-qrZS3rxRah14L9c_Rhlt1e2WRMw$
>>>>>>>>>
>>>>>>>>> [3] https://urldefense.com/v3/https://github.com/sundararajana/panama-jextract-samples/tree/master/opengl;!!ACWV5N9M2RV99hQ!bD8kYg-yxOkAx3K51U-h3dQqyLInU20XCvH8O8KiyWJ-qrZS3rxRah14L9c_RhltTdkbjNo$
>>>>>>>>>
>>>>>>>>> [4] https://urldefense.com/v3/https://github.com/jzy3d/jzy3d-api/blob/69a14166096a46bfb6e74cd3ab02e11d41c09024/jzy3d-core/src/main/java/org/jzy3d/painters/IPainter.java;!!ACWV5N9M2RV99hQ!bD8kYg-yxOkAx3K51U-h3dQqyLInU20XCvH8O8KiyWJ-qrZS3rxRah14L9c_RhltwLuRJOg$

From jorn.vernee at oracle.com  Tue Sep 21 17:50:42 2021
From: jorn.vernee at oracle.com (Jorn Vernee)
Date: Tue, 21 Sep 2021 19:50:42 +0200
Subject: [External] : Re: JEP-412 & OpenGL
In-Reply-To: 
References: 
 <44916ce4-1174-28d0-6cff-28ee6ac7b487@oracle.com>
 <91EE3A16-B5E3-4DAA-A299-6B332178B5A0@oracle.com>
 <20IAXMh_D5CwrlzRuub4xeEQVgsdy_SG-PGZ_mFzrEPcaCOUWu2_6lwXTxR10bHTJmUQW8Xaq0xnen8Fmp65kBkg3Nikf1y-h2zDL-80-lI=@protonmail.com>
 
 
 
 <7e4389ad-1a15-d480-72af-e92c507ffe49@oracle.com>
 
Message-ID: <49b0129b-7a26-e520-4d63-72ef402756e0@oracle.com>

Hi,

Your source code looks correct to me.

I've tried out the project here as well, and the only two changes I had 
to make to make it work were changing the compiler plugin to version 
3.8.1 (it seems like the latest version was not picking up the 
`--add-modules` flag). I then have this in the pom.xml:

```
 ??? ??? ??? 
maven-compiler-plugin
 ??? ??? ??? ??? 3.8.1
 ??? ??? ??? ??? 
 ??? ??? ??? ??? ??? 17
 ??? ??? ??? ??? ??? 17
 ??? ??? ??? ??? ??? UTF-8
 ??? ??? ??? ??? ??? 
--add-modules=jdk.incubator.foreign
 ??? ??? ??? ??? ??? 
 ??? ??? ??? ??? 
 ??? ??? ??? 
```

(Everything else still the same),

And after running `mvn clean package` I can run the program with:

```
 > java '-Djava.library.path='? 
--enable-native-access=ALL-UNNAMED --add-modules jdk.incubator.foreign 
-jar .\target\panama-gl-2.0.1-SNAPSHOT.jar
```

(Just had to fix a minor issue in Teapot since I'm using freeglut, but 
that shouldn't matter for you). This displays the teapot for me.

So the only thing I can suggest at this point is to update the version 
of your maven-compile-plugin

HTH,
Jorn

On 21/09/2021 19:38, Martin Pernollet wrote:
> Hi,
>
> Thanks for the jar option clarification.
>
> Teapot [0] indeed imports opengl.glut_h.* but opengl.glut_h extends opengl.glut_h_3 (and cascading to h2 and then h1). All the GL primitives called by Teapot are methods defined in glut_h_*, e.g. as glShadeModel(). Does this look normal then?
>
> [0] https://urldefense.com/v3/__https://github.com/jzy3d/panama-gl/blob/main/src/main/java/Teapot.java__;!!ACWV5N9M2RV99hQ!cIN_fFK3UfVQgbhYOhe8V6GNsyy446g9Y7ulr2-sfBr_mwelkQVbDsJh8NPDlt7v$  can be nicely browsed on Github that provides an IDE like ability to navigate in code.
>
>
>
> ??????? Original Message ???????
>
> Le mardi 21 septembre 2021 ? 18:42, Jorn Vernee  a ?crit :
>
>> Hi Martin,
>>
>> Note that anything passed after the `-jar ` argument is a program
>>
>> argument, passing all the flags before `-jar` passes them as VM
>>
>> arguments, which is correct.
>>
>> The second error message you are getting is a bit puzzling. It seems
>>
>> that somehow your Teapot class is directly trying to access an internal
>>
>> binding class.
>>
>> Note that the generated bindings should be accessed through
>>
>> opengl.glut_h, which is public [1], instead of opengl.glut_h_3, which is
>>
>> package-private [2].
>>
>> HTH,
>>
>> Jorn
>>
>> [1] :
>>
>> https://urldefense.com/v3/__https://github.com/jzy3d/panama-gl/blob/main/src/main/java/opengl/glut_h.java__;!!ACWV5N9M2RV99hQ!cIN_fFK3UfVQgbhYOhe8V6GNsyy446g9Y7ulr2-sfBr_mwelkQVbDsJh8NGhSAfu$
>>
>> [2] :
>>
>> https://urldefense.com/v3/__https://github.com/jzy3d/panama-gl/blob/main/src/main/java/opengl/glut_h_3.java__;!!ACWV5N9M2RV99hQ!cIN_fFK3UfVQgbhYOhe8V6GNsyy446g9Y7ulr2-sfBr_mwelkQVbDsJh8G52B9OM$
>>
>> On 21/09/2021 16:41, Martin Pernollet wrote:
>>
>>> Yes, I also added it at runtime as follow
>>>
>>> java -jar target/panama-gl-2.0.1-SNAPSHOT.jar -XstartOnFirstThread --enable-native-access=ALL-UNNAMED --add-modules jdk.incubator.foreign -Djava.library.path=.:/System/Library/Frameworks/OpenGL.framework/Versions/Current/Libraries/
>>>
>>> But the error was coming from the position of the -jar argument. I can go (just a little) further by putting the -jar argument at the end as follow
>>>
>>> java -XstartOnFirstThread --enable-native-access=ALL-UNNAMED --add-modules jdk.incubator.foreign -Djava.library.path=.:/System/Library/Frameworks/OpenGL.framework/Versions/Current/Libraries/ -jar target/panama-gl-2.0.1-SNAPSHOT.jar
>>>
>>> WARNING: Using incubator modules: jdk.incubator.foreign
>>>
>>> Exception in thread "main" java.lang.IllegalAccessError: failed to access class opengl.glut_h_3 from class Teapot (opengl.glut_h_3 and Teapot are in unnamed module of loader 'app')
>>>
>>> at Teapot.main(Teapot.java:80)
>>>
>>> Still have to learn a few things about modules :)
>>>
>>> Sent with ProtonMail Secure Email.
>>>
>>> ??????? Original Message ???????
>>>
>>> Le mardi 21 septembre 2021 ? 14:41, Maurizio Cimadamore maurizio.cimadamore at oracle.com a ?crit :
>>>
>>>> Hi Martin,
>>>>
>>>> I think the compilation setup looks correct. The question is how do you
>>>>
>>>> run the application? The --add-modules option has to be added both at
>>>>
>>>> compile-time (which you are doing) and at run-time.
>>>>
>>>> Maurizio
>>>>
>>>> On 21/09/2021 13:15, Martin Pernollet wrote:
>>>>
>>>>> Hi everyone,
>>>>>
>>>>> I followed the steps of the OpenGL tutorial and mentioned them here [1]. I got stuck with the below error when running the JAR - which I create with Maven + Shade plugin to later use Jzy3D and Panama together.
>>>>>
>>>>> Error: Unable to initialize main class Teapot
>>>>>
>>>>> Caused by: java.lang.NoClassDefFoundError: jdk/incubator/foreign/Addressable
>>>>>
>>>>> Do you have a suggestion for this? I already tried building by passing the --add-modules in three different ways :
>>>>>
>>>>> (1) mvn install -D--add-modules=jdk.incubator.foreign
>>>>>
>>>>> (2) mvn install --add-modules jdk.incubator.foreign
>>>>>
>>>>> (3) mvn install without arguments by relying on maven compiler plugin setup as follow
>>>>>
>>>>> 
>>>>>
>>>>> maven-compiler-plugin
>>>>>
>>>>> 2.3.2
>>>>>
>>>>> 
>>>>>
>>>>> 17
>>>>>
>>>>> 17
>>>>>
>>>>> UTF-8
>>>>>
>>>>> 
>>>>>
>>>>> --add-modules
>>>>>
>>>>> jdk.incubator.foreign
>>>>>
>>>>> --add-exports
>>>>>
>>>>> jdk.incubator.foreign
>>>>>
>>>>> 
>>>>>
>>>>> 
>>>>>
>>>>> 
>>>>>
>>>>> I'll gladly bundled the Q&A in the above readme for other developers.
>>>>>
>>>>> Thanks in advance,
>>>>>
>>>>> Martin
>>>>>
>>>>> [1] https://urldefense.com/v3/https://github.com/jzy3d/panama-gl;!!ACWV5N9M2RV99hQ!bD8kYg-yxOkAx3K51U-h3dQqyLInU20XCvH8O8KiyWJ-qrZS3rxRah14L9c_Rhlt8SNQYGs$
>>>>>
>>>>> [2] https://urldefense.com/v3/https://github.com/sundararajana/panama-jextract-samples/issues;!!ACWV5N9M2RV99hQ!bD8kYg-yxOkAx3K51U-h3dQqyLInU20XCvH8O8KiyWJ-qrZS3rxRah14L9c_Rhlt2ft10UE$
>>>>>
>>>>> Sent with ProtonMail Secure Email.
>>>>>
>>>>> ??????? Original Message ???????
>>>>>
>>>>> Le lundi 20 septembre 2021 ? 14:24, Martin Pernollet martin.pernollet at protonmail.com a ?crit :
>>>>>
>>>>>> Thank you all for your answers.
>>>>>>
>>>>>> I'll give a try in the coming weeks and will tell you how this works.
>>>>>>
>>>>>> Martin
>>>>>>
>>>>>> Sent with ProtonMail Secure Email.
>>>>>>
>>>>>> ??????? Original Message ???????
>>>>>>
>>>>>> Le samedi 18 septembre 2021 ? 12:56, John Rose john.r.rose at oracle.com a ?crit :
>>>>>>
>>>>>>> Actually the JOGL work is one of the old inspirations for Panama.
>>>>>>>
>>>>>>> The idea that we could use declarative schema information (instead of imperatives coded C wrappers) to transition between Java and native libraries is found in SWIG, JOGL, Panama, JNR, and many other places. (I did a tech. like that in the mid ?90s for a pre-Java VM.)
>>>>>>>
>>>>>>> That said, surely even a JNI code generation tool is worse than something that just runs out of a JAR or jshell session. Eventually, I hope, we will tease apart the aspects of JNI into a proper set of primitives that allows, but does not require, hand written or tool written JNI C code.
>>>>>>>
>>>>>>> The primitives I am thinking of these days are:
>>>>>>>
>>>>>>> Panama native lookup accesses nearly all native entry point.
>>>>>>>
>>>>>>> These are optimizable by the JIT and/or AOT to be equivalent with today?s ad hoc JVM native transition wrappers.
>>>>>>>
>>>>>>> And then, a way to program any native method not only via JNI but via an Indy-style bootstrap method. This would lazily generate the body of the native method (driven by declarative information, typically) to a Panama wrapper or some other thing.
>>>>>>>
>>>>>>> The endgame is that native methods are fully meta programmable, not losing any JNI use cases (because Panama), but adding other ones, with suitable BSMs.
>>>>>>>
>>>>>>> In a world where native methods have BMMs, a JAR file can contain thousands of method definitions and zero byte codes. Each method will be elaborated just in time by a declarative BSM recipe. An AOT compiler can generate the equivalent of JNI stubs if requested but it?s not needed because the (Panama based) runtime knows how to generate the stubs as early or as late as needed.
>>>>>>>
>>>>>>> JOGL can stay as it is until it is ready to retool into the more powerful framework.
>>>>>>>
>>>>>>>> On Sep 17, 2021, at 9:26 AM, Maurizio Cimadamore Maurizio.Cimadamore at oracle.com wrote:
>>>>>>>>
>>>>>>>> Hi Martin,
>>>>>>>>
>>>>>>>> We have no plans to drop support for JNI. JEP 412 offers a replacement which allows libraries to express bindings purely in Java code. In most cases, this is desirable, but I understand that frameworks written prior that JEP might have little to no appetite to rewrite everyting to use MethodHandle/VarHandle and/or jextract.
>>>>>>>>
>>>>>>>> As you noted, OpenGL works well with the new foreign APIs, and we have written various samples using OpenGL bindings generated by jextract.
>>>>>>>>
>>>>>>>> That said, it is beyond the goal of JEP 412 (and its succesors) to provide an uniform OpenGL API within the JDK - but I think the foreign APIs and the tools (jextract) are now reaching a level of maturity which would allow for such experiments to occur outside the JDK, and we'd be pleased to hear some feedback in the panama-dev mailing list!
>>>>>>>>
>>>>>>>> Hope this answers your question
>>>>>>>>
>>>>>>>> Maurizio
>>>>>>>>
>>>>>>>>> On 17/09/2021 12:54, Martin Pernollet wrote:
>>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I actively maintain Jzy3D [1], a framework for drawing 3D charts in Java. It uses JOGL which access native OpenGL with the help of GlueGen, a tool to generate JNI bindings. Jzy3D has an additional OpenGL pure Java CPU renderer [2] to circumvent compatibility limitations of JOGL, mainly for MacOS.
>>>>>>>>>
>>>>>>>>> Will JEP-412 close the doors to bindings relying on JNI? In other word will JOGL be able to continue working with GlueGen and JNI?
>>>>>>>>>
>>>>>>>>> Are there known plans in OpenJDK for enabling OpenGL (+Metal?) consistently across OS and hardwares via a unified API? II have seen an OpenGL example based on JEP-412 here [3]. I would be interested to assist on that topic and may help making Jzy3D compatible to such API. Jzy3D indeed offers a IPainter interface [4] that allows pluging multiple implementations of OpenGL for Java, hence helping to compare JOGL, EmulGL or any other OpenGL java API.
>>>>>>>>>
>>>>>>>>> Thanks in advance,
>>>>>>>>>
>>>>>>>>> Martin
>>>>>>>>>
>>>>>>>>> [1] https://urldefense.com/v3/http://jzy3d.org/;!!ACWV5N9M2RV99hQ!bD8kYg-yxOkAx3K51U-h3dQqyLInU20XCvH8O8KiyWJ-qrZS3rxRah14L9c_RhltGULw2_M$
>>>>>>>>>
>>>>>>>>> [2] https://urldefense.com/v3/https://github.com/jzy3d/jzy3d-api/tree/69a14166096a46bfb6e74cd3ab02e11d41c09024/jzy3d-emul-gl;!!ACWV5N9M2RV99hQ!bD8kYg-yxOkAx3K51U-h3dQqyLInU20XCvH8O8KiyWJ-qrZS3rxRah14L9c_Rhlt1e2WRMw$
>>>>>>>>>
>>>>>>>>> [3] https://urldefense.com/v3/https://github.com/sundararajana/panama-jextract-samples/tree/master/opengl;!!ACWV5N9M2RV99hQ!bD8kYg-yxOkAx3K51U-h3dQqyLInU20XCvH8O8KiyWJ-qrZS3rxRah14L9c_RhltTdkbjNo$
>>>>>>>>>
>>>>>>>>> [4] https://urldefense.com/v3/https://github.com/jzy3d/jzy3d-api/blob/69a14166096a46bfb6e74cd3ab02e11d41c09024/jzy3d-core/src/main/java/org/jzy3d/painters/IPainter.java;!!ACWV5N9M2RV99hQ!bD8kYg-yxOkAx3K51U-h3dQqyLInU20XCvH8O8KiyWJ-qrZS3rxRah14L9c_RhltwLuRJOg$

From maurizio.cimadamore at oracle.com  Tue Sep 21 18:11:34 2021
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 21 Sep 2021 19:11:34 +0100
Subject: Will we need to use the --enable-native-access option to enable
 JNI in the future?
In-Reply-To: 
References: 
 
 
 
 
 <18b80809-54b1-1b40-e5f2-a2b1a4e10711@oracle.com>
 
 <2eb43d4c-6eee-39f7-877b-d98681773520@oracle.com>
 
Message-ID: <0eb894b2-0de7-d0bc-dc4d-298126e3726b@oracle.com>

Summarizing, you have what we could call an "application".

You have a launcher for it in some platforms, and on other platforms you 
don't.

Of course, where there's a launcher it is trivial (albeit maybe tedious) 
to add the required options depending on the java version.

Without the launcher you are constrained by what can be expressed in the 
manifest of the jarfile - which at the moment is "not a lot" :-)


With respect to bundling JRE, I think modularization has helped a lot 
there. You can create an image (using jlink) that only contains the 
modules you want - and then, use jpackage to generate a small executable 
out of that. We tried this approach to create a standalone jextract 
tool, and I have to say it worked really well - the size is very compact 
(as most of the JDK modules are dropped), to the point that the size of 
the standalone app tracks closely that of the native library it depends 
on (libclang). I hope many more projects decide to do things this way, 
because, IMHO, it just a much saner way to package up things and 
dependencies.


I really do think that modules are the right boundaries to enforce 
restrictions.

I concede that, given the current situation, if the option was called 
--enable-restricted-access instead of --enable-native-access that might 
be perceived as less of a "lie".

Maurizio



On 21/09/2021 17:09, Glavo wrote:
>
>     I think this is the real important point here. I'd like to understand
>     more about this use case. Do you have an executable AND multi-release
>     JAR? Is it an application that you are developing? Do you want that
>     application to be just executed using `java -jar foo.jar`? Does your
>     application have a launcher to trigger the `java -jar` command?
>
>
> Yes, even more than one of my programs are looking forward to introducing
> Panama to improve some corner features, even if they don't use native
> methods at present: Although using native access can improve the user
> experience, it is not necessary. If JNI is introduced, the build and
> testing process will be extremely complex, and it is difficult to support
> some niche platforms (e.g. Linux MIPS64el). JNA or JNR will significantly
> expand the size of small programs. I expect to use Panama as an 
> alternative
> to JNA to implement some optional functions, enable it on Java 21, and
> gracefully fallback in earlier versions.
>
>
> Using a more specific example, there is a JavaFX GUI application that
> I am involved in developing. It's a popular program. We have more than
> *one hundred thousand users*. This is a program for ordinary users. Most
> of them are not developers.
>
> It is always distributed as a fatJar (~3.6MB) and is expected to be
> out of the box except (Only need Java environment). In order to make it
> out of the box, it will automatically download OpenJFX at runtime and
> put it into module path by dirty way (Use BuiltinClassLoader::loadModule).
>
> It has a launcher, but not always available. We splice an exe in front
> of the contents of the jar file (It is still a JAR, which is allowed
> by the ZIP format). The launcher will look for java.exe in several
> places and start the program with CreateProcess. However, our program
> is cross platform, and there are many users who do not use Windows,
> and our launcher is only effective on the Windows platform.
> On other platforms, we simply distribute the fatJar. Fortunately, it
> works well because the double-click action of jar on the Mac OS is
> open it with java -jar. For Linux users, the most common usage is to
> start it with java -jar. Moreover, many of our windows users will use
> jar instead of exe version, because the double-click action of jar will
> also be associated when installing JRE, so they often do not need to
> rely on launcher.
>
> We have no plans to provide launchers on platforms other than windows,
> We won't give up Java 8 for a long time (maybe before 2031, but maybe
> later). Bundling JRE and distributing it is absolutely unacceptable.
> It will expand our application distribution by more than seven times,
> and expand the volume after decompression by more than 20 times!
> It is acceptable for us to recommend users to install Java by themselves,
> because the program is related to minecraft, and users always need a
> JRE. We want to keep the form of distributing a single jar. Being clean
> and portable software is one of its selling points.
>
>     For the record, I don't despise all code at all -
>     but I also think that the position of "must be run with a clean `java
>     -jar`, no extra arguments" is (while a good goal) a bit unrealistic.
>     Most of the real world Java application I've seen all need to drop in
>     some extra command line option (e.g. -Xmx), but I think your problem
>     here is more specific than "just add a command line option" - the
>     problem is adding an option that is only supported on _some_ JDKs (see
>     below).
>
>
> I don't think this is unrealistic. Java's default options are good
> enough for most small programs, and I have noticed that Java has been
> improving out of box availability. I believe that Java's default options
> will be good enough for most client applications in the future.
>
>     Please walk me through your use case a bit, and please let's keep the
>     conversation focussed - arguing over general safety principles is not
>     very helpful, when the real problem is, I suspect, driven by something
>     much more concrete.
>
> I know you have your point of view, and I don't want to keep pestering
> on it. But I want to remind you one last time: This option is currently
> very confusing to users, at least the name is problematic. At present,
> it cannot restrict native access, but it implies that it has this
> ability. This is a security risk. I insist that for the time being,
> Panama should not force the check of native access execution by default.
> It needs to prepare the security mechanism and remind the user to use
> it, but it should not start to execute by default until it is ready
> to restrict JNI (and deprecated sun.misc.Unsafe).
>
> Of course, real-world safety problems often come from dynamically
> loaded code, but it also reduces the value of this option. I hope that
> Panama will pay more attention to dynamic safety management rather
> than static safety.
>
>
> Here I would like to add another question:
> Is it too coarse-grained to always manage native access permissions
> based on modules? This seems appropriate for a binding library or a
> library that often uses foreign memory. However, for some modules with
> only a few methods that require native access, can't I grant temporary
> permissions? Just like:
>
> doWithNativeAccess(() -> {
> someUnsafeMethod(); // ok
> ? });
> someUnsafeMethod(); // IllegalCallerException
>
> Maurizio Cimadamore  > ?2021?9?21??? 
> ??6:20???
>
>     I'll zoom in on this issue, because I think it's the one we need to
>     understand the most. For the record, I don't despise all code at
>     all -
>     but I also think that the position of "must be run with a clean `java
>     -jar`, no extra arguments" is (while a good goal) a bit unrealistic.
>     Most of the real world Java application I've seen all need to drop in
>     some extra command line option (e.g. -Xmx), but I think your problem
>     here is more specific than "just add a command line option" - the
>     problem is adding an option that is only supported on _some_ JDKs
>     (see
>     below).
>
>     On 21/09/2021 03:51, Glavo wrote:
>     > In my original plan, I would convert it into a multi-release jar.
>     > On the Java platform available to Panama, I will use Panama to call
>     > the system API.?This will allow me to adapt to more platforms (e.g.
>     > mips64el).
>     > Panama's restrictions made me abandon this scheme.?Because
>     > I can't execute it on any version of Java platform with a
>     unified?command.
>
>     I think this is the real important point here. I'd like to understand
>     more about this use case. Do you have an executable AND multi-release
>     JAR? Is it an application that you are developing? Do you want that
>     application to be just executed using `java -jar foo.jar`? Does your
>     application have a launcher to trigger the `java -jar` command?
>
>     Please walk me through your use case a bit, and please let's keep the
>     conversation focussed - arguing over general safety principles is not
>     very helpful, when the real problem is, I suspect, driven by
>     something
>     much more concrete.
>
>     Thanks
>     Maurizio
>
>

From martin.pernollet at protonmail.com  Tue Sep 21 18:11:42 2021
From: martin.pernollet at protonmail.com (Martin Pernollet)
Date: Tue, 21 Sep 2021 18:11:42 +0000
Subject: [External] : Re: JEP-412 & OpenGL
In-Reply-To: <49b0129b-7a26-e520-4d63-72ef402756e0@oracle.com>
References: 
 <44916ce4-1174-28d0-6cff-28ee6ac7b487@oracle.com>
 <91EE3A16-B5E3-4DAA-A299-6B332178B5A0@oracle.com>
 <20IAXMh_D5CwrlzRuub4xeEQVgsdy_SG-PGZ_mFzrEPcaCOUWu2_6lwXTxR10bHTJmUQW8Xaq0xnen8Fmp65kBkg3Nikf1y-h2zDL-80-lI=@protonmail.com>
 
 
 
 <7e4389ad-1a15-d480-72af-e92c507ffe49@oracle.com>
 
 <49b0129b-7a26-e520-4d63-72ef402756e0@oracle.com>
Message-ID: 

Thank you a lot, it is working now, what a beautiful teapot :) Git repo updated with your suggestions.

It seems that the window is a native one, so I presume that rendering in a classical AWT Canvas will require to render offscreen, get the image, then draw it in a Canvas. Right?

Martin


??????? Original Message ???????

Le mardi 21 septembre 2021 ? 19:50, Jorn Vernee  a ?crit :

> Hi,
>
> Your source code looks correct to me.
>
> I've tried out the project here as well, and the only two changes I had
>
> to make to make it work were changing the compiler plugin to version
>
> 3.8.1 (it seems like the latest version was not picking up the
>
> `--add-modules` flag). I then have this in the pom.xml:
>
>      ??? ??? ??? 
>
>     maven-compiler-plugin
>
>      ??? ??? ??? ??? 3.8.1
>
>      ??? ??? ??? ??? 
>
>      ??? ??? ??? ??? ??? 17
>
>      ??? ??? ??? ??? ??? 17
>
>      ??? ??? ??? ??? ??? UTF-8
>
>      ??? ??? ??? ??? ??? 
>
>     --add-modules=jdk.incubator.foreign
>
>      ??? ??? ??? ??? ??? 
>
>      ??? ??? ??? ??? 
>
>      ??? ??? ??? 
>
>
>
> (Everything else still the same),
>
> And after running `mvn clean package` I can run the program with:
>
>      > java '-Djava.library.path='?
>
>     --enable-native-access=ALL-UNNAMED --add-modules jdk.incubator.foreign
>     -jar .\\target\\panama-gl-2.0.1-SNAPSHOT.jar
>
>
> (Just had to fix a minor issue in Teapot since I'm using freeglut, but
>
> that shouldn't matter for you). This displays the teapot for me.
>
> So the only thing I can suggest at this point is to update the version
>
> of your maven-compile-plugin
>
> HTH,
>
> Jorn
>
> On 21/09/2021 19:38, Martin Pernollet wrote:
>
> > Hi,
> >
> > Thanks for the jar option clarification.
> >
> > Teapot [0] indeed imports opengl.glut_h.* but opengl.glut_h extends opengl.glut_h_3 (and cascading to h2 and then h1). All the GL primitives called by Teapot are methods defined in glut_h_*, e.g. as glShadeModel(). Does this look normal then?
> >
> > [0] https://urldefense.com/v3/https://github.com/jzy3d/panama-gl/blob/main/src/main/java/Teapot.java;!!ACWV5N9M2RV99hQ!cIN_fFK3UfVQgbhYOhe8V6GNsyy446g9Y7ulr2-sfBr_mwelkQVbDsJh8NPDlt7v$ can be nicely browsed on Github that provides an IDE like ability to navigate in code.
> >
> > ??????? Original Message ???????
> >
> > Le mardi 21 septembre 2021 ? 18:42, Jorn Vernee jorn.vernee at oracle.com a ?crit :
> >
> > > Hi Martin,
> > >
> > > Note that anything passed after the `-jar ` argument is a program
> > >
> > > argument, passing all the flags before `-jar` passes them as VM
> > >
> > > arguments, which is correct.
> > >
> > > The second error message you are getting is a bit puzzling. It seems
> > >
> > > that somehow your Teapot class is directly trying to access an internal
> > >
> > > binding class.
> > >
> > > Note that the generated bindings should be accessed through
> > >
> > > opengl.glut_h, which is public [1], instead of opengl.glut_h_3, which is
> > >
> > > package-private [2].
> > >
> > > HTH,
> > >
> > > Jorn
> > >
> > > [1] :
> > >
> > > https://urldefense.com/v3/https://github.com/jzy3d/panama-gl/blob/main/src/main/java/opengl/glut_h.java;!!ACWV5N9M2RV99hQ!cIN_fFK3UfVQgbhYOhe8V6GNsyy446g9Y7ulr2-sfBr_mwelkQVbDsJh8NGhSAfu$
> > >
> > > [2] :
> > >
> > > https://urldefense.com/v3/https://github.com/jzy3d/panama-gl/blob/main/src/main/java/opengl/glut_h_3.java;!!ACWV5N9M2RV99hQ!cIN_fFK3UfVQgbhYOhe8V6GNsyy446g9Y7ulr2-sfBr_mwelkQVbDsJh8G52B9OM$
> > >
> > > On 21/09/2021 16:41, Martin Pernollet wrote:
> > >
> > > > Yes, I also added it at runtime as follow
> > > >
> > > > java -jar target/panama-gl-2.0.1-SNAPSHOT.jar -XstartOnFirstThread --enable-native-access=ALL-UNNAMED --add-modules jdk.incubator.foreign -Djava.library.path=.:/System/Library/Frameworks/OpenGL.framework/Versions/Current/Libraries/
> > > >
> > > > But the error was coming from the position of the -jar argument. I can go (just a little) further by putting the -jar argument at the end as follow
> > > >
> > > > java -XstartOnFirstThread --enable-native-access=ALL-UNNAMED --add-modules jdk.incubator.foreign -Djava.library.path=.:/System/Library/Frameworks/OpenGL.framework/Versions/Current/Libraries/ -jar target/panama-gl-2.0.1-SNAPSHOT.jar
> > > >
> > > > WARNING: Using incubator modules: jdk.incubator.foreign
> > > >
> > > > Exception in thread "main" java.lang.IllegalAccessError: failed to access class opengl.glut_h_3 from class Teapot (opengl.glut_h_3 and Teapot are in unnamed module of loader 'app')
> > > >
> > > > at Teapot.main(Teapot.java:80)
> > > >
> > > > Still have to learn a few things about modules :)
> > > >
> > > > Sent with ProtonMail Secure Email.
> > > >
> > > > ??????? Original Message ???????
> > > >
> > > > Le mardi 21 septembre 2021 ? 14:41, Maurizio Cimadamore maurizio.cimadamore at oracle.com a ?crit :
> > > >
> > > > > Hi Martin,
> > > > >
> > > > > I think the compilation setup looks correct. The question is how do you
> > > > >
> > > > > run the application? The --add-modules option has to be added both at
> > > > >
> > > > > compile-time (which you are doing) and at run-time.
> > > > >
> > > > > Maurizio
> > > > >
> > > > > On 21/09/2021 13:15, Martin Pernollet wrote:
> > > > >
> > > > > > Hi everyone,
> > > > > >
> > > > > > I followed the steps of the OpenGL tutorial and mentioned them here [1]. I got stuck with the below error when running the JAR - which I create with Maven + Shade plugin to later use Jzy3D and Panama together.
> > > > > >
> > > > > > Error: Unable to initialize main class Teapot
> > > > > >
> > > > > > Caused by: java.lang.NoClassDefFoundError: jdk/incubator/foreign/Addressable
> > > > > >
> > > > > > Do you have a suggestion for this? I already tried building by passing the --add-modules in three different ways :
> > > > > >
> > > > > > (1) mvn install -D--add-modules=jdk.incubator.foreign
> > > > > >
> > > > > > (2) mvn install --add-modules jdk.incubator.foreign
> > > > > >
> > > > > > (3) mvn install without arguments by relying on maven compiler plugin setup as follow
> > > > > >
> > > > > > 
> > > > > >
> > > > > > maven-compiler-plugin
> > > > > >
> > > > > > 2.3.2
> > > > > >
> > > > > > 
> > > > > >
> > > > > > 17
> > > > > >
> > > > > > 17
> > > > > >
> > > > > > UTF-8
> > > > > >
> > > > > > 
> > > > > >
> > > > > > --add-modules
> > > > > >
> > > > > > jdk.incubator.foreign
> > > > > >
> > > > > > --add-exports
> > > > > >
> > > > > > jdk.incubator.foreign
> > > > > >
> > > > > > 
> > > > > >
> > > > > > 
> > > > > >
> > > > > > 
> > > > > >
> > > > > > I'll gladly bundled the Q&A in the above readme for other developers.
> > > > > >
> > > > > > Thanks in advance,
> > > > > >
> > > > > > Martin
> > > > > >
> > > > > > [1] https://urldefense.com/v3/https://github.com/jzy3d/panama-gl;!!ACWV5N9M2RV99hQ!bD8kYg-yxOkAx3K51U-h3dQqyLInU20XCvH8O8KiyWJ-qrZS3rxRah14L9c_Rhlt8SNQYGs$
> > > > > >
> > > > > > [2] https://urldefense.com/v3/https://github.com/sundararajana/panama-jextract-samples/issues;!!ACWV5N9M2RV99hQ!bD8kYg-yxOkAx3K51U-h3dQqyLInU20XCvH8O8KiyWJ-qrZS3rxRah14L9c_Rhlt2ft10UE$
> > > > > >
> > > > > > Sent with ProtonMail Secure Email.
> > > > > >
> > > > > > ??????? Original Message ???????
> > > > > >
> > > > > > Le lundi 20 septembre 2021 ? 14:24, Martin Pernollet martin.pernollet at protonmail.com a ?crit :
> > > > > >
> > > > > > > Thank you all for your answers.
> > > > > > >
> > > > > > > I'll give a try in the coming weeks and will tell you how this works.
> > > > > > >
> > > > > > > Martin
> > > > > > >
> > > > > > > Sent with ProtonMail Secure Email.
> > > > > > >
> > > > > > > ??????? Original Message ???????
> > > > > > >
> > > > > > > Le samedi 18 septembre 2021 ? 12:56, John Rose john.r.rose at oracle.com a ?crit :
> > > > > > >
> > > > > > > > Actually the JOGL work is one of the old inspirations for Panama.
> > > > > > > >
> > > > > > > > The idea that we could use declarative schema information (instead of imperatives coded C wrappers) to transition between Java and native libraries is found in SWIG, JOGL, Panama, JNR, and many other places. (I did a tech. like that in the mid ?90s for a pre-Java VM.)
> > > > > > > >
> > > > > > > > That said, surely even a JNI code generation tool is worse than something that just runs out of a JAR or jshell session. Eventually, I hope, we will tease apart the aspects of JNI into a proper set of primitives that allows, but does not require, hand written or tool written JNI C code.
> > > > > > > >
> > > > > > > > The primitives I am thinking of these days are:
> > > > > > > >
> > > > > > > > Panama native lookup accesses nearly all native entry point.
> > > > > > > >
> > > > > > > > These are optimizable by the JIT and/or AOT to be equivalent with today?s ad hoc JVM native transition wrappers.
> > > > > > > >
> > > > > > > > And then, a way to program any native method not only via JNI but via an Indy-style bootstrap method. This would lazily generate the body of the native method (driven by declarative information, typically) to a Panama wrapper or some other thing.
> > > > > > > >
> > > > > > > > The endgame is that native methods are fully meta programmable, not losing any JNI use cases (because Panama), but adding other ones, with suitable BSMs.
> > > > > > > >
> > > > > > > > In a world where native methods have BMMs, a JAR file can contain thousands of method definitions and zero byte codes. Each method will be elaborated just in time by a declarative BSM recipe. An AOT compiler can generate the equivalent of JNI stubs if requested but it?s not needed because the (Panama based) runtime knows how to generate the stubs as early or as late as needed.
> > > > > > > >
> > > > > > > > JOGL can stay as it is until it is ready to retool into the more powerful framework.
> > > > > > > >
> > > > > > > > > On Sep 17, 2021, at 9:26 AM, Maurizio Cimadamore Maurizio.Cimadamore at oracle.com wrote:
> > > > > > > > >
> > > > > > > > > Hi Martin,
> > > > > > > > >
> > > > > > > > > We have no plans to drop support for JNI. JEP 412 offers a replacement which allows libraries to express bindings purely in Java code. In most cases, this is desirable, but I understand that frameworks written prior that JEP might have little to no appetite to rewrite everyting to use MethodHandle/VarHandle and/or jextract.
> > > > > > > > >
> > > > > > > > > As you noted, OpenGL works well with the new foreign APIs, and we have written various samples using OpenGL bindings generated by jextract.
> > > > > > > > >
> > > > > > > > > That said, it is beyond the goal of JEP 412 (and its succesors) to provide an uniform OpenGL API within the JDK - but I think the foreign APIs and the tools (jextract) are now reaching a level of maturity which would allow for such experiments to occur outside the JDK, and we'd be pleased to hear some feedback in the panama-dev mailing list!
> > > > > > > > >
> > > > > > > > > Hope this answers your question
> > > > > > > > >
> > > > > > > > > Maurizio
> > > > > > > > >
> > > > > > > > > > On 17/09/2021 12:54, Martin Pernollet wrote:
> > > > > > > > > >
> > > > > > > > > > Hi,
> > > > > > > > > >
> > > > > > > > > > I actively maintain Jzy3D [1], a framework for drawing 3D charts in Java. It uses JOGL which access native OpenGL with the help of GlueGen, a tool to generate JNI bindings. Jzy3D has an additional OpenGL pure Java CPU renderer [2] to circumvent compatibility limitations of JOGL, mainly for MacOS.
> > > > > > > > > >
> > > > > > > > > > Will JEP-412 close the doors to bindings relying on JNI? In other word will JOGL be able to continue working with GlueGen and JNI?
> > > > > > > > > >
> > > > > > > > > > Are there known plans in OpenJDK for enabling OpenGL (+Metal?) consistently across OS and hardwares via a unified API? II have seen an OpenGL example based on JEP-412 here [3]. I would be interested to assist on that topic and may help making Jzy3D compatible to such API. Jzy3D indeed offers a IPainter interface [4] that allows pluging multiple implementations of OpenGL for Java, hence helping to compare JOGL, EmulGL or any other OpenGL java API.
> > > > > > > > > >
> > > > > > > > > > Thanks in advance,
> > > > > > > > > >
> > > > > > > > > > Martin
> > > > > > > > > >
> > > > > > > > > > [1] https://urldefense.com/v3/http://jzy3d.org/;!!ACWV5N9M2RV99hQ!bD8kYg-yxOkAx3K51U-h3dQqyLInU20XCvH8O8KiyWJ-qrZS3rxRah14L9c_RhltGULw2_M$
> > > > > > > > > >
> > > > > > > > > > [2] https://urldefense.com/v3/https://github.com/jzy3d/jzy3d-api/tree/69a14166096a46bfb6e74cd3ab02e11d41c09024/jzy3d-emul-gl;!!ACWV5N9M2RV99hQ!bD8kYg-yxOkAx3K51U-h3dQqyLInU20XCvH8O8KiyWJ-qrZS3rxRah14L9c_Rhlt1e2WRMw$
> > > > > > > > > >
> > > > > > > > > > [3] https://urldefense.com/v3/https://github.com/sundararajana/panama-jextract-samples/tree/master/opengl;!!ACWV5N9M2RV99hQ!bD8kYg-yxOkAx3K51U-h3dQqyLInU20XCvH8O8KiyWJ-qrZS3rxRah14L9c_RhltTdkbjNo$
> > > > > > > > > >
> > > > > > > > > > [4] https://urldefense.com/v3/https://github.com/jzy3d/jzy3d-api/blob/69a14166096a46bfb6e74cd3ab02e11d41c09024/jzy3d-core/src/main/java/org/jzy3d/painters/IPainter.java;!!ACWV5N9M2RV99hQ!bD8kYg-yxOkAx3K51U-h3dQqyLInU20XCvH8O8KiyWJ-qrZS3rxRah14L9c_RhltwLuRJOg$

From psandoz at openjdk.java.net  Tue Sep 21 18:43:21 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Tue, 21 Sep 2021 18:43:21 GMT
Subject: [foreign-memaccess+abi] RFR: 8273905: Foreign API refresh [v10]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 20 Sep 2021 13:16:07 GMT, Maurizio Cimadamore  wrote:

>> As outlined in [1], there are areas of the foreign API we'd like to improve upon, such as:
>> 
>> * dereference: there is a mismatch between API points which create segments (which take a layout) and dereference API points, which do not take layouts
>> 
>> * role of `MemoryAddress`: in Java 17, `MemoryAddress` has become a stateful carrier, which is attached to a scope. This is inconvenient, as in most cases, a memory address is just a raw pointer that arises when interacting with native code.
>> 
>> * resource scopes: the API for scopes has too many flavors to pick from, many of which overlap. The fact that scopes and segment allocators are unrelated forces clients to introduce ad hoc conversions from scopes to allocators, and library developers to add overloads. Finally, the API for acquiring scopes doesn't work well with try-with-resources, and could also be simplified. 
>> 
>> I will add separate comments to explain how the API has changed to resolve the above issues.
>> 
>> [1] - https://mail.openjdk.java.net/pipermail/panama-dev/2021-September/014946.html
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   * Add implNote on `ResourceScope#keepAlive` documenting the maximum number of keep alive requests
>   * Make sure that the keep alive limit is also enforced in confined scope implementations

src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/UpcallStubs.java line 69:

> 67:         @Override
> 68:         public MemoryAddress address() {
> 69:             return MemoryAddress.ofLong(entry);

Does not check if the scope is closed.

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

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

From psandoz at openjdk.java.net  Tue Sep 21 19:38:31 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Tue, 21 Sep 2021 19:38:31 GMT
Subject: [foreign-memaccess+abi] RFR: 8273905: Foreign API refresh [v10]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 20 Sep 2021 13:16:07 GMT, Maurizio Cimadamore  wrote:

>> As outlined in [1], there are areas of the foreign API we'd like to improve upon, such as:
>> 
>> * dereference: there is a mismatch between API points which create segments (which take a layout) and dereference API points, which do not take layouts
>> 
>> * role of `MemoryAddress`: in Java 17, `MemoryAddress` has become a stateful carrier, which is attached to a scope. This is inconvenient, as in most cases, a memory address is just a raw pointer that arises when interacting with native code.
>> 
>> * resource scopes: the API for scopes has too many flavors to pick from, many of which overlap. The fact that scopes and segment allocators are unrelated forces clients to introduce ad hoc conversions from scopes to allocators, and library developers to add overloads. Finally, the API for acquiring scopes doesn't work well with try-with-resources, and could also be simplified. 
>> 
>> I will add separate comments to explain how the API has changed to resolve the above issues.
>> 
>> [1] - https://mail.openjdk.java.net/pipermail/panama-dev/2021-September/014946.html
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   * Add implNote on `ResourceScope#keepAlive` documenting the maximum number of keep alive requests
>   * Make sure that the keep alive limit is also enforced in confined scope implementations

Looks good, just one further issue identified with the upcall stub implementation, which I believe should be easy to fix.

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

Marked as reviewed by psandoz (Committer).

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

From zjx001202 at gmail.com  Tue Sep 21 20:14:57 2021
From: zjx001202 at gmail.com (Glavo)
Date: Wed, 22 Sep 2021 04:14:57 +0800
Subject: Will we need to use the --enable-native-access option to enable
 JNI in the future?
In-Reply-To: <0eb894b2-0de7-d0bc-dc4d-298126e3726b@oracle.com>
References: 
 
 
 
 
 <18b80809-54b1-1b40-e5f2-a2b1a4e10711@oracle.com>
 
 <2eb43d4c-6eee-39f7-877b-d98681773520@oracle.com>
 
 <0eb894b2-0de7-d0bc-dc4d-298126e3726b@oracle.com>
Message-ID: 



some complaints
I don't think jpackage and jlink are satisfactory for smaller programs.
I haven't considered bundling JRE for the above program for the time
being. Because of its work content, it needs a complete JRE.
However, I am trying to provide bundled JRE for distribution for many
of my other tools, and the results are not satisfactory.

Specifically, I have a tool implemented using JavaFX, used to view
the file structure of Java class file (~230 kb, only dependencies on
javafx.controls, no other dependencies). It is bundled with a minimal
JRE 13.0.1 generated using jlink, and eliminate unnecessary executable
programs, and use launcher to directly call jvm.dll to start. After
compression by deflate algorithm, the size is about 25m, and nearly 70m
after decompression. This requires me to pay more than 100 times the
CDN traffic fee (about 70 times if LZMA compression is used). Of course,
this is just a very small tool. However, if I try to bundle JRE for the
software mentioned in the previous email, even the compressed size will
increase by more than 70m (the size has increased twenty times). If so,
in order to distribute this free software that hardly brings us revenue,
we may have to pay hundreds of dollars of CDN traffic fees to service
provider every month, which is unacceptable.

As a Java developer, I have developed or used many developer oriented
tools implemented in Java, Most of them I don't think I should carry
its own JRE, and it seems that using different JREs will also make it
difficult to use CDS to improve startup time and save memory.
I think it is necessary to distribute the programs without binding JRE
separately.



I really do think that modules are the right boundaries to enforce
> restrictions.
>

Ah, is that so. In fact, I'm curious about how to implement fine-grained
permission control after deprecated foo. It seems that Panama doesn't
intend to implement it. Perhaps the introduction of dynamic native
access control in the future will make this use case more flexible.

Thank you for your contribution and thank you again for your patient reply.

In the end, I'd like to conclude with my expectations and suggestions.
I hope these suggestions can help the development of Panama.


   - Better integration of Panama and JPMS (maybe use `*native module {}`*
   to declare module in module-info,java)
   - Allow --enable-native-access to pass between modules (maybe like
`*opens native
   to ;*` declare in module-info.java)
   - To allow --enable-native-access to be declared in manifest.mf (maybe
   *EnableNativeAccess *entry)
   - Enable module native access at runtime
   - In the far future, restrict JNI (If Panama and JPMS can be better
   integrated, JNI may be able to reuse it)
   - Use clearer, non misleading names

Finally, thank you again.

(If I want to ask a question about JPMS, which mailing list should I go to?
Is jdk-dev?)

Maurizio Cimadamore  ?2021?9?22??? ??2:11???

> Summarizing, you have what we could call an "application".
>
> You have a launcher for it in some platforms, and on other platforms you
> don't.
>
> Of course, where there's a launcher it is trivial (albeit maybe tedious)
> to add the required options depending on the java version.
>
> Without the launcher you are constrained by what can be expressed in the
> manifest of the jarfile - which at the moment is "not a lot" :-)
>
> 
> With respect to bundling JRE, I think modularization has helped a lot
> there. You can create an image (using jlink) that only contains the modules
> you want - and then, use jpackage to generate a small executable out of
> that. We tried this approach to create a standalone jextract tool, and I
> have to say it worked really well - the size is very compact (as most of
> the JDK modules are dropped), to the point that the size of the standalone
> app tracks closely that of the native library it depends on (libclang). I
> hope many more projects decide to do things this way, because, IMHO, it
> just a much saner way to package up things and dependencies.
> 
>
> I really do think that modules are the right boundaries to enforce
> restrictions.
>
> I concede that, given the current situation, if the option was called
> --enable-restricted-access instead of --enable-native-access that might be
> perceived as less of a "lie".
>
> Maurizio
>
>
>
> On 21/09/2021 17:09, Glavo wrote:
>
> I think this is the real important point here. I'd like to understand
>> more about this use case. Do you have an executable AND multi-release
>> JAR? Is it an application that you are developing? Do you want that
>> application to be just executed using `java -jar foo.jar`? Does your
>> application have a launcher to trigger the `java -jar` command?
>>
>
> Yes, even more than one of my programs are looking forward to introducing
> Panama to improve some corner features, even if they don't use native
> methods at present: Although using native access can improve the user
> experience, it is not necessary. If JNI is introduced, the build and
> testing process will be extremely complex, and it is difficult to support
> some niche platforms (e.g. Linux MIPS64el). JNA or JNR will significantly
> expand the size of small programs. I expect to use Panama as an
> alternative
> to JNA to implement some optional functions, enable it on Java 21, and
> gracefully fallback in earlier versions.
>
>
> Using a more specific example, there is a JavaFX GUI application that
> I am involved in developing. It's a popular program. We have more than
> *one hundred thousand users*. This is a program for ordinary users. Most
> of them are not developers.
>
> It is always distributed as a fatJar (~3.6MB) and is expected to be
> out of the box except (Only need Java environment). In order to make it
> out of the box, it will automatically download OpenJFX at runtime and
> put it into module path by dirty way (Use BuiltinClassLoader::loadModule).
>
> It has a launcher, but not always available. We splice an exe in front
> of the contents of the jar file (It is still a JAR, which is allowed
> by the ZIP format). The launcher will look for java.exe in several
> places and start the program with CreateProcess. However, our program
> is cross platform, and there are many users who do not use Windows,
> and our launcher is only effective on the Windows platform.
> On other platforms, we simply distribute the fatJar. Fortunately, it
> works well because the double-click action of jar on the Mac OS is
> open it with java -jar. For Linux users, the most common usage is to
> start it with java -jar. Moreover, many of our windows users will use
> jar instead of exe version, because the double-click action of jar will
> also be associated when installing JRE, so they often do not need to
> rely on launcher.
>
> We have no plans to provide launchers on platforms other than windows,
> We won't give up Java 8 for a long time (maybe before 2031, but maybe
> later). Bundling JRE and distributing it is absolutely unacceptable.
> It will expand our application distribution by more than seven times,
> and expand the volume after decompression by more than 20 times!
> It is acceptable for us to recommend users to install Java by themselves,
> because the program is related to minecraft, and users always need a
> JRE. We want to keep the form of distributing a single jar. Being clean
> and portable software is one of its selling points.
>
> For the record, I don't despise all code at all -
>> but I also think that the position of "must be run with a clean `java
>> -jar`, no extra arguments" is (while a good goal) a bit unrealistic.
>> Most of the real world Java application I've seen all need to drop in
>> some extra command line option (e.g. -Xmx), but I think your problem
>> here is more specific than "just add a command line option" - the
>> problem is adding an option that is only supported on _some_ JDKs (see
>> below).
>>
>
> I don't think this is unrealistic. Java's default options are good
> enough for most small programs, and I have noticed that Java has been
> improving out of box availability. I believe that Java's default options
> will be good enough for most client applications in the future.
>
> Please walk me through your use case a bit, and please let's keep the
>> conversation focussed - arguing over general safety principles is not
>> very helpful, when the real problem is, I suspect, driven by something
>> much more concrete.
>>
>
> I know you have your point of view, and I don't want to keep pestering
> on it. But I want to remind you one last time: This option is currently
> very confusing to users, at least the name is problematic. At present,
> it cannot restrict native access, but it implies that it has this
> ability. This is a security risk. I insist that for the time being,
> Panama should not force the check of native access execution by default.
> It needs to prepare the security mechanism and remind the user to use
> it, but it should not start to execute by default until it is ready
> to restrict JNI (and deprecated sun.misc.Unsafe).
>
> Of course, real-world safety problems often come from dynamically
> loaded code, but it also reduces the value of this option. I hope that
> Panama will pay more attention to dynamic safety management rather
> than static safety.
>
>
> Here I would like to add another question:
> Is it too coarse-grained to always manage native access permissions
> based on modules? This seems appropriate for a binding library or a
> library that often uses foreign memory. However, for some modules with
> only a few methods that require native access, can't I grant temporary
> permissions? Just like:
>
>   doWithNativeAccess(() -> {
>       someUnsafeMethod(); // ok
>   });
>   someUnsafeMethod(); // IllegalCallerException
>
> Maurizio Cimadamore  ?2021?9?21???
> ??6:20???
>
>> I'll zoom in on this issue, because I think it's the one we need to
>> understand the most. For the record, I don't despise all code at all -
>> but I also think that the position of "must be run with a clean `java
>> -jar`, no extra arguments" is (while a good goal) a bit unrealistic.
>> Most of the real world Java application I've seen all need to drop in
>> some extra command line option (e.g. -Xmx), but I think your problem
>> here is more specific than "just add a command line option" - the
>> problem is adding an option that is only supported on _some_ JDKs (see
>> below).
>>
>> On 21/09/2021 03:51, Glavo wrote:
>> > In my original plan, I would convert it into a multi-release jar.
>> > On the Java platform available to Panama, I will use Panama to call
>> > the system API. This will allow me to adapt to more platforms (e.g.
>> > mips64el).
>> > Panama's restrictions made me abandon this scheme. Because
>> > I can't execute it on any version of Java platform with a
>> unified command.
>>
>> I think this is the real important point here. I'd like to understand
>> more about this use case. Do you have an executable AND multi-release
>> JAR? Is it an application that you are developing? Do you want that
>> application to be just executed using `java -jar foo.jar`? Does your
>> application have a launcher to trigger the `java -jar` command?
>>
>> Please walk me through your use case a bit, and please let's keep the
>> conversation focussed - arguing over general safety principles is not
>> very helpful, when the real problem is, I suspect, driven by something
>> much more concrete.
>>
>> Thanks
>> Maurizio
>>
>>
>>

From maurizio.cimadamore at oracle.com  Tue Sep 21 21:01:06 2021
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 21 Sep 2021 22:01:06 +0100
Subject: Will we need to use the --enable-native-access option to enable
 JNI in the future?
In-Reply-To: 
References: 
 
 
 
 
 <18b80809-54b1-1b40-e5f2-a2b1a4e10711@oracle.com>
 
 <2eb43d4c-6eee-39f7-877b-d98681773520@oracle.com>
 
 <0eb894b2-0de7-d0bc-dc4d-298126e3726b@oracle.com>
 
Message-ID: 


On 21/09/2021 21:14, Glavo wrote:
> In the end, I'd like to conclude with my expectations and suggestions.
> I hope these suggestions can help the development of Panama.
>
>   * Better integration of Panama and JPMS (maybe use `/native module
>     {}`/ to declare module in module-info,java)
>   * Allow --enable-native-access to pass between modules (maybe like
>     `/opens?native to ;/` declare in module-info.java)
>   * To allow --enable-native-access to be declared in manifest.mf
>     (maybe /EnableNativeAccess /entry)
>   * Enable module native access at runtime
>
I think I agree with all the points above (and these were very much on 
the roadmap, they are just not done yet, as some of them requires 
additional exploration).
>
>   * In the far future,?restrict JNI (If Panama and JPMS can be better
>     integrated, JNI may be able to reuse it)
>
this is also something that we'd like to get to, although, as I said, we 
have to play more carefully there (e.g. maybe first warn, then error).
>
>   * Use clearer, non misleading names
>
I think I tend to agree with this too. Naming is hard. I think we 
probably over-rotated towards "native", maybe something that has to do 
with "restricted" which is the word the API uses would be better, but I 
don't have any clever idea right now.


> Finally, thank you again.

Thank you for sharing your side of the story. I think overall, the 
things you propose, while not immediately available right now, are part 
of the solution that we'd like to offer at some point.

Maurizio

>
> (If I want to ask a question about JPMS, which mailing list should I 
> go to? Is jdk-dev?)

From maurizio.cimadamore at oracle.com  Tue Sep 21 21:02:21 2021
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 21 Sep 2021 22:02:21 +0100
Subject: [External] : Re: JEP-412 & OpenGL
In-Reply-To: 
References: 
 <91EE3A16-B5E3-4DAA-A299-6B332178B5A0@oracle.com>
 <20IAXMh_D5CwrlzRuub4xeEQVgsdy_SG-PGZ_mFzrEPcaCOUWu2_6lwXTxR10bHTJmUQW8Xaq0xnen8Fmp65kBkg3Nikf1y-h2zDL-80-lI=@protonmail.com>
 
 
 
 <7e4389ad-1a15-d480-72af-e92c507ffe49@oracle.com>
 
 <49b0129b-7a26-e520-4d63-72ef402756e0@oracle.com>
 
Message-ID: <046b0f69-ba5d-e827-6c68-26b28d4b2960@oracle.com>


On 21/09/2021 19:11, Martin Pernollet wrote:
> Thank you a lot, it is working now, what a beautiful teapot :) Git repo updated with your suggestions.
>
> It seems that the window is a native one, so I presume that rendering in a classical AWT Canvas will require to render offscreen, get the image, then draw it in a Canvas. Right?

GLUT uses its own way for opening windows - so yes, that'd be a native one.

Maurizio

>
> Martin
>
>
> ??????? Original Message ???????
>
> Le mardi 21 septembre 2021 ? 19:50, Jorn Vernee  a ?crit :
>
>> Hi,
>>
>> Your source code looks correct to me.
>>
>> I've tried out the project here as well, and the only two changes I had
>>
>> to make to make it work were changing the compiler plugin to version
>>
>> 3.8.1 (it seems like the latest version was not picking up the
>>
>> `--add-modules` flag). I then have this in the pom.xml:
>>
>>       ??? ??? ??? 
>>
>>      maven-compiler-plugin
>>
>>       ??? ??? ??? ??? 3.8.1
>>
>>       ??? ??? ??? ??? 
>>
>>       ??? ??? ??? ??? ??? 17
>>
>>       ??? ??? ??? ??? ??? 17
>>
>>       ??? ??? ??? ??? ??? UTF-8
>>
>>       ??? ??? ??? ??? ??? 
>>
>>      --add-modules=jdk.incubator.foreign
>>
>>       ??? ??? ??? ??? ??? 
>>
>>       ??? ??? ??? ??? 
>>
>>       ??? ??? ??? 
>>
>>
>>
>> (Everything else still the same),
>>
>> And after running `mvn clean package` I can run the program with:
>>
>>       > java '-Djava.library.path='
>>
>>      --enable-native-access=ALL-UNNAMED --add-modules jdk.incubator.foreign
>>      -jar .\\target\\panama-gl-2.0.1-SNAPSHOT.jar
>>
>>
>> (Just had to fix a minor issue in Teapot since I'm using freeglut, but
>>
>> that shouldn't matter for you). This displays the teapot for me.
>>
>> So the only thing I can suggest at this point is to update the version
>>
>> of your maven-compile-plugin
>>
>> HTH,
>>
>> Jorn
>>
>> On 21/09/2021 19:38, Martin Pernollet wrote:
>>
>>> Hi,
>>>
>>> Thanks for the jar option clarification.
>>>
>>> Teapot [0] indeed imports opengl.glut_h.* but opengl.glut_h extends opengl.glut_h_3 (and cascading to h2 and then h1). All the GL primitives called by Teapot are methods defined in glut_h_*, e.g. as glShadeModel(). Does this look normal then?
>>>
>>> [0] https://urldefense.com/v3/https://github.com/jzy3d/panama-gl/blob/main/src/main/java/Teapot.java;!!ACWV5N9M2RV99hQ!cIN_fFK3UfVQgbhYOhe8V6GNsyy446g9Y7ulr2-sfBr_mwelkQVbDsJh8NPDlt7v$ can be nicely browsed on Github that provides an IDE like ability to navigate in code.
>>>
>>> ??????? Original Message ???????
>>>
>>> Le mardi 21 septembre 2021 ? 18:42, Jorn Vernee jorn.vernee at oracle.com a ?crit :
>>>
>>>> Hi Martin,
>>>>
>>>> Note that anything passed after the `-jar ` argument is a program
>>>>
>>>> argument, passing all the flags before `-jar` passes them as VM
>>>>
>>>> arguments, which is correct.
>>>>
>>>> The second error message you are getting is a bit puzzling. It seems
>>>>
>>>> that somehow your Teapot class is directly trying to access an internal
>>>>
>>>> binding class.
>>>>
>>>> Note that the generated bindings should be accessed through
>>>>
>>>> opengl.glut_h, which is public [1], instead of opengl.glut_h_3, which is
>>>>
>>>> package-private [2].
>>>>
>>>> HTH,
>>>>
>>>> Jorn
>>>>
>>>> [1] :
>>>>
>>>> https://urldefense.com/v3/https://github.com/jzy3d/panama-gl/blob/main/src/main/java/opengl/glut_h.java;!!ACWV5N9M2RV99hQ!cIN_fFK3UfVQgbhYOhe8V6GNsyy446g9Y7ulr2-sfBr_mwelkQVbDsJh8NGhSAfu$
>>>>
>>>> [2] :
>>>>
>>>> https://urldefense.com/v3/https://github.com/jzy3d/panama-gl/blob/main/src/main/java/opengl/glut_h_3.java;!!ACWV5N9M2RV99hQ!cIN_fFK3UfVQgbhYOhe8V6GNsyy446g9Y7ulr2-sfBr_mwelkQVbDsJh8G52B9OM$
>>>>
>>>> On 21/09/2021 16:41, Martin Pernollet wrote:
>>>>
>>>>> Yes, I also added it at runtime as follow
>>>>>
>>>>> java -jar target/panama-gl-2.0.1-SNAPSHOT.jar -XstartOnFirstThread --enable-native-access=ALL-UNNAMED --add-modules jdk.incubator.foreign -Djava.library.path=.:/System/Library/Frameworks/OpenGL.framework/Versions/Current/Libraries/
>>>>>
>>>>> But the error was coming from the position of the -jar argument. I can go (just a little) further by putting the -jar argument at the end as follow
>>>>>
>>>>> java -XstartOnFirstThread --enable-native-access=ALL-UNNAMED --add-modules jdk.incubator.foreign -Djava.library.path=.:/System/Library/Frameworks/OpenGL.framework/Versions/Current/Libraries/ -jar target/panama-gl-2.0.1-SNAPSHOT.jar
>>>>>
>>>>> WARNING: Using incubator modules: jdk.incubator.foreign
>>>>>
>>>>> Exception in thread "main" java.lang.IllegalAccessError: failed to access class opengl.glut_h_3 from class Teapot (opengl.glut_h_3 and Teapot are in unnamed module of loader 'app')
>>>>>
>>>>> at Teapot.main(Teapot.java:80)
>>>>>
>>>>> Still have to learn a few things about modules :)
>>>>>
>>>>> Sent with ProtonMail Secure Email.
>>>>>
>>>>> ??????? Original Message ???????
>>>>>
>>>>> Le mardi 21 septembre 2021 ? 14:41, Maurizio Cimadamore maurizio.cimadamore at oracle.com a ?crit :
>>>>>
>>>>>> Hi Martin,
>>>>>>
>>>>>> I think the compilation setup looks correct. The question is how do you
>>>>>>
>>>>>> run the application? The --add-modules option has to be added both at
>>>>>>
>>>>>> compile-time (which you are doing) and at run-time.
>>>>>>
>>>>>> Maurizio
>>>>>>
>>>>>> On 21/09/2021 13:15, Martin Pernollet wrote:
>>>>>>
>>>>>>> Hi everyone,
>>>>>>>
>>>>>>> I followed the steps of the OpenGL tutorial and mentioned them here [1]. I got stuck with the below error when running the JAR - which I create with Maven + Shade plugin to later use Jzy3D and Panama together.
>>>>>>>
>>>>>>> Error: Unable to initialize main class Teapot
>>>>>>>
>>>>>>> Caused by: java.lang.NoClassDefFoundError: jdk/incubator/foreign/Addressable
>>>>>>>
>>>>>>> Do you have a suggestion for this? I already tried building by passing the --add-modules in three different ways :
>>>>>>>
>>>>>>> (1) mvn install -D--add-modules=jdk.incubator.foreign
>>>>>>>
>>>>>>> (2) mvn install --add-modules jdk.incubator.foreign
>>>>>>>
>>>>>>> (3) mvn install without arguments by relying on maven compiler plugin setup as follow
>>>>>>>
>>>>>>> 
>>>>>>>
>>>>>>> maven-compiler-plugin
>>>>>>>
>>>>>>> 2.3.2
>>>>>>>
>>>>>>> 
>>>>>>>
>>>>>>> 17
>>>>>>>
>>>>>>> 17
>>>>>>>
>>>>>>> UTF-8
>>>>>>>
>>>>>>> 
>>>>>>>
>>>>>>> --add-modules
>>>>>>>
>>>>>>> jdk.incubator.foreign
>>>>>>>
>>>>>>> --add-exports
>>>>>>>
>>>>>>> jdk.incubator.foreign
>>>>>>>
>>>>>>> 
>>>>>>>
>>>>>>> 
>>>>>>>
>>>>>>> 
>>>>>>>
>>>>>>> I'll gladly bundled the Q&A in the above readme for other developers.
>>>>>>>
>>>>>>> Thanks in advance,
>>>>>>>
>>>>>>> Martin
>>>>>>>
>>>>>>> [1] https://urldefense.com/v3/https://github.com/jzy3d/panama-gl;!!ACWV5N9M2RV99hQ!bD8kYg-yxOkAx3K51U-h3dQqyLInU20XCvH8O8KiyWJ-qrZS3rxRah14L9c_Rhlt8SNQYGs$
>>>>>>>
>>>>>>> [2] https://urldefense.com/v3/https://github.com/sundararajana/panama-jextract-samples/issues;!!ACWV5N9M2RV99hQ!bD8kYg-yxOkAx3K51U-h3dQqyLInU20XCvH8O8KiyWJ-qrZS3rxRah14L9c_Rhlt2ft10UE$
>>>>>>>
>>>>>>> Sent with ProtonMail Secure Email.
>>>>>>>
>>>>>>> ??????? Original Message ???????
>>>>>>>
>>>>>>> Le lundi 20 septembre 2021 ? 14:24, Martin Pernollet martin.pernollet at protonmail.com a ?crit :
>>>>>>>
>>>>>>>> Thank you all for your answers.
>>>>>>>>
>>>>>>>> I'll give a try in the coming weeks and will tell you how this works.
>>>>>>>>
>>>>>>>> Martin
>>>>>>>>
>>>>>>>> Sent with ProtonMail Secure Email.
>>>>>>>>
>>>>>>>> ??????? Original Message ???????
>>>>>>>>
>>>>>>>> Le samedi 18 septembre 2021 ? 12:56, John Rose john.r.rose at oracle.com a ?crit :
>>>>>>>>
>>>>>>>>> Actually the JOGL work is one of the old inspirations for Panama.
>>>>>>>>>
>>>>>>>>> The idea that we could use declarative schema information (instead of imperatives coded C wrappers) to transition between Java and native libraries is found in SWIG, JOGL, Panama, JNR, and many other places. (I did a tech. like that in the mid ?90s for a pre-Java VM.)
>>>>>>>>>
>>>>>>>>> That said, surely even a JNI code generation tool is worse than something that just runs out of a JAR or jshell session. Eventually, I hope, we will tease apart the aspects of JNI into a proper set of primitives that allows, but does not require, hand written or tool written JNI C code.
>>>>>>>>>
>>>>>>>>> The primitives I am thinking of these days are:
>>>>>>>>>
>>>>>>>>> Panama native lookup accesses nearly all native entry point.
>>>>>>>>>
>>>>>>>>> These are optimizable by the JIT and/or AOT to be equivalent with today?s ad hoc JVM native transition wrappers.
>>>>>>>>>
>>>>>>>>> And then, a way to program any native method not only via JNI but via an Indy-style bootstrap method. This would lazily generate the body of the native method (driven by declarative information, typically) to a Panama wrapper or some other thing.
>>>>>>>>>
>>>>>>>>> The endgame is that native methods are fully meta programmable, not losing any JNI use cases (because Panama), but adding other ones, with suitable BSMs.
>>>>>>>>>
>>>>>>>>> In a world where native methods have BMMs, a JAR file can contain thousands of method definitions and zero byte codes. Each method will be elaborated just in time by a declarative BSM recipe. An AOT compiler can generate the equivalent of JNI stubs if requested but it?s not needed because the (Panama based) runtime knows how to generate the stubs as early or as late as needed.
>>>>>>>>>
>>>>>>>>> JOGL can stay as it is until it is ready to retool into the more powerful framework.
>>>>>>>>>
>>>>>>>>>> On Sep 17, 2021, at 9:26 AM, Maurizio Cimadamore Maurizio.Cimadamore at oracle.com wrote:
>>>>>>>>>>
>>>>>>>>>> Hi Martin,
>>>>>>>>>>
>>>>>>>>>> We have no plans to drop support for JNI. JEP 412 offers a replacement which allows libraries to express bindings purely in Java code. In most cases, this is desirable, but I understand that frameworks written prior that JEP might have little to no appetite to rewrite everyting to use MethodHandle/VarHandle and/or jextract.
>>>>>>>>>>
>>>>>>>>>> As you noted, OpenGL works well with the new foreign APIs, and we have written various samples using OpenGL bindings generated by jextract.
>>>>>>>>>>
>>>>>>>>>> That said, it is beyond the goal of JEP 412 (and its succesors) to provide an uniform OpenGL API within the JDK - but I think the foreign APIs and the tools (jextract) are now reaching a level of maturity which would allow for such experiments to occur outside the JDK, and we'd be pleased to hear some feedback in the panama-dev mailing list!
>>>>>>>>>>
>>>>>>>>>> Hope this answers your question
>>>>>>>>>>
>>>>>>>>>> Maurizio
>>>>>>>>>>
>>>>>>>>>>> On 17/09/2021 12:54, Martin Pernollet wrote:
>>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> I actively maintain Jzy3D [1], a framework for drawing 3D charts in Java. It uses JOGL which access native OpenGL with the help of GlueGen, a tool to generate JNI bindings. Jzy3D has an additional OpenGL pure Java CPU renderer [2] to circumvent compatibility limitations of JOGL, mainly for MacOS.
>>>>>>>>>>>
>>>>>>>>>>> Will JEP-412 close the doors to bindings relying on JNI? In other word will JOGL be able to continue working with GlueGen and JNI?
>>>>>>>>>>>
>>>>>>>>>>> Are there known plans in OpenJDK for enabling OpenGL (+Metal?) consistently across OS and hardwares via a unified API? II have seen an OpenGL example based on JEP-412 here [3]. I would be interested to assist on that topic and may help making Jzy3D compatible to such API. Jzy3D indeed offers a IPainter interface [4] that allows pluging multiple implementations of OpenGL for Java, hence helping to compare JOGL, EmulGL or any other OpenGL java API.
>>>>>>>>>>>
>>>>>>>>>>> Thanks in advance,
>>>>>>>>>>>
>>>>>>>>>>> Martin
>>>>>>>>>>>
>>>>>>>>>>> [1] https://urldefense.com/v3/http://jzy3d.org/;!!ACWV5N9M2RV99hQ!bD8kYg-yxOkAx3K51U-h3dQqyLInU20XCvH8O8KiyWJ-qrZS3rxRah14L9c_RhltGULw2_M$
>>>>>>>>>>>
>>>>>>>>>>> [2] https://urldefense.com/v3/https://github.com/jzy3d/jzy3d-api/tree/69a14166096a46bfb6e74cd3ab02e11d41c09024/jzy3d-emul-gl;!!ACWV5N9M2RV99hQ!bD8kYg-yxOkAx3K51U-h3dQqyLInU20XCvH8O8KiyWJ-qrZS3rxRah14L9c_Rhlt1e2WRMw$
>>>>>>>>>>>
>>>>>>>>>>> [3] https://urldefense.com/v3/https://github.com/sundararajana/panama-jextract-samples/tree/master/opengl;!!ACWV5N9M2RV99hQ!bD8kYg-yxOkAx3K51U-h3dQqyLInU20XCvH8O8KiyWJ-qrZS3rxRah14L9c_RhltTdkbjNo$
>>>>>>>>>>>
>>>>>>>>>>> [4] https://urldefense.com/v3/https://github.com/jzy3d/jzy3d-api/blob/69a14166096a46bfb6e74cd3ab02e11d41c09024/jzy3d-core/src/main/java/org/jzy3d/painters/IPainter.java;!!ACWV5N9M2RV99hQ!bD8kYg-yxOkAx3K51U-h3dQqyLInU20XCvH8O8KiyWJ-qrZS3rxRah14L9c_RhltwLuRJOg$

From maurizio.cimadamore at oracle.com  Tue Sep 21 21:03:26 2021
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 21 Sep 2021 22:03:26 +0100
Subject: Will we need to use the --enable-native-access option to enable
 JNI in the future?
In-Reply-To: 
References: 
 
 
 
 
 <18b80809-54b1-1b40-e5f2-a2b1a4e10711@oracle.com>
 
 <2eb43d4c-6eee-39f7-877b-d98681773520@oracle.com>
 
 <0eb894b2-0de7-d0bc-dc4d-298126e3726b@oracle.com>
 
Message-ID: <1c7b83c3-7179-f7e4-65a8-7eb19e7ff9f7@oracle.com>

I think there is jigsaw-dev which is a mailing list where discussions 
around modules tend to happen.

Maurizio

On 21/09/2021 21:14, Glavo wrote:
> (If I want to ask a question about JPMS, which mailing list should I 
> go to? Is jdk-dev?)

From sviswanathan at openjdk.java.net  Tue Sep 21 21:50:17 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Tue, 21 Sep 2021 21:50:17 GMT
Subject: [vectorIntrinsics+mask] RFR: 8273949: Intrinsic creation for
 VectorMask.toLong operation. [v3]
In-Reply-To: <6BV8s5FyH0GDcaUreJfsaFuGcvcZZmcFSZ1-HujLgIo=.e981bc14-143e-4c2b-9dd0-a7cfb941d6f5@github.com>
References: 
 <6BV8s5FyH0GDcaUreJfsaFuGcvcZZmcFSZ1-HujLgIo=.e981bc14-143e-4c2b-9dd0-a7cfb941d6f5@github.com>
Message-ID: 

On Mon, 20 Sep 2021 19:28:40 GMT, Jatin Bhateja  wrote:

>> Summary of changes:
>> - Intrinsification of VectorMask.toLong() API.
>> - Supports inline expansion for both AVX512 and non-AVX512 targets.
>> - Used toLong() API to optimize existing Java API implementation of VectorMask.laneIsSet() operation.
>> 
>> Following performance number are generated using JMH benchmark modification included with the patch.
>> 
>> System:  Intel(R) Xeon(R) Platinum 8280 CPU @ 2.70GHz (Cascade Lake Server 28C 2S)
>> 
>> Benchmark | VECSIZE | Baseline Score (ops/ms) | With Opt (ops/ms) | Gain Ratio
>> -- | -- | -- | -- | --
>> MaskQueryOperationsBenchmark.testToLongByte | 128 | 90451.424 | 346941.379 | 3.835665196
>> MaskQueryOperationsBenchmark.testToLongByte | 256 | 63127.764 | 338331.425 | 5.359471072
>> MaskQueryOperationsBenchmark.testToLongByte | 512 | 40543.264 | 313836.333 | 7.740776199
>> MaskQueryOperationsBenchmark.testToLongLong | 128 | 171989.714 | 152872.758 | 0.88884826
>> MaskQueryOperationsBenchmark.testToLongLong | 256 | 164702.273 | 324794.578 | 1.972010295
>> MaskQueryOperationsBenchmark.testToLongLong | 512 | 122667.916 | 318060.096 | 2.59285481
>> MaskQueryOperationsBenchmark.testToLongShort | 128 | 122656.408 | 346691.082 | 2.826522378
>> MaskQueryOperationsBenchmark.testToLongShort | 256 | 96838.555 | 360909.28 | 3.726917239
>> MaskQueryOperationsBenchmark.testToLongShort | 512 | 63119.009 | 313075.159 | 4.960077225
>> MaskQueryOperationsBenchmark.testToLonglong | 128 | 180855.623 | 324620.433 | 1.794914792
>> MaskQueryOperationsBenchmark.testToLonglong | 256 | 122705.631 | 324315.916 | 2.643040204
>> MaskQueryOperationsBenchmark.testToLonglong | 512 | 90396.687 | 324318.095 | 3.58772103
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8273949: Review comments resolution.

src/hotspot/cpu/x86/x86.ad line 8663:

> 8661: %}
> 8662: 
> 8663: instruct vmask_tolong_evex(rRegL dst, kReg mask) %{

The instructs with rRegL should be in ifdef _LP64.

src/hotspot/cpu/x86/x86.ad line 8694:

> 8692: %}
> 8693: 
> 8694: instruct vmask_truecount_evex(rRegI dst, kReg mask, rRegL tmp) %{

This should have flags register as popcnt instruction affects flags.

src/hotspot/cpu/x86/x86.ad line 8709:

> 8707: 
> 8708: instruct vmask_truecount_avx(rRegI dst, vec mask, rRegL tmp, vec xtmp, vec xtmp1) %{
> 8709:   predicate(n->in(1)->bottom_type()->isa_vectmask() == NULL);

This should also include flags register.

src/hotspot/share/opto/vectornode.hpp line 963:

> 961:  public:
> 962:   VectorMaskToLongNode(Node* mask, const Type* ty):
> 963:     VectorMaskOpNode(mask, ty, Op_VectorMaskLastTrue) {}

Shouldn't this be Op_VectorMaskToLong?

src/hotspot/share/prims/vectorSupport.cpp line 441:

> 439:         case T_FLOAT: // fall-through
> 440:         case T_DOUBLE: return Op_VectorMaskToLong;
> 441:         default: fatal("MASK_TRUECOUNT: %s", type2name(bt));

MASK_TOLONG here? Also break is missing.

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

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

From samuel.audet at gmail.com  Wed Sep 22 03:19:08 2021
From: samuel.audet at gmail.com (Samuel Audet)
Date: Wed, 22 Sep 2021 12:19:08 +0900
Subject: Will we need to use the --enable-native-access option to enable
 JNI in the future?
In-Reply-To: 
References: 
 
 
 
 
 <18b80809-54b1-1b40-e5f2-a2b1a4e10711@oracle.com>
 
 <2eb43d4c-6eee-39f7-877b-d98681773520@oracle.com>
 
Message-ID: <6c4f7554-4d9d-e094-46b5-a6c2c9d7f159@gmail.com>

I don't feel this is something that should be set on a per-application 
basis. I really do mean something like an "environment", like an 
environment variable. Sure, we can ask users to set JAVA_TOOL_OPTIONS 
and what not, but that is not user friendly. It's not for end users. 
Those users should be able to tell the application whether it's OK to 
run that code or not. For example, in the case of Android, etc, we can 
assume the default to be "yes", but for some desktop application, the 
end users could be instructed to go set a checkbox somewhere in the 
settings of the JDK.

This, incidentally, would satisfy the needs of applications such as the 
one Glavo describes, no?

In any case, please explain why this kind of approach is not being 
considered!

Samuel

On 9/21/21 8:59 PM, Samuel Audet wrote:
> FWIW, I think the core issue comes from the fact that the Java platform is
> unable to take responsibility for any of the native code, so what about a
> way to define some sort of "environment", for the lack of a better word.
> For example, when the code gets loaded on Android, iOS, or WebAssembly, we
> already know that the native code is going to run in a sandbox, so we
> shouldn't have to specify any flags because executing any native code is
> already considered as "safe" by the native platform. Maybe not as "safe" as
> Java code, but that's not the point, the point is that maybe the decision
> should be deferred to the underlying platform? Thoughts?
> 
> Samuel
> 
> On Tue, Sep 21, 2021, 19:20 Maurizio Cimadamore  wrote:
> 
>> I'll zoom in on this issue, because I think it's the one we need to
>> understand the most. For the record, I don't despise all code at all -
>> but I also think that the position of "must be run with a clean `java
>> -jar`, no extra arguments" is (while a good goal) a bit unrealistic.
>> Most of the real world Java application I've seen all need to drop in
>> some extra command line option (e.g. -Xmx), but I think your problem
>> here is more specific than "just add a command line option" - the
>> problem is adding an option that is only supported on _some_ JDKs (see
>> below).
>>
>> On 21/09/2021 03:51, Glavo wrote:
>>> In my original plan, I would convert it into a multi-release jar.
>>> On the Java platform available to Panama, I will use Panama to call
>>> the system API. This will allow me to adapt to more platforms (e.g.
>>> mips64el).
>>> Panama's restrictions made me abandon this scheme. Because
>>> I can't execute it on any version of Java platform with a
>> unified command.
>>
>> I think this is the real important point here. I'd like to understand
>> more about this use case. Do you have an executable AND multi-release
>> JAR? Is it an application that you are developing? Do you want that
>> application to be just executed using `java -jar foo.jar`? Does your
>> application have a launcher to trigger the `java -jar` command?
>>
>> Please walk me through your use case a bit, and please let's keep the
>> conversation focussed - arguing over general safety principles is not
>> very helpful, when the real problem is, I suspect, driven by something
>> much more concrete.
>>
>> Thanks
>> Maurizio
>>
> 


From jbhateja at openjdk.java.net  Wed Sep 22 04:29:17 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Wed, 22 Sep 2021 04:29:17 GMT
Subject: [vectorIntrinsics+mask] RFR: 8273949: Intrinsic creation for
 VectorMask.toLong operation. [v3]
In-Reply-To: <6BV8s5FyH0GDcaUreJfsaFuGcvcZZmcFSZ1-HujLgIo=.e981bc14-143e-4c2b-9dd0-a7cfb941d6f5@github.com>
References: 
 <6BV8s5FyH0GDcaUreJfsaFuGcvcZZmcFSZ1-HujLgIo=.e981bc14-143e-4c2b-9dd0-a7cfb941d6f5@github.com>
Message-ID: <-gRIMFAqNO_Dp_LhR4NKmXglCtp9hJ3MEfLbryHdnHY=.23a465c2-523c-4ad0-a276-a10925467d17@github.com>

On Mon, 20 Sep 2021 19:28:40 GMT, Jatin Bhateja  wrote:

>> Summary of changes:
>> - Intrinsification of VectorMask.toLong() API.
>> - Supports inline expansion for both AVX512 and non-AVX512 targets.
>> - Used toLong() API to optimize existing Java API implementation of VectorMask.laneIsSet() operation.
>> 
>> Following performance number are generated using JMH benchmark modification included with the patch.
>> 
>> System:  Intel(R) Xeon(R) Platinum 8280 CPU @ 2.70GHz (Cascade Lake Server 28C 2S)
>> 
>> Benchmark | VECSIZE | Baseline Score (ops/ms) | With Opt (ops/ms) | Gain Ratio
>> -- | -- | -- | -- | --
>> MaskQueryOperationsBenchmark.testToLongByte | 128 | 90451.424 | 346941.379 | 3.835665196
>> MaskQueryOperationsBenchmark.testToLongByte | 256 | 63127.764 | 338331.425 | 5.359471072
>> MaskQueryOperationsBenchmark.testToLongByte | 512 | 40543.264 | 313836.333 | 7.740776199
>> MaskQueryOperationsBenchmark.testToLongLong | 128 | 171989.714 | 152872.758 | 0.88884826
>> MaskQueryOperationsBenchmark.testToLongLong | 256 | 164702.273 | 324794.578 | 1.972010295
>> MaskQueryOperationsBenchmark.testToLongLong | 512 | 122667.916 | 318060.096 | 2.59285481
>> MaskQueryOperationsBenchmark.testToLongShort | 128 | 122656.408 | 346691.082 | 2.826522378
>> MaskQueryOperationsBenchmark.testToLongShort | 256 | 96838.555 | 360909.28 | 3.726917239
>> MaskQueryOperationsBenchmark.testToLongShort | 512 | 63119.009 | 313075.159 | 4.960077225
>> MaskQueryOperationsBenchmark.testToLonglong | 128 | 180855.623 | 324620.433 | 1.794914792
>> MaskQueryOperationsBenchmark.testToLonglong | 256 | 122705.631 | 324315.916 | 2.643040204
>> MaskQueryOperationsBenchmark.testToLonglong | 512 | 90396.687 | 324318.095 | 3.58772103
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8273949: Review comments resolution.

@nsjian , kindly check the IR change, it may need some change in AARCH64 backend since now VectorStoreMask is not being inserted while connecting mask generating node to mask operation node. This saves redundant store mask operation if target supports predicate registers.

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

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

From jbhateja at openjdk.java.net  Wed Sep 22 05:53:25 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Wed, 22 Sep 2021 05:53:25 GMT
Subject: [vectorIntrinsics+mask] RFR: 8273949: Intrinsic creation for
 VectorMask.toLong operation. [v4]
In-Reply-To: 
References: 
Message-ID: 

> Summary of changes:
> - Intrinsification of VectorMask.toLong() API.
> - Supports inline expansion for both AVX512 and non-AVX512 targets.
> - Used toLong() API to optimize existing Java API implementation of VectorMask.laneIsSet() operation.
> 
> Following performance number are generated using JMH benchmark modification included with the patch.
> 
> System:  Intel(R) Xeon(R) Platinum 8280 CPU @ 2.70GHz (Cascade Lake Server 28C 2S)
> 
> Benchmark | VECSIZE | Baseline Score (ops/ms) | With Opt (ops/ms) | Gain Ratio
> -- | -- | -- | -- | --
> MaskQueryOperationsBenchmark.testToLongByte | 128 | 90451.424 | 346941.379 | 3.835665196
> MaskQueryOperationsBenchmark.testToLongByte | 256 | 63127.764 | 338331.425 | 5.359471072
> MaskQueryOperationsBenchmark.testToLongByte | 512 | 40543.264 | 313836.333 | 7.740776199
> MaskQueryOperationsBenchmark.testToLongLong | 128 | 171989.714 | 152872.758 | 0.88884826
> MaskQueryOperationsBenchmark.testToLongLong | 256 | 164702.273 | 324794.578 | 1.972010295
> MaskQueryOperationsBenchmark.testToLongLong | 512 | 122667.916 | 318060.096 | 2.59285481
> MaskQueryOperationsBenchmark.testToLongShort | 128 | 122656.408 | 346691.082 | 2.826522378
> MaskQueryOperationsBenchmark.testToLongShort | 256 | 96838.555 | 360909.28 | 3.726917239
> MaskQueryOperationsBenchmark.testToLongShort | 512 | 63119.009 | 313075.159 | 4.960077225
> MaskQueryOperationsBenchmark.testToLonglong | 128 | 180855.623 | 324620.433 | 1.794914792
> MaskQueryOperationsBenchmark.testToLonglong | 256 | 122705.631 | 324315.916 | 2.643040204
> MaskQueryOperationsBenchmark.testToLonglong | 512 | 90396.687 | 324318.095 | 3.58772103

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  8273949: Review comments resolution.

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

Changes:
  - all: https://git.openjdk.java.net/panama-vector/pull/126/files
  - new: https://git.openjdk.java.net/panama-vector/pull/126/files/6b38d057..f1816ce8

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

  Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/panama-vector/pull/126.diff
  Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/126/head:pull/126

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

From jbhateja at openjdk.java.net  Wed Sep 22 08:21:57 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Wed, 22 Sep 2021 08:21:57 GMT
Subject: [vectorIntrinsics+mask] RFR: 8273949: Intrinsic creation for
 VectorMask.toLong operation. [v3]
In-Reply-To: 
References: 
 <6BV8s5FyH0GDcaUreJfsaFuGcvcZZmcFSZ1-HujLgIo=.e981bc14-143e-4c2b-9dd0-a7cfb941d6f5@github.com>
 
Message-ID: 

On Tue, 21 Sep 2021 17:14:30 GMT, Sandhya Viswanathan  wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8273949: Review comments resolution.
>
> src/hotspot/cpu/x86/x86.ad line 8663:
> 
>> 8661: %}
>> 8662: 
>> 8663: instruct vmask_tolong_evex(rRegL dst, kReg mask) %{
> 
> The instructs with rRegL should be in ifdef _LP64.

Its already covered under _LP64

> src/hotspot/share/prims/vectorSupport.cpp line 441:
> 
>> 439:         case T_FLOAT: // fall-through
>> 440:         case T_DOUBLE: return Op_VectorMaskToLong;
>> 441:         default: fatal("MASK_TRUECOUNT: %s", type2name(bt));
> 
> MASK_TOLONG here? Also break is missing.

This is consistent with other case statements.

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

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

From maurizio.cimadamore at oracle.com  Wed Sep 22 09:18:08 2021
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Wed, 22 Sep 2021 10:18:08 +0100
Subject: Will we need to use the --enable-native-access option to enable
 JNI in the future?
In-Reply-To: <6c4f7554-4d9d-e094-46b5-a6c2c9d7f159@gmail.com>
References: 
 
 
 
 
 <18b80809-54b1-1b40-e5f2-a2b1a4e10711@oracle.com>
 
 <2eb43d4c-6eee-39f7-877b-d98681773520@oracle.com>
 
 <6c4f7554-4d9d-e094-46b5-a6c2c9d7f159@gmail.com>
Message-ID: 


On 22/09/2021 04:19, Samuel Audet wrote:
> I don't feel this is something that should be set on a per-application 
> basis. I really do mean something like an "environment", like an 
> environment variable. Sure, we can ask users to set JAVA_TOOL_OPTIONS 
> and what not, but that is not user friendly. It's not for end users. 
> Those users should be able to tell the application whether it's OK to 
> run that code or not. For example, in the case of Android, etc, we can 
> assume the default to be "yes", but for some desktop application, the 
> end users could be instructed to go set a checkbox somewhere in the 
> settings of the JDK.
>
> This, incidentally, would satisfy the needs of applications such as 
> the one Glavo describes, no?
>
> In any case, please explain why this kind of approach is not being 
> considered!

The reasons why this is not considered are similar to why we don't just 
have a single kill switch to enable _all_ native restricted methods in 
_any_ modules. We could do something like --enable-preview, a single 
flag which enable native access for everything. This would also make 
Glavo use case work (well, plus some trick to ignore unrecognized 
options for older versions, but we have 
-XX:+IgnoreUnrecognizedVMOptions). The problem with this (and other 
blanket approaches) is that the application packager has no way to be 
notified when _something_ changes in the dependencies of his/her 
application.

I think smartphones provide a good analogy: you grant permission on an 
application basis; e.g. when you install app X, you are asked whether 
you are ok with X accessing your storage and camera. What you are 
proposing is that, instead, we have a global setting in our devices 
which say "please give every app all the access they want and never 
bother me with this again". Such a model, while certainly minimizing 
friction, is surely bound to create issues in the long run.

I think there were many interesting point in Glavo's email - e.g. naming 
of the option could be misleading and over promising, the fact that if 
access is granted to module A and A depends on B, we also have to grant 
access to B as well, etc.

But having a global "sudo please let me do what I want" switch was never 
suggested, and is not a direction we'd like to take, sorry.

Maurizio


>
> Samuel
>
> On 9/21/21 8:59 PM, Samuel Audet wrote:
>> FWIW, I think the core issue comes from the fact that the Java 
>> platform is
>> unable to take responsibility for any of the native code, so what 
>> about a
>> way to define some sort of "environment", for the lack of a better word.
>> For example, when the code gets loaded on Android, iOS, or 
>> WebAssembly, we
>> already know that the native code is going to run in a sandbox, so we
>> shouldn't have to specify any flags because executing any native code is
>> already considered as "safe" by the native platform. Maybe not as 
>> "safe" as
>> Java code, but that's not the point, the point is that maybe the 
>> decision
>> should be deferred to the underlying platform? Thoughts?
>>
>> Samuel
>>
>> On Tue, Sep 21, 2021, 19:20 Maurizio Cimadamore 
>>  wrote:
>>
>>> I'll zoom in on this issue, because I think it's the one we need to
>>> understand the most. For the record, I don't despise all code at all -
>>> but I also think that the position of "must be run with a clean `java
>>> -jar`, no extra arguments" is (while a good goal) a bit unrealistic.
>>> Most of the real world Java application I've seen all need to drop in
>>> some extra command line option (e.g. -Xmx), but I think your problem
>>> here is more specific than "just add a command line option" - the
>>> problem is adding an option that is only supported on _some_ JDKs (see
>>> below).
>>>
>>> On 21/09/2021 03:51, Glavo wrote:
>>>> In my original plan, I would convert it into a multi-release jar.
>>>> On the Java platform available to Panama, I will use Panama to call
>>>> the system API. This will allow me to adapt to more platforms (e.g.
>>>> mips64el).
>>>> Panama's restrictions made me abandon this scheme. Because
>>>> I can't execute it on any version of Java platform with a
>>> unified command.
>>>
>>> I think this is the real important point here. I'd like to understand
>>> more about this use case. Do you have an executable AND multi-release
>>> JAR? Is it an application that you are developing? Do you want that
>>> application to be just executed using `java -jar foo.jar`? Does your
>>> application have a launcher to trigger the `java -jar` command?
>>>
>>> Please walk me through your use case a bit, and please let's keep the
>>> conversation focussed - arguing over general safety principles is not
>>> very helpful, when the real problem is, I suspect, driven by something
>>> much more concrete.
>>>
>>> Thanks
>>> Maurizio
>>>
>>
>

From mcimadamore at openjdk.java.net  Wed Sep 22 09:36:01 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 22 Sep 2021 09:36:01 GMT
Subject: [foreign-memaccess+abi] RFR: 8273905: Foreign API refresh [v11]
In-Reply-To: 
References: 
Message-ID: 

> As outlined in [1], there are areas of the foreign API we'd like to improve upon, such as:
> 
> * dereference: there is a mismatch between API points which create segments (which take a layout) and dereference API points, which do not take layouts
> 
> * role of `MemoryAddress`: in Java 17, `MemoryAddress` has become a stateful carrier, which is attached to a scope. This is inconvenient, as in most cases, a memory address is just a raw pointer that arises when interacting with native code.
> 
> * resource scopes: the API for scopes has too many flavors to pick from, many of which overlap. The fact that scopes and segment allocators are unrelated forces clients to introduce ad hoc conversions from scopes to allocators, and library developers to add overloads. Finally, the API for acquiring scopes doesn't work well with try-with-resources, and could also be simplified. 
> 
> I will add separate comments to explain how the API has changed to resolve the above issues.
> 
> [1] - https://mail.openjdk.java.net/pipermail/panama-dev/2021-September/014946.html

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

  * Add scope check to UpcallStub::address
  * Beefed up SafeFunctionAccessTest

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

Changes:
  - all: https://git.openjdk.java.net/panama-foreign/pull/576/files
  - new: https://git.openjdk.java.net/panama-foreign/pull/576/files/162cb936..4ab40717

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=576&range=10
 - incr: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=576&range=09-10

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

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

From njian at openjdk.java.net  Wed Sep 22 10:13:30 2021
From: njian at openjdk.java.net (Ningsheng Jian)
Date: Wed, 22 Sep 2021 10:13:30 GMT
Subject: [vectorIntrinsics+mask] RFR: 8273949: Intrinsic creation for
 VectorMask.toLong operation. [v3]
In-Reply-To: <-gRIMFAqNO_Dp_LhR4NKmXglCtp9hJ3MEfLbryHdnHY=.23a465c2-523c-4ad0-a276-a10925467d17@github.com>
References: 
 <6BV8s5FyH0GDcaUreJfsaFuGcvcZZmcFSZ1-HujLgIo=.e981bc14-143e-4c2b-9dd0-a7cfb941d6f5@github.com>
 <-gRIMFAqNO_Dp_LhR4NKmXglCtp9hJ3MEfLbryHdnHY=.23a465c2-523c-4ad0-a276-a10925467d17@github.com>
Message-ID: 

On Wed, 22 Sep 2021 04:25:44 GMT, Jatin Bhateja  wrote:

> @nsjian , kindly check the IR change, it may need some change in AARCH64 backend since now VectorStoreMask is not being inserted while connecting mask generating node to mask operation node. This saves redundant store mask operation if target supports predicate registers.

Hi @jatin-bhateja , thanks for the heads-up. The VectorMaskOp connection change looks reasonable. We will update SVE backend later.

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

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

From sundar at openjdk.java.net  Wed Sep 22 10:22:55 2021
From: sundar at openjdk.java.net (Athijegannathan Sundararajan)
Date: Wed, 22 Sep 2021 10:22:55 GMT
Subject: [foreign-memaccess+abi] RFR: 8273905: Foreign API refresh [v11]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 22 Sep 2021 09:36:01 GMT, Maurizio Cimadamore  wrote:

>> As outlined in [1], there are areas of the foreign API we'd like to improve upon, such as:
>> 
>> * dereference: there is a mismatch between API points which create segments (which take a layout) and dereference API points, which do not take layouts
>> 
>> * role of `MemoryAddress`: in Java 17, `MemoryAddress` has become a stateful carrier, which is attached to a scope. This is inconvenient, as in most cases, a memory address is just a raw pointer that arises when interacting with native code.
>> 
>> * resource scopes: the API for scopes has too many flavors to pick from, many of which overlap. The fact that scopes and segment allocators are unrelated forces clients to introduce ad hoc conversions from scopes to allocators, and library developers to add overloads. Finally, the API for acquiring scopes doesn't work well with try-with-resources, and could also be simplified. 
>> 
>> I will add separate comments to explain how the API has changed to resolve the above issues.
>> 
>> [1] - https://mail.openjdk.java.net/pipermail/panama-dev/2021-September/014946.html
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   * Add scope check to UpcallStub::address
>   * Beefed up SafeFunctionAccessTest

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/VaList.java line 1:

> 1: package jdk.incubator.foreign;

copyright header is missing

test/micro/org/openjdk/bench/jdk/incubator/foreign/CLayouts.java line 1:

> 1: package org.openjdk.bench.jdk.incubator.foreign;

copyright header missing

test/micro/org/openjdk/bench/jdk/incubator/foreign/LoopOverNewHeap.java line 2:

> 1: /*
> 2:  * Copyright (c) 2020, Oracle and/or its affiliates. All rights reserved.

new file. (c) year 2021

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

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

From mcimadamore at openjdk.java.net  Wed Sep 22 11:19:26 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 22 Sep 2021 11:19:26 GMT
Subject: [foreign-memaccess+abi] RFR: 8273905: Foreign API refresh [v12]
In-Reply-To: 
References: 
Message-ID: 

> As outlined in [1], there are areas of the foreign API we'd like to improve upon, such as:
> 
> * dereference: there is a mismatch between API points which create segments (which take a layout) and dereference API points, which do not take layouts
> 
> * role of `MemoryAddress`: in Java 17, `MemoryAddress` has become a stateful carrier, which is attached to a scope. This is inconvenient, as in most cases, a memory address is just a raw pointer that arises when interacting with native code.
> 
> * resource scopes: the API for scopes has too many flavors to pick from, many of which overlap. The fact that scopes and segment allocators are unrelated forces clients to introduce ad hoc conversions from scopes to allocators, and library developers to add overloads. Finally, the API for acquiring scopes doesn't work well with try-with-resources, and could also be simplified. 
> 
> I will add separate comments to explain how the API has changed to resolve the above issues.
> 
> [1] - https://mail.openjdk.java.net/pipermail/panama-dev/2021-September/014946.html

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

  Add/fix copyright headers

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

Changes:
  - all: https://git.openjdk.java.net/panama-foreign/pull/576/files
  - new: https://git.openjdk.java.net/panama-foreign/pull/576/files/4ab40717..51de1859

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=576&range=11
 - incr: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=576&range=10-11

  Stats: 49 lines in 3 files changed: 48 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/panama-foreign/pull/576.diff
  Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/576/head:pull/576

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

From duke at openjdk.java.net  Wed Sep 22 15:19:19 2021
From: duke at openjdk.java.net (duke)
Date: Wed, 22 Sep 2021 15:19:19 GMT
Subject: git: openjdk/panama-foreign: foreign-jextract: 2 new changesets
Message-ID: 

Changeset: 831e75bc
Author:    Maurizio Cimadamore 
Date:      2021-09-22 15:17:25 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/831e75bcb2eff79be1b2fb743aea9a2a2560cbd8

8273905: Foreign API refresh

Reviewed-by: uschindler, psandoz

! src/java.base/share/classes/java/lang/Module.java
! src/java.base/share/classes/java/nio/Buffer.java
! src/java.base/share/classes/jdk/internal/access/JavaNioAccess.java
! src/java.base/share/classes/jdk/internal/misc/X-ScopedMemoryAccess.java.template
! src/java.base/share/classes/jdk/internal/reflect/Reflection.java
! src/java.base/share/classes/sun/nio/ch/IOUtil.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/FunctionDescriptor.java
! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/GroupLayout.java
- src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemoryAccess.java
! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemoryAddress.java
- src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemoryCopy.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/PaddingLayout.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/SymbolLookup.java
+ src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/VaList.java
! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/ValueLayout.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/CABI.java
! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/ConfinedScope.java
! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/LayoutPath.java
! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/MemoryAddressImpl.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/SystemLookup.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/BufferLayout.java
! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/CallingSequenceBuilder.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/UpcallHandler.java
! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/UpcallStubs.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
! 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/sysv/TypeClass.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/TypeClass.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/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/TestArrayCopy.java
! test/jdk/java/foreign/TestArrays.java
! test/jdk/java/foreign/TestByteBuffer.java
- test/jdk/java/foreign/TestCircularInit1.java
- test/jdk/java/foreign/TestCircularInit2.java
! test/jdk/java/foreign/TestCondy.java
- test/jdk/java/foreign/TestCopyFrom.java
! test/jdk/java/foreign/TestDowncall.java
! test/jdk/java/foreign/TestFree.java
! test/jdk/java/foreign/TestFunctionDescriptor.java
! test/jdk/java/foreign/TestHandshake.java
! test/jdk/java/foreign/TestIllegalLink.java
! test/jdk/java/foreign/TestIntrinsics.java
- test/jdk/java/foreign/TestLayoutAttributes.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/TestMemoryAccess.java
+ test/jdk/java/foreign/TestMemoryAccessInstance.java
- test/jdk/java/foreign/TestMemoryAccessStatics.java
! test/jdk/java/foreign/TestMemoryAlignment.java
- test/jdk/java/foreign/TestMemoryCopy.java
+ test/jdk/java/foreign/TestMemoryDereference.java
! test/jdk/java/foreign/TestMemoryHandleAsUnsigned.java
! test/jdk/java/foreign/TestMismatch.java
! test/jdk/java/foreign/TestNULLAddress.java
! test/jdk/java/foreign/TestNative.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/TestSegmentCopy.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/TestStringEncoding.java
! test/jdk/java/foreign/TestSymbolLookup.java
! test/jdk/java/foreign/TestTypeAccess.java
! test/jdk/java/foreign/TestUnsupportedPlatform.java
! test/jdk/java/foreign/TestUpcall.java
! test/jdk/java/foreign/TestUpcallException.java
! test/jdk/java/foreign/TestUpcallHighArity.java
! test/jdk/java/foreign/TestUpcallStructScope.java
! test/jdk/java/foreign/TestVarArgs.java
! test/jdk/java/foreign/TestVarHandleCombinators.java
! test/jdk/java/foreign/ThrowingUpcall.java
! test/jdk/java/foreign/callarranger/TestAarch64CallArranger.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/org/openjdk/foreigntest/PanamaMainUnnamedModule.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/invoker_module/handle/invoker/MethodHandleInvoker.java
! test/jdk/java/foreign/handles/lookup_module/handle/lookup/MethodHandleLookup.java
! test/jdk/java/foreign/malloc/TestMixedMallocFree.java
! test/jdk/java/foreign/stackwalk/TestAsyncStackWalk.java
! test/jdk/java/foreign/stackwalk/TestStackWalk.java
! test/jdk/java/foreign/valist/VaListTest.java
! test/jdk/java/foreign/virtual/TestVirtualCalls.java
! test/jdk/java/util/stream/test/org/openjdk/tests/java/util/stream/SegmentTestDataProvider.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/CLayouts.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/LoopOverNewHeap.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/LoopOverPollutedBuffer.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/QSort.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/TestLoadBytes.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/points/support/PanamaPoint.java
! test/micro/org/openjdk/bench/jdk/incubator/vector/TestLoadStoreBytes.java
! test/micro/org/openjdk/bench/jdk/incubator/vector/TestLoadStoreShort.java

Changeset: 1ac1abfd
Author:    duke 
Date:      2021-09-22 15:18:33 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/1ac1abfd4d2148c11c1654ff226895d83c36ba2b

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



From mcimadamore at openjdk.java.net  Wed Sep 22 15:21:11 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 22 Sep 2021 15:21:11 GMT
Subject: [foreign-memaccess+abi] Integrated: 8273905: Foreign API refresh
In-Reply-To: 
References: 
Message-ID: 

On Thu, 16 Sep 2021 16:39:11 GMT, Maurizio Cimadamore  wrote:

> As outlined in [1], there are areas of the foreign API we'd like to improve upon, such as:
> 
> * dereference: there is a mismatch between API points which create segments (which take a layout) and dereference API points, which do not take layouts
> 
> * role of `MemoryAddress`: in Java 17, `MemoryAddress` has become a stateful carrier, which is attached to a scope. This is inconvenient, as in most cases, a memory address is just a raw pointer that arises when interacting with native code.
> 
> * resource scopes: the API for scopes has too many flavors to pick from, many of which overlap. The fact that scopes and segment allocators are unrelated forces clients to introduce ad hoc conversions from scopes to allocators, and library developers to add overloads. Finally, the API for acquiring scopes doesn't work well with try-with-resources, and could also be simplified. 
> 
> I will add separate comments to explain how the API has changed to resolve the above issues.
> 
> [1] - https://mail.openjdk.java.net/pipermail/panama-dev/2021-September/014946.html

This pull request has now been integrated.

Changeset: 831e75bc
Author:    Maurizio Cimadamore 
URL:       https://git.openjdk.java.net/panama-foreign/commit/831e75bcb2eff79be1b2fb743aea9a2a2560cbd8
Stats:     13419 lines in 164 files changed: 4841 ins; 6309 del; 2269 mod

8273905: Foreign API refresh

Reviewed-by: uschindler, psandoz

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

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

From mcimadamore at openjdk.java.net  Wed Sep 22 15:48:54 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 22 Sep 2021 15:48:54 GMT
Subject: [foreign-jextract] RFR: 8274155 Foreign API refresh - jextract update
Message-ID: 

These are the jextract changes for the recent refresh of the Foreign Memory Access/Foreign Linker API. The biggest change in this API refresh comes from the removal of layout attributes. Jextract used to store several information in the form of layouts attributes. After some analysis, it turned out that in all cases, the use of layout attributes was not necessary, and it was really driven by the fact that jextract was, in certain places, using `MemoryLayout` as its main internal representation, instead of using the more flexible `Declaration`/`Type` APIs. Unfortunately, updating `RecordLayoutComputer` to work on `Declaration` rather than `MemoryLayout` caused changes in several part of the jextract parsing frontend.

Other minor changes were required, to adjust jextract to the new API changes - but most of these are small. I've dropped several now redundant overloads (so the size of the generated bindings should be smaller). There's also an additional piece of code which is used to emit typedef for common C primitive types such as `C_INT` and the likes (since the layouts for these are no longer in `CLinker`).

The test changes are mostly trivial updates to use the new API.

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

Commit messages:
 - Remove commented lines
 - Merge branch 'foreign-jextract' into foreign-finalize+jextract
 - Tweak test after removal of MemoryAddress::freeMemory
 - Add/fix copyright headers
 - * Add scope check to UpcallStub::address
 - * Add implNote on `ResourceScope#keepAlive` documenting the maximum number of keep alive requests
 - * Drop more unused imports
 - Fix javadoc for `MemoryAddress::setUtf8String`
 - Drop `MemoryAddress::freeMemory`/`MemoryAddress::allocateMemory` leftovers
 - Clarify javadoc of indexed getters/setters in `MemorySegment`/`MemoryAddress`
 - ... and 5 more: https://git.openjdk.java.net/panama-foreign/compare/1ac1abfd...9976b842

Changes: https://git.openjdk.java.net/panama-foreign/pull/577/files
 Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=577&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274155
  Stats: 1545 lines in 80 files changed: 518 ins; 675 del; 352 mod
  Patch: https://git.openjdk.java.net/panama-foreign/pull/577.diff
  Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/577/head:pull/577

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

From mcimadamore at openjdk.java.net  Wed Sep 22 15:48:55 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 22 Sep 2021 15:48:55 GMT
Subject: [foreign-jextract] RFR: 8274155 Foreign API refresh - jextract
 update
In-Reply-To: 
References: 
Message-ID: <_GGOqeR9dem4GrQvQ2rH0VPduIElTm0ssZRPZzZWSCc=.0f645c05-f495-472a-9782-7ed233b833a8@github.com>

On Wed, 22 Sep 2021 15:31:43 GMT, Maurizio Cimadamore  wrote:

> These are the jextract changes for the recent refresh of the Foreign Memory Access/Foreign Linker API. The biggest change in this API refresh comes from the removal of layout attributes. Jextract used to store several information in the form of layouts attributes. After some analysis, it turned out that in all cases, the use of layout attributes was not necessary, and it was really driven by the fact that jextract was, in certain places, using `MemoryLayout` as its main internal representation, instead of using the more flexible `Declaration`/`Type` APIs. Unfortunately, updating `RecordLayoutComputer` to work on `Declaration` rather than `MemoryLayout` caused changes in several part of the jextract parsing frontend.
> 
> Other minor changes were required, to adjust jextract to the new API changes - but most of these are small. I've dropped several now redundant overloads (so the size of the generated bindings should be smaller). There's also an additional piece of code which is used to emit typedef for common C primitive types such as `C_INT` and the likes (since the layouts for these are no longer in `CLinker`).
> 
> The test changes are mostly trivial updates to use the new API.

Warning: there's a lot of changes in the generated libclang bindings, as I had to make these compatible with the new API. I basically bulk replaced code to use new API idioms using regular expressions, so the changes in these classes are not very interesting (as long as the thing still builds). We should probably regenerate the bindings after we're done, and clean them up.

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

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

From sviswanathan at openjdk.java.net  Wed Sep 22 16:20:24 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Wed, 22 Sep 2021 16:20:24 GMT
Subject: [vectorIntrinsics+mask] RFR: 8273949: Intrinsic creation for
 VectorMask.toLong operation. [v4]
In-Reply-To: 
References: 
 
Message-ID: <4mJN7V_6BkrL2xlY3rTfrAPiJk10cbqtWZhVIdCYT7Q=.458fc0f9-2f42-4aed-bc6d-9e824c1cd7db@github.com>

On Wed, 22 Sep 2021 05:53:25 GMT, Jatin Bhateja  wrote:

>> Summary of changes:
>> - Intrinsification of VectorMask.toLong() API.
>> - Supports inline expansion for both AVX512 and non-AVX512 targets.
>> - Used toLong() API to optimize existing Java API implementation of VectorMask.laneIsSet() operation.
>> 
>> Following performance number are generated using JMH benchmark modification included with the patch.
>> 
>> System:  Intel(R) Xeon(R) Platinum 8280 CPU @ 2.70GHz (Cascade Lake Server 28C 2S)
>> 
>> Benchmark | VECSIZE | Baseline Score (ops/ms) | With Opt (ops/ms) | Gain Ratio
>> -- | -- | -- | -- | --
>> MaskQueryOperationsBenchmark.testToLongByte | 128 | 90451.424 | 346941.379 | 3.835665196
>> MaskQueryOperationsBenchmark.testToLongByte | 256 | 63127.764 | 338331.425 | 5.359471072
>> MaskQueryOperationsBenchmark.testToLongByte | 512 | 40543.264 | 313836.333 | 7.740776199
>> MaskQueryOperationsBenchmark.testToLongLong | 128 | 171989.714 | 152872.758 | 0.88884826
>> MaskQueryOperationsBenchmark.testToLongLong | 256 | 164702.273 | 324794.578 | 1.972010295
>> MaskQueryOperationsBenchmark.testToLongLong | 512 | 122667.916 | 318060.096 | 2.59285481
>> MaskQueryOperationsBenchmark.testToLongShort | 128 | 122656.408 | 346691.082 | 2.826522378
>> MaskQueryOperationsBenchmark.testToLongShort | 256 | 96838.555 | 360909.28 | 3.726917239
>> MaskQueryOperationsBenchmark.testToLongShort | 512 | 63119.009 | 313075.159 | 4.960077225
>> MaskQueryOperationsBenchmark.testToLonglong | 128 | 180855.623 | 324620.433 | 1.794914792
>> MaskQueryOperationsBenchmark.testToLonglong | 256 | 122705.631 | 324315.916 | 2.643040204
>> MaskQueryOperationsBenchmark.testToLonglong | 512 | 90396.687 | 324318.095 | 3.58772103
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8273949: Review comments resolution.

Only one comment on cut and paste mistake in error message, Please fix that. Other than that the patch looks good. No need for re-rereview.

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

Marked as reviewed by sviswanathan (Committer).

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

From sviswanathan at openjdk.java.net  Wed Sep 22 16:20:26 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Wed, 22 Sep 2021 16:20:26 GMT
Subject: [vectorIntrinsics+mask] RFR: 8273949: Intrinsic creation for
 VectorMask.toLong operation. [v3]
In-Reply-To: 
References: 
 <6BV8s5FyH0GDcaUreJfsaFuGcvcZZmcFSZ1-HujLgIo=.e981bc14-143e-4c2b-9dd0-a7cfb941d6f5@github.com>
 
 
Message-ID: 

On Wed, 22 Sep 2021 08:18:09 GMT, Jatin Bhateja  wrote:

>> src/hotspot/share/prims/vectorSupport.cpp line 441:
>> 
>>> 439:         case T_FLOAT: // fall-through
>>> 440:         case T_DOUBLE: return Op_VectorMaskToLong;
>>> 441:         default: fatal("MASK_TRUECOUNT: %s", type2name(bt));
>> 
>> MASK_TOLONG here? Also break is missing.
>
> This is consistent with other case statements.

default: fatal("MASK_TRUECOUNT: %s", type2name(bt));
should refer to MASK_TOLONG.

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

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

From eliu at openjdk.java.net  Thu Sep 23 01:01:00 2021
From: eliu at openjdk.java.net (Eric Liu)
Date: Thu, 23 Sep 2021 01:01:00 GMT
Subject: [vectorIntrinsics+mask] RFR: 8273949: Intrinsic creation for
 VectorMask.toLong operation. [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 22 Sep 2021 05:53:25 GMT, Jatin Bhateja  wrote:

>> Summary of changes:
>> - Intrinsification of VectorMask.toLong() API.
>> - Supports inline expansion for both AVX512 and non-AVX512 targets.
>> - Used toLong() API to optimize existing Java API implementation of VectorMask.laneIsSet() operation.
>> 
>> Following performance number are generated using JMH benchmark modification included with the patch.
>> 
>> System:  Intel(R) Xeon(R) Platinum 8280 CPU @ 2.70GHz (Cascade Lake Server 28C 2S)
>> 
>> Benchmark | VECSIZE | Baseline Score (ops/ms) | With Opt (ops/ms) | Gain Ratio
>> -- | -- | -- | -- | --
>> MaskQueryOperationsBenchmark.testToLongByte | 128 | 90451.424 | 346941.379 | 3.835665196
>> MaskQueryOperationsBenchmark.testToLongByte | 256 | 63127.764 | 338331.425 | 5.359471072
>> MaskQueryOperationsBenchmark.testToLongByte | 512 | 40543.264 | 313836.333 | 7.740776199
>> MaskQueryOperationsBenchmark.testToLongLong | 128 | 171989.714 | 152872.758 | 0.88884826
>> MaskQueryOperationsBenchmark.testToLongLong | 256 | 164702.273 | 324794.578 | 1.972010295
>> MaskQueryOperationsBenchmark.testToLongLong | 512 | 122667.916 | 318060.096 | 2.59285481
>> MaskQueryOperationsBenchmark.testToLongShort | 128 | 122656.408 | 346691.082 | 2.826522378
>> MaskQueryOperationsBenchmark.testToLongShort | 256 | 96838.555 | 360909.28 | 3.726917239
>> MaskQueryOperationsBenchmark.testToLongShort | 512 | 63119.009 | 313075.159 | 4.960077225
>> MaskQueryOperationsBenchmark.testToLonglong | 128 | 180855.623 | 324620.433 | 1.794914792
>> MaskQueryOperationsBenchmark.testToLonglong | 256 | 122705.631 | 324315.916 | 2.643040204
>> MaskQueryOperationsBenchmark.testToLonglong | 512 | 90396.687 | 324318.095 | 3.58772103
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8273949: Review comments resolution.

LGTM. 

Just the comment is mismatched.
``` java
// 
// long maskReductionCoerced(int oper, Class maskClass, Class elemClass,
//                          int length, M m, VectorMaskOp defaultImpl)
bool LibraryCallKit::inline_vector_mask_operation() {

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

Marked as reviewed by eliu (Committer).

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

From jbhateja at openjdk.java.net  Thu Sep 23 03:10:01 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Thu, 23 Sep 2021 03:10:01 GMT
Subject: [vectorIntrinsics+mask] RFR: 8273949: Intrinsic creation for
 VectorMask.toLong operation. [v5]
In-Reply-To: 
References: 
Message-ID: 

> Summary of changes:
> - Intrinsification of VectorMask.toLong() API.
> - Supports inline expansion for both AVX512 and non-AVX512 targets.
> - Used toLong() API to optimize existing Java API implementation of VectorMask.laneIsSet() operation.
> 
> Following performance number are generated using JMH benchmark modification included with the patch.
> 
> System:  Intel(R) Xeon(R) Platinum 8280 CPU @ 2.70GHz (Cascade Lake Server 28C 2S)
> 
> Benchmark | VECSIZE | Baseline Score (ops/ms) | With Opt (ops/ms) | Gain Ratio
> -- | -- | -- | -- | --
> MaskQueryOperationsBenchmark.testToLongByte | 128 | 90451.424 | 346941.379 | 3.835665196
> MaskQueryOperationsBenchmark.testToLongByte | 256 | 63127.764 | 338331.425 | 5.359471072
> MaskQueryOperationsBenchmark.testToLongByte | 512 | 40543.264 | 313836.333 | 7.740776199
> MaskQueryOperationsBenchmark.testToLongLong | 128 | 171989.714 | 152872.758 | 0.88884826
> MaskQueryOperationsBenchmark.testToLongLong | 256 | 164702.273 | 324794.578 | 1.972010295
> MaskQueryOperationsBenchmark.testToLongLong | 512 | 122667.916 | 318060.096 | 2.59285481
> MaskQueryOperationsBenchmark.testToLongShort | 128 | 122656.408 | 346691.082 | 2.826522378
> MaskQueryOperationsBenchmark.testToLongShort | 256 | 96838.555 | 360909.28 | 3.726917239
> MaskQueryOperationsBenchmark.testToLongShort | 512 | 63119.009 | 313075.159 | 4.960077225
> MaskQueryOperationsBenchmark.testToLonglong | 128 | 180855.623 | 324620.433 | 1.794914792
> MaskQueryOperationsBenchmark.testToLonglong | 256 | 122705.631 | 324315.916 | 2.643040204
> MaskQueryOperationsBenchmark.testToLonglong | 512 | 90396.687 | 324318.095 | 3.58772103

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  8273949: Resolving synthetic comment.

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

Changes:
  - all: https://git.openjdk.java.net/panama-vector/pull/126/files
  - new: https://git.openjdk.java.net/panama-vector/pull/126/files/f1816ce8..daedf3a8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=126&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=126&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/panama-vector/pull/126.diff
  Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/126/head:pull/126

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

From jbhateja at openjdk.java.net  Thu Sep 23 03:16:38 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Thu, 23 Sep 2021 03:16:38 GMT
Subject: [vectorIntrinsics+mask] RFR: 8273949: Intrinsic creation for
 VectorMask.toLong operation. [v6]
In-Reply-To: 
References: 
Message-ID: 

> Summary of changes:
> - Intrinsification of VectorMask.toLong() API.
> - Supports inline expansion for both AVX512 and non-AVX512 targets.
> - Used toLong() API to optimize existing Java API implementation of VectorMask.laneIsSet() operation.
> 
> Following performance number are generated using JMH benchmark modification included with the patch.
> 
> System:  Intel(R) Xeon(R) Platinum 8280 CPU @ 2.70GHz (Cascade Lake Server 28C 2S)
> 
> Benchmark | VECSIZE | Baseline Score (ops/ms) | With Opt (ops/ms) | Gain Ratio
> -- | -- | -- | -- | --
> MaskQueryOperationsBenchmark.testToLongByte | 128 | 90451.424 | 346941.379 | 3.835665196
> MaskQueryOperationsBenchmark.testToLongByte | 256 | 63127.764 | 338331.425 | 5.359471072
> MaskQueryOperationsBenchmark.testToLongByte | 512 | 40543.264 | 313836.333 | 7.740776199
> MaskQueryOperationsBenchmark.testToLongLong | 128 | 171989.714 | 152872.758 | 0.88884826
> MaskQueryOperationsBenchmark.testToLongLong | 256 | 164702.273 | 324794.578 | 1.972010295
> MaskQueryOperationsBenchmark.testToLongLong | 512 | 122667.916 | 318060.096 | 2.59285481
> MaskQueryOperationsBenchmark.testToLongShort | 128 | 122656.408 | 346691.082 | 2.826522378
> MaskQueryOperationsBenchmark.testToLongShort | 256 | 96838.555 | 360909.28 | 3.726917239
> MaskQueryOperationsBenchmark.testToLongShort | 512 | 63119.009 | 313075.159 | 4.960077225
> MaskQueryOperationsBenchmark.testToLonglong | 128 | 180855.623 | 324620.433 | 1.794914792
> MaskQueryOperationsBenchmark.testToLonglong | 256 | 122705.631 | 324315.916 | 2.643040204
> MaskQueryOperationsBenchmark.testToLonglong | 512 | 90396.687 | 324318.095 | 3.58772103

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  8273949: Resolving synthetic comment.

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

Changes:
  - all: https://git.openjdk.java.net/panama-vector/pull/126/files
  - new: https://git.openjdk.java.net/panama-vector/pull/126/files/daedf3a8..f115417b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=126&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=126&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/panama-vector/pull/126.diff
  Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/126/head:pull/126

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

From jbhateja at openjdk.java.net  Thu Sep 23 03:16:39 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Thu, 23 Sep 2021 03:16:39 GMT
Subject: [vectorIntrinsics+mask] Integrated: 8273949: Intrinsic creation for
 VectorMask.toLong operation.
In-Reply-To: 
References: 
Message-ID: 

On Fri, 17 Sep 2021 19:50:37 GMT, Jatin Bhateja  wrote:

> Summary of changes:
> - Intrinsification of VectorMask.toLong() API.
> - Supports inline expansion for both AVX512 and non-AVX512 targets.
> - Used toLong() API to optimize existing Java API implementation of VectorMask.laneIsSet() operation.
> 
> Following performance number are generated using JMH benchmark modification included with the patch.
> 
> System:  Intel(R) Xeon(R) Platinum 8280 CPU @ 2.70GHz (Cascade Lake Server 28C 2S)
> 
> Benchmark | VECSIZE | Baseline Score (ops/ms) | With Opt (ops/ms) | Gain Ratio
> -- | -- | -- | -- | --
> MaskQueryOperationsBenchmark.testToLongByte | 128 | 90451.424 | 346941.379 | 3.835665196
> MaskQueryOperationsBenchmark.testToLongByte | 256 | 63127.764 | 338331.425 | 5.359471072
> MaskQueryOperationsBenchmark.testToLongByte | 512 | 40543.264 | 313836.333 | 7.740776199
> MaskQueryOperationsBenchmark.testToLongLong | 128 | 171989.714 | 152872.758 | 0.88884826
> MaskQueryOperationsBenchmark.testToLongLong | 256 | 164702.273 | 324794.578 | 1.972010295
> MaskQueryOperationsBenchmark.testToLongLong | 512 | 122667.916 | 318060.096 | 2.59285481
> MaskQueryOperationsBenchmark.testToLongShort | 128 | 122656.408 | 346691.082 | 2.826522378
> MaskQueryOperationsBenchmark.testToLongShort | 256 | 96838.555 | 360909.28 | 3.726917239
> MaskQueryOperationsBenchmark.testToLongShort | 512 | 63119.009 | 313075.159 | 4.960077225
> MaskQueryOperationsBenchmark.testToLonglong | 128 | 180855.623 | 324620.433 | 1.794914792
> MaskQueryOperationsBenchmark.testToLonglong | 256 | 122705.631 | 324315.916 | 2.643040204
> MaskQueryOperationsBenchmark.testToLonglong | 512 | 90396.687 | 324318.095 | 3.58772103

This pull request has now been integrated.

Changeset: 0e7348dd
Author:    Jatin Bhateja 
URL:       https://git.openjdk.java.net/panama-vector/commit/0e7348dd9b81a7310357c600131fb99bd9f74ccd
Stats:     660 lines in 45 files changed: 409 ins; 15 del; 236 mod

8273949: Intrinsic creation for VectorMask.toLong operation.

Reviewed-by: psandoz, sviswanathan, eliu

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

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

From sundar at openjdk.java.net  Thu Sep 23 03:44:07 2021
From: sundar at openjdk.java.net (Athijegannathan Sundararajan)
Date: Thu, 23 Sep 2021 03:44:07 GMT
Subject: [foreign-jextract] RFR: 8274155 Foreign API refresh - jextract
 update
In-Reply-To: 
References: 
Message-ID: 

On Wed, 22 Sep 2021 15:31:43 GMT, Maurizio Cimadamore  wrote:

> These are the jextract changes for the recent refresh of the Foreign Memory Access/Foreign Linker API. The biggest change in this API refresh comes from the removal of layout attributes. Jextract used to store several information in the form of layouts attributes. After some analysis, it turned out that in all cases, the use of layout attributes was not necessary, and it was really driven by the fact that jextract was, in certain places, using `MemoryLayout` as its main internal representation, instead of using the more flexible `Declaration`/`Type` APIs. Unfortunately, updating `RecordLayoutComputer` to work on `Declaration` rather than `MemoryLayout` caused changes in several part of the jextract parsing frontend.
> 
> Other minor changes were required, to adjust jextract to the new API changes - but most of these are small. I've dropped several now redundant overloads (so the size of the generated bindings should be smaller). There's also an additional piece of code which is used to emit typedef for common C primitive types such as `C_INT` and the likes (since the layouts for these are no longer in `CLinker`).
> 
> The test changes are mostly trivial updates to use the new API.

src/jdk.incubator.jextract/share/classes/jdk/internal/clang/libclang/CLayouts.java line 1:

> 1: package jdk.internal.clang.libclang;

copyright header missing

src/jdk.incubator.jextract/share/classes/jdk/internal/clang/libclang/CLayouts.java line 5:

> 3: import jdk.incubator.foreign.ValueLayout;
> 4: 
> 5: public class CLayouts {

could this be an interface?

src/jdk.incubator.jextract/share/classes/jdk/internal/clang/libclang/RuntimeHelper.java line 55:

> 53: import static jdk.internal.clang.libclang.CLayouts.C_LONG_LONG;
> 54: import static jdk.internal.clang.libclang.CLayouts.C_POINTER;
> 55: 

I assume this is transition code. RuntimeHelper is generated. It cannot use handwritten CLayouts interface (unless we plan to generate something similar from jextract every time)

src/jdk.incubator.jextract/share/classes/jdk/internal/clang/libclang/constants$0.java line 36:

> 34: import static jdk.incubator.foreign.CLinker.*;
> 35: import static jdk.internal.clang.libclang.CLayouts.*;
> 36: 

Same comment as for RuntimeHelper. All these are extracted code. Need to figure out how to do CLayouts equivalent from jextract.

src/jdk.incubator.jextract/share/classes/jdk/internal/jextract/impl/ConstantBuilder.java line 332:

> 330:         append("MemorySegment ");
> 331:         append(fieldName);
> 332:         append(" = ResourceScope.newSharedScope().allocateUtf8String(\"");

Do we need shared scope here? or confined scope will do?

src/jdk.incubator.jextract/share/classes/jdk/internal/jextract/impl/OutputFactory.java line 371:

> 369: 
> 370:         if (type instanceof Type.Declared) {
> 371:             // anon type - let's generate something

name empty check removed. Does this comment make sense still?

src/jdk.incubator.jextract/share/classes/jdk/internal/jextract/impl/RecordLayoutComputer.java line 191:

> 189: //        }
> 190: //        return c.spelling();
> 191: //    }

debug code leftover?

src/jdk.incubator.jextract/share/classes/jdk/internal/jextract/impl/ToplevelBuilder.java line 189:

> 187:             emitPrimitiveTypedef(Type.primitive(Type.Primitive.Kind.Double), "C_DOUBLE");
> 188:             emitPointerTypedef("C_POINTER");
> 189:         }

Will this clash with user's typedef?

typedef int C_INT; 

in user's header?

src/jdk.incubator.jextract/share/classes/jdk/internal/jextract/impl/TypeImpl.java line 45:

> 43: 
> 44:     public static final boolean IS_WINDOWS = System.getProperty("os.name").startsWith("Windows");
> 45: 

is this used?

test/jdk/tools/jextract/JextractToolRunner.java line 68:

> 66:     public static final ValueLayout.OfDouble C_DOUBLE = ValueLayout.JAVA_DOUBLE;
> 67:     public static final ValueLayout.OfAddress C_POINTER = ValueLayout.ADDRESS;
> 68: 

where are these constant used?

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

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

From mcimadamore at openjdk.java.net  Thu Sep 23 09:57:38 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 23 Sep 2021 09:57:38 GMT
Subject: [foreign-jextract] RFR: 8274155 Foreign API refresh - jextract
 update
In-Reply-To: 
References: 
 
Message-ID: <5nt95A4h0hGXjokgz88lTC11txS7I0wZzXRcrp8mYx0=.f0218717-ab50-4570-9398-3f951d252a98@github.com>

On Thu, 23 Sep 2021 02:59:21 GMT, Athijegannathan Sundararajan  wrote:

>> These are the jextract changes for the recent refresh of the Foreign Memory Access/Foreign Linker API. The biggest change in this API refresh comes from the removal of layout attributes. Jextract used to store several information in the form of layouts attributes. After some analysis, it turned out that in all cases, the use of layout attributes was not necessary, and it was really driven by the fact that jextract was, in certain places, using `MemoryLayout` as its main internal representation, instead of using the more flexible `Declaration`/`Type` APIs. Unfortunately, updating `RecordLayoutComputer` to work on `Declaration` rather than `MemoryLayout` caused changes in several part of the jextract parsing frontend.
>> 
>> Other minor changes were required, to adjust jextract to the new API changes - but most of these are small. I've dropped several now redundant overloads (so the size of the generated bindings should be smaller). There's also an additional piece of code which is used to emit typedef for common C primitive types such as `C_INT` and the likes (since the layouts for these are no longer in `CLinker`).
>> 
>> The test changes are mostly trivial updates to use the new API.
>
> src/jdk.incubator.jextract/share/classes/jdk/internal/clang/libclang/CLayouts.java line 5:
> 
>> 3: import jdk.incubator.foreign.ValueLayout;
>> 4: 
>> 5: public class CLayouts {
> 
> could this be an interface?

yes - this can be an interface.

> src/jdk.incubator.jextract/share/classes/jdk/internal/clang/libclang/RuntimeHelper.java line 55:
> 
>> 53: import static jdk.internal.clang.libclang.CLayouts.C_LONG_LONG;
>> 54: import static jdk.internal.clang.libclang.CLayouts.C_POINTER;
>> 55: 
> 
> I assume this is transition code. RuntimeHelper is generated. It cannot use handwritten CLayouts interface (unless we plan to generate something similar from jextract every time)

Yep, this is transitional code - jextract will generate these layouts now.

> src/jdk.incubator.jextract/share/classes/jdk/internal/jextract/impl/ConstantBuilder.java line 332:
> 
>> 330:         append("MemorySegment ");
>> 331:         append(fieldName);
>> 332:         append(" = ResourceScope.newSharedScope().allocateUtf8String(\"");
> 
> Do we need shared scope here? or confined scope will do?

This is a string constant - so we don't know which thread will use it. It cannot be confined. Thinking more, perhaps we should even use the global scope - because we don't really want these to ever be cleaned up.

> src/jdk.incubator.jextract/share/classes/jdk/internal/jextract/impl/OutputFactory.java line 371:
> 
>> 369: 
>> 370:         if (type instanceof Type.Declared) {
>> 371:             // anon type - let's generate something
> 
> name empty check removed. Does this comment make sense still?

I will need to double check this one.

> src/jdk.incubator.jextract/share/classes/jdk/internal/jextract/impl/RecordLayoutComputer.java line 191:
> 
>> 189: //        }
>> 190: //        return c.spelling();
>> 191: //    }
> 
> debug code leftover?

good catch

> src/jdk.incubator.jextract/share/classes/jdk/internal/jextract/impl/ToplevelBuilder.java line 189:
> 
>> 187:             emitPrimitiveTypedef(Type.primitive(Type.Primitive.Kind.Double), "C_DOUBLE");
>> 188:             emitPointerTypedef("C_POINTER");
>> 189:         }
> 
> Will this clash with user's typedef?
> 
> typedef int C_INT; 
> 
> in user's header?

possibly, perhaps we can introduce some disambiguation later?

> src/jdk.incubator.jextract/share/classes/jdk/internal/jextract/impl/TypeImpl.java line 45:
> 
>> 43: 
>> 44:     public static final boolean IS_WINDOWS = System.getProperty("os.name").startsWith("Windows");
>> 45: 
> 
> is this used?

yes, ```Long("long", TypeImpl.IS_WINDOWS ? ValueLayout.JAVA_INT : ValueLayout.JAVA_LONG),```

> test/jdk/tools/jextract/JextractToolRunner.java line 68:
> 
>> 66:     public static final ValueLayout.OfDouble C_DOUBLE = ValueLayout.JAVA_DOUBLE;
>> 67:     public static final ValueLayout.OfAddress C_POINTER = ValueLayout.ADDRESS;
>> 68: 
> 
> where are these constant used?

in tests which extends this class, I believe

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

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

From njian at openjdk.java.net  Thu Sep 23 09:59:02 2021
From: njian at openjdk.java.net (Ningsheng Jian)
Date: Thu, 23 Sep 2021 09:59:02 GMT
Subject: [vectorIntrinsics] RFR: Merge panama-vector:master
Message-ID: <-5vNR0i3L2P6mZ6ovpyGkaZmDdmeXcszVT9MweywU64=.f5b810c6-a271-4047-899c-141c5fbff7a3@github.com>

Some aarch64 conflicts resolved. Verified on AArch64 and x86.

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

Commit messages:
 - Merge 'panama-vector/master' into vectorIntrinsics
 - 8267356: AArch64: Vector API SVE codegen support
 - 8273714: jdk/jfr/api/consumer/TestRecordedFrame.java still times out after JDK-8273047
 - 8205137: Remove Applet support from SwingSet2
 - 8274120: [JVMCI] CompileBroker should resolve parameter types for JVMCI compiles
 - 8272759: (fc) java/nio/channels/FileChannel/Transfer2GPlus.java failed in timeout
 - 8271602: Add Math.ceilDiv() family parallel to Math.floorDiv() family
 - 8273924: ArrayIndexOutOfBoundsException thrown in java.util.JapaneseImperialCalendar.add()
 - 8274039: codestrings gtest fails when hsdis is present
 - 8274003: ProcessHandleImpl.Info toString has an if check which is always true
 - ... and 65 more: https://git.openjdk.java.net/panama-vector/compare/4e318de1...2c8916b8

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - vectorIntrinsics: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=129&range=00.0
 - panama-vector:master: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=129&range=00.1

Changes: https://git.openjdk.java.net/panama-vector/pull/129/files
  Stats: 14726 lines in 505 files changed: 9835 ins; 2452 del; 2439 mod
  Patch: https://git.openjdk.java.net/panama-vector/pull/129.diff
  Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/129/head:pull/129

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

From mcimadamore at openjdk.java.net  Thu Sep 23 10:02:29 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 23 Sep 2021 10:02:29 GMT
Subject: [foreign-jextract] RFR: 8274155 Foreign API refresh - jextract
 update
In-Reply-To: 
References: 
 
Message-ID: <0oeLFalFoRG2YGpD6-J5l8H63e_XFlv-dG6kGGQJndg=.9e25cf45-9316-4181-ad4c-577726c7852f@github.com>

On Thu, 23 Sep 2021 03:05:55 GMT, Athijegannathan Sundararajan  wrote:

>> These are the jextract changes for the recent refresh of the Foreign Memory Access/Foreign Linker API. The biggest change in this API refresh comes from the removal of layout attributes. Jextract used to store several information in the form of layouts attributes. After some analysis, it turned out that in all cases, the use of layout attributes was not necessary, and it was really driven by the fact that jextract was, in certain places, using `MemoryLayout` as its main internal representation, instead of using the more flexible `Declaration`/`Type` APIs. Unfortunately, updating `RecordLayoutComputer` to work on `Declaration` rather than `MemoryLayout` caused changes in several part of the jextract parsing frontend.
>> 
>> Other minor changes were required, to adjust jextract to the new API changes - but most of these are small. I've dropped several now redundant overloads (so the size of the generated bindings should be smaller). There's also an additional piece of code which is used to emit typedef for common C primitive types such as `C_INT` and the likes (since the layouts for these are no longer in `CLinker`).
>> 
>> The test changes are mostly trivial updates to use the new API.
>
> src/jdk.incubator.jextract/share/classes/jdk/internal/clang/libclang/constants$0.java line 36:
> 
>> 34: import static jdk.incubator.foreign.CLinker.*;
>> 35: import static jdk.internal.clang.libclang.CLayouts.*;
>> 36: 
> 
> Same comment as for RuntimeHelper. All these are extracted code. Need to figure out how to do CLayouts equivalent from jextract.

This is just a workaround I did to avoid rewriting all these constants classes (since they were using layouts like C_INT and such). So I defined the `CLayouts` class, and kept the rest identical to what it was before. If we regenerate all the bindings, all these dependencies will go away.

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

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

From mcimadamore at openjdk.java.net  Thu Sep 23 10:16:21 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 23 Sep 2021 10:16:21 GMT
Subject: [foreign-jextract] RFR: 8274155 Foreign API refresh - jextract
 update
In-Reply-To: <5nt95A4h0hGXjokgz88lTC11txS7I0wZzXRcrp8mYx0=.f0218717-ab50-4570-9398-3f951d252a98@github.com>
References: 
 
 <5nt95A4h0hGXjokgz88lTC11txS7I0wZzXRcrp8mYx0=.f0218717-ab50-4570-9398-3f951d252a98@github.com>
Message-ID: 

On Thu, 23 Sep 2021 09:52:32 GMT, Maurizio Cimadamore  wrote:

>> src/jdk.incubator.jextract/share/classes/jdk/internal/jextract/impl/OutputFactory.java line 371:
>> 
>>> 369: 
>>> 370:         if (type instanceof Type.Declared) {
>>> 371:             // anon type - let's generate something
>> 
>> name empty check removed. Does this comment make sense still?
>
> I will need to double check this one.

This is caused by a difference in the AST when nested structs are found. Consider this example:

struct Foo {
    struct Bar {
        int x, y;
    } bar;
};


The AST used to be:

Scoped: TOPLEVEL 
    Scoped: STRUCT Foo layout = [[b32(x)[abi/kind=INT,layout/name=x]b32(y)[abi/kind=INT,layout/name=y]](bar)[layout/name=bar]](Foo)[layout/name=Foo]
        Scoped: STRUCT Bar layout = [b32(x)[abi/kind=INT,layout/name=x]b32(y)[abi/kind=INT,layout/name=y]](Bar)[layout/name=Bar]
            Variable: FIELD x type = Int(layout = b32[abi/kind=INT]), layout = Optional[b32[abi/kind=INT]]
            Variable: FIELD y type = Int(layout = b32[abi/kind=INT]), layout = Optional[b32[abi/kind=INT]]
        Variable: FIELD bar type = Declared([b32(x)[abi/kind=INT,layout/name=x]b32(y)[abi/kind=INT,layout/name=y]](Bar)[layout/name=Bar]), layout = Optional[[b32(x)[abi/kind=INT,layout/name=x]b32(y)[abi/kind=INT,layout/name=y]](Bar)[layout/name=Bar]]

Here you can see that both `Foo` and `Bar` declaration are present in the AST. After these changes the AST is like this:


Scoped: TOPLEVEL 
    Scoped: STRUCT Foo layout = [[8%b32(x)8%b32(y)](bar)](Foo)
        Variable: FIELD bar type = Declared([8%b32(x)8%b32(y)](Bar)), layout = Optional[[8%b32(x)8%b32(y)](Bar)]


That is, the declaration for `Bar` is still there, but it's "hidden" behind the declared type of the struct field `bar`.

Is there some API method I can call to find a struct declared "on the fly" in this way?

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

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

From sundar at openjdk.java.net  Thu Sep 23 10:30:24 2021
From: sundar at openjdk.java.net (Athijegannathan Sundararajan)
Date: Thu, 23 Sep 2021 10:30:24 GMT
Subject: [foreign-jextract] RFR: 8274155 Foreign API refresh - jextract
 update
In-Reply-To: <5nt95A4h0hGXjokgz88lTC11txS7I0wZzXRcrp8mYx0=.f0218717-ab50-4570-9398-3f951d252a98@github.com>
References: 
 
 <5nt95A4h0hGXjokgz88lTC11txS7I0wZzXRcrp8mYx0=.f0218717-ab50-4570-9398-3f951d252a98@github.com>
Message-ID: 

On Thu, 23 Sep 2021 09:51:11 GMT, Maurizio Cimadamore  wrote:

>> src/jdk.incubator.jextract/share/classes/jdk/internal/jextract/impl/ConstantBuilder.java line 332:
>> 
>>> 330:         append("MemorySegment ");
>>> 331:         append(fieldName);
>>> 332:         append(" = ResourceScope.newSharedScope().allocateUtf8String(\"");
>> 
>> Do we need shared scope here? or confined scope will do?
>
> This is a string constant - so we don't know which thread will use it. It cannot be confined. Thinking more, perhaps we should even use the global scope - because we don't really want these to ever be cleaned up.

got it

>> src/jdk.incubator.jextract/share/classes/jdk/internal/jextract/impl/ToplevelBuilder.java line 189:
>> 
>>> 187:             emitPrimitiveTypedef(Type.primitive(Type.Primitive.Kind.Double), "C_DOUBLE");
>>> 188:             emitPointerTypedef("C_POINTER");
>>> 189:         }
>> 
>> Will this clash with user's typedef?
>> 
>> typedef int C_INT; 
>> 
>> in user's header?
>
> possibly, perhaps we can introduce some disambiguation later?

sounds good

>> src/jdk.incubator.jextract/share/classes/jdk/internal/jextract/impl/TypeImpl.java line 45:
>> 
>>> 43: 
>>> 44:     public static final boolean IS_WINDOWS = System.getProperty("os.name").startsWith("Windows");
>>> 45: 
>> 
>> is this used?
>
> yes, ```Long("long", TypeImpl.IS_WINDOWS ? ValueLayout.JAVA_INT : ValueLayout.JAVA_LONG),```

okay. missed that.

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

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

From mcimadamore at openjdk.java.net  Thu Sep 23 10:37:10 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 23 Sep 2021 10:37:10 GMT
Subject: [foreign-jextract] RFR: 8274155 Foreign API refresh - jextract
 update [v2]
In-Reply-To: 
References: 
Message-ID: 

> These are the jextract changes for the recent refresh of the Foreign Memory Access/Foreign Linker API. The biggest change in this API refresh comes from the removal of layout attributes. Jextract used to store several information in the form of layouts attributes. After some analysis, it turned out that in all cases, the use of layout attributes was not necessary, and it was really driven by the fact that jextract was, in certain places, using `MemoryLayout` as its main internal representation, instead of using the more flexible `Declaration`/`Type` APIs. Unfortunately, updating `RecordLayoutComputer` to work on `Declaration` rather than `MemoryLayout` caused changes in several part of the jextract parsing frontend.
> 
> Other minor changes were required, to adjust jextract to the new API changes - but most of these are small. I've dropped several now redundant overloads (so the size of the generated bindings should be smaller). There's also an additional piece of code which is used to emit typedef for common C primitive types such as `C_INT` and the likes (since the layouts for these are no longer in `CLinker`).
> 
> The test changes are mostly trivial updates to use the new API.

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

  Address review comments

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

Changes:
  - all: https://git.openjdk.java.net/panama-foreign/pull/577/files
  - new: https://git.openjdk.java.net/panama-foreign/pull/577/files/9976b842..5e66fa7b

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

  Stats: 45 lines in 5 files changed: 26 ins; 15 del; 4 mod
  Patch: https://git.openjdk.java.net/panama-foreign/pull/577.diff
  Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/577/head:pull/577

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

From sundar at openjdk.java.net  Thu Sep 23 10:41:16 2021
From: sundar at openjdk.java.net (Athijegannathan Sundararajan)
Date: Thu, 23 Sep 2021 10:41:16 GMT
Subject: [foreign-jextract] RFR: 8274155 Foreign API refresh - jextract
 update [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 23 Sep 2021 10:37:10 GMT, Maurizio Cimadamore  wrote:

>> These are the jextract changes for the recent refresh of the Foreign Memory Access/Foreign Linker API. The biggest change in this API refresh comes from the removal of layout attributes. Jextract used to store several information in the form of layouts attributes. After some analysis, it turned out that in all cases, the use of layout attributes was not necessary, and it was really driven by the fact that jextract was, in certain places, using `MemoryLayout` as its main internal representation, instead of using the more flexible `Declaration`/`Type` APIs. Unfortunately, updating `RecordLayoutComputer` to work on `Declaration` rather than `MemoryLayout` caused changes in several part of the jextract parsing frontend.
>> 
>> Other minor changes were required, to adjust jextract to the new API changes - but most of these are small. I've dropped several now redundant overloads (so the size of the generated bindings should be smaller). There's also an additional piece of code which is used to emit typedef for common C primitive types such as `C_INT` and the likes (since the layouts for these are no longer in `CLinker`).
>> 
>> The test changes are mostly trivial updates to use the new API.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

Marked as reviewed by sundar (Committer).

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

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

From mcimadamore at openjdk.java.net  Thu Sep 23 10:53:34 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 23 Sep 2021 10:53:34 GMT
Subject: [foreign-jextract] Integrated: 8274155 Foreign API refresh - jextract
 update
In-Reply-To: 
References: 
Message-ID: 

On Wed, 22 Sep 2021 15:31:43 GMT, Maurizio Cimadamore  wrote:

> These are the jextract changes for the recent refresh of the Foreign Memory Access/Foreign Linker API. The biggest change in this API refresh comes from the removal of layout attributes. Jextract used to store several information in the form of layouts attributes. After some analysis, it turned out that in all cases, the use of layout attributes was not necessary, and it was really driven by the fact that jextract was, in certain places, using `MemoryLayout` as its main internal representation, instead of using the more flexible `Declaration`/`Type` APIs. Unfortunately, updating `RecordLayoutComputer` to work on `Declaration` rather than `MemoryLayout` caused changes in several part of the jextract parsing frontend.
> 
> Other minor changes were required, to adjust jextract to the new API changes - but most of these are small. I've dropped several now redundant overloads (so the size of the generated bindings should be smaller). There's also an additional piece of code which is used to emit typedef for common C primitive types such as `C_INT` and the likes (since the layouts for these are no longer in `CLinker`).
> 
> The test changes are mostly trivial updates to use the new API.

This pull request has now been integrated.

Changeset: 80e0d4b9
Author:    Maurizio Cimadamore 
URL:       https://git.openjdk.java.net/panama-foreign/commit/80e0d4b952912980ff6cc318330efdc8d9340277
Stats:     1572 lines in 80 files changed: 535 ins; 681 del; 356 mod

8274155: Foreign API refresh - jextract update

Reviewed-by: sundar

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

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

From mcimadamore at openjdk.java.net  Thu Sep 23 14:07:39 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 23 Sep 2021 14:07:39 GMT
Subject: [foreign-jextract] RFR: Refresh panama documents to reflect API
 changes
Message-ID: 

This change updates the memory access/linker markdown documents, to reflect the latest API changes described in [1].

[1] - https://inside.java/2021/09/16/finalizing-the-foreign-apis/

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

Commit messages:
 - Merge branch 'foreign-jextract' into update_docs
 - Add footnote on invokeExact and Addressable
 - Update panama_ffi.md
 - Update panama_memaccess.md
 - Refresh memory access and linker docs to reflect API changes
 - Address review comments
 - Remove commented lines
 - Merge branch 'foreign-jextract' into foreign-finalize+jextract
 - Tweak test after removal of MemoryAddress::freeMemory
 - Add/fix copyright headers
 - ... and 11 more: https://git.openjdk.java.net/panama-foreign/compare/80e0d4b9...3f42f5d6

Changes: https://git.openjdk.java.net/panama-foreign/pull/578/files
 Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=578&range=00
  Stats: 223 lines in 2 files changed: 25 ins; 51 del; 147 mod
  Patch: https://git.openjdk.java.net/panama-foreign/pull/578.diff
  Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/578/head:pull/578

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

From sundar at openjdk.java.net  Thu Sep 23 14:45:36 2021
From: sundar at openjdk.java.net (Athijegannathan Sundararajan)
Date: Thu, 23 Sep 2021 14:45:36 GMT
Subject: [foreign-jextract] RFR: Refresh panama documents to reflect API
 changes
In-Reply-To: 
References: 
Message-ID: 

On Thu, 23 Sep 2021 13:59:44 GMT, Maurizio Cimadamore  wrote:

> This change updates the memory access/linker markdown documents, to reflect the latest API changes described in [1].
> 
> [1] - https://inside.java/2021/09/16/finalizing-the-foreign-apis/

doc/panama_ffi.md line 29:

> 27: try (ResourceScope scope = ResourceScope.newConfinedScope()) {
> 28: 	MemorySegment segment = MemorySegment.ofAddressNative(100, scope);
> 29: 	int x = MemoryAccess.getInt(segment);

Using MemoryAccess

doc/panama_ffi.md line 33:

> 31: ```
> 32: 
> 33: Both `MemoryAddress` and `MemorySegment`, implements the `Addressable` interface, which is an interface modelling entities that can be passed *by reference* ? that is, which can be projected to a `MemoryAddress` instance. In the case of `MemoryAddress` such a projection is the identity function; in the case of a memory segment, the projection returns the `MemoryAddres` instance for the segment's base address. This abstraction allows to pass either memory address or memory segments where an address is expected (this is especially useful when generating native bindings).

"Both `MemoryAddress` and `MemorySegment`, implement the..."

doc/panama_ffi.md line 88:

> 86: ### Symbol lookups
> 87: 
> 88: The first ingredient of any foreign function support is a mechanism to lookup symbols in native libraries. In traditional Java/JNI, this is done via the `System::loadLibrary` and `System::load` methods, which internally map into calls to `dlopen`. Unfortunately, these methods do not provide a way for clients to obtain the address associated with a given library symbol. For this reason, the Foreign Linker API introduces a new abstraction, namely `SymbolLookup` (similar in spirit to a method handle lookup), which provides capabilities to lookup named symbols; we can obtain a symbol lookup in 2 different ways 1:

'dlopen' or 'LoadLlibrary' ?

doc/panama_ffi.md line 133:

> 131: | `struct Point { int x; int y; };`
`union Choice { float a; int b; };`
... | `GroupLayout`  | `MemorySegment`                    |
> 132: 
> 133: Note that all C pointer types are modelled using the `ADDRESS` layout constant; the Java carrier type associated with this layout is either `Addressable` or `MemoryAddress` depending on whether the layout appears in a parameter position (resp. return position) in the function descriptor associated with a downcall method handle (resp. upcall stub). This maximizes applicability of e.g. downcall method handles, ensuring that any implementation of `Addressable` (e.g. memory segments, memory address, upcall stubs, va lists) can be passed where a pointer is expected.

Can the first sentence be reworded a bit?" depending on ..." part.

doc/panama_ffi.md line 284:

> 282: ```java
> 283: printf.invoke(CLinker.toCString("%d plus %d equals %d").address(), 2, 2, 4); //prints "2 plus 2 equals 4"
> 284: ```

Older CLinker.toCString used

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

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

From mcimadamore at openjdk.java.net  Thu Sep 23 15:13:46 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 23 Sep 2021 15:13:46 GMT
Subject: [foreign-jextract] RFR: Refresh panama documents to reflect API
 changes [v2]
In-Reply-To: 
References: 
Message-ID: 

> This change updates the memory access/linker markdown documents, to reflect the latest API changes described in [1].
> 
> [1] - https://inside.java/2021/09/16/finalizing-the-foreign-apis/

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

  Address review comments

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

Changes:
  - all: https://git.openjdk.java.net/panama-foreign/pull/578/files
  - new: https://git.openjdk.java.net/panama-foreign/pull/578/files/3f42f5d6..af00c6a6

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

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

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

From sundar at openjdk.java.net  Thu Sep 23 15:18:40 2021
From: sundar at openjdk.java.net (Athijegannathan Sundararajan)
Date: Thu, 23 Sep 2021 15:18:40 GMT
Subject: [foreign-jextract] RFR: Refresh panama documents to reflect API
 changes [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 23 Sep 2021 15:13:46 GMT, Maurizio Cimadamore  wrote:

>> This change updates the memory access/linker markdown documents, to reflect the latest API changes described in [1].
>> 
>> [1] - https://inside.java/2021/09/16/finalizing-the-foreign-apis/
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

Looks good

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

Marked as reviewed by sundar (Committer).

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

From mcimadamore at openjdk.java.net  Thu Sep 23 15:27:12 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 23 Sep 2021 15:27:12 GMT
Subject: [foreign-jextract] Integrated: Refresh panama documents to reflect
 API changes
In-Reply-To: 
References: 
Message-ID: 

On Thu, 23 Sep 2021 13:59:44 GMT, Maurizio Cimadamore  wrote:

> This change updates the memory access/linker markdown documents, to reflect the latest API changes described in [1].
> 
> [1] - https://inside.java/2021/09/16/finalizing-the-foreign-apis/

This pull request has now been integrated.

Changeset: 93a10ab1
Author:    Maurizio Cimadamore 
URL:       https://git.openjdk.java.net/panama-foreign/commit/93a10ab1ea8dd8d0081844a824081db9c93b727d
Stats:     223 lines in 2 files changed: 24 ins; 48 del; 151 mod

Refresh panama documents to reflect API changes

Reviewed-by: sundar

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

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

From mcimadamore at openjdk.java.net  Thu Sep 23 17:14:21 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 23 Sep 2021 17:14:21 GMT
Subject: [foreign-memaccess+abi] RFR: 8274219: Add back generic factory to
 create value layouts
Message-ID: 

This patch adds back a factory to create value layouts in a generic way. While we cannot make the API 100% type safe, some dynamic usages can greatly benefit from this. The `Binding` class provides a good example (greatly simplified here). Also, the logic for reconstructing layouts (see `describeConstable`) becomes a lot more regular.

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

Commit messages:
 - Add factory for value layouts

Changes: https://git.openjdk.java.net/panama-foreign/pull/579/files
 Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=579&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274219
  Stats: 172 lines in 4 files changed: 87 ins; 78 del; 7 mod
  Patch: https://git.openjdk.java.net/panama-foreign/pull/579.diff
  Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/579/head:pull/579

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

From jvernee at openjdk.java.net  Thu Sep 23 19:18:27 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Thu, 23 Sep 2021 19:18:27 GMT
Subject: [foreign-memaccess+abi] RFR: 8274219: Add back generic factory to
 create value layouts
In-Reply-To: 
References: 
Message-ID: 

On Thu, 23 Sep 2021 17:07:34 GMT, Maurizio Cimadamore  wrote:

> This patch adds back a factory to create value layouts in a generic way. While we cannot make the API 100% type safe, some dynamic usages can greatly benefit from this. The `Binding` class provides a good example (greatly simplified here). Also, the logic for reconstructing layouts (see `describeConstable`) becomes a lot more regular.

Marked as reviewed by jvernee (Committer).

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

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

From jbhateja at openjdk.java.net  Thu Sep 23 20:01:37 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Thu, 23 Sep 2021 20:01:37 GMT
Subject: [vectorIntrinsics] RFR: Merge panama-vector:master
In-Reply-To: <-5vNR0i3L2P6mZ6ovpyGkaZmDdmeXcszVT9MweywU64=.f5b810c6-a271-4047-899c-141c5fbff7a3@github.com>
References: <-5vNR0i3L2P6mZ6ovpyGkaZmDdmeXcszVT9MweywU64=.f5b810c6-a271-4047-899c-141c5fbff7a3@github.com>
Message-ID: <7cIHwnM2x6AnAApZt5OfzKVYdYzTREVJJl1FgUbgW5o=.7b2438a3-bb50-41f7-975c-41d51171cbcc@github.com>

On Thu, 23 Sep 2021 09:52:18 GMT, Ningsheng Jian  wrote:

> Some aarch64 conflicts resolved. Verified on AArch64 and x86.

Marked as reviewed by jbhateja (Committer).

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

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

From psandoz at openjdk.java.net  Thu Sep 23 20:09:23 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Thu, 23 Sep 2021 20:09:23 GMT
Subject: [foreign-memaccess+abi] RFR: 8274219: Add back generic factory to
 create value layouts
In-Reply-To: 
References: 
Message-ID: 

On Thu, 23 Sep 2021 17:07:34 GMT, Maurizio Cimadamore  wrote:

> This patch adds back a factory to create value layouts in a generic way. While we cannot make the API 100% type safe, some dynamic usages can greatly benefit from this. The `Binding` class provides a good example (greatly simplified here). Also, the logic for reconstructing layouts (see `describeConstable`) becomes a lot more regular.

Marked as reviewed by psandoz (Committer).

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemoryLayout.java line 685:

> 683: 
> 684:     /**
> 685:      * Create a value layout of given Java carrier and byte order. The type of resulting value layout is determined

Suggestion:

     * Creates a value layout of given Java carrier and byte order. The type of resulting value layout is determined

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

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

From jbhateja at openjdk.java.net  Thu Sep 23 20:10:46 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Thu, 23 Sep 2021 20:10:46 GMT
Subject: [vectorIntrinsics+mask] RFR: [X86] Masking support related cleanups.
Message-ID: 

- Some cleanups related to VectorLoadMask, VectorStoreMask and CICS patterns (one source is memory operand).

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

Commit messages:
 - [X86] Masking support related cleanups.

Changes: https://git.openjdk.java.net/panama-vector/pull/130/files
 Webrev: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=130&range=00
  Stats: 185 lines in 7 files changed: 20 ins; 73 del; 92 mod
  Patch: https://git.openjdk.java.net/panama-vector/pull/130.diff
  Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/130/head:pull/130

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

From jbhateja at openjdk.java.net  Thu Sep 23 20:14:29 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Thu, 23 Sep 2021 20:14:29 GMT
Subject: [vectorIntrinsics+mask] Withdrawn: [X86] Masking support related
 cleanups.
In-Reply-To: 
References: 
Message-ID: 

On Thu, 23 Sep 2021 20:04:18 GMT, Jatin Bhateja  wrote:

> - Some cleanups related to VectorLoadMask, VectorStoreMask and CICS patterns (one source is memory operand).

This pull request has been closed without being integrated.

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

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

From jbhateja at openjdk.java.net  Thu Sep 23 20:21:48 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Thu, 23 Sep 2021 20:21:48 GMT
Subject: [vectorIntrinsics+mask] RFR: 8274236: Cleanups related to X86 masking
 support.
Message-ID: 

- Re-factor and cleanup existing VectorLoadMask, VectorStoreMask and CICS patterns (one source is memory operand).

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

Commit messages:
 - 8274236: Cleanups related to X86 masking support.

Changes: https://git.openjdk.java.net/panama-vector/pull/131/files
 Webrev: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=131&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274236
  Stats: 185 lines in 7 files changed: 20 ins; 73 del; 92 mod
  Patch: https://git.openjdk.java.net/panama-vector/pull/131.diff
  Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/131/head:pull/131

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

From duke at openjdk.java.net  Thu Sep 23 20:34:58 2021
From: duke at openjdk.java.net (duke)
Date: Thu, 23 Sep 2021 20:34:58 GMT
Subject: git: openjdk/panama-foreign: foreign-jextract: 2 new changesets
Message-ID: <63b35b52-8f5f-4369-861b-7c7b8542743d@openjdk.org>

Changeset: 79b304b4
Author:    Maurizio Cimadamore 
Date:      2021-09-23 20:33:19 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/79b304b4f423189e84bc6085e576ac1d9c9e6ab3

8274219: Add back generic factory to create value layouts

Reviewed-by: jvernee, psandoz

! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/AbstractLayout.java
! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemoryLayout.java
! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/ValueLayout.java
! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/Binding.java

Changeset: 957306a3
Author:    duke 
Date:      2021-09-23 20:34:26 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/957306a31b4115bca0ef8e20d2d29f249fe0fcc9

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



From mcimadamore at openjdk.java.net  Thu Sep 23 20:36:21 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 23 Sep 2021 20:36:21 GMT
Subject: [foreign-memaccess+abi] RFR: 8274219: Add back generic factory to
 create value layouts [v2]
In-Reply-To: 
References: 
Message-ID: <2EDQWvI9e08YpZ7SwXAf07sUU5XgmW9A1_QyaElaYQQ=.318d546c-5865-4e15-9070-ad15aca7322b@github.com>

> This patch adds back a factory to create value layouts in a generic way. While we cannot make the API 100% type safe, some dynamic usages can greatly benefit from this. The `Binding` class provides a good example (greatly simplified here). Also, the logic for reconstructing layouts (see `describeConstable`) becomes a lot more regular.

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

  Update src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemoryLayout.java
  
  Co-authored-by: Paul Sandoz 

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

Changes:
  - all: https://git.openjdk.java.net/panama-foreign/pull/579/files
  - new: https://git.openjdk.java.net/panama-foreign/pull/579/files/6c477aed..75631014

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=579&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=579&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/579.diff
  Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/579/head:pull/579

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

From mcimadamore at openjdk.java.net  Thu Sep 23 20:36:23 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 23 Sep 2021 20:36:23 GMT
Subject: [foreign-memaccess+abi] Integrated: 8274219: Add back generic factory
 to create value layouts
In-Reply-To: 
References: 
Message-ID: 

On Thu, 23 Sep 2021 17:07:34 GMT, Maurizio Cimadamore  wrote:

> This patch adds back a factory to create value layouts in a generic way. While we cannot make the API 100% type safe, some dynamic usages can greatly benefit from this. The `Binding` class provides a good example (greatly simplified here). Also, the logic for reconstructing layouts (see `describeConstable`) becomes a lot more regular.

This pull request has now been integrated.

Changeset: 79b304b4
Author:    Maurizio Cimadamore 
URL:       https://git.openjdk.java.net/panama-foreign/commit/79b304b4f423189e84bc6085e576ac1d9c9e6ab3
Stats:     172 lines in 4 files changed: 87 ins; 78 del; 7 mod

8274219: Add back generic factory to create value layouts

Reviewed-by: jvernee, psandoz

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

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

From sviswanathan at openjdk.java.net  Thu Sep 23 22:56:03 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Thu, 23 Sep 2021 22:56:03 GMT
Subject: [vectorIntrinsics+mask] RFR: 8274236: Cleanups related to X86
 masking support.
In-Reply-To: 
References: 
Message-ID: 

On Thu, 23 Sep 2021 20:14:32 GMT, Jatin Bhateja  wrote:

> - Re-factor and cleanup existing VectorLoadMask, VectorStoreMask and CICS patterns (one source is memory operand).

src/hotspot/cpu/x86/x86.ad line 1498:

> 1496:     case Op_VectorStoreMask:
> 1497:     case Op_VectorBlend:
> 1498:       if (UseSSE < 3) {

This doesnt look correct. packusdw needs SSE4.  Also all the others in this case block need SSE4.

src/hotspot/cpu/x86/x86.ad line 7925:

> 7923:   predicate(Matcher::vector_length(n) <= 16 && n->in(1)->bottom_type()->isa_vectmask() == NULL);
> 7924:   match(Set dst (VectorStoreMask src size));
> 7925:   effect(TEMP_DEF dst);

The original storeMask2B didn't need TEMP dst and so was a separate rule.

src/hotspot/cpu/x86/x86.ad line 7948:

> 7946:   match(Set dst (VectorStoreMask src size));
> 7947:   format %{ "vector_store_mask $dst, $src \t! elem size is $size byte[s]" %}
> 7948:   effect(TEMP_DEF dst);

The original storeMask4B didn't need TEMP dst and so was a separate rule.

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

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

From sviswanathan at openjdk.java.net  Thu Sep 23 23:01:07 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Thu, 23 Sep 2021 23:01:07 GMT
Subject: [vectorIntrinsics+mask] RFR: 8274236: Cleanups related to X86
 masking support.
In-Reply-To: 
References: 
Message-ID: 

On Thu, 23 Sep 2021 20:14:32 GMT, Jatin Bhateja  wrote:

> - Re-factor and cleanup existing VectorLoadMask, VectorStoreMask and CICS patterns (one source is memory operand).

Marked as reviewed by sviswanathan (Committer).

Other than the 3 comments above, rest of the patch looks good.
Please fix and integrate. No need for re-review.

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

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

From jbhateja at openjdk.java.net  Fri Sep 24 02:53:49 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Fri, 24 Sep 2021 02:53:49 GMT
Subject: [vectorIntrinsics+mask] RFR: 8274236: Cleanups related to X86
 masking support. [v2]
In-Reply-To: 
References: 
Message-ID: <4l1Kjht_8m6uyY817GTGk-5Okz1T3AyIcS-zAPobKhI=.ff208962-20a7-4899-bb0e-acc4370820cd@github.com>

> - Re-factor and cleanup existing VectorLoadMask, VectorStoreMask and CICS patterns (one source is memory operand).

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  8274236: Review comments resolved.

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

Changes:
  - all: https://git.openjdk.java.net/panama-vector/pull/131/files
  - new: https://git.openjdk.java.net/panama-vector/pull/131/files/7fa950a2..23f3ee6e

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

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/panama-vector/pull/131.diff
  Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/131/head:pull/131

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

From jbhateja at openjdk.java.net  Fri Sep 24 02:53:51 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Fri, 24 Sep 2021 02:53:51 GMT
Subject: [vectorIntrinsics+mask] RFR: 8274236: Cleanups related to X86
 masking support. [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 23 Sep 2021 22:51:39 GMT, Sandhya Viswanathan  wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8274236: Review comments resolved.
>
> src/hotspot/cpu/x86/x86.ad line 1498:
> 
>> 1496:     case Op_VectorStoreMask:
>> 1497:     case Op_VectorBlend:
>> 1498:       if (UseSSE < 3) {
> 
> This doesnt look correct. packusdw needs SSE4.  Also all the others in this case block need SSE4.

Thanks, DONE

> src/hotspot/cpu/x86/x86.ad line 7925:
> 
>> 7923:   predicate(Matcher::vector_length(n) <= 16 && n->in(1)->bottom_type()->isa_vectmask() == NULL);
>> 7924:   match(Set dst (VectorStoreMask src size));
>> 7925:   effect(TEMP_DEF dst);
> 
> The original storeMask2B didn't need TEMP dst and so was a separate rule.

TEMP_DST ensures creation of separate machine operands which gets allocated same register as DST, thus preventing any accidental sharing of register with any other temporary machine operand over the node.  In this case since there is no other explicit temporary register used to effectively, TEMP_DEF  is same at DEF for all practical purpose.

> src/hotspot/cpu/x86/x86.ad line 7948:
> 
>> 7946:   match(Set dst (VectorStoreMask src size));
>> 7947:   format %{ "vector_store_mask $dst, $src \t! elem size is $size byte[s]" %}
>> 7948:   effect(TEMP_DEF dst);
> 
> The original storeMask4B didn't need TEMP dst and so was a separate rule.

TEMP_DST ensures creation of separate machine operands which gets allocated same register as DST, thus preventing any accidental sharing of register with any other temporary machine operand over the node.  In this case since there is no other explicit temporary register used to effectively, TEMP_DEF  is same at DEF for all practical purpose.

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

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

From jbhateja at openjdk.java.net  Fri Sep 24 02:53:52 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Fri, 24 Sep 2021 02:53:52 GMT
Subject: [vectorIntrinsics+mask] Integrated: 8274236: Cleanups related to X86
 masking support.
In-Reply-To: 
References: 
Message-ID: 

On Thu, 23 Sep 2021 20:14:32 GMT, Jatin Bhateja  wrote:

> - Re-factor and cleanup existing VectorLoadMask, VectorStoreMask and CICS patterns (one source is memory operand).

This pull request has now been integrated.

Changeset: a6189c78
Author:    Jatin Bhateja 
URL:       https://git.openjdk.java.net/panama-vector/commit/a6189c78453ffce1690b015691cad22490fc7a2d
Stats:     184 lines in 7 files changed: 20 ins; 73 del; 91 mod

8274236: Cleanups related to X86 masking support.

Reviewed-by: sviswanathan

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

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

From samuel.audet at gmail.com  Fri Sep 24 03:53:50 2021
From: samuel.audet at gmail.com (Samuel Audet)
Date: Fri, 24 Sep 2021 12:53:50 +0900
Subject: Will we need to use the --enable-native-access option to enable
 JNI in the future?
In-Reply-To: 
References: 
 
 
 
 
 <18b80809-54b1-1b40-e5f2-a2b1a4e10711@oracle.com>
 
 <2eb43d4c-6eee-39f7-877b-d98681773520@oracle.com>
 
 <6c4f7554-4d9d-e094-46b5-a6c2c9d7f159@gmail.com>
 
Message-ID: 

What I have in mind is not a blanket approach like "sudo" for 
everything, it is more in fact like granting permissions to applications 
on mobile platforms. If it turns out that we don't want to grant native 
access to applications by default, then we could have it that whenever 
users install such an app, they would get prompted to grant that 
permission, or not.

In fact, this is exactly how "sudo" on Windows works: You get asked with 
a nice user-friendly prompt if you're sure that you want to grant 
administrator permissions to that application you're trying to run. It 
doesn't ask you to go figure how to launch it from the command line!

Actually, Android, iOS, Mac, Windows, even GNOME on Linux does it like 
that these days, and it's been working fine for over a decade now on 
every single platform that I am aware of. Please explain why this would 
be the wrong way to go for Java. I can hope that you're working on 
something revolutionary, but I'm quite disillusioned by OpenJDK in 
general these days, so I don't think that's what is happening here, but 
I'll give you the benefit of the doubt.

I think your main point is that the "application packager has no way to 
be notified when _something_ changes in the dependencies of his/her 
application", which sounds reasonable, but I don't see when that would 
be a problem. Could you elaborate on this scenario? In my book, 
"application packagers" are also programmers, so they already do things 
like test applications in multiple environments anyway (with and without 
sudo-like permissions), so I think that any changes in the dependencies 
would easily show up at that stage. Do you have a counterexample in mind?

Samuel

On 9/22/21 6:18 PM, Maurizio Cimadamore wrote:
> 
> On 22/09/2021 04:19, Samuel Audet wrote:
>> I don't feel this is something that should be set on a per-application 
>> basis. I really do mean something like an "environment", like an 
>> environment variable. Sure, we can ask users to set JAVA_TOOL_OPTIONS 
>> and what not, but that is not user friendly. It's not for end users. 
>> Those users should be able to tell the application whether it's OK to 
>> run that code or not. For example, in the case of Android, etc, we can 
>> assume the default to be "yes", but for some desktop application, the 
>> end users could be instructed to go set a checkbox somewhere in the 
>> settings of the JDK.
>>
>> This, incidentally, would satisfy the needs of applications such as 
>> the one Glavo describes, no?
>>
>> In any case, please explain why this kind of approach is not being 
>> considered!
> 
> The reasons why this is not considered are similar to why we don't just 
> have a single kill switch to enable _all_ native restricted methods in 
> _any_ modules. We could do something like --enable-preview, a single 
> flag which enable native access for everything. This would also make 
> Glavo use case work (well, plus some trick to ignore unrecognized 
> options for older versions, but we have 
> -XX:+IgnoreUnrecognizedVMOptions). The problem with this (and other 
> blanket approaches) is that the application packager has no way to be 
> notified when _something_ changes in the dependencies of his/her 
> application.
> 
> I think smartphones provide a good analogy: you grant permission on an 
> application basis; e.g. when you install app X, you are asked whether 
> you are ok with X accessing your storage and camera. What you are 
> proposing is that, instead, we have a global setting in our devices 
> which say "please give every app all the access they want and never 
> bother me with this again". Such a model, while certainly minimizing 
> friction, is surely bound to create issues in the long run.
> 
> I think there were many interesting point in Glavo's email - e.g. naming 
> of the option could be misleading and over promising, the fact that if 
> access is granted to module A and A depends on B, we also have to grant 
> access to B as well, etc.
> 
> But having a global "sudo please let me do what I want" switch was never 
> suggested, and is not a direction we'd like to take, sorry.
> 
> Maurizio
> 
> 
>>
>> Samuel
>>
>> On 9/21/21 8:59 PM, Samuel Audet wrote:
>>> FWIW, I think the core issue comes from the fact that the Java platform is
>>> unable to take responsibility for any of the native code, so what about a
>>> way to define some sort of "environment", for the lack of a better word.
>>> For example, when the code gets loaded on Android, iOS, or WebAssembly, we
>>> already know that the native code is going to run in a sandbox, so we
>>> shouldn't have to specify any flags because executing any native code is
>>> already considered as "safe" by the native platform. Maybe not as "safe" as
>>> Java code, but that's not the point, the point is that maybe the decision
>>> should be deferred to the underlying platform? Thoughts?
>>>
>>> Samuel
>>>
>>> On Tue, Sep 21, 2021, 19:20 Maurizio Cimadamore 
>>>  wrote:
>>>
>>>> I'll zoom in on this issue, because I think it's the one we need to
>>>> understand the most. For the record, I don't despise all code at all -
>>>> but I also think that the position of "must be run with a clean `java
>>>> -jar`, no extra arguments" is (while a good goal) a bit unrealistic.
>>>> Most of the real world Java application I've seen all need to drop in
>>>> some extra command line option (e.g. -Xmx), but I think your problem
>>>> here is more specific than "just add a command line option" - the
>>>> problem is adding an option that is only supported on _some_ JDKs (see
>>>> below).
>>>>
>>>> On 21/09/2021 03:51, Glavo wrote:
>>>>> In my original plan, I would convert it into a multi-release jar.
>>>>> On the Java platform available to Panama, I will use Panama to call
>>>>> the system API. This will allow me to adapt to more platforms (e.g.
>>>>> mips64el).
>>>>> Panama's restrictions made me abandon this scheme. Because
>>>>> I can't execute it on any version of Java platform with a
>>>> unified command.
>>>>
>>>> I think this is the real important point here. I'd like to understand
>>>> more about this use case. Do you have an executable AND multi-release
>>>> JAR? Is it an application that you are developing? Do you want that
>>>> application to be just executed using `java -jar foo.jar`? Does your
>>>> application have a launcher to trigger the `java -jar` command?
>>>>
>>>> Please walk me through your use case a bit, and please let's keep the
>>>> conversation focussed - arguing over general safety principles is not
>>>> very helpful, when the real problem is, I suspect, driven by something
>>>> much more concrete.
>>>>
>>>> Thanks
>>>> Maurizio
>>>>
>>>
>>


From njian at openjdk.java.net  Fri Sep 24 06:21:38 2021
From: njian at openjdk.java.net (Ningsheng Jian)
Date: Fri, 24 Sep 2021 06:21:38 GMT
Subject: [vectorIntrinsics] RFR: Merge panama-vector:master [v2]
In-Reply-To: <-5vNR0i3L2P6mZ6ovpyGkaZmDdmeXcszVT9MweywU64=.f5b810c6-a271-4047-899c-141c5fbff7a3@github.com>
References: <-5vNR0i3L2P6mZ6ovpyGkaZmDdmeXcszVT9MweywU64=.f5b810c6-a271-4047-899c-141c5fbff7a3@github.com>
Message-ID: 

> Some aarch64 conflicts resolved. Verified on AArch64 and x86.

Ningsheng Jian has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 738 commits:

 - Merge 'panama-vector/master' into vectorIntrinsics
 - Merge panama-vector:master
   
   Reviewed-by: eliu
 - Merge panama-vector:master
   
   Reviewed-by: jbhateja, psandoz
 - 8263532: C2: Improve vector box elimination for Phi nodes
   
   Reviewed-by: psandoz
 - Merge panama-vector:master
   
   Co-authored-by: Ningsheng Jian 
 - Optimize mem barriers for ByteBuffer cases
   
   Reviewed-by: psandoz, vlivanov
 - 8271009: AArch64: Wrap duplicated SVE instructions into a single method
   
   Reviewed-by: njian, xgong
 - 8271005: AArch64: Add SVE codegen for VectorMask reduction nodes
   
   Reviewed-by: njian, eliu
 - Merge panama-vector:master
   
   Reviewed-by: xgong, sviswanathan
 - 8269264: Some more cleanups for Vector API SVE support
   
   Reviewed-by: xgong
 - ... and 728 more: https://git.openjdk.java.net/panama-vector/compare/9d3379b9...2c8916b8

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

Changes: https://git.openjdk.java.net/panama-vector/pull/129/files
 Webrev: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=129&range=01
  Stats: 67647 lines in 112 files changed: 67563 ins; 18 del; 66 mod
  Patch: https://git.openjdk.java.net/panama-vector/pull/129.diff
  Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/129/head:pull/129

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

From njian at openjdk.java.net  Fri Sep 24 06:21:39 2021
From: njian at openjdk.java.net (Ningsheng Jian)
Date: Fri, 24 Sep 2021 06:21:39 GMT
Subject: [vectorIntrinsics] Integrated: Merge panama-vector:master
In-Reply-To: <-5vNR0i3L2P6mZ6ovpyGkaZmDdmeXcszVT9MweywU64=.f5b810c6-a271-4047-899c-141c5fbff7a3@github.com>
References: <-5vNR0i3L2P6mZ6ovpyGkaZmDdmeXcszVT9MweywU64=.f5b810c6-a271-4047-899c-141c5fbff7a3@github.com>
Message-ID: 

On Thu, 23 Sep 2021 09:52:18 GMT, Ningsheng Jian  wrote:

> Some aarch64 conflicts resolved. Verified on AArch64 and x86.

This pull request has now been integrated.

Changeset: 98a7a541
Author:    Ningsheng Jian 
URL:       https://git.openjdk.java.net/panama-vector/commit/98a7a541285059a47df94d115a060cf911dfa91c
Stats:     14726 lines in 505 files changed: 9835 ins; 2452 del; 2439 mod

Merge panama-vector:master

Reviewed-by: jbhateja

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

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

From maurizio.cimadamore at oracle.com  Fri Sep 24 09:46:07 2021
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Fri, 24 Sep 2021 10:46:07 +0100
Subject: Will we need to use the --enable-native-access option to enable
 JNI in the future?
In-Reply-To: 
References: 
 
 
 
 
 <18b80809-54b1-1b40-e5f2-a2b1a4e10711@oracle.com>
 
 <2eb43d4c-6eee-39f7-877b-d98681773520@oracle.com>
 
 <6c4f7554-4d9d-e094-46b5-a6c2c9d7f159@gmail.com>
 
 
Message-ID: <2b3c3be4-3dbb-9831-c9f0-cb662a7b4f76@oracle.com>


On 24/09/2021 04:53, Samuel Audet wrote:
> I think your main point is that the "application packager has no way 
> to be notified when _something_ changes in the dependencies of his/her 
> application", which sounds reasonable, but I don't see when that would 
> be a problem. Could you elaborate on this scenario? In my book, 
> "application packagers" are also programmers, so they already do 
> things like test applications in multiple environments anyway (with 
> and without sudo-like permissions), so I think that any changes in the 
> dependencies would easily show up at that stage. Do you have a 
> counterexample in mind? 

The counterexample I have in mind is auditing. If you distribute a 
binary in the wild, you probably want to be very careful not only about 
what yout application does, but also whether your code has dependencies 
on libraries which might do something strange. From the perspective of 
the distributor, any native access (whether direct, or indirect) counts: 
if a bad native access in a 5-th level dependency compromises the 
application, the application as a whole will be considered "at fault".

Nevertheless, your point is valid: the distinction between a developer 
deploying a test on X and an "application packager" is subtle, and I get 
that, in the former case, the restrictions imposed by the mechanism we 
have now can be perceived as overly strict.

No matter how you look at it, I think it's a hard thing to balance - as 
soon as you make some sort of escape hatch available via command-line 
and/or environment (for the developer use case), it is hard then not to 
lose all the benefits for the auditing-like use cases.

That said, the feedback in this thread will be taken into account, and 
we will consider minor tweaks to the existing mechanism which will 
provide for a smoother transition from JNI to Panama, as well as to 
reduce friction in the cases you mention.

Maurizio





From njian at openjdk.java.net  Fri Sep 24 10:23:00 2021
From: njian at openjdk.java.net (Ningsheng Jian)
Date: Fri, 24 Sep 2021 10:23:00 GMT
Subject: [vectorIntrinsics+mask] RFR: Merge panama-vector:vectorIntrinsics
Message-ID: 

AArch64 conflicts resolved. Others are clean.

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

Commit messages:
 - Merge vectorIntrinsics into vectorIntrinsics+mask
 - Merge panama-vector:master
 - 8267356: AArch64: Vector API SVE codegen support
 - 8273714: jdk/jfr/api/consumer/TestRecordedFrame.java still times out after JDK-8273047
 - 8205137: Remove Applet support from SwingSet2
 - 8274120: [JVMCI] CompileBroker should resolve parameter types for JVMCI compiles
 - 8272759: (fc) java/nio/channels/FileChannel/Transfer2GPlus.java failed in timeout
 - 8271602: Add Math.ceilDiv() family parallel to Math.floorDiv() family
 - 8273924: ArrayIndexOutOfBoundsException thrown in java.util.JapaneseImperialCalendar.add()
 - 8274039: codestrings gtest fails when hsdis is present
 - ... and 410 more: https://git.openjdk.java.net/panama-vector/compare/a6189c78...7903c351

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=132&range=00.0
 - panama-vector:vectorIntrinsics: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=132&range=00.1

Changes: https://git.openjdk.java.net/panama-vector/pull/132/files
  Stats: 47675 lines in 1789 files changed: 29770 ins; 9632 del; 8273 mod
  Patch: https://git.openjdk.java.net/panama-vector/pull/132.diff
  Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/132/head:pull/132

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

From eliu at openjdk.java.net  Fri Sep 24 10:34:08 2021
From: eliu at openjdk.java.net (Eric Liu)
Date: Fri, 24 Sep 2021 10:34:08 GMT
Subject: [vectorIntrinsics+mask] RFR: Merge panama-vector:vectorIntrinsics
In-Reply-To: 
References: 
Message-ID: 

On Fri, 24 Sep 2021 09:42:59 GMT, Ningsheng Jian  wrote:

> AArch64 conflicts resolved. Others are clean.

Thanks for your work.

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

Marked as reviewed by eliu (Committer).

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

From duke at openjdk.java.net  Fri Sep 24 11:07:34 2021
From: duke at openjdk.java.net (duke)
Date: Fri, 24 Sep 2021 11:07:34 GMT
Subject: git: openjdk/panama-foreign: foreign-memaccess+abi: 95 new changesets
Message-ID: <795db029-4049-4324-ad70-834dfaab44ff@openjdk.org>

Changeset: 27d747ad
Author:    Matthias Baesken 
Date:      2021-09-17 12:53:38 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/27d747ad4f13193d5fc651d893540465248c48a6

8273877: os::unsetenv unused

Reviewed-by: mdoerr, stuefe

! src/hotspot/os/posix/os_posix.cpp
! src/hotspot/os/windows/os_windows.cpp
! src/hotspot/share/runtime/os.hpp

Changeset: 17f7a45c
Author:    Phil Race 
Date:      2021-09-17 15:00:52 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/17f7a45ce40ecf0666f282e68be1844d38a5d1c7

8273913: Problem list some headful client jtreg tests that fail on macOS 12

Reviewed-by: pbansal, aivanov

! test/jdk/ProblemList.txt

Changeset: 2f8c2211
Author:    Kartik Ohri 
Committer: Paul Sandoz 
Date:      2021-09-17 15:12:34 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/2f8c2211c8c7f9661e283c8df914fde5bda197a6

8273681: Add Vector API vs Arrays.mismatch intrinsic benchmark

Reviewed-by: psandoz

+ test/micro/org/openjdk/bench/jdk/incubator/vector/ArrayMismatchBenchmark.java

Changeset: 83020617
Author:    sunxu 
Committer: Calvin Cheung 
Date:      2021-09-17 16:41:51 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/83020617e70d40a42029720534af561f8af8bce2

8273774: CDSPluginTest should only expect classes_nocoops.jsa exists on supported 64-bit platforms

Reviewed-by: ccheung, mchung

! test/jdk/tools/jlink/plugins/CDSPluginTest.java

Changeset: 2a2e9190
Author:    lawrence.andrews 
Committer: Alexey Ivanov 
Date:      2021-09-17 18:11:23 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/2a2e9190d4e866ac1b712feb0e4bb61d08e112c7

8273685: Remove jtreg tag manual=yesno for java/awt/Graphics/LCDTextAndGraphicsState.java & show test instruction

Reviewed-by: aivanov, pbansal

! test/jdk/java/awt/Graphics/LCDTextAndGraphicsState.java

Changeset: bb9d1427
Author:    Thomas Stuefe 
Date:      2021-09-18 08:29:48 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/bb9d142759ece7665329b124a8ea0b16049b024a

8273958: gtest/MetaspaceGtests executes unnecessary tests in debug builds

Reviewed-by: jiefu

! test/hotspot/jtreg/gtest/MetaspaceGtests.java

Changeset: 7c9868c0
Author:    Zhengyu Gu 
Date:      2021-09-18 23:11:06 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/7c9868c0b3c9bd3d305e71f91596190813cdccce

8273454: C2: Transform (-a)*(-b) into a*b

Reviewed-by: thartmann, eliu, chagedorn

! src/hotspot/share/opto/mulnode.cpp
+ test/hotspot/jtreg/compiler/integerArithmetic/TestNegMultiply.java

Changeset: dc7f452a
Author:    Matthias Baesken 
Date:      2021-09-20 08:29:12 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/dc7f452acbe3afa5aa6e31d316bd5e669c86d6f6

8273815: move have_special_privileges to os_posix for POSIX platforms

Reviewed-by: mdoerr, stuefe, dholmes

! src/hotspot/os/aix/os_aix.cpp
! src/hotspot/os/bsd/os_bsd.cpp
! src/hotspot/os/linux/os_linux.cpp
! src/hotspot/os/posix/os_posix.cpp

Changeset: d2388b7a
Author:    Thomas Stuefe 
Date:      2021-09-20 08:46:44 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/d2388b7a0f4bfb55ea0d5648175e3253f30a4302

8273959: Some metaspace diagnostic switches should be develop

Reviewed-by: dholmes, jiefu

! src/hotspot/share/runtime/globals.hpp
! test/hotspot/jtreg/gtest/MetaspaceGtests.java

Changeset: a561eac9
Author:    Christian Hagedorn 
Date:      2021-09-20 12:53:56 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/a561eac912740da6a5982c47558e13f34481219f

8273895: compiler/ciReplay/TestVMNoCompLevel.java fails due to wrong data size with TieredStopAtLevel=2,3

Reviewed-by: kvn, dlong

! test/hotspot/jtreg/compiler/ciReplay/TestVMNoCompLevel.java

Changeset: 6f3e40c1
Author:    Christian Hagedorn 
Date:      2021-09-20 12:56:08 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/6f3e40c16db899f1add67b997dede17eeb83418f

8273825: TestIRMatching.java fails after JDK-8266550

Reviewed-by: thartmann, roland

! test/hotspot/jtreg/compiler/lib/ir_framework/IRNode.java

Changeset: f71df142
Author:    Naoto Sato 
Date:      2021-09-20 13:38:38 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/f71df142a97f522b40e90c3105e0e5bd8d5af9a2

8273187: jtools tests fail with missing markerName check

Reviewed-by: iris, sspitsyn, joehw

! test/jdk/ProblemList.txt
! test/jdk/sun/tools/jcmd/JcmdOutputEncodingTest.java
! test/jdk/sun/tools/jstack/BasicJStackTest.java

Changeset: 699865f7
Author:    Jan Lahoda 
Date:      2021-09-20 13:43:14 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/699865f76cdf76fbd8042c1b5677b71e29faa4bc

8259039: Passing different version to --release flag than javac version output warning

Reviewed-by: jjg

! src/jdk.compiler/share/classes/com/sun/tools/javac/code/ClassFinder.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/ct.properties
! src/jdk.compiler/share/classes/com/sun/tools/javac/util/Names.java
+ test/langtools/tools/javac/platform/CtPropertiesTest.java

Changeset: 1f8af524
Author:    Aleksey Shipilev 
Date:      2021-09-20 14:02:07 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/1f8af524ffe2d2d1469d8f07887b1f61c6e4d7b8

8273314: Add tier4 test groups

Reviewed-by: serb, iignatyev

! test/hotspot/jtreg/TEST.groups
! test/jaxp/TEST.groups
! test/jdk/TEST.groups
! test/langtools/TEST.groups

Changeset: 544193a3
Author:    Aleksey Shipilev 
Date:      2021-09-20 14:05:03 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/544193a3bb6431ee4bb0bd43cb29cc60c7709b25

8247980: Exclusive execution of java/util/stream tests slows down tier1

Reviewed-by: iignatyev

! test/jdk/TEST.ROOT

Changeset: 4da45c43
Author:    lawrence.andrews 
Committer: Alexey Ivanov 
Date:      2021-09-20 14:07:50 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/4da45c430139fe66fab020c2f96686dc9cf26a97

8270609: [TESTBUG] java/awt/print/Dialog/DialogCopies.java does not show instruction

Reviewed-by: aivanov

! test/jdk/java/awt/print/Dialog/DialogCopies.java

Changeset: 9aa12daa
Author:    Nils Eliasson 
Date:      2021-09-20 14:11:16 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/9aa12daa15944910c7b29d1715e8aee66cca5315

8273934: Remove unused perfcounters

Reviewed-by: chagedorn

! src/hotspot/share/compiler/compileBroker.hpp

Changeset: 4d95a5d6
Author:    Nils Eliasson 
Date:      2021-09-20 14:59:44 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/4d95a5d6dc7cc3d2b239c554a1302ac647807bd6

8273933: [TESTBUG] Test must run without preallocated exceptions

Reviewed-by: chagedorn, thartmann

! test/hotspot/jtreg/vmTestbase/jit/t/t105/t105.java

Changeset: 48aff231
Author:    Erik Gahlin 
Date:      2021-09-20 15:44:46 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/48aff23165db668eb9c06477d16a8e72b6dc6b56

8272515: JFR: Names should only be valid Java identifiers

Reviewed-by: mgronlun

! src/java.base/share/classes/jdk/internal/module/Checks.java
! src/jdk.jfr/share/classes/jdk/jfr/EventFactory.java
! src/jdk.jfr/share/classes/jdk/jfr/Name.java
! src/jdk.jfr/share/classes/jdk/jfr/ValueDescriptor.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/EventControl.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/EventInstrumentation.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/MetadataLoader.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/Type.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/TypeLibrary.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/Utils.java
! test/jdk/jdk/jfr/api/metadata/annotations/TestName.java

Changeset: dad5d271
Author:    Erik Gahlin 
Date:      2021-09-20 15:59:02 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/dad5d27172dbe24ae13b6386d1cdf15549f6619d

8272867: JFR: ManagementSupport.removeBefore() lost coverage

Reviewed-by: mseledtsov, mgronlun

! src/jdk.jfr/share/classes/jdk/jfr/internal/management/ManagementSupport.java

Changeset: 4b3a4fff
Author:    Thomas Schatzl 
Date:      2021-09-20 16:17:52 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/4b3a4fff39c1fba0d7eae719525e2a46b0a6d6ed

8273940: vmTestbase/vm/mlvm/meth/stress/gc/callSequencesDuringGC/Test.java crashes in full gc during VM exit

Reviewed-by: lkorinth

! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp
! src/hotspot/share/gc/g1/g1ConcurrentMark.hpp
! src/hotspot/share/gc/g1/g1ConcurrentMarkThread.cpp

Changeset: 26e5e9ae
Author:    Erik Gahlin 
Date:      2021-09-20 16:53:20 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/26e5e9ae8cddbbd8bc498d2951e37970358f79ba

8273654: JFR: Remove unused SecuritySupport.setAccessible(Field)

Reviewed-by: mseledtsov, shade

! src/jdk.jfr/share/classes/jdk/jfr/internal/SecuritySupport.java

Changeset: a67f0f9d
Author:    Calvin Cheung 
Date:      2021-09-20 16:56:32 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/a67f0f9dc04200c22db05e277346f24d31306b53

8273505: runtime/cds/appcds/loaderConstraints/DynamicLoaderConstraintsTest.java#default-cl crashed with SIGSEGV in MetaspaceShared::link_shared_classes

Reviewed-by: iklam, minqi

! src/hotspot/share/cds/metaspaceShared.cpp
! src/hotspot/share/classfile/classLoaderData.cpp

Changeset: b3b4b1cc
Author:    Andrey Turbanov 
Committer: Alexey Ivanov 
Date:      2021-09-20 17:23:02 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/b3b4b1cc218d4c02809eb7fd4d83d541acfbd9bd

8273907: Cleanup redundant Math.max/min calls in DefaultHighlighter

Reviewed-by: pbansal, aivanov, azvegint

! src/java.desktop/share/classes/javax/swing/text/DefaultHighlighter.java

Changeset: 5c21c004
Author:    Mikhailo Seledtsov 
Date:      2021-09-20 19:03:34 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/5c21c0044104b52fcaf3f3a830ea6e219d504ada

8267163: Rename anonymous loader tests to hidden loader tests

Reviewed-by: dholmes, hseigel

! test/hotspot/jtreg/ProblemList-Xcomp.txt
- test/hotspot/jtreg/vmTestbase/vm/mlvm/anonloader/func/findByName/Test.java
- test/hotspot/jtreg/vmTestbase/vm/mlvm/anonloader/share/AnonkTestee02.java
- test/hotspot/jtreg/vmTestbase/vm/mlvm/anonloader/stress/byteMutation/Test.java
- test/hotspot/jtreg/vmTestbase/vm/mlvm/anonloader/stress/oome/heap/Test.java
- test/hotspot/jtreg/vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java
- test/hotspot/jtreg/vmTestbase/vm/mlvm/anonloader/stress/parallelLoad/Test.java
- test/hotspot/jtreg/vmTestbase/vm/mlvm/anonloader/stress/randomBytecodes/Test.java
+ test/hotspot/jtreg/vmTestbase/vm/mlvm/hiddenloader/func/findByName/Test.java
= test/hotspot/jtreg/vmTestbase/vm/mlvm/hiddenloader/share/HiddenkTestee01.java
+ test/hotspot/jtreg/vmTestbase/vm/mlvm/hiddenloader/share/HiddenkTestee02.java
= test/hotspot/jtreg/vmTestbase/vm/mlvm/hiddenloader/share/StressClassLoadingTest.java
= test/hotspot/jtreg/vmTestbase/vm/mlvm/hiddenloader/stress/byteMutation/TEST.properties
+ test/hotspot/jtreg/vmTestbase/vm/mlvm/hiddenloader/stress/byteMutation/Test.java
= test/hotspot/jtreg/vmTestbase/vm/mlvm/hiddenloader/stress/oome/heap/TEST.properties
+ test/hotspot/jtreg/vmTestbase/vm/mlvm/hiddenloader/stress/oome/heap/Test.java
= test/hotspot/jtreg/vmTestbase/vm/mlvm/hiddenloader/stress/oome/metaspace/TEST.properties
+ test/hotspot/jtreg/vmTestbase/vm/mlvm/hiddenloader/stress/oome/metaspace/Test.java
= test/hotspot/jtreg/vmTestbase/vm/mlvm/hiddenloader/stress/parallelLoad/TEST.properties
+ test/hotspot/jtreg/vmTestbase/vm/mlvm/hiddenloader/stress/parallelLoad/Test.java
= test/hotspot/jtreg/vmTestbase/vm/mlvm/hiddenloader/stress/randomBytecodes/TEST.properties
+ test/hotspot/jtreg/vmTestbase/vm/mlvm/hiddenloader/stress/randomBytecodes/Test.java

Changeset: 04891c95
Author:    Chris Plummer 
Date:      2021-09-20 20:10:10 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/04891c95e0a29409959aa3e649964788e589a6da

8273912: Add threadControl_dumpThread(jthread) function

Reviewed-by: kevinw, sspitsyn

! src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c
! src/jdk.jdwp.agent/share/native/libjdwp/threadControl.h

Changeset: 5fde4b64
Author:    Alex Menkov 
Date:      2021-09-20 20:17:57 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/5fde4b64e25a3b3a4c01c57064624b9f930a1324

8273909: vmTestbase/nsk/jdi/Event/request/request001 can still fail with "ERROR: new event is not ThreadStartEvent"

Reviewed-by: cjplummer, sspitsyn

! test/hotspot/jtreg/vmTestbase/nsk/jdi/Event/request/request001.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventIterator/nextEvent/nextevent001.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadDeathRequest/addThreadFilter/addthreadfilter001.java
! test/hotspot/jtreg/vmTestbase/nsk/share/jdi/JDIBase.java

Changeset: ee3576a4
Author:    Erik Gahlin 
Date:      2021-09-20 20:43:22 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/ee3576a48b700df3d8ad4bd447346d4102b20818

8256735: JFR: 'jfr' tool displays incorrect timestamps

Reviewed-by: mseledtsov, mgronlun

! src/jdk.jfr/share/classes/jdk/jfr/internal/tool/PrettyWriter.java

Changeset: 1bd11a7f
Author:    Sergey Bylokhov 
Date:      2021-09-20 21:25:40 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/1bd11a7f2ca433f4aa9c545a20960e0778ec545e

8273887: [macos] java/awt/color/ICC_ColorSpace/MTTransformReplacedProfile.java timed out

Reviewed-by: aivanov

! test/jdk/java/awt/color/ICC_ColorSpace/MTTransformReplacedProfile.java

Changeset: 7ce60c6f
Author:    Erik Gahlin 
Date:      2021-09-20 21:58:57 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/7ce60c6ff6950bbe07fbc363303e7e6ce5e1b696

8273651: JFR: onMetadata(), setStartTime(), setEndTime() lacks test coverage

Reviewed-by: mgronlun, mseledtsov

! test/jdk/jdk/jfr/jmx/streaming/TestDelegated.java
+ test/jdk/jdk/jfr/jmx/streaming/TestMetadataEvent.java

Changeset: d16bf04c
Author:    Erik Gahlin 
Date:      2021-09-20 23:15:39 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/d16bf04c95ad20a003af70679e7b735b0780ac30

8273613: JFR: RemoteRecordingStream::start() blocks close()

Reviewed-by: mgronlun

! src/jdk.management.jfr/share/classes/jdk/management/jfr/RemoteRecordingStream.java
+ test/jdk/jdk/jfr/jmx/streaming/TestStart.java

Changeset: 9c91ff57
Author:    Joe Darcy 
Date:      2021-09-21 02:23:52 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/9c91ff57e8b4b48e997e0424ff93b29e695ec527

8274031: Typo in StringBuilder.readObject

Reviewed-by: bpb

! src/java.base/share/classes/java/lang/StringBuilder.java

Changeset: 240fa6ef
Author:    Aleksey Shipilev 
Date:      2021-09-21 05:57:57 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/240fa6efa266bc9c9f269c6215aa9df469b6eaa8

8273927: Enable hsdis for riscv64

Reviewed-by: ihse

! src/utils/hsdis/hsdis.c

Changeset: f242cb5c
Author:    Aleksey Shipilev 
Date:      2021-09-21 06:00:06 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/f242cb5ce0af3bacf7af51351121f9137db92931

8273797: Stop impersonating "server" VM in all VM variants

Reviewed-by: dholmes, erikj, ihse

! make/autoconf/flags-ldflags.m4
! make/autoconf/hotspot.m4
! make/hotspot/HotspotCommon.gmk
! make/modules/java.base/Copy.gmk
! make/modules/java.base/Lib.gmk

Changeset: 6642d2eb
Author:    Thomas Stuefe 
Date:      2021-09-21 06:27:32 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/6642d2eb8b129a2291191647197c5b3333a32989

8273783: Simplify Metaspace arena guard handling

Reviewed-by: coleenp, lucy

! src/hotspot/share/memory/metaspace.cpp
- src/hotspot/share/memory/metaspace/allocationGuard.hpp
! src/hotspot/share/memory/metaspace/metaspaceArena.cpp
! src/hotspot/share/memory/metaspace/metaspaceArena.hpp
! src/hotspot/share/memory/metaspace/metaspaceCommon.cpp
! src/hotspot/share/memory/metaspace/metaspaceSettings.cpp
! test/hotspot/gtest/metaspace/test_allocationGuard.cpp
! test/hotspot/gtest/metaspace/test_metaspace_misc.cpp
! test/hotspot/gtest/metaspace/test_metaspacearena_stress.cpp

Changeset: c60bcd09
Author:    Stefan Karlsson 
Date:      2021-09-21 07:42:36 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/c60bcd09b73f6ad176bbd73fe3c1a09545609353

8273928: Use named run ids when problem listing tests

Reviewed-by: pliden, kbarrett, dholmes

! test/hotspot/jtreg/ProblemList-zgc.txt
! test/hotspot/jtreg/ProblemList.txt
! test/hotspot/jtreg/compiler/gcbarriers/UnsafeIntrinsicsTest.java
! test/hotspot/jtreg/compiler/loopopts/TestRangeCheckPredicatesControl.java
! test/hotspot/jtreg/compiler/vectorapi/VectorRebracket128Test.java
! test/hotspot/jtreg/gc/TestReferenceClearDuringReferenceProcessing.java
! test/hotspot/jtreg/gc/stringdedup/TestStringDeduplicationAgeThreshold.java
! test/hotspot/jtreg/gc/stringdedup/TestStringDeduplicationFullGC.java
! test/hotspot/jtreg/gc/stringdedup/TestStringDeduplicationInterned.java
! test/hotspot/jtreg/gc/stringdedup/TestStringDeduplicationPrintOptions.java
! test/hotspot/jtreg/gc/stringdedup/TestStringDeduplicationTableResize.java
! test/hotspot/jtreg/gc/stringdedup/TestStringDeduplicationYoungGC.java
! test/hotspot/jtreg/runtime/os/TestTracePageSizes.java
! test/hotspot/jtreg/serviceability/dcmd/gc/HeapDumpCompressedTest.java
! test/hotspot/jtreg/serviceability/sa/ClhsdbFindPC.java
! test/hotspot/jtreg/serviceability/sa/ClhsdbPmap.java
! test/hotspot/jtreg/serviceability/sa/ClhsdbPstack.java

Changeset: 65ed0a74
Author:    Julia Boes 
Date:      2021-09-21 08:07:25 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/65ed0a742e65fe7e661e8da2adea6cd41992869e

8273655: content-types.properties files are missing some common types

Reviewed-by: bpb, dfuchs

! src/java.base/unix/classes/sun/net/www/content-types.properties
! src/java.base/windows/classes/sun/net/www/content-types.properties
! test/jdk/java/nio/file/Files/probeContentType/Basic.java

Changeset: a5108a60
Author:    Thejasvi Voniadka 
Committer: Abdul Kolarkunnu 
Date:      2021-09-21 09:01:09 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/a5108a605e6a1e427d90dbeeb8630a3d01d6b405

8273646: Add openssl from path variable also in to Default System Openssl Path in OpensslArtifactFetcher

Reviewed-by: weijun

! test/lib/jdk/test/lib/security/OpensslArtifactFetcher.java

Changeset: afd218d3
Author:    Thomas Schatzl 
Date:      2021-09-21 09:20:21 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/afd218d39a3125fcea50968edef6e6cfbacfff50

8274053: [BACKOUT] JDK-8270842: G1: Only young regions need to redirty outside references in remset.

Reviewed-by: sjohanss

! src/hotspot/share/gc/g1/g1EvacFailure.cpp

Changeset: 7acec3f1
Author:    Aleksey Shipilev 
Date:      2021-09-21 11:26:28 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/7acec3f161234b99da76193781296157b98d689c

8236505: Mark jdk/editpad/EditPadTest.java as @headful

Reviewed-by: jlahoda

! test/jdk/jdk/editpad/EditPadTest.java

Changeset: 111d5e1a
Author:    Coleen Phillimore 
Date:      2021-09-21 11:37:49 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/111d5e1a9324cb5e8d98627f6329d17fcbc9c13d

8273915: Create 'nosafepoint' rank

Reviewed-by: dholmes, iklam

! src/hotspot/share/classfile/classLoaderData.cpp
! src/hotspot/share/gc/g1/g1ServiceThread.cpp
! src/hotspot/share/gc/parallel/psCompactionManager.cpp
! src/hotspot/share/gc/shared/taskTerminator.cpp
! src/hotspot/share/gc/shared/workgroup.cpp
! src/hotspot/share/gc/z/zMessagePort.inline.hpp
! src/hotspot/share/gc/z/zMetronome.cpp
! src/hotspot/share/memory/heapInspection.hpp
! src/hotspot/share/memory/metaspace/testHelpers.cpp
! src/hotspot/share/prims/jvmtiTagMap.cpp
! src/hotspot/share/runtime/handshake.cpp
! src/hotspot/share/runtime/mutex.cpp
! src/hotspot/share/runtime/mutex.hpp
! src/hotspot/share/runtime/mutexLocker.cpp
! src/hotspot/share/runtime/vmOperations.cpp
! src/hotspot/share/runtime/vmThread.cpp
! src/hotspot/share/services/heapDumperCompression.cpp
! src/hotspot/share/services/memoryManager.cpp
! src/hotspot/share/utilities/concurrentHashTable.inline.hpp
! test/hotspot/gtest/metaspace/test_is_metaspace_obj.cpp
! test/hotspot/gtest/metaspace/test_metaspacearena.cpp
! test/hotspot/gtest/metaspace/test_metaspacearena_stress.cpp
! test/hotspot/gtest/runtime/test_mutex.cpp
! test/hotspot/gtest/runtime/test_safepoint_locks.cpp
! test/hotspot/gtest/utilities/test_filterQueue.cpp

Changeset: 57df0dbc
Author:    Erik Gahlin 
Date:      2021-09-21 12:02:00 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/57df0dbc45914969df34e6f42b6c815785e11048

8270873: JFR: Catch DirectoryIteratorException when scanning for .jfr files

Reviewed-by: mgronlun

! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/RepositoryFiles.java

Changeset: 42d5d2ab
Author:    Artem Semenov 
Committer: Anton Tarasov 
Date:      2021-09-21 12:38:29 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/42d5d2abaad8a88a5e1326ea8b4494aeb8b5748b

8274056: JavaAccessibilityUtilities leaks JNI objects

Reviewed-by: aivanov, ant

! src/java.desktop/macosx/native/libawt_lwawt/awt/JavaAccessibilityUtilities.m

Changeset: 6d91a3eb
Author:    Sean Mullan 
Date:      2021-09-21 13:45:47 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/6d91a3eb7bd1e1403cfb67f7eb8ce06d7e08e7a7

8269039: Disable SHA-1 Signed JARs

Reviewed-by: weijun

! src/java.base/share/classes/module-info.java
! src/java.base/share/classes/sun/security/provider/certpath/AlgorithmChecker.java
! src/java.base/share/classes/sun/security/provider/certpath/CertPathConstraintsParameters.java
! src/java.base/share/classes/sun/security/provider/certpath/PKIX.java
! src/java.base/share/classes/sun/security/provider/certpath/PKIXCertPathValidator.java
! src/java.base/share/classes/sun/security/provider/certpath/SunCertPathBuilder.java
! src/java.base/share/classes/sun/security/util/DisabledAlgorithmConstraints.java
! src/java.base/share/classes/sun/security/util/JarConstraintsParameters.java
! src/java.base/share/conf/security/java.security
! src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java
- test/jdk/java/security/Security/signedfirst/Dyn.sh
+ test/jdk/java/security/Security/signedfirst/DynStatic.java
- test/jdk/java/security/Security/signedfirst/Static.sh
+ test/jdk/java/security/Security/signedfirst/com/sun/exp/provider/EXP.java
+ test/jdk/java/security/Security/signedfirst/com/sun/exp/provider/SHA.java
- test/jdk/java/security/Security/signedfirst/exp.jar
- test/jdk/java/security/Security/signedfirst/keystore.jks
! test/jdk/java/util/jar/JarFile/Signed.jar
! test/jdk/java/util/jar/JarFile/test.jar
! test/jdk/java/util/jar/JarInputStream/signed.jar
! test/jdk/sun/security/tools/jarsigner/CheckSignerCertChain.java
! test/jdk/sun/security/tools/jarsigner/DiffEnd.java
! test/jdk/sun/security/tools/jarsigner/OldSig.java
+ test/jdk/sun/security/tools/jarsigner/OldSig.props
! test/jdk/sun/security/tools/jarsigner/Test4431684.java
! test/jdk/sun/security/tools/jarsigner/TimestampCheck.java
! test/lib/jdk/test/lib/security/SecurityUtils.java

Changeset: 0fc47e99
Author:    Pavel Rappo 
Date:      2021-09-21 15:53:35 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/0fc47e99d20a1ee886df878f1302769bdd913aab

8266666: Implementation for snippets

Co-authored-by: Jonathan Gibbons 
Co-authored-by: Hannes Walln?fer 
Reviewed-by: jjg

! src/java.compiler/share/classes/javax/tools/DocumentationTool.java
! src/jdk.compiler/share/classes/com/sun/source/doctree/AttributeTree.java
! src/jdk.compiler/share/classes/com/sun/source/doctree/DocTree.java
! src/jdk.compiler/share/classes/com/sun/source/doctree/DocTreeVisitor.java
+ src/jdk.compiler/share/classes/com/sun/source/doctree/SnippetTree.java
! src/jdk.compiler/share/classes/com/sun/source/util/DocTreeFactory.java
! 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/tools/javac/parser/DocCommentParser.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DCTree.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DocPretty.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DocTreeMaker.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/TagletWriterImpl.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/BaseConfiguration.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/BaseOptions.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css
+ src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/SnippetTaglet.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/snippet/Action.java
+ src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/AddStyle.java
+ src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/Attribute.java
+ src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/Attributes.java
+ src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/Bookmark.java
+ src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/MarkupParser.java
+ src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/ParseException.java
+ src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/Parser.java
+ src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/Replace.java
+ src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/Style.java
+ src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/StyledText.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/CommentHelper.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java
! test/langtools/jdk/javadoc/doclet/checkStylesheetClasses/CheckStylesheetClasses.java
+ test/langtools/jdk/javadoc/doclet/testSnippetTag/TestSnippetTag.java
! test/langtools/jdk/javadoc/doclet/testTaglets/TestTaglets.out
! test/langtools/jdk/javadoc/tool/api/basic/DocumentationToolLocationTest.java
! test/langtools/tools/doclint/EmptyHtmlTest.java
! test/langtools/tools/javac/doctree/DocCommentTester.java
+ test/langtools/tools/javac/doctree/SnippetTest.java

Changeset: 161fdb4a
Author:    Lance Andersen 
Date:      2021-09-21 19:23:49 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/161fdb4afbc6e67cc7580fe753112c4d894a9b6b

8273935: (zipfs) Files.getFileAttributeView() throws UOE instead of returning null when view not supported

Reviewed-by: alanb, bpb, sgehwolf

! src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipPath.java
! test/jdk/jdk/nio/zipfs/TestPosix.java
+ test/jdk/jdk/nio/zipfs/testng/test/PosixAttributeViewTest.java
! test/jdk/jdk/nio/zipfs/testng/util/ZipFsBaseTest.java

Changeset: a72c8aa6
Author:    Leonid Mesnik 
Date:      2021-09-21 23:36:16 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/a72c8aa6ad58bad57ddbd65139bcb88b6d8aa5db

8273921: Refactor NSK/JDI tests to create thread using factory

Reviewed-by: cjplummer, sspitsyn, amenkov

! test/hotspot/jtreg/vmTestbase/nsk/jdi/BScenarios/multithrd/tc01x001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/BScenarios/multithrd/tc02x001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/BScenarios/multithrd/tc02x002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/BScenarios/multithrd/tc02x003a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/BScenarios/multithrd/tc02x004a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/BScenarios/multithrd/tc03x001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/BScenarios/multithrd/tc04x001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/BreakpointRequest/_bounds_/filters001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/BreakpointRequest/addInstanceFilter/instancefilter001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/BreakpointRequest/addInstanceFilter/instancefilter002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/BreakpointRequest/addInstanceFilter/instancefilter003a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/BreakpointRequest/addInstanceFilter/instancefilter004a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/BreakpointRequest/addThreadFilter/threadfilter001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/BreakpointRequest/addThreadFilter/threadfilter002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/BreakpointRequest/addThreadFilter/threadfilter003a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/BreakpointRequest/addThreadFilter/threadfilter004a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/BreakpointRequest/location/location001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassPrepareRequest/addClassExclusionFilter/filter001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassPrepareRequest/addClassExclusionFilter/filter002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassPrepareRequest/addClassFilter_rt/filter_rt001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassPrepareRequest/addClassFilter_rt/filter_rt002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassPrepareRequest/addClassFilter_rt/filter_rt003a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassPrepareRequest/addClassFilter_s/filter_s001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassPrepareRequest/addClassFilter_s/filter_s002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/invokeMethod/invokemethod001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/invokeMethod/invokemethod007a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/invokeMethod/invokemethod011t.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/invokeMethod/invokemethod013t.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/newInstance/newinstance001.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/newInstance/newinstance001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/newInstance/newinstance007a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/Event/equals/equals001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/Event/hashCode/hashcode001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/Event/request/request001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventIterator/nextEvent/nextevent001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequest/addCountFilter/addcountfilter001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequest/disable/disable001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequest/disable/disable002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequest/enable/enable001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequest/enable/enable002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequest/getProperty/getproperty001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequest/isEnabled/isenabled001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequest/putProperty/putproperty001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequest/setEnabled/setenabled001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequest/setEnabled/setenabled002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequest/setEnabled/setenabled003a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequest/setSuspendPolicy/setsuspendpolicy001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequest/suspendPolicy/suspendpolicy001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/createStepRequest/crstepreq002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/createStepRequest/crstepreq003a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/createStepRequest/crstepreq004a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/createStepRequest/crstepreq005a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/createStepRequest/crstepreq006a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/createStepRequest/crstepreq007a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/createStepRequest/crstepreq008a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/createStepRequest/crstepreq009a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/createStepRequest/crstepreq010a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/deleteEventRequest/delevtreq002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/deleteEventRequests/delevtreqs002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/stepRequests/stepreq001t.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/stepRequests/stepreq002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/eventIterator/eventiterator003a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/resume/resume008a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/resume/resume009a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/suspendPolicy/suspendpolicy008a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/suspendPolicy/suspendpolicy009a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionRequest/addClassExclusionFilter/filter001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionRequest/addClassFilter_rt/filter_rt001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionRequest/addClassFilter_rt/filter_rt002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionRequest/addClassFilter_rt/filter_rt003a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionRequest/addClassFilter_s/filter_s001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionRequest/addClassFilter_s/filter_s002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionRequest/addInstanceFilter/instancefilter001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionRequest/addInstanceFilter/instancefilter002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionRequest/addInstanceFilter/instancefilter003a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionRequest/addInstanceFilter/instancefilter004a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionRequest/addThreadFilter/threadfilter001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionRequest/addThreadFilter/threadfilter002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionRequest/addThreadFilter/threadfilter004a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionRequest/notifyCaught/notifycaught001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionRequest/notifyUncaught/notifyuncaught001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/LocalVariable/isVisible/isvisible001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/Locatable/location/location004a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/Locatable/location/location005a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/LocatableEvent/thread/thread001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodEntryRequest/addClassExclusionFilter/filter001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodEntryRequest/addClassFilter_rt/filter_rt001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodEntryRequest/addClassFilter_rt/filter_rt002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodEntryRequest/addClassFilter_rt/filter_rt003a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodEntryRequest/addClassFilter_s/filter_s001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodEntryRequest/addInstanceFilter/instancefilter001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodEntryRequest/addInstanceFilter/instancefilter002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodEntryRequest/addInstanceFilter/instancefilter003a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodEntryRequest/addInstanceFilter/instancefilter004a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodEntryRequest/addThreadFilter/threadfilter001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodEntryRequest/addThreadFilter/threadfilter002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodEntryRequest/addThreadFilter/threadfilter004a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitRequest/addClassExclusionFilter/filter001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitRequest/addClassFilter_rt/filter_rt001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitRequest/addClassFilter_rt/filter_rt002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitRequest/addClassFilter_rt/filter_rt003a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitRequest/addClassFilter_s/filter_s001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitRequest/addInstanceFilter/instancefilter001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitRequest/addInstanceFilter/instancefilter002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitRequest/addInstanceFilter/instancefilter003a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitRequest/addInstanceFilter/instancefilter004a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitRequest/addThreadFilter/threadfilter001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitRequest/addThreadFilter/threadfilter002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitRequest/addThreadFilter/threadfilter003a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitRequest/addThreadFilter/threadfilter004a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/getValue/getvalue001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/owningThread/owningthread001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/owningThread/owningthread002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/getValue/getvalue001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/getValue/getvalue002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/getValues/getvalues001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/getValues/getvalues002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/location/location001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/setValue/setvalue001/setvalue001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/setValue/setvalue002/setvalue002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/setValue/setvalue003/setvalue003a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/setValue/setvalue004/setvalue004a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/thisObject/thisobject002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/thread/thread001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/visibleVariableByName/visiblevarbyname001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/visibleVariableByName/visiblevarbyname002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/visibleVariables/visiblevariables001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/visibleVariables/visiblevariables002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepRequest/addClassExclusionFilter/filter001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepRequest/addClassFilter_rt/filter_rt001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepRequest/addClassFilter_rt/filter_rt002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepRequest/addClassFilter_rt/filter_rt003a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepRequest/addClassFilter_s/filter_s001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepRequest/addClassFilter_s/filter_s002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepRequest/addInstanceFilter/instancefilter001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepRequest/addInstanceFilter/instancefilter002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepRequest/addInstanceFilter/instancefilter003a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepRequest/addInstanceFilter/instancefilter004a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepRequest/depth/depth001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepRequest/depth/depth002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepRequest/depth/depth003a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepRequest/size/size001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepRequest/size/size002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepRequest/thread/thread001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadDeathRequest/addThreadFilter/addthreadfilter001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadDeathRequest/addThreadFilter/addthreadfilter003a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadDeathRequest/addThreadFilter/addthreadfilter004a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadDeathRequest/addThreadFilter/addthreadfilter005a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/currentContendedMonitor/currentcm001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/frame/frame001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/frameCount/framecount001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/frames_ii/frames_ii001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/isAtBreakpoint/isatbreakpoint001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/isSuspended/issuspended001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/isSuspended/issuspended002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/isSuspended/issuspended003a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/isSuspended/issuspended004a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/name/name001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/popFrames/popframes001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/popFrames/popframes002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/popFrames/popframes003a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/popFrames/popframes004a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/resume/resume001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/stop/stop001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/suspend/suspend001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/suspendCount/suspendcount001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadStartEvent/thread/thread001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadStartRequest/addThreadFilter/addthreadfilter001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadStartRequest/addThreadFilter/addthreadfilter003a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadStartRequest/addThreadFilter/addthreadfilter004a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadStartRequest/addThreadFilter/addthreadfilter005a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/allThreads/allthreads001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/canGetCurrentContendedMonitor/cangccm001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/canGetMonitorInfo/cangetmonitorinfo001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/canGetOwnedMonitorInfo/cangetinfo001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/dispose/dispose002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/dispose/dispose003a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/dispose/dispose004a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/suspend/suspend001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addClassExclusionFilter/filter001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addClassExclusionFilter/filter002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addClassFilter_rt/filter_rt001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addClassFilter_rt/filter_rt002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addClassFilter_rt/filter_rt005a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addClassFilter_rt/filter_rt006a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addClassFilter_s/filter_s001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addClassFilter_s/filter_s002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addInstanceFilter/instancefilter001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addInstanceFilter/instancefilter002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addInstanceFilter/instancefilter003a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addInstanceFilter/instancefilter004a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addInstanceFilter/instancefilter005a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addInstanceFilter/instancefilter006a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addInstanceFilter/instancefilter007a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addInstanceFilter/instancefilter008a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addThreadFilter/addthreadfilter001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addThreadFilter/addthreadfilter002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addThreadFilter/addthreadfilter003a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addThreadFilter/addthreadfilter004a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addThreadFilter/addthreadfilter005a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addThreadFilter/addthreadfilter006a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addThreadFilter/addthreadfilter007a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addThreadFilter/addthreadfilter008a.java
+ test/hotspot/jtreg/vmTestbase/nsk/share/jdi/JDIThreadFactory.java
+ test/hotspot/jtreg/vmTestbase/nsk/share/jdi/NamedTask.java

Changeset: cbe57e86
Author:    Andrey Turbanov 
Committer: Sergey Bylokhov 
Date:      2021-09-22 01:26:21 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/cbe57e860487d1a31a092ec326dc64bf5599a00e

8273684: Replace usages of java.util.Stack with ArrayDeque

Reviewed-by: cjplummer, serb

! src/java.desktop/share/classes/com/sun/media/sound/DLSSoundbank.java
! src/java.desktop/share/classes/javax/swing/text/html/HTMLDocument.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CommandProcessor.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/ui/AnnotatedMemoryPanel.java

Changeset: 11cddd32
Author:    Yi Yang 
Date:      2021-09-22 02:20:30 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/11cddd3261e2bfaa4f2b9142ce9e275bbc48c72e

8272114: Unused _last_state in osThread_windows

Reviewed-by: stuefe, dholmes

! src/hotspot/os/windows/osThread_windows.hpp

Changeset: 517405e4
Author:    Ao Qi 
Committer: Yi Yang 
Date:      2021-09-22 02:28:49 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/517405e462dc6104c33471c58242ea7b244c6218

8273965: some testlibrary_tests/ir_framework tests fail when c1 disabled

Reviewed-by: chagedorn, thartmann

! 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/TestRunTests.java

Changeset: eeaf43b2
Author:    Daniel D. Daugherty 
Date:      2021-09-22 02:53:02 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/eeaf43b229941f49326ed6d0f37e77f6f0ce5409

8274114: ProblemList serviceability/sa/TestJhsdbJstackMixed.java on linux-aarch64 in -Xcomp mode

Reviewed-by: cjplummer

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

Changeset: 688b3fe2
Author:    Prasanta Sadhukhan 
Date:      2021-09-22 08:02:13 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/688b3fe2eb2593e2cad675fb0f40b8bc6adce22f

8274070: Rectify problemlist platform for failing test on macos12

Reviewed-by: azvegint

! test/jdk/ProblemList.txt

Changeset: d9872ba3
Author:    Thomas Schatzl 
Date:      2021-09-22 08:07:03 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/d9872ba3d6c5afb2ae8e17c38e2222a2a1ab9493

8273590: Move helper classes in G1 post evacuation sub tasks to cpp files

Reviewed-by: sjohanss, kbarrett

! src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.cpp
! src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.hpp

Changeset: c77ebe88
Author:    Aleksey Shipilev 
Date:      2021-09-22 08:40:04 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/c77ebe88748b0a55f1fc7a5497314a752eab1e2a

8274060: C2: Incorrect computation after JDK-8273454

Reviewed-by: thartmann, neliasso, chagedorn

! src/hotspot/share/opto/mulnode.cpp
+ test/hotspot/jtreg/compiler/integerArithmetic/TestNegAnd.java

Changeset: 51085b52
Author:    Thomas Schatzl 
Date:      2021-09-22 10:17:31 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/51085b523eb7f37c3af5b566b55eca37c127bdcf

8274054: Add custom enqueue calls during reference processing

Reviewed-by: ayang, kbarrett, sjohanss

! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp
! src/hotspot/share/gc/g1/g1FullCollector.cpp
! src/hotspot/share/gc/g1/g1YoungCollector.cpp
! src/hotspot/share/gc/parallel/psParallelCompact.cpp
! src/hotspot/share/gc/parallel/psScavenge.cpp
! src/hotspot/share/gc/serial/serialGcRefProcProxyTask.hpp
! src/hotspot/share/gc/shared/referenceProcessor.cpp
! src/hotspot/share/gc/shared/referenceProcessor.hpp
! src/hotspot/share/gc/shared/referenceProcessor.inline.hpp

Changeset: 7f78803b
Author:    sunxu 
Committer: Lance Andersen 
Date:      2021-09-22 11:38:29 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/7f78803b0926ea194334ad9b3c9f06cbe17a83dd

8273961: jdk/nio/zipfs/ZipFSTester.java fails if file path contains '+' character

Reviewed-by: clanger, lancea

! test/jdk/jdk/nio/zipfs/ZipFSTester.java

Changeset: 3f73ca7f
Author:    Thomas Schatzl 
Date:      2021-09-22 11:41:13 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/3f73ca7fcd674e10d4382ec4bd8d4cb0da1e4256

8274068: Rename G1ScanInYoungSetter to G1SkipCardEnqueueSetter

Reviewed-by: sjohanss, ayang

! src/hotspot/share/gc/g1/g1OopClosures.hpp
! src/hotspot/share/gc/g1/g1OopClosures.inline.hpp
! src/hotspot/share/gc/g1/g1ParScanThreadState.cpp

Changeset: d245a8cc
Author:    Thomas Schatzl 
Date:      2021-09-22 11:43:13 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/d245a8cc852de21547928252ed6f0474f0d49b1c

8274069: Clean up g1ParScanThreadState a bit

Reviewed-by: sjohanss, ayang, kbarrett

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

Changeset: aefd4ac4
Author:    Erik Gahlin 
Date:      2021-09-22 11:45:29 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/aefd4ac4a336f00c067bcb91b95472ccc9a6bf83

8258734: jdk/jfr/event/oldobject/TestClassLoaderLeak.java failed with "RuntimeException: Could not find class leak"

Reviewed-by: mgronlun

! test/jdk/jdk/jfr/event/oldobject/TestClassLoaderLeak.java

Changeset: ba7d550c
Author:    Jan Lahoda 
Date:      2021-09-22 12:52:31 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/ba7d550c6e6d84b36d81aafa1dfded0c99b5c248

8270139: jshell InternalError crash for import of @Repeatable followed by unresolved ref

Reviewed-by: vromero

! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java
+ test/langtools/jdk/jshell/ErrorRecoveryTest.java
+ test/langtools/tools/javac/recovery/AnnotationRecovery.java

Changeset: 71788c69
Author:    Jan Lahoda 
Date:      2021-09-22 12:53:57 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/71788c69dbae854331f3393044dab458c906045f

8271287: jdk/jshell/CommandCompletionTest.java fails with "lists don't have the same size expected"

Reviewed-by: vromero

! test/langtools/jdk/jshell/CommandCompletionTest.java

Changeset: c6df3c95
Author:    Pavel Rappo 
Date:      2021-09-22 13:42:23 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/c6df3c9571cfa9607f3deffeaa77701dde9fea15

8274071: Clean up java.lang.ref comments and documentation

Reviewed-by: rriggs, kbarrett, mchung, iris, lancea

! src/java.base/share/classes/java/lang/ref/Reference.java

Changeset: 0a361638
Author:    Roger Riggs 
Date:      2021-09-22 13:55:19 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/0a361638c5ea4d3e109d950e34a61b4737c8f670

8272600: (test) Use native "sleep" in Basic.java

Reviewed-by: iklam, dholmes

! test/jdk/java/lang/ProcessBuilder/Basic.java
+ test/jdk/java/lang/ProcessBuilder/exeBasicSleep.c

Changeset: 33df388a
Author:    Roger Riggs 
Date:      2021-09-22 13:57:37 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/33df388a24267e868574e4604b2e2ab170dc5a09

8274003: ProcessHandleImpl.Info toString has an if check which is always true

Reviewed-by: bpb, naoto, iris

! src/java.base/share/classes/java/lang/ProcessHandleImpl.java

Changeset: c9de8063
Author:    Patric Hedlin 
Date:      2021-09-22 14:20:17 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/c9de80635e25badbb5410e22b6619379598a9a57

8274039: codestrings gtest fails when hsdis is present

Reviewed-by: shade

! test/hotspot/gtest/code/test_codestrings.cpp

Changeset: d39aad92
Author:    Naoto Sato 
Date:      2021-09-22 15:50:49 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/d39aad92308fbc28bd2de164e331062ebf62da85

8273924: ArrayIndexOutOfBoundsException thrown in java.util.JapaneseImperialCalendar.add()

Reviewed-by: rriggs, iris, joehw

! src/java.base/share/classes/sun/util/calendar/BaseCalendar.java
! test/jdk/java/util/Calendar/CalendarTestScripts/JapaneseTests.java
! test/jdk/java/util/Calendar/CalendarTestScripts/japanese/japanese_add.cts

Changeset: da38ced3
Author:    Raffaello Giulietti 
Committer: Brian Burkhalter 
Date:      2021-09-22 16:16:14 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/da38ced3299cbd02f210bea4130990a43f6104bf

8271602: Add Math.ceilDiv() family parallel to Math.floorDiv() family

Reviewed-by: bpb

! src/java.base/share/classes/java/lang/Math.java
! src/java.base/share/classes/java/lang/StrictMath.java
! test/jdk/java/lang/Math/DivModTests.java
! test/jdk/java/lang/Math/ExactArithTests.java

Changeset: 81d41647
Author:    Brian Burkhalter 
Date:      2021-09-22 16:29:04 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/81d416477f9856861a5af13058bfc3028bcb9b60

8272759: (fc) java/nio/channels/FileChannel/Transfer2GPlus.java failed in timeout

Reviewed-by: alanb

! test/jdk/java/nio/channels/FileChannel/Transfer2GPlus.java

Changeset: 57fe11c9
Author:    Tom Rodriguez 
Date:      2021-09-22 17:16:41 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/57fe11c9a37c121a244b3d6c9c0a1413dc0484b7

8274120: [JVMCI] CompileBroker should resolve parameter types for JVMCI compiles

Reviewed-by: dnsimon, thartmann

! src/hotspot/share/compiler/compileBroker.cpp

Changeset: 8821b000
Author:    Alisen Chung 
Committer: Alexey Ivanov 
Date:      2021-09-22 18:32:05 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/8821b0004170e18c8e7d6e5bbe8759344ff769b1

8205137: Remove Applet support from SwingSet2
8205139: Remove Applet support from J2Ddemo

Reviewed-by: aivanov, kizune

! src/demo/share/README
! src/demo/share/jfc/J2Ddemo/java2d/J2Ddemo.java
! src/demo/share/jfc/SwingSet2/ButtonDemo.java
! src/demo/share/jfc/SwingSet2/ColorChooserDemo.java
! src/demo/share/jfc/SwingSet2/ComboBoxDemo.java
! src/demo/share/jfc/SwingSet2/DemoModule.java
! src/demo/share/jfc/SwingSet2/FileChooserDemo.java
! src/demo/share/jfc/SwingSet2/HtmlDemo.java
! src/demo/share/jfc/SwingSet2/InternalFrameDemo.java
! src/demo/share/jfc/SwingSet2/ListDemo.java
! src/demo/share/jfc/SwingSet2/OptionPaneDemo.java
! src/demo/share/jfc/SwingSet2/ProgressBarDemo.java
! src/demo/share/jfc/SwingSet2/README.txt
! src/demo/share/jfc/SwingSet2/ScrollPaneDemo.java
! src/demo/share/jfc/SwingSet2/SliderDemo.java
! src/demo/share/jfc/SwingSet2/SplitPaneDemo.java
- src/demo/share/jfc/SwingSet2/SwingSet2.html
! src/demo/share/jfc/SwingSet2/TabbedPaneDemo.java
! src/demo/share/jfc/SwingSet2/TableDemo.java
! src/demo/share/jfc/SwingSet2/ToolTipDemo.java
! src/demo/share/jfc/SwingSet2/TreeDemo.java

Changeset: 60313889
Author:    Erik Gahlin 
Date:      2021-09-22 21:28:11 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/603138895f1665e75f01bb787af3222f08abc4db

8273714: jdk/jfr/api/consumer/TestRecordedFrame.java still times out after JDK-8273047

Reviewed-by: mgronlun

! test/jdk/jdk/jfr/api/consumer/TestRecordedFrame.java
+ test/jdk/jdk/jfr/api/consumer/TestRecordedFrameType.java

Changeset: 9d3379b9
Author:    Ningsheng Jian 
Date:      2021-09-23 02:58:59 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/9d3379b9755e9739f0b8f5c29deb1d28d0f3aa81

8267356: AArch64: Vector API SVE codegen support

Co-authored-by: Xiaohong Gong 
Co-authored-by: Wang Huang 
Co-authored-by: Ningsheng Jian 
Co-authored-by: Xuejin He 
Co-authored-by: Ai Jiaming 
Co-authored-by: Eric Liu 
Reviewed-by: aph, ngasson

! src/hotspot/cpu/aarch64/aarch64.ad
! src/hotspot/cpu/aarch64/aarch64_neon.ad
! src/hotspot/cpu/aarch64/aarch64_neon_ad.m4
! src/hotspot/cpu/aarch64/aarch64_sve.ad
! src/hotspot/cpu/aarch64/aarch64_sve_ad.m4
! src/hotspot/cpu/aarch64/assembler_aarch64.cpp
! src/hotspot/cpu/aarch64/assembler_aarch64.hpp
! 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/share/opto/output.cpp
! test/hotspot/gtest/aarch64/aarch64-asmtest.py
! test/hotspot/gtest/aarch64/asmtest.out.h

Changeset: 0fbbe4c9
Author:    Ioi Lam 
Date:      2021-09-23 03:49:06 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/0fbbe4c9a779c24d5502648c866b7f1e1e50acc0

8274033: Some tier-4 CDS EpsilonGC tests throw OOM

Reviewed-by: dholmes, ccheung, minqi

! test/hotspot/jtreg/TEST.groups

Changeset: 45adc922
Author:    Prasanta Sadhukhan 
Date:      2021-09-23 05:15:37 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/45adc9227a28c8d614c41ac496bbeaa752e5fd7b

8273578: javax/swing/JMenu/4515762/bug4515762.java fails on macOS 12

Reviewed-by: jdv, serb

! test/jdk/ProblemList.txt
! test/jdk/javax/swing/JMenu/4515762/bug4515762.java

Changeset: 1c6fa113
Author:    Matthias Baesken 
Date:      2021-09-23 05:34:18 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/1c6fa113bd06585945e077f0d2004a291c27946d

8273979: move some os time related functions to os_posix for POSIX platforms

Reviewed-by: dholmes, lucy

! src/hotspot/os/aix/os_aix.cpp
! src/hotspot/os/bsd/os_bsd.cpp
! src/hotspot/os/linux/os_linux.cpp
! src/hotspot/os/posix/os_posix.cpp

Changeset: 2166ed13
Author:    Jaikiran Pai 
Date:      2021-09-23 05:37:19 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/2166ed136917bb68f8155a25e4f4a6c5c7115566

8273894: ConcurrentModificationException raised every time ReferralsCache drops referral

Reviewed-by: shade

! src/java.security.jgss/share/classes/sun/security/krb5/internal/ReferralsCache.java

Changeset: a74c099d
Author:    Lin Zang 
Date:      2021-09-23 07:00:06 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/a74c099d67272b2ef542405d30db62a82cbbebc6

8252842: Extend jmap to support parallel heap dump

Reviewed-by: rschmelter, cjplummer

! src/hotspot/share/services/attachListener.cpp
! src/hotspot/share/services/heapDumper.cpp
! src/hotspot/share/services/heapDumper.hpp
! src/hotspot/share/services/heapDumperCompression.cpp
! src/hotspot/share/services/heapDumperCompression.hpp
! test/lib/jdk/test/lib/hprof/parser/Reader.java

Changeset: 8b833bbe
Author:    Andrey Turbanov 
Committer: Christian Hagedorn 
Date:      2021-09-23 07:47:04 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/8b833bbea84829664f23d17c7f94c0379b48f365

8274048: IGV: Replace usages of Collections.sort with List.sort call

Reviewed-by: chagedorn

! src/utils/IdealGraphVisualizer/Data/src/main/java/com/sun/hotspot/igv/data/InputGraph.java
! src/utils/IdealGraphVisualizer/Data/src/main/java/com/sun/hotspot/igv/data/Properties.java
! src/utils/IdealGraphVisualizer/FilterWindow/src/main/java/com/sun/hotspot/igv/filterwindow/FilterTopComponent.java
! src/utils/IdealGraphVisualizer/Graph/src/main/java/com/sun/hotspot/igv/graph/Diagram.java
! src/utils/IdealGraphVisualizer/Graph/src/main/java/com/sun/hotspot/igv/graph/Figure.java
! src/utils/IdealGraphVisualizer/HierarchicalLayout/src/main/java/com/sun/hotspot/igv/hierarchicallayout/HierarchicalLayoutManager.java
! src/utils/IdealGraphVisualizer/ServerCompiler/src/main/java/com/sun/hotspot/igv/servercompiler/ServerCompilerScheduler.java
! src/utils/IdealGraphVisualizer/View/src/main/java/com/sun/hotspot/igv/view/NodeQuickSearch.java

Changeset: 87998565
Author:    Pavel Rappo 
Date:      2021-09-23 08:08:39 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/8799856528f5804b616b734caed3fc4ba9811bfa

8274075: Fix miscellaneous typos in java.base

Reviewed-by: dfuchs, darcy, iris, lancea, bpb

! src/java.base/share/classes/java/io/PrintStream.java
! src/java.base/share/classes/java/io/WriteAbortedException.java
! src/java.base/share/classes/java/lang/Throwable.java
! src/java.base/share/classes/java/lang/invoke/LambdaProxyClassArchive.java
! src/java.base/share/classes/java/lang/invoke/MethodHandles.java
! src/java.base/share/classes/java/nio/file/FileChannelLinesSpliterator.java
! src/java.base/share/classes/java/security/Security.java
! src/java.base/share/classes/java/util/Properties.java
! src/java.base/share/classes/java/util/stream/AbstractPipeline.java

Changeset: 4f3b626a
Author:    Andrew Haley 
Date:      2021-09-23 09:00:46 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/4f3b626a36319cbbbbdcb1c02a84486a3d4eddb6

8271567: AArch64: AES Galois CounterMode (GCM) interleaved implementation using vector instructions

Reviewed-by: ngasson, adinn, xliu

! src/hotspot/cpu/aarch64/assembler_aarch64.hpp
! src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp
+ src/hotspot/cpu/aarch64/macroAssembler_aarch64_aes.cpp
! src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp
! src/hotspot/cpu/aarch64/stubRoutines_aarch64.hpp
! src/hotspot/cpu/aarch64/vm_version_aarch64.cpp
! src/hotspot/os_cpu/bsd_aarch64/vm_version_bsd_aarch64.cpp

Changeset: d0987513
Author:    Coleen Phillimore 
Date:      2021-09-23 11:21:02 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/d0987513665def1b6b2981ab5932b6f1b8b310d8

8273916: Remove 'special' ranking

Reviewed-by: dholmes, pchilanomate

! src/hotspot/share/runtime/mutex.hpp
! src/hotspot/share/runtime/mutexLocker.cpp
! src/hotspot/share/runtime/mutexLocker.hpp
! test/hotspot/gtest/runtime/test_mutex.cpp
! test/hotspot/gtest/runtime/test_safepoint_locks.cpp

Changeset: c4345285
Author:    Naoto Sato 
Date:      2021-09-23 12:48:49 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/c43452859d7211f0d6537d71bd0df89412d4ff6f

8273546: DecimalFormat documentation contains literal HTML character references

Reviewed-by: joehw, bpb, iris, lancea

! src/java.base/share/classes/java/math/BigInteger.java
! src/java.base/share/classes/java/text/CompactNumberFormat.java
! src/java.base/share/classes/java/text/DecimalFormat.java

Changeset: 66ce09f5
Author:    Tobias Holenstein 
Committer: Tobias Hartmann 
Date:      2021-09-23 12:55:42 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/66ce09f51eb37029c8ba67a70f8c90a307dae1eb

8272703: StressSeed should be set via FLAG_SET_ERGO

Reviewed-by: chagedorn, thartmann

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

Changeset: 653a612a
Author:    Tobias Holenstein 
Committer: Tobias Hartmann 
Date:      2021-09-23 12:59:22 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/653a612a5aac266509f414c570871b7141b9347d

8270156: Add "randomness" and "stress" keys to JTreg tests which use StressGCM, StressLCM and/or StressIGVN

Reviewed-by: thartmann, chagedorn

! test/hotspot/jtreg/compiler/arguments/TestStressOptions.java
! test/hotspot/jtreg/compiler/c2/Test7179138_1.java
! test/hotspot/jtreg/compiler/c2/TestJumpTable.java
! test/hotspot/jtreg/compiler/debug/TestGenerateStressSeed.java
! test/hotspot/jtreg/compiler/debug/TestStressCM.java
! test/hotspot/jtreg/compiler/debug/TestStressIGVNAndCCP.java
! test/hotspot/jtreg/compiler/exceptions/TestSpilling.java
! test/hotspot/jtreg/compiler/loopopts/TestLostDependencyOnZeroTripGuard.java

Changeset: 1b7f4b7d
Author:    Liam Miller-Cushon 
Date:      2021-09-23 13:41:10 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/1b7f4b7dd8a6070d290875a95099780c9f060139

8274169: HotSpot Style Guide has stale link to chromium style guide

Reviewed-by: dholmes, ihse

! doc/hotspot-style.html
! doc/hotspot-style.md

Changeset: 3b1b8fc6
Author:    Roger Riggs 
Date:      2021-09-23 15:01:25 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/3b1b8fc646493eae5f4df828afe29abb75fa5e60

8269850: Most JDK releases report macOS version 12 as 10.16 instead of 12.0

Reviewed-by: naoto, clanger

! src/java.base/macosx/native/libjava/java_props_macosx.c

Changeset: 1fdc6560
Author:    Brian Burkhalter 
Date:      2021-09-23 15:57:12 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/1fdc6560841f72b761756d935dd02e4bb2395ec6

8274175: (fc) java/nio/channels/FileChannel/Transfer2GPlus.java still failed in timeout

Reviewed-by: alanb

! test/jdk/java/nio/channels/FileChannel/Transfer2GPlus.java

Changeset: 5ffbe755
Author:    Pavel Rappo 
Date:      2021-09-23 16:18:07 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/5ffbe7555771c67e28b5361d2a569f3dd858ff36

8274195: Doc cleanup in java.nio.file

Reviewed-by: alanb, lancea, bpb

! src/java.base/share/classes/java/nio/file/DirectoryStream.java
! src/java.base/share/classes/java/nio/file/Files.java

Changeset: 0aa63fec
Author:    Daniel D. Daugherty 
Date:      2021-09-23 17:14:49 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/0aa63feca8704c8958530ef9e3df128570c50e12

8274216: ProblemList 2 serviceability/dcmd/gc tests with ZGC on linux-all and windows-all

Reviewed-by: darcy, tschatzl

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

Changeset: 56b8b352
Author:    Andrey Turbanov 
Committer: Roger Riggs 
Date:      2021-09-23 20:04:36 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/56b8b35286634f2d2224ca445bc9f32ff284ae74

8273261: Replace 'while' cycles with iterator with enhanced-for in java.base

Reviewed-by: dfuchs, rriggs, iris, mullan

! src/java.base/share/classes/java/security/cert/X509CRLSelector.java
! src/java.base/share/classes/java/security/cert/X509CertSelector.java
! src/java.base/share/classes/java/text/AttributedString.java
! src/java.base/share/classes/javax/security/auth/PrivateCredentialPermission.java
! src/java.base/share/classes/javax/security/auth/Subject.java
! src/java.base/share/classes/jdk/internal/util/jar/JarIndex.java
! src/java.base/share/classes/sun/net/www/protocol/ftp/FtpURLConnection.java
! src/java.base/share/classes/sun/net/www/protocol/http/AuthCacheImpl.java
! src/java.base/share/classes/sun/security/provider/SubjectCodeSource.java
! src/java.base/share/classes/sun/security/tools/keytool/Main.java
! src/java.base/share/classes/sun/security/x509/PolicyInformation.java

Changeset: bb74ae87
Author:    Julia Boes 
Date:      2021-09-24 08:08:27 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/bb74ae87abee0fb550e4138242919ec791f7791c

8274171: java/nio/file/Files/probeContentType/Basic.java failed on "Content type" mismatches

Reviewed-by: rriggs, bpb

! test/jdk/java/nio/file/Files/probeContentType/Basic.java

Changeset: 1d440141
Author:    Hannes Walln?fer 
Date:      2021-09-24 08:51:55 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/1d44014171637b0134fb0e39f871584e6c8793f3

8273034: Make javadoc navigation collapsible on small displays

Reviewed-by: jjg

! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlIds.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/markup/HtmlAttr.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/search.js.template
! 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/stylesheet.css
! test/langtools/jdk/javadoc/doclet/checkStylesheetClasses/CheckStylesheetClasses.java
! test/langtools/jdk/javadoc/doclet/testPackageSummary/TestPackageSummary.java
! test/langtools/jdk/javadoc/doclet/testStylesheet/TestStylesheet.java

Changeset: 971aa353
Author:    Aleksey Shipilev 
Date:      2021-09-24 09:03:33 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/971aa353aae51222ca33ebfdd61b91672a6c871a

8274083: Update testing docs to mention tiered testing

Reviewed-by: dholmes, jiefu, stuefe, ihse, mseledtsov, alanb

! doc/testing.html
! doc/testing.md

Changeset: df4c2a48
Author:    duke 
Date:      2021-09-24 11:01:14 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/df4c2a4857b0c967a7cd76e8c27459f61ed0d786

Automatic merge of jdk:master into master


Changeset: 1414f2c2
Author:    duke 
Date:      2021-09-24 11:01:36 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/1414f2c2c56409ee8b7a51026f28a1b5277c03f3

Automatic merge of master into foreign-memaccess+abi



From duke at openjdk.java.net  Fri Sep 24 11:13:14 2021
From: duke at openjdk.java.net (duke)
Date: Fri, 24 Sep 2021 11:13:14 GMT
Subject: git: openjdk/panama-foreign: master: 94 new changesets
Message-ID: <15a7ec99-8f0b-49bb-bd9d-9ff6b44937ce@openjdk.org>

Changeset: 27d747ad
Author:    Matthias Baesken 
Date:      2021-09-17 12:53:38 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/27d747ad4f13193d5fc651d893540465248c48a6

8273877: os::unsetenv unused

Reviewed-by: mdoerr, stuefe

! src/hotspot/os/posix/os_posix.cpp
! src/hotspot/os/windows/os_windows.cpp
! src/hotspot/share/runtime/os.hpp

Changeset: 17f7a45c
Author:    Phil Race 
Date:      2021-09-17 15:00:52 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/17f7a45ce40ecf0666f282e68be1844d38a5d1c7

8273913: Problem list some headful client jtreg tests that fail on macOS 12

Reviewed-by: pbansal, aivanov

! test/jdk/ProblemList.txt

Changeset: 2f8c2211
Author:    Kartik Ohri 
Committer: Paul Sandoz 
Date:      2021-09-17 15:12:34 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/2f8c2211c8c7f9661e283c8df914fde5bda197a6

8273681: Add Vector API vs Arrays.mismatch intrinsic benchmark

Reviewed-by: psandoz

+ test/micro/org/openjdk/bench/jdk/incubator/vector/ArrayMismatchBenchmark.java

Changeset: 83020617
Author:    sunxu 
Committer: Calvin Cheung 
Date:      2021-09-17 16:41:51 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/83020617e70d40a42029720534af561f8af8bce2

8273774: CDSPluginTest should only expect classes_nocoops.jsa exists on supported 64-bit platforms

Reviewed-by: ccheung, mchung

! test/jdk/tools/jlink/plugins/CDSPluginTest.java

Changeset: 2a2e9190
Author:    lawrence.andrews 
Committer: Alexey Ivanov 
Date:      2021-09-17 18:11:23 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/2a2e9190d4e866ac1b712feb0e4bb61d08e112c7

8273685: Remove jtreg tag manual=yesno for java/awt/Graphics/LCDTextAndGraphicsState.java & show test instruction

Reviewed-by: aivanov, pbansal

! test/jdk/java/awt/Graphics/LCDTextAndGraphicsState.java

Changeset: bb9d1427
Author:    Thomas Stuefe 
Date:      2021-09-18 08:29:48 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/bb9d142759ece7665329b124a8ea0b16049b024a

8273958: gtest/MetaspaceGtests executes unnecessary tests in debug builds

Reviewed-by: jiefu

! test/hotspot/jtreg/gtest/MetaspaceGtests.java

Changeset: 7c9868c0
Author:    Zhengyu Gu 
Date:      2021-09-18 23:11:06 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/7c9868c0b3c9bd3d305e71f91596190813cdccce

8273454: C2: Transform (-a)*(-b) into a*b

Reviewed-by: thartmann, eliu, chagedorn

! src/hotspot/share/opto/mulnode.cpp
+ test/hotspot/jtreg/compiler/integerArithmetic/TestNegMultiply.java

Changeset: dc7f452a
Author:    Matthias Baesken 
Date:      2021-09-20 08:29:12 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/dc7f452acbe3afa5aa6e31d316bd5e669c86d6f6

8273815: move have_special_privileges to os_posix for POSIX platforms

Reviewed-by: mdoerr, stuefe, dholmes

! src/hotspot/os/aix/os_aix.cpp
! src/hotspot/os/bsd/os_bsd.cpp
! src/hotspot/os/linux/os_linux.cpp
! src/hotspot/os/posix/os_posix.cpp

Changeset: d2388b7a
Author:    Thomas Stuefe 
Date:      2021-09-20 08:46:44 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/d2388b7a0f4bfb55ea0d5648175e3253f30a4302

8273959: Some metaspace diagnostic switches should be develop

Reviewed-by: dholmes, jiefu

! src/hotspot/share/runtime/globals.hpp
! test/hotspot/jtreg/gtest/MetaspaceGtests.java

Changeset: a561eac9
Author:    Christian Hagedorn 
Date:      2021-09-20 12:53:56 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/a561eac912740da6a5982c47558e13f34481219f

8273895: compiler/ciReplay/TestVMNoCompLevel.java fails due to wrong data size with TieredStopAtLevel=2,3

Reviewed-by: kvn, dlong

! test/hotspot/jtreg/compiler/ciReplay/TestVMNoCompLevel.java

Changeset: 6f3e40c1
Author:    Christian Hagedorn 
Date:      2021-09-20 12:56:08 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/6f3e40c16db899f1add67b997dede17eeb83418f

8273825: TestIRMatching.java fails after JDK-8266550

Reviewed-by: thartmann, roland

! test/hotspot/jtreg/compiler/lib/ir_framework/IRNode.java

Changeset: f71df142
Author:    Naoto Sato 
Date:      2021-09-20 13:38:38 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/f71df142a97f522b40e90c3105e0e5bd8d5af9a2

8273187: jtools tests fail with missing markerName check

Reviewed-by: iris, sspitsyn, joehw

! test/jdk/ProblemList.txt
! test/jdk/sun/tools/jcmd/JcmdOutputEncodingTest.java
! test/jdk/sun/tools/jstack/BasicJStackTest.java

Changeset: 699865f7
Author:    Jan Lahoda 
Date:      2021-09-20 13:43:14 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/699865f76cdf76fbd8042c1b5677b71e29faa4bc

8259039: Passing different version to --release flag than javac version output warning

Reviewed-by: jjg

! src/jdk.compiler/share/classes/com/sun/tools/javac/code/ClassFinder.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/ct.properties
! src/jdk.compiler/share/classes/com/sun/tools/javac/util/Names.java
+ test/langtools/tools/javac/platform/CtPropertiesTest.java

Changeset: 1f8af524
Author:    Aleksey Shipilev 
Date:      2021-09-20 14:02:07 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/1f8af524ffe2d2d1469d8f07887b1f61c6e4d7b8

8273314: Add tier4 test groups

Reviewed-by: serb, iignatyev

! test/hotspot/jtreg/TEST.groups
! test/jaxp/TEST.groups
! test/jdk/TEST.groups
! test/langtools/TEST.groups

Changeset: 544193a3
Author:    Aleksey Shipilev 
Date:      2021-09-20 14:05:03 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/544193a3bb6431ee4bb0bd43cb29cc60c7709b25

8247980: Exclusive execution of java/util/stream tests slows down tier1

Reviewed-by: iignatyev

! test/jdk/TEST.ROOT

Changeset: 4da45c43
Author:    lawrence.andrews 
Committer: Alexey Ivanov 
Date:      2021-09-20 14:07:50 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/4da45c430139fe66fab020c2f96686dc9cf26a97

8270609: [TESTBUG] java/awt/print/Dialog/DialogCopies.java does not show instruction

Reviewed-by: aivanov

! test/jdk/java/awt/print/Dialog/DialogCopies.java

Changeset: 9aa12daa
Author:    Nils Eliasson 
Date:      2021-09-20 14:11:16 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/9aa12daa15944910c7b29d1715e8aee66cca5315

8273934: Remove unused perfcounters

Reviewed-by: chagedorn

! src/hotspot/share/compiler/compileBroker.hpp

Changeset: 4d95a5d6
Author:    Nils Eliasson 
Date:      2021-09-20 14:59:44 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/4d95a5d6dc7cc3d2b239c554a1302ac647807bd6

8273933: [TESTBUG] Test must run without preallocated exceptions

Reviewed-by: chagedorn, thartmann

! test/hotspot/jtreg/vmTestbase/jit/t/t105/t105.java

Changeset: 48aff231
Author:    Erik Gahlin 
Date:      2021-09-20 15:44:46 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/48aff23165db668eb9c06477d16a8e72b6dc6b56

8272515: JFR: Names should only be valid Java identifiers

Reviewed-by: mgronlun

! src/java.base/share/classes/jdk/internal/module/Checks.java
! src/jdk.jfr/share/classes/jdk/jfr/EventFactory.java
! src/jdk.jfr/share/classes/jdk/jfr/Name.java
! src/jdk.jfr/share/classes/jdk/jfr/ValueDescriptor.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/EventControl.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/EventInstrumentation.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/MetadataLoader.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/Type.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/TypeLibrary.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/Utils.java
! test/jdk/jdk/jfr/api/metadata/annotations/TestName.java

Changeset: dad5d271
Author:    Erik Gahlin 
Date:      2021-09-20 15:59:02 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/dad5d27172dbe24ae13b6386d1cdf15549f6619d

8272867: JFR: ManagementSupport.removeBefore() lost coverage

Reviewed-by: mseledtsov, mgronlun

! src/jdk.jfr/share/classes/jdk/jfr/internal/management/ManagementSupport.java

Changeset: 4b3a4fff
Author:    Thomas Schatzl 
Date:      2021-09-20 16:17:52 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/4b3a4fff39c1fba0d7eae719525e2a46b0a6d6ed

8273940: vmTestbase/vm/mlvm/meth/stress/gc/callSequencesDuringGC/Test.java crashes in full gc during VM exit

Reviewed-by: lkorinth

! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp
! src/hotspot/share/gc/g1/g1ConcurrentMark.hpp
! src/hotspot/share/gc/g1/g1ConcurrentMarkThread.cpp

Changeset: 26e5e9ae
Author:    Erik Gahlin 
Date:      2021-09-20 16:53:20 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/26e5e9ae8cddbbd8bc498d2951e37970358f79ba

8273654: JFR: Remove unused SecuritySupport.setAccessible(Field)

Reviewed-by: mseledtsov, shade

! src/jdk.jfr/share/classes/jdk/jfr/internal/SecuritySupport.java

Changeset: a67f0f9d
Author:    Calvin Cheung 
Date:      2021-09-20 16:56:32 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/a67f0f9dc04200c22db05e277346f24d31306b53

8273505: runtime/cds/appcds/loaderConstraints/DynamicLoaderConstraintsTest.java#default-cl crashed with SIGSEGV in MetaspaceShared::link_shared_classes

Reviewed-by: iklam, minqi

! src/hotspot/share/cds/metaspaceShared.cpp
! src/hotspot/share/classfile/classLoaderData.cpp

Changeset: b3b4b1cc
Author:    Andrey Turbanov 
Committer: Alexey Ivanov 
Date:      2021-09-20 17:23:02 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/b3b4b1cc218d4c02809eb7fd4d83d541acfbd9bd

8273907: Cleanup redundant Math.max/min calls in DefaultHighlighter

Reviewed-by: pbansal, aivanov, azvegint

! src/java.desktop/share/classes/javax/swing/text/DefaultHighlighter.java

Changeset: 5c21c004
Author:    Mikhailo Seledtsov 
Date:      2021-09-20 19:03:34 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/5c21c0044104b52fcaf3f3a830ea6e219d504ada

8267163: Rename anonymous loader tests to hidden loader tests

Reviewed-by: dholmes, hseigel

! test/hotspot/jtreg/ProblemList-Xcomp.txt
- test/hotspot/jtreg/vmTestbase/vm/mlvm/anonloader/func/findByName/Test.java
- test/hotspot/jtreg/vmTestbase/vm/mlvm/anonloader/share/AnonkTestee02.java
- test/hotspot/jtreg/vmTestbase/vm/mlvm/anonloader/stress/byteMutation/Test.java
- test/hotspot/jtreg/vmTestbase/vm/mlvm/anonloader/stress/oome/heap/Test.java
- test/hotspot/jtreg/vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java
- test/hotspot/jtreg/vmTestbase/vm/mlvm/anonloader/stress/parallelLoad/Test.java
- test/hotspot/jtreg/vmTestbase/vm/mlvm/anonloader/stress/randomBytecodes/Test.java
+ test/hotspot/jtreg/vmTestbase/vm/mlvm/hiddenloader/func/findByName/Test.java
= test/hotspot/jtreg/vmTestbase/vm/mlvm/hiddenloader/share/HiddenkTestee01.java
+ test/hotspot/jtreg/vmTestbase/vm/mlvm/hiddenloader/share/HiddenkTestee02.java
= test/hotspot/jtreg/vmTestbase/vm/mlvm/hiddenloader/share/StressClassLoadingTest.java
= test/hotspot/jtreg/vmTestbase/vm/mlvm/hiddenloader/stress/byteMutation/TEST.properties
+ test/hotspot/jtreg/vmTestbase/vm/mlvm/hiddenloader/stress/byteMutation/Test.java
= test/hotspot/jtreg/vmTestbase/vm/mlvm/hiddenloader/stress/oome/heap/TEST.properties
+ test/hotspot/jtreg/vmTestbase/vm/mlvm/hiddenloader/stress/oome/heap/Test.java
= test/hotspot/jtreg/vmTestbase/vm/mlvm/hiddenloader/stress/oome/metaspace/TEST.properties
+ test/hotspot/jtreg/vmTestbase/vm/mlvm/hiddenloader/stress/oome/metaspace/Test.java
= test/hotspot/jtreg/vmTestbase/vm/mlvm/hiddenloader/stress/parallelLoad/TEST.properties
+ test/hotspot/jtreg/vmTestbase/vm/mlvm/hiddenloader/stress/parallelLoad/Test.java
= test/hotspot/jtreg/vmTestbase/vm/mlvm/hiddenloader/stress/randomBytecodes/TEST.properties
+ test/hotspot/jtreg/vmTestbase/vm/mlvm/hiddenloader/stress/randomBytecodes/Test.java

Changeset: 04891c95
Author:    Chris Plummer 
Date:      2021-09-20 20:10:10 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/04891c95e0a29409959aa3e649964788e589a6da

8273912: Add threadControl_dumpThread(jthread) function

Reviewed-by: kevinw, sspitsyn

! src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c
! src/jdk.jdwp.agent/share/native/libjdwp/threadControl.h

Changeset: 5fde4b64
Author:    Alex Menkov 
Date:      2021-09-20 20:17:57 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/5fde4b64e25a3b3a4c01c57064624b9f930a1324

8273909: vmTestbase/nsk/jdi/Event/request/request001 can still fail with "ERROR: new event is not ThreadStartEvent"

Reviewed-by: cjplummer, sspitsyn

! test/hotspot/jtreg/vmTestbase/nsk/jdi/Event/request/request001.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventIterator/nextEvent/nextevent001.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadDeathRequest/addThreadFilter/addthreadfilter001.java
! test/hotspot/jtreg/vmTestbase/nsk/share/jdi/JDIBase.java

Changeset: ee3576a4
Author:    Erik Gahlin 
Date:      2021-09-20 20:43:22 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/ee3576a48b700df3d8ad4bd447346d4102b20818

8256735: JFR: 'jfr' tool displays incorrect timestamps

Reviewed-by: mseledtsov, mgronlun

! src/jdk.jfr/share/classes/jdk/jfr/internal/tool/PrettyWriter.java

Changeset: 1bd11a7f
Author:    Sergey Bylokhov 
Date:      2021-09-20 21:25:40 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/1bd11a7f2ca433f4aa9c545a20960e0778ec545e

8273887: [macos] java/awt/color/ICC_ColorSpace/MTTransformReplacedProfile.java timed out

Reviewed-by: aivanov

! test/jdk/java/awt/color/ICC_ColorSpace/MTTransformReplacedProfile.java

Changeset: 7ce60c6f
Author:    Erik Gahlin 
Date:      2021-09-20 21:58:57 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/7ce60c6ff6950bbe07fbc363303e7e6ce5e1b696

8273651: JFR: onMetadata(), setStartTime(), setEndTime() lacks test coverage

Reviewed-by: mgronlun, mseledtsov

! test/jdk/jdk/jfr/jmx/streaming/TestDelegated.java
+ test/jdk/jdk/jfr/jmx/streaming/TestMetadataEvent.java

Changeset: d16bf04c
Author:    Erik Gahlin 
Date:      2021-09-20 23:15:39 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/d16bf04c95ad20a003af70679e7b735b0780ac30

8273613: JFR: RemoteRecordingStream::start() blocks close()

Reviewed-by: mgronlun

! src/jdk.management.jfr/share/classes/jdk/management/jfr/RemoteRecordingStream.java
+ test/jdk/jdk/jfr/jmx/streaming/TestStart.java

Changeset: 9c91ff57
Author:    Joe Darcy 
Date:      2021-09-21 02:23:52 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/9c91ff57e8b4b48e997e0424ff93b29e695ec527

8274031: Typo in StringBuilder.readObject

Reviewed-by: bpb

! src/java.base/share/classes/java/lang/StringBuilder.java

Changeset: 240fa6ef
Author:    Aleksey Shipilev 
Date:      2021-09-21 05:57:57 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/240fa6efa266bc9c9f269c6215aa9df469b6eaa8

8273927: Enable hsdis for riscv64

Reviewed-by: ihse

! src/utils/hsdis/hsdis.c

Changeset: f242cb5c
Author:    Aleksey Shipilev 
Date:      2021-09-21 06:00:06 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/f242cb5ce0af3bacf7af51351121f9137db92931

8273797: Stop impersonating "server" VM in all VM variants

Reviewed-by: dholmes, erikj, ihse

! make/autoconf/flags-ldflags.m4
! make/autoconf/hotspot.m4
! make/hotspot/HotspotCommon.gmk
! make/modules/java.base/Copy.gmk
! make/modules/java.base/Lib.gmk

Changeset: 6642d2eb
Author:    Thomas Stuefe 
Date:      2021-09-21 06:27:32 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/6642d2eb8b129a2291191647197c5b3333a32989

8273783: Simplify Metaspace arena guard handling

Reviewed-by: coleenp, lucy

! src/hotspot/share/memory/metaspace.cpp
- src/hotspot/share/memory/metaspace/allocationGuard.hpp
! src/hotspot/share/memory/metaspace/metaspaceArena.cpp
! src/hotspot/share/memory/metaspace/metaspaceArena.hpp
! src/hotspot/share/memory/metaspace/metaspaceCommon.cpp
! src/hotspot/share/memory/metaspace/metaspaceSettings.cpp
! test/hotspot/gtest/metaspace/test_allocationGuard.cpp
! test/hotspot/gtest/metaspace/test_metaspace_misc.cpp
! test/hotspot/gtest/metaspace/test_metaspacearena_stress.cpp

Changeset: c60bcd09
Author:    Stefan Karlsson 
Date:      2021-09-21 07:42:36 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/c60bcd09b73f6ad176bbd73fe3c1a09545609353

8273928: Use named run ids when problem listing tests

Reviewed-by: pliden, kbarrett, dholmes

! test/hotspot/jtreg/ProblemList-zgc.txt
! test/hotspot/jtreg/ProblemList.txt
! test/hotspot/jtreg/compiler/gcbarriers/UnsafeIntrinsicsTest.java
! test/hotspot/jtreg/compiler/loopopts/TestRangeCheckPredicatesControl.java
! test/hotspot/jtreg/compiler/vectorapi/VectorRebracket128Test.java
! test/hotspot/jtreg/gc/TestReferenceClearDuringReferenceProcessing.java
! test/hotspot/jtreg/gc/stringdedup/TestStringDeduplicationAgeThreshold.java
! test/hotspot/jtreg/gc/stringdedup/TestStringDeduplicationFullGC.java
! test/hotspot/jtreg/gc/stringdedup/TestStringDeduplicationInterned.java
! test/hotspot/jtreg/gc/stringdedup/TestStringDeduplicationPrintOptions.java
! test/hotspot/jtreg/gc/stringdedup/TestStringDeduplicationTableResize.java
! test/hotspot/jtreg/gc/stringdedup/TestStringDeduplicationYoungGC.java
! test/hotspot/jtreg/runtime/os/TestTracePageSizes.java
! test/hotspot/jtreg/serviceability/dcmd/gc/HeapDumpCompressedTest.java
! test/hotspot/jtreg/serviceability/sa/ClhsdbFindPC.java
! test/hotspot/jtreg/serviceability/sa/ClhsdbPmap.java
! test/hotspot/jtreg/serviceability/sa/ClhsdbPstack.java

Changeset: 65ed0a74
Author:    Julia Boes 
Date:      2021-09-21 08:07:25 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/65ed0a742e65fe7e661e8da2adea6cd41992869e

8273655: content-types.properties files are missing some common types

Reviewed-by: bpb, dfuchs

! src/java.base/unix/classes/sun/net/www/content-types.properties
! src/java.base/windows/classes/sun/net/www/content-types.properties
! test/jdk/java/nio/file/Files/probeContentType/Basic.java

Changeset: a5108a60
Author:    Thejasvi Voniadka 
Committer: Abdul Kolarkunnu 
Date:      2021-09-21 09:01:09 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/a5108a605e6a1e427d90dbeeb8630a3d01d6b405

8273646: Add openssl from path variable also in to Default System Openssl Path in OpensslArtifactFetcher

Reviewed-by: weijun

! test/lib/jdk/test/lib/security/OpensslArtifactFetcher.java

Changeset: afd218d3
Author:    Thomas Schatzl 
Date:      2021-09-21 09:20:21 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/afd218d39a3125fcea50968edef6e6cfbacfff50

8274053: [BACKOUT] JDK-8270842: G1: Only young regions need to redirty outside references in remset.

Reviewed-by: sjohanss

! src/hotspot/share/gc/g1/g1EvacFailure.cpp

Changeset: 7acec3f1
Author:    Aleksey Shipilev 
Date:      2021-09-21 11:26:28 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/7acec3f161234b99da76193781296157b98d689c

8236505: Mark jdk/editpad/EditPadTest.java as @headful

Reviewed-by: jlahoda

! test/jdk/jdk/editpad/EditPadTest.java

Changeset: 111d5e1a
Author:    Coleen Phillimore 
Date:      2021-09-21 11:37:49 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/111d5e1a9324cb5e8d98627f6329d17fcbc9c13d

8273915: Create 'nosafepoint' rank

Reviewed-by: dholmes, iklam

! src/hotspot/share/classfile/classLoaderData.cpp
! src/hotspot/share/gc/g1/g1ServiceThread.cpp
! src/hotspot/share/gc/parallel/psCompactionManager.cpp
! src/hotspot/share/gc/shared/taskTerminator.cpp
! src/hotspot/share/gc/shared/workgroup.cpp
! src/hotspot/share/gc/z/zMessagePort.inline.hpp
! src/hotspot/share/gc/z/zMetronome.cpp
! src/hotspot/share/memory/heapInspection.hpp
! src/hotspot/share/memory/metaspace/testHelpers.cpp
! src/hotspot/share/prims/jvmtiTagMap.cpp
! src/hotspot/share/runtime/handshake.cpp
! src/hotspot/share/runtime/mutex.cpp
! src/hotspot/share/runtime/mutex.hpp
! src/hotspot/share/runtime/mutexLocker.cpp
! src/hotspot/share/runtime/vmOperations.cpp
! src/hotspot/share/runtime/vmThread.cpp
! src/hotspot/share/services/heapDumperCompression.cpp
! src/hotspot/share/services/memoryManager.cpp
! src/hotspot/share/utilities/concurrentHashTable.inline.hpp
! test/hotspot/gtest/metaspace/test_is_metaspace_obj.cpp
! test/hotspot/gtest/metaspace/test_metaspacearena.cpp
! test/hotspot/gtest/metaspace/test_metaspacearena_stress.cpp
! test/hotspot/gtest/runtime/test_mutex.cpp
! test/hotspot/gtest/runtime/test_safepoint_locks.cpp
! test/hotspot/gtest/utilities/test_filterQueue.cpp

Changeset: 57df0dbc
Author:    Erik Gahlin 
Date:      2021-09-21 12:02:00 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/57df0dbc45914969df34e6f42b6c815785e11048

8270873: JFR: Catch DirectoryIteratorException when scanning for .jfr files

Reviewed-by: mgronlun

! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/RepositoryFiles.java

Changeset: 42d5d2ab
Author:    Artem Semenov 
Committer: Anton Tarasov 
Date:      2021-09-21 12:38:29 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/42d5d2abaad8a88a5e1326ea8b4494aeb8b5748b

8274056: JavaAccessibilityUtilities leaks JNI objects

Reviewed-by: aivanov, ant

! src/java.desktop/macosx/native/libawt_lwawt/awt/JavaAccessibilityUtilities.m

Changeset: 6d91a3eb
Author:    Sean Mullan 
Date:      2021-09-21 13:45:47 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/6d91a3eb7bd1e1403cfb67f7eb8ce06d7e08e7a7

8269039: Disable SHA-1 Signed JARs

Reviewed-by: weijun

! src/java.base/share/classes/module-info.java
! src/java.base/share/classes/sun/security/provider/certpath/AlgorithmChecker.java
! src/java.base/share/classes/sun/security/provider/certpath/CertPathConstraintsParameters.java
! src/java.base/share/classes/sun/security/provider/certpath/PKIX.java
! src/java.base/share/classes/sun/security/provider/certpath/PKIXCertPathValidator.java
! src/java.base/share/classes/sun/security/provider/certpath/SunCertPathBuilder.java
! src/java.base/share/classes/sun/security/util/DisabledAlgorithmConstraints.java
! src/java.base/share/classes/sun/security/util/JarConstraintsParameters.java
! src/java.base/share/conf/security/java.security
! src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java
- test/jdk/java/security/Security/signedfirst/Dyn.sh
+ test/jdk/java/security/Security/signedfirst/DynStatic.java
- test/jdk/java/security/Security/signedfirst/Static.sh
+ test/jdk/java/security/Security/signedfirst/com/sun/exp/provider/EXP.java
+ test/jdk/java/security/Security/signedfirst/com/sun/exp/provider/SHA.java
- test/jdk/java/security/Security/signedfirst/exp.jar
- test/jdk/java/security/Security/signedfirst/keystore.jks
! test/jdk/java/util/jar/JarFile/Signed.jar
! test/jdk/java/util/jar/JarFile/test.jar
! test/jdk/java/util/jar/JarInputStream/signed.jar
! test/jdk/sun/security/tools/jarsigner/CheckSignerCertChain.java
! test/jdk/sun/security/tools/jarsigner/DiffEnd.java
! test/jdk/sun/security/tools/jarsigner/OldSig.java
+ test/jdk/sun/security/tools/jarsigner/OldSig.props
! test/jdk/sun/security/tools/jarsigner/Test4431684.java
! test/jdk/sun/security/tools/jarsigner/TimestampCheck.java
! test/lib/jdk/test/lib/security/SecurityUtils.java

Changeset: 0fc47e99
Author:    Pavel Rappo 
Date:      2021-09-21 15:53:35 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/0fc47e99d20a1ee886df878f1302769bdd913aab

8266666: Implementation for snippets

Co-authored-by: Jonathan Gibbons 
Co-authored-by: Hannes Walln?fer 
Reviewed-by: jjg

! src/java.compiler/share/classes/javax/tools/DocumentationTool.java
! src/jdk.compiler/share/classes/com/sun/source/doctree/AttributeTree.java
! src/jdk.compiler/share/classes/com/sun/source/doctree/DocTree.java
! src/jdk.compiler/share/classes/com/sun/source/doctree/DocTreeVisitor.java
+ src/jdk.compiler/share/classes/com/sun/source/doctree/SnippetTree.java
! src/jdk.compiler/share/classes/com/sun/source/util/DocTreeFactory.java
! 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/tools/javac/parser/DocCommentParser.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DCTree.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DocPretty.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DocTreeMaker.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/TagletWriterImpl.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/BaseConfiguration.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/BaseOptions.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css
+ src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/SnippetTaglet.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/snippet/Action.java
+ src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/AddStyle.java
+ src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/Attribute.java
+ src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/Attributes.java
+ src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/Bookmark.java
+ src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/MarkupParser.java
+ src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/ParseException.java
+ src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/Parser.java
+ src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/Replace.java
+ src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/Style.java
+ src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/StyledText.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/CommentHelper.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java
! test/langtools/jdk/javadoc/doclet/checkStylesheetClasses/CheckStylesheetClasses.java
+ test/langtools/jdk/javadoc/doclet/testSnippetTag/TestSnippetTag.java
! test/langtools/jdk/javadoc/doclet/testTaglets/TestTaglets.out
! test/langtools/jdk/javadoc/tool/api/basic/DocumentationToolLocationTest.java
! test/langtools/tools/doclint/EmptyHtmlTest.java
! test/langtools/tools/javac/doctree/DocCommentTester.java
+ test/langtools/tools/javac/doctree/SnippetTest.java

Changeset: 161fdb4a
Author:    Lance Andersen 
Date:      2021-09-21 19:23:49 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/161fdb4afbc6e67cc7580fe753112c4d894a9b6b

8273935: (zipfs) Files.getFileAttributeView() throws UOE instead of returning null when view not supported

Reviewed-by: alanb, bpb, sgehwolf

! src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipPath.java
! test/jdk/jdk/nio/zipfs/TestPosix.java
+ test/jdk/jdk/nio/zipfs/testng/test/PosixAttributeViewTest.java
! test/jdk/jdk/nio/zipfs/testng/util/ZipFsBaseTest.java

Changeset: a72c8aa6
Author:    Leonid Mesnik 
Date:      2021-09-21 23:36:16 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/a72c8aa6ad58bad57ddbd65139bcb88b6d8aa5db

8273921: Refactor NSK/JDI tests to create thread using factory

Reviewed-by: cjplummer, sspitsyn, amenkov

! test/hotspot/jtreg/vmTestbase/nsk/jdi/BScenarios/multithrd/tc01x001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/BScenarios/multithrd/tc02x001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/BScenarios/multithrd/tc02x002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/BScenarios/multithrd/tc02x003a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/BScenarios/multithrd/tc02x004a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/BScenarios/multithrd/tc03x001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/BScenarios/multithrd/tc04x001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/BreakpointRequest/_bounds_/filters001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/BreakpointRequest/addInstanceFilter/instancefilter001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/BreakpointRequest/addInstanceFilter/instancefilter002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/BreakpointRequest/addInstanceFilter/instancefilter003a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/BreakpointRequest/addInstanceFilter/instancefilter004a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/BreakpointRequest/addThreadFilter/threadfilter001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/BreakpointRequest/addThreadFilter/threadfilter002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/BreakpointRequest/addThreadFilter/threadfilter003a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/BreakpointRequest/addThreadFilter/threadfilter004a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/BreakpointRequest/location/location001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassPrepareRequest/addClassExclusionFilter/filter001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassPrepareRequest/addClassExclusionFilter/filter002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassPrepareRequest/addClassFilter_rt/filter_rt001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassPrepareRequest/addClassFilter_rt/filter_rt002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassPrepareRequest/addClassFilter_rt/filter_rt003a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassPrepareRequest/addClassFilter_s/filter_s001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassPrepareRequest/addClassFilter_s/filter_s002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/invokeMethod/invokemethod001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/invokeMethod/invokemethod007a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/invokeMethod/invokemethod011t.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/invokeMethod/invokemethod013t.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/newInstance/newinstance001.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/newInstance/newinstance001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/newInstance/newinstance007a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/Event/equals/equals001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/Event/hashCode/hashcode001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/Event/request/request001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventIterator/nextEvent/nextevent001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequest/addCountFilter/addcountfilter001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequest/disable/disable001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequest/disable/disable002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequest/enable/enable001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequest/enable/enable002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequest/getProperty/getproperty001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequest/isEnabled/isenabled001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequest/putProperty/putproperty001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequest/setEnabled/setenabled001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequest/setEnabled/setenabled002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequest/setEnabled/setenabled003a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequest/setSuspendPolicy/setsuspendpolicy001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequest/suspendPolicy/suspendpolicy001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/createStepRequest/crstepreq002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/createStepRequest/crstepreq003a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/createStepRequest/crstepreq004a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/createStepRequest/crstepreq005a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/createStepRequest/crstepreq006a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/createStepRequest/crstepreq007a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/createStepRequest/crstepreq008a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/createStepRequest/crstepreq009a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/createStepRequest/crstepreq010a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/deleteEventRequest/delevtreq002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/deleteEventRequests/delevtreqs002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/stepRequests/stepreq001t.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/stepRequests/stepreq002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/eventIterator/eventiterator003a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/resume/resume008a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/resume/resume009a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/suspendPolicy/suspendpolicy008a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/suspendPolicy/suspendpolicy009a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionRequest/addClassExclusionFilter/filter001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionRequest/addClassFilter_rt/filter_rt001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionRequest/addClassFilter_rt/filter_rt002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionRequest/addClassFilter_rt/filter_rt003a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionRequest/addClassFilter_s/filter_s001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionRequest/addClassFilter_s/filter_s002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionRequest/addInstanceFilter/instancefilter001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionRequest/addInstanceFilter/instancefilter002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionRequest/addInstanceFilter/instancefilter003a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionRequest/addInstanceFilter/instancefilter004a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionRequest/addThreadFilter/threadfilter001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionRequest/addThreadFilter/threadfilter002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionRequest/addThreadFilter/threadfilter004a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionRequest/notifyCaught/notifycaught001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionRequest/notifyUncaught/notifyuncaught001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/LocalVariable/isVisible/isvisible001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/Locatable/location/location004a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/Locatable/location/location005a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/LocatableEvent/thread/thread001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodEntryRequest/addClassExclusionFilter/filter001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodEntryRequest/addClassFilter_rt/filter_rt001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodEntryRequest/addClassFilter_rt/filter_rt002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodEntryRequest/addClassFilter_rt/filter_rt003a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodEntryRequest/addClassFilter_s/filter_s001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodEntryRequest/addInstanceFilter/instancefilter001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodEntryRequest/addInstanceFilter/instancefilter002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodEntryRequest/addInstanceFilter/instancefilter003a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodEntryRequest/addInstanceFilter/instancefilter004a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodEntryRequest/addThreadFilter/threadfilter001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodEntryRequest/addThreadFilter/threadfilter002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodEntryRequest/addThreadFilter/threadfilter004a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitRequest/addClassExclusionFilter/filter001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitRequest/addClassFilter_rt/filter_rt001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitRequest/addClassFilter_rt/filter_rt002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitRequest/addClassFilter_rt/filter_rt003a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitRequest/addClassFilter_s/filter_s001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitRequest/addInstanceFilter/instancefilter001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitRequest/addInstanceFilter/instancefilter002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitRequest/addInstanceFilter/instancefilter003a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitRequest/addInstanceFilter/instancefilter004a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitRequest/addThreadFilter/threadfilter001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitRequest/addThreadFilter/threadfilter002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitRequest/addThreadFilter/threadfilter003a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitRequest/addThreadFilter/threadfilter004a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/getValue/getvalue001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/owningThread/owningthread001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/owningThread/owningthread002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/getValue/getvalue001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/getValue/getvalue002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/getValues/getvalues001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/getValues/getvalues002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/location/location001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/setValue/setvalue001/setvalue001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/setValue/setvalue002/setvalue002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/setValue/setvalue003/setvalue003a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/setValue/setvalue004/setvalue004a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/thisObject/thisobject002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/thread/thread001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/visibleVariableByName/visiblevarbyname001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/visibleVariableByName/visiblevarbyname002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/visibleVariables/visiblevariables001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/visibleVariables/visiblevariables002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepRequest/addClassExclusionFilter/filter001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepRequest/addClassFilter_rt/filter_rt001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepRequest/addClassFilter_rt/filter_rt002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepRequest/addClassFilter_rt/filter_rt003a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepRequest/addClassFilter_s/filter_s001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepRequest/addClassFilter_s/filter_s002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepRequest/addInstanceFilter/instancefilter001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepRequest/addInstanceFilter/instancefilter002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepRequest/addInstanceFilter/instancefilter003a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepRequest/addInstanceFilter/instancefilter004a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepRequest/depth/depth001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepRequest/depth/depth002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepRequest/depth/depth003a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepRequest/size/size001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepRequest/size/size002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepRequest/thread/thread001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadDeathRequest/addThreadFilter/addthreadfilter001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadDeathRequest/addThreadFilter/addthreadfilter003a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadDeathRequest/addThreadFilter/addthreadfilter004a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadDeathRequest/addThreadFilter/addthreadfilter005a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/currentContendedMonitor/currentcm001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/frame/frame001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/frameCount/framecount001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/frames_ii/frames_ii001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/isAtBreakpoint/isatbreakpoint001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/isSuspended/issuspended001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/isSuspended/issuspended002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/isSuspended/issuspended003a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/isSuspended/issuspended004a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/name/name001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/popFrames/popframes001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/popFrames/popframes002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/popFrames/popframes003a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/popFrames/popframes004a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/resume/resume001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/stop/stop001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/suspend/suspend001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/suspendCount/suspendcount001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadStartEvent/thread/thread001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadStartRequest/addThreadFilter/addthreadfilter001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadStartRequest/addThreadFilter/addthreadfilter003a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadStartRequest/addThreadFilter/addthreadfilter004a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadStartRequest/addThreadFilter/addthreadfilter005a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/allThreads/allthreads001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/canGetCurrentContendedMonitor/cangccm001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/canGetMonitorInfo/cangetmonitorinfo001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/canGetOwnedMonitorInfo/cangetinfo001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/dispose/dispose002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/dispose/dispose003a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/dispose/dispose004a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/suspend/suspend001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addClassExclusionFilter/filter001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addClassExclusionFilter/filter002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addClassFilter_rt/filter_rt001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addClassFilter_rt/filter_rt002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addClassFilter_rt/filter_rt005a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addClassFilter_rt/filter_rt006a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addClassFilter_s/filter_s001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addClassFilter_s/filter_s002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addInstanceFilter/instancefilter001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addInstanceFilter/instancefilter002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addInstanceFilter/instancefilter003a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addInstanceFilter/instancefilter004a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addInstanceFilter/instancefilter005a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addInstanceFilter/instancefilter006a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addInstanceFilter/instancefilter007a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addInstanceFilter/instancefilter008a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addThreadFilter/addthreadfilter001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addThreadFilter/addthreadfilter002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addThreadFilter/addthreadfilter003a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addThreadFilter/addthreadfilter004a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addThreadFilter/addthreadfilter005a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addThreadFilter/addthreadfilter006a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addThreadFilter/addthreadfilter007a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addThreadFilter/addthreadfilter008a.java
+ test/hotspot/jtreg/vmTestbase/nsk/share/jdi/JDIThreadFactory.java
+ test/hotspot/jtreg/vmTestbase/nsk/share/jdi/NamedTask.java

Changeset: cbe57e86
Author:    Andrey Turbanov 
Committer: Sergey Bylokhov 
Date:      2021-09-22 01:26:21 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/cbe57e860487d1a31a092ec326dc64bf5599a00e

8273684: Replace usages of java.util.Stack with ArrayDeque

Reviewed-by: cjplummer, serb

! src/java.desktop/share/classes/com/sun/media/sound/DLSSoundbank.java
! src/java.desktop/share/classes/javax/swing/text/html/HTMLDocument.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CommandProcessor.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/ui/AnnotatedMemoryPanel.java

Changeset: 11cddd32
Author:    Yi Yang 
Date:      2021-09-22 02:20:30 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/11cddd3261e2bfaa4f2b9142ce9e275bbc48c72e

8272114: Unused _last_state in osThread_windows

Reviewed-by: stuefe, dholmes

! src/hotspot/os/windows/osThread_windows.hpp

Changeset: 517405e4
Author:    Ao Qi 
Committer: Yi Yang 
Date:      2021-09-22 02:28:49 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/517405e462dc6104c33471c58242ea7b244c6218

8273965: some testlibrary_tests/ir_framework tests fail when c1 disabled

Reviewed-by: chagedorn, thartmann

! 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/TestRunTests.java

Changeset: eeaf43b2
Author:    Daniel D. Daugherty 
Date:      2021-09-22 02:53:02 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/eeaf43b229941f49326ed6d0f37e77f6f0ce5409

8274114: ProblemList serviceability/sa/TestJhsdbJstackMixed.java on linux-aarch64 in -Xcomp mode

Reviewed-by: cjplummer

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

Changeset: 688b3fe2
Author:    Prasanta Sadhukhan 
Date:      2021-09-22 08:02:13 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/688b3fe2eb2593e2cad675fb0f40b8bc6adce22f

8274070: Rectify problemlist platform for failing test on macos12

Reviewed-by: azvegint

! test/jdk/ProblemList.txt

Changeset: d9872ba3
Author:    Thomas Schatzl 
Date:      2021-09-22 08:07:03 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/d9872ba3d6c5afb2ae8e17c38e2222a2a1ab9493

8273590: Move helper classes in G1 post evacuation sub tasks to cpp files

Reviewed-by: sjohanss, kbarrett

! src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.cpp
! src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.hpp

Changeset: c77ebe88
Author:    Aleksey Shipilev 
Date:      2021-09-22 08:40:04 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/c77ebe88748b0a55f1fc7a5497314a752eab1e2a

8274060: C2: Incorrect computation after JDK-8273454

Reviewed-by: thartmann, neliasso, chagedorn

! src/hotspot/share/opto/mulnode.cpp
+ test/hotspot/jtreg/compiler/integerArithmetic/TestNegAnd.java

Changeset: 51085b52
Author:    Thomas Schatzl 
Date:      2021-09-22 10:17:31 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/51085b523eb7f37c3af5b566b55eca37c127bdcf

8274054: Add custom enqueue calls during reference processing

Reviewed-by: ayang, kbarrett, sjohanss

! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp
! src/hotspot/share/gc/g1/g1FullCollector.cpp
! src/hotspot/share/gc/g1/g1YoungCollector.cpp
! src/hotspot/share/gc/parallel/psParallelCompact.cpp
! src/hotspot/share/gc/parallel/psScavenge.cpp
! src/hotspot/share/gc/serial/serialGcRefProcProxyTask.hpp
! src/hotspot/share/gc/shared/referenceProcessor.cpp
! src/hotspot/share/gc/shared/referenceProcessor.hpp
! src/hotspot/share/gc/shared/referenceProcessor.inline.hpp

Changeset: 7f78803b
Author:    sunxu 
Committer: Lance Andersen 
Date:      2021-09-22 11:38:29 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/7f78803b0926ea194334ad9b3c9f06cbe17a83dd

8273961: jdk/nio/zipfs/ZipFSTester.java fails if file path contains '+' character

Reviewed-by: clanger, lancea

! test/jdk/jdk/nio/zipfs/ZipFSTester.java

Changeset: 3f73ca7f
Author:    Thomas Schatzl 
Date:      2021-09-22 11:41:13 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/3f73ca7fcd674e10d4382ec4bd8d4cb0da1e4256

8274068: Rename G1ScanInYoungSetter to G1SkipCardEnqueueSetter

Reviewed-by: sjohanss, ayang

! src/hotspot/share/gc/g1/g1OopClosures.hpp
! src/hotspot/share/gc/g1/g1OopClosures.inline.hpp
! src/hotspot/share/gc/g1/g1ParScanThreadState.cpp

Changeset: d245a8cc
Author:    Thomas Schatzl 
Date:      2021-09-22 11:43:13 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/d245a8cc852de21547928252ed6f0474f0d49b1c

8274069: Clean up g1ParScanThreadState a bit

Reviewed-by: sjohanss, ayang, kbarrett

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

Changeset: aefd4ac4
Author:    Erik Gahlin 
Date:      2021-09-22 11:45:29 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/aefd4ac4a336f00c067bcb91b95472ccc9a6bf83

8258734: jdk/jfr/event/oldobject/TestClassLoaderLeak.java failed with "RuntimeException: Could not find class leak"

Reviewed-by: mgronlun

! test/jdk/jdk/jfr/event/oldobject/TestClassLoaderLeak.java

Changeset: ba7d550c
Author:    Jan Lahoda 
Date:      2021-09-22 12:52:31 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/ba7d550c6e6d84b36d81aafa1dfded0c99b5c248

8270139: jshell InternalError crash for import of @Repeatable followed by unresolved ref

Reviewed-by: vromero

! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java
+ test/langtools/jdk/jshell/ErrorRecoveryTest.java
+ test/langtools/tools/javac/recovery/AnnotationRecovery.java

Changeset: 71788c69
Author:    Jan Lahoda 
Date:      2021-09-22 12:53:57 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/71788c69dbae854331f3393044dab458c906045f

8271287: jdk/jshell/CommandCompletionTest.java fails with "lists don't have the same size expected"

Reviewed-by: vromero

! test/langtools/jdk/jshell/CommandCompletionTest.java

Changeset: c6df3c95
Author:    Pavel Rappo 
Date:      2021-09-22 13:42:23 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/c6df3c9571cfa9607f3deffeaa77701dde9fea15

8274071: Clean up java.lang.ref comments and documentation

Reviewed-by: rriggs, kbarrett, mchung, iris, lancea

! src/java.base/share/classes/java/lang/ref/Reference.java

Changeset: 0a361638
Author:    Roger Riggs 
Date:      2021-09-22 13:55:19 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/0a361638c5ea4d3e109d950e34a61b4737c8f670

8272600: (test) Use native "sleep" in Basic.java

Reviewed-by: iklam, dholmes

! test/jdk/java/lang/ProcessBuilder/Basic.java
+ test/jdk/java/lang/ProcessBuilder/exeBasicSleep.c

Changeset: 33df388a
Author:    Roger Riggs 
Date:      2021-09-22 13:57:37 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/33df388a24267e868574e4604b2e2ab170dc5a09

8274003: ProcessHandleImpl.Info toString has an if check which is always true

Reviewed-by: bpb, naoto, iris

! src/java.base/share/classes/java/lang/ProcessHandleImpl.java

Changeset: c9de8063
Author:    Patric Hedlin 
Date:      2021-09-22 14:20:17 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/c9de80635e25badbb5410e22b6619379598a9a57

8274039: codestrings gtest fails when hsdis is present

Reviewed-by: shade

! test/hotspot/gtest/code/test_codestrings.cpp

Changeset: d39aad92
Author:    Naoto Sato 
Date:      2021-09-22 15:50:49 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/d39aad92308fbc28bd2de164e331062ebf62da85

8273924: ArrayIndexOutOfBoundsException thrown in java.util.JapaneseImperialCalendar.add()

Reviewed-by: rriggs, iris, joehw

! src/java.base/share/classes/sun/util/calendar/BaseCalendar.java
! test/jdk/java/util/Calendar/CalendarTestScripts/JapaneseTests.java
! test/jdk/java/util/Calendar/CalendarTestScripts/japanese/japanese_add.cts

Changeset: da38ced3
Author:    Raffaello Giulietti 
Committer: Brian Burkhalter 
Date:      2021-09-22 16:16:14 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/da38ced3299cbd02f210bea4130990a43f6104bf

8271602: Add Math.ceilDiv() family parallel to Math.floorDiv() family

Reviewed-by: bpb

! src/java.base/share/classes/java/lang/Math.java
! src/java.base/share/classes/java/lang/StrictMath.java
! test/jdk/java/lang/Math/DivModTests.java
! test/jdk/java/lang/Math/ExactArithTests.java

Changeset: 81d41647
Author:    Brian Burkhalter 
Date:      2021-09-22 16:29:04 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/81d416477f9856861a5af13058bfc3028bcb9b60

8272759: (fc) java/nio/channels/FileChannel/Transfer2GPlus.java failed in timeout

Reviewed-by: alanb

! test/jdk/java/nio/channels/FileChannel/Transfer2GPlus.java

Changeset: 57fe11c9
Author:    Tom Rodriguez 
Date:      2021-09-22 17:16:41 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/57fe11c9a37c121a244b3d6c9c0a1413dc0484b7

8274120: [JVMCI] CompileBroker should resolve parameter types for JVMCI compiles

Reviewed-by: dnsimon, thartmann

! src/hotspot/share/compiler/compileBroker.cpp

Changeset: 8821b000
Author:    Alisen Chung 
Committer: Alexey Ivanov 
Date:      2021-09-22 18:32:05 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/8821b0004170e18c8e7d6e5bbe8759344ff769b1

8205137: Remove Applet support from SwingSet2
8205139: Remove Applet support from J2Ddemo

Reviewed-by: aivanov, kizune

! src/demo/share/README
! src/demo/share/jfc/J2Ddemo/java2d/J2Ddemo.java
! src/demo/share/jfc/SwingSet2/ButtonDemo.java
! src/demo/share/jfc/SwingSet2/ColorChooserDemo.java
! src/demo/share/jfc/SwingSet2/ComboBoxDemo.java
! src/demo/share/jfc/SwingSet2/DemoModule.java
! src/demo/share/jfc/SwingSet2/FileChooserDemo.java
! src/demo/share/jfc/SwingSet2/HtmlDemo.java
! src/demo/share/jfc/SwingSet2/InternalFrameDemo.java
! src/demo/share/jfc/SwingSet2/ListDemo.java
! src/demo/share/jfc/SwingSet2/OptionPaneDemo.java
! src/demo/share/jfc/SwingSet2/ProgressBarDemo.java
! src/demo/share/jfc/SwingSet2/README.txt
! src/demo/share/jfc/SwingSet2/ScrollPaneDemo.java
! src/demo/share/jfc/SwingSet2/SliderDemo.java
! src/demo/share/jfc/SwingSet2/SplitPaneDemo.java
- src/demo/share/jfc/SwingSet2/SwingSet2.html
! src/demo/share/jfc/SwingSet2/TabbedPaneDemo.java
! src/demo/share/jfc/SwingSet2/TableDemo.java
! src/demo/share/jfc/SwingSet2/ToolTipDemo.java
! src/demo/share/jfc/SwingSet2/TreeDemo.java

Changeset: 60313889
Author:    Erik Gahlin 
Date:      2021-09-22 21:28:11 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/603138895f1665e75f01bb787af3222f08abc4db

8273714: jdk/jfr/api/consumer/TestRecordedFrame.java still times out after JDK-8273047

Reviewed-by: mgronlun

! test/jdk/jdk/jfr/api/consumer/TestRecordedFrame.java
+ test/jdk/jdk/jfr/api/consumer/TestRecordedFrameType.java

Changeset: 9d3379b9
Author:    Ningsheng Jian 
Date:      2021-09-23 02:58:59 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/9d3379b9755e9739f0b8f5c29deb1d28d0f3aa81

8267356: AArch64: Vector API SVE codegen support

Co-authored-by: Xiaohong Gong 
Co-authored-by: Wang Huang 
Co-authored-by: Ningsheng Jian 
Co-authored-by: Xuejin He 
Co-authored-by: Ai Jiaming 
Co-authored-by: Eric Liu 
Reviewed-by: aph, ngasson

! src/hotspot/cpu/aarch64/aarch64.ad
! src/hotspot/cpu/aarch64/aarch64_neon.ad
! src/hotspot/cpu/aarch64/aarch64_neon_ad.m4
! src/hotspot/cpu/aarch64/aarch64_sve.ad
! src/hotspot/cpu/aarch64/aarch64_sve_ad.m4
! src/hotspot/cpu/aarch64/assembler_aarch64.cpp
! src/hotspot/cpu/aarch64/assembler_aarch64.hpp
! 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/share/opto/output.cpp
! test/hotspot/gtest/aarch64/aarch64-asmtest.py
! test/hotspot/gtest/aarch64/asmtest.out.h

Changeset: 0fbbe4c9
Author:    Ioi Lam 
Date:      2021-09-23 03:49:06 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/0fbbe4c9a779c24d5502648c866b7f1e1e50acc0

8274033: Some tier-4 CDS EpsilonGC tests throw OOM

Reviewed-by: dholmes, ccheung, minqi

! test/hotspot/jtreg/TEST.groups

Changeset: 45adc922
Author:    Prasanta Sadhukhan 
Date:      2021-09-23 05:15:37 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/45adc9227a28c8d614c41ac496bbeaa752e5fd7b

8273578: javax/swing/JMenu/4515762/bug4515762.java fails on macOS 12

Reviewed-by: jdv, serb

! test/jdk/ProblemList.txt
! test/jdk/javax/swing/JMenu/4515762/bug4515762.java

Changeset: 1c6fa113
Author:    Matthias Baesken 
Date:      2021-09-23 05:34:18 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/1c6fa113bd06585945e077f0d2004a291c27946d

8273979: move some os time related functions to os_posix for POSIX platforms

Reviewed-by: dholmes, lucy

! src/hotspot/os/aix/os_aix.cpp
! src/hotspot/os/bsd/os_bsd.cpp
! src/hotspot/os/linux/os_linux.cpp
! src/hotspot/os/posix/os_posix.cpp

Changeset: 2166ed13
Author:    Jaikiran Pai 
Date:      2021-09-23 05:37:19 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/2166ed136917bb68f8155a25e4f4a6c5c7115566

8273894: ConcurrentModificationException raised every time ReferralsCache drops referral

Reviewed-by: shade

! src/java.security.jgss/share/classes/sun/security/krb5/internal/ReferralsCache.java

Changeset: a74c099d
Author:    Lin Zang 
Date:      2021-09-23 07:00:06 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/a74c099d67272b2ef542405d30db62a82cbbebc6

8252842: Extend jmap to support parallel heap dump

Reviewed-by: rschmelter, cjplummer

! src/hotspot/share/services/attachListener.cpp
! src/hotspot/share/services/heapDumper.cpp
! src/hotspot/share/services/heapDumper.hpp
! src/hotspot/share/services/heapDumperCompression.cpp
! src/hotspot/share/services/heapDumperCompression.hpp
! test/lib/jdk/test/lib/hprof/parser/Reader.java

Changeset: 8b833bbe
Author:    Andrey Turbanov 
Committer: Christian Hagedorn 
Date:      2021-09-23 07:47:04 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/8b833bbea84829664f23d17c7f94c0379b48f365

8274048: IGV: Replace usages of Collections.sort with List.sort call

Reviewed-by: chagedorn

! src/utils/IdealGraphVisualizer/Data/src/main/java/com/sun/hotspot/igv/data/InputGraph.java
! src/utils/IdealGraphVisualizer/Data/src/main/java/com/sun/hotspot/igv/data/Properties.java
! src/utils/IdealGraphVisualizer/FilterWindow/src/main/java/com/sun/hotspot/igv/filterwindow/FilterTopComponent.java
! src/utils/IdealGraphVisualizer/Graph/src/main/java/com/sun/hotspot/igv/graph/Diagram.java
! src/utils/IdealGraphVisualizer/Graph/src/main/java/com/sun/hotspot/igv/graph/Figure.java
! src/utils/IdealGraphVisualizer/HierarchicalLayout/src/main/java/com/sun/hotspot/igv/hierarchicallayout/HierarchicalLayoutManager.java
! src/utils/IdealGraphVisualizer/ServerCompiler/src/main/java/com/sun/hotspot/igv/servercompiler/ServerCompilerScheduler.java
! src/utils/IdealGraphVisualizer/View/src/main/java/com/sun/hotspot/igv/view/NodeQuickSearch.java

Changeset: 87998565
Author:    Pavel Rappo 
Date:      2021-09-23 08:08:39 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/8799856528f5804b616b734caed3fc4ba9811bfa

8274075: Fix miscellaneous typos in java.base

Reviewed-by: dfuchs, darcy, iris, lancea, bpb

! src/java.base/share/classes/java/io/PrintStream.java
! src/java.base/share/classes/java/io/WriteAbortedException.java
! src/java.base/share/classes/java/lang/Throwable.java
! src/java.base/share/classes/java/lang/invoke/LambdaProxyClassArchive.java
! src/java.base/share/classes/java/lang/invoke/MethodHandles.java
! src/java.base/share/classes/java/nio/file/FileChannelLinesSpliterator.java
! src/java.base/share/classes/java/security/Security.java
! src/java.base/share/classes/java/util/Properties.java
! src/java.base/share/classes/java/util/stream/AbstractPipeline.java

Changeset: 4f3b626a
Author:    Andrew Haley 
Date:      2021-09-23 09:00:46 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/4f3b626a36319cbbbbdcb1c02a84486a3d4eddb6

8271567: AArch64: AES Galois CounterMode (GCM) interleaved implementation using vector instructions

Reviewed-by: ngasson, adinn, xliu

! src/hotspot/cpu/aarch64/assembler_aarch64.hpp
! src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp
+ src/hotspot/cpu/aarch64/macroAssembler_aarch64_aes.cpp
! src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp
! src/hotspot/cpu/aarch64/stubRoutines_aarch64.hpp
! src/hotspot/cpu/aarch64/vm_version_aarch64.cpp
! src/hotspot/os_cpu/bsd_aarch64/vm_version_bsd_aarch64.cpp

Changeset: d0987513
Author:    Coleen Phillimore 
Date:      2021-09-23 11:21:02 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/d0987513665def1b6b2981ab5932b6f1b8b310d8

8273916: Remove 'special' ranking

Reviewed-by: dholmes, pchilanomate

! src/hotspot/share/runtime/mutex.hpp
! src/hotspot/share/runtime/mutexLocker.cpp
! src/hotspot/share/runtime/mutexLocker.hpp
! test/hotspot/gtest/runtime/test_mutex.cpp
! test/hotspot/gtest/runtime/test_safepoint_locks.cpp

Changeset: c4345285
Author:    Naoto Sato 
Date:      2021-09-23 12:48:49 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/c43452859d7211f0d6537d71bd0df89412d4ff6f

8273546: DecimalFormat documentation contains literal HTML character references

Reviewed-by: joehw, bpb, iris, lancea

! src/java.base/share/classes/java/math/BigInteger.java
! src/java.base/share/classes/java/text/CompactNumberFormat.java
! src/java.base/share/classes/java/text/DecimalFormat.java

Changeset: 66ce09f5
Author:    Tobias Holenstein 
Committer: Tobias Hartmann 
Date:      2021-09-23 12:55:42 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/66ce09f51eb37029c8ba67a70f8c90a307dae1eb

8272703: StressSeed should be set via FLAG_SET_ERGO

Reviewed-by: chagedorn, thartmann

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

Changeset: 653a612a
Author:    Tobias Holenstein 
Committer: Tobias Hartmann 
Date:      2021-09-23 12:59:22 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/653a612a5aac266509f414c570871b7141b9347d

8270156: Add "randomness" and "stress" keys to JTreg tests which use StressGCM, StressLCM and/or StressIGVN

Reviewed-by: thartmann, chagedorn

! test/hotspot/jtreg/compiler/arguments/TestStressOptions.java
! test/hotspot/jtreg/compiler/c2/Test7179138_1.java
! test/hotspot/jtreg/compiler/c2/TestJumpTable.java
! test/hotspot/jtreg/compiler/debug/TestGenerateStressSeed.java
! test/hotspot/jtreg/compiler/debug/TestStressCM.java
! test/hotspot/jtreg/compiler/debug/TestStressIGVNAndCCP.java
! test/hotspot/jtreg/compiler/exceptions/TestSpilling.java
! test/hotspot/jtreg/compiler/loopopts/TestLostDependencyOnZeroTripGuard.java

Changeset: 1b7f4b7d
Author:    Liam Miller-Cushon 
Date:      2021-09-23 13:41:10 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/1b7f4b7dd8a6070d290875a95099780c9f060139

8274169: HotSpot Style Guide has stale link to chromium style guide

Reviewed-by: dholmes, ihse

! doc/hotspot-style.html
! doc/hotspot-style.md

Changeset: 3b1b8fc6
Author:    Roger Riggs 
Date:      2021-09-23 15:01:25 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/3b1b8fc646493eae5f4df828afe29abb75fa5e60

8269850: Most JDK releases report macOS version 12 as 10.16 instead of 12.0

Reviewed-by: naoto, clanger

! src/java.base/macosx/native/libjava/java_props_macosx.c

Changeset: 1fdc6560
Author:    Brian Burkhalter 
Date:      2021-09-23 15:57:12 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/1fdc6560841f72b761756d935dd02e4bb2395ec6

8274175: (fc) java/nio/channels/FileChannel/Transfer2GPlus.java still failed in timeout

Reviewed-by: alanb

! test/jdk/java/nio/channels/FileChannel/Transfer2GPlus.java

Changeset: 5ffbe755
Author:    Pavel Rappo 
Date:      2021-09-23 16:18:07 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/5ffbe7555771c67e28b5361d2a569f3dd858ff36

8274195: Doc cleanup in java.nio.file

Reviewed-by: alanb, lancea, bpb

! src/java.base/share/classes/java/nio/file/DirectoryStream.java
! src/java.base/share/classes/java/nio/file/Files.java

Changeset: 0aa63fec
Author:    Daniel D. Daugherty 
Date:      2021-09-23 17:14:49 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/0aa63feca8704c8958530ef9e3df128570c50e12

8274216: ProblemList 2 serviceability/dcmd/gc tests with ZGC on linux-all and windows-all

Reviewed-by: darcy, tschatzl

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

Changeset: 56b8b352
Author:    Andrey Turbanov 
Committer: Roger Riggs 
Date:      2021-09-23 20:04:36 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/56b8b35286634f2d2224ca445bc9f32ff284ae74

8273261: Replace 'while' cycles with iterator with enhanced-for in java.base

Reviewed-by: dfuchs, rriggs, iris, mullan

! src/java.base/share/classes/java/security/cert/X509CRLSelector.java
! src/java.base/share/classes/java/security/cert/X509CertSelector.java
! src/java.base/share/classes/java/text/AttributedString.java
! src/java.base/share/classes/javax/security/auth/PrivateCredentialPermission.java
! src/java.base/share/classes/javax/security/auth/Subject.java
! src/java.base/share/classes/jdk/internal/util/jar/JarIndex.java
! src/java.base/share/classes/sun/net/www/protocol/ftp/FtpURLConnection.java
! src/java.base/share/classes/sun/net/www/protocol/http/AuthCacheImpl.java
! src/java.base/share/classes/sun/security/provider/SubjectCodeSource.java
! src/java.base/share/classes/sun/security/tools/keytool/Main.java
! src/java.base/share/classes/sun/security/x509/PolicyInformation.java

Changeset: bb74ae87
Author:    Julia Boes 
Date:      2021-09-24 08:08:27 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/bb74ae87abee0fb550e4138242919ec791f7791c

8274171: java/nio/file/Files/probeContentType/Basic.java failed on "Content type" mismatches

Reviewed-by: rriggs, bpb

! test/jdk/java/nio/file/Files/probeContentType/Basic.java

Changeset: 1d440141
Author:    Hannes Walln?fer 
Date:      2021-09-24 08:51:55 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/1d44014171637b0134fb0e39f871584e6c8793f3

8273034: Make javadoc navigation collapsible on small displays

Reviewed-by: jjg

! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlIds.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/markup/HtmlAttr.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/search.js.template
! 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/stylesheet.css
! test/langtools/jdk/javadoc/doclet/checkStylesheetClasses/CheckStylesheetClasses.java
! test/langtools/jdk/javadoc/doclet/testPackageSummary/TestPackageSummary.java
! test/langtools/jdk/javadoc/doclet/testStylesheet/TestStylesheet.java

Changeset: 971aa353
Author:    Aleksey Shipilev 
Date:      2021-09-24 09:03:33 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/971aa353aae51222ca33ebfdd61b91672a6c871a

8274083: Update testing docs to mention tiered testing

Reviewed-by: dholmes, jiefu, stuefe, ihse, mseledtsov, alanb

! doc/testing.html
! doc/testing.md

Changeset: df4c2a48
Author:    duke 
Date:      2021-09-24 11:01:14 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/df4c2a4857b0c967a7cd76e8c27459f61ed0d786

Automatic merge of jdk:master into master



From duke at openjdk.java.net  Fri Sep 24 11:20:36 2021
From: duke at openjdk.java.net (duke)
Date: Fri, 24 Sep 2021 11:20:36 GMT
Subject: git: openjdk/panama-foreign: foreign-jextract: 96 new changesets
Message-ID: <31c32f1f-0132-4f7a-8c9b-95b3311ef74e@openjdk.org>

Changeset: 27d747ad
Author:    Matthias Baesken 
Date:      2021-09-17 12:53:38 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/27d747ad4f13193d5fc651d893540465248c48a6

8273877: os::unsetenv unused

Reviewed-by: mdoerr, stuefe

! src/hotspot/os/posix/os_posix.cpp
! src/hotspot/os/windows/os_windows.cpp
! src/hotspot/share/runtime/os.hpp

Changeset: 17f7a45c
Author:    Phil Race 
Date:      2021-09-17 15:00:52 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/17f7a45ce40ecf0666f282e68be1844d38a5d1c7

8273913: Problem list some headful client jtreg tests that fail on macOS 12

Reviewed-by: pbansal, aivanov

! test/jdk/ProblemList.txt

Changeset: 2f8c2211
Author:    Kartik Ohri 
Committer: Paul Sandoz 
Date:      2021-09-17 15:12:34 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/2f8c2211c8c7f9661e283c8df914fde5bda197a6

8273681: Add Vector API vs Arrays.mismatch intrinsic benchmark

Reviewed-by: psandoz

+ test/micro/org/openjdk/bench/jdk/incubator/vector/ArrayMismatchBenchmark.java

Changeset: 83020617
Author:    sunxu 
Committer: Calvin Cheung 
Date:      2021-09-17 16:41:51 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/83020617e70d40a42029720534af561f8af8bce2

8273774: CDSPluginTest should only expect classes_nocoops.jsa exists on supported 64-bit platforms

Reviewed-by: ccheung, mchung

! test/jdk/tools/jlink/plugins/CDSPluginTest.java

Changeset: 2a2e9190
Author:    lawrence.andrews 
Committer: Alexey Ivanov 
Date:      2021-09-17 18:11:23 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/2a2e9190d4e866ac1b712feb0e4bb61d08e112c7

8273685: Remove jtreg tag manual=yesno for java/awt/Graphics/LCDTextAndGraphicsState.java & show test instruction

Reviewed-by: aivanov, pbansal

! test/jdk/java/awt/Graphics/LCDTextAndGraphicsState.java

Changeset: bb9d1427
Author:    Thomas Stuefe 
Date:      2021-09-18 08:29:48 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/bb9d142759ece7665329b124a8ea0b16049b024a

8273958: gtest/MetaspaceGtests executes unnecessary tests in debug builds

Reviewed-by: jiefu

! test/hotspot/jtreg/gtest/MetaspaceGtests.java

Changeset: 7c9868c0
Author:    Zhengyu Gu 
Date:      2021-09-18 23:11:06 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/7c9868c0b3c9bd3d305e71f91596190813cdccce

8273454: C2: Transform (-a)*(-b) into a*b

Reviewed-by: thartmann, eliu, chagedorn

! src/hotspot/share/opto/mulnode.cpp
+ test/hotspot/jtreg/compiler/integerArithmetic/TestNegMultiply.java

Changeset: dc7f452a
Author:    Matthias Baesken 
Date:      2021-09-20 08:29:12 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/dc7f452acbe3afa5aa6e31d316bd5e669c86d6f6

8273815: move have_special_privileges to os_posix for POSIX platforms

Reviewed-by: mdoerr, stuefe, dholmes

! src/hotspot/os/aix/os_aix.cpp
! src/hotspot/os/bsd/os_bsd.cpp
! src/hotspot/os/linux/os_linux.cpp
! src/hotspot/os/posix/os_posix.cpp

Changeset: d2388b7a
Author:    Thomas Stuefe 
Date:      2021-09-20 08:46:44 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/d2388b7a0f4bfb55ea0d5648175e3253f30a4302

8273959: Some metaspace diagnostic switches should be develop

Reviewed-by: dholmes, jiefu

! src/hotspot/share/runtime/globals.hpp
! test/hotspot/jtreg/gtest/MetaspaceGtests.java

Changeset: a561eac9
Author:    Christian Hagedorn 
Date:      2021-09-20 12:53:56 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/a561eac912740da6a5982c47558e13f34481219f

8273895: compiler/ciReplay/TestVMNoCompLevel.java fails due to wrong data size with TieredStopAtLevel=2,3

Reviewed-by: kvn, dlong

! test/hotspot/jtreg/compiler/ciReplay/TestVMNoCompLevel.java

Changeset: 6f3e40c1
Author:    Christian Hagedorn 
Date:      2021-09-20 12:56:08 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/6f3e40c16db899f1add67b997dede17eeb83418f

8273825: TestIRMatching.java fails after JDK-8266550

Reviewed-by: thartmann, roland

! test/hotspot/jtreg/compiler/lib/ir_framework/IRNode.java

Changeset: f71df142
Author:    Naoto Sato 
Date:      2021-09-20 13:38:38 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/f71df142a97f522b40e90c3105e0e5bd8d5af9a2

8273187: jtools tests fail with missing markerName check

Reviewed-by: iris, sspitsyn, joehw

! test/jdk/ProblemList.txt
! test/jdk/sun/tools/jcmd/JcmdOutputEncodingTest.java
! test/jdk/sun/tools/jstack/BasicJStackTest.java

Changeset: 699865f7
Author:    Jan Lahoda 
Date:      2021-09-20 13:43:14 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/699865f76cdf76fbd8042c1b5677b71e29faa4bc

8259039: Passing different version to --release flag than javac version output warning

Reviewed-by: jjg

! src/jdk.compiler/share/classes/com/sun/tools/javac/code/ClassFinder.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/ct.properties
! src/jdk.compiler/share/classes/com/sun/tools/javac/util/Names.java
+ test/langtools/tools/javac/platform/CtPropertiesTest.java

Changeset: 1f8af524
Author:    Aleksey Shipilev 
Date:      2021-09-20 14:02:07 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/1f8af524ffe2d2d1469d8f07887b1f61c6e4d7b8

8273314: Add tier4 test groups

Reviewed-by: serb, iignatyev

! test/hotspot/jtreg/TEST.groups
! test/jaxp/TEST.groups
! test/jdk/TEST.groups
! test/langtools/TEST.groups

Changeset: 544193a3
Author:    Aleksey Shipilev 
Date:      2021-09-20 14:05:03 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/544193a3bb6431ee4bb0bd43cb29cc60c7709b25

8247980: Exclusive execution of java/util/stream tests slows down tier1

Reviewed-by: iignatyev

! test/jdk/TEST.ROOT

Changeset: 4da45c43
Author:    lawrence.andrews 
Committer: Alexey Ivanov 
Date:      2021-09-20 14:07:50 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/4da45c430139fe66fab020c2f96686dc9cf26a97

8270609: [TESTBUG] java/awt/print/Dialog/DialogCopies.java does not show instruction

Reviewed-by: aivanov

! test/jdk/java/awt/print/Dialog/DialogCopies.java

Changeset: 9aa12daa
Author:    Nils Eliasson 
Date:      2021-09-20 14:11:16 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/9aa12daa15944910c7b29d1715e8aee66cca5315

8273934: Remove unused perfcounters

Reviewed-by: chagedorn

! src/hotspot/share/compiler/compileBroker.hpp

Changeset: 4d95a5d6
Author:    Nils Eliasson 
Date:      2021-09-20 14:59:44 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/4d95a5d6dc7cc3d2b239c554a1302ac647807bd6

8273933: [TESTBUG] Test must run without preallocated exceptions

Reviewed-by: chagedorn, thartmann

! test/hotspot/jtreg/vmTestbase/jit/t/t105/t105.java

Changeset: 48aff231
Author:    Erik Gahlin 
Date:      2021-09-20 15:44:46 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/48aff23165db668eb9c06477d16a8e72b6dc6b56

8272515: JFR: Names should only be valid Java identifiers

Reviewed-by: mgronlun

! src/java.base/share/classes/jdk/internal/module/Checks.java
! src/jdk.jfr/share/classes/jdk/jfr/EventFactory.java
! src/jdk.jfr/share/classes/jdk/jfr/Name.java
! src/jdk.jfr/share/classes/jdk/jfr/ValueDescriptor.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/EventControl.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/EventInstrumentation.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/MetadataLoader.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/Type.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/TypeLibrary.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/Utils.java
! test/jdk/jdk/jfr/api/metadata/annotations/TestName.java

Changeset: dad5d271
Author:    Erik Gahlin 
Date:      2021-09-20 15:59:02 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/dad5d27172dbe24ae13b6386d1cdf15549f6619d

8272867: JFR: ManagementSupport.removeBefore() lost coverage

Reviewed-by: mseledtsov, mgronlun

! src/jdk.jfr/share/classes/jdk/jfr/internal/management/ManagementSupport.java

Changeset: 4b3a4fff
Author:    Thomas Schatzl 
Date:      2021-09-20 16:17:52 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/4b3a4fff39c1fba0d7eae719525e2a46b0a6d6ed

8273940: vmTestbase/vm/mlvm/meth/stress/gc/callSequencesDuringGC/Test.java crashes in full gc during VM exit

Reviewed-by: lkorinth

! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp
! src/hotspot/share/gc/g1/g1ConcurrentMark.hpp
! src/hotspot/share/gc/g1/g1ConcurrentMarkThread.cpp

Changeset: 26e5e9ae
Author:    Erik Gahlin 
Date:      2021-09-20 16:53:20 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/26e5e9ae8cddbbd8bc498d2951e37970358f79ba

8273654: JFR: Remove unused SecuritySupport.setAccessible(Field)

Reviewed-by: mseledtsov, shade

! src/jdk.jfr/share/classes/jdk/jfr/internal/SecuritySupport.java

Changeset: a67f0f9d
Author:    Calvin Cheung 
Date:      2021-09-20 16:56:32 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/a67f0f9dc04200c22db05e277346f24d31306b53

8273505: runtime/cds/appcds/loaderConstraints/DynamicLoaderConstraintsTest.java#default-cl crashed with SIGSEGV in MetaspaceShared::link_shared_classes

Reviewed-by: iklam, minqi

! src/hotspot/share/cds/metaspaceShared.cpp
! src/hotspot/share/classfile/classLoaderData.cpp

Changeset: b3b4b1cc
Author:    Andrey Turbanov 
Committer: Alexey Ivanov 
Date:      2021-09-20 17:23:02 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/b3b4b1cc218d4c02809eb7fd4d83d541acfbd9bd

8273907: Cleanup redundant Math.max/min calls in DefaultHighlighter

Reviewed-by: pbansal, aivanov, azvegint

! src/java.desktop/share/classes/javax/swing/text/DefaultHighlighter.java

Changeset: 5c21c004
Author:    Mikhailo Seledtsov 
Date:      2021-09-20 19:03:34 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/5c21c0044104b52fcaf3f3a830ea6e219d504ada

8267163: Rename anonymous loader tests to hidden loader tests

Reviewed-by: dholmes, hseigel

! test/hotspot/jtreg/ProblemList-Xcomp.txt
- test/hotspot/jtreg/vmTestbase/vm/mlvm/anonloader/func/findByName/Test.java
- test/hotspot/jtreg/vmTestbase/vm/mlvm/anonloader/share/AnonkTestee02.java
- test/hotspot/jtreg/vmTestbase/vm/mlvm/anonloader/stress/byteMutation/Test.java
- test/hotspot/jtreg/vmTestbase/vm/mlvm/anonloader/stress/oome/heap/Test.java
- test/hotspot/jtreg/vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java
- test/hotspot/jtreg/vmTestbase/vm/mlvm/anonloader/stress/parallelLoad/Test.java
- test/hotspot/jtreg/vmTestbase/vm/mlvm/anonloader/stress/randomBytecodes/Test.java
+ test/hotspot/jtreg/vmTestbase/vm/mlvm/hiddenloader/func/findByName/Test.java
= test/hotspot/jtreg/vmTestbase/vm/mlvm/hiddenloader/share/HiddenkTestee01.java
+ test/hotspot/jtreg/vmTestbase/vm/mlvm/hiddenloader/share/HiddenkTestee02.java
= test/hotspot/jtreg/vmTestbase/vm/mlvm/hiddenloader/share/StressClassLoadingTest.java
= test/hotspot/jtreg/vmTestbase/vm/mlvm/hiddenloader/stress/byteMutation/TEST.properties
+ test/hotspot/jtreg/vmTestbase/vm/mlvm/hiddenloader/stress/byteMutation/Test.java
= test/hotspot/jtreg/vmTestbase/vm/mlvm/hiddenloader/stress/oome/heap/TEST.properties
+ test/hotspot/jtreg/vmTestbase/vm/mlvm/hiddenloader/stress/oome/heap/Test.java
= test/hotspot/jtreg/vmTestbase/vm/mlvm/hiddenloader/stress/oome/metaspace/TEST.properties
+ test/hotspot/jtreg/vmTestbase/vm/mlvm/hiddenloader/stress/oome/metaspace/Test.java
= test/hotspot/jtreg/vmTestbase/vm/mlvm/hiddenloader/stress/parallelLoad/TEST.properties
+ test/hotspot/jtreg/vmTestbase/vm/mlvm/hiddenloader/stress/parallelLoad/Test.java
= test/hotspot/jtreg/vmTestbase/vm/mlvm/hiddenloader/stress/randomBytecodes/TEST.properties
+ test/hotspot/jtreg/vmTestbase/vm/mlvm/hiddenloader/stress/randomBytecodes/Test.java

Changeset: 04891c95
Author:    Chris Plummer 
Date:      2021-09-20 20:10:10 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/04891c95e0a29409959aa3e649964788e589a6da

8273912: Add threadControl_dumpThread(jthread) function

Reviewed-by: kevinw, sspitsyn

! src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c
! src/jdk.jdwp.agent/share/native/libjdwp/threadControl.h

Changeset: 5fde4b64
Author:    Alex Menkov 
Date:      2021-09-20 20:17:57 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/5fde4b64e25a3b3a4c01c57064624b9f930a1324

8273909: vmTestbase/nsk/jdi/Event/request/request001 can still fail with "ERROR: new event is not ThreadStartEvent"

Reviewed-by: cjplummer, sspitsyn

! test/hotspot/jtreg/vmTestbase/nsk/jdi/Event/request/request001.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventIterator/nextEvent/nextevent001.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadDeathRequest/addThreadFilter/addthreadfilter001.java
! test/hotspot/jtreg/vmTestbase/nsk/share/jdi/JDIBase.java

Changeset: ee3576a4
Author:    Erik Gahlin 
Date:      2021-09-20 20:43:22 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/ee3576a48b700df3d8ad4bd447346d4102b20818

8256735: JFR: 'jfr' tool displays incorrect timestamps

Reviewed-by: mseledtsov, mgronlun

! src/jdk.jfr/share/classes/jdk/jfr/internal/tool/PrettyWriter.java

Changeset: 1bd11a7f
Author:    Sergey Bylokhov 
Date:      2021-09-20 21:25:40 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/1bd11a7f2ca433f4aa9c545a20960e0778ec545e

8273887: [macos] java/awt/color/ICC_ColorSpace/MTTransformReplacedProfile.java timed out

Reviewed-by: aivanov

! test/jdk/java/awt/color/ICC_ColorSpace/MTTransformReplacedProfile.java

Changeset: 7ce60c6f
Author:    Erik Gahlin 
Date:      2021-09-20 21:58:57 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/7ce60c6ff6950bbe07fbc363303e7e6ce5e1b696

8273651: JFR: onMetadata(), setStartTime(), setEndTime() lacks test coverage

Reviewed-by: mgronlun, mseledtsov

! test/jdk/jdk/jfr/jmx/streaming/TestDelegated.java
+ test/jdk/jdk/jfr/jmx/streaming/TestMetadataEvent.java

Changeset: d16bf04c
Author:    Erik Gahlin 
Date:      2021-09-20 23:15:39 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/d16bf04c95ad20a003af70679e7b735b0780ac30

8273613: JFR: RemoteRecordingStream::start() blocks close()

Reviewed-by: mgronlun

! src/jdk.management.jfr/share/classes/jdk/management/jfr/RemoteRecordingStream.java
+ test/jdk/jdk/jfr/jmx/streaming/TestStart.java

Changeset: 9c91ff57
Author:    Joe Darcy 
Date:      2021-09-21 02:23:52 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/9c91ff57e8b4b48e997e0424ff93b29e695ec527

8274031: Typo in StringBuilder.readObject

Reviewed-by: bpb

! src/java.base/share/classes/java/lang/StringBuilder.java

Changeset: 240fa6ef
Author:    Aleksey Shipilev 
Date:      2021-09-21 05:57:57 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/240fa6efa266bc9c9f269c6215aa9df469b6eaa8

8273927: Enable hsdis for riscv64

Reviewed-by: ihse

! src/utils/hsdis/hsdis.c

Changeset: f242cb5c
Author:    Aleksey Shipilev 
Date:      2021-09-21 06:00:06 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/f242cb5ce0af3bacf7af51351121f9137db92931

8273797: Stop impersonating "server" VM in all VM variants

Reviewed-by: dholmes, erikj, ihse

! make/autoconf/flags-ldflags.m4
! make/autoconf/hotspot.m4
! make/hotspot/HotspotCommon.gmk
! make/modules/java.base/Copy.gmk
! make/modules/java.base/Lib.gmk

Changeset: 6642d2eb
Author:    Thomas Stuefe 
Date:      2021-09-21 06:27:32 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/6642d2eb8b129a2291191647197c5b3333a32989

8273783: Simplify Metaspace arena guard handling

Reviewed-by: coleenp, lucy

! src/hotspot/share/memory/metaspace.cpp
- src/hotspot/share/memory/metaspace/allocationGuard.hpp
! src/hotspot/share/memory/metaspace/metaspaceArena.cpp
! src/hotspot/share/memory/metaspace/metaspaceArena.hpp
! src/hotspot/share/memory/metaspace/metaspaceCommon.cpp
! src/hotspot/share/memory/metaspace/metaspaceSettings.cpp
! test/hotspot/gtest/metaspace/test_allocationGuard.cpp
! test/hotspot/gtest/metaspace/test_metaspace_misc.cpp
! test/hotspot/gtest/metaspace/test_metaspacearena_stress.cpp

Changeset: c60bcd09
Author:    Stefan Karlsson 
Date:      2021-09-21 07:42:36 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/c60bcd09b73f6ad176bbd73fe3c1a09545609353

8273928: Use named run ids when problem listing tests

Reviewed-by: pliden, kbarrett, dholmes

! test/hotspot/jtreg/ProblemList-zgc.txt
! test/hotspot/jtreg/ProblemList.txt
! test/hotspot/jtreg/compiler/gcbarriers/UnsafeIntrinsicsTest.java
! test/hotspot/jtreg/compiler/loopopts/TestRangeCheckPredicatesControl.java
! test/hotspot/jtreg/compiler/vectorapi/VectorRebracket128Test.java
! test/hotspot/jtreg/gc/TestReferenceClearDuringReferenceProcessing.java
! test/hotspot/jtreg/gc/stringdedup/TestStringDeduplicationAgeThreshold.java
! test/hotspot/jtreg/gc/stringdedup/TestStringDeduplicationFullGC.java
! test/hotspot/jtreg/gc/stringdedup/TestStringDeduplicationInterned.java
! test/hotspot/jtreg/gc/stringdedup/TestStringDeduplicationPrintOptions.java
! test/hotspot/jtreg/gc/stringdedup/TestStringDeduplicationTableResize.java
! test/hotspot/jtreg/gc/stringdedup/TestStringDeduplicationYoungGC.java
! test/hotspot/jtreg/runtime/os/TestTracePageSizes.java
! test/hotspot/jtreg/serviceability/dcmd/gc/HeapDumpCompressedTest.java
! test/hotspot/jtreg/serviceability/sa/ClhsdbFindPC.java
! test/hotspot/jtreg/serviceability/sa/ClhsdbPmap.java
! test/hotspot/jtreg/serviceability/sa/ClhsdbPstack.java

Changeset: 65ed0a74
Author:    Julia Boes 
Date:      2021-09-21 08:07:25 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/65ed0a742e65fe7e661e8da2adea6cd41992869e

8273655: content-types.properties files are missing some common types

Reviewed-by: bpb, dfuchs

! src/java.base/unix/classes/sun/net/www/content-types.properties
! src/java.base/windows/classes/sun/net/www/content-types.properties
! test/jdk/java/nio/file/Files/probeContentType/Basic.java

Changeset: a5108a60
Author:    Thejasvi Voniadka 
Committer: Abdul Kolarkunnu 
Date:      2021-09-21 09:01:09 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/a5108a605e6a1e427d90dbeeb8630a3d01d6b405

8273646: Add openssl from path variable also in to Default System Openssl Path in OpensslArtifactFetcher

Reviewed-by: weijun

! test/lib/jdk/test/lib/security/OpensslArtifactFetcher.java

Changeset: afd218d3
Author:    Thomas Schatzl 
Date:      2021-09-21 09:20:21 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/afd218d39a3125fcea50968edef6e6cfbacfff50

8274053: [BACKOUT] JDK-8270842: G1: Only young regions need to redirty outside references in remset.

Reviewed-by: sjohanss

! src/hotspot/share/gc/g1/g1EvacFailure.cpp

Changeset: 7acec3f1
Author:    Aleksey Shipilev 
Date:      2021-09-21 11:26:28 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/7acec3f161234b99da76193781296157b98d689c

8236505: Mark jdk/editpad/EditPadTest.java as @headful

Reviewed-by: jlahoda

! test/jdk/jdk/editpad/EditPadTest.java

Changeset: 111d5e1a
Author:    Coleen Phillimore 
Date:      2021-09-21 11:37:49 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/111d5e1a9324cb5e8d98627f6329d17fcbc9c13d

8273915: Create 'nosafepoint' rank

Reviewed-by: dholmes, iklam

! src/hotspot/share/classfile/classLoaderData.cpp
! src/hotspot/share/gc/g1/g1ServiceThread.cpp
! src/hotspot/share/gc/parallel/psCompactionManager.cpp
! src/hotspot/share/gc/shared/taskTerminator.cpp
! src/hotspot/share/gc/shared/workgroup.cpp
! src/hotspot/share/gc/z/zMessagePort.inline.hpp
! src/hotspot/share/gc/z/zMetronome.cpp
! src/hotspot/share/memory/heapInspection.hpp
! src/hotspot/share/memory/metaspace/testHelpers.cpp
! src/hotspot/share/prims/jvmtiTagMap.cpp
! src/hotspot/share/runtime/handshake.cpp
! src/hotspot/share/runtime/mutex.cpp
! src/hotspot/share/runtime/mutex.hpp
! src/hotspot/share/runtime/mutexLocker.cpp
! src/hotspot/share/runtime/vmOperations.cpp
! src/hotspot/share/runtime/vmThread.cpp
! src/hotspot/share/services/heapDumperCompression.cpp
! src/hotspot/share/services/memoryManager.cpp
! src/hotspot/share/utilities/concurrentHashTable.inline.hpp
! test/hotspot/gtest/metaspace/test_is_metaspace_obj.cpp
! test/hotspot/gtest/metaspace/test_metaspacearena.cpp
! test/hotspot/gtest/metaspace/test_metaspacearena_stress.cpp
! test/hotspot/gtest/runtime/test_mutex.cpp
! test/hotspot/gtest/runtime/test_safepoint_locks.cpp
! test/hotspot/gtest/utilities/test_filterQueue.cpp

Changeset: 57df0dbc
Author:    Erik Gahlin 
Date:      2021-09-21 12:02:00 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/57df0dbc45914969df34e6f42b6c815785e11048

8270873: JFR: Catch DirectoryIteratorException when scanning for .jfr files

Reviewed-by: mgronlun

! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/RepositoryFiles.java

Changeset: 42d5d2ab
Author:    Artem Semenov 
Committer: Anton Tarasov 
Date:      2021-09-21 12:38:29 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/42d5d2abaad8a88a5e1326ea8b4494aeb8b5748b

8274056: JavaAccessibilityUtilities leaks JNI objects

Reviewed-by: aivanov, ant

! src/java.desktop/macosx/native/libawt_lwawt/awt/JavaAccessibilityUtilities.m

Changeset: 6d91a3eb
Author:    Sean Mullan 
Date:      2021-09-21 13:45:47 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/6d91a3eb7bd1e1403cfb67f7eb8ce06d7e08e7a7

8269039: Disable SHA-1 Signed JARs

Reviewed-by: weijun

! src/java.base/share/classes/module-info.java
! src/java.base/share/classes/sun/security/provider/certpath/AlgorithmChecker.java
! src/java.base/share/classes/sun/security/provider/certpath/CertPathConstraintsParameters.java
! src/java.base/share/classes/sun/security/provider/certpath/PKIX.java
! src/java.base/share/classes/sun/security/provider/certpath/PKIXCertPathValidator.java
! src/java.base/share/classes/sun/security/provider/certpath/SunCertPathBuilder.java
! src/java.base/share/classes/sun/security/util/DisabledAlgorithmConstraints.java
! src/java.base/share/classes/sun/security/util/JarConstraintsParameters.java
! src/java.base/share/conf/security/java.security
! src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java
- test/jdk/java/security/Security/signedfirst/Dyn.sh
+ test/jdk/java/security/Security/signedfirst/DynStatic.java
- test/jdk/java/security/Security/signedfirst/Static.sh
+ test/jdk/java/security/Security/signedfirst/com/sun/exp/provider/EXP.java
+ test/jdk/java/security/Security/signedfirst/com/sun/exp/provider/SHA.java
- test/jdk/java/security/Security/signedfirst/exp.jar
- test/jdk/java/security/Security/signedfirst/keystore.jks
! test/jdk/java/util/jar/JarFile/Signed.jar
! test/jdk/java/util/jar/JarFile/test.jar
! test/jdk/java/util/jar/JarInputStream/signed.jar
! test/jdk/sun/security/tools/jarsigner/CheckSignerCertChain.java
! test/jdk/sun/security/tools/jarsigner/DiffEnd.java
! test/jdk/sun/security/tools/jarsigner/OldSig.java
+ test/jdk/sun/security/tools/jarsigner/OldSig.props
! test/jdk/sun/security/tools/jarsigner/Test4431684.java
! test/jdk/sun/security/tools/jarsigner/TimestampCheck.java
! test/lib/jdk/test/lib/security/SecurityUtils.java

Changeset: 0fc47e99
Author:    Pavel Rappo 
Date:      2021-09-21 15:53:35 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/0fc47e99d20a1ee886df878f1302769bdd913aab

8266666: Implementation for snippets

Co-authored-by: Jonathan Gibbons 
Co-authored-by: Hannes Walln?fer 
Reviewed-by: jjg

! src/java.compiler/share/classes/javax/tools/DocumentationTool.java
! src/jdk.compiler/share/classes/com/sun/source/doctree/AttributeTree.java
! src/jdk.compiler/share/classes/com/sun/source/doctree/DocTree.java
! src/jdk.compiler/share/classes/com/sun/source/doctree/DocTreeVisitor.java
+ src/jdk.compiler/share/classes/com/sun/source/doctree/SnippetTree.java
! src/jdk.compiler/share/classes/com/sun/source/util/DocTreeFactory.java
! 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/tools/javac/parser/DocCommentParser.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DCTree.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DocPretty.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DocTreeMaker.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/TagletWriterImpl.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/BaseConfiguration.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/BaseOptions.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css
+ src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/SnippetTaglet.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/snippet/Action.java
+ src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/AddStyle.java
+ src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/Attribute.java
+ src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/Attributes.java
+ src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/Bookmark.java
+ src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/MarkupParser.java
+ src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/ParseException.java
+ src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/Parser.java
+ src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/Replace.java
+ src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/Style.java
+ src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/StyledText.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/CommentHelper.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java
! test/langtools/jdk/javadoc/doclet/checkStylesheetClasses/CheckStylesheetClasses.java
+ test/langtools/jdk/javadoc/doclet/testSnippetTag/TestSnippetTag.java
! test/langtools/jdk/javadoc/doclet/testTaglets/TestTaglets.out
! test/langtools/jdk/javadoc/tool/api/basic/DocumentationToolLocationTest.java
! test/langtools/tools/doclint/EmptyHtmlTest.java
! test/langtools/tools/javac/doctree/DocCommentTester.java
+ test/langtools/tools/javac/doctree/SnippetTest.java

Changeset: 161fdb4a
Author:    Lance Andersen 
Date:      2021-09-21 19:23:49 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/161fdb4afbc6e67cc7580fe753112c4d894a9b6b

8273935: (zipfs) Files.getFileAttributeView() throws UOE instead of returning null when view not supported

Reviewed-by: alanb, bpb, sgehwolf

! src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipPath.java
! test/jdk/jdk/nio/zipfs/TestPosix.java
+ test/jdk/jdk/nio/zipfs/testng/test/PosixAttributeViewTest.java
! test/jdk/jdk/nio/zipfs/testng/util/ZipFsBaseTest.java

Changeset: a72c8aa6
Author:    Leonid Mesnik 
Date:      2021-09-21 23:36:16 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/a72c8aa6ad58bad57ddbd65139bcb88b6d8aa5db

8273921: Refactor NSK/JDI tests to create thread using factory

Reviewed-by: cjplummer, sspitsyn, amenkov

! test/hotspot/jtreg/vmTestbase/nsk/jdi/BScenarios/multithrd/tc01x001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/BScenarios/multithrd/tc02x001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/BScenarios/multithrd/tc02x002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/BScenarios/multithrd/tc02x003a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/BScenarios/multithrd/tc02x004a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/BScenarios/multithrd/tc03x001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/BScenarios/multithrd/tc04x001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/BreakpointRequest/_bounds_/filters001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/BreakpointRequest/addInstanceFilter/instancefilter001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/BreakpointRequest/addInstanceFilter/instancefilter002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/BreakpointRequest/addInstanceFilter/instancefilter003a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/BreakpointRequest/addInstanceFilter/instancefilter004a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/BreakpointRequest/addThreadFilter/threadfilter001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/BreakpointRequest/addThreadFilter/threadfilter002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/BreakpointRequest/addThreadFilter/threadfilter003a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/BreakpointRequest/addThreadFilter/threadfilter004a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/BreakpointRequest/location/location001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassPrepareRequest/addClassExclusionFilter/filter001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassPrepareRequest/addClassExclusionFilter/filter002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassPrepareRequest/addClassFilter_rt/filter_rt001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassPrepareRequest/addClassFilter_rt/filter_rt002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassPrepareRequest/addClassFilter_rt/filter_rt003a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassPrepareRequest/addClassFilter_s/filter_s001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassPrepareRequest/addClassFilter_s/filter_s002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/invokeMethod/invokemethod001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/invokeMethod/invokemethod007a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/invokeMethod/invokemethod011t.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/invokeMethod/invokemethod013t.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/newInstance/newinstance001.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/newInstance/newinstance001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassType/newInstance/newinstance007a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/Event/equals/equals001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/Event/hashCode/hashcode001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/Event/request/request001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventIterator/nextEvent/nextevent001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequest/addCountFilter/addcountfilter001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequest/disable/disable001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequest/disable/disable002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequest/enable/enable001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequest/enable/enable002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequest/getProperty/getproperty001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequest/isEnabled/isenabled001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequest/putProperty/putproperty001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequest/setEnabled/setenabled001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequest/setEnabled/setenabled002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequest/setEnabled/setenabled003a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequest/setSuspendPolicy/setsuspendpolicy001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequest/suspendPolicy/suspendpolicy001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/createStepRequest/crstepreq002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/createStepRequest/crstepreq003a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/createStepRequest/crstepreq004a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/createStepRequest/crstepreq005a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/createStepRequest/crstepreq006a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/createStepRequest/crstepreq007a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/createStepRequest/crstepreq008a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/createStepRequest/crstepreq009a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/createStepRequest/crstepreq010a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/deleteEventRequest/delevtreq002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/deleteEventRequests/delevtreqs002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/stepRequests/stepreq001t.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequestManager/stepRequests/stepreq002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/eventIterator/eventiterator003a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/resume/resume008a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/resume/resume009a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/suspendPolicy/suspendpolicy008a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/suspendPolicy/suspendpolicy009a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionRequest/addClassExclusionFilter/filter001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionRequest/addClassFilter_rt/filter_rt001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionRequest/addClassFilter_rt/filter_rt002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionRequest/addClassFilter_rt/filter_rt003a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionRequest/addClassFilter_s/filter_s001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionRequest/addClassFilter_s/filter_s002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionRequest/addInstanceFilter/instancefilter001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionRequest/addInstanceFilter/instancefilter002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionRequest/addInstanceFilter/instancefilter003a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionRequest/addInstanceFilter/instancefilter004a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionRequest/addThreadFilter/threadfilter001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionRequest/addThreadFilter/threadfilter002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionRequest/addThreadFilter/threadfilter004a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionRequest/notifyCaught/notifycaught001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ExceptionRequest/notifyUncaught/notifyuncaught001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/LocalVariable/isVisible/isvisible001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/Locatable/location/location004a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/Locatable/location/location005a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/LocatableEvent/thread/thread001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodEntryRequest/addClassExclusionFilter/filter001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodEntryRequest/addClassFilter_rt/filter_rt001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodEntryRequest/addClassFilter_rt/filter_rt002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodEntryRequest/addClassFilter_rt/filter_rt003a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodEntryRequest/addClassFilter_s/filter_s001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodEntryRequest/addInstanceFilter/instancefilter001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodEntryRequest/addInstanceFilter/instancefilter002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodEntryRequest/addInstanceFilter/instancefilter003a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodEntryRequest/addInstanceFilter/instancefilter004a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodEntryRequest/addThreadFilter/threadfilter001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodEntryRequest/addThreadFilter/threadfilter002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodEntryRequest/addThreadFilter/threadfilter004a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitRequest/addClassExclusionFilter/filter001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitRequest/addClassFilter_rt/filter_rt001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitRequest/addClassFilter_rt/filter_rt002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitRequest/addClassFilter_rt/filter_rt003a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitRequest/addClassFilter_s/filter_s001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitRequest/addInstanceFilter/instancefilter001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitRequest/addInstanceFilter/instancefilter002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitRequest/addInstanceFilter/instancefilter003a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitRequest/addInstanceFilter/instancefilter004a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitRequest/addThreadFilter/threadfilter001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitRequest/addThreadFilter/threadfilter002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitRequest/addThreadFilter/threadfilter003a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitRequest/addThreadFilter/threadfilter004a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/getValue/getvalue001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/owningThread/owningthread001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/owningThread/owningthread002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/getValue/getvalue001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/getValue/getvalue002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/getValues/getvalues001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/getValues/getvalues002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/location/location001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/setValue/setvalue001/setvalue001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/setValue/setvalue002/setvalue002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/setValue/setvalue003/setvalue003a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/setValue/setvalue004/setvalue004a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/thisObject/thisobject002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/thread/thread001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/visibleVariableByName/visiblevarbyname001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/visibleVariableByName/visiblevarbyname002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/visibleVariables/visiblevariables001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StackFrame/visibleVariables/visiblevariables002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepRequest/addClassExclusionFilter/filter001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepRequest/addClassFilter_rt/filter_rt001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepRequest/addClassFilter_rt/filter_rt002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepRequest/addClassFilter_rt/filter_rt003a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepRequest/addClassFilter_s/filter_s001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepRequest/addClassFilter_s/filter_s002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepRequest/addInstanceFilter/instancefilter001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepRequest/addInstanceFilter/instancefilter002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepRequest/addInstanceFilter/instancefilter003a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepRequest/addInstanceFilter/instancefilter004a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepRequest/depth/depth001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepRequest/depth/depth002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepRequest/depth/depth003a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepRequest/size/size001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepRequest/size/size002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/StepRequest/thread/thread001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadDeathRequest/addThreadFilter/addthreadfilter001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadDeathRequest/addThreadFilter/addthreadfilter003a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadDeathRequest/addThreadFilter/addthreadfilter004a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadDeathRequest/addThreadFilter/addthreadfilter005a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/currentContendedMonitor/currentcm001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/frame/frame001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/frameCount/framecount001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/frames_ii/frames_ii001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/isAtBreakpoint/isatbreakpoint001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/isSuspended/issuspended001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/isSuspended/issuspended002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/isSuspended/issuspended003a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/isSuspended/issuspended004a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/name/name001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/popFrames/popframes001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/popFrames/popframes002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/popFrames/popframes003a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/popFrames/popframes004a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/resume/resume001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/stop/stop001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/suspend/suspend001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/suspendCount/suspendcount001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadStartEvent/thread/thread001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadStartRequest/addThreadFilter/addthreadfilter001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadStartRequest/addThreadFilter/addthreadfilter003a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadStartRequest/addThreadFilter/addthreadfilter004a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadStartRequest/addThreadFilter/addthreadfilter005a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/allThreads/allthreads001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/canGetCurrentContendedMonitor/cangccm001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/canGetMonitorInfo/cangetmonitorinfo001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/canGetOwnedMonitorInfo/cangetinfo001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/dispose/dispose002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/dispose/dispose003a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/dispose/dispose004a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/suspend/suspend001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addClassExclusionFilter/filter001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addClassExclusionFilter/filter002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addClassFilter_rt/filter_rt001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addClassFilter_rt/filter_rt002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addClassFilter_rt/filter_rt005a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addClassFilter_rt/filter_rt006a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addClassFilter_s/filter_s001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addClassFilter_s/filter_s002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addInstanceFilter/instancefilter001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addInstanceFilter/instancefilter002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addInstanceFilter/instancefilter003a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addInstanceFilter/instancefilter004a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addInstanceFilter/instancefilter005a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addInstanceFilter/instancefilter006a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addInstanceFilter/instancefilter007a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addInstanceFilter/instancefilter008a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addThreadFilter/addthreadfilter001a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addThreadFilter/addthreadfilter002a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addThreadFilter/addthreadfilter003a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addThreadFilter/addthreadfilter004a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addThreadFilter/addthreadfilter005a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addThreadFilter/addthreadfilter006a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addThreadFilter/addthreadfilter007a.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/WatchpointRequest/addThreadFilter/addthreadfilter008a.java
+ test/hotspot/jtreg/vmTestbase/nsk/share/jdi/JDIThreadFactory.java
+ test/hotspot/jtreg/vmTestbase/nsk/share/jdi/NamedTask.java

Changeset: cbe57e86
Author:    Andrey Turbanov 
Committer: Sergey Bylokhov 
Date:      2021-09-22 01:26:21 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/cbe57e860487d1a31a092ec326dc64bf5599a00e

8273684: Replace usages of java.util.Stack with ArrayDeque

Reviewed-by: cjplummer, serb

! src/java.desktop/share/classes/com/sun/media/sound/DLSSoundbank.java
! src/java.desktop/share/classes/javax/swing/text/html/HTMLDocument.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CommandProcessor.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/ui/AnnotatedMemoryPanel.java

Changeset: 11cddd32
Author:    Yi Yang 
Date:      2021-09-22 02:20:30 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/11cddd3261e2bfaa4f2b9142ce9e275bbc48c72e

8272114: Unused _last_state in osThread_windows

Reviewed-by: stuefe, dholmes

! src/hotspot/os/windows/osThread_windows.hpp

Changeset: 517405e4
Author:    Ao Qi 
Committer: Yi Yang 
Date:      2021-09-22 02:28:49 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/517405e462dc6104c33471c58242ea7b244c6218

8273965: some testlibrary_tests/ir_framework tests fail when c1 disabled

Reviewed-by: chagedorn, thartmann

! 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/TestRunTests.java

Changeset: eeaf43b2
Author:    Daniel D. Daugherty 
Date:      2021-09-22 02:53:02 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/eeaf43b229941f49326ed6d0f37e77f6f0ce5409

8274114: ProblemList serviceability/sa/TestJhsdbJstackMixed.java on linux-aarch64 in -Xcomp mode

Reviewed-by: cjplummer

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

Changeset: 688b3fe2
Author:    Prasanta Sadhukhan 
Date:      2021-09-22 08:02:13 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/688b3fe2eb2593e2cad675fb0f40b8bc6adce22f

8274070: Rectify problemlist platform for failing test on macos12

Reviewed-by: azvegint

! test/jdk/ProblemList.txt

Changeset: d9872ba3
Author:    Thomas Schatzl 
Date:      2021-09-22 08:07:03 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/d9872ba3d6c5afb2ae8e17c38e2222a2a1ab9493

8273590: Move helper classes in G1 post evacuation sub tasks to cpp files

Reviewed-by: sjohanss, kbarrett

! src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.cpp
! src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.hpp

Changeset: c77ebe88
Author:    Aleksey Shipilev 
Date:      2021-09-22 08:40:04 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/c77ebe88748b0a55f1fc7a5497314a752eab1e2a

8274060: C2: Incorrect computation after JDK-8273454

Reviewed-by: thartmann, neliasso, chagedorn

! src/hotspot/share/opto/mulnode.cpp
+ test/hotspot/jtreg/compiler/integerArithmetic/TestNegAnd.java

Changeset: 51085b52
Author:    Thomas Schatzl 
Date:      2021-09-22 10:17:31 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/51085b523eb7f37c3af5b566b55eca37c127bdcf

8274054: Add custom enqueue calls during reference processing

Reviewed-by: ayang, kbarrett, sjohanss

! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp
! src/hotspot/share/gc/g1/g1FullCollector.cpp
! src/hotspot/share/gc/g1/g1YoungCollector.cpp
! src/hotspot/share/gc/parallel/psParallelCompact.cpp
! src/hotspot/share/gc/parallel/psScavenge.cpp
! src/hotspot/share/gc/serial/serialGcRefProcProxyTask.hpp
! src/hotspot/share/gc/shared/referenceProcessor.cpp
! src/hotspot/share/gc/shared/referenceProcessor.hpp
! src/hotspot/share/gc/shared/referenceProcessor.inline.hpp

Changeset: 7f78803b
Author:    sunxu 
Committer: Lance Andersen 
Date:      2021-09-22 11:38:29 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/7f78803b0926ea194334ad9b3c9f06cbe17a83dd

8273961: jdk/nio/zipfs/ZipFSTester.java fails if file path contains '+' character

Reviewed-by: clanger, lancea

! test/jdk/jdk/nio/zipfs/ZipFSTester.java

Changeset: 3f73ca7f
Author:    Thomas Schatzl 
Date:      2021-09-22 11:41:13 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/3f73ca7fcd674e10d4382ec4bd8d4cb0da1e4256

8274068: Rename G1ScanInYoungSetter to G1SkipCardEnqueueSetter

Reviewed-by: sjohanss, ayang

! src/hotspot/share/gc/g1/g1OopClosures.hpp
! src/hotspot/share/gc/g1/g1OopClosures.inline.hpp
! src/hotspot/share/gc/g1/g1ParScanThreadState.cpp

Changeset: d245a8cc
Author:    Thomas Schatzl 
Date:      2021-09-22 11:43:13 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/d245a8cc852de21547928252ed6f0474f0d49b1c

8274069: Clean up g1ParScanThreadState a bit

Reviewed-by: sjohanss, ayang, kbarrett

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

Changeset: aefd4ac4
Author:    Erik Gahlin 
Date:      2021-09-22 11:45:29 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/aefd4ac4a336f00c067bcb91b95472ccc9a6bf83

8258734: jdk/jfr/event/oldobject/TestClassLoaderLeak.java failed with "RuntimeException: Could not find class leak"

Reviewed-by: mgronlun

! test/jdk/jdk/jfr/event/oldobject/TestClassLoaderLeak.java

Changeset: ba7d550c
Author:    Jan Lahoda 
Date:      2021-09-22 12:52:31 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/ba7d550c6e6d84b36d81aafa1dfded0c99b5c248

8270139: jshell InternalError crash for import of @Repeatable followed by unresolved ref

Reviewed-by: vromero

! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java
+ test/langtools/jdk/jshell/ErrorRecoveryTest.java
+ test/langtools/tools/javac/recovery/AnnotationRecovery.java

Changeset: 71788c69
Author:    Jan Lahoda 
Date:      2021-09-22 12:53:57 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/71788c69dbae854331f3393044dab458c906045f

8271287: jdk/jshell/CommandCompletionTest.java fails with "lists don't have the same size expected"

Reviewed-by: vromero

! test/langtools/jdk/jshell/CommandCompletionTest.java

Changeset: c6df3c95
Author:    Pavel Rappo 
Date:      2021-09-22 13:42:23 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/c6df3c9571cfa9607f3deffeaa77701dde9fea15

8274071: Clean up java.lang.ref comments and documentation

Reviewed-by: rriggs, kbarrett, mchung, iris, lancea

! src/java.base/share/classes/java/lang/ref/Reference.java

Changeset: 0a361638
Author:    Roger Riggs 
Date:      2021-09-22 13:55:19 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/0a361638c5ea4d3e109d950e34a61b4737c8f670

8272600: (test) Use native "sleep" in Basic.java

Reviewed-by: iklam, dholmes

! test/jdk/java/lang/ProcessBuilder/Basic.java
+ test/jdk/java/lang/ProcessBuilder/exeBasicSleep.c

Changeset: 33df388a
Author:    Roger Riggs 
Date:      2021-09-22 13:57:37 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/33df388a24267e868574e4604b2e2ab170dc5a09

8274003: ProcessHandleImpl.Info toString has an if check which is always true

Reviewed-by: bpb, naoto, iris

! src/java.base/share/classes/java/lang/ProcessHandleImpl.java

Changeset: c9de8063
Author:    Patric Hedlin 
Date:      2021-09-22 14:20:17 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/c9de80635e25badbb5410e22b6619379598a9a57

8274039: codestrings gtest fails when hsdis is present

Reviewed-by: shade

! test/hotspot/gtest/code/test_codestrings.cpp

Changeset: d39aad92
Author:    Naoto Sato 
Date:      2021-09-22 15:50:49 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/d39aad92308fbc28bd2de164e331062ebf62da85

8273924: ArrayIndexOutOfBoundsException thrown in java.util.JapaneseImperialCalendar.add()

Reviewed-by: rriggs, iris, joehw

! src/java.base/share/classes/sun/util/calendar/BaseCalendar.java
! test/jdk/java/util/Calendar/CalendarTestScripts/JapaneseTests.java
! test/jdk/java/util/Calendar/CalendarTestScripts/japanese/japanese_add.cts

Changeset: da38ced3
Author:    Raffaello Giulietti 
Committer: Brian Burkhalter 
Date:      2021-09-22 16:16:14 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/da38ced3299cbd02f210bea4130990a43f6104bf

8271602: Add Math.ceilDiv() family parallel to Math.floorDiv() family

Reviewed-by: bpb

! src/java.base/share/classes/java/lang/Math.java
! src/java.base/share/classes/java/lang/StrictMath.java
! test/jdk/java/lang/Math/DivModTests.java
! test/jdk/java/lang/Math/ExactArithTests.java

Changeset: 81d41647
Author:    Brian Burkhalter 
Date:      2021-09-22 16:29:04 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/81d416477f9856861a5af13058bfc3028bcb9b60

8272759: (fc) java/nio/channels/FileChannel/Transfer2GPlus.java failed in timeout

Reviewed-by: alanb

! test/jdk/java/nio/channels/FileChannel/Transfer2GPlus.java

Changeset: 57fe11c9
Author:    Tom Rodriguez 
Date:      2021-09-22 17:16:41 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/57fe11c9a37c121a244b3d6c9c0a1413dc0484b7

8274120: [JVMCI] CompileBroker should resolve parameter types for JVMCI compiles

Reviewed-by: dnsimon, thartmann

! src/hotspot/share/compiler/compileBroker.cpp

Changeset: 8821b000
Author:    Alisen Chung 
Committer: Alexey Ivanov 
Date:      2021-09-22 18:32:05 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/8821b0004170e18c8e7d6e5bbe8759344ff769b1

8205137: Remove Applet support from SwingSet2
8205139: Remove Applet support from J2Ddemo

Reviewed-by: aivanov, kizune

! src/demo/share/README
! src/demo/share/jfc/J2Ddemo/java2d/J2Ddemo.java
! src/demo/share/jfc/SwingSet2/ButtonDemo.java
! src/demo/share/jfc/SwingSet2/ColorChooserDemo.java
! src/demo/share/jfc/SwingSet2/ComboBoxDemo.java
! src/demo/share/jfc/SwingSet2/DemoModule.java
! src/demo/share/jfc/SwingSet2/FileChooserDemo.java
! src/demo/share/jfc/SwingSet2/HtmlDemo.java
! src/demo/share/jfc/SwingSet2/InternalFrameDemo.java
! src/demo/share/jfc/SwingSet2/ListDemo.java
! src/demo/share/jfc/SwingSet2/OptionPaneDemo.java
! src/demo/share/jfc/SwingSet2/ProgressBarDemo.java
! src/demo/share/jfc/SwingSet2/README.txt
! src/demo/share/jfc/SwingSet2/ScrollPaneDemo.java
! src/demo/share/jfc/SwingSet2/SliderDemo.java
! src/demo/share/jfc/SwingSet2/SplitPaneDemo.java
- src/demo/share/jfc/SwingSet2/SwingSet2.html
! src/demo/share/jfc/SwingSet2/TabbedPaneDemo.java
! src/demo/share/jfc/SwingSet2/TableDemo.java
! src/demo/share/jfc/SwingSet2/ToolTipDemo.java
! src/demo/share/jfc/SwingSet2/TreeDemo.java

Changeset: 60313889
Author:    Erik Gahlin 
Date:      2021-09-22 21:28:11 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/603138895f1665e75f01bb787af3222f08abc4db

8273714: jdk/jfr/api/consumer/TestRecordedFrame.java still times out after JDK-8273047

Reviewed-by: mgronlun

! test/jdk/jdk/jfr/api/consumer/TestRecordedFrame.java
+ test/jdk/jdk/jfr/api/consumer/TestRecordedFrameType.java

Changeset: 9d3379b9
Author:    Ningsheng Jian 
Date:      2021-09-23 02:58:59 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/9d3379b9755e9739f0b8f5c29deb1d28d0f3aa81

8267356: AArch64: Vector API SVE codegen support

Co-authored-by: Xiaohong Gong 
Co-authored-by: Wang Huang 
Co-authored-by: Ningsheng Jian 
Co-authored-by: Xuejin He 
Co-authored-by: Ai Jiaming 
Co-authored-by: Eric Liu 
Reviewed-by: aph, ngasson

! src/hotspot/cpu/aarch64/aarch64.ad
! src/hotspot/cpu/aarch64/aarch64_neon.ad
! src/hotspot/cpu/aarch64/aarch64_neon_ad.m4
! src/hotspot/cpu/aarch64/aarch64_sve.ad
! src/hotspot/cpu/aarch64/aarch64_sve_ad.m4
! src/hotspot/cpu/aarch64/assembler_aarch64.cpp
! src/hotspot/cpu/aarch64/assembler_aarch64.hpp
! 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/share/opto/output.cpp
! test/hotspot/gtest/aarch64/aarch64-asmtest.py
! test/hotspot/gtest/aarch64/asmtest.out.h

Changeset: 0fbbe4c9
Author:    Ioi Lam 
Date:      2021-09-23 03:49:06 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/0fbbe4c9a779c24d5502648c866b7f1e1e50acc0

8274033: Some tier-4 CDS EpsilonGC tests throw OOM

Reviewed-by: dholmes, ccheung, minqi

! test/hotspot/jtreg/TEST.groups

Changeset: 45adc922
Author:    Prasanta Sadhukhan 
Date:      2021-09-23 05:15:37 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/45adc9227a28c8d614c41ac496bbeaa752e5fd7b

8273578: javax/swing/JMenu/4515762/bug4515762.java fails on macOS 12

Reviewed-by: jdv, serb

! test/jdk/ProblemList.txt
! test/jdk/javax/swing/JMenu/4515762/bug4515762.java

Changeset: 1c6fa113
Author:    Matthias Baesken 
Date:      2021-09-23 05:34:18 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/1c6fa113bd06585945e077f0d2004a291c27946d

8273979: move some os time related functions to os_posix for POSIX platforms

Reviewed-by: dholmes, lucy

! src/hotspot/os/aix/os_aix.cpp
! src/hotspot/os/bsd/os_bsd.cpp
! src/hotspot/os/linux/os_linux.cpp
! src/hotspot/os/posix/os_posix.cpp

Changeset: 2166ed13
Author:    Jaikiran Pai 
Date:      2021-09-23 05:37:19 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/2166ed136917bb68f8155a25e4f4a6c5c7115566

8273894: ConcurrentModificationException raised every time ReferralsCache drops referral

Reviewed-by: shade

! src/java.security.jgss/share/classes/sun/security/krb5/internal/ReferralsCache.java

Changeset: a74c099d
Author:    Lin Zang 
Date:      2021-09-23 07:00:06 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/a74c099d67272b2ef542405d30db62a82cbbebc6

8252842: Extend jmap to support parallel heap dump

Reviewed-by: rschmelter, cjplummer

! src/hotspot/share/services/attachListener.cpp
! src/hotspot/share/services/heapDumper.cpp
! src/hotspot/share/services/heapDumper.hpp
! src/hotspot/share/services/heapDumperCompression.cpp
! src/hotspot/share/services/heapDumperCompression.hpp
! test/lib/jdk/test/lib/hprof/parser/Reader.java

Changeset: 8b833bbe
Author:    Andrey Turbanov 
Committer: Christian Hagedorn 
Date:      2021-09-23 07:47:04 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/8b833bbea84829664f23d17c7f94c0379b48f365

8274048: IGV: Replace usages of Collections.sort with List.sort call

Reviewed-by: chagedorn

! src/utils/IdealGraphVisualizer/Data/src/main/java/com/sun/hotspot/igv/data/InputGraph.java
! src/utils/IdealGraphVisualizer/Data/src/main/java/com/sun/hotspot/igv/data/Properties.java
! src/utils/IdealGraphVisualizer/FilterWindow/src/main/java/com/sun/hotspot/igv/filterwindow/FilterTopComponent.java
! src/utils/IdealGraphVisualizer/Graph/src/main/java/com/sun/hotspot/igv/graph/Diagram.java
! src/utils/IdealGraphVisualizer/Graph/src/main/java/com/sun/hotspot/igv/graph/Figure.java
! src/utils/IdealGraphVisualizer/HierarchicalLayout/src/main/java/com/sun/hotspot/igv/hierarchicallayout/HierarchicalLayoutManager.java
! src/utils/IdealGraphVisualizer/ServerCompiler/src/main/java/com/sun/hotspot/igv/servercompiler/ServerCompilerScheduler.java
! src/utils/IdealGraphVisualizer/View/src/main/java/com/sun/hotspot/igv/view/NodeQuickSearch.java

Changeset: 87998565
Author:    Pavel Rappo 
Date:      2021-09-23 08:08:39 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/8799856528f5804b616b734caed3fc4ba9811bfa

8274075: Fix miscellaneous typos in java.base

Reviewed-by: dfuchs, darcy, iris, lancea, bpb

! src/java.base/share/classes/java/io/PrintStream.java
! src/java.base/share/classes/java/io/WriteAbortedException.java
! src/java.base/share/classes/java/lang/Throwable.java
! src/java.base/share/classes/java/lang/invoke/LambdaProxyClassArchive.java
! src/java.base/share/classes/java/lang/invoke/MethodHandles.java
! src/java.base/share/classes/java/nio/file/FileChannelLinesSpliterator.java
! src/java.base/share/classes/java/security/Security.java
! src/java.base/share/classes/java/util/Properties.java
! src/java.base/share/classes/java/util/stream/AbstractPipeline.java

Changeset: 4f3b626a
Author:    Andrew Haley 
Date:      2021-09-23 09:00:46 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/4f3b626a36319cbbbbdcb1c02a84486a3d4eddb6

8271567: AArch64: AES Galois CounterMode (GCM) interleaved implementation using vector instructions

Reviewed-by: ngasson, adinn, xliu

! src/hotspot/cpu/aarch64/assembler_aarch64.hpp
! src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp
+ src/hotspot/cpu/aarch64/macroAssembler_aarch64_aes.cpp
! src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp
! src/hotspot/cpu/aarch64/stubRoutines_aarch64.hpp
! src/hotspot/cpu/aarch64/vm_version_aarch64.cpp
! src/hotspot/os_cpu/bsd_aarch64/vm_version_bsd_aarch64.cpp

Changeset: d0987513
Author:    Coleen Phillimore 
Date:      2021-09-23 11:21:02 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/d0987513665def1b6b2981ab5932b6f1b8b310d8

8273916: Remove 'special' ranking

Reviewed-by: dholmes, pchilanomate

! src/hotspot/share/runtime/mutex.hpp
! src/hotspot/share/runtime/mutexLocker.cpp
! src/hotspot/share/runtime/mutexLocker.hpp
! test/hotspot/gtest/runtime/test_mutex.cpp
! test/hotspot/gtest/runtime/test_safepoint_locks.cpp

Changeset: c4345285
Author:    Naoto Sato 
Date:      2021-09-23 12:48:49 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/c43452859d7211f0d6537d71bd0df89412d4ff6f

8273546: DecimalFormat documentation contains literal HTML character references

Reviewed-by: joehw, bpb, iris, lancea

! src/java.base/share/classes/java/math/BigInteger.java
! src/java.base/share/classes/java/text/CompactNumberFormat.java
! src/java.base/share/classes/java/text/DecimalFormat.java

Changeset: 66ce09f5
Author:    Tobias Holenstein 
Committer: Tobias Hartmann 
Date:      2021-09-23 12:55:42 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/66ce09f51eb37029c8ba67a70f8c90a307dae1eb

8272703: StressSeed should be set via FLAG_SET_ERGO

Reviewed-by: chagedorn, thartmann

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

Changeset: 653a612a
Author:    Tobias Holenstein 
Committer: Tobias Hartmann 
Date:      2021-09-23 12:59:22 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/653a612a5aac266509f414c570871b7141b9347d

8270156: Add "randomness" and "stress" keys to JTreg tests which use StressGCM, StressLCM and/or StressIGVN

Reviewed-by: thartmann, chagedorn

! test/hotspot/jtreg/compiler/arguments/TestStressOptions.java
! test/hotspot/jtreg/compiler/c2/Test7179138_1.java
! test/hotspot/jtreg/compiler/c2/TestJumpTable.java
! test/hotspot/jtreg/compiler/debug/TestGenerateStressSeed.java
! test/hotspot/jtreg/compiler/debug/TestStressCM.java
! test/hotspot/jtreg/compiler/debug/TestStressIGVNAndCCP.java
! test/hotspot/jtreg/compiler/exceptions/TestSpilling.java
! test/hotspot/jtreg/compiler/loopopts/TestLostDependencyOnZeroTripGuard.java

Changeset: 1b7f4b7d
Author:    Liam Miller-Cushon 
Date:      2021-09-23 13:41:10 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/1b7f4b7dd8a6070d290875a95099780c9f060139

8274169: HotSpot Style Guide has stale link to chromium style guide

Reviewed-by: dholmes, ihse

! doc/hotspot-style.html
! doc/hotspot-style.md

Changeset: 3b1b8fc6
Author:    Roger Riggs 
Date:      2021-09-23 15:01:25 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/3b1b8fc646493eae5f4df828afe29abb75fa5e60

8269850: Most JDK releases report macOS version 12 as 10.16 instead of 12.0

Reviewed-by: naoto, clanger

! src/java.base/macosx/native/libjava/java_props_macosx.c

Changeset: 1fdc6560
Author:    Brian Burkhalter 
Date:      2021-09-23 15:57:12 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/1fdc6560841f72b761756d935dd02e4bb2395ec6

8274175: (fc) java/nio/channels/FileChannel/Transfer2GPlus.java still failed in timeout

Reviewed-by: alanb

! test/jdk/java/nio/channels/FileChannel/Transfer2GPlus.java

Changeset: 5ffbe755
Author:    Pavel Rappo 
Date:      2021-09-23 16:18:07 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/5ffbe7555771c67e28b5361d2a569f3dd858ff36

8274195: Doc cleanup in java.nio.file

Reviewed-by: alanb, lancea, bpb

! src/java.base/share/classes/java/nio/file/DirectoryStream.java
! src/java.base/share/classes/java/nio/file/Files.java

Changeset: 0aa63fec
Author:    Daniel D. Daugherty 
Date:      2021-09-23 17:14:49 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/0aa63feca8704c8958530ef9e3df128570c50e12

8274216: ProblemList 2 serviceability/dcmd/gc tests with ZGC on linux-all and windows-all

Reviewed-by: darcy, tschatzl

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

Changeset: 56b8b352
Author:    Andrey Turbanov 
Committer: Roger Riggs 
Date:      2021-09-23 20:04:36 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/56b8b35286634f2d2224ca445bc9f32ff284ae74

8273261: Replace 'while' cycles with iterator with enhanced-for in java.base

Reviewed-by: dfuchs, rriggs, iris, mullan

! src/java.base/share/classes/java/security/cert/X509CRLSelector.java
! src/java.base/share/classes/java/security/cert/X509CertSelector.java
! src/java.base/share/classes/java/text/AttributedString.java
! src/java.base/share/classes/javax/security/auth/PrivateCredentialPermission.java
! src/java.base/share/classes/javax/security/auth/Subject.java
! src/java.base/share/classes/jdk/internal/util/jar/JarIndex.java
! src/java.base/share/classes/sun/net/www/protocol/ftp/FtpURLConnection.java
! src/java.base/share/classes/sun/net/www/protocol/http/AuthCacheImpl.java
! src/java.base/share/classes/sun/security/provider/SubjectCodeSource.java
! src/java.base/share/classes/sun/security/tools/keytool/Main.java
! src/java.base/share/classes/sun/security/x509/PolicyInformation.java

Changeset: bb74ae87
Author:    Julia Boes 
Date:      2021-09-24 08:08:27 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/bb74ae87abee0fb550e4138242919ec791f7791c

8274171: java/nio/file/Files/probeContentType/Basic.java failed on "Content type" mismatches

Reviewed-by: rriggs, bpb

! test/jdk/java/nio/file/Files/probeContentType/Basic.java

Changeset: 1d440141
Author:    Hannes Walln?fer 
Date:      2021-09-24 08:51:55 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/1d44014171637b0134fb0e39f871584e6c8793f3

8273034: Make javadoc navigation collapsible on small displays

Reviewed-by: jjg

! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlIds.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/markup/HtmlAttr.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/search.js.template
! 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/stylesheet.css
! test/langtools/jdk/javadoc/doclet/checkStylesheetClasses/CheckStylesheetClasses.java
! test/langtools/jdk/javadoc/doclet/testPackageSummary/TestPackageSummary.java
! test/langtools/jdk/javadoc/doclet/testStylesheet/TestStylesheet.java

Changeset: 971aa353
Author:    Aleksey Shipilev 
Date:      2021-09-24 09:03:33 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/971aa353aae51222ca33ebfdd61b91672a6c871a

8274083: Update testing docs to mention tiered testing

Reviewed-by: dholmes, jiefu, stuefe, ihse, mseledtsov, alanb

! doc/testing.html
! doc/testing.md

Changeset: df4c2a48
Author:    duke 
Date:      2021-09-24 11:01:14 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/df4c2a4857b0c967a7cd76e8c27459f61ed0d786

Automatic merge of jdk:master into master


Changeset: 1414f2c2
Author:    duke 
Date:      2021-09-24 11:01:36 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/1414f2c2c56409ee8b7a51026f28a1b5277c03f3

Automatic merge of master into foreign-memaccess+abi


Changeset: 38baa7b4
Author:    duke 
Date:      2021-09-24 11:01:54 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/38baa7b43de30e2f2e8c247ccac90e587ffe2611

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

! src/java.base/share/classes/module-info.java
! test/jdk/TEST.groups
! src/java.base/share/classes/module-info.java
! test/jdk/TEST.groups


From sundar at openjdk.java.net  Fri Sep 24 12:22:22 2021
From: sundar at openjdk.java.net (Athijegannathan Sundararajan)
Date: Fri, 24 Sep 2021 12:22:22 GMT
Subject: [foreign-jextract] RFR: 8274280: regenarate libclang binding in
 jextract module
Message-ID: 

Moved CLayouts out of the generated code package. Except for libName & copyright header, no changes to the jextract generated code now.

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

Commit messages:
 - 8274280: regenarate libclang binding in jextract module

Changes: https://git.openjdk.java.net/panama-foreign/pull/580/files
 Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=580&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274280
  Stats: 764 lines in 32 files changed: 15 ins; 150 del; 599 mod
  Patch: https://git.openjdk.java.net/panama-foreign/pull/580.diff
  Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/580/head:pull/580

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

From jvernee at openjdk.java.net  Fri Sep 24 12:27:11 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 24 Sep 2021 12:27:11 GMT
Subject: [foreign-jextract] RFR: 8274280: regenarate libclang binding in
 jextract module
In-Reply-To: 
References: 
Message-ID: 

On Fri, 24 Sep 2021 12:15:20 GMT, Athijegannathan Sundararajan  wrote:

> Moved CLayouts out of the generated code package. Except for libName & copyright header, no changes to the jextract generated code now.

src/jdk.incubator.jextract/share/classes/jdk/internal/clang/libclang/CXToken.java line 40:

> 38:         MemoryLayout.sequenceLayout(4, JAVA_INT).withName("int_data"),
> 39:         ADDRESS.withName("ptr_data")
> 40:     );

Why these changes? Shouldn't this still be using `C_INT` and `C_POINTER` ?

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

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

From sundar at openjdk.java.net  Fri Sep 24 12:27:11 2021
From: sundar at openjdk.java.net (Athijegannathan Sundararajan)
Date: Fri, 24 Sep 2021 12:27:11 GMT
Subject: [foreign-jextract] RFR: 8274280: regenarate libclang binding in
 jextract module
In-Reply-To: 
References: 
 
Message-ID: <3hNl4Ry4lpkmZX9Xvfv7UIvdQAbljMbKNcDmbLgDAv0=.6e488ef3-c557-4bbb-9c6d-28963350de8f@github.com>

On Fri, 24 Sep 2021 12:23:08 GMT, Jorn Vernee  wrote:

>> Moved CLayouts out of the generated code package. Except for libName & copyright header, no changes to the jextract generated code now.
>
> src/jdk.incubator.jextract/share/classes/jdk/internal/clang/libclang/CXToken.java line 40:
> 
>> 38:         MemoryLayout.sequenceLayout(4, JAVA_INT).withName("int_data"),
>> 39:         ADDRESS.withName("ptr_data")
>> 40:     );
> 
> Why these changes? Shouldn't this still be using `C_INT` and `C_POINTER` ?

That's generated code. In this patch I am not touching jextract generated code except for copyright header + libName

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

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

From sundar at openjdk.java.net  Fri Sep 24 13:05:59 2021
From: sundar at openjdk.java.net (Athijegannathan Sundararajan)
Date: Fri, 24 Sep 2021 13:05:59 GMT
Subject: [foreign-jextract] RFR: 8274280: regenarate libclang binding in
 jextract module [v2]
In-Reply-To: 
References: 
Message-ID: 

> Moved CLayouts out of the generated code package. Except for libName & copyright header, no changes to the jextract generated code now.

Athijegannathan Sundararajan has updated the pull request incrementally with one additional commit since the last revision:

  removed CLayouts. Using generated C_* layouts instead. Using ADDRESS in TypeImpl.java instead of C_POINTER.

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

Changes:
  - all: https://git.openjdk.java.net/panama-foreign/pull/580/files
  - new: https://git.openjdk.java.net/panama-foreign/pull/580/files/13e06b99..363d9871

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

  Stats: 49 lines in 6 files changed: 0 ins; 39 del; 10 mod
  Patch: https://git.openjdk.java.net/panama-foreign/pull/580.diff
  Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/580/head:pull/580

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

From mcimadamore at openjdk.java.net  Fri Sep 24 13:06:00 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 24 Sep 2021 13:06:00 GMT
Subject: [foreign-jextract] RFR: 8274280: regenarate libclang binding in
 jextract module [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 24 Sep 2021 13:02:18 GMT, Athijegannathan Sundararajan  wrote:

>> Moved CLayouts out of the generated code package. Except for libName & copyright header, no changes to the jextract generated code now.
>
> Athijegannathan Sundararajan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed CLayouts. Using generated C_* layouts instead. Using ADDRESS in TypeImpl.java instead of C_POINTER.

Looks good!

src/jdk.incubator.jextract/share/classes/jdk/internal/clang/CLayouts.java line 26:

> 24:  */
> 25: 
> 26: package jdk.internal.clang;

This class should be removed. Other classes in the libclang package should use the C layouts that are generated in the main class header. Outside of the package, we should just use regular ValueLayouts (e.g. `ADDRESS`).

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

Marked as reviewed by mcimadamore (Committer).

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

From sundar at openjdk.java.net  Fri Sep 24 13:12:00 2021
From: sundar at openjdk.java.net (Athijegannathan Sundararajan)
Date: Fri, 24 Sep 2021 13:12:00 GMT
Subject: [foreign-jextract] Integrated: 8274280: regenarate libclang binding
 in jextract module
In-Reply-To: 
References: 
Message-ID: <23y2m2ygLFyJHt5f0jM-oKZhUptQeWrUH3rWz_ogdR4=.7b65356d-0248-4667-94e9-15a8a7910e6b@github.com>

On Fri, 24 Sep 2021 12:15:20 GMT, Athijegannathan Sundararajan  wrote:

> Moved CLayouts out of the generated code package. Except for libName & copyright header, no changes to the jextract generated code now.

This pull request has now been integrated.

Changeset: cae41c97
Author:    Athijegannathan Sundararajan 
URL:       https://git.openjdk.java.net/panama-foreign/commit/cae41c97b9a3aa1290c1e40b1f802107f1dd0654
Stats:     803 lines in 32 files changed: 15 ins; 189 del; 599 mod

8274280: regenarate libclang binding in jextract module

Reviewed-by: mcimadamore

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

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

From mcimadamore at openjdk.java.net  Fri Sep 24 13:23:38 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 24 Sep 2021 13:23:38 GMT
Subject: [foreign-memaccess+abi] RFR: 8274285: By reference parameters
 should be kept alive during downcalls
In-Reply-To: <3AYukUF-ebUpouONIDqVSzCmmITOPscVPLL5etV5zRo=.c6bd4afc-1259-40d2-ba44-164e27eb7164@github.com>
References: <3AYukUF-ebUpouONIDqVSzCmmITOPscVPLL5etV5zRo=.c6bd4afc-1259-40d2-ba44-164e27eb7164@github.com>
Message-ID: 

On Fri, 24 Sep 2021 13:10:44 GMT, Maurizio Cimadamore  wrote:

> This patch adds an adapter around the downcall method handle which keeps alive all by-reference arguments by acquiring/releasing their associated scopes.
> 
> I've implemented the adapted in a separate method in `SharedUtils`, because `SharedUtils::wrapWithAllocator` is relatively complex, and has mostly to do with creating a scope and closing it after the call.
> Also, `wrapWithAllocator` is only called when specialized method handles are active, which means adding logic there doesn't fix the programmable fallback case.
> 
> Since we plan to do more implementation restructuring in this area, I preferred to keep things simple for now.
> 
> Also note that the acquire/release logic isn't too smart - if multiple arguments backed by the same scoped are passed, we do separate acquire/release for each of them. Again, I didn't want to spend too many cycles given that the implementation of this area might change, so my aim for now was to make things safe; we can improve efficiency later.
> 
> Here are some benchmarks, for now, which compare the difference between passing a struct by reference using the struct's address (e.g. calling `MemorySegment::address` before the downcall), vs. passing the struct directly. In the first case, the scope is the global scope, so acquiring/relesing is a no-op. In the latter case we have a real scope, which we need to acquire and release.
> 
> 
> Benchmark                                                           Mode  Cnt   Score   Error  Units
> CallOverheadConstant.panama_identity_memory_address_confined        avgt   30  13.094 ? 0.220  ns/op
> CallOverheadConstant.panama_identity_memory_address_confined_3      avgt   30  16.051 ? 0.230  ns/op
> CallOverheadConstant.panama_identity_memory_address_shared          avgt   30  13.287 ? 0.172  ns/op
> CallOverheadConstant.panama_identity_memory_address_shared_3        avgt   30  15.812 ? 0.365  ns/op
> 
> Benchmark
> CallOverheadConstant.panama_identity_struct_ref_confined    avgt   30  11.544 ? 0.170  ns/op
> CallOverheadConstant.panama_identity_struct_ref_confined_3  avgt   30  12.213 ? 0.228  ns/op
> CallOverheadConstant.panama_identity_struct_ref_shared      avgt   30  17.214 ? 0.560  ns/op
> CallOverheadConstant.panama_identity_struct_ref_shared_3    avgt   30  33.132 ? 0.934  ns/op
> 
> 
> As it can be seen, in the confined case the numbers are good. In the shared case there's more overhead - that's the price for safety. We will be able to make this faster (by only acquiring scopes which have not already been acquired) - but note that users can always opt out of safety by projecting the `Addressable` down to a raw memory address, which would remove all the costs.

src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/SharedUtils.java line 385:

> 383:         closer = collectArguments(closer, insertPos++, MH_CLOSE_CONTEXT); // (Throwable, V?, Addressable?, BindingContext) -> V/void
> 384: 
> 385:         if (!upcall) {

This can go away, because we use acquire/release anyway to keep these args alive in the new adapter/wrapper.

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

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

From mcimadamore at openjdk.java.net  Fri Sep 24 13:23:37 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 24 Sep 2021 13:23:37 GMT
Subject: [foreign-memaccess+abi] RFR: 8274285: By reference parameters should
 be kept alive during downcalls
Message-ID: <3AYukUF-ebUpouONIDqVSzCmmITOPscVPLL5etV5zRo=.c6bd4afc-1259-40d2-ba44-164e27eb7164@github.com>

This patch adds an adapter around the downcall method handle which keeps alive all by-reference arguments by acquiring/releasing their associated scopes.

I've implemented the adapted in a separate method in `SharedUtils`, because `SharedUtils::wrapWithAllocator` is relatively complex, and has mostly to do with creating a scope and closing it after the call.
Also, `wrapWithAllocator` is only called when specialized method handles are active, which means adding logic there doesn't fix the programmable fallback case.

Since we plan to do more implementation restructuring in this area, I preferred to keep things simple for now.

Also note that the acquire/release logic isn't too smart - if multiple arguments backed by the same scoped are passed, we do separate acquire/release for each of them. Again, I didn't want to spend too many cycles given that the implementation of this area might change, so my aim for now was to make things safe; we can improve efficiency later.

Here are some benchmarks, for now, which compare the difference between passing a struct by reference using the struct's address (e.g. calling `MemorySegment::address` before the downcall), vs. passing the struct directly. In the first case, the scope is the global scope, so acquiring/relesing is a no-op. In the latter case we have a real scope, which we need to acquire and release.


Benchmark                                                           Mode  Cnt   Score   Error  Units
CallOverheadConstant.panama_identity_memory_address_confined        avgt   30  13.094 ? 0.220  ns/op
CallOverheadConstant.panama_identity_memory_address_confined_3      avgt   30  16.051 ? 0.230  ns/op
CallOverheadConstant.panama_identity_memory_address_shared          avgt   30  13.287 ? 0.172  ns/op
CallOverheadConstant.panama_identity_memory_address_shared_3        avgt   30  15.812 ? 0.365  ns/op

Benchmark
CallOverheadConstant.panama_identity_struct_ref_confined    avgt   30  11.544 ? 0.170  ns/op
CallOverheadConstant.panama_identity_struct_ref_confined_3  avgt   30  12.213 ? 0.228  ns/op
CallOverheadConstant.panama_identity_struct_ref_shared      avgt   30  17.214 ? 0.560  ns/op
CallOverheadConstant.panama_identity_struct_ref_shared_3    avgt   30  33.132 ? 0.934  ns/op


As it can be seen, in the confined case the numbers are good. In the shared case there's more overhead - that's the price for safety. We will be able to make this faster (by only acquiring scopes which have not already been acquired) - but note that users can always opt out of safety by projecting the `Addressable` down to a raw memory address, which would remove all the costs.

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

Commit messages:
 - Acquire/Release by-ref arguments during downcalls

Changes: https://git.openjdk.java.net/panama-foreign/pull/581/files
 Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=581&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274285
  Stats: 290 lines in 12 files changed: 261 ins; 18 del; 11 mod
  Patch: https://git.openjdk.java.net/panama-foreign/pull/581.diff
  Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/581/head:pull/581

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

From mcimadamore at openjdk.java.net  Fri Sep 24 13:33:28 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 24 Sep 2021 13:33:28 GMT
Subject: [foreign-memaccess+abi] RFR: 8274285: By reference parameters
 should be kept alive during downcalls [v2]
In-Reply-To: <3AYukUF-ebUpouONIDqVSzCmmITOPscVPLL5etV5zRo=.c6bd4afc-1259-40d2-ba44-164e27eb7164@github.com>
References: <3AYukUF-ebUpouONIDqVSzCmmITOPscVPLL5etV5zRo=.c6bd4afc-1259-40d2-ba44-164e27eb7164@github.com>
Message-ID: 

> This patch adds an adapter around the downcall method handle which keeps alive all by-reference arguments by acquiring/releasing their associated scopes.
> 
> I've implemented the adapted in a separate method in `SharedUtils`, because `SharedUtils::wrapWithAllocator` is relatively complex, and has mostly to do with creating a scope and closing it after the call.
> Also, `wrapWithAllocator` is only called when specialized method handles are active, which means adding logic there doesn't fix the programmable fallback case.
> 
> Since we plan to do more implementation restructuring in this area, I preferred to keep things simple for now.
> 
> Also note that the acquire/release logic isn't too smart - if multiple arguments backed by the same scoped are passed, we do separate acquire/release for each of them. Again, I didn't want to spend too many cycles given that the implementation of this area might change, so my aim for now was to make things safe; we can improve efficiency later.
> 
> Here are some benchmarks, for now, which compare the difference between passing a struct by reference using the struct's address (e.g. calling `MemorySegment::address` before the downcall), vs. passing the struct directly. In the first case, the scope is the global scope, so acquiring/relesing is a no-op. In the latter case we have a real scope, which we need to acquire and release.
> 
> 
> Benchmark                                                           Mode  Cnt   Score   Error  Units
> CallOverheadConstant.panama_identity_memory_address_confined        avgt   30  13.094 ? 0.220  ns/op
> CallOverheadConstant.panama_identity_memory_address_confined_3      avgt   30  16.051 ? 0.230  ns/op
> CallOverheadConstant.panama_identity_memory_address_shared          avgt   30  13.287 ? 0.172  ns/op
> CallOverheadConstant.panama_identity_memory_address_shared_3        avgt   30  15.812 ? 0.365  ns/op
> 
> Benchmark
> CallOverheadConstant.panama_identity_struct_ref_confined    avgt   30  11.544 ? 0.170  ns/op
> CallOverheadConstant.panama_identity_struct_ref_confined_3  avgt   30  12.213 ? 0.228  ns/op
> CallOverheadConstant.panama_identity_struct_ref_shared      avgt   30  17.214 ? 0.560  ns/op
> CallOverheadConstant.panama_identity_struct_ref_shared_3    avgt   30  33.132 ? 0.934  ns/op
> 
> 
> As it can be seen, in the confined case the numbers are good. In the shared case there's more overhead - that's the price for safety. We will be able to make this faster (by only acquiring scopes which have not already been acquired) - but note that users can always opt out of safety by projecting the `Addressable` down to a raw memory address, which would remove all the costs.

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

  Rename benchamrk method to avoid confusion

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

Changes:
  - all: https://git.openjdk.java.net/panama-foreign/pull/581/files
  - new: https://git.openjdk.java.net/panama-foreign/pull/581/files/4cb346ad..24ae457c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=581&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=581&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/581.diff
  Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/581/head:pull/581

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

From mcimadamore at openjdk.java.net  Fri Sep 24 13:43:16 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 24 Sep 2021 13:43:16 GMT
Subject: [foreign-memaccess+abi] RFR: Fix VarHandleTestExact
Message-ID: <0IEMaXo9tkS9Sh6mN6Z5WWYEzbeFWW8ZFytgh2eVTw0=.e72d4b61-f4d9-4064-a3bd-3fc2c82e1371@github.com>

This small patch fixes a compilation error in a j.l.i test using memory access var handles.

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

Commit messages:
 - Fix VarHandleTestExact

Changes: https://git.openjdk.java.net/panama-foreign/pull/582/files
 Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=582&range=00
  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/panama-foreign/pull/582.diff
  Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/582/head:pull/582

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

From mcimadamore at openjdk.java.net  Fri Sep 24 14:06:15 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 24 Sep 2021 14:06:15 GMT
Subject: [foreign-memaccess+abi] RFR: 8274287: Add a way to specify block size
 of unbounded arena allocator
Message-ID: 

Following the discussion here:

https://mail.openjdk.java.net/pipermail/panama-dev/2021-May/013815.html

This patch renames arena allocator factories, to make room for new unbounded factory which allows clients to specify a custom block size.

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

Commit messages:
 - Rename arena allocator factories to make room for new unbounded overload which takes block size.

Changes: https://git.openjdk.java.net/panama-foreign/pull/583/files
 Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=583&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274287
  Stats: 76 lines in 12 files changed: 44 ins; 0 del; 32 mod
  Patch: https://git.openjdk.java.net/panama-foreign/pull/583.diff
  Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/583/head:pull/583

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

From jvernee at openjdk.java.net  Fri Sep 24 14:26:15 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 24 Sep 2021 14:26:15 GMT
Subject: [foreign-memaccess+abi] RFR: 8274285: By reference parameters
 should be kept alive during downcalls [v2]
In-Reply-To: 
References: <3AYukUF-ebUpouONIDqVSzCmmITOPscVPLL5etV5zRo=.c6bd4afc-1259-40d2-ba44-164e27eb7164@github.com>
 
Message-ID: 

On Fri, 24 Sep 2021 13:33:28 GMT, Maurizio Cimadamore  wrote:

>> This patch adds an adapter around the downcall method handle which keeps alive all by-reference arguments by acquiring/releasing their associated scopes.
>> 
>> I've implemented the adapted in a separate method in `SharedUtils`, because `SharedUtils::wrapWithAllocator` is relatively complex, and has mostly to do with creating a scope and closing it after the call.
>> Also, `wrapWithAllocator` is only called when specialized method handles are active, which means adding logic there doesn't fix the programmable fallback case.
>> 
>> Since we plan to do more implementation restructuring in this area, I preferred to keep things simple for now.
>> 
>> Also note that the acquire/release logic isn't too smart - if multiple arguments backed by the same scoped are passed, we do separate acquire/release for each of them. Again, I didn't want to spend too many cycles given that the implementation of this area might change, so my aim for now was to make things safe; we can improve efficiency later.
>> 
>> Here are some benchmarks, for now, which compare the difference between passing a struct by reference using the struct's address (e.g. calling `MemorySegment::address` before the downcall), vs. passing the struct directly. In the first case, the scope is the global scope, so acquiring/relesing is a no-op. In the latter case we have a real scope, which we need to acquire and release.
>> 
>> 
>> Benchmark                                                           Mode  Cnt   Score   Error  Units
>> CallOverheadConstant.panama_identity_memory_address_confined        avgt   30  13.094 ? 0.220  ns/op
>> CallOverheadConstant.panama_identity_memory_address_confined_3      avgt   30  16.051 ? 0.230  ns/op
>> CallOverheadConstant.panama_identity_memory_address_shared          avgt   30  13.287 ? 0.172  ns/op
>> CallOverheadConstant.panama_identity_memory_address_shared_3        avgt   30  15.812 ? 0.365  ns/op
>> 
>> Benchmark
>> CallOverheadConstant.panama_identity_struct_ref_confined    avgt   30  11.544 ? 0.170  ns/op
>> CallOverheadConstant.panama_identity_struct_ref_confined_3  avgt   30  12.213 ? 0.228  ns/op
>> CallOverheadConstant.panama_identity_struct_ref_shared      avgt   30  17.214 ? 0.560  ns/op
>> CallOverheadConstant.panama_identity_struct_ref_shared_3    avgt   30  33.132 ? 0.934  ns/op
>> 
>> 
>> As it can be seen, in the confined case the numbers are good. In the shared case there's more overhead - that's the price for safety. We will be able to make this faster (by only acquiring scopes which have not already been acquired) - but note that users can always opt out of safety by projecting the `Addressable` down to a raw memory address, which would remove all the costs.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename benchamrk method to avoid confusion

Marked as reviewed by jvernee (Committer).

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

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

From jvernee at openjdk.java.net  Fri Sep 24 14:26:22 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 24 Sep 2021 14:26:22 GMT
Subject: [foreign-memaccess+abi] RFR: Fix VarHandleTestExact
In-Reply-To: <0IEMaXo9tkS9Sh6mN6Z5WWYEzbeFWW8ZFytgh2eVTw0=.e72d4b61-f4d9-4064-a3bd-3fc2c82e1371@github.com>
References: <0IEMaXo9tkS9Sh6mN6Z5WWYEzbeFWW8ZFytgh2eVTw0=.e72d4b61-f4d9-4064-a3bd-3fc2c82e1371@github.com>
Message-ID: 

On Fri, 24 Sep 2021 13:37:51 GMT, Maurizio Cimadamore  wrote:

> This small patch fixes a compilation error in a j.l.i test using memory access var handles.

Marked as reviewed by jvernee (Committer).

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

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

From jvernee at openjdk.java.net  Fri Sep 24 14:35:21 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 24 Sep 2021 14:35:21 GMT
Subject: [foreign-memaccess+abi] RFR: 8274287: Add a way to specify block
 size of unbounded arena allocator
In-Reply-To: 
References: 
Message-ID: 

On Fri, 24 Sep 2021 14:00:23 GMT, Maurizio Cimadamore  wrote:

> Following the discussion here:
> 
> https://mail.openjdk.java.net/pipermail/panama-dev/2021-May/013815.html
> 
> This patch renames arena allocator factories, to make room for new unbounded factory which allows clients to specify a custom block size.

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/SegmentAllocator.java line 399:

> 397:      *     and set {@code S = S'}; the allocator then tries to respond to the same allocation request again.
> 398:      *     
  • if the size of the allocation requests is bigger than the size of {@code S}, allocate a new segment {@code S'}
> 399:      *     (using malloc), which has a sufficient size to satisfy the allocation request, and return {@code S'}.

Instead of mentioning `malloc` here, I think it's better to say something like "using MemorySegment::allocateNative", so as not to over-specify (e.g. in case we want to change the allocator).

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/SegmentAllocator.java line 418:

> 416:      * than the thread owning {@code scope}.
> 417:      */
> 418:     static SegmentAllocator arenaUnbounded(long blockSize, ResourceScope scope) {

Would be good to check if `blockSize > 0` here I think (and add javadoc, test for that).

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

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

From mcimadamore at openjdk.java.net  Fri Sep 24 14:42:16 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 24 Sep 2021 14:42:16 GMT
Subject: [foreign-memaccess+abi] RFR: 8274287: Add a way to specify block
 size of unbounded arena allocator
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 24 Sep 2021 14:29:33 GMT, Jorn Vernee  wrote:

>> Following the discussion here:
>> 
>> https://mail.openjdk.java.net/pipermail/panama-dev/2021-May/013815.html
>> 
>> This patch renames arena allocator factories, to make room for new unbounded factory which allows clients to specify a custom block size.
>
> src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/SegmentAllocator.java line 399:
> 
>> 397:      *     and set {@code S = S'}; the allocator then tries to respond to the same allocation request again.
>> 398:      *     
  • if the size of the allocation requests is bigger than the size of {@code S}, allocate a new segment {@code S'}
>> 399:      *     (using malloc), which has a sufficient size to satisfy the allocation request, and return {@code S'}.
> 
> Instead of mentioning `malloc` here, I think it's better to say something like "using MemorySegment::allocateNative", so as not to over-specify (e.g. in case we want to change the allocator).

true - well spotted

> src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/SegmentAllocator.java line 418:
> 
>> 416:      * than the thread owning {@code scope}.
>> 417:      */
>> 418:     static SegmentAllocator arenaUnbounded(long blockSize, ResourceScope scope) {
> 
> Would be good to check if `blockSize > 0` here I think (and add javadoc, test for that).

Will do

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

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

From jvernee at openjdk.java.net  Fri Sep 24 14:43:36 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 24 Sep 2021 14:43:36 GMT
Subject: [foreign-memaccess+abi] RFR: 8274285: By reference parameters
 should be kept alive during downcalls [v2]
In-Reply-To: 
References: <3AYukUF-ebUpouONIDqVSzCmmITOPscVPLL5etV5zRo=.c6bd4afc-1259-40d2-ba44-164e27eb7164@github.com>
 
Message-ID: 

On Fri, 24 Sep 2021 13:33:28 GMT, Maurizio Cimadamore  wrote:

>> This patch adds an adapter around the downcall method handle which keeps alive all by-reference arguments by acquiring/releasing their associated scopes.
>> 
>> I've implemented the adapted in a separate method in `SharedUtils`, because `SharedUtils::wrapWithAllocator` is relatively complex, and has mostly to do with creating a scope and closing it after the call.
>> Also, `wrapWithAllocator` is only called when specialized method handles are active, which means adding logic there doesn't fix the programmable fallback case.
>> 
>> Since we plan to do more implementation restructuring in this area, I preferred to keep things simple for now.
>> 
>> Also note that the acquire/release logic isn't too smart - if multiple arguments backed by the same scoped are passed, we do separate acquire/release for each of them. Again, I didn't want to spend too many cycles given that the implementation of this area might change, so my aim for now was to make things safe; we can improve efficiency later.
>> 
>> Here are some benchmarks, for now, which compare the difference between passing a struct by reference using the struct's address (e.g. calling `MemorySegment::address` before the downcall), vs. passing the struct directly. In the first case, the scope is the global scope, so acquiring/relesing is a no-op. In the latter case we have a real scope, which we need to acquire and release.
>> 
>> 
>> Benchmark                                                           Mode  Cnt   Score   Error  Units
>> CallOverheadConstant.panama_identity_memory_address_confined        avgt   30  13.094 ? 0.220  ns/op
>> CallOverheadConstant.panama_identity_memory_address_confined_3      avgt   30  16.051 ? 0.230  ns/op
>> CallOverheadConstant.panama_identity_memory_address_shared          avgt   30  13.287 ? 0.172  ns/op
>> CallOverheadConstant.panama_identity_memory_address_shared_3        avgt   30  15.812 ? 0.365  ns/op
>> 
>> Benchmark
>> CallOverheadConstant.panama_identity_struct_ref_confined    avgt   30  11.544 ? 0.170  ns/op
>> CallOverheadConstant.panama_identity_struct_ref_confined_3  avgt   30  12.213 ? 0.228  ns/op
>> CallOverheadConstant.panama_identity_struct_ref_shared      avgt   30  17.214 ? 0.560  ns/op
>> CallOverheadConstant.panama_identity_struct_ref_shared_3    avgt   30  33.132 ? 0.934  ns/op
>> 
>> 
>> As it can be seen, in the confined case the numbers are good. In the shared case there's more overhead - that's the price for safety. We will be able to make this faster (by only acquiring scopes which have not already been acquired) - but note that users can always opt out of safety by projecting the `Addressable` down to a raw memory address, which would remove all the costs.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename benchamrk method to avoid confusion

Already approved but now thinking of this: I think the javadoc in CLinker needs to be updated to specify the new behavior as well? (it's currently missing for the reachability fences, but I think it would be good to add something...)

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

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

From mcimadamore at openjdk.java.net  Fri Sep 24 14:49:01 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 24 Sep 2021 14:49:01 GMT
Subject: [foreign-memaccess+abi] RFR: 8274287: Add a way to specify block
 size of unbounded arena allocator [v2]
In-Reply-To: 
References: 
Message-ID: <623Sld9ZuU-nUFqgeBdIwyQVPi24-9doq4V4rq7xvvg=.8fef28c0-7443-4e79-a256-b6c78904f9bd@github.com>

> Following the discussion here:
> 
> https://mail.openjdk.java.net/pipermail/panama-dev/2021-May/013815.html
> 
> This patch renames arena allocator factories, to make room for new unbounded factory which allows clients to specify a custom block size.

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

  Address review comments

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

Changes:
  - all: https://git.openjdk.java.net/panama-foreign/pull/583/files
  - new: https://git.openjdk.java.net/panama-foreign/pull/583/files/eeea3f89..3ee0f9d9

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

  Stats: 13 lines in 2 files changed: 9 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/panama-foreign/pull/583.diff
  Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/583/head:pull/583

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

From jvernee at openjdk.java.net  Fri Sep 24 14:52:11 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 24 Sep 2021 14:52:11 GMT
Subject: [foreign-memaccess+abi] RFR: 8274287: Add a way to specify block
 size of unbounded arena allocator [v2]
In-Reply-To: <623Sld9ZuU-nUFqgeBdIwyQVPi24-9doq4V4rq7xvvg=.8fef28c0-7443-4e79-a256-b6c78904f9bd@github.com>
References: 
 <623Sld9ZuU-nUFqgeBdIwyQVPi24-9doq4V4rq7xvvg=.8fef28c0-7443-4e79-a256-b6c78904f9bd@github.com>
Message-ID: 

On Fri, 24 Sep 2021 14:49:01 GMT, Maurizio Cimadamore  wrote:

>> Following the discussion here:
>> 
>> https://mail.openjdk.java.net/pipermail/panama-dev/2021-May/013815.html
>> 
>> This patch renames arena allocator factories, to make room for new unbounded factory which allows clients to specify a custom block size.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/SegmentAllocator.java line 361:

> 359:      *     and set {@code S = S'}; the allocator then tries to respond to the same allocation request again.
> 360:      *     
  • if the size of the allocation requests is bigger than the size of {@code S}, allocate a new segment {@code S'}
> 361:      *     (using malloc), which has a sufficient size to satisfy the allocation request, and return {@code S'}.

Still a mention of `malloc` here, as well as in the same text for the other `arenaUnbounded` overload.

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

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

From duke at openjdk.java.net  Fri Sep 24 14:57:16 2021
From: duke at openjdk.java.net (duke)
Date: Fri, 24 Sep 2021 14:57:16 GMT
Subject: git: openjdk/panama-foreign: foreign-jextract: 2 new changesets
Message-ID: 

Changeset: 93455403
Author:    Maurizio Cimadamore 
Date:      2021-09-24 14:55:14 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/934554032fdce622f95f7f70728470d3b5679a29

Fix VarHandleTestExact

Reviewed-by: jvernee

! test/jdk/java/lang/invoke/VarHandles/VarHandleTestExact.java

Changeset: cf74d355
Author:    duke 
Date:      2021-09-24 14:55:58 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/cf74d355a534b2ca79475a14e0e2e40c860bcd34

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



From mcimadamore at openjdk.java.net  Fri Sep 24 14:59:24 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 24 Sep 2021 14:59:24 GMT
Subject: [foreign-memaccess+abi] Integrated: Fix VarHandleTestExact
In-Reply-To: <0IEMaXo9tkS9Sh6mN6Z5WWYEzbeFWW8ZFytgh2eVTw0=.e72d4b61-f4d9-4064-a3bd-3fc2c82e1371@github.com>
References: <0IEMaXo9tkS9Sh6mN6Z5WWYEzbeFWW8ZFytgh2eVTw0=.e72d4b61-f4d9-4064-a3bd-3fc2c82e1371@github.com>
Message-ID: 

On Fri, 24 Sep 2021 13:37:51 GMT, Maurizio Cimadamore  wrote:

> This small patch fixes a compilation error in a j.l.i test using memory access var handles.

This pull request has now been integrated.

Changeset: 93455403
Author:    Maurizio Cimadamore 
URL:       https://git.openjdk.java.net/panama-foreign/commit/934554032fdce622f95f7f70728470d3b5679a29
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

Fix VarHandleTestExact

Reviewed-by: jvernee

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

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

From mcimadamore at openjdk.java.net  Fri Sep 24 15:01:08 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 24 Sep 2021 15:01:08 GMT
Subject: [foreign-memaccess+abi] RFR: 8274285: By reference parameters
 should be kept alive during downcalls [v3]
In-Reply-To: <3AYukUF-ebUpouONIDqVSzCmmITOPscVPLL5etV5zRo=.c6bd4afc-1259-40d2-ba44-164e27eb7164@github.com>
References: <3AYukUF-ebUpouONIDqVSzCmmITOPscVPLL5etV5zRo=.c6bd4afc-1259-40d2-ba44-164e27eb7164@github.com>
Message-ID: 

> This patch adds an adapter around the downcall method handle which keeps alive all by-reference arguments by acquiring/releasing their associated scopes.
> 
> I've implemented the adapted in a separate method in `SharedUtils`, because `SharedUtils::wrapWithAllocator` is relatively complex, and has mostly to do with creating a scope and closing it after the call.
> Also, `wrapWithAllocator` is only called when specialized method handles are active, which means adding logic there doesn't fix the programmable fallback case.
> 
> Since we plan to do more implementation restructuring in this area, I preferred to keep things simple for now.
> 
> Also note that the acquire/release logic isn't too smart - if multiple arguments backed by the same scoped are passed, we do separate acquire/release for each of them. Again, I didn't want to spend too many cycles given that the implementation of this area might change, so my aim for now was to make things safe; we can improve efficiency later.
> 
> Here are some benchmarks, for now, which compare the difference between passing a struct by reference using the struct's address (e.g. calling `MemorySegment::address` before the downcall), vs. passing the struct directly. In the first case, the scope is the global scope, so acquiring/relesing is a no-op. In the latter case we have a real scope, which we need to acquire and release.
> 
> 
> Benchmark                                                           Mode  Cnt   Score   Error  Units
> CallOverheadConstant.panama_identity_memory_address_confined        avgt   30  13.094 ? 0.220  ns/op
> CallOverheadConstant.panama_identity_memory_address_confined_3      avgt   30  16.051 ? 0.230  ns/op
> CallOverheadConstant.panama_identity_memory_address_shared          avgt   30  13.287 ? 0.172  ns/op
> CallOverheadConstant.panama_identity_memory_address_shared_3        avgt   30  15.812 ? 0.365  ns/op
> 
> Benchmark
> CallOverheadConstant.panama_identity_struct_ref_confined    avgt   30  11.544 ? 0.170  ns/op
> CallOverheadConstant.panama_identity_struct_ref_confined_3  avgt   30  12.213 ? 0.228  ns/op
> CallOverheadConstant.panama_identity_struct_ref_shared      avgt   30  17.214 ? 0.560  ns/op
> CallOverheadConstant.panama_identity_struct_ref_shared_3    avgt   30  33.132 ? 0.934  ns/op
> 
> 
> As it can be seen, in the confined case the numbers are good. In the shared case there's more overhead - that's the price for safety. We will be able to make this faster (by only acquiring scopes which have not already been acquired) - but note that users can always opt out of safety by projecting the `Addressable` down to a raw memory address, which would remove all the costs.

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

  Add javadoc describing the linker behavior w.r.t. by-reference parameters in downcalls

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

Changes:
  - all: https://git.openjdk.java.net/panama-foreign/pull/581/files
  - new: https://git.openjdk.java.net/panama-foreign/pull/581/files/24ae457c..6a63761a

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

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

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

From mcimadamore at openjdk.java.net  Fri Sep 24 15:01:09 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 24 Sep 2021 15:01:09 GMT
Subject: [foreign-memaccess+abi] RFR: 8274285: By reference parameters
 should be kept alive during downcalls [v2]
In-Reply-To: 
References: <3AYukUF-ebUpouONIDqVSzCmmITOPscVPLL5etV5zRo=.c6bd4afc-1259-40d2-ba44-164e27eb7164@github.com>
 
 
Message-ID: 

On Fri, 24 Sep 2021 14:37:54 GMT, Jorn Vernee  wrote:

> Already approved but now thinking of this: I think the javadoc in CLinker needs to be updated to specify the new behavior as well? (it's currently missing for the reachability fences, but I think it would be good to add something...)

Added extra javadoc.

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

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

From mcimadamore at openjdk.java.net  Fri Sep 24 15:04:59 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 24 Sep 2021 15:04:59 GMT
Subject: [foreign-memaccess+abi] RFR: 8274287: Add a way to specify block
 size of unbounded arena allocator [v3]
In-Reply-To: 
References: 
Message-ID: 

> Following the discussion here:
> 
> https://mail.openjdk.java.net/pipermail/panama-dev/2021-May/013815.html
> 
> This patch renames arena allocator factories, to make room for new unbounded factory which allows clients to specify a custom block size.

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

  Drop additional references to `malloc`

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

Changes:
  - all: https://git.openjdk.java.net/panama-foreign/pull/583/files
  - new: https://git.openjdk.java.net/panama-foreign/pull/583/files/3ee0f9d9..51268647

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

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

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

From mcimadamore at openjdk.java.net  Fri Sep 24 15:05:01 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 24 Sep 2021 15:05:01 GMT
Subject: [foreign-memaccess+abi] RFR: 8274287: Add a way to specify block
 size of unbounded arena allocator [v2]
In-Reply-To: 
References: 
 <623Sld9ZuU-nUFqgeBdIwyQVPi24-9doq4V4rq7xvvg=.8fef28c0-7443-4e79-a256-b6c78904f9bd@github.com>
 
Message-ID: 

On Fri, 24 Sep 2021 14:49:23 GMT, Jorn Vernee  wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review comments
>
> src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/SegmentAllocator.java line 361:
> 
>> 359:      *     and set {@code S = S'}; the allocator then tries to respond to the same allocation request again.
>> 360:      *     
  • if the size of the allocation requests is bigger than the size of {@code S}, allocate a new segment {@code S'}
>> 361:      *     (using malloc), which has a sufficient size to satisfy the allocation request, and return {@code S'}.
> 
> Still a mention of `malloc` here, as well as in the same text for the other `arenaUnbounded` overload.

Sorry - missed those. Hopefully fixed now.

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

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

From jvernee at openjdk.java.net  Fri Sep 24 15:29:12 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 24 Sep 2021 15:29:12 GMT
Subject: [foreign-memaccess+abi] RFR: 8274287: Add a way to specify block
 size of unbounded arena allocator [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 24 Sep 2021 15:04:59 GMT, Maurizio Cimadamore  wrote:

>> Following the discussion here:
>> 
>> https://mail.openjdk.java.net/pipermail/panama-dev/2021-May/013815.html
>> 
>> This patch renames arena allocator factories, to make room for new unbounded factory which allows clients to specify a custom block size.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Drop additional references to `malloc`

Marked as reviewed by jvernee (Committer).

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

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

From mcimadamore at openjdk.java.net  Fri Sep 24 15:29:35 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 24 Sep 2021 15:29:35 GMT
Subject: [foreign-memaccess+abi] Integrated: 8274285: By reference parameters
 should be kept alive during downcalls
In-Reply-To: <3AYukUF-ebUpouONIDqVSzCmmITOPscVPLL5etV5zRo=.c6bd4afc-1259-40d2-ba44-164e27eb7164@github.com>
References: <3AYukUF-ebUpouONIDqVSzCmmITOPscVPLL5etV5zRo=.c6bd4afc-1259-40d2-ba44-164e27eb7164@github.com>
Message-ID: 

On Fri, 24 Sep 2021 13:10:44 GMT, Maurizio Cimadamore  wrote:

> This patch adds an adapter around the downcall method handle which keeps alive all by-reference arguments by acquiring/releasing their associated scopes.
> 
> I've implemented the adapted in a separate method in `SharedUtils`, because `SharedUtils::wrapWithAllocator` is relatively complex, and has mostly to do with creating a scope and closing it after the call.
> Also, `wrapWithAllocator` is only called when specialized method handles are active, which means adding logic there doesn't fix the programmable fallback case.
> 
> Since we plan to do more implementation restructuring in this area, I preferred to keep things simple for now.
> 
> Also note that the acquire/release logic isn't too smart - if multiple arguments backed by the same scoped are passed, we do separate acquire/release for each of them. Again, I didn't want to spend too many cycles given that the implementation of this area might change, so my aim for now was to make things safe; we can improve efficiency later.
> 
> Here are some benchmarks, for now, which compare the difference between passing a struct by reference using the struct's address (e.g. calling `MemorySegment::address` before the downcall), vs. passing the struct directly. In the first case, the scope is the global scope, so acquiring/relesing is a no-op. In the latter case we have a real scope, which we need to acquire and release.
> 
> 
> Benchmark                                                           Mode  Cnt   Score   Error  Units
> CallOverheadConstant.panama_identity_memory_address_confined        avgt   30  13.094 ? 0.220  ns/op
> CallOverheadConstant.panama_identity_memory_address_confined_3      avgt   30  16.051 ? 0.230  ns/op
> CallOverheadConstant.panama_identity_memory_address_shared          avgt   30  13.287 ? 0.172  ns/op
> CallOverheadConstant.panama_identity_memory_address_shared_3        avgt   30  15.812 ? 0.365  ns/op
> 
> Benchmark
> CallOverheadConstant.panama_identity_struct_ref_confined    avgt   30  11.544 ? 0.170  ns/op
> CallOverheadConstant.panama_identity_struct_ref_confined_3  avgt   30  12.213 ? 0.228  ns/op
> CallOverheadConstant.panama_identity_struct_ref_shared      avgt   30  17.214 ? 0.560  ns/op
> CallOverheadConstant.panama_identity_struct_ref_shared_3    avgt   30  33.132 ? 0.934  ns/op
> 
> 
> As it can be seen, in the confined case the numbers are good. In the shared case there's more overhead - that's the price for safety. We will be able to make this faster (by only acquiring scopes which have not already been acquired) - but note that users can always opt out of safety by projecting the `Addressable` down to a raw memory address, which would remove all the costs.

This pull request has now been integrated.

Changeset: 208d6b7b
Author:    Maurizio Cimadamore 
URL:       https://git.openjdk.java.net/panama-foreign/commit/208d6b7b959e222b2141ff192a442bde86a08292
Stats:     298 lines in 13 files changed: 267 ins; 18 del; 13 mod

8274285: By reference parameters should be kept alive during downcalls

Reviewed-by: jvernee

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

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

From duke at openjdk.java.net  Fri Sep 24 15:30:04 2021
From: duke at openjdk.java.net (duke)
Date: Fri, 24 Sep 2021 15:30:04 GMT
Subject: git: openjdk/panama-foreign: foreign-jextract: 2 new changesets
Message-ID: 

Changeset: 208d6b7b
Author:    Maurizio Cimadamore 
Date:      2021-09-24 15:27:08 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/208d6b7b959e222b2141ff192a442bde86a08292

8274285: By reference parameters should be kept alive during downcalls

Reviewed-by: jvernee

! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.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/classes/jdk/internal/foreign/abi/aarch64/linux/LinuxAArch64Linker.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/x64/sysv/SysVx64Linker.java
! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/x64/windows/Windowsx64Linker.java
! test/jdk/java/foreign/SafeFunctionAccessTest.java
! test/jdk/java/foreign/libSafeAccess.c
! 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/libCallOverhead.c

Changeset: b3cfaca1
Author:    duke 
Date:      2021-09-24 15:28:12 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/b3cfaca101daf531cd34d63db6795785006d2495

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



From duke at openjdk.java.net  Fri Sep 24 15:44:35 2021
From: duke at openjdk.java.net (duke)
Date: Fri, 24 Sep 2021 15:44:35 GMT
Subject: git: openjdk/panama-foreign: foreign-jextract: 2 new changesets
Message-ID: 

Changeset: 5ce4e30b
Author:    Maurizio Cimadamore 
Date:      2021-09-24 15:41:51 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/5ce4e30bb880e45daa86c757dba1e990baa8de76

8274287: Add a way to specify block size of unbounded arena allocator

Reviewed-by: jvernee

! 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/internal/foreign/ArenaAllocator.java
! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/Binding.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/MacOsAArch64VaList.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/windows/WinVaList.java
! test/jdk/java/foreign/NativeTestHelper.java
! test/jdk/java/foreign/TestScopedOperations.java
! test/jdk/java/foreign/TestSegmentAllocators.java
! test/micro/org/openjdk/bench/jdk/incubator/foreign/StrLenTest.java

Changeset: 54ec366b
Author:    duke 
Date:      2021-09-24 15:42:37 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/54ec366b4960be803e40d57bcd00b5b714840084

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



From mcimadamore at openjdk.java.net  Fri Sep 24 15:45:14 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 24 Sep 2021 15:45:14 GMT
Subject: [foreign-memaccess+abi] Integrated: 8274287: Add a way to specify
 block size of unbounded arena allocator
In-Reply-To: 
References: 
Message-ID: 

On Fri, 24 Sep 2021 14:00:23 GMT, Maurizio Cimadamore  wrote:

> Following the discussion here:
> 
> https://mail.openjdk.java.net/pipermail/panama-dev/2021-May/013815.html
> 
> This patch renames arena allocator factories, to make room for new unbounded factory which allows clients to specify a custom block size.

This pull request has now been integrated.

Changeset: 5ce4e30b
Author:    Maurizio Cimadamore 
URL:       https://git.openjdk.java.net/panama-foreign/commit/5ce4e30bb880e45daa86c757dba1e990baa8de76
Stats:     92 lines in 12 files changed: 53 ins; 0 del; 39 mod

8274287: Add a way to specify block size of unbounded arena allocator

Reviewed-by: jvernee

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

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

From mcimadamore at openjdk.java.net  Fri Sep 24 15:59:14 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 24 Sep 2021 15:59:14 GMT
Subject: [foreign-jextract] RFR: Fix jextract test after arena allocator API
 change
Message-ID: 

As the subject says, this simple change tweaks one jextract test to use the new arena allocator method name.

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

Commit messages:
 - Fix test to use new arena allocator method name

Changes: https://git.openjdk.java.net/panama-foreign/pull/584/files
 Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=584&range=00
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/panama-foreign/pull/584.diff
  Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/584/head:pull/584

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

From sviswanathan at openjdk.java.net  Fri Sep 24 16:18:15 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Fri, 24 Sep 2021 16:18:15 GMT
Subject: [vectorIntrinsics+mask] RFR: Merge panama-vector:vectorIntrinsics
In-Reply-To: 
References: 
Message-ID: 

On Fri, 24 Sep 2021 09:42:59 GMT, Ningsheng Jian  wrote:

> AArch64 conflicts resolved. Others are clean.

Marked as reviewed by sviswanathan (Committer).

@nsjian Thanks a lot for the merge.

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

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

From sundar at openjdk.java.net  Fri Sep 24 16:37:03 2021
From: sundar at openjdk.java.net (Athijegannathan Sundararajan)
Date: Fri, 24 Sep 2021 16:37:03 GMT
Subject: [foreign-jextract] RFR: Fix jextract test after arena allocator
 API change
In-Reply-To: 
References: 
Message-ID: 

On Fri, 24 Sep 2021 15:53:51 GMT, Maurizio Cimadamore  wrote:

> As the subject says, this simple change tweaks one jextract test to use the new arena allocator method name.

Marked as reviewed by sundar (Committer).

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

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

From mcimadamore at openjdk.java.net  Fri Sep 24 16:49:04 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 24 Sep 2021 16:49:04 GMT
Subject: [foreign-jextract] Integrated: Fix jextract test after arena
 allocator API change
In-Reply-To: 
References: 
Message-ID: 

On Fri, 24 Sep 2021 15:53:51 GMT, Maurizio Cimadamore  wrote:

> As the subject says, this simple change tweaks one jextract test to use the new arena allocator method name.

This pull request has now been integrated.

Changeset: 23490d01
Author:    Maurizio Cimadamore 
URL:       https://git.openjdk.java.net/panama-foreign/commit/23490d0121f1f947ca95e72c16ec877c99559680
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

Fix jextract test after arena allocator API change

Reviewed-by: sundar

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

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

From njian at openjdk.java.net  Sat Sep 25 02:20:02 2021
From: njian at openjdk.java.net (Ningsheng Jian)
Date: Sat, 25 Sep 2021 02:20:02 GMT
Subject: [vectorIntrinsics+mask] RFR: Merge panama-vector:vectorIntrinsics
 [v2]
In-Reply-To: 
References: 
Message-ID: 

> AArch64 conflicts resolved. Others are clean.

Ningsheng Jian has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 32 commits:

 - Merge vectorIntrinsics into vectorIntrinsics+mask
 - 8274236: Cleanups related to X86 masking support.
   
   Reviewed-by: sviswanathan
 - 8273949: Intrinsic creation for VectorMask.toLong operation.
   
   Reviewed-by: psandoz, sviswanathan, eliu
 - 8273264: AArch64: [vector] Add missing rules for VectorMaskCast
   
   Co-authored-by: Ningsheng Jian 
   Reviewed-by: njian, psandoz
 - 8273406: Optimize various masked vector operations for AVX512 target.
   
   Reviewed-by: sviswanathan
 - 8273367: [Vector API] Fix a regression of rearrange intrinsic after JDK-8272479
   
   Reviewed-by: njian
 - 8273371: [Vector API] Crash in Assembler::evpermd when code-gen for masked rearrange operation on AVX512
   
   Reviewed-by: jbhateja
 - 8273205: [Vector API] Crash in C2_MacroAssembler::vprotate_var after JDK-8271366
   
   Reviewed-by: njian, jbhateja
 - 8272745: VectorAPI: Vector/Mask type cleanup for masked vector intrinsics
   
   Co-authored-by: Paul Sandoz 
   Reviewed-by: psandoz
 - 8273159: Remove LoadVectorMaskNode/StoreVectorMaskNode
   
   Co-authored-by: Xiaohong Gong 
   Co-authored-by: Ningsheng Jian 
   Reviewed-by: eliu, sviswanathan
 - ... and 22 more: https://git.openjdk.java.net/panama-vector/compare/98a7a541...7903c351

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

Changes: https://git.openjdk.java.net/panama-vector/pull/132/files
 Webrev: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=132&range=01
  Stats: 20827 lines in 101 files changed: 16112 ins; 1615 del; 3100 mod
  Patch: https://git.openjdk.java.net/panama-vector/pull/132.diff
  Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/132/head:pull/132

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

From njian at openjdk.java.net  Sat Sep 25 02:20:04 2021
From: njian at openjdk.java.net (Ningsheng Jian)
Date: Sat, 25 Sep 2021 02:20:04 GMT
Subject: [vectorIntrinsics+mask] Integrated: Merge
 panama-vector:vectorIntrinsics
In-Reply-To: 
References: 
Message-ID: <9RK502bD37naTheVzv-y3mUuJwfPgPq809Qgs1EZdjQ=.b3b4075b-e542-4963-bcae-7ddc346f6483@github.com>

On Fri, 24 Sep 2021 09:42:59 GMT, Ningsheng Jian  wrote:

> AArch64 conflicts resolved. Others are clean.

This pull request has now been integrated.

Changeset: b4d6d5c4
Author:    Ningsheng Jian 
URL:       https://git.openjdk.java.net/panama-vector/commit/b4d6d5c4d55647977e60212c61fcd5e90d08e59f
Stats:     47675 lines in 1789 files changed: 29770 ins; 9632 del; 8273 mod

Merge panama-vector:vectorIntrinsics

Reviewed-by: eliu, sviswanathan

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

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

From samuel.audet at gmail.com  Sat Sep 25 13:17:44 2021
From: samuel.audet at gmail.com (Samuel Audet)
Date: Sat, 25 Sep 2021 22:17:44 +0900
Subject: Will we need to use the --enable-native-access option to enable
 JNI in the future?
In-Reply-To: <2b3c3be4-3dbb-9831-c9f0-cb662a7b4f76@oracle.com>
References: 
 
 
 
 
 <18b80809-54b1-1b40-e5f2-a2b1a4e10711@oracle.com>
 
 <2eb43d4c-6eee-39f7-877b-d98681773520@oracle.com>
 
 <6c4f7554-4d9d-e094-46b5-a6c2c9d7f159@gmail.com>
 
 
 <2b3c3be4-3dbb-9831-c9f0-cb662a7b4f76@oracle.com>
Message-ID: 

We can still do auditing at test time and even after everything's been
deployed in the wild, for example, something like this:
https://developer.android.com/guide/topics/data/audit-access

That said, it is best to catch as many errors as possible as early as
possible, and if I understand correctly what you're saying now, this is
what this experiment is all about...

Samuel

On Fri, Sep 24, 2021, 18:46 Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

>
> On 24/09/2021 04:53, Samuel Audet wrote:
> > I think your main point is that the "application packager has no way
> > to be notified when _something_ changes in the dependencies of his/her
> > application", which sounds reasonable, but I don't see when that would
> > be a problem. Could you elaborate on this scenario? In my book,
> > "application packagers" are also programmers, so they already do
> > things like test applications in multiple environments anyway (with
> > and without sudo-like permissions), so I think that any changes in the
> > dependencies would easily show up at that stage. Do you have a
> > counterexample in mind?
>
> The counterexample I have in mind is auditing. If you distribute a
> binary in the wild, you probably want to be very careful not only about
> what yout application does, but also whether your code has dependencies
> on libraries which might do something strange. From the perspective of
> the distributor, any native access (whether direct, or indirect) counts:
> if a bad native access in a 5-th level dependency compromises the
> application, the application as a whole will be considered "at fault".
>
> Nevertheless, your point is valid: the distinction between a developer
> deploying a test on X and an "application packager" is subtle, and I get
> that, in the former case, the restrictions imposed by the mechanism we
> have now can be perceived as overly strict.
>
> No matter how you look at it, I think it's a hard thing to balance - as
> soon as you make some sort of escape hatch available via command-line
> and/or environment (for the developer use case), it is hard then not to
> lose all the benefits for the auditing-like use cases.
>
> That said, the feedback in this thread will be taken into account, and
> we will consider minor tweaks to the existing mechanism which will
> provide for a smoother transition from JNI to Panama, as well as to
> reduce friction in the cases you mention.
>
> Maurizio
>
>
>
>
>

From aph-open at littlepinkcloud.com  Sat Sep 25 17:04:59 2021
From: aph-open at littlepinkcloud.com (Andrew Haley)
Date: Sat, 25 Sep 2021 18:04:59 +0100
Subject: Will we need to use the --enable-native-access option to enable
 JNI in the future?
In-Reply-To: <2b3c3be4-3dbb-9831-c9f0-cb662a7b4f76@oracle.com>
References: 
 
 
 
 
 <18b80809-54b1-1b40-e5f2-a2b1a4e10711@oracle.com>
 
 <2eb43d4c-6eee-39f7-877b-d98681773520@oracle.com>
 
 <6c4f7554-4d9d-e094-46b5-a6c2c9d7f159@gmail.com>
 
 
 <2b3c3be4-3dbb-9831-c9f0-cb662a7b4f76@oracle.com>
Message-ID: <07931247-049e-ccb4-74d9-1befce26e350@littlepinkcloud.com>

On 9/24/21 10:46 AM, Maurizio Cimadamore wrote:
> 
> On 24/09/2021 04:53, Samuel Audet wrote:
>> I think your main point is that the "application packager has no way 
>> to be notified when _something_ changes in the dependencies of his/her 
>> application", which sounds reasonable, but I don't see when that would 
>> be a problem. Could you elaborate on this scenario? In my book, 
>> "application packagers" are also programmers, so they already do 
>> things like test applications in multiple environments anyway (with 
>> and without sudo-like permissions), so I think that any changes in the 
>> dependencies would easily show up at that stage. Do you have a 
>> counterexample in mind? 
> 
> The counterexample I have in mind is auditing. If you distribute a 
> binary in the wild, you probably want to be very careful not only about 
> what yout application does, but also whether your code has dependencies 
> on libraries which might do something strange.

For a real-world example of this, I've had JVM crashes that look like
heap corruption, and asked a customer whether there was any native code
involved: it's always useful to exclude that possibility early in the
process. I got the answer "no", and struggled to replicate the bug. When
I eventually did replicate it, there was indeed a native library. One of
the libraries used by the customer, unknown to them, hid a native library
in the jarfile, unpacked it into /tmp, and deleted it from /tmp when the
program terminated.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. 
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From jiefu at openjdk.java.net  Sun Sep 26 15:51:26 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Sun, 26 Sep 2021 15:51:26 GMT
Subject: [vectorIntrinsics+mask] RFR: 8273949: Intrinsic creation for
 VectorMask.toLong operation. [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 23 Sep 2021 03:16:38 GMT, Jatin Bhateja  wrote:

>> Summary of changes:
>> - Intrinsification of VectorMask.toLong() API.
>> - Supports inline expansion for both AVX512 and non-AVX512 targets.
>> - Used toLong() API to optimize existing Java API implementation of VectorMask.laneIsSet() operation.
>> 
>> Following performance number are generated using JMH benchmark modification included with the patch.
>> 
>> System:  Intel(R) Xeon(R) Platinum 8280 CPU @ 2.70GHz (Cascade Lake Server 28C 2S)
>> 
>> Benchmark | VECSIZE | Baseline Score (ops/ms) | With Opt (ops/ms) | Gain Ratio
>> -- | -- | -- | -- | --
>> MaskQueryOperationsBenchmark.testToLongByte | 128 | 90451.424 | 346941.379 | 3.835665196
>> MaskQueryOperationsBenchmark.testToLongByte | 256 | 63127.764 | 338331.425 | 5.359471072
>> MaskQueryOperationsBenchmark.testToLongByte | 512 | 40543.264 | 313836.333 | 7.740776199
>> MaskQueryOperationsBenchmark.testToLongLong | 128 | 171989.714 | 152872.758 | 0.88884826
>> MaskQueryOperationsBenchmark.testToLongLong | 256 | 164702.273 | 324794.578 | 1.972010295
>> MaskQueryOperationsBenchmark.testToLongLong | 512 | 122667.916 | 318060.096 | 2.59285481
>> MaskQueryOperationsBenchmark.testToLongShort | 128 | 122656.408 | 346691.082 | 2.826522378
>> MaskQueryOperationsBenchmark.testToLongShort | 256 | 96838.555 | 360909.28 | 3.726917239
>> MaskQueryOperationsBenchmark.testToLongShort | 512 | 63119.009 | 313075.159 | 4.960077225
>> MaskQueryOperationsBenchmark.testToLonglong | 128 | 180855.623 | 324620.433 | 1.794914792
>> MaskQueryOperationsBenchmark.testToLonglong | 256 | 122705.631 | 324315.916 | 2.643040204
>> MaskQueryOperationsBenchmark.testToLonglong | 512 | 90396.687 | 324318.095 | 3.58772103
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8273949: Resolving synthetic comment.

Build failure on MacOS after this PR: https://github.com/openjdk/panama-vector/pull/133 .

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

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

From anhmdq at gmail.com  Sun Sep 26 17:27:02 2021
From: anhmdq at gmail.com (=?UTF-8?Q?Qu=C3=A2n_Anh_Mai?=)
Date: Mon, 27 Sep 2021 00:27:02 +0700
Subject: A bug in the Vector API?
Message-ID: 

Hi,

I don't know whether this is the correct place to report this. There seems
to be a bug in the implementation of `AbstractVector.resizeLanes0`. To be
more specific, the mask which is used to remove the sign extension of the
signed cast is created as `long mask = -1L >>> sizeChange;`. However, this
results in a very large value of mask which will be rejected by the
following broadcast. If I'm not mistaken, the mask should be created by
`long mask = -1L >>> -dsp.elementSize();` instead.

Steps to reproduce:
- Use vector unsigned casts in the form of
someVector.convertShape(VectorOperators.ZERO_EXTEND_...).
- The operation will then throw IllegalArgumentException.

Regards,
Qu?n Anh

From jiefu at openjdk.java.net  Sun Sep 26 21:29:07 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Sun, 26 Sep 2021 21:29:07 GMT
Subject: [vectorIntrinsics+mask] RFR: 8274331: [Vector API] Build failure on
 MacOS after JDK-8273949
Message-ID: 

Hi all,

Build failure was observed on our MacOS platform after JDK-8273949.

It seems to be caused by a typo in the jmh test [1] since after this fix the build is fine.

I'm still not clear how this can happen.
But it would be better to fix this typo.

Thanks.
Best regards,
Jie

[1] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics%2Bmask/test/micro/org/openjdk/bench/jdk/incubator/vector/MaskQueryOperationsBenchmark.java#L169

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

Commit messages:
 - 8274331: [Vector API] Build failure on MacOS after JDK-8273949

Changes: https://git.openjdk.java.net/panama-vector/pull/133/files
 Webrev: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=133&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274331
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/panama-vector/pull/133.diff
  Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/133/head:pull/133

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

From njian at openjdk.java.net  Mon Sep 27 07:09:02 2021
From: njian at openjdk.java.net (Ningsheng Jian)
Date: Mon, 27 Sep 2021 07:09:02 GMT
Subject: [vectorIntrinsics+mask] RFR: 8274331: [Vector API] Build failure
 on MacOS after JDK-8273949
In-Reply-To: 
References: 
Message-ID: 

On Sun, 26 Sep 2021 15:39:27 GMT, Jie Fu  wrote:

> Hi all,
> 
> Build failure was observed on our MacOS platform after JDK-8273949.
> 
> It seems to be caused by a typo in the jmh test [1] since after this fix the build is fine.
> 
> I'm still not clear how this can happen.
> But it would be better to fix this typo.
> 
> Thanks.
> Best regards,
> Jie
> 
> [1] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics%2Bmask/test/micro/org/openjdk/bench/jdk/incubator/vector/MaskQueryOperationsBenchmark.java#L169

Looks good to me. JMH will generate test class for each case. MacOS by default is not a case sensitive file system, and there are two tests with 'same' name 'testToLonglong' and 'testToLongLong'.

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

Marked as reviewed by njian (Committer).

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

From jiefu at openjdk.java.net  Mon Sep 27 07:25:51 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Mon, 27 Sep 2021 07:25:51 GMT
Subject: [vectorIntrinsics+mask] RFR: 8274331: [Vector API] Build failure
 on MacOS after JDK-8273949
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 27 Sep 2021 07:06:14 GMT, Ningsheng Jian  wrote:

> Looks good to me. JMH will generate test class for each case. MacOS by default is not a case sensitive file system, and there are two tests with 'same' name 'testToLonglong' and 'testToLongLong'.

Ah, got it.
And I verified this fact with:

$ cp T.java t.java
cp: t.java and T.java are identical (not copied).


Thanks a lot.

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

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

From jbhateja at openjdk.java.net  Mon Sep 27 07:41:12 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Mon, 27 Sep 2021 07:41:12 GMT
Subject: [vectorIntrinsics+mask] RFR: 8274331: [Vector API] Build failure
 on MacOS after JDK-8273949
In-Reply-To: 
References: 
Message-ID: 

On Sun, 26 Sep 2021 15:39:27 GMT, Jie Fu  wrote:

> Hi all,
> 
> Build failure was observed on our MacOS platform after JDK-8273949.
> 
> It seems to be caused by a typo in the jmh test [1] since after this fix the build is fine.
> 
> I'm still not clear how this can happen.
> But it would be better to fix this typo.
> 
> Thanks.
> Best regards,
> Jie
> 
> [1] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics%2Bmask/test/micro/org/openjdk/bench/jdk/incubator/vector/MaskQueryOperationsBenchmark.java#L169

Marked as reviewed by jbhateja (Committer).

LGTM

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

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

From jiefu at openjdk.java.net  Mon Sep 27 09:28:04 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Mon, 27 Sep 2021 09:28:04 GMT
Subject: [vectorIntrinsics+mask] RFR: 8274331: [Vector API] Build failure
 on MacOS after JDK-8273949
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 27 Sep 2021 07:06:14 GMT, Ningsheng Jian  wrote:

>> Hi all,
>> 
>> Build failure was observed on our MacOS platform after JDK-8273949.
>> 
>> It seems to be caused by a typo in the jmh test [1] since after this fix the build is fine.
>> 
>> I'm still not clear how this can happen.
>> But it would be better to fix this typo.
>> 
>> Thanks.
>> Best regards,
>> Jie
>> 
>> [1] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics%2Bmask/test/micro/org/openjdk/bench/jdk/incubator/vector/MaskQueryOperationsBenchmark.java#L169
>
> Looks good to me. JMH will generate test class for each case. MacOS by default is not a case sensitive file system, and there are two tests with 'same' name 'testToLonglong' and 'testToLongLong'.

Thanks @nsjian and @jatin-bhateja .

I need a sponsor.

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

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

From jiefu at openjdk.java.net  Mon Sep 27 10:00:11 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Mon, 27 Sep 2021 10:00:11 GMT
Subject: [vectorIntrinsics+mask] Integrated: 8274331: [Vector API] Build
 failure on MacOS after JDK-8273949
In-Reply-To: 
References: 
Message-ID: <2xYqNF-YDfu7C7HRp15Jlw3ewoRV0o3VBqkYHUcYoZU=.a7643dac-efd0-4518-b494-5ea94f4944cf@github.com>

On Sun, 26 Sep 2021 15:39:27 GMT, Jie Fu  wrote:

> Hi all,
> 
> Build failure was observed on our MacOS platform after JDK-8273949.
> 
> It seems to be caused by a typo in the jmh test [1] since after this fix the build is fine.
> 
> I'm still not clear how this can happen.
> But it would be better to fix this typo.
> 
> Thanks.
> Best regards,
> Jie
> 
> [1] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics%2Bmask/test/micro/org/openjdk/bench/jdk/incubator/vector/MaskQueryOperationsBenchmark.java#L169

This pull request has now been integrated.

Changeset: 9ba59cc3
Author:    Jie Fu 
Committer: Ningsheng Jian 
URL:       https://git.openjdk.java.net/panama-vector/commit/9ba59cc36e87cf2eeeac94f98f4a4b0854a8fc59
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8274331: [Vector API] Build failure on MacOS after JDK-8273949

Reviewed-by: njian, jbhateja

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

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

From eliu at openjdk.java.net  Mon Sep 27 10:13:33 2021
From: eliu at openjdk.java.net (Eric Liu)
Date: Mon, 27 Sep 2021 10:13:33 GMT
Subject: [vectorIntrinsics+mask] RFR: 8274342: AArch64: [vector] AArch64 SVE
 backend code cleanup
Message-ID: 

This patch refactors AArch64 SVE backend codes with merging some rules
into C2_MacroAssembler. As the input of VectorMaskOp changed after
JDK-8273949, this patch fixes the backend to support using predicate
register as input.

The size of libjvm.so reduces about 100KB after this patch.

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

Commit messages:
 - 8274342: AArch64: [vector] AArch64 SVE backend code cleanup

Changes: https://git.openjdk.java.net/panama-vector/pull/134/files
 Webrev: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=134&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274342
  Stats: 1382 lines in 6 files changed: 140 ins; 734 del; 508 mod
  Patch: https://git.openjdk.java.net/panama-vector/pull/134.diff
  Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/134/head:pull/134

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

From njian at openjdk.java.net  Mon Sep 27 10:27:48 2021
From: njian at openjdk.java.net (Ningsheng Jian)
Date: Mon, 27 Sep 2021 10:27:48 GMT
Subject: [vectorIntrinsics+mask] RFR: 8274342: AArch64: [vector] AArch64
 SVE backend code cleanup
In-Reply-To: 
References: 
Message-ID: <5ySxzIyfjXf0YXtDZfbwhuK_sfPrB_qNsJhSI6xlA-8=.9acecefe-5618-4410-a530-589987bd7366@github.com>

On Mon, 27 Sep 2021 09:59:49 GMT, Eric Liu  wrote:

> This patch refactors AArch64 SVE backend codes with merging some rules
> into C2_MacroAssembler. As the input of VectorMaskOp changed after
> JDK-8273949, this patch fixes the backend to support using predicate
> register as input.
> 
> The size of libjvm.so reduces about 100KB after this patch.

LGTM.

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

Marked as reviewed by njian (Committer).

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

From duncan.gittins at gmail.com  Mon Sep 27 15:45:53 2021
From: duncan.gittins at gmail.com (Duncan Gittins)
Date: Mon, 27 Sep 2021 16:45:53 +0100
Subject: Win32 / OLE issues
In-Reply-To: <6ca6d6ea-e21d-4ff6-da5b-b16eb5779146@gmail.com>
References: <6ca6d6ea-e21d-4ff6-da5b-b16eb5779146@gmail.com>
Message-ID: 

The jextract parameters which generate the broken Windows OLE API code I
outlined below is:

    jextract -source -lole32 -t duncan.win.ole -d source\duncan.win\java
headers\Ole32.h

where headers\Ole32.h contains:

    #include 

A temporary workaround for this jextract issue is to edit
FunctionalInterfaceBuilder.java / emitFunctionalFactoryForPointer() to
insert the (Addressable) casts for MemoryAddress parameters:

---
a/src/jdk.incubator.jextract/share/classes/jdk/internal/jextract/impl/FunctionalInterfaceBuilder.java
+++
b/src/jdk.incubator.jextract/share/classes/jdk/internal/jextract/impl/FunctionalInterfaceBuilder.java
@@ -123,7 +123,7 @@ public class FunctionalInterfaceBuilder extends
ClassSourceBuilder {
             append(mhConstant.accessExpression() +
".invokeExact((Addressable)addr");
             if (fiType.parameterCount() > 0) {
                 String params = IntStream.range(0, fiType.parameterCount())
-                        .mapToObj(i -> "x" + i)
+                        .mapToObj(i ->
(fiType.parameterType(i).getName().endsWith(".MemoryAddress") ?
"(Addressable)":"")+"x" + i)
                         .collect(Collectors.joining(", "));
                 append(", " + params);
             }

this fixes the ofAddress callbacks, for example see IPersistFileVtbl.java:

   public interface Load {
        ....
        static Load ofAddress(MemoryAddress addr) {
            return (jdk.incubator.foreign.MemoryAddress x0,
jdk.incubator.foreign.MemoryAddress x1, int x2) -> {
                try {
// WAS:          return
(int)IPersistFileVtbl.Load$MH.invokeExact((Addressable)addr, x0, x1, x2);
                      return
(int)IPersistFileVtbl.Load$MH.invokeExact((Addressable)addr,
(Addressable)x0, (Addressable)x1, x2);
                } catch (Throwable ex$) {
                    throw new AssertionError("should not reach here", ex$);
                }
            };
        }

Kind regards

Duncan


On Fri, 24 Sept 2021 at 16:36, Duncan Gittins 
wrote:

> I've pulled latest panama-foreign which has the changes outlined in
>
>     https://inside.java/2021/09/16/finalizing-the-foreign-apis/
>
> I've a few problems to resolve to match up, one is related to jextract
> which generates interfaces for Windows OLE APIs.  The invokeExact params
> are missing some (Addressable) casts (I think?) eg this is IUnknown Release:
>
>     public interface Release {
>
>         int apply(jdk.incubator.foreign.MemoryAddress x0);
>         static CLinker.UpcallStub allocate(Release fi) {
>             return RuntimeHelper.upcallStub(Release.class, fi,
> IUnknownVtbl.Release$FUNC, "(Ljdk/incubator/foreign/MemoryAddress;)I");
>         }
>         static CLinker.UpcallStub allocate(Release fi, ResourceScope
> scope) {
>             return RuntimeHelper.upcallStub(Release.class, fi,
> IUnknownVtbl.Release$FUNC, "(Ljdk/incubator/foreign/MemoryAddress;)I",
> scope);
>         }
>         static Release ofAddress(MemoryAddress addr) {
>             return (jdk.incubator.foreign.MemoryAddress x0) -> {
>                 try {
>                     return
> (int)IUnknownVtbl.Release$MH.invokeExact((Addressable)addr, x0);
>                 } catch (Throwable ex$) {
>                     throw new AssertionError("should not reach here", ex$);
>                 }
>             };
>         }
>     }
>
> Stack traces show
>
>      Caused by: java.lang.invoke.WrongMethodTypeException: expected
> (Addressable,Addressable)int but found (Addressable,MemoryAddress)int
>
> Kind regards
>
> Duncan
>
>
>

From paul.sandoz at oracle.com  Mon Sep 27 17:19:21 2021
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 27 Sep 2021 17:19:21 +0000
Subject: Result: New Panama Committer: Jie Fu
Message-ID: <276D4519-94E9-46C8-8F0C-338906818095@oracle.com>

Voting for Jie Fu [1] closed on the 23rd September 2021.

Yes: 6
Veto: 0
Abstain: 0

According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination.

Paul.

[1] https://mail.openjdk.java.net/pipermail/panama-dev/2021-September/014910.html

From eliu at openjdk.java.net  Tue Sep 28 08:48:17 2021
From: eliu at openjdk.java.net (Eric Liu)
Date: Tue, 28 Sep 2021 08:48:17 GMT
Subject: [vectorIntrinsics+mask] Integrated: 8274342: AArch64: [vector]
 AArch64 SVE backend code cleanup
In-Reply-To: 
References: 
Message-ID: 

On Mon, 27 Sep 2021 09:59:49 GMT, Eric Liu  wrote:

> This patch refactors AArch64 SVE backend codes with merging some rules
> into C2_MacroAssembler. As the input of VectorMaskOp changed after
> JDK-8273949, this patch fixes the backend to support using predicate
> register as input.
> 
> The size of libjvm.so reduces about 100KB after this patch.

This pull request has now been integrated.

Changeset: 17b43095
Author:    Eric Liu 
URL:       https://git.openjdk.java.net/panama-vector/commit/17b430956541ddc07f0d549ca98ac0e65f0b2a81
Stats:     1382 lines in 6 files changed: 140 ins; 734 del; 508 mod

8274342: AArch64: [vector] AArch64 SVE backend code cleanup

Reviewed-by: njian

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

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

From jboes at openjdk.java.net  Tue Sep 28 13:08:55 2021
From: jboes at openjdk.java.net (Julia Boes)
Date: Tue, 28 Sep 2021 13:08:55 GMT
Subject: [foreign-memaccess+abi] RFR: 8274157: java.foreign: Add method
 MemorySegment::isOverlapping
Message-ID: 

This change adds a method to the MemorySegment API that detects if two segments are overlapping.

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

Commit messages:
 - initial change

Changes: https://git.openjdk.java.net/panama-foreign/pull/585/files
 Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=585&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274157
  Stats: 176 lines in 4 files changed: 171 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/panama-foreign/pull/585.diff
  Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/585/head:pull/585

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

From mcimadamore at openjdk.java.net  Tue Sep 28 14:20:05 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 28 Sep 2021 14:20:05 GMT
Subject: [foreign-memaccess+abi] RFR: 8274157: java.foreign: Add method
 MemorySegment::isOverlapping
In-Reply-To: 
References: 
Message-ID: <9BnTm9tEnxW6I1ZdUFmE2NFcN77AU1Tf1exvXbWrAZk=.57b2d243-01d7-4713-8996-04af9442f176@github.com>

On Tue, 28 Sep 2021 12:59:19 GMT, Julia Boes  wrote:

> This change adds a method to the MemorySegment API that detects if two segments are overlapping.

Good work. As I was going through the changes, it occurred to me that another way to stack this API is to return the slice that is common to both segments (or `null` if none exist). I don't know which version would be more interesting; any comment on this @leerho?

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

> 322: 
> 323:     /**
> 324:      * Returns true if this segment overlaps the {@code other} segment.

We should probably explain what "overlaps" mean. E.g. "Two segments S1 and S2 are said to overlap if it is possible to find at least two slices L1 (from S1) and L2 (from S2) such that L1 and L2 are backed by the same memory region".

This description is vague enough (as it is defined in terms of slicing). At the same time it makes it clear as to why an heap segment can never overlap with an heap segment (and vice-versa).

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

> 324:      * Returns true if this segment overlaps the {@code other} segment.
> 325:      *
> 326:      * If the two segments are not either both backed by native or heap memory, {@code false} is returned.

If you like the above suggestion, I'd replace this para with:

"As such, it is never possible for a native (javadoc link) segment to overlap with an heap segment".

We can drop the sentence about offset and sizes - as that seems more of an impl detail? But perhaps, if you want to explain more, a couple of examples would be better? E.g.


MemorySegment s1 = MemorySegment.allocateNative(100, scope);
MemorySegment s2 = MemorySegment.allocateNative(100, scope);
s1.overlap(s2); // false
MemorySegment s3 = s1.slice(0, 50);
s1.overlap(slice); // true
s2.overlap(slice); // false

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

> 328:      *
> 329:      * @param other the segment to be tested for an overlap with this segment.
> 330:      * @return {@code true} if this segment overlaps the other segment.

Suggestion:

     * @return {@code true} if this segment overlaps with the other segment.

src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java line 257:

> 255: 
> 256:     @Override
> 257:     public boolean isOverlapping(MemorySegment other) {

maybe add final, so that other segment subclasses cannot accidentally override?

src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java line 260:

> 258:         AbstractMemorySegmentImpl that = (AbstractMemorySegmentImpl)Objects.requireNonNull(other);
> 259:         if (base() == that.base()) {  // both are either native or heap
> 260:             this.checkAccess(0, this.length, true);

I don't think `checkAccess` is needed? That operation is typically called when accessing a segment to dereference, to verify that:
* the accessed location is within the bounds of the segment
* the access mode (read/write) is compatible with the segment
Here, you don't do dereference, so these checks are not necessary, `checkValidState()` is what you want.

test/jdk/java/foreign/TestSegmentsOverlap.java line 42:

> 40: 
> 41:     @Test
> 42:     public void testNativeBasic() {

there are two kinds of native segments (or even three): segments created via `MemorySegment::allocateNative` and segments created via `MemorySegment.mapFile`. Perhaps it could be worth testing both (I believe `TestByteBuffer` has an example of a mapped segment).

Additionally, we have native segments which come from a direct buffer:


ByteBuffer b = ByteBuffer.allocateDirect(10);
MemorySegment s = MemorySegment.ofBuffer(b); // native segment!

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

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

From mcimadamore at openjdk.java.net  Tue Sep 28 18:18:27 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 28 Sep 2021 18:18:27 GMT
Subject: [foreign-memaccess+abi] RFR: Make Addressable sealed again
Message-ID: 

Following the API refresh, I realized that making `Addressable` non-sealed was perhaps a step too far, at least for the time being. It forces a `scope()` accessor on the interface, which in turns pollutes the `MemoryAddress` interface (since a memory address has no scope).
While the API, as currently defined is sound, I'd prefer to make things tighter for now, as I realized that the need to define custom `Addressable` is perhaps limited. For instance, one place I thought they would have been useful was to model structs - but thinking more, a struct is probably backed by a segment anyway - and the segment is addressable. So, assuming the struct exposes a segment accessor, we still have ways to pass it around w/o necessarily having it implement the `Addressable` interface directly.

In the implementation we do have a new internal `Scoped` interface, which is used to keep all by-reference parameters alive by the linker. Basically, this interface re-adds the scope accessor which has been removed from the public API.

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

Commit messages:
 - Add missing copyright
 - Tweak Addressable to become sealed

Changes: https://git.openjdk.java.net/panama-foreign/pull/586/files
 Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=586&range=00
  Stats: 85 lines in 13 files changed: 39 ins; 29 del; 17 mod
  Patch: https://git.openjdk.java.net/panama-foreign/pull/586.diff
  Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/586/head:pull/586

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

From jvernee at openjdk.java.net  Tue Sep 28 18:23:11 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Tue, 28 Sep 2021 18:23:11 GMT
Subject: [foreign-memaccess+abi] RFR: Make Addressable sealed again
In-Reply-To: 
References: 
Message-ID: 

On Tue, 28 Sep 2021 18:11:56 GMT, Maurizio Cimadamore  wrote:

> Following the API refresh, I realized that making `Addressable` non-sealed was perhaps a step too far, at least for the time being. It forces a `scope()` accessor on the interface, which in turns pollutes the `MemoryAddress` interface (since a memory address has no scope).
> While the API, as currently defined is sound, I'd prefer to make things tighter for now, as I realized that the need to define custom `Addressable` is perhaps limited. For instance, one place I thought they would have been useful was to model structs - but thinking more, a struct is probably backed by a segment anyway - and the segment is addressable. So, assuming the struct exposes a segment accessor, we still have ways to pass it around w/o necessarily having it implement the `Addressable` interface directly.
> 
> In the implementation we do have a new internal `Scoped` interface, which is used to keep all by-reference parameters alive by the linker. Basically, this interface re-adds the scope accessor which has been removed from the public API.

Marked as reviewed by jvernee (Committer).

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/Addressable.java line 53:

> 51:      * @return The memory address associated with this addressable.
> 52:      * @throws IllegalStateException if the scope associated with this addressable has been closed, or if access occurs from
> 53:      * a thread other than the thread owning that scope.

Assuming that this method can still throw an exception for the reason described here, is it okay for API methods to throw unspecified exceptions?

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

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

From sviswanathan at openjdk.java.net  Tue Sep 28 19:59:45 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Tue, 28 Sep 2021 19:59:45 GMT
Subject: [vectorIntrinsics] RFR: Merge panama-vector:vectorIntrinsics+mask
Message-ID: 

Merging final vectorIntrinsics+mask changes into vectorIntrinsics.
It is a clean merge without any conflicts.
Please approve.

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

Commit messages:
 - 8274342: AArch64: [vector] AArch64 SVE backend code cleanup
 - 8274331: [Vector API] Build failure on MacOS after JDK-8273949
 - Merge panama-vector:vectorIntrinsics
 - 8274236: Cleanups related to X86 masking support.
 - 8273949: Intrinsic creation for VectorMask.toLong operation.
 - 8273264: AArch64: [vector] Add missing rules for VectorMaskCast
 - 8273406: Optimize various masked vector operations for AVX512 target.
 - 8273367: [Vector API] Fix a regression of rearrange intrinsic after JDK-8272479
 - 8273371: [Vector API] Crash in Assembler::evpermd when code-gen for masked rearrange operation on AVX512
 - 8273205: [Vector API] Crash in C2_MacroAssembler::vprotate_var after JDK-8271366
 - ... and 24 more: https://git.openjdk.java.net/panama-vector/compare/98a7a541...17b43095

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.java.net/panama-vector/pull/135/files
  Stats: 21686 lines in 101 files changed: 15978 ins; 2075 del; 3633 mod
  Patch: https://git.openjdk.java.net/panama-vector/pull/135.diff
  Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/135/head:pull/135

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

From mcimadamore at openjdk.java.net  Tue Sep 28 20:11:10 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 28 Sep 2021 20:11:10 GMT
Subject: [foreign-memaccess+abi] RFR: Make Addressable sealed again
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 28 Sep 2021 18:18:42 GMT, Jorn Vernee  wrote:

>> Following the API refresh, I realized that making `Addressable` non-sealed was perhaps a step too far, at least for the time being. It forces a `scope()` accessor on the interface, which in turns pollutes the `MemoryAddress` interface (since a memory address has no scope).
>> While the API, as currently defined is sound, I'd prefer to make things tighter for now, as I realized that the need to define custom `Addressable` is perhaps limited. For instance, one place I thought they would have been useful was to model structs - but thinking more, a struct is probably backed by a segment anyway - and the segment is addressable. So, assuming the struct exposes a segment accessor, we still have ways to pass it around w/o necessarily having it implement the `Addressable` interface directly.
>> 
>> In the implementation we do have a new internal `Scoped` interface, which is used to keep all by-reference parameters alive by the linker. Basically, this interface re-adds the scope accessor which has been removed from the public API.
>
> src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/Addressable.java line 53:
> 
>> 51:      * @return The memory address associated with this addressable.
>> 52:      * @throws IllegalStateException if the scope associated with this addressable has been closed, or if access occurs from
>> 53:      * a thread other than the thread owning that scope.
> 
> Assuming that this method can still throw an exception for the reason described here, is it okay for API methods to throw unspecified exceptions?

for runtime exception, I think that's fine. That's kind of the case with `UnsupportedOperationException`. We might add some text to the documentation, but in general I think that's within bounds.

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

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

From github.com+12941506+leerho at openjdk.java.net  Tue Sep 28 22:30:03 2021
From: github.com+12941506+leerho at openjdk.java.net (Lee Rhodes)
Date: Tue, 28 Sep 2021 22:30:03 GMT
Subject: [foreign-memaccess+abi] RFR: 8274157: java.foreign: Add method
 MemorySegment::isOverlapping
In-Reply-To: <9BnTm9tEnxW6I1ZdUFmE2NFcN77AU1Tf1exvXbWrAZk=.57b2d243-01d7-4713-8996-04af9442f176@github.com>
References: 
 <9BnTm9tEnxW6I1ZdUFmE2NFcN77AU1Tf1exvXbWrAZk=.57b2d243-01d7-4713-8996-04af9442f176@github.com>
Message-ID: 

On Tue, 28 Sep 2021 14:01:59 GMT, Maurizio Cimadamore  wrote:

>> This change adds a method to the MemorySegment API that detects if two segments are overlapping.
>
> src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemorySegment.java line 324:
> 
>> 322: 
>> 323:     /**
>> 324:      * Returns true if this segment overlaps the {@code other} segment.
> 
> We should probably explain what "overlaps" mean. E.g. "Two segments S1 and S2 are said to overlap if it is possible to find at least two slices L1 (from S1) and L2 (from S2) such that L1 and L2 are backed by the same memory region".
> 
> This description is vague enough (as it is defined in terms of slicing). At the same time it makes it clear as to why an heap segment can never overlap with an heap segment (and vice-versa).

Returning the slice of the overlapped region is an interesting idea.

I was trying to think if this would be useful in computing intersections between A and B, but alas, the circumstances where this would be true are highly specialized. In the general case, if the returned slice is != null, then the lower bound of the size of the intersection is the size of the slice.  But if it is null, we know absolutely nothing.  So for intersections anyway, this is not too useful.  

The use-case I originally had in mind was copying non-primitive elements from A into B.  To do this efficiently, without requiring extra copying space requires that we know if there is an overlap and knowing whether A_lo <= B_lo,  or B_lo < A_lo (by address),  or if A is a subset of B.  Knowing that there exists an overlap is a big help, but to answer the rest we would need to obtain the start and end addresses of both A and B.

In my mind, what would be more useful than returning the overlapping slice, would be to return sufficient information so that an efficient copy from A to B could proceed immediately.  For example, returning a small array of 4 addresses: {A_lo, A_hi, B_lo, B_hi}.  This provides all the info we need for all different types of copies and moves.

Cheers,
Lee.

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

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

From github.com+12941506+leerho at openjdk.java.net  Tue Sep 28 23:10:24 2021
From: github.com+12941506+leerho at openjdk.java.net (Lee Rhodes)
Date: Tue, 28 Sep 2021 23:10:24 GMT
Subject: [foreign-memaccess+abi] RFR: 8274157: java.foreign: Add method
 MemorySegment::isOverlapping
In-Reply-To: 
References: 
 <9BnTm9tEnxW6I1ZdUFmE2NFcN77AU1Tf1exvXbWrAZk=.57b2d243-01d7-4713-8996-04af9442f176@github.com>
 
Message-ID: 

On Tue, 28 Sep 2021 22:26:20 GMT, Lee Rhodes  wrote:

>> src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemorySegment.java line 324:
>> 
>>> 322: 
>>> 323:     /**
>>> 324:      * Returns true if this segment overlaps the {@code other} segment.
>> 
>> We should probably explain what "overlaps" mean. E.g. "Two segments S1 and S2 are said to overlap if it is possible to find at least two slices L1 (from S1) and L2 (from S2) such that L1 and L2 are backed by the same memory region".
>> 
>> This description is vague enough (as it is defined in terms of slicing). At the same time it makes it clear as to why an heap segment can never overlap with an heap segment (and vice-versa).
>
> Returning the slice of the overlapped region is an interesting idea.
> 
> I was trying to think if this would be useful in computing intersections between A and B, but alas, the circumstances where this would be true are highly specialized. In the general case, if the returned slice is != null, then the lower bound of the size of the intersection is the size of the slice.  But if it is null, we know absolutely nothing.  So for intersections anyway, this is not too useful.  
> 
> The use-case I originally had in mind was copying non-primitive elements from A into B.  To do this efficiently, without requiring extra copying space requires that we know if there is an overlap and knowing whether A_lo <= B_lo,  or B_lo < A_lo (by address),  or if A is a subset of B.  Knowing that there exists an overlap is a big help, but to answer the rest we would need to obtain the start and end addresses of both A and B.
> 
> In my mind, what would be more useful than returning the overlapping slice, would be to return sufficient information so that an efficient copy from A to B could proceed immediately.  For example, returning a small array of 4 addresses: {A_lo, A_hi, B_lo, B_hi}.  This provides all the info we need for all different types of copies and moves.
> 
> Cheers,
> Lee.

If you are reluctant to return actual addresses, you could return the 4 values as relative offsets where either A_lo == 0, or B_lo == 0, or A_lo == B_lo == 0.

I thought I saw in one of your refactorings where you eliminated both MemoryAccess and MemoryCopy, a new general purpose copy(seg A, LayoutA, offsetA, seg B, LayoutB, offsetB, length) or something like that (I can't find it at this moment).  If the layouts can describe repeating elements of any size, doesn't this solve the copy problem and possibly eliminate the need for the isOverlapping() method?

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

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

From mcimadamore at openjdk.java.net  Tue Sep 28 23:10:24 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 28 Sep 2021 23:10:24 GMT
Subject: [foreign-memaccess+abi] RFR: 8274157: java.foreign: Add method
 MemorySegment::isOverlapping
In-Reply-To: 
References: 
 <9BnTm9tEnxW6I1ZdUFmE2NFcN77AU1Tf1exvXbWrAZk=.57b2d243-01d7-4713-8996-04af9442f176@github.com>
 
 
Message-ID: 

On Tue, 28 Sep 2021 23:07:52 GMT, Lee Rhodes  wrote:

>> Returning the slice of the overlapped region is an interesting idea.
>> 
>> I was trying to think if this would be useful in computing intersections between A and B, but alas, the circumstances where this would be true are highly specialized. In the general case, if the returned slice is != null, then the lower bound of the size of the intersection is the size of the slice.  But if it is null, we know absolutely nothing.  So for intersections anyway, this is not too useful.  
>> 
>> The use-case I originally had in mind was copying non-primitive elements from A into B.  To do this efficiently, without requiring extra copying space requires that we know if there is an overlap and knowing whether A_lo <= B_lo,  or B_lo < A_lo (by address),  or if A is a subset of B.  Knowing that there exists an overlap is a big help, but to answer the rest we would need to obtain the start and end addresses of both A and B.
>> 
>> In my mind, what would be more useful than returning the overlapping slice, would be to return sufficient information so that an efficient copy from A to B could proceed immediately.  For example, returning a small array of 4 addresses: {A_lo, A_hi, B_lo, B_hi}.  This provides all the info we need for all different types of copies and moves.
>> 
>> Cheers,
>> Lee.
>
> If you are reluctant to return actual addresses, you could return the 4 values as relative offsets where either A_lo == 0, or B_lo == 0, or A_lo == B_lo == 0.
> 
> I thought I saw in one of your refactorings where you eliminated both MemoryAccess and MemoryCopy, a new general purpose copy(seg A, LayoutA, offsetA, seg B, LayoutB, offsetB, length) or something like that (I can't find it at this moment).  If the layouts can describe repeating elements of any size, doesn't this solve the copy problem and possibly eliminate the need for the isOverlapping() method?

Not sure I understand correctly - but it sounds almost as if you are interested in knowing the two, maximal, non-overlapping slices of A and B?

It would help to have an example with some numeric bounds, to make sure we're talking about the same things.

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

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

From mcimadamore at openjdk.java.net  Tue Sep 28 23:26:48 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 28 Sep 2021 23:26:48 GMT
Subject: [foreign-memaccess+abi] RFR: 8274157: java.foreign: Add method
 MemorySegment::isOverlapping
In-Reply-To: 
References: 
 <9BnTm9tEnxW6I1ZdUFmE2NFcN77AU1Tf1exvXbWrAZk=.57b2d243-01d7-4713-8996-04af9442f176@github.com>
 
 
 
Message-ID: <54p0JTuk4MH1GnQlHs0_--NcMulB6BOPU4V8RnAe7Qk=.7183c47e-bbb3-4eeb-84b8-695667cb5dda@github.com>

On Tue, 28 Sep 2021 23:08:13 GMT, Maurizio Cimadamore  wrote:

>> If you are reluctant to return actual addresses, you could return the 4 values as relative offsets where either A_lo == 0, or B_lo == 0, or A_lo == B_lo == 0.
>> 
>> I thought I saw in one of your refactorings where you eliminated both MemoryAccess and MemoryCopy, a new general purpose copy(seg A, LayoutA, offsetA, seg B, LayoutB, offsetB, length) or something like that (I can't find it at this moment).  If the layouts can describe repeating elements of any size, doesn't this solve the copy problem and possibly eliminate the need for the isOverlapping() method?
>
> Not sure I understand correctly - but it sounds almost as if you are interested in knowing the two, maximal, non-overlapping slices of A and B?
> 
> It would help to have an example with some numeric bounds, to make sure we're talking about the same things.

> If you are reluctant to return actual addresses, you could return the 4 values as relative offsets where either A_lo == 0, or B_lo == 0, or A_lo == B_lo == 0.
> 
> I thought I saw in one of your refactorings where you eliminated both MemoryAccess and MemoryCopy, a new general purpose copy(seg A, LayoutA, offsetA, seg B, LayoutB, offsetB, length) or something like that (I can't find it at this moment). If the layouts can describe repeating elements of any size, doesn't this solve the copy problem and possibly eliminate the need for the isOverlapping() method?

The MemorySegment::copy you are referring to takes a pair of ValueLayouts, which cannot be arbitrarily big. In fact, not even the underlying `Unsafe.copyMemorySwap` can work with arbitrary element sizes.

That said, I'm still trying to understand what exactly you want to do; if you want to copy elements of N bytes from a slice to another - why isn't copying bytes enough (since the bulk copy already can deal with overlapping addresses)? Do you want to "swap" entire structs as part of the copy (that would be inefficient!).

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

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

From mcimadamore at openjdk.java.net  Tue Sep 28 23:38:58 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 28 Sep 2021 23:38:58 GMT
Subject: [foreign-memaccess+abi] RFR: 8274157: java.foreign: Add method
 MemorySegment::isOverlapping
In-Reply-To: <54p0JTuk4MH1GnQlHs0_--NcMulB6BOPU4V8RnAe7Qk=.7183c47e-bbb3-4eeb-84b8-695667cb5dda@github.com>
References: 
 <9BnTm9tEnxW6I1ZdUFmE2NFcN77AU1Tf1exvXbWrAZk=.57b2d243-01d7-4713-8996-04af9442f176@github.com>
 
 
 
 <54p0JTuk4MH1GnQlHs0_--NcMulB6BOPU4V8RnAe7Qk=.7183c47e-bbb3-4eeb-84b8-695667cb5dda@github.com>
Message-ID: 

On Tue, 28 Sep 2021 23:24:19 GMT, Maurizio Cimadamore  wrote:

>> Not sure I understand correctly - but it sounds almost as if you are interested in knowing the two, maximal, non-overlapping slices of A and B?
>> 
>> It would help to have an example with some numeric bounds, to make sure we're talking about the same things.
>
>> If you are reluctant to return actual addresses, you could return the 4 values as relative offsets where either A_lo == 0, or B_lo == 0, or A_lo == B_lo == 0.
>> 
>> I thought I saw in one of your refactorings where you eliminated both MemoryAccess and MemoryCopy, a new general purpose copy(seg A, LayoutA, offsetA, seg B, LayoutB, offsetB, length) or something like that (I can't find it at this moment). If the layouts can describe repeating elements of any size, doesn't this solve the copy problem and possibly eliminate the need for the isOverlapping() method?
> 
> The MemorySegment::copy you are referring to takes a pair of ValueLayouts, which cannot be arbitrarily big. In fact, not even the underlying `Unsafe.copyMemorySwap` can work with arbitrary element sizes.
> 
> That said, I'm still trying to understand what exactly you want to do; if you want to copy elements of N bytes from a slice to another - why isn't copying bytes enough (since the bulk copy already can deal with overlapping addresses)? Do you want to "swap" entire structs as part of the copy (that would be inefficient!).

Reading from older emails - I'm starting to have doubts about whether the overlap predicate in this PR does anything for you. You want to protect against the case whether two segments are mapping of _the same file_, but in different address spaces. So there might not even be an address overlap. This is what the spec is calling out, I think: since there's no address overlap, Unsafe doesn't know how to protect against that. But that is a much lower level kind of overlap, which has nothing to do with the one provided here - do you agree? If the address space is the same - e.g. plain segments allocated with `malloc`, what bulk copy does is already enough.

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

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

From mcimadamore at openjdk.java.net  Wed Sep 29 00:09:29 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 29 Sep 2021 00:09:29 GMT
Subject: [foreign-memaccess+abi] RFR: 8274157: java.foreign: Add method
 MemorySegment::isOverlapping
In-Reply-To: 
References: 
 <9BnTm9tEnxW6I1ZdUFmE2NFcN77AU1Tf1exvXbWrAZk=.57b2d243-01d7-4713-8996-04af9442f176@github.com>
 
 
 
 <54p0JTuk4MH1GnQlHs0_--NcMulB6BOPU4V8RnAe7Qk=.7183c47e-bbb3-4eeb-84b8-695667cb5dda@github.com>
 
Message-ID: <7PJKfdkEjVf1uyLcjHSsT0FrboJL_7R6jzIbeJXXW-4=.6ac31c53-2429-43bd-b503-d15c07a2d3f6@github.com>

On Tue, 28 Sep 2021 23:32:54 GMT, Maurizio Cimadamore  wrote:

>>> If you are reluctant to return actual addresses, you could return the 4 values as relative offsets where either A_lo == 0, or B_lo == 0, or A_lo == B_lo == 0.
>>> 
>>> I thought I saw in one of your refactorings where you eliminated both MemoryAccess and MemoryCopy, a new general purpose copy(seg A, LayoutA, offsetA, seg B, LayoutB, offsetB, length) or something like that (I can't find it at this moment). If the layouts can describe repeating elements of any size, doesn't this solve the copy problem and possibly eliminate the need for the isOverlapping() method?
>> 
>> The MemorySegment::copy you are referring to takes a pair of ValueLayouts, which cannot be arbitrarily big. In fact, not even the underlying `Unsafe.copyMemorySwap` can work with arbitrary element sizes.
>> 
>> That said, I'm still trying to understand what exactly you want to do; if you want to copy elements of N bytes from a slice to another - why isn't copying bytes enough (since the bulk copy already can deal with overlapping addresses)? Do you want to "swap" entire structs as part of the copy (that would be inefficient!).
>
> Reading from older emails - I'm starting to have doubts about whether the overlap predicate in this PR does anything for you. You want to protect against the case whether two segments are mapping of _the same file_, but in different address spaces. So there might not even be an address overlap. This is what the spec is calling out, I think: since there's no address overlap, Unsafe doesn't know how to protect against that. But that is a much lower level kind of overlap, which has nothing to do with the one provided here - do you agree? If the address space is the same - e.g. plain segments allocated with `malloc`, what bulk copy does is already enough.

Ok, I guess I now figured out what you mean; you basically want to implement something that has same correctness guarantees as `System.arraycopy` which works on _arbitrary_ element sizes, not just 8/16/32/64 byte sizes. The copy method we have is good (in the sense that you can also copy by bytes, or by int/long words), but if you also need multi-bit swap (where multi > 64) then you are out of luck (but I'm curious about this use case of extreme swappiness :-) ).

It is possible, in the future, that with the help of the vector API, we might be able to indeed lift the restriction, and provide a bulk copy (written in Java :-) ) which works on elements bigger than 64 bits. In the meantime, we have two options:

* you "take the hit" when dealing with element sizes > 64bit (meaning in these case you will need extra buffer)
* we provide enough primitives which allow you (or others) to implement other copy routines which support similar guarantees as `System.arraycopy`

Another issue: note that the `MemoryAddress::segmentOffset` has also gone in the API refresh, and I believe your plan was probably to rely on it to do the computations; we could add it back if that was really an issue. Or we could come up with similar methods which work on segments instead (e.g. return the start/end offset of a segment into another segment - which combined with an overlapping slice region would probably do what you need to do).

I don't know how common this issue is in your API, so I can't judge. The general feeling I get is that an overlapping predicate without some other ways to compute offsets between slices is not very useful - and so, in that case it would be better to do nothing.

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

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

From eliu at openjdk.java.net  Wed Sep 29 01:40:19 2021
From: eliu at openjdk.java.net (Eric Liu)
Date: Wed, 29 Sep 2021 01:40:19 GMT
Subject: [vectorIntrinsics] RFR: Merge panama-vector:vectorIntrinsics+mask
In-Reply-To: 
References: 
Message-ID: <4zRiP7IeDT9ZmNBXJtDyx_OGrg9fc3pOke4Cw4b-n-0=.f0de9ed3-807f-4501-a460-c63757b6a6f7@github.com>

On Tue, 28 Sep 2021 19:52:43 GMT, Sandhya Viswanathan  wrote:

> Merging final vectorIntrinsics+mask changes into vectorIntrinsics.
> It is a clean merge without any conflicts.
> Please approve.

Marked as reviewed by eliu (Committer).

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

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

From jbhateja at openjdk.java.net  Wed Sep 29 01:49:44 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Wed, 29 Sep 2021 01:49:44 GMT
Subject: [vectorIntrinsics] RFR: Merge panama-vector:vectorIntrinsics+mask
In-Reply-To: 
References: 
Message-ID: 

On Tue, 28 Sep 2021 19:52:43 GMT, Sandhya Viswanathan  wrote:

> Merging final vectorIntrinsics+mask changes into vectorIntrinsics.
> It is a clean merge without any conflicts.
> Please approve.

Marked as reviewed by jbhateja (Committer).

Thanks @sviswa7

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

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

From github.com+12941506+leerho at openjdk.java.net  Wed Sep 29 02:07:44 2021
From: github.com+12941506+leerho at openjdk.java.net (Lee Rhodes)
Date: Wed, 29 Sep 2021 02:07:44 GMT
Subject: [foreign-memaccess+abi] RFR: 8274157: java.foreign: Add method
 MemorySegment::isOverlapping
In-Reply-To: 
References: 
Message-ID: <3vnXb16RqbZCWskCDWnPYWk8jlod8uMYCFrsGXkX41w=.fc672ae3-86dc-4837-a6bb-00479ec0fd45@github.com>

On Tue, 28 Sep 2021 12:59:19 GMT, Julia Boes  wrote:

> This change adds a method to the MemorySegment API that detects if two segments are overlapping.

I think you understand. But I haven't lost hope, that there aren't some
simple primitives that would allow copying of multiple structs from one
segment to another where a struct could be an arbitrary size in bytes (not
bits).

Imagine these segments are quite large ~ gigabytes.  Forcing me to allocate
a buffer segment of that size and perform redundant copy operations just
because I can't figure out whether these segments overlap in memory and
which segment precedes the other is a huge penalty.

I didn't realize you had already tossed the MemoryAddress:: segmentOffset. This
operation is crucial for this task.

The minimal primitive operations required would be

   - boolean Segment.isOverlapping(Segment); //if segments are in different
   spaces (heap, off-heap) the result is obviously false.
   - long startingAddress(Segment);  //this has to work whether it is
   on-heap or off-heap.

You may consider the underlying copy mechanics to do this to be
inefficient, perhaps, but it would still be orders-of-magnitude more
efficient than having to create a huge segment buffer and do all the
redundant copies.

I will construct a simulated java example using these primitives, just to
be clear. :)

Cheers,
Lee.

On Tue, Sep 28, 2021 at 5:04 PM Maurizio Cimadamore <
***@***.***> wrote:

> ***@***.**** commented on this pull request.
> ------------------------------
>
> In
> src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemorySegment.java
> 
> :
>
> > @@ -320,6 +320,20 @@ default MemorySegment asSlice(long offset) {
>       */
>      boolean isMapped();
>
> +    /**
> +     * Returns true if this segment overlaps the ***@***.*** other} segment.
>
> Ok, I guess I now figured out what you mean; you basically want to
> implement something that has same correctness guarantees as
> System.arraycopy which works on *arbitrary* element sizes, not just
> 8/16/32/64 byte sizes. The copy method we have is good (in the sense that
> you can also copy by bytes, or by int/long words), but if you also need
> multi-bit swap (where multi > 64) then you are out of luck (but I'm curious
> about this use case of extreme swappiness :-) ).
>
> It is possible, in the future, that with the help of the vector API, we
> might be able to indeed lift the restriction, and provide a bulk copy
> (written in Java :-) ) which works on elements bigger than 64 bits. In the
> meantime, we have two options:
>
>    - you "take the hit" when dealing with element sizes > 64bit (meaning
>    in these case you will need extra buffer)
>    - we provide enough primitives which allow you (or others) to
>    implement other copy routines which support similar guarantees as
>    System.arraycopy
>
> Another issue: note that the MemoryAddress::segmentOffset has also gone
> in the API refresh, and I believe your plan was probably to rely on it to
> do the computations; we could add it back if that was really an issue. Or
> we could come up with similar methods which work on segments instead (e.g.
> return the start/end offset of a segment into another segment - which
> combined with an overlapping slice region would probably do what you need
> to do).
>
> I don't know how common this issue is in your API, so I can't judge. The
> general feeling I get is that an overlapping predicate without some other
> ways to compute offsets between slices is not very useful - and so, in that
> case it would be better to do nothing.
>
> ?
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> ,
> or unsubscribe
> 
> .
> Triage notifications on the go with GitHub Mobile for iOS
> 
> or Android
> .
>
>

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

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

From sviswanathan at openjdk.java.net  Wed Sep 29 03:44:23 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Wed, 29 Sep 2021 03:44:23 GMT
Subject: [vectorIntrinsics] RFR: Merge panama-vector:vectorIntrinsics+mask
 [v2]
In-Reply-To: 
References: 
Message-ID: 

> Merging final vectorIntrinsics+mask changes into vectorIntrinsics.
> It is a clean merge without any conflicts.
> Please approve.

Sandhya Viswanathan 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-vector/pull/135/files
  - new: https://git.openjdk.java.net/panama-vector/pull/135/files/17b43095..17b43095

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

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/panama-vector/pull/135.diff
  Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/135/head:pull/135

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

From sviswanathan at openjdk.java.net  Wed Sep 29 03:44:28 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Wed, 29 Sep 2021 03:44:28 GMT
Subject: [vectorIntrinsics] Integrated: Merge
 panama-vector:vectorIntrinsics+mask
In-Reply-To: 
References: 
Message-ID: <3UERuA7a_u1pcThKWvZaWUbEpivfp9o75Yahp6tGNm8=.5e6191e5-a393-4691-a371-b7e94bfd45f5@github.com>

On Tue, 28 Sep 2021 19:52:43 GMT, Sandhya Viswanathan  wrote:

> Merging final vectorIntrinsics+mask changes into vectorIntrinsics.
> It is a clean merge without any conflicts.
> Please approve.

This pull request has now been integrated.

Changeset: bfea1ea8
Author:    Sandhya Viswanathan 
URL:       https://git.openjdk.java.net/panama-vector/commit/bfea1ea814d3bb0af5c2be0232254907d323f12b
Stats:     21686 lines in 101 files changed: 15978 ins; 2075 del; 3633 mod

Merge panama-vector:vectorIntrinsics+mask

Reviewed-by: eliu, jbhateja

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

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

From mcimadamore at openjdk.java.net  Wed Sep 29 10:10:26 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 29 Sep 2021 10:10:26 GMT
Subject: [foreign-memaccess+abi] RFR: 8274157: java.foreign: Add method
 MemorySegment::isOverlapping
In-Reply-To: 
References: 
Message-ID: <3dyTBmvUCMonyZPJ1QWuFVmK4v5J2Ox8QHdU-0B0Ahw=.0a2230e0-e948-4081-a4e8-d9c05bb8efb7@github.com>

On Tue, 28 Sep 2021 12:59:19 GMT, Julia Boes  wrote:

> This change adds a method to the MemorySegment API that detects if two segments are overlapping.

Hi,
some context: the main reason we dropped `segmentOffset` form `MemoryAddress` is that `MemoryAddress` now has a clearer role, which is more geared towards native interop. In other words, if you don't care about foreign functions, I believe `MemoryAddress` is not for you (unless you want to store the address of an off-heap segment in some other segment).

Now, I believe that the idea of returning the overlapping slice, combined with a way to tell the start offset of a segment into another might work?


MemorySegment overlap_a = a.overlap(b);


Now, if `overlap` is not null, can't you derive useful parameters from it, and from `a` and `b` ?

e.g.


long overlap_start_a = a.offsetOf(overlap_a);
long overlap_end_a = overlap_start_a + overlap_a.byteSize()

Then, you can obtain same info for `b`:


MemorySegment overlap_b = b.overlap(a);
long overlap_start_b = b.offsetOf(overlap_b);
long overlap_end_b = overlap_start_b + overlap_b.byteSize()

This is (more or less) the info you are looking for, right?

> I think you understand. But I haven't lost hope, that there aren't some simple primitives that would allow copying of multiple structs from one segment to another where a struct could be an arbitrary size in bytes (not bits). Imagine these segments are quite large ~ gigabytes. Forcing me to allocate a buffer segment of that size and perform redundant copy operations just because I can't figure out whether these segments overlap in memory and which segment precedes the other is a huge penalty. I didn't realize you had already tossed the MemoryAddress:: segmentOffset. This operation is crucial for this task. The minimal primitive operations required would be - boolean Segment.isOverlapping(Segment); //if segments are in different spaces (heap, off-heap) the result is obviously false. - long startingAddress(Segment); //this has to work whether it is on-heap or off-heap. You may consider the underlying copy mechanics to do this to be inefficient, perhaps, but it would still be orders-o
 f-magnitude more efficient than having to create a huge segment buffer and do all the redundant copies. I will construct a simulated java example using these primitives, just to be clear. :) Cheers, Lee.
> [?](#)
> On Tue, Sep 28, 2021 at 5:04 PM Maurizio Cimadamore < ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemorySegment.java <[#585 (comment)](https://github.com/openjdk/panama-foreign/pull/585#discussion_r718049243)> : > @@ -320,6 +320,20 @@ default MemorySegment asSlice(long offset) { */ boolean isMapped(); + /** + * Returns true if this segment overlaps the ***@***.*** other} segment. Ok, I guess I now figured out what you mean; you basically want to implement something that has same correctness guarantees as System.arraycopy which works on *arbitrary* element sizes, not just 8/16/32/64 byte sizes. The copy method we have is good (in the sense that you can also copy by bytes, or by int/long words), but if you also need multi-bit swap (where multi > 64) then you are out of luck (but I'm curious about this use case of extreme swappiness :-) ). It is possible, in the future,
  that with the help of the vector API, we might be able to indeed lift the restriction, and provide a bulk copy (written in Java :-) ) which works on elements bigger than 64 bits. In the meantime, we have two options: - you "take the hit" when dealing with element sizes > 64bit (meaning in these case you will need extra buffer) - we provide enough primitives which allow you (or others) to implement other copy routines which support similar guarantees as System.arraycopy Another issue: note that the MemoryAddress::segmentOffset has also gone in the API refresh, and I believe your plan was probably to rely on it to do the computations; we could add it back if that was really an issue. Or we could come up with similar methods which work on segments instead (e.g. return the start/end offset of a segment into another segment - which combined with an overlapping slice region would probably do what you need to do). I don't know how common this issue is in your API, so I can't judge. The ge
 neral feeling I get is that an overlapping predicate without some other ways to compute offsets between slices is not very useful - and so, in that case it would be better to do nothing. ? You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <[#585 (comment)](https://github.com/openjdk/panama-foreign/pull/585#discussion_r718049243)>, or unsubscribe  . Triage notifications on the go with GitHub Mobile for iOS  or Android .

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

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

From github.com+12941506+leerho at openjdk.java.net  Wed Sep 29 16:01:33 2021
From: github.com+12941506+leerho at openjdk.java.net (Lee Rhodes)
Date: Wed, 29 Sep 2021 16:01:33 GMT
Subject: [foreign-memaccess+abi] RFR: 8274157: java.foreign: Add method
 MemorySegment::isOverlapping
In-Reply-To: 
References: 
Message-ID: 

On Tue, 28 Sep 2021 12:59:19 GMT, Julia Boes  wrote:

> This change adds a method to the MemorySegment API that detects if two segments are overlapping.

Yes, I think this should work.


On Wed, Sep 29, 2021 at 3:08 AM Maurizio Cimadamore <
***@***.***> wrote:

> Hi,
> some context: the main reason we dropped segmentOffset form MemoryAddress
> is that MemoryAddress now has a clearer role, which is more geared
> towards native interop. In other words, if you don't care about foreign
> functions, I believe MemoryAddress is not for you (unless you want to
> store the address of an off-heap segment in some other segment).
>
> Now, I believe that the idea of returning the overlapping slice, combined
> with a way to tell the start offset of a segment into another might work?
>
> MemorySegment overlap_a = a.overlap(b);
>
>
> Now, if overlap is not null, can't you derive useful parameters from it,
> and from a and b ?
>
> e.g.
>
> long overlap_start_a = a.offsetOf(overlap_a);
>
> long overlap_end_a = overlap_start_a + overlap_a.byteSize()
>
>
> Then, you can obtain same info for b:
>
> MemorySegment overlap_b = b.overlap(a);
>
> long overlap_start_b = b.offsetOf(overlap_b);
>
> long overlap_end_b = overlap_start_b + overlap_b.byteSize()
>
>
> This is (more or less) the info you are looking for, right?
>
> I think you understand. But I haven't lost hope, that there aren't some
> simple primitives that would allow copying of multiple structs from one
> segment to another where a struct could be an arbitrary size in bytes (not
> bits). Imagine these segments are quite large ~ gigabytes. Forcing me to
> allocate a buffer segment of that size and perform redundant copy
> operations just because I can't figure out whether these segments overlap
> in memory and which segment precedes the other is a huge penalty. I didn't
> realize you had already tossed the MemoryAddress:: segmentOffset. This
> operation is crucial for this task. The minimal primitive operations
> required would be - boolean Segment.isOverlapping(Segment); //if segments
> are in different spaces (heap, off-heap) the result is obviously false. -
> long startingAddress(Segment); //this has to work whether it is on-heap or
> off-heap. You may consider the underlying copy mechanics to do this to be
> inefficient, perhaps, but it would still be orders-of-magnitude more
> efficient than having to create a huge segment buffer and do all the
> redundant copies. I will construct a simulated java example using these
> primitives, just to be clear. :) Cheers, Lee.
> ? <#m_2355500162956900017_>
> On Tue, Sep 28, 2021 at 5:04 PM Maurizio Cimadamore < *@*.*> wrote: @.**
> commented on this pull request. ------------------------------ In
> src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemorySegment.java
> <#585 (comment)
> >
> : > @@ -320,6 +320,20 @@ default MemorySegment asSlice(long offset) { */
> boolean isMapped(); + /** + * Returns true if this segment overlaps the
> *@*.*** other} segment. Ok, I guess I now figured out what you mean; you
> basically want to implement something that has same correctness guarantees
> as System.arraycopy which works on *arbitrary* element sizes, not just
> 8/16/32/64 byte sizes. The copy method we have is good (in the sense that
> you can also copy by bytes, or by int/long words), but if you also need
> multi-bit swap (where multi > 64) then you are out of luck (but I'm curious
> about this use case of extreme swappiness :-) ). It is possible, in the
> future, that with the help of the vector API, we might be able to indeed
> lift the restriction, and provide a bulk copy (written in Java :-) ) which
> works on elements bigger than 64 bits. In the meantime, we have two
> options: - you "take the hit" when dealing with element sizes > 64bit
> (meaning in these case you will need extra buffer) - we provide enough
> primitives which allow you (or others) to implement other copy routines
> which support similar guarantees as System.arraycopy Another issue: note
> that the MemoryAddress::segmentOffset has also gone in the API refresh, and
> I believe your plan was probably to rely on it to do the computations; we
> could add it back if that was really an issue. Or we could come up with
> similar methods which work on segments instead (e.g. return the start/end
> offset of a segment into another segment - which combined with an
> overlapping slice region would probably do what you need to do). I don't
> know how common this issue is in your API, so I can't judge. The general
> feeling I get is that an overlapping predicate without some other ways to
> compute offsets between slices is not very useful - and so, in that case it
> would be better to do nothing. ? You are receiving this because you were
> mentioned. Reply to this email directly, view it on GitHub <#585 (comment)
> >,
> or unsubscribe
> https://github.com/notifications/unsubscribe-auth/ADCXRQSYPPW4KEAVTUOB7WDUEJJZ3ANCNFSM5E5LPKJA
> . Triage notifications on the go with GitHub Mobile for iOS
> https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
> or Android
> https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub
> .
>
> ?
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> ,
> or unsubscribe
> 
> .
> Triage notifications on the go with GitHub Mobile for iOS
> 
> or Android
> .
>
>

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

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

From duke at openjdk.java.net  Wed Sep 29 16:28:33 2021
From: duke at openjdk.java.net (duke)
Date: Wed, 29 Sep 2021 16:28:33 GMT
Subject: git: openjdk/panama-foreign: foreign-jextract: 2 new changesets
Message-ID: 

Changeset: ab61f068
Author:    Maurizio Cimadamore 
Date:      2021-09-29 16:26:30 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/ab61f0688fe856dd2cb76735eb057170d55ba49c

Make Addressable sealed again

Reviewed-by: jvernee

! 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/MemoryAddress.java
! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/VaList.java
! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java
! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/MemoryAddressImpl.java
= src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/Scoped.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/linux/LinuxAArch64VaList.java
! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/aarch64/macos/MacOsAArch64VaList.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/windows/WinVaList.java

Changeset: 264d4866
Author:    duke 
Date:      2021-09-29 16:27:20 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/264d48660ba225afb2c0831a687548b7c66cddf8

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



From mcimadamore at openjdk.java.net  Wed Sep 29 16:30:17 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 29 Sep 2021 16:30:17 GMT
Subject: [foreign-memaccess+abi] Integrated: Make Addressable sealed again
In-Reply-To: 
References: 
Message-ID: <5E7Wtu9UctiDBGZj3PATeqJGY4wz9TJb4GdAKbtSZhU=.9c9c907b-93bf-4273-b3f8-2177e5c5f6e2@github.com>

On Tue, 28 Sep 2021 18:11:56 GMT, Maurizio Cimadamore  wrote:

> Following the API refresh, I realized that making `Addressable` non-sealed was perhaps a step too far, at least for the time being. It forces a `scope()` accessor on the interface, which in turns pollutes the `MemoryAddress` interface (since a memory address has no scope).
> While the API, as currently defined is sound, I'd prefer to make things tighter for now, as I realized that the need to define custom `Addressable` is perhaps limited. For instance, one place I thought they would have been useful was to model structs - but thinking more, a struct is probably backed by a segment anyway - and the segment is addressable. So, assuming the struct exposes a segment accessor, we still have ways to pass it around w/o necessarily having it implement the `Addressable` interface directly.
> 
> In the implementation we do have a new internal `Scoped` interface, which is used to keep all by-reference parameters alive by the linker. Basically, this interface re-adds the scope accessor which has been removed from the public API.

This pull request has now been integrated.

Changeset: ab61f068
Author:    Maurizio Cimadamore 
URL:       https://git.openjdk.java.net/panama-foreign/commit/ab61f0688fe856dd2cb76735eb057170d55ba49c
Stats:     85 lines in 13 files changed: 39 ins; 29 del; 17 mod

Make Addressable sealed again

Reviewed-by: jvernee

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

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

From mcimadamore at openjdk.java.net  Wed Sep 29 16:33:52 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 29 Sep 2021 16:33:52 GMT
Subject: [foreign-memaccess+abi] RFR: 8274157: java.foreign: Add method
 MemorySegment::isOverlapping
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 29 Sep 2021 15:59:12 GMT, Lee Rhodes  wrote:

> Yes, I think this should work.

Thanks for confirming. Btw is it the case that you want to perform bulk copies with byte-swapping for arbitrary sizes? E.g. you want to swap bytes for entire structs? I guess I'm not super sure of what is your real use case (e.g. the reason as to why just copying bytes from one segment to another is not enough). For instance, if you want to bulk copy arbitrary structs, adjusting for endianness is not simple at all - as you would have to swap each field individually.

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

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

From github.com+7535718+rsmogura at openjdk.java.net  Wed Sep 29 16:33:53 2021
From: github.com+7535718+rsmogura at openjdk.java.net (Radoslaw Smogura)
Date: Wed, 29 Sep 2021 16:33:53 GMT
Subject: [foreign-memaccess+abi] RFR: 8274157: java.foreign: Add method
 MemorySegment::isOverlapping
In-Reply-To: 
References: 
Message-ID: <3SveR2iWhEhCHyhTeUDQZQiJvQ76w1oSaQrMKwKXEJ8=.e9722ddf-261d-44a9-9e6b-fd7c5e529c51@github.com>

On Tue, 28 Sep 2021 12:59:19 GMT, Julia Boes  wrote:

> This change adds a method to the MemorySegment API that detects if two segments are overlapping.

src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java line 272:

> 270:             final long thisEnd = thisStart + this.byteSize() - 1L;
> 271:             final long thatEnd = thatStart + that.byteSize() - 1L;
> 272:             if (thisStart < thatStart && thisEnd >= thatStart) {

Not sure if this is relevant, would it make sense to replace this checks by
`thisStart <= thatEnd && thisEnd >= thatStart`
I think it can be more performant.

Maybe we will be able to drop subtract of 1 and use strong equality

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

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

From github.com+12941506+leerho at openjdk.java.net  Wed Sep 29 17:03:55 2021
From: github.com+12941506+leerho at openjdk.java.net (Lee Rhodes)
Date: Wed, 29 Sep 2021 17:03:55 GMT
Subject: [foreign-memaccess+abi] RFR: 8274157: java.foreign: Add method
 MemorySegment::isOverlapping
In-Reply-To: 
References: 
Message-ID: <1MgjQjsjajE8QBXx-JHQ4bWXTzgwve-HVH7bHrT36hU=.3edf8046-9c0d-4173-8a72-4354dddd6682@github.com>

On Tue, 28 Sep 2021 12:59:19 GMT, Julia Boes  wrote:

> This change adds a method to the MemorySegment API that detects if two segments are overlapping.

Doing byte swapping (i.e, adjusting for endianness) is not required.   This
is for copying structs from one segment to another where all the structs
are the same, but arbitrary size.  If we have to restrict these sizes to
multiples of 2,4, or 8 bytes that would be OK.  But allowing these structs
to be larger than 8 bytes is critical, otherwise we would use existing copy
methods.

On Wed, Sep 29, 2021 at 9:31 AM Radoslaw Smogura ***@***.***>
wrote:

> ***@***.**** commented on this pull request.
> ------------------------------
>
> In
> src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java
> 
> :
>
> > +    public boolean isOverlapping(MemorySegment other) {
> +        AbstractMemorySegmentImpl that = (AbstractMemorySegmentImpl)Objects.requireNonNull(other);
> +        if (base() == that.base()) {  // both are either native or heap
> +            this.checkAccess(0, this.length, true);
> +            that.checkAccess(0, that.length, true);
> +            this.checkValidState();
> +            that.checkValidState();
> +
> +            final long thisStart = this.min();
> +            final long thatStart = that.min();
> +            if (thisStart == thatStart) {
> +                return true;
> +            }
> +            final long thisEnd = thisStart + this.byteSize() - 1L;
> +            final long thatEnd = thatStart + that.byteSize() - 1L;
> +            if (thisStart < thatStart && thisEnd >= thatStart) {
>
> Not sure if this is relevant, would it make sense to replace this checks by
> thisStart <= thatEnd && thisEnd >= thatStart
> I think it can be more performant.
>
> Maybe we will be able to drop subtract of 1 and use strong equality
>
> ?
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> ,
> or unsubscribe
> 
> .
> Triage notifications on the go with GitHub Mobile for iOS
> 
> or Android
> .
>
>

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

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

From maurizio.cimadamore at oracle.com  Wed Sep 29 17:18:51 2021
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Wed, 29 Sep 2021 18:18:51 +0100
Subject: [foreign-memaccess+abi] RFR: 8274157: java.foreign: Add method
 MemorySegment::isOverlapping
In-Reply-To: <1MgjQjsjajE8QBXx-JHQ4bWXTzgwve-HVH7bHrT36hU=.3edf8046-9c0d-4173-8a72-4354dddd6682@github.com>
References: 
 <1MgjQjsjajE8QBXx-JHQ4bWXTzgwve-HVH7bHrT36hU=.3edf8046-9c0d-4173-8a72-4354dddd6682@github.com>
Message-ID: <920d8ef3-4f50-a2f8-67e0-decbcba937f5@oracle.com>


On 29/09/2021 18:03, Lee Rhodes wrote:
> On Tue, 28 Sep 2021 12:59:19 GMT, Julia Boes  wrote:
>
>> This change adds a method to the MemorySegment API that detects if two segments are overlapping.
> Doing byte swapping (i.e, adjusting for endianness) is not required.   This
> is for copying structs from one segment to another where all the structs
> are the same, but arbitrary size.  If we have to restrict these sizes to
> multiples of 2,4, or 8 bytes that would be OK.  But allowing these structs
> to be larger than 8 bytes is critical, otherwise we would use existing copy
> methods.

If you don't need byte swapping - then isn't this:

```
static void copy(MemorySegment srcSegment, long srcOffset, MemorySegment 
dstSegment, long dstOffset, long bytes)
```

enough for your needs? What goes wrong if I use the above copy method on 
one of your struct arrays?

Maurizio

>
> On Wed, Sep 29, 2021 at 9:31 AM Radoslaw Smogura ***@***.***>
> wrote:
>
>> ***@***.**** commented on this pull request.
>> ------------------------------
>>
>> In
>> src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java
>> 
>> :
>>
>>> +    public boolean isOverlapping(MemorySegment other) {
>> +        AbstractMemorySegmentImpl that = (AbstractMemorySegmentImpl)Objects.requireNonNull(other);
>> +        if (base() == that.base()) {  // both are either native or heap
>> +            this.checkAccess(0, this.length, true);
>> +            that.checkAccess(0, that.length, true);
>> +            this.checkValidState();
>> +            that.checkValidState();
>> +
>> +            final long thisStart = this.min();
>> +            final long thatStart = that.min();
>> +            if (thisStart == thatStart) {
>> +                return true;
>> +            }
>> +            final long thisEnd = thisStart + this.byteSize() - 1L;
>> +            final long thatEnd = thatStart + that.byteSize() - 1L;
>> +            if (thisStart < thatStart && thisEnd >= thatStart) {
>>
>> Not sure if this is relevant, would it make sense to replace this checks by
>> thisStart <= thatEnd && thisEnd >= thatStart
>> I think it can be more performant.
>>
>> Maybe we will be able to drop subtract of 1 and use strong equality
>>
>> ?
>> You are receiving this because you were mentioned.
>> Reply to this email directly, view it on GitHub
>> ,
>> or unsubscribe
>> 
>> .
>> Triage notifications on the go with GitHub Mobile for iOS
>> 
>> or Android
>> .
>>
>>
> -------------
>
> PR: https://git.openjdk.java.net/panama-foreign/pull/585

From psandoz at openjdk.java.net  Wed Sep 29 19:28:12 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Wed, 29 Sep 2021 19:28:12 GMT
Subject: [vectorIntrinsics] RFR: Merge panama-vector:master
Message-ID: <6xgCrexHL8ox66YqB5FTmLmiIGRekJeVndo-Yo5v5w8=.883e96df-9204-46fa-a3b5-2c624f1a2765@github.com>

Doing another merge to ensue test configuration is up to date, thereby ensuring test infrastructure configuration is in sync.

Merge was clean. Local build and test on mac is also clean.

(Previous attempt selected the wrong base repository!)

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

Commit messages:
 - Merge branch 'master' into merge-master-to-vectorIntrinsics
 - 8274509: Remove stray * and stylistic . from doc comments
 - 8274453: (sctp) com/sun/nio/sctp/SctpChannel/CloseDescriptors.java test should be resilient to lsof warnings
 - 8274330: Incorrect encoding of the DistributionPointName object in IssuingDistributionPointExtension
 - 8272562: C2: assert(false) failed: Bad graph detected in build_loop_late
 - 8274340: [BACKOUT] JDK-8271880: Tighten condition for excluding regions from collecting cards with cross-references
 - 8274242: Implement fast-path for ASCII-compatible CharsetEncoders on x86
 - 8271855: [TESTBUG] Wrong weakCompareAndSet assumption in UnsafeIntrinsicsTest
 - 8274130: C2: MulNode::Ideal chained transformations may act on wrong nodes
 - 8274172: Convert JavadocTester to use NIO
 - ... and 78 more: https://git.openjdk.java.net/panama-vector/compare/bfea1ea8...62fbeb1e

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - vectorIntrinsics: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=137&range=00.0
 - panama-vector:master: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=137&range=00.1

Changes: https://git.openjdk.java.net/panama-vector/pull/137/files
  Stats: 8951 lines in 305 files changed: 6222 ins; 1560 del; 1169 mod
  Patch: https://git.openjdk.java.net/panama-vector/pull/137.diff
  Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/137/head:pull/137

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

From leerho at gmail.com  Wed Sep 29 21:19:50 2021
From: leerho at gmail.com (leerho)
Date: Wed, 29 Sep 2021 14:19:50 -0700
Subject: [foreign-memaccess+abi] RFR: 8274157: java.foreign: Add method
 MemorySegment::isOverlapping
In-Reply-To: <920d8ef3-4f50-a2f8-67e0-decbcba937f5@oracle.com>
References: 
 <1MgjQjsjajE8QBXx-JHQ4bWXTzgwve-HVH7bHrT36hU=.3edf8046-9c0d-4173-8a72-4354dddd6682@github.com>
 <920d8ef3-4f50-a2f8-67e0-decbcba937f5@oracle.com>
Message-ID: 

Nothing ??!  You are correct for this particular use case. But
*isOverlapping(segment)* is such a basic bit of information about two
segments there might be other use cases that would find this valuable.



On Wed, Sep 29, 2021 at 10:57 AM Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

>
> On 29/09/2021 18:03, Lee Rhodes wrote:
> > On Tue, 28 Sep 2021 12:59:19 GMT, Julia Boes  wrote:
> >
> >> This change adds a method to the MemorySegment API that detects if two
> segments are overlapping.
> > Doing byte swapping (i.e, adjusting for endianness) is not required.
>  This
> > is for copying structs from one segment to another where all the structs
> > are the same, but arbitrary size.  If we have to restrict these sizes to
> > multiples of 2,4, or 8 bytes that would be OK.  But allowing these
> structs
> > to be larger than 8 bytes is critical, otherwise we would use existing
> copy
> > methods.
>
> If you don't need byte swapping - then isn't this:
>
> ```
> static void copy(MemorySegment srcSegment, long srcOffset, MemorySegment
> dstSegment, long dstOffset, long bytes)
> ```
>
> enough for your needs? What goes wrong if I use the above copy method on
> one of your struct arrays?
>
> Maurizio
>
> >
> > On Wed, Sep 29, 2021 at 9:31 AM Radoslaw Smogura ***@***.***>
> > wrote:
> >
> >> ***@***.**** commented on this pull request.
> >> ------------------------------
> >>
> >> In
> >>
> src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java
> >> <
> https://github.com/openjdk/panama-foreign/pull/585#discussion_r718684769>
> >> :
> >>
> >>> +    public boolean isOverlapping(MemorySegment other) {
> >> +        AbstractMemorySegmentImpl that =
> (AbstractMemorySegmentImpl)Objects.requireNonNull(other);
> >> +        if (base() == that.base()) {  // both are either native or heap
> >> +            this.checkAccess(0, this.length, true);
> >> +            that.checkAccess(0, that.length, true);
> >> +            this.checkValidState();
> >> +            that.checkValidState();
> >> +
> >> +            final long thisStart = this.min();
> >> +            final long thatStart = that.min();
> >> +            if (thisStart == thatStart) {
> >> +                return true;
> >> +            }
> >> +            final long thisEnd = thisStart + this.byteSize() - 1L;
> >> +            final long thatEnd = thatStart + that.byteSize() - 1L;
> >> +            if (thisStart < thatStart && thisEnd >= thatStart) {
> >>
> >> Not sure if this is relevant, would it make sense to replace this
> checks by
> >> thisStart <= thatEnd && thisEnd >= thatStart
> >> I think it can be more performant.
> >>
> >> Maybe we will be able to drop subtract of 1 and use strong equality
> >>
> >> ?
> >> You are receiving this because you were mentioned.
> >> Reply to this email directly, view it on GitHub
> >> <
> https://github.com/openjdk/panama-foreign/pull/585#pullrequestreview-766923138
> >,
> >> or unsubscribe
> >> <
> https://github.com/notifications/unsubscribe-auth/ADCXRQTV4KNEK3ALQ7WM5G3UEM5NVANCNFSM5E5LPKJA
> >
> >> .
> >> Triage notifications on the go with GitHub Mobile for iOS
> >> <
> https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
> >
> >> or Android
> >> <
> https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub
> >.
> >>
> >>
> > -------------
> >
> > PR: https://git.openjdk.java.net/panama-foreign/pull/585
>

From sviswanathan at openjdk.java.net  Wed Sep 29 21:22:18 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Wed, 29 Sep 2021 21:22:18 GMT
Subject: [vectorIntrinsics] RFR: Merge panama-vector:master
In-Reply-To: <6xgCrexHL8ox66YqB5FTmLmiIGRekJeVndo-Yo5v5w8=.883e96df-9204-46fa-a3b5-2c624f1a2765@github.com>
References: <6xgCrexHL8ox66YqB5FTmLmiIGRekJeVndo-Yo5v5w8=.883e96df-9204-46fa-a3b5-2c624f1a2765@github.com>
Message-ID: 

On Wed, 29 Sep 2021 19:22:48 GMT, Paul Sandoz  wrote:

> Doing another merge to ensue test configuration is up to date, thereby ensuring test infrastructure configuration is in sync.
> 
> Merge was clean. Local build and test on mac is also clean.
> 
> (Previous attempt selected the wrong base repository!)

Marked as reviewed by sviswanathan (Committer).

The merge looks good to me.

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

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

From mcimadamore at openjdk.java.net  Wed Sep 29 21:24:05 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 29 Sep 2021 21:24:05 GMT
Subject: [foreign-memaccess+abi] RFR: TestScopedOperations does not work as
 expected
Message-ID: 

When Julia started to work on the `MemorySegment::overlap` API, she noticed (thanks!) an issue with the TestScopedOperation. Essentially this test checks that calling methods on various objects should be scope-safe - that is, it shouldn't be possible to call certain methods (e.g. MemorySegment::address) if the scope associated with the object is closed, or from a thread other than the owning thread.

The test had a fatal flaw, which was probably introduced when we moved to the `ResourceScope` API. Since the scoped operation creates the desired object (e.g. a segment) and then performs an operation on it, and since that operation is performed _after_ the scope has been closed, as a result, all tests trivially fail as expected, since the object cannot be created in the first place (the scope is closed!!).

The solution is to separate the logic for creating the object from the logic for testing the scoped operation. In fixing the test I realized that the test was running two combinations which didn't make sense (prefixAllocator::allocate, and segment::spliterator, neither of which is scoped), and found a bug in the VaList implementation - for VaList::skip, which was missing a scope check (which this patch also addresses).

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

Commit messages:
 - Fix TestScopedOperations

Changes: https://git.openjdk.java.net/panama-foreign/pull/587/files
 Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=587&range=00
  Stats: 50 lines in 6 files changed: 20 ins; 7 del; 23 mod
  Patch: https://git.openjdk.java.net/panama-foreign/pull/587.diff
  Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/587/head:pull/587

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

From maurizio.cimadamore at oracle.com  Wed Sep 29 21:50:29 2021
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Wed, 29 Sep 2021 22:50:29 +0100
Subject: [foreign-memaccess+abi] RFR: 8274157: java.foreign: Add method
 MemorySegment::isOverlapping
In-Reply-To: 
References: 
 <1MgjQjsjajE8QBXx-JHQ4bWXTzgwve-HVH7bHrT36hU=.3edf8046-9c0d-4173-8a72-4354dddd6682@github.com>
 <920d8ef3-4f50-a2f8-67e0-decbcba937f5@oracle.com>
 
Message-ID: <84df0b18-3631-73d1-c606-97b49aa8550d@oracle.com>


On 29/09/2021 22:19, leerho wrote:
> Nothing???!? You are correct for?this particular use case. But 
> /isOverlapping(segment)/?is such a basic bit of information about two 
> segments there might be other use cases that would find this valuable.

Ok - point taken.

And I think that, since we dropped MemoryAddress::segmentOffset (out of 
necessity), having some other way to find the offset of a segment 
relative to each other might come in handy anyway.

Maurizio

>
>
>
> On Wed, Sep 29, 2021 at 10:57 AM Maurizio Cimadamore 
>  > wrote:
>
>
>     On 29/09/2021 18:03, Lee Rhodes wrote:
>     > On Tue, 28 Sep 2021 12:59:19 GMT, Julia Boes      > wrote:
>     >
>     >> This change adds a method to the MemorySegment API that detects
>     if two segments are overlapping.
>     > Doing byte swapping (i.e, adjusting for endianness) is not
>     required.? ?This
>     > is for copying structs from one segment to another where all the
>     structs
>     > are the same, but arbitrary size.? If we have to restrict these
>     sizes to
>     > multiples of 2,4, or 8 bytes that would be OK.? But allowing
>     these structs
>     > to be larger than 8 bytes is critical, otherwise we would use
>     existing copy
>     > methods.
>
>     If you don't need byte swapping - then isn't this:
>
>     ```
>     static void copy(MemorySegment srcSegment, long srcOffset,
>     MemorySegment
>     dstSegment, long dstOffset, long bytes)
>     ```
>
>     enough for your needs? What goes wrong if I use the above copy
>     method on
>     one of your struct arrays?
>
>     Maurizio
>
>     >
>     > On Wed, Sep 29, 2021 at 9:31 AM Radoslaw Smogura ***@***.***>
>     > wrote:
>     >
>     >> ***@***.**** commented on this pull request.
>     >> ------------------------------
>     >>
>     >> In
>     >>
>     src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java
>     >>
>          >
>     >> :
>     >>
>     >>> +? ? public boolean isOverlapping(MemorySegment other) {
>     >> +? ? ? ? AbstractMemorySegmentImpl that =
>     (AbstractMemorySegmentImpl)Objects.requireNonNull(other);
>     >> +? ? ? ? if (base() == that.base()) {? // both are either
>     native or heap
>     >> +? ? ? ? ? ? this.checkAccess(0, this.length, true);
>     >> +? ? ? ? ? ? that.checkAccess(0, that.length, true);
>     >> +? ? ? ? ? ? this.checkValidState();
>     >> +? ? ? ? ? ? that.checkValidState();
>     >> +
>     >> +? ? ? ? ? ? final long thisStart = this.min();
>     >> +? ? ? ? ? ? final long thatStart = that.min();
>     >> +? ? ? ? ? ? if (thisStart == thatStart) {
>     >> +? ? ? ? ? ? ? ? return true;
>     >> +? ? ? ? ? ? }
>     >> +? ? ? ? ? ? final long thisEnd = thisStart + this.byteSize() - 1L;
>     >> +? ? ? ? ? ? final long thatEnd = thatStart + that.byteSize() - 1L;
>     >> +? ? ? ? ? ? if (thisStart < thatStart && thisEnd >= thatStart) {
>     >>
>     >> Not sure if this is relevant, would it make sense to replace
>     this checks by
>     >> thisStart <= thatEnd && thisEnd >= thatStart
>     >> I think it can be more performant.
>     >>
>     >> Maybe we will be able to drop subtract of 1 and use strong equality
>     >>
>     >> ?
>     >> You are receiving this because you were mentioned.
>     >> Reply to this email directly, view it on GitHub
>     >>
>          >,
>     >> or unsubscribe
>     >>
>          >
>     >> .
>     >> Triage notifications on the go with GitHub Mobile for iOS
>     >>
>          >
>     >> or Android
>     >>
>          >.
>     >>
>     >>
>     > -------------
>     >
>     > PR: https://git.openjdk.java.net/panama-foreign/pull/585
>     
>

From eliu at openjdk.java.net  Thu Sep 30 01:40:04 2021
From: eliu at openjdk.java.net (Eric Liu)
Date: Thu, 30 Sep 2021 01:40:04 GMT
Subject: [vectorIntrinsics] RFR: Merge panama-vector:master
In-Reply-To: <6xgCrexHL8ox66YqB5FTmLmiIGRekJeVndo-Yo5v5w8=.883e96df-9204-46fa-a3b5-2c624f1a2765@github.com>
References: <6xgCrexHL8ox66YqB5FTmLmiIGRekJeVndo-Yo5v5w8=.883e96df-9204-46fa-a3b5-2c624f1a2765@github.com>
Message-ID: 

On Wed, 29 Sep 2021 19:22:48 GMT, Paul Sandoz  wrote:

> Doing another merge to ensue test configuration is up to date, thereby ensuring test infrastructure configuration is in sync.
> 
> Merge was clean. Local build and test on mac is also clean.
> 
> (Previous attempt selected the wrong base repository!)

LGTM.

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

Marked as reviewed by eliu (Committer).

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

From jbhateja at openjdk.java.net  Thu Sep 30 04:33:52 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Thu, 30 Sep 2021 04:33:52 GMT
Subject: [vectorIntrinsics] RFR: Merge panama-vector:master
In-Reply-To: <6xgCrexHL8ox66YqB5FTmLmiIGRekJeVndo-Yo5v5w8=.883e96df-9204-46fa-a3b5-2c624f1a2765@github.com>
References: <6xgCrexHL8ox66YqB5FTmLmiIGRekJeVndo-Yo5v5w8=.883e96df-9204-46fa-a3b5-2c624f1a2765@github.com>
Message-ID: 

On Wed, 29 Sep 2021 19:22:48 GMT, Paul Sandoz  wrote:

> Doing another merge to ensue test configuration is up to date, thereby ensuring test infrastructure configuration is in sync.
> 
> Merge was clean. Local build and test on mac is also clean.
> 
> (Previous attempt selected the wrong base repository!)

Marked as reviewed by jbhateja (Committer).

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

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

From jiefu at openjdk.java.net  Thu Sep 30 05:04:44 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Thu, 30 Sep 2021 05:04:44 GMT
Subject: [vectorIntrinsics] RFR: 8274533: [Vector API] Incorrect computation
 by VectorMask.toLong operation after JDK-8273949
Message-ID: 

Hi all,

Please review this small fix which fixes the incorrect result by VectorMask.toLong after JDK-8273949.

Thanks.
Best regards,
Jie

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

Commit messages:
 - 8274533: [Vector API] Incorrect computation by VectorMask.toLong operation after JDK-8273949

Changes: https://git.openjdk.java.net/panama-vector/pull/138/files
 Webrev: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=138&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274533
  Stats: 62 lines in 2 files changed: 62 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/panama-vector/pull/138.diff
  Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/138/head:pull/138

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

From jiefu at openjdk.java.net  Thu Sep 30 06:04:49 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Thu, 30 Sep 2021 06:04:49 GMT
Subject: [vectorIntrinsics+mask] RFR: 8273949: Intrinsic creation for
 VectorMask.toLong operation. [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 23 Sep 2021 03:16:38 GMT, Jatin Bhateja  wrote:

>> Summary of changes:
>> - Intrinsification of VectorMask.toLong() API.
>> - Supports inline expansion for both AVX512 and non-AVX512 targets.
>> - Used toLong() API to optimize existing Java API implementation of VectorMask.laneIsSet() operation.
>> 
>> Following performance number are generated using JMH benchmark modification included with the patch.
>> 
>> System:  Intel(R) Xeon(R) Platinum 8280 CPU @ 2.70GHz (Cascade Lake Server 28C 2S)
>> 
>> Benchmark | VECSIZE | Baseline Score (ops/ms) | With Opt (ops/ms) | Gain Ratio
>> -- | -- | -- | -- | --
>> MaskQueryOperationsBenchmark.testToLongByte | 128 | 90451.424 | 346941.379 | 3.835665196
>> MaskQueryOperationsBenchmark.testToLongByte | 256 | 63127.764 | 338331.425 | 5.359471072
>> MaskQueryOperationsBenchmark.testToLongByte | 512 | 40543.264 | 313836.333 | 7.740776199
>> MaskQueryOperationsBenchmark.testToLongLong | 128 | 171989.714 | 152872.758 | 0.88884826
>> MaskQueryOperationsBenchmark.testToLongLong | 256 | 164702.273 | 324794.578 | 1.972010295
>> MaskQueryOperationsBenchmark.testToLongLong | 512 | 122667.916 | 318060.096 | 2.59285481
>> MaskQueryOperationsBenchmark.testToLongShort | 128 | 122656.408 | 346691.082 | 2.826522378
>> MaskQueryOperationsBenchmark.testToLongShort | 256 | 96838.555 | 360909.28 | 3.726917239
>> MaskQueryOperationsBenchmark.testToLongShort | 512 | 63119.009 | 313075.159 | 4.960077225
>> MaskQueryOperationsBenchmark.testToLonglong | 128 | 180855.623 | 324620.433 | 1.794914792
>> MaskQueryOperationsBenchmark.testToLonglong | 256 | 122705.631 | 324315.916 | 2.643040204
>> MaskQueryOperationsBenchmark.testToLonglong | 512 | 90396.687 | 324318.095 | 3.58772103
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8273949: Resolving synthetic comment.

Incorrect computation after this pr.
Please see: https://github.com/openjdk/panama-vector/pull/138 .
Thanks.

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

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

From jboes at openjdk.java.net  Thu Sep 30 08:23:58 2021
From: jboes at openjdk.java.net (Julia Boes)
Date: Thu, 30 Sep 2021 08:23:58 GMT
Subject: [foreign-memaccess+abi] RFR: TestScopedOperations does not work
 as expected
In-Reply-To: 
References: 
Message-ID: 

On Wed, 29 Sep 2021 21:16:39 GMT, Maurizio Cimadamore  wrote:

> When Julia started to work on the `MemorySegment::overlap` API, she noticed (thanks!) an issue with the TestScopedOperation. Essentially this test checks that calling methods on various objects should be scope-safe - that is, it shouldn't be possible to call certain methods (e.g. MemorySegment::address) if the scope associated with the object is closed, or from a thread other than the owning thread.
> 
> The test had a fatal flaw, which was probably introduced when we moved to the `ResourceScope` API. Since the scoped operation creates the desired object (e.g. a segment) and then performs an operation on it, and since that operation is performed _after_ the scope has been closed, as a result, all tests trivially fail as expected, since the object cannot be created in the first place (the scope is closed!!).
> 
> The solution is to separate the logic for creating the object from the logic for testing the scoped operation. In fixing the test I realized that the test was running two combinations which didn't make sense (prefixAllocator::allocate, and segment::spliterator, neither of which is scoped), and found a bug in the VaList implementation - for VaList::skip, which was missing a scope check (which this patch also addresses).

Looks good, and you found a bug along the way, nice.

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

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

From jbhateja at openjdk.java.net  Thu Sep 30 10:15:44 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Thu, 30 Sep 2021 10:15:44 GMT
Subject: [vectorIntrinsics] RFR: 8274533: [Vector API] Incorrect
 computation by VectorMask.toLong operation after JDK-8273949
In-Reply-To: 
References: 
Message-ID: 

On Thu, 30 Sep 2021 04:57:09 GMT, Jie Fu  wrote:

> Hi all,
> 
> Please review this small fix which fixes the incorrect result by VectorMask.toLong after JDK-8273949.
> 
> Thanks.
> Best regards,
> Jie

Hi Jei, 
I am working on an alternate patch which fixes instruction sequence in legacy storeMask patterns.
Will share it shortly, I think it will also address this issue, kindly review the patch once its posted.

Best Regards,
Jatin

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

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

From jiefu at openjdk.java.net  Thu Sep 30 11:46:58 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Thu, 30 Sep 2021 11:46:58 GMT
Subject: [vectorIntrinsics] RFR: 8274533: [Vector API] Incorrect
 computation by VectorMask.toLong operation after JDK-8273949
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 30 Sep 2021 10:13:01 GMT, Jatin Bhateja  wrote:

> Hi Jei, I am working on an alternate patch which fixes instruction sequence in legacy storeMask patterns. Will share it shortly, I think it will also address this issue, kindly review the patch once its posted.
> 
> Best Regards, Jatin

Hi @jatin-bhateja ,

This is just a small bug fix, which follows the code style of current implementation.
Maybe you can still go on with your enhancement after this fix.

It took me hours to narrow down and fix the problem.
Otherwise, it would be completely a waste of time to do this kind of things.
Thanks.

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

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

From jvernee at openjdk.java.net  Thu Sep 30 11:48:52 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Thu, 30 Sep 2021 11:48:52 GMT
Subject: [foreign-memaccess+abi] RFR: TestScopedOperations does not work
 as expected
In-Reply-To: 
References: 
Message-ID: 

On Wed, 29 Sep 2021 21:16:39 GMT, Maurizio Cimadamore  wrote:

> When Julia started to work on the `MemorySegment::overlap` API, she noticed (thanks!) an issue with the TestScopedOperation. Essentially this test checks that calling methods on various objects should be scope-safe - that is, it shouldn't be possible to call certain methods (e.g. MemorySegment::address) if the scope associated with the object is closed, or from a thread other than the owning thread.
> 
> The test had a fatal flaw, which was probably introduced when we moved to the `ResourceScope` API. Since the scoped operation creates the desired object (e.g. a segment) and then performs an operation on it, and since that operation is performed _after_ the scope has been closed, as a result, all tests trivially fail as expected, since the object cannot be created in the first place (the scope is closed!!).
> 
> The solution is to separate the logic for creating the object from the logic for testing the scoped operation. In fixing the test I realized that the test was running two combinations which didn't make sense (prefixAllocator::allocate, and segment::spliterator, neither of which is scoped), and found a bug in the VaList implementation - for VaList::skip, which was missing a scope check (which this patch also addresses).

Looks like you have some merge conflicts as well

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/SegmentAllocator.java line 29:

> 27: 
> 28: import jdk.internal.foreign.ArenaAllocator;
> 29: import jdk.internal.foreign.ResourceScopeImpl;

Spurious import?

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

Marked as reviewed by jvernee (Committer).

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

From mcimadamore at openjdk.java.net  Thu Sep 30 12:08:57 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 30 Sep 2021 12:08:57 GMT
Subject: [foreign-memaccess+abi] RFR: TestScopedOperations does not work
 as expected [v2]
In-Reply-To: 
References: 
Message-ID: 

> When Julia started to work on the `MemorySegment::overlap` API, she noticed (thanks!) an issue with the TestScopedOperation. Essentially this test checks that calling methods on various objects should be scope-safe - that is, it shouldn't be possible to call certain methods (e.g. MemorySegment::address) if the scope associated with the object is closed, or from a thread other than the owning thread.
> 
> The test had a fatal flaw, which was probably introduced when we moved to the `ResourceScope` API. Since the scoped operation creates the desired object (e.g. a segment) and then performs an operation on it, and since that operation is performed _after_ the scope has been closed, as a result, all tests trivially fail as expected, since the object cannot be created in the first place (the scope is closed!!).
> 
> The solution is to separate the logic for creating the object from the logic for testing the scoped operation. In fixing the test I realized that the test was running two combinations which didn't make sense (prefixAllocator::allocate, and segment::spliterator, neither of which is scoped), and found a bug in the VaList implementation - for VaList::skip, which was missing a scope check (which this patch also addresses).

Maurizio Cimadamore 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 fixScopedOperationTest
 - Fix TestScopedOperations

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

Changes: https://git.openjdk.java.net/panama-foreign/pull/587/files
 Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=587&range=01
  Stats: 49 lines in 5 files changed: 19 ins; 7 del; 23 mod
  Patch: https://git.openjdk.java.net/panama-foreign/pull/587.diff
  Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/587/head:pull/587

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

From duke at openjdk.java.net  Thu Sep 30 12:30:30 2021
From: duke at openjdk.java.net (duke)
Date: Thu, 30 Sep 2021 12:30:30 GMT
Subject: git: openjdk/panama-foreign: foreign-jextract: 2 new changesets
Message-ID: 

Changeset: 45111908
Author:    Maurizio Cimadamore 
Date:      2021-09-30 12:27:14 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/451119083514a197f055babb567596ef07c27d2f

TestScopedOperations does not work as expected

Reviewed-by: jvernee

! 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/MacOsAArch64VaList.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/windows/WinVaList.java
! test/jdk/java/foreign/TestScopedOperations.java

Changeset: 050dfa15
Author:    duke 
Date:      2021-09-30 12:28:17 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/050dfa15e8075a4d548ffe5a521930cc23da7f77

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



From mcimadamore at openjdk.java.net  Thu Sep 30 12:31:04 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 30 Sep 2021 12:31:04 GMT
Subject: [foreign-memaccess+abi] Integrated: TestScopedOperations does not
 work as expected
In-Reply-To: 
References: 
Message-ID: 

On Wed, 29 Sep 2021 21:16:39 GMT, Maurizio Cimadamore  wrote:

> When Julia started to work on the `MemorySegment::overlap` API, she noticed (thanks!) an issue with the TestScopedOperation. Essentially this test checks that calling methods on various objects should be scope-safe - that is, it shouldn't be possible to call certain methods (e.g. MemorySegment::address) if the scope associated with the object is closed, or from a thread other than the owning thread.
> 
> The test had a fatal flaw, which was probably introduced when we moved to the `ResourceScope` API. Since the scoped operation creates the desired object (e.g. a segment) and then performs an operation on it, and since that operation is performed _after_ the scope has been closed, as a result, all tests trivially fail as expected, since the object cannot be created in the first place (the scope is closed!!).
> 
> The solution is to separate the logic for creating the object from the logic for testing the scoped operation. In fixing the test I realized that the test was running two combinations which didn't make sense (prefixAllocator::allocate, and segment::spliterator, neither of which is scoped), and found a bug in the VaList implementation - for VaList::skip, which was missing a scope check (which this patch also addresses).

This pull request has now been integrated.

Changeset: 45111908
Author:    Maurizio Cimadamore 
URL:       https://git.openjdk.java.net/panama-foreign/commit/451119083514a197f055babb567596ef07c27d2f
Stats:     49 lines in 5 files changed: 19 ins; 7 del; 23 mod

TestScopedOperations does not work as expected

Reviewed-by: jvernee

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

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

From jvernee at openjdk.java.net  Thu Sep 30 14:14:03 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Thu, 30 Sep 2021 14:14:03 GMT
Subject: [foreign-memaccess+abi] RFR: 8274592: Performance regression in
 upcalls
In-Reply-To: <_u92GUNNwgB6pcRVyeJh5eK-UOIx87fMluR_c55e_-k=.8626a343-250e-4318-8a03-1943afdae7a8@github.com>
References: <_u92GUNNwgB6pcRVyeJh5eK-UOIx87fMluR_c55e_-k=.8626a343-250e-4318-8a03-1943afdae7a8@github.com>
Message-ID: <3XHuZG6Z-vJF50wcR4bOCq-L8IL0vuZJKnBWIKEYQ7s=.2564682d-be17-4d05-b614-3ebfca4ebc74@github.com>

On Thu, 30 Sep 2021 13:49:33 GMT, Maurizio Cimadamore  wrote:

> Following the recent API refresh, I noticed that the QSort benchmark was broken (as it passed `MemoryAddress` where `Addressable` was expected). Upon fixing the benchmark, I realized that performance of upcalls dropped significantly (~3x).
> 
> After some investigation, I realized that we were using the default scope factory (which uses a cleaner!) inside some classes in the linker implementation.
> 
> The solution is to use the explicit factory which disables the cleaner, so as to avoid overhead.
> 
> There were similar issues in microbenchmarks; while using the default factory is fine for e.g. fields, using it for benchmark code is not great, as that skews the benchmark (because of the cleaner). So I replaced all usages of the default factories in the benchmark methods, except in places where we explicitly wanted to use them.

Marked as reviewed by jvernee (Committer).

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

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

From duke at openjdk.java.net  Thu Sep 30 14:38:08 2021
From: duke at openjdk.java.net (duke)
Date: Thu, 30 Sep 2021 14:38:08 GMT
Subject: git: openjdk/panama-foreign: foreign-jextract: 2 new changesets
Message-ID: <07d2facc-977e-4739-b8e5-8c0747906b46@openjdk.org>

Changeset: 9cd966f1
Author:    Maurizio Cimadamore 
Date:      2021-09-30 14:36:18 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/9cd966f1944a6109d1cc537510c3beae50348439

8274592: Performance regression in upcalls

Reviewed-by: jvernee

! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/Binding.java
! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/ProgrammableInvoker.java
! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/x64/sysv/SysVVaList.java
! test/micro/org/openjdk/bench/jdk/incubator/foreign/BulkMismatchAcquire.java
! test/micro/org/openjdk/bench/jdk/incubator/foreign/QSort.java
! test/micro/org/openjdk/bench/jdk/incubator/foreign/ResourceScopeClose.java
! test/micro/org/openjdk/bench/jdk/incubator/foreign/VaList.java
! test/micro/org/openjdk/bench/jdk/incubator/foreign/points/support/PanamaPoint.java
! test/micro/org/openjdk/bench/jdk/incubator/vector/TestLoadStoreBytes.java
! test/micro/org/openjdk/bench/jdk/incubator/vector/TestLoadStoreShort.java

Changeset: 13fd5a6b
Author:    duke 
Date:      2021-09-30 14:37:22 +0000
URL:       https://git.openjdk.java.net/panama-foreign/commit/13fd5a6b4486251332d1146a7f5d16a3ffdca6d9

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



From mcimadamore at openjdk.java.net  Thu Sep 30 14:40:17 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 30 Sep 2021 14:40:17 GMT
Subject: [foreign-memaccess+abi] Integrated: 8274592: Performance regression
 in upcalls
In-Reply-To: <_u92GUNNwgB6pcRVyeJh5eK-UOIx87fMluR_c55e_-k=.8626a343-250e-4318-8a03-1943afdae7a8@github.com>
References: <_u92GUNNwgB6pcRVyeJh5eK-UOIx87fMluR_c55e_-k=.8626a343-250e-4318-8a03-1943afdae7a8@github.com>
Message-ID: <0VragaOddHqGYugOtlpZNnGLMAr50N8X4AkH_bLhvfA=.61e59ec0-0e30-4b22-b7bc-76e70e74e6db@github.com>

On Thu, 30 Sep 2021 13:49:33 GMT, Maurizio Cimadamore  wrote:

> Following the recent API refresh, I noticed that the QSort benchmark was broken (as it passed `MemoryAddress` where `Addressable` was expected). Upon fixing the benchmark, I realized that performance of upcalls dropped significantly (~3x).
> 
> After some investigation, I realized that we were using the default scope factory (which uses a cleaner!) inside some classes in the linker implementation.
> 
> The solution is to use the explicit factory which disables the cleaner, so as to avoid overhead.
> 
> There were similar issues in microbenchmarks; while using the default factory is fine for e.g. fields, using it for benchmark code is not great, as that skews the benchmark (because of the cleaner). So I replaced all usages of the default factories in the benchmark methods, except in places where we explicitly wanted to use them.

This pull request has now been integrated.

Changeset: 9cd966f1
Author:    Maurizio Cimadamore 
URL:       https://git.openjdk.java.net/panama-foreign/commit/9cd966f1944a6109d1cc537510c3beae50348439
Stats:     30 lines in 10 files changed: 13 ins; 0 del; 17 mod

8274592: Performance regression in upcalls

Reviewed-by: jvernee

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

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

From mcimadamore at openjdk.java.net  Thu Sep 30 15:19:17 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 30 Sep 2021 15:19:17 GMT
Subject: [foreign-memaccess+abi] RFR: 8274602: Generalize UpcallStub into
 NativeSymbol
Message-ID: 

It might sometimes be useful to define a custom symbol lookup which returns symbols backed by a library that can be unloaded dynamically (e.g. using dlopen).
We indeed have all the pieces to get there, except that symbnol lookup returns a memory address, which is not a scoped entity.

To address this, I propose that we add a new sealed interface/final class (`NativeSymbol`) which implements `Addressable` and is used in two places:
* as a return value for a symbol lookup
* as a proxy for an upcall stub

In other words, `NativeSymbol` is used to reference to some symbol in some library, where the library can have a given scope. Upcall stubs are just a special case where the upcall symbol is synthetized on the fly by the VM. With this in place, I think we can drop `CLinker.UpcallStub` and just use an "anonymous` NativeSymbol to represent upcall stubs.

With this, it should be possible to define a dlopen-based lookup such as the one below:
https://github.com/sundararajana/panama-jextract-samples/blob/master/dlopen/Dlopen.java

In a way that is completely *safe* - that is, so that it is not possible for a library to be unloaded while a function is being executed (even when the scope  associated to the native symbol is shared).

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

Commit messages:
 - Merge branch 'foreign-memaccess+abi' into native_symbol
 - Fix QSort benchmark
 - Add scope check
 - Merge branch 'foreign-memaccess+abi' into native_symbol
 - Initial push

Changes: https://git.openjdk.java.net/panama-foreign/pull/589/files
 Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=589&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274602
  Stats: 237 lines in 31 files changed: 102 ins; 72 del; 63 mod
  Patch: https://git.openjdk.java.net/panama-foreign/pull/589.diff
  Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/589/head:pull/589

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

From psandoz at openjdk.java.net  Thu Sep 30 15:25:39 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Thu, 30 Sep 2021 15:25:39 GMT
Subject: [vectorIntrinsics] RFR: Merge panama-vector:master [v2]
In-Reply-To: <6xgCrexHL8ox66YqB5FTmLmiIGRekJeVndo-Yo5v5w8=.883e96df-9204-46fa-a3b5-2c624f1a2765@github.com>
References: <6xgCrexHL8ox66YqB5FTmLmiIGRekJeVndo-Yo5v5w8=.883e96df-9204-46fa-a3b5-2c624f1a2765@github.com>
Message-ID: 

> Doing another merge to ensue test configuration is up to date, thereby ensuring test infrastructure configuration is in sync.
> 
> Merge was clean. Local build and test on mac is also clean.
> 
> (Previous attempt selected the wrong base repository!)

Paul Sandoz has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 774 commits:

 - Merge branch 'master' into merge-master-to-vectorIntrinsics
 - Merge panama-vector:vectorIntrinsics+mask
   
   Reviewed-by: eliu, jbhateja
 - 8274342: AArch64: [vector] AArch64 SVE backend code cleanup
   
   Reviewed-by: njian
 - 8274331: [Vector API] Build failure on MacOS after JDK-8273949
   
   Reviewed-by: njian, jbhateja
 - Merge panama-vector:vectorIntrinsics
   
   Reviewed-by: eliu, sviswanathan
 - Merge panama-vector:master
   
   Reviewed-by: jbhateja
 - Merge panama-vector:master
   
   Reviewed-by: eliu
 - Merge panama-vector:master
   
   Reviewed-by: jbhateja, psandoz
 - 8263532: C2: Improve vector box elimination for Phi nodes
   
   Reviewed-by: psandoz
 - 8274236: Cleanups related to X86 masking support.
   
   Reviewed-by: sviswanathan
 - ... and 764 more: https://git.openjdk.java.net/panama-vector/compare/97b28742...62fbeb1e

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

Changes: https://git.openjdk.java.net/panama-vector/pull/137/files
 Webrev: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=137&range=01
  Stats: 89320 lines in 198 files changed: 83541 ins; 2093 del; 3686 mod
  Patch: https://git.openjdk.java.net/panama-vector/pull/137.diff
  Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/137/head:pull/137

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

From psandoz at openjdk.java.net  Thu Sep 30 15:25:41 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Thu, 30 Sep 2021 15:25:41 GMT
Subject: [vectorIntrinsics] Integrated: Merge panama-vector:master
In-Reply-To: <6xgCrexHL8ox66YqB5FTmLmiIGRekJeVndo-Yo5v5w8=.883e96df-9204-46fa-a3b5-2c624f1a2765@github.com>
References: <6xgCrexHL8ox66YqB5FTmLmiIGRekJeVndo-Yo5v5w8=.883e96df-9204-46fa-a3b5-2c624f1a2765@github.com>
Message-ID: 

On Wed, 29 Sep 2021 19:22:48 GMT, Paul Sandoz  wrote:

> Doing another merge to ensue test configuration is up to date, thereby ensuring test infrastructure configuration is in sync.
> 
> Merge was clean. Local build and test on mac is also clean.
> 
> (Previous attempt selected the wrong base repository!)

This pull request has now been integrated.

Changeset: 79dc88db
Author:    Paul Sandoz 
URL:       https://git.openjdk.java.net/panama-vector/commit/79dc88db8b3c8fb522771c34cfc95ab828a0ae2a
Stats:     8951 lines in 305 files changed: 6222 ins; 1560 del; 1169 mod

Merge panama-vector:master

Reviewed-by: sviswanathan, eliu, jbhateja

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

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

From psandoz at openjdk.java.net  Thu Sep 30 15:51:30 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Thu, 30 Sep 2021 15:51:30 GMT
Subject: [vectorIntrinsics] RFR: 8274533: [Vector API] Incorrect
 computation by VectorMask.toLong operation after JDK-8273949
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 30 Sep 2021 11:43:51 GMT, Jie Fu  wrote:

>> Hi Jei, 
>> I am working on an alternate patch which fixes instruction sequence in legacy storeMask patterns.
>> Will share it shortly, I think it will also address this issue, kindly review the patch once its posted.
>> 
>> Best Regards,
>> Jatin
>
>> Hi Jei, I am working on an alternate patch which fixes instruction sequence in legacy storeMask patterns. Will share it shortly, I think it will also address this issue, kindly review the patch once its posted.
>> 
>> Best Regards, Jatin
> 
> Hi @jatin-bhateja ,
> 
> This is just a small bug fix, which follows the code style of current implementation.
> Maybe you can still go on with your enhancement after this fix.
> 
> It took me hours to narrow down and fix the problem.
> Otherwise, it would be completely a waste of time to do this kind of things.
> Thanks.

@DamonFool I think Jatin is saying there is a broader architectural issue that needs to be fixed, encompassing the part you fixed. In that case i would prefer to wait and fix more broadly.

It's easy to get into these situations when we are all working diligently across various TZs. We can avoid them by better communication on the panama-dev list e.g. let's try and send quick emails identifying issues and intent of work. Alas, because of TZs, this can introduce some delay, and sometimes we need to make judgements on how fast to proceed. I will send a quick email reporting an issue Jatin is aware of and possibly related to this one.

So in this case, although i realize and appreciate your efforts, can you please place this PR on hold and give some time for Jatin submit his PR?

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

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

From paul.sandoz at oracle.com  Thu Sep 30 15:53:57 2021
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 30 Sep 2021 15:53:57 +0000
Subject: [vector] Test failing: compiler/vectorapi/VectorMaskCastTest.java.
Message-ID: <251F53CA-8496-4B71-933B-5FD4AD669086@oracle.com>

Hi,

Reporting that compiler/vectorapi/VectorMaskCastTest.java is failing on AVX512 with the options -XX:UseAVX=3 -XX:+UnlockDiagnosticVMOptions -XX:+UseKNLSetting.

I already reported this directly to Jatin.

Paul.


# JRE version: Java(TM) SE Runtime Environment (18.0+1) (fastdebug build 18-panama+1-60)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 18-panama+1-60, mixed mode, sharing, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x148375a]  Matcher::Label_Root(Node const*, State*, Node*, Node*&)+0x4ea

?

Host: XXXXXX, Intel(R) Xeon(R) Gold 6354 CPU @ 3.00GHz, 12 cores, 46G, Oracle Linux Server release 7.9
Time: Wed Sep 29 08:41:07 2021 UTC elapsed time: 2.835986 seconds (0d 0h 0m 2s)

?

Current CompileTask:
C2:   2836 1086             compiler.vectorapi.VectorMaskCastTest::testInt256ToDouble512 (27 bytes)

Stack: [0x00007fed388f9000,0x00007fed389fa000],  sp=0x00007fed389f4b60,  free space=1006k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x148375a]  Matcher::Label_Root(Node const*, State*, Node*, Node*&)+0x4ea
V  [libjvm.so+0x148387b]  Matcher::Label_Root(Node const*, State*, Node*, Node*&)+0x60b
V  [libjvm.so+0x14841ac]  Matcher::match_tree(Node const*)+0x20c
V  [libjvm.so+0x1492ff5]  Matcher::xform(Node*, int)+0xf55
V  [libjvm.so+0x149c06a]  Matcher::match()+0x490a
V  [libjvm.so+0xa7859c]  Compile::Code_Gen()+0x9c
V  [libjvm.so+0xa84d02]  Compile::Compile(ciEnv*, ciMethod*, int, bool, bool, bool, bool, bool, DirectiveSet*)+0x1652
V  [libjvm.so+0x89cca6]  C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x646
V  [libjvm.so+0xa94e89]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0xc39
V  [libjvm.so+0xa95b68]  CompileBroker::compiler_thread_loop()+0x598
V  [libjvm.so+0x191dcbc]  JavaThread::thread_main_inner()+0x27c
V  [libjvm.so+0x19242f0]  Thread::call_run()+0x100
V  [libjvm.so+0x1601f44]  thread_native_entry(Thread*)+0x104


From jbhateja at openjdk.java.net  Thu Sep 30 19:45:08 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Thu, 30 Sep 2021 19:45:08 GMT
Subject: [vectorIntrinsics] RFR: 8274533: [Vector API] Incorrect
 computation by VectorMask.toLong operation after JDK-8273949
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 30 Sep 2021 11:43:51 GMT, Jie Fu  wrote:

>> Hi Jei, 
>> I am working on an alternate patch which fixes instruction sequence in legacy storeMask patterns.
>> Will share it shortly, I think it will also address this issue, kindly review the patch once its posted.
>> 
>> Best Regards,
>> Jatin
>
>> Hi Jei, I am working on an alternate patch which fixes instruction sequence in legacy storeMask patterns. Will share it shortly, I think it will also address this issue, kindly review the patch once its posted.
>> 
>> Best Regards, Jatin
> 
> Hi @jatin-bhateja ,
> 
> This is just a small bug fix, which follows the code style of current implementation.
> Maybe you can still go on with your enhancement after this fix.
> 
> It took me hours to narrow down and fix the problem.
> Otherwise, it would be completely a waste of time to do this kind of things.
> Thanks.

Hi @DamonFool , I have created a pull request which tries to address this issues in a differ manner. 
Please take a look. 
For your current patch since its a fix in AVX2 pattern to masklen will always be less than 64 in all the cases.

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

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

From jbhateja at openjdk.java.net  Thu Sep 30 19:47:40 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Thu, 30 Sep 2021 19:47:40 GMT
Subject: [vectorIntrinsics] RFR: 8274569: X86 backend related incorrectness
 issues in legacy store mask patterns
Message-ID: 

- Issue was seen while unit testing changes for masking related optimizations on vectorIntrinsics branch.

- Following patterns result into incorrect store mask computation, even though contextually store-mask is followed by StoreVector which does takes care of various vector sizes. But C2 does emit VectorStoreMask in IR to populate a byte vector. 

  - instruct storeMask2B
  - instruct storeMask4B
  - instruct storeMask8B
  - instruct storeMask8B_avx

- Replicate with immI operand is correctly taking care of shorter vector lengths thus it can be fall back case for following pattern with immediate -1 argument. 
  - instruct ReplI_M1
  
Patch also adds a test case which exhaustively coves load/store vector masks operations for different SPECIES.

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

Commit messages:
 - 8274569: X86 backend related incorrectness issues in legacy storemask patterns

Changes: https://git.openjdk.java.net/panama-vector/pull/139/files
 Webrev: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=139&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274569
  Stats: 259 lines in 2 files changed: 241 ins; 0 del; 18 mod
  Patch: https://git.openjdk.java.net/panama-vector/pull/139.diff
  Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/139/head:pull/139

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

From jiefu at openjdk.java.net  Thu Sep 30 23:24:00 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Thu, 30 Sep 2021 23:24:00 GMT
Subject: [vectorIntrinsics] RFR: 8274533: [Vector API] Incorrect
 computation by VectorMask.toLong operation after JDK-8273949
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Thu, 30 Sep 2021 15:49:08 GMT, Paul Sandoz  wrote:

> So in this case, although i realize and appreciate your efforts, can you please place this PR on hold and give some time for Jatin submit his PR?

Done.
Thanks.

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

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

From jiefu at openjdk.java.net  Thu Sep 30 23:24:02 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Thu, 30 Sep 2021 23:24:02 GMT
Subject: [vectorIntrinsics] Withdrawn: 8274533: [Vector API] Incorrect
 computation by VectorMask.toLong operation after JDK-8273949
In-Reply-To: 
References: 
Message-ID: 

On Thu, 30 Sep 2021 04:57:09 GMT, Jie Fu  wrote:

> Hi all,
> 
> Please review this small fix which fixes the incorrect result by VectorMask.toLong after JDK-8273949.
> 
> Thanks.
> Best regards,
> Jie

This pull request has been closed without being integrated.

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

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