From Jie.He at arm.com Thu Jan 9 09:02:03 2020 From: Jie.He at arm.com (Jie He) Date: Thu, 9 Jan 2020 09:02:03 +0000 Subject: some questions about project tsan Message-ID: Hi I'm an engineer from ARM, and noticed this project is helpful to detect data race in Java level. I have some questions about this project: 1, how about the current status? All dev jobs have been finished already? 2, for detection of data race in Java code, I think current implementation only in X86 is enough. A data race in java code will be found whatever the machine platform is. So that, porting this project to AARCH64 is meaningless? Is it helpful to find some issues which don't happen in X86? 3, Is there a plan to add the support to detect data race in JVM self? E.g. add the instrumentation into the assemble code generated by interpreter, compiler and runtime, In some machine platforms which have weak memory model like arm and ppc, engineers often make mistakes when writing data race related code even though they are experienced. I think such a tool could help to detect these bugs easily than before. Thanks Jie He From aeubanks at google.com Thu Jan 9 17:21:24 2020 From: aeubanks at google.com (Arthur Eubanks) Date: Thu, 9 Jan 2020 09:21:24 -0800 Subject: some questions about project tsan In-Reply-To: References: Message-ID: On Thu, Jan 9, 2020 at 1:02 AM Jie He wrote: > Hi > > I'm an engineer from ARM, and noticed this project is helpful to detect > data race in Java level. > Thanks for the interest! > > I have some questions about this project: > > 1, how about the current status? All dev jobs have been finished already? > It works and we use this internally at Google. There should be no false positives reported, but not everything is precise and there are false negatives (e.g. final fields, finalizers, etc.). I believe the current implementation catches most races, which is good enough, and extra effort spent making instrumentation more precise would only find a couple more races, which may or may not be worth the effort. Ideally we'd like to upstream this into mainline. > 2, for detection of data race in Java code, I think current implementation > only in X86 is enough. A data race in java code will be found whatever the > machine platform is. > So that, porting this project to AARCH64 is meaningless? Is it helpful > to find some issues which don't happen in X86? > Yes a data race will likely be found on x86 and it would apply to AARCH64 as well. Porting to AARCH64 could still be interesting and useful for people who only have AARCH64 machines. And maybe running on different architectures will change the timing of concurrent execution, causing races to disappear or appear. > 3, Is there a plan to add the support to detect data race in JVM self? > E.g. add the instrumentation into the assemble code generated by > interpreter, compiler and runtime, > In some machine platforms which have weak memory model like arm and > ppc, engineers often make mistakes when writing data race related code even > though they are experienced. > I think such a tool could help to detect these bugs easily than before. > We've thought about this in the past, but there is a ton of intentionally racy code. You could try adding -fsanitize=thread to the hotspot compilations and running it just to see what would happen. > > Thanks > Jie He > From Jie.He at arm.com Fri Jan 10 02:12:24 2020 From: Jie.He at arm.com (Jie He) Date: Fri, 10 Jan 2020 02:12:24 +0000 Subject: some questions about project tsan In-Reply-To: References: Message-ID: Hi Arthur Thanks for your reply. I will let you know If we start to add the AARCH64 support. Before that, I still have to do some investigation about the feasibility of tsan for JVM. Anyway, thank u. B.R Jie He From: Arthur Eubanks Sent: Friday, January 10, 2020 1:21 AM To: Jie He Cc: tsan-dev at openjdk.java.net; nd Subject: Re: some questions about project tsan On Thu, Jan 9, 2020 at 1:02 AM Jie He > wrote: Hi I'm an engineer from ARM, and noticed this project is helpful to detect data race in Java level. Thanks for the interest! I have some questions about this project: 1, how about the current status? All dev jobs have been finished already? It works and we use this internally at Google. There should be no false positives reported, but not everything is precise and there are false negatives (e.g. final fields, finalizers, etc.). I believe the current implementation catches most races, which is good enough, and extra effort spent making instrumentation more precise would only find a couple more races, which may or may not be worth the effort. Ideally we'd like to upstream this into mainline. 2, for detection of data race in Java code, I think current implementation only in X86 is enough. A data race in java code will be found whatever the machine platform is. So that, porting this project to AARCH64 is meaningless? Is it helpful to find some issues which don't happen in X86? Yes a data race will likely be found on x86 and it would apply to AARCH64 as well. Porting to AARCH64 could still be interesting and useful for people who only have AARCH64 machines. And maybe running on different architectures will change the timing of concurrent execution, causing races to disappear or appear. 3, Is there a plan to add the support to detect data race in JVM self? E.g. add the instrumentation into the assemble code generated by interpreter, compiler and runtime, In some machine platforms which have weak memory model like arm and ppc, engineers often make mistakes when writing data race related code even though they are experienced. I think such a tool could help to detect these bugs easily than before. We've thought about this in the past, but there is a ton of intentionally racy code. You could try adding -fsanitize=thread to the hotspot compilations and running it just to see what would happen. Thanks Jie He