From duke at openjdk.java.net Tue Apr 5 20:26:18 2022 From: duke at openjdk.java.net (Vamsi Parasa) Date: Tue, 5 Apr 2022 20:26:18 GMT Subject: RFR: 8282221: x86 intrinsics for divideUnsigned and remainderUnsigned methods in java.lang.Integer and java.lang.Long [v8] In-Reply-To: References: Message-ID: > Optimizes the divideUnsigned() and remainderUnsigned() methods in java.lang.Integer and java.lang.Long classes using x86 intrinsics. This change shows 3x improvement for Integer methods and upto 25% improvement for Long. This change also implements the DivMod optimization which fuses division and modulus operations if needed. The DivMod optimization shows 3x improvement for Integer and ~65% improvement for Long. Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision: add error msg for jtreg test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7572/files - new: https://git.openjdk.java.net/jdk/pull/7572/files/e97c6fbc..8047767c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7572&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7572&range=06-07 Stats: 41 lines in 2 files changed: 37 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/7572.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7572/head:pull/7572 PR: https://git.openjdk.java.net/jdk/pull/7572 From duke at openjdk.java.net Tue Apr 5 20:26:20 2022 From: duke at openjdk.java.net (Vamsi Parasa) Date: Tue, 5 Apr 2022 20:26:20 GMT Subject: RFR: 8282221: x86 intrinsics for divideUnsigned and remainderUnsigned methods in java.lang.Integer and java.lang.Long [v6] In-Reply-To: References: <95NvO8tp9Px6gaY9DiVuMV7AzibD9SaCQBcRVVeB8eU=.7618df09-83cd-45c9-83e6-8529a3bdc491@github.com> Message-ID: On Tue, 5 Apr 2022 17:06:44 GMT, Sandhya Viswanathan wrote: >> Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision: >> >> add bmi1 support check and jtreg tests > > src/hotspot/cpu/x86/c2_MacroAssembler_x86.hpp line 362: > >> 360: void vector_popcount_long(XMMRegister dst, XMMRegister src, XMMRegister xtmp1, >> 361: XMMRegister xtmp2, XMMRegister xtmp3, Register rtmp, >> 362: int vec_enc); > > This doesn't seem to be related to this patch. This is coming due to a merge with the latest upstream (jdk) > test/hotspot/jtreg/compiler/intrinsics/TestIntegerDivMod.java line 107: > >> 105: } >> 106: if (mismatch) { >> 107: throw new RuntimeException("Test failed"); > > It would be good to print dividend, divisor, operation, actual result and expected result here. Please see the updated error message in the recent commit. > test/hotspot/jtreg/compiler/intrinsics/TestLongDivMod.java line 104: > >> 102: } >> 103: if (mismatch) { >> 104: throw new RuntimeException("Test failed"); > > It would be good to print dividend, divisor, operation, actual result and expected result here. Please see the updated error message in the recent commit. ------------- PR: https://git.openjdk.java.net/jdk/pull/7572 From kvn at openjdk.java.net Tue Apr 5 20:30:47 2022 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Tue, 5 Apr 2022 20:30:47 GMT Subject: RFR: 8280872: Reorder code cache segments to improve code density [v10] In-Reply-To: References: Message-ID: On Tue, 5 Apr 2022 08:16:20 GMT, Boris Ulasevich wrote: >> Currently the codecache segment order is [non-nmethod, non-profiled, profiled]. With this change we move the non-nmethod segment between two code segments. Currently only the aarch64 backend is adapted to make use of these changes. >> >> In AARCH the offset limit for a branch instruction is 128MB. The bigger jumps are encoded with three instructions. Most of far branches are jumps into the non-nmethod blobs. With the non-nmethod segment in between code segments the jump distance from method to the stub becomes shorter. The result is a 4% reduction in generated code size for the CodeCache range from 128MB to 240MB. >> >> As a side effect, the performance of some tests is slightly improved: >> ``ArraysFill.testCharFill 10 thrpt 15 170235.720 -> 178477.212 ops/ms`` >> >> Testing: jdk/hotspot jtreg and microbenchmarks on AMD and AARCH > > Boris Ulasevich has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: > > - Merge branch 'openjdk:master' into codecache_segments_order > - addressing the build issue, fixing the test and polishing the IC stub size arithmetic > - Merge branch 'openjdk:master' into codecache_segments_order > - review findings: use instruction_size istead of raw constant, strengthen the assert, check alignment, move comments, segments order: profiled - non_method - non_profiled > - rename, adding test > - moving nops out of far_jump > - minor renaming > - review comments. remove far_call limit. undo trampoline-to-farcall. add trampoline_needs_far_jump func > - fix name: is_non_nmethod, adding target_needs_far_branch func > - change codecache segments order: nonprofiled-nonmethod-profiled > increase far jump threshold: sideof(codecache)=128M -> sizeof(nonprofiled+nonmethod)=128M Marked as reviewed by kvn (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7517 From kvn at openjdk.java.net Tue Apr 5 20:30:47 2022 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Tue, 5 Apr 2022 20:30:47 GMT Subject: RFR: 8280872: Reorder code cache segments to improve code density [v9] In-Reply-To: <3njAB-erwFRjbwDB-iZHKeM0Ow9eT3hq0WAb605-5C4=.ae74be6c-716c-4f1e-8c61-1d10c71af390@github.com> References: <8UR-gDKjw9txPWMU1E-beo_0nodNxiTjQhWsMoCxibo=.3cb132f3-2252-4c95-ab9d-ecbe596359a2@github.com> <3njAB-erwFRjbwDB-iZHKeM0Ow9eT3hq0WAb605-5C4=.ae74be6c-716c-4f1e-8c61-1d10c71af390@github.com> Message-ID: On Tue, 5 Apr 2022 06:22:09 GMT, Boris Ulasevich wrote: >> test/hotspot/jtreg/compiler/c2/aarch64/TestFarJump.java line 39: >> >>> 37: * @requires vm.flagless >>> 38: * @requires os.arch=="aarch64" >>> 39: * @requires vm.debug == false >> >> Why you disabled test with debug VM? > > In a debug build the functionality does not work as expected. On AARCH64 branch range is +/-128MB. This is reflected by branch_range constant in [assembler_aarch64.hpp](https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/aarch64/assembler_aarch64.hpp#L850). The issue is that for debug build the branch_range constant is intentionally modified to test trampolines, and my test fails because branches are encoded into three instructions starting at 2MB, not 128MB: > > // The maximum range of a branch is fixed for the AArch64 > // architecture. In debug mode we shrink it in order to test > // trampolines, but not so small that branches in the interpreter > // are out of range. > static const uint64_t branch_range = NOT_DEBUG(128 * M) DEBUG_ONLY(2 * M); Got it. ------------- PR: https://git.openjdk.java.net/jdk/pull/7517 From kvn at openjdk.java.net Tue Apr 5 22:36:11 2022 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Tue, 5 Apr 2022 22:36:11 GMT Subject: RFR: 8183390: Fix and re-enable post loop vectorization [v8] In-Reply-To: <6RhKJ874fBXiAuaLD6C7A39V5uaAojt_uOARv1LlZ3I=.76664d99-75de-4396-b9c8-eb70ac19ed05@github.com> References: <6RhKJ874fBXiAuaLD6C7A39V5uaAojt_uOARv1LlZ3I=.76664d99-75de-4396-b9c8-eb70ac19ed05@github.com> Message-ID: On Fri, 1 Apr 2022 07:14:46 GMT, Pengfei Li wrote: >> ### Background >> >> Post loop vectorization is a C2 compiler optimization in an experimental >> VM feature called PostLoopMultiversioning. It transforms the range-check >> eliminated post loop to a 1-iteration vectorized loop with vector mask. >> This optimization was contributed by Intel in 2016 to support x86 AVX512 >> masked vector instructions. However, it was disabled soon after an issue >> was found. Due to insufficient maintenance in these years, multiple bugs >> have been accumulated inside. But we (Arm) still think this is a useful >> framework for vector mask support in C2 auto-vectorized loops, for both >> x86 AVX512 and AArch64 SVE. Hence, we propose this to fix and re-enable >> post loop vectorization. >> >> ### Changes in this patch >> >> This patch reworks post loop vectorization. The most significant change >> is removing vector mask support in C2 x86 backend and re-implementing >> it in the mid-end. With this, we can re-enable post loop vectorization >> for platforms other than x86. >> >> Previous implementation hard-codes x86 k1 register as a reserved AVX512 >> opmask register and defines two routines (setvectmask/restorevectmask) >> to set and restore the value of k1. But after [JDK-8211251](https://bugs.openjdk.java.net/browse/JDK-8211251) which encodes >> AVX512 instructions as unmasked by default, generated vector masks are >> no longer used in AVX512 vector instructions. To fix incorrect codegen >> and add vector mask support for more platforms, we turn to add a vector >> mask input to C2 mid-end IRs. Specifically, we use a VectorMaskGenNode >> to generate a mask and replace all Load/Store nodes in the post loop >> into LoadVectorMasked/StoreVectorMasked nodes with that mask input. This >> IR form is exactly the same to those which are used in VectorAPI mask >> support. For now, we only add mask inputs for Load/Store nodes because >> we don't have reduction operations supported in post loop vectorization. >> After this change, the x86 k1 register is no longer reserved and can be >> allocated when PostLoopMultiversioning is enabled. >> >> Besides this change, we have fixed a compiler crash and five incorrect >> result issues with post loop vectorization. >> >> **I) C2 crashes with segmentation fault in strip-mined loops** >> >> Previous implementation was done before C2 loop strip-mining was merged >> into JDK master so it didn't take strip-mined loops into consideration. >> In C2's strip mined loops, post loop is not the sibling of the main loop >> in ideal loop tree. Instead, it's the sibling of the main loop's parent. >> This patch fixed a SIGSEGV issue caused by NULL pointer when locating >> post loop from strip-mined main loop. >> >> **II) Incorrect result issues with post loop vectorization** >> >> We have also fixed five incorrect vectorization issues. Some of them are >> hidden deep and can only be reproduced with corner cases. These issues >> have a common cause that it assumes the post loop can be vectorized if >> the vectorization in corresponding main loop is successful. But in many >> cases this assumption is wrong. Below are details. >> >> - **[Issue-1] Incorrect vectorization for partial vectorizable loops** >> >> This issue can be reproduced by below loop where only some operations in >> the loop body are vectorizable. >> >> for (int i = 0; i < 10000; i++) { >> res[i] = a[i] * b[i]; >> k = 3 * k + 1; >> } >> >> In the main loop, superword can work well if parts of the operations in >> loop body are not vectorizable since those parts can be unrolled only. >> But for post loops, we don't create vectors through combining scalar IRs >> generated from loop unrolling. Instead, we are doing scalars to vectors >> replacement for all operations in the loop body. Hence, all operations >> should be either vectorized together or not vectorized at all. To fix >> this kind of cases, we add an extra field "_slp_vector_pack_count" in >> CountedLoopNode to record the eventual count of vector packs in the main >> loop. This value is then passed to post loop and compared with post loop >> pack count. Vectorization will be bailed out in post loop if it creates >> more vector packs than in the main loop. >> >> - **[Issue-2] Incorrect result in loops with growing-down vectors** >> >> This issue appears with growing-down vectors, that is, vectors that grow >> to smaller memory address as the loop iterates. It can be reproduced by >> below counting-up loop with negative scale value in array index. >> >> for (int i = 0; i < 10000; i++) { >> a[MAX - i] = b[MAX - i]; >> } >> >> Cause of this issue is that for a growing-down vector, generated vector >> mask value has reversed vector-lane order so it masks incorrect vector >> lanes. Note that if negative scale value appears in counting-down loops, >> the vector will be growing up. With this rule, we fix the issue by only >> allowing positive array index scales in counting-up loops and negative >> array index scales in counting-down loops. This check is done with the >> help of SWPointer by comparing scale values in each memory access in the >> loop with loop stride value. >> >> - **[Issue-3] Incorrect result in manually unrolled loops** >> >> This issue can be reproduced by below manually unrolled loop. >> >> for (int i = 0; i < 10000; i += 2) { >> c[i] = a[i] + b[i]; >> c[i + 1] = a[i + 1] * b[i + 1]; >> } >> >> In this loop, operations in the 2nd statement duplicate those in the 1st >> statement with a small memory address offset. Vectorization in the main >> loop works well in this case because C2 does further unrolling and pack >> combination. But we cannot vectorize the post loop through replacement >> from scalars to vectors because it creates duplicated vector operations. >> To fix this, we restrict post loop vectorization to loops with stride >> values of 1 or -1. >> >> - **[Issue-4] Incorrect result in loops with mixed vector element sizes** >> >> This issue is found after we enable post loop vectorization for AArch64. >> It's reproducible by multiple array operations with different element >> sizes inside a loop. On x86, there is no issue because the values of x86 >> AVX512 opmasks only depend on which vector lanes are active. But AArch64 >> is different - the values of SVE predicates also depend on lane size of >> the vector. Hence, on AArch64 SVE, if a loop has mixed vector element >> sizes, we should use different vector masks. For now, we just support >> loops with only one vector element size, i.e., "int + float" vectors in >> a single loop is ok but "int + double" vectors in a single loop is not >> vectorizable. This fix also enables subword vectors support to make all >> primitive type array operations vectorizable. >> >> - **[Issue-5] Incorrect result in loops with potential data dependence** >> >> This issue can be reproduced by below corner case on AArch64 only. >> >> for (int i = 0; i < 10000; i++) { >> a[i] = x; >> a[i + OFFSET] = y; >> } >> >> In this case, two stores in the loop have data dependence if the OFFSET >> value is smaller than the vector length. So we cannot do vectorization >> through replacing scalars to vectors. But the main loop vectorization >> in this case is successful on AArch64 because AArch64 has partial vector >> load/store support. It splits vector fill with different values in lanes >> to several smaller-sized fills. In this patch, we add additional data >> dependence check for this kind of cases. The check is also done with the >> help of SWPointer class. In this check, we require that every two memory >> accesses (with at least one store) of the same element type (or subword >> size) in the loop has the same array index expression. >> >> ### Tests >> >> So far we have tested full jtreg on both x86 AVX512 and AArch64 SVE with >> experimental VM option "PostLoopMultiversioning" turned on. We found no >> issue in all tests. We notice that those existing cases are not enough >> because some of above issues are not spotted by them. We would like to >> add some new cases but we found existing vectorization tests are a bit >> cumbersome - golden results must be pre-calculated and hard-coded in the >> test code for correctness verification. Thus, in this patch, we propose >> a new vectorization testing framework. >> >> Our new framework brings a simpler way to add new cases. For a new test >> case, we only need to create a new method annotated with "@Test". The >> test runner will invoke each annotated method twice automatically. First >> time it runs in the interpreter and second time it's forced compiled by >> C2. Then the two return results are compared. So in this framework each >> test method should return a primitive value or an array of primitives. >> In this way, no extra verification code for vectorization correctness is >> required. This test runner is still jtreg-based and takes advantages of >> the jtreg WhiteBox API, which enables test methods running at specific >> compilation levels. Each test class inside is also jtreg-based. It just >> need to inherit from the test runner class and run with two additional >> options "-Xbootclasspath/a:." and "-XX:+WhiteBoxAPI". >> >> ### Summary & Future work >> >> In this patch, we reworked post loop vectorization. We made it platform >> independent and fixed several issues inside. We also implemented a new >> vectorization testing framework with many test cases inside. Meanwhile, >> we did some code cleanups. >> >> This patch only touches C2 code guarded with PostLoopMultiversioning, >> except a few data structure changes. So, there's no behavior change when >> experimental VM option PostLoopMultiversioning is off. Also, to reduce >> risks, we still propose to keep post loop vectorization experimental for >> now. But if it receives positive feedback, we would like to change it to >> non-experimental in the future. > > Pengfei Li has updated the pull request incrementally with one additional commit since the last revision: > > Fix test case and add a comment Testing passed. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6828 From sviswanathan at openjdk.java.net Tue Apr 5 23:16:46 2022 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Tue, 5 Apr 2022 23:16:46 GMT Subject: RFR: 8282221: x86 intrinsics for divideUnsigned and remainderUnsigned methods in java.lang.Integer and java.lang.Long [v8] In-Reply-To: References: Message-ID: On Tue, 5 Apr 2022 20:26:18 GMT, Vamsi Parasa wrote: >> Optimizes the divideUnsigned() and remainderUnsigned() methods in java.lang.Integer and java.lang.Long classes using x86 intrinsics. This change shows 3x improvement for Integer methods and upto 25% improvement for Long. This change also implements the DivMod optimization which fuses division and modulus operations if needed. The DivMod optimization shows 3x improvement for Integer and ~65% improvement for Long. > > Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision: > > add error msg for jtreg test Marked as reviewed by sviswanathan (Reviewer). Looks good to me. You need one more review. @vnkozlov Could you please help review this patch? ------------- PR: https://git.openjdk.java.net/jdk/pull/7572 From pli at openjdk.java.net Tue Apr 5 23:52:51 2022 From: pli at openjdk.java.net (Pengfei Li) Date: Tue, 5 Apr 2022 23:52:51 GMT Subject: RFR: 8183390: Fix and re-enable post loop vectorization [v8] In-Reply-To: References: <6RhKJ874fBXiAuaLD6C7A39V5uaAojt_uOARv1LlZ3I=.76664d99-75de-4396-b9c8-eb70ac19ed05@github.com> Message-ID: On Tue, 5 Apr 2022 22:33:19 GMT, Vladimir Kozlov wrote: > Testing passed. Thanks @vnkozlov . I will integrate this. ------------- PR: https://git.openjdk.java.net/jdk/pull/6828 From pli at openjdk.java.net Tue Apr 5 23:52:53 2022 From: pli at openjdk.java.net (Pengfei Li) Date: Tue, 5 Apr 2022 23:52:53 GMT Subject: Integrated: 8183390: Fix and re-enable post loop vectorization In-Reply-To: References: Message-ID: On Tue, 14 Dec 2021 08:48:25 GMT, Pengfei Li wrote: > ### Background > > Post loop vectorization is a C2 compiler optimization in an experimental > VM feature called PostLoopMultiversioning. It transforms the range-check > eliminated post loop to a 1-iteration vectorized loop with vector mask. > This optimization was contributed by Intel in 2016 to support x86 AVX512 > masked vector instructions. However, it was disabled soon after an issue > was found. Due to insufficient maintenance in these years, multiple bugs > have been accumulated inside. But we (Arm) still think this is a useful > framework for vector mask support in C2 auto-vectorized loops, for both > x86 AVX512 and AArch64 SVE. Hence, we propose this to fix and re-enable > post loop vectorization. > > ### Changes in this patch > > This patch reworks post loop vectorization. The most significant change > is removing vector mask support in C2 x86 backend and re-implementing > it in the mid-end. With this, we can re-enable post loop vectorization > for platforms other than x86. > > Previous implementation hard-codes x86 k1 register as a reserved AVX512 > opmask register and defines two routines (setvectmask/restorevectmask) > to set and restore the value of k1. But after [JDK-8211251](https://bugs.openjdk.java.net/browse/JDK-8211251) which encodes > AVX512 instructions as unmasked by default, generated vector masks are > no longer used in AVX512 vector instructions. To fix incorrect codegen > and add vector mask support for more platforms, we turn to add a vector > mask input to C2 mid-end IRs. Specifically, we use a VectorMaskGenNode > to generate a mask and replace all Load/Store nodes in the post loop > into LoadVectorMasked/StoreVectorMasked nodes with that mask input. This > IR form is exactly the same to those which are used in VectorAPI mask > support. For now, we only add mask inputs for Load/Store nodes because > we don't have reduction operations supported in post loop vectorization. > After this change, the x86 k1 register is no longer reserved and can be > allocated when PostLoopMultiversioning is enabled. > > Besides this change, we have fixed a compiler crash and five incorrect > result issues with post loop vectorization. > > **I) C2 crashes with segmentation fault in strip-mined loops** > > Previous implementation was done before C2 loop strip-mining was merged > into JDK master so it didn't take strip-mined loops into consideration. > In C2's strip mined loops, post loop is not the sibling of the main loop > in ideal loop tree. Instead, it's the sibling of the main loop's parent. > This patch fixed a SIGSEGV issue caused by NULL pointer when locating > post loop from strip-mined main loop. > > **II) Incorrect result issues with post loop vectorization** > > We have also fixed five incorrect vectorization issues. Some of them are > hidden deep and can only be reproduced with corner cases. These issues > have a common cause that it assumes the post loop can be vectorized if > the vectorization in corresponding main loop is successful. But in many > cases this assumption is wrong. Below are details. > > - **[Issue-1] Incorrect vectorization for partial vectorizable loops** > > This issue can be reproduced by below loop where only some operations in > the loop body are vectorizable. > > for (int i = 0; i < 10000; i++) { > res[i] = a[i] * b[i]; > k = 3 * k + 1; > } > > In the main loop, superword can work well if parts of the operations in > loop body are not vectorizable since those parts can be unrolled only. > But for post loops, we don't create vectors through combining scalar IRs > generated from loop unrolling. Instead, we are doing scalars to vectors > replacement for all operations in the loop body. Hence, all operations > should be either vectorized together or not vectorized at all. To fix > this kind of cases, we add an extra field "_slp_vector_pack_count" in > CountedLoopNode to record the eventual count of vector packs in the main > loop. This value is then passed to post loop and compared with post loop > pack count. Vectorization will be bailed out in post loop if it creates > more vector packs than in the main loop. > > - **[Issue-2] Incorrect result in loops with growing-down vectors** > > This issue appears with growing-down vectors, that is, vectors that grow > to smaller memory address as the loop iterates. It can be reproduced by > below counting-up loop with negative scale value in array index. > > for (int i = 0; i < 10000; i++) { > a[MAX - i] = b[MAX - i]; > } > > Cause of this issue is that for a growing-down vector, generated vector > mask value has reversed vector-lane order so it masks incorrect vector > lanes. Note that if negative scale value appears in counting-down loops, > the vector will be growing up. With this rule, we fix the issue by only > allowing positive array index scales in counting-up loops and negative > array index scales in counting-down loops. This check is done with the > help of SWPointer by comparing scale values in each memory access in the > loop with loop stride value. > > - **[Issue-3] Incorrect result in manually unrolled loops** > > This issue can be reproduced by below manually unrolled loop. > > for (int i = 0; i < 10000; i += 2) { > c[i] = a[i] + b[i]; > c[i + 1] = a[i + 1] * b[i + 1]; > } > > In this loop, operations in the 2nd statement duplicate those in the 1st > statement with a small memory address offset. Vectorization in the main > loop works well in this case because C2 does further unrolling and pack > combination. But we cannot vectorize the post loop through replacement > from scalars to vectors because it creates duplicated vector operations. > To fix this, we restrict post loop vectorization to loops with stride > values of 1 or -1. > > - **[Issue-4] Incorrect result in loops with mixed vector element sizes** > > This issue is found after we enable post loop vectorization for AArch64. > It's reproducible by multiple array operations with different element > sizes inside a loop. On x86, there is no issue because the values of x86 > AVX512 opmasks only depend on which vector lanes are active. But AArch64 > is different - the values of SVE predicates also depend on lane size of > the vector. Hence, on AArch64 SVE, if a loop has mixed vector element > sizes, we should use different vector masks. For now, we just support > loops with only one vector element size, i.e., "int + float" vectors in > a single loop is ok but "int + double" vectors in a single loop is not > vectorizable. This fix also enables subword vectors support to make all > primitive type array operations vectorizable. > > - **[Issue-5] Incorrect result in loops with potential data dependence** > > This issue can be reproduced by below corner case on AArch64 only. > > for (int i = 0; i < 10000; i++) { > a[i] = x; > a[i + OFFSET] = y; > } > > In this case, two stores in the loop have data dependence if the OFFSET > value is smaller than the vector length. So we cannot do vectorization > through replacing scalars to vectors. But the main loop vectorization > in this case is successful on AArch64 because AArch64 has partial vector > load/store support. It splits vector fill with different values in lanes > to several smaller-sized fills. In this patch, we add additional data > dependence check for this kind of cases. The check is also done with the > help of SWPointer class. In this check, we require that every two memory > accesses (with at least one store) of the same element type (or subword > size) in the loop has the same array index expression. > > ### Tests > > So far we have tested full jtreg on both x86 AVX512 and AArch64 SVE with > experimental VM option "PostLoopMultiversioning" turned on. We found no > issue in all tests. We notice that those existing cases are not enough > because some of above issues are not spotted by them. We would like to > add some new cases but we found existing vectorization tests are a bit > cumbersome - golden results must be pre-calculated and hard-coded in the > test code for correctness verification. Thus, in this patch, we propose > a new vectorization testing framework. > > Our new framework brings a simpler way to add new cases. For a new test > case, we only need to create a new method annotated with "@Test". The > test runner will invoke each annotated method twice automatically. First > time it runs in the interpreter and second time it's forced compiled by > C2. Then the two return results are compared. So in this framework each > test method should return a primitive value or an array of primitives. > In this way, no extra verification code for vectorization correctness is > required. This test runner is still jtreg-based and takes advantages of > the jtreg WhiteBox API, which enables test methods running at specific > compilation levels. Each test class inside is also jtreg-based. It just > need to inherit from the test runner class and run with two additional > options "-Xbootclasspath/a:." and "-XX:+WhiteBoxAPI". > > ### Summary & Future work > > In this patch, we reworked post loop vectorization. We made it platform > independent and fixed several issues inside. We also implemented a new > vectorization testing framework with many test cases inside. Meanwhile, > we did some code cleanups. > > This patch only touches C2 code guarded with PostLoopMultiversioning, > except a few data structure changes. So, there's no behavior change when > experimental VM option PostLoopMultiversioning is off. Also, to reduce > risks, we still propose to keep post loop vectorization experimental for > now. But if it receives positive feedback, we would like to change it to > non-experimental in the future. This pull request has now been integrated. Changeset: 741be461 Author: Pengfei Li URL: https://git.openjdk.java.net/jdk/commit/741be46138c4a02f1d9661b3acffb533f50ba9cf Stats: 4861 lines in 40 files changed: 4532 ins; 290 del; 39 mod 8183390: Fix and re-enable post loop vectorization Reviewed-by: roland, thartmann, kvn ------------- PR: https://git.openjdk.java.net/jdk/pull/6828 From kvn at openjdk.java.net Wed Apr 6 00:49:43 2022 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Wed, 6 Apr 2022 00:49:43 GMT Subject: RFR: 8282221: x86 intrinsics for divideUnsigned and remainderUnsigned methods in java.lang.Integer and java.lang.Long [v8] In-Reply-To: References: Message-ID: On Tue, 5 Apr 2022 20:26:18 GMT, Vamsi Parasa wrote: >> Optimizes the divideUnsigned() and remainderUnsigned() methods in java.lang.Integer and java.lang.Long classes using x86 intrinsics. This change shows 3x improvement for Integer methods and upto 25% improvement for Long. This change also implements the DivMod optimization which fuses division and modulus operations if needed. The DivMod optimization shows 3x improvement for Integer and ~65% improvement for Long. > > Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision: > > add error msg for jtreg test I have few comments. src/hotspot/cpu/x86/assembler_x86.cpp line 12375: > 12373: } > 12374: #endif > 12375: Please, place it near `idivq()` so you would not need `#ifdef`. src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4568: > 4566: subl(rdx, divisor); > 4567: if (VM_Version::supports_bmi1()) andnl(rax, rdx, rax); > 4568: else { Please, follow our coding stile here and in following methods: if (VM_Version::supports_bmi1()) { andnl(rax, rdx, rax); } else { src/hotspot/cpu/x86/x86_64.ad line 8701: > 8699: %} > 8700: > 8701: instruct udivI_rReg(rax_RegI rax, no_rax_rdx_RegI div, rFlagsReg cr, rdx_RegI rdx) I suggest to follow the pattern in other `div/mod` instructions: `(rax_RegI rax, rdx_RegI rdx, no_rax_rdx_RegI div, rFlagsReg cr)` Similar in following new instructions. test/hotspot/jtreg/compiler/intrinsics/TestIntegerDivMod.java line 55: > 53: dividends[i] = rng.nextInt(); > 54: divisors[i] = rng.nextInt(); > 55: } I don't trust RND to generate corner cases. Please, add cases here and in TestLongDivMod.java for MAX, MIN, 0. ------------- Changes requested by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7572 From kvn at openjdk.java.net Wed Apr 6 00:49:43 2022 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Wed, 6 Apr 2022 00:49:43 GMT Subject: RFR: 8282221: x86 intrinsics for divideUnsigned and remainderUnsigned methods in java.lang.Integer and java.lang.Long [v4] In-Reply-To: References: Message-ID: On Thu, 24 Feb 2022 19:04:37 GMT, Vamsi Parasa wrote: >> src/hotspot/share/opto/divnode.cpp line 881: >> >>> 879: return (phase->type( in(2) )->higher_equal(TypeLong::ONE)) ? in(1) : this; >>> 880: } >>> 881: //------------------------------Value------------------------------------------ >> >> Ideal transform to replace unsigned divide by cheaper logical right shift instruction if divisor is POW will be useful. > > Thanks for suggesting the enhancement. This enhancement will be implemented as a part of https://bugs.openjdk.java.net/browse/JDK-8282365 You do need `Ideal()` methods at least to check for dead code. ------------- PR: https://git.openjdk.java.net/jdk/pull/7572 From xgong at openjdk.java.net Wed Apr 6 02:18:36 2022 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Wed, 6 Apr 2022 02:18:36 GMT Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE with predicate feature In-Reply-To: References: Message-ID: <3gF6JzPEK-BJbxjV5c8Hj5jDN3uPWLu_a5cdvtRB7AI=.e2e66b9a-eda9-4046-883c-992275b097e4@github.com> On Wed, 30 Mar 2022 10:31:59 GMT, Xiaohong Gong wrote: > Currently the vector load with mask when the given index happens out of the array boundary is implemented with pure java scalar code to avoid the IOOBE (IndexOutOfBoundaryException). This is necessary for architectures that do not support the predicate feature. Because the masked load is implemented with a full vector load and a vector blend applied on it. And a full vector load will definitely cause the IOOBE which is not valid. However, for architectures that support the predicate feature like SVE/AVX-512/RVV, it can be vectorized with the predicated load instruction as long as the indexes of the masked lanes are within the bounds of the array. For these architectures, loading with unmasked lanes does not raise exception. > > This patch adds the vectorization support for the masked load with IOOBE part. Please see the original java implementation (FIXME: optimize): > > > @ForceInline > public static > ByteVector fromArray(VectorSpecies species, > byte[] a, int offset, > VectorMask m) { > ByteSpecies vsp = (ByteSpecies) species; > if (offset >= 0 && offset <= (a.length - species.length())) { > return vsp.dummyVector().fromArray0(a, offset, m); > } > > // FIXME: optimize > checkMaskFromIndexSize(offset, vsp, m, 1, a.length); > return vsp.vOp(m, i -> a[offset + i]); > } > > Since it can only be vectorized with the predicate load, the hotspot must check whether the current backend supports it and falls back to the java scalar version if not. This is different from the normal masked vector load that the compiler will generate a full vector load and a vector blend if the predicate load is not supported. So to let the compiler make the expected action, an additional flag (i.e. `usePred`) is added to the existing "loadMasked" intrinsic, with the value "true" for the IOOBE part while "false" for the normal load. And the compiler will fail to intrinsify if the flag is "true" and the predicate load is not supported by the backend, which means that normal java path will be executed. > > Also adds the same vectorization support for masked: > - fromByteArray/fromByteBuffer > - fromBooleanArray > - fromCharArray > > The performance for the new added benchmarks improve about `1.88x ~ 30.26x` on the x86 AVX-512 system: > > Benchmark before After Units > LoadMaskedIOOBEBenchmark.byteLoadArrayMaskIOOBE 737.542 1387.069 ops/ms > LoadMaskedIOOBEBenchmark.doubleLoadArrayMaskIOOBE 118.366 330.776 ops/ms > LoadMaskedIOOBEBenchmark.floatLoadArrayMaskIOOBE 233.832 6125.026 ops/ms > LoadMaskedIOOBEBenchmark.intLoadArrayMaskIOOBE 233.816 7075.923 ops/ms > LoadMaskedIOOBEBenchmark.longLoadArrayMaskIOOBE 119.771 330.587 ops/ms > LoadMaskedIOOBEBenchmark.shortLoadArrayMaskIOOBE 431.961 939.301 ops/ms > > Similar performance gain can also be observed on 512-bit SVE system. Hi @PaulSandoz @jatin-bhateja @sviswa7, could you please help to check this PR? Any feedback is welcome! Thanks a lot! ------------- PR: https://git.openjdk.java.net/jdk/pull/8035 From eliu at openjdk.java.net Wed Apr 6 03:38:27 2022 From: eliu at openjdk.java.net (Eric Liu) Date: Wed, 6 Apr 2022 03:38:27 GMT Subject: RFR: 8282528: AArch64: Incorrect replicate2L_zero rule [v2] In-Reply-To: References: Message-ID: > This patch fixes the wrong matching rule of replicate2L_zero. It was > matched "ReplicateI" by mistake so that long immediates(not only zero) > had to be moved to register first and matched to replicate2L finally. To > fix this trivial bug, this patch fixes the typo and extends the rule of > replicate2L_zero to replicate2L_imm, which now supports all possible > long immediate values. > > The final code changes are shown as below: > > replicate2L_imm: > > mov x13, #0xff > movk x13, #0xff, lsl #16 > movk x13, #0xff, lsl #32 > dup v16.2d, x13 > > => > > movi v16.2d, #0xff00ff00ff > > [Test] > test/jdk/jdk/incubator/vector, test/hotspot/jtreg/compiler/vectorapi > passed without failure. Eric Liu has updated the pull request incrementally with one additional commit since the last revision: fix comment Change-Id: Ic51820391d19b61e37847cc04375ecd79fc86779 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7939/files - new: https://git.openjdk.java.net/jdk/pull/7939/files/a5201990..aa66f34b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7939&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7939&range=00-01 Stats: 105 lines in 3 files changed: 49 ins; 41 del; 15 mod Patch: https://git.openjdk.java.net/jdk/pull/7939.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7939/head:pull/7939 PR: https://git.openjdk.java.net/jdk/pull/7939 From duke at openjdk.java.net Wed Apr 6 06:02:07 2022 From: duke at openjdk.java.net (Vamsi Parasa) Date: Wed, 6 Apr 2022 06:02:07 GMT Subject: RFR: 8282221: x86 intrinsics for divideUnsigned and remainderUnsigned methods in java.lang.Integer and java.lang.Long [v9] In-Reply-To: References: Message-ID: > Optimizes the divideUnsigned() and remainderUnsigned() methods in java.lang.Integer and java.lang.Long classes using x86 intrinsics. This change shows 3x improvement for Integer methods and upto 25% improvement for Long. This change also implements the DivMod optimization which fuses division and modulus operations if needed. The DivMod optimization shows 3x improvement for Integer and ~65% improvement for Long. Vamsi Parasa has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits: - Merge branch 'openjdk:master' into udivmod - add error msg for jtreg test - update jtreg test to run on x86_64 - add bmi1 support check and jtreg tests - Merge branch 'master' of https://git.openjdk.java.net/jdk into udivmod - fix 32bit build issues - Fix line at end of file - Move intrinsic code to macro assembly routines; remove unused transformations for div and mod nodes - fix trailing white space errors - fix whitespaces - ... and 3 more: https://git.openjdk.java.net/jdk/compare/741be461...acba7c19 ------------- Changes: https://git.openjdk.java.net/jdk/pull/7572/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7572&range=08 Stats: 1007 lines in 20 files changed: 1005 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7572.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7572/head:pull/7572 PR: https://git.openjdk.java.net/jdk/pull/7572 From jbhateja at openjdk.java.net Wed Apr 6 06:27:43 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Wed, 6 Apr 2022 06:27:43 GMT Subject: RFR: 8282221: x86 intrinsics for divideUnsigned and remainderUnsigned methods in java.lang.Integer and java.lang.Long [v9] In-Reply-To: References: Message-ID: <4VLY-BlfRmTaHHkrfFcRe1xAHtoAlzHIpziHGSq0Bes=.85eb4200-63eb-48c0-993c-4b4ddd1c9bf2@github.com> On Wed, 6 Apr 2022 06:02:07 GMT, Vamsi Parasa wrote: >> Optimizes the divideUnsigned() and remainderUnsigned() methods in java.lang.Integer and java.lang.Long classes using x86 intrinsics. This change shows 3x improvement for Integer methods and upto 25% improvement for Long. This change also implements the DivMod optimization which fuses division and modulus operations if needed. The DivMod optimization shows 3x improvement for Integer and ~65% improvement for Long. > > Vamsi Parasa has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits: > > - Merge branch 'openjdk:master' into udivmod > - add error msg for jtreg test > - update jtreg test to run on x86_64 > - add bmi1 support check and jtreg tests > - Merge branch 'master' of https://git.openjdk.java.net/jdk into udivmod > - fix 32bit build issues > - Fix line at end of file > - Move intrinsic code to macro assembly routines; remove unused transformations for div and mod nodes > - fix trailing white space errors > - fix whitespaces > - ... and 3 more: https://git.openjdk.java.net/jdk/compare/741be461...acba7c19 Marked as reviewed by jbhateja (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7572 From jbhateja at openjdk.java.net Wed Apr 6 06:27:43 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Wed, 6 Apr 2022 06:27:43 GMT Subject: RFR: 8282221: x86 intrinsics for divideUnsigned and remainderUnsigned methods in java.lang.Integer and java.lang.Long [v4] In-Reply-To: References: Message-ID: On Mon, 4 Apr 2022 07:24:12 GMT, Vamsi Parasa wrote: >> Also need a jtreg test for this. > >> Also need a jtreg test for this. > > Thanks Sandhya for the review. Made the suggested changes and added jtreg tests as well. Hi @vamsi-parasa , thanks for addressing my comments, looks good to me otherwise apart from the outstanding comments. ------------- PR: https://git.openjdk.java.net/jdk/pull/7572 From duke at openjdk.java.net Wed Apr 6 08:32:48 2022 From: duke at openjdk.java.net (KIRIYAMA Takuya) Date: Wed, 6 Apr 2022 08:32:48 GMT Subject: RFR: 8280761: UseCompressedOops should be set after limit_heap_by_allocatable_memory In-Reply-To: <7eCgGE2aRORssT3lsLD-y7Z5IVNnIhzOTDXOSPLvfwo=.c4804a79-2645-421b-aca6-4ef87c2cbb4d@github.com> References: <7eCgGE2aRORssT3lsLD-y7Z5IVNnIhzOTDXOSPLvfwo=.c4804a79-2645-421b-aca6-4ef87c2cbb4d@github.com> Message-ID: On Tue, 5 Apr 2022 10:07:33 GMT, Albert Mingkun Yang wrote: > I noticed that Github Action is not enabled for this PR. Please follow the instructions in https://wiki.openjdk.java.net/display/SKARA/Testing to enable Github Action. Also, I got build errors locally. I am very sorry. I enabled Github Action . I have successfully built on Windows and Linux locally. ------------- PR: https://git.openjdk.java.net/jdk/pull/7938 From ayang at openjdk.java.net Wed Apr 6 08:52:45 2022 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Wed, 6 Apr 2022 08:52:45 GMT Subject: RFR: 8280761: UseCompressedOops should be set after limit_heap_by_allocatable_memory In-Reply-To: References: <7eCgGE2aRORssT3lsLD-y7Z5IVNnIhzOTDXOSPLvfwo=.c4804a79-2645-421b-aca6-4ef87c2cbb4d@github.com> Message-ID: On Wed, 6 Apr 2022 08:29:27 GMT, KIRIYAMA Takuya wrote: > I enabled Github Action . Doesn't look like GA is properly running. It should say sth like "12 successful checks", as shown in #7341. > I have successfully built on Windows and Linux locally. OK, maybe this is a 32/64-bit thing. Having a working GA would have caught this. ------------- PR: https://git.openjdk.java.net/jdk/pull/7938 From bulasevich at openjdk.java.net Wed Apr 6 09:35:57 2022 From: bulasevich at openjdk.java.net (Boris Ulasevich) Date: Wed, 6 Apr 2022 09:35:57 GMT Subject: RFR: 8280872: Reorder code cache segments to improve code density [v9] In-Reply-To: References: <8UR-gDKjw9txPWMU1E-beo_0nodNxiTjQhWsMoCxibo=.3cb132f3-2252-4c95-ab9d-ecbe596359a2@github.com> <3njAB-erwFRjbwDB-iZHKeM0Ow9eT3hq0WAb605-5C4=.ae74be6c-716c-4f1e-8c61-1d10c71af390@github.com> Message-ID: On Tue, 5 Apr 2022 20:27:38 GMT, Vladimir Kozlov wrote: >> In a debug build the functionality does not work as expected. On AARCH64 branch range is +/-128MB. This is reflected by branch_range constant in [assembler_aarch64.hpp](https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/aarch64/assembler_aarch64.hpp#L850). The issue is that for debug build the branch_range constant is intentionally modified to test trampolines, and my test fails because branches are encoded into three instructions starting at 2MB, not 128MB: >> >> // The maximum range of a branch is fixed for the AArch64 >> // architecture. In debug mode we shrink it in order to test >> // trampolines, but not so small that branches in the interpreter >> // are out of range. >> static const uint64_t branch_range = NOT_DEBUG(128 * M) DEBUG_ONLY(2 * M); > > Got it. Thank you! ------------- PR: https://git.openjdk.java.net/jdk/pull/7517 From bulasevich at openjdk.java.net Wed Apr 6 09:35:59 2022 From: bulasevich at openjdk.java.net (Boris Ulasevich) Date: Wed, 6 Apr 2022 09:35:59 GMT Subject: Integrated: 8280872: Reorder code cache segments to improve code density In-Reply-To: References: Message-ID: On Thu, 17 Feb 2022 15:40:07 GMT, Boris Ulasevich wrote: > Currently the codecache segment order is [non-nmethod, non-profiled, profiled]. With this change we move the non-nmethod segment between two code segments. Currently only the aarch64 backend is adapted to make use of these changes. > > In AARCH the offset limit for a branch instruction is 128MB. The bigger jumps are encoded with three instructions. Most of far branches are jumps into the non-nmethod blobs. With the non-nmethod segment in between code segments the jump distance from method to the stub becomes shorter. The result is a 4% reduction in generated code size for the CodeCache range from 128MB to 240MB. > > As a side effect, the performance of some tests is slightly improved: > ``ArraysFill.testCharFill 10 thrpt 15 170235.720 -> 178477.212 ops/ms`` > > Testing: jdk/hotspot jtreg and microbenchmarks on AMD and AARCH This pull request has now been integrated. Changeset: e524107a Author: Boris Ulasevich URL: https://git.openjdk.java.net/jdk/commit/e524107a74d149354c505372e7b4a8af87d6ad02 Stats: 203 lines in 7 files changed: 185 ins; 1 del; 17 mod 8280872: Reorder code cache segments to improve code density Reviewed-by: simonis, kvn ------------- PR: https://git.openjdk.java.net/jdk/pull/7517 From tschatzl at openjdk.java.net Wed Apr 6 10:15:52 2022 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Wed, 6 Apr 2022 10:15:52 GMT Subject: Withdrawn: 8278492: Parameter -XX:MinRAMPercentage has no effect In-Reply-To: References: Message-ID: On Wed, 9 Mar 2022 10:07:50 GMT, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this change that makes the `MinRAMPercentage` flag actually affect minimum heap size? > > Testing: gha, test case > > Thanks, > Thomas This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/7755 From tschatzl at openjdk.java.net Wed Apr 6 11:21:40 2022 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Wed, 6 Apr 2022 11:21:40 GMT Subject: RFR: 8280761: UseCompressedOops should be set after limit_heap_by_allocatable_memory In-Reply-To: References: Message-ID: <1ApyX0wamZ4qZZ4URCQ8Q7O0KG6VCN1KiW12qndAWYg=.43640e25-ac84-4e5b-a4bf-9f3bb59f8b6c@github.com> On Thu, 24 Mar 2022 06:52:34 GMT, KIRIYAMA Takuya wrote: > I fixed to set UseCompressedOops flag after limit_heap_by_allocatable_memory(). > So when ulimit -v is called and -XX:MaxRAM is set, UseCompressedOops does not become false. > And all hotspot tier1 test are passed. > Would you please review this fix? The code will not compile on anything but 32 bit platforms. Here's a result on linux-x64: .../src/hotspot/share/runtime/arguments.cpp: In static member function 'static void Arguments::set_heap_size()': .../src/hotspot/share/runtime/arguments.cpp:1826:11: error: 'reasonable_max' was not declared in this scope 1826 | if (reasonable_max > max_coop_heap) { `reasonable_max` used within the `_LP64` block, and the change ends the scope it is declared in at line 1795. This also results in the entire block in the `_LP64` block to be misaligned. I believe (without checking), the closing brace at 1795 has been intended to stay in line 1842. Please fix. ------------- PR: https://git.openjdk.java.net/jdk/pull/7938 From duke at openjdk.java.net Wed Apr 6 17:30:40 2022 From: duke at openjdk.java.net (Vamsi Parasa) Date: Wed, 6 Apr 2022 17:30:40 GMT Subject: RFR: 8282221: x86 intrinsics for divideUnsigned and remainderUnsigned methods in java.lang.Integer and java.lang.Long [v8] In-Reply-To: References: Message-ID: On Wed, 6 Apr 2022 00:46:01 GMT, Vladimir Kozlov wrote: > I have few comments. Thank you Vladimir (@vnkozlov) for suggesting the changes! Will incorporate the suggestions and push an update in few hours. ------------- PR: https://git.openjdk.java.net/jdk/pull/7572 From duke at openjdk.java.net Wed Apr 6 22:40:06 2022 From: duke at openjdk.java.net (Srinivas Vamsi Parasa) Date: Wed, 6 Apr 2022 22:40:06 GMT Subject: RFR: 8282221: x86 intrinsics for divideUnsigned and remainderUnsigned methods in java.lang.Integer and java.lang.Long [v10] In-Reply-To: References: Message-ID: > Optimizes the divideUnsigned() and remainderUnsigned() methods in java.lang.Integer and java.lang.Long classes using x86 intrinsics. This change shows 3x improvement for Integer methods and upto 25% improvement for Long. This change also implements the DivMod optimization which fuses division and modulus operations if needed. The DivMod optimization shows 3x improvement for Integer and ~65% improvement for Long. Srinivas Vamsi Parasa has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits: - use appropriate style changes - Merge branch 'master' of https://git.openjdk.java.net/jdk into udivmod - Merge branch 'openjdk:master' into udivmod - add error msg for jtreg test - update jtreg test to run on x86_64 - add bmi1 support check and jtreg tests - Merge branch 'master' of https://git.openjdk.java.net/jdk into udivmod - fix 32bit build issues - Fix line at end of file - Move intrinsic code to macro assembly routines; remove unused transformations for div and mod nodes - ... and 5 more: https://git.openjdk.java.net/jdk/compare/4451257b...9949047c ------------- Changes: https://git.openjdk.java.net/jdk/pull/7572/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7572&range=09 Stats: 1011 lines in 20 files changed: 1009 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7572.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7572/head:pull/7572 PR: https://git.openjdk.java.net/jdk/pull/7572 From thartmann at openjdk.java.net Thu Apr 7 05:41:48 2022 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Thu, 7 Apr 2022 05:41:48 GMT Subject: RFR: 8265768 [aarch64] Use glibc libm impl for dlog,dlog10,dexp iff 2.29 or greater on AArch64. In-Reply-To: References: Message-ID: On Fri, 1 Apr 2022 15:38:36 GMT, Andrew Haley wrote: >> Will this patch change `java.lang.Math`, `java.lang.StrictMath` or both? I've noticed differences in iterative machine learning algorithms using exp & log across different JVMs and architectures which we try to track in [Tribuo](https://github.com/oracle/tribuo) by recording the JVM & arch in our model provenance objects. If this patch is integrated will there be an easy way to get (e.g. from `System.getProperty`) what implementation of exp is in use by the current JVM? Otherwise I won't be able to notify users that the model may not reproduce if they rerun the same computation on different versions of Linux with the same JVM & architecture. > >> Will this patch change `java.lang.Math`, `java.lang.StrictMath` or both? I've noticed differences in iterative machine learning algorithms using exp & log across different JVMs and architectures which we try to track in [Tribuo](https://github.com/oracle/tribuo) by recording the JVM & arch in our model provenance objects. > > Exactly so, and that is why this patch was never integrated. This was only ever going to be about `java.lang.Math`, but we foundered on the rock of monotonicity. Here's the spec: > > "most methods with more than 0.5 ulp errors are required to be semi-monotonic: whenever the mathematical function is non-decreasing, so is the floating-point approximation, likewise, whenever the mathematical function is non-increasing, so is the floating-point approximation. Not all approximations that have 1 ulp accuracy will automatically meet the monotonicity requirements." > > We couldn't guarantee we'd meet the monotonicity requirements if we used glibc libm, so this patch was, with some regret, abandoned. @theRealAph Thanks for the summary. I closed the JBS issue as Won't Fix. ------------- PR: https://git.openjdk.java.net/jdk/pull/3510 From duke at openjdk.java.net Thu Apr 7 06:58:32 2022 From: duke at openjdk.java.net (KIRIYAMA Takuya) Date: Thu, 7 Apr 2022 06:58:32 GMT Subject: RFR: 8280761: UseCompressedOops should be set after limit_heap_by_allocatable_memory [v2] In-Reply-To: References: Message-ID: > I fixed to set UseCompressedOops flag after limit_heap_by_allocatable_memory(). > So when ulimit -v is called and -XX:MaxRAM is set, UseCompressedOops does not become false. > And all hotspot tier1 test are passed. > Would you please review this fix? KIRIYAMA Takuya has updated the pull request incrementally with one additional commit since the last revision: 8280761: UseCompressedOops should be set after limit_heap_by_allocatable_memory ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7938/files - new: https://git.openjdk.java.net/jdk/pull/7938/files/73c1c935..cf5a9352 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7938&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7938&range=00-01 Stats: 8 lines in 1 file changed: 4 ins; 4 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7938.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7938/head:pull/7938 PR: https://git.openjdk.java.net/jdk/pull/7938 From duke at openjdk.java.net Thu Apr 7 09:01:04 2022 From: duke at openjdk.java.net (Tobias Holenstein) Date: Thu, 7 Apr 2022 09:01:04 GMT Subject: RFR: JDK-8075816: AliasLevel is broken and should be deprecated Message-ID: Deprecated AliasLevel and edited help messages. Added flag to VMDeprecatedOptions test. Checked that tests are not affected. ------------- Commit messages: - JDK-8075816: AliasLevel is broken and should be deprecated Changes: https://git.openjdk.java.net/jdk/pull/8140/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8140&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8075816 Stats: 4 lines in 3 files changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8140.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8140/head:pull/8140 PR: https://git.openjdk.java.net/jdk/pull/8140 From thartmann at openjdk.java.net Thu Apr 7 09:01:08 2022 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Thu, 7 Apr 2022 09:01:08 GMT Subject: RFR: JDK-8075816: AliasLevel is broken and should be deprecated In-Reply-To: References: Message-ID: On Thu, 7 Apr 2022 08:29:07 GMT, Tobias Holenstein wrote: > Deprecated AliasLevel and edited help messages. > Added flag to VMDeprecatedOptions test. > > Checked that tests are not affected. Looks good to me. ------------- Marked as reviewed by thartmann (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8140 From lucy at openjdk.java.net Thu Apr 7 10:09:21 2022 From: lucy at openjdk.java.net (Lutz Schmidt) Date: Thu, 7 Apr 2022 10:09:21 GMT Subject: RFR: 8278757: [s390] Implement AES Counter Mode Intrinsic Message-ID: Please review (and approve, if possible) this pull request. This is a s390-only enhancement. It introduces the implementation of an AES-CTR intrinsic, making use of the specific s390 instruction for AES counter-mode encryption. Testing: SAP does no longer maintain a full build and test environment for s390. Testing is therefore limited to running some test suites (SPECjbb*, SPECjvm*) manually. But: identical code is contained in SAP's commercial product and thoroughly tested in that context. No issues were uncovered. @backwaterred Could you please conduct some "official" testing for this PR? Thank you all! ------------- Commit messages: - 8278757: [s390] Implement AES Counter Mode Intrinsic Changes: https://git.openjdk.java.net/jdk/pull/8142/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8142&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8278757 Stats: 689 lines in 5 files changed: 669 ins; 5 del; 15 mod Patch: https://git.openjdk.java.net/jdk/pull/8142.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8142/head:pull/8142 PR: https://git.openjdk.java.net/jdk/pull/8142 From stuefe at openjdk.java.net Thu Apr 7 13:38:07 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 7 Apr 2022 13:38:07 GMT Subject: RFR: 8283710: JVMTI: Use BitSet for object marking [v4] In-Reply-To: References: Message-ID: On Mon, 4 Apr 2022 17:51:28 GMT, Roman Kennke wrote: >> JVMTI heap walking marks objects in order to track which have been visited already. In order to do that, it uses bits in the object header. Those are the same bits that are also used by some GCs to mark objects (the lowest two bits, also used by locking code). Some GCs also use the bits in order to indicate 'forwarded' objects, where the upper bits of the header represent the forward-pointer. In the case of Shenandoah, it's even more problematic because this happens concurrently, even while JVMTI heap walks can intercept. So far we carefully worked around that problem, but it becomes very problematic in Lilliput, where accesses to the Klass* also requires to decode the header, and figure out what bits means what. >> >> In addition to that, marking objects in their header requires that the original header gets saved and restored. We only do that for 'interesting' headers, that is headers that have a stack-lock, monitor or hash-code. All other headers are reset to their default value. This means we are losing object's GC age. This is not catastrophic, but nontheless interferes with GC. >> >> JFR already has a datastructure called BitSet to support object marking without messing with object's headers. We can use that in JVMTI too. >> >> Testing: >> - [x] tier1 >> - [x] tier2 >> - [x] tier3 >> - [x] serviceability/jvmti >> - [x] vmTestbase/nsk/jvmti > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Templatize BitSet for MEMFLAGS Hi @coleenp and @rkennke, Since the JVMTI heap walk usually walks the whole heap, the bitmap may not be as sparse as we think. It would materialize a lot - possibly all - of its fragments. The increased memory consumption during JVMTI heap walk may mess with JVMTI agents using heapwalking for analysis in OOM situations. But I'm not against this. It is clearly more maintainable. A lot clearer. And if it helps lilliput, we save a lot more memory than we pay here. --- About this PR: You moved Bitset to general-purpose land. Now its a general purpose class, and should be more versatile and better documented. A comment would be good, at least for the structure itself. Proposal (feel free to modify/extend): BitSet is a sparse bitmap describing a memory range. It holds one bit per xxx-aligned address. Its underlying backing memory is allocated on-demand only, in yyy-sized fragments. Fragments are never deleted. The underlying memory is allocated from C-Heap. I would also rename the function, since it is very unclear what the difference is between BitMap and BitSet. E.g. "AddressMap" "SparseAddressMap", or similar. fragment size xxx and alignment yyy would ideally be configurable at compile time. At the moment, it feels very "heapish". It uses oop. It uses LogMinObjAlignmentInBytes. Ideally we would not include oop.hpp, and not know about oops. Especially the dependency on LogMinObjAlignmentInBytes is not optimal: that is a runtime variable depending on `-XX:ObjectAlignmentInBytes`. It would be good if that could be a compile time constant. Right now, IIUC, `BitSet::addr_to_bit()` will always load the alignment from memory. As a general purpose structure, some gtests would be nice. Maybe in some future RFE. --- A general thought, maybe for a future RFE: We now have BitMap and BitSet, which do almost the same thing. Instead of having a new class BitSet, whose job is to be sparse, we could give BitMap the ability to be sparse. We'd save code, reuse the rich BitMap interface and get all the test code for free. One way to do that would be to make BitMap responsible for committing its underlying backing memory, in chunks, on-demand only. To do that BitMap would need a secondary map - a commit map - to remember which fragments of its backing memory are committed. Commit map would have a bit per 64M fragment. As a sketch: class BitMap { // bitmap holding one bit per 64M fragment of the underlying bitmap backing memory BitMap _commit_map; inline void set_bit(idx_t bit) { // - find out which fragment the bit lives in // - if (commitmap[fragmentid] == 0) { commit_fragment(); commitmap[fragmentid]=1; } // - set bit } // same for clear_bit() bool at(idx_t index) const { // - find out which fragment the bit lives in // - if (commitmap[fragmentid] == 0) { return false; } // bit has never been set, is therefore zero // - else return the actual bit } } The sparse-handling part would have to be switchable at compile time so that we won't pay for it in non-sparse BitMap. I believe this solution could be simpler than a new separate utility class, and be more versatile. Would be interesting to know @kimbarrett 's opinion. But this can be done of course in a separate RFE. If at all. Cheers, Thomas src/hotspot/share/jfr/leakprofiler/chains/bfsClosure.hpp line 42: > 40: EdgeQueue* _edge_queue; > 41: EdgeStore* _edge_store; > 42: BitSet* _mark_bits; It feels weird to have an implementation detail like "under which NMT category is the bitmap allocated" in the interface of all functions now. I don't have a better idea for now, but how about we at least typedef this thing in JFR space somewhere? E.g. `typedef BitSet JFRBitSet` ? src/hotspot/share/prims/jvmtiTagMap.cpp line 1337: > 1335: // Stack allocated class to help ensure that ObjectMarker is used > 1336: // correctly. Constructor initializes ObjectMarker, destructor calls > 1337: // ObjectMarker's done() function to restore object headers. This comment is outdated, right? src/hotspot/share/prims/jvmtiTagMap.cpp line 1338: > 1336: // correctly. Constructor initializes ObjectMarker, destructor calls > 1337: // ObjectMarker's done() function to restore object headers. > 1338: class ObjectMarker : public StackObj { Maybe, for a future RFE: Ideally this would live as member in the VMOp, constructed and cleaned up by it. No stack obj nor global pointer needed then. We'd have to fix those few callers that have no access to the calling VMOp though. src/hotspot/share/utilities/bitset.hpp line 54: > 52: } > 53: }; > 54: We can loose the "protected" below since we never derive from this class src/hotspot/share/utilities/bitset.inline.hpp line 94: > 92: template > 93: inline BitMap::idx_t BitSet::addr_to_bit(uintptr_t addr) const { > 94: return (addr & _bitmap_granularity_mask) >> LogMinObjAlignmentInBytes; See my earlier comment. This is a runtime variable, would be nice to have this as compile time constant. ------------- PR: https://git.openjdk.java.net/jdk/pull/7964 From ayang at openjdk.java.net Thu Apr 7 14:10:42 2022 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Thu, 7 Apr 2022 14:10:42 GMT Subject: RFR: 8280761: UseCompressedOops should be set after limit_heap_by_allocatable_memory [v2] In-Reply-To: References: Message-ID: On Thu, 7 Apr 2022 06:58:32 GMT, KIRIYAMA Takuya wrote: >> I fixed to set UseCompressedOops flag after limit_heap_by_allocatable_memory(). >> So when ulimit -v is called and -XX:MaxRAM is set, UseCompressedOops does not become false. >> And all hotspot tier1 test are passed. >> Would you please review this fix? > > KIRIYAMA Takuya has updated the pull request incrementally with one additional commit since the last revision: > > 8280761: UseCompressedOops should be set after limit_heap_by_allocatable_memory The hotspot change looks good to me, but there's sth unclear to me in the test. test/hotspot/jtreg/gc/arguments/TestUseCompressedOopsFlagsWithUlimit.java line 62: > 60: > 61: String cmd = ProcessTools.getCommandLine(ProcessTools.createTestJvm(args.toArray(String[]::new))); > 62: ProcessBuilder pb = new ProcessBuilder("sh", "-c", "ulimit -v 10485760;" + cmd); The `ulimit -v` parameter should be passed in as well like `MaxRAM`. Then, from the calling context, one can see whether coop should be enabled or not. test/hotspot/jtreg/gc/arguments/TestUseCompressedOopsFlagsWithUlimit.java line 86: > 84: // 1. Verify that MaxRAMPercentage overrides UseCompressedOops Ergo > 85: // 2. Verify that UseCompressedOops forces compressed oops limit even > 86: // when other flags are specified. I don't understand why `MaxRAMPercentage` or `UseCompressedOops` are relevant to this fix/bug. ------------- Changes requested by ayang (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7938 From lucy at openjdk.java.net Thu Apr 7 14:24:57 2022 From: lucy at openjdk.java.net (Lutz Schmidt) Date: Thu, 7 Apr 2022 14:24:57 GMT Subject: RFR: 8278757: [s390] Implement AES Counter Mode Intrinsic In-Reply-To: References: Message-ID: On Thu, 7 Apr 2022 10:02:07 GMT, Lutz Schmidt wrote: > Please review (and approve, if possible) this pull request. > > This is a s390-only enhancement. It introduces the implementation of an AES-CTR intrinsic, making use of the specific s390 instruction for AES counter-mode encryption. > > Testing: SAP does no longer maintain a full build and test environment for s390. Testing is therefore limited to running some test suites (SPECjbb*, SPECjvm*) manually. But: identical code is contained in SAP's commercial product and thoroughly tested in that context. No issues were uncovered. > > @backwaterred Could you please conduct some "official" testing for this PR? > > Thank you all! Once again: With only s390 files in the changeset, there is no way for this PR to fail linux x86 tests. ------------- PR: https://git.openjdk.java.net/jdk/pull/8142 From rkennke at openjdk.java.net Thu Apr 7 15:15:44 2022 From: rkennke at openjdk.java.net (Roman Kennke) Date: Thu, 7 Apr 2022 15:15:44 GMT Subject: RFR: 8283710: JVMTI: Use BitSet for object marking [v4] In-Reply-To: References: Message-ID: <9LOZ_IbIoIHs0gVF_YI4cvIrlOUf_FvzykRZq2Dqmz8=.76583c5a-30be-45d7-b853-d7f771ed20fd@github.com> On Thu, 7 Apr 2022 13:31:31 GMT, Thomas Stuefe wrote: > Since the JVMTI heap walk usually walks the whole heap, the bitmap may not be as sparse as we think. It would materialize a lot - possibly all - of its fragments. The increased memory consumption during JVMTI heap walk may mess with JVMTI agents using heapwalking for analysis in OOM situations. The on-demand allocation of fragments should be a lot better than what I proposed before (in the Lilliput PR). The Java heap is typically never fully occupied, Java OOM situations aside. Heap walking may also start from a single object, in which case we would likely only walk a small subset of the heap. The current solution already allocates 2x4000x8 bytes by default for stashing locked and hashed headers. Also, only because Java runs out of memory on the heap doesn't mean that it's likely that we're also running out of native heap. The maximum memory usage should be around 1/64th of the Java heap size on default object alignment. > About this PR: > > You moved Bitset to general-purpose land. Now its a general purpose class, and should be more versatile and better documented. A comment would be good, at least for the structure itself. Proposal (feel free to modify/extend): > > ``` > BitSet is a sparse bitmap describing a memory range. It holds one bit per xxx-aligned > address. Its underlying backing memory is allocated on-demand only, in yyy-sized > fragments. Fragments are never deleted. The underlying memory is allocated from C-Heap. > ``` Yes, I will do that. > I would also rename the function, since it is very unclear what the difference is between BitMap and BitSet. E.g. "AddressMap" "SparseAddressMap", or similar. As you noted elsewhere, it is currently very heap/object-centric. We could name it ObjectBitSet or something like that for now. I would not want to implement the (reasonable) abstractions that you're proposing below, simply because it's not used as such, currently. Whenever we need such use, or have a desire to merge BitMap and ObjectBitSet, then we shall consider the abstractions, but now it seems a bit premature. > fragment size xxx and alignment yyy would ideally be configurable at compile time. At the moment, it feels very "heapish". It uses oop. It uses LogMinObjAlignmentInBytes. Ideally we would not include oop.hpp, and not know about oops. > Especially the dependency on LogMinObjAlignmentInBytes is not optimal: that is a runtime variable depending on `-XX:ObjectAlignmentInBytes`. It would be good if that could be a compile time constant. Right now, IIUC, `BitSet::addr_to_bit()` will always load the alignment from memory. Yes, but we *do* want to use it as object bitmap, and thus should know about ObjAlignmentInBytes, and this is determined at run-time only. > As a general purpose structure, some gtests would be nice. Maybe in some future RFE. Indeed. I will look into adding some. > A general thought, maybe for a future RFE: > > We now have BitMap and BitSet, which do almost the same thing. Instead of having a new class BitSet, whose job is to be sparse, we could give BitMap the ability to be sparse. We'd save code, reuse the rich BitMap interface and get all the test code for free. > > One way to do that would be to make BitMap responsible for committing its underlying backing memory, in chunks, on-demand only. To do that BitMap would need a secondary map - a commit map - to remember which fragments of its backing memory are committed. Commit map would have a bit per 64M fragment. > > As a sketch: > > ``` > class BitMap { > > // bitmap holding one bit per 64M fragment of the underlying bitmap backing memory > BitMap _commit_map; > > inline void set_bit(idx_t bit) { > // - find out which fragment the bit lives in > // - if (commitmap[fragmentid] == 0) { commit_fragment(); commitmap[fragmentid]=1; } > // - set bit > } > > // same for clear_bit() > > bool at(idx_t index) const { > // - find out which fragment the bit lives in > // - if (commitmap[fragmentid] == 0) { return false; } // bit has never been set, is therefore zero > // - else return the actual bit > } > > } > ``` > > The sparse-handling part would have to be switchable at compile time so that we won't pay for it in non-sparse BitMap. > > I believe this solution could be simpler than a new separate utility class, and be more versatile. Would be interesting to know @kimbarrett 's opinion. > > But this can be done of course in a separate RFE. If at all. Yes, let's do that as follow-up RFE. Thanks, Roman ------------- PR: https://git.openjdk.java.net/jdk/pull/7964 From stuefe at openjdk.java.net Thu Apr 7 16:40:44 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 7 Apr 2022 16:40:44 GMT Subject: RFR: 8283710: JVMTI: Use BitSet for object marking [v4] In-Reply-To: References: Message-ID: On Mon, 4 Apr 2022 17:51:28 GMT, Roman Kennke wrote: >> JVMTI heap walking marks objects in order to track which have been visited already. In order to do that, it uses bits in the object header. Those are the same bits that are also used by some GCs to mark objects (the lowest two bits, also used by locking code). Some GCs also use the bits in order to indicate 'forwarded' objects, where the upper bits of the header represent the forward-pointer. In the case of Shenandoah, it's even more problematic because this happens concurrently, even while JVMTI heap walks can intercept. So far we carefully worked around that problem, but it becomes very problematic in Lilliput, where accesses to the Klass* also requires to decode the header, and figure out what bits means what. >> >> In addition to that, marking objects in their header requires that the original header gets saved and restored. We only do that for 'interesting' headers, that is headers that have a stack-lock, monitor or hash-code. All other headers are reset to their default value. This means we are losing object's GC age. This is not catastrophic, but nontheless interferes with GC. >> >> JFR already has a datastructure called BitSet to support object marking without messing with object's headers. We can use that in JVMTI too. >> >> Testing: >> - [x] tier1 >> - [x] tier2 >> - [x] tier3 >> - [x] serviceability/jvmti >> - [x] vmTestbase/nsk/jvmti > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Templatize BitSet for MEMFLAGS If you add my proposed comment for bitset.hpp, or some variation of it, then the rest looks good to me in its current form. Thanks for considering my proposals! Thanks, Thomas ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7964 From rkennke at openjdk.java.net Thu Apr 7 17:20:41 2022 From: rkennke at openjdk.java.net (Roman Kennke) Date: Thu, 7 Apr 2022 17:20:41 GMT Subject: RFR: 8283710: JVMTI: Use BitSet for object marking [v5] In-Reply-To: References: Message-ID: <1CwiXwbDhtkDbV556jogJzJiIyn6TdMYG9SMN-Axk-o=.80e6543f-e78a-4ba8-9afb-400eea502fd2@github.com> > JVMTI heap walking marks objects in order to track which have been visited already. In order to do that, it uses bits in the object header. Those are the same bits that are also used by some GCs to mark objects (the lowest two bits, also used by locking code). Some GCs also use the bits in order to indicate 'forwarded' objects, where the upper bits of the header represent the forward-pointer. In the case of Shenandoah, it's even more problematic because this happens concurrently, even while JVMTI heap walks can intercept. So far we carefully worked around that problem, but it becomes very problematic in Lilliput, where accesses to the Klass* also requires to decode the header, and figure out what bits means what. > > In addition to that, marking objects in their header requires that the original header gets saved and restored. We only do that for 'interesting' headers, that is headers that have a stack-lock, monitor or hash-code. All other headers are reset to their default value. This means we are losing object's GC age. This is not catastrophic, but nontheless interferes with GC. > > JFR already has a datastructure called BitSet to support object marking without messing with object's headers. We can use that in JVMTI too. > > Testing: > - [x] tier1 > - [x] tier2 > - [x] tier3 > - [x] serviceability/jvmti > - [x] vmTestbase/nsk/jvmti Roman Kennke has updated the pull request incrementally with four additional commits since the last revision: - Add comment describing ObjectBitSet - Refactor JVMTI usage of ObjectBitSet - Typedef ObjectBitSet to JFRBitSet in JFR code - Rename BitSet to ObjectBitSet ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7964/files - new: https://git.openjdk.java.net/jdk/pull/7964/files/6d0f429d..e14f8d73 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7964&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7964&range=03-04 Stats: 603 lines in 10 files changed: 284 ins; 293 del; 26 mod Patch: https://git.openjdk.java.net/jdk/pull/7964.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7964/head:pull/7964 PR: https://git.openjdk.java.net/jdk/pull/7964 From rkennke at openjdk.java.net Thu Apr 7 17:22:16 2022 From: rkennke at openjdk.java.net (Roman Kennke) Date: Thu, 7 Apr 2022 17:22:16 GMT Subject: RFR: 8283710: JVMTI: Use BitSet for object marking [v4] In-Reply-To: References: Message-ID: On Thu, 7 Apr 2022 16:37:22 GMT, Thomas Stuefe wrote: > If you add my proposed comment for bitset.hpp, or some variation of it, then the rest looks good to me in its current form. Thanks for considering my proposals! > > Thanks, Thomas I did that, and some more of your suggestions, please have another look! I refactored the JVMTI usage. Instead of being global in ObjectMarker, the ObjectBitSet* is now in the VM_Op, except that I also needed to drag it into CallbackInvoker, where it is a static field again. This whole class can/should probably be refactored to not be AllStatic, but also local to the VM_Op, but that seems a task for a follow-up as well. Unfortunately, there is no good place to reset the CallbackInvoker, but that is also true for all other of its fields already. WDYT now? ------------- PR: https://git.openjdk.java.net/jdk/pull/7964 From stuefe at openjdk.java.net Thu Apr 7 17:51:44 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 7 Apr 2022 17:51:44 GMT Subject: RFR: 8283710: JVMTI: Use BitSet for object marking [v5] In-Reply-To: <1CwiXwbDhtkDbV556jogJzJiIyn6TdMYG9SMN-Axk-o=.80e6543f-e78a-4ba8-9afb-400eea502fd2@github.com> References: <1CwiXwbDhtkDbV556jogJzJiIyn6TdMYG9SMN-Axk-o=.80e6543f-e78a-4ba8-9afb-400eea502fd2@github.com> Message-ID: On Thu, 7 Apr 2022 17:20:41 GMT, Roman Kennke wrote: >> JVMTI heap walking marks objects in order to track which have been visited already. In order to do that, it uses bits in the object header. Those are the same bits that are also used by some GCs to mark objects (the lowest two bits, also used by locking code). Some GCs also use the bits in order to indicate 'forwarded' objects, where the upper bits of the header represent the forward-pointer. In the case of Shenandoah, it's even more problematic because this happens concurrently, even while JVMTI heap walks can intercept. So far we carefully worked around that problem, but it becomes very problematic in Lilliput, where accesses to the Klass* also requires to decode the header, and figure out what bits means what. >> >> In addition to that, marking objects in their header requires that the original header gets saved and restored. We only do that for 'interesting' headers, that is headers that have a stack-lock, monitor or hash-code. All other headers are reset to their default value. This means we are losing object's GC age. This is not catastrophic, but nontheless interferes with GC. >> >> JFR already has a datastructure called BitSet to support object marking without messing with object's headers. We can use that in JVMTI too. >> >> Testing: >> - [x] tier1 >> - [x] tier2 >> - [x] tier3 >> - [x] serviceability/jvmti >> - [x] vmTestbase/nsk/jvmti > > Roman Kennke has updated the pull request incrementally with four additional commits since the last revision: > > - Add comment describing ObjectBitSet > - Refactor JVMTI usage of ObjectBitSet > - Typedef ObjectBitSet to JFRBitSet in JFR code > - Rename BitSet to ObjectBitSet Looks better :) Placed in the VMOp this is less confusing. Also, less code. Small remarks inline, feel free to ignore them. We are entering nitpicking territory here. Cheers, Thomas src/hotspot/share/jfr/leakprofiler/chains/bfsClosure.hpp line 37: > 35: class ObjectBitSet; > 36: > 37: typedef ObjectBitSet JFRBitSet; Can you include memory/allocation.hpp for the MEMFLAGS? iterator.hpp already does, but better to be include-clean src/hotspot/share/prims/jvmtiTagMap.cpp line 2252: > 2250: GrowableArray* _visit_stack; // the visit stack > 2251: > 2252: JVMTIBitSet* _bitset; Small nit: You may consider making this a simple member, then you can get rid of the dynamic allocation and deallocation. Just feed the address of the member to CallbackInvoker. If you are worried about stack size, Bitset is not that big, 100ish bytes or so. Should still be fine to put the VMOp on the stack. ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7964 From stuefe at openjdk.java.net Thu Apr 7 17:51:44 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 7 Apr 2022 17:51:44 GMT Subject: RFR: 8283710: JVMTI: Use BitSet for object marking [v5] In-Reply-To: References: <1CwiXwbDhtkDbV556jogJzJiIyn6TdMYG9SMN-Axk-o=.80e6543f-e78a-4ba8-9afb-400eea502fd2@github.com> Message-ID: On Thu, 7 Apr 2022 17:22:12 GMT, Thomas Stuefe wrote: >> Roman Kennke has updated the pull request incrementally with four additional commits since the last revision: >> >> - Add comment describing ObjectBitSet >> - Refactor JVMTI usage of ObjectBitSet >> - Typedef ObjectBitSet to JFRBitSet in JFR code >> - Rename BitSet to ObjectBitSet > > src/hotspot/share/jfr/leakprofiler/chains/bfsClosure.hpp line 37: > >> 35: class ObjectBitSet; >> 36: >> 37: typedef ObjectBitSet JFRBitSet; > > Can you include memory/allocation.hpp for the MEMFLAGS? iterator.hpp already does, but better to be include-clean Optional: move this typedef to an own jfr/leakprofiler/utilities/jfrbitset.hpp and include that one instead of objectbitset.inline.hpp in the callee cpp files ------------- PR: https://git.openjdk.java.net/jdk/pull/7964 From stuefe at openjdk.java.net Thu Apr 7 18:02:57 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 7 Apr 2022 18:02:57 GMT Subject: RFR: 8283710: JVMTI: Use BitSet for object marking [v5] In-Reply-To: <1CwiXwbDhtkDbV556jogJzJiIyn6TdMYG9SMN-Axk-o=.80e6543f-e78a-4ba8-9afb-400eea502fd2@github.com> References: <1CwiXwbDhtkDbV556jogJzJiIyn6TdMYG9SMN-Axk-o=.80e6543f-e78a-4ba8-9afb-400eea502fd2@github.com> Message-ID: On Thu, 7 Apr 2022 17:20:41 GMT, Roman Kennke wrote: >> JVMTI heap walking marks objects in order to track which have been visited already. In order to do that, it uses bits in the object header. Those are the same bits that are also used by some GCs to mark objects (the lowest two bits, also used by locking code). Some GCs also use the bits in order to indicate 'forwarded' objects, where the upper bits of the header represent the forward-pointer. In the case of Shenandoah, it's even more problematic because this happens concurrently, even while JVMTI heap walks can intercept. So far we carefully worked around that problem, but it becomes very problematic in Lilliput, where accesses to the Klass* also requires to decode the header, and figure out what bits means what. >> >> In addition to that, marking objects in their header requires that the original header gets saved and restored. We only do that for 'interesting' headers, that is headers that have a stack-lock, monitor or hash-code. All other headers are reset to their default value. This means we are losing object's GC age. This is not catastrophic, but nontheless interferes with GC. >> >> JFR already has a datastructure called BitSet to support object marking without messing with object's headers. We can use that in JVMTI too. >> >> Testing: >> - [x] tier1 >> - [x] tier2 >> - [x] tier3 >> - [x] serviceability/jvmti >> - [x] vmTestbase/nsk/jvmti > > Roman Kennke has updated the pull request incrementally with four additional commits since the last revision: > > - Add comment describing ObjectBitSet > - Refactor JVMTI usage of ObjectBitSet > - Typedef ObjectBitSet to JFRBitSet in JFR code > - Rename BitSet to ObjectBitSet About https://github.com/openjdk/jdk/pull/8148, could you wait until that one is in? Would make it easier to backport Zhengyus change. ------------- PR: https://git.openjdk.java.net/jdk/pull/7964 From rkennke at openjdk.java.net Thu Apr 7 18:28:42 2022 From: rkennke at openjdk.java.net (Roman Kennke) Date: Thu, 7 Apr 2022 18:28:42 GMT Subject: RFR: 8283710: JVMTI: Use BitSet for object marking [v6] In-Reply-To: References: Message-ID: > JVMTI heap walking marks objects in order to track which have been visited already. In order to do that, it uses bits in the object header. Those are the same bits that are also used by some GCs to mark objects (the lowest two bits, also used by locking code). Some GCs also use the bits in order to indicate 'forwarded' objects, where the upper bits of the header represent the forward-pointer. In the case of Shenandoah, it's even more problematic because this happens concurrently, even while JVMTI heap walks can intercept. So far we carefully worked around that problem, but it becomes very problematic in Lilliput, where accesses to the Klass* also requires to decode the header, and figure out what bits means what. > > In addition to that, marking objects in their header requires that the original header gets saved and restored. We only do that for 'interesting' headers, that is headers that have a stack-lock, monitor or hash-code. All other headers are reset to their default value. This means we are losing object's GC age. This is not catastrophic, but nontheless interferes with GC. > > JFR already has a datastructure called BitSet to support object marking without messing with object's headers. We can use that in JVMTI too. > > Testing: > - [x] tier1 > - [x] tier2 > - [x] tier3 > - [x] serviceability/jvmti > - [x] vmTestbase/nsk/jvmti Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: Move JFRBitSet typedef into its own header; Make _bitset a direct member, not dynamically allocated ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7964/files - new: https://git.openjdk.java.net/jdk/pull/7964/files/e14f8d73..b525f2da Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7964&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7964&range=04-05 Stats: 58 lines in 7 files changed: 38 ins; 14 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/7964.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7964/head:pull/7964 PR: https://git.openjdk.java.net/jdk/pull/7964 From rkennke at openjdk.java.net Thu Apr 7 18:28:43 2022 From: rkennke at openjdk.java.net (Roman Kennke) Date: Thu, 7 Apr 2022 18:28:43 GMT Subject: RFR: 8283710: JVMTI: Use BitSet for object marking [v5] In-Reply-To: <1CwiXwbDhtkDbV556jogJzJiIyn6TdMYG9SMN-Axk-o=.80e6543f-e78a-4ba8-9afb-400eea502fd2@github.com> References: <1CwiXwbDhtkDbV556jogJzJiIyn6TdMYG9SMN-Axk-o=.80e6543f-e78a-4ba8-9afb-400eea502fd2@github.com> Message-ID: On Thu, 7 Apr 2022 17:20:41 GMT, Roman Kennke wrote: >> JVMTI heap walking marks objects in order to track which have been visited already. In order to do that, it uses bits in the object header. Those are the same bits that are also used by some GCs to mark objects (the lowest two bits, also used by locking code). Some GCs also use the bits in order to indicate 'forwarded' objects, where the upper bits of the header represent the forward-pointer. In the case of Shenandoah, it's even more problematic because this happens concurrently, even while JVMTI heap walks can intercept. So far we carefully worked around that problem, but it becomes very problematic in Lilliput, where accesses to the Klass* also requires to decode the header, and figure out what bits means what. >> >> In addition to that, marking objects in their header requires that the original header gets saved and restored. We only do that for 'interesting' headers, that is headers that have a stack-lock, monitor or hash-code. All other headers are reset to their default value. This means we are losing object's GC age. This is not catastrophic, but nontheless interferes with GC. >> >> JFR already has a datastructure called BitSet to support object marking without messing with object's headers. We can use that in JVMTI too. >> >> Testing: >> - [x] tier1 >> - [x] tier2 >> - [x] tier3 >> - [x] serviceability/jvmti >> - [x] vmTestbase/nsk/jvmti > > Roman Kennke has updated the pull request incrementally with four additional commits since the last revision: > > - Add comment describing ObjectBitSet > - Refactor JVMTI usage of ObjectBitSet > - Typedef ObjectBitSet to JFRBitSet in JFR code > - Rename BitSet to ObjectBitSet > About #8148, could you wait until that one is in? Would make it easier to backport Zhengyus change. Thanks for the heads-up! Yes I will wait. I also implemented your latest suggestions. While I wait for #8148, I will also add some gtests. Then it should be good to go. I also filed: https://bugs.openjdk.java.net/browse/JDK-8284543 ------------- PR: https://git.openjdk.java.net/jdk/pull/7964 From kvn at openjdk.java.net Thu Apr 7 18:39:42 2022 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Thu, 7 Apr 2022 18:39:42 GMT Subject: RFR: JDK-8075816: AliasLevel is broken and should be deprecated In-Reply-To: References: Message-ID: On Thu, 7 Apr 2022 08:29:07 GMT, Tobias Holenstein wrote: > Deprecated AliasLevel and edited help messages. > Added flag to VMDeprecatedOptions test. > > Checked that tests are not affected. I would like to have full description about the issue. The flags has values range [0-3]. Which values are broken? Which default value will be after flags removal and why? ------------- PR: https://git.openjdk.java.net/jdk/pull/8140 From duke at openjdk.java.net Thu Apr 7 21:27:33 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Thu, 7 Apr 2022 21:27:33 GMT Subject: RFR: 8278757: [s390] Implement AES Counter Mode Intrinsic In-Reply-To: References: Message-ID: On Thu, 7 Apr 2022 14:21:47 GMT, Lutz Schmidt wrote: >> Please review (and approve, if possible) this pull request. >> >> This is a s390-only enhancement. It introduces the implementation of an AES-CTR intrinsic, making use of the specific s390 instruction for AES counter-mode encryption. >> >> Testing: SAP does no longer maintain a full build and test environment for s390. Testing is therefore limited to running some test suites (SPECjbb*, SPECjvm*) manually. But: identical code is contained in SAP's commercial product and thoroughly tested in that context. No issues were uncovered. >> >> @backwaterred Could you please conduct some "official" testing for this PR? >> >> Thank you all! >> >> Note: some performance figures can be found in the JBS ticket. > > Once again: > With only s390 files in the changeset, there is no way for this PR to fail linux x86 tests. @RealLucy Tier1 tests in progress :slightly_smiling_face:. I will update this comment when they complete --- ------------- PR: https://git.openjdk.java.net/jdk/pull/8142 From duke at openjdk.java.net Fri Apr 8 00:59:36 2022 From: duke at openjdk.java.net (Srinivas Vamsi Parasa) Date: Fri, 8 Apr 2022 00:59:36 GMT Subject: RFR: 8282221: x86 intrinsics for divideUnsigned and remainderUnsigned methods in java.lang.Integer and java.lang.Long [v11] In-Reply-To: References: Message-ID: > Optimizes the divideUnsigned() and remainderUnsigned() methods in java.lang.Integer and java.lang.Long classes using x86 intrinsics. This change shows 3x improvement for Integer methods and upto 25% improvement for Long. This change also implements the DivMod optimization which fuses division and modulus operations if needed. The DivMod optimization shows 3x improvement for Integer and ~65% improvement for Long. Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision: Idead Ideal for udiv, umod nodes and update jtreg tests to use corner cases ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7572/files - new: https://git.openjdk.java.net/jdk/pull/7572/files/9949047c..bfb6c02e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7572&range=10 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7572&range=09-10 Stats: 701 lines in 7 files changed: 423 ins; 274 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/7572.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7572/head:pull/7572 PR: https://git.openjdk.java.net/jdk/pull/7572 From duke at openjdk.java.net Fri Apr 8 00:59:38 2022 From: duke at openjdk.java.net (Srinivas Vamsi Parasa) Date: Fri, 8 Apr 2022 00:59:38 GMT Subject: RFR: 8282221: x86 intrinsics for divideUnsigned and remainderUnsigned methods in java.lang.Integer and java.lang.Long [v8] In-Reply-To: References: Message-ID: On Wed, 6 Apr 2022 00:46:01 GMT, Vladimir Kozlov wrote: >> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision: >> >> add error msg for jtreg test > > I have few comments. Hi Vladimir (@vnkozlov), Incorporated all the suggestions you made in the previous review and pushed a new commit. Please let me know if anything else is needed. Thanks, Vamsi > src/hotspot/cpu/x86/assembler_x86.cpp line 12375: > >> 12373: } >> 12374: #endif >> 12375: > > Please, place it near `idivq()` so you would not need `#ifdef`. Made the change as per your suggestion. > src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4568: > >> 4566: subl(rdx, divisor); >> 4567: if (VM_Version::supports_bmi1()) andnl(rax, rdx, rax); >> 4568: else { > > Please, follow our coding stile here and in following methods: > > if (VM_Version::supports_bmi1()) { > andnl(rax, rdx, rax); > } else { Pls see the new commit which fixed the coding style. > src/hotspot/cpu/x86/x86_64.ad line 8701: > >> 8699: %} >> 8700: >> 8701: instruct udivI_rReg(rax_RegI rax, no_rax_rdx_RegI div, rFlagsReg cr, rdx_RegI rdx) > > I suggest to follow the pattern in other `div/mod` instructions: `(rax_RegI rax, rdx_RegI rdx, no_rax_rdx_RegI div, rFlagsReg cr)` > > Similar in following new instructions. Pls see the new commit which fixed the pattern. > test/hotspot/jtreg/compiler/intrinsics/TestIntegerDivMod.java line 55: > >> 53: dividends[i] = rng.nextInt(); >> 54: divisors[i] = rng.nextInt(); >> 55: } > > I don't trust RND to generate corner cases. > Please, add cases here and in TestLongDivMod.java for MAX, MIN, 0. You are right. Using an updated corner cases test revealed divide by zero crash which was fixed. Please see the updated jtreg tests inspired by unsigned divide/remainder tests in test/jdk/java/lang/Long/Unsigned.java and test/jdk/java/lang/Integer/Unsigned.java. ------------- PR: https://git.openjdk.java.net/jdk/pull/7572 From duke at openjdk.java.net Fri Apr 8 00:59:38 2022 From: duke at openjdk.java.net (Srinivas Vamsi Parasa) Date: Fri, 8 Apr 2022 00:59:38 GMT Subject: RFR: 8282221: x86 intrinsics for divideUnsigned and remainderUnsigned methods in java.lang.Integer and java.lang.Long [v4] In-Reply-To: References: Message-ID: On Wed, 6 Apr 2022 00:45:37 GMT, Vladimir Kozlov wrote: >> Thanks for suggesting the enhancement. This enhancement will be implemented as a part of https://bugs.openjdk.java.net/browse/JDK-8282365 > > You do need `Ideal()` methods at least to check for dead code. Added the Ideal() methods for checking dead code. Pls see the new commit. ------------- PR: https://git.openjdk.java.net/jdk/pull/7572 From duke at openjdk.java.net Fri Apr 8 01:05:33 2022 From: duke at openjdk.java.net (Srinivas Vamsi Parasa) Date: Fri, 8 Apr 2022 01:05:33 GMT Subject: RFR: 8282221: x86 intrinsics for divideUnsigned and remainderUnsigned methods in java.lang.Integer and java.lang.Long [v12] In-Reply-To: References: Message-ID: > Optimizes the divideUnsigned() and remainderUnsigned() methods in java.lang.Integer and java.lang.Long classes using x86 intrinsics. This change shows 3x improvement for Integer methods and upto 25% improvement for Long. This change also implements the DivMod optimization which fuses division and modulus operations if needed. The DivMod optimization shows 3x improvement for Integer and ~65% improvement for Long. Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision: uncomment zero in integer div, mod test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7572/files - new: https://git.openjdk.java.net/jdk/pull/7572/files/bfb6c02e..3e3fc977 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7572&range=11 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7572&range=10-11 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7572.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7572/head:pull/7572 PR: https://git.openjdk.java.net/jdk/pull/7572 From kvn at openjdk.java.net Fri Apr 8 01:50:02 2022 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 8 Apr 2022 01:50:02 GMT Subject: RFR: 8282221: x86 intrinsics for divideUnsigned and remainderUnsigned methods in java.lang.Integer and java.lang.Long [v12] In-Reply-To: References: Message-ID: On Fri, 8 Apr 2022 01:05:33 GMT, Srinivas Vamsi Parasa wrote: >> Optimizes the divideUnsigned() and remainderUnsigned() methods in java.lang.Integer and java.lang.Long classes using x86 intrinsics. This change shows 3x improvement for Integer methods and upto 25% improvement for Long. This change also implements the DivMod optimization which fuses division and modulus operations if needed. The DivMod optimization shows 3x improvement for Integer and ~65% improvement for Long. > > Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision: > > uncomment zero in integer div, mod test Good. I forgot before to ask about how you handle devision by 0 and now you added check for it. Let me run testing before approval. ------------- PR: https://git.openjdk.java.net/jdk/pull/7572 From duke at openjdk.java.net Fri Apr 8 02:02:43 2022 From: duke at openjdk.java.net (Quan Anh Mai) Date: Fri, 8 Apr 2022 02:02:43 GMT Subject: RFR: 8282221: x86 intrinsics for divideUnsigned and remainderUnsigned methods in java.lang.Integer and java.lang.Long [v12] In-Reply-To: References: Message-ID: On Fri, 8 Apr 2022 01:05:33 GMT, Srinivas Vamsi Parasa wrote: >> Optimizes the divideUnsigned() and remainderUnsigned() methods in java.lang.Integer and java.lang.Long classes using x86 intrinsics. This change shows 3x improvement for Integer methods and upto 25% improvement for Long. This change also implements the DivMod optimization which fuses division and modulus operations if needed. The DivMod optimization shows 3x improvement for Integer and ~65% improvement for Long. > > Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision: > > uncomment zero in integer div, mod test Personally, I think the optimisation for `div < 0` should be handled by the mid-end optimiser, which will not only give us the advantages of dead code elimination, but also global code motion. I would suggest the backend only doing `xorl rdx, rdx; divl $div$$Register` and the optimisation for `div < 0` will be implemented as a part of JDK-8282365. What do you think? Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/7572 From kbarrett at openjdk.java.net Fri Apr 8 02:05:41 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Fri, 8 Apr 2022 02:05:41 GMT Subject: RFR: 8283710: JVMTI: Use BitSet for object marking In-Reply-To: <4WleT5oWgzYka9hUYg1QiAld3OeC_hS41LJILk30fls=.92015a62-ac2f-4bb8-b550-45279f924c0b@github.com> References: <2V13Kr51baZQzWRorTT52LphO6pvNw3rugJrbC1mksA=.29cb7364-fe29-461d-864f-4c0c164502bd@github.com> <--W_f_6TlAnxqAKsvy0G8UlfJbDr32SEuqMZ_Uc5Hw0=.e0ad488c-ce07-4e5e-8c34-ee1ddc891749@github.com> <4WleT5oWgzYka9hUYg1QiAld3OeC_hS41LJILk30fls=.92015a62-ac2f-4bb8-b550-45279f924c0b@github.com> Message-ID: <1-bj5KJVcCxQUTmH22mBXWF9kdPBEQES3fYe6SzJZVg=.9101452c-db61-4486-b092-4003013f5199@github.com> On Mon, 4 Apr 2022 21:53:28 GMT, Roman Kennke wrote: > > One open question is which MEMFLAGS to use. mtTracing doesn't seem to be exactly right. Should I templatize BitSet and make JVMTI use mtServiceability and JRF use mtTracing as it did before? > > Yes, I think templatizing for MEMFLAGS makes sense (concurrentHashTable.hpp is too). I haven't had time to look at the code, but I don't know about this. Slapping a template parameter on everything isn't necessarily a good idea. We recently (JDK-8283368) undid exactly this sort of thing in the cardset code, instead making the MEMFLAGS value a runtime parameter provided at construction time. This avoids a bunch of generated code duplication, additional template syntax, and allows more implementation be put in .cpp files because it isn't a template. ------------- PR: https://git.openjdk.java.net/jdk/pull/7964 From kbarrett at openjdk.java.net Fri Apr 8 02:18:41 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Fri, 8 Apr 2022 02:18:41 GMT Subject: RFR: 8283710: JVMTI: Use BitSet for object marking [v6] In-Reply-To: References: Message-ID: On Thu, 7 Apr 2022 18:28:42 GMT, Roman Kennke wrote: >> JVMTI heap walking marks objects in order to track which have been visited already. In order to do that, it uses bits in the object header. Those are the same bits that are also used by some GCs to mark objects (the lowest two bits, also used by locking code). Some GCs also use the bits in order to indicate 'forwarded' objects, where the upper bits of the header represent the forward-pointer. In the case of Shenandoah, it's even more problematic because this happens concurrently, even while JVMTI heap walks can intercept. So far we carefully worked around that problem, but it becomes very problematic in Lilliput, where accesses to the Klass* also requires to decode the header, and figure out what bits means what. >> >> In addition to that, marking objects in their header requires that the original header gets saved and restored. We only do that for 'interesting' headers, that is headers that have a stack-lock, monitor or hash-code. All other headers are reset to their default value. This means we are losing object's GC age. This is not catastrophic, but nontheless interferes with GC. >> >> JFR already has a datastructure called BitSet to support object marking without messing with object's headers. We can use that in JVMTI too. >> >> Testing: >> - [x] tier1 >> - [x] tier2 >> - [x] tier3 >> - [x] serviceability/jvmti >> - [x] vmTestbase/nsk/jvmti > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Move JFRBitSet typedef into its own header; Make _bitset a direct member, not dynamically allocated > > > One open question is which MEMFLAGS to use. mtTracing doesn't seem to be exactly right. Should I templatize BitSet and make JVMTI use mtServiceability and JRF use mtTracing as it did before? > > > > > > Yes, I think templatizing for MEMFLAGS makes sense (concurrentHashTable.hpp is too). > > Slapping a template parameter on everything isn't necessarily a good idea. [...] There is a design principle that one should strive to only impose a template parameter on code that actually needs it. According to that principle, most of the bitset is completely independent of the MEMFLAGS value, and shouldn't be parameterized on it. There's a well-known paper about this: http://www.open-std.org/jtc1/sc22/WG21/docs/papers/2009/n2911.pdf (the so-called SCARY paper). I learned a lot from that paper. ------------- PR: https://git.openjdk.java.net/jdk/pull/7964 From eliu at openjdk.java.net Fri Apr 8 02:31:48 2022 From: eliu at openjdk.java.net (Eric Liu) Date: Fri, 8 Apr 2022 02:31:48 GMT Subject: RFR: 8282528: AArch64: Incorrect replicate2L_zero rule [v2] In-Reply-To: References: Message-ID: On Wed, 6 Apr 2022 03:38:27 GMT, Eric Liu wrote: >> This patch fixes the wrong matching rule of replicate2L_zero. It was >> matched "ReplicateI" by mistake so that long immediates(not only zero) >> had to be moved to register first and matched to replicate2L finally. To >> fix this trivial bug, this patch fixes the typo and extends the rule of >> replicate2L_zero to replicate2L_imm, which now supports all possible >> long immediate values. >> >> The final code changes are shown as below: >> >> replicate2L_imm: >> >> mov x13, #0xff >> movk x13, #0xff, lsl #16 >> movk x13, #0xff, lsl #32 >> dup v16.2d, x13 >> >> => >> >> movi v16.2d, #0xff00ff00ff >> >> [Test] >> test/jdk/jdk/incubator/vector, test/hotspot/jtreg/compiler/vectorapi >> passed without failure. > > Eric Liu has updated the pull request incrementally with one additional commit since the last revision: > > fix comment > > Change-Id: Ic51820391d19b61e37847cc04375ecd79fc86779 @theRealAph Could you help to take a look at this? The latest commit refines the code generator for macro mov, which now will generate DUP for those immediates can not be encoded in MOVI. E.g., for the case of IntVector.broadcast(0x12345678), the final code changes are shown as below: Before: movi v16.4s, #0x78 orr v16.4s, #0x56, lsl #8 orr v16.4s, #0x34, lsl #16 orr v16.4s, #0x12, lsl #24 After: mov w14, #0x5678 movk w14, #0x1234, lsl #16 dup v16.4s, w14 LLVM also uses DUP for those unencodable immediates which GCC loads from constant pool. ------------- PR: https://git.openjdk.java.net/jdk/pull/7939 From iklam at openjdk.java.net Fri Apr 8 03:16:16 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 8 Apr 2022 03:16:16 GMT Subject: RFR: 8284336: CDS SignedJar.java test fails due to archived Reference object Message-ID: During `java -Xshare:dump`, `ClassLoaders.bootLoader().resourceCache` is usually null. However, if a signed class is loaded, `resourceCache` will point to a `java.lang.ref.SoftReference`. Although rare (we have never seen this during our testing), it's possible for `resourceCache.discovered` to directly or indirectly point to another `Reference` which may contain an object that cannot be archived. The fix is simple: reset the `resourceCache` field of all three archived ClassLoader objects (boot/platform/app). I cannot reproduce the problem and I am unable to write a deterministic test case. However, the bug reporter has tested my preliminary patch and is no longer able to reproduce the failure. Please see the bug report [JDK-8284336](https://bugs.openjdk.java.net/browse/JDK-8284336) for detailed analysis and traces. ------------- Commit messages: - 8284336: CDS SignedJar.java test fails due to archived Reference object Changes: https://git.openjdk.java.net/jdk/pull/8151/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8151&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8284336 Stats: 28 lines in 5 files changed: 25 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/8151.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8151/head:pull/8151 PR: https://git.openjdk.java.net/jdk/pull/8151 From stuefe at openjdk.java.net Fri Apr 8 03:43:44 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 8 Apr 2022 03:43:44 GMT Subject: RFR: 8283710: JVMTI: Use BitSet for object marking In-Reply-To: <1-bj5KJVcCxQUTmH22mBXWF9kdPBEQES3fYe6SzJZVg=.9101452c-db61-4486-b092-4003013f5199@github.com> References: <2V13Kr51baZQzWRorTT52LphO6pvNw3rugJrbC1mksA=.29cb7364-fe29-461d-864f-4c0c164502bd@github.com> <--W_f_6TlAnxqAKsvy0G8UlfJbDr32SEuqMZ_Uc5Hw0=.e0ad488c-ce07-4e5e-8c34-ee1ddc891749@github.com> <4WleT5oWgzYka9hUYg1QiAld3OeC_hS41LJILk30fls=.92015a62-ac2f-4bb8-b550-45279f924c0b@github.com> <1-bj5KJVcCxQUTmH22mBXWF9kdPBEQES3fYe6SzJZVg=.9101452c-db61-4486-b092-4003013f5199@github.com> Message-ID: On Fri, 8 Apr 2022 02:01:50 GMT, Kim Barrett wrote: > > > One open question is which MEMFLAGS to use. mtTracing doesn't seem to be exactly right. Should I templatize BitSet and make JVMTI use mtServiceability and JRF use mtTracing as it did before? > > > > > > Yes, I think templatizing for MEMFLAGS makes sense (concurrentHashTable.hpp is too). > > I haven't had time to look at the code, but I don't know about this. Slapping a template parameter on everything isn't necessarily a good idea. We recently (JDK-8283368) undid exactly this sort of thing in the cardset code, instead making the MEMFLAGS value a runtime parameter provided at construction time. This avoids a bunch of generated code duplication, additional template syntax, and allows more implementation be put in .cpp files because it isn't a template. I never liked MEMFLAGS as template parameter. A runtime parameter would it make easier to use a general-purpose data structure on behalf of a subsystem and account its memory to that subsystem, while still being able to pass it around as a simple pointer to other utility functions. But here Roman squirreled the template definition away into a typedef, so I think we could cleanup MEMFLAG usage in a separate RFE? (we also should move MEMFLAGS to an own header file, btw, to avoid having to pull allocation.hpp every time) ------------- PR: https://git.openjdk.java.net/jdk/pull/7964 From stuefe at openjdk.java.net Fri Apr 8 04:20:39 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 8 Apr 2022 04:20:39 GMT Subject: RFR: 8283710: JVMTI: Use BitSet for object marking [v6] In-Reply-To: References: Message-ID: On Thu, 7 Apr 2022 18:28:42 GMT, Roman Kennke wrote: >> JVMTI heap walking marks objects in order to track which have been visited already. In order to do that, it uses bits in the object header. Those are the same bits that are also used by some GCs to mark objects (the lowest two bits, also used by locking code). Some GCs also use the bits in order to indicate 'forwarded' objects, where the upper bits of the header represent the forward-pointer. In the case of Shenandoah, it's even more problematic because this happens concurrently, even while JVMTI heap walks can intercept. So far we carefully worked around that problem, but it becomes very problematic in Lilliput, where accesses to the Klass* also requires to decode the header, and figure out what bits means what. >> >> In addition to that, marking objects in their header requires that the original header gets saved and restored. We only do that for 'interesting' headers, that is headers that have a stack-lock, monitor or hash-code. All other headers are reset to their default value. This means we are losing object's GC age. This is not catastrophic, but nontheless interferes with GC. >> >> JFR already has a datastructure called BitSet to support object marking without messing with object's headers. We can use that in JVMTI too. >> >> Testing: >> - [x] tier1 >> - [x] tier2 >> - [x] tier3 >> - [x] serviceability/jvmti >> - [x] vmTestbase/nsk/jvmti > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Move JFRBitSet typedef into its own header; Make _bitset a direct member, not dynamically allocated BTW, one neat solution to the MEMFLAGS problem would be to make it a property of the thread, and stackable. With sort of a MemflagMark. Each Thread could have a property "default MEMFLAGS", set with a MemFlagMark, and that gets used by default with every malloc in this thread. This way we may be able to get rid of a lot (most?) manual MEMFLAG declarations. ------------- PR: https://git.openjdk.java.net/jdk/pull/7964 From alanb at openjdk.java.net Fri Apr 8 07:11:42 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 8 Apr 2022 07:11:42 GMT Subject: RFR: 8284336: CDS SignedJar.java test fails due to archived Reference object In-Reply-To: References: Message-ID: On Thu, 7 Apr 2022 22:44:19 GMT, Ioi Lam wrote: > During `java -Xshare:dump`, `ClassLoaders.bootLoader().resourceCache` is usually null. However, if a signed class is loaded, `resourceCache` will point to a `java.lang.ref.SoftReference`. Although rare (we have never seen this during our testing), it's possible for `resourceCache.discovered` to directly or indirectly point to another `Reference` which may contain an object that cannot be archived. > > The fix is simple: reset the `resourceCache` field of all three archived ClassLoader objects (boot/platform/app). > > I cannot reproduce the problem and I am unable to write a deterministic test case. However, the bug reporter has tested my preliminary patch and is no longer able to reproduce the failure. > > Please see the bug report [JDK-8284336](https://bugs.openjdk.java.net/browse/JDK-8284336) for detailed analysis and traces. The updates to resetArchivedStates look okay. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8151 From duke at openjdk.java.net Fri Apr 8 07:39:39 2022 From: duke at openjdk.java.net (KIRIYAMA Takuya) Date: Fri, 8 Apr 2022 07:39:39 GMT Subject: RFR: 8280761: UseCompressedOops should be set after limit_heap_by_allocatable_memory [v2] In-Reply-To: References: Message-ID: <_fg657SevqM0I2DL7OalAKgthDSmqyncixT0vgswb7Q=.38a2366e-c9f1-4647-bbe0-dffc04746456@github.com> On Thu, 7 Apr 2022 14:05:57 GMT, Albert Mingkun Yang wrote: >> KIRIYAMA Takuya has updated the pull request incrementally with one additional commit since the last revision: >> >> 8280761: UseCompressedOops should be set after limit_heap_by_allocatable_memory > > test/hotspot/jtreg/gc/arguments/TestUseCompressedOopsFlagsWithUlimit.java line 62: > >> 60: >> 61: String cmd = ProcessTools.getCommandLine(ProcessTools.createTestJvm(args.toArray(String[]::new))); >> 62: ProcessBuilder pb = new ProcessBuilder("sh", "-c", "ulimit -v 10485760;" + cmd); > > The `ulimit -v` parameter should be passed in as well like `MaxRAM`. Then, from the calling context, one can see whether coop should be enabled or not. Thank you for your review. > I don't understand why `MaxRAMPercentage` or `UseCompressedOops` are relevant to this fix/bug. I forgot to remove this comment when I copied form TestMaxRAMFlags.java. I fixed this comment. > The `ulimit -v` parameter should be passed in as well like `MaxRAM`. Then, from the calling context, one can see whether coop should be enabled or not. This bug appears when ulimit -v is specified and MaxRAM is set bigger value. So I think it does not need that ulimit -v parameter let be variable. ------------- PR: https://git.openjdk.java.net/jdk/pull/7938 From duke at openjdk.java.net Fri Apr 8 07:39:38 2022 From: duke at openjdk.java.net (KIRIYAMA Takuya) Date: Fri, 8 Apr 2022 07:39:38 GMT Subject: RFR: 8280761: UseCompressedOops should be set after limit_heap_by_allocatable_memory [v3] In-Reply-To: References: Message-ID: > I fixed to set UseCompressedOops flag after limit_heap_by_allocatable_memory(). > So when ulimit -v is called and -XX:MaxRAM is set, UseCompressedOops does not become false. > And all hotspot tier1 test are passed. > Would you please review this fix? KIRIYAMA Takuya has updated the pull request incrementally with one additional commit since the last revision: 8280761 UseCompressedOops should be set after limit_heap_by_allocatable_memory ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7938/files - new: https://git.openjdk.java.net/jdk/pull/7938/files/cf5a9352..148d0fd6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7938&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7938&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7938.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7938/head:pull/7938 PR: https://git.openjdk.java.net/jdk/pull/7938 From stefank at openjdk.java.net Fri Apr 8 07:56:42 2022 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Fri, 8 Apr 2022 07:56:42 GMT Subject: Integrated: 8284297: Move FILE_AND_LINE to a platform independent header In-Reply-To: References: Message-ID: On Mon, 4 Apr 2022 12:40:21 GMT, Stefan Karlsson wrote: > The ppc and s390 ports have a macro called FILE_AND_LINE, which concatenates the filename and the line number. Loom uses the same macro in other ports. I propose that we upstream Loom's patch to move this macro to a platform independent header. This pull request has now been integrated. Changeset: a445ecd1 Author: Stefan Karlsson URL: https://git.openjdk.java.net/jdk/commit/a445ecd1e9e255e9cd977c727b3dba8f17acf5d9 Stats: 34 lines in 21 files changed: 23 ins; 10 del; 1 mod 8284297: Move FILE_AND_LINE to a platform independent header Reviewed-by: tschatzl ------------- PR: https://git.openjdk.java.net/jdk/pull/8092 From tschatzl at openjdk.java.net Fri Apr 8 08:20:58 2022 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Fri, 8 Apr 2022 08:20:58 GMT Subject: RFR: 8284435: Add dedicated filler objects for known dead Java heap areas Message-ID: Hi all, can I have reviews for this change that adds dedicated filler objects to the VM? Currently, when formatting areas of dead objects all gcs use instances of j.l.Object and int-arrays. This has the drawback of not being easily able to discern whether a given object is actually dead (and should never be referenced) or just a regular j.l.Object/int array. This also makes enhanced error detection (any reference to such an object is an error - i.e. detecting references to such objects) and to skip potentially already unloaded classes when scanning areas of the heap below TAMS, G1 uses its prev bitmap. Other collectors do not have this extra information at the moment, so they can't (and don't) do this kind of verification. With [JDK-8210708](https://bugs.openjdk.java.net/browse/JDK-8210708) the prev bitmap will effectively be removed in G1; G1 will format the dead areas with these filler objects to avoid coming across unloaded classes. This is fine wrt to normal operation, however, this looses the existing enhanced verification mentioned above. This change proposes to add dedicated VM-internal filler objects, i.e. equivalents of j.l.Object and int-arrays. This has the following benefits: - keep this error detection (actually making it much simpler) and allowing similar verification for other collectors. (This change does not add this) - this also makes it "easy" to detect references to filler objects in debugging tools - you only need to know the two klasses (or just get their friendly name) to see whether that reference may actually be valid (or refers to the inside such an object). References to these classes in the crash file may also allow the issue to be more clear. This causes some minor changes to external behavior: - logs/heap dumps now contain instances of these objects - which seems fine as previously they have just been reported as part of j.l.Object/int-arrays statistics. The VM spec also does not guarantee whether a particular kind of object should/should not show there anyway afaik. - if the application ever gets to instantiate a reference to such an object somehow, any enabled verification will crash the VM. That's bad luck for messing with internal classes, but that's the purpose of these objects. The change takes care that getting a reference will not be possible by normal means (i.e. via Class.forName() etc) - which should be sufficient to avoid the issue. Actually, existing mechanisms seem to be sufficient. Testing: tier1-8 There is one question I would like the reviewers to specially think about, the name of the filler array klass. I just used `Ljava/internal/vm/FillerArray;` for that, looking at other internal symbols/klasses, but I'm not sure this adheres to naming guidelines. Thanks go to @iklam for helping out with the change. Thanks, Thomas ------------- Commit messages: - First stab at new filler - sjohanss Changes: https://git.openjdk.java.net/jdk/pull/8156/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8156&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8284435 Stats: 33 lines in 7 files changed: 27 ins; 1 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/8156.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8156/head:pull/8156 PR: https://git.openjdk.java.net/jdk/pull/8156 From tschatzl at openjdk.java.net Fri Apr 8 08:51:33 2022 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Fri, 8 Apr 2022 08:51:33 GMT Subject: RFR: 8280761: UseCompressedOops should be set after limit_heap_by_allocatable_memory [v3] In-Reply-To: References: Message-ID: <2DdMP21sLmkOjljpF9BbaqtCEMhdlBjN11IYslz9m7A=.4a7c50f0-e3ef-421a-8332-08da22e9d0f6@github.com> On Fri, 8 Apr 2022 07:39:38 GMT, KIRIYAMA Takuya wrote: >> I fixed to set UseCompressedOops flag after limit_heap_by_allocatable_memory(). >> So when ulimit -v is called and -XX:MaxRAM is set, UseCompressedOops does not become false. >> And all hotspot tier1 test are passed. >> Would you please review this fix? > > KIRIYAMA Takuya has updated the pull request incrementally with one additional commit since the last revision: > > 8280761 UseCompressedOops should be set after limit_heap_by_allocatable_memory Looks okay. ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7938 From ayang at openjdk.java.net Fri Apr 8 08:51:34 2022 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Fri, 8 Apr 2022 08:51:34 GMT Subject: RFR: 8280761: UseCompressedOops should be set after limit_heap_by_allocatable_memory [v3] In-Reply-To: References: Message-ID: On Fri, 8 Apr 2022 07:39:38 GMT, KIRIYAMA Takuya wrote: >> I fixed to set UseCompressedOops flag after limit_heap_by_allocatable_memory(). >> So when ulimit -v is called and -XX:MaxRAM is set, UseCompressedOops does not become false. >> And all hotspot tier1 test are passed. >> Would you please review this fix? > > KIRIYAMA Takuya has updated the pull request incrementally with one additional commit since the last revision: > > 8280761 UseCompressedOops should be set after limit_heap_by_allocatable_memory In summary, the signature I have in mind is sth like `checkFlag(long ulimit_v, long max_ram, boolean expected_coop)`. test/hotspot/jtreg/gc/arguments/TestUseCompressedOopsFlagsWithUlimit.java line 86: > 84: // 1. Verify that UseCompressedOops Ergo follows ulimit -v setting. > 85: // 2. Verify that UseCompressedOops forces compressed oops limit even > 86: // when ulimit -v are specified. I understand the first bullet but not the second. Looking at the reproducers in the JBS ticket, `UseCompressedOops` should not be provided; it's read only. test/hotspot/jtreg/gc/arguments/TestUseCompressedOopsFlagsWithUlimit.java line 90: > 88: long oneG = 1L * 1024L * 1024L * 1024L; > 89: > 90: // Args: MaxRAM , MaxRAMPercentage, forcecoop, expect coop I am not sure why `MaxRAMPercentage` is needed here. ------------- PR: https://git.openjdk.java.net/jdk/pull/7938 From ayang at openjdk.java.net Fri Apr 8 08:51:35 2022 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Fri, 8 Apr 2022 08:51:35 GMT Subject: RFR: 8280761: UseCompressedOops should be set after limit_heap_by_allocatable_memory [v2] In-Reply-To: <_fg657SevqM0I2DL7OalAKgthDSmqyncixT0vgswb7Q=.38a2366e-c9f1-4647-bbe0-dffc04746456@github.com> References: <_fg657SevqM0I2DL7OalAKgthDSmqyncixT0vgswb7Q=.38a2366e-c9f1-4647-bbe0-dffc04746456@github.com> Message-ID: On Fri, 8 Apr 2022 07:35:17 GMT, KIRIYAMA Takuya wrote: >> test/hotspot/jtreg/gc/arguments/TestUseCompressedOopsFlagsWithUlimit.java line 62: >> >>> 60: >>> 61: String cmd = ProcessTools.getCommandLine(ProcessTools.createTestJvm(args.toArray(String[]::new))); >>> 62: ProcessBuilder pb = new ProcessBuilder("sh", "-c", "ulimit -v 10485760;" + cmd); >> >> The `ulimit -v` parameter should be passed in as well like `MaxRAM`. Then, from the calling context, one can see whether coop should be enabled or not. > > Thank you for your review. > >> I don't understand why `MaxRAMPercentage` or `UseCompressedOops` are relevant to this fix/bug. > > I forgot to remove this comment when I copied form TestMaxRAMFlags.java. > I fixed this comment. > >> The `ulimit -v` parameter should be passed in as well like `MaxRAM`. Then, from the calling context, one can see whether coop should be enabled or not. > > This bug appears when ulimit -v is specified and MaxRAM is set bigger value. So I think it does not need that > ulimit -v parameter let be variable. It's not about whether it's constant or variable. In this context, it's unclear why coop is enabled. // Args: MaxRAM , MaxRAMPercentage, forcecoop, expect coop checkFlag(32 * oneG, 100, false, true); `checkFlag` should not sneak in logic altering the coop value. ------------- PR: https://git.openjdk.java.net/jdk/pull/7938 From tschatzl at openjdk.java.net Fri Apr 8 09:10:43 2022 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Fri, 8 Apr 2022 09:10:43 GMT Subject: RFR: 8283710: JVMTI: Use BitSet for object marking [v4] In-Reply-To: <9LOZ_IbIoIHs0gVF_YI4cvIrlOUf_FvzykRZq2Dqmz8=.76583c5a-30be-45d7-b853-d7f771ed20fd@github.com> References: <9LOZ_IbIoIHs0gVF_YI4cvIrlOUf_FvzykRZq2Dqmz8=.76583c5a-30be-45d7-b853-d7f771ed20fd@github.com> Message-ID: On Thu, 7 Apr 2022 15:11:54 GMT, Roman Kennke wrote: > A general thought, maybe for a future RFE: > >We now have BitMap and BitSet, which do almost the same thing. Instead of having a new class BitSet, whose job is to be sparse, we could give BitMap the ability to be sparse. We'd save code, reuse the rich BitMap interface and get all the test code for free. > >One way to do that would be to make BitMap responsible for committing its underlying backing memory, in chunks, on-demand only. To do that BitMap would need a secondary map - a commit map - to remember which fragments of its backing memory are committed. Commit map would have a bit per 64M fragment. Please don't do this. `BitMap` (well, `BitMapView`) is also used as a lightweight way to overlay it on arbitrary memory temporarily (i.e. remembered sets bitmaps). This typically boils down to no additional memory usage (and overhead) at all. So any additional memory usage or initialization should not be added lightly. Also in most other cases, `BitMap` is used for very tiny bitmaps anyway, this would just add unnecessary functionality (and overhead) for 99% of the usage of `BitMap`. Further GCs are using `BitMap` to implement such sparse bit sets already, managing their memory with the corresponding Java heap memory; so adding this functionality at the `BitMap` level would just duplicate functionality with probably not-so-hilarious side effects. I also *do* think that the use cases for a dense `BitMap` are significantly different from (huge) sparse "BitMap"s to warrant its own separate class (not saying that one couldn't use the other internally, or that if that `BitSet` could be reused in GCs if configurable enough). I am also not sure that the automatic lazy backing of the OS isn't sufficient for these use cases (e.g. JVMTI) too. Thanks, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/7964 From aph at openjdk.java.net Fri Apr 8 09:12:41 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Fri, 8 Apr 2022 09:12:41 GMT Subject: RFR: 8282528: AArch64: Incorrect replicate2L_zero rule [v2] In-Reply-To: References: Message-ID: On Wed, 6 Apr 2022 03:38:27 GMT, Eric Liu wrote: >> This patch fixes the wrong matching rule of replicate2L_zero. It was >> matched "ReplicateI" by mistake so that long immediates(not only zero) >> had to be moved to register first and matched to replicate2L finally. To >> fix this trivial bug, this patch fixes the typo and extends the rule of >> replicate2L_zero to replicate2L_imm, which now supports all possible >> long immediate values. >> >> The final code changes are shown as below: >> >> replicate2L_imm: >> >> mov x13, #0xff >> movk x13, #0xff, lsl #16 >> movk x13, #0xff, lsl #32 >> dup v16.2d, x13 >> >> => >> >> movi v16.2d, #0xff00ff00ff >> >> [Test] >> test/jdk/jdk/incubator/vector, test/hotspot/jtreg/compiler/vectorapi >> passed without failure. > > Eric Liu has updated the pull request incrementally with one additional commit since the last revision: > > fix comment > > Change-Id: Ic51820391d19b61e37847cc04375ecd79fc86779 src/hotspot/cpu/aarch64/aarch64_neon_ad.m4 line 1571: > 1569: `$3 $4', `I _imm', ` '$con$$constant, > 1570: `$3 $4', `L _imm', ` '$con$$constant, > 1571: `$6', vRegF,` This `ifelse` is rather confusing. Can't the '& 0xff' be passed as arguments into `VREPLICATE`? ------------- PR: https://git.openjdk.java.net/jdk/pull/7939 From aph at openjdk.java.net Fri Apr 8 09:20:32 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Fri, 8 Apr 2022 09:20:32 GMT Subject: RFR: 8282528: AArch64: Incorrect replicate2L_zero rule [v2] In-Reply-To: References: Message-ID: On Wed, 6 Apr 2022 03:38:27 GMT, Eric Liu wrote: >> This patch fixes the wrong matching rule of replicate2L_zero. It was >> matched "ReplicateI" by mistake so that long immediates(not only zero) >> had to be moved to register first and matched to replicate2L finally. To >> fix this trivial bug, this patch fixes the typo and extends the rule of >> replicate2L_zero to replicate2L_imm, which now supports all possible >> long immediate values. >> >> The final code changes are shown as below: >> >> replicate2L_imm: >> >> mov x13, #0xff >> movk x13, #0xff, lsl #16 >> movk x13, #0xff, lsl #32 >> dup v16.2d, x13 >> >> => >> >> movi v16.2d, #0xff00ff00ff >> >> [Test] >> test/jdk/jdk/incubator/vector, test/hotspot/jtreg/compiler/vectorapi >> passed without failure. > > Eric Liu has updated the pull request incrementally with one additional commit since the last revision: > > fix comment > > Change-Id: Ic51820391d19b61e37847cc04375ecd79fc86779 It's tricky to reason about this. Sure, a micro-benchmark might suggest that `movz; movk` is better than a bunch of `movi` and `orri` with shifts, but on the other hand `dup(vec, general reg )` takes up slots in the base pipelines that might in non-benchmark code be used for something else. having said that, I don't think the difference is huge, so for now maybe we should just prefer smaller code sizes. ------------- PR: https://git.openjdk.java.net/jdk/pull/7939 From tschatzl at openjdk.java.net Fri Apr 8 09:21:42 2022 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Fri, 8 Apr 2022 09:21:42 GMT Subject: RFR: 8280761: UseCompressedOops should be set after limit_heap_by_allocatable_memory [v3] In-Reply-To: References: Message-ID: On Fri, 8 Apr 2022 08:44:33 GMT, Albert Mingkun Yang wrote: >> KIRIYAMA Takuya has updated the pull request incrementally with one additional commit since the last revision: >> >> 8280761 UseCompressedOops should be set after limit_heap_by_allocatable_memory > > test/hotspot/jtreg/gc/arguments/TestUseCompressedOopsFlagsWithUlimit.java line 86: > >> 84: // 1. Verify that UseCompressedOops Ergo follows ulimit -v setting. >> 85: // 2. Verify that UseCompressedOops forces compressed oops limit even >> 86: // when ulimit -v are specified. > > I understand the first bullet but not the second. Looking at the reproducers in the JBS ticket, `UseCompressedOops` should not be provided; it's read only. This looks like an additional (unrelated) test to make sure it is overridden if necessary imho. It seems a bit forced though because there is no test that actually verifies that `UseCompressedOops` is `false` later. I'm good with removing the test case. > test/hotspot/jtreg/gc/arguments/TestUseCompressedOopsFlagsWithUlimit.java line 90: > >> 88: long oneG = 1L * 1024L * 1024L * 1024L; >> 89: >> 90: // Args: MaxRAM , MaxRAMPercentage, forcecoop, expect coop > > I am not sure why `MaxRAMPercentage` is needed here. I think this is that the initial value for `reasonable_max` is exactly `MaxRAM`; you are right that for this test it is not necessary to pass it explicitly, just always set it to 100 percent in the command line. ------------- PR: https://git.openjdk.java.net/jdk/pull/7938 From tschatzl at openjdk.java.net Fri Apr 8 09:21:42 2022 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Fri, 8 Apr 2022 09:21:42 GMT Subject: RFR: 8280761: UseCompressedOops should be set after limit_heap_by_allocatable_memory [v3] In-Reply-To: References: Message-ID: <6GOMMUZQwo2KpLSctWaV1RvoiYp5wGaHF1WbMUy5TGg=.857388ea-9fdc-4105-839e-56a018fdd54e@github.com> On Fri, 8 Apr 2022 09:13:18 GMT, Thomas Schatzl wrote: >> test/hotspot/jtreg/gc/arguments/TestUseCompressedOopsFlagsWithUlimit.java line 90: >> >>> 88: long oneG = 1L * 1024L * 1024L * 1024L; >>> 89: >>> 90: // Args: MaxRAM , MaxRAMPercentage, forcecoop, expect coop >> >> I am not sure why `MaxRAMPercentage` is needed here. > > I think this is that the initial value for `reasonable_max` is exactly `MaxRAM`; you are right that for this test it is not necessary to pass it explicitly, just always set it to 100 percent in the command line. Consider that values like `MaxRAM` might change in the future (unlikely as it is). Setting it makes following the execution a bit easier imho. ------------- PR: https://git.openjdk.java.net/jdk/pull/7938 From stuefe at openjdk.java.net Fri Apr 8 09:44:48 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 8 Apr 2022 09:44:48 GMT Subject: RFR: 8283710: JVMTI: Use BitSet for object marking [v6] In-Reply-To: References: Message-ID: On Thu, 7 Apr 2022 18:28:42 GMT, Roman Kennke wrote: >> JVMTI heap walking marks objects in order to track which have been visited already. In order to do that, it uses bits in the object header. Those are the same bits that are also used by some GCs to mark objects (the lowest two bits, also used by locking code). Some GCs also use the bits in order to indicate 'forwarded' objects, where the upper bits of the header represent the forward-pointer. In the case of Shenandoah, it's even more problematic because this happens concurrently, even while JVMTI heap walks can intercept. So far we carefully worked around that problem, but it becomes very problematic in Lilliput, where accesses to the Klass* also requires to decode the header, and figure out what bits means what. >> >> In addition to that, marking objects in their header requires that the original header gets saved and restored. We only do that for 'interesting' headers, that is headers that have a stack-lock, monitor or hash-code. All other headers are reset to their default value. This means we are losing object's GC age. This is not catastrophic, but nontheless interferes with GC. >> >> JFR already has a datastructure called BitSet to support object marking without messing with object's headers. We can use that in JVMTI too. >> >> Testing: >> - [x] tier1 >> - [x] tier2 >> - [x] tier3 >> - [x] serviceability/jvmti >> - [x] vmTestbase/nsk/jvmti > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Move JFRBitSet typedef into its own header; Make _bitset a direct member, not dynamically allocated Hi Thomas, > > A general thought, maybe for a future RFE: > > We now have BitMap and BitSet, which do almost the same thing. Instead of having a new class BitSet, whose job is to be sparse, we could give BitMap the ability to be sparse. We'd save code, reuse the rich BitMap interface and get all the test code for free. > > One way to do that would be to make BitMap responsible for committing its underlying backing memory, in chunks, on-demand only. To do that BitMap would need a secondary map - a commit map - to remember which fragments of its backing memory are committed. Commit map would have a bit per 64M fragment. > > Please don't do this. `BitMap` (well, `BitMapView`) is also used as a lightweight way to overlay it on arbitrary memory temporarily (i.e. remembered sets bitmaps). This typically boils down to no additional memory usage (and overhead) at all. So any additional memory usage or initialization should not be added lightly. Also in most other cases, `BitMap` is used for very tiny bitmaps anyway, this would just add unnecessary functionality (and overhead) for 99% of the usage of `BitMap`. > > Further GCs are using `BitMap` to implement such sparse bit sets already, managing their memory with the corresponding Java heap memory; so adding this functionality at the `BitMap` level would just duplicate functionality with probably not-so-hilarious side effects. > Yes, you are right. I had some more time to think about this and came to the same conclusion. Also abstracting bitwise getters and setters as I thought originally would probably not be enough. > I also _do_ think that the use cases for a dense `BitMap` are significantly different from (huge) sparse "BitMap"s to warrant its own separate class (not saying that one couldn't use the other internally, or that if that `BitSet` could be reused in GCs if configurable enough). > > I am also not sure that the automatic lazy backing of the OS isn't sufficient for these use cases (e.g. JVMTI) too. I'm not sure about this. We often run against the commit charge of the underlying OS, which seems to be more frequent than running out of physical memory. I think voluntary uncommit does make sense. Whether the libc actually uncommits on free() is a different question, but in this case, I think they do, the fragments are large enough. Thanks, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/7964 From lucy at openjdk.java.net Fri Apr 8 10:07:33 2022 From: lucy at openjdk.java.net (Lutz Schmidt) Date: Fri, 8 Apr 2022 10:07:33 GMT Subject: RFR: 8278757: [s390] Implement AES Counter Mode Intrinsic [v2] In-Reply-To: References: Message-ID: > Please review (and approve, if possible) this pull request. > > This is a s390-only enhancement. It introduces the implementation of an AES-CTR intrinsic, making use of the specific s390 instruction for AES counter-mode encryption. > > Testing: SAP does no longer maintain a full build and test environment for s390. Testing is therefore limited to running some test suites (SPECjbb*, SPECjvm*) manually. But: identical code is contained in SAP's commercial product and thoroughly tested in that context. No issues were uncovered. > > @backwaterred Could you please conduct some "official" testing for this PR? > > Thank you all! > > Note: some performance figures can be found in the JBS ticket. Lutz Schmidt has updated the pull request incrementally with one additional commit since the last revision: 8278757: update copyright year ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8142/files - new: https://git.openjdk.java.net/jdk/pull/8142/files/934e71a0..0fd502a2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8142&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8142&range=00-01 Stats: 8 lines in 4 files changed: 0 ins; 0 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/8142.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8142/head:pull/8142 PR: https://git.openjdk.java.net/jdk/pull/8142 From ayang at openjdk.java.net Fri Apr 8 10:16:44 2022 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Fri, 8 Apr 2022 10:16:44 GMT Subject: RFR: 8280761: UseCompressedOops should be set after limit_heap_by_allocatable_memory [v3] In-Reply-To: <6GOMMUZQwo2KpLSctWaV1RvoiYp5wGaHF1WbMUy5TGg=.857388ea-9fdc-4105-839e-56a018fdd54e@github.com> References: <6GOMMUZQwo2KpLSctWaV1RvoiYp5wGaHF1WbMUy5TGg=.857388ea-9fdc-4105-839e-56a018fdd54e@github.com> Message-ID: <-Cdfx9sVBVGWB-EP7XEPD8AgIydxIRHPHpSdzyJzLvY=.1ee8ab37-9c4e-45e9-bf0a-7df5ee24f80f@github.com> On Fri, 8 Apr 2022 09:18:01 GMT, Thomas Schatzl wrote: >> I think this is that the initial value for `reasonable_max` is exactly `MaxRAM`; you are right that for this test it is not necessary to pass it explicitly, just always set it to 100 percent in the command line. > > Consider that values like `MaxRAM` might change in the future (unlikely as it is). Setting it makes following the execution a bit easier imho. Aha, I see. Having `MaxRAMPercentage` set explicitly instead of relying on its default value indeed makes the test more resilient. Please add a comment for `MaxRAMPercentage`. ------------- PR: https://git.openjdk.java.net/jdk/pull/7938 From chagedorn at openjdk.java.net Fri Apr 8 11:01:36 2022 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Fri, 8 Apr 2022 11:01:36 GMT Subject: RFR: 8242181: [Linux] Show source information when printing native stack traces in hs_err files [v7] 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 incrementally with one additional commit since the last revision: Fix build, add GCC flag gdwarf-4 to exclude DWARF 5, add assertions ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7126/files - new: https://git.openjdk.java.net/jdk/pull/7126/files/06489da2..f24c284d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7126&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7126&range=05-06 Stats: 20 lines in 4 files changed: 10 ins; 5 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/7126.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7126/head:pull/7126 PR: https://git.openjdk.java.net/jdk/pull/7126 From chagedorn at openjdk.java.net Fri Apr 8 11:01:37 2022 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Fri, 8 Apr 2022 11:01:37 GMT Subject: RFR: 8242181: [Linux] Show source information when printing native stack traces in hs_err files [v2] In-Reply-To: <9kJSXjQdxkkNKDyFOZ3FiHkSda_BVgW632KkKyz3k14=.024fac33-1147-4d22-bdb8-91cefc913e25@github.com> References: <9kJSXjQdxkkNKDyFOZ3FiHkSda_BVgW632KkKyz3k14=.024fac33-1147-4d22-bdb8-91cefc913e25@github.com> Message-ID: <5tKPmJYC_QCpoRAXGXg_6osgahmz2jUebKnraadqzvk=.f5b027ef-3876-4749-b601-e1d2ab3b9c04@github.com> On Wed, 26 Jan 2022 14:23:14 GMT, Erik Joelsson wrote: >> Christian Hagedorn has updated the pull request incrementally with two additional commits since the last revision: >> >> - Update test/hotspot/jtreg/runtime/ErrorHandling/TestDwarf.java >> >> Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com> >> - Update test/hotspot/jtreg/runtime/ErrorHandling/TestDwarf.java >> >> Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com> > > Build changes look good. I've pushed an update to fix the builds, add some assertions and to add the `gdwarf-4` GCC flag for now to exclude DWARF 5 and let the tests pass again (@erikj79 is that the right place? Do I need to add it at other places as well?). I think this `gdwarf-4` flag is currently the only option to eventually move forward with this RFE without extending the parser to support DWARF 5. I could still do that as a follow-up task and then remove the `gdwarf-4` flag again. But also adding DWARF 5 support in this patch is probably too much. What do you think about that? As mentioned above, I'm going to be away for the rest of the month. I will get back to this PR at the start of May again. Cheers, Christian ------------- PR: https://git.openjdk.java.net/jdk/pull/7126 From lucy at openjdk.java.net Fri Apr 8 11:10:13 2022 From: lucy at openjdk.java.net (Lutz Schmidt) Date: Fri, 8 Apr 2022 11:10:13 GMT Subject: RFR: 8278757: [s390] Implement AES Counter Mode Intrinsic [v3] In-Reply-To: References: Message-ID: > Please review (and approve, if possible) this pull request. > > This is a s390-only enhancement. It introduces the implementation of an AES-CTR intrinsic, making use of the specific s390 instruction for AES counter-mode encryption. > > Testing: SAP does no longer maintain a full build and test environment for s390. Testing is therefore limited to running some test suites (SPECjbb*, SPECjvm*) manually. But: identical code is contained in SAP's commercial product and thoroughly tested in that context. No issues were uncovered. > > @backwaterred Could you please conduct some "official" testing for this PR? > > Thank you all! > > Note: some performance figures can be found in the JBS ticket. Lutz Schmidt has updated the pull request incrementally with one additional commit since the last revision: 8278757: resolve merge conflict ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8142/files - new: https://git.openjdk.java.net/jdk/pull/8142/files/0fd502a2..c7969756 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8142&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8142&range=01-02 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8142.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8142/head:pull/8142 PR: https://git.openjdk.java.net/jdk/pull/8142 From chagedorn at openjdk.java.net Fri Apr 8 11:11:29 2022 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Fri, 8 Apr 2022 11:11:29 GMT Subject: RFR: 8242181: [Linux] Show source information when printing native stack traces in hs_err files [v8] 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 60 commits: - Merge branch 'master' into JDK-8242181 - Fix build, add GCC flag gdwarf-4 to exclude DWARF 5, add assertions - Apply remaining review comments from Thomas Stuefe - Change load_dwarf_file with DwarfFilePath and DebugInfo - Revert renaming on Windows - Merge branch 'master' into JDK-8242181 - Updating some comments - Cleanup loading dwarf file and add summary - Review comments of first pass by Thomas except dwarf file loading - Merge branch 'master' into JDK-8242181 - ... and 50 more: https://git.openjdk.java.net/jdk/compare/60281810...229f1b90 ------------- Changes: https://git.openjdk.java.net/jdk/pull/7126/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7126&range=07 Stats: 2704 lines in 18 files changed: 2606 ins; 41 del; 57 mod Patch: https://git.openjdk.java.net/jdk/pull/7126.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7126/head:pull/7126 PR: https://git.openjdk.java.net/jdk/pull/7126 From lucy at openjdk.java.net Fri Apr 8 11:17:12 2022 From: lucy at openjdk.java.net (Lutz Schmidt) Date: Fri, 8 Apr 2022 11:17:12 GMT Subject: RFR: 8278757: [s390] Implement AES Counter Mode Intrinsic [v4] In-Reply-To: References: Message-ID: > Please review (and approve, if possible) this pull request. > > This is a s390-only enhancement. It introduces the implementation of an AES-CTR intrinsic, making use of the specific s390 instruction for AES counter-mode encryption. > > Testing: SAP does no longer maintain a full build and test environment for s390. Testing is therefore limited to running some test suites (SPECjbb*, SPECjvm*) manually. But: identical code is contained in SAP's commercial product and thoroughly tested in that context. No issues were uncovered. > > @backwaterred Could you please conduct some "official" testing for this PR? > > Thank you all! > > Note: some performance figures can be found in the JBS ticket. Lutz Schmidt has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: - Merge branch 'master' into JDK-8278757 - 8278757: resolve merge conflict - 8278757: update copyright year - 8278757: [s390] Implement AES Counter Mode Intrinsic ------------- Changes: https://git.openjdk.java.net/jdk/pull/8142/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8142&range=03 Stats: 697 lines in 5 files changed: 669 ins; 5 del; 23 mod Patch: https://git.openjdk.java.net/jdk/pull/8142.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8142/head:pull/8142 PR: https://git.openjdk.java.net/jdk/pull/8142 From shade at openjdk.java.net Fri Apr 8 11:53:21 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 8 Apr 2022 11:53:21 GMT Subject: RFR: 8284578: Relax InterpreterCodelet stub alignment Message-ID: `InterpreterCodelet` is aligned by `CodeEntryAlignment` (`CAE`) twice. First, the entire stub is aligned, which aligns its data section. Then, the code section in the stub is aligned. Since `CAE` is usually larger than the size of `InterpreterCodelet`, we are wasting quite a bit of space for each codelet. In the extreme cases, like PPC that defaults to `CAE=128`, we have 16 bytes of codelet data effectively taking 128 bytes! This can be made better by relaxing the `InterpreterCodelet` stub alignment to `HeapWordSize`, while leaving its code section alignment the same. This tangentially touches the only other user for `StubQueue`: `ICStub`. Unfortunately, we cannot do the same kind of relaxation there, because there is a reverse lookup function that needs to reach data section from the code section, which forces us to keep the same alignment for both. Interpreter sizes on Linux x86_64 release: # Baseline, CEA=32 (default) code size = 94K bytes avg codelet size = 356 bytes # Baseline, CEA=128 (PPC-like) code size = 133K bytes avg codelet size = 501 bytes # Patched, CEA=32 (default) code size = 89K bytes avg codelet size = 338 bytes # Patched, CEA=128 (PPC-like) code size = 100K bytes avg codelet size = 380 bytes Point performance runs (SPECjvm2008:serial with `-Xint` on Linux x86_64 release): Benchmark Mode Cnt Score Error Units # Baseline, CEA=32 Serial.test thrpt 9 73.427 ? 0.152 ops/s # Baseline, CEA=128 Serial.test thrpt 9 70.999 ? 0.246 ops/s # Patched, CEA=32 Serial.test thrpt 9 73.991 ? 0.860 ops/s # Patched, CEA=128 Serial.test thrpt 9 72.981 ? 0.301 ops/s Additional testing: - [x] Linux x86_64 fastdebug `tier1` - [ ] Linux x86_64 fastdebug `tier2` - [ ] Linux x86_64 fastdebug `tier3` ------------- Commit messages: - Initial implementation Changes: https://git.openjdk.java.net/jdk/pull/8159/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8159&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8284578 Stats: 43 lines in 4 files changed: 16 ins; 5 del; 22 mod Patch: https://git.openjdk.java.net/jdk/pull/8159.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8159/head:pull/8159 PR: https://git.openjdk.java.net/jdk/pull/8159 From rkennke at openjdk.java.net Fri Apr 8 12:05:44 2022 From: rkennke at openjdk.java.net (Roman Kennke) Date: Fri, 8 Apr 2022 12:05:44 GMT Subject: RFR: 8283710: JVMTI: Use BitSet for object marking In-Reply-To: References: <2V13Kr51baZQzWRorTT52LphO6pvNw3rugJrbC1mksA=.29cb7364-fe29-461d-864f-4c0c164502bd@github.com> <--W_f_6TlAnxqAKsvy0G8UlfJbDr32SEuqMZ_Uc5Hw0=.e0ad488c-ce07-4e5e-8c34-ee1ddc891749@github.com> <4WleT5oWgzYka9hUYg1QiAld3OeC_hS41LJILk30fls=.92015a62-ac2f-4bb8-b550-45279f924c0b@github.com> <1-bj5KJVcCxQUTmH22mBXWF9kdPBEQES3fYe6SzJZVg=.9101452c-db61-4486-b092-4003013f5199@github.com> Message-ID: On Fri, 8 Apr 2022 03:40:41 GMT, Thomas Stuefe wrote: > > > One open question is which MEMFLAGS to use. mtTracing doesn't seem to be exactly right. Should I templatize BitSet and make JVMTI use mtServiceability and JRF use mtTracing as it did before? > > > > > > Yes, I think templatizing for MEMFLAGS makes sense (concurrentHashTable.hpp is too). > > I haven't had time to look at the code, but I don't know about this. Slapping a template parameter on everything isn't necessarily a good idea. We recently (JDK-8283368) undid exactly this sort of thing in the cardset code, instead making the MEMFLAGS value a runtime parameter provided at construction time. This avoids a bunch of generated code duplication, additional template syntax, and allows more implementation be put in .cpp files because it isn't a template. The trouble is that ObjectBitSet is a subclass of CHeapObj, which takes a template parameter for memflags itself. How could I avoid templatizing the ObjectBitSet itself? ------------- PR: https://git.openjdk.java.net/jdk/pull/7964 From coleenp at openjdk.java.net Fri Apr 8 13:02:43 2022 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 8 Apr 2022 13:02:43 GMT Subject: RFR: 8283710: JVMTI: Use BitSet for object marking [v6] In-Reply-To: References: Message-ID: On Thu, 7 Apr 2022 18:28:42 GMT, Roman Kennke wrote: >> JVMTI heap walking marks objects in order to track which have been visited already. In order to do that, it uses bits in the object header. Those are the same bits that are also used by some GCs to mark objects (the lowest two bits, also used by locking code). Some GCs also use the bits in order to indicate 'forwarded' objects, where the upper bits of the header represent the forward-pointer. In the case of Shenandoah, it's even more problematic because this happens concurrently, even while JVMTI heap walks can intercept. So far we carefully worked around that problem, but it becomes very problematic in Lilliput, where accesses to the Klass* also requires to decode the header, and figure out what bits means what. >> >> In addition to that, marking objects in their header requires that the original header gets saved and restored. We only do that for 'interesting' headers, that is headers that have a stack-lock, monitor or hash-code. All other headers are reset to their default value. This means we are losing object's GC age. This is not catastrophic, but nontheless interferes with GC. >> >> JFR already has a datastructure called BitSet to support object marking without messing with object's headers. We can use that in JVMTI too. >> >> Testing: >> - [x] tier1 >> - [x] tier2 >> - [x] tier3 >> - [x] serviceability/jvmti >> - [x] vmTestbase/nsk/jvmti > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Move JFRBitSet typedef into its own header; Make _bitset a direct member, not dynamically allocated Here's an idea. Add an mtflag called mtBitMap and use that. There's plenty of bits in mt flags. ------------- PR: https://git.openjdk.java.net/jdk/pull/7964 From erikj at openjdk.java.net Fri Apr 8 13:06:03 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 8 Apr 2022 13:06:03 GMT Subject: RFR: 8242181: [Linux] Show source information when printing native stack traces in hs_err files [v8] In-Reply-To: References: Message-ID: On Fri, 8 Apr 2022 11:11:29 GMT, Christian Hagedorn wrote: >> 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 60 commits: > > - Merge branch 'master' into JDK-8242181 > - Fix build, add GCC flag gdwarf-4 to exclude DWARF 5, add assertions > - Apply remaining review comments from Thomas Stuefe > - Change load_dwarf_file with DwarfFilePath and DebugInfo > - Revert renaming on Windows > - Merge branch 'master' into JDK-8242181 > - Updating some comments > - Cleanup loading dwarf file and add summary > - Review comments of first pass by Thomas except dwarf file loading > - Merge branch 'master' into JDK-8242181 > - ... and 50 more: https://git.openjdk.java.net/jdk/compare/60281810...229f1b90 make/autoconf/flags-cflags.m4 line 116: > 114: fi > 115: > 116: CFLAGS_DEBUG_SYMBOLS="-g -gdwarf-4" We may need to guard this with a FLAGS_COMPILER_CHECK_ARGUMENTS. Perhaps it should also be applied only on Linux since the whole feature is Linux only. What do you think @magicus? ------------- PR: https://git.openjdk.java.net/jdk/pull/7126 From shade at openjdk.java.net Fri Apr 8 13:31:11 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 8 Apr 2022 13:31:11 GMT Subject: RFR: 8284584: Avoid duplicate node_idx_t definitions Message-ID: While looking at `Node`, I realized there are two definitions for node_idx_t, another one added by [JDK-8076284](https://bugs.openjdk.java.net/browse/JDK-8076284). These should be de-duplicated to avoid confusion. ------------- Commit messages: - Move Changes: https://git.openjdk.java.net/jdk/pull/8164/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8164&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8284584 Stats: 12 lines in 3 files changed: 5 ins; 7 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8164.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8164/head:pull/8164 PR: https://git.openjdk.java.net/jdk/pull/8164 From ihse at openjdk.java.net Fri Apr 8 13:38:12 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Fri, 8 Apr 2022 13:38:12 GMT Subject: RFR: 8242181: [Linux] Show source information when printing native stack traces in hs_err files [v8] In-Reply-To: References: Message-ID: On Fri, 8 Apr 2022 13:02:00 GMT, Erik Joelsson wrote: >> Christian Hagedorn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 60 commits: >> >> - Merge branch 'master' into JDK-8242181 >> - Fix build, add GCC flag gdwarf-4 to exclude DWARF 5, add assertions >> - Apply remaining review comments from Thomas Stuefe >> - Change load_dwarf_file with DwarfFilePath and DebugInfo >> - Revert renaming on Windows >> - Merge branch 'master' into JDK-8242181 >> - Updating some comments >> - Cleanup loading dwarf file and add summary >> - Review comments of first pass by Thomas except dwarf file loading >> - Merge branch 'master' into JDK-8242181 >> - ... and 50 more: https://git.openjdk.java.net/jdk/compare/60281810...229f1b90 > > make/autoconf/flags-cflags.m4 line 116: > >> 114: fi >> 115: >> 116: CFLAGS_DEBUG_SYMBOLS="-g -gdwarf-4" > > We may need to guard this with a FLAGS_COMPILER_CHECK_ARGUMENTS. Perhaps it should also be applied only on Linux since the whole feature is Linux only. What do you think @magicus? I'm googling around for some information about -gdwarf-4 but is mostly coming up empty handed. :( I found [this](https://www.phoronix.com/scan.php?page=news_item&px=GCC-11-DWARF-5-Possible-Default) saying that dwarf-5 became default in gcc11. It also claims dwarf-4 is about 10 years old. My guess is that all our supported gcc versions do support -gdwarf-4, but this needs to be verified. In practice, we only use gcc on linux so I'm not convinced we need to have an addition check for that. If we ever are going to support gcc on other OSes I think we'll have many more, much harder problems, than to remove the -gdwarf-4 flag. ------------- PR: https://git.openjdk.java.net/jdk/pull/7126 From rkennke at openjdk.java.net Fri Apr 8 14:20:41 2022 From: rkennke at openjdk.java.net (Roman Kennke) Date: Fri, 8 Apr 2022 14:20:41 GMT Subject: RFR: 8283710: JVMTI: Use BitSet for object marking [v6] In-Reply-To: References: Message-ID: On Fri, 8 Apr 2022 12:59:26 GMT, Coleen Phillimore wrote: > Here's an idea. Add an mtflag called mtBitMap and use that. There's plenty of bits in mt flags. Naa, I don't think this is justified. It isn't used as widely or frequently to warrant its own flag. ------------- PR: https://git.openjdk.java.net/jdk/pull/7964 From stuefe at openjdk.java.net Fri Apr 8 14:54:41 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 8 Apr 2022 14:54:41 GMT Subject: RFR: 8283710: JVMTI: Use BitSet for object marking [v6] In-Reply-To: References: Message-ID: On Fri, 8 Apr 2022 14:17:06 GMT, Roman Kennke wrote: > > Here's an idea. Add an mtflag called mtBitMap and use that. There's plenty of bits in mt flags. > > Naa, I don't think this is justified. It isn't used as widely or frequently to warrant its own flag. Plus, it would muddy the water, since what we actually want is the memory accounted toward the subsystem on behalf of which we create the data structure. mtBitMap would be a bit like "mtArray" for GrowableArray. Note that there was the idea, and an associated JBS issue (https://bugs.openjdk.java.net/browse/JDK-8281819) of making NMT categories groupable in a one- or multi-layered hierarchy. That way, one could account to "mtGC" -> "mtBitSet", for instance. For now, I opt to either live with what we have with the typedef'ed BitSet, and leave MEMFLAG cleanups to a later RFE. Alternatively, make the MEMFLAG a runtime parameter of the bitset, use that for the heap allocated fragments, but use "mtInternal" for the actual class. I mean, those are just a few bytes. ------------- PR: https://git.openjdk.java.net/jdk/pull/7964 From stuefe at openjdk.java.net Fri Apr 8 14:54:42 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 8 Apr 2022 14:54:42 GMT Subject: RFR: 8283710: JVMTI: Use BitSet for object marking [v6] In-Reply-To: References: Message-ID: On Thu, 7 Apr 2022 18:28:42 GMT, Roman Kennke wrote: >> JVMTI heap walking marks objects in order to track which have been visited already. In order to do that, it uses bits in the object header. Those are the same bits that are also used by some GCs to mark objects (the lowest two bits, also used by locking code). Some GCs also use the bits in order to indicate 'forwarded' objects, where the upper bits of the header represent the forward-pointer. In the case of Shenandoah, it's even more problematic because this happens concurrently, even while JVMTI heap walks can intercept. So far we carefully worked around that problem, but it becomes very problematic in Lilliput, where accesses to the Klass* also requires to decode the header, and figure out what bits means what. >> >> In addition to that, marking objects in their header requires that the original header gets saved and restored. We only do that for 'interesting' headers, that is headers that have a stack-lock, monitor or hash-code. All other headers are reset to their default value. This means we are losing object's GC age. This is not catastrophic, but nontheless interferes with GC. >> >> JFR already has a datastructure called BitSet to support object marking without messing with object's headers. We can use that in JVMTI too. >> >> Testing: >> - [x] tier1 >> - [x] tier2 >> - [x] tier3 >> - [x] serviceability/jvmti >> - [x] vmTestbase/nsk/jvmti > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Move JFRBitSet typedef into its own header; Make _bitset a direct member, not dynamically allocated Third alternative would be not to derive from CHeapObj at all, since we don't new it anywhere if I see correctly. ------------- PR: https://git.openjdk.java.net/jdk/pull/7964 From alanb at openjdk.java.net Fri Apr 8 15:03:28 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 8 Apr 2022 15:03:28 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) Message-ID: This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. We will refresh this PR periodically to pick up changes and fixes from the loom repo. Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. ------------- Commit messages: - Initial push Changes: https://git.openjdk.java.net/jdk/pull/8166/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8166&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8284161 Stats: 101472 lines in 1116 files changed: 91922 ins; 4207 del; 5343 mod Patch: https://git.openjdk.java.net/jdk/pull/8166.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8166/head:pull/8166 PR: https://git.openjdk.java.net/jdk/pull/8166 From coleenp at openjdk.java.net Fri Apr 8 15:03:39 2022 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 8 Apr 2022 15:03:39 GMT Subject: RFR: 8283710: JVMTI: Use BitSet for object marking [v6] In-Reply-To: References: Message-ID: <6m_aPm2bCCe1oQpZs6jAy2PWnigb7jmoRlM8Mz5Ffm0=.d7975987-fcf6-4dcb-ad35-3e4220855bb2@github.com> On Thu, 7 Apr 2022 18:28:42 GMT, Roman Kennke wrote: >> JVMTI heap walking marks objects in order to track which have been visited already. In order to do that, it uses bits in the object header. Those are the same bits that are also used by some GCs to mark objects (the lowest two bits, also used by locking code). Some GCs also use the bits in order to indicate 'forwarded' objects, where the upper bits of the header represent the forward-pointer. In the case of Shenandoah, it's even more problematic because this happens concurrently, even while JVMTI heap walks can intercept. So far we carefully worked around that problem, but it becomes very problematic in Lilliput, where accesses to the Klass* also requires to decode the header, and figure out what bits means what. >> >> In addition to that, marking objects in their header requires that the original header gets saved and restored. We only do that for 'interesting' headers, that is headers that have a stack-lock, monitor or hash-code. All other headers are reset to their default value. This means we are losing object's GC age. This is not catastrophic, but nontheless interferes with GC. >> >> JFR already has a datastructure called BitSet to support object marking without messing with object's headers. We can use that in JVMTI too. >> >> Testing: >> - [x] tier1 >> - [x] tier2 >> - [x] tier3 >> - [x] serviceability/jvmti >> - [x] vmTestbase/nsk/jvmti > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Move JFRBitSet typedef into its own header; Make _bitset a direct member, not dynamically allocated We must call new on it somewhere. I am not opposed to making this an mtFlags template then. This is a small point in this improvement. ------------- PR: https://git.openjdk.java.net/jdk/pull/7964 From kvn at openjdk.java.net Fri Apr 8 16:36:47 2022 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 8 Apr 2022 16:36:47 GMT Subject: RFR: 8282221: x86 intrinsics for divideUnsigned and remainderUnsigned methods in java.lang.Integer and java.lang.Long [v12] In-Reply-To: References: Message-ID: <3ol5UgzLV7Nh2MtleKBs1GzbsmDAj7VBgK0MwQqPBgU=.bc82f703-6e32-43c3-8276-344805f4e9bb@github.com> On Fri, 8 Apr 2022 01:59:10 GMT, Quan Anh Mai wrote: > Personally, I think the optimisation for `div < 0` should be handled by the mid-end optimiser, which will not only give us the advantages of dead code elimination, but also global code motion. I would suggest the backend only doing `xorl rdx, rdx; divl $div$$Register` and the optimisation for `div < 0` will be implemented as a part of JDK-8282365. What do you think? I agree that we can do more optimizations with constants as JDK-8282365 suggested. But I think we should proceed with current changes as they are after fixing remaining issues. I assume that you are talking about case when `divisor` is constant (or both). Because if it is not, IR optimization will not help - we don't profile arithmetic values so we can't generate uncommon trap path without some profiling information. ------------- PR: https://git.openjdk.java.net/jdk/pull/7572 From kvn at openjdk.java.net Fri Apr 8 16:42:34 2022 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 8 Apr 2022 16:42:34 GMT Subject: RFR: 8282221: x86 intrinsics for divideUnsigned and remainderUnsigned methods in java.lang.Integer and java.lang.Long [v8] In-Reply-To: References: Message-ID: On Fri, 8 Apr 2022 00:55:50 GMT, Srinivas Vamsi Parasa wrote: >> I have few comments. > > Hi Vladimir (@vnkozlov), > > Incorporated all the suggestions you made in the previous review and pushed a new commit. > Please let me know if anything else is needed. > > Thanks, > Vamsi @vamsi-parasa I got failures in new tests when run with `-XX:UseAVX=3 -XX:+UnlockDiagnosticVMOptions -XX:+UseKNLSetting ` flags: # A fatal error has been detected by the Java Runtime Environment: # # SIGFPE (0x8) at pc=0x00007f2fa8c674ea, pid=3334, tid=3335 # # JRE version: Java(TM) SE Runtime Environment (19.0) (fastdebug build 19-internal-2022-04-08-0157190.vladimir.kozlov.jdkgit) # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 19-internal-2022-04-08-0157190.vladimir.kozlov.jdkgit, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64) # Problematic frame: # J 504% c2 compiler.intrinsics.TestLongUnsignedDivMod.testDivideUnsigned()V (48 bytes) @ 0x00007f2fa8c674ea [0x00007f2fa8c672a0+0x000000000000024a] # # A fatal error has been detected by the Java Runtime Environment: # # SIGFPE (0x8) at pc=0x00007fb8c0c4fb18, pid=3309, tid=3310 # # JRE version: Java(TM) SE Runtime Environment (19.0) (fastdebug build 19-internal-2022-04-08-0157190.vladimir.kozlov.jdkgit) # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 19-internal-2022-04-08-0157190.vladimir.kozlov.jdkgit, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64) # Problematic frame: # J 445 c2 compiler.intrinsics.TestIntegerUnsignedDivMod.divmod(III)V (23 bytes) @ 0x00007fb8c0c4fb18 [0x00007fb8c0c4fae0+0x0000000000000038] # ------------- PR: https://git.openjdk.java.net/jdk/pull/7572 From rkennke at openjdk.java.net Fri Apr 8 16:47:53 2022 From: rkennke at openjdk.java.net (Roman Kennke) Date: Fri, 8 Apr 2022 16:47:53 GMT Subject: RFR: 8283710: JVMTI: Use BitSet for object marking [v6] In-Reply-To: <6m_aPm2bCCe1oQpZs6jAy2PWnigb7jmoRlM8Mz5Ffm0=.d7975987-fcf6-4dcb-ad35-3e4220855bb2@github.com> References: <6m_aPm2bCCe1oQpZs6jAy2PWnigb7jmoRlM8Mz5Ffm0=.d7975987-fcf6-4dcb-ad35-3e4220855bb2@github.com> Message-ID: On Fri, 8 Apr 2022 15:00:22 GMT, Coleen Phillimore wrote: > We must call new on it somewhere. I am not opposed to making this an mtFlags template then. This is a small point in this improvement. Yes, at some point we need to allocate the fragments and fragments table. We could *perhaps* work around it by passing MEMFLAGS as constexpr, but I don't think this would change generated code much. ------------- PR: https://git.openjdk.java.net/jdk/pull/7964 From iklam at openjdk.java.net Fri Apr 8 16:53:42 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 8 Apr 2022 16:53:42 GMT Subject: RFR: 8284435: Add dedicated filler objects for known dead Java heap areas In-Reply-To: References: Message-ID: On Fri, 8 Apr 2022 08:13:33 GMT, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this change that adds dedicated filler objects to the VM? > > Currently, when formatting areas of dead objects all gcs use instances of j.l.Object and int-arrays. > > This has the drawback of not being easily able to discern whether a given object is actually dead (and should never be referenced) or just a regular j.l.Object/int array. > > This also makes enhanced error detection (any reference to such an object is an error - i.e. detecting references to such objects) and to skip potentially already unloaded classes when scanning areas of the heap below TAMS, G1 uses its prev bitmap. > Other collectors do not have this extra information at the moment, so they can't (and don't) do this kind of verification. > > With [JDK-8210708](https://bugs.openjdk.java.net/browse/JDK-8210708) the prev bitmap will effectively be removed in G1; G1 will format the dead areas with these filler objects to avoid coming across unloaded classes. This is fine wrt to normal operation, however, this looses the existing enhanced verification mentioned above. > > This change proposes to add dedicated VM-internal filler objects, i.e. equivalents of j.l.Object and int-arrays. > > This has the following benefits: > > - keep this error detection (actually making it much simpler) and allowing similar verification for other collectors. (This change does not add this) > > - this also makes it "easy" to detect references to filler objects in debugging tools - you only need to know the two klasses (or just get their friendly name) to see whether that reference may actually be valid (or refers to the inside such an object). References to these classes in the crash file may also allow the issue to be more clear. > > This causes some minor changes to external behavior: > > - logs/heap dumps now contain instances of these objects - which seems fine as previously they have just been reported as part of j.l.Object/int-arrays statistics. The VM spec also does not guarantee whether a particular kind of object should/should not show there anyway afaik. > > - if the application ever gets to instantiate a reference to such an object somehow, any enabled verification will crash the VM. That's bad luck for messing with internal classes, but that's the purpose of these objects. > > The change takes care that getting a reference will not be possible by normal means (i.e. via Class.forName() etc) - which should be sufficient to avoid the issue. Actually, existing mechanisms seem to be sufficient. > > > Testing: tier1-8 > > There is one question I would like the reviewers to specially think about, the name of the filler array klass. I just used `Ljava/internal/vm/FillerArray;` for that, looking at other internal symbols/klasses, but I'm not sure this adheres to naming guidelines. > > Thanks go to @iklam for helping out with the change. > > Thanks, > Thomas Changes requested by iklam (Reviewer). src/hotspot/share/classfile/systemDictionaryShared.cpp line 1727: > 1725: ArchivedMirrorPatcher::update_array_klasses(k); > 1726: } > 1727: ArchivedMirrorPatcher::update_array_klasses(Universe::fillerArrayKlassObj()); I think this is not necessary. `Universe::fillerArrayKlassObj()` shares the same mirror as `Universe::intArrayKlassObj()`, which has already been updated in the loop above. `ArchivedMirrorPatcher::update_array_klasses(k)` will essentially do `k->mirror->pointer_back_to_klass += delta`, so it will incorrectly set the pointer when delta is not zero. I would suggest running with -XX:ArchiveRelocationMode=1 -Xlog:cds -Xlog:class+load=debug and step into the following code: void java_lang_Class::update_archived_mirror_native_pointers(oop archived_mirror) { assert(MetaspaceShared::relocation_delta() != 0, "must be"); Klass* k = ((Klass*)archived_mirror->metadata_field(_klass_offset)); archived_mirror->metadata_field_put(_klass_offset, (Klass*)(address(k) + MetaspaceShared::relocation_delta())); <<<< HERE src/hotspot/share/memory/universe.cpp line 205: > 203: } > 204: // Hide _fillerArrayKlassObj from JVMTI > 205: // closure->do_klass(_fillerArrayKlassObj); Maybe the comment should be more explicit? // We don't do the following because it will confuse JVMTI. // _fillerArrayKlassObj is used only by GC, which doesn't need to see // this klass from basic_type_classes_do(). ------------- PR: https://git.openjdk.java.net/jdk/pull/8156 From duke at openjdk.java.net Fri Apr 8 16:53:51 2022 From: duke at openjdk.java.net (Quan Anh Mai) Date: Fri, 8 Apr 2022 16:53:51 GMT Subject: RFR: 8282221: x86 intrinsics for divideUnsigned and remainderUnsigned methods in java.lang.Integer and java.lang.Long [v8] In-Reply-To: References: Message-ID: <7qJdOYS-ms-iCS9TOplg9pSiWzu-cS-GYzdRfuu5IOU=.855a0fdc-5d87-47a3-98af-b2771b5e79b6@github.com> On Fri, 8 Apr 2022 16:39:31 GMT, Vladimir Kozlov wrote: >> Hi Vladimir (@vnkozlov), >> >> Incorporated all the suggestions you made in the previous review and pushed a new commit. >> Please let me know if anything else is needed. >> >> Thanks, >> Vamsi > > @vamsi-parasa I got failures in new tests when run with `-XX:UseAVX=3 -XX:+UnlockDiagnosticVMOptions -XX:+UseKNLSetting ` flags: > > # A fatal error has been detected by the Java Runtime Environment: > # > # SIGFPE (0x8) at pc=0x00007f2fa8c674ea, pid=3334, tid=3335 > # > # JRE version: Java(TM) SE Runtime Environment (19.0) (fastdebug build 19-internal-2022-04-08-0157190.vladimir.kozlov.jdkgit) > # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 19-internal-2022-04-08-0157190.vladimir.kozlov.jdkgit, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64) > # Problematic frame: > # J 504% c2 compiler.intrinsics.TestLongUnsignedDivMod.testDivideUnsigned()V (48 bytes) @ 0x00007f2fa8c674ea [0x00007f2fa8c672a0+0x000000000000024a] > # > > > > # A fatal error has been detected by the Java Runtime Environment: > # > # SIGFPE (0x8) at pc=0x00007fb8c0c4fb18, pid=3309, tid=3310 > # > # JRE version: Java(TM) SE Runtime Environment (19.0) (fastdebug build 19-internal-2022-04-08-0157190.vladimir.kozlov.jdkgit) > # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 19-internal-2022-04-08-0157190.vladimir.kozlov.jdkgit, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64) > # Problematic frame: > # J 445 c2 compiler.intrinsics.TestIntegerUnsignedDivMod.divmod(III)V (23 bytes) @ 0x00007fb8c0c4fb18 [0x00007fb8c0c4fae0+0x0000000000000038] > # @vnkozlov The `uDivI_rRegNode` currently emits machine code equivalent to the following Java pseudocode: if (div < 0) { // fast path, if div < 0, then (unsigned)div > MAX_UINT / 2U // I don't know why this is so complicated, basically this is rax u>= div ? 1 : 0 return (rax & ~(rax - div)) >>> (Integer.SIZE - 1); } else { // slow path, just do the division normally return rax u/ div; } What I am suggesting is to leave the negative-divisor fast part to be implemented in the IR and the macro assembler should only concern emitting the division instruction and not worry about optimisation here. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/7572 From ccheung at openjdk.java.net Fri Apr 8 16:57:35 2022 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Fri, 8 Apr 2022 16:57:35 GMT Subject: RFR: 8284336: CDS SignedJar.java test fails due to archived Reference object In-Reply-To: References: Message-ID: On Thu, 7 Apr 2022 22:44:19 GMT, Ioi Lam wrote: > During `java -Xshare:dump`, `ClassLoaders.bootLoader().resourceCache` is usually null. However, if a signed class is loaded, `resourceCache` will point to a `java.lang.ref.SoftReference`. Although rare (we have never seen this during our testing), it's possible for `resourceCache.discovered` to directly or indirectly point to another `Reference` which may contain an object that cannot be archived. > > The fix is simple: reset the `resourceCache` field of all three archived ClassLoader objects (boot/platform/app). > > I cannot reproduce the problem and I am unable to write a deterministic test case. However, the bug reporter has tested my preliminary patch and is no longer able to reproduce the failure. > > Please see the bug report [JDK-8284336](https://bugs.openjdk.java.net/browse/JDK-8284336) for detailed analysis and traces. LGTM. ------------- Marked as reviewed by ccheung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8151 From stuefe at openjdk.java.net Fri Apr 8 17:03:41 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 8 Apr 2022 17:03:41 GMT Subject: RFR: 8283710: JVMTI: Use BitSet for object marking [v6] In-Reply-To: References: Message-ID: On Thu, 7 Apr 2022 18:28:42 GMT, Roman Kennke wrote: >> JVMTI heap walking marks objects in order to track which have been visited already. In order to do that, it uses bits in the object header. Those are the same bits that are also used by some GCs to mark objects (the lowest two bits, also used by locking code). Some GCs also use the bits in order to indicate 'forwarded' objects, where the upper bits of the header represent the forward-pointer. In the case of Shenandoah, it's even more problematic because this happens concurrently, even while JVMTI heap walks can intercept. So far we carefully worked around that problem, but it becomes very problematic in Lilliput, where accesses to the Klass* also requires to decode the header, and figure out what bits means what. >> >> In addition to that, marking objects in their header requires that the original header gets saved and restored. We only do that for 'interesting' headers, that is headers that have a stack-lock, monitor or hash-code. All other headers are reset to their default value. This means we are losing object's GC age. This is not catastrophic, but nontheless interferes with GC. >> >> JFR already has a datastructure called BitSet to support object marking without messing with object's headers. We can use that in JVMTI too. >> >> Testing: >> - [x] tier1 >> - [x] tier2 >> - [x] tier3 >> - [x] serviceability/jvmti >> - [x] vmTestbase/nsk/jvmti > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Move JFRBitSet typedef into its own header; Make _bitset a direct member, not dynamically allocated > > We must call new on it somewhere. I am not opposed to making this an mtFlags template then. This is a small point in this improvement. > > Yes, at some point we need to allocate the fragments and fragments table. We could _perhaps_ work around it by passing MEMFLAGS as constexpr, but I don't think this would change generated code much. (all bikeshedding since we all agree the current version is fine, no?) No, sorry, I meant make BitSet a normal class. Not derived from CHeapObj, since it gets not newed, only used via composition or on a stack. And give it a runtime parm to set the MEMFLAG. So: class BitSet { const MEMFLAGS _flags; public: BitSet(MEMFLAGS f = mtInternal) : _flags(f) {...} }; and use those flags for the c-heap allocation of the fragments. ------------- PR: https://git.openjdk.java.net/jdk/pull/7964 From kvn at openjdk.java.net Fri Apr 8 17:07:37 2022 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 8 Apr 2022 17:07:37 GMT Subject: RFR: 8284584: Avoid duplicate node_idx_t definitions In-Reply-To: References: Message-ID: On Fri, 8 Apr 2022 13:25:16 GMT, Aleksey Shipilev wrote: > While looking at `Node`, I realized there are two definitions for node_idx_t, another one added by [JDK-8076284](https://bugs.openjdk.java.net/browse/JDK-8076284). These should be de-duplicated to avoid confusion. I am not sure we want to move C2's specific type to general code. `node.hpp` includes `compile.hpp` so may be leave definition there only. ------------- PR: https://git.openjdk.java.net/jdk/pull/8164 From kvn at openjdk.java.net Fri Apr 8 17:17:48 2022 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 8 Apr 2022 17:17:48 GMT Subject: RFR: 8282221: x86 intrinsics for divideUnsigned and remainderUnsigned methods in java.lang.Integer and java.lang.Long [v12] In-Reply-To: References: Message-ID: On Fri, 8 Apr 2022 01:05:33 GMT, Srinivas Vamsi Parasa wrote: >> Optimizes the divideUnsigned() and remainderUnsigned() methods in java.lang.Integer and java.lang.Long classes using x86 intrinsics. This change shows 3x improvement for Integer methods and upto 25% improvement for Long. This change also implements the DivMod optimization which fuses division and modulus operations if needed. The DivMod optimization shows 3x improvement for Integer and ~65% improvement for Long. > > Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision: > > uncomment zero in integer div, mod test Agree, this is reasonable suggestion. It could be done in these changes. ------------- PR: https://git.openjdk.java.net/jdk/pull/7572 From iklam at openjdk.java.net Fri Apr 8 17:22:43 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 8 Apr 2022 17:22:43 GMT Subject: RFR: 8284336: CDS SignedJar.java test fails due to archived Reference object In-Reply-To: References: Message-ID: On Fri, 8 Apr 2022 07:08:29 GMT, Alan Bateman wrote: >> During `java -Xshare:dump`, `ClassLoaders.bootLoader().resourceCache` is usually null. However, if a signed class is loaded, `resourceCache` will point to a `java.lang.ref.SoftReference`. Although rare (we have never seen this during our testing), it's possible for `resourceCache.discovered` to directly or indirectly point to another `Reference` which may contain an object that cannot be archived. >> >> The fix is simple: reset the `resourceCache` field of all three archived ClassLoader objects (boot/platform/app). >> >> I cannot reproduce the problem and I am unable to write a deterministic test case. However, the bug reporter has tested my preliminary patch and is no longer able to reproduce the failure. >> >> Please see the bug report [JDK-8284336](https://bugs.openjdk.java.net/browse/JDK-8284336) for detailed analysis and traces. > > The updates to resetArchivedStates look okay. Thanks @AlanBateman and @calvinccheung for the review! ------------- PR: https://git.openjdk.java.net/jdk/pull/8151 From iklam at openjdk.java.net Fri Apr 8 17:22:43 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 8 Apr 2022 17:22:43 GMT Subject: Integrated: 8284336: CDS SignedJar.java test fails due to archived Reference object In-Reply-To: References: Message-ID: <8Xiu1d7aUGEzZXenIQX6EouQI7jFJWAD1CGxPpFIxRI=.b2eb0af2-7426-4c17-a185-b58f582137db@github.com> On Thu, 7 Apr 2022 22:44:19 GMT, Ioi Lam wrote: > During `java -Xshare:dump`, `ClassLoaders.bootLoader().resourceCache` is usually null. However, if a signed class is loaded, `resourceCache` will point to a `java.lang.ref.SoftReference`. Although rare (we have never seen this during our testing), it's possible for `resourceCache.discovered` to directly or indirectly point to another `Reference` which may contain an object that cannot be archived. > > The fix is simple: reset the `resourceCache` field of all three archived ClassLoader objects (boot/platform/app). > > I cannot reproduce the problem and I am unable to write a deterministic test case. However, the bug reporter has tested my preliminary patch and is no longer able to reproduce the failure. > > Please see the bug report [JDK-8284336](https://bugs.openjdk.java.net/browse/JDK-8284336) for detailed analysis and traces. This pull request has now been integrated. Changeset: 662320a0 Author: Ioi Lam URL: https://git.openjdk.java.net/jdk/commit/662320a0ec0b373fa1e4df9281224e9bdbdf76ac Stats: 28 lines in 5 files changed: 25 ins; 0 del; 3 mod 8284336: CDS SignedJar.java test fails due to archived Reference object Reviewed-by: alanb, ccheung ------------- PR: https://git.openjdk.java.net/jdk/pull/8151 From rkennke at openjdk.java.net Fri Apr 8 17:35:09 2022 From: rkennke at openjdk.java.net (Roman Kennke) Date: Fri, 8 Apr 2022 17:35:09 GMT Subject: RFR: 8283710: JVMTI: Use BitSet for object marking [v7] In-Reply-To: References: Message-ID: > JVMTI heap walking marks objects in order to track which have been visited already. In order to do that, it uses bits in the object header. Those are the same bits that are also used by some GCs to mark objects (the lowest two bits, also used by locking code). Some GCs also use the bits in order to indicate 'forwarded' objects, where the upper bits of the header represent the forward-pointer. In the case of Shenandoah, it's even more problematic because this happens concurrently, even while JVMTI heap walks can intercept. So far we carefully worked around that problem, but it becomes very problematic in Lilliput, where accesses to the Klass* also requires to decode the header, and figure out what bits means what. > > In addition to that, marking objects in their header requires that the original header gets saved and restored. We only do that for 'interesting' headers, that is headers that have a stack-lock, monitor or hash-code. All other headers are reset to their default value. This means we are losing object's GC age. This is not catastrophic, but nontheless interferes with GC. > > JFR already has a datastructure called BitSet to support object marking without messing with object's headers. We can use that in JVMTI too. > > Testing: > - [x] tier1 > - [x] tier2 > - [x] tier3 > - [x] serviceability/jvmti > - [x] vmTestbase/nsk/jvmti Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: - Merge branch 'master' into JDK-8283710 - Move JFRBitSet typedef into its own header; Make _bitset a direct member, not dynamically allocated - Add comment describing ObjectBitSet - Refactor JVMTI usage of ObjectBitSet - Typedef ObjectBitSet to JFRBitSet in JFR code - Rename BitSet to ObjectBitSet - Templatize BitSet for MEMFLAGS - Rename ObjectMarkerController -> ObjectMarker - Use (former JFR) BitSet for JVMTI object marking - Restore missing include - ... and 2 more: https://git.openjdk.java.net/jdk/compare/0a026759...9ea51d78 ------------- Changes: https://git.openjdk.java.net/jdk/pull/7964/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7964&range=06 Stats: 774 lines in 12 files changed: 326 ins; 427 del; 21 mod Patch: https://git.openjdk.java.net/jdk/pull/7964.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7964/head:pull/7964 PR: https://git.openjdk.java.net/jdk/pull/7964 From rkennke at openjdk.java.net Fri Apr 8 17:37:03 2022 From: rkennke at openjdk.java.net (Roman Kennke) Date: Fri, 8 Apr 2022 17:37:03 GMT Subject: RFR: 8283710: JVMTI: Use BitSet for object marking [v6] In-Reply-To: References: Message-ID: <7Yp8cUNVVqIC0wjJukhd5zQPu4UKJbW2BrExokwzllA=.ea44e9cc-8afc-47fa-bffa-0e5882ec70b0@github.com> On Fri, 8 Apr 2022 17:00:19 GMT, Thomas Stuefe wrote: > > > We must call new on it somewhere. I am not opposed to making this an mtFlags template then. This is a small point in this improvement. > > > > > > Yes, at some point we need to allocate the fragments and fragments table. We could _perhaps_ work around it by passing MEMFLAGS as constexpr, but I don't think this would change generated code much. > > (all bikeshedding since we all agree the current version is fine, no?) > > No, sorry, I meant make BitSet a normal class. Not derived from CHeapObj, since it gets not newed, only used via composition or on a stack. And give it a runtime parm to set the MEMFLAG. > > So: > > ``` > class BitSet { > const MEMFLAGS _flags; > public: > BitSet(MEMFLAGS f = mtInternal) : _flags(f) {...} > }; > ``` > > and use those flags for the c-heap allocation of the fragments. Yes, I get that. But the fragments and fragment-table are themselves inner classes that take a MEMFLAGS template. I could (perhaps) either use a constexpr MEMFLAGS arg and pass this through, or do at some point a switch like: switch (_flags) { case mtServiceability: ... new BitMapFragmentTable(); break; case mtServiceability: ... new BitMapFragmentTable(); break; default: ShouldNotReachHere(); } Which seems kinda-ugly but would work (I think), and avoid making the outer class template-ized. ------------- PR: https://git.openjdk.java.net/jdk/pull/7964 From sviswanathan at openjdk.java.net Fri Apr 8 18:34:10 2022 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Fri, 8 Apr 2022 18:34:10 GMT Subject: RFR: 8282221: x86 intrinsics for divideUnsigned and remainderUnsigned methods in java.lang.Integer and java.lang.Long [v12] In-Reply-To: References: Message-ID: On Fri, 8 Apr 2022 01:05:33 GMT, Srinivas Vamsi Parasa wrote: >> Optimizes the divideUnsigned() and remainderUnsigned() methods in java.lang.Integer and java.lang.Long classes using x86 intrinsics. This change shows 3x improvement for Integer methods and upto 25% improvement for Long. This change also implements the DivMod optimization which fuses division and modulus operations if needed. The DivMod optimization shows 3x improvement for Integer and ~65% improvement for Long. > > Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision: > > uncomment zero in integer div, mod test My suggestion is to keep the -ve path assembly optimization in this patch. When the optimization in IR is introduced, the assembly could then be simplified as suggested by @merykitty. ------------- PR: https://git.openjdk.java.net/jdk/pull/7572 From duke at openjdk.java.net Fri Apr 8 18:39:59 2022 From: duke at openjdk.java.net (farhankhan04) Date: Fri, 8 Apr 2022 18:39:59 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) In-Reply-To: References: Message-ID: <27Nx03MrIUd1fTR-T3GAGvt6aaX5_P-RUUVzd4pOgGE=.0194757d-30c9-48ec-bc6b-10195d39cfea@github.com> On Fri, 8 Apr 2022 13:43:39 GMT, Alan Bateman wrote: > This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. > > We will refresh this PR periodically to pick up changes and fixes from the loom repo. > > Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. > > The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. > > There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. > > The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. > > The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. Marked as reviewed by farhankhan04 at github.com (no known OpenJDK username). ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From kvn at openjdk.java.net Fri Apr 8 19:37:44 2022 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 8 Apr 2022 19:37:44 GMT Subject: RFR: 8282221: x86 intrinsics for divideUnsigned and remainderUnsigned methods in java.lang.Integer and java.lang.Long [v12] In-Reply-To: References: Message-ID: On Fri, 8 Apr 2022 18:32:06 GMT, Sandhya Viswanathan wrote: > My suggestion is to keep the -ve path assembly optimization in this patch. > When the optimization in IR is introduced, the assembly could then be simplified as suggested by @merykitty. Okay. Lets do that as part of JDK-8282365. ------------- PR: https://git.openjdk.java.net/jdk/pull/7572 From duke at openjdk.java.net Fri Apr 8 22:17:23 2022 From: duke at openjdk.java.net (Srinivas Vamsi Parasa) Date: Fri, 8 Apr 2022 22:17:23 GMT Subject: RFR: 8282221: x86 intrinsics for divideUnsigned and remainderUnsigned methods in java.lang.Integer and java.lang.Long [v13] In-Reply-To: References: Message-ID: > Optimizes the divideUnsigned() and remainderUnsigned() methods in java.lang.Integer and java.lang.Long classes using x86 intrinsics. This change shows 3x improvement for Integer methods and upto 25% improvement for Long. This change also implements the DivMod optimization which fuses division and modulus operations if needed. The DivMod optimization shows 3x improvement for Integer and ~65% improvement for Long. Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision: Fix the divmod crash due to lack of control node ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7572/files - new: https://git.openjdk.java.net/jdk/pull/7572/files/3e3fc977..a71ea238 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7572&range=12 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7572&range=11-12 Stats: 8 lines in 2 files changed: 0 ins; 4 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/7572.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7572/head:pull/7572 PR: https://git.openjdk.java.net/jdk/pull/7572 From duke at openjdk.java.net Fri Apr 8 22:17:23 2022 From: duke at openjdk.java.net (Srinivas Vamsi Parasa) Date: Fri, 8 Apr 2022 22:17:23 GMT Subject: RFR: 8282221: x86 intrinsics for divideUnsigned and remainderUnsigned methods in java.lang.Integer and java.lang.Long [v8] In-Reply-To: References: Message-ID: On Fri, 8 Apr 2022 00:55:50 GMT, Srinivas Vamsi Parasa wrote: >> I have few comments. > > Hi Vladimir (@vnkozlov), > > Incorporated all the suggestions you made in the previous review and pushed a new commit. > Please let me know if anything else is needed. > > Thanks, > Vamsi > @vamsi-parasa I got failures in new tests when run with `-XX:UseAVX=3 -XX:+UnlockDiagnosticVMOptions -XX:+UseKNLSetting ` flags: > > ``` > # A fatal error has been detected by the Java Runtime Environment: > # > # SIGFPE (0x8) at pc=0x00007f2fa8c674ea, pid=3334, tid=3335 > # > # JRE version: Java(TM) SE Runtime Environment (19.0) (fastdebug build 19-internal-2022-04-08-0157190.vladimir.kozlov.jdkgit) > # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 19-internal-2022-04-08-0157190.vladimir.kozlov.jdkgit, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64) > # Problematic frame: > # J 504% c2 compiler.intrinsics.TestLongUnsignedDivMod.testDivideUnsigned()V (48 bytes) @ 0x00007f2fa8c674ea [0x00007f2fa8c672a0+0x000000000000024a] > # > ``` > > ``` > # A fatal error has been detected by the Java Runtime Environment: > # > # SIGFPE (0x8) at pc=0x00007fb8c0c4fb18, pid=3309, tid=3310 > # > # JRE version: Java(TM) SE Runtime Environment (19.0) (fastdebug build 19-internal-2022-04-08-0157190.vladimir.kozlov.jdkgit) > # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 19-internal-2022-04-08-0157190.vladimir.kozlov.jdkgit, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64) > # Problematic frame: > # J 445 c2 compiler.intrinsics.TestIntegerUnsignedDivMod.divmod(III)V (23 bytes) @ 0x00007fb8c0c4fb18 [0x00007fb8c0c4fae0+0x0000000000000038] > # > ``` Hi Vladimir (@vnkozlov), fixed it in the new commit, could you pls check? This is being caused by lack of control() node in udiv/umod related nodes. After adding the control() node, the tests are passing for me. Thanks for pointing this out! ------------- PR: https://git.openjdk.java.net/jdk/pull/7572 From kvn at openjdk.java.net Fri Apr 8 22:33:52 2022 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 8 Apr 2022 22:33:52 GMT Subject: RFR: 8282221: x86 intrinsics for divideUnsigned and remainderUnsigned methods in java.lang.Integer and java.lang.Long [v13] In-Reply-To: References: Message-ID: On Fri, 8 Apr 2022 22:17:23 GMT, Srinivas Vamsi Parasa wrote: >> Optimizes the divideUnsigned() and remainderUnsigned() methods in java.lang.Integer and java.lang.Long classes using x86 intrinsics. This change shows 3x improvement for Integer methods and upto 25% improvement for Long. This change also implements the DivMod optimization which fuses division and modulus operations if needed. The DivMod optimization shows 3x improvement for Integer and ~65% improvement for Long. > > Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision: > > Fix the divmod crash due to lack of control node I submitted new testing. ------------- PR: https://git.openjdk.java.net/jdk/pull/7572 From sviswanathan at openjdk.java.net Sat Apr 9 00:13:38 2022 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Sat, 9 Apr 2022 00:13:38 GMT Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE with predicate feature In-Reply-To: References: Message-ID: On Wed, 30 Mar 2022 10:31:59 GMT, Xiaohong Gong wrote: > Currently the vector load with mask when the given index happens out of the array boundary is implemented with pure java scalar code to avoid the IOOBE (IndexOutOfBoundaryException). This is necessary for architectures that do not support the predicate feature. Because the masked load is implemented with a full vector load and a vector blend applied on it. And a full vector load will definitely cause the IOOBE which is not valid. However, for architectures that support the predicate feature like SVE/AVX-512/RVV, it can be vectorized with the predicated load instruction as long as the indexes of the masked lanes are within the bounds of the array. For these architectures, loading with unmasked lanes does not raise exception. > > This patch adds the vectorization support for the masked load with IOOBE part. Please see the original java implementation (FIXME: optimize): > > > @ForceInline > public static > ByteVector fromArray(VectorSpecies species, > byte[] a, int offset, > VectorMask m) { > ByteSpecies vsp = (ByteSpecies) species; > if (offset >= 0 && offset <= (a.length - species.length())) { > return vsp.dummyVector().fromArray0(a, offset, m); > } > > // FIXME: optimize > checkMaskFromIndexSize(offset, vsp, m, 1, a.length); > return vsp.vOp(m, i -> a[offset + i]); > } > > Since it can only be vectorized with the predicate load, the hotspot must check whether the current backend supports it and falls back to the java scalar version if not. This is different from the normal masked vector load that the compiler will generate a full vector load and a vector blend if the predicate load is not supported. So to let the compiler make the expected action, an additional flag (i.e. `usePred`) is added to the existing "loadMasked" intrinsic, with the value "true" for the IOOBE part while "false" for the normal load. And the compiler will fail to intrinsify if the flag is "true" and the predicate load is not supported by the backend, which means that normal java path will be executed. > > Also adds the same vectorization support for masked: > - fromByteArray/fromByteBuffer > - fromBooleanArray > - fromCharArray > > The performance for the new added benchmarks improve about `1.88x ~ 30.26x` on the x86 AVX-512 system: > > Benchmark before After Units > LoadMaskedIOOBEBenchmark.byteLoadArrayMaskIOOBE 737.542 1387.069 ops/ms > LoadMaskedIOOBEBenchmark.doubleLoadArrayMaskIOOBE 118.366 330.776 ops/ms > LoadMaskedIOOBEBenchmark.floatLoadArrayMaskIOOBE 233.832 6125.026 ops/ms > LoadMaskedIOOBEBenchmark.intLoadArrayMaskIOOBE 233.816 7075.923 ops/ms > LoadMaskedIOOBEBenchmark.longLoadArrayMaskIOOBE 119.771 330.587 ops/ms > LoadMaskedIOOBEBenchmark.shortLoadArrayMaskIOOBE 431.961 939.301 ops/ms > > Similar performance gain can also be observed on 512-bit SVE system. src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java line 2861: > 2859: ByteSpecies vsp = (ByteSpecies) species; > 2860: if (offset >= 0 && offset <= (a.length - species.vectorByteSize())) { > 2861: return vsp.dummyVector().fromByteArray0(a, offset, m, /* usePred */ false).maybeSwap(bo); Instead of usePred a term like inRange or offetInRage or offsetInVectorRange would be easier to follow. ------------- PR: https://git.openjdk.java.net/jdk/pull/8035 From stuefe at openjdk.java.net Sat Apr 9 06:44:53 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Sat, 9 Apr 2022 06:44:53 GMT Subject: RFR: 8283710: JVMTI: Use BitSet for object marking [v6] In-Reply-To: <7Yp8cUNVVqIC0wjJukhd5zQPu4UKJbW2BrExokwzllA=.ea44e9cc-8afc-47fa-bffa-0e5882ec70b0@github.com> References: <7Yp8cUNVVqIC0wjJukhd5zQPu4UKJbW2BrExokwzllA=.ea44e9cc-8afc-47fa-bffa-0e5882ec70b0@github.com> Message-ID: On Fri, 8 Apr 2022 17:34:57 GMT, Roman Kennke wrote: > Yes, I get that. But the fragments and fragment-table are themselves inner classes that take a MEMFLAGS template. I could (perhaps) either use a constexpr MEMFLAGS arg and pass this through, or do at some point a switch like: > > ``` > switch (_flags) { > case mtServiceability: > ... new BitMapFragmentTable(); break; > case mtServiceability: > ... new BitMapFragmentTable(); break; > default: ShouldNotReachHere(); > } > ``` > > Which seems kinda-ugly but would work (I think), and avoid making the outer class template-ized. I see what you mean. This MEMFLAGS template parameter is deeply interwoven into everything. I'd just live with the current solution. It uses established pattern, so at least nobody is surprised. I think the basic problem is that CHeapObj itself is a template class. Rethinking MEMFLAGS seems worthwhile for a future RFE. As I wrote, one approach could be to make them a property of the current thread, and switchable and stackable via a Mark class. That way, everything allocated within a given range of frames would count toward a given category. No need to decide on a fine-granular basis. No need for templates. Maybe no need even to have a MEMFLAGS argument for every allocation. ------------- PR: https://git.openjdk.java.net/jdk/pull/7964 From duke at openjdk.java.net Sat Apr 9 06:53:42 2022 From: duke at openjdk.java.net (Furkan =?UTF-8?B?w5Z6bWVu?=) Date: Sat, 9 Apr 2022 06:53:42 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) In-Reply-To: References: Message-ID: On Fri, 8 Apr 2022 13:43:39 GMT, Alan Bateman wrote: > This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. > > We will refresh this PR periodically to pick up changes and fixes from the loom repo. > > Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. > > The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. > > There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. > > The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. > > The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. Marked as reviewed by furkannzmnn at github.com (no known OpenJDK username). Marked as reviewed by furkannzmnn at github.com (no known OpenJDK username). ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From kvn at openjdk.java.net Sat Apr 9 18:29:37 2022 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Sat, 9 Apr 2022 18:29:37 GMT Subject: RFR: 8282221: x86 intrinsics for divideUnsigned and remainderUnsigned methods in java.lang.Integer and java.lang.Long [v13] In-Reply-To: References: Message-ID: On Fri, 8 Apr 2022 22:17:23 GMT, Srinivas Vamsi Parasa wrote: >> Optimizes the divideUnsigned() and remainderUnsigned() methods in java.lang.Integer and java.lang.Long classes using x86 intrinsics. This change shows 3x improvement for Integer methods and upto 25% improvement for Long. This change also implements the DivMod optimization which fuses division and modulus operations if needed. The DivMod optimization shows 3x improvement for Integer and ~65% improvement for Long. > > Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision: > > Fix the divmod crash due to lack of control node Testing passed. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7572 From duke at openjdk.java.net Sun Apr 10 01:19:35 2022 From: duke at openjdk.java.net (ExE Boss) Date: Sun, 10 Apr 2022 01:19:35 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) In-Reply-To: References: Message-ID: On Fri, 8 Apr 2022 13:43:39 GMT, Alan Bateman wrote: > This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. > > We will refresh this PR periodically to pick up changes and fixes from the loom repo. > > Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. > > The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. > > There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. > > The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. > > The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. src/java.base/share/classes/java/lang/Runnable.java line 31: > 29: * Represents an operation that does not return a result. > 30: * > 31: *

This is a functional interface This?is?supposed to?point to?the?`package?summary.html` of?`java.util.function`, so?it?should?be: Suggestion: *

This is a functional interface or Suggestion: *

This is a {@linkplain java.util.function functional interface} ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From duke at openjdk.java.net Sun Apr 10 03:36:46 2022 From: duke at openjdk.java.net (Srinivas Vamsi Parasa) Date: Sun, 10 Apr 2022 03:36:46 GMT Subject: RFR: 8282221: x86 intrinsics for divideUnsigned and remainderUnsigned methods in java.lang.Integer and java.lang.Long [v13] In-Reply-To: References: Message-ID: <32_WRVZn9x-znpjO70MY_BZoQT8oRSRdSjtSfhvlzzE=.9ab1fcfa-fb70-4a2a-af25-6ed456b53827@github.com> On Sat, 9 Apr 2022 18:25:54 GMT, Vladimir Kozlov wrote: > Testing passed. Thank you Vladimir! ------------- PR: https://git.openjdk.java.net/jdk/pull/7572 From duke at openjdk.java.net Sun Apr 10 03:49:47 2022 From: duke at openjdk.java.net (Srinivas Vamsi Parasa) Date: Sun, 10 Apr 2022 03:49:47 GMT Subject: Integrated: 8282221: x86 intrinsics for divideUnsigned and remainderUnsigned methods in java.lang.Integer and java.lang.Long In-Reply-To: References: Message-ID: On Tue, 22 Feb 2022 09:24:47 GMT, Srinivas Vamsi Parasa wrote: > Optimizes the divideUnsigned() and remainderUnsigned() methods in java.lang.Integer and java.lang.Long classes using x86 intrinsics. This change shows 3x improvement for Integer methods and upto 25% improvement for Long. This change also implements the DivMod optimization which fuses division and modulus operations if needed. The DivMod optimization shows 3x improvement for Integer and ~65% improvement for Long. This pull request has now been integrated. Changeset: 37e28aea Author: vamsi-parasa Committer: Jatin Bhateja URL: https://git.openjdk.java.net/jdk/commit/37e28aea27c8d8336ddecde777e63b51a939d281 Stats: 1156 lines in 20 files changed: 1154 ins; 1 del; 1 mod 8282221: x86 intrinsics for divideUnsigned and remainderUnsigned methods in java.lang.Integer and java.lang.Long Reviewed-by: sviswanathan, kvn, jbhateja ------------- PR: https://git.openjdk.java.net/jdk/pull/7572 From duke at openjdk.java.net Sun Apr 10 06:50:47 2022 From: duke at openjdk.java.net (Srinivas Vamsi Parasa) Date: Sun, 10 Apr 2022 06:50:47 GMT Subject: RFR: 8282221: x86 intrinsics for divideUnsigned and remainderUnsigned methods in java.lang.Integer and java.lang.Long [v4] In-Reply-To: References: Message-ID: On Wed, 6 Apr 2022 06:23:47 GMT, Jatin Bhateja wrote: >>> Also need a jtreg test for this. >> >> Thanks Sandhya for the review. Made the suggested changes and added jtreg tests as well. > > Hi @vamsi-parasa , thanks for addressing my comments, looks good to me otherwise apart from the outstanding comments. @jatin-bhateja Thank you Jatin! ------------- PR: https://git.openjdk.java.net/jdk/pull/7572 From stuefe at openjdk.java.net Sun Apr 10 08:32:01 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Sun, 10 Apr 2022 08:32:01 GMT Subject: RFR: JDK-8283326: Implement SafeFetch statically Message-ID: Hi, This is a reimplementation of SafeFetch to get rid of dynamic code generation. This is done, depending on platform, via static assembly, Posix setjmp/longjmp or SEH. This is based on a proposal by @theRealAph [1] when discussing [JDK-8282475](https://bugs.openjdk.java.net/browse/JDK-8282475). I extended the proposal to do this for all platforms, not just MacOS, see discussion below. --- Why we do this: SafeFetch is special: it is a basic utility function that may be called before the VM is properly initialized, from a "foreign" thread not attached to the VM, in a broken environment... mainly this is due to its use during stack walking, error reporting, hex dumping, etc. SafeFetch has to be safe to call under any circumstances - or as safe as we can make it. Today, SafeFetch is implemented via stub routines. That causes problems: - MacOs aarch64 has mechanisms to prevent execution of arbitrary non-text memory. On that platform, invoking generated code requires some awkward gymnastics [2]. These workarounds require access to Thread::current, which renders SafeFetch non-functional if Thread::current is NULL (e.g. crash reporting in "foreign" native threads or in a corrupted VM). They also cost a bit of performance on every SafeFetch invocation. Note that more OSes may implement similar execution prevention mechanics in the future. - There is a time window during VM initialization where the stubs are not generated yet and thus SafeFetch is not available. Both points cause hs-err files to be compromised (e.g. missing call stacks) for crashes in native threads, when the VM is corrupted, or early during VM initialization. Since SafeFetch is such a basic tool, it causes more issues than that (e.g., on AIX it is used for verifying mprotect() itself). But hs-err files being compromised by secondary errors is the most annoying effect. A minor point is that generating stubs takes a tiny bit of startup time. Not a big issue, but anything we can generate at build time instead of at runtime is good. --- The patch: - Removes the SafeFetch stub routine generation for all platforms - For Linux and MacOS, it implements SafeFetch as cpu-specific static assembler routines. These routines live in `os_cpu/_/safefetch__.S`. - On Windows, SafeFetch is implemented via SEH. This is beautifully simple and does not need handwritten assembly at all. See `os/windows/safefetch_windows.hpp`. - On Zero, SafeFetch uses a Posix compatible solution using `sigsetjmp(2)`. This is portable and robust, but a bit slow compared to the other methods. Note that this solution existed before, and is well tested. I just moved the code around and massaged it a bit. - AIX uses now the same method as Zero. AIX "downgraded" in that sense from the stub routine solution, but since SAP gave up maintenance of AIX, I don't have easy access to AIX hardware. If SafeFetch speed becomes an issue, I am sure a solution based on static assembly can be implemented on AIX too. - The SafeFetch gtests were greatly expanded. Tests: - The patch was tested manually by building and running gtests on: - MacOS (x64, aarch64) - Linux (aarch64, arm, ppcle, s390, x64, x86, riscv) - Windows (x64 and x86, but not arm, see below) - AIX - Zero (on Linux x64). - GHAs - The patch ran through SAP nightlies for several nights in a row Note: - I have no access to Windows arm, so I could not test it. I contacted @mo-beck to verify that the patch works there. - I have no access to BSD. I am not sure who maintains BSD, so I have no idea who to contact. However, I believe the MacOS solution should work for BSD too. If not, BSD can simply fall back to the Posix sigjmp solution like AIX and Zero. It would be nice to have @RealLucy, @TheRealMDoerr and @theRealAph to okay s390, ppcle and aarch64 (and possibly arm32). Each assembly file is tiny, so it should not take long. @RealFYang and @backwaterred already tested the patch on RiscV and AIX (thanks). Thanks, Thomas [1] https://github.com/openjdk/jdk/pull/7727#issuecomment-1064980598 [2] https://github.com/openjdk/jdk/blob/4df67426ed02f18af0757897acb28b636a317a91/src/hotspot/share/runtime/safefetch.inline.hpp#L37-L41 ------------- Commit messages: - wip - static safefetch Changes: https://git.openjdk.java.net/jdk/pull/7865/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7865&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283326 Stats: 1546 lines in 38 files changed: 955 ins; 550 del; 41 mod Patch: https://git.openjdk.java.net/jdk/pull/7865.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7865/head:pull/7865 PR: https://git.openjdk.java.net/jdk/pull/7865 From kim.barrett at oracle.com Sun Apr 10 12:34:40 2022 From: kim.barrett at oracle.com (Kim Barrett) Date: Sun, 10 Apr 2022 12:34:40 +0000 Subject: RFR: 8283710: JVMTI: Use BitSet for object marking [v6] In-Reply-To: References: <7Yp8cUNVVqIC0wjJukhd5zQPu4UKJbW2BrExokwzllA=.ea44e9cc-8afc-47fa-bffa-0e5882ec70b0@github.com> Message-ID: > On Apr 9, 2022, at 2:44 AM, Thomas Stuefe wrote: > > On Fri, 8 Apr 2022 17:34:57 GMT, Roman Kennke wrote: > >> Yes, I get that. But the fragments and fragment-table are themselves inner classes that take a MEMFLAGS template. I could (perhaps) either use a constexpr MEMFLAGS arg and pass this through, or do at some point a switch like: >> >> ``` >> switch (_flags) { >> case mtServiceability: >> ... new BitMapFragmentTable(); break; >> case mtServiceability: >> ... new BitMapFragmentTable(); break; >> default: ShouldNotReachHere(); >> } >> ``` >> >> Which seems kinda-ugly but would work (I think), and avoid making the outer class template-ized. > > I see what you mean. This MEMFLAGS template parameter is deeply interwoven into everything. I'd just live with the current solution. It uses established pattern, so at least nobody is surprised. > > I think the basic problem is that CHeapObj itself is a template class. Rethinking MEMFLAGS seems worthwhile for a future RFE. As I wrote, one approach could be to make them a property of the current thread, and switchable and stackable via a Mark class. That way, everything allocated within a given range of frames would count toward a given category. No need to decide on a fine-granular basis. No need for templates. Maybe no need even to have a MEMFLAGS argument for every allocation. While working on something else I ran into a similar problem and found a different approach that seemed to work well. I?m planning to explore it in the context of CHeapObj, but haven?t gotten around to it yet. I should file an RFE in case someone else is interested. From ihse at openjdk.java.net Sun Apr 10 22:18:42 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Sun, 10 Apr 2022 22:18:42 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) In-Reply-To: References: Message-ID: On Fri, 8 Apr 2022 13:43:39 GMT, Alan Bateman wrote: > This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. > > We will refresh this PR periodically to pick up changes and fixes from the loom repo. > > Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. > > The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. > > There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. > > The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. > > The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. src/java.base/share/classes/jdk/internal/misc/StructureViolationExceptions.java line 81: > 79: Constructor ctor; > 80: try { > 81: Class exClass = Class.forName("jdk.incubator.concurrent.StructureViolationException"); Should this not be `jdk.internal.misc`? (Also, if this is the case, maybe there's a test missing that could have discovered this...) ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From dholmes at openjdk.java.net Mon Apr 11 02:04:47 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 11 Apr 2022 02:04:47 GMT Subject: RFR: 8282221: x86 intrinsics for divideUnsigned and remainderUnsigned methods in java.lang.Integer and java.lang.Long [v13] In-Reply-To: References: Message-ID: On Fri, 8 Apr 2022 22:17:23 GMT, Srinivas Vamsi Parasa wrote: >> Optimizes the divideUnsigned() and remainderUnsigned() methods in java.lang.Integer and java.lang.Long classes using x86 intrinsics. This change shows 3x improvement for Integer methods and upto 25% improvement for Long. This change also implements the DivMod optimization which fuses division and modulus operations if needed. The DivMod optimization shows 3x improvement for Integer and ~65% improvement for Long. > > Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision: > > Fix the divmod crash due to lack of control node This change appears to be causing crashes in tier4 - possibly Xcomp related: # assert(ctrl == kit.control()) failed: Control flow was added although the intrinsic bailed out I will file a new bug. ------------- PR: https://git.openjdk.java.net/jdk/pull/7572 From duke at openjdk.java.net Mon Apr 11 05:24:41 2022 From: duke at openjdk.java.net (Srinivas Vamsi Parasa) Date: Mon, 11 Apr 2022 05:24:41 GMT Subject: RFR: 8282221: x86 intrinsics for divideUnsigned and remainderUnsigned methods in java.lang.Integer and java.lang.Long [v13] In-Reply-To: References: Message-ID: On Mon, 11 Apr 2022 02:01:17 GMT, David Holmes wrote: > This change appears to be causing crashes in tier4 - possibly Xcomp related: > > # assert(ctrl == kit.control()) failed: Control flow was added although the intrinsic bailed out > I will file a new bug. Thank you for informing this issue! In order to reproduce the issue, I just kickstarted a tier4 run on a Xeon server. Will keep you updated. ------------- PR: https://git.openjdk.java.net/jdk/pull/7572 From dholmes at openjdk.java.net Mon Apr 11 06:27:48 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 11 Apr 2022 06:27:48 GMT Subject: RFR: JDK-8283326: Implement SafeFetch statically In-Reply-To: References: Message-ID: On Fri, 18 Mar 2022 08:52:46 GMT, Thomas Stuefe wrote: > Hi, > > This is a reimplementation of SafeFetch to get rid of dynamic code generation. This is done, depending on platform, via static assembly, Posix setjmp/longjmp or SEH. > > This is based on a proposal by @theRealAph [1] when discussing [JDK-8282475](https://bugs.openjdk.java.net/browse/JDK-8282475). I extended the proposal to do this for all platforms, not just MacOS, see discussion below. > > --- > > Why we do this: > > SafeFetch is special: it is a basic utility function that may be called before the VM is properly initialized, from a "foreign" thread not attached to the VM, in a broken environment... mainly this is due to its use during stack walking, error reporting, hex dumping, etc. SafeFetch has to be safe to call under any circumstances - or as safe as we can make it. > > Today, SafeFetch is implemented via stub routines. That causes problems: > > - MacOs aarch64 has mechanisms to prevent execution of arbitrary non-text memory. On that platform, invoking generated code requires some awkward gymnastics [2]. These workarounds require access to Thread::current, which renders SafeFetch non-functional if Thread::current is NULL (e.g. crash reporting in "foreign" native threads or in a corrupted VM). They also cost a bit of performance on every SafeFetch invocation. Note that more OSes may implement similar execution prevention mechanics in the future. > > - There is a time window during VM initialization where the stubs are not generated yet and thus SafeFetch is not available. > > Both points cause hs-err files to be compromised (e.g. missing call stacks) for crashes in native threads, when the VM is corrupted, or early during VM initialization. Since SafeFetch is such a basic tool, it causes more issues than that (e.g., on AIX it is used for verifying mprotect() itself). But hs-err files being compromised by secondary errors is the most annoying effect. > > A minor point is that generating stubs takes a tiny bit of startup time. Not a big issue, but anything we can generate at build time instead of at runtime is good. > > --- > > The patch: > > - Removes the SafeFetch stub routine generation for all platforms > - For Linux and MacOS, it implements SafeFetch as cpu-specific static assembler routines. These routines live in `os_cpu/_/safefetch__.S`. > - On Windows, SafeFetch is implemented via SEH. This is beautifully simple and does not need handwritten assembly at all. See `os/windows/safefetch_windows.hpp`. > - On Zero, SafeFetch uses a Posix compatible solution using `sigsetjmp(2)`. This is portable and robust, but a bit slow compared to the other methods. Note that this solution existed before, and is well tested. I just moved the code around and massaged it a bit. > - AIX uses now the same method as Zero. AIX "downgraded" in that sense from the stub routine solution, but since SAP gave up maintenance of AIX, I don't have easy access to AIX hardware. If SafeFetch speed becomes an issue, I am sure a solution based on static assembly can be implemented on AIX too. > - The SafeFetch gtests were greatly expanded. > > Tests: > > - The patch was tested manually by building and running gtests on: > - MacOS (x64, aarch64) > - Linux (aarch64, arm, ppcle, s390, x64, x86, riscv) > - Windows (x64 and x86, but not arm, see below) > - AIX > - Zero (on Linux x64). > - GHAs > - The patch ran through SAP nightlies for several nights in a row > > Note: > - I have no access to Windows arm, so I could not test it. I contacted @mo-beck to verify that the patch works there. > - I have no access to BSD. I am not sure who maintains BSD, so I have no idea who to contact. However, I believe the MacOS solution should work for BSD too. If not, BSD can simply fall back to the Posix sigjmp solution like AIX and Zero. > > It would be nice to have @RealLucy, @TheRealMDoerr and @theRealAph to okay s390, ppcle and aarch64 (and possibly arm32). Each assembly file is tiny, so it should not take long. @RealFYang and @backwaterred already tested the patch on RiscV and AIX (thanks). > > Thanks, Thomas > > [1] https://github.com/openjdk/jdk/pull/7727#issuecomment-1064980598 > [2] https://github.com/openjdk/jdk/blob/4df67426ed02f18af0757897acb28b636a317a91/src/hotspot/share/runtime/safefetch.inline.hpp#L37-L41 Hi Thomas, This looks really good! Definite approval in principle. I can't comment on the details of the .S files. A few nits and comments. Main is comment is that SAFEFETCH_METHOD_x defines don't seem to actually be needed ?? Thanks, David src/hotspot/os/posix/safefetch_sigjmp.cpp line 35: > 33: > 34: // For SafeFetch we need POSIX TLS and sigsetjmp/longjmp. > 35: // (Note: We would prefer compiler level TLS but for some reason __thread does not __thread cannot be safely used from a signal handler. src/hotspot/os/posix/safefetch_sigjmp.cpp line 88: > 86: > 87: // Still here... All went well, adr was valid. > 88: *result = n; Nit: if we are paranoid shouldn't we reset TLS before we write the result? src/hotspot/os/posix/safefetch_sigjmp.hpp line 27: > 25: > 26: #ifndef CPU_POSIX_SAFEFETCH_SIGJMP_HPP > 27: #define CPU_POSIX_SAFEFETCH_SIGJMP_HPP The include guard doesn't match the file name. src/hotspot/os/posix/signals_posix.cpp line 603: > 601: if (S390_ONLY(sig == SIGILL || sig == SIGFPE) NOT_S390(false)) { > 602: pc = (address)info->si_addr; > 603: } else if (ZERO_ONLY(true) NOT_ZERO(false)) { So on most platforms this will become: if (false) { ... } else if (false) { ... } I would expect compilers to complain about that. ?? Update: I see this code already exists so obviously the compilers don't complain. src/hotspot/os/posix/signals_posix.cpp line 614: > 612: } > 613: > 614: #if defined(SAFEFETCH_METHOD_STATIC_ASSEMBLY) || defined(SAFEFETCH_METHOD_SIGSETJMP) The guard seems unnecessary - all posix platforms need to handle safefetch here don't they? src/hotspot/os/posix/vmError_posix.cpp line 79: > 77: > 78: #if defined(SAFEFETCH_METHOD_STATIC_ASSEMBLY) || defined(SAFEFETCH_METHOD_SIGSETJMP) > 79: // Handle safefetch here too, to be able to use SafeFetc() inside the error handler Typo: SafeFetc() src/hotspot/os/windows/safefetch_windows.hpp line 46: > 44: > 45: inline int SafeFetch32(const int* adr, int errValue) { return SafeFetchXX(adr, errValue); } > 46: inline intptr_t SafeFetchN(const intptr_t* adr, intptr_t errValue) { return SafeFetchXX(adr, errValue); } Nit: these are hard to read on one long line, please use multi-lines. src/hotspot/share/runtime/os.hpp line 302: > 300: // platforms, usable as a compile-time constant. > 301: static const size_t max_page_size_crossplatform = 64 * K; // ppc has 64 K pages. > 302: What is this for?? src/hotspot/share/runtime/safefetch.hpp line 32: > 30: // Windows uses Structured Exception Handling > 31: #include "safefetch_windows.hpp" > 32: #define SAFEFETCH_METHOD_SEH This doesn't seem to be needed. src/hotspot/share/runtime/safefetch.hpp line 42: > 40: // All other platforms use static assembly > 41: #include "safefetch_static.hpp" > 42: #define SAFEFETCH_METHOD_STATIC_ASSEMBLY It seems to me that we don't actually need these SAFEFETCH_METHOD_x defines. ------------- Changes requested by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7865 From dholmes at openjdk.java.net Mon Apr 11 06:27:48 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 11 Apr 2022 06:27:48 GMT Subject: RFR: JDK-8283326: Implement SafeFetch statically In-Reply-To: References: Message-ID: On Mon, 11 Apr 2022 06:02:41 GMT, David Holmes wrote: >> Hi, >> >> This is a reimplementation of SafeFetch to get rid of dynamic code generation. This is done, depending on platform, via static assembly, Posix setjmp/longjmp or SEH. >> >> This is based on a proposal by @theRealAph [1] when discussing [JDK-8282475](https://bugs.openjdk.java.net/browse/JDK-8282475). I extended the proposal to do this for all platforms, not just MacOS, see discussion below. >> >> --- >> >> Why we do this: >> >> SafeFetch is special: it is a basic utility function that may be called before the VM is properly initialized, from a "foreign" thread not attached to the VM, in a broken environment... mainly this is due to its use during stack walking, error reporting, hex dumping, etc. SafeFetch has to be safe to call under any circumstances - or as safe as we can make it. >> >> Today, SafeFetch is implemented via stub routines. That causes problems: >> >> - MacOs aarch64 has mechanisms to prevent execution of arbitrary non-text memory. On that platform, invoking generated code requires some awkward gymnastics [2]. These workarounds require access to Thread::current, which renders SafeFetch non-functional if Thread::current is NULL (e.g. crash reporting in "foreign" native threads or in a corrupted VM). They also cost a bit of performance on every SafeFetch invocation. Note that more OSes may implement similar execution prevention mechanics in the future. >> >> - There is a time window during VM initialization where the stubs are not generated yet and thus SafeFetch is not available. >> >> Both points cause hs-err files to be compromised (e.g. missing call stacks) for crashes in native threads, when the VM is corrupted, or early during VM initialization. Since SafeFetch is such a basic tool, it causes more issues than that (e.g., on AIX it is used for verifying mprotect() itself). But hs-err files being compromised by secondary errors is the most annoying effect. >> >> A minor point is that generating stubs takes a tiny bit of startup time. Not a big issue, but anything we can generate at build time instead of at runtime is good. >> >> --- >> >> The patch: >> >> - Removes the SafeFetch stub routine generation for all platforms >> - For Linux and MacOS, it implements SafeFetch as cpu-specific static assembler routines. These routines live in `os_cpu/_/safefetch__.S`. >> - On Windows, SafeFetch is implemented via SEH. This is beautifully simple and does not need handwritten assembly at all. See `os/windows/safefetch_windows.hpp`. >> - On Zero, SafeFetch uses a Posix compatible solution using `sigsetjmp(2)`. This is portable and robust, but a bit slow compared to the other methods. Note that this solution existed before, and is well tested. I just moved the code around and massaged it a bit. >> - AIX uses now the same method as Zero. AIX "downgraded" in that sense from the stub routine solution, but since SAP gave up maintenance of AIX, I don't have easy access to AIX hardware. If SafeFetch speed becomes an issue, I am sure a solution based on static assembly can be implemented on AIX too. >> - The SafeFetch gtests were greatly expanded. >> >> Tests: >> >> - The patch was tested manually by building and running gtests on: >> - MacOS (x64, aarch64) >> - Linux (aarch64, arm, ppcle, s390, x64, x86, riscv) >> - Windows (x64 and x86, but not arm, see below) >> - AIX >> - Zero (on Linux x64). >> - GHAs >> - The patch ran through SAP nightlies for several nights in a row >> >> Note: >> - I have no access to Windows arm, so I could not test it. I contacted @mo-beck to verify that the patch works there. >> - I have no access to BSD. I am not sure who maintains BSD, so I have no idea who to contact. However, I believe the MacOS solution should work for BSD too. If not, BSD can simply fall back to the Posix sigjmp solution like AIX and Zero. >> >> It would be nice to have @RealLucy, @TheRealMDoerr and @theRealAph to okay s390, ppcle and aarch64 (and possibly arm32). Each assembly file is tiny, so it should not take long. @RealFYang and @backwaterred already tested the patch on RiscV and AIX (thanks). >> >> Thanks, Thomas >> >> [1] https://github.com/openjdk/jdk/pull/7727#issuecomment-1064980598 >> [2] https://github.com/openjdk/jdk/blob/4df67426ed02f18af0757897acb28b636a317a91/src/hotspot/share/runtime/safefetch.inline.hpp#L37-L41 > > src/hotspot/os/posix/vmError_posix.cpp line 79: > >> 77: >> 78: #if defined(SAFEFETCH_METHOD_STATIC_ASSEMBLY) || defined(SAFEFETCH_METHOD_SIGSETJMP) >> 79: // Handle safefetch here too, to be able to use SafeFetc() inside the error handler > > Typo: SafeFetc() Ditto regarding whether the guard is needed. ------------- PR: https://git.openjdk.java.net/jdk/pull/7865 From thartmann at openjdk.java.net Mon Apr 11 06:30:45 2022 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Mon, 11 Apr 2022 06:30:45 GMT Subject: RFR: 8282221: x86 intrinsics for divideUnsigned and remainderUnsigned methods in java.lang.Integer and java.lang.Long [v13] In-Reply-To: References: Message-ID: On Fri, 8 Apr 2022 22:17:23 GMT, Srinivas Vamsi Parasa wrote: >> Optimizes the divideUnsigned() and remainderUnsigned() methods in java.lang.Integer and java.lang.Long classes using x86 intrinsics. This change shows 3x improvement for Integer methods and upto 25% improvement for Long. This change also implements the DivMod optimization which fuses division and modulus operations if needed. The DivMod optimization shows 3x improvement for Integer and ~65% improvement for Long. > > Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision: > > Fix the divmod crash due to lack of control node The issue is easy to reproduce, see [JDK-8284635](https://bugs.openjdk.java.net/browse/JDK-8284635). ------------- PR: https://git.openjdk.java.net/jdk/pull/7572 From alanb at openjdk.java.net Mon Apr 11 07:16:45 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 11 Apr 2022 07:16:45 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) In-Reply-To: References: Message-ID: On Sun, 10 Apr 2022 00:40:02 GMT, ExE Boss wrote: > This?is?supposed to?point to?the?`package?summary.html` Thanks, this link is indeed wrong. Will be fixed when we refresh. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From alanb at openjdk.java.net Mon Apr 11 07:16:45 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 11 Apr 2022 07:16:45 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) In-Reply-To: References: Message-ID: On Sun, 10 Apr 2022 22:14:41 GMT, Magnus Ihse Bursie wrote: > Should this not be `jdk.internal.misc`? (Also, if this is the case, maybe there's a test missing that could have discovered this...) The exception is in an incubator module, it's just that code in java.base can't statically reference it. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From duke at openjdk.java.net Mon Apr 11 07:36:47 2022 From: duke at openjdk.java.net (ExE Boss) Date: Mon, 11 Apr 2022 07:36:47 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) In-Reply-To: References: Message-ID: On Mon, 11 Apr 2022 07:12:09 GMT, Alan Bateman wrote: >> src/java.base/share/classes/jdk/internal/misc/StructureViolationExceptions.java line 81: >> >>> 79: Constructor ctor; >>> 80: try { >>> 81: Class exClass = Class.forName("jdk.incubator.concurrent.StructureViolationException"); >> >> Should this not be `jdk.internal.misc`? (Also, if this is the case, maybe there's a test missing that could have discovered this...) > >> Should this not be `jdk.internal.misc`? (Also, if this is the case, maybe there's a test missing that could have discovered this...) > > The exception is in an incubator module, it's just that code in java.base can't statically reference it. Maybe it?should?use a?`MethodHandle` fetched?using `IMPL_LOOKUP` instead, in?order to?avoid the?runtime?overhead of?going through `CallerSensitive` methods (`Class.forName` and?`Constructor.newInstance`). It?should?probably also?be?cached. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From alanb at openjdk.java.net Mon Apr 11 07:43:46 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 11 Apr 2022 07:43:46 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) In-Reply-To: References: Message-ID: On Mon, 11 Apr 2022 07:33:20 GMT, ExE Boss wrote: > Maybe it?should?use a?`MethodHandle` fetched?using `IMPL_LOOKUP` instead, in?order to?avoid the?runtime?overhead of?going through `CallerSensitive` methods (`Class.forName` and?`Constructor.newInstance`). > > It?should?probably also?be?cached. It is cached. It's also a very exceptional case that only arises when the SC API (separate JEP, not here) is used incorrectly. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From duke at openjdk.java.net Mon Apr 11 08:46:43 2022 From: duke at openjdk.java.net (KIRIYAMA Takuya) Date: Mon, 11 Apr 2022 08:46:43 GMT Subject: RFR: 8280761: UseCompressedOops should be set after limit_heap_by_allocatable_memory [v3] In-Reply-To: References: Message-ID: <0fkb1Ur3CZmL_I33ijMC8pv1G5vQIyX6HUOI60Ua4ZA=.82dcfcbe-52a6-49e8-a40b-5ae44ea431db@github.com> On Fri, 8 Apr 2022 09:16:39 GMT, Thomas Schatzl wrote: > This looks like an additional (unrelated) test to make sure it is overridden if necessary imho. That is correct. Do you mean that the following code should be removed? `checkFlag(128 * oneG, 100, true, true);` ------------- PR: https://git.openjdk.java.net/jdk/pull/7938 From stuefe at openjdk.java.net Mon Apr 11 09:07:36 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 11 Apr 2022 09:07:36 GMT Subject: RFR: JDK-8283326: Implement SafeFetch statically In-Reply-To: References: Message-ID: On Mon, 11 Apr 2022 05:52:15 GMT, David Holmes wrote: >> Hi, >> >> This is a reimplementation of SafeFetch to get rid of dynamic code generation. This is done, depending on platform, via static assembly, Posix setjmp/longjmp or SEH. >> >> This is based on a proposal by @theRealAph [1] when discussing [JDK-8282475](https://bugs.openjdk.java.net/browse/JDK-8282475). I extended the proposal to do this for all platforms, not just MacOS, see discussion below. >> >> --- >> >> Why we do this: >> >> SafeFetch is special: it is a basic utility function that may be called before the VM is properly initialized, from a "foreign" thread not attached to the VM, in a broken environment... mainly this is due to its use during stack walking, error reporting, hex dumping, etc. SafeFetch has to be safe to call under any circumstances - or as safe as we can make it. >> >> Today, SafeFetch is implemented via stub routines. That causes problems: >> >> - MacOs aarch64 has mechanisms to prevent execution of arbitrary non-text memory. On that platform, invoking generated code requires some awkward gymnastics [2]. These workarounds require access to Thread::current, which renders SafeFetch non-functional if Thread::current is NULL (e.g. crash reporting in "foreign" native threads or in a corrupted VM). They also cost a bit of performance on every SafeFetch invocation. Note that more OSes may implement similar execution prevention mechanics in the future. >> >> - There is a time window during VM initialization where the stubs are not generated yet and thus SafeFetch is not available. >> >> Both points cause hs-err files to be compromised (e.g. missing call stacks) for crashes in native threads, when the VM is corrupted, or early during VM initialization. Since SafeFetch is such a basic tool, it causes more issues than that (e.g., on AIX it is used for verifying mprotect() itself). But hs-err files being compromised by secondary errors is the most annoying effect. >> >> A minor point is that generating stubs takes a tiny bit of startup time. Not a big issue, but anything we can generate at build time instead of at runtime is good. >> >> --- >> >> The patch: >> >> - Removes the SafeFetch stub routine generation for all platforms >> - For Linux and MacOS, it implements SafeFetch as cpu-specific static assembler routines. These routines live in `os_cpu/_/safefetch__.S`. >> - On Windows, SafeFetch is implemented via SEH. This is beautifully simple and does not need handwritten assembly at all. See `os/windows/safefetch_windows.hpp`. >> - On Zero, SafeFetch uses a Posix compatible solution using `sigsetjmp(2)`. This is portable and robust, but a bit slow compared to the other methods. Note that this solution existed before, and is well tested. I just moved the code around and massaged it a bit. >> - AIX uses now the same method as Zero. AIX "downgraded" in that sense from the stub routine solution, but since SAP gave up maintenance of AIX, I don't have easy access to AIX hardware. If SafeFetch speed becomes an issue, I am sure a solution based on static assembly can be implemented on AIX too. >> - The SafeFetch gtests were greatly expanded. >> >> Tests: >> >> - The patch was tested manually by building and running gtests on: >> - MacOS (x64, aarch64) >> - Linux (aarch64, arm, ppcle, s390, x64, x86, riscv) >> - Windows (x64 and x86, but not arm, see below) >> - AIX >> - Zero (on Linux x64). >> - GHAs >> - The patch ran through SAP nightlies for several nights in a row >> >> Note: >> - I have no access to Windows arm, so I could not test it. I contacted @mo-beck to verify that the patch works there. >> - I have no access to BSD. I am not sure who maintains BSD, so I have no idea who to contact. However, I believe the MacOS solution should work for BSD too. If not, BSD can simply fall back to the Posix sigjmp solution like AIX and Zero. >> >> It would be nice to have @RealLucy, @TheRealMDoerr and @theRealAph to okay s390, ppcle and aarch64 (and possibly arm32). Each assembly file is tiny, so it should not take long. @RealFYang and @backwaterred already tested the patch on RiscV and AIX (thanks). >> >> Thanks, Thomas >> >> [1] https://github.com/openjdk/jdk/pull/7727#issuecomment-1064980598 >> [2] https://github.com/openjdk/jdk/blob/4df67426ed02f18af0757897acb28b636a317a91/src/hotspot/share/runtime/safefetch.inline.hpp#L37-L41 > > src/hotspot/os/posix/safefetch_sigjmp.cpp line 35: > >> 33: >> 34: // For SafeFetch we need POSIX TLS and sigsetjmp/longjmp. >> 35: // (Note: We would prefer compiler level TLS but for some reason __thread does not > > __thread cannot be safely used from a signal handler. Ah, that explains the weird errors I got. I'll change the comment. ------------- PR: https://git.openjdk.java.net/jdk/pull/7865 From jbhateja at openjdk.java.net Mon Apr 11 09:08:41 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Mon, 11 Apr 2022 09:08:41 GMT Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE with predicate feature In-Reply-To: References: <35S4J_r9jBw_-SAow2oMYaSsTvubhSmZFVPb_VM6KEg=.7feff8fa-6e20-453e-aed6-e53c7d9beaad@github.com> <8Yu4J-PCYFJtBXrfgWoCbaR-7QZTXH4IzmXOf_lk164=.66071c45-1f1a-4931-a414-778f353c7e83@github.com> Message-ID: On Thu, 31 Mar 2022 03:53:15 GMT, Xiaohong Gong wrote: >> Yeah, maybe I misunderstood what you mean. So maybe the masked store `(store(src, m))` could be implemented with: >> >> 1) v1 = load >> 2) v2 = blend(load, src, m) >> 3) store(v2) >> >> Let's record this a JBS and fix it with a followed-up patch. Thanks! > > The optimization for masked store is recorded to: https://bugs.openjdk.java.net/browse/JDK-8284050 > The blend should be with the intended-to-store vector, so that masked lanes contain the need-to-store elements and unmasked lanes contain the loaded elements, which would be stored back, which results in unchanged values. It may not work if memory is beyond legal accessible address space of the process, a corner case could be a page boundary. Thus re-composing the intermediated vector which partially contains actual updates but effectively perform full vector write to destination address may not work in all scenarios. ------------- PR: https://git.openjdk.java.net/jdk/pull/8035 From stuefe at openjdk.java.net Mon Apr 11 09:12:33 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 11 Apr 2022 09:12:33 GMT Subject: RFR: JDK-8283326: Implement SafeFetch statically In-Reply-To: References: Message-ID: On Mon, 11 Apr 2022 06:00:12 GMT, David Holmes wrote: >> Hi, >> >> This is a reimplementation of SafeFetch to get rid of dynamic code generation. This is done, depending on platform, via static assembly, Posix setjmp/longjmp or SEH. >> >> This is based on a proposal by @theRealAph [1] when discussing [JDK-8282475](https://bugs.openjdk.java.net/browse/JDK-8282475). I extended the proposal to do this for all platforms, not just MacOS, see discussion below. >> >> --- >> >> Why we do this: >> >> SafeFetch is special: it is a basic utility function that may be called before the VM is properly initialized, from a "foreign" thread not attached to the VM, in a broken environment... mainly this is due to its use during stack walking, error reporting, hex dumping, etc. SafeFetch has to be safe to call under any circumstances - or as safe as we can make it. >> >> Today, SafeFetch is implemented via stub routines. That causes problems: >> >> - MacOs aarch64 has mechanisms to prevent execution of arbitrary non-text memory. On that platform, invoking generated code requires some awkward gymnastics [2]. These workarounds require access to Thread::current, which renders SafeFetch non-functional if Thread::current is NULL (e.g. crash reporting in "foreign" native threads or in a corrupted VM). They also cost a bit of performance on every SafeFetch invocation. Note that more OSes may implement similar execution prevention mechanics in the future. >> >> - There is a time window during VM initialization where the stubs are not generated yet and thus SafeFetch is not available. >> >> Both points cause hs-err files to be compromised (e.g. missing call stacks) for crashes in native threads, when the VM is corrupted, or early during VM initialization. Since SafeFetch is such a basic tool, it causes more issues than that (e.g., on AIX it is used for verifying mprotect() itself). But hs-err files being compromised by secondary errors is the most annoying effect. >> >> A minor point is that generating stubs takes a tiny bit of startup time. Not a big issue, but anything we can generate at build time instead of at runtime is good. >> >> --- >> >> The patch: >> >> - Removes the SafeFetch stub routine generation for all platforms >> - For Linux and MacOS, it implements SafeFetch as cpu-specific static assembler routines. These routines live in `os_cpu/_/safefetch__.S`. >> - On Windows, SafeFetch is implemented via SEH. This is beautifully simple and does not need handwritten assembly at all. See `os/windows/safefetch_windows.hpp`. >> - On Zero, SafeFetch uses a Posix compatible solution using `sigsetjmp(2)`. This is portable and robust, but a bit slow compared to the other methods. Note that this solution existed before, and is well tested. I just moved the code around and massaged it a bit. >> - AIX uses now the same method as Zero. AIX "downgraded" in that sense from the stub routine solution, but since SAP gave up maintenance of AIX, I don't have easy access to AIX hardware. If SafeFetch speed becomes an issue, I am sure a solution based on static assembly can be implemented on AIX too. >> - The SafeFetch gtests were greatly expanded. >> >> Tests: >> >> - The patch was tested manually by building and running gtests on: >> - MacOS (x64, aarch64) >> - Linux (aarch64, arm, ppcle, s390, x64, x86, riscv) >> - Windows (x64 and x86, but not arm, see below) >> - AIX >> - Zero (on Linux x64). >> - GHAs >> - The patch ran through SAP nightlies for several nights in a row >> >> Note: >> - I have no access to Windows arm, so I could not test it. I contacted @mo-beck to verify that the patch works there. >> - I have no access to BSD. I am not sure who maintains BSD, so I have no idea who to contact. However, I believe the MacOS solution should work for BSD too. If not, BSD can simply fall back to the Posix sigjmp solution like AIX and Zero. >> >> It would be nice to have @RealLucy, @TheRealMDoerr and @theRealAph to okay s390, ppcle and aarch64 (and possibly arm32). Each assembly file is tiny, so it should not take long. @RealFYang and @backwaterred already tested the patch on RiscV and AIX (thanks). >> >> Thanks, Thomas >> >> [1] https://github.com/openjdk/jdk/pull/7727#issuecomment-1064980598 >> [2] https://github.com/openjdk/jdk/blob/4df67426ed02f18af0757897acb28b636a317a91/src/hotspot/share/runtime/safefetch.inline.hpp#L37-L41 > > src/hotspot/os/posix/signals_posix.cpp line 603: > >> 601: if (S390_ONLY(sig == SIGILL || sig == SIGFPE) NOT_S390(false)) { >> 602: pc = (address)info->si_addr; >> 603: } else if (ZERO_ONLY(true) NOT_ZERO(false)) { > > So on most platforms this will become: > > > if (false) { > ... > } else if (false) { > ... > } > > > I would expect compilers to complain about that. ?? > > Update: I see this code already exists so obviously the compilers don't complain. An advantage of this style compared to ifdefs is that you compile all branches and catch build errors early... I admit it looks weird, and we don't usually do this. But since this code just moved, I'd like to leave it this way. ------------- PR: https://git.openjdk.java.net/jdk/pull/7865 From stuefe at openjdk.java.net Mon Apr 11 09:21:41 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 11 Apr 2022 09:21:41 GMT Subject: RFR: JDK-8283326: Implement SafeFetch statically In-Reply-To: References: Message-ID: On Mon, 11 Apr 2022 06:24:05 GMT, David Holmes wrote: > Hi Thomas, > > This looks really good! Definite approval in principle. I can't comment on the details of the .S files. A few nits and comments. Main is comment is that SAFEFETCH_METHOD_x defines don't seem to actually be needed ?? > > Thanks, David Thank you David! SAFEFETCH_METHOD_xx was supposed to be a clean separation between safefetch method and platform, since there is no clear 1:1 relation and you can, and may need to, mix and match. Examples: - On Posix platforms you can use either static assembly or setjmp, and need to exclude one of them from compilation - either build safefetch_xx_xx.S, or build safefetch_sigjmp.cpp. - On Windows, we use SEH, but I don't know yet if that works for Windows aarch64, and we still may need to switch to static assembly for this platform. I hope to avoid this though since MASM is a pain. Therefore I'd like to keep the separation between SafeFetch method and platform, at least for now. Makes it easer to switch back and forth, and I find it actually cleaner. Cheers Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/7865 From fweimer at openjdk.java.net Mon Apr 11 10:13:44 2022 From: fweimer at openjdk.java.net (Florian Weimer) Date: Mon, 11 Apr 2022 10:13:44 GMT Subject: RFR: JDK-8283326: Implement SafeFetch statically In-Reply-To: References: Message-ID: <8UpDSUrPORbSrYWpdlrFlw7gMzrCs36cNM-ij-7gSqU=.e51b5cbf-86d2-417d-813a-efabc4564075@github.com> On Mon, 11 Apr 2022 09:03:58 GMT, Thomas Stuefe wrote: >> src/hotspot/os/posix/safefetch_sigjmp.cpp line 35: >> >>> 33: >>> 34: // For SafeFetch we need POSIX TLS and sigsetjmp/longjmp. >>> 35: // (Note: We would prefer compiler level TLS but for some reason __thread does not >> >> __thread cannot be safely used from a signal handler. > > Ah, that explains the weird errors I got. I'll change the comment. `pthread_getspecific` and `pthread_setspecific` cannot be called from a signal handler, either. In particular, `pthread_setspecific` may call `malloc`. On GNU/Linux, if you use initial-exec TLS, it is fully async-signal-safe. Less so for the other variants. But maybe this does not matter because the assembler implementation uses `os::Posix::ucontext_set_pc` to redirect the execution in a more direction fashion? ------------- PR: https://git.openjdk.java.net/jdk/pull/7865 From fweimer at openjdk.java.net Mon Apr 11 10:13:46 2022 From: fweimer at openjdk.java.net (Florian Weimer) Date: Mon, 11 Apr 2022 10:13:46 GMT Subject: RFR: JDK-8283326: Implement SafeFetch statically In-Reply-To: References: Message-ID: On Fri, 18 Mar 2022 08:52:46 GMT, Thomas Stuefe wrote: > Hi, > > This is a reimplementation of SafeFetch to get rid of dynamic code generation. This is done, depending on platform, via static assembly, Posix setjmp/longjmp or SEH. > > This is based on a proposal by @theRealAph [1] when discussing [JDK-8282475](https://bugs.openjdk.java.net/browse/JDK-8282475). I extended the proposal to do this for all platforms, not just MacOS, see discussion below. > > --- > > Why we do this: > > SafeFetch is special: it is a basic utility function that may be called before the VM is properly initialized, from a "foreign" thread not attached to the VM, in a broken environment... mainly this is due to its use during stack walking, error reporting, hex dumping, etc. SafeFetch has to be safe to call under any circumstances - or as safe as we can make it. > > Today, SafeFetch is implemented via stub routines. That causes problems: > > - MacOs aarch64 has mechanisms to prevent execution of arbitrary non-text memory. On that platform, invoking generated code requires some awkward gymnastics [2]. These workarounds require access to Thread::current, which renders SafeFetch non-functional if Thread::current is NULL (e.g. crash reporting in "foreign" native threads or in a corrupted VM). They also cost a bit of performance on every SafeFetch invocation. Note that more OSes may implement similar execution prevention mechanics in the future. > > - There is a time window during VM initialization where the stubs are not generated yet and thus SafeFetch is not available. > > Both points cause hs-err files to be compromised (e.g. missing call stacks) for crashes in native threads, when the VM is corrupted, or early during VM initialization. Since SafeFetch is such a basic tool, it causes more issues than that (e.g., on AIX it is used for verifying mprotect() itself). But hs-err files being compromised by secondary errors is the most annoying effect. > > A minor point is that generating stubs takes a tiny bit of startup time. Not a big issue, but anything we can generate at build time instead of at runtime is good. > > --- > > The patch: > > - Removes the SafeFetch stub routine generation for all platforms > - For Linux and MacOS, it implements SafeFetch as cpu-specific static assembler routines. These routines live in `os_cpu/_/safefetch__.S`. > - On Windows, SafeFetch is implemented via SEH. This is beautifully simple and does not need handwritten assembly at all. See `os/windows/safefetch_windows.hpp`. > - On Zero, SafeFetch uses a Posix compatible solution using `sigsetjmp(2)`. This is portable and robust, but a bit slow compared to the other methods. Note that this solution existed before, and is well tested. I just moved the code around and massaged it a bit. > - AIX uses now the same method as Zero. AIX "downgraded" in that sense from the stub routine solution, but since SAP gave up maintenance of AIX, I don't have easy access to AIX hardware. If SafeFetch speed becomes an issue, I am sure a solution based on static assembly can be implemented on AIX too. > - The SafeFetch gtests were greatly expanded. > > Tests: > > - The patch was tested manually by building and running gtests on: > - MacOS (x64, aarch64) > - Linux (aarch64, arm, ppcle, s390, x64, x86, riscv) > - Windows (x64 and x86, but not arm, see below) > - AIX > - Zero (on Linux x64). > - GHAs > - The patch ran through SAP nightlies for several nights in a row > > Note: > - I have no access to Windows arm, so I could not test it. I contacted @mo-beck to verify that the patch works there. > - I have no access to BSD. I am not sure who maintains BSD, so I have no idea who to contact. However, I believe the MacOS solution should work for BSD too. If not, BSD can simply fall back to the Posix sigjmp solution like AIX and Zero. > > It would be nice to have @RealLucy, @TheRealMDoerr and @theRealAph to okay s390, ppcle and aarch64 (and possibly arm32). Each assembly file is tiny, so it should not take long. @RealFYang and @backwaterred already tested the patch on RiscV and AIX (thanks). > > Thanks, Thomas > > [1] https://github.com/openjdk/jdk/pull/7727#issuecomment-1064980598 > [2] https://github.com/openjdk/jdk/blob/4df67426ed02f18af0757897acb28b636a317a91/src/hotspot/share/runtime/safefetch.inline.hpp#L37-L41 src/hotspot/os/posix/safefetch_sigjmp.cpp line 85: > 83: > 84: // unsafe access > 85: n = *adr; Maybe this should use `*const_cast(adr)` to force the read? ------------- PR: https://git.openjdk.java.net/jdk/pull/7865 From dholmes at openjdk.java.net Mon Apr 11 10:40:36 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 11 Apr 2022 10:40:36 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v24] In-Reply-To: References: Message-ID: <-3pH-9NVTEgTBaWbZ05s8pSHxZZIwMFUlgxPpqvke8s=.2a1299f4-6bc4-46b1-8cea-181fb17e6f6a@github.com> On Mon, 4 Apr 2022 14:57:30 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.java.net/jeps/424 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Fix TestLinkToNativeRBP VM changes look good. Thanks, David src/hotspot/share/prims/scopedMemoryAccess.cpp line 141: > 139: > 140: /* > 141: * This function performs a thread-local handshake against all threads running at the time Nit: thread-local?? ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7888 From tschatzl at openjdk.java.net Mon Apr 11 10:48:34 2022 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Mon, 11 Apr 2022 10:48:34 GMT Subject: RFR: 8284435: Add dedicated filler objects for known dead Java heap areas [v2] In-Reply-To: References: Message-ID: > Hi all, > > can I have reviews for this change that adds dedicated filler objects to the VM? > > Currently, when formatting areas of dead objects all gcs use instances of j.l.Object and int-arrays. > > This has the drawback of not being easily able to discern whether a given object is actually dead (and should never be referenced) or just a regular j.l.Object/int array. > > This also makes enhanced error detection (any reference to such an object is an error - i.e. detecting references to such objects) and to skip potentially already unloaded classes when scanning areas of the heap below TAMS, G1 uses its prev bitmap. > Other collectors do not have this extra information at the moment, so they can't (and don't) do this kind of verification. > > With [JDK-8210708](https://bugs.openjdk.java.net/browse/JDK-8210708) the prev bitmap will effectively be removed in G1; G1 will format the dead areas with these filler objects to avoid coming across unloaded classes. This is fine wrt to normal operation, however, this looses the existing enhanced verification mentioned above. > > This change proposes to add dedicated VM-internal filler objects, i.e. equivalents of j.l.Object and int-arrays. > > This has the following benefits: > > - keep this error detection (actually making it much simpler) and allowing similar verification for other collectors. (This change does not add this) > > - this also makes it "easy" to detect references to filler objects in debugging tools - you only need to know the two klasses (or just get their friendly name) to see whether that reference may actually be valid (or refers to the inside such an object). References to these classes in the crash file may also allow the issue to be more clear. > > This causes some minor changes to external behavior: > > - logs/heap dumps now contain instances of these objects - which seems fine as previously they have just been reported as part of j.l.Object/int-arrays statistics. The VM spec also does not guarantee whether a particular kind of object should/should not show there anyway afaik. > > - if the application ever gets to instantiate a reference to such an object somehow, any enabled verification will crash the VM. That's bad luck for messing with internal classes, but that's the purpose of these objects. > > The change takes care that getting a reference will not be possible by normal means (i.e. via Class.forName() etc) - which should be sufficient to avoid the issue. Actually, existing mechanisms seem to be sufficient. > > > Testing: tier1-8 > > There is one question I would like the reviewers to specially think about, the name of the filler array klass. I just used `Ljava/internal/vm/FillerArray;` for that, looking at other internal symbols/klasses, but I'm not sure this adheres to naming guidelines. > > Thanks go to @iklam for helping out with the change. > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with two additional commits since the last revision: - iklam review - Test case ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8156/files - new: https://git.openjdk.java.net/jdk/pull/8156/files/9cee3295..b3e2c6c3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8156&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8156&range=00-01 Stats: 54 lines in 2 files changed: 53 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8156.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8156/head:pull/8156 PR: https://git.openjdk.java.net/jdk/pull/8156 From tschatzl at openjdk.java.net Mon Apr 11 10:48:35 2022 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Mon, 11 Apr 2022 10:48:35 GMT Subject: RFR: 8284435: Add dedicated filler objects for known dead Java heap areas [v2] In-Reply-To: References: Message-ID: <-NcmZgItAp7e1O6-7x25Zm_0_DjptadNlAxFtr9KiU4=.7fdcf257-ece4-4a83-b433-198bfd547ab6@github.com> On Fri, 8 Apr 2022 16:45:54 GMT, Ioi Lam wrote: >> Thomas Schatzl has updated the pull request incrementally with two additional commits since the last revision: >> >> - iklam review >> - Test case > > src/hotspot/share/classfile/systemDictionaryShared.cpp line 1727: > >> 1725: ArchivedMirrorPatcher::update_array_klasses(k); >> 1726: } >> 1727: ArchivedMirrorPatcher::update_array_klasses(Universe::fillerArrayKlassObj()); > > I think this is not necessary. `Universe::fillerArrayKlassObj()` shares the same mirror as `Universe::intArrayKlassObj()`, which has already been updated in the loop above. > > `ArchivedMirrorPatcher::update_array_klasses(k)` will essentially do `k->mirror->pointer_back_to_klass += delta`, so it will incorrectly set the pointer when delta is not zero. > > I would suggest running with > > > -XX:ArchiveRelocationMode=1 -Xlog:cds -Xlog:class+load=debug > > > and step into the following code: > > > void java_lang_Class::update_archived_mirror_native_pointers(oop archived_mirror) { > assert(MetaspaceShared::relocation_delta() != 0, "must be"); > > Klass* k = ((Klass*)archived_mirror->metadata_field(_klass_offset)); > archived_mirror->metadata_field_put(_klass_offset, > (Klass*)(address(k) + MetaspaceShared::relocation_delta())); <<<< HERE Stepping into that code (well, I added some logging) indicated that the mirrors for these klasses (`_fillerArrayKlassObj` and `intArrayKlassObj`) are different, so the field is not updated multiple times. So this code seems required, also because there are lots of crashes when removing the `ArchivedMirrorPatcher::update_array_klasses` call. (Say, if you print the `java_mirror()` after Universe initialization) The problem with the compiler we had (which was resolved by initializing the filler array before the int-array) was that in the component mirror, there is a reference to the arrayklass that represents an array of that basic type. So as the code earlier initialized the filler array klass after the int array klass, the compiler used the filler array klass for array instantiation which tests did not like. ------------- PR: https://git.openjdk.java.net/jdk/pull/8156 From rkennke at openjdk.java.net Mon Apr 11 11:55:33 2022 From: rkennke at openjdk.java.net (Roman Kennke) Date: Mon, 11 Apr 2022 11:55:33 GMT Subject: RFR: 8283710: JVMTI: Use BitSet for object marking [v8] In-Reply-To: References: Message-ID: > JVMTI heap walking marks objects in order to track which have been visited already. In order to do that, it uses bits in the object header. Those are the same bits that are also used by some GCs to mark objects (the lowest two bits, also used by locking code). Some GCs also use the bits in order to indicate 'forwarded' objects, where the upper bits of the header represent the forward-pointer. In the case of Shenandoah, it's even more problematic because this happens concurrently, even while JVMTI heap walks can intercept. So far we carefully worked around that problem, but it becomes very problematic in Lilliput, where accesses to the Klass* also requires to decode the header, and figure out what bits means what. > > In addition to that, marking objects in their header requires that the original header gets saved and restored. We only do that for 'interesting' headers, that is headers that have a stack-lock, monitor or hash-code. All other headers are reset to their default value. This means we are losing object's GC age. This is not catastrophic, but nontheless interferes with GC. > > JFR already has a datastructure called BitSet to support object marking without messing with object's headers. We can use that in JVMTI too. > > Testing: > - [x] tier1 > - [x] tier2 > - [x] tier3 > - [x] serviceability/jvmti > - [x] vmTestbase/nsk/jvmti Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: Add some basic tests for ObjectBitSet ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7964/files - new: https://git.openjdk.java.net/jdk/pull/7964/files/9ea51d78..b2d913b9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7964&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7964&range=06-07 Stats: 66 lines in 1 file changed: 66 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7964.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7964/head:pull/7964 PR: https://git.openjdk.java.net/jdk/pull/7964 From stuefe at openjdk.java.net Mon Apr 11 12:00:39 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 11 Apr 2022 12:00:39 GMT Subject: RFR: JDK-8283326: Implement SafeFetch statically In-Reply-To: <8UpDSUrPORbSrYWpdlrFlw7gMzrCs36cNM-ij-7gSqU=.e51b5cbf-86d2-417d-813a-efabc4564075@github.com> References: <8UpDSUrPORbSrYWpdlrFlw7gMzrCs36cNM-ij-7gSqU=.e51b5cbf-86d2-417d-813a-efabc4564075@github.com> Message-ID: On Mon, 11 Apr 2022 09:58:16 GMT, Florian Weimer wrote: >> Ah, that explains the weird errors I got. I'll change the comment. > > `pthread_getspecific` and `pthread_setspecific` cannot be called from a signal handler, either. In particular, `pthread_setspecific` may call `malloc`. > > On GNU/Linux, if you use initial-exec TLS, it is fully async-signal-safe. Less so for the other variants. But maybe this does not matter because the assembler implementation uses `os::Posix::ucontext_set_pc` to redirect the execution in a more direction fashion? @fweimer-rh I'll move `pthread_setspecific` out of signal handling, thanks for the hint. `pthread_getspecific` may not be signal safe, but it has been in use in JVM signal handlers for decades (signal handlers call `Thread::current`, which uses TLS) and it works in practice on all Posix platforms. ------------- PR: https://git.openjdk.java.net/jdk/pull/7865 From rkennke at openjdk.java.net Mon Apr 11 12:05:30 2022 From: rkennke at openjdk.java.net (Roman Kennke) Date: Mon, 11 Apr 2022 12:05:30 GMT Subject: RFR: 8283710: JVMTI: Use BitSet for object marking In-Reply-To: References: <7Yp8cUNVVqIC0wjJukhd5zQPu4UKJbW2BrExokwzllA=.ea44e9cc-8afc-47fa-bffa-0e5882ec70b0@github.com> Message-ID: On Sat, 9 Apr 2022 06:41:11 GMT, Thomas Stuefe wrote: >>> On Apr 9\, 2022\, at 2\:44 AM\, Thomas Stuefe \ wrote\: >>> >>> On Fri\, 8 Apr 2022 17\:34\:57 GMT\, Roman Kennke \ wrote\: >>> >>>> Yes\, I get that\. But the fragments and fragment\-table are themselves inner classes that take a MEMFLAGS template\. I could \(perhaps\) either use a constexpr MEMFLAGS arg and pass this through\, or do at some point a switch like\: >>>> >>>> \`\`\` >>>> switch \(\_flags\) \{ >>>> case mtServiceability\: >>>> \.\.\. new BitMapFragmentTable\\(\)\; break\; >>>> case mtServiceability\: >>>> \.\.\. new BitMapFragmentTable\\(\)\; break\; >>>> default\: ShouldNotReachHere\(\)\; >>>> \} >>>> \`\`\` >>>> >>>> Which seems kinda\-ugly but would work \(I think\)\, and avoid making the outer class template\-ized\. >>> >>> I see what you mean\. This MEMFLAGS template parameter is deeply interwoven into everything\. I\'d just live with the current solution\. It uses established pattern\, so at least nobody is surprised\. >>> >>> I think the basic problem is that CHeapObj itself is a template class\. Rethinking MEMFLAGS seems worthwhile for a future RFE\. As I wrote\, one approach could be to make them a property of the current thread\, and switchable and stackable via a Mark class\. That way\, everything allocated within a given range of frames would count toward a given category\. No need to decide on a fine\-granular basis\. No need for templates\. Maybe no need even to have a MEMFLAGS argument for every allocation\. >> >> While working on something else I ran into a similar problem and found a different >> approach that seemed to work well\. I\?m planning to explore it in the context of >> CHeapObj\, but haven\?t gotten around to it yet\. I should file an RFE in case someone >> else is interested\. > >> Yes, I get that. But the fragments and fragment-table are themselves inner classes that take a MEMFLAGS template. I could (perhaps) either use a constexpr MEMFLAGS arg and pass this through, or do at some point a switch like: >> >> ``` >> switch (_flags) { >> case mtServiceability: >> ... new BitMapFragmentTable(); break; >> case mtServiceability: >> ... new BitMapFragmentTable(); break; >> default: ShouldNotReachHere(); >> } >> ``` >> >> Which seems kinda-ugly but would work (I think), and avoid making the outer class template-ized. > > I see what you mean. This MEMFLAGS template parameter is deeply interwoven into everything. I'd just live with the current solution. It uses established pattern, so at least nobody is surprised. > > I think the basic problem is that CHeapObj itself is a template class. Rethinking MEMFLAGS seems worthwhile for a future RFE. As I wrote, one approach could be to make them a property of the current thread, and switchable and stackable via a Mark class. That way, everything allocated within a given range of frames would count toward a given category. No need to decide on a fine-granular basis. No need for templates. Maybe no need even to have a MEMFLAGS argument for every allocation. Have we reached a consensus that the current proposal is the way to go? If so, could you please mark the latest revision as Reviewed (again), @tstuefe and @coleenp (and whoever else feels like doing so)? I also added some basic gtests for ObjectBitSet. Please note my remark on the NULL test case. ------------- PR: https://git.openjdk.java.net/jdk/pull/7964 From mcimadamore at openjdk.java.net Mon Apr 11 12:07:34 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 11 Apr 2022 12:07:34 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v24] In-Reply-To: <-3pH-9NVTEgTBaWbZ05s8pSHxZZIwMFUlgxPpqvke8s=.2a1299f4-6bc4-46b1-8cea-181fb17e6f6a@github.com> References: <-3pH-9NVTEgTBaWbZ05s8pSHxZZIwMFUlgxPpqvke8s=.2a1299f4-6bc4-46b1-8cea-181fb17e6f6a@github.com> Message-ID: On Mon, 11 Apr 2022 10:33:54 GMT, David Holmes wrote: >> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix TestLinkToNativeRBP > > src/hotspot/share/prims/scopedMemoryAccess.cpp line 141: > >> 139: >> 140: /* >> 141: * This function performs a thread-local handshake against all threads running at the time > > Nit: thread-local?? I was assuming the term "thread-local handshake" was a thing in the VM, as per: https://openjdk.java.net/jeps/312 ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From eliu at openjdk.java.net Mon Apr 11 12:16:23 2022 From: eliu at openjdk.java.net (Eric Liu) Date: Mon, 11 Apr 2022 12:16:23 GMT Subject: RFR: 8282528: AArch64: Incorrect replicate2L_zero rule [v3] In-Reply-To: References: Message-ID: > This patch fixes the wrong matching rule of replicate2L_zero. It was > matched "ReplicateI" by mistake so that long immediates(not only zero) > had to be moved to register first and matched to replicate2L finally. To > fix this trivial bug, this patch fixes the typo and extends the rule of > replicate2L_zero to replicate2L_imm, which now supports all possible > long immediate values. > > The final code changes are shown as below: > > replicate2L_imm: > > mov x13, #0xff > movk x13, #0xff, lsl #16 > movk x13, #0xff, lsl #32 > dup v16.2d, x13 > > => > > movi v16.2d, #0xff00ff00ff > > [Test] > test/jdk/jdk/incubator/vector, test/hotspot/jtreg/compiler/vectorapi > passed without failure. Eric Liu has updated the pull request incrementally with one additional commit since the last revision: refine m4 file Change-Id: Ia2347e8b60aa0e4f026047006e6203e3b3d04383 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7939/files - new: https://git.openjdk.java.net/jdk/pull/7939/files/aa66f34b..19afc185 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7939&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7939&range=01-02 Stats: 51 lines in 2 files changed: 5 ins; 3 del; 43 mod Patch: https://git.openjdk.java.net/jdk/pull/7939.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7939/head:pull/7939 PR: https://git.openjdk.java.net/jdk/pull/7939 From eliu at openjdk.java.net Mon Apr 11 12:27:43 2022 From: eliu at openjdk.java.net (Eric Liu) Date: Mon, 11 Apr 2022 12:27:43 GMT Subject: RFR: 8282528: AArch64: Incorrect replicate2L_zero rule [v2] In-Reply-To: References: Message-ID: On Fri, 8 Apr 2022 09:09:18 GMT, Andrew Haley wrote: >> Eric Liu has updated the pull request incrementally with one additional commit since the last revision: >> >> fix comment >> >> Change-Id: Ic51820391d19b61e37847cc04375ecd79fc86779 > > src/hotspot/cpu/aarch64/aarch64_neon_ad.m4 line 1571: > >> 1569: `$3 $4', `I _imm', ` '$con$$constant, >> 1570: `$3 $4', `L _imm', ` '$con$$constant, >> 1571: `$6', vRegF,` > > This `ifelse` is rather confusing. Can't the '& 0xff' be passed as arguments into `VREPLICATE`? Done. I think these rules should not have been merged by force. It's hard to maintain. ------------- PR: https://git.openjdk.java.net/jdk/pull/7939 From coleenp at openjdk.java.net Mon Apr 11 12:36:43 2022 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Mon, 11 Apr 2022 12:36:43 GMT Subject: RFR: 8283710: JVMTI: Use BitSet for object marking [v8] In-Reply-To: References: Message-ID: On Mon, 11 Apr 2022 11:55:33 GMT, Roman Kennke wrote: >> JVMTI heap walking marks objects in order to track which have been visited already. In order to do that, it uses bits in the object header. Those are the same bits that are also used by some GCs to mark objects (the lowest two bits, also used by locking code). Some GCs also use the bits in order to indicate 'forwarded' objects, where the upper bits of the header represent the forward-pointer. In the case of Shenandoah, it's even more problematic because this happens concurrently, even while JVMTI heap walks can intercept. So far we carefully worked around that problem, but it becomes very problematic in Lilliput, where accesses to the Klass* also requires to decode the header, and figure out what bits means what. >> >> In addition to that, marking objects in their header requires that the original header gets saved and restored. We only do that for 'interesting' headers, that is headers that have a stack-lock, monitor or hash-code. All other headers are reset to their default value. This means we are losing object's GC age. This is not catastrophic, but nontheless interferes with GC. >> >> JFR already has a datastructure called BitSet to support object marking without messing with object's headers. We can use that in JVMTI too. >> >> Testing: >> - [x] tier1 >> - [x] tier2 >> - [x] tier3 >> - [x] serviceability/jvmti >> - [x] vmTestbase/nsk/jvmti > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Add some basic tests for ObjectBitSet I think this looks great and thank you for all your work resolving comments and bringing this in from the lilliput changes you were going to make. This is a big improvement imo and lets us potentially fix other problems in the jvmti tag map implementation. The template instantiation doesn't bother me. There's only 2 and it's not a big code bloat and it's the way the code has been dealing with memflags. Maybe the mechanism should be revisited, like the GC change that Kim pointed to, but I don't see the motivation to make it something different. Maybe a later RFE can propose a different mechanism for memflags in general. We picked this because we thought it was simple. Thank you for your work on this, Roman and your comments Thomas. test/hotspot/gtest/utilities/test_objectBitSet.cpp line 38: > 36: // allocate a fragement for the memory range starting at 0 and mark the first bit when passing NULL. > 37: // In the absense of any error handling, I am not sure what would possibly be a reasonable better > 38: // way to do it, though. Thanks for the comment. If it matters someday we'll have the comment.. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7964 From aph at openjdk.java.net Mon Apr 11 12:41:40 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Mon, 11 Apr 2022 12:41:40 GMT Subject: RFR: 8282528: AArch64: Incorrect replicate2L_zero rule [v2] In-Reply-To: References: Message-ID: On Mon, 11 Apr 2022 12:24:37 GMT, Eric Liu wrote: >> src/hotspot/cpu/aarch64/aarch64_neon_ad.m4 line 1571: >> >>> 1569: `$3 $4', `I _imm', ` '$con$$constant, >>> 1570: `$3 $4', `L _imm', ` '$con$$constant, >>> 1571: `$6', vRegF,` >> >> This `ifelse` is rather confusing. Can't the '& 0xff' be passed as arguments into `VREPLICATE`? > > Done. I think these rules should not have been merged by force. It's hard to maintain. It doesn't look too awful. Having said that, if I were you I'd get rid of all the `ifelse` expressions triggered by empty args. ------------- PR: https://git.openjdk.java.net/jdk/pull/7939 From stuefe at openjdk.java.net Mon Apr 11 12:43:47 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 11 Apr 2022 12:43:47 GMT Subject: RFR: 8283710: JVMTI: Use BitSet for object marking [v8] In-Reply-To: References: Message-ID: On Mon, 11 Apr 2022 11:55:33 GMT, Roman Kennke wrote: >> JVMTI heap walking marks objects in order to track which have been visited already. In order to do that, it uses bits in the object header. Those are the same bits that are also used by some GCs to mark objects (the lowest two bits, also used by locking code). Some GCs also use the bits in order to indicate 'forwarded' objects, where the upper bits of the header represent the forward-pointer. In the case of Shenandoah, it's even more problematic because this happens concurrently, even while JVMTI heap walks can intercept. So far we carefully worked around that problem, but it becomes very problematic in Lilliput, where accesses to the Klass* also requires to decode the header, and figure out what bits means what. >> >> In addition to that, marking objects in their header requires that the original header gets saved and restored. We only do that for 'interesting' headers, that is headers that have a stack-lock, monitor or hash-code. All other headers are reset to their default value. This means we are losing object's GC age. This is not catastrophic, but nontheless interferes with GC. >> >> JFR already has a datastructure called BitSet to support object marking without messing with object's headers. We can use that in JVMTI too. >> >> Testing: >> - [x] tier1 >> - [x] tier2 >> - [x] tier3 >> - [x] serviceability/jvmti >> - [x] vmTestbase/nsk/jvmti > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Add some basic tests for ObjectBitSet All good ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7964 From tschatzl at openjdk.java.net Mon Apr 11 13:36:52 2022 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Mon, 11 Apr 2022 13:36:52 GMT Subject: RFR: 8280761: UseCompressedOops should be set after limit_heap_by_allocatable_memory [v3] In-Reply-To: <0fkb1Ur3CZmL_I33ijMC8pv1G5vQIyX6HUOI60Ua4ZA=.82dcfcbe-52a6-49e8-a40b-5ae44ea431db@github.com> References: <0fkb1Ur3CZmL_I33ijMC8pv1G5vQIyX6HUOI60Ua4ZA=.82dcfcbe-52a6-49e8-a40b-5ae44ea431db@github.com> Message-ID: On Mon, 11 Apr 2022 08:43:41 GMT, KIRIYAMA Takuya wrote: >> This looks like an additional (unrelated) test to make sure it is overridden if necessary imho. It seems a bit forced though because there is no test that actually verifies that `UseCompressedOops` is `false` later. >> I'm good with removing the test case. > >> This looks like an additional (unrelated) test to make sure it is overridden if necessary imho. > > That is correct. > Do you mean that the following code should be removed? > > `checkFlag(128 * oneG, 100, true, true);` Yes. Removing this test case would limit the testing to the actual problem stated in the CR. Verifying that `UseCompressedOops` is enabled correctly is tested somewhere else already, and there is no reason that using `ulimit -v` would change that behavior. ------------- PR: https://git.openjdk.java.net/jdk/pull/7938 From lkorinth at openjdk.java.net Mon Apr 11 13:53:36 2022 From: lkorinth at openjdk.java.net (Leo Korinth) Date: Mon, 11 Apr 2022 13:53:36 GMT Subject: RFR: 8269537: memset() is called after operator new [v4] In-Reply-To: References: Message-ID: On Wed, 20 Oct 2021 09:36:38 GMT, Leo Korinth wrote: >> The basic problem is that we are relying on undefined behaviour, as documented in the code: >> >> // This whole business of passing information from ResourceObj::operator new >> // to the ResourceObj constructor via fields in the "object" is technically UB. >> // But it seems to work within the limitations of HotSpot usage (such as no >> // multiple inheritance) with the compilers and compiler options we're using. >> // And it gives some possibly useful checking for misuse of ResourceObj. >> >> >> I am removing the undefined behaviour by passing the type of allocation through a thread local variable. >> >> This solution has some advantages: >> 1) it is not UB >> 2) it is simpler and easier to understand >> 3) it uses less memory (I could make it use even less if I made the enum `allocation_type` a u8) >> 4) in the *very* unlikely situation that stack memory (or embedded) already equals the data calculated from the address of the object, the code will also work. >> >> When doing the change, I also updated `allocated_on_stack()` to the new name `allocated_on_stack_or_embedded()` which is much harder to misinterpret. >> >> I also disallow to "fake" the memory type by explicitly calling `ResourceObj::set_allocation_type`. >> >> This forced me to change two places that is faking the allocation type of an embedded `GrowableArray` from `STACK_OR_EMBEDDED` to `C_HEAP`. The faking of the type is hard to understand as a `STACK_OR_EMBEDDED` `GrowableArray` can allocate any type of object. My guess is that `GrowableArray` has changed behaviour, or maybe that it was hard to understand because the old naming of `allocated_on_stack()`. >> >> I have also tried to update the comments. In doing that I not only changed the comments for this change, but also for the *incorrect* advice to always delete object you allocate with new. >> >> Testing on debug build tier1-3 >> Testing on release build tier1 > > Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: > > review updates I would like to have this change approved, or the approval of removing tracking the allocation type altogether. I do not like having this pull request open any more. The current code is not okay. ------------- PR: https://git.openjdk.java.net/jdk/pull/5387 From rkennke at openjdk.java.net Mon Apr 11 14:54:45 2022 From: rkennke at openjdk.java.net (Roman Kennke) Date: Mon, 11 Apr 2022 14:54:45 GMT Subject: RFR: 8283710: JVMTI: Use BitSet for object marking [v8] In-Reply-To: References: Message-ID: <37wlmFUyNaJ8zPwBNjRaau9ugTNDEieR7SIVWnz0Pjs=.64f446b7-9e15-4752-9401-fa26326879db@github.com> On Mon, 11 Apr 2022 11:55:33 GMT, Roman Kennke wrote: >> JVMTI heap walking marks objects in order to track which have been visited already. In order to do that, it uses bits in the object header. Those are the same bits that are also used by some GCs to mark objects (the lowest two bits, also used by locking code). Some GCs also use the bits in order to indicate 'forwarded' objects, where the upper bits of the header represent the forward-pointer. In the case of Shenandoah, it's even more problematic because this happens concurrently, even while JVMTI heap walks can intercept. So far we carefully worked around that problem, but it becomes very problematic in Lilliput, where accesses to the Klass* also requires to decode the header, and figure out what bits means what. >> >> In addition to that, marking objects in their header requires that the original header gets saved and restored. We only do that for 'interesting' headers, that is headers that have a stack-lock, monitor or hash-code. All other headers are reset to their default value. This means we are losing object's GC age. This is not catastrophic, but nontheless interferes with GC. >> >> JFR already has a datastructure called BitSet to support object marking without messing with object's headers. We can use that in JVMTI too. >> >> Testing: >> - [x] tier1 >> - [x] tier2 >> - [x] tier3 >> - [x] serviceability/jvmti >> - [x] vmTestbase/nsk/jvmti > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Add some basic tests for ObjectBitSet Thank you all! GHA are green too, so I'll ------------- PR: https://git.openjdk.java.net/jdk/pull/7964 From rkennke at openjdk.java.net Mon Apr 11 14:54:46 2022 From: rkennke at openjdk.java.net (Roman Kennke) Date: Mon, 11 Apr 2022 14:54:46 GMT Subject: Integrated: 8283710: JVMTI: Use BitSet for object marking In-Reply-To: References: Message-ID: On Fri, 25 Mar 2022 20:10:32 GMT, Roman Kennke wrote: > JVMTI heap walking marks objects in order to track which have been visited already. In order to do that, it uses bits in the object header. Those are the same bits that are also used by some GCs to mark objects (the lowest two bits, also used by locking code). Some GCs also use the bits in order to indicate 'forwarded' objects, where the upper bits of the header represent the forward-pointer. In the case of Shenandoah, it's even more problematic because this happens concurrently, even while JVMTI heap walks can intercept. So far we carefully worked around that problem, but it becomes very problematic in Lilliput, where accesses to the Klass* also requires to decode the header, and figure out what bits means what. > > In addition to that, marking objects in their header requires that the original header gets saved and restored. We only do that for 'interesting' headers, that is headers that have a stack-lock, monitor or hash-code. All other headers are reset to their default value. This means we are losing object's GC age. This is not catastrophic, but nontheless interferes with GC. > > JFR already has a datastructure called BitSet to support object marking without messing with object's headers. We can use that in JVMTI too. > > Testing: > - [x] tier1 > - [x] tier2 > - [x] tier3 > - [x] serviceability/jvmti > - [x] vmTestbase/nsk/jvmti This pull request has now been integrated. Changeset: abfd2f98 Author: Roman Kennke URL: https://git.openjdk.java.net/jdk/commit/abfd2f98dcbe3e96efe52b1d66e4c2efb3542955 Stats: 840 lines in 13 files changed: 392 ins; 427 del; 21 mod 8283710: JVMTI: Use BitSet for object marking Reviewed-by: stuefe, coleenp ------------- PR: https://git.openjdk.java.net/jdk/pull/7964 From tschatzl at openjdk.java.net Mon Apr 11 14:55:32 2022 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Mon, 11 Apr 2022 14:55:32 GMT Subject: RFR: 8284435: Add dedicated filler objects for known dead Java heap areas [v3] In-Reply-To: References: Message-ID: > Hi all, > > can I have reviews for this change that adds dedicated filler objects to the VM? > > Currently, when formatting areas of dead objects all gcs use instances of j.l.Object and int-arrays. > > This has the drawback of not being easily able to discern whether a given object is actually dead (and should never be referenced) or just a regular j.l.Object/int array. > > This also makes enhanced error detection (any reference to such an object is an error - i.e. detecting references to such objects) and to skip potentially already unloaded classes when scanning areas of the heap below TAMS, G1 uses its prev bitmap. > Other collectors do not have this extra information at the moment, so they can't (and don't) do this kind of verification. > > With [JDK-8210708](https://bugs.openjdk.java.net/browse/JDK-8210708) the prev bitmap will effectively be removed in G1; G1 will format the dead areas with these filler objects to avoid coming across unloaded classes. This is fine wrt to normal operation, however, this looses the existing enhanced verification mentioned above. > > This change proposes to add dedicated VM-internal filler objects, i.e. equivalents of j.l.Object and int-arrays. > > This has the following benefits: > > - keep this error detection (actually making it much simpler) and allowing similar verification for other collectors. (This change does not add this) > > - this also makes it "easy" to detect references to filler objects in debugging tools - you only need to know the two klasses (or just get their friendly name) to see whether that reference may actually be valid (or refers to the inside such an object). References to these classes in the crash file may also allow the issue to be more clear. > > This causes some minor changes to external behavior: > > - logs/heap dumps now contain instances of these objects - which seems fine as previously they have just been reported as part of j.l.Object/int-arrays statistics. The VM spec also does not guarantee whether a particular kind of object should/should not show there anyway afaik. > > - if the application ever gets to instantiate a reference to such an object somehow, any enabled verification will crash the VM. That's bad luck for messing with internal classes, but that's the purpose of these objects. > > The change takes care that getting a reference will not be possible by normal means (i.e. via Class.forName() etc) - which should be sufficient to avoid the issue. Actually, existing mechanisms seem to be sufficient. > > > Testing: tier1-8 > > There is one question I would like the reviewers to specially think about, the name of the filler array klass. I just used `Ljava/internal/vm/FillerArray;` for that, looking at other internal symbols/klasses, but I'm not sure this adheres to naming guidelines. > > Thanks go to @iklam for helping out with the change. > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: Fix test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8156/files - new: https://git.openjdk.java.net/jdk/pull/8156/files/b3e2c6c3..effb9cd5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8156&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8156&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8156.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8156/head:pull/8156 PR: https://git.openjdk.java.net/jdk/pull/8156 From duke at openjdk.java.net Mon Apr 11 14:56:19 2022 From: duke at openjdk.java.net (Tobias Holenstein) Date: Mon, 11 Apr 2022 14:56:19 GMT Subject: RFR: JDK-8075816: AliasLevel is broken and should be deprecated [v2] In-Reply-To: References: Message-ID: > Deprecated AliasLevel and edited help messages. > Added flag to VMDeprecatedOptions test. > > Checked that tests are not affected. Tobias Holenstein has updated the pull request incrementally with one additional commit since the last revision: Obsolete AliasLevel flag ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8140/files - new: https://git.openjdk.java.net/jdk/pull/8140/files/84412b89..6a1bed2d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8140&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8140&range=00-01 Stats: 77 lines in 12 files changed: 2 ins; 57 del; 18 mod Patch: https://git.openjdk.java.net/jdk/pull/8140.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8140/head:pull/8140 PR: https://git.openjdk.java.net/jdk/pull/8140 From kvn at openjdk.java.net Mon Apr 11 16:13:35 2022 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Mon, 11 Apr 2022 16:13:35 GMT Subject: RFR: JDK-8075816: AliasLevel is broken and should be deprecated [v2] In-Reply-To: References: Message-ID: On Mon, 11 Apr 2022 14:56:19 GMT, Tobias Holenstein wrote: >> Making the `AliasLevel` flag obsolete. And refactor code to always use default value 3. `AliasLevel` had the following values: >> >> - "0 - for no aliasing, " >> - "1 - for oop/field/static/array split, " >> - "2 - for class split, " >> - "3 - for unique instances" >> >> The variable `_AliasLevel` is set by the value passed in `Compile::Init(int aliaslevel)` with `aliaslevel` being `3` except when call by `Compile::Compile(...)` for a runtime stub where `aliaslevel` is `0`. Therefor `_AliasLevel` can be turned into on boolean `do_aliasing` that indicated whether aliasing is turned off for runtime stubs or on otherwise. Code for level 1 and 2 can be removed completely. > > Tobias Holenstein has updated the pull request incrementally with one additional commit since the last revision: > > Obsolete AliasLevel flag src/hotspot/share/opto/compile.cpp line 1051: > 1049: aliaslevel = 2; // No unique types without escape analysis > 1050: } > 1051: _AliasLevel = aliaslevel; Please, test with EA switched off `-XX:-DoEscapeAnalysis` There are tests which switch it off. Also it is off in tier7 and tier8 for compiler tests. So I am puzzled that bug say that it crash with `aliasLevel=2`. Also update subject of PR to match new bug's subject. ------------- PR: https://git.openjdk.java.net/jdk/pull/8140 From stefan.reich.maker.of.eye at googlemail.com Mon Apr 11 16:57:36 2022 From: stefan.reich.maker.of.eye at googlemail.com (Stefan Reich) Date: Mon, 11 Apr 2022 18:57:36 +0200 Subject: Header size with -XX:-UseCompressedOops Message-ID: Hi, quick question to the experts. Java object header size is 12 bytes with CompressedOOPS (have verified this many times). Now I did a test with -XX:-UseCompressedOops just for fun and found that headers are still 12 bytes? I verified this in two ways: a. using Unsafe.objectFieldOffset b. making a whole lot of identical objects and measuring heap use before and after (with calls to System.gc) Both these methods give me a size of 16 bytes for an object with a single int field. How is this possible? Many greetings Stefan Reich -- == Gaz.AI == From thomas.stuefe at gmail.com Mon Apr 11 17:28:07 2022 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 11 Apr 2022 19:28:07 +0200 Subject: Header size with -XX:-UseCompressedOops In-Reply-To: References: Message-ID: Hi Stefan, I think you want to set CompressedClassPointers. There used to be a dependency between CompressedOops and CompressedClassPointers - switching the former off switched the latter off too - but that dependency is gone and these settings are now independent of each other. Cheers, Thomas On Mon, Apr 11, 2022 at 6:57 PM Stefan Reich < stefan.reich.maker.of.eye at googlemail.com> wrote: > Hi, quick question to the experts. > > Java object header size is 12 bytes with CompressedOOPS (have verified this > many times). > > Now I did a test with -XX:-UseCompressedOops just for fun and found that > headers are still 12 bytes? > > I verified this in two ways: > > a. using Unsafe.objectFieldOffset > b. making a whole lot of identical objects and measuring heap use before > and after (with calls to System.gc) > > Both these methods give me a size of 16 bytes for an object with a single > int field. > > How is this possible? > > Many greetings > Stefan Reich > > -- > == Gaz.AI == > From mcimadamore at openjdk.java.net Mon Apr 11 17:29:56 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 11 Apr 2022 17:29:56 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v25] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/424 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Fix UnrolledAccess benchmark ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7888/files - new: https://git.openjdk.java.net/jdk/pull/7888/files/d84de510..c9afcd17 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=24 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=23-24 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/7888.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888 PR: https://git.openjdk.java.net/jdk/pull/7888 From dfuchs at openjdk.java.net Mon Apr 11 17:31:01 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Mon, 11 Apr 2022 17:31:01 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) In-Reply-To: References: Message-ID: On Fri, 8 Apr 2022 13:43:39 GMT, Alan Bateman wrote: > This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. > > We will refresh this PR periodically to pick up changes and fixes from the loom repo. > > Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. > > The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. > > There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. > > The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. > > The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. src/java.base/share/classes/java/io/BufferedReader.java line 101: > 99: */ > 100: public BufferedReader(Reader in, int sz) { > 101: Objects.requireNonNull(in); Not sure if that even matters - but there will be a slight change of behaviour here if `InternalLock.CAN_USE_INTERNAL_LOCK` is ever `false`. Instead of synchronizing on `in`, the `BufferedReader` will synchronize on `this`. Now that I think of it - it probably does matter since even if CAN_USE_INTERNAL_LOCK is true, untrusted subclasses of BufferedReader calling this constructor might expect the locking to be performed on `in`? ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From akozlov at openjdk.java.net Mon Apr 11 17:42:41 2022 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Mon, 11 Apr 2022 17:42:41 GMT Subject: RFR: JDK-8283326: Implement SafeFetch statically In-Reply-To: References: Message-ID: On Fri, 18 Mar 2022 08:52:46 GMT, Thomas Stuefe wrote: > Hi, > > This is a reimplementation of SafeFetch to get rid of dynamic code generation. This is done, depending on platform, via static assembly, Posix setjmp/longjmp or SEH. > > This is based on a proposal by @theRealAph [1] when discussing [JDK-8282475](https://bugs.openjdk.java.net/browse/JDK-8282475). I extended the proposal to do this for all platforms, not just MacOS, see discussion below. > > --- > > Why we do this: > > SafeFetch is special: it is a basic utility function that may be called before the VM is properly initialized, from a "foreign" thread not attached to the VM, in a broken environment... mainly this is due to its use during stack walking, error reporting, hex dumping, etc. SafeFetch has to be safe to call under any circumstances - or as safe as we can make it. > > Today, SafeFetch is implemented via stub routines. That causes problems: > > - MacOs aarch64 has mechanisms to prevent execution of arbitrary non-text memory. On that platform, invoking generated code requires some awkward gymnastics [2]. These workarounds require access to Thread::current, which renders SafeFetch non-functional if Thread::current is NULL (e.g. crash reporting in "foreign" native threads or in a corrupted VM). They also cost a bit of performance on every SafeFetch invocation. Note that more OSes may implement similar execution prevention mechanics in the future. > > - There is a time window during VM initialization where the stubs are not generated yet and thus SafeFetch is not available. > > Both points cause hs-err files to be compromised (e.g. missing call stacks) for crashes in native threads, when the VM is corrupted, or early during VM initialization. Since SafeFetch is such a basic tool, it causes more issues than that (e.g., on AIX it is used for verifying mprotect() itself). But hs-err files being compromised by secondary errors is the most annoying effect. > > A minor point is that generating stubs takes a tiny bit of startup time. Not a big issue, but anything we can generate at build time instead of at runtime is good. > > --- > > The patch: > > - Removes the SafeFetch stub routine generation for all platforms > - For Linux and MacOS, it implements SafeFetch as cpu-specific static assembler routines. These routines live in `os_cpu/_/safefetch__.S`. > - On Windows, SafeFetch is implemented via SEH. This is beautifully simple and does not need handwritten assembly at all. See `os/windows/safefetch_windows.hpp`. > - On Zero, SafeFetch uses a Posix compatible solution using `sigsetjmp(2)`. This is portable and robust, but a bit slow compared to the other methods. Note that this solution existed before, and is well tested. I just moved the code around and massaged it a bit. > - AIX uses now the same method as Zero. AIX "downgraded" in that sense from the stub routine solution, but since SAP gave up maintenance of AIX, I don't have easy access to AIX hardware. If SafeFetch speed becomes an issue, I am sure a solution based on static assembly can be implemented on AIX too. > - The SafeFetch gtests were greatly expanded. > > Tests: > > - The patch was tested manually by building and running gtests on: > - MacOS (x64, aarch64) > - Linux (aarch64, arm, ppcle, s390, x64, x86, riscv) > - Windows (x64 and x86, but not arm, see below) > - AIX > - Zero (on Linux x64). > - GHAs > - The patch ran through SAP nightlies for several nights in a row > > Note: > - I have no access to Windows arm, so I could not test it. I contacted @mo-beck to verify that the patch works there. > - I have no access to BSD. I am not sure who maintains BSD, so I have no idea who to contact. However, I believe the MacOS solution should work for BSD too. If not, BSD can simply fall back to the Posix sigjmp solution like AIX and Zero. > > It would be nice to have @RealLucy, @TheRealMDoerr and @theRealAph to okay s390, ppcle and aarch64 (and possibly arm32). Each assembly file is tiny, so it should not take long. @RealFYang and @backwaterred already tested the patch on RiscV and AIX (thanks). > > Thanks, Thomas > > [1] https://github.com/openjdk/jdk/pull/7727#issuecomment-1064980598 > [2] https://github.com/openjdk/jdk/blob/4df67426ed02f18af0757897acb28b636a317a91/src/hotspot/share/runtime/safefetch.inline.hpp#L37-L41 src/hotspot/os_cpu/bsd_aarch64/safefetch_bsd_aarch64.S line 55: > 53: SYMBOL(_SafeFetch32_continuation): > 54: mov x0, x1 > 55: ret Minor: on RISC platforms you seems to prefer to pack exceptional and non-exceptional paths, and on x86 they are separated. If we align this with x86, we'd save an instruction in each execution of non-exceptional path, with an extra instruction in static code. ldr w0, [x0] ret SYMBOL(_SafeFetch32_continuation): mov x0, x1 ret src/hotspot/share/runtime/safefetch_static.cpp line 52: > 50: address pc = os::Posix::ucontext_get_pc(uc); > 51: if (pc == (address)_SafeFetch32_fault) { > 52: os::Posix::ucontext_set_pc(uc, (address)_SafeFetch32_continuation); This posix-specific code should be probably moved to os/posix. src/hotspot/share/runtime/safefetch_static.hpp line 42: > 40: > 41: inline bool CanUseSafeFetch32() { return true; } > 42: inline bool CanUseSafeFetchN() { return true; } AFAICS all CanUseSafeFetchXX always return true and there are few calls of these functions. It's worth to remove them completely then. ------------- PR: https://git.openjdk.java.net/jdk/pull/7865 From stefan.reich.maker.of.eye at googlemail.com Mon Apr 11 17:58:04 2022 From: stefan.reich.maker.of.eye at googlemail.com (Stefan Reich) Date: Mon, 11 Apr 2022 19:58:04 +0200 Subject: Header size with -XX:-UseCompressedOops In-Reply-To: References: Message-ID: Hi Thomas, oh! Never heard about that change. Now I know. And yes this changes the picture as expected. Thanks On Mon, 11 Apr 2022 at 19:28, Thomas St?fe wrote: > Hi Stefan, > > I think you want to set CompressedClassPointers. > > There used to be a dependency between CompressedOops and > CompressedClassPointers - switching the former off switched the latter off > too - but that dependency is gone and these settings are now independent of > each other. > > Cheers, Thomas > > On Mon, Apr 11, 2022 at 6:57 PM Stefan Reich < > stefan.reich.maker.of.eye at googlemail.com> wrote: > >> Hi, quick question to the experts. >> >> Java object header size is 12 bytes with CompressedOOPS (have verified >> this >> many times). >> >> Now I did a test with -XX:-UseCompressedOops just for fun and found that >> headers are still 12 bytes? >> >> I verified this in two ways: >> >> a. using Unsafe.objectFieldOffset >> b. making a whole lot of identical objects and measuring heap use before >> and after (with calls to System.gc) >> >> Both these methods give me a size of 16 bytes for an object with a single >> int field. >> >> How is this possible? >> >> Many greetings >> Stefan Reich >> >> -- >> == Gaz.AI == >> > -- == Gaz.AI == From thomas.stuefe at gmail.com Mon Apr 11 18:11:03 2022 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 11 Apr 2022 20:11:03 +0200 Subject: Header size with -XX:-UseCompressedOops In-Reply-To: References: Message-ID: Hi Stefan, See https://bugs.openjdk.java.net/browse/JDK-8241825 Cheers, Thomas On Mon 11. Apr 2022 at 19:58, Stefan Reich < stefan.reich.maker.of.eye at googlemail.com> wrote: > Hi Thomas, > > oh! Never heard about that change. Now I know. And yes this changes the > picture as expected. > > Thanks > > On Mon, 11 Apr 2022 at 19:28, Thomas St?fe > wrote: > >> Hi Stefan, >> >> I think you want to set CompressedClassPointers. >> >> There used to be a dependency between CompressedOops and >> CompressedClassPointers - switching the former off switched the latter off >> too - but that dependency is gone and these settings are now independent of >> each other. >> >> Cheers, Thomas >> >> On Mon, Apr 11, 2022 at 6:57 PM Stefan Reich < >> stefan.reich.maker.of.eye at googlemail.com> wrote: >> >>> Hi, quick question to the experts. >>> >>> Java object header size is 12 bytes with CompressedOOPS (have verified >>> this >>> many times). >>> >>> Now I did a test with -XX:-UseCompressedOops just for fun and found that >>> headers are still 12 bytes? >>> >>> I verified this in two ways: >>> >>> a. using Unsafe.objectFieldOffset >>> b. making a whole lot of identical objects and measuring heap use before >>> and after (with calls to System.gc) >>> >>> Both these methods give me a size of 16 bytes for an object with a single >>> int field. >>> >>> How is this possible? >>> >>> Many greetings >>> Stefan Reich >>> >>> -- >>> == Gaz.AI == >>> >> > > -- > == Gaz.AI == > From stefan.reich.maker.of.eye at googlemail.com Mon Apr 11 18:15:44 2022 From: stefan.reich.maker.of.eye at googlemail.com (Stefan Reich) Date: Mon, 11 Apr 2022 20:15:44 +0200 Subject: Header size with -XX:-UseCompressedOops In-Reply-To: References: Message-ID: So with CompressedOOPS=false and CompressedClassPointers=true, classes will be put in a special segment that allows their pointers to be compressed? Kinda makes sense because which program has more than a gigabyte worth of actual class objects? On Mon, 11 Apr 2022 at 20:11, Thomas St?fe wrote: > Hi Stefan, > > See > https://bugs.openjdk.java.net/browse/JDK-8241825 > > Cheers, Thomas > > On Mon 11. Apr 2022 at 19:58, Stefan Reich < > stefan.reich.maker.of.eye at googlemail.com> wrote: > >> Hi Thomas, >> >> oh! Never heard about that change. Now I know. And yes this changes the >> picture as expected. >> >> Thanks >> >> On Mon, 11 Apr 2022 at 19:28, Thomas St?fe >> wrote: >> >>> Hi Stefan, >>> >>> I think you want to set CompressedClassPointers. >>> >>> There used to be a dependency between CompressedOops and >>> CompressedClassPointers - switching the former off switched the latter off >>> too - but that dependency is gone and these settings are now independent of >>> each other. >>> >>> Cheers, Thomas >>> >>> On Mon, Apr 11, 2022 at 6:57 PM Stefan Reich < >>> stefan.reich.maker.of.eye at googlemail.com> wrote: >>> >>>> Hi, quick question to the experts. >>>> >>>> Java object header size is 12 bytes with CompressedOOPS (have verified >>>> this >>>> many times). >>>> >>>> Now I did a test with -XX:-UseCompressedOops just for fun and found that >>>> headers are still 12 bytes? >>>> >>>> I verified this in two ways: >>>> >>>> a. using Unsafe.objectFieldOffset >>>> b. making a whole lot of identical objects and measuring heap use before >>>> and after (with calls to System.gc) >>>> >>>> Both these methods give me a size of 16 bytes for an object with a >>>> single >>>> int field. >>>> >>>> How is this possible? >>>> >>>> Many greetings >>>> Stefan Reich >>>> >>>> -- >>>> == Gaz.AI == >>>> >>> >> >> -- >> == Gaz.AI == >> > -- == Gaz.AI == From mcimadamore at openjdk.java.net Mon Apr 11 18:36:48 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 11 Apr 2022 18:36:48 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v26] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/424 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Use a less expensive array element alignment check The bit to byte conversion shows up in hot paths ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7888/files - new: https://git.openjdk.java.net/jdk/pull/7888/files/c9afcd17..a68195ae Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=25 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=24-25 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7888.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888 PR: https://git.openjdk.java.net/jdk/pull/7888 From ioi.lam at oracle.com Mon Apr 11 20:24:45 2022 From: ioi.lam at oracle.com (Ioi Lam) Date: Mon, 11 Apr 2022 13:24:45 -0700 Subject: Header size with -XX:-UseCompressedOops In-Reply-To: References: Message-ID: I vaguely remember there were some pathological cases where the ClassSpace was fragmented so badly that we ran out of space for loading new classes, even though the total size of classes were well below 1GB. Thomas, after your clean-up of the metaspace allocation code, do we still have such these fragmentation problems? Thanks - Ioi On 4/11/2022 11:15 AM, Stefan Reich wrote: > So with CompressedOOPS=false and CompressedClassPointers=true, classes will > be put in a special segment that allows their pointers to be compressed? > > Kinda makes sense because which program has more than a gigabyte worth of > actual class objects? > > On Mon, 11 Apr 2022 at 20:11, Thomas St?fe wrote: > >> Hi Stefan, >> >> See >> https://bugs.openjdk.java.net/browse/JDK-8241825 >> >> Cheers, Thomas >> >> On Mon 11. Apr 2022 at 19:58, Stefan Reich < >> stefan.reich.maker.of.eye at googlemail.com> wrote: >> >>> Hi Thomas, >>> >>> oh! Never heard about that change. Now I know. And yes this changes the >>> picture as expected. >>> >>> Thanks >>> >>> On Mon, 11 Apr 2022 at 19:28, Thomas St?fe >>> wrote: >>> >>>> Hi Stefan, >>>> >>>> I think you want to set CompressedClassPointers. >>>> >>>> There used to be a dependency between CompressedOops and >>>> CompressedClassPointers - switching the former off switched the latter off >>>> too - but that dependency is gone and these settings are now independent of >>>> each other. >>>> >>>> Cheers, Thomas >>>> >>>> On Mon, Apr 11, 2022 at 6:57 PM Stefan Reich < >>>> stefan.reich.maker.of.eye at googlemail.com> wrote: >>>> >>>>> Hi, quick question to the experts. >>>>> >>>>> Java object header size is 12 bytes with CompressedOOPS (have verified >>>>> this >>>>> many times). >>>>> >>>>> Now I did a test with -XX:-UseCompressedOops just for fun and found that >>>>> headers are still 12 bytes? >>>>> >>>>> I verified this in two ways: >>>>> >>>>> a. using Unsafe.objectFieldOffset >>>>> b. making a whole lot of identical objects and measuring heap use before >>>>> and after (with calls to System.gc) >>>>> >>>>> Both these methods give me a size of 16 bytes for an object with a >>>>> single >>>>> int field. >>>>> >>>>> How is this possible? >>>>> >>>>> Many greetings >>>>> Stefan Reich >>>>> >>>>> -- >>>>> == Gaz.AI == >>>>> >>> -- >>> == Gaz.AI == >>> From dholmes at openjdk.java.net Mon Apr 11 21:54:40 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 11 Apr 2022 21:54:40 GMT Subject: RFR: 8284435: Add dedicated filler objects for known dead Java heap areas [v3] In-Reply-To: References: Message-ID: On Mon, 11 Apr 2022 14:55:32 GMT, Thomas Schatzl wrote: >> Hi all, >> >> can I have reviews for this change that adds dedicated filler objects to the VM? >> >> Currently, when formatting areas of dead objects all gcs use instances of j.l.Object and int-arrays. >> >> This has the drawback of not being easily able to discern whether a given object is actually dead (and should never be referenced) or just a regular j.l.Object/int array. >> >> This also makes enhanced error detection (any reference to such an object is an error - i.e. detecting references to such objects) and to skip potentially already unloaded classes when scanning areas of the heap below TAMS, G1 uses its prev bitmap. >> Other collectors do not have this extra information at the moment, so they can't (and don't) do this kind of verification. >> >> With [JDK-8210708](https://bugs.openjdk.java.net/browse/JDK-8210708) the prev bitmap will effectively be removed in G1; G1 will format the dead areas with these filler objects to avoid coming across unloaded classes. This is fine wrt to normal operation, however, this looses the existing enhanced verification mentioned above. >> >> This change proposes to add dedicated VM-internal filler objects, i.e. equivalents of j.l.Object and int-arrays. >> >> This has the following benefits: >> >> - keep this error detection (actually making it much simpler) and allowing similar verification for other collectors. (This change does not add this) >> >> - this also makes it "easy" to detect references to filler objects in debugging tools - you only need to know the two klasses (or just get their friendly name) to see whether that reference may actually be valid (or refers to the inside such an object). References to these classes in the crash file may also allow the issue to be more clear. >> >> This causes some minor changes to external behavior: >> >> - logs/heap dumps now contain instances of these objects - which seems fine as previously they have just been reported as part of j.l.Object/int-arrays statistics. The VM spec also does not guarantee whether a particular kind of object should/should not show there anyway afaik. >> >> - if the application ever gets to instantiate a reference to such an object somehow, any enabled verification will crash the VM. That's bad luck for messing with internal classes, but that's the purpose of these objects. >> >> The change takes care that getting a reference will not be possible by normal means (i.e. via Class.forName() etc) - which should be sufficient to avoid the issue. Actually, existing mechanisms seem to be sufficient. >> >> >> Testing: tier1-8 >> >> There is one question I would like the reviewers to specially think about, the name of the filler array klass. I just used `Ljava/internal/vm/FillerArray;` for that, looking at other internal symbols/klasses, but I'm not sure this adheres to naming guidelines. >> >> Thanks go to @iklam for helping out with the change. >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > Fix test Do you really need to define a real `FillerObject.java` class? Can't you use an internal-only variant of a hidden class to represent this? ------------- PR: https://git.openjdk.java.net/jdk/pull/8156 From dholmes at openjdk.java.net Mon Apr 11 22:41:45 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 11 Apr 2022 22:41:45 GMT Subject: RFR: 8269537: memset() is called after operator new [v4] In-Reply-To: References: Message-ID: On Mon, 11 Apr 2022 13:50:49 GMT, Leo Korinth wrote: >> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: >> >> review updates > > I would like to have this change approved, or the approval of removing tracking the allocation type altogether. I do not like having this pull request open any more. The current code is not okay. @lkorinth it is not clear what state this PR is in as you have a merge-conflict with mainline that has not been addressed. I suggest updating the PR so it is ready to integrate again and then resume the review. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/5387 From dholmes at openjdk.java.net Mon Apr 11 22:51:08 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 11 Apr 2022 22:51:08 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v24] In-Reply-To: References: <-3pH-9NVTEgTBaWbZ05s8pSHxZZIwMFUlgxPpqvke8s=.2a1299f4-6bc4-46b1-8cea-181fb17e6f6a@github.com> Message-ID: On Mon, 11 Apr 2022 12:04:41 GMT, Maurizio Cimadamore wrote: >> src/hotspot/share/prims/scopedMemoryAccess.cpp line 141: >> >>> 139: >>> 140: /* >>> 141: * This function performs a thread-local handshake against all threads running at the time >> >> Nit: thread-local?? > > I was assuming the term "thread-local handshake" was a thing in the VM, as per: > https://openjdk.java.net/jeps/312 Ha! Mea culpa. I've been too buried in the other kind of thread-local lately. I completely forgot we actually described handshakes that way. :) ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From dlong at openjdk.java.net Mon Apr 11 22:59:44 2022 From: dlong at openjdk.java.net (Dean Long) Date: Mon, 11 Apr 2022 22:59:44 GMT Subject: RFR: 8284578: Relax InterpreterCodelet stub alignment In-Reply-To: References: Message-ID: On Fri, 8 Apr 2022 11:45:13 GMT, Aleksey Shipilev wrote: > `InterpreterCodelet` is aligned by `CodeEntryAlignment` (`CAE`) twice. First, the entire stub is aligned, which aligns its data section. Then, the code section in the stub is aligned. Since `CAE` is usually larger than the size of `InterpreterCodelet`, we are wasting quite a bit of space for each codelet. In the extreme cases, like PPC that defaults to `CAE=128`, we have 16 bytes of codelet data effectively taking 128 bytes! > > This can be made better by relaxing the `InterpreterCodelet` stub alignment to `HeapWordSize`, while leaving its code section alignment the same. > > This tangentially touches the only other user for `StubQueue`: `ICStub`. Unfortunately, we cannot do the same kind of relaxation there, because there is a reverse lookup function that needs to reach data section from the code section, which forces us to keep the same alignment for both. > > Interpreter sizes on Linux x86_64 release: > > > # Baseline, CEA=32 (default) > code size = 94K bytes > avg codelet size = 356 bytes > > # Baseline, CEA=128 (PPC-like) > code size = 133K bytes > avg codelet size = 501 bytes > > # Patched, CEA=32 (default) > code size = 89K bytes > avg codelet size = 338 bytes > > # Patched, CEA=128 (PPC-like) > code size = 100K bytes > avg codelet size = 380 bytes > > > Point performance runs (SPECjvm2008:serial with `-Xint` on Linux x86_64 release): > > > Benchmark Mode Cnt Score Error Units > > # Baseline, CEA=32 > Serial.test thrpt 9 73.427 ? 0.152 ops/s > > # Baseline, CEA=128 > Serial.test thrpt 9 70.999 ? 0.246 ops/s > > # Patched, CEA=32 > Serial.test thrpt 9 73.991 ? 0.860 ops/s > > # Patched, CEA=128 > Serial.test thrpt 9 72.981 ? 0.301 ops/s > > > Additional testing: > - [x] Linux x86_64 fastdebug `tier1` > - [ ] Linux x86_64 fastdebug `tier2` > - [ ] Linux x86_64 fastdebug `tier3` Does your change make this recent change obsolete, or is it still needed? https://github.com/openjdk/jdk/blob/026b85303c01326bc49a1105a89853d7641fcd50/src/hotspot/share/interpreter/templateInterpreter.cpp#L53 ------------- PR: https://git.openjdk.java.net/jdk/pull/8159 From dholmes at openjdk.java.net Mon Apr 11 23:44:46 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 11 Apr 2022 23:44:46 GMT Subject: RFR: 8283710: JVMTI: Use BitSet for object marking [v8] In-Reply-To: References: Message-ID: On Mon, 11 Apr 2022 11:55:33 GMT, Roman Kennke wrote: >> JVMTI heap walking marks objects in order to track which have been visited already. In order to do that, it uses bits in the object header. Those are the same bits that are also used by some GCs to mark objects (the lowest two bits, also used by locking code). Some GCs also use the bits in order to indicate 'forwarded' objects, where the upper bits of the header represent the forward-pointer. In the case of Shenandoah, it's even more problematic because this happens concurrently, even while JVMTI heap walks can intercept. So far we carefully worked around that problem, but it becomes very problematic in Lilliput, where accesses to the Klass* also requires to decode the header, and figure out what bits means what. >> >> In addition to that, marking objects in their header requires that the original header gets saved and restored. We only do that for 'interesting' headers, that is headers that have a stack-lock, monitor or hash-code. All other headers are reset to their default value. This means we are losing object's GC age. This is not catastrophic, but nontheless interferes with GC. >> >> JFR already has a datastructure called BitSet to support object marking without messing with object's headers. We can use that in JVMTI too. >> >> Testing: >> - [x] tier1 >> - [x] tier2 >> - [x] tier3 >> - [x] serviceability/jvmti >> - [x] vmTestbase/nsk/jvmti > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Add some basic tests for ObjectBitSet src/hotspot/share/jfr/leakprofiler/chains/jfrbitset.hpp line 26: > 24: > 25: #ifndef SHARE_JFR_LEAKPROFILER_JFRBITMAP_HPP > 26: #define SHARE_JFR_LEAKPROFILER_JFRBITMAP_HPP This is wrong - it should be BITSET not BITMAP ------------- PR: https://git.openjdk.java.net/jdk/pull/7964 From dholmes at openjdk.java.net Tue Apr 12 02:35:38 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 12 Apr 2022 02:35:38 GMT Subject: RFR: JDK-8283326: Implement SafeFetch statically In-Reply-To: References: <8UpDSUrPORbSrYWpdlrFlw7gMzrCs36cNM-ij-7gSqU=.e51b5cbf-86d2-417d-813a-efabc4564075@github.com> Message-ID: On Mon, 11 Apr 2022 11:57:37 GMT, Thomas Stuefe wrote: >> `pthread_getspecific` and `pthread_setspecific` cannot be called from a signal handler, either. In particular, `pthread_setspecific` may call `malloc`. >> >> On GNU/Linux, if you use initial-exec TLS, it is fully async-signal-safe. Less so for the other variants. But maybe this does not matter because the assembler implementation uses `os::Posix::ucontext_set_pc` to redirect the execution in a more direction fashion? > > @fweimer-rh I'll move `pthread_setspecific` out of signal handling, thanks for the hint. > > `pthread_getspecific` may not be signal safe, but it has been in use in JVM signal handlers for decades (signal handlers call `Thread::current`, which uses TLS) and it works in practice on all Posix platforms. Sorry I missed the use of pthread_setspecific in the signal handler - yes that is also unsafe. As noted pthread_getspecific is not listed to be safe but appears so in practice. It was investigated when we introduced the use of compiler-based thread-locals. ------------- PR: https://git.openjdk.java.net/jdk/pull/7865 From dholmes at openjdk.java.net Tue Apr 12 02:40:44 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 12 Apr 2022 02:40:44 GMT Subject: RFR: JDK-8283326: Implement SafeFetch statically In-Reply-To: References: Message-ID: On Mon, 11 Apr 2022 09:18:33 GMT, Thomas Stuefe wrote: > On Posix platforms you can use either static assembly or setjmp, and need to exclude one of them from compilation - either build safefetch_xx_xx.S, or build safefetch_sigjmp.cpp. Yes but we don't need to make this build time selectable. If a platform supports static then it will have a .S file and won't use the sigjmp file (which will be empty due to ifdef based on platform); otherwise no .S file and the sigjmp file is populated. I would hope all Windows platforms support SEH. ------------- PR: https://git.openjdk.java.net/jdk/pull/7865 From thartmann at openjdk.java.net Tue Apr 12 05:46:41 2022 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Tue, 12 Apr 2022 05:46:41 GMT Subject: RFR: JDK-8075816: AliasLevel is broken and should be deprecated [v2] In-Reply-To: References: Message-ID: On Mon, 11 Apr 2022 14:56:19 GMT, Tobias Holenstein wrote: >> Making the `AliasLevel` flag obsolete. And refactor code to always use default value 3. `AliasLevel` had the following values: >> >> - "0 - for no aliasing, " >> - "1 - for oop/field/static/array split, " >> - "2 - for class split, " >> - "3 - for unique instances" >> >> The variable `_AliasLevel` is set by the value passed in `Compile::Init(int aliaslevel)` with `aliaslevel` being `3` except when call by `Compile::Compile(...)` for a runtime stub where `aliaslevel` is `0`. Therefor `_AliasLevel` can be turned into on boolean `do_aliasing` that indicated whether aliasing is turned off for runtime stubs or on otherwise. Code for level 1 and 2 can be removed completely. > > Tobias Holenstein has updated the pull request incrementally with one additional commit since the last revision: > > Obsolete AliasLevel flag >From looking at the code and history, it seems that `AliasLevel` values `0` and `1` are currently disabled due to issues. The VM will print: AliasLevel (1) is not compatible with -Xcomp or -Xmixed Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. But `2` seems to work fine. `3` is the default. @tobiasholenstein did you find any issues with `AliasLevel=2`? ------------- PR: https://git.openjdk.java.net/jdk/pull/8140 From rkennke at openjdk.java.net Tue Apr 12 06:11:46 2022 From: rkennke at openjdk.java.net (Roman Kennke) Date: Tue, 12 Apr 2022 06:11:46 GMT Subject: RFR: 8283710: JVMTI: Use BitSet for object marking [v8] In-Reply-To: References: Message-ID: On Mon, 11 Apr 2022 23:41:40 GMT, David Holmes wrote: > This is wrong - it should be BITSET not BITMAP Oh, good find! I filed a follow-up issue: https://bugs.openjdk.java.net/browse/JDK-8284725 ------------- PR: https://git.openjdk.java.net/jdk/pull/7964 From duke at openjdk.java.net Tue Apr 12 06:50:34 2022 From: duke at openjdk.java.net (KIRIYAMA Takuya) Date: Tue, 12 Apr 2022 06:50:34 GMT Subject: RFR: 8280761: UseCompressedOops should be set after limit_heap_by_allocatable_memory [v3] In-Reply-To: <-Cdfx9sVBVGWB-EP7XEPD8AgIydxIRHPHpSdzyJzLvY=.1ee8ab37-9c4e-45e9-bf0a-7df5ee24f80f@github.com> References: <6GOMMUZQwo2KpLSctWaV1RvoiYp5wGaHF1WbMUy5TGg=.857388ea-9fdc-4105-839e-56a018fdd54e@github.com> <-Cdfx9sVBVGWB-EP7XEPD8AgIydxIRHPHpSdzyJzLvY=.1ee8ab37-9c4e-45e9-bf0a-7df5ee24f80f@github.com> Message-ID: On Fri, 8 Apr 2022 10:12:55 GMT, Albert Mingkun Yang wrote: >> Consider that values like `MaxRAM` might change in the future (unlikely as it is). Setting it makes following the execution a bit easier imho. > > Aha, I see. Having `MaxRAMPercentage` set explicitly instead of relying on its default value indeed makes the test more resilient. Please add a comment for `MaxRAMPercentage`. OK. I added a comment for MaxRAMPercentage. ------------- PR: https://git.openjdk.java.net/jdk/pull/7938 From duke at openjdk.java.net Tue Apr 12 06:50:32 2022 From: duke at openjdk.java.net (KIRIYAMA Takuya) Date: Tue, 12 Apr 2022 06:50:32 GMT Subject: RFR: 8280761: UseCompressedOops should be set after limit_heap_by_allocatable_memory [v3] In-Reply-To: References: <0fkb1Ur3CZmL_I33ijMC8pv1G5vQIyX6HUOI60Ua4ZA=.82dcfcbe-52a6-49e8-a40b-5ae44ea431db@github.com> Message-ID: On Mon, 11 Apr 2022 13:33:27 GMT, Thomas Schatzl wrote: >>> This looks like an additional (unrelated) test to make sure it is overridden if necessary imho. >> >> That is correct. >> Do you mean that the following code should be removed? >> >> `checkFlag(128 * oneG, 100, true, true);` > > Yes. Removing this test case would limit the testing to the actual problem stated in the CR. Verifying that `UseCompressedOops` is enabled correctly is tested somewhere else already, and there is no reason that using `ulimit -v` would change that behavior. I understand. I removed this test patern. ------------- PR: https://git.openjdk.java.net/jdk/pull/7938 From duke at openjdk.java.net Tue Apr 12 06:50:32 2022 From: duke at openjdk.java.net (KIRIYAMA Takuya) Date: Tue, 12 Apr 2022 06:50:32 GMT Subject: RFR: 8280761: UseCompressedOops should be set after limit_heap_by_allocatable_memory [v4] In-Reply-To: References: Message-ID: > I fixed to set UseCompressedOops flag after limit_heap_by_allocatable_memory(). > So when ulimit -v is called and -XX:MaxRAM is set, UseCompressedOops does not become false. > And all hotspot tier1 test are passed. > Would you please review this fix? KIRIYAMA Takuya has updated the pull request incrementally with one additional commit since the last revision: 8280761 UseCompressedOops should be set after limit_heap_by_allocatable_memory ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7938/files - new: https://git.openjdk.java.net/jdk/pull/7938/files/148d0fd6..486aa9ef Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7938&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7938&range=02-03 Stats: 12 lines in 1 file changed: 0 ins; 6 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/7938.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7938/head:pull/7938 PR: https://git.openjdk.java.net/jdk/pull/7938 From thomas.stuefe at gmail.com Tue Apr 12 07:19:53 2022 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 12 Apr 2022 09:19:53 +0200 Subject: Header size with -XX:-UseCompressedOops In-Reply-To: References: Message-ID: On Mon, Apr 11, 2022 at 10:24 PM Ioi Lam wrote: > I vaguely remember there were some pathological cases where the > ClassSpace was fragmented so badly that we ran out of space for loading > new classes, even though the total size of classes were well below 1GB. > > Thomas, after your clean-up of the metaspace allocation code, do we > still have such these fragmentation problems? > > In theory yes, but it's quite unlikely now since the new buddy allocator is very effective in preventing fragmentation at chunk level. Note that every allocator would have some internal fragmentation. Thats the price we paid for moving Klass out of Permgen. (still beats Permgen though :). Cheers, Thomas > Thanks > - Ioi > > On 4/11/2022 11:15 AM, Stefan Reich wrote: > > So with CompressedOOPS=false and CompressedClassPointers=true, classes > will > > be put in a special segment that allows their pointers to be compressed? > > > > Kinda makes sense because which program has more than a gigabyte worth of > > actual class objects? > > > > On Mon, 11 Apr 2022 at 20:11, Thomas St?fe > wrote: > > > >> Hi Stefan, > >> > >> See > >> https://bugs.openjdk.java.net/browse/JDK-8241825 > >> > >> Cheers, Thomas > >> > >> On Mon 11. Apr 2022 at 19:58, Stefan Reich < > >> stefan.reich.maker.of.eye at googlemail.com> wrote: > >> > >>> Hi Thomas, > >>> > >>> oh! Never heard about that change. Now I know. And yes this changes the > >>> picture as expected. > >>> > >>> Thanks > >>> > >>> On Mon, 11 Apr 2022 at 19:28, Thomas St?fe > >>> wrote: > >>> > >>>> Hi Stefan, > >>>> > >>>> I think you want to set CompressedClassPointers. > >>>> > >>>> There used to be a dependency between CompressedOops and > >>>> CompressedClassPointers - switching the former off switched the > latter off > >>>> too - but that dependency is gone and these settings are now > independent of > >>>> each other. > >>>> > >>>> Cheers, Thomas > >>>> > >>>> On Mon, Apr 11, 2022 at 6:57 PM Stefan Reich < > >>>> stefan.reich.maker.of.eye at googlemail.com> wrote: > >>>> > >>>>> Hi, quick question to the experts. > >>>>> > >>>>> Java object header size is 12 bytes with CompressedOOPS (have > verified > >>>>> this > >>>>> many times). > >>>>> > >>>>> Now I did a test with -XX:-UseCompressedOops just for fun and found > that > >>>>> headers are still 12 bytes? > >>>>> > >>>>> I verified this in two ways: > >>>>> > >>>>> a. using Unsafe.objectFieldOffset > >>>>> b. making a whole lot of identical objects and measuring heap use > before > >>>>> and after (with calls to System.gc) > >>>>> > >>>>> Both these methods give me a size of 16 bytes for an object with a > >>>>> single > >>>>> int field. > >>>>> > >>>>> How is this possible? > >>>>> > >>>>> Many greetings > >>>>> Stefan Reich > >>>>> > >>>>> -- > >>>>> == Gaz.AI == > >>>>> > >>> -- > >>> == Gaz.AI == > >>> > > From ayang at openjdk.java.net Tue Apr 12 07:52:33 2022 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Tue, 12 Apr 2022 07:52:33 GMT Subject: RFR: 8280761: UseCompressedOops should be set after limit_heap_by_allocatable_memory [v4] In-Reply-To: References: Message-ID: On Tue, 12 Apr 2022 06:50:32 GMT, KIRIYAMA Takuya wrote: >> I fixed to set UseCompressedOops flag after limit_heap_by_allocatable_memory(). >> So when ulimit -v is called and -XX:MaxRAM is set, UseCompressedOops does not become false. >> And all hotspot tier1 test are passed. >> Would you please review this fix? > > KIRIYAMA Takuya has updated the pull request incrementally with one additional commit since the last revision: > > 8280761 UseCompressedOops should be set after limit_heap_by_allocatable_memory test/hotspot/jtreg/gc/arguments/TestUseCompressedOopsFlagsWithUlimit.java line 85: > 83: > 84: // Args: MaxRAM , MaxRAMPercentage, expect coop > 85: // Having MaxRAMPercentage set explicitly instead of relying on its default value indeed makes the test more resilient. Slight rewording, `// Setting MaxRAMPercentage explicitly to make the test more resilient.` ------------- PR: https://git.openjdk.java.net/jdk/pull/7938 From ayang at openjdk.java.net Tue Apr 12 07:56:43 2022 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Tue, 12 Apr 2022 07:56:43 GMT Subject: RFR: 8280761: UseCompressedOops should be set after limit_heap_by_allocatable_memory [v4] In-Reply-To: References: Message-ID: On Tue, 12 Apr 2022 06:50:32 GMT, KIRIYAMA Takuya wrote: >> I fixed to set UseCompressedOops flag after limit_heap_by_allocatable_memory(). >> So when ulimit -v is called and -XX:MaxRAM is set, UseCompressedOops does not become false. >> And all hotspot tier1 test are passed. >> Would you please review this fix? > > KIRIYAMA Takuya has updated the pull request incrementally with one additional commit since the last revision: > > 8280761 UseCompressedOops should be set after limit_heap_by_allocatable_memory Thank you for the revision. Embedding `ulimit -v` inside `checkFlag` still hinders readability, IMO. What I have in mind is: // ulimit, max_ram, max_ram_percent, expected_coop checkFlag(5 * oneG, 32 * oneG, 100, true); Then, it's clear in this context why coop is enabled. ------------- PR: https://git.openjdk.java.net/jdk/pull/7938 From stuefe at openjdk.java.net Tue Apr 12 07:57:35 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 12 Apr 2022 07:57:35 GMT Subject: RFR: JDK-8283326: Implement SafeFetch statically In-Reply-To: References: Message-ID: <_fejWjlR5JNkdIFNW1I1kbG6_GmsFqGBk3WLc538ZL4=.74a9eddf-65f3-4334-a05d-abb3534e34a7@github.com> On Mon, 11 Apr 2022 06:13:22 GMT, David Holmes wrote: >> Hi, >> >> This is a reimplementation of SafeFetch to get rid of dynamic code generation. This is done, depending on platform, via static assembly, Posix setjmp/longjmp or SEH. >> >> This is based on a proposal by @theRealAph [1] when discussing [JDK-8282475](https://bugs.openjdk.java.net/browse/JDK-8282475). I extended the proposal to do this for all platforms, not just MacOS, see discussion below. >> >> --- >> >> Why we do this: >> >> SafeFetch is special: it is a basic utility function that may be called before the VM is properly initialized, from a "foreign" thread not attached to the VM, in a broken environment... mainly this is due to its use during stack walking, error reporting, hex dumping, etc. SafeFetch has to be safe to call under any circumstances - or as safe as we can make it. >> >> Today, SafeFetch is implemented via stub routines. That causes problems: >> >> - MacOs aarch64 has mechanisms to prevent execution of arbitrary non-text memory. On that platform, invoking generated code requires some awkward gymnastics [2]. These workarounds require access to Thread::current, which renders SafeFetch non-functional if Thread::current is NULL (e.g. crash reporting in "foreign" native threads or in a corrupted VM). They also cost a bit of performance on every SafeFetch invocation. Note that more OSes may implement similar execution prevention mechanics in the future. >> >> - There is a time window during VM initialization where the stubs are not generated yet and thus SafeFetch is not available. >> >> Both points cause hs-err files to be compromised (e.g. missing call stacks) for crashes in native threads, when the VM is corrupted, or early during VM initialization. Since SafeFetch is such a basic tool, it causes more issues than that (e.g., on AIX it is used for verifying mprotect() itself). But hs-err files being compromised by secondary errors is the most annoying effect. >> >> A minor point is that generating stubs takes a tiny bit of startup time. Not a big issue, but anything we can generate at build time instead of at runtime is good. >> >> --- >> >> The patch: >> >> - Removes the SafeFetch stub routine generation for all platforms >> - For Linux and MacOS, it implements SafeFetch as cpu-specific static assembler routines. These routines live in `os_cpu/_/safefetch__.S`. >> - On Windows, SafeFetch is implemented via SEH. This is beautifully simple and does not need handwritten assembly at all. See `os/windows/safefetch_windows.hpp`. >> - On Zero, SafeFetch uses a Posix compatible solution using `sigsetjmp(2)`. This is portable and robust, but a bit slow compared to the other methods. Note that this solution existed before, and is well tested. I just moved the code around and massaged it a bit. >> - AIX uses now the same method as Zero. AIX "downgraded" in that sense from the stub routine solution, but since SAP gave up maintenance of AIX, I don't have easy access to AIX hardware. If SafeFetch speed becomes an issue, I am sure a solution based on static assembly can be implemented on AIX too. >> - The SafeFetch gtests were greatly expanded. >> >> Tests: >> >> - The patch was tested manually by building and running gtests on: >> - MacOS (x64, aarch64) >> - Linux (aarch64, arm, ppcle, s390, x64, x86, riscv) >> - Windows (x64 and x86, but not arm, see below) >> - AIX >> - Zero (on Linux x64). >> - GHAs >> - The patch ran through SAP nightlies for several nights in a row >> >> Note: >> - I have no access to Windows arm, so I could not test it. I contacted @mo-beck to verify that the patch works there. >> - I have no access to BSD. I am not sure who maintains BSD, so I have no idea who to contact. However, I believe the MacOS solution should work for BSD too. If not, BSD can simply fall back to the Posix sigjmp solution like AIX and Zero. >> >> It would be nice to have @RealLucy, @TheRealMDoerr and @theRealAph to okay s390, ppcle and aarch64 (and possibly arm32). Each assembly file is tiny, so it should not take long. @RealFYang and @backwaterred already tested the patch on RiscV and AIX (thanks). >> >> Thanks, Thomas >> >> [1] https://github.com/openjdk/jdk/pull/7727#issuecomment-1064980598 >> [2] https://github.com/openjdk/jdk/blob/4df67426ed02f18af0757897acb28b636a317a91/src/hotspot/share/runtime/safefetch.inline.hpp#L37-L41 > > src/hotspot/share/runtime/os.hpp line 302: > >> 300: // platforms, usable as a compile-time constant. >> 301: static const size_t max_page_size_crossplatform = 64 * K; // ppc has 64 K pages. >> 302: > > What is this for?? A remnant of an older implementation that slipped through. Thanks for catching, I'll remove it. ------------- PR: https://git.openjdk.java.net/jdk/pull/7865 From stuefe at openjdk.java.net Tue Apr 12 08:04:36 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 12 Apr 2022 08:04:36 GMT Subject: RFR: JDK-8283326: Implement SafeFetch statically In-Reply-To: References: Message-ID: <9BGBtAqglhKczAzMQdE135flLhoE9WyZwI2QdfAYmK0=.17f5f278-2f7c-4fa7-a475-fb387a76428a@github.com> On Mon, 11 Apr 2022 10:07:29 GMT, Florian Weimer wrote: >> Hi, >> >> This is a reimplementation of SafeFetch to get rid of dynamic code generation. This is done, depending on platform, via static assembly, Posix setjmp/longjmp or SEH. >> >> This is based on a proposal by @theRealAph [1] when discussing [JDK-8282475](https://bugs.openjdk.java.net/browse/JDK-8282475). I extended the proposal to do this for all platforms, not just MacOS, see discussion below. >> >> --- >> >> Why we do this: >> >> SafeFetch is special: it is a basic utility function that may be called before the VM is properly initialized, from a "foreign" thread not attached to the VM, in a broken environment... mainly this is due to its use during stack walking, error reporting, hex dumping, etc. SafeFetch has to be safe to call under any circumstances - or as safe as we can make it. >> >> Today, SafeFetch is implemented via stub routines. That causes problems: >> >> - MacOs aarch64 has mechanisms to prevent execution of arbitrary non-text memory. On that platform, invoking generated code requires some awkward gymnastics [2]. These workarounds require access to Thread::current, which renders SafeFetch non-functional if Thread::current is NULL (e.g. crash reporting in "foreign" native threads or in a corrupted VM). They also cost a bit of performance on every SafeFetch invocation. Note that more OSes may implement similar execution prevention mechanics in the future. >> >> - There is a time window during VM initialization where the stubs are not generated yet and thus SafeFetch is not available. >> >> Both points cause hs-err files to be compromised (e.g. missing call stacks) for crashes in native threads, when the VM is corrupted, or early during VM initialization. Since SafeFetch is such a basic tool, it causes more issues than that (e.g., on AIX it is used for verifying mprotect() itself). But hs-err files being compromised by secondary errors is the most annoying effect. >> >> A minor point is that generating stubs takes a tiny bit of startup time. Not a big issue, but anything we can generate at build time instead of at runtime is good. >> >> --- >> >> The patch: >> >> - Removes the SafeFetch stub routine generation for all platforms >> - For Linux and MacOS, it implements SafeFetch as cpu-specific static assembler routines. These routines live in `os_cpu/_/safefetch__.S`. >> - On Windows, SafeFetch is implemented via SEH. This is beautifully simple and does not need handwritten assembly at all. See `os/windows/safefetch_windows.hpp`. >> - On Zero, SafeFetch uses a Posix compatible solution using `sigsetjmp(2)`. This is portable and robust, but a bit slow compared to the other methods. Note that this solution existed before, and is well tested. I just moved the code around and massaged it a bit. >> - AIX uses now the same method as Zero. AIX "downgraded" in that sense from the stub routine solution, but since SAP gave up maintenance of AIX, I don't have easy access to AIX hardware. If SafeFetch speed becomes an issue, I am sure a solution based on static assembly can be implemented on AIX too. >> - The SafeFetch gtests were greatly expanded. >> >> Tests: >> >> - The patch was tested manually by building and running gtests on: >> - MacOS (x64, aarch64) >> - Linux (aarch64, arm, ppcle, s390, x64, x86, riscv) >> - Windows (x64 and x86, but not arm, see below) >> - AIX >> - Zero (on Linux x64). >> - GHAs >> - The patch ran through SAP nightlies for several nights in a row >> >> Note: >> - I have no access to Windows arm, so I could not test it. I contacted @mo-beck to verify that the patch works there. >> - I have no access to BSD. I am not sure who maintains BSD, so I have no idea who to contact. However, I believe the MacOS solution should work for BSD too. If not, BSD can simply fall back to the Posix sigjmp solution like AIX and Zero. >> >> It would be nice to have @RealLucy, @TheRealMDoerr and @theRealAph to okay s390, ppcle and aarch64 (and possibly arm32). Each assembly file is tiny, so it should not take long. @RealFYang and @backwaterred already tested the patch on RiscV and AIX (thanks). >> >> Thanks, Thomas >> >> [1] https://github.com/openjdk/jdk/pull/7727#issuecomment-1064980598 >> [2] https://github.com/openjdk/jdk/blob/4df67426ed02f18af0757897acb28b636a317a91/src/hotspot/share/runtime/safefetch.inline.hpp#L37-L41 > > src/hotspot/os/posix/safefetch_sigjmp.cpp line 85: > >> 83: >> 84: // unsafe access >> 85: n = *adr; > > Maybe this should use `*const_cast(adr)` to force the read? I am not sure why this would be needed? ------------- PR: https://git.openjdk.java.net/jdk/pull/7865 From stuefe at openjdk.java.net Tue Apr 12 09:12:41 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 12 Apr 2022 09:12:41 GMT Subject: RFR: JDK-8283326: Implement SafeFetch statically In-Reply-To: References: Message-ID: On Mon, 11 Apr 2022 17:38:14 GMT, Anton Kozlov wrote: >> Hi, >> >> This is a reimplementation of SafeFetch to get rid of dynamic code generation. This is done, depending on platform, via static assembly, Posix setjmp/longjmp or SEH. >> >> This is based on a proposal by @theRealAph [1] when discussing [JDK-8282475](https://bugs.openjdk.java.net/browse/JDK-8282475). I extended the proposal to do this for all platforms, not just MacOS, see discussion below. >> >> --- >> >> Why we do this: >> >> SafeFetch is special: it is a basic utility function that may be called before the VM is properly initialized, from a "foreign" thread not attached to the VM, in a broken environment... mainly this is due to its use during stack walking, error reporting, hex dumping, etc. SafeFetch has to be safe to call under any circumstances - or as safe as we can make it. >> >> Today, SafeFetch is implemented via stub routines. That causes problems: >> >> - MacOs aarch64 has mechanisms to prevent execution of arbitrary non-text memory. On that platform, invoking generated code requires some awkward gymnastics [2]. These workarounds require access to Thread::current, which renders SafeFetch non-functional if Thread::current is NULL (e.g. crash reporting in "foreign" native threads or in a corrupted VM). They also cost a bit of performance on every SafeFetch invocation. Note that more OSes may implement similar execution prevention mechanics in the future. >> >> - There is a time window during VM initialization where the stubs are not generated yet and thus SafeFetch is not available. >> >> Both points cause hs-err files to be compromised (e.g. missing call stacks) for crashes in native threads, when the VM is corrupted, or early during VM initialization. Since SafeFetch is such a basic tool, it causes more issues than that (e.g., on AIX it is used for verifying mprotect() itself). But hs-err files being compromised by secondary errors is the most annoying effect. >> >> A minor point is that generating stubs takes a tiny bit of startup time. Not a big issue, but anything we can generate at build time instead of at runtime is good. >> >> --- >> >> The patch: >> >> - Removes the SafeFetch stub routine generation for all platforms >> - For Linux and MacOS, it implements SafeFetch as cpu-specific static assembler routines. These routines live in `os_cpu/_/safefetch__.S`. >> - On Windows, SafeFetch is implemented via SEH. This is beautifully simple and does not need handwritten assembly at all. See `os/windows/safefetch_windows.hpp`. >> - On Zero, SafeFetch uses a Posix compatible solution using `sigsetjmp(2)`. This is portable and robust, but a bit slow compared to the other methods. Note that this solution existed before, and is well tested. I just moved the code around and massaged it a bit. >> - AIX uses now the same method as Zero. AIX "downgraded" in that sense from the stub routine solution, but since SAP gave up maintenance of AIX, I don't have easy access to AIX hardware. If SafeFetch speed becomes an issue, I am sure a solution based on static assembly can be implemented on AIX too. >> - The SafeFetch gtests were greatly expanded. >> >> Tests: >> >> - The patch was tested manually by building and running gtests on: >> - MacOS (x64, aarch64) >> - Linux (aarch64, arm, ppcle, s390, x64, x86, riscv) >> - Windows (x64 and x86, but not arm, see below) >> - AIX >> - Zero (on Linux x64). >> - GHAs >> - The patch ran through SAP nightlies for several nights in a row >> >> Note: >> - I have no access to Windows arm, so I could not test it. I contacted @mo-beck to verify that the patch works there. >> - I have no access to BSD. I am not sure who maintains BSD, so I have no idea who to contact. However, I believe the MacOS solution should work for BSD too. If not, BSD can simply fall back to the Posix sigjmp solution like AIX and Zero. >> >> It would be nice to have @RealLucy, @TheRealMDoerr and @theRealAph to okay s390, ppcle and aarch64 (and possibly arm32). Each assembly file is tiny, so it should not take long. @RealFYang and @backwaterred already tested the patch on RiscV and AIX (thanks). >> >> Thanks, Thomas >> >> [1] https://github.com/openjdk/jdk/pull/7727#issuecomment-1064980598 >> [2] https://github.com/openjdk/jdk/blob/4df67426ed02f18af0757897acb28b636a317a91/src/hotspot/share/runtime/safefetch.inline.hpp#L37-L41 > > src/hotspot/os_cpu/bsd_aarch64/safefetch_bsd_aarch64.S line 55: > >> 53: SYMBOL(_SafeFetch32_continuation): >> 54: mov x0, x1 >> 55: ret > > Minor: on RISC platforms you seems to prefer to pack exceptional and non-exceptional paths, and on x86 they are separated. If we align this with x86, we'd save an instruction in each execution of non-exceptional path, with an extra instruction in static code. > > ldr w0, [x0] > ret > SYMBOL(_SafeFetch32_continuation): > mov x0, x1 > ret I'm surprised this would work. Can you really specify the same register as load destination and as load source? ------------- PR: https://git.openjdk.java.net/jdk/pull/7865 From duke at openjdk.java.net Tue Apr 12 09:31:39 2022 From: duke at openjdk.java.net (Tobias Holenstein) Date: Tue, 12 Apr 2022 09:31:39 GMT Subject: RFR: JDK-8075816: AliasLevel is broken and should be deprecated [v2] In-Reply-To: References: Message-ID: On Mon, 11 Apr 2022 16:10:38 GMT, Vladimir Kozlov wrote: >> Tobias Holenstein has updated the pull request incrementally with one additional commit since the last revision: >> >> Obsolete AliasLevel flag > > src/hotspot/share/opto/compile.cpp line 1051: > >> 1049: aliaslevel = 2; // No unique types without escape analysis >> 1050: } >> 1051: _AliasLevel = aliaslevel; > > Please, test with EA switched off `-XX:-DoEscapeAnalysis` > There are tests which switch it off. Also it is off in tier7 and tier8 for compiler tests. So I am puzzled that bug say that it crash with `aliasLevel=2`. > Also update subject of PR to match new bug's subject. You are right: the statement in the bug report that `AliasLevel<3` is broken is wrong. The VM crashes for `AliasLevel=0` and `AliasLevel=1` but not for `AliasLevel=2`. So with `-XX:-DoEscapeAnalysis` it is always automatically set to`AliasLevel=2`. But when `-XX:+DoEscapeAnalysis -XX:+EliminateAllocations` there is ONE use-case for `AliasLevel` : https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/escape.cpp#L336-L341 - for `-XX:AliasLevel=3` `split_unique_types(alloc_worklist, arraycopy_worklist, mergemem_worklist);` is called - for `-XX:AliasLevel=2` `split_unique_types(alloc_worklist, arraycopy_worklist, mergemem_worklist);` is NOT called So does the use case `-XX:+DoEscapeAnalysis -XX:+EliminateAllocations -XX:AliasLevel=2` make sense and is it something that is used? Since `AliasLevel` is not completely broken the question is if we should deprecated instead of making it obsolete? ------------- PR: https://git.openjdk.java.net/jdk/pull/8140 From stuefe at openjdk.java.net Tue Apr 12 09:36:42 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 12 Apr 2022 09:36:42 GMT Subject: RFR: JDK-8283326: Implement SafeFetch statically In-Reply-To: References: Message-ID: On Tue, 12 Apr 2022 02:37:05 GMT, David Holmes wrote: > > On Posix platforms you can use either static assembly or setjmp, and need to exclude one of them from compilation - either build safefetch_xx_xx.S, or build safefetch_sigjmp.cpp. > > Yes but we don't need to make this build time selectable. If a platform supports static then it will have a .S file and won't use the sigjmp file (which will be empty due to ifdef based on platform); otherwise no .S file and the sigjmp file is populated. > How would this work? You would add a "#if defined(zero) && defined(aix) &&..." to safefetch_sigjmp.cpp? I honestly find this less readable and grep-able than now... ------------- PR: https://git.openjdk.java.net/jdk/pull/7865 From stuefe at openjdk.java.net Tue Apr 12 09:46:36 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 12 Apr 2022 09:46:36 GMT Subject: RFR: JDK-8283326: Implement SafeFetch statically In-Reply-To: References: Message-ID: On Tue, 12 Apr 2022 09:09:47 GMT, Thomas Stuefe wrote: >> src/hotspot/os_cpu/bsd_aarch64/safefetch_bsd_aarch64.S line 55: >> >>> 53: SYMBOL(_SafeFetch32_continuation): >>> 54: mov x0, x1 >>> 55: ret >> >> Minor: on RISC platforms you seems to prefer to pack exceptional and non-exceptional paths, and on x86 they are separated. If we align this with x86, we'd save an instruction in each execution of non-exceptional path, with an extra instruction in static code. >> >> ldr w0, [x0] >> ret >> SYMBOL(_SafeFetch32_continuation): >> mov x0, x1 >> ret > > I'm surprised this would work. Can you really specify the same register as load destination and as load source? Ah, it seems to work. You live and learn :) ------------- PR: https://git.openjdk.java.net/jdk/pull/7865 From dholmes at openjdk.java.net Tue Apr 12 10:23:49 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 12 Apr 2022 10:23:49 GMT Subject: RFR: JDK-8283326: Implement SafeFetch statically In-Reply-To: References: Message-ID: <0SaQuDYi09bbLSlhwHDnGdIuQgv7vimnvzbtIl6Ku78=.6c3f753d-bd9d-45ed-affd-e036d9acad3b@github.com> On Mon, 11 Apr 2022 06:20:50 GMT, David Holmes wrote: >> Hi, >> >> This is a reimplementation of SafeFetch to get rid of dynamic code generation. This is done, depending on platform, via static assembly, Posix setjmp/longjmp or SEH. >> >> This is based on a proposal by @theRealAph [1] when discussing [JDK-8282475](https://bugs.openjdk.java.net/browse/JDK-8282475). I extended the proposal to do this for all platforms, not just MacOS, see discussion below. >> >> --- >> >> Why we do this: >> >> SafeFetch is special: it is a basic utility function that may be called before the VM is properly initialized, from a "foreign" thread not attached to the VM, in a broken environment... mainly this is due to its use during stack walking, error reporting, hex dumping, etc. SafeFetch has to be safe to call under any circumstances - or as safe as we can make it. >> >> Today, SafeFetch is implemented via stub routines. That causes problems: >> >> - MacOs aarch64 has mechanisms to prevent execution of arbitrary non-text memory. On that platform, invoking generated code requires some awkward gymnastics [2]. These workarounds require access to Thread::current, which renders SafeFetch non-functional if Thread::current is NULL (e.g. crash reporting in "foreign" native threads or in a corrupted VM). They also cost a bit of performance on every SafeFetch invocation. Note that more OSes may implement similar execution prevention mechanics in the future. >> >> - There is a time window during VM initialization where the stubs are not generated yet and thus SafeFetch is not available. >> >> Both points cause hs-err files to be compromised (e.g. missing call stacks) for crashes in native threads, when the VM is corrupted, or early during VM initialization. Since SafeFetch is such a basic tool, it causes more issues than that (e.g., on AIX it is used for verifying mprotect() itself). But hs-err files being compromised by secondary errors is the most annoying effect. >> >> A minor point is that generating stubs takes a tiny bit of startup time. Not a big issue, but anything we can generate at build time instead of at runtime is good. >> >> --- >> >> The patch: >> >> - Removes the SafeFetch stub routine generation for all platforms >> - For Linux and MacOS, it implements SafeFetch as cpu-specific static assembler routines. These routines live in `os_cpu/_/safefetch__.S`. >> - On Windows, SafeFetch is implemented via SEH. This is beautifully simple and does not need handwritten assembly at all. See `os/windows/safefetch_windows.hpp`. >> - On Zero, SafeFetch uses a Posix compatible solution using `sigsetjmp(2)`. This is portable and robust, but a bit slow compared to the other methods. Note that this solution existed before, and is well tested. I just moved the code around and massaged it a bit. >> - AIX uses now the same method as Zero. AIX "downgraded" in that sense from the stub routine solution, but since SAP gave up maintenance of AIX, I don't have easy access to AIX hardware. If SafeFetch speed becomes an issue, I am sure a solution based on static assembly can be implemented on AIX too. >> - The SafeFetch gtests were greatly expanded. >> >> Tests: >> >> - The patch was tested manually by building and running gtests on: >> - MacOS (x64, aarch64) >> - Linux (aarch64, arm, ppcle, s390, x64, x86, riscv) >> - Windows (x64 and x86, but not arm, see below) >> - AIX >> - Zero (on Linux x64). >> - GHAs >> - The patch ran through SAP nightlies for several nights in a row >> >> Note: >> - I have no access to Windows arm, so I could not test it. I contacted @mo-beck to verify that the patch works there. >> - I have no access to BSD. I am not sure who maintains BSD, so I have no idea who to contact. However, I believe the MacOS solution should work for BSD too. If not, BSD can simply fall back to the Posix sigjmp solution like AIX and Zero. >> >> It would be nice to have @RealLucy, @TheRealMDoerr and @theRealAph to okay s390, ppcle and aarch64 (and possibly arm32). Each assembly file is tiny, so it should not take long. @RealFYang and @backwaterred already tested the patch on RiscV and AIX (thanks). >> >> Thanks, Thomas >> >> [1] https://github.com/openjdk/jdk/pull/7727#issuecomment-1064980598 >> [2] https://github.com/openjdk/jdk/blob/4df67426ed02f18af0757897acb28b636a317a91/src/hotspot/share/runtime/safefetch.inline.hpp#L37-L41 > > src/hotspot/os/posix/signals_posix.cpp line 614: > >> 612: } >> 613: >> 614: #if defined(SAFEFETCH_METHOD_STATIC_ASSEMBLY) || defined(SAFEFETCH_METHOD_SIGSETJMP) > > The guard seems unnecessary - all posix platforms need to handle safefetch here don't they? Sorry how is this "resolved". Every posix platform will define one of those cases so this code is effectively unconditional. ------------- PR: https://git.openjdk.java.net/jdk/pull/7865 From dholmes at openjdk.java.net Tue Apr 12 10:23:52 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 12 Apr 2022 10:23:52 GMT Subject: RFR: JDK-8283326: Implement SafeFetch statically In-Reply-To: References: Message-ID: On Mon, 11 Apr 2022 06:21:19 GMT, David Holmes wrote: >> src/hotspot/os/posix/vmError_posix.cpp line 79: >> >>> 77: >>> 78: #if defined(SAFEFETCH_METHOD_STATIC_ASSEMBLY) || defined(SAFEFETCH_METHOD_SIGSETJMP) >>> 79: // Handle safefetch here too, to be able to use SafeFetc() inside the error handler >> >> Typo: SafeFetc() > > Ditto regarding whether the guard is needed. Again this code is effectively unconditional - the ifdefs are not needed. ------------- PR: https://git.openjdk.java.net/jdk/pull/7865 From mcimadamore at openjdk.java.net Tue Apr 12 10:24:47 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 12 Apr 2022 10:24:47 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v27] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/424 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Add @ForceInline annotation on session accessor Beef up UnrolledAccess benchmark ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7888/files - new: https://git.openjdk.java.net/jdk/pull/7888/files/a68195ae..66cebe77 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=26 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=25-26 Stats: 32 lines in 2 files changed: 32 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7888.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888 PR: https://git.openjdk.java.net/jdk/pull/7888 From dholmes at openjdk.java.net Tue Apr 12 10:27:36 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 12 Apr 2022 10:27:36 GMT Subject: RFR: JDK-8283326: Implement SafeFetch statically In-Reply-To: References: Message-ID: On Tue, 12 Apr 2022 09:33:04 GMT, Thomas Stuefe wrote: > How would this work? You would add a "#if defined(zero) && defined(aix) &&..." to safefetch_sigjmp.cpp? > > I honestly find this less readable and grep-able than now... I missed the use of SAFEFETCH_METHOD_SIGSETJMP to control the compilation of safefetch_sigjmp.cpp, but that is the only define that you need. Posix systems are either setjmp or static the only file that needs to know that is safefetch_sigjmp.cpp. ------------- PR: https://git.openjdk.java.net/jdk/pull/7865 From stuefe at openjdk.java.net Tue Apr 12 10:42:33 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 12 Apr 2022 10:42:33 GMT Subject: RFR: JDK-8283326: Implement SafeFetch statically In-Reply-To: <0SaQuDYi09bbLSlhwHDnGdIuQgv7vimnvzbtIl6Ku78=.6c3f753d-bd9d-45ed-affd-e036d9acad3b@github.com> References: <0SaQuDYi09bbLSlhwHDnGdIuQgv7vimnvzbtIl6Ku78=.6c3f753d-bd9d-45ed-affd-e036d9acad3b@github.com> Message-ID: On Tue, 12 Apr 2022 10:19:59 GMT, David Holmes wrote: >> src/hotspot/os/posix/signals_posix.cpp line 614: >> >>> 612: } >>> 613: >>> 614: #if defined(SAFEFETCH_METHOD_STATIC_ASSEMBLY) || defined(SAFEFETCH_METHOD_SIGSETJMP) >> >> The guard seems unnecessary - all posix platforms need to handle safefetch here don't they? > > Sorry how is this "resolved". Every posix platform will define one of those cases so this code is effectively unconditional. I use "resolved" to mark my internal progress, which you may not see yet since I did not push yet. Probably should not use "resolve". ------------- PR: https://git.openjdk.java.net/jdk/pull/7865 From thartmann at openjdk.java.net Tue Apr 12 10:45:33 2022 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Tue, 12 Apr 2022 10:45:33 GMT Subject: RFR: JDK-8075816: AliasLevel is broken and should be deprecated [v2] In-Reply-To: References: Message-ID: On Tue, 12 Apr 2022 09:28:00 GMT, Tobias Holenstein wrote: >> src/hotspot/share/opto/compile.cpp line 1051: >> >>> 1049: aliaslevel = 2; // No unique types without escape analysis >>> 1050: } >>> 1051: _AliasLevel = aliaslevel; >> >> Please, test with EA switched off `-XX:-DoEscapeAnalysis` >> There are tests which switch it off. Also it is off in tier7 and tier8 for compiler tests. So I am puzzled that bug say that it crash with `aliasLevel=2`. >> Also update subject of PR to match new bug's subject. > > You are right: the statement in the bug report that `AliasLevel<3` is broken is wrong. The VM crashes for `AliasLevel=0` and `AliasLevel=1` but not for `AliasLevel=2`. So with `-XX:-DoEscapeAnalysis` it is always automatically set to`AliasLevel=2`. > But when `-XX:+DoEscapeAnalysis -XX:+EliminateAllocations` there is ONE use-case for `AliasLevel` : > https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/escape.cpp#L336-L341 > - for `-XX:AliasLevel=3` `split_unique_types(alloc_worklist, arraycopy_worklist, mergemem_worklist);` is called > - for `-XX:AliasLevel=2` `split_unique_types(alloc_worklist, arraycopy_worklist, mergemem_worklist);` is NOT called > > So does the use case `-XX:+DoEscapeAnalysis -XX:+EliminateAllocations -XX:AliasLevel=2` make sense and is it something that is used? > > Since `AliasLevel` is not completely broken the question is if we should deprecated instead of making it obsolete? I don't think there is a real use case for `-XX:AliasLevel=2` given that one can get similar behavior with `-XX:-EliminateAllocations` (or `-XX:-DoEscapeAnalysis`). I would therefore vote for **deprecating** `AliasLevel`. ------------- PR: https://git.openjdk.java.net/jdk/pull/8140 From eliu at openjdk.java.net Tue Apr 12 10:48:27 2022 From: eliu at openjdk.java.net (Eric Liu) Date: Tue, 12 Apr 2022 10:48:27 GMT Subject: RFR: 8282528: AArch64: Incorrect replicate2L_zero rule [v4] In-Reply-To: References: Message-ID: > This patch fixes the wrong matching rule of replicate2L_zero. It was > matched "ReplicateI" by mistake so that long immediates(not only zero) > had to be moved to register first and matched to replicate2L finally. To > fix this trivial bug, this patch fixes the typo and extends the rule of > replicate2L_zero to replicate2L_imm, which now supports all possible > long immediate values. > > The final code changes are shown as below: > > replicate2L_imm: > > mov x13, #0xff > movk x13, #0xff, lsl #16 > movk x13, #0xff, lsl #32 > dup v16.2d, x13 > > => > > movi v16.2d, #0xff00ff00ff > > [Test] > test/jdk/jdk/incubator/vector, test/hotspot/jtreg/compiler/vectorapi > passed without failure. Eric Liu has updated the pull request incrementally with one additional commit since the last revision: remove ifelse which is triggered by empty args Change-Id: I461e62495c7abc0f84ef1f66443f6bcf7adbeff0 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7939/files - new: https://git.openjdk.java.net/jdk/pull/7939/files/19afc185..fb250776 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7939&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7939&range=02-03 Stats: 34 lines in 1 file changed: 6 ins; 0 del; 28 mod Patch: https://git.openjdk.java.net/jdk/pull/7939.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7939/head:pull/7939 PR: https://git.openjdk.java.net/jdk/pull/7939 From eliu at openjdk.java.net Tue Apr 12 10:48:28 2022 From: eliu at openjdk.java.net (Eric Liu) Date: Tue, 12 Apr 2022 10:48:28 GMT Subject: RFR: 8282528: AArch64: Incorrect replicate2L_zero rule [v2] In-Reply-To: References: Message-ID: <0DgY73dU0fUzcwWS46aqxCEToTRSxelMeBDdV7K4Vh0=.7bbcddb0-71fc-4de6-9145-c0d78f382420@github.com> On Mon, 11 Apr 2022 12:37:57 GMT, Andrew Haley wrote: >> Done. I think these rules should not have been merged by force. It's hard to maintain. > > It doesn't look too awful. Having said that, if I were you I'd get rid of all the `ifelse` expressions triggered by empty args. Thanks for your suggestion. Fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/7939 From stuefe at openjdk.java.net Tue Apr 12 10:48:44 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 12 Apr 2022 10:48:44 GMT Subject: RFR: JDK-8283326: Implement SafeFetch statically In-Reply-To: References: Message-ID: On Tue, 12 Apr 2022 10:24:39 GMT, David Holmes wrote: > > How would this work? You would add a "#if defined(zero) && defined(aix) &&..." to safefetch_sigjmp.cpp? > > I honestly find this less readable and grep-able than now... > > I missed the use of SAFEFETCH_METHOD_SIGSETJMP to control the compilation of safefetch_sigjmp.cpp, but that is the only define that you need. Posix systems are either setjmp or static the only file that needs to know that is safefetch_sigjmp.cpp. That, and safefetch_static.cpp. Those two files contain the two variants of handle_safefetch(). ------------- PR: https://git.openjdk.java.net/jdk/pull/7865 From akozlov at openjdk.java.net Tue Apr 12 10:53:28 2022 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Tue, 12 Apr 2022 10:53:28 GMT Subject: RFR: JDK-8283326: Implement SafeFetch statically In-Reply-To: References: Message-ID: <4j7vefwOkhT5rNHSDg6dAowyOt31xSvHrjz7aHAf2fs=.d04ffebf-9ec6-41cc-81dd-20b1a914ac11@github.com> On Tue, 12 Apr 2022 09:43:41 GMT, Thomas Stuefe wrote: >> I'm surprised this would work. Can you really specify the same register as load destination and as load source? > > Ah, it seems to work. You live and learn :) Yes, on arm32/64 it would not work if the instruction uses a register as a target and write-back, like `ldr r0, [r0, 4]!`, otherwise it's OK. AFAIR, it's also OK on ppc. As a reference, I've checked the output of gcc/clang, both don't use the extra register, so the argument regarding performance looks valid :) Not insisting on fixing, this is indeed minor. anton at mercury:/tmp$ cat test.c long test(long* addr) { return *addr; } anton at mercury:/tmp$ aarch64-linux-gnu-gcc --version aarch64-linux-gnu-gcc (GCC) 11.2.0 anton at mercury:/tmp$ aarch64-linux-gnu-gcc -c -O3 -o test.o test.c anton at mercury:/tmp$ aarch64-linux-gnu-objdump -d test.o 0000000000000000 : 0: f9400000 ldr x0, [x0] 4: d65f03c0 ret ------------- PR: https://git.openjdk.java.net/jdk/pull/7865 From stuefe at openjdk.java.net Tue Apr 12 11:23:01 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 12 Apr 2022 11:23:01 GMT Subject: RFR: JDK-8283326: Implement SafeFetch statically [v2] In-Reply-To: References: Message-ID: <5JIL3N8hmdEx4fTdcfPsV30Opa3MOgdgsI8E3A8gofo=.c58b72b9-438f-490d-ad68-0c8dbd06146b@github.com> > Hi, > > This is a reimplementation of SafeFetch to get rid of dynamic code generation. This is done, depending on platform, via static assembly, Posix setjmp/longjmp or SEH. > > This is based on a proposal by @theRealAph [1] when discussing [JDK-8282475](https://bugs.openjdk.java.net/browse/JDK-8282475). I extended the proposal to do this for all platforms, not just MacOS, see discussion below. > > --- > > Why we do this: > > SafeFetch is special: it is a basic utility function that may be called before the VM is properly initialized, from a "foreign" thread not attached to the VM, in a broken environment... mainly this is due to its use during stack walking, error reporting, hex dumping, etc. SafeFetch has to be safe to call under any circumstances - or as safe as we can make it. > > Today, SafeFetch is implemented via stub routines. That causes problems: > > - MacOs aarch64 has mechanisms to prevent execution of arbitrary non-text memory. On that platform, invoking generated code requires some awkward gymnastics [2]. These workarounds require access to Thread::current, which renders SafeFetch non-functional if Thread::current is NULL (e.g. crash reporting in "foreign" native threads or in a corrupted VM). They also cost a bit of performance on every SafeFetch invocation. Note that more OSes may implement similar execution prevention mechanics in the future. > > - There is a time window during VM initialization where the stubs are not generated yet and thus SafeFetch is not available. > > Both points cause hs-err files to be compromised (e.g. missing call stacks) for crashes in native threads, when the VM is corrupted, or early during VM initialization. Since SafeFetch is such a basic tool, it causes more issues than that (e.g., on AIX it is used for verifying mprotect() itself). But hs-err files being compromised by secondary errors is the most annoying effect. > > A minor point is that generating stubs takes a tiny bit of startup time. Not a big issue, but anything we can generate at build time instead of at runtime is good. > > --- > > The patch: > > - Removes the SafeFetch stub routine generation for all platforms > - For Linux and MacOS, it implements SafeFetch as cpu-specific static assembler routines. These routines live in `os_cpu/_/safefetch__.S`. > - On Windows, SafeFetch is implemented via SEH. This is beautifully simple and does not need handwritten assembly at all. See `os/windows/safefetch_windows.hpp`. > - On Zero, SafeFetch uses a Posix compatible solution using `sigsetjmp(2)`. This is portable and robust, but a bit slow compared to the other methods. Note that this solution existed before, and is well tested. I just moved the code around and massaged it a bit. > - AIX uses now the same method as Zero. AIX "downgraded" in that sense from the stub routine solution, but since SAP gave up maintenance of AIX, I don't have easy access to AIX hardware. If SafeFetch speed becomes an issue, I am sure a solution based on static assembly can be implemented on AIX too. > - The SafeFetch gtests were greatly expanded. > > Tests: > > - The patch was tested manually by building and running gtests on: > - MacOS (x64, aarch64) > - Linux (aarch64, arm, ppcle, s390, x64, x86, riscv) > - Windows (x64 and x86, but not arm, see below) > - AIX > - Zero (on Linux x64). > - GHAs > - The patch ran through SAP nightlies for several nights in a row > > Note: > - I have no access to Windows arm, so I could not test it. I contacted @mo-beck to verify that the patch works there. > - I have no access to BSD. I am not sure who maintains BSD, so I have no idea who to contact. However, I believe the MacOS solution should work for BSD too. If not, BSD can simply fall back to the Posix sigjmp solution like AIX and Zero. > > It would be nice to have @RealLucy, @TheRealMDoerr and @theRealAph to okay s390, ppcle and aarch64 (and possibly arm32). Each assembly file is tiny, so it should not take long. @RealFYang and @backwaterred already tested the patch on RiscV and AIX (thanks). > > Thanks, Thomas > > [1] https://github.com/openjdk/jdk/pull/7727#issuecomment-1064980598 > [2] https://github.com/openjdk/jdk/blob/4df67426ed02f18af0757897acb28b636a317a91/src/hotspot/share/runtime/safefetch.inline.hpp#L37-L41 Thomas Stuefe has updated the pull request incrementally with ten additional commits since the last revision: - Change RISC implementations to use one op less per standard path - Reduce usage of SAFEFETCH_METHOD_ and remove SAFEFETCH_METHOD_SEH altogether - RiscV: Use ABI names - move safefetch_static.cpp to os/posix - remove CanUseSafeFetch - revert test code - minor-aesthetics - Add comment about pthread_getspecific signal safety - move pthread_setspecific out of signal handler ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7865/files - new: https://git.openjdk.java.net/jdk/pull/7865/files/f158cc37..8d1cc4ed Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7865&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7865&range=00-01 Stats: 116 lines in 20 files changed: 22 ins; 34 del; 60 mod Patch: https://git.openjdk.java.net/jdk/pull/7865.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7865/head:pull/7865 PR: https://git.openjdk.java.net/jdk/pull/7865 From stuefe at openjdk.java.net Tue Apr 12 11:23:03 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 12 Apr 2022 11:23:03 GMT Subject: RFR: JDK-8283326: Implement SafeFetch statically In-Reply-To: References: Message-ID: On Fri, 18 Mar 2022 08:52:46 GMT, Thomas Stuefe wrote: > Hi, > > This is a reimplementation of SafeFetch to get rid of dynamic code generation. This is done, depending on platform, via static assembly, Posix setjmp/longjmp or SEH. > > This is based on a proposal by @theRealAph [1] when discussing [JDK-8282475](https://bugs.openjdk.java.net/browse/JDK-8282475). I extended the proposal to do this for all platforms, not just MacOS, see discussion below. > > --- > > Why we do this: > > SafeFetch is special: it is a basic utility function that may be called before the VM is properly initialized, from a "foreign" thread not attached to the VM, in a broken environment... mainly this is due to its use during stack walking, error reporting, hex dumping, etc. SafeFetch has to be safe to call under any circumstances - or as safe as we can make it. > > Today, SafeFetch is implemented via stub routines. That causes problems: > > - MacOs aarch64 has mechanisms to prevent execution of arbitrary non-text memory. On that platform, invoking generated code requires some awkward gymnastics [2]. These workarounds require access to Thread::current, which renders SafeFetch non-functional if Thread::current is NULL (e.g. crash reporting in "foreign" native threads or in a corrupted VM). They also cost a bit of performance on every SafeFetch invocation. Note that more OSes may implement similar execution prevention mechanics in the future. > > - There is a time window during VM initialization where the stubs are not generated yet and thus SafeFetch is not available. > > Both points cause hs-err files to be compromised (e.g. missing call stacks) for crashes in native threads, when the VM is corrupted, or early during VM initialization. Since SafeFetch is such a basic tool, it causes more issues than that (e.g., on AIX it is used for verifying mprotect() itself). But hs-err files being compromised by secondary errors is the most annoying effect. > > A minor point is that generating stubs takes a tiny bit of startup time. Not a big issue, but anything we can generate at build time instead of at runtime is good. > > --- > > The patch: > > - Removes the SafeFetch stub routine generation for all platforms > - For Linux and MacOS, it implements SafeFetch as cpu-specific static assembler routines. These routines live in `os_cpu/_/safefetch__.S`. > - On Windows, SafeFetch is implemented via SEH. This is beautifully simple and does not need handwritten assembly at all. See `os/windows/safefetch_windows.hpp`. > - On Zero, SafeFetch uses a Posix compatible solution using `sigsetjmp(2)`. This is portable and robust, but a bit slow compared to the other methods. Note that this solution existed before, and is well tested. I just moved the code around and massaged it a bit. > - AIX uses now the same method as Zero. AIX "downgraded" in that sense from the stub routine solution, but since SAP gave up maintenance of AIX, I don't have easy access to AIX hardware. If SafeFetch speed becomes an issue, I am sure a solution based on static assembly can be implemented on AIX too. > - The SafeFetch gtests were greatly expanded. > > Tests: > > - The patch was tested manually by building and running gtests on: > - MacOS (x64, aarch64) > - Linux (aarch64, arm, ppcle, s390, x64, x86, riscv) > - Windows (x64 and x86, but not arm, see below) > - AIX > - Zero (on Linux x64). > - GHAs > - The patch ran through SAP nightlies for several nights in a row > > Note: > - I have no access to Windows arm, so I could not test it. I contacted @mo-beck to verify that the patch works there. > - I have no access to BSD. I am not sure who maintains BSD, so I have no idea who to contact. However, I believe the MacOS solution should work for BSD too. If not, BSD can simply fall back to the Posix sigjmp solution like AIX and Zero. > > It would be nice to have @RealLucy, @TheRealMDoerr and @theRealAph to okay s390, ppcle and aarch64 (and possibly arm32). Each assembly file is tiny, so it should not take long. @RealFYang and @backwaterred already tested the patch on RiscV and AIX (thanks). > > Thanks, Thomas > > [1] https://github.com/openjdk/jdk/pull/7727#issuecomment-1064980598 > [2] https://github.com/openjdk/jdk/blob/4df67426ed02f18af0757897acb28b636a317a91/src/hotspot/share/runtime/safefetch.inline.hpp#L37-L41 Hi David, Florian and Anton, thanks for reviewing this. Changes: - In safefetch_sigjmp.cpp, moved pthread_setspecific out of signal handling. Thanks to @fweimer-rh for catching this. - In safefetch_sigjmp.cpp, reset TLS slot before accessing output variable for writing. - Following Antons proposal, I removed CanSafeFetchxx. I wondered for a brief moment it was worth keeping it, since strictly speaking two of the three methods need signal handlers to work, so cannot work before we install the hotspot signal handler. But that would incur runtime checks which are not really useful in practice: all situations where SafeFetch are invoked are guaranteed to happen when signal handler has been installed (e.g. hs-err files can only get written if our handler runs). - Following Antons proposal, I changed the RISC implementations to use one operation less per standard path by loading into directly into the return register. - I whittled the usage of SAFEFETCH_METHOD_ macros down to the bare minimum needed to control which implementation Posix platforms use. - Moved safefetch_static.cpp to os/posix/safefetch_static_posix.cpp. + minor stuff, too small to mention, all review driven. Thanks for reviewing! Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/7865 From jvernee at openjdk.java.net Tue Apr 12 11:37:21 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Tue, 12 Apr 2022 11:37:21 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v3] In-Reply-To: References: Message-ID: > Hi, > > This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo. > > This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20. > > I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first. > > This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes: > > 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1]. > 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed [2], [3], [4], [5]. > 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later). > 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9]. > > While the patch mostly consists of VM changes, there are also some Java changes to support (2). > > The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier. > > Testing: Tier1-4 > > Thanks, > Jorn > > [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358 > [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49 > [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3 > [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3 > [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120 > [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a > [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062 > [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f > [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9 Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: Remove unneeded ComputeMoveOrder ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7959/files - new: https://git.openjdk.java.net/jdk/pull/7959/files/3434deda..a7b9f131 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=01-02 Stats: 174 lines in 1 file changed: 0 ins; 174 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7959.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7959/head:pull/7959 PR: https://git.openjdk.java.net/jdk/pull/7959 From coleenp at openjdk.java.net Tue Apr 12 12:08:53 2022 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 12 Apr 2022 12:08:53 GMT Subject: RFR: 8284274: Error reporting crashes because missing ResourceMarks Message-ID: Taking the suggestion from @stefank in the bug report, disable the ResourceMark missing assert during error reporting. There's a ResourceArea in the thread that can be used. Added a test. Tested with tier1-4 on x86 and aarch64 platforms. ------------- Commit messages: - 8284274: Error reporting crashes because missing ResourceMarks - 8284274: Error reporting crashes because missing ResourceMarks Changes: https://git.openjdk.java.net/jdk/pull/8201/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8201&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8284274 Stats: 129 lines in 3 files changed: 126 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/8201.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8201/head:pull/8201 PR: https://git.openjdk.java.net/jdk/pull/8201 From alanb at openjdk.java.net Tue Apr 12 13:05:33 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 12 Apr 2022 13:05:33 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) In-Reply-To: References: Message-ID: On Mon, 11 Apr 2022 17:27:11 GMT, Daniel Fuchs wrote: > Not sure if that even matters - but there will be a slight change of behaviour here if `InternalLock.CAN_USE_INTERNAL_LOCK` is ever `false`. Instead of synchronizing on `in`, the `BufferedReader` will synchronize on `this`. Good! We can change this so that depends on whether BufferedReader is extended and whether the given Reader is trusted. It's not clear if anyone could reliably depend on undocumented behavior like this but we have to be cautious at the same time. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From dholmes at openjdk.java.net Tue Apr 12 13:07:55 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 12 Apr 2022 13:07:55 GMT Subject: RFR: JDK-8283326: Implement SafeFetch statically [v2] In-Reply-To: <5JIL3N8hmdEx4fTdcfPsV30Opa3MOgdgsI8E3A8gofo=.c58b72b9-438f-490d-ad68-0c8dbd06146b@github.com> References: <5JIL3N8hmdEx4fTdcfPsV30Opa3MOgdgsI8E3A8gofo=.c58b72b9-438f-490d-ad68-0c8dbd06146b@github.com> Message-ID: On Tue, 12 Apr 2022 11:23:01 GMT, Thomas Stuefe wrote: >> Hi, >> >> This is a reimplementation of SafeFetch to get rid of dynamic code generation. This is done, depending on platform, via static assembly, Posix setjmp/longjmp or SEH. >> >> This is based on a proposal by @theRealAph [1] when discussing [JDK-8282475](https://bugs.openjdk.java.net/browse/JDK-8282475). I extended the proposal to do this for all platforms, not just MacOS, see discussion below. >> >> --- >> >> Why we do this: >> >> SafeFetch is special: it is a basic utility function that may be called before the VM is properly initialized, from a "foreign" thread not attached to the VM, in a broken environment... mainly this is due to its use during stack walking, error reporting, hex dumping, etc. SafeFetch has to be safe to call under any circumstances - or as safe as we can make it. >> >> Today, SafeFetch is implemented via stub routines. That causes problems: >> >> - MacOs aarch64 has mechanisms to prevent execution of arbitrary non-text memory. On that platform, invoking generated code requires some awkward gymnastics [2]. These workarounds require access to Thread::current, which renders SafeFetch non-functional if Thread::current is NULL (e.g. crash reporting in "foreign" native threads or in a corrupted VM). They also cost a bit of performance on every SafeFetch invocation. Note that more OSes may implement similar execution prevention mechanics in the future. >> >> - There is a time window during VM initialization where the stubs are not generated yet and thus SafeFetch is not available. >> >> Both points cause hs-err files to be compromised (e.g. missing call stacks) for crashes in native threads, when the VM is corrupted, or early during VM initialization. Since SafeFetch is such a basic tool, it causes more issues than that (e.g., on AIX it is used for verifying mprotect() itself). But hs-err files being compromised by secondary errors is the most annoying effect. >> >> A minor point is that generating stubs takes a tiny bit of startup time. Not a big issue, but anything we can generate at build time instead of at runtime is good. >> >> --- >> >> The patch: >> >> - Removes the SafeFetch stub routine generation for all platforms >> - For Linux and MacOS, it implements SafeFetch as cpu-specific static assembler routines. These routines live in `os_cpu/_/safefetch__.S`. >> - On Windows, SafeFetch is implemented via SEH. This is beautifully simple and does not need handwritten assembly at all. See `os/windows/safefetch_windows.hpp`. >> - On Zero, SafeFetch uses a Posix compatible solution using `sigsetjmp(2)`. This is portable and robust, but a bit slow compared to the other methods. Note that this solution existed before, and is well tested. I just moved the code around and massaged it a bit. >> - AIX uses now the same method as Zero. AIX "downgraded" in that sense from the stub routine solution, but since SAP gave up maintenance of AIX, I don't have easy access to AIX hardware. If SafeFetch speed becomes an issue, I am sure a solution based on static assembly can be implemented on AIX too. >> - The SafeFetch gtests were greatly expanded. >> >> Tests: >> >> - The patch was tested manually by building and running gtests on: >> - MacOS (x64, aarch64) >> - Linux (aarch64, arm, ppcle, s390, x64, x86, riscv) >> - Windows (x64 and x86, but not arm, see below) >> - AIX >> - Zero (on Linux x64). >> - GHAs >> - The patch ran through SAP nightlies for several nights in a row >> >> Note: >> - I have no access to Windows arm, so I could not test it. I contacted @mo-beck to verify that the patch works there. >> - I have no access to BSD. I am not sure who maintains BSD, so I have no idea who to contact. However, I believe the MacOS solution should work for BSD too. If not, BSD can simply fall back to the Posix sigjmp solution like AIX and Zero. >> >> It would be nice to have @RealLucy, @TheRealMDoerr and @theRealAph to okay s390, ppcle and aarch64 (and possibly arm32). Each assembly file is tiny, so it should not take long. @RealFYang and @backwaterred already tested the patch on RiscV and AIX (thanks). >> >> Thanks, Thomas >> >> [1] https://github.com/openjdk/jdk/pull/7727#issuecomment-1064980598 >> [2] https://github.com/openjdk/jdk/blob/4df67426ed02f18af0757897acb28b636a317a91/src/hotspot/share/runtime/safefetch.inline.hpp#L37-L41 > > Thomas Stuefe has updated the pull request incrementally with ten additional commits since the last revision: > > - Change RISC implementations to use one op less per standard path > - Reduce usage of SAFEFETCH_METHOD_ and remove SAFEFETCH_METHOD_SEH altogether > - RiscV: Use ABI names > - move safefetch_static.cpp to os/posix > - remove CanUseSafeFetch > - revert test code > - minor-aesthetics > - Add comment about pthread_getspecific signal safety > - move pthread_setspecific out of signal handler Updates look good - thanks. I think perhaps we could simplify the ifdefs even further but I'm okay with them as they are. Thanks, David src/hotspot/share/runtime/os.cpp line 1048: > 1046: // Helps to prove validity of a not-NULL pointer. > 1047: // Returns true in very early stages of VM life when stub is not yet generated. > 1048: #define SAFEFETCH_DEFAULT true This is dead code now. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7865 From stuefe at openjdk.java.net Tue Apr 12 13:23:24 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 12 Apr 2022 13:23:24 GMT Subject: RFR: JDK-8284726: Print active locale settings in hs_err reports and in VM.info Message-ID: To analyze locale problems in native code - e.g. stemming from third-party code calling `setlocale(3)` - it would be useful to print the active locale settings in hs-err reports and in VM.info. Patch notes: - Posix is fuzzy about the exact role of LC_ALL. It defines LC_ALL as a way to set all locales in one go, but the implementation could still keep the individual categories separately and just let LC_ALL override the individual settings. Therefore I opted to print both, even though on glibc the information seems redundant. - Since this is Posix specific, callers require #ifndef _WIN32 in shared files. That's not nice, but the alternative would be an empty stub implementation for windows, which I find also unappealing. Example output, Ubuntu 20.04: Java started with LC_ALL=C: thomas at starfish $ jjjcmd Simple VM.info | ack LC_ LC_ALL=C LC_ALL=C LC_COLLATE=C LC_CTYPE=C LC_MESSAGES=C LC_MONETARY=C LC_NUMERIC=C LC_TIME=C Java started with my default system settings: thomas at starfish:/shared/projects/openjdk/jdk-jdk/source/src/hotspot$ jjjcmd Simple VM.info | ack LC_ LC_ALL=LC_CTYPE=C;LC_NUMERIC=en_DK.UTF-8;LC_TIME=en_DK.UTF-8;LC_COLLATE=C;LC_MONETARY=en_DK.UTF-8;LC_MESSAGES=C;LC_PAPER=en_DK.UTF-8;LC_NAME=en_DK.UTF-8;LC_ADDRESS=en_DK.UTF-8;LC_TELEPHONE=en_DK.UTF-8;LC_MEASUREMENT=en_DK.UTF-8;LC_IDENTIFICATION=en_DK.UTF-8 LC_COLLATE=C LC_CTYPE=C LC_MESSAGES=C LC_MONETARY=en_DK.UTF-8 LC_NUMERIC=en_DK.UTF-8 LC_TIME=en_DK.UTF-8 ------------- Commit messages: - print posix locale categories Changes: https://git.openjdk.java.net/jdk/pull/8194/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8194&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8284726 Stats: 44 lines in 3 files changed: 44 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8194.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8194/head:pull/8194 PR: https://git.openjdk.java.net/jdk/pull/8194 From stuefe at openjdk.java.net Tue Apr 12 13:24:09 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 12 Apr 2022 13:24:09 GMT Subject: RFR: JDK-8283326: Implement SafeFetch statically [v3] In-Reply-To: References: Message-ID: > Hi, > > This is a reimplementation of SafeFetch to get rid of dynamic code generation. This is done, depending on platform, via static assembly, Posix setjmp/longjmp or SEH. > > This is based on a proposal by @theRealAph [1] when discussing [JDK-8282475](https://bugs.openjdk.java.net/browse/JDK-8282475). I extended the proposal to do this for all platforms, not just MacOS, see discussion below. > > --- > > Why we do this: > > SafeFetch is special: it is a basic utility function that may be called before the VM is properly initialized, from a "foreign" thread not attached to the VM, in a broken environment... mainly this is due to its use during stack walking, error reporting, hex dumping, etc. SafeFetch has to be safe to call under any circumstances - or as safe as we can make it. > > Today, SafeFetch is implemented via stub routines. That causes problems: > > - MacOs aarch64 has mechanisms to prevent execution of arbitrary non-text memory. On that platform, invoking generated code requires some awkward gymnastics [2]. These workarounds require access to Thread::current, which renders SafeFetch non-functional if Thread::current is NULL (e.g. crash reporting in "foreign" native threads or in a corrupted VM). They also cost a bit of performance on every SafeFetch invocation. Note that more OSes may implement similar execution prevention mechanics in the future. > > - There is a time window during VM initialization where the stubs are not generated yet and thus SafeFetch is not available. > > Both points cause hs-err files to be compromised (e.g. missing call stacks) for crashes in native threads, when the VM is corrupted, or early during VM initialization. Since SafeFetch is such a basic tool, it causes more issues than that (e.g., on AIX it is used for verifying mprotect() itself). But hs-err files being compromised by secondary errors is the most annoying effect. > > A minor point is that generating stubs takes a tiny bit of startup time. Not a big issue, but anything we can generate at build time instead of at runtime is good. > > --- > > The patch: > > - Removes the SafeFetch stub routine generation for all platforms > - For Linux and MacOS, it implements SafeFetch as cpu-specific static assembler routines. These routines live in `os_cpu/_/safefetch__.S`. > - On Windows, SafeFetch is implemented via SEH. This is beautifully simple and does not need handwritten assembly at all. See `os/windows/safefetch_windows.hpp`. > - On Zero, SafeFetch uses a Posix compatible solution using `sigsetjmp(2)`. This is portable and robust, but a bit slow compared to the other methods. Note that this solution existed before, and is well tested. I just moved the code around and massaged it a bit. > - AIX uses now the same method as Zero. AIX "downgraded" in that sense from the stub routine solution, but since SAP gave up maintenance of AIX, I don't have easy access to AIX hardware. If SafeFetch speed becomes an issue, I am sure a solution based on static assembly can be implemented on AIX too. > - The SafeFetch gtests were greatly expanded. > > Tests: > > - The patch was tested manually by building and running gtests on: > - MacOS (x64, aarch64) > - Linux (aarch64, arm, ppcle, s390, x64, x86, riscv) > - Windows (x64 and x86, but not arm, see below) > - AIX > - Zero (on Linux x64). > - GHAs > - The patch ran through SAP nightlies for several nights in a row > > Note: > - I have no access to Windows arm, so I could not test it. I contacted @mo-beck to verify that the patch works there. > - I have no access to BSD. I am not sure who maintains BSD, so I have no idea who to contact. However, I believe the MacOS solution should work for BSD too. If not, BSD can simply fall back to the Posix sigjmp solution like AIX and Zero. > > It would be nice to have @RealLucy, @TheRealMDoerr and @theRealAph to okay s390, ppcle and aarch64 (and possibly arm32). Each assembly file is tiny, so it should not take long. @RealFYang and @backwaterred already tested the patch on RiscV and AIX (thanks). > > Thanks, Thomas > > [1] https://github.com/openjdk/jdk/pull/7727#issuecomment-1064980598 > [2] https://github.com/openjdk/jdk/blob/4df67426ed02f18af0757897acb28b636a317a91/src/hotspot/share/runtime/safefetch.inline.hpp#L37-L41 Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: remove SAFEFETCH_DEFAULT ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7865/files - new: https://git.openjdk.java.net/jdk/pull/7865/files/8d1cc4ed..27b50935 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7865&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7865&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7865.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7865/head:pull/7865 PR: https://git.openjdk.java.net/jdk/pull/7865 From stuefe at openjdk.java.net Tue Apr 12 13:24:10 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 12 Apr 2022 13:24:10 GMT Subject: RFR: JDK-8283326: Implement SafeFetch statically [v2] In-Reply-To: References: <5JIL3N8hmdEx4fTdcfPsV30Opa3MOgdgsI8E3A8gofo=.c58b72b9-438f-490d-ad68-0c8dbd06146b@github.com> Message-ID: <6wq3B5i7ZNPOpbaYEJyh1hqvvS9-Vs_AC2DhxIcbxdY=.69593749-fdcb-4dc8-9708-80be67f2b3ef@github.com> On Tue, 12 Apr 2022 13:03:52 GMT, David Holmes wrote: > Updates look good - thanks. > Thanks a lot, David! > I think perhaps we could simplify the ifdefs even further but I'm okay with them as they are. Yes, we may reduce this coding even further. Let's see how this works out. Cheers, Thomas > > Thanks, David ------------- PR: https://git.openjdk.java.net/jdk/pull/7865 From dholmes at openjdk.java.net Tue Apr 12 13:30:43 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 12 Apr 2022 13:30:43 GMT Subject: RFR: 8284274: Error reporting crashes because missing ResourceMarks In-Reply-To: References: Message-ID: On Tue, 12 Apr 2022 12:01:15 GMT, Coleen Phillimore wrote: > Taking the suggestion from @stefank in the bug report, disable the ResourceMark missing assert during error reporting. There's a ResourceArea in the thread that can be used. Added a test. > Tested with tier1-4 on x86 and aarch64 platforms. Hi Coleen, Looks good! One query below. Thanks, David src/hotspot/share/utilities/vmError.cpp line 550: > 548: // error handler after a secondary crash works. > 549: STEP("test secondary crash 1") > 550: if (_verbose && TestCrashInErrorHandler == 14) { Where does the 14 come from ?? ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8201 From hseigel at openjdk.java.net Tue Apr 12 13:39:56 2022 From: hseigel at openjdk.java.net (Harold Seigel) Date: Tue, 12 Apr 2022 13:39:56 GMT Subject: RFR: 8284274: Error reporting crashes because missing ResourceMarks In-Reply-To: References: Message-ID: On Tue, 12 Apr 2022 13:26:46 GMT, David Holmes wrote: >> Taking the suggestion from @stefank in the bug report, disable the ResourceMark missing assert during error reporting. There's a ResourceArea in the thread that can be used. Added a test. >> Tested with tier1-4 on x86 and aarch64 platforms. > > src/hotspot/share/utilities/vmError.cpp line 550: > >> 548: // error handler after a secondary crash works. >> 549: STEP("test secondary crash 1") >> 550: if (_verbose && TestCrashInErrorHandler == 14) { > > Where does the 14 come from ?? Maybe "// 14 - SIGSEGV" in vmError.cpp? ------------- PR: https://git.openjdk.java.net/jdk/pull/8201 From stuefe at openjdk.java.net Tue Apr 12 13:39:57 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 12 Apr 2022 13:39:57 GMT Subject: RFR: 8284274: Error reporting crashes because missing ResourceMarks In-Reply-To: References: Message-ID: On Tue, 12 Apr 2022 13:33:57 GMT, Harold Seigel wrote: >> src/hotspot/share/utilities/vmError.cpp line 550: >> >>> 548: // error handler after a secondary crash works. >>> 549: STEP("test secondary crash 1") >>> 550: if (_verbose && TestCrashInErrorHandler == 14) { >> >> Where does the 14 come from ?? > > Maybe "// 14 - SIGSEGV" in vmError.cpp? See runtime/ErrorHandling/SecondaryErrorTest.java, it is fed into VMError::controlled_crash(). That test crashes the VM first with one signal, then inside the error handler with a second, different, signal, to test that the second error signal was correctly unblocked or left unblocked. Otherwise, the VM would just disappear. ------------- PR: https://git.openjdk.java.net/jdk/pull/8201 From mdoerr at openjdk.java.net Tue Apr 12 14:19:37 2022 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Tue, 12 Apr 2022 14:19:37 GMT Subject: RFR: JDK-8283326: Implement SafeFetch statically [v3] In-Reply-To: References: Message-ID: On Tue, 12 Apr 2022 13:24:09 GMT, Thomas Stuefe wrote: >> Hi, >> >> This is a reimplementation of SafeFetch to get rid of dynamic code generation. This is done, depending on platform, via static assembly, Posix setjmp/longjmp or SEH. >> >> This is based on a proposal by @theRealAph [1] when discussing [JDK-8282475](https://bugs.openjdk.java.net/browse/JDK-8282475). I extended the proposal to do this for all platforms, not just MacOS, see discussion below. >> >> --- >> >> Why we do this: >> >> SafeFetch is special: it is a basic utility function that may be called before the VM is properly initialized, from a "foreign" thread not attached to the VM, in a broken environment... mainly this is due to its use during stack walking, error reporting, hex dumping, etc. SafeFetch has to be safe to call under any circumstances - or as safe as we can make it. >> >> Today, SafeFetch is implemented via stub routines. That causes problems: >> >> - MacOs aarch64 has mechanisms to prevent execution of arbitrary non-text memory. On that platform, invoking generated code requires some awkward gymnastics [2]. These workarounds require access to Thread::current, which renders SafeFetch non-functional if Thread::current is NULL (e.g. crash reporting in "foreign" native threads or in a corrupted VM). They also cost a bit of performance on every SafeFetch invocation. Note that more OSes may implement similar execution prevention mechanics in the future. >> >> - There is a time window during VM initialization where the stubs are not generated yet and thus SafeFetch is not available. >> >> Both points cause hs-err files to be compromised (e.g. missing call stacks) for crashes in native threads, when the VM is corrupted, or early during VM initialization. Since SafeFetch is such a basic tool, it causes more issues than that (e.g., on AIX it is used for verifying mprotect() itself). But hs-err files being compromised by secondary errors is the most annoying effect. >> >> A minor point is that generating stubs takes a tiny bit of startup time. Not a big issue, but anything we can generate at build time instead of at runtime is good. >> >> --- >> >> The patch: >> >> - Removes the SafeFetch stub routine generation for all platforms >> - For Linux and MacOS, it implements SafeFetch as cpu-specific static assembler routines. These routines live in `os_cpu/_/safefetch__.S`. >> - On Windows, SafeFetch is implemented via SEH. This is beautifully simple and does not need handwritten assembly at all. See `os/windows/safefetch_windows.hpp`. >> - On Zero, SafeFetch uses a Posix compatible solution using `sigsetjmp(2)`. This is portable and robust, but a bit slow compared to the other methods. Note that this solution existed before, and is well tested. I just moved the code around and massaged it a bit. >> - AIX uses now the same method as Zero. AIX "downgraded" in that sense from the stub routine solution, but since SAP gave up maintenance of AIX, I don't have easy access to AIX hardware. If SafeFetch speed becomes an issue, I am sure a solution based on static assembly can be implemented on AIX too. >> - The SafeFetch gtests were greatly expanded. >> >> Tests: >> >> - The patch was tested manually by building and running gtests on: >> - MacOS (x64, aarch64) >> - Linux (aarch64, arm, ppcle, s390, x64, x86, riscv) >> - Windows (x64 and x86, but not arm, see below) >> - AIX >> - Zero (on Linux x64). >> - GHAs >> - The patch ran through SAP nightlies for several nights in a row >> >> Note: >> - I have no access to Windows arm, so I could not test it. I contacted @mo-beck to verify that the patch works there. >> - I have no access to BSD. I am not sure who maintains BSD, so I have no idea who to contact. However, I believe the MacOS solution should work for BSD too. If not, BSD can simply fall back to the Posix sigjmp solution like AIX and Zero. >> >> It would be nice to have @RealLucy, @TheRealMDoerr and @theRealAph to okay s390, ppcle and aarch64 (and possibly arm32). Each assembly file is tiny, so it should not take long. @RealFYang and @backwaterred already tested the patch on RiscV and AIX (thanks). >> >> Thanks, Thomas >> >> [1] https://github.com/openjdk/jdk/pull/7727#issuecomment-1064980598 >> [2] https://github.com/openjdk/jdk/blob/4df67426ed02f18af0757897acb28b636a317a91/src/hotspot/share/runtime/safefetch.inline.hpp#L37-L41 > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > remove SAFEFETCH_DEFAULT It's very unfortunate that such a simple task requires so much platform code. Would be nice if the Windows implementation would work everywhere :-) I'm not aware of a simple implementation which works reliably on all platforms, so LGTM. Feel free to fix indentation. Would it make sense to add a test case which uses a negative int as default value for SafeFetch32? Just to make sure the signed int gets passed correctly through the assembler stubs and reaches C++ code without loss of sign extension. src/hotspot/os_cpu/bsd_aarch64/safefetch_bsd_aarch64.S line 47: > 45: # w1 : defaultval > 46: > 47: # needed to align function start to 4 byte indentation src/hotspot/os_cpu/bsd_x86/safefetch_bsd_x86_64.S line 47: > 45: # %rdi : address > 46: # %esi : defaultval > 47: ELF_TYPE(SafeFetch32, at function) indentation src/hotspot/os_cpu/linux_x86/safefetch_linux_x86_32.S line 34: > 32: # 8(%esp) : default value > 33: # 4(%esp) : crash address > 34: # 0(%esp) : return pc indentation ------------- Marked as reviewed by mdoerr (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7865 From coleenp at openjdk.java.net Tue Apr 12 14:22:49 2022 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 12 Apr 2022 14:22:49 GMT Subject: RFR: 8284274: Error reporting crashes because missing ResourceMarks In-Reply-To: References: Message-ID: On Tue, 12 Apr 2022 13:36:55 GMT, Thomas Stuefe wrote: >> Maybe "// 14 - SIGSEGV" in vmError.cpp? > > See runtime/ErrorHandling/SecondaryErrorTest.java, it is fed into VMError::controlled_crash(). > > That test crashes the VM first with one signal, then inside the error handler with a second, different, signal, to test that the second error signal was correctly unblocked or left unblocked. Otherwise, the VM would just disappear. Yes, the 14 comes with the test. Nothing else queries the value of TestCrashInErrorHandler or passes anything but 14 or now in my test, 2. ------------- PR: https://git.openjdk.java.net/jdk/pull/8201 From coleenp at openjdk.java.net Tue Apr 12 14:22:50 2022 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 12 Apr 2022 14:22:50 GMT Subject: RFR: 8284274: Error reporting crashes because missing ResourceMarks In-Reply-To: References: Message-ID: On Tue, 12 Apr 2022 14:19:02 GMT, Coleen Phillimore wrote: >> See runtime/ErrorHandling/SecondaryErrorTest.java, it is fed into VMError::controlled_crash(). >> >> That test crashes the VM first with one signal, then inside the error handler with a second, different, signal, to test that the second error signal was correctly unblocked or left unblocked. Otherwise, the VM would just disappear. > > Yes, the 14 comes with the test. Nothing else queries the value of TestCrashInErrorHandler or passes anything but 14 or now in my test, 2. We could change the 14 to the first test to some enum test_error_handler { secondary_crash = 1, resource_mark_crash = 2 }; and change the test. I just left the 14 since the test can't see the enum values. ------------- PR: https://git.openjdk.java.net/jdk/pull/8201 From aph at openjdk.java.net Tue Apr 12 14:23:23 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Tue, 12 Apr 2022 14:23:23 GMT Subject: RFR: 8282541: AArch64: Auto-vectorize Math.round API Message-ID: Before, Apple M1: +-----------------------------------------+---------------------------------+ |Benchmark | (TESTSIZE) Mode Score Units| +-----------------------------------------+---------------------------------+ |FpRoundingBenchmark.test_round_double | 1024 thrpt 1612.391 ops/ms| |FpRoundingBenchmark.test_round_double | 2048 thrpt 804.291 ops/ms| |FpRoundingBenchmark.test_round_float | 1024 thrpt 1558.202 ops/ms| |FpRoundingBenchmark.test_round_float | 2048 thrpt 775.730 ops/ms| +------------------------------------------+--------------------------------+ After: +-----------------------------------------+----------------------------------+ |Benchmark | (TESTSIZE) Mode Score Units| +-----------------------------------------+----------------------------------+ |FpRoundingBenchmark.test_round_double | 1024 thrpt 2720.153 ops/ms| |FpRoundingBenchmark.test_round_double | 2048 thrpt 1371.750 ops/ms| |FpRoundingBenchmark.test_round_float | 1024 thrpt 5940.263 ops/ms| |FpRoundingBenchmark.test_round_float | 2048 thrpt 3036.201 ops/ms| +-----------------------------------------+----------------------------------+ About the algorithm: `Math.round()` is tricky. Its specification corresponds to no standard rounding mode: it "returns the closest long to the argument, with ties rounding to positive infinity." For positive inputs this is the same as IEEE-754's `convertToIntegerTiesToAway` operation, which rounds away from zero, but there's no equivalent for negative inputs. `Math.round()` used simply to add 0.5 and convert to integer by taking the floor of the result, but that wasn't right because it suffers from double rounding. This breaks several cases, in particular because `0.4999999... (+) 0.5 == 1.0` (Here, `(+)` indicates an addition followed by roundTiesToEven.) There is no corresponding problem with `-0.4999999...` or `-0.9999999...` Also, in the 32-bit `float` case, `8388609 (+) 0.5 == 8388610` because 8388609 (0x1.000002p+23) as a 32-bit integer has no fraction bits, so adding 0.5, followed by roundTiesToEven, rounds upwards. This problem manifests for every odd integer within the binade from 0x1.000002p+23 to 0x1.fffffep+23, whether positive or negative. There is a corresponding problem for the `double` range. The patch for JDK-8279508 handles this by flipping the floating-point rounding mode to roundTowardNegative, adding 0.5, and taking the floor. While this does work on AArch64, the performance is tragic. AArch64 implementations seem to wait for all instructions in flight to retire, change the rounding mode, and do the operation. This effectively serializes the entire thread. This patch takes a different approach. Firstly, we can observe that we can use the `frinta` instruction for the entire positive range. The negative range is a bit trickier, but we can observe that any x, abs{x) >= -0x1.000000p+23, has no fractional bits so it must be an integer. For convenence, we can convert that range with the `frinta` instruction as well. All that remains are x < 0, abs{x) < -0x1.000000p+23. Adding 0.5 followed by roundTiesToEven doesn't lead to a problem because for x < 0 && abs{x) >= 0.5, adding 0.5 only reduces the magnitude of x; for all x < 0 && abs{x) < 0.5, adding 0.5 followed by roundTiesToEven return 0. ------------- Commit messages: - Delete dead code - Untabify - Fix assertion - 8282541: AArch64: Auto-vectorize Math.round API - Cleanup - Cleanup - Rebase - Rebase Changes: https://git.openjdk.java.net/jdk/pull/8204/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8204&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282541 Stats: 1054 lines in 13 files changed: 489 ins; 9 del; 556 mod Patch: https://git.openjdk.java.net/jdk/pull/8204.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8204/head:pull/8204 PR: https://git.openjdk.java.net/jdk/pull/8204 From mbaesken at openjdk.java.net Tue Apr 12 14:26:02 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Tue, 12 Apr 2022 14:26:02 GMT Subject: RFR: JDK-8284754: print more interesting env variables in hs_err and VM.info Message-ID: There are a few more interesting env variables, e.g. documented here https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html that should be printed in hs_err for better supportability. For example, TMPDIR is a cross platform addition to what was done for Windows with : 8283497: [windows] print TMP and TEMP in hs_err and VM.info . ------------- Commit messages: - JDK-8284754 Changes: https://git.openjdk.java.net/jdk/pull/8205/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8205&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8284754 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8205.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8205/head:pull/8205 PR: https://git.openjdk.java.net/jdk/pull/8205 From hseigel at openjdk.java.net Tue Apr 12 14:27:38 2022 From: hseigel at openjdk.java.net (Harold Seigel) Date: Tue, 12 Apr 2022 14:27:38 GMT Subject: RFR: 8284274: Error reporting crashes because missing ResourceMarks In-Reply-To: References: Message-ID: On Tue, 12 Apr 2022 14:20:48 GMT, Coleen Phillimore wrote: >> Yes, the 14 comes with the test. Nothing else queries the value of TestCrashInErrorHandler or passes anything but 14 or now in my test, 2. > > We could change the 14 to the first test to some enum test_error_handler { secondary_crash = 1, resource_mark_crash = 2 }; and change the test. I just left the 14 since the test can't see the enum values. Can you add a comment explaining the 14 and 2? ------------- PR: https://git.openjdk.java.net/jdk/pull/8201 From aph at openjdk.java.net Tue Apr 12 14:38:32 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Tue, 12 Apr 2022 14:38:32 GMT Subject: RFR: 8282528: AArch64: Incorrect replicate2L_zero rule [v4] In-Reply-To: References: Message-ID: On Tue, 12 Apr 2022 10:48:27 GMT, Eric Liu wrote: >> This patch fixes the wrong matching rule of replicate2L_zero. It was >> matched "ReplicateI" by mistake so that long immediates(not only zero) >> had to be moved to register first and matched to replicate2L finally. To >> fix this trivial bug, this patch fixes the typo and extends the rule of >> replicate2L_zero to replicate2L_imm, which now supports all possible >> long immediate values. >> >> The final code changes are shown as below: >> >> replicate2L_imm: >> >> mov x13, #0xff >> movk x13, #0xff, lsl #16 >> movk x13, #0xff, lsl #32 >> dup v16.2d, x13 >> >> => >> >> movi v16.2d, #0xff00ff00ff >> >> [Test] >> test/jdk/jdk/incubator/vector, test/hotspot/jtreg/compiler/vectorapi >> passed without failure. > > Eric Liu has updated the pull request incrementally with one additional commit since the last revision: > > remove ifelse which is triggered by empty args > > Change-Id: I461e62495c7abc0f84ef1f66443f6bcf7adbeff0 Looks good to me. ------------- Marked as reviewed by aph (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7939 From stuefe at openjdk.java.net Tue Apr 12 15:50:13 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 12 Apr 2022 15:50:13 GMT Subject: RFR: JDK-8283326: Implement SafeFetch statically [v4] In-Reply-To: References: Message-ID: > Hi, > > This is a reimplementation of SafeFetch to get rid of dynamic code generation. This is done, depending on platform, via static assembly, Posix setjmp/longjmp or SEH. > > This is based on a proposal by @theRealAph [1] when discussing [JDK-8282475](https://bugs.openjdk.java.net/browse/JDK-8282475). I extended the proposal to do this for all platforms, not just MacOS, see discussion below. > > --- > > Why we do this: > > SafeFetch is special: it is a basic utility function that may be called before the VM is properly initialized, from a "foreign" thread not attached to the VM, in a broken environment... mainly this is due to its use during stack walking, error reporting, hex dumping, etc. SafeFetch has to be safe to call under any circumstances - or as safe as we can make it. > > Today, SafeFetch is implemented via stub routines. That causes problems: > > - MacOs aarch64 has mechanisms to prevent execution of arbitrary non-text memory. On that platform, invoking generated code requires some awkward gymnastics [2]. These workarounds require access to Thread::current, which renders SafeFetch non-functional if Thread::current is NULL (e.g. crash reporting in "foreign" native threads or in a corrupted VM). They also cost a bit of performance on every SafeFetch invocation. Note that more OSes may implement similar execution prevention mechanics in the future. > > - There is a time window during VM initialization where the stubs are not generated yet and thus SafeFetch is not available. > > Both points cause hs-err files to be compromised (e.g. missing call stacks) for crashes in native threads, when the VM is corrupted, or early during VM initialization. Since SafeFetch is such a basic tool, it causes more issues than that (e.g., on AIX it is used for verifying mprotect() itself). But hs-err files being compromised by secondary errors is the most annoying effect. > > A minor point is that generating stubs takes a tiny bit of startup time. Not a big issue, but anything we can generate at build time instead of at runtime is good. > > --- > > The patch: > > - Removes the SafeFetch stub routine generation for all platforms > - For Linux and MacOS, it implements SafeFetch as cpu-specific static assembler routines. These routines live in `os_cpu/_/safefetch__.S`. > - On Windows, SafeFetch is implemented via SEH. This is beautifully simple and does not need handwritten assembly at all. See `os/windows/safefetch_windows.hpp`. > - On Zero, SafeFetch uses a Posix compatible solution using `sigsetjmp(2)`. This is portable and robust, but a bit slow compared to the other methods. Note that this solution existed before, and is well tested. I just moved the code around and massaged it a bit. > - AIX uses now the same method as Zero. AIX "downgraded" in that sense from the stub routine solution, but since SAP gave up maintenance of AIX, I don't have easy access to AIX hardware. If SafeFetch speed becomes an issue, I am sure a solution based on static assembly can be implemented on AIX too. > - The SafeFetch gtests were greatly expanded. > > Tests: > > - The patch was tested manually by building and running gtests on: > - MacOS (x64, aarch64) > - Linux (aarch64, arm, ppcle, s390, x64, x86, riscv) > - Windows (x64 and x86, but not arm, see below) > - AIX > - Zero (on Linux x64). > - GHAs > - The patch ran through SAP nightlies for several nights in a row > > Note: > - I have no access to Windows arm, so I could not test it. I contacted @mo-beck to verify that the patch works there. > - I have no access to BSD. I am not sure who maintains BSD, so I have no idea who to contact. However, I believe the MacOS solution should work for BSD too. If not, BSD can simply fall back to the Posix sigjmp solution like AIX and Zero. > > It would be nice to have @RealLucy, @TheRealMDoerr and @theRealAph to okay s390, ppcle and aarch64 (and possibly arm32). Each assembly file is tiny, so it should not take long. @RealFYang and @backwaterred already tested the patch on RiscV and AIX (thanks). > > Thanks, Thomas > > [1] https://github.com/openjdk/jdk/pull/7727#issuecomment-1064980598 > [2] https://github.com/openjdk/jdk/blob/4df67426ed02f18af0757897acb28b636a317a91/src/hotspot/share/runtime/safefetch.inline.hpp#L37-L41 Thomas Stuefe has updated the pull request incrementally with two additional commits since the last revision: - fix indentations - extend gtests to test with -1 as default value ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7865/files - new: https://git.openjdk.java.net/jdk/pull/7865/files/27b50935..f9c2d9d0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7865&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7865&range=02-03 Stats: 8 lines in 4 files changed: 4 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/7865.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7865/head:pull/7865 PR: https://git.openjdk.java.net/jdk/pull/7865 From stuefe at openjdk.java.net Tue Apr 12 15:52:00 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 12 Apr 2022 15:52:00 GMT Subject: RFR: JDK-8283326: Implement SafeFetch statically [v3] In-Reply-To: References: Message-ID: On Tue, 12 Apr 2022 14:16:22 GMT, Martin Doerr wrote: > It's very unfortunate that such a simple task requires so much platform code. Would be nice if the Windows implementation would work everywhere :-) I'm not aware of a simple implementation which works reliably on all platforms, so LGTM. Thanks Martin! Honestly, the new implementation does not add much complexity which has not been there before. Discounting test addition, we have about 150 locs more, most caused by the unfortunate code duplication between bsd and Linux. But as you said, there is no easy separation here. I have fought with this aspect of the patch for too long now, and I think this is the cleanest and least surprising solution. It also follows what the copy_bytes_ assembly routines did before. > Would it make sense to add a test case which uses a negative int as default value for SafeFetch32? Just to make sure the signed int gets passed correctly through the assembler stubs and reaches C++ code without loss of sign extension. I fixed the indentations and extended the gtest as you proposed. I re-ran tests on x64, x86, arm-32 and aarch64, looks good. Thanks! Cheers Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/7865 From coleenp at openjdk.java.net Tue Apr 12 16:17:13 2022 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 12 Apr 2022 16:17:13 GMT Subject: RFR: 8284274: Error reporting crashes because missing ResourceMarks [v2] In-Reply-To: References: Message-ID: <-Dc0lrCQpTBjof6ucB5sAuCbMZuZhXAeMqFN8poIUeo=.065fb375-c8c3-4c9b-bed9-7f3fb23bd514@github.com> > Taking the suggestion from @stefank in the bug report, disable the ResourceMark missing assert during error reporting. There's a ResourceArea in the thread that can be used. Added a test. > Tested with tier1-4 on x86 and aarch64 platforms. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Add some variable names for test values. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8201/files - new: https://git.openjdk.java.net/jdk/pull/8201/files/0bbe3b9f..bfb7621c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8201&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8201&range=00-01 Stats: 6 lines in 1 file changed: 3 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/8201.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8201/head:pull/8201 PR: https://git.openjdk.java.net/jdk/pull/8201 From coleenp at openjdk.java.net Tue Apr 12 16:17:15 2022 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 12 Apr 2022 16:17:15 GMT Subject: RFR: 8284274: Error reporting crashes because missing ResourceMarks [v2] In-Reply-To: References: Message-ID: On Tue, 12 Apr 2022 14:24:30 GMT, Harold Seigel wrote: >> We could change the 14 to the first test to some enum test_error_handler { secondary_crash = 1, resource_mark_crash = 2 }; and change the test. I just left the 14 since the test can't see the enum values. > > Can you add a comment explaining the 14 and 2? I gave them local #defines so they'd have good names. ------------- PR: https://git.openjdk.java.net/jdk/pull/8201 From stuefe at openjdk.java.net Tue Apr 12 16:24:36 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 12 Apr 2022 16:24:36 GMT Subject: RFR: 8284274: Error reporting crashes because missing ResourceMarks [v2] In-Reply-To: <-Dc0lrCQpTBjof6ucB5sAuCbMZuZhXAeMqFN8poIUeo=.065fb375-c8c3-4c9b-bed9-7f3fb23bd514@github.com> References: <-Dc0lrCQpTBjof6ucB5sAuCbMZuZhXAeMqFN8poIUeo=.065fb375-c8c3-4c9b-bed9-7f3fb23bd514@github.com> Message-ID: On Tue, 12 Apr 2022 16:17:13 GMT, Coleen Phillimore wrote: >> Taking the suggestion from @stefank in the bug report, disable the ResourceMark missing assert during error reporting. There's a ResourceArea in the thread that can be used. Added a test. >> Tested with tier1-4 on x86 and aarch64 platforms. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Add some variable names for test values. Trying to understand this... We cannot just wrap VMError::report() in a ResourceMark since that requires Thread::current() to be != NULL and would crash immediately when called in a non-VM-attached thread. But there are instances where RA allocation happens in error reporting. We don't really like that, but don't have the time to fix that, so we tolerate them. But we don't especially care for cleanup, since we will die anyway. Also the less we do with C-heap the better, and better avoid those unnecessary free() calls. So we tolerate missing ResourceMarks during error handling. The only thing to remark is that the crashing step should really not use RA. "printing registers" is a very basic thing, should only require a valid ucontext_t and nothing else. Maybe that would be worth hunting down. I always thought a NoResourceAreaMark, similar to a NoHandleMark, would be nice to have. But I always shied away from the cleanup that would follow :) test/hotspot/jtreg/runtime/ErrorHandling/ResourceMarkTest.java line 64: > 62: output_detail.shouldMatch("#.+SIGFPE.*"); > 63: output_detail.shouldMatch("This is a message with no ResourceMark"); > 64: Note that we introduced -XX:+ErrorFileToStdout and -XX:+ErrorFileToStderr, you could use that instead of looking for the hs-err file, and parse output_detail directly for the strings in question. The ErrorHandler tests are older than those switches and could be rewritten too. ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8201 From kvn at openjdk.java.net Tue Apr 12 16:32:43 2022 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Tue, 12 Apr 2022 16:32:43 GMT Subject: RFR: JDK-8075816: AliasLevel is broken and should be deprecated [v2] In-Reply-To: References: Message-ID: On Tue, 12 Apr 2022 10:42:32 GMT, Tobias Hartmann wrote: >> You are right: the statement in the bug report that `AliasLevel<3` is broken is wrong. The VM crashes for `AliasLevel=0` and `AliasLevel=1` but not for `AliasLevel=2`. So with `-XX:-DoEscapeAnalysis` it is always automatically set to`AliasLevel=2`. >> But when `-XX:+DoEscapeAnalysis -XX:+EliminateAllocations` there is ONE use-case for `AliasLevel` : >> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/escape.cpp#L336-L341 >> - for `-XX:AliasLevel=3` `split_unique_types(alloc_worklist, arraycopy_worklist, mergemem_worklist);` is called >> - for `-XX:AliasLevel=2` `split_unique_types(alloc_worklist, arraycopy_worklist, mergemem_worklist);` is NOT called >> >> So does the use case `-XX:+DoEscapeAnalysis -XX:+EliminateAllocations -XX:AliasLevel=2` make sense and is it something that is used? >> >> Since `AliasLevel` is not completely broken the question is if we should deprecated instead of making it obsolete? > > I don't think there is a real use case for `-XX:AliasLevel=2` given that one can get similar behavior with `-XX:-EliminateAllocations` (or `-XX:-DoEscapeAnalysis`). I would therefore vote for **deprecating** `AliasLevel`. Yes, I agree with Tobias. Lets treat `-XX:AliasLevel=2` as `-XX:-EliminateAllocations`. There are tests which use this flags. And yes, we should deprecate `AliasLevel` but correcting bug's and CSR's text with this new information about `-XX:AliasLevel=2`. ------------- PR: https://git.openjdk.java.net/jdk/pull/8140 From duke at openjdk.java.net Tue Apr 12 16:46:16 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Tue, 12 Apr 2022 16:46:16 GMT Subject: RFR: 8282477: [x86, aarch64] vmassert(_last_Java_pc == NULL, "already walkable"); fails with async profiler Message-ID: Fix the assertion by replacing it by assertion that does not fail. ------------- Commit messages: - Fix assertion in aarch64, x86 and riscv Changes: https://git.openjdk.java.net/jdk/pull/8209/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8209&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282477 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/8209.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8209/head:pull/8209 PR: https://git.openjdk.java.net/jdk/pull/8209 From djelinski at openjdk.java.net Tue Apr 12 16:52:54 2022 From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 12 Apr 2022 16:52:54 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) In-Reply-To: References: Message-ID: <0jpZ1dprNSBX81zrd455SGK5Z_vvp5EtT5oS8b-XLxE=.adac88d9-cef5-479b-b94d-2de4cf381909@github.com> On Fri, 8 Apr 2022 13:43:39 GMT, Alan Bateman wrote: > This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. > > We will refresh this PR periodically to pick up changes and fixes from the loom repo. > > Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. > > The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. > > There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. > > The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. > > The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. src/java.base/share/classes/sun/nio/ch/SelChImpl.java line 89: > 87: } else { > 88: long millis; > 89: if (nanos == 0) { Was this change intentional? (`<=` replaced by `==`) If it was, please update the javadoc - `NANOSECONDS.toMillis(-1)` = 0 implies no waiting in Net.poll ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From mdoerr at openjdk.java.net Tue Apr 12 17:00:37 2022 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Tue, 12 Apr 2022 17:00:37 GMT Subject: RFR: JDK-8283326: Implement SafeFetch statically [v4] In-Reply-To: References: Message-ID: On Tue, 12 Apr 2022 15:50:13 GMT, Thomas Stuefe wrote: >> Hi, >> >> This is a reimplementation of SafeFetch to get rid of dynamic code generation. This is done, depending on platform, via static assembly, Posix setjmp/longjmp or SEH. >> >> This is based on a proposal by @theRealAph [1] when discussing [JDK-8282475](https://bugs.openjdk.java.net/browse/JDK-8282475). I extended the proposal to do this for all platforms, not just MacOS, see discussion below. >> >> --- >> >> Why we do this: >> >> SafeFetch is special: it is a basic utility function that may be called before the VM is properly initialized, from a "foreign" thread not attached to the VM, in a broken environment... mainly this is due to its use during stack walking, error reporting, hex dumping, etc. SafeFetch has to be safe to call under any circumstances - or as safe as we can make it. >> >> Today, SafeFetch is implemented via stub routines. That causes problems: >> >> - MacOs aarch64 has mechanisms to prevent execution of arbitrary non-text memory. On that platform, invoking generated code requires some awkward gymnastics [2]. These workarounds require access to Thread::current, which renders SafeFetch non-functional if Thread::current is NULL (e.g. crash reporting in "foreign" native threads or in a corrupted VM). They also cost a bit of performance on every SafeFetch invocation. Note that more OSes may implement similar execution prevention mechanics in the future. >> >> - There is a time window during VM initialization where the stubs are not generated yet and thus SafeFetch is not available. >> >> Both points cause hs-err files to be compromised (e.g. missing call stacks) for crashes in native threads, when the VM is corrupted, or early during VM initialization. Since SafeFetch is such a basic tool, it causes more issues than that (e.g., on AIX it is used for verifying mprotect() itself). But hs-err files being compromised by secondary errors is the most annoying effect. >> >> A minor point is that generating stubs takes a tiny bit of startup time. Not a big issue, but anything we can generate at build time instead of at runtime is good. >> >> --- >> >> The patch: >> >> - Removes the SafeFetch stub routine generation for all platforms >> - For Linux and MacOS, it implements SafeFetch as cpu-specific static assembler routines. These routines live in `os_cpu/_/safefetch__.S`. >> - On Windows, SafeFetch is implemented via SEH. This is beautifully simple and does not need handwritten assembly at all. See `os/windows/safefetch_windows.hpp`. >> - On Zero, SafeFetch uses a Posix compatible solution using `sigsetjmp(2)`. This is portable and robust, but a bit slow compared to the other methods. Note that this solution existed before, and is well tested. I just moved the code around and massaged it a bit. >> - AIX uses now the same method as Zero. AIX "downgraded" in that sense from the stub routine solution, but since SAP gave up maintenance of AIX, I don't have easy access to AIX hardware. If SafeFetch speed becomes an issue, I am sure a solution based on static assembly can be implemented on AIX too. >> - The SafeFetch gtests were greatly expanded. >> >> Tests: >> >> - The patch was tested manually by building and running gtests on: >> - MacOS (x64, aarch64) >> - Linux (aarch64, arm, ppcle, s390, x64, x86, riscv) >> - Windows (x64 and x86, but not arm, see below) >> - AIX >> - Zero (on Linux x64). >> - GHAs >> - The patch ran through SAP nightlies for several nights in a row >> >> Note: >> - I have no access to Windows arm, so I could not test it. I contacted @mo-beck to verify that the patch works there. >> - I have no access to BSD. I am not sure who maintains BSD, so I have no idea who to contact. However, I believe the MacOS solution should work for BSD too. If not, BSD can simply fall back to the Posix sigjmp solution like AIX and Zero. >> >> It would be nice to have @RealLucy, @TheRealMDoerr and @theRealAph to okay s390, ppcle and aarch64 (and possibly arm32). Each assembly file is tiny, so it should not take long. @RealFYang and @backwaterred already tested the patch on RiscV and AIX (thanks). >> >> Thanks, Thomas >> >> [1] https://github.com/openjdk/jdk/pull/7727#issuecomment-1064980598 >> [2] https://github.com/openjdk/jdk/blob/4df67426ed02f18af0757897acb28b636a317a91/src/hotspot/share/runtime/safefetch.inline.hpp#L37-L41 > > Thomas Stuefe has updated the pull request incrementally with two additional commits since the last revision: > > - fix indentations > - extend gtests to test with -1 as default value Thanks for the update! Thumbs up from my side! ------------- Marked as reviewed by mdoerr (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7865 From akozlov at openjdk.java.net Tue Apr 12 18:55:44 2022 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Tue, 12 Apr 2022 18:55:44 GMT Subject: RFR: JDK-8283326: Implement SafeFetch statically [v4] In-Reply-To: References: Message-ID: On Tue, 12 Apr 2022 15:50:13 GMT, Thomas Stuefe wrote: >> Hi, >> >> This is a reimplementation of SafeFetch to get rid of dynamic code generation. This is done, depending on platform, via static assembly, Posix setjmp/longjmp or SEH. >> >> This is based on a proposal by @theRealAph [1] when discussing [JDK-8282475](https://bugs.openjdk.java.net/browse/JDK-8282475). I extended the proposal to do this for all platforms, not just MacOS, see discussion below. >> >> --- >> >> Why we do this: >> >> SafeFetch is special: it is a basic utility function that may be called before the VM is properly initialized, from a "foreign" thread not attached to the VM, in a broken environment... mainly this is due to its use during stack walking, error reporting, hex dumping, etc. SafeFetch has to be safe to call under any circumstances - or as safe as we can make it. >> >> Today, SafeFetch is implemented via stub routines. That causes problems: >> >> - MacOs aarch64 has mechanisms to prevent execution of arbitrary non-text memory. On that platform, invoking generated code requires some awkward gymnastics [2]. These workarounds require access to Thread::current, which renders SafeFetch non-functional if Thread::current is NULL (e.g. crash reporting in "foreign" native threads or in a corrupted VM). They also cost a bit of performance on every SafeFetch invocation. Note that more OSes may implement similar execution prevention mechanics in the future. >> >> - There is a time window during VM initialization where the stubs are not generated yet and thus SafeFetch is not available. >> >> Both points cause hs-err files to be compromised (e.g. missing call stacks) for crashes in native threads, when the VM is corrupted, or early during VM initialization. Since SafeFetch is such a basic tool, it causes more issues than that (e.g., on AIX it is used for verifying mprotect() itself). But hs-err files being compromised by secondary errors is the most annoying effect. >> >> A minor point is that generating stubs takes a tiny bit of startup time. Not a big issue, but anything we can generate at build time instead of at runtime is good. >> >> --- >> >> The patch: >> >> - Removes the SafeFetch stub routine generation for all platforms >> - For Linux and MacOS, it implements SafeFetch as cpu-specific static assembler routines. These routines live in `os_cpu/_/safefetch__.S`. >> - On Windows, SafeFetch is implemented via SEH. This is beautifully simple and does not need handwritten assembly at all. See `os/windows/safefetch_windows.hpp`. >> - On Zero, SafeFetch uses a Posix compatible solution using `sigsetjmp(2)`. This is portable and robust, but a bit slow compared to the other methods. Note that this solution existed before, and is well tested. I just moved the code around and massaged it a bit. >> - AIX uses now the same method as Zero. AIX "downgraded" in that sense from the stub routine solution, but since SAP gave up maintenance of AIX, I don't have easy access to AIX hardware. If SafeFetch speed becomes an issue, I am sure a solution based on static assembly can be implemented on AIX too. >> - The SafeFetch gtests were greatly expanded. >> >> Tests: >> >> - The patch was tested manually by building and running gtests on: >> - MacOS (x64, aarch64) >> - Linux (aarch64, arm, ppcle, s390, x64, x86, riscv) >> - Windows (x64 and x86, but not arm, see below) >> - AIX >> - Zero (on Linux x64). >> - GHAs >> - The patch ran through SAP nightlies for several nights in a row >> >> Note: >> - I have no access to Windows arm, so I could not test it. I contacted @mo-beck to verify that the patch works there. >> - I have no access to BSD. I am not sure who maintains BSD, so I have no idea who to contact. However, I believe the MacOS solution should work for BSD too. If not, BSD can simply fall back to the Posix sigjmp solution like AIX and Zero. >> >> It would be nice to have @RealLucy, @TheRealMDoerr and @theRealAph to okay s390, ppcle and aarch64 (and possibly arm32). Each assembly file is tiny, so it should not take long. @RealFYang and @backwaterred already tested the patch on RiscV and AIX (thanks). >> >> Thanks, Thomas >> >> [1] https://github.com/openjdk/jdk/pull/7727#issuecomment-1064980598 >> [2] https://github.com/openjdk/jdk/blob/4df67426ed02f18af0757897acb28b636a317a91/src/hotspot/share/runtime/safefetch.inline.hpp#L37-L41 > > Thomas Stuefe has updated the pull request incrementally with two additional commits since the last revision: > > - fix indentations > - extend gtests to test with -1 as default value That's Indeed unfortunate, although reasonable, that asm files cannot be placed cpu-specific directory. A comment below. src/hotspot/share/runtime/safefetch.hpp line 30: > 28: > 29: #include "utilities/macros.hpp" > 30: Sorry, found late. This file now lacks the interface and description from the former safefetch.inline.hpp https://github.com/openjdk/jdk/blob/19b140a7f30ea600d66bcf8370d94f5d6bf6d0d1/src/hotspot/share/runtime/safefetch.inline.hpp#L35. A reader would need to look at the implementation files and assume they provide consistent interface. This seems not trivial just to provide declarations because in different implementation has C++ or C linkage. I can only imagine to make e.g. SafeFetch32 to call SafeFetch32_impl that may have any linkage, be inline or extern, etc. ------------- PR: https://git.openjdk.java.net/jdk/pull/7865 From mdoerr at openjdk.java.net Tue Apr 12 19:11:01 2022 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Tue, 12 Apr 2022 19:11:01 GMT Subject: RFR: 8282477: [x86, aarch64] vmassert(_last_Java_pc == NULL, "already walkable"); fails with async profiler In-Reply-To: References: Message-ID: On Tue, 12 Apr 2022 16:38:11 GMT, Johannes Bechberger wrote: > Fix the assertion by replacing it by assertion that does not fail. Fix looks good (but I'm biased). A short comment would be helpful explaining that the async profiler can intercept and make the stack walkable just before the assert. ------------- PR: https://git.openjdk.java.net/jdk/pull/8209 From djelinski at openjdk.java.net Tue Apr 12 19:12:48 2022 From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 12 Apr 2022 19:12:48 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) In-Reply-To: References: Message-ID: On Fri, 8 Apr 2022 13:43:39 GMT, Alan Bateman wrote: > This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. > > We will refresh this PR periodically to pick up changes and fixes from the loom repo. > > Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. > > The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. > > There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. > > The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. > > The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. src/java.base/share/classes/sun/nio/cs/StreamEncoder.java line 110: > 108: > 109: public void flushBuffer() throws IOException { > 110: if (lock instanceof InternalLock locker) { now that StreamEncoder is final, we can drop the `else` branch ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From coleenp at openjdk.java.net Tue Apr 12 19:38:51 2022 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 12 Apr 2022 19:38:51 GMT Subject: RFR: 8284274: Error reporting crashes because missing ResourceMarks [v2] In-Reply-To: References: <-Dc0lrCQpTBjof6ucB5sAuCbMZuZhXAeMqFN8poIUeo=.065fb375-c8c3-4c9b-bed9-7f3fb23bd514@github.com> Message-ID: On Tue, 12 Apr 2022 16:15:50 GMT, Thomas Stuefe wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Add some variable names for test values. > > test/hotspot/jtreg/runtime/ErrorHandling/ResourceMarkTest.java line 64: > >> 62: output_detail.shouldMatch("#.+SIGFPE.*"); >> 63: output_detail.shouldMatch("This is a message with no ResourceMark"); >> 64: > > Note that we introduced -XX:+ErrorFileToStdout and -XX:+ErrorFileToStderr, you could use that instead of looking for the hs-err file, and parse output_detail directly for the strings in question. The ErrorHandler tests are older than those switches and could be rewritten too. Ha Thomas, I copied your test almost verbatim. If I send all the hs_err file to stdout, jtreg might truncate it and that won't help, also if the test someday fails, the output will be lost in the jtreg truncation. Having two test do sort of the same thing seemed nice to me. ------------- PR: https://git.openjdk.java.net/jdk/pull/8201 From coleenp at openjdk.java.net Tue Apr 12 19:49:41 2022 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 12 Apr 2022 19:49:41 GMT Subject: RFR: 8284274: Error reporting crashes because missing ResourceMarks [v2] In-Reply-To: <-Dc0lrCQpTBjof6ucB5sAuCbMZuZhXAeMqFN8poIUeo=.065fb375-c8c3-4c9b-bed9-7f3fb23bd514@github.com> References: <-Dc0lrCQpTBjof6ucB5sAuCbMZuZhXAeMqFN8poIUeo=.065fb375-c8c3-4c9b-bed9-7f3fb23bd514@github.com> Message-ID: On Tue, 12 Apr 2022 16:17:13 GMT, Coleen Phillimore wrote: >> Taking the suggestion from @stefank in the bug report, disable the ResourceMark missing assert during error reporting. There's a ResourceArea in the thread that can be used. Added a test. >> Tested with tier1-4 on x86 and aarch64 platforms. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Add some variable names for test values. Thanks Thomas for reviewing this. I had a theory why we would see a missing ResourceMark in a loom stack trace (StackFrameStream?) but didn't have a reproducer for it. It seems better to suppress this assert completely during error reporting. If a resource allocation is used with no current thread, that would be a different crash. I agree, we should try to avoid any allocation during hs_err file production but sometimes these resource allocations sneak in a lower level, so better to let them go. I'm surprised we don't get more asserts from ResourceMark. ------------- PR: https://git.openjdk.java.net/jdk/pull/8201 From dholmes at openjdk.java.net Tue Apr 12 23:17:11 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 12 Apr 2022 23:17:11 GMT Subject: RFR: 8284274: Error reporting crashes because missing ResourceMarks [v2] In-Reply-To: <-Dc0lrCQpTBjof6ucB5sAuCbMZuZhXAeMqFN8poIUeo=.065fb375-c8c3-4c9b-bed9-7f3fb23bd514@github.com> References: <-Dc0lrCQpTBjof6ucB5sAuCbMZuZhXAeMqFN8poIUeo=.065fb375-c8c3-4c9b-bed9-7f3fb23bd514@github.com> Message-ID: On Tue, 12 Apr 2022 16:17:13 GMT, Coleen Phillimore wrote: >> Taking the suggestion from @stefank in the bug report, disable the ResourceMark missing assert during error reporting. There's a ResourceArea in the thread that can be used. Added a test. >> Tested with tier1-4 on x86 and aarch64 platforms. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Add some variable names for test values. Still fine for me. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8201 From dholmes at openjdk.java.net Wed Apr 13 01:27:23 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 13 Apr 2022 01:27:23 GMT Subject: RFR: 8282477: [x86, aarch64] vmassert(_last_Java_pc == NULL, "already walkable"); fails with async profiler In-Reply-To: References: Message-ID: <5Owd3BY_jU4dguy8K2J3BZArjvA6dgdnh3w6jOZPETQ=.293d07a1-e5ab-4054-9cca-d42dfa3e6623@github.com> On Tue, 12 Apr 2022 16:38:11 GMT, Johannes Bechberger wrote: > Fix the assertion by replacing it by assertion that does not fail. I remain concerned that AsyncGetCallTrace should not be mutating thread state in this way as it could break numerous things in numerous ways. Instead perhaps AGCT should be saving the current values of key thread state and then restoring them after? ------------- PR: https://git.openjdk.java.net/jdk/pull/8209 From stuefe at openjdk.java.net Wed Apr 13 03:33:16 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 13 Apr 2022 03:33:16 GMT Subject: RFR: 8284274: Error reporting crashes because missing ResourceMarks [v2] In-Reply-To: References: <-Dc0lrCQpTBjof6ucB5sAuCbMZuZhXAeMqFN8poIUeo=.065fb375-c8c3-4c9b-bed9-7f3fb23bd514@github.com> Message-ID: On Tue, 12 Apr 2022 19:34:53 GMT, Coleen Phillimore wrote: >> test/hotspot/jtreg/runtime/ErrorHandling/ResourceMarkTest.java line 64: >> >>> 62: output_detail.shouldMatch("#.+SIGFPE.*"); >>> 63: output_detail.shouldMatch("This is a message with no ResourceMark"); >>> 64: >> >> Note that we introduced -XX:+ErrorFileToStdout and -XX:+ErrorFileToStderr, you could use that instead of looking for the hs-err file, and parse output_detail directly for the strings in question. The ErrorHandler tests are older than those switches and could be rewritten too. > > Ha Thomas, I copied your test almost verbatim. If I send all the hs_err file to stdout, jtreg might truncate it and that won't help, also if the test someday fails, the output will be lost in the jtreg truncation. Having two test do sort of the same thing seemed nice to me. You are right, truncation could be an issue when analyzing test errors. ------------- PR: https://git.openjdk.java.net/jdk/pull/8201 From stuefe at openjdk.java.net Wed Apr 13 03:38:32 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 13 Apr 2022 03:38:32 GMT Subject: RFR: 8284274: Error reporting crashes because missing ResourceMarks [v2] In-Reply-To: References: <-Dc0lrCQpTBjof6ucB5sAuCbMZuZhXAeMqFN8poIUeo=.065fb375-c8c3-4c9b-bed9-7f3fb23bd514@github.com> Message-ID: On Tue, 12 Apr 2022 19:46:37 GMT, Coleen Phillimore wrote: > Thanks Thomas for reviewing this. I had a theory why we would see a missing ResourceMark in a loom stack trace (StackFrameStream?) but didn't have a reproducer for it. It seems better to suppress this assert completely during error reporting. I agree. > If a resource allocation is used with no current thread, that would be a different crash. I agree, we should try to avoid any allocation during hs_err file production but sometimes these resource allocations sneak in a lower level, so better to let them go. I'm surprised we don't get more asserts from ResourceMark. At SAP we rely a lot on hs-err files, and fixing secondary errors is something we did a lot. For a while, we had even tests for that and really tried to keep up, fixing every instance. But I think we gave up on that, since it bitrots too fast. Thank you for that fix! Cheers, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/8201 From stuefe at openjdk.java.net Wed Apr 13 03:40:18 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 13 Apr 2022 03:40:18 GMT Subject: RFR: JDK-8283326: Implement SafeFetch statically [v4] In-Reply-To: References: Message-ID: On Tue, 12 Apr 2022 17:42:16 GMT, Anton Kozlov wrote: >> Thomas Stuefe has updated the pull request incrementally with two additional commits since the last revision: >> >> - fix indentations >> - extend gtests to test with -1 as default value > > src/hotspot/share/runtime/safefetch.hpp line 30: > >> 28: >> 29: #include "utilities/macros.hpp" >> 30: > > Sorry, found late. This file now lacks the interface and description from the former safefetch.inline.hpp https://github.com/openjdk/jdk/blob/19b140a7f30ea600d66bcf8370d94f5d6bf6d0d1/src/hotspot/share/runtime/safefetch.inline.hpp#L35. A reader would need to look at the implementation files and assume they provide consistent interface. > > This seems not trivial just to provide declarations because in different implementation has C++ or C linkage. I can only imagine to make e.g. SafeFetch32 to call SafeFetch32_impl that may have any linkage, be inline or extern, etc. Yes, this bugged me too. I tried to keep the windows implementations inline. Your proposal makes sense, I'll do that. ------------- PR: https://git.openjdk.java.net/jdk/pull/7865 From eliu at openjdk.java.net Wed Apr 13 04:25:15 2022 From: eliu at openjdk.java.net (Eric Liu) Date: Wed, 13 Apr 2022 04:25:15 GMT Subject: Integrated: 8282528: AArch64: Incorrect replicate2L_zero rule In-Reply-To: References: Message-ID: On Thu, 24 Mar 2022 09:14:16 GMT, Eric Liu wrote: > This patch fixes the wrong matching rule of replicate2L_zero. It was > matched "ReplicateI" by mistake so that long immediates(not only zero) > had to be moved to register first and matched to replicate2L finally. To > fix this trivial bug, this patch fixes the typo and extends the rule of > replicate2L_zero to replicate2L_imm, which now supports all possible > long immediate values. > > The final code changes are shown as below: > > replicate2L_imm: > > mov x13, #0xff > movk x13, #0xff, lsl #16 > movk x13, #0xff, lsl #32 > dup v16.2d, x13 > > => > > movi v16.2d, #0xff00ff00ff > > [Test] > test/jdk/jdk/incubator/vector, test/hotspot/jtreg/compiler/vectorapi > passed without failure. This pull request has now been integrated. Changeset: c3559028 Author: Eric Liu Committer: Pengfei Li URL: https://git.openjdk.java.net/jdk/commit/c35590282d54d8388f2f7501a30365e0a912bfda Stats: 497 lines in 7 files changed: 395 ins; 36 del; 66 mod 8282528: AArch64: Incorrect replicate2L_zero rule Reviewed-by: aph ------------- PR: https://git.openjdk.java.net/jdk/pull/7939 From stuefe at openjdk.java.net Wed Apr 13 05:40:58 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 13 Apr 2022 05:40:58 GMT Subject: RFR: JDK-8283326: Implement SafeFetch statically [v5] In-Reply-To: References: Message-ID: > Hi, > > This is a reimplementation of SafeFetch to get rid of dynamic code generation. This is done, depending on platform, via static assembly, Posix setjmp/longjmp or SEH. > > This is based on a proposal by @theRealAph [1] when discussing [JDK-8282475](https://bugs.openjdk.java.net/browse/JDK-8282475). I extended the proposal to do this for all platforms, not just MacOS, see discussion below. > > --- > > Why we do this: > > SafeFetch is special: it is a basic utility function that may be called before the VM is properly initialized, from a "foreign" thread not attached to the VM, in a broken environment... mainly this is due to its use during stack walking, error reporting, hex dumping, etc. SafeFetch has to be safe to call under any circumstances - or as safe as we can make it. > > Today, SafeFetch is implemented via stub routines. That causes problems: > > - MacOs aarch64 has mechanisms to prevent execution of arbitrary non-text memory. On that platform, invoking generated code requires some awkward gymnastics [2]. These workarounds require access to Thread::current, which renders SafeFetch non-functional if Thread::current is NULL (e.g. crash reporting in "foreign" native threads or in a corrupted VM). They also cost a bit of performance on every SafeFetch invocation. Note that more OSes may implement similar execution prevention mechanics in the future. > > - There is a time window during VM initialization where the stubs are not generated yet and thus SafeFetch is not available. > > Both points cause hs-err files to be compromised (e.g. missing call stacks) for crashes in native threads, when the VM is corrupted, or early during VM initialization. Since SafeFetch is such a basic tool, it causes more issues than that (e.g., on AIX it is used for verifying mprotect() itself). But hs-err files being compromised by secondary errors is the most annoying effect. > > A minor point is that generating stubs takes a tiny bit of startup time. Not a big issue, but anything we can generate at build time instead of at runtime is good. > > --- > > The patch: > > - Removes the SafeFetch stub routine generation for all platforms > - For Linux and MacOS, it implements SafeFetch as cpu-specific static assembler routines. These routines live in `os_cpu/_/safefetch__.S`. > - On Windows, SafeFetch is implemented via SEH. This is beautifully simple and does not need handwritten assembly at all. See `os/windows/safefetch_windows.hpp`. > - On Zero, SafeFetch uses a Posix compatible solution using `sigsetjmp(2)`. This is portable and robust, but a bit slow compared to the other methods. Note that this solution existed before, and is well tested. I just moved the code around and massaged it a bit. > - AIX uses now the same method as Zero. AIX "downgraded" in that sense from the stub routine solution, but since SAP gave up maintenance of AIX, I don't have easy access to AIX hardware. If SafeFetch speed becomes an issue, I am sure a solution based on static assembly can be implemented on AIX too. > - The SafeFetch gtests were greatly expanded. > > Tests: > > - The patch was tested manually by building and running gtests on: > - MacOS (x64, aarch64) > - Linux (aarch64, arm, ppcle, s390, x64, x86, riscv) > - Windows (x64 and x86, but not arm, see below) > - AIX > - Zero (on Linux x64). > - GHAs > - The patch ran through SAP nightlies for several nights in a row > > Note: > - I have no access to Windows arm, so I could not test it. I contacted @mo-beck to verify that the patch works there. > - I have no access to BSD. I am not sure who maintains BSD, so I have no idea who to contact. However, I believe the MacOS solution should work for BSD too. If not, BSD can simply fall back to the Posix sigjmp solution like AIX and Zero. > > It would be nice to have @RealLucy, @TheRealMDoerr and @theRealAph to okay s390, ppcle and aarch64 (and possibly arm32). Each assembly file is tiny, so it should not take long. @RealFYang and @backwaterred already tested the patch on RiscV and AIX (thanks). > > Thanks, Thomas > > [1] https://github.com/openjdk/jdk/pull/7727#issuecomment-1064980598 > [2] https://github.com/openjdk/jdk/blob/4df67426ed02f18af0757897acb28b636a317a91/src/hotspot/share/runtime/safefetch.inline.hpp#L37-L41 Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: SafeFetch common prototypes in safefetch.hpp ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7865/files - new: https://git.openjdk.java.net/jdk/pull/7865/files/f9c2d9d0..16520bc2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7865&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7865&range=03-04 Stats: 58 lines in 14 files changed: 9 ins; 0 del; 49 mod Patch: https://git.openjdk.java.net/jdk/pull/7865.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7865/head:pull/7865 PR: https://git.openjdk.java.net/jdk/pull/7865 From stuefe at openjdk.java.net Wed Apr 13 05:45:08 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 13 Apr 2022 05:45:08 GMT Subject: RFR: JDK-8283326: Implement SafeFetch statically [v5] In-Reply-To: References: Message-ID: On Wed, 13 Apr 2022 05:40:58 GMT, Thomas Stuefe wrote: >> Hi, >> >> This is a reimplementation of SafeFetch to get rid of dynamic code generation. This is done, depending on platform, via static assembly, Posix setjmp/longjmp or SEH. >> >> This is based on a proposal by @theRealAph [1] when discussing [JDK-8282475](https://bugs.openjdk.java.net/browse/JDK-8282475). I extended the proposal to do this for all platforms, not just MacOS, see discussion below. >> >> --- >> >> Why we do this: >> >> SafeFetch is special: it is a basic utility function that may be called before the VM is properly initialized, from a "foreign" thread not attached to the VM, in a broken environment... mainly this is due to its use during stack walking, error reporting, hex dumping, etc. SafeFetch has to be safe to call under any circumstances - or as safe as we can make it. >> >> Today, SafeFetch is implemented via stub routines. That causes problems: >> >> - MacOs aarch64 has mechanisms to prevent execution of arbitrary non-text memory. On that platform, invoking generated code requires some awkward gymnastics [2]. These workarounds require access to Thread::current, which renders SafeFetch non-functional if Thread::current is NULL (e.g. crash reporting in "foreign" native threads or in a corrupted VM). They also cost a bit of performance on every SafeFetch invocation. Note that more OSes may implement similar execution prevention mechanics in the future. >> >> - There is a time window during VM initialization where the stubs are not generated yet and thus SafeFetch is not available. >> >> Both points cause hs-err files to be compromised (e.g. missing call stacks) for crashes in native threads, when the VM is corrupted, or early during VM initialization. Since SafeFetch is such a basic tool, it causes more issues than that (e.g., on AIX it is used for verifying mprotect() itself). But hs-err files being compromised by secondary errors is the most annoying effect. >> >> A minor point is that generating stubs takes a tiny bit of startup time. Not a big issue, but anything we can generate at build time instead of at runtime is good. >> >> --- >> >> The patch: >> >> - Removes the SafeFetch stub routine generation for all platforms >> - For Linux and MacOS, it implements SafeFetch as cpu-specific static assembler routines. These routines live in `os_cpu/_/safefetch__.S`. >> - On Windows, SafeFetch is implemented via SEH. This is beautifully simple and does not need handwritten assembly at all. See `os/windows/safefetch_windows.hpp`. >> - On Zero, SafeFetch uses a Posix compatible solution using `sigsetjmp(2)`. This is portable and robust, but a bit slow compared to the other methods. Note that this solution existed before, and is well tested. I just moved the code around and massaged it a bit. >> - AIX uses now the same method as Zero. AIX "downgraded" in that sense from the stub routine solution, but since SAP gave up maintenance of AIX, I don't have easy access to AIX hardware. If SafeFetch speed becomes an issue, I am sure a solution based on static assembly can be implemented on AIX too. >> - The SafeFetch gtests were greatly expanded. >> >> Tests: >> >> - The patch was tested manually by building and running gtests on: >> - MacOS (x64, aarch64) >> - Linux (aarch64, arm, ppcle, s390, x64, x86, riscv) >> - Windows (x64 and x86, but not arm, see below) >> - AIX >> - Zero (on Linux x64). >> - GHAs >> - The patch ran through SAP nightlies for several nights in a row >> >> Note: >> - I have no access to Windows arm, so I could not test it. I contacted @mo-beck to verify that the patch works there. >> - I have no access to BSD. I am not sure who maintains BSD, so I have no idea who to contact. However, I believe the MacOS solution should work for BSD too. If not, BSD can simply fall back to the Posix sigjmp solution like AIX and Zero. >> >> It would be nice to have @RealLucy, @TheRealMDoerr and @theRealAph to okay s390, ppcle and aarch64 (and possibly arm32). Each assembly file is tiny, so it should not take long. @RealFYang and @backwaterred already tested the patch on RiscV and AIX (thanks). >> >> Thanks, Thomas >> >> [1] https://github.com/openjdk/jdk/pull/7727#issuecomment-1064980598 >> [2] https://github.com/openjdk/jdk/blob/4df67426ed02f18af0757897acb28b636a317a91/src/hotspot/share/runtime/safefetch.inline.hpp#L37-L41 > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > SafeFetch common prototypes in safefetch.hpp I wrapped the functions into inline wrappers, which live in safefetch.hpp - easy to see that way. Re-tested on linux x86, 64, arm, aarch, zero, ppcle, windows x64, x86, mac m1. I hope this is the last major change, re-testing all this stuff is a lot of work... ------------- PR: https://git.openjdk.java.net/jdk/pull/7865 From pli at openjdk.java.net Wed Apr 13 05:46:34 2022 From: pli at openjdk.java.net (Pengfei Li) Date: Wed, 13 Apr 2022 05:46:34 GMT Subject: RFR: 8282528: AArch64: Incorrect replicate2L_zero rule [v4] In-Reply-To: References: Message-ID: <_r031LuftTJdp0nQez3GBsMfSUXwRCDfeWxUh3jr5GM=.462d9bd3-dc98-424a-98ba-5fdc94826f3c@github.com> On Tue, 12 Apr 2022 10:48:27 GMT, Eric Liu wrote: >> This patch fixes the wrong matching rule of replicate2L_zero. It was >> matched "ReplicateI" by mistake so that long immediates(not only zero) >> had to be moved to register first and matched to replicate2L finally. To >> fix this trivial bug, this patch fixes the typo and extends the rule of >> replicate2L_zero to replicate2L_imm, which now supports all possible >> long immediate values. >> >> The final code changes are shown as below: >> >> replicate2L_imm: >> >> mov x13, #0xff >> movk x13, #0xff, lsl #16 >> movk x13, #0xff, lsl #32 >> dup v16.2d, x13 >> >> => >> >> movi v16.2d, #0xff00ff00ff >> >> [Test] >> test/jdk/jdk/incubator/vector, test/hotspot/jtreg/compiler/vectorapi >> passed without failure. > > Eric Liu has updated the pull request incrementally with one additional commit since the last revision: > > remove ifelse which is triggered by empty args > > Change-Id: I461e62495c7abc0f84ef1f66443f6bcf7adbeff0 This has been internally reviewed by me. So I reviewed and sponsored it. ------------- PR: https://git.openjdk.java.net/jdk/pull/7939 From duke at openjdk.java.net Wed Apr 13 06:42:56 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Wed, 13 Apr 2022 06:42:56 GMT Subject: RFR: 8282477: [x86, aarch64] vmassert(_last_Java_pc == NULL, "already walkable"); fails with async profiler [v2] In-Reply-To: References: Message-ID: > Fix the assertion by replacing it by assertion that does not fail. Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: Do not alter JFA in sender_for_entry ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8209/files - new: https://git.openjdk.java.net/jdk/pull/8209/files/778e8418..f152367b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8209&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8209&range=00-01 Stats: 40 lines in 5 files changed: 21 ins; 4 del; 15 mod Patch: https://git.openjdk.java.net/jdk/pull/8209.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8209/head:pull/8209 PR: https://git.openjdk.java.net/jdk/pull/8209 From duke at openjdk.java.net Wed Apr 13 06:42:57 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Wed, 13 Apr 2022 06:42:57 GMT Subject: RFR: 8282477: [x86, aarch64] vmassert(_last_Java_pc == NULL, "already walkable"); fails with async profiler In-Reply-To: References: Message-ID: On Tue, 12 Apr 2022 16:38:11 GMT, Johannes Bechberger wrote: > Fix the assertion by replacing it by assertion that does not fail. You're right. But I would choose a different approach: `sender_for_entry` should not modify the anchor. I modified my PR accordingly. ------------- PR: https://git.openjdk.java.net/jdk/pull/8209 From njian at openjdk.java.net Wed Apr 13 07:10:09 2022 From: njian at openjdk.java.net (Ningsheng Jian) Date: Wed, 13 Apr 2022 07:10:09 GMT Subject: RFR: 8282541: AArch64: Auto-vectorize Math.round API In-Reply-To: References: Message-ID: <88RK-3hLy6Q3WdSNYrHqvdjqMnXtk7FhEBsPhNAADeE=.d35f4b9a-b161-470c-b73d-32e58aa68e3e@github.com> On Tue, 12 Apr 2022 13:26:02 GMT, Andrew Haley wrote: > Before, Apple M1: > > +-----------------------------------------+---------------------------------+ > |Benchmark | (TESTSIZE) Mode Score Units| > +-----------------------------------------+---------------------------------+ > |FpRoundingBenchmark.test_round_double | 1024 thrpt 1612.391 ops/ms| > |FpRoundingBenchmark.test_round_double | 2048 thrpt 804.291 ops/ms| > |FpRoundingBenchmark.test_round_float | 1024 thrpt 1558.202 ops/ms| > |FpRoundingBenchmark.test_round_float | 2048 thrpt 775.730 ops/ms| > +------------------------------------------+--------------------------------+ > > After: > > +-----------------------------------------+----------------------------------+ > |Benchmark | (TESTSIZE) Mode Score Units| > +-----------------------------------------+----------------------------------+ > |FpRoundingBenchmark.test_round_double | 1024 thrpt 2720.153 ops/ms| > |FpRoundingBenchmark.test_round_double | 2048 thrpt 1371.750 ops/ms| > |FpRoundingBenchmark.test_round_float | 1024 thrpt 5940.263 ops/ms| > |FpRoundingBenchmark.test_round_float | 2048 thrpt 3036.201 ops/ms| > +-----------------------------------------+----------------------------------+ > > About the algorithm: > > `Math.round()` is tricky. Its specification corresponds to no standard > rounding mode: it "returns the closest long to the argument, with ties > rounding to positive infinity." For positive inputs this is the same > as IEEE-754's `convertToIntegerTiesToAway` operation, which rounds > away from zero, but there's no equivalent for negative inputs. > > `Math.round()` used simply to add 0.5 and convert to integer by taking > the floor of the result, but that wasn't right because it suffers from > double rounding. This breaks several cases, in particular because > > `0.4999999... (+) 0.5 == 1.0` > > (Here, `(+)` indicates an addition followed by roundTiesToEven.) > > There is no corresponding problem with `-0.4999999...` or `-0.9999999...` > > Also, in the 32-bit `float` case, > > `8388609 (+) 0.5 == 8388610` > > because 8388609 (0x1.000002p+23) as a 32-bit integer has no fraction > bits, so adding 0.5, followed by roundTiesToEven, rounds upwards. This > problem manifests for every odd integer within the binade from > 0x1.000002p+23 to 0x1.fffffep+23, whether positive or negative. There > is a corresponding problem for the `double` range. > > The patch for JDK-8279508 handles this by flipping the floating-point > rounding mode to roundTowardNegative, adding 0.5, and taking the > floor. While this does work on AArch64, the performance is > tragic. AArch64 implementations seem to wait for all instructions in > flight to retire, change the rounding mode, and do the operation. This > effectively serializes the entire thread. > > This patch takes a different approach. Firstly, we can observe that we > can use the `frinta` instruction for the entire positive range. The > negative range is a bit trickier, but we can observe that any x, > abs{x) >= -0x1.000000p+23, has no fractional bits so it must be an > integer. For convenence, we can convert that range with the `frinta` > instruction as well. > > All that remains are x < 0, abs{x) < -0x1.000000p+23. Adding 0.5 > followed by roundTiesToEven doesn't lead to a problem because for > x < 0 && abs{x) >= 0.5, adding 0.5 only reduces the magnitude of x; > for all x < 0 && abs{x) < 0.5, adding 0.5 followed by roundTiesToEven > return 0. src/hotspot/cpu/aarch64/aarch64_neon_ad.m4 line 374: > 372: VECTOR_JAVA_FROUND(F, 4F, I, T4S, 4, INT, vReg) > 373: VECTOR_JAVA_FROUND(D, 2D, L, T2D, 2, LONG, vReg) > 374: I don't know why do we need these rules. Should "UseSVE > 0" all go to the rules in sve ad file which call to vector_round_sve()? src/hotspot/cpu/aarch64/aarch64_sve_ad.m4 line 2130: > 2128: %{ > 2129: predicate(UseSVE > 0 && > 2130: n->as_Vector()->length() == $5); Remove `n->as_Vector()->length() == $5` ? I think there is no need to limit vector length for SVE, i.e. for all SVE vector lengths, we should generate the same code. For example, you have limited the size to 8F below, which is 256 bits but there's no rule for other bits (512) of vector then. ------------- PR: https://git.openjdk.java.net/jdk/pull/8204 From akozlov at openjdk.java.net Wed Apr 13 08:04:29 2022 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Wed, 13 Apr 2022 08:04:29 GMT Subject: RFR: JDK-8283326: Implement SafeFetch statically [v5] In-Reply-To: References: Message-ID: On Wed, 13 Apr 2022 05:40:58 GMT, Thomas Stuefe wrote: >> Hi, >> >> This is a reimplementation of SafeFetch to get rid of dynamic code generation. This is done, depending on platform, via static assembly, Posix setjmp/longjmp or SEH. >> >> This is based on a proposal by @theRealAph [1] when discussing [JDK-8282475](https://bugs.openjdk.java.net/browse/JDK-8282475). I extended the proposal to do this for all platforms, not just MacOS, see discussion below. >> >> --- >> >> Why we do this: >> >> SafeFetch is special: it is a basic utility function that may be called before the VM is properly initialized, from a "foreign" thread not attached to the VM, in a broken environment... mainly this is due to its use during stack walking, error reporting, hex dumping, etc. SafeFetch has to be safe to call under any circumstances - or as safe as we can make it. >> >> Today, SafeFetch is implemented via stub routines. That causes problems: >> >> - MacOs aarch64 has mechanisms to prevent execution of arbitrary non-text memory. On that platform, invoking generated code requires some awkward gymnastics [2]. These workarounds require access to Thread::current, which renders SafeFetch non-functional if Thread::current is NULL (e.g. crash reporting in "foreign" native threads or in a corrupted VM). They also cost a bit of performance on every SafeFetch invocation. Note that more OSes may implement similar execution prevention mechanics in the future. >> >> - There is a time window during VM initialization where the stubs are not generated yet and thus SafeFetch is not available. >> >> Both points cause hs-err files to be compromised (e.g. missing call stacks) for crashes in native threads, when the VM is corrupted, or early during VM initialization. Since SafeFetch is such a basic tool, it causes more issues than that (e.g., on AIX it is used for verifying mprotect() itself). But hs-err files being compromised by secondary errors is the most annoying effect. >> >> A minor point is that generating stubs takes a tiny bit of startup time. Not a big issue, but anything we can generate at build time instead of at runtime is good. >> >> --- >> >> The patch: >> >> - Removes the SafeFetch stub routine generation for all platforms >> - For Linux and MacOS, it implements SafeFetch as cpu-specific static assembler routines. These routines live in `os_cpu/_/safefetch__.S`. >> - On Windows, SafeFetch is implemented via SEH. This is beautifully simple and does not need handwritten assembly at all. See `os/windows/safefetch_windows.hpp`. >> - On Zero, SafeFetch uses a Posix compatible solution using `sigsetjmp(2)`. This is portable and robust, but a bit slow compared to the other methods. Note that this solution existed before, and is well tested. I just moved the code around and massaged it a bit. >> - AIX uses now the same method as Zero. AIX "downgraded" in that sense from the stub routine solution, but since SAP gave up maintenance of AIX, I don't have easy access to AIX hardware. If SafeFetch speed becomes an issue, I am sure a solution based on static assembly can be implemented on AIX too. >> - The SafeFetch gtests were greatly expanded. >> >> Tests: >> >> - The patch was tested manually by building and running gtests on: >> - MacOS (x64, aarch64) >> - Linux (aarch64, arm, ppcle, s390, x64, x86, riscv) >> - Windows (x64 and x86, but not arm, see below) >> - AIX >> - Zero (on Linux x64). >> - GHAs >> - The patch ran through SAP nightlies for several nights in a row >> >> Note: >> - I have no access to Windows arm, so I could not test it. I contacted @mo-beck to verify that the patch works there. >> - I have no access to BSD. I am not sure who maintains BSD, so I have no idea who to contact. However, I believe the MacOS solution should work for BSD too. If not, BSD can simply fall back to the Posix sigjmp solution like AIX and Zero. >> >> It would be nice to have @RealLucy, @TheRealMDoerr and @theRealAph to okay s390, ppcle and aarch64 (and possibly arm32). Each assembly file is tiny, so it should not take long. @RealFYang and @backwaterred already tested the patch on RiscV and AIX (thanks). >> >> Thanks, Thomas >> >> [1] https://github.com/openjdk/jdk/pull/7727#issuecomment-1064980598 >> [2] https://github.com/openjdk/jdk/blob/4df67426ed02f18af0757897acb28b636a317a91/src/hotspot/share/runtime/safefetch.inline.hpp#L37-L41 > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > SafeFetch common prototypes in safefetch.hpp Really appreciate the last change. A last minor comment is below. In the rest, looks good. Thank you! src/hotspot/share/runtime/safefetch.hpp line 47: > 45: > 46: > 47: inline int SafeFetch32(int* adr, int errValue) { It would be nice to preserve the old comment ("Safefetch allows to load a value from a location that's not known to be valid ..."). ------------- Marked as reviewed by akozlov (Committer). PR: https://git.openjdk.java.net/jdk/pull/7865 From duke at openjdk.java.net Wed Apr 13 08:38:59 2022 From: duke at openjdk.java.net (KIRIYAMA Takuya) Date: Wed, 13 Apr 2022 08:38:59 GMT Subject: RFR: 8280761: UseCompressedOops should be set after limit_heap_by_allocatable_memory [v5] In-Reply-To: References: Message-ID: > I fixed to set UseCompressedOops flag after limit_heap_by_allocatable_memory(). > So when ulimit -v is called and -XX:MaxRAM is set, UseCompressedOops does not become false. > And all hotspot tier1 test are passed. > Would you please review this fix? KIRIYAMA Takuya has updated the pull request incrementally with one additional commit since the last revision: 8280761 UseCompressedOops should be set after limit_heap_by_allocatable_memory ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7938/files - new: https://git.openjdk.java.net/jdk/pull/7938/files/486aa9ef..e2fe253f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7938&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7938&range=03-04 Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/7938.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7938/head:pull/7938 PR: https://git.openjdk.java.net/jdk/pull/7938 From duke at openjdk.java.net Wed Apr 13 08:38:59 2022 From: duke at openjdk.java.net (KIRIYAMA Takuya) Date: Wed, 13 Apr 2022 08:38:59 GMT Subject: RFR: 8280761: UseCompressedOops should be set after limit_heap_by_allocatable_memory [v4] In-Reply-To: References: Message-ID: On Tue, 12 Apr 2022 06:50:32 GMT, KIRIYAMA Takuya wrote: >> I fixed to set UseCompressedOops flag after limit_heap_by_allocatable_memory(). >> So when ulimit -v is called and -XX:MaxRAM is set, UseCompressedOops does not become false. >> And all hotspot tier1 test are passed. >> Would you please review this fix? > > KIRIYAMA Takuya has updated the pull request incrementally with one additional commit since the last revision: > > 8280761 UseCompressedOops should be set after limit_heap_by_allocatable_memory > Slight rewording, // Setting MaxRAMPercentage explicitly to make the test more resilient. Thank you, I fixed this comment. > Embedding ulimit -v inside checkFlag still hinders readability, IMO. Sounds good. I fixed this tests as you advised. ------------- PR: https://git.openjdk.java.net/jdk/pull/7938 From ayang at openjdk.java.net Wed Apr 13 08:44:07 2022 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Wed, 13 Apr 2022 08:44:07 GMT Subject: RFR: 8280761: UseCompressedOops should be set after limit_heap_by_allocatable_memory [v5] In-Reply-To: References: Message-ID: On Wed, 13 Apr 2022 08:38:59 GMT, KIRIYAMA Takuya wrote: >> I fixed to set UseCompressedOops flag after limit_heap_by_allocatable_memory(). >> So when ulimit -v is called and -XX:MaxRAM is set, UseCompressedOops does not become false. >> And all hotspot tier1 test are passed. >> Would you please review this fix? > > KIRIYAMA Takuya has updated the pull request incrementally with one additional commit since the last revision: > > 8280761 UseCompressedOops should be set after limit_heap_by_allocatable_memory Marked as reviewed by ayang (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7938 From shade at openjdk.java.net Wed Apr 13 09:15:14 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 13 Apr 2022 09:15:14 GMT Subject: RFR: 8284578: Relax InterpreterCodelet stub alignment [v2] In-Reply-To: References: Message-ID: > `InterpreterCodelet` is aligned by `CodeEntryAlignment` (`CAE`) twice. First, the entire stub is aligned, which aligns its data section. Then, the code section in the stub is aligned. Since `CAE` is usually larger than the size of `InterpreterCodelet`, we are wasting quite a bit of space for each codelet. In the extreme cases, like PPC that defaults to `CAE=128`, we have 16 bytes of codelet data effectively taking 128 bytes! > > This can be made better by relaxing the `InterpreterCodelet` stub alignment to `HeapWordSize`, while leaving its code section alignment the same. > > This tangentially touches the only other user for `StubQueue`: `ICStub`. Unfortunately, we cannot do the same kind of relaxation there, because there is a reverse lookup function that needs to reach data section from the code section, which forces us to keep the same alignment for both. > > Interpreter sizes on Linux x86_64 release: > > > # Baseline, CEA=32 (default) > code size = 94K bytes > avg codelet size = 356 bytes > > # Baseline, CEA=128 (PPC-like) > code size = 133K bytes > avg codelet size = 501 bytes > > # Patched, CEA=32 (default) > code size = 89K bytes > avg codelet size = 338 bytes > > # Patched, CEA=128 (PPC-like) > code size = 100K bytes > avg codelet size = 380 bytes > > > Point performance runs (SPECjvm2008:serial with `-Xint` on Linux x86_64 release): > > > Benchmark Mode Cnt Score Error Units > > # Baseline, CEA=32 > Serial.test thrpt 9 73.427 ? 0.152 ops/s > > # Baseline, CEA=128 > Serial.test thrpt 9 70.999 ? 0.246 ops/s > > # Patched, CEA=32 > Serial.test thrpt 9 73.991 ? 0.860 ops/s > > # Patched, CEA=128 > Serial.test thrpt 9 72.981 ? 0.301 ops/s > > > Additional testing: > - [x] Linux x86_64 fastdebug `tier1` > - [x] Linux x86_64 fastdebug `tier2` > - [x] Linux x86_64 fastdebug `tier3` 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: - Relax slack space a bit - Merge branch 'master' into JDK-8284578-intcodelet-align - Initial implementation ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8159/files - new: https://git.openjdk.java.net/jdk/pull/8159/files/952d52b4..3a42e573 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8159&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8159&range=00-01 Stats: 141369 lines in 1378 files changed: 100670 ins; 6900 del; 33799 mod Patch: https://git.openjdk.java.net/jdk/pull/8159.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8159/head:pull/8159 PR: https://git.openjdk.java.net/jdk/pull/8159 From shade at openjdk.java.net Wed Apr 13 09:15:15 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 13 Apr 2022 09:15:15 GMT Subject: RFR: 8284578: Relax InterpreterCodelet stub alignment In-Reply-To: References: Message-ID: <3OXJOp1qGo8C8kKBZERN0qZGQfZW1eKDyUw6dyN6ork=.bf018f88-82b7-43a2-b33c-d0a398c3a8f6@github.com> On Mon, 11 Apr 2022 22:56:55 GMT, Dean Long wrote: > Does your change make this recent change obsolete, or is it still needed? > > https://github.com/openjdk/jdk/blob/026b85303c01326bc49a1105a89853d7641fcd50/src/hotspot/share/interpreter/templateInterpreter.cpp#L53 Checked, the additional slack space for alignment is still needed for the `compiler/arguments/TestCodeEntryAlignment.java` that tries large `CodeEntryAlignment`-s. `CodeEntryAlignment*2` is too much. `HeapWordSize * 2` is not enough. `HeapWordSize + CodeEntryAlignment` fits the intent of the patch. See new commit. ------------- PR: https://git.openjdk.java.net/jdk/pull/8159 From stuefe at openjdk.java.net Wed Apr 13 09:22:45 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 13 Apr 2022 09:22:45 GMT Subject: RFR: JDK-8283326: Implement SafeFetch statically [v6] In-Reply-To: References: Message-ID: > Hi, > > This is a reimplementation of SafeFetch to get rid of dynamic code generation. This is done, depending on platform, via static assembly, Posix setjmp/longjmp or SEH. > > This is based on a proposal by @theRealAph [1] when discussing [JDK-8282475](https://bugs.openjdk.java.net/browse/JDK-8282475). I extended the proposal to do this for all platforms, not just MacOS, see discussion below. > > --- > > Why we do this: > > SafeFetch is special: it is a basic utility function that may be called before the VM is properly initialized, from a "foreign" thread not attached to the VM, in a broken environment... mainly this is due to its use during stack walking, error reporting, hex dumping, etc. SafeFetch has to be safe to call under any circumstances - or as safe as we can make it. > > Today, SafeFetch is implemented via stub routines. That causes problems: > > - MacOs aarch64 has mechanisms to prevent execution of arbitrary non-text memory. On that platform, invoking generated code requires some awkward gymnastics [2]. These workarounds require access to Thread::current, which renders SafeFetch non-functional if Thread::current is NULL (e.g. crash reporting in "foreign" native threads or in a corrupted VM). They also cost a bit of performance on every SafeFetch invocation. Note that more OSes may implement similar execution prevention mechanics in the future. > > - There is a time window during VM initialization where the stubs are not generated yet and thus SafeFetch is not available. > > Both points cause hs-err files to be compromised (e.g. missing call stacks) for crashes in native threads, when the VM is corrupted, or early during VM initialization. Since SafeFetch is such a basic tool, it causes more issues than that (e.g., on AIX it is used for verifying mprotect() itself). But hs-err files being compromised by secondary errors is the most annoying effect. > > A minor point is that generating stubs takes a tiny bit of startup time. Not a big issue, but anything we can generate at build time instead of at runtime is good. > > --- > > The patch: > > - Removes the SafeFetch stub routine generation for all platforms > - For Linux and MacOS, it implements SafeFetch as cpu-specific static assembler routines. These routines live in `os_cpu/_/safefetch__.S`. > - On Windows, SafeFetch is implemented via SEH. This is beautifully simple and does not need handwritten assembly at all. See `os/windows/safefetch_windows.hpp`. > - On Zero, SafeFetch uses a Posix compatible solution using `sigsetjmp(2)`. This is portable and robust, but a bit slow compared to the other methods. Note that this solution existed before, and is well tested. I just moved the code around and massaged it a bit. > - AIX uses now the same method as Zero. AIX "downgraded" in that sense from the stub routine solution, but since SAP gave up maintenance of AIX, I don't have easy access to AIX hardware. If SafeFetch speed becomes an issue, I am sure a solution based on static assembly can be implemented on AIX too. > - The SafeFetch gtests were greatly expanded. > > Tests: > > - The patch was tested manually by building and running gtests on: > - MacOS (x64, aarch64) > - Linux (aarch64, arm, ppcle, s390, x64, x86, riscv) > - Windows (x64 and x86, but not arm, see below) > - AIX > - Zero (on Linux x64). > - GHAs > - The patch ran through SAP nightlies for several nights in a row > > Note: > - I have no access to Windows arm, so I could not test it. I contacted @mo-beck to verify that the patch works there. > - I have no access to BSD. I am not sure who maintains BSD, so I have no idea who to contact. However, I believe the MacOS solution should work for BSD too. If not, BSD can simply fall back to the Posix sigjmp solution like AIX and Zero. > > It would be nice to have @RealLucy, @TheRealMDoerr and @theRealAph to okay s390, ppcle and aarch64 (and possibly arm32). Each assembly file is tiny, so it should not take long. @RealFYang and @backwaterred already tested the patch on RiscV and AIX (thanks). > > Thanks, Thomas > > [1] https://github.com/openjdk/jdk/pull/7727#issuecomment-1064980598 > [2] https://github.com/openjdk/jdk/blob/4df67426ed02f18af0757897acb28b636a317a91/src/hotspot/share/runtime/safefetch.inline.hpp#L37-L41 Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: re-add lost comment ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7865/files - new: https://git.openjdk.java.net/jdk/pull/7865/files/16520bc2..03b0cf34 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7865&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7865&range=04-05 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7865.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7865/head:pull/7865 PR: https://git.openjdk.java.net/jdk/pull/7865 From stuefe at openjdk.java.net Wed Apr 13 09:22:48 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 13 Apr 2022 09:22:48 GMT Subject: RFR: JDK-8283326: Implement SafeFetch statically [v5] In-Reply-To: References: Message-ID: On Wed, 13 Apr 2022 07:59:01 GMT, Anton Kozlov wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> SafeFetch common prototypes in safefetch.hpp > > src/hotspot/share/runtime/safefetch.hpp line 47: > >> 45: >> 46: >> 47: inline int SafeFetch32(int* adr, int errValue) { > > It would be nice to preserve the old comment ("Safefetch allows to load a value from a location that's not known to be valid ..."). Thank you, Anton. I re-added the comment as you proposed. ------------- PR: https://git.openjdk.java.net/jdk/pull/7865 From dfuchs at openjdk.java.net Wed Apr 13 09:52:13 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 13 Apr 2022 09:52:13 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) In-Reply-To: References: Message-ID: <0TWk5zeiftA1QMeIsGcHifCZ2qSb30DiHmheGwMK64s=.85193997-2184-42bc-a65b-b14fb6ccd2af@github.com> On Tue, 12 Apr 2022 13:02:44 GMT, Alan Bateman wrote: >> src/java.base/share/classes/java/io/BufferedReader.java line 101: >> >>> 99: */ >>> 100: public BufferedReader(Reader in, int sz) { >>> 101: Objects.requireNonNull(in); >> >> Not sure if that even matters - but there will be a slight change of behaviour here if `InternalLock.CAN_USE_INTERNAL_LOCK` is ever `false`. Instead of synchronizing on `in`, the `BufferedReader` will synchronize on `this`. >> Now that I think of it - it probably does matter since even if CAN_USE_INTERNAL_LOCK is true, untrusted subclasses of BufferedReader calling this constructor might expect the locking to be performed on `in`? > >> Not sure if that even matters - but there will be a slight change of behaviour here if `InternalLock.CAN_USE_INTERNAL_LOCK` is ever `false`. Instead of synchronizing on `in`, the `BufferedReader` will synchronize on `this`. > > Good! We can change this so that depends on whether BufferedReader is extended and whether the given Reader is trusted. It's not clear if anyone could reliably depend on undocumented behavior like this but we have to be cautious at the same time. Thanks - the same issue appears with `BufferedWriter`/`Writer`. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From shade at openjdk.java.net Wed Apr 13 09:57:01 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 13 Apr 2022 09:57:01 GMT Subject: RFR: 8284584: Avoid duplicate node_idx_t definitions [v2] In-Reply-To: References: Message-ID: > While looking at `Node`, I realized there are two definitions for node_idx_t, another one added by [JDK-8076284](https://bugs.openjdk.java.net/browse/JDK-8076284). These should be de-duplicated to avoid confusion. 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: - Leave one definition in compile.hpp only - Merge branch 'master' into JDK-8284584-node-idx-duplicate - Move ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8164/files - new: https://git.openjdk.java.net/jdk/pull/8164/files/21cea3b2..980ba3bf Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8164&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8164&range=00-01 Stats: 141377 lines in 1379 files changed: 100676 ins; 6905 del; 33796 mod Patch: https://git.openjdk.java.net/jdk/pull/8164.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8164/head:pull/8164 PR: https://git.openjdk.java.net/jdk/pull/8164 From shade at openjdk.java.net Wed Apr 13 09:57:01 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 13 Apr 2022 09:57:01 GMT Subject: RFR: 8284584: Avoid duplicate node_idx_t definitions [v2] In-Reply-To: References: Message-ID: On Fri, 8 Apr 2022 17:04:31 GMT, Vladimir Kozlov wrote: > I am not sure we want to move C2's specific type to general code. `node.hpp` includes `compile.hpp` so may be leave definition there only. `compile.hpp` looks like a dumping ground for everything global to C2, right? If so, it indeed makes sense to leave the only definition there. Please see new commit. ------------- PR: https://git.openjdk.java.net/jdk/pull/8164 From mdoerr at openjdk.java.net Wed Apr 13 09:57:25 2022 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Wed, 13 Apr 2022 09:57:25 GMT Subject: RFR: 8282477: [x86, aarch64] vmassert(_last_Java_pc == NULL, "already walkable"); fails with async profiler [v2] In-Reply-To: References: Message-ID: On Wed, 13 Apr 2022 06:42:56 GMT, Johannes Bechberger wrote: >> Fix the assertion by replacing it by assertion that does not fail. > > Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: > > Do not alter JFA in sender_for_entry This makes sense. Please make sure to test it in our nightly tests. ------------- PR: https://git.openjdk.java.net/jdk/pull/8209 From duke at openjdk.java.net Wed Apr 13 10:05:19 2022 From: duke at openjdk.java.net (duke) Date: Wed, 13 Apr 2022 10:05:19 GMT Subject: Withdrawn: 8214976: Warn about uses of functions replaced for portability In-Reply-To: References: Message-ID: On Thu, 27 Jan 2022 19:18:10 GMT, Harold Seigel wrote: > Please review this new attempt to resolve JDK-8214976. This fix adds Pragmas to generate compilation errors, when using gcc, if calling a native system function instead of the os:: version of the function. The fix includes changes to calls in non-shared code because it is cleaner than adding PRAGMAs and, for some cases, the os:: version of a function has added value, such as asserts and RESTARTABLE. This fix slightly changes the signature of os::abort() so it wouldn't conflict with native abort() functions. Changes to Windows code is left for a future RFE. > > This fix was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, Mach5 tiers 3-5 on Linux x64, and Mach5 builds of Zero, PPC, and s390. > > Thanks, Harold This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/7248 From rkennke at openjdk.java.net Wed Apr 13 10:06:46 2022 From: rkennke at openjdk.java.net (Roman Kennke) Date: Wed, 13 Apr 2022 10:06:46 GMT Subject: RFR: 8284816: Make markWord::has_monitor() more robust Message-ID: Currently, markWord::has_monitor() is implemented like this: ` return ((value() & monitor_value) != 0);` monitor value is `0b10`. This means that it also reports marked or forwarded objects (`0b11`) as having a monitor, which is wrong. As far as I can tell, it does not cause any problems because relevant code is either not affected by marked/forwarded objects, or by testing bits in an order that hides the problem. I suggest to test the bits properly to make it more robust and avoid potenial future bugs. Testing: - [x] tier1 - [ ] tier2 - [ ] tier3 ------------- Commit messages: - 8284816: Make markWord::has_monitor() more robust Changes: https://git.openjdk.java.net/jdk/pull/8219/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8219&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8284816 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8219.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8219/head:pull/8219 PR: https://git.openjdk.java.net/jdk/pull/8219 From ngasson at openjdk.java.net Wed Apr 13 10:14:15 2022 From: ngasson at openjdk.java.net (Nick Gasson) Date: Wed, 13 Apr 2022 10:14:15 GMT Subject: RFR: 8282541: AArch64: Auto-vectorize Math.round API In-Reply-To: References: Message-ID: On Tue, 12 Apr 2022 13:26:02 GMT, Andrew Haley wrote: > Before, Apple M1: > > +-----------------------------------------+---------------------------------+ > |Benchmark | (TESTSIZE) Mode Score Units| > +-----------------------------------------+---------------------------------+ > |FpRoundingBenchmark.test_round_double | 1024 thrpt 1612.391 ops/ms| > |FpRoundingBenchmark.test_round_double | 2048 thrpt 804.291 ops/ms| > |FpRoundingBenchmark.test_round_float | 1024 thrpt 1558.202 ops/ms| > |FpRoundingBenchmark.test_round_float | 2048 thrpt 775.730 ops/ms| > +------------------------------------------+--------------------------------+ > > After: > > +-----------------------------------------+----------------------------------+ > |Benchmark | (TESTSIZE) Mode Score Units| > +-----------------------------------------+----------------------------------+ > |FpRoundingBenchmark.test_round_double | 1024 thrpt 2720.153 ops/ms| > |FpRoundingBenchmark.test_round_double | 2048 thrpt 1371.750 ops/ms| > |FpRoundingBenchmark.test_round_float | 1024 thrpt 5940.263 ops/ms| > |FpRoundingBenchmark.test_round_float | 2048 thrpt 3036.201 ops/ms| > +-----------------------------------------+----------------------------------+ > > About the algorithm: > > `Math.round()` is tricky. Its specification corresponds to no standard > rounding mode: it "returns the closest long to the argument, with ties > rounding to positive infinity." For positive inputs this is the same > as IEEE-754's `convertToIntegerTiesToAway` operation, which rounds > away from zero, but there's no equivalent for negative inputs. > > `Math.round()` used simply to add 0.5 and convert to integer by taking > the floor of the result, but that wasn't right because it suffers from > double rounding. This breaks several cases, in particular because > > `0.4999999... (+) 0.5 == 1.0` > > (Here, `(+)` indicates an addition followed by roundTiesToEven.) > > There is no corresponding problem with `-0.4999999...` or `-0.9999999...` > > Also, in the 32-bit `float` case, > > `8388609 (+) 0.5 == 8388610` > > because 8388609 (0x1.000002p+23) as a 32-bit integer has no fraction > bits, so adding 0.5, followed by roundTiesToEven, rounds upwards. This > problem manifests for every odd integer within the binade from > 0x1.000002p+23 to 0x1.fffffep+23, whether positive or negative. There > is a corresponding problem for the `double` range. > > The patch for JDK-8279508 handles this by flipping the floating-point > rounding mode to roundTowardNegative, adding 0.5, and taking the > floor. While this does work on AArch64, the performance is > tragic. AArch64 implementations seem to wait for all instructions in > flight to retire, change the rounding mode, and do the operation. This > effectively serializes the entire thread. > > This patch takes a different approach. Firstly, we can observe that we > can use the `frinta` instruction for the entire positive range. The > negative range is a bit trickier, but we can observe that any x, > abs{x) >= -0x1.000000p+23, has no fractional bits so it must be an > integer. For convenence, we can convert that range with the `frinta` > instruction as well. > > All that remains are x < 0, abs{x) < -0x1.000000p+23. Adding 0.5 > followed by roundTiesToEven doesn't lead to a problem because for > x < 0 && abs{x) >= 0.5, adding 0.5 only reduces the magnitude of x; > for all x < 0 && abs{x) < 0.5, adding 0.5 followed by roundTiesToEven > return 0. src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5198: > 5196: fcvtasd(dst, src); > 5197: // Test if src >= 0 || abs(src) >= 0x1.0p52 > 5198: eor(rscratch1, rscratch1, 1ul << 63); // flip sign bit This doesn't compile on Windows AArch64: d:\a\jdk\jdk\jdk\src\hotspot\cpu\aarch64\macroAssembler_aarch64.cpp(5198): error C2220: the following warning is treated as an error d:\a\jdk\jdk\jdk\src\hotspot\cpu\aarch64\macroAssembler_aarch64.cpp(5198): warning C4293: '<<': shift count negative or too big, undefined behavior Windows is LLP64 isn't it? So you probably want 1ull or `UCONST64(1)` here. ------------- PR: https://git.openjdk.java.net/jdk/pull/8204 From stuefe at openjdk.java.net Wed Apr 13 10:27:15 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 13 Apr 2022 10:27:15 GMT Subject: RFR: 8284816: Make markWord::has_monitor() more robust In-Reply-To: References: Message-ID: On Wed, 13 Apr 2022 09:59:49 GMT, Roman Kennke wrote: > Currently, markWord::has_monitor() is implemented like this: > > ` return ((value() & monitor_value) != 0);` > > monitor value is `0b10`. This means that it also reports marked or forwarded objects (`0b11`) as having a monitor, which is wrong. As far as I can tell, it does not cause any problems because relevant code is either not affected by marked/forwarded objects, or by testing bits in an order that hides the problem. > > I suggest to test the bits properly to make it more robust and avoid potenial future bugs. > > Testing: > - [x] tier1 > - [ ] tier2 > - [ ] tier3 LGTM ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8219 From stuefe at openjdk.java.net Wed Apr 13 10:35:16 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 13 Apr 2022 10:35:16 GMT Subject: RFR: JDK-8284754: print more interesting env variables in hs_err and VM.info In-Reply-To: References: Message-ID: <3XAFzaQvRgQ4ngm46Xef8O2rCFj89LM1Ezymg_MqiQw=.1885e8c4-a831-4d1f-8f46-3be1bc6b4d5d@github.com> On Tue, 12 Apr 2022 14:19:06 GMT, Matthias Baesken wrote: > There are a few more interesting env variables, e.g. documented here > https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html > that should be printed in hs_err for better supportability. > For example, TMPDIR is a cross platform addition to what was done for Windows with : 8283497: [windows] print TMP and TEMP in hs_err and VM.info . Looks good and trivial. ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8205 From ayang at openjdk.java.net Wed Apr 13 10:50:24 2022 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Wed, 13 Apr 2022 10:50:24 GMT Subject: RFR: 8280761: UseCompressedOops should be set after limit_heap_by_allocatable_memory [v5] In-Reply-To: References: Message-ID: On Wed, 13 Apr 2022 08:38:59 GMT, KIRIYAMA Takuya wrote: >> I fixed to set UseCompressedOops flag after limit_heap_by_allocatable_memory(). >> So when ulimit -v is called and -XX:MaxRAM is set, UseCompressedOops does not become false. >> And all hotspot tier1 test are passed. >> Would you please review this fix? > > KIRIYAMA Takuya has updated the pull request incrementally with one additional commit since the last revision: > > 8280761 UseCompressedOops should be set after limit_heap_by_allocatable_memory Need sth like this to resolve the failure. // Convert bytes to kbytes for ulimit -v var ulimit_prefix = "ulimit -v " + (ulimit / 1024); ... ProcessBuilder pb = new ProcessBuilder("sh", "-c", ulimit_prefix + ";" + cmd); ------------- PR: https://git.openjdk.java.net/jdk/pull/7938 From mbaesken at openjdk.java.net Wed Apr 13 11:52:16 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Wed, 13 Apr 2022 11:52:16 GMT Subject: Integrated: JDK-8284754: print more interesting env variables in hs_err and VM.info In-Reply-To: References: Message-ID: On Tue, 12 Apr 2022 14:19:06 GMT, Matthias Baesken wrote: > There are a few more interesting env variables, e.g. documented here > https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html > that should be printed in hs_err for better supportability. > For example, TMPDIR is a cross platform addition to what was done for Windows with : 8283497: [windows] print TMP and TEMP in hs_err and VM.info . This pull request has now been integrated. Changeset: 8ee2944c Author: Matthias Baesken URL: https://git.openjdk.java.net/jdk/commit/8ee2944cc404d4d53d0f94b56dd52111fd31cc39 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod 8284754: print more interesting env variables in hs_err and VM.info Reviewed-by: stuefe ------------- PR: https://git.openjdk.java.net/jdk/pull/8205 From duke at openjdk.java.net Wed Apr 13 11:53:23 2022 From: duke at openjdk.java.net (ExE Boss) Date: Wed, 13 Apr 2022 11:53:23 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) In-Reply-To: <0TWk5zeiftA1QMeIsGcHifCZ2qSb30DiHmheGwMK64s=.85193997-2184-42bc-a65b-b14fb6ccd2af@github.com> References: <0TWk5zeiftA1QMeIsGcHifCZ2qSb30DiHmheGwMK64s=.85193997-2184-42bc-a65b-b14fb6ccd2af@github.com> Message-ID: On Wed, 13 Apr 2022 09:49:04 GMT, Daniel Fuchs wrote: >>> Not sure if that even matters - but there will be a slight change of behaviour here if `InternalLock.CAN_USE_INTERNAL_LOCK` is ever `false`. Instead of synchronizing on `in`, the `BufferedReader` will synchronize on `this`. >> >> Good! We can change this so that depends on whether BufferedReader is extended and whether the given Reader is trusted. It's not clear if anyone could reliably depend on undocumented behavior like this but we have to be cautious at the same time. > > Thanks - the same issue appears with `BufferedWriter`/`Writer`. The?solution is?to?add the?`private`?constructor: private Reader(Object fallbackLock, Void internal) { // assert fallbackLock != null; // use InternalLock for trusted classes Class clazz = getClass(); if (clazz == InputStreamReader.class || clazz == BufferedReader.class || clazz == FileReader.class || clazz == sun.nio.cs.StreamDecoder.class) { this.lock = InternalLock.newLockOr(fallbackLock); } else { this.lock = fallbackLock; } } to?`Reader` (and?an?equivalent `private`?constructor to?`Writer`). --- The?`protected`?`Reader`?constructors can?then be?changed to: protected Reader() { this(this, null); } and protected Reader(Object lock) { this(Objects.requireNonNull(lock), null); } --- Doing?so will?allow this?change to?be?reverted: Suggestion: super(in); ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From duke at openjdk.java.net Wed Apr 13 11:53:27 2022 From: duke at openjdk.java.net (ExE Boss) Date: Wed, 13 Apr 2022 11:53:27 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) In-Reply-To: References: Message-ID: <4-uBO0InSz17RTM1s27E5N7wWALqT4QnQDEqaC1Msbk=.4864c9fe-caeb-4eb6-aaaf-1ac5695049c6@github.com> On Tue, 12 Apr 2022 19:09:32 GMT, Daniel Jeli?ski wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > src/java.base/share/classes/sun/nio/cs/StreamEncoder.java line 110: > >> 108: >> 109: public void flushBuffer() throws IOException { >> 110: if (lock instanceof InternalLock locker) { > > now that StreamEncoder is final, we can drop the `else` branch Actually, we?can?t in?case `InternalLock.CAN_USE_INTERNAL_LOCK` is?ever?`false` (which?it might?be if?it gets?exposed as?a?system?property). ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From alanb at openjdk.java.net Wed Apr 13 12:02:16 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 13 Apr 2022 12:02:16 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) In-Reply-To: <0jpZ1dprNSBX81zrd455SGK5Z_vvp5EtT5oS8b-XLxE=.adac88d9-cef5-479b-b94d-2de4cf381909@github.com> References: <0jpZ1dprNSBX81zrd455SGK5Z_vvp5EtT5oS8b-XLxE=.adac88d9-cef5-479b-b94d-2de4cf381909@github.com> Message-ID: <42x8p2tSXc1XsNqEQV1xTKhIfg9RBPLMiY2YQOwkS_Q=.25eb38fd-d338-49b5-a0aa-240043062f7b@github.com> On Tue, 12 Apr 2022 16:49:41 GMT, Daniel Jeli?ski wrote: > If it was, please update the javadoc - `NANOSECONDS.toMillis(-1)` = 0 implies no waiting in Net.poll It's benign for the current usages but you are right, it was not intentional. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From zgu at openjdk.java.net Wed Apr 13 12:31:16 2022 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Wed, 13 Apr 2022 12:31:16 GMT Subject: RFR: 8284816: Make markWord::has_monitor() more robust In-Reply-To: References: Message-ID: <9sDJ2KwDHlSIhk08pjwDrP0WsUnOgzDKS7G-02BqsOM=.f6aba9cb-9453-4e92-9c3c-3f912ff4bb19@github.com> On Wed, 13 Apr 2022 09:59:49 GMT, Roman Kennke wrote: > Currently, markWord::has_monitor() is implemented like this: > > ` return ((value() & monitor_value) != 0);` > > monitor value is `0b10`. This means that it also reports marked or forwarded objects (`0b11`) as having a monitor, which is wrong. As far as I can tell, it does not cause any problems because relevant code is either not affected by marked/forwarded objects, or by testing bits in an order that hides the problem. > > I suggest to test the bits properly to make it more robust and avoid potenial future bugs. > > Testing: > - [x] tier1 > - [ ] tier2 > - [ ] tier3 Good. ------------- Marked as reviewed by zgu (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8219 From alanb at openjdk.java.net Wed Apr 13 14:21:20 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 13 Apr 2022 14:21:20 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2] In-Reply-To: References: Message-ID: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com> > This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. > > We will refresh this PR periodically to pick up changes and fixes from the loom repo. > > Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. > > The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. > > There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. > > The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. > > The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: Refresh ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8166/files - new: https://git.openjdk.java.net/jdk/pull/8166/files/21972f45..0e12c206 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8166&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8166&range=00-01 Stats: 1837 lines in 112 files changed: 786 ins; 531 del; 520 mod Patch: https://git.openjdk.java.net/jdk/pull/8166.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8166/head:pull/8166 PR: https://git.openjdk.java.net/jdk/pull/8166 From alanb at openjdk.java.net Wed Apr 13 14:22:18 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 13 Apr 2022 14:22:18 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2] In-Reply-To: <4-uBO0InSz17RTM1s27E5N7wWALqT4QnQDEqaC1Msbk=.4864c9fe-caeb-4eb6-aaaf-1ac5695049c6@github.com> References: <4-uBO0InSz17RTM1s27E5N7wWALqT4QnQDEqaC1Msbk=.4864c9fe-caeb-4eb6-aaaf-1ac5695049c6@github.com> Message-ID: On Wed, 13 Apr 2022 11:35:33 GMT, ExE Boss wrote: > Actually, we?can?t in?case `InternalLock.CAN_USE_INTERNAL_LOCK` is?ever?`false` That's right, both StreamEncoder and StreamDecoder need the both cases. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From coleenp at openjdk.java.net Wed Apr 13 14:49:31 2022 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 13 Apr 2022 14:49:31 GMT Subject: RFR: 8284274: Error reporting crashes because missing ResourceMarks [v2] In-Reply-To: <-Dc0lrCQpTBjof6ucB5sAuCbMZuZhXAeMqFN8poIUeo=.065fb375-c8c3-4c9b-bed9-7f3fb23bd514@github.com> References: <-Dc0lrCQpTBjof6ucB5sAuCbMZuZhXAeMqFN8poIUeo=.065fb375-c8c3-4c9b-bed9-7f3fb23bd514@github.com> Message-ID: On Tue, 12 Apr 2022 16:17:13 GMT, Coleen Phillimore wrote: >> Taking the suggestion from @stefank in the bug report, disable the ResourceMark missing assert during error reporting. There's a ResourceArea in the thread that can be used. Added a test. >> Tested with tier1-4 on x86 and aarch64 platforms. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Add some variable names for test values. Thank you David and Thomas for the reviews. ------------- PR: https://git.openjdk.java.net/jdk/pull/8201 From coleenp at openjdk.java.net Wed Apr 13 14:49:34 2022 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 13 Apr 2022 14:49:34 GMT Subject: Integrated: 8284274: Error reporting crashes because missing ResourceMarks In-Reply-To: References: Message-ID: On Tue, 12 Apr 2022 12:01:15 GMT, Coleen Phillimore wrote: > Taking the suggestion from @stefank in the bug report, disable the ResourceMark missing assert during error reporting. There's a ResourceArea in the thread that can be used. Added a test. > Tested with tier1-4 on x86 and aarch64 platforms. This pull request has now been integrated. Changeset: e245f9d2 Author: Coleen Phillimore URL: https://git.openjdk.java.net/jdk/commit/e245f9d2007b0a6c9962b6bf4488ba4d4ce47e92 Stats: 132 lines in 3 files changed: 129 ins; 0 del; 3 mod 8284274: Error reporting crashes because missing ResourceMarks Reviewed-by: dholmes, stuefe ------------- PR: https://git.openjdk.java.net/jdk/pull/8201 From alanb at openjdk.java.net Wed Apr 13 14:59:32 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 13 Apr 2022 14:59:32 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2] In-Reply-To: References: <0TWk5zeiftA1QMeIsGcHifCZ2qSb30DiHmheGwMK64s=.85193997-2184-42bc-a65b-b14fb6ccd2af@github.com> Message-ID: On Wed, 13 Apr 2022 11:38:55 GMT, ExE Boss wrote: >> Thanks - the same issue appears with `BufferedWriter`/`Writer`. > > The?solution is?to?add the?`private`?constructor: > > private Reader(Object fallbackLock, Void internal) { > // assert fallbackLock != null; > // use InternalLock for trusted classes > Class clazz = getClass(); > if (clazz == InputStreamReader.class > || clazz == BufferedReader.class > || clazz == FileReader.class > || clazz == sun.nio.cs.StreamDecoder.class) { > this.lock = InternalLock.newLockOr(fallbackLock); > } else { > this.lock = fallbackLock; > } > } > > to?`Reader` (and?an?equivalent `private`?constructor to?`Writer`). > > --- > > The?`protected`?`Reader`?constructors can?then be?changed to: > > protected Reader() { > this(this, null); > } > > and > > protected Reader(Object lock) { > this(Objects.requireNonNull(lock), null); > } > > > --- > > Doing?so will?allow this?change to?be?reverted: > Suggestion: > > super(in); > Thanks - the same issue appears with `BufferedWriter`/`Writer`. Right. I think we can reduce this to the case where a BufferedReader is not subclassed, and it wraps an InputStreamReader or FileReader that have not been subclassed. Similarly the case where a BufferedWriter is not subclassed and it wraps an OutputStreamWriter or FileWriter that have not been subclassed. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From rkennke at openjdk.java.net Wed Apr 13 15:02:15 2022 From: rkennke at openjdk.java.net (Roman Kennke) Date: Wed, 13 Apr 2022 15:02:15 GMT Subject: RFR: 8284816: Make markWord::has_monitor() more robust In-Reply-To: <6_Yp8-8cJGp_W74uJ9T7jh6FzjG5nxvKy8gtfw-b7dY=.08da3180-4b14-46d6-b8d9-16d970202e5f@github.com> References: <6_Yp8-8cJGp_W74uJ9T7jh6FzjG5nxvKy8gtfw-b7dY=.08da3180-4b14-46d6-b8d9-16d970202e5f@github.com> Message-ID: On Wed, 13 Apr 2022 14:57:08 GMT, Daniel D. Daugherty wrote: >> Currently, markWord::has_monitor() is implemented like this: >> >> ` return ((value() & monitor_value) != 0);` >> >> monitor value is `0b10`. This means that it also reports marked or forwarded objects (`0b11`) as having a monitor, which is wrong. As far as I can tell, it does not cause any problems because relevant code is either not affected by marked/forwarded objects, or by testing bits in an order that hides the problem. >> >> I suggest to test the bits properly to make it more robust and avoid potenial future bugs. >> >> Testing: >> - [x] tier1 >> - [ ] tier2 >> - [ ] tier3 > > src/hotspot/share/oops/markWord.hpp line 179: > >> 177: } >> 178: bool has_monitor() const { >> 179: return ((value() & lock_mask_in_place) == monitor_value); > > So I'm a bit confused: > > src/hotspot/share/oops/markWord.hpp: > > `static const uintptr_t monitor_value = 2;` > > In the bug report you say: >> monitor value is 0b10 > > but that not what I'm seeing. What am I missing? Binary (0b) 10 == decimal 2 ;-) ------------- PR: https://git.openjdk.java.net/jdk/pull/8219 From duke at openjdk.java.net Wed Apr 13 15:02:36 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Wed, 13 Apr 2022 15:02:36 GMT Subject: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing Message-ID: Move the AsyncGetCallTrace method implementation into a separate method and wrap its call in non-assert compilation mode in `os::ThreadCrashProtection` like it is done in [JFR](https://github.com/openjdk/jdk/blob/965ea8d9cd29aee41ba2b1b0b0c67bb67eca22dd/src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp#L165). This prevents AsyncGetCallTrace from crashing on segmentation faults (but not on `guarantee`s). If a crash is observed, then the `num_frames` field of the trace is set to `ticks_unknown_state` (-7) to signal a state that cannot be properly handled. `ticks_unknown_state` is currently also used for signaling unknown thread states but this should not be a problem, as the semantic is the same. If `num_frames` already has an error code then this error code is not changed. This helps to distinguish between errors in walking threads in Java and non-Java mode, as `num_frames` is set there before the walking to the appropriate error code. _Thanks for @tstuefe for suggesting this._ ------------- Commit messages: - Wrap ASGCT in crash protection code Changes: https://git.openjdk.java.net/jdk/pull/8225/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8225&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8284828 Stats: 144 lines in 1 file changed: 87 ins; 56 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8225.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8225/head:pull/8225 PR: https://git.openjdk.java.net/jdk/pull/8225 From dcubed at openjdk.java.net Wed Apr 13 15:02:14 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 13 Apr 2022 15:02:14 GMT Subject: RFR: 8284816: Make markWord::has_monitor() more robust In-Reply-To: References: Message-ID: <6_Yp8-8cJGp_W74uJ9T7jh6FzjG5nxvKy8gtfw-b7dY=.08da3180-4b14-46d6-b8d9-16d970202e5f@github.com> On Wed, 13 Apr 2022 09:59:49 GMT, Roman Kennke wrote: > Currently, markWord::has_monitor() is implemented like this: > > ` return ((value() & monitor_value) != 0);` > > monitor value is `0b10`. This means that it also reports marked or forwarded objects (`0b11`) as having a monitor, which is wrong. As far as I can tell, it does not cause any problems because relevant code is either not affected by marked/forwarded objects, or by testing bits in an order that hides the problem. > > I suggest to test the bits properly to make it more robust and avoid potenial future bugs. > > Testing: > - [x] tier1 > - [ ] tier2 > - [ ] tier3 Changes requested by dcubed (Reviewer). src/hotspot/share/oops/markWord.hpp line 179: > 177: } > 178: bool has_monitor() const { > 179: return ((value() & lock_mask_in_place) == monitor_value); So I'm a bit confused: src/hotspot/share/oops/markWord.hpp: `static const uintptr_t monitor_value = 2;` In the bug report you say: > monitor value is 0b10 but that not what I'm seeing. What am I missing? ------------- PR: https://git.openjdk.java.net/jdk/pull/8219 From dcubed at openjdk.java.net Wed Apr 13 15:15:26 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 13 Apr 2022 15:15:26 GMT Subject: RFR: 8284816: Make markWord::has_monitor() more robust In-Reply-To: References: <6_Yp8-8cJGp_W74uJ9T7jh6FzjG5nxvKy8gtfw-b7dY=.08da3180-4b14-46d6-b8d9-16d970202e5f@github.com> Message-ID: On Wed, 13 Apr 2022 14:58:57 GMT, Roman Kennke wrote: >> src/hotspot/share/oops/markWord.hpp line 179: >> >>> 177: } >>> 178: bool has_monitor() const { >>> 179: return ((value() & lock_mask_in_place) == monitor_value); >> >> So I'm a bit confused: >> >> src/hotspot/share/oops/markWord.hpp: >> >> `static const uintptr_t monitor_value = 2;` >> >> In the bug report you say: >>> monitor value is 0b10 >> >> but that not what I'm seeing. What am I missing? > > Binary (0b) 10 == decimal 2 ;-) Sorry, I read that as 0xb10. ------------- PR: https://git.openjdk.java.net/jdk/pull/8219 From jbachorik at openjdk.java.net Wed Apr 13 15:17:20 2022 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Wed, 13 Apr 2022 15:17:20 GMT Subject: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing In-Reply-To: References: Message-ID: On Wed, 13 Apr 2022 14:53:54 GMT, Johannes Bechberger wrote: > Move the AsyncGetCallTrace method implementation into a separate method and wrap its call in non-assert compilation mode in `os::ThreadCrashProtection` like it is done in [JFR](https://github.com/openjdk/jdk/blob/965ea8d9cd29aee41ba2b1b0b0c67bb67eca22dd/src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp#L165). > This prevents AsyncGetCallTrace from crashing on segmentation faults (but not on `guarantee`s). > > If a crash is observed, then the `num_frames` field of the trace is set to `ticks_unknown_state` (-7) to signal a state that cannot be properly handled. `ticks_unknown_state` is currently also used for signaling unknown thread states but this should not be a problem, as the semantic is the same. If `num_frames` already has an error code then this error code is not changed. This helps to distinguish between errors in walking threads in Java and non-Java mode, as `num_frames` is set there before the walking to the appropriate error code. > > _Thanks for @tstuefe for suggesting this._ src/hotspot/share/prims/forte.cpp line 671: > 669: #ifndef ASSERT > 670: trace->num_frames = ticks_unknown_state; > 671: AsyncGetCallTraceCallBack cb(trace, depth, ucontext); ~Isn't [this assert](https://github.com/openjdk/jdk/blob/e245f9d2007b0a6c9962b6bf4488ba4d4ce47e92/src/hotspot/os/posix/os_posix.cpp#L1158) failing? It seems like the crash protection is only for the JFR sampler thread.~ OIC - this is only when asserts are not enabled. ------------- PR: https://git.openjdk.java.net/jdk/pull/8225 From dcubed at openjdk.java.net Wed Apr 13 15:19:16 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 13 Apr 2022 15:19:16 GMT Subject: RFR: 8284816: Make markWord::has_monitor() more robust In-Reply-To: References: Message-ID: On Wed, 13 Apr 2022 09:59:49 GMT, Roman Kennke wrote: > Currently, markWord::has_monitor() is implemented like this: > > ` return ((value() & monitor_value) != 0);` > > monitor value is `0b10`. This means that it also reports marked or forwarded objects (`0b11`) as having a monitor, which is wrong. As far as I can tell, it does not cause any problems because relevant code is either not affected by marked/forwarded objects, or by testing bits in an order that hides the problem. > > I suggest to test the bits properly to make it more robust and avoid potenial future bugs. > > Testing: > - [x] tier1 > - [ ] tier2 > - [ ] tier3 I agree that the new code is more precise. Thumbs up. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8219 From stuefe at openjdk.java.net Wed Apr 13 15:23:09 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 13 Apr 2022 15:23:09 GMT Subject: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing In-Reply-To: References: Message-ID: <0sKTrq19b1zQ9EWEXIZlVbj008SJiu3OcIKBQCgOEwc=.cde5895d-63b5-48df-a7fe-79eaccc911b0@github.com> On Wed, 13 Apr 2022 14:53:54 GMT, Johannes Bechberger wrote: > Move the AsyncGetCallTrace method implementation into a separate method and wrap its call in non-assert compilation mode in `os::ThreadCrashProtection` like it is done in [JFR](https://github.com/openjdk/jdk/blob/965ea8d9cd29aee41ba2b1b0b0c67bb67eca22dd/src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp#L165). > This prevents AsyncGetCallTrace from crashing on segmentation faults (but not on `guarantee`s). > > If a crash is observed, then the `num_frames` field of the trace is set to `ticks_unknown_state` (-7) to signal a state that cannot be properly handled. `ticks_unknown_state` is currently also used for signaling unknown thread states but this should not be a problem, as the semantic is the same. If `num_frames` already has an error code then this error code is not changed. This helps to distinguish between errors in walking threads in Java and non-Java mode, as `num_frames` is set there before the walking to the appropriate error code. > > _Thanks for @tstuefe for suggesting this._ src/hotspot/share/prims/forte.cpp line 508: > 506: > 507: > 508: void asyncGetCallTraceImpl(ASGCT_CallTrace *trace, jint depth, void* ucontext) { make it static? No need to export this. src/hotspot/share/prims/forte.cpp line 669: > 667: JNIEXPORT > 668: void AsyncGetCallTrace(ASGCT_CallTrace *trace, jint depth, void* ucontext) { > 669: #ifndef ASSERT Since ThreadCrashProtection uses Thread::current, here I would bail for Thread::current_or_null_safe() == NULL src/hotspot/share/prims/forte.cpp line 674: > 672: os::ThreadCrashProtection crash_protection; > 673: if (!crash_protection.call(cb)) { > 674: if (trace->num_frames < -10 || trace->num_frames >= 0) { Where does this -10 come from? ------------- PR: https://git.openjdk.java.net/jdk/pull/8225 From stuefe at openjdk.java.net Wed Apr 13 15:23:10 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 13 Apr 2022 15:23:10 GMT Subject: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing In-Reply-To: References: Message-ID: On Wed, 13 Apr 2022 15:11:41 GMT, Jaroslav Bachorik wrote: >> Move the AsyncGetCallTrace method implementation into a separate method and wrap its call in non-assert compilation mode in `os::ThreadCrashProtection` like it is done in [JFR](https://github.com/openjdk/jdk/blob/965ea8d9cd29aee41ba2b1b0b0c67bb67eca22dd/src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp#L165). >> This prevents AsyncGetCallTrace from crashing on segmentation faults (but not on `guarantee`s). >> >> If a crash is observed, then the `num_frames` field of the trace is set to `ticks_unknown_state` (-7) to signal a state that cannot be properly handled. `ticks_unknown_state` is currently also used for signaling unknown thread states but this should not be a problem, as the semantic is the same. If `num_frames` already has an error code then this error code is not changed. This helps to distinguish between errors in walking threads in Java and non-Java mode, as `num_frames` is set there before the walking to the appropriate error code. >> >> _Thanks for @tstuefe for suggesting this._ > > src/hotspot/share/prims/forte.cpp line 671: > >> 669: #ifndef ASSERT >> 670: trace->num_frames = ticks_unknown_state; >> 671: AsyncGetCallTraceCallBack cb(trace, depth, ucontext); > > ~Isn't [this assert](https://github.com/openjdk/jdk/blob/e245f9d2007b0a6c9962b6bf4488ba4d4ce47e92/src/hotspot/os/posix/os_posix.cpp#L1158) failing? It seems like the crash protection is only for the JFR sampler thread.~ > > OIC - this is only when asserts are not enabled. I think if we start using ThreadCrashProtection like a general-purpose class, we should make it one and remove the JFR dependencies. ------------- PR: https://git.openjdk.java.net/jdk/pull/8225 From stuefe at openjdk.java.net Wed Apr 13 15:35:26 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 13 Apr 2022 15:35:26 GMT Subject: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing In-Reply-To: References: Message-ID: On Wed, 13 Apr 2022 14:53:54 GMT, Johannes Bechberger wrote: > Move the AsyncGetCallTrace method implementation into a separate method and wrap its call in non-assert compilation mode in `os::ThreadCrashProtection` like it is done in [JFR](https://github.com/openjdk/jdk/blob/965ea8d9cd29aee41ba2b1b0b0c67bb67eca22dd/src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp#L165). > This prevents AsyncGetCallTrace from crashing on segmentation faults (but not on `guarantee`s). > > If a crash is observed, then the `num_frames` field of the trace is set to `ticks_unknown_state` (-7) to signal a state that cannot be properly handled. `ticks_unknown_state` is currently also used for signaling unknown thread states but this should not be a problem, as the semantic is the same. If `num_frames` already has an error code then this error code is not changed. This helps to distinguish between errors in walking threads in Java and non-Java mode, as `num_frames` is set there before the walking to the appropriate error code. > > _Thanks for @tstuefe for suggesting this._ I'm actually ambivalent about the "production only" thing. I dislike having different behavior between debug and release, I prefer to test what later runs in the field. Also, if we prevent crashes because we want to ignore them, we should ignore them in debug too, otherwise, we burn error analysis cycles needlessly. Optionally, I'd make the behavior of ThreadCrashProtection switchable at runtime with a diagnostic XX switch. That switch would control the jumping back in the signal handler. That way, if you encounter strange bugs while using async profiler, one can disable the crash guard and enable asserts and crashes. If you decide to do that, we should also do tests for it, so maybe leave it for a future RFE. ------------- PR: https://git.openjdk.java.net/jdk/pull/8225 From duke at openjdk.java.net Wed Apr 13 15:35:29 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Wed, 13 Apr 2022 15:35:29 GMT Subject: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing In-Reply-To: References: Message-ID: On Wed, 13 Apr 2022 15:19:43 GMT, Thomas Stuefe wrote: >> src/hotspot/share/prims/forte.cpp line 671: >> >>> 669: #ifndef ASSERT >>> 670: trace->num_frames = ticks_unknown_state; >>> 671: AsyncGetCallTraceCallBack cb(trace, depth, ucontext); >> >> ~Isn't [this assert](https://github.com/openjdk/jdk/blob/e245f9d2007b0a6c9962b6bf4488ba4d4ce47e92/src/hotspot/os/posix/os_posix.cpp#L1158) failing? It seems like the crash protection is only for the JFR sampler thread.~ >> >> OIC - this is only when asserts are not enabled. > > I think if we start using ThreadCrashProtection like a general-purpose class, we should make it one and remove the JFR dependencies. I fully agree, should I do this as part of this PR? ------------- PR: https://git.openjdk.java.net/jdk/pull/8225 From duke at openjdk.java.net Wed Apr 13 15:41:46 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Wed, 13 Apr 2022 15:41:46 GMT Subject: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing [v2] In-Reply-To: References: Message-ID: <2EvIrXO3KCfYDt1_O5tkJRAwvxik7E1yj98cE8UK6ls=.23cce809-aae8-48da-95d3-c2a162768b26@github.com> > Move the AsyncGetCallTrace method implementation into a separate method and wrap its call in non-assert compilation mode in `os::ThreadCrashProtection` like it is done in [JFR](https://github.com/openjdk/jdk/blob/965ea8d9cd29aee41ba2b1b0b0c67bb67eca22dd/src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp#L165). > This prevents AsyncGetCallTrace from crashing on segmentation faults (but not on `guarantee`s). > > If a crash is observed, then the `num_frames` field of the trace is set to `ticks_unknown_state` (-7) to signal a state that cannot be properly handled. `ticks_unknown_state` is currently also used for signaling unknown thread states but this should not be a problem, as the semantic is the same. If `num_frames` already has an error code then this error code is not changed. This helps to distinguish between errors in walking threads in Java and non-Java mode, as `num_frames` is set there before the walking to the appropriate error code. > > _Thanks for @tstuefe for suggesting this._ Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: Check for Thread::current_or_null_safe and other stuff ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8225/files - new: https://git.openjdk.java.net/jdk/pull/8225/files/4b5f34c6..80d227cd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8225&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8225&range=00-01 Stats: 7 lines in 1 file changed: 5 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8225.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8225/head:pull/8225 PR: https://git.openjdk.java.net/jdk/pull/8225 From duke at openjdk.java.net Wed Apr 13 15:41:48 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Wed, 13 Apr 2022 15:41:48 GMT Subject: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing [v2] In-Reply-To: <0sKTrq19b1zQ9EWEXIZlVbj008SJiu3OcIKBQCgOEwc=.cde5895d-63b5-48df-a7fe-79eaccc911b0@github.com> References: <0sKTrq19b1zQ9EWEXIZlVbj008SJiu3OcIKBQCgOEwc=.cde5895d-63b5-48df-a7fe-79eaccc911b0@github.com> Message-ID: On Wed, 13 Apr 2022 15:18:15 GMT, Thomas Stuefe wrote: >> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: >> >> Check for Thread::current_or_null_safe and other stuff > > src/hotspot/share/prims/forte.cpp line 674: > >> 672: os::ThreadCrashProtection crash_protection; >> 673: if (!crash_protection.call(cb)) { >> 674: if (trace->num_frames < -10 || trace->num_frames >= 0) { > > Where does this -10 come from? it is the lowest error code ------------- PR: https://git.openjdk.java.net/jdk/pull/8225 From duke at openjdk.java.net Wed Apr 13 15:41:49 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Wed, 13 Apr 2022 15:41:49 GMT Subject: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing [v2] In-Reply-To: References: <0sKTrq19b1zQ9EWEXIZlVbj008SJiu3OcIKBQCgOEwc=.cde5895d-63b5-48df-a7fe-79eaccc911b0@github.com> Message-ID: On Wed, 13 Apr 2022 15:36:05 GMT, Johannes Bechberger wrote: >> src/hotspot/share/prims/forte.cpp line 674: >> >>> 672: os::ThreadCrashProtection crash_protection; >>> 673: if (!crash_protection.call(cb)) { >>> 674: if (trace->num_frames < -10 || trace->num_frames >= 0) { >> >> Where does this -10 come from? > > it is the lowest error code I removed it, an invalid error code should never happen. ------------- PR: https://git.openjdk.java.net/jdk/pull/8225 From duke at openjdk.java.net Wed Apr 13 15:47:08 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Wed, 13 Apr 2022 15:47:08 GMT Subject: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing [v3] In-Reply-To: References: Message-ID: > Move the AsyncGetCallTrace method implementation into a separate method and wrap its call in non-assert compilation mode in `os::ThreadCrashProtection` like it is done in [JFR](https://github.com/openjdk/jdk/blob/965ea8d9cd29aee41ba2b1b0b0c67bb67eca22dd/src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp#L165). > This prevents AsyncGetCallTrace from crashing on segmentation faults (but not on `guarantee`s). > > If a crash is observed, then the `num_frames` field of the trace is set to `ticks_unknown_state` (-7) to signal a state that cannot be properly handled. `ticks_unknown_state` is currently also used for signaling unknown thread states but this should not be a problem, as the semantic is the same. If `num_frames` already has an error code then this error code is not changed. This helps to distinguish between errors in walking threads in Java and non-Java mode, as `num_frames` is set there before the walking to the appropriate error code. > > _Thanks for @tstuefe for suggesting this._ Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: Turn it always on ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8225/files - new: https://git.openjdk.java.net/jdk/pull/8225/files/80d227cd..d3a66505 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8225&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8225&range=01-02 Stats: 5 lines in 1 file changed: 0 ins; 5 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8225.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8225/head:pull/8225 PR: https://git.openjdk.java.net/jdk/pull/8225 From jbachorik at openjdk.java.net Wed Apr 13 15:47:08 2022 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Wed, 13 Apr 2022 15:47:08 GMT Subject: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing In-Reply-To: References: Message-ID: On Wed, 13 Apr 2022 15:29:00 GMT, Thomas Stuefe wrote: >> Move the AsyncGetCallTrace method implementation into a separate method and wrap its call in non-assert compilation mode in `os::ThreadCrashProtection` like it is done in [JFR](https://github.com/openjdk/jdk/blob/965ea8d9cd29aee41ba2b1b0b0c67bb67eca22dd/src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp#L165). >> This prevents AsyncGetCallTrace from crashing on segmentation faults (but not on `guarantee`s). >> >> If a crash is observed, then the `num_frames` field of the trace is set to `ticks_unknown_state` (-7) to signal a state that cannot be properly handled. `ticks_unknown_state` is currently also used for signaling unknown thread states but this should not be a problem, as the semantic is the same. If `num_frames` already has an error code then this error code is not changed. This helps to distinguish between errors in walking threads in Java and non-Java mode, as `num_frames` is set there before the walking to the appropriate error code. >> >> _Thanks for @tstuefe for suggesting this._ > > I'm actually ambivalent about the "production only" thing. > > I dislike having different behavior between debug and release, I prefer to test what later runs in the field. Also, if we prevent crashes because we want to ignore them, we should ignore them in debug too, otherwise, we burn error analysis cycles needlessly. > > Optionally, I'd make the behavior of ThreadCrashProtection switchable at runtime with a diagnostic XX switch. That switch would control the jumping back in the signal handler. That way, if you encounter strange bugs while using async profiler, one can disable the crash guard and enable asserts and crashes. If you decide to do that, we should also do tests for it, so maybe leave it for a future RFE. What @tstuefe said about debug vs. production made me wonder whether the assert in `ThreadCrashProtection` is still useful at all. I mean, we are deliberately using it from threads other than the JFR sampler thread and if that usage is not breaking stuff left and right, probably we could remove it? (/cc @mgronlun) ------------- PR: https://git.openjdk.java.net/jdk/pull/8225 From duke at openjdk.java.net Wed Apr 13 15:47:09 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Wed, 13 Apr 2022 15:47:09 GMT Subject: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing In-Reply-To: References: Message-ID: On Wed, 13 Apr 2022 15:29:00 GMT, Thomas Stuefe wrote: > I dislike having different behavior between debug and release, I prefer to test what later runs in the field. Also, if we prevent crashes because we want to ignore them, we should ignore them in debug too, otherwise, we burn error analysis cycles needlessly. I copied this from JFR (where this the default, albeit configurable behaviour). But I agree and changed it. > What @tstuefe said about debug vs. production made me wonder whether the assert in ThreadCrashProtection is still useful at all. I mean, we are deliberately using it from threads other than the JFR sampler thread and if that usage is not breaking stuff left and right, probably we could remove it? I agree, I'm going to remove it. Its functionality is too good to be restrained to JFR. ------------- PR: https://git.openjdk.java.net/jdk/pull/8225 From duke at openjdk.java.net Wed Apr 13 15:55:52 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Wed, 13 Apr 2022 15:55:52 GMT Subject: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing [v4] In-Reply-To: References: Message-ID: <8xwsTix84l48SqTssnCpU7XBD2IasVdqIJnntlNvr3U=.e9b83bf8-ff74-4ad4-a4f6-4cae3fb3df13@github.com> > Move the AsyncGetCallTrace method implementation into a separate method and wrap its call in non-assert compilation mode in `os::ThreadCrashProtection` like it is done in [JFR](https://github.com/openjdk/jdk/blob/965ea8d9cd29aee41ba2b1b0b0c67bb67eca22dd/src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp#L165). > This prevents AsyncGetCallTrace from crashing on segmentation faults (but not on `guarantee`s). > > If a crash is observed, then the `num_frames` field of the trace is set to `ticks_unknown_state` (-7) to signal a state that cannot be properly handled. `ticks_unknown_state` is currently also used for signaling unknown thread states but this should not be a problem, as the semantic is the same. If `num_frames` already has an error code then this error code is not changed. This helps to distinguish between errors in walking threads in Java and non-Java mode, as `num_frames` is set there before the walking to the appropriate error code. > > _Thanks for @tstuefe for suggesting this._ Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: Remove JFR assert from ThreadCrashProtection Remove the Thread::is_JfrSampler_thread() method too, as it has only be used by the removed asserts ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8225/files - new: https://git.openjdk.java.net/jdk/pull/8225/files/d3a66505..77a21cb5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8225&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8225&range=02-03 Stats: 9 lines in 6 files changed: 1 ins; 4 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/8225.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8225/head:pull/8225 PR: https://git.openjdk.java.net/jdk/pull/8225 From alanb at openjdk.java.net Wed Apr 13 16:16:23 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 13 Apr 2022 16:16:23 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v27] In-Reply-To: References: Message-ID: On Tue, 12 Apr 2022 10:24:47 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.java.net/jeps/424 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Add @ForceInline annotation on session accessor > Beef up UnrolledAccess benchmark src/java.base/share/classes/java/nio/channels/FileChannel.java line 1052: > 1050: public MemorySegment map(MapMode mode, long offset, long size, > 1051: MemorySession session) > 1052: throws IOException, UnsupportedOperationException Just a minor here is that UOE is a runtime exception so probably shouldn't be in the throws. ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From kvn at openjdk.java.net Wed Apr 13 16:37:19 2022 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Wed, 13 Apr 2022 16:37:19 GMT Subject: RFR: 8284584: Avoid duplicate node_idx_t definitions [v2] In-Reply-To: References: Message-ID: <64Ej4l0iJ6bIXzdl9NGu0avVEAtSld_Yd31MjONQsi0=.61960c77-07bb-441e-8c66-ee967cce4212@github.com> On Wed, 13 Apr 2022 09:57:01 GMT, Aleksey Shipilev wrote: >> While looking at `Node`, I realized there are two definitions for node_idx_t, another one added by [JDK-8076284](https://bugs.openjdk.java.net/browse/JDK-8076284). These should be de-duplicated to avoid confusion. > > 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: > > - Leave one definition in compile.hpp only > - Merge branch 'master' into JDK-8284584-node-idx-duplicate > - Move Marked as reviewed by kvn (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8164 From kvn at openjdk.java.net Wed Apr 13 16:41:14 2022 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Wed, 13 Apr 2022 16:41:14 GMT Subject: RFR: 8284578: Relax InterpreterCodelet stub alignment [v2] In-Reply-To: References: Message-ID: On Wed, 13 Apr 2022 09:15:14 GMT, Aleksey Shipilev wrote: >> `InterpreterCodelet` is aligned by `CodeEntryAlignment` (`CAE`) twice. First, the entire stub is aligned, which aligns its data section. Then, the code section in the stub is aligned. Since `CAE` is usually larger than the size of `InterpreterCodelet`, we are wasting quite a bit of space for each codelet. In the extreme cases, like PPC that defaults to `CAE=128`, we have 16 bytes of codelet data effectively taking 128 bytes! >> >> This can be made better by relaxing the `InterpreterCodelet` stub alignment to `HeapWordSize`, while leaving its code section alignment the same. >> >> This tangentially touches the only other user for `StubQueue`: `ICStub`. Unfortunately, we cannot do the same kind of relaxation there, because there is a reverse lookup function that needs to reach data section from the code section, which forces us to keep the same alignment for both. >> >> Interpreter sizes on Linux x86_64 release: >> >> >> # Baseline, CEA=32 (default) >> code size = 94K bytes >> avg codelet size = 356 bytes >> >> # Baseline, CEA=128 (PPC-like) >> code size = 133K bytes >> avg codelet size = 501 bytes >> >> # Patched, CEA=32 (default) >> code size = 89K bytes >> avg codelet size = 338 bytes >> >> # Patched, CEA=128 (PPC-like) >> code size = 100K bytes >> avg codelet size = 380 bytes >> >> >> Point performance runs (SPECjvm2008:serial with `-Xint` on Linux x86_64 release): >> >> >> Benchmark Mode Cnt Score Error Units >> >> # Baseline, CEA=32 >> Serial.test thrpt 9 73.427 ? 0.152 ops/s >> >> # Baseline, CEA=128 >> Serial.test thrpt 9 70.999 ? 0.246 ops/s >> >> # Patched, CEA=32 >> Serial.test thrpt 9 73.991 ? 0.860 ops/s >> >> # Patched, CEA=128 >> Serial.test thrpt 9 72.981 ? 0.301 ops/s >> >> >> Additional testing: >> - [x] Linux x86_64 fastdebug `tier1` >> - [x] Linux x86_64 fastdebug `tier2` >> - [x] Linux x86_64 fastdebug `tier3` > > 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: > > - Relax slack space a bit > - Merge branch 'master' into JDK-8284578-intcodelet-align > - Initial implementation Looks good. I will test it. ------------- PR: https://git.openjdk.java.net/jdk/pull/8159 From mgronlun at openjdk.java.net Wed Apr 13 16:57:15 2022 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Wed, 13 Apr 2022 16:57:15 GMT Subject: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing [v4] In-Reply-To: <8xwsTix84l48SqTssnCpU7XBD2IasVdqIJnntlNvr3U=.e9b83bf8-ff74-4ad4-a4f6-4cae3fb3df13@github.com> References: <8xwsTix84l48SqTssnCpU7XBD2IasVdqIJnntlNvr3U=.e9b83bf8-ff74-4ad4-a4f6-4cae3fb3df13@github.com> Message-ID: On Wed, 13 Apr 2022 15:55:52 GMT, Johannes Bechberger wrote: >> Move the AsyncGetCallTrace method implementation into a separate method and wrap its call in non-assert compilation mode in `os::ThreadCrashProtection` like it is done in [JFR](https://github.com/openjdk/jdk/blob/965ea8d9cd29aee41ba2b1b0b0c67bb67eca22dd/src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp#L165). >> This prevents AsyncGetCallTrace from crashing on segmentation faults (but not on `guarantee`s). >> >> If a crash is observed, then the `num_frames` field of the trace is set to `ticks_unknown_state` (-7) to signal a state that cannot be properly handled. `ticks_unknown_state` is currently also used for signaling unknown thread states but this should not be a problem, as the semantic is the same. If `num_frames` already has an error code then this error code is not changed. This helps to distinguish between errors in walking threads in Java and non-Java mode, as `num_frames` is set there before the walking to the appropriate error code. >> >> _Thanks for @tstuefe for suggesting this._ > > Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: > > Remove JFR assert from ThreadCrashProtection > > Remove the Thread::is_JfrSampler_thread() method too, > as it has only be used by the removed asserts The JFR code has the product vs debug split in order to capture - debug and fix - the issues in stack walking that we protect for in product builds. ------------- PR: https://git.openjdk.java.net/jdk/pull/8225 From duke at openjdk.java.net Wed Apr 13 16:57:16 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Wed, 13 Apr 2022 16:57:16 GMT Subject: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing [v4] In-Reply-To: <8xwsTix84l48SqTssnCpU7XBD2IasVdqIJnntlNvr3U=.e9b83bf8-ff74-4ad4-a4f6-4cae3fb3df13@github.com> References: <8xwsTix84l48SqTssnCpU7XBD2IasVdqIJnntlNvr3U=.e9b83bf8-ff74-4ad4-a4f6-4cae3fb3df13@github.com> Message-ID: On Wed, 13 Apr 2022 15:55:52 GMT, Johannes Bechberger wrote: >> Move the AsyncGetCallTrace method implementation into a separate method and wrap its call in non-assert compilation mode in `os::ThreadCrashProtection` like it is done in [JFR](https://github.com/openjdk/jdk/blob/965ea8d9cd29aee41ba2b1b0b0c67bb67eca22dd/src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp#L165). >> This prevents AsyncGetCallTrace from crashing on segmentation faults (but not on `guarantee`s). >> >> If a crash is observed, then the `num_frames` field of the trace is set to `ticks_unknown_state` (-7) to signal a state that cannot be properly handled. `ticks_unknown_state` is currently also used for signaling unknown thread states but this should not be a problem, as the semantic is the same. If `num_frames` already has an error code then this error code is not changed. This helps to distinguish between errors in walking threads in Java and non-Java mode, as `num_frames` is set there before the walking to the appropriate error code. >> >> _Thanks for @tstuefe for suggesting this._ > > Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: > > Remove JFR assert from ThreadCrashProtection > > Remove the Thread::is_JfrSampler_thread() method too, > as it has only be used by the removed asserts I would like to add an `-XX` option to disable the crash protection for testing. But I don't know how to do this. ------------- PR: https://git.openjdk.java.net/jdk/pull/8225 From aph at openjdk.java.net Wed Apr 13 17:47:56 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Wed, 13 Apr 2022 17:47:56 GMT Subject: RFR: 8282541: AArch64: Auto-vectorize Math.round API [v2] In-Reply-To: References: Message-ID: > Before, Apple M1: > > +-----------------------------------------+---------------------------------+ > |Benchmark | (TESTSIZE) Mode Score Units| > +-----------------------------------------+---------------------------------+ > |FpRoundingBenchmark.test_round_double | 1024 thrpt 1612.391 ops/ms| > |FpRoundingBenchmark.test_round_double | 2048 thrpt 804.291 ops/ms| > |FpRoundingBenchmark.test_round_float | 1024 thrpt 1558.202 ops/ms| > |FpRoundingBenchmark.test_round_float | 2048 thrpt 775.730 ops/ms| > +------------------------------------------+--------------------------------+ > > After: > > +-----------------------------------------+----------------------------------+ > |Benchmark | (TESTSIZE) Mode Score Units| > +-----------------------------------------+----------------------------------+ > |FpRoundingBenchmark.test_round_double | 1024 thrpt 2720.153 ops/ms| > |FpRoundingBenchmark.test_round_double | 2048 thrpt 1371.750 ops/ms| > |FpRoundingBenchmark.test_round_float | 1024 thrpt 5940.263 ops/ms| > |FpRoundingBenchmark.test_round_float | 2048 thrpt 3036.201 ops/ms| > +-----------------------------------------+----------------------------------+ > > About the algorithm: > > `Math.round()` is tricky. Its specification corresponds to no standard > rounding mode: it "returns the closest long to the argument, with ties > rounding to positive infinity." For positive inputs this is the same > as IEEE-754's `convertToIntegerTiesToAway` operation, which rounds > away from zero, but there's no equivalent for negative inputs. > > `Math.round()` used simply to add 0.5 and convert to integer by taking > the floor of the result, but that wasn't right because it suffers from > double rounding. This breaks several cases, in particular because > > `0.4999999... (+) 0.5 == 1.0` > > (Here, `(+)` indicates an addition followed by roundTiesToEven.) > > There is no corresponding problem with `-0.4999999...` or `-0.9999999...` > > Also, in the 32-bit `float` case, > > `8388609 (+) 0.5 == 8388610` > > because 8388609 (0x1.000002p+23) as a 32-bit integer has no fraction > bits, so adding 0.5, followed by roundTiesToEven, rounds upwards. This > problem manifests for every odd integer within the binade from > 0x1.000002p+23 to 0x1.fffffep+23, whether positive or negative. There > is a corresponding problem for the `double` range. > > The patch for JDK-8279508 handles this by flipping the floating-point > rounding mode to roundTowardNegative, adding 0.5, and taking the > floor. While this does work on AArch64, the performance is > tragic. AArch64 implementations seem to wait for all instructions in > flight to retire, change the rounding mode, and do the operation. This > effectively serializes the entire thread. > > This patch takes a different approach. Firstly, we can observe that we > can use the `frinta` instruction for the entire positive range. The > negative range is a bit trickier, but we can observe that any x, > abs{x) >= -0x1.000000p+23, has no fractional bits so it must be an > integer. For convenence, we can convert that range with the `frinta` > instruction as well. > > All that remains are x < 0, abs{x) < -0x1.000000p+23. Adding 0.5 > followed by roundTiesToEven doesn't lead to a problem because for > x < 0 && abs{x) >= 0.5, adding 0.5 only reduces the magnitude of x; > for all x < 0 && abs{x) < 0.5, adding 0.5 followed by roundTiesToEven > return 0. Andrew Haley has updated the pull request incrementally with two additional commits since the last revision: - Merge branch 'JDK-8282541' of https://github.com/theRealAph/jdk into JDK-8282541 - Windows! ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8204/files - new: https://git.openjdk.java.net/jdk/pull/8204/files/11b0eae2..1a43443a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8204&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8204&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8204.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8204/head:pull/8204 PR: https://git.openjdk.java.net/jdk/pull/8204 From aph at openjdk.java.net Wed Apr 13 17:47:57 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Wed, 13 Apr 2022 17:47:57 GMT Subject: RFR: 8282541: AArch64: Auto-vectorize Math.round API [v2] In-Reply-To: References: Message-ID: On Wed, 13 Apr 2022 10:10:23 GMT, Nick Gasson wrote: >> Andrew Haley has updated the pull request incrementally with two additional commits since the last revision: >> >> - Merge branch 'JDK-8282541' of https://github.com/theRealAph/jdk into JDK-8282541 >> - Windows! > > src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5198: > >> 5196: fcvtasd(dst, src); >> 5197: // Test if src >= 0 || abs(src) >= 0x1.0p52 >> 5198: eor(rscratch1, rscratch1, 1ul << 63); // flip sign bit > > This doesn't compile on Windows AArch64: > > > d:\a\jdk\jdk\jdk\src\hotspot\cpu\aarch64\macroAssembler_aarch64.cpp(5198): error C2220: the following warning is treated as an error > d:\a\jdk\jdk\jdk\src\hotspot\cpu\aarch64\macroAssembler_aarch64.cpp(5198): warning C4293: '<<': shift count negative or too big, undefined behavior > > > Windows is LLP64 isn't it? So you probably want 1ull or `UCONST64(1)` here. Done. ------------- PR: https://git.openjdk.java.net/jdk/pull/8204 From aturbanov at openjdk.java.net Wed Apr 13 20:45:35 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Wed, 13 Apr 2022 20:45:35 GMT Subject: RFR: 8284853: Fix varios 'expected' typo Message-ID: <32dmK9fPqvYhxpZmTgVYMYCfJNLZ3bI8ROg9UqUIRHc=.25e61d1a-6f26-4ea4-b5d3-3c6a80ce08dd@github.com> Found various typos of expected: `exepected`, `exept`, `epectedly`, `expeced`, `Unexpeted`, etc. ------------- Commit messages: - [PATCH] Fix 'expected' typo - [PATCH] Fix 'expected' typo - [PATCH] Fix 'expected' typo Changes: https://git.openjdk.java.net/jdk/pull/8231/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8231&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8284853 Stats: 65 lines in 28 files changed: 0 ins; 0 del; 65 mod Patch: https://git.openjdk.java.net/jdk/pull/8231.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8231/head:pull/8231 PR: https://git.openjdk.java.net/jdk/pull/8231 From kvn at openjdk.java.net Wed Apr 13 21:21:23 2022 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Wed, 13 Apr 2022 21:21:23 GMT Subject: RFR: 8284578: Relax InterpreterCodelet stub alignment [v2] In-Reply-To: References: Message-ID: On Wed, 13 Apr 2022 09:15:14 GMT, Aleksey Shipilev wrote: >> `InterpreterCodelet` is aligned by `CodeEntryAlignment` (`CAE`) twice. First, the entire stub is aligned, which aligns its data section. Then, the code section in the stub is aligned. Since `CAE` is usually larger than the size of `InterpreterCodelet`, we are wasting quite a bit of space for each codelet. In the extreme cases, like PPC that defaults to `CAE=128`, we have 16 bytes of codelet data effectively taking 128 bytes! >> >> This can be made better by relaxing the `InterpreterCodelet` stub alignment to `HeapWordSize`, while leaving its code section alignment the same. >> >> This tangentially touches the only other user for `StubQueue`: `ICStub`. Unfortunately, we cannot do the same kind of relaxation there, because there is a reverse lookup function that needs to reach data section from the code section, which forces us to keep the same alignment for both. >> >> Interpreter sizes on Linux x86_64 release: >> >> >> # Baseline, CEA=32 (default) >> code size = 94K bytes >> avg codelet size = 356 bytes >> >> # Baseline, CEA=128 (PPC-like) >> code size = 133K bytes >> avg codelet size = 501 bytes >> >> # Patched, CEA=32 (default) >> code size = 89K bytes >> avg codelet size = 338 bytes >> >> # Patched, CEA=128 (PPC-like) >> code size = 100K bytes >> avg codelet size = 380 bytes >> >> >> Point performance runs (SPECjvm2008:serial with `-Xint` on Linux x86_64 release): >> >> >> Benchmark Mode Cnt Score Error Units >> >> # Baseline, CEA=32 >> Serial.test thrpt 9 73.427 ? 0.152 ops/s >> >> # Baseline, CEA=128 >> Serial.test thrpt 9 70.999 ? 0.246 ops/s >> >> # Patched, CEA=32 >> Serial.test thrpt 9 73.991 ? 0.860 ops/s >> >> # Patched, CEA=128 >> Serial.test thrpt 9 72.981 ? 0.301 ops/s >> >> >> Additional testing: >> - [x] Linux x86_64 fastdebug `tier1` >> - [x] Linux x86_64 fastdebug `tier2` >> - [x] Linux x86_64 fastdebug `tier3` > > 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: > > - Relax slack space a bit > - Merge branch 'master' into JDK-8284578-intcodelet-align > - Initial implementation Testing passed. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8159 From mcimadamore at openjdk.java.net Wed Apr 13 21:30:17 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 13 Apr 2022 21:30:17 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v27] In-Reply-To: References: Message-ID: On Wed, 13 Apr 2022 16:12:31 GMT, Alan Bateman wrote: >> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: >> >> Add @ForceInline annotation on session accessor >> Beef up UnrolledAccess benchmark > > src/java.base/share/classes/java/nio/channels/FileChannel.java line 1052: > >> 1050: public MemorySegment map(MapMode mode, long offset, long size, >> 1051: MemorySession session) >> 1052: throws IOException, UnsupportedOperationException > > Just a minor here is that UOE is a runtime exception so probably shouldn't be in the throws. whoops - good catch - will fix! ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From mcimadamore at openjdk.java.net Wed Apr 13 21:35:07 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 13 Apr 2022 21:35:07 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v28] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/424 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Drop `UnsupportedOperationException` from throws clause in FileChannel/FileChannelImpl ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7888/files - new: https://git.openjdk.java.net/jdk/pull/7888/files/66cebe77..3a87df5e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=27 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=26-27 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7888.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888 PR: https://git.openjdk.java.net/jdk/pull/7888 From mcimadamore at openjdk.java.net Wed Apr 13 21:36:58 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 13 Apr 2022 21:36:58 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v29] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/424 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Remove whitespaces ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7888/files - new: https://git.openjdk.java.net/jdk/pull/7888/files/3a87df5e..8637379e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=28 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=27-28 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7888.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888 PR: https://git.openjdk.java.net/jdk/pull/7888 From bpb at openjdk.java.net Wed Apr 13 22:15:15 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 13 Apr 2022 22:15:15 GMT Subject: RFR: 8284853: Fix varios 'expected' typo In-Reply-To: <32dmK9fPqvYhxpZmTgVYMYCfJNLZ3bI8ROg9UqUIRHc=.25e61d1a-6f26-4ea4-b5d3-3c6a80ce08dd@github.com> References: <32dmK9fPqvYhxpZmTgVYMYCfJNLZ3bI8ROg9UqUIRHc=.25e61d1a-6f26-4ea4-b5d3-3c6a80ce08dd@github.com> Message-ID: On Wed, 13 Apr 2022 20:36:48 GMT, Andrey Turbanov wrote: > Found various typos of expected: `exepected`, `exept`, `epectedly`, `expeced`, `Unexpeted`, etc. Expect the Unexpeted. ------------- Marked as reviewed by bpb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8231 From cjplummer at openjdk.java.net Wed Apr 13 22:45:18 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Wed, 13 Apr 2022 22:45:18 GMT Subject: RFR: 8284853: Fix varios 'expected' typo In-Reply-To: <32dmK9fPqvYhxpZmTgVYMYCfJNLZ3bI8ROg9UqUIRHc=.25e61d1a-6f26-4ea4-b5d3-3c6a80ce08dd@github.com> References: <32dmK9fPqvYhxpZmTgVYMYCfJNLZ3bI8ROg9UqUIRHc=.25e61d1a-6f26-4ea4-b5d3-3c6a80ce08dd@github.com> Message-ID: On Wed, 13 Apr 2022 20:36:48 GMT, Andrey Turbanov wrote: > Found various typos of expected: `exepected`, `exept`, `epectedly`, `expeced`, `Unexpeted`, etc. test/jdk/java/lang/StackWalker/StackStreamTest.java line 218: > 216: private static void equalsOrThrow(String label, List list, List expected) { > 217: System.out.println("List: " + list); > 218: System.out.println("Expected: " + list); I think there is a per-existing bug here. Shouldn't the second println print `expected` instead of `list`? ------------- PR: https://git.openjdk.java.net/jdk/pull/8231 From dlong at openjdk.java.net Thu Apr 14 01:04:08 2022 From: dlong at openjdk.java.net (Dean Long) Date: Thu, 14 Apr 2022 01:04:08 GMT Subject: RFR: 8284578: Relax InterpreterCodelet stub alignment [v2] In-Reply-To: References: Message-ID: On Wed, 13 Apr 2022 09:15:14 GMT, Aleksey Shipilev wrote: >> `InterpreterCodelet` is aligned by `CodeEntryAlignment` (`CAE`) twice. First, the entire stub is aligned, which aligns its data section. Then, the code section in the stub is aligned. Since `CAE` is usually larger than the size of `InterpreterCodelet`, we are wasting quite a bit of space for each codelet. In the extreme cases, like PPC that defaults to `CAE=128`, we have 16 bytes of codelet data effectively taking 128 bytes! >> >> This can be made better by relaxing the `InterpreterCodelet` stub alignment to `HeapWordSize`, while leaving its code section alignment the same. >> >> This tangentially touches the only other user for `StubQueue`: `ICStub`. Unfortunately, we cannot do the same kind of relaxation there, because there is a reverse lookup function that needs to reach data section from the code section, which forces us to keep the same alignment for both. >> >> Interpreter sizes on Linux x86_64 release: >> >> >> # Baseline, CEA=32 (default) >> code size = 94K bytes >> avg codelet size = 356 bytes >> >> # Baseline, CEA=128 (PPC-like) >> code size = 133K bytes >> avg codelet size = 501 bytes >> >> # Patched, CEA=32 (default) >> code size = 89K bytes >> avg codelet size = 338 bytes >> >> # Patched, CEA=128 (PPC-like) >> code size = 100K bytes >> avg codelet size = 380 bytes >> >> >> Point performance runs (SPECjvm2008:serial with `-Xint` on Linux x86_64 release): >> >> >> Benchmark Mode Cnt Score Error Units >> >> # Baseline, CEA=32 >> Serial.test thrpt 9 73.427 ? 0.152 ops/s >> >> # Baseline, CEA=128 >> Serial.test thrpt 9 70.999 ? 0.246 ops/s >> >> # Patched, CEA=32 >> Serial.test thrpt 9 73.991 ? 0.860 ops/s >> >> # Patched, CEA=128 >> Serial.test thrpt 9 72.981 ? 0.301 ops/s >> >> >> Additional testing: >> - [x] Linux x86_64 fastdebug `tier1` >> - [x] Linux x86_64 fastdebug `tier2` >> - [x] Linux x86_64 fastdebug `tier3` > > 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: > > - Relax slack space a bit > - Merge branch 'master' into JDK-8284578-intcodelet-align > - Initial implementation Looks good. ------------- Marked as reviewed by dlong (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8159 From duke at openjdk.java.net Thu Apr 14 06:16:04 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Thu, 14 Apr 2022 06:16:04 GMT Subject: RFR: 8282477: [x86, aarch64] vmassert(_last_Java_pc == NULL, "already walkable"); fails with async profiler [v2] In-Reply-To: References: Message-ID: On Wed, 13 Apr 2022 06:42:56 GMT, Johannes Bechberger wrote: >> Fix the assertion by replacing it by assertion that does not fail. > > Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: > > Do not alter JFA in sender_for_entry Our nightly tests seem to be fine with this change. ------------- PR: https://git.openjdk.java.net/jdk/pull/8209 From jbachorik at openjdk.java.net Thu Apr 14 06:17:04 2022 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Thu, 14 Apr 2022 06:17:04 GMT Subject: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing [v4] In-Reply-To: <8xwsTix84l48SqTssnCpU7XBD2IasVdqIJnntlNvr3U=.e9b83bf8-ff74-4ad4-a4f6-4cae3fb3df13@github.com> References: <8xwsTix84l48SqTssnCpU7XBD2IasVdqIJnntlNvr3U=.e9b83bf8-ff74-4ad4-a4f6-4cae3fb3df13@github.com> Message-ID: On Wed, 13 Apr 2022 15:55:52 GMT, Johannes Bechberger wrote: >> Move the AsyncGetCallTrace method implementation into a separate method and wrap its call in non-assert compilation mode in `os::ThreadCrashProtection` like it is done in [JFR](https://github.com/openjdk/jdk/blob/965ea8d9cd29aee41ba2b1b0b0c67bb67eca22dd/src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp#L165). >> This prevents AsyncGetCallTrace from crashing on segmentation faults (but not on `guarantee`s). >> >> If a crash is observed, then the `num_frames` field of the trace is set to `ticks_unknown_state` (-7) to signal a state that cannot be properly handled. `ticks_unknown_state` is currently also used for signaling unknown thread states but this should not be a problem, as the semantic is the same. If `num_frames` already has an error code then this error code is not changed. This helps to distinguish between errors in walking threads in Java and non-Java mode, as `num_frames` is set there before the walking to the appropriate error code. >> >> _Thanks for @tstuefe for suggesting this._ > > Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: > > Remove JFR assert from ThreadCrashProtection > > Remove the Thread::is_JfrSampler_thread() method too, > as it has only be used by the removed asserts As for the `-XX` option - I think you can start from [globals.hpp](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/globals.hpp). ------------- PR: https://git.openjdk.java.net/jdk/pull/8225 From duke at openjdk.java.net Thu Apr 14 06:17:04 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Thu, 14 Apr 2022 06:17:04 GMT Subject: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing [v4] In-Reply-To: <8xwsTix84l48SqTssnCpU7XBD2IasVdqIJnntlNvr3U=.e9b83bf8-ff74-4ad4-a4f6-4cae3fb3df13@github.com> References: <8xwsTix84l48SqTssnCpU7XBD2IasVdqIJnntlNvr3U=.e9b83bf8-ff74-4ad4-a4f6-4cae3fb3df13@github.com> Message-ID: On Wed, 13 Apr 2022 15:55:52 GMT, Johannes Bechberger wrote: >> Move the AsyncGetCallTrace method implementation into a separate method and wrap its call in non-assert compilation mode in `os::ThreadCrashProtection` like it is done in [JFR](https://github.com/openjdk/jdk/blob/965ea8d9cd29aee41ba2b1b0b0c67bb67eca22dd/src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp#L165). >> This prevents AsyncGetCallTrace from crashing on segmentation faults (but not on `guarantee`s). >> >> If a crash is observed, then the `num_frames` field of the trace is set to `ticks_unknown_state` (-7) to signal a state that cannot be properly handled. `ticks_unknown_state` is currently also used for signaling unknown thread states but this should not be a problem, as the semantic is the same. If `num_frames` already has an error code then this error code is not changed. This helps to distinguish between errors in walking threads in Java and non-Java mode, as `num_frames` is set there before the walking to the appropriate error code. >> >> _Thanks for @tstuefe for suggesting this._ > > Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: > > Remove JFR assert from ThreadCrashProtection > > Remove the Thread::is_JfrSampler_thread() method too, > as it has only be used by the removed asserts and how I can I access it from the code deep down? ------------- PR: https://git.openjdk.java.net/jdk/pull/8225 From duke at openjdk.java.net Thu Apr 14 06:33:55 2022 From: duke at openjdk.java.net (KIRIYAMA Takuya) Date: Thu, 14 Apr 2022 06:33:55 GMT Subject: RFR: 8280761: UseCompressedOops should be set after limit_heap_by_allocatable_memory [v6] In-Reply-To: References: Message-ID: > I fixed to set UseCompressedOops flag after limit_heap_by_allocatable_memory(). > So when ulimit -v is called and -XX:MaxRAM is set, UseCompressedOops does not become false. > And all hotspot tier1 test are passed. > Would you please review this fix? KIRIYAMA Takuya has updated the pull request incrementally with one additional commit since the last revision: 8280761 UseCompressedOops should be set after limit_heap_by_allocatable_memory ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7938/files - new: https://git.openjdk.java.net/jdk/pull/7938/files/e2fe253f..65223a52 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7938&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7938&range=04-05 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7938.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7938/head:pull/7938 PR: https://git.openjdk.java.net/jdk/pull/7938 From duke at openjdk.java.net Thu Apr 14 06:33:56 2022 From: duke at openjdk.java.net (KIRIYAMA Takuya) Date: Thu, 14 Apr 2022 06:33:56 GMT Subject: RFR: 8280761: UseCompressedOops should be set after limit_heap_by_allocatable_memory [v5] In-Reply-To: References: Message-ID: On Wed, 13 Apr 2022 10:47:12 GMT, Albert Mingkun Yang wrote: > Need sth like this to resolve the failure. I'm sorry. This is my mistake. I added your code. ------------- PR: https://git.openjdk.java.net/jdk/pull/7938 From jbachorik at openjdk.java.net Thu Apr 14 06:54:15 2022 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Thu, 14 Apr 2022 06:54:15 GMT Subject: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing [v4] In-Reply-To: <8xwsTix84l48SqTssnCpU7XBD2IasVdqIJnntlNvr3U=.e9b83bf8-ff74-4ad4-a4f6-4cae3fb3df13@github.com> References: <8xwsTix84l48SqTssnCpU7XBD2IasVdqIJnntlNvr3U=.e9b83bf8-ff74-4ad4-a4f6-4cae3fb3df13@github.com> Message-ID: <0kBSFmTMFv0M-bnpTMtjnSccc2FChAW4vZ9XwwKq1Ro=.ac14378a-ffbe-4efd-bd57-cbe84a6c581f@github.com> On Wed, 13 Apr 2022 15:55:52 GMT, Johannes Bechberger wrote: >> Move the AsyncGetCallTrace method implementation into a separate method and wrap its call in non-assert compilation mode in `os::ThreadCrashProtection` like it is done in [JFR](https://github.com/openjdk/jdk/blob/965ea8d9cd29aee41ba2b1b0b0c67bb67eca22dd/src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp#L165). >> This prevents AsyncGetCallTrace from crashing on segmentation faults (but not on `guarantee`s). >> >> If a crash is observed, then the `num_frames` field of the trace is set to `ticks_unknown_state` (-7) to signal a state that cannot be properly handled. `ticks_unknown_state` is currently also used for signaling unknown thread states but this should not be a problem, as the semantic is the same. If `num_frames` already has an error code then this error code is not changed. This helps to distinguish between errors in walking threads in Java and non-Java mode, as `num_frames` is set there before the walking to the appropriate error code. >> >> _Thanks for @tstuefe for suggesting this._ > > Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: > > Remove JFR assert from ThreadCrashProtection > > Remove the Thread::is_JfrSampler_thread() method too, > as it has only be used by the removed asserts Should be as easy as eg. https://github.com/openjdk/jdk/blob/bf85b0095ff3ad8775501bd65e7ccf9103ecc15f/src/hotspot/share/runtime/os.cpp#L463 - where `ReduceSignalUsage` is defined as https://github.com/openjdk/jdk/blob/bf85b0095ff3ad8775501bd65e7ccf9103ecc15f/src/hotspot/share/runtime/globals.hpp#L722 ------------- PR: https://git.openjdk.java.net/jdk/pull/8225 From shade at openjdk.java.net Thu Apr 14 07:33:12 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 14 Apr 2022 07:33:12 GMT Subject: RFR: 8284578: Relax InterpreterCodelet stub alignment [v2] In-Reply-To: References: Message-ID: On Wed, 13 Apr 2022 09:15:14 GMT, Aleksey Shipilev wrote: >> `InterpreterCodelet` is aligned by `CodeEntryAlignment` (`CAE`) twice. First, the entire stub is aligned, which aligns its data section. Then, the code section in the stub is aligned. Since `CAE` is usually larger than the size of `InterpreterCodelet`, we are wasting quite a bit of space for each codelet. In the extreme cases, like PPC that defaults to `CAE=128`, we have 16 bytes of codelet data effectively taking 128 bytes! >> >> This can be made better by relaxing the `InterpreterCodelet` stub alignment to `HeapWordSize`, while leaving its code section alignment the same. >> >> This tangentially touches the only other user for `StubQueue`: `ICStub`. Unfortunately, we cannot do the same kind of relaxation there, because there is a reverse lookup function that needs to reach data section from the code section, which forces us to keep the same alignment for both. >> >> Interpreter sizes on Linux x86_64 release: >> >> >> # Baseline, CEA=32 (default) >> code size = 94K bytes >> avg codelet size = 356 bytes >> >> # Baseline, CEA=128 (PPC-like) >> code size = 133K bytes >> avg codelet size = 501 bytes >> >> # Patched, CEA=32 (default) >> code size = 89K bytes >> avg codelet size = 338 bytes >> >> # Patched, CEA=128 (PPC-like) >> code size = 100K bytes >> avg codelet size = 380 bytes >> >> >> Point performance runs (SPECjvm2008:serial with `-Xint` on Linux x86_64 release): >> >> >> Benchmark Mode Cnt Score Error Units >> >> # Baseline, CEA=32 >> Serial.test thrpt 9 73.427 ? 0.152 ops/s >> >> # Baseline, CEA=128 >> Serial.test thrpt 9 70.999 ? 0.246 ops/s >> >> # Patched, CEA=32 >> Serial.test thrpt 9 73.991 ? 0.860 ops/s >> >> # Patched, CEA=128 >> Serial.test thrpt 9 72.981 ? 0.301 ops/s >> >> >> Additional testing: >> - [x] Linux x86_64 fastdebug `tier1` >> - [x] Linux x86_64 fastdebug `tier2` >> - [x] Linux x86_64 fastdebug `tier3` > > 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: > > - Relax slack space a bit > - Merge branch 'master' into JDK-8284578-intcodelet-align > - Initial implementation Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/8159 From shade at openjdk.java.net Thu Apr 14 07:33:12 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 14 Apr 2022 07:33:12 GMT Subject: Integrated: 8284578: Relax InterpreterCodelet stub alignment In-Reply-To: References: Message-ID: <8E_OXhN0AHy2hS_oHPiLfNrgs8sdmw6VY9zXamw0Nx4=.0c25439a-40aa-47dc-a02c-915f6551bfb2@github.com> On Fri, 8 Apr 2022 11:45:13 GMT, Aleksey Shipilev wrote: > `InterpreterCodelet` is aligned by `CodeEntryAlignment` (`CAE`) twice. First, the entire stub is aligned, which aligns its data section. Then, the code section in the stub is aligned. Since `CAE` is usually larger than the size of `InterpreterCodelet`, we are wasting quite a bit of space for each codelet. In the extreme cases, like PPC that defaults to `CAE=128`, we have 16 bytes of codelet data effectively taking 128 bytes! > > This can be made better by relaxing the `InterpreterCodelet` stub alignment to `HeapWordSize`, while leaving its code section alignment the same. > > This tangentially touches the only other user for `StubQueue`: `ICStub`. Unfortunately, we cannot do the same kind of relaxation there, because there is a reverse lookup function that needs to reach data section from the code section, which forces us to keep the same alignment for both. > > Interpreter sizes on Linux x86_64 release: > > > # Baseline, CEA=32 (default) > code size = 94K bytes > avg codelet size = 356 bytes > > # Baseline, CEA=128 (PPC-like) > code size = 133K bytes > avg codelet size = 501 bytes > > # Patched, CEA=32 (default) > code size = 89K bytes > avg codelet size = 338 bytes > > # Patched, CEA=128 (PPC-like) > code size = 100K bytes > avg codelet size = 380 bytes > > > Point performance runs (SPECjvm2008:serial with `-Xint` on Linux x86_64 release): > > > Benchmark Mode Cnt Score Error Units > > # Baseline, CEA=32 > Serial.test thrpt 9 73.427 ? 0.152 ops/s > > # Baseline, CEA=128 > Serial.test thrpt 9 70.999 ? 0.246 ops/s > > # Patched, CEA=32 > Serial.test thrpt 9 73.991 ? 0.860 ops/s > > # Patched, CEA=128 > Serial.test thrpt 9 72.981 ? 0.301 ops/s > > > Additional testing: > - [x] Linux x86_64 fastdebug `tier1` > - [x] Linux x86_64 fastdebug `tier2` > - [x] Linux x86_64 fastdebug `tier3` This pull request has now been integrated. Changeset: 2241a057 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/2241a057050ed521cfbfbe8a758353e621dee15f Stats: 46 lines in 5 files changed: 16 ins; 5 del; 25 mod 8284578: Relax InterpreterCodelet stub alignment Reviewed-by: kvn, dlong ------------- PR: https://git.openjdk.java.net/jdk/pull/8159 From shade at openjdk.java.net Thu Apr 14 09:15:07 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 14 Apr 2022 09:15:07 GMT Subject: RFR: 8284584: Avoid duplicate node_idx_t definitions [v2] In-Reply-To: References: Message-ID: On Wed, 13 Apr 2022 09:57:01 GMT, Aleksey Shipilev wrote: >> While looking at `Node`, I realized there are two definitions for node_idx_t, another one added by [JDK-8076284](https://bugs.openjdk.java.net/browse/JDK-8076284). These should be de-duplicated to avoid confusion. > > 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: > > - Leave one definition in compile.hpp only > - Merge branch 'master' into JDK-8284584-node-idx-duplicate > - Move Thank you! Simple/trivial, or do I need another reviewer? ------------- PR: https://git.openjdk.java.net/jdk/pull/8164 From aturbanov at openjdk.java.net Thu Apr 14 09:28:17 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Thu, 14 Apr 2022 09:28:17 GMT Subject: RFR: 8284853: Fix various 'expected' typo [v2] In-Reply-To: <32dmK9fPqvYhxpZmTgVYMYCfJNLZ3bI8ROg9UqUIRHc=.25e61d1a-6f26-4ea4-b5d3-3c6a80ce08dd@github.com> References: <32dmK9fPqvYhxpZmTgVYMYCfJNLZ3bI8ROg9UqUIRHc=.25e61d1a-6f26-4ea4-b5d3-3c6a80ce08dd@github.com> Message-ID: > Found various typos of expected: `exepected`, `exept`, `epectedly`, `expeced`, `Unexpeted`, etc. Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: 8284853: Fix various 'expected' typo improve test log ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8231/files - new: https://git.openjdk.java.net/jdk/pull/8231/files/fe6d9890..9fc75e89 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8231&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8231&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8231.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8231/head:pull/8231 PR: https://git.openjdk.java.net/jdk/pull/8231 From rkennke at openjdk.java.net Thu Apr 14 09:37:14 2022 From: rkennke at openjdk.java.net (Roman Kennke) Date: Thu, 14 Apr 2022 09:37:14 GMT Subject: RFR: 8284816: Make markWord::has_monitor() more robust In-Reply-To: References: Message-ID: On Wed, 13 Apr 2022 15:16:12 GMT, Daniel D. Daugherty wrote: > I agree that the new code is more precise. > > Thumbs up. Thank you all! ------------- PR: https://git.openjdk.java.net/jdk/pull/8219 From rkennke at openjdk.java.net Thu Apr 14 09:37:15 2022 From: rkennke at openjdk.java.net (Roman Kennke) Date: Thu, 14 Apr 2022 09:37:15 GMT Subject: Integrated: 8284816: Make markWord::has_monitor() more robust In-Reply-To: References: Message-ID: On Wed, 13 Apr 2022 09:59:49 GMT, Roman Kennke wrote: > Currently, markWord::has_monitor() is implemented like this: > > ` return ((value() & monitor_value) != 0);` > > monitor value is `0b10`. This means that it also reports marked or forwarded objects (`0b11`) as having a monitor, which is wrong. As far as I can tell, it does not cause any problems because relevant code is either not affected by marked/forwarded objects, or by testing bits in an order that hides the problem. > > I suggest to test the bits properly to make it more robust and avoid potenial future bugs. > > Testing: > - [x] tier1 > - [ ] tier2 > - [ ] tier3 This pull request has now been integrated. Changeset: 339005db Author: Roman Kennke URL: https://git.openjdk.java.net/jdk/commit/339005dbc99e94ed094612c7b34eb0c93ca1f8c1 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8284816: Make markWord::has_monitor() more robust Reviewed-by: stuefe, zgu, dcubed ------------- PR: https://git.openjdk.java.net/jdk/pull/8219 From lucy at openjdk.java.net Thu Apr 14 10:00:20 2022 From: lucy at openjdk.java.net (Lutz Schmidt) Date: Thu, 14 Apr 2022 10:00:20 GMT Subject: RFR: JDK-8283326: Implement SafeFetch statically [v6] In-Reply-To: References: Message-ID: On Wed, 13 Apr 2022 09:22:45 GMT, Thomas Stuefe wrote: >> Hi, >> >> This is a reimplementation of SafeFetch to get rid of dynamic code generation. This is done, depending on platform, via static assembly, Posix setjmp/longjmp or SEH. >> >> This is based on a proposal by @theRealAph [1] when discussing [JDK-8282475](https://bugs.openjdk.java.net/browse/JDK-8282475). I extended the proposal to do this for all platforms, not just MacOS, see discussion below. >> >> --- >> >> Why we do this: >> >> SafeFetch is special: it is a basic utility function that may be called before the VM is properly initialized, from a "foreign" thread not attached to the VM, in a broken environment... mainly this is due to its use during stack walking, error reporting, hex dumping, etc. SafeFetch has to be safe to call under any circumstances - or as safe as we can make it. >> >> Today, SafeFetch is implemented via stub routines. That causes problems: >> >> - MacOs aarch64 has mechanisms to prevent execution of arbitrary non-text memory. On that platform, invoking generated code requires some awkward gymnastics [2]. These workarounds require access to Thread::current, which renders SafeFetch non-functional if Thread::current is NULL (e.g. crash reporting in "foreign" native threads or in a corrupted VM). They also cost a bit of performance on every SafeFetch invocation. Note that more OSes may implement similar execution prevention mechanics in the future. >> >> - There is a time window during VM initialization where the stubs are not generated yet and thus SafeFetch is not available. >> >> Both points cause hs-err files to be compromised (e.g. missing call stacks) for crashes in native threads, when the VM is corrupted, or early during VM initialization. Since SafeFetch is such a basic tool, it causes more issues than that (e.g., on AIX it is used for verifying mprotect() itself). But hs-err files being compromised by secondary errors is the most annoying effect. >> >> A minor point is that generating stubs takes a tiny bit of startup time. Not a big issue, but anything we can generate at build time instead of at runtime is good. >> >> --- >> >> The patch: >> >> - Removes the SafeFetch stub routine generation for all platforms >> - For Linux and MacOS, it implements SafeFetch as cpu-specific static assembler routines. These routines live in `os_cpu/_/safefetch__.S`. >> - On Windows, SafeFetch is implemented via SEH. This is beautifully simple and does not need handwritten assembly at all. See `os/windows/safefetch_windows.hpp`. >> - On Zero, SafeFetch uses a Posix compatible solution using `sigsetjmp(2)`. This is portable and robust, but a bit slow compared to the other methods. Note that this solution existed before, and is well tested. I just moved the code around and massaged it a bit. >> - AIX uses now the same method as Zero. AIX "downgraded" in that sense from the stub routine solution, but since SAP gave up maintenance of AIX, I don't have easy access to AIX hardware. If SafeFetch speed becomes an issue, I am sure a solution based on static assembly can be implemented on AIX too. >> - The SafeFetch gtests were greatly expanded. >> >> Tests: >> >> - The patch was tested manually by building and running gtests on: >> - MacOS (x64, aarch64) >> - Linux (aarch64, arm, ppcle, s390, x64, x86, riscv) >> - Windows (x64 and x86, but not arm, see below) >> - AIX >> - Zero (on Linux x64). >> - GHAs >> - The patch ran through SAP nightlies for several nights in a row >> >> Note: >> - I have no access to Windows arm, so I could not test it. I contacted @mo-beck to verify that the patch works there. >> - I have no access to BSD. I am not sure who maintains BSD, so I have no idea who to contact. However, I believe the MacOS solution should work for BSD too. If not, BSD can simply fall back to the Posix sigjmp solution like AIX and Zero. >> >> It would be nice to have @RealLucy, @TheRealMDoerr and @theRealAph to okay s390, ppcle and aarch64 (and possibly arm32). Each assembly file is tiny, so it should not take long. @RealFYang and @backwaterred already tested the patch on RiscV and AIX (thanks). >> >> Thanks, Thomas >> >> [1] https://github.com/openjdk/jdk/pull/7727#issuecomment-1064980598 >> [2] https://github.com/openjdk/jdk/blob/4df67426ed02f18af0757897acb28b636a317a91/src/hotspot/share/runtime/safefetch.inline.hpp#L37-L41 > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > re-add lost comment Changes look good to me. ------------- Marked as reviewed by lucy (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7865 From stuefe at openjdk.java.net Thu Apr 14 10:00:20 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 14 Apr 2022 10:00:20 GMT Subject: RFR: JDK-8283326: Implement SafeFetch statically [v6] In-Reply-To: References: Message-ID: <9_ZGeocsZJ0dAPUtMjyhp5PZpjKx_fWJQ-G69Lf9LEU=.19e6f9d2-c8cc-4939-90be-dcdcdc681c21@github.com> On Thu, 14 Apr 2022 09:54:10 GMT, Lutz Schmidt wrote: > Changes look good to me. Thanks @RealLucy! Nice to have s390 expert approval :) ------------- PR: https://git.openjdk.java.net/jdk/pull/7865 From luhenry at openjdk.java.net Thu Apr 14 10:20:11 2022 From: luhenry at openjdk.java.net (Ludovic Henry) Date: Thu, 14 Apr 2022 10:20:11 GMT Subject: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing [v4] In-Reply-To: <8xwsTix84l48SqTssnCpU7XBD2IasVdqIJnntlNvr3U=.e9b83bf8-ff74-4ad4-a4f6-4cae3fb3df13@github.com> References: <8xwsTix84l48SqTssnCpU7XBD2IasVdqIJnntlNvr3U=.e9b83bf8-ff74-4ad4-a4f6-4cae3fb3df13@github.com> Message-ID: On Wed, 13 Apr 2022 15:55:52 GMT, Johannes Bechberger wrote: >> Move the AsyncGetCallTrace method implementation into a separate method and wrap its call in non-assert compilation mode in `os::ThreadCrashProtection` like it is done in [JFR](https://github.com/openjdk/jdk/blob/965ea8d9cd29aee41ba2b1b0b0c67bb67eca22dd/src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp#L165). >> This prevents AsyncGetCallTrace from crashing on segmentation faults (but not on `guarantee`s). >> >> If a crash is observed, then the `num_frames` field of the trace is set to `ticks_unknown_state` (-7) to signal a state that cannot be properly handled. `ticks_unknown_state` is currently also used for signaling unknown thread states but this should not be a problem, as the semantic is the same. If `num_frames` already has an error code then this error code is not changed. This helps to distinguish between errors in walking threads in Java and non-Java mode, as `num_frames` is set there before the walking to the appropriate error code. >> >> _Thanks for @tstuefe for suggesting this._ > > Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: > > Remove JFR assert from ThreadCrashProtection > > Remove the Thread::is_JfrSampler_thread() method too, > as it has only be used by the removed asserts At https://github.com/openjdk/jdk/blob/77a21cb5658961b20011b7125a1ed896622faa4d/src/hotspot/share/prims/forte.cpp#L461, you have a NoHandleMark which wouldn?t get cleaned up in case of crash. For other such cases, it could be worth having some form of assertion in StackObj destructor to make sure you don?t call it when you have a crash protection. That assert would trigger only in debug and even when there is no crash so it should help us root out such issue faster. ------------- PR: https://git.openjdk.java.net/jdk/pull/8225 From redestad at openjdk.java.net Thu Apr 14 10:34:15 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 14 Apr 2022 10:34:15 GMT Subject: RFR: 8284584: Avoid duplicate node_idx_t definitions [v2] In-Reply-To: References: Message-ID: On Wed, 13 Apr 2022 09:57:01 GMT, Aleksey Shipilev wrote: >> While looking at `Node`, I realized there are two definitions for node_idx_t, another one added by [JDK-8076284](https://bugs.openjdk.java.net/browse/JDK-8076284). These should be de-duplicated to avoid confusion. > > 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: > > - Leave one definition in compile.hpp only > - Merge branch 'master' into JDK-8284584-node-idx-duplicate > - Move Looks good and trivial ------------- Marked as reviewed by redestad (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8164 From yyang at openjdk.java.net Thu Apr 14 10:42:11 2022 From: yyang at openjdk.java.net (Yi Yang) Date: Thu, 14 Apr 2022 10:42:11 GMT Subject: RFR: 8284853: Fix various 'expected' typo [v2] In-Reply-To: References: <32dmK9fPqvYhxpZmTgVYMYCfJNLZ3bI8ROg9UqUIRHc=.25e61d1a-6f26-4ea4-b5d3-3c6a80ce08dd@github.com> Message-ID: On Thu, 14 Apr 2022 09:28:17 GMT, Andrey Turbanov wrote: >> Found various typos of expected: `exepected`, `exept`, `epectedly`, `expeced`, `Unexpeted`, etc. > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8284853: Fix various 'expected' typo > improve test log I found [yet another typo](https://github.com/kelthuzadx/jdk/commit/acb9e15bc0bf5395d1c0875f36992f692734f948), I wonder if you can merge this into your patch so that I do not need to submit a new PR for it? Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/8231 From stuefe at openjdk.java.net Thu Apr 14 11:11:17 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 14 Apr 2022 11:11:17 GMT Subject: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing [v4] In-Reply-To: References: <8xwsTix84l48SqTssnCpU7XBD2IasVdqIJnntlNvr3U=.e9b83bf8-ff74-4ad4-a4f6-4cae3fb3df13@github.com> Message-ID: On Thu, 14 Apr 2022 10:16:28 GMT, Ludovic Henry wrote: > At > > https://github.com/openjdk/jdk/blob/77a21cb5658961b20011b7125a1ed896622faa4d/src/hotspot/share/prims/forte.cpp#L461 > > , you have a NoHandleMark which wouldn?t get cleaned up in case of crash. > For other such cases, it could be worth having some form of assertion in StackObj destructor to make sure you don?t call it when you have a crash protection. That assert would trigger only in debug and even when there is no crash so it should help us root out such issue faster. Darn, @luhenry is right. And the more I think about this, the more doubts I get about this approach. We have only one other subsystem that does this kind of wholesale catching of error signals and then unwinding the stack (JFR) and presumably they fine-combed their coding and are sure exactly what they do under the sigjmp guard. Are we also certain? Because as long as we cannot guarantee that we really don't use RAII, or actually anything needing cleanup (e.g. dynamic memory allocation), and that we don't accidentally abandon a lock, we cannot use sigjmp. This precludes use of resource area, and had that not been an issue? We cannot even use malloc here. Under these circumstances, crashing may be better than not crashing, since not crashing could leave the thread in a corrupted state or in a deadlock. I think the safer approach, albeit much more work intensive, would be to make sure we do not crash. Starting with removing RA allocation. I tried to make RA signal safe with https://bugs.openjdk.java.net/browse/JDK-8282405, but that got totally stuck, so better just remove it altogether from AGCT. Over using SafeFetch or plain defensive coding to avoid crashing. Sorry for this. If I'm wrong, please someone correct me. This looked like a simple solution at first. ------------- PR: https://git.openjdk.java.net/jdk/pull/8225 From shade at openjdk.java.net Thu Apr 14 11:13:18 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 14 Apr 2022 11:13:18 GMT Subject: RFR: 8284584: Avoid duplicate node_idx_t definitions [v2] In-Reply-To: References: Message-ID: On Wed, 13 Apr 2022 09:57:01 GMT, Aleksey Shipilev wrote: >> While looking at `Node`, I realized there are two definitions for node_idx_t, another one added by [JDK-8076284](https://bugs.openjdk.java.net/browse/JDK-8076284). These should be de-duplicated to avoid confusion. > > 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: > > - Leave one definition in compile.hpp only > - Merge branch 'master' into JDK-8284584-node-idx-duplicate > - Move Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/8164 From shade at openjdk.java.net Thu Apr 14 11:16:18 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 14 Apr 2022 11:16:18 GMT Subject: Integrated: 8284584: Avoid duplicate node_idx_t definitions In-Reply-To: References: Message-ID: On Fri, 8 Apr 2022 13:25:16 GMT, Aleksey Shipilev wrote: > While looking at `Node`, I realized there are two definitions for node_idx_t, another one added by [JDK-8076284](https://bugs.openjdk.java.net/browse/JDK-8076284). These should be de-duplicated to avoid confusion. This pull request has now been integrated. Changeset: 9a00b432 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/9a00b432eab01918f99e7a37ba0cc832ef3a1a58 Stats: 11 lines in 2 files changed: 5 ins; 6 del; 0 mod 8284584: Avoid duplicate node_idx_t definitions Reviewed-by: kvn, redestad ------------- PR: https://git.openjdk.java.net/jdk/pull/8164 From duke at openjdk.java.net Thu Apr 14 11:33:15 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Thu, 14 Apr 2022 11:33:15 GMT Subject: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing [v4] In-Reply-To: References: <8xwsTix84l48SqTssnCpU7XBD2IasVdqIJnntlNvr3U=.e9b83bf8-ff74-4ad4-a4f6-4cae3fb3df13@github.com> Message-ID: On Thu, 14 Apr 2022 11:06:50 GMT, Thomas Stuefe wrote: > We have only one other subsystem that does this kind of wholesale catching of error signals and then unwinding the stack (JFR) and presumably they fine-combed their coding and are sure exactly what they do under the sigjmp guard. Are we also certain? They share almost all of their code. Allocating on the heap is not safe in the signal handler and should be considered an error. My goal is remove all code that (potentially) modifies the heap or the state of the VM from AsyncGetCallTrace, with the focus on the methods that are called from AsyncGetCallTrace but from JFR. Both are so similar that this practical. Regarding the `NoHandleMark`: I must have missed this. > I think the safer approach, albeit much more work intensive, would be to make sure we do not crash. Starting with removing RA allocation. I tried to make RA signal safe with https://bugs.openjdk.java.net/browse/JDK-8282405, but that got totally stuck, so better just remove it altogether from AGCT. Over using SafeFetch or plain defensive coding to avoid crashing. They are complementary goals. My goal is to improve ASGCT and its stability but this PR should help prevent rare segmentation faults to appear in production. ------------- PR: https://git.openjdk.java.net/jdk/pull/8225 From duke at openjdk.java.net Thu Apr 14 11:43:03 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Thu, 14 Apr 2022 11:43:03 GMT Subject: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing [v5] In-Reply-To: References: Message-ID: > Move the AsyncGetCallTrace method implementation into a separate method and wrap its call in non-assert compilation mode in `os::ThreadCrashProtection` like it is done in [JFR](https://github.com/openjdk/jdk/blob/965ea8d9cd29aee41ba2b1b0b0c67bb67eca22dd/src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp#L165). > This prevents AsyncGetCallTrace from crashing on segmentation faults (but not on `guarantee`s). > > If a crash is observed, then the `num_frames` field of the trace is set to `ticks_unknown_state` (-7) to signal a state that cannot be properly handled. `ticks_unknown_state` is currently also used for signaling unknown thread states but this should not be a problem, as the semantic is the same. If `num_frames` already has an error code then this error code is not changed. This helps to distinguish between errors in walking threads in Java and non-Java mode, as `num_frames` is set there before the walking to the appropriate error code. > > _Thanks for @tstuefe for suggesting this._ Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: Place NoHandleMark properly ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8225/files - new: https://git.openjdk.java.net/jdk/pull/8225/files/77a21cb5..8abf582c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8225&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8225&range=03-04 Stats: 3 lines in 1 file changed: 1 ins; 2 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8225.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8225/head:pull/8225 PR: https://git.openjdk.java.net/jdk/pull/8225 From jbachorik at openjdk.java.net Thu Apr 14 11:50:35 2022 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Thu, 14 Apr 2022 11:50:35 GMT Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee Message-ID: A gist of the fix is to allow relaxed instantiation of a frame when done from a signal handler - eg. for profiling purposes. Currently, a frame instantiation will fail on guarantee when we happen to hit a zombie method which is still on stack. While this would indicate a serious error for the normal execution flow, in case of profiling where the executing thread can be expected at any possible method this is something which may happen and we really should not take the profiled JVM down due to it. The behaviour defaults to checking the code blob status in the guarantee so nothing will change for the rest of the callers - just ASGCT will be affected.

Unfortunately, I am not able to create a simple reproducer for the crash other that testing in our production where the crash is happening sporadically. However, thanks to @parttimenerd and his [ASGCT stress test](https://github.com/parttimenerd/asgct2-tester.git) the problem can be reproduced quite reliably. ------------- Commit messages: - Add missing change for linux_arm - Remove unnecessary pc_from_sp() - Merge branch 'master' into jb/agct_crash_fix - Missing s390/linux fix part - Fix linux/s390 - One more rename - Rename parameter - Fix whitespace errors - 8283849: AsyncGetCallTrace may crash JVM Changes: https://git.openjdk.java.net/jdk/pull/8061/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8061&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283849 Stats: 214 lines in 35 files changed: 73 ins; 4 del; 137 mod Patch: https://git.openjdk.java.net/jdk/pull/8061.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8061/head:pull/8061 PR: https://git.openjdk.java.net/jdk/pull/8061 From mcimadamore at openjdk.java.net Thu Apr 14 12:01:30 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 14 Apr 2022 12:01:30 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v30] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/424 Maurizio Cimadamore has updated the pull request incrementally with four additional commits since the last revision: - Add ValueLayout changes - Tweak support for array element var handle - Add @see - Initial push ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7888/files - new: https://git.openjdk.java.net/jdk/pull/7888/files/8637379e..2e3d57a8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=29 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=28-29 Stats: 129 lines in 4 files changed: 97 ins; 25 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/7888.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888 PR: https://git.openjdk.java.net/jdk/pull/7888 From stuefe at openjdk.java.net Thu Apr 14 12:59:26 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 14 Apr 2022 12:59:26 GMT Subject: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing [v4] In-Reply-To: References: <8xwsTix84l48SqTssnCpU7XBD2IasVdqIJnntlNvr3U=.e9b83bf8-ff74-4ad4-a4f6-4cae3fb3df13@github.com> Message-ID: On Thu, 14 Apr 2022 11:30:13 GMT, Johannes Bechberger wrote: > > We have only one other subsystem that does this kind of wholesale catching of error signals and then unwinding the stack (JFR) and presumably they fine-combed their coding and are sure exactly what they do under the sigjmp guard. Are we also certain? > > They share almost all of their code. Allocating on the heap is not safe in the signal handler and should be considered an error. > > My goal is remove all code that (potentially) modifies the heap or the state of the VM from AsyncGetCallTrace, with the focus on the methods that are called from AsyncGetCallTrace but from JFR. Both are so similar that this practical. > > Regarding the `NoHandleMark`: I must have missed this. > > > I think the safer approach, albeit much more work intensive, would be to make sure we do not crash. Starting with removing RA allocation. I tried to make RA signal safe with https://bugs.openjdk.java.net/browse/JDK-8282405, but that got totally stuck, so better just remove it altogether from AGCT. Over using SafeFetch or plain defensive coding to avoid crashing. > > They are complementary goals. My goal is to improve ASGCT and its stability but this PR should help prevent rare segmentation faults to appear in production. Sorry, I remain unconvinced. Catching and ignoring error signals is akin to silencing the smoke detector because the noise bothers you. Your house still burns. With this patch, we would ignore error signals and the VM would continue running, with a potentially corrupted state of VM and/or system libraries. That may cause silent data corruption, or even security holes. A hard fast crash is always better. We deliberately never return from error handling for this very reason. Once we report a crash, we never even unwind the stack. There had been attempts in the past to return from error handling to normal VM mode for this reason and that, and we always avoided it. The sigjmp technique is fine if you can guarantee that your code does not change state beyond what lives on the thread stack. No global state can change then, not in the VM itself, nor in system libraries. In order to prove that your catch-all patch is safe, you would have to fine-comb AGCT and all the code it calls and make it safe to always jump out of. I believe the work involved would be much higher than just fixing the crashes, and it would be much more prone to bitrot. I believe there is no easy way here. I think if you want to make AGCT safe, you have to analyze and solve the individual crash points. Because if you catch them wholesale, how do you know which crashes are safe to ignore, and which should stop the VM? And even if the crash is safe to ignore, how do you know that by sigjumping back you won't leave the VM in an inconsistent state? ------------- PR: https://git.openjdk.java.net/jdk/pull/8225 From duke at openjdk.java.net Thu Apr 14 13:06:58 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Thu, 14 Apr 2022 13:06:58 GMT Subject: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing [v6] In-Reply-To: References: Message-ID: > Move the AsyncGetCallTrace method implementation into a separate method and wrap its call in non-assert compilation mode in `os::ThreadCrashProtection` like it is done in [JFR](https://github.com/openjdk/jdk/blob/965ea8d9cd29aee41ba2b1b0b0c67bb67eca22dd/src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp#L165). > This prevents AsyncGetCallTrace from crashing on segmentation faults (but not on `guarantee`s). > > If a crash is observed, then the `num_frames` field of the trace is set to `ticks_unknown_state` (-7) to signal a state that cannot be properly handled. `ticks_unknown_state` is currently also used for signaling unknown thread states but this should not be a problem, as the semantic is the same. If `num_frames` already has an error code then this error code is not changed. This helps to distinguish between errors in walking threads in Java and non-Java mode, as `num_frames` is set there before the walking to the appropriate error code. > > _Thanks for @tstuefe for suggesting this._ Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: Handle nested ThreadCrashProtection on POSIX ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8225/files - new: https://git.openjdk.java.net/jdk/pull/8225/files/8abf582c..5e2be187 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8225&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8225&range=04-05 Stats: 28 lines in 3 files changed: 11 ins; 9 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/8225.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8225/head:pull/8225 PR: https://git.openjdk.java.net/jdk/pull/8225 From ihse at openjdk.java.net Thu Apr 14 13:13:15 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Thu, 14 Apr 2022 13:13:15 GMT Subject: RFR: 8284853: Fix various 'expected' typo [v2] In-Reply-To: References: <32dmK9fPqvYhxpZmTgVYMYCfJNLZ3bI8ROg9UqUIRHc=.25e61d1a-6f26-4ea4-b5d3-3c6a80ce08dd@github.com> Message-ID: On Thu, 14 Apr 2022 09:28:17 GMT, Andrey Turbanov wrote: >> Found various typos of expected: `exepected`, `exept`, `epectedly`, `expeced`, `Unexpeted`, etc. > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8284853: Fix various 'expected' typo > improve test log Build changes look good. ------------- Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8231 From luhenry at openjdk.java.net Thu Apr 14 13:55:59 2022 From: luhenry at openjdk.java.net (Ludovic Henry) Date: Thu, 14 Apr 2022 13:55:59 GMT Subject: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing [v6] In-Reply-To: References: Message-ID: On Thu, 14 Apr 2022 13:06:58 GMT, Johannes Bechberger wrote: >> Move the AsyncGetCallTrace method implementation into a separate method and wrap its call in non-assert compilation mode in `os::ThreadCrashProtection` like it is done in [JFR](https://github.com/openjdk/jdk/blob/965ea8d9cd29aee41ba2b1b0b0c67bb67eca22dd/src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp#L165). >> This prevents AsyncGetCallTrace from crashing on segmentation faults (but not on `guarantee`s). >> >> If a crash is observed, then the `num_frames` field of the trace is set to `ticks_unknown_state` (-7) to signal a state that cannot be properly handled. `ticks_unknown_state` is currently also used for signaling unknown thread states but this should not be a problem, as the semantic is the same. If `num_frames` already has an error code then this error code is not changed. This helps to distinguish between errors in walking threads in Java and non-Java mode, as `num_frames` is set there before the walking to the appropriate error code. >> >> _Thanks for @tstuefe for suggesting this._ > > Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: > > Handle nested ThreadCrashProtection on POSIX It could be worth exploring unifying the JFR and AGCT stackwalking mechanism then. If the crash handler is good enough for JFR, it should be considered good enough for AGCT. As raised in a separate email exchange, this doesn't however fix all kind of crashes, such as calls to `guarantee(...)` (like in `CodeCache::find_blob`) since it does not trigger a signal but calls `VMError::report_and_die` directly (or equivalent). Since the code of JFR for stackunwinding is pretty much a copy/paste of AGCT, it's not clear to me what's the difference is (which locks are being held? which other synchronization mechanism?). By unifying, and making sure we use JFR's mechanism wholesale in AGCT, we would make sure AGCT is at least as stable as JFR. From our production use, JFR is stable (we haven't observe consistent crashes like we do with AGCT), so that is to me the reference we need to match. I understand the AGCT2 proposal is unifying + native frames. So we could take the unifying and make it part of this enhancement to AGCT and keep the native frames for AGCT2. ------------- PR: https://git.openjdk.java.net/jdk/pull/8225 From duke at openjdk.java.net Thu Apr 14 14:09:04 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Thu, 14 Apr 2022 14:09:04 GMT Subject: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing [v6] In-Reply-To: References: Message-ID: On Thu, 14 Apr 2022 13:53:08 GMT, Ludovic Henry wrote: > I understand the AGCT2 proposal is unifying + native frames. So we could take the unifying and make it part of this enhancement to AGCT and keep the native frames for AGCT2. I don't think that this should be part of this PR. I'm currently looking into the differences between ASGCT and JFR to be able to certify that ASGCT satisfies the condition of ThreadCrashProtection. If this the case then using it is not problematic. After this a unification is possible, but I would like to keep this PR simple. The unification changes far more code. ------------- PR: https://git.openjdk.java.net/jdk/pull/8225 From jbachorik at openjdk.java.net Thu Apr 14 14:16:45 2022 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Thu, 14 Apr 2022 14:16:45 GMT Subject: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing [v6] In-Reply-To: References: Message-ID: <-TeNiJLBgA5wVXx5z0gqVqCHt5tjPAw7cR7Xj1Cu_UM=.39273b82-d452-4a79-a23c-86f633203b4f@github.com> On Thu, 14 Apr 2022 13:06:58 GMT, Johannes Bechberger wrote: >> Move the AsyncGetCallTrace method implementation into a separate method and wrap its call in non-assert compilation mode in `os::ThreadCrashProtection` like it is done in [JFR](https://github.com/openjdk/jdk/blob/965ea8d9cd29aee41ba2b1b0b0c67bb67eca22dd/src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp#L165). >> This prevents AsyncGetCallTrace from crashing on segmentation faults (but not on `guarantee`s). >> >> If a crash is observed, then the `num_frames` field of the trace is set to `ticks_unknown_state` (-7) to signal a state that cannot be properly handled. `ticks_unknown_state` is currently also used for signaling unknown thread states but this should not be a problem, as the semantic is the same. If `num_frames` already has an error code then this error code is not changed. This helps to distinguish between errors in walking threads in Java and non-Java mode, as `num_frames` is set there before the walking to the appropriate error code. >> >> _Thanks for @tstuefe for suggesting this._ > > Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: > > Handle nested ThreadCrashProtection on POSIX I second the attitude of not snowballing on this PR. Either this is a totally hopeless approach and should be abandoned or it is ok short term and then we should proceed. If nothing else, an isolated and focused fix will have higher chances of backporting than if we just pile on all the goodies we want from the JFR/ASGCT unification (which I think will never get backported). And from the practical ponit of view we really need the chance of crashing JVM reduced in all important versions back to JDK 8 - I know users should upgrade but there is the the nice, theoretical world and then there is the messy world we live in where JDK 8 will continue on living for at least a few years and we (Datadog) need to support it. ------------- PR: https://git.openjdk.java.net/jdk/pull/8225 From duke at openjdk.java.net Thu Apr 14 14:37:25 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Thu, 14 Apr 2022 14:37:25 GMT Subject: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing [v7] In-Reply-To: References: Message-ID: > Move the AsyncGetCallTrace method implementation into a separate method and wrap its call in non-assert compilation mode in `os::ThreadCrashProtection` like it is done in [JFR](https://github.com/openjdk/jdk/blob/965ea8d9cd29aee41ba2b1b0b0c67bb67eca22dd/src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp#L165). > This prevents AsyncGetCallTrace from crashing on segmentation faults (but not on `guarantee`s). > > If a crash is observed, then the `num_frames` field of the trace is set to `ticks_unknown_state` (-7) to signal a state that cannot be properly handled. `ticks_unknown_state` is currently also used for signaling unknown thread states but this should not be a problem, as the semantic is the same. If `num_frames` already has an error code then this error code is not changed. This helps to distinguish between errors in walking threads in Java and non-Java mode, as `num_frames` is set there before the walking to the appropriate error code. > > _Thanks for @tstuefe for suggesting this._ Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: Add CrashProtectAsyncGetCallTrace option ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8225/files - new: https://git.openjdk.java.net/jdk/pull/8225/files/5e2be187..d003ce09 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8225&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8225&range=05-06 Stats: 13 lines in 2 files changed: 7 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/8225.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8225/head:pull/8225 PR: https://git.openjdk.java.net/jdk/pull/8225 From duke at openjdk.java.net Thu Apr 14 14:37:26 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Thu, 14 Apr 2022 14:37:26 GMT Subject: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing [v6] In-Reply-To: References: Message-ID: On Thu, 14 Apr 2022 13:06:58 GMT, Johannes Bechberger wrote: >> Move the AsyncGetCallTrace method implementation into a separate method and wrap its call in non-assert compilation mode in `os::ThreadCrashProtection` like it is done in [JFR](https://github.com/openjdk/jdk/blob/965ea8d9cd29aee41ba2b1b0b0c67bb67eca22dd/src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp#L165). >> This prevents AsyncGetCallTrace from crashing on segmentation faults (but not on `guarantee`s). >> >> If a crash is observed, then the `num_frames` field of the trace is set to `ticks_unknown_state` (-7) to signal a state that cannot be properly handled. `ticks_unknown_state` is currently also used for signaling unknown thread states but this should not be a problem, as the semantic is the same. If `num_frames` already has an error code then this error code is not changed. This helps to distinguish between errors in walking threads in Java and non-Java mode, as `num_frames` is set there before the walking to the appropriate error code. >> >> _Thanks for @tstuefe for suggesting this._ > > Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: > > Handle nested ThreadCrashProtection on POSIX I compared the code of ASGCT and JFR and found only one instance of a method that is used in ASGCT, but not in JFR and which does affect the VM state. It is the `JavaThread::block_if_vm_exited` method which is transitively called, a fix for this is coming. Therefore there is, in my opinion, no reason why we cannot wrap AsyncGetCallTrace in ThreadCrashProtection. ------------- PR: https://git.openjdk.java.net/jdk/pull/8225 From duke at openjdk.java.net Thu Apr 14 14:56:29 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Thu, 14 Apr 2022 14:56:29 GMT Subject: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing [v8] In-Reply-To: References: Message-ID: > Move the AsyncGetCallTrace method implementation into a separate method and wrap its call in non-assert compilation mode in `os::ThreadCrashProtection` like it is done in [JFR](https://github.com/openjdk/jdk/blob/965ea8d9cd29aee41ba2b1b0b0c67bb67eca22dd/src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp#L165). > This prevents AsyncGetCallTrace from crashing on segmentation faults (but not on `guarantee`s). > > If a crash is observed, then the `num_frames` field of the trace is set to `ticks_unknown_state` (-7) to signal a state that cannot be properly handled. `ticks_unknown_state` is currently also used for signaling unknown thread states but this should not be a problem, as the semantic is the same. If `num_frames` already has an error code then this error code is not changed. This helps to distinguish between errors in walking threads in Java and non-Java mode, as `num_frames` is set there before the walking to the appropriate error code. > > _Thanks for @tstuefe for suggesting this._ Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: Do not call JavaThread::thread_from_jni_environment Calling JavaThread::thread_from_jni_environment for a terminated thread might cause the aquisition of a lock. Calling JavaThread::current does not have this problem and AsyncGetCallTrace can only be called on the current thread anyway. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8225/files - new: https://git.openjdk.java.net/jdk/pull/8225/files/d003ce09..b16e85d2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8225&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8225&range=06-07 Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/8225.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8225/head:pull/8225 PR: https://git.openjdk.java.net/jdk/pull/8225 From duke at openjdk.java.net Thu Apr 14 15:19:17 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Thu, 14 Apr 2022 15:19:17 GMT Subject: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing [v9] In-Reply-To: References: Message-ID: > Move the AsyncGetCallTrace method implementation into a separate method and wrap its call in non-assert compilation mode in `os::ThreadCrashProtection` like it is done in [JFR](https://github.com/openjdk/jdk/blob/965ea8d9cd29aee41ba2b1b0b0c67bb67eca22dd/src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp#L165). > This prevents AsyncGetCallTrace from crashing on segmentation faults (but not on `guarantee`s). > > If a crash is observed, then the `num_frames` field of the trace is set to `ticks_unknown_state` (-7) to signal a state that cannot be properly handled. `ticks_unknown_state` is currently also used for signaling unknown thread states but this should not be a problem, as the semantic is the same. If `num_frames` already has an error code then this error code is not changed. This helps to distinguish between errors in walking threads in Java and non-Java mode, as `num_frames` is set there before the walking to the appropriate error code. > > _Thanks for @tstuefe for suggesting this._ Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: Use JavaThread::current_or_null ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8225/files - new: https://git.openjdk.java.net/jdk/pull/8225/files/b16e85d2..102fd783 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8225&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8225&range=07-08 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8225.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8225/head:pull/8225 PR: https://git.openjdk.java.net/jdk/pull/8225 From stuefe at openjdk.java.net Thu Apr 14 15:45:31 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 14 Apr 2022 15:45:31 GMT Subject: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing [v6] In-Reply-To: References: Message-ID: On Thu, 14 Apr 2022 14:33:35 GMT, Johannes Bechberger wrote: > I compared the code of ASGCT and JFR and found only one instance of a method that is used in ASGCT, but not in JFR and which does affect the VM state. It is the `JavaThread::block_if_vm_exited` method which is transitively called, a fix for this is coming. Therefore there is, in my opinion, no reason why we cannot wrap AsyncGetCallTrace in ThreadCrashProtection. Sorry, you did address none of my arguments. I see a reasoning chain that starts by JFR being "good enough" and from there concluding that using it in AGCT its good enough too. Well, maybe it was a bad idea in the first place. And right now, this code is only used by JFR. Reusing it perpetuates this pattern which others will follow. Because its so convenient just to catch all crashes. Does the code use Resource Area? Then its not sigjmp safe. Does it do any kind of dynamic allocation which could leak? Then its not sigjmp safe. Does it use locks? Again, not sigjmp safe. Does it use any kind of RAII objects? You guess it, its not sigjmp safe. Does it call libc functions that cause it to change state? Probably unsafe too. And even if you today can prove that the whole code is safe, how do you prevent bitrot? These are general purpose hotspot functions. Someone may tomorrow use malloc, or RA. How would you know? The fact that we never saw a problem in JFR does not prove much. A corruption may never show symptoms. It may only effect certain platforms, certain conditions, certain flukes of the memory layout god. There may be that one crash that you really should not have ignored or sigjmp'ed out of, but you never saw it in your tests, because it only happens to that one customer. What I really worry about is the delayed effect. Hiding the crash may cause delayed errors that are really hard to track down. Effectively transforming what would be a simple crash with an hs-err file and a core into a maintenance nightmare. That is why sigjmp is used very sparingly, and only in very controlled environments. Put it another way: to really prove that what you do is safe, you have to answer, for every possible crash location: 1) is the crash itself benign and can be ignored? 2) is it safe to jump out of the crash code back to the entrance of AGCT, or would that interruption corrupt the VM or a system library? My point is, if you can answer these questions, you can fix the crash. Therefore it makes no sense to wholesale catch signals. Either the code is safe and does not crash, then no need for catch-all. Or it is not, then its important to understand where we crash and why. Ignoring unknown crashes is not a good idea. ------------- PR: https://git.openjdk.java.net/jdk/pull/8225 From mgronlun at openjdk.java.net Thu Apr 14 16:47:31 2022 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Thu, 14 Apr 2022 16:47:31 GMT Subject: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing [v9] In-Reply-To: References: Message-ID: On Thu, 14 Apr 2022 15:19:17 GMT, Johannes Bechberger wrote: >> Move the AsyncGetCallTrace method implementation into a separate method and wrap its call in non-assert compilation mode in `os::ThreadCrashProtection` like it is done in [JFR](https://github.com/openjdk/jdk/blob/965ea8d9cd29aee41ba2b1b0b0c67bb67eca22dd/src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp#L165). >> This prevents AsyncGetCallTrace from crashing on segmentation faults (but not on `guarantee`s). >> >> If a crash is observed, then the `num_frames` field of the trace is set to `ticks_unknown_state` (-7) to signal a state that cannot be properly handled. `ticks_unknown_state` is currently also used for signaling unknown thread states but this should not be a problem, as the semantic is the same. If `num_frames` already has an error code then this error code is not changed. This helps to distinguish between errors in walking threads in Java and non-Java mode, as `num_frames` is set there before the walking to the appropriate error code. >> >> _Thanks for @tstuefe for suggesting this._ > > Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: > > Use JavaThread::current_or_null One important difference to consider is that in JFR, in contrast to AGCT. there is only a single thread, the ThreadSampler thread, that is wrapped in the CrashProtection. Stack walking is different in JFR compared to AGCT, in that it is done by a _different_thread_, during a point where the target is suspended. Originally, this thread sampler thread was not even part of the VM, although now it is a NonJavaThread. It has been trimmed to not involve malloc(), raii, and other hard-to-recover from constructs, from the moment it has another thread suspended. Over the years, some transitive malloc() calls has snuck in, but it was eventually found due to rare deadlocking. Thomas brings a good point about crashes needing to be recoverable. ------------- PR: https://git.openjdk.java.net/jdk/pull/8225 From duke at openjdk.java.net Thu Apr 14 17:04:24 2022 From: duke at openjdk.java.net (Tobias Holenstein) Date: Thu, 14 Apr 2022 17:04:24 GMT Subject: RFR: JDK-8075816: Deprecate AliasLevel flag since it is broken [v3] In-Reply-To: References: Message-ID: > Deprecate the `AliasLevel` flag. `AliasLevel` can have the following values: > > "0 - for no aliasing, " > "1 - for oop/field/static/array split, " > "2 - for class split, " > "3 - for unique instances" > > - Deprecate AliasLevel in JDK 19. > - Obsolete it in JDK 20 > - Expire it in JDK 21. > > Users will now get the following message when running: > `java -XX:AliasLevel= Java HotSpot(TM) 64-Bit Server VM warning: Option AliasLevel was deprecated in version 19.0 and will likely be removed in a future release.` Tobias Holenstein has updated the pull request incrementally with one additional commit since the last revision: Revert "Obsolete AliasLevel flag" This reverts commit 6a1bed2d7ed5494b051fae09d28787fd01de9635. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8140/files - new: https://git.openjdk.java.net/jdk/pull/8140/files/6a1bed2d..782fb37d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8140&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8140&range=01-02 Stats: 77 lines in 12 files changed: 57 ins; 2 del; 18 mod Patch: https://git.openjdk.java.net/jdk/pull/8140.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8140/head:pull/8140 PR: https://git.openjdk.java.net/jdk/pull/8140 From mgronlun at openjdk.java.net Thu Apr 14 17:11:31 2022 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Thu, 14 Apr 2022 17:11:31 GMT Subject: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing [v9] In-Reply-To: References: Message-ID: On Thu, 14 Apr 2022 15:19:17 GMT, Johannes Bechberger wrote: >> Move the AsyncGetCallTrace method implementation into a separate method and wrap its call in non-assert compilation mode in `os::ThreadCrashProtection` like it is done in [JFR](https://github.com/openjdk/jdk/blob/965ea8d9cd29aee41ba2b1b0b0c67bb67eca22dd/src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp#L165). >> This prevents AsyncGetCallTrace from crashing on segmentation faults (but not on `guarantee`s). >> >> If a crash is observed, then the `num_frames` field of the trace is set to `ticks_unknown_state` (-7) to signal a state that cannot be properly handled. `ticks_unknown_state` is currently also used for signaling unknown thread states but this should not be a problem, as the semantic is the same. If `num_frames` already has an error code then this error code is not changed. This helps to distinguish between errors in walking threads in Java and non-Java mode, as `num_frames` is set there before the walking to the appropriate error code. >> >> _Thanks for @tstuefe for suggesting this._ > > Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: > > Use JavaThread::current_or_null For additional context, I should add that the CrashProtection mechanism was mainly put in place as a result of having to deliver JFR from JRockit into Hotspot under a deadline. upholding feature-parity. The stack walking code was in really bad shape back then. Over the years though, it has been hardened and improved much, and I have not seen any reported issues about JFR crashes in many years (we log when crashing in production). An important difference is that AGCT allows more thread states compared to JFR, so there can be issues in that area that are not seen in JFR. ------------- PR: https://git.openjdk.java.net/jdk/pull/8225 From aph at openjdk.java.net Thu Apr 14 17:33:31 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Thu, 14 Apr 2022 17:33:31 GMT Subject: RFR: 8282541: AArch64: Auto-vectorize Math.round API [v2] In-Reply-To: <88RK-3hLy6Q3WdSNYrHqvdjqMnXtk7FhEBsPhNAADeE=.d35f4b9a-b161-470c-b73d-32e58aa68e3e@github.com> References: <88RK-3hLy6Q3WdSNYrHqvdjqMnXtk7FhEBsPhNAADeE=.d35f4b9a-b161-470c-b73d-32e58aa68e3e@github.com> Message-ID: On Wed, 13 Apr 2022 06:44:25 GMT, Ningsheng Jian wrote: > Remove `n->as_Vector()->length() == $5` ? I think there is no need to limit vector length for SVE, i.e. for all SVE vector lengths, we should generate the same code. For example, you have limited the size to 8F below, which is 256 bits but there's no rule for other bits (512) of vector then. Ah yes, it should be `>= 256` ------------- PR: https://git.openjdk.java.net/jdk/pull/8204 From duke at openjdk.java.net Thu Apr 14 17:41:30 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Thu, 14 Apr 2022 17:41:30 GMT Subject: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing [v9] In-Reply-To: References: Message-ID: <3F_-XP2apC9QBGJ8O1UUpnoWvJJLd1ZblXocwm7cBUk=.ca5329a6-32ab-4803-9fdb-7e4defec92cc@github.com> On Thu, 14 Apr 2022 15:19:17 GMT, Johannes Bechberger wrote: >> Move the AsyncGetCallTrace method implementation into a separate method and wrap its call in non-assert compilation mode in `os::ThreadCrashProtection` like it is done in [JFR](https://github.com/openjdk/jdk/blob/965ea8d9cd29aee41ba2b1b0b0c67bb67eca22dd/src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp#L165). >> This prevents AsyncGetCallTrace from crashing on segmentation faults (but not on `guarantee`s). >> >> If a crash is observed, then the `num_frames` field of the trace is set to `ticks_unknown_state` (-7) to signal a state that cannot be properly handled. `ticks_unknown_state` is currently also used for signaling unknown thread states but this should not be a problem, as the semantic is the same. If `num_frames` already has an error code then this error code is not changed. This helps to distinguish between errors in walking threads in Java and non-Java mode, as `num_frames` is set there before the walking to the appropriate error code. >> >> _Thanks for @tstuefe for suggesting this._ > > Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: > > Use JavaThread::current_or_null This seems to get a bit out of hand and I do not currently have time to address these (vacation). I would like to put the discussion on hold for now and therefore converted it into a draft. ------------- PR: https://git.openjdk.java.net/jdk/pull/8225 From aph at openjdk.java.net Thu Apr 14 17:43:49 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Thu, 14 Apr 2022 17:43:49 GMT Subject: RFR: 8282541: AArch64: Auto-vectorize Math.round API [v2] In-Reply-To: <88RK-3hLy6Q3WdSNYrHqvdjqMnXtk7FhEBsPhNAADeE=.d35f4b9a-b161-470c-b73d-32e58aa68e3e@github.com> References: <88RK-3hLy6Q3WdSNYrHqvdjqMnXtk7FhEBsPhNAADeE=.d35f4b9a-b161-470c-b73d-32e58aa68e3e@github.com> Message-ID: On Wed, 13 Apr 2022 07:01:18 GMT, Ningsheng Jian wrote: > I don't know why do we need these rules. Should "UseSVE > 0" all go to the rules in sve ad file which call to vector_round_sve()? The freely-available Arm? Neoverse V1 Software Optimization Guide shows instructions such as ASIMD `FRINTA` having a throughput of 2 operations per clock, whereas it shows SVE `FRINTA` has a throughput of 1 operation per clock. This is true of most instructions used in `Math.round()`. I conclude that on V1, for short vectors, if we use ASIMD rather than equivalent SVE instructions, we should expect to virtually double throughput. For vectors wider than ASIMD supports, SVE should be a win. At present, there is no reason not to use ASIMD for short vectors on all AArch64 processors. It won't significantly impair performance, and I can't think of any future circumstances in which it might. ------------- PR: https://git.openjdk.java.net/jdk/pull/8204 From aturbanov at openjdk.java.net Thu Apr 14 18:09:37 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Thu, 14 Apr 2022 18:09:37 GMT Subject: Integrated: 8284853: Fix various 'expected' typo In-Reply-To: <32dmK9fPqvYhxpZmTgVYMYCfJNLZ3bI8ROg9UqUIRHc=.25e61d1a-6f26-4ea4-b5d3-3c6a80ce08dd@github.com> References: <32dmK9fPqvYhxpZmTgVYMYCfJNLZ3bI8ROg9UqUIRHc=.25e61d1a-6f26-4ea4-b5d3-3c6a80ce08dd@github.com> Message-ID: On Wed, 13 Apr 2022 20:36:48 GMT, Andrey Turbanov wrote: > Found various typos of expected: `exepected`, `exept`, `epectedly`, `expeced`, `Unexpeted`, etc. This pull request has now been integrated. Changeset: 48c75498 Author: Andrey Turbanov URL: https://git.openjdk.java.net/jdk/commit/48c75498060f076287d3d44c49934db9ac70887b Stats: 65 lines in 28 files changed: 0 ins; 0 del; 65 mod 8284853: Fix various 'expected' typo Reviewed-by: bpb, ihse ------------- PR: https://git.openjdk.java.net/jdk/pull/8231 From aturbanov at openjdk.java.net Thu Apr 14 18:09:34 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Thu, 14 Apr 2022 18:09:34 GMT Subject: RFR: 8284853: Fix various 'expected' typo [v2] In-Reply-To: References: <32dmK9fPqvYhxpZmTgVYMYCfJNLZ3bI8ROg9UqUIRHc=.25e61d1a-6f26-4ea4-b5d3-3c6a80ce08dd@github.com> Message-ID: On Thu, 14 Apr 2022 10:38:33 GMT, Yi Yang wrote: >I found [yet another typo](https://github.com/kelthuzadx/jdk/commit/acb9e15bc0bf5395d1c0875f36992f692734f948), I wonder if you can merge this into your patch so that I do not need to submit a new PR for it? Thanks. I think it deserves a separate ticket. BTW there are a lot of other typos in JDK, especially in comments. ------------- PR: https://git.openjdk.java.net/jdk/pull/8231 From psandoz at openjdk.java.net Thu Apr 14 21:42:08 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Thu, 14 Apr 2022 21:42:08 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2] In-Reply-To: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com> References: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com> Message-ID: On Wed, 13 Apr 2022 14:21:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh src/java.base/share/classes/java/lang/Thread.java line 862: > 860: * @param start the starting value of the counter > 861: * @return this builder > 862: * @throws IllegalArgumentException if count is negative Suggestion: * @throws IllegalArgumentException if start is negative ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From psandoz at openjdk.java.net Thu Apr 14 21:54:44 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Thu, 14 Apr 2022 21:54:44 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2] In-Reply-To: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com> References: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com> Message-ID: On Wed, 13 Apr 2022 14:21:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh src/java.base/share/classes/java/lang/Thread.java line 213: > 211: > 212: // Additional fields for platform threads > 213: private static class FieldHolder { All but the task field are explicitly known by the VM (and stillborn is not accessed by Java code. Suggest grouping accordingly. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From psandoz at openjdk.java.net Thu Apr 14 22:22:45 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Thu, 14 Apr 2022 22:22:45 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2] In-Reply-To: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com> References: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com> Message-ID: On Wed, 13 Apr 2022 14:21:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh src/java.base/share/classes/java/lang/Thread.java line 3028: > 3026: > 3027: /** The thread container that this thread is in */ > 3028: @Stable private volatile ThreadContainer container; The `volatile` modifier with `@Stable` is unusual. IIUC the field is set once on start (behaves as if a final field). Once C2 gets hold of it and can treat the value as a runtime constant the `volatile` has no effect. This is a tricky area but i think a store fence will suffice in `setThreadContainer` since the value goes from null to non-null and therefore cannot be speculated upon. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From psandoz at openjdk.java.net Fri Apr 15 00:19:43 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Fri, 15 Apr 2022 00:19:43 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2] In-Reply-To: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com> References: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com> Message-ID: On Wed, 13 Apr 2022 14:21:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh src/java.base/share/classes/java/lang/VirtualThread.java line 65: > 63: * system. > 64: */ > 65: class VirtualThread extends Thread { Suggestion: final class VirtualThread extends Thread { src/java.base/share/classes/java/lang/VirtualThread.java line 94: > 92: * RUNNING -> PARKING // Thread attempts to park > 93: * PARKING -> PARKED // yield successful, thread is parked > 94: * PARKING -> PINNED // yield failed, thread is pinned Suggestion: * PARKING -> PARKED // parking successful, thread is parked * PARKING -> PINNED // parking failed, thread is pinned ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From njian at openjdk.java.net Fri Apr 15 03:29:40 2022 From: njian at openjdk.java.net (Ningsheng Jian) Date: Fri, 15 Apr 2022 03:29:40 GMT Subject: RFR: 8282541: AArch64: Auto-vectorize Math.round API [v2] In-Reply-To: References: <88RK-3hLy6Q3WdSNYrHqvdjqMnXtk7FhEBsPhNAADeE=.d35f4b9a-b161-470c-b73d-32e58aa68e3e@github.com> Message-ID: <_SuC-IP3rF6aHB_Ii8q5uozKoTA3Y0FJxrTw1Hf907Q=.d2db969f-9569-4712-98c1-cabf93ac9139@github.com> On Thu, 14 Apr 2022 17:41:13 GMT, Andrew Haley wrote: >> src/hotspot/cpu/aarch64/aarch64_neon_ad.m4 line 374: >> >>> 372: VECTOR_JAVA_FROUND(F, 4F, I, T4S, 4, INT, vReg) >>> 373: VECTOR_JAVA_FROUND(D, 2D, L, T2D, 2, LONG, vReg) >>> 374: >> >> I don't know why do we need these rules. Should "UseSVE > 0" all go to the rules in sve ad file which call to vector_round_sve()? > >> I don't know why do we need these rules. Should "UseSVE > 0" all go to the rules in sve ad file which call to vector_round_sve()? > > The freely-available Arm? Neoverse V1 Software Optimization Guide shows instructions such as ASIMD `FRINTA` having a throughput of 2 operations per clock, whereas it shows SVE `FRINTA` has a throughput of 1 operation per clock. This is true of most instructions used in `Math.round()`. I conclude that on V1, for short vectors, if we use ASIMD rather than equivalent SVE instructions, we should expect to virtually double throughput. For vectors wider than ASIMD supports, SVE should be a win. > > At present, there is no reason not to use ASIMD for short vectors on all AArch64 processors. It won't significantly impair performance, and I can't think of any future circumstances in which it might. OK, thanks! Looks reasonable to me. We are going to make all vecX/vecD regs to vReg, I think that should make SIMD code cleaner. Currently all rules for vReg are in aarch64_sve.ad. And since the codegen is actually for SVE target, though generates ASIMD insns, perhaps move these rules to aarch64_sve.ad would be better? Also I think the 2F/4F rules could be merged into one, like: instruct vroundvRegF(vReg dst, vReg src, vReg tmp1, vReg tmp2, vReg tmp3) %{ predicate(n->as_Vector()->length_in_bytes() <= 16); match(Set dst (RoundVF src)); effect(TEMP_DEF dst, TEMP tmp1, TEMP tmp2, TEMP tmp3); format %{ "vround $dst, $src\t# round vReg F to I vector" %} ins_encode %{ uint size = Matcher::vector_length_in_bytes(this); __ vector_round_neon(as_FloatRegister($dst$$reg), as_FloatRegister($src$$reg), as_FloatRegister($tmp1$$reg), as_FloatRegister($tmp2$$reg), as_FloatRegister($tmp3$$reg), (size == 16) ? __ T4S : __ T2S); %} ins_pipe(pipe_slow); %} ------------- PR: https://git.openjdk.java.net/jdk/pull/8204 From eliu at openjdk.java.net Fri Apr 15 05:52:01 2022 From: eliu at openjdk.java.net (Eric Liu) Date: Fri, 15 Apr 2022 05:52:01 GMT Subject: RFR: 8284563: AArch64: bitperm feature detection for SVE2 on Linux Message-ID: This patch adds BITPERM feature detection for SVE2 on Linux. BITPERM is an optional feature in SVE2 [1]. It enables 3 SVE2 instructions (BEXT, BDEP, BGRP). BEXT and BDEP map efficiently to some vector operations, e.g., the compress and expand functionalities [2] which are proposed in VectorAPI's 4th incubation [3]. Besides, to generate specific code based on different architecture features like x86, this patch exports VM_Version::supports_XXX() for all CPU features. E.g., VM_Version::supports_svebitperm() for easy use. This patch also fixes a trivial bug, that sets UseSVE back to 1 if it's 2 in SVE1 system. [1] https://developer.arm.com/documentation/ddi0601/2022-03/AArch64-Registers/ID-AA64ZFR0-EL1--SVE-Feature-ID-register-0 [2] https://bugs.openjdk.java.net/browse/JDK-8283893 [3] https://bugs.openjdk.java.net/browse/JDK-8280173 ------------- Commit messages: - 8284563: AArch64: bitperm feature detection for SVE2 on Linux Changes: https://git.openjdk.java.net/jdk/pull/8258/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8258&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8284563 Stats: 63 lines in 5 files changed: 23 ins; 1 del; 39 mod Patch: https://git.openjdk.java.net/jdk/pull/8258.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8258/head:pull/8258 PR: https://git.openjdk.java.net/jdk/pull/8258 From ihse at openjdk.java.net Fri Apr 15 07:47:15 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Fri, 15 Apr 2022 07:47:15 GMT Subject: RFR: 8284903: Fix typos in hotspot Message-ID: I ran `codespell` on hotspot, and accepted those changes where it indeed discovered real typos. You'd be surprised over the many implementions of instrinsics and other intructions accross all archtectures I've encounted, so for the preceding reason it's neccesery to sucessfully seach for exisiting typos... ------------- Commit messages: - Pass #2 - Pass #1 in shared code - Pass #1 in platform-specific code Changes: https://git.openjdk.java.net/jdk/pull/8260/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8260&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8284903 Stats: 910 lines in 446 files changed: 0 ins; 0 del; 910 mod Patch: https://git.openjdk.java.net/jdk/pull/8260.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8260/head:pull/8260 PR: https://git.openjdk.java.net/jdk/pull/8260 From aph at openjdk.java.net Fri Apr 15 08:17:41 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Fri, 15 Apr 2022 08:17:41 GMT Subject: RFR: 8282541: AArch64: Auto-vectorize Math.round API [v2] In-Reply-To: <_SuC-IP3rF6aHB_Ii8q5uozKoTA3Y0FJxrTw1Hf907Q=.d2db969f-9569-4712-98c1-cabf93ac9139@github.com> References: <88RK-3hLy6Q3WdSNYrHqvdjqMnXtk7FhEBsPhNAADeE=.d35f4b9a-b161-470c-b73d-32e58aa68e3e@github.com> <_SuC-IP3rF6aHB_Ii8q5uozKoTA3Y0FJxrTw1Hf907Q=.d2db969f-9569-4712-98c1-cabf93ac9139@github.com> Message-ID: On Fri, 15 Apr 2022 03:26:27 GMT, Ningsheng Jian wrote: >>> I don't know why do we need these rules. Should "UseSVE > 0" all go to the rules in sve ad file which call to vector_round_sve()? >> >> The freely-available Arm? Neoverse V1 Software Optimization Guide shows instructions such as ASIMD `FRINTA` having a throughput of 2 operations per clock, whereas it shows SVE `FRINTA` has a throughput of 1 operation per clock. This is true of most instructions used in `Math.round()`. I conclude that on V1, for short vectors, if we use ASIMD rather than equivalent SVE instructions, we should expect to virtually double throughput. For vectors wider than ASIMD supports, SVE should be a win. >> >> At present, there is no reason not to use ASIMD for short vectors on all AArch64 processors. It won't significantly impair performance, and I can't think of any future circumstances in which it might. > > OK, thanks! Looks reasonable to me. We are going to make all vecX/vecD regs to vReg, I think that should make SIMD code cleaner. > > Currently all rules for vReg are in aarch64_sve.ad. And since the codegen is actually for SVE target, though generates ASIMD insns, perhaps move these rules to aarch64_sve.ad would be better? Also I think the 2F/4F rules could be merged into one, like: > > > instruct vroundvRegF(vReg dst, vReg src, vReg tmp1, vReg tmp2, vReg tmp3) > %{ > predicate(n->as_Vector()->length_in_bytes() <= 16); > match(Set dst (RoundVF src)); > effect(TEMP_DEF dst, TEMP tmp1, TEMP tmp2, TEMP tmp3); > format %{ "vround $dst, $src\t# round vReg F to I vector" %} > ins_encode %{ > uint size = Matcher::vector_length_in_bytes(this); > __ vector_round_neon(as_FloatRegister($dst$$reg), as_FloatRegister($src$$reg), > as_FloatRegister($tmp1$$reg), as_FloatRegister($tmp2$$reg), > as_FloatRegister($tmp3$$reg), (size == 16) ? __ T4S : __ T2S); > %} > ins_pipe(pipe_slow); > %} Seems reasonable. Maybe we could the logic down into MacroAssembler. That way there'd be one point at which the SVE/Neon devcision was made, in MacroAssembler. The disadvantage would be that Neon and SVE versions require different register clobbers, but that might not matter. ------------- PR: https://git.openjdk.java.net/jdk/pull/8204 From aph at openjdk.java.net Fri Apr 15 08:20:51 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Fri, 15 Apr 2022 08:20:51 GMT Subject: RFR: 8284563: AArch64: bitperm feature detection for SVE2 on Linux In-Reply-To: References: Message-ID: On Fri, 15 Apr 2022 05:45:58 GMT, Eric Liu wrote: > This patch adds BITPERM feature detection for SVE2 on Linux. BITPERM is > an optional feature in SVE2 [1]. It enables 3 SVE2 instructions (BEXT, > BDEP, BGRP). BEXT and BDEP map efficiently to some vector operations, > e.g., the compress and expand functionalities [2] which are proposed in > VectorAPI's 4th incubation [3]. Besides, to generate specific code based > on different architecture features like x86, this patch exports > VM_Version::supports_XXX() for all CPU features. E.g., > VM_Version::supports_svebitperm() for easy use. > > This patch also fixes a trivial bug, that sets UseSVE back to 1 if it's > 2 in SVE1 system. > > [1] https://developer.arm.com/documentation/ddi0601/2022-03/AArch64-Registers/ID-AA64ZFR0-EL1--SVE-Feature-ID-register-0 > [2] https://bugs.openjdk.java.net/browse/JDK-8283893 > [3] https://bugs.openjdk.java.net/browse/JDK-8280173 Looks like a good cleanup. VM_Version is getting to be very unruly. ------------- Marked as reviewed by aph (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8258 From stuefe at openjdk.java.net Fri Apr 15 09:08:44 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 15 Apr 2022 09:08:44 GMT Subject: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing [v9] In-Reply-To: References: Message-ID: On Thu, 14 Apr 2022 17:08:32 GMT, Markus Gr?nlund wrote: > For additional context, I should add that the CrashProtection mechanism was mainly put in place as a result of having to deliver JFR from JRockit into Hotspot under a deadline, upholding feature-parity. The stack walking code was in really bad shape back then. Over the years, it has been hardened and improved much, and I have not seen any reported issues about JFR crashes in many years (we log when crashing in production). > > An important difference is that AGCT allows more thread states compared to JFR, so there can be issues in that area that are not seen in JFR. Thanks for the JFR insight, Marcus. I can see the CrashProtection being a stop-gap measure under time constraints. Maybe worth rethinking now. From your description, the way it is used in JFR differ significantly from how the async-profiler would use it. Privately, I start wondering whether the benefits of async-profiler over JFR are worth the risk of corrupting the VM or the work needed to harden out AGCT. Their feature-set seems to overlap a lot. I may not see the whole picture though, I'm not a profiler expert. ------------- PR: https://git.openjdk.java.net/jdk/pull/8225 From njian at openjdk.java.net Fri Apr 15 10:04:40 2022 From: njian at openjdk.java.net (Ningsheng Jian) Date: Fri, 15 Apr 2022 10:04:40 GMT Subject: RFR: 8284563: AArch64: bitperm feature detection for SVE2 on Linux In-Reply-To: References: Message-ID: <-tRedEjmlUXfwqLEQz7GWKiy64cAcOKCXXZEkl7EnpY=.7d1d300a-0350-4283-a400-85d685bb2238@github.com> On Fri, 15 Apr 2022 05:45:58 GMT, Eric Liu wrote: > This patch adds BITPERM feature detection for SVE2 on Linux. BITPERM is > an optional feature in SVE2 [1]. It enables 3 SVE2 instructions (BEXT, > BDEP, BGRP). BEXT and BDEP map efficiently to some vector operations, > e.g., the compress and expand functionalities [2] which are proposed in > VectorAPI's 4th incubation [3]. Besides, to generate specific code based > on different architecture features like x86, this patch exports > VM_Version::supports_XXX() for all CPU features. E.g., > VM_Version::supports_svebitperm() for easy use. > > This patch also fixes a trivial bug, that sets UseSVE back to 1 if it's > 2 in SVE1 system. > > [1] https://developer.arm.com/documentation/ddi0601/2022-03/AArch64-Registers/ID-AA64ZFR0-EL1--SVE-Feature-ID-register-0 > [2] https://bugs.openjdk.java.net/browse/JDK-8283893 > [3] https://bugs.openjdk.java.net/browse/JDK-8280173 src/hotspot/cpu/aarch64/vm_version_aarch64.hpp line 132: > 130: // Feature identification > 131: #define CPU_FEATURE_DETECTION(id, name, bit) \ > 132: static bool supports_##name() { return (_features & CPU_##id) != 0; }; Having supports_a53mac() looks a bit weird to me. ------------- PR: https://git.openjdk.java.net/jdk/pull/8258 From duke at openjdk.java.net Fri Apr 15 10:07:41 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Fri, 15 Apr 2022 10:07:41 GMT Subject: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing [v9] In-Reply-To: References: Message-ID: On Fri, 15 Apr 2022 09:05:23 GMT, Thomas Stuefe wrote: > Thanks for the JFR insight, Marcus. I can see the CrashProtection being a stop-gap measure under time constraints. Maybe worth rethinking now. From your description, the way it is used in JFR differ significantly from how the async-profiler would use it. I came to the same conclusion. Therefore I don't think that adding CrashProtection is worth the effort. > Privately, I start wondering whether the benefits of async-profiler over JFR are worth the risk of corrupting the VM or the work needed to harden out AGCT. Their feature-set seems to overlap a lot. I may not see the whole picture though, I'm not a profiler expert. ASGCT makes it possible to develop your own profiler. The implementation overlaps but the feature set does not. You cannot build your own profiler with JFR. AsyncProfiler has with ASGCT the possibility to capture call traces with different intervals that are related to perf-events which is not possible in JFR. ASGCT should be a best effort API that has its caveats, one of them being that it might crash the VM. I think the goal is to make ASGCT as safe as possible to use without altering the normal behaviour (and speed) of the VM. Calling the API should not alter anything on the heap or in any other data structures. This is also true for JFR and many stability fixes for ASGCT (like using SafeFetch in some places) should also benefit the stability of JFR. I therefore want to close this PR (and the related issue) and propose my "[Do not call JavaThread::thread_from_jni_environment](https://github.com/openjdk/jdk/pull/8225/commits/b16e85d2251ae8cf7433ff146ea209d094a37c8a)" commit in a new PR as adding PRs for all the errors I find in JFR and ASGCT seems to be the way forward. ------------- PR: https://git.openjdk.java.net/jdk/pull/8225 From stuefe at openjdk.java.net Fri Apr 15 10:41:44 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 15 Apr 2022 10:41:44 GMT Subject: RFR: JDK-8283326: Implement SafeFetch statically [v6] In-Reply-To: References: Message-ID: On Wed, 13 Apr 2022 09:22:45 GMT, Thomas Stuefe wrote: >> Hi, >> >> This is a reimplementation of SafeFetch to get rid of dynamic code generation. This is done, depending on platform, via static assembly, Posix setjmp/longjmp or SEH. >> >> This is based on a proposal by @theRealAph [1] when discussing [JDK-8282475](https://bugs.openjdk.java.net/browse/JDK-8282475). I extended the proposal to do this for all platforms, not just MacOS, see discussion below. >> >> --- >> >> Why we do this: >> >> SafeFetch is special: it is a basic utility function that may be called before the VM is properly initialized, from a "foreign" thread not attached to the VM, in a broken environment... mainly this is due to its use during stack walking, error reporting, hex dumping, etc. SafeFetch has to be safe to call under any circumstances - or as safe as we can make it. >> >> Today, SafeFetch is implemented via stub routines. That causes problems: >> >> - MacOs aarch64 has mechanisms to prevent execution of arbitrary non-text memory. On that platform, invoking generated code requires some awkward gymnastics [2]. These workarounds require access to Thread::current, which renders SafeFetch non-functional if Thread::current is NULL (e.g. crash reporting in "foreign" native threads or in a corrupted VM). They also cost a bit of performance on every SafeFetch invocation. Note that more OSes may implement similar execution prevention mechanics in the future. >> >> - There is a time window during VM initialization where the stubs are not generated yet and thus SafeFetch is not available. >> >> Both points cause hs-err files to be compromised (e.g. missing call stacks) for crashes in native threads, when the VM is corrupted, or early during VM initialization. Since SafeFetch is such a basic tool, it causes more issues than that (e.g., on AIX it is used for verifying mprotect() itself). But hs-err files being compromised by secondary errors is the most annoying effect. >> >> A minor point is that generating stubs takes a tiny bit of startup time. Not a big issue, but anything we can generate at build time instead of at runtime is good. >> >> --- >> >> The patch: >> >> - Removes the SafeFetch stub routine generation for all platforms >> - For Linux and MacOS, it implements SafeFetch as cpu-specific static assembler routines. These routines live in `os_cpu/_/safefetch__.S`. >> - On Windows, SafeFetch is implemented via SEH. This is beautifully simple and does not need handwritten assembly at all. See `os/windows/safefetch_windows.hpp`. >> - On Zero, SafeFetch uses a Posix compatible solution using `sigsetjmp(2)`. This is portable and robust, but a bit slow compared to the other methods. Note that this solution existed before, and is well tested. I just moved the code around and massaged it a bit. >> - AIX uses now the same method as Zero. AIX "downgraded" in that sense from the stub routine solution, but since SAP gave up maintenance of AIX, I don't have easy access to AIX hardware. If SafeFetch speed becomes an issue, I am sure a solution based on static assembly can be implemented on AIX too. >> - The SafeFetch gtests were greatly expanded. >> >> Tests: >> >> - The patch was tested manually by building and running gtests on: >> - MacOS (x64, aarch64) >> - Linux (aarch64, arm, ppcle, s390, x64, x86, riscv) >> - Windows (x64 and x86, but not arm, see below) >> - AIX >> - Zero (on Linux x64). >> - GHAs >> - The patch ran through SAP nightlies for several nights in a row >> >> Note: >> - I have no access to Windows arm, so I could not test it. I contacted @mo-beck to verify that the patch works there. >> - I have no access to BSD. I am not sure who maintains BSD, so I have no idea who to contact. However, I believe the MacOS solution should work for BSD too. If not, BSD can simply fall back to the Posix sigjmp solution like AIX and Zero. >> >> It would be nice to have @RealLucy, @TheRealMDoerr and @theRealAph to okay s390, ppcle and aarch64 (and possibly arm32). Each assembly file is tiny, so it should not take long. @RealFYang and @backwaterred already tested the patch on RiscV and AIX (thanks). >> >> Thanks, Thomas >> >> [1] https://github.com/openjdk/jdk/pull/7727#issuecomment-1064980598 >> [2] https://github.com/openjdk/jdk/blob/4df67426ed02f18af0757897acb28b636a317a91/src/hotspot/share/runtime/safefetch.inline.hpp#L37-L41 > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > re-add lost comment Happily, Microsoft reported back that my patch works on Windows aarch64 too. Since all other platforms are fine, I'll push. Thanks to @theRealAph for the idea, @fweimer-rh for the initial help, @dholmes-ora , @AntonKozlov , @TheRealMDoerr and @RealLucy for the reviews. This has been a fun little project. ------------- PR: https://git.openjdk.java.net/jdk/pull/7865 From stuefe at openjdk.java.net Fri Apr 15 10:41:45 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 15 Apr 2022 10:41:45 GMT Subject: Integrated: JDK-8283326: Implement SafeFetch statically In-Reply-To: References: Message-ID: On Fri, 18 Mar 2022 08:52:46 GMT, Thomas Stuefe wrote: > Hi, > > This is a reimplementation of SafeFetch to get rid of dynamic code generation. This is done, depending on platform, via static assembly, Posix setjmp/longjmp or SEH. > > This is based on a proposal by @theRealAph [1] when discussing [JDK-8282475](https://bugs.openjdk.java.net/browse/JDK-8282475). I extended the proposal to do this for all platforms, not just MacOS, see discussion below. > > --- > > Why we do this: > > SafeFetch is special: it is a basic utility function that may be called before the VM is properly initialized, from a "foreign" thread not attached to the VM, in a broken environment... mainly this is due to its use during stack walking, error reporting, hex dumping, etc. SafeFetch has to be safe to call under any circumstances - or as safe as we can make it. > > Today, SafeFetch is implemented via stub routines. That causes problems: > > - MacOs aarch64 has mechanisms to prevent execution of arbitrary non-text memory. On that platform, invoking generated code requires some awkward gymnastics [2]. These workarounds require access to Thread::current, which renders SafeFetch non-functional if Thread::current is NULL (e.g. crash reporting in "foreign" native threads or in a corrupted VM). They also cost a bit of performance on every SafeFetch invocation. Note that more OSes may implement similar execution prevention mechanics in the future. > > - There is a time window during VM initialization where the stubs are not generated yet and thus SafeFetch is not available. > > Both points cause hs-err files to be compromised (e.g. missing call stacks) for crashes in native threads, when the VM is corrupted, or early during VM initialization. Since SafeFetch is such a basic tool, it causes more issues than that (e.g., on AIX it is used for verifying mprotect() itself). But hs-err files being compromised by secondary errors is the most annoying effect. > > A minor point is that generating stubs takes a tiny bit of startup time. Not a big issue, but anything we can generate at build time instead of at runtime is good. > > --- > > The patch: > > - Removes the SafeFetch stub routine generation for all platforms > - For Linux and MacOS, it implements SafeFetch as cpu-specific static assembler routines. These routines live in `os_cpu/_/safefetch__.S`. > - On Windows, SafeFetch is implemented via SEH. This is beautifully simple and does not need handwritten assembly at all. See `os/windows/safefetch_windows.hpp`. > - On Zero, SafeFetch uses a Posix compatible solution using `sigsetjmp(2)`. This is portable and robust, but a bit slow compared to the other methods. Note that this solution existed before, and is well tested. I just moved the code around and massaged it a bit. > - AIX uses now the same method as Zero. AIX "downgraded" in that sense from the stub routine solution, but since SAP gave up maintenance of AIX, I don't have easy access to AIX hardware. If SafeFetch speed becomes an issue, I am sure a solution based on static assembly can be implemented on AIX too. > - The SafeFetch gtests were greatly expanded. > > Tests: > > - The patch was tested manually by building and running gtests on: > - MacOS (x64, aarch64) > - Linux (aarch64, arm, ppcle, s390, x64, x86, riscv) > - Windows (x64 and x86, but not arm, see below) > - AIX > - Zero (on Linux x64). > - GHAs > - The patch ran through SAP nightlies for several nights in a row > > Note: > - I have no access to Windows arm, so I could not test it. I contacted @mo-beck to verify that the patch works there. > - I have no access to BSD. I am not sure who maintains BSD, so I have no idea who to contact. However, I believe the MacOS solution should work for BSD too. If not, BSD can simply fall back to the Posix sigjmp solution like AIX and Zero. > > It would be nice to have @RealLucy, @TheRealMDoerr and @theRealAph to okay s390, ppcle and aarch64 (and possibly arm32). Each assembly file is tiny, so it should not take long. @RealFYang and @backwaterred already tested the patch on RiscV and AIX (thanks). > > Thanks, Thomas > > [1] https://github.com/openjdk/jdk/pull/7727#issuecomment-1064980598 > [2] https://github.com/openjdk/jdk/blob/4df67426ed02f18af0757897acb28b636a317a91/src/hotspot/share/runtime/safefetch.inline.hpp#L37-L41 This pull request has now been integrated. Changeset: bdf8a2a2 Author: Thomas Stuefe URL: https://git.openjdk.java.net/jdk/commit/bdf8a2a2050393e91800786f8d5a5d6805f936eb Stats: 1610 lines in 37 files changed: 973 ins; 565 del; 72 mod 8283326: Implement SafeFetch statically Reviewed-by: dholmes, mdoerr, akozlov, lucy ------------- PR: https://git.openjdk.java.net/jdk/pull/7865 From alanb at openjdk.java.net Fri Apr 15 11:45:01 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 15 Apr 2022 11:45:01 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v3] In-Reply-To: References: Message-ID: > This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. > > We will refresh this PR periodically to pick up changes and fixes from the loom repo. > > Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. > > The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. > > There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. > > The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. > > The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. Alan Bateman 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 five additional commits since the last revision: - Refresh - Refresh - Merge with jdk-19+18 - Refresh - Initial push ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8166/files - new: https://git.openjdk.java.net/jdk/pull/8166/files/0e12c206..f53f0d4e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8166&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8166&range=01-02 Stats: 148912 lines in 1502 files changed: 104901 ins; 9917 del; 34094 mod Patch: https://git.openjdk.java.net/jdk/pull/8166.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8166/head:pull/8166 PR: https://git.openjdk.java.net/jdk/pull/8166 From aturbanov at openjdk.java.net Fri Apr 15 12:34:47 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Fri, 15 Apr 2022 12:34:47 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v3] In-Reply-To: References: Message-ID: On Fri, 15 Apr 2022 11:45:01 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman 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 five additional commits since the last revision: > > - Refresh > - Refresh > - Merge with jdk-19+18 > - Refresh > - Initial push src/java.base/share/classes/jdk/internal/access/JavaUtilConcurrentTLRAccess.java line 29: > 27: > 28: public interface JavaUtilConcurrentTLRAccess { > 29: int nextSecondaryThreadLocalRandomSeed(); method seems unused now ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From alanb at openjdk.java.net Fri Apr 15 13:01:43 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 15 Apr 2022 13:01:43 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2] In-Reply-To: References: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com> Message-ID: <6wPsXjV1MP9Q86NWt2YOWecuHH0EXJwVjmPdA_baDFM=.56c7d00d-8169-4311-9d34-ac43e4ce64d0@github.com> On Thu, 14 Apr 2022 21:39:17 GMT, Paul Sandoz wrote: >> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: >> >> Refresh > > src/java.base/share/classes/java/lang/Thread.java line 862: > >> 860: * @param start the starting value of the counter >> 861: * @return this builder >> 862: * @throws IllegalArgumentException if count is negative > > Suggestion: > > * @throws IllegalArgumentException if start is negative Thanks, I think that dates from when the param was renamed. > src/java.base/share/classes/java/lang/VirtualThread.java line 65: > >> 63: * system. >> 64: */ >> 65: class VirtualThread extends Thread { > > Suggestion: > > final class VirtualThread extends Thread { okay. > src/java.base/share/classes/java/lang/VirtualThread.java line 94: > >> 92: * RUNNING -> PARKING // Thread attempts to park >> 93: * PARKING -> PARKED // yield successful, thread is parked >> 94: * PARKING -> PINNED // yield failed, thread is pinned > > Suggestion: > > * PARKING -> PARKED // parking successful, thread is parked > * PARKING -> PINNED // parking failed, thread is pinned The comment was about cont.yield, will change it to make it clearer. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From alanb at openjdk.java.net Fri Apr 15 13:01:43 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 15 Apr 2022 13:01:43 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v3] In-Reply-To: References: Message-ID: On Fri, 15 Apr 2022 12:31:24 GMT, Andrey Turbanov wrote: > method seems unused now It's used by the SL API, which will follow later. I realize this may sound complicated but it avoids more complicated splits. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From abhijangda at gmail.com Fri Apr 15 16:36:34 2022 From: abhijangda at gmail.com (Abhinav Jangda) Date: Fri, 15 Apr 2022 12:36:34 -0400 Subject: Creating a compressed heap graph Message-ID: Hi everyone, I am a PhD student at UMass Amherst. I am working on Hotspot in a research project. I have to create a compressed graph representation of the heap graph, where 1. each vertex in the compressed graph is a Java object (or array) allocated on heap, and 2. a directed edge between vertex v to u represents that u is the value of one of the fields (or element) of v. To create such a compressed graph on the fly, I need to look for two events happening in Hotspot: when a new object is created, and when a field of an object or an array element is set. I want to patch the generated code for these events, where a global counter declared in Hotspot is incremented and a new object address and field address are set to a memory location allocated in C heap. I have two questions regarding these: 1. Is it correct that InstanceKlass::allocate_instance is the function that allocates a new object in all compiler levels (Interpreter to most aggressive opt compiler)? 2. I have found that MacroAssembler::store_heap_oop is the function that generates code to store an object field to an object for the Interpreter. Is this correct and is this the case for all compiler levels? I understand that going through different cases is a lot of work and the final patched code might be un-optimized. Is there a way I can patch the bytecode in hotspot and add the code for global counter and setting values on C heap inside the bytecode? Is there a standardized way to write a pass over bytecode? Thanks a lot for the help. Please let me know about this. Thank You, Abhinav Jangda From cjplummer at openjdk.java.net Fri Apr 15 19:30:34 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Fri, 15 Apr 2022 19:30:34 GMT Subject: RFR: 8284903: Fix typos in hotspot In-Reply-To: References: Message-ID: On Fri, 15 Apr 2022 07:40:04 GMT, Magnus Ihse Bursie wrote: > I ran `codespell` on hotspot, and accepted those changes where it indeed discovered real typos. > > You'd be surprised over the many implementions of instrinsics and other intructions accross all archtectures I've encounted, so for the preceding reason it's neccesery to sucessfully seach for exisiting typos... I tried to cover all serviceability files, but didn't want to pick and choose individual files within any given directory, so I reviewed all files in any directory that contained a serviceability related file. So the following were covered by my review: src/os src/os_cpu src/share/prims src/share/services src/hotspot/share/prims/jvmtiThreadState.hpp line 136: > 134: ~JvmtiThreadState(); > 135: > 136: // is event_type enabled and usable for this thread in any environments? Should it be "environment"? src/hotspot/share/services/memTracker.hpp line 128: > 126: > 127: // Record arena size change. Arena size is the size of all arena > 128: // chunks that backing up the arena. This doesn't read correctly (not due to your change). Perhaps "that back up" or "that are backing up" is what was intended. ------------- Marked as reviewed by cjplummer (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8260 From psandoz at openjdk.java.net Fri Apr 15 20:43:57 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Fri, 15 Apr 2022 20:43:57 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2] In-Reply-To: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com> References: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com> Message-ID: <52LXUMJwDqrd_x_5VFbI9ZhmRGfKyc8XT5HB4p5JoXk=.482b750b-00d2-4b6b-aefe-4468c2bb6107@github.com> On Wed, 13 Apr 2022 14:21:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh src/java.base/share/classes/jdk/internal/misc/Blocker.java line 118: > 116: static long beginCompensatedBlock(ForkJoinPool pool) { > 117: try { > 118: return (long) beginCompensatedBlock.invoke(pool); Suggestion: return (long) beginCompensatedBlock.invokeExact(pool); src/java.base/share/classes/jdk/internal/misc/Blocker.java line 126: > 124: static void endCompensatedBlock(ForkJoinPool pool, long post) { > 125: try { > 126: endCompensatedBlock.invoke(pool, post); Suggestion: endCompensatedBlock.invokeExact(pool, post); ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From psandoz at openjdk.java.net Fri Apr 15 20:54:41 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Fri, 15 Apr 2022 20:54:41 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2] In-Reply-To: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com> References: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com> Message-ID: On Wed, 13 Apr 2022 14:21:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh src/java.base/share/classes/jdk/internal/misc/InternalLock.java line 46: > 44: } else { > 45: CAN_USE_INTERNAL_LOCK = true; > 46: } Suggestion: CAN_USE_INTERNAL_LOCK = Boolean.getBoolean("jdk.io.useMonitors"); ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From psandoz at openjdk.java.net Fri Apr 15 21:04:54 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Fri, 15 Apr 2022 21:04:54 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2] In-Reply-To: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com> References: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com> Message-ID: On Wed, 13 Apr 2022 14:21:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh src/java.base/share/classes/jdk/internal/misc/ThreadFlock.java line 262: > 260: * @return the thread, started > 261: * @throws IllegalStateException if this flock is shutdown or closed > 262: * @throws jdk.incubator.concurrent.StructureViolationException if the current Suggestion: * @throws WrongThreadException if the current thread is not the owner or a thread * contained in the flock * @throws jdk.incubator.concurrent.StructureViolationException if the current ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From psandoz at openjdk.java.net Fri Apr 15 21:14:56 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Fri, 15 Apr 2022 21:14:56 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2] In-Reply-To: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com> References: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com> Message-ID: On Wed, 13 Apr 2022 14:21:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh src/java.base/share/classes/jdk/internal/misc/ThreadTracker.java line 59: > 57: && this.thread == other.thread; > 58: } > 59: } Suggestion: private record ThreadRef(Thread thread) { @Override public int hashCode() { return Long.hashCode(thread.threadId()); } @Override public boolean equals(Object obj) { return (obj instanceof ThreadRef other) && this.thread == other.thread; } } ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From psandoz at openjdk.java.net Fri Apr 15 21:18:52 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Fri, 15 Apr 2022 21:18:52 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2] In-Reply-To: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com> References: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com> Message-ID: On Wed, 13 Apr 2022 14:21:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh src/java.base/share/classes/jdk/internal/vm/Continuation.java line 94: > 92: default: > 93: throw new AssertionError("Unknown pinned reason: " + reason); > 94: } Suggestion: return switch (reason) { case 2 -> Pinned.CRITICAL_SECTION; case 3 -> Pinned.NATIVE; case 4 -> Pinned.MONITOR; default -> throw new AssertionError("Unknown pinned reason: " + reason); }; ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From psandoz at openjdk.java.net Fri Apr 15 21:28:39 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Fri, 15 Apr 2022 21:28:39 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2] In-Reply-To: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com> References: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com> Message-ID: On Wed, 13 Apr 2022 14:21:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh src/java.base/share/classes/jdk/internal/vm/Continuation.java line 115: > 113: } > 114: > 115: private Runnable target; Can be final? (Does not appear to be updated by the VM, or via unsafe by some other class) ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From psandoz at openjdk.java.net Fri Apr 15 21:34:43 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Fri, 15 Apr 2022 21:34:43 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2] In-Reply-To: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com> References: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com> Message-ID: On Wed, 13 Apr 2022 14:21:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh src/java.base/share/classes/jdk/internal/vm/Continuation.java line 264: > 262: } finally { > 263: fence(); > 264: StackChunk c = tail; `c` is not used src/java.base/share/classes/jdk/internal/vm/Continuation.java line 310: > 308: > 309: @IntrinsicCandidate > 310: private static int doYield() { throw new Error("Intrinsic not installed"); }; Suggestion: private static int doYield() { throw new Error("Intrinsic not installed"); } ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From psandoz at openjdk.java.net Fri Apr 15 21:39:41 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Fri, 15 Apr 2022 21:39:41 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2] In-Reply-To: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com> References: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com> Message-ID: On Wed, 13 Apr 2022 14:21:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh src/java.base/share/classes/jdk/internal/vm/Continuation.java line 474: > 472: private void processNmethods(int before, int after) { > 473: > 474: } Unused field and method? ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From psandoz at openjdk.java.net Fri Apr 15 22:04:42 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Fri, 15 Apr 2022 22:04:42 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2] In-Reply-To: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com> References: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com> Message-ID: On Wed, 13 Apr 2022 14:21:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh src/java.base/share/classes/jdk/internal/vm/ThreadContainers.java line 184: > 182: * with the Thread API. > 183: */ > 184: private static class RootContainer extends ThreadContainer { This implementation could be clearer if split out into two, and the value assigned to `INSTANCE` is selected based on the system property. Something to consider later perhaps. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From psandoz at openjdk.java.net Fri Apr 15 22:13:43 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Fri, 15 Apr 2022 22:13:43 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2] In-Reply-To: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com> References: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com> Message-ID: On Wed, 13 Apr 2022 14:21:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh src/java.base/share/classes/jdk/internal/vm/annotation/ChangesCurrentThread.java line 35: > 33: * disables inlining for the method to which it is applied unless the > 34: * method being unlined into is also annotated ChangesCurrentThread. > 35: Suggestion: * method being inlined into is also annotated ChangesCurrentThread. * ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From stuefe at openjdk.java.net Sat Apr 16 06:00:40 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Sat, 16 Apr 2022 06:00:40 GMT Subject: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing [v9] In-Reply-To: References: Message-ID: On Fri, 15 Apr 2022 10:04:12 GMT, Johannes Bechberger wrote: > > Thanks for the JFR insight, Marcus. I can see the CrashProtection being a stop-gap measure under time constraints. Maybe worth rethinking now. From your description, the way it is used in JFR differ significantly from how the async-profiler would use it. > > I came to the same conclusion. Therefore I don't think that adding CrashProtection is worth the effort. > > > Privately, I start wondering whether the benefits of async-profiler over JFR are worth the risk of corrupting the VM or the work needed to harden out AGCT. Their feature-set seems to overlap a lot. I may not see the whole picture though, I'm not a profiler expert. > > ASGCT makes it possible to develop your own profiler. The implementation overlaps but the feature set does not. You cannot build your own profiler with JFR. AsyncProfiler has with ASGCT the possibility to capture call traces with different intervals that are related to perf-events which is not possible in JFR. > > ASGCT should be a best effort API that has its caveats, one of them being that it might crash the VM. I disagree on this one, partly because you a crash is not the worst that could happen, that would be data corruption due to some freakish causal chain. And partly because that crashiness of AGCT is little known outside our community, so customers are probably not aware of this risk. > I think the goal is to make ASGCT as safe as possible to use without altering the normal behaviour (and speed) of the VM. Calling the API should not alter anything on the heap or in any other data structures. This is also true for JFR and many stability fixes for ASGCT (like using SafeFetch in some places) should also benefit the stability of JFR. > > I therefore want to close this PR (and the related issue) and propose my "[Do not call JavaThread::thread_from_jni_environment](https://github.com/openjdk/jdk/pull/8225/commits/b16e85d2251ae8cf7433ff146ea209d094a37c8a)" commit in a new PR as adding PRs for all the errors I find in JFR and ASGCT seems to be the way forward. Sounds reasonable. I'm sorry for frustrating your efforts here. Cheers, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/8225 From duke at openjdk.java.net Sat Apr 16 07:10:35 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Sat, 16 Apr 2022 07:10:35 GMT Subject: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing [v9] In-Reply-To: References: Message-ID: On Sat, 16 Apr 2022 05:56:51 GMT, Thomas Stuefe wrote: > I disagree on this one, partly because you a crash is not the worst that could happen, that would be data corruption due to some freakish causal chain. Of course, but it is in reality far harder to test for. But ideally, ASGCT does never use a method that does alter state, at the expense that it might sometimes discard results. Even methods that modify caches (or comparable data structures) are problematic. I want to do a manual code analysis in the next few weeks of all code called by ASGCT (not just the parts that differ from JFR) to check whether this is true. > And partly because that crashiness of AGCT is little known outside our community, so customers are probably not aware of this risk. I don't think so, the problem are more transitive users that use a tool like AsyncProfiler that might crash their VM (or corrupt the data). > Sounds reasonable. I'm sorry for frustrating your efforts here. At least I learned something. ------------- PR: https://git.openjdk.java.net/jdk/pull/8225 From duke at openjdk.java.net Sat Apr 16 07:10:35 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Sat, 16 Apr 2022 07:10:35 GMT Subject: Withdrawn: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing In-Reply-To: References: Message-ID: On Wed, 13 Apr 2022 14:53:54 GMT, Johannes Bechberger wrote: > Move the AsyncGetCallTrace method implementation into a separate method and wrap its call in non-assert compilation mode in `os::ThreadCrashProtection` like it is done in [JFR](https://github.com/openjdk/jdk/blob/965ea8d9cd29aee41ba2b1b0b0c67bb67eca22dd/src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp#L165). > This prevents AsyncGetCallTrace from crashing on segmentation faults (but not on `guarantee`s). > > If a crash is observed, then the `num_frames` field of the trace is set to `ticks_unknown_state` (-7) to signal a state that cannot be properly handled. `ticks_unknown_state` is currently also used for signaling unknown thread states but this should not be a problem, as the semantic is the same. If `num_frames` already has an error code then this error code is not changed. This helps to distinguish between errors in walking threads in Java and non-Java mode, as `num_frames` is set there before the walking to the appropriate error code. > > _Thanks for @tstuefe for suggesting this._ This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/8225 From jpai at openjdk.java.net Sat Apr 16 09:28:42 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Sat, 16 Apr 2022 09:28:42 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v3] In-Reply-To: References: Message-ID: On Fri, 15 Apr 2022 11:45:01 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman 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 five additional commits since the last revision: > > - Refresh > - Refresh > - Merge with jdk-19+18 > - Refresh > - Initial push src/java.base/share/classes/java/io/BufferedOutputStream.java line 136: > 134: * are added. A no-op if the buffer is not resizable. > 135: */ > 136: private void growIfNeeded(int len) { Hello Alan, like some methods in other classes (BufferedInputStream#fill() for example), should we mention here that this method assumes that it's being called while a lock is held? ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From jpai at openjdk.java.net Sat Apr 16 10:32:42 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Sat, 16 Apr 2022 10:32:42 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v3] In-Reply-To: References: Message-ID: On Fri, 15 Apr 2022 11:45:01 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman 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 five additional commits since the last revision: > > - Refresh > - Refresh > - Merge with jdk-19+18 > - Refresh > - Initial push src/java.base/share/classes/jdk/internal/misc/Blocker.java line 76: > 74: && currentCarrierThread() instanceof CarrierThread ct && !ct.inBlocking()) { > 75: ct.beginBlocking(); > 76: long comp = ForkJoinPools.beginCompensatedBlock(ct.getPool()); It appears that `ForkJoinPools.beginCompensatedBlock(...)` can throw an exception. Would such an exception require the CarrierThread's blocking state (which we set on the previous line) to be reset by a call to `ct.endBlocking()`? Or is it futile to reset that state if any exception gets thrown from the call to `ForkJoinPools.beginCompensatedBlock(...)`? src/java.base/share/classes/jdk/internal/misc/Blocker.java line 94: > 92: > 93: /** > 94: * Marks the end an operation that may have blocked. I think this should have been "Marks the end of an ..." ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From jpai at openjdk.java.net Sat Apr 16 11:09:36 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Sat, 16 Apr 2022 11:09:36 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v3] In-Reply-To: References: Message-ID: On Fri, 15 Apr 2022 11:45:01 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman 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 five additional commits since the last revision: > > - Refresh > - Refresh > - Merge with jdk-19+18 > - Refresh > - Initial push src/java.base/share/classes/java/io/FilterInputStream.java line 233: > 231: */ > 232: @Override > 233: public void reset() throws IOException { I suspect this change to remove synchronization from `mark()` and `reset()` is intentional. The `FilterInputStream` class doesn't explain the thread safety semantics, nor can I find commit history which would hint on why these (and only these) methods were syncrhonized. But it looks like this synchronization was there to serialize calls to `mark()` and `reset()` on the same `FilterInputStream` from multiple threads. With this synchronization now removed, subclasses or even direct usages of `FilterInputStream` would now be impacted. Potentially outside of the JDK. Would that be a concern? ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From dnsimon at openjdk.java.net Sat Apr 16 12:02:52 2022 From: dnsimon at openjdk.java.net (Doug Simon) Date: Sat, 16 Apr 2022 12:02:52 GMT Subject: RFR: 8242440: use separate, destroyable JavaVM instances per libgraal compiler thread Message-ID: Currently, libgraal runs in a single, permanent JavaVM instance loaded from libjvmcicompiler.so. This poses 2 problems: 1. The memory used for libgraal is never released, even when the libgraal compiler queues are idle. 2. Since all libgraal HotSpot compiler threads share the same SVM heap, libgraal compilation is effectively paused when a GC occurs (SVM currently has a stop the world collector). The more compiler threads there are, the more often this happens. This PR implements the following solution to these problems: 1. Create a new JavaVM instance per libgraal compiler thread (i.e. a separate SVM isolate per thread). This prevents GC in one libgraal thread from impacting another libgraal thread. 2. Destroy the JavaVM instances when a libgraal compiler thread becomes idle and create a new one when subsequent compilation requests arrive. Most of the changes are in JVMCI specific files. The most significant change to shared code is the addition of the `JavaThread:: _libjvmci_runtime` field. This is required as any thread (not just a `CompilerThread`) can be associated with a specific `JVMCIRuntime` object. ------------- Commit messages: - add support for multiple libjvmci runtimes Changes: https://git.openjdk.java.net/jdk/pull/8262/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8262&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8242440 Stats: 1008 lines in 22 files changed: 812 ins; 74 del; 122 mod Patch: https://git.openjdk.java.net/jdk/pull/8262.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8262/head:pull/8262 PR: https://git.openjdk.java.net/jdk/pull/8262 From alanb at openjdk.java.net Sat Apr 16 14:26:43 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Sat, 16 Apr 2022 14:26:43 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2] In-Reply-To: <52LXUMJwDqrd_x_5VFbI9ZhmRGfKyc8XT5HB4p5JoXk=.482b750b-00d2-4b6b-aefe-4468c2bb6107@github.com> References: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com> <52LXUMJwDqrd_x_5VFbI9ZhmRGfKyc8XT5HB4p5JoXk=.482b750b-00d2-4b6b-aefe-4468c2bb6107@github.com> Message-ID: On Fri, 15 Apr 2022 20:39:51 GMT, Paul Sandoz wrote: >> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: >> >> Refresh > > src/java.base/share/classes/jdk/internal/misc/Blocker.java line 126: > >> 124: static void endCompensatedBlock(ForkJoinPool pool, long post) { >> 125: try { >> 126: endCompensatedBlock.invoke(pool, post); > > Suggestion: > > endCompensatedBlock.invokeExact(pool, post); Yes, that would be better. > src/java.base/share/classes/jdk/internal/misc/InternalLock.java line 46: > >> 44: } else { >> 45: CAN_USE_INTERNAL_LOCK = true; >> 46: } > > Suggestion: > > CAN_USE_INTERNAL_LOCK = Boolean.getBoolean("jdk.io.useMonitors"); This doesn't work for the empty string case as it would map to true rather than false. So I think we leave this as is. > src/java.base/share/classes/jdk/internal/misc/ThreadFlock.java line 262: > >> 260: * @return the thread, started >> 261: * @throws IllegalStateException if this flock is shutdown or closed >> 262: * @throws jdk.incubator.concurrent.StructureViolationException if the current > > Suggestion: > > * @throws WrongThreadException if the current thread is not the owner or a thread > * contained in the flock > * @throws jdk.incubator.concurrent.StructureViolationException if the current Thanks, I think this slipped in when moving the SL API to the incubator module. It should be IllegalThreadStateException if the thread has already started, and WrongThreadException if not the owner (or flock). > src/java.base/share/classes/jdk/internal/misc/ThreadTracker.java line 59: > >> 57: && this.thread == other.thread; >> 58: } >> 59: } > > Suggestion: > > private record ThreadRef(Thread thread) { > @Override > public int hashCode() { > return Long.hashCode(thread.threadId()); > } > > @Override > public boolean equals(Object obj) { > return (obj instanceof ThreadRef other) > && this.thread == other.thread; > } > } Yes, this can be a record. > src/java.base/share/classes/jdk/internal/vm/annotation/ChangesCurrentThread.java line 35: > >> 33: * disables inlining for the method to which it is applied unless the >> 34: * method being unlined into is also annotated ChangesCurrentThread. >> 35: > > Suggestion: > > * method being inlined into is also annotated ChangesCurrentThread. > * Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From alanb at openjdk.java.net Sat Apr 16 14:33:46 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Sat, 16 Apr 2022 14:33:46 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v3] In-Reply-To: References: Message-ID: <3DUMJmZ230xIecn-FP1iApMRFsr21tD2OGfZ-Sg2_Uc=.65d0cb79-e651-406c-aaa9-859937051963@github.com> On Sat, 16 Apr 2022 10:29:36 GMT, Jaikiran Pai wrote: >> Alan Bateman 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 five additional commits since the last revision: >> >> - Refresh >> - Refresh >> - Merge with jdk-19+18 >> - Refresh >> - Initial push > > src/java.base/share/classes/jdk/internal/misc/Blocker.java line 94: > >> 92: >> 93: /** >> 94: * Marks the end an operation that may have blocked. > > I think this should have been "Marks the end of an ..." Yes, there's a typo there - thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From alanb at openjdk.java.net Sat Apr 16 14:37:44 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Sat, 16 Apr 2022 14:37:44 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v3] In-Reply-To: References: Message-ID: On Sat, 16 Apr 2022 10:25:56 GMT, Jaikiran Pai wrote: >> Alan Bateman 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 five additional commits since the last revision: >> >> - Refresh >> - Refresh >> - Merge with jdk-19+18 >> - Refresh >> - Initial push > > src/java.base/share/classes/jdk/internal/misc/Blocker.java line 76: > >> 74: && currentCarrierThread() instanceof CarrierThread ct && !ct.inBlocking()) { >> 75: ct.beginBlocking(); >> 76: long comp = ForkJoinPools.beginCompensatedBlock(ct.getPool()); > > It appears that `ForkJoinPools.beginCompensatedBlock(...)` can throw an exception. Would such an exception require the CarrierThread's blocking state (which we set on the previous line) to be reset by a call to `ct.endBlocking()`? Or is it futile to reset that state if any exception gets thrown from the call to `ForkJoinPools.beginCompensatedBlock(...)`? REE isn't possible here but maybe you mean a resource issues such as stack overflow or OOME. If that happens then the flag wouldn't be reset. It wouldn't a corrects issue but we may be able to make this a bit more robust for these cases. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From duke at openjdk.java.net Sat Apr 16 14:45:40 2022 From: duke at openjdk.java.net (ExE Boss) Date: Sat, 16 Apr 2022 14:45:40 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2] In-Reply-To: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com> References: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com> Message-ID: On Wed, 13 Apr 2022 14:21:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh src/java.base/share/classes/jdk/internal/misc/Blocker.java line 111: > 109: methodType = MethodType.methodType(void.class, long.class); > 110: endCompensatedBlock = l.findVirtual(ForkJoinPool.class, "endCompensatedBlock", methodType); > 111: This?can?use `SharedSecrets.getJavaLangInvokeAccess()` in?order to?avoid?using `privateLookupIn(?)` and?`AccessController.doPrivileged(?)`. Suggestion: JavaLangInvokeAccess JLIA = SharedSecrets.getJavaLangInvokeAccess(); MethodType methodType = MethodType.methodType(long.class); beginCompensatedBlock = JLIA.findVirtual(ForkJoinPool.class, "beginCompensatedBlock", methodType); if (beginCompensatedBlock == null) { throw new NoSuchMethodException(ForkJoinPool.class + ".beginCompensatedBlock" + methodType); } methodType = MethodType.methodType(void.class, long.class); endCompensatedBlock = JLIA.findVirtual(ForkJoinPool.class, "endCompensatedBlock", methodType); if (endCompensatedBlock == null) { throw new NoSuchMethodException(ForkJoinPool.class + ".endCompensatedBlock" + methodType); } ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From alanb at openjdk.java.net Sat Apr 16 15:02:45 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Sat, 16 Apr 2022 15:02:45 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v3] In-Reply-To: References: Message-ID: On Sat, 16 Apr 2022 11:05:47 GMT, Jaikiran Pai wrote: >> Alan Bateman 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 five additional commits since the last revision: >> >> - Refresh >> - Refresh >> - Merge with jdk-19+18 >> - Refresh >> - Initial push > > src/java.base/share/classes/java/io/FilterInputStream.java line 233: > >> 231: */ >> 232: @Override >> 233: public void reset() throws IOException { > > I suspect this change to remove synchronization from `mark()` and `reset()` is intentional. The `FilterInputStream` class doesn't explain the thread safety semantics, nor can I find commit history which would hint on why these (and only these) methods were syncrhonized. But it looks like this synchronization was there to serialize calls to `mark()` and `reset()` on the same `FilterInputStream` from multiple threads. With this synchronization now removed, subclasses or even direct usages of `FilterInputStream` would now be impacted. Potentially outside of the JDK. Would that be a concern? Yes, this is intentional but it would be great to split out this change and get them into the main line in advance. There is a JEP size task required to re-visit all of the locking in java.io. In the case of the input/output streams, most of it is not documented and there are several inconsistencies. In the case of FilterInputStream, it doesn't use synchronization for the other ops. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From alanb at openjdk.java.net Sat Apr 16 15:02:47 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Sat, 16 Apr 2022 15:02:47 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2] In-Reply-To: References: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com> Message-ID: <6Y07wh7rpLs5SDolUCKoYqjmlst-6TKw03RpPubm0bM=.4401cd6d-e80a-48f9-bce2-77e9c757e4b2@github.com> On Sat, 16 Apr 2022 12:31:41 GMT, ExE Boss wrote: >> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: >> >> Refresh > > src/java.base/share/classes/jdk/internal/misc/Blocker.java line 111: > >> 109: methodType = MethodType.methodType(void.class, long.class); >> 110: endCompensatedBlock = l.findVirtual(ForkJoinPool.class, "endCompensatedBlock", methodType); >> 111: > > This?can?use `SharedSecrets.getJavaLangInvokeAccess()` in?order to?avoid?using `privateLookupIn(?)` and?`AccessController.doPrivileged(?)`. > > Suggestion: > > JavaLangInvokeAccess JLIA = SharedSecrets.getJavaLangInvokeAccess(); > MethodType methodType = MethodType.methodType(long.class); > beginCompensatedBlock = JLIA.findVirtual(ForkJoinPool.class, "beginCompensatedBlock", methodType); > if (beginCompensatedBlock == null) { > throw new NoSuchMethodException(ForkJoinPool.class + ".beginCompensatedBlock" + methodType); > } > methodType = MethodType.methodType(void.class, long.class); > endCompensatedBlock = JLIA.findVirtual(ForkJoinPool.class, "endCompensatedBlock", methodType); > if (endCompensatedBlock == null) { > throw new NoSuchMethodException(ForkJoinPool.class + ".endCompensatedBlock" + methodType); > } I think we may just eliminate the reflection use and use a shared secret instead. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From alanb at openjdk.java.net Sat Apr 16 15:02:49 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Sat, 16 Apr 2022 15:02:49 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2] In-Reply-To: References: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com> Message-ID: On Fri, 15 Apr 2022 22:01:10 GMT, Paul Sandoz wrote: >> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: >> >> Refresh > > src/java.base/share/classes/jdk/internal/vm/ThreadContainers.java line 184: > >> 182: * with the Thread API. >> 183: */ >> 184: private static class RootContainer extends ThreadContainer { > > This implementation could be clearer if split out into two, and the value assigned to `INSTANCE` is selected based on the system property. Something to consider later perhaps. We've been undecided on whether to just track all threads. If we do that then there would be only one implementation. But yes, if we continue with two then they should be split out. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From alanb at openjdk.java.net Sat Apr 16 15:59:48 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Sat, 16 Apr 2022 15:59:48 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v3] In-Reply-To: References: Message-ID: On Sat, 16 Apr 2022 09:25:20 GMT, Jaikiran Pai wrote: >> Alan Bateman 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 five additional commits since the last revision: >> >> - Refresh >> - Refresh >> - Merge with jdk-19+18 >> - Refresh >> - Initial push > > src/java.base/share/classes/java/io/BufferedOutputStream.java line 136: > >> 134: * are added. A no-op if the buffer is not resizable. >> 135: */ >> 136: private void growIfNeeded(int len) { > > Hello Alan, like some methods in other classes (BufferedInputStream#fill() for example), should we mention here that this method assumes that it's being called while a lock is held? Okay, we can add a comment to these methods (asserts are possible but tend not to be used in this area). ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From dholmes at openjdk.java.net Sun Apr 17 02:28:35 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Sun, 17 Apr 2022 02:28:35 GMT Subject: RFR: 8242440: use separate, destroyable JavaVM instances per libgraal compiler thread In-Reply-To: References: Message-ID: On Fri, 15 Apr 2022 13:29:43 GMT, Doug Simon wrote: > Currently, libgraal runs in a single, permanent JavaVM instance loaded from libjvmcicompiler.so. This poses 2 problems: > > 1. The memory used for libgraal is never released, even when the libgraal compiler queues are idle. > 2. Since all libgraal HotSpot compiler threads share the same SVM heap, libgraal compilation is effectively paused when a GC occurs (SVM currently has a stop the world collector). The more compiler threads there are, the more often this happens. > > This PR implements the following solution to these problems: > 1. Create a new JavaVM instance per libgraal compiler thread (i.e. a separate SVM isolate per thread). This prevents GC in one libgraal thread from impacting another libgraal thread. > 2. Destroy the JavaVM instances when a libgraal compiler thread becomes idle and create a new one when subsequent compilation requests arrive. > > Most of the changes are in JVMCI specific files. The most significant change to shared code is the addition of the `JavaThread:: _libjvmci_runtime` field. This is required as any thread (not just a `CompilerThread`) can be associated with a specific `JVMCIRuntime` object. src/hotspot/share/compiler/abstractCompiler.hpp line 170: > 168: // Notifies this compiler that the current thread (`thread`) is about to stop. > 169: // The current thread currently holds the CompileThread_lock. > 170: virtual void stopping_compiler_thread(CompilerThread* thread) { If `thread` is the current thread then I'd recommend calling it `current` so that this is clear. ------------- PR: https://git.openjdk.java.net/jdk/pull/8262 From jpai at openjdk.java.net Sun Apr 17 03:34:35 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Sun, 17 Apr 2022 03:34:35 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v3] In-Reply-To: References: Message-ID: On Sat, 16 Apr 2022 14:34:01 GMT, Alan Bateman wrote: >> src/java.base/share/classes/jdk/internal/misc/Blocker.java line 76: >> >>> 74: && currentCarrierThread() instanceof CarrierThread ct && !ct.inBlocking()) { >>> 75: ct.beginBlocking(); >>> 76: long comp = ForkJoinPools.beginCompensatedBlock(ct.getPool()); >> >> It appears that `ForkJoinPools.beginCompensatedBlock(...)` can throw an exception. Would such an exception require the CarrierThread's blocking state (which we set on the previous line) to be reset by a call to `ct.endBlocking()`? Or is it futile to reset that state if any exception gets thrown from the call to `ForkJoinPools.beginCompensatedBlock(...)`? > > REE isn't possible here but maybe you mean a resource issues such as stack overflow or OOME. If that happens then the flag wouldn't be reset. It wouldn't a correctness issue but we may be able to make this a bit more robust for these cases. Hello Alan, My concern wasn't really about OOME or resource issue. I had noticed the `ForkJoinPools.beginCompensatedBlock` has a try/catch which then propagates back the `Throwable`. So I thought there could be some genuine exceptions that could be thrown in this flow which ultimately calls `ForkJoinPool.beginCompensatedBlock()`. I haven't yet reached the changes in `ForkJoinPool.java` class itself, so it's likely that this catch block is only there for theoretical reasons when dealing with `MethodHandle`. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From jpai at openjdk.java.net Sun Apr 17 03:52:49 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Sun, 17 Apr 2022 03:52:49 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v3] In-Reply-To: References: Message-ID: On Fri, 15 Apr 2022 11:45:01 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman 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 five additional commits since the last revision: > > - Refresh > - Refresh > - Merge with jdk-19+18 > - Refresh > - Initial push src/java.base/share/classes/java/io/PrintStream.java line 1420: > 1418: } else { > 1419: synchronized (this) { > 1420: implFormat(format, args); I think there's a typo here. I think it should have been: implFormat(l, format, args); ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From jpai at openjdk.java.net Sun Apr 17 05:00:40 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Sun, 17 Apr 2022 05:00:40 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v3] In-Reply-To: References: Message-ID: On Fri, 15 Apr 2022 11:45:01 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman 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 five additional commits since the last revision: > > - Refresh > - Refresh > - Merge with jdk-19+18 > - Refresh > - Initial push src/java.base/share/classes/java/lang/StackTraceElement.java line 556: > 554: } > 555: > 556: static StackTraceElement[] of(StackTraceElement[] stackTrace) { Is it intentional that this method is returning a `StackTraceElement[]` instead of `void`. The current implementation just returns back the passed array after operating on each element. Are callers mandated to use the returned array for subsequent operations instead of the passed array? ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From kbarrett at openjdk.java.net Sun Apr 17 05:39:33 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Sun, 17 Apr 2022 05:39:33 GMT Subject: RFR: 8242440: use separate, destroyable JavaVM instances per libgraal compiler thread In-Reply-To: References: Message-ID: <2-IBy0ERqZXykr2FcvJzq2gi5zmQsN_5h3iNZcCvrtU=.5039ed2d-fedf-45f4-8b7e-56c76c06f474@github.com> On Fri, 15 Apr 2022 13:29:43 GMT, Doug Simon wrote: > Currently, libgraal runs in a single, permanent JavaVM instance loaded from libjvmcicompiler.so. This poses 2 problems: > > 1. The memory used for libgraal is never released, even when the libgraal compiler queues are idle. > 2. Since all libgraal HotSpot compiler threads share the same SVM heap, libgraal compilation is effectively paused when a GC occurs (SVM currently has a stop the world collector). The more compiler threads there are, the more often this happens. > > This PR implements the following solution to these problems: > 1. Create a new JavaVM instance per libgraal compiler thread (i.e. a separate SVM isolate per thread). This prevents GC in one libgraal thread from impacting another libgraal thread. > 2. Destroy the JavaVM instances when a libgraal compiler thread becomes idle and create a new one when subsequent compilation requests arrive. > > Most of the changes are in JVMCI specific files. The most significant change to shared code is the addition of the `JavaThread:: _libjvmci_runtime` field. This is required as any thread (not just a `CompilerThread`) can be associated with a specific `JVMCIRuntime` object. I've only carefully looked at the runtime changes; only skimming the jvmci and compiler parts. src/hotspot/share/jvmci/jvmciRuntime.cpp line 905: > 903: object_handles()->release(ptrs, released); > 904: } > 905: _jobjects->clear(); `clear` doesn't free any memory from the growable-array, so a runtime's _jobjects will have a capacity based on the high-water usage. I don't know if that's intentional. I was going to suggest using `GrowableArray::clear_and_deallocate()` if not, but the initialization of the array specifies a non-zero initial capacity (100). src/hotspot/share/jvmci/jvmciRuntime.cpp line 975: > 973: > 974: JVMCIRuntime::JVMCIRuntime(JVMCIRuntime* next, int id, bool for_compile_broker) { > 975: _init_state = uninitialized; Why is this constructor using assignments rather than a ctor-initializer? There's lots of old code that doesn't, and the Style Guide doesn't require it (yet - https://bugs.openjdk.java.net/browse/JDK-8252586), but that's the trend (and generally considered best practice). src/hotspot/share/jvmci/jvmciRuntime.cpp line 976: > 974: JVMCIRuntime::JVMCIRuntime(JVMCIRuntime* next, int id, bool for_compile_broker) { > 975: _init_state = uninitialized; > 976: _shared_library_javavm = NULL; Prefer nullptr to NULL in new code. src/hotspot/share/jvmci/jvmciRuntime.cpp line 1185: > 1183: JNIEnv* JVMCIRuntime::init_shared_library_javavm() { > 1184: MutexLocker locker(_lock); > 1185: JavaVM* javaVM = (JavaVM*) _shared_library_javavm; Pointless cast. src/hotspot/share/jvmci/jvmciRuntime.hpp line 168: > 166: // destroying remaining JNI handles when the JavaVM associated > 167: // with this runtime is shutdown. > 168: GrowableArray* _jobjects; I think _jobjects should be a nested object rather than a pointer. src/hotspot/share/jvmci/jvmciRuntime.hpp line 168: > 166: // destroying remaining JNI handles when the JavaVM associated > 167: // with this runtime is shutdown. > 168: GrowableArray* _jobjects; I wonder if it would simplify anything to use OopHandle instead of jobject as the element type? src/hotspot/share/jvmci/jvmciRuntime.hpp line 177: > 175: int _num_attached_threads; > 176: enum { > 177: cannot_be_attached = -1 // See _num_attached_threads We no longer use enums (with unspecified type) to define constants. Use `static const` instead. (There's lots of old code that still does this, but new code should not.) src/hotspot/share/runtime/mutexLocker.hpp line 151: > 149: > 150: #if INCLUDE_JVMCI > 151: #define JVMCIRuntime_lock_rank safepoint This shouldn't be a macro. Use `const Mutex::Rank JVMCIRuntime_lock_rank = safepoint;`. src/hotspot/share/runtime/thread.hpp line 1230: > 1228: JVMCIRuntime* libjvmci_runtime() const { return _libjvmci_runtime; } > 1229: void set_libjvmci_runtime(JVMCIRuntime* rt) { > 1230: assert((_libjvmci_runtime == NULL && rt != NULL) || (_libjvmci_runtime != NULL && rt == NULL), "must be"); Prefer nullptr to NULL in new code. ------------- Changes requested by kbarrett (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8262 From jpai at openjdk.java.net Sun Apr 17 06:19:48 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Sun, 17 Apr 2022 06:19:48 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v3] In-Reply-To: References: Message-ID: On Fri, 15 Apr 2022 11:45:01 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman 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 five additional commits since the last revision: > > - Refresh > - Refresh > - Merge with jdk-19+18 > - Refresh > - Initial push src/java.base/share/classes/java/lang/Thread.java line 602: > 600: } else { > 601: // getContextClassLoader not trusted > 602: ClassLoader cl = parent.contextClassLoader; I might be misreading the comment on that line, but reading this if/else block a few times, I'm unsure what the expectations here are. It's my understanding that a call to `getContextClassLoader()` can't be trusted if that method has been overridden by the passed `Thread` type. In such cases, we don't call that method and instead just use the field value of `contextClassLoader` (which is a private field on `Thread`). Is that understanding correct? If yes, then the condition in the `if` block a few lines above, looks odd. It seems to be calling the `getContextClassLoader()` if that method is overridden by the passed `Thread` type, i.e. the untrusted case. Should it instead be: if (sm == null || !isCCLOverridden(parent.getClass())) { return parent.getContextClassLoader(); } (notice the negation) ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From alanb at openjdk.java.net Sun Apr 17 06:58:42 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Sun, 17 Apr 2022 06:58:42 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v3] In-Reply-To: References: Message-ID: On Sun, 17 Apr 2022 03:49:19 GMT, Jaikiran Pai wrote: >> Alan Bateman 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 five additional commits since the last revision: >> >> - Refresh >> - Refresh >> - Merge with jdk-19+18 >> - Refresh >> - Initial push > > src/java.base/share/classes/java/io/PrintStream.java line 1420: > >> 1418: } else { >> 1419: synchronized (this) { >> 1420: implFormat(format, args); > > I think there's a typo here. I think it should have been: > > > implFormat(l, format, args); Well spotted, the locale should be provided. > src/java.base/share/classes/java/lang/Thread.java line 602: > >> 600: } else { >> 601: // getContextClassLoader not trusted >> 602: ClassLoader cl = parent.contextClassLoader; > > I might be misreading the comment on that line, but reading this if/else block a few times, I'm unsure what the expectations here are. > > It's my understanding that a call to `getContextClassLoader()` can't be trusted if that method has been overridden by the passed `Thread` type. In such cases, we don't call that method and instead just use the field value of `contextClassLoader` (which is a private field on `Thread`). Is that understanding correct? If yes, then the condition in the `if` block a few lines above, looks odd. It seems to be calling the `getContextClassLoader()` if that method is overridden by the passed `Thread` type, i.e. the untrusted case. Should it instead be: > > if (sm == null || !isCCLOverridden(parent.getClass())) { > return parent.getContextClassLoader(); > } > > (notice the negation) This code hasn't changed, it's just moved to a helper method. When running with a security manager and the CCL methods aren't overridden, then it avoids the permission check. However, I can see how the comment is mis-reading so we can improve that. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From dnsimon at openjdk.java.net Sun Apr 17 09:02:37 2022 From: dnsimon at openjdk.java.net (Doug Simon) Date: Sun, 17 Apr 2022 09:02:37 GMT Subject: RFR: 8242440: use separate, destroyable JavaVM instances per libgraal compiler thread In-Reply-To: <2-IBy0ERqZXykr2FcvJzq2gi5zmQsN_5h3iNZcCvrtU=.5039ed2d-fedf-45f4-8b7e-56c76c06f474@github.com> References: <2-IBy0ERqZXykr2FcvJzq2gi5zmQsN_5h3iNZcCvrtU=.5039ed2d-fedf-45f4-8b7e-56c76c06f474@github.com> Message-ID: <4Z8M1GtFQgERjYfj-kxr71iv4et4BThMtFqQmHbYJLg=.26978688-ac3f-4fa1-b42e-64da2579390e@github.com> On Sun, 17 Apr 2022 04:42:44 GMT, Kim Barrett wrote: >> Currently, libgraal runs in a single, permanent JavaVM instance loaded from libjvmcicompiler.so. This poses 2 problems: >> >> 1. The memory used for libgraal is never released, even when the libgraal compiler queues are idle. >> 2. Since all libgraal HotSpot compiler threads share the same SVM heap, libgraal compilation is effectively paused when a GC occurs (SVM currently has a stop the world collector). The more compiler threads there are, the more often this happens. >> >> This PR implements the following solution to these problems: >> 1. Create a new JavaVM instance per libgraal compiler thread (i.e. a separate SVM isolate per thread). This prevents GC in one libgraal thread from impacting another libgraal thread. >> 2. Destroy the JavaVM instances when a libgraal compiler thread becomes idle and create a new one when subsequent compilation requests arrive. >> >> Most of the changes are in JVMCI specific files. The most significant change to shared code is the addition of the `JavaThread:: _libjvmci_runtime` field. This is required as any thread (not just a `CompilerThread`) can be associated with a specific `JVMCIRuntime` object. > > src/hotspot/share/jvmci/jvmciRuntime.cpp line 905: > >> 903: object_handles()->release(ptrs, released); >> 904: } >> 905: _jobjects->clear(); > > `clear` doesn't free any memory from the growable-array, so a runtime's _jobjects will have a capacity based on the high-water usage. I don't know if that's intentional. I was going to suggest using `GrowableArray::clear_and_deallocate()` if not, but the initialization of the array specifies a non-zero initial capacity (100). It's expected that libgraal isolates have roughly the same pattern in terms of jobject allocation so keeping the memory around is intentional. > src/hotspot/share/jvmci/jvmciRuntime.cpp line 976: > >> 974: JVMCIRuntime::JVMCIRuntime(JVMCIRuntime* next, int id, bool for_compile_broker) { >> 975: _init_state = uninitialized; >> 976: _shared_library_javavm = NULL; > > Prefer nullptr to NULL in new code. Thanks for the reminder. I'm tempted to now change `NULL` to `nullptr` in all `jvmci/*` files. What's the policy/recommendation on that? Don't bother/separate PR/piggy-back on this PR? > src/hotspot/share/jvmci/jvmciRuntime.hpp line 168: > >> 166: // destroying remaining JNI handles when the JavaVM associated >> 167: // with this runtime is shutdown. >> 168: GrowableArray* _jobjects; > > I wonder if it would simplify anything to use OopHandle instead of jobject as the element type? Interesting proposal. What would be the advantage of `OopHandle` over `jobject`? That require a bunch of `reinterpret_cast`ing between `jobject` and `OopHandle` which I'm not sure is even possible? > src/hotspot/share/runtime/mutexLocker.hpp line 151: > >> 149: >> 150: #if INCLUDE_JVMCI >> 151: #define JVMCIRuntime_lock_rank safepoint > > This shouldn't be a macro. Use `const Mutex::Rank JVMCIRuntime_lock_rank = safepoint;`. Thanks. This suggestion actually helps me clean up the code by allocating a global `JVMCIRuntime_lock` instead (associated with the first `JVMCIRuntime` created) and using it as a prototype for the lock when subsequent `JVMCIRuntime`s are created. ------------- PR: https://git.openjdk.java.net/jdk/pull/8262 From dnsimon at openjdk.java.net Sun Apr 17 09:07:40 2022 From: dnsimon at openjdk.java.net (Doug Simon) Date: Sun, 17 Apr 2022 09:07:40 GMT Subject: RFR: 8242440: use separate, destroyable JavaVM instances per libgraal compiler thread In-Reply-To: <2-IBy0ERqZXykr2FcvJzq2gi5zmQsN_5h3iNZcCvrtU=.5039ed2d-fedf-45f4-8b7e-56c76c06f474@github.com> References: <2-IBy0ERqZXykr2FcvJzq2gi5zmQsN_5h3iNZcCvrtU=.5039ed2d-fedf-45f4-8b7e-56c76c06f474@github.com> Message-ID: On Sun, 17 Apr 2022 05:22:09 GMT, Kim Barrett wrote: >> Currently, libgraal runs in a single, permanent JavaVM instance loaded from libjvmcicompiler.so. This poses 2 problems: >> >> 1. The memory used for libgraal is never released, even when the libgraal compiler queues are idle. >> 2. Since all libgraal HotSpot compiler threads share the same SVM heap, libgraal compilation is effectively paused when a GC occurs (SVM currently has a stop the world collector). The more compiler threads there are, the more often this happens. >> >> This PR implements the following solution to these problems: >> 1. Create a new JavaVM instance per libgraal compiler thread (i.e. a separate SVM isolate per thread). This prevents GC in one libgraal thread from impacting another libgraal thread. >> 2. Destroy the JavaVM instances when a libgraal compiler thread becomes idle and create a new one when subsequent compilation requests arrive. >> >> Most of the changes are in JVMCI specific files. The most significant change to shared code is the addition of the `JavaThread:: _libjvmci_runtime` field. This is required as any thread (not just a `CompilerThread`) can be associated with a specific `JVMCIRuntime` object. > > src/hotspot/share/jvmci/jvmciRuntime.cpp line 1185: > >> 1183: JNIEnv* JVMCIRuntime::init_shared_library_javavm() { >> 1184: MutexLocker locker(_lock); >> 1185: JavaVM* javaVM = (JavaVM*) _shared_library_javavm; > > Pointless cast. Without that cast, I get this compiler error: ------------- PR: https://git.openjdk.java.net/jdk/pull/8262 From jpai at openjdk.java.net Sun Apr 17 12:42:49 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Sun, 17 Apr 2022 12:42:49 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v3] In-Reply-To: References: Message-ID: On Fri, 15 Apr 2022 11:45:01 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman 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 five additional commits since the last revision: > > - Refresh > - Refresh > - Merge with jdk-19+18 > - Refresh > - Initial push src/java.base/share/classes/java/lang/Thread.java line 1554: > 1552: * Null out reference after Thread termination (JDK-4006245) > 1553: */ > 1554: void clearReferences() { I had a look at the referenced [JDK-4006245](https://bugs.openjdk.java.net/browse/JDK-4006245). The previous/existing reference cleaning logic seems to have been added mainly to `null` the reference to the user/application class instance represented by the `Runnable` task. Of course, other references too were being cleared. The description in the linked JBS seems to suggest that the `Thread` instance wasn't being GCed sooner. That was more than 2 decades back. I don't have enough knowledge of this area to know if this is still an issue in recent GC implementations. With the new implementation in this PR, this `clearReferences()` will no longer set the user/application `task` instance to `null`. I understand why we aren't doing that - the `task` field in the `FieldHolder` is `final` (IMO, rightly so). This, in theory, undoes what JDK-4006245 had implemented. I don't know if we still need such a change here and I'm just bringing this up to see if anyone else has any opinions or if any additional experiments need to be run in context of this change. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From jpai at openjdk.java.net Sun Apr 17 13:36:49 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Sun, 17 Apr 2022 13:36:49 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v3] In-Reply-To: References: Message-ID: On Fri, 15 Apr 2022 11:45:01 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman 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 five additional commits since the last revision: > > - Refresh > - Refresh > - Merge with jdk-19+18 > - Refresh > - Initial push src/java.base/share/classes/java/lang/Thread.java line 2414: > 2412: sm.checkPermission(new RuntimePermission("setContextClassLoader")); > 2413: } > 2414: if (!isSupportedClassLoader(contextClassLoader)) { For a few moments, I thought this was a typo and should instead have been: if (!isSupportedClassLoader(cl)) { but then thinking a bit more, I realized what's being done here. Essentially, this checks whether the _current_ context classloader is set to "not allowed to change/set context classloader" (represented by `Constants.NOT_SUPPORTED_CLASSLOADER`). Do you think this line deserves some short code comment that it intentionally passes the current contextClassLoader (and not the one passed to the method) to `isSupportedClassLoader`? ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From alanb at openjdk.java.net Sun Apr 17 16:03:30 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Sun, 17 Apr 2022 16:03:30 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v4] In-Reply-To: References: Message-ID: <_TWRNeLakN4zFnF3jIC_2ezkgvSzl-9O5xtV7qI-NDA=.b07a1c1a-edc1-4078-b580-a065a28a7b1f@github.com> > This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. > > We will refresh this PR periodically to pick up changes and fixes from the loom repo. > > Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. > > The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. > > There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. > > The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. > > The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: Refresh ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8166/files - new: https://git.openjdk.java.net/jdk/pull/8166/files/f53f0d4e..ff1ef712 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8166&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8166&range=02-03 Stats: 1517 lines in 74 files changed: 1034 ins; 311 del; 172 mod Patch: https://git.openjdk.java.net/jdk/pull/8166.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8166/head:pull/8166 PR: https://git.openjdk.java.net/jdk/pull/8166 From alanb at openjdk.java.net Sun Apr 17 16:03:31 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Sun, 17 Apr 2022 16:03:31 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v3] In-Reply-To: References: Message-ID: On Sun, 17 Apr 2022 12:39:24 GMT, Jaikiran Pai wrote: > I had a look at the referenced [JDK-4006245](https://bugs.openjdk.java.net/browse/JDK-4006245). The previous/existing reference cleaning logic seems to have been added mainly to `null` the reference to the user/application class instance represented by the `Runnable` task. Of course, other references too were being cleared. The description in the linked JBS seems to suggest that the `Thread` instance wasn't being GCed sooner. That was more than 2 decades back. I don't have enough knowledge of this area to know if this is still an issue in recent GC implementations. The comment on that method dates from early JDK releases with the Classic VM and its conservative GC. It also predates the java.lang.ref API. The question that I think you are asking is if you create a Thread with a runnable task, let it terminate but keep the reference to the Thread forever then what does it keep alive. We can think about more but so far we haven't seen any issues or tests fail with the reference to the runnable task. > src/java.base/share/classes/java/lang/Thread.java line 2414: > >> 2412: sm.checkPermission(new RuntimePermission("setContextClassLoader")); >> 2413: } >> 2414: if (!isSupportedClassLoader(contextClassLoader)) { > > For a few moments, I thought this was a typo and should instead have been: > > if (!isSupportedClassLoader(cl)) { > > but then thinking a bit more, I realized what's being done here. Essentially, this checks whether the _current_ context classloader is set to "not allowed to change/set context classloader" (represented by `Constants.NOT_SUPPORTED_CLASSLOADER`). > > Do you think this line deserves some short code comment that it intentionally passes the current contextClassLoader (and not the one passed to the method) to `isSupportedClassLoader`? I think the comment on isSupportedClassLoader is readable so I think it's okay. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From alanb at openjdk.java.net Sun Apr 17 16:03:32 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Sun, 17 Apr 2022 16:03:32 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2] In-Reply-To: References: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com> Message-ID: On Fri, 15 Apr 2022 21:15:45 GMT, Paul Sandoz wrote: >> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: >> >> Refresh > > src/java.base/share/classes/jdk/internal/vm/Continuation.java line 94: > >> 92: default: >> 93: throw new AssertionError("Unknown pinned reason: " + reason); >> 94: } > > Suggestion: > > return switch (reason) { > case 2 -> Pinned.CRITICAL_SECTION; > case 3 -> Pinned.NATIVE; > case 4 -> Pinned.MONITOR; > default -> throw new AssertionError("Unknown pinned reason: " + reason); > }; That would be clearer (I think this predates switch expressions). ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From eliu at openjdk.java.net Mon Apr 18 03:30:45 2022 From: eliu at openjdk.java.net (Eric Liu) Date: Mon, 18 Apr 2022 03:30:45 GMT Subject: RFR: 8284563: AArch64: bitperm feature detection for SVE2 on Linux In-Reply-To: <-tRedEjmlUXfwqLEQz7GWKiy64cAcOKCXXZEkl7EnpY=.7d1d300a-0350-4283-a400-85d685bb2238@github.com> References: <-tRedEjmlUXfwqLEQz7GWKiy64cAcOKCXXZEkl7EnpY=.7d1d300a-0350-4283-a400-85d685bb2238@github.com> Message-ID: On Fri, 15 Apr 2022 09:59:47 GMT, Ningsheng Jian wrote: >> This patch adds BITPERM feature detection for SVE2 on Linux. BITPERM is >> an optional feature in SVE2 [1]. It enables 3 SVE2 instructions (BEXT, >> BDEP, BGRP). BEXT and BDEP map efficiently to some vector operations, >> e.g., the compress and expand functionalities [2] which are proposed in >> VectorAPI's 4th incubation [3]. Besides, to generate specific code based >> on different architecture features like x86, this patch exports >> VM_Version::supports_XXX() for all CPU features. E.g., >> VM_Version::supports_svebitperm() for easy use. >> >> This patch also fixes a trivial bug, that sets UseSVE back to 1 if it's >> 2 in SVE1 system. >> >> [1] https://developer.arm.com/documentation/ddi0601/2022-03/AArch64-Registers/ID-AA64ZFR0-EL1--SVE-Feature-ID-register-0 >> [2] https://bugs.openjdk.java.net/browse/JDK-8283893 >> [3] https://bugs.openjdk.java.net/browse/JDK-8280173 > > src/hotspot/cpu/aarch64/vm_version_aarch64.hpp line 132: > >> 130: // Feature identification >> 131: #define CPU_FEATURE_DETECTION(id, name, bit) \ >> 132: static bool supports_##name() { return (_features & CPU_##id) != 0; }; > > Having supports_a53mac() looks a bit weird to me. Yeah, I was thinking this before. Indeed, A53MAC and STXR_PREFETCH are not CPU feature. Considering that some codes depend on that, it's acceptable to me leaving them here at this moment. ------------- PR: https://git.openjdk.java.net/jdk/pull/8258 From kbarrett at openjdk.java.net Mon Apr 18 04:42:51 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Mon, 18 Apr 2022 04:42:51 GMT Subject: RFR: 8242440: use separate, destroyable JavaVM instances per libgraal compiler thread In-Reply-To: References: <2-IBy0ERqZXykr2FcvJzq2gi5zmQsN_5h3iNZcCvrtU=.5039ed2d-fedf-45f4-8b7e-56c76c06f474@github.com> Message-ID: On Sun, 17 Apr 2022 09:04:10 GMT, Doug Simon wrote: >> src/hotspot/share/jvmci/jvmciRuntime.cpp line 1185: >> >>> 1183: JNIEnv* JVMCIRuntime::init_shared_library_javavm() { >>> 1184: MutexLocker locker(_lock); >>> 1185: JavaVM* javaVM = (JavaVM*) _shared_library_javavm; >> >> Pointless cast. > > Without that cast, I get this compiler error: I forgot that `_shared_library_javavm` is declared `volatile JavaVM*`. So what's needed is a const_cast to discard the volatile. But why is it pointer to volatile? I'm not seeing any reason for that; the out argument for `JNI_CreateJavaVM` doesn't specify volatile. I wonder if it's supposed to instead be `JavaVM* volatile` to (attempt to, though maybe not correctly) support unlocked reads with concurrent locked writes? ------------- PR: https://git.openjdk.java.net/jdk/pull/8262 From kbarrett at openjdk.java.net Mon Apr 18 04:48:38 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Mon, 18 Apr 2022 04:48:38 GMT Subject: RFR: 8242440: use separate, destroyable JavaVM instances per libgraal compiler thread In-Reply-To: <4Z8M1GtFQgERjYfj-kxr71iv4et4BThMtFqQmHbYJLg=.26978688-ac3f-4fa1-b42e-64da2579390e@github.com> References: <2-IBy0ERqZXykr2FcvJzq2gi5zmQsN_5h3iNZcCvrtU=.5039ed2d-fedf-45f4-8b7e-56c76c06f474@github.com> <4Z8M1GtFQgERjYfj-kxr71iv4et4BThMtFqQmHbYJLg=.26978688-ac3f-4fa1-b42e-64da2579390e@github.com> Message-ID: On Sun, 17 Apr 2022 08:58:23 GMT, Doug Simon wrote: >> src/hotspot/share/jvmci/jvmciRuntime.cpp line 976: >> >>> 974: JVMCIRuntime::JVMCIRuntime(JVMCIRuntime* next, int id, bool for_compile_broker) { >>> 975: _init_state = uninitialized; >>> 976: _shared_library_javavm = NULL; >> >> Prefer nullptr to NULL in new code. > > Thanks for the reminder. I'm tempted to now change `NULL` to `nullptr` in all `jvmci/*` files. What's the policy/recommendation on that? Don't bother/separate PR/piggy-back on this PR? I think most folks have been taking a nullptr in new code approach, without anyone doing substantial conversions. Though Leo did look at a wholesale conversion at one point (it turned out to be a little premature, since we didn't really have nullptr yet). There are some places where there are strange overload games being played because NULL is an unadorned `0` on some platforms, and I think Leo found some places where the selected overload was even wrong because of that. I certainly wouldn't a wholesale conversion of JVMCI as part of this PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/8262 From kbarrett at openjdk.java.net Mon Apr 18 04:52:38 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Mon, 18 Apr 2022 04:52:38 GMT Subject: RFR: 8242440: use separate, destroyable JavaVM instances per libgraal compiler thread In-Reply-To: <4Z8M1GtFQgERjYfj-kxr71iv4et4BThMtFqQmHbYJLg=.26978688-ac3f-4fa1-b42e-64da2579390e@github.com> References: <2-IBy0ERqZXykr2FcvJzq2gi5zmQsN_5h3iNZcCvrtU=.5039ed2d-fedf-45f4-8b7e-56c76c06f474@github.com> <4Z8M1GtFQgERjYfj-kxr71iv4et4BThMtFqQmHbYJLg=.26978688-ac3f-4fa1-b42e-64da2579390e@github.com> Message-ID: On Sun, 17 Apr 2022 08:58:37 GMT, Doug Simon wrote: >> src/hotspot/share/jvmci/jvmciRuntime.hpp line 168: >> >>> 166: // destroying remaining JNI handles when the JavaVM associated >>> 167: // with this runtime is shutdown. >>> 168: GrowableArray* _jobjects; >> >> I wonder if it would simplify anything to use OopHandle instead of jobject as the element type? > > Interesting proposal. What would be the advantage of `OopHandle` over `jobject`? That require a bunch of `reinterpret_cast`ing between `jobject` and `OopHandle` which I'm not sure is even possible? The suggestion was about managing the handles and associated values (and I'm not even sure it would help there). But maybe `jobject` is too deeply embedded in JVMCI usage? Or maybe there are places where it really needs to be using `jobject` rather than `oop*` or a thin wrapper over `oop*` like `OopHandle`? ------------- PR: https://git.openjdk.java.net/jdk/pull/8262 From njian at openjdk.java.net Mon Apr 18 06:35:30 2022 From: njian at openjdk.java.net (Ningsheng Jian) Date: Mon, 18 Apr 2022 06:35:30 GMT Subject: RFR: 8284563: AArch64: bitperm feature detection for SVE2 on Linux In-Reply-To: References: <-tRedEjmlUXfwqLEQz7GWKiy64cAcOKCXXZEkl7EnpY=.7d1d300a-0350-4283-a400-85d685bb2238@github.com> Message-ID: On Mon, 18 Apr 2022 03:27:18 GMT, Eric Liu wrote: >> src/hotspot/cpu/aarch64/vm_version_aarch64.hpp line 132: >> >>> 130: // Feature identification >>> 131: #define CPU_FEATURE_DETECTION(id, name, bit) \ >>> 132: static bool supports_##name() { return (_features & CPU_##id) != 0; }; >> >> Having supports_a53mac() looks a bit weird to me. > > Yeah, I was thinking this before. Indeed, A53MAC and STXR_PREFETCH are not CPU feature. Considering that some codes depend on that, it's acceptable to me leaving them here at this moment. OK. Then could you also update the usages of these two `features` with your new functions? ------------- PR: https://git.openjdk.java.net/jdk/pull/8258 From duke at openjdk.java.net Mon Apr 18 06:53:40 2022 From: duke at openjdk.java.net (KIRIYAMA Takuya) Date: Mon, 18 Apr 2022 06:53:40 GMT Subject: RFR: 8280761: UseCompressedOops should be set after limit_heap_by_allocatable_memory [v6] In-Reply-To: References: Message-ID: On Thu, 14 Apr 2022 06:33:55 GMT, KIRIYAMA Takuya wrote: >> I fixed to set UseCompressedOops flag after limit_heap_by_allocatable_memory(). >> So when ulimit -v is called and -XX:MaxRAM is set, UseCompressedOops does not become false. >> And all hotspot tier1 test are passed. >> Would you please review this fix? > > KIRIYAMA Takuya has updated the pull request incrementally with one additional commit since the last revision: > > 8280761 UseCompressedOops should be set after limit_heap_by_allocatable_memory I appreciate all reviews. I hope this change is integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/7938 From dholmes at openjdk.java.net Mon Apr 18 06:58:39 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 18 Apr 2022 06:58:39 GMT Subject: RFR: 8242440: use separate, destroyable JavaVM instances per libgraal compiler thread In-Reply-To: References: Message-ID: On Fri, 15 Apr 2022 13:29:43 GMT, Doug Simon wrote: > Currently, libgraal runs in a single, permanent JavaVM instance loaded from libjvmcicompiler.so. This poses 2 problems: > > 1. The memory used for libgraal is never released, even when the libgraal compiler queues are idle. > 2. Since all libgraal HotSpot compiler threads share the same SVM heap, libgraal compilation is effectively paused when a GC occurs (SVM currently has a stop the world collector). The more compiler threads there are, the more often this happens. > > This PR implements the following solution to these problems: > 1. Create a new JavaVM instance per libgraal compiler thread (i.e. a separate SVM isolate per thread). This prevents GC in one libgraal thread from impacting another libgraal thread. > 2. Destroy the JavaVM instances when a libgraal compiler thread becomes idle and create a new one when subsequent compilation requests arrive. > > Most of the changes are in JVMCI specific files. The most significant change to shared code is the addition of the `JavaThread:: _libjvmci_runtime` field. This is required as any thread (not just a `CompilerThread`) can be associated with a specific `JVMCIRuntime` object. @dougxc I am not clear on what you are doing here, as we don't support loading the JVM more than once per-process and "destroying" a JVM doesn't return a lot of the resources you might expect to be returned. ------------- PR: https://git.openjdk.java.net/jdk/pull/8262 From aph at openjdk.java.net Mon Apr 18 08:11:49 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Mon, 18 Apr 2022 08:11:49 GMT Subject: RFR: 8284563: AArch64: bitperm feature detection for SVE2 on Linux In-Reply-To: References: <-tRedEjmlUXfwqLEQz7GWKiy64cAcOKCXXZEkl7EnpY=.7d1d300a-0350-4283-a400-85d685bb2238@github.com> Message-ID: On Mon, 18 Apr 2022 06:32:06 GMT, Ningsheng Jian wrote: >> Yeah, I was thinking this before. Indeed, A53MAC and STXR_PREFETCH are not CPU feature. Considering that some codes depend on that, it's acceptable to me leaving them here at this moment. > > OK. Then could you also update the usages of these two `features` with your new functions? `STXR_PREFETCH` is usually done unconditionally in non-JVM code. Does it ever hurt performance? If not, let's get rid of `STXR_PREFETCH` and do prefetching unconditionally. ------------- PR: https://git.openjdk.java.net/jdk/pull/8258 From dnsimon at openjdk.java.net Mon Apr 18 08:21:16 2022 From: dnsimon at openjdk.java.net (Doug Simon) Date: Mon, 18 Apr 2022 08:21:16 GMT Subject: RFR: 8242440: use separate, destroyable JavaVM instances per libgraal compiler thread In-Reply-To: References: Message-ID: On Mon, 18 Apr 2022 06:55:07 GMT, David Holmes wrote: > @dougxc I am not clear on what you are doing here, as we don't support loading the JVM more than once per-process and "destroying" a JVM doesn't return a lot of the resources you might expect to be returned. The JavaVM instances being managed here are separate from the HotSpot JavaVM instance. The former each encapsulate a single SubstrateVM runtime. If you look at `JVMCIRuntime::init_shared_library_javavm`, you'll see that it [calls `JNI_CreateJavaVM` in `libjvmcicompiler.so`](https://github.com/openjdk/jdk/pull/8262/files#diff-f6b79d39a54fc627561d67d22fb07d30eed6dac79520f44016d0019106fde58dR1225). There is one of these (lazily created) SubstrateVM JavaVMs per JVMCIRuntime and they are destroyed when the last thread detaches from a JVMCIRuntime. Destroying these JavaVM instances releases a lot of resources (e.g. a whole SubstrateVM GC heap). ------------- PR: https://git.openjdk.java.net/jdk/pull/8262 From dnsimon at openjdk.java.net Mon Apr 18 09:16:33 2022 From: dnsimon at openjdk.java.net (Doug Simon) Date: Mon, 18 Apr 2022 09:16:33 GMT Subject: RFR: 8242440: use separate, destroyable JavaVM instances per libgraal compiler thread In-Reply-To: References: <2-IBy0ERqZXykr2FcvJzq2gi5zmQsN_5h3iNZcCvrtU=.5039ed2d-fedf-45f4-8b7e-56c76c06f474@github.com> Message-ID: On Mon, 18 Apr 2022 04:39:48 GMT, Kim Barrett wrote: >> Without that cast, I get this compiler error: > > I forgot that `_shared_library_javavm` is declared `volatile JavaVM*`. So what's needed is a const_cast to discard the volatile. But why is it pointer to volatile? I'm not seeing any reason for that; the out argument for `JNI_CreateJavaVM` doesn't specify volatile. I wonder if it's supposed to instead be `JavaVM* volatile` to (attempt to, though maybe not correctly) support unlocked reads with concurrent locked writes? It is declared volatile for correct double checked locking in the code prior to this PR: JNIEnv* JVMCIRuntime::init_shared_library_javavm() { JavaVM* javaVM = (JavaVM*) _shared_library_javavm; if (javaVM == NULL) { MutexLocker locker(JVMCI_lock); // Check again under JVMCI_lock javaVM = (JavaVM*) _shared_library_javavm; if (javaVM != NULL) { return NULL; } However, now that `JVMCIRuntime::_lock` is acquired at the entry to `JVMCIRuntime::init_shared_library_javavm` there is indeed no longer a need for it to be volatile. ------------- PR: https://git.openjdk.java.net/jdk/pull/8262 From dnsimon at openjdk.java.net Mon Apr 18 09:22:34 2022 From: dnsimon at openjdk.java.net (Doug Simon) Date: Mon, 18 Apr 2022 09:22:34 GMT Subject: RFR: 8242440: use separate, destroyable JavaVM instances per libgraal compiler thread In-Reply-To: References: <2-IBy0ERqZXykr2FcvJzq2gi5zmQsN_5h3iNZcCvrtU=.5039ed2d-fedf-45f4-8b7e-56c76c06f474@github.com> <4Z8M1GtFQgERjYfj-kxr71iv4et4BThMtFqQmHbYJLg=.26978688-ac3f-4fa1-b42e-64da2579390e@github.com> Message-ID: On Mon, 18 Apr 2022 04:45:24 GMT, Kim Barrett wrote: >> Thanks for the reminder. I'm tempted to now change `NULL` to `nullptr` in all `jvmci/*` files. What's the policy/recommendation on that? Don't bother/separate PR/piggy-back on this PR? > > I think most folks have been taking a nullptr in new code approach, without anyone doing substantial conversions. Though Leo did look at a wholesale conversion at one point (it turned out to be a little premature, since we didn't really have nullptr yet). There are some places where there are strange overload games being played because NULL is an unadorned `0` on some platforms, and I think Leo found some places where the selected overload was even wrong because of that. I certainly wouldn't a wholesale conversion of JVMCI as part of this PR. Ok, I'll take this opportunity to convert some JVMCI code to `nullptr` and do more in subsequent PRs. ------------- PR: https://git.openjdk.java.net/jdk/pull/8262 From eliu at openjdk.java.net Mon Apr 18 10:58:39 2022 From: eliu at openjdk.java.net (Eric Liu) Date: Mon, 18 Apr 2022 10:58:39 GMT Subject: RFR: 8284563: AArch64: bitperm feature detection for SVE2 on Linux [v2] In-Reply-To: References: Message-ID: > This patch adds BITPERM feature detection for SVE2 on Linux. BITPERM is > an optional feature in SVE2 [1]. It enables 3 SVE2 instructions (BEXT, > BDEP, BGRP). BEXT and BDEP map efficiently to some vector operations, > e.g., the compress and expand functionalities [2] which are proposed in > VectorAPI's 4th incubation [3]. Besides, to generate specific code based > on different architecture features like x86, this patch exports > VM_Version::supports_XXX() for all CPU features. E.g., > VM_Version::supports_svebitperm() for easy use. > > This patch also fixes a trivial bug, that sets UseSVE back to 1 if it's > 2 in SVE1 system. > > [1] https://developer.arm.com/documentation/ddi0601/2022-03/AArch64-Registers/ID-AA64ZFR0-EL1--SVE-Feature-ID-register-0 > [2] https://bugs.openjdk.java.net/browse/JDK-8283893 > [3] https://bugs.openjdk.java.net/browse/JDK-8280173 Eric Liu has updated the pull request incrementally with one additional commit since the last revision: small fix Change-Id: Ida979f925055761ad73e50655d0584dcee24aea4 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8258/files - new: https://git.openjdk.java.net/jdk/pull/8258/files/1cfec16e..70fa72a0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8258&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8258&range=00-01 Stats: 8 lines in 3 files changed: 0 ins; 0 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/8258.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8258/head:pull/8258 PR: https://git.openjdk.java.net/jdk/pull/8258 From eliu at openjdk.java.net Mon Apr 18 11:09:57 2022 From: eliu at openjdk.java.net (Eric Liu) Date: Mon, 18 Apr 2022 11:09:57 GMT Subject: RFR: 8284563: AArch64: bitperm feature detection for SVE2 on Linux [v2] In-Reply-To: References: <-tRedEjmlUXfwqLEQz7GWKiy64cAcOKCXXZEkl7EnpY=.7d1d300a-0350-4283-a400-85d685bb2238@github.com> Message-ID: <3OeWzDWpqTTXni22O2BI6_02fNzH7h4px1cr7S5t_JQ=.34ad7e4e-cb79-4f1a-8ed1-16b4414f0da4@github.com> On Mon, 18 Apr 2022 08:08:00 GMT, Andrew Haley wrote: >> OK. Then could you also update the usages of these two `features` with your new functions? > > `STXR_PREFETCH` is usually done unconditionally in non-JVM code. Does it ever hurt performance? If not, let's get rid of `STXR_PREFETCH` and do prefetching unconditionally. @theRealAph TBH I don't know the history about this code. Considering that may impact the performance, I don't have too much confidence to dispose of it in this patch. Do you think it's fine to trace it in a separate JBS? ------------- PR: https://git.openjdk.java.net/jdk/pull/8258 From duke at openjdk.java.net Mon Apr 18 12:22:56 2022 From: duke at openjdk.java.net (ExE Boss) Date: Mon, 18 Apr 2022 12:22:56 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v4] In-Reply-To: <_TWRNeLakN4zFnF3jIC_2ezkgvSzl-9O5xtV7qI-NDA=.b07a1c1a-edc1-4078-b580-a065a28a7b1f@github.com> References: <_TWRNeLakN4zFnF3jIC_2ezkgvSzl-9O5xtV7qI-NDA=.b07a1c1a-edc1-4078-b580-a065a28a7b1f@github.com> Message-ID: On Sun, 17 Apr 2022 16:03:30 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh src/java.base/share/classes/jdk/internal/misc/ThreadFlock.java line 266: > 264: * contained in the flock > 265: * @throws jdk.incubator.concurrent.StructureViolationException if the current > 266: * scope-local bindings are not the same as when the flock was created Suggestion: * scope-local bindings are not the same as when the flock was created ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From coleenp at openjdk.java.net Mon Apr 18 18:00:40 2022 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Mon, 18 Apr 2022 18:00:40 GMT Subject: RFR: 8284903: Fix typos in hotspot In-Reply-To: References: Message-ID: On Fri, 15 Apr 2022 07:40:04 GMT, Magnus Ihse Bursie wrote: > I ran `codespell` on hotspot, and accepted those changes where it indeed discovered real typos. > > You'd be surprised over the many implementions of instrinsics and other intructions accross all archtectures I've encounted, so for the preceding reason it's neccesery to sucessfully seach for exisiting typos... I checked all directories except gc, jfr, metaspace, opto and jvmti. It's surprising that there aren't more typos. The changes to each file are tiny (one word to three words). ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8260 From kvn at openjdk.java.net Mon Apr 18 18:40:40 2022 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Mon, 18 Apr 2022 18:40:40 GMT Subject: RFR: 8284903: Fix typos in hotspot In-Reply-To: References: Message-ID: <0CKX2hdjVTCzFrtYznCHOfTWFFkRvKBfQilIOETpBK4=.b72aaefe-d6c6-4a2e-ba29-cc6198576d91@github.com> On Fri, 15 Apr 2022 07:40:04 GMT, Magnus Ihse Bursie wrote: > I ran `codespell` on hotspot, and accepted those changes where it indeed discovered real typos. > > You'd be surprised over the many implementions of instrinsics and other intructions accross all archtectures I've encounted, so for the preceding reason it's neccesery to sucessfully seach for exisiting typos... Nice work! I reviewed compiler related code: `cpu`, `os`, `os_cpu`, `share/adlc`, `share/c1`, `share/ci`, `share/code`, `share/compiler`, `share/jvmci`, `share/opto`. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8260 From kbarrett at openjdk.java.net Mon Apr 18 20:58:27 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Mon, 18 Apr 2022 20:58:27 GMT Subject: RFR: 8242440: use separate, destroyable JavaVM instances per libgraal compiler thread In-Reply-To: References: <2-IBy0ERqZXykr2FcvJzq2gi5zmQsN_5h3iNZcCvrtU=.5039ed2d-fedf-45f4-8b7e-56c76c06f474@github.com> Message-ID: On Mon, 18 Apr 2022 09:13:22 GMT, Doug Simon wrote: >> I forgot that `_shared_library_javavm` is declared `volatile JavaVM*`. So what's needed is a const_cast to discard the volatile. But why is it pointer to volatile? I'm not seeing any reason for that; the out argument for `JNI_CreateJavaVM` doesn't specify volatile. I wonder if it's supposed to instead be `JavaVM* volatile` to (attempt to, though maybe not correctly) support unlocked reads with concurrent locked writes? > > It is declared volatile for correct double checked locking in the code prior to this PR: > > JNIEnv* JVMCIRuntime::init_shared_library_javavm() { > JavaVM* javaVM = (JavaVM*) _shared_library_javavm; > if (javaVM == NULL) { > MutexLocker locker(JVMCI_lock); > // Check again under JVMCI_lock > javaVM = (JavaVM*) _shared_library_javavm; > if (javaVM != NULL) { > return NULL; > } > > However, now that `JVMCIRuntime::_lock` is acquired at the entry to `JVMCIRuntime::init_shared_library_javavm` there is indeed no longer a need for it to be volatile. The declaration was wrong for that usage - it should have been "volatile pointer to X" (`JavaVM* volatile`) but was declared "pointer to volatile X" (`volatile JavaVM*`). That also wasn't a correct implementation of DCLP. Good thing you are changing this. So yes, the volatile should be nuked and this cast and the similar one in destroy_shared_library_javavm can be removed. ------------- PR: https://git.openjdk.java.net/jdk/pull/8262 From mchung at openjdk.java.net Mon Apr 18 22:49:43 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Mon, 18 Apr 2022 22:49:43 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v4] In-Reply-To: <_TWRNeLakN4zFnF3jIC_2ezkgvSzl-9O5xtV7qI-NDA=.b07a1c1a-edc1-4078-b580-a065a28a7b1f@github.com> References: <_TWRNeLakN4zFnF3jIC_2ezkgvSzl-9O5xtV7qI-NDA=.b07a1c1a-edc1-4078-b580-a065a28a7b1f@github.com> Message-ID: On Sun, 17 Apr 2022 16:03:30 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh src/java.management/share/classes/java/lang/management/ThreadMXBean.java line 655: > 653: * synchronization control. It might be an expensive operation. > 654: * Its behavior with cycles involving virtual threads is not defined > 655: * in this release. What does the current implementation return if the virtual threads are involved in a deadlock? The class spec says "ThreadMXBean does not support monitoring or management of virtual threads" while this javadoc says it's undefined. I wonder if it's helpful to include `@implNote` if appropriate. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From mchung at openjdk.java.net Tue Apr 19 00:09:37 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 19 Apr 2022 00:09:37 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v4] In-Reply-To: <_TWRNeLakN4zFnF3jIC_2ezkgvSzl-9O5xtV7qI-NDA=.b07a1c1a-edc1-4078-b580-a065a28a7b1f@github.com> References: <_TWRNeLakN4zFnF3jIC_2ezkgvSzl-9O5xtV7qI-NDA=.b07a1c1a-edc1-4078-b580-a065a28a7b1f@github.com> Message-ID: On Sun, 17 Apr 2022 16:03:30 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh src/java.base/share/classes/java/lang/ref/ReferenceQueue.java line 206: > 204: throws IllegalArgumentException, InterruptedException { > 205: if (timeout < 0) throw new IllegalArgumentException("Negative timeout value"); > 206: if (timeout == 0) return remove(); Nit: use the same formatting as in `NativeReferenceQueue::remove` and in this file. if (timeout < 0) throw new IllegalArgumentException("Negative timeout value"); if (timeout == 0) return remove(); ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From dholmes at openjdk.java.net Tue Apr 19 00:26:42 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 19 Apr 2022 00:26:42 GMT Subject: RFR: 8284903: Fix typos in hotspot In-Reply-To: References: Message-ID: On Fri, 15 Apr 2022 07:40:04 GMT, Magnus Ihse Bursie wrote: > I ran `codespell` on hotspot, and accepted those changes where it indeed discovered real typos. > > You'd be surprised over the many implementions of instrinsics and other intructions accross all archtectures I've encounted, so for the preceding reason it's neccesery to sucessfully seach for exisiting typos... Hi Magnus, Generally looks good. Thanks for doing this extremely tedious cleanup. A few comments/suggestions/corrections below. And of course copyright dates need updating for Oracle copyrights. Thanks, David src/hotspot/cpu/x86/c1_LIRGenerator_x86.cpp line 125: > 123: bool LIRGenerator::can_store_as_constant(Value v, BasicType type) const { > 124: if (type == T_SHORT || type == T_CHAR) { > 125: // there is no immediate move of word values in assembler_i486.?pp Dead comment as there is no such file any more. src/hotspot/cpu/x86/macroAssembler_x86.hpp line 865: > 863: > 864: // 32bit can do a case table jump in one instruction but we no longer allow the base > 865: // to be installed in the Address class. This jump will transfers to the address transfer not transfers src/hotspot/share/c1/c1_Runtime1.cpp line 552: > 550: Exceptions::debug_check_abort(exception); > 551: > 552: // Check the stack guard pages and re-enable them if necessary and there is Curious how inconsistent hyphenation rules are in English :) I would use reenable in the same way we use mismatch. src/hotspot/share/code/nmethod.cpp line 2906: > 2904: > 2905: // Compressed undisassembled disassembly format. > 2906: // The following statuses are defined/supported: status is the more usual self-plural - or use "status values" src/hotspot/share/runtime/os.cpp line 644: > 642: DEBUG_ONLY(check_crash_protection()); > 643: > 644: // On malloc(0), implementers of malloc(3) have the choice to return either I suggest "implementations of malloc..." src/hotspot/share/runtime/task.hpp line 72: > 70: void enroll(); > 71: > 72: // Make the task deactivate Should be "inactive" src/hotspot/share/services/threadIdTable.cpp line 94: > 92: if (!_is_initialized) { > 93: { > 94: // There is no obvious benefits in allowing the thread table s/benefits/benefit/ src/hotspot/share/services/threadIdTable.cpp line 95: > 93: { > 94: // There is no obvious benefits in allowing the thread table > 95: // to be concurrently populated during the initialization. delete "the" ------------- Changes requested by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8260 From mchung at openjdk.java.net Tue Apr 19 02:03:35 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 19 Apr 2022 02:03:35 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v4] In-Reply-To: <_TWRNeLakN4zFnF3jIC_2ezkgvSzl-9O5xtV7qI-NDA=.b07a1c1a-edc1-4078-b580-a065a28a7b1f@github.com> References: <_TWRNeLakN4zFnF3jIC_2ezkgvSzl-9O5xtV7qI-NDA=.b07a1c1a-edc1-4078-b580-a065a28a7b1f@github.com> Message-ID: On Sun, 17 Apr 2022 16:03:30 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh src/java.base/share/classes/java/lang/System.java line 2173: > 2171: > 2172: // start Finalizer and Reference Handler threads > 2173: SharedSecrets.getJavaLangRefAccess().startThreads(); I think it would avoid any confusion if `VM.initLevel(1)` is the last step in `initPhase1`, i.e. call after this line. Previously, the finalizer starts very early and it has to wait until initLevel is set to level 1 which guarantees that `JavaLangAccess` is available. With this change, `JavaLangAccess` is already set. src/java.base/share/classes/java/lang/ref/ReferenceQueue.java line 61: > 59: private final Condition notEmpty; > 60: > 61: void signal() { notEmpty.signalAll(); } `signal()`, `await()` and `await(long)` methods are only used by `ReferenceQueue`. Good to make them private. src/jdk.management/share/classes/com/sun/management/HotSpotDiagnosticMXBean.java line 138: > 136: * > 137: * @param outputFile the path to the file to create > 138: * @param format the format to use (TEXT_PLAIN or JSON) It's useful to link to `ThreadDumpFormat#TEXT_PLAN` and `ThreadDumpFormat#JSON` ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From dholmes at openjdk.java.net Tue Apr 19 02:43:40 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 19 Apr 2022 02:43:40 GMT Subject: RFR: 8282477: [x86, aarch64] vmassert(_last_Java_pc == NULL, "already walkable"); fails with async profiler [v2] In-Reply-To: References: Message-ID: On Wed, 13 Apr 2022 06:42:56 GMT, Johannes Bechberger wrote: >> Fix the assertion by replacing it by assertion that does not fail. > > Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: > > Do not alter JFA in sender_for_entry Hi Johannes, Sorry for the delay in getting back to you on this one (vacation). With this change `JavaFrameAnchor::capture_last_Java_pc` is now only called from `JFA::make_walkable()` so it no longer needs to exist as a method. But I have to wonder why we have: if (!jfa->walkable()) { // Capture _last_Java_pc (if needed) and mark anchor walkable. jfa->capture_last_Java_pc(); } in the first place instead of simply: if (!jfa->walkable()) { jfa->make_walkable(); } and the check of `walkable()` isn't even needed in that case. ------------- PR: https://git.openjdk.java.net/jdk/pull/8209 From jiefu at openjdk.java.net Tue Apr 19 03:13:25 2022 From: jiefu at openjdk.java.net (Jie Fu) Date: Tue, 19 Apr 2022 03:13:25 GMT Subject: RFR: 8284877: Check type compatibility before looking up method from receiver's vtable In-Reply-To: References: Message-ID: On Thu, 14 Apr 2022 10:40:21 GMT, Yi Yang wrote: > Hi, can I have a review for this enhancement? This patch adds type compatibility check before method lookup for robustness. In some internal cases, serialization framework may improperly generate an object of wrong type, which leads JVM randomly crashes during method resolution. > > For example: > > invokevirtual selected method: receiver-class:java.util.ArrayList, resolved-class:com.taobao.forest.domain.util.LongMapSupportArrayList, resolved_method:com.taobao.forest.domain.util.LongMapSupportArrayList.toMap()Ljava/util/Map;, selected_method:0x458, vtable_index:56# > > The real type of receiver is ArrayList, while the resolved method is LongMapSupportArrayList.toMap. VM attempts to select method as if looking up from receiver's vtable via vtable index of resolved method(i.e. attempts to lookup toMap from > ArrayList.toMap), an invalid method or incorrect method would be selected, thus causing some strange crashes. > > I think it's reasonable to add a type compatibility check before method lookup. If such an incompatible call is found, JVM could throw an exception instead. Just wondering: is it possible to write a reproducer? ------------- PR: https://git.openjdk.java.net/jdk/pull/8241 From yyang at openjdk.java.net Tue Apr 19 03:21:22 2022 From: yyang at openjdk.java.net (Yi Yang) Date: Tue, 19 Apr 2022 03:21:22 GMT Subject: RFR: 8284877: Check type compatibility before looking up method from receiver's vtable In-Reply-To: References: Message-ID: On Tue, 19 Apr 2022 03:11:09 GMT, Jie Fu wrote: > Just wondering: is it possible to write a reproducer? Hi @DamonFool, it's not easy to write a jtreg test, this crash happens in production environment. But I can provide more information # linktime_resolve_virtual_method invokevirtual resolved method: caller-class:com.taobao.forest.domain.dataobject.std.impl.DefaultStdCategoryPropertyDO, compile-time-class:com.taobao.forest.domain.util.LongMapSupportArrayList, method:com.taobao.forest.domain.util.LongMapSupportArrayList.toMap()Ljava/util/Map;, method_holder:com.taobao.forest.domain.util.MapSupportArrayList, access_flags: public # runtime_resolve_virtual_method invokevirtual selected method: receiver-class:java.util.ArrayList, resolved-class:com.taobao.forest.domain.util.LongMapSupportArrayList, resolved_method:com.taobao.forest.domain.util.LongMapSupportArrayList.toMap()Ljava/util/Map;, selected_method:0x458, vtable_index:56# ------------- PR: https://git.openjdk.java.net/jdk/pull/8241 From duke at openjdk.java.net Tue Apr 19 05:01:26 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Tue, 19 Apr 2022 05:01:26 GMT Subject: RFR: 8282477: [x86, aarch64] vmassert(_last_Java_pc == NULL, "already walkable"); fails with async profiler [v2] In-Reply-To: References: Message-ID: On Wed, 13 Apr 2022 06:42:56 GMT, Johannes Bechberger wrote: >> Fix the assertion by replacing it by assertion that does not fail. > > Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: > > Do not alter JFA in sender_for_entry Neither do I, I fix it next week (vacation). ------------- PR: https://git.openjdk.java.net/jdk/pull/8209 From aph at openjdk.java.net Tue Apr 19 07:33:25 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Tue, 19 Apr 2022 07:33:25 GMT Subject: RFR: 8284563: AArch64: bitperm feature detection for SVE2 on Linux [v2] In-Reply-To: <3OeWzDWpqTTXni22O2BI6_02fNzH7h4px1cr7S5t_JQ=.34ad7e4e-cb79-4f1a-8ed1-16b4414f0da4@github.com> References: <-tRedEjmlUXfwqLEQz7GWKiy64cAcOKCXXZEkl7EnpY=.7d1d300a-0350-4283-a400-85d685bb2238@github.com> <3OeWzDWpqTTXni22O2BI6_02fNzH7h4px1cr7S5t_JQ=.34ad7e4e-cb79-4f1a-8ed1-16b4414f0da4@github.com> Message-ID: <7UE1PjKc1YKS2eFBYPNRki8yaaaiEMoVfnhsF0QSTn0=.1260e2fd-188d-4b63-bd1b-bc3ff1f37c32@github.com> On Mon, 18 Apr 2022 11:06:05 GMT, Eric Liu wrote: >> `STXR_PREFETCH` is usually done unconditionally in non-JVM code. Does it ever hurt performance? If not, let's get rid of `STXR_PREFETCH` and do prefetching unconditionally. > > @theRealAph > > TBH I don't know the history about this code. Considering that may impact the performance, I don't have too much confidence to dispose of it in this patch. > > Do you think it's fine to trace it in a separate JBS? Absolutely, yes, getting rid of `STXR_PREFETCH` should be separate from this patch. We need, as a group, to keep on top of accreting complexity. That's hard when the people changing code don't know the history of that code. ------------- PR: https://git.openjdk.java.net/jdk/pull/8258 From eliu at openjdk.java.net Tue Apr 19 07:55:22 2022 From: eliu at openjdk.java.net (Eric Liu) Date: Tue, 19 Apr 2022 07:55:22 GMT Subject: RFR: 8284563: AArch64: bitperm feature detection for SVE2 on Linux [v2] In-Reply-To: <7UE1PjKc1YKS2eFBYPNRki8yaaaiEMoVfnhsF0QSTn0=.1260e2fd-188d-4b63-bd1b-bc3ff1f37c32@github.com> References: <-tRedEjmlUXfwqLEQz7GWKiy64cAcOKCXXZEkl7EnpY=.7d1d300a-0350-4283-a400-85d685bb2238@github.com> <3OeWzDWpqTTXni22O2BI6_02fNzH7h4px1cr7S5t_JQ=.34ad7e4e-cb79-4f1a-8ed1-16b4414f0da4@github.com> <7UE1PjKc1YKS2eFBYPNRki8yaaaiEMoVfnhsF0QSTn0=.1260e2fd-188d-4b63-bd1b-bc3ff1f37c32@github.com> Message-ID: On Tue, 19 Apr 2022 07:30:11 GMT, Andrew Haley wrote: >> @theRealAph >> >> TBH I don't know the history about this code. Considering that may impact the performance, I don't have too much confidence to dispose of it in this patch. >> >> Do you think it's fine to trace it in a separate JBS? > > Absolutely, yes, getting rid of `STXR_PREFETCH` should be separate from this patch. > > We need, as a group, to keep on top of accreting complexity. That's hard when the people changing code don't know the history of that code. I created a separate JBS for it. https://bugs.openjdk.java.net/browse/JDK-8284990 ------------- PR: https://git.openjdk.java.net/jdk/pull/8258 From duke at openjdk.java.net Tue Apr 19 08:00:25 2022 From: duke at openjdk.java.net (Tobias Holenstein) Date: Tue, 19 Apr 2022 08:00:25 GMT Subject: RFR: JDK-8075816: Deprecate AliasLevel flag since it is broken [v3] In-Reply-To: References: Message-ID: On Tue, 12 Apr 2022 16:29:21 GMT, Vladimir Kozlov wrote: >> I don't think there is a real use case for `-XX:AliasLevel=2` given that one can get similar behavior with `-XX:-EliminateAllocations` (or `-XX:-DoEscapeAnalysis`). I would therefore vote for **deprecating** `AliasLevel`. > > Yes, I agree with Tobias. Lets treat `-XX:AliasLevel=2` as `-XX:-EliminateAllocations`. There are tests which use this flags. > And yes, we should deprecate `AliasLevel` but correcting bug's and CSR's text with this new information about `-XX:AliasLevel=2`. The CSR request (JDK-8284515) is now updated for **deprecating** `AliasLevel` ------------- PR: https://git.openjdk.java.net/jdk/pull/8140 From aph at openjdk.java.net Tue Apr 19 08:00:27 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Tue, 19 Apr 2022 08:00:27 GMT Subject: RFR: 8284563: AArch64: bitperm feature detection for SVE2 on Linux [v2] In-Reply-To: References: <-tRedEjmlUXfwqLEQz7GWKiy64cAcOKCXXZEkl7EnpY=.7d1d300a-0350-4283-a400-85d685bb2238@github.com> <3OeWzDWpqTTXni22O2BI6_02fNzH7h4px1cr7S5t_JQ=.34ad7e4e-cb79-4f1a-8ed1-16b4414f0da4@github.com> <7UE1PjKc1YKS2eFBYPNRki8yaaaiEMoVfnhsF0QSTn0=.1260e2fd-188d-4b63-bd1b-bc3ff1f37c32@github.com> Message-ID: On Tue, 19 Apr 2022 07:52:07 GMT, Eric Liu wrote: >> Absolutely, yes, getting rid of `STXR_PREFETCH` should be separate from this patch. >> >> We need, as a group, to keep on top of accreting complexity. That's hard when the people changing code don't know the history of that code. > > I created a separate JBS for it. https://bugs.openjdk.java.net/browse/JDK-8284990 Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/8258 From thartmann at openjdk.java.net Tue Apr 19 08:04:19 2022 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Tue, 19 Apr 2022 08:04:19 GMT Subject: RFR: JDK-8075816: Deprecate AliasLevel flag since it is broken [v3] In-Reply-To: References: Message-ID: <11zHQ-sntex__9NkyH85fJVDeQoSUhKk2Q2OduMsQ4w=.a463a93f-e59e-4c9a-b515-908b77fd77c8@github.com> On Thu, 14 Apr 2022 17:04:24 GMT, Tobias Holenstein wrote: >> Deprecate the `AliasLevel` flag. `AliasLevel` can have the following values: >> >> "0 - for no aliasing, " >> "1 - for oop/field/static/array split, " >> "2 - for class split, " >> "3 - for unique instances" >> >> - Deprecate AliasLevel in JDK 19. >> - Obsolete it in JDK 20 >> - Expire it in JDK 21. >> >> Users will now get the following message when running: >> `java -XX:AliasLevel= Java HotSpot(TM) 64-Bit Server VM warning: Option AliasLevel was deprecated in version 19.0 and will likely be removed in a future release.` > > Tobias Holenstein has updated the pull request incrementally with one additional commit since the last revision: > > Revert "Obsolete AliasLevel flag" > > This reverts commit 6a1bed2d7ed5494b051fae09d28787fd01de9635. Looks good to me. ------------- Marked as reviewed by thartmann (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8140 From njian at openjdk.java.net Tue Apr 19 08:37:25 2022 From: njian at openjdk.java.net (Ningsheng Jian) Date: Tue, 19 Apr 2022 08:37:25 GMT Subject: RFR: 8284563: AArch64: bitperm feature detection for SVE2 on Linux [v2] In-Reply-To: References: Message-ID: On Mon, 18 Apr 2022 10:58:39 GMT, Eric Liu wrote: >> This patch adds BITPERM feature detection for SVE2 on Linux. BITPERM is >> an optional feature in SVE2 [1]. It enables 3 SVE2 instructions (BEXT, >> BDEP, BGRP). BEXT and BDEP map efficiently to some vector operations, >> e.g., the compress and expand functionalities [2] which are proposed in >> VectorAPI's 4th incubation [3]. Besides, to generate specific code based >> on different architecture features like x86, this patch exports >> VM_Version::supports_XXX() for all CPU features. E.g., >> VM_Version::supports_svebitperm() for easy use. >> >> This patch also fixes a trivial bug, that sets UseSVE back to 1 if it's >> 2 in SVE1 system. >> >> [1] https://developer.arm.com/documentation/ddi0601/2022-03/AArch64-Registers/ID-AA64ZFR0-EL1--SVE-Feature-ID-register-0 >> [2] https://bugs.openjdk.java.net/browse/JDK-8283893 >> [3] https://bugs.openjdk.java.net/browse/JDK-8280173 > > Eric Liu has updated the pull request incrementally with one additional commit since the last revision: > > small fix > > Change-Id: Ida979f925055761ad73e50655d0584dcee24aea4 Marked as reviewed by njian (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8258 From dnsimon at openjdk.java.net Tue Apr 19 08:52:28 2022 From: dnsimon at openjdk.java.net (Doug Simon) Date: Tue, 19 Apr 2022 08:52:28 GMT Subject: RFR: 8284903: Fix typos in hotspot In-Reply-To: References: Message-ID: On Fri, 15 Apr 2022 07:40:04 GMT, Magnus Ihse Bursie wrote: > I ran `codespell` on hotspot, and accepted those changes where it indeed discovered real typos. > > You'd be surprised over the many implementions of instrinsics and other intructions accross all archtectures I've encounted, so for the preceding reason it's neccesery to sucessfully seach for exisiting typos... Are there plans to add `codespell` to the make system to somehow catch/prevent spelling regressions in future? I understand this may not be feasible. ------------- PR: https://git.openjdk.java.net/jdk/pull/8260 From duke at openjdk.java.net Tue Apr 19 09:01:25 2022 From: duke at openjdk.java.net (XenoAmess) Date: Tue, 19 Apr 2022 09:01:25 GMT Subject: RFR: 8284903: Fix typos in hotspot In-Reply-To: References: Message-ID: On Tue, 19 Apr 2022 08:49:28 GMT, Doug Simon wrote: > Are there plans to add `codespell` to the make system to somehow catch/prevent spelling regressions in future? I understand this may not be feasible. IMO all spell checking mechanisms suffers from false positive and need human manual job to filter them... So maybe we can only arrange a scan per year or per months... ------------- PR: https://git.openjdk.java.net/jdk/pull/8260 From mdoerr at openjdk.java.net Tue Apr 19 09:08:28 2022 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Tue, 19 Apr 2022 09:08:28 GMT Subject: RFR: 8283643: [AIX, testbug] MachCodeFramesInErrorFile test fails to find 'Native frames' text In-Reply-To: References: Message-ID: On Mon, 4 Apr 2022 15:47:06 GMT, Tyler Steele wrote: > I observed a failure of MachCodeFramesInErrorFile.java on AIX. The raised error complains that 'Native frames: ' is missing. To fix the failure, I made two changes to the test that allowed it to pass on AIX. > > The first change made was to the test's `extractFrames` method. AIX overrides `os::platform_print_native_stack` with stack printing specific to AIX/Power. This code does not produce the 'Native frames: ' text that `vmError::print_native_stack` does, so the test was modified to expect the AIX output when run on AIX. > > A second change was made to the address passed to the `crashInNative1` method. AIX does not consider low-address memory to be protected as other platforms do. In fact, "the first 256 bytes are reserved for software use" according to the Power ISA. Accordingly, the read address for PPC was changed to -1 (0xFF..FF) to produce the expected failure result. > > ### Testing > > Tier1 tests complete as expected on AIX/Power. Looks basically good to me, but please take a look at my comments. test/hotspot/jtreg/runtime/ErrorHandling/MachCodeFramesInErrorFile.java line 75: > 73: assert args[0].equals("crashInVM"); > 74: // AIX does not prohibit low address reads > 75: crashInNative1( Platform.isPPC() ? -1 : 10 ); Spaces next to braces are uncommon. test/hotspot/jtreg/runtime/ErrorHandling/MachCodeFramesInErrorFile.java line 177: > 175: } else { > 176: marker = (nativeStack ? "Native" : "Java") + " frames: "; > 177: } Yeah, we have special stack trace code on AIX. Ok. test/hotspot/jtreg/runtime/ErrorHandling/MachCodeFramesInErrorFile.java line 189: > 187: } > 188: } > 189: throw new RuntimeException("\"" + marker + "\" line missing in hs_err_pid file:\n"); Please explain removal! ------------- PR: https://git.openjdk.java.net/jdk/pull/8094 From dnsimon at openjdk.java.net Tue Apr 19 09:10:37 2022 From: dnsimon at openjdk.java.net (Doug Simon) Date: Tue, 19 Apr 2022 09:10:37 GMT Subject: RFR: 8242440: use separate, destroyable JavaVM instances per libgraal compiler thread In-Reply-To: References: <2-IBy0ERqZXykr2FcvJzq2gi5zmQsN_5h3iNZcCvrtU=.5039ed2d-fedf-45f4-8b7e-56c76c06f474@github.com> Message-ID: On Mon, 18 Apr 2022 20:55:40 GMT, Kim Barrett wrote: >> It is declared volatile for correct double checked locking in the code prior to this PR: >> >> JNIEnv* JVMCIRuntime::init_shared_library_javavm() { >> JavaVM* javaVM = (JavaVM*) _shared_library_javavm; >> if (javaVM == NULL) { >> MutexLocker locker(JVMCI_lock); >> // Check again under JVMCI_lock >> javaVM = (JavaVM*) _shared_library_javavm; >> if (javaVM != NULL) { >> return NULL; >> } >> >> However, now that `JVMCIRuntime::_lock` is acquired at the entry to `JVMCIRuntime::init_shared_library_javavm` there is indeed no longer a need for it to be volatile. > > The declaration was wrong for that usage - it should have been "volatile pointer to X" (`JavaVM* volatile`) but was declared "pointer to volatile X" (`volatile JavaVM*`). That also wasn't a correct implementation of DCLP. Good thing you are changing this. So yes, the volatile should be nuked and this cast and the similar one in destroy_shared_library_javavm can be removed. Thanks for the correction. I have removed `volatile` altogether now. It's also a good reminder of the subtleties in C++ that do not exist in Java. ------------- PR: https://git.openjdk.java.net/jdk/pull/8262 From tschatzl at openjdk.java.net Tue Apr 19 09:26:26 2022 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Tue, 19 Apr 2022 09:26:26 GMT Subject: RFR: 8284435: Add dedicated filler objects for known dead Java heap areas [v3] In-Reply-To: References: Message-ID: On Mon, 11 Apr 2022 21:51:32 GMT, David Holmes wrote: > Do you really need to define a real `FillerObject.java` class? Can't you use an internal-only variant of a hidden class to represent this? I am not sure I understand this request, but of course I am open to try different approaches. An existing example would be fine to get me on track; but maybe I am only not understanding your terminology: do you mean to have a special subclass of instanceKlass for `FillerObject`? I had that, but that has been much much more effort (in terms of code, maintainability, ...) than having such an additional Java class file in the JDK and use the existing macros to use it everywhere. ------------- PR: https://git.openjdk.java.net/jdk/pull/8156 From hoffmann at mountainminds.com Tue Apr 19 09:52:21 2022 From: hoffmann at mountainminds.com (Marc Hoffmann) Date: Tue, 19 Apr 2022 11:52:21 +0200 Subject: ARM32 crash since 8283326: Implement SafeFetch statically Message-ID: <9BA0F03F-129B-487A-97E3-4DDD41FF4E20@mountainminds.com> Dear Hotspot developers, Marc here from the JaCoCo project. Since the following commit the native arm32 build seems to be broken: 8283326: Implement SafeFetch statically Reviewed-by: dholmes, mdoerr, akozlov, lucy https://github.com/openjdk/jdk/commit/bdf8a2a2050393e91800786f8d5a5d6805f936eb The build crashes reproducible with the following error: # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0xb43939e0, pid=16897, tid=16902 # # JRE version: OpenJDK Runtime Environment (19.0) (build 19-internal-adhoc..workspace) # Java VM: OpenJDK Server VM (19-internal-adhoc..workspace, mixed mode, g1 gc, linux-arm) # Problematic frame: # v ~StubRoutines::atomic_add # # Core dump will be written. Default location: /workspace/make/core # # If you would like to submit a bug report, please visit: # https://bugreport.java.com/bugreport/crash.jsp # See crash report file attached. Should I open a bug report for this or is this already known? Thanks for looking into this and best regards, -marc From stuefe at openjdk.java.net Tue Apr 19 10:01:27 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 19 Apr 2022 10:01:27 GMT Subject: RFR: 8283643: [AIX, testbug] MachCodeFramesInErrorFile test fails to find 'Native frames' text In-Reply-To: References: Message-ID: On Mon, 4 Apr 2022 15:47:06 GMT, Tyler Steele wrote: > I observed a failure of MachCodeFramesInErrorFile.java on AIX. The raised error complains that 'Native frames: ' is missing. To fix the failure, I made two changes to the test that allowed it to pass on AIX. > > The first change made was to the test's `extractFrames` method. AIX overrides `os::platform_print_native_stack` with stack printing specific to AIX/Power. This code does not produce the 'Native frames: ' text that `vmError::print_native_stack` does, so the test was modified to expect the AIX output when run on AIX. > > A second change was made to the address passed to the `crashInNative1` method. AIX does not consider low-address memory to be protected as other platforms do. In fact, "the first 256 bytes are reserved for software use" according to the Power ISA. Accordingly, the read address for PPC was changed to -1 (0xFF..FF) to produce the expected failure result. > > ### Testing > > Tier1 tests complete as expected on AIX/Power. Hi Tyler, in the JVM we have `VMError::segfault_address` for this reason. I'd prefer if we reused that (publishing it via Whitebox method) instead of polluting the shared tests with PPC specifics. We could reuse this whitebox method in other tests, actually, without running into the NULL-is-readable issue again. (To see how whitebox methods are used, see the classes in sun.hotspot.WhiteBox and their corresponding "WB_..." endpoints in hotspot/share/prims/whitebox.cpp. Its all pretty straightforward). Another, maybe simpler option would be just to write instead of read in `crashInNative3`. crashInJava3 uses write too (putLong). But it looks deliberate, so you'd have to look at the original RFR for this test. Cheers, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/8094 From thomas.stuefe at gmail.com Tue Apr 19 10:02:08 2022 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 19 Apr 2022 12:02:08 +0200 Subject: ARM32 crash since 8283326: Implement SafeFetch statically In-Reply-To: <9BA0F03F-129B-487A-97E3-4DDD41FF4E20@mountainminds.com> References: <9BA0F03F-129B-487A-97E3-4DDD41FF4E20@mountainminds.com> Message-ID: Yes, please open a bug report, and if possible attach a hs-err file or at least the crash stack. The patch was tested on arm32, so I'm not sure yet what's wrong. Note that I do a cross build for arm32, I don't build natively. Cheers, Thomas On Tue, Apr 19, 2022 at 11:52 AM Marc Hoffmann wrote: > Dear Hotspot developers, > > Marc here from the JaCoCo project. Since the following commit the native > arm32 build seems to be broken: > > 8283326: Implement SafeFetch statically > Reviewed-by: dholmes, mdoerr, akozlov, lucy > > > https://github.com/openjdk/jdk/commit/bdf8a2a2050393e91800786f8d5a5d6805f936eb > < > https://github.com/openjdk/jdk/commit/bdf8a2a2050393e91800786f8d5a5d6805f936eb > > > > > The build crashes reproducible with the following error: > > # > # A fatal error has been detected by the Java Runtime Environment: > # > # SIGSEGV (0xb) at pc=0xb43939e0, pid=16897, tid=16902 > # > # JRE version: OpenJDK Runtime Environment (19.0) (build > 19-internal-adhoc..workspace) > # Java VM: OpenJDK Server VM (19-internal-adhoc..workspace, mixed mode, g1 > gc, linux-arm) > # Problematic frame: > # v ~StubRoutines::atomic_add > # > # Core dump will be written. Default location: /workspace/make/core > # > # If you would like to submit a bug report, please visit: > # https://bugreport.java.com/bugreport/crash.jsp > # > See crash report file attached. > > Should I open a bug report for this or is this already known? > > Thanks for looking into this and best regards, > -marc > > > > From dnsimon at openjdk.java.net Tue Apr 19 10:11:04 2022 From: dnsimon at openjdk.java.net (Doug Simon) Date: Tue, 19 Apr 2022 10:11:04 GMT Subject: RFR: 8242440: use separate, destroyable JavaVM instances per libgraal compiler thread [v2] In-Reply-To: References: Message-ID: > Currently, libgraal runs in a single, permanent JavaVM instance loaded from libjvmcicompiler.so. This poses 2 problems: > > 1. The memory used for libgraal is never released, even when the libgraal compiler queues are idle. > 2. Since all libgraal HotSpot compiler threads share the same SVM heap, libgraal compilation is effectively paused when a GC occurs (SVM currently has a stop the world collector). The more compiler threads there are, the more often this happens. > > This PR implements the following solution to these problems: > 1. Create a new JavaVM instance per libgraal compiler thread (i.e. a separate SVM isolate per thread). This prevents GC in one libgraal thread from impacting another libgraal thread. > 2. Destroy the JavaVM instances when a libgraal compiler thread becomes idle and create a new one when subsequent compilation requests arrive. > > Most of the changes are in JVMCI specific files. The most significant change to shared code is the addition of the `JavaThread:: _libjvmci_runtime` field. This is required as any thread (not just a `CompilerThread`) can be associated with a specific `JVMCIRuntime` object. Doug Simon has updated the pull request incrementally with six additional commits since the last revision: - avoid use of jobject for oop handles implementing foreign object references in libjvmci heap to HotSpot heap objects - inlined JVMCIRuntime::_jobjects - replace NULL with nullptr - added JVMCIRuntime_lock global - replace enum with const definition - rename thread parameter to current ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8262/files - new: https://git.openjdk.java.net/jdk/pull/8262/files/204952a0..fc9dd87f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8262&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8262&range=00-01 Stats: 195 lines in 15 files changed: 18 ins; 5 del; 172 mod Patch: https://git.openjdk.java.net/jdk/pull/8262.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8262/head:pull/8262 PR: https://git.openjdk.java.net/jdk/pull/8262 From dnsimon at openjdk.java.net Tue Apr 19 10:11:06 2022 From: dnsimon at openjdk.java.net (Doug Simon) Date: Tue, 19 Apr 2022 10:11:06 GMT Subject: RFR: 8242440: use separate, destroyable JavaVM instances per libgraal compiler thread [v2] In-Reply-To: <2-IBy0ERqZXykr2FcvJzq2gi5zmQsN_5h3iNZcCvrtU=.5039ed2d-fedf-45f4-8b7e-56c76c06f474@github.com> References: <2-IBy0ERqZXykr2FcvJzq2gi5zmQsN_5h3iNZcCvrtU=.5039ed2d-fedf-45f4-8b7e-56c76c06f474@github.com> Message-ID: <1u6HOYkjJkyqcY-ulGOjCDNxse6JenYFQ9pxOQ97uFM=.fa7c7d50-f77f-467c-a9f3-ef14721ca283@github.com> On Sun, 17 Apr 2022 04:14:30 GMT, Kim Barrett wrote: >> Doug Simon has updated the pull request incrementally with six additional commits since the last revision: >> >> - avoid use of jobject for oop handles implementing foreign object references in libjvmci heap to HotSpot heap objects >> - inlined JVMCIRuntime::_jobjects >> - replace NULL with nullptr >> - added JVMCIRuntime_lock global >> - replace enum with const definition >> - rename thread parameter to current > > src/hotspot/share/jvmci/jvmciRuntime.hpp line 168: > >> 166: // destroying remaining JNI handles when the JavaVM associated >> 167: // with this runtime is shutdown. >> 168: GrowableArray* _jobjects; > > I think _jobjects should be a nested object rather than a pointer. Fixed: https://github.com/openjdk/jdk/pull/8262/commits/1d5b815d0dbc4781059ec1b9e7375dc593af9438 > src/hotspot/share/jvmci/jvmciRuntime.hpp line 177: > >> 175: int _num_attached_threads; >> 176: enum { >> 177: cannot_be_attached = -1 // See _num_attached_threads > > We no longer use enums (with unspecified type) to define constants. Use `static const` instead. (There's lots of old code that still does this, but new code should not.) Fixed: https://github.com/openjdk/jdk/pull/8262/commits/53edb1d00a7d8ff6b22b3d9a32b7dc915874c3e7 ------------- PR: https://git.openjdk.java.net/jdk/pull/8262 From dnsimon at openjdk.java.net Tue Apr 19 10:11:06 2022 From: dnsimon at openjdk.java.net (Doug Simon) Date: Tue, 19 Apr 2022 10:11:06 GMT Subject: RFR: 8242440: use separate, destroyable JavaVM instances per libgraal compiler thread [v2] In-Reply-To: References: <2-IBy0ERqZXykr2FcvJzq2gi5zmQsN_5h3iNZcCvrtU=.5039ed2d-fedf-45f4-8b7e-56c76c06f474@github.com> <4Z8M1GtFQgERjYfj-kxr71iv4et4BThMtFqQmHbYJLg=.26978688-ac3f-4fa1-b42e-64da2579390e@github.com> Message-ID: <-w7ENI65tahXRnskmz78H2cW2yT-Z_JE65Ty_021Ztg=.dcb79e70-7a85-4576-9d58-1af90573761b@github.com> On Mon, 18 Apr 2022 04:49:20 GMT, Kim Barrett wrote: >> Interesting proposal. What would be the advantage of `OopHandle` over `jobject`? That require a bunch of `reinterpret_cast`ing between `jobject` and `OopHandle` which I'm not sure is even possible? > > The suggestion was about managing the handles and associated values (and I'm not even sure it would help there). But maybe `jobject` is too deeply embedded in JVMCI usage? Or maybe there are places where it really needs to be using `jobject` rather than `oop*` or a thin wrapper over `oop*` like `OopHandle`? I'm avoiding `jobject` altogether now: https://github.com/openjdk/jdk/pull/8262/commits/fc9dd87fe87271c33f9861e97c84d1cc681e40c6 ------------- PR: https://git.openjdk.java.net/jdk/pull/8262 From dnsimon at openjdk.java.net Tue Apr 19 10:11:05 2022 From: dnsimon at openjdk.java.net (Doug Simon) Date: Tue, 19 Apr 2022 10:11:05 GMT Subject: RFR: 8242440: use separate, destroyable JavaVM instances per libgraal compiler thread [v2] In-Reply-To: References: Message-ID: On Sun, 17 Apr 2022 02:25:40 GMT, David Holmes wrote: >> Doug Simon has updated the pull request incrementally with six additional commits since the last revision: >> >> - avoid use of jobject for oop handles implementing foreign object references in libjvmci heap to HotSpot heap objects >> - inlined JVMCIRuntime::_jobjects >> - replace NULL with nullptr >> - added JVMCIRuntime_lock global >> - replace enum with const definition >> - rename thread parameter to current > > src/hotspot/share/compiler/abstractCompiler.hpp line 170: > >> 168: // Notifies this compiler that the current thread (`thread`) is about to stop. >> 169: // The current thread currently holds the CompileThread_lock. >> 170: virtual void stopping_compiler_thread(CompilerThread* thread) { > > If `thread` is the current thread then I'd recommend calling it `current` so that this is clear. Fixed: https://github.com/openjdk/jdk/pull/8262/commits/f448c2f6f859aea772a748458cbd336a8744afed ------------- PR: https://git.openjdk.java.net/jdk/pull/8262 From dnsimon at openjdk.java.net Tue Apr 19 10:11:07 2022 From: dnsimon at openjdk.java.net (Doug Simon) Date: Tue, 19 Apr 2022 10:11:07 GMT Subject: RFR: 8242440: use separate, destroyable JavaVM instances per libgraal compiler thread [v2] In-Reply-To: <4Z8M1GtFQgERjYfj-kxr71iv4et4BThMtFqQmHbYJLg=.26978688-ac3f-4fa1-b42e-64da2579390e@github.com> References: <2-IBy0ERqZXykr2FcvJzq2gi5zmQsN_5h3iNZcCvrtU=.5039ed2d-fedf-45f4-8b7e-56c76c06f474@github.com> <4Z8M1GtFQgERjYfj-kxr71iv4et4BThMtFqQmHbYJLg=.26978688-ac3f-4fa1-b42e-64da2579390e@github.com> Message-ID: On Sun, 17 Apr 2022 08:58:47 GMT, Doug Simon wrote: >> src/hotspot/share/runtime/mutexLocker.hpp line 151: >> >>> 149: >>> 150: #if INCLUDE_JVMCI >>> 151: #define JVMCIRuntime_lock_rank safepoint >> >> This shouldn't be a macro. Use `const Mutex::Rank JVMCIRuntime_lock_rank = safepoint;`. > > Thanks. This suggestion actually helps me clean up the code by allocating a global `JVMCIRuntime_lock` and associating with the first `JVMCIRuntime` created. It is then used as a prototype for the lock associated with subsequent `JVMCIRuntime`s. Fixed: https://github.com/openjdk/jdk/pull/8262/commits/117fbd7d69e1768755ff3b0b7c8cf3e01310c37e ------------- PR: https://git.openjdk.java.net/jdk/pull/8262 From dnsimon at openjdk.java.net Tue Apr 19 10:17:14 2022 From: dnsimon at openjdk.java.net (Doug Simon) Date: Tue, 19 Apr 2022 10:17:14 GMT Subject: RFR: 8242440: use separate, destroyable JavaVM instances per libgraal compiler thread [v3] In-Reply-To: References: Message-ID: > Currently, libgraal runs in a single, permanent JavaVM instance loaded from libjvmcicompiler.so. This poses 2 problems: > > 1. The memory used for libgraal is never released, even when the libgraal compiler queues are idle. > 2. Since all libgraal HotSpot compiler threads share the same SVM heap, libgraal compilation is effectively paused when a GC occurs (SVM currently has a stop the world collector). The more compiler threads there are, the more often this happens. > > This PR implements the following solution to these problems: > 1. Create a new JavaVM instance per libgraal compiler thread (i.e. a separate SVM isolate per thread). This prevents GC in one libgraal thread from impacting another libgraal thread. > 2. Destroy the JavaVM instances when a libgraal compiler thread becomes idle and create a new one when subsequent compilation requests arrive. > > Most of the changes are in JVMCI specific files. The most significant change to shared code is the addition of the `JavaThread:: _libjvmci_runtime` field. This is required as any thread (not just a `CompilerThread`) can be associated with a specific `JVMCIRuntime` object. Doug Simon has updated the pull request incrementally with one additional commit since the last revision: removed (incorrect) volatile modifier from JVMCIRuntime::_shared_library_javavm ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8262/files - new: https://git.openjdk.java.net/jdk/pull/8262/files/fc9dd87f..8aacbbaa Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8262&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8262&range=01-02 Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/8262.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8262/head:pull/8262 PR: https://git.openjdk.java.net/jdk/pull/8262 From dnsimon at openjdk.java.net Tue Apr 19 10:17:14 2022 From: dnsimon at openjdk.java.net (Doug Simon) Date: Tue, 19 Apr 2022 10:17:14 GMT Subject: RFR: 8242440: use separate, destroyable JavaVM instances per libgraal compiler thread [v3] In-Reply-To: References: <2-IBy0ERqZXykr2FcvJzq2gi5zmQsN_5h3iNZcCvrtU=.5039ed2d-fedf-45f4-8b7e-56c76c06f474@github.com> Message-ID: On Tue, 19 Apr 2022 09:06:54 GMT, Doug Simon wrote: >> The declaration was wrong for that usage - it should have been "volatile pointer to X" (`JavaVM* volatile`) but was declared "pointer to volatile X" (`volatile JavaVM*`). That also wasn't a correct implementation of DCLP. Good thing you are changing this. So yes, the volatile should be nuked and this cast and the similar one in destroy_shared_library_javavm can be removed. > > Thanks for the correction. I have removed `volatile` altogether now. It's also a good reminder of the subtleties in C++ that do not exist in Java. Fixed: https://github.com/openjdk/jdk/pull/8262/commits/8aacbbaa2c3909694e83000ca0f8366fc6dc7931 ------------- PR: https://git.openjdk.java.net/jdk/pull/8262 From alanb at openjdk.java.net Tue Apr 19 10:52:30 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 19 Apr 2022 10:52:30 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v4] In-Reply-To: References: <_TWRNeLakN4zFnF3jIC_2ezkgvSzl-9O5xtV7qI-NDA=.b07a1c1a-edc1-4078-b580-a065a28a7b1f@github.com> Message-ID: On Tue, 19 Apr 2022 00:09:04 GMT, Mandy Chung wrote: >> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: >> >> Refresh > > src/java.base/share/classes/java/lang/ref/ReferenceQueue.java line 61: > >> 59: private final Condition notEmpty; >> 60: >> 61: void signal() { notEmpty.signalAll(); } > > `signal()`, `await()` and `await(long)` methods are only used by `ReferenceQueue`. Good to make them private. They are overridden so can't be private. > src/java.base/share/classes/java/lang/ref/ReferenceQueue.java line 206: > >> 204: throws IllegalArgumentException, InterruptedException { >> 205: if (timeout < 0) throw new IllegalArgumentException("Negative timeout value"); >> 206: if (timeout == 0) return remove(); > > Nit: use the same formatting as in `NativeReferenceQueue::remove` and in this file. > > > if (timeout < 0) > throw new IllegalArgumentException("Negative timeout value"); > if (timeout == 0) > return remove(); okay > src/java.management/share/classes/java/lang/management/ThreadMXBean.java line 655: > >> 653: * synchronization control. It might be an expensive operation. >> 654: * Its behavior with cycles involving virtual threads is not defined >> 655: * in this release. > > What does the current implementation return if the virtual threads are involved in a deadlock? The class spec says "ThreadMXBean does not support monitoring or management of virtual threads" while this javadoc says it's undefined. I wonder if it's helpful to include `@implNote` if appropriate. If there is cycle involving a virtual thread then the thread id of its carrier will be included in array. I think we can do better and include the thread id of the mounted thread. > src/jdk.management/share/classes/com/sun/management/HotSpotDiagnosticMXBean.java line 138: > >> 136: * >> 137: * @param outputFile the path to the file to create >> 138: * @param format the format to use (TEXT_PLAIN or JSON) > > It's useful to link to `ThreadDumpFormat#TEXT_PLAN` and `ThreadDumpFormat#JSON` I think it might be better if the description is changed to "the format to use". There is already a link to the ThreadDumpFormat enum in method signature. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From dholmes at openjdk.java.net Tue Apr 19 12:17:27 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 19 Apr 2022 12:17:27 GMT Subject: RFR: 8284877: Check type compatibility before looking up method from receiver's vtable In-Reply-To: References: Message-ID: On Thu, 14 Apr 2022 10:40:21 GMT, Yi Yang wrote: > Hi, can I have a review for this enhancement? This patch adds type compatibility check before method lookup for robustness. In some internal cases, serialization framework may improperly generate an object of wrong type, which leads JVM randomly crashes during method resolution. > > For example: > > invokevirtual selected method: receiver-class:java.util.ArrayList, resolved-class:com.taobao.forest.domain.util.LongMapSupportArrayList, resolved_method:com.taobao.forest.domain.util.LongMapSupportArrayList.toMap()Ljava/util/Map;, selected_method:0x458, vtable_index:56# > > The real type of receiver is ArrayList, while the resolved method is LongMapSupportArrayList.toMap. VM attempts to select method as if looking up from receiver's vtable via vtable index of resolved method(i.e. attempts to lookup `toMap()` from > ArrayList), an invalid method or incorrect method would be selected, thus causing some strange crashes. > > I think it's reasonable to add a type compatibility check before method lookup. If such an incompatible call is found, JVM could throw an exception instead. Hi, This really needs a test case so we can understand exactly what is going on. Receiver type checking happens in a number of places so we need to understand how the problem arises and exactly what should be happening in that case per the JVMS. If this is a corrupt serialization stream then it may indicate a bug in the JDK deserialization code - again important to know. Thanks, David ------------- PR: https://git.openjdk.java.net/jdk/pull/8241 From duke at openjdk.java.net Tue Apr 19 12:56:43 2022 From: duke at openjdk.java.net (KIRIYAMA Takuya) Date: Tue, 19 Apr 2022 12:56:43 GMT Subject: Integrated: 8280761: UseCompressedOops should be set after limit_heap_by_allocatable_memory In-Reply-To: References: Message-ID: On Thu, 24 Mar 2022 06:52:34 GMT, KIRIYAMA Takuya wrote: > I fixed to set UseCompressedOops flag after limit_heap_by_allocatable_memory(). > So when ulimit -v is called and -XX:MaxRAM is set, UseCompressedOops does not become false. > And all hotspot tier1 test are passed. > Would you please review this fix? This pull request has now been integrated. Changeset: 8d96ab0f Author: KIRIYAMA Takuya Committer: Albert Mingkun Yang URL: https://git.openjdk.java.net/jdk/commit/8d96ab0f36d91a54cf7951a159325bd4f6aab41d Stats: 116 lines in 2 files changed: 104 ins; 12 del; 0 mod 8280761: UseCompressedOops should be set after limit_heap_by_allocatable_memory Reviewed-by: ayang, tschatzl ------------- PR: https://git.openjdk.java.net/jdk/pull/7938 From lucy at openjdk.java.net Tue Apr 19 14:02:26 2022 From: lucy at openjdk.java.net (Lutz Schmidt) Date: Tue, 19 Apr 2022 14:02:26 GMT Subject: RFR: 8278757: [s390] Implement AES Counter Mode Intrinsic In-Reply-To: References: Message-ID: On Thu, 7 Apr 2022 21:24:45 GMT, Tyler Steele wrote: >> Once again: >> With only s390 files in the changeset, there is no way for this PR to fail linux x86 tests. > > @RealLucy Tier1 tests in progress :slightly_smiling_face:. I will update this comment when they complete > > --- > > I see only one failure, but I don't believe it's a new one. [We saw it [last time](https://github.com/openjdk/jdk/pull/7324#issuecomment-1063214518) as well] > - compiler/c2/irTests/TestAutoVectorization2DArray.java @backwaterred Sorry for replying late. Your test result edit slipped my attention. I'm sure you are right. We say this error before. With testing ok, it's _only_ about reviews now. Might prove difficult. Btw: did you have a look at the performance test results? They are multi-platform. And s390 doesn't look too bad. :-) ------------- PR: https://git.openjdk.java.net/jdk/pull/8142 From ihse at openjdk.java.net Tue Apr 19 14:04:25 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 19 Apr 2022 14:04:25 GMT Subject: RFR: 8284903: Fix typos in hotspot In-Reply-To: References: Message-ID: On Fri, 15 Apr 2022 07:40:04 GMT, Magnus Ihse Bursie wrote: > I ran `codespell` on hotspot, and accepted those changes where it indeed discovered real typos. > > You'd be surprised over the many implementions of instrinsics and other intructions accross all archtectures I've encounted, so for the preceding reason it's neccesery to sucessfully seach for exisiting typos... Thank you for all your input! I will update the PR according to all suggestions. But let me answer a few more general comments first. The spelling corrections in this PR was generated by codespell. I manually removed all false positives (that was the most tedious part of this fix). Codespell works by checking a list of commonly misspelled words, not by verifying that all words are present in a list of accepted spellings. The latter approach might work for normal prose, but is utterly worthless for source code. In practice, codespell does automatically what several users have been doing manually lately -- discover a common misspelling, searching the code base for more instances of that misspelling. So, there are certainly lots of typos left. But this should reasonably cut down on the number of PRs of the type "Fix typos for supercalifragilisticexpialidocious" that updates a lot of files for just a single misspelled word. For some cases where I were not sure (like mismatch or re-enable), I googled, read spelling recommendations and/or checked how common alternative spellings where. When the ratio exceeded 10:1 or so, I deemed one alternative as "correct"; in less common cases I let the original authors choice of spelling remain. I have not read the complete sentences, just verified that the actual word fixes seemed to make sense. Hence the odd results in some places. Ideally, I would like to find some way of keeping the code "codespell clean" using tooling. Due to the amount of false positives, this is not a trivial task. I don't think we'll ever be able to have it as part of jcheck, but we might have a script that someone runs once per release or so. I'm not yet sure how to achieve this, but my two main ideas is to either just run codespell on added or modified code (think "+" lines in git diff), or to have a list of acknowledged false positives that should be skipped. Before I can even start on this, the huge number of *true* positives needs to be addressed, though! Hotspot is by no means worst, it's just a huge chunk of code which I addressed all at once. ------------- PR: https://git.openjdk.java.net/jdk/pull/8260 From kvn at openjdk.java.net Tue Apr 19 16:09:25 2022 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Tue, 19 Apr 2022 16:09:25 GMT Subject: RFR: JDK-8075816: Deprecate AliasLevel flag since it is broken [v3] In-Reply-To: References: Message-ID: On Thu, 14 Apr 2022 17:04:24 GMT, Tobias Holenstein wrote: >> Deprecate the `AliasLevel` flag. `AliasLevel` can have the following values: >> >> "0 - for no aliasing, " >> "1 - for oop/field/static/array split, " >> "2 - for class split, " >> "3 - for unique instances" >> >> - Deprecate AliasLevel in JDK 19. >> - Obsolete it in JDK 20 >> - Expire it in JDK 21. >> >> Users will now get the following message when running: >> `java -XX:AliasLevel= Java HotSpot(TM) 64-Bit Server VM warning: Option AliasLevel was deprecated in version 19.0 and will likely be removed in a future release.` > > Tobias Holenstein has updated the pull request incrementally with one additional commit since the last revision: > > Revert "Obsolete AliasLevel flag" > > This reverts commit 6a1bed2d7ed5494b051fae09d28787fd01de9635. Good. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8140 From aph at openjdk.java.net Tue Apr 19 16:39:14 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Tue, 19 Apr 2022 16:39:14 GMT Subject: RFR: 8282541: AArch64: Auto-vectorize Math.round API [v3] In-Reply-To: References: Message-ID: > Before, Apple M1: > > +-----------------------------------------+---------------------------------+ > |Benchmark | (TESTSIZE) Mode Score Units| > +-----------------------------------------+---------------------------------+ > |FpRoundingBenchmark.test_round_double | 1024 thrpt 1612.391 ops/ms| > |FpRoundingBenchmark.test_round_double | 2048 thrpt 804.291 ops/ms| > |FpRoundingBenchmark.test_round_float | 1024 thrpt 1558.202 ops/ms| > |FpRoundingBenchmark.test_round_float | 2048 thrpt 775.730 ops/ms| > +------------------------------------------+--------------------------------+ > > After: > > +-----------------------------------------+----------------------------------+ > |Benchmark | (TESTSIZE) Mode Score Units| > +-----------------------------------------+----------------------------------+ > |FpRoundingBenchmark.test_round_double | 1024 thrpt 2720.153 ops/ms| > |FpRoundingBenchmark.test_round_double | 2048 thrpt 1371.750 ops/ms| > |FpRoundingBenchmark.test_round_float | 1024 thrpt 5940.263 ops/ms| > |FpRoundingBenchmark.test_round_float | 2048 thrpt 3036.201 ops/ms| > +-----------------------------------------+----------------------------------+ > > About the algorithm: > > `Math.round()` is tricky. Its specification corresponds to no standard > rounding mode: it "returns the closest long to the argument, with ties > rounding to positive infinity." For positive inputs this is the same > as IEEE-754's `convertToIntegerTiesToAway` operation, which rounds > away from zero, but there's no equivalent for negative inputs. > > `Math.round()` used simply to add 0.5 and convert to integer by taking > the floor of the result, but that wasn't right because it suffers from > double rounding. This breaks several cases, in particular because > > `0.4999999... (+) 0.5 == 1.0` > > (Here, `(+)` indicates an addition followed by roundTiesToEven.) > > There is no corresponding problem with `-0.4999999...` or `-0.9999999...` > > Also, in the 32-bit `float` case, > > `8388609 (+) 0.5 == 8388610` > > because 8388609 (0x1.000002p+23) as a 32-bit integer has no fraction > bits, so adding 0.5, followed by roundTiesToEven, rounds upwards. This > problem manifests for every odd integer within the binade from > 0x1.000002p+23 to 0x1.fffffep+23, whether positive or negative. There > is a corresponding problem for the `double` range. > > The patch for JDK-8279508 handles this by flipping the floating-point > rounding mode to roundTowardNegative, adding 0.5, and taking the > floor. While this does work on AArch64, the performance is > tragic. AArch64 implementations seem to wait for all instructions in > flight to retire, change the rounding mode, and do the operation. This > effectively serializes the entire thread. > > This patch takes a different approach. Firstly, we can observe that we > can use the `frinta` instruction for the entire positive range. The > negative range is a bit trickier, but we can observe that any x, > abs{x) >= -0x1.000000p+23, has no fractional bits so it must be an > integer. For convenence, we can convert that range with the `frinta` > instruction as well. > > All that remains are x < 0, abs{x) < -0x1.000000p+23. Adding 0.5 > followed by roundTiesToEven doesn't lead to a problem because for > x < 0 && abs{x) >= 0.5, adding 0.5 only reduces the magnitude of x; > for all x < 0 && abs{x) < 0.5, adding 0.5 followed by roundTiesToEven > return 0. Andrew Haley has updated the pull request incrementally with two additional commits since the last revision: - Put all SVE-mode ops in aarch64_sve.ad. - Move size extimate for Op_RoundXX to matcher. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8204/files - new: https://git.openjdk.java.net/jdk/pull/8204/files/1a43443a..c365b3ff Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8204&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8204&range=01-02 Stats: 144 lines in 10 files changed: 52 ins; 55 del; 37 mod Patch: https://git.openjdk.java.net/jdk/pull/8204.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8204/head:pull/8204 PR: https://git.openjdk.java.net/jdk/pull/8204 From aph at openjdk.java.net Tue Apr 19 16:45:27 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Tue, 19 Apr 2022 16:45:27 GMT Subject: RFR: 8282541: AArch64: Auto-vectorize Math.round API [v3] In-Reply-To: References: <88RK-3hLy6Q3WdSNYrHqvdjqMnXtk7FhEBsPhNAADeE=.d35f4b9a-b161-470c-b73d-32e58aa68e3e@github.com> <_SuC-IP3rF6aHB_Ii8q5uozKoTA3Y0FJxrTw1Hf907Q=.d2db969f-9569-4712-98c1-cabf93ac9139@github.com> Message-ID: On Fri, 15 Apr 2022 08:14:37 GMT, Andrew Haley wrote: >> OK, thanks! Looks reasonable to me. We are going to make all vecX/vecD regs to vReg, I think that should make SIMD code cleaner. >> >> Currently all rules for vReg are in aarch64_sve.ad. And since the codegen is actually for SVE target, though generates ASIMD insns, perhaps move these rules to aarch64_sve.ad would be better? Also I think the 2F/4F rules could be merged into one, like: >> >> >> instruct vroundvRegF(vReg dst, vReg src, vReg tmp1, vReg tmp2, vReg tmp3) >> %{ >> predicate(n->as_Vector()->length_in_bytes() <= 16); >> match(Set dst (RoundVF src)); >> effect(TEMP_DEF dst, TEMP tmp1, TEMP tmp2, TEMP tmp3); >> format %{ "vround $dst, $src\t# round vReg F to I vector" %} >> ins_encode %{ >> uint size = Matcher::vector_length_in_bytes(this); >> __ vector_round_neon(as_FloatRegister($dst$$reg), as_FloatRegister($src$$reg), >> as_FloatRegister($tmp1$$reg), as_FloatRegister($tmp2$$reg), >> as_FloatRegister($tmp3$$reg), (size == 16) ? __ T4S : __ T2S); >> %} >> ins_pipe(pipe_slow); >> %} > > Seems reasonable. Maybe we could the logic down into MacroAssembler. That way there'd be one point at which the SVE/Neon devcision was made, in MacroAssembler. The disadvantage would be that Neon and SVE versions require different register clobbers, but that might not matter. Hi, do you like it better now? Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/8204 From lkorinth at openjdk.java.net Tue Apr 19 16:49:12 2022 From: lkorinth at openjdk.java.net (Leo Korinth) Date: Tue, 19 Apr 2022 16:49:12 GMT Subject: RFR: 8269537: memset() is called after operator new [v5] In-Reply-To: References: Message-ID: > The basic problem is that we are relying on undefined behaviour, as documented in the code: > > // This whole business of passing information from ResourceObj::operator new > // to the ResourceObj constructor via fields in the "object" is technically UB. > // But it seems to work within the limitations of HotSpot usage (such as no > // multiple inheritance) with the compilers and compiler options we're using. > // And it gives some possibly useful checking for misuse of ResourceObj. > > > I am removing the undefined behaviour by passing the type of allocation through a thread local variable. > > This solution has some advantages: > 1) it is not UB > 2) it is simpler and easier to understand > 3) it uses less memory (I could make it use even less if I made the enum `allocation_type` a u8) > 4) in the *very* unlikely situation that stack memory (or embedded) already equals the data calculated from the address of the object, the code will also work. > > When doing the change, I also updated `allocated_on_stack()` to the new name `allocated_on_stack_or_embedded()` which is much harder to misinterpret. > > I also disallow to "fake" the memory type by explicitly calling `ResourceObj::set_allocation_type`. > > This forced me to change two places that is faking the allocation type of an embedded `GrowableArray` from `STACK_OR_EMBEDDED` to `C_HEAP`. The faking of the type is hard to understand as a `STACK_OR_EMBEDDED` `GrowableArray` can allocate any type of object. My guess is that `GrowableArray` has changed behaviour, or maybe that it was hard to understand because the old naming of `allocated_on_stack()`. > > I have also tried to update the comments. In doing that I not only changed the comments for this change, but also for the *incorrect* advice to always delete object you allocate with new. > > Testing on debug build tier1-3 > Testing on release build tier1 Leo Korinth has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: - Merge branch 'master' into _8269537 - Merge branch 'master' into _8269537 - review updates - Use a thread local buffer so that the compiler might reorder operator new. - First update * Change backing type of ResourceObj::allocation_type to be u8. Also remove no longer needed mask and explicit zero value of STACK_OR_EMBEDDED value. * Now setting allocation type with set_type() with assert. - 8269537: memset() is called after operator new ------------- Changes: https://git.openjdk.java.net/jdk/pull/5387/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5387&range=04 Stats: 174 lines in 8 files changed: 48 ins; 93 del; 33 mod Patch: https://git.openjdk.java.net/jdk/pull/5387.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5387/head:pull/5387 PR: https://git.openjdk.java.net/jdk/pull/5387 From mchung at openjdk.java.net Tue Apr 19 16:52:34 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 19 Apr 2022 16:52:34 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v4] In-Reply-To: References: <_TWRNeLakN4zFnF3jIC_2ezkgvSzl-9O5xtV7qI-NDA=.b07a1c1a-edc1-4078-b580-a065a28a7b1f@github.com> Message-ID: On Tue, 19 Apr 2022 10:49:14 GMT, Alan Bateman wrote: >> src/java.base/share/classes/java/lang/ref/ReferenceQueue.java line 61: >> >>> 59: private final Condition notEmpty; >>> 60: >>> 61: void signal() { notEmpty.signalAll(); } >> >> `signal()`, `await()` and `await(long)` methods are only used by `ReferenceQueue`. Good to make them private. > > They are overridden so can't be private. That's right, I missed it. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From lkorinth at openjdk.java.net Tue Apr 19 16:53:38 2022 From: lkorinth at openjdk.java.net (Leo Korinth) Date: Tue, 19 Apr 2022 16:53:38 GMT Subject: RFR: 8269537: memset() is called after operator new [v5] In-Reply-To: References: Message-ID: On Tue, 19 Apr 2022 16:49:12 GMT, Leo Korinth wrote: >> The basic problem is that we are relying on undefined behaviour, as documented in the code: >> >> // This whole business of passing information from ResourceObj::operator new >> // to the ResourceObj constructor via fields in the "object" is technically UB. >> // But it seems to work within the limitations of HotSpot usage (such as no >> // multiple inheritance) with the compilers and compiler options we're using. >> // And it gives some possibly useful checking for misuse of ResourceObj. >> >> >> I am removing the undefined behaviour by passing the type of allocation through a thread local variable. >> >> This solution has some advantages: >> 1) it is not UB >> 2) it is simpler and easier to understand >> 3) it uses less memory (I could make it use even less if I made the enum `allocation_type` a u8) >> 4) in the *very* unlikely situation that stack memory (or embedded) already equals the data calculated from the address of the object, the code will also work. >> >> When doing the change, I also updated `allocated_on_stack()` to the new name `allocated_on_stack_or_embedded()` which is much harder to misinterpret. >> >> I also disallow to "fake" the memory type by explicitly calling `ResourceObj::set_allocation_type`. >> >> This forced me to change two places that is faking the allocation type of an embedded `GrowableArray` from `STACK_OR_EMBEDDED` to `C_HEAP`. The faking of the type is hard to understand as a `STACK_OR_EMBEDDED` `GrowableArray` can allocate any type of object. My guess is that `GrowableArray` has changed behaviour, or maybe that it was hard to understand because the old naming of `allocated_on_stack()`. >> >> I have also tried to update the comments. In doing that I not only changed the comments for this change, but also for the *incorrect* advice to always delete object you allocate with new. >> >> Testing on debug build tier1-3 >> Testing on release build tier1 > > Leo Korinth has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - Merge branch 'master' into _8269537 > - Merge branch 'master' into _8269537 > - review updates > - Use a thread local buffer so that the compiler might reorder operator new. > - First update > > * Change backing type of ResourceObj::allocation_type to be u8. Also remove no longer needed mask and explicit zero value of STACK_OR_EMBEDDED value. > > * Now setting allocation type with set_type() with assert. > - 8269537: memset() is called after operator new Rebased. I think my approach is better than the current. I think we would be better off without tracking the allocation type at all though, so please consider that approach as well. ------------- PR: https://git.openjdk.java.net/jdk/pull/5387 From lucy at openjdk.java.net Tue Apr 19 17:32:25 2022 From: lucy at openjdk.java.net (Lutz Schmidt) Date: Tue, 19 Apr 2022 17:32:25 GMT Subject: RFR: 8284903: Fix typos in hotspot In-Reply-To: References: Message-ID: On Fri, 15 Apr 2022 07:40:04 GMT, Magnus Ihse Bursie wrote: > I ran `codespell` on hotspot, and accepted those changes where it indeed discovered real typos. > > You'd be surprised over the many implementions of instrinsics and other intructions accross all archtectures I've encounted, so for the preceding reason it's neccesery to sucessfully seach for exisiting typos... This is a partial approval for - cpu/ppc - cpu/s390 - os/aix - os_cpu/aix_ppc - os_cpu/linux_ppc - os_cpu/linux_s390 Thank you for completing this tedious job! ------------- Marked as reviewed by lucy (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8260 From stefank at openjdk.java.net Tue Apr 19 18:06:25 2022 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Tue, 19 Apr 2022 18:06:25 GMT Subject: RFR: 8284903: Fix typos in hotspot In-Reply-To: References: Message-ID: On Fri, 15 Apr 2022 07:40:04 GMT, Magnus Ihse Bursie wrote: > I ran `codespell` on hotspot, and accepted those changes where it indeed discovered real typos. > > You'd be surprised over the many implementions of instrinsics and other intructions accross all archtectures I've encounted, so for the preceding reason it's neccesery to sucessfully seach for exisiting typos... Reviewed: - gc/ - oops/ - utilities/ ------------- Marked as reviewed by stefank (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8260 From ihse at openjdk.java.net Tue Apr 19 19:08:26 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 19 Apr 2022 19:08:26 GMT Subject: RFR: 8284903: Fix typos in hotspot [v2] In-Reply-To: References: Message-ID: > I ran `codespell` on hotspot, and accepted those changes where it indeed discovered real typos. > > You'd be surprised over the many implementions of instrinsics and other intructions accross all archtectures I've encounted, so for the preceding reason it's neccesery to sucessfully seach for exisiting typos... Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Fix some places according to code reviews ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8260/files - new: https://git.openjdk.java.net/jdk/pull/8260/files/449d8a23..28bb365f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8260&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8260&range=00-01 Stats: 9 lines in 8 files changed: 0 ins; 1 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/8260.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8260/head:pull/8260 PR: https://git.openjdk.java.net/jdk/pull/8260 From ihse at openjdk.java.net Tue Apr 19 19:13:03 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 19 Apr 2022 19:13:03 GMT Subject: RFR: 8284903: Fix typos in hotspot [v3] In-Reply-To: References: Message-ID: <3Is0RhXgzstSAZW41f6AGki3RZtWmBm8x4yuRZSz4OE=.da5d7f88-92e4-4a3f-9e5c-407d768d3618@github.com> > I ran `codespell` on hotspot, and accepted those changes where it indeed discovered real typos. > > You'd be surprised over the many implementions of instrinsics and other intructions accross all archtectures I've encounted, so for the preceding reason it's neccesery to sucessfully seach for exisiting typos... Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Update copyright headers ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8260/files - new: https://git.openjdk.java.net/jdk/pull/8260/files/28bb365f..4fc36d6b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8260&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8260&range=01-02 Stats: 287 lines in 287 files changed: 0 ins; 0 del; 287 mod Patch: https://git.openjdk.java.net/jdk/pull/8260.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8260/head:pull/8260 PR: https://git.openjdk.java.net/jdk/pull/8260 From ihse at openjdk.java.net Tue Apr 19 19:14:02 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 19 Apr 2022 19:14:02 GMT Subject: Integrated: 8284903: Fix typos in hotspot In-Reply-To: References: Message-ID: On Fri, 15 Apr 2022 07:40:04 GMT, Magnus Ihse Bursie wrote: > I ran `codespell` on hotspot, and accepted those changes where it indeed discovered real typos. > > You'd be surprised over the many implementions of instrinsics and other intructions accross all archtectures I've encounted, so for the preceding reason it's neccesery to sucessfully seach for exisiting typos... This pull request has now been integrated. Changeset: 4594696f Author: Magnus Ihse Bursie URL: https://git.openjdk.java.net/jdk/commit/4594696f5462995ec58ca1d2c1bde7cc857c5caf Stats: 1197 lines in 446 files changed: 0 ins; 1 del; 1196 mod 8284903: Fix typos in hotspot Reviewed-by: cjplummer, coleenp, kvn, lucy, stefank ------------- PR: https://git.openjdk.java.net/jdk/pull/8260 From duke at openjdk.java.net Tue Apr 19 22:04:28 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Tue, 19 Apr 2022 22:04:28 GMT Subject: RFR: 8283643: [AIX, testbug] MachCodeFramesInErrorFile test fails to find 'Native frames' text In-Reply-To: References: Message-ID: On Mon, 4 Apr 2022 15:47:06 GMT, Tyler Steele wrote: > I observed a failure of MachCodeFramesInErrorFile.java on AIX. The raised error complains that 'Native frames: ' is missing. To fix the failure, I made two changes to the test that allowed it to pass on AIX. > > The first change made was to the test's `extractFrames` method. AIX overrides `os::platform_print_native_stack` with stack printing specific to AIX/Power. This code does not produce the 'Native frames: ' text that `vmError::print_native_stack` does, so the test was modified to expect the AIX output when run on AIX. > > A second change was made to the address passed to the `crashInNative1` method. AIX does not consider low-address memory to be protected as other platforms do. In fact, "the first 256 bytes are reserved for software use" according to the Power ISA. Accordingly, the read address for PPC was changed to -1 (0xFF..FF) to produce the expected failure result. > > ### Testing > > Tier1 tests complete as expected on AIX/Power. Hi Thomas, > in the JVM we have `VMError::segfault_address` for this reason. I'd prefer if we reused that (publishing it via Whitebox method) instead of polluting the shared tests with PPC specifics. We could reuse this whitebox method in other tests, actually, without running into the NULL-is-readable issue again. > > (To see how whitebox methods are used, see the classes in sun.hotspot.WhiteBox and their corresponding "WB_..." endpoints in hotspot/share/prims/whitebox.cpp. Its all pretty straightforward). I like this idea. It's not really reasonable to expect that everyone will keep track of all the little nuances between the different systems, and it's easier if we solve the problem one way and use it in multiple places. I will take a look at this. > Another, maybe simpler option would be just to write instead of read in `crashInNative3`. crashInJava3 uses write too (putLong). But it looks deliberate, so you'd have to look at the original RFR for this test. Tried that ;-) Your intuition is good; the crash produces slightly different output than the test expects. ------------- PR: https://git.openjdk.java.net/jdk/pull/8094 From duke at openjdk.java.net Tue Apr 19 22:14:26 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Tue, 19 Apr 2022 22:14:26 GMT Subject: RFR: 8283643: [AIX, testbug] MachCodeFramesInErrorFile test fails to find 'Native frames' text In-Reply-To: References: Message-ID: On Tue, 19 Apr 2022 09:02:54 GMT, Martin Doerr wrote: >> I observed a failure of MachCodeFramesInErrorFile.java on AIX. The raised error complains that 'Native frames: ' is missing. To fix the failure, I made two changes to the test that allowed it to pass on AIX. >> >> The first change made was to the test's `extractFrames` method. AIX overrides `os::platform_print_native_stack` with stack printing specific to AIX/Power. This code does not produce the 'Native frames: ' text that `vmError::print_native_stack` does, so the test was modified to expect the AIX output when run on AIX. >> >> A second change was made to the address passed to the `crashInNative1` method. AIX does not consider low-address memory to be protected as other platforms do. In fact, "the first 256 bytes are reserved for software use" according to the Power ISA. Accordingly, the read address for PPC was changed to -1 (0xFF..FF) to produce the expected failure result. >> >> ### Testing >> >> Tier1 tests complete as expected on AIX/Power. > > test/hotspot/jtreg/runtime/ErrorHandling/MachCodeFramesInErrorFile.java line 177: > >> 175: } else { >> 176: marker = (nativeStack ? "Native" : "Java") + " frames: "; >> 177: } > > Yeah, we have special stack trace code on AIX. Ok. ?? > test/hotspot/jtreg/runtime/ErrorHandling/MachCodeFramesInErrorFile.java line 189: > >> 187: } >> 188: } >> 189: throw new RuntimeException("\"" + marker + "\" line missing in hs_err_pid file:\n"); > > Please explain removal! OK! This was an odd one; I was getting errors that complained about the length of the message in the exception. It looked like 2^16 was the max number of characters that could be included in a RuntimeException. I haven't found the upper limit documented anywhere, but I would get unexpected failures with it included in the message. The text prints to stdout, so I didn't suffer by removing it. ------------- PR: https://git.openjdk.java.net/jdk/pull/8094 From duke at openjdk.java.net Tue Apr 19 22:18:28 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Tue, 19 Apr 2022 22:18:28 GMT Subject: RFR: 8283643: [AIX, testbug] MachCodeFramesInErrorFile test fails to find 'Native frames' text In-Reply-To: References: Message-ID: On Tue, 19 Apr 2022 09:01:40 GMT, Martin Doerr wrote: >> I observed a failure of MachCodeFramesInErrorFile.java on AIX. The raised error complains that 'Native frames: ' is missing. To fix the failure, I made two changes to the test that allowed it to pass on AIX. >> >> The first change made was to the test's `extractFrames` method. AIX overrides `os::platform_print_native_stack` with stack printing specific to AIX/Power. This code does not produce the 'Native frames: ' text that `vmError::print_native_stack` does, so the test was modified to expect the AIX output when run on AIX. >> >> A second change was made to the address passed to the `crashInNative1` method. AIX does not consider low-address memory to be protected as other platforms do. In fact, "the first 256 bytes are reserved for software use" according to the Power ISA. Accordingly, the read address for PPC was changed to -1 (0xFF..FF) to produce the expected failure result. >> >> ### Testing >> >> Tier1 tests complete as expected on AIX/Power. > > test/hotspot/jtreg/runtime/ErrorHandling/MachCodeFramesInErrorFile.java line 75: > >> 73: assert args[0].equals("crashInVM"); >> 74: // AIX does not prohibit low address reads >> 75: crashInNative1( Platform.isPPC() ? -1 : 10 ); > > Spaces next to braces are uncommon. I will drop them. ------------- PR: https://git.openjdk.java.net/jdk/pull/8094 From eliu at openjdk.java.net Wed Apr 20 00:59:38 2022 From: eliu at openjdk.java.net (Eric Liu) Date: Wed, 20 Apr 2022 00:59:38 GMT Subject: Integrated: 8284563: AArch64: bitperm feature detection for SVE2 on Linux In-Reply-To: References: Message-ID: On Fri, 15 Apr 2022 05:45:58 GMT, Eric Liu wrote: > This patch adds BITPERM feature detection for SVE2 on Linux. BITPERM is > an optional feature in SVE2 [1]. It enables 3 SVE2 instructions (BEXT, > BDEP, BGRP). BEXT and BDEP map efficiently to some vector operations, > e.g., the compress and expand functionalities [2] which are proposed in > VectorAPI's 4th incubation [3]. Besides, to generate specific code based > on different architecture features like x86, this patch exports > VM_Version::supports_XXX() for all CPU features. E.g., > VM_Version::supports_svebitperm() for easy use. > > This patch also fixes a trivial bug, that sets UseSVE back to 1 if it's > 2 in SVE1 system. > > [1] https://developer.arm.com/documentation/ddi0601/2022-03/AArch64-Registers/ID-AA64ZFR0-EL1--SVE-Feature-ID-register-0 > [2] https://bugs.openjdk.java.net/browse/JDK-8283893 > [3] https://bugs.openjdk.java.net/browse/JDK-8280173 This pull request has now been integrated. Changeset: 72726c41 Author: Eric Liu Committer: Pengfei Li URL: https://git.openjdk.java.net/jdk/commit/72726c41829b33fd2baf5b3604cab49d39489dd2 Stats: 70 lines in 6 files changed: 23 ins; 1 del; 46 mod 8284563: AArch64: bitperm feature detection for SVE2 on Linux Reviewed-by: aph, njian ------------- PR: https://git.openjdk.java.net/jdk/pull/8258 From xgong at openjdk.java.net Wed Apr 20 02:49:27 2022 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Wed, 20 Apr 2022 02:49:27 GMT Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE with predicate feature In-Reply-To: References: <35S4J_r9jBw_-SAow2oMYaSsTvubhSmZFVPb_VM6KEg=.7feff8fa-6e20-453e-aed6-e53c7d9beaad@github.com> <8Yu4J-PCYFJtBXrfgWoCbaR-7QZTXH4IzmXOf_lk164=.66071c45-1f1a-4931-a414-778f353c7e83@github.com> Message-ID: On Mon, 11 Apr 2022 09:04:36 GMT, Jatin Bhateja wrote: >> The optimization for masked store is recorded to: https://bugs.openjdk.java.net/browse/JDK-8284050 > >> The blend should be with the intended-to-store vector, so that masked lanes contain the need-to-store elements and unmasked lanes contain the loaded elements, which would be stored back, which results in unchanged values. > > It may not work if memory is beyond legal accessible address space of the process, a corner case could be a page boundary. Thus re-composing the intermediated vector which partially contains actual updates but effectively perform full vector write to destination address may not work in all scenarios. Thanks for the comment! So how about adding the check for the valid array range like the masked vector load? Codes like: public final void intoArray(byte[] a, int offset, VectorMask m) { if (m.allTrue()) { intoArray(a, offset); } else { ByteSpecies vsp = vspecies(); if (offset >= 0 && offset <= (a.length - vsp.length())) { // a full range check intoArray0(a, offset, m, /* usePred */ false); // can be vectorized by load+blend_store } else { checkMaskFromIndexSize(offset, vsp, m, 1, a.length); intoArray0(a, offset, m, /* usePred */ true); // only be vectorized by the predicated store } } } ------------- PR: https://git.openjdk.java.net/jdk/pull/8035 From xgong at openjdk.java.net Wed Apr 20 02:49:28 2022 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Wed, 20 Apr 2022 02:49:28 GMT Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE with predicate feature In-Reply-To: References: Message-ID: On Sat, 9 Apr 2022 00:10:40 GMT, Sandhya Viswanathan wrote: >> Currently the vector load with mask when the given index happens out of the array boundary is implemented with pure java scalar code to avoid the IOOBE (IndexOutOfBoundaryException). This is necessary for architectures that do not support the predicate feature. Because the masked load is implemented with a full vector load and a vector blend applied on it. And a full vector load will definitely cause the IOOBE which is not valid. However, for architectures that support the predicate feature like SVE/AVX-512/RVV, it can be vectorized with the predicated load instruction as long as the indexes of the masked lanes are within the bounds of the array. For these architectures, loading with unmasked lanes does not raise exception. >> >> This patch adds the vectorization support for the masked load with IOOBE part. Please see the original java implementation (FIXME: optimize): >> >> >> @ForceInline >> public static >> ByteVector fromArray(VectorSpecies species, >> byte[] a, int offset, >> VectorMask m) { >> ByteSpecies vsp = (ByteSpecies) species; >> if (offset >= 0 && offset <= (a.length - species.length())) { >> return vsp.dummyVector().fromArray0(a, offset, m); >> } >> >> // FIXME: optimize >> checkMaskFromIndexSize(offset, vsp, m, 1, a.length); >> return vsp.vOp(m, i -> a[offset + i]); >> } >> >> Since it can only be vectorized with the predicate load, the hotspot must check whether the current backend supports it and falls back to the java scalar version if not. This is different from the normal masked vector load that the compiler will generate a full vector load and a vector blend if the predicate load is not supported. So to let the compiler make the expected action, an additional flag (i.e. `usePred`) is added to the existing "loadMasked" intrinsic, with the value "true" for the IOOBE part while "false" for the normal load. And the compiler will fail to intrinsify if the flag is "true" and the predicate load is not supported by the backend, which means that normal java path will be executed. >> >> Also adds the same vectorization support for masked: >> - fromByteArray/fromByteBuffer >> - fromBooleanArray >> - fromCharArray >> >> The performance for the new added benchmarks improve about `1.88x ~ 30.26x` on the x86 AVX-512 system: >> >> Benchmark before After Units >> LoadMaskedIOOBEBenchmark.byteLoadArrayMaskIOOBE 737.542 1387.069 ops/ms >> LoadMaskedIOOBEBenchmark.doubleLoadArrayMaskIOOBE 118.366 330.776 ops/ms >> LoadMaskedIOOBEBenchmark.floatLoadArrayMaskIOOBE 233.832 6125.026 ops/ms >> LoadMaskedIOOBEBenchmark.intLoadArrayMaskIOOBE 233.816 7075.923 ops/ms >> LoadMaskedIOOBEBenchmark.longLoadArrayMaskIOOBE 119.771 330.587 ops/ms >> LoadMaskedIOOBEBenchmark.shortLoadArrayMaskIOOBE 431.961 939.301 ops/ms >> >> Similar performance gain can also be observed on 512-bit SVE system. > > src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java line 2861: > >> 2859: ByteSpecies vsp = (ByteSpecies) species; >> 2860: if (offset >= 0 && offset <= (a.length - species.vectorByteSize())) { >> 2861: return vsp.dummyVector().fromByteArray0(a, offset, m, /* usePred */ false).maybeSwap(bo); > > Instead of usePred a term like inRange or offetInRage or offsetInVectorRange would be easier to follow. Thanks for the review. I will change it later. ------------- PR: https://git.openjdk.java.net/jdk/pull/8035 From njian at openjdk.java.net Wed Apr 20 04:01:45 2022 From: njian at openjdk.java.net (Ningsheng Jian) Date: Wed, 20 Apr 2022 04:01:45 GMT Subject: RFR: 8282541: AArch64: Auto-vectorize Math.round API [v3] In-Reply-To: References: Message-ID: On Tue, 19 Apr 2022 16:39:14 GMT, Andrew Haley wrote: >> Before, Apple M1: >> >> +-----------------------------------------+---------------------------------+ >> |Benchmark | (TESTSIZE) Mode Score Units| >> +-----------------------------------------+---------------------------------+ >> |FpRoundingBenchmark.test_round_double | 1024 thrpt 1612.391 ops/ms| >> |FpRoundingBenchmark.test_round_double | 2048 thrpt 804.291 ops/ms| >> |FpRoundingBenchmark.test_round_float | 1024 thrpt 1558.202 ops/ms| >> |FpRoundingBenchmark.test_round_float | 2048 thrpt 775.730 ops/ms| >> +------------------------------------------+--------------------------------+ >> >> After: >> >> +-----------------------------------------+----------------------------------+ >> |Benchmark | (TESTSIZE) Mode Score Units| >> +-----------------------------------------+----------------------------------+ >> |FpRoundingBenchmark.test_round_double | 1024 thrpt 2720.153 ops/ms| >> |FpRoundingBenchmark.test_round_double | 2048 thrpt 1371.750 ops/ms| >> |FpRoundingBenchmark.test_round_float | 1024 thrpt 5940.263 ops/ms| >> |FpRoundingBenchmark.test_round_float | 2048 thrpt 3036.201 ops/ms| >> +-----------------------------------------+----------------------------------+ >> >> About the algorithm: >> >> `Math.round()` is tricky. Its specification corresponds to no standard >> rounding mode: it "returns the closest long to the argument, with ties >> rounding to positive infinity." For positive inputs this is the same >> as IEEE-754's `convertToIntegerTiesToAway` operation, which rounds >> away from zero, but there's no equivalent for negative inputs. >> >> `Math.round()` used simply to add 0.5 and convert to integer by taking >> the floor of the result, but that wasn't right because it suffers from >> double rounding. This breaks several cases, in particular because >> >> `0.4999999... (+) 0.5 == 1.0` >> >> (Here, `(+)` indicates an addition followed by roundTiesToEven.) >> >> There is no corresponding problem with `-0.4999999...` or `-0.9999999...` >> >> Also, in the 32-bit `float` case, >> >> `8388609 (+) 0.5 == 8388610` >> >> because 8388609 (0x1.000002p+23) as a 32-bit integer has no fraction >> bits, so adding 0.5, followed by roundTiesToEven, rounds upwards. This >> problem manifests for every odd integer within the binade from >> 0x1.000002p+23 to 0x1.fffffep+23, whether positive or negative. There >> is a corresponding problem for the `double` range. >> >> The patch for JDK-8279508 handles this by flipping the floating-point >> rounding mode to roundTowardNegative, adding 0.5, and taking the >> floor. While this does work on AArch64, the performance is >> tragic. AArch64 implementations seem to wait for all instructions in >> flight to retire, change the rounding mode, and do the operation. This >> effectively serializes the entire thread. >> >> This patch takes a different approach. Firstly, we can observe that we >> can use the `frinta` instruction for the entire positive range. The >> negative range is a bit trickier, but we can observe that any x, >> abs{x) >= -0x1.000000p+23, has no fractional bits so it must be an >> integer. For convenence, we can convert that range with the `frinta` >> instruction as well. >> >> All that remains are x < 0, abs{x) < -0x1.000000p+23. Adding 0.5 >> followed by roundTiesToEven doesn't lead to a problem because for >> x < 0 && abs{x) >= 0.5, adding 0.5 only reduces the magnitude of x; >> for all x < 0 && abs{x) < 0.5, adding 0.5 followed by roundTiesToEven >> return 0. > > Andrew Haley has updated the pull request incrementally with two additional commits since the last revision: > > - Put all SVE-mode ops in aarch64_sve.ad. > - Move size extimate for Op_RoundXX to matcher. Marked as reviewed by njian (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8204 From njian at openjdk.java.net Wed Apr 20 04:01:47 2022 From: njian at openjdk.java.net (Ningsheng Jian) Date: Wed, 20 Apr 2022 04:01:47 GMT Subject: RFR: 8282541: AArch64: Auto-vectorize Math.round API [v3] In-Reply-To: References: <88RK-3hLy6Q3WdSNYrHqvdjqMnXtk7FhEBsPhNAADeE=.d35f4b9a-b161-470c-b73d-32e58aa68e3e@github.com> <_SuC-IP3rF6aHB_Ii8q5uozKoTA3Y0FJxrTw1Hf907Q=.d2db969f-9569-4712-98c1-cabf93ac9139@github.com> Message-ID: On Tue, 19 Apr 2022 16:42:13 GMT, Andrew Haley wrote: > Hi, do you like it better now? Thanks. Yeah, looks good to me now! And the jmh results on some of our test systems (with and without SVE) look quite good. ------------- PR: https://git.openjdk.java.net/jdk/pull/8204 From stuefe at openjdk.java.net Wed Apr 20 05:52:22 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 20 Apr 2022 05:52:22 GMT Subject: RFR: 8283643: [AIX, testbug] MachCodeFramesInErrorFile test fails to find 'Native frames' text In-Reply-To: References: Message-ID: On Mon, 4 Apr 2022 15:47:06 GMT, Tyler Steele wrote: > I observed a failure of MachCodeFramesInErrorFile.java on AIX. The raised error complains that 'Native frames: ' is missing. To fix the failure, I made two changes to the test that allowed it to pass on AIX. > > The first change made was to the test's `extractFrames` method. AIX overrides `os::platform_print_native_stack` with stack printing specific to AIX/Power. This code does not produce the 'Native frames: ' text that `vmError::print_native_stack` does, so the test was modified to expect the AIX output when run on AIX. > > A second change was made to the address passed to the `crashInNative1` method. AIX does not consider low-address memory to be protected as other platforms do. In fact, "the first 256 bytes are reserved for software use" according to the Power ISA. Accordingly, the read address for PPC was changed to -1 (0xFF..FF) to produce the expected failure result. > > ### Testing > > Tier1 tests complete as expected on AIX/Power. BTW, feel free to tweak the native stack printing on os_aix.cpp to print "Native" etc like the other variants do. It is just cosmetics, and the less AIX specifics in shared code the better. Thanks for taking care of this! ------------- PR: https://git.openjdk.java.net/jdk/pull/8094 From dholmes at openjdk.java.net Wed Apr 20 06:17:43 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 20 Apr 2022 06:17:43 GMT Subject: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing [v9] In-Reply-To: References: Message-ID: On Thu, 14 Apr 2022 15:19:17 GMT, Johannes Bechberger wrote: >> Move the AsyncGetCallTrace method implementation into a separate method and wrap its call in non-assert compilation mode in `os::ThreadCrashProtection` like it is done in [JFR](https://github.com/openjdk/jdk/blob/965ea8d9cd29aee41ba2b1b0b0c67bb67eca22dd/src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp#L165). >> This prevents AsyncGetCallTrace from crashing on segmentation faults (but not on `guarantee`s). >> >> If a crash is observed, then the `num_frames` field of the trace is set to `ticks_unknown_state` (-7) to signal a state that cannot be properly handled. `ticks_unknown_state` is currently also used for signaling unknown thread states but this should not be a problem, as the semantic is the same. If `num_frames` already has an error code then this error code is not changed. This helps to distinguish between errors in walking threads in Java and non-Java mode, as `num_frames` is set there before the walking to the appropriate error code. >> >> _Thanks for @tstuefe for suggesting this._ > > Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: > > Use JavaThread::current_or_null Just for the record I was happy to return from vacation and see this had resolved into something not going forward. AGCT is a legacy mechanism that was created for one single unsupported purpose. It is inherently unsafe to hit a thread with a signal and then try to figure out what kind of introspection the thread can do upon itself. If you want to try and produce a more robust, "supported" version of AGCT then there needs to be a commitment of resources and support going forward - as would be established by the JEP process. ------------- PR: https://git.openjdk.java.net/jdk/pull/8225 From dholmes at openjdk.java.net Wed Apr 20 06:23:27 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 20 Apr 2022 06:23:27 GMT Subject: RFR: 8284903: Fix typos in hotspot [v2] In-Reply-To: References: Message-ID: On Tue, 19 Apr 2022 19:08:26 GMT, Magnus Ihse Bursie wrote: >> I ran `codespell` on hotspot, and accepted those changes where it indeed discovered real typos. >> >> You'd be surprised over the many implementions of instrinsics and other intructions accross all archtectures I've encounted, so for the preceding reason it's neccesery to sucessfully seach for exisiting typos... > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Fix some places according to code reviews src/hotspot/share/runtime/task.hpp line 72: > 70: void enroll(); > 71: > 72: // Make the task inactivate That should have been "inactive". ------------- PR: https://git.openjdk.java.net/jdk/pull/8260 From yyang at openjdk.java.net Wed Apr 20 07:00:24 2022 From: yyang at openjdk.java.net (Yi Yang) Date: Wed, 20 Apr 2022 07:00:24 GMT Subject: RFR: 8284877: Check type compatibility before looking up method from receiver's vtable In-Reply-To: References: Message-ID: On Tue, 19 Apr 2022 12:14:08 GMT, David Holmes wrote: >> Hi, can I have a review for this enhancement? This patch adds type compatibility check before method lookup for robustness. In some internal cases, serialization framework may improperly generate an object of wrong type, which leads JVM randomly crashes during method resolution. >> >> For example: >> >> invokevirtual selected method: receiver-class:java.util.ArrayList, resolved-class:com.taobao.forest.domain.util.LongMapSupportArrayList, resolved_method:com.taobao.forest.domain.util.LongMapSupportArrayList.toMap()Ljava/util/Map;, selected_method:0x458, vtable_index:56# >> >> The real type of receiver is ArrayList, while the resolved method is LongMapSupportArrayList.toMap. VM attempts to select method as if looking up from receiver's vtable via vtable index of resolved method(i.e. attempts to lookup `toMap()` from >> ArrayList), an invalid method or incorrect method would be selected, thus causing some strange crashes. >> >> I think it's reasonable to add a type compatibility check before method lookup. If such an incompatible call is found, JVM could throw an exception instead. > > Hi, > > This really needs a test case so we can understand exactly what is going on. Receiver type checking happens in a number of places so we need to understand how the problem arises and exactly what should be happening in that case per the JVMS. If this is a corrupt serialization stream then it may indicate a bug in the JDK deserialization code - again important to know. > > Thanks, > David Hi @dholmes-ora, I believe this is not a problem of JDK serialization because it uses a third-party library, this library deserializes an ill-typed object via Unsafe, which leads to some strange crashes, so this patch is not a Fix, but an Enhancement. This problem happens in production and I'm trying to reproduce it locally, but it's still not working, I'll keep trying. We preserved many debug information, it should be enough to tell what was going on at that time. The crash stacks are as follows: #1 Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x48ddc5] CompilationPolicy::can_be_compiled(methodHandle, int)+0x155 V [libjvm.so+0x490c81] CompilationPolicy::must_be_compiled(methodHandle, int)+0x91 V [libjvm.so+0x7e1d50] CallInfo::set_common(KlassHandle, KlassHandle, methodHandle, methodHandle, CallInfo::CallKind, int, Thread*)+0xa0 V [libjvm.so+0x7e2082] CallInfo::set_virtual(KlassHandle, KlassHandle, methodHandle, methodHandle, int, Thread*)+0xf2 V [libjvm.so+0x7e2627] LinkResolver::runtime_resolve_virtual_method(CallInfo&, methodHandle, KlassHandle, Handle, KlassHandle, bool, Thread*)+0x1e7 V [libjvm.so+0x7e2cf2] LinkResolver::resolve_virtual_call(CallInfo&, Handle, KlassHandle, KlassHandle, Symbol*, Symbol*, KlassHandle, bool, bool, Thread*)+0x152 V [libjvm.so+0x7e2f96] LinkResolver::resolve_invokevirtual(CallInfo&, Handle, constantPoolHandle, int, Thread*)+0x276 V [libjvm.so+0x7e760b] LinkResolver::resolve_invoke(CallInfo&, Handle, constantPoolHandle, int, Bytecodes::Code, Thread*)+0x20b V [libjvm.so+0x69777d] InterpreterRuntime::resolve_invoke(JavaThread*, Bytecodes::Code)+0x1bd j com.taobao.forest.domain.dataobject.std.impl.DefaultStdCategoryPropertyDO.getValuesMap()Ljava/util/Map;+4 v ~StubRoutines::call_stub ... #2 Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x7e25c0] LinkResolver::runtime_resolve_virtual_method(CallInfo&, methodHandle, KlassHandle, Handle, KlassHandle, bool, Thread*)+0x180 V [libjvm.so+0x7e2cf2] LinkResolver::resolve_virtual_call(CallInfo&, Handle, KlassHandle, KlassHandle, Symbol*, Symbol*, KlassHandle, bool, bool, Thread*)+0x152 V [libjvm.so+0x7e2f96] LinkResolver::resolve_invokevirtual(CallInfo&, Handle, constantPoolHandle, int, Thread*)+0x276 V [libjvm.so+0x7e760b] LinkResolver::resolve_invoke(CallInfo&, Handle, constantPoolHandle, int, Bytecodes::Code, Thread*)+0x20b V [libjvm.so+0x69777d] InterpreterRuntime::resolve_invoke(JavaThread*, Bytecodes::Code)+0x1bd j com.taobao.forest.domain.dataobject.std.impl.DefaultStdCategoryPropertyDO.getValuesMap()Ljava/util/Map;+4 v ~StubRoutines::call_stub Some method resolution logs are as folows: # linktime_resolve_virtual_method invokevirtual resolved method: caller-class:com.taobao.forest.domain.dataobject.std.impl.DefaultStdCategoryPropertyDO, compile-time-class:com.taobao.forest.domain.util.LongMapSupportArrayList, method:com.taobao.forest.domain.util.LongMapSupportArrayList.toMap()Ljava/util/Map;, method_holder:com.taobao.forest.domain.util.MapSupportArrayList, access_flags: public # runtime_resolve_virtual_method invokevirtual selected method: receiver-class:java.util.ArrayList, resolved-class:com.taobao.forest.domain.util.LongMapSupportArrayList, resolved_method:com.taobao.forest.domain.util.LongMapSupportArrayList.toMap()Ljava/util/Map;, selected_method:0x458, vtable_index:56# I want to clarify it again. During linktime_resolve_virtual_method, JVM finds that the method to be called is LongMapSupportArrayList.toMap, and the method holder class is `DefaultStdCategoryPropertyDO`. It looks like: public class DefaultStdCategoryPropertyDO extends DefaultFeatureSupportDO implements StdCategoryPropertyDO { ... private LongMapSupportArrayList longValues = new LongMapSupportArrayList("valueId"); ... public Map getValuesMap() { return this.longValues.toMap(); } } Then at runtime_resolve_virtual_method, the real type of the receiver is ArrayList. Since there is no receiver type check, the JVM tries to find toMap from ArrayList's vtables (through the virtual table index), which may eventually find an invalid method (selected_method: 0x458), or incorrect method (crash at CallInfo::set_virtual) ------------- PR: https://git.openjdk.java.net/jdk/pull/8241 From dholmes at openjdk.java.net Wed Apr 20 07:30:25 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 20 Apr 2022 07:30:25 GMT Subject: RFR: 8284877: Check type compatibility before looking up method from receiver's vtable In-Reply-To: References: Message-ID: On Thu, 14 Apr 2022 10:40:21 GMT, Yi Yang wrote: > Hi, can I have a review for this enhancement? This patch adds type compatibility check before method lookup for robustness. In some internal cases, serialization framework may improperly generate an object of wrong type, which leads JVM randomly crashes during method resolution. > > For example: > > invokevirtual selected method: receiver-class:java.util.ArrayList, resolved-class:com.taobao.forest.domain.util.LongMapSupportArrayList, resolved_method:com.taobao.forest.domain.util.LongMapSupportArrayList.toMap()Ljava/util/Map;, selected_method:0x458, vtable_index:56# > > The real type of receiver is ArrayList, while the resolved method is LongMapSupportArrayList.toMap. VM attempts to select method as if looking up from receiver's vtable via vtable index of resolved method(i.e. attempts to lookup `toMap()` from > ArrayList), an invalid method or incorrect method would be selected, thus causing some strange crashes. > > I think it's reasonable to add a type compatibility check before method lookup. If such an incompatible call is found, JVM could throw an exception instead. I admit I'm still not completely clear on the exact situation here in terms of what code is invoking what method with what receiver. If the bytecode is malformed then that should have been detected before now - as long as verification has not been disabled. ------------- PR: https://git.openjdk.java.net/jdk/pull/8241 From psandoz at openjdk.java.net Wed Apr 20 07:36:02 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Wed, 20 Apr 2022 07:36:02 GMT Subject: RFR: 8283839: [JVMCI] add support for querying indy bootstrap method target and arguments In-Reply-To: References: Message-ID: On Sat, 16 Apr 2022 16:06:48 GMT, Doug Simon wrote: > This PR adds support to JVMCI for obtaining the call info for the bootstrap method associated with an invokedynamic or constantdynamic constant pool entry. > > In the context of Native Image, this is necessary to be able to defer execution of select bootstrap methods to image run time (as opposed to executing the bootstrap method during Native Image build time). > > I've also included a minor change to adopt use of the `jvms` javadoc tag in JVMCI Java code. This is preferable to the HTML links previously used in that the latter refer to a specific JDK release. src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotConstantPool.java line 597: > 595: List staticArgumentsList; > 596: if (staticArguments == null) { > 597: staticArgumentsList = Collections.emptyList(); Suggestion: staticArgumentsList = List.of(); src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/JavaKind.java line 104: > 102: /** > 103: * Returns the name of the kind as a single upper case character. For the void and primitive > 104: * kinds, this is the FieldType term in table 4.3-A of JVMS @{jvms 4.3.2}. For Suggestion: * kinds, this is the FieldType term in table 4.3-A of JVMS {@jvms 4.3.2}. For ------------- PR: https://git.openjdk.java.net/jdk/pull/8273 From dnsimon at openjdk.java.net Wed Apr 20 07:36:00 2022 From: dnsimon at openjdk.java.net (Doug Simon) Date: Wed, 20 Apr 2022 07:36:00 GMT Subject: RFR: 8283839: [JVMCI] add support for querying indy bootstrap method target and arguments Message-ID: This PR adds support to JVMCI for obtaining the call info for the bootstrap method associated with an invokedynamic or constantdynamic constant pool entry. In the context of Native Image, this is necessary to be able to defer execution of select bootstrap methods to image run time (as opposed to executing the bootstrap method during Native Image build time). I've also included a minor change to adopt use of the `jvms` javadoc tag in JVMCI Java code. This is preferable to the HTML links previously used in that the latter refer to a specific JDK release. ------------- Commit messages: - added ConstantPool.lookupBootstrapMethod - use @jvms javadoc tag Changes: https://git.openjdk.java.net/jdk/pull/8273/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8273&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283839 Stats: 342 lines in 13 files changed: 306 ins; 14 del; 22 mod Patch: https://git.openjdk.java.net/jdk/pull/8273.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8273/head:pull/8273 PR: https://git.openjdk.java.net/jdk/pull/8273 From dnsimon at openjdk.java.net Wed Apr 20 07:38:59 2022 From: dnsimon at openjdk.java.net (Doug Simon) Date: Wed, 20 Apr 2022 07:38:59 GMT Subject: RFR: 8283839: [JVMCI] add support for querying indy bootstrap method target and arguments [v2] In-Reply-To: References: Message-ID: > This PR adds support to JVMCI for obtaining the call info for the bootstrap method associated with an invokedynamic or constantdynamic constant pool entry. > > In the context of Native Image, this is necessary to be able to defer execution of select bootstrap methods to image run time (as opposed to executing the bootstrap method during Native Image build time). > > I've also included a minor change to adopt use of the `jvms` javadoc tag in JVMCI Java code. This is preferable to the HTML links previously used in that the latter refer to a specific JDK release. Doug Simon has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains two new commits since the last revision: - added ConstantPool.lookupBootstrapMethod - use @jvms javadoc tag ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8273/files - new: https://git.openjdk.java.net/jdk/pull/8273/files/de6f022a..087f909e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8273&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8273&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8273.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8273/head:pull/8273 PR: https://git.openjdk.java.net/jdk/pull/8273 From yyang at openjdk.java.net Wed Apr 20 07:42:25 2022 From: yyang at openjdk.java.net (Yi Yang) Date: Wed, 20 Apr 2022 07:42:25 GMT Subject: RFR: 8284877: Check type compatibility before looking up method from receiver's vtable In-Reply-To: References: Message-ID: On Wed, 20 Apr 2022 07:27:01 GMT, David Holmes wrote: > I admit I'm still not completely clear on the exact situation here in terms of what code is invoking what method with what receiver. If the bytecode is malformed then that should have been detected before now - as long as verification has not been disabled. Okay, let me clarify more clearer:) In the following code, the type of receiver longValues is LongMapSupportArrayList statically.(User-defined classes, contains a toMap) method. public class DefaultStdCategoryPropertyDO extends DefaultFeatureSupportDO implements StdCategoryPropertyDO { ... private LongMapSupportArrayList longValues = new LongMapSupportArrayList("valueId"); ... public Map getValuesMap() { return this.longValues.toMap(); } } Third-party serialization framework generates a ill-type longValues, i.e. public class DefaultStdCategoryPropertyDO extends DefaultFeatureSupportDO implements StdCategoryPropertyDO { ... private ArrayList longValues; ... public Map getValuesMap() { return this.longValues.toMap(); } } Since there is no receiver type check in LinkResolver, trying to call ArrayList.toMap causes JVM crashes in many strange places. As why this call escapes many checks before LinkResolver, I admit I don't know. ------------- PR: https://git.openjdk.java.net/jdk/pull/8241 From aph at openjdk.java.net Wed Apr 20 07:51:12 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Wed, 20 Apr 2022 07:51:12 GMT Subject: RFR: 8282541: AArch64: Auto-vectorize Math.round API [v3] In-Reply-To: References: <88RK-3hLy6Q3WdSNYrHqvdjqMnXtk7FhEBsPhNAADeE=.d35f4b9a-b161-470c-b73d-32e58aa68e3e@github.com> <_SuC-IP3rF6aHB_Ii8q5uozKoTA3Y0FJxrTw1Hf907Q=.d2db969f-9569-4712-98c1-cabf93ac9139@github.com> Message-ID: On Wed, 20 Apr 2022 03:56:38 GMT, Ningsheng Jian wrote: >> Hi, do you like it better now? Thanks. > >> Hi, do you like it better now? Thanks. > > Yeah, looks good to me now! And the jmh results on some of our test systems (with and without SVE) look quite good. That's great. Thanks for helping by testing the patch, I appreciate it. ------------- PR: https://git.openjdk.java.net/jdk/pull/8204 From duke at openjdk.java.net Wed Apr 20 08:25:26 2022 From: duke at openjdk.java.net (Tobias Holenstein) Date: Wed, 20 Apr 2022 08:25:26 GMT Subject: RFR: JDK-8075816: Deprecate AliasLevel flag since it is broken [v2] In-Reply-To: References: Message-ID: On Tue, 12 Apr 2022 05:42:52 GMT, Tobias Hartmann wrote: >> Tobias Holenstein has updated the pull request incrementally with one additional commit since the last revision: >> >> Obsolete AliasLevel flag > > From looking at the code and history, it seems that `AliasLevel` values `0` and `1` are currently disabled due to issues. The VM will print: > > AliasLevel (1) is not compatible with -Xcomp or -Xmixed > Error: Could not create the Java Virtual Machine. > Error: A fatal exception has occurred. Program will exit. > > > But `2` seems to work fine. `3` is the default. @tobiasholenstein did you find any issues with `AliasLevel=2`? thanks @TobiHartmann and @vnkozlov for the reviews! ------------- PR: https://git.openjdk.java.net/jdk/pull/8140 From duke at openjdk.java.net Wed Apr 20 08:25:27 2022 From: duke at openjdk.java.net (Tobias Holenstein) Date: Wed, 20 Apr 2022 08:25:27 GMT Subject: RFR: JDK-8075816: Deprecate AliasLevel flag since it is broken [v3] In-Reply-To: References: Message-ID: On Thu, 14 Apr 2022 17:04:24 GMT, Tobias Holenstein wrote: >> Deprecate the `AliasLevel` flag. `AliasLevel` can have the following values: >> >> "0 - for no aliasing, " >> "1 - for oop/field/static/array split, " >> "2 - for class split, " >> "3 - for unique instances" >> >> - Deprecate AliasLevel in JDK 19. >> - Obsolete it in JDK 20 >> - Expire it in JDK 21. >> >> Users will now get the following message when running: >> `java -XX:AliasLevel= Java HotSpot(TM) 64-Bit Server VM warning: Option AliasLevel was deprecated in version 19.0 and will likely be removed in a future release.` > > Tobias Holenstein has updated the pull request incrementally with one additional commit since the last revision: > > Revert "Obsolete AliasLevel flag" > > This reverts commit 6a1bed2d7ed5494b051fae09d28787fd01de9635. \integrate ------------- PR: https://git.openjdk.java.net/jdk/pull/8140 From duke at openjdk.java.net Wed Apr 20 09:46:32 2022 From: duke at openjdk.java.net (Tobias Holenstein) Date: Wed, 20 Apr 2022 09:46:32 GMT Subject: Integrated: JDK-8075816: Deprecate AliasLevel flag since it is broken In-Reply-To: References: Message-ID: On Thu, 7 Apr 2022 08:29:07 GMT, Tobias Holenstein wrote: > Deprecate the `AliasLevel` flag. `AliasLevel` can have the following values: > > "0 - for no aliasing, " > "1 - for oop/field/static/array split, " > "2 - for class split, " > "3 - for unique instances" > > - Deprecate AliasLevel in JDK 19. > - Obsolete it in JDK 20 > - Expire it in JDK 21. > > Users will now get the following message when running: > `java -XX:AliasLevel= Java HotSpot(TM) 64-Bit Server VM warning: Option AliasLevel was deprecated in version 19.0 and will likely be removed in a future release.` This pull request has now been integrated. Changeset: 46b2e547 Author: Tobias Holenstein Committer: Tobias Hartmann URL: https://git.openjdk.java.net/jdk/commit/46b2e547a9f680a2a93fecc2b223e895c26e96d7 Stats: 4 lines in 3 files changed: 3 ins; 0 del; 1 mod 8075816: Deprecate AliasLevel flag since it is broken Reviewed-by: thartmann, kvn ------------- PR: https://git.openjdk.java.net/jdk/pull/8140 From ngasson at openjdk.java.net Wed Apr 20 09:58:16 2022 From: ngasson at openjdk.java.net (Nick Gasson) Date: Wed, 20 Apr 2022 09:58:16 GMT Subject: RFR: 8282541: AArch64: Auto-vectorize Math.round API [v3] In-Reply-To: References: Message-ID: On Tue, 19 Apr 2022 16:39:14 GMT, Andrew Haley wrote: >> Before, Apple M1: >> >> +-----------------------------------------+---------------------------------+ >> |Benchmark | (TESTSIZE) Mode Score Units| >> +-----------------------------------------+---------------------------------+ >> |FpRoundingBenchmark.test_round_double | 1024 thrpt 1612.391 ops/ms| >> |FpRoundingBenchmark.test_round_double | 2048 thrpt 804.291 ops/ms| >> |FpRoundingBenchmark.test_round_float | 1024 thrpt 1558.202 ops/ms| >> |FpRoundingBenchmark.test_round_float | 2048 thrpt 775.730 ops/ms| >> +------------------------------------------+--------------------------------+ >> >> After: >> >> +-----------------------------------------+----------------------------------+ >> |Benchmark | (TESTSIZE) Mode Score Units| >> +-----------------------------------------+----------------------------------+ >> |FpRoundingBenchmark.test_round_double | 1024 thrpt 2720.153 ops/ms| >> |FpRoundingBenchmark.test_round_double | 2048 thrpt 1371.750 ops/ms| >> |FpRoundingBenchmark.test_round_float | 1024 thrpt 5940.263 ops/ms| >> |FpRoundingBenchmark.test_round_float | 2048 thrpt 3036.201 ops/ms| >> +-----------------------------------------+----------------------------------+ >> >> About the algorithm: >> >> `Math.round()` is tricky. Its specification corresponds to no standard >> rounding mode: it "returns the closest long to the argument, with ties >> rounding to positive infinity." For positive inputs this is the same >> as IEEE-754's `convertToIntegerTiesToAway` operation, which rounds >> away from zero, but there's no equivalent for negative inputs. >> >> `Math.round()` used simply to add 0.5 and convert to integer by taking >> the floor of the result, but that wasn't right because it suffers from >> double rounding. This breaks several cases, in particular because >> >> `0.4999999... (+) 0.5 == 1.0` >> >> (Here, `(+)` indicates an addition followed by roundTiesToEven.) >> >> There is no corresponding problem with `-0.4999999...` or `-0.9999999...` >> >> Also, in the 32-bit `float` case, >> >> `8388609 (+) 0.5 == 8388610` >> >> because 8388609 (0x1.000002p+23) as a 32-bit integer has no fraction >> bits, so adding 0.5, followed by roundTiesToEven, rounds upwards. This >> problem manifests for every odd integer within the binade from >> 0x1.000002p+23 to 0x1.fffffep+23, whether positive or negative. There >> is a corresponding problem for the `double` range. >> >> The patch for JDK-8279508 handles this by flipping the floating-point >> rounding mode to roundTowardNegative, adding 0.5, and taking the >> floor. While this does work on AArch64, the performance is >> tragic. AArch64 implementations seem to wait for all instructions in >> flight to retire, change the rounding mode, and do the operation. This >> effectively serializes the entire thread. >> >> This patch takes a different approach. Firstly, we can observe that we >> can use the `frinta` instruction for the entire positive range. The >> negative range is a bit trickier, but we can observe that any x, >> abs{x) >= -0x1.000000p+23, has no fractional bits so it must be an >> integer. For convenence, we can convert that range with the `frinta` >> instruction as well. >> >> All that remains are x < 0, abs{x) < -0x1.000000p+23. Adding 0.5 >> followed by roundTiesToEven doesn't lead to a problem because for >> x < 0 && abs{x) >= 0.5, adding 0.5 only reduces the magnitude of x; >> for all x < 0 && abs{x) < 0.5, adding 0.5 followed by roundTiesToEven >> return 0. > > Andrew Haley has updated the pull request incrementally with two additional commits since the last revision: > > - Put all SVE-mode ops in aarch64_sve.ad. > - Move size extimate for Op_RoundXX to matcher. src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5193: > 5191: FloatRegister ftmp) { > 5192: Label DONE; > 5193: BLOCK_COMMENT("java_round_float: { "); Should be "java_round_double: {"? src/hotspot/cpu/ppc/matcher_ppc.hpp line 168: > 166: > 167: // Returns pre-selection estimated cost of a vector operation. > 168: static int op_pre_select_sz_estimate(int vopc, BasicType ety, int vlen) { For Op_Round* on PPC and S390 we currently estimate size 30 but this changes it to zero. Presumably that's correct though as those platforms don't emit any code in the corresponding match rules? ------------- PR: https://git.openjdk.java.net/jdk/pull/8204 From aph at openjdk.java.net Wed Apr 20 10:06:27 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Wed, 20 Apr 2022 10:06:27 GMT Subject: RFR: 8282541: AArch64: Auto-vectorize Math.round API [v3] In-Reply-To: References: Message-ID: On Wed, 20 Apr 2022 09:51:34 GMT, Nick Gasson wrote: >> Andrew Haley has updated the pull request incrementally with two additional commits since the last revision: >> >> - Put all SVE-mode ops in aarch64_sve.ad. >> - Move size extimate for Op_RoundXX to matcher. > > src/hotspot/cpu/ppc/matcher_ppc.hpp line 168: > >> 166: >> 167: // Returns pre-selection estimated cost of a vector operation. >> 168: static int op_pre_select_sz_estimate(int vopc, BasicType ety, int vlen) { > > For Op_Round* on PPC and S390 we currently estimate size 30 but this changes it to zero. Presumably that's correct though as those platforms don't emit any code in the corresponding match rules? As and when those platforms get ported, they should provide appropriate estimates. I an working on this code, though, and I'll change it back to 30 for other platforms. BTW, many of the numbers in that table are wrong for non-x86, and we really should provide estimates that are AArch64-realistic, but not today. ------------- PR: https://git.openjdk.java.net/jdk/pull/8204 From aph at openjdk.java.net Wed Apr 20 11:18:07 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Wed, 20 Apr 2022 11:18:07 GMT Subject: RFR: 8282541: AArch64: Auto-vectorize Math.round API [v4] In-Reply-To: References: Message-ID: > Before, Apple M1: > > +-----------------------------------------+---------------------------------+ > |Benchmark | (TESTSIZE) Mode Score Units| > +-----------------------------------------+---------------------------------+ > |FpRoundingBenchmark.test_round_double | 1024 thrpt 1612.391 ops/ms| > |FpRoundingBenchmark.test_round_double | 2048 thrpt 804.291 ops/ms| > |FpRoundingBenchmark.test_round_float | 1024 thrpt 1558.202 ops/ms| > |FpRoundingBenchmark.test_round_float | 2048 thrpt 775.730 ops/ms| > +------------------------------------------+--------------------------------+ > > After: > > +-----------------------------------------+----------------------------------+ > |Benchmark | (TESTSIZE) Mode Score Units| > +-----------------------------------------+----------------------------------+ > |FpRoundingBenchmark.test_round_double | 1024 thrpt 2720.153 ops/ms| > |FpRoundingBenchmark.test_round_double | 2048 thrpt 1371.750 ops/ms| > |FpRoundingBenchmark.test_round_float | 1024 thrpt 5940.263 ops/ms| > |FpRoundingBenchmark.test_round_float | 2048 thrpt 3036.201 ops/ms| > +-----------------------------------------+----------------------------------+ > > About the algorithm: > > `Math.round()` is tricky. Its specification corresponds to no standard > rounding mode: it "returns the closest long to the argument, with ties > rounding to positive infinity." For positive inputs this is the same > as IEEE-754's `convertToIntegerTiesToAway` operation, which rounds > away from zero, but there's no equivalent for negative inputs. > > `Math.round()` used simply to add 0.5 and convert to integer by taking > the floor of the result, but that wasn't right because it suffers from > double rounding. This breaks several cases, in particular because > > `0.4999999... (+) 0.5 == 1.0` > > (Here, `(+)` indicates an addition followed by roundTiesToEven.) > > There is no corresponding problem with `-0.4999999...` or `-0.9999999...` > > Also, in the 32-bit `float` case, > > `8388609 (+) 0.5 == 8388610` > > because 8388609 (0x1.000002p+23) as a 32-bit integer has no fraction > bits, so adding 0.5, followed by roundTiesToEven, rounds upwards. This > problem manifests for every odd integer within the binade from > 0x1.000002p+23 to 0x1.fffffep+23, whether positive or negative. There > is a corresponding problem for the `double` range. > > The patch for JDK-8279508 handles this by flipping the floating-point > rounding mode to roundTowardNegative, adding 0.5, and taking the > floor. While this does work on AArch64, the performance is > tragic. AArch64 implementations seem to wait for all instructions in > flight to retire, change the rounding mode, and do the operation. This > effectively serializes the entire thread. > > This patch takes a different approach. Firstly, we can observe that we > can use the `frinta` instruction for the entire positive range. The > negative range is a bit trickier, but we can observe that any x, > abs{x) >= -0x1.000000p+23, has no fractional bits so it must be an > integer. For convenence, we can convert that range with the `frinta` > instruction as well. > > All that remains are x < 0, abs{x) < -0x1.000000p+23. Adding 0.5 > followed by roundTiesToEven doesn't lead to a problem because for > x < 0 && abs{x) >= 0.5, adding 0.5 only reduces the magnitude of x; > for all x < 0 && abs{x) < 0.5, adding 0.5 followed by roundTiesToEven > return 0. Andrew Haley has updated the pull request incrementally with two additional commits since the last revision: - Thinko in comment. - Reorganize cost estimates for unrolling. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8204/files - new: https://git.openjdk.java.net/jdk/pull/8204/files/c365b3ff..6ae678bc Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8204&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8204&range=02-03 Stats: 112 lines in 8 files changed: 86 ins; 9 del; 17 mod Patch: https://git.openjdk.java.net/jdk/pull/8204.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8204/head:pull/8204 PR: https://git.openjdk.java.net/jdk/pull/8204 From ngasson at openjdk.java.net Wed Apr 20 12:24:32 2022 From: ngasson at openjdk.java.net (Nick Gasson) Date: Wed, 20 Apr 2022 12:24:32 GMT Subject: RFR: 8282541: AArch64: Auto-vectorize Math.round API [v4] In-Reply-To: References: Message-ID: On Wed, 20 Apr 2022 11:18:07 GMT, Andrew Haley wrote: >> Before, Apple M1: >> >> +-----------------------------------------+---------------------------------+ >> |Benchmark | (TESTSIZE) Mode Score Units| >> +-----------------------------------------+---------------------------------+ >> |FpRoundingBenchmark.test_round_double | 1024 thrpt 1612.391 ops/ms| >> |FpRoundingBenchmark.test_round_double | 2048 thrpt 804.291 ops/ms| >> |FpRoundingBenchmark.test_round_float | 1024 thrpt 1558.202 ops/ms| >> |FpRoundingBenchmark.test_round_float | 2048 thrpt 775.730 ops/ms| >> +------------------------------------------+--------------------------------+ >> >> After: >> >> +-----------------------------------------+----------------------------------+ >> |Benchmark | (TESTSIZE) Mode Score Units| >> +-----------------------------------------+----------------------------------+ >> |FpRoundingBenchmark.test_round_double | 1024 thrpt 2720.153 ops/ms| >> |FpRoundingBenchmark.test_round_double | 2048 thrpt 1371.750 ops/ms| >> |FpRoundingBenchmark.test_round_float | 1024 thrpt 5940.263 ops/ms| >> |FpRoundingBenchmark.test_round_float | 2048 thrpt 3036.201 ops/ms| >> +-----------------------------------------+----------------------------------+ >> >> About the algorithm: >> >> `Math.round()` is tricky. Its specification corresponds to no standard >> rounding mode: it "returns the closest long to the argument, with ties >> rounding to positive infinity." For positive inputs this is the same >> as IEEE-754's `convertToIntegerTiesToAway` operation, which rounds >> away from zero, but there's no equivalent for negative inputs. >> >> `Math.round()` used simply to add 0.5 and convert to integer by taking >> the floor of the result, but that wasn't right because it suffers from >> double rounding. This breaks several cases, in particular because >> >> `0.4999999... (+) 0.5 == 1.0` >> >> (Here, `(+)` indicates an addition followed by roundTiesToEven.) >> >> There is no corresponding problem with `-0.4999999...` or `-0.9999999...` >> >> Also, in the 32-bit `float` case, >> >> `8388609 (+) 0.5 == 8388610` >> >> because 8388609 (0x1.000002p+23) as a 32-bit integer has no fraction >> bits, so adding 0.5, followed by roundTiesToEven, rounds upwards. This >> problem manifests for every odd integer within the binade from >> 0x1.000002p+23 to 0x1.fffffep+23, whether positive or negative. There >> is a corresponding problem for the `double` range. >> >> The patch for JDK-8279508 handles this by flipping the floating-point >> rounding mode to roundTowardNegative, adding 0.5, and taking the >> floor. While this does work on AArch64, the performance is >> tragic. AArch64 implementations seem to wait for all instructions in >> flight to retire, change the rounding mode, and do the operation. This >> effectively serializes the entire thread. >> >> This patch takes a different approach. Firstly, we can observe that we >> can use the `frinta` instruction for the entire positive range. The >> negative range is a bit trickier, but we can observe that any x, >> abs{x) >= -0x1.000000p+23, has no fractional bits so it must be an >> integer. For convenence, we can convert that range with the `frinta` >> instruction as well. >> >> All that remains are x < 0, abs{x) < -0x1.000000p+23. Adding 0.5 >> followed by roundTiesToEven doesn't lead to a problem because for >> x < 0 && abs{x) >= 0.5, adding 0.5 only reduces the magnitude of x; >> for all x < 0 && abs{x) < 0.5, adding 0.5 followed by roundTiesToEven >> return 0. > > Andrew Haley has updated the pull request incrementally with two additional commits since the last revision: > > - Thinko in comment. > - Reorganize cost estimates for unrolling. Marked as reviewed by ngasson (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8204 From kevinw at openjdk.java.net Wed Apr 20 14:04:32 2022 From: kevinw at openjdk.java.net (Kevin Walls) Date: Wed, 20 Apr 2022 14:04:32 GMT Subject: RFR: 8284853: Fix various 'expected' typo [v2] In-Reply-To: References: <32dmK9fPqvYhxpZmTgVYMYCfJNLZ3bI8ROg9UqUIRHc=.25e61d1a-6f26-4ea4-b5d3-3c6a80ce08dd@github.com> Message-ID: On Thu, 14 Apr 2022 18:04:16 GMT, Andrey Turbanov wrote: > I found [yet another typo](https://github.com/kelthuzadx/jdk/commit/acb9e15bc0bf5395d1c0875f36992f692734f948) ... I didn't think "JVMInvokeMethodSlack" was a typo. I think it's the idea of "slack space" meaning leftover space. We require a certain amount of this space. We need some slack on the stack, in order to invoke. ------------- PR: https://git.openjdk.java.net/jdk/pull/8231 From duke at openjdk.java.net Wed Apr 20 14:41:40 2022 From: duke at openjdk.java.net (ExE Boss) Date: Wed, 20 Apr 2022 14:41:40 GMT Subject: RFR: 8284877: Check type compatibility before looking up method from receiver's vtable In-Reply-To: References: Message-ID: <148sTXqmi6ajQvI0wQymShU_YcHNUlKM2hENt6FEN1w=.76a35513-9acb-4d2f-878b-5ef37f0dd513@github.com> On Wed, 20 Apr 2022 07:27:01 GMT, David Holmes wrote: >> Hi, can I have a review for this enhancement? This patch adds type compatibility check before method lookup for robustness. In some internal cases, serialization framework may improperly generate an object of wrong type, which leads JVM randomly crashes during method resolution. >> >> For example: >> >> invokevirtual selected method: receiver-class:java.util.ArrayList, resolved-class:com.taobao.forest.domain.util.LongMapSupportArrayList, resolved_method:com.taobao.forest.domain.util.LongMapSupportArrayList.toMap()Ljava/util/Map;, selected_method:0x458, vtable_index:56# >> >> The real type of receiver is ArrayList, while the resolved method is LongMapSupportArrayList.toMap. VM attempts to select method as if looking up from receiver's vtable via vtable index of resolved method(i.e. attempts to lookup `toMap()` from >> ArrayList), an invalid method or incorrect method would be selected, thus causing some strange crashes. >> >> I think it's reasonable to add a type compatibility check before method lookup. If such an incompatible call is found, JVM could throw an exception instead. > > I admit I'm still not completely clear on the exact situation here in terms of what code is invoking what method with what receiver. If the bytecode is malformed then that should have been detected before now - as long as verification has not been disabled. @dholmes-ora From?my?understanding, the bytecode is correct, but?the?third?party serialisation?library ends?up incorrectly?deserialising the?`LongMapSupportArrayList`?instance as?an?`ArrayList`, and?then?uses `Unsafe.setObject` to?store?it in?the?`longValues`?field, which?is?typed as?`LongMapSupportArrayList`. -------------------------------------------------------------------------------- Then, when the `getValuesMap()` method calls `this.longValues.toMap()`, the?JVM?assumes that?since `longValues` is?typed as?`LongMapSupportArrayList`, the?`LongMapSupportArrayList.toMap:()Ljava/util/Map;`?method will?always?exist, but?since the?`longValues`?field now?contains a?`java.util.ArrayList` (which?doesn?t?have the?`toMap()`?method), the?`vtable`?index is?invalid, which?leads?to a?VM?crash. ------------- PR: https://git.openjdk.java.net/jdk/pull/8241 From lucy at openjdk.java.net Wed Apr 20 14:53:03 2022 From: lucy at openjdk.java.net (Lutz Schmidt) Date: Wed, 20 Apr 2022 14:53:03 GMT Subject: RFR: 8278757: [s390] Implement AES Counter Mode Intrinsic [v5] In-Reply-To: References: Message-ID: > Please review (and approve, if possible) this pull request. > > This is a s390-only enhancement. It introduces the implementation of an AES-CTR intrinsic, making use of the specific s390 instruction for AES counter-mode encryption. > > Testing: SAP does no longer maintain a full build and test environment for s390. Testing is therefore limited to running some test suites (SPECjbb*, SPECjvm*) manually. But: identical code is contained in SAP's commercial product and thoroughly tested in that context. No issues were uncovered. > > @backwaterred Could you please conduct some "official" testing for this PR? > > Thank you all! > > Note: some performance figures can be found in the JBS ticket. Lutz Schmidt has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: - Merge branch 'master' into JDK-8278757 - Merge branch 'master' into JDK-8278757 - 8278757: resolve merge conflict - 8278757: update copyright year - 8278757: [s390] Implement AES Counter Mode Intrinsic ------------- Changes: https://git.openjdk.java.net/jdk/pull/8142/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8142&range=04 Stats: 696 lines in 5 files changed: 669 ins; 5 del; 22 mod Patch: https://git.openjdk.java.net/jdk/pull/8142.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8142/head:pull/8142 PR: https://git.openjdk.java.net/jdk/pull/8142 From duke at openjdk.java.net Wed Apr 20 15:04:29 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Wed, 20 Apr 2022 15:04:29 GMT Subject: RFR: 8283643: [AIX, testbug] MachCodeFramesInErrorFile test fails to find 'Native frames' text In-Reply-To: References: Message-ID: On Wed, 20 Apr 2022 05:49:15 GMT, Thomas Stuefe wrote: >> I observed a failure of MachCodeFramesInErrorFile.java on AIX. The raised error complains that 'Native frames: ' is missing. To fix the failure, I made two changes to the test that allowed it to pass on AIX. >> >> The first change made was to the test's `extractFrames` method. AIX overrides `os::platform_print_native_stack` with stack printing specific to AIX/Power. This code does not produce the 'Native frames: ' text that `vmError::print_native_stack` does, so the test was modified to expect the AIX output when run on AIX. >> >> A second change was made to the address passed to the `crashInNative1` method. AIX does not consider low-address memory to be protected as other platforms do. In fact, "the first 256 bytes are reserved for software use" according to the Power ISA. Accordingly, the read address for PPC was changed to -1 (0xFF..FF) to produce the expected failure result. >> >> ### Testing >> >> Tier1 tests complete as expected on AIX/Power. > > BTW, feel free to tweak the native stack printing on os_aix.cpp to print "Native" etc like the other variants do. It is just cosmetics, and the less AIX specifics in shared code the better. > > Thanks for taking care of this! Thanks for your suggestions @tstuefe. Your comments suggest a different tack than I originally took with this change, so I converted this to a draft while I test out those ideas. ------------- PR: https://git.openjdk.java.net/jdk/pull/8094 From duke at openjdk.java.net Wed Apr 20 15:42:19 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Wed, 20 Apr 2022 15:42:19 GMT Subject: RFR: 8283643: [AIX, testbug] MachCodeFramesInErrorFile test fails to find 'Native frames' text [v2] In-Reply-To: References: Message-ID: > I observed a failure of MachCodeFramesInErrorFile.java on AIX. The raised error complains that 'Native frames: ' is missing. To fix the failure, I made two changes to the test that allowed it to pass on AIX. > > The first change made was to the test's `extractFrames` method. AIX overrides `os::platform_print_native_stack` with stack printing specific to AIX/Power. This code does not produce the 'Native frames: ' text that `vmError::print_native_stack` does, so the test was modified to expect the AIX output when run on AIX. > > A second change was made to the address passed to the `crashInNative1` method. AIX does not consider low-address memory to be protected as other platforms do. In fact, "the first 256 bytes are reserved for software use" according to the Power ISA. Accordingly, the read address for PPC was changed to -1 (0xFF..FF) to produce the expected failure result. > > ### Testing > > Tier1 tests complete as expected on AIX/Power. Tyler Steele has updated the pull request incrementally with one additional commit since the last revision: Removes AIX-specific printing - Replaces "--- current frame" with "Native frame" in print_callstack_for_context - Modifies MachCodeFramesInErrorFile to accept "Native frame" for all platforms ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8094/files - new: https://git.openjdk.java.net/jdk/pull/8094/files/9a4b07db..a8308db4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8094&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8094&range=00-01 Stats: 8 lines in 2 files changed: 0 ins; 4 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/8094.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8094/head:pull/8094 PR: https://git.openjdk.java.net/jdk/pull/8094 From mdoerr at openjdk.java.net Wed Apr 20 15:50:42 2022 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Wed, 20 Apr 2022 15:50:42 GMT Subject: RFR: 8278757: [s390] Implement AES Counter Mode Intrinsic [v5] In-Reply-To: References: Message-ID: On Wed, 20 Apr 2022 14:53:03 GMT, Lutz Schmidt wrote: >> Please review (and approve, if possible) this pull request. >> >> This is a s390-only enhancement. It introduces the implementation of an AES-CTR intrinsic, making use of the specific s390 instruction for AES counter-mode encryption. >> >> Testing: SAP does no longer maintain a full build and test environment for s390. Testing is therefore limited to running some test suites (SPECjbb*, SPECjvm*) manually. But: identical code is contained in SAP's commercial product and thoroughly tested in that context. No issues were uncovered. >> >> @backwaterred Could you please conduct some "official" testing for this PR? >> >> Thank you all! >> >> Note: some performance figures can be found in the JBS ticket. > > Lutz Schmidt has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: > > - Merge branch 'master' into JDK-8278757 > - Merge branch 'master' into JDK-8278757 > - 8278757: resolve merge conflict > - 8278757: update copyright year > - 8278757: [s390] Implement AES Counter Mode Intrinsic Looks basically correct, but I still need to check a few things. I already have some change requests. src/hotspot/cpu/s390/stubGenerator_s390.cpp line 1755: > 1753: __ should_not_reach_here(); > 1754: } > 1755: Please assert that VM_Version::has_Crypto_AES() instead. Otherwise, the stub shouldn't get generated at all (handled by vm_version_s390.cpp). src/hotspot/cpu/s390/stubGenerator_s390.cpp line 1826: > 1824: __ should_not_reach_here(); > 1825: } > 1826: Like above. src/hotspot/cpu/s390/stubGenerator_s390.cpp line 1902: > 1900: // +--------+ <-- Z_SP + alignment loss (part 1+2), octoword-aligned > 1901: // | | > 1902: // : : additional alignment loss. Blocks above can't tolerate unusabe DW @SP. "unusabe"? src/hotspot/cpu/s390/stubGenerator_s390.cpp line 1919: > 1917: // parmBlk-4: ctrVal_len (as retrieved from iv array), in bytes, as HW > 1918: // parmBlk-8: msglen length (in bytes) of crypto msg, as passed in by caller > 1919: // return value is calculated from this: rv = msglen - processed. Strange indentation. src/hotspot/cpu/s390/stubGenerator_s390.cpp line 1965: > 1963: // check length against expected. > 1964: __ z_chi(scratch, AES_ctrVal_len); > 1965: __ asm_assert_eq("counter value needs same size as data block", 0xb00b); Why do we need to copy it to memory if we just want to compare it? Is this debugging code worth keeping it this way? src/hotspot/cpu/s390/stubGenerator_s390.cpp line 1984: > 1982: int offset = j * AES_ctrVal_len; > 1983: __ z_algsi(offset + 8, counter, j); // increment iv by index value > 1984: // TODO: for correctness, use 128-bit add Does this TODO need to get resolved? src/hotspot/cpu/s390/stubGenerator_s390.cpp line 1999: > 1997: int offset = j * AES_ctrVal_len; > 1998: __ z_algsi(offset + 8, counter, AES_ctrVec_len); // calculate new ctr vector elements (simple increment) > 1999: // TODO: for correctness, use 128-bit add TODO as above. src/hotspot/cpu/s390/stubGenerator_s390.cpp line 2012: > 2010: BLOCK_COMMENT(err_msg("push_Block counterMode_AESCrypt%d {", parmBlk_len*8)); > 2011: > 2012: AES_dataBlk_space = (2*dataBlk_len + AES_parmBlk_align - 1) & (~(AES_parmBlk_align - 1)); // space for data blocks (src and dst, one each) for partial block processing) Line too long! src/hotspot/cpu/s390/stubGenerator_s390.cpp line 2199: > 2197: if (! VM_Version::has_Crypto_AES_CTR()) { > 2198: __ should_not_reach_here(); > 2199: } Like above. src/hotspot/cpu/s390/stubGenerator_s390.cpp line 2387: > 2385: if (! VM_Version::has_Crypto_AES_CTR()) { > 2386: __ should_not_reach_here(); > 2387: } Like above. ------------- Changes requested by mdoerr (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8142 From duke at openjdk.java.net Wed Apr 20 16:03:49 2022 From: duke at openjdk.java.net (XenoAmess) Date: Wed, 20 Apr 2022 16:03:49 GMT Subject: RFR: 8285149: Using HashMap.newHashMap to replace new HashMap(int) Message-ID: These are the changes that too many to be reviewed in 8186958, thus split some of them out. ------------- Commit messages: - 9073085: ues HashMap.newHashMap to replace new HashMap(int) Changes: https://git.openjdk.java.net/jdk/pull/8301/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8301&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8285149 Stats: 36 lines in 20 files changed: 0 ins; 0 del; 36 mod Patch: https://git.openjdk.java.net/jdk/pull/8301.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8301/head:pull/8301 PR: https://git.openjdk.java.net/jdk/pull/8301 From mdoerr at openjdk.java.net Wed Apr 20 16:08:41 2022 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Wed, 20 Apr 2022 16:08:41 GMT Subject: RFR: 8283643: [AIX, testbug] MachCodeFramesInErrorFile test fails to find 'Native frames' text [v2] In-Reply-To: References: Message-ID: On Tue, 19 Apr 2022 22:11:04 GMT, Tyler Steele wrote: >> test/hotspot/jtreg/runtime/ErrorHandling/MachCodeFramesInErrorFile.java line 189: >> >>> 187: } >>> 188: } >>> 189: throw new RuntimeException("\"" + marker + "\" line missing in hs_err_pid file:\n"); >> >> Please explain removal! > > OK! > This was an odd one; I was getting errors that complained about the length of the message in the exception. It looked like 2^16 was the max number of characters that could be included in a RuntimeException. I haven't found the upper limit documented anywhere, but I would get unexpected failures with it included in the message. The text prints to stdout, so I didn't suffer by removing it. Maybe just print the last line? ------------- PR: https://git.openjdk.java.net/jdk/pull/8094 From duke at openjdk.java.net Wed Apr 20 16:27:36 2022 From: duke at openjdk.java.net (liach) Date: Wed, 20 Apr 2022 16:27:36 GMT Subject: RFR: 8285149: Using HashMap.newHashMap to replace new HashMap(int) In-Reply-To: References: Message-ID: On Tue, 19 Apr 2022 17:44:10 GMT, XenoAmess wrote: > These are the changes that too many to be reviewed in 8186958, thus split some of them out. Would you consider replacing usages of `new HashMap<>(size, 1)`, such as in `AnnotationInvocationHandler`, as well? Such maps have a smaller table and are more likely to have collisions than `HashMap.newHashMap(size)`. ------------- PR: https://git.openjdk.java.net/jdk/pull/8301 From psandoz at openjdk.java.net Wed Apr 20 16:28:29 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Wed, 20 Apr 2022 16:28:29 GMT Subject: RFR: 8283839: [JVMCI] add support for querying indy bootstrap method target and arguments [v2] In-Reply-To: References: Message-ID: <3Y7lnowqF1MmR5iCV5cSsz9FPpPINUKIiM4jTkzznzs=.53b6176d-c32a-4cac-8e93-8826baa67057@github.com> On Wed, 20 Apr 2022 07:38:59 GMT, Doug Simon wrote: >> This PR adds support to JVMCI for obtaining the call info for the bootstrap method associated with an invokedynamic or constantdynamic constant pool entry. >> >> In the context of Native Image, this is necessary to be able to defer execution of select bootstrap methods to image run time (as opposed to executing the bootstrap method during Native Image build time). >> >> I've also included a minor change to adopt use of the `jvms` javadoc tag in JVMCI Java code. This is preferable to the HTML links previously used in that the latter refer to a specific JDK release. > > Doug Simon has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains two new commits since the last revision: > > - added ConstantPool.lookupBootstrapMethod > - use @jvms javadoc tag Looks good (not an expert on JVMCI but i could follow the change). I am presuming no CSR is required for the new public method. ------------- Marked as reviewed by psandoz (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8273 From kvn at openjdk.java.net Wed Apr 20 16:38:37 2022 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Wed, 20 Apr 2022 16:38:37 GMT Subject: RFR: 8284563: AArch64: bitperm feature detection for SVE2 on Linux [v2] In-Reply-To: References: Message-ID: On Mon, 18 Apr 2022 10:58:39 GMT, Eric Liu wrote: >> This patch adds BITPERM feature detection for SVE2 on Linux. BITPERM is >> an optional feature in SVE2 [1]. It enables 3 SVE2 instructions (BEXT, >> BDEP, BGRP). BEXT and BDEP map efficiently to some vector operations, >> e.g., the compress and expand functionalities [2] which are proposed in >> VectorAPI's 4th incubation [3]. Besides, to generate specific code based >> on different architecture features like x86, this patch exports >> VM_Version::supports_XXX() for all CPU features. E.g., >> VM_Version::supports_svebitperm() for easy use. >> >> This patch also fixes a trivial bug, that sets UseSVE back to 1 if it's >> 2 in SVE1 system. >> >> [1] https://developer.arm.com/documentation/ddi0601/2022-03/AArch64-Registers/ID-AA64ZFR0-EL1--SVE-Feature-ID-register-0 >> [2] https://bugs.openjdk.java.net/browse/JDK-8283893 >> [3] https://bugs.openjdk.java.net/browse/JDK-8280173 > > Eric Liu has updated the pull request incrementally with one additional commit since the last revision: > > small fix > > Change-Id: Ida979f925055761ad73e50655d0584dcee24aea4 this changes broke `compiler/intrinsics/sha/cli/TestUseSHA256IntrinsicsOptionOnUnsupportedCPU.java` test: java.lang.AssertionError: Option 'UseSHA256Intrinsics' is expected to have 'false' value Option 'UseSHA256Intrinsics' should be disabled by default at jdk.test.lib.cli.CommandLineOptionTest.verifyOptionValue(CommandLineOptionTest.java:307) at jdk.test.lib.cli.CommandLineOptionTest.verifyOptionValue(CommandLineOptionTest.java:280) at jdk.test.lib.cli.CommandLineOptionTest.verifyOptionValueForSameVM(CommandLineOptionTest.java:404) at compiler.intrinsics.sha.cli.testcases.GenericTestCaseForUnsupportedAArch64CPU.verifyOptionValues(GenericTestCaseForUnsupportedAArch64CPU.java:89) at compiler.intrinsics.sha.cli.DigestOptionsBase$TestCase.test(DigestOptionsBase.java:163) at compiler.intrinsics.sha.cli.DigestOptionsBase.runTestCases(DigestOptionsBase.java:139) at jdk.test.lib.cli.CommandLineOptionTest.test(CommandLineOptionTest.java:537) at compiler.intrinsics.sha.cli.TestUseSHA256IntrinsicsOptionOnUnsupportedCPU.main(TestUseSHA256IntrinsicsOptionOnUnsupportedCPU.java:58) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) at java.base/java.lang.reflect.Method.invoke(Method.java:578) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) at java.base/java.lang.Thread.run(Thread.java:828) Caused by: java.lang.RuntimeException: 'UseSHA256Intrinsics\\s*:?=\\s*false' missing from stdout/stderr ------------- PR: https://git.openjdk.java.net/jdk/pull/8258 From duke at openjdk.java.net Wed Apr 20 17:25:29 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Wed, 20 Apr 2022 17:25:29 GMT Subject: RFR: 8283643: [AIX, testbug] MachCodeFramesInErrorFile test fails to find 'Native frames' text [v3] In-Reply-To: References: Message-ID: <3jiRIvDZbCROlqvG0YOGt7cAZOACOUxIyJZ_3-ftuGo=.dcb12c16-ad1a-431a-b9f9-4da7f526597c@github.com> > I observed a failure of MachCodeFramesInErrorFile.java on AIX. The raised error complains that 'Native frames: ' is missing. To fix the failure, I made two changes to the test that allowed it to pass on AIX. > > The first change made was to the test's `extractFrames` method. AIX overrides `os::platform_print_native_stack` with stack printing specific to AIX/Power. This code does not produce the 'Native frames: ' text that `vmError::print_native_stack` does, so the test was modified to expect the AIX output when run on AIX. > > A second change was made to the address passed to the `crashInNative1` method. AIX does not consider low-address memory to be protected as other platforms do. In fact, "the first 256 bytes are reserved for software use" according to the Power ISA. Accordingly, the read address for PPC was changed to -1 (0xFF..FF) to produce the expected failure result. > > ### Testing > > Tier1 tests complete as expected on AIX/Power. Tyler Steele has updated the pull request incrementally with one additional commit since the last revision: Ammend comment in MachCodeFramesInErrorFile to reflect changes to extractFrames method. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8094/files - new: https://git.openjdk.java.net/jdk/pull/8094/files/a8308db4..3c288176 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8094&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8094&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8094.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8094/head:pull/8094 PR: https://git.openjdk.java.net/jdk/pull/8094 From aph at openjdk.java.net Wed Apr 20 17:26:21 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Wed, 20 Apr 2022 17:26:21 GMT Subject: RFR: 8282541: AArch64: Auto-vectorize Math.round API [v5] In-Reply-To: References: Message-ID: > Before, Apple M1: > > +-----------------------------------------+---------------------------------+ > |Benchmark | (TESTSIZE) Mode Score Units| > +-----------------------------------------+---------------------------------+ > |FpRoundingBenchmark.test_round_double | 1024 thrpt 1612.391 ops/ms| > |FpRoundingBenchmark.test_round_double | 2048 thrpt 804.291 ops/ms| > |FpRoundingBenchmark.test_round_float | 1024 thrpt 1558.202 ops/ms| > |FpRoundingBenchmark.test_round_float | 2048 thrpt 775.730 ops/ms| > +------------------------------------------+--------------------------------+ > > After: > > +-----------------------------------------+----------------------------------+ > |Benchmark | (TESTSIZE) Mode Score Units| > +-----------------------------------------+----------------------------------+ > |FpRoundingBenchmark.test_round_double | 1024 thrpt 2720.153 ops/ms| > |FpRoundingBenchmark.test_round_double | 2048 thrpt 1371.750 ops/ms| > |FpRoundingBenchmark.test_round_float | 1024 thrpt 5940.263 ops/ms| > |FpRoundingBenchmark.test_round_float | 2048 thrpt 3036.201 ops/ms| > +-----------------------------------------+----------------------------------+ > > About the algorithm: > > `Math.round()` is tricky. Its specification corresponds to no standard > rounding mode: it "returns the closest long to the argument, with ties > rounding to positive infinity." For positive inputs this is the same > as IEEE-754's `convertToIntegerTiesToAway` operation, which rounds > away from zero, but there's no equivalent for negative inputs. > > `Math.round()` used simply to add 0.5 and convert to integer by taking > the floor of the result, but that wasn't right because it suffers from > double rounding. This breaks several cases, in particular because > > `0.4999999... (+) 0.5 == 1.0` > > (Here, `(+)` indicates an addition followed by roundTiesToEven.) > > There is no corresponding problem with `-0.4999999...` or `-0.9999999...` > > Also, in the 32-bit `float` case, > > `8388609 (+) 0.5 == 8388610` > > because 8388609 (0x1.000002p+23) as a 32-bit integer has no fraction > bits, so adding 0.5, followed by roundTiesToEven, rounds upwards. This > problem manifests for every odd integer within the binade from > 0x1.000002p+23 to 0x1.fffffep+23, whether positive or negative. There > is a corresponding problem for the `double` range. > > The patch for JDK-8279508 handles this by flipping the floating-point > rounding mode to roundTowardNegative, adding 0.5, and taking the > floor. While this does work on AArch64, the performance is > tragic. AArch64 implementations seem to wait for all instructions in > flight to retire, change the rounding mode, and do the operation. This > effectively serializes the entire thread. > > This patch takes a different approach. Firstly, we can observe that we > can use the `frinta` instruction for the entire positive range. The > negative range is a bit trickier, but we can observe that any x, > abs{x) >= -0x1.000000p+23, has no fractional bits so it must be an > integer. For convenence, we can convert that range with the `frinta` > instruction as well. > > All that remains are x < 0, abs{x) < -0x1.000000p+23. Adding 0.5 > followed by roundTiesToEven doesn't lead to a problem because for > x < 0 && abs{x) >= 0.5, adding 0.5 only reduces the magnitude of x; > for all x < 0 && abs{x) < 0.5, adding 0.5 followed by roundTiesToEven > return 0. Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: Test comparisons with zero ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8204/files - new: https://git.openjdk.java.net/jdk/pull/8204/files/6ae678bc..3632d35c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8204&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8204&range=03-04 Stats: 1187 lines in 2 files changed: 34 ins; 2 del; 1151 mod Patch: https://git.openjdk.java.net/jdk/pull/8204.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8204/head:pull/8204 PR: https://git.openjdk.java.net/jdk/pull/8204 From aph at openjdk.java.net Wed Apr 20 17:31:08 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Wed, 20 Apr 2022 17:31:08 GMT Subject: RFR: 8282541: AArch64: Auto-vectorize Math.round API [v6] In-Reply-To: References: Message-ID: > Before, Apple M1: > > +-----------------------------------------+---------------------------------+ > |Benchmark | (TESTSIZE) Mode Score Units| > +-----------------------------------------+---------------------------------+ > |FpRoundingBenchmark.test_round_double | 1024 thrpt 1612.391 ops/ms| > |FpRoundingBenchmark.test_round_double | 2048 thrpt 804.291 ops/ms| > |FpRoundingBenchmark.test_round_float | 1024 thrpt 1558.202 ops/ms| > |FpRoundingBenchmark.test_round_float | 2048 thrpt 775.730 ops/ms| > +------------------------------------------+--------------------------------+ > > After: > > +-----------------------------------------+----------------------------------+ > |Benchmark | (TESTSIZE) Mode Score Units| > +-----------------------------------------+----------------------------------+ > |FpRoundingBenchmark.test_round_double | 1024 thrpt 2720.153 ops/ms| > |FpRoundingBenchmark.test_round_double | 2048 thrpt 1371.750 ops/ms| > |FpRoundingBenchmark.test_round_float | 1024 thrpt 5940.263 ops/ms| > |FpRoundingBenchmark.test_round_float | 2048 thrpt 3036.201 ops/ms| > +-----------------------------------------+----------------------------------+ > > About the algorithm: > > `Math.round()` is tricky. Its specification corresponds to no standard > rounding mode: it "returns the closest long to the argument, with ties > rounding to positive infinity." For positive inputs this is the same > as IEEE-754's `convertToIntegerTiesToAway` operation, which rounds > away from zero, but there's no equivalent for negative inputs. > > `Math.round()` used simply to add 0.5 and convert to integer by taking > the floor of the result, but that wasn't right because it suffers from > double rounding. This breaks several cases, in particular because > > `0.4999999... (+) 0.5 == 1.0` > > (Here, `(+)` indicates an addition followed by roundTiesToEven.) > > There is no corresponding problem with `-0.4999999...` or `-0.9999999...` > > Also, in the 32-bit `float` case, > > `8388609 (+) 0.5 == 8388610` > > because 8388609 (0x1.000002p+23) as a 32-bit integer has no fraction > bits, so adding 0.5, followed by roundTiesToEven, rounds upwards. This > problem manifests for every odd integer within the binade from > 0x1.000002p+23 to 0x1.fffffep+23, whether positive or negative. There > is a corresponding problem for the `double` range. > > The patch for JDK-8279508 handles this by flipping the floating-point > rounding mode to roundTowardNegative, adding 0.5, and taking the > floor. While this does work on AArch64, the performance is > tragic. AArch64 implementations seem to wait for all instructions in > flight to retire, change the rounding mode, and do the operation. This > effectively serializes the entire thread. > > This patch takes a different approach. Firstly, we can observe that we > can use the `frinta` instruction for the entire positive range. The > negative range is a bit trickier, but we can observe that any x, > abs{x) >= -0x1.000000p+23, has no fractional bits so it must be an > integer. For convenence, we can convert that range with the `frinta` > instruction as well. > > All that remains are x < 0, abs{x) < -0x1.000000p+23. Adding 0.5 > followed by roundTiesToEven doesn't lead to a problem because for > x < 0 && abs{x) >= 0.5, adding 0.5 only reduces the magnitude of x; > for all x < 0 && abs{x) < 0.5, adding 0.5 followed by roundTiesToEven > return 0. Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: Untabify ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8204/files - new: https://git.openjdk.java.net/jdk/pull/8204/files/3632d35c..ebe17660 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8204&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8204&range=04-05 Stats: 1037 lines in 1 file changed: 0 ins; 0 del; 1037 mod Patch: https://git.openjdk.java.net/jdk/pull/8204.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8204/head:pull/8204 PR: https://git.openjdk.java.net/jdk/pull/8204 From duke at openjdk.java.net Wed Apr 20 17:31:11 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Wed, 20 Apr 2022 17:31:11 GMT Subject: RFR: 8283643: [AIX, testbug] MachCodeFramesInErrorFile test fails to find 'Native frames' text [v4] In-Reply-To: References: Message-ID: > I observed a failure of MachCodeFramesInErrorFile.java on AIX. The raised error complains that 'Native frames: ' is missing. To fix the failure, I made two changes to the test that allowed it to pass on AIX. > > The first change made was to the test's `extractFrames` method. AIX overrides `os::platform_print_native_stack` with stack printing specific to AIX/Power. This code does not produce the 'Native frames: ' text that `vmError::print_native_stack` does, so the test was modified to expect the AIX output when run on AIX. > > A second change was made to the address passed to the `crashInNative1` method. AIX does not consider low-address memory to be protected as other platforms do. In fact, "the first 256 bytes are reserved for software use" according to the Power ISA. Accordingly, the read address for PPC was changed to -1 (0xFF..FF) to produce the expected failure result. > > ### Testing > > Tier1 tests complete as expected on AIX/Power. Tyler Steele has updated the pull request incrementally with one additional commit since the last revision: Test: Sample error with no printing should print hs_err output ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8094/files - new: https://git.openjdk.java.net/jdk/pull/8094/files/3c288176..6c70a45d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8094&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8094&range=02-03 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8094.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8094/head:pull/8094 PR: https://git.openjdk.java.net/jdk/pull/8094 From eliu at openjdk.java.net Wed Apr 20 17:34:30 2022 From: eliu at openjdk.java.net (Eric Liu) Date: Wed, 20 Apr 2022 17:34:30 GMT Subject: RFR: 8284563: AArch64: bitperm feature detection for SVE2 on Linux [v2] In-Reply-To: References: Message-ID: <_cBWVpxp8Dr7gdDTd_ymOxix-Zgc9DOloj1boxa6lJo=.75ffe4d4-a7cd-4a15-bb14-f5492b242189@github.com> On Mon, 18 Apr 2022 10:58:39 GMT, Eric Liu wrote: >> This patch adds BITPERM feature detection for SVE2 on Linux. BITPERM is >> an optional feature in SVE2 [1]. It enables 3 SVE2 instructions (BEXT, >> BDEP, BGRP). BEXT and BDEP map efficiently to some vector operations, >> e.g., the compress and expand functionalities [2] which are proposed in >> VectorAPI's 4th incubation [3]. Besides, to generate specific code based >> on different architecture features like x86, this patch exports >> VM_Version::supports_XXX() for all CPU features. E.g., >> VM_Version::supports_svebitperm() for easy use. >> >> This patch also fixes a trivial bug, that sets UseSVE back to 1 if it's >> 2 in SVE1 system. >> >> [1] https://developer.arm.com/documentation/ddi0601/2022-03/AArch64-Registers/ID-AA64ZFR0-EL1--SVE-Feature-ID-register-0 >> [2] https://bugs.openjdk.java.net/browse/JDK-8283893 >> [3] https://bugs.openjdk.java.net/browse/JDK-8280173 > > Eric Liu has updated the pull request incrementally with one additional commit since the last revision: > > small fix > > Change-Id: Ida979f925055761ad73e50655d0584dcee24aea4 I guess the new name `sha2` caused this issue. My intention was to align the name and CPU feature. I checked the related code but missed this test case at that time. Do you have plan to fix it? Or I can withdraw the name back certainly. ------------- PR: https://git.openjdk.java.net/jdk/pull/8258 From duke at openjdk.java.net Wed Apr 20 17:39:16 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Wed, 20 Apr 2022 17:39:16 GMT Subject: RFR: 8283643: [AIX, testbug] MachCodeFramesInErrorFile test fails to find 'Native frames' text [v5] In-Reply-To: References: Message-ID: > I observed a failure of MachCodeFramesInErrorFile.java on AIX. The raised error complains that 'Native frames: ' is missing. To fix the failure, I made two changes to the test that allowed it to pass on AIX. > > The first change made was to the test's `extractFrames` method. AIX overrides `os::platform_print_native_stack` with stack printing specific to AIX/Power. This code does not produce the 'Native frames: ' text that `vmError::print_native_stack` does, so the test was modified to expect the AIX output when run on AIX. > > A second change was made to the address passed to the `crashInNative1` method. AIX does not consider low-address memory to be protected as other platforms do. In fact, "the first 256 bytes are reserved for software use" according to the Power ISA. Accordingly, the read address for PPC was changed to -1 (0xFF..FF) to produce the expected failure result. > > ### Testing > > Tier1 tests complete as expected on AIX/Power. Tyler Steele has updated the pull request incrementally with two additional commits since the last revision: - Revert "Test: Sample error with no printing should print hs_err output" This reverts commit 6c70a45d862c1aa26d9c4d585bf8ecd39892e3bb. - Adds logging to stdout/stderr to prevent too-long Exception messages. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8094/files - new: https://git.openjdk.java.net/jdk/pull/8094/files/6c70a45d..d13f91af Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8094&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8094&range=03-04 Stats: 6 lines in 1 file changed: 1 ins; 2 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/8094.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8094/head:pull/8094 PR: https://git.openjdk.java.net/jdk/pull/8094 From duke at openjdk.java.net Wed Apr 20 17:47:36 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Wed, 20 Apr 2022 17:47:36 GMT Subject: RFR: 8283643: [AIX, testbug] MachCodeFramesInErrorFile test fails to find 'Native frames' text [v5] In-Reply-To: References: Message-ID: On Wed, 20 Apr 2022 16:05:13 GMT, Martin Doerr wrote: >> OK! >> This was an odd one; I was getting errors that complained about the length of the message in the exception. It looked like 2^16 was the max number of characters that could be included in a RuntimeException. I haven't found the upper limit documented anywhere, but I would get unexpected failures with it included in the message. The text prints to stdout, so I didn't suffer by removing it. > > Maybe just print the last line? I did a bit more testing to jog my memory (it has been a little while since I made these changes). You were right to be concerned about the removal; the error text is not printed automatically. To avoid having an exception message be too long, I printed the String to std[out|err] using the usual System.[out|err].println methods. Good catch :slightly_smiling_face: ------------- PR: https://git.openjdk.java.net/jdk/pull/8094 From kvn at openjdk.java.net Wed Apr 20 17:55:27 2022 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Wed, 20 Apr 2022 17:55:27 GMT Subject: RFR: 8284563: AArch64: bitperm feature detection for SVE2 on Linux [v2] In-Reply-To: References: Message-ID: On Mon, 18 Apr 2022 10:58:39 GMT, Eric Liu wrote: >> This patch adds BITPERM feature detection for SVE2 on Linux. BITPERM is >> an optional feature in SVE2 [1]. It enables 3 SVE2 instructions (BEXT, >> BDEP, BGRP). BEXT and BDEP map efficiently to some vector operations, >> e.g., the compress and expand functionalities [2] which are proposed in >> VectorAPI's 4th incubation [3]. Besides, to generate specific code based >> on different architecture features like x86, this patch exports >> VM_Version::supports_XXX() for all CPU features. E.g., >> VM_Version::supports_svebitperm() for easy use. >> >> This patch also fixes a trivial bug, that sets UseSVE back to 1 if it's >> 2 in SVE1 system. >> >> [1] https://developer.arm.com/documentation/ddi0601/2022-03/AArch64-Registers/ID-AA64ZFR0-EL1--SVE-Feature-ID-register-0 >> [2] https://bugs.openjdk.java.net/browse/JDK-8283893 >> [3] https://bugs.openjdk.java.net/browse/JDK-8280173 > > Eric Liu has updated the pull request incrementally with one additional commit since the last revision: > > small fix > > Change-Id: Ida979f925055761ad73e50655d0584dcee24aea4 I am testing the fix: rename `sha2` back to `sha256`. ------------- PR: https://git.openjdk.java.net/jdk/pull/8258 From duke at openjdk.java.net Wed Apr 20 18:00:32 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Wed, 20 Apr 2022 18:00:32 GMT Subject: RFR: 8283643: [AIX, testbug] MachCodeFramesInErrorFile test fails to find 'Native frames' text In-Reply-To: References: Message-ID: <0qc-nQXYTAwL99zobq3zPjTtZhPsI-6vbKGgD-xG4H8=.6b1ebe36-3825-4af8-b7de-cd8170d1afc9@github.com> On Wed, 20 Apr 2022 05:49:15 GMT, Thomas Stuefe wrote: > ...feel free to tweak the native stack printing on os_aix.cpp to print "Native" etc like the other variants do. It is just cosmetics, and the less AIX specifics in shared code the better. This worked well! I incorporated this change. Regarding publishing `VMError::segfault_address` via a Whitebox method. I think this is meaty enough to warrant it's own issue and PR. I'll add that to my todo list and tag you when it's ready for review. In that PR I will scan through the project for tests where the change can be used and make changes as appropriate. My AIX testing is again passing. Converting this back to and open PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/8094 From ioi.lam at oracle.com Wed Apr 20 18:09:03 2022 From: ioi.lam at oracle.com (Ioi Lam) Date: Wed, 20 Apr 2022 11:09:03 -0700 Subject: [RFC 8285277] - How should the JVM handle container memory limits Message-ID: <955f87a4-333d-eabe-aba4-2c302075b99a@oracle.com> I would like to have a discussion on how (or whether) the JVM should handle container memory limits -- see JDK-8285277 [1] The JVM may be terminated by the Linux OOM killer if it tries to use more memory than the memory limit specified for a container. JDK-8284900 [2] tries to avoid OOM by checking InitialHeapSize against the memory limit. However, this is incomplete because the JVM can use memory in other ways: - If -Xmx is larger than -Xms, the heap may expand - malloc memory - code cache - thread stacks We have several choices: (a) Following the direction of JDK-8284900, check for the initial memory usage? of other types of memory as well. The problem with this is that checking the "initial" usage some type of memory usage (malloc or stack) is difficult or impossible. (b) Avoid committing more memory when the total memory usage is close to the limit. E.g., avoid expanding the Java heap, or return NULL from os::malloc(). The problem is that some operations in the VM cannot handle malloc failure and will terminate the VM anyway. Also, trying to obey the memory limit with concurrent allocator/deallocator threads is probably difficult or impossible. (c) Do not consider the memory limit and let the VM be killed by the OOM killer. This may be what the user wants -- the user knows that the app will normally run within the memory limit, so if the heap expands too much the app probably has a memory leak and should be killed, to be automatically restarted by an external mechanism (such as Kubernetes). [1] https://bugs.openjdk.java.net/browse/JDK-8285277 [2] https://bugs.openjdk.java.net/browse/JDK-8284900 From duke at openjdk.java.net Wed Apr 20 18:32:22 2022 From: duke at openjdk.java.net (XenoAmess) Date: Wed, 20 Apr 2022 18:32:22 GMT Subject: RFR: 8285149: Using HashMap.newHashMap to replace new HashMap(int) [v2] In-Reply-To: References: Message-ID: > These are the changes that too many to be reviewed in 8186958, thus split some of them out. XenoAmess has updated the pull request incrementally with two additional commits since the last revision: - add more replaces - add more replaces ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8301/files - new: https://git.openjdk.java.net/jdk/pull/8301/files/2ac4d7bc..28afb90b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8301&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8301&range=00-01 Stats: 109 lines in 64 files changed: 0 ins; 10 del; 99 mod Patch: https://git.openjdk.java.net/jdk/pull/8301.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8301/head:pull/8301 PR: https://git.openjdk.java.net/jdk/pull/8301 From duke at openjdk.java.net Wed Apr 20 18:42:39 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Wed, 20 Apr 2022 18:42:39 GMT Subject: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing [v9] In-Reply-To: References: Message-ID: On Thu, 14 Apr 2022 15:19:17 GMT, Johannes Bechberger wrote: >> Move the AsyncGetCallTrace method implementation into a separate method and wrap its call in non-assert compilation mode in `os::ThreadCrashProtection` like it is done in [JFR](https://github.com/openjdk/jdk/blob/965ea8d9cd29aee41ba2b1b0b0c67bb67eca22dd/src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp#L165). >> This prevents AsyncGetCallTrace from crashing on segmentation faults (but not on `guarantee`s). >> >> If a crash is observed, then the `num_frames` field of the trace is set to `ticks_unknown_state` (-7) to signal a state that cannot be properly handled. `ticks_unknown_state` is currently also used for signaling unknown thread states but this should not be a problem, as the semantic is the same. If `num_frames` already has an error code then this error code is not changed. This helps to distinguish between errors in walking threads in Java and non-Java mode, as `num_frames` is set there before the walking to the appropriate error code. >> >> _Thanks for @tstuefe for suggesting this._ > > Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: > > Use JavaThread::current_or_null This is what the ASGCT2 JEP is for. I'm happy to discuss my JEP draft with you next week, drop me a mail when you have time. ------------- PR: https://git.openjdk.java.net/jdk/pull/8225 From dnsimon at openjdk.java.net Wed Apr 20 19:12:30 2022 From: dnsimon at openjdk.java.net (Doug Simon) Date: Wed, 20 Apr 2022 19:12:30 GMT Subject: RFR: 8283643: [AIX, testbug] MachCodeFramesInErrorFile test fails to find 'Native frames' text [v5] In-Reply-To: References: Message-ID: On Wed, 20 Apr 2022 17:39:16 GMT, Tyler Steele wrote: >> I observed a failure of MachCodeFramesInErrorFile.java on AIX. The raised error complains that 'Native frames: ' is missing. To fix the failure, I made two changes to the test that allowed it to pass on AIX. >> >> The first change made was to the test's `extractFrames` method. AIX overrides `os::platform_print_native_stack` with stack printing specific to AIX/Power. This code does not produce the 'Native frames: ' text that `vmError::print_native_stack` does, so the test was modified to expect the AIX output when run on AIX. [Edit: The changes made to `extractFrames` are now minimal. I made the change to `AixNativeCallstack::print_callstack_for_context` instead.] >> >> A second change was made to the address passed to the `crashInNative1` method. AIX does not consider low-address memory to be protected as other platforms do. In fact, "the first 256 bytes are reserved for software use" according to the Power ISA. Accordingly, the read address for PPC was changed to -1 (0xFF..FF) to produce the expected failure result. >> >> ### Testing >> >> Tier1 tests complete as expected on AIX/Power. > > Tyler Steele has updated the pull request incrementally with two additional commits since the last revision: > > - Revert "Test: Sample error with no printing should print hs_err output" > > This reverts commit 6c70a45d862c1aa26d9c4d585bf8ecd39892e3bb. > - Adds logging to stdout/stderr to prevent too-long Exception messages. test/hotspot/jtreg/runtime/ErrorHandling/MachCodeFramesInErrorFile.java line 133: > 131: System.out.println("stdout:\n" + output.getStdout()); > 132: System.err.println("stderr:\n" + output.getStderr()); > 133: throw new RuntimeException("Did not find hs_err_pid file in output"); Why this change (and a similar one at the end of the file)? This separates the reporting of a failed condition (i.e., could not find expected patten in output) from the context (i.e. contents of stderr and stdout) that assists in diagnosing why the condition may have failed. ------------- PR: https://git.openjdk.java.net/jdk/pull/8094 From duke at openjdk.java.net Wed Apr 20 19:24:25 2022 From: duke at openjdk.java.net (XenoAmess) Date: Wed, 20 Apr 2022 19:24:25 GMT Subject: RFR: 8285149: Using HashMap.newHashMap to replace new HashMap(int) [v3] In-Reply-To: References: Message-ID: > These are the changes that too many to be reviewed in 8186958, thus split some of them out. XenoAmess has updated the pull request incrementally with one additional commit since the last revision: add more replaces ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8301/files - new: https://git.openjdk.java.net/jdk/pull/8301/files/28afb90b..4f2d4838 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8301&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8301&range=01-02 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/8301.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8301/head:pull/8301 PR: https://git.openjdk.java.net/jdk/pull/8301 From dnsimon at openjdk.java.net Wed Apr 20 20:04:27 2022 From: dnsimon at openjdk.java.net (Doug Simon) Date: Wed, 20 Apr 2022 20:04:27 GMT Subject: RFR: 8283839: [JVMCI] add support for querying indy bootstrap method target and arguments [v2] In-Reply-To: <3Y7lnowqF1MmR5iCV5cSsz9FPpPINUKIiM4jTkzznzs=.53b6176d-c32a-4cac-8e93-8826baa67057@github.com> References: <3Y7lnowqF1MmR5iCV5cSsz9FPpPINUKIiM4jTkzznzs=.53b6176d-c32a-4cac-8e93-8826baa67057@github.com> Message-ID: On Wed, 20 Apr 2022 16:25:09 GMT, Paul Sandoz wrote: > Looks good (not an expert on JVMCI but i could follow the change). I am presuming no CSR is required for the new public method. Since JVMCI is not public API (no packages in `jdk.internal.vm.ci` are exported unqualified), I don't believe a CSR is needed. ------------- PR: https://git.openjdk.java.net/jdk/pull/8273 From dnsimon at openjdk.java.net Wed Apr 20 20:12:26 2022 From: dnsimon at openjdk.java.net (Doug Simon) Date: Wed, 20 Apr 2022 20:12:26 GMT Subject: RFR: 8283839: [JVMCI] add support for querying indy bootstrap method target and arguments [v2] In-Reply-To: <3Y7lnowqF1MmR5iCV5cSsz9FPpPINUKIiM4jTkzznzs=.53b6176d-c32a-4cac-8e93-8826baa67057@github.com> References: <3Y7lnowqF1MmR5iCV5cSsz9FPpPINUKIiM4jTkzznzs=.53b6176d-c32a-4cac-8e93-8826baa67057@github.com> Message-ID: On Wed, 20 Apr 2022 16:25:09 GMT, Paul Sandoz wrote: >> Doug Simon has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains two new commits since the last revision: >> >> - added ConstantPool.lookupBootstrapMethod >> - use @jvms javadoc tag > > Looks good (not an expert on JVMCI but i could follow the change). I am presuming no CSR is required for the new public method. Thanks for the review @PaulSandoz . ------------- PR: https://git.openjdk.java.net/jdk/pull/8273 From kvn at openjdk.java.net Wed Apr 20 20:18:27 2022 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Wed, 20 Apr 2022 20:18:27 GMT Subject: RFR: 8283839: [JVMCI] add support for querying indy bootstrap method target and arguments [v2] In-Reply-To: References: Message-ID: On Wed, 20 Apr 2022 07:38:59 GMT, Doug Simon wrote: >> This PR adds support to JVMCI for obtaining the call info for the bootstrap method associated with an invokedynamic or constantdynamic constant pool entry. >> >> In the context of Native Image, this is necessary to be able to defer execution of select bootstrap methods to image run time (as opposed to executing the bootstrap method during Native Image build time). >> >> I've also included a minor change to adopt use of the `jvms` javadoc tag in JVMCI Java code. This is preferable to the HTML links previously used in that the latter refer to a specific JDK release. > > Doug Simon has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains two new commits since the last revision: > > - added ConstantPool.lookupBootstrapMethod > - use @jvms javadoc tag Seems fine. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8273 From dnsimon at openjdk.java.net Wed Apr 20 20:25:45 2022 From: dnsimon at openjdk.java.net (Doug Simon) Date: Wed, 20 Apr 2022 20:25:45 GMT Subject: RFR: 8283839: [JVMCI] add support for querying indy bootstrap method target and arguments [v2] In-Reply-To: References: Message-ID: On Wed, 20 Apr 2022 20:14:35 GMT, Vladimir Kozlov wrote: >> Doug Simon has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains two new commits since the last revision: >> >> - added ConstantPool.lookupBootstrapMethod >> - use @jvms javadoc tag > > Seems fine. Thanks for the review @vnkozlov . ------------- PR: https://git.openjdk.java.net/jdk/pull/8273 From dnsimon at openjdk.java.net Wed Apr 20 20:28:41 2022 From: dnsimon at openjdk.java.net (Doug Simon) Date: Wed, 20 Apr 2022 20:28:41 GMT Subject: Integrated: 8283839: [JVMCI] add support for querying indy bootstrap method target and arguments In-Reply-To: References: Message-ID: On Sat, 16 Apr 2022 16:06:48 GMT, Doug Simon wrote: > This PR adds support to JVMCI for obtaining the call info for the bootstrap method associated with an invokedynamic or constantdynamic constant pool entry. > > In the context of Native Image, this is necessary to be able to defer execution of select bootstrap methods to image run time (as opposed to executing the bootstrap method during Native Image build time). > > I've also included a minor change to adopt use of the `jvms` javadoc tag in JVMCI Java code. This is preferable to the HTML links previously used in that the latter refer to a specific JDK release. This pull request has now been integrated. Changeset: 8543aaa7 Author: Doug Simon URL: https://git.openjdk.java.net/jdk/commit/8543aaa7eb84e8e12924f4e7db7ae33af6020648 Stats: 342 lines in 13 files changed: 306 ins; 14 del; 22 mod 8283839: [JVMCI] add support for querying indy bootstrap method target and arguments Reviewed-by: psandoz, kvn ------------- PR: https://git.openjdk.java.net/jdk/pull/8273 From kvn at openjdk.java.net Wed Apr 20 20:59:26 2022 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Wed, 20 Apr 2022 20:59:26 GMT Subject: RFR: 8242440: use separate, destroyable JavaVM instances per libgraal compiler thread [v3] In-Reply-To: References: Message-ID: On Tue, 19 Apr 2022 10:17:14 GMT, Doug Simon wrote: >> Currently, libgraal runs in a single, permanent JavaVM instance loaded from libjvmcicompiler.so. This poses 2 problems: >> >> 1. The memory used for libgraal is never released, even when the libgraal compiler queues are idle. >> 2. Since all libgraal HotSpot compiler threads share the same SVM heap, libgraal compilation is effectively paused when a GC occurs (SVM currently has a stop the world collector). The more compiler threads there are, the more often this happens. >> >> This PR implements the following solution to these problems: >> 1. Create a new JavaVM instance per libgraal compiler thread (i.e. a separate SVM isolate per thread). This prevents GC in one libgraal thread from impacting another libgraal thread. >> 2. Destroy the JavaVM instances when a libgraal compiler thread becomes idle and create a new one when subsequent compilation requests arrive. >> >> Most of the changes are in JVMCI specific files. The most significant change to shared code is the addition of the `JavaThread:: _libjvmci_runtime` field. This is required as any thread (not just a `CompilerThread`) can be associated with a specific `JVMCIRuntime` object. > > Doug Simon has updated the pull request incrementally with one additional commit since the last revision: > > removed (incorrect) volatile modifier from JVMCIRuntime::_shared_library_javavm Preliminary comment. I agree with David that calling additional library `JavaVM` is confusing and is not correct. This is SVM: "The former each encapsulate a single SubstrateVM runtime". May be you should called as such in code and comments. src/hotspot/share/jvmci/jvmci_globals.hpp line 64: > 62: "Max number of threads per JVMCI native runtime. " \ > 63: "Specify 0 to force use of a single JVMCI native runtime. ") \ > 64: range(0, max_jint) \ Does it mean that value `0` has the same effect as `1`? ------------- PR: https://git.openjdk.java.net/jdk/pull/8262 From kvn at openjdk.java.net Wed Apr 20 21:12:48 2022 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Wed, 20 Apr 2022 21:12:48 GMT Subject: RFR: 8285266: compiler/intrinsics/sha/cli/TestUseSHA256IntrinsicsOptionOnUnsupportedCPU.java fails after JDK-8284563 Message-ID: Changes for #8258 renamed `sha256` aarch64 feature to `sha2`. Unfortunately this name is used by testing to determine if a feature is supported: [IntrinsicPredicates.java#L78](https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/compiler/testlibrary/sha/predicate/IntrinsicPredicates.java#L78) I reverted the name back to fix the issue. Tested tier1-3. ------------- Commit messages: - 8285266: compiler/intrinsics/sha/cli/TestUseSHA256IntrinsicsOptionOnUnsupportedCPU.java fails after JDK-8284563 Changes: https://git.openjdk.java.net/jdk/pull/8324/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8324&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8285266 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/8324.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8324/head:pull/8324 PR: https://git.openjdk.java.net/jdk/pull/8324 From dnsimon at openjdk.java.net Wed Apr 20 21:20:43 2022 From: dnsimon at openjdk.java.net (Doug Simon) Date: Wed, 20 Apr 2022 21:20:43 GMT Subject: RFR: 8242440: use separate, destroyable JavaVM instances per libgraal compiler thread [v3] In-Reply-To: References: Message-ID: <1sJf6-Ss1G3CUj1fY_PvUyfRAIscl1EVfLpnIe-GUKA=.f0914015-5965-45ed-9469-4414ef122fc0@github.com> On Wed, 20 Apr 2022 20:56:19 GMT, Vladimir Kozlov wrote: > Preliminary comment. I agree with David that calling additional library `JavaVM` is confusing and is not correct. This is SVM: "The former each encapsulate a single SubstrateVM runtime". May be you should called as such in code and comments. `JavaVM` is a JNI defined type and HotSpot instantiates and communicates with libgraal purely through JNI so I believe it is the right terminology. The fact that libgraal is built with SVM is an implementation detail that HotSpot is not aware of. That's why "SVM" does not appear anywhere in the JVMCI C++ code. > src/hotspot/share/jvmci/jvmci_globals.hpp line 64: > >> 62: "Max number of threads per JVMCI native runtime. " \ >> 63: "Specify 0 to force use of a single JVMCI native runtime. ") \ >> 64: range(0, max_jint) \ > > Does it mean that value `0` has the same effect as `1`? No. `0` means there is a single JVMCI native runtime shared by all threads where as `1` means each thread (that accesses JVMCI) gets its own unique isolate. ------------- PR: https://git.openjdk.java.net/jdk/pull/8262 From mikael at openjdk.java.net Wed Apr 20 22:08:27 2022 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Wed, 20 Apr 2022 22:08:27 GMT Subject: RFR: 8285266: compiler/intrinsics/sha/cli/TestUseSHA256IntrinsicsOptionOnUnsupportedCPU.java fails after JDK-8284563 In-Reply-To: References: Message-ID: On Wed, 20 Apr 2022 21:06:34 GMT, Vladimir Kozlov wrote: > Changes for #8258 renamed `sha256` aarch64 feature to `sha2`. Unfortunately this name is used by testing to determine if a feature is supported: [IntrinsicPredicates.java#L78](https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/compiler/testlibrary/sha/predicate/IntrinsicPredicates.java#L78) > > I reverted the name back to fix the issue. Tested tier1-3. Marked as reviewed by mikael (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8324 From kvn at openjdk.java.net Wed Apr 20 22:09:51 2022 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Wed, 20 Apr 2022 22:09:51 GMT Subject: RFR: 8242440: use separate, destroyable JavaVM instances per libgraal compiler thread [v3] In-Reply-To: <1sJf6-Ss1G3CUj1fY_PvUyfRAIscl1EVfLpnIe-GUKA=.f0914015-5965-45ed-9469-4414ef122fc0@github.com> References: <1sJf6-Ss1G3CUj1fY_PvUyfRAIscl1EVfLpnIe-GUKA=.f0914015-5965-45ed-9469-4414ef122fc0@github.com> Message-ID: <49wj3wzSk5R0Xkq8VPwASyQ7IMLAPTaNicEUaqxk7_Q=.ee92ca20-ee17-45de-b5f0-0381976c44d7@github.com> On Wed, 20 Apr 2022 21:18:04 GMT, Doug Simon wrote: >> src/hotspot/share/jvmci/jvmci_globals.hpp line 64: >> >>> 62: "Max number of threads per JVMCI native runtime. " \ >>> 63: "Specify 0 to force use of a single JVMCI native runtime. ") \ >>> 64: range(0, max_jint) \ >> >> Does it mean that value `0` has the same effect as `1`? > > No. `0` means there is a single JVMCI native runtime shared by all threads where as `1` means each thread (that accesses JVMCI) gets its own unique isolate. ok ------------- PR: https://git.openjdk.java.net/jdk/pull/8262 From kvn at openjdk.java.net Wed Apr 20 22:23:30 2022 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Wed, 20 Apr 2022 22:23:30 GMT Subject: RFR: 8242440: use separate, destroyable JavaVM instances per libgraal compiler thread [v3] In-Reply-To: References: Message-ID: On Tue, 19 Apr 2022 10:17:14 GMT, Doug Simon wrote: >> Currently, libgraal runs in a single, permanent JavaVM instance loaded from libjvmcicompiler.so. This poses 2 problems: >> >> 1. The memory used for libgraal is never released, even when the libgraal compiler queues are idle. >> 2. Since all libgraal HotSpot compiler threads share the same SVM heap, libgraal compilation is effectively paused when a GC occurs (SVM currently has a stop the world collector). The more compiler threads there are, the more often this happens. >> >> This PR implements the following solution to these problems: >> 1. Create a new JavaVM instance per libgraal compiler thread (i.e. a separate SVM isolate per thread). This prevents GC in one libgraal thread from impacting another libgraal thread. >> 2. Destroy the JavaVM instances when a libgraal compiler thread becomes idle and create a new one when subsequent compilation requests arrive. >> >> Most of the changes are in JVMCI specific files. The most significant change to shared code is the addition of the `JavaThread:: _libjvmci_runtime` field. This is required as any thread (not just a `CompilerThread`) can be associated with a specific `JVMCIRuntime` object. > > Doug Simon has updated the pull request incrementally with one additional commit since the last revision: > > removed (incorrect) volatile modifier from JVMCIRuntime::_shared_library_javavm src/hotspot/share/jvmci/jvmciCompiler.cpp line 172: > 170: // Don't detach JVMCI compiler threads from their JVMCI > 171: // runtime during the VM startup grace period > 172: if (runtime != nullptr && delay > 0 && tty->time_stamp().milliseconds() > DEFAULT_COMPILER_IDLE_DELAY) { Can it be more coordinated by some status instead of time? Time depends on machine you run and does not guarantee right case. I could be done in separate changes. ------------- PR: https://git.openjdk.java.net/jdk/pull/8262 From kvn at openjdk.java.net Wed Apr 20 22:40:28 2022 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Wed, 20 Apr 2022 22:40:28 GMT Subject: RFR: 8242440: use separate, destroyable JavaVM instances per libgraal compiler thread [v3] In-Reply-To: References: Message-ID: On Tue, 19 Apr 2022 10:17:14 GMT, Doug Simon wrote: >> Currently, libgraal runs in a single, permanent JavaVM instance loaded from libjvmcicompiler.so. This poses 2 problems: >> >> 1. The memory used for libgraal is never released, even when the libgraal compiler queues are idle. >> 2. Since all libgraal HotSpot compiler threads share the same SVM heap, libgraal compilation is effectively paused when a GC occurs (SVM currently has a stop the world collector). The more compiler threads there are, the more often this happens. >> >> This PR implements the following solution to these problems: >> 1. Create a new JavaVM instance per libgraal compiler thread (i.e. a separate SVM isolate per thread). This prevents GC in one libgraal thread from impacting another libgraal thread. >> 2. Destroy the JavaVM instances when a libgraal compiler thread becomes idle and create a new one when subsequent compilation requests arrive. >> >> Most of the changes are in JVMCI specific files. The most significant change to shared code is the addition of the `JavaThread:: _libjvmci_runtime` field. This is required as any thread (not just a `CompilerThread`) can be associated with a specific `JVMCIRuntime` object. > > Doug Simon has updated the pull request incrementally with one additional commit since the last revision: > > removed (incorrect) volatile modifier from JVMCIRuntime::_shared_library_javavm Changes seems fine to me. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8262 From kvn at openjdk.java.net Wed Apr 20 22:41:30 2022 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Wed, 20 Apr 2022 22:41:30 GMT Subject: RFR: 8285266: compiler/intrinsics/sha/cli/TestUseSHA256IntrinsicsOptionOnUnsupportedCPU.java fails after JDK-8284563 In-Reply-To: References: Message-ID: On Wed, 20 Apr 2022 21:06:34 GMT, Vladimir Kozlov wrote: > Changes for #8258 renamed `sha256` aarch64 feature to `sha2`. Unfortunately this name is used by testing to determine if a feature is supported: [IntrinsicPredicates.java#L78](https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/compiler/testlibrary/sha/predicate/IntrinsicPredicates.java#L78) > > I reverted the name back to fix the issue. Tested tier1-3. I consider it is trivial. ------------- PR: https://git.openjdk.java.net/jdk/pull/8324 From kvn at openjdk.java.net Wed Apr 20 22:47:29 2022 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Wed, 20 Apr 2022 22:47:29 GMT Subject: RFR: 8285266: compiler/intrinsics/sha/cli/TestUseSHA256IntrinsicsOptionOnUnsupportedCPU.java fails after JDK-8284563 In-Reply-To: References: Message-ID: On Wed, 20 Apr 2022 21:06:34 GMT, Vladimir Kozlov wrote: > Changes for #8258 renamed `sha256` aarch64 feature to `sha2`. Unfortunately this name is used by testing to determine if a feature is supported: [IntrinsicPredicates.java#L78](https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/compiler/testlibrary/sha/predicate/IntrinsicPredicates.java#L78) > > I reverted the name back to fix the issue. Tested tier1-3. Thank you, Mikael ------------- PR: https://git.openjdk.java.net/jdk/pull/8324 From kvn at openjdk.java.net Wed Apr 20 22:47:29 2022 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Wed, 20 Apr 2022 22:47:29 GMT Subject: Integrated: 8285266: compiler/intrinsics/sha/cli/TestUseSHA256IntrinsicsOptionOnUnsupportedCPU.java fails after JDK-8284563 In-Reply-To: References: Message-ID: On Wed, 20 Apr 2022 21:06:34 GMT, Vladimir Kozlov wrote: > Changes for #8258 renamed `sha256` aarch64 feature to `sha2`. Unfortunately this name is used by testing to determine if a feature is supported: [IntrinsicPredicates.java#L78](https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/compiler/testlibrary/sha/predicate/IntrinsicPredicates.java#L78) > > I reverted the name back to fix the issue. Tested tier1-3. This pull request has now been integrated. Changeset: 691c5da5 Author: Vladimir Kozlov URL: https://git.openjdk.java.net/jdk/commit/691c5da59352e8473de53e67252d719df1c02601 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod 8285266: compiler/intrinsics/sha/cli/TestUseSHA256IntrinsicsOptionOnUnsupportedCPU.java fails after JDK-8284563 Reviewed-by: mikael ------------- PR: https://git.openjdk.java.net/jdk/pull/8324 From dholmes at openjdk.java.net Thu Apr 21 00:00:24 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 21 Apr 2022 00:00:24 GMT Subject: RFR: 8284877: Check type compatibility before looking up method from receiver's vtable In-Reply-To: References: Message-ID: On Thu, 14 Apr 2022 10:40:21 GMT, Yi Yang wrote: > Hi, can I have a review for this enhancement? This patch adds type compatibility check before method lookup for robustness. In some internal cases, serialization framework may improperly generate an object of wrong type, which leads JVM randomly crashes during method resolution. > > For example: > > invokevirtual selected method: receiver-class:java.util.ArrayList, resolved-class:com.taobao.forest.domain.util.LongMapSupportArrayList, resolved_method:com.taobao.forest.domain.util.LongMapSupportArrayList.toMap()Ljava/util/Map;, selected_method:0x458, vtable_index:56# > > The real type of receiver is ArrayList, while the resolved method is LongMapSupportArrayList.toMap. VM attempts to select method as if looking up from receiver's vtable via vtable index of resolved method(i.e. attempts to lookup `toMap()` from > ArrayList), an invalid method or incorrect method would be selected, thus causing some strange crashes. > > I think it's reasonable to add a type compatibility check before method lookup. If such an incompatible call is found, JVM could throw an exception instead. If Unsafe is being used to circumvent the type system, then we should not be adding additional checks in the VM to catch that later. If you use Unsafe directly and you do it wrong then you can crash the VM - that is not a VM problem to fix. ------------- PR: https://git.openjdk.java.net/jdk/pull/8241 From dholmes at openjdk.java.net Thu Apr 21 00:46:37 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 21 Apr 2022 00:46:37 GMT Subject: RFR: 8284877: Check type compatibility before looking up method from receiver's vtable In-Reply-To: References: Message-ID: On Thu, 14 Apr 2022 10:40:21 GMT, Yi Yang wrote: > Hi, can I have a review for this enhancement? This patch adds type compatibility check before method lookup for robustness. In some internal cases, serialization framework may improperly generate an object of wrong type, which leads JVM randomly crashes during method resolution. > > For example: > > invokevirtual selected method: receiver-class:java.util.ArrayList, resolved-class:com.taobao.forest.domain.util.LongMapSupportArrayList, resolved_method:com.taobao.forest.domain.util.LongMapSupportArrayList.toMap()Ljava/util/Map;, selected_method:0x458, vtable_index:56# > > The real type of receiver is ArrayList, while the resolved method is LongMapSupportArrayList.toMap. VM attempts to select method as if looking up from receiver's vtable via vtable index of resolved method(i.e. attempts to lookup `toMap()` from > ArrayList), an invalid method or incorrect method would be selected, thus causing some strange crashes. > > I think it's reasonable to add a type compatibility check before method lookup. If such an incompatible call is found, JVM could throw an exception instead. src/hotspot/share/interpreter/linkResolver.cpp line 1360: > 1358: // Receriver should be compatible with resolved klass, i.e. it must be a type of resolved klass > 1359: // or a subtype of resolved klass(receiver instanceof resolved_klass) > 1360: if (!recv.is_null() && !recv()->is_a(resolved_klass)) { It might be marginally cheaper to use `recv_klass->is_subtype_of(resolved_klass)` given you already have it available. ------------- PR: https://git.openjdk.java.net/jdk/pull/8241 From dholmes at openjdk.java.net Thu Apr 21 00:50:42 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 21 Apr 2022 00:50:42 GMT Subject: RFR: 8284877: Check type compatibility before looking up method from receiver's vtable In-Reply-To: References: Message-ID: On Thu, 14 Apr 2022 10:40:21 GMT, Yi Yang wrote: > Hi, can I have a review for this enhancement? This patch adds type compatibility check before method lookup for robustness. In some internal cases, serialization framework may improperly generate an object of wrong type, which leads JVM randomly crashes during method resolution. > > For example: > > invokevirtual selected method: receiver-class:java.util.ArrayList, resolved-class:com.taobao.forest.domain.util.LongMapSupportArrayList, resolved_method:com.taobao.forest.domain.util.LongMapSupportArrayList.toMap()Ljava/util/Map;, selected_method:0x458, vtable_index:56# > > The real type of receiver is ArrayList, while the resolved method is LongMapSupportArrayList.toMap. VM attempts to select method as if looking up from receiver's vtable via vtable index of resolved method(i.e. attempts to lookup `toMap()` from > ArrayList), an invalid method or incorrect method would be selected, thus causing some strange crashes. > > I think it's reasonable to add a type compatibility check before method lookup. If such an incompatible call is found, JVM could throw an exception instead. src/hotspot/share/interpreter/linkResolver.cpp line 1363: > 1361: ResourceMark rm(THREAD); > 1362: stringStream ss; > 1363: ss.print("Receiver should be type/subtype of %s", resolved_klass->external_name()); You should report the actual receiver type as well, as anyone encountering this exception would be completely baffled by it. ------------- PR: https://git.openjdk.java.net/jdk/pull/8241 From david.holmes at oracle.com Thu Apr 21 02:30:44 2022 From: david.holmes at oracle.com (David Holmes) Date: Thu, 21 Apr 2022 12:30:44 +1000 Subject: [RFC 8285277] - How should the JVM handle container memory limits In-Reply-To: <955f87a4-333d-eabe-aba4-2c302075b99a@oracle.com> References: <955f87a4-333d-eabe-aba4-2c302075b99a@oracle.com> Message-ID: <7522e6fc-2790-caaf-5b71-2f670ec72d50@oracle.com> On 21/04/2022 4:09 am, Ioi Lam wrote: > I would like to have a discussion on how (or whether) the JVM should > handle container memory limits -- see JDK-8285277 [1] > > > The JVM may be terminated by the Linux OOM killer if it tries to use > more memory than the memory limit specified for a container. JDK-8284900 > [2] tries to avoid OOM by checking InitialHeapSize against the memory > limit. However, this is incomplete because the JVM can use memory in > other ways: > > - If -Xmx is larger than -Xms, the heap may expand > - malloc memory > - code cache > - thread stacks > > We have several choices: > > (a) Following the direction of JDK-8284900, check for the initial memory > usage? of other types of memory as well. The problem with this is that > checking the "initial" usage some type of memory usage (malloc or stack) > is difficult or impossible. > > (b) Avoid committing more memory when the total memory usage is close to > the limit. E.g., avoid expanding the Java heap, or return NULL from > os::malloc(). The problem is that some operations in the VM cannot > handle malloc failure and will terminate the VM anyway. Also, trying to > obey the memory limit with concurrent allocator/deallocator threads is > probably difficult or impossible. > > (c) Do not consider the memory limit and let the VM be killed by the OOM > killer. This may be what the user wants -- the user knows that the app > will normally run within the memory limit, so if the heap expands too > much the app probably has a memory leak and should be killed, to be > automatically restarted by an external mechanism (such as Kubernetes). I guess a combo of (a) and (c). Any memory limit imposed by a container should appear as the value of "available memory" just as if not in a container. So we have been taking available memory into account since day one and making some ergonomic decisions based on that, but not going out of our way to try and avoid the OOMKiller. So I don't see why container memory limits change anything - as long as we apply those limits correctly. Cheers, David > > [1] https://bugs.openjdk.java.net/browse/JDK-8285277 > [2] https://bugs.openjdk.java.net/browse/JDK-8284900 > From dholmes at openjdk.java.net Thu Apr 21 03:03:26 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 21 Apr 2022 03:03:26 GMT Subject: RFR: 8283643: [AIX, testbug] MachCodeFramesInErrorFile test fails to find 'Native frames' text [v5] In-Reply-To: References: Message-ID: <6JSw5OeoBWFr1htYK6NsGjVOY83KTihnrCYoapUDGfI=.b8169d28-444e-4962-96f6-92e67fd31aee@github.com> On Wed, 20 Apr 2022 19:09:15 GMT, Doug Simon wrote: >> Tyler Steele has updated the pull request incrementally with two additional commits since the last revision: >> >> - Revert "Test: Sample error with no printing should print hs_err output" >> >> This reverts commit 6c70a45d862c1aa26d9c4d585bf8ecd39892e3bb. >> - Adds logging to stdout/stderr to prevent too-long Exception messages. > > test/hotspot/jtreg/runtime/ErrorHandling/MachCodeFramesInErrorFile.java line 133: > >> 131: System.out.println("stdout:\n" + output.getStdout()); >> 132: System.err.println("stderr:\n" + output.getStderr()); >> 133: throw new RuntimeException("Did not find hs_err_pid file in output"); > > Why this change (and a similar one at the end of the file)? This separates the reporting of a failed condition (i.e., could not find expected patten in output) from the context (i.e. contents of stderr and stdout) that assists in diagnosing why the condition may have failed. Also the test should really take advantage of output.shouldMatch to check for the hs_err line, which in turn will report stdout and stderr on failure, and throw the exception. ------------- PR: https://git.openjdk.java.net/jdk/pull/8094 From dholmes at openjdk.java.net Thu Apr 21 03:11:26 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 21 Apr 2022 03:11:26 GMT Subject: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing [v9] In-Reply-To: References: Message-ID: <_3ndQ6uF29rGkGMmcxHykEIE1gAMyIxa8oXmxkz3Kxw=.188d2075-f2ed-4210-b4d4-80c8a1f1a5fa@github.com> On Thu, 14 Apr 2022 15:19:17 GMT, Johannes Bechberger wrote: >> Move the AsyncGetCallTrace method implementation into a separate method and wrap its call in non-assert compilation mode in `os::ThreadCrashProtection` like it is done in [JFR](https://github.com/openjdk/jdk/blob/965ea8d9cd29aee41ba2b1b0b0c67bb67eca22dd/src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp#L165). >> This prevents AsyncGetCallTrace from crashing on segmentation faults (but not on `guarantee`s). >> >> If a crash is observed, then the `num_frames` field of the trace is set to `ticks_unknown_state` (-7) to signal a state that cannot be properly handled. `ticks_unknown_state` is currently also used for signaling unknown thread states but this should not be a problem, as the semantic is the same. If `num_frames` already has an error code then this error code is not changed. This helps to distinguish between errors in walking threads in Java and non-Java mode, as `num_frames` is set there before the walking to the appropriate error code. >> >> _Thanks for @tstuefe for suggesting this._ > > Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: > > Use JavaThread::current_or_null Sorry I wasn't clear - doing this kind of change as part of the ASGCT2 JEP is what I was suggesting. But that is not a JEP that I can actively get involved in. It is really for the serviceability team and JFR team to comment on. Unfortunately folks are very busy at the moment due to the Project Loom preview, so it may be hard to get that discussion going. ------------- PR: https://git.openjdk.java.net/jdk/pull/8225 From yyang at openjdk.java.net Thu Apr 21 06:04:27 2022 From: yyang at openjdk.java.net (Yi Yang) Date: Thu, 21 Apr 2022 06:04:27 GMT Subject: RFR: 8284877: Check type compatibility before looking up method from receiver's vtable [v2] In-Reply-To: References: Message-ID: > Hi, can I have a review for this enhancement? This patch adds type compatibility check before method lookup for robustness. In some internal cases, serialization framework may improperly generate an object of wrong type, which leads JVM randomly crashes during method resolution. > > For example: > > invokevirtual selected method: receiver-class:java.util.ArrayList, resolved-class:com.taobao.forest.domain.util.LongMapSupportArrayList, resolved_method:com.taobao.forest.domain.util.LongMapSupportArrayList.toMap()Ljava/util/Map;, selected_method:0x458, vtable_index:56# > > The real type of receiver is ArrayList, while the resolved method is LongMapSupportArrayList.toMap. VM attempts to select method as if looking up from receiver's vtable via vtable index of resolved method(i.e. attempts to lookup `toMap()` from > ArrayList), an invalid method or incorrect method would be selected, thus causing some strange crashes. > > I think it's reasonable to add a type compatibility check before method lookup. If such an incompatible call is found, JVM could throw an exception instead. Yi Yang has updated the pull request incrementally with one additional commit since the last revision: add jtreg test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8241/files - new: https://git.openjdk.java.net/jdk/pull/8241/files/5318589b..8acc1b7f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8241&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8241&range=00-01 Stats: 96 lines in 2 files changed: 93 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/8241.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8241/head:pull/8241 PR: https://git.openjdk.java.net/jdk/pull/8241 From yyang at openjdk.java.net Thu Apr 21 06:04:28 2022 From: yyang at openjdk.java.net (Yi Yang) Date: Thu, 21 Apr 2022 06:04:28 GMT Subject: RFR: 8284877: Check type compatibility before looking up method from receiver's vtable In-Reply-To: References: Message-ID: On Wed, 20 Apr 2022 23:57:30 GMT, David Holmes wrote: >> Hi, can I have a review for this enhancement? This patch adds type compatibility check before method lookup for robustness. In some internal cases, serialization framework may improperly generate an object of wrong type, which leads JVM randomly crashes during method resolution. >> >> For example: >> >> invokevirtual selected method: receiver-class:java.util.ArrayList, resolved-class:com.taobao.forest.domain.util.LongMapSupportArrayList, resolved_method:com.taobao.forest.domain.util.LongMapSupportArrayList.toMap()Ljava/util/Map;, selected_method:0x458, vtable_index:56# >> >> The real type of receiver is ArrayList, while the resolved method is LongMapSupportArrayList.toMap. VM attempts to select method as if looking up from receiver's vtable via vtable index of resolved method(i.e. attempts to lookup `toMap()` from >> ArrayList), an invalid method or incorrect method would be selected, thus causing some strange crashes. >> >> I think it's reasonable to add a type compatibility check before method lookup. If such an incompatible call is found, JVM could throw an exception instead. > > If Unsafe is being used to circumvent the type system, then we should not be adding additional checks in the VM to catch that later. If you use Unsafe directly and you do it wrong then you can crash the VM - that is not a VM problem to fix. > @dholmes-ora From?my?understanding, the bytecode is correct, but?the?third?party serialisation?library ends?up incorrectly?deserialising the?`LongMapSupportArrayList`?instance as?an?`ArrayList`, and?then?uses `Unsafe.setObject` to?store?it in?the?`longValues`?field, which?is?typed as?`LongMapSupportArrayList`. > > Then, when the `getValuesMap()` method calls `this.longValues.toMap()`, the?JVM?assumes that?since `longValues` is?typed as?`LongMapSupportArrayList`, the?`LongMapSupportArrayList.toMap:()Ljava/util/Map;`?method will?always?exist, but?since the?`longValues`?field now?contains a?`java.util.ArrayList` (which?doesn?t?have the?`toMap()`?method), the?`vtable`?index is?invalid, which?leads?to a?VM?crash. Exactly right. ------------- PR: https://git.openjdk.java.net/jdk/pull/8241 From yyang at openjdk.java.net Thu Apr 21 06:04:28 2022 From: yyang at openjdk.java.net (Yi Yang) Date: Thu, 21 Apr 2022 06:04:28 GMT Subject: RFR: 8284877: Check type compatibility before looking up method from receiver's vtable [v2] In-Reply-To: References: Message-ID: On Thu, 21 Apr 2022 00:46:51 GMT, David Holmes wrote: >> Yi Yang has updated the pull request incrementally with one additional commit since the last revision: >> >> add jtreg test > > src/hotspot/share/interpreter/linkResolver.cpp line 1363: > >> 1361: ResourceMark rm(THREAD); >> 1362: stringStream ss; >> 1363: ss.print("Receiver should be type/subtype of %s", resolved_klass->external_name()); > > You should report the actual receiver type as well, as anyone encountering this exception would be completely baffled by it. Done. I added a jtreg test case to reproduce it. ------------- PR: https://git.openjdk.java.net/jdk/pull/8241 From dnsimon at openjdk.java.net Thu Apr 21 07:28:30 2022 From: dnsimon at openjdk.java.net (Doug Simon) Date: Thu, 21 Apr 2022 07:28:30 GMT Subject: RFR: 8242440: use separate, destroyable JavaVM instances per libgraal compiler thread In-Reply-To: References: Message-ID: On Mon, 18 Apr 2022 06:55:07 GMT, David Holmes wrote: >> Currently, libgraal runs in a single, permanent JavaVM instance loaded from libjvmcicompiler.so. This poses 2 problems: >> >> 1. The memory used for libgraal is never released, even when the libgraal compiler queues are idle. >> 2. Since all libgraal HotSpot compiler threads share the same SVM heap, libgraal compilation is effectively paused when a GC occurs (SVM currently has a stop the world collector). The more compiler threads there are, the more often this happens. >> >> This PR implements the following solution to these problems: >> 1. Create a new JavaVM instance per libgraal compiler thread (i.e. a separate SVM isolate per thread). This prevents GC in one libgraal thread from impacting another libgraal thread. >> 2. Destroy the JavaVM instances when a libgraal compiler thread becomes idle and create a new one when subsequent compilation requests arrive. >> >> Most of the changes are in JVMCI specific files. The most significant change to shared code is the addition of the `JavaThread:: _libjvmci_runtime` field. This is required as any thread (not just a `CompilerThread`) can be associated with a specific `JVMCIRuntime` object. > > @dougxc I am not clear on what you are doing here, as we don't support loading the JVM more than once per-process and "destroying" a JVM doesn't return a lot of the resources you might expect to be returned. @dholmes-ora @kimbarrett are you ok with this PR now? ------------- PR: https://git.openjdk.java.net/jdk/pull/8262 From dnsimon at openjdk.java.net Thu Apr 21 07:28:30 2022 From: dnsimon at openjdk.java.net (Doug Simon) Date: Thu, 21 Apr 2022 07:28:30 GMT Subject: RFR: 8242440: use separate, destroyable JavaVM instances per libgraal compiler thread [v3] In-Reply-To: References: Message-ID: On Wed, 20 Apr 2022 22:20:07 GMT, Vladimir Kozlov wrote: >> Doug Simon has updated the pull request incrementally with one additional commit since the last revision: >> >> removed (incorrect) volatile modifier from JVMCIRuntime::_shared_library_javavm > > src/hotspot/share/jvmci/jvmciCompiler.cpp line 172: > >> 170: // Don't detach JVMCI compiler threads from their JVMCI >> 171: // runtime during the VM startup grace period >> 172: if (runtime != nullptr && delay > 0 && tty->time_stamp().milliseconds() > DEFAULT_COMPILER_IDLE_DELAY) { > > Can it be more coordinated by some status instead of time? Time depends on machine you run and does not guarantee right case. I could be done in separate changes. This check exists only to avoid adding extra overhead of creating and destroying libgraal runtimes during early VM execution for very short lived apps (i.e. less than 1000 ms). After that, normal libgraal runtime management should not be a problem. In combination with [lazy allocation of compiler threads](https://bugs.openjdk.java.net/browse/JDK-8198756), it's very rare in practice for a compiler thread to want to shutdown anyway during the first 1000 ms of VM execution. ------------- PR: https://git.openjdk.java.net/jdk/pull/8262 From sgehwolf at redhat.com Thu Apr 21 09:49:52 2022 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 21 Apr 2022 11:49:52 +0200 Subject: [RFC 8285277] - How should the JVM handle container memory limits In-Reply-To: <955f87a4-333d-eabe-aba4-2c302075b99a@oracle.com> References: <955f87a4-333d-eabe-aba4-2c302075b99a@oracle.com> Message-ID: On Wed, 2022-04-20 at 11:09 -0700, Ioi Lam wrote: > I would like to have a discussion on how (or whether) the JVM should > handle container memory limits -- see JDK-8285277 [1] It does handle container memory limits. os::physical_memory() returns the container limit instead of the host value if a container limit is in place. That was one big aspect of JDK-8146115 when it was done in JDK 10 timeframe. See: https://github.com/openjdk/jdk/blob/fa04d1f832ff201248f935939fa255988053a1d0/src/hotspot/os/linux/os_linux.cpp #L217..L232 What am I missing? > The JVM may be terminated by the Linux OOM killer if it tries to use > more memory than the memory limit specified for a container. JDK-8284900 > [2] tries to avoid OOM by checking InitialHeapSize against the memory > limit. However, this is incomplete because the JVM can use memory in > other ways: > > - If -Xmx is larger than -Xms, the heap may expand > - malloc memory > - code cache > - thread stacks JDK-8284900 is somewhat a special case which, IIUIC, tries to avoid user-errors detectable at JVM startup. For example setting -Xms to a value >= physical memory (including swap). In this case the JVM would be at risk to get killed by the OOM killer and doing this check on start-up would catch it before it comes to it. On the other hand, I don't see any handling of such a case on a *physical* machine. Consider a machine with 8GB of RAM and somebody spawning a JVM with -Xms8g on it. It'll happily oblige? In one of my VMs with 8GB I see this: $ ./jdk19-jdk/bin/java -Xms8g -XX:+PrintFlagsFinal -version 2>&1 | grep InitialHeapSize size_t InitialHeapSize = 8589934592 {product} {command line} $ free --giga total used free shared buff/cache available Mem: 8 0 7 0 0 7 Swap: 8 0 8 > We have several choices: > > (a) Following the direction of JDK-8284900, check for the initial memory > usage? of other types of memory as well. The problem with this is that > checking the "initial" usage some type of memory usage (malloc or stack) > is difficult or impossible. > > (b) Avoid committing more memory when the total memory usage is close to > the limit. E.g., avoid expanding the Java heap, or return NULL from > os::malloc(). The problem is that some operations in the VM cannot > handle malloc failure and will terminate the VM anyway. Also, trying to > obey the memory limit with concurrent allocator/deallocator threads is > probably difficult or impossible. > > (c) Do not consider the memory limit and let the VM be killed by the OOM > killer. This may be what the user wants -- the user knows that the app > will normally run within the memory limit, so if the heap expands too > much the app probably has a memory leak and should be killed, to be > automatically restarted by an external mechanism (such as Kubernetes). Neither of the above? It would perhaps make sense to do some sanitiy checks on JVM start-up (somewhat akin to JDK-8284900). But this should probably be done with the main operating system API. Not using OSContainer API as proposed in JDK-8284900. For example, print a warning if MaxHeapSize, InitialHeapSize and MinHeapSize are larger than the reported physical memory (and/or cap it at a lower size if so). Isn't (b) being handled by setting os::pysical_memory() and os::available_memory() to the container limits (which we currently do)? It would behave similarly to a physical machine running out of memory, no? Thanks, Severin > [1] https://bugs.openjdk.java.net/browse/JDK-8285277 > [2] https://bugs.openjdk.java.net/browse/JDK-8284900 > From jiefu at openjdk.java.net Thu Apr 21 09:57:18 2022 From: jiefu at openjdk.java.net (Jie Fu) Date: Thu, 21 Apr 2022 09:57:18 GMT Subject: RFR: 8285342: Zero build failure with clang due to values not handled in switch Message-ID: Hi all, May I get reviews for this trivial change? It fixes zero build failure with clang due to values not handled in switch. Thanks. Best regards, Jie ------------- Commit messages: - 8285342: Zero build failure with clang due to values not handled in switch Changes: https://git.openjdk.java.net/jdk/pull/8330/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8330&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8285342 Stats: 4 lines in 2 files changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8330.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8330/head:pull/8330 PR: https://git.openjdk.java.net/jdk/pull/8330 From shade at openjdk.java.net Thu Apr 21 10:05:25 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 21 Apr 2022 10:05:25 GMT Subject: RFR: 8285342: Zero build failure with clang due to values not handled in switch In-Reply-To: References: Message-ID: On Thu, 21 Apr 2022 09:42:36 GMT, Jie Fu wrote: > Hi all, > > May I get reviews for this trivial change? > > It fixes zero build failure with clang due to values not handled in switch. > > Thanks. > Best regards, > Jie I think it should actually be `ShouldNotReachHere()`, and legitimate cases listed as explicit cases. ------------- Changes requested by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8330 From aph at openjdk.java.net Thu Apr 21 10:05:25 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Thu, 21 Apr 2022 10:05:25 GMT Subject: RFR: 8285342: Zero build failure with clang due to values not handled in switch In-Reply-To: References: Message-ID: On Thu, 21 Apr 2022 09:42:36 GMT, Jie Fu wrote: > Hi all, > > May I get reviews for this trivial change? > > It fixes zero build failure with clang due to values not handled in switch. > > Thanks. > Best regards, > Jie src/hotspot/cpu/zero/zeroInterpreter_zero.cpp line 623: > 621: break; > 622: default: > 623: ; `ShouldNotReachHere()` ? Maybe an `assert()` ? ------------- PR: https://git.openjdk.java.net/jdk/pull/8330 From dholmes at openjdk.java.net Thu Apr 21 10:55:30 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 21 Apr 2022 10:55:30 GMT Subject: RFR: 8242440: use separate, destroyable JavaVM instances per libgraal compiler thread In-Reply-To: References: Message-ID: On Thu, 21 Apr 2022 07:24:49 GMT, Doug Simon wrote: >> @dougxc I am not clear on what you are doing here, as we don't support loading the JVM more than once per-process and "destroying" a JVM doesn't return a lot of the resources you might expect to be returned. > > @dholmes-ora @kimbarrett are you ok with this PR now? @dougxc my concern was addressed but I can't review this. ------------- PR: https://git.openjdk.java.net/jdk/pull/8262 From ayang at openjdk.java.net Thu Apr 21 10:56:08 2022 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Thu, 21 Apr 2022 10:56:08 GMT Subject: RFR: 8285364: Use more precise name for ReferenceType::REF_OTHER Message-ID: Simple rename and some comments update. Test: build ------------- Commit messages: - ref-rename Changes: https://git.openjdk.java.net/jdk/pull/8332/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8332&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8285364 Stats: 9 lines in 7 files changed: 0 ins; 0 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/8332.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8332/head:pull/8332 PR: https://git.openjdk.java.net/jdk/pull/8332 From dholmes at openjdk.java.net Thu Apr 21 11:07:34 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 21 Apr 2022 11:07:34 GMT Subject: RFR: 8284877: Check type compatibility before looking up method from receiver's vtable [v2] In-Reply-To: References: Message-ID: On Thu, 21 Apr 2022 06:04:27 GMT, Yi Yang wrote: >> Hi, can I have a review for this enhancement? This patch adds type compatibility check before method lookup for robustness. In some internal cases, serialization framework may improperly generate an object of wrong type, which leads JVM randomly crashes during method resolution. >> >> For example: >> >> invokevirtual selected method: receiver-class:java.util.ArrayList, resolved-class:com.taobao.forest.domain.util.LongMapSupportArrayList, resolved_method:com.taobao.forest.domain.util.LongMapSupportArrayList.toMap()Ljava/util/Map;, selected_method:0x458, vtable_index:56# >> >> The real type of receiver is ArrayList, while the resolved method is LongMapSupportArrayList.toMap. VM attempts to select method as if looking up from receiver's vtable via vtable index of resolved method(i.e. attempts to lookup `toMap()` from >> ArrayList), an invalid method or incorrect method would be selected, thus causing some strange crashes. >> >> I think it's reasonable to add a type compatibility check before method lookup. If such an incompatible call is found, JVM could throw an exception instead. > > Yi Yang has updated the pull request incrementally with one additional commit since the last revision: > > add jtreg test Sorry but I am firmly against this "enhancement". Unsafe.putObject is clearly being used incorrectly and it clearly states: /** * Stores a reference value into a given Java variable. *

* Unless the reference {@code x} being stored is either null * or matches the field type, the results are undefined. The bug is in the library issuing the Unsafe call. The VM does not, and should not, guard against such misuses of Unsafe. ------------- PR: https://git.openjdk.java.net/jdk/pull/8241 From jiefu at openjdk.java.net Thu Apr 21 11:12:46 2022 From: jiefu at openjdk.java.net (Jie Fu) Date: Thu, 21 Apr 2022 11:12:46 GMT Subject: RFR: 8285342: Zero build failure with clang due to values not handled in switch In-Reply-To: References: Message-ID: On Thu, 21 Apr 2022 10:02:17 GMT, Andrew Haley wrote: > `ShouldNotReachHere()` ? Maybe an `assert()` ? We should not add `ShouldNotReachHere()` or `assert()` here. This is because the `entry->flag_state()` may be `itos/ftos...`. The logic is only add one more slot for long/double. So just do nothing here. ------------- PR: https://git.openjdk.java.net/jdk/pull/8330 From kbarrett at openjdk.java.net Thu Apr 21 11:18:55 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Thu, 21 Apr 2022 11:18:55 GMT Subject: RFR: 8285364: Use more precise name for ReferenceType::REF_OTHER In-Reply-To: References: Message-ID: On Thu, 21 Apr 2022 10:48:06 GMT, Albert Mingkun Yang wrote: > Simple rename and some comments update. > > Test: build Changes requested by kbarrett (Reviewer). src/hotspot/share/jfr/recorder/checkpoint/types/jfrType.cpp line 214: > 212: } > 213: > 214: static const char* reference_type_to_string(ReferenceType rt) { This function seems misplaced here. Seems like it belongs with the ReferenceType type. (This could be a followup RFE.) src/hotspot/share/jfr/recorder/checkpoint/types/jfrType.cpp line 217: > 215: switch (rt) { > 216: case REF_NONE: return "None reference"; > 217: case REF_REFERENCE: return "j.l.r.Reference"; I think either "Reference" or "java.lang.ref.Reference" would be better than the abbreviation. src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/memory/ReferenceType.java line 31: > 29: public enum ReferenceType { > 30: REF_NONE ("None reference"), // Regular class > 31: REF_REFERENCE ("j.l.r.Reference"), // java/lang/ref/Reference, super class of the following Again here, don't abbreviate the package path. ------------- PR: https://git.openjdk.java.net/jdk/pull/8332 From jiefu at openjdk.java.net Thu Apr 21 11:19:27 2022 From: jiefu at openjdk.java.net (Jie Fu) Date: Thu, 21 Apr 2022 11:19:27 GMT Subject: RFR: 8285342: Zero build failure with clang due to values not handled in switch [v2] In-Reply-To: References: Message-ID: > Hi all, > > May I get reviews for this trivial change? > > It fixes zero build failure with clang due to values not handled in switch. > > Thanks. > Best regards, > Jie Jie Fu has updated the pull request incrementally with one additional commit since the last revision: Add ShouldNotReachHere() ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8330/files - new: https://git.openjdk.java.net/jdk/pull/8330/files/b5a67a50..eb739aa5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8330&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8330&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8330.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8330/head:pull/8330 PR: https://git.openjdk.java.net/jdk/pull/8330 From jiefu at openjdk.java.net Thu Apr 21 11:19:27 2022 From: jiefu at openjdk.java.net (Jie Fu) Date: Thu, 21 Apr 2022 11:19:27 GMT Subject: RFR: 8285342: Zero build failure with clang due to values not handled in switch [v2] In-Reply-To: References: Message-ID: On Thu, 21 Apr 2022 10:00:43 GMT, Aleksey Shipilev wrote: >> Jie Fu has updated the pull request incrementally with one additional commit since the last revision: >> >> Add ShouldNotReachHere() > > I think it should actually be `ShouldNotReachHere()`, and legitimate cases listed as explicit cases. Thanks @shipilev and @theRealAph for your review. Let's add `ShouldNotReachHere()` since zero seems to be more widely tested by release VMs. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/8330 From ayang at openjdk.java.net Thu Apr 21 11:30:20 2022 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Thu, 21 Apr 2022 11:30:20 GMT Subject: RFR: 8285364: Use more precise name for ReferenceType::REF_OTHER [v2] In-Reply-To: References: Message-ID: > Simple rename and some comments update. > > Test: build Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: review ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8332/files - new: https://git.openjdk.java.net/jdk/pull/8332/files/6423f0ad..746ff8e3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8332&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8332&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8332.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8332/head:pull/8332 PR: https://git.openjdk.java.net/jdk/pull/8332 From alanb at openjdk.java.net Thu Apr 21 11:35:57 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 21 Apr 2022 11:35:57 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v5] In-Reply-To: References: Message-ID: <3RNoPzJecSfEBdapZpbKMJZG1ep3mVUW1Z5kKNrFYSk=.821824df-3431-437a-b5c8-c4627021d349@github.com> > This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. > > We will refresh this PR periodically to pick up changes and fixes from the loom repo. > > Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. > > The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. > > There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. > > The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. > > The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: Refresh ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8166/files - new: https://git.openjdk.java.net/jdk/pull/8166/files/ff1ef712..5e202eca Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8166&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8166&range=03-04 Stats: 1827 lines in 289 files changed: 682 ins; 377 del; 768 mod Patch: https://git.openjdk.java.net/jdk/pull/8166.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8166/head:pull/8166 PR: https://git.openjdk.java.net/jdk/pull/8166 From alanb at openjdk.java.net Thu Apr 21 11:36:02 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 21 Apr 2022 11:36:02 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2] In-Reply-To: References: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com> Message-ID: On Fri, 15 Apr 2022 21:31:09 GMT, Paul Sandoz wrote: >> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: >> >> Refresh > > src/java.base/share/classes/jdk/internal/vm/Continuation.java line 264: > >> 262: } finally { >> 263: fence(); >> 264: StackChunk c = tail; > > `c` is not used Ron has done some cleanup so this is removed. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From alanb at openjdk.java.net Thu Apr 21 11:36:04 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 21 Apr 2022 11:36:04 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2] In-Reply-To: References: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com> Message-ID: On Sat, 16 Apr 2022 14:59:55 GMT, Alan Bateman wrote: >> src/java.base/share/classes/jdk/internal/vm/ThreadContainers.java line 184: >> >>> 182: * with the Thread API. >>> 183: */ >>> 184: private static class RootContainer extends ThreadContainer { >> >> This implementation could be clearer if split out into two, and the value assigned to `INSTANCE` is selected based on the system property. Something to consider later perhaps. > > We've been undecided on whether to just track all threads. If we do that then there would be only one implementation. But yes, if we continue with two then they should be split out. Done. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From alanb at openjdk.java.net Thu Apr 21 11:35:59 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 21 Apr 2022 11:35:59 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v4] In-Reply-To: References: <_TWRNeLakN4zFnF3jIC_2ezkgvSzl-9O5xtV7qI-NDA=.b07a1c1a-edc1-4078-b580-a065a28a7b1f@github.com> Message-ID: <-G75Xv0RAXFvZt1TM0JXiQk9R5YX_SPAUennszGlXMA=.fde68d79-9d39-417c-8bec-e21ec04df70d@github.com> On Tue, 19 Apr 2022 01:11:56 GMT, Mandy Chung wrote: >> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: >> >> Refresh > > src/java.base/share/classes/java/lang/System.java line 2173: > >> 2171: >> 2172: // start Finalizer and Reference Handler threads >> 2173: SharedSecrets.getJavaLangRefAccess().startThreads(); > > I think it would avoid any confusion if `VM.initLevel(1)` is the last step in `initPhase1`, i.e. call after this line. Previously, the finalizer starts very early and it has to wait until initLevel is set to level 1 which guarantees that `JavaLangAccess` is available. With this change, `JavaLangAccess` is already set. Yes, that would be best, just wasn't possible before now. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From stefank at openjdk.java.net Thu Apr 21 11:38:39 2022 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Thu, 21 Apr 2022 11:38:39 GMT Subject: RFR: 8285364: Use more precise name for ReferenceType::REF_OTHER [v2] In-Reply-To: References: Message-ID: On Thu, 21 Apr 2022 11:30:20 GMT, Albert Mingkun Yang wrote: >> Simple rename and some comments update. >> >> Test: build > > Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: > > review Do we even need REF_OTHER / REF_REFERENCE? I see a bunch of ShouldNotReachHeres and then set_reference_type(REF_OTHER). Maybe the latter could be changed to REF_NONE? ------------- PR: https://git.openjdk.java.net/jdk/pull/8332 From ayang at openjdk.java.net Thu Apr 21 11:47:28 2022 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Thu, 21 Apr 2022 11:47:28 GMT Subject: RFR: 8285364: Use more precise name for ReferenceType::REF_OTHER [v2] In-Reply-To: References: Message-ID: On Thu, 21 Apr 2022 11:36:35 GMT, Stefan Karlsson wrote: > Maybe the latter could be changed to REF_NONE? `vmClasses::Reference_klass()->set_reference_type(REF_NONE);` fails in `make images`. The relevant code is: ClassFileParser::post_process_parsed_stream(...) { ... _rt = (NULL ==_super_klass) ? REF_NONE : _super_klass->reference_type(); } InstanceKlass::allocate_instance_klass(...) { ... if (REF_NONE == parser.reference_type()) { ... } else { // reference ik = new (loader_data, size, THREAD) InstanceRefKlass(parser); } } The `else` branch is for non-strong refs and relies on the ref-type of their super klass not being `REF_NONE`. ------------- PR: https://git.openjdk.java.net/jdk/pull/8332 From stefank at openjdk.java.net Thu Apr 21 12:22:25 2022 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Thu, 21 Apr 2022 12:22:25 GMT Subject: RFR: 8285364: Use more precise name for ReferenceType::REF_OTHER [v2] In-Reply-To: References: Message-ID: On Thu, 21 Apr 2022 11:30:20 GMT, Albert Mingkun Yang wrote: >> Simple rename and some comments update. >> >> Test: build > > Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: > > review That's unfortunate. The allocate_instance_klass function can easily be changed to also check if class_name == vmSymbols::java_lang_ref_Reference(). But even with that, make images fails. I wasn't a fan of the REF_REFERENCE name, since it isn't really that descriptive to me, and had hoped to fine a way to just get rid of it instead of finding a better name. ------------- PR: https://git.openjdk.java.net/jdk/pull/8332 From lucy at openjdk.java.net Thu Apr 21 14:26:09 2022 From: lucy at openjdk.java.net (Lutz Schmidt) Date: Thu, 21 Apr 2022 14:26:09 GMT Subject: RFR: 8278757: [s390] Implement AES Counter Mode Intrinsic [v6] In-Reply-To: References: Message-ID: > Please review (and approve, if possible) this pull request. > > This is a s390-only enhancement. It introduces the implementation of an AES-CTR intrinsic, making use of the specific s390 instruction for AES counter-mode encryption. > > Testing: SAP does no longer maintain a full build and test environment for s390. Testing is therefore limited to running some test suites (SPECjbb*, SPECjvm*) manually. But: identical code is contained in SAP's commercial product and thoroughly tested in that context. No issues were uncovered. > > @backwaterred Could you please conduct some "official" testing for this PR? > > Thank you all! > > Note: some performance figures can be found in the JBS ticket. Lutz Schmidt has updated the pull request incrementally with two additional commits since the last revision: - Merge branch 'JDK-8278757' of ssh://github.com/RealLucy/jdk into JDK-8278757 Merge to bring local branch up-to-date - 8278757: honor review comments part 1 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8142/files - new: https://git.openjdk.java.net/jdk/pull/8142/files/7b40f945..a99a6fbe Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8142&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8142&range=04-05 Stats: 46 lines in 1 file changed: 7 ins; 25 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/8142.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8142/head:pull/8142 PR: https://git.openjdk.java.net/jdk/pull/8142 From ayang at openjdk.java.net Thu Apr 21 15:12:26 2022 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Thu, 21 Apr 2022 15:12:26 GMT Subject: RFR: 8285364: Use more precise name for ReferenceType::REF_OTHER [v2] In-Reply-To: References: Message-ID: <47QtF1Bs-x4E8CQ8KcJnU2zRu7RzC320Coe6nEOjqJc=.838f3840-656c-4a47-a664-0ab808e2c811@github.com> On Thu, 21 Apr 2022 12:19:20 GMT, Stefan Karlsson wrote: > had hoped to fine a way to just get rid of it instead of finding a better name. `vmClasses::Reference_klass()->set_reference_type(REF_SOFT);` works. In fact, anything other than `REF_NONE` works. The correct ref-type for each subclass of `Reference` will be set later on in `vmClasses::resolve_all`. Do you think that is better? ------------- PR: https://git.openjdk.java.net/jdk/pull/8332 From duke at openjdk.java.net Thu Apr 21 16:17:35 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Thu, 21 Apr 2022 16:17:35 GMT Subject: RFR: 8283643: [AIX, testbug] MachCodeFramesInErrorFile test fails to find 'Native frames' text [v5] In-Reply-To: References: Message-ID: On Wed, 20 Apr 2022 17:39:16 GMT, Tyler Steele wrote: >> I observed a failure of MachCodeFramesInErrorFile.java on AIX. The raised error complains that 'Native frames: ' is missing. To fix the failure, I made two changes to the test that allowed it to pass on AIX. >> >> The first change made was to the test's `extractFrames` method. AIX overrides `os::platform_print_native_stack` with stack printing specific to AIX/Power. This code does not produce the 'Native frames: ' text that `vmError::print_native_stack` does, so the test was modified to expect the AIX output when run on AIX. [Edit: The changes made to `extractFrames` are now minimal. I made the change to `AixNativeCallstack::print_callstack_for_context` instead.] >> >> A second change was made to the address passed to the `crashInNative1` method. AIX does not consider low-address memory to be protected as other platforms do. In fact, "the first 256 bytes are reserved for software use" according to the Power ISA. Accordingly, the read address for PPC was changed to -1 (0xFF..FF) to produce the expected failure result. >> >> ### Testing >> >> Tier1 tests complete as expected on AIX/Power. > > Tyler Steele has updated the pull request incrementally with two additional commits since the last revision: > > - Revert "Test: Sample error with no printing should print hs_err output" > > This reverts commit 6c70a45d862c1aa26d9c4d585bf8ecd39892e3bb. > - Adds logging to stdout/stderr to prevent too-long Exception messages. test/hotspot/jtreg/runtime/ErrorHandling/MachCodeFramesInErrorFile.java line 185: > 183: } > 184: } > 185: System.err.println(hsErr); It's a popular (and reasonable) [question](https://github.com/openjdk/jdk/pull/8094#discussion_r852787701) as to why I made the change to the exception reporting. This is the error that resulted from a too-long exception message. java.io.UTFDataFormatException: encoded string (`main' t....11 END.) too long: 116222 bytes at java.base/java.io.DataOutputStream.writeUTF(DataOutputStream.java:369) at java.base/java.io.DataOutputStream.writeUTF(DataOutputStream.java:333) at com.sun.javatest.regtest.agent.AgentServer.writeStatus(AgentServer.java:351) at com.sun.javatest.regtest.agent.AgentServer.doMain(AgentServer.java:307) at com.sun.javatest.regtest.agent.AgentServer.run(AgentServer.java:233) at com.sun.javatest.regtest.agent.AgentServer.main(AgentServer.java:70) This error hampered my ability to debug this test. It's not very clear from the message as to where it's coming from, and it occurs sporadically depending on the length of the message produced. I eventually traced it to the line: `throw new RuntimeException(""" + marker + "" line missing in hs_err_pid file:\n" + hsErr);`. To trigger the error for this comment, I changed `hsErr` to `hsErr + hsErr`. This issue may be platform specific, or the issue just isn't encountered very often because it's uncommon to add > 64KiB Strings to an Exception. Either way, making this change made the test failures much easier to diagnose. ------------- PR: https://git.openjdk.java.net/jdk/pull/8094 From shade at openjdk.java.net Thu Apr 21 16:31:29 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 21 Apr 2022 16:31:29 GMT Subject: RFR: 8285342: Zero build failure with clang due to values not handled in switch [v2] In-Reply-To: References: Message-ID: On Thu, 21 Apr 2022 11:19:27 GMT, Jie Fu wrote: >> Hi all, >> >> May I get reviews for this trivial change? >> >> It fixes zero build failure with clang due to values not handled in switch. >> >> Thanks. >> Best regards, >> Jie > > Jie Fu has updated the pull request incrementally with one additional commit since the last revision: > > Add ShouldNotReachHere() Looks fine. Please run `make bootcycle-images` on some Zero config, to test that we never actually hit the `ShouldNotReachHere`? ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8330 From kvn at openjdk.java.net Thu Apr 21 16:32:37 2022 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Thu, 21 Apr 2022 16:32:37 GMT Subject: RFR: 8242440: use separate, destroyable JavaVM instances per libgraal compiler thread [v3] In-Reply-To: References: Message-ID: On Thu, 21 Apr 2022 07:24:11 GMT, Doug Simon wrote: >> src/hotspot/share/jvmci/jvmciCompiler.cpp line 172: >> >>> 170: // Don't detach JVMCI compiler threads from their JVMCI >>> 171: // runtime during the VM startup grace period >>> 172: if (runtime != nullptr && delay > 0 && tty->time_stamp().milliseconds() > DEFAULT_COMPILER_IDLE_DELAY) { >> >> Can it be more coordinated by some status instead of time? Time depends on machine you run and does not guarantee right case. I could be done in separate changes. > > This check exists only to avoid adding extra overhead of creating and destroying libgraal runtimes during early VM execution for very short lived apps (i.e. less than 1000 ms). After that, normal libgraal runtime management should not be a problem. In combination with [lazy allocation of compiler threads](https://bugs.openjdk.java.net/browse/JDK-8198756), it's very rare in practice for a compiler thread to want to shutdown anyway during the first 1000 ms of VM execution. Thank you for explanation. ------------- PR: https://git.openjdk.java.net/jdk/pull/8262 From aph at openjdk.java.net Thu Apr 21 16:36:29 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Thu, 21 Apr 2022 16:36:29 GMT Subject: RFR: 8285342: Zero build failure with clang due to values not handled in switch [v2] In-Reply-To: References: Message-ID: On Thu, 21 Apr 2022 11:19:27 GMT, Jie Fu wrote: >> Hi all, >> >> May I get reviews for this trivial change? >> >> It fixes zero build failure with clang due to values not handled in switch. >> >> Thanks. >> Best regards, >> Jie > > Jie Fu has updated the pull request incrementally with one additional commit since the last revision: > > Add ShouldNotReachHere() Marked as reviewed by aph (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8330 From aph at openjdk.java.net Thu Apr 21 16:36:29 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Thu, 21 Apr 2022 16:36:29 GMT Subject: RFR: 8285342: Zero build failure with clang due to values not handled in switch [v2] In-Reply-To: References: Message-ID: <98xdbrHgPvJb1gQBACC8Pihtq6p4XPcjPJ4jJEyp2tg=.d1f159b5-a372-4848-ac5b-882a57f40f26@github.com> On Thu, 21 Apr 2022 11:09:23 GMT, Jie Fu wrote: >> src/hotspot/cpu/zero/zeroInterpreter_zero.cpp line 623: >> >>> 621: break; >>> 622: default: >>> 623: ; >> >> `ShouldNotReachHere()` ? Maybe an `assert()` ? > >> `ShouldNotReachHere()` ? Maybe an `assert()` ? > > We should not add `ShouldNotReachHere()` or `assert()` here. > This is because the `entry->flag_state()` may be `itos/ftos...`. > The logic is only add one more slot for long/double. > So just do nothing here. Eww, OK. ------------- PR: https://git.openjdk.java.net/jdk/pull/8330 From duke at openjdk.java.net Thu Apr 21 16:44:36 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Thu, 21 Apr 2022 16:44:36 GMT Subject: RFR: 8283643: [AIX, testbug] MachCodeFramesInErrorFile test fails to find 'Native frames' text [v5] In-Reply-To: References: Message-ID: On Wed, 20 Apr 2022 19:09:15 GMT, Doug Simon wrote: >> Tyler Steele has updated the pull request incrementally with two additional commits since the last revision: >> >> - Revert "Test: Sample error with no printing should print hs_err output" >> >> This reverts commit 6c70a45d862c1aa26d9c4d585bf8ecd39892e3bb. >> - Adds logging to stdout/stderr to prevent too-long Exception messages. > > test/hotspot/jtreg/runtime/ErrorHandling/MachCodeFramesInErrorFile.java line 133: > >> 131: System.out.println("stdout:\n" + output.getStdout()); >> 132: System.err.println("stderr:\n" + output.getStderr()); >> 133: throw new RuntimeException("Did not find hs_err_pid file in output"); > > Why this change (and a similar one at the end of the file)? This separates the reporting of a failed condition (i.e., could not find expected patten in output) from the context (i.e. contents of stderr and stdout) that assists in diagnosing why the condition may have failed. @dougxc, I added [an explanation](https://github.com/openjdk/jdk/pull/8094/files#r855362995) to the similar change at the end of the file. That was the one I discovered first. Here I made a similar change to prevent the same issue from occurring. @dholmes-ora, I don't think output.shouldMatch is the best choice here because it involves doing the same operation twice. I believe I would end up looking for the pattern and throwing an error with shouldMatch, then looking for the pattern again and returning the String with firstMatch. I do like your idea of using more standard code however. I would like to replace the calls to println with `output.reportDiagnosticSummary()` if that is a reasonable compromise to your suggestion? ------------- PR: https://git.openjdk.java.net/jdk/pull/8094 From jiefu at openjdk.java.net Thu Apr 21 23:49:28 2022 From: jiefu at openjdk.java.net (Jie Fu) Date: Thu, 21 Apr 2022 23:49:28 GMT Subject: RFR: 8285342: Zero build failure with clang due to values not handled in switch [v2] In-Reply-To: References: Message-ID: On Thu, 21 Apr 2022 16:28:16 GMT, Aleksey Shipilev wrote: > Looks fine. Please run `make bootcycle-images` on some Zero config, to test that we never actually hit the `ShouldNotReachHere`? `make bootcycle-images` passed on MacOS. So let's integrate it. ------------- PR: https://git.openjdk.java.net/jdk/pull/8330 From jiefu at openjdk.java.net Thu Apr 21 23:49:28 2022 From: jiefu at openjdk.java.net (Jie Fu) Date: Thu, 21 Apr 2022 23:49:28 GMT Subject: Integrated: 8285342: Zero build failure with clang due to values not handled in switch In-Reply-To: References: Message-ID: On Thu, 21 Apr 2022 09:42:36 GMT, Jie Fu wrote: > Hi all, > > May I get reviews for this trivial change? > > It fixes zero build failure with clang due to values not handled in switch. > > Thanks. > Best regards, > Jie This pull request has now been integrated. Changeset: d84b9c54 Author: Jie Fu URL: https://git.openjdk.java.net/jdk/commit/d84b9c54893dd33686d49755fca7a4b7f6a681c4 Stats: 4 lines in 2 files changed: 4 ins; 0 del; 0 mod 8285342: Zero build failure with clang due to values not handled in switch Reviewed-by: shade, aph ------------- PR: https://git.openjdk.java.net/jdk/pull/8330 From fjiang at openjdk.java.net Fri Apr 22 02:11:48 2022 From: fjiang at openjdk.java.net (Feilong Jiang) Date: Fri, 22 Apr 2022 02:11:48 GMT Subject: RFR: 8285303: riscv: Incorrect register mask in call_native_base Message-ID: <4cVLgyZuTzCDWf8f7cEK8T3OjSYKgx3iABJwI7UD0ac=.5a60df1c-ad23-46ae-97c0-d377ce0bed12@github.com> In `MacroAssembler::call_native_base`, t0 and xmethod should be saved as expected: void MacroAssembler::call_native_base(address entry_point, Label *retaddr) { Label E, L; int32_t offset = 0; push_reg(0x80000040, sp); // push << t0 & xmethod >> to sp movptr_with_offset(t0, entry_point, offset); jalr(x1, t0, offset); if (retaddr != NULL) { bind(*retaddr); } pop_reg(0x80000040, sp); // pop << t0 & xmethod >> from sp } Register mask of '0x80000040' operates << t1 & xmethod >> here, which should be '0x80000020' for << t0 & xmethod >>. This PR also removes `MacroAssembler::call_native_base` and `MacroAssembler::call_native_base`, expands the definitions of `call_native_base` to `MacroAssembler::call_VM_leaf_base` directly. Linux RISCV64 release hotspot/jdk tier1 tests are passed on QEMU. ------------- Commit messages: - fix incorrect reg mask of call_VM_leaf_base Changes: https://git.openjdk.java.net/jdk/pull/8353/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8353&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8285303 Stats: 19 lines in 2 files changed: 0 ins; 17 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8353.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8353/head:pull/8353 PR: https://git.openjdk.java.net/jdk/pull/8353 From duke at openjdk.java.net Fri Apr 22 02:41:28 2022 From: duke at openjdk.java.net (ExE Boss) Date: Fri, 22 Apr 2022 02:41:28 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v5] In-Reply-To: <3RNoPzJecSfEBdapZpbKMJZG1ep3mVUW1Z5kKNrFYSk=.821824df-3431-437a-b5c8-c4627021d349@github.com> References: <3RNoPzJecSfEBdapZpbKMJZG1ep3mVUW1Z5kKNrFYSk=.821824df-3431-437a-b5c8-c4627021d349@github.com> Message-ID: On Thu, 21 Apr 2022 11:35:57 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh src/java.base/share/classes/java/lang/ThreadLocal.java line 179: > 177: private T get(Thread t) { > 178: ThreadLocalMap map = getMap(t); > 179: if (map != null && map != ThreadLocalMap.NOT_SUPPORTED) { Due?to the?way `setInitialValue` is?implemented, `getMap(t)` will?currently be?called?twice when?`ThreadLocal`s are?disabled. -------------------------------------------------------------------------------- This?method should?probably be?changed so?that?when `map?==?ThreadLocalMap.NOT_SUPPORTED`, it?simply?does: return initialValue(); -------------------------------------------------------------------------------- Suggestion: if (map != null) { if (map == ThreadLocalMap.NOT_SUPPORTED) { return initialValue(); } src/java.base/share/classes/java/lang/ThreadLocal.java line 423: > 421: * Construct a new map without a table. > 422: */ > 423: ThreadLocalMap() { It?might be?possible for?this to?be?`private`: Suggestion: private ThreadLocalMap() { ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From yyang at openjdk.java.net Fri Apr 22 02:55:28 2022 From: yyang at openjdk.java.net (Yi Yang) Date: Fri, 22 Apr 2022 02:55:28 GMT Subject: RFR: 8284877: Check type compatibility before looking up method from receiver's vtable [v2] In-Reply-To: References: Message-ID: On Thu, 21 Apr 2022 06:04:27 GMT, Yi Yang wrote: >> Hi, can I have a review for this enhancement? This patch adds type compatibility check before method lookup for robustness. In some internal cases, serialization framework may improperly generate an object of wrong type, which leads JVM randomly crashes during method resolution. >> >> For example: >> >> invokevirtual selected method: receiver-class:java.util.ArrayList, resolved-class:com.taobao.forest.domain.util.LongMapSupportArrayList, resolved_method:com.taobao.forest.domain.util.LongMapSupportArrayList.toMap()Ljava/util/Map;, selected_method:0x458, vtable_index:56# >> >> The real type of receiver is ArrayList, while the resolved method is LongMapSupportArrayList.toMap. VM attempts to select method as if looking up from receiver's vtable via vtable index of resolved method(i.e. attempts to lookup `toMap()` from >> ArrayList), an invalid method or incorrect method would be selected, thus causing some strange crashes. >> >> I think it's reasonable to add a type compatibility check before method lookup. If such an incompatible call is found, JVM could throw an exception instead. > > Yi Yang has updated the pull request incrementally with one additional commit since the last revision: > > add jtreg test Okay. It is acceptable for me to accept or not. Acceptable: More VM robustness, as we don't have receiver checks from interpreter->LinkResolver according to crash stack. Unacceptable: Yes, it's undefined behavior when incorrectly using Unsafe. ------------- PR: https://git.openjdk.java.net/jdk/pull/8241 From yyang at openjdk.java.net Fri Apr 22 02:55:28 2022 From: yyang at openjdk.java.net (Yi Yang) Date: Fri, 22 Apr 2022 02:55:28 GMT Subject: Withdrawn: 8284877: Check type compatibility before looking up method from receiver's vtable In-Reply-To: References: Message-ID: On Thu, 14 Apr 2022 10:40:21 GMT, Yi Yang wrote: > Hi, can I have a review for this enhancement? This patch adds type compatibility check before method lookup for robustness. In some internal cases, serialization framework may improperly generate an object of wrong type, which leads JVM randomly crashes during method resolution. > > For example: > > invokevirtual selected method: receiver-class:java.util.ArrayList, resolved-class:com.taobao.forest.domain.util.LongMapSupportArrayList, resolved_method:com.taobao.forest.domain.util.LongMapSupportArrayList.toMap()Ljava/util/Map;, selected_method:0x458, vtable_index:56# > > The real type of receiver is ArrayList, while the resolved method is LongMapSupportArrayList.toMap. VM attempts to select method as if looking up from receiver's vtable via vtable index of resolved method(i.e. attempts to lookup `toMap()` from > ArrayList), an invalid method or incorrect method would be selected, thus causing some strange crashes. > > I think it's reasonable to add a type compatibility check before method lookup. If such an incompatible call is found, JVM could throw an exception instead. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/8241 From fyang at openjdk.java.net Fri Apr 22 03:13:24 2022 From: fyang at openjdk.java.net (Fei Yang) Date: Fri, 22 Apr 2022 03:13:24 GMT Subject: RFR: 8285303: riscv: Incorrect register mask in call_native_base In-Reply-To: <4cVLgyZuTzCDWf8f7cEK8T3OjSYKgx3iABJwI7UD0ac=.5a60df1c-ad23-46ae-97c0-d377ce0bed12@github.com> References: <4cVLgyZuTzCDWf8f7cEK8T3OjSYKgx3iABJwI7UD0ac=.5a60df1c-ad23-46ae-97c0-d377ce0bed12@github.com> Message-ID: On Fri, 22 Apr 2022 02:02:01 GMT, Feilong Jiang wrote: > In `MacroAssembler::call_native_base`, t0 and xmethod should be saved as expected: > > > void MacroAssembler::call_native_base(address entry_point, Label *retaddr) { > Label E, L; > int32_t offset = 0; > push_reg(0x80000040, sp); // push << t0 & xmethod >> to sp > movptr_with_offset(t0, entry_point, offset); > jalr(x1, t0, offset); > if (retaddr != NULL) { > bind(*retaddr); > } > pop_reg(0x80000040, sp); // pop << t0 & xmethod >> from sp > } > > > Register mask of '0x80000040' operates << t1 & xmethod >> here, which should be '0x80000020' for << t0 & xmethod >>. > > This PR also removes `MacroAssembler::call_native_base` and `MacroAssembler::call_native_base`, expands the definitions of `call_native_base` to `MacroAssembler::call_VM_leaf_base` directly. > > Linux RISCV64 release hotspot/jdk tier1 tests are passed on QEMU. Thanks for fixing this typo. I think register t0 is not alive at the callsites so it's never triggered. ------------- Marked as reviewed by fyang (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8353 From yadongwang at openjdk.java.net Fri Apr 22 03:18:25 2022 From: yadongwang at openjdk.java.net (Yadong Wang) Date: Fri, 22 Apr 2022 03:18:25 GMT Subject: RFR: 8285303: riscv: Incorrect register mask in call_native_base In-Reply-To: <4cVLgyZuTzCDWf8f7cEK8T3OjSYKgx3iABJwI7UD0ac=.5a60df1c-ad23-46ae-97c0-d377ce0bed12@github.com> References: <4cVLgyZuTzCDWf8f7cEK8T3OjSYKgx3iABJwI7UD0ac=.5a60df1c-ad23-46ae-97c0-d377ce0bed12@github.com> Message-ID: On Fri, 22 Apr 2022 02:02:01 GMT, Feilong Jiang wrote: > In `MacroAssembler::call_native_base`, t0 and xmethod should be saved as expected: > > > void MacroAssembler::call_native_base(address entry_point, Label *retaddr) { > Label E, L; > int32_t offset = 0; > push_reg(0x80000040, sp); // push << t0 & xmethod >> to sp > movptr_with_offset(t0, entry_point, offset); > jalr(x1, t0, offset); > if (retaddr != NULL) { > bind(*retaddr); > } > pop_reg(0x80000040, sp); // pop << t0 & xmethod >> from sp > } > > > Register mask of '0x80000040' operates << t1 & xmethod >> here, which should be '0x80000020' for << t0 & xmethod >>. > > This PR also removes `MacroAssembler::call_native_base` and `MacroAssembler::call_native_base`, expands the definitions of `call_native_base` to `MacroAssembler::call_VM_leaf_base` directly. > > Linux RISCV64 release hotspot/jdk tier1 tests are passed on QEMU. lgtm ------------- Marked as reviewed by yadongwang (Author). PR: https://git.openjdk.java.net/jdk/pull/8353 From kbarrett at openjdk.java.net Fri Apr 22 05:23:27 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Fri, 22 Apr 2022 05:23:27 GMT Subject: RFR: 8242440: use separate, destroyable JavaVM instances per libgraal compiler thread [v3] In-Reply-To: References: Message-ID: On Tue, 19 Apr 2022 10:17:14 GMT, Doug Simon wrote: >> Currently, libgraal runs in a single, permanent JavaVM instance loaded from libjvmcicompiler.so. This poses 2 problems: >> >> 1. The memory used for libgraal is never released, even when the libgraal compiler queues are idle. >> 2. Since all libgraal HotSpot compiler threads share the same SVM heap, libgraal compilation is effectively paused when a GC occurs (SVM currently has a stop the world collector). The more compiler threads there are, the more often this happens. >> >> This PR implements the following solution to these problems: >> 1. Create a new JavaVM instance per libgraal compiler thread (i.e. a separate SVM isolate per thread). This prevents GC in one libgraal thread from impacting another libgraal thread. >> 2. Destroy the JavaVM instances when a libgraal compiler thread becomes idle and create a new one when subsequent compilation requests arrive. >> >> Most of the changes are in JVMCI specific files. The most significant change to shared code is the addition of the `JavaThread:: _libjvmci_runtime` field. This is required as any thread (not just a `CompilerThread`) can be associated with a specific `JVMCIRuntime` object. > > Doug Simon has updated the pull request incrementally with one additional commit since the last revision: > > removed (incorrect) volatile modifier from JVMCIRuntime::_shared_library_javavm One more possible improvement suggestion. As I said before, I've only reviewed the runtime parts (which looks okay), and just skimmed the rest. So don't count me as the required 2nd reviewer. src/hotspot/share/jvmci/jvmciRuntime.cpp line 895: > 893: ResourceMark rm; > 894: oop** ptrs = NEW_RESOURCE_ARRAY(oop*, _oop_handles.length()); > 895: for (int i = 0; i < _oop_handles.length(); i++) { Now that _oop_handles is a vector of `oop*`, the resource allocation and possibly some copying could be avoided. Do an in-place removal of nullptr and clearing of the values pass over the vector, and then use object_handles()->release(_oop_handles.at_ptr(0), _oop_handles.length()) For future, I wonder if it would be worth changing OopStorage bulk release to ignore nullptrs in the array, to better support this kind of use-case. But I'm not sure how common this kind of use-case (array of handles, some of which might be nullptr) really might be. I think there are only a couple uses of bulk release so far. ------------- PR: https://git.openjdk.java.net/jdk/pull/8262 From xgong at openjdk.java.net Fri Apr 22 07:08:24 2022 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Fri, 22 Apr 2022 07:08:24 GMT Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE with predicate feature [v2] In-Reply-To: References: Message-ID: > Currently the vector load with mask when the given index happens out of the array boundary is implemented with pure java scalar code to avoid the IOOBE (IndexOutOfBoundaryException). This is necessary for architectures that do not support the predicate feature. Because the masked load is implemented with a full vector load and a vector blend applied on it. And a full vector load will definitely cause the IOOBE which is not valid. However, for architectures that support the predicate feature like SVE/AVX-512/RVV, it can be vectorized with the predicated load instruction as long as the indexes of the masked lanes are within the bounds of the array. For these architectures, loading with unmasked lanes does not raise exception. > > This patch adds the vectorization support for the masked load with IOOBE part. Please see the original java implementation (FIXME: optimize): > > > @ForceInline > public static > ByteVector fromArray(VectorSpecies species, > byte[] a, int offset, > VectorMask m) { > ByteSpecies vsp = (ByteSpecies) species; > if (offset >= 0 && offset <= (a.length - species.length())) { > return vsp.dummyVector().fromArray0(a, offset, m); > } > > // FIXME: optimize > checkMaskFromIndexSize(offset, vsp, m, 1, a.length); > return vsp.vOp(m, i -> a[offset + i]); > } > > Since it can only be vectorized with the predicate load, the hotspot must check whether the current backend supports it and falls back to the java scalar version if not. This is different from the normal masked vector load that the compiler will generate a full vector load and a vector blend if the predicate load is not supported. So to let the compiler make the expected action, an additional flag (i.e. `usePred`) is added to the existing "loadMasked" intrinsic, with the value "true" for the IOOBE part while "false" for the normal load. And the compiler will fail to intrinsify if the flag is "true" and the predicate load is not supported by the backend, which means that normal java path will be executed. > > Also adds the same vectorization support for masked: > - fromByteArray/fromByteBuffer > - fromBooleanArray > - fromCharArray > > The performance for the new added benchmarks improve about `1.88x ~ 30.26x` on the x86 AVX-512 system: > > Benchmark before After Units > LoadMaskedIOOBEBenchmark.byteLoadArrayMaskIOOBE 737.542 1387.069 ops/ms > LoadMaskedIOOBEBenchmark.doubleLoadArrayMaskIOOBE 118.366 330.776 ops/ms > LoadMaskedIOOBEBenchmark.floatLoadArrayMaskIOOBE 233.832 6125.026 ops/ms > LoadMaskedIOOBEBenchmark.intLoadArrayMaskIOOBE 233.816 7075.923 ops/ms > LoadMaskedIOOBEBenchmark.longLoadArrayMaskIOOBE 119.771 330.587 ops/ms > LoadMaskedIOOBEBenchmark.shortLoadArrayMaskIOOBE 431.961 939.301 ops/ms > > Similar performance gain can also be observed on 512-bit SVE system. Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision: Rename the "usePred" to "offsetInRange" ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8035/files - new: https://git.openjdk.java.net/jdk/pull/8035/files/8f9e8a3c..9b2d2f19 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8035&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8035&range=00-01 Stats: 393 lines in 41 files changed: 0 ins; 0 del; 393 mod Patch: https://git.openjdk.java.net/jdk/pull/8035.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8035/head:pull/8035 PR: https://git.openjdk.java.net/jdk/pull/8035 From xgong at openjdk.java.net Fri Apr 22 07:12:28 2022 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Fri, 22 Apr 2022 07:12:28 GMT Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE with predicate feature [v2] In-Reply-To: References: Message-ID: On Wed, 20 Apr 2022 02:46:09 GMT, Xiaohong Gong wrote: >> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java line 2861: >> >>> 2859: ByteSpecies vsp = (ByteSpecies) species; >>> 2860: if (offset >= 0 && offset <= (a.length - species.vectorByteSize())) { >>> 2861: return vsp.dummyVector().fromByteArray0(a, offset, m, /* usePred */ false).maybeSwap(bo); >> >> Instead of usePred a term like inRange or offetInRage or offsetInVectorRange would be easier to follow. > > Thanks for the review. I will change it later. The name is updated to `offsetInRange`. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/8035 From xlinzheng at openjdk.java.net Fri Apr 22 07:34:10 2022 From: xlinzheng at openjdk.java.net (Xiaolin Zheng) Date: Fri, 22 Apr 2022 07:34:10 GMT Subject: RFR: 8285437: riscv: Fix MachNode size mismatch for MacroAssembler::verify_oops* Message-ID: Trivial and same as [JDK-8283737](https://bugs.openjdk.java.net/browse/JDK-8283737): in fastdebug build, MacroAssembler::verify_oop is used in match rules encodeHeapOop and decodeHeapOop, which also requires a fixed length. Logs are inside the JBS issue, and this issue could be reproduced by using `-XX:+VerifyOops`. Tested using `-XX:+VerifyOops` a hotspot tier1 on qemu. Thanks, Xiaolin ------------- Commit messages: - Fix again: MachNode size mismatch Changes: https://git.openjdk.java.net/jdk/pull/8356/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8356&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8285437 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8356.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8356/head:pull/8356 PR: https://git.openjdk.java.net/jdk/pull/8356 From xlinzheng at openjdk.java.net Fri Apr 22 07:42:03 2022 From: xlinzheng at openjdk.java.net (Xiaolin Zheng) Date: Fri, 22 Apr 2022 07:42:03 GMT Subject: RFR: 8285436: riscv: Fix broken MacroAssembler::debug64 Message-ID: <0HvPSOlWnK-s0XLEnPnPJ9FUnFY-g06EVTdGX82k3FQ=.927d47af-ab0a-4488-8268-dd8169ff0658@github.com> `MacroAssembler::stop()`[1] and `StubGenerator::generate_verify_oop()`[2] would first push all regs (calling `MacroAssembler::pusha()`[3]) onto the stack and then call `MacroAssembler::debug64()`[4] to print the pushed regs. But `MacroAssembler::pusha()`[3] won't push x0~x4 so the result of `MacroAssembler::debug64()` is broken. Tested by manually adding a `__ verify_oop(x1)` and option `-XX:+VerifyOops -XX:+ShowMessageBoxOnError` to deliberately crash the VM to make sure the new result matches the fact. Also a hotspot tier1. [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/riscv/macroAssembler_riscv.cpp#L533 [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/riscv/stubGenerator_riscv.cpp#L581 [3] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/riscv/macroAssembler_riscv.cpp#L1126-L1130 [4] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/riscv/macroAssembler_riscv.cpp#L473-L503 Thanks, Xiaolin ------------- Commit messages: - Fix: broken MacroAssembler::debug64 Changes: https://git.openjdk.java.net/jdk/pull/8357/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8357&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8285436 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8357.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8357/head:pull/8357 PR: https://git.openjdk.java.net/jdk/pull/8357 From xlinzheng at openjdk.java.net Fri Apr 22 07:49:01 2022 From: xlinzheng at openjdk.java.net (Xiaolin Zheng) Date: Fri, 22 Apr 2022 07:49:01 GMT Subject: RFR: 8285435: Show file and line in MacroAssembler::verify_oop for AArch64 and RISC-V platforms (Port from x86) Message-ID: <4Y-IZhHKc1Ojv5z4H6VeCom5h7_jLl_MREZwlLp3x04=.f5fb1c7f-f950-476b-a86e-06a49f9db386@github.com> Hi team, Could I have a review of this patch? This patch ports useful [JDK-8239492](https://bugs.openjdk.java.net/browse/JDK-8239492) and [JDK-8255900](https://bugs.openjdk.java.net/browse/JDK-8255900) to AArch64 and RISC-V platforms, to show exact files and lines when `verify_oop` fails. It is very useful for debugging broken oops. Add one `__ verify_oops()` in `aarch64.ad` and `riscv.ad` to deliberately crash the VM to see the result: Before: build/linux-aarch64-server-slowdebug/images/jdk/bin/java -XX:+VerifyOops -jar demo-0.0.1-SNAPSHOT.jar ...... # Internal Error (/home/yunyao.zxl/jdk/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp:2553), pid=420, tid=425 # fatal error: DEBUG MESSAGE: verify_oop: c_rarg1: broken oop After: build/linux-aarch64-server-slowdebug/images/jdk/bin/java -XX:+VerifyOops -jar demo-0.0.1-SNAPSHOT.jar ... # Internal Error (/home/yunyao.zxl/jdk/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp:2553), pid=420, tid=425 # fatal error: DEBUG MESSAGE: verify_oop: c_rarg1: broken oop r1 (/home/yunyao.zxl/jdk/src/hotspot/cpu/aarch64/aarch64.ad:1907) Tested AArch64 hotspot jtreg tier1, and RISCV tier1 is running. Thanks, Xiaolin ------------- Commit messages: - Print files and lines in verify_oops* Changes: https://git.openjdk.java.net/jdk/pull/8359/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8359&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8285435 Stats: 67 lines in 12 files changed: 33 ins; 0 del; 34 mod Patch: https://git.openjdk.java.net/jdk/pull/8359.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8359/head:pull/8359 PR: https://git.openjdk.java.net/jdk/pull/8359 From stefank at openjdk.java.net Fri Apr 22 08:07:29 2022 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Fri, 22 Apr 2022 08:07:29 GMT Subject: RFR: 8285364: Use more precise name for ReferenceType::REF_OTHER [v2] In-Reply-To: References: Message-ID: On Thu, 21 Apr 2022 11:30:20 GMT, Albert Mingkun Yang wrote: >> Simple rename and some comments update. >> >> Test: build > > Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: > > review Using REF_SOFT seems too hacky. If we rewrite the initialization a bit we can make this work. See suggested change in: https://github.com/stefank/jdk/tree/ref-rename https://github.com/stefank/jdk/commit/68161ce45de7d35b81f9cd6414e1e4cdf0c07665 ------------- PR: https://git.openjdk.java.net/jdk/pull/8332 From ayang at openjdk.java.net Fri Apr 22 08:26:26 2022 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Fri, 22 Apr 2022 08:26:26 GMT Subject: RFR: 8285364: Use more precise name for ReferenceType::REF_OTHER [v2] In-Reply-To: References: Message-ID: On Fri, 22 Apr 2022 08:03:42 GMT, Stefan Karlsson wrote: > Using REF_SOFT seems too hacky. Just to put all alternatives on the table. The use of `REF_SOFT` is ephemeral. // in vmClasses::resolve_all vmClasses::Reference_klass()->set_reference_type(REF_SOFT); // setting ref-type of Soft/Weak/Final/Phantom vmClasses::SoftReference_klass()->set_reference_type(REF_SOFT); ... vmClasses::Reference_klass()->set_reference_type(REF_NONE); I have no particular preference. What does everyone think? ------------- PR: https://git.openjdk.java.net/jdk/pull/8332 From rpressler at openjdk.java.net Fri Apr 22 08:49:46 2022 From: rpressler at openjdk.java.net (Ron Pressler) Date: Fri, 22 Apr 2022 08:49:46 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v3] In-Reply-To: References: Message-ID: On Sun, 17 Apr 2022 04:57:34 GMT, Jaikiran Pai wrote: >> Alan Bateman 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 five additional commits since the last revision: >> >> - Refresh >> - Refresh >> - Merge with jdk-19+18 >> - Refresh >> - Initial push > > src/java.base/share/classes/java/lang/StackTraceElement.java line 556: > >> 554: } >> 555: >> 556: static StackTraceElement[] of(StackTraceElement[] stackTrace) { > > Is it intentional that this method is returning a `StackTraceElement[]` instead of `void`. The current implementation just returns back the passed array after operating on each element. Are callers mandated to use the returned array for subsequent operations instead of the passed array? It's just for convenience of use. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From kbarrett at openjdk.java.net Fri Apr 22 09:08:25 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Fri, 22 Apr 2022 09:08:25 GMT Subject: RFR: 8285364: Use more precise name for ReferenceType::REF_OTHER [v2] In-Reply-To: References: Message-ID: On Thu, 21 Apr 2022 11:30:20 GMT, Albert Mingkun Yang wrote: >> Simple rename and some comments update. >> >> Test: build > > Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: > > review > > Using REF_SOFT seems too hacky. > > Just to put all alternatives on the table. The use of `REF_SOFT` is ephemeral. > > [...] > I have no particular preference. What does everyone think? I also think using REF_SOFT like that is overly hacky. I think there is still a bootstrapping weirdness, whether using REF_REFERENCE or using Stefan's approach. I think Soft/Weak/Final/PhantomReference_klass get constructed with the reftype of Reference_klass (whatever that is), and then have it later updated to the correct value. In that respect REF_OTHER seems better than REF_REFERENCE. So I no longer like the renaming. Getting rid of it entirely with Stefan's approach, they get REF_NONE initially and then set to the proper value; that's far from the worst bootstrapping kludge I've ever seen. ------------- PR: https://git.openjdk.java.net/jdk/pull/8332 From ayang at openjdk.java.net Fri Apr 22 09:43:45 2022 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Fri, 22 Apr 2022 09:43:45 GMT Subject: RFR: 8285364: Use more precise name for ReferenceType::REF_OTHER [v3] In-Reply-To: References: Message-ID: > Simple rename and some comments update. > > Test: build Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: Remove REF_ enum for java.lang.ref.Reference Signed-off-by: Albert Yang ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8332/files - new: https://git.openjdk.java.net/jdk/pull/8332/files/746ff8e3..73f80ea4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8332&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8332&range=01-02 Stats: 58 lines in 11 files changed: 28 ins; 24 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/8332.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8332/head:pull/8332 PR: https://git.openjdk.java.net/jdk/pull/8332 From ayang at openjdk.java.net Fri Apr 22 09:44:48 2022 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Fri, 22 Apr 2022 09:44:48 GMT Subject: RFR: 8285364: Remove REF_ enum for java.lang.ref.Reference [v2] In-Reply-To: References: Message-ID: On Thu, 21 Apr 2022 11:30:20 GMT, Albert Mingkun Yang wrote: >> Simple rename and some comments update. >> >> Test: build > > Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: > > review I have taken the commit from Stefan and updated the title. ------------- PR: https://git.openjdk.java.net/jdk/pull/8332 From dnsimon at openjdk.java.net Fri Apr 22 10:08:20 2022 From: dnsimon at openjdk.java.net (Doug Simon) Date: Fri, 22 Apr 2022 10:08:20 GMT Subject: RFR: 8242440: use separate, destroyable JavaVM instances per libgraal compiler thread [v4] In-Reply-To: References: Message-ID: > Currently, libgraal runs in a single, permanent JavaVM instance loaded from libjvmcicompiler.so. This poses 2 problems: > > 1. The memory used for libgraal is never released, even when the libgraal compiler queues are idle. > 2. Since all libgraal HotSpot compiler threads share the same SVM heap, libgraal compilation is effectively paused when a GC occurs (SVM currently has a stop the world collector). The more compiler threads there are, the more often this happens. > > This PR implements the following solution to these problems: > 1. Create a new JavaVM instance per libgraal compiler thread (i.e. a separate SVM isolate per thread). This prevents GC in one libgraal thread from impacting another libgraal thread. > 2. Destroy the JavaVM instances when a libgraal compiler thread becomes idle and create a new one when subsequent compilation requests arrive. > > Most of the changes are in JVMCI specific files. The most significant change to shared code is the addition of the `JavaThread:: _libjvmci_runtime` field. This is required as any thread (not just a `CompilerThread`) can be associated with a specific `JVMCIRuntime` object. Doug Simon has updated the pull request incrementally with one additional commit since the last revision: avoid resource allocation in JVMCIRuntime::release_and_clear_globals ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8262/files - new: https://git.openjdk.java.net/jdk/pull/8262/files/8aacbbaa..385880c2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8262&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8262&range=02-03 Stats: 9 lines in 1 file changed: 3 ins; 2 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/8262.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8262/head:pull/8262 PR: https://git.openjdk.java.net/jdk/pull/8262 From fjiang at openjdk.java.net Fri Apr 22 09:42:39 2022 From: fjiang at openjdk.java.net (Feilong Jiang) Date: Fri, 22 Apr 2022 09:42:39 GMT Subject: RFR: 8285303: riscv: Incorrect register mask in call_native_base In-Reply-To: References: <4cVLgyZuTzCDWf8f7cEK8T3OjSYKgx3iABJwI7UD0ac=.5a60df1c-ad23-46ae-97c0-d377ce0bed12@github.com> Message-ID: On Fri, 22 Apr 2022 03:14:56 GMT, Yadong Wang wrote: >> In `MacroAssembler::call_native_base`, t0 and xmethod should be saved as expected: >> >> >> void MacroAssembler::call_native_base(address entry_point, Label *retaddr) { >> Label E, L; >> int32_t offset = 0; >> push_reg(0x80000040, sp); // push << t0 & xmethod >> to sp >> movptr_with_offset(t0, entry_point, offset); >> jalr(x1, t0, offset); >> if (retaddr != NULL) { >> bind(*retaddr); >> } >> pop_reg(0x80000040, sp); // pop << t0 & xmethod >> from sp >> } >> >> >> Register mask of '0x80000040' operates << t1 & xmethod >> here, which should be '0x80000020' for << t0 & xmethod >>. >> >> This PR also removes `MacroAssembler::call_native_base` and `MacroAssembler::call_native_base`, expands the definitions of `call_native_base` to `MacroAssembler::call_VM_leaf_base` directly. >> >> Linux RISCV64 release hotspot/jdk tier1 tests are passed on QEMU. > > lgtm @yadongw @RealFYang -- Thank you for the reviews. ------------- PR: https://git.openjdk.java.net/jdk/pull/8353 From dnsimon at openjdk.java.net Fri Apr 22 11:12:21 2022 From: dnsimon at openjdk.java.net (Doug Simon) Date: Fri, 22 Apr 2022 11:12:21 GMT Subject: RFR: 8242440: use separate, destroyable JavaVM instances per libgraal compiler thread [v3] In-Reply-To: References: Message-ID: On Fri, 22 Apr 2022 05:10:16 GMT, Kim Barrett wrote: >> Doug Simon has updated the pull request incrementally with one additional commit since the last revision: >> >> removed (incorrect) volatile modifier from JVMCIRuntime::_shared_library_javavm > > src/hotspot/share/jvmci/jvmciRuntime.cpp line 895: > >> 893: ResourceMark rm; >> 894: oop** ptrs = NEW_RESOURCE_ARRAY(oop*, _oop_handles.length()); >> 895: for (int i = 0; i < _oop_handles.length(); i++) { > > Now that _oop_handles is a vector of `oop*`, the resource allocation and > possibly some copying could be avoided. Do an in-place removal of nullptr and > clearing of the values pass over the vector, and then use > > object_handles()->release(_oop_handles.at_ptr(0), _oop_handles.length()) > > For future, I wonder if it would be worth changing OopStorage bulk release to ignore nullptrs in the array, to better support this kind of use-case. But I'm not sure how common this kind of use-case (array of handles, some of which might be nullptr) really might be. I think there are only a couple uses of bulk release so far. Nice suggestion on avoiding resource allocation: https://github.com/openjdk/jdk/pull/8262/commits/385880c2bf0343aee8166c6bc45446e0033c876b I don't think it's worth changing OopStorage bulk release for this use case. ------------- PR: https://git.openjdk.java.net/jdk/pull/8262 From lucy at openjdk.java.net Fri Apr 22 11:21:31 2022 From: lucy at openjdk.java.net (Lutz Schmidt) Date: Fri, 22 Apr 2022 11:21:31 GMT Subject: RFR: 8278757: [s390] Implement AES Counter Mode Intrinsic [v7] In-Reply-To: References: Message-ID: <7AJ73w2pfnUEnZREojkEf6A-yuFUGFyhryhoFK3KIic=.affe4f51-280d-4099-bc72-ab05be656669@github.com> > Please review (and approve, if possible) this pull request. > > This is a s390-only enhancement. It introduces the implementation of an AES-CTR intrinsic, making use of the specific s390 instruction for AES counter-mode encryption. > > Testing: SAP does no longer maintain a full build and test environment for s390. Testing is therefore limited to running some test suites (SPECjbb*, SPECjvm*) manually. But: identical code is contained in SAP's commercial product and thoroughly tested in that context. No issues were uncovered. > > @backwaterred Could you please conduct some "official" testing for this PR? > > Thank you all! > > Note: some performance figures can be found in the JBS ticket. Lutz Schmidt has updated the pull request incrementally with one additional commit since the last revision: 8278757: honor review comments part 2 - resolve TODOs ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8142/files - new: https://git.openjdk.java.net/jdk/pull/8142/files/a99a6fbe..9bed793b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8142&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8142&range=05-06 Stats: 51 lines in 3 files changed: 37 ins; 2 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/8142.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8142/head:pull/8142 PR: https://git.openjdk.java.net/jdk/pull/8142 From lucy at openjdk.java.net Fri Apr 22 11:31:25 2022 From: lucy at openjdk.java.net (Lutz Schmidt) Date: Fri, 22 Apr 2022 11:31:25 GMT Subject: RFR: 8278757: [s390] Implement AES Counter Mode Intrinsic [v7] In-Reply-To: <7AJ73w2pfnUEnZREojkEf6A-yuFUGFyhryhoFK3KIic=.affe4f51-280d-4099-bc72-ab05be656669@github.com> References: <7AJ73w2pfnUEnZREojkEf6A-yuFUGFyhryhoFK3KIic=.affe4f51-280d-4099-bc72-ab05be656669@github.com> Message-ID: <5gExl902o7NYAkV0lYaphfIaN9e9gzsZsVQdPuqIFsY=.e79e652a-0e35-458d-a8b6-c7ad54370fa5@github.com> On Fri, 22 Apr 2022 11:21:31 GMT, Lutz Schmidt wrote: >> Please review (and approve, if possible) this pull request. >> >> This is a s390-only enhancement. It introduces the implementation of an AES-CTR intrinsic, making use of the specific s390 instruction for AES counter-mode encryption. >> >> Testing: SAP does no longer maintain a full build and test environment for s390. Testing is therefore limited to running some test suites (SPECjbb*, SPECjvm*) manually. But: identical code is contained in SAP's commercial product and thoroughly tested in that context. No issues were uncovered. >> >> @backwaterred Could you please conduct some "official" testing for this PR? >> >> Thank you all! >> >> Note: some performance figures can be found in the JBS ticket. > > Lutz Schmidt has updated the pull request incrementally with one additional commit since the last revision: > > 8278757: honor review comments part 2 - resolve TODOs PR is now updated to (hopefully) cover all review comments/requests. To efficiently implement the 128-bit increment operation, I had to provide new instructions (add with carry). Testing and generated code examination is not completed yet. ------------- PR: https://git.openjdk.java.net/jdk/pull/8142 From thartmann at openjdk.java.net Fri Apr 22 13:35:31 2022 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Fri, 22 Apr 2022 13:35:31 GMT Subject: RFR: 8242440: use separate, destroyable JavaVM instances per libgraal compiler thread [v4] In-Reply-To: References: Message-ID: On Fri, 22 Apr 2022 10:08:20 GMT, Doug Simon wrote: >> Currently, libgraal runs in a single, permanent JavaVM instance loaded from libjvmcicompiler.so. This poses 2 problems: >> >> 1. The memory used for libgraal is never released, even when the libgraal compiler queues are idle. >> 2. Since all libgraal HotSpot compiler threads share the same SVM heap, libgraal compilation is effectively paused when a GC occurs (SVM currently has a stop the world collector). The more compiler threads there are, the more often this happens. >> >> This PR implements the following solution to these problems: >> 1. Create a new JavaVM instance per libgraal compiler thread (i.e. a separate SVM isolate per thread). This prevents GC in one libgraal thread from impacting another libgraal thread. >> 2. Destroy the JavaVM instances when a libgraal compiler thread becomes idle and create a new one when subsequent compilation requests arrive. >> >> Most of the changes are in JVMCI specific files. The most significant change to shared code is the addition of the `JavaThread:: _libjvmci_runtime` field. This is required as any thread (not just a `CompilerThread`) can be associated with a specific `JVMCIRuntime` object. > > Doug Simon has updated the pull request incrementally with one additional commit since the last revision: > > avoid resource allocation in JVMCIRuntime::release_and_clear_globals I'm not an expert in the JVMCI code but it looks reasonable to me. src/hotspot/share/compiler/compileBroker.cpp line 443: > 441: } > 442: > 443: AbstractCompiler *compiler = thread->compiler(); Suggestion: AbstractCompiler* compiler = thread->compiler(); src/hotspot/share/jvmci/jvmci.cpp line 204: > 202: } > 203: for (JVMCIRuntime* runtime = _compiler_runtimes; runtime != nullptr; runtime = runtime->_next) { > 204: runtime->_metadata_handles->do_unloading(); Suggestion: for (JVMCIRuntime* runtime = _compiler_runtimes; runtime != nullptr; runtime = runtime->_next) { runtime->_metadata_handles->do_unloading(); src/hotspot/share/jvmci/jvmci.cpp line 264: > 262: java_runtime->shutdown(); > 263: } > 264: JVMCIRuntime *runtime = thread->libjvmci_runtime(); Suggestion: JVMCIRuntime* runtime = thread->libjvmci_runtime(); src/hotspot/share/jvmci/jvmci.hpp line 122: > 120: // Returns true iff there is a new shared library JavaVM per compilation. > 121: static bool one_shared_library_javavm_per_compilation() { > 122: return JVMCIThreadsPerNativeLibraryRuntime == 1 && JVMCICompilerIdleDelay == 0; Why does this check for `JVMCICompilerIdleDelay == 0` and where is this method used? src/hotspot/share/jvmci/jvmciCompilerToVM.cpp line 2269: > 2267: C2V_BLOCK(jboolean, isCurrentThreadAttached, (JNIEnv* env, jobject)) > 2268: requireJVMCINativeLibrary(JVMCI_CHECK_0); > 2269: JVMCIRuntime *runtime = thread->libjvmci_runtime(); Suggestion: JVMCIRuntime* runtime = thread->libjvmci_runtime(); src/hotspot/share/jvmci/jvmciCompilerToVM.cpp line 2391: > 2389: requireJVMCINativeLibrary(JVMCI_CHECK_0); > 2390: requireInHotSpot("detachCurrentThread", JVMCI_CHECK_0); > 2391: JVMCIRuntime *runtime = thread->libjvmci_runtime(); Suggestion: JVMCIRuntime* runtime = thread->libjvmci_runtime(); src/hotspot/share/jvmci/jvmciCompilerToVM.cpp line 2414: > 2412: JNI_THROW_("detachCurrentThread", InternalError, "JVMCI shared library thread cannot release JVMCI shared library JavaVM", false); > 2413: } > 2414: JVMCIRuntime *runtime = thread->libjvmci_runtime(); Suggestion: JVMCIRuntime* runtime = thread->libjvmci_runtime(); src/hotspot/share/jvmci/jvmci_globals.hpp line 71: > 69: "compiler queue becomes idle, it is detached from its JVMCIRuntime. "\ > 70: "Once the last thread is detached from a JVMCIRuntime, all " \ > 71: "all resources associated with the runtime are reclaimed.") \ Suggestion: "Once the last thread is detached from a JVMCIRuntime, all " \ "resources associated with the runtime are reclaimed.") \ src/hotspot/share/jvmci/vmStructs_jvmci.cpp line 412: > 410: declare_constant(JVM_ACC_FIELD_STABLE) \ > 411: declare_constant(JVM_ACC_FIELD_HAS_GENERIC_SIGNATURE) \ > 412: declare_constant(JVM_ACC_IS_VALUE_BASED_CLASS) \ This looks Valhalla specific, why is it added here? ------------- Marked as reviewed by thartmann (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8262 From dnsimon at openjdk.java.net Fri Apr 22 14:04:31 2022 From: dnsimon at openjdk.java.net (Doug Simon) Date: Fri, 22 Apr 2022 14:04:31 GMT Subject: RFR: 8242440: use separate, destroyable JavaVM instances per libgraal compiler thread [v4] In-Reply-To: References: Message-ID: On Fri, 22 Apr 2022 11:30:15 GMT, Tobias Hartmann wrote: >> Doug Simon has updated the pull request incrementally with one additional commit since the last revision: >> >> avoid resource allocation in JVMCIRuntime::release_and_clear_globals > > src/hotspot/share/jvmci/vmStructs_jvmci.cpp line 412: > >> 410: declare_constant(JVM_ACC_FIELD_STABLE) \ >> 411: declare_constant(JVM_ACC_FIELD_HAS_GENERIC_SIGNATURE) \ >> 412: declare_constant(JVM_ACC_IS_VALUE_BASED_CLASS) \ > > This looks Valhalla specific, why is it added here? This is needed to fix a Graal-specific regression on `DiagnoseSyncOnValueBasedClasses`. It's a shame that there's no way to automatically iterate over all `JVM_ACC*` values in vmstructs. ------------- PR: https://git.openjdk.java.net/jdk/pull/8262 From dnsimon at openjdk.java.net Fri Apr 22 14:10:24 2022 From: dnsimon at openjdk.java.net (Doug Simon) Date: Fri, 22 Apr 2022 14:10:24 GMT Subject: RFR: 8242440: use separate, destroyable JavaVM instances per libgraal compiler thread [v5] In-Reply-To: References: Message-ID: > Currently, libgraal runs in a single, permanent JavaVM instance loaded from libjvmcicompiler.so. This poses 2 problems: > > 1. The memory used for libgraal is never released, even when the libgraal compiler queues are idle. > 2. Since all libgraal HotSpot compiler threads share the same SVM heap, libgraal compilation is effectively paused when a GC occurs (SVM currently has a stop the world collector). The more compiler threads there are, the more often this happens. > > This PR implements the following solution to these problems: > 1. Create a new JavaVM instance per libgraal compiler thread (i.e. a separate SVM isolate per thread). This prevents GC in one libgraal thread from impacting another libgraal thread. > 2. Destroy the JavaVM instances when a libgraal compiler thread becomes idle and create a new one when subsequent compilation requests arrive. > > Most of the changes are in JVMCI specific files. The most significant change to shared code is the addition of the `JavaThread:: _libjvmci_runtime` field. This is required as any thread (not just a `CompilerThread`) can be associated with a specific `JVMCIRuntime` object. Doug Simon has updated the pull request incrementally with one additional commit since the last revision: made suggested formatting changes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8262/files - new: https://git.openjdk.java.net/jdk/pull/8262/files/385880c2..1b75a167 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8262&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8262&range=03-04 Stats: 5 lines in 4 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/8262.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8262/head:pull/8262 PR: https://git.openjdk.java.net/jdk/pull/8262 From dnsimon at openjdk.java.net Fri Apr 22 14:22:13 2022 From: dnsimon at openjdk.java.net (Doug Simon) Date: Fri, 22 Apr 2022 14:22:13 GMT Subject: RFR: 8242440: use separate, destroyable JavaVM instances per libgraal compiler thread [v6] In-Reply-To: References: Message-ID: <5SYjD-y_-sAiysbXHqIV8f4e6ZXTifEnSJ9XPq1gRfw=.cd29d90a-9a44-439a-8d57-887694c5d115@github.com> > Currently, libgraal runs in a single, permanent JavaVM instance loaded from libjvmcicompiler.so. This poses 2 problems: > > 1. The memory used for libgraal is never released, even when the libgraal compiler queues are idle. > 2. Since all libgraal HotSpot compiler threads share the same SVM heap, libgraal compilation is effectively paused when a GC occurs (SVM currently has a stop the world collector). The more compiler threads there are, the more often this happens. > > This PR implements the following solution to these problems: > 1. Create a new JavaVM instance per libgraal compiler thread (i.e. a separate SVM isolate per thread). This prevents GC in one libgraal thread from impacting another libgraal thread. > 2. Destroy the JavaVM instances when a libgraal compiler thread becomes idle and create a new one when subsequent compilation requests arrive. > > Most of the changes are in JVMCI specific files. The most significant change to shared code is the addition of the `JavaThread:: _libjvmci_runtime` field. This is required as any thread (not just a `CompilerThread`) can be associated with a specific `JVMCIRuntime` object. Doug Simon has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains two new commits since the last revision: - documented option values to enable multi-isolate stress-test mode - made suggested formatting changes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8262/files - new: https://git.openjdk.java.net/jdk/pull/8262/files/1b75a167..ea170e7a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8262&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8262&range=04-05 Stats: 5 lines in 3 files changed: 2 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/8262.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8262/head:pull/8262 PR: https://git.openjdk.java.net/jdk/pull/8262 From dnsimon at openjdk.java.net Fri Apr 22 14:22:14 2022 From: dnsimon at openjdk.java.net (Doug Simon) Date: Fri, 22 Apr 2022 14:22:14 GMT Subject: RFR: 8242440: use separate, destroyable JavaVM instances per libgraal compiler thread [v4] In-Reply-To: References: Message-ID: <73qbrRKWV7O3oB92hCjxUjjURFX3B5hl4Hha_wFG21M=.b3910259-fd4a-4c42-9ecf-aaea07a906a0@github.com> On Fri, 22 Apr 2022 13:23:12 GMT, Tobias Hartmann wrote: >> Doug Simon has updated the pull request incrementally with one additional commit since the last revision: >> >> avoid resource allocation in JVMCIRuntime::release_and_clear_globals > > src/hotspot/share/jvmci/jvmci.hpp line 122: > >> 120: // Returns true iff there is a new shared library JavaVM per compilation. >> 121: static bool one_shared_library_javavm_per_compilation() { >> 122: return JVMCIThreadsPerNativeLibraryRuntime == 1 && JVMCICompilerIdleDelay == 0; > > Why does this check for `JVMCICompilerIdleDelay == 0` and where is this method used? It's used in `JVMCIRuntime::post_compile`. The combination of `JVMCIThreadsPerNativeLibraryRuntime == 1 && JVMCICompilerIdleDelay == 0` is the stress test mode for multi-isolate support. It forces a new libgraal isolate to be used for every single compilation. I've updated the help text for `JVMCICompilerIdleDelay ` to document this mode: https://github.com/openjdk/jdk/pull/8262/commits/ea170e7af1e2a97a0509224fd6ba79bcb07038bd ------------- PR: https://git.openjdk.java.net/jdk/pull/8262 From dnsimon at openjdk.java.net Fri Apr 22 15:33:19 2022 From: dnsimon at openjdk.java.net (Doug Simon) Date: Fri, 22 Apr 2022 15:33:19 GMT Subject: RFR: 8242440: use separate, destroyable JavaVM instances per libgraal compiler thread [v7] In-Reply-To: References: Message-ID: <3virHqUdXutsY2AEI1yPDrD8pFMW28HGbfLH8iGSI8w=.b201b374-62c8-4df3-8a13-4160128fb231@github.com> > Currently, libgraal runs in a single, permanent JavaVM instance loaded from libjvmcicompiler.so. This poses 2 problems: > > 1. The memory used for libgraal is never released, even when the libgraal compiler queues are idle. > 2. Since all libgraal HotSpot compiler threads share the same SVM heap, libgraal compilation is effectively paused when a GC occurs (SVM currently has a stop the world collector). The more compiler threads there are, the more often this happens. > > This PR implements the following solution to these problems: > 1. Create a new JavaVM instance per libgraal compiler thread (i.e. a separate SVM isolate per thread). This prevents GC in one libgraal thread from impacting another libgraal thread. > 2. Destroy the JavaVM instances when a libgraal compiler thread becomes idle and create a new one when subsequent compilation requests arrive. > > Most of the changes are in JVMCI specific files. The most significant change to shared code is the addition of the `JavaThread:: _libjvmci_runtime` field. This is required as any thread (not just a `CompilerThread`) can be associated with a specific `JVMCIRuntime` object. Doug Simon 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: documented option values to enable multi-isolate stress-test mode ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8262/files - new: https://git.openjdk.java.net/jdk/pull/8262/files/ea170e7a..7af1246b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8262&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8262&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8262.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8262/head:pull/8262 PR: https://git.openjdk.java.net/jdk/pull/8262 From stefank at openjdk.java.net Fri Apr 22 16:04:26 2022 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Fri, 22 Apr 2022 16:04:26 GMT Subject: RFR: 8285364: Remove REF_ enum for java.lang.ref.Reference [v2] In-Reply-To: References: Message-ID: On Fri, 22 Apr 2022 09:04:37 GMT, Kim Barrett wrote: > > > Using REF_SOFT seems too hacky. > > > > > > Just to put all alternatives on the table. The use of `REF_SOFT` is ephemeral. > > [...] > > I have no particular preference. What does everyone think? > > I also think using REF_SOFT like that is overly hacky. > > I think there is still a bootstrapping weirdness, whether using REF_REFERENCE or using Stefan's approach. I think Soft/Weak/Final/PhantomReference_klass get constructed with the reftype of Reference_klass (whatever that is), and then have it later updated to the correct value. In that respect REF_OTHER seems better than REF_REFERENCE. So I no longer like the renaming. Getting rid of it entirely with Stefan's approach, they get REF_NONE initially and then set to the proper value; that's far from the worst bootstrapping kludge I've ever seen. I think we can fix the bootstrapping kludge with something like this: https://github.com/stefank/jdk/commit/e62ddb780730dbb5d6766f882346bf0fcc6cdb59 With this patch, we'll always have the correct _reference_type after the InstanceRefKlass constructor has run. (Patch has not gone through full testing yet) ------------- PR: https://git.openjdk.java.net/jdk/pull/8332 From duke at openjdk.java.net Fri Apr 22 20:18:16 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Fri, 22 Apr 2022 20:18:16 GMT Subject: RFR: 8283643: [AIX, testbug] MachCodeFramesInErrorFile test fails to find 'Native frames' text [v6] In-Reply-To: References: Message-ID: > I observed a failure of MachCodeFramesInErrorFile.java on AIX. The raised error complains that 'Native frames: ' is missing. To fix the failure, I made two changes to the test that allowed it to pass on AIX. > > The first change made was to the test's `extractFrames` method. AIX overrides `os::platform_print_native_stack` with stack printing specific to AIX/Power. This code does not produce the 'Native frames: ' text that `vmError::print_native_stack` does, so the test was modified to expect the AIX output when run on AIX. [Edit: The changes made to `extractFrames` are now minimal. I made the change to `AixNativeCallstack::print_callstack_for_context` instead.] > > A second change was made to the address passed to the `crashInNative1` method. AIX does not consider low-address memory to be protected as other platforms do. In fact, "the first 256 bytes are reserved for software use" according to the Power ISA. Accordingly, the read address for PPC was changed to -1 (0xFF..FF) to produce the expected failure result. > > ### Testing > > Tier1 tests complete as expected on AIX/Power. Tyler Steele has updated the pull request incrementally with one additional commit since the last revision: Use OuputAnalyzer::reportDiagnosticSummary instead of printing directly. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8094/files - new: https://git.openjdk.java.net/jdk/pull/8094/files/d13f91af..d0a05457 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8094&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8094&range=04-05 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8094.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8094/head:pull/8094 PR: https://git.openjdk.java.net/jdk/pull/8094 From serb at openjdk.java.net Fri Apr 22 23:45:27 2022 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Fri, 22 Apr 2022 23:45:27 GMT Subject: RFR: 8285149: Using HashMap.newHashMap to replace new HashMap(int) [v3] In-Reply-To: References: Message-ID: On Wed, 20 Apr 2022 19:24:25 GMT, XenoAmess wrote: >> These are the changes that too many to be reviewed in 8186958, thus split some of them out. > > XenoAmess has updated the pull request incrementally with one additional commit since the last revision: > > add more replaces src/demo/share/java2d/J2DBench/src/j2dbench/tests/text/TextTests.java line 291: > 289: > 290: > 291: static HashMap strcache = HashMap.newHashMap(tscripts.length); This code maintains compatibility with jdk1.4, not necessary to change it. src/java.datatransfer/share/classes/java/awt/datatransfer/SystemFlavorMap.java line 815: > 813: } > 814: > 815: Map retval =HashMap.newHashMap(natives.length); missed space after '=' ------------- PR: https://git.openjdk.java.net/jdk/pull/8301 From fjiang at openjdk.java.net Fri Apr 22 23:53:27 2022 From: fjiang at openjdk.java.net (Feilong Jiang) Date: Fri, 22 Apr 2022 23:53:27 GMT Subject: Integrated: 8285303: riscv: Incorrect register mask in call_native_base In-Reply-To: <4cVLgyZuTzCDWf8f7cEK8T3OjSYKgx3iABJwI7UD0ac=.5a60df1c-ad23-46ae-97c0-d377ce0bed12@github.com> References: <4cVLgyZuTzCDWf8f7cEK8T3OjSYKgx3iABJwI7UD0ac=.5a60df1c-ad23-46ae-97c0-d377ce0bed12@github.com> Message-ID: On Fri, 22 Apr 2022 02:02:01 GMT, Feilong Jiang wrote: > In `MacroAssembler::call_native_base`, t0 and xmethod should be saved as expected: > > > void MacroAssembler::call_native_base(address entry_point, Label *retaddr) { > Label E, L; > int32_t offset = 0; > push_reg(0x80000040, sp); // push << t0 & xmethod >> to sp > movptr_with_offset(t0, entry_point, offset); > jalr(x1, t0, offset); > if (retaddr != NULL) { > bind(*retaddr); > } > pop_reg(0x80000040, sp); // pop << t0 & xmethod >> from sp > } > > > Register mask of '0x80000040' operates << t1 & xmethod >> here, which should be '0x80000020' for << t0 & xmethod >>. > > This PR also removes `MacroAssembler::call_native_base` and `MacroAssembler::call_native_base`, expands the definitions of `call_native_base` to `MacroAssembler::call_VM_leaf_base` directly. > > Linux RISCV64 release hotspot/jdk tier1 tests are passed on QEMU. This pull request has now been integrated. Changeset: b10833bb Author: Feilong Jiang Committer: Fei Yang URL: https://git.openjdk.java.net/jdk/commit/b10833bbf3cd33c6e6a4cf2671f587a27c606ebb Stats: 19 lines in 2 files changed: 0 ins; 17 del; 2 mod 8285303: riscv: Incorrect register mask in call_native_base Co-authored-by: Dingli Zhang Reviewed-by: fyang, yadongwang ------------- PR: https://git.openjdk.java.net/jdk/pull/8353 From dholmes at openjdk.java.net Sat Apr 23 06:02:27 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Sat, 23 Apr 2022 06:02:27 GMT Subject: RFR: 8283643: [AIX, testbug] MachCodeFramesInErrorFile test fails to find 'Native frames' text [v5] In-Reply-To: References: Message-ID: <5Xf2O9dcjSnUa07-a-qIDw2Da-YkuZDmXWvITFDyJP4=.87e3e7fb-af7d-47db-af93-9c083365bdb5@github.com> On Thu, 21 Apr 2022 16:41:02 GMT, Tyler Steele wrote: >> test/hotspot/jtreg/runtime/ErrorHandling/MachCodeFramesInErrorFile.java line 133: >> >>> 131: System.out.println("stdout:\n" + output.getStdout()); >>> 132: System.err.println("stderr:\n" + output.getStderr()); >>> 133: throw new RuntimeException("Did not find hs_err_pid file in output"); >> >> Why this change (and a similar one at the end of the file)? This separates the reporting of a failed condition (i.e., could not find expected patten in output) from the context (i.e. contents of stderr and stdout) that assists in diagnosing why the condition may have failed. > > @dougxc, I added [an explanation](https://github.com/openjdk/jdk/pull/8094/files#r855362995) to the similar change at the end of the file. That was the one I discovered first. Here I made a similar change to prevent the same issue from occurring. > > @dholmes-ora, I don't think output.shouldMatch is the best choice here because it involves doing the same operation twice. I believe I would end up looking for the pattern and throwing an error with shouldMatch, then looking for the pattern again and returning the String with firstMatch. I do like your idea of using more standard code however. I would like to replace the calls to println with `output.reportDiagnosticSummary()` if that is a reasonable compromise to your suggestion? It is a test so I'm not overly concerned about scanning the output twice - though I agree it is a bit irksome to have to do that (new RFE: add `firstMatchOrFail`?). Using `reportDiagnosticSummary` is a reasonable compromise. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/8094 From dnsimon at openjdk.java.net Sat Apr 23 06:11:28 2022 From: dnsimon at openjdk.java.net (Doug Simon) Date: Sat, 23 Apr 2022 06:11:28 GMT Subject: Integrated: 8242440: use separate, destroyable JavaVM instances per libgraal compiler thread In-Reply-To: References: Message-ID: <8eLXZS0ycDfCDC6sbtj1R1z0HQR-Udlg7NIC42TjZWo=.1b793e82-bdbc-4d60-a116-6034391dfc73@github.com> On Fri, 15 Apr 2022 13:29:43 GMT, Doug Simon wrote: > Currently, libgraal runs in a single, permanent JavaVM instance loaded from libjvmcicompiler.so. This poses 2 problems: > > 1. The memory used for libgraal is never released, even when the libgraal compiler queues are idle. > 2. Since all libgraal HotSpot compiler threads share the same SVM heap, libgraal compilation is effectively paused when a GC occurs (SVM currently has a stop the world collector). The more compiler threads there are, the more often this happens. > > This PR implements the following solution to these problems: > 1. Create a new JavaVM instance per libgraal compiler thread (i.e. a separate SVM isolate per thread). This prevents GC in one libgraal thread from impacting another libgraal thread. > 2. Destroy the JavaVM instances when a libgraal compiler thread becomes idle and create a new one when subsequent compilation requests arrive. > > Most of the changes are in JVMCI specific files. The most significant change to shared code is the addition of the `JavaThread:: _libjvmci_runtime` field. This is required as any thread (not just a `CompilerThread`) can be associated with a specific `JVMCIRuntime` object. This pull request has now been integrated. Changeset: 357b1b18 Author: Doug Simon URL: https://git.openjdk.java.net/jdk/commit/357b1b18c20233f16fba872b79237e9459f5ba43 Stats: 1088 lines in 23 files changed: 828 ins; 74 del; 186 mod 8242440: use separate, destroyable JavaVM instances per libgraal compiler thread Reviewed-by: kvn, thartmann ------------- PR: https://git.openjdk.java.net/jdk/pull/8262 From dnsimon at openjdk.java.net Sat Apr 23 09:41:29 2022 From: dnsimon at openjdk.java.net (Doug Simon) Date: Sat, 23 Apr 2022 09:41:29 GMT Subject: RFR: 8242440: use separate, destroyable JavaVM instances per libgraal compiler thread [v3] In-Reply-To: References: Message-ID: <6SgnK6Sn_EIK1VFPV07FqCiy9smIyBxxxt0_n3SHpyI=.ca87b49f-8d45-4331-8a98-92dbfbf4870f@github.com> On Fri, 22 Apr 2022 05:20:20 GMT, Kim Barrett wrote: >> Doug Simon has updated the pull request incrementally with one additional commit since the last revision: >> >> removed (incorrect) volatile modifier from JVMCIRuntime::_shared_library_javavm > > One more possible improvement suggestion. As I said before, I've only reviewed the runtime parts (which looks okay), and just skimmed the rest. So don't count me as the required 2nd reviewer. Thanks @kimbarrett for the very helpful feedback on this PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/8262 From duke at openjdk.java.net Sat Apr 23 14:34:58 2022 From: duke at openjdk.java.net (XenoAmess) Date: Sat, 23 Apr 2022 14:34:58 GMT Subject: RFR: 8285149: Using HashMap.newHashMap to replace new HashMap(int) [v4] In-Reply-To: References: Message-ID: > These are the changes that too many to be reviewed in 8186958, thus split some of them out. XenoAmess has updated the pull request incrementally with two additional commits since the last revision: - maintains compatibility with jdk1.4 for TextTests - fix missed space after '=' ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8301/files - new: https://git.openjdk.java.net/jdk/pull/8301/files/4f2d4838..684d1528 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8301&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8301&range=02-03 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8301.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8301/head:pull/8301 PR: https://git.openjdk.java.net/jdk/pull/8301 From duke at openjdk.java.net Sat Apr 23 14:35:00 2022 From: duke at openjdk.java.net (XenoAmess) Date: Sat, 23 Apr 2022 14:35:00 GMT Subject: RFR: 8285149: Using HashMap.newHashMap to replace new HashMap(int) [v3] In-Reply-To: References: Message-ID: On Fri, 22 Apr 2022 23:31:41 GMT, Sergey Bylokhov wrote: >> XenoAmess has updated the pull request incrementally with one additional commit since the last revision: >> >> add more replaces > > src/demo/share/java2d/J2DBench/src/j2dbench/tests/text/TextTests.java line 291: > >> 289: >> 290: >> 291: static HashMap strcache = HashMap.newHashMap(tscripts.length); > > This code maintains compatibility with jdk1.4, not necessary to change it. @mrserb done. > src/java.datatransfer/share/classes/java/awt/datatransfer/SystemFlavorMap.java line 815: > >> 813: } >> 814: >> 815: Map retval =HashMap.newHashMap(natives.length); > > missed space after '=' @mrserb done. ------------- PR: https://git.openjdk.java.net/jdk/pull/8301 From lucy at openjdk.java.net Mon Apr 25 08:05:06 2022 From: lucy at openjdk.java.net (Lutz Schmidt) Date: Mon, 25 Apr 2022 08:05:06 GMT Subject: RFR: 8278757: [s390] Implement AES Counter Mode Intrinsic [v8] In-Reply-To: References: Message-ID: > Please review (and approve, if possible) this pull request. > > This is a s390-only enhancement. It introduces the implementation of an AES-CTR intrinsic, making use of the specific s390 instruction for AES counter-mode encryption. > > Testing: SAP does no longer maintain a full build and test environment for s390. Testing is therefore limited to running some test suites (SPECjbb*, SPECjvm*) manually. But: identical code is contained in SAP's commercial product and thoroughly tested in that context. No issues were uncovered. > > @backwaterred Could you please conduct some "official" testing for this PR? > > Thank you all! > > Note: some performance figures can be found in the JBS ticket. Lutz Schmidt has updated the pull request incrementally with one additional commit since the last revision: 8278757: more helpful block comments and code cleanup ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8142/files - new: https://git.openjdk.java.net/jdk/pull/8142/files/9bed793b..47fbd459 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8142&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8142&range=06-07 Stats: 28 lines in 1 file changed: 3 ins; 13 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/8142.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8142/head:pull/8142 PR: https://git.openjdk.java.net/jdk/pull/8142 From lucy at openjdk.java.net Mon Apr 25 11:23:39 2022 From: lucy at openjdk.java.net (Lutz Schmidt) Date: Mon, 25 Apr 2022 11:23:39 GMT Subject: RFR: 8278757: [s390] Implement AES Counter Mode Intrinsic [v8] In-Reply-To: References: Message-ID: On Mon, 25 Apr 2022 08:05:06 GMT, Lutz Schmidt wrote: >> Please review (and approve, if possible) this pull request. >> >> This is a s390-only enhancement. It introduces the implementation of an AES-CTR intrinsic, making use of the specific s390 instruction for AES counter-mode encryption. >> >> Testing: SAP does no longer maintain a full build and test environment for s390. Testing is therefore limited to running some test suites (SPECjbb*, SPECjvm*) manually. But: identical code is contained in SAP's commercial product and thoroughly tested in that context. No issues were uncovered. >> >> @backwaterred Could you please conduct some "official" testing for this PR? >> >> Thank you all! >> >> Note: some performance figures can be found in the JBS ticket. > > Lutz Schmidt has updated the pull request incrementally with one additional commit since the last revision: > > 8278757: more helpful block comments and code cleanup MacOS tier1 test failures are not a factor for a s390-only change. Private testing revealed no issues. No performance impact of recent changes. @backwaterred could you please re-run tier1 tests on linuxs390x with the latest changes included? Thank you! ------------- PR: https://git.openjdk.java.net/jdk/pull/8142 From mdoerr at openjdk.java.net Mon Apr 25 13:06:26 2022 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Mon, 25 Apr 2022 13:06:26 GMT Subject: RFR: 8278757: [s390] Implement AES Counter Mode Intrinsic [v8] In-Reply-To: References: Message-ID: <2SOG1PoO_GY78g0GB51nFUiHFxtwYHEQfufyVzfn8ew=.699236ff-da53-4707-9f44-87515451a6ff@github.com> On Mon, 25 Apr 2022 08:05:06 GMT, Lutz Schmidt wrote: >> Please review (and approve, if possible) this pull request. >> >> This is a s390-only enhancement. It introduces the implementation of an AES-CTR intrinsic, making use of the specific s390 instruction for AES counter-mode encryption. >> >> Testing: SAP does no longer maintain a full build and test environment for s390. Testing is therefore limited to running some test suites (SPECjbb*, SPECjvm*) manually. But: identical code is contained in SAP's commercial product and thoroughly tested in that context. No issues were uncovered. >> >> @backwaterred Could you please conduct some "official" testing for this PR? >> >> Thank you all! >> >> Note: some performance figures can be found in the JBS ticket. > > Lutz Schmidt has updated the pull request incrementally with one additional commit since the last revision: > > 8278757: more helpful block comments and code cleanup Thanks for improving it! Looks basically good to me. Awaiting tests. src/hotspot/cpu/s390/stubGenerator_s390.cpp line 2011: > 2009: __ z_alcg(scratch, Address(counter, offset)); // add carry to high-order DW > 2010: __ z_stg(scratch, Address(counter, offset)); // store back > 2011: } Good. Maybe add a Big Endian comment? src/hotspot/cpu/s390/stubGenerator_s390.cpp line 2929: > 2927: } else { > 2928: assert(VM_Version::has_Crypto_AES_CTR(), "Inconsistent settings. Check vm_version_s390.cpp"); > 2929: } A bit complicated. Why if + assert? That's redundant. ------------- PR: https://git.openjdk.java.net/jdk/pull/8142 From alanb at openjdk.java.net Mon Apr 25 13:14:48 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 25 Apr 2022 13:14:48 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v5] In-Reply-To: References: <3RNoPzJecSfEBdapZpbKMJZG1ep3mVUW1Z5kKNrFYSk=.821824df-3431-437a-b5c8-c4627021d349@github.com> Message-ID: On Fri, 22 Apr 2022 02:26:50 GMT, ExE Boss wrote: >> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: >> >> Refresh > > src/java.base/share/classes/java/lang/ThreadLocal.java line 179: > >> 177: private T get(Thread t) { >> 178: ThreadLocalMap map = getMap(t); >> 179: if (map != null && map != ThreadLocalMap.NOT_SUPPORTED) { > > Due?to the?way `setInitialValue` is?implemented, `getMap(t)` will?currently be?called?twice when?`ThreadLocal`s are?disabled. > > -------------------------------------------------------------------------------- > > This?method should?probably be?changed so?that?when `map?==?ThreadLocalMap.NOT_SUPPORTED`, it?simply?does: > > return initialValue(); > > > -------------------------------------------------------------------------------- > > Suggestion: > > if (map != null) { > if (map == ThreadLocalMap.NOT_SUPPORTED) { > return initialValue(); > } It's benign but what you suggest may be clearer - thanks! > src/java.base/share/classes/java/lang/ThreadLocal.java line 423: > >> 421: * Construct a new map without a table. >> 422: */ >> 423: ThreadLocalMap() { > > It?might be?possible for?this to?be?`private`: > Suggestion: > > private ThreadLocalMap() { Yes, this can be private. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From alanb at openjdk.java.net Mon Apr 25 13:14:52 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 25 Apr 2022 13:14:52 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2] In-Reply-To: References: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com> Message-ID: On Fri, 15 Apr 2022 21:24:58 GMT, Paul Sandoz wrote: >> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: >> >> Refresh > > src/java.base/share/classes/jdk/internal/vm/Continuation.java line 115: > >> 113: } >> 114: >> 115: private Runnable target; > > Can be final? (Does not appear to be updated by the VM, or via unsafe by some other class) Yes, it can. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From alanb at openjdk.java.net Mon Apr 25 13:19:49 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 25 Apr 2022 13:19:49 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v6] In-Reply-To: References: Message-ID: > This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. > > We will refresh this PR periodically to pick up changes and fixes from the loom repo. > > Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. > > The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. > > There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. > > The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. > > The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: - Refresh cf561073f48fad58e931a5285b92629aa83c9bd1 - Merge with jdk-19+19 - Refresh - Refresh - Refresh - Refresh - Merge with jdk-19+18 - Refresh - Initial push ------------- Changes: https://git.openjdk.java.net/jdk/pull/8166/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8166&range=05 Stats: 104157 lines in 1144 files changed: 94155 ins; 4291 del; 5711 mod Patch: https://git.openjdk.java.net/jdk/pull/8166.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8166/head:pull/8166 PR: https://git.openjdk.java.net/jdk/pull/8166 From lucy at openjdk.java.net Mon Apr 25 13:39:43 2022 From: lucy at openjdk.java.net (Lutz Schmidt) Date: Mon, 25 Apr 2022 13:39:43 GMT Subject: RFR: 8278757: [s390] Implement AES Counter Mode Intrinsic [v8] In-Reply-To: <2SOG1PoO_GY78g0GB51nFUiHFxtwYHEQfufyVzfn8ew=.699236ff-da53-4707-9f44-87515451a6ff@github.com> References: <2SOG1PoO_GY78g0GB51nFUiHFxtwYHEQfufyVzfn8ew=.699236ff-da53-4707-9f44-87515451a6ff@github.com> Message-ID: On Mon, 25 Apr 2022 13:00:26 GMT, Martin Doerr wrote: >> Lutz Schmidt has updated the pull request incrementally with one additional commit since the last revision: >> >> 8278757: more helpful block comments and code cleanup > > src/hotspot/cpu/s390/stubGenerator_s390.cpp line 2011: > >> 2009: __ z_alcg(scratch, Address(counter, offset)); // add carry to high-order DW >> 2010: __ z_stg(scratch, Address(counter, offset)); // store back >> 2011: } > > Good. Maybe add a Big Endian comment? With Big-Endian becoming more and more exotic, I agree it might be a good idea to explain what it means. I added a three-line comment preceding the generate_increment*() emitters. Will become visible with the next commit. ------------- PR: https://git.openjdk.java.net/jdk/pull/8142 From lucy at openjdk.java.net Mon Apr 25 13:47:29 2022 From: lucy at openjdk.java.net (Lutz Schmidt) Date: Mon, 25 Apr 2022 13:47:29 GMT Subject: RFR: 8278757: [s390] Implement AES Counter Mode Intrinsic [v8] In-Reply-To: <2SOG1PoO_GY78g0GB51nFUiHFxtwYHEQfufyVzfn8ew=.699236ff-da53-4707-9f44-87515451a6ff@github.com> References: <2SOG1PoO_GY78g0GB51nFUiHFxtwYHEQfufyVzfn8ew=.699236ff-da53-4707-9f44-87515451a6ff@github.com> Message-ID: On Mon, 25 Apr 2022 13:01:56 GMT, Martin Doerr wrote: >> Lutz Schmidt has updated the pull request incrementally with one additional commit since the last revision: >> >> 8278757: more helpful block comments and code cleanup > > src/hotspot/cpu/s390/stubGenerator_s390.cpp line 2929: > >> 2927: } else { >> 2928: assert(VM_Version::has_Crypto_AES_CTR(), "Inconsistent settings. Check vm_version_s390.cpp"); >> 2929: } > > A bit complicated. Why if + assert? That's redundant. I wanted to keep at least some safety net: prevent unsupported code from being emitted (in any build mode) and issue a speaking message in non-PRODUCT builds. If you insist, I will delete the safety net and solely rely on the flag evaluation in vm_version_s390.cpp to be correct. ------------- PR: https://git.openjdk.java.net/jdk/pull/8142 From mdoerr at openjdk.java.net Mon Apr 25 13:52:52 2022 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Mon, 25 Apr 2022 13:52:52 GMT Subject: RFR: 8278757: [s390] Implement AES Counter Mode Intrinsic [v8] In-Reply-To: References: <2SOG1PoO_GY78g0GB51nFUiHFxtwYHEQfufyVzfn8ew=.699236ff-da53-4707-9f44-87515451a6ff@github.com> Message-ID: <0KbVwBrHDPwCJKB8tsNzD9ew5kF5TislFu04OS8lEFI=.6c1a6321-2e05-4176-80e3-8411a2df6228@github.com> On Mon, 25 Apr 2022 13:44:11 GMT, Lutz Schmidt wrote: >> src/hotspot/cpu/s390/stubGenerator_s390.cpp line 2929: >> >>> 2927: } else { >>> 2928: assert(VM_Version::has_Crypto_AES_CTR(), "Inconsistent settings. Check vm_version_s390.cpp"); >>> 2929: } >> >> A bit complicated. Why if + assert? That's redundant. > > I wanted to keep at least some safety net: prevent unsupported code from being emitted (in any build mode) and issue a speaking message in non-PRODUCT builds. If you insist, I will delete the safety net and solely rely on the flag evaluation in vm_version_s390.cpp to be correct. What would happen in product build? Jump to NULL? I wouldn't call this a safety net :-) ------------- PR: https://git.openjdk.java.net/jdk/pull/8142 From lucy at openjdk.java.net Mon Apr 25 14:00:25 2022 From: lucy at openjdk.java.net (Lutz Schmidt) Date: Mon, 25 Apr 2022 14:00:25 GMT Subject: RFR: 8278757: [s390] Implement AES Counter Mode Intrinsic [v8] In-Reply-To: <0KbVwBrHDPwCJKB8tsNzD9ew5kF5TislFu04OS8lEFI=.6c1a6321-2e05-4176-80e3-8411a2df6228@github.com> References: <2SOG1PoO_GY78g0GB51nFUiHFxtwYHEQfufyVzfn8ew=.699236ff-da53-4707-9f44-87515451a6ff@github.com> <0KbVwBrHDPwCJKB8tsNzD9ew5kF5TislFu04OS8lEFI=.6c1a6321-2e05-4176-80e3-8411a2df6228@github.com> Message-ID: On Mon, 25 Apr 2022 13:48:41 GMT, Martin Doerr wrote: >> I wanted to keep at least some safety net: prevent unsupported code from being emitted (in any build mode) and issue a speaking message in non-PRODUCT builds. If you insist, I will delete the safety net and solely rely on the flag evaluation in vm_version_s390.cpp to be correct. > > What would happen in product build? Jump to NULL? I wouldn't call this a safety net :-) As far as I understand the code, bool LibraryCallKit::inline_aescrypt_Block() would return false, effectively preventing the intrinsic code to be called. ------------- PR: https://git.openjdk.java.net/jdk/pull/8142 From mdoerr at openjdk.java.net Mon Apr 25 14:17:27 2022 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Mon, 25 Apr 2022 14:17:27 GMT Subject: RFR: 8278757: [s390] Implement AES Counter Mode Intrinsic [v8] In-Reply-To: References: <2SOG1PoO_GY78g0GB51nFUiHFxtwYHEQfufyVzfn8ew=.699236ff-da53-4707-9f44-87515451a6ff@github.com> <0KbVwBrHDPwCJKB8tsNzD9ew5kF5TislFu04OS8lEFI=.6c1a6321-2e05-4176-80e3-8411a2df6228@github.com> Message-ID: <_5W0hCf2ci-olHOPcHjnHGi8V6Iu41mV34dA1TW_nW0=.783c739a-4528-4930-9339-623ee0eba030@github.com> On Mon, 25 Apr 2022 13:56:56 GMT, Lutz Schmidt wrote: >> What would happen in product build? Jump to NULL? I wouldn't call this a safety net :-) > > As far as I understand the code, bool LibraryCallKit::inline_aescrypt_Block() would return false, effectively preventing the intrinsic code to be called. Ok, `try_to_inline` should return false. I suggest to add a comment in the `else` block. ------------- PR: https://git.openjdk.java.net/jdk/pull/8142 From lucy at openjdk.java.net Mon Apr 25 14:35:29 2022 From: lucy at openjdk.java.net (Lutz Schmidt) Date: Mon, 25 Apr 2022 14:35:29 GMT Subject: RFR: 8278757: [s390] Implement AES Counter Mode Intrinsic [v8] In-Reply-To: <_5W0hCf2ci-olHOPcHjnHGi8V6Iu41mV34dA1TW_nW0=.783c739a-4528-4930-9339-623ee0eba030@github.com> References: <2SOG1PoO_GY78g0GB51nFUiHFxtwYHEQfufyVzfn8ew=.699236ff-da53-4707-9f44-87515451a6ff@github.com> <0KbVwBrHDPwCJKB8tsNzD9ew5kF5TislFu04OS8lEFI=.6c1a6321-2e05-4176-80e3-8411a2df6228@github.com> <_5W0hCf2ci-olHOPcHjnHGi8V6Iu41mV34dA1TW_nW0=.783c739a-4528-4930-9339-623ee0eba030@github.com> Message-ID: On Mon, 25 Apr 2022 14:13:38 GMT, Martin Doerr wrote: >> As far as I understand the code, bool LibraryCallKit::inline_aescrypt_Block() would return false, effectively preventing the intrinsic code to be called. > > Ok, `try_to_inline` should return false. I suggest to add a comment in the `else` block. Done. See latest commit. ------------- PR: https://git.openjdk.java.net/jdk/pull/8142 From lucy at openjdk.java.net Mon Apr 25 14:35:28 2022 From: lucy at openjdk.java.net (Lutz Schmidt) Date: Mon, 25 Apr 2022 14:35:28 GMT Subject: RFR: 8278757: [s390] Implement AES Counter Mode Intrinsic [v9] In-Reply-To: References: Message-ID: > Please review (and approve, if possible) this pull request. > > This is a s390-only enhancement. It introduces the implementation of an AES-CTR intrinsic, making use of the specific s390 instruction for AES counter-mode encryption. > > Testing: SAP does no longer maintain a full build and test environment for s390. Testing is therefore limited to running some test suites (SPECjbb*, SPECjvm*) manually. But: identical code is contained in SAP's commercial product and thoroughly tested in that context. No issues were uncovered. > > @backwaterred Could you please conduct some "official" testing for this PR? > > Thank you all! > > Note: some performance figures can be found in the JBS ticket. Lutz Schmidt has updated the pull request incrementally with one additional commit since the last revision: 8278757: add clarifying comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8142/files - new: https://git.openjdk.java.net/jdk/pull/8142/files/47fbd459..b280f2e0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8142&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8142&range=07-08 Stats: 7 lines in 1 file changed: 7 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8142.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8142/head:pull/8142 PR: https://git.openjdk.java.net/jdk/pull/8142 From mdoerr at openjdk.java.net Mon Apr 25 15:48:30 2022 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Mon, 25 Apr 2022 15:48:30 GMT Subject: RFR: 8278757: [s390] Implement AES Counter Mode Intrinsic [v9] In-Reply-To: References: Message-ID: On Mon, 25 Apr 2022 14:35:28 GMT, Lutz Schmidt wrote: >> Please review (and approve, if possible) this pull request. >> >> This is a s390-only enhancement. It introduces the implementation of an AES-CTR intrinsic, making use of the specific s390 instruction for AES counter-mode encryption. >> >> Testing: SAP does no longer maintain a full build and test environment for s390. Testing is therefore limited to running some test suites (SPECjbb*, SPECjvm*) manually. But: identical code is contained in SAP's commercial product and thoroughly tested in that context. No issues were uncovered. >> >> @backwaterred Could you please conduct some "official" testing for this PR? >> >> Thank you all! >> >> Note: some performance figures can be found in the JBS ticket. > > Lutz Schmidt has updated the pull request incrementally with one additional commit since the last revision: > > 8278757: add clarifying comments LGTM. Please make sure it get thoroughly tested before integrating. ------------- Marked as reviewed by mdoerr (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8142 From coleenp at openjdk.java.net Mon Apr 25 15:55:26 2022 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Mon, 25 Apr 2022 15:55:26 GMT Subject: RFR: 8285364: Remove REF_ enum for java.lang.ref.Reference [v3] In-Reply-To: References: Message-ID: On Fri, 22 Apr 2022 09:43:45 GMT, Albert Mingkun Yang wrote: >> Simple rename and some comments update. >> >> Test: build > > Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: > > Remove REF_ enum for java.lang.ref.Reference > > Signed-off-by: Albert Yang src/hotspot/share/oops/instanceKlass.cpp line 441: > 439: > 440: // Allocation > 441: if (parser.is_java_lang_ref_Reference_subclass()) { I'm having a really hard time understanding this. java.lang.Reference now doesn't have any REF_OTHER type set. I didn't realize that a java.lang.Reference instance is a plain InstanceKlass, and not an InstanceRefKlass. Is this right? ------------- PR: https://git.openjdk.java.net/jdk/pull/8332 From lucy at openjdk.java.net Mon Apr 25 16:15:29 2022 From: lucy at openjdk.java.net (Lutz Schmidt) Date: Mon, 25 Apr 2022 16:15:29 GMT Subject: RFR: 8278757: [s390] Implement AES Counter Mode Intrinsic [v9] In-Reply-To: References: Message-ID: On Mon, 25 Apr 2022 15:45:10 GMT, Martin Doerr wrote: > LGTM. Please make sure it get thoroughly tested before integrating. Sure. Now that we have reached the fix point of the iteration, I will bring the changes back into the SAP codebase. We then have a pretty decent test coverage. In addition, I will wait for the results from @backwaterred Thanks for reviewing and for your helpful comments! ------------- PR: https://git.openjdk.java.net/jdk/pull/8142 From duke at openjdk.java.net Mon Apr 25 19:16:24 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Mon, 25 Apr 2022 19:16:24 GMT Subject: RFR: 8283643: [AIX, testbug] MachCodeFramesInErrorFile test fails to find 'Native frames' text In-Reply-To: References: Message-ID: On Tue, 19 Apr 2022 09:04:38 GMT, Martin Doerr wrote: >> I observed a failure of MachCodeFramesInErrorFile.java on AIX. The raised error complains that 'Native frames: ' is missing. To fix the failure, I made two changes to the test that allowed it to pass on AIX. >> >> The first change made was to the test's `extractFrames` method. AIX overrides `os::platform_print_native_stack` with stack printing specific to AIX/Power. This code does not produce the 'Native frames: ' text that `vmError::print_native_stack` does, so the test was modified to expect the AIX output when run on AIX. [Edit: The changes made to `extractFrames` are now minimal. I made the change to `AixNativeCallstack::print_callstack_for_context` instead.] >> >> A second change was made to the address passed to the `crashInNative1` method. AIX does not consider low-address memory to be protected as other platforms do. In fact, "the first 256 bytes are reserved for software use" according to the Power ISA. Accordingly, the read address for PPC was changed to -1 (0xFF..FF) to produce the expected failure result. >> >> ### Testing >> >> Tier1 tests complete as expected on AIX/Power. > > Looks basically good to me, but please take a look at my comments. I believe all requested changes are complete, but I don't have any reviews. Are there any changes you'd like to see before merge @TheRealMDoerr, @dougxc, or @dholmes-ora? ------------- PR: https://git.openjdk.java.net/jdk/pull/8094 From stefank at openjdk.java.net Mon Apr 25 19:40:33 2022 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Mon, 25 Apr 2022 19:40:33 GMT Subject: RFR: 8285364: Remove REF_ enum for java.lang.ref.Reference [v3] In-Reply-To: References: Message-ID: On Mon, 25 Apr 2022 15:51:35 GMT, Coleen Phillimore wrote: >> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove REF_ enum for java.lang.ref.Reference >> >> Signed-off-by: Albert Yang > > src/hotspot/share/oops/instanceKlass.cpp line 441: > >> 439: >> 440: // Allocation >> 441: if (parser.is_java_lang_ref_Reference_subclass()) { > > I'm having a really hard time understanding this. java.lang.Reference now doesn't have any REF_OTHER type set. I didn't realize that a java.lang.Reference instance is a plain InstanceKlass, and not an InstanceRefKlass. Is this right? Yes, I was also surprised by this. The java.lang.ref.Reference Klass is only an InstanceKlass, not an InstanceRefKlass. ------------- PR: https://git.openjdk.java.net/jdk/pull/8332 From dnsimon at openjdk.java.net Mon Apr 25 20:30:28 2022 From: dnsimon at openjdk.java.net (Doug Simon) Date: Mon, 25 Apr 2022 20:30:28 GMT Subject: RFR: 8283643: [AIX, testbug] MachCodeFramesInErrorFile test fails to find 'Native frames' text [v6] In-Reply-To: References: Message-ID: On Fri, 22 Apr 2022 20:18:16 GMT, Tyler Steele wrote: >> I observed a failure of MachCodeFramesInErrorFile.java on AIX. The raised error complains that 'Native frames: ' is missing. To fix the failure, I made two changes to the test that allowed it to pass on AIX. >> >> The first change made was to the test's `extractFrames` method. AIX overrides `os::platform_print_native_stack` with stack printing specific to AIX/Power. This code does not produce the 'Native frames: ' text that `vmError::print_native_stack` does, so the test was modified to expect the AIX output when run on AIX. [Edit: The changes made to `extractFrames` are now minimal. I made the change to `AixNativeCallstack::print_callstack_for_context` instead.] >> >> A second change was made to the address passed to the `crashInNative1` method. AIX does not consider low-address memory to be protected as other platforms do. In fact, "the first 256 bytes are reserved for software use" according to the Power ISA. Accordingly, the read address for PPC was changed to -1 (0xFF..FF) to produce the expected failure result. >> >> ### Testing >> >> Tier1 tests complete as expected on AIX/Power. > > Tyler Steele has updated the pull request incrementally with one additional commit since the last revision: > > Use OuputAnalyzer::reportDiagnosticSummary instead of printing directly. Marked as reviewed by dnsimon (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8094 From lancea at openjdk.java.net Mon Apr 25 20:53:26 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Mon, 25 Apr 2022 20:53:26 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v6] In-Reply-To: References: Message-ID: On Mon, 25 Apr 2022 13:19:49 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: > > - Refresh cf561073f48fad58e931a5285b92629aa83c9bd1 > - Merge with jdk-19+19 > - Refresh > - Refresh > - Refresh > - Refresh > - Merge with jdk-19+18 > - Refresh > - Initial push Test changes look good. One question/comment below ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From lancea at openjdk.java.net Mon Apr 25 20:53:28 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Mon, 25 Apr 2022 20:53:28 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v5] In-Reply-To: <3RNoPzJecSfEBdapZpbKMJZG1ep3mVUW1Z5kKNrFYSk=.821824df-3431-437a-b5c8-c4627021d349@github.com> References: <3RNoPzJecSfEBdapZpbKMJZG1ep3mVUW1Z5kKNrFYSk=.821824df-3431-437a-b5c8-c4627021d349@github.com> Message-ID: On Thu, 21 Apr 2022 11:35:57 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh test/jdk/jdk/internal/vm/Continuation/Basic.java line 327: > 325: > 326: // @Test > 327: public void testPinnedNative() { Are you disabling this test? if so, you can do `@Test(enabled=false)` ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From duke at openjdk.java.net Mon Apr 25 21:45:14 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Mon, 25 Apr 2022 21:45:14 GMT Subject: RFR: 8278757: [s390] Implement AES Counter Mode Intrinsic [v9] In-Reply-To: References: Message-ID: On Mon, 25 Apr 2022 14:35:28 GMT, Lutz Schmidt wrote: >> Please review (and approve, if possible) this pull request. >> >> This is a s390-only enhancement. It introduces the implementation of an AES-CTR intrinsic, making use of the specific s390 instruction for AES counter-mode encryption. >> >> Testing: SAP does no longer maintain a full build and test environment for s390. Testing is therefore limited to running some test suites (SPECjbb*, SPECjvm*) manually. But: identical code is contained in SAP's commercial product and thoroughly tested in that context. No issues were uncovered. >> >> @backwaterred Could you please conduct some "official" testing for this PR? >> >> Thank you all! >> >> Note: some performance figures can be found in the JBS ticket. > > Lutz Schmidt has updated the pull request incrementally with one additional commit since the last revision: > > 8278757: add clarifying comments I see I have missed a request or two to re-run these tests. Sorry to keep you waiting! The much anticipated s390x Tier1 tests are running now. Updates will appear below. --- ------------- PR: https://git.openjdk.java.net/jdk/pull/8142 From dholmes at openjdk.java.net Tue Apr 26 05:03:54 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 26 Apr 2022 05:03:54 GMT Subject: RFR: 8283643: [AIX, testbug] MachCodeFramesInErrorFile test fails to find 'Native frames' text [v6] In-Reply-To: References: Message-ID: On Fri, 22 Apr 2022 20:18:16 GMT, Tyler Steele wrote: >> I observed a failure of MachCodeFramesInErrorFile.java on AIX. The raised error complains that 'Native frames: ' is missing. To fix the failure, I made two changes to the test that allowed it to pass on AIX. >> >> The first change made was to the test's `extractFrames` method. AIX overrides `os::platform_print_native_stack` with stack printing specific to AIX/Power. This code does not produce the 'Native frames: ' text that `vmError::print_native_stack` does, so the test was modified to expect the AIX output when run on AIX. [Edit: The changes made to `extractFrames` are now minimal. I made the change to `AixNativeCallstack::print_callstack_for_context` instead.] >> >> A second change was made to the address passed to the `crashInNative1` method. AIX does not consider low-address memory to be protected as other platforms do. In fact, "the first 256 bytes are reserved for software use" according to the Power ISA. Accordingly, the read address for PPC was changed to -1 (0xFF..FF) to produce the expected failure result. >> >> ### Testing >> >> Tier1 tests complete as expected on AIX/Power. > > Tyler Steele has updated the pull request incrementally with one additional commit since the last revision: > > Use OuputAnalyzer::reportDiagnosticSummary instead of printing directly. Change seems reasonable but please fix the issue below before integrating. Thanks, David test/hotspot/jtreg/runtime/ErrorHandling/MachCodeFramesInErrorFile.java line 75: > 73: assert args[0].equals("crashInVM"); > 74: // AIX does not prohibit low address reads > 75: crashInNative1(Platform.isPPC() ? -1 : 10); Is it AIX or PPC or AIX/PPC that needs the change? The code should match the comment. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8094 From stuefe at openjdk.java.net Tue Apr 26 05:12:52 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 26 Apr 2022 05:12:52 GMT Subject: RFR: JDK-8284726: Print active locale settings in hs_err reports and in VM.info In-Reply-To: References: Message-ID: On Tue, 12 Apr 2022 06:44:41 GMT, Thomas Stuefe wrote: > To analyze locale problems in native code - e.g. stemming from third-party code calling `setlocale(3)` - it would be useful to print the active locale settings in hs-err reports and in VM.info. > > Patch notes: > - Posix is fuzzy about the exact role of LC_ALL. It defines LC_ALL as a way to set all locales in one go, but the implementation could still keep the individual categories separately and just let LC_ALL override the individual settings. Therefore I opted to print both, even though on glibc the information seems redundant. > - Since this is Posix specific, callers require #ifndef _WIN32 in shared files. That's not nice, but the alternative would be an empty stub implementation for windows, which I find also unappealing. > > Example output, Ubuntu 20.04: > > Java started with LC_ALL=C: > > thomas at starfish $ jcmd Simple VM.info | ack LC_ > LC_ALL=C > LC_ALL=C > LC_COLLATE=C > LC_CTYPE=C > LC_MESSAGES=C > LC_MONETARY=C > LC_NUMERIC=C > LC_TIME=C > > > Java started with my default system settings: > > thomas at starfish $ jcmd Simple VM.info | ack LC_ > LC_ALL=LC_CTYPE=C;LC_NUMERIC=en_DK.UTF-8;LC_TIME=en_DK.UTF-8;LC_COLLATE=C;LC_MONETARY=en_DK.UTF-8;LC_MESSAGES=C;LC_PAPER=en_DK.UTF-8;LC_NAME=en_DK.UTF-8;LC_ADDRESS=en_DK.UTF-8;LC_TELEPHONE=en_DK.UTF-8;LC_MEASUREMENT=en_DK.UTF-8;LC_IDENTIFICATION=en_DK.UTF-8 > LC_COLLATE=C > LC_CTYPE=C > LC_MESSAGES=C > LC_MONETARY=en_DK.UTF-8 > LC_NUMERIC=en_DK.UTF-8 > LC_TIME=en_DK.UTF-8 Friendly ping. This is rather trivial. ------------- PR: https://git.openjdk.java.net/jdk/pull/8194 From dholmes at openjdk.java.net Tue Apr 26 06:00:52 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 26 Apr 2022 06:00:52 GMT Subject: RFR: JDK-8284726: Print active locale settings in hs_err reports and in VM.info In-Reply-To: References: Message-ID: On Tue, 12 Apr 2022 06:44:41 GMT, Thomas Stuefe wrote: > To analyze locale problems in native code - e.g. stemming from third-party code calling `setlocale(3)` - it would be useful to print the active locale settings in hs-err reports and in VM.info. > > Patch notes: > - Posix is fuzzy about the exact role of LC_ALL. It defines LC_ALL as a way to set all locales in one go, but the implementation could still keep the individual categories separately and just let LC_ALL override the individual settings. Therefore I opted to print both, even though on glibc the information seems redundant. > - Since this is Posix specific, callers require #ifndef _WIN32 in shared files. That's not nice, but the alternative would be an empty stub implementation for windows, which I find also unappealing. > > Example output, Ubuntu 20.04: > > Java started with LC_ALL=C: > > thomas at starfish $ jcmd Simple VM.info | ack LC_ > LC_ALL=C > LC_ALL=C > LC_COLLATE=C > LC_CTYPE=C > LC_MESSAGES=C > LC_MONETARY=C > LC_NUMERIC=C > LC_TIME=C > > > Java started with my default system settings: > > thomas at starfish $ jcmd Simple VM.info | ack LC_ > LC_ALL=LC_CTYPE=C;LC_NUMERIC=en_DK.UTF-8;LC_TIME=en_DK.UTF-8;LC_COLLATE=C;LC_MONETARY=en_DK.UTF-8;LC_MESSAGES=C;LC_PAPER=en_DK.UTF-8;LC_NAME=en_DK.UTF-8;LC_ADDRESS=en_DK.UTF-8;LC_TELEPHONE=en_DK.UTF-8;LC_MEASUREMENT=en_DK.UTF-8;LC_IDENTIFICATION=en_DK.UTF-8 > LC_COLLATE=C > LC_CTYPE=C > LC_MESSAGES=C > LC_MONETARY=en_DK.UTF-8 > LC_NUMERIC=en_DK.UTF-8 > LC_TIME=en_DK.UTF-8 Seems reasonable - though the macro processing seems overkill for such a short list. :) One query below. Thanks, David src/hotspot/os/posix/os_posix.cpp line 575: > 573: const char* locale = setlocale(categories[i].c, NULL); > 574: st->print_cr("%s=%s", categories[i].name, > 575: ((locale != NULL) ? locale : "")); I can't see where the query version of setLocale is allowed to return NULL, but if it did isn't that different to being set to "" ? ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8194 From stuefe at openjdk.java.net Tue Apr 26 07:47:54 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 26 Apr 2022 07:47:54 GMT Subject: RFR: 8283643: [AIX, testbug] MachCodeFramesInErrorFile test fails to find 'Native frames' text [v6] In-Reply-To: References: Message-ID: On Tue, 26 Apr 2022 05:00:06 GMT, David Holmes wrote: >> Tyler Steele has updated the pull request incrementally with one additional commit since the last revision: >> >> Use OuputAnalyzer::reportDiagnosticSummary instead of printing directly. > > test/hotspot/jtreg/runtime/ErrorHandling/MachCodeFramesInErrorFile.java line 75: > >> 73: assert args[0].equals("crashInVM"); >> 74: // AIX does not prohibit low address reads >> 75: crashInNative1(Platform.isPPC() ? -1 : 10); > > Is it AIX or PPC or AIX/PPC that needs the change? The code should match the comment. This is AIX only, so yes, this should be restricted to AIX. ------------- PR: https://git.openjdk.java.net/jdk/pull/8094 From adinn at openjdk.java.net Tue Apr 26 08:52:47 2022 From: adinn at openjdk.java.net (Andrew Dinn) Date: Tue, 26 Apr 2022 08:52:47 GMT Subject: RFR: 8282541: AArch64: Auto-vectorize Math.round API [v6] In-Reply-To: References: Message-ID: On Wed, 20 Apr 2022 17:31:08 GMT, Andrew Haley wrote: >> Before, Apple M1: >> >> +-----------------------------------------+---------------------------------+ >> |Benchmark | (TESTSIZE) Mode Score Units| >> +-----------------------------------------+---------------------------------+ >> |FpRoundingBenchmark.test_round_double | 1024 thrpt 1612.391 ops/ms| >> |FpRoundingBenchmark.test_round_double | 2048 thrpt 804.291 ops/ms| >> |FpRoundingBenchmark.test_round_float | 1024 thrpt 1558.202 ops/ms| >> |FpRoundingBenchmark.test_round_float | 2048 thrpt 775.730 ops/ms| >> +------------------------------------------+--------------------------------+ >> >> After: >> >> +-----------------------------------------+----------------------------------+ >> |Benchmark | (TESTSIZE) Mode Score Units| >> +-----------------------------------------+----------------------------------+ >> |FpRoundingBenchmark.test_round_double | 1024 thrpt 2720.153 ops/ms| >> |FpRoundingBenchmark.test_round_double | 2048 thrpt 1371.750 ops/ms| >> |FpRoundingBenchmark.test_round_float | 1024 thrpt 5940.263 ops/ms| >> |FpRoundingBenchmark.test_round_float | 2048 thrpt 3036.201 ops/ms| >> +-----------------------------------------+----------------------------------+ >> >> About the algorithm: >> >> `Math.round()` is tricky. Its specification corresponds to no standard >> rounding mode: it "returns the closest long to the argument, with ties >> rounding to positive infinity." For positive inputs this is the same >> as IEEE-754's `convertToIntegerTiesToAway` operation, which rounds >> away from zero, but there's no equivalent for negative inputs. >> >> `Math.round()` used simply to add 0.5 and convert to integer by taking >> the floor of the result, but that wasn't right because it suffers from >> double rounding. This breaks several cases, in particular because >> >> `0.4999999... (+) 0.5 == 1.0` >> >> (Here, `(+)` indicates an addition followed by roundTiesToEven.) >> >> There is no corresponding problem with `-0.4999999...` or `-0.9999999...` >> >> Also, in the 32-bit `float` case, >> >> `8388609 (+) 0.5 == 8388610` >> >> because 8388609 (0x1.000002p+23) as a 32-bit integer has no fraction >> bits, so adding 0.5, followed by roundTiesToEven, rounds upwards. This >> problem manifests for every odd integer within the binade from >> 0x1.000002p+23 to 0x1.fffffep+23, whether positive or negative. There >> is a corresponding problem for the `double` range. >> >> The patch for JDK-8279508 handles this by flipping the floating-point >> rounding mode to roundTowardNegative, adding 0.5, and taking the >> floor. While this does work on AArch64, the performance is >> tragic. AArch64 implementations seem to wait for all instructions in >> flight to retire, change the rounding mode, and do the operation. This >> effectively serializes the entire thread. >> >> This patch takes a different approach. Firstly, we can observe that we >> can use the `frinta` instruction for the entire positive range. The >> negative range is a bit trickier, but we can observe that any x, >> abs{x) >= -0x1.000000p+23, has no fractional bits so it must be an >> integer. For convenence, we can convert that range with the `frinta` >> instruction as well. >> >> All that remains are x < 0, abs{x) < -0x1.000000p+23. Adding 0.5 >> followed by roundTiesToEven doesn't lead to a problem because for >> x < 0 && abs{x) >= 0.5, adding 0.5 only reduces the magnitude of x; >> for all x < 0 && abs{x) < 0.5, adding 0.5 followed by roundTiesToEven >> return 0. > > Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: > > Untabify This looks fine to me. ------------- Marked as reviewed by adinn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8204 From kevinw at openjdk.java.net Tue Apr 26 09:31:51 2022 From: kevinw at openjdk.java.net (Kevin Walls) Date: Tue, 26 Apr 2022 09:31:51 GMT Subject: RFR: JDK-8284726: Print active locale settings in hs_err reports and in VM.info In-Reply-To: References: Message-ID: On Tue, 12 Apr 2022 06:44:41 GMT, Thomas Stuefe wrote: > To analyze locale problems in native code - e.g. stemming from third-party code calling `setlocale(3)` - it would be useful to print the active locale settings in hs-err reports and in VM.info. > > Patch notes: > - Posix is fuzzy about the exact role of LC_ALL. It defines LC_ALL as a way to set all locales in one go, but the implementation could still keep the individual categories separately and just let LC_ALL override the individual settings. Therefore I opted to print both, even though on glibc the information seems redundant. > - Since this is Posix specific, callers require #ifndef _WIN32 in shared files. That's not nice, but the alternative would be an empty stub implementation for windows, which I find also unappealing. > > Example output, Ubuntu 20.04: > > Java started with LC_ALL=C: > > thomas at starfish $ jcmd Simple VM.info | ack LC_ > LC_ALL=C > LC_ALL=C > LC_COLLATE=C > LC_CTYPE=C > LC_MESSAGES=C > LC_MONETARY=C > LC_NUMERIC=C > LC_TIME=C > > > Java started with my default system settings: > > thomas at starfish $ jcmd Simple VM.info | ack LC_ > LC_ALL=LC_CTYPE=C;LC_NUMERIC=en_DK.UTF-8;LC_TIME=en_DK.UTF-8;LC_COLLATE=C;LC_MONETARY=en_DK.UTF-8;LC_MESSAGES=C;LC_PAPER=en_DK.UTF-8;LC_NAME=en_DK.UTF-8;LC_ADDRESS=en_DK.UTF-8;LC_TELEPHONE=en_DK.UTF-8;LC_MEASUREMENT=en_DK.UTF-8;LC_IDENTIFICATION=en_DK.UTF-8 > LC_COLLATE=C > LC_CTYPE=C > LC_MESSAGES=C > LC_MONETARY=en_DK.UTF-8 > LC_NUMERIC=en_DK.UTF-8 > LC_TIME=en_DK.UTF-8 Do you want to separate them with a header? ie. have print_active_locale do tty->print_cr "Active Local:" or similar, like when other info such as the environment is printed? Currently they are separated from the env vars by a blank line, but maybe it's not clear they are not coming from the environment. ------------- PR: https://git.openjdk.java.net/jdk/pull/8194 From stuefe at openjdk.java.net Tue Apr 26 11:55:49 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 26 Apr 2022 11:55:49 GMT Subject: RFR: JDK-8284726: Print active locale settings in hs_err reports and in VM.info In-Reply-To: References: Message-ID: On Tue, 26 Apr 2022 05:57:58 GMT, David Holmes wrote: > Seems reasonable - though the macro processing seems overkill for such a short list. :) > Hah, yes, originally I printed more LC variants, but cut down the list because probably nobody needs all of them. > One query below. > > Thanks, David > src/hotspot/os/posix/os_posix.cpp line 575: > >> 573: const char* locale = setlocale(categories[i].c, NULL); >> 574: st->print_cr("%s=%s", categories[i].name, >> 575: ((locale != NULL) ? locale : "")); > > I can't see where the query version of setLocale is allowed to return NULL, but if it did isn't that different to being set to "" ? "The return value is NULL if the request cannot be honored." linux manpage. I can print "??" instead? ------------- PR: https://git.openjdk.java.net/jdk/pull/8194 From dholmes at openjdk.java.net Tue Apr 26 12:49:55 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 26 Apr 2022 12:49:55 GMT Subject: RFR: JDK-8284726: Print active locale settings in hs_err reports and in VM.info In-Reply-To: References: Message-ID: On Tue, 26 Apr 2022 11:51:40 GMT, Thomas Stuefe wrote: >> src/hotspot/os/posix/os_posix.cpp line 575: >> >>> 573: const char* locale = setlocale(categories[i].c, NULL); >>> 574: st->print_cr("%s=%s", categories[i].name, >>> 575: ((locale != NULL) ? locale : "")); >> >> I can't see where the query version of setLocale is allowed to return NULL, but if it did isn't that different to being set to "" ? > > "The return value is NULL if the request cannot be honored." linux manpage. > I can print "??" instead? The Linux manpage is even more vague than the Posix spec. :( I'd prefer "" or "" or "" to just "??". ------------- PR: https://git.openjdk.java.net/jdk/pull/8194 From stuefe at openjdk.java.net Tue Apr 26 13:23:52 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 26 Apr 2022 13:23:52 GMT Subject: RFR: JDK-8284726: Print active locale settings in hs_err reports and in VM.info In-Reply-To: References: Message-ID: On Tue, 26 Apr 2022 09:28:47 GMT, Kevin Walls wrote: > > Do you want to separate them with a header? ie. have print_active_locale do tty->print_cr "Active Locale:" or similar, like when other info such as the environment is printed? Currently they are separated from the env vars by a blank line, but maybe it's not clear they are not coming from the environment. Sure, I can do that. ------------- PR: https://git.openjdk.java.net/jdk/pull/8194 From stuefe at openjdk.java.net Tue Apr 26 13:23:53 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 26 Apr 2022 13:23:53 GMT Subject: RFR: JDK-8284726: Print active locale settings in hs_err reports and in VM.info In-Reply-To: References: Message-ID: On Tue, 26 Apr 2022 12:46:09 GMT, David Holmes wrote: >> "The return value is NULL if the request cannot be honored." linux manpage. >> I can print "??" instead? > > The Linux manpage is even more vague than the Posix spec. :( > > I'd prefer "" or "" or "" to just "??". This comment was confusing until I read it as mail :) ------------- PR: https://git.openjdk.java.net/jdk/pull/8194 From stuefe at openjdk.java.net Tue Apr 26 13:33:44 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 26 Apr 2022 13:33:44 GMT Subject: RFR: JDK-8284726: Print active locale settings in hs_err reports and in VM.info [v2] In-Reply-To: References: Message-ID: > To analyze locale problems in native code - e.g. stemming from third-party code calling `setlocale(3)` - it would be useful to print the active locale settings in hs-err reports and in VM.info. > > Patch notes: > - Posix is fuzzy about the exact role of LC_ALL. It defines LC_ALL as a way to set all locales in one go, but the implementation could still keep the individual categories separately and just let LC_ALL override the individual settings. Therefore I opted to print both, even though on glibc the information seems redundant. > - Since this is Posix specific, callers require #ifndef _WIN32 in shared files. That's not nice, but the alternative would be an empty stub implementation for windows, which I find also unappealing. > > Example output, Ubuntu 20.04: > > Java started with LC_ALL=C: > > thomas at starfish $ jcmd Simple VM.info | ack LC_ > LC_ALL=C > LC_ALL=C > LC_COLLATE=C > LC_CTYPE=C > LC_MESSAGES=C > LC_MONETARY=C > LC_NUMERIC=C > LC_TIME=C > > > Java started with my default system settings: > > thomas at starfish $ jcmd Simple VM.info | ack LC_ > LC_ALL=LC_CTYPE=C;LC_NUMERIC=en_DK.UTF-8;LC_TIME=en_DK.UTF-8;LC_COLLATE=C;LC_MONETARY=en_DK.UTF-8;LC_MESSAGES=C;LC_PAPER=en_DK.UTF-8;LC_NAME=en_DK.UTF-8;LC_ADDRESS=en_DK.UTF-8;LC_TELEPHONE=en_DK.UTF-8;LC_MEASUREMENT=en_DK.UTF-8;LC_IDENTIFICATION=en_DK.UTF-8 > LC_COLLATE=C > LC_CTYPE=C > LC_MESSAGES=C > LC_MONETARY=en_DK.UTF-8 > LC_NUMERIC=en_DK.UTF-8 > LC_TIME=en_DK.UTF-8 Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: feedback kevin, david ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8194/files - new: https://git.openjdk.java.net/jdk/pull/8194/files/fe67a920..f168c8a9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8194&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8194&range=00-01 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8194.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8194/head:pull/8194 PR: https://git.openjdk.java.net/jdk/pull/8194 From aph at openjdk.java.net Tue Apr 26 13:47:58 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Tue, 26 Apr 2022 13:47:58 GMT Subject: Integrated: 8282541: AArch64: Auto-vectorize Math.round API In-Reply-To: References: Message-ID: <0kCtfj3gdtrf8cEoANKsd4ni42Cf_bAlOFze6go2O_g=.237d79f4-d1ce-43d1-8c0e-41ea8bbadedc@github.com> On Tue, 12 Apr 2022 13:26:02 GMT, Andrew Haley wrote: > Before, Apple M1: > > +-----------------------------------------+---------------------------------+ > |Benchmark | (TESTSIZE) Mode Score Units| > +-----------------------------------------+---------------------------------+ > |FpRoundingBenchmark.test_round_double | 1024 thrpt 1612.391 ops/ms| > |FpRoundingBenchmark.test_round_double | 2048 thrpt 804.291 ops/ms| > |FpRoundingBenchmark.test_round_float | 1024 thrpt 1558.202 ops/ms| > |FpRoundingBenchmark.test_round_float | 2048 thrpt 775.730 ops/ms| > +------------------------------------------+--------------------------------+ > > After: > > +-----------------------------------------+----------------------------------+ > |Benchmark | (TESTSIZE) Mode Score Units| > +-----------------------------------------+----------------------------------+ > |FpRoundingBenchmark.test_round_double | 1024 thrpt 2720.153 ops/ms| > |FpRoundingBenchmark.test_round_double | 2048 thrpt 1371.750 ops/ms| > |FpRoundingBenchmark.test_round_float | 1024 thrpt 5940.263 ops/ms| > |FpRoundingBenchmark.test_round_float | 2048 thrpt 3036.201 ops/ms| > +-----------------------------------------+----------------------------------+ > > About the algorithm: > > `Math.round()` is tricky. Its specification corresponds to no standard > rounding mode: it "returns the closest long to the argument, with ties > rounding to positive infinity." For positive inputs this is the same > as IEEE-754's `convertToIntegerTiesToAway` operation, which rounds > away from zero, but there's no equivalent for negative inputs. > > `Math.round()` used simply to add 0.5 and convert to integer by taking > the floor of the result, but that wasn't right because it suffers from > double rounding. This breaks several cases, in particular because > > `0.4999999... (+) 0.5 == 1.0` > > (Here, `(+)` indicates an addition followed by roundTiesToEven.) > > There is no corresponding problem with `-0.4999999...` or `-0.9999999...` > > Also, in the 32-bit `float` case, > > `8388609 (+) 0.5 == 8388610` > > because 8388609 (0x1.000002p+23) as a 32-bit integer has no fraction > bits, so adding 0.5, followed by roundTiesToEven, rounds upwards. This > problem manifests for every odd integer within the binade from > 0x1.000002p+23 to 0x1.fffffep+23, whether positive or negative. There > is a corresponding problem for the `double` range. > > The patch for JDK-8279508 handles this by flipping the floating-point > rounding mode to roundTowardNegative, adding 0.5, and taking the > floor. While this does work on AArch64, the performance is > tragic. AArch64 implementations seem to wait for all instructions in > flight to retire, change the rounding mode, and do the operation. This > effectively serializes the entire thread. > > This patch takes a different approach. Firstly, we can observe that we > can use the `frinta` instruction for the entire positive range. The > negative range is a bit trickier, but we can observe that any x, > abs{x) >= -0x1.000000p+23, has no fractional bits so it must be an > integer. For convenence, we can convert that range with the `frinta` > instruction as well. > > All that remains are x < 0, abs{x) < -0x1.000000p+23. Adding 0.5 > followed by roundTiesToEven doesn't lead to a problem because for > x < 0 && abs{x) >= 0.5, adding 0.5 only reduces the magnitude of x; > for all x < 0 && abs{x) < 0.5, adding 0.5 followed by roundTiesToEven > return 0. This pull request has now been integrated. Changeset: a7b51573 Author: Andrew Haley URL: https://git.openjdk.java.net/jdk/commit/a7b5157375f3691a7425f15a78cd5411776b9331 Stats: 1210 lines in 20 files changed: 599 ins; 13 del; 598 mod 8282541: AArch64: Auto-vectorize Math.round API Reviewed-by: njian, ngasson, adinn ------------- PR: https://git.openjdk.java.net/jdk/pull/8204 From eosterlund at openjdk.java.net Tue Apr 26 13:51:17 2022 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Tue, 26 Apr 2022 13:51:17 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v6] In-Reply-To: References: Message-ID: <3euEQy5Mq4sADeywuO86A4TGzStWEaaRyEHdZRCoPao=.593b7f97-4ce1-44fb-a77d-5677a34ce2a8@github.com> On Mon, 25 Apr 2022 13:19:49 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: > > - Refresh cf561073f48fad58e931a5285b92629aa83c9bd1 > - Merge with jdk-19+19 > - Refresh > - Refresh > - Refresh > - Refresh > - Merge with jdk-19+18 > - Refresh > - Initial push I have done a long and extensive hands-on review of most of the JVM code (excluding most of the JVMTI changes). There is still room for improvements, but I think this is in a good enough shape to be integrated now, plus minus some patches in the ether between the fibers branch and this PR which I'm sure will pop up soon. So this looks good to me. Ship it! ------------- Marked as reviewed by eosterlund (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8166 From duke at openjdk.java.net Tue Apr 26 14:07:50 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Tue, 26 Apr 2022 14:07:50 GMT Subject: RFR: 8283643: [AIX, testbug] MachCodeFramesInErrorFile test fails to find 'Native frames' text [v6] In-Reply-To: References: Message-ID: On Tue, 26 Apr 2022 07:44:19 GMT, Thomas Stuefe wrote: >> test/hotspot/jtreg/runtime/ErrorHandling/MachCodeFramesInErrorFile.java line 75: >> >>> 73: assert args[0].equals("crashInVM"); >>> 74: // AIX does not prohibit low address reads >>> 75: crashInNative1(Platform.isPPC() ? -1 : 10); >> >> Is it AIX or PPC or AIX/PPC that needs the change? The code should match the comment. > > This is AIX only, so yes, this should be restricted to AIX. I remember changing this now. It's actually PPC. The Power ISA specifies that the first 256 bytes are 'reserved for software use'. I'll change the comment. ------------- PR: https://git.openjdk.java.net/jdk/pull/8094 From duke at openjdk.java.net Tue Apr 26 14:15:32 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Tue, 26 Apr 2022 14:15:32 GMT Subject: RFR: 8283643: [AIX, testbug] MachCodeFramesInErrorFile test fails to find 'Native frames' text [v7] In-Reply-To: References: Message-ID: > I observed a failure of MachCodeFramesInErrorFile.java on AIX. The raised error complains that 'Native frames: ' is missing. To fix the failure, I made two changes to the test that allowed it to pass on AIX. > > The first change made was to the test's `extractFrames` method. AIX overrides `os::platform_print_native_stack` with stack printing specific to AIX/Power. This code does not produce the 'Native frames: ' text that `vmError::print_native_stack` does, so the test was modified to expect the AIX output when run on AIX. [Edit: The changes made to `extractFrames` are now minimal. I made the change to `AixNativeCallstack::print_callstack_for_context` instead.] > > A second change was made to the address passed to the `crashInNative1` method. AIX does not consider low-address memory to be protected as other platforms do. In fact, "the first 256 bytes are reserved for software use" according to the Power ISA. Accordingly, the read address for PPC was changed to -1 (0xFF..FF) to produce the expected failure result. > > ### Testing > > Tier1 tests complete as expected on AIX/Power. Tyler Steele has updated the pull request incrementally with one additional commit since the last revision: Fix comment ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8094/files - new: https://git.openjdk.java.net/jdk/pull/8094/files/d0a05457..4257f8ec Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8094&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8094&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8094.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8094/head:pull/8094 PR: https://git.openjdk.java.net/jdk/pull/8094 From duke at openjdk.java.net Tue Apr 26 14:15:34 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Tue, 26 Apr 2022 14:15:34 GMT Subject: RFR: 8283643: [AIX, testbug] MachCodeFramesInErrorFile test fails to find 'Native frames' text [v6] In-Reply-To: References: Message-ID: On Fri, 22 Apr 2022 20:18:16 GMT, Tyler Steele wrote: >> I observed a failure of MachCodeFramesInErrorFile.java on AIX. The raised error complains that 'Native frames: ' is missing. To fix the failure, I made two changes to the test that allowed it to pass on AIX. >> >> The first change made was to the test's `extractFrames` method. AIX overrides `os::platform_print_native_stack` with stack printing specific to AIX/Power. This code does not produce the 'Native frames: ' text that `vmError::print_native_stack` does, so the test was modified to expect the AIX output when run on AIX. [Edit: The changes made to `extractFrames` are now minimal. I made the change to `AixNativeCallstack::print_callstack_for_context` instead.] >> >> A second change was made to the address passed to the `crashInNative1` method. AIX does not consider low-address memory to be protected as other platforms do. In fact, "the first 256 bytes are reserved for software use" according to the Power ISA. Accordingly, the read address for PPC was changed to -1 (0xFF..FF) to produce the expected failure result. >> >> ### Testing >> >> Tier1 tests complete as expected on AIX/Power. > > Tyler Steele has updated the pull request incrementally with one additional commit since the last revision: > > Use OuputAnalyzer::reportDiagnosticSummary instead of printing directly. Thanks very much for your reviews and comments. ------------- PR: https://git.openjdk.java.net/jdk/pull/8094 From stuefe at openjdk.java.net Tue Apr 26 14:26:54 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 26 Apr 2022 14:26:54 GMT Subject: RFR: 8283643: [AIX, testbug] MachCodeFramesInErrorFile test fails to find 'Native frames' text [v6] In-Reply-To: References: Message-ID: On Tue, 26 Apr 2022 14:04:48 GMT, Tyler Steele wrote: >> This is AIX only, so yes, this should be restricted to AIX. > > I remember changing this now. It's actually PPC. The Power ISA specifies that the first 256 bytes are 'reserved for software use'. > > I'll change the comment. Really? I was always assuming the linux kernel handles this differently. ------------- PR: https://git.openjdk.java.net/jdk/pull/8094 From mdoerr at openjdk.java.net Tue Apr 26 15:11:49 2022 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Tue, 26 Apr 2022 15:11:49 GMT Subject: RFR: 8283643: [AIX, testbug] MachCodeFramesInErrorFile test fails to find 'Native frames' text [v6] In-Reply-To: References: Message-ID: On Tue, 26 Apr 2022 14:23:14 GMT, Thomas Stuefe wrote: >> I remember changing this now. It's actually PPC. The Power ISA specifies that the first 256 bytes are 'reserved for software use'. >> >> I'll change the comment. > > Really? I was always assuming the linux kernel handles this differently. I think the mentioned Power ISA chapter addresses real addresses, not the user mode virtual address space. We always get SIGSEGV when accessing the first page on linux. ------------- PR: https://git.openjdk.java.net/jdk/pull/8094 From stuefe at openjdk.java.net Tue Apr 26 15:28:55 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 26 Apr 2022 15:28:55 GMT Subject: RFR: 8283643: [AIX, testbug] MachCodeFramesInErrorFile test fails to find 'Native frames' text [v6] In-Reply-To: References: Message-ID: On Tue, 26 Apr 2022 15:08:51 GMT, Martin Doerr wrote: >> Really? I was always assuming the linux kernel handles this differently. > > I think the mentioned Power ISA chapter addresses real addresses, not the user mode virtual address space. We always get SIGSEGV when accessing the first page on linux. Thanks for clarifying! ------------- PR: https://git.openjdk.java.net/jdk/pull/8094 From duke at openjdk.java.net Tue Apr 26 15:28:55 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Tue, 26 Apr 2022 15:28:55 GMT Subject: Integrated: 8283643: [AIX, testbug] MachCodeFramesInErrorFile test fails to find 'Native frames' text In-Reply-To: References: Message-ID: <0J47BgAIMg3ksnNlfN_MhCZuMl7cMU1ITk8UkoDvJwo=.578d5498-81b5-4f0c-8c45-f53dfc9c1a53@github.com> On Mon, 4 Apr 2022 15:47:06 GMT, Tyler Steele wrote: > I observed a failure of MachCodeFramesInErrorFile.java on AIX. The raised error complains that 'Native frames: ' is missing. To fix the failure, I made two changes to the test that allowed it to pass on AIX. > > The first change made was to the test's `extractFrames` method. AIX overrides `os::platform_print_native_stack` with stack printing specific to AIX/Power. This code does not produce the 'Native frames: ' text that `vmError::print_native_stack` does, so the test was modified to expect the AIX output when run on AIX. [Edit: The changes made to `extractFrames` are now minimal. I made the change to `AixNativeCallstack::print_callstack_for_context` instead.] > > A second change was made to the address passed to the `crashInNative1` method. AIX does not consider low-address memory to be protected as other platforms do. In fact, "the first 256 bytes are reserved for software use" according to the Power ISA. Accordingly, the read address for PPC was changed to -1 (0xFF..FF) to produce the expected failure result. > > ### Testing > > Tier1 tests complete as expected on AIX/Power. This pull request has now been integrated. Changeset: 97a0a292 Author: Tyler Steele Committer: Thomas Stuefe URL: https://git.openjdk.java.net/jdk/commit/97a0a292a6950a3d0a7928d5ac439670c84f0dbe Stats: 14 lines in 2 files changed: 4 ins; 2 del; 8 mod 8283643: [AIX, testbug] MachCodeFramesInErrorFile test fails to find 'Native frames' text Reviewed-by: dnsimon, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/8094 From lucy at openjdk.java.net Tue Apr 26 15:36:05 2022 From: lucy at openjdk.java.net (Lutz Schmidt) Date: Tue, 26 Apr 2022 15:36:05 GMT Subject: RFR: 8278757: [s390] Implement AES Counter Mode Intrinsic [v9] In-Reply-To: References: Message-ID: <0yWEdqyEN90vkl56PLhVFcfBK1oaUcDnTaC9NDSh0fA=.afc1c37f-0f4e-4903-939e-0dabb07daec6@github.com> On Mon, 25 Apr 2022 21:42:39 GMT, Tyler Steele wrote: >> Lutz Schmidt has updated the pull request incrementally with one additional commit since the last revision: >> >> 8278757: add clarifying comments > > I see I have missed a request or two to re-run these tests. Sorry to keep you waiting! The much anticipated s390x Tier1 tests are running now. Updates will appear below. > > --- > > > # newfailures.txt > compiler/c2/irTests/TestAutoVectorization2DArray.java > > > The results completed overnight. It's just our old friend that failed. Looking good @RealLucy. @backwaterred Wonderful. SAP-internal testing will commence tonight. Will update this comment with results. ------------- PR: https://git.openjdk.java.net/jdk/pull/8142 From duke at openjdk.java.net Tue Apr 26 16:27:33 2022 From: duke at openjdk.java.net (Evgeny Astigeevich) Date: Tue, 26 Apr 2022 16:27:33 GMT Subject: RFR: 8285487: Do not generate trampolines for runtime calls if they are not needed Message-ID: [JDK-8280872](https://bugs.openjdk.java.net/browse/JDK-8280872) put the non-nmethod segment between two others. It made trampolines for runtime calls redundant in most cases. This PR uses `target_needs_far_branch()` for runtime calls to check whether they need trampolines. Trampolines are not generated if they are not needed. Testing: - `tier1`...`tier4`: Passed - `compiler/c2/aarch64/TestTrampoline.java`: Passed Note: `compiler/c2/aarch64/TestTrampoline.java` requires the release build. This is because debug builds have the branch range set to 2M which causes always generation of trampolines. ------------- Commit messages: - Remove debug code - 8285487: Do not generate trampolines for runtime calls if they are not needed Changes: https://git.openjdk.java.net/jdk/pull/8403/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8403&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8285487 Stats: 120 lines in 2 files changed: 118 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8403.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8403/head:pull/8403 PR: https://git.openjdk.java.net/jdk/pull/8403 From alanb at openjdk.java.net Tue Apr 26 17:27:35 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 26 Apr 2022 17:27:35 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v7] In-Reply-To: References: Message-ID: > This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. > > We will refresh this PR periodically to pick up changes and fixes from the loom repo. > > Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. > > The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. > > There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. > > The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. > > The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: Refresh 8d8f0a2fd646e57fe6b4e8ab669f836dc46dda69 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8166/files - new: https://git.openjdk.java.net/jdk/pull/8166/files/05781877..0864cb09 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8166&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8166&range=05-06 Stats: 582 lines in 34 files changed: 285 ins; 128 del; 169 mod Patch: https://git.openjdk.java.net/jdk/pull/8166.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8166/head:pull/8166 PR: https://git.openjdk.java.net/jdk/pull/8166 From duke at openjdk.java.net Tue Apr 26 18:10:52 2022 From: duke at openjdk.java.net (Evgeny Astigeevich) Date: Tue, 26 Apr 2022 18:10:52 GMT Subject: RFR: 8285487: Do not generate trampolines for runtime calls if they are not needed In-Reply-To: References: Message-ID: On Tue, 26 Apr 2022 16:14:44 GMT, Evgeny Astigeevich wrote: > [JDK-8280872](https://bugs.openjdk.java.net/browse/JDK-8280872) put the non-nmethod segment between two others. It made trampolines for runtime calls redundant in most cases. > > This PR uses `target_needs_far_branch()` for runtime calls to check whether they need trampolines. Trampolines are not generated if they are not needed. > > Testing: > - `tier1`...`tier4`: Passed > - `compiler/c2/aarch64/TestTrampoline.java`: Passed > > Note: `compiler/c2/aarch64/TestTrampoline.java` requires the release build. This is because debug builds have the branch range set to 2M which causes always generation of trampolines. @simonis, @bulasevich Could you please review? ------------- PR: https://git.openjdk.java.net/jdk/pull/8403 From ioi.lam at oracle.com Tue Apr 26 18:12:02 2022 From: ioi.lam at oracle.com (Ioi Lam) Date: Tue, 26 Apr 2022 11:12:02 -0700 Subject: [RFC 8285277] - How should the JVM handle container memory limits In-Reply-To: References: <955f87a4-333d-eabe-aba4-2c302075b99a@oracle.com> Message-ID: <7baf6243-150c-2432-9540-a27e4ca1c90c@oracle.com> On 4/21/2022 2:49 AM, Severin Gehwolf wrote: > On Wed, 2022-04-20 at 11:09 -0700, Ioi Lam wrote: >> I would like to have a discussion on how (or whether) the JVM should >> handle container memory limits -- see JDK-8285277 [1] > It does handle container memory limits. os::physical_memory() returns > the container limit instead of the host value if a container limit is > in place. That was one big aspect of JDK-8146115 when it was done in > JDK 10 timeframe. See: > > https://github.com/openjdk/jdk/blob/fa04d1f832ff201248f935939fa255988053a1d0/src/hotspot/os/linux/os_linux.cpp#L217..L232 > > What am I missing? Yes, the container support code does expose the memory limit through APIs like os::physical_memory(), and we use the same ergonomic logic as if we are running on a physical machine with a small amount of RAM. However, I am wondering if we need to reconsider our logic if the "physical memory" is unusually small. Currently, the ergonomic code will set the heap size to a "sensible" fraction of os::physical_memory(). This usually works fine on modern day machines with lots of RAM and swap. Even the below-$100 windows laptops have at least 4GB. On my 64GB box, max heap is set to 16GB by default. This should be enough for most apps, and will practically never be killed by OOM unless the system is really overloaded. ================ $ java -XX:+PrintFlagsFinal --version | egrep '((MaxHeapSize)|(InitialHeapSize))' ?? size_t InitialHeapSize????????????????????????? = 1056964608??????????????????????????????? {product} {ergonomic} ?? size_t MaxHeapSize????????????????????????????? = 16869490688?????????????????????????????? {product} {ergonomic} ================ But inside a container that has only a 128MB limit (which might be "typical" for micro-services??) ================ $ java -XX:+PrintFlagsFinal --version | egrep '((MaxHeapSize)|(InitialHeapSize))' ?? size_t InitialHeapSize????????????????????????? = 8388608?????????????????????????????????? {product} {ergonomic} ?? size_t MaxHeapSize????????????????????????????? = 67108864????????????????????????????????? {product} {ergonomic} ================ The default MaxHeapSize seems wasteful. We are paying for 128MB but really just use 64MB of heap. I am able to start with a 108MB heap size without getting killed. ====================== $ java -XshowSettings:system -Xms108m -XX:+AlwaysPreTouch --version Operating System Metrics: ??? Provider: cgroupv1 ? ? .... ??? Memory Limit: 128.00M ??? Memory Soft Limit: Unlimited ??? Memory & Swap Limit: 128.00M java 19-internal 2022-09-20 Java(TM) SE Runtime Environment (build 19-internal-adhoc.iklam) Java HotSpot(TM) 64-Bit Server VM (build 19-internal-adhoc.iklam, mixed mode, sharing) ========================== The problem is - If we want to efficiently use all the memory we paid for in a container, we need to tune the VM parameters manually - But tuning is very difficult and error prone. With the 100mb heap setting, my app could easily be killed if it uses too much memory in malloc, native buffers, or even the JIT. Currently we don't fail early (no check of -Xms, -Xmx, etc, against available memory), and don't fail predictably. So, I am wondering if there's anything we can do to make Java both safe and efficient when running under an small memory budget. Thanks - Ioi >> The JVM may be terminated by the Linux OOM killer if it tries to use >> more memory than the memory limit specified for a container. JDK-8284900 >> [2] tries to avoid OOM by checking InitialHeapSize against the memory >> limit. However, this is incomplete because the JVM can use memory in >> other ways: >> >> - If -Xmx is larger than -Xms, the heap may expand >> - malloc memory >> - code cache >> - thread stacks > JDK-8284900 is somewhat a special case which, IIUIC, tries to avoid > user-errors detectable at JVM startup. For example setting -Xms to a > value >= physical memory (including swap). In this case the JVM would > be at risk to get killed by the OOM killer and doing this check on > start-up would catch it before it comes to it. > > On the other hand, I don't see any handling of such a case on a > *physical* machine. Consider a machine with 8GB of RAM and somebody > spawning a JVM with -Xms8g on it. It'll happily oblige? In one of my > VMs with 8GB I see this: > > $ ./jdk19-jdk/bin/java -Xms8g -XX:+PrintFlagsFinal -version 2>&1 | grep InitialHeapSize > size_t InitialHeapSize = 8589934592 {product} {command line} > $ free --giga > total used free shared buff/cache available > Mem: 8 0 7 0 0 7 > Swap: 8 0 8 > >> We have several choices: >> >> (a) Following the direction of JDK-8284900, check for the initial memory >> usage? of other types of memory as well. The problem with this is that >> checking the "initial" usage some type of memory usage (malloc or stack) >> is difficult or impossible. >> >> (b) Avoid committing more memory when the total memory usage is close to >> the limit. E.g., avoid expanding the Java heap, or return NULL from >> os::malloc(). The problem is that some operations in the VM cannot >> handle malloc failure and will terminate the VM anyway. Also, trying to >> obey the memory limit with concurrent allocator/deallocator threads is >> probably difficult or impossible. >> >> (c) Do not consider the memory limit and let the VM be killed by the OOM >> killer. This may be what the user wants -- the user knows that the app >> will normally run within the memory limit, so if the heap expands too >> much the app probably has a memory leak and should be killed, to be >> automatically restarted by an external mechanism (such as Kubernetes). > Neither of the above? > > It would perhaps make sense to do some sanitiy checks on JVM start-up > (somewhat akin to JDK-8284900). But this should probably be done with > the main operating system API. Not using OSContainer API as proposed in > JDK-8284900. For example, print a warning if MaxHeapSize, > InitialHeapSize and MinHeapSize are larger than the reported physical > memory (and/or cap it at a lower size if so). > > Isn't (b) being handled by setting os::pysical_memory() and > os::available_memory() to the container limits (which we currently do)? > It would behave similarly to a physical machine running out of memory, > no? > > Thanks, > Severin > > >> [1] https://bugs.openjdk.java.net/browse/JDK-8285277 >> [2] https://bugs.openjdk.java.net/browse/JDK-8284900 >> From dfuchs at openjdk.java.net Tue Apr 26 19:02:19 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 26 Apr 2022 19:02:19 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v7] In-Reply-To: References: Message-ID: On Tue, 26 Apr 2022 17:27:35 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh 8d8f0a2fd646e57fe6b4e8ab669f836dc46dda69 src/java.base/share/classes/sun/nio/ch/DatagramChannelImpl.java line 770: > 768: synchronized (p) { > 769: DatagramPackets.setLength(p, n); > 770: p.setSocketAddress(sender); Hmmm... For integrity it might be better to call the public `DatagramPacket::setData(byte[] buf, int offset, int length)` method here now. The additional advantage is that the private access to `DatagramPackets.setLength(p, n);` will no longer be needed. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From prr at openjdk.java.net Wed Apr 27 04:39:43 2022 From: prr at openjdk.java.net (Phil Race) Date: Wed, 27 Apr 2022 04:39:43 GMT Subject: RFR: 8285149: Using HashMap.newHashMap to replace new HashMap(int) [v4] In-Reply-To: References: Message-ID: On Sat, 23 Apr 2022 14:34:58 GMT, XenoAmess wrote: >> These are the changes that too many to be reviewed in 8186958, thus split some of them out. > > XenoAmess has updated the pull request incrementally with two additional commits since the last revision: > > - maintains compatibility with jdk1.4 for TextTests > - fix missed space after '=' I'm getting a bit tired of seeing these JDK wide changes with lots of files touched. Delete all changes in desktop from this PR and re-submit them as a separate PR. Also do not change J2DBench. We deliberately avoid using new API so that we can take it and run it on very old JDK versions to help track regressions. ------------- PR: https://git.openjdk.java.net/jdk/pull/8301 From duke at openjdk.java.net Wed Apr 27 05:18:43 2022 From: duke at openjdk.java.net (XenoAmess) Date: Wed, 27 Apr 2022 05:18:43 GMT Subject: RFR: 8285149: Using HashMap.newHashMap to replace new HashMap(int) [v4] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 04:36:37 GMT, Phil Race wrote: > I'm getting a bit tired of seeing these JDK wide changes with lots of files touched. @prrace I'm also a bit tired of seeing so many amazing mis-use in existed codes in jdk. In some place I even see somebody creates a HashMap with factor = 10. I felt my eyes widen and likes seeing a new world or something, then I suddenly notice that he the writer might not have the ability to use HashMap, but use it just as HashTable. Nevermind. > Delete all changes in desktop from this PR and re-submit them as a separate PR. > > Also do not change J2DBench. We deliberately avoid using new API so that we can take it and run it on very old JDK versions to help track regressions. Will do 10+ hours later when I off work. ------------- PR: https://git.openjdk.java.net/jdk/pull/8301 From alanb at openjdk.java.net Wed Apr 27 06:26:50 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 27 Apr 2022 06:26:50 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v7] In-Reply-To: References: Message-ID: On Tue, 26 Apr 2022 18:58:23 GMT, Daniel Fuchs wrote: >> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: >> >> Refresh 8d8f0a2fd646e57fe6b4e8ab669f836dc46dda69 > > src/java.base/share/classes/sun/nio/ch/DatagramChannelImpl.java line 770: > >> 768: synchronized (p) { >> 769: DatagramPackets.setLength(p, n); >> 770: p.setSocketAddress(sender); > > Hmmm... For integrity it might be better to call the public `DatagramPacket::setData(byte[] buf, int offset, int length)` method here now. The additional advantage is that the private access to `DatagramPackets.setLength(p, n);` will no longer be needed. DatagramPackets.setLength is not really new, it's just moved. There's a flaw in DatagramPacket that forces its usage - the details are in JDK-8232817. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From rpressler at openjdk.java.net Wed Apr 27 07:36:00 2022 From: rpressler at openjdk.java.net (Ron Pressler) Date: Wed, 27 Apr 2022 07:36:00 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v5] In-Reply-To: References: <3RNoPzJecSfEBdapZpbKMJZG1ep3mVUW1Z5kKNrFYSk=.821824df-3431-437a-b5c8-c4627021d349@github.com> Message-ID: On Mon, 25 Apr 2022 20:48:54 GMT, Lance Andersen wrote: >> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: >> >> Refresh > > test/jdk/jdk/internal/vm/Continuation/Basic.java line 327: > >> 325: >> 326: // @Test >> 327: public void testPinnedNative() { > > Are you disabling this test? if so, you can do `@Test(enabled=false)` I updated the test and enabled it. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From lucy at openjdk.java.net Wed Apr 27 08:00:42 2022 From: lucy at openjdk.java.net (Lutz Schmidt) Date: Wed, 27 Apr 2022 08:00:42 GMT Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee In-Reply-To: References: Message-ID: On Thu, 31 Mar 2022 15:45:05 GMT, Jaroslav Bachorik wrote: > A gist of the fix is to allow relaxed instantiation of a frame when done from a signal handler - eg. for profiling purposes. > > Currently, a frame instantiation will fail on guarantee when we happen to hit a zombie method which is still on stack. While this would indicate a serious error for the normal execution flow, in case of profiling where the executing thread can be expected at any possible method this is something which may happen and we really should not take the profiled JVM down due to it. > > The behaviour defaults to checking the code blob status in the guarantee so nothing will change for the rest of the callers - just ASGCT will be affected. > >

> Unfortunately, I am not able to create a simple reproducer for the crash other that testing in our production where the crash is happening sporadically. > However, thanks to @parttimenerd and his [ASGCT stress test](https://github.com/parttimenerd/asgct2-tester.git) the problem can be reproduced quite reliably. This is not a complete review yet, just some general remarks. While I absolutely appreciate the tedious work and time you invested, I dislike the widespread nature of your changes. This is not just your fault. Your changes only make deficiencies in the code layout really obvious. Did you spend a thought on consolidating e.g. the changes in `os_cpu` into a common file, potentially in `os/linux` or, even better, `os/posix`? The` cpu` tree is begging for consolidation as well. Maybe most of the init stuff can be done in `runtime/frame.*`? While browsing through the changes, I found that in `pd_get_top_frame()`, the code is inconsistent. Some instances provide special handling for `#if COMPILER2_OR_JVMCI`, others only for `#if COMPILER2`, and sometimes there is no special handling at all. We should either have it everywhere or nowhere. Furthermore, I would prefer to see only one syntactical form, either `#if`, or `#ifdef` or `#if defined()`. Please note the subtle differences! I added a few inline comments where the code needs some TLC. src/hotspot/cpu/aarch64/frame_aarch64.inline.hpp line 52: > 50: assert(pauth_ptr_is_raw(pc), "cannot be signed"); > 51: intptr_t a = intptr_t(sp); > 52: intptr_t b = intptr_t(fp); What are these declarations good for? src/hotspot/cpu/aarch64/frame_aarch64.inline.hpp line 58: > 56: _pc = pc; > 57: assert(pc != NULL, "no pc?"); > 58: if (!forSignalHandler) { Indentation? src/hotspot/cpu/aarch64/frame_aarch64.inline.hpp line 58: > 56: _pc = pc; > 57: assert(pc != NULL, "no pc?"); > 58: if (!forSignalHandler) { Indentation? ------------- Changes requested by lucy (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8061 From rehn at openjdk.java.net Wed Apr 27 08:46:55 2022 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 27 Apr 2022 08:46:55 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v7] In-Reply-To: References: Message-ID: On Tue, 26 Apr 2022 17:27:35 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh 8d8f0a2fd646e57fe6b4e8ab669f836dc46dda69 I have looked mostly on runtime, and to much lesser extent the others parts. There are some loose ends, but nothing major that can't wait, so I think it's time. Looks fine, thanks. ------------- Marked as reviewed by rehn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8166 From bulasevich at openjdk.java.net Wed Apr 27 08:47:33 2022 From: bulasevich at openjdk.java.net (Boris Ulasevich) Date: Wed, 27 Apr 2022 08:47:33 GMT Subject: RFR: 8285487: Do not generate trampolines for runtime calls if they are not needed In-Reply-To: References: Message-ID: On Tue, 26 Apr 2022 16:14:44 GMT, Evgeny Astigeevich wrote: > [JDK-8280872](https://bugs.openjdk.java.net/browse/JDK-8280872) put the non-nmethod segment between two others. It made trampolines for runtime calls redundant in most cases. > > This PR uses `target_needs_far_branch()` for runtime calls to check whether they need trampolines. Trampolines are not generated if they are not needed. > > Testing: > - `tier1`...`tier4`: Passed > - `compiler/c2/aarch64/TestTrampoline.java`: Passed > > Note: `compiler/c2/aarch64/TestTrampoline.java` requires the release build. This is because debug builds have the branch range set to 2M which causes always generation of trampolines. src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 406: > 404: // If CodeCache size > 128M, such calls must have reserved trampolines for the case: > 405: // C2 compiled method calls C1 compiled method. > 406: return (entry.rspec().type() == relocInfo::runtime_call_type) ? target_needs_far_branch(entry.target()) Why is target_needs_far_branch() applied for runtime_call_type only? test/hotspot/jtreg/compiler/c2/aarch64/TestTrampoline.java line 57: > 55: // As the non-nmethod segment is put between other two segments, > 56: // ReservedCodeCacheSize=240M guarantees no trampolines for runtime calls to the non-nmethod segment. > 57: command.add("-XX:ReservedCodeCacheSize=240M"); To reduce memory load on the test machines, I would reduce the ReservedCodeCacheSize to 140M. Minor stylistic comment: let us remove empty lines 59, 61, 63, 65, 67 below. ------------- PR: https://git.openjdk.java.net/jdk/pull/8403 From sspitsyn at openjdk.java.net Wed Apr 27 09:36:16 2022 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 27 Apr 2022 09:36:16 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v7] In-Reply-To: References: Message-ID: On Tue, 26 Apr 2022 17:27:35 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh 8d8f0a2fd646e57fe6b4e8ab669f836dc46dda69 I've reviewed JDI, JDB and JDWP changes. All look good. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8166 From stefank at openjdk.java.net Wed Apr 27 09:52:43 2022 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Wed, 27 Apr 2022 09:52:43 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v7] In-Reply-To: References: Message-ID: On Tue, 26 Apr 2022 17:27:35 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh 8d8f0a2fd646e57fe6b4e8ab669f836dc46dda69 Similar comments to @fisk. This is what I've been focusing on: * In-depth: gc/, oops/, memory/, utilities/ * Partially: runtime/ * Cleanups: hotspot/ ------------- Marked as reviewed by stefank (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8166 From tschatzl at openjdk.java.net Wed Apr 27 10:00:39 2022 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Wed, 27 Apr 2022 10:00:39 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v7] In-Reply-To: References: Message-ID: On Tue, 26 Apr 2022 17:27:35 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh 8d8f0a2fd646e57fe6b4e8ab669f836dc46dda69 Reviewed changes in gc/, oops/, memory/, partially in runtime/. ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8166 From mcimadamore at openjdk.java.net Wed Apr 27 10:25:34 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 27 Apr 2022 10:25:34 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v31] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/424 Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 50 commits: - Merge branch 'master' into foreign-preview - Add ValueLayout changes - Tweak support for array element var handle - Add @see - Initial push - Remove whitespaces - Drop `UnsupportedOperationException` from throws clause in FileChannel/FileChannelImpl - Add @ForceInline annotation on session accessor Beef up UnrolledAccess benchmark - Use a less expensive array element alignment check The bit to byte conversion shows up in hot paths - Fix UnrolledAccess benchmark - ... and 40 more: https://git.openjdk.java.net/jdk/compare/72f82dd7...746de5ce ------------- Changes: https://git.openjdk.java.net/jdk/pull/7888/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=30 Stats: 65314 lines in 367 files changed: 43344 ins; 19432 del; 2538 mod Patch: https://git.openjdk.java.net/jdk/pull/7888.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888 PR: https://git.openjdk.java.net/jdk/pull/7888 From thartmann at openjdk.java.net Wed Apr 27 10:32:59 2022 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Wed, 27 Apr 2022 10:32:59 GMT Subject: RFR: 8285301: C2: assert(!requires_atomic_access) failed: can't ensure atomicity Message-ID: We hit asserts in `BarrierSetC2::load_at_resolved` and `BarrierSetC2::store_at_resolved` when running with `-XX:+AlwaysAtomicAccesses` because the corresponding code paths have not been implemented yet. Although the assert triggers on all platforms, it only affects long and double accesses on 32-bit systems (everything else is atomic anyway). I moved the `requires_atomic_access` logic into `LoadNode::make` and `StoreNode::make` and refactored related code. I noticed that `LoadNode::convert_to_reinterpret_load` and `StoreNode::convert_to_reinterpret_store` did not properly check for `requires_atomic_access` and fixed that as well. I'm currently running all tests with `-XX:+AlwaysAtomicAccesses`. Thanks, Tobias ------------- Commit messages: - 8285301: C2: assert(\!requires_atomic_access) failed: can't ensure atomicity Changes: https://git.openjdk.java.net/jdk/pull/8422/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8422&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8285301 Stats: 194 lines in 11 files changed: 54 ins; 79 del; 61 mod Patch: https://git.openjdk.java.net/jdk/pull/8422.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8422/head:pull/8422 PR: https://git.openjdk.java.net/jdk/pull/8422 From lancea at openjdk.java.net Wed Apr 27 10:37:46 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Wed, 27 Apr 2022 10:37:46 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v7] In-Reply-To: References: Message-ID: On Tue, 26 Apr 2022 17:27:35 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh 8d8f0a2fd646e57fe6b4e8ab669f836dc46dda69 I have been through all of the tests and they look good. ------------- Marked as reviewed by lancea (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8166 From dfuchs at openjdk.java.net Wed Apr 27 11:38:50 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 27 Apr 2022 11:38:50 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v7] In-Reply-To: References: Message-ID: <-PrU1VXjpfCBPL6p9DQaFDv5GcKHWWDLkh1gF5E1Vdk=.223612b6-8044-4c33-84ef-1634e80c2e0c@github.com> On Tue, 26 Apr 2022 17:27:35 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh 8d8f0a2fd646e57fe6b4e8ab669f836dc46dda69 src/jdk.management/share/classes/com/sun/management/HotSpotDiagnosticMXBean.java line 149: > 147: * access to the file or {@link java.lang.management.ManagementPermission > 148: * ManagementPermission("control")} is denied > 149: * @since 19 Maybe there ought to be an `@throws UnsupportedOperationException` here since that is what the default implementation of the method is supposed to do. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From mcimadamore at openjdk.java.net Wed Apr 27 11:49:42 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 27 Apr 2022 11:49:42 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v32] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/424 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Address CSR comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7888/files - new: https://git.openjdk.java.net/jdk/pull/7888/files/746de5ce..6990183f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=31 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=30-31 Stats: 114 lines in 9 files changed: 36 ins; 0 del; 78 mod Patch: https://git.openjdk.java.net/jdk/pull/7888.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888 PR: https://git.openjdk.java.net/jdk/pull/7888 From mcimadamore at openjdk.java.net Wed Apr 27 12:00:29 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 27 Apr 2022 12:00:29 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v33] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/424 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Simplify libraryLookup impl ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7888/files - new: https://git.openjdk.java.net/jdk/pull/7888/files/6990183f..5866bbb5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=32 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=31-32 Stats: 21 lines in 1 file changed: 6 ins; 11 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/7888.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888 PR: https://git.openjdk.java.net/jdk/pull/7888 From coleenp at openjdk.java.net Wed Apr 27 12:39:42 2022 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 27 Apr 2022 12:39:42 GMT Subject: RFR: 8285364: Remove REF_ enum for java.lang.ref.Reference [v3] In-Reply-To: References: Message-ID: <7ERXZAkg8hiuWewX3W3dd1fBK1mN3TjY0YxSiOcztxQ=.17f8cb74-753d-4220-ad00-55495f6ce657@github.com> On Fri, 22 Apr 2022 09:43:45 GMT, Albert Mingkun Yang wrote: >> Simple rename and some comments update. >> >> Test: build > > Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: > > Remove REF_ enum for java.lang.ref.Reference > > Signed-off-by: Albert Yang I think this is better. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8332 From coleenp at openjdk.java.net Wed Apr 27 12:39:43 2022 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 27 Apr 2022 12:39:43 GMT Subject: RFR: 8285364: Remove REF_ enum for java.lang.ref.Reference [v3] In-Reply-To: References: Message-ID: On Mon, 25 Apr 2022 19:36:49 GMT, Stefan Karlsson wrote: >> src/hotspot/share/oops/instanceKlass.cpp line 441: >> >>> 439: >>> 440: // Allocation >>> 441: if (parser.is_java_lang_ref_Reference_subclass()) { >> >> I'm having a really hard time understanding this. java.lang.Reference now doesn't have any REF_OTHER type set. I didn't realize that a java.lang.Reference instance is a plain InstanceKlass, and not an InstanceRefKlass. Is this right? > > Yes, I was also surprised by this. The java.lang.ref.Reference Klass is only an InstanceKlass, not an InstanceRefKlass. Yeah, please add a short comment in the is_java_lang_ref_Reference_subclass function that this is the case, now that we've learned this. ------------- PR: https://git.openjdk.java.net/jdk/pull/8332 From sgehwolf at redhat.com Wed Apr 27 13:01:42 2022 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 27 Apr 2022 15:01:42 +0200 Subject: [RFC 8285277] - How should the JVM handle container memory limits In-Reply-To: <7baf6243-150c-2432-9540-a27e4ca1c90c@oracle.com> References: <955f87a4-333d-eabe-aba4-2c302075b99a@oracle.com> <7baf6243-150c-2432-9540-a27e4ca1c90c@oracle.com> Message-ID: <50640774d030e5f2b3ef95a1c4b98ae635a1c31f.camel@redhat.com> On Tue, 2022-04-26 at 11:12 -0700, Ioi Lam wrote: > On 4/21/2022 2:49 AM, Severin Gehwolf wrote: > > On Wed, 2022-04-20 at 11:09 -0700, Ioi Lam wrote: > > > I would like to have a discussion on how (or whether) the JVM should > > > handle container memory limits -- see JDK-8285277 [1] > > It does handle container memory limits. os::physical_memory() returns > > the container limit instead of the host value if a container limit is > > in place. That was one big aspect of JDK-8146115 when it was done in > > JDK 10 timeframe. See: > > > > https://github.com/openjdk/jdk/blob/fa04d1f832ff201248f935939fa255988053a1d0/src/hotspot/os/linux/os_linux.cpp#L217..L232 > > > > What am I missing? > > Yes, the container support code does expose the memory limit through > APIs like os::physical_memory(), and we use the same ergonomic logic as > if we are running on a physical machine with a small amount of RAM. > > However, I am wondering if we need to reconsider our logic if the > "physical memory" is unusually small. Not just for small containers. Some tunings are needed for larger containers too (considering that it's usually 1 process per container). > Currently, the ergonomic code will set the heap size to a "sensible" > fraction of os::physical_memory(). This usually works fine on modern day > machines with lots of RAM and swap. Even the below-$100 windows laptops > have at least 4GB. For some definition of "sensible". For a physical machine a value of MaxRAMPercentage=25 makes sense. For a container where the typical use case is some cloud orchestration framework spawning them and in 99% of the cases the container runs a single process with some memory limit imposed a value of MaxRAMPercentage=25 doesn't make as much sense. Say a container limit is 500MB, then your heap limit (MaxHeapSize) without any further tuning elsewhere will be 500/4 (126MB), which in that case most of the time won't be what the user wants. Note that this means that the JVM will throw OutOfMemory errors as soon as the MaxHeapSize is being reached, even though there probably is unused container memory still available (most likely 3*500/4 - N, where N the amount of native JVM memory). > On my 64GB box, max heap is set to 16GB by default. This should be > enough for most apps, and will practically never be killed by OOM unless > the system is really overloaded. > > ================ > $ java -XX:+PrintFlagsFinal --version | egrep > '((MaxHeapSize)|(InitialHeapSize))' > ??? size_t InitialHeapSize????????????????????????? = > 1056964608??????????????????????????????? {product} {ergonomic} > ??? size_t MaxHeapSize????????????????????????????? = > 16869490688?????????????????????????????? {product} {ergonomic} > ================ > > But inside a container that has only a 128MB limit (which might be > "typical" for micro-services??) > > ================ > $ java -XX:+PrintFlagsFinal --version | egrep > '((MaxHeapSize)|(InitialHeapSize))' > ??? size_t InitialHeapSize????????????????????????? = > 8388608?????????????????????????????????? {product} {ergonomic} > ??? size_t MaxHeapSize????????????????????????????? = > 67108864????????????????????????????????? {product} {ergonomic} > ================ > > The default MaxHeapSize seems wasteful. We are paying for 128MB but > really just use 64MB of heap. I am able to start with a 108MB heap size > without getting killed. Yes. While I got confused a little what you meant by "wasteful" it sounds like you are saying it should set MaxHeapSize to a higher level. Is that correct? If so that's basically what I was trying to say with the (wrong) default of MaxRAMPercentage when run in a container. My experimentations with this didn't go anywhere, though, as we cannot reliably detect if we are on a plain Linux system or in a container. See JDK-8261242. > ====================== > $ java -XshowSettings:system -Xms108m -XX:+AlwaysPreTouch --version > Operating System Metrics: > ???? Provider: cgroupv1 > ?? ? .... > ???? Memory Limit: 128.00M > ???? Memory Soft Limit: Unlimited > ???? Memory & Swap Limit: 128.00M > > java 19-internal 2022-09-20 > Java(TM) SE Runtime Environment (build 19-internal-adhoc.iklam) > Java HotSpot(TM) 64-Bit Server VM (build 19-internal-adhoc.iklam, mixed > mode, sharing) > ========================== > > The problem is > > - If we want to efficiently use all the memory we paid for in a > container, we need to tune the VM parameters manually > > - But tuning is very difficult and error prone. With the 100mb heap > setting, my app could easily be killed if it uses too much memory in > malloc, native buffers, or even the JIT. Currently we don't fail early > (no check of -Xms, -Xmx, etc, against available memory), and don't fail > predictably. +1 to doing some more sanity checks on JVM startup when some of those settings exceed physical memory. > > So, I am wondering if there's anything we can do to make Java both safe > and efficient when running under an small memory budget. I sure hope that we can improve this. One low hanging fruit would be to adjust MaxRAMPercentage (in containers). The question is how to do this without causing issues for JVMs running on physical machines on Linux. Thanks, Severin > Thanks > - Ioi > > > > > The JVM may be terminated by the Linux OOM killer if it tries to use > > > more memory than the memory limit specified for a container. JDK-8284900 > > > [2] tries to avoid OOM by checking InitialHeapSize against the memory > > > limit. However, this is incomplete because the JVM can use memory in > > > other ways: > > > > > > - If -Xmx is larger than -Xms, the heap may expand > > > - malloc memory > > > - code cache > > > - thread stacks > > JDK-8284900 is somewhat a special case which, IIUIC, tries to avoid > > user-errors detectable at JVM startup. For example setting -Xms to a > > value >= physical memory (including swap). In this case the JVM would > > be at risk to get killed by the OOM killer and doing this check on > > start-up would catch it before it comes to it. > > > > On the other hand, I don't see any handling of such a case on a > > *physical* machine. Consider a machine with 8GB of RAM and somebody > > spawning a JVM with -Xms8g on it. It'll happily oblige? In one of my > > VMs with 8GB I see this: > > > > $ ./jdk19-jdk/bin/java -Xms8g -XX:+PrintFlagsFinal -version 2>&1 | grep InitialHeapSize > > ??? size_t InitialHeapSize????????????????????????? = 8589934592??????????????????????????????? {product} {command line} > > $ free --giga > > ??????????????? total??????? used??????? free????? shared? buff/cache?? available > > Mem:?????????????? 8?????????? 0?????????? 7?????????? 0?????????? 0?????????? 7 > > Swap:????????????? 8?????????? 0?????????? 8 > > > > > We have several choices: > > > > > > (a) Following the direction of JDK-8284900, check for the initial memory > > > usage? of other types of memory as well. The problem with this is that > > > checking the "initial" usage some type of memory usage (malloc or stack) > > > is difficult or impossible. > > > > > > (b) Avoid committing more memory when the total memory usage is close to > > > the limit. E.g., avoid expanding the Java heap, or return NULL from > > > os::malloc(). The problem is that some operations in the VM cannot > > > handle malloc failure and will terminate the VM anyway. Also, trying to > > > obey the memory limit with concurrent allocator/deallocator threads is > > > probably difficult or impossible. > > > > > > (c) Do not consider the memory limit and let the VM be killed by the OOM > > > killer. This may be what the user wants -- the user knows that the app > > > will normally run within the memory limit, so if the heap expands too > > > much the app probably has a memory leak and should be killed, to be > > > automatically restarted by an external mechanism (such as Kubernetes). > > Neither of the above? > > > > It would perhaps make sense to do some sanitiy checks on JVM start-up > > (somewhat akin to JDK-8284900). But this should probably be done with > > the main operating system API. Not using OSContainer API as proposed in > > JDK-8284900. For example, print a warning if MaxHeapSize, > > InitialHeapSize and MinHeapSize are larger than the reported physical > > memory (and/or cap it at a lower size if so). > > > > Isn't (b) being handled by setting os::pysical_memory() and > > os::available_memory() to the container limits (which we currently do)? > > It would behave similarly to a physical machine running out of memory, > > no? > > > > Thanks, > > Severin > > > > > > > [1] https://bugs.openjdk.java.net/browse/JDK-8285277 > > > [2] https://bugs.openjdk.java.net/browse/JDK-8284900 > > > > From dholmes at openjdk.java.net Wed Apr 27 13:23:42 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 27 Apr 2022 13:23:42 GMT Subject: RFR: JDK-8284726: Print active locale settings in hs_err reports and in VM.info [v2] In-Reply-To: References: Message-ID: On Tue, 26 Apr 2022 13:33:44 GMT, Thomas Stuefe wrote: >> To analyze locale problems in native code - e.g. stemming from third-party code calling `setlocale(3)` - it would be useful to print the active locale settings in hs-err reports and in VM.info. >> >> Patch notes: >> - Posix is fuzzy about the exact role of LC_ALL. It defines LC_ALL as a way to set all locales in one go, but the implementation could still keep the individual categories separately and just let LC_ALL override the individual settings. Therefore I opted to print both, even though on glibc the information seems redundant. >> - Since this is Posix specific, callers require #ifndef _WIN32 in shared files. That's not nice, but the alternative would be an empty stub implementation for windows, which I find also unappealing. >> >> Example output, Ubuntu 20.04: >> >> Java started with LC_ALL=C: >> >> thomas at starfish $ jcmd Simple VM.info | ack LC_ >> LC_ALL=C >> LC_ALL=C >> LC_COLLATE=C >> LC_CTYPE=C >> LC_MESSAGES=C >> LC_MONETARY=C >> LC_NUMERIC=C >> LC_TIME=C >> >> >> Java started with my default system settings: >> >> thomas at starfish $ jcmd Simple VM.info | ack LC_ >> LC_ALL=LC_CTYPE=C;LC_NUMERIC=en_DK.UTF-8;LC_TIME=en_DK.UTF-8;LC_COLLATE=C;LC_MONETARY=en_DK.UTF-8;LC_MESSAGES=C;LC_PAPER=en_DK.UTF-8;LC_NAME=en_DK.UTF-8;LC_ADDRESS=en_DK.UTF-8;LC_TELEPHONE=en_DK.UTF-8;LC_MEASUREMENT=en_DK.UTF-8;LC_IDENTIFICATION=en_DK.UTF-8 >> LC_COLLATE=C >> LC_CTYPE=C >> LC_MESSAGES=C >> LC_MONETARY=en_DK.UTF-8 >> LC_NUMERIC=en_DK.UTF-8 >> LC_TIME=en_DK.UTF-8 > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > feedback kevin, david Marked as reviewed by dholmes (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8194 From dholmes at openjdk.java.net Wed Apr 27 13:23:42 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 27 Apr 2022 13:23:42 GMT Subject: RFR: JDK-8284726: Print active locale settings in hs_err reports and in VM.info [v2] In-Reply-To: References: Message-ID: On Tue, 26 Apr 2022 13:20:37 GMT, Thomas Stuefe wrote: >> The Linux manpage is even more vague than the Posix spec. :( >> >> I'd prefer "" or "" or "" to just "??". > > This comment was confusing until I read it as mail :) Sorry I never noticed that. I will add escape characters to make it clear for future readers :) ------------- PR: https://git.openjdk.java.net/jdk/pull/8194 From alanb at openjdk.java.net Wed Apr 27 13:44:13 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 27 Apr 2022 13:44:13 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v7] In-Reply-To: <-PrU1VXjpfCBPL6p9DQaFDv5GcKHWWDLkh1gF5E1Vdk=.223612b6-8044-4c33-84ef-1634e80c2e0c@github.com> References: <-PrU1VXjpfCBPL6p9DQaFDv5GcKHWWDLkh1gF5E1Vdk=.223612b6-8044-4c33-84ef-1634e80c2e0c@github.com> Message-ID: On Wed, 27 Apr 2022 11:34:51 GMT, Daniel Fuchs wrote: >> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: >> >> Refresh 8d8f0a2fd646e57fe6b4e8ab669f836dc46dda69 > > src/jdk.management/share/classes/com/sun/management/HotSpotDiagnosticMXBean.java line 149: > >> 147: * access to the file or {@link java.lang.management.ManagementPermission >> 148: * ManagementPermission("control")} is denied >> 149: * @since 19 > > Maybe there ought to be an `@throws UnsupportedOperationException` here since that is what the default implementation of the method is supposed to do. Well spotted. The implSpec further up documents it but it should be in the throws list too. > test/jdk/java/net/vthread/HttpALot.java line 76: > >> 74: var address = server.getAddress(); >> 75: URL url = new URL("http://" + address.getHostName() + ":" + address.getPort() + "/hello"); >> 76: > > Nit: Ideally we should use the URIBuilder from the test library here, and the IP literal address to improve stability of the test on machines that may have strange /etc/hosts configuration. This can be taken care of after this PR has been integrated. A few of these tests started out as standalone classes that could be run without test infrastructure. This one, and InterruptHttp, can be easily changed to use the URIBuilder infra library, so we can do that. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From dfuchs at openjdk.java.net Wed Apr 27 13:44:14 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 27 Apr 2022 13:44:14 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v7] In-Reply-To: References: Message-ID: On Tue, 26 Apr 2022 17:27:35 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh 8d8f0a2fd646e57fe6b4e8ab669f836dc46dda69 test/jdk/java/net/vthread/HttpALot.java line 76: > 74: var address = server.getAddress(); > 75: URL url = new URL("http://" + address.getHostName() + ":" + address.getPort() + "/hello"); > 76: Nit: Ideally we should use the URIBuilder from the test library here, and the IP literal address to improve stability of the test on machines that may have strange /etc/hosts configuration. This can be taken care of after this PR has been integrated. test/jdk/java/net/vthread/InterruptHttp.java line 88: > 86: InetAddress lb = InetAddress.getLoopbackAddress(); > 87: listener = new ServerSocket(0, -1, lb); > 88: address = "http://" + lb.getHostAddress() + ":" + listener.getLocalPort(); Same remark about using URIBuilder here. It would take care of properly formatting the address in case of IPv6 literals. This can be taken care of after this PR has been integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From mbaesken at openjdk.java.net Wed Apr 27 14:15:44 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Wed, 27 Apr 2022 14:15:44 GMT Subject: RFR: JDK-8284726: Print active locale settings in hs_err reports and in VM.info [v2] In-Reply-To: References: Message-ID: On Tue, 26 Apr 2022 13:33:44 GMT, Thomas Stuefe wrote: >> To analyze locale problems in native code - e.g. stemming from third-party code calling `setlocale(3)` - it would be useful to print the active locale settings in hs-err reports and in VM.info. >> >> Patch notes: >> - Posix is fuzzy about the exact role of LC_ALL. It defines LC_ALL as a way to set all locales in one go, but the implementation could still keep the individual categories separately and just let LC_ALL override the individual settings. Therefore I opted to print both, even though on glibc the information seems redundant. >> - Since this is Posix specific, callers require #ifndef _WIN32 in shared files. That's not nice, but the alternative would be an empty stub implementation for windows, which I find also unappealing. >> >> Example output, Ubuntu 20.04: >> >> Java started with LC_ALL=C: >> >> thomas at starfish $ jcmd Simple VM.info | ack LC_ >> LC_ALL=C >> LC_ALL=C >> LC_COLLATE=C >> LC_CTYPE=C >> LC_MESSAGES=C >> LC_MONETARY=C >> LC_NUMERIC=C >> LC_TIME=C >> >> >> Java started with my default system settings: >> >> thomas at starfish $ jcmd Simple VM.info | ack LC_ >> LC_ALL=LC_CTYPE=C;LC_NUMERIC=en_DK.UTF-8;LC_TIME=en_DK.UTF-8;LC_COLLATE=C;LC_MONETARY=en_DK.UTF-8;LC_MESSAGES=C;LC_PAPER=en_DK.UTF-8;LC_NAME=en_DK.UTF-8;LC_ADDRESS=en_DK.UTF-8;LC_TELEPHONE=en_DK.UTF-8;LC_MEASUREMENT=en_DK.UTF-8;LC_IDENTIFICATION=en_DK.UTF-8 >> LC_COLLATE=C >> LC_CTYPE=C >> LC_MESSAGES=C >> LC_MONETARY=en_DK.UTF-8 >> LC_NUMERIC=en_DK.UTF-8 >> LC_TIME=en_DK.UTF-8 > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > feedback kevin, david Looks okay to me. Probably you want to update the COPYRIGHT header info of os_posix.hpp (if so no further review needed from my side). ------------- Marked as reviewed by mbaesken (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8194 From alanb at openjdk.java.net Wed Apr 27 14:24:20 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 27 Apr 2022 14:24:20 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: > This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. > > We will refresh this PR periodically to pick up changes and fixes from the loom repo. > > Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. > > The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. > > There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. > > The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. > > The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8166/files - new: https://git.openjdk.java.net/jdk/pull/8166/files/0864cb09..f2ed4f9c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8166&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8166&range=06-07 Stats: 505 lines in 15 files changed: 139 ins; 189 del; 177 mod Patch: https://git.openjdk.java.net/jdk/pull/8166.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8166/head:pull/8166 PR: https://git.openjdk.java.net/jdk/pull/8166 From kevinw at openjdk.java.net Wed Apr 27 14:29:43 2022 From: kevinw at openjdk.java.net (Kevin Walls) Date: Wed, 27 Apr 2022 14:29:43 GMT Subject: RFR: JDK-8284726: Print active locale settings in hs_err reports and in VM.info [v2] In-Reply-To: References: Message-ID: On Tue, 26 Apr 2022 13:33:44 GMT, Thomas Stuefe wrote: >> To analyze locale problems in native code - e.g. stemming from third-party code calling `setlocale(3)` - it would be useful to print the active locale settings in hs-err reports and in VM.info. >> >> Patch notes: >> - Posix is fuzzy about the exact role of LC_ALL. It defines LC_ALL as a way to set all locales in one go, but the implementation could still keep the individual categories separately and just let LC_ALL override the individual settings. Therefore I opted to print both, even though on glibc the information seems redundant. >> - Since this is Posix specific, callers require #ifndef _WIN32 in shared files. That's not nice, but the alternative would be an empty stub implementation for windows, which I find also unappealing. >> >> Example output, Ubuntu 20.04: >> >> Java started with LC_ALL=C: >> >> thomas at starfish $ jcmd Simple VM.info | ack LC_ >> LC_ALL=C >> LC_ALL=C >> LC_COLLATE=C >> LC_CTYPE=C >> LC_MESSAGES=C >> LC_MONETARY=C >> LC_NUMERIC=C >> LC_TIME=C >> >> >> Java started with my default system settings: >> >> thomas at starfish $ jcmd Simple VM.info | ack LC_ >> LC_ALL=LC_CTYPE=C;LC_NUMERIC=en_DK.UTF-8;LC_TIME=en_DK.UTF-8;LC_COLLATE=C;LC_MONETARY=en_DK.UTF-8;LC_MESSAGES=C;LC_PAPER=en_DK.UTF-8;LC_NAME=en_DK.UTF-8;LC_ADDRESS=en_DK.UTF-8;LC_TELEPHONE=en_DK.UTF-8;LC_MEASUREMENT=en_DK.UTF-8;LC_IDENTIFICATION=en_DK.UTF-8 >> LC_COLLATE=C >> LC_CTYPE=C >> LC_MESSAGES=C >> LC_MONETARY=en_DK.UTF-8 >> LC_NUMERIC=en_DK.UTF-8 >> LC_TIME=en_DK.UTF-8 > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > feedback kevin, david Marked as reviewed by kevinw (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8194 From ayang at openjdk.java.net Wed Apr 27 14:31:59 2022 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Wed, 27 Apr 2022 14:31:59 GMT Subject: RFR: 8285364: Remove REF_ enum for java.lang.ref.Reference [v3] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 12:35:56 GMT, Coleen Phillimore wrote: >> Yes, I was also surprised by this. The java.lang.ref.Reference Klass is only an InstanceKlass, not an InstanceRefKlass. > > Yeah, please add a short comment in the is_java_lang_ref_Reference_subclass function that this is the case, now that we've learned this. Instead of documenting this surprise, how about removing it by extending this method to cover all subtypes of `j.l.r.Reference`? bool ClassFileParser::is_java_lang_ref_Reference_or_subclass() const { if (_super_klass == NULL) { return false; } if (_class_name == vmSymbols::java_lang_ref_Reference()) { return true; } if (_super_klass->name() == vmSymbols::java_lang_ref_Reference()) { return true; } return _super_klass->reference_type() != REF_NONE; } ------------- PR: https://git.openjdk.java.net/jdk/pull/8332 From duke at openjdk.java.net Wed Apr 27 14:34:39 2022 From: duke at openjdk.java.net (Evgeny Astigeevich) Date: Wed, 27 Apr 2022 14:34:39 GMT Subject: RFR: 8285487: Do not generate trampolines for runtime calls if they are not needed [v2] In-Reply-To: References: Message-ID: > [JDK-8280872](https://bugs.openjdk.java.net/browse/JDK-8280872) put the non-nmethod segment between two others. It made trampolines for runtime calls redundant in most cases. > > This PR uses `target_needs_far_branch()` for runtime calls to check whether they need trampolines. Trampolines are not generated if they are not needed. > > Testing: > - `tier1`...`tier4`: Passed > - `compiler/c2/aarch64/TestTrampoline.java`: Passed > > Note: `compiler/c2/aarch64/TestTrampoline.java` requires the release build. This is because debug builds have the branch range set to 2M which causes always generation of trampolines. Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: XX:ReservedCodeCacheSize=130M for test and update comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8403/files - new: https://git.openjdk.java.net/jdk/pull/8403/files/2d533e39..859f422d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8403&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8403&range=00-01 Stats: 26 lines in 2 files changed: 14 ins; 5 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/8403.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8403/head:pull/8403 PR: https://git.openjdk.java.net/jdk/pull/8403 From duke at openjdk.java.net Wed Apr 27 14:34:40 2022 From: duke at openjdk.java.net (Evgeny Astigeevich) Date: Wed, 27 Apr 2022 14:34:40 GMT Subject: RFR: 8285487: Do not generate trampolines for runtime calls if they are not needed [v2] In-Reply-To: References: Message-ID: <9W7_NFhwr1rX3-likYWWGXzl4xVfccL8pTjtygcbF9Q=.79fb64d8-e6ab-46ba-a898-4f8b8e5449b2@github.com> On Wed, 27 Apr 2022 08:44:44 GMT, Boris Ulasevich wrote: >> Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: >> >> XX:ReservedCodeCacheSize=130M for test and update comments > > src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 406: > >> 404: // If CodeCache size > 128M, such calls must have reserved trampolines for the case: >> 405: // C2 compiled method calls C1 compiled method. >> 406: return (entry.rspec().type() == relocInfo::runtime_call_type) ? target_needs_far_branch(entry.target()) > > Why is target_needs_far_branch() applied for runtime_call_type only? Updated comment to make it clear. > test/hotspot/jtreg/compiler/c2/aarch64/TestTrampoline.java line 57: > >> 55: // As the non-nmethod segment is put between other two segments, >> 56: // ReservedCodeCacheSize=240M guarantees no trampolines for runtime calls to the non-nmethod segment. >> 57: command.add("-XX:ReservedCodeCacheSize=240M"); > > To reduce memory load on the test machines, I would reduce the ReservedCodeCacheSize to 140M. > > Minor stylistic comment: let us remove empty lines 59, 61, 63, 65, 67 below. Reduced it to 130M. ------------- PR: https://git.openjdk.java.net/jdk/pull/8403 From dfuchs at openjdk.java.net Wed Apr 27 14:36:07 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 27 Apr 2022 14:36:07 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: <-DAfgDmuhsODNWuhCRea8JMYvDS4Gq6fX1kmESiMDss=.37b60329-a65f-4ab9-a78c-79db99f80226@github.com> On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e Thanks for the refresh Alan! Things look good to me now. I have gone over java.io, the networking parts of java.nio, java.net, and the JMX related changes. For what I have reviewed, I believe this is good to go. ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8166 From lmesnik at openjdk.java.net Wed Apr 27 14:43:11 2022 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Wed, 27 Apr 2022 14:43:11 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e Reviewed jvmti changes, hotspot tests (excluding tests modified by lmesnik), jdk svc tests changes. ------------- Marked as reviewed by lmesnik (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8166 From stuefe at openjdk.java.net Wed Apr 27 16:53:38 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 27 Apr 2022 16:53:38 GMT Subject: RFR: JDK-8284726: Print active locale settings in hs_err reports and in VM.info [v3] In-Reply-To: References: Message-ID: > To analyze locale problems in native code - e.g. stemming from third-party code calling `setlocale(3)` - it would be useful to print the active locale settings in hs-err reports and in VM.info. > > Patch notes: > - Posix is fuzzy about the exact role of LC_ALL. It defines LC_ALL as a way to set all locales in one go, but the implementation could still keep the individual categories separately and just let LC_ALL override the individual settings. Therefore I opted to print both, even though on glibc the information seems redundant. > - Since this is Posix specific, callers require #ifndef _WIN32 in shared files. That's not nice, but the alternative would be an empty stub implementation for windows, which I find also unappealing. > > Example output, Ubuntu 20.04: > > Java started with LC_ALL=C: > > thomas at starfish $ jcmd Simple VM.info | ack LC_ > LC_ALL=C > LC_ALL=C > LC_COLLATE=C > LC_CTYPE=C > LC_MESSAGES=C > LC_MONETARY=C > LC_NUMERIC=C > LC_TIME=C > > > Java started with my default system settings: > > thomas at starfish $ jcmd Simple VM.info | ack LC_ > LC_ALL=LC_CTYPE=C;LC_NUMERIC=en_DK.UTF-8;LC_TIME=en_DK.UTF-8;LC_COLLATE=C;LC_MONETARY=en_DK.UTF-8;LC_MESSAGES=C;LC_PAPER=en_DK.UTF-8;LC_NAME=en_DK.UTF-8;LC_ADDRESS=en_DK.UTF-8;LC_TELEPHONE=en_DK.UTF-8;LC_MEASUREMENT=en_DK.UTF-8;LC_IDENTIFICATION=en_DK.UTF-8 > LC_COLLATE=C > LC_CTYPE=C > LC_MESSAGES=C > LC_MONETARY=en_DK.UTF-8 > LC_NUMERIC=en_DK.UTF-8 > LC_TIME=en_DK.UTF-8 Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: Fix copyright ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8194/files - new: https://git.openjdk.java.net/jdk/pull/8194/files/f168c8a9..93347f86 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8194&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8194&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8194.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8194/head:pull/8194 PR: https://git.openjdk.java.net/jdk/pull/8194 From stuefe at openjdk.java.net Wed Apr 27 16:53:39 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 27 Apr 2022 16:53:39 GMT Subject: RFR: JDK-8284726: Print active locale settings in hs_err reports and in VM.info [v2] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 13:20:04 GMT, David Holmes wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> feedback kevin, david > > Marked as reviewed by dholmes (Reviewer). Thanks @dholmes-ora , @MBaesken and @kevinjwalls for the reviews. ------------- PR: https://git.openjdk.java.net/jdk/pull/8194 From stuefe at openjdk.java.net Wed Apr 27 16:53:39 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 27 Apr 2022 16:53:39 GMT Subject: Integrated: JDK-8284726: Print active locale settings in hs_err reports and in VM.info In-Reply-To: References: Message-ID: On Tue, 12 Apr 2022 06:44:41 GMT, Thomas Stuefe wrote: > To analyze locale problems in native code - e.g. stemming from third-party code calling `setlocale(3)` - it would be useful to print the active locale settings in hs-err reports and in VM.info. > > Patch notes: > - Posix is fuzzy about the exact role of LC_ALL. It defines LC_ALL as a way to set all locales in one go, but the implementation could still keep the individual categories separately and just let LC_ALL override the individual settings. Therefore I opted to print both, even though on glibc the information seems redundant. > - Since this is Posix specific, callers require #ifndef _WIN32 in shared files. That's not nice, but the alternative would be an empty stub implementation for windows, which I find also unappealing. > > Example output, Ubuntu 20.04: > > Java started with LC_ALL=C: > > thomas at starfish $ jcmd Simple VM.info | ack LC_ > LC_ALL=C > LC_ALL=C > LC_COLLATE=C > LC_CTYPE=C > LC_MESSAGES=C > LC_MONETARY=C > LC_NUMERIC=C > LC_TIME=C > > > Java started with my default system settings: > > thomas at starfish $ jcmd Simple VM.info | ack LC_ > LC_ALL=LC_CTYPE=C;LC_NUMERIC=en_DK.UTF-8;LC_TIME=en_DK.UTF-8;LC_COLLATE=C;LC_MONETARY=en_DK.UTF-8;LC_MESSAGES=C;LC_PAPER=en_DK.UTF-8;LC_NAME=en_DK.UTF-8;LC_ADDRESS=en_DK.UTF-8;LC_TELEPHONE=en_DK.UTF-8;LC_MEASUREMENT=en_DK.UTF-8;LC_IDENTIFICATION=en_DK.UTF-8 > LC_COLLATE=C > LC_CTYPE=C > LC_MESSAGES=C > LC_MONETARY=en_DK.UTF-8 > LC_NUMERIC=en_DK.UTF-8 > LC_TIME=en_DK.UTF-8 This pull request has now been integrated. Changeset: 6ce4e755 Author: Thomas Stuefe URL: https://git.openjdk.java.net/jdk/commit/6ce4e755a47daa980e522faa27a059cc9df5c304 Stats: 46 lines in 3 files changed: 45 ins; 0 del; 1 mod 8284726: Print active locale settings in hs_err reports and in VM.info Reviewed-by: dholmes, mbaesken, kevinw ------------- PR: https://git.openjdk.java.net/jdk/pull/8194 From dcubed at openjdk.java.net Wed Apr 27 17:12:29 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 27 Apr 2022 17:12:29 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e I've reviewed the JVM/TI, JDWP and JDI changes and I'm good with those. I haven't reviewed the JDB changes (forgot about those) and I have not (yet) reviewed the Runtime changes. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8166 From kevinw at openjdk.java.net Wed Apr 27 17:12:29 2022 From: kevinw at openjdk.java.net (Kevin Walls) Date: Wed, 27 Apr 2022 17:12:29 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e Been through the JDI changes and jdb/example code. Built and manually tested some operations with jdb observing virtual threads. Been through jdk.management/share/classes/com/sun/management and also manually tested jconsole attaching (e.g. dumpThreads operation in both TEXT_PLAIN and JSON). ------------- Marked as reviewed by kevinw (Committer). PR: https://git.openjdk.java.net/jdk/pull/8166 From mchung at openjdk.java.net Wed Apr 27 17:30:06 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 27 Apr 2022 17:30:06 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e src/java.base/share/classes/java/lang/PinnedThreadPrinter.java line 58: > 56: > 57: // maps a class to the hashes of stack traces pinned by that code in that class > 58: private static final Map, Hashes> classToHashes = new WeakHashMap<>(); Can you use `ClassValue` in this case? ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From amenkov at openjdk.java.net Wed Apr 27 17:48:55 2022 From: amenkov at openjdk.java.net (Alex Menkov) Date: Wed, 27 Apr 2022 17:48:55 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e Reviewed debugger-related code (JDI/JDWP/JDB/tests) and partially JVMTI. ------------- Marked as reviewed by amenkov (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8166 From ioi.lam at oracle.com Wed Apr 27 17:51:29 2022 From: ioi.lam at oracle.com (Ioi Lam) Date: Wed, 27 Apr 2022 10:51:29 -0700 Subject: [RFC 8285277] - How should the JVM handle container memory limits In-Reply-To: <50640774d030e5f2b3ef95a1c4b98ae635a1c31f.camel@redhat.com> References: <955f87a4-333d-eabe-aba4-2c302075b99a@oracle.com> <7baf6243-150c-2432-9540-a27e4ca1c90c@oracle.com> <50640774d030e5f2b3ef95a1c4b98ae635a1c31f.camel@redhat.com> Message-ID: <643d3ce6-1b1c-5174-caf8-d390a06f1a6d@oracle.com> On 4/27/2022 6:01 AM, Severin Gehwolf wrote: > On Tue, 2022-04-26 at 11:12 -0700, Ioi Lam wrote: >> On 4/21/2022 2:49 AM, Severin Gehwolf wrote: >>> On Wed, 2022-04-20 at 11:09 -0700, Ioi Lam wrote: >>>> I would like to have a discussion on how (or whether) the JVM should >>>> handle container memory limits -- see JDK-8285277 [1] >>> It does handle container memory limits. os::physical_memory() returns >>> the container limit instead of the host value if a container limit is >>> in place. That was one big aspect of JDK-8146115 when it was done in >>> JDK 10 timeframe. See: >>> >>> https://github.com/openjdk/jdk/blob/fa04d1f832ff201248f935939fa255988053a1d0/src/hotspot/os/linux/os_linux.cpp#L217..L232 >>> >>> What am I missing? >> Yes, the container support code does expose the memory limit through >> APIs like os::physical_memory(), and we use the same ergonomic logic as >> if we are running on a physical machine with a small amount of RAM. >> >> However, I am wondering if we need to reconsider our logic if the >> "physical memory" is unusually small. > Not just for small containers. Some tunings are needed for larger > containers too (considering that it's usually 1 process per container). > >> Currently, the ergonomic code will set the heap size to a "sensible" >> fraction of os::physical_memory(). This usually works fine on modern day >> machines with lots of RAM and swap. Even the below-$100 windows laptops >> have at least 4GB. > For some definition of "sensible". For a physical machine a value of > MaxRAMPercentage=25 makes sense. For a container where the typical use > case is some cloud orchestration framework spawning them and in 99% of > the cases the container runs a single process with some memory limit > imposed a value of MaxRAMPercentage=25 doesn't make as much sense. Say > a container limit is 500MB, then your heap limit (MaxHeapSize) without > any further tuning elsewhere will be 500/4 (126MB), which in that case > most of the time won't be what the user wants. Note that this means > that the JVM will throw OutOfMemory errors as soon as the MaxHeapSize > is being reached, even though there probably is unused container memory > still available (most likely 3*500/4 - N, where N the amount of native > JVM memory). > >> On my 64GB box, max heap is set to 16GB by default. This should be >> enough for most apps, and will practically never be killed by OOM unless >> the system is really overloaded. >> >> ================ >> $ java -XX:+PrintFlagsFinal --version | egrep >> '((MaxHeapSize)|(InitialHeapSize))' >> ??? size_t InitialHeapSize????????????????????????? = >> 1056964608??????????????????????????????? {product} {ergonomic} >> ??? size_t MaxHeapSize????????????????????????????? = >> 16869490688?????????????????????????????? {product} {ergonomic} >> ================ >> >> But inside a container that has only a 128MB limit (which might be >> "typical" for micro-services??) >> >> ================ >> $ java -XX:+PrintFlagsFinal --version | egrep >> '((MaxHeapSize)|(InitialHeapSize))' >> ??? size_t InitialHeapSize????????????????????????? = >> 8388608?????????????????????????????????? {product} {ergonomic} >> ??? size_t MaxHeapSize????????????????????????????? = >> 67108864????????????????????????????????? {product} {ergonomic} >> ================ >> >> The default MaxHeapSize seems wasteful. We are paying for 128MB but >> really just use 64MB of heap. I am able to start with a 108MB heap size >> without getting killed. > Yes. While I got confused a little what you meant by "wasteful" it > sounds like you are saying it should set MaxHeapSize to a higher level. > Is that correct? Yes, that's what I mean. > If so that's basically what I was trying to say with > the (wrong) default of MaxRAMPercentage when run in a container. My > experimentations with this didn't go anywhere, though, as we cannot > reliably detect if we are on a plain Linux system or in a container. > See JDK-8261242. Perhaps instead of the JVM being smart, we provide a new option (OK I admit I hate adding new options), something like - use more aggressive default heap size - I am running in a container by myself Another approach (probably orthogonal) is to be able to "bounce off" the memory limit without getting killed. If the VM detects that it's getting close to the memory limit, it can proactively shrink the heap and force a GC. This hopefully will cause some native buffers to be freed and classes to be unloaded. With this ability, the VM can set more aggressive defaults, and the user can also set -Xmx more aggressively. That way we can have high utilization of available memory. E.g., you can cache more data structures inside the heap, and throw away those caches when memory pressure changes. Thanks - Ioi >> ====================== >> $ java -XshowSettings:system -Xms108m -XX:+AlwaysPreTouch --version >> Operating System Metrics: >> ???? Provider: cgroupv1 >> ?? ? .... >> ???? Memory Limit: 128.00M >> ???? Memory Soft Limit: Unlimited >> ???? Memory & Swap Limit: 128.00M >> >> java 19-internal 2022-09-20 >> Java(TM) SE Runtime Environment (build 19-internal-adhoc.iklam) >> Java HotSpot(TM) 64-Bit Server VM (build 19-internal-adhoc.iklam, mixed >> mode, sharing) >> ========================== >> >> The problem is >> >> - If we want to efficiently use all the memory we paid for in a >> container, we need to tune the VM parameters manually >> >> - But tuning is very difficult and error prone. With the 100mb heap >> setting, my app could easily be killed if it uses too much memory in >> malloc, native buffers, or even the JIT. Currently we don't fail early >> (no check of -Xms, -Xmx, etc, against available memory), and don't fail >> predictably. > +1 to doing some more sanity checks on JVM startup when some of those > settings exceed physical memory. > >> So, I am wondering if there's anything we can do to make Java both safe >> and efficient when running under an small memory budget. > I sure hope that we can improve this. One low hanging fruit would be to > adjust MaxRAMPercentage (in containers). The question is how to do this > without causing issues for JVMs running on physical machines on Linux. > > Thanks, > Severin > >> Thanks >> - Ioi >> >> >>>> The JVM may be terminated by the Linux OOM killer if it tries to use >>>> more memory than the memory limit specified for a container. JDK-8284900 >>>> [2] tries to avoid OOM by checking InitialHeapSize against the memory >>>> limit. However, this is incomplete because the JVM can use memory in >>>> other ways: >>>> >>>> - If -Xmx is larger than -Xms, the heap may expand >>>> - malloc memory >>>> - code cache >>>> - thread stacks >>> JDK-8284900 is somewhat a special case which, IIUIC, tries to avoid >>> user-errors detectable at JVM startup. For example setting -Xms to a >>> value >= physical memory (including swap). In this case the JVM would >>> be at risk to get killed by the OOM killer and doing this check on >>> start-up would catch it before it comes to it. >>> >>> On the other hand, I don't see any handling of such a case on a >>> *physical* machine. Consider a machine with 8GB of RAM and somebody >>> spawning a JVM with -Xms8g on it. It'll happily oblige? In one of my >>> VMs with 8GB I see this: >>> >>> $ ./jdk19-jdk/bin/java -Xms8g -XX:+PrintFlagsFinal -version 2>&1 | grep InitialHeapSize >>> ??? size_t InitialHeapSize????????????????????????? = 8589934592??????????????????????????????? {product} {command line} >>> $ free --giga >>> ??????????????? total??????? used??????? free????? shared? buff/cache?? available >>> Mem:?????????????? 8?????????? 0?????????? 7?????????? 0?????????? 0?????????? 7 >>> Swap:????????????? 8?????????? 0?????????? 8 >>> >>>> We have several choices: >>>> >>>> (a) Following the direction of JDK-8284900, check for the initial memory >>>> usage? of other types of memory as well. The problem with this is that >>>> checking the "initial" usage some type of memory usage (malloc or stack) >>>> is difficult or impossible. >>>> >>>> (b) Avoid committing more memory when the total memory usage is close to >>>> the limit. E.g., avoid expanding the Java heap, or return NULL from >>>> os::malloc(). The problem is that some operations in the VM cannot >>>> handle malloc failure and will terminate the VM anyway. Also, trying to >>>> obey the memory limit with concurrent allocator/deallocator threads is >>>> probably difficult or impossible. >>>> >>>> (c) Do not consider the memory limit and let the VM be killed by the OOM >>>> killer. This may be what the user wants -- the user knows that the app >>>> will normally run within the memory limit, so if the heap expands too >>>> much the app probably has a memory leak and should be killed, to be >>>> automatically restarted by an external mechanism (such as Kubernetes). >>> Neither of the above? >>> >>> It would perhaps make sense to do some sanitiy checks on JVM start-up >>> (somewhat akin to JDK-8284900). But this should probably be done with >>> the main operating system API. Not using OSContainer API as proposed in >>> JDK-8284900. For example, print a warning if MaxHeapSize, >>> InitialHeapSize and MinHeapSize are larger than the reported physical >>> memory (and/or cap it at a lower size if so). >>> >>> Isn't (b) being handled by setting os::pysical_memory() and >>> os::available_memory() to the container limits (which we currently do)? >>> It would behave similarly to a physical machine running out of memory, >>> no? >>> >>> Thanks, >>> Severin >>> >>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8285277 >>>> [2] https://bugs.openjdk.java.net/browse/JDK-8284900 >>>> From mchung at openjdk.java.net Wed Apr 27 17:55:23 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 27 Apr 2022 17:55:23 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e src/java.base/share/classes/jdk/internal/misc/UnsafeConstants.java line 122: > 120: */ > 121: > 122: public static final int SCOPED_CACHE_SHIFT; I can't find this constant being used. If added for future, maybe keep `UnsafeConstants` class and this static field package-private for now. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From mchung at openjdk.java.net Wed Apr 27 18:11:08 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 27 Apr 2022 18:11:08 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e src/java.management/share/classes/sun/management/ThreadImpl.java line 447: > 445: if (threads != null) { > 446: long[] tids = Stream.of(threads) > 447: .filter(t -> !(t instanceof jdk.internal.misc.CarrierThread)) Returning an array of thread IDs of just the platform threads is good. The javadoc needs to be updated to say "Returns an array of thread identifiers for the platform threads...." ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From psandoz at openjdk.java.net Wed Apr 27 18:21:13 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Wed, 27 Apr 2022 18:21:13 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 17:27:56 GMT, Mandy Chung wrote: >> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: >> >> Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e > > src/java.base/share/classes/java/lang/PinnedThreadPrinter.java line 58: > >> 56: >> 57: // maps a class to the hashes of stack traces pinned by that code in that class >> 58: private static final Map, Hashes> classToHashes = new WeakHashMap<>(); > > Can you use `ClassValue` in this case? I was wondering that too, but held off commenting since it's not super performance critical given `classToHashes` is synchronized on. However, it does make the code a little clearer. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From mchung at openjdk.java.net Wed Apr 27 18:21:13 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 27 Apr 2022 18:21:13 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 18:13:15 GMT, Paul Sandoz wrote: >> src/java.base/share/classes/java/lang/PinnedThreadPrinter.java line 58: >> >>> 56: >>> 57: // maps a class to the hashes of stack traces pinned by that code in that class >>> 58: private static final Map, Hashes> classToHashes = new WeakHashMap<>(); >> >> Can you use `ClassValue` in this case? > > I was wondering that too, but held off commenting since it's not super performance critical given `classToHashes` is synchronized on. However, it does make the code a little clearer. It's not critical and no problem if this is cleaned up as a follow-up. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From dlong at openjdk.java.net Wed Apr 27 19:11:17 2022 From: dlong at openjdk.java.net (Dean Long) Date: Wed, 27 Apr 2022 19:11:17 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e Marked as reviewed by dlong (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From alanb at openjdk.java.net Wed Apr 27 19:25:53 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 27 Apr 2022 19:25:53 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 17:53:01 GMT, Mandy Chung wrote: >> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: >> >> Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e > > src/java.base/share/classes/jdk/internal/misc/UnsafeConstants.java line 122: > >> 120: */ >> 121: >> 122: public static final int SCOPED_CACHE_SHIFT; > > I can't find this constant being used. If added for future, maybe keep `UnsafeConstants` class and this static field package-private for now. It originally configured the number of lines in extent local cache but the implementation has changed. @theRealAph would be best to comment on this, it may be possible to delete it. > src/java.management/share/classes/sun/management/ThreadImpl.java line 447: > >> 445: if (threads != null) { >> 446: long[] tids = Stream.of(threads) >> 447: .filter(t -> !(t instanceof jdk.internal.misc.CarrierThread)) > > Returning an array of thread IDs of just the platform threads is good. The javadoc needs to be updated to say "Returns an array of thread identifiers for the platform threads...." I think you mean the comment on the private method. Yes, that could be clearer that it just returns platform threads. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From dlong at openjdk.java.net Wed Apr 27 19:46:58 2022 From: dlong at openjdk.java.net (Dean Long) Date: Wed, 27 Apr 2022 19:46:58 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e The compiler changes look good to me. Marked as reviewed by dlong (Reviewer). ------------- Marked as reviewed by dlong (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8166 From alanb at openjdk.java.net Wed Apr 27 19:46:59 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 27 Apr 2022 19:46:59 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: <-k-fd3inPeP7D7elq5T4NOXMUrScsScjLsBqx3q6ucI=.37b4419d-32f1-48af-9c41-09979ca578ce@github.com> On Wed, 27 Apr 2022 18:16:54 GMT, Mandy Chung wrote: >> I was wondering that too, but held off commenting since it's not super performance critical given `classToHashes` is synchronized on. However, it does make the code a little clearer. > > It's not critical and no problem if this is cleaned up as a follow-up. Good idea, this could be improved. As Paul says, it's not performance critical as this is a diagnostic option for printing the stack trace when pinned. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From psandoz at openjdk.java.net Wed Apr 27 19:47:01 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Wed, 27 Apr 2022 19:47:01 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e src/java.base/share/classes/java/util/concurrent/ThreadPerTaskExecutor.java line 45: > 43: * threads is unbounded. > 44: */ > 45: class ThreadPerTaskExecutor implements ExecutorService { This class manages the set of per-task threads which arguably should be the job of the thread container, and it awkwardly overrides the container's set of threads by setting a field on `SharedThreadContainer.threadsSupplier`. `SharedThreadContainer` supports a number of different shared container policies that could be made clearer. Architecturally i think this could be better layered but it can be iterated on later. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From kvn at openjdk.java.net Wed Apr 27 20:01:42 2022 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Wed, 27 Apr 2022 20:01:42 GMT Subject: RFR: 8285301: C2: assert(!requires_atomic_access) failed: can't ensure atomicity In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 10:25:36 GMT, Tobias Hartmann wrote: > We hit asserts in `BarrierSetC2::load_at_resolved` and `BarrierSetC2::store_at_resolved` when running with `-XX:+AlwaysAtomicAccesses` because the corresponding code paths have not been implemented yet. Although the assert triggers on all platforms, it only affects long and double accesses on 32-bit systems (everything else is atomic anyway). > > I moved the `requires_atomic_access` logic into `LoadNode::make` and `StoreNode::make` and refactored related code. > > I noticed that `LoadNode::convert_to_reinterpret_load` and `StoreNode::convert_to_reinterpret_store` did not properly check for `requires_atomic_access` and fixed that as well. > > I'm currently running all tests with `-XX:+AlwaysAtomicAccesses`. > > Thanks, > Tobias src/hotspot/share/opto/memnode.hpp line 610: > 608: static StoreNode* make(PhaseGVN& gvn, Node* c, Node* mem, Node* adr, > 609: const TypePtr* at, Node* val, BasicType bt, > 610: MemOrd mo = MemNode::unordered, bool require_atomic_access = false); I think it was intentionally `MemOrd mo` parameter did not specify default value so that value is always specified at all call sites. I think this change is not required for the fix. ------------- PR: https://git.openjdk.java.net/jdk/pull/8422 From kvn at openjdk.java.net Wed Apr 27 20:13:41 2022 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Wed, 27 Apr 2022 20:13:41 GMT Subject: RFR: 8285301: C2: assert(!requires_atomic_access) failed: can't ensure atomicity In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 10:25:36 GMT, Tobias Hartmann wrote: > We hit asserts in `BarrierSetC2::load_at_resolved` and `BarrierSetC2::store_at_resolved` when running with `-XX:+AlwaysAtomicAccesses` because the corresponding code paths have not been implemented yet. Although the assert triggers on all platforms, it only affects long and double accesses on 32-bit systems (everything else is atomic anyway). > > I moved the `requires_atomic_access` logic into `LoadNode::make` and `StoreNode::make` and refactored related code. > > I noticed that `LoadNode::convert_to_reinterpret_load` and `StoreNode::convert_to_reinterpret_store` did not properly check for `requires_atomic_access` and fixed that as well. > > I'm currently running all tests with `-XX:+AlwaysAtomicAccesses`. > > Thanks, > Tobias src/hotspot/share/opto/memnode.cpp line 1300: > 1298: } > 1299: bool require_atomic_access = (Opcode() == Op_LoadL && ((LoadLNode*)this)->require_atomic_access()) || > 1300: (Opcode() == Op_LoadD && ((LoadDNode*)this)->require_atomic_access()); You can call `Opcode()` only once (it is virtual call - expensive). src/hotspot/share/opto/memnode.cpp line 1322: > 1320: assert(has_reinterpret_variant(vt), "no reinterpret variant: %s %s", Name(), type2name(bt)); > 1321: bool require_atomic_access = (Opcode() == Op_StoreL && ((StoreLNode*)this)->require_atomic_access()) || > 1322: (Opcode() == Op_StoreD && ((StoreDNode*)this)->require_atomic_access()); Call `Opcode()` once. ------------- PR: https://git.openjdk.java.net/jdk/pull/8422 From psandoz at openjdk.java.net Wed Apr 27 20:14:59 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Wed, 27 Apr 2022 20:14:59 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: <7hqD-RqcX58pubiORXgyjVjuyg_-yi1NZqJ8CJIPH20=.480769c3-4033-4741-904d-10c77de38cc4@github.com> On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e src/java.base/share/classes/java/lang/Thread.java line 116: > 114: * carrier threads. Locking and I/O operations are examples of operations > 115: * where a carrier thread may be re-scheduled from one virtual thread to another. > 116: * Code executing in a virtual thread is not aware of underlying carrier thread. Suggestion: * Code executing in a virtual thread is not aware of the underlying carrier thread. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From ioi.lam at oracle.com Wed Apr 27 20:24:49 2022 From: ioi.lam at oracle.com (Ioi Lam) Date: Wed, 27 Apr 2022 13:24:49 -0700 Subject: [RFC 8285277] - How should the JVM handle container memory limits In-Reply-To: <50640774d030e5f2b3ef95a1c4b98ae635a1c31f.camel@redhat.com> References: <955f87a4-333d-eabe-aba4-2c302075b99a@oracle.com> <7baf6243-150c-2432-9540-a27e4ca1c90c@oracle.com> <50640774d030e5f2b3ef95a1c4b98ae635a1c31f.camel@redhat.com> Message-ID: <227b1f73-28a6-e178-142f-234fc713934f@oracle.com> On 4/27/2022 6:01 AM, Severin Gehwolf wrote: > On Tue, 2022-04-26 at 11:12 -0700, Ioi Lam wrote: >> On 4/21/2022 2:49 AM, Severin Gehwolf wrote: >>> On Wed, 2022-04-20 at 11:09 -0700, Ioi Lam wrote: >>>> I would like to have a discussion on how (or whether) the JVM should >>>> handle container memory limits -- see JDK-8285277 [1] >>> It does handle container memory limits. os::physical_memory() returns >>> the container limit instead of the host value if a container limit is >>> in place. That was one big aspect of JDK-8146115 when it was done in >>> JDK 10 timeframe. See: >>> >>> https://github.com/openjdk/jdk/blob/fa04d1f832ff201248f935939fa255988053a1d0/src/hotspot/os/linux/os_linux.cpp#L217..L232 >>> >>> What am I missing? >> Yes, the container support code does expose the memory limit through >> APIs like os::physical_memory(), and we use the same ergonomic logic as >> if we are running on a physical machine with a small amount of RAM. >> >> However, I am wondering if we need to reconsider our logic if the >> "physical memory" is unusually small. > Not just for small containers. Some tunings are needed for larger > containers too (considering that it's usually 1 process per container). > >> Currently, the ergonomic code will set the heap size to a "sensible" >> fraction of os::physical_memory(). This usually works fine on modern day >> machines with lots of RAM and swap. Even the below-$100 windows laptops >> have at least 4GB. > For some definition of "sensible". For a physical machine a value of > MaxRAMPercentage=25 makes sense. For a container where the typical use > case is some cloud orchestration framework spawning them and in 99% of > the cases the container runs a single process with some memory limit > imposed a value of MaxRAMPercentage=25 doesn't make as much sense. Say > a container limit is 500MB, then your heap limit (MaxHeapSize) without > any further tuning elsewhere will be 500/4 (126MB), which in that case > most of the time won't be what the user wants. Note that this means > that the JVM will throw OutOfMemory errors as soon as the MaxHeapSize > is being reached, even though there probably is unused container memory > still available (most likely 3*500/4 - N, where N the amount of native > JVM memory). > >> On my 64GB box, max heap is set to 16GB by default. This should be >> enough for most apps, and will practically never be killed by OOM unless >> the system is really overloaded. >> >> ================ >> $ java -XX:+PrintFlagsFinal --version | egrep >> '((MaxHeapSize)|(InitialHeapSize))' >> ??? size_t InitialHeapSize????????????????????????? = >> 1056964608??????????????????????????????? {product} {ergonomic} >> ??? size_t MaxHeapSize????????????????????????????? = >> 16869490688?????????????????????????????? {product} {ergonomic} >> ================ >> >> But inside a container that has only a 128MB limit (which might be >> "typical" for micro-services??) >> >> ================ >> $ java -XX:+PrintFlagsFinal --version | egrep >> '((MaxHeapSize)|(InitialHeapSize))' >> ??? size_t InitialHeapSize????????????????????????? = >> 8388608?????????????????????????????????? {product} {ergonomic} >> ??? size_t MaxHeapSize????????????????????????????? = >> 67108864????????????????????????????????? {product} {ergonomic} >> ================ >> >> The default MaxHeapSize seems wasteful. We are paying for 128MB but >> really just use 64MB of heap. I am able to start with a 108MB heap size >> without getting killed. > Yes. While I got confused a little what you meant by "wasteful" it > sounds like you are saying it should set MaxHeapSize to a higher level. > Is that correct? If so that's basically what I was trying to say with > the (wrong) default of MaxRAMPercentage when run in a container. My > experimentations with this didn't go anywhere, though, as we cannot > reliably detect if we are on a plain Linux system or in a container. > See JDK-8261242. > >> ====================== >> $ java -XshowSettings:system -Xms108m -XX:+AlwaysPreTouch --version >> Operating System Metrics: >> ???? Provider: cgroupv1 >> ?? ? .... >> ???? Memory Limit: 128.00M >> ???? Memory Soft Limit: Unlimited >> ???? Memory & Swap Limit: 128.00M >> >> java 19-internal 2022-09-20 >> Java(TM) SE Runtime Environment (build 19-internal-adhoc.iklam) >> Java HotSpot(TM) 64-Bit Server VM (build 19-internal-adhoc.iklam, mixed >> mode, sharing) >> ========================== >> >> The problem is >> >> - If we want to efficiently use all the memory we paid for in a >> container, we need to tune the VM parameters manually >> >> - But tuning is very difficult and error prone. With the 100mb heap >> setting, my app could easily be killed if it uses too much memory in >> malloc, native buffers, or even the JIT. Currently we don't fail early >> (no check of -Xms, -Xmx, etc, against available memory), and don't fail >> predictably. > +1 to doing some more sanity checks on JVM startup when some of those > settings exceed physical memory. I think this makes sense. We need to decide what the behavior should be: - what flags to check - print warnings? - abort the VM? - override the settings to conform to available memory? - always do this, or only when running inside a container? If the latter, we will have the problem of? JDK-8261242 Also, we will need a CSR if we decide to abort the VM or override the user-specified settings. Thanks - Ioi >> So, I am wondering if there's anything we can do to make Java both safe >> and efficient when running under an small memory budget. > I sure hope that we can improve this. One low hanging fruit would be to > adjust MaxRAMPercentage (in containers). The question is how to do this > without causing issues for JVMs running on physical machines on Linux. > > Thanks, > Severin > >> Thanks >> - Ioi >> >> >>>> The JVM may be terminated by the Linux OOM killer if it tries to use >>>> more memory than the memory limit specified for a container. JDK-8284900 >>>> [2] tries to avoid OOM by checking InitialHeapSize against the memory >>>> limit. However, this is incomplete because the JVM can use memory in >>>> other ways: >>>> >>>> - If -Xmx is larger than -Xms, the heap may expand >>>> - malloc memory >>>> - code cache >>>> - thread stacks >>> JDK-8284900 is somewhat a special case which, IIUIC, tries to avoid >>> user-errors detectable at JVM startup. For example setting -Xms to a >>> value >= physical memory (including swap). In this case the JVM would >>> be at risk to get killed by the OOM killer and doing this check on >>> start-up would catch it before it comes to it. >>> >>> On the other hand, I don't see any handling of such a case on a >>> *physical* machine. Consider a machine with 8GB of RAM and somebody >>> spawning a JVM with -Xms8g on it. It'll happily oblige? In one of my >>> VMs with 8GB I see this: >>> >>> $ ./jdk19-jdk/bin/java -Xms8g -XX:+PrintFlagsFinal -version 2>&1 | grep InitialHeapSize >>> ??? size_t InitialHeapSize????????????????????????? = 8589934592??????????????????????????????? {product} {command line} >>> $ free --giga >>> ??????????????? total??????? used??????? free????? shared? buff/cache?? available >>> Mem:?????????????? 8?????????? 0?????????? 7?????????? 0?????????? 0?????????? 7 >>> Swap:????????????? 8?????????? 0?????????? 8 >>> >>>> We have several choices: >>>> >>>> (a) Following the direction of JDK-8284900, check for the initial memory >>>> usage? of other types of memory as well. The problem with this is that >>>> checking the "initial" usage some type of memory usage (malloc or stack) >>>> is difficult or impossible. >>>> >>>> (b) Avoid committing more memory when the total memory usage is close to >>>> the limit. E.g., avoid expanding the Java heap, or return NULL from >>>> os::malloc(). The problem is that some operations in the VM cannot >>>> handle malloc failure and will terminate the VM anyway. Also, trying to >>>> obey the memory limit with concurrent allocator/deallocator threads is >>>> probably difficult or impossible. >>>> >>>> (c) Do not consider the memory limit and let the VM be killed by the OOM >>>> killer. This may be what the user wants -- the user knows that the app >>>> will normally run within the memory limit, so if the heap expands too >>>> much the app probably has a memory leak and should be killed, to be >>>> automatically restarted by an external mechanism (such as Kubernetes). >>> Neither of the above? >>> >>> It would perhaps make sense to do some sanitiy checks on JVM start-up >>> (somewhat akin to JDK-8284900). But this should probably be done with >>> the main operating system API. Not using OSContainer API as proposed in >>> JDK-8284900. For example, print a warning if MaxHeapSize, >>> InitialHeapSize and MinHeapSize are larger than the reported physical >>> memory (and/or cap it at a lower size if so). >>> >>> Isn't (b) being handled by setting os::pysical_memory() and >>> os::available_memory() to the container limits (which we currently do)? >>> It would behave similarly to a physical machine running out of memory, >>> no? >>> >>> Thanks, >>> Severin >>> >>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8285277 >>>> [2] https://bugs.openjdk.java.net/browse/JDK-8284900 >>>> From mchung at openjdk.java.net Wed Apr 27 22:31:07 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 27 Apr 2022 22:31:07 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e I reviewed most of the source files in `java.base` except `java.util.concurrent`. I also reviewed `java.logging`, `java.management` and `jdk.management` modules. The changes are easy to follow and clean. Looks good to me. ------------- Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8166 From psandoz at openjdk.java.net Wed Apr 27 22:43:45 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Wed, 27 Apr 2022 22:43:45 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e It's great to see end game in play for this multi-year effort, impressive work by all involved. I looked through code in the base module. Generally looks well structured and documented. The fork join code is naturally hard to review. I did try! (it takes the prize for the highest Java code density in the JDK). I mostly looked for regular and repeated structure rather than trying to fully understand/review the intricate concurrency details. IMO there is some post integration work to do around the architecture of thread containers, i presume the structured concurrency implementation (use of thread flock) will help with that. ------------- Marked as reviewed by psandoz (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8166 From bpb at openjdk.java.net Wed Apr 27 23:10:10 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 27 Apr 2022 23:10:10 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: <3XCjG_IelbjoKjjlqgOq0me4CmVTvVNP-cUMgi2W8V4=.53a46e15-552c-4962-a620-5d97a85c138d@github.com> On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e The changes to the `java.io` package and related files in `libjava`, and the changes to the non-networking parts of the `java.nio.channels`, `sun.nio.ch`, and `sun.nio.fs` packages and related files in `libnio` all look fine to me. ------------- Marked as reviewed by bpb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8166 From dlong at openjdk.java.net Wed Apr 27 23:18:44 2022 From: dlong at openjdk.java.net (Dean Long) Date: Wed, 27 Apr 2022 23:18:44 GMT Subject: RFR: 8285301: C2: assert(!requires_atomic_access) failed: can't ensure atomicity In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 10:25:36 GMT, Tobias Hartmann wrote: > We hit asserts in `BarrierSetC2::load_at_resolved` and `BarrierSetC2::store_at_resolved` when running with `-XX:+AlwaysAtomicAccesses` because the corresponding code paths have not been implemented yet. Although the assert triggers on all platforms, it only affects long and double accesses on 32-bit systems (everything else is atomic anyway). > > I moved the `requires_atomic_access` logic into `LoadNode::make` and `StoreNode::make` and refactored related code. > > I noticed that `LoadNode::convert_to_reinterpret_load` and `StoreNode::convert_to_reinterpret_store` did not properly check for `requires_atomic_access` and fixed that as well. > > I'm currently running all tests with `-XX:+AlwaysAtomicAccesses`. > > Thanks, > Tobias The new TestAlwaysAtomicAccesses test seems suspiciously simple. I guess the idea is to catch issues during startup with -Xcomp. A comment saying that could prevent someone from thinking the test does nothing. ------------- PR: https://git.openjdk.java.net/jdk/pull/8422 From coleenp at openjdk.java.net Thu Apr 28 00:31:46 2022 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 28 Apr 2022 00:31:46 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e I've reviewed the new files in Hotspot runtime and the cpu directories, as well as the changes to existing files in runtime, oops, utilities, interpreter and classfile. I'm happy to approve this PR. Thank you to everyone for their hard work in reviewing this code, and well done to @pron and @AlanBateman and all the loom team for bringing us this significant and exciting new feature for Java! src/hotspot/share/prims/jvmtiEnvBase.cpp line 2388: > 2386: } > 2387: > 2388: void @sspitsyn We should clean up this aberrant style of putting the return type on the line before the rest of the function declaration after this integration. It looks so strange. I noticed that it's pre-existing for other functions in this file. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8166 From sviswanathan at openjdk.java.net Thu Apr 28 00:50:40 2022 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Thu, 28 Apr 2022 00:50:40 GMT Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE with predicate feature [v2] In-Reply-To: References: Message-ID: On Fri, 22 Apr 2022 07:08:24 GMT, Xiaohong Gong wrote: >> Currently the vector load with mask when the given index happens out of the array boundary is implemented with pure java scalar code to avoid the IOOBE (IndexOutOfBoundaryException). This is necessary for architectures that do not support the predicate feature. Because the masked load is implemented with a full vector load and a vector blend applied on it. And a full vector load will definitely cause the IOOBE which is not valid. However, for architectures that support the predicate feature like SVE/AVX-512/RVV, it can be vectorized with the predicated load instruction as long as the indexes of the masked lanes are within the bounds of the array. For these architectures, loading with unmasked lanes does not raise exception. >> >> This patch adds the vectorization support for the masked load with IOOBE part. Please see the original java implementation (FIXME: optimize): >> >> >> @ForceInline >> public static >> ByteVector fromArray(VectorSpecies species, >> byte[] a, int offset, >> VectorMask m) { >> ByteSpecies vsp = (ByteSpecies) species; >> if (offset >= 0 && offset <= (a.length - species.length())) { >> return vsp.dummyVector().fromArray0(a, offset, m); >> } >> >> // FIXME: optimize >> checkMaskFromIndexSize(offset, vsp, m, 1, a.length); >> return vsp.vOp(m, i -> a[offset + i]); >> } >> >> Since it can only be vectorized with the predicate load, the hotspot must check whether the current backend supports it and falls back to the java scalar version if not. This is different from the normal masked vector load that the compiler will generate a full vector load and a vector blend if the predicate load is not supported. So to let the compiler make the expected action, an additional flag (i.e. `usePred`) is added to the existing "loadMasked" intrinsic, with the value "true" for the IOOBE part while "false" for the normal load. And the compiler will fail to intrinsify if the flag is "true" and the predicate load is not supported by the backend, which means that normal java path will be executed. >> >> Also adds the same vectorization support for masked: >> - fromByteArray/fromByteBuffer >> - fromBooleanArray >> - fromCharArray >> >> The performance for the new added benchmarks improve about `1.88x ~ 30.26x` on the x86 AVX-512 system: >> >> Benchmark before After Units >> LoadMaskedIOOBEBenchmark.byteLoadArrayMaskIOOBE 737.542 1387.069 ops/ms >> LoadMaskedIOOBEBenchmark.doubleLoadArrayMaskIOOBE 118.366 330.776 ops/ms >> LoadMaskedIOOBEBenchmark.floatLoadArrayMaskIOOBE 233.832 6125.026 ops/ms >> LoadMaskedIOOBEBenchmark.intLoadArrayMaskIOOBE 233.816 7075.923 ops/ms >> LoadMaskedIOOBEBenchmark.longLoadArrayMaskIOOBE 119.771 330.587 ops/ms >> LoadMaskedIOOBEBenchmark.shortLoadArrayMaskIOOBE 431.961 939.301 ops/ms >> >> Similar performance gain can also be observed on 512-bit SVE system. > > Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision: > > Rename the "usePred" to "offsetInRange" Rest of the patch looks good to me. src/hotspot/share/opto/vectorIntrinsics.cpp line 1232: > 1230: // out when current case uses the predicate feature. > 1231: if (!supports_predicate) { > 1232: bool use_predicate = false; If we rename this to needs_predicate it will be easier to understand. ------------- PR: https://git.openjdk.java.net/jdk/pull/8035 From sspitsyn at openjdk.java.net Thu Apr 28 02:24:53 2022 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Thu, 28 Apr 2022 02:24:53 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 19:00:52 GMT, Coleen Phillimore wrote: >> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: >> >> Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e > > src/hotspot/share/prims/jvmtiEnvBase.cpp line 2388: > >> 2386: } >> 2387: >> 2388: void > > @sspitsyn We should clean up this aberrant style of putting the return type on the line before the rest of the function declaration after this integration. It looks so strange. I noticed that it's pre-existing for other functions in this file. I'm okay to follow any style. We can do it after the integration. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From yadongwang at openjdk.java.net Thu Apr 28 04:10:15 2022 From: yadongwang at openjdk.java.net (Yadong Wang) Date: Thu, 28 Apr 2022 04:10:15 GMT Subject: RFR: 8285699: riscv: Provide information when hitting a HaltNode Message-ID: The code generated in MacroAssembler::stop is indeed grossly bloated with pusha()/popa() and a native call. We would like to follow the implementation in aarch64 port [JDK-8245986](https://bugs.openjdk.java.net/browse/JDK-8245986), and provide a halt reason when hitting a C2 HaltNode on riscv, and implement it by triggering illegal instruction exceptions. hs_err_pid log BEFORE: # # A fatal error has been detected by the Java Runtime Environment: # # SIGILL (0x4) at pc=0x0000003fdd049cd0, pid=2203593, tid=2203614 # # JRE version: OpenJDK Runtime Environment (19.0) (fastdebug build 19-internal-adhoc.wangyadong.jdk) # Java VM: OpenJDK 64-Bit Server VM (fastdebug 19-internal-adhoc.wangyadong.jdk, compiled mode, compressed oops, compressed class ptrs, g1 gc, linux-riscv64) # Problematic frame: # J 20 c2 compiler.unsafe.TestUnsafeLoadWithZeroAddress.main([Ljava/lang/String;)V (13 bytes) @ 0x0000003fdd049cd0 [0x0000003fdd049c40+0x0000000000000090] # # No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # If you would like to submit a bug report, please visit: # https://bugreport.java.com/bugreport/crash.jsp # --------------- S U M M A R Y ------------ Command Line: -Dtest.vm.opts= -Dtest.tool.vm.opts= -Dtest.compiler.opts= -Dtest.java.opts= -Dtest.jdk=/home/wangyadong/openjdk-19-internal-before -Dcompile.jdk=/home/wangyadong/openjdk-19-internal-before -Dtest.timeout.factor=1.0 -Dtest.root=/home/wangyadong/riscv-port/test/hotspot/jtreg -Dtest.name=compiler/unsafe/TestUnsafeLoadWithZeroAddress.java -Dtest.file=/home/wangyadong/riscv-port/test/hotspot/jtreg/compiler/unsafe/TestUnsafeLoadWithZeroAddress.java -Dtest.src=/home/wangyadong/riscv-port/test/hotspot/jtreg/compiler/unsafe -Dtest.src.path=/home/wangyadong/riscv-port/test/hotspot/jtreg/compiler/unsafe -Dtest.classes=/home/wangyadong/riscv-port/JTwork/classes/compiler/unsafe/TestUnsafeLoadWithZeroAddress.d -Dtest.class.path=/home/wangyadong/riscv-port/JTwork/classes/compiler/unsafe/TestUnsafeLoadWithZeroAddress.d -Dtest.modules=java.base/jdk.internal.misc:+open --add-modules=java.base --add-exports=java.base/jdk.internal.misc=ALL-UNNAMED --add-opens=java.base/jdk.internal.misc=A LL-UNNAMED -Xcomp -Xbatch -XX:-TieredCompilation -XX:+AlwaysIncrementalInline -XX:CompileCommand=compileonly,compiler.unsafe.TestUnsafeLoadWithZeroAddress::* com.sun.javatest.regtest.agent.MainWrapper /home/wangyadong/riscv-port/JTwork/compiler/unsafe/TestUnsafeLoadWithZeroAddress.d/main.0.jta Host: ubuntu, RISCV64, 4 cores, 15G, Ubuntu 21.04 Time: Thu Apr 28 00:00:50 2022 CST elapsed time: 4.374528 seconds (0d 0h 0m 4s) --------------- T H R E A D --------------- Current thread (0x0000003fe8471060): JavaThread "MainThread" [_thread_in_Java, id=2203614, stack(0x0000003fc47a4000,0x0000003fc49a4000)] Stack: [0x0000003fc47a4000,0x0000003fc49a4000], sp=0x0000003fc49a1f00, free space=2039k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) J 20 c2 compiler.unsafe.TestUnsafeLoadWithZeroAddress.main([Ljava/lang/String;)V (13 bytes) @ 0x0000003fdd049cd0 [0x0000003fdd049c40+0x0000000000000090] j java.lang.invoke.LambdaForm$DMH+0x0000000800080800.invokeStatic(Ljava/lang/Object;Ljava/lang/Object;)V+10 java.base at 19-internal j java.lang.invoke.LambdaForm$MH+0x0000000800081c00.invoke(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;+33 java.base at 19-internal j java.lang.invoke.Invokers$Holder.invokeExact_MT(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;+20 java.base at 19-internal j jdk.internal.reflect.DirectMethodHandleAccessor.invokeImpl(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+55 java.base at 19-internal j jdk.internal.reflect.DirectMethodHandleAccessor.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+23 java.base at 19-internal j java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+102 java.base at 19-internal j com.sun.javatest.regtest.agent.MainWrapper$MainThread.run()V+172 j java.lang.Thread.run()V+11 java.base at 19-internal v ~StubRoutines::call_stub V [libjvm.so+0xa8a0fe] JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)+0x4cc V [libjvm.so+0xa8a674] JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)+0x3e0 V [libjvm.so+0xa8aa02] JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*)+0x60 V [libjvm.so+0xbcf9b4] thread_entry(JavaThread*, JavaThread*)+0x88 V [libjvm.so+0x1299d94] JavaThread::thread_main_inner()+0x24e V [libjvm.so+0x12a0cd4] Thread::call_run()+0xd4 V [libjvm.so+0xf3c52e] thread_native_entry(Thread*)+0xee C [libpthread.so.0+0x7460] start_thread+0xb4 C [libc.so.6+0xa7362] hs_err_pid log AFTER: # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (0xe0000000), pid=2178405, tid=2178428 # stop: unsafe off-heap access with zero address # # JRE version: OpenJDK Runtime Environment (19.0) (fastdebug build 19-internal-adhoc.wangyadong.jdk) # Java VM: OpenJDK 64-Bit Server VM (fastdebug 19-internal-adhoc.wangyadong.jdk, compiled mode, compressed oops, compressed class ptrs, g1 gc, linux-riscv64) # Problematic frame: # J 20 c2 compiler.unsafe.TestUnsafeLoadWithZeroAddress.main([Ljava/lang/String;)V (13 bytes) @ 0x0000003fe0f4c5d0 [0x0000003fe0f4c540+0x0000000000000090] # # No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # If you would like to submit a bug report, please visit: # https://bugreport.java.com/bugreport/crash.jsp # --------------- S U M M A R Y ------------ Command Line: -Dtest.vm.opts= -Dtest.tool.vm.opts= -Dtest.compiler.opts= -Dtest.java.opts= -Dtest.jdk=/home/wangyadong/openjdk-19-internal-fastdebug -Dcompile.jdk=/home/wangyadong/openjdk-19-internal-fastdebug -Dtest.timeout.factor=1.0 -Dtest.root=/home/wangyadong/riscv-port/test/hotspot/jtreg -Dtest.name=compiler/unsafe/TestUnsafeLoadWithZeroAddress.java -Dtest.file=/home/wangyadong/riscv-port/test/hotspot/jtreg/compiler/unsafe/TestUnsafeLoadWithZeroAddress.java -Dtest.src=/home/wangyadong/riscv-port/test/hotspot/jtreg/compiler/unsafe -Dtest.src.path=/home/wangyadong/riscv-port/test/hotspot/jtreg/compiler/unsafe -Dtest.classes=/home/wangyadong/riscv-port/JTwork/classes/compiler/unsafe/TestUnsafeLoadWithZeroAddress.d -Dtest.class.path=/home/wangyadong/riscv-port/JTwork/classes/compiler/unsafe/TestUnsafeLoadWithZeroAddress.d -Dtest.modules=java.base/jdk.internal.misc:+open --add-modules=java.base --add-exports=java.base/jdk.internal.misc=ALL-UNNAMED --add-opens=java.base/jdk.internal. misc=ALL-UNNAMED -Xcomp -Xbatch -XX:-TieredCompilation -XX:+AlwaysIncrementalInline -XX:CompileCommand=compileonly,compiler.unsafe.TestUnsafeLoadWithZeroAddress::* com.sun.javatest.regtest.agent.MainWrapper /home/wangyadong/riscv-port/JTwork/compiler/unsafe/TestUnsafeLoadWithZeroAddress.d/main.0.jta Host: ubuntu, RISCV64, 4 cores, 15G, Ubuntu 21.04 Time: Wed Apr 27 23:41:11 2022 CST elapsed time: 4.469731 seconds (0d 0h 0m 4s) --------------- T H R E A D --------------- Current thread (0x0000003fec45d7a0): JavaThread "MainThread" [_thread_in_Java, id=2178428, stack(0x0000003fc91fe000,0x0000003fc93fe000)] Stack: [0x0000003fc91fe000,0x0000003fc93fe000], sp=0x0000003fc93fbf00, free space=2039k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) J 20 c2 compiler.unsafe.TestUnsafeLoadWithZeroAddress.main([Ljava/lang/String;)V (13 bytes) @ 0x0000003fe0f4c5d0 [0x0000003fe0f4c540+0x0000000000000090] j java.lang.invoke.LambdaForm$DMH+0x00000008000c0000.invokeStatic(Ljava/lang/Object;Ljava/lang/Object;)V+10 java.base at 19-internal j java.lang.invoke.LambdaForm$MH+0x00000008000c1400.invoke(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;+33 java.base at 19-internal j java.lang.invoke.Invokers$Holder.invokeExact_MT(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;+20 java.base at 19-internal j jdk.internal.reflect.DirectMethodHandleAccessor.invokeImpl(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+55 java.base at 19-internal j jdk.internal.reflect.DirectMethodHandleAccessor.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+23 java.base at 19-internal j java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+102 java.base at 19-internal j com.sun.javatest.regtest.agent.MainWrapper$MainThread.run()V+172 j java.lang.Thread.run()V+11 java.base at 19-internal v ~StubRoutines::call_stub V [libjvm.so+0xa8a0d2] JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)+0x4cc V [libjvm.so+0xa8a648] JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)+0x3e0 V [libjvm.so+0xa8a9d6] JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*)+0x60 V [libjvm.so+0xbcf988] thread_entry(JavaThread*, JavaThread*)+0x88 V [libjvm.so+0x1299ca6] JavaThread::thread_main_inner()+0x24e V [libjvm.so+0x12a0be6] Thread::call_run()+0xd4 V [libjvm.so+0xf3c294] thread_native_entry(Thread*)+0xee C [libpthread.so.0+0x7460] start_thread+0xb4 C [libc.so.6+0xa7362] This patch passes hotspot and jdk tiere1 on unmatched, and all jtreg tests are tested on Qemu without new failures. ------------- Commit messages: - 8285699: riscv: Provide information when hitting a HaltNode Changes: https://git.openjdk.java.net/jdk/pull/8442/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8442&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8285699 Stats: 98 lines in 9 files changed: 45 ins; 39 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/8442.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8442/head:pull/8442 PR: https://git.openjdk.java.net/jdk/pull/8442 From smarks at openjdk.java.net Thu Apr 28 05:29:56 2022 From: smarks at openjdk.java.net (Stuart Marks) Date: Thu, 28 Apr 2022 05:29:56 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e Reviewed java.io, java.lang, java.lang.ref. ------------- Marked as reviewed by smarks (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8166 From thartmann at openjdk.java.net Thu Apr 28 05:34:31 2022 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Thu, 28 Apr 2022 05:34:31 GMT Subject: RFR: 8285301: C2: assert(!requires_atomic_access) failed: can't ensure atomicity [v2] In-Reply-To: References: Message-ID: > We hit asserts in `BarrierSetC2::load_at_resolved` and `BarrierSetC2::store_at_resolved` when running with `-XX:+AlwaysAtomicAccesses` because the corresponding code paths have not been implemented yet. Although the assert triggers on all platforms, it only affects long and double accesses on 32-bit systems (everything else is atomic anyway). > > I moved the `requires_atomic_access` logic into `LoadNode::make` and `StoreNode::make` and refactored related code. > > I noticed that `LoadNode::convert_to_reinterpret_load` and `StoreNode::convert_to_reinterpret_store` did not properly check for `requires_atomic_access` and fixed that as well. > > I'm currently running all tests with `-XX:+AlwaysAtomicAccesses`. > > Thanks, > Tobias Tobias Hartmann has updated the pull request incrementally with two additional commits since the last revision: - Removed default arg - Invoking Opcode only once. Added comment to test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8422/files - new: https://git.openjdk.java.net/jdk/pull/8422/files/3785374e..07926a58 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8422&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8422&range=00-01 Stats: 18 lines in 5 files changed: 4 ins; 0 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/8422.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8422/head:pull/8422 PR: https://git.openjdk.java.net/jdk/pull/8422 From thartmann at openjdk.java.net Thu Apr 28 05:34:31 2022 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Thu, 28 Apr 2022 05:34:31 GMT Subject: RFR: 8285301: C2: assert(!requires_atomic_access) failed: can't ensure atomicity [v2] In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 05:30:30 GMT, Tobias Hartmann wrote: >> We hit asserts in `BarrierSetC2::load_at_resolved` and `BarrierSetC2::store_at_resolved` when running with `-XX:+AlwaysAtomicAccesses` because the corresponding code paths have not been implemented yet. Although the assert triggers on all platforms, it only affects long and double accesses on 32-bit systems (everything else is atomic anyway). >> >> I moved the `requires_atomic_access` logic into `LoadNode::make` and `StoreNode::make` and refactored related code. >> >> I noticed that `LoadNode::convert_to_reinterpret_load` and `StoreNode::convert_to_reinterpret_store` did not properly check for `requires_atomic_access` and fixed that as well. >> >> I'm currently running all tests with `-XX:+AlwaysAtomicAccesses`. >> >> Thanks, >> Tobias > > Tobias Hartmann has updated the pull request incrementally with two additional commits since the last revision: > > - Removed default arg > - Invoking Opcode only once. Added comment to test Thanks for the reviews, Vladimir and Dean. > The new TestAlwaysAtomicAccesses test seems suspiciously simple. I guess the idea is to catch issues during startup with -Xcomp. A comment saying that could prevent someone from thinking the test does nothing. Right, we have quite a few such tests for flags that are rarely used. A simple run with `-Xcomp` is enough to trigger the originally report issues. More issues are then triggered by the other tests that I modified. I added a comment explaining the purpose. ------------- PR: https://git.openjdk.java.net/jdk/pull/8422 From thartmann at openjdk.java.net Thu Apr 28 05:34:32 2022 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Thu, 28 Apr 2022 05:34:32 GMT Subject: RFR: 8285301: C2: assert(!requires_atomic_access) failed: can't ensure atomicity [v2] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 20:07:28 GMT, Vladimir Kozlov wrote: >> Tobias Hartmann has updated the pull request incrementally with two additional commits since the last revision: >> >> - Removed default arg >> - Invoking Opcode only once. Added comment to test > > src/hotspot/share/opto/memnode.cpp line 1322: > >> 1320: assert(has_reinterpret_variant(vt), "no reinterpret variant: %s %s", Name(), type2name(bt)); >> 1321: bool require_atomic_access = (Opcode() == Op_StoreL && ((StoreLNode*)this)->require_atomic_access()) || >> 1322: (Opcode() == Op_StoreD && ((StoreDNode*)this)->require_atomic_access()); > > Call `Opcode()` once. Done. > src/hotspot/share/opto/memnode.hpp line 610: > >> 608: static StoreNode* make(PhaseGVN& gvn, Node* c, Node* mem, Node* adr, >> 609: const TypePtr* at, Node* val, BasicType bt, >> 610: MemOrd mo = MemNode::unordered, bool require_atomic_access = false); > > I think it was intentionally `MemOrd mo` parameter did not specify default value so that value is always specified at all call sites. I think this change is not required for the fix. Okay, I reverted that change. ------------- PR: https://git.openjdk.java.net/jdk/pull/8422 From yadongwang at openjdk.java.net Thu Apr 28 06:10:18 2022 From: yadongwang at openjdk.java.net (Yadong Wang) Date: Thu, 28 Apr 2022 06:10:18 GMT Subject: RFR: 8285699: riscv: Provide information when hitting a HaltNode [v2] In-Reply-To: References: Message-ID: > The code generated in MacroAssembler::stop is indeed grossly bloated with pusha()/popa() and a native call. We would like to follow the implementation in aarch64 port [JDK-8245986](https://bugs.openjdk.java.net/browse/JDK-8245986), and provide a halt reason when hitting a C2 HaltNode on riscv, and implement it by triggering illegal instruction exceptions. > > hs_err_pid log BEFORE: > > # > # A fatal error has been detected by the Java Runtime Environment: > # > # SIGILL (0x4) at pc=0x0000003fdd049cd0, pid=2203593, tid=2203614 > # > # JRE version: OpenJDK Runtime Environment (19.0) (fastdebug build 19-internal-adhoc.wangyadong.jdk) > # Java VM: OpenJDK 64-Bit Server VM (fastdebug 19-internal-adhoc.wangyadong.jdk, compiled mode, compressed oops, compressed class ptrs, g1 gc, linux-riscv64) > # Problematic frame: > # J 20 c2 compiler.unsafe.TestUnsafeLoadWithZeroAddress.main([Ljava/lang/String;)V (13 bytes) @ 0x0000003fdd049cd0 [0x0000003fdd049c40+0x0000000000000090] > # > # No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again > # > # If you would like to submit a bug report, please visit: > # https://bugreport.java.com/bugreport/crash.jsp > # > > --------------- S U M M A R Y ------------ > > Command Line: -Dtest.vm.opts= -Dtest.tool.vm.opts= -Dtest.compiler.opts= -Dtest.java.opts= -Dtest.jdk=/home/wangyadong/openjdk-19-internal-before -Dcompile.jdk=/home/wangyadong/openjdk-19-internal-before -Dtest.timeout.factor=1.0 -Dtest.root=/home/wangyadong/riscv-port/test/hotspot/jtreg -Dtest.name=compiler/unsafe/TestUnsafeLoadWithZeroAddress.java -Dtest.file=/home/wangyadong/riscv-port/test/hotspot/jtreg/compiler/unsafe/TestUnsafeLoadWithZeroAddress.java -Dtest.src=/home/wangyadong/riscv-port/test/hotspot/jtreg/compiler/unsafe -Dtest.src.path=/home/wangyadong/riscv-port/test/hotspot/jtreg/compiler/unsafe -Dtest.classes=/home/wangyadong/riscv-port/JTwork/classes/compiler/unsafe/TestUnsafeLoadWithZeroAddress.d -Dtest.class.path=/home/wangyadong/riscv-port/JTwork/classes/compiler/unsafe/TestUnsafeLoadWithZeroAddress.d -Dtest.modules=java.base/jdk.internal.misc:+open --add-modules=java.base --add-exports=java.base/jdk.internal.misc=ALL-UNNAMED --add-opens=java.base/jdk.internal.misc =ALL-UNNAMED -Xcomp -Xbatch -XX:-TieredCompilation -XX:+AlwaysIncrementalInline -XX:CompileCommand=compileonly,compiler.unsafe.TestUnsafeLoadWithZeroAddress::* com.sun.javatest.regtest.agent.MainWrapper /home/wangyadong/riscv-port/JTwork/compiler/unsafe/TestUnsafeLoadWithZeroAddress.d/main.0.jta > > Host: ubuntu, RISCV64, 4 cores, 15G, Ubuntu 21.04 > Time: Thu Apr 28 00:00:50 2022 CST elapsed time: 4.374528 seconds (0d 0h 0m 4s) > > --------------- T H R E A D --------------- > > Current thread (0x0000003fe8471060): JavaThread "MainThread" [_thread_in_Java, id=2203614, stack(0x0000003fc47a4000,0x0000003fc49a4000)] > > Stack: [0x0000003fc47a4000,0x0000003fc49a4000], sp=0x0000003fc49a1f00, free space=2039k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > J 20 c2 compiler.unsafe.TestUnsafeLoadWithZeroAddress.main([Ljava/lang/String;)V (13 bytes) @ 0x0000003fdd049cd0 [0x0000003fdd049c40+0x0000000000000090] > j java.lang.invoke.LambdaForm$DMH+0x0000000800080800.invokeStatic(Ljava/lang/Object;Ljava/lang/Object;)V+10 java.base at 19-internal > j java.lang.invoke.LambdaForm$MH+0x0000000800081c00.invoke(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;+33 java.base at 19-internal > j java.lang.invoke.Invokers$Holder.invokeExact_MT(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;+20 java.base at 19-internal > j jdk.internal.reflect.DirectMethodHandleAccessor.invokeImpl(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+55 java.base at 19-internal > j jdk.internal.reflect.DirectMethodHandleAccessor.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+23 java.base at 19-internal > j java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+102 java.base at 19-internal > j com.sun.javatest.regtest.agent.MainWrapper$MainThread.run()V+172 > j java.lang.Thread.run()V+11 java.base at 19-internal > v ~StubRoutines::call_stub > V [libjvm.so+0xa8a0fe] JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)+0x4cc > V [libjvm.so+0xa8a674] JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)+0x3e0 > V [libjvm.so+0xa8aa02] JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*)+0x60 > V [libjvm.so+0xbcf9b4] thread_entry(JavaThread*, JavaThread*)+0x88 > V [libjvm.so+0x1299d94] JavaThread::thread_main_inner()+0x24e > V [libjvm.so+0x12a0cd4] Thread::call_run()+0xd4 > V [libjvm.so+0xf3c52e] thread_native_entry(Thread*)+0xee > C [libpthread.so.0+0x7460] start_thread+0xb4 > C [libc.so.6+0xa7362] > > hs_err_pid log AFTER: > > # > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (0xe0000000), pid=2178405, tid=2178428 > # stop: unsafe off-heap access with zero address > # > # JRE version: OpenJDK Runtime Environment (19.0) (fastdebug build 19-internal-adhoc.wangyadong.jdk) > # Java VM: OpenJDK 64-Bit Server VM (fastdebug 19-internal-adhoc.wangyadong.jdk, compiled mode, compressed oops, compressed class ptrs, g1 gc, linux-riscv64) > # Problematic frame: > # J 20 c2 compiler.unsafe.TestUnsafeLoadWithZeroAddress.main([Ljava/lang/String;)V (13 bytes) @ 0x0000003fe0f4c5d0 [0x0000003fe0f4c540+0x0000000000000090] > # > # No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again > # > # If you would like to submit a bug report, please visit: > # https://bugreport.java.com/bugreport/crash.jsp > # > > --------------- S U M M A R Y ------------ > > Command Line: -Dtest.vm.opts= -Dtest.tool.vm.opts= -Dtest.compiler.opts= -Dtest.java.opts= -Dtest.jdk=/home/wangyadong/openjdk-19-internal-fastdebug -Dcompile.jdk=/home/wangyadong/openjdk-19-internal-fastdebug -Dtest.timeout.factor=1.0 -Dtest.root=/home/wangyadong/riscv-port/test/hotspot/jtreg -Dtest.name=compiler/unsafe/TestUnsafeLoadWithZeroAddress.java -Dtest.file=/home/wangyadong/riscv-port/test/hotspot/jtreg/compiler/unsafe/TestUnsafeLoadWithZeroAddress.java -Dtest.src=/home/wangyadong/riscv-port/test/hotspot/jtreg/compiler/unsafe -Dtest.src.path=/home/wangyadong/riscv-port/test/hotspot/jtreg/compiler/unsafe -Dtest.classes=/home/wangyadong/riscv-port/JTwork/classes/compiler/unsafe/TestUnsafeLoadWithZeroAddress.d -Dtest.class.path=/home/wangyadong/riscv-port/JTwork/classes/compiler/unsafe/TestUnsafeLoadWithZeroAddress.d -Dtest.modules=java.base/jdk.internal.misc:+open --add-modules=java.base --add-exports=java.base/jdk.internal.misc=ALL-UNNAMED --add-opens=java.base/jdk.interna l.misc=ALL-UNNAMED -Xcomp -Xbatch -XX:-TieredCompilation -XX:+AlwaysIncrementalInline -XX:CompileCommand=compileonly,compiler.unsafe.TestUnsafeLoadWithZeroAddress::* com.sun.javatest.regtest.agent.MainWrapper /home/wangyadong/riscv-port/JTwork/compiler/unsafe/TestUnsafeLoadWithZeroAddress.d/main.0.jta > > Host: ubuntu, RISCV64, 4 cores, 15G, Ubuntu 21.04 > Time: Wed Apr 27 23:41:11 2022 CST elapsed time: 4.469731 seconds (0d 0h 0m 4s) > > --------------- T H R E A D --------------- > > Current thread (0x0000003fec45d7a0): JavaThread "MainThread" [_thread_in_Java, id=2178428, stack(0x0000003fc91fe000,0x0000003fc93fe000)] > > Stack: [0x0000003fc91fe000,0x0000003fc93fe000], sp=0x0000003fc93fbf00, free space=2039k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > J 20 c2 compiler.unsafe.TestUnsafeLoadWithZeroAddress.main([Ljava/lang/String;)V (13 bytes) @ 0x0000003fe0f4c5d0 [0x0000003fe0f4c540+0x0000000000000090] > j java.lang.invoke.LambdaForm$DMH+0x00000008000c0000.invokeStatic(Ljava/lang/Object;Ljava/lang/Object;)V+10 java.base at 19-internal > j java.lang.invoke.LambdaForm$MH+0x00000008000c1400.invoke(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;+33 java.base at 19-internal > j java.lang.invoke.Invokers$Holder.invokeExact_MT(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;+20 java.base at 19-internal > j jdk.internal.reflect.DirectMethodHandleAccessor.invokeImpl(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+55 java.base at 19-internal > j jdk.internal.reflect.DirectMethodHandleAccessor.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+23 java.base at 19-internal > j java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+102 java.base at 19-internal > j com.sun.javatest.regtest.agent.MainWrapper$MainThread.run()V+172 > j java.lang.Thread.run()V+11 java.base at 19-internal > v ~StubRoutines::call_stub > V [libjvm.so+0xa8a0d2] JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)+0x4cc > V [libjvm.so+0xa8a648] JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)+0x3e0 > V [libjvm.so+0xa8a9d6] JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*)+0x60 > V [libjvm.so+0xbcf988] thread_entry(JavaThread*, JavaThread*)+0x88 > V [libjvm.so+0x1299ca6] JavaThread::thread_main_inner()+0x24e > V [libjvm.so+0x12a0be6] Thread::call_run()+0xd4 > V [libjvm.so+0xf3c294] thread_native_entry(Thread*)+0xee > C [libpthread.so.0+0x7460] start_thread+0xb4 > C [libc.so.6+0xa7362] > > > This patch passes hotspot and jdk tiere1 on unmatched, and all jtreg tests are tested on Qemu without new failures. Yadong Wang has updated the pull request incrementally with one additional commit since the last revision: fix comment typo ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8442/files - new: https://git.openjdk.java.net/jdk/pull/8442/files/d50899ba..2968c6b8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8442&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8442&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/8442.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8442/head:pull/8442 PR: https://git.openjdk.java.net/jdk/pull/8442 From yadongwang at openjdk.java.net Thu Apr 28 06:20:20 2022 From: yadongwang at openjdk.java.net (Yadong Wang) Date: Thu, 28 Apr 2022 06:20:20 GMT Subject: RFR: 8285699: riscv: Provide information when hitting a HaltNode [v3] In-Reply-To: References: Message-ID: <3Hfnc5vgI3_15Vjrre-bc5Uc2aJG3b6IQd83hQQOUy4=.abd3b67c-f9eb-4c0b-bac1-5fbb8de92b3e@github.com> > The code generated in MacroAssembler::stop is indeed grossly bloated with pusha()/popa() and a native call. We would like to follow the implementation in aarch64 port [JDK-8245986](https://bugs.openjdk.java.net/browse/JDK-8245986), and provide a halt reason when hitting a C2 HaltNode on riscv, and implement it by triggering illegal instruction exceptions. > > hs_err_pid log BEFORE: > > # > # A fatal error has been detected by the Java Runtime Environment: > # > # SIGILL (0x4) at pc=0x0000003fdd049cd0, pid=2203593, tid=2203614 > # > # JRE version: OpenJDK Runtime Environment (19.0) (fastdebug build 19-internal-adhoc.wangyadong.jdk) > # Java VM: OpenJDK 64-Bit Server VM (fastdebug 19-internal-adhoc.wangyadong.jdk, compiled mode, compressed oops, compressed class ptrs, g1 gc, linux-riscv64) > # Problematic frame: > # J 20 c2 compiler.unsafe.TestUnsafeLoadWithZeroAddress.main([Ljava/lang/String;)V (13 bytes) @ 0x0000003fdd049cd0 [0x0000003fdd049c40+0x0000000000000090] > # > # No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again > # > # If you would like to submit a bug report, please visit: > # https://bugreport.java.com/bugreport/crash.jsp > # > > --------------- S U M M A R Y ------------ > > Command Line: -Dtest.vm.opts= -Dtest.tool.vm.opts= -Dtest.compiler.opts= -Dtest.java.opts= -Dtest.jdk=/home/wangyadong/openjdk-19-internal-before -Dcompile.jdk=/home/wangyadong/openjdk-19-internal-before -Dtest.timeout.factor=1.0 -Dtest.root=/home/wangyadong/riscv-port/test/hotspot/jtreg -Dtest.name=compiler/unsafe/TestUnsafeLoadWithZeroAddress.java -Dtest.file=/home/wangyadong/riscv-port/test/hotspot/jtreg/compiler/unsafe/TestUnsafeLoadWithZeroAddress.java -Dtest.src=/home/wangyadong/riscv-port/test/hotspot/jtreg/compiler/unsafe -Dtest.src.path=/home/wangyadong/riscv-port/test/hotspot/jtreg/compiler/unsafe -Dtest.classes=/home/wangyadong/riscv-port/JTwork/classes/compiler/unsafe/TestUnsafeLoadWithZeroAddress.d -Dtest.class.path=/home/wangyadong/riscv-port/JTwork/classes/compiler/unsafe/TestUnsafeLoadWithZeroAddress.d -Dtest.modules=java.base/jdk.internal.misc:+open --add-modules=java.base --add-exports=java.base/jdk.internal.misc=ALL-UNNAMED --add-opens=java.base/jdk.internal.misc =ALL-UNNAMED -Xcomp -Xbatch -XX:-TieredCompilation -XX:+AlwaysIncrementalInline -XX:CompileCommand=compileonly,compiler.unsafe.TestUnsafeLoadWithZeroAddress::* com.sun.javatest.regtest.agent.MainWrapper /home/wangyadong/riscv-port/JTwork/compiler/unsafe/TestUnsafeLoadWithZeroAddress.d/main.0.jta > > Host: ubuntu, RISCV64, 4 cores, 15G, Ubuntu 21.04 > Time: Thu Apr 28 00:00:50 2022 CST elapsed time: 4.374528 seconds (0d 0h 0m 4s) > > --------------- T H R E A D --------------- > > Current thread (0x0000003fe8471060): JavaThread "MainThread" [_thread_in_Java, id=2203614, stack(0x0000003fc47a4000,0x0000003fc49a4000)] > > Stack: [0x0000003fc47a4000,0x0000003fc49a4000], sp=0x0000003fc49a1f00, free space=2039k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > J 20 c2 compiler.unsafe.TestUnsafeLoadWithZeroAddress.main([Ljava/lang/String;)V (13 bytes) @ 0x0000003fdd049cd0 [0x0000003fdd049c40+0x0000000000000090] > j java.lang.invoke.LambdaForm$DMH+0x0000000800080800.invokeStatic(Ljava/lang/Object;Ljava/lang/Object;)V+10 java.base at 19-internal > j java.lang.invoke.LambdaForm$MH+0x0000000800081c00.invoke(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;+33 java.base at 19-internal > j java.lang.invoke.Invokers$Holder.invokeExact_MT(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;+20 java.base at 19-internal > j jdk.internal.reflect.DirectMethodHandleAccessor.invokeImpl(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+55 java.base at 19-internal > j jdk.internal.reflect.DirectMethodHandleAccessor.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+23 java.base at 19-internal > j java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+102 java.base at 19-internal > j com.sun.javatest.regtest.agent.MainWrapper$MainThread.run()V+172 > j java.lang.Thread.run()V+11 java.base at 19-internal > v ~StubRoutines::call_stub > V [libjvm.so+0xa8a0fe] JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)+0x4cc > V [libjvm.so+0xa8a674] JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)+0x3e0 > V [libjvm.so+0xa8aa02] JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*)+0x60 > V [libjvm.so+0xbcf9b4] thread_entry(JavaThread*, JavaThread*)+0x88 > V [libjvm.so+0x1299d94] JavaThread::thread_main_inner()+0x24e > V [libjvm.so+0x12a0cd4] Thread::call_run()+0xd4 > V [libjvm.so+0xf3c52e] thread_native_entry(Thread*)+0xee > C [libpthread.so.0+0x7460] start_thread+0xb4 > C [libc.so.6+0xa7362] > > hs_err_pid log AFTER: > > # > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (0xe0000000), pid=2178405, tid=2178428 > # stop: unsafe off-heap access with zero address > # > # JRE version: OpenJDK Runtime Environment (19.0) (fastdebug build 19-internal-adhoc.wangyadong.jdk) > # Java VM: OpenJDK 64-Bit Server VM (fastdebug 19-internal-adhoc.wangyadong.jdk, compiled mode, compressed oops, compressed class ptrs, g1 gc, linux-riscv64) > # Problematic frame: > # J 20 c2 compiler.unsafe.TestUnsafeLoadWithZeroAddress.main([Ljava/lang/String;)V (13 bytes) @ 0x0000003fe0f4c5d0 [0x0000003fe0f4c540+0x0000000000000090] > # > # No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again > # > # If you would like to submit a bug report, please visit: > # https://bugreport.java.com/bugreport/crash.jsp > # > > --------------- S U M M A R Y ------------ > > Command Line: -Dtest.vm.opts= -Dtest.tool.vm.opts= -Dtest.compiler.opts= -Dtest.java.opts= -Dtest.jdk=/home/wangyadong/openjdk-19-internal-fastdebug -Dcompile.jdk=/home/wangyadong/openjdk-19-internal-fastdebug -Dtest.timeout.factor=1.0 -Dtest.root=/home/wangyadong/riscv-port/test/hotspot/jtreg -Dtest.name=compiler/unsafe/TestUnsafeLoadWithZeroAddress.java -Dtest.file=/home/wangyadong/riscv-port/test/hotspot/jtreg/compiler/unsafe/TestUnsafeLoadWithZeroAddress.java -Dtest.src=/home/wangyadong/riscv-port/test/hotspot/jtreg/compiler/unsafe -Dtest.src.path=/home/wangyadong/riscv-port/test/hotspot/jtreg/compiler/unsafe -Dtest.classes=/home/wangyadong/riscv-port/JTwork/classes/compiler/unsafe/TestUnsafeLoadWithZeroAddress.d -Dtest.class.path=/home/wangyadong/riscv-port/JTwork/classes/compiler/unsafe/TestUnsafeLoadWithZeroAddress.d -Dtest.modules=java.base/jdk.internal.misc:+open --add-modules=java.base --add-exports=java.base/jdk.internal.misc=ALL-UNNAMED --add-opens=java.base/jdk.interna l.misc=ALL-UNNAMED -Xcomp -Xbatch -XX:-TieredCompilation -XX:+AlwaysIncrementalInline -XX:CompileCommand=compileonly,compiler.unsafe.TestUnsafeLoadWithZeroAddress::* com.sun.javatest.regtest.agent.MainWrapper /home/wangyadong/riscv-port/JTwork/compiler/unsafe/TestUnsafeLoadWithZeroAddress.d/main.0.jta > > Host: ubuntu, RISCV64, 4 cores, 15G, Ubuntu 21.04 > Time: Wed Apr 27 23:41:11 2022 CST elapsed time: 4.469731 seconds (0d 0h 0m 4s) > > --------------- T H R E A D --------------- > > Current thread (0x0000003fec45d7a0): JavaThread "MainThread" [_thread_in_Java, id=2178428, stack(0x0000003fc91fe000,0x0000003fc93fe000)] > > Stack: [0x0000003fc91fe000,0x0000003fc93fe000], sp=0x0000003fc93fbf00, free space=2039k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > J 20 c2 compiler.unsafe.TestUnsafeLoadWithZeroAddress.main([Ljava/lang/String;)V (13 bytes) @ 0x0000003fe0f4c5d0 [0x0000003fe0f4c540+0x0000000000000090] > j java.lang.invoke.LambdaForm$DMH+0x00000008000c0000.invokeStatic(Ljava/lang/Object;Ljava/lang/Object;)V+10 java.base at 19-internal > j java.lang.invoke.LambdaForm$MH+0x00000008000c1400.invoke(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;+33 java.base at 19-internal > j java.lang.invoke.Invokers$Holder.invokeExact_MT(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;+20 java.base at 19-internal > j jdk.internal.reflect.DirectMethodHandleAccessor.invokeImpl(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+55 java.base at 19-internal > j jdk.internal.reflect.DirectMethodHandleAccessor.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+23 java.base at 19-internal > j java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+102 java.base at 19-internal > j com.sun.javatest.regtest.agent.MainWrapper$MainThread.run()V+172 > j java.lang.Thread.run()V+11 java.base at 19-internal > v ~StubRoutines::call_stub > V [libjvm.so+0xa8a0d2] JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)+0x4cc > V [libjvm.so+0xa8a648] JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)+0x3e0 > V [libjvm.so+0xa8a9d6] JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*)+0x60 > V [libjvm.so+0xbcf988] thread_entry(JavaThread*, JavaThread*)+0x88 > V [libjvm.so+0x1299ca6] JavaThread::thread_main_inner()+0x24e > V [libjvm.so+0x12a0be6] Thread::call_run()+0xd4 > V [libjvm.so+0xf3c294] thread_native_entry(Thread*)+0xee > C [libpthread.so.0+0x7460] start_thread+0xb4 > C [libc.so.6+0xa7362] > > > This patch passes hotspot and jdk tiere1 on unmatched, and all jtreg tests are tested on Qemu without new failures. Yadong Wang has updated the pull request incrementally with one additional commit since the last revision: fix typo ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8442/files - new: https://git.openjdk.java.net/jdk/pull/8442/files/2968c6b8..9e2a2d30 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8442&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8442&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8442.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8442/head:pull/8442 PR: https://git.openjdk.java.net/jdk/pull/8442 From jbhateja at openjdk.java.net Thu Apr 28 06:30:42 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Thu, 28 Apr 2022 06:30:42 GMT Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE with predicate feature [v2] In-Reply-To: References: <35S4J_r9jBw_-SAow2oMYaSsTvubhSmZFVPb_VM6KEg=.7feff8fa-6e20-453e-aed6-e53c7d9beaad@github.com> <8Yu4J-PCYFJtBXrfgWoCbaR-7QZTXH4IzmXOf_lk164=.66071c45-1f1a-4931-a414-778f353c7e83@github.com> Message-ID: On Wed, 20 Apr 2022 02:44:39 GMT, Xiaohong Gong wrote: >>> The blend should be with the intended-to-store vector, so that masked lanes contain the need-to-store elements and unmasked lanes contain the loaded elements, which would be stored back, which results in unchanged values. >> >> It may not work if memory is beyond legal accessible address space of the process, a corner case could be a page boundary. Thus re-composing the intermediated vector which partially contains actual updates but effectively perform full vector write to destination address may not work in all scenarios. > > Thanks for the comment! So how about adding the check for the valid array range like the masked vector load? > Codes like: > > public final > void intoArray(byte[] a, int offset, > VectorMask m) { > if (m.allTrue()) { > intoArray(a, offset); > } else { > ByteSpecies vsp = vspecies(); > if (offset >= 0 && offset <= (a.length - vsp.length())) { // a full range check > intoArray0(a, offset, m, /* usePred */ false); // can be vectorized by load+blend_store > } else { > checkMaskFromIndexSize(offset, vsp, m, 1, a.length); > intoArray0(a, offset, m, /* usePred */ true); // only be vectorized by the predicated store > } > } > } Thanks, this looks ok since out of range condition will not be intrinsified if targets does not support predicated vector store. ------------- PR: https://git.openjdk.java.net/jdk/pull/8035 From fyang at openjdk.java.net Thu Apr 28 06:47:42 2022 From: fyang at openjdk.java.net (Fei Yang) Date: Thu, 28 Apr 2022 06:47:42 GMT Subject: RFR: 8285699: riscv: Provide information when hitting a HaltNode [v3] In-Reply-To: <3Hfnc5vgI3_15Vjrre-bc5Uc2aJG3b6IQd83hQQOUy4=.abd3b67c-f9eb-4c0b-bac1-5fbb8de92b3e@github.com> References: <3Hfnc5vgI3_15Vjrre-bc5Uc2aJG3b6IQd83hQQOUy4=.abd3b67c-f9eb-4c0b-bac1-5fbb8de92b3e@github.com> Message-ID: <-6jpTfeRfUW79FnbM9kDRvhPdO14bsCTGpHInvqT9Ng=.6f4662c6-29a7-44af-8b2d-e9ff26c29da8@github.com> On Thu, 28 Apr 2022 06:20:20 GMT, Yadong Wang wrote: >> The code generated in MacroAssembler::stop is indeed grossly bloated with pusha()/popa() and a native call. We would like to follow the implementation in aarch64 port [JDK-8245986](https://bugs.openjdk.java.net/browse/JDK-8245986), and provide a halt reason when hitting a C2 HaltNode on riscv, and implement it by triggering illegal instruction exceptions. >> >> hs_err_pid log BEFORE: >> >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # SIGILL (0x4) at pc=0x0000003fdd049cd0, pid=2203593, tid=2203614 >> # >> # JRE version: OpenJDK Runtime Environment (19.0) (fastdebug build 19-internal-adhoc.wangyadong.jdk) >> # Java VM: OpenJDK 64-Bit Server VM (fastdebug 19-internal-adhoc.wangyadong.jdk, compiled mode, compressed oops, compressed class ptrs, g1 gc, linux-riscv64) >> # Problematic frame: >> # J 20 c2 compiler.unsafe.TestUnsafeLoadWithZeroAddress.main([Ljava/lang/String;)V (13 bytes) @ 0x0000003fdd049cd0 [0x0000003fdd049c40+0x0000000000000090] >> # >> # No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again >> # >> # If you would like to submit a bug report, please visit: >> # https://bugreport.java.com/bugreport/crash.jsp >> # >> >> --------------- S U M M A R Y ------------ >> >> Command Line: -Dtest.vm.opts= -Dtest.tool.vm.opts= -Dtest.compiler.opts= -Dtest.java.opts= -Dtest.jdk=/home/wangyadong/openjdk-19-internal-before -Dcompile.jdk=/home/wangyadong/openjdk-19-internal-before -Dtest.timeout.factor=1.0 -Dtest.root=/home/wangyadong/riscv-port/test/hotspot/jtreg -Dtest.name=compiler/unsafe/TestUnsafeLoadWithZeroAddress.java -Dtest.file=/home/wangyadong/riscv-port/test/hotspot/jtreg/compiler/unsafe/TestUnsafeLoadWithZeroAddress.java -Dtest.src=/home/wangyadong/riscv-port/test/hotspot/jtreg/compiler/unsafe -Dtest.src.path=/home/wangyadong/riscv-port/test/hotspot/jtreg/compiler/unsafe -Dtest.classes=/home/wangyadong/riscv-port/JTwork/classes/compiler/unsafe/TestUnsafeLoadWithZeroAddress.d -Dtest.class.path=/home/wangyadong/riscv-port/JTwork/classes/compiler/unsafe/TestUnsafeLoadWithZeroAddress.d -Dtest.modules=java.base/jdk.internal.misc:+open --add-modules=java.base --add-exports=java.base/jdk.internal.misc=ALL-UNNAMED --add-opens=java.base/jdk.internal.mis c=ALL-UNNAMED -Xcomp -Xbatch -XX:-TieredCompilation -XX:+AlwaysIncrementalInline -XX:CompileCommand=compileonly,compiler.unsafe.TestUnsafeLoadWithZeroAddress::* com.sun.javatest.regtest.agent.MainWrapper /home/wangyadong/riscv-port/JTwork/compiler/unsafe/TestUnsafeLoadWithZeroAddress.d/main.0.jta >> >> Host: ubuntu, RISCV64, 4 cores, 15G, Ubuntu 21.04 >> Time: Thu Apr 28 00:00:50 2022 CST elapsed time: 4.374528 seconds (0d 0h 0m 4s) >> >> --------------- T H R E A D --------------- >> >> Current thread (0x0000003fe8471060): JavaThread "MainThread" [_thread_in_Java, id=2203614, stack(0x0000003fc47a4000,0x0000003fc49a4000)] >> >> Stack: [0x0000003fc47a4000,0x0000003fc49a4000], sp=0x0000003fc49a1f00, free space=2039k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) >> J 20 c2 compiler.unsafe.TestUnsafeLoadWithZeroAddress.main([Ljava/lang/String;)V (13 bytes) @ 0x0000003fdd049cd0 [0x0000003fdd049c40+0x0000000000000090] >> j java.lang.invoke.LambdaForm$DMH+0x0000000800080800.invokeStatic(Ljava/lang/Object;Ljava/lang/Object;)V+10 java.base at 19-internal >> j java.lang.invoke.LambdaForm$MH+0x0000000800081c00.invoke(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;+33 java.base at 19-internal >> j java.lang.invoke.Invokers$Holder.invokeExact_MT(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;+20 java.base at 19-internal >> j jdk.internal.reflect.DirectMethodHandleAccessor.invokeImpl(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+55 java.base at 19-internal >> j jdk.internal.reflect.DirectMethodHandleAccessor.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+23 java.base at 19-internal >> j java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+102 java.base at 19-internal >> j com.sun.javatest.regtest.agent.MainWrapper$MainThread.run()V+172 >> j java.lang.Thread.run()V+11 java.base at 19-internal >> v ~StubRoutines::call_stub >> V [libjvm.so+0xa8a0fe] JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)+0x4cc >> V [libjvm.so+0xa8a674] JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)+0x3e0 >> V [libjvm.so+0xa8aa02] JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*)+0x60 >> V [libjvm.so+0xbcf9b4] thread_entry(JavaThread*, JavaThread*)+0x88 >> V [libjvm.so+0x1299d94] JavaThread::thread_main_inner()+0x24e >> V [libjvm.so+0x12a0cd4] Thread::call_run()+0xd4 >> V [libjvm.so+0xf3c52e] thread_native_entry(Thread*)+0xee >> C [libpthread.so.0+0x7460] start_thread+0xb4 >> C [libc.so.6+0xa7362] >> >> hs_err_pid log AFTER: >> >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # Internal Error (0xe0000000), pid=2178405, tid=2178428 >> # stop: unsafe off-heap access with zero address >> # >> # JRE version: OpenJDK Runtime Environment (19.0) (fastdebug build 19-internal-adhoc.wangyadong.jdk) >> # Java VM: OpenJDK 64-Bit Server VM (fastdebug 19-internal-adhoc.wangyadong.jdk, compiled mode, compressed oops, compressed class ptrs, g1 gc, linux-riscv64) >> # Problematic frame: >> # J 20 c2 compiler.unsafe.TestUnsafeLoadWithZeroAddress.main([Ljava/lang/String;)V (13 bytes) @ 0x0000003fe0f4c5d0 [0x0000003fe0f4c540+0x0000000000000090] >> # >> # No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again >> # >> # If you would like to submit a bug report, please visit: >> # https://bugreport.java.com/bugreport/crash.jsp >> # >> >> --------------- S U M M A R Y ------------ >> >> Command Line: -Dtest.vm.opts= -Dtest.tool.vm.opts= -Dtest.compiler.opts= -Dtest.java.opts= -Dtest.jdk=/home/wangyadong/openjdk-19-internal-fastdebug -Dcompile.jdk=/home/wangyadong/openjdk-19-internal-fastdebug -Dtest.timeout.factor=1.0 -Dtest.root=/home/wangyadong/riscv-port/test/hotspot/jtreg -Dtest.name=compiler/unsafe/TestUnsafeLoadWithZeroAddress.java -Dtest.file=/home/wangyadong/riscv-port/test/hotspot/jtreg/compiler/unsafe/TestUnsafeLoadWithZeroAddress.java -Dtest.src=/home/wangyadong/riscv-port/test/hotspot/jtreg/compiler/unsafe -Dtest.src.path=/home/wangyadong/riscv-port/test/hotspot/jtreg/compiler/unsafe -Dtest.classes=/home/wangyadong/riscv-port/JTwork/classes/compiler/unsafe/TestUnsafeLoadWithZeroAddress.d -Dtest.class.path=/home/wangyadong/riscv-port/JTwork/classes/compiler/unsafe/TestUnsafeLoadWithZeroAddress.d -Dtest.modules=java.base/jdk.internal.misc:+open --add-modules=java.base --add-exports=java.base/jdk.internal.misc=ALL-UNNAMED --add-opens=java.base/jdk.intern al.misc=ALL-UNNAMED -Xcomp -Xbatch -XX:-TieredCompilation -XX:+AlwaysIncrementalInline -XX:CompileCommand=compileonly,compiler.unsafe.TestUnsafeLoadWithZeroAddress::* com.sun.javatest.regtest.agent.MainWrapper /home/wangyadong/riscv-port/JTwork/compiler/unsafe/TestUnsafeLoadWithZeroAddress.d/main.0.jta >> >> Host: ubuntu, RISCV64, 4 cores, 15G, Ubuntu 21.04 >> Time: Wed Apr 27 23:41:11 2022 CST elapsed time: 4.469731 seconds (0d 0h 0m 4s) >> >> --------------- T H R E A D --------------- >> >> Current thread (0x0000003fec45d7a0): JavaThread "MainThread" [_thread_in_Java, id=2178428, stack(0x0000003fc91fe000,0x0000003fc93fe000)] >> >> Stack: [0x0000003fc91fe000,0x0000003fc93fe000], sp=0x0000003fc93fbf00, free space=2039k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) >> J 20 c2 compiler.unsafe.TestUnsafeLoadWithZeroAddress.main([Ljava/lang/String;)V (13 bytes) @ 0x0000003fe0f4c5d0 [0x0000003fe0f4c540+0x0000000000000090] >> j java.lang.invoke.LambdaForm$DMH+0x00000008000c0000.invokeStatic(Ljava/lang/Object;Ljava/lang/Object;)V+10 java.base at 19-internal >> j java.lang.invoke.LambdaForm$MH+0x00000008000c1400.invoke(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;+33 java.base at 19-internal >> j java.lang.invoke.Invokers$Holder.invokeExact_MT(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;+20 java.base at 19-internal >> j jdk.internal.reflect.DirectMethodHandleAccessor.invokeImpl(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+55 java.base at 19-internal >> j jdk.internal.reflect.DirectMethodHandleAccessor.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+23 java.base at 19-internal >> j java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+102 java.base at 19-internal >> j com.sun.javatest.regtest.agent.MainWrapper$MainThread.run()V+172 >> j java.lang.Thread.run()V+11 java.base at 19-internal >> v ~StubRoutines::call_stub >> V [libjvm.so+0xa8a0d2] JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)+0x4cc >> V [libjvm.so+0xa8a648] JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)+0x3e0 >> V [libjvm.so+0xa8a9d6] JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*)+0x60 >> V [libjvm.so+0xbcf988] thread_entry(JavaThread*, JavaThread*)+0x88 >> V [libjvm.so+0x1299ca6] JavaThread::thread_main_inner()+0x24e >> V [libjvm.so+0x12a0be6] Thread::call_run()+0xd4 >> V [libjvm.so+0xf3c294] thread_native_entry(Thread*)+0xee >> C [libpthread.so.0+0x7460] start_thread+0xb4 >> C [libc.so.6+0xa7362] >> >> >> This patch passes hotspot and jdk tiere1 on unmatched, and all jtreg tests are tested on Qemu without new failures. > > Yadong Wang has updated the pull request incrementally with one additional commit since the last revision: > > fix typo Looks good. ------------- Marked as reviewed by fyang (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8442 From david.holmes at oracle.com Thu Apr 28 06:58:29 2022 From: david.holmes at oracle.com (David Holmes) Date: Thu, 28 Apr 2022 16:58:29 +1000 Subject: [RFC 8285277] - How should the JVM handle container memory limits In-Reply-To: <7baf6243-150c-2432-9540-a27e4ca1c90c@oracle.com> References: <955f87a4-333d-eabe-aba4-2c302075b99a@oracle.com> <7baf6243-150c-2432-9540-a27e4ca1c90c@oracle.com> Message-ID: <1195bb8b-21d8-d77e-1aa9-60819401e7b0@oracle.com> On 27/04/2022 4:12 am, Ioi Lam wrote: > On 4/21/2022 2:49 AM, Severin Gehwolf wrote: >> On Wed, 2022-04-20 at 11:09 -0700, Ioi Lam wrote: >>> I would like to have a discussion on how (or whether) the JVM should >>> handle container memory limits -- see JDK-8285277 [1] >> It does handle container memory limits. os::physical_memory() returns >> the container limit instead of the host value if a container limit is >> in place. That was one big aspect of JDK-8146115 when it was done in >> JDK 10 timeframe. See: >> >> https://github.com/openjdk/jdk/blob/fa04d1f832ff201248f935939fa255988053a1d0/src/hotspot/os/linux/os_linux.cpp#L217..L232 >> >> >> What am I missing? > > Yes, the container support code does expose the memory limit through > APIs like os::physical_memory(), and we use the same ergonomic logic as > if we are running on a physical machine with a small amount of RAM. > > However, I am wondering if we need to reconsider our logic if the > "physical memory" is unusually small. > > Currently, the ergonomic code will set the heap size to a "sensible" > fraction of os::physical_memory(). This usually works fine on modern day > machines with lots of RAM and swap. Even the below-$100 windows laptops > have at least 4GB. > > On my 64GB box, max heap is set to 16GB by default. This should be > enough for most apps, and will practically never be killed by OOM unless > the system is really overloaded. > > ================ > $ java -XX:+PrintFlagsFinal --version | egrep > '((MaxHeapSize)|(InitialHeapSize))' > ?? size_t InitialHeapSize????????????????????????? = > 1056964608??????????????????????????????? {product} {ergonomic} > ?? size_t MaxHeapSize????????????????????????????? = > 16869490688?????????????????????????????? {product} {ergonomic} > ================ > > But inside a container that has only a 128MB limit (which might be > "typical" for micro-services??) > > ================ > $ java -XX:+PrintFlagsFinal --version | egrep > '((MaxHeapSize)|(InitialHeapSize))' > ?? size_t InitialHeapSize????????????????????????? = > 8388608?????????????????????????????????? {product} {ergonomic} > ?? size_t MaxHeapSize????????????????????????????? = > 67108864????????????????????????????????? {product} {ergonomic} > ================ > > The default MaxHeapSize seems wasteful. We are paying for 128MB but > really just use 64MB of heap. I am able to start with a 108MB heap size > without getting killed. > > ====================== > $ java -XshowSettings:system -Xms108m -XX:+AlwaysPreTouch --version > Operating System Metrics: > ??? Provider: cgroupv1 > ? ? .... > ??? Memory Limit: 128.00M > ??? Memory Soft Limit: Unlimited > ??? Memory & Swap Limit: 128.00M > > java 19-internal 2022-09-20 > Java(TM) SE Runtime Environment (build 19-internal-adhoc.iklam) > Java HotSpot(TM) 64-Bit Server VM (build 19-internal-adhoc.iklam, mixed > mode, sharing) > ========================== > > The problem is > > - If we want to efficiently use all the memory we paid for in a > container, we need to tune the VM parameters manually > > - But tuning is very difficult and error prone. With the 100mb heap > setting, my app could easily be killed if it uses too much memory in > malloc, native buffers, or even the JIT. Currently we don't fail early > (no check of -Xms, -Xmx, etc, against available memory), and don't fail > predictably. > > So, I am wondering if there's anything we can do to make Java both safe > and efficient when running under an small memory budget. I think the only thing you could do for the scenario outlined, when the VM has no idea what may be running in the container nor how much of the container memory it might have available to it, is to provide the "I'm running by myself so max out the memory use" flag. But even then determining how much slack you need to leave will be difficult given we only really have control over some aspects of memory usage. Trying to pro-actively reduce memory use when you hit some soft limit is a good idea, but does such an API exist to let you know when you have hit that soft limit? Cheers, David > Thanks > - Ioi > > >>> The JVM may be terminated by the Linux OOM killer if it tries to use >>> more memory than the memory limit specified for a container. JDK-8284900 >>> [2] tries to avoid OOM by checking InitialHeapSize against the memory >>> limit. However, this is incomplete because the JVM can use memory in >>> other ways: >>> >>> - If -Xmx is larger than -Xms, the heap may expand >>> - malloc memory >>> - code cache >>> - thread stacks >> JDK-8284900 is somewhat a special case which, IIUIC, tries to avoid >> user-errors detectable at JVM startup. For example setting -Xms to a >> value >= physical memory (including swap). In this case the JVM would >> be at risk to get killed by the OOM killer and doing this check on >> start-up would catch it before it comes to it. >> >> On the other hand, I don't see any handling of such a case on a >> *physical* machine. Consider a machine with 8GB of RAM and somebody >> spawning a JVM with -Xms8g on it. It'll happily oblige? In one of my >> VMs with 8GB I see this: >> >> $ ./jdk19-jdk/bin/java -Xms8g -XX:+PrintFlagsFinal -version 2>&1 | >> grep InitialHeapSize >> ??? size_t InitialHeapSize????????????????????????? = >> 8589934592??????????????????????????????? {product} {command line} >> $ free --giga >> ??????????????? total??????? used??????? free????? shared >> buff/cache?? available >> Mem:?????????????? 8?????????? 0?????????? 7?????????? 0 >> 0?????????? 7 >> Swap:????????????? 8?????????? 0?????????? 8 >> >>> We have several choices: >>> >>> (a) Following the direction of JDK-8284900, check for the initial memory >>> usage? of other types of memory as well. The problem with this is that >>> checking the "initial" usage some type of memory usage (malloc or stack) >>> is difficult or impossible. >>> >>> (b) Avoid committing more memory when the total memory usage is close to >>> the limit. E.g., avoid expanding the Java heap, or return NULL from >>> os::malloc(). The problem is that some operations in the VM cannot >>> handle malloc failure and will terminate the VM anyway. Also, trying to >>> obey the memory limit with concurrent allocator/deallocator threads is >>> probably difficult or impossible. >>> >>> (c) Do not consider the memory limit and let the VM be killed by the OOM >>> killer. This may be what the user wants -- the user knows that the app >>> will normally run within the memory limit, so if the heap expands too >>> much the app probably has a memory leak and should be killed, to be >>> automatically restarted by an external mechanism (such as Kubernetes). >> Neither of the above? >> >> It would perhaps make sense to do some sanitiy checks on JVM start-up >> (somewhat akin to JDK-8284900). But this should probably be done with >> the main operating system API. Not using OSContainer API as proposed in >> JDK-8284900. For example, print a warning if MaxHeapSize, >> InitialHeapSize and MinHeapSize are larger than the reported physical >> memory (and/or cap it at a lower size if so). >> >> Isn't (b) being handled by setting os::pysical_memory() and >> os::available_memory() to the container limits (which we currently do)? >> It would behave similarly to a physical machine running out of memory, >> no? >> >> Thanks, >> Severin >> >> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8285277 >>> [2] https://bugs.openjdk.java.net/browse/JDK-8284900 >>> > From thomas.stuefe at gmail.com Thu Apr 28 07:11:27 2022 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 28 Apr 2022 09:11:27 +0200 Subject: [RFC 8285277] - How should the JVM handle container memory limits In-Reply-To: <1195bb8b-21d8-d77e-1aa9-60819401e7b0@oracle.com> References: <955f87a4-333d-eabe-aba4-2c302075b99a@oracle.com> <7baf6243-150c-2432-9540-a27e4ca1c90c@oracle.com> <1195bb8b-21d8-d77e-1aa9-60819401e7b0@oracle.com> Message-ID: > > > I think the only thing you could do for the scenario outlined, when the > VM has no idea what may be running in the container nor how much of the > container memory it might have available to it, is to provide the "I'm > running by myself so max out the memory use" flag. But even then > determining how much slack you need to leave will be difficult given we > only really have control over some aspects of memory usage. > > Trying to pro-actively reduce memory use when you hit some soft limit is > a good idea, but does such an API exist to let you know when you have > hit that soft limit? > > How about a slim concurrent thread in a loop observing RSS, comparing with a pre-set soft limit, and - if the used java heap and the used metaspace are of any significance (since these are the main things a gc can influence) - trigger a gc, possibly asynchronously. Cheers, Thomas > Cheers, > David > > > From aph at openjdk.java.net Thu Apr 28 07:46:45 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Thu, 28 Apr 2022 07:46:45 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 19:21:58 GMT, Alan Bateman wrote: >> src/java.base/share/classes/jdk/internal/misc/UnsafeConstants.java line 122: >> >>> 120: */ >>> 121: >>> 122: public static final int SCOPED_CACHE_SHIFT; >> >> I can't find this constant being used. If added for future, maybe keep `UnsafeConstants` class and this static field package-private for now. > > It originally configured the number of lines in extent local cache but the implementation has changed. @theRealAph would be best to comment on this, it may be possible to delete it. Yes, it's dead. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From thomas.stuefe at gmail.com Thu Apr 28 07:50:05 2022 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 28 Apr 2022 09:50:05 +0200 Subject: [RFC 8285277] - How should the JVM handle container memory limits In-Reply-To: <227b1f73-28a6-e178-142f-234fc713934f@oracle.com> References: <955f87a4-333d-eabe-aba4-2c302075b99a@oracle.com> <7baf6243-150c-2432-9540-a27e4ca1c90c@oracle.com> <50640774d030e5f2b3ef95a1c4b98ae635a1c31f.camel@redhat.com> <227b1f73-28a6-e178-142f-234fc713934f@oracle.com> Message-ID: > > > >> > >> - If we want to efficiently use all the memory we paid for in a > >> container, we need to tune the VM parameters manually > >> > >> - But tuning is very difficult and error prone. With the 100mb heap > >> setting, my app could easily be killed if it uses too much memory in > >> malloc, native buffers, or even the JIT. Currently we don't fail early > >> (no check of -Xms, -Xmx, etc, against available memory), and don't fail > >> predictably. > > +1 to doing some more sanity checks on JVM startup when some of those > > settings exceed physical memory. > > I think this makes sense. We need to decide what the behavior should be: > > - what flags to check > - print warnings? > - abort the VM? > - override the settings to conform to available memory? > - always do this, or only when running inside a container? If the > latter, we will have the problem of JDK-8261242 > > Please only a warning! There may be valid reasons for starting with a massively overextended (uncommitted) heap, e.g. sparse databases. Maybe this is just a documentation problem? -Xmx only reserves address space. In default overcommit mode, you can happily run with Xmx10000G on a modern Linux box. Xms is subject to the overcommit heuristics of the underlying system, which by default are somewhat larger than mem+swap but not endlessly so. If you want an early error when running with too large a heap, you can prevent that today by switching off overcommit heuristics (vm.overcommit_memory=2), setting overcommit_ratio to something like 100 (if you are the only big process on that container), and start the VM with -Xmx == -Xms. Am I overlooking something? -- Some more thoughts: One problem is to correctly estimate the amount of native memory we need. That is very difficult. It depends on many things, e.g. - number of threads, and avg depth of thread stacks - number of classes loaded, and class load churn (metaspace fragmentation) - Used collector (each collector has additional data structures) - malloc granularity and frequency. malloc overhead can be absymal, starting from the NMT malloc header down to the glibc overhead. I have observed factor 4-6 ratio malloc use payload to malloc cost in poorly written applications. Most of this is known, right, this is nothing new. Problem with all these scenarios is that there is no fallback. In most cases with native memory, if you run out, you are done. What would be nice is to pre-allocate and pre-commit certain areas which are normally allocated on demand, to trigger certain OOMs early. We cannot do this for every allocation, but some ideas are: 1) modify Metaspace to preallocate memory - at the moment it's tuned to allocate on-demand only, but that feature may be counterintuitive in containers. One example could be to divert from the current growable-list-of-mappings-model to something simpler like what today is the class space (one large preallocated mapping) 2) For C-heap, you could change os::malloc() to not use C-heap but an internal, pre-allocated buffer. Which you then can allocate and commit upfront. The problem with that approach is that you need to roll your own allocator, which is absolutely not trivial if you want it to be production grade quality (reliable, fast in mt scenarios, somewhat memory conservative - although glibc does not shine there either tbh) 3) A simpler alternative to (2) would be to estimate the C-heap usage (would have to do this anyway) and, on VM start, preallocate it to test if we can. Then release it again. Or keep it, release it on demand like a balloon if memory pressure grows. Though that would incur unnecessary memory costs. Cheers, Thomas From alanb at openjdk.java.net Thu Apr 28 07:52:58 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 28 Apr 2022 07:52:58 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 19:43:22 GMT, Paul Sandoz wrote: >> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: >> >> Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e > > src/java.base/share/classes/java/util/concurrent/ThreadPerTaskExecutor.java line 45: > >> 43: * threads is unbounded. >> 44: */ >> 45: class ThreadPerTaskExecutor implements ExecutorService { > > This class manages the set of per-task threads which arguably should be the job of the thread container, and it awkwardly overrides the container's set of threads by setting a field on `SharedThreadContainer.threadsSupplier`. > > `SharedThreadContainer` supports a number of different shared container policies that could be made clearer. > > Architecturally i think this could be better layered but it can be iterated on later. Indeed, the layering is a bit awkward and I plan to replace it. It came about as a short term solution to avoid double bookkeeping of virtual threads. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From ayang at openjdk.java.net Thu Apr 28 09:15:33 2022 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Thu, 28 Apr 2022 09:15:33 GMT Subject: RFR: 8285364: Remove REF_ enum for java.lang.ref.Reference [v4] In-Reply-To: References: Message-ID: > Simple rename and some comments update. > > Test: build Albert Mingkun Yang has updated the pull request incrementally with two additional commits since the last revision: - comment - Rework reference type initialization Signed-off-by: Albert Yang ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8332/files - new: https://git.openjdk.java.net/jdk/pull/8332/files/73f80ea4..e4f6a66a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8332&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8332&range=02-03 Stats: 57 lines in 7 files changed: 50 ins; 4 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/8332.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8332/head:pull/8332 PR: https://git.openjdk.java.net/jdk/pull/8332 From ayang at openjdk.java.net Thu Apr 28 09:15:34 2022 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Thu, 28 Apr 2022 09:15:34 GMT Subject: RFR: 8285364: Remove REF_ enum for java.lang.ref.Reference [v3] In-Reply-To: References: Message-ID: On Fri, 22 Apr 2022 09:43:45 GMT, Albert Mingkun Yang wrote: >> Simple rename and some comments update. >> >> Test: build > > Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: > > Remove REF_ enum for java.lang.ref.Reference > > Signed-off-by: Albert Yang I have taken "Rework reference type initialization" from Stefan and added comments on a potential surprise that `j.l.r.Reference` is `instanceKlass` not `instanceRefKlass`. ------------- PR: https://git.openjdk.java.net/jdk/pull/8332 From duke at openjdk.java.net Thu Apr 28 09:47:24 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Thu, 28 Apr 2022 09:47:24 GMT Subject: RFR: 8285794: AsyncGetCallTrace might acquire a lock via JavaThread::thread_from_jni_environment Message-ID: Calling JavaThread::thread_from_jni_environment for a terminated thread in AsyncGetCallTrace might cause the acquisition of a lock, making AsyncGetCallTrace non-signal-safe. AsyncGetCallTrace can only be called for the current threads (there are asserts for that), therefore using JavaThread::current directly and checking the termination status is semantically equivalent. ------------- Commit messages: - Use JavaThread::current_or_null - Do not call JavaThread::thread_from_jni_environment Changes: https://git.openjdk.java.net/jdk/pull/8446/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8446&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8285794 Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/8446.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8446/head:pull/8446 PR: https://git.openjdk.java.net/jdk/pull/8446 From aph at openjdk.java.net Thu Apr 28 10:06:03 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Thu, 28 Apr 2022 10:06:03 GMT Subject: RFR: 8285802: AArch64: Consistently handle offsets in MacroAssembler as 64-bit quantities Message-ID: In a few places we pass offsets as 32-bit ints rather than 64-bit longs, and we're not consistent about it. We shold have a clean 64-bit path for offset generation and validation. ------------- Commit messages: - 8285802: AArch64: Consistently handle offsets in MacroAssembler as 64-bit quantities Changes: https://git.openjdk.java.net/jdk/pull/8448/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8448&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8285802 Stats: 11 lines in 2 files changed: 0 ins; 0 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/8448.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8448/head:pull/8448 PR: https://git.openjdk.java.net/jdk/pull/8448 From sgehwolf at redhat.com Thu Apr 28 10:08:08 2022 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 28 Apr 2022 12:08:08 +0200 Subject: [RFC 8285277] - How should the JVM handle container memory limits In-Reply-To: <643d3ce6-1b1c-5174-caf8-d390a06f1a6d@oracle.com> References: <955f87a4-333d-eabe-aba4-2c302075b99a@oracle.com> <7baf6243-150c-2432-9540-a27e4ca1c90c@oracle.com> <50640774d030e5f2b3ef95a1c4b98ae635a1c31f.camel@redhat.com> <643d3ce6-1b1c-5174-caf8-d390a06f1a6d@oracle.com> Message-ID: On Wed, 2022-04-27 at 10:51 -0700, Ioi Lam wrote: > > > =========== > > > > > > The default MaxHeapSize seems wasteful. We are paying for 128MB but > > > really just use 64MB of heap. I am able to start with a 108MB heap size > > > without getting killed. > > Yes. While I got confused a little what you meant by "wasteful" it > > sounds like you are saying it should set MaxHeapSize to a higher level. > > Is that correct? > > Yes, that's what I mean. OK thanks, that wasn't clear initially. > > If so that's basically what I was trying to say with > > the (wrong) default of MaxRAMPercentage when run in a container. My > > experimentations with this didn't go anywhere, though, as we cannot > > reliably detect if we are on a plain Linux system or in a container. > > See JDK-8261242. > > Perhaps instead of the JVM being smart, we provide a new option (OK I > admit I hate adding new options), something like > > - use more aggressive default heap size > - I am running in a container by myself I guess this seems the only option (for now) to be able to make some progress on this. Personally, I'm on the fence on which direction to go though. On by default and provide the flag to turn it off or the other way round. Thanks, Severin From aph at openjdk.java.net Thu Apr 28 10:13:19 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Thu, 28 Apr 2022 10:13:19 GMT Subject: RFR: 8285802: AArch64: Consistently handle offsets in MacroAssembler as 64-bit quantities [v2] In-Reply-To: References: Message-ID: > In a few places we pass offsets as 32-bit ints rather than 64-bit longs, and we're not consistent about it. We shold have a clean 64-bit path for offset generation and validation. Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: 8285802: AArch64: Consistently handle offsets in MacroAssembler as 64-bit quantities ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8448/files - new: https://git.openjdk.java.net/jdk/pull/8448/files/99159f7e..367842f0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8448&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8448&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8448.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8448/head:pull/8448 PR: https://git.openjdk.java.net/jdk/pull/8448 From sgehwolf at redhat.com Thu Apr 28 10:28:59 2022 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 28 Apr 2022 12:28:59 +0200 Subject: [RFC 8285277] - How should the JVM handle container memory limits In-Reply-To: References: <955f87a4-333d-eabe-aba4-2c302075b99a@oracle.com> <7baf6243-150c-2432-9540-a27e4ca1c90c@oracle.com> <50640774d030e5f2b3ef95a1c4b98ae635a1c31f.camel@redhat.com> <227b1f73-28a6-e178-142f-234fc713934f@oracle.com> Message-ID: <8e8b45f2b247192893e7b87fcae2eb6818f10bfe.camel@redhat.com> On Thu, 2022-04-28 at 09:50 +0200, Thomas St?fe wrote: > > > > > > > > - If we want to efficiently use all the memory we paid for in a > > > > container, we need to tune the VM parameters manually > > > > > > > > - But tuning is very difficult and error prone. With the 100mb heap > > > > setting, my app could easily be killed if it uses too much memory in > > > > malloc, native buffers, or even the JIT. Currently we don't fail early > > > > (no check of -Xms, -Xmx, etc, against available memory), and don't fail > > > > predictably. > > > +1 to doing some more sanity checks on JVM startup when some of those > > > settings exceed physical memory. > > > > I think this makes sense. We need to decide what the behavior should be: > > > > - what flags to check > > - print warnings? > > - abort the VM? > > - override the settings to conform to available memory? > > - always do this, or only when running inside a container? If the > > latter, we will have the problem of? JDK-8261242 Always do it. There should be no special casing for the container case. > > > Please only a warning! I tend to agree. > There may be valid reasons for starting with a massively overextended > (uncommitted) heap, e.g. sparse databases. > > Maybe this is just a documentation problem? -Xmx only reserves address > space. In default overcommit mode, you can happily run with Xmx10000G on a > modern Linux box. Xms is subject to the overcommit heuristics of the > underlying system, which by default are somewhat larger than mem+swap but > not endlessly so. > > If you want an early error when running with too large a heap, you can > prevent that today by switching off overcommit heuristics > (vm.overcommit_memory=2), setting overcommit_ratio to something like 100 > (if you are the only big process on that container), and start the VM with > -Xmx == -Xms. Am I overlooking something? Good points. I do think, though, that those massive overcommit cases are the outliers as compared to the average JVM process. Especially in the container world, where many people get some memory limit via an orchestration framework and are blissfully unaware that - as a result - the -Xmx/-Xms settings actually exceed that limit. A warning (and accepting the warning) seems fine in those overcommit cases and might actually raise awareness in other cases, IMO. Thanks, Severin From duke at openjdk.java.net Thu Apr 28 10:55:29 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Thu, 28 Apr 2022 10:55:29 GMT Subject: RFR: 8282477: [x86, aarch64] vmassert(_last_Java_pc == NULL, "already walkable"); fails with async profiler [v3] In-Reply-To: References: Message-ID: > Fix the assertion by replacing it by assertion that does not fail. Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: Use make_walkable ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8209/files - new: https://git.openjdk.java.net/jdk/pull/8209/files/f152367b..83ed9c70 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8209&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8209&range=01-02 Stats: 76 lines in 7 files changed: 1 ins; 55 del; 20 mod Patch: https://git.openjdk.java.net/jdk/pull/8209.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8209/head:pull/8209 PR: https://git.openjdk.java.net/jdk/pull/8209 From aph at openjdk.java.net Thu Apr 28 11:10:36 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Thu, 28 Apr 2022 11:10:36 GMT Subject: RFR: 8285802: AArch64: Consistently handle offsets in MacroAssembler as 64-bit quantities [v3] In-Reply-To: References: Message-ID: > In a few places we pass offsets as 32-bit ints rather than 64-bit longs, and we're not consistent about it. We shold have a clean 64-bit path for offset generation and validation. Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: Use Assembler::add routines in MacroAssembler::mov routines. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8448/files - new: https://git.openjdk.java.net/jdk/pull/8448/files/367842f0..a9bb2df2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8448&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8448&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8448.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8448/head:pull/8448 PR: https://git.openjdk.java.net/jdk/pull/8448 From kbarrett at openjdk.java.net Thu Apr 28 11:17:44 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Thu, 28 Apr 2022 11:17:44 GMT Subject: RFR: 8285364: Remove REF_ enum for java.lang.ref.Reference [v4] In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 09:15:33 GMT, Albert Mingkun Yang wrote: >> Simple rename and some comments update. >> >> Test: build > > Albert Mingkun Yang has updated the pull request incrementally with two additional commits since the last revision: > > - comment > - Rework reference type initialization > > Signed-off-by: Albert Yang There are further cleanups possible if we didn't have REF_NONE and InstanceKlass didn't have a reference type. But there are a number of uses of InstanceKlass::reference_type. Doing anything along those lines (assuming it's deemed worthwhile to do so) can be done in a followup RFE. src/hotspot/share/classfile/classFileParser.cpp line 6098: > 6096: > 6097: return _super_klass->reference_type() != REF_NONE; > 6098: } Stylistically, I'd prefer an if-ladder here. I might also swap the reference-type check and the name check, so the for-bootstrapping name check case being last (with a comment to that effect). src/hotspot/share/oops/instanceKlass.cpp line 497: > 495: _nest_host_index(0), > 496: _init_state(allocated), > 497: _reference_type(REF_NONE), This is initializing `_reference_type` to the wrong value for a `InstanceRefKlass` object, which then needs to reset it in the derived constructor. Why not get the reference type from the parser? The (currently file-scoped static) determine_reference_type function in instanceRefKlass.cpp doesn't have any dependency on the klass object being constructed, just the parser. src/hotspot/share/oops/instanceKlass.hpp line 580: > 578: protected: > 579: // Only used by the InstanceRefKlass constructor > 580: void set_reference_type(ReferenceType t) { This function wouldn't be needed at all if the reference type was properly initialized. src/hotspot/share/oops/instanceRefKlass.cpp line 55: > 53: } > 54: > 55: // Bootstrapping: this is either of the four direct subclasses of java.lang.ref.Reference s/either of the four/one of the/. In particular remove "four" else, someday, finalization will finally be GC'd and this comment will need to be noticed and updated. ------------- Changes requested by kbarrett (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8332 From dholmes at openjdk.java.net Thu Apr 28 11:26:00 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 28 Apr 2022 11:26:00 GMT Subject: RFR: 8285794: AsyncGetCallTrace might acquire a lock via JavaThread::thread_from_jni_environment In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 09:38:30 GMT, Johannes Bechberger wrote: > Calling JavaThread::thread_from_jni_environment for a terminated thread in AsyncGetCallTrace might cause the acquisition of a lock, making AsyncGetCallTrace non-signal-safe. > > AsyncGetCallTrace can only be called for the current threads (there are asserts for that), therefore using JavaThread::current directly and checking the termination status is semantically equivalent. Changes requested by dholmes (Reviewer). src/hotspot/share/prims/forte.cpp line 566: > 564: void AsyncGetCallTrace(ASGCT_CallTrace *trace, jint depth, void* ucontext) { > 565: > 566: JavaThread* thread = JavaThread::current_or_null(); As this can be in a signal handling context it needs to be Thread::current_or_null_safe(). src/hotspot/share/prims/forte.cpp line 568: > 566: JavaThread* thread = JavaThread::current_or_null(); > 567: > 568: if (trace->env_id == NULL || thread == NULL || thread->is_terminated() || thread->is_exiting()) { `is_exiting()` also covers `is_terminated()`. src/hotspot/share/prims/forte.cpp line 580: > 578: } > 579: > 580: assert(thread == JavaThread::thread_from_jni_environment(trace->env_id), Please add a comment before the assert: // This is safe now as the thread has not terminated and so no VM exit check occurs. ------------- PR: https://git.openjdk.java.net/jdk/pull/8446 From dholmes at openjdk.java.net Thu Apr 28 11:26:02 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 28 Apr 2022 11:26:02 GMT Subject: RFR: 8285794: AsyncGetCallTrace might acquire a lock via JavaThread::thread_from_jni_environment In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 11:15:34 GMT, David Holmes wrote: >> Calling JavaThread::thread_from_jni_environment for a terminated thread in AsyncGetCallTrace might cause the acquisition of a lock, making AsyncGetCallTrace non-signal-safe. >> >> AsyncGetCallTrace can only be called for the current threads (there are asserts for that), therefore using JavaThread::current directly and checking the termination status is semantically equivalent. > > src/hotspot/share/prims/forte.cpp line 566: > >> 564: void AsyncGetCallTrace(ASGCT_CallTrace *trace, jint depth, void* ucontext) { >> 565: >> 566: JavaThread* thread = JavaThread::current_or_null(); > > As this can be in a signal handling context it needs to be Thread::current_or_null_safe(). Also please add a comment before this: // Can't use thread_from_jni_environment as it may also perform a VM exit check that is unsafe to // do from this context. ------------- PR: https://git.openjdk.java.net/jdk/pull/8446 From duke at openjdk.java.net Thu Apr 28 11:38:32 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Thu, 28 Apr 2022 11:38:32 GMT Subject: RFR: 8285794: AsyncGetCallTrace might acquire a lock via JavaThread::thread_from_jni_environment [v2] In-Reply-To: References: Message-ID: > Calling JavaThread::thread_from_jni_environment for a terminated thread in AsyncGetCallTrace might cause the acquisition of a lock, making AsyncGetCallTrace non-signal-safe. > > AsyncGetCallTrace can only be called for the current threads (there are asserts for that), therefore using JavaThread::current directly and checking the termination status is semantically equivalent. Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: Use Thread::current_or_null_safe() and add comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8446/files - new: https://git.openjdk.java.net/jdk/pull/8446/files/28180bc9..1e2885e6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8446&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8446&range=00-01 Stats: 8 lines in 1 file changed: 6 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8446.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8446/head:pull/8446 PR: https://git.openjdk.java.net/jdk/pull/8446 From aph at openjdk.java.net Thu Apr 28 12:38:20 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Thu, 28 Apr 2022 12:38:20 GMT Subject: RFR: 8285802: AArch64: Consistently handle offsets in MacroAssembler as 64-bit quantities [v4] In-Reply-To: References: Message-ID: > In a few places we pass offsets as 32-bit ints rather than 64-bit longs, and we're not consistent about it. We shold have a clean 64-bit path for offset generation and validation. Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: Windows! ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8448/files - new: https://git.openjdk.java.net/jdk/pull/8448/files/a9bb2df2..fc66cb9d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8448&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8448&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8448.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8448/head:pull/8448 PR: https://git.openjdk.java.net/jdk/pull/8448 From aph-open at littlepinkcloud.com Thu Apr 28 12:53:45 2022 From: aph-open at littlepinkcloud.com (Andrew Haley) Date: Thu, 28 Apr 2022 13:53:45 +0100 Subject: Windows integral promotions / uint64_t Message-ID: <98a9c5c9-ff43-7f1e-b512-99161cfba43a@littlepinkcloud.com> I'm seeing this failure from the Windows/AArch64 C++ compiler: * For target hotspot_variant-server_libjvm_objs_stubGenerator_aarch64.obj: stubGenerator_aarch64.cpp d:\a\jdk\jdk\jdk\src\hotspot\cpu\aarch64\stubGenerator_aarch64.cpp(6524): error C2668: 'MacroAssembler::sub': ambiguous call to overloaded function d:\a\jdk\jdk\jdk\src\hotspot\cpu\aarch64\macroAssembler_aarch64.hpp(1174): note: could be 'void MacroAssembler::sub(Register,Register,Register)' d:\a\jdk\jdk\jdk\src\hotspot\cpu\aarch64\macroAssembler_aarch64.hpp(1174): note: or 'void MacroAssembler::sub(Register,Register,uint64_t)' d:\a\jdk\jdk\jdk\src\hotspot\cpu\aarch64\stubGenerator_aarch64.cpp(6524): note: while trying to match the argument list '(const Register, const Register, unsigned int)' ... (rest of output omitted) 6524: __ sub(sp, rfp, ((unsigned)framesize-4) << LogBytesPerInt); // prolog Is this a known bug in the compiler? It seems to me as though there is an implicit integral promotion from unsigned int to uint64_t, but there is no implicit conversion from unsigned int to Register (which is of pointer- to const RegisterImpl type). Therefore, according to the ranking of implicit conversion sequences rule, this should work. Or is the problem that, according to the Windows compiler, there is no implicit integral promotion from unsigned int to uint64_t? I guess that's possible if there is no standard type which corresponds to uint64_t, but surely that's unsigned long long. Isn't it? If this is the case, we could use some template magic to define conversions from the standard types to Xint64_t, and include them in the Windows build. That would reduce the pain. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From dholmes at openjdk.java.net Thu Apr 28 13:23:38 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 28 Apr 2022 13:23:38 GMT Subject: RFR: 8285794: AsyncGetCallTrace might acquire a lock via JavaThread::thread_from_jni_environment [v2] In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 11:38:32 GMT, Johannes Bechberger wrote: >> Calling JavaThread::thread_from_jni_environment for a terminated thread in AsyncGetCallTrace might cause the acquisition of a lock, making AsyncGetCallTrace non-signal-safe. >> >> AsyncGetCallTrace can only be called for the current threads (there are asserts for that), therefore using JavaThread::current directly and checking the termination status is semantically equivalent. > > Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: > > Use Thread::current_or_null_safe() and add comments Changes requested by dholmes (Reviewer). src/hotspot/share/prims/forte.cpp line 35: > 33: #include "runtime/frame.inline.hpp" > 34: #include "runtime/javaCalls.hpp" > 35: #include "runtime/thread.hpp" You don't need this as you already include the thread.inline.hpp which has to include thread.hpp. src/hotspot/share/prims/forte.cpp line 571: > 569: Thread* raw_thread = Thread::current_or_null_safe(); > 570: > 571: if (trace->env_id == NULL || raw_thread == NULL || !raw_thread->is_Java_thread() || ((JavaThread*)raw_thread)->is_exiting()) { use `rawThread->as_JavaThread()` not a plain cast. src/hotspot/share/prims/forte.cpp line 577: > 575: } > 576: > 577: JavaThread* thread = (JavaThread*)raw_thread; use `rawThread->as_JavaThread()` not a plain cast. You could also incorporate this into the earlier code so you don't do it twice. ------------- PR: https://git.openjdk.java.net/jdk/pull/8446 From egahlin at openjdk.java.net Thu Apr 28 14:47:16 2022 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Thu, 28 Apr 2022 14:47:16 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e src/hotspot/share/jfr/leakprofiler/sampling/objectSampler.cpp line 168: > 166: assert(!tl->is_excluded(), "invariant"); > 167: if (virtual_thread) { > 168: // TODO: blob cache for virtual threads Fix this now or after integration? src/hotspot/share/jfr/metadata/metadata.xml line 121: > 119: thread="true" stackTrace="true"> > 120: > 121: "Continuation class" = >" Continuation Class" numFrames = frames numRefs = references "Number of interpreted frames" => "Interpreted Frames" "Number of references" => "References" "Stack size in bytes" => "Stack Size" contentType"bytes" src/hotspot/share/jfr/metadata/metadata.xml line 130: > 128: thread="true" stackTrace="true"> > 129: > 130: contClass => continuationClass "Continuation class" => "Continuation Class" "Class of the continuation" Remove (not needed) "Number of interpreted frames" => "Interpreted Frames" numFrames => frames "Number of references" => "References" numRefs => references "Stack size in bytes" => "Stack Size" contentType="bytes" src/hotspot/share/jfr/metadata/metadata.xml line 138: > 136: > 137: > 138: "Allocated new" => "Allocated New" src/hotspot/share/jfr/recorder/checkpoint/jfrCheckpointManager.cpp line 94: > 92: static const size_t global_buffer_size = 512 * K; > 93: > 94: static const size_t thread_local_buffer_prealloc_count = 32; Why is more memory needed? Moore's law or something specific to virtual threads? src/hotspot/share/jfr/recorder/checkpoint/jfrCheckpointWriter.cpp line 81: > 79: be_writer.write(size); > 80: be_writer.write(time); > 81: be_writer.write(JfrTicks::now().value() - time); Why is this changed? src/jdk.jfr/share/classes/jdk/jfr/events/VirtualThreadEndEvent.java line 35: > 33: > 34: @Category({"Java Runtime"}) > 35: @Label("Virtual thread end") "Virtual thread end" => "Virtual Thread End" Remove description. src/jdk.jfr/share/classes/jdk/jfr/events/VirtualThreadPinnedEvent.java line 35: > 33: > 34: @Category({"Java Runtime"}) > 35: @Label("Virtual thread pinned") "Virtual thread pinned" => "Virtual Thread Pinned" Remove description src/jdk.jfr/share/classes/jdk/jfr/events/VirtualThreadStartEvent.java line 35: > 33: > 34: @Category({"Java Runtime"}) > 35: @Label("Virtual thread start") "virtual thread start" => "Virtual Thread Start" Remove description src/jdk.jfr/share/classes/jdk/jfr/events/VirtualThreadSubmitFailedEvent.java line 35: > 33: > 34: @Category({"Java Runtime"}) > 35: @Label("Virtual thread submit task failed") The label is a bit a long, would "Virtual Thread Submit Failed" work? ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From kvn at openjdk.java.net Thu Apr 28 14:51:55 2022 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Thu, 28 Apr 2022 14:51:55 GMT Subject: RFR: 8285301: C2: assert(!requires_atomic_access) failed: can't ensure atomicity [v2] In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 05:34:31 GMT, Tobias Hartmann wrote: >> We hit asserts in `BarrierSetC2::load_at_resolved` and `BarrierSetC2::store_at_resolved` when running with `-XX:+AlwaysAtomicAccesses` because the corresponding code paths have not been implemented yet. Although the assert triggers on all platforms, it only affects long and double accesses on 32-bit systems (everything else is atomic anyway). >> >> I moved the `requires_atomic_access` logic into `LoadNode::make` and `StoreNode::make` and refactored related code. >> >> I noticed that `LoadNode::convert_to_reinterpret_load` and `StoreNode::convert_to_reinterpret_store` did not properly check for `requires_atomic_access` and fixed that as well. >> >> I'm currently running all tests with `-XX:+AlwaysAtomicAccesses`. >> >> Thanks, >> Tobias > > Tobias Hartmann has updated the pull request incrementally with two additional commits since the last revision: > > - Removed default arg > - Invoking Opcode only once. Added comment to test Looks good. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8422 From mgronlun at openjdk.java.net Thu Apr 28 15:06:01 2022 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Thu, 28 Apr 2022 15:06:01 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 14:37:22 GMT, Erik Gahlin wrote: >> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: >> >> Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e > > src/hotspot/share/jfr/recorder/checkpoint/jfrCheckpointWriter.cpp line 81: > >> 79: be_writer.write(size); >> 80: be_writer.write(time); >> 81: be_writer.write(JfrTicks::now().value() - time); > > Why is this changed? It was a small optimization attempted before the current system of writing virtual thread checkpoints in bulk. Will restore it, thank you. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From mgronlun at openjdk.java.net Thu Apr 28 15:11:10 2022 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Thu, 28 Apr 2022 15:11:10 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 14:41:04 GMT, Erik Gahlin wrote: >> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: >> >> Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e > > src/hotspot/share/jfr/recorder/checkpoint/jfrCheckpointManager.cpp line 94: > >> 92: static const size_t global_buffer_size = 512 * K; >> 93: >> 94: static const size_t thread_local_buffer_prealloc_count = 32; > > Why is more memory needed? Moore's law or something specific to virtual threads? The carrier thread will write the metadata for the mounted virtual threads lazily with virtual threads as part of the event write. They write this thread locally, and the memory increase accommodates fewer roundtrips to fetch new buffers. The previous size was small because it would only hold at most one entry. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From ngasson at openjdk.java.net Thu Apr 28 15:18:44 2022 From: ngasson at openjdk.java.net (Nick Gasson) Date: Thu, 28 Apr 2022 15:18:44 GMT Subject: RFR: 8285802: AArch64: Consistently handle offsets in MacroAssembler as 64-bit quantities [v4] In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 12:38:20 GMT, Andrew Haley wrote: >> In a few places we pass offsets as 32-bit ints rather than 64-bit longs, and we're not consistent about it. We shold have a clean 64-bit path for offset generation and validation. > > Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: > > Windows! Seems fine. Was this fixing a particular issue? src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 6524: > 6522: > 6523: // lr and fp are already in place > 6524: __ sub(sp, rfp, ((uint64_t)framesize-4) << LogBytesPerInt); // prolog Typo prolog -> prologue in the existing code. ------------- Marked as reviewed by ngasson (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8448 From mgronlun at openjdk.java.net Thu Apr 28 15:47:16 2022 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Thu, 28 Apr 2022 15:47:16 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 14:44:05 GMT, Erik Gahlin wrote: >> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: >> >> Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e > > src/hotspot/share/jfr/leakprofiler/sampling/objectSampler.cpp line 168: > >> 166: assert(!tl->is_excluded(), "invariant"); >> 167: if (virtual_thread) { >> 168: // TODO: blob cache for virtual threads > > Fix this now or after integration? Well spotted. It is an optimization and can happen after integration. I will create an enhancement for tracking; thank you. > src/hotspot/share/jfr/metadata/metadata.xml line 121: > >> 119: thread="true" stackTrace="true"> >> 120: >> 121: > > "Continuation class" = >" Continuation Class" > numFrames = frames > numRefs = references > "Number of interpreted frames" => "Interpreted Frames" > "Number of references" => "References" > "Stack size in bytes" => "Stack Size" contentType"bytes" Will fix. > src/hotspot/share/jfr/metadata/metadata.xml line 130: > >> 128: thread="true" stackTrace="true"> >> 129: >> 130: > > contClass => continuationClass > "Continuation class" => "Continuation Class" > "Class of the continuation" Remove (not needed) > "Number of interpreted frames" => "Interpreted Frames" > numFrames => frames > "Number of references" => "References" > numRefs => references > "Stack size in bytes" => "Stack Size" contentType="bytes" Will fix. > src/hotspot/share/jfr/metadata/metadata.xml line 138: > >> 136: >> 137: >> 138: > > "Allocated new" => "Allocated New" Will fix, thanks. > src/jdk.jfr/share/classes/jdk/jfr/events/VirtualThreadEndEvent.java line 35: > >> 33: >> 34: @Category({"Java Runtime"}) >> 35: @Label("Virtual thread end") > > "Virtual thread end" => "Virtual Thread End" > Remove description. Will fix. > src/jdk.jfr/share/classes/jdk/jfr/events/VirtualThreadPinnedEvent.java line 35: > >> 33: >> 34: @Category({"Java Runtime"}) >> 35: @Label("Virtual thread pinned") > > "Virtual thread pinned" => "Virtual Thread Pinned" > Remove description Will fix. > src/jdk.jfr/share/classes/jdk/jfr/events/VirtualThreadStartEvent.java line 35: > >> 33: >> 34: @Category({"Java Runtime"}) >> 35: @Label("Virtual thread start") > > "virtual thread start" => "Virtual Thread Start" > Remove description Will fix, thanks. > src/jdk.jfr/share/classes/jdk/jfr/events/VirtualThreadSubmitFailedEvent.java line 35: > >> 33: >> 34: @Category({"Java Runtime"}) >> 35: @Label("Virtual thread submit task failed") > > The label is a bit a long, would "Virtual Thread Submit Failed" work? It works. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From alanb at openjdk.java.net Thu Apr 28 15:47:17 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 28 Apr 2022 15:47:17 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: <81ywC27bKQgyP3gndP6y02PPiOfHrTAlU-YA46fZvZ0=.9f0253da-a679-43b9-b445-a598cc193518@github.com> On Thu, 28 Apr 2022 15:10:18 GMT, Markus Gr?nlund wrote: >> src/jdk.jfr/share/classes/jdk/jfr/events/VirtualThreadSubmitFailedEvent.java line 35: >> >>> 33: >>> 34: @Category({"Java Runtime"}) >>> 35: @Label("Virtual thread submit task failed") >> >> The label is a bit a long, would "Virtual Thread Submit Failed" work? > > It works. Thanks. Yes, this is okay. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From kim.barrett at oracle.com Thu Apr 28 16:14:48 2022 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 28 Apr 2022 16:14:48 +0000 Subject: Windows integral promotions / uint64_t In-Reply-To: <98a9c5c9-ff43-7f1e-b512-99161cfba43a@littlepinkcloud.com> References: <98a9c5c9-ff43-7f1e-b512-99161cfba43a@littlepinkcloud.com> Message-ID: > On Apr 28, 2022, at 8:53 AM, Andrew Haley wrote: > > I'm seeing this failure from the Windows/AArch64 C++ compiler: > > * For target hotspot_variant-server_libjvm_objs_stubGenerator_aarch64.obj: > stubGenerator_aarch64.cpp > d:\a\jdk\jdk\jdk\src\hotspot\cpu\aarch64\stubGenerator_aarch64.cpp(6524): error C2668: 'MacroAssembler::sub': ambiguous call to overloaded function > d:\a\jdk\jdk\jdk\src\hotspot\cpu\aarch64\macroAssembler_aarch64.hpp(1174): note: could be 'void MacroAssembler::sub(Register,Register,Register)' > d:\a\jdk\jdk\jdk\src\hotspot\cpu\aarch64\macroAssembler_aarch64.hpp(1174): note: or 'void MacroAssembler::sub(Register,Register,uint64_t)' > d:\a\jdk\jdk\jdk\src\hotspot\cpu\aarch64\stubGenerator_aarch64.cpp(6524): note: while trying to match the argument list '(const Register, const Register, unsigned int)' > ... (rest of output omitted) > > 6524: __ sub(sp, rfp, ((unsigned)framesize-4) << LogBytesPerInt); // prolog > > > Is this a known bug in the compiler? It seems to me as though there is > an implicit integral promotion from unsigned int to uint64_t, but there is no > implicit conversion from unsigned int to Register (which is of pointer- > to const RegisterImpl type). Therefore, according to the ranking of > implicit conversion sequences rule, this should work. > > Or is the problem that, according to the Windows compiler, there is no > implicit integral promotion from unsigned int to uint64_t? I guess that's > possible if there is no standard type which corresponds to uint64_t, but > surely that's unsigned long long. Isn't it? > > If this is the case, we could use some template magic to define conversions > from the standard types to Xint64_t, and include them in the Windows build. > That would reduce the pain. I think what may be happening here is that the third argument to sub is a constant expression whose value is 0, so is ambiguously either an integral 0 or a null pointer. C++14 says only a literal 0 is supposed to be implicitly convertible to a pointer [1], but C++11 and earlier allow any constexpr 0 to implicitly convert [2]. And I noticed a while ago that gcc seems to have retained the old behavior even in C++14 mode (at least sometimes?). Maybe Visual Studio is doing the same? But then, why aren?t we seeing similar problems with gcc? [1] C++14 4.10/1 A null pointer constant is an integer literal (2.14.2) with value zero ? [2] C++11 4.10/1 A null pointer constant is an integral constant expression (5.19) prvalue of integer type that evaluates to zero? A way to deal with this kind of thing is to use templates to inhibit conversions and use SFINAE to select and forward to type-specific helpers. So something like template::value)> void sub(Register arg0, Register arg1, ThirdArgType arg2) { sub_integral_third_arg(arg0, arg1, arg2); } template::value)> void sub(Register arg0, Register arg1, ThirdArgType arg2) { sub_ponter_third_arg(arg0, arg1, arg2); } This is obviously pretty ugly, and not something I would really recommend here. Once again the hacky way Register is defined is biting us. From duke at openjdk.java.net Thu Apr 28 16:36:39 2022 From: duke at openjdk.java.net (XenoAmess) Date: Thu, 28 Apr 2022 16:36:39 GMT Subject: RFR: 8285149: Using HashMap.newHashMap to replace new HashMap(int) [v4] In-Reply-To: References: Message-ID: <4K3rhX2RGM_yaCKKJALcP7EplXS2pJXM8zYGNGEg-6Y=.c03f7730-b26a-459a-8d60-ea8ab9149603@github.com> On Wed, 27 Apr 2022 05:11:54 GMT, XenoAmess wrote: > Also do not change J2DBench. We deliberately avoid using new API so that we can take it and run it on very old JDK versions to help track regressions. For J2DBench, I don't see any changes that not complicated with older jdk version for now. please recheck. thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/8301 From aph at openjdk.java.net Thu Apr 28 16:43:41 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Thu, 28 Apr 2022 16:43:41 GMT Subject: RFR: 8285802: AArch64: Consistently handle offsets in MacroAssembler as 64-bit quantities [v4] In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 15:15:21 GMT, Nick Gasson wrote: > Seems fine. Was this fixing a particular issue? It's a latent bug. I don't think it manifests today, but it's a bug. > src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 6524: > >> 6522: >> 6523: // lr and fp are already in place >> 6524: __ sub(sp, rfp, ((uint64_t)framesize-4) << LogBytesPerInt); // prolog > > Typo prolog -> prologue in the existing code. I think that "prolog" is a correct variant of "prologue" in American English. ------------- PR: https://git.openjdk.java.net/jdk/pull/8448 From duke at openjdk.java.net Thu Apr 28 16:56:38 2022 From: duke at openjdk.java.net (XenoAmess) Date: Thu, 28 Apr 2022 16:56:38 GMT Subject: RFR: 8285149: Using HashMap.newHashMap to replace new HashMap(int) [v5] In-Reply-To: References: Message-ID: > These are the changes that too many to be reviewed in 8186958, thus split some of them out. XenoAmess has updated the pull request incrementally with one additional commit since the last revision: revert changes to java.desktop as prrace said ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8301/files - new: https://git.openjdk.java.net/jdk/pull/8301/files/684d1528..c9cfb50a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8301&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8301&range=03-04 Stats: 56 lines in 30 files changed: 8 ins; 0 del; 48 mod Patch: https://git.openjdk.java.net/jdk/pull/8301.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8301/head:pull/8301 PR: https://git.openjdk.java.net/jdk/pull/8301 From duke at openjdk.java.net Thu Apr 28 17:00:44 2022 From: duke at openjdk.java.net (Evgeny Astigeevich) Date: Thu, 28 Apr 2022 17:00:44 GMT Subject: RFR: 8285487: Do not generate trampolines for runtime calls if they are not needed [v2] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 14:34:39 GMT, Evgeny Astigeevich wrote: >> [JDK-8280872](https://bugs.openjdk.java.net/browse/JDK-8280872) put the non-nmethod segment between two others. It made trampolines for runtime calls redundant in most cases. >> >> This PR uses `target_needs_far_branch()` for runtime calls to check whether they need trampolines. Trampolines are not generated if they are not needed. >> >> Testing: >> - `tier1`...`tier4`: Passed >> - `compiler/c2/aarch64/TestTrampoline.java`: Passed >> >> Note: `compiler/c2/aarch64/TestTrampoline.java` requires the release build. This is because debug builds have the branch range set to 2M which causes always generation of trampolines. > > Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: > > XX:ReservedCodeCacheSize=130M for test and update comments Hi Vladimir(@vnkozlov), Could you please review the PR? ------------- PR: https://git.openjdk.java.net/jdk/pull/8403 From weijun at openjdk.java.net Thu Apr 28 17:43:43 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 28 Apr 2022 17:43:43 GMT Subject: RFR: 8285149: Using HashMap.newHashMap to replace new HashMap(int) [v5] In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 16:56:38 GMT, XenoAmess wrote: >> These are the changes that too many to be reviewed in 8186958, thus split some of them out. > > XenoAmess has updated the pull request incrementally with one additional commit since the last revision: > > revert changes to java.desktop as prrace said src/java.base/share/classes/sun/security/rsa/SunRsaSignEntries.java line 58: > 56: // start populating content using the specified provider > 57: // common attribute map > 58: HashMap attrs = HashMap.newHashMap(3); Looks like 1 is enough. ------------- PR: https://git.openjdk.java.net/jdk/pull/8301 From sviswanathan at openjdk.java.net Thu Apr 28 17:57:46 2022 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Thu, 28 Apr 2022 17:57:46 GMT Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE with predicate feature [v2] In-Reply-To: References: Message-ID: On Fri, 22 Apr 2022 07:08:24 GMT, Xiaohong Gong wrote: >> Currently the vector load with mask when the given index happens out of the array boundary is implemented with pure java scalar code to avoid the IOOBE (IndexOutOfBoundaryException). This is necessary for architectures that do not support the predicate feature. Because the masked load is implemented with a full vector load and a vector blend applied on it. And a full vector load will definitely cause the IOOBE which is not valid. However, for architectures that support the predicate feature like SVE/AVX-512/RVV, it can be vectorized with the predicated load instruction as long as the indexes of the masked lanes are within the bounds of the array. For these architectures, loading with unmasked lanes does not raise exception. >> >> This patch adds the vectorization support for the masked load with IOOBE part. Please see the original java implementation (FIXME: optimize): >> >> >> @ForceInline >> public static >> ByteVector fromArray(VectorSpecies species, >> byte[] a, int offset, >> VectorMask m) { >> ByteSpecies vsp = (ByteSpecies) species; >> if (offset >= 0 && offset <= (a.length - species.length())) { >> return vsp.dummyVector().fromArray0(a, offset, m); >> } >> >> // FIXME: optimize >> checkMaskFromIndexSize(offset, vsp, m, 1, a.length); >> return vsp.vOp(m, i -> a[offset + i]); >> } >> >> Since it can only be vectorized with the predicate load, the hotspot must check whether the current backend supports it and falls back to the java scalar version if not. This is different from the normal masked vector load that the compiler will generate a full vector load and a vector blend if the predicate load is not supported. So to let the compiler make the expected action, an additional flag (i.e. `usePred`) is added to the existing "loadMasked" intrinsic, with the value "true" for the IOOBE part while "false" for the normal load. And the compiler will fail to intrinsify if the flag is "true" and the predicate load is not supported by the backend, which means that normal java path will be executed. >> >> Also adds the same vectorization support for masked: >> - fromByteArray/fromByteBuffer >> - fromBooleanArray >> - fromCharArray >> >> The performance for the new added benchmarks improve about `1.88x ~ 30.26x` on the x86 AVX-512 system: >> >> Benchmark before After Units >> LoadMaskedIOOBEBenchmark.byteLoadArrayMaskIOOBE 737.542 1387.069 ops/ms >> LoadMaskedIOOBEBenchmark.doubleLoadArrayMaskIOOBE 118.366 330.776 ops/ms >> LoadMaskedIOOBEBenchmark.floatLoadArrayMaskIOOBE 233.832 6125.026 ops/ms >> LoadMaskedIOOBEBenchmark.intLoadArrayMaskIOOBE 233.816 7075.923 ops/ms >> LoadMaskedIOOBEBenchmark.longLoadArrayMaskIOOBE 119.771 330.587 ops/ms >> LoadMaskedIOOBEBenchmark.shortLoadArrayMaskIOOBE 431.961 939.301 ops/ms >> >> Similar performance gain can also be observed on 512-bit SVE system. > > Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision: > > Rename the "usePred" to "offsetInRange" @PaulSandoz Could you please take a look at the Java changes when you find time. This PR from @XiaohongGong is a very good step towards long standing Vector API wish list for better tail loop handling. ------------- PR: https://git.openjdk.java.net/jdk/pull/8035 From shade at openjdk.java.net Thu Apr 28 18:01:06 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 28 Apr 2022 18:01:06 GMT Subject: RFR: 8285851: Cleanup C2AtomicParseAccess::needs_pinning() Message-ID: It returns `true` by default, and the setter for it was removed by [JDK-8235653](https://bugs.openjdk.java.net/browse/JDK-8235653). ------------- Commit messages: - Fix Changes: https://git.openjdk.java.net/jdk/pull/8455/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8455&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8285851 Stats: 7 lines in 2 files changed: 0 ins; 6 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8455.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8455/head:pull/8455 PR: https://git.openjdk.java.net/jdk/pull/8455 From kvn at openjdk.java.net Thu Apr 28 18:03:01 2022 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Thu, 28 Apr 2022 18:03:01 GMT Subject: RFR: 8285487: Do not generate trampolines for runtime calls if they are not needed [v2] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 14:34:39 GMT, Evgeny Astigeevich wrote: >> [JDK-8280872](https://bugs.openjdk.java.net/browse/JDK-8280872) put the non-nmethod segment between two others. It made trampolines for runtime calls redundant in most cases. >> >> This PR uses `target_needs_far_branch()` for runtime calls to check whether they need trampolines. Trampolines are not generated if they are not needed. >> >> Testing: >> - `tier1`...`tier4`: Passed >> - `compiler/c2/aarch64/TestTrampoline.java`: Passed >> >> Note: `compiler/c2/aarch64/TestTrampoline.java` requires the release build. This is because debug builds have the branch range set to 2M which causes always generation of trampolines. > > Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: > > XX:ReservedCodeCacheSize=130M for test and update comments src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 407: > 405: // Once they are generated neither a caller nor a callee address cannot be changed. > 406: // Check whether a far branch is needed to reach the target. > 407: return target_needs_far_branch(entry.target()); >From what I understand `target_needs_far_branch()` works only for stubs which are inside CodeCache. `runtime` method, as you correctly pointed, is code in VM which can be in any distance from CodeCache. For example, it will give incorrect answer if CodeCache size is small: https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp#L391 Or I am confused by the name of this method `target_needs_trampoline` and the comment. Do you actually mean `need_far_branch_for_trampoline`? ------------- PR: https://git.openjdk.java.net/jdk/pull/8403 From duke at openjdk.java.net Thu Apr 28 18:07:36 2022 From: duke at openjdk.java.net (XenoAmess) Date: Thu, 28 Apr 2022 18:07:36 GMT Subject: RFR: 8285149: Using HashMap.newHashMap to replace new HashMap(int) [v6] In-Reply-To: References: Message-ID: > These are the changes that too many to be reviewed in 8186958, thus split some of them out. XenoAmess has updated the pull request incrementally with one additional commit since the last revision: change from 3 to 1 according to wangweij ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8301/files - new: https://git.openjdk.java.net/jdk/pull/8301/files/c9cfb50a..1b4bac0f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8301&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8301&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8301.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8301/head:pull/8301 PR: https://git.openjdk.java.net/jdk/pull/8301 From duke at openjdk.java.net Thu Apr 28 18:07:37 2022 From: duke at openjdk.java.net (XenoAmess) Date: Thu, 28 Apr 2022 18:07:37 GMT Subject: RFR: 8285149: Using HashMap.newHashMap to replace new HashMap(int) [v5] In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 17:36:41 GMT, Weijun Wang wrote: > Looks like 1 is enough. @wangweij done. ------------- PR: https://git.openjdk.java.net/jdk/pull/8301 From mcimadamore at openjdk.java.net Thu Apr 28 18:10:57 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 28 Apr 2022 18:10:57 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v34] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/424 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Downcall and upcall tests use wrong layout which is missing some trailing padding ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7888/files - new: https://git.openjdk.java.net/jdk/pull/7888/files/5866bbb5..945317ec Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=33 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=32-33 Stats: 9 lines in 2 files changed: 7 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7888.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888 PR: https://git.openjdk.java.net/jdk/pull/7888 From egahlin at openjdk.java.net Thu Apr 28 19:34:10 2022 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Thu, 28 Apr 2022 19:34:10 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e Marked as reviewed by egahlin (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From duke at openjdk.java.net Thu Apr 28 20:01:55 2022 From: duke at openjdk.java.net (Evgeny Astigeevich) Date: Thu, 28 Apr 2022 20:01:55 GMT Subject: RFR: 8285487: Do not generate trampolines for runtime calls if they are not needed [v2] In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 17:58:53 GMT, Vladimir Kozlov wrote: > runtime method, as you correctly pointed, is code in VM which can be in any distance from CodeCache. Good catch. The function works with assumptions of `MacroAssembler::trampoline_call`. `MacroAssembler::trampoline_call` implicitly assumes the target is inside `CodeCache`: // Maybe emit a call via a trampoline. If the code cache is small // trampolines won't be emitted. I'll move the code of `target_needs_far_branch` inside of `MacroAssembler::trampoline_call`. I'll also add an assert checking the target address is inside `CodeCache`. ------------- PR: https://git.openjdk.java.net/jdk/pull/8403 From ayang at openjdk.java.net Thu Apr 28 20:13:35 2022 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Thu, 28 Apr 2022 20:13:35 GMT Subject: RFR: 8285364: Remove REF_ enum for java.lang.ref.Reference [v4] In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 11:05:45 GMT, Kim Barrett wrote: >> Albert Mingkun Yang has updated the pull request incrementally with two additional commits since the last revision: >> >> - comment >> - Rework reference type initialization >> >> Signed-off-by: Albert Yang > > src/hotspot/share/classfile/classFileParser.cpp line 6098: > >> 6096: >> 6097: return _super_klass->reference_type() != REF_NONE; >> 6098: } > > Stylistically, I'd prefer an if-ladder here. I might also swap the reference-type check and the name check, so the for-bootstrapping name check case being last (with a comment to that effect). These if-checks more or less mirror the type hierarchy, `Object -> Reference -> Soft|Weak... -> ...`. Then, walking down the type hierarchy using the early-return style here makes more sense to me. > src/hotspot/share/oops/instanceKlass.cpp line 497: > >> 495: _nest_host_index(0), >> 496: _init_state(allocated), >> 497: _reference_type(REF_NONE), > > This is initializing `_reference_type` to the wrong value for a `InstanceRefKlass` object, which then needs to reset it in the derived constructor. Why not get the reference type from the parser? The (currently file-scoped static) determine_reference_type function in instanceRefKlass.cpp doesn't have any dependency on the klass object being constructed, just the parser. The current approach limits the knowledge of non-strong ref types to `instanceRefKlass` file. ------------- PR: https://git.openjdk.java.net/jdk/pull/8332 From ayang at openjdk.java.net Thu Apr 28 20:13:34 2022 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Thu, 28 Apr 2022 20:13:34 GMT Subject: RFR: 8285364: Remove REF_ enum for java.lang.ref.Reference [v5] In-Reply-To: References: Message-ID: <44AueDGOTyuK9Lsclh3_lrRjAnXqCvSCjNf3vYEcN5k=.ceb37603-399b-4852-8512-99079833fe11@github.com> > Simple rename and some comments update. > > Test: build Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: review ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8332/files - new: https://git.openjdk.java.net/jdk/pull/8332/files/e4f6a66a..4b9081be Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8332&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8332&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8332.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8332/head:pull/8332 PR: https://git.openjdk.java.net/jdk/pull/8332 From dlong at openjdk.java.net Thu Apr 28 21:23:55 2022 From: dlong at openjdk.java.net (Dean Long) Date: Thu, 28 Apr 2022 21:23:55 GMT Subject: RFR: 8285301: C2: assert(!requires_atomic_access) failed: can't ensure atomicity [v2] In-Reply-To: References: Message-ID: <7so-sC0KzbXZPeip5XPOEhtzv7vjP-siIp8iEmg3HAo=.a3617e56-fd51-4431-9231-ffeeed1189aa@github.com> On Thu, 28 Apr 2022 05:34:31 GMT, Tobias Hartmann wrote: >> We hit asserts in `BarrierSetC2::load_at_resolved` and `BarrierSetC2::store_at_resolved` when running with `-XX:+AlwaysAtomicAccesses` because the corresponding code paths have not been implemented yet. Although the assert triggers on all platforms, it only affects long and double accesses on 32-bit systems (everything else is atomic anyway). >> >> I moved the `requires_atomic_access` logic into `LoadNode::make` and `StoreNode::make` and refactored related code. >> >> I noticed that `LoadNode::convert_to_reinterpret_load` and `StoreNode::convert_to_reinterpret_store` did not properly check for `requires_atomic_access` and fixed that as well. >> >> I'm currently running all tests with `-XX:+AlwaysAtomicAccesses`. >> >> Thanks, >> Tobias > > Tobias Hartmann has updated the pull request incrementally with two additional commits since the last revision: > > - Removed default arg > - Invoking Opcode only once. Added comment to test Marked as reviewed by dlong (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8422 From duke at openjdk.java.net Thu Apr 28 21:55:25 2022 From: duke at openjdk.java.net (Evgeny Astigeevich) Date: Thu, 28 Apr 2022 21:55:25 GMT Subject: RFR: 8285487: Do not generate trampolines for runtime calls if they are not needed [v3] In-Reply-To: References: Message-ID: > [JDK-8280872](https://bugs.openjdk.java.net/browse/JDK-8280872) put the non-nmethod segment between two others. It made trampolines for runtime calls redundant in most cases. > > This PR uses `target_needs_far_branch()` for runtime calls to check whether they need trampolines. Trampolines are not generated if they are not needed. > > Testing: > - `tier1`...`tier4`: Passed > - `compiler/c2/aarch64/TestTrampoline.java`: Passed > > Note: `compiler/c2/aarch64/TestTrampoline.java` requires the release build. This is because debug builds have the branch range set to 2M which causes always generation of trampolines. Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: Move code of target_needs_trampoline inside trampoline_call ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8403/files - new: https://git.openjdk.java.net/jdk/pull/8403/files/859f422d..245da6e0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8403&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8403&range=01-02 Stats: 31 lines in 1 file changed: 9 ins; 20 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8403.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8403/head:pull/8403 PR: https://git.openjdk.java.net/jdk/pull/8403 From kvn at openjdk.java.net Thu Apr 28 22:20:02 2022 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Thu, 28 Apr 2022 22:20:02 GMT Subject: RFR: 8285487: Do not generate trampolines for runtime calls if they are not needed [v2] In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 19:58:38 GMT, Evgeny Astigeevich wrote: >> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 407: >> >>> 405: // Once they are generated neither a caller nor a callee address cannot be changed. >>> 406: // Check whether a far branch is needed to reach the target. >>> 407: return target_needs_far_branch(entry.target()); >> >> From what I understand `target_needs_far_branch()` works only for stubs which are inside CodeCache. >> `runtime` method, as you correctly pointed, is code in VM which can be in any distance from CodeCache. >> For example, it will give incorrect answer if CodeCache size is small: >> https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp#L391 >> >> Or I am confused by the name of this method `target_needs_trampoline` and the comment. >> Do you actually mean `need_far_branch_for_trampoline`? > >> runtime method, as you correctly pointed, is code in VM which can be in any distance from CodeCache. > > Good catch. The function works with assumptions of `MacroAssembler::trampoline_call`. > `MacroAssembler::trampoline_call` implicitly assumes the target is inside `CodeCache`: > > // Maybe emit a call via a trampoline. If the code cache is small > // trampolines won't be emitted. > > I'll move the code of `target_needs_trampoline` inside of `MacroAssembler::trampoline_call`. > I'll also add an assert checking the target address is inside `CodeCache`. I suggest to put somewhere description where `far` calls and `trampoline` should/can be used. Looking on `MacroAssembler::far_call()` and based on the assert there it targets only entries inside CodeCache. Which is strange because if `runtime` entry inside the 2gb range from any place in CodeCache you can use it. We have such check for x86: https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/assembler_x86.cpp#L11701 And you don't need trampoline if you can use `far` call to such `runtime` entry. If you need trampoline there is also choice how you call/jump to **it**. Trampoline code is inside CodeCache and `target_needs_far_branch()` works to find type of instruction to reach *trampoline*. That is what I though your changes are doing. ------------- PR: https://git.openjdk.java.net/jdk/pull/8403 From gli at openjdk.java.net Fri Apr 29 00:46:18 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Fri, 29 Apr 2022 00:46:18 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v34] In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 18:10:57 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.java.net/jeps/424 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Downcall and upcall tests use wrong layout which is missing some trailing padding Remind: please use the command `/jep JEP-424` [1] to mark this PR. [1] https://wiki.openjdk.java.net/display/SKARA/Pull+Request+Commands#PullRequestCommands-/jep ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From gli at openjdk.java.net Fri Apr 29 00:48:08 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Fri, 29 Apr 2022 00:48:08 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e Remind: please use the command `/jep JEP-425` [1] to mark this PR. [1] https://wiki.openjdk.java.net/display/SKARA/Pull+Request+Commands#PullRequestCommands-/jep ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From duke at openjdk.java.net Fri Apr 29 03:19:05 2022 From: duke at openjdk.java.net (Will) Date: Fri, 29 Apr 2022 03:19:05 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e Marked as reviewed by will-molloy at github.com (no known OpenJDK username). ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From yadongwang at openjdk.java.net Fri Apr 29 03:23:42 2022 From: yadongwang at openjdk.java.net (Yadong Wang) Date: Fri, 29 Apr 2022 03:23:42 GMT Subject: Integrated: 8285699: riscv: Provide information when hitting a HaltNode In-Reply-To: References: Message-ID: <80s7VjEjsF64wBFrmhhnNEpSLakZbQ6jFaWDxpYb-Xo=.17245b9d-6e44-4dde-b0a7-8ae2a7dd734d@github.com> On Thu, 28 Apr 2022 04:03:33 GMT, Yadong Wang wrote: > The code generated in MacroAssembler::stop is indeed grossly bloated with pusha()/popa() and a native call. We would like to follow the implementation in aarch64 port [JDK-8245986](https://bugs.openjdk.java.net/browse/JDK-8245986), and provide a halt reason when hitting a C2 HaltNode on riscv, and implement it by triggering illegal instruction exceptions. > > hs_err_pid log BEFORE: > > # > # A fatal error has been detected by the Java Runtime Environment: > # > # SIGILL (0x4) at pc=0x0000003fdd049cd0, pid=2203593, tid=2203614 > # > # JRE version: OpenJDK Runtime Environment (19.0) (fastdebug build 19-internal-adhoc.wangyadong.jdk) > # Java VM: OpenJDK 64-Bit Server VM (fastdebug 19-internal-adhoc.wangyadong.jdk, compiled mode, compressed oops, compressed class ptrs, g1 gc, linux-riscv64) > # Problematic frame: > # J 20 c2 compiler.unsafe.TestUnsafeLoadWithZeroAddress.main([Ljava/lang/String;)V (13 bytes) @ 0x0000003fdd049cd0 [0x0000003fdd049c40+0x0000000000000090] > # > # No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again > # > # If you would like to submit a bug report, please visit: > # https://bugreport.java.com/bugreport/crash.jsp > # > > --------------- S U M M A R Y ------------ > > Command Line: -Dtest.vm.opts= -Dtest.tool.vm.opts= -Dtest.compiler.opts= -Dtest.java.opts= -Dtest.jdk=/home/wangyadong/openjdk-19-internal-before -Dcompile.jdk=/home/wangyadong/openjdk-19-internal-before -Dtest.timeout.factor=1.0 -Dtest.root=/home/wangyadong/riscv-port/test/hotspot/jtreg -Dtest.name=compiler/unsafe/TestUnsafeLoadWithZeroAddress.java -Dtest.file=/home/wangyadong/riscv-port/test/hotspot/jtreg/compiler/unsafe/TestUnsafeLoadWithZeroAddress.java -Dtest.src=/home/wangyadong/riscv-port/test/hotspot/jtreg/compiler/unsafe -Dtest.src.path=/home/wangyadong/riscv-port/test/hotspot/jtreg/compiler/unsafe -Dtest.classes=/home/wangyadong/riscv-port/JTwork/classes/compiler/unsafe/TestUnsafeLoadWithZeroAddress.d -Dtest.class.path=/home/wangyadong/riscv-port/JTwork/classes/compiler/unsafe/TestUnsafeLoadWithZeroAddress.d -Dtest.modules=java.base/jdk.internal.misc:+open --add-modules=java.base --add-exports=java.base/jdk.internal.misc=ALL-UNNAMED --add-opens=java.base/jdk.internal.misc =ALL-UNNAMED -Xcomp -Xbatch -XX:-TieredCompilation -XX:+AlwaysIncrementalInline -XX:CompileCommand=compileonly,compiler.unsafe.TestUnsafeLoadWithZeroAddress::* com.sun.javatest.regtest.agent.MainWrapper /home/wangyadong/riscv-port/JTwork/compiler/unsafe/TestUnsafeLoadWithZeroAddress.d/main.0.jta > > Host: ubuntu, RISCV64, 4 cores, 15G, Ubuntu 21.04 > Time: Thu Apr 28 00:00:50 2022 CST elapsed time: 4.374528 seconds (0d 0h 0m 4s) > > --------------- T H R E A D --------------- > > Current thread (0x0000003fe8471060): JavaThread "MainThread" [_thread_in_Java, id=2203614, stack(0x0000003fc47a4000,0x0000003fc49a4000)] > > Stack: [0x0000003fc47a4000,0x0000003fc49a4000], sp=0x0000003fc49a1f00, free space=2039k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > J 20 c2 compiler.unsafe.TestUnsafeLoadWithZeroAddress.main([Ljava/lang/String;)V (13 bytes) @ 0x0000003fdd049cd0 [0x0000003fdd049c40+0x0000000000000090] > j java.lang.invoke.LambdaForm$DMH+0x0000000800080800.invokeStatic(Ljava/lang/Object;Ljava/lang/Object;)V+10 java.base at 19-internal > j java.lang.invoke.LambdaForm$MH+0x0000000800081c00.invoke(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;+33 java.base at 19-internal > j java.lang.invoke.Invokers$Holder.invokeExact_MT(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;+20 java.base at 19-internal > j jdk.internal.reflect.DirectMethodHandleAccessor.invokeImpl(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+55 java.base at 19-internal > j jdk.internal.reflect.DirectMethodHandleAccessor.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+23 java.base at 19-internal > j java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+102 java.base at 19-internal > j com.sun.javatest.regtest.agent.MainWrapper$MainThread.run()V+172 > j java.lang.Thread.run()V+11 java.base at 19-internal > v ~StubRoutines::call_stub > V [libjvm.so+0xa8a0fe] JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)+0x4cc > V [libjvm.so+0xa8a674] JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)+0x3e0 > V [libjvm.so+0xa8aa02] JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*)+0x60 > V [libjvm.so+0xbcf9b4] thread_entry(JavaThread*, JavaThread*)+0x88 > V [libjvm.so+0x1299d94] JavaThread::thread_main_inner()+0x24e > V [libjvm.so+0x12a0cd4] Thread::call_run()+0xd4 > V [libjvm.so+0xf3c52e] thread_native_entry(Thread*)+0xee > C [libpthread.so.0+0x7460] start_thread+0xb4 > C [libc.so.6+0xa7362] > > hs_err_pid log AFTER: > > # > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (0xe0000000), pid=2178405, tid=2178428 > # stop: unsafe off-heap access with zero address > # > # JRE version: OpenJDK Runtime Environment (19.0) (fastdebug build 19-internal-adhoc.wangyadong.jdk) > # Java VM: OpenJDK 64-Bit Server VM (fastdebug 19-internal-adhoc.wangyadong.jdk, compiled mode, compressed oops, compressed class ptrs, g1 gc, linux-riscv64) > # Problematic frame: > # J 20 c2 compiler.unsafe.TestUnsafeLoadWithZeroAddress.main([Ljava/lang/String;)V (13 bytes) @ 0x0000003fe0f4c5d0 [0x0000003fe0f4c540+0x0000000000000090] > # > # No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again > # > # If you would like to submit a bug report, please visit: > # https://bugreport.java.com/bugreport/crash.jsp > # > > --------------- S U M M A R Y ------------ > > Command Line: -Dtest.vm.opts= -Dtest.tool.vm.opts= -Dtest.compiler.opts= -Dtest.java.opts= -Dtest.jdk=/home/wangyadong/openjdk-19-internal-fastdebug -Dcompile.jdk=/home/wangyadong/openjdk-19-internal-fastdebug -Dtest.timeout.factor=1.0 -Dtest.root=/home/wangyadong/riscv-port/test/hotspot/jtreg -Dtest.name=compiler/unsafe/TestUnsafeLoadWithZeroAddress.java -Dtest.file=/home/wangyadong/riscv-port/test/hotspot/jtreg/compiler/unsafe/TestUnsafeLoadWithZeroAddress.java -Dtest.src=/home/wangyadong/riscv-port/test/hotspot/jtreg/compiler/unsafe -Dtest.src.path=/home/wangyadong/riscv-port/test/hotspot/jtreg/compiler/unsafe -Dtest.classes=/home/wangyadong/riscv-port/JTwork/classes/compiler/unsafe/TestUnsafeLoadWithZeroAddress.d -Dtest.class.path=/home/wangyadong/riscv-port/JTwork/classes/compiler/unsafe/TestUnsafeLoadWithZeroAddress.d -Dtest.modules=java.base/jdk.internal.misc:+open --add-modules=java.base --add-exports=java.base/jdk.internal.misc=ALL-UNNAMED --add-opens=java.base/jdk.interna l.misc=ALL-UNNAMED -Xcomp -Xbatch -XX:-TieredCompilation -XX:+AlwaysIncrementalInline -XX:CompileCommand=compileonly,compiler.unsafe.TestUnsafeLoadWithZeroAddress::* com.sun.javatest.regtest.agent.MainWrapper /home/wangyadong/riscv-port/JTwork/compiler/unsafe/TestUnsafeLoadWithZeroAddress.d/main.0.jta > > Host: ubuntu, RISCV64, 4 cores, 15G, Ubuntu 21.04 > Time: Wed Apr 27 23:41:11 2022 CST elapsed time: 4.469731 seconds (0d 0h 0m 4s) > > --------------- T H R E A D --------------- > > Current thread (0x0000003fec45d7a0): JavaThread "MainThread" [_thread_in_Java, id=2178428, stack(0x0000003fc91fe000,0x0000003fc93fe000)] > > Stack: [0x0000003fc91fe000,0x0000003fc93fe000], sp=0x0000003fc93fbf00, free space=2039k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > J 20 c2 compiler.unsafe.TestUnsafeLoadWithZeroAddress.main([Ljava/lang/String;)V (13 bytes) @ 0x0000003fe0f4c5d0 [0x0000003fe0f4c540+0x0000000000000090] > j java.lang.invoke.LambdaForm$DMH+0x00000008000c0000.invokeStatic(Ljava/lang/Object;Ljava/lang/Object;)V+10 java.base at 19-internal > j java.lang.invoke.LambdaForm$MH+0x00000008000c1400.invoke(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;+33 java.base at 19-internal > j java.lang.invoke.Invokers$Holder.invokeExact_MT(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;+20 java.base at 19-internal > j jdk.internal.reflect.DirectMethodHandleAccessor.invokeImpl(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+55 java.base at 19-internal > j jdk.internal.reflect.DirectMethodHandleAccessor.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+23 java.base at 19-internal > j java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+102 java.base at 19-internal > j com.sun.javatest.regtest.agent.MainWrapper$MainThread.run()V+172 > j java.lang.Thread.run()V+11 java.base at 19-internal > v ~StubRoutines::call_stub > V [libjvm.so+0xa8a0d2] JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)+0x4cc > V [libjvm.so+0xa8a648] JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)+0x3e0 > V [libjvm.so+0xa8a9d6] JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*)+0x60 > V [libjvm.so+0xbcf988] thread_entry(JavaThread*, JavaThread*)+0x88 > V [libjvm.so+0x1299ca6] JavaThread::thread_main_inner()+0x24e > V [libjvm.so+0x12a0be6] Thread::call_run()+0xd4 > V [libjvm.so+0xf3c294] thread_native_entry(Thread*)+0xee > C [libpthread.so.0+0x7460] start_thread+0xb4 > C [libc.so.6+0xa7362] > > > This patch passes hotspot and jdk tiere1 on unmatched, and all jtreg tests are tested on Qemu without new failures. This pull request has now been integrated. Changeset: 94b533a9 Author: Yadong Wang Committer: Fei Yang URL: https://git.openjdk.java.net/jdk/commit/94b533a94c97a46181394da5d6a7f4ee8b69a0c4 Stats: 98 lines in 9 files changed: 45 ins; 39 del; 14 mod 8285699: riscv: Provide information when hitting a HaltNode Reviewed-by: fyang ------------- PR: https://git.openjdk.java.net/jdk/pull/8442 From dholmes at openjdk.java.net Fri Apr 29 04:25:35 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 29 Apr 2022 04:25:35 GMT Subject: RFR: 8282477: [x86, aarch64] vmassert(_last_Java_pc == NULL, "already walkable"); fails with async profiler [v3] In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 10:55:29 GMT, Johannes Bechberger wrote: >> Fix the assertion by replacing it by assertion that does not fail. > > Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: > > Use make_walkable General shape of the change looks okay. Just one change below that leads to a broader query. :) Thanks, David src/hotspot/cpu/aarch64/frame_aarch64.cpp line 835: > 833: #endif > 834: > 835: void JavaFrameAnchor::make_walkable(Thread* thread) { No need to change the type of `thread` (the later cast in the assert was unnecessary). Though why is the thread passed in as it is unused except in the assert?? ------------- Changes requested by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8209 From sspitsyn at openjdk.java.net Fri Apr 29 05:52:00 2022 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Fri, 29 Apr 2022 05:52:00 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e test/hotspot/jtreg/serviceability/jvmti/events/Breakpoint/breakpoint01/libbreakpoint01.cpp line 66: > 64: for (i = 0; i < METH_NUM; i++) > 65: bpEvents[i] = 0; > 66: } As I understand all new tests are C++ based. So, I'd suggest to always use C++ style of loops: for (int i = 0; i < METH_NUM; i++) ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From thartmann at openjdk.java.net Fri Apr 29 06:15:43 2022 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Fri, 29 Apr 2022 06:15:43 GMT Subject: RFR: 8285301: C2: assert(!requires_atomic_access) failed: can't ensure atomicity [v2] In-Reply-To: References: Message-ID: <52z3XHTKVu_3axw2cFTdQyVPLZHqMmrrFk0ql80WbhU=.63e0e7f3-789a-4936-974f-d942dadb3124@github.com> On Thu, 28 Apr 2022 05:34:31 GMT, Tobias Hartmann wrote: >> We hit asserts in `BarrierSetC2::load_at_resolved` and `BarrierSetC2::store_at_resolved` when running with `-XX:+AlwaysAtomicAccesses` because the corresponding code paths have not been implemented yet. Although the assert triggers on all platforms, it only affects long and double accesses on 32-bit systems (everything else is atomic anyway). >> >> I moved the `requires_atomic_access` logic into `LoadNode::make` and `StoreNode::make` and refactored related code. >> >> I noticed that `LoadNode::convert_to_reinterpret_load` and `StoreNode::convert_to_reinterpret_store` did not properly check for `requires_atomic_access` and fixed that as well. >> >> I'm currently running all tests with `-XX:+AlwaysAtomicAccesses`. >> >> Thanks, >> Tobias > > Tobias Hartmann has updated the pull request incrementally with two additional commits since the last revision: > > - Removed default arg > - Invoking Opcode only once. Added comment to test Vladimir, Dean, thanks for the reviews! ------------- PR: https://git.openjdk.java.net/jdk/pull/8422 From thartmann at openjdk.java.net Fri Apr 29 06:15:47 2022 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Fri, 29 Apr 2022 06:15:47 GMT Subject: Integrated: 8285301: C2: assert(!requires_atomic_access) failed: can't ensure atomicity In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 10:25:36 GMT, Tobias Hartmann wrote: > We hit asserts in `BarrierSetC2::load_at_resolved` and `BarrierSetC2::store_at_resolved` when running with `-XX:+AlwaysAtomicAccesses` because the corresponding code paths have not been implemented yet. Although the assert triggers on all platforms, it only affects long and double accesses on 32-bit systems (everything else is atomic anyway). > > I moved the `requires_atomic_access` logic into `LoadNode::make` and `StoreNode::make` and refactored related code. > > I noticed that `LoadNode::convert_to_reinterpret_load` and `StoreNode::convert_to_reinterpret_store` did not properly check for `requires_atomic_access` and fixed that as well. > > I'm currently running all tests with `-XX:+AlwaysAtomicAccesses`. > > Thanks, > Tobias This pull request has now been integrated. Changeset: 0a4a6403 Author: Tobias Hartmann URL: https://git.openjdk.java.net/jdk/commit/0a4a6403bbdfa7a9f632dbf625435d9aaf04074c Stats: 188 lines in 10 files changed: 57 ins; 78 del; 53 mod 8285301: C2: assert(!requires_atomic_access) failed: can't ensure atomicity Reviewed-by: kvn, dlong ------------- PR: https://git.openjdk.java.net/jdk/pull/8422 From sspitsyn at openjdk.java.net Fri Apr 29 06:17:16 2022 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Fri, 29 Apr 2022 06:17:16 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e test/hotspot/jtreg/serviceability/jvmti/events/Breakpoint/breakpoint01/libbreakpoint01.cpp line 139: > 137: thr_info.name, (jni->IsVirtualThread(thread) == JNI_TRUE) ? "virtual" : "kernel", > 138: (thr_info.is_daemon == JNI_TRUE) ? "deamon" : "user"); > 139: } I'd suggest to add locals (their names are up to you): const char* thr_virtual_tag = jni->IsVirtualThread(thread) == JNI_TRUE ? "virtual" : "kernel"; const char* thr_daemon_tag == JNI_TRUE) ? "deamon" : "user"; It is better to place togeter lines: 129+130. Line 137 is not aligned, and there are many unneeded spaces. The '()' around conditions are not needed. At least, I do not see them increasing readability. test/hotspot/jtreg/serviceability/jvmti/events/Breakpoint/breakpoint01/libbreakpoint01.cpp line 167: > 165: result = checkStatus = STATUS_FAILED; > 166: LOG( > 167: "TEST FAILED: Breakpoint event with unexpected class signature:\n" Combine lines 166+167. test/hotspot/jtreg/serviceability/jvmti/events/Breakpoint/breakpoint01/libbreakpoint01.cpp line 187: > 185: jboolean isVirtual = jni->IsVirtualThread(thread); > 186: if (isVirtual != METHODS_ATTRS[i]) { > 187: LOG("TEST FAILED: IsVirtualThread check failed with unexpected result %d when expected is %d\n", isVirtual, METHODS_ATTRS[i]); Line 187 is too long and can be splitted. test/hotspot/jtreg/serviceability/jvmti/events/Breakpoint/breakpoint01/libbreakpoint01.cpp line 231: > 229: result = STATUS_FAILED; > 230: LOG( > 231: "TEST FAILED: wrong number of Breakpoint events\n" Combine 230+231. test/hotspot/jtreg/serviceability/jvmti/events/Breakpoint/breakpoint01/libbreakpoint01.cpp line 307: > 305: if (agent_lock == NULL) { > 306: return JNI_ERR; > 307: } Better to also use same style with curly brackets in fragments: 293, 296, 299. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From sspitsyn at openjdk.java.net Fri Apr 29 06:23:14 2022 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Fri, 29 Apr 2022 06:23:14 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e test/hotspot/jtreg/serviceability/jvmti/events/ClassLoad/classload01/libclassload01.cpp line 139: > 137: primClsEvents[i]++; > 138: LOG( > 139: "TEST FAILED: JVMTI_EVENT_CLASS_LOAD event received for\n" Combine 138+138. I won't comment this more in hope the same will be fixed in all tests. test/hotspot/jtreg/serviceability/jvmti/events/ClassLoad/classload01/libclassload01.cpp line 177: > 175: return JNI_VERSION_1_8; > 176: } > 177: #endif One empty line would be nice to add after 177. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From sspitsyn at openjdk.java.net Fri Apr 29 06:39:57 2022 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Fri, 29 Apr 2022 06:39:57 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e test/hotspot/jtreg/serviceability/jvmti/events/ClassPrepare/classprep01/libclassprep01.cpp line 59: > 57: static jvmtiEventCallbacks callbacks; > 58: static jint result = PASSED; > 59: static volatile size_t eventsCount = 0; // TODO these 2 vars mofified from different threads in getReady/check. What to DO??? I'd suggest to use RawMonitorLocker with event_lock or counter_lock to protect updates of these counters. You can remove this comment then. test/hotspot/jtreg/serviceability/jvmti/events/ClassPrepare/classprep01/libclassprep01.cpp line 201: > 199: LOG("\n"); > 200: > 201: Too many empty lines. It might make sense to do a common cleanup with all edits like this. test/hotspot/jtreg/serviceability/jvmti/events/ClassPrepare/classprep01/libclassprep01.cpp line 258: > 256: return JNI_VERSION_1_8; > 257: } > 258: #endif Empty line is missed => common cleanup. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From duke at openjdk.java.net Fri Apr 29 06:41:52 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Fri, 29 Apr 2022 06:41:52 GMT Subject: RFR: 8282477: [x86, aarch64] vmassert(_last_Java_pc == NULL, "already walkable"); fails with async profiler [v3] In-Reply-To: References: Message-ID: On Fri, 29 Apr 2022 04:17:09 GMT, David Holmes wrote: > Though why is the thread passed in as it is unused except in the assert?? I don't know. Removing it would clean up the code. ------------- PR: https://git.openjdk.java.net/jdk/pull/8209 From sspitsyn at openjdk.java.net Fri Apr 29 06:46:46 2022 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Fri, 29 Apr 2022 06:46:46 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e test/hotspot/jtreg/serviceability/jvmti/events/Exception/exception01/libexception01.cpp line 178: > 176: ex.c_cls, ex.c_name, ex.c_sig, > 177: (jint)(ex.c_loc >> 32), (jint)ex.c_loc); > 178: result = STATUS_FAILED; Unaligned lines in the range: 172-177. There are some non-uinified unneeded spaces at lines 172,175. test/hotspot/jtreg/serviceability/jvmti/events/Exception/exception01/libexception01.cpp line 287: > 285: } > 286: > 287: eventsCount = 0; Counters are not protected with locks. I'm not sure it is a real problem here but would be better to double-check. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From sspitsyn at openjdk.java.net Fri Apr 29 06:50:40 2022 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Fri, 29 Apr 2022 06:50:40 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e I'm sorry for the noise with my comments. I'll continue to discuss it privately unless there is something really important. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From mcimadamore at openjdk.java.net Fri Apr 29 08:09:46 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 29 Apr 2022 08:09:46 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v34] In-Reply-To: References: Message-ID: On Fri, 29 Apr 2022 00:44:01 GMT, Guoxiong Li wrote: > Remind: please use the command `/jep JEP-424` [1] to mark this PR. > > [1] https://wiki.openjdk.java.net/display/SKARA/Pull+Request+Commands#PullRequestCommands-/jep Question: I'm willing to try it out. If something goes wrong - would a `jep unneeded` be enough to "unstuck" this PR? ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From mcimadamore at openjdk.java.net Fri Apr 29 08:15:32 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 29 Apr 2022 08:15:32 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v35] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/424 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Tweak Addressable javadoc ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7888/files - new: https://git.openjdk.java.net/jdk/pull/7888/files/945317ec..d1fcf012 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=34 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=33-34 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7888.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888 PR: https://git.openjdk.java.net/jdk/pull/7888 From gli at openjdk.java.net Fri Apr 29 08:33:44 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Fri, 29 Apr 2022 08:33:44 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v34] In-Reply-To: References: Message-ID: On Fri, 29 Apr 2022 08:06:24 GMT, Maurizio Cimadamore wrote: > would a jep unneeded be enough to "unstuck" this PR? Yes if no bug. Conceptually, the `/jep unneeded` will behave as no jep command. ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From adinn at openjdk.java.net Fri Apr 29 09:49:41 2022 From: adinn at openjdk.java.net (Andrew Dinn) Date: Fri, 29 Apr 2022 09:49:41 GMT Subject: RFR: 8285802: AArch64: Consistently handle offsets in MacroAssembler as 64-bit quantities [v4] In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 12:38:20 GMT, Andrew Haley wrote: >> In a few places we pass offsets as 32-bit ints rather than 64-bit longs, and we're not consistent about it. We shold have a clean 64-bit path for offset generation and validation. > > Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: > > Windows! Looks ok, even on Windows! (the UI test that failed was because of a timeout so I assume it can be disregarded). ------------- Marked as reviewed by adinn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8448 From duke at openjdk.java.net Fri Apr 29 10:41:45 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Fri, 29 Apr 2022 10:41:45 GMT Subject: RFR: 8285794: AsyncGetCallTrace might acquire a lock via JavaThread::thread_from_jni_environment [v2] In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 13:18:59 GMT, David Holmes wrote: >> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: >> >> Use Thread::current_or_null_safe() and add comments > > src/hotspot/share/prims/forte.cpp line 571: > >> 569: Thread* raw_thread = Thread::current_or_null_safe(); >> 570: >> 571: if (trace->env_id == NULL || raw_thread == NULL || !raw_thread->is_Java_thread() || ((JavaThread*)raw_thread)->is_exiting()) { > > use `rawThread->as_JavaThread()` not a plain cast. this method does not exist ------------- PR: https://git.openjdk.java.net/jdk/pull/8446 From kbarrett at openjdk.java.net Fri Apr 29 11:00:44 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Fri, 29 Apr 2022 11:00:44 GMT Subject: RFR: 8285364: Remove REF_ enum for java.lang.ref.Reference [v4] In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 20:06:47 GMT, Albert Mingkun Yang wrote: >> src/hotspot/share/oops/instanceKlass.cpp line 497: >> >>> 495: _nest_host_index(0), >>> 496: _init_state(allocated), >>> 497: _reference_type(REF_NONE), >> >> This is initializing `_reference_type` to the wrong value for a `InstanceRefKlass` object, which then needs to reset it in the derived constructor. Why not get the reference type from the parser? The (currently file-scoped static) determine_reference_type function in instanceRefKlass.cpp doesn't have any dependency on the klass object being constructed, just the parser. > > The current approach limits the knowledge of non-strong ref types to `instanceRefKlass` file. The `_reference_type` used to be initialized correctly in most cases, but needed fixing up for a few cases during bootstrapping. With this change it is *never* initialized correctly for Reference subtypes and always needs an initialization kludge for them. That's not an improvement. ------------- PR: https://git.openjdk.java.net/jdk/pull/8332 From mdoerr at openjdk.java.net Fri Apr 29 11:01:46 2022 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Fri, 29 Apr 2022 11:01:46 GMT Subject: RFR: 8282477: [x86, aarch64] vmassert(_last_Java_pc == NULL, "already walkable"); fails with async profiler [v3] In-Reply-To: References: Message-ID: On Fri, 29 Apr 2022 06:38:47 GMT, Johannes Bechberger wrote: >> src/hotspot/cpu/aarch64/frame_aarch64.cpp line 835: >> >>> 833: #endif >>> 834: >>> 835: void JavaFrameAnchor::make_walkable(Thread* thread) { >> >> No need to change the type of `thread` (the later cast in the assert was unnecessary). >> >> Though why is the thread passed in as it is unused except in the assert?? > >> Though why is the thread passed in as it is unused except in the assert?? > > I don't know. Removing it would clean up the code. Right, I also noticed that. Unneeded `Thread::current()` calls are not nice, either. If we can live without the assertion I'd like to see the thread parameter go away. ------------- PR: https://git.openjdk.java.net/jdk/pull/8209 From duke at openjdk.java.net Fri Apr 29 11:07:45 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Fri, 29 Apr 2022 11:07:45 GMT Subject: RFR: 8282477: [x86, aarch64] vmassert(_last_Java_pc == NULL, "already walkable"); fails with async profiler [v3] In-Reply-To: References: Message-ID: On Fri, 29 Apr 2022 10:58:28 GMT, Martin Doerr wrote: >>> Though why is the thread passed in as it is unused except in the assert?? >> >> I don't know. Removing it would clean up the code. > > Right, I also noticed that. Unneeded `Thread::current()` calls are not nice, either. If we can live without the assertion I'd like to see the thread parameter go away. I removed the assertion. ------------- PR: https://git.openjdk.java.net/jdk/pull/8209 From duke at openjdk.java.net Fri Apr 29 11:14:38 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Fri, 29 Apr 2022 11:14:38 GMT Subject: RFR: 8282477: [x86, aarch64] vmassert(_last_Java_pc == NULL, "already walkable"); fails with async profiler [v4] In-Reply-To: References: Message-ID: > Fix the assertion by replacing it by assertion that does not fail. Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: Remove Thread from make_walkable signature ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8209/files - new: https://git.openjdk.java.net/jdk/pull/8209/files/83ed9c70..c6b6b6d6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8209&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8209&range=02-03 Stats: 26 lines in 17 files changed: 3 ins; 2 del; 21 mod Patch: https://git.openjdk.java.net/jdk/pull/8209.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8209/head:pull/8209 PR: https://git.openjdk.java.net/jdk/pull/8209 From ayang at openjdk.java.net Fri Apr 29 11:42:44 2022 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Fri, 29 Apr 2022 11:42:44 GMT Subject: RFR: 8285364: Remove REF_ enum for java.lang.ref.Reference [v4] In-Reply-To: References: Message-ID: On Fri, 29 Apr 2022 10:56:49 GMT, Kim Barrett wrote: >> The current approach limits the knowledge of non-strong ref types to `instanceRefKlass` file. > > The `_reference_type` used to be initialized correctly in most cases, but > needed fixing up for a few cases during bootstrapping. With this change it is > *never* initialized correctly for Reference subtypes and always needs an > initialization kludge for them. That's not an improvement. `_reference_type` always gets the correct value after the constructor is run. The member initializer list just follows the convention of having all fields set. One could move this field inside the constructor body to ensure this field is set only once. ------------- PR: https://git.openjdk.java.net/jdk/pull/8332 From aph at openjdk.java.net Fri Apr 29 12:49:46 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Fri, 29 Apr 2022 12:49:46 GMT Subject: RFR: 8285487: Do not generate trampolines for runtime calls if they are not needed [v3] In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 21:55:25 GMT, Evgeny Astigeevich wrote: >> [JDK-8280872](https://bugs.openjdk.java.net/browse/JDK-8280872) put the non-nmethod segment between two others. It made trampolines for runtime calls redundant in most cases. >> >> This PR uses `target_needs_far_branch()` for runtime calls to check whether they need trampolines. Trampolines are not generated if they are not needed. >> >> Testing: >> - `tier1`...`tier4`: Passed >> - `compiler/c2/aarch64/TestTrampoline.java`: Passed >> >> Note: `compiler/c2/aarch64/TestTrampoline.java` requires the release build. This is because debug builds have the branch range set to 2M which causes always generation of trampolines. > > Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: > > Move code of target_needs_trampoline inside trampoline_call src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 578: > 576: // If CodeCache size > 128M, such Java calls must have reserved trampolines for cases > 577: // when a new callee address out of 128M range. > 578: bool need_trampoline = (entry.rspec().type() == relocInfo::runtime_call_type) ? This isn't clear. Are you trying to prove that, even if the caller is moved as far as it possibly can be from the runtime target, the branch will still be in range? That is to say, all of the code in the current CodeHeap is within 128M of the target? ------------- PR: https://git.openjdk.java.net/jdk/pull/8403 From aph at openjdk.java.net Fri Apr 29 12:57:43 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Fri, 29 Apr 2022 12:57:43 GMT Subject: RFR: 8285487: Do not generate trampolines for runtime calls if they are not needed [v3] In-Reply-To: References: Message-ID: <6BLRx1h-CQvukYtRVcBNAROhod7j2jRNdQKU-0Cgnc0=.a0d3270e-8a82-4596-a0d0-3c295981d885@github.com> On Thu, 28 Apr 2022 21:55:25 GMT, Evgeny Astigeevich wrote: >> [JDK-8280872](https://bugs.openjdk.java.net/browse/JDK-8280872) put the non-nmethod segment between two others. It made trampolines for runtime calls redundant in most cases. >> >> This PR uses `target_needs_far_branch()` for runtime calls to check whether they need trampolines. Trampolines are not generated if they are not needed. >> >> Testing: >> - `tier1`...`tier4`: Passed >> - `compiler/c2/aarch64/TestTrampoline.java`: Passed >> >> Note: `compiler/c2/aarch64/TestTrampoline.java` requires the release build. This is because debug builds have the branch range set to 2M which causes always generation of trampolines. > > Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: > > Move code of target_needs_trampoline inside trampoline_call src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 579: > 577: // when a new callee address out of 128M range. > 578: bool need_trampoline = (entry.rspec().type() == relocInfo::runtime_call_type) ? > 579: target_needs_far_branch(entry.target()) : far_branches(); This is all very confusing too. Can't `target_needs_far_branch()` handle all cases? So we don't need a conditional expression here. ------------- PR: https://git.openjdk.java.net/jdk/pull/8403 From aph at openjdk.java.net Fri Apr 29 13:03:51 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Fri, 29 Apr 2022 13:03:51 GMT Subject: Integrated: 8285802: AArch64: Consistently handle offsets in MacroAssembler as 64-bit quantities In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 09:59:13 GMT, Andrew Haley wrote: > In a few places we pass offsets as 32-bit ints rather than 64-bit longs, and we're not consistent about it. We shold have a clean 64-bit path for offset generation and validation. This pull request has now been integrated. Changeset: df4d5cf5 Author: Andrew Haley URL: https://git.openjdk.java.net/jdk/commit/df4d5cf5f53c1451487e6301d31c196fac029f7a Stats: 13 lines in 3 files changed: 0 ins; 0 del; 13 mod 8285802: AArch64: Consistently handle offsets in MacroAssembler as 64-bit quantities Reviewed-by: ngasson, adinn ------------- PR: https://git.openjdk.java.net/jdk/pull/8448 From duke at openjdk.java.net Fri Apr 29 13:34:54 2022 From: duke at openjdk.java.net (Evgeny Astigeevich) Date: Fri, 29 Apr 2022 13:34:54 GMT Subject: RFR: 8285487: Do not generate trampolines for runtime calls if they are not needed [v2] In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 22:16:19 GMT, Vladimir Kozlov wrote: >>> runtime method, as you correctly pointed, is code in VM which can be in any distance from CodeCache. >> >> Good catch. The function works with assumptions of `MacroAssembler::trampoline_call`. >> `MacroAssembler::trampoline_call` implicitly assumes the target is inside `CodeCache`: >> >> // Maybe emit a call via a trampoline. If the code cache is small >> // trampolines won't be emitted. >> >> I'll move the code of `target_needs_trampoline` inside of `MacroAssembler::trampoline_call`. >> I'll also add an assert checking the target address is inside `CodeCache`. > > I suggest to put somewhere description where `far` calls and `trampoline` should/can be used. > > Looking on `MacroAssembler::far_call()` and based on the assert there it targets only entries inside CodeCache. Which is strange because if `runtime` entry inside the 2gb range from any place in CodeCache you can use it. We have such check for x86: https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/assembler_x86.cpp#L11701 > And you don't need trampoline if you can use `far` call to such `runtime` entry. > > If you need trampoline there is also choice how you call/jump to **it**. Trampoline code is inside CodeCache and `target_needs_far_branch()` works to find type of instruction to reach *trampoline*. That is what I though your changes are doing. Yes, you are right. There is an issue that for runtime calls into `CodeCaceh` both `far_call` and `trampoline_call` can be used. `MacroAssembler::trampoline_call` should be used for runtime calls outside `CodeCache` and Java calls. If a runtime call is into `CodeCache` then `far_call` should be used. ------------- PR: https://git.openjdk.java.net/jdk/pull/8403 From duke at openjdk.java.net Fri Apr 29 14:54:50 2022 From: duke at openjdk.java.net (Evgeny Astigeevich) Date: Fri, 29 Apr 2022 14:54:50 GMT Subject: RFR: 8285487: Do not generate trampolines for runtime calls if they are not needed [v3] In-Reply-To: References: Message-ID: <7x_Q-o1Iwvph6Bk1v-R6BTp8fZM0vViUHuSX9CNtDEY=.1d578888-f0ed-4682-8419-a52fc8ad3991@github.com> On Fri, 29 Apr 2022 12:46:25 GMT, Andrew Haley wrote: > Are you trying to prove that, even if the caller is moved as far as it possibly can be from the runtime target, the branch will still be in range? Yes, for calls into the non-nmethod segment. > That is to say, all of the code in the current CodeHeap is within 128M of the target? With the non-nmethod segment in the middle, it is 248M: 120M + 8M + 120M. ------------- PR: https://git.openjdk.java.net/jdk/pull/8403 From duke at openjdk.java.net Fri Apr 29 15:10:03 2022 From: duke at openjdk.java.net (Evgeny Astigeevich) Date: Fri, 29 Apr 2022 15:10:03 GMT Subject: RFR: 8285487: Do not generate trampolines for runtime calls if they are not needed [v3] In-Reply-To: <6BLRx1h-CQvukYtRVcBNAROhod7j2jRNdQKU-0Cgnc0=.a0d3270e-8a82-4596-a0d0-3c295981d885@github.com> References: <6BLRx1h-CQvukYtRVcBNAROhod7j2jRNdQKU-0Cgnc0=.a0d3270e-8a82-4596-a0d0-3c295981d885@github.com> Message-ID: On Fri, 29 Apr 2022 12:54:15 GMT, Andrew Haley wrote: >> Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: >> >> Move code of target_needs_trampoline inside trampoline_call > > src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 579: > >> 577: // when a new callee address out of 128M range. >> 578: bool need_trampoline = (entry.rspec().type() == relocInfo::runtime_call_type) ? >> 579: target_needs_far_branch(entry.target()) : far_branches(); > > This is all very confusing too. Can't `target_needs_far_branch()` handle all cases? So we don't need a conditional expression here. I'll update `MacroAssembler::trampoline_call` doc when it should be used. All runtime calls into `CodeCache` must use `far_call`. `far_call` is more compact and faster vs `trampoline_call`: far call: adrp add blr trampoline call: bl trampoline trampoline: ldr [embedded] br embedded: 8 bytes of target address What do you think? ------------- PR: https://git.openjdk.java.net/jdk/pull/8403 From iklam at openjdk.java.net Fri Apr 29 16:47:39 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 29 Apr 2022 16:47:39 GMT Subject: RFR: 8284435: Add dedicated filler objects for known dead Java heap areas [v3] In-Reply-To: References: Message-ID: On Mon, 11 Apr 2022 14:55:32 GMT, Thomas Schatzl wrote: >> Hi all, >> >> can I have reviews for this change that adds dedicated filler objects to the VM? >> >> Currently, when formatting areas of dead objects all gcs use instances of j.l.Object and int-arrays. >> >> This has the drawback of not being easily able to discern whether a given object is actually dead (and should never be referenced) or just a regular j.l.Object/int array. >> >> This also makes enhanced error detection (any reference to such an object is an error - i.e. detecting references to such objects) and to skip potentially already unloaded classes when scanning areas of the heap below TAMS, G1 uses its prev bitmap. >> Other collectors do not have this extra information at the moment, so they can't (and don't) do this kind of verification. >> >> With [JDK-8210708](https://bugs.openjdk.java.net/browse/JDK-8210708) the prev bitmap will effectively be removed in G1; G1 will format the dead areas with these filler objects to avoid coming across unloaded classes. This is fine wrt to normal operation, however, this looses the existing enhanced verification mentioned above. >> >> This change proposes to add dedicated VM-internal filler objects, i.e. equivalents of j.l.Object and int-arrays. >> >> This has the following benefits: >> >> - keep this error detection (actually making it much simpler) and allowing similar verification for other collectors. (This change does not add this) >> >> - this also makes it "easy" to detect references to filler objects in debugging tools - you only need to know the two klasses (or just get their friendly name) to see whether that reference may actually be valid (or refers to the inside such an object). References to these classes in the crash file may also allow the issue to be more clear. >> >> This causes some minor changes to external behavior: >> >> - logs/heap dumps now contain instances of these objects - which seems fine as previously they have just been reported as part of j.l.Object/int-arrays statistics. The VM spec also does not guarantee whether a particular kind of object should/should not show there anyway afaik. >> >> - if the application ever gets to instantiate a reference to such an object somehow, any enabled verification will crash the VM. That's bad luck for messing with internal classes, but that's the purpose of these objects. >> >> The change takes care that getting a reference will not be possible by normal means (i.e. via Class.forName() etc) - which should be sufficient to avoid the issue. Actually, existing mechanisms seem to be sufficient. >> >> >> Testing: tier1-8 >> >> There is one question I would like the reviewers to specially think about, the name of the filler array klass. I just used `Ljava/internal/vm/FillerArray;` for that, looking at other internal symbols/klasses, but I'm not sure this adheres to naming guidelines. >> >> Thanks go to @iklam for helping out with the change. >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > Fix test The latest version looks good to me. ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8156 From kvn at openjdk.java.net Fri Apr 29 17:58:47 2022 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 29 Apr 2022 17:58:47 GMT Subject: RFR: 8285802: AArch64: Consistently handle offsets in MacroAssembler as 64-bit quantities [v4] In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 12:38:20 GMT, Andrew Haley wrote: >> In a few places we pass offsets as 32-bit ints rather than 64-bit longs, and we're not consistent about it. We shold have a clean 64-bit path for offset generation and validation. > > Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: > > Windows! These changes introduced regression: https://bugs.openjdk.java.net/browse/JDK-8285923 ------------- PR: https://git.openjdk.java.net/jdk/pull/8448 From mseledtsov at openjdk.java.net Fri Apr 29 18:14:01 2022 From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov) Date: Fri, 29 Apr 2022 18:14:01 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview). >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling _Unimplemented_) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Extent Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e test/hotspot/jtreg/runtime/vthread/StackChunkClassLoaderTest.java line 2: > 1: /* > 2: * Copyright (c) 2021, Oracle and/or its affiliates. All rights reserved. Please update copyright year. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From mseledtsov at openjdk.java.net Fri Apr 29 18:30:26 2022 From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov) Date: Fri, 29 Apr 2022 18:30:26 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: On Fri, 29 Apr 2022 18:23:35 GMT, Mikhailo Seledtsov wrote: >> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: >> >> Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e > > test/jdk/jdk/jfr/api/consumer/TestManyClasses.java line 57: > >> 55: int classLoaderCount = Integer.parseInt(args[0]); >> 56: int classCount = Integer.parseInt(args[1]); >> 57: for (int i = 0; i > Minor: Style: please insert space between < and classCount Also, should this be i < classLoaderCount ?? ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From mseledtsov at openjdk.java.net Fri Apr 29 18:30:25 2022 From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov) Date: Fri, 29 Apr 2022 18:30:25 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview). >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling _Unimplemented_) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Extent Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e test/jdk/jdk/jfr/api/consumer/TestManyClasses.java line 57: > 55: int classLoaderCount = Integer.parseInt(args[0]); > 56: int classCount = Integer.parseInt(args[1]); > 57: for (int i = 0; i 62: theClass.newInstance(); > 63: TestEvent event = new TestEvent(); > 64: event.theClass = event; Did you mean event.theClass = theClass instead ? test/jdk/jdk/jfr/api/consumer/TestManyRecordings.java line 57: > 55: int classLoaderCount = Integer.parseInt(args[0]); > 56: int classCount = Integer.parseInt(args[1]); > 57: for (int i = 0; i Hi All, Patch adds the planned support for new vector operations and APIs targeted for [JEP 426: Vector API (Fourth Incubator).](https://bugs.openjdk.java.net/browse/JDK-8280173) Following is the brief summary of changes:- 1) Extends the scope of existing lanewise API for following new vector operations. - VectorOperations.BIT_COUNT: counts the number of one-bits - VectorOperations.LEADING_ZEROS_COUNT: counts the number of leading zero bits - VectorOperations.TRAILING_ZEROS_COUNT: counts the number of trailing zero bits - VectorOperations.REVERSE: reversing the order of bits - VectorOperations.REVERSE_BYTES: reversing the order of bytes - compress and expand bits: Semantics are based on Hacker's Delight section 7-4 Compress, or Generalized Extract. 2) Adds following new APIs to perform cross lane vector compress and expansion operations under the influence of a mask. - Vector.compress - Vector.expand - VectorMask.compress 3) Adds predicated and non-predicated versions of following new APIs to load and store the contents of vector from foreign MemorySegments. - Vector.fromMemorySegment - Vector.intoMemorySegment 4) C2 Compiler IR enhancements and optimized X86 and AARCH64 backend support for each newly added operation. Patch has been regressed over AARCH64 and X86 targets different AVX levels. Kindly review and share your feedback. Best Regards, Jatin ------------- Commit messages: - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960 - 8284960: AARCH64 backend changes. - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960 - 8284960: Integration of JEP 426: Vector API (Fourth Incubator) Changes: https://git.openjdk.java.net/jdk/pull/8425/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8425&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8284960 Stats: 37837 lines in 214 files changed: 16462 ins; 16923 del; 4452 mod Patch: https://git.openjdk.java.net/jdk/pull/8425.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8425/head:pull/8425 PR: https://git.openjdk.java.net/jdk/pull/8425 From gli at openjdk.java.net Fri Apr 29 18:33:25 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Fri, 29 Apr 2022 18:33:25 GMT Subject: RFR: 8284960: Integration of JEP 426: Vector API (Fourth Incubator) In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 11:03:48 GMT, Jatin Bhateja wrote: > Hi All, > > Patch adds the planned support for new vector operations and APIs targeted for [JEP 426: Vector API (Fourth Incubator).](https://bugs.openjdk.java.net/browse/JDK-8280173) > > Following is the brief summary of changes:- > > 1) Extends the scope of existing lanewise API for following new vector operations. > - VectorOperations.BIT_COUNT: counts the number of one-bits > - VectorOperations.LEADING_ZEROS_COUNT: counts the number of leading zero bits > - VectorOperations.TRAILING_ZEROS_COUNT: counts the number of trailing zero bits > - VectorOperations.REVERSE: reversing the order of bits > - VectorOperations.REVERSE_BYTES: reversing the order of bytes > - compress and expand bits: Semantics are based on Hacker's Delight section 7-4 Compress, or Generalized Extract. > > 2) Adds following new APIs to perform cross lane vector compress and expansion operations under the influence of a mask. > - Vector.compress > - Vector.expand > - VectorMask.compress > > 3) Adds predicated and non-predicated versions of following new APIs to load and store the contents of vector from foreign MemorySegments. > - Vector.fromMemorySegment > - Vector.intoMemorySegment > > 4) C2 Compiler IR enhancements and optimized X86 and AARCH64 backend support for each newly added operation. > > > Patch has been regressed over AARCH64 and X86 targets different AVX levels. > > Kindly review and share your feedback. > > Best Regards, > Jatin Remind: please use the command `/jep JEP-426` [1] to mark this PR. [1] https://wiki.openjdk.java.net/display/SKARA/Pull+Request+Commands#PullRequestCommands-/jep ------------- PR: https://git.openjdk.java.net/jdk/pull/8425 From kvn at openjdk.java.net Fri Apr 29 19:35:47 2022 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 29 Apr 2022 19:35:47 GMT Subject: RFR: 8285487: Do not generate trampolines for runtime calls if they are not needed [v3] In-Reply-To: References: <6BLRx1h-CQvukYtRVcBNAROhod7j2jRNdQKU-0Cgnc0=.a0d3270e-8a82-4596-a0d0-3c295981d885@github.com> Message-ID: On Fri, 29 Apr 2022 15:06:20 GMT, Evgeny Astigeevich wrote: >> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 579: >> >>> 577: // when a new callee address out of 128M range. >>> 578: bool need_trampoline = (entry.rspec().type() == relocInfo::runtime_call_type) ? >>> 579: target_needs_far_branch(entry.target()) : far_branches(); >> >> This is all very confusing too. Can't `target_needs_far_branch()` handle all cases? So we don't need a conditional expression here. > > I'll update `MacroAssembler::trampoline_call` doc when it should be used. All runtime calls into `CodeCache` must use `far_call`. `far_call` is more compact and faster vs `trampoline_call`: > far call: > > adrp > add > blr > > trampoline call: > > bl trampoline > trampoline: > ldr [embedded] > br > embedded: > 8 bytes of target address > > > What do you think? To be clear. `relocInfo::runtime_call_type` is used for stubs calls which are inside CodeCache and for VM runtime calls which are outside CodeCache. Depending on call's distance you can use all 3 types of instruction for all cases - even VM runtime method could be near CodeCache so you can use "near" call. So when you are asking what type of call should be generated you can get all 3 answers. The optimization is that for other calls (inside CodeCache) you need only 2 types of call: far and near. And `MacroAssembler::far_call()` handles it correctly. Back to `trampoline_call()` function. 1. The header comment is incorrect: "If the code cache is small trampolines won't be emitted." 2. New `assert(CodeCache::contains(entry.target())` is wrong. 3. I would like to know why `trampoline_call()` could be used for `relocInfo::virtual_call_type` and `relocInfo::opt_virtual_call_type` (based on assert). They should be inside CodeCache and you don't need trampoline for it. Right? Unless you generate code outside CodeCache. 4. I don't understand how call to trampoline is handled (lines 603-607) they do not reference `stub` value returned by `emit_trampoline_stub()`. Why not use `far_call()` to call trampoline code? 5. `target_needs_far_branch()` works only inside CodeCache. You need separate `target_needs_trampoline()` for `relocInfo::runtime_call_type`. New method should check distance to target vs CodeCache boundaries like we do for x86: https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/assembler_x86.cpp#L11701 I think the code could be like this: if (entry.rspec().type() != relocInfo::runtime_call_type || CodeCache::find_blob(entry.target()) != NULL) { // Call inside CodeCache far_call(entry, cbuf, rscratch1); return pc(); } if (target_needs_trampoline(entry)) { // Check distance from CodeCache // Generate trampoline to call outside CodeCache stub = emit_trampoline_stub(); // Call to trampoline far_call(stub, cbuf, rscratch1); } else { // Far call outside CodeCache. // Near call can't be used because generated code could be posted in any place in CodeCache when installed. adrp add blr } return pc(); ------------- PR: https://git.openjdk.java.net/jdk/pull/8403 From egahlin at openjdk.java.net Fri Apr 29 21:00:27 2022 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Fri, 29 Apr 2022 21:00:27 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: <5w1-RAMPJ1845QC0VJ2YRwifky-U04KUmBp6kQGoOF8=.8486acaa-beda-4706-b394-962f2e8954c0@github.com> On Fri, 29 Apr 2022 18:27:27 GMT, Mikhailo Seledtsov wrote: >> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: >> >> Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e > > test/jdk/jdk/jfr/api/consumer/TestManyRecordings.java line 57: > >> 55: int classLoaderCount = Integer.parseInt(args[0]); >> 56: int classCount = Integer.parseInt(args[1]); >> 57: for (int i = 0; i > Did you mean classLoaderCount here instead of classCount? Also, please make sure there is a space between < and classLoaderCount. The JFR "tests" look strange. I would expect a test called TestManyRecording to start recordings, not created a lot of classes, similar to TestManyClasses. How is this related to Loom? Could this be a merge gone bad? ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From xliu at openjdk.java.net Fri Apr 29 21:15:44 2022 From: xliu at openjdk.java.net (Xin Liu) Date: Fri, 29 Apr 2022 21:15:44 GMT Subject: RFR: 8285487: Do not generate trampolines for runtime calls if they are not needed [v3] In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 21:55:25 GMT, Evgeny Astigeevich wrote: >> [JDK-8280872](https://bugs.openjdk.java.net/browse/JDK-8280872) put the non-nmethod segment between two others. It made trampolines for runtime calls redundant in most cases. >> >> This PR uses `target_needs_far_branch()` for runtime calls to check whether they need trampolines. Trampolines are not generated if they are not needed. >> >> Testing: >> - `tier1`...`tier4`: Passed >> - `compiler/c2/aarch64/TestTrampoline.java`: Passed >> >> Note: `compiler/c2/aarch64/TestTrampoline.java` requires the release build. This is because debug builds have the branch range set to 2M which causes always generation of trampolines. > > Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: > > Move code of target_needs_trampoline inside trampoline_call test/hotspot/jtreg/compiler/c2/aarch64/TestTrampoline.java line 38: > 36: * @library /test/lib > 37: * > 38: * @requires vm.flagless you don't need 4 annotations. you can use logical operators in an expression. ------------- PR: https://git.openjdk.java.net/jdk/pull/8403 From duke at openjdk.java.net Fri Apr 29 21:24:46 2022 From: duke at openjdk.java.net (Evgeny Astigeevich) Date: Fri, 29 Apr 2022 21:24:46 GMT Subject: RFR: 8285487: Do not generate trampolines for runtime calls if they are not needed [v3] In-Reply-To: References: <6BLRx1h-CQvukYtRVcBNAROhod7j2jRNdQKU-0Cgnc0=.a0d3270e-8a82-4596-a0d0-3c295981d885@github.com> Message-ID: <-EEsFIwVzotOBaC9DJV9fVlXf1NBjhm51KJYeY1WDFY=.4563f592-c641-4025-986b-9c6e356100fc@github.com> On Fri, 29 Apr 2022 19:32:36 GMT, Vladimir Kozlov wrote: >> I'll update `MacroAssembler::trampoline_call` doc when it should be used. All runtime calls into `CodeCache` must use `far_call`. `far_call` is more compact and faster vs `trampoline_call`: >> far call: >> >> adrp >> add >> blr >> >> trampoline call: >> >> bl trampoline >> trampoline: >> ldr [embedded] >> br >> embedded: >> 8 bytes of target address >> >> >> What do you think? > > To be clear. `relocInfo::runtime_call_type` is used for stubs calls which are inside CodeCache and for VM runtime calls which are outside CodeCache. Depending on call's distance you can use all 3 types of instruction for all cases - even VM runtime method could be near CodeCache so you can use "near" call. So when you are asking what type of call should be generated you can get all 3 answers. > > The optimization is that for other calls (inside CodeCache) you need only 2 types of call: far and near. And `MacroAssembler::far_call()` handles it correctly. > > Back to `trampoline_call()` function. > 1. The header comment is incorrect: "If the code cache is small trampolines won't be emitted." > 2. New `assert(CodeCache::contains(entry.target())` is wrong. > 3. I would like to know why `trampoline_call()` could be used for `relocInfo::virtual_call_type` and `relocInfo::opt_virtual_call_type` (based on assert). They should be inside CodeCache and you don't need trampoline for it. Right? Unless you generate code outside CodeCache. > 4. I don't understand how call to trampoline is handled (lines 603-607) they do not reference `stub` value returned by `emit_trampoline_stub()`. Why not use `far_call()` to call trampoline code? > 5. `target_needs_far_branch()` works only inside CodeCache. You need separate `target_needs_trampoline()` for `relocInfo::runtime_call_type`. New method should check distance to target vs CodeCache boundaries like we do for x86: https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/assembler_x86.cpp#L11701 > > I think the code could be like this: > > > if (entry.rspec().type() != relocInfo::runtime_call_type || > CodeCache::find_blob(entry.target()) != NULL) { > // Call inside CodeCache > far_call(entry, cbuf, rscratch1); > return pc(); > } > if (target_needs_trampoline(entry)) { // Check distance from CodeCache > // Generate trampoline to call outside CodeCache > stub = emit_trampoline_stub(); > // Call to trampoline > far_call(stub, cbuf, rscratch1); > } else { > // Far call outside CodeCache. > // Near call can't be used because generated code could be posted in any place in CodeCache when installed. > adrp > add > blr > } > return pc(); Hi Vladimir, Thank you for the detailed comment. > The optimization is that for other calls (inside CodeCache) you need only 2 types of call: far and near. And MacroAssembler::far_call() handles it correctly. Yes., I've checked the uses of `trampoline_call`. There are no calls outside CodeCache. They must be replaced with `far_call`. I did this and got a crash of the debug build. Debug builds reduce the branch range from 128M to 2M to be able to test trampolines. Debug builds with the 128M branch range work. With the 2M branch range the debug build fails at: ScopeDesc* CompiledMethod::scope_desc_at(address pc) { PcDesc* pd = pc_desc_at(pc); guarantee(pd != NULL, "scope must be present"); return new ScopeDesc(this, pd); } with the stack: V [libjvm.so+0xa8f138] CompiledMethod::scope_desc_at(unsigned char*)+0x40 V [libjvm.so+0x1567290] compiledVFrame::compiledVFrame(frame const*, RegisterMap const*, JavaThread*, CompiledMethod*)+0xc8 V [libjvm.so+0x155f1f0] vframe::new_vframe(frame const*, RegisterMap const*, JavaThread*)+0xd8 V [libjvm.so+0xaeb574] Deoptimization::uncommon_trap_inner(JavaThread*, int)+0x1b4 V [libjvm.so+0xaeca44] Deoptimization::uncommon_trap(JavaThread*, int, int)+0x24 > I would like to know why trampoline_call() could be used for relocInfo::virtual_call_type and relocInfo::opt_virtual_call_type (based on assert). They should be inside CodeCache and you don't need trampoline for it. Right? If CodeCashe is bigger than 128M, we need a trampoline for them. We generate: bl trampoline trampoline: Initially, we have a call of `resolve_virtual_call_stub`. If the stub finds a compiled method, it patches: - `bl` if the found method is near. - `trampoline` if the found method is far. For the 240M CodeCache, we patch `trampoline` when a C2 compiled method calls a C1 compiled method or vice verse. When a C2 compiled method calls a C2 compiled method or a C1 compiled method calls a C1 compiled method, we have a normal direct call. If we used a `far_call` there, we would always have an indirect call because a call site would be: adrp add blr So the use of `trampoline_call` here is an optimization. >I don't understand how call to trampoline is handled (lines 603-607) they do not reference stub value returned by emit_trampoline_stub(). Why not use far_call() to call trampoline code? And they should not. Here it is `CodeBuffer`, calls are not linked yet. Trampoline code is put into the stub code section of `CodeBuffer`. We insert a self-calling instruction. When we move the generated code into `CodeCache` we link the calls by patching them based on `relocInfo` records. I think during linking we try to bypass trampolines if possible. ------------- PR: https://git.openjdk.java.net/jdk/pull/8403 From psandoz at openjdk.java.net Fri Apr 29 21:37:44 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Fri, 29 Apr 2022 21:37:44 GMT Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE with predicate feature [v2] In-Reply-To: References: Message-ID: On Fri, 22 Apr 2022 07:08:24 GMT, Xiaohong Gong wrote: >> Currently the vector load with mask when the given index happens out of the array boundary is implemented with pure java scalar code to avoid the IOOBE (IndexOutOfBoundaryException). This is necessary for architectures that do not support the predicate feature. Because the masked load is implemented with a full vector load and a vector blend applied on it. And a full vector load will definitely cause the IOOBE which is not valid. However, for architectures that support the predicate feature like SVE/AVX-512/RVV, it can be vectorized with the predicated load instruction as long as the indexes of the masked lanes are within the bounds of the array. For these architectures, loading with unmasked lanes does not raise exception. >> >> This patch adds the vectorization support for the masked load with IOOBE part. Please see the original java implementation (FIXME: optimize): >> >> >> @ForceInline >> public static >> ByteVector fromArray(VectorSpecies species, >> byte[] a, int offset, >> VectorMask m) { >> ByteSpecies vsp = (ByteSpecies) species; >> if (offset >= 0 && offset <= (a.length - species.length())) { >> return vsp.dummyVector().fromArray0(a, offset, m); >> } >> >> // FIXME: optimize >> checkMaskFromIndexSize(offset, vsp, m, 1, a.length); >> return vsp.vOp(m, i -> a[offset + i]); >> } >> >> Since it can only be vectorized with the predicate load, the hotspot must check whether the current backend supports it and falls back to the java scalar version if not. This is different from the normal masked vector load that the compiler will generate a full vector load and a vector blend if the predicate load is not supported. So to let the compiler make the expected action, an additional flag (i.e. `usePred`) is added to the existing "loadMasked" intrinsic, with the value "true" for the IOOBE part while "false" for the normal load. And the compiler will fail to intrinsify if the flag is "true" and the predicate load is not supported by the backend, which means that normal java path will be executed. >> >> Also adds the same vectorization support for masked: >> - fromByteArray/fromByteBuffer >> - fromBooleanArray >> - fromCharArray >> >> The performance for the new added benchmarks improve about `1.88x ~ 30.26x` on the x86 AVX-512 system: >> >> Benchmark before After Units >> LoadMaskedIOOBEBenchmark.byteLoadArrayMaskIOOBE 737.542 1387.069 ops/ms >> LoadMaskedIOOBEBenchmark.doubleLoadArrayMaskIOOBE 118.366 330.776 ops/ms >> LoadMaskedIOOBEBenchmark.floatLoadArrayMaskIOOBE 233.832 6125.026 ops/ms >> LoadMaskedIOOBEBenchmark.intLoadArrayMaskIOOBE 233.816 7075.923 ops/ms >> LoadMaskedIOOBEBenchmark.longLoadArrayMaskIOOBE 119.771 330.587 ops/ms >> LoadMaskedIOOBEBenchmark.shortLoadArrayMaskIOOBE 431.961 939.301 ops/ms >> >> Similar performance gain can also be observed on 512-bit SVE system. > > Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision: > > Rename the "usePred" to "offsetInRange" IIUC when the hardware does not support predicated loads then any false `offsetIntRange` value causes the load intrinsic to fail resulting in the fallback, so it would not be materially any different to the current behavior, just more uniformly implemented. Why can't the intrinsic support the passing a boolean directly? Is it something to do with constants? If that is not possible I recommend creating named constant values and pass those all the way through rather than converting a boolean to an integer value. Then there is no need for a branch checking `offsetInRange`. Might be better to hold off until the JEP is integrated and then update, since this will conflict (`byte[]` and `ByteBuffer` load methods are removed and `MemorySegment` load methods are added). You could prepare for that now by branching off `vectorIntrinsics`. ------------- PR: https://git.openjdk.java.net/jdk/pull/8035 From duke at openjdk.java.net Fri Apr 29 21:48:46 2022 From: duke at openjdk.java.net (Evgeny Astigeevich) Date: Fri, 29 Apr 2022 21:48:46 GMT Subject: RFR: 8285487: Do not generate trampolines for runtime calls if they are not needed [v3] In-Reply-To: <-EEsFIwVzotOBaC9DJV9fVlXf1NBjhm51KJYeY1WDFY=.4563f592-c641-4025-986b-9c6e356100fc@github.com> References: <6BLRx1h-CQvukYtRVcBNAROhod7j2jRNdQKU-0Cgnc0=.a0d3270e-8a82-4596-a0d0-3c295981d885@github.com> <-EEsFIwVzotOBaC9DJV9fVlXf1NBjhm51KJYeY1WDFY=.4563f592-c641-4025-986b-9c6e356100fc@github.com> Message-ID: On Fri, 29 Apr 2022 21:21:28 GMT, Evgeny Astigeevich wrote: >> To be clear. `relocInfo::runtime_call_type` is used for stubs calls which are inside CodeCache and for VM runtime calls which are outside CodeCache. Depending on call's distance you can use all 3 types of instruction for all cases - even VM runtime method could be near CodeCache so you can use "near" call. So when you are asking what type of call should be generated you can get all 3 answers. >> >> The optimization is that for other calls (inside CodeCache) you need only 2 types of call: far and near. And `MacroAssembler::far_call()` handles it correctly. >> >> Back to `trampoline_call()` function. >> 1. The header comment is incorrect: "If the code cache is small trampolines won't be emitted." >> 2. New `assert(CodeCache::contains(entry.target())` is wrong. >> 3. I would like to know why `trampoline_call()` could be used for `relocInfo::virtual_call_type` and `relocInfo::opt_virtual_call_type` (based on assert). They should be inside CodeCache and you don't need trampoline for it. Right? Unless you generate code outside CodeCache. >> 4. I don't understand how call to trampoline is handled (lines 603-607) they do not reference `stub` value returned by `emit_trampoline_stub()`. Why not use `far_call()` to call trampoline code? >> 5. `target_needs_far_branch()` works only inside CodeCache. You need separate `target_needs_trampoline()` for `relocInfo::runtime_call_type`. New method should check distance to target vs CodeCache boundaries like we do for x86: https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/assembler_x86.cpp#L11701 >> >> I think the code could be like this: >> >> >> if (entry.rspec().type() != relocInfo::runtime_call_type || >> CodeCache::find_blob(entry.target()) != NULL) { >> // Call inside CodeCache >> far_call(entry, cbuf, rscratch1); >> return pc(); >> } >> if (target_needs_trampoline(entry)) { // Check distance from CodeCache >> // Generate trampoline to call outside CodeCache >> stub = emit_trampoline_stub(); >> // Call to trampoline >> far_call(stub, cbuf, rscratch1); >> } else { >> // Far call outside CodeCache. >> // Near call can't be used because generated code could be posted in any place in CodeCache when installed. >> adrp >> add >> blr >> } >> return pc(); > > Hi Vladimir, > Thank you for the detailed comment. > >> The optimization is that for other calls (inside CodeCache) you need only 2 types of call: far and near. And MacroAssembler::far_call() handles it correctly. > > Yes., I've checked the uses of `trampoline_call`. There are no calls outside CodeCache. They must be replaced with `far_call`. I did this and got a crash of the debug build. Debug builds reduce the branch range from 128M to 2M to be able to test trampolines. Debug builds with the 128M branch range work. With the 2M branch range the debug build fails at: > > ScopeDesc* CompiledMethod::scope_desc_at(address pc) { > PcDesc* pd = pc_desc_at(pc); > guarantee(pd != NULL, "scope must be present"); > return new ScopeDesc(this, pd); > } > > with the stack: > > V [libjvm.so+0xa8f138] CompiledMethod::scope_desc_at(unsigned char*)+0x40 > V [libjvm.so+0x1567290] compiledVFrame::compiledVFrame(frame const*, RegisterMap const*, JavaThread*, CompiledMethod*)+0xc8 > V [libjvm.so+0x155f1f0] vframe::new_vframe(frame const*, RegisterMap const*, JavaThread*)+0xd8 > V [libjvm.so+0xaeb574] Deoptimization::uncommon_trap_inner(JavaThread*, int)+0x1b4 > V [libjvm.so+0xaeca44] Deoptimization::uncommon_trap(JavaThread*, int, int)+0x24 > > >> I would like to know why trampoline_call() could be used for relocInfo::virtual_call_type and relocInfo::opt_virtual_call_type (based on assert). They should be inside CodeCache and you don't need trampoline for it. Right? > > If CodeCashe is bigger than 128M, we need a trampoline for them. > We generate: > > bl trampoline > trampoline: > > Initially, we have a call of `resolve_virtual_call_stub`. If the stub finds a compiled method, it patches: > - `bl` if the found method is near. > - `trampoline` if the found method is far. > For the 240M CodeCache, we patch `trampoline` when a C2 compiled method calls a C1 compiled method or vice verse. When a C2 compiled method calls a C2 compiled method or a C1 compiled method calls a C1 compiled method, we have a normal direct call. > If we used a `far_call` there, we would always have an indirect call because a call site would be: > > adrp > add > blr > > So the use of `trampoline_call` here is an optimization. > >>I don't understand how call to trampoline is handled (lines 603-607) they do not reference stub value returned by emit_trampoline_stub(). Why not use far_call() to call trampoline code? > > And they should not. Here it is `CodeBuffer`, calls are not linked yet. Trampoline code is put into the stub code section of `CodeBuffer`. We insert a self-calling instruction. When we move the generated code into `CodeCache` we link the calls by patching them based on `relocInfo` records. I think during linking we try to bypass trampolines if possible. Yes, we try to bypass trampolines during moving code into `CodeCache`: void Relocation::pd_set_call_destination(address x) { assert(is_call(), "should be a call here"); if (NativeCall::is_call_at(addr())) { address trampoline = nativeCall_at(addr())->get_trampoline(); if (trampoline) { nativeCall_at(addr())->set_destination_mt_safe(x, /* assert_lock */false); return; } } MacroAssembler::pd_patch_instruction(addr(), x); assert(pd_call_destination(addr()) == x, "fail in reloc"); } void NativeCall::set_destination_mt_safe(address dest, bool assert_lock) { .... ResourceMark rm; int code_size = NativeInstruction::instruction_size; address addr_call = addr_at(0); bool reachable = Assembler::reachable_from_branch_at(addr_call, dest); ... // Patch the constant in the call's trampoline stub. address trampoline_stub_addr = get_trampoline(); ... // Patch the call. if (reachable) { set_destination(dest); } else { assert (trampoline_stub_addr != NULL, "we need a trampoline"); set_destination(trampoline_stub_addr); } ... } ------------- PR: https://git.openjdk.java.net/jdk/pull/8403 From kvn at openjdk.java.net Fri Apr 29 22:40:32 2022 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 29 Apr 2022 22:40:32 GMT Subject: RFR: 8285487: Do not generate trampolines for runtime calls if they are not needed [v3] In-Reply-To: References: <6BLRx1h-CQvukYtRVcBNAROhod7j2jRNdQKU-0Cgnc0=.a0d3270e-8a82-4596-a0d0-3c295981d885@github.com> <-EEsFIwVzotOBaC9DJV9fVlXf1NBjhm51KJYeY1WDFY=.4563f592-c641-4025-986b-9c6e356100fc@github.com> Message-ID: On Fri, 29 Apr 2022 21:45:24 GMT, Evgeny Astigeevich wrote: >> Hi Vladimir, >> Thank you for the detailed comment. >> >>> The optimization is that for other calls (inside CodeCache) you need only 2 types of call: far and near. And MacroAssembler::far_call() handles it correctly. >> >> Yes., I've checked the uses of `trampoline_call`. There are no calls outside CodeCache. They must be replaced with `far_call`. I did this and got a crash of the debug build. Debug builds reduce the branch range from 128M to 2M to be able to test trampolines. Debug builds with the 128M branch range work. With the 2M branch range the debug build fails at: >> >> ScopeDesc* CompiledMethod::scope_desc_at(address pc) { >> PcDesc* pd = pc_desc_at(pc); >> guarantee(pd != NULL, "scope must be present"); >> return new ScopeDesc(this, pd); >> } >> >> with the stack: >> >> V [libjvm.so+0xa8f138] CompiledMethod::scope_desc_at(unsigned char*)+0x40 >> V [libjvm.so+0x1567290] compiledVFrame::compiledVFrame(frame const*, RegisterMap const*, JavaThread*, CompiledMethod*)+0xc8 >> V [libjvm.so+0x155f1f0] vframe::new_vframe(frame const*, RegisterMap const*, JavaThread*)+0xd8 >> V [libjvm.so+0xaeb574] Deoptimization::uncommon_trap_inner(JavaThread*, int)+0x1b4 >> V [libjvm.so+0xaeca44] Deoptimization::uncommon_trap(JavaThread*, int, int)+0x24 >> >> >>> I would like to know why trampoline_call() could be used for relocInfo::virtual_call_type and relocInfo::opt_virtual_call_type (based on assert). They should be inside CodeCache and you don't need trampoline for it. Right? >> >> If CodeCashe is bigger than 128M, we need a trampoline for them. >> We generate: >> >> bl trampoline >> trampoline: >> >> Initially, we have a call of `resolve_virtual_call_stub`. If the stub finds a compiled method, it patches: >> - `bl` if the found method is near. >> - `trampoline` if the found method is far. >> For the 240M CodeCache, we patch `trampoline` when a C2 compiled method calls a C1 compiled method or vice verse. When a C2 compiled method calls a C2 compiled method or a C1 compiled method calls a C1 compiled method, we have a normal direct call. >> If we used a `far_call` there, we would always have an indirect call because a call site would be: >> >> adrp >> add >> blr >> >> So the use of `trampoline_call` here is an optimization. >> >>>I don't understand how call to trampoline is handled (lines 603-607) they do not reference stub value returned by emit_trampoline_stub(). Why not use far_call() to call trampoline code? >> >> And they should not. Here it is `CodeBuffer`, calls are not linked yet. Trampoline code is put into the stub code section of `CodeBuffer`. We insert a self-calling instruction. When we move the generated code into `CodeCache` we link the calls by patching them based on `relocInfo` records. I think during linking we try to bypass trampolines if possible. > > Yes, we try to bypass trampolines during moving code into `CodeCache`: > > void Relocation::pd_set_call_destination(address x) { > assert(is_call(), "should be a call here"); > if (NativeCall::is_call_at(addr())) { > address trampoline = nativeCall_at(addr())->get_trampoline(); > if (trampoline) { > nativeCall_at(addr())->set_destination_mt_safe(x, /* assert_lock */false); > return; > } > } > MacroAssembler::pd_patch_instruction(addr(), x); > assert(pd_call_destination(addr()) == x, "fail in reloc"); > } > > void NativeCall::set_destination_mt_safe(address dest, bool assert_lock) { > .... > ResourceMark rm; > int code_size = NativeInstruction::instruction_size; > address addr_call = addr_at(0); > bool reachable = Assembler::reachable_from_branch_at(addr_call, dest); > ... > // Patch the constant in the call's trampoline stub. > address trampoline_stub_addr = get_trampoline(); > ... > // Patch the call. > if (reachable) { > set_destination(dest); > } else { > assert (trampoline_stub_addr != NULL, "we need a trampoline"); > set_destination(trampoline_stub_addr); > } > ... > } So my assumption that `trampoline_call()` could be used for call outside CodeCache is wrong (and the method's comment is correct). I looked on few places where runtime call is generated and `trampoline_call()` indeed is used only for CodeCache (at least in places are looked on): https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/aarch64/aarch64.ad#L3858 My points 1. and 2. are void. Thank you for answering my questions 3. and 4. That also explains your `need_trampoline` code change. You answered all my questions. Please, do latest merge and updates if needed so I can review final changes. ------------- PR: https://git.openjdk.java.net/jdk/pull/8403 From mseledtsov at openjdk.java.net Fri Apr 29 23:21:12 2022 From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov) Date: Fri, 29 Apr 2022 23:21:12 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview). >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling _Unimplemented_) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Extent Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e test/lib/jdk/test/lib/thread/VThreadRunner.java line 61: > 59: /** > 60: * Run a task in a virtual thread and wait for it to terminate. > 61: * If the task completse with an exception then it is thrown by this method. typo: completse --> completes test/lib/jdk/test/lib/thread/VThreadRunner.java line 121: > 119: /** > 120: * Run a task in a virtual thread and wait for it to terminate. > 121: * If the task completse with an exception then it is thrown by this method. completse --> completes ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From mseledtsov at openjdk.java.net Fri Apr 29 23:57:02 2022 From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov) Date: Fri, 29 Apr 2022 23:57:02 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview). >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling _Unimplemented_) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Extent Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e I have reviewed the following portions of this change: test/common, test/gtest, test/hotspot/runtime, test/jdk/jfr, test library Feedback: - see several minor comments inline - under runtime/cds/appcds/test-classes there is an empty "TEST.properties" file; was it added by mistake? With only a few minor comments, I approve of the code reviewed by me provided that my comments will be addressed. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From dholmes at openjdk.java.net Sat Apr 30 10:39:31 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Sat, 30 Apr 2022 10:39:31 GMT Subject: RFR: 8282477: [x86, aarch64] vmassert(_last_Java_pc == NULL, "already walkable"); fails with async profiler [v4] In-Reply-To: References: Message-ID: On Fri, 29 Apr 2022 11:14:38 GMT, Johannes Bechberger wrote: >> Fix the assertion by replacing it by assertion that does not fail. > > Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: > > Remove Thread from make_walkable signature This seems fine to me now. Perhaps we can get @dean-long to review this as he added this code back in 2016. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8209 From dholmes at openjdk.java.net Sat Apr 30 10:57:32 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Sat, 30 Apr 2022 10:57:32 GMT Subject: RFR: 8285794: AsyncGetCallTrace might acquire a lock via JavaThread::thread_from_jni_environment [v2] In-Reply-To: References: Message-ID: On Fri, 29 Apr 2022 10:38:42 GMT, Johannes Bechberger wrote: >> src/hotspot/share/prims/forte.cpp line 571: >> >>> 569: Thread* raw_thread = Thread::current_or_null_safe(); >>> 570: >>> 571: if (trace->env_id == NULL || raw_thread == NULL || !raw_thread->is_Java_thread() || ((JavaThread*)raw_thread)->is_exiting()) { >> >> use `rawThread->as_JavaThread()` not a plain cast. > > this method does not exist Sorry I meant: `JavaThread::cast(rawThread)` ------------- PR: https://git.openjdk.java.net/jdk/pull/8446 From duke at openjdk.java.net Sat Apr 30 14:11:41 2022 From: duke at openjdk.java.net (ExE Boss) Date: Sat, 30 Apr 2022 14:11:41 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v35] In-Reply-To: References: Message-ID: On Fri, 29 Apr 2022 08:15:32 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.java.net/jeps/424 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Tweak Addressable javadoc src/java.base/share/classes/jdk/internal/misc/X-ScopedMemoryAccess.java.template line 101: > 99: } > 100: > 101: public final static class ScopedAccessError extends Error { This?should probably?use the?canonical modifier?order as?specified in?[JDK?8276348] ([GH?6213]): Suggestion: public static final class ScopedAccessError extends Error { [JDK?8276348]: https://bugs.openjdk.java.net/browse/JDK-8276348 "[JDK?8276348] Use?blessed modifier?order in?java.base" [GH?6213]: https://github.com/openjdk/jdk/pull/6213 ------------- PR: https://git.openjdk.java.net/jdk/pull/7888