From github.com+10233373+jhe33 at openjdk.java.net Wed May 6 09:47:29 2020 From: github.com+10233373+jhe33 at openjdk.java.net (Jie He) Date: Wed, 6 May 2020 09:47:29 GMT Subject: RFR: Avoid jtreg test timeout in aarch64 due to a stackoverflow in process reaper Message-ID: <8cMNnH73ROsMxJ4Ygth5Biw-qWHBPU9cgH2PTNe49TU=.27b7c5e6-6c8d-4b84-a2d8-1b9e96541bc9@github.com> Process reaper has a small size stack by default, 128K. With tsan enabled, it often causes SOE failure when running jtreg tests. Set -Djdk.lang.processReaperUseDefaultStackSize=true, to let jtreg test use default JVM stack size (global variable ThreadStackSize) in aarch64, which could be configured by -Xss. I took an investigation about the stackoverflow, [1]. and found the different GLIBC behaviors between x86 and aarch64 stack allocation due to default stack size in openjdk. x86 will get the stack from glibc cached stack because it matches the threshold to allocate a stack from cached stack, but aarch64 not. [1] https://groups.google.com/forum/#!topic/thread-sanitizer/RsPcxUXBokg ------------- Commit messages: - Process reaper uses default JVM stack size in aarch64 Changes: https://git.openjdk.java.net/tsan/pull/8/files Webrev: https://webrevs.openjdk.java.net/tsan/8/webrev.00 Stats: 9 lines in 1 file changed: 9 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/tsan/pull/8.diff Fetch: git fetch https://git.openjdk.java.net/tsan pull/8/head:pull/8 PR: https://git.openjdk.java.net/tsan/pull/8 From Jie.He at arm.com Thu May 7 05:25:19 2020 From: Jie.He at arm.com (Jie He) Date: Thu, 7 May 2020 05:25:19 +0000 Subject: current code location encoding doesn't work in aarch64 Message-ID: Hi We know jdk/tsan uses a 64-bit value to identify code location, lowest 16-bit for bci, the next 44-bit for method id. In aarch64 current tsan memory mapping, method id allocated from heap is typically like 0xffffxxxxxxxx, which Couldn't be encoded by 47-bit directly. However, there are only 3 application memory regions, they are static const uptr kLoAppMemBeg = 0x0000000001000ull; static const uptr kLoAppMemEnd = 0x0000200000000ull; static const uptr kMidAppMemBeg = 0x0aaaa00000000ull; static const uptr kMidAppMemEnd = 0x0aaaf00000000ull; static const uptr kHiAppMemBeg = 0x0ffff00000000ull; static const uptr kHiAppMemEnd = 0x1000000000000ull; I think in aarch64, we don't need 47-bit to encode the method id, because highest 12 bits are fixed, and could be encoded by at most 2 bits. e.g. 00 means LoAppMemRange, 01 means MidRange, 10 means HighRange. Or simpler, just check the value of the highest 4 bits, 0x0 means LoRange, 0x2 means MidRange, 0x7 means HighRange. Like below 307 static jmethodID tsan_method_id_from_code_location(u8 loc) { 308 u8 id = (u8)( 309 (loc & ~(tsan_fake_pc_bit | tsan_bci_mask)) >> tsan_method_id_shift); 310 311 #ifdef AARCH64 312 u8 ms4bits = id >> 44; 313 if (ms4bits == 0x7ULL || ms4bits == 0x2ULL ) 314 id = id | 0x800000000000ULL; 315 #endif 316 317 return (jmethodID)id; 318 } What do you think? Thanks Jie He From github.com+10233373+jhe33 at openjdk.java.net Thu May 7 11:22:18 2020 From: github.com+10233373+jhe33 at openjdk.java.net (Jie He) Date: Thu, 7 May 2020 11:22:18 GMT Subject: RFR: Add aarch64 specific lock/unlock tsan instruments Message-ID: Add aarch64 specific lock/unlock instruments into interpreter and runtime. Update an assertion in aarch64 due to different memory layout. With tsan enabled, too small java stack often causes SOE, especially thread "process reaper". Therefore, for running jtreg test in aarch64, we have to set jdk.lang.processReaperUseDefaultStackSize as true. ------------- Commit messages: - Add aarch64 specific lock/unlock tsan instruments Changes: https://git.openjdk.java.net/tsan/pull/9/files Webrev: https://webrevs.openjdk.java.net/tsan/9/webrev.00 Stats: 38 lines in 3 files changed: 37 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/tsan/pull/9.diff Fetch: git fetch https://git.openjdk.java.net/tsan pull/9/head:pull/9 PR: https://git.openjdk.java.net/tsan/pull/9 From aeubanks at openjdk.java.net Thu May 7 16:26:31 2020 From: aeubanks at openjdk.java.net (Arthur Eubanks) Date: Thu, 7 May 2020 16:26:31 GMT Subject: RFR: Avoid jtreg test timeout in aarch64 due to a stackoverflow in process reaper In-Reply-To: <8cMNnH73ROsMxJ4Ygth5Biw-qWHBPU9cgH2PTNe49TU=.27b7c5e6-6c8d-4b84-a2d8-1b9e96541bc9@github.com> References: <8cMNnH73ROsMxJ4Ygth5Biw-qWHBPU9cgH2PTNe49TU=.27b7c5e6-6c8d-4b84-a2d8-1b9e96541bc9@github.com> Message-ID: On Wed, 6 May 2020 09:41:59 GMT, Jie He wrote: > Process reaper has a small size stack by default, 128K. With tsan > enabled, it often causes SOE failure when running jtreg tests. Set > -Djdk.lang.processReaperUseDefaultStackSize=true, to let jtreg test > use default JVM stack size (global variable ThreadStackSize) in > aarch64, which could be configured by -Xss. > > I took an investigation about the stackoverflow, [1]. > and found the different GLIBC behaviors between x86 and aarch64 stack > allocation due to default stack size in openjdk. x86 will get the stack from > glibc cached stack because it matches the threshold to allocate a stack from > cached stack, but aarch64 not. > > [1] https://groups.google.com/forum/#!topic/thread-sanitizer/RsPcxUXBokg I read through https://groups.google.com/forum/#!topic/thread-sanitizer/RsPcxUXBokg (nice investigation btw!) but don't quite understand > and found the different GLIBC behaviors between x86 and aarch64 stack > allocation due to default stack size in openjdk. x86 will get the stack from > glibc cached stack because it matches the threshold to allocate a stack from > cached stack, but aarch64 not. Do you mean that on x86 the stack size of the thread is larger than requested because glibc happened to have something larger lying around to use? So we are currently getting lucky in x86 with stack sizes? ------------- PR: https://git.openjdk.java.net/tsan/pull/8 From aeubanks at openjdk.java.net Thu May 7 16:33:26 2020 From: aeubanks at openjdk.java.net (Arthur Eubanks) Date: Thu, 7 May 2020 16:33:26 GMT Subject: RFR: Add aarch64 specific lock/unlock tsan instruments In-Reply-To: References: Message-ID: On Thu, 7 May 2020 11:14:26 GMT, Jie He wrote: > Add aarch64 specific lock/unlock instruments into interpreter and > runtime. > > Update an assertion in aarch64 due to different memory layout. > > With tsan enabled, too small java stack often causes SOE, especially > thread "process reaper". Therefore, for running jtreg test in aarch64, > we have to set jdk.lang.processReaperUseDefaultStackSize as true. What do you think about making the `16` based on the arch? `assert((id_u8 & left_n_bits(16)) == 0, "jmethodID is not aligned");` ------------- PR: https://git.openjdk.java.net/tsan/pull/9 From aeubanks at google.com Thu May 7 17:37:50 2020 From: aeubanks at google.com (Arthur Eubanks) Date: Thu, 7 May 2020 10:37:50 -0700 Subject: current code location encoding doesn't work in aarch64 In-Reply-To: References: Message-ID: On Wed, May 6, 2020 at 10:41 PM Jie He wrote: > Hi > > We know jdk/tsan uses a 64-bit value to identify code location, lowest > 16-bit for bci, the next 44-bit for method id. > > In aarch64 current tsan memory mapping, method id allocated from heap is > typically like 0xffffxxxxxxxx, which > Couldn't be encoded by 47-bit directly. I don't understand, doesn't 0xffffxxxxxxxx only require 32 bits to represent? > However, there are only 3 application memory regions, they are > > static const uptr kLoAppMemBeg = 0x0000000001000ull; > static const uptr kLoAppMemEnd = 0x0000200000000ull; > static const uptr kMidAppMemBeg = 0x0aaaa00000000ull; > static const uptr kMidAppMemEnd = 0x0aaaf00000000ull; > static const uptr kHiAppMemBeg = 0x0ffff00000000ull; > static const uptr kHiAppMemEnd = 0x1000000000000ull; > > I think in aarch64, we don't need 47-bit to encode the method id, because > highest 12 bits are fixed, and could be encoded by at most 2 bits. > e.g. 00 means LoAppMemRange, 01 means MidRange, 10 means HighRange. > Or simpler, just check the value of the highest 4 bits, 0x0 means LoRange, > 0x2 means MidRange, 0x7 means HighRange. > You don't even need the high 2 bits right? Chopping them off and using the 3rd and 4th highest bits, you can use 00 for low, 10 for mid, and 11 for high. But I suppose it doesn't really matter as long as we can fit things in. > Like below > > 307 static jmethodID tsan_method_id_from_code_location(u8 loc) { > 308 u8 id = (u8)( > 309 (loc & ~(tsan_fake_pc_bit | tsan_bci_mask)) >> > tsan_method_id_shift); > 310 > 311 #ifdef AARCH64 > 312 u8 ms4bits = id >> 44; > 313 if (ms4bits == 0x7ULL || ms4bits == 0x2ULL ) > 314 id = id | 0x800000000000ULL; > Doesn't this end up mixing high and mid? > 315 #endif > 316 > 317 return (jmethodID)id; > 318 } > > What do you think? > > Thanks > Jie He > > > > > From github.com+10233373+jhe33 at openjdk.java.net Fri May 8 02:43:19 2020 From: github.com+10233373+jhe33 at openjdk.java.net (Jie He) Date: Fri, 8 May 2020 02:43:19 GMT Subject: RFR: Avoid jtreg test timeout in aarch64 due to a stackoverflow in process reaper In-Reply-To: References: <8cMNnH73ROsMxJ4Ygth5Biw-qWHBPU9cgH2PTNe49TU=.27b7c5e6-6c8d-4b84-a2d8-1b9e96541bc9@github.com> Message-ID: On Thu, 7 May 2020 16:24:11 GMT, Arthur Eubanks wrote: > I read through https://groups.google.com/forum/#!topic/thread-sanitizer/RsPcxUXBokg (nice investigation btw!) but don't > quite understand > > and found the different GLIBC behaviors between x86 and aarch64 stack > > allocation due to default stack size in openjdk. x86 will get the stack from > > glibc cached stack because it matches the threshold to allocate a stack from > > cached stack, but aarch64 not. > > Do you mean that on x86 the stack size of the thread is larger than requested because glibc happened to have something > larger lying around to use? So we are currently getting lucky in x86 with stack sizes? yes, but not exactly. x86 gets the stack from cached stack is another story. Initially, when started to investigate the SOE failure, I noticed the different behaviors between x86 and aarch64. TSAN increases the stack size to 384K, but x86 always could get a 1M stack, meanwhile, aarch64 couldn't. I thought it might be the reason why no SOE on x86. In fact, it's not the root cause as you already know. even though x86 gets 384K stack by bypassing the glibc allocation, it won't incur SOE in this case. However I have to take time to investigate the glibc. By default, stack size of x86 is 1M in openjdk, and aarch64 is 2M. I assume aarch64 will take more stack consumption than x86 in most cases. sometimes glibc allocates the stack from cached stacks, it depends on if the requested stack size is larger than 1/4 cached stack. here, 384K > 1/4 * 1M on x86, but not > 1/4 * 2M on aarch64. anyway, I think the issue in TSAN also will impact the effective usable stack on x86, it could make easier to SOE even though it doesn't happen in this case. ------------- PR: https://git.openjdk.java.net/tsan/pull/8 From Jie.He at arm.com Fri May 8 03:09:33 2020 From: Jie.He at arm.com (Jie He) Date: Fri, 8 May 2020 03:09:33 +0000 Subject: current code location encoding doesn't work in aarch64 In-Reply-To: References: Message-ID: On Fri, May 8, 2020 at 01:40 AM Arthur Eubanks wrote? On Wed, May 6, 2020 at 10:41 PM Jie He > wrote: > Hi > > We know jdk/tsan uses a 64-bit value to identify code location, lowest > 16-bit for bci, the next 44-bit for method id. > > In aarch64 current tsan memory mapping, method id allocated from heap is > typically like 0xffffxxxxxxxx, which > Couldn't be encoded by 47-bit directly. I don't understand, doesn't 0xffffxxxxxxxx only require 32 bits to represent? Yes, but I?m not sure if it?s possible that the heap will be allocated in Low or Mid memory ranges. and X86 just puts the method id directly into the code location packet, I won't change this code. > However, there are only 3 application memory regions, they are > > static const uptr kLoAppMemBeg = 0x0000000001000ull; > static const uptr kLoAppMemEnd = 0x0000200000000ull; > static const uptr kMidAppMemBeg = 0x0aaaa00000000ull; > static const uptr kMidAppMemEnd = 0x0aaaf00000000ull; > static const uptr kHiAppMemBeg = 0x0ffff00000000ull; > static const uptr kHiAppMemEnd = 0x1000000000000ull; > > I think in aarch64, we don't need 47-bit to encode the method id, because > highest 12 bits are fixed, and could be encoded by at most 2 bits. > e.g. 00 means LoAppMemRange, 01 means MidRange, 10 means HighRange. > Or simpler, just check the value of the highest 4 bits, 0x0 means LoRange, > 0x2 means MidRange, 0x7 means HighRange. > You don't even need the high 2 bits right? Chopping them off and using the 3rd and 4th highest bits, you can use 00 for low, 10 for mid, and 11 for high. But I suppose it doesn't really matter as long as we can fit things in. > Like below > > 307 static jmethodID tsan_method_id_from_code_location(u8 loc) { > 308 u8 id = (u8)( > 309 (loc & ~(tsan_fake_pc_bit | tsan_bci_mask)) >> > tsan_method_id_shift); > 310 > 311 #ifdef AARCH64 > 312 u8 ms4bits = id >> 44; > 313 if (ms4bits == 0x7ULL || ms4bits == 0x2ULL ) > 314 id = id | 0x800000000000ULL; > Doesn't this end up mixing high and mid? address in high range is like 0xffffxxxxxxxx, and in mid range is like 0xaaaxxxxxxxxx. by the previous code location encoding in function tsan_code_location, the msb of the 48-bit address will be overwrote, the id become 0x7fffxxxxxxxx and 0x2aaxxxxxxxxx respectively. then I use id = id | 0x800000000000ULL; to restore the highest 4 bits of method id to 0xf and 0xa. > 315 #endif > 316 > 317 return (jmethodID)id; > 318 } > > What do you think? > > Thanks > Jie He > > > > > From github.com+10233373+jhe33 at openjdk.java.net Fri May 8 03:14:52 2020 From: github.com+10233373+jhe33 at openjdk.java.net (Jie He) Date: Fri, 8 May 2020 03:14:52 GMT Subject: RFR: Add aarch64 specific lock/unlock tsan instruments In-Reply-To: References: Message-ID: <0tatPtdGXbOB-bbGu06Qvj5ULV8rr32RM9Kb6LTEHt0=.83974c45-f7ce-4397-ac94-b652af92f089@github.com> On Thu, 7 May 2020 16:31:05 GMT, Arthur Eubanks wrote: > What do you think about making the `16` based on the arch? > > `assert((id_u8 & left_n_bits(16)) == 0, "jmethodID is not aligned");` the assertion guarantees it's a 47-bit address, I think it's not neccessary for aarch64, I can add a AMD64_ONLY for it. ------------- PR: https://git.openjdk.java.net/tsan/pull/9 From github.com+10233373+jhe33 at openjdk.java.net Fri May 8 04:21:01 2020 From: github.com+10233373+jhe33 at openjdk.java.net (Jie He) Date: Fri, 8 May 2020 04:21:01 GMT Subject: RFR: Add aarch64 specific lock/unlock tsan instruments In-Reply-To: <0tatPtdGXbOB-bbGu06Qvj5ULV8rr32RM9Kb6LTEHt0=.83974c45-f7ce-4397-ac94-b652af92f089@github.com> References: <0tatPtdGXbOB-bbGu06Qvj5ULV8rr32RM9Kb6LTEHt0=.83974c45-f7ce-4397-ac94-b652af92f089@github.com> Message-ID: On Fri, 8 May 2020 03:12:30 GMT, Jie He wrote: > > What do you think about making the `16` based on the arch? > > `assert((id_u8 & left_n_bits(16)) == 0, "jmethodID is not aligned");` > > the assertion guarantees it's a 47-bit address, I think it's not neccessary for aarch64, I can add a AMD64_ONLY for it. done ------------- PR: https://git.openjdk.java.net/tsan/pull/9 From github.com+10233373+jhe33 at openjdk.java.net Fri May 8 04:21:01 2020 From: github.com+10233373+jhe33 at openjdk.java.net (Jie He) Date: Fri, 8 May 2020 04:21:01 GMT Subject: [Rev 01] RFR: Add aarch64 specific lock/unlock tsan instruments In-Reply-To: References: Message-ID: <8nsdyq0TbVwL5L_r_0U8SbFBcqyZh9iMtyfxPxIjs48=.5710fb02-652e-481b-ad0c-faaf380bec65@github.com> > Add aarch64 specific lock/unlock instruments into interpreter and > runtime. > > Update an assertion in aarch64 due to different memory layout. > > With tsan enabled, too small java stack often causes SOE, especially > thread "process reaper". Therefore, for running jtreg test in aarch64, > we have to set jdk.lang.processReaperUseDefaultStackSize as true. Jie He 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: Add aarch64 specific lock/unlock tsan instruments Add aarch64 specific lock/unlock instruments into interpreter and runtime. Update an assertion in aarch64 due to different memory layout. With tsan enabled, too small java stack often causes SOE, especially thread "process reaper". Therefore, for running jtreg test in aarch64, we have to set jdk.lang.processReaperUseDefaultStackSize as true. TEST_IMG: ubuntu/openjdk-test TEST_CMD: safe projects/jdk/build-test.sh \ TEST_CMD: --debug-level fastdebug \ TEST_CMD: --configure-args " \ TEST_CMD: --with-toolchain-type=clang,\ TEST_CMD: --with-toolchain-path=/usr/lib/llvm-8/bin" \ TEST_CMD: --vmopts "-Djdk.lang.processReaperUseDefaultStackSize=true" \ TEST_CMD: --scope hotspot:tsan/NonRacyIntMemberLoopTest.java Change-Id: I0ba34e85267f32ce236a1ae0282e71ce9568feb5 Jira: ENTLLT-2812 ------------- Changes: - all: https://git.openjdk.java.net/tsan/pull/9/files - new: https://git.openjdk.java.net/tsan/pull/9/files/7b4a7479..c077b1bc Webrevs: - full: https://webrevs.openjdk.java.net/tsan/9/webrev.01 - incr: https://webrevs.openjdk.java.net/tsan/9/webrev.00-01 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/tsan/pull/9.diff Fetch: git fetch https://git.openjdk.java.net/tsan pull/9/head:pull/9 PR: https://git.openjdk.java.net/tsan/pull/9 From github.com+10233373+jhe33 at openjdk.java.net Fri May 8 05:18:02 2020 From: github.com+10233373+jhe33 at openjdk.java.net (Jie He) Date: Fri, 8 May 2020 05:18:02 GMT Subject: [Rev 02] RFR: Add aarch64 specific lock/unlock tsan instruments In-Reply-To: References: Message-ID: <7pbcPRJSDD49Qc6HDXPGAQCSTQmyC6YnAzKUWYIlX54=.785f0cbf-856c-48d6-b3b7-184ad26dbea7@github.com> > Add aarch64 specific lock/unlock instruments into interpreter and > runtime. > > Update an assertion in aarch64 due to different memory layout. > > With tsan enabled, too small java stack often causes SOE, especially > thread "process reaper". Therefore, for running jtreg test in aarch64, > we have to set jdk.lang.processReaperUseDefaultStackSize as true. Jie He 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: Add aarch64 specific lock/unlock tsan instruments Add aarch64 specific lock/unlock instruments into interpreter and runtime. Update an assertion in aarch64 due to different memory layout. With tsan enabled, too small java stack often causes SOE, especially thread "process reaper". Therefore, for running jtreg test in aarch64, we have to set jdk.lang.processReaperUseDefaultStackSize as true. Change-Id: ------------- Changes: - all: https://git.openjdk.java.net/tsan/pull/9/files - new: https://git.openjdk.java.net/tsan/pull/9/files/c077b1bc..1112aca3 Webrevs: - full: https://webrevs.openjdk.java.net/tsan/9/webrev.02 - incr: https://webrevs.openjdk.java.net/tsan/9/webrev.01-02 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/tsan/pull/9.diff Fetch: git fetch https://git.openjdk.java.net/tsan pull/9/head:pull/9 PR: https://git.openjdk.java.net/tsan/pull/9 From Jie.He at arm.com Fri May 8 06:48:59 2020 From: Jie.He at arm.com (Jie He) Date: Fri, 8 May 2020 06:48:59 +0000 Subject: How does tsan guarantee it won't clobber the xmm registers? Message-ID: Hi Arthur I saw x86 code saves xmm0 because libc functions are called. Then I have a question about current tsan instruments in interpreter. How does tsan guarantee it won't clobber the xmm registers? I think it depends on compiler. I couldn't find the documents or code to declare that. Thanks Jie He From aeubanks at openjdk.java.net Fri May 8 16:21:42 2020 From: aeubanks at openjdk.java.net (Arthur Eubanks) Date: Fri, 8 May 2020 16:21:42 GMT Subject: RFR: Avoid jtreg test timeout in aarch64 due to a stackoverflow in process reaper In-Reply-To: References: <8cMNnH73ROsMxJ4Ygth5Biw-qWHBPU9cgH2PTNe49TU=.27b7c5e6-6c8d-4b84-a2d8-1b9e96541bc9@github.com> Message-ID: On Fri, 8 May 2020 02:40:51 GMT, Jie He wrote: >> I read through https://groups.google.com/forum/#!topic/thread-sanitizer/RsPcxUXBokg (nice investigation btw!) but don't >> quite understand >>> and found the different GLIBC behaviors between x86 and aarch64 stack >>> allocation due to default stack size in openjdk. x86 will get the stack from >>> glibc cached stack because it matches the threshold to allocate a stack from >>> cached stack, but aarch64 not. >> >> Do you mean that on x86 the stack size of the thread is larger than requested because glibc happened to have something >> larger lying around to use? So we are currently getting lucky in x86 with stack sizes? > >> I read through https://groups.google.com/forum/#!topic/thread-sanitizer/RsPcxUXBokg (nice investigation btw!) but don't >> quite understand >> > and found the different GLIBC behaviors between x86 and aarch64 stack >> > allocation due to default stack size in openjdk. x86 will get the stack from >> > glibc cached stack because it matches the threshold to allocate a stack from >> > cached stack, but aarch64 not. >> >> Do you mean that on x86 the stack size of the thread is larger than requested because glibc happened to have something >> larger lying around to use? So we are currently getting lucky in x86 with stack sizes? > > yes, but not exactly. x86 gets the stack from cached stack is another story. > > Initially, when started to investigate the SOE failure, I noticed the different behaviors between x86 and aarch64. TSAN > increases the stack size to 384K, but x86 always could get a 1M stack, meanwhile, aarch64 couldn't. I thought it might > be the reason why no SOE on x86. In fact, it's not the root cause as you already know. even though x86 gets 384K stack > by bypassing the glibc allocation, it won't incur SOE in this case. However I have to take time to investigate the > glibc. By default, stack size of x86 is 1M in openjdk, and aarch64 is 2M. I assume aarch64 will take more stack > consumption than x86 in most cases. sometimes glibc allocates the stack from cached stacks, it depends on if the > requested stack size is larger than 1/4 cached stack. here, 384K > 1/4 * 1M on x86, but not > 1/4 * 2M on aarch64. > anyway, I think the issue in TSAN also will impact the effective usable stack on x86, it could make easier to SOE even > though it doesn't happen in this case. LGTM ------------- PR: https://git.openjdk.java.net/tsan/pull/8 From aeubanks at openjdk.java.net Fri May 8 16:21:17 2020 From: aeubanks at openjdk.java.net (Arthur Eubanks) Date: Fri, 8 May 2020 16:21:17 GMT Subject: RFR: Add aarch64 specific lock/unlock tsan instruments In-Reply-To: References: <0tatPtdGXbOB-bbGu06Qvj5ULV8rr32RM9Kb6LTEHt0=.83974c45-f7ce-4397-ac94-b652af92f089@github.com> Message-ID: On Fri, 8 May 2020 03:44:13 GMT, Jie He wrote: >>> What do you think about making the `16` based on the arch? >>> >>> `assert((id_u8 & left_n_bits(16)) == 0, "jmethodID is not aligned");` >> >> the assertion guarantees it's a 47-bit address, I think it's not neccessary for aarch64, I can add a AMD64_ONLY for it. > >> > What do you think about making the `16` based on the arch? >> > `assert((id_u8 & left_n_bits(16)) == 0, "jmethodID is not aligned");` >> >> the assertion guarantees it's a 47-bit address, I think it's not neccessary for aarch64, I can add a AMD64_ONLY for it. > > done LGTM ------------- PR: https://git.openjdk.java.net/tsan/pull/9 From github.com+10233373+jhe33 at openjdk.java.net Sat May 9 02:22:39 2020 From: github.com+10233373+jhe33 at openjdk.java.net (Jie He) Date: Sat, 9 May 2020 02:22:39 GMT Subject: RFR: Avoid jtreg test timeout in aarch64 due to a stackoverflow in process reaper In-Reply-To: References: <8cMNnH73ROsMxJ4Ygth5Biw-qWHBPU9cgH2PTNe49TU=.27b7c5e6-6c8d-4b84-a2d8-1b9e96541bc9@github.com> Message-ID: On Fri, 8 May 2020 16:17:46 GMT, Arthur Eubanks wrote: > LGTM thanks ------------- PR: https://git.openjdk.java.net/tsan/pull/8 From github.com+10233373+jhe33 at openjdk.java.net Sat May 9 02:23:26 2020 From: github.com+10233373+jhe33 at openjdk.java.net (Jie He) Date: Sat, 9 May 2020 02:23:26 GMT Subject: RFR: Add aarch64 specific lock/unlock tsan instruments In-Reply-To: References: <0tatPtdGXbOB-bbGu06Qvj5ULV8rr32RM9Kb6LTEHt0=.83974c45-f7ce-4397-ac94-b652af92f089@github.com> Message-ID: On Fri, 8 May 2020 16:18:56 GMT, Arthur Eubanks wrote: > LGTM thanks ------------- PR: https://git.openjdk.java.net/tsan/pull/9 From github.com+10233373+jhe33 at openjdk.java.net Sun May 10 04:32:40 2020 From: github.com+10233373+jhe33 at openjdk.java.net (Jie He) Date: Sun, 10 May 2020 04:32:40 GMT Subject: [Integrated] RFR: Avoid jtreg test timeout in aarch64 due to a stackoverflow in process reaper In-Reply-To: <8cMNnH73ROsMxJ4Ygth5Biw-qWHBPU9cgH2PTNe49TU=.27b7c5e6-6c8d-4b84-a2d8-1b9e96541bc9@github.com> References: <8cMNnH73ROsMxJ4Ygth5Biw-qWHBPU9cgH2PTNe49TU=.27b7c5e6-6c8d-4b84-a2d8-1b9e96541bc9@github.com> Message-ID: On Wed, 6 May 2020 09:41:59 GMT, Jie He wrote: > Process reaper has a small size stack by default, 128K. With tsan > enabled, it often causes SOE failure when running jtreg tests. Set > -Djdk.lang.processReaperUseDefaultStackSize=true, to let jtreg test > use default JVM stack size (global variable ThreadStackSize) in > aarch64, which could be configured by -Xss. > > I took an investigation about the stackoverflow, [1]. > and found the different GLIBC behaviors between x86 and aarch64 stack > allocation due to default stack size in openjdk. x86 will get the stack from > glibc cached stack because it matches the threshold to allocate a stack from > cached stack, but aarch64 not. > > [1] https://groups.google.com/forum/#!topic/thread-sanitizer/RsPcxUXBokg This pull request has now been integrated. Changeset: 02fa9c0d Author: jie.he <10233373+jhe33 at users.noreply.github.com> Committer: Arthur Eubanks URL: https://git.openjdk.java.net/tsan/commit/02fa9c0d Stats: 9 lines in 1 file changed: 0 ins; 9 del; 0 mod Avoid jtreg test timeout in aarch64 due to a stackoverflow in process reaper ------------- PR: https://git.openjdk.java.net/tsan/pull/8 From github.com+10233373+jhe33 at openjdk.java.net Sun May 10 04:33:52 2020 From: github.com+10233373+jhe33 at openjdk.java.net (Jie He) Date: Sun, 10 May 2020 04:33:52 GMT Subject: [Integrated] RFR: Add aarch64 specific lock/unlock tsan instruments In-Reply-To: References: Message-ID: On Thu, 7 May 2020 11:14:26 GMT, Jie He wrote: > Add aarch64 specific lock/unlock instruments into interpreter and > runtime. > > Update an assertion in aarch64 due to different memory layout. > > With tsan enabled, too small java stack often causes SOE, especially > thread "process reaper". Therefore, for running jtreg test in aarch64, > we have to set jdk.lang.processReaperUseDefaultStackSize as true. This pull request has now been integrated. Changeset: 3ec97caa Author: jie.he <10233373+jhe33 at users.noreply.github.com> Committer: Arthur Eubanks URL: https://git.openjdk.java.net/tsan/commit/3ec97caa Stats: 41 lines in 3 files changed: 0 ins; 40 del; 1 mod Add aarch64 specific lock/unlock tsan instruments ------------- PR: https://git.openjdk.java.net/tsan/pull/9 From martinrb at google.com Sun May 10 20:29:52 2020 From: martinrb at google.com (Martin Buchholz) Date: Sun, 10 May 2020 13:29:52 -0700 Subject: RFR: Avoid jtreg test timeout in aarch64 due to a stackoverflow in process reaper In-Reply-To: <8cMNnH73ROsMxJ4Ygth5Biw-qWHBPU9cgH2PTNe49TU=.27b7c5e6-6c8d-4b84-a2d8-1b9e96541bc9@github.com> References: <8cMNnH73ROsMxJ4Ygth5Biw-qWHBPU9cgH2PTNe49TU=.27b7c5e6-6c8d-4b84-a2d8-1b9e96541bc9@github.com> Message-ID: I was the one who introduced a small stack size for the process reaper, trying to be a good citizen thread. I still believe it is the right approach, and any stack overflow in that thread indicated a serious JVM bug to fix. Those StackOverflowErrors should have been a nudge to hotspot implementers to eradicate StackOverflowError entirely. But that never happened. On Wed, May 6, 2020 at 2:49 AM Jie He wrote: > > Process reaper has a small size stack by default, 128K. With tsan > enabled, it often causes SOE failure when running jtreg tests. Set > -Djdk.lang.processReaperUseDefaultStackSize=true, to let jtreg test > use default JVM stack size (global variable ThreadStackSize) in > aarch64, which could be configured by -Xss. > > I took an investigation about the stackoverflow, [1]. > and found the different GLIBC behaviors between x86 and aarch64 stack > allocation due to default stack size in openjdk. x86 will get the stack from > glibc cached stack because it matches the threshold to allocate a stack from > cached stack, but aarch64 not. > > [1] https://groups.google.com/forum/#!topic/thread-sanitizer/RsPcxUXBokg > > ------------- > > Commit messages: > - Process reaper uses default JVM stack size in aarch64 > > Changes: https://git.openjdk.java.net/tsan/pull/8/files > Webrev: https://webrevs.openjdk.java.net/tsan/8/webrev.00 > Stats: 9 lines in 1 file changed: 9 ins; 0 del; 0 mod > Patch: https://git.openjdk.java.net/tsan/pull/8.diff > Fetch: git fetch https://git.openjdk.java.net/tsan pull/8/head:pull/8 > > PR: https://git.openjdk.java.net/tsan/pull/8 From github.com+10233373+jhe33 at openjdk.java.net Mon May 11 02:20:20 2020 From: github.com+10233373+jhe33 at openjdk.java.net (Jie He) Date: Mon, 11 May 2020 02:20:20 GMT Subject: RFR: Avoid jtreg test timeout in aarch64 due to a stackoverflow in process reaper In-Reply-To: References: <8cMNnH73ROsMxJ4Ygth5Biw-qWHBPU9cgH2PTNe49TU=.27b7c5e6-6c8d-4b84-a2d8-1b9e96541bc9@github.com> Message-ID: On Sat, 9 May 2020 02:20:19 GMT, Jie He wrote: >> LGTM > >> LGTM > > thanks > _Mailing list message from [Martin Buchholz](mailto:martinrb at google.com) on > [tsan-dev](mailto:tsan-dev at openjdk.java.net):_ > I was the one who introduced a small stack size for the process > reaper, trying to be a good citizen thread. > I still believe it is the right approach, and any stack overflow in > that thread indicated a serious JVM bug to fix. > Those StackOverflowErrors should have been a nudge to hotspot > implementers to eradicate StackOverflowError entirely. > But that never happened. > > On Wed, May 6, 2020 at 2:49 AM Jie He > wrote: > > > Process reaper has a small size stack by default, 128K. With tsan > > enabled, it often causes SOE failure when running jtreg tests. Set > > -Djdk.lang.processReaperUseDefaultStackSize=true, to let jtreg test > > use default JVM stack size (global variable ThreadStackSize) in > > aarch64, which could be configured by -Xss. > > I took an investigation about the stackoverflow, [1]. > > and found the different GLIBC behaviors between x86 and aarch64 stack > > allocation due to default stack size in openjdk. x86 will get the stack from > > glibc cached stack because it matches the threshold to allocate a stack from > > cached stack, but aarch64 not. > > [1] https://groups.google.com/forum/#!topic/thread-sanitizer/RsPcxUXBokg > > ------------- > > Commit messages: > > - Process reaper uses default JVM stack size in aarch64 > > Changes: https://git.openjdk.java.net/tsan/pull/8/files > > Webrev: https://webrevs.openjdk.java.net/tsan/8/webrev.00 > > Stats: 9 lines in 1 file changed: 9 ins; 0 del; 0 mod > > Patch: https://git.openjdk.java.net/tsan/pull/8.diff > > Fetch: git fetch https://git.openjdk.java.net/tsan pull/8/head:pull/8 > > PR: https://git.openjdk.java.net/tsan/pull/8 yes, Martin, I have reported an issue to llvm/tsan. with tsan enabled, it reduces the effiective usable stack size. ------------- PR: https://git.openjdk.java.net/tsan/pull/8 From martinrb at google.com Mon May 11 02:30:10 2020 From: martinrb at google.com (Martin Buchholz) Date: Sun, 10 May 2020 19:30:10 -0700 Subject: RFR: Avoid jtreg test timeout in aarch64 due to a stackoverflow in process reaper In-Reply-To: References: <8cMNnH73ROsMxJ4Ygth5Biw-qWHBPU9cgH2PTNe49TU=.27b7c5e6-6c8d-4b84-a2d8-1b9e96541bc9@github.com> Message-ID: On Sun, May 10, 2020 at 7:20 PM Jie He wrote: > yes, Martin, I have reported an issue to llvm/tsan. with tsan enabled, it reduces the effiective usable stack size. I have always thought that when the JVM is asked to create a thread with some stack size, then the JVM should try hard to ensure that all the requested space is usable for java stack frames, i.e. nothing is deducted for "overhead". The spirit of Java (portability and reliability) hasn't reached stack space calculations yet. From github.com+10233373+jhe33 at openjdk.java.net Mon May 11 02:47:10 2020 From: github.com+10233373+jhe33 at openjdk.java.net (Jie He) Date: Mon, 11 May 2020 02:47:10 GMT Subject: RFR: Avoid jtreg test timeout in aarch64 due to a stackoverflow in process reaper In-Reply-To: References: <8cMNnH73ROsMxJ4Ygth5Biw-qWHBPU9cgH2PTNe49TU=.27b7c5e6-6c8d-4b84-a2d8-1b9e96541bc9@github.com> Message-ID: On Mon, 11 May 2020 02:17:57 GMT, Jie He wrote: >>> LGTM >> >> thanks > >> _Mailing list message from [Martin Buchholz](mailto:martinrb at google.com) on >> [tsan-dev](mailto:tsan-dev at openjdk.java.net):_ >> I was the one who introduced a small stack size for the process >> reaper, trying to be a good citizen thread. >> I still believe it is the right approach, and any stack overflow in >> that thread indicated a serious JVM bug to fix. >> Those StackOverflowErrors should have been a nudge to hotspot >> implementers to eradicate StackOverflowError entirely. >> But that never happened. >> >> On Wed, May 6, 2020 at 2:49 AM Jie He >> wrote: >> >> > Process reaper has a small size stack by default, 128K. With tsan >> > enabled, it often causes SOE failure when running jtreg tests. Set >> > -Djdk.lang.processReaperUseDefaultStackSize=true, to let jtreg test >> > use default JVM stack size (global variable ThreadStackSize) in >> > aarch64, which could be configured by -Xss. >> > I took an investigation about the stackoverflow, [1]. >> > and found the different GLIBC behaviors between x86 and aarch64 stack >> > allocation due to default stack size in openjdk. x86 will get the stack from >> > glibc cached stack because it matches the threshold to allocate a stack from >> > cached stack, but aarch64 not. >> > [1] https://groups.google.com/forum/#!topic/thread-sanitizer/RsPcxUXBokg >> > ------------- >> > Commit messages: >> > - Process reaper uses default JVM stack size in aarch64 >> > Changes: https://git.openjdk.java.net/tsan/pull/8/files >> > Webrev: https://webrevs.openjdk.java.net/tsan/8/webrev.00 >> > Stats: 9 lines in 1 file changed: 9 ins; 0 del; 0 mod >> > Patch: https://git.openjdk.java.net/tsan/pull/8.diff >> > Fetch: git fetch https://git.openjdk.java.net/tsan pull/8/head:pull/8 >> > PR: https://git.openjdk.java.net/tsan/pull/8 > > yes, Martin, I have reported an issue to llvm/tsan. with tsan enabled, it reduces the effiective usable stack size. > _Mailing list message from [Martin Buchholz](mailto:martinrb at google.com) on > [tsan-dev](mailto:tsan-dev at openjdk.java.net):_ > On Sun, May 10, 2020 at 7:20 PM Jie He > wrote: > > > yes, Martin, I have reported an issue to llvm/tsan. with tsan enabled, it reduces the effiective usable stack size. > > I have always thought that when the JVM is asked to create a thread > with some stack size, then the JVM should try hard to ensure that all > the requested space is usable for java stack frames, i.e. nothing is > deducted for "overhead". > > The spirit of Java (portability and reliability) hasn't reached stack > space calculations yet. I think the stack allocation mechanism in glibc will also hide some stack related issues by JVM. in some cases, glibc will allocate a larger stack than you specified. it's out of scope of JVM. ------------- PR: https://git.openjdk.java.net/tsan/pull/8 From martinrb at google.com Mon May 11 03:37:10 2020 From: martinrb at google.com (Martin Buchholz) Date: Sun, 10 May 2020 20:37:10 -0700 Subject: RFR: Avoid jtreg test timeout in aarch64 due to a stackoverflow in process reaper In-Reply-To: References: <8cMNnH73ROsMxJ4Ygth5Biw-qWHBPU9cgH2PTNe49TU=.27b7c5e6-6c8d-4b84-a2d8-1b9e96541bc9@github.com> Message-ID: On Sun, May 10, 2020 at 7:47 PM Jie He wrote: > On Mon, 11 May 2020 02:17:57 GMT, Jie He 10233373+jhe33 at openjdk.org> wrote: > > >>> LGTM > >> > >> thanks > > > >> _Mailing list message from [Martin Buchholz](mailto:martinrb at google.com) > on > >> [tsan-dev](mailto:tsan-dev at openjdk.java.net):_ > >> I was the one who introduced a small stack size for the process > >> reaper, trying to be a good citizen thread. > >> I still believe it is the right approach, and any stack overflow in > >> that thread indicated a serious JVM bug to fix. > >> Those StackOverflowErrors should have been a nudge to hotspot > >> implementers to eradicate StackOverflowError entirely. > >> But that never happened. > >> > >> On Wed, May 6, 2020 at 2:49 AM Jie He > >> wrote: > >> > >> > Process reaper has a small size stack by default, 128K. With tsan > >> > enabled, it often causes SOE failure when running jtreg tests. Set > >> > -Djdk.lang.processReaperUseDefaultStackSize=true, to let jtreg test > >> > use default JVM stack size (global variable ThreadStackSize) in > >> > aarch64, which could be configured by -Xss. > >> > I took an investigation about the stackoverflow, [1]. > >> > and found the different GLIBC behaviors between x86 and aarch64 stack > >> > allocation due to default stack size in openjdk. x86 will get the > stack from > >> > glibc cached stack because it matches the threshold to allocate a > stack from > >> > cached stack, but aarch64 not. > >> > [1] > https://groups.google.com/forum/#!topic/thread-sanitizer/RsPcxUXBokg > >> > ------------- > >> > Commit messages: > >> > - Process reaper uses default JVM stack size in aarch64 > >> > Changes: https://git.openjdk.java.net/tsan/pull/8/files > >> > Webrev: https://webrevs.openjdk.java.net/tsan/8/webrev.00 > >> > Stats: 9 lines in 1 file changed: 9 ins; 0 del; 0 mod > >> > Patch: https://git.openjdk.java.net/tsan/pull/8.diff > >> > Fetch: git fetch https://git.openjdk.java.net/tsan pull/8/head:pull/8 > >> > PR: https://git.openjdk.java.net/tsan/pull/8 > > > > yes, Martin, I have reported an issue to llvm/tsan. with tsan enabled, > it reduces the effiective usable stack size. > > > _Mailing list message from [Martin Buchholz](mailto:martinrb at google.com) > on > > [tsan-dev](mailto:tsan-dev at openjdk.java.net):_ > > On Sun, May 10, 2020 at 7:20 PM Jie He > > wrote: > > > > > yes, Martin, I have reported an issue to llvm/tsan. with tsan enabled, > it reduces the effiective usable stack size. > > > > I have always thought that when the JVM is asked to create a thread > > with some stack size, then the JVM should try hard to ensure that all > > the requested space is usable for java stack frames, i.e. nothing is > > deducted for "overhead". > > > > The spirit of Java (portability and reliability) hasn't reached stack > > space calculations yet. > > I think the stack allocation mechanism in glibc will also hide some stack > related issues by JVM. > in some cases, glibc will allocate a larger stack than you specified. it's > out of scope of JVM. > It might be a bug or misfeature in glibc, but it's JVM's job to deal with it, if necessary writing glibc-version-dependent code. > > ------------- > > PR: https://git.openjdk.java.net/tsan/pull/8 > From aeubanks at google.com Mon May 11 16:18:07 2020 From: aeubanks at google.com (Arthur Eubanks) Date: Mon, 11 May 2020 09:18:07 -0700 Subject: current code location encoding doesn't work in aarch64 In-Reply-To: References: Message-ID: Ah I think I miscounted the bits, sounds good. On Thu, May 7, 2020 at 8:09 PM Jie He wrote: > > > On Fri, May 8, 2020 at 01:40 AM Arthur Eubanks > wrote? > > On Wed, May 6, 2020 at 10:41 PM Jie He wrote: > > > Hi > > > > We know jdk/tsan uses a 64-bit value to identify code location, lowest > > 16-bit for bci, the next 44-bit for method id. > > > > In aarch64 current tsan memory mapping, method id allocated from heap is > > typically like 0xffffxxxxxxxx, which > > Couldn't be encoded by 47-bit directly. > > I don't understand, doesn't 0xffffxxxxxxxx only require 32 bits to > represent? > > > > Yes, but I?m not sure if it?s possible that the heap will be allocated in > Low or Mid memory ranges. > > and X86 just puts the method id directly into the code location packet, I > won't change this code. > > > > However, there are only 3 application memory regions, they are > > > > static const uptr kLoAppMemBeg = 0x0000000001000ull; > > static const uptr kLoAppMemEnd = 0x0000200000000ull; > > static const uptr kMidAppMemBeg = 0x0aaaa00000000ull; > > static const uptr kMidAppMemEnd = 0x0aaaf00000000ull; > > static const uptr kHiAppMemBeg = 0x0ffff00000000ull; > > static const uptr kHiAppMemEnd = 0x1000000000000ull; > > > > I think in aarch64, we don't need 47-bit to encode the method id, because > > highest 12 bits are fixed, and could be encoded by at most 2 bits. > > e.g. 00 means LoAppMemRange, 01 means MidRange, 10 means HighRange. > > Or simpler, just check the value of the highest 4 bits, 0x0 means > LoRange, > > 0x2 means MidRange, 0x7 means HighRange. > > > You don't even need the high 2 bits right? Chopping them off and using the > 3rd and 4th highest bits, you can use 00 for low, 10 for mid, and 11 for > high. But I suppose it doesn't really matter as long as we can fit things > in. > > > Like below > > > > 307 static jmethodID tsan_method_id_from_code_location(u8 loc) { > > 308 u8 id = (u8)( > > 309 (loc & ~(tsan_fake_pc_bit | tsan_bci_mask)) >> > > tsan_method_id_shift); > > 310 > > 311 #ifdef AARCH64 > > 312 u8 ms4bits = id >> 44; > > 313 if (ms4bits == 0x7ULL || ms4bits == 0x2ULL ) > > 314 id = id | 0x800000000000ULL; > > > Doesn't this end up mixing high and mid? > > > > address in high range is like 0xffffxxxxxxxx, and in mid range is like > 0xaaaxxxxxxxxx. > > by the previous code location encoding in function tsan_code_location, the > msb of the 48-bit address will be overwrote, > > the id become 0x7fffxxxxxxxx and 0x2aaxxxxxxxxx respectively. > > then I use id = id | 0x800000000000ULL; to restore the highest 4 bits of > method id to 0xf and 0xa. > > > > 315 #endif > > 316 > > 317 return (jmethodID)id; > > 318 } > > > > What do you think? > > > > Thanks > > Jie He > > > > > > > > > > > > > > From aeubanks at google.com Mon May 11 16:23:54 2020 From: aeubanks at google.com (Arthur Eubanks) Date: Mon, 11 May 2020 09:23:54 -0700 Subject: How does tsan guarantee it won't clobber the xmm registers? In-Reply-To: References: Message-ID: Could you be more specific as to which calls you're worried about? TemplateTable::tsan_observe_get_or_put and TemplateTable::tsan_observe_load_or_store do save xmm0. On Thu, May 7, 2020 at 11:52 PM Jie He wrote: > Hi Arthur > > I saw x86 code saves xmm0 because libc functions are called. > Then I have a question about current tsan instruments in interpreter. > How does tsan guarantee it won't clobber the xmm registers? I think it > depends on compiler. > I couldn't find the documents or code to declare that. > > Thanks > Jie He > From Jie.He at arm.com Tue May 12 02:31:16 2020 From: Jie.He at arm.com (Jie He) Date: Tue, 12 May 2020 02:31:16 +0000 Subject: How does tsan guarantee it won't clobber the xmm registers? In-Reply-To: References: Message-ID: No, currently I didn?t find any error. I just worry about the tsan internal implementation, which depends on the compiler optimization. e.g. if there is a counted loop inside llvm/tsan code, is it possible to use vector instruction to optimize out by compiler? I think tsan is supposed to not to clobber these registers, otherwise, instruments code in application have to save/restore too many registers. Thanks Jie He From: Arthur Eubanks Sent: Tuesday, May 12, 2020 12:24 AM To: Jie He Cc: tsan-dev at openjdk.java.net; nd Subject: Re: How does tsan guarantee it won't clobber the xmm registers? Could you be more specific as to which calls you're worried about? TemplateTable::tsan_observe_get_or_put and TemplateTable::tsan_observe_load_or_store do save xmm0. On Thu, May 7, 2020 at 11:52 PM Jie He > wrote: Hi Arthur I saw x86 code saves xmm0 because libc functions are called. Then I have a question about current tsan instruments in interpreter. How does tsan guarantee it won't clobber the xmm registers? I think it depends on compiler. I couldn't find the documents or code to declare that. Thanks Jie He From github.com+10233373+jhe33 at openjdk.java.net Thu May 14 10:32:00 2020 From: github.com+10233373+jhe33 at openjdk.java.net (Jie He) Date: Thu, 14 May 2020 10:32:00 GMT Subject: RFR: Update code location decoding for aarch64 Message-ID: Jdk/tsan uses a 64-bit value to identify the code location info. The lowest 16-bit for bci, the next 44-bit for method id, and the highest 4 bits are reserved for internal purpose. 44 bits with 8 bytes alignment could represent 47-bit address space. It's sufficient for x86, but not for aarch64 whose heap address needs 48-bit in most cases. According to current tsan memory mapping, method id on aarch64 could be allocated only in 3 memory regions, which highest 12 bits are fixed, they are 0x0, 0xaaa and 0xfff respectively. We could use it to distinguish which space the method id comes from. After code location encoding in tsan_code_location(), the MSB of the id will be overwritten, but we can restore it in decoding function because we know the memory range the id is allocated to. It won't impact the performance. The decoding function is only called when need to report a race. I found the issue after enabled object field related instruments. ------------- Commit messages: - Update code location decoding for aarch64 Changes: https://git.openjdk.java.net/tsan/pull/10/files Webrev: https://webrevs.openjdk.java.net/tsan/10/webrev.00 Stats: 17 lines in 1 file changed: 14 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/tsan/pull/10.diff Fetch: git fetch https://git.openjdk.java.net/tsan pull/10/head:pull/10 PR: https://git.openjdk.java.net/tsan/pull/10 From aeubanks at openjdk.java.net Thu May 14 15:52:04 2020 From: aeubanks at openjdk.java.net (Arthur Eubanks) Date: Thu, 14 May 2020 15:52:04 GMT Subject: RFR: Update code location decoding for aarch64 In-Reply-To: References: Message-ID: <6h51lcIoGNItzRBw70Ne6gKsp-VsatzNl9AMiO01Jcw=.b0042843-412a-4e46-a913-39ec930602f9@github.com> On Thu, 14 May 2020 10:24:58 GMT, Jie He wrote: > Jdk/tsan uses a 64-bit value to identify the code location info. The > lowest 16-bit for bci, the next 44-bit for method id, and the highest 4 > bits are reserved for internal purpose. 44 bits with 8 bytes alignment > could represent 47-bit address space. It's sufficient for x86, but not > for aarch64 whose heap address needs 48-bit in most cases. > > According to current tsan memory mapping, method id on aarch64 could be > allocated only in 3 memory regions, which highest 12 bits are fixed, they > are 0x0, 0xaaa and 0xfff respectively. We could use it to distinguish > which space the method id comes from. > > After code location encoding in tsan_code_location(), the MSB of the > id will be overwritten, but we can restore it in decoding function because > we know the memory range the id is allocated to. > > It won't impact the performance. The decoding function is only called > when need to report a race. > > I found the issue after enabled object field related instruments. LGTM ------------- PR: https://git.openjdk.java.net/tsan/pull/10 From github.com+10233373+jhe33 at openjdk.java.net Fri May 15 03:26:35 2020 From: github.com+10233373+jhe33 at openjdk.java.net (Jie He) Date: Fri, 15 May 2020 03:26:35 GMT Subject: [Integrated] RFR: Update code location decoding for aarch64 In-Reply-To: References: Message-ID: <57zQ98HeJc4r4Acw1mlai6xMhYuXnUZ_UAIegE-4ybQ=.de6262e3-7126-483e-8747-25a43b872e57@github.com> On Thu, 14 May 2020 10:24:58 GMT, Jie He wrote: > Jdk/tsan uses a 64-bit value to identify the code location info. The > lowest 16-bit for bci, the next 44-bit for method id, and the highest 4 > bits are reserved for internal purpose. 44 bits with 8 bytes alignment > could represent 47-bit address space. It's sufficient for x86, but not > for aarch64 whose heap address needs 48-bit in most cases. > > According to current tsan memory mapping, method id on aarch64 could be > allocated only in 3 memory regions, which highest 12 bits are fixed, they > are 0x0, 0xaaa and 0xfff respectively. We could use it to distinguish > which space the method id comes from. > > After code location encoding in tsan_code_location(), the MSB of the > id will be overwritten, but we can restore it in decoding function because > we know the memory range the id is allocated to. > > It won't impact the performance. The decoding function is only called > when need to report a race. > > I found the issue after enabled object field related instruments. This pull request has now been integrated. Changeset: 3c27e4dc Author: jie.he Committer: Arthur Eubanks URL: https://git.openjdk.java.net/tsan/commit/3c27e4dc Stats: 17 lines in 1 file changed: 0 ins; 14 del; 3 mod Update code location decoding for aarch64 ------------- PR: https://git.openjdk.java.net/tsan/pull/10 From dvyukov at google.com Sat May 23 12:56:31 2020 From: dvyukov at google.com (Dmitry Vyukov) Date: Sat, 23 May 2020 14:56:31 +0200 Subject: __tsan_java_finalize bug Message-ID: Hi, FYI there is a bug reported in tsan's AcquireGlobal: https://github.com/golang/go/issues/39186 It's for Go, but I think it equally affects __tsan_java_finalize(). Is it used in the current implementation for Java finalizers? Brief summary: it requires a very special program pattern and a very narrow inconsistency window (4 threads participating in a very special and tricky interleaving), but if all of that is satisfied it can lead to arbitrary unexplainable false positives. From github.com+10233373+jhe33 at openjdk.java.net Tue May 26 05:02:13 2020 From: github.com+10233373+jhe33 at openjdk.java.net (Jie He) Date: Tue, 26 May 2020 05:02:13 GMT Subject: RFR: Add the code to track object allocation for aarch64 Message-ID: Jdk/tsan has added the code in gc to track the oop move/collect, thus, in this patch, what we only need to do is to track the oop allocation in interpreter. Jdk/tsan builds a hash table to track all oops, oop address as hash key. Any move/collect of oop detected by code at the end of each gc will update the hash table, then call tsan APIs _tsan_java_move or _tsan_java_free to notify llvm/tsan. ------------- Commit messages: - Add the code to track object allocation for aarch64 Changes: https://git.openjdk.java.net/tsan/pull/12/files Webrev: https://webrevs.openjdk.java.net/tsan/12/webrev.00 Stats: 8 lines in 1 file changed: 8 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/tsan/pull/12.diff Fetch: git fetch https://git.openjdk.java.net/tsan pull/12/head:pull/12 PR: https://git.openjdk.java.net/tsan/pull/12 From github.com+10482586+erik1iu at openjdk.java.net Tue May 26 14:50:16 2020 From: github.com+10482586+erik1iu at openjdk.java.net (eric.1iu) Date: Tue, 26 May 2020 14:50:16 GMT Subject: RFR: Enable field access instrumentation for aarch64 Message-ID: <6N6MwZPGuJaaehHaMbIQcV2hNblPlhJwQcH-0IfFqKA=.56a1191c-4973-413b-a7d1-fb4d65d66905@github.com> This patch enables field access instrumentation for aarch64. According to the implementation of x86, this patch inserts TSAN functions in interpreter (templateTable_aarch64.cpp) at three places which can cover all field accesses: 1. getfield_or_static 2. putfield_or_static 3. load_field_cp_cache_entry This patch implements the annotation 'java.util.concurrent.annotation.LazyInit', which causes TSAN to ignore races on that field. References that marked by @LazyInit are not simply ignored, but a release/acquire is performed on them. This is so that any following accesses to its member variables are not also reported as race. This patch also moves some architecture independent code into common files. TODO: - Array access instrumentation will be updated in later patch. [Tests] test/hotspot/jtreg/tsan/RacyByteMemberLoopTest.java test/hotspot/jtreg/tsan/RacyCharMemberLoopTest.java test/hotspot/jtreg/tsan/RacyShortMemberLoopTest.java test/hotspot/jtreg/tsan/RacyIntMemberLoopTest.java test/hotspot/jtreg/tsan/RacyFloatMemberLoopTest.java test/hotspot/jtreg/tsan/RacyLongMemberLoopTest.java test/hotspot/jtreg/tsan/RacyDoubleMemberLoopTest.java test/hotspot/jtreg/tsan/LazyInitLoopTest.java test/hotspot/jtreg/tsan/LazyInitReferenceLoopTest.java With this patch, those test cases above passed on aarch64. No new failure found on x86. ------------- Commit messages: - [TSAN] Enable field access instrumentation for aarch64 Changes: https://git.openjdk.java.net/tsan/pull/11/files Webrev: https://webrevs.openjdk.java.net/tsan/11/webrev.00 Stats: 226 lines in 5 files changed: 168 ins; 52 del; 6 mod Patch: https://git.openjdk.java.net/tsan/pull/11.diff Fetch: git fetch https://git.openjdk.java.net/tsan pull/11/head:pull/11 PR: https://git.openjdk.java.net/tsan/pull/11 From aeubanks at openjdk.java.net Tue May 26 17:02:08 2020 From: aeubanks at openjdk.java.net (Arthur Eubanks) Date: Tue, 26 May 2020 17:02:08 GMT Subject: RFR: Enable field access instrumentation for aarch64 In-Reply-To: <6N6MwZPGuJaaehHaMbIQcV2hNblPlhJwQcH-0IfFqKA=.56a1191c-4973-413b-a7d1-fb4d65d66905@github.com> References: <6N6MwZPGuJaaehHaMbIQcV2hNblPlhJwQcH-0IfFqKA=.56a1191c-4973-413b-a7d1-fb4d65d66905@github.com> Message-ID: On Thu, 21 May 2020 09:58:14 GMT, eric.1iu wrote: > This patch enables field access instrumentation for aarch64. > > According to the implementation of x86, this patch inserts TSAN > functions in interpreter (templateTable_aarch64.cpp) at three places > which can cover all field accesses: > > 1. getfield_or_static > 2. putfield_or_static > 3. load_field_cp_cache_entry > > This patch implements the annotation > 'java.util.concurrent.annotation.LazyInit', which causes TSAN to ignore > races on that field. References that marked by @LazyInit are not simply > ignored, but a release/acquire is performed on them. This is so that any > following accesses to its member variables are not also reported as race. > > This patch also moves some architecture independent code into common > files. > > TODO: > - Array access instrumentation will be updated in later patch. > > [Tests] > test/hotspot/jtreg/tsan/RacyByteMemberLoopTest.java > test/hotspot/jtreg/tsan/RacyCharMemberLoopTest.java > test/hotspot/jtreg/tsan/RacyShortMemberLoopTest.java > test/hotspot/jtreg/tsan/RacyIntMemberLoopTest.java > test/hotspot/jtreg/tsan/RacyFloatMemberLoopTest.java > test/hotspot/jtreg/tsan/RacyLongMemberLoopTest.java > test/hotspot/jtreg/tsan/RacyDoubleMemberLoopTest.java > test/hotspot/jtreg/tsan/LazyInitLoopTest.java > test/hotspot/jtreg/tsan/LazyInitReferenceLoopTest.java > > With this patch, those test cases above passed on aarch64. > No new failure found on x86. LGTM, just one minor nit src/hotspot/share/interpreter/templateTable.hpp line 335: > 334: static void def(Bytecodes::Code code, int flags, TosState in, TosState out, void (*gen)(int arg ), int > arg ); 335: static void def(Bytecodes::Code code, int flags, TosState in, TosState out, void (*gen)(bool arg > ), bool arg ); 336: static void def(Bytecodes::Code code, int flags, TosState in, TosState out, void > (*gen)(TosState tos), TosState tos); This seems unnecessary and can introduce potential merge conflicts ------------- PR: https://git.openjdk.java.net/tsan/pull/11 From aeubanks at openjdk.java.net Tue May 26 17:07:16 2020 From: aeubanks at openjdk.java.net (Arthur Eubanks) Date: Tue, 26 May 2020 17:07:16 GMT Subject: RFR: Add the code to track object allocation for aarch64 In-Reply-To: References: Message-ID: On Fri, 22 May 2020 06:59:47 GMT, Jie He wrote: > Jdk/tsan has added the code in gc to track the oop move/collect, thus, > in this patch, what we only need to do is to track the oop allocation > in interpreter. > > Jdk/tsan builds a hash table to track all oops, oop address as hash key. > Any move/collect of oop detected by code at the end of each gc will > update the hash table, then call tsan APIs _tsan_java_move or > _tsan_java_free to notify llvm/tsan. lgtm ------------- PR: https://git.openjdk.java.net/tsan/pull/12 From manc at openjdk.java.net Tue May 26 17:57:06 2020 From: manc at openjdk.java.net (Man Cao) Date: Tue, 26 May 2020 17:57:06 GMT Subject: RFR: Add the code to track object allocation for aarch64 In-Reply-To: References: Message-ID: On Tue, 26 May 2020 17:03:54 GMT, Arthur Eubanks wrote: >> Jdk/tsan has added the code in gc to track the oop move/collect, thus, >> in this patch, what we only need to do is to track the oop allocation >> in interpreter. >> >> Jdk/tsan builds a hash table to track all oops, oop address as hash key. >> Any move/collect of oop detected by code at the end of each gc will >> update the hash table, then call tsan APIs _tsan_java_move or >> _tsan_java_free to notify llvm/tsan. > > lgtm LGTM ------------- PR: https://git.openjdk.java.net/tsan/pull/12 From github.com+10482586+erik1iu at openjdk.java.net Wed May 27 01:49:24 2020 From: github.com+10482586+erik1iu at openjdk.java.net (eric.1iu) Date: Wed, 27 May 2020 01:49:24 GMT Subject: RFR: Enable field access instrumentation for aarch64 In-Reply-To: References: <6N6MwZPGuJaaehHaMbIQcV2hNblPlhJwQcH-0IfFqKA=.56a1191c-4973-413b-a7d1-fb4d65d66905@github.com> Message-ID: On Tue, 26 May 2020 16:56:32 GMT, Arthur Eubanks wrote: >> This patch enables field access instrumentation for aarch64. >> >> According to the implementation of x86, this patch inserts TSAN >> functions in interpreter (templateTable_aarch64.cpp) at three places >> which can cover all field accesses: >> >> 1. getfield_or_static >> 2. putfield_or_static >> 3. load_field_cp_cache_entry >> >> This patch implements the annotation >> 'java.util.concurrent.annotation.LazyInit', which causes TSAN to ignore >> races on that field. References that marked by @LazyInit are not simply >> ignored, but a release/acquire is performed on them. This is so that any >> following accesses to its member variables are not also reported as race. >> >> This patch also moves some architecture independent code into common >> files. >> >> TODO: >> - Array access instrumentation will be updated in later patch. >> >> [Tests] >> test/hotspot/jtreg/tsan/RacyByteMemberLoopTest.java >> test/hotspot/jtreg/tsan/RacyCharMemberLoopTest.java >> test/hotspot/jtreg/tsan/RacyShortMemberLoopTest.java >> test/hotspot/jtreg/tsan/RacyIntMemberLoopTest.java >> test/hotspot/jtreg/tsan/RacyFloatMemberLoopTest.java >> test/hotspot/jtreg/tsan/RacyLongMemberLoopTest.java >> test/hotspot/jtreg/tsan/RacyDoubleMemberLoopTest.java >> test/hotspot/jtreg/tsan/LazyInitLoopTest.java >> test/hotspot/jtreg/tsan/LazyInitReferenceLoopTest.java >> >> With this patch, those test cases above passed on aarch64. >> No new failure found on x86. > > src/hotspot/share/interpreter/templateTable.hpp line 335: > >> 334: static void def(Bytecodes::Code code, int flags, TosState in, TosState out, void (*gen)(int arg ), int >> arg ); 335: static void def(Bytecodes::Code code, int flags, TosState in, TosState out, void (*gen)(bool arg >> ), bool arg ); 336: static void def(Bytecodes::Code code, int flags, TosState in, TosState out, void >> (*gen)(TosState tos), TosState tos); > > This seems unnecessary and can introduce potential merge conflicts Agree. ------------- PR: https://git.openjdk.java.net/tsan/pull/11 From github.com+10482586+erik1iu at openjdk.java.net Wed May 27 02:28:29 2020 From: github.com+10482586+erik1iu at openjdk.java.net (eric.1iu) Date: Wed, 27 May 2020 02:28:29 GMT Subject: [Rev 01] RFR: Enable field access instrumentation for aarch64 In-Reply-To: <6N6MwZPGuJaaehHaMbIQcV2hNblPlhJwQcH-0IfFqKA=.56a1191c-4973-413b-a7d1-fb4d65d66905@github.com> References: <6N6MwZPGuJaaehHaMbIQcV2hNblPlhJwQcH-0IfFqKA=.56a1191c-4973-413b-a7d1-fb4d65d66905@github.com> Message-ID: > This patch enables field access instrumentation for aarch64. > > According to the implementation of x86, this patch inserts TSAN > functions in interpreter (templateTable_aarch64.cpp) at three places > which can cover all field accesses: > > 1. getfield_or_static > 2. putfield_or_static > 3. load_field_cp_cache_entry > > This patch implements the annotation > 'java.util.concurrent.annotation.LazyInit', which causes TSAN to ignore > races on that field. References that marked by @LazyInit are not simply > ignored, but a release/acquire is performed on them. This is so that any > following accesses to its member variables are not also reported as race. > > This patch also moves some architecture independent code into common > files. > > TODO: > - Array access instrumentation will be updated in later patch. > > [Tests] > test/hotspot/jtreg/tsan/RacyByteMemberLoopTest.java > test/hotspot/jtreg/tsan/RacyCharMemberLoopTest.java > test/hotspot/jtreg/tsan/RacyShortMemberLoopTest.java > test/hotspot/jtreg/tsan/RacyIntMemberLoopTest.java > test/hotspot/jtreg/tsan/RacyFloatMemberLoopTest.java > test/hotspot/jtreg/tsan/RacyLongMemberLoopTest.java > test/hotspot/jtreg/tsan/RacyDoubleMemberLoopTest.java > test/hotspot/jtreg/tsan/LazyInitLoopTest.java > test/hotspot/jtreg/tsan/LazyInitReferenceLoopTest.java > > With this patch, those test cases above passed on aarch64. > No new failure found on x86. eric.1iu 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: [TSAN] Enable field access instrumentation for aarch64 This patch enables field access instrumentation for aarch64. According to the implementation of x86, this patch inserts TSAN functions in interpreter (templateTable_aarch64.cpp) at three places which can cover all field accesses: 1. getfield_or_static 2. putfield_or_static 3. load_field_cp_cache_entry This patch implements the annotation 'java.util.concurrent.annotation.LazyInit', which causes TSAN to ignore races on that field. References that marked by @LazyInit are not simply ignored, but a release/acquire is performed on them. This is so that any following accesses to its member variables are not also reported as race. This patch also moves some architecture independent code into common files. TODO: - Array access instrumentation will be updated in later patch. Change-Id: I867124a6166c54040ac313fb366861dfc845f18d ------------- Changes: - all: https://git.openjdk.java.net/tsan/pull/11/files - new: https://git.openjdk.java.net/tsan/pull/11/files/fa8696f9..ab84aeb7 Webrevs: - full: https://webrevs.openjdk.java.net/tsan/11/webrev.01 - incr: https://webrevs.openjdk.java.net/tsan/11/webrev.00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/tsan/pull/11.diff Fetch: git fetch https://git.openjdk.java.net/tsan pull/11/head:pull/11 PR: https://git.openjdk.java.net/tsan/pull/11 From github.com+10233373+jhe33 at openjdk.java.net Wed May 27 05:27:21 2020 From: github.com+10233373+jhe33 at openjdk.java.net (Jie He) Date: Wed, 27 May 2020 05:27:21 GMT Subject: [Integrated] RFR: Add the code to track object allocation for aarch64 In-Reply-To: References: Message-ID: <3ZQXs8sTSl5tJUj2K9gyJzquaXE9hXngH6d9PRrpBT8=.4e24a39d-cc92-4b4b-80d9-ad86b5b45a6d@github.com> On Fri, 22 May 2020 06:59:47 GMT, Jie He wrote: > Jdk/tsan has added the code in gc to track the oop move/collect, thus, > in this patch, what we only need to do is to track the oop allocation > in interpreter. > > Jdk/tsan builds a hash table to track all oops, oop address as hash key. > Any move/collect of oop detected by code at the end of each gc will > update the hash table, then call tsan APIs _tsan_java_move or > _tsan_java_free to notify llvm/tsan. This pull request has now been integrated. Changeset: 7ff9b065 Author: jie.he Committer: Arthur Eubanks URL: https://git.openjdk.java.net/tsan/commit/7ff9b065 Stats: 8 lines in 1 file changed: 0 ins; 8 del; 0 mod Add the code to track object allocation for aarch64 ------------- PR: https://git.openjdk.java.net/tsan/pull/12 From github.com+10482586+erik1iu at openjdk.java.net Wed May 27 16:06:45 2020 From: github.com+10482586+erik1iu at openjdk.java.net (eric.1iu) Date: Wed, 27 May 2020 16:06:45 GMT Subject: [Integrated] RFR: Enable field access instrumentation for aarch64 In-Reply-To: <6N6MwZPGuJaaehHaMbIQcV2hNblPlhJwQcH-0IfFqKA=.56a1191c-4973-413b-a7d1-fb4d65d66905@github.com> References: <6N6MwZPGuJaaehHaMbIQcV2hNblPlhJwQcH-0IfFqKA=.56a1191c-4973-413b-a7d1-fb4d65d66905@github.com> Message-ID: On Thu, 21 May 2020 09:58:14 GMT, eric.1iu wrote: > This patch enables field access instrumentation for aarch64. > > According to the implementation of x86, this patch inserts TSAN > functions in interpreter (templateTable_aarch64.cpp) at three places > which can cover all field accesses: > > 1. getfield_or_static > 2. putfield_or_static > 3. load_field_cp_cache_entry > > This patch implements the annotation > 'java.util.concurrent.annotation.LazyInit', which causes TSAN to ignore > races on that field. References that marked by @LazyInit are not simply > ignored, but a release/acquire is performed on them. This is so that any > following accesses to its member variables are not also reported as race. > > This patch also moves some architecture independent code into common > files. > > TODO: > - Array access instrumentation will be updated in later patch. > > [Tests] > test/hotspot/jtreg/tsan/RacyByteMemberLoopTest.java > test/hotspot/jtreg/tsan/RacyCharMemberLoopTest.java > test/hotspot/jtreg/tsan/RacyShortMemberLoopTest.java > test/hotspot/jtreg/tsan/RacyIntMemberLoopTest.java > test/hotspot/jtreg/tsan/RacyFloatMemberLoopTest.java > test/hotspot/jtreg/tsan/RacyLongMemberLoopTest.java > test/hotspot/jtreg/tsan/RacyDoubleMemberLoopTest.java > test/hotspot/jtreg/tsan/LazyInitLoopTest.java > test/hotspot/jtreg/tsan/LazyInitReferenceLoopTest.java > > With this patch, those test cases above passed on aarch64. > No new failure found on x86. This pull request has now been integrated. Changeset: 7f1f31a1 Author: Eric Liu Committer: Arthur Eubanks URL: https://git.openjdk.java.net/tsan/commit/7f1f31a1 Stats: 225 lines in 5 files changed: 52 ins; 168 del; 5 mod Enable field access instrumentation for aarch64 ------------- PR: https://git.openjdk.java.net/tsan/pull/11 From manc at google.com Wed May 27 19:03:34 2020 From: manc at google.com (Man Cao) Date: Wed, 27 May 2020 12:03:34 -0700 Subject: __tsan_java_finalize bug In-Reply-To: References: Message-ID: __tsan_java_finalize() is used in Java finalizer: https://github.com/openjdk/tsan/blob/7f1f31a18bafd9df728b03c63953f4e3fe20abdb/src/java.base/share/classes/java/lang/ref/Finalizer.java#L90 tsanFinalize() calls __tsan_java_finalize(). finalize() is deprecated since Java 9. Perhaps the Cleaner mechanism does not need __tsan_java_finalize()? -Man On Sat, May 23, 2020 at 5:57 AM Dmitry Vyukov wrote: > Hi, > > FYI there is a bug reported in tsan's AcquireGlobal: > https://github.com/golang/go/issues/39186 > It's for Go, but I think it equally affects __tsan_java_finalize(). Is > it used in the current implementation for Java finalizers? > > Brief summary: it requires a very special program pattern and a very > narrow inconsistency window (4 threads participating in a very special > and tricky interleaving), but if all of that is satisfied it can lead > to arbitrary unexplainable false positives. > From dvyukov at google.com Wed May 27 19:36:26 2020 From: dvyukov at google.com (Dmitry Vyukov) Date: Wed, 27 May 2020 21:36:26 +0200 Subject: __tsan_java_finalize bug In-Reply-To: References: Message-ID: On Wed, May 27, 2020 at 9:03 PM Man Cao wrote: > > __tsan_java_finalize() is used in Java finalizer: > https://github.com/openjdk/tsan/blob/7f1f31a18bafd9df728b03c63953f4e3fe20abdb/src/java.base/share/classes/java/lang/ref/Finalizer.java#L90 > tsanFinalize() calls __tsan_java_finalize(). > > finalize() is deprecated since Java 9. Perhaps the Cleaner mechanism does not need __tsan_java_finalize()? I can't tell right away. This area proved to be tricky :) >From quick skimming I don't see any synchronization/visibility guarantees for Cleaner. If there are none (everything is supposed to be synchronized by user code explicitly), then we done! But FWIW the tsan issue with GlobalAcquire was fixed upstream. > On Sat, May 23, 2020 at 5:57 AM Dmitry Vyukov wrote: >> >> Hi, >> >> FYI there is a bug reported in tsan's AcquireGlobal: >> https://github.com/golang/go/issues/39186 >> It's for Go, but I think it equally affects __tsan_java_finalize(). Is >> it used in the current implementation for Java finalizers? >> >> Brief summary: it requires a very special program pattern and a very >> narrow inconsistency window (4 threads participating in a very special >> and tricky interleaving), but if all of that is satisfied it can lead >> to arbitrary unexplainable false positives. From martinrb at google.com Thu May 28 01:18:31 2020 From: martinrb at google.com (Martin Buchholz) Date: Wed, 27 May 2020 18:18:31 -0700 Subject: __tsan_java_finalize bug In-Reply-To: References: Message-ID: On Wed, May 27, 2020 at 12:37 PM Dmitry Vyukov wrote: > > On Wed, May 27, 2020 at 9:03 PM Man Cao wrote: > > > > __tsan_java_finalize() is used in Java finalizer: > > https://github.com/openjdk/tsan/blob/7f1f31a18bafd9df728b03c63953f4e3fe20abdb/src/java.base/share/classes/java/lang/ref/Finalizer.java#L90 > > tsanFinalize() calls __tsan_java_finalize(). > > > > finalize() is deprecated since Java 9. Perhaps the Cleaner mechanism does not need __tsan_java_finalize()? > > I can't tell right away. This area proved to be tricky :) > > From quick skimming I don't see any synchronization/visibility > guarantees for Cleaner. If there are none (everything is supposed to > be synchronized by user code explicitly), then we done! I did my own overview of jdk docs, and I came to the same conclusion as Dmitry ! From github.com+10482586+erik1iu at openjdk.java.net Thu May 28 07:46:10 2020 From: github.com+10482586+erik1iu at openjdk.java.net (eric.1iu) Date: Thu, 28 May 2020 07:46:10 GMT Subject: RFR: Enable array access instrumentation for aarch64 Message-ID: This patch is a subsequent patch of https://github.com/openjdk/tsan/pull/11. This patch inserts TSAN instrumentation in interpreter at array access bytecodes like below: - aaload, baload, caload, daload, iaload, laload, saload - aastore, bastore, castore, dastore, iastore, lastore, sastore Besides those normal array access bytecodes, some fast bytecodes (e.g. fast_icaload) would result in memory access as well. TSAN has disabled bytecode rewrite in previous patch. This patch inserts assertions in 'fast_xaccess', 'fast_accessfield' and 'fast_icaload' to make sure that TSAN would not reach there. [TEST] With this patch, all TSAN test cases passed both on x86 and aarch64. ------------- Commit messages: - Enable array access instrumentation for aarch64 Changes: https://git.openjdk.java.net/tsan/pull/13/files Webrev: https://webrevs.openjdk.java.net/tsan/13/webrev.00 Stats: 84 lines in 2 files changed: 56 ins; 3 del; 25 mod Patch: https://git.openjdk.java.net/tsan/pull/13.diff Fetch: git fetch https://git.openjdk.java.net/tsan pull/13/head:pull/13 PR: https://git.openjdk.java.net/tsan/pull/13 From aeubanks at openjdk.java.net Thu May 28 17:44:12 2020 From: aeubanks at openjdk.java.net (Arthur Eubanks) Date: Thu, 28 May 2020 17:44:12 GMT Subject: RFR: Enable array access instrumentation for aarch64 In-Reply-To: References: Message-ID: On Thu, 28 May 2020 07:37:16 GMT, eric.1iu wrote: > This patch is a subsequent patch of https://github.com/openjdk/tsan/pull/11. > > This patch inserts TSAN instrumentation in interpreter at array access > bytecodes like below: > > - aaload, baload, caload, daload, iaload, laload, saload > - aastore, bastore, castore, dastore, iastore, lastore, sastore > > Besides those normal array access bytecodes, some fast bytecodes (e.g. > fast_icaload) would result in memory access as well. TSAN has disabled > bytecode rewrite in previous patch. This patch inserts assertions > in 'fast_xaccess', 'fast_accessfield' and 'fast_icaload' to make sure > that TSAN would not reach there. > > > [TEST] > With this patch, all TSAN test cases passed both on x86 and aarch64. LGTM Exciting that all the tests pass now! Is there any follow up work after this? (Except of course the monumental task of upstreaming this into jdk/jdk) ------------- PR: https://git.openjdk.java.net/tsan/pull/13 From github.com+10482586+erik1iu at openjdk.java.net Fri May 29 02:55:40 2020 From: github.com+10482586+erik1iu at openjdk.java.net (eric.1iu) Date: Fri, 29 May 2020 02:55:40 GMT Subject: RFR: Enable array access instrumentation for aarch64 In-Reply-To: References: Message-ID: On Thu, 28 May 2020 17:41:49 GMT, Arthur Eubanks wrote: >> This patch is a subsequent patch of https://github.com/openjdk/tsan/pull/11. >> >> This patch inserts TSAN instrumentation in interpreter at array access >> bytecodes like below: >> >> - aaload, baload, caload, daload, iaload, laload, saload >> - aastore, bastore, castore, dastore, iastore, lastore, sastore >> >> Besides those normal array access bytecodes, some fast bytecodes (e.g. >> fast_icaload) would result in memory access as well. TSAN has disabled >> bytecode rewrite in previous patch. This patch inserts assertions >> in 'fast_xaccess', 'fast_accessfield' and 'fast_icaload' to make sure >> that TSAN would not reach there. >> >> >> [TEST] >> With this patch, all TSAN test cases passed both on x86 and aarch64. > > LGTM > > Exciting that all the tests pass now! Is there any follow up work after this? (Except of course the monumental task of > upstreaming this into jdk/jdk) Hi Arthur, Thanks for your review. We (@jhe33 @erik1iu ) will do more testing about TSAN recently, and also intend to spend some time to investigate if it's possible to enable TSAN in C1 compiler. I suppose there would not have patch delivery in the short term. Finally, thanks for your (your team's) pre-investigation and lots of common works on TSAN, which is a great work for the whole project and gives us great help. B&R Eric ------------- PR: https://git.openjdk.java.net/tsan/pull/13 From github.com+10233373+jhe33 at openjdk.java.net Fri May 29 03:06:52 2020 From: github.com+10233373+jhe33 at openjdk.java.net (Jie He) Date: Fri, 29 May 2020 03:06:52 GMT Subject: RFR: Enable array access instrumentation for aarch64 In-Reply-To: References: Message-ID: On Fri, 29 May 2020 02:53:25 GMT, eric.1iu wrote: > Hi Arthur, > > Thanks for your review. > > We (@jhe33 @erik1iu ) will do more testing about TSAN recently, and also intend to spend some time to investigate if > it's possible to enable TSAN in C1 compiler. I suppose there would not have patch delivery in the short term. > Finally, thanks for your (your team's) pre-investigation and lots of common works on TSAN, which is a great work for > the whole project and gives us great help. > B&R > Eric yes, it's really helpful for us, thanks @aeubanks @caoman. ------------- PR: https://git.openjdk.java.net/tsan/pull/13 From github.com+10482586+erik1iu at openjdk.java.net Fri May 29 04:12:54 2020 From: github.com+10482586+erik1iu at openjdk.java.net (eric.1iu) Date: Fri, 29 May 2020 04:12:54 GMT Subject: [Integrated] RFR: Enable array access instrumentation for aarch64 In-Reply-To: References: Message-ID: On Thu, 28 May 2020 07:37:16 GMT, eric.1iu wrote: > This patch is a subsequent patch of https://github.com/openjdk/tsan/pull/11. > > This patch inserts TSAN instrumentation in interpreter at array access > bytecodes like below: > > - aaload, baload, caload, daload, iaload, laload, saload > - aastore, bastore, castore, dastore, iastore, lastore, sastore > > Besides those normal array access bytecodes, some fast bytecodes (e.g. > fast_icaload) would result in memory access as well. TSAN has disabled > bytecode rewrite in previous patch. This patch inserts assertions > in 'fast_xaccess', 'fast_accessfield' and 'fast_icaload' to make sure > that TSAN would not reach there. > > > [TEST] > With this patch, all TSAN test cases passed both on x86 and aarch64. This pull request has now been integrated. Changeset: 5b22e180 Author: Eric Liu Committer: Arthur Eubanks URL: https://git.openjdk.java.net/tsan/commit/5b22e180 Stats: 84 lines in 2 files changed: 3 ins; 56 del; 25 mod Enable array access instrumentation for aarch64 ------------- PR: https://git.openjdk.java.net/tsan/pull/13 From aeubanks at openjdk.java.net Fri May 29 04:12:53 2020 From: aeubanks at openjdk.java.net (Arthur Eubanks) Date: Fri, 29 May 2020 04:12:53 GMT Subject: RFR: Enable array access instrumentation for aarch64 In-Reply-To: References: Message-ID: On Fri, 29 May 2020 03:04:33 GMT, Jie He wrote: >> Hi Arthur, >> >> Thanks for your review. >> >> We (@jhe33 @erik1iu ) will do more testing about TSAN recently, and also intend to spend some time to investigate if >> it's possible to enable TSAN in C1 compiler. I suppose there would not have patch delivery in the short term. >> Finally, thanks for your (your team's) pre-investigation and lots of common works on TSAN, which is a great work for >> the whole project and gives us great help. >> B&R >> Eric > >> Hi Arthur, >> >> Thanks for your review. >> >> We (@jhe33 @erik1iu ) will do more testing about TSAN recently, and also intend to spend some time to investigate if >> it's possible to enable TSAN in C1 compiler. I suppose there would not have patch delivery in the short term. >> Finally, thanks for your (your team's) pre-investigation and lots of common works on TSAN, which is a great work for >> the whole project and gives us great help. >> B&R >> Eric > > yes, it's really helpful for us, thanks @aeubanks @caoman. Internally we actually have an implementation of TSan for C1 that's based on JDK 8 but it's not really tested. The person who worked on it is no longer involved with the project, but it might be useful if we somehow create a patch containing those changes. ------------- PR: https://git.openjdk.java.net/tsan/pull/13 From manc at openjdk.java.net Fri May 29 18:43:16 2020 From: manc at openjdk.java.net (Man Cao) Date: Fri, 29 May 2020 18:43:16 GMT Subject: RFR: Enable array access instrumentation for aarch64 In-Reply-To: References: Message-ID: On Fri, 29 May 2020 04:09:57 GMT, Arthur Eubanks wrote: >>> Hi Arthur, >>> >>> Thanks for your review. >>> >>> We (@jhe33 @erik1iu ) will do more testing about TSAN recently, and also intend to spend some time to investigate if >>> it's possible to enable TSAN in C1 compiler. I suppose there would not have patch delivery in the short term. >>> Finally, thanks for your (your team's) pre-investigation and lots of common works on TSAN, which is a great work for >>> the whole project and gives us great help. >>> B&R >>> Eric >> >> yes, it's really helpful for us, thanks @aeubanks @caoman. > > Internally we actually have an implementation of TSan for C1 that's based on JDK 8 but it's not really tested. The > person who worked on it is no longer involved with the project, but it might be useful if we somehow create a patch > containing those changes. Great to see the tests are working! My apology on not having time to review recent commits. I'll take a closer look when I have time. ------------- PR: https://git.openjdk.java.net/tsan/pull/13