From lukenbutters at gmail.com Mon May 10 21:41:26 2021 From: lukenbutters at gmail.com (Luke B) Date: Tue, 11 May 2021 07:41:26 +1000 Subject: I have test failures, is master the correct branch to build from? Message-ID: Hi, I cloned git at github.com:openjdk/jdk.git followed the build instructions and was able to build the JDK on master, however when I ran: make run-test-tier1 some of the tests failed: ============================== Test summary ============================== TEST TOTAL PASS FAIL ERROR >> jtreg:test/hotspot/jtreg:tier1 1728 1721 7 0 << jtreg:test/jdk:tier1 2026 2026 0 0 jtreg:test/langtools:tier1 4167 4167 0 0 jtreg:test/jaxp:tier1 0 0 0 0 jtreg:test/lib-test:tier1 0 0 0 0 ============================== TEST FAILURE Looking in the report.html for the hotspot tests I see: "native" failed 7 tests and "bug8251158 native" failed 2 tests. Is this expected, am I building the wrong branch? If not do I need to install something to get those tests passing? many thanks, -Luke From david.holmes at oracle.com Mon May 10 23:59:30 2021 From: david.holmes at oracle.com (David Holmes) Date: Tue, 11 May 2021 09:59:30 +1000 Subject: I have test failures, is master the correct branch to build from? In-Reply-To: References: Message-ID: <83253f79-86e1-9e03-1e5a-5ac1d53b5a50@oracle.com> Hi Luke, Please take this to hotspot-dev at openjdk.java.net (you will need to subscribe to it). There is not enough information here to know why specific tests are failing for you. make sure you apply the ProblemList.txt file when running jtreg so that known failures are excluded. Thanks, David On 11/05/2021 7:41 am, Luke B wrote: > Hi, > > I cloned git at github.com:openjdk/jdk.git followed the build instructions and > was able to build the JDK on master, however when I ran: > > make run-test-tier1 > > some of the tests failed: > > ============================== > Test summary > ============================== > TEST TOTAL PASS FAIL > ERROR >>> jtreg:test/hotspot/jtreg:tier1 1728 1721 7 > 0 << > jtreg:test/jdk:tier1 2026 2026 0 > 0 > jtreg:test/langtools:tier1 4167 4167 0 > 0 > jtreg:test/jaxp:tier1 0 0 0 > 0 > jtreg:test/lib-test:tier1 0 0 0 > 0 > ============================== > TEST FAILURE > > Looking in the report.html for the hotspot tests I see: > "native" failed 7 tests and "bug8251158 native" failed 2 tests. > > Is this expected, am I building the wrong branch? If not do I need to > install something to get those tests passing? > > many thanks, > -Luke > From volker.simonis at gmail.com Wed May 12 13:25:54 2021 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 12 May 2021 15:25:54 +0200 Subject: Resigning as PowerPC/AIX Port Project Lead Message-ID: I hereby resign as PowerPC/AIX Port Project Lead. The PowerPC/AIX Port [1] was proposed almost exactly 9 years ago [2]. It was the first externally contributed, full OpenJDK port and paved the way for subsequent porting projects like aarch64 and s390. It was also the beginning of a fruitful cooperation between SAP, IBM and Oracle who have all contributed to the success of this project. While PowerPC and especially AIX can still be seen as "niche" platforms, the presence of the PowerPC/AIX Port in the OpenJDK main line has helped to considerably improve and streamline the whole code base. I hope this mutually beneficial collaboration will continue in the future and would like to propose Martin Doerr (mdoerr [3]) as new Project Lead. Martin is a true PowerPC/Itanium expert and a real memory model wizard. He's a long term member of the SAP JVM team, an OpenJDK Reviewer and a member of the OpenJDK HotSpot and Members Groups [3]. In the end, and according to the OpenJDK Bylaws, the Lead of the sponsoring group (Dalibor Topic from the Porters Group) needs to assign a new Project Lead [4]. I for myself can't think of any better candidate and warmly recommend Martin for this position. Thank you and best regards, Volker [1] https://wiki.openjdk.java.net/display/PPCAIXPort [2] http://mail.openjdk.java.net/pipermail/announce/2012-May/000125.html [3] http://openjdk.java.net/census#mdoerr [4] http://openjdk.java.net/bylaws#project-lead From waishon009 at gmail.com Sat May 15 20:15:02 2021 From: waishon009 at gmail.com (Waishon) Date: Sat, 15 May 2021 22:15:02 +0200 Subject: Starting and joining a lot of threads slower on AMD systems compared to Intel systems In-Reply-To: <4e9bc985-7dee-4530-9810-388a369942ef@Spark> References: <4e9bc985-7dee-4530-9810-388a369942ef@Spark> Message-ID: <5d176e10-5833-41f0-93ad-601fd1169e36@Spark> Hey there! In a study project we should create 100.000 threads to get a feeling for the time it takes to create a lot of threads and why it's more efficient to use tasks instead. However we found out, that the same "Create and start 100.000 threads" code runs a lot slower on a modern Ryzen AMD systems compared to some older (even notebook) Intel systems. We did some benchmarking with different JDKs, but all using Java 16 (older versions didn't make a difference). We know that this isn't a good "real world" example, however we would be very interested in the reason, why AMD is a lot slower in this special scenario. ?? ?public class ThreadCreator { ?? ? ? ?public static void main(String[] args) throws InterruptedException { ?? ? ? ? ? ?List startedThreads = new ArrayList<>(); ?? ? ? ? ? ?long startTime = System.currentTimeMillis(); ?? ? ? ? ? ?for (int i = 0; i < 100_000; i++) { ?? ? ? ? ? ? ? ?Thread t = new Thread(() -> {}); ?? ? ? ? ? ? ? ?t.start(); ?? ? ? ? ? ? ? ?startedThreads.add(t); ?? ? ? ? ? ?} ?? ? ? ? ? ?for (Thread t : startedThreads) { ?? ? ? ? ? ? ? ?t.join(); ?? ? ? ? ? ?} ?? ? ? ? ? ?System.out.println("Duration: " + (System.currentTimeMillis() - startTime)); ?? ? ? ?} ?? ?} The benchmark results: ?? ?AMD Ryzen 7 3700X System (Java 16, Ubuntu 20.04): ?? ?Adopt OpenJDK (Hotspot): 13882ms ?? ?Adopt OpenJDK (OpenJ9): 7521ms ?? ?Intel i7-8550U System (Fedora 34, Java 16): ?? ?Adopt OpenJDK (Hotspot): 5321ms ?? ?Adopt OpenJDK (OpenJ9): 3089ms ?? ?Intel i5-6600k System (Windows 10, Java 16): ?? ?Adopt OpenJDK (Hotspot): 29433ms (Maybe realted to low memory of this system) ?? ?Adopt OpenJDK (OpenJ9): 5119ms The OpenJ9 JVM reduces the time on both systems to nearly the half. However the AMD system never reaches the time of the Intel systems. The AMD system only runs at 10% cpu utilisation during this test. What might be the reason why starting and joining threads is so much slower on AMD systems compared to Intel systems? (Disclaimer: This question was also posted on Stackoverflow, which referred to this mailing list: https://stackoverflow.com/questions/67550679/creating-threads-is-slower-on-amd-systems-compared-to-intel-systems) Thank you very much in advance! From thomas.stuefe at gmail.com Sun May 16 05:40:06 2021 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Sun, 16 May 2021 07:40:06 +0200 Subject: Starting and joining a lot of threads slower on AMD systems compared to Intel systems In-Reply-To: <5d176e10-5833-41f0-93ad-601fd1169e36@Spark> References: <4e9bc985-7dee-4530-9810-388a369942ef@Spark> <5d176e10-5833-41f0-93ad-601fd1169e36@Spark> Message-ID: Hi, Just some points: - you run the tests on different OSes with different kernels and different libc implementations. So the software stack below the VM is different, not only the hardware. I would run the tests on the same software stack. - you want to know the cost of joining, but measure thread start + thread joining. If you want to measure thread joining, create the threads, wait until they are up, then measure joining. - you have an unknown element of "how many threads are alive at the same time". This is timing dependent. Your threads return right away. A fast machine may create the threads faster and hence push a higher wave of concurrently alive threads, whereas a slower machine may spread thread creation out more. Higher number of concurrently alive threads take more time for task switches and impose more stress on the memory management, see below. - About memory: - each thread needs a stack. Stack costs by default 1M+x virtual memory. Creating 100k threads will cost you a *lot* of address space. On my 64g machine I can create about 32k threads before address space runs out. To limit this effect I would reduce the max thread stack size. - more importantly each thread needs: - stack guard pages (16k per thread on linux) - a little bit of stack, one page or two, even if it does nothing - VM control structures All that memory needs to be committed and counts toward the commit charge. 100k threads may bring you well into swapping territory. On my machine, I need about 400M for 25k threads. Make sure that you don't start swapping. Again, only measure thread joining after all threads are up, not creation + joining. Hope that helps, Cheers, Thomas On Sat, May 15, 2021 at 10:15 PM Waishon wrote: > Hey there! > > In a study project we should create 100.000 threads to get a feeling for > the time it takes to create a lot of threads and why it's more efficient to > use tasks instead. > > However we found out, that the same "Create and start 100.000 threads" > code runs a lot slower on a modern Ryzen AMD systems compared to some older > (even notebook) Intel systems. We did some benchmarking with different > JDKs, but all using Java 16 (older versions didn't make a difference). We > know that this isn't a good "real world" example, however we would be very > interested in the reason, why AMD is a lot slower in this special scenario. > > public class ThreadCreator { > public static void main(String[] args) throws InterruptedException > { > List startedThreads = new ArrayList<>(); > long startTime = System.currentTimeMillis(); > > for (int i = 0; i < 100_000; i++) { > Thread t = new Thread(() -> {}); > t.start(); > startedThreads.add(t); > } > > for (Thread t : startedThreads) { > t.join(); > } > > System.out.println("Duration: " + (System.currentTimeMillis() > - startTime)); > } > } > > The benchmark results: > > AMD Ryzen 7 3700X System (Java 16, Ubuntu 20.04): > Adopt OpenJDK (Hotspot): 13882ms > Adopt OpenJDK (OpenJ9): 7521ms > > Intel i7-8550U System (Fedora 34, Java 16): > Adopt OpenJDK (Hotspot): 5321ms > Adopt OpenJDK (OpenJ9): 3089ms > > Intel i5-6600k System (Windows 10, Java 16): > Adopt OpenJDK (Hotspot): 29433ms (Maybe realted to low memory of this > system) > Adopt OpenJDK (OpenJ9): 5119ms > > The OpenJ9 JVM reduces the time on both systems to nearly the half. > However the AMD system never reaches the time of the Intel systems. The AMD > system only runs at 10% cpu utilisation during this test. > > What might be the reason why starting and joining threads is so much > slower on AMD systems compared to Intel systems? > > (Disclaimer: This question was also posted on Stackoverflow, which > referred to this mailing list: > https://stackoverflow.com/questions/67550679/creating-threads-is-slower-on-amd-systems-compared-to-intel-systems > ) > > Thank you very much in advance! > From shade at redhat.com Sun May 16 05:46:01 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Sun, 16 May 2021 07:46:01 +0200 Subject: Starting and joining a lot of threads slower on AMD systems compared to Intel systems In-Reply-To: <5d176e10-5833-41f0-93ad-601fd1169e36@Spark> References: <4e9bc985-7dee-4530-9810-388a369942ef@Spark> <5d176e10-5833-41f0-93ad-601fd1169e36@Spark> Message-ID: In addition to excellent Thomas Stuefes' reply: On 5/15/21 10:15 PM, Waishon wrote: > In a study project we should create 100.000 threads to get a feeling for the time it takes to > create a lot of threads and why it's more efficient to use tasks instead. I think what you found is in the spirit of the assignment: not only you discovered the overheads are high, but also that they are different across systems, OSes, etc. > What might be the reason why starting and joining threads is so much slower on AMD systems > compared to Intel systems? > > (Disclaimer: This question was also posted on Stackoverflow, which referred to this mailing list: > https://stackoverflow.com/questions/67550679/creating-threads-is-slower-on-amd-systems-compared-to-intel-systems) Well, could be a number of things. Most likely, since we are dealing with OS syscalls on thread creation, we are probably doing mostly memory and task management for new threads. But to know more, you need to follow the advice of the very first SO comment: "You should probably use a profiler and it will better tell you where the time is being spent." [1] For example, with async-profiler [2] would profile both Java, JVM and kernel code: $ java -agentpath:$asyncProfilerPath/libasyncProfiler.so=start,event=cpu,frequency=10000,file=profile.html ThreadCreator -- Thanks, -Aleksey [1] https://stackoverflow.com/questions/67550679/creating-threads-is-slower-on-amd-systems-compared-to-intel-systems#comment119397887_67550679 [2] https://github.com/jvm-profiling-tools/async-profiler From thomas.stuefe at gmail.com Sun May 16 06:06:58 2021 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Sun, 16 May 2021 08:06:58 +0200 Subject: Starting and joining a lot of threads slower on AMD systems compared to Intel systems In-Reply-To: References: <4e9bc985-7dee-4530-9810-388a369942ef@Spark> <5d176e10-5833-41f0-93ad-601fd1169e36@Spark> Message-ID: The difference to J9 is annoying though. It just occurred to me that we have this handshake between creator thread and newborn thread. The creator thread waits for the newborn to be up and running, in order to avoid inconsistent thread states. Which requires the newborn to get at least some cycles, competing with all its siblings. I wonder whether J9 does this differently. May be worth looking into. ..Thomas On Sun, May 16, 2021 at 7:46 AM Aleksey Shipilev wrote: > In addition to excellent Thomas Stuefes' reply: > > On 5/15/21 10:15 PM, Waishon wrote: > > In a study project we should create 100.000 threads to get a feeling for > the time it takes to > > create a lot of threads and why it's more efficient to use tasks instead. > I think what you found is in the spirit of the assignment: not only you > discovered the overheads are > high, but also that they are different across systems, OSes, etc. > > > What might be the reason why starting and joining threads is so much > slower on AMD systems > > compared to Intel systems? > > > > (Disclaimer: This question was also posted on Stackoverflow, which > referred to this mailing list: > > > https://stackoverflow.com/questions/67550679/creating-threads-is-slower-on-amd-systems-compared-to-intel-systems > ) > Well, could be a number of things. Most likely, since we are dealing with > OS syscalls on thread > creation, we are probably doing mostly memory and task management for new > threads. But to know more, > you need to follow the advice of the very first SO comment: "You should > probably use a profiler and > it will better tell you where the time is being spent." [1] > > For example, with async-profiler [2] would profile both Java, JVM and > kernel code: > $ java > -agentpath:$asyncProfilerPath/libasyncProfiler.so=start,event=cpu,frequency=10000,file=profile.html > > ThreadCreator > > -- > Thanks, > -Aleksey > > [1] > > https://stackoverflow.com/questions/67550679/creating-threads-is-slower-on-amd-systems-compared-to-intel-systems#comment119397887_67550679 > [2] https://github.com/jvm-profiling-tools/async-profiler > > From thomas.stuefe at gmail.com Sun May 16 07:02:16 2021 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Sun, 16 May 2021 09:02:16 +0200 Subject: Starting and joining a lot of threads slower on AMD systems compared to Intel systems In-Reply-To: References: <4e9bc985-7dee-4530-9810-388a369942ef@Spark> <5d176e10-5833-41f0-93ad-601fd1169e36@Spark> Message-ID: On Sun, May 16, 2021 at 8:06 AM Thomas St?fe wrote: > The difference to J9 is annoying though. > > It just occurred to me that we have this handshake between creator thread > and newborn thread. The creator thread waits for the newborn to be up and > running, in order to avoid inconsistent thread states. Which requires the > newborn to get at least some cycles, competing with all its siblings. > Which interestingly we don't do for all platforms (not on AIX nor Windows). Another reason to execute such tests on the same OS and hardware. > > I wonder whether J9 does this differently. May be worth looking into. > > Found a trivial low hanging fruit at least: https://github.com/openjdk/jdk/pull/4042 ..Thomas > ..Thomas > > > On Sun, May 16, 2021 at 7:46 AM Aleksey Shipilev wrote: > >> In addition to excellent Thomas Stuefes' reply: >> >> On 5/15/21 10:15 PM, Waishon wrote: >> > In a study project we should create 100.000 threads to get a feeling >> for the time it takes to >> > create a lot of threads and why it's more efficient to use tasks >> instead. >> I think what you found is in the spirit of the assignment: not only you >> discovered the overheads are >> high, but also that they are different across systems, OSes, etc. >> >> > What might be the reason why starting and joining threads is so much >> slower on AMD systems >> > compared to Intel systems? >> > >> > (Disclaimer: This question was also posted on Stackoverflow, which >> referred to this mailing list: >> > >> https://stackoverflow.com/questions/67550679/creating-threads-is-slower-on-amd-systems-compared-to-intel-systems >> ) >> Well, could be a number of things. Most likely, since we are dealing with >> OS syscalls on thread >> creation, we are probably doing mostly memory and task management for new >> threads. But to know more, >> you need to follow the advice of the very first SO comment: "You should >> probably use a profiler and >> it will better tell you where the time is being spent." [1] >> >> For example, with async-profiler [2] would profile both Java, JVM and >> kernel code: >> $ java >> -agentpath:$asyncProfilerPath/libasyncProfiler.so=start,event=cpu,frequency=10000,file=profile.html >> >> ThreadCreator >> >> -- >> Thanks, >> -Aleksey >> >> [1] >> >> https://stackoverflow.com/questions/67550679/creating-threads-is-slower-on-amd-systems-compared-to-intel-systems#comment119397887_67550679 >> [2] https://github.com/jvm-profiling-tools/async-profiler >> >> From david.holmes at oracle.com Sun May 16 22:52:42 2021 From: david.holmes at oracle.com (David Holmes) Date: Mon, 17 May 2021 08:52:42 +1000 Subject: Starting and joining a lot of threads slower on AMD systems compared to Intel systems In-Reply-To: References: <4e9bc985-7dee-4530-9810-388a369942ef@Spark> <5d176e10-5833-41f0-93ad-601fd1169e36@Spark> Message-ID: <0a33a1cc-000d-65d8-1326-32e5ee31b64a@oracle.com> On 16/05/2021 5:02 pm, Thomas St?fe wrote: > On Sun, May 16, 2021 at 8:06 AM Thomas St?fe > wrote: > >> The difference to J9 is annoying though. >> >> It just occurred to me that we have this handshake between creator thread >> and newborn thread. The creator thread waits for the newborn to be up and >> running, in order to avoid inconsistent thread states. Which requires the >> newborn to get at least some cycles, competing with all its siblings. >> > > Which interestingly we don't do for all platforms (not on AIX nor Windows). > Another reason to execute such tests on the same OS and hardware. As Linux/BSD/macOS can't start threads suspended we have to emulate that with this handshake. The reason this is needed is to ensure the newly created thread can't run to completion and delete itself before the creator has finished the initial interaction with it. David ----- > >> >> I wonder whether J9 does this differently. May be worth looking into. >> >> > Found a trivial low hanging fruit at least: > https://github.com/openjdk/jdk/pull/4042 > > ..Thomas > > >> ..Thomas >> >> >> On Sun, May 16, 2021 at 7:46 AM Aleksey Shipilev wrote: >> >>> In addition to excellent Thomas Stuefes' reply: >>> >>> On 5/15/21 10:15 PM, Waishon wrote: >>>> In a study project we should create 100.000 threads to get a feeling >>> for the time it takes to >>>> create a lot of threads and why it's more efficient to use tasks >>> instead. >>> I think what you found is in the spirit of the assignment: not only you >>> discovered the overheads are >>> high, but also that they are different across systems, OSes, etc. >>> >>>> What might be the reason why starting and joining threads is so much >>> slower on AMD systems >>>> compared to Intel systems? >>>> >>>> (Disclaimer: This question was also posted on Stackoverflow, which >>> referred to this mailing list: >>>> >>> https://stackoverflow.com/questions/67550679/creating-threads-is-slower-on-amd-systems-compared-to-intel-systems >>> ) >>> Well, could be a number of things. Most likely, since we are dealing with >>> OS syscalls on thread >>> creation, we are probably doing mostly memory and task management for new >>> threads. But to know more, >>> you need to follow the advice of the very first SO comment: "You should >>> probably use a profiler and >>> it will better tell you where the time is being spent." [1] >>> >>> For example, with async-profiler [2] would profile both Java, JVM and >>> kernel code: >>> $ java >>> -agentpath:$asyncProfilerPath/libasyncProfiler.so=start,event=cpu,frequency=10000,file=profile.html >>> >>> ThreadCreator >>> >>> -- >>> Thanks, >>> -Aleksey >>> >>> [1] >>> >>> https://stackoverflow.com/questions/67550679/creating-threads-is-slower-on-amd-systems-compared-to-intel-systems#comment119397887_67550679 >>> [2] https://github.com/jvm-profiling-tools/async-profiler >>> >>> From michal.gorniewski at gmail.com Thu May 20 09:07:30 2021 From: michal.gorniewski at gmail.com (=?UTF-8?Q?Micha=C5=82_G=C3=B3rniewski?=) Date: Thu, 20 May 2021 11:07:30 +0200 Subject: Counter-intuitive behavior of CompleteableFuture Message-ID: Hi, With following code: ------------------------------ public static void main(String[] args) { CompletableFuture initial = new CompletableFuture<>(); CompletableFuture withSteps = initial .thenApply(s -> { System.out.println("STEP1: " + s); return s; }) .thenApply(s -> { System.out.println("STEP2: " + s); return s; }); CompletableFuture timeout = withSteps; timeout.whenComplete((s, throwable) -> System.out.println("TIMEOUT: " + throwable)); timeout.completeExceptionally(new RuntimeException("TIMEOUT")); initial.complete("SUCCESS"); } ------------------------------ I got output like this: ------------------------------ TIMEOUT: java.lang.RuntimeException: TIMEOUT STEP1: SUCCESS ------------------------------ I don't understand why "STEP2" is not executed in this case. Is this expected? Thanks, Micha? G?rniewski From pavel.rappo at oracle.com Thu May 20 10:26:28 2021 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Thu, 20 May 2021 10:26:28 +0000 Subject: Counter-intuitive behavior of CompleteableFuture In-Reply-To: References: Message-ID: <7EEA105B-CF60-4C73-8989-4E377E815F77@oracle.com> 1. Haven't you effectively cancelled "STEP 2" by completing the respective future exceptionally? 2. If you need a result of a future at some point, wait for it: timeout.join() (or use an overload of CompletableFuture.get) Questions related to the contents of java.util.concurrent.** should generally be asked on the "Concurrency-interest" mailing list: http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest > On 20 May 2021, at 10:07, Micha? G?rniewski wrote: > > Hi, > > With following code: > > ------------------------------ > public static void main(String[] args) { > CompletableFuture initial = new CompletableFuture<>(); > > CompletableFuture withSteps = initial > .thenApply(s -> { > System.out.println("STEP1: " + s); > return s; > }) > .thenApply(s -> { > System.out.println("STEP2: " + s); > return s; > }); > > CompletableFuture timeout = withSteps; > > timeout.whenComplete((s, throwable) -> > System.out.println("TIMEOUT: " + throwable)); > > timeout.completeExceptionally(new RuntimeException("TIMEOUT")); > initial.complete("SUCCESS"); > } > ------------------------------ > > I got output like this: > > ------------------------------ > TIMEOUT: java.lang.RuntimeException: TIMEOUT > STEP1: SUCCESS > ------------------------------ > > I don't understand why "STEP2" is not executed in this case. Is this expected? > > Thanks, > Micha? G?rniewski From michal.gorniewski at gmail.com Thu May 20 12:25:13 2021 From: michal.gorniewski at gmail.com (=?UTF-8?Q?Micha=C5=82_G=C3=B3rniewski?=) Date: Thu, 20 May 2021 14:25:13 +0200 Subject: Counter-intuitive behavior of CompleteableFuture In-Reply-To: <7EEA105B-CF60-4C73-8989-4E377E815F77@oracle.com> References: <7EEA105B-CF60-4C73-8989-4E377E815F77@oracle.com> Message-ID: For me this is a somewhat confusing API. I've stumble upon this while using resilience4j library: https://github.com/resilience4j/resilience4j/issues/1427 I will open a thread on concurrency-interest. Thanks, Micha? czw., 20 maj 2021 o 12:26 Pavel Rappo napisa?(a): > > 1. Haven't you effectively cancelled "STEP 2" by completing the respective future exceptionally? > 2. If you need a result of a future at some point, wait for it: > > timeout.join() (or use an overload of CompletableFuture.get) > > Questions related to the contents of java.util.concurrent.** should generally be asked on the "Concurrency-interest" mailing list: http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest > > > On 20 May 2021, at 10:07, Micha? G?rniewski wrote: > > > > Hi, > > > > With following code: > > > > ------------------------------ > > public static void main(String[] args) { > > CompletableFuture initial = new CompletableFuture<>(); > > > > CompletableFuture withSteps = initial > > .thenApply(s -> { > > System.out.println("STEP1: " + s); > > return s; > > }) > > .thenApply(s -> { > > System.out.println("STEP2: " + s); > > return s; > > }); > > > > CompletableFuture timeout = withSteps; > > > > timeout.whenComplete((s, throwable) -> > > System.out.println("TIMEOUT: " + throwable)); > > > > timeout.completeExceptionally(new RuntimeException("TIMEOUT")); > > initial.complete("SUCCESS"); > > } > > ------------------------------ > > > > I got output like this: > > > > ------------------------------ > > TIMEOUT: java.lang.RuntimeException: TIMEOUT > > STEP1: SUCCESS > > ------------------------------ > > > > I don't understand why "STEP2" is not executed in this case. Is this expected? > > > > Thanks, > > Micha? G?rniewski > From david.lloyd at redhat.com Thu May 20 14:00:39 2021 From: david.lloyd at redhat.com (David Lloyd) Date: Thu, 20 May 2021 09:00:39 -0500 Subject: Introducing qbicc Message-ID: Hi Everyone, We have created a new Github project, qbicc [1], to capture some of the prototyping work we are doing around native images. Qbicc is an experimental sandbox project intended for VM developers to rapidly prototype potential approaches to challenges surrounding native Java support in a way that is independent from any particular JVM implementation. With the announcement of Project Leyden - which aims to standardize native image generation in Java - it has become clear that use cases around native compilation are more important than ever, and we expect that the qbicc project will help to drive the discussion around the art of the possible in a broad range of compile-to-native Java applications. Many of the ideas being explored in qbicc have been guided not only by application considerations, but also by our experience with GraalVM and OpenJDK HotSpot. Red Hat intends to not only continue contributing to GraalVM, but to also contribute to Project Leyden at OpenJDK, and to that end we have done extensive initial analysis and have started a discussion about it [2]. Further, we expect the ideas prototyped in qbicc will help identify new contribution opportunities to both the GraalVM and OpenJDK communities. Qbicc is a small code base with few interdependencies so changes to each area are localized. This makes it easier to experiment with and explore designs that are infeasible to retrofit into dynamic JVMs on an experimental basis. Some of the areas we have focussed on recently with qbicc include the object header design, array design, using typeids rather than native pointers, Lightweight Rapid Type Analysis (RTA, to minimize the classes, and methods required in the closed world), and more. Areas we are currently looking into include addressing heap serialization and optimizing compile time initialization, with a potential view towards identifying ways in which these features might possibly be standardized in Leyden. As mentioned above, qbicc is not intended for end users and we currently have no plans to build any products around it. Our aim is to use this project to experiment with approaches to native image generation and thereby drive discussions within the Leyden project and GraalVM native-image, with real-world data and experience in areas that are directly applicable to the benefit of Java runtimes and applications. We invite you to use our GitHub discussion board [3] and interactive developer Zulip chat [4] to join the discussion. [1] https://github.com/qbicc/qbicc [2] https://mail.openjdk.java.net/pipermail/discuss/2021-April/005788.html [3] https://github.com/qbicc/qbicc/discussions [4] https://qbicc.zulipchat.com -- - DML ? he/him From florent.guillaume at gmail.com Fri May 21 11:59:08 2021 From: florent.guillaume at gmail.com (Florent Guillaume) Date: Fri, 21 May 2021 13:59:08 +0200 Subject: Starting and joining a lot of threads slower on AMD systems compared to Intel systems In-Reply-To: <0a33a1cc-000d-65d8-1326-32e5ee31b64a@oracle.com> References: <4e9bc985-7dee-4530-9810-388a369942ef@Spark> <5d176e10-5833-41f0-93ad-601fd1169e36@Spark> <0a33a1cc-000d-65d8-1326-32e5ee31b64a@oracle.com> Message-ID: On Mon, May 17, 2021 at 12:53 AM David Holmes wrote: > On 16/05/2021 5:02 pm, Thomas St?fe wrote: > > On Sun, May 16, 2021 at 8:06 AM Thomas St?fe > > wrote: > > > >> The difference to J9 is annoying though. > >> > >> It just occurred to me that we have this handshake between creator > thread > >> and newborn thread. The creator thread waits for the newborn to be up > and > >> running, in order to avoid inconsistent thread states. Which requires > the > >> newborn to get at least some cycles, competing with all its siblings. > >> > > > > Which interestingly we don't do for all platforms (not on AIX nor > Windows). > > Another reason to execute such tests on the same OS and hardware. > > As Linux/BSD/macOS can't start threads suspended we have to emulate that > with this handshake. The reason this is needed is to ensure the newly > created thread can't run to completion and delete itself before the > creator has finished the initial interaction with it. > It seems that macOS has the Apple-specific POSIX_SPAWN_START_SUSPENDED to do that. Florent From david.holmes at oracle.com Fri May 21 14:37:46 2021 From: david.holmes at oracle.com (David Holmes) Date: Sat, 22 May 2021 00:37:46 +1000 Subject: Starting and joining a lot of threads slower on AMD systems compared to Intel systems In-Reply-To: References: <4e9bc985-7dee-4530-9810-388a369942ef@Spark> <5d176e10-5833-41f0-93ad-601fd1169e36@Spark> <0a33a1cc-000d-65d8-1326-32e5ee31b64a@oracle.com> Message-ID: <1b366a61-7422-551a-8070-74a011c02eee@oracle.com> On 21/05/2021 9:59 pm, Florent Guillaume wrote: > On Mon, May 17, 2021 at 12:53 AM David Holmes > wrote: > > On 16/05/2021 5:02 pm, Thomas St?fe wrote: > > On Sun, May 16, 2021 at 8:06 AM Thomas St?fe > > > > wrote: > > > >> The difference to J9 is annoying though. > >> > >> It just occurred to me that we have this handshake between > creator thread > >> and newborn thread. The creator thread waits for the newborn to > be up and > >> running, in order to avoid inconsistent thread states. Which > requires the > >> newborn to get at least some cycles, competing with all its > siblings. > >> > > > > Which interestingly we don't do for all platforms (not on AIX nor > Windows). > > Another reason to execute such tests on the same OS and hardware. > > As Linux/BSD/macOS can't start threads suspended we have to emulate > that > with this handshake. The reason this is needed is to ensure the newly > created thread can't run to completion and delete itself before the > creator has finished the initial interaction with it. > > > It seems that macOS has the Apple-specific > POSIX_SPAWN_START_SUSPENDED?to do that. That is for process creation not threads. David ----- > Florent >