From koehlerkokser at gmail.com Mon Feb 4 12:42:31 2019 From: koehlerkokser at gmail.com (Herr Knack) Date: Mon, 4 Feb 2019 13:42:31 +0100 Subject: Question to JMH and JIT Message-ID: Hey there, I currently try to find a mathematical model to compute the approximate runtime of a function term out of its basic structure for my machine (Ubuntu 16.04, i7-5500U, 2.40GHz?4). For first microbenchmark measurements I used the JMH and measured the throughput of some simple functions (4 different forks, 3 warmup and 5 measurement iterations each fork, 10 sec time each iteration). I found out, that it is really difficult to see the connection between the structure of the function term and its runtime in the microbenchmark. I assume that the JIT compiler does some weird stuff to optimize the functions, but I can?t see which optimizations in detail are done there. Could JIT be the problem? Does anyone know if the workflow of JIT optimizations is documented anywhere? I hope someone can help, because I?m getting crazy about it. Here some results I got. I converted the throughput (runs/sec) to a average time per run in ns. The standard deviation is smaller as you might think, so the average time is most likely correct in an area of +/-0.3 ns : - (((0.5 * x) * 0.5) * (((((0.5 * x) * 0.5) / 0.5) + (((0.5 * x) * 0.5) * 0.5)) * (((0.5 * x) * 0.5) + x))) + x, 15 operations (3+, 11*, 1/), 28.09 ns - x + ((((0.5 * x) * (0.5 * x)) * (0.5 * x)) + ((0.5 * x) * ((((0.5 * x) * (0.5 * x)) * (0.5 * x)) * (((0.5 * x) * (0.5 * x)) / ((((0.5 * x) * ((0.5 * x) * (0.5 * x))) / (0.5 + ((0.5 * x) * (0.5 * x)))) + (((0.5 * x) * (0.5 * x)) * (0.5 * x))))))), 35 operations (4+,29*,2/), 38.61 ns - (((x / (x / (0.5 * x))) * (x / (x / (0.5 * x)))) * (0.5 * x)) + (x + ((((x / (x / (0.5 * x))) * (x / (x / (0.5 * x)))) * (0.5 * x)) / (((x / (0.5 * x)) + 0.5) - ((((x / (x / (0.5 * x))) * (x / (x / (0.5 * x)))) * (0.5 * x)) * (x / (x / (0.5 * x))))))), 38 operations (4+-,18*,16/), 40.70 ns I assume that there is an constant offset for method calls and so on. In addition I suppose that already calculated term pieces don?t have to be calculated again. But these conclusions did not help me either. Regards, KKokser From shade at redhat.com Mon Feb 4 13:15:44 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 4 Feb 2019 14:15:44 +0100 Subject: Question to JMH and JIT In-Reply-To: References: Message-ID: On 2/4/19 1:42 PM, Herr Knack wrote: > Could JIT be the problem? Yes, it could. > Does anyone know if the workflow of JIT > optimizations is documented anywhere? Even if it was, it is unlikely to help you. You need to drill into what is going on in the benchmark. It is hard to do based on your current explanation, because there is no benchmark code. > I hope someone can help, because I?m getting crazy about it. Profile the benchmark with -prof perfasm at different workload sizes, and that should highlight what is the final generated code, which would give you some idea what might go wrong. Thanks, -Aleksey From koehlerkokser at gmail.com Mon Feb 4 13:53:55 2019 From: koehlerkokser at gmail.com (Herr Knack) Date: Mon, 4 Feb 2019 14:53:55 +0100 Subject: Question to JMH and JIT In-Reply-To: References: Message-ID: Hello Aleksey and thanks for your fast reply! Sorry for the unclearness. In my benchmark methods I just execute any arbitrary function looking like the examples from above and consume them with a JMH blackhole. Before each iteration I compute a random input value between -10 and 10 which is put into the benchmark method via a static state class. This random generatingcode is not measured with the code in the benchmark method. So the benchmark code looks like this: package org.sample; > > import java.util.ArrayList; > import java.util.List; > import java.util.Random; > > import org.openjdk.jmh.annotations.*; > import org.openjdk.jmh.infra.Blackhole; > > @Fork(4) > @Warmup(iterations = 3) > @Measurement(iterations = 5) > public class MyBenchmark { > > @State(Scope.Thread) > public static class MyState { > Random random; > double[] inputs = new double[2]; > double a; > double b; > > @Setup(Level.Invocation) > public void setup() { > random = new Random(); > inputs = random.doubles(inputs.length,-10,10).toArray(); > a = inputs[0]; > b = inputs[1]; > } > } > > @Benchmark > public void test1(MyState state, Blackhole blackhole) { > blackhole.consume((((state.a / (state.a / (0.5 * state.a))) * > (state.a / (state.a / (0.5 * state.a)))) * (0.5 * state.a)) + (state.a + > ((((state.a / (state.a / (0.5 * state.a))) * (state.a / (state.a / (0.5 * > state.a)))) * (0.5 * state.a)) / (((state.a / (0.5 * state.a)) + 0.5) - > ((((state.a / (state.a / (0.5 * state.a))) * (state.a / (state.a / (0.5 * > state.a)))) * (0.5 * state.a)) * (state.a / (state.a / (0.5 * > state.a)))))))); > } > > ... > } > Thank you for your hints, I will also try profiling the benchmark. Maybe there are some other ideas? Regards, KKokser On Mon, Feb 4, 2019 at 2:15 PM Aleksey Shipilev wrote: > On 2/4/19 1:42 PM, Herr Knack wrote: > > Could JIT be the problem? > > Yes, it could. > > > Does anyone know if the workflow of JIT > > optimizations is documented anywhere? > > Even if it was, it is unlikely to help you. You need to drill into what is > going on in the > benchmark. It is hard to do based on your current explanation, because > there is no benchmark code. > > > I hope someone can help, because I?m getting crazy about it. > Profile the benchmark with -prof perfasm at different workload sizes, and > that should highlight what > is the final generated code, which would give you some idea what might go > wrong. > > Thanks, > -Aleksey > > From ngortheone at gmail.com Mon Feb 4 19:37:12 2019 From: ngortheone at gmail.com (Ngor) Date: Mon, 4 Feb 2019 14:37:12 -0500 Subject: Question to JMH and JIT In-Reply-To: References: Message-ID: In addition I highly recommend reading the paper on the topic: Statistically Rigorous Java Performance Evaluation https://dri.es/files/oopsla07-georges.pdf On Mon, Feb 4, 2019 at 7:44 AM Herr Knack wrote: > Hey there, > > I currently try to find a mathematical model to compute the approximate > runtime of a function term out of its basic structure for my machine > (Ubuntu 16.04, i7-5500U, 2.40GHz?4). For first microbenchmark measurements > I used the JMH and measured the throughput of some simple functions (4 > different forks, 3 warmup and 5 measurement iterations each fork, 10 sec > time each iteration). > > I found out, that it is really difficult to see the connection between the > structure of the function term and its runtime in the microbenchmark. I > assume that the JIT compiler does some weird stuff to optimize the > functions, but I can?t see which optimizations in detail are done there. > > Could JIT be the problem? Does anyone know if the workflow of JIT > optimizations is documented anywhere? > > I hope someone can help, because I?m getting crazy about it. Here some > results I got. I converted the throughput (runs/sec) to a average time per > run in ns. The standard deviation is smaller as you might think, so the > average time is most likely correct in an area of +/-0.3 ns : > > - (((0.5 * x) * 0.5) * (((((0.5 * x) * 0.5) / 0.5) + (((0.5 * x) * 0.5) * > 0.5)) * (((0.5 * x) * 0.5) + x))) + x, 15 operations (3+, 11*, 1/), 28.09 > ns > > - x + ((((0.5 * x) * (0.5 * x)) * (0.5 * x)) + ((0.5 * x) * ((((0.5 * x) * > (0.5 * x)) * (0.5 * x)) * (((0.5 * x) * (0.5 * x)) / ((((0.5 * x) * ((0.5 * > x) * (0.5 * x))) / (0.5 + ((0.5 * x) * (0.5 * x)))) + (((0.5 * x) * (0.5 * > x)) * (0.5 * x))))))), 35 operations (4+,29*,2/), 38.61 ns > > - (((x / (x / (0.5 * x))) * (x / (x / (0.5 * x)))) * (0.5 * x)) + (x + > ((((x / (x / (0.5 * x))) * (x / (x / (0.5 * x)))) * (0.5 * x)) / (((x / > (0.5 * x)) + 0.5) - ((((x / (x / (0.5 * x))) * (x / (x / (0.5 * x)))) * > (0.5 * x)) * (x / (x / (0.5 * x))))))), 38 operations (4+-,18*,16/), 40.70 > ns > > I assume that there is an constant offset for method calls and so on. In > addition I suppose that already calculated term pieces don?t have to be > calculated again. But these conclusions did not help me either. > > Regards, > > KKokser > From david.holmes at oracle.com Mon Feb 4 22:57:41 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 5 Feb 2019 08:57:41 +1000 Subject: Question to JMH and JIT In-Reply-To: References: Message-ID: <1877ce95-6887-f0d9-26bf-1d2f0ac24e8f@oracle.com> Folks, This is not a suitable topic for the discuss list, please take technical discussions elsewhere. Thanks, David On 5/02/2019 5:37 am, Ngor wrote: > In addition I highly recommend reading the paper on the topic: > > Statistically Rigorous Java Performance Evaluation > https://dri.es/files/oopsla07-georges.pdf > > On Mon, Feb 4, 2019 at 7:44 AM Herr Knack wrote: > >> Hey there, >> >> I currently try to find a mathematical model to compute the approximate >> runtime of a function term out of its basic structure for my machine >> (Ubuntu 16.04, i7-5500U, 2.40GHz?4). For first microbenchmark measurements >> I used the JMH and measured the throughput of some simple functions (4 >> different forks, 3 warmup and 5 measurement iterations each fork, 10 sec >> time each iteration). >> >> I found out, that it is really difficult to see the connection between the >> structure of the function term and its runtime in the microbenchmark. I >> assume that the JIT compiler does some weird stuff to optimize the >> functions, but I can?t see which optimizations in detail are done there. >> >> Could JIT be the problem? Does anyone know if the workflow of JIT >> optimizations is documented anywhere? >> >> I hope someone can help, because I?m getting crazy about it. Here some >> results I got. I converted the throughput (runs/sec) to a average time per >> run in ns. The standard deviation is smaller as you might think, so the >> average time is most likely correct in an area of +/-0.3 ns : >> >> - (((0.5 * x) * 0.5) * (((((0.5 * x) * 0.5) / 0.5) + (((0.5 * x) * 0.5) * >> 0.5)) * (((0.5 * x) * 0.5) + x))) + x, 15 operations (3+, 11*, 1/), 28.09 >> ns >> >> - x + ((((0.5 * x) * (0.5 * x)) * (0.5 * x)) + ((0.5 * x) * ((((0.5 * x) * >> (0.5 * x)) * (0.5 * x)) * (((0.5 * x) * (0.5 * x)) / ((((0.5 * x) * ((0.5 * >> x) * (0.5 * x))) / (0.5 + ((0.5 * x) * (0.5 * x)))) + (((0.5 * x) * (0.5 * >> x)) * (0.5 * x))))))), 35 operations (4+,29*,2/), 38.61 ns >> >> - (((x / (x / (0.5 * x))) * (x / (x / (0.5 * x)))) * (0.5 * x)) + (x + >> ((((x / (x / (0.5 * x))) * (x / (x / (0.5 * x)))) * (0.5 * x)) / (((x / >> (0.5 * x)) + 0.5) - ((((x / (x / (0.5 * x))) * (x / (x / (0.5 * x)))) * >> (0.5 * x)) * (x / (x / (0.5 * x))))))), 38 operations (4+-,18*,16/), 40.70 >> ns >> >> I assume that there is an constant offset for method calls and so on. In >> addition I suppose that already calculated term pieces don?t have to be >> calculated again. But these conclusions did not help me either. >> >> Regards, >> >> KKokser >> From stokito at gmail.com Tue Feb 5 06:36:25 2019 From: stokito at gmail.com (Sergey Ponomarev) Date: Tue, 5 Feb 2019 08:36:25 +0200 Subject: Question to JMH and JIT In-Reply-To: <1877ce95-6887-f0d9-26bf-1d2f0ac24e8f@oracle.com> References: <1877ce95-6887-f0d9-26bf-1d2f0ac24e8f@oracle.com> Message-ID: Hi David, You are right and it's fairly a good point: maybe it worth to create some kind of usergroup list or forum topic where users can discuss results of benchmarking? And it might be good to create some FAQ or topic in the documentation with links to articles about performance optimization done by JIT. On Tue, 5 Feb 2019 at 07:59, David Holmes wrote: > Folks, > > This is not a suitable topic for the discuss list, please take technical > discussions elsewhere. > > Thanks, > David > > On 5/02/2019 5:37 am, Ngor wrote: > > In addition I highly recommend reading the paper on the topic: > > > > Statistically Rigorous Java Performance Evaluation > > https://dri.es/files/oopsla07-georges.pdf > > > > On Mon, Feb 4, 2019 at 7:44 AM Herr Knack > wrote: > > > >> Hey there, > >> > >> I currently try to find a mathematical model to compute the approximate > >> runtime of a function term out of its basic structure for my machine > >> (Ubuntu 16.04, i7-5500U, 2.40GHz?4). For first microbenchmark > measurements > >> I used the JMH and measured the throughput of some simple functions (4 > >> different forks, 3 warmup and 5 measurement iterations each fork, 10 sec > >> time each iteration). > >> > >> I found out, that it is really difficult to see the connection between > the > >> structure of the function term and its runtime in the microbenchmark. I > >> assume that the JIT compiler does some weird stuff to optimize the > >> functions, but I can?t see which optimizations in detail are done there. > >> > >> Could JIT be the problem? Does anyone know if the workflow of JIT > >> optimizations is documented anywhere? > >> > >> I hope someone can help, because I?m getting crazy about it. Here some > >> results I got. I converted the throughput (runs/sec) to a average time > per > >> run in ns. The standard deviation is smaller as you might think, so the > >> average time is most likely correct in an area of +/-0.3 ns : > >> > >> - (((0.5 * x) * 0.5) * (((((0.5 * x) * 0.5) / 0.5) + (((0.5 * x) * 0.5) > * > >> 0.5)) * (((0.5 * x) * 0.5) + x))) + x, 15 operations (3+, 11*, 1/), > 28.09 > >> ns > >> > >> - x + ((((0.5 * x) * (0.5 * x)) * (0.5 * x)) + ((0.5 * x) * ((((0.5 * > x) * > >> (0.5 * x)) * (0.5 * x)) * (((0.5 * x) * (0.5 * x)) / ((((0.5 * x) * > ((0.5 * > >> x) * (0.5 * x))) / (0.5 + ((0.5 * x) * (0.5 * x)))) + (((0.5 * x) * > (0.5 * > >> x)) * (0.5 * x))))))), 35 operations (4+,29*,2/), 38.61 ns > >> > >> - (((x / (x / (0.5 * x))) * (x / (x / (0.5 * x)))) * (0.5 * x)) + (x + > >> ((((x / (x / (0.5 * x))) * (x / (x / (0.5 * x)))) * (0.5 * x)) / (((x / > >> (0.5 * x)) + 0.5) - ((((x / (x / (0.5 * x))) * (x / (x / (0.5 * x)))) * > >> (0.5 * x)) * (x / (x / (0.5 * x))))))), 38 operations (4+-,18*,16/), > 40.70 > >> ns > >> > >> I assume that there is an constant offset for method calls and so on. In > >> addition I suppose that already calculated term pieces don?t have to be > >> calculated again. But these conclusions did not help me either. > >> > >> Regards, > >> > >> KKokser > >> > -- Sergey Ponomarev , skype:stokito From vusonlam at t-online.de Mon Feb 11 17:04:32 2019 From: vusonlam at t-online.de (vusonlam at t-online.de) Date: Mon, 11 Feb 2019 18:04:32 +0100 (CET) Subject: javax.xml.ws.WebServiceException: Failed to access the WSDL at: https:// and Server returned HTTP response code: 401 for URL: https:// Message-ID: <1549904672238.1863914.ba6cd2027f824eb2de613546f9360b60647da4ef@spica.telekom.de> Hello, we have now a issue with Java and need your help. In the Java version 1.8.0-201 (both OPENJDK and Oracle Java) we?re getting the erros by accessing to our web service in SAP: javax.xml.ws.WebServiceException: Failed to access the WSDL at: https:// ? Server returned HTTP response code: 401 for URL: https://... But if we start the application with Java Web Service (javaws) then the users get an authentication form to put their login data into. Could you please say us, what you have to do to get the login form when we start the application outside of javaws (also with java). Any help will be highly appreciated! Lam Vu ? From martijnverburg at gmail.com Mon Feb 11 20:03:33 2019 From: martijnverburg at gmail.com (Martijn Verburg) Date: Mon, 11 Feb 2019 20:03:33 +0000 Subject: javax.xml.ws.WebServiceException: Failed to access the WSDL at: https:// and Server returned HTTP response code: 401 for URL: https:// In-Reply-To: <1549904672238.1863914.ba6cd2027f824eb2de613546f9360b60647da4ef@spica.telekom.de> References: <1549904672238.1863914.ba6cd2027f824eb2de613546f9360b60647da4ef@spica.telekom.de> Message-ID: Hi Lam Vu, Welcome to OpenJDK. Unfortunately, this is the incorrect mailing list to report bugs too! I would strongly recommend writing up a full report with a lot more detail and post it to StackOverflow or your application server provide (looks like SAP in this case). Cheers, Martijn On Mon, 11 Feb 2019 at 17:05, vusonlam at t-online.de wrote: > Hello, > > we have now a issue with Java and need your help. > > In the Java version 1.8.0-201 (both OPENJDK and Oracle Java) we?re getting > the erros by accessing to our web service in SAP: > javax.xml.ws.WebServiceException: Failed to access the WSDL at: https:// > ? > Server returned HTTP response code: 401 for URL: https://... > > But if we start the application with Java Web Service (javaws) then the > users get an authentication form to put their login data into. > > Could you please say us, what you have to do to get the login form when we > start the application outside of javaws (also with java). > > Any help will be highly appreciated! > > Lam Vu > > ? > From jcbeyler at google.com Wed Feb 13 23:32:01 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Wed, 13 Feb 2019 15:32:01 -0800 Subject: Call For Vote: New Project Tsan Message-ID: Hello, I hereby propose the creation of the Tsan Project with Jean Christophe Beyler as the Lead and the Serviceability Group as the sponsoring Group. In accordance with the OpenJDK guidelines [1], the TSAN project would provide a venue to explore and incubate a Thread SANitizing (TSAN) feature that could be integrated into the Hotspot JVM and the JVM Tool Interface. This includes working, evaluating, and incubating a Thread-Sanitizer implementation [2] for Java. The Google platform team has historically worked on a Thread SANitizing (TSAN) project internally. Thread sanitizing allows Java users to see data race conditions in their Java projects. It is used internally to automatically detect and warn users of existing data races detected while running user code. The TSAN project proposes to investigate, in the open, how these changes could be made general enough to be pushed into the mainline, or should be dropped due to being too specific or could be done using other existing mechanisms. The project would not be a Google-only project and will have a mailing list to discuss and potentially accept any contribution trying to extend and/or enhance the TSAN implementation. The evaluation criteria for the TSAN implementation includes but would not be limited to: * Performance: not adding overhead to non-tsan runs is paramount and there are various means to do so * General usefulness for the community at large so that the TSAN feature is deemed a good feature to have If the TSAN implementation becomes stable and is deemed useful enough, the TSAN project would shepherd the work in one or more JEPs to integrate TSAN into the mainline of OpenJDK. The Tsan project scope was discussed during the call for discussion for the Atlantis project [3]. It was determined that the Atlantis project's scope was not well defined and it would be better to start with a separate Tsan project with an end goal and better determined boundaries. The current suggested initial Reviewers and Committers would be but is most likely not going to be limited to (alphabetical order of first name): * Alex Menkov (amenkov) * Chuck Rasbold (rasbold) * Daniil Titov (dtitov) * Jean Christophe Beyler (jcbeyler) * Liam Cushon (cushon) * Serguei Spitsyn (sspitsyn) Votes are due by Wednesday 27, 23:59 pm Pacific Time. Only current OpenJDK Members [3] are eligible to vote on this motion. Votes must be cast in the open on the discuss list. Replying to this message is sufficient if your mail program honors the Reply-To header. For Lazy Consensus voting instructions, see [5]. Thanks, Jc [1] http://openjdk.java.net/projects/#new-project [2] https://bugs.openjdk.java.net/browse/JDK-8208520 [3] https://mail.openjdk.java.net/pipermail/discuss/2018-November/004904.html [4] http://openjdk.java.net/census#members [5] http://openjdk.java.net/projects/#new-project-vote From serguei.spitsyn at oracle.com Wed Feb 13 23:44:51 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 13 Feb 2019 15:44:51 -0800 Subject: Call For Vote: New Project Tsan In-Reply-To: References: Message-ID: <459533b0-45e7-71cc-4095-2eed7dbde465@oracle.com> Vote: yes From martinrb at google.com Thu Feb 14 00:08:04 2019 From: martinrb at google.com (Martin Buchholz) Date: Wed, 13 Feb 2019 16:08:04 -0800 Subject: Call For Vote: New Project Tsan In-Reply-To: <459533b0-45e7-71cc-4095-2eed7dbde465@oracle.com> References: <459533b0-45e7-71cc-4095-2eed7dbde465@oracle.com> Message-ID: Jean Christophe's Call For Vote ended up in my Spam folder JDK-8213225 From jcbeyler at google.com Thu Feb 14 00:35:34 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Wed, 13 Feb 2019 16:35:34 -0800 Subject: Call For Vote: New Project Tsan In-Reply-To: <459533b0-45e7-71cc-4095-2eed7dbde465@oracle.com> References: <459533b0-45e7-71cc-4095-2eed7dbde465@oracle.com> Message-ID: Hi all, My apologies, I should have sent the CFV in the announce list and not the discuss list. The thread is now created there: https://mail.openjdk.java.net/pipermail/announce/2019-February/000262.html Thanks and my apologies again, Jc On Wed, Feb 13, 2019 at 3:45 PM serguei.spitsyn at oracle.com < serguei.spitsyn at oracle.com> wrote: > Vote: yes > -- Thanks, Jc From thomas.stuefe at gmail.com Thu Feb 14 06:35:47 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 14 Feb 2019 07:35:47 +0100 Subject: Call For Vote: Project Tsan In-Reply-To: References: Message-ID: Vote: yes On Thu, Feb 14, 2019 at 1:08 AM Jean Christophe Beyler wrote: > Hello, > > I hereby propose the creation of the Tsan Project with Jean Christophe > Beyler as the Lead and the Serviceability Group as the sponsoring Group. > > In accordance with the OpenJDK guidelines [1], the TSAN project would > provide a venue to explore and incubate a Thread SANitizing (TSAN) feature > that could be integrated into the Hotspot JVM and the JVM Tool Interface. > This includes working, evaluating, and incubating a Thread-Sanitizer > implementation [2] for Java. > > The Google platform team has historically worked on a Thread SANitizing > (TSAN) project internally. Thread sanitizing allows Java users to see data > race conditions in their Java projects. It is used internally to > automatically detect and warn users of existing data races detected while > running user code. The TSAN project proposes to investigate, in the open, > how these changes could be made general enough to be pushed into the > mainline, or should be dropped due to being too specific or could be done > using other existing mechanisms. The project would not be a Google-only > project and will have a mailing list to discuss and potentially accept any > contribution trying to extend and/or enhance the TSAN implementation. > > The evaluation criteria for the TSAN implementation includes but would not > be limited to: > * Performance: not adding overhead to non-tsan runs is paramount and > there are various means to do so > * General usefulness for the community at large so that the TSAN > feature is deemed a good feature to have > > If the TSAN implementation becomes stable and is deemed useful enough, the > TSAN project would shepherd the work in one or more JEPs to integrate TSAN > into the mainline of OpenJDK. > > The Tsan project scope was discussed during the call for discussion for the > Atlantis project [3]. It was determined that the Atlantis project's scope > was not well defined and it would be better to start with a separate Tsan > project with an end goal and better determined boundaries. > > The current suggested initial Reviewers and Committers would be but is most > likely not going to be limited to (alphabetical order of first name): > * Alex Menkov (amenkov) > * Chuck Rasbold (rasbold) > * Daniil Titov (dtitov) > * Jean Christophe Beyler (jcbeyler) > * Liam Cushon (cushon) > * Serguei Spitsyn (sspitsyn) > > > Votes are due by Wednesday 27, 23:59 pm Pacific Time. > > Only current OpenJDK Members [3] are eligible to vote on this motion. > Votes must be cast in the open on the discuss list. Replying to this > message is sufficient if your mail program honors the Reply-To header. > > For Lazy Consensus voting instructions, see [5]. > > Thanks, > Jc > > [1] http://openjdk.java.net/projects/#new-project > [2] https://bugs.openjdk.java.net/browse/JDK-8208520 > [3] > https://mail.openjdk.java.net/pipermail/discuss/2018-November/004904.html > [4] http://openjdk.java.net/census#members > [5] http://openjdk.java.net/projects/#new-project-vote > From volker.simonis at gmail.com Thu Feb 14 07:44:56 2019 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 14 Feb 2019 08:44:56 +0100 Subject: Call For Vote: Project Tsan In-Reply-To: References: Message-ID: Vote: yes On Thu, Feb 14, 2019 at 1:08 AM Jean Christophe Beyler wrote: > > Hello, > > I hereby propose the creation of the Tsan Project with Jean Christophe > Beyler as the Lead and the Serviceability Group as the sponsoring Group. > > In accordance with the OpenJDK guidelines [1], the TSAN project would > provide a venue to explore and incubate a Thread SANitizing (TSAN) feature > that could be integrated into the Hotspot JVM and the JVM Tool Interface. > This includes working, evaluating, and incubating a Thread-Sanitizer > implementation [2] for Java. > > The Google platform team has historically worked on a Thread SANitizing > (TSAN) project internally. Thread sanitizing allows Java users to see data > race conditions in their Java projects. It is used internally to > automatically detect and warn users of existing data races detected while > running user code. The TSAN project proposes to investigate, in the open, > how these changes could be made general enough to be pushed into the > mainline, or should be dropped due to being too specific or could be done > using other existing mechanisms. The project would not be a Google-only > project and will have a mailing list to discuss and potentially accept any > contribution trying to extend and/or enhance the TSAN implementation. > > The evaluation criteria for the TSAN implementation includes but would not > be limited to: > * Performance: not adding overhead to non-tsan runs is paramount and > there are various means to do so > * General usefulness for the community at large so that the TSAN > feature is deemed a good feature to have > > If the TSAN implementation becomes stable and is deemed useful enough, the > TSAN project would shepherd the work in one or more JEPs to integrate TSAN > into the mainline of OpenJDK. > > The Tsan project scope was discussed during the call for discussion for the > Atlantis project [3]. It was determined that the Atlantis project's scope > was not well defined and it would be better to start with a separate Tsan > project with an end goal and better determined boundaries. > > The current suggested initial Reviewers and Committers would be but is most > likely not going to be limited to (alphabetical order of first name): > * Alex Menkov (amenkov) > * Chuck Rasbold (rasbold) > * Daniil Titov (dtitov) > * Jean Christophe Beyler (jcbeyler) > * Liam Cushon (cushon) > * Serguei Spitsyn (sspitsyn) > > > Votes are due by Wednesday 27, 23:59 pm Pacific Time. > > Only current OpenJDK Members [3] are eligible to vote on this motion. > Votes must be cast in the open on the discuss list. Replying to this > message is sufficient if your mail program honors the Reply-To header. > > For Lazy Consensus voting instructions, see [5]. > > Thanks, > Jc > > [1] http://openjdk.java.net/projects/#new-project > [2] https://bugs.openjdk.java.net/browse/JDK-8208520 > [3] > https://mail.openjdk.java.net/pipermail/discuss/2018-November/004904.html > [4] http://openjdk.java.net/census#members > [5] http://openjdk.java.net/projects/#new-project-vote From thomas.stuefe at gmail.com Thu Feb 14 07:48:56 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 14 Feb 2019 08:48:56 +0100 Subject: Call For Vote: Project Tsan In-Reply-To: References: Message-ID: Oops, misread that. Sorry for the noise, pls ignore my mail. On Thu, Feb 14, 2019 at 7:35 AM Thomas St?fe wrote: > Vote: yes > > On Thu, Feb 14, 2019 at 1:08 AM Jean Christophe Beyler < > jcbeyler at google.com> wrote: > >> Hello, >> >> I hereby propose the creation of the Tsan Project with Jean Christophe >> Beyler as the Lead and the Serviceability Group as the sponsoring Group. >> >> In accordance with the OpenJDK guidelines [1], the TSAN project would >> provide a venue to explore and incubate a Thread SANitizing (TSAN) feature >> that could be integrated into the Hotspot JVM and the JVM Tool Interface. >> This includes working, evaluating, and incubating a Thread-Sanitizer >> implementation [2] for Java. >> >> The Google platform team has historically worked on a Thread SANitizing >> (TSAN) project internally. Thread sanitizing allows Java users to see data >> race conditions in their Java projects. It is used internally to >> automatically detect and warn users of existing data races detected while >> running user code. The TSAN project proposes to investigate, in the open, >> how these changes could be made general enough to be pushed into the >> mainline, or should be dropped due to being too specific or could be done >> using other existing mechanisms. The project would not be a Google-only >> project and will have a mailing list to discuss and potentially accept any >> contribution trying to extend and/or enhance the TSAN implementation. >> >> The evaluation criteria for the TSAN implementation includes but would not >> be limited to: >> * Performance: not adding overhead to non-tsan runs is paramount and >> there are various means to do so >> * General usefulness for the community at large so that the TSAN >> feature is deemed a good feature to have >> >> If the TSAN implementation becomes stable and is deemed useful enough, the >> TSAN project would shepherd the work in one or more JEPs to integrate TSAN >> into the mainline of OpenJDK. >> >> The Tsan project scope was discussed during the call for discussion for >> the >> Atlantis project [3]. It was determined that the Atlantis project's scope >> was not well defined and it would be better to start with a separate Tsan >> project with an end goal and better determined boundaries. >> >> The current suggested initial Reviewers and Committers would be but is >> most >> likely not going to be limited to (alphabetical order of first name): >> * Alex Menkov (amenkov) >> * Chuck Rasbold (rasbold) >> * Daniil Titov (dtitov) >> * Jean Christophe Beyler (jcbeyler) >> * Liam Cushon (cushon) >> * Serguei Spitsyn (sspitsyn) >> >> >> Votes are due by Wednesday 27, 23:59 pm Pacific Time. >> >> Only current OpenJDK Members [3] are eligible to vote on this motion. >> Votes must be cast in the open on the discuss list. Replying to this >> message is sufficient if your mail program honors the Reply-To header. >> >> For Lazy Consensus voting instructions, see [5]. >> >> Thanks, >> Jc >> >> [1] http://openjdk.java.net/projects/#new-project >> [2] https://bugs.openjdk.java.net/browse/JDK-8208520 >> [3] >> https://mail.openjdk.java.net/pipermail/discuss/2018-November/004904.html >> [4] http://openjdk.java.net/census#members >> [5] http://openjdk.java.net/projects/#new-project-vote >> > From roman at kennke.org Thu Feb 14 09:32:42 2019 From: roman at kennke.org (Roman Kennke) Date: Thu, 14 Feb 2019 10:32:42 +0100 Subject: Call For Vote: Project Tsan In-Reply-To: References: Message-ID: <2e237648-6f15-4d62-6bee-dfaa92e217c4@kennke.org> Vote: yes Thanks! Roman > Hello, > > I hereby propose the creation of the Tsan Project with Jean Christophe > Beyler as the Lead and the Serviceability Group as the sponsoring Group. > > In accordance with the OpenJDK guidelines [1], the TSAN project would > provide a venue to explore and incubate a Thread SANitizing (TSAN) feature > that could be integrated into the Hotspot JVM and the JVM Tool Interface. > This includes working, evaluating, and incubating a Thread-Sanitizer > implementation [2] for Java. > > The Google platform team has historically worked on a Thread SANitizing > (TSAN) project internally. Thread sanitizing allows Java users to see data > race conditions in their Java projects. It is used internally to > automatically detect and warn users of existing data races detected while > running user code. The TSAN project proposes to investigate, in the open, > how these changes could be made general enough to be pushed into the > mainline, or should be dropped due to being too specific or could be done > using other existing mechanisms. The project would not be a Google-only > project and will have a mailing list to discuss and potentially accept any > contribution trying to extend and/or enhance the TSAN implementation. > > The evaluation criteria for the TSAN implementation includes but would not > be limited to: > * Performance: not adding overhead to non-tsan runs is paramount and > there are various means to do so > * General usefulness for the community at large so that the TSAN > feature is deemed a good feature to have > > If the TSAN implementation becomes stable and is deemed useful enough, the > TSAN project would shepherd the work in one or more JEPs to integrate TSAN > into the mainline of OpenJDK. > > The Tsan project scope was discussed during the call for discussion for the > Atlantis project [3]. It was determined that the Atlantis project's scope > was not well defined and it would be better to start with a separate Tsan > project with an end goal and better determined boundaries. > > The current suggested initial Reviewers and Committers would be but is most > likely not going to be limited to (alphabetical order of first name): > * Alex Menkov (amenkov) > * Chuck Rasbold (rasbold) > * Daniil Titov (dtitov) > * Jean Christophe Beyler (jcbeyler) > * Liam Cushon (cushon) > * Serguei Spitsyn (sspitsyn) > > > Votes are due by Wednesday 27, 23:59 pm Pacific Time. > > Only current OpenJDK Members [3] are eligible to vote on this motion. > Votes must be cast in the open on the discuss list. Replying to this > message is sufficient if your mail program honors the Reply-To header. > > For Lazy Consensus voting instructions, see [5]. > > Thanks, > Jc > > [1] http://openjdk.java.net/projects/#new-project > [2] https://bugs.openjdk.java.net/browse/JDK-8208520 > [3] > https://mail.openjdk.java.net/pipermail/discuss/2018-November/004904.html > [4] http://openjdk.java.net/census#members > [5] http://openjdk.java.net/projects/#new-project-vote > From fweimer at redhat.com Thu Feb 14 13:50:35 2019 From: fweimer at redhat.com (Florian Weimer) Date: Thu, 14 Feb 2019 14:50:35 +0100 Subject: Call For Vote: Project Tsan In-Reply-To: (Jean Christophe Beyler's message of "Wed, 13 Feb 2019 16:02:10 -0800") References: Message-ID: <871s4aiims.fsf@oldenburg2.str.redhat.com> * Jean Christophe Beyler: > The evaluation criteria for the TSAN implementation includes but would not > be limited to: > * Performance: not adding overhead to non-tsan runs is paramount and > there are various means to do so > * General usefulness for the community at large so that the TSAN > feature is deemed a good feature to have Is there any relationship with the native TSAN implementation in LLVM? Thanks, Florian From serguei.spitsyn at oracle.com Thu Feb 14 15:39:45 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 14 Feb 2019 07:39:45 -0800 Subject: Call For Vote: New Project Tsan In-Reply-To: References: Message-ID: <0e02000b-c784-000c-bf89-b8c8770fc7d7@oracle.com> Vote: yes On 2/13/19 15:32, Jean Christophe Beyler wrote: > Hello, > > I hereby propose the creation of the Tsan Project with Jean Christophe > Beyler as the Lead and the Serviceability Group as the sponsoring Group. > > In accordance with the OpenJDK guidelines [1], the TSAN project would > provide a venue to explore and incubate a Thread SANitizing (TSAN) feature > that could be integrated into the Hotspot JVM and the JVM Tool Interface. > This includes working, evaluating, and incubating a Thread-Sanitizer > implementation [2] for Java. > > The Google platform team has historically worked on a Thread SANitizing > (TSAN) project internally. Thread sanitizing allows Java users to see data > race conditions in their Java projects. It is used internally to > automatically detect and warn users of existing data races detected while > running user code. The TSAN project proposes to investigate, in the open, > how these changes could be made general enough to be pushed into the > mainline, or should be dropped due to being too specific or could be done > using other existing mechanisms. The project would not be a Google-only > project and will have a mailing list to discuss and potentially accept any > contribution trying to extend and/or enhance the TSAN implementation. > > The evaluation criteria for the TSAN implementation includes but would not > be limited to: > * Performance: not adding overhead to non-tsan runs is paramount and > there are various means to do so > * General usefulness for the community at large so that the TSAN > feature is deemed a good feature to have > > If the TSAN implementation becomes stable and is deemed useful enough, the > TSAN project would shepherd the work in one or more JEPs to integrate TSAN > into the mainline of OpenJDK. > > The Tsan project scope was discussed during the call for discussion for the > Atlantis project [3]. It was determined that the Atlantis project's scope > was not well defined and it would be better to start with a separate Tsan > project with an end goal and better determined boundaries. > > The current suggested initial Reviewers and Committers would be but is most > likely not going to be limited to (alphabetical order of first name): > * Alex Menkov (amenkov) > * Chuck Rasbold (rasbold) > * Daniil Titov (dtitov) > * Jean Christophe Beyler (jcbeyler) > * Liam Cushon (cushon) > * Serguei Spitsyn (sspitsyn) > > > Votes are due by Wednesday 27, 23:59 pm Pacific Time. > > Only current OpenJDK Members [3] are eligible to vote on this motion. > Votes must be cast in the open on the discuss list. Replying to this > message is sufficient if your mail program honors the Reply-To header. > > For Lazy Consensus voting instructions, see [5]. > > Thanks, > Jc > > [1] http://openjdk.java.net/projects/#new-project > [2] https://bugs.openjdk.java.net/browse/JDK-8208520 > [3] > https://mail.openjdk.java.net/pipermail/discuss/2018-November/004904.html > [4] http://openjdk.java.net/census#members > [5] http://openjdk.java.net/projects/#new-project-vote From karen.kinnear at oracle.com Thu Feb 14 17:11:30 2019 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 14 Feb 2019 12:11:30 -0500 Subject: Call For Vote: Project Tsan In-Reply-To: References: Message-ID: vote: yes thanks, Karen > On Feb 13, 2019, at 7:02 PM, Jean Christophe Beyler wrote: > > Hello, > > I hereby propose the creation of the Tsan Project with Jean Christophe > Beyler as the Lead and the Serviceability Group as the sponsoring Group. > > In accordance with the OpenJDK guidelines [1], the TSAN project would > provide a venue to explore and incubate a Thread SANitizing (TSAN) feature > that could be integrated into the Hotspot JVM and the JVM Tool Interface. > This includes working, evaluating, and incubating a Thread-Sanitizer > implementation [2] for Java. > > The Google platform team has historically worked on a Thread SANitizing > (TSAN) project internally. Thread sanitizing allows Java users to see data > race conditions in their Java projects. It is used internally to > automatically detect and warn users of existing data races detected while > running user code. The TSAN project proposes to investigate, in the open, > how these changes could be made general enough to be pushed into the > mainline, or should be dropped due to being too specific or could be done > using other existing mechanisms. The project would not be a Google-only > project and will have a mailing list to discuss and potentially accept any > contribution trying to extend and/or enhance the TSAN implementation. > > The evaluation criteria for the TSAN implementation includes but would not > be limited to: > * Performance: not adding overhead to non-tsan runs is paramount and > there are various means to do so > * General usefulness for the community at large so that the TSAN > feature is deemed a good feature to have > > If the TSAN implementation becomes stable and is deemed useful enough, the > TSAN project would shepherd the work in one or more JEPs to integrate TSAN > into the mainline of OpenJDK. > > The Tsan project scope was discussed during the call for discussion for the > Atlantis project [3]. It was determined that the Atlantis project's scope > was not well defined and it would be better to start with a separate Tsan > project with an end goal and better determined boundaries. > > The current suggested initial Reviewers and Committers would be but is most > likely not going to be limited to (alphabetical order of first name): > * Alex Menkov (amenkov) > * Chuck Rasbold (rasbold) > * Daniil Titov (dtitov) > * Jean Christophe Beyler (jcbeyler) > * Liam Cushon (cushon) > * Serguei Spitsyn (sspitsyn) > > > Votes are due by Wednesday 27, 23:59 pm Pacific Time. > > Only current OpenJDK Members [3] are eligible to vote on this motion. > Votes must be cast in the open on the discuss list. Replying to this > message is sufficient if your mail program honors the Reply-To header. > > For Lazy Consensus voting instructions, see [5]. > > Thanks, > Jc > > [1] http://openjdk.java.net/projects/#new-project > [2] https://bugs.openjdk.java.net/browse/JDK-8208520 > [3] > https://mail.openjdk.java.net/pipermail/discuss/2018-November/004904.html > [4] http://openjdk.java.net/census#members > [5] http://openjdk.java.net/projects/#new-project-vote From martinrb at google.com Thu Feb 14 17:17:38 2019 From: martinrb at google.com (Martin Buchholz) Date: Thu, 14 Feb 2019 09:17:38 -0800 Subject: Call For Vote: Project Tsan In-Reply-To: References: Message-ID: Vote: yes From rasbold at google.com Thu Feb 14 18:51:12 2019 From: rasbold at google.com (Chuck Rasbold) Date: Thu, 14 Feb 2019 10:51:12 -0800 Subject: Call For Vote: Project Tsan In-Reply-To: References: Message-ID: Vote: yes On Wed, Feb 13, 2019 at 4:09 PM Jean Christophe Beyler wrote: > Hello, > > I hereby propose the creation of the Tsan Project with Jean Christophe > Beyler as the Lead and the Serviceability Group as the sponsoring Group. > > In accordance with the OpenJDK guidelines [1], the TSAN project would > provide a venue to explore and incubate a Thread SANitizing (TSAN) feature > that could be integrated into the Hotspot JVM and the JVM Tool Interface. > This includes working, evaluating, and incubating a Thread-Sanitizer > implementation [2] for Java. > > The Google platform team has historically worked on a Thread SANitizing > (TSAN) project internally. Thread sanitizing allows Java users to see data > race conditions in their Java projects. It is used internally to > automatically detect and warn users of existing data races detected while > running user code. The TSAN project proposes to investigate, in the open, > how these changes could be made general enough to be pushed into the > mainline, or should be dropped due to being too specific or could be done > using other existing mechanisms. The project would not be a Google-only > project and will have a mailing list to discuss and potentially accept any > contribution trying to extend and/or enhance the TSAN implementation. > > The evaluation criteria for the TSAN implementation includes but would not > be limited to: > * Performance: not adding overhead to non-tsan runs is paramount and > there are various means to do so > * General usefulness for the community at large so that the TSAN > feature is deemed a good feature to have > > If the TSAN implementation becomes stable and is deemed useful enough, the > TSAN project would shepherd the work in one or more JEPs to integrate TSAN > into the mainline of OpenJDK. > > The Tsan project scope was discussed during the call for discussion for the > Atlantis project [3]. It was determined that the Atlantis project's scope > was not well defined and it would be better to start with a separate Tsan > project with an end goal and better determined boundaries. > > The current suggested initial Reviewers and Committers would be but is most > likely not going to be limited to (alphabetical order of first name): > * Alex Menkov (amenkov) > * Chuck Rasbold (rasbold) > * Daniil Titov (dtitov) > * Jean Christophe Beyler (jcbeyler) > * Liam Cushon (cushon) > * Serguei Spitsyn (sspitsyn) > > > Votes are due by Wednesday 27, 23:59 pm Pacific Time. > > Only current OpenJDK Members [3] are eligible to vote on this motion. > Votes must be cast in the open on the discuss list. Replying to this > message is sufficient if your mail program honors the Reply-To header. > > For Lazy Consensus voting instructions, see [5]. > > Thanks, > Jc > > [1] http://openjdk.java.net/projects/#new-project > [2] https://bugs.openjdk.java.net/browse/JDK-8208520 > [3] > https://mail.openjdk.java.net/pipermail/discuss/2018-November/004904.html > [4] http://openjdk.java.net/census#members > [5] http://openjdk.java.net/projects/#new-project-vote > From magnus.ihse.bursie at oracle.com Thu Feb 14 19:41:19 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 14 Feb 2019 20:41:19 +0100 Subject: Call For Vote: Project Tsan In-Reply-To: References: Message-ID: Vote: yes /Magnus On 2019-02-14 01:02, Jean Christophe Beyler wrote: > Hello, > > I hereby propose the creation of the Tsan Project with Jean Christophe > Beyler as the Lead and the Serviceability Group as the sponsoring Group. > > In accordance with the OpenJDK guidelines [1], the TSAN project would > provide a venue to explore and incubate a Thread SANitizing (TSAN) feature > that could be integrated into the Hotspot JVM and the JVM Tool Interface. > This includes working, evaluating, and incubating a Thread-Sanitizer > implementation [2] for Java. > > The Google platform team has historically worked on a Thread SANitizing > (TSAN) project internally. Thread sanitizing allows Java users to see data > race conditions in their Java projects. It is used internally to > automatically detect and warn users of existing data races detected while > running user code. The TSAN project proposes to investigate, in the open, > how these changes could be made general enough to be pushed into the > mainline, or should be dropped due to being too specific or could be done > using other existing mechanisms. The project would not be a Google-only > project and will have a mailing list to discuss and potentially accept any > contribution trying to extend and/or enhance the TSAN implementation. > > The evaluation criteria for the TSAN implementation includes but would not > be limited to: > * Performance: not adding overhead to non-tsan runs is paramount and > there are various means to do so > * General usefulness for the community at large so that the TSAN > feature is deemed a good feature to have > > If the TSAN implementation becomes stable and is deemed useful enough, the > TSAN project would shepherd the work in one or more JEPs to integrate TSAN > into the mainline of OpenJDK. > > The Tsan project scope was discussed during the call for discussion for the > Atlantis project [3]. It was determined that the Atlantis project's scope > was not well defined and it would be better to start with a separate Tsan > project with an end goal and better determined boundaries. > > The current suggested initial Reviewers and Committers would be but is most > likely not going to be limited to (alphabetical order of first name): > * Alex Menkov (amenkov) > * Chuck Rasbold (rasbold) > * Daniil Titov (dtitov) > * Jean Christophe Beyler (jcbeyler) > * Liam Cushon (cushon) > * Serguei Spitsyn (sspitsyn) > > > Votes are due by Wednesday 27, 23:59 pm Pacific Time. > > Only current OpenJDK Members [3] are eligible to vote on this motion. > Votes must be cast in the open on the discuss list. Replying to this > message is sufficient if your mail program honors the Reply-To header. > > For Lazy Consensus voting instructions, see [5]. > > Thanks, > Jc > > [1] http://openjdk.java.net/projects/#new-project > [2] https://bugs.openjdk.java.net/browse/JDK-8208520 > [3] > https://mail.openjdk.java.net/pipermail/discuss/2018-November/004904.html > [4] http://openjdk.java.net/census#members > [5] http://openjdk.java.net/projects/#new-project-vote From jcbeyler at google.com Thu Feb 14 20:54:23 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Thu, 14 Feb 2019 12:54:23 -0800 Subject: Call For Vote: Project Tsan In-Reply-To: <871s4aiims.fsf@oldenburg2.str.redhat.com> References: <871s4aiims.fsf@oldenburg2.str.redhat.com> Message-ID: Hi Florian, Our internal version is built on top of it so we currently are planning to do the same in this project. Are there any issues you can foresee with doing this? Jc On Thu, Feb 14, 2019 at 5:50 AM Florian Weimer wrote: > * Jean Christophe Beyler: > > > The evaluation criteria for the TSAN implementation includes but would > not > > be limited to: > > * Performance: not adding overhead to non-tsan runs is paramount and > > there are various means to do so > > * General usefulness for the community at large so that the TSAN > > feature is deemed a good feature to have > > Is there any relationship with the native TSAN implementation in LLVM? > > Thanks, > Florian > -- Thanks, Jc From vladimir.kozlov at oracle.com Thu Feb 14 22:37:56 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 14 Feb 2019 14:37:56 -0800 Subject: Call For Vote: Project Tsan In-Reply-To: References: Message-ID: <2a551ccc-9434-4f1e-affd-db15624e6410@oracle.com> Vote: yes On 2/13/19 4:02 PM, Jean Christophe Beyler wrote: > Hello, > > I hereby propose the creation of the Tsan Project with Jean Christophe > Beyler as the Lead and the Serviceability Group as the sponsoring Group. > > In accordance with the OpenJDK guidelines [1], the TSAN project would > provide a venue to explore and incubate a Thread SANitizing (TSAN) feature > that could be integrated into the Hotspot JVM and the JVM Tool Interface. > This includes working, evaluating, and incubating a Thread-Sanitizer > implementation [2] for Java. > > The Google platform team has historically worked on a Thread SANitizing > (TSAN) project internally. Thread sanitizing allows Java users to see data > race conditions in their Java projects. It is used internally to > automatically detect and warn users of existing data races detected while > running user code. The TSAN project proposes to investigate, in the open, > how these changes could be made general enough to be pushed into the > mainline, or should be dropped due to being too specific or could be done > using other existing mechanisms. The project would not be a Google-only > project and will have a mailing list to discuss and potentially accept any > contribution trying to extend and/or enhance the TSAN implementation. > > The evaluation criteria for the TSAN implementation includes but would not > be limited to: > * Performance: not adding overhead to non-tsan runs is paramount and > there are various means to do so > * General usefulness for the community at large so that the TSAN > feature is deemed a good feature to have > > If the TSAN implementation becomes stable and is deemed useful enough, the > TSAN project would shepherd the work in one or more JEPs to integrate TSAN > into the mainline of OpenJDK. > > The Tsan project scope was discussed during the call for discussion for the > Atlantis project [3]. It was determined that the Atlantis project's scope > was not well defined and it would be better to start with a separate Tsan > project with an end goal and better determined boundaries. > > The current suggested initial Reviewers and Committers would be but is most > likely not going to be limited to (alphabetical order of first name): > * Alex Menkov (amenkov) > * Chuck Rasbold (rasbold) > * Daniil Titov (dtitov) > * Jean Christophe Beyler (jcbeyler) > * Liam Cushon (cushon) > * Serguei Spitsyn (sspitsyn) > > > Votes are due by Wednesday 27, 23:59 pm Pacific Time. > > Only current OpenJDK Members [3] are eligible to vote on this motion. > Votes must be cast in the open on the discuss list. Replying to this > message is sufficient if your mail program honors the Reply-To header. > > For Lazy Consensus voting instructions, see [5]. > > Thanks, > Jc > > [1] http://openjdk.java.net/projects/#new-project > [2] https://bugs.openjdk.java.net/browse/JDK-8208520 > [3] > https://mail.openjdk.java.net/pipermail/discuss/2018-November/004904.html > [4] http://openjdk.java.net/census#members > [5] http://openjdk.java.net/projects/#new-project-vote > From jesper.wilhelmsson at oracle.com Fri Feb 15 01:41:43 2019 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Fri, 15 Feb 2019 02:41:43 +0100 Subject: Call For Vote: Project Tsan In-Reply-To: References: Message-ID: Vote: Yes /Jesper > On 14 Feb 2019, at 01:02, Jean Christophe Beyler wrote: > > Hello, > > I hereby propose the creation of the Tsan Project with Jean Christophe > Beyler as the Lead and the Serviceability Group as the sponsoring Group. > > In accordance with the OpenJDK guidelines [1], the TSAN project would > provide a venue to explore and incubate a Thread SANitizing (TSAN) feature > that could be integrated into the Hotspot JVM and the JVM Tool Interface. > This includes working, evaluating, and incubating a Thread-Sanitizer > implementation [2] for Java. > > The Google platform team has historically worked on a Thread SANitizing > (TSAN) project internally. Thread sanitizing allows Java users to see data > race conditions in their Java projects. It is used internally to > automatically detect and warn users of existing data races detected while > running user code. The TSAN project proposes to investigate, in the open, > how these changes could be made general enough to be pushed into the > mainline, or should be dropped due to being too specific or could be done > using other existing mechanisms. The project would not be a Google-only > project and will have a mailing list to discuss and potentially accept any > contribution trying to extend and/or enhance the TSAN implementation. > > The evaluation criteria for the TSAN implementation includes but would not > be limited to: > * Performance: not adding overhead to non-tsan runs is paramount and > there are various means to do so > * General usefulness for the community at large so that the TSAN > feature is deemed a good feature to have > > If the TSAN implementation becomes stable and is deemed useful enough, the > TSAN project would shepherd the work in one or more JEPs to integrate TSAN > into the mainline of OpenJDK. > > The Tsan project scope was discussed during the call for discussion for the > Atlantis project [3]. It was determined that the Atlantis project's scope > was not well defined and it would be better to start with a separate Tsan > project with an end goal and better determined boundaries. > > The current suggested initial Reviewers and Committers would be but is most > likely not going to be limited to (alphabetical order of first name): > * Alex Menkov (amenkov) > * Chuck Rasbold (rasbold) > * Daniil Titov (dtitov) > * Jean Christophe Beyler (jcbeyler) > * Liam Cushon (cushon) > * Serguei Spitsyn (sspitsyn) > > > Votes are due by Wednesday 27, 23:59 pm Pacific Time. > > Only current OpenJDK Members [3] are eligible to vote on this motion. > Votes must be cast in the open on the discuss list. Replying to this > message is sufficient if your mail program honors the Reply-To header. > > For Lazy Consensus voting instructions, see [5]. > > Thanks, > Jc > > [1] http://openjdk.java.net/projects/#new-project > [2] https://bugs.openjdk.java.net/browse/JDK-8208520 > [3] > https://mail.openjdk.java.net/pipermail/discuss/2018-November/004904.html > [4] http://openjdk.java.net/census#members > [5] http://openjdk.java.net/projects/#new-project-vote From laurent.daynes at oracle.com Fri Feb 15 10:11:30 2019 From: laurent.daynes at oracle.com (Laurent Daynes) Date: Fri, 15 Feb 2019 11:11:30 +0100 Subject: Call For Vote: Project Tsan In-Reply-To: References: Message-ID: <24d205f8-758b-a96d-5e52-4b90375f01ad@oracle.com> Vote: yes Le 14/02/2019 ? 01:02, Jean Christophe Beyler a ?crit?: > Hello, > > I hereby propose the creation of the Tsan Project with Jean Christophe > Beyler as the Lead and the Serviceability Group as the sponsoring Group. > > In accordance with the OpenJDK guidelines [1], the TSAN project would > provide a venue to explore and incubate a Thread SANitizing (TSAN) feature > that could be integrated into the Hotspot JVM and the JVM Tool Interface. > This includes working, evaluating, and incubating a Thread-Sanitizer > implementation [2] for Java. > > The Google platform team has historically worked on a Thread SANitizing > (TSAN) project internally. Thread sanitizing allows Java users to see data > race conditions in their Java projects. It is used internally to > automatically detect and warn users of existing data races detected while > running user code. The TSAN project proposes to investigate, in the open, > how these changes could be made general enough to be pushed into the > mainline, or should be dropped due to being too specific or could be done > using other existing mechanisms. The project would not be a Google-only > project and will have a mailing list to discuss and potentially accept any > contribution trying to extend and/or enhance the TSAN implementation. > > The evaluation criteria for the TSAN implementation includes but would not > be limited to: > * Performance: not adding overhead to non-tsan runs is paramount and > there are various means to do so > * General usefulness for the community at large so that the TSAN > feature is deemed a good feature to have > > If the TSAN implementation becomes stable and is deemed useful enough, the > TSAN project would shepherd the work in one or more JEPs to integrate TSAN > into the mainline of OpenJDK. > > The Tsan project scope was discussed during the call for discussion for the > Atlantis project [3]. It was determined that the Atlantis project's scope > was not well defined and it would be better to start with a separate Tsan > project with an end goal and better determined boundaries. > > The current suggested initial Reviewers and Committers would be but is most > likely not going to be limited to (alphabetical order of first name): > * Alex Menkov (amenkov) > * Chuck Rasbold (rasbold) > * Daniil Titov (dtitov) > * Jean Christophe Beyler (jcbeyler) > * Liam Cushon (cushon) > * Serguei Spitsyn (sspitsyn) > > > Votes are due by Wednesday 27, 23:59 pm Pacific Time. > > Only current OpenJDK Members [3] are eligible to vote on this motion. > Votes must be cast in the open on the discuss list. Replying to this > message is sufficient if your mail program honors the Reply-To header. > > For Lazy Consensus voting instructions, see [5]. > > Thanks, > Jc > > [1] http://openjdk.java.net/projects/#new-project > [2] https://bugs.openjdk.java.net/browse/JDK-8208520 > [3] > https://mail.openjdk.java.net/pipermail/discuss/2018-November/004904.html > [4] http://openjdk.java.net/census#members > [5] http://openjdk.java.net/projects/#new-project-vote From fweimer at redhat.com Fri Feb 15 11:53:18 2019 From: fweimer at redhat.com (Florian Weimer) Date: Fri, 15 Feb 2019 12:53:18 +0100 Subject: Call For Vote: Project Tsan In-Reply-To: (Jean Christophe Beyler's message of "Thu, 14 Feb 2019 12:54:23 -0800") References: <871s4aiims.fsf@oldenburg2.str.redhat.com> Message-ID: <87y36hjmj5.fsf@oldenburg2.str.redhat.com> * Jean Christophe Beyler: > Our internal version is built on top of it so we currently are > planning to do the same in this project. Are there any issues you can > foresee with doing this? The interceptors in the sanitizers are extremely problematic from a ABI compatibility perspective. We can manage that if we bundle them with a toolchain version they have been tested with, but this might not necessarily be the case with an OpenJDK build that is not supplied by the toolchain vendor. My concern is that would basically freeze toolchain-internal interfaces in stone because changing them would break existing OpenJDK binaries. Thanks, Florian From ChrisPhi at LGonQn.Org Fri Feb 15 16:12:15 2019 From: ChrisPhi at LGonQn.Org ("Chris Phillips"@T O) Date: Fri, 15 Feb 2019 11:12:15 -0500 Subject: Call For Vote: Project Tsan (Jean Christophe Beyler) In-Reply-To: References: Message-ID: <06c6c284-d853-902b-2128-f91eba2f42b6@LGonQn.Org> Vote: yes Chris From martinrb at google.com Fri Feb 15 23:39:21 2019 From: martinrb at google.com (Martin Buchholz) Date: Fri, 15 Feb 2019 15:39:21 -0800 Subject: Call For Vote: Project Tsan In-Reply-To: <87y36hjmj5.fsf@oldenburg2.str.redhat.com> References: <871s4aiims.fsf@oldenburg2.str.redhat.com> <87y36hjmj5.fsf@oldenburg2.str.redhat.com> Message-ID: There may be a cultural expectations gap. Companies (like Google) might make the toolchain a part of their basic computing infrastructure; build everything from source, and use a tsan that comes with the one blessed toolchain used to build everything else. Linux distros (like Red Hat) probably also try to build most binaries with a preferred toolchain, but there is a much wider promise of ABI compatibility. In particular, part of the value proposition of having a Linux distro is users not having to rebuild from source, and being able to combine binaries built by others, using different toolchains. On Fri, Feb 15, 2019 at 3:54 AM Florian Weimer wrote: > * Jean Christophe Beyler: > > > Our internal version is built on top of it so we currently are > > planning to do the same in this project. Are there any issues you can > > foresee with doing this? > > The interceptors in the sanitizers are extremely problematic from a ABI > compatibility perspective. We can manage that if we bundle them with a > toolchain version they have been tested with, but this might not > necessarily be the case with an OpenJDK build that is not supplied by > the toolchain vendor. > > My concern is that would basically freeze toolchain-internal interfaces > in stone because changing them would break existing OpenJDK binaries. > > Thanks, > Florian > From andru at cs.cornell.edu Mon Feb 25 15:30:40 2019 From: andru at cs.cornell.edu (Andrew Myers) Date: Mon, 25 Feb 2019 10:30:40 -0500 Subject: JLang, a Java-to-LLVM compiler Message-ID: <5C740A20.6030405@cs.cornell.edu> * We are happy to announce an initial release of JLang, a Java-to-LLVM ahead-of-time compiler, on Github at https://polyglot-compiler.github.io/JLang/. JLang compiles Java source code directly to LLVM, allowing a variety of LLVM back ends to be used to target various architectures. The JVM and JNI interfaces are supported with a shared library whose source code is also distributed as part of JLang. Support for Java libraries is provided by compiling the OpenJDK Java source into a shared library with JLang and then linking the OpenJDK native libraries. JLang is built on top of the Polyglot extensible compiler framework, so it supports experimentation with new language features and with new implementation techniques. The current JLang release can be used to compile and run a variety of Java programs, but it has a number of significant limitations that are in the process of being addressed: * JLang implements Java 7, so does not yet support some newer Java features such as lambdas, default methods, or modules. * Java concurrency is not supported. * Some corners of the reflection API need more work. We welcome the involvement of external contributors. Interested parties can subscribe to the users mailing list from the JLang web site. Credits: Daniel Donenfeld, Matt Gharrity, Daniel Weber, Drew Zagieboylo, Yizhou Zhang ----- Andrew Myers Dept. of Computer Science Cornell University *