From haosun at openjdk.org Fri Jul 1 10:46:17 2022 From: haosun at openjdk.org (Hao Sun) Date: Fri, 1 Jul 2022 10:46:17 GMT Subject: RFR: 8285790: AArch64: Merge C2 NEON and SVE matching rules Message-ID: **MOTIVATION** This is a big refactoring patch of merging rules in aarch64_sve.ad and aarch64_neon.ad. The motivation can also be found at [1]. Currently AArch64 has aarch64_sve.ad and aarch64_neon.ad to support SVE and NEON codegen respectively. 1) For SVE rules we use vReg operand to match VecA for an arbitrary length of vector type, when SVE is enabled; 2) For NEON rules we use vecX/vecD operands to match VecX/VecD for 128-bit/64-bit vectors, when SVE is not enabled. This separation looked clean at the time of introducing SVE support. However, there are two main drawbacks now. **Drawback-1**: NEON (Advanced SIMD) is the mandatory feature on AArch64 and SVE vector registers share the lower 128 bits with NEON registers. For some cases, even when SVE is enabled, we still prefer to match NEON rules and emit NEON instructions. **Drawback-2**: With more and more vector rules added to support VectorAPI, there are lots of rules in both two ad files with different predication conditions, e.g., different values of UseSVE or vector type/size. Examples can be found in [1]. These two drawbacks make the code less maintainable and increase the libjvm.so code size. **KEY UPDATES** In this patch, we mainly do two things, using generic vReg to match all NEON/SVE vector registers and merging NEON/SVE matching rules. - Update-1: Use generic vReg to match all NEON/SVE vector registers Two different approaches were considered, and we prefer to use generic vector solution but keep VecA operand for all >128-bit vectors. See the last slide in [1]. All the changes lie in the AArch64 backend. 1) Some helpers are updated in aarch64.ad to enable generic vector on AArch64. See vector_ideal_reg(), pd_specialize_generic_vector_operand(), is_reg2reg_move() and is_generic_vector(). 2) Operand vecA is created to match VecA register, and vReg is updated to match VecA/D/X registers dynamically. With the introduction of generic vReg, difference in register types between NEON rules and SVE rules can be eliminated, which makes it easy to merge these rules. - Update-2: Try to merge existing rules As updated in GensrcAdlc.gmk, new ad file, aarch64_vector.ad, is introduced to hold the grouped and merged matching rules. 1) Similar rules with difference in vector type/size can be merged into new rules, where different types and vector sizes are handled in the codegen part, e.g., vadd(). This resolves **Drawback-2**. 2) In most cases, we tend to emit NEON instructions for 128-bit vector operations on SVE platforms, e.g., vadd(). This resolves **Drawback-1**. It's important to note that there are some exceptions. Exception-1: For some rules, there are no direct NEON instructions, but exists simple SVE implementation due to newly added SVE ISA. Such rules include vloadconB, vmulL_neon, vminL_neon, vmaxL_neon, reduce_addF_le128b (4F case), reduce_and/or/xor_neon, reduce_minL_neon, reduce_maxL_neon, vcvtLtoF_neon, vcvtDtoI_neon, rearrange_HS_neon. Exception-2: Vector mask generation and operation rules are different because vector mask is stored in different types of registers between NEON and SVE, e.g., vmaskcmp_neon and vmask_truecount_neon rules. Exception-3: Shift right related rules are different because vector shift right instructions differ a bit between NEON and SVE. For these exceptions, we emit NEON or SVE code simply based on UseSVE options. **MINOR UPDATES and CODE REFACTORING** Since we've touched all lines of code during merging rules, we further do more minor updates and refactoring. - Reduce regmask bits Stack slot alignment is handled specially for scalable vector, which will firstly align to SlotsPerVecA, and then align to the real vector length. We should guarantee SlotsPerVecA is no bigger than the real vector length. Otherwise, unused stack space would be allocated. In AArch64 SVE, the vector length can be 128 to 2048 bits. However, SlotsPerVecA is currently set as 8, i.e. 8 * 32 = 256 bits. As a result, on a 128-bit SVE platform, the stack slot is aligned to 256 bits, leaving the half 128 bits unused. In this patch, we reduce SlotsPerVecA from 8 to 4. See the updates in register_aarch64.hpp, regmask.hpp and aarch64.ad (chunk1 and vectora_reg). - Refactor NEON/SVE vector op support check. Merge NEON and SVE vector supported check into one single function. To be consistent, SVE default size supported check now is relaxed from no less than 64 bits to the same condition as NEON's min_vector_size(), i.e. 4 bytes and 4/2 booleans are also supported. This should be fine, as we assume at least we will emit NEON code for those small vectors, with unified rules. - Some notes for new rules 1) Since new rules are unique and it makes no sense to set different "ins_cost", we turn to use the default cost. 2) By default we use "pipe_slow" for matching rules in aarch64_vector.ad now. Hence, many SIMD pipeline classes at aarch64.ad become unused and can be removed. 3) Suffixes '_le128b/_gt128b' and '_neon/_sve' are appended in the matching rule names if needed. a) 'le128b' means the vector length is less than or equal to 128 bits. This rule can be matched on both NEON and 128-bit SVE. b) 'gt128b' means the vector length is greater than 128 bits. This rule can only be matched on SVE. c) 'neon' means this rule can only be matched on NEON, i.e. the generated instruction is not better than those in 128-bit SVE. d) 'sve' means this rule is only matched on SVE for all possible vector length, i.e. not limited to gt128b. Note-1: m4 file is not introduced because many duplications are highly reduced now. Note-2: We guess the code review for this big patch would probably take some time and we may need to merge latest code from master branch from time to time. We prefer to keep aarch64_neon/sve.ad and the corresponding m4 files for easy comparison and review. Of course, they will be finally removed after some solid reviews before integration. Note-3: Several other minor refactorings are done in this patch, but we cannot list all of them in the commit message. We have reviewed and tested the rules carefully to guarantee the quality. **TESTING** 1) Cross compilations on arm32/s390/pps/riscv passed. 2) tier1~3 jtreg passed on both x64 and aarch64 machines. 3) vector tests: all the test cases under the following directories can pass on both NEON and SVE systems with max vector length 16/32/64 bytes. "test/hotspot/jtreg/compiler/vectorapi/" "test/jdk/jdk/incubator/vector/" "test/hotspot/jtreg/compiler/vectorization/" 4) Performance evaluation: we choose vector micro-benchmarks from panama-vector:vectorIntrinsics [2] to evaluate the performance of this patch. We've tested *MaxVectorTests.java cases on one 128-bit SVE platform and one NEON platform, and didn't see any visiable regression with NEON and SVE. We will continue to verify more cases on other platforms with NEON and different SVE vector sizes. **BENEFITS** The number of matching rules is reduced to ~ **42%**. before: 373 (aarch64_neon.ad) + 380 (aarch64_sve.ad) = 753 after : 313 (aarch64_vector.ad) Code size for libjvm.so (release build) on aarch64 is reduced to ~ **96%**. before: 25246528 B (commit 7905788e969) after : 24208776 B (**nearly 1 MB reduction**) [1] http://cr.openjdk.java.net/~njian/8285790/JDK-8285790.pdf [2] https://github.com/openjdk/panama-vector/tree/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation Co-Developed-by: Ningsheng Jian Co-Developed-by: Eric Liu ------------- Commit messages: - 8285790: AArch64: Merge C2 NEON and SVE matching rules Changes: https://git.openjdk.org/jdk/pull/9346/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9346&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8285790 Stats: 7151 lines in 12 files changed: 6454 ins; 576 del; 121 mod Patch: https://git.openjdk.org/jdk/pull/9346.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9346/head:pull/9346 PR: https://git.openjdk.org/jdk/pull/9346 From aph at openjdk.org Fri Jul 1 11:29:42 2022 From: aph at openjdk.org (Andrew Haley) Date: Fri, 1 Jul 2022 11:29:42 GMT Subject: RFR: 8285790: AArch64: Merge C2 NEON and SVE matching rules In-Reply-To: References: Message-ID: <_l-poEFY80LRmKZyRhpxvSohm6nLv_ruaO1_WzKmTlQ=.9faff21d-d67c-42e0-8de7-be2ca9397b88@github.com> On Fri, 1 Jul 2022 10:36:36 GMT, Hao Sun wrote: > **MOTIVATION** > > This is a big refactoring patch of merging rules in aarch64_sve.ad and > aarch64_neon.ad. The motivation can also be found at [1]. > > Currently AArch64 has aarch64_sve.ad and aarch64_neon.ad to support SVE > and NEON codegen respectively. 1) For SVE rules we use vReg operand to > match VecA for an arbitrary length of vector type, when SVE is enabled; > 2) For NEON rules we use vecX/vecD operands to match VecX/VecD for > 128-bit/64-bit vectors, when SVE is not enabled. > > This separation looked clean at the time of introducing SVE support. > However, there are two main drawbacks now. > > **Drawback-1**: NEON (Advanced SIMD) is the mandatory feature on AArch64 and > SVE vector registers share the lower 128 bits with NEON registers. For > some cases, even when SVE is enabled, we still prefer to match NEON > rules and emit NEON instructions. > > **Drawback-2**: With more and more vector rules added to support VectorAPI, > there are lots of rules in both two ad files with different predication > conditions, e.g., different values of UseSVE or vector type/size. > > Examples can be found in [1]. These two drawbacks make the code less > maintainable and increase the libjvm.so code size. > > **KEY UPDATES** > > In this patch, we mainly do two things, using generic vReg to match all > NEON/SVE vector registers and merging NEON/SVE matching rules. > > - Update-1: Use generic vReg to match all NEON/SVE vector registers > > Two different approaches were considered, and we prefer to use generic > vector solution but keep VecA operand for all >128-bit vectors. See the > last slide in [1]. All the changes lie in the AArch64 backend. > > 1) Some helpers are updated in aarch64.ad to enable generic vector on > AArch64. See vector_ideal_reg(), pd_specialize_generic_vector_operand(), > is_reg2reg_move() and is_generic_vector(). > > 2) Operand vecA is created to match VecA register, and vReg is updated > to match VecA/D/X registers dynamically. > > With the introduction of generic vReg, difference in register types > between NEON rules and SVE rules can be eliminated, which makes it easy > to merge these rules. > > - Update-2: Try to merge existing rules > > As updated in GensrcAdlc.gmk, new ad file, aarch64_vector.ad, is > introduced to hold the grouped and merged matching rules. > > 1) Similar rules with difference in vector type/size can be merged into > new rules, where different types and vector sizes are handled in the > codegen part, e.g., vadd(). This resolves **Drawback-2**. > > 2) In most cases, we tend to emit NEON instructions for 128-bit vector > operations on SVE platforms, e.g., vadd(). This resolves **Drawback-1**. > > It's important to note that there are some exceptions. > > Exception-1: For some rules, there are no direct NEON instructions, but > exists simple SVE implementation due to newly added SVE ISA. Such rules > include vloadconB, vmulL_neon, vminL_neon, vmaxL_neon, > reduce_addF_le128b (4F case), reduce_and/or/xor_neon, reduce_minL_neon, > reduce_maxL_neon, vcvtLtoF_neon, vcvtDtoI_neon, rearrange_HS_neon. > > Exception-2: Vector mask generation and operation rules are different > because vector mask is stored in different types of registers between > NEON and SVE, e.g., vmaskcmp_neon and vmask_truecount_neon rules. > > Exception-3: Shift right related rules are different because vector > shift right instructions differ a bit between NEON and SVE. > > For these exceptions, we emit NEON or SVE code simply based on UseSVE > options. > > **MINOR UPDATES and CODE REFACTORING** > > Since we've touched all lines of code during merging rules, we further > do more minor updates and refactoring. > > - Reduce regmask bits > > Stack slot alignment is handled specially for scalable vector, which > will firstly align to SlotsPerVecA, and then align to the real vector > length. We should guarantee SlotsPerVecA is no bigger than the real > vector length. Otherwise, unused stack space would be allocated. > > In AArch64 SVE, the vector length can be 128 to 2048 bits. However, > SlotsPerVecA is currently set as 8, i.e. 8 * 32 = 256 bits. As a result, > on a 128-bit SVE platform, the stack slot is aligned to 256 bits, > leaving the half 128 bits unused. In this patch, we reduce SlotsPerVecA > from 8 to 4. > > See the updates in register_aarch64.hpp, regmask.hpp and aarch64.ad > (chunk1 and vectora_reg). > > - Refactor NEON/SVE vector op support check. > > Merge NEON and SVE vector supported check into one single function. To > be consistent, SVE default size supported check now is relaxed from no > less than 64 bits to the same condition as NEON's min_vector_size(), > i.e. 4 bytes and 4/2 booleans are also supported. This should be fine, > as we assume at least we will emit NEON code for those small vectors, > with unified rules. > > - Some notes for new rules > > 1) Since new rules are unique and it makes no sense to set different > "ins_cost", we turn to use the default cost. > > 2) By default we use "pipe_slow" for matching rules in aarch64_vector.ad > now. Hence, many SIMD pipeline classes at aarch64.ad become unused and > can be removed. > > 3) Suffixes '_le128b/_gt128b' and '_neon/_sve' are appended in the > matching rule names if needed. > a) 'le128b' means the vector length is less than or equal to 128 bits. > This rule can be matched on both NEON and 128-bit SVE. > b) 'gt128b' means the vector length is greater than 128 bits. This rule > can only be matched on SVE. > c) 'neon' means this rule can only be matched on NEON, i.e. the > generated instruction is not better than those in 128-bit SVE. > d) 'sve' means this rule is only matched on SVE for all possible vector > length, i.e. not limited to gt128b. > > Note-1: m4 file is not introduced because many duplications are highly > reduced now. > Note-2: We guess the code review for this big patch would probably take > some time and we may need to merge latest code from master branch from > time to time. We prefer to keep aarch64_neon/sve.ad and the > corresponding m4 files for easy comparison and review. Of course, they > will be finally removed after some solid reviews before integration. > Note-3: Several other minor refactorings are done in this patch, but we > cannot list all of them in the commit message. We have reviewed and > tested the rules carefully to guarantee the quality. > > **TESTING** > > 1) Cross compilations on arm32/s390/pps/riscv passed. > 2) tier1~3 jtreg passed on both x64 and aarch64 machines. > 3) vector tests: all the test cases under the following directories can > pass on both NEON and SVE systems with max vector length 16/32/64 bytes. > > "test/hotspot/jtreg/compiler/vectorapi/" > "test/jdk/jdk/incubator/vector/" > "test/hotspot/jtreg/compiler/vectorization/" > > 4) Performance evaluation: we choose vector micro-benchmarks from > panama-vector:vectorIntrinsics [2] to evaluate the performance of this > patch. We've tested *MaxVectorTests.java cases on one 128-bit SVE > platform and one NEON platform, and didn't see any visiable regression > with NEON and SVE. We will continue to verify more cases on other > platforms with NEON and different SVE vector sizes. > > **BENEFITS** > > The number of matching rules is reduced to ~ **42%**. > before: 373 (aarch64_neon.ad) + 380 (aarch64_sve.ad) = 753 > after : 313 (aarch64_vector.ad) > > Code size for libjvm.so (release build) on aarch64 is reduced to ~ **96%**. > before: 25246528 B (commit 7905788e969) > after : 24208776 B (**nearly 1 MB reduction**) > > [1] http://cr.openjdk.java.net/~njian/8285790/JDK-8285790.pdf > [2] https://github.com/openjdk/panama-vector/tree/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation > > Co-Developed-by: Ningsheng Jian > Co-Developed-by: Eric Liu Aha! I was looking forward to this. On 7/1/22 11:46, Hao Sun wrote: > Note-1: m4 file is not introduced because many duplications are highly > reduced now. Yes, but there's still a lot of duplications. I'll make a few examples of where you should make simple changes that will usefully increase the level of abstraction. That will be a start. ------------- PR: https://git.openjdk.org/jdk/pull/9346 From duke at openjdk.org Fri Jul 1 17:31:46 2022 From: duke at openjdk.org (Nikita Gubarkov) Date: Fri, 1 Jul 2022 17:31:46 GMT Subject: RFR: 8289189: Configure fails on WSL1 In-Reply-To: <5b5npslmm6Hmf6rRtQvHy6Q6HLwIRv0Bdf9j5PNawUc=.df61881a-1df1-4d71-bc21-8dae9d82586a@github.com> References: <5b5npslmm6Hmf6rRtQvHy6Q6HLwIRv0Bdf9j5PNawUc=.df61881a-1df1-4d71-bc21-8dae9d82586a@github.com> Message-ID: On Sun, 26 Jun 2022 12:31:22 GMT, Nikita Gubarkov wrote: > Use temp directory for autoconf on both WSL1 and WSL2 For me it fails since [this commit](https://github.com/JetBrains/JetBrainsRuntime/commit/2d4af2255feb2eaeca533424f8cba3ec0945d757). Turned out earlier it incorrectly defined my environment as wsl2, though I was building on wsl1, but everything worked fine. And then it started failing when defining my environment as wsl1. I don't fully understand why it fails, it successfully builds conftest.exe, then runs and it exits with 139 code (SIGSEGV). I couldn't reproduce it manually, but it fails every time in configure script. And though it's 100% reproducible for me, my colleagues weren't able to reproduce it. Given that I don't know why this helps, I just took the codepath which worked for me before. Anyway this patch shouldn't break anything, as it just makes WSL1 use %TEMP% instead of current working directory which are both on Windows FS. At least on those machines where this issue wasn't reproducible, it still works with this fix. ------------- PR: https://git.openjdk.org/jdk/pull/9289 From ysuenaga at openjdk.org Sat Jul 2 07:09:26 2022 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Sat, 2 Jul 2022 07:09:26 GMT Subject: RFR: 8289189: Configure fails on WSL1 In-Reply-To: References: <5b5npslmm6Hmf6rRtQvHy6Q6HLwIRv0Bdf9j5PNawUc=.df61881a-1df1-4d71-bc21-8dae9d82586a@github.com> Message-ID: On Fri, 1 Jul 2022 17:27:49 GMT, Nikita Gubarkov wrote: > I don't fully understand why it fails, it successfully builds conftest.exe, then runs and it exits with 139 code (SIGSEGV). I couldn't reproduce it manually, but it fails every time in configure script. And though it's 100% reproducible for me, my colleagues weren't able to reproduce it. I've seen same error on my WSL 1, but I think it is not a bug in OpenJDK. Did you get strace from configure script? AFAICS it seems to be caused by WSL kernel, and [I've reported it to WSL community](https://github.com/microsoft/WSL/issues/8388). ------------- PR: https://git.openjdk.org/jdk/pull/9289 From duke at openjdk.org Sun Jul 3 11:40:33 2022 From: duke at openjdk.org (Nikita Gubarkov) Date: Sun, 3 Jul 2022 11:40:33 GMT Subject: RFR: 8289189: Configure fails on WSL1 In-Reply-To: <5b5npslmm6Hmf6rRtQvHy6Q6HLwIRv0Bdf9j5PNawUc=.df61881a-1df1-4d71-bc21-8dae9d82586a@github.com> References: <5b5npslmm6Hmf6rRtQvHy6Q6HLwIRv0Bdf9j5PNawUc=.df61881a-1df1-4d71-bc21-8dae9d82586a@github.com> Message-ID: On Sun, 26 Jun 2022 12:31:22 GMT, Nikita Gubarkov wrote: > Use temp directory for autoconf on both WSL1 and WSL2 Here's the [strace log](https://github.com/openjdk/jdk/files/9034638/strace.log). ------------- PR: https://git.openjdk.org/jdk/pull/9289 From ysuenaga at openjdk.org Sun Jul 3 14:32:42 2022 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Sun, 3 Jul 2022 14:32:42 GMT Subject: RFR: 8289189: Configure fails on WSL1 In-Reply-To: <5b5npslmm6Hmf6rRtQvHy6Q6HLwIRv0Bdf9j5PNawUc=.df61881a-1df1-4d71-bc21-8dae9d82586a@github.com> References: <5b5npslmm6Hmf6rRtQvHy6Q6HLwIRv0Bdf9j5PNawUc=.df61881a-1df1-4d71-bc21-8dae9d82586a@github.com> Message-ID: On Sun, 26 Jun 2022 12:31:22 GMT, Nikita Gubarkov wrote: > Use temp directory for autoconf on both WSL1 and WSL2 --- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=NULL} --- +++ killed by SIGSEGV (core dumped) +++ I think it is a bug in WSL kernel because this SEGV is SI_KERNEL. It looks like same issue which I reported WSL community, and it seems not to be a bug in OpenJDK. ------------- PR: https://git.openjdk.org/jdk/pull/9289 From duke at openjdk.org Sun Jul 3 15:01:31 2022 From: duke at openjdk.org (Nikita Gubarkov) Date: Sun, 3 Jul 2022 15:01:31 GMT Subject: RFR: 8289189: Configure fails on WSL1 In-Reply-To: <5b5npslmm6Hmf6rRtQvHy6Q6HLwIRv0Bdf9j5PNawUc=.df61881a-1df1-4d71-bc21-8dae9d82586a@github.com> References: <5b5npslmm6Hmf6rRtQvHy6Q6HLwIRv0Bdf9j5PNawUc=.df61881a-1df1-4d71-bc21-8dae9d82586a@github.com> Message-ID: On Sun, 26 Jun 2022 12:31:22 GMT, Nikita Gubarkov wrote: > Use temp directory for autoconf on both WSL1 and WSL2 Yes, it looks the same. And if the same issue is reproducible for you, can you try this patch and see if it fixes the crash, please? I mean it would still be useful to integrate this patch as a workaround if it does work not only for me, what do you think? ------------- PR: https://git.openjdk.org/jdk/pull/9289 From ysuenaga at openjdk.org Sun Jul 3 15:24:43 2022 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Sun, 3 Jul 2022 15:24:43 GMT Subject: RFR: 8289189: Configure fails on WSL1 In-Reply-To: <5b5npslmm6Hmf6rRtQvHy6Q6HLwIRv0Bdf9j5PNawUc=.df61881a-1df1-4d71-bc21-8dae9d82586a@github.com> References: <5b5npslmm6Hmf6rRtQvHy6Q6HLwIRv0Bdf9j5PNawUc=.df61881a-1df1-4d71-bc21-8dae9d82586a@github.com> Message-ID: On Sun, 26 Jun 2022 12:31:22 GMT, Nikita Gubarkov wrote: > Use temp directory for autoconf on both WSL1 and WSL2 If your patch fixes the problem, SEGV will happen in build stage (I saw the crash in cl.exe calls from makefile.) I think WSL 2 is the only workaround. You should use Cygwin if you do not want to use WSL 2. ------------- PR: https://git.openjdk.org/jdk/pull/9289 From duke at openjdk.org Sun Jul 3 15:32:42 2022 From: duke at openjdk.org (Nikita Gubarkov) Date: Sun, 3 Jul 2022 15:32:42 GMT Subject: RFR: 8289189: Configure fails on WSL1 In-Reply-To: <5b5npslmm6Hmf6rRtQvHy6Q6HLwIRv0Bdf9j5PNawUc=.df61881a-1df1-4d71-bc21-8dae9d82586a@github.com> References: <5b5npslmm6Hmf6rRtQvHy6Q6HLwIRv0Bdf9j5PNawUc=.df61881a-1df1-4d71-bc21-8dae9d82586a@github.com> Message-ID: <1NRqgK2o9U-Kt7_9X-tU0lUyHbumsdy-bNpohsv5DZE=.9a40c959-36e7-438b-8790-b93d0a26170a@github.com> On Sun, 26 Jun 2022 12:31:22 GMT, Nikita Gubarkov wrote: > Use temp directory for autoconf on both WSL1 and WSL2 But I did actually build the JDK with this fix, that worked for me. ------------- PR: https://git.openjdk.org/jdk/pull/9289 From ysuenaga at openjdk.org Sun Jul 3 15:47:30 2022 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Sun, 3 Jul 2022 15:47:30 GMT Subject: RFR: 8289189: Configure fails on WSL1 In-Reply-To: <5b5npslmm6Hmf6rRtQvHy6Q6HLwIRv0Bdf9j5PNawUc=.df61881a-1df1-4d71-bc21-8dae9d82586a@github.com> References: <5b5npslmm6Hmf6rRtQvHy6Q6HLwIRv0Bdf9j5PNawUc=.df61881a-1df1-4d71-bc21-8dae9d82586a@github.com> Message-ID: On Sun, 26 Jun 2022 12:31:22 GMT, Nikita Gubarkov wrote: > Use temp directory for autoconf on both WSL1 and WSL2 In my case, SEGV in configure script happened on Ryzen 3300X. OTOH it did not happen on Intel Core i3 (Whiskey Lake) , but SEGV happened in build stage as I said before. Your parch will avoid the crash in configure script, but I think it is not enough for building OpenJDK. Your strace log shows the SEGV comes from the WSL kernel, so I want to know your patch can avoid the problem in point of WSL 1. ------------- PR: https://git.openjdk.org/jdk/pull/9289 From haosun at openjdk.org Mon Jul 4 02:21:37 2022 From: haosun at openjdk.org (Hao Sun) Date: Mon, 4 Jul 2022 02:21:37 GMT Subject: RFR: 8285790: AArch64: Merge C2 NEON and SVE matching rules In-Reply-To: References: Message-ID: <4X_4L9tRljWUlHEpiHyrwX3GT59XrU6RpNzX2wF7nYs=.a65e9076-b0ae-407f-9961-b945808becd9@github.com> On Fri, 1 Jul 2022 10:36:36 GMT, Hao Sun wrote: > **MOTIVATION** > > This is a big refactoring patch of merging rules in aarch64_sve.ad and > aarch64_neon.ad. The motivation can also be found at [1]. > > Currently AArch64 has aarch64_sve.ad and aarch64_neon.ad to support SVE > and NEON codegen respectively. 1) For SVE rules we use vReg operand to > match VecA for an arbitrary length of vector type, when SVE is enabled; > 2) For NEON rules we use vecX/vecD operands to match VecX/VecD for > 128-bit/64-bit vectors, when SVE is not enabled. > > This separation looked clean at the time of introducing SVE support. > However, there are two main drawbacks now. > > **Drawback-1**: NEON (Advanced SIMD) is the mandatory feature on AArch64 and > SVE vector registers share the lower 128 bits with NEON registers. For > some cases, even when SVE is enabled, we still prefer to match NEON > rules and emit NEON instructions. > > **Drawback-2**: With more and more vector rules added to support VectorAPI, > there are lots of rules in both two ad files with different predication > conditions, e.g., different values of UseSVE or vector type/size. > > Examples can be found in [1]. These two drawbacks make the code less > maintainable and increase the libjvm.so code size. > > **KEY UPDATES** > > In this patch, we mainly do two things, using generic vReg to match all > NEON/SVE vector registers and merging NEON/SVE matching rules. > > - Update-1: Use generic vReg to match all NEON/SVE vector registers > > Two different approaches were considered, and we prefer to use generic > vector solution but keep VecA operand for all >128-bit vectors. See the > last slide in [1]. All the changes lie in the AArch64 backend. > > 1) Some helpers are updated in aarch64.ad to enable generic vector on > AArch64. See vector_ideal_reg(), pd_specialize_generic_vector_operand(), > is_reg2reg_move() and is_generic_vector(). > > 2) Operand vecA is created to match VecA register, and vReg is updated > to match VecA/D/X registers dynamically. > > With the introduction of generic vReg, difference in register types > between NEON rules and SVE rules can be eliminated, which makes it easy > to merge these rules. > > - Update-2: Try to merge existing rules > > As updated in GensrcAdlc.gmk, new ad file, aarch64_vector.ad, is > introduced to hold the grouped and merged matching rules. > > 1) Similar rules with difference in vector type/size can be merged into > new rules, where different types and vector sizes are handled in the > codegen part, e.g., vadd(). This resolves **Drawback-2**. > > 2) In most cases, we tend to emit NEON instructions for 128-bit vector > operations on SVE platforms, e.g., vadd(). This resolves **Drawback-1**. > > It's important to note that there are some exceptions. > > Exception-1: For some rules, there are no direct NEON instructions, but > exists simple SVE implementation due to newly added SVE ISA. Such rules > include vloadconB, vmulL_neon, vminL_neon, vmaxL_neon, > reduce_addF_le128b (4F case), reduce_and/or/xor_neon, reduce_minL_neon, > reduce_maxL_neon, vcvtLtoF_neon, vcvtDtoI_neon, rearrange_HS_neon. > > Exception-2: Vector mask generation and operation rules are different > because vector mask is stored in different types of registers between > NEON and SVE, e.g., vmaskcmp_neon and vmask_truecount_neon rules. > > Exception-3: Shift right related rules are different because vector > shift right instructions differ a bit between NEON and SVE. > > For these exceptions, we emit NEON or SVE code simply based on UseSVE > options. > > **MINOR UPDATES and CODE REFACTORING** > > Since we've touched all lines of code during merging rules, we further > do more minor updates and refactoring. > > - Reduce regmask bits > > Stack slot alignment is handled specially for scalable vector, which > will firstly align to SlotsPerVecA, and then align to the real vector > length. We should guarantee SlotsPerVecA is no bigger than the real > vector length. Otherwise, unused stack space would be allocated. > > In AArch64 SVE, the vector length can be 128 to 2048 bits. However, > SlotsPerVecA is currently set as 8, i.e. 8 * 32 = 256 bits. As a result, > on a 128-bit SVE platform, the stack slot is aligned to 256 bits, > leaving the half 128 bits unused. In this patch, we reduce SlotsPerVecA > from 8 to 4. > > See the updates in register_aarch64.hpp, regmask.hpp and aarch64.ad > (chunk1 and vectora_reg). > > - Refactor NEON/SVE vector op support check. > > Merge NEON and SVE vector supported check into one single function. To > be consistent, SVE default size supported check now is relaxed from no > less than 64 bits to the same condition as NEON's min_vector_size(), > i.e. 4 bytes and 4/2 booleans are also supported. This should be fine, > as we assume at least we will emit NEON code for those small vectors, > with unified rules. > > - Some notes for new rules > > 1) Since new rules are unique and it makes no sense to set different > "ins_cost", we turn to use the default cost. > > 2) By default we use "pipe_slow" for matching rules in aarch64_vector.ad > now. Hence, many SIMD pipeline classes at aarch64.ad become unused and > can be removed. > > 3) Suffixes '_le128b/_gt128b' and '_neon/_sve' are appended in the > matching rule names if needed. > a) 'le128b' means the vector length is less than or equal to 128 bits. > This rule can be matched on both NEON and 128-bit SVE. > b) 'gt128b' means the vector length is greater than 128 bits. This rule > can only be matched on SVE. > c) 'neon' means this rule can only be matched on NEON, i.e. the > generated instruction is not better than those in 128-bit SVE. > d) 'sve' means this rule is only matched on SVE for all possible vector > length, i.e. not limited to gt128b. > > Note-1: m4 file is not introduced because many duplications are highly > reduced now. > Note-2: We guess the code review for this big patch would probably take > some time and we may need to merge latest code from master branch from > time to time. We prefer to keep aarch64_neon/sve.ad and the > corresponding m4 files for easy comparison and review. Of course, they > will be finally removed after some solid reviews before integration. > Note-3: Several other minor refactorings are done in this patch, but we > cannot list all of them in the commit message. We have reviewed and > tested the rules carefully to guarantee the quality. > > **TESTING** > > 1) Cross compilations on arm32/s390/pps/riscv passed. > 2) tier1~3 jtreg passed on both x64 and aarch64 machines. > 3) vector tests: all the test cases under the following directories can > pass on both NEON and SVE systems with max vector length 16/32/64 bytes. > > "test/hotspot/jtreg/compiler/vectorapi/" > "test/jdk/jdk/incubator/vector/" > "test/hotspot/jtreg/compiler/vectorization/" > > 4) Performance evaluation: we choose vector micro-benchmarks from > panama-vector:vectorIntrinsics [2] to evaluate the performance of this > patch. We've tested *MaxVectorTests.java cases on one 128-bit SVE > platform and one NEON platform, and didn't see any visiable regression > with NEON and SVE. We will continue to verify more cases on other > platforms with NEON and different SVE vector sizes. > > **BENEFITS** > > The number of matching rules is reduced to ~ **42%**. > before: 373 (aarch64_neon.ad) + 380 (aarch64_sve.ad) = 753 > after : 313 (aarch64_vector.ad) > > Code size for libjvm.so (release build) on aarch64 is reduced to ~ **96%**. > before: 25246528 B (commit 7905788e969) > after : 24208776 B (**nearly 1 MB reduction**) > > [1] http://cr.openjdk.java.net/~njian/8285790/JDK-8285790.pdf > [2] https://github.com/openjdk/panama-vector/tree/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation > > Co-Developed-by: Ningsheng Jian > Co-Developed-by: Eric Liu We got one GHA test failure on linux-x86/tier1, with the following error log. See the [link](https://github.com/shqking/jdk/runs/7173063926?check_suite_focus=true). `Error: Unable to find an artifact with the name: bundles-linux-x86` I suppose it's **not** related to our patch. Besides, we have tested tier1~3 on linux x64/aarch64 locally. ------------- PR: https://git.openjdk.org/jdk/pull/9346 From haosun at openjdk.org Mon Jul 4 02:46:39 2022 From: haosun at openjdk.org (Hao Sun) Date: Mon, 4 Jul 2022 02:46:39 GMT Subject: RFR: 8285790: AArch64: Merge C2 NEON and SVE matching rules In-Reply-To: <_l-poEFY80LRmKZyRhpxvSohm6nLv_ruaO1_WzKmTlQ=.9faff21d-d67c-42e0-8de7-be2ca9397b88@github.com> References: <_l-poEFY80LRmKZyRhpxvSohm6nLv_ruaO1_WzKmTlQ=.9faff21d-d67c-42e0-8de7-be2ca9397b88@github.com> Message-ID: On Fri, 1 Jul 2022 11:25:36 GMT, Andrew Haley wrote: >> **MOTIVATION** >> >> This is a big refactoring patch of merging rules in aarch64_sve.ad and >> aarch64_neon.ad. The motivation can also be found at [1]. >> >> Currently AArch64 has aarch64_sve.ad and aarch64_neon.ad to support SVE >> and NEON codegen respectively. 1) For SVE rules we use vReg operand to >> match VecA for an arbitrary length of vector type, when SVE is enabled; >> 2) For NEON rules we use vecX/vecD operands to match VecX/VecD for >> 128-bit/64-bit vectors, when SVE is not enabled. >> >> This separation looked clean at the time of introducing SVE support. >> However, there are two main drawbacks now. >> >> **Drawback-1**: NEON (Advanced SIMD) is the mandatory feature on AArch64 and >> SVE vector registers share the lower 128 bits with NEON registers. For >> some cases, even when SVE is enabled, we still prefer to match NEON >> rules and emit NEON instructions. >> >> **Drawback-2**: With more and more vector rules added to support VectorAPI, >> there are lots of rules in both two ad files with different predication >> conditions, e.g., different values of UseSVE or vector type/size. >> >> Examples can be found in [1]. These two drawbacks make the code less >> maintainable and increase the libjvm.so code size. >> >> **KEY UPDATES** >> >> In this patch, we mainly do two things, using generic vReg to match all >> NEON/SVE vector registers and merging NEON/SVE matching rules. >> >> - Update-1: Use generic vReg to match all NEON/SVE vector registers >> >> Two different approaches were considered, and we prefer to use generic >> vector solution but keep VecA operand for all >128-bit vectors. See the >> last slide in [1]. All the changes lie in the AArch64 backend. >> >> 1) Some helpers are updated in aarch64.ad to enable generic vector on >> AArch64. See vector_ideal_reg(), pd_specialize_generic_vector_operand(), >> is_reg2reg_move() and is_generic_vector(). >> >> 2) Operand vecA is created to match VecA register, and vReg is updated >> to match VecA/D/X registers dynamically. >> >> With the introduction of generic vReg, difference in register types >> between NEON rules and SVE rules can be eliminated, which makes it easy >> to merge these rules. >> >> - Update-2: Try to merge existing rules >> >> As updated in GensrcAdlc.gmk, new ad file, aarch64_vector.ad, is >> introduced to hold the grouped and merged matching rules. >> >> 1) Similar rules with difference in vector type/size can be merged into >> new rules, where different types and vector sizes are handled in the >> codegen part, e.g., vadd(). This resolves **Drawback-2**. >> >> 2) In most cases, we tend to emit NEON instructions for 128-bit vector >> operations on SVE platforms, e.g., vadd(). This resolves **Drawback-1**. >> >> It's important to note that there are some exceptions. >> >> Exception-1: For some rules, there are no direct NEON instructions, but >> exists simple SVE implementation due to newly added SVE ISA. Such rules >> include vloadconB, vmulL_neon, vminL_neon, vmaxL_neon, >> reduce_addF_le128b (4F case), reduce_and/or/xor_neon, reduce_minL_neon, >> reduce_maxL_neon, vcvtLtoF_neon, vcvtDtoI_neon, rearrange_HS_neon. >> >> Exception-2: Vector mask generation and operation rules are different >> because vector mask is stored in different types of registers between >> NEON and SVE, e.g., vmaskcmp_neon and vmask_truecount_neon rules. >> >> Exception-3: Shift right related rules are different because vector >> shift right instructions differ a bit between NEON and SVE. >> >> For these exceptions, we emit NEON or SVE code simply based on UseSVE >> options. >> >> **MINOR UPDATES and CODE REFACTORING** >> >> Since we've touched all lines of code during merging rules, we further >> do more minor updates and refactoring. >> >> - Reduce regmask bits >> >> Stack slot alignment is handled specially for scalable vector, which >> will firstly align to SlotsPerVecA, and then align to the real vector >> length. We should guarantee SlotsPerVecA is no bigger than the real >> vector length. Otherwise, unused stack space would be allocated. >> >> In AArch64 SVE, the vector length can be 128 to 2048 bits. However, >> SlotsPerVecA is currently set as 8, i.e. 8 * 32 = 256 bits. As a result, >> on a 128-bit SVE platform, the stack slot is aligned to 256 bits, >> leaving the half 128 bits unused. In this patch, we reduce SlotsPerVecA >> from 8 to 4. >> >> See the updates in register_aarch64.hpp, regmask.hpp and aarch64.ad >> (chunk1 and vectora_reg). >> >> - Refactor NEON/SVE vector op support check. >> >> Merge NEON and SVE vector supported check into one single function. To >> be consistent, SVE default size supported check now is relaxed from no >> less than 64 bits to the same condition as NEON's min_vector_size(), >> i.e. 4 bytes and 4/2 booleans are also supported. This should be fine, >> as we assume at least we will emit NEON code for those small vectors, >> with unified rules. >> >> - Some notes for new rules >> >> 1) Since new rules are unique and it makes no sense to set different >> "ins_cost", we turn to use the default cost. >> >> 2) By default we use "pipe_slow" for matching rules in aarch64_vector.ad >> now. Hence, many SIMD pipeline classes at aarch64.ad become unused and >> can be removed. >> >> 3) Suffixes '_le128b/_gt128b' and '_neon/_sve' are appended in the >> matching rule names if needed. >> a) 'le128b' means the vector length is less than or equal to 128 bits. >> This rule can be matched on both NEON and 128-bit SVE. >> b) 'gt128b' means the vector length is greater than 128 bits. This rule >> can only be matched on SVE. >> c) 'neon' means this rule can only be matched on NEON, i.e. the >> generated instruction is not better than those in 128-bit SVE. >> d) 'sve' means this rule is only matched on SVE for all possible vector >> length, i.e. not limited to gt128b. >> >> Note-1: m4 file is not introduced because many duplications are highly >> reduced now. >> Note-2: We guess the code review for this big patch would probably take >> some time and we may need to merge latest code from master branch from >> time to time. We prefer to keep aarch64_neon/sve.ad and the >> corresponding m4 files for easy comparison and review. Of course, they >> will be finally removed after some solid reviews before integration. >> Note-3: Several other minor refactorings are done in this patch, but we >> cannot list all of them in the commit message. We have reviewed and >> tested the rules carefully to guarantee the quality. >> >> **TESTING** >> >> 1) Cross compilations on arm32/s390/pps/riscv passed. >> 2) tier1~3 jtreg passed on both x64 and aarch64 machines. >> 3) vector tests: all the test cases under the following directories can >> pass on both NEON and SVE systems with max vector length 16/32/64 bytes. >> >> "test/hotspot/jtreg/compiler/vectorapi/" >> "test/jdk/jdk/incubator/vector/" >> "test/hotspot/jtreg/compiler/vectorization/" >> >> 4) Performance evaluation: we choose vector micro-benchmarks from >> panama-vector:vectorIntrinsics [2] to evaluate the performance of this >> patch. We've tested *MaxVectorTests.java cases on one 128-bit SVE >> platform and one NEON platform, and didn't see any visiable regression >> with NEON and SVE. We will continue to verify more cases on other >> platforms with NEON and different SVE vector sizes. >> >> **BENEFITS** >> >> The number of matching rules is reduced to ~ **42%**. >> before: 373 (aarch64_neon.ad) + 380 (aarch64_sve.ad) = 753 >> after : 313 (aarch64_vector.ad) >> >> Code size for libjvm.so (release build) on aarch64 is reduced to ~ **96%**. >> before: 25246528 B (commit 7905788e969) >> after : 24208776 B (**nearly 1 MB reduction**) >> >> [1] http://cr.openjdk.java.net/~njian/8285790/JDK-8285790.pdf >> [2] https://github.com/openjdk/panama-vector/tree/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation >> >> Co-Developed-by: Ningsheng Jian >> Co-Developed-by: Eric Liu > > Aha! I was looking forward to this. > > On 7/1/22 11:46, Hao Sun wrote: > > Note-1: m4 file is not introduced because many duplications are highly > > reduced now. > > Yes, but there's still a lot of duplications. I'll make a few examples > of where you should make simple changes that will usefully increase the > level of abstraction. That will be a start. @theRealAph Thanks for your comment. Yes. There are still duplicate code. I can easily list several ones, such as the reduce-and/or/xor, vector shift ops and several reg with imm rules. We're open to keep m4 file. But I would suggest that we may put our attention firstly on 1) our implementation on generic vector registers and 2) the merged rules (in particular those we share the codegen for NEON only platform and 128-bit vector ops on SVE platform). After that we may discuss whether to use m4 file and how to implement it if needed. ------------- PR: https://git.openjdk.org/jdk/pull/9346 From ysuenaga at openjdk.org Mon Jul 4 04:03:37 2022 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Mon, 4 Jul 2022 04:03:37 GMT Subject: RFR: 8289189: Configure fails on WSL1 In-Reply-To: <5b5npslmm6Hmf6rRtQvHy6Q6HLwIRv0Bdf9j5PNawUc=.df61881a-1df1-4d71-bc21-8dae9d82586a@github.com> References: <5b5npslmm6Hmf6rRtQvHy6Q6HLwIRv0Bdf9j5PNawUc=.df61881a-1df1-4d71-bc21-8dae9d82586a@github.com> Message-ID: <5KsK1u43k2ThlPqC1KbpzJV2aJnptpRgn1FgLuEJEUk=.7d48cc53-9505-4ada-ba97-25bffb6fbd30@github.com> On Sun, 26 Jun 2022 12:31:22 GMT, Nikita Gubarkov wrote: > Use temp directory for autoconf on both WSL1 and WSL2 The crash has gone since WSL v0.61.4 . According to [release note](https://github.com/microsoft/WSL/releases/tag/0.61.4), it has fixed memory corruption in `WSLENV` - it works fine to me. It is worth to try it (You can update via MS store). (However wslpath spec looks like changed, and it breaks fixpath behavior. So I've sent PR for it as #9357 ) ------------- PR: https://git.openjdk.org/jdk/pull/9289 From ysuenaga at openjdk.org Mon Jul 4 06:54:03 2022 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Mon, 4 Jul 2022 06:54:03 GMT Subject: RFR: 8289646: configure script failed on WSL Message-ID: configure failed as following when I run it on WSL 1. checking for version string... 20-internal-adhoc.yasuenag.jdk configure: Found potential Boot JDK using configure arguments configure: The command for java_to_test, which resolves as "/mnt/d/java/jdk-18/bin/java", can not be found. configure: error: Cannot locate /mnt/d/java/jdk-18/bin/java configure exiting with result code 1 fixpath.sh would attempt to add ".exe" (e.g. "java" -> "java.exe") if `wslpath -w" failed (returns non-zero value). However it returns zero even if the path does not exist in recent WSL (v0.61.4 at least). WSL v0.60.0.0 $ wslpath -w silver-bullet wslpath: silver-bullet: No such file or directory $ echo $? 1 WSL v0.61.4.0 $ wslpath -w silver-bullet silver-bullet $ echo $? 0 We should add ".exe" at the tail of path regardless of return value from wslpath. ------------- Commit messages: - 8289646: configure script failed on WSL Changes: https://git.openjdk.org/jdk/pull/9357/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9357&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289646 Stats: 19 lines in 1 file changed: 2 ins; 10 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/9357.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9357/head:pull/9357 PR: https://git.openjdk.org/jdk/pull/9357 From aph at openjdk.org Mon Jul 4 12:54:43 2022 From: aph at openjdk.org (Andrew Haley) Date: Mon, 4 Jul 2022 12:54:43 GMT Subject: RFR: 8285790: AArch64: Merge C2 NEON and SVE matching rules In-Reply-To: <_l-poEFY80LRmKZyRhpxvSohm6nLv_ruaO1_WzKmTlQ=.9faff21d-d67c-42e0-8de7-be2ca9397b88@github.com> References: <_l-poEFY80LRmKZyRhpxvSohm6nLv_ruaO1_WzKmTlQ=.9faff21d-d67c-42e0-8de7-be2ca9397b88@github.com> Message-ID: <_ZcvC_kGQPJuD-WAwAocrGLlbHEF66ww-FgDhUl6av4=.06b039a0-ed2c-42cb-9e1e-c8f32c712789@github.com> On Fri, 1 Jul 2022 11:25:36 GMT, Andrew Haley wrote: >> **MOTIVATION** >> >> This is a big refactoring patch of merging rules in aarch64_sve.ad and >> aarch64_neon.ad. The motivation can also be found at [1]. >> >> Currently AArch64 has aarch64_sve.ad and aarch64_neon.ad to support SVE >> and NEON codegen respectively. 1) For SVE rules we use vReg operand to >> match VecA for an arbitrary length of vector type, when SVE is enabled; >> 2) For NEON rules we use vecX/vecD operands to match VecX/VecD for >> 128-bit/64-bit vectors, when SVE is not enabled. >> >> This separation looked clean at the time of introducing SVE support. >> However, there are two main drawbacks now. >> >> **Drawback-1**: NEON (Advanced SIMD) is the mandatory feature on AArch64 and >> SVE vector registers share the lower 128 bits with NEON registers. For >> some cases, even when SVE is enabled, we still prefer to match NEON >> rules and emit NEON instructions. >> >> **Drawback-2**: With more and more vector rules added to support VectorAPI, >> there are lots of rules in both two ad files with different predication >> conditions, e.g., different values of UseSVE or vector type/size. >> >> Examples can be found in [1]. These two drawbacks make the code less >> maintainable and increase the libjvm.so code size. >> >> **KEY UPDATES** >> >> In this patch, we mainly do two things, using generic vReg to match all >> NEON/SVE vector registers and merging NEON/SVE matching rules. >> >> - Update-1: Use generic vReg to match all NEON/SVE vector registers >> >> Two different approaches were considered, and we prefer to use generic >> vector solution but keep VecA operand for all >128-bit vectors. See the >> last slide in [1]. All the changes lie in the AArch64 backend. >> >> 1) Some helpers are updated in aarch64.ad to enable generic vector on >> AArch64. See vector_ideal_reg(), pd_specialize_generic_vector_operand(), >> is_reg2reg_move() and is_generic_vector(). >> >> 2) Operand vecA is created to match VecA register, and vReg is updated >> to match VecA/D/X registers dynamically. >> >> With the introduction of generic vReg, difference in register types >> between NEON rules and SVE rules can be eliminated, which makes it easy >> to merge these rules. >> >> - Update-2: Try to merge existing rules >> >> As updated in GensrcAdlc.gmk, new ad file, aarch64_vector.ad, is >> introduced to hold the grouped and merged matching rules. >> >> 1) Similar rules with difference in vector type/size can be merged into >> new rules, where different types and vector sizes are handled in the >> codegen part, e.g., vadd(). This resolves **Drawback-2**. >> >> 2) In most cases, we tend to emit NEON instructions for 128-bit vector >> operations on SVE platforms, e.g., vadd(). This resolves **Drawback-1**. >> >> It's important to note that there are some exceptions. >> >> Exception-1: For some rules, there are no direct NEON instructions, but >> exists simple SVE implementation due to newly added SVE ISA. Such rules >> include vloadconB, vmulL_neon, vminL_neon, vmaxL_neon, >> reduce_addF_le128b (4F case), reduce_and/or/xor_neon, reduce_minL_neon, >> reduce_maxL_neon, vcvtLtoF_neon, vcvtDtoI_neon, rearrange_HS_neon. >> >> Exception-2: Vector mask generation and operation rules are different >> because vector mask is stored in different types of registers between >> NEON and SVE, e.g., vmaskcmp_neon and vmask_truecount_neon rules. >> >> Exception-3: Shift right related rules are different because vector >> shift right instructions differ a bit between NEON and SVE. >> >> For these exceptions, we emit NEON or SVE code simply based on UseSVE >> options. >> >> **MINOR UPDATES and CODE REFACTORING** >> >> Since we've touched all lines of code during merging rules, we further >> do more minor updates and refactoring. >> >> - Reduce regmask bits >> >> Stack slot alignment is handled specially for scalable vector, which >> will firstly align to SlotsPerVecA, and then align to the real vector >> length. We should guarantee SlotsPerVecA is no bigger than the real >> vector length. Otherwise, unused stack space would be allocated. >> >> In AArch64 SVE, the vector length can be 128 to 2048 bits. However, >> SlotsPerVecA is currently set as 8, i.e. 8 * 32 = 256 bits. As a result, >> on a 128-bit SVE platform, the stack slot is aligned to 256 bits, >> leaving the half 128 bits unused. In this patch, we reduce SlotsPerVecA >> from 8 to 4. >> >> See the updates in register_aarch64.hpp, regmask.hpp and aarch64.ad >> (chunk1 and vectora_reg). >> >> - Refactor NEON/SVE vector op support check. >> >> Merge NEON and SVE vector supported check into one single function. To >> be consistent, SVE default size supported check now is relaxed from no >> less than 64 bits to the same condition as NEON's min_vector_size(), >> i.e. 4 bytes and 4/2 booleans are also supported. This should be fine, >> as we assume at least we will emit NEON code for those small vectors, >> with unified rules. >> >> - Some notes for new rules >> >> 1) Since new rules are unique and it makes no sense to set different >> "ins_cost", we turn to use the default cost. >> >> 2) By default we use "pipe_slow" for matching rules in aarch64_vector.ad >> now. Hence, many SIMD pipeline classes at aarch64.ad become unused and >> can be removed. >> >> 3) Suffixes '_le128b/_gt128b' and '_neon/_sve' are appended in the >> matching rule names if needed. >> a) 'le128b' means the vector length is less than or equal to 128 bits. >> This rule can be matched on both NEON and 128-bit SVE. >> b) 'gt128b' means the vector length is greater than 128 bits. This rule >> can only be matched on SVE. >> c) 'neon' means this rule can only be matched on NEON, i.e. the >> generated instruction is not better than those in 128-bit SVE. >> d) 'sve' means this rule is only matched on SVE for all possible vector >> length, i.e. not limited to gt128b. >> >> Note-1: m4 file is not introduced because many duplications are highly >> reduced now. >> Note-2: We guess the code review for this big patch would probably take >> some time and we may need to merge latest code from master branch from >> time to time. We prefer to keep aarch64_neon/sve.ad and the >> corresponding m4 files for easy comparison and review. Of course, they >> will be finally removed after some solid reviews before integration. >> Note-3: Several other minor refactorings are done in this patch, but we >> cannot list all of them in the commit message. We have reviewed and >> tested the rules carefully to guarantee the quality. >> >> **TESTING** >> >> 1) Cross compilations on arm32/s390/pps/riscv passed. >> 2) tier1~3 jtreg passed on both x64 and aarch64 machines. >> 3) vector tests: all the test cases under the following directories can >> pass on both NEON and SVE systems with max vector length 16/32/64 bytes. >> >> "test/hotspot/jtreg/compiler/vectorapi/" >> "test/jdk/jdk/incubator/vector/" >> "test/hotspot/jtreg/compiler/vectorization/" >> >> 4) Performance evaluation: we choose vector micro-benchmarks from >> panama-vector:vectorIntrinsics [2] to evaluate the performance of this >> patch. We've tested *MaxVectorTests.java cases on one 128-bit SVE >> platform and one NEON platform, and didn't see any visiable regression >> with NEON and SVE. We will continue to verify more cases on other >> platforms with NEON and different SVE vector sizes. >> >> **BENEFITS** >> >> The number of matching rules is reduced to ~ **42%**. >> before: 373 (aarch64_neon.ad) + 380 (aarch64_sve.ad) = 753 >> after : 313 (aarch64_vector.ad) >> >> Code size for libjvm.so (release build) on aarch64 is reduced to ~ **96%**. >> before: 25246528 B (commit 7905788e969) >> after : 24208776 B (**nearly 1 MB reduction**) >> >> [1] http://cr.openjdk.java.net/~njian/8285790/JDK-8285790.pdf >> [2] https://github.com/openjdk/panama-vector/tree/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation >> >> Co-Developed-by: Ningsheng Jian >> Co-Developed-by: Eric Liu > > Aha! I was looking forward to this. > > On 7/1/22 11:46, Hao Sun wrote: > > Note-1: m4 file is not introduced because many duplications are highly > > reduced now. > > Yes, but there's still a lot of duplications. I'll make a few examples > of where you should make simple changes that will usefully increase the > level of abstraction. That will be a start. > @theRealAph Thanks for your comment. Yes. There are still duplicate code. I can easily list several ones, such as the reduce-and/or/xor, vector shift ops and several reg with imm rules. We're open to keep m4 file. > > But I would suggest that we may put our attention firstly on 1) our implementation on generic vector registers and 2) the merged rules (in particular those we share the codegen for NEON only platform and 128-bit vector ops on SVE platform). After that we may discuss whether to use m4 file and how to implement it if needed. We can do both: there's no sense in which one excludes the other, and we have time. However, just putting aside for a moment the lack of useful abstraction mechanisms, I note that there's a lot of code like this: if (length_in_bytes <= 16) { // ... Neon } else { assert(UseSVE > 0, "must be sve"); // ... SVE } which is to say, there's an implicit assumption that if an operation can be done with Neon it will be, and SVE will only be used if not. What is the justification for that assumption? ------------- PR: https://git.openjdk.org/jdk/pull/9346 From ihse at openjdk.org Mon Jul 4 16:18:30 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 4 Jul 2022 16:18:30 GMT Subject: RFR: 8289646: configure script failed on WSL In-Reply-To: References: Message-ID: On Mon, 4 Jul 2022 03:56:03 GMT, Yasumasa Suenaga wrote: > configure failed as following when I run it on WSL 1. > > > checking for version string... 20-internal-adhoc.yasuenag.jdk > configure: Found potential Boot JDK using configure arguments > configure: The command for java_to_test, which resolves as "/mnt/d/java/jdk-18/bin/java", can not be found. > configure: error: Cannot locate /mnt/d/java/jdk-18/bin/java > configure exiting with result code 1 > > > fixpath.sh would attempt to add ".exe" (e.g. "java" -> "java.exe") if `wslpath -w" failed (returns non-zero value). However it returns zero even if the path does not exist in recent WSL (v0.61.4 at least). > > WSL v0.60.0.0 > > $ wslpath -w silver-bullet > wslpath: silver-bullet: No such file or directory > $ echo $? > 1 > > > WSL v0.61.4.0 > > $ wslpath -w silver-bullet > silver-bullet > $ echo $? > 0 > > > We should add ".exe" at the tail of path regardless of return value from wslpath. Configure has been working fine for WSL1 for many years now. Do you have any idea what is different in your environment? The "fixpath" solution is a finicky thing, and any changes to it needs extensive testing on all supported windows environments. Ideally, I'd like to avoid any changes at all to it, since it's quite battle proven by now. Has WSL never worked for you? Did it stop working at a certain JDK version? Or after an upgrade of WSL/Windows? Ah, sorry, now I understand what you are saying. Since `wslpath` has become more permissive in v0.61.4.0, we can't rely on it to complain if the path is missing `.exe`. Makes sense. ------------- PR: https://git.openjdk.org/jdk/pull/9357 From ihse at openjdk.org Mon Jul 4 16:29:27 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 4 Jul 2022 16:29:27 GMT Subject: RFR: 8289646: configure script failed on WSL In-Reply-To: References: Message-ID: On Mon, 4 Jul 2022 03:56:03 GMT, Yasumasa Suenaga wrote: > configure failed as following when I run it on WSL 1. > > > checking for version string... 20-internal-adhoc.yasuenag.jdk > configure: Found potential Boot JDK using configure arguments > configure: The command for java_to_test, which resolves as "/mnt/d/java/jdk-18/bin/java", can not be found. > configure: error: Cannot locate /mnt/d/java/jdk-18/bin/java > configure exiting with result code 1 > > > fixpath.sh would attempt to add ".exe" (e.g. "java" -> "java.exe") if `wslpath -w" failed (returns non-zero value). However it returns zero even if the path does not exist in recent WSL (v0.61.4 at least). > > WSL v0.60.0.0 > > $ wslpath -w silver-bullet > wslpath: silver-bullet: No such file or directory > $ echo $? > 1 > > > WSL v0.61.4.0 > > $ wslpath -w silver-bullet > silver-bullet > $ echo $? > 0 > > > We should add ".exe" at the tail of path regardless of return value from wslpath. I added some comments. As a minimum, you need to verify that this works on WSL1, WSL2 and Cygwin. Ideally, you would test on msys2 as well. You will need to verify that importing paths works for executables both with and without .exe, both if they reside in the winenv root (like in /tmp) or on the Windows drive (like /cygwin/d/data/...). As I wrote, I think you might run into problems for things like /tmp/foo.exe on WSL1. It might also work on newer versions of wslpath but break on older, seeing that Microsoft is in the habit of changing the behaviour of wslpath... make/scripts/fixpath.sh line 150: > 148: if [[ "$path" != "" ]]; then > 149: # Store current unix path > 150: unixpath="$path" I think the distinction between "unixpath" and "winpath" was helpful, with "path" being the input/output variable of this conversion process. Was there some specific reason that you've removed "unixpath"? make/scripts/fixpath.sh line 177: > 175: > 176: if [[ ! -e $path ]]; then > 177: if [[ -e $path.exe ]]; then I'm not entirely sure this is correct. The comment above states: " On WSL1, PATHTOOL will fail for files in envroot." That could mean that it will also fail even if you provide it with $path.exe. If this is the case, then your change will break. It might even be that "WSL1" in this case means "older versions of WSL1", since Microsoft made some changes even to WSL1 when WSL2 was introduced to be able to run in parallel. ------------- PR: https://git.openjdk.org/jdk/pull/9357 From ysuenaga at openjdk.org Mon Jul 4 22:32:20 2022 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Mon, 4 Jul 2022 22:32:20 GMT Subject: RFR: 8289646: configure script failed on WSL [v2] In-Reply-To: References: Message-ID: > configure failed as following when I run it on WSL 1. > > > checking for version string... 20-internal-adhoc.yasuenag.jdk > configure: Found potential Boot JDK using configure arguments > configure: The command for java_to_test, which resolves as "/mnt/d/java/jdk-18/bin/java", can not be found. > configure: error: Cannot locate /mnt/d/java/jdk-18/bin/java > configure exiting with result code 1 > > > fixpath.sh would attempt to add ".exe" (e.g. "java" -> "java.exe") if `wslpath -w" failed (returns non-zero value). However it returns zero even if the path does not exist in recent WSL (v0.61.4 at least). > > WSL v0.60.0.0 > > $ wslpath -w silver-bullet > wslpath: silver-bullet: No such file or directory > $ echo $? > 1 > > > WSL v0.61.4.0 > > $ wslpath -w silver-bullet > silver-bullet > $ echo $? > 0 > > > We should add ".exe" at the tail of path regardless of return value from wslpath. Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: Update the fix to use unixpath ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9357/files - new: https://git.openjdk.org/jdk/pull/9357/files/d28656f9..ce651d04 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9357&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9357&range=00-01 Stats: 17 lines in 1 file changed: 8 ins; 1 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/9357.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9357/head:pull/9357 PR: https://git.openjdk.org/jdk/pull/9357 From ysuenaga at openjdk.org Mon Jul 4 22:35:20 2022 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Mon, 4 Jul 2022 22:35:20 GMT Subject: RFR: 8289646: configure script failed on WSL In-Reply-To: References: Message-ID: <5lzoWXX91Yp_kWql1sQBNLZU9ylAw5_rZ_2XUjtAy5k=.a5f94061-be5a-4f4c-b36d-83947e659963@github.com> On Mon, 4 Jul 2022 16:26:21 GMT, Magnus Ihse Bursie wrote: >> configure failed as following when I run it on WSL 1. >> >> >> checking for version string... 20-internal-adhoc.yasuenag.jdk >> configure: Found potential Boot JDK using configure arguments >> configure: The command for java_to_test, which resolves as "/mnt/d/java/jdk-18/bin/java", can not be found. >> configure: error: Cannot locate /mnt/d/java/jdk-18/bin/java >> configure exiting with result code 1 >> >> >> fixpath.sh would attempt to add ".exe" (e.g. "java" -> "java.exe") if `wslpath -w" failed (returns non-zero value). However it returns zero even if the path does not exist in recent WSL (v0.61.4 at least). >> >> WSL v0.60.0.0 >> >> $ wslpath -w silver-bullet >> wslpath: silver-bullet: No such file or directory >> $ echo $? >> 1 >> >> >> WSL v0.61.4.0 >> >> $ wslpath -w silver-bullet >> silver-bullet >> $ echo $? >> 0 >> >> >> We should add ".exe" at the tail of path regardless of return value from wslpath. > > I added some comments. As a minimum, you need to verify that this works on WSL1, WSL2 and Cygwin. Ideally, you would test on msys2 as well. You will need to verify that importing paths works for executables both with and without .exe, both if they reside in the winenv root (like in /tmp) or on the Windows drive (like /cygwin/d/data/...). > > As I wrote, I think you might run into problems for things like /tmp/foo.exe on WSL1. It might also work on newer versions of wslpath but break on older, seeing that Microsoft is in the habit of changing the behaviour of wslpath... Thanks @magicus for your comment! I thought we can remove `unixpath` to simplify fixpath in this patch, but we can use it to keep current behavior. So I updated this PR to use `unixpath`. Could you review again? It uses `test -e` instead of return code from wslpath. ------------- PR: https://git.openjdk.org/jdk/pull/9357 From ysuenaga at openjdk.org Mon Jul 4 23:07:41 2022 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Mon, 4 Jul 2022 23:07:41 GMT Subject: RFR: 8289646: configure script failed on WSL In-Reply-To: References: Message-ID: On Mon, 4 Jul 2022 16:26:21 GMT, Magnus Ihse Bursie wrote: > As a minimum, you need to verify that this works on WSL1, WSL2 and Cygwin. I tested my patch on both WSL 1 and 2. GHA will test on Cygwin (it seems to work). > It might also work on newer versions of wslpath but break on older, seeing that Microsoft is in the habit of changing the behaviour of wslpath... In my latest PR, it uses `test -e` whether to determine to add ".exe" to the path. I think it is an expected behavior (add ".exe" if the path does not exist), and also it does not depends on wslpath behavior. ------------- PR: https://git.openjdk.org/jdk/pull/9357 From ihse at openjdk.org Mon Jul 4 23:17:25 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 4 Jul 2022 23:17:25 GMT Subject: RFR: 8289646: configure script failed on WSL [v2] In-Reply-To: References: Message-ID: On Mon, 4 Jul 2022 22:32:20 GMT, Yasumasa Suenaga wrote: >> configure failed as following when I run it on WSL 1. >> >> >> checking for version string... 20-internal-adhoc.yasuenag.jdk >> configure: Found potential Boot JDK using configure arguments >> configure: The command for java_to_test, which resolves as "/mnt/d/java/jdk-18/bin/java", can not be found. >> configure: error: Cannot locate /mnt/d/java/jdk-18/bin/java >> configure exiting with result code 1 >> >> >> fixpath.sh would attempt to add ".exe" (e.g. "java" -> "java.exe") if `wslpath -w" failed (returns non-zero value). However it returns zero even if the path does not exist in recent WSL (v0.61.4 at least). >> >> WSL v0.60.0.0 >> >> $ wslpath -w silver-bullet >> wslpath: silver-bullet: No such file or directory >> $ echo $? >> 1 >> >> >> WSL v0.61.4.0 >> >> $ wslpath -w silver-bullet >> silver-bullet >> $ echo $? >> 0 >> >> >> We should add ".exe" at the tail of path regardless of return value from wslpath. > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Update the fix to use unixpath This looks better with less changes. Note that GHA tests msys2 nowadays, not Cygwin. Also, how do you exercise the four different test cases per platform I requested using GHA? While this looks better, I'm still not convinced this is correct. What if the path is not an executable? Now you unconditionally add .exe, even if the .exe does not exist. I think import_path() can be used to import e.g. directories, too, right? So if the starting path does not exist, but the .exe version of it exists, it seems quite safe and correct to swap it out for the .exe version. But I don't think you can just do it unconditionally. Apart from testing running `fixpath import` with an executable both in the env root file namespace, and with the Windows file namespace -- both with and without .exe -- I also think you need to test with a directory, in both namespaces. (Ideally, we'd have automatic tests for this kind of things, but it's been too complicated to write tests that can setup a proper environment, so we're forced to do systematic manual testing whenever we change this code.) ------------- PR: https://git.openjdk.org/jdk/pull/9357 From ysuenaga at openjdk.org Tue Jul 5 03:07:10 2022 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Tue, 5 Jul 2022 03:07:10 GMT Subject: RFR: 8289646: configure script failed on WSL [v3] In-Reply-To: References: Message-ID: <3c1FcymALB5PYxsyuyGLLJ2Iux5_LjxHqyNKy6tVBts=.94e5e53e-d239-41a2-b8f3-c9d28df86485@github.com> > configure failed as following when I run it on WSL 1. > > > checking for version string... 20-internal-adhoc.yasuenag.jdk > configure: Found potential Boot JDK using configure arguments > configure: The command for java_to_test, which resolves as "/mnt/d/java/jdk-18/bin/java", can not be found. > configure: error: Cannot locate /mnt/d/java/jdk-18/bin/java > configure exiting with result code 1 > > > fixpath.sh would attempt to add ".exe" (e.g. "java" -> "java.exe") if `wslpath -w" failed (returns non-zero value). However it returns zero even if the path does not exist in recent WSL (v0.61.4 at least). > > WSL v0.60.0.0 > > $ wslpath -w silver-bullet > wslpath: silver-bullet: No such file or directory > $ echo $? > 1 > > > WSL v0.61.4.0 > > $ wslpath -w silver-bullet > silver-bullet > $ echo $? > 0 > > > We should add ".exe" at the tail of path regardless of return value from wslpath. Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: Add to check unixpath existing ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9357/files - new: https://git.openjdk.org/jdk/pull/9357/files/ce651d04..c0667805 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9357&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9357&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9357.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9357/head:pull/9357 PR: https://git.openjdk.org/jdk/pull/9357 From ysuenaga at openjdk.org Tue Jul 5 03:09:21 2022 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Tue, 5 Jul 2022 03:09:21 GMT Subject: RFR: 8289646: configure script failed on WSL [v2] In-Reply-To: References: Message-ID: On Mon, 4 Jul 2022 22:32:20 GMT, Yasumasa Suenaga wrote: >> configure failed as following when I run it on WSL 1. >> >> >> checking for version string... 20-internal-adhoc.yasuenag.jdk >> configure: Found potential Boot JDK using configure arguments >> configure: The command for java_to_test, which resolves as "/mnt/d/java/jdk-18/bin/java", can not be found. >> configure: error: Cannot locate /mnt/d/java/jdk-18/bin/java >> configure exiting with result code 1 >> >> >> fixpath.sh would attempt to add ".exe" (e.g. "java" -> "java.exe") if `wslpath -w" failed (returns non-zero value). However it returns zero even if the path does not exist in recent WSL (v0.61.4 at least). >> >> WSL v0.60.0.0 >> >> $ wslpath -w silver-bullet >> wslpath: silver-bullet: No such file or directory >> $ echo $? >> 1 >> >> >> WSL v0.61.4.0 >> >> $ wslpath -w silver-bullet >> silver-bullet >> $ echo $? >> 0 >> >> >> We should add ".exe" at the tail of path regardless of return value from wslpath. > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Update the fix to use unixpath I think we should test on each platforms manually as possible. IMHO fixpath is a complex application, so it is better to make testcases for it, but I'm not sure it is right thing (because fixpath is not a part of OpenJDK binaries - for example, we can think it is ok to pass GHA build test (msys2)). > What if the path is not an executable? Now you unconditionally add .exe, even if the .exe does not exist. I think all of files on Windows filesystems (NTFS, vfat) has exec bit (+x) - I've read about it in book in the past, but I forget the title... fixpath has relied on return code from PATHTOOL, so it expects non-zero value if the path does not exist. I added path check as following in new commit. 155 # Now turn it into a windows path 156 winpath="$($PATHTOOL -w "$unixpath" 2>/dev/null)" 157 if [[ $? -eq 0 && -e "$unixpath" ]]; then ------------- PR: https://git.openjdk.org/jdk/pull/9357 From haosun at openjdk.org Tue Jul 5 04:25:25 2022 From: haosun at openjdk.org (Hao Sun) Date: Tue, 5 Jul 2022 04:25:25 GMT Subject: RFR: 8285790: AArch64: Merge C2 NEON and SVE matching rules In-Reply-To: <_ZcvC_kGQPJuD-WAwAocrGLlbHEF66ww-FgDhUl6av4=.06b039a0-ed2c-42cb-9e1e-c8f32c712789@github.com> References: <_l-poEFY80LRmKZyRhpxvSohm6nLv_ruaO1_WzKmTlQ=.9faff21d-d67c-42e0-8de7-be2ca9397b88@github.com> <_ZcvC_kGQPJuD-WAwAocrGLlbHEF66ww-FgDhUl6av4=.06b039a0-ed2c-42cb-9e1e-c8f32c712789@github.com> Message-ID: On Mon, 4 Jul 2022 12:51:22 GMT, Andrew Haley wrote: > However, just putting aside for a moment the lack of useful abstraction mechanisms, I note that there's a lot of code like this: > > ``` > if (length_in_bytes <= 16) { > // ... Neon > } else { > assert(UseSVE > 0, "must be sve"); > // ... SVE > } > ``` > > which is to say, there's an implicit assumption that if an operation can be done with Neon it will be, and SVE will only be used if not. What is the justification for that assumption? Not exactly. It's only for common **64/128-bit unpredicated** vector operations, when NEON have equivalent instructions as SVE. Recall the **Drawback-1** and **Update-2 (part 2)** in the commit message. Besides the code pattern you mentioned, there are many pairs of rules with "**_le128b**" and "**_gt128b**" suffixes, e.g., vmulI_le128b() and vmulI_gt128b(). We use two rules mainly because different numbers of arguments are used. Otherwise, we tend to put them into one rule, which is your mentioned pattern, e.g., vadd(). The main reason we conduct this change lies in that from Neoverse V1 and N2 optimization guides, if the size fit, common NEON instructions are no slower than equivalent SVE instructions in latency and throughput. Note-1: In current aarch64_sve.ad file, there are already several rules under this rule, e.g., loadV16_vreg(), vroundFtoI(), insertI_le128bits(). There is an ongoing patch as well in [link](https://github.com/openjdk/jdk/pull/7999). This patch makes them more clear. Note-2: As we mentioned in the part 4 in **TESTING** section, we ran JMH testing on one SVE machine and didn't observe regression and we will do more measurement on different systems. ------------- PR: https://git.openjdk.org/jdk/pull/9346 From magnus.ihse.bursie at oracle.com Tue Jul 5 10:43:57 2022 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 5 Jul 2022 12:43:57 +0200 Subject: Warning about git from 'make test' on Windows In-Reply-To: References: Message-ID: <4f0835b9-51a1-08c4-3418-4a9a34025a20@oracle.com> Christoph, Andrey, Thanks for your input and debugging. I have created https://bugs.openjdk.org/browse/JDK-8289735 to track this. I believe this is easy to fix, but I'm not sure I'm able to provide a PR before I leave on vacation. /Magnus On 2022-06-03 09:09, Langer, Christoph wrote: > Hi, > > I see the same on my windows build. I verified that 8.3 filenames are enabled. > > I took a little closer look. In my PATH env in Cygwin I have: ...:/cygdrive/c/Program Files/Git/cmd:... > > The git path is resolved via UTIL_LOOKUP_PROGS(GIT, git) in basic_tools.m4. UTIL_LOOKUP_PROGS, defined in util_paths.m4 must somehow not be capable to correctly resolve the path with spaces. The output in configure is: > > checking for git... Files/Git/cmd/git > > Maybe this gives a hint on how to fix it? I guess I can configure my path to use the 8.3 notation. But maybe UTIL_LOOKUP_PROGS could be improved? > > Cheers > Christoph > >> -----Original Message----- >> From: build-dev On Behalf Of Magnus Ihse >> Bursie >> Sent: Freitag, 3. Juni 2022 01:10 >> To: Andrey Turbanov ; build-dev at openjdk.java.net >> Subject: Re: Warning about git from 'make test' on Windows >> >> >> On 2022-06-02 21:26, Andrey Turbanov wrote: >>> Hello. >>> I noticed strange warnings produced by 'make test' recently on my >>> Win11 installation. For example: >>> >>> $ make test TEST="tier1" >>> Building target 'test' in configuration 'windows-x86_64-server-release' >>> /usr/bin/bash: Files/Git/cmd/git: No such file or directory >>> /usr/bin/bash: Files/Git/cmd/git: No such file or directory Test >>> selection 'tier1', will run: >>> >>> >>> Also found this in >>> build\windows-x86_64-server-release\configure-support\config.log >>> >>> configure:29274: checking for git >>> configure:29502: result: Files/Git/cmd/git >>> >>> Seems like space in git path is incorrectly handled. >>> Is it a known issue or is it a limitation of autoconf? >> Spaces in paths is always tricky and is best avoided. That being said, we try to >> make autoconf robust for tools in directories with space in them. >> >> Are you running in Cygwin? >> >> Can you verify that your C: drive can use short paths. See >> https://openjdk.java.net/groups/build/doc/building.html#spaces-in-path >> >> /Magnus >>> Andrey Turbanov From duke at openjdk.org Tue Jul 5 12:19:17 2022 From: duke at openjdk.org (ScientificWare) Date: Tue, 5 Jul 2022 12:19:17 GMT Subject: RFR: JDK-8289741 : Remove unused imports from DTDBuilder.java Message-ID: <_NwZVv_R3J3rji4AQYptjRFrewWjITtqvSuFsfk0JuM=.17e9f97e-076a-4b5e-ac6f-0cd100aa0f60@github.com> This is tracked in JBS as [JDK-8289741](https://bugs.openjdk.org/browse/JDK-8289741) > **Remove unused imports from DTDBuilder.java** Some imports are no more used. - java.io.FileNotFoundException; - java.io.BufferedInputStream; - java.io.OutputStream; - java.util.BitSet; - java.util.StringTokenizer; - java.util.Properties; - java.util.zip.DeflaterOutputStream; - java.util.zip.Deflater; - java.net.URL; ------------- Commit messages: - Merge branch 'openjdk:master' into scientificware-patch-001-DTDBuilder - Merge branch 'openjdk:master' into scientificware-patch-001-DTDBuilder - Merge branch 'openjdk:master' into scientificware-patch-001-DTDBuilder - Merge branch 'openjdk:master' into scientificware-patch-001-DTDBuilder - Merge branch 'openjdk:master' into scientificware-patch-001-DTDBuilder - Merge branch 'openjdk:master' into scientificware-patch-001-DTDBuilder - Remove unused imports. Changes: https://git.openjdk.org/jdk/pull/9360/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9360&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289741 Stats: 11 lines in 1 file changed: 0 ins; 10 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9360.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9360/head:pull/9360 PR: https://git.openjdk.org/jdk/pull/9360 From duke at openjdk.org Tue Jul 5 12:19:18 2022 From: duke at openjdk.org (ScientificWare) Date: Tue, 5 Jul 2022 12:19:18 GMT Subject: RFR: JDK-8289741 : Remove unused imports from DTDBuilder.java In-Reply-To: <6EzP1J6Wql9_M9ek2JNDk5UneiH2a5ilaf-BssTXa-E=.15e32eab-3b8c-444e-a085-c40465f0754d@github.com> References: <_NwZVv_R3J3rji4AQYptjRFrewWjITtqvSuFsfk0JuM=.17e9f97e-076a-4b5e-ac6f-0cd100aa0f60@github.com> <6EzP1J6Wql9_M9ek2JNDk5UneiH2a5ilaf-BssTXa-E=.15e32eab-3b8c-444e-a085-c40465f0754d@github.com> Message-ID: On Tue, 5 Jul 2022 01:53:33 GMT, Julian Waters wrote: >> This is tracked in JBS as >> >> [JDK-8289741](https://bugs.openjdk.org/browse/JDK-8289741) >> >>> **Remove unused imports from DTDBuilder.java** >> Some imports are no more used. >> >> - java.io.FileNotFoundException; >> - java.io.BufferedInputStream; >> - java.io.OutputStream; >> - java.util.BitSet; >> - java.util.StringTokenizer; >> - java.util.Properties; >> - java.util.zip.DeflaterOutputStream; >> - java.util.zip.Deflater; >> - java.net.URL; > > @scientificware Do you need an entry in the JBS for this PR? Hi @TheShermanTanker, Yes I need it. I'm waiting for the Issue Id. Regards > Alright, was asking since I can help create one for you, but it seems that others already have it covered @TheShermanTanker , thank you for asking and helping. > it seems that others already have it covered In fact, I don't known. Yesterday, I posted 3 reports in the Java Bug Database and I have no feedback at this moment. ------------- PR: https://git.openjdk.org/jdk/pull/9360 From jwaters at openjdk.org Tue Jul 5 12:19:18 2022 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 5 Jul 2022 12:19:18 GMT Subject: RFR: JDK-8289741 : Remove unused imports from DTDBuilder.java In-Reply-To: <_NwZVv_R3J3rji4AQYptjRFrewWjITtqvSuFsfk0JuM=.17e9f97e-076a-4b5e-ac6f-0cd100aa0f60@github.com> References: <_NwZVv_R3J3rji4AQYptjRFrewWjITtqvSuFsfk0JuM=.17e9f97e-076a-4b5e-ac6f-0cd100aa0f60@github.com> Message-ID: <6EzP1J6Wql9_M9ek2JNDk5UneiH2a5ilaf-BssTXa-E=.15e32eab-3b8c-444e-a085-c40465f0754d@github.com> On Mon, 4 Jul 2022 07:04:40 GMT, ScientificWare wrote: > This is tracked in JBS as > > [JDK-8289741](https://bugs.openjdk.org/browse/JDK-8289741) > >> **Remove unused imports from DTDBuilder.java** > Some imports are no more used. > > - java.io.FileNotFoundException; > - java.io.BufferedInputStream; > - java.io.OutputStream; > - java.util.BitSet; > - java.util.StringTokenizer; > - java.util.Properties; > - java.util.zip.DeflaterOutputStream; > - java.util.zip.Deflater; > - java.net.URL; @scientificware Do you need an entry in the JBS for this PR? Alright, was asking since I can help create one for you, but it seems that others already have it covered ------------- PR: https://git.openjdk.org/jdk/pull/9360 From jwaters at openjdk.org Tue Jul 5 12:19:18 2022 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 5 Jul 2022 12:19:18 GMT Subject: RFR: JDK-8289741 : Remove unused imports from DTDBuilder.java In-Reply-To: <6EzP1J6Wql9_M9ek2JNDk5UneiH2a5ilaf-BssTXa-E=.15e32eab-3b8c-444e-a085-c40465f0754d@github.com> References: <_NwZVv_R3J3rji4AQYptjRFrewWjITtqvSuFsfk0JuM=.17e9f97e-076a-4b5e-ac6f-0cd100aa0f60@github.com> <6EzP1J6Wql9_M9ek2JNDk5UneiH2a5ilaf-BssTXa-E=.15e32eab-3b8c-444e-a085-c40465f0754d@github.com> Message-ID: On Tue, 5 Jul 2022 03:40:51 GMT, Julian Waters wrote: >> This is tracked in JBS as >> >> [JDK-8289741](https://bugs.openjdk.org/browse/JDK-8289741) >> >>> **Remove unused imports from DTDBuilder.java** >> Some imports are no more used. >> >> - java.io.FileNotFoundException; >> - java.io.BufferedInputStream; >> - java.io.OutputStream; >> - java.util.BitSet; >> - java.util.StringTokenizer; >> - java.util.Properties; >> - java.util.zip.DeflaterOutputStream; >> - java.util.zip.Deflater; >> - java.net.URL; > > Alright, was asking since I can help create one for you, but it seems that others already have it covered > @TheShermanTanker , thank you for asking and helping. > > > it seems that others already have it covered > > In fact, I dont known. Yesterday, I posted 3 reports in the Java Bug Database and I have no feedback at this moment. Well, in that case, wait no longer! Your issue ID is [8289741](https://bugs.openjdk.org/browse/JDK-8289741), just change your title to "8289741" and the automated tooling should take care of the rest and send this PR to the appropriate teams for review. All the best! ------------- PR: https://git.openjdk.org/jdk/pull/9360 From duke at openjdk.org Tue Jul 5 12:37:38 2022 From: duke at openjdk.org (ScientificWare) Date: Tue, 5 Jul 2022 12:37:38 GMT Subject: RFR: JDK-8289741 : Remove unused imports from DTDBuilder.java In-Reply-To: References: <_NwZVv_R3J3rji4AQYptjRFrewWjITtqvSuFsfk0JuM=.17e9f97e-076a-4b5e-ac6f-0cd100aa0f60@github.com> <6EzP1J6Wql9_M9ek2JNDk5UneiH2a5ilaf-BssTXa-E=.15e32eab-3b8c-444e-a085-c40465f0754d@github.com> Message-ID: On Tue, 5 Jul 2022 11:34:05 GMT, Julian Waters wrote: >> Alright, was asking since I can help create one for you, but it seems that others already have it covered > >> @TheShermanTanker , thank you for asking and helping. >> >> > it seems that others already have it covered >> >> In fact, I dont known. Yesterday, I posted 3 reports in the Java Bug Database and I have no feedback at this moment. > > Well, in that case, wait no longer! > Your issue ID is [8289741](https://bugs.openjdk.org/browse/JDK-8289741), just change your title to "8289741" and the automated tooling should take care of the rest and send this PR to the appropriate teams for review. > > All the best! @TheShermanTanker Thanks. ------------- PR: https://git.openjdk.org/jdk/pull/9360 From ihse at openjdk.org Tue Jul 5 16:09:43 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 5 Jul 2022 16:09:43 GMT Subject: RFR: 8289755: Remove --enable-reproducible-build from jib profile Message-ID: Since [JDK-8288396](https://bugs.openjdk.org/browse/JDK-8288396), the flag ` --enable-reproducible-build` is deprecated, and does nothing but print a warning. It is still included in the jib profiles, which make they output a warning. ------------- Commit messages: - 8289755: Remove --enable-reproducible-build from jib profile Changes: https://git.openjdk.org/jdk/pull/9379/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9379&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289755 Stats: 13 lines in 1 file changed: 0 ins; 12 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9379.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9379/head:pull/9379 PR: https://git.openjdk.org/jdk/pull/9379 From itakiguchi at openjdk.org Wed Jul 6 16:23:22 2022 From: itakiguchi at openjdk.org (Ichiroh Takiguchi) Date: Wed, 6 Jul 2022 16:23:22 GMT Subject: RFR: 8289834: Add SBCS and DBCS Only EBCDIC charsets Message-ID: OpenJDK supports "Japanese EBCDIC - Katakana" and "Korean EBCDIC" SBCS and DBCS Only charsets. |Charset|Mix|SBCS|DBCS| | -- | -- | -- | -- | | Japanese EBCDIC - Katakana | Cp930 | Cp290 | Cp300 | | Korean | Cp933 | Cp833 | Cp834 | But OpenJDK does not supports some of "Japanese EBCDIC - English" / "Simplified Chinese EBCDIC" / "Traditional Chinese EBCDIC" SBCS and DBCS Only charsets. I'd like to request Cp1027/Cp835/Cp836/Cp837 for consistency |Charset|Mix|SBCS|DBCS| | ------------- | ------------- | ------------- | ------------- | | Japanese EBCDIC - English | Cp939 | **Cp1027** | Cp300 | | Simplified Chinese EBCDIC | Cp935 | **Cp836** | **Cp837** | | Traditional Chinese EBCDIC | Cp937 | (*1) | **Cp835** | *1: Cp037 compatible ------------- Commit messages: - 8289834: Missing SBCS and DBCS Only EBCDIC charsets Changes: https://git.openjdk.org/jdk/pull/9399/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9399&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289834 Stats: 369 lines in 6 files changed: 367 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/9399.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9399/head:pull/9399 PR: https://git.openjdk.org/jdk/pull/9399 From ihse at openjdk.org Wed Jul 6 17:50:47 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 6 Jul 2022 17:50:47 GMT Subject: RFR: 8289646: configure script failed on WSL [v3] In-Reply-To: <3c1FcymALB5PYxsyuyGLLJ2Iux5_LjxHqyNKy6tVBts=.94e5e53e-d239-41a2-b8f3-c9d28df86485@github.com> References: <3c1FcymALB5PYxsyuyGLLJ2Iux5_LjxHqyNKy6tVBts=.94e5e53e-d239-41a2-b8f3-c9d28df86485@github.com> Message-ID: On Tue, 5 Jul 2022 03:07:10 GMT, Yasumasa Suenaga wrote: >> configure failed as following when I run it on WSL 1. >> >> >> checking for version string... 20-internal-adhoc.yasuenag.jdk >> configure: Found potential Boot JDK using configure arguments >> configure: The command for java_to_test, which resolves as "/mnt/d/java/jdk-18/bin/java", can not be found. >> configure: error: Cannot locate /mnt/d/java/jdk-18/bin/java >> configure exiting with result code 1 >> >> >> fixpath.sh would attempt to add ".exe" (e.g. "java" -> "java.exe") if `wslpath -w" failed (returns non-zero value). However it returns zero even if the path does not exist in recent WSL (v0.61.4 at least). >> >> WSL v0.60.0.0 >> >> $ wslpath -w silver-bullet >> wslpath: silver-bullet: No such file or directory >> $ echo $? >> 1 >> >> >> WSL v0.61.4.0 >> >> $ wslpath -w silver-bullet >> silver-bullet >> $ echo $? >> 0 >> >> >> We should add ".exe" at the tail of path regardless of return value from wslpath. > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Add to check unixpath existing I'm talking about other files than executables. The path could be a data file, or a directory. It might not even exist; the import path function was written to be as tolerant as possible for stuff that seems to be a valid path but where only the initial part exists. I'm worried that with the patch you are proposing, we will unconditinonally add `.exe` to any path that is not existing, which will make the next test fail (since then the path with the addition of `.exe` will most likely not exist either). In contrast, I believe the old code could accept stuff like /tmp/foo/bar, if /tmp/foo were a valid directory, but the file /tmp/foo/bar did not exist yet. I don't have any ready access to a Windows machine right now (is on the verge of going on vacation for the summer), but can you verify that either: 1) the code prior to your fix would not accept a path like /tmp/foo/bar before, or that 2) your code will still accept it (this does not seem likely if I read the code correctly). The problem that you are trying to solve is kind of the opposite of the solution you present. The issue is that wslpath is *too* permissive, accepting a path like /mnt/c/bin/git.exe when it should have returned false, making us retry with /mnt/c/bin/git.exe, which would then have succeeded. So what you need to to is rather, if wslpath *succeeds*, try again with an .exe prefix, and if that *too* succeeds, use that instead. *And* you need to keep the current behavior, for old versions of WSL. ------------- PR: https://git.openjdk.org/jdk/pull/9357 From itakiguchi at openjdk.org Wed Jul 6 16:23:22 2022 From: itakiguchi at openjdk.org (Ichiroh Takiguchi) Date: Wed, 6 Jul 2022 16:23:22 GMT Subject: RFR: 8289834: Add SBCS and DBCS Only EBCDIC charsets In-Reply-To: References: Message-ID: On Wed, 6 Jul 2022 14:05:39 GMT, Ichiroh Takiguchi wrote: > OpenJDK supports "Japanese EBCDIC - Katakana" and "Korean EBCDIC" SBCS and DBCS Only charsets. > |Charset|Mix|SBCS|DBCS| > | -- | -- | -- | -- | > | Japanese EBCDIC - Katakana | Cp930 | Cp290 | Cp300 | > | Korean | Cp933 | Cp833 | Cp834 | > > But OpenJDK does not supports some of "Japanese EBCDIC - English" / "Simplified Chinese EBCDIC" / "Traditional Chinese EBCDIC" SBCS and DBCS Only charsets. > > I'd like to request Cp1027/Cp835/Cp836/Cp837 for consistency > |Charset|Mix|SBCS|DBCS| > | ------------- | ------------- | ------------- | ------------- | > | Japanese EBCDIC - English | Cp939 | **Cp1027** | Cp300 | > | Simplified Chinese EBCDIC | Cp935 | **Cp836** | **Cp837** | > | Traditional Chinese EBCDIC | Cp937 | (*1) | **Cp835** | > > *1: Cp037 compatible Discussions are available on : [JDK-8289834](https://bugs.openjdk.org/browse/JDK-8289834): Add SBCS and DBCS Only EBCDIC charsets ------------- PR: https://git.openjdk.org/jdk/pull/9399 From christoph.langer at sap.com Wed Jul 6 06:03:21 2022 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 6 Jul 2022 06:03:21 +0000 Subject: Warning about git from 'make test' on Windows In-Reply-To: <4f0835b9-51a1-08c4-3418-4a9a34025a20@oracle.com> References: <4f0835b9-51a1-08c4-3418-4a9a34025a20@oracle.com> Message-ID: Hi Magnus, thanks for opening the bug and I hope you'll get to fix it eventually. It's not urgent to me, though. I might add that I fixed the error message for me by installing the Cygwin package for Git. By doing that, it is correctly picked up and no issues with the path to it. Best regards Christoph > -----Original Message----- > From: Magnus Ihse Bursie > Sent: Dienstag, 5. Juli 2022 12:44 > To: Langer, Christoph ; Andrey Turbanov > ; build-dev at openjdk.java.net > Subject: Re: Warning about git from 'make test' on Windows > > Christoph, Andrey, > > Thanks for your input and debugging. I have created > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs. > openjdk.org%2Fbrowse%2FJDK- > 8289735&data=05%7C01%7Cchristoph.langer%40sap.com%7C1a67c2c65 > 92747f6e42908da5e73533f%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0 > %7C637926146654427371%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjA > wMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C > %7C&sdata=BZUHbHjFTJlibZ0lVtKs85fqZ%2FJhMhTtBO6KRT0drvU%3D& > amp;reserved=0 to track this. I believe this is easy to fix, but I'm not sure I'm > able to provide a PR before I leave on vacation. > > /Magnus > > On 2022-06-03 09:09, Langer, Christoph wrote: > > Hi, > > > > I see the same on my windows build. I verified that 8.3 filenames are > enabled. > > > > I took a little closer look. In my PATH env in Cygwin I have: > ...:/cygdrive/c/Program Files/Git/cmd:... > > > > The git path is resolved via UTIL_LOOKUP_PROGS(GIT, git) in > basic_tools.m4. UTIL_LOOKUP_PROGS, defined in util_paths.m4 must > somehow not be capable to correctly resolve the path with spaces. The > output in configure is: > > > > checking for git... Files/Git/cmd/git > > > > Maybe this gives a hint on how to fix it? I guess I can configure my path to > use the 8.3 notation. But maybe UTIL_LOOKUP_PROGS could be improved? > > > > Cheers > > Christoph > > > >> -----Original Message----- > >> From: build-dev On Behalf Of > Magnus > >> Ihse Bursie > >> Sent: Freitag, 3. Juni 2022 01:10 > >> To: Andrey Turbanov ; build- > dev at openjdk.java.net > >> Subject: Re: Warning about git from 'make test' on Windows > >> > >> > >> On 2022-06-02 21:26, Andrey Turbanov wrote: > >>> Hello. > >>> I noticed strange warnings produced by 'make test' recently on my > >>> Win11 installation. For example: > >>> > >>> $ make test TEST="tier1" > >>> Building target 'test' in configuration 'windows-x86_64-server-release' > >>> /usr/bin/bash: Files/Git/cmd/git: No such file or directory > >>> /usr/bin/bash: Files/Git/cmd/git: No such file or directory Test > >>> selection 'tier1', will run: > >>> > >>> > >>> Also found this in > >>> build\windows-x86_64-server-release\configure-support\config.log > >>> > >>> configure:29274: checking for git > >>> configure:29502: result: Files/Git/cmd/git > >>> > >>> Seems like space in git path is incorrectly handled. > >>> Is it a known issue or is it a limitation of autoconf? > >> Spaces in paths is always tricky and is best avoided. That being > >> said, we try to make autoconf robust for tools in directories with space in > them. > >> > >> Are you running in Cygwin? > >> > >> Can you verify that your C: drive can use short paths. See > >> https://openjdk.java.net/groups/build/doc/building.html#spaces-in-pat > >> h > >> > >> /Magnus > >>> Andrey Turbanov From chagedorn at openjdk.org Wed Jul 6 07:28:01 2022 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Wed, 6 Jul 2022 07:28:01 GMT Subject: RFR: 8242181: [Linux] Show source information when printing native stack traces in hs_err files [v13] In-Reply-To: References: Message-ID: > When printing the native stack trace on Linux (mostly done for hs_err files), it only prints the method with its parameters and a relative offset in the method: > > Stack: [0x00007f6e01739000,0x00007f6e0183a000], sp=0x00007f6e01838110, free space=1020k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > V [libjvm.so+0x620d86] Compilation::~Compilation()+0x64 > V [libjvm.so+0x624b92] Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0xec > V [libjvm.so+0x8303ef] CompileBroker::invoke_compiler_on_method(CompileTask*)+0x899 > V [libjvm.so+0x82f067] CompileBroker::compiler_thread_loop()+0x3df > V [libjvm.so+0x84f0d1] CompilerThread::thread_entry(JavaThread*, JavaThread*)+0x69 > V [libjvm.so+0x1209329] JavaThread::thread_main_inner()+0x15d > V [libjvm.so+0x12091c9] JavaThread::run()+0x167 > V [libjvm.so+0x1206ada] Thread::call_run()+0x180 > V [libjvm.so+0x1012e55] thread_native_entry(Thread*)+0x18f > > This makes it sometimes difficult to see where exactly the methods were called from and sometimes almost impossible when there are multiple invocations of the same method within one method. > > This patch improves this by providing source information (filename + line number) to the native stack traces on Linux similar to what's already done on Windows (see [JDK-8185712](https://bugs.openjdk.java.net/browse/JDK-8185712)): > > Stack: [0x00007f34fca18000,0x00007f34fcb19000], sp=0x00007f34fcb17110, free space=1020k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > V [libjvm.so+0x620d86] Compilation::~Compilation()+0x64 (c1_Compilation.cpp:607) > V [libjvm.so+0x624b92] Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0xec (c1_Compiler.cpp:250) > V [libjvm.so+0x8303ef] CompileBroker::invoke_compiler_on_method(CompileTask*)+0x899 (compileBroker.cpp:2291) > V [libjvm.so+0x82f067] CompileBroker::compiler_thread_loop()+0x3df (compileBroker.cpp:1966) > V [libjvm.so+0x84f0d1] CompilerThread::thread_entry(JavaThread*, JavaThread*)+0x69 (compilerThread.cpp:59) > V [libjvm.so+0x1209329] JavaThread::thread_main_inner()+0x15d (thread.cpp:1297) > V [libjvm.so+0x12091c9] JavaThread::run()+0x167 (thread.cpp:1280) > V [libjvm.so+0x1206ada] Thread::call_run()+0x180 (thread.cpp:358) > V [libjvm.so+0x1012e55] thread_native_entry(Thread*)+0x18f (os_linux.cpp:705) > > For Linux, we need to parse the debug symbols which are generated by GCC in DWARF - a standardized debugging format. This patch adds support for DWARF 4, the default of GCC 10.x, for 32 and 64 bit architectures (tested with x86_32, x86_64 and AArch64). DWARF 5 is not supported as it was still experimental and not generated for HotSpot. However, newer GCC version may soon generate DWARF 5 by default in which case this parser either needs to be extended or the build of HotSpot configured to only emit DWARF 4. > > The code follows the parsing steps described in the official DWARF 4 spec: https://dwarfstd.org/doc/DWARF4.pdf > I added references to the corresponding sections throughout the code. However, I tried to explain the steps from the DWARF spec directly in the code (method names, comments etc.). This allows to follow the code without the need to actually deep dive into the spec. > > The comments at the `Dwarf` class in the `elf.hpp` file explain in more detail how a DWARF file is structured and how the parsing algorithm works to get to the filename and line number information. There are more class comments throughout the `elf.hpp` file about how different DWARF sections are structured and how the parsing algorithm needs to fetch the required information. Therefore, I will not repeat the exact workings of the algorithm here but refer to the code comments. I've tried to add as much information as possible to improve the readability. > > Generally, I've tried to stay away from adding any assertions as this code is almost always executed when already processing a VM error. Instead, the DWARF parser aims to just exit gracefully and possibly omit source information for a stack frame instead of risking to stop writing the hs_err file when an assertion would have failed. To debug failures, `-Xlog:dwarf` can be used with `info`, `debug` or `trace` which provides logging messages throughout parsing. > > **Testing:** > Apart from manual testing, I've added two kinds of tests: > - A JTreg test: Spawns new VMs to let them crash in various ways. The test reads the created hs_err files to check if the DWARF parsing could correctly find the filename and line number. For normal HotSpot files, I could not check against hardcoded filenames and line numbers as they are subject to change (especially line number can quickly become different). I therefore just added some sanity checks in the form of "found a non-empty file" and "found a non-zero line number". On top of that, I added tests that let the VM crash in custom C files (which will not change). This enables an additional verification of hardcoded filenames and line numbers. > - Gtests: Directly calling the `get_source()` method which initiates DWARF parsing. Tested some special cases, for example, having a buffer that is not big enough to store the filename. > > On top of that, there are also existing JTreg tests that call `-XX:NativeMemoryTracking=detail` which will print a native stack trace with the new source information. These tests were also run as part of the standard tier testing and can be considered as sanity tests for this implementation. > > To make tests work in our infrastructure or if some other setups want to have debug symbols at different locations, I've added support for an additional `_JVM_DWARF_PATH` environment variable. This variable can specify a path from which the DWARF symbol file should be read by the parser if the default locations do not contain debug symbols (required some `make` changes). This is similar to what's done on Windows with `_NT_SYMBOL_PATH`. The JTreg test, however, also works if there are no symbols available. In that case, the test just skips all the assertion checks for the filename and line number. > > I haven't run any specific performance testing as this new code is mainly executed when an error will exit the VM and only if symbol files are available (which is normally not the case when using Java release builds as a user). > > Special thanks to @tschatzl for giving me some pointers to start based on his knowledge from a DWARF 2 parser he once wrote in Pascal and for discussing approaches on how to retrieve the source information and to @erikj79 for providing help for the changes required for `make`! > > Thanks, > Christian Christian Hagedorn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 69 commits: - Merge branch 'master' into JDK-8242181 - Exclude TestDwarf.java when run with product because TraceDwarf is a develop flag - Merge branch 'master' into JDK-8242181 - Merge branch 'master' into JDK-8242181 - Fix TestDwarf for older GCC versions - Change logging from UL to tty based with new TraceDwarfLevel develop flag - Add support to parse the .debug_line section in DWARF 2 as emitted by GCC 8, add some comments - Merge branch 'master' into JDK-8242181 - Merge branch 'master' into JDK-8242181 - Merge branch 'master' into JDK-8242181 - ... and 59 more: https://git.openjdk.org/jdk/compare/d8f4e97b...33c924ef ------------- Changes: https://git.openjdk.org/jdk/pull/7126/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=7126&range=12 Stats: 2781 lines in 18 files changed: 2684 ins; 41 del; 56 mod Patch: https://git.openjdk.org/jdk/pull/7126.diff Fetch: git fetch https://git.openjdk.org/jdk pull/7126/head:pull/7126 PR: https://git.openjdk.org/jdk/pull/7126 From ysuenaga at openjdk.org Thu Jul 7 09:35:24 2022 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Thu, 7 Jul 2022 09:35:24 GMT Subject: RFR: 8289646: configure script failed on WSL [v3] In-Reply-To: References: <3c1FcymALB5PYxsyuyGLLJ2Iux5_LjxHqyNKy6tVBts=.94e5e53e-d239-41a2-b8f3-c9d28df86485@github.com> Message-ID: On Wed, 6 Jul 2022 17:47:21 GMT, Magnus Ihse Bursie wrote: > I'm worried that with the patch you are proposing, we will unconditinonally add `.exe` to any path that is not existing, which will make the next test fail (since then the path with the addition of `.exe` will most likely not exist either). In contrast, No, if ".exe" does not exist as a executable, it would be in fallback code as following (L171). So this patch wouldn't break current behavior. (Maybe it is more suitable to use return value from `ls` command to check file / dir exists - but current code uses `-e` in fallback code.) 149 # Store current unix path 150 unixpath="$path" 151 # If $unixpath does not exist, add .exe (needed on WSL) 152 if [[ ! -e "$unixpath" ]]; then 153 unixpath="$unixpath.exe" 154 fi 155 # Now turn it into a windows path 156 winpath="$($PATHTOOL -w "$unixpath" 2>/dev/null)" 157 if [[ $? -eq 0 && -e "$unixpath" ]]; then : 171 else 172 # On WSL1, PATHTOOL will fail for files in envroot. If the unix path 173 # exists, we assume that $path is a valid unix path. 174 175 if [[ ! -e $path ]]; then 176 if [[ -e $path.exe ]]; then 177 path="$path.exe" 178 else 179 if [[ $QUIET != true ]]; then 180 echo fixpath: warning: Path "'"$path"'" does not exist >&2 181 fi 182 # This is not a fatal error, maybe the path will be created later on 183 fi 184 fi 185 fi > I believe the old code could accept stuff like /tmp/foo/bar, if /tmp/foo were a valid directory, but the file /tmp/foo/bar did not exist yet. > > I don't have any ready access to a Windows machine right now (is on the verge of going on vacation for the summer), but can you verify that either: > > 1. the code prior to your fix would not accept a path like /tmp/foo/bar before, or that > 2. your code will still accept it (this does not seem likely if I read the code correctly). I got same result both WSL 0.60.0.0 and 0.61.8.0 . We can get `/tmp/foo/bar` in both case. * current behavior (master branch): $ ./make/scripts/fixpath.sh import /tmp/foo/bar ------------- PR: https://git.openjdk.org/jdk/pull/9357 From alanb at openjdk.org Thu Jul 7 09:50:39 2022 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 7 Jul 2022 09:50:39 GMT Subject: RFR: 8289834: Add SBCS and DBCS Only EBCDIC charsets In-Reply-To: References: Message-ID: <6YYa4t3fubjt79BqFSmZ6N-_KfD75m56Pxr3Da_08Lg=.7cbf3637-bcfe-4ba5-a88f-f20ea7597042@github.com> On Wed, 6 Jul 2022 16:18:08 GMT, Ichiroh Takiguchi wrote: > Discussions are available on : > [JDK-8289834](https://bugs.openjdk.org/browse/JDK-8289834): Add SBCS and DBCS Only EBCDIC charsets Yes, I think this need discussion on whether the JDK really needs to keep including and adding more EBCDIC charsets. I understand they can be useful for someone using JDBC to connect to a database on z/OS but this scenario would work equally well if the EBCDIC charsets were deployed on the class path or module path. Do you know if the icu4j project is still alive? I've often wondered why there wasn't more use of the provider mechanism. ------------- PR: https://git.openjdk.org/jdk/pull/9399 From ihse at openjdk.org Thu Jul 7 10:21:45 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 7 Jul 2022 10:21:45 GMT Subject: RFR: 8289646: configure script failed on WSL [v3] In-Reply-To: <3c1FcymALB5PYxsyuyGLLJ2Iux5_LjxHqyNKy6tVBts=.94e5e53e-d239-41a2-b8f3-c9d28df86485@github.com> References: <3c1FcymALB5PYxsyuyGLLJ2Iux5_LjxHqyNKy6tVBts=.94e5e53e-d239-41a2-b8f3-c9d28df86485@github.com> Message-ID: On Tue, 5 Jul 2022 03:07:10 GMT, Yasumasa Suenaga wrote: >> configure failed as following when I run it on WSL 1. >> >> >> checking for version string... 20-internal-adhoc.yasuenag.jdk >> configure: Found potential Boot JDK using configure arguments >> configure: The command for java_to_test, which resolves as "/mnt/d/java/jdk-18/bin/java", can not be found. >> configure: error: Cannot locate /mnt/d/java/jdk-18/bin/java >> configure exiting with result code 1 >> >> >> fixpath.sh would attempt to add ".exe" (e.g. "java" -> "java.exe") if `wslpath -w" failed (returns non-zero value). However it returns zero even if the path does not exist in recent WSL (v0.61.4 at least). >> >> WSL v0.60.0.0 >> >> $ wslpath -w silver-bullet >> wslpath: silver-bullet: No such file or directory >> $ echo $? >> 1 >> >> >> WSL v0.61.4.0 >> >> $ wslpath -w silver-bullet >> silver-bullet >> $ echo $? >> 0 >> >> >> We should add ".exe" at the tail of path regardless of return value from wslpath. > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Add to check unixpath existing I don't get it, you are saying that in mainline you get no warning but with your patch you get a warning, and yet you claim behavior is the same? On one hand, it seems like the latter behavior is indeed more correct, if you pass a path that do not exist. (And I'm curious as to why this warning did not trigger in mainline?) But, in our configure script, we are not calling `fixpath import` with the `-q` option, so this new warning will leak through. I think we ought to use `-q`, though, and I was a bit surprised at noticing that we do not. So, it seems that the warning is warranted and we should be able to cope with it, but I don't understand why it does not show up in mainline, and I am worried about changing the behavior. And overall, I still think it sounds like a risky and not really warranted behavior to unconditionally add .exe, regardless of if this file exists or not, and then hope that this will fail later on if it does not exists. What is your rationale for *not* verifying the presence of the .exe version before adding the extension? I'm sorry I'm so anti, it's just that we have severely lacking methods of verifying the correctness of fixpath.sh, and historically even the most innocuous changes in path conversion on Windows have lead to breakage in odd circumstances, so I'm naturally extremely conservative about changes here. ------------- PR: https://git.openjdk.org/jdk/pull/9357 From ysuenaga at openjdk.org Thu Jul 7 11:56:45 2022 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Thu, 7 Jul 2022 11:56:45 GMT Subject: RFR: 8289646: configure script failed on WSL [v3] In-Reply-To: References: <3c1FcymALB5PYxsyuyGLLJ2Iux5_LjxHqyNKy6tVBts=.94e5e53e-d239-41a2-b8f3-c9d28df86485@github.com> Message-ID: <56w0w3pBbwEr3l9ML2ncx3ldd2n0LVNURx8T9ZxLeYg=.37ca29c9-4bb4-4c5e-9093-9dd535058b9c@github.com> On Thu, 7 Jul 2022 10:18:15 GMT, Magnus Ihse Bursie wrote: > I don't get it, you are saying that in mainline you get no warning but with your patch you get a warning, and yet you claim behavior is the same? > > On one hand, it seems like the latter behavior is indeed more correct, if you pass a path that do not exist. (And I'm curious as to why this warning did not trigger in mainline?) Sorry, unfortunately my laptop (WSL 0.60.0.0) seems to be updated to 0.61.8.0 silently during the test... I got following result current fixpath.sh on older WSL (on Windows 10 - it is not updated because it is offline!) $ ./make/scripts/fixpath.sh import /tmp/foo/bar fixpath: warning: Path '/tmp/foo/bar' does not exist ------------- PR: https://git.openjdk.org/jdk/pull/9357 From ihse at openjdk.org Thu Jul 7 12:50:50 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 7 Jul 2022 12:50:50 GMT Subject: RFR: 8289646: configure script failed on WSL [v3] In-Reply-To: <3c1FcymALB5PYxsyuyGLLJ2Iux5_LjxHqyNKy6tVBts=.94e5e53e-d239-41a2-b8f3-c9d28df86485@github.com> References: <3c1FcymALB5PYxsyuyGLLJ2Iux5_LjxHqyNKy6tVBts=.94e5e53e-d239-41a2-b8f3-c9d28df86485@github.com> Message-ID: On Tue, 5 Jul 2022 03:07:10 GMT, Yasumasa Suenaga wrote: >> configure failed as following when I run it on WSL 1. >> >> >> checking for version string... 20-internal-adhoc.yasuenag.jdk >> configure: Found potential Boot JDK using configure arguments >> configure: The command for java_to_test, which resolves as "/mnt/d/java/jdk-18/bin/java", can not be found. >> configure: error: Cannot locate /mnt/d/java/jdk-18/bin/java >> configure exiting with result code 1 >> >> >> fixpath.sh would attempt to add ".exe" (e.g. "java" -> "java.exe") if `wslpath -w" failed (returns non-zero value). However it returns zero even if the path does not exist in recent WSL (v0.61.4 at least). >> >> WSL v0.60.0.0 >> >> $ wslpath -w silver-bullet >> wslpath: silver-bullet: No such file or directory >> $ echo $? >> 1 >> >> >> WSL v0.61.4.0 >> >> $ wslpath -w silver-bullet >> silver-bullet >> $ echo $? >> 0 >> >> >> We should add ".exe" at the tail of path regardless of return value from wslpath. > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Add to check unixpath existing Ok, fine, but if it breaks, you fix it. ? ------------- Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.org/jdk/pull/9357 From ysuenaga at openjdk.org Fri Jul 8 00:10:06 2022 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Fri, 8 Jul 2022 00:10:06 GMT Subject: Integrated: 8289646: configure script failed on WSL In-Reply-To: References: Message-ID: On Mon, 4 Jul 2022 03:56:03 GMT, Yasumasa Suenaga wrote: > configure failed as following when I run it on WSL 1. > > > checking for version string... 20-internal-adhoc.yasuenag.jdk > configure: Found potential Boot JDK using configure arguments > configure: The command for java_to_test, which resolves as "/mnt/d/java/jdk-18/bin/java", can not be found. > configure: error: Cannot locate /mnt/d/java/jdk-18/bin/java > configure exiting with result code 1 > > > fixpath.sh would attempt to add ".exe" (e.g. "java" -> "java.exe") if `wslpath -w" failed (returns non-zero value). However it returns zero even if the path does not exist in recent WSL (v0.61.4 at least). > > WSL v0.60.0.0 > > $ wslpath -w silver-bullet > wslpath: silver-bullet: No such file or directory > $ echo $? > 1 > > > WSL v0.61.4.0 > > $ wslpath -w silver-bullet > silver-bullet > $ echo $? > 0 > > > We should add ".exe" at the tail of path regardless of return value from wslpath. This pull request has now been integrated. Changeset: 3f1174aa Author: Yasumasa Suenaga URL: https://git.openjdk.org/jdk/commit/3f1174aa4709aabcfde8b40deec88b8ed466cc06 Stats: 8 lines in 1 file changed: 2 ins; 3 del; 3 mod 8289646: configure script failed on WSL Reviewed-by: ihse ------------- PR: https://git.openjdk.org/jdk/pull/9357 From duke at openjdk.org Fri Jul 8 14:33:40 2022 From: duke at openjdk.org (George Adams) Date: Fri, 8 Jul 2022 14:33:40 GMT Subject: RFR: 8290000: Bump macOS GitHub actions to macOS 11 [v4] In-Reply-To: <2dkE2-KXoLMjRr8co8_N0UmmqMG5TRa7bCp-Qr6IEf0=.604a183f-b2cd-45b9-a1e8-557a3009ad97@github.com> References: <2dkE2-KXoLMjRr8co8_N0UmmqMG5TRa7bCp-Qr6IEf0=.604a183f-b2cd-45b9-a1e8-557a3009ad97@github.com> Message-ID: > macOS 10.15 has been deprecated for some time and will be removed completely on August 30th. See https://github.com/actions/virtual-environments#available-environments and https://github.com/actions/virtual-environments/issues/5583 for context. > > It's also worth pointing out that they are shutting down the agents already which means that we likely see longer wait times for executors so this should speed up the workflow for developers. We'll need to backport this all the way down to JDK8u to avoid breaking the CI system. George Adams has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: switch to macos-11 as 12 doesn't have toolchain ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9426/files - new: https://git.openjdk.org/jdk/pull/9426/files/d65f5d06..bbb2758d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9426&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9426&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9426.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9426/head:pull/9426 PR: https://git.openjdk.org/jdk/pull/9426 From duke at openjdk.org Fri Jul 8 09:58:21 2022 From: duke at openjdk.org (George Adams) Date: Fri, 8 Jul 2022 09:58:21 GMT Subject: RFR: 8290000: Bump macOS GitHub actions to macOS 12 Message-ID: <2dkE2-KXoLMjRr8co8_N0UmmqMG5TRa7bCp-Qr6IEf0=.604a183f-b2cd-45b9-a1e8-557a3009ad97@github.com> macOS 10.15 has been deprecated for some time and will be removed completely on August 30th. See https://github.com/actions/virtual-environments#available-environments and https://github.com/actions/virtual-environments/issues/5583 for context. It's also worth pointing out that they are shutting down the agents already which means that we likely see longer wait times for executors so this should speed up the workflow for developers. We'll need to backport this all the way down to JDK8u to avoid breaking the CI system. ------------- Commit messages: - Bump macOS GitHub actions to macOS 12 Changes: https://git.openjdk.org/jdk/pull/9426/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9426&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290000 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/9426.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9426/head:pull/9426 PR: https://git.openjdk.org/jdk/pull/9426 From duke at openjdk.org Fri Jul 8 11:17:38 2022 From: duke at openjdk.org (George Adams) Date: Fri, 8 Jul 2022 11:17:38 GMT Subject: RFR: 8290000: Bump macOS GitHub actions to macOS 12 [v2] In-Reply-To: <2dkE2-KXoLMjRr8co8_N0UmmqMG5TRa7bCp-Qr6IEf0=.604a183f-b2cd-45b9-a1e8-557a3009ad97@github.com> References: <2dkE2-KXoLMjRr8co8_N0UmmqMG5TRa7bCp-Qr6IEf0=.604a183f-b2cd-45b9-a1e8-557a3009ad97@github.com> Message-ID: <-zMSJ6YKdvV-ENZhHhyjFhlP0dODFXHhbk9HnszIZig=.f35354e9-0ed1-4ef2-8715-1b9a585869d6@github.com> > macOS 10.15 has been deprecated for some time and will be removed completely on August 30th. See https://github.com/actions/virtual-environments#available-environments and https://github.com/actions/virtual-environments/issues/5583 for context. > > It's also worth pointing out that they are shutting down the agents already which means that we likely see longer wait times for executors so this should speed up the workflow for developers. We'll need to backport this all the way down to JDK8u to avoid breaking the CI system. George Adams has updated the pull request incrementally with one additional commit since the last revision: bump xcode ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9426/files - new: https://git.openjdk.org/jdk/pull/9426/files/4c31343f..c3acca21 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9426&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9426&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/9426.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9426/head:pull/9426 PR: https://git.openjdk.org/jdk/pull/9426 From duke at openjdk.org Fri Jul 8 11:24:12 2022 From: duke at openjdk.org (George Adams) Date: Fri, 8 Jul 2022 11:24:12 GMT Subject: RFR: 8290000: Bump macOS GitHub actions to macOS 12 [v3] In-Reply-To: <2dkE2-KXoLMjRr8co8_N0UmmqMG5TRa7bCp-Qr6IEf0=.604a183f-b2cd-45b9-a1e8-557a3009ad97@github.com> References: <2dkE2-KXoLMjRr8co8_N0UmmqMG5TRa7bCp-Qr6IEf0=.604a183f-b2cd-45b9-a1e8-557a3009ad97@github.com> Message-ID: > macOS 10.15 has been deprecated for some time and will be removed completely on August 30th. See https://github.com/actions/virtual-environments#available-environments and https://github.com/actions/virtual-environments/issues/5583 for context. > > It's also worth pointing out that they are shutting down the agents already which means that we likely see longer wait times for executors so this should speed up the workflow for developers. We'll need to backport this all the way down to JDK8u to avoid breaking the CI system. George Adams has updated the pull request incrementally with one additional commit since the last revision: switch to macos-11 as 12 doesn't have toolchain ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9426/files - new: https://git.openjdk.org/jdk/pull/9426/files/c3acca21..d65f5d06 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9426&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9426&range=01-02 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/9426.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9426/head:pull/9426 PR: https://git.openjdk.org/jdk/pull/9426 From duke at openjdk.org Fri Jul 8 18:25:41 2022 From: duke at openjdk.org (Nikita Gubarkov) Date: Fri, 8 Jul 2022 18:25:41 GMT Subject: RFR: 8289189: Configure fails on WSL1 In-Reply-To: <5b5npslmm6Hmf6rRtQvHy6Q6HLwIRv0Bdf9j5PNawUc=.df61881a-1df1-4d71-bc21-8dae9d82586a@github.com> References: <5b5npslmm6Hmf6rRtQvHy6Q6HLwIRv0Bdf9j5PNawUc=.df61881a-1df1-4d71-bc21-8dae9d82586a@github.com> Message-ID: <-FXEEvFwcsQLC4cY_5LooXqMNTeZnlSBTYsIkGaaB3Q=.33820f3c-3788-4827-a10a-a3ed7f9cc39d@github.com> On Sun, 26 Jun 2022 12:31:22 GMT, Nikita Gubarkov wrote: > Use temp directory for autoconf on both WSL1 and WSL2 Thanks! On newer WSL it works indeed. ------------- PR: https://git.openjdk.org/jdk/pull/9289 From duke at openjdk.org Fri Jul 8 18:25:42 2022 From: duke at openjdk.org (Nikita Gubarkov) Date: Fri, 8 Jul 2022 18:25:42 GMT Subject: Withdrawn: 8289189: Configure fails on WSL1 In-Reply-To: <5b5npslmm6Hmf6rRtQvHy6Q6HLwIRv0Bdf9j5PNawUc=.df61881a-1df1-4d71-bc21-8dae9d82586a@github.com> References: <5b5npslmm6Hmf6rRtQvHy6Q6HLwIRv0Bdf9j5PNawUc=.df61881a-1df1-4d71-bc21-8dae9d82586a@github.com> Message-ID: On Sun, 26 Jun 2022 12:31:22 GMT, Nikita Gubarkov wrote: > Use temp directory for autoconf on both WSL1 and WSL2 This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/9289 From George.Adams at microsoft.com Mon Jul 11 20:30:38 2022 From: George.Adams at microsoft.com (George Adams) Date: Mon, 11 Jul 2022 20:30:38 +0000 Subject: GitHub workflows using setup-java action instead of hardcoded URLs Message-ID: Hi all, I was speaking with Christoph Clanger today about the GitHub actions rewrite which has already made contributing so much simpler. I wanted to see if there was an interest in switching to using the actions/setup-java GitHub action as a way of handling the Boot JDK installation rather than the current hardcoded URLs defined here https://github.com/openjdk/jdk/blob/master/make/conf/github-actions.conf#L31-L41 If people think this is a good idea then I?ll submit a patch for review this week. Thanks George -------------- next part -------------- An HTML attachment was scrubbed... URL: From ecki at zusammenkunft.net Thu Jul 7 23:16:10 2022 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Thu, 7 Jul 2022 23:16:10 +0000 Subject: RFR: 8289834: Add SBCS and DBCS Only EBCDIC charsets In-Reply-To: <6YYa4t3fubjt79BqFSmZ6N-_KfD75m56Pxr3Da_08Lg=.7cbf3637-bcfe-4ba5-a88f-f20ea7597042@github.com> References: <6YYa4t3fubjt79BqFSmZ6N-_KfD75m56Pxr3Da_08Lg=.7cbf3637-bcfe-4ba5-a88f-f20ea7597042@github.com> Message-ID: And also there is no reason why db drivers or host connectors should not ship their own charset support (Oracle JDBC for example had nls_charset addons. My employer also ship a custom EBCDIC encoding which includes some compatibility hacks, and that took some effort to adopt it to the missing ext mechanism). Having said that, with JPMS a ?legacy ebcdic? encoding module would be possible while still being optional. Maybe in the future a mechanism for modules which can be added (instead of removed) from standard distribution would make that nicer? Is there a performance restriction for charset if they are not part of a platform module (optimized string access)? Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: core-libs-dev im Auftrag von Alan Bateman Gesendet: Thursday, July 7, 2022 11:50:39 AM An: build-dev at openjdk.org ; core-libs-dev at openjdk.org ; i18n-dev at openjdk.org Betreff: Re: RFR: 8289834: Add SBCS and DBCS Only EBCDIC charsets On Wed, 6 Jul 2022 16:18:08 GMT, Ichiroh Takiguchi wrote: > Discussions are available on : > [JDK-8289834](https://bugs.openjdk.org/browse/JDK-8289834): Add SBCS and DBCS Only EBCDIC charsets Yes, I think this need discussion on whether the JDK really needs to keep including and adding more EBCDIC charsets. I understand they can be useful for someone using JDBC to connect to a database on z/OS but this scenario would work equally well if the EBCDIC charsets were deployed on the class path or module path. Do you know if the icu4j project is still alive? I've often wondered why there wasn't more use of the provider mechanism. ------------- PR: https://git.openjdk.org/jdk/pull/9399 -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Tue Jul 12 01:24:24 2022 From: david.holmes at oracle.com (David Holmes) Date: Tue, 12 Jul 2022 11:24:24 +1000 Subject: GitHub workflows using setup-java action instead of hardcoded URLs In-Reply-To: References: Message-ID: <7cca740b-6237-7d0c-1a34-7727716ef772@oracle.com> Hi George, On 12/07/2022 6:30 am, George Adams wrote: > Hi all, > > I was speaking with Christoph Clanger today about the GitHub actions > rewrite which has already > made contributing so much simpler. > > I wanted to see if there was an interest in switching to using the > actions/setup-java GitHub action > as a way of handling the Boot JDK installation rather than the current > hardcoded URLs defined here > https://github.com/openjdk/jdk/blob/master/make/conf/github-actions.conf#L31-L41 > > > If people think this is a good idea then I?ll submit a patch for review > this week. I don't really see any benefit to doing this, especially when the existing hardcoded downloads do not even appear to be available via setup-java. And even if they were we would just replace a fixed known URL with a fixed known (java-version, distribution) pair of arguments to setup-java. And setup-java seems to do far more than what we need for our GHA testing. Just my 2c. Cheers, David > > Thanks > > George > From George.Adams at microsoft.com Tue Jul 12 09:23:34 2022 From: George.Adams at microsoft.com (George Adams) Date: Tue, 12 Jul 2022 09:23:34 +0000 Subject: [EXTERNAL] Re: GitHub workflows using setup-java action instead of hardcoded URLs In-Reply-To: <7cca740b-6237-7d0c-1a34-7727716ef772@oracle.com> References: <7cca740b-6237-7d0c-1a34-7727716ef772@oracle.com> Message-ID: H David, The key difference is that we wouldn?t nee to keep updating the full version number/checksum. We could ofcourse use the oracle-actions/setup-java and do something like this: - name: 'Set up latest Oracle JDK 18' uses: oracle-actions/setup-java at v1 with: website: oracle.com release: 18 I?m more than happy to leave the codebase as it is but I don?t like the way that we have to keep updating the version number/checksum. Thanks George From: David Holmes Date: Tuesday, 12 July 2022 at 02:24 To: George Adams , build-dev at openjdk.org Subject: [EXTERNAL] Re: GitHub workflows using setup-java action instead of hardcoded URLs [You don't often get email from david.holmes at oracle.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] Hi George, On 12/07/2022 6:30 am, George Adams wrote: > Hi all, > > I was speaking with Christoph Clanger today about the GitHub actions > rewrite which has already > made contributing so much simpler. > > I wanted to see if there was an interest in switching to using the > actions/setup-java GitHub action > as a way of handling the Boot JDK installation rather than the current > hardcoded URLs defined here > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenjdk%2Fjdk%2Fblob%2Fmaster%2Fmake%2Fconf%2Fgithub-actions.conf%23L31-L41&data=05%7C01%7CGeorge.Adams%40microsoft.com%7Cda1703f1651e40f195b408da63a54a13%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637931858846280896%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=bVhVDzv%2FJxXCeVgpDGVi8sdxOTQZvT6R4730ay%2BU%2Bk4%3D&reserved=0 > > > If people think this is a good idea then I?ll submit a patch for review > this week. I don't really see any benefit to doing this, especially when the existing hardcoded downloads do not even appear to be available via setup-java. And even if they were we would just replace a fixed known URL with a fixed known (java-version, distribution) pair of arguments to setup-java. And setup-java seems to do far more than what we need for our GHA testing. Just my 2c. Cheers, David > > Thanks > > George > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Tue Jul 12 09:30:20 2022 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 12 Jul 2022 10:30:20 +0100 Subject: [EXTERNAL] Re: GitHub workflows using setup-java action instead of hardcoded URLs In-Reply-To: References: <7cca740b-6237-7d0c-1a34-7727716ef772@oracle.com> Message-ID: <4aa31e6e-4286-9683-56c4-fcffeea9a540@oracle.com> On 12/07/2022 10:23, George Adams wrote: > > H David, > > The key difference is that we wouldn?t nee to keep updating the full > version number/checksum. We could ofcourse use the > oracle-actions/setup-java > and do something like > this: ? - name: 'Set up latest Oracle JDK 18' > > ??? uses: oracle-actions/setup-java at v1 > > ??? with: > > ????? website: oracle.com > > ????? release: 18 > > I?m more than happy to leave the codebase as it is but I don?t like > the way that we have to keep updating the version number/checksum. > > Bumping the version of the boot JDK is something that happens during every release, usually soon after the GA of the previous release. I don't think you can avoid that. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From George.Adams at microsoft.com Tue Jul 12 09:35:50 2022 From: George.Adams at microsoft.com (George Adams) Date: Tue, 12 Jul 2022 09:35:50 +0000 Subject: [EXTERNAL] Re: GitHub workflows using setup-java action instead of hardcoded URLs In-Reply-To: <4aa31e6e-4286-9683-56c4-fcffeea9a540@oracle.com> References: <7cca740b-6237-7d0c-1a34-7727716ef772@oracle.com> <4aa31e6e-4286-9683-56c4-fcffeea9a540@oracle.com> Message-ID: Hu Alan, By using the setup-java action with release set to a major version (e.g 18) it will always pull the latest GA build of OpenJDK for that version. E.g 18 currently sets up jdk-18.0.1+10 in the GitHub actions environment. The point is that by switching to using a setup-java action it would be one fewer task to complete after each GA tag is released. -George From: Alan Bateman Date: Tuesday, 12 July 2022 at 10:30 To: George Adams , build-dev at openjdk.org Subject: Re: [EXTERNAL] Re: GitHub workflows using setup-java action instead of hardcoded URLs On 12/07/2022 10:23, George Adams wrote: H David, The key difference is that we wouldn?t nee to keep updating the full version number/checksum. We could ofcourse use the oracle-actions/setup-java and do something like this: - name: 'Set up latest Oracle JDK 18' uses: oracle-actions/setup-java at v1 with: website: oracle.com release: 18 I?m more than happy to leave the codebase as it is but I don?t like the way that we have to keep updating the version number/checksum. Bumping the version of the boot JDK is something that happens during every release, usually soon after the GA of the previous release. I don't think you can avoid that. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Tue Jul 12 10:03:50 2022 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 12 Jul 2022 11:03:50 +0100 Subject: [EXTERNAL] Re: GitHub workflows using setup-java action instead of hardcoded URLs In-Reply-To: References: <7cca740b-6237-7d0c-1a34-7727716ef772@oracle.com> <4aa31e6e-4286-9683-56c4-fcffeea9a540@oracle.com> Message-ID: <84bb98dd-d623-db24-00d9-da1bd94ad5af@oracle.com> On 12/07/2022 10:35, George Adams wrote: > > Hu Alan, > > By using the setup-java action with release set to a major version > (e.g 18) it will always pull the latest GA build of OpenJDK for that > version. E.g 18 currently sets up jdk-18.0.1+10 in the GitHub actions > environment. The point is that by switching to using a setup-java > action it would be one fewer task to complete after each GA tag is > released. > > So I think you are asking if the boot JDK is bumped when there is an update of the boot JDK released. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From George.Adams at microsoft.com Tue Jul 12 10:04:59 2022 From: George.Adams at microsoft.com (George Adams) Date: Tue, 12 Jul 2022 10:04:59 +0000 Subject: [EXTERNAL] Re: GitHub workflows using setup-java action instead of hardcoded URLs In-Reply-To: <84bb98dd-d623-db24-00d9-da1bd94ad5af@oracle.com> References: <7cca740b-6237-7d0c-1a34-7727716ef772@oracle.com> <4aa31e6e-4286-9683-56c4-fcffeea9a540@oracle.com> <84bb98dd-d623-db24-00d9-da1bd94ad5af@oracle.com> Message-ID: Yes sorry, perhaps I didn?t make that very clear -George From: Alan Bateman Date: Tuesday, 12 July 2022 at 11:04 To: George Adams , build-dev at openjdk.org Subject: Re: [EXTERNAL] Re: GitHub workflows using setup-java action instead of hardcoded URLs On 12/07/2022 10:35, George Adams wrote: Hu Alan, By using the setup-java action with release set to a major version (e.g 18) it will always pull the latest GA build of OpenJDK for that version. E.g 18 currently sets up jdk-18.0.1+10 in the GitHub actions environment. The point is that by switching to using a setup-java action it would be one fewer task to complete after each GA tag is released. So I think you are asking if the boot JDK is bumped when there is an update of the boot JDK released. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From tanksherman27 at gmail.com Tue Jul 12 11:13:54 2022 From: tanksherman27 at gmail.com (Julian Waters) Date: Tue, 12 Jul 2022 19:13:54 +0800 Subject: Minimal JVM Message-ID: Sorry if this sounds like a bit of a silly question, but what's the difference between a Minimal VM (Enabled by --enable-jvm-feature-minimal), and, say, the regular Server VM the build system generates by default? All it seems to do is define MINIMAL_JVM (Which doesn't seem to be used anywhere?), set VMTYPE to "Minimal", and if the target OS is Linux, let strip operate more aggressively and remove everything that isn't needed in the final shared library, as opposed to only debug symbols as per usual. Am I missing something here? best regards, Julian -------------- next part -------------- An HTML attachment was scrubbed... URL: From tanksherman27 at gmail.com Tue Jul 12 11:19:15 2022 From: tanksherman27 at gmail.com (Julian Waters) Date: Tue, 12 Jul 2022 19:19:15 +0800 Subject: Minimal JVM Message-ID: Sorry if this sounds like a bit of a silly question, but what's the difference between a Minimal VM (Enabled by --enable-jvm-feature-minimal), and, say, the regular Server VM the build system generates by default? All it seems to do is define MINIMAL_JVM (Which doesn't seem to be used anywhere?), set VMTYPE to "Minimal", and if the target OS is Linux, let strip operate more aggressively and remove everything that isn't needed in the final shared library, as opposed to only debug symbols as per usual. Am I missing something here? best regards, Julian EDIT: Sent this to the old mailing address initially. Whoops! -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.stuefe at gmail.com Tue Jul 12 12:01:47 2022 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 12 Jul 2022 14:01:47 +0200 Subject: Minimal JVM In-Reply-To: References: Message-ID: Hi Julian, the minimal build filters out a whole bunch of optional JVM subsystems in the configure stage, see https://github.com/openjdk/jdk/blob/04c47da118b2870d1c7525348a2ffdf9cd1cc0a4/make/autoconf/jvm-features.m4#L422-L425 That typically manifests via flags like -DINCLUDE_CDS=0, see hotspot/lib/JvmFeatures.gmk HTH, Cheers, Thomas On Tue, Jul 12, 2022 at 1:24 PM Julian Waters wrote: > Sorry if this sounds like a bit of a silly question, but what's the > difference between a Minimal VM (Enabled by --enable-jvm-feature-minimal), > and, say, the regular Server VM the build system generates by default? All > it seems to do is define MINIMAL_JVM (Which doesn't seem to be used > anywhere?), set VMTYPE to "Minimal", and if the target OS is Linux, let > strip operate more aggressively and remove everything that isn't needed in > the final shared library, as opposed to only debug symbols as per usual. Am > I missing something here? > > best regards, > Julian > > EDIT: Sent this to the old mailing address initially. Whoops! > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Tue Jul 12 13:02:49 2022 From: david.holmes at oracle.com (David Holmes) Date: Tue, 12 Jul 2022 23:02:49 +1000 Subject: [EXTERNAL] Re: GitHub workflows using setup-java action instead of hardcoded URLs In-Reply-To: References: <7cca740b-6237-7d0c-1a34-7727716ef772@oracle.com> <4aa31e6e-4286-9683-56c4-fcffeea9a540@oracle.com> Message-ID: On 12/07/2022 7:35 pm, George Adams wrote: > Hu Alan, > > By using the setup-java action with release set to a major version (e.g > 18) it will always pull the latest GA build of OpenJDK for that version. > E.g 18 currently sets up jdk-18.0.1+10 in the GitHub actions > environment. The point is that by switching to using a setup-java action > it would be one fewer task to complete after each GA tag is released. But we don't update the boot JDK when there are new update releases. Unless there is a reason to change, the boot JDK for 19 will be 18.0.0 GA, and we only bump that number once per release cycle. David > -George > > *From: *Alan Bateman > *Date: *Tuesday, 12 July 2022 at 10:30 > *To: *George Adams , build-dev at openjdk.org > > *Subject: *Re: [EXTERNAL] Re: GitHub workflows using setup-java action > instead of hardcoded URLs > > On 12/07/2022 10:23, George Adams wrote: > > H David, > > The key difference is that we wouldn?t nee to keep updating the full > version number/checksum. We could ofcourse use the > oracle-actions/setup-java > > and do something like this: > > ? - name: 'Set up latest Oracle JDK 18' > > ??? uses: oracle-actions/setup-java at v1 > > ??? with: > > ????? website: oracle.com > > ????? release: 18 > > I?m more than happy to leave the codebase as it is but I don?t like > the way that we have to keep updating the version number/checksum. > > Bumping the version of the boot JDK is something that happens during > every release, usually soon after the GA of the previous release. I > don't think you can avoid that. > > -Alan > From tanksherman27 at gmail.com Wed Jul 13 05:40:59 2022 From: tanksherman27 at gmail.com (Julian Waters) Date: Wed, 13 Jul 2022 13:40:59 +0800 Subject: Minimal JVM In-Reply-To: References: Message-ID: Hi Thomas, Thanks for the explanation! No clue how I missed out something that was right there... best regards, Julian On Tue, Jul 12, 2022 at 8:01 PM Thomas St?fe wrote: > Hi Julian, > > the minimal build filters out a whole bunch of optional JVM subsystems in > the configure stage, see > https://github.com/openjdk/jdk/blob/04c47da118b2870d1c7525348a2ffdf9cd1cc0a4/make/autoconf/jvm-features.m4#L422-L425 > > That typically manifests via flags like -DINCLUDE_CDS=0, > see hotspot/lib/JvmFeatures.gmk > > HTH, Cheers, Thomas > > > On Tue, Jul 12, 2022 at 1:24 PM Julian Waters > wrote: > >> Sorry if this sounds like a bit of a silly question, but what's the >> difference between a Minimal VM (Enabled by --enable-jvm-feature-minimal), >> and, say, the regular Server VM the build system generates by default? All >> it seems to do is define MINIMAL_JVM (Which doesn't seem to be used >> anywhere?), set VMTYPE to "Minimal", and if the target OS is Linux, let >> strip operate more aggressively and remove everything that isn't needed in >> the final shared library, as opposed to only debug symbols as per usual. Am >> I missing something here? >> >> best regards, >> Julian >> >> EDIT: Sent this to the old mailing address initially. Whoops! >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ioi.lam at oracle.com Thu Jul 14 18:02:05 2022 From: ioi.lam at oracle.com (Ioi Lam) Date: Thu, 14 Jul 2022 11:02:05 -0700 Subject: "make hotspot" builds test .obj files first Message-ID: My windows build is very slow, and it spends the first few minutes compiling test_xxx.obj files. Is it possible to build the HotSpot VM .obj files first? Thanks - Ioi $ time make hotspot LOG=info Generating main target list Running make as 'make LOG=info hotspot' Building target 'hotspot' in configuration 'windows-x64-slowdebug' Building JVM variant 'server' with features 'cds compiler1 compiler2 epsilongc g1gc jfr jni-check jvmci jvmti management oracle-src parallelgc serialgc services vm-structs zgc' Updating support/modules_libs/java.base/server/jvm.dll due to 6 file(s) Compiling BUILD_GTEST_LIBJVM_pch.cpp (for jvm.dll) Compiling BUILD_LIBJVM_pch.cpp (for jvm.dll) Compiling gtestMain.cpp (for jvm.dll) Compiling logTestFixture.cpp (for jvm.dll) Compiling metaspaceGtestCommon.cpp (for jvm.dll) Compiling metaspaceGtestContexts.cpp (for jvm.dll) Compiling test_AltHashing.cpp (for jvm.dll) Compiling test_ThreadsListHandle.cpp (for jvm.dll) Compiling test_adaptiveSampler.cpp (for jvm.dll) Compiling test_align.cpp (for jvm.dll) Compiling test_allocationGuard.cpp (for jvm.dll) Compiling test_arena.cpp (for jvm.dll) Compiling test_arenagrowthpolicy.cpp (for jvm.dll) From magnus.ihse.bursie at oracle.com Fri Jul 15 15:51:10 2022 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 15 Jul 2022 17:51:10 +0200 Subject: "make hotspot" builds test .obj files first In-Reply-To: References: Message-ID: <5fd6447b-7de8-1a20-51e6-84b727c6b828@oracle.com> On 2022-07-14 20:02, Ioi Lam wrote: > My windows build is very slow, and it spends the first few minutes > compiling test_xxx.obj files. > > Is it possible to build the HotSpot VM .obj files first? This is on my long list of "nice to have" enhancement: https://bugs.openjdk.org/browse/JDK-8217726 I actually started trying to fix it a few months ago, but ran into some unexpected snags. I honestly do not remember what the problems were right now. The work, as far as I got, is available here: https://github.com/magicus/jdk/tree/move-gtest-to-test Unfortunately this will cause a slight performance penalty when building the entire image from scratch (like in our CI systems) due to missed opportunities of parallelisation (and because make is stupid enough to not utilize the fact that the hotspot dll is done earlier), but it will make pure "make hotspot" builds much faster. If anyone feels like continuing the work, it's all up for grabs. Otherwise I'll get around to it when I get around to it... :-( /Magnus > > Thanks > - Ioi > > $ time make hotspot LOG=info > Generating main target list > Running make as 'make LOG=info hotspot' > Building target 'hotspot' in configuration 'windows-x64-slowdebug' > Building JVM variant 'server' with features 'cds compiler1 compiler2 > epsilongc g1gc jfr jni-check jvmci jvmti management oracle-src > parallelgc serialgc services vm-structs zgc' > Updating support/modules_libs/java.base/server/jvm.dll due to 6 file(s) > Compiling BUILD_GTEST_LIBJVM_pch.cpp (for jvm.dll) > Compiling BUILD_LIBJVM_pch.cpp (for jvm.dll) > Compiling gtestMain.cpp (for jvm.dll) > Compiling logTestFixture.cpp (for jvm.dll) > Compiling metaspaceGtestCommon.cpp (for jvm.dll) > Compiling metaspaceGtestContexts.cpp (for jvm.dll) > Compiling test_AltHashing.cpp (for jvm.dll) > Compiling test_ThreadsListHandle.cpp (for jvm.dll) > Compiling test_adaptiveSampler.cpp (for jvm.dll) > Compiling test_align.cpp (for jvm.dll) > Compiling test_allocationGuard.cpp (for jvm.dll) > Compiling test_arena.cpp (for jvm.dll) > Compiling test_arenagrowthpolicy.cpp (for jvm.dll) > From wetmore at openjdk.org Sat Jul 16 01:19:55 2022 From: wetmore at openjdk.org (Bradford Wetmore) Date: Sat, 16 Jul 2022 01:19:55 GMT Subject: RFR: 8289755: Remove --enable-reproducible-build from jib profile In-Reply-To: References: Message-ID: On Tue, 5 Jul 2022 16:01:50 GMT, Magnus Ihse Bursie wrote: > Since [JDK-8288396](https://bugs.openjdk.org/browse/JDK-8288396), the flag ` --enable-reproducible-build` is deprecated, and does nothing but print a warning. It is still included in the jib profiles, which make they output a warning. Not a build team person, but looks ok to me. ------------- Marked as reviewed by wetmore (Reviewer). PR: https://git.openjdk.org/jdk/pull/9379 From asemenyuk at openjdk.org Sat Jul 16 19:45:51 2022 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Sat, 16 Jul 2022 19:45:51 GMT Subject: RFR: 8283707: Support version format on Windows Message-ID: 8283707: Support version format on Windows ------------- Commit messages: - Create separate tests for the new feature. - Trailing whitespaces fixed - Better test coverage - Bugfixes after manual testing - 8283707: Support version format on Windows Changes: https://git.openjdk.org/jdk/pull/9507/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9507&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8283707 Stats: 1316 lines in 15 files changed: 1256 ins; 18 del; 42 mod Patch: https://git.openjdk.org/jdk/pull/9507.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9507/head:pull/9507 PR: https://git.openjdk.org/jdk/pull/9507 From asemenyuk at openjdk.org Sat Jul 16 22:08:12 2022 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Sat, 16 Jul 2022 22:08:12 GMT Subject: RFR: 8283707: Support version format on Windows [v2] In-Reply-To: References: Message-ID: > 8283707: Support version format on Windows Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision: Comments fixed and better naming in the code. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9507/files - new: https://git.openjdk.org/jdk/pull/9507/files/f8b187f2..0e2238da Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9507&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9507&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/9507.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9507/head:pull/9507 PR: https://git.openjdk.org/jdk/pull/9507 From jvernee at openjdk.org Mon Jul 18 12:43:11 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 18 Jul 2022 12:43:11 GMT Subject: RFR: 8290373: Enable lossy conversion warnings on Windows Message-ID: This patch enables lossy conversion warnings (C4244 [1]) for hotspot on Windows/MSVC. Instead of fixing all warnings that were produced from this, I've instead locally disabled the warning in the files that produced warnings. This allows gradually making progress with cleaning up these warnings on a per-file basis, instead of trying to fix all of them in one shot. Out of the ~1100 files that make up hotspot on Windows x64, ~290 have warnings for them disabled (not counting aarch64 files), which means that with this patch ~800 files are protected by enabling this warning globally. Warnings can be fixed in individual files, or groups of files in followup patches, and warnings for those files can be enabled. I'm working on a patch that does the same for GCC, but it produces warnings in about 150 more files (mostly linux/posix specific files), so I wanted to gather feedback on this approach before continuing with that. --- To disable warnings for a file, in most cases the following prelude is added after the last `#include` at the start of a file: PRAGMA_DIAG_PUSH PRAGMA_ALLOW_LOSSY_CONVERSIONS And then the following is added at the end of the file for cpp files, or before closing the header guard for hpp files: PRAGMA_DIAG_POP 1 notable exception are files produced by adlc, which had their code-gen modified to add these lines instead. There were also 2 files that include headers in the middle of the file (ostream.cpp & sharedRuntime.cpp), for which I've added the PRAGMA's after the include block at the start of the file instead. They only included system headers, for which disabling warnings doesn't matter any ways. [1]: https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-levels-3-and-4-c4244?view=msvc-170 ------------- Commit messages: - Rest of the tests - More test - AArch64 - Disable for tests - Fix apostrophe - Last few manual - Automatics - WIP - More disabled warnings - Enable narrow conversion warnings Changes: https://git.openjdk.org/jdk/pull/9516/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9516&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290373 Stats: 1586 lines in 318 files changed: 1579 ins; 3 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/9516.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9516/head:pull/9516 PR: https://git.openjdk.org/jdk/pull/9516 From jwaters at openjdk.org Mon Jul 18 12:43:12 2022 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 18 Jul 2022 12:43:12 GMT Subject: RFR: 8290373: Enable lossy conversion warnings on Windows In-Reply-To: References: Message-ID: <6jYHwEXQDqzoCOx7G0x9td35oeXTqQAbFhbnw9FhiV4=.089830f6-ac2f-4621-b313-e3e5ac584f96@github.com> On Fri, 15 Jul 2022 13:25:57 GMT, Jorn Vernee wrote: > This patch enables lossy conversion warnings (C4244 [1]) for hotspot on Windows/MSVC. Instead of fixing all warnings that were produced from this, I've instead locally disabled the warning in the files that produced warnings. This allows gradually making progress with cleaning up these warnings on a per-file basis, instead of trying to fix all of them in one shot. > > Out of the ~1100 files that make up hotspot on Windows x64, ~290 have warnings for them disabled (not counting aarch64 files), which means that with this patch ~800 files are protected by enabling this warning globally. > > Warnings can be fixed in individual files, or groups of files in followup patches, and warnings for those files can be enabled. > > I'm working on a patch that does the same for GCC, but it produces warnings in about 150 more files (mostly linux/posix specific files), so I wanted to gather feedback on this approach before continuing with that. > > --- > > To disable warnings for a file, in most cases the following prelude is added after the last `#include` at the start of a file: > > PRAGMA_DIAG_PUSH > PRAGMA_ALLOW_LOSSY_CONVERSIONS > > And then the following is added at the end of the file for cpp files, or before closing the header guard for hpp files: > > PRAGMA_DIAG_POP > > 1 notable exception are files produced by adlc, which had their code-gen modified to add these lines instead. There were also 2 files that include headers in the middle of the file (ostream.cpp & sharedRuntime.cpp), for which I've added the PRAGMA's after the include block at the start of the file instead. They only included system headers, for which disabling warnings doesn't matter any ways. > > [1]: https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-levels-3-and-4-c4244?view=msvc-170 Small question: What's the equivalent option to disable the same warning for gcc? (slightly related to https://bugs.openjdk.org/browse/JDK-8288293) ------------- PR: https://git.openjdk.org/jdk/pull/9516 From jvernee at openjdk.org Mon Jul 18 12:43:13 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 18 Jul 2022 12:43:13 GMT Subject: RFR: 8290373: Enable lossy conversion warnings on Windows In-Reply-To: <6jYHwEXQDqzoCOx7G0x9td35oeXTqQAbFhbnw9FhiV4=.089830f6-ac2f-4621-b313-e3e5ac584f96@github.com> References: <6jYHwEXQDqzoCOx7G0x9td35oeXTqQAbFhbnw9FhiV4=.089830f6-ac2f-4621-b313-e3e5ac584f96@github.com> Message-ID: On Sun, 17 Jul 2022 12:54:32 GMT, Julian Waters wrote: >> This patch enables lossy conversion warnings (C4244 [1]) for hotspot on Windows/MSVC. Instead of fixing all warnings that were produced from this, I've instead locally disabled the warning in the files that produced warnings. This allows gradually making progress with cleaning up these warnings on a per-file basis, instead of trying to fix all of them in one shot. >> >> Out of the ~1100 files that make up hotspot on Windows x64, ~290 have warnings for them disabled (not counting aarch64 files), which means that with this patch ~800 files are protected by enabling this warning globally. >> >> Warnings can be fixed in individual files, or groups of files in followup patches, and warnings for those files can be enabled. >> >> I'm working on a patch that does the same for GCC, but it produces warnings in about 150 more files (mostly linux/posix specific files), so I wanted to gather feedback on this approach before continuing with that. >> >> --- >> >> To disable warnings for a file, in most cases the following prelude is added after the last `#include` at the start of a file: >> >> PRAGMA_DIAG_PUSH >> PRAGMA_ALLOW_LOSSY_CONVERSIONS >> >> And then the following is added at the end of the file for cpp files, or before closing the header guard for hpp files: >> >> PRAGMA_DIAG_POP >> >> 1 notable exception are files produced by adlc, which had their code-gen modified to add these lines instead. There were also 2 files that include headers in the middle of the file (ostream.cpp & sharedRuntime.cpp), for which I've added the PRAGMA's after the include block at the start of the file instead. They only included system headers, for which disabling warnings doesn't matter any ways. >> >> [1]: https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-levels-3-and-4-c4244?view=msvc-170 > > Small question: What's the equivalent option to disable the same warning for gcc? (slightly related to https://bugs.openjdk.org/browse/JDK-8288293) @TheShermanTanker It's `-Wconversion`. You will have to disable the warning for non-hotspot binaries to get the equivalent behavior. See this commit: https://github.com/openjdk/jdk/commit/44bebd84c041d62f374bfb6f61685d86e5e41518 ------------- PR: https://git.openjdk.org/jdk/pull/9516 From duke at openjdk.org Mon Jul 18 12:46:49 2022 From: duke at openjdk.org (George Adams) Date: Mon, 18 Jul 2022 12:46:49 GMT Subject: RFR: 8290000: Bump macOS GitHub actions to macOS 11 [v4] In-Reply-To: References: <2dkE2-KXoLMjRr8co8_N0UmmqMG5TRa7bCp-Qr6IEf0=.604a183f-b2cd-45b9-a1e8-557a3009ad97@github.com> Message-ID: <7Kv7NA1OWqHf_P7Pkq5JFuuho0oGo-rcCCeMWG4iLIA=.c223e96a-83aa-48ac-b3eb-9b374d450cbc@github.com> On Fri, 8 Jul 2022 14:33:40 GMT, George Adams wrote: >> macOS 10.15 has been deprecated for some time and will be removed completely on August 30th. See https://github.com/actions/virtual-environments#available-environments and https://github.com/actions/virtual-environments/issues/5583 for context. >> >> It's also worth pointing out that they are shutting down the agents already which means that we likely see longer wait times for executors so this should speed up the workflow for developers. We'll need to backport this all the way down to JDK8u to avoid breaking the CI system. > > George Adams has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > switch to macos-11 as 12 doesn't have toolchain cc @erikj79 @magicus I think this PR likely needs one of you to review it? There is a reasonable sense of urgency here because I'm going to need to backport this down to all versions. ------------- PR: https://git.openjdk.org/jdk/pull/9426 From shade at openjdk.org Mon Jul 18 13:03:08 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 18 Jul 2022 13:03:08 GMT Subject: RFR: 8290000: Bump macOS GitHub actions to macOS 11 [v4] In-Reply-To: References: <2dkE2-KXoLMjRr8co8_N0UmmqMG5TRa7bCp-Qr6IEf0=.604a183f-b2cd-45b9-a1e8-557a3009ad97@github.com> Message-ID: On Fri, 8 Jul 2022 14:33:40 GMT, George Adams wrote: >> macOS 10.15 has been deprecated for some time and will be removed completely on August 30th. See https://github.com/actions/virtual-environments#available-environments and https://github.com/actions/virtual-environments/issues/5583 for context. >> >> It's also worth pointing out that they are shutting down the agents already which means that we likely see longer wait times for executors so this should speed up the workflow for developers. We'll need to backport this all the way down to JDK8u to avoid breaking the CI system. > > George Adams has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > switch to macos-11 as 12 doesn't have toolchain Looks fine to me. XCode 11.7 is listed as the lowest version supported by macos-11 image. I shall wait for some more people to ack this, and then I can sponsor. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.org/jdk/pull/9426 From duke at openjdk.org Mon Jul 18 13:03:09 2022 From: duke at openjdk.org (George Adams) Date: Mon, 18 Jul 2022 13:03:09 GMT Subject: RFR: 8290000: Bump macOS GitHub actions to macOS 11 [v4] In-Reply-To: References: <2dkE2-KXoLMjRr8co8_N0UmmqMG5TRa7bCp-Qr6IEf0=.604a183f-b2cd-45b9-a1e8-557a3009ad97@github.com> Message-ID: On Mon, 18 Jul 2022 12:56:14 GMT, Aleksey Shipilev wrote: >> George Adams has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: >> >> switch to macos-11 as 12 doesn't have toolchain > > Looks fine to me. XCode 11.7 is listed as the lowest version supported by macos-11 image. Thanks for the review @shipilev! Are you willing to sponsor? ------------- PR: https://git.openjdk.org/jdk/pull/9426 From almatvee at openjdk.org Mon Jul 18 21:56:05 2022 From: almatvee at openjdk.org (Alexander Matveev) Date: Mon, 18 Jul 2022 21:56:05 GMT Subject: RFR: 8283707: Support version format on Windows [v2] In-Reply-To: References: Message-ID: On Sat, 16 Jul 2022 22:08:12 GMT, Alexey Semenyuk wrote: >> 8283707: Support version format on Windows > > Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision: > > Comments fixed and better naming in the code. Marked as reviewed by almatvee (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9507 From clanger at openjdk.org Mon Jul 18 22:11:58 2022 From: clanger at openjdk.org (Christoph Langer) Date: Mon, 18 Jul 2022 22:11:58 GMT Subject: RFR: 8290000: Bump macOS GitHub actions to macOS 11 [v4] In-Reply-To: References: <2dkE2-KXoLMjRr8co8_N0UmmqMG5TRa7bCp-Qr6IEf0=.604a183f-b2cd-45b9-a1e8-557a3009ad97@github.com> Message-ID: <2e0s9Tk6tdDRkSJbKXOC8jJGrWQgNQ9hWmpUjs5of0A=.29271d59-8ed1-435d-b9d0-668d30a5cbb9@github.com> On Fri, 8 Jul 2022 14:33:40 GMT, George Adams wrote: >> macOS 10.15 has been deprecated for some time and will be removed completely on August 30th. See https://github.com/actions/virtual-environments#available-environments and https://github.com/actions/virtual-environments/issues/5583 for context. >> >> It's also worth pointing out that they are shutting down the agents already which means that we likely see longer wait times for executors so this should speed up the workflow for developers. We'll need to backport this all the way down to JDK8u to avoid breaking the CI system. > > George Adams has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > switch to macos-11 as 12 doesn't have toolchain I think this should be fine, reading the matrix at https://wiki.openjdk.org/display/Build/Supported+Build+Platforms and taking into account the deprecation of macos-10.15 as runner platform in Github Actions. ------------- Marked as reviewed by clanger (Reviewer). PR: https://git.openjdk.org/jdk/pull/9426 From shade at openjdk.org Tue Jul 19 06:29:04 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 19 Jul 2022 06:29:04 GMT Subject: RFR: 8290000: Bump macOS GitHub actions to macOS 11 [v4] In-Reply-To: References: <2dkE2-KXoLMjRr8co8_N0UmmqMG5TRa7bCp-Qr6IEf0=.604a183f-b2cd-45b9-a1e8-557a3009ad97@github.com> Message-ID: On Fri, 8 Jul 2022 14:33:40 GMT, George Adams wrote: >> macOS 10.15 has been deprecated for some time and will be removed completely on August 30th. See https://github.com/actions/virtual-environments#available-environments and https://github.com/actions/virtual-environments/issues/5583 for context. >> >> It's also worth pointing out that they are shutting down the agents already which means that we likely see longer wait times for executors so this should speed up the workflow for developers. We'll need to backport this all the way down to JDK8u to avoid breaking the CI system. > > George Adams has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > switch to macos-11 as 12 doesn't have toolchain All right then! I was thinking if we should do XCode 12.4 then, to align better with the matrix. But since this patch is targeted for backporting, it would probably be better to stick to the lowest toolchain version. ------------- PR: https://git.openjdk.org/jdk/pull/9426 From duke at openjdk.org Tue Jul 19 06:32:21 2022 From: duke at openjdk.org (George Adams) Date: Tue, 19 Jul 2022 06:32:21 GMT Subject: Integrated: 8290000: Bump macOS GitHub actions to macOS 11 In-Reply-To: <2dkE2-KXoLMjRr8co8_N0UmmqMG5TRa7bCp-Qr6IEf0=.604a183f-b2cd-45b9-a1e8-557a3009ad97@github.com> References: <2dkE2-KXoLMjRr8co8_N0UmmqMG5TRa7bCp-Qr6IEf0=.604a183f-b2cd-45b9-a1e8-557a3009ad97@github.com> Message-ID: <3qXLYgsOqbSjifOvsFFNI9i3-f0Fu2OP0WHRqOxsD04=.1412f72b-3320-4d0b-b151-9dced560680f@github.com> On Fri, 8 Jul 2022 09:45:49 GMT, George Adams wrote: > macOS 10.15 has been deprecated for some time and will be removed completely on August 30th. See https://github.com/actions/virtual-environments#available-environments and https://github.com/actions/virtual-environments/issues/5583 for context. > > It's also worth pointing out that they are shutting down the agents already which means that we likely see longer wait times for executors so this should speed up the workflow for developers. We'll need to backport this all the way down to JDK8u to avoid breaking the CI system. This pull request has now been integrated. Changeset: 4e6cd67f Author: George Adams Committer: Aleksey Shipilev URL: https://git.openjdk.org/jdk/commit/4e6cd67fec3d978f4c8c1aed95a1d09b544eff68 Stats: 4 lines in 3 files changed: 0 ins; 0 del; 4 mod 8290000: Bump macOS GitHub actions to macOS 11 Reviewed-by: shade, clanger ------------- PR: https://git.openjdk.org/jdk/pull/9426 From asemenyuk at openjdk.org Tue Jul 19 17:04:22 2022 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 19 Jul 2022 17:04:22 GMT Subject: Integrated: 8283707: Support version format on Windows In-Reply-To: References: Message-ID: On Fri, 15 Jul 2022 04:37:58 GMT, Alexey Semenyuk wrote: > 8283707: Support version format on Windows This pull request has now been integrated. Changeset: 977e0948 Author: Alexey Semenyuk URL: https://git.openjdk.org/jdk/commit/977e09489dd1f49d8f373ef7b8c5e47fedb82793 Stats: 1316 lines in 15 files changed: 1256 ins; 18 del; 42 mod 8283707: Support version format on Windows Reviewed-by: almatvee ------------- PR: https://git.openjdk.org/jdk/pull/9507 From dlong at openjdk.org Tue Jul 19 20:16:51 2022 From: dlong at openjdk.org (Dean Long) Date: Tue, 19 Jul 2022 20:16:51 GMT Subject: RFR: 8290373: Enable lossy conversion warnings on Windows In-Reply-To: References: Message-ID: On Fri, 15 Jul 2022 13:25:57 GMT, Jorn Vernee wrote: > This patch enables lossy conversion warnings (C4244 [1]) for hotspot on Windows/MSVC. Instead of fixing all warnings that were produced from this, I've instead locally disabled the warning in the files that produced warnings. This allows gradually making progress with cleaning up these warnings on a per-file basis, instead of trying to fix all of them in one shot. > > Out of the ~1100 files that make up hotspot on Windows x64 , ~290 have warnings for them disabled (not counting aarch64 files), which means that with this patch ~800 files are protected by enabling this warning globally. > > Warnings can be fixed in individual files, or groups of files in followup patches, and warnings for those files can be enabled. > > I'm working on a patch that does the same for GCC, but it produces warnings in about 150 more files, so I wanted to gather feedback on this approach before continuing with that. > > --- > > To disable warnings for a file, in most cases the following prelude is added after the last `#include` at the start of a file: > > PRAGMA_DIAG_PUSH > PRAGMA_ALLOW_LOSSY_CONVERSIONS > > And then the following is added at the end of the file for cpp files, or before closing the header guard for hpp files: > > PRAGMA_DIAG_POP > > 1 notable exception are files produced by adlc, which had their code-gen modified to add these lines instead. There were also 2 files that include headers in the middle of the file (ostream.cpp & sharedRuntime.cpp), for which I've added the PRAGMA's after the include block at the start of the file instead. They only included system headers, for which disabling warnings doesn't matter any ways. > > [1]: https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-levels-3-and-4-c4244?view=msvc-170 I thought PRAGMA_DIAG_PUSH/POP are for narrowing the scope of the pragma. So unless we are concatenating .cpp files together, I would think they are not needed for .cpp files if we want to affect the whole file. ------------- PR: https://git.openjdk.org/jdk/pull/9516 From jvernee at openjdk.org Tue Jul 19 20:55:38 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 19 Jul 2022 20:55:38 GMT Subject: RFR: 8290373: Enable lossy conversion warnings on Windows In-Reply-To: References: Message-ID: On Tue, 19 Jul 2022 20:13:35 GMT, Dean Long wrote: >> This patch enables lossy conversion warnings (C4244 [1]) for hotspot on Windows/MSVC. Instead of fixing all warnings that were produced from this, I've instead locally disabled the warning in the files that produced warnings. This allows gradually making progress with cleaning up these warnings on a per-file basis, instead of trying to fix all of them in one shot. >> >> Out of the ~1100 files that make up hotspot on Windows x64 , ~290 have warnings for them disabled (not counting aarch64 files), which means that with this patch ~800 files are protected by enabling this warning globally. >> >> Warnings can be fixed in individual files, or groups of files in followup patches, and warnings for those files can be enabled. >> >> I'm working on a patch that does the same for GCC, but it produces warnings in about 150 more files, so I wanted to gather feedback on this approach before continuing with that. >> >> --- >> >> To disable warnings for a file, in most cases the following prelude is added after the last `#include` at the start of a file: >> >> PRAGMA_DIAG_PUSH >> PRAGMA_ALLOW_LOSSY_CONVERSIONS >> >> And then the following is added at the end of the file for cpp files, or before closing the header guard for hpp files: >> >> PRAGMA_DIAG_POP >> >> 1 notable exception are files produced by adlc, which had their code-gen modified to add these lines instead. There were also 2 files that include headers in the middle of the file (ostream.cpp & sharedRuntime.cpp), for which I've added the PRAGMA's after the include block at the start of the file instead. They only included system headers, for which disabling warnings doesn't matter any ways. >> >> [1]: https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-levels-3-and-4-c4244?view=msvc-170 > > I thought PRAGMA_DIAG_PUSH/POP are for narrowing the scope of the pragma. So unless we are concatenating .cpp files together, I would think they are not needed for .cpp files if we want to affect the whole file. @dean-long That's a good point. The PUSH and POP could be removed for the cpp files. ------------- PR: https://git.openjdk.org/jdk/pull/9516 From jvernee at openjdk.org Wed Jul 20 13:58:07 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 20 Jul 2022 13:58:07 GMT Subject: RFR: 8290373: Enable lossy conversion warnings on Windows [v2] In-Reply-To: References: Message-ID: > This patch enables lossy conversion warnings (C4244 [1]) for hotspot on Windows/MSVC. Instead of fixing all warnings that were produced from this, I've instead locally disabled the warning in the files that produced warnings. This allows gradually making progress with cleaning up these warnings on a per-file basis, instead of trying to fix all of them in one shot. > > Out of the ~1100 files that make up hotspot on Windows x64 , ~290 have warnings for them disabled (not counting aarch64 files), which means that with this patch ~800 files are protected by enabling this warning globally. > > Warnings can be fixed in individual files, or groups of files in followup patches, and warnings for those files can be enabled. > > I'm working on a patch that does the same for GCC, but it produces warnings in about 150 more files, so I wanted to gather feedback on this approach before continuing with that. > > --- > > To disable warnings for a file, in most cases the following prelude is added after the last `#include` at the start of a file: > > PRAGMA_DIAG_PUSH > PRAGMA_ALLOW_LOSSY_CONVERSIONS > > And then the following is added at the end of the file for cpp files, or before closing the header guard for hpp files: > > PRAGMA_DIAG_POP > > 1 notable exception are files produced by adlc, which had their code-gen modified to add these lines instead. There were also 2 files that include headers in the middle of the file (ostream.cpp & sharedRuntime.cpp), for which I've added the PRAGMA's after the include block at the start of the file instead. They only included system headers, for which disabling warnings doesn't matter any ways. > > [1]: https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-levels-3-and-4-c4244?view=msvc-170 Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: Remove PUSH POP from cpp files ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9516/files - new: https://git.openjdk.org/jdk/pull/9516/files/0484768d..7b309eb7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9516&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9516&range=00-01 Stats: 711 lines in 237 files changed: 5 ins; 704 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/9516.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9516/head:pull/9516 PR: https://git.openjdk.org/jdk/pull/9516 From jvernee at openjdk.org Wed Jul 20 14:15:54 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 20 Jul 2022 14:15:54 GMT Subject: RFR: 8290373: Enable lossy conversion warnings on Windows [v3] In-Reply-To: References: Message-ID: > This patch enables lossy conversion warnings (C4244 [1]) for hotspot on Windows/MSVC. Instead of fixing all warnings that were produced from this, I've instead locally disabled the warning in the files that produced warnings. This allows gradually making progress with cleaning up these warnings on a per-file basis, instead of trying to fix all of them in one shot. > > Out of the ~1100 files that make up hotspot on Windows x64 , ~290 have warnings for them disabled (not counting aarch64 files), which means that with this patch ~800 files are protected by enabling this warning globally. > > Warnings can be fixed in individual files, or groups of files in followup patches, and warnings for those files can be enabled. > > I'm working on a patch that does the same for GCC, but it produces warnings in about 150 more files, so I wanted to gather feedback on this approach before continuing with that. > > --- > > To disable warnings for a file, in most cases the following prelude is added after the last `#include` at the start of a file: > > PRAGMA_DIAG_PUSH > PRAGMA_ALLOW_LOSSY_CONVERSIONS > > And then the following is added at the end of the file for cpp files, or before closing the header guard for hpp files: > > PRAGMA_DIAG_POP > > 1 notable exception are files produced by adlc, which had their code-gen modified to add these lines instead. There were also 2 files that include headers in the middle of the file (ostream.cpp & sharedRuntime.cpp), for which I've added the PRAGMA's after the include block at the start of the file instead. They only included system headers, for which disabling warnings doesn't matter any ways. > > [1]: https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-levels-3-and-4-c4244?view=msvc-170 Jorn Vernee has updated the pull request incrementally with two additional commits since the last revision: - Polish - Remove PUSH POP from test files ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9516/files - new: https://git.openjdk.org/jdk/pull/9516/files/7b309eb7..d905b203 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9516&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9516&range=01-02 Stats: 35 lines in 14 files changed: 13 ins; 22 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9516.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9516/head:pull/9516 PR: https://git.openjdk.org/jdk/pull/9516 From jvernee at openjdk.org Wed Jul 20 14:18:49 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 20 Jul 2022 14:18:49 GMT Subject: RFR: 8290373: Enable lossy conversion warnings on Windows [v4] In-Reply-To: References: Message-ID: > This patch enables lossy conversion warnings (C4244 [1]) for hotspot on Windows/MSVC. Instead of fixing all warnings that were produced from this, I've instead locally disabled the warning in the files that produced warnings. This allows gradually making progress with cleaning up these warnings on a per-file basis, instead of trying to fix all of them in one shot. > > Out of the ~1100 files that make up hotspot on Windows x64 , ~290 have warnings for them disabled (not counting aarch64 files), which means that with this patch ~800 files are protected by enabling this warning globally. > > Warnings can be fixed in individual files, or groups of files in followup patches, and warnings for those files can be enabled. > > I'm working on a patch that does the same for GCC, but it produces warnings in about 150 more files, so I wanted to gather feedback on this approach before continuing with that. > > --- > > To disable warnings for a file, in most cases the following prelude is added after the last `#include` at the start of a file: > > PRAGMA_DIAG_PUSH > PRAGMA_ALLOW_LOSSY_CONVERSIONS > > And then the following is added at the end of the file for cpp files, or before closing the header guard for hpp files: > > PRAGMA_DIAG_POP > > 1 notable exception are files produced by adlc, which had their code-gen modified to add these lines instead. There were also 2 files that include headers in the middle of the file (ostream.cpp & sharedRuntime.cpp), for which I've added the PRAGMA's after the include block at the start of the file instead. They only included system headers, for which disabling warnings doesn't matter any ways. > > [1]: https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-levels-3-and-4-c4244?view=msvc-170 Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits: - Merge branch 'master' into Warn_Narrow - Polish pt2 - Polish - Remove PUSH POP from test files - Remove PUSH POP from cpp files - Rest of the tests - More test - AArch64 - Disable for tests - Fix apostrophe - ... and 5 more: https://git.openjdk.org/jdk/compare/1c055076...fb276afd ------------- Changes: https://git.openjdk.org/jdk/pull/9516/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9516&range=03 Stats: 872 lines in 318 files changed: 869 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/9516.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9516/head:pull/9516 PR: https://git.openjdk.org/jdk/pull/9516 From aph at openjdk.org Wed Jul 20 14:21:14 2022 From: aph at openjdk.org (Andrew Haley) Date: Wed, 20 Jul 2022 14:21:14 GMT Subject: RFR: 8290373: Enable lossy conversion warnings on Windows [v3] In-Reply-To: References: Message-ID: On Wed, 20 Jul 2022 14:15:54 GMT, Jorn Vernee wrote: >> This patch enables lossy conversion warnings (C4244 [1]) for hotspot on Windows/MSVC. Instead of fixing all warnings that were produced from this, I've instead locally disabled the warning in the files that produced warnings. This allows gradually making progress with cleaning up these warnings on a per-file basis, instead of trying to fix all of them in one shot. >> >> Out of the ~1100 files that make up hotspot on Windows x64 , ~290 have warnings for them disabled (not counting aarch64 files), which means that with this patch ~800 files are protected by enabling this warning globally. >> >> Warnings can be fixed in individual files, or groups of files in followup patches, and warnings for those files can be enabled. >> >> I'm working on a patch that does the same for GCC, but it produces warnings in about 150 more files, so I wanted to gather feedback on this approach before continuing with that. >> >> --- >> >> To disable warnings for a file, in most cases the following prelude is added after the last `#include` at the start of a file: >> >> PRAGMA_DIAG_PUSH >> PRAGMA_ALLOW_LOSSY_CONVERSIONS >> >> And then the following is added at the end of the file for cpp files, or before closing the header guard for hpp files: >> >> PRAGMA_DIAG_POP >> >> 1 notable exception are files produced by adlc, which had their code-gen modified to add these lines instead. There were also 2 files that include headers in the middle of the file (ostream.cpp & sharedRuntime.cpp), for which I've added the PRAGMA's after the include block at the start of the file instead. They only included system headers, for which disabling warnings doesn't matter any ways. >> >> [1]: https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-levels-3-and-4-c4244?view=msvc-170 > > Jorn Vernee has updated the pull request incrementally with two additional commits since the last revision: > > - Polish > - Remove PUSH POP from test files This feels to me like rather a blunt instrument. IMO, it would be better to use checked_cast() where lossy conversions happen. That would make code easier to understand, and it'd give us warnings when things go wrong. ------------- PR: https://git.openjdk.org/jdk/pull/9516 From jvernee at openjdk.org Wed Jul 20 14:46:04 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 20 Jul 2022 14:46:04 GMT Subject: RFR: 8290373: Enable lossy conversion warnings on Windows [v3] In-Reply-To: References: Message-ID: On Wed, 20 Jul 2022 14:18:45 GMT, Andrew Haley wrote: >> Jorn Vernee has updated the pull request incrementally with two additional commits since the last revision: >> >> - Polish >> - Remove PUSH POP from test files > > This feels to me like rather a blunt instrument. IMO, it would be better to use checked_cast() where lossy conversions happen. That would make code easier to understand, and it'd give us warnings when things go wrong. @theRealAph I think ultimately, each warning site should be inspected, and a bespoke solution should be found. Inserting `checked_cast` is only one of a possible set of solutions. Others being changing the type of variables used, or some wider refactoring. This change was mostly applied mechanically by parsing the build log, and then using a script to insert these lines, with a manual review + 1 or 2 fixups. Making sure the inserted `checked_cast`s are correct seems much harder. I think having `PRAGMA_ALLOW_LOSSY_CONVERSIONS` in the file also sends a much clearer message that: warnings in this file have not been looked at/fixed yet, which I don't think `checked_cast` does. I have my doubts that adding `checked_cast` everywhere is always correct. In some cases the truncation might be the desired behaviour (just not made explicit with a cast), and I don't want to run the risk of breaking such code where the tests don't catch it (while I also don't want to get into a lengthy process of fixing up those cases one by one). The approach I've taken preserves the current behavior of the code, but it also allows for fixing these warnings on a per-file basis. This seems to me like an easier and safer way to make progress. ------------- PR: https://git.openjdk.org/jdk/pull/9516 From aph at openjdk.org Wed Jul 20 15:17:02 2022 From: aph at openjdk.org (Andrew Haley) Date: Wed, 20 Jul 2022 15:17:02 GMT Subject: RFR: 8290373: Enable lossy conversion warnings on Windows [v3] In-Reply-To: References: Message-ID: <_g8tdYQ5mT6j-D2LnVoZvg1yUbb-2bEBWsvEzS68Pro=.550ef5a4-952e-40dc-ae90-5ac26826c03c@github.com> On Wed, 20 Jul 2022 14:42:44 GMT, Jorn Vernee wrote: > This change was mostly applied mechanically by parsing the build log, and then using a script to insert these lines, with a manual review + 1 or 2 fixups. Making sure the inserted `checked_cast`s are correct seems much harder. It is. > I think having `PRAGMA_ALLOW_LOSSY_CONVERSIONS` in the file also sends a much clearer message that: warnings in this file have not been looked at/fixed yet, which I don't think `checked_cast` does. It kinda would, because such casts would have to be considered. But OK. > The approach I've taken preserves the current behavior of the code, but it also allows for fixing these warnings on a per-file basis (besides enabling the warning for the 800 or so files that don't have warnings right now). This seems to me like an easier and safer way to make progress. OK, so this is hopefully a temporary fix. ------------- PR: https://git.openjdk.org/jdk/pull/9516 From jvernee at openjdk.org Wed Jul 20 15:22:47 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 20 Jul 2022 15:22:47 GMT Subject: RFR: 8290373: Enable lossy conversion warnings on Windows [v3] In-Reply-To: <_g8tdYQ5mT6j-D2LnVoZvg1yUbb-2bEBWsvEzS68Pro=.550ef5a4-952e-40dc-ae90-5ac26826c03c@github.com> References: <_g8tdYQ5mT6j-D2LnVoZvg1yUbb-2bEBWsvEzS68Pro=.550ef5a4-952e-40dc-ae90-5ac26826c03c@github.com> Message-ID: On Wed, 20 Jul 2022 15:13:05 GMT, Andrew Haley wrote: > > I think having `PRAGMA_ALLOW_LOSSY_CONVERSIONS` in the file also sends a much clearer message that: warnings in this file have not been looked at/fixed yet, which I don't think `checked_cast` does. > > It kinda would, because such casts would have to be considered. But OK. What I mean is that `checked_cast` can also be used intentionally. So, looking at a particular `checked_cast` it might be hard to tell if this use case should still be address/fixed. or if it has already been addressed and the solution was to use `checked_cast`. > > The approach I've taken preserves the current behavior of the code, but it also allows for fixing these warnings on a per-file basis (besides enabling the warning for the 800 or so files that don't have warnings right now). This seems to me like an easier and safer way to make progress. > > OK, so this is hopefully a temporary fix. Yes, this is not meant to be a long term solution. Just a way of allowing for more incremental progress, as well as a stop gap for files that are good today. ------------- PR: https://git.openjdk.org/jdk/pull/9516 From dholmes at openjdk.org Thu Jul 21 01:55:59 2022 From: dholmes at openjdk.org (David Holmes) Date: Thu, 21 Jul 2022 01:55:59 GMT Subject: RFR: 8290373: Enable lossy conversion warnings on Windows [v4] In-Reply-To: References: Message-ID: On Wed, 20 Jul 2022 14:18:49 GMT, Jorn Vernee wrote: >> This patch enables lossy conversion warnings (C4244 [1]) for hotspot on Windows/MSVC. Instead of fixing all warnings that were produced from this, I've instead locally disabled the warning in the files that produced warnings. This allows gradually making progress with cleaning up these warnings on a per-file basis, instead of trying to fix all of them in one shot. i.e. it is not meant as a long term solution, but as a way of allowing incremental progress. >> >> Out of the ~1100 files that make up hotspot on Windows x64 , ~290 have warnings for them disabled (not counting aarch64 files), which means that with this patch ~800 files are protected by enabling this warning globally. >> >> Warnings can be fixed in individual files, or groups of files in followup patches, and warnings for those files can be enabled. >> >> I'm working on a patch that does the same for GCC, but it produces warnings in about 150 more files, so I wanted to gather feedback on this approach before continuing with that. >> >> --- >> >> To disable warnings for a file, in most cases the following prelude is added after the last `#include` at the start of a file: >> >> PRAGMA_DIAG_PUSH >> PRAGMA_ALLOW_LOSSY_CONVERSIONS >> >> And then the following is added at the end of the file for cpp files, or before closing the header guard for hpp files: >> >> PRAGMA_DIAG_POP >> >> 1 notable exception are files produced by adlc, which had their code-gen modified to add these lines instead. There were also 2 files that include headers in the middle of the file (ostream.cpp & sharedRuntime.cpp), for which I've added the PRAGMA's after the include block at the start of the file instead. They only included system headers, for which disabling warnings doesn't matter any ways. >> >> [1]: https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-levels-3-and-4-c4244?view=msvc-170 > > Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits: > > - Merge branch 'master' into Warn_Narrow > - Polish pt2 > - Polish > - Remove PUSH POP from test files > - Remove PUSH POP from cpp files > - Rest of the tests > - More test > - AArch64 > - Disable for tests > - Fix apostrophe > - ... and 5 more: https://git.openjdk.org/jdk/compare/1c055076...fb276afd So IIUC the idea here is to turn on this warning to catch lossy conversions going forward, but to suppress the warning on all existing cases in the hope that eventually one day they will get looked at and fixed as appropriate. Is this such an insidious problem that we absolutely must prevent any future occurrences from arising, noting that if they happen in a file already ignoring the warning then we won't notice anyway? To me this needs to be a first step in a well-defined and resourced plan to actually address these issues, not just the first step with a hope other steps will follow. Just my 2c. Cheers. ------------- PR: https://git.openjdk.org/jdk/pull/9516 From duke at openjdk.org Thu Jul 21 15:20:07 2022 From: duke at openjdk.org (Sacha Coppey) Date: Thu, 21 Jul 2022 15:20:07 GMT Subject: RFR: 8290154: [JVMCI] Implement JVMCI for RISC-V Message-ID: This patch adds a JVMCI implementation for RISC-V. It creates the jdk.vm.ci.riscv64 and jdk.vm.ci.hotspot.riscv64 packages, as well as implements a part of jvmciCodeInstaller_riscv64.cpp. To check for correctness, it enables JVMCI code installation tests on RISC-V. It should be tested soon in GraalVM Native Image as well. ------------- Commit messages: - 8290154: [JVMCI] Implement JVMCI for RISC-V Changes: https://git.openjdk.org/jdk/pull/9587/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9587&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290154 Stats: 1690 lines in 20 files changed: 1668 ins; 0 del; 22 mod Patch: https://git.openjdk.org/jdk/pull/9587.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9587/head:pull/9587 PR: https://git.openjdk.org/jdk/pull/9587 From jvernee at openjdk.org Fri Jul 22 13:22:28 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Fri, 22 Jul 2022 13:22:28 GMT Subject: RFR: 8290059: Do not use std::thread in panama tests Message-ID: This patch removes the use of std::thread from the `java.lang.foreign` tests, and switches to the OS specific thread APIs, in order to change things such as the stack size on some platforms where this is required in the future (see the JBS issue). This is done by adding a small header-only library that exposes a function to run code in freshly spawned threads (`run_async`). Testing: Running the affected tests on platforms that implement the linker. ------------- Commit messages: - Linux fixes - Don't use std::thread in j.l.f tests Changes: https://git.openjdk.org/jdk/pull/9599/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9599&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290059 Stats: 171 lines in 7 files changed: 123 ins; 7 del; 41 mod Patch: https://git.openjdk.org/jdk/pull/9599.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9599/head:pull/9599 PR: https://git.openjdk.org/jdk/pull/9599 From jvernee at openjdk.org Fri Jul 22 15:01:26 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Fri, 22 Jul 2022 15:01:26 GMT Subject: RFR: 8290373: Enable lossy conversion warnings on Windows [v4] In-Reply-To: References: Message-ID: On Wed, 20 Jul 2022 14:18:49 GMT, Jorn Vernee wrote: >> This patch enables lossy conversion warnings (C4244 [1]) for hotspot on Windows/MSVC. Instead of fixing all warnings that were produced from this, I've instead locally disabled the warning in the files that produced warnings. This allows gradually making progress with cleaning up these warnings on a per-file basis, instead of trying to fix all of them in one shot. i.e. it is not meant as a long term solution, but as a way of allowing incremental progress. >> >> Out of the ~1100 files that make up hotspot on Windows x64 , ~290 have warnings for them disabled (not counting aarch64 files), which means that with this patch ~800 files are protected by enabling this warning globally. >> >> Warnings can be fixed in individual files, or groups of files in followup patches, and warnings for those files can be enabled. >> >> I'm working on a patch that does the same for GCC, but it produces warnings in about 150 more files, so I wanted to gather feedback on this approach before continuing with that. >> >> --- >> >> To disable warnings for a file, in most cases the following prelude is added after the last `#include` at the start of a file: >> >> PRAGMA_DIAG_PUSH >> PRAGMA_ALLOW_LOSSY_CONVERSIONS >> >> And then the following is added at the end of the file for cpp files, or before closing the header guard for hpp files: >> >> PRAGMA_DIAG_POP >> >> 1 notable exception are files produced by adlc, which had their code-gen modified to add these lines instead. There were also 2 files that include headers in the middle of the file (ostream.cpp & sharedRuntime.cpp), for which I've added the PRAGMA's after the include block at the start of the file instead. They only included system headers, for which disabling warnings doesn't matter any ways. >> >> [1]: https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-levels-3-and-4-c4244?view=msvc-170 > > Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits: > > - Merge branch 'master' into Warn_Narrow > - Polish pt2 > - Polish > - Remove PUSH POP from test files > - Remove PUSH POP from cpp files > - Rest of the tests > - More test > - AArch64 > - Disable for tests > - Fix apostrophe > - ... and 5 more: https://git.openjdk.org/jdk/compare/1c055076...fb276afd I think these warnings are a nice-to-have. Kinda like a certain code style. However, I don't think it's important enough to organize people and go through fixing each and every one of them in the 450 or so files all at once. The warnings being either unimportant enough to turn them off like we do now, or being important enough to turn them on and fix all of them is, I think, a false dichotomy. In reality, the importance of fixing these warnings seems to be more in the middle. And I think this is what leads to a stalemate (the original JBS issue for this was filed in 2015 [1]). So, I'd like to suggest a compromise instead. We could have a policy similar to how styling is fixed currently in HotSpot (mostly in the compiler code). In that case styling is fixed in the surrounding code that is touched by a patch. In the case of these warnings, I propose that when a patch touches a file with lossy conversion warnings disabled, it should also enable the warnings and fix them for that file. Maybe it's useful to rename the macro to something like `PRAGMA_FIXME_LOSSY_CONVERSIONS` for that as well. [1] : https://bugs.openjdk.org/browse/JDK-8135181 ------------- PR: https://git.openjdk.org/jdk/pull/9516 From mcimadamore at openjdk.org Fri Jul 22 15:01:12 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 22 Jul 2022 15:01:12 GMT Subject: RFR: 8290059: Do not use std::thread in panama tests In-Reply-To: References: Message-ID: On Thu, 21 Jul 2022 18:48:14 GMT, Jorn Vernee wrote: > This patch removes the use of std::thread from the `java.lang.foreign` tests, and switches to the OS specific thread APIs, in order to change things such as the stack size on some platforms where this is required in the future (see the JBS issue). > > This is done by adding a small header-only library that exposes a function to run code in freshly spawned threads (`run_async`). > > Testing: Running the affected tests on platforms that implement the linker. Looks good! test/lib/native/testlib_threads.h line 37: > 35: typedef HANDLE THREAD_ID; > 36: > 37: #else // !_WIN32 the comments in the #else are inconsistent - some use `!_WIN32`, some use `!windows` others use nothing. ------------- Marked as reviewed by mcimadamore (Reviewer). PR: https://git.openjdk.org/jdk/pull/9599 From jvernee at openjdk.org Fri Jul 22 16:45:55 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Fri, 22 Jul 2022 16:45:55 GMT Subject: RFR: 8290059: Do not use std::thread in panama tests [v2] In-Reply-To: References: Message-ID: > This patch removes the use of std::thread from the `java.lang.foreign` tests, and switches to the OS specific thread APIs, in order to change things such as the stack size on some platforms where this is required in the future (see the JBS issue). > > This is done by adding a small header-only library that exposes a function to run code in freshly spawned threads (`run_async`). > > Testing: Running the affected tests on platforms that implement the linker. Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: Fixes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9599/files - new: https://git.openjdk.org/jdk/pull/9599/files/8e538b47..49e60f2d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9599&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9599&range=00-01 Stats: 17 lines in 1 file changed: 5 ins; 5 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/9599.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9599/head:pull/9599 PR: https://git.openjdk.org/jdk/pull/9599 From mcimadamore at openjdk.org Fri Jul 22 16:45:56 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 22 Jul 2022 16:45:56 GMT Subject: RFR: 8290059: Do not use std::thread in panama tests [v2] In-Reply-To: References: Message-ID: <3oZXLMv51fsA2eyUVWSGTfhXOWM5ESXJmOp-PhxEPoE=.bdf26040-dc62-4141-a33b-79b0f4ff7cd0@github.com> On Fri, 22 Jul 2022 16:41:24 GMT, Jorn Vernee wrote: >> This patch removes the use of std::thread from the `java.lang.foreign` tests, and switches to the OS specific thread APIs, in order to change things such as the stack size on some platforms where this is required in the future (see the JBS issue). >> >> This is done by adding a small header-only library that exposes a function to run code in freshly spawned threads (`run_async`). >> >> Testing: Running the affected tests on platforms that implement the linker. > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > Fixes Marked as reviewed by mcimadamore (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9599 From clanger at openjdk.org Fri Jul 22 16:45:57 2022 From: clanger at openjdk.org (Christoph Langer) Date: Fri, 22 Jul 2022 16:45:57 GMT Subject: RFR: 8290059: Do not use std::thread in panama tests In-Reply-To: References: Message-ID: On Thu, 21 Jul 2022 18:48:14 GMT, Jorn Vernee wrote: > This patch removes the use of std::thread from the `java.lang.foreign` tests, and switches to the OS specific thread APIs, in order to change things such as the stack size on some platforms where this is required in the future (see the JBS issue). > > This is done by adding a small header-only library that exposes a function to run code in freshly spawned threads (`run_async`). > > Testing: Running the affected tests on platforms that implement the linker. @JornVernee thanks for doing this so quickly. I suggest undoing https://github.com/openjdk/jdk/commit/d7f0de272c85ee8d0890c9d61e10065b618b69d7 in this change, too. If you update this PR I can run it through our Alpine test pipeline. ------------- PR: https://git.openjdk.org/jdk/pull/9599 From jvernee at openjdk.org Fri Jul 22 16:45:58 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Fri, 22 Jul 2022 16:45:58 GMT Subject: RFR: 8290059: Do not use std::thread in panama tests In-Reply-To: References: Message-ID: On Fri, 22 Jul 2022 15:09:13 GMT, Christoph Langer wrote: >> This patch removes the use of std::thread from the `java.lang.foreign` tests, and switches to the OS specific thread APIs, in order to change things such as the stack size on some platforms where this is required in the future (see the JBS issue). >> >> This is done by adding a small header-only library that exposes a function to run code in freshly spawned threads (`run_async`). >> >> Testing: Running the affected tests on platforms that implement the linker. > > @JornVernee thanks for doing this so quickly. I suggest undoing https://github.com/openjdk/jdk/commit/d7f0de272c85ee8d0890c9d61e10065b618b69d7 in this change, too. If you update this PR I can run it through our Alpine test pipeline. @RealCLanger Note that I'm not setting the stack size of the thread in this patch. I'm just using the defaults. From the discussion on the bug, I don't think this sufficient to make the tests pass on Apline/MuslC. I avoided getting into that since I don't have ready access to an Alpine/MuslC testing environment atm. So, I've left setting the stack size on MuslC, and re-enabling the tests for someone that does. Hopefully this patch is enough to get that going easily. ------------- PR: https://git.openjdk.org/jdk/pull/9599 From jvernee at openjdk.org Fri Jul 22 16:45:59 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Fri, 22 Jul 2022 16:45:59 GMT Subject: RFR: 8290059: Do not use std::thread in panama tests [v2] In-Reply-To: References: Message-ID: On Fri, 22 Jul 2022 14:56:16 GMT, Maurizio Cimadamore wrote: >> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixes > > Looks good! @mcimadamore Thanks for the comments. I've cleaned up the comments on the compiler switches (just removed them). I also realized there was an unused typedef for `THREAD_ID`, which I've removed. Finally, I realized that after printing an error, we should probably also exit the test (I'd forgotten to add this before making the PR public). I've added a helper function called `fatal` that prints the error message and then calls `exit`. The tests still pass with that. ------------- PR: https://git.openjdk.org/jdk/pull/9599 From clanger at openjdk.org Fri Jul 22 16:46:00 2022 From: clanger at openjdk.org (Christoph Langer) Date: Fri, 22 Jul 2022 16:46:00 GMT Subject: RFR: 8290059: Do not use std::thread in panama tests In-Reply-To: References: Message-ID: On Fri, 22 Jul 2022 15:09:13 GMT, Christoph Langer wrote: >> This patch removes the use of std::thread from the `java.lang.foreign` tests, and switches to the OS specific thread APIs, in order to change things such as the stack size on some platforms where this is required in the future (see the JBS issue). >> >> This is done by adding a small header-only library that exposes a function to run code in freshly spawned threads (`run_async`). >> >> Testing: Running the affected tests on platforms that implement the linker. > > @JornVernee thanks for doing this so quickly. I suggest undoing https://github.com/openjdk/jdk/commit/d7f0de272c85ee8d0890c9d61e10065b618b69d7 in this change, too. If you update this PR I can run it through our Alpine test pipeline. > @RealCLanger Note that I'm not setting the stack size of the thread in this patch. I'm just using the defaults. From the discussion on the bug, I don't think this sufficient to make the tests pass on Apline/MuslC. > > I avoided getting into that since I don't have ready access to an Alpine/MuslC testing environment atm. So, I've left setting the stack size on MuslC, and re-enabling the tests for someone that does. Hopefully this patch is enough to get that going easily. OK, thanks for clarifying that. @tstuefe, maybe you want to have a look after this fix is in? ------------- PR: https://git.openjdk.org/jdk/pull/9599 From stuefe at openjdk.org Fri Jul 22 18:47:20 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 22 Jul 2022 18:47:20 GMT Subject: RFR: 8290059: Do not use std::thread in panama tests [v2] In-Reply-To: References: Message-ID: On Fri, 22 Jul 2022 16:45:55 GMT, Jorn Vernee wrote: >> This patch removes the use of std::thread from the `java.lang.foreign` tests, and switches to the OS specific thread APIs, in order to change things such as the stack size on some platforms where this is required in the future (see the JBS issue). >> >> This is done by adding a small header-only library that exposes a function to run code in freshly spawned threads (`run_async`). >> >> Testing: Running the affected tests on platforms that implement the linker. > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > Fixes Hi @JornVernee, good job and thanks for doing it so quickly. Looks good, module the GetLastError comment. About the stack size and Alpine, I am fine with doing the A?pine-specific fix in a follow-up, or you can do it as part of this change. Strictly speaking its not part of this bug report to adjust the stack size. If you fix the GetLastError issue, I don't need another look. Thanks, Thomas test/lib/native/testlib_threads.h line 50: > 48: static void fatal(const char* message) { > 49: perror(message); > 50: exit(-1); Won't work as intended for Windows APIs. I would print the result of `GetLastError()` instead. Alternatively I am fine fine with just omitting the error code, because I think the old tests did not handle errors either. Or did we catch std::thread exceptions somewhere? test/lib/native/testlib_threads.h line 61: > 59: helper->proc(helper->context); > 60: return 0; > 61: } I'm curious, does this only exist because of the DWORD vs void* return value size of the native thread functions? I wondered why you don't just pass the test procedure to the thread start API directly. About stdcall, does Oracle still build Windows 32bit? ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.org/jdk/pull/9599 From naoto at openjdk.org Fri Jul 22 22:01:39 2022 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 22 Jul 2022 22:01:39 GMT Subject: RFR: 8289227: Support for BCP 47 Extension T - Transformed Content Message-ID: This PR is to propose supporting the `T` extension to the BCP 47 to which `java.util.Locale` class conforms. There are two extensions to the BCP 47, one is `Unicode Locale Extension` which has been supported since JDK7, the other is this `Transformed Content` extension. A CSR has also been drafted. ------------- Commit messages: - IllformedLocaleEx -> LocaleSyntaxEx - SystemProperty tests - Revived returning Optional - Some clean-ups, including making Extension a sealed class. - Bring the specialized methods back - Using Optional - FieldSeparators()/FieldSubtag() -> Fields() - 8289227: Support for BCP 47 Extension T - T-ext Changes: https://git.openjdk.org/jdk/pull/9620/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9620&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289227 Stats: 776 lines in 23 files changed: 600 ins; 135 del; 41 mod Patch: https://git.openjdk.org/jdk/pull/9620.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9620/head:pull/9620 PR: https://git.openjdk.org/jdk/pull/9620 From dholmes at openjdk.org Sat Jul 23 06:02:14 2022 From: dholmes at openjdk.org (David Holmes) Date: Sat, 23 Jul 2022 06:02:14 GMT Subject: RFR: 8290059: Do not use std::thread in panama tests [v2] In-Reply-To: References: Message-ID: On Fri, 22 Jul 2022 16:45:55 GMT, Jorn Vernee wrote: >> This patch removes the use of std::thread from the `java.lang.foreign` tests, and switches to the OS specific thread APIs, in order to change things such as the stack size on some platforms where this is required in the future (see the JBS issue). >> >> This is done by adding a small header-only library that exposes a function to run code in freshly spawned threads (`run_async`). >> >> Testing: Running the affected tests on platforms that implement the linker. > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > Fixes `run_async` is an odd name for this, especially as the fact you create then join mean it doesn't run asynchronously at all - it runs synchronously in another thread. The API would be more generally useful if you split the start and the join, but that would require also exposing an opaque thread "handle" (though splitting also means you don't have to try and think of a good name for `run_in_a_new_thread-and_join_it()` - you just have `threadStart` and `threadJoin`). ------------- PR: https://git.openjdk.org/jdk/pull/9599 From tanksherman27 at gmail.com Sun Jul 24 08:07:21 2022 From: tanksherman27 at gmail.com (Julian Waters) Date: Sun, 24 Jul 2022 16:07:21 +0800 Subject: Where is STRIP set for clang? Message-ID: Found something interesting in FLAGS_SETUP_STRIPFLAGS recently: ## Setup strip. # FIXME: should this really be per platform, or should it be per toolchain type? # strip is not provided by clang; so guessing platform makes most sense. STRIPFLAGS is set to -S after this for clang (or more accurately, when the OS being compiled for is MacOS), but STRIP for clang (Likely using the clang driver itself) doesn't seem to be set anywhere within make. The only place I can find it being set is in toolchain.m4, UTIL_LOOKUP_TOOLCHAIN_PROGS(STRIP, strip), when the OS that's being compiled for != windows. But if the comment that strip isn't available for clang is still correct and up to date, this doesn't seem right, considering Linux allows for compiling the JDK with clang as well, while -S is only set with MacOS, and the != windows check would also not work properly since it would still check for the regular strip utility even if the compiler was clang. best regards, Julian -------------- next part -------------- An HTML attachment was scrubbed... URL: From dholmes at openjdk.org Mon Jul 25 01:19:04 2022 From: dholmes at openjdk.org (David Holmes) Date: Mon, 25 Jul 2022 01:19:04 GMT Subject: RFR: 8290373: Enable lossy conversion warnings on Windows [v4] In-Reply-To: References: Message-ID: On Fri, 22 Jul 2022 14:56:08 GMT, Jorn Vernee wrote: > I propose that when a patch touches a file with lossy conversion warnings disabled, it should also enable the warnings and fix them for that file. This contradicts other common recomendations of not mixing unrelated issues in the same PR. Fixing style nits is harmless but fixing an actual lossy conversion issue could itself lead to bugs and unexpected fanout. ------------- PR: https://git.openjdk.org/jdk/pull/9516 From fyang at openjdk.org Mon Jul 25 07:34:49 2022 From: fyang at openjdk.org (Fei Yang) Date: Mon, 25 Jul 2022 07:34:49 GMT Subject: RFR: 8290154: [JVMCI] Implement JVMCI for RISC-V In-Reply-To: References: Message-ID: On Thu, 21 Jul 2022 10:18:05 GMT, Sacha Coppey wrote: > This patch adds a JVMCI implementation for RISC-V. It creates the jdk.vm.ci.riscv64 and jdk.vm.ci.hotspot.riscv64 packages, as well as implements a part of jvmciCodeInstaller_riscv64.cpp. To check for correctness, it enables JVMCI code installation tests on RISC-V. It should be tested soon in GraalVM Native Image as well. Hi, I see some JVM crash when I try the following test with fastdebug build with your patch: test/hotspot/jtreg/compiler/jvmci/jdk.vm.ci.code.test/src/jdk/vm/ci/code/test/SimpleDebugInfoTest.java //////////////////////////////////////////////////// Internal Error (/home/fyang/openjdk-jdk/src/hotspot/cpu/riscv/nativeInst_riscv.cpp:118), pid=1154 063, tid=1154084 assert(NativeCall::is_call_at((address)this)) failed: unexpected code at call site //////////////////////////////////////////////////// ------------- PR: https://git.openjdk.org/jdk/pull/9587 From duke at openjdk.org Mon Jul 25 12:02:30 2022 From: duke at openjdk.org (Sacha Coppey) Date: Mon, 25 Jul 2022 12:02:30 GMT Subject: RFR: 8290154: [JVMCI] Implement JVMCI for RISC-V [v2] In-Reply-To: References: Message-ID: <4RWjt5pOsf8Qswdf7ViTiJMLkvdyNQ6KwVSuj6X09bo=.ac7e8054-280d-4893-9d9f-00d3b36ce813@github.com> > This patch adds a JVMCI implementation for RISC-V. It creates the jdk.vm.ci.riscv64 and jdk.vm.ci.hotspot.riscv64 packages, as well as implements a part of jvmciCodeInstaller_riscv64.cpp. To check for correctness, it enables JVMCI code installation tests on RISC-V. It should be tested soon in GraalVM Native Image as well. Sacha Coppey has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: 8290154: [JVMCI] Implement JVMCI for RISC-V ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9587/files - new: https://git.openjdk.org/jdk/pull/9587/files/df247c0b..68882a86 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9587&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9587&range=00-01 Stats: 7 lines in 1 file changed: 2 ins; 1 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/9587.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9587/head:pull/9587 PR: https://git.openjdk.org/jdk/pull/9587 From duke at openjdk.org Mon Jul 25 13:41:04 2022 From: duke at openjdk.org (Sacha Coppey) Date: Mon, 25 Jul 2022 13:41:04 GMT Subject: RFR: 8290154: [JVMCI] Implement JVMCI for RISC-V [v3] In-Reply-To: References: Message-ID: <8aRWtlLJUymEF1hJG0jEHZrPAE_W66D1yNPNCPWuPBs=.08b33aa3-c785-408a-a5f6-3d38fa739737@github.com> > This patch adds a JVMCI implementation for RISC-V. It creates the jdk.vm.ci.riscv64 and jdk.vm.ci.hotspot.riscv64 packages, as well as implements a part of jvmciCodeInstaller_riscv64.cpp. To check for correctness, it enables JVMCI code installation tests on RISC-V. It should be tested soon in GraalVM Native Image as well. Sacha Coppey has updated the pull request incrementally with one additional commit since the last revision: Use nativeInstruction_at instead of nativeCall_at to avoid wrongly initializating a call ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9587/files - new: https://git.openjdk.org/jdk/pull/9587/files/68882a86..925a2651 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9587&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9587&range=01-02 Stats: 8 lines in 1 file changed: 1 ins; 1 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/9587.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9587/head:pull/9587 PR: https://git.openjdk.org/jdk/pull/9587 From duke at openjdk.org Mon Jul 25 14:38:26 2022 From: duke at openjdk.org (Sacha Coppey) Date: Mon, 25 Jul 2022 14:38:26 GMT Subject: RFR: 8290154: [JVMCI] Implement JVMCI for RISC-V [v4] In-Reply-To: References: Message-ID: > This patch adds a JVMCI implementation for RISC-V. It creates the jdk.vm.ci.riscv64 and jdk.vm.ci.hotspot.riscv64 packages, as well as implements a part of jvmciCodeInstaller_riscv64.cpp. To check for correctness, it enables JVMCI code installation tests on RISC-V. It should be tested soon in GraalVM Native Image as well. Sacha Coppey has updated the pull request incrementally with one additional commit since the last revision: Avoid using set_destination when call is not jal ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9587/files - new: https://git.openjdk.org/jdk/pull/9587/files/925a2651..9f7cbf6c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9587&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9587&range=02-03 Stats: 13 lines in 2 files changed: 0 ins; 7 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/9587.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9587/head:pull/9587 PR: https://git.openjdk.org/jdk/pull/9587 From duke at openjdk.org Mon Jul 25 17:27:25 2022 From: duke at openjdk.org (Sacha Coppey) Date: Mon, 25 Jul 2022 17:27:25 GMT Subject: RFR: 8290154: [JVMCI] Implement JVMCI for RISC-V In-Reply-To: References: Message-ID: On Mon, 25 Jul 2022 07:30:08 GMT, Fei Yang wrote: > Hi, I see some JVM crash when I try the following test with fastdebug build with your patch: test/hotspot/jtreg/compiler/jvmci/jdk.vm.ci.code.test/src/jdk/vm/ci/code/test/SimpleDebugInfoTest.java Thank you for pointing this out, I did not run the patch with fastdebug. I saw other issues after solving this one, so I take some time to solve them as well. ------------- PR: https://git.openjdk.org/jdk/pull/9587 From hseigel at openjdk.org Mon Jul 25 17:32:21 2022 From: hseigel at openjdk.org (Harold Seigel) Date: Mon, 25 Jul 2022 17:32:21 GMT Subject: RFR: 8285792: Posix signal handler modification checking issues. Message-ID: Please review this fix for JDK-8285792. The fix removes print statements from check_signal_handler() so that it doesn't print all the handlers every time it finds one that is modified. Instead, it returns true if the handler is modified, false otherwise. Its caller, user_handler(), then prints all the handlers just once even if multiple signal handlers were modified. The fix also adds a check for VMError::crash_handler_adress() to check_signal_handler() to prevent it from being treated as a signal handler modification. The fix was tested with Mach5 tiers 1-2 on Linux and Mac OS and Mach 5 tiers 3-5 on Linux x64. The regression test is excluded on Windows. Thanks, Harold ------------- Commit messages: - 8285792: Posix signal handler modification checking issues. Changes: https://git.openjdk.org/jdk/pull/9631/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9631&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8285792 Stats: 194 lines in 5 files changed: 172 ins; 4 del; 18 mod Patch: https://git.openjdk.org/jdk/pull/9631.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9631/head:pull/9631 PR: https://git.openjdk.org/jdk/pull/9631 From prr at openjdk.org Mon Jul 25 17:54:07 2022 From: prr at openjdk.org (Phil Race) Date: Mon, 25 Jul 2022 17:54:07 GMT Subject: RFR: 8285792: Posix signal handler modification checking issues. In-Reply-To: References: Message-ID: On Mon, 25 Jul 2022 17:21:27 GMT, Harold Seigel wrote: > Please review this fix for JDK-8285792. The fix removes print statements from check_signal_handler() so that it doesn't print all the handlers every time it finds one that is modified. Instead, it returns true if the handler is modified, false otherwise. Its caller, user_handler(), then prints all the handlers just once even if multiple signal handlers were modified. > > The fix also adds a check for VMError::crash_handler_adress() to check_signal_handler() to prevent it from being treated as a signal handler modification. > > The fix was tested with Mach5 tiers 1-2 on Linux and Mac OS and Mach 5 tiers 3-5 on Linux x64. The regression test is excluded on Windows. > > Thanks, Harold Will this reduce the messages we were seeing in this bug https://bugs.openjdk.org/browse/JDK-8279878 ? If this is the same thing, is there a reason it is coupled to -Xcheck:jni ? ------------- PR: https://git.openjdk.org/jdk/pull/9631 From hseigel at openjdk.org Mon Jul 25 19:33:02 2022 From: hseigel at openjdk.org (Harold Seigel) Date: Mon, 25 Jul 2022 19:33:02 GMT Subject: RFR: 8285792: Posix signal handler modification checking issues. In-Reply-To: References: Message-ID: On Mon, 25 Jul 2022 17:21:27 GMT, Harold Seigel wrote: > Please review this fix for JDK-8285792. The fix removes print statements from check_signal_handler() so that it doesn't print all the handlers every time it finds one that is modified. Instead, it returns true if the handler is modified, false otherwise. Its caller, user_handler(), then prints all the handlers just once even if multiple signal handlers were modified. > > The fix also adds a check for VMError::crash_handler_adress() to check_signal_handler() to prevent it from being treated as a signal handler modification. > > The fix was tested with Mach5 tiers 1-2 on Linux and Mac OS and Mach 5 tiers 3-5 on Linux x64. The regression test is excluded on Windows. > > Thanks, Harold I ran the test for JDK-8279878 after removing both this fix and the fix for JDK-8279878 and the test still passed. So I don't think its failure was related to this issue. This fix prevents the output from occurring more than once. It does not prevent it from occurring at all. The JVM was reporting that it found an unexpected handler for SIG_IGN. Is it possible that such a handler is no longer being defined? Note that the JVM only checks for unexpected signal handlers if -Xcheck:jni or -XX:+CheckJNICall is specified. ------------- PR: https://git.openjdk.org/jdk/pull/9631 From prr at openjdk.org Mon Jul 25 20:54:07 2022 From: prr at openjdk.org (Phil Race) Date: Mon, 25 Jul 2022 20:54:07 GMT Subject: RFR: 8285792: Posix signal handler modification checking issues. In-Reply-To: References: Message-ID: On Mon, 25 Jul 2022 19:29:52 GMT, Harold Seigel wrote: > I ran the test for JDK-8279878 after removing both this fix and the fix for JDK-8279878 and the test still passed. So I don't think its failure was related to this issue. This fix prevents the output from occurring more than once. It does not prevent it from occurring at all. > > The JVM was reporting that it found an unexpected handler for SIG_IGN. Is it possible that such a handler is no longer being defined? > > Note that the JVM only checks for unexpected signal handlers if -Xcheck:jni or -XX:+CheckJNICall is specified. Sure .. we updated the test to ignore these warnings ... but I was hoping that maybe your changes would obsolete the need to ignore them. However I actually suspect it won't help if it just minimises them rather than eliminates them. It stems from the GTK library (the standard library for Gnome desktop apps on Linux) calling (SIGPIPE, SIG_IGN) during initialization Their reasons are here : https://docs.gtk.org/gtk3/func.init.html So the VM warnings are something of a mild annoyance that we've worked around in this test but it never made sense to me what this has to do with JNI ? ------------- PR: https://git.openjdk.org/jdk/pull/9631 From dholmes at openjdk.org Mon Jul 25 21:56:02 2022 From: dholmes at openjdk.org (David Holmes) Date: Mon, 25 Jul 2022 21:56:02 GMT Subject: RFR: 8285792: Posix signal handler modification checking issues. In-Reply-To: References: Message-ID: On Mon, 25 Jul 2022 17:21:27 GMT, Harold Seigel wrote: > Please review this fix for JDK-8285792. The fix removes print statements from check_signal_handler() so that it doesn't print all the handlers every time it finds one that is modified. Instead, it returns true if the handler is modified, false otherwise. Its caller, user_handler(), then prints all the handlers just once even if multiple signal handlers were modified. > > The fix also adds a check for VMError::crash_handler_adress() to check_signal_handler() to prevent it from being treated as a signal handler modification. > > The fix was tested with Mach5 tiers 1-2 on Linux and Mac OS and Mach 5 tiers 3-5 on Linux x64. The regression test is excluded on Windows. > > Thanks, Harold Looking at [JDK-4229104](https://bugs.openjdk.org/browse/JDK-4229104) I have to wonder whether our handling of `SIGPIPE` is still necessary? Even if so, the fact we always ignore it if we get it suggests we really don't care if someone else has installed a (temporary) handler for it, so perhaps we should not include it (or `SIGXFSZ`) in these checks? ------------- PR: https://git.openjdk.org/jdk/pull/9631 From dholmes at openjdk.org Mon Jul 25 22:04:07 2022 From: dholmes at openjdk.org (David Holmes) Date: Mon, 25 Jul 2022 22:04:07 GMT Subject: RFR: 8285792: Posix signal handler modification checking issues. In-Reply-To: References: Message-ID: On Mon, 25 Jul 2022 17:21:27 GMT, Harold Seigel wrote: > Please review this fix for JDK-8285792. The fix removes print statements from check_signal_handler() so that it doesn't print all the handlers every time it finds one that is modified. Instead, it returns true if the handler is modified, false otherwise. Its caller, user_handler(), then prints all the handlers just once even if multiple signal handlers were modified. > > The fix also adds a check for VMError::crash_handler_adress() to check_signal_handler() to prevent it from being treated as a signal handler modification. > > The fix was tested with Mach5 tiers 1-2 on Linux and Mac OS and Mach 5 tiers 3-5 on Linux x64. The regression test is excluded on Windows. > > Thanks, Harold Hi Harold, Overall seems fine. A couple of nits. We could simplify the test by just having (as is common) on Java file which launches itself in a new VM when invoked with no-args, and does the real test when passed a (dummy) arg. Then we will have one less file and clearer names. Thanks. src/hotspot/os/posix/signals_posix.cpp line 843: > 841: // Compare both sigaction structures (intelligently; only the members we care about). > 842: // Ignore if the handler is our own crash handler. > 843: if (!are_handlers_equal(&act, expected_act) && Pre-existing nit: really this should be called `are_actions_equal`. The poor naming is clearer when you now follow this with `HANDLER_IS`. test/hotspot/jtreg/runtime/posixSig/TestPsig.java line 28: > 26: System.loadLibrary("TestPsig"); > 27: } > 28: public static native void doSomething(int val); Suggestion: `private static native void changeSigActionFor(int sig);` ------------- Changes requested by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/9631 From erikj at openjdk.org Mon Jul 25 22:30:12 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 25 Jul 2022 22:30:12 GMT Subject: RFR: 8289755: Remove --enable-reproducible-build from jib profile In-Reply-To: References: Message-ID: On Tue, 5 Jul 2022 16:01:50 GMT, Magnus Ihse Bursie wrote: > Since [JDK-8288396](https://bugs.openjdk.org/browse/JDK-8288396), the flag ` --enable-reproducible-build` is deprecated, and does nothing but print a warning. It is still included in the jib profiles, which make they output a warning. Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9379 From erikj at openjdk.org Mon Jul 25 22:35:01 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 25 Jul 2022 22:35:01 GMT Subject: RFR: 8290059: Do not use std::thread in panama tests [v2] In-Reply-To: References: Message-ID: On Fri, 22 Jul 2022 16:45:55 GMT, Jorn Vernee wrote: >> This patch removes the use of std::thread from the `java.lang.foreign` tests, and switches to the OS specific thread APIs, in order to change things such as the stack size on some platforms where this is required in the future (see the JBS issue). >> >> This is done by adding a small header-only library that exposes a function to run code in freshly spawned threads (`run_async`). >> >> Testing: Running the affected tests on platforms that implement the linker. > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > Fixes Build changes look good. ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.org/jdk/pull/9599 From asotona at openjdk.org Tue Jul 26 08:32:00 2022 From: asotona at openjdk.org (Adam Sotona) Date: Tue, 26 Jul 2022 08:32:00 GMT Subject: RFR: 8244681: Add a warning for possibly lossy conversion in compound assignments [v14] In-Reply-To: References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> Message-ID: On Mon, 27 Jun 2022 09:25:58 GMT, Adam Sotona wrote: >> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions. >> >> The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable. >> >> The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. >> >> Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments. >> >> Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks. >> >> Thanks for your review, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > re-enabled lossy conversions warnings for java.security.jgss, jdk.crypto.ec and jdk.internal.le ping to keep the PR open ------------- PR: https://git.openjdk.org/jdk/pull/8599 From shade at openjdk.org Tue Jul 26 12:39:29 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 26 Jul 2022 12:39:29 GMT Subject: RFR: 8290466: Default to --with-source-date=current to avoid unmodified Hotspot recompilation Message-ID: See the bug for symptoms and rationale. In short, after [JDK-8288396](https://bugs.openjdk.org/browse/JDK-8288396) moved the timestamp to `CFLAGS_VM_VERSION` macro, which changes with every build, we get Hotspot recompilation every time, even when Hotspot is not modified. I believe current behavior is correct for `--with-source-date=updated` (current default): you do Hotspot build, you get updated build timestamp, which forces recompilation of affected compilation units, relinkage, re-creation of jmods/jimage. The way out is to switch to `--with-source-date=current`, which would only get the build timestamp at configure time. CIs and build farms are likely reconfiguring before every build anyway, so their behavior is unlikely to be affected. But this switch definitely improves the day-to-day OpenJDK development work: it saves >50 seconds on every `make` for my machine, see below. Back-to-back unmodified build before: $ CONF=linux-x86_64-server-release time make hotspot Building target 'hotspot' in configuration 'linux-x86_64-server-release' Finished building target 'hotspot' in configuration 'linux-x86_64-server-release' 39.03user 10.97system 0:56.89elapsed 87%CPU (0avgtext+0avgdata 2048944maxresident)k 363616inputs+4108072outputs (484major+1100154minor)pagefaults 0swaps $ CONF=linux-x86_64-server-release time make hotspot Building target 'hotspot' in configuration 'linux-x86_64-server-release' Finished building target 'hotspot' in configuration 'linux-x86_64-server-release' 38.18user 9.02system 0:49.18elapsed 95%CPU (0avgtext+0avgdata 2048788maxresident)k 40inputs+4101112outputs (0major+1100077minor)pagefaults 0swaps Back-to-back unmodified build after: $ CONF=linux-x86_64-server-release time make hotspot Building target 'hotspot' in configuration 'linux-x86_64-server-release' Finished building target 'hotspot' in configuration 'linux-x86_64-server-release' 2.15user 0.22system 0:02.59elapsed 91%CPU (0avgtext+0avgdata 49480maxresident)k 0inputs+176outputs (0major+55506minor)pagefaults 0swaps $ CONF=linux-x86_64-server-release time make hotspot Building target 'hotspot' in configuration 'linux-x86_64-server-release' Finished building target 'hotspot' in configuration 'linux-x86_64-server-release' 2.18user 0.14system 0:02.46elapsed 94%CPU (0avgtext+0avgdata 49332maxresident)k ------------- Commit messages: - Fix Changes: https://git.openjdk.org/jdk/pull/9638/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9638&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290466 Stats: 8 lines in 3 files changed: 0 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/9638.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9638/head:pull/9638 PR: https://git.openjdk.org/jdk/pull/9638 From jvernee at openjdk.org Tue Jul 26 13:02:36 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 26 Jul 2022 13:02:36 GMT Subject: RFR: 8290059: Do not use std::thread in panama tests [v2] In-Reply-To: References: Message-ID: On Fri, 22 Jul 2022 18:32:56 GMT, Thomas Stuefe wrote: >> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixes > > test/lib/native/testlib_threads.h line 50: > >> 48: static void fatal(const char* message) { >> 49: perror(message); >> 50: exit(-1); > > Won't work as intended for Windows APIs. I would print the result of `GetLastError()` instead. > > Alternatively I am fine fine with just omitting the error code, because I think the old tests did not handle errors either. Or did we catch std::thread exceptions somewhere? The intent was to exit the test with a non-zero exit code, in order to avoid any accidental false positives. I could return the error code from `GetLastError` and from the respective pthread apis as an exit code instead. Is that what you mean? ------------- PR: https://git.openjdk.org/jdk/pull/9599 From jvernee at openjdk.org Tue Jul 26 13:06:50 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 26 Jul 2022 13:06:50 GMT Subject: RFR: 8290059: Do not use std::thread in panama tests [v2] In-Reply-To: References: Message-ID: On Fri, 22 Jul 2022 18:37:02 GMT, Thomas Stuefe wrote: >> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixes > > test/lib/native/testlib_threads.h line 61: > >> 59: helper->proc(helper->context); >> 60: return 0; >> 61: } > > I'm curious, does this only exist because of the DWORD vs void* return value size of the native thread functions? I wondered why you don't just pass the test procedure to the thread start API directly. > > About stdcall, does Oracle still build Windows 32bit? Yes, this exists as an adapter from PROCEDURE to whatever callback type the OS API expects. I tried passing the procedure to the start API as well, but the compiler complains that the types don't match. Even if I make PROCEDURE return `int`, it seems to want `DWORD` explicitly. This was taken from the old library code which uses `_beginthreadex`. That one explicitly wants to use `__stdcall`, so I just matched that. Looking again, it doesn't look like the same is required for `CreateThread` [1]. I'll remove it for clarity. [1] : https://docs.microsoft.com/en-us/previous-versions/windows/desktop/legacy/ms686736(v=vs.85) ------------- PR: https://git.openjdk.org/jdk/pull/9599 From jvernee at openjdk.org Tue Jul 26 13:12:03 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 26 Jul 2022 13:12:03 GMT Subject: RFR: 8290059: Do not use std::thread in panama tests [v2] In-Reply-To: References: Message-ID: On Sat, 23 Jul 2022 05:58:42 GMT, David Holmes wrote: > `run_async` is an odd name for this, especially as the fact you create then join mean it doesn't run asynchronously at all - it runs synchronously in another thread. I took the name from the CompleteableFuture API [1], although in that case a future is returned on which a user can call `get`. I can rename the function. Does `run_in_new_thread` seem good enough? > The API would be more generally useful if you split the start and the join, but that would require also exposing an opaque thread "handle" (though splitting also means you don't have to try and think of a good name for `run_in_a_new_thread-and_join_it()` - you just have `threadStart` and `threadJoin`). I can see this being useful in order to start many threads up front, and then join then all afterwards (to get them running concurrently). Though, I'd like to hold off on getting into that since the current tests don't need that functionality. The library header can be freely amended later as well. [1] : https://docs.oracle.com/en/java/javase/18/docs/api/java.base/java/util/concurrent/CompletableFuture.html#runAsync(java.lang.Runnable) ------------- PR: https://git.openjdk.org/jdk/pull/9599 From jvernee at openjdk.org Tue Jul 26 13:21:08 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 26 Jul 2022 13:21:08 GMT Subject: RFR: 8290373: Enable lossy conversion warnings on Windows [v4] In-Reply-To: References: Message-ID: On Mon, 25 Jul 2022 01:15:31 GMT, David Holmes wrote: > > I propose that when a patch touches a file with lossy conversion warnings disabled, it should also enable the warnings and fix them for that file. > > This contradicts other common recomendations of not mixing unrelated issues in the same PR. Fixing style nits is harmless but fixing an actual lossy conversion issue could itself lead to bugs and unexpected fanout. That's a good point. I think that takes piggybacking on other patches off the table then. ------------- PR: https://git.openjdk.org/jdk/pull/9516 From jvernee at openjdk.org Tue Jul 26 13:43:05 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 26 Jul 2022 13:43:05 GMT Subject: RFR: 8290059: Do not use std::thread in panama tests [v2] In-Reply-To: References: Message-ID: <2_x86cAiZlRioKzyKzv7PDMqNucasO_M79C0AW-HRb0=.8e2690d0-6e21-4787-8c04-f5eb47d01ea3@github.com> On Tue, 26 Jul 2022 12:58:09 GMT, Jorn Vernee wrote: >> test/lib/native/testlib_threads.h line 50: >> >>> 48: static void fatal(const char* message) { >>> 49: perror(message); >>> 50: exit(-1); >> >> Won't work as intended for Windows APIs. I would print the result of `GetLastError()` instead. >> >> Alternatively I am fine fine with just omitting the error code, because I think the old tests did not handle errors either. Or did we catch std::thread exceptions somewhere? > > The intent was to exit the test with a non-zero exit code, in order to avoid any accidental false positives. > > I could return the error code from `GetLastError` and from the respective pthread apis as an exit code instead. Is that what you mean? FWIW, `perror` just prints to `stderr`: https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/perror-wperror?view=msvc-170 ------------- PR: https://git.openjdk.org/jdk/pull/9599 From jvernee at openjdk.org Tue Jul 26 13:47:03 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 26 Jul 2022 13:47:03 GMT Subject: RFR: 8290059: Do not use std::thread in panama tests [v2] In-Reply-To: <2_x86cAiZlRioKzyKzv7PDMqNucasO_M79C0AW-HRb0=.8e2690d0-6e21-4787-8c04-f5eb47d01ea3@github.com> References: <2_x86cAiZlRioKzyKzv7PDMqNucasO_M79C0AW-HRb0=.8e2690d0-6e21-4787-8c04-f5eb47d01ea3@github.com> Message-ID: On Tue, 26 Jul 2022 13:39:50 GMT, Jorn Vernee wrote: >> The intent was to exit the test with a non-zero exit code, in order to avoid any accidental false positives. >> >> I could return the error code from `GetLastError` and from the respective pthread apis as an exit code instead. Is that what you mean? > > FWIW, `perror` just prints to `stderr`: https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/perror-wperror?view=msvc-170 Ah, I see what you mean now. The C standard library function `perror` defines this to also print a textual description of `errno`. https://en.cppreference.com/w/c/io/perror so that won't work for the Windows APIs. I think the alternative would be to use `FormatMessage` on Windows. I didn't really think that much into this. Maybe it's clearer to use `fputs` with `stderr` here. ------------- PR: https://git.openjdk.org/jdk/pull/9599 From hseigel at openjdk.org Tue Jul 26 14:06:31 2022 From: hseigel at openjdk.org (Harold Seigel) Date: Tue, 26 Jul 2022 14:06:31 GMT Subject: RFR: 8285792: Posix signal handler modification checking issues. In-Reply-To: References: Message-ID: On Mon, 25 Jul 2022 20:50:07 GMT, Phil Race wrote: >> So the VM warnings are something of a mild annoyance that we've worked around in this test but it never made sense to me what this has to do with JNI ? At some point it was decided that checkJNI should check for certain user defined signal handlers. Changing that would require a CSR and is outside the scope of this pull request. ------------- PR: https://git.openjdk.org/jdk/pull/9631 From jvernee at openjdk.org Tue Jul 26 14:31:03 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 26 Jul 2022 14:31:03 GMT Subject: RFR: 8290059: Do not use std::thread in panama tests [v3] In-Reply-To: References: Message-ID: <45HrpHpQSNAgY1Pu-pqnKcenMRKrPNfOTorearwc2Aw=.8db27bf0-019f-4344-b7db-54899bee876e@github.com> > This patch removes the use of std::thread from the `java.lang.foreign` tests, and switches to the OS specific thread APIs, in order to change things such as the stack size on some platforms where this is required in the future (see the JBS issue). > > This is done by adding a small header-only library that exposes a function to run code in freshly spawned threads (`run_async`). > > Testing: Running the affected tests on platforms that implement the linker. Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: Review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9599/files - new: https://git.openjdk.org/jdk/pull/9599/files/49e60f2d..cf415f5d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9599&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9599&range=01-02 Stats: 22 lines in 6 files changed: 6 ins; 0 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/9599.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9599/head:pull/9599 PR: https://git.openjdk.org/jdk/pull/9599 From jvernee at openjdk.org Tue Jul 26 14:34:19 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 26 Jul 2022 14:34:19 GMT Subject: RFR: 8290059: Do not use std::thread in panama tests [v4] In-Reply-To: References: Message-ID: > This patch removes the use of std::thread from the `java.lang.foreign` tests, and switches to the OS specific thread APIs, in order to change things such as the stack size on some platforms where this is required in the future (see the JBS issue). > > This is done by adding a small header-only library that exposes a function to run code in freshly spawned threads (`run_async`). > > Testing: Running the affected tests on platforms that implement the linker. Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: 1 more comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9599/files - new: https://git.openjdk.org/jdk/pull/9599/files/cf415f5d..721f70bc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9599&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9599&range=02-03 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9599.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9599/head:pull/9599 PR: https://git.openjdk.org/jdk/pull/9599 From jvernee at openjdk.org Tue Jul 26 14:34:22 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 26 Jul 2022 14:34:22 GMT Subject: RFR: 8290059: Do not use std::thread in panama tests [v2] In-Reply-To: References: Message-ID: On Fri, 22 Jul 2022 16:45:55 GMT, Jorn Vernee wrote: >> This patch removes the use of std::thread from the `java.lang.foreign` tests, and switches to the OS specific thread APIs, in order to change things such as the stack size on some platforms where this is required in the future (see the JBS issue). >> >> This is done by adding a small header-only library that exposes a function to run code in freshly spawned threads (`run_async`). >> >> Testing: Running the affected tests on platforms that implement the linker. > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > Fixes I made some tentative changes based on the review comments: - Added some code comments. - Switch `perror` to `fputs` with `stderr` for clarity. - Use the OS API error code as exit code. - Switch the windows type of `procedure` to exactly what the `CreateThread` expects: https://docs.microsoft.com/en-us/previous-versions/windows/desktop/legacy/ms686736(v=vs.85) - Renamed `run_async` to `run_in_new_thread`. Please take another look. ------------- PR: https://git.openjdk.org/jdk/pull/9599 From hseigel at openjdk.org Tue Jul 26 15:39:54 2022 From: hseigel at openjdk.org (Harold Seigel) Date: Tue, 26 Jul 2022 15:39:54 GMT Subject: RFR: 8285792: Posix signal handler modification checking issues. [v2] In-Reply-To: References: Message-ID: > Please review this fix for JDK-8285792. The fix removes print statements from check_signal_handler() so that it doesn't print all the handlers every time it finds one that is modified. Instead, it returns true if the handler is modified, false otherwise. Its caller, user_handler(), then prints all the handlers just once even if multiple signal handlers were modified. > > The fix also adds a check for VMError::crash_handler_adress() to check_signal_handler() to prevent it from being treated as a signal handler modification. > > The fix was tested with Mach5 tiers 1-2 on Linux and Mac OS and Mach 5 tiers 3-5 on Linux x64. The regression test is excluded on Windows. > > Thanks, Harold Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: Consolidate java test files, change tested signals ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9631/files - new: https://git.openjdk.org/jdk/pull/9631/files/c988e4d2..f57603ff Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9631&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9631&range=00-01 Stats: 68 lines in 4 files changed: 13 ins; 39 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/9631.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9631/head:pull/9631 PR: https://git.openjdk.org/jdk/pull/9631 From hseigel at openjdk.org Tue Jul 26 15:39:57 2022 From: hseigel at openjdk.org (Harold Seigel) Date: Tue, 26 Jul 2022 15:39:57 GMT Subject: RFR: 8285792: Posix signal handler modification checking issues. [v2] In-Reply-To: References: Message-ID: On Mon, 25 Jul 2022 21:58:00 GMT, David Holmes wrote: >> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: >> >> Consolidate java test files, change tested signals > > test/hotspot/jtreg/runtime/posixSig/TestPsig.java line 28: > >> 26: System.loadLibrary("TestPsig"); >> 27: } >> 28: public static native void doSomething(int val); > > Suggestion: > > `private static native void changeSigActionFor(int sig);` Fixed in latest commit. ------------- PR: https://git.openjdk.org/jdk/pull/9631 From ananyanayak102 at gmail.com Tue Jul 26 15:50:40 2022 From: ananyanayak102 at gmail.com (Ananya Nayak) Date: Tue, 26 Jul 2022 21:20:40 +0530 Subject: Issue regarding hugeLength() method of ArraysSupport class in java.internal.util package Message-ID: After analysing the method declaration carefully I realized some bugs in the code: 1. the if condition on seeing min length as less than 0 returns out of memory error with a message that "required length is too large" which is contradictory to what we are checking in the condition. 2. We should actually return the out of memory error when it exceeds the SOFT_ARRAY_MAX_LENGTH 3. Moreover we are returning minLength in the third condition when we actually shouldn't because it exceeds the limit Kindly verify this. -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.joelsson at oracle.com Tue Jul 26 17:04:51 2022 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Tue, 26 Jul 2022 10:04:51 -0700 Subject: Where is STRIP set for clang? In-Reply-To: References: Message-ID: <092e2aac-425e-f29e-9e09-fecc64e6d52d@oracle.com> I'm not very familiar with this, but it looks like clang/llvm does come with its own strip utility, which would make this comment wrong. On Linux, it's likely common to find the gnu binutils strip on the path even when trying to use clang to compile OpenJDK. Ideally we should setup STRIPFLAGS based on probing the strip executable that was found. /Erik On 7/24/22 1:07 AM, Julian Waters wrote: > Found something interesting in FLAGS_SETUP_STRIPFLAGS recently: > ## Setup strip. > # FIXME: should this really be per platform, or should it be per > toolchain type? > # strip is not provided by clang; so guessing platform makes most sense. > > STRIPFLAGS is set to -S after this for clang (or more accurately, when > the OS being compiled for is MacOS), but STRIP for clang (Likely using > the clang driver itself) doesn't seem to be set anywhere within make. > The only place I can find it being set is in > toolchain.m4,?UTIL_LOOKUP_TOOLCHAIN_PROGS(STRIP, strip), when the OS > that's being compiled for != windows. But if the comment that strip > isn't available for clang is still correct and up to date, this > doesn't seem right, considering Linux allows for compiling the JDK > with clang as well, while -S is only set with MacOS, and the != > windows check would also not work properly since it would still check > for the regular strip utility even if the compiler was clang. > > best regards, > Julian From erikj at openjdk.org Tue Jul 26 17:12:21 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 26 Jul 2022 17:12:21 GMT Subject: RFR: 8290466: Default to --with-source-date=current to avoid unmodified Hotspot recompilation In-Reply-To: References: Message-ID: On Tue, 26 Jul 2022 12:28:41 GMT, Aleksey Shipilev wrote: > See the bug for symptoms and rationale. > > In short, after [JDK-8288396](https://bugs.openjdk.org/browse/JDK-8288396) moved the timestamp to `CFLAGS_VM_VERSION` macro, which changes with every build, we get Hotspot recompilation every time, even when Hotspot is not modified. > > I believe current behavior is correct for `--with-source-date=updated` (current default): you do Hotspot build, you get updated build timestamp, which forces recompilation of affected compilation units, relinkage, re-creation of jmods/jimage. The way out is to switch to `--with-source-date=current`, which would only get the build timestamp at configure time. > > CIs and build farms are likely reconfiguring before every build anyway, so their behavior is unlikely to be affected. But this switch definitely improves the day-to-day OpenJDK development work: it saves >50 seconds on every `make` for my machine, see below. > > Back-to-back unmodified build before: > > > $ CONF=linux-x86_64-server-release time make hotspot > Building target 'hotspot' in configuration 'linux-x86_64-server-release' > Finished building target 'hotspot' in configuration 'linux-x86_64-server-release' > > 39.03user 10.97system 0:56.89elapsed 87%CPU (0avgtext+0avgdata 2048944maxresident)k > 363616inputs+4108072outputs (484major+1100154minor)pagefaults 0swaps > > $ CONF=linux-x86_64-server-release time make hotspot > Building target 'hotspot' in configuration 'linux-x86_64-server-release' > Finished building target 'hotspot' in configuration 'linux-x86_64-server-release' > > 38.18user 9.02system 0:49.18elapsed 95%CPU (0avgtext+0avgdata 2048788maxresident)k > 40inputs+4101112outputs (0major+1100077minor)pagefaults 0swaps > > > Back-to-back unmodified build after: > > > $ CONF=linux-x86_64-server-release time make hotspot > Building target 'hotspot' in configuration 'linux-x86_64-server-release' > Finished building target 'hotspot' in configuration 'linux-x86_64-server-release' > > 2.15user 0.22system 0:02.59elapsed 91%CPU (0avgtext+0avgdata 49480maxresident)k > 0inputs+176outputs (0major+55506minor)pagefaults 0swaps > > $ CONF=linux-x86_64-server-release time make hotspot > Building target 'hotspot' in configuration 'linux-x86_64-server-release' > Finished building target 'hotspot' in configuration 'linux-x86_64-server-release' > > 2.18user 0.14system 0:02.46elapsed 94%CPU (0avgtext+0avgdata 49332maxresident)k Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9638 From hseigel at openjdk.org Tue Jul 26 17:16:16 2022 From: hseigel at openjdk.org (Harold Seigel) Date: Tue, 26 Jul 2022 17:16:16 GMT Subject: RFR: 8285792: Posix signal handler modification checking issues. [v3] In-Reply-To: References: Message-ID: > Please review this fix for JDK-8285792. The fix removes print statements from check_signal_handler() so that it doesn't print all the handlers every time it finds one that is modified. Instead, it returns true if the handler is modified, false otherwise. Its caller, user_handler(), then prints all the handlers just once even if multiple signal handlers were modified. > > The fix also adds a check for VMError::crash_handler_adress() to check_signal_handler() to prevent it from being treated as a signal handler modification. > > The fix was tested with Mach5 tiers 1-2 on Linux and Mac OS and Mach 5 tiers 3-5 on Linux x64. The regression test is excluded on Windows. > > Thanks, Harold Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: SIGFPE change ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9631/files - new: https://git.openjdk.org/jdk/pull/9631/files/f57603ff..45515f59 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9631&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9631&range=01-02 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/9631.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9631/head:pull/9631 PR: https://git.openjdk.org/jdk/pull/9631 From hseigel at openjdk.org Tue Jul 26 17:16:18 2022 From: hseigel at openjdk.org (Harold Seigel) Date: Tue, 26 Jul 2022 17:16:18 GMT Subject: RFR: 8285792: Posix signal handler modification checking issues. In-Reply-To: References: Message-ID: On Mon, 25 Jul 2022 21:52:26 GMT, David Holmes wrote: >> Please review this fix for JDK-8285792. The fix removes print statements from check_signal_handler() so that it doesn't print all the handlers every time it finds one that is modified. Instead, it returns true if the handler is modified, false otherwise. Its caller, user_handler(), then prints all the handlers just once even if multiple signal handlers were modified. >> >> The fix also adds a check for VMError::crash_handler_adress() to check_signal_handler() to prevent it from being treated as a signal handler modification. >> >> The fix was tested with Mach5 tiers 1-2 on Linux and Mac OS and Mach 5 tiers 3-5 on Linux x64. The regression test is excluded on Windows. >> >> Thanks, Harold > > Looking at [JDK-4229104](https://bugs.openjdk.org/browse/JDK-4229104) I have to wonder whether our handling of `SIGPIPE` is still necessary? Even if so, the fact we always ignore it if we get it suggests we really don't care if someone else has installed a (temporary) handler for it, so perhaps we should not include it (or `SIGXFSZ`) in these checks? @dholmes-ora Thanks for looking at this. Please review the latest changes. Should I enter a new rfe to look at JVM handling of SIGPIPE and SIGXFSZ in these checks? ------------- PR: https://git.openjdk.org/jdk/pull/9631 From hseigel at openjdk.org Tue Jul 26 17:16:21 2022 From: hseigel at openjdk.org (Harold Seigel) Date: Tue, 26 Jul 2022 17:16:21 GMT Subject: RFR: 8285792: Posix signal handler modification checking issues. [v3] In-Reply-To: References: Message-ID: On Mon, 25 Jul 2022 21:45:30 GMT, David Holmes wrote: >> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: >> >> SIGFPE change > > src/hotspot/os/posix/signals_posix.cpp line 843: > >> 841: // Compare both sigaction structures (intelligently; only the members we care about). >> 842: // Ignore if the handler is our own crash handler. >> 843: if (!are_handlers_equal(&act, expected_act) && > > Pre-existing nit: really this should be called `are_actions_equal`. The poor naming is clearer when you now follow this with `HANDLER_IS`. Thanks for the suggestion. Function are_handlers_equal() is renamed to are_actions_equal() in the latest commit. ------------- PR: https://git.openjdk.org/jdk/pull/9631 From weijun at openjdk.org Tue Jul 26 18:47:12 2022 From: weijun at openjdk.org (Weijun Wang) Date: Tue, 26 Jul 2022 18:47:12 GMT Subject: RFR: 8290920: sspi_bridge.dll not built if BUILD_CRYPTO is false Message-ID: The DLL should be built no matter what `BUILD_CRYPTO` is. ------------- Commit messages: - the fix Changes: https://git.openjdk.org/jdk/pull/9647/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9647&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290920 Stats: 25 lines in 1 file changed: 13 ins; 11 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9647.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9647/head:pull/9647 PR: https://git.openjdk.org/jdk/pull/9647 From aturbanov at openjdk.org Tue Jul 26 19:15:14 2022 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Tue, 26 Jul 2022 19:15:14 GMT Subject: RFR: 8290154: [JVMCI] Implement JVMCI for RISC-V [v4] In-Reply-To: References: Message-ID: On Mon, 25 Jul 2022 14:38:26 GMT, Sacha Coppey wrote: >> This patch adds a partial JVMCI implementation for RISC-V, to allow using the GraalVM Native Image RISC-V LLVM backend, which does not use JVMCI for code emission. >> It creates the jdk.vm.ci.riscv64 and jdk.vm.ci.hotspot.riscv64 packages, as well as implements a part of jvmciCodeInstaller_riscv64.cpp. To check for correctness, it enables JVMCI code installation tests on RISC-V. It will be tested soon in Native Image as well. > > Sacha Coppey has updated the pull request incrementally with one additional commit since the last revision: > > Avoid using set_destination when call is not jal src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.riscv64/src/jdk/vm/ci/riscv64/RISCV64Kind.java line 111: > 109: > 110: public boolean isFP() { > 111: switch(this) { let's add space after `switch` ------------- PR: https://git.openjdk.org/jdk/pull/9587 From hseigel at openjdk.org Tue Jul 26 19:53:10 2022 From: hseigel at openjdk.org (Harold Seigel) Date: Tue, 26 Jul 2022 19:53:10 GMT Subject: RFR: 8285792: Posix signal handler modification checking issues. [v4] In-Reply-To: References: Message-ID: > Please review this fix for JDK-8285792. The fix removes print statements from check_signal_handler() so that it doesn't print all the handlers every time it finds one that is modified. Instead, it returns true if the handler is modified, false otherwise. Its caller, user_handler(), then prints all the handlers just once even if multiple signal handlers were modified. > > The fix also adds a check for VMError::crash_handler_adress() to check_signal_handler() to prevent it from being treated as a signal handler modification. > > The fix was tested with Mach5 tiers 1-2 on Linux and Mac OS and Mach 5 tiers 3-5 on Linux x64. The regression test is excluded on Windows. > > Thanks, Harold Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: fix whitespace issue ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9631/files - new: https://git.openjdk.org/jdk/pull/9631/files/45515f59..bca129a7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9631&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9631&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9631.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9631/head:pull/9631 PR: https://git.openjdk.org/jdk/pull/9631 From duke at openjdk.org Tue Jul 26 20:12:01 2022 From: duke at openjdk.org (Mark Powers) Date: Tue, 26 Jul 2022 20:12:01 GMT Subject: RFR: 8290920: sspi_bridge.dll not built if BUILD_CRYPTO is false In-Reply-To: References: Message-ID: <-nX2tK2Uiv3YvZ0ej-97dX-HwTaFYkLZ1tGfyTz2wro=.23a7e08d-dcf3-4413-b316-fe53b0b38a31@github.com> On Tue, 26 Jul 2022 18:12:33 GMT, Weijun Wang wrote: > The DLL should be built no matter what `BUILD_CRYPTO` is. Your fix looks good to me. I'm assuming sspi_bridge.dll is useful regardless of the value of BUILD_CRYPTO. ------------- PR: https://git.openjdk.org/jdk/pull/9647 From valeriep at openjdk.org Tue Jul 26 23:44:02 2022 From: valeriep at openjdk.org (Valerie Peng) Date: Tue, 26 Jul 2022 23:44:02 GMT Subject: RFR: 8290920: sspi_bridge.dll not built if BUILD_CRYPTO is false In-Reply-To: References: Message-ID: On Tue, 26 Jul 2022 18:12:33 GMT, Weijun Wang wrote: > The DLL should be built no matter what `BUILD_CRYPTO` is. Looks good to me. ------------- Marked as reviewed by valeriep (Reviewer). PR: https://git.openjdk.org/jdk/pull/9647 From david.holmes at oracle.com Wed Jul 27 06:12:32 2022 From: david.holmes at oracle.com (David Holmes) Date: Wed, 27 Jul 2022 16:12:32 +1000 Subject: Issue regarding hugeLength() method of ArraysSupport class in java.internal.util package In-Reply-To: References: Message-ID: <1dad53ad-528b-7c37-3dde-1a0fadfb75b1@oracle.com> Hi, Please take this core core-libs-dev as this is not a build issue. Thanks, David On 27/07/2022 1:50 am, Ananya Nayak wrote: > After analysing the method declaration carefully I realized some bugs in > the code: > > 1. ?the if condition on seeing min length as less than 0 returns out > of memory error with a message that "required length is too large" > which is contradictory to what we are checking in the condition. > 2. We should actually return the out of memory error when it exceeds > the SOFT_ARRAY_MAX_LENGTH > 3. Moreover we are returning minLength in the third condition when we > actually shouldn't because?it exceeds the limit > > Kindly verify this. From ananyanayak102 at gmail.com Wed Jul 27 06:18:44 2022 From: ananyanayak102 at gmail.com (Ananya Nayak) Date: Wed, 27 Jul 2022 11:48:44 +0530 Subject: Issue regarding hugeLength() method of ArraysSupport class in java.internal.util package In-Reply-To: <1dad53ad-528b-7c37-3dde-1a0fadfb75b1@oracle.com> References: <1dad53ad-528b-7c37-3dde-1a0fadfb75b1@oracle.com> Message-ID: Ok, will do that. On Wed, 27 Jul 2022, 11:42 David Holmes, wrote: > Hi, > > Please take this core core-libs-dev as this is not a build issue. > > Thanks, > David > > On 27/07/2022 1:50 am, Ananya Nayak wrote: > > After analysing the method declaration carefully I realized some bugs in > > the code: > > > > 1. the if condition on seeing min length as less than 0 returns out > > of memory error with a message that "required length is too large" > > which is contradictory to what we are checking in the condition. > > 2. We should actually return the out of memory error when it exceeds > > the SOFT_ARRAY_MAX_LENGTH > > 3. Moreover we are returning minLength in the third condition when we > > actually shouldn't because it exceeds the limit > > > > Kindly verify this. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dholmes at openjdk.org Wed Jul 27 06:37:05 2022 From: dholmes at openjdk.org (David Holmes) Date: Wed, 27 Jul 2022 06:37:05 GMT Subject: RFR: 8285792: Posix signal handler modification checking issues. [v4] In-Reply-To: References: Message-ID: <7aSH9c-q_q4y0It4hbMaasSdKGpiaZetfeEIozV0YxA=.1bd7f4fb-0861-47b6-8621-56bc46d113d6@github.com> On Tue, 26 Jul 2022 19:53:10 GMT, Harold Seigel wrote: >> Please review this fix for JDK-8285792. The fix removes print statements from check_signal_handler() so that it doesn't print all the handlers every time it finds one that is modified. Instead, it returns true if the handler is modified, false otherwise. Its caller, user_handler(), then prints all the handlers just once even if multiple signal handlers were modified. >> >> The fix also adds a check for VMError::crash_handler_adress() to check_signal_handler() to prevent it from being treated as a signal handler modification. >> >> The fix was tested with Mach5 tiers 1-2 on Linux and Mac OS and Mach 5 tiers 3-5 on Linux x64. The regression test is excluded on Windows. >> >> Thanks, Harold > > Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: > > fix whitespace issue Hi Harold, Updates look good - thanks. Please file a RFE to look at omitting SIGPIPE and perhaps SIGXFSZ from the check. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/9631 From dholmes at openjdk.org Wed Jul 27 06:47:02 2022 From: dholmes at openjdk.org (David Holmes) Date: Wed, 27 Jul 2022 06:47:02 GMT Subject: RFR: 8290059: Do not use std::thread in panama tests [v2] In-Reply-To: References: Message-ID: On Tue, 26 Jul 2022 13:10:00 GMT, Jorn Vernee wrote: > Does run_in_new_thread seem good enough? No, sorry, the fact it both runs and joins is a critical aspect. `run_async` in `CompleteableFuture` just does the "run in new thread" part, whereas the `get()` on the returned `FutureTask` provides the "join". So a function that does both needs to make that clear in the name - and there is no nice succinct name for that, so we get stuck with something like `run_in_new_thread_and_join`. Or we just have ` startThread` and `joinThread` :) ------------- PR: https://git.openjdk.org/jdk/pull/9599 From lgxbslgx at gmail.com Wed Jul 27 08:30:14 2022 From: lgxbslgx at gmail.com (Guoxiong Li) Date: Wed, 27 Jul 2022 16:30:14 +0800 Subject: Building failed when using the options `--always-make` and `JOBS=4` Message-ID: Hi all, When using the command `make images --always-make CONF_CHECK=ignore JOBS=4` to build the JDK, it doesn't succeed and returns the error message (See below for detail). It seems that two or more processes concurrently process the target `module-deps.gmk` which exists in the file `make/common/Modules.gmk`. All these processes print module dependence information into file `build/linux-x86_64-server-slowdebug/make-support/module-deps.gmk` so that the file `module-deps.gmk` contains unqualified information. I attach my local file `module-deps.gmk` for you to read. It is a bug which is related to both parallelism and the option `--always-make`. So if you remove `JOBS=4` or `--always-make`, you can not reproduce the bug. And we may never use the argument `--always-make` because it takes more time to build the JDK. But unfortunately, when using vscode support according to the JDK document [1] and using the vscode extension `ms-vscode.makefile-tools` [2], this extension will use the argument `--always-make` and then will report this error. [1] https://github.com/openjdk/jdk/blob/master/doc/ide.md [2] https://github.com/microsoft/vscode-makefile-tools/ Here is the error message during building. ``` Building target 'images' in configuration 'linux-x86_64-server-slowdebug' Compiling 1 files for BUILD_TOOLS_HOTSPOT Compiling 8 files for BUILD_TOOLS_LANGTOOLS /home/lgx/source/java/jdk-vscode/build/linux-x86_64-server-slowdebug/make-support/module-deps.gmk:8: *** missing separator. Stop. make/Main.gmk:157: recipe for target 'java.base-copy' failed make[2]: *** [java.base-copy] Error 2 make[2]: *** Waiting for unfinished jobs.... /home/lgx/source/java/jdk-vscode/build/linux-x86_64-server-slowdebug/make-support/module-deps.gmk:8: *** missing separator. Stop. make/Main.gmk:157: recipe for target 'java.desktop-copy' failed make[2]: *** [java.desktop-copy] Error 2 ERROR: Build failed for target 'images' in configuration 'linux-x86_64-server-slowdebug' (exit code 2) === Make failed targets repeated here === make/Main.gmk:157: recipe for target 'java.base-copy' failed make/Main.gmk:157: recipe for target 'java.desktop-copy' failed === End of repeated output === HELP: Try searching the build log for the name of the first failed target. HELP: Run 'make doctor' to diagnose build problems. /home/lgx/source/java/jdk-vscode/make/Init.gmk:310: recipe for target 'main' failed make[1]: *** [main] Error 2 /home/lgx/source/java/jdk-vscode/make/Init.gmk:186: recipe for target 'images' failed make: *** [images] Error 2 ``` Best Regards, -- Guoxiong -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: module-deps.gmk Type: application/octet-stream Size: 14807 bytes Desc: not available URL: From lgxbslgx at gmail.com Wed Jul 27 08:30:14 2022 From: lgxbslgx at gmail.com (Guoxiong Li) Date: Wed, 27 Jul 2022 16:30:14 +0800 Subject: Building failed when using the options `--always-make` and `JOBS=4` Message-ID: Hi all, When using the command `make images --always-make CONF_CHECK=ignore JOBS=4` to build the JDK, it doesn't succeed and returns the error message (See below for detail). It seems that two or more processes concurrently process the target `module-deps.gmk` which exists in the file `make/common/Modules.gmk`. All these processes print module dependence information into file `build/linux-x86_64-server-slowdebug/make-support/module-deps.gmk` so that the file `module-deps.gmk` contains unqualified information. I attach my local file `module-deps.gmk` for you to read. It is a bug which is related to both parallelism and the option `--always-make`. So if you remove `JOBS=4` or `--always-make`, you can not reproduce the bug. And we may never use the argument `--always-make` because it takes more time to build the JDK. But unfortunately, when using vscode support according to the JDK document [1] and using the vscode extension `ms-vscode.makefile-tools` [2], this extension will use the argument `--always-make` and then will report this error. [1] https://github.com/openjdk/jdk/blob/master/doc/ide.md [2] https://github.com/microsoft/vscode-makefile-tools/ Here is the error message during building. ``` Building target 'images' in configuration 'linux-x86_64-server-slowdebug' Compiling 1 files for BUILD_TOOLS_HOTSPOT Compiling 8 files for BUILD_TOOLS_LANGTOOLS /home/lgx/source/java/jdk-vscode/build/linux-x86_64-server-slowdebug/make-support/module-deps.gmk:8: *** missing separator. Stop. make/Main.gmk:157: recipe for target 'java.base-copy' failed make[2]: *** [java.base-copy] Error 2 make[2]: *** Waiting for unfinished jobs.... /home/lgx/source/java/jdk-vscode/build/linux-x86_64-server-slowdebug/make-support/module-deps.gmk:8: *** missing separator. Stop. make/Main.gmk:157: recipe for target 'java.desktop-copy' failed make[2]: *** [java.desktop-copy] Error 2 ERROR: Build failed for target 'images' in configuration 'linux-x86_64-server-slowdebug' (exit code 2) === Make failed targets repeated here === make/Main.gmk:157: recipe for target 'java.base-copy' failed make/Main.gmk:157: recipe for target 'java.desktop-copy' failed === End of repeated output === HELP: Try searching the build log for the name of the first failed target. HELP: Run 'make doctor' to diagnose build problems. /home/lgx/source/java/jdk-vscode/make/Init.gmk:310: recipe for target 'main' failed make[1]: *** [main] Error 2 /home/lgx/source/java/jdk-vscode/make/Init.gmk:186: recipe for target 'images' failed make: *** [images] Error 2 ``` Best Regards, -- Guoxiong -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: module-deps.gmk Type: application/octet-stream Size: 14807 bytes Desc: not available URL: From duke at openjdk.org Wed Jul 27 11:25:22 2022 From: duke at openjdk.org (Sacha Coppey) Date: Wed, 27 Jul 2022 11:25:22 GMT Subject: RFR: 8290154: [JVMCI] Implement JVMCI for RISC-V [v5] In-Reply-To: References: Message-ID: > This patch adds a partial JVMCI implementation for RISC-V, to allow using the GraalVM Native Image RISC-V LLVM backend, which does not use JVMCI for code emission. > It creates the jdk.vm.ci.riscv64 and jdk.vm.ci.hotspot.riscv64 packages, as well as implements a part of jvmciCodeInstaller_riscv64.cpp. To check for correctness, it enables JVMCI code installation tests on RISC-V. It will be tested soon in Native Image as well. Sacha Coppey has updated the pull request incrementally with one additional commit since the last revision: Add space in switch ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9587/files - new: https://git.openjdk.org/jdk/pull/9587/files/9f7cbf6c..8742b9b2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9587&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9587&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9587.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9587/head:pull/9587 PR: https://git.openjdk.org/jdk/pull/9587 From duke at openjdk.org Wed Jul 27 11:25:26 2022 From: duke at openjdk.org (Sacha Coppey) Date: Wed, 27 Jul 2022 11:25:26 GMT Subject: RFR: 8290154: [JVMCI] Implement JVMCI for RISC-V [v4] In-Reply-To: References: Message-ID: On Tue, 26 Jul 2022 19:11:23 GMT, Andrey Turbanov wrote: >> Sacha Coppey has updated the pull request incrementally with one additional commit since the last revision: >> >> Avoid using set_destination when call is not jal > > src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.riscv64/src/jdk/vm/ci/riscv64/RISCV64Kind.java line 111: > >> 109: >> 110: public boolean isFP() { >> 111: switch(this) { > > let's add space after `switch` Sure! ------------- PR: https://git.openjdk.org/jdk/pull/9587 From erik.joelsson at oracle.com Wed Jul 27 12:18:59 2022 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Wed, 27 Jul 2022 05:18:59 -0700 Subject: Building failed when using the options `--always-make` and `JOBS=4` In-Reply-To: References: Message-ID: Hello, Building with --always-make seems like a bad idea and I would say not recommended with the OpenJDK build. We try very hard to keep the incremental build correct and reliable. While this particular problem could be fixed, I wouldn't be surprised if there is more build logic that relies on dependency evaluation to actually be correct in our build. Are you sure you can't configure the plugin to not add this parameter? /Erik On 7/27/22 1:30 AM, Guoxiong Li wrote: > Hi all, > > When using the command `make images --always-make CONF_CHECK=ignore > JOBS=4` to build the JDK, > it doesn't succeed and returns the error message (See below for detail). > It seems that two or more processes concurrently process the target > `module-deps.gmk` which exists in the file `make/common/Modules.gmk`. > All these processes print module dependence information into file > `build/linux-x86_64-server-slowdebug/make-support/module-deps.gmk` > so that the file `module-deps.gmk` contains unqualified information. I > attach my local file `module-deps.gmk` for you to read. > > It is a bug which is related to both parallelism and the option > `--always-make`. > So if you remove `JOBS=4` or `--always-make`, you can not reproduce > the bug. > And we may never use the argument `--always-make` because it takes > more time to build the JDK. > But unfortunately, when using?vscode support according to the JDK > document [1] and using the vscode extension `ms-vscode.makefile-tools` > [2], > this extension will use the argument `--always-make` and then will > report this error. > > [1] https://github.com/openjdk/jdk/blob/master/doc/ide.md > [2] https://github.com/microsoft/vscode-makefile-tools/ > > > Here is the error message during building. > ``` > Building target 'images' in configuration 'linux-x86_64-server-slowdebug' > Compiling 1 files for BUILD_TOOLS_HOTSPOT > Compiling 8 files for BUILD_TOOLS_LANGTOOLS > /home/lgx/source/java/jdk-vscode/build/linux-x86_64-server-slowdebug/make-support/module-deps.gmk:8: > *** missing separator.? Stop. > make/Main.gmk:157: recipe for target 'java.base-copy' failed > make[2]: *** [java.base-copy] Error 2 > make[2]: *** Waiting for unfinished jobs.... > /home/lgx/source/java/jdk-vscode/build/linux-x86_64-server-slowdebug/make-support/module-deps.gmk:8: > *** missing separator.? Stop. > make/Main.gmk:157: recipe for target 'java.desktop-copy' failed > make[2]: *** [java.desktop-copy] Error 2 > > ERROR: Build failed for target 'images' in configuration > 'linux-x86_64-server-slowdebug' (exit code 2) > > === Make failed targets repeated here === > make/Main.gmk:157: recipe for target 'java.base-copy' failed > make/Main.gmk:157: recipe for target 'java.desktop-copy' failed > === End of repeated output === > > HELP: Try searching the build log for the name of the first failed target. > HELP: Run 'make doctor' to diagnose build problems. > > /home/lgx/source/java/jdk-vscode/make/Init.gmk:310: recipe for target > 'main' failed > make[1]: *** [main] Error 2 > /home/lgx/source/java/jdk-vscode/make/Init.gmk:186: recipe for target > 'images' failed > make: *** [images] Error 2 > ``` > > Best Regards, > -- Guoxiong -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.joelsson at oracle.com Wed Jul 27 12:18:59 2022 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Wed, 27 Jul 2022 05:18:59 -0700 Subject: Building failed when using the options `--always-make` and `JOBS=4` In-Reply-To: References: Message-ID: Hello, Building with --always-make seems like a bad idea and I would say not recommended with the OpenJDK build. We try very hard to keep the incremental build correct and reliable. While this particular problem could be fixed, I wouldn't be surprised if there is more build logic that relies on dependency evaluation to actually be correct in our build. Are you sure you can't configure the plugin to not add this parameter? /Erik On 7/27/22 1:30 AM, Guoxiong Li wrote: > Hi all, > > When using the command `make images --always-make CONF_CHECK=ignore > JOBS=4` to build the JDK, > it doesn't succeed and returns the error message (See below for detail). > It seems that two or more processes concurrently process the target > `module-deps.gmk` which exists in the file `make/common/Modules.gmk`. > All these processes print module dependence information into file > `build/linux-x86_64-server-slowdebug/make-support/module-deps.gmk` > so that the file `module-deps.gmk` contains unqualified information. I > attach my local file `module-deps.gmk` for you to read. > > It is a bug which is related to both parallelism and the option > `--always-make`. > So if you remove `JOBS=4` or `--always-make`, you can not reproduce > the bug. > And we may never use the argument `--always-make` because it takes > more time to build the JDK. > But unfortunately, when using?vscode support according to the JDK > document [1] and using the vscode extension `ms-vscode.makefile-tools` > [2], > this extension will use the argument `--always-make` and then will > report this error. > > [1] https://github.com/openjdk/jdk/blob/master/doc/ide.md > [2] https://github.com/microsoft/vscode-makefile-tools/ > > > Here is the error message during building. > ``` > Building target 'images' in configuration 'linux-x86_64-server-slowdebug' > Compiling 1 files for BUILD_TOOLS_HOTSPOT > Compiling 8 files for BUILD_TOOLS_LANGTOOLS > /home/lgx/source/java/jdk-vscode/build/linux-x86_64-server-slowdebug/make-support/module-deps.gmk:8: > *** missing separator.? Stop. > make/Main.gmk:157: recipe for target 'java.base-copy' failed > make[2]: *** [java.base-copy] Error 2 > make[2]: *** Waiting for unfinished jobs.... > /home/lgx/source/java/jdk-vscode/build/linux-x86_64-server-slowdebug/make-support/module-deps.gmk:8: > *** missing separator.? Stop. > make/Main.gmk:157: recipe for target 'java.desktop-copy' failed > make[2]: *** [java.desktop-copy] Error 2 > > ERROR: Build failed for target 'images' in configuration > 'linux-x86_64-server-slowdebug' (exit code 2) > > === Make failed targets repeated here === > make/Main.gmk:157: recipe for target 'java.base-copy' failed > make/Main.gmk:157: recipe for target 'java.desktop-copy' failed > === End of repeated output === > > HELP: Try searching the build log for the name of the first failed target. > HELP: Run 'make doctor' to diagnose build problems. > > /home/lgx/source/java/jdk-vscode/make/Init.gmk:310: recipe for target > 'main' failed > make[1]: *** [main] Error 2 > /home/lgx/source/java/jdk-vscode/make/Init.gmk:186: recipe for target > 'images' failed > make: *** [images] Error 2 > ``` > > Best Regards, > -- Guoxiong -------------- next part -------------- An HTML attachment was scrubbed... URL: From erikj at openjdk.org Wed Jul 27 12:19:33 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 27 Jul 2022 12:19:33 GMT Subject: RFR: 8285792: Posix signal handler modification checking issues. [v4] In-Reply-To: References: Message-ID: On Tue, 26 Jul 2022 19:53:10 GMT, Harold Seigel wrote: >> Please review this fix for JDK-8285792. The fix removes print statements from check_signal_handler() so that it doesn't print all the handlers every time it finds one that is modified. Instead, it returns true if the handler is modified, false otherwise. Its caller, user_handler(), then prints all the handlers just once even if multiple signal handlers were modified. >> >> The fix also adds a check for VMError::crash_handler_adress() to check_signal_handler() to prevent it from being treated as a signal handler modification. >> >> The fix was tested with Mach5 tiers 1-2 on Linux and Mac OS and Mach 5 tiers 3-5 on Linux x64. The regression test is excluded on Windows. >> >> Thanks, Harold > > Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: > > fix whitespace issue Build change looks good. ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.org/jdk/pull/9631 From weijun at openjdk.org Wed Jul 27 12:22:41 2022 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 27 Jul 2022 12:22:41 GMT Subject: RFR: 8290920: sspi_bridge.dll not built if BUILD_CRYPTO is false [v2] In-Reply-To: References: Message-ID: > The DLL should be built no matter what `BUILD_CRYPTO` is. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: indentation change ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9647/files - new: https://git.openjdk.org/jdk/pull/9647/files/3f9551e2..9be09545 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9647&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9647&range=00-01 Stats: 9 lines in 1 file changed: 0 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/9647.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9647/head:pull/9647 PR: https://git.openjdk.org/jdk/pull/9647 From erikj at openjdk.org Wed Jul 27 12:22:42 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 27 Jul 2022 12:22:42 GMT Subject: RFR: 8290920: sspi_bridge.dll not built if BUILD_CRYPTO is false [v2] In-Reply-To: References: Message-ID: On Wed, 27 Jul 2022 12:06:51 GMT, Weijun Wang wrote: >> The DLL should be built no matter what `BUILD_CRYPTO` is. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > indentation change Looks good. Minor style nit. We like to have 2 space indent for logical blocks and 4 space for continuation in the makefiles. See https://openjdk.org/groups/build/doc/code-conventions.html. So in this case, please remove 2 spaces from everything in the new ifeq block. ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.org/jdk/pull/9647 From lgxbslgx at gmail.com Wed Jul 27 12:36:16 2022 From: lgxbslgx at gmail.com (Guoxiong Li) Date: Wed, 27 Jul 2022 20:36:16 +0800 Subject: Building failed when using the options `--always-make` and `JOBS=4` In-Reply-To: References: Message-ID: Hi Erik, Thanks for replying to this thread. > Are you sure you can't configure the plugin to not add this parameter? The configuration can be changed and I fixed it locally just now. But it needs more time to dive into the extension and its configuration. Maybe it is good to provide some information about it in the document `ide.md`. I don't know whether it is a good idea to fix this particular issue if `--always-make` is not suggested now. And other issues may occur after fixing this particular issue if the current building system doesn't support `--always-make` completely. Best Regards, -- Guoxiong -------------- next part -------------- An HTML attachment was scrubbed... URL: From lgxbslgx at gmail.com Wed Jul 27 12:36:16 2022 From: lgxbslgx at gmail.com (Guoxiong Li) Date: Wed, 27 Jul 2022 20:36:16 +0800 Subject: Building failed when using the options `--always-make` and `JOBS=4` In-Reply-To: References: Message-ID: Hi Erik, Thanks for replying to this thread. > Are you sure you can't configure the plugin to not add this parameter? The configuration can be changed and I fixed it locally just now. But it needs more time to dive into the extension and its configuration. Maybe it is good to provide some information about it in the document `ide.md`. I don't know whether it is a good idea to fix this particular issue if `--always-make` is not suggested now. And other issues may occur after fixing this particular issue if the current building system doesn't support `--always-make` completely. Best Regards, -- Guoxiong -------------- next part -------------- An HTML attachment was scrubbed... URL: From hseigel at openjdk.org Wed Jul 27 12:55:22 2022 From: hseigel at openjdk.org (Harold Seigel) Date: Wed, 27 Jul 2022 12:55:22 GMT Subject: RFR: 8285792: Posix signal handler modification checking issues. [v4] In-Reply-To: References: Message-ID: On Tue, 26 Jul 2022 19:53:10 GMT, Harold Seigel wrote: >> Please review this fix for JDK-8285792. The fix removes print statements from check_signal_handler() so that it doesn't print all the handlers every time it finds one that is modified. Instead, it returns true if the handler is modified, false otherwise. Its caller, user_handler(), then prints all the handlers just once even if multiple signal handlers were modified. >> >> The fix also adds a check for VMError::crash_handler_adress() to check_signal_handler() to prevent it from being treated as a signal handler modification. >> >> The fix was tested with Mach5 tiers 1-2 on Linux and Mac OS and Mach 5 tiers 3-5 on Linux x64. The regression test is excluded on Windows. >> >> Thanks, Harold > > Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: > > fix whitespace issue Thanks David and Erik for the reviews! ------------- PR: https://git.openjdk.org/jdk/pull/9631 From hseigel at openjdk.org Wed Jul 27 12:55:28 2022 From: hseigel at openjdk.org (Harold Seigel) Date: Wed, 27 Jul 2022 12:55:28 GMT Subject: Integrated: 8285792: Posix signal handler modification checking issues. In-Reply-To: References: Message-ID: <8ay0nKpjlbf5QlgaRscu8VMAEgWh8efUBMdfKPYZLYM=.1001f6c2-df7e-462d-b861-459924597f51@github.com> On Mon, 25 Jul 2022 17:21:27 GMT, Harold Seigel wrote: > Please review this fix for JDK-8285792. The fix removes print statements from check_signal_handler() so that it doesn't print all the handlers every time it finds one that is modified. Instead, it returns true if the handler is modified, false otherwise. Its caller, user_handler(), then prints all the handlers just once even if multiple signal handlers were modified. > > The fix also adds a check for VMError::crash_handler_adress() to check_signal_handler() to prevent it from being treated as a signal handler modification. > > The fix was tested with Mach5 tiers 1-2 on Linux and Mac OS and Mach 5 tiers 3-5 on Linux x64. The regression test is excluded on Windows. > > Thanks, Harold This pull request has now been integrated. Changeset: 48b77a69 Author: Harold Seigel URL: https://git.openjdk.org/jdk/commit/48b77a69697adb9967e58a18e1f248afb30e1b26 Stats: 171 lines in 4 files changed: 146 ins; 4 del; 21 mod 8285792: Posix signal handler modification checking issues. Reviewed-by: dholmes, erikj ------------- PR: https://git.openjdk.org/jdk/pull/9631 From jvernee at openjdk.org Wed Jul 27 14:34:49 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 27 Jul 2022 14:34:49 GMT Subject: RFR: 8290059: Do not use std::thread in panama tests [v5] In-Reply-To: References: Message-ID: > This patch removes the use of std::thread from the `java.lang.foreign` tests, and switches to the OS specific thread APIs, in order to change things such as the stack size on some platforms where this is required in the future (see the JBS issue). > > This is done by adding a small header-only library that exposes a function to run code in freshly spawned threads (`run_async`). > > Testing: Running the affected tests on platforms that implement the linker. Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: run_in_new_thread_and_join ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9599/files - new: https://git.openjdk.org/jdk/pull/9599/files/721f70bc..be6c484b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9599&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9599&range=03-04 Stats: 7 lines in 6 files changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/9599.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9599/head:pull/9599 PR: https://git.openjdk.org/jdk/pull/9599 From jvernee at openjdk.org Wed Jul 27 14:34:50 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 27 Jul 2022 14:34:50 GMT Subject: RFR: 8290059: Do not use std::thread in panama tests [v2] In-Reply-To: References: Message-ID: <-HTKS0BueluMoHSQIduIEL24ZwPswDbdwzMOd3l64FM=.a00f15aa-2677-4319-ba9f-32639da0c23a@github.com> On Wed, 27 Jul 2022 06:43:45 GMT, David Holmes wrote: > > Does run_in_new_thread seem good enough? > > No, sorry, the fact it both runs and joins is a critical aspect. `run_async` in `CompleteableFuture` just does the "run in new thread" part, whereas the `get()` on the returned `FutureTask` provides the "join". So a function that does both needs to make that clear in the name - and there is no nice succinct name for that, so we get stuck with something like `run_in_new_thread_and_join`. Or we just have ` startThread` and `joinThread` :) `startThread` and `joinThread` is not the functionality that the tests need. The functionality that's needed is one that combines these two, so that's what I went with. An API without real users is harder to get right. I've looked into adding `startThread` and `joinThread`. But, the story is not so simple. Since now the context passed to `CreateThread` and `pthread_create` has to outlive the function, which means heap allocating, or asking the caller to stack allocate. I think a typical C API might have a `new_thread` and `delete_thread` to do the memory management. These functions could be folded into `startThread` and `joinThread`, and we'd rename those to `create_and_start_thread` and `join_and_destroy_thread` (I think it's important to signal to callers that allocation happens, so that the memory will be cleaned up by calling join as well), but at that point it feels like we're back where we started. The alternative being stack allocation. i.e. the caller declares a `THREAD` variable and passes a pointer to it to `start_thread`, which then uses that memory. This avoids the heap allocation, but adds more noise in the caller. Getting into that just feels like too much unneeded complexity at this moment. So, `run_in_new_thread_and_join` it is. ------------- PR: https://git.openjdk.org/jdk/pull/9599 From shade at openjdk.org Wed Jul 27 14:44:55 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 27 Jul 2022 14:44:55 GMT Subject: RFR: 8290466: Default to --with-source-date=current to avoid unmodified Hotspot recompilation In-Reply-To: References: Message-ID: <0H8lVlF2TSnbHWIf2cSxDQtpECHSeY_wDjQ0tb4oHw8=.2691e136-0b1e-4e02-ab55-708c449d5858@github.com> On Tue, 26 Jul 2022 12:28:41 GMT, Aleksey Shipilev wrote: > See the bug for symptoms and rationale. > > In short, after [JDK-8288396](https://bugs.openjdk.org/browse/JDK-8288396) moved the timestamp to `CFLAGS_VM_VERSION` macro, which changes with every build, we get Hotspot recompilation every time, even when Hotspot is not modified. > > I believe current behavior is correct for `--with-source-date=updated` (current default): you do Hotspot build, you get updated build timestamp, which forces recompilation of affected compilation units, relinkage, re-creation of jmods/jimage. The way out is to switch to `--with-source-date=current`, which would only get the build timestamp at configure time. > > CIs and build farms are likely reconfiguring before every build anyway, so their behavior is unlikely to be affected. But this switch definitely improves the day-to-day OpenJDK development work: it saves >50 seconds on every `make` for my machine, see below. > > Back-to-back unmodified build before: > > > $ CONF=linux-x86_64-server-release time make hotspot > Building target 'hotspot' in configuration 'linux-x86_64-server-release' > Finished building target 'hotspot' in configuration 'linux-x86_64-server-release' > > 39.03user 10.97system 0:56.89elapsed 87%CPU (0avgtext+0avgdata 2048944maxresident)k > 363616inputs+4108072outputs (484major+1100154minor)pagefaults 0swaps > > $ CONF=linux-x86_64-server-release time make hotspot > Building target 'hotspot' in configuration 'linux-x86_64-server-release' > Finished building target 'hotspot' in configuration 'linux-x86_64-server-release' > > 38.18user 9.02system 0:49.18elapsed 95%CPU (0avgtext+0avgdata 2048788maxresident)k > 40inputs+4101112outputs (0major+1100077minor)pagefaults 0swaps > > > Back-to-back unmodified build after: > > > $ CONF=linux-x86_64-server-release time make hotspot > Building target 'hotspot' in configuration 'linux-x86_64-server-release' > Finished building target 'hotspot' in configuration 'linux-x86_64-server-release' > > 2.15user 0.22system 0:02.59elapsed 91%CPU (0avgtext+0avgdata 49480maxresident)k > 0inputs+176outputs (0major+55506minor)pagefaults 0swaps > > $ CONF=linux-x86_64-server-release time make hotspot > Building target 'hotspot' in configuration 'linux-x86_64-server-release' > Finished building target 'hotspot' in configuration 'linux-x86_64-server-release' > > 2.18user 0.14system 0:02.46elapsed 94%CPU (0avgtext+0avgdata 49332maxresident)k Any other opinions? ------------- PR: https://git.openjdk.org/jdk/pull/9638 From naoto at openjdk.org Wed Jul 27 18:13:34 2022 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 27 Jul 2022 18:13:34 GMT Subject: RFR: 8290488: IBM864 character encoding implementation bug Message-ID: Adding an extra c2b mapping for the `%` in `IBM864` charset. The discrepancy came from the mapping difference between MS and IBM. ------------- Commit messages: - Fix 0x25 c2b in IBM864 Changes: https://git.openjdk.org/jdk/pull/9661/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9661&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290488 Stats: 6 lines in 3 files changed: 2 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/9661.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9661/head:pull/9661 PR: https://git.openjdk.org/jdk/pull/9661 From iris at openjdk.org Wed Jul 27 19:19:13 2022 From: iris at openjdk.org (Iris Clark) Date: Wed, 27 Jul 2022 19:19:13 GMT Subject: RFR: 8290488: IBM864 character encoding implementation bug In-Reply-To: References: Message-ID: On Wed, 27 Jul 2022 17:47:36 GMT, Naoto Sato wrote: > Adding an extra c2b mapping for the `%` in `IBM864` charset. The discrepancy came from the mapping difference between MS and IBM. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9661 From tanksherman27 at gmail.com Thu Jul 28 02:46:36 2022 From: tanksherman27 at gmail.com (Julian Waters) Date: Thu, 28 Jul 2022 10:46:36 +0800 Subject: Where is STRIP set for clang? In-Reply-To: <092e2aac-425e-f29e-9e09-fecc64e6d52d@oracle.com> References: <092e2aac-425e-f29e-9e09-fecc64e6d52d@oracle.com> Message-ID: What would be a good way to test for the strip executable? The easiest solution off the top of my head is to assume a particular compiler uses a particular strip, but that sounds a little too inflexible. best regards, Julian On Wed, Jul 27, 2022 at 1:04 AM wrote: > I'm not very familiar with this, but it looks like clang/llvm does come > with its own strip utility, which would make this comment wrong. > > On Linux, it's likely common to find the gnu binutils strip on the path > even when trying to use clang to compile OpenJDK. Ideally we should > setup STRIPFLAGS based on probing the strip executable that was found. > > /Erik > > On 7/24/22 1:07 AM, Julian Waters wrote: > > Found something interesting in FLAGS_SETUP_STRIPFLAGS recently: > > ## Setup strip. > > # FIXME: should this really be per platform, or should it be per > > toolchain type? > > # strip is not provided by clang; so guessing platform makes most sense. > > > > STRIPFLAGS is set to -S after this for clang (or more accurately, when > > the OS being compiled for is MacOS), but STRIP for clang (Likely using > > the clang driver itself) doesn't seem to be set anywhere within make. > > The only place I can find it being set is in > > toolchain.m4, UTIL_LOOKUP_TOOLCHAIN_PROGS(STRIP, strip), when the OS > > that's being compiled for != windows. But if the comment that strip > > isn't available for clang is still correct and up to date, this > > doesn't seem right, considering Linux allows for compiling the JDK > > with clang as well, while -S is only set with MacOS, and the != > > windows check would also not work properly since it would still check > > for the regular strip utility even if the compiler was clang. > > > > best regards, > > Julian > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dholmes at openjdk.org Thu Jul 28 04:59:31 2022 From: dholmes at openjdk.org (David Holmes) Date: Thu, 28 Jul 2022 04:59:31 GMT Subject: RFR: 8290059: Do not use std::thread in panama tests [v2] In-Reply-To: <-HTKS0BueluMoHSQIduIEL24ZwPswDbdwzMOd3l64FM=.a00f15aa-2677-4319-ba9f-32639da0c23a@github.com> References: <-HTKS0BueluMoHSQIduIEL24ZwPswDbdwzMOd3l64FM=.a00f15aa-2677-4319-ba9f-32639da0c23a@github.com> Message-ID: <1eo26bTf2CEWe-9qAq4ZSWIuI436q4itVdSqkMrvcPk=.481da348-9fd2-4407-9885-19500b65eb93@github.com> On Wed, 27 Jul 2022 14:29:26 GMT, Jorn Vernee wrote: > startThread and joinThread is not the functionality that the tests need. But it is the functionality the tests are already using. > now the context passed to CreateThread and pthread_create has to outlive the function That's not an issue for the API to solve, that is an issue for the user of the API to solve. pthread_create doesn't involve any memory management. > So, run_in_new_thread_and_join it is. Okay, that is fine. ------------- PR: https://git.openjdk.org/jdk/pull/9599 From jvernee at openjdk.org Thu Jul 28 11:21:50 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Thu, 28 Jul 2022 11:21:50 GMT Subject: RFR: 8290059: Do not use std::thread in panama tests [v2] In-Reply-To: References: Message-ID: On Fri, 22 Jul 2022 18:44:30 GMT, Thomas Stuefe wrote: >> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixes > > Hi @JornVernee, > > good job and thanks for doing it so quickly. Looks good, module the GetLastError comment. > > About the stack size and Alpine, I am fine with doing the A?pine-specific fix in a follow-up, or you can do it as part of this change. Strictly speaking its not part of this bug report to adjust the stack size. > > If you fix the GetLastError issue, I don't need another look. > Thanks, Thomas @tstuefe Do the changes I made look good? If so I'll go ahead and integrate. ------------- PR: https://git.openjdk.org/jdk/pull/9599 From jwaters at openjdk.org Thu Jul 28 11:35:00 2022 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 28 Jul 2022 11:35:00 GMT Subject: RFR: 8291454: Missing check for JLI C runtime library in CoreLibraries.gmk Message-ID: CoreLibraries.gmk is missing a check for MSVCR_DLL. This results in a defined, but empty macro in libjli if it is not defined in the build system, which is incorrect ------------- Commit messages: - Add missing check in JLI macro definitions Changes: https://git.openjdk.org/jdk/pull/9669/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9669&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8291454 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/9669.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9669/head:pull/9669 PR: https://git.openjdk.org/jdk/pull/9669 From stuefe at openjdk.org Thu Jul 28 11:41:38 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 28 Jul 2022 11:41:38 GMT Subject: RFR: 8290059: Do not use std::thread in panama tests [v5] In-Reply-To: References: Message-ID: On Wed, 27 Jul 2022 14:34:49 GMT, Jorn Vernee wrote: >> This patch removes the use of std::thread from the `java.lang.foreign` tests, and switches to the OS specific thread APIs, in order to change things such as the stack size on some platforms where this is required in the future (see the JBS issue). >> >> This is done by adding a small header-only library that exposes a function to run code in freshly spawned threads (`run_async`). >> >> Testing: Running the affected tests on platforms that implement the linker. > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > run_in_new_thread_and_join Looks still good. ------------- PR: https://git.openjdk.org/jdk/pull/9599 From erikj at openjdk.org Thu Jul 28 12:30:02 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 28 Jul 2022 12:30:02 GMT Subject: RFR: 8291454: Missing check for JLI C runtime library in CoreLibraries.gmk In-Reply-To: References: Message-ID: On Thu, 28 Jul 2022 02:20:26 GMT, Julian Waters wrote: > CoreLibraries.gmk is missing a check for MSVCR_DLL. This results in a defined, but empty macro in libjli if it is not defined in the build system, which is incorrect Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9669 From jvernee at openjdk.org Thu Jul 28 14:55:58 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Thu, 28 Jul 2022 14:55:58 GMT Subject: Integrated: 8290059: Do not use std::thread in panama tests In-Reply-To: References: Message-ID: On Thu, 21 Jul 2022 18:48:14 GMT, Jorn Vernee wrote: > This patch removes the use of std::thread from the `java.lang.foreign` tests, and switches to the OS specific thread APIs, in order to change things such as the stack size on some platforms where this is required in the future (see the JBS issue). > > This is done by adding a small header-only library that exposes a function to run code in freshly spawned threads (`run_async`). > > Testing: Running the affected tests on platforms that implement the linker. This pull request has now been integrated. Changeset: 54a2c5a6 Author: Jorn Vernee URL: https://git.openjdk.org/jdk/commit/54a2c5a6d148fecbe87f861933e4ae9459bacf65 Stats: 179 lines in 7 files changed: 131 ins; 7 del; 41 mod 8290059: Do not use std::thread in panama tests Reviewed-by: mcimadamore, stuefe, erikj ------------- PR: https://git.openjdk.org/jdk/pull/9599 From ihse at openjdk.org Thu Jul 28 22:34:55 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 28 Jul 2022 22:34:55 GMT Subject: RFR: 8287828: Fix so that one can select jtreg test case by ID from make [v6] In-Reply-To: References: Message-ID: On Mon, 27 Jun 2022 14:27:36 GMT, Leo Korinth wrote: >> One can select a testcase by ID when running a jtreg test case directly from jtreg (using the testcase.java#testID syntax). However, this has not been possible to do when launching jtreg indirectly from make. >> >> This fix attempts to address this issue. I have not tested this thoroughly yet, I wanted to show the code to get feedback first. The idea is to *not* emulated destructive imperative assignments through the use of eval. I instead try to handle it in a functional style without reassigning variables. I have tried to make the change as small as possible. >> >> I am not used to change the build system, so I would appreciate thorough review. >> >> `IfAppend` and `IfPrepend` are general purpose functions. If similar functions exists elsewhere inside the code base or in make itself I should probably use those instead. If they do not exist, they might be useful elsewhere and maybe should be placed in a common make file instead of the RunTests.gmk file. > > Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: > > remove one unnessesary $(subst) Bot, give Peace, I mean Leo, a chance... ------------- PR: https://git.openjdk.org/jdk/pull/9028 From ihse at openjdk.org Thu Jul 28 22:36:51 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 28 Jul 2022 22:36:51 GMT Subject: Integrated: 8289755: Remove --enable-reproducible-build from jib profile In-Reply-To: References: Message-ID: On Tue, 5 Jul 2022 16:01:50 GMT, Magnus Ihse Bursie wrote: > Since [JDK-8288396](https://bugs.openjdk.org/browse/JDK-8288396), the flag ` --enable-reproducible-build` is deprecated, and does nothing but print a warning. It is still included in the jib profiles, which make they output a warning. This pull request has now been integrated. Changeset: eeac3da7 Author: Magnus Ihse Bursie URL: https://git.openjdk.org/jdk/commit/eeac3da79565064a2e2c2d5a325f45250a90681d Stats: 13 lines in 1 file changed: 0 ins; 12 del; 1 mod 8289755: Remove --enable-reproducible-build from jib profile Reviewed-by: wetmore, erikj ------------- PR: https://git.openjdk.org/jdk/pull/9379 From shade at openjdk.org Fri Jul 29 07:33:17 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 29 Jul 2022 07:33:17 GMT Subject: RFR: 8290466: Default to --with-source-date=current to avoid unmodified Hotspot recompilation In-Reply-To: References: Message-ID: On Tue, 26 Jul 2022 12:28:41 GMT, Aleksey Shipilev wrote: > See the bug for symptoms and rationale. > > In short, after [JDK-8288396](https://bugs.openjdk.org/browse/JDK-8288396) moved the timestamp to `CFLAGS_VM_VERSION` macro, which changes with every build, we get Hotspot recompilation every time, even when Hotspot is not modified. > > I believe current behavior is correct for `--with-source-date=updated` (current default): you do Hotspot build, you get updated build timestamp, which forces recompilation of affected compilation units, relinkage, re-creation of jmods/jimage. The way out is to switch to `--with-source-date=current`, which would only get the build timestamp at configure time. > > CIs and build farms are likely reconfiguring before every build anyway, so their behavior is unlikely to be affected. But this switch definitely improves the day-to-day OpenJDK development work: it saves >50 seconds on every `make` for my machine, see below. > > Back-to-back unmodified build before: > > > $ CONF=linux-x86_64-server-release time make hotspot > Building target 'hotspot' in configuration 'linux-x86_64-server-release' > Finished building target 'hotspot' in configuration 'linux-x86_64-server-release' > > 39.03user 10.97system 0:56.89elapsed 87%CPU (0avgtext+0avgdata 2048944maxresident)k > 363616inputs+4108072outputs (484major+1100154minor)pagefaults 0swaps > > $ CONF=linux-x86_64-server-release time make hotspot > Building target 'hotspot' in configuration 'linux-x86_64-server-release' > Finished building target 'hotspot' in configuration 'linux-x86_64-server-release' > > 38.18user 9.02system 0:49.18elapsed 95%CPU (0avgtext+0avgdata 2048788maxresident)k > 40inputs+4101112outputs (0major+1100077minor)pagefaults 0swaps > > > Back-to-back unmodified build after: > > > $ CONF=linux-x86_64-server-release time make hotspot > Building target 'hotspot' in configuration 'linux-x86_64-server-release' > Finished building target 'hotspot' in configuration 'linux-x86_64-server-release' > > 2.15user 0.22system 0:02.59elapsed 91%CPU (0avgtext+0avgdata 49480maxresident)k > 0inputs+176outputs (0major+55506minor)pagefaults 0swaps > > $ CONF=linux-x86_64-server-release time make hotspot > Building target 'hotspot' in configuration 'linux-x86_64-server-release' > Finished building target 'hotspot' in configuration 'linux-x86_64-server-release' > > 2.18user 0.14system 0:02.46elapsed 94%CPU (0avgtext+0avgdata 49332maxresident)k @magicus -- you are good with this, or? ------------- PR: https://git.openjdk.org/jdk/pull/9638 From ihse at openjdk.org Fri Jul 29 09:18:40 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 29 Jul 2022 09:18:40 GMT Subject: RFR: 8290466: Default to --with-source-date=current to avoid unmodified Hotspot recompilation In-Reply-To: References: Message-ID: On Tue, 26 Jul 2022 12:28:41 GMT, Aleksey Shipilev wrote: > See the bug for symptoms and rationale. > > In short, after [JDK-8288396](https://bugs.openjdk.org/browse/JDK-8288396) moved the timestamp to `CFLAGS_VM_VERSION` macro, which changes with every build, we get Hotspot recompilation every time, even when Hotspot is not modified. > > I believe current behavior is correct for `--with-source-date=updated` (current default): you do Hotspot build, you get updated build timestamp, which forces recompilation of affected compilation units, relinkage, re-creation of jmods/jimage. The way out is to switch to `--with-source-date=current`, which would only get the build timestamp at configure time. > > CIs and build farms are likely reconfiguring before every build anyway, so their behavior is unlikely to be affected. But this switch definitely improves the day-to-day OpenJDK development work: it saves >50 seconds on every `make` for my machine, see below. > > Back-to-back unmodified build before: > > > $ CONF=linux-x86_64-server-release time make hotspot > Building target 'hotspot' in configuration 'linux-x86_64-server-release' > Finished building target 'hotspot' in configuration 'linux-x86_64-server-release' > > 39.03user 10.97system 0:56.89elapsed 87%CPU (0avgtext+0avgdata 2048944maxresident)k > 363616inputs+4108072outputs (484major+1100154minor)pagefaults 0swaps > > $ CONF=linux-x86_64-server-release time make hotspot > Building target 'hotspot' in configuration 'linux-x86_64-server-release' > Finished building target 'hotspot' in configuration 'linux-x86_64-server-release' > > 38.18user 9.02system 0:49.18elapsed 95%CPU (0avgtext+0avgdata 2048788maxresident)k > 40inputs+4101112outputs (0major+1100077minor)pagefaults 0swaps > > > Back-to-back unmodified build after: > > > $ CONF=linux-x86_64-server-release time make hotspot > Building target 'hotspot' in configuration 'linux-x86_64-server-release' > Finished building target 'hotspot' in configuration 'linux-x86_64-server-release' > > 2.15user 0.22system 0:02.59elapsed 91%CPU (0avgtext+0avgdata 49480maxresident)k > 0inputs+176outputs (0major+55506minor)pagefaults 0swaps > > $ CONF=linux-x86_64-server-release time make hotspot > Building target 'hotspot' in configuration 'linux-x86_64-server-release' > Finished building target 'hotspot' in configuration 'linux-x86_64-server-release' > > 2.18user 0.14system 0:02.46elapsed 94%CPU (0avgtext+0avgdata 49332maxresident)k Marked as reviewed by ihse (Reviewer). Sorry for the slow response, I'm on vacation. ? This looks good to me. Just update the default value in the help text as well: [how to set SOURCE_DATE_EPOCH ('updated', 'current', 'version' a timestamp or an ISO-8601 date) @<:@current/value of SOURCE_DATE_EPOCH@:>@])], (github does not allow me to comment on it since it's too far away from any changed lines in the PR) ------------- PR: https://git.openjdk.org/jdk/pull/9638 From shade at openjdk.org Fri Jul 29 09:34:53 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 29 Jul 2022 09:34:53 GMT Subject: RFR: 8290466: Default to --with-source-date=current to avoid unmodified Hotspot recompilation [v2] In-Reply-To: References: Message-ID: > See the bug for symptoms and rationale. > > In short, after [JDK-8288396](https://bugs.openjdk.org/browse/JDK-8288396) moved the timestamp to `CFLAGS_VM_VERSION` macro, which changes with every build, we get Hotspot recompilation every time, even when Hotspot is not modified. > > I believe current behavior is correct for `--with-source-date=updated` (current default): you do Hotspot build, you get updated build timestamp, which forces recompilation of affected compilation units, relinkage, re-creation of jmods/jimage. The way out is to switch to `--with-source-date=current`, which would only get the build timestamp at configure time. > > CIs and build farms are likely reconfiguring before every build anyway, so their behavior is unlikely to be affected. But this switch definitely improves the day-to-day OpenJDK development work: it saves >50 seconds on every `make` for my machine, see below. > > Back-to-back unmodified build before: > > > $ CONF=linux-x86_64-server-release time make hotspot > Building target 'hotspot' in configuration 'linux-x86_64-server-release' > Finished building target 'hotspot' in configuration 'linux-x86_64-server-release' > > 39.03user 10.97system 0:56.89elapsed 87%CPU (0avgtext+0avgdata 2048944maxresident)k > 363616inputs+4108072outputs (484major+1100154minor)pagefaults 0swaps > > $ CONF=linux-x86_64-server-release time make hotspot > Building target 'hotspot' in configuration 'linux-x86_64-server-release' > Finished building target 'hotspot' in configuration 'linux-x86_64-server-release' > > 38.18user 9.02system 0:49.18elapsed 95%CPU (0avgtext+0avgdata 2048788maxresident)k > 40inputs+4101112outputs (0major+1100077minor)pagefaults 0swaps > > > Back-to-back unmodified build after: > > > $ CONF=linux-x86_64-server-release time make hotspot > Building target 'hotspot' in configuration 'linux-x86_64-server-release' > Finished building target 'hotspot' in configuration 'linux-x86_64-server-release' > > 2.15user 0.22system 0:02.59elapsed 91%CPU (0avgtext+0avgdata 49480maxresident)k > 0inputs+176outputs (0major+55506minor)pagefaults 0swaps > > $ CONF=linux-x86_64-server-release time make hotspot > Building target 'hotspot' in configuration 'linux-x86_64-server-release' > Finished building target 'hotspot' in configuration 'linux-x86_64-server-release' > > 2.18user 0.14system 0:02.46elapsed 94%CPU (0avgtext+0avgdata 49332maxresident)k Aleksey Shipilev 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: - Missed the spot - Merge branch 'master' into JDK-8290466-default-source-date-current - Fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9638/files - new: https://git.openjdk.org/jdk/pull/9638/files/0f0163f5..10ab14aa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9638&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9638&range=00-01 Stats: 8370 lines in 323 files changed: 4727 ins; 2878 del; 765 mod Patch: https://git.openjdk.org/jdk/pull/9638.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9638/head:pull/9638 PR: https://git.openjdk.org/jdk/pull/9638 From shade at openjdk.org Fri Jul 29 09:34:54 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 29 Jul 2022 09:34:54 GMT Subject: RFR: 8290466: Default to --with-source-date=current to avoid unmodified Hotspot recompilation In-Reply-To: References: Message-ID: On Fri, 29 Jul 2022 09:14:30 GMT, Magnus Ihse Bursie wrote: > Sorry for the slow response, I'm on vacation. Ah. I seen a few replies from you assumed you are back. > ``` > [how to set SOURCE_DATE_EPOCH ('updated', 'current', 'version' a timestamp or an ISO-8601 date) @<:@current/value of SOURCE_DATE_EPOCH@:>@])], > ``` Good spot, fixed in new commit. ------------- PR: https://git.openjdk.org/jdk/pull/9638 From hseigel at openjdk.org Fri Jul 29 18:12:38 2022 From: hseigel at openjdk.org (Harold Seigel) Date: Fri, 29 Jul 2022 18:12:38 GMT Subject: RFR: 8291360: Create entry points to expose low-level class file information Message-ID: Please review this change to fix JDK-8291360. This fix adds entry points getClassFileVersion() and getClassAccessFlagsRaw() to class java.lang.Class. The new entry points return the current class's class file version and its raw access flags. The fix was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 1-3 on Linux x64. Additionally, the JCK lang, vm, and api tests and new regression tests were run locally on Linux x64. Thanks, Harold ------------- Commit messages: - 8291360: Create entry points to expose low-level class file information Changes: https://git.openjdk.org/jdk/pull/9688/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9688&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8291360 Stats: 704 lines in 9 files changed: 703 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9688.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9688/head:pull/9688 PR: https://git.openjdk.org/jdk/pull/9688 From darcy at openjdk.org Fri Jul 29 18:15:15 2022 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 29 Jul 2022 18:15:15 GMT Subject: RFR: 8291360: Create entry points to expose low-level class file information In-Reply-To: References: Message-ID: On Fri, 29 Jul 2022 18:02:46 GMT, Harold Seigel wrote: > Please review this change to fix JDK-8291360. This fix adds entry points getClassFileVersion() and getClassAccessFlagsRaw() to class java.lang.Class. The new entry points return the current class's class file version and its raw access flags. > > The fix was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 1-3 on Linux x64. Additionally, the JCK lang, vm, and api tests and new regression tests were run locally on Linux x64. > > Thanks, Harold src/java.base/share/classes/java/lang/Class.java line 4700: > 4698: * returned. If the class is a primitive then ACC_ABSTRACT | ACC_FINAL | ACC_PUBLIC. > 4699: */ > 4700: private int getClassAccessFlagsRaw() { For a "raw" method, it might be better to return the flags on the array class object itself rather than loop down to the component type. ------------- PR: https://git.openjdk.org/jdk/pull/9688 From hseigel at openjdk.org Fri Jul 29 19:56:51 2022 From: hseigel at openjdk.org (Harold Seigel) Date: Fri, 29 Jul 2022 19:56:51 GMT Subject: RFR: 8291360: Create entry points to expose low-level class file information In-Reply-To: References: Message-ID: On Fri, 29 Jul 2022 18:12:22 GMT, Joe Darcy wrote: >> Please review this change to fix JDK-8291360. This fix adds entry points getClassFileVersion() and getClassAccessFlagsRaw() to class java.lang.Class. The new entry points return the current class's class file version and its raw access flags. >> >> The fix was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 1-3 on Linux x64. Additionally, the JCK lang, vm, and api tests and new regression tests were run locally on Linux x64. >> >> Thanks, Harold > > src/java.base/share/classes/java/lang/Class.java line 4700: > >> 4698: * returned. If the class is a primitive then ACC_ABSTRACT | ACC_FINAL | ACC_PUBLIC. >> 4699: */ >> 4700: private int getClassAccessFlagsRaw() { > > For a "raw" method, it might be better to return the flags on the array class object itself rather than loop down to the component type. There's no bytecode stream for arrays. It's created using anewarray with a dimension operand and a cp pointer to the component type. So there are no flags for the array object. ------------- PR: https://git.openjdk.org/jdk/pull/9688 From rriggs at openjdk.org Fri Jul 29 21:25:47 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 29 Jul 2022 21:25:47 GMT Subject: RFR: 8291360: Create entry points to expose low-level class file information In-Reply-To: References: Message-ID: On Fri, 29 Jul 2022 18:02:46 GMT, Harold Seigel wrote: > Please review this change to fix JDK-8291360. This fix adds entry points getClassFileVersion() and getClassAccessFlagsRaw() to class java.lang.Class. The new entry points return the current class's class file version and its raw access flags. > > The fix was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 1-3 on Linux x64. Additionally, the JCK lang, vm, and api tests and new regression tests were run locally on Linux x64. > > Thanks, Harold src/hotspot/share/prims/jvm.cpp line 4059: > 4057: return JVM_CLASSFILE_MAJOR_VERSION; > 4058: } > 4059: assert(!java_lang_Class::as_Klass(mirror)->is_array_klass(), "unexpected array class"); Can this throw IllegalArgumentException instead. Asserts only report problems when built with debug (Right?) test/hotspot/jtreg/runtime/ClassFile/ClassAccessFlagsRawTest.java line 59: > 57: // test primitive array. should return ACC_ABSTRACT | ACC_FINAL | ACC_PUBLIC. > 58: int flags = (int)m.invoke((new int[3]).getClass()); > 59: if (flags != 1041) { Can this be a hex constant, It's easier to understand the bits. Or assemble the flags from java.lang.reflect.Modifier.XXX static fields. test/hotspot/jtreg/runtime/ClassFile/classAccessFlagsRaw.jcod line 25: > 23: */ > 24: > 25: // Class with ACC_SUPER set Can these classes be defined more succinctly either in Java or .asm? ------------- PR: https://git.openjdk.org/jdk/pull/9688 From rriggs at openjdk.org Fri Jul 29 21:25:48 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 29 Jul 2022 21:25:48 GMT Subject: RFR: 8291360: Create entry points to expose low-level class file information In-Reply-To: References: Message-ID: On Fri, 29 Jul 2022 21:05:19 GMT, Roger Riggs wrote: >> Please review this change to fix JDK-8291360. This fix adds entry points getClassFileVersion() and getClassAccessFlagsRaw() to class java.lang.Class. The new entry points return the current class's class file version and its raw access flags. >> >> The fix was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 1-3 on Linux x64. Additionally, the JCK lang, vm, and api tests and new regression tests were run locally on Linux x64. >> >> Thanks, Harold > > src/hotspot/share/prims/jvm.cpp line 4059: > >> 4057: return JVM_CLASSFILE_MAJOR_VERSION; >> 4058: } >> 4059: assert(!java_lang_Class::as_Klass(mirror)->is_array_klass(), "unexpected array class"); > > Can this throw IllegalArgumentException instead. > Asserts only report problems when built with debug (Right?) Or, Can the VM do this traversal as/more efficiently than doing at the java level? ------------- PR: https://git.openjdk.org/jdk/pull/9688 From dholmes at openjdk.org Sat Jul 30 07:50:19 2022 From: dholmes at openjdk.org (David Holmes) Date: Sat, 30 Jul 2022 07:50:19 GMT Subject: RFR: 8291360: Create entry points to expose low-level class file information In-Reply-To: References: Message-ID: On Fri, 29 Jul 2022 21:19:27 GMT, Roger Riggs wrote: >> src/hotspot/share/prims/jvm.cpp line 4059: >> >>> 4057: return JVM_CLASSFILE_MAJOR_VERSION; >>> 4058: } >>> 4059: assert(!java_lang_Class::as_Klass(mirror)->is_array_klass(), "unexpected array class"); >> >> Can this throw IllegalArgumentException instead. >> Asserts only report problems when built with debug (Right?) > > Or, Can the VM do this traversal as/more efficiently than doing at the java level? It is usual for the Java code to do such checks and throw exceptions, so that the VM assumes it is correct and only asserts incase something has been missed on the Java side. ------------- PR: https://git.openjdk.org/jdk/pull/9688 From dholmes at openjdk.org Sat Jul 30 07:50:20 2022 From: dholmes at openjdk.org (David Holmes) Date: Sat, 30 Jul 2022 07:50:20 GMT Subject: RFR: 8291360: Create entry points to expose low-level class file information In-Reply-To: References: Message-ID: On Sat, 30 Jul 2022 07:44:11 GMT, David Holmes wrote: >> Or, Can the VM do this traversal as/more efficiently than doing at the java level? > > It is usual for the Java code to do such checks and throw exceptions, so that the VM assumes it is correct and only asserts incase something has been missed on the Java side. Though in this case the Java code has defined behaviour for array types so it is correct for the VM to assume this is not an array type and to assert if it is. ------------- PR: https://git.openjdk.org/jdk/pull/9688 From shade at openjdk.org Sun Jul 31 18:38:00 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Sun, 31 Jul 2022 18:38:00 GMT Subject: RFR: 8290466: Default to --with-source-date=current to avoid unmodified Hotspot recompilation [v2] In-Reply-To: References: Message-ID: On Fri, 29 Jul 2022 09:34:53 GMT, Aleksey Shipilev wrote: >> See the bug for symptoms and rationale. >> >> In short, after [JDK-8288396](https://bugs.openjdk.org/browse/JDK-8288396) moved the timestamp to `CFLAGS_VM_VERSION` macro, which changes with every build, we get Hotspot recompilation every time, even when Hotspot is not modified. >> >> I believe current behavior is correct for `--with-source-date=updated` (current default): you do Hotspot build, you get updated build timestamp, which forces recompilation of affected compilation units, relinkage, re-creation of jmods/jimage. The way out is to switch to `--with-source-date=current`, which would only get the build timestamp at configure time. >> >> CIs and build farms are likely reconfiguring before every build anyway, so their behavior is unlikely to be affected. But this switch definitely improves the day-to-day OpenJDK development work: it saves >50 seconds on every `make` for my machine, see below. >> >> Back-to-back unmodified build before: >> >> >> $ CONF=linux-x86_64-server-release time make hotspot >> Building target 'hotspot' in configuration 'linux-x86_64-server-release' >> Finished building target 'hotspot' in configuration 'linux-x86_64-server-release' >> >> 39.03user 10.97system 0:56.89elapsed 87%CPU (0avgtext+0avgdata 2048944maxresident)k >> 363616inputs+4108072outputs (484major+1100154minor)pagefaults 0swaps >> >> $ CONF=linux-x86_64-server-release time make hotspot >> Building target 'hotspot' in configuration 'linux-x86_64-server-release' >> Finished building target 'hotspot' in configuration 'linux-x86_64-server-release' >> >> 38.18user 9.02system 0:49.18elapsed 95%CPU (0avgtext+0avgdata 2048788maxresident)k >> 40inputs+4101112outputs (0major+1100077minor)pagefaults 0swaps >> >> >> Back-to-back unmodified build after: >> >> >> $ CONF=linux-x86_64-server-release time make hotspot >> Building target 'hotspot' in configuration 'linux-x86_64-server-release' >> Finished building target 'hotspot' in configuration 'linux-x86_64-server-release' >> >> 2.15user 0.22system 0:02.59elapsed 91%CPU (0avgtext+0avgdata 49480maxresident)k >> 0inputs+176outputs (0major+55506minor)pagefaults 0swaps >> >> $ CONF=linux-x86_64-server-release time make hotspot >> Building target 'hotspot' in configuration 'linux-x86_64-server-release' >> Finished building target 'hotspot' in configuration 'linux-x86_64-server-release' >> >> 2.18user 0.14system 0:02.46elapsed 94%CPU (0avgtext+0avgdata 49332maxresident)k > > Aleksey Shipilev 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: > > - Missed the spot > - Merge branch 'master' into JDK-8290466-default-source-date-current > - Fix Entering the week with faster builds. ------------- PR: https://git.openjdk.org/jdk/pull/9638 From shade at openjdk.org Sun Jul 31 18:56:38 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Sun, 31 Jul 2022 18:56:38 GMT Subject: Integrated: 8290466: Default to --with-source-date=current to avoid unmodified Hotspot recompilation In-Reply-To: References: Message-ID: On Tue, 26 Jul 2022 12:28:41 GMT, Aleksey Shipilev wrote: > See the bug for symptoms and rationale. > > In short, after [JDK-8288396](https://bugs.openjdk.org/browse/JDK-8288396) moved the timestamp to `CFLAGS_VM_VERSION` macro, which changes with every build, we get Hotspot recompilation every time, even when Hotspot is not modified. > > I believe current behavior is correct for `--with-source-date=updated` (current default): you do Hotspot build, you get updated build timestamp, which forces recompilation of affected compilation units, relinkage, re-creation of jmods/jimage. The way out is to switch to `--with-source-date=current`, which would only get the build timestamp at configure time. > > CIs and build farms are likely reconfiguring before every build anyway, so their behavior is unlikely to be affected. But this switch definitely improves the day-to-day OpenJDK development work: it saves >50 seconds on every `make` for my machine, see below. > > Back-to-back unmodified build before: > > > $ CONF=linux-x86_64-server-release time make hotspot > Building target 'hotspot' in configuration 'linux-x86_64-server-release' > Finished building target 'hotspot' in configuration 'linux-x86_64-server-release' > > 39.03user 10.97system 0:56.89elapsed 87%CPU (0avgtext+0avgdata 2048944maxresident)k > 363616inputs+4108072outputs (484major+1100154minor)pagefaults 0swaps > > $ CONF=linux-x86_64-server-release time make hotspot > Building target 'hotspot' in configuration 'linux-x86_64-server-release' > Finished building target 'hotspot' in configuration 'linux-x86_64-server-release' > > 38.18user 9.02system 0:49.18elapsed 95%CPU (0avgtext+0avgdata 2048788maxresident)k > 40inputs+4101112outputs (0major+1100077minor)pagefaults 0swaps > > > Back-to-back unmodified build after: > > > $ CONF=linux-x86_64-server-release time make hotspot > Building target 'hotspot' in configuration 'linux-x86_64-server-release' > Finished building target 'hotspot' in configuration 'linux-x86_64-server-release' > > 2.15user 0.22system 0:02.59elapsed 91%CPU (0avgtext+0avgdata 49480maxresident)k > 0inputs+176outputs (0major+55506minor)pagefaults 0swaps > > $ CONF=linux-x86_64-server-release time make hotspot > Building target 'hotspot' in configuration 'linux-x86_64-server-release' > Finished building target 'hotspot' in configuration 'linux-x86_64-server-release' > > 2.18user 0.14system 0:02.46elapsed 94%CPU (0avgtext+0avgdata 49332maxresident)k This pull request has now been integrated. Changeset: d9cb410e Author: Aleksey Shipilev URL: https://git.openjdk.org/jdk/commit/d9cb410efc07a60e426f2399e020dcaccaba7dfa Stats: 9 lines in 3 files changed: 0 ins; 0 del; 9 mod 8290466: Default to --with-source-date=current to avoid unmodified Hotspot recompilation Reviewed-by: erikj, ihse ------------- PR: https://git.openjdk.org/jdk/pull/9638 From dholmes at openjdk.org Sun Jul 31 22:25:37 2022 From: dholmes at openjdk.org (David Holmes) Date: Sun, 31 Jul 2022 22:25:37 GMT Subject: RFR: 8291360: Create entry points to expose low-level class file information In-Reply-To: References: Message-ID: On Fri, 29 Jul 2022 18:02:46 GMT, Harold Seigel wrote: > Please review this change to fix JDK-8291360. This fix adds entry points getClassFileVersion() and getClassAccessFlagsRaw() to class java.lang.Class. The new entry points return the current class's class file version and its raw access flags. > > The fix was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 1-3 on Linux x64. Additionally, the JCK lang, vm, and api tests and new regression tests were run locally on Linux x64. > > Thanks, Harold Hi Harold, Generally seems fine. A few nits and comments. Thanks. src/hotspot/share/include/jvm.h line 1163: > 1161: > 1162: /* > 1163: * Value types support. Value types? This is supporting the core reflection work isn't it? src/hotspot/share/prims/jvm.cpp line 4050: > 4048: /* > 4049: * Return the current class's class file version. The low order 16 bits of the > 4050: * the returned jint contains the class's major version. The high order 16 bits typo "the the" across the lines typo s/contains/contain/ src/hotspot/share/prims/jvm.cpp line 4051: > 4049: * Return the current class's class file version. The low order 16 bits of the > 4050: * the returned jint contains the class's major version. The high order 16 bits > 4051: * contains the class's minor version. typo s/contains/contain/ src/hotspot/share/prims/jvm.cpp line 4064: > 4062: assert(c->is_instance_klass(), "must be"); > 4063: InstanceKlass* ik = InstanceKlass::cast(c); > 4064: return (ik->minor_version() << 16) | ik->major_version(); I'm curious why the format is minor:major rather than major:minor ? src/java.base/share/classes/java/lang/Class.java line 4698: > 4696: * > 4697: * If the class is an array type then the access flags of the component type is > 4698: * returned. If the class is a primitive then ACC_ABSTRACT | ACC_FINAL | ACC_PUBLIC. The `ACC_ABSTRACT` seems odd - is that way of indicating this "class" can't be instantiated? Is there some spec document that explains this choice? test/hotspot/jtreg/runtime/ClassFile/ClassAccessFlagsRawTest.java line 60: > 58: int flags = (int)m.invoke((new int[3]).getClass()); > 59: if (flags != 1041) { > 60: throw new RuntimeException("expected 1041, got " + flags + " for primitive array"); Hex output would be clearer here too. test/hotspot/jtreg/runtime/ClassFile/ClassAccessFlagsRawTest.java line 66: > 64: flags = (int)m.invoke((new SUPERnotset[2]).getClass()); > 65: if (flags != 1) { > 66: throw new RuntimeException("expected 1, got " + flags + " for object array"); Again hex output would be clearer test/hotspot/jtreg/runtime/ClassFile/ClassFileVersionTest.java line 31: > 29: * @modules java.base/java.lang:open > 30: * @compile classFileVersions.jcod > 31: * @run main/othervm --enable-preview ClassFileVersionTest What preview feature is being used here? test/hotspot/jtreg/runtime/ClassFile/ClassFileVersionTest.java line 45: > 43: if (ver != expectedResult) { > 44: throw new RuntimeException( > 45: "expected " + expectedResult + ", got " + ver + " for class " + className); It would be clearer to show the expected and actual in minor:major format. That way if the test fails we can easily see which bit is wrong. test/hotspot/jtreg/runtime/ClassFile/ClassFileVersionTest.java line 55: > 53: > 54: testIt("Version64", 64); > 55: testIt("Version59", 59); Any particular reason to choose 59? Shouldn't there also be tests for non-zero minor versions? test/hotspot/jtreg/runtime/ClassFile/ClassFileVersionTest.java line 62: > 60: int ver = (int)m.invoke((new int[3]).getClass()); > 61: if (ver != 64) { > 62: throw new RuntimeException("expected 64, got " + ver + " for primitive array"); Again minor:major format. ------------- Changes requested by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/9688