From jcbeyler at google.com Thu Mar 14 03:17:17 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Wed, 13 Mar 2019 20:17:17 -0700 Subject: How to integrate Tsan with OpenJDK Message-ID: Florian Weimer said in https://mail.openjdk.java.net/pipermail/discuss/2019-March/005007.html: "If OpenJDK starts to poke at libc internals, like the sanitizers do today, OpenJDK will potentially need porting to each new libc version. You will not be able to run older OpenJDK versions on newer libcs, as it is possible today. It will likely make it more complicated to build binaries which are compatible with a wide range of systems. This is what we see with the sanitizers in LLVM and GCC today. If you copy a variant of this code into OpenJDK, you will have the same problem." The conversation here is: - How do we distribute OpenJDK with a TSAN implementation? - What does that look like? - What restrictions/promises to users should we make? What should we not make as promises? I have no answers to these (though I have opinions :-)); I open the floor to others who would want to talk/think about these issues... Thanks, Jc From fweimer at redhat.com Thu Mar 14 12:41:25 2019 From: fweimer at redhat.com (Florian Weimer) Date: Thu, 14 Mar 2019 13:41:25 +0100 Subject: How to integrate Tsan with OpenJDK In-Reply-To: (Jean Christophe Beyler's message of "Wed, 13 Mar 2019 20:17:17 -0700") References: Message-ID: <875zsl7hmy.fsf@oldenburg2.str.redhat.com> * Jean Christophe Beyler: > Florian Weimer said in > https://mail.openjdk.java.net/pipermail/discuss/2019-March/005007.html: > > "If OpenJDK starts to poke at libc internals, like the sanitizers do today, OpenJDK will > potentially need porting to each new libc version. > > You will not be able to run older OpenJDK versions on newer libcs, as it is possible today. > > It will likely make it more complicated to build binaries which are compatible with a wide > range of systems. > > This is what we see with the sanitizers in LLVM and GCC today. If you copy a variant of this > code into OpenJDK, you will have the same problem." > > The conversation here is: > - How do we distribute OpenJDK with a TSAN implementation? > - What does that look like? > - What restrictions/promises to users should we make? What should we not make as > promises? > > I have no answers to these (though I have opinions :-)); I open the > floor to others who would want to talk/think about these issues... I should point out that this only applies to the native TSAN code with its interceptors. I don't know if there's a plan to support tracking across JNI boundaries and integrate with the native TSAN. If the plan is integration with native TSAN, it could be an opportunity to clean this up (finally). Thanks, Florian From jcbeyler at google.com Fri Mar 15 02:33:33 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Thu, 14 Mar 2019 19:33:33 -0700 Subject: Branches for development Message-ID: Hi all, I was thinking about the branches we should use for development. One branch should be a mirror of jdk/jdk. I don't know if that has to be the default branch (or is it just a convention?). Potentially, I would do this: - default: is the mirror of jdk/jdk and other branches are based off of that one - unstable: would be where all our development goes - stable: would be any moment we feel we got some sub-feature complete and are have related examples that now work, etc. I would not open the stable just yes evidently but would open the unstable one for our development. On the other hand, I could see it the other way around and have: - default: is our unstable branch where our development goes - mirror: would be the jdk/jdk mirror - stable: would then become our stable release branch when we have something to show case. Opinions? And question: - Must we have default as the mirror of jdk/jdk or could it be an arbitrary branch name? Thanks! Jc From jcbeyler at google.com Fri Mar 15 03:12:40 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Thu, 14 Mar 2019 20:12:40 -0700 Subject: How to integrate Tsan with OpenJDK In-Reply-To: <875zsl7hmy.fsf@oldenburg2.str.redhat.com> References: <875zsl7hmy.fsf@oldenburg2.str.redhat.com> Message-ID: Hi Florian, I admit my lack of expertise in distribution problems and you do evidently raise a good question of how could we package/implement the TSAN portion to be use-able by OpenJDK distributors and also by users who just build everything from scratch. - I would imagine that there might/should be a means to check at runtime if the libc you've been built with is the same as the one on the OS you are running with - But that might be too restrictive, complicated - I could imagine the distribution could also potentially keep a tsan library in sync by then just having everything as a dynamic library? Loading and setting up interceptors might be interesting :) - Do you have any ideas on how this could work from a distribution perspective? We are far far away from facing this issue but having an idea of a path forward is always good to have so I'm happy that we are talking about it now :). For what it is worth, my current first step was to get us to have a java_tsan library that is built as a separate launcher and loads up the tsan library somehow and then just works. And for what it is worth, though our internal implementation does do native TSAN, it is not an automatic first goal of this work, preferring to stay only in Java land. Though it is a nice stretch goal to have as we have seen it being useful for our users, Jc On Thu, Mar 14, 2019 at 5:41 AM Florian Weimer wrote: > * Jean Christophe Beyler: > > > Florian Weimer said in > > https://mail.openjdk.java.net/pipermail/discuss/2019-March/005007.html: > > > > "If OpenJDK starts to poke at libc internals, like the sanitizers do > today, OpenJDK will > > potentially need porting to each new libc version. > > > > You will not be able to run older OpenJDK versions on newer libcs, as it > is possible today. > > > > It will likely make it more complicated to build binaries which are > compatible with a wide > > range of systems. > > > > This is what we see with the sanitizers in LLVM and GCC today. If you > copy a variant of this > > code into OpenJDK, you will have the same problem." > > > > The conversation here is: > > - How do we distribute OpenJDK with a TSAN implementation? > > - What does that look like? > > - What restrictions/promises to users should we make? What should we > not make as > > promises? > > > > I have no answers to these (though I have opinions :-)); I open the > > floor to others who would want to talk/think about these issues... > > I should point out that this only applies to the native TSAN code with > its interceptors. I don't know if there's a plan to support tracking > across JNI boundaries and integrate with the native TSAN. > > If the plan is integration with native TSAN, it could be an opportunity > to clean this up (finally). > > Thanks, > Florian > -- Thanks, Jc From manc at google.com Fri Mar 15 20:40:19 2019 From: manc at google.com (Man Cao) Date: Fri, 15 Mar 2019 13:40:19 -0700 Subject: Branches for development In-Reply-To: References: Message-ID: I'd vote to be consistent with other projects such as Loom or Valhalla, that "default" is the mirror of jdk/jdk. Being consistent would at least avoid confusion when contributors from other projects participate in the tsan project. And there might be a technical reason that we are unaware of, e.g., using "default" as the mirror might ease the merge process somehow. Is there a reason why "mirror" as the mirror and "default" as the development branch is superior to the other way round? For "stable" and "unstable", it might be better that we start off with just one development branch ("dev" or "tsan" are better names than "unstable", IMO), and when there's a need to demonstrate something, we fork a "stable-[timestamp]" branch if we feel it's necessary. Maintaining two ongoing branches requires extra work for merging and porting, which is likely troublesome. -Man From jcbeyler at google.com Fri Mar 15 20:48:56 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Fri, 15 Mar 2019 13:48:56 -0700 Subject: Branches for development In-Reply-To: References: Message-ID: I believe that when you clone the repo, you are set to be in default by "default". Therefore committers will have to ensure care and self-preservation to not be pushing to it. Using a different name than "default" for the mirror branch would alleviate that. But I agree consistency is important so I'll also vote on: - default: mirror of jdk/jdk - tsan: main development branch for tsan Anyone else have an opinion on this? Jc On Fri, Mar 15, 2019 at 1:41 PM Man Cao wrote: > I'd vote to be consistent with other projects such as Loom or Valhalla, > that "default" is the mirror of jdk/jdk. > Being consistent would at least avoid confusion when contributors from > other projects participate in the tsan project. And there might be a > technical reason that we are unaware of, e.g., using "default" as the > mirror might ease the merge process somehow. > Is there a reason why "mirror" as the mirror and "default" as the > development branch is superior to the other way round? > > For "stable" and "unstable", it might be better that we start off with just > one development branch ("dev" or "tsan" are better names than "unstable", > IMO), and when there's a need to demonstrate something, we fork a > "stable-[timestamp]" branch if we feel it's necessary. > Maintaining two ongoing branches requires extra work for merging and > porting, which is likely troublesome. > > -Man > -- Thanks, Jc From serguei.spitsyn at oracle.com Fri Mar 15 20:52:45 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 15 Mar 2019 13:52:45 -0700 Subject: Branches for development In-Reply-To: References: Message-ID: Hi Jc, Yes, it looks most reasonable to me. Thanks, Serguei On 3/15/19 1:48 PM, Jean Christophe Beyler wrote: > I believe that when you clone the repo, you are set to be in default by > "default". Therefore committers will have to ensure care and > self-preservation to not be pushing to it. > > Using a different name than "default" for the mirror branch would alleviate > that. > > But I agree consistency is important so I'll also vote on: > > - default: mirror of jdk/jdk > - tsan: main development branch for tsan > > Anyone else have an opinion on this? > Jc > > On Fri, Mar 15, 2019 at 1:41 PM Man Cao wrote: > >> I'd vote to be consistent with other projects such as Loom or Valhalla, >> that "default" is the mirror of jdk/jdk. >> Being consistent would at least avoid confusion when contributors from >> other projects participate in the tsan project. And there might be a >> technical reason that we are unaware of, e.g., using "default" as the >> mirror might ease the merge process somehow. >> Is there a reason why "mirror" as the mirror and "default" as the >> development branch is superior to the other way round? >> >> For "stable" and "unstable", it might be better that we start off with just >> one development branch ("dev" or "tsan" are better names than "unstable", >> IMO), and when there's a need to demonstrate something, we fork a >> "stable-[timestamp]" branch if we feel it's necessary. >> Maintaining two ongoing branches requires extra work for merging and >> porting, which is likely troublesome. >> >> -Man >> > From jcbeyler at google.com Mon Mar 18 16:36:57 2019 From: jcbeyler at google.com (jcbeyler at google.com) Date: Mon, 18 Mar 2019 16:36:57 +0000 Subject: hg: tsan/dev: 43 new changesets Message-ID: <201903181637.x2IGb0EX001754@aojmv0008.oracle.com> Changeset: 943cfab99051 Author: jjg Date: 2019-03-14 13:33 -0700 URL: http://hg.openjdk.java.net/tsan/dev/rev/943cfab99051 8219691: method summary table head should be enclosed in Reviewed-by: jjg Contributed-by: dthomson at google.com ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlTag.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/Table.java ! test/langtools/jdk/javadoc/doclet/testDeprecatedDocs/TestDeprecatedDocs.java ! test/langtools/jdk/javadoc/doclet/testJavaFX/TestJavaFX.java ! test/langtools/jdk/javadoc/doclet/testModules/TestIndirectExportsOpens.java ! test/langtools/jdk/javadoc/doclet/testModules/TestModuleServices.java ! test/langtools/jdk/javadoc/doclet/testModules/TestModules.java ! test/langtools/jdk/javadoc/doclet/testNewLanguageFeatures/TestNewLanguageFeatures.java ! test/langtools/jdk/javadoc/doclet/testPackagePage/TestPackagePage.java ! test/langtools/jdk/javadoc/doclet/testSearch/TestSearch.java ! test/langtools/jdk/javadoc/doclet/testUnnamedPackage/TestUnnamedPackage.java Changeset: b70c65a946a0 Author: ngasson Date: 2019-03-14 14:25 -0700 URL: http://hg.openjdk.java.net/tsan/dev/rev/b70c65a946a0 8219628: [TESTBUG] javadoc/doclet/InheritDocForUserTags fails with -othervm Reviewed-by: jjg, clanger ! test/langtools/jdk/javadoc/doclet/InheritDocForUserTags/DocTest.java ! test/langtools/jdk/javadoc/lib/javadoc/tester/JavadocTester.java Changeset: b6134b6d75ff Author: jjg Date: 2019-03-14 15:30 -0700 URL: http://hg.openjdk.java.net/tsan/dev/rev/b6134b6d75ff 8220249: fix headings in java.compiler Reviewed-by: erikj, darcy ! make/CompileJavaModules.gmk ! src/java.compiler/share/classes/javax/annotation/processing/Generated.java Changeset: 8a66c92526cb Author: iignatyev Date: 2019-03-14 16:17 -0700 URL: http://hg.openjdk.java.net/tsan/dev/rev/8a66c92526cb 8220689: problem list RandomCommandsTest in graal runs Reviewed-by: kvn ! test/hotspot/jtreg/ProblemList-graal.txt Changeset: 421b47214391 Author: dtitov Date: 2019-03-14 16:28 -0700 URL: http://hg.openjdk.java.net/tsan/dev/rev/421b47214391 8218812: vmTestbase/nsk/jvmti/GetAllThreads/allthr001/TestDescription.java failed Reviewed-by: dlong, sspitsyn, jcbeyler ! test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_tools.cpp Changeset: 6ab293f66cae Author: iignatyev Date: 2019-03-14 19:37 -0700 URL: http://hg.openjdk.java.net/tsan/dev/rev/6ab293f66cae 8219139: move hotspot tests from test/jdk/vm Reviewed-by: dholmes, mseledtsov + test/hotspot/jtreg/compiler/codegen/BadLogicCode.java + test/hotspot/jtreg/compiler/codegen/ShiftTest.java + test/hotspot/jtreg/compiler/exceptions/ExceptionInInit.java + test/hotspot/jtreg/compiler/runtime/JITClassInit.java + test/hotspot/jtreg/gc/ArraySize.java + test/hotspot/jtreg/gc/InfiniteList.java + test/hotspot/jtreg/runtime/ErrorHandling/ExplicitArithmeticCheck.java + test/hotspot/jtreg/runtime/Thread/MonitorCacheMaybeExpand_DeadLock.java + test/hotspot/jtreg/runtime/interpreter/WideStrictInline.java + test/hotspot/jtreg/runtime/reflect/ReflectStackOverflow.java + test/hotspot/jtreg/runtime/verifier/TestStaticIF.java + test/hotspot/jtreg/runtime/verifier/VerifyProtectedConstructor.java + test/hotspot/jtreg/runtime/verifier/VerifyStackForExceptionHandlers.java + test/hotspot/jtreg/runtime/verifier/defaultMethods/DefaultMethodRegressionTests.java + test/hotspot/jtreg/runtime/verifier/defaultMethods/DefaultMethodRegressionTestsRun.java ! test/jdk/TEST.groups + test/jdk/tools/launcher/JniInvocationTest.java + test/jdk/tools/launcher/exeJniInvocationTest.c - test/jdk/vm/JniInvocationTest.java - test/jdk/vm/exeJniInvocationTest.c - test/jdk/vm/gc/ArraySize.java - test/jdk/vm/gc/InfiniteList.java - test/jdk/vm/jit/BadLogicCode.java - test/jdk/vm/jit/ExceptionInInit.java - test/jdk/vm/jit/JITClassInit.java - test/jdk/vm/runtime/ExplicitArithmeticCheck.java - test/jdk/vm/runtime/MonitorCacheMaybeExpand_DeadLock.java - test/jdk/vm/runtime/ReflectStackOverflow.java - test/jdk/vm/runtime/ShiftTest.java - test/jdk/vm/runtime/WideStrictInline.java - test/jdk/vm/verifier/TestStaticIF.java - test/jdk/vm/verifier/VerifyProtectedConstructor.java - test/jdk/vm/verifier/VerifyStackForExceptionHandlers.java - test/jdk/vm/verifier/defaultMethods/DefaultMethodRegressionTests.java - test/jdk/vm/verifier/defaultMethods/DefaultMethodRegressionTestsRun.java Changeset: 8ff8b3734549 Author: thartmann Date: 2019-03-15 08:27 +0100 URL: http://hg.openjdk.java.net/tsan/dev/rev/8ff8b3734549 8220611: compiler/classUnloading/methodUnloading/TestOverloadCompileQueues.java timeout Summary: Test should not be executed with Graal as JIT. Reviewed-by: kvn ! test/hotspot/jtreg/compiler/classUnloading/methodUnloading/TestOverloadCompileQueues.java Changeset: fb7a1fdeaea7 Author: gadams Date: 2019-03-15 06:16 -0400 URL: http://hg.openjdk.java.net/tsan/dev/rev/fb7a1fdeaea7 8220678: unquarantine nsk/jdi/ThreadReference/setEnabled/setenabled003 Reviewed-by: cjplummer, sspitsyn ! test/hotspot/jtreg/ProblemList.txt Changeset: 6f14d52d5e10 Author: shade Date: 2019-03-15 13:01 +0100 URL: http://hg.openjdk.java.net/tsan/dev/rev/6f14d52d5e10 8220712: [TESTBUG] gc/shenandoah/compiler/TestMaybeNullUnsafeAccess should run with Shenandoah enabled Reviewed-by: rkennke, roland ! test/hotspot/jtreg/gc/shenandoah/compiler/TestMaybeNullUnsafeAccess.java Changeset: 81605c74b980 Author: chegar Date: 2019-03-15 14:50 +0000 URL: http://hg.openjdk.java.net/tsan/dev/rev/81605c74b980 8179549: Typo in network properties documentation Reviewed-by: clanger, coffeys ! src/java.base/share/classes/java/net/doc-files/net-properties.html Changeset: 8f91e1a7ebdc Author: chegar Date: 2019-03-15 14:54 +0000 URL: http://hg.openjdk.java.net/tsan/dev/rev/8f91e1a7ebdc 8213912: Semantic typo in HttpExchange.java Reviewed-by: dfuchs ! src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpExchange.java Changeset: 62e4ada7c4c8 Author: erikj Date: 2019-03-15 09:13 -0700 URL: http://hg.openjdk.java.net/tsan/dev/rev/62e4ada7c4c8 8220093: Change to GCC 8.2 for building on Linux at Oracle Reviewed-by: tbell ! make/autoconf/toolchain.m4 ! make/conf/jib-profiles.js ! make/devkit/Makefile + make/devkit/Tars.gmk ! make/devkit/Tools.gmk Changeset: c61f09122d3b Author: jwilhelm Date: 2019-03-15 18:59 +0100 URL: http://hg.openjdk.java.net/tsan/dev/rev/c61f09122d3b 8220704: ZGC: gc tests complain Java heap too small Reviewed-by: iignatyev, tschatzl ! test/hotspot/jtreg/gc/ArraySize.java ! test/hotspot/jtreg/gc/InfiniteList.java Changeset: 5529640c5f67 Author: coleenp Date: 2019-03-15 16:00 -0400 URL: http://hg.openjdk.java.net/tsan/dev/rev/5529640c5f67 8220512: Deoptimize redefinition functions that have dirty ICs Summary: Walk ICs to determine whether nmethods are dependent on redefined classes. Reviewed-by: sspitsyn, eosterlund ! src/hotspot/share/aot/aotCodeHeap.cpp ! src/hotspot/share/aot/aotCodeHeap.hpp ! src/hotspot/share/aot/aotCompiledMethod.cpp ! src/hotspot/share/aot/aotCompiledMethod.hpp ! src/hotspot/share/aot/aotLoader.cpp ! src/hotspot/share/aot/aotLoader.hpp ! src/hotspot/share/ci/ciEnv.hpp ! src/hotspot/share/ci/ciObjectFactory.cpp ! src/hotspot/share/ci/ciObjectFactory.hpp ! src/hotspot/share/classfile/metadataOnStackMark.cpp ! src/hotspot/share/code/codeCache.cpp ! src/hotspot/share/code/codeCache.hpp ! src/hotspot/share/code/compiledMethod.cpp ! src/hotspot/share/code/compiledMethod.hpp ! src/hotspot/share/code/nmethod.cpp ! src/hotspot/share/code/nmethod.hpp ! src/hotspot/share/compiler/compileTask.cpp ! src/hotspot/share/compiler/compileTask.hpp ! src/hotspot/share/memory/iterator.hpp ! src/hotspot/share/runtime/frame.cpp ! src/hotspot/share/runtime/frame.hpp ! src/hotspot/share/runtime/thread.cpp ! src/hotspot/share/runtime/thread.hpp Changeset: d2f8b7b33013 Author: bpb Date: 2019-03-15 16:24 -0700 URL: http://hg.openjdk.java.net/tsan/dev/rev/d2f8b7b33013 8219876: (bf) Improve IndexOutOfBoundsException messages in $Type$Buffer classes Reviewed-by: alanb, rriggs ! src/java.base/share/classes/java/nio/Buffer.java ! src/java.base/share/classes/java/nio/ByteBufferAs-X-Buffer.java.template ! src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template ! src/java.base/share/classes/java/nio/Heap-X-Buffer.java.template ! src/java.base/share/classes/java/nio/StringCharBuffer.java ! src/java.base/share/classes/java/nio/X-Buffer.java.template Changeset: 5274462d5725 Author: jwilhelm Date: 2019-03-16 02:08 +0100 URL: http://hg.openjdk.java.net/tsan/dev/rev/5274462d5725 8220745: Fix problemlist entry to refer to 8220613 Reviewed-by: dcubed ! test/jdk/ProblemList.txt Changeset: 4985c8ca55b9 Author: ysuenaga Date: 2019-03-16 21:27 +0900 URL: http://hg.openjdk.java.net/tsan/dev/rev/4985c8ca55b9 8220555: JFR tool shows potentially misleading message when it cannot access a file Reviewed-by: egahlin, mseledtsov ! src/jdk.jfr/share/classes/jdk/jfr/internal/tool/Command.java ! test/jdk/jdk/jfr/tool/TestPrint.java Changeset: 1caf2daef7cf Author: alanb Date: 2019-03-16 12:31 +0000 URL: http://hg.openjdk.java.net/tsan/dev/rev/1caf2daef7cf 8220738: (sc) Move ServerSocketChannelImpl remaining native method to Net Reviewed-by: bpb ! src/java.base/share/classes/sun/nio/ch/Net.java ! src/java.base/share/classes/sun/nio/ch/ServerSocketChannelImpl.java ! src/java.base/unix/classes/sun/nio/ch/UnixAsynchronousServerSocketChannelImpl.java ! src/java.base/unix/native/libnio/ch/IOUtil.c ! src/java.base/unix/native/libnio/ch/Net.c - src/java.base/unix/native/libnio/ch/ServerSocketChannelImpl.c - src/java.base/unix/native/libnio/ch/UnixAsynchronousServerSocketChannelImpl.c ! src/java.base/unix/native/libnio/ch/nio_util.h ! src/java.base/windows/native/libnio/ch/IOUtil.c ! src/java.base/windows/native/libnio/ch/Net.c - src/java.base/windows/native/libnio/ch/ServerSocketChannelImpl.c ! src/java.base/windows/native/libnio/ch/nio_util.h ! src/jdk.sctp/unix/classes/sun/nio/ch/sctp/SctpServerChannelImpl.java - src/jdk.sctp/unix/native/libsctp/SctpServerChannelImpl.c ! test/jdk/com/sun/nio/sctp/SctpMultiChannel/SendFailed.java Changeset: b5a73f22b2bd Author: alanb Date: 2019-03-16 19:44 +0000 URL: http://hg.openjdk.java.net/tsan/dev/rev/b5a73f22b2bd 8220493: Prepare Socket/ServerSocket for alternative platform SocketImpl Reviewed-by: chegar Contributed-by: alan.bateman at oracle.com, michael.x.mcmahon at oracle.com ! src/java.base/share/classes/java/net/AbstractPlainSocketImpl.java + src/java.base/share/classes/java/net/DelegatingSocketImpl.java ! src/java.base/share/classes/java/net/HttpConnectSocketImpl.java ! src/java.base/share/classes/java/net/ServerSocket.java ! src/java.base/share/classes/java/net/Socket.java ! src/java.base/share/classes/java/net/SocketImpl.java ! src/java.base/share/classes/java/net/SocksSocketImpl.java + src/java.base/share/classes/sun/net/PlatformSocketImpl.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/instrument/SocketInputStreamInstrumentor.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/instrument/SocketOutputStreamInstrumentor.java + test/jdk/java/net/SocketImpl/SocketImplCombinations.java ! test/jdk/jdk/jfr/event/io/TestInstrumentation.java Changeset: 56e9781e6044 Author: igerasim Date: 2019-03-16 13:44 -0700 URL: http://hg.openjdk.java.net/tsan/dev/rev/56e9781e6044 6307456: UnixFileSystem_md.c use of chmod() and access() should handle EINTR signal appropriately (unix) Reviewed-by: bpb, dholmes, alanb ! src/java.base/unix/native/libjava/UnixFileSystem_md.c ! src/java.base/unix/native/libjava/io_util_md.h Changeset: 1a18b8d56d73 Author: igerasim Date: 2019-03-16 15:05 -0700 URL: http://hg.openjdk.java.net/tsan/dev/rev/1a18b8d56d73 8220684: Process.waitFor(long, TimeUnit) can return false for a process that exited within the timeout Reviewed-by: prappo, dholmes, rriggs ! src/java.base/share/classes/java/lang/Process.java + test/jdk/java/lang/Process/WaitFor.java Changeset: 5e1480a38a43 Author: chegar Date: 2019-03-17 08:26 +0000 URL: http://hg.openjdk.java.net/tsan/dev/rev/5e1480a38a43 8220719: Allow other named NetPermissions to be used Reviewed-by: mullan, alanb ! src/java.base/share/classes/java/net/NetPermission.java Changeset: 7c23a4432610 Author: pliden Date: 2019-03-18 11:50 +0100 URL: http://hg.openjdk.java.net/tsan/dev/rev/7c23a4432610 8220569: ZGC: Rename and rework ZUnmapBadViews to ZVerifyViews Reviewed-by: stefank, eosterlund ! src/hotspot/os_cpu/linux_x86/gc/z/zPhysicalMemoryBacking_linux_x86.cpp ! src/hotspot/os_cpu/linux_x86/gc/z/zPhysicalMemoryBacking_linux_x86.hpp ! src/hotspot/share/gc/z/zHeap.cpp ! src/hotspot/share/gc/z/zHeap.hpp ! src/hotspot/share/gc/z/zPageAllocator.cpp ! src/hotspot/share/gc/z/zPageAllocator.hpp ! src/hotspot/share/gc/z/zPhysicalMemory.cpp ! src/hotspot/share/gc/z/zPhysicalMemory.hpp ! src/hotspot/share/gc/z/z_globals.hpp ! test/hotspot/jtreg/compiler/gcbarriers/UnsafeIntrinsicsTest.java Changeset: 759a63069fac Author: pliden Date: 2019-03-18 11:50 +0100 URL: http://hg.openjdk.java.net/tsan/dev/rev/759a63069fac 8220741: ZGC: Move CPU agnostic files from linux_x86 to linux Reviewed-by: stefank, eosterlund + src/hotspot/os/linux/gc/z/zLargePages_linux.cpp + src/hotspot/os/linux/gc/z/zNUMA_linux.cpp + src/hotspot/os/linux/gc/z/zVirtualMemory_linux.cpp - src/hotspot/os_cpu/linux_x86/gc/z/zLargePages_linux_x86.cpp - src/hotspot/os_cpu/linux_x86/gc/z/zNUMA_linux_x86.cpp - src/hotspot/os_cpu/linux_x86/gc/z/zVirtualMemory_linux_x86.cpp Changeset: 349843ebb209 Author: pliden Date: 2019-03-18 11:50 +0100 URL: http://hg.openjdk.java.net/tsan/dev/rev/349843ebb209 8220586: ZGC: Move relocation logic from ZPage to ZRelocate Reviewed-by: stefank, eosterlund ! src/hotspot/share/gc/z/zHeap.cpp ! src/hotspot/share/gc/z/zPage.cpp ! src/hotspot/share/gc/z/zPage.hpp ! src/hotspot/share/gc/z/zPage.inline.hpp ! src/hotspot/share/gc/z/zRelocate.cpp ! src/hotspot/share/gc/z/zRelocate.hpp Changeset: f344a0c6e19e Author: pliden Date: 2019-03-18 11:50 +0100 URL: http://hg.openjdk.java.net/tsan/dev/rev/f344a0c6e19e 8220587: ZGC: Break out forwarding information from ZPage Reviewed-by: stefank, eosterlund ! src/hotspot/share/gc/z/vmStructs_z.hpp ! src/hotspot/share/gc/z/zBarrier.cpp + src/hotspot/share/gc/z/zForwarding.cpp + src/hotspot/share/gc/z/zForwarding.hpp + src/hotspot/share/gc/z/zForwarding.inline.hpp + src/hotspot/share/gc/z/zForwardingEntry.hpp ! src/hotspot/share/gc/z/zForwardingTable.cpp ! src/hotspot/share/gc/z/zForwardingTable.hpp ! src/hotspot/share/gc/z/zForwardingTable.inline.hpp - src/hotspot/share/gc/z/zForwardingTableEntry.hpp ! src/hotspot/share/gc/z/zGranuleMap.hpp ! src/hotspot/share/gc/z/zGranuleMap.inline.hpp ! src/hotspot/share/gc/z/zHeap.cpp ! src/hotspot/share/gc/z/zHeap.hpp ! src/hotspot/share/gc/z/zHeap.inline.hpp ! src/hotspot/share/gc/z/zPage.cpp ! src/hotspot/share/gc/z/zPage.hpp ! src/hotspot/share/gc/z/zPage.inline.hpp ! src/hotspot/share/gc/z/zPageAllocator.cpp ! src/hotspot/share/gc/z/zPageCache.cpp ! src/hotspot/share/gc/z/zRelocate.cpp ! src/hotspot/share/gc/z/zRelocate.hpp + test/hotspot/gtest/gc/z/test_zForwarding.cpp - test/hotspot/gtest/gc/z/test_zForwardingTable.cpp ! test/hotspot/jtreg/ProblemList-zgc.txt Changeset: 790679f86a51 Author: pliden Date: 2019-03-18 11:50 +0100 URL: http://hg.openjdk.java.net/tsan/dev/rev/790679f86a51 8220588: ZGC: Convert ZRelocationSet to hold ZForwardings instead of ZPages Reviewed-by: stefank, eosterlund ! src/hotspot/share/gc/z/zDriver.cpp ! src/hotspot/share/gc/z/zDriver.hpp ! src/hotspot/share/gc/z/zForwarding.cpp ! src/hotspot/share/gc/z/zForwarding.hpp ! src/hotspot/share/gc/z/zForwarding.inline.hpp ! src/hotspot/share/gc/z/zForwardingTable.cpp ! src/hotspot/share/gc/z/zForwardingTable.hpp ! src/hotspot/share/gc/z/zHeap.cpp ! src/hotspot/share/gc/z/zHeap.hpp ! src/hotspot/share/gc/z/zHeap.inline.hpp ! src/hotspot/share/gc/z/zRelocate.cpp ! src/hotspot/share/gc/z/zRelocationSet.cpp ! src/hotspot/share/gc/z/zRelocationSet.hpp ! src/hotspot/share/gc/z/zRelocationSet.inline.hpp ! src/hotspot/share/gc/z/zRelocationSetSelector.cpp ! src/hotspot/share/gc/z/zRelocationSetSelector.hpp ! test/hotspot/gtest/gc/z/test_zForwarding.cpp Changeset: c585ef187216 Author: pliden Date: 2019-03-18 11:50 +0100 URL: http://hg.openjdk.java.net/tsan/dev/rev/c585ef187216 8220589: ZGC: Remove superfluous ZPageTableEntry Reviewed-by: stefank, eosterlund ! src/hotspot/share/gc/z/vmStructs_z.hpp ! src/hotspot/share/gc/z/zDebug.gdb ! src/hotspot/share/gc/z/zHeap.cpp ! src/hotspot/share/gc/z/zHeap.hpp ! src/hotspot/share/gc/z/zHeap.inline.hpp ! src/hotspot/share/gc/z/zMark.cpp ! src/hotspot/share/gc/z/zMark.hpp ! src/hotspot/share/gc/z/zPageTable.cpp ! src/hotspot/share/gc/z/zPageTable.hpp ! src/hotspot/share/gc/z/zPageTable.inline.hpp - src/hotspot/share/gc/z/zPageTableEntry.hpp ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZHeap.java Changeset: 84295bd6d359 Author: pliden Date: 2019-03-18 11:50 +0100 URL: http://hg.openjdk.java.net/tsan/dev/rev/84295bd6d359 8220590: ZGC: Remove ZPages from ZPageTable when freed Reviewed-by: stefank, eosterlund ! src/hotspot/share/gc/z/zHeap.cpp ! src/hotspot/share/gc/z/zPageTable.cpp Changeset: b9f030844be4 Author: pliden Date: 2019-03-18 11:50 +0100 URL: http://hg.openjdk.java.net/tsan/dev/rev/b9f030844be4 8220591: ZGC: Don't delay reclaimation of ZVirtualMemory Reviewed-by: stefank, eosterlund ! src/hotspot/share/gc/z/zPageAllocator.cpp Changeset: d0d26fc836dd Author: pliden Date: 2019-03-18 11:50 +0100 URL: http://hg.openjdk.java.net/tsan/dev/rev/d0d26fc836dd 8220592: ZGC: Move destruction of detached ZPages into ZPageAllocator Reviewed-by: stefank, eosterlund ! src/hotspot/share/gc/z/zHeap.cpp ! src/hotspot/share/gc/z/zPageAllocator.cpp ! src/hotspot/share/gc/z/zPageAllocator.hpp Changeset: eb54b34af2be Author: pliden Date: 2019-03-18 11:50 +0100 URL: http://hg.openjdk.java.net/tsan/dev/rev/eb54b34af2be 8220593: ZGC: Remove superfluous ZPage::is_detached() Reviewed-by: stefank, eosterlund ! src/hotspot/share/gc/z/zHeap.cpp ! src/hotspot/share/gc/z/zPage.cpp ! src/hotspot/share/gc/z/zPage.hpp ! src/hotspot/share/gc/z/zPage.inline.hpp ! src/hotspot/share/gc/z/zPageCache.cpp Changeset: 5748eae24183 Author: pliden Date: 2019-03-18 11:50 +0100 URL: http://hg.openjdk.java.net/tsan/dev/rev/5748eae24183 8220594: ZGC: Remove superfluous ZPage::is_active() Reviewed-by: stefank, eosterlund ! src/hotspot/share/gc/z/zPage.cpp ! src/hotspot/share/gc/z/zPage.hpp ! src/hotspot/share/gc/z/zPage.inline.hpp ! src/hotspot/share/gc/z/zPageAllocator.cpp ! src/hotspot/share/gc/z/zPageCache.cpp ! test/hotspot/gtest/gc/z/test_zForwarding.cpp Changeset: 8f1771ea1e39 Author: pliden Date: 2019-03-18 11:50 +0100 URL: http://hg.openjdk.java.net/tsan/dev/rev/8f1771ea1e39 8220595: ZGC: Introduce ZAttachedArray Reviewed-by: stefank, eosterlund + src/hotspot/share/gc/z/zAttachedArray.hpp + src/hotspot/share/gc/z/zAttachedArray.inline.hpp Changeset: 07943af21b96 Author: pliden Date: 2019-03-18 11:50 +0100 URL: http://hg.openjdk.java.net/tsan/dev/rev/07943af21b96 8220596: ZGC: Convert ZNMethodData to use ZAttachedArray Reviewed-by: stefank, eosterlund ! src/hotspot/share/gc/z/zNMethodData.cpp ! src/hotspot/share/gc/z/zNMethodData.hpp Changeset: f92f1f1045ad Author: pliden Date: 2019-03-18 11:50 +0100 URL: http://hg.openjdk.java.net/tsan/dev/rev/f92f1f1045ad 8220597: ZGC: Convert ZForwarding to use ZAttachedArray Reviewed-by: stefank, eosterlund ! src/hotspot/share/gc/z/vmStructs_z.hpp ! src/hotspot/share/gc/z/zForwarding.cpp ! src/hotspot/share/gc/z/zForwarding.hpp ! src/hotspot/share/gc/z/zForwarding.inline.hpp ! test/hotspot/gtest/gc/z/test_zForwarding.cpp Changeset: e6a92f2f37a9 Author: pliden Date: 2019-03-18 11:50 +0100 URL: http://hg.openjdk.java.net/tsan/dev/rev/e6a92f2f37a9 8220599: ZGC: Introduce ZSafeDelete Reviewed-by: stefank, eosterlund ! src/hotspot/share/gc/z/zArray.hpp ! src/hotspot/share/gc/z/zArray.inline.hpp + src/hotspot/share/gc/z/zSafeDelete.hpp + src/hotspot/share/gc/z/zSafeDelete.inline.hpp Changeset: 6d1caebf8d37 Author: pliden Date: 2019-03-18 11:50 +0100 URL: http://hg.openjdk.java.net/tsan/dev/rev/6d1caebf8d37 8220600: ZGC: Delete ZPages using ZSafeDelete Reviewed-by: stefank, eosterlund ! src/hotspot/share/gc/z/zDriver.cpp ! src/hotspot/share/gc/z/zDriver.hpp ! src/hotspot/share/gc/z/zHeap.cpp ! src/hotspot/share/gc/z/zHeap.hpp ! src/hotspot/share/gc/z/zPageAllocator.cpp ! src/hotspot/share/gc/z/zPageAllocator.hpp Changeset: 36e0665773e7 Author: pliden Date: 2019-03-18 11:50 +0100 URL: http://hg.openjdk.java.net/tsan/dev/rev/36e0665773e7 8220601: ZGC: Delete ZNMethodTableEntry arrays using ZSafeDelete Reviewed-by: stefank, eosterlund - src/hotspot/share/gc/z/zNMethodAllocator.cpp - src/hotspot/share/gc/z/zNMethodAllocator.hpp ! src/hotspot/share/gc/z/zNMethodTable.cpp ! src/hotspot/share/gc/z/zNMethodTable.hpp Changeset: 2786541e4f91 Author: sgehwolf Date: 2019-03-13 20:07 +0100 URL: http://hg.openjdk.java.net/tsan/dev/rev/2786541e4f91 8220579: [Containers] SubSystem.java out of sync with osContainer_linux.cpp Reviewed-by: bobv, adinn ! src/java.base/linux/classes/jdk/internal/platform/cgroupv1/SubSystem.java Changeset: b4779a44476b Author: stefank Date: 2019-03-18 15:19 +0100 URL: http://hg.openjdk.java.net/tsan/dev/rev/b4779a44476b 8220606: Move ScavengableNMethods unlinking to unregister_nmethod Reviewed-by: pliden, eosterlund ! src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp ! src/hotspot/share/gc/shared/genCollectedHeap.cpp ! src/hotspot/share/gc/shared/scavengableNMethods.cpp ! src/hotspot/share/gc/shared/scavengableNMethods.hpp Changeset: 98e21d4da074 Author: stefank Date: 2019-03-18 15:21 +0100 URL: http://hg.openjdk.java.net/tsan/dev/rev/98e21d4da074 8220609: Cleanups in ScavengableNMethods Reviewed-by: pliden, eosterlund ! src/hotspot/share/gc/cms/concurrentMarkSweepGeneration.cpp ! src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp ! src/hotspot/share/gc/parallel/parallelScavengeHeap.hpp ! src/hotspot/share/gc/parallel/psMarkSweep.cpp ! src/hotspot/share/gc/parallel/psParallelCompact.cpp ! src/hotspot/share/gc/parallel/psTasks.cpp ! src/hotspot/share/gc/serial/genMarkSweep.cpp ! src/hotspot/share/gc/shared/genCollectedHeap.cpp ! src/hotspot/share/gc/shared/genCollectedHeap.hpp ! src/hotspot/share/gc/shared/scavengableNMethods.cpp ! src/hotspot/share/gc/shared/scavengableNMethods.hpp Changeset: e81b44c68680 Author: rkennke Date: 2019-03-18 16:33 +0100 URL: http://hg.openjdk.java.net/tsan/dev/rev/e81b44c68680 8220780: ShenandoahBS::AccessBarrier::oop_store_in_heap ignores AS_NO_KEEPALIVE Reviewed-by: shade ! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.hpp ! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp From jcbeyler at google.com Mon Mar 18 16:40:04 2019 From: jcbeyler at google.com (jcbeyler at google.com) Date: Mon, 18 Mar 2019 16:40:04 +0000 Subject: hg: tsan/dev: Start of Tsan Message-ID: <201903181640.x2IGe4o6002904@aojmv0008.oracle.com> Changeset: 703483568c30 Author: jcbeyler Date: 2019-03-18 09:39 -0700 URL: http://hg.openjdk.java.net/tsan/dev/rev/703483568c30 Start of Tsan From jcbeyler at google.com Thu Mar 21 17:47:47 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Thu, 21 Mar 2019 10:47:47 -0700 Subject: RFR (M): First JTREG Tsan test Message-ID: Hi all, Could I get a review for this: http://cr.openjdk.java.net/~jcbeyler/first_test/webrev.00/ It basically creates a simple racy test and adds the JTREG infrastructure to make future tests easy to write. Note: the test evidently fails until we get Tsan in any kind of shape but this will allow me to write up some documentation on the wiki page once pushed. :-) Thanks, Jc From aeubanks at google.com Thu Mar 21 19:47:27 2019 From: aeubanks at google.com (Arthur Eubanks) Date: Thu, 21 Mar 2019 12:47:27 -0700 Subject: RFR (M): First JTREG Tsan test In-Reply-To: References: Message-ID: Remove the "symmetric behavior" comment in AbstractLoop.java. Do we need "requires vm.compMode == "Xint"" in the test? The test should check that the return code is non-zero. On Thu, Mar 21, 2019 at 10:49 AM Jean Christophe Beyler wrote: > Hi all, > > Could I get a review for this: > http://cr.openjdk.java.net/~jcbeyler/first_test/webrev.00/ > > It basically creates a simple racy test and adds the JTREG infrastructure > to make future tests easy to write. > > Note: the test evidently fails until we get Tsan in any kind of shape but > this will allow me to write up some documentation on the wiki page once > pushed. :-) > > Thanks, > Jc > From jcbeyler at google.com Thu Mar 21 20:00:09 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Thu, 21 Mar 2019 13:00:09 -0700 Subject: RFR (M): First JTREG Tsan test In-Reply-To: References: Message-ID: Done for the symmetric; I actually now just added the code to check that it does fail. When TSAN will be up and running, this will trip the test and start failing so we can update it automatically then. Let me know what you think: Webrev: http://cr.openjdk.java.net/~jcbeyler/first_test/webrev.01/ Jc On Thu, Mar 21, 2019 at 12:47 PM Arthur Eubanks wrote: > Remove the "symmetric behavior" comment in AbstractLoop.java. > Do we need "requires vm.compMode == "Xint"" in the test? > The test should check that the return code is non-zero. > > On Thu, Mar 21, 2019 at 10:49 AM Jean Christophe Beyler < > jcbeyler at google.com> wrote: > >> Hi all, >> >> Could I get a review for this: >> http://cr.openjdk.java.net/~jcbeyler/first_test/webrev.00/ >> >> It basically creates a simple racy test and adds the JTREG infrastructure >> to make future tests easy to write. >> >> Note: the test evidently fails until we get Tsan in any kind of shape but >> this will allow me to write up some documentation on the wiki page once >> pushed. :-) >> >> Thanks, >> Jc >> > -- Thanks, Jc From aeubanks at google.com Thu Mar 21 20:02:53 2019 From: aeubanks at google.com (Arthur Eubanks) Date: Thu, 21 Mar 2019 13:02:53 -0700 Subject: RFR (M): First JTREG Tsan test In-Reply-To: References: Message-ID: "unexpectantly" isn't a real word :P LGTM otherwise On Thu, Mar 21, 2019 at 1:00 PM Jean Christophe Beyler wrote: > Done for the symmetric; I actually now just added the code to check that > it does fail. When TSAN will be up and running, this will trip the test and > start failing so we can update it automatically then. Let me know what you > think: > > Webrev: http://cr.openjdk.java.net/~jcbeyler/first_test/webrev.01/ > > Jc > > On Thu, Mar 21, 2019 at 12:47 PM Arthur Eubanks > wrote: > >> Remove the "symmetric behavior" comment in AbstractLoop.java. >> Do we need "requires vm.compMode == "Xint"" in the test? >> The test should check that the return code is non-zero. >> >> On Thu, Mar 21, 2019 at 10:49 AM Jean Christophe Beyler < >> jcbeyler at google.com> wrote: >> >>> Hi all, >>> >>> Could I get a review for this: >>> http://cr.openjdk.java.net/~jcbeyler/first_test/webrev.00/ >>> >>> It basically creates a simple racy test and adds the JTREG infrastructure >>> to make future tests easy to write. >>> >>> Note: the test evidently fails until we get Tsan in any kind of shape but >>> this will allow me to write up some documentation on the wiki page once >>> pushed. :-) >>> >>> Thanks, >>> Jc >>> >> > > -- > > Thanks, > Jc > From jcbeyler at google.com Thu Mar 21 20:12:28 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Thu, 21 Mar 2019 13:12:28 -0700 Subject: RFR (M): First JTREG Tsan test In-Reply-To: References: Message-ID: Typo, should be unexpectedly :) Fixed on my local version, Jc On Thu, Mar 21, 2019 at 1:03 PM Arthur Eubanks wrote: > "unexpectantly" isn't a real word :P > LGTM otherwise > > On Thu, Mar 21, 2019 at 1:00 PM Jean Christophe Beyler < > jcbeyler at google.com> wrote: > >> Done for the symmetric; I actually now just added the code to check that >> it does fail. When TSAN will be up and running, this will trip the test and >> start failing so we can update it automatically then. Let me know what you >> think: >> >> Webrev: http://cr.openjdk.java.net/~jcbeyler/first_test/webrev.01/ >> >> Jc >> >> On Thu, Mar 21, 2019 at 12:47 PM Arthur Eubanks >> wrote: >> >>> Remove the "symmetric behavior" comment in AbstractLoop.java. >>> Do we need "requires vm.compMode == "Xint"" in the test? >>> The test should check that the return code is non-zero. >>> >>> On Thu, Mar 21, 2019 at 10:49 AM Jean Christophe Beyler < >>> jcbeyler at google.com> wrote: >>> >>>> Hi all, >>>> >>>> Could I get a review for this: >>>> http://cr.openjdk.java.net/~jcbeyler/first_test/webrev.00/ >>>> >>>> It basically creates a simple racy test and adds the JTREG >>>> infrastructure >>>> to make future tests easy to write. >>>> >>>> Note: the test evidently fails until we get Tsan in any kind of shape >>>> but >>>> this will allow me to write up some documentation on the wiki page once >>>> pushed. :-) >>>> >>>> Thanks, >>>> Jc >>>> >>> >> >> -- >> >> Thanks, >> Jc >> > -- Thanks, Jc From daniil.x.titov at oracle.com Fri Mar 22 02:32:35 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Thu, 21 Mar 2019 19:32:35 -0700 Subject: RFR (M): First JTREG Tsan test In-Reply-To: References: Message-ID: <7BC242DC-4427-4B08-8E03-36ACF05038DA@oracle.com> Hi JC, The change looks good to me. Thanks! -Daniil ?On 3/21/19, 1:13 PM, "tsan-dev on behalf of Jean Christophe Beyler" wrote: Typo, should be unexpectedly :) Fixed on my local version, Jc On Thu, Mar 21, 2019 at 1:03 PM Arthur Eubanks wrote: > "unexpectantly" isn't a real word :P > LGTM otherwise > > On Thu, Mar 21, 2019 at 1:00 PM Jean Christophe Beyler < > jcbeyler at google.com> wrote: > >> Done for the symmetric; I actually now just added the code to check that >> it does fail. When TSAN will be up and running, this will trip the test and >> start failing so we can update it automatically then. Let me know what you >> think: >> >> Webrev: http://cr.openjdk.java.net/~jcbeyler/first_test/webrev.01/ >> >> Jc >> >> On Thu, Mar 21, 2019 at 12:47 PM Arthur Eubanks >> wrote: >> >>> Remove the "symmetric behavior" comment in AbstractLoop.java. >>> Do we need "requires vm.compMode == "Xint"" in the test? >>> The test should check that the return code is non-zero. >>> >>> On Thu, Mar 21, 2019 at 10:49 AM Jean Christophe Beyler < >>> jcbeyler at google.com> wrote: >>> >>>> Hi all, >>>> >>>> Could I get a review for this: >>>> http://cr.openjdk.java.net/~jcbeyler/first_test/webrev.00/ >>>> >>>> It basically creates a simple racy test and adds the JTREG >>>> infrastructure >>>> to make future tests easy to write. >>>> >>>> Note: the test evidently fails until we get Tsan in any kind of shape >>>> but >>>> this will allow me to write up some documentation on the wiki page once >>>> pushed. :-) >>>> >>>> Thanks, >>>> Jc >>>> >>> >> >> -- >> >> Thanks, >> Jc >> > -- Thanks, Jc From manc at google.com Fri Mar 22 03:38:26 2019 From: manc at google.com (Man Cao) Date: Thu, 21 Mar 2019 20:38:26 -0700 Subject: RFR (M): First JTREG Tsan test In-Reply-To: <7BC242DC-4427-4B08-8E03-36ACF05038DA@oracle.com> References: <7BC242DC-4427-4B08-8E03-36ACF05038DA@oracle.com> Message-ID: I couldn't run this test with "make run-test TEST="jtreg:test/hotspot/jtreg/tsan/RacyIntMemberLoopTest.java"", I got the following messages: Test selection 'jtreg:test/hotspot/jtreg/tsan/RacyIntMemberLoopTest.java', will run: * jtreg:test/hotspot/jtreg/tsan/RacyIntMemberLoopTest.java Running test 'jtreg:test/hotspot/jtreg/tsan/RacyIntMemberLoopTest.java' Test results: no tests selected Report written to /usr/local/google/home/manc/ws/tsanBuild/test-results/jtreg_test_hotspot_jtreg_tsan_RacyIntMemberLoopTest_java/html/report.html Results written to /usr/local/google/home/manc/ws/tsanBuild/test-support/jtreg_test_hotspot_jtreg_tsan_RacyIntMemberLoopTest_java Finished running test 'jtreg:test/hotspot/jtreg/tsan/RacyIntMemberLoopTest.java' Test report is stored in /usr/local/google/home/manc/ws/tsanBuild/test-results/jtreg_test_hotspot_jtreg_tsan_RacyIntMemberLoopTest_java ============================== Test summary ============================== TEST TOTAL PASS FAIL ERROR jtreg:test/hotspot/jtreg/tsan/RacyIntMemberLoopTest.java 0 0 0 0 ============================== TEST SUCCESS If I run "make run-test TEST="jtreg:test/hotspot/jtreg/gc/TestNoPerfCounter.java"", it will show something like: Running test 'jtreg:test/hotspot/jtreg/gc/TestNoPerfCounter.java' Passed: gc/TestNoPerfCounter.java Test results: passed: 1 ... TEST TOTAL PASS FAIL ERROR jtreg:test/hotspot/jtreg/gc/TestNoPerfCounter.java 1 1 0 0 Is there anything I'm missing here to run this test? Below are code comments: In RacyIntMemberLoopTest.java 48 .shouldMatch("(Read|Write) of size 4 at 0x[0-9]+ by thread T[0-9]+") "0x[0-9]+" might be wrong to match an address. Should it be "0x[0-9a-fA-F]+" or just "0x.+"? Nit: The test name typically does not end in ".java". /* @test RacyIntMemberLoopTest.java -Man From jcbeyler at google.com Fri Mar 22 04:01:36 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Thu, 21 Mar 2019 21:01:36 -0700 Subject: RFR (M): First JTREG Tsan test In-Reply-To: References: <7BC242DC-4427-4B08-8E03-36ACF05038DA@oracle.com> Message-ID: Hi Man and Daniil, Thanks for the review :-) I inlined my answers Man: On Thu, Mar 21, 2019 at 8:38 PM Man Cao wrote: > I couldn't run this test with "make run-test > TEST="jtreg:test/hotspot/jtreg/tsan/RacyIntMemberLoopTest.java"", I got the > following messages: > > Test selection 'jtreg:test/hotspot/jtreg/tsan/RacyIntMemberLoopTest.java', > will run: > * jtreg:test/hotspot/jtreg/tsan/RacyIntMemberLoopTest.java > Running test 'jtreg:test/hotspot/jtreg/tsan/RacyIntMemberLoopTest.java' > Test results: no tests selected > Report written to > /usr/local/google/home/manc/ws/tsanBuild/test-results/jtreg_test_hotspot_jtreg_tsan_RacyIntMemberLoopTest_java/html/report.html > Results written to > /usr/local/google/home/manc/ws/tsanBuild/test-support/jtreg_test_hotspot_jtreg_tsan_RacyIntMemberLoopTest_java > Finished running test > 'jtreg:test/hotspot/jtreg/tsan/RacyIntMemberLoopTest.java' > Test report is stored in > /usr/local/google/home/manc/ws/tsanBuild/test-results/jtreg_test_hotspot_jtreg_tsan_RacyIntMemberLoopTest_java > > ============================== > Test summary > ============================== > TEST TOTAL PASS FAIL > ERROR > jtreg:test/hotspot/jtreg/tsan/RacyIntMemberLoopTest.java > 0 0 0 > 0 > ============================== > TEST SUCCESS > > If I run "make run-test > TEST="jtreg:test/hotspot/jtreg/gc/TestNoPerfCounter.java"", it will show > something like: > > Running test 'jtreg:test/hotspot/jtreg/gc/TestNoPerfCounter.java' > Passed: gc/TestNoPerfCounter.java > Test results: passed: 1 > ... > TEST TOTAL PASS FAIL > ERROR > jtreg:test/hotspot/jtreg/gc/TestNoPerfCounter.java > 1 1 0 > 0 > > Is there anything I'm missing here to run this test? > > Because I put the @requires Xint since it would not work otherwise for the first step that we are going for, you need to tell JTREG to use Xint or it skips the test :) make run-test JTREG="VM_OPTIONS=-Xint" TEST="jtreg:test/hotspot/jtreg/tsan/RacyIntMemberLoopTest.java" Later down the road, maybe we could remove it but I'd like for now to leave the @requires since really we should not try to run it without... > Below are code comments: > > In RacyIntMemberLoopTest.java > > 48 .shouldMatch("(Read|Write) of size 4 at 0x[0-9]+ by thread T[0-9]+") > > "0x[0-9]+" might be wrong to match an address. Should it be > "0x[0-9a-fA-F]+" or just "0x.+"? > > Good point, I had just simplified it compared to what we had but missed the hexa letters. I added them (I rather that then the . version we had. > Nit: > The test name typically does not end in ".java". > /* @test RacyIntMemberLoopTest.java > True, there are some but also some without the name at all. Removed it. New webrev is here: Thanks, Jc From manc at google.com Fri Mar 22 17:21:11 2019 From: manc at google.com (Man Cao) Date: Fri, 22 Mar 2019 10:21:11 -0700 Subject: RFR (M): First JTREG Tsan test In-Reply-To: References: <7BC242DC-4427-4B08-8E03-36ACF05038DA@oracle.com> Message-ID: Thanks for the instructions! I assume this is the webrev that you intended to include in last email: http://cr.openjdk.java.net/~jcbeyler/first_test/webrev.02. It confused me initially that it has both "@requires vm.compMode == "Xint"" and "@run main/othervm -Xint ...". Can we only have one of them? "@requires" needs more typing when running the test. But if TSAN supports C1 or other compilers, it might be easier to modify all "@requires" than all "@run". Also, "@compile RacyIntMemberLoopTest.java" seems unnecessary and can be removed. -Man From jcbeyler at google.com Fri Mar 22 17:32:00 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Fri, 22 Mar 2019 10:32:00 -0700 Subject: RFR (M): First JTREG Tsan test In-Reply-To: References: <7BC242DC-4427-4B08-8E03-36ACF05038DA@oracle.com> Message-ID: Yes for the webrev :) Done for both :) One day the @require will have to come back when we are adding C1 support for example but we can deal with that later. Want to see the new webrev or good to go on your side apart from those two elements? Jc On Fri, Mar 22, 2019 at 10:21 AM Man Cao wrote: > Thanks for the instructions! > I assume this is the webrev that you intended to include in last email: > http://cr.openjdk.java.net/~jcbeyler/first_test/webrev.02. > > It confused me initially that it has both "@requires vm.compMode == > "Xint"" and "@run main/othervm -Xint ...". Can we only have one of them? > "@requires" needs more typing when running the test. But if TSAN supports > C1 or other compilers, it might be easier to modify all "@requires" than > all "@run". > > Also, "@compile RacyIntMemberLoopTest.java" seems unnecessary and can be > removed. > > -Man > -- Thanks, Jc From manc at google.com Fri Mar 22 17:49:43 2019 From: manc at google.com (Man Cao) Date: Fri, 22 Mar 2019 10:49:43 -0700 Subject: RFR (M): First JTREG Tsan test In-Reply-To: References: <7BC242DC-4427-4B08-8E03-36ACF05038DA@oracle.com> Message-ID: LGTM after fixing these. No need for new webrev. -Man On Fri, Mar 22, 2019 at 10:32 AM Jean Christophe Beyler wrote: > Yes for the webrev :) > Done for both :) > > One day the @require will have to come back when we are adding C1 support > for example but we can deal with that later. > > Want to see the new webrev or good to go on your side apart from those two > elements? > Jc > > On Fri, Mar 22, 2019 at 10:21 AM Man Cao wrote: > >> Thanks for the instructions! >> I assume this is the webrev that you intended to include in last email: >> http://cr.openjdk.java.net/~jcbeyler/first_test/webrev.02. >> >> It confused me initially that it has both "@requires vm.compMode == >> "Xint"" and "@run main/othervm -Xint ...". Can we only have one of them? >> "@requires" needs more typing when running the test. But if TSAN supports >> C1 or other compilers, it might be easier to modify all "@requires" than >> all "@run". >> >> Also, "@compile RacyIntMemberLoopTest.java" seems unnecessary and can be >> removed. >> >> -Man >> > > > -- > > Thanks, > Jc > From jcbeyler at google.com Fri Mar 22 18:41:47 2019 From: jcbeyler at google.com (jcbeyler at google.com) Date: Fri, 22 Mar 2019 18:41:47 +0000 Subject: hg: tsan/dev: Adding a first JTREG test that passes if TSAN is not working Message-ID: <201903221841.x2MIflO1020872@aojmv0008.oracle.com> Changeset: a1852c684bc9 Author: jcbeyler Date: 2019-03-22 11:41 -0700 URL: http://hg.openjdk.java.net/tsan/dev/rev/a1852c684bc9 Adding a first JTREG test that passes if TSAN is not working Test currently passes until we get the base Java tsan up and running. Then the test would fail and we can flip the switch on it. + test/hotspot/jtreg/tsan/AbstractLoop.java + test/hotspot/jtreg/tsan/RacyIntMemberLoopTest.java + test/hotspot/jtreg/tsan/TsanRunner.java From aeubanks at google.com Mon Mar 25 17:39:57 2019 From: aeubanks at google.com (Arthur Eubanks) Date: Mon, 25 Mar 2019 10:39:57 -0700 Subject: [RFR] Create interface to call TSAN runtime Message-ID: Hi, Here's a patch which allows the JVM to call into TSAN runtime functions. With the -XX:+ThreadSanitizer flag it will call __tsan_java_init() on startup, and will call __tsan_java_fini() on shutdown, exiting with whatever __tsan_java_fini() returns if non-zero. Currently the way to provide the TSAN runtime is with LD_PRELOAD. In the future we will have a better way, but this is the current short-term solution so we can iterate faster. $ LD_PRELOAD=/usr/lib/gcc/x86_64-linux-gnu/8/libtsan.so ./images/jdk/bin/java -XX:+ThreadSanitizer works, reports some internal JVM races, and exits with 66, the default exit code when TSAN finds any races. $ LD_PRELOAD=/usr/lib/gcc/x86_64-linux-gnu/8/libtsan.so TSAN_OPTIONS="exitcode=123" ./images/jdk/bin/java -XX:+ThreadSanitizer ; echo $? Overriding the default TSAN error exit code works. http://cr.openjdk.java.net/~aeubanks/tsaninit/webrev.00/index.html From jcbeyler at google.com Mon Mar 25 18:01:23 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Mon, 25 Mar 2019 11:01:23 -0700 Subject: [RFR] Create interface to call TSAN runtime In-Reply-To: References: Message-ID: Hi Arthur, LGTM, thanks! My only nit would be that your file: http://cr.openjdk.java.net/~aeubanks/tsaninit/webrev.00/src/hotspot/share/runtime/tsanExternalDecls.hpp.html contains all the methods we use. Would we want to add into it incrementally instead? I'm indifferent both ways, just wondering :) Jc On Mon, Mar 25, 2019 at 10:41 AM Arthur Eubanks wrote: > Hi, > > Here's a patch which allows the JVM to call into TSAN runtime functions. > With the -XX:+ThreadSanitizer flag it will call __tsan_java_init() on > startup, and will call __tsan_java_fini() on shutdown, exiting with > whatever __tsan_java_fini() returns if non-zero. > > Currently the way to provide the TSAN runtime is with LD_PRELOAD. In the > future we will have a better way, but this is the current short-term > solution so we can iterate faster. > > $ LD_PRELOAD=/usr/lib/gcc/x86_64-linux-gnu/8/libtsan.so > ./images/jdk/bin/java -XX:+ThreadSanitizer > works, reports some internal JVM races, and exits with 66, the default exit > code when TSAN finds any races. > > $ LD_PRELOAD=/usr/lib/gcc/x86_64-linux-gnu/8/libtsan.so > TSAN_OPTIONS="exitcode=123" ./images/jdk/bin/java -XX:+ThreadSanitizer ; > echo $? > Overriding the default TSAN error exit code works. > > http://cr.openjdk.java.net/~aeubanks/tsaninit/webrev.00/index.html > -- Thanks, Jc From aeubanks at google.com Mon Mar 25 18:13:07 2019 From: aeubanks at google.com (Arthur Eubanks) Date: Mon, 25 Mar 2019 11:13:07 -0700 Subject: [RFR] Create interface to call TSAN runtime In-Reply-To: References: Message-ID: > > My only nit would be that your file: > > http://cr.openjdk.java.net/~aeubanks/tsaninit/webrev.00/src/hotspot/share/runtime/tsanExternalDecls.hpp.html > > contains all the methods we use. Would we want to add into it > incrementally instead? I'm indifferent both ways, just wondering :) > Hmm, I suppose it would make more sense to add them incrementally. Changed. http://cr.openjdk.java.net/~aeubanks/tsaninit/webrev.01/ From jcbeyler at google.com Mon Mar 25 18:32:38 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Mon, 25 Mar 2019 11:32:38 -0700 Subject: [RFR] Create interface to call TSAN runtime In-Reply-To: References: Message-ID: Looks good again except that now : 33 // These declarations, along with TsanSymbolizeStackFrame, constitute the 34 // VM-ThreadSanitizer interface. These functions are the only way the VM 35 // notifies Tsan about critical events; they are "push" functions. 36 // (TSAN calls TsanSymbolizeStackFrame when it prints stack traces). 37 // 42 // The __tsan_java_* functions accept a raw oop as an argument; Tsan tracks 43 // metadata for each oop using fixed address offsets. Make no real sense when you read the file; they should be added later :-) No need for a new webrev btw, Jc On Mon, Mar 25, 2019 at 11:13 AM Arthur Eubanks wrote: > My only nit would be that your file: >> >> http://cr.openjdk.java.net/~aeubanks/tsaninit/webrev.00/src/hotspot/share/runtime/tsanExternalDecls.hpp.html >> >> contains all the methods we use. Would we want to add into it >> incrementally instead? I'm indifferent both ways, just wondering :) >> > Hmm, I suppose it would make more sense to add them incrementally. Changed. > http://cr.openjdk.java.net/~aeubanks/tsaninit/webrev.01/ > -- Thanks, Jc From aeubanks at google.com Mon Mar 25 18:37:23 2019 From: aeubanks at google.com (Arthur Eubanks) Date: Mon, 25 Mar 2019 11:37:23 -0700 Subject: [RFR] Create interface to call TSAN runtime In-Reply-To: References: Message-ID: > > Looks good again except that now : > > > 33 // These declarations, along with TsanSymbolizeStackFrame, constitute > the > 34 // VM-ThreadSanitizer interface. These functions are the only way the > VM > 35 // notifies Tsan about critical events; they are "push" functions. > 36 // (TSAN calls TsanSymbolizeStackFrame when it prints stack traces). > 37 // > > 42 // The __tsan_java_* functions accept a raw oop as an argument; Tsan tracks > 43 // metadata for each oop using fixed address offsets. > > > Make no real sense when you read the file; they should be added later :-) > > Oops, fixed. From manc at google.com Tue Mar 26 01:26:38 2019 From: manc at google.com (Man Cao) Date: Mon, 25 Mar 2019 18:26:38 -0700 Subject: [RFR] Create interface to call TSAN runtime In-Reply-To: References: Message-ID: Looks good as well. -Man From aeubanks at google.com Tue Mar 26 17:49:38 2019 From: aeubanks at google.com (aeubanks at google.com) Date: Tue, 26 Mar 2019 17:49:38 +0000 Subject: hg: tsan/dev: Create interface to call TSAN runtime Message-ID: <201903261749.x2QHndo1008008@aojmv0008.oracle.com> Changeset: b9a33a2a9d3f Author: aeubanks Date: 2019-03-26 10:09 -0700 URL: http://hg.openjdk.java.net/tsan/dev/rev/b9a33a2a9d3f Create interface to call TSAN runtime $ LD_PRELOAD=/usr/lib/gcc/x86_64-linux-gnu/8/libtsan.so ./images/jdk/bin/java -XX:+ThreadSanitizer works, reports some internal JVM races, and exits with 66, the default exit code when TSAN finds any races. $ LD_PRELOAD=/usr/lib/gcc/x86_64-linux-gnu/8/libtsan.so TSAN_OPTIONS="exitcode=123" ./images/jdk/bin/java -XX:+ThreadSanitizer ; echo $? Overriding the default TSAN error exit code works. With this, the way to provide the TSAN runtime is with LD_PRELOAD. In the future we will have a better way, but this is the current short-term solution so we can iterate faster. ! src/hotspot/share/runtime/globals.hpp ! src/hotspot/share/runtime/init.cpp + src/hotspot/share/runtime/tsan.cpp + src/hotspot/share/runtime/tsanExternalDecls.hpp From aeubanks at google.com Wed Mar 27 15:45:52 2019 From: aeubanks at google.com (Arthur Eubanks) Date: Wed, 27 Mar 2019 08:45:52 -0700 Subject: [RFR]: Add __tsan_symbolize_external_ex Message-ID: http://cr.openjdk.java.net/~aeubanks/tsansymbolizeexternal/webrev.00/index.html Small change that adds __tsan_symbolize_external_ex(), the function TSAN calls to symbolize a Java frame. The actual implementation will come later. From jcbeyler at google.com Wed Mar 27 15:50:05 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Wed, 27 Mar 2019 08:50:05 -0700 Subject: [RFR]: Add __tsan_symbolize_external_ex In-Reply-To: References: Message-ID: Hi Arthur, Any reason you want to do it two steps? Otherwise it looks good to me (I'm curious why we always pass -1 as column but we can take that offline :-)), Jc On Wed, Mar 27, 2019 at 8:47 AM Arthur Eubanks wrote: > > http://cr.openjdk.java.net/~aeubanks/tsansymbolizeexternal/webrev.00/index.html > > Small change that adds __tsan_symbolize_external_ex(), the function TSAN > calls to symbolize a Java frame. The actual implementation will come later. > -- Thanks, Jc From aeubanks at google.com Wed Mar 27 15:56:29 2019 From: aeubanks at google.com (Arthur Eubanks) Date: Wed, 27 Mar 2019 08:56:29 -0700 Subject: [RFR]: Add __tsan_symbolize_external_ex In-Reply-To: References: Message-ID: > > Any reason you want to do it two steps? > This slightly differs from our internal patch where we have a wrapper in the launcher. I wanted to see if this difference made sense. From manc at google.com Wed Mar 27 18:34:10 2019 From: manc at google.com (Man Cao) Date: Wed, 27 Mar 2019 11:34:10 -0700 Subject: [RFR]: Add __tsan_symbolize_external_ex In-Reply-To: References: Message-ID: Looks good. Minor comment is that you could add some comment on how __tsan_symbolize_external_ex() differs from other functions starting with "__tsan", and why it does not need to be inside tsanExternalDecls.hpp. No need for a new webrev. -Man On Wed, Mar 27, 2019 at 8:57 AM Arthur Eubanks wrote: > > > > Any reason you want to do it two steps? > > > This slightly differs from our internal patch where we have a wrapper in > the launcher. I wanted to see if this difference made sense. > From aeubanks at google.com Wed Mar 27 18:38:51 2019 From: aeubanks at google.com (Arthur Eubanks) Date: Wed, 27 Mar 2019 11:38:51 -0700 Subject: [RFR]: Add __tsan_symbolize_external_ex In-Reply-To: References: Message-ID: Done. On Wed, Mar 27, 2019 at 11:34 AM Man Cao wrote: > Looks good. > Minor comment is that you could add some comment on > how __tsan_symbolize_external_ex() differs from other functions starting > with "__tsan", and why it does not need to be inside tsanExternalDecls.hpp. > No need for a new webrev. > > -Man > > > On Wed, Mar 27, 2019 at 8:57 AM Arthur Eubanks > wrote: > >> > >> > Any reason you want to do it two steps? >> > >> This slightly differs from our internal patch where we have a wrapper in >> the launcher. I wanted to see if this difference made sense. >> > From aeubanks at google.com Wed Mar 27 18:40:26 2019 From: aeubanks at google.com (aeubanks at google.com) Date: Wed, 27 Mar 2019 18:40:26 +0000 Subject: hg: tsan/dev: Add __tsan_symbolize_external_ex() Message-ID: <201903271840.x2RIeRc5020609@aojmv0008.oracle.com> Changeset: 28f0415a0822 Author: aeubanks Date: 2019-03-27 11:40 -0700 URL: http://hg.openjdk.java.net/tsan/dev/rev/28f0415a0822 Add __tsan_symbolize_external_ex() This is the function that TSAN calls to symbolize a stack frame produced by Java. The actual implementation will come later. ! src/hotspot/share/runtime/tsan.cpp From aeubanks at google.com Wed Mar 27 23:33:51 2019 From: aeubanks at google.com (Arthur Eubanks) Date: Wed, 27 Mar 2019 16:33:51 -0700 Subject: [RFR]: Fix broken build Message-ID: The previous change is broken (I thought I tested it...) due to a type that the JVM doesn't recognize. int64 -> julong. diff --git a/src/hotspot/share/runtime/tsan.cpp b/src/hotspot/share/runtime/tsan.cpp --- a/src/hotspot/share/runtime/tsan.cpp +++ b/src/hotspot/share/runtime/tsan.cpp @@ -58,7 +58,7 @@ typedef void (*AddFrameFunc)(void *ctx, // This is not in tsanExternalDecls.hpp because this is a function that the JVM // is supposed to override which TSAN will call, not a TSAN function that the // JVM calls. -extern "C" void __tsan_symbolize_external_ex(int64 pc, +extern "C" void __tsan_symbolize_external_ex(julong pc, AddFrameFunc addFrame, void *ctx) { From manc at google.com Wed Mar 27 23:36:36 2019 From: manc at google.com (Man Cao) Date: Wed, 27 Mar 2019 16:36:36 -0700 Subject: [RFR]: Fix broken build In-Reply-To: References: Message-ID: Looks good. -Man On Wed, Mar 27, 2019 at 4:34 PM Arthur Eubanks wrote: > The previous change is broken (I thought I tested it...) due to a type that > the JVM doesn't recognize. int64 -> julong. > > diff --git a/src/hotspot/share/runtime/tsan.cpp > b/src/hotspot/share/runtime/tsan.cpp > --- a/src/hotspot/share/runtime/tsan.cpp > +++ b/src/hotspot/share/runtime/tsan.cpp > @@ -58,7 +58,7 @@ typedef void (*AddFrameFunc)(void *ctx, > // This is not in tsanExternalDecls.hpp because this is a function that > the JVM > // is supposed to override which TSAN will call, not a TSAN function that > the > // JVM calls. > -extern "C" void __tsan_symbolize_external_ex(int64 pc, > +extern "C" void __tsan_symbolize_external_ex(julong pc, > AddFrameFunc addFrame, > void *ctx) { > From aeubanks at google.com Wed Mar 27 23:38:15 2019 From: aeubanks at google.com (aeubanks at google.com) Date: Wed, 27 Mar 2019 23:38:15 +0000 Subject: hg: tsan/dev: Change a wrong type to fix build Message-ID: <201903272338.x2RNcF7M022780@aojmv0008.oracle.com> Changeset: 1c8f3ed98dd6 Author: aeubanks Date: 2019-03-27 16:19 -0700 URL: http://hg.openjdk.java.net/tsan/dev/rev/1c8f3ed98dd6 Change a wrong type to fix build JVM doesn't recognize "int64", use "julong" instead. ! src/hotspot/share/runtime/tsan.cpp From aeubanks at google.com Wed Mar 27 23:45:09 2019 From: aeubanks at google.com (Arthur Eubanks) Date: Wed, 27 Mar 2019 16:45:09 -0700 Subject: [RFR]: Interpreter method entry/exit Message-ID: http://cr.openjdk.java.net/~aeubanks/tsanmethodentryexit/webrev.00/ This change adds method entry and exit hooks to the interpreter and native wrappers. I also made it so that essentially -Xint is passed when -XX:+ThreadSanitizer is passed. Without it, I got weird crashes that were only fixed by passing -Xint alongside -XX:+ThreadSanitizer. $ LD_PRELOAD=/usr/lib/gcc/x86_64-linux-gnu/8/libtsan.so ./images/jdk/bin/java -XX:+ThreadSanitizer From jcbeyler at google.com Thu Mar 28 02:29:30 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Wed, 27 Mar 2019 19:29:30 -0700 Subject: [RFR]: Interpreter method entry/exit In-Reply-To: References: Message-ID: Hi Arthur, There seems to be a permission issue with your webrev? Btw, are you by chance updating the wiki with the commands to be run now or should I do it at some point in the future? Jc On Wed, Mar 27, 2019 at 4:46 PM Arthur Eubanks wrote: > http://cr.openjdk.java.net/~aeubanks/tsanmethodentryexit/webrev.00/ > > This change adds method entry and exit hooks to the interpreter and native > wrappers. > > I also made it so that essentially -Xint is passed when > -XX:+ThreadSanitizer is passed. Without it, I got weird crashes that were > only fixed by passing -Xint alongside -XX:+ThreadSanitizer. > > $ LD_PRELOAD=/usr/lib/gcc/x86_64-linux-gnu/8/libtsan.so > ./images/jdk/bin/java -XX:+ThreadSanitizer > -- Thanks, Jc From jcbeyler at google.com Thu Mar 28 02:28:36 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Wed, 27 Mar 2019 19:28:36 -0700 Subject: [RFR]: Fix broken build In-Reply-To: References: Message-ID: LGTM, Jc On Wed, Mar 27, 2019 at 4:37 PM Man Cao wrote: > Looks good. > -Man > > > On Wed, Mar 27, 2019 at 4:34 PM Arthur Eubanks > wrote: > > > The previous change is broken (I thought I tested it...) due to a type > that > > the JVM doesn't recognize. int64 -> julong. > > > > diff --git a/src/hotspot/share/runtime/tsan.cpp > > b/src/hotspot/share/runtime/tsan.cpp > > --- a/src/hotspot/share/runtime/tsan.cpp > > +++ b/src/hotspot/share/runtime/tsan.cpp > > @@ -58,7 +58,7 @@ typedef void (*AddFrameFunc)(void *ctx, > > // This is not in tsanExternalDecls.hpp because this is a function that > > the JVM > > // is supposed to override which TSAN will call, not a TSAN function > that > > the > > // JVM calls. > > -extern "C" void __tsan_symbolize_external_ex(int64 pc, > > +extern "C" void __tsan_symbolize_external_ex(julong pc, > > AddFrameFunc addFrame, > > void *ctx) { > > > -- Thanks, Jc From aeubanks at google.com Thu Mar 28 04:57:14 2019 From: aeubanks at google.com (Arthur Eubanks) Date: Wed, 27 Mar 2019 21:57:14 -0700 Subject: [RFR]: Interpreter method entry/exit In-Reply-To: References: Message-ID: > > There seems to be a permission issue with your webrev? > All of my webrevs are down from the webpage even though I can see them from ftp. I think it's a transient issue, we'll see tomorrow. > > Btw, are you by chance updating the wiki with the commands to be run now > or should I do it at some point in the future? > Jc > I'll update the wiki in a separate change. From jcbeyler at google.com Thu Mar 28 15:48:46 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Thu, 28 Mar 2019 08:48:46 -0700 Subject: [RFR]: Interpreter method entry/exit In-Reply-To: References: Message-ID: Hi Arthur, Yes, the access issues were due to maintenance :); I had seen the email but had not connected the two until other webrevs (including my own!) were not available :) For now it looks good to me to get us going; I wonder if there is a way to piggy back JVMTI's infrastructure since they have the method entry/exit in the right spots. But I'm not sure how that would really look like and is it logical to do so; perhaps we could at least check at some point that each JVMTI point of call, we do it as well :) So, LGTM, Jc On Wed, Mar 27, 2019 at 9:57 PM Arthur Eubanks wrote: > There seems to be a permission issue with your webrev? >> > All of my webrevs are down from the webpage even though I can see them > from ftp. I think it's a transient issue, we'll see tomorrow. > >> >> Btw, are you by chance updating the wiki with the commands to be run now >> or should I do it at some point in the future? >> Jc >> > I'll update the wiki in a separate change. > -- Thanks, Jc From manc at google.com Thu Mar 28 20:53:58 2019 From: manc at google.com (Man Cao) Date: Thu, 28 Mar 2019 13:53:58 -0700 Subject: [RFR]: Interpreter method entry/exit In-Reply-To: References: Message-ID: Looks good, except "debug_only" could be changed to "DEBUG_ONLY" in sharedRuntime.cpp. No need for a new webrev. -Man On Thu, Mar 28, 2019 at 8:49 AM Jean Christophe Beyler wrote: > Hi Arthur, > > Yes, the access issues were due to maintenance :); I had seen the email but > had not connected the two until other webrevs (including my own!) were not > available :) > > For now it looks good to me to get us going; I wonder if there is a way to > piggy back JVMTI's infrastructure since they have the method entry/exit in > the right spots. But I'm not sure how that would really look like and is it > logical to do so; perhaps we could at least check at some point that each > JVMTI point of call, we do it as well :) > > So, LGTM, > Jc > > On Wed, Mar 27, 2019 at 9:57 PM Arthur Eubanks > wrote: > > > There seems to be a permission issue with your webrev? > >> > > All of my webrevs are down from the webpage even though I can see them > > from ftp. I think it's a transient issue, we'll see tomorrow. > > > >> > >> Btw, are you by chance updating the wiki with the commands to be run now > >> or should I do it at some point in the future? > >> Jc > >> > > I'll update the wiki in a separate change. > > > > > -- > > Thanks, > Jc > From aeubanks at google.com Thu Mar 28 21:01:26 2019 From: aeubanks at google.com (Arthur Eubanks) Date: Thu, 28 Mar 2019 14:01:26 -0700 Subject: [RFR]: Interpreter method entry/exit In-Reply-To: References: Message-ID: > > Looks good, except "debug_only" could be changed to "DEBUG_ONLY" > in sharedRuntime.cpp. > No need for a new webrev. > Done From aeubanks at google.com Thu Mar 28 21:01:40 2019 From: aeubanks at google.com (aeubanks at google.com) Date: Thu, 28 Mar 2019 21:01:40 +0000 Subject: hg: tsan/dev: Add method entry/exit hooks for interpreter and native wrappers Message-ID: <201903282101.x2SL1eGh016179@aojmv0008.oracle.com> Changeset: 777d0b339577 Author: aeubanks Date: 2019-03-27 16:40 -0700 URL: http://hg.openjdk.java.net/tsan/dev/rev/777d0b339577 Add method entry/exit hooks for interpreter and native wrappers Also force -Xint when -XX:+ThreadSanitizer ! src/hotspot/cpu/x86/interp_masm_x86.cpp ! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/sharedRuntime.cpp ! src/hotspot/share/runtime/sharedRuntime.hpp ! src/hotspot/share/runtime/tsanExternalDecls.hpp From manc at google.com Sat Mar 30 02:10:45 2019 From: manc at google.com (Man Cao) Date: Fri, 29 Mar 2019 19:10:45 -0700 Subject: RFR (M): Make TSAN a build-time JVM feature Message-ID: Hi, Could I get review for this: http://cr.openjdk.java.net/~manc/tsan/20190329/webrev.00/ It makes it possible to disable TSAN at build time, using "--with-jvm-features=-tsan". My initial purpose was to add a "#ifdef" macro for TSAN, but it seems making TSAN a JVM feature is the right way to go for the long term. Tested by building with and without TSAN, and running LD_PRELOAD. -Man From manc at google.com Sat Mar 30 02:13:07 2019 From: manc at google.com (Man Cao) Date: Fri, 29 Mar 2019 19:13:07 -0700 Subject: RFR (M): Make TSAN a build-time JVM feature In-Reply-To: References: Message-ID: Note that I moved the two new files for TSAN into the directory "share/tsan". Looking at our internal TSAN code, there will be more new files for TSAN to add in the future. A separate directory seems cleaner. -Man On Fri, Mar 29, 2019 at 7:10 PM Man Cao wrote: > Hi, > > Could I get review for this: > http://cr.openjdk.java.net/~manc/tsan/20190329/webrev.00/ > > It makes it possible to disable TSAN at build time, using > "--with-jvm-features=-tsan". My initial purpose was to add a "#ifdef" macro > for TSAN, but it seems making TSAN a JVM feature is the right way to go for > the long term. > > Tested by building with and without TSAN, and running LD_PRELOAD. > > -Man > From jcbeyler at google.com Sat Mar 30 02:50:57 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Fri, 29 Mar 2019 19:50:57 -0700 Subject: RFR (M): Make TSAN a build-time JVM feature In-Reply-To: References: Message-ID: Agreed Man on all points, LGTM, Jc On Fri, Mar 29, 2019 at 7:14 PM Man Cao wrote: > Note that I moved the two new files for TSAN into the directory > "share/tsan". > Looking at our internal TSAN code, there will be more new files for TSAN to > add in the future. A separate directory seems cleaner. > > -Man > > > On Fri, Mar 29, 2019 at 7:10 PM Man Cao wrote: > > > Hi, > > > > Could I get review for this: > > http://cr.openjdk.java.net/~manc/tsan/20190329/webrev.00/ > > > > It makes it possible to disable TSAN at build time, using > > "--with-jvm-features=-tsan". My initial purpose was to add a "#ifdef" > macro > > for TSAN, but it seems making TSAN a JVM feature is the right way to go > for > > the long term. > > > > Tested by building with and without TSAN, and running LD_PRELOAD. > > > > -Man > > > -- Thanks, Jc