From outsider404 at gmail.com Mon Jul 1 19:08:13 2024 From: outsider404 at gmail.com (Michal Domagala) Date: Mon, 1 Jul 2024 21:08:13 +0200 Subject: Virtual thread memory leak because TrackingRootContainer keeps threads Message-ID: According to https://openjdk.org/jeps/444, "Unlike platform thread stacks, virtual thread stacks are not GC roots." But jdk.internal.vm.ThreadContainers.RootContainer.TrackingRootContainer#VTHREADS keeps (hard) references to each virtual thread. Effectively, virtual threads are GC roots. I described full example here: https://stackoverflow.com/questions/78596905/why-virtual-thread-is-not-garbage-collected-when-not-reachable The problem was not visible since https://bugs.openjdk.org/browse/JDK-8309406, because before the change, VTHREADS "keep" was not enabled and i guess nobody cares memory leak. But after the change every JVM is affected. A workaround for memory leak is set jdk.trackAllThreads=false Best regards Michal Domagala -------------- next part -------------- An HTML attachment was scrubbed... URL: From robaho at icloud.com Mon Jul 1 19:38:05 2024 From: robaho at icloud.com (Robert Engels) Date: Mon, 1 Jul 2024 14:38:05 -0500 Subject: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: References: Message-ID: I am not sure you can call it a memory leak - you would have the same problem if it was a platform thread - it would be stuck waiting on a queue - and so any references the thread held in its stack would ?leak? as well. Having two different behaviors for platform and virtual threads in this regard would cause a lot of problems with interoperability (switching between thread types). I don?t think a code author should need to know if their resources are being used by a virtual thread or a platform thread and adjust. Treating VT threads as GC roots make more sense to me. > On Jul 1, 2024, at 2:08 PM, Michal Domagala wrote: > > According to https://openjdk.org/jeps/444 , > > "Unlike platform thread stacks, virtual thread stacks are not GC roots." > > But jdk.internal.vm.ThreadContainers.RootContainer.TrackingRootContainer#VTHREADS keeps (hard) references to each virtual thread. Effectively, virtual threads are GC roots. > > I described full example here: https://stackoverflow.com/questions/78596905/why-virtual-thread-is-not-garbage-collected-when-not-reachable > > The problem was not visible since https://bugs.openjdk.org/browse/JDK-8309406 , because before the change, VTHREADS "keep" was not enabled and i guess nobody cares memory leak. > > But after the change every JVM is affected. > > A workaround for memory leak is set jdk.trackAllThreads=false > > Best regards > Michal Domagala > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bronee at gmail.com Mon Jul 1 23:59:01 2024 From: bronee at gmail.com (Brian S O'Neill) Date: Mon, 1 Jul 2024 16:59:01 -0700 Subject: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: References: Message-ID: I was confused when I first discovered that virtual threads could be GC'd when blocked with an infinite timeout. This was before the trackAllThreads option was enabled by default. If the virtual thread is blocked with an effectively infinite timeout (100 years), it won't be GC'd even when trackAllThreads is false. For consistency, I think it makes sense for virtual threads to never actually be GC'd except until after they exit. If you depended on virtual threads being GC'd when blocked with a real infinite timeout, then switching to platform threads would introduce a memory leak that didn't exist before. Ideally, the two thread types should be interchangeable. On 2024-07-01 12:08 PM, Michal Domagala wrote: > According to https://openjdk.org/jeps/444 , > > "Unlike platform thread stacks, virtual thread stacks are not GC roots." > > But?jdk.internal.vm.ThreadContainers.RootContainer.TrackingRootContainer#VTHREADS keeps (hard) references to each?virtual thread. Effectively, virtual?threads are GC roots. > > I described full example here: > https://stackoverflow.com/questions/78596905/why-virtual-thread-is-not-garbage-collected-when-not-reachable > > The problem was not visible?since > https://bugs.openjdk.org/browse/JDK-8309406 > , because before the > change, VTHREADS "keep" was not enabled and i guess nobody cares memory > leak. > > But after the change every?JVM is affected. > > A workaround for memory leak is set jdk.trackAllThreads=false > > Best regards > Michal Domagala > From outsider404 at gmail.com Tue Jul 2 14:45:18 2024 From: outsider404 at gmail.com (Michal Domagala) Date: Tue, 2 Jul 2024 16:45:18 +0200 Subject: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: References: Message-ID: I did research and I found that virtual threads are designed with the rule that RAM is the limit. It means millions of virtual threads are OK. And millions of GC roots is garbage collector death. But it is a performance reason, not a "heart" reason. For me, the "heart" reason is simplicity of use. I would like to use virtual thread in any place in code when I want without overhead. For example, I can parallelize computation using just ForkJoinPool. I would like to parallelize blocking with the same simplicity. One of Java's simplicity factors is the lack of destructor. When object reference is lost, I do not care how resources are reclaimed. If VT is not GC root, I can start as many as I want within - a potentially complex - object and the system will reclaim resources when the object is GC'ed. If VT is GC root, I must inspect each VT one by one and make sure they are stopped. It is called a destructor and destructor is not simple. People wrote here that platform and virtual threads should be interchangeable. They are interchangeable, because they have the same API. Being GC root is not API - it is implementation. wt., 2 lip 2024 o 02:37 Brian S O'Neill napisa?(a): > I was confused when I first discovered that virtual threads could be > GC'd when blocked with an infinite timeout. This was before the > trackAllThreads option was enabled by default. > > If the virtual thread is blocked with an effectively infinite timeout > (100 years), it won't be GC'd even when trackAllThreads is false. For > consistency, I think it makes sense for virtual threads to never > actually be GC'd except until after they exit. > > If you depended on virtual threads being GC'd when blocked with a real > infinite timeout, then switching to platform threads would introduce a > memory leak that didn't exist before. Ideally, the two thread types > should be interchangeable. > > > On 2024-07-01 12:08 PM, Michal Domagala wrote: > > According to https://openjdk.org/jeps/444 >, > > > > "Unlike platform thread stacks, virtual thread stacks are not GC roots." > > > > > But jdk.internal.vm.ThreadContainers.RootContainer.TrackingRootContainer#VTHREADS > keeps (hard) references to each virtual thread. Effectively, > virtual threads are GC roots. > > > > I described full example here: > > > https://stackoverflow.com/questions/78596905/why-virtual-thread-is-not-garbage-collected-when-not-reachable > < > https://stackoverflow.com/questions/78596905/why-virtual-thread-is-not-garbage-collected-when-not-reachable > > > > > > The problem was not visible since > > https://bugs.openjdk.org/browse/JDK-8309406 > > , because before the > > change, VTHREADS "keep" was not enabled and i guess nobody cares memory > > leak. > > > > But after the change every JVM is affected. > > > > A workaround for memory leak is set jdk.trackAllThreads=false > > > > Best regards > > Michal Domagala > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pedro.lamarao at prodist.com.br Tue Jul 2 16:01:01 2024 From: pedro.lamarao at prodist.com.br (=?UTF-8?Q?Pedro_Lamar=C3=A3o?=) Date: Tue, 2 Jul 2024 13:01:01 -0300 Subject: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: References: Message-ID: Em seg., 1 de jul. de 2024 ?s 21:02, Brian S O'Neill escreveu: > If you depended on virtual threads being GC'd when blocked with a real > infinite timeout, then switching to platform threads would introduce a > memory leak that didn't exist before. Ideally, the two thread types > should be interchangeable. > But what about an "impossible" wait? A thread in a pseudo-infinite wait will wake eventually, and the platform cannot know if this was intentional or not. But a thread waiting on a blocking queue whose only reference is the thread itself will never wake, since there is no one to insert into the queue. -- Pedro Lamar?o -------------- next part -------------- An HTML attachment was scrubbed... URL: From robaho at icloud.com Tue Jul 2 16:02:09 2024 From: robaho at icloud.com (robert engels) Date: Tue, 2 Jul 2024 11:02:09 -0500 Subject: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: References: Message-ID: <88EA283B-3555-4498-AF5F-A6FF2C9E1D7E@icloud.com> An HTML attachment was scrubbed... URL: From robaho at icloud.com Tue Jul 2 16:03:44 2024 From: robaho at icloud.com (robert engels) Date: Tue, 2 Jul 2024 11:03:44 -0500 Subject: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: References: Message-ID: <9C76EE5C-DE55-4F15-B496-274190FA4591@icloud.com> An HTML attachment was scrubbed... URL: From robaho at icloud.com Tue Jul 2 16:11:42 2024 From: robaho at icloud.com (robert engels) Date: Tue, 2 Jul 2024 11:11:42 -0500 Subject: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: <9C76EE5C-DE55-4F15-B496-274190FA4591@icloud.com> References: <9C76EE5C-DE55-4F15-B496-274190FA4591@icloud.com> Message-ID: <56542BFB-EB37-4046-B90F-575294725045@icloud.com> An HTML attachment was scrubbed... URL: From bronee at gmail.com Tue Jul 2 16:12:50 2024 From: bronee at gmail.com (Brian S O'Neill) Date: Tue, 2 Jul 2024 09:12:50 -0700 Subject: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: References: Message-ID: <96c080ac-2e64-4ba3-91ad-eaa52225ca77@gmail.com> Before Thread.stop was disabled, a platform thread could never be stuck in an unbreakable wait. It might be possible to allow platform threads to be GC'd when it's impossible to be woken up, but it wouldn't work when the blocking is in native code. On 2024-07-02 09:01 AM, Pedro Lamar?o wrote: > Em seg., 1 de jul. de 2024 ?s 21:02, Brian S O'Neill > escreveu: > > If you depended on virtual threads being GC'd when blocked with a real > infinite timeout, then switching to platform threads would introduce a > memory leak that didn't exist before. Ideally, the two thread types > should be interchangeable. > > > But what about an "impossible" wait? > A thread in a pseudo-infinite wait will wake eventually, and the > platform cannot know if this was intentional or not. > But a thread waiting on a blocking queue whose only reference is the > thread itself will never wake, since there is no one to insert into the > queue. > > -- > Pedro Lamar?o From bronee at gmail.com Tue Jul 2 16:16:13 2024 From: bronee at gmail.com (Brian S O'Neill) Date: Tue, 2 Jul 2024 09:16:13 -0700 Subject: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: <96c080ac-2e64-4ba3-91ad-eaa52225ca77@gmail.com> References: <96c080ac-2e64-4ba3-91ad-eaa52225ca77@gmail.com> Message-ID: But I guess you'd need a reference to the Thread in order to stop it, and so it wouldn't be GC'd anyhow. The bigger problem might be ThreadGroups, since all threads belong to one. To be GC'd, all threads in the group would also need to be gone. On 2024-07-02 09:12 AM, Brian S O'Neill wrote: > Before Thread.stop was disabled, a platform thread could never be stuck > in an unbreakable wait. It might be possible to allow platform threads > to be GC'd when it's impossible to be woken up, but it wouldn't work > when the blocking is in native code. > > On 2024-07-02 09:01 AM, Pedro Lamar?o wrote: >> Em seg., 1 de jul. de 2024 ?s 21:02, Brian S O'Neill > > escreveu: >> >> ??? If you depended on virtual threads being GC'd when blocked with a >> real >> ??? infinite timeout, then switching to platform threads would >> introduce a >> ??? memory leak that didn't exist before. Ideally, the two thread types >> ??? should be interchangeable. >> >> >> But what about an "impossible" wait? >> A thread in a pseudo-infinite wait will wake eventually, and the >> platform cannot know if this was intentional or not. >> But a thread waiting on a blocking queue whose only reference is the >> thread itself will never wake, since there is no one to insert into >> the queue. >> >> -- >> Pedro Lamar?o From robaho at icloud.com Tue Jul 2 16:19:15 2024 From: robaho at icloud.com (Robert Engels) Date: Tue, 2 Jul 2024 11:19:15 -0500 Subject: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: References: <96c080ac-2e64-4ba3-91ad-eaa52225ca77@gmail.com> Message-ID: As I mentioned, you can?t just make the threads ?disappear?. The only option would be for the read() to terminate with an interrupted exception, or UnsatisfiableError (or the like), but the thread would continue - unless the exception went all the way up the stack to cause the thread termination - which is already clearly defined. > On Jul 2, 2024, at 11:16 AM, Brian S O'Neill wrote: > > But I guess you'd need a reference to the Thread in order to stop it, and so it wouldn't be GC'd anyhow. The bigger problem might be ThreadGroups, since all threads belong to one. To be GC'd, all threads in the group would also need to be gone. > > On 2024-07-02 09:12 AM, Brian S O'Neill wrote: >> Before Thread.stop was disabled, a platform thread could never be stuck in an unbreakable wait. It might be possible to allow platform threads to be GC'd when it's impossible to be woken up, but it wouldn't work when the blocking is in native code. >> On 2024-07-02 09:01 AM, Pedro Lamar?o wrote: >>> Em seg., 1 de jul. de 2024 ?s 21:02, Brian S O'Neill > escreveu: >>> >>> If you depended on virtual threads being GC'd when blocked with a real >>> infinite timeout, then switching to platform threads would introduce a >>> memory leak that didn't exist before. Ideally, the two thread types >>> should be interchangeable. >>> >>> >>> But what about an "impossible" wait? >>> A thread in a pseudo-infinite wait will wake eventually, and the platform cannot know if this was intentional or not. >>> But a thread waiting on a blocking queue whose only reference is the thread itself will never wake, since there is no one to insert into the queue. >>> >>> -- >>> Pedro Lamar?o From ron.pressler at oracle.com Tue Jul 2 18:08:43 2024 From: ron.pressler at oracle.com (Ron Pressler) Date: Tue, 2 Jul 2024 18:08:43 +0000 Subject: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: References: Message-ID: <5A2E1F5D-9346-48B2-B6C8-3459FB6E32B0@oracle.com> We would eventually like to allow setting tracking option on a per-thread basis, but we need to work out a few details. > On 1 Jul 2024, at 20:08, Michal Domagala wrote: > > According to https://openjdk.org/jeps/444, > > "Unlike platform thread stacks, virtual thread stacks are not GC roots." > > But jdk.internal.vm.ThreadContainers.RootContainer.TrackingRootContainer#VTHREADS keeps (hard) references to each virtual thread. Effectively, virtual threads are GC roots. > > I described full example here: https://stackoverflow.com/questions/78596905/why-virtual-thread-is-not-garbage-collected-when-not-reachable > > The problem was not visible since https://bugs.openjdk.org/browse/JDK-8309406, because before the change, VTHREADS "keep" was not enabled and i guess nobody cares memory leak. > > But after the change every JVM is affected. > > A workaround for memory leak is set jdk.trackAllThreads=false > > Best regards > Michal Domagala > From rengels at ix.netcom.com Tue Jul 2 18:41:32 2024 From: rengels at ix.netcom.com (robert engels) Date: Tue, 2 Jul 2024 13:41:32 -0500 Subject: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: <5A2E1F5D-9346-48B2-B6C8-3459FB6E32B0@oracle.com> References: <5A2E1F5D-9346-48B2-B6C8-3459FB6E32B0@oracle.com> Message-ID: <5C2E3DDB-6F90-44F8-9783-A2B2C77378AA@ix.netcom.com> Is this in an effort to allow the automatic clean-up the OP refers to? Wouldn?t this make the code function differently if called by a VT vs a PT? This seems like a huge problem to me and against the design of VT (and Java for that matter). > On Jul 2, 2024, at 1:08 PM, Ron Pressler wrote: > > We would eventually like to allow setting tracking option on a per-thread basis, but we need to work out a few details. > >> On 1 Jul 2024, at 20:08, Michal Domagala wrote: >> >> According to https://openjdk.org/jeps/444, >> >> "Unlike platform thread stacks, virtual thread stacks are not GC roots." >> >> But jdk.internal.vm.ThreadContainers.RootContainer.TrackingRootContainer#VTHREADS keeps (hard) references to each virtual thread. Effectively, virtual threads are GC roots. >> >> I described full example here: https://stackoverflow.com/questions/78596905/why-virtual-thread-is-not-garbage-collected-when-not-reachable >> >> The problem was not visible since https://bugs.openjdk.org/browse/JDK-8309406, because before the change, VTHREADS "keep" was not enabled and i guess nobody cares memory leak. >> >> But after the change every JVM is affected. >> >> A workaround for memory leak is set jdk.trackAllThreads=false >> >> Best regards >> Michal Domagala >> > From robaho at me.com Tue Jul 2 20:50:00 2024 From: robaho at me.com (Robert Engels) Date: Tue, 2 Jul 2024 15:50:00 -0500 Subject: Interesting profile session In-Reply-To: <4f740363-4d3d-4f8c-8dcb-c1d439d99ca0@oracle.com> References: <62c21cea-d76e-44c1-a887-e7f8836d285d@oracle.com> <17AD6AC4-6529-4337-8C2A-ABE71030BC63@me.com> <7FDC8772-D5E5-4E94-9F96-E2B3B72E981B@me.com> <4f740363-4d3d-4f8c-8dcb-c1d439d99ca0@oracle.com> Message-ID: <1EC21491-C3B9-4FAE-96F1-1D13F55E0FE2@me.com> Just an fyi, it looks like it was this issue: https://github.com/async-profiler/async-profiler/issues/923 I guess starting in JDK-23 the size of the HeapBlock header changed. > On Jun 28, 2024, at 1:25 AM, Alan Bateman wrote: > > On 27/06/2024 22:44, Robert Engels wrote: >> One issue I have run into, with the Loom EA build I can?t run the async profiler against it. > > The current EA build is based on jdk-24+3. I don't know if async profiler is working with JDK 24 EA builds yet, it would be good to check that as a baseline. > > -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron.pressler at oracle.com Wed Jul 3 14:12:53 2024 From: ron.pressler at oracle.com (Ron Pressler) Date: Wed, 3 Jul 2024 14:12:53 +0000 Subject: [External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: <5C2E3DDB-6F90-44F8-9783-A2B2C77378AA@ix.netcom.com> References: <5A2E1F5D-9346-48B2-B6C8-3459FB6E32B0@oracle.com> <5C2E3DDB-6F90-44F8-9783-A2B2C77378AA@ix.netcom.com> Message-ID: <7196614D-E2FA-4492-BE1E-B2BB0B0DE1CE@oracle.com> > On 2 Jul 2024, at 19:41, robert engels wrote: > > Is this in an effort to allow the automatic clean-up the OP refers to? Not cleanup, but memory reclamation. If a thread provably can never continue, it can continue running forever (conceptually) without consuming any RAM (although you want be able to observe it). If a thread can never do anything, it behaves exactly as if the thread doesn?t exist. > > Wouldn?t this make the code function differently if called by a VT vs a PT? This seems like a huge problem to me and against the design of VT (and Java for that matter). It would only ?function? differently in the sense that observability (i.e. a thread dump) and memory consumption would be different, which are not considered functional changes by the spec. > >> On Jul 2, 2024, at 1:08 PM, Ron Pressler wrote: >> >> We would eventually like to allow setting tracking option on a per-thread basis, but we need to work out a few details. >> >>> On 1 Jul 2024, at 20:08, Michal Domagala wrote: >>> >>> According to https://openjdk.org/jeps/444, >>> >>> "Unlike platform thread stacks, virtual thread stacks are not GC roots." >>> >>> But jdk.internal.vm.ThreadContainers.RootContainer.TrackingRootContainer#VTHREADS keeps (hard) references to each virtual thread. Effectively, virtual threads are GC roots. >>> >>> I described full example here: https://urldefense.com/v3/__https://stackoverflow.com/questions/78596905/why-virtual-thread-is-not-garbage-collected-when-not-reachable__;!!ACWV5N9M2RV99hQ!ISk6c21Jkzy3I92KCoA9udUUidpoMoyHTAGx1uC1gzAqH-hBQkxNMLRu6VEZxznn3M45Lbt-tlqmYwlNEQ$ >>> >>> The problem was not visible since https://bugs.openjdk.org/browse/JDK-8309406, because before the change, VTHREADS "keep" was not enabled and i guess nobody cares memory leak. >>> >>> But after the change every JVM is affected. >>> >>> A workaround for memory leak is set jdk.trackAllThreads=false >>> >>> Best regards >>> Michal Domagala >>> >> > From rengels at ix.netcom.com Wed Jul 3 14:36:23 2024 From: rengels at ix.netcom.com (robert engels) Date: Wed, 3 Jul 2024 09:36:23 -0500 Subject: [External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: <7196614D-E2FA-4492-BE1E-B2BB0B0DE1CE@oracle.com> References: <5A2E1F5D-9346-48B2-B6C8-3459FB6E32B0@oracle.com> <5C2E3DDB-6F90-44F8-9783-A2B2C77378AA@ix.netcom.com> <7196614D-E2FA-4492-BE1E-B2BB0B0DE1CE@oracle.com> Message-ID: But won?t that be a breaking api change: /** * Retrieves and removes the head of this queue, waiting if necessary * until an element becomes available. * * @return the head of this queue * @throws InterruptedException if interrupted while waiting */ E take() throws InterruptedException; For example, given this code: T timedGetElement() throws InterruptedException { Timer t = Timer.start(); try { return queue.take(); } finally { t.stop(); } } With the proposed changes, stop() may never be called - leading to potential resource leaks. Whereas currently the rules ensure stop() will be called unless the application hard terminates. This would essentially equating thread ?death? with a hard application termination from an observability standpoint. You would have similar issues with any tracing/logging type frameworks. > On Jul 3, 2024, at 9:12 AM, Ron Pressler wrote: > > > >> On 2 Jul 2024, at 19:41, robert engels > wrote: >> >> Is this in an effort to allow the automatic clean-up the OP refers to? > > Not cleanup, but memory reclamation. If a thread provably can never continue, it can continue running forever (conceptually) without consuming any RAM (although you want be able to observe it). If a thread can never do anything, it behaves exactly as if the thread doesn?t exist. > >> >> Wouldn?t this make the code function differently if called by a VT vs a PT? This seems like a huge problem to me and against the design of VT (and Java for that matter). > > It would only ?function? differently in the sense that observability (i.e. a thread dump) and memory consumption would be different, which are not considered functional changes by the spec. > >> >>> On Jul 2, 2024, at 1:08 PM, Ron Pressler wrote: >>> >>> We would eventually like to allow setting tracking option on a per-thread basis, but we need to work out a few details. >>> >>>> On 1 Jul 2024, at 20:08, Michal Domagala wrote: >>>> >>>> According to https://openjdk.org/jeps/444, >>>> >>>> "Unlike platform thread stacks, virtual thread stacks are not GC roots." >>>> >>>> But jdk.internal.vm.ThreadContainers.RootContainer.TrackingRootContainer#VTHREADS keeps (hard) references to each virtual thread. Effectively, virtual threads are GC roots. >>>> >>>> I described full example here: https://urldefense.com/v3/__https://stackoverflow.com/questions/78596905/why-virtual-thread-is-not-garbage-collected-when-not-reachable__;!!ACWV5N9M2RV99hQ!ISk6c21Jkzy3I92KCoA9udUUidpoMoyHTAGx1uC1gzAqH-hBQkxNMLRu6VEZxznn3M45Lbt-tlqmYwlNEQ$ >>>> >>>> The problem was not visible since https://bugs.openjdk.org/browse/JDK-8309406 , because before the change, VTHREADS "keep" was not enabled and i guess nobody cares memory leak. >>>> >>>> But after the change every JVM is affected. >>>> >>>> A workaround for memory leak is set jdk.trackAllThreads=false >>>> >>>> Best regards >>>> Michal Domagala -------------- next part -------------- An HTML attachment was scrubbed... URL: From attila.kelemen85 at gmail.com Wed Jul 3 14:53:04 2024 From: attila.kelemen85 at gmail.com (Attila Kelemen) Date: Wed, 3 Jul 2024 16:53:04 +0200 Subject: [External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: References: <5A2E1F5D-9346-48B2-B6C8-3459FB6E32B0@oracle.com> <5C2E3DDB-6F90-44F8-9783-A2B2C77378AA@ix.netcom.com> <7196614D-E2FA-4492-BE1E-B2BB0B0DE1CE@oracle.com> Message-ID: The assumption is that the thread can provably never continue. That implies `stop` never being called. So, there is no observable difference. robert engels ezt ?rta (id?pont: 2024. j?l. 3., Sze, 16:38): > But won?t that be a breaking api change: > > /** > * Retrieves and removes the head of this queue, waiting if necessary > * until an element becomes available. > * > * @return the head of this queue > * @throws InterruptedException if interrupted while waiting > */ > E take() throws InterruptedException; > > For example, given this code: > > T timedGetElement() throws InterruptedException { > Timer t = Timer.start(); > try { > return queue.take(); > } finally { > t.stop(); > } > } > > With the proposed changes, stop() may never be called - leading to > potential resource leaks. > > Whereas currently the rules ensure stop() will be called unless the > application hard terminates. This would essentially equating thread ?death? > with a hard application termination from an observability standpoint. > > You would have similar issues with any tracing/logging type frameworks. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bronee at gmail.com Wed Jul 3 14:55:16 2024 From: bronee at gmail.com (Brian S O'Neill) Date: Wed, 3 Jul 2024 07:55:16 -0700 Subject: [External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: References: <5A2E1F5D-9346-48B2-B6C8-3459FB6E32B0@oracle.com> <5C2E3DDB-6F90-44F8-9783-A2B2C77378AA@ix.netcom.com> <7196614D-E2FA-4492-BE1E-B2BB0B0DE1CE@oracle.com> Message-ID: <5bd3e74b-4cae-4147-bb7c-b81fe727589f@gmail.com> If the take method never returns, the stop method will never be called in either case. Does it matter if the VT is reclaimed or not? I think the more interesting case is when the timer is finalizable or uses a Cleaner. If the VT decides that it cannot continue and goes away, then the timer can be reclaimed too. The invocation of the cleaning action might give the impression that the take method did continue, when in fact it never did. On 2024-07-03 07:36 AM, robert engels wrote: > But won?t that be a breaking api change: > > /** > * Retrieves and removes the head of this queue, waiting if necessary > * until an element becomes available. > * > * @returnthe head of this queue > * @throwsInterruptedExceptionif interrupted while waiting > */ > E take() throws InterruptedException; > > For example, given this code: > > T timedGetElement() throws InterruptedException { > ? Timer t = Timer.start(); > ? ?try { > ? ? ? return queue.take(); > ? ?} finally { > ? ? ? t.stop(); > ? ?} > } > > With the proposed changes, stop() may never be called - leading to > potential resource leaks. > > Whereas currently the rules ensure stop() will be called unless the > application hard terminates. This would essentially equating thread > ?death? with a hard application termination from an observability > standpoint. > > You would have similar issues with any tracing/logging type frameworks. > > >> On Jul 3, 2024, at 9:12 AM, Ron Pressler > > wrote: >> >> >> >>> On 2 Jul 2024, at 19:41, robert engels >> > wrote: >>> >>> Is this in an effort to allow the automatic clean-up the OP refers to? >> >> Not cleanup, but memory reclamation. If a thread provably can never >> continue, it can continue running forever (conceptually) without >> consuming any RAM (although you want be able to observe it). If a >> thread can never do anything, it behaves exactly as if the thread >> doesn?t exist. >> From rengels at ix.netcom.com Wed Jul 3 14:58:08 2024 From: rengels at ix.netcom.com (robert engels) Date: Wed, 3 Jul 2024 09:58:08 -0500 Subject: [External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: References: <5A2E1F5D-9346-48B2-B6C8-3459FB6E32B0@oracle.com> <5C2E3DDB-6F90-44F8-9783-A2B2C77378AA@ix.netcom.com> <7196614D-E2FA-4492-BE1E-B2BB0B0DE1CE@oracle.com> Message-ID: <99B9907A-218C-46DF-B909-70EC39CEABAE@ix.netcom.com> I understand, but with a PT thread being a GC, and methods like Thread.enumerate() is was never possibly - and a ?service? could always find the ?blocked? threads and interrupt them. If VT are not findable (or optionally findable), I think it is a breaking change which goes against the JEP design for virtual threads, and it is going to lead to two different types of patterns for queue handling based on the thread types involved - I think this is a very bad idea. > On Jul 3, 2024, at 9:53 AM, Attila Kelemen wrote: > > The assumption is that the thread can provably never continue. That implies `stop` never being called. So, there is no observable difference. > > robert engels > ezt ?rta (id?pont: 2024. j?l. 3., Sze, 16:38): > But won?t that be a breaking api change: > > /** > * Retrieves and removes the head of this queue, waiting if necessary > * until an element becomes available. > * > * @return the head of this queue > * @throws InterruptedException if interrupted while waiting > */ > E take() throws InterruptedException; > > For example, given this code: > > T timedGetElement() throws InterruptedException { > Timer t = Timer.start(); > try { > return queue.take(); > } finally { > t.stop(); > } > } > > With the proposed changes, stop() may never be called - leading to potential resource leaks. > > Whereas currently the rules ensure stop() will be called unless the application hard terminates. This would essentially equating thread ?death? with a hard application termination from an observability standpoint. > > You would have similar issues with any tracing/logging type frameworks. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From attila.kelemen85 at gmail.com Wed Jul 3 15:04:39 2024 From: attila.kelemen85 at gmail.com (Attila Kelemen) Date: Wed, 3 Jul 2024 17:04:39 +0200 Subject: [External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: <99B9907A-218C-46DF-B909-70EC39CEABAE@ix.netcom.com> References: <5A2E1F5D-9346-48B2-B6C8-3459FB6E32B0@oracle.com> <5C2E3DDB-6F90-44F8-9783-A2B2C77378AA@ix.netcom.com> <7196614D-E2FA-4492-BE1E-B2BB0B0DE1CE@oracle.com> <99B9907A-218C-46DF-B909-70EC39CEABAE@ix.netcom.com> Message-ID: Maybe Ron will prove me wrong, but I never felt that the design of the JEP was meant to make VT appear as PT in all aspects. In fact, what the JEP is usually about is that it equates VT with tasks submitted to an executor. And in that case, VT being a GC root is a strange thing. Though I think either case is unlikely to make a difference in practice. robert engels ezt ?rta (id?pont: 2024. j?l. 3., Sze, 16:58): > I understand, but with a PT thread being a GC, and methods like > Thread.enumerate() is was never possibly - and a ?service? could always > find the ?blocked? threads and interrupt them. > > If VT are not findable (or optionally findable), I think it is a breaking > change which goes against the JEP design for virtual threads, and it is > going to lead to two different types of patterns for queue handling based > on the thread types involved - I think this is a very bad idea. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron.pressler at oracle.com Wed Jul 3 15:44:16 2024 From: ron.pressler at oracle.com (Ron Pressler) Date: Wed, 3 Jul 2024 15:44:16 +0000 Subject: [External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: <99B9907A-218C-46DF-B909-70EC39CEABAE@ix.netcom.com> References: <5A2E1F5D-9346-48B2-B6C8-3459FB6E32B0@oracle.com> <5C2E3DDB-6F90-44F8-9783-A2B2C77378AA@ix.netcom.com> <7196614D-E2FA-4492-BE1E-B2BB0B0DE1CE@oracle.com> <99B9907A-218C-46DF-B909-70EC39CEABAE@ix.netcom.com> Message-ID: <44E8FB97-4D46-4F3B-8C0C-13893A67EA9B@oracle.com> > On 3 Jul 2024, at 15:58, robert engels wrote: > > I understand, but with a PT thread being a GC, and methods like Thread.enumerate() is was never possibly - and a ?service? could always find the ?blocked? threads and interrupt them. > > If VT are not findable (or optionally findable), I think it is a breaking change which goes against the JEP design for virtual threads, and it is going to lead to two different types of patterns for queue handling based on the thread types involved - I think this is a very bad idea. What change can you observe? You could say that you could observe a difference if there?s some weak reference to the thread, in which case the reference may be enqueued for a VT but not a PT. Only we never promise that weak references are ever enqueued; that entirely depends on the particular chosen GC, so you?d be able to observe only a difference that you?d also observe with a different selection of GC. Another difference is that you could potentially wake up a PT by enumerating all PTs, but this difference already exists today; collecting the VT doesn?t introduce any further change. I certainly can?t see what effect any of this would have on queue handling. ? Ron From ron.pressler at oracle.com Wed Jul 3 15:51:51 2024 From: ron.pressler at oracle.com (Ron Pressler) Date: Wed, 3 Jul 2024 15:51:51 +0000 Subject: [External] : Re: Experience using virtual threads in EA 23-loom+4-102 In-Reply-To: <2B54EE29-CDD4-47A0-8178-27F8FE2AD39F@icloud.com> References: <07DDEEC5-688D-45A4-A651-CFDA38E3757C@oracle.com> <2B54EE29-CDD4-47A0-8178-27F8FE2AD39F@icloud.com> Message-ID: > On 29 Jun 2024, at 19:04, robert engels wrote: > > I think the issue is for cpu bound work land - eg image conversions, etc. I think not having time sharing is only an issue for machines with low cpu counts. The issue is that tail latency gets out of control. Latency is not generally improved by time sharing regardless of the number of CPUs. In some situations time sharing will make it (potentially much) better, and in others it will make it (potentially much) worse. For example, if you start many threads doing the *same* heavy computation on platform threads and compare that to virtual threads you?ll see that the virtual thread latencies will be much better than the platform thread latencies. If the computation done on the different threads is very different in its duration you?ll see the exact opposite occur. > IO tasks get blocked too easily. Every general workload OS has time sharing (that I?m aware of) has time sharing just for this reason. IO preempts threads both in the OS and with the virtual thread scheduler even without time sharing. The reason non-realtime OSes have time sharing is different, and has nothing to do with performance (realtime kernels is a different matter). The main reason for time sharing is to keep the machine responsive when it?s at 100% CPU to allow operator interaction, but this is already the case with virtual threads by virtue of the fact that they?re mapped to OS threads. ? Ron From robaho at icloud.com Wed Jul 3 16:43:51 2024 From: robaho at icloud.com (Robert Engels) Date: Wed, 3 Jul 2024 11:43:51 -0500 Subject: [External] : Re: Experience using virtual threads in EA 23-loom+4-102 In-Reply-To: References: <07DDEEC5-688D-45A4-A651-CFDA38E3757C@oracle.com> <2B54EE29-CDD4-47A0-8178-27F8FE2AD39F@icloud.com> Message-ID: <052D6B72-3AD7-442C-99BB-87F1F183BB74@icloud.com> I don't think that is correct - but I could be wrong. With platform threads the min and max latency in a completely cpu bound scenario should be very close the the average with a completely fair scheduler (when all tasks/threads are submitted at the same time). Without timesharing, the average will be the same, but the min and max latencies will be far off the average - as the tasks submitted first complete very quickly, and the tasks submitted at the end take a very long time because they need to have all of the tasks before them complete. In regards to the the ?enough cpus? comment, I only meant that if there are enough cpus and a ?somewhat? balanced workload, it is unlikely that all of the cpu bounds tasks could consume all of the carrier threads given a random distribution. If you have more active tasks than cpus and the majority of the tasks are cpu bound, the IO tasks are going to suffer in a non-timesliced scenario - they will be stalled waiting for a carrier thread - even though the amount of cpu they need will be very small. This has a lot of info on the subject https://docs.kernel.org/scheduler/sched-design-CFS.html including: On real hardware, we can run only a single task at once, so we have to introduce the concept of ?virtual runtime.? The virtual runtime of a task specifies when its next timeslice would start execution on the ideal multi-tasking CPU described above. In practice, the virtual runtime of a task is its actual runtime normalized to the total number of running tasks. I recommend this https://opensource.com/article/19/2/fair-scheduling-linux for an in-depth discussion on how the dynamic timeslices are computed. The linux scheduler relies on timeslicing in order to have a ?fair? system. I think most Java ?server? type applications strive for fairness as well - i.e. long tail latencies in anything are VERY bad (thus the constant fight against long GC pauses - better to amortize those for consistency). > On Jul 3, 2024, at 10:51 AM, Ron Pressler wrote: > > > >> On 29 Jun 2024, at 19:04, robert engels wrote: >> >> I think the issue is for cpu bound work land - eg image conversions, etc. I think not having time sharing is only an issue for machines with low cpu counts. The issue is that tail latency gets out of control. > > Latency is not generally improved by time sharing regardless of the number of CPUs. In some situations time sharing will make it (potentially much) better, and in others it will make it (potentially much) worse. For example, if you start many threads doing the *same* heavy computation on platform threads and compare that to virtual threads you?ll see that the virtual thread latencies will be much better than the platform thread latencies. If the computation done on the different threads is very different in its duration you?ll see the exact opposite occur. > > >> IO tasks get blocked too easily. Every general workload OS has time sharing (that I?m aware of) has time sharing just for this reason. > > IO preempts threads both in the OS and with the virtual thread scheduler even without time sharing. The reason non-realtime OSes have time sharing is different, and has nothing to do with performance (realtime kernels is a different matter). The main reason for time sharing is to keep the machine responsive when it?s at 100% CPU to allow operator interaction, but this is already the case with virtual threads by virtue of the fact that they?re mapped to OS threads. > > ? Ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From rengels at ix.netcom.com Wed Jul 3 17:03:04 2024 From: rengels at ix.netcom.com (robert engels) Date: Wed, 3 Jul 2024 12:03:04 -0500 Subject: [External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: <44E8FB97-4D46-4F3B-8C0C-13893A67EA9B@oracle.com> References: <5A2E1F5D-9346-48B2-B6C8-3459FB6E32B0@oracle.com> <5C2E3DDB-6F90-44F8-9783-A2B2C77378AA@ix.netcom.com> <7196614D-E2FA-4492-BE1E-B2BB0B0DE1CE@oracle.com> <99B9907A-218C-46DF-B909-70EC39CEABAE@ix.netcom.com> <44E8FB97-4D46-4F3B-8C0C-13893A67EA9B@oracle.com> Message-ID: <0A2CC387-3B85-4C3F-8AEA-24B6FD1D9DB3@ix.netcom.com> In thinking about it some more, if there is no way to enumerate VT instances, then they already differ greatly from platform threads from an API standpoint and this will affect many monitoring systems (although they probably don?t deal with millions of threads well either - as was discussed in another thread). I have used thread enumeration and cpu monitoring to detect ?stuck? threads (i.e. maybe the thread that was supposed to be writing to the queue died, so the reader is making no progress). With this proposal, my reader thread is just going to go away with no observability. I assume this is only for infinite reads - so if we add some level of timeout, then it seems you need some sort of way to detect ?no possible writer? on the queue (if my thread was allowed to continue) as this would be important to know, otherwise you have an infinite timeout loop. It feels like a radical change to Java queue systems and it doesn?t feel like a good one. I still think having the take() throw a UnsatisfiableError with the default handling be thread death would be easier to reason about, and more consistent with current Java design patterns. In fact, the reader could spawn another writer if it chose in handling this. Without an exception bubbling up, I think you are going to have threads/tasks dying all of the time, and no idea where or why the thread died (i.e. how will report which queue the take() became invalid on up the callstack if not for an exception?). It feels like that this will lead to a specialized VT monitoring api where you register listeners for these various conditions - why do this when there already exists the exception mechanism, default thread handlers, etc. > On Jul 3, 2024, at 10:44 AM, Ron Pressler wrote: > > > >> On 3 Jul 2024, at 15:58, robert engels wrote: >> >> I understand, but with a PT thread being a GC, and methods like Thread.enumerate() is was never possibly - and a ?service? could always find the ?blocked? threads and interrupt them. >> >> If VT are not findable (or optionally findable), I think it is a breaking change which goes against the JEP design for virtual threads, and it is going to lead to two different types of patterns for queue handling based on the thread types involved - I think this is a very bad idea. > > What change can you observe? > > You could say that you could observe a difference if there?s some weak reference to the thread, in which case the reference may be enqueued for a VT but not a PT. Only we never promise that weak references are ever enqueued; that entirely depends on the particular chosen GC, so you?d be able to observe only a difference that you?d also observe with a different selection of GC. > > Another difference is that you could potentially wake up a PT by enumerating all PTs, but this difference already exists today; collecting the VT doesn?t introduce any further change. > > I certainly can?t see what effect any of this would have on queue handling. > > ? Ron From spullara at gmail.com Wed Jul 3 17:17:06 2024 From: spullara at gmail.com (Sam Pullara) Date: Wed, 3 Jul 2024 10:17:06 -0700 Subject: [External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: <0A2CC387-3B85-4C3F-8AEA-24B6FD1D9DB3@ix.netcom.com> References: <5A2E1F5D-9346-48B2-B6C8-3459FB6E32B0@oracle.com> <5C2E3DDB-6F90-44F8-9783-A2B2C77378AA@ix.netcom.com> <7196614D-E2FA-4492-BE1E-B2BB0B0DE1CE@oracle.com> <99B9907A-218C-46DF-B909-70EC39CEABAE@ix.netcom.com> <44E8FB97-4D46-4F3B-8C0C-13893A67EA9B@oracle.com> <0A2CC387-3B85-4C3F-8AEA-24B6FD1D9DB3@ix.netcom.com> Message-ID: Isn't the way around this to not use a queue at all and launch a new VT for each piece of work? If this is a common issue in your code base maybe add Closeable to the queue and abort on close? Hoping it all gets collected doesn't seem like the right answer to me and not keeping the VT as a root seems wrong as well. On Wed, Jul 3, 2024 at 10:03?AM robert engels wrote: > In thinking about it some more, if there is no way to enumerate VT > instances, then they already differ greatly from platform threads from an > API standpoint and this will affect many monitoring systems (although they > probably don?t deal with millions of threads well either - as was discussed > in another thread). > > I have used thread enumeration and cpu monitoring to detect ?stuck? > threads (i.e. maybe the thread that was supposed to be writing to the queue > died, so the reader is making no progress). With this proposal, my reader > thread is just going to go away with no observability. > > I assume this is only for infinite reads - so if we add some level of > timeout, then it seems you need some sort of way to detect ?no possible > writer? on the queue (if my thread was allowed to continue) as this would > be important to know, otherwise you have an infinite timeout loop. > > It feels like a radical change to Java queue systems and it doesn?t feel > like a good one. > > I still think having the take() throw a UnsatisfiableError with the > default handling be thread death would be easier to reason about, and more > consistent with current Java design patterns. In fact, the reader could > spawn another writer if it chose in handling this. Without an exception > bubbling up, I think you are going to have threads/tasks dying all of the > time, and no idea where or why the thread died (i.e. how will report which > queue the take() became invalid on up the callstack if not for an > exception?). > > It feels like that this will lead to a specialized VT monitoring api where > you register listeners for these various conditions - why do this when > there already exists the exception mechanism, default thread handlers, etc. > > > On Jul 3, 2024, at 10:44 AM, Ron Pressler > wrote: > > > > > > > >> On 3 Jul 2024, at 15:58, robert engels wrote: > >> > >> I understand, but with a PT thread being a GC, and methods like > Thread.enumerate() is was never possibly - and a ?service? could always > find the ?blocked? threads and interrupt them. > >> > >> If VT are not findable (or optionally findable), I think it is a > breaking change which goes against the JEP design for virtual threads, and > it is going to lead to two different types of patterns for queue handling > based on the thread types involved - I think this is a very bad idea. > > > > What change can you observe? > > > > You could say that you could observe a difference if there?s some weak > reference to the thread, in which case the reference may be enqueued for a > VT but not a PT. Only we never promise that weak references are ever > enqueued; that entirely depends on the particular chosen GC, so you?d be > able to observe only a difference that you?d also observe with a different > selection of GC. > > > > Another difference is that you could potentially wake up a PT by > enumerating all PTs, but this difference already exists today; collecting > the VT doesn?t introduce any further change. > > > > I certainly can?t see what effect any of this would have on queue > handling. > > > > ? Ron > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From spullara at gmail.com Wed Jul 3 17:18:53 2024 From: spullara at gmail.com (Sam Pullara) Date: Wed, 3 Jul 2024 10:18:53 -0700 Subject: [External] : Re: Experience using virtual threads in EA 23-loom+4-102 In-Reply-To: <052D6B72-3AD7-442C-99BB-87F1F183BB74@icloud.com> References: <07DDEEC5-688D-45A4-A651-CFDA38E3757C@oracle.com> <2B54EE29-CDD4-47A0-8178-27F8FE2AD39F@icloud.com> <052D6B72-3AD7-442C-99BB-87F1F183BB74@icloud.com> Message-ID: As a developer trying to use this stuff, I 100% agree that fair is better. If I need something that isn't fair, I can do that myself. On Wed, Jul 3, 2024 at 9:44?AM Robert Engels wrote: > I don't think that is correct - but I could be wrong. > > With platform threads the min and max latency in a completely cpu bound > scenario should be very close the the average with a completely fair > scheduler (when all tasks/threads are submitted at the same time). > > Without timesharing, the average will be the same, but the min and max > latencies will be far off the average - as the tasks submitted first > complete very quickly, and the tasks submitted at the end take a very long > time because they need to have all of the tasks before them complete. > > In regards to the the ?enough cpus? comment, I only meant that if there > are enough cpus and a ?somewhat? balanced workload, it is unlikely that all > of the cpu bounds tasks could consume all of the carrier threads given a > random distribution. If you have more active tasks than cpus and the > majority of the tasks are cpu bound, the IO tasks are going to suffer in a > non-timesliced scenario - they will be stalled waiting for a carrier thread > - even though the amount of cpu they need will be very small. > > This has a lot of info on the subject > https://docs.kernel.org/scheduler/sched-design-CFS.html including: > > On real hardware, we can run only a single task at once, so we have to > introduce the concept of ?virtual runtime.? The virtual runtime of a task > specifies when its next timeslice would start execution on the ideal > multi-tasking CPU described above. In practice, the virtual runtime of a > task is its actual runtime normalized to the total number of running tasks. > > I recommend this > https://opensource.com/article/19/2/fair-scheduling-linux for an in-depth > discussion on how the dynamic timeslices are computed. > > The linux scheduler relies on timeslicing in order to have a ?fair? > system. I think most Java ?server? type applications strive for fairness as > well - i.e. long tail latencies in anything are VERY bad (thus the constant > fight against long GC pauses - better to amortize those for consistency). > > > On Jul 3, 2024, at 10:51 AM, Ron Pressler wrote: > > > > On 29 Jun 2024, at 19:04, robert engels wrote: > > I think the issue is for cpu bound work land - eg image conversions, etc. > I think not having time sharing is only an issue for machines with low cpu > counts. The issue is that tail latency gets out of control. > > > Latency is not generally improved by time sharing regardless of the number > of CPUs. In some situations time sharing will make it (potentially much) > better, and in others it will make it (potentially much) worse. For > example, if you start many threads doing the *same* heavy computation on > platform threads and compare that to virtual threads you?ll see that the > virtual thread latencies will be much better than the platform thread > latencies. If the computation done on the different threads is very > different in its duration you?ll see the exact opposite occur. > > > IO tasks get blocked too easily. Every general workload OS has time > sharing (that I?m aware of) has time sharing just for this reason. > > > IO preempts threads both in the OS and with the virtual thread scheduler > even without time sharing. The reason non-realtime OSes have time sharing > is different, and has nothing to do with performance (realtime kernels is a > different matter). The main reason for time sharing is to keep the machine > responsive when it?s at 100% CPU to allow operator interaction, but this is > already the case with virtual threads by virtue of the fact that they?re > mapped to OS threads. > > ? Ron > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rengels at ix.netcom.com Wed Jul 3 17:27:58 2024 From: rengels at ix.netcom.com (robert engels) Date: Wed, 3 Jul 2024 12:27:58 -0500 Subject: [External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: References: <5A2E1F5D-9346-48B2-B6C8-3459FB6E32B0@oracle.com> <5C2E3DDB-6F90-44F8-9783-A2B2C77378AA@ix.netcom.com> <7196614D-E2FA-4492-BE1E-B2BB0B0DE1CE@oracle.com> <99B9907A-218C-46DF-B909-70EC39CEABAE@ix.netcom.com> <44E8FB97-4D46-4F3B-8C0C-13893A67EA9B@oracle.com> <0A2CC387-3B85-4C3F-8AEA-24B6FD1D9DB3@ix.netcom.com> Message-ID: I agree 100% - I am fighting that the auto-closing of the queues, clean-up, etc is ?unneeded magic" > On Jul 3, 2024, at 12:17 PM, Sam Pullara wrote: > > Isn't the way around this to not use a queue at all and launch a new VT for each piece of work? If this is a common issue in your code base maybe add Closeable to the queue and abort on close? Hoping it all gets collected doesn't seem like the right answer to me and not keeping the VT as a root seems wrong as well. > > On Wed, Jul 3, 2024 at 10:03?AM robert engels > wrote: > In thinking about it some more, if there is no way to enumerate VT instances, then they already differ greatly from platform threads from an API standpoint and this will affect many monitoring systems (although they probably don?t deal with millions of threads well either - as was discussed in another thread). > > I have used thread enumeration and cpu monitoring to detect ?stuck? threads (i.e. maybe the thread that was supposed to be writing to the queue died, so the reader is making no progress). With this proposal, my reader thread is just going to go away with no observability. > > I assume this is only for infinite reads - so if we add some level of timeout, then it seems you need some sort of way to detect ?no possible writer? on the queue (if my thread was allowed to continue) as this would be important to know, otherwise you have an infinite timeout loop. > > It feels like a radical change to Java queue systems and it doesn?t feel like a good one. > > I still think having the take() throw a UnsatisfiableError with the default handling be thread death would be easier to reason about, and more consistent with current Java design patterns. In fact, the reader could spawn another writer if it chose in handling this. Without an exception bubbling up, I think you are going to have threads/tasks dying all of the time, and no idea where or why the thread died (i.e. how will report which queue the take() became invalid on up the callstack if not for an exception?). > > It feels like that this will lead to a specialized VT monitoring api where you register listeners for these various conditions - why do this when there already exists the exception mechanism, default thread handlers, etc. > > > On Jul 3, 2024, at 10:44 AM, Ron Pressler > wrote: > > > > > > > >> On 3 Jul 2024, at 15:58, robert engels > wrote: > >> > >> I understand, but with a PT thread being a GC, and methods like Thread.enumerate() is was never possibly - and a ?service? could always find the ?blocked? threads and interrupt them. > >> > >> If VT are not findable (or optionally findable), I think it is a breaking change which goes against the JEP design for virtual threads, and it is going to lead to two different types of patterns for queue handling based on the thread types involved - I think this is a very bad idea. > > > > What change can you observe? > > > > You could say that you could observe a difference if there?s some weak reference to the thread, in which case the reference may be enqueued for a VT but not a PT. Only we never promise that weak references are ever enqueued; that entirely depends on the particular chosen GC, so you?d be able to observe only a difference that you?d also observe with a different selection of GC. > > > > Another difference is that you could potentially wake up a PT by enumerating all PTs, but this difference already exists today; collecting the VT doesn?t introduce any further change. > > > > I certainly can?t see what effect any of this would have on queue handling. > > > > ? Ron > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hrgdavor at gmail.com Wed Jul 3 17:28:49 2024 From: hrgdavor at gmail.com (Davor Hrg) Date: Wed, 3 Jul 2024 19:28:49 +0200 Subject: [External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: References: <5A2E1F5D-9346-48B2-B6C8-3459FB6E32B0@oracle.com> <5C2E3DDB-6F90-44F8-9783-A2B2C77378AA@ix.netcom.com> <7196614D-E2FA-4492-BE1E-B2BB0B0DE1CE@oracle.com> <99B9907A-218C-46DF-B909-70EC39CEABAE@ix.netcom.com> Message-ID: I am likely misunderstanding. Could weak reference to VT be ok, to be able to enumerate from inside the app? And gc to do its thing On Wed, 3 Jul 2024, 19:24 Attila Kelemen, wrote: > Maybe Ron will prove me wrong, but I never felt that the design of the JEP > was meant to make VT appear as PT in all aspects. In fact, what the JEP is > usually about is that it equates VT with tasks submitted to an executor. > And in that case, VT being a GC root is a strange thing. Though I think > either case is unlikely to make a difference in practice. > > robert engels ezt ?rta (id?pont: 2024. j?l. 3., > Sze, 16:58): > >> I understand, but with a PT thread being a GC, and methods like >> Thread.enumerate() is was never possibly - and a ?service? could always >> find the ?blocked? threads and interrupt them. >> >> If VT are not findable (or optionally findable), I think it is a breaking >> change which goes against the JEP design for virtual threads, and it is >> going to lead to two different types of patterns for queue handling based >> on the thread types involved - I think this is a very bad idea. >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From robaho at icloud.com Wed Jul 3 17:37:51 2024 From: robaho at icloud.com (Robert Engels) Date: Wed, 3 Jul 2024 12:37:51 -0500 Subject: [External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: References: <5A2E1F5D-9346-48B2-B6C8-3459FB6E32B0@oracle.com> <5C2E3DDB-6F90-44F8-9783-A2B2C77378AA@ix.netcom.com> <7196614D-E2FA-4492-BE1E-B2BB0B0DE1CE@oracle.com> <99B9907A-218C-46DF-B909-70EC39CEABAE@ix.netcom.com> Message-ID: <5E65D417-5184-4086-8B78-B9D4B4833763@icloud.com> Weak Refs don?t fully work - at least not the with the standard queus. if you do weakref.get().take() you?ve created a strong reference in during the duration of the take() if the VT is a GC root - which I thought they were until this discussion. But it sounds like they are only considered a GC root if they can ever be Runnable again - and that the system is going to try and determine that the VT is never runnable, so a take() will be magically ended and every reference the VT thread had to any object is cleared and things just get cleaned up. I assume finalizers and cleaners will still run for all affected objects, including the queue object itself. It?s fine and workable, but I think it is magic that Java doesn?t need. Clearly the Loom teams understands how they would implement it (I admit I have no idea - I think about it and it feels very complex to try and implement without special cases some types of VT blocks). Having PT be GC roots and not having VT threads be GC roots feels wrong to me, but I am having a hard time fully articulating why. > On Jul 3, 2024, at 12:28 PM, Davor Hrg wrote: > > I am likely misunderstanding. Could weak reference to VT be ok, to be able to enumerate from inside the app? And gc to do its thing > > > > On Wed, 3 Jul 2024, 19:24 Attila Kelemen, > wrote: > Maybe Ron will prove me wrong, but I never felt that the design of the JEP was meant to make VT appear as PT in all aspects. In fact, what the JEP is usually about is that it equates VT with tasks submitted to an executor. And in that case, VT being a GC root is a strange thing. Though I think either case is unlikely to make a difference in practice. > > robert engels > ezt ?rta (id?pont: 2024. j?l. 3., Sze, 16:58): > I understand, but with a PT thread being a GC, and methods like Thread.enumerate() is was never possibly - and a ?service? could always find the ?blocked? threads and interrupt them. > > If VT are not findable (or optionally findable), I think it is a breaking change which goes against the JEP design for virtual threads, and it is going to lead to two different types of patterns for queue handling based on the thread types involved - I think this is a very bad idea. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From attila.kelemen85 at gmail.com Wed Jul 3 17:39:47 2024 From: attila.kelemen85 at gmail.com (Attila Kelemen) Date: Wed, 3 Jul 2024 19:39:47 +0200 Subject: [External] : Re: Experience using virtual threads in EA 23-loom+4-102 In-Reply-To: <052D6B72-3AD7-442C-99BB-87F1F183BB74@icloud.com> References: <07DDEEC5-688D-45A4-A651-CFDA38E3757C@oracle.com> <2B54EE29-CDD4-47A0-8178-27F8FE2AD39F@icloud.com> <052D6B72-3AD7-442C-99BB-87F1F183BB74@icloud.com> Message-ID: I think you somewhat misunderstood Ron's comment on "same". Same means that they are progressing the same task. For example, you have a large composite task which is made up of 100 small chunks, and then you start these 100 chunks of work in parallel. If you are fair, then what you will see is that 0%, 0% ... and suddenly 100% when all of them are completed (assuming total fairness). While in case of non-fair, you will see progress that few chunks done, yet a few more done, etc. Robert Engels ezt ?rta (id?pont: 2024. j?l. 3., Sze, 18:44): > I don't think that is correct - but I could be wrong. > > With platform threads the min and max latency in a completely cpu bound > scenario should be very close the the average with a completely fair > scheduler (when all tasks/threads are submitted at the same time). > > Without timesharing, the average will be the same, but the min and max > latencies will be far off the average - as the tasks submitted first > complete very quickly, and the tasks submitted at the end take a very long > time because they need to have all of the tasks before them complete. > > In regards to the the ?enough cpus? comment, I only meant that if there > are enough cpus and a ?somewhat? balanced workload, it is unlikely that all > of the cpu bounds tasks could consume all of the carrier threads given a > random distribution. If you have more active tasks than cpus and the > majority of the tasks are cpu bound, the IO tasks are going to suffer in a > non-timesliced scenario - they will be stalled waiting for a carrier thread > - even though the amount of cpu they need will be very small. > > This has a lot of info on the subject > https://docs.kernel.org/scheduler/sched-design-CFS.html including: > > On real hardware, we can run only a single task at once, so we have to > introduce the concept of ?virtual runtime.? The virtual runtime of a task > specifies when its next timeslice would start execution on the ideal > multi-tasking CPU described above. In practice, the virtual runtime of a > task is its actual runtime normalized to the total number of running tasks. > > I recommend this > https://opensource.com/article/19/2/fair-scheduling-linux for an in-depth > discussion on how the dynamic timeslices are computed. > > The linux scheduler relies on timeslicing in order to have a ?fair? > system. I think most Java ?server? type applications strive for fairness as > well - i.e. long tail latencies in anything are VERY bad (thus the constant > fight against long GC pauses - better to amortize those for consistency). > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From attila.kelemen85 at gmail.com Wed Jul 3 17:44:13 2024 From: attila.kelemen85 at gmail.com (Attila Kelemen) Date: Wed, 3 Jul 2024 19:44:13 +0200 Subject: [External] : Re: Experience using virtual threads in EA 23-loom+4-102 In-Reply-To: References: <07DDEEC5-688D-45A4-A651-CFDA38E3757C@oracle.com> <2B54EE29-CDD4-47A0-8178-27F8FE2AD39F@icloud.com> <052D6B72-3AD7-442C-99BB-87F1F183BB74@icloud.com> Message-ID: If you want fairness that you can do as well. You can use platform threads. Fairness cannot be assumed to be free. Also there are various degrees of fairness. Sam Pullara ezt ?rta (id?pont: 2024. j?l. 3., Sze, 19:20): > As a developer trying to use this stuff, I 100% agree that fair is better. > If I need something that isn't fair, I can do that myself. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robaho at icloud.com Wed Jul 3 17:46:18 2024 From: robaho at icloud.com (Robert Engels) Date: Wed, 3 Jul 2024 12:46:18 -0500 Subject: [External] : Re: Experience using virtual threads in EA 23-loom+4-102 In-Reply-To: References: <07DDEEC5-688D-45A4-A651-CFDA38E3757C@oracle.com> <2B54EE29-CDD4-47A0-8178-27F8FE2AD39F@icloud.com> <052D6B72-3AD7-442C-99BB-87F1F183BB74@icloud.com> Message-ID: <5F0A5DAA-0333-4EFF-B297-1DFABAAC8D19@icloud.com> Tbh, I didn?t quite understand this: "Latency is not generally improved by time sharing regardless of the number of CPUs. In some situations time sharing will make it (potentially much) better, and in others it will make it (potentially much) worse. ? Because it is referring to two different things in my opinion. I would have stated this that: ?Tail latency is improved for cpu bound tasks by timesharing regardless of the number of CPUs?. I don?t see how timesharing can ever make tail latency worse - as normally the context switch overhead is a very small percentage of the timeslice allotment. Also, the statement: "IO preempts threads both in the OS and with the virtual thread scheduler even without time sharing.? is not correct according to what I know about most OSes. An OS without timeslicing will never pre-empt a completely CPU bound task - it will run to completion or be killed - those are the only options (and the latter is close to Thread.stop() which as we know is problematic). > On Jul 3, 2024, at 12:39 PM, Attila Kelemen wrote: > > I think you somewhat misunderstood Ron's comment on "same". Same means that they are progressing the same task. For example, you have a large composite task which is made up of 100 small chunks, and then you start these 100 chunks of work in parallel. If you are fair, then what you will see is that 0%, 0% ... and suddenly 100% when all of them are completed (assuming total fairness). While in case of non-fair, you will see progress that few chunks done, yet a few more done, etc. > > Robert Engels > ezt ?rta (id?pont: 2024. j?l. 3., Sze, 18:44): > I don't think that is correct - but I could be wrong. > > With platform threads the min and max latency in a completely cpu bound scenario should be very close the the average with a completely fair scheduler (when all tasks/threads are submitted at the same time). > > Without timesharing, the average will be the same, but the min and max latencies will be far off the average - as the tasks submitted first complete very quickly, and the tasks submitted at the end take a very long time because they need to have all of the tasks before them complete. > > In regards to the the ?enough cpus? comment, I only meant that if there are enough cpus and a ?somewhat? balanced workload, it is unlikely that all of the cpu bounds tasks could consume all of the carrier threads given a random distribution. If you have more active tasks than cpus and the majority of the tasks are cpu bound, the IO tasks are going to suffer in a non-timesliced scenario - they will be stalled waiting for a carrier thread - even though the amount of cpu they need will be very small. > > This has a lot of info on the subject https://docs.kernel.org/scheduler/sched-design-CFS.html including: > > On real hardware, we can run only a single task at once, so we have to introduce the concept of ?virtual runtime.? The virtual runtime of a task specifies when its next timeslice would start execution on the ideal multi-tasking CPU described above. In practice, the virtual runtime of a task is its actual runtime normalized to the total number of running tasks. > > I recommend this https://opensource.com/article/19/2/fair-scheduling-linux for an in-depth discussion on how the dynamic timeslices are computed. > > The linux scheduler relies on timeslicing in order to have a ?fair? system. I think most Java ?server? type applications strive for fairness as well - i.e. long tail latencies in anything are VERY bad (thus the constant fight against long GC pauses - better to amortize those for consistency). > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robaho at icloud.com Wed Jul 3 17:47:29 2024 From: robaho at icloud.com (Robert Engels) Date: Wed, 3 Jul 2024 12:47:29 -0500 Subject: [External] : Re: Experience using virtual threads in EA 23-loom+4-102 In-Reply-To: <5F0A5DAA-0333-4EFF-B297-1DFABAAC8D19@icloud.com> References: <07DDEEC5-688D-45A4-A651-CFDA38E3757C@oracle.com> <2B54EE29-CDD4-47A0-8178-27F8FE2AD39F@icloud.com> <052D6B72-3AD7-442C-99BB-87F1F183BB74@icloud.com> <5F0A5DAA-0333-4EFF-B297-1DFABAAC8D19@icloud.com> Message-ID: Tbc, I am referring to cpu bound tasks of equal duration (cpu time). > On Jul 3, 2024, at 12:46 PM, Robert Engels wrote: > > Tbh, I didn?t quite understand this: > > "Latency is not generally improved by time sharing regardless of the number of CPUs. In some situations time sharing will make it (potentially much) better, and in others it will make it (potentially much) worse. ? > > Because it is referring to two different things in my opinion. > > I would have stated this that: > > ?Tail latency is improved for cpu bound tasks by timesharing regardless of the number of CPUs?. > > I don?t see how timesharing can ever make tail latency worse - as normally the context switch overhead is a very small percentage of the timeslice allotment. > > Also, the statement: > > "IO preempts threads both in the OS and with the virtual thread scheduler even without time sharing.? > > is not correct according to what I know about most OSes. An OS without timeslicing will never pre-empt a completely CPU bound task - it will run to completion or be killed - those are the only options (and the latter is close to Thread.stop() which as we know is problematic). > >> On Jul 3, 2024, at 12:39 PM, Attila Kelemen > wrote: >> >> I think you somewhat misunderstood Ron's comment on "same". Same means that they are progressing the same task. For example, you have a large composite task which is made up of 100 small chunks, and then you start these 100 chunks of work in parallel. If you are fair, then what you will see is that 0%, 0% ... and suddenly 100% when all of them are completed (assuming total fairness). While in case of non-fair, you will see progress that few chunks done, yet a few more done, etc. >> >> Robert Engels > ezt ?rta (id?pont: 2024. j?l. 3., Sze, 18:44): >> I don't think that is correct - but I could be wrong. >> >> With platform threads the min and max latency in a completely cpu bound scenario should be very close the the average with a completely fair scheduler (when all tasks/threads are submitted at the same time). >> >> Without timesharing, the average will be the same, but the min and max latencies will be far off the average - as the tasks submitted first complete very quickly, and the tasks submitted at the end take a very long time because they need to have all of the tasks before them complete. >> >> In regards to the the ?enough cpus? comment, I only meant that if there are enough cpus and a ?somewhat? balanced workload, it is unlikely that all of the cpu bounds tasks could consume all of the carrier threads given a random distribution. If you have more active tasks than cpus and the majority of the tasks are cpu bound, the IO tasks are going to suffer in a non-timesliced scenario - they will be stalled waiting for a carrier thread - even though the amount of cpu they need will be very small. >> >> This has a lot of info on the subject https://docs.kernel.org/scheduler/sched-design-CFS.html including: >> >> On real hardware, we can run only a single task at once, so we have to introduce the concept of ?virtual runtime.? The virtual runtime of a task specifies when its next timeslice would start execution on the ideal multi-tasking CPU described above. In practice, the virtual runtime of a task is its actual runtime normalized to the total number of running tasks. >> >> I recommend this https://opensource.com/article/19/2/fair-scheduling-linux for an in-depth discussion on how the dynamic timeslices are computed. >> >> The linux scheduler relies on timeslicing in order to have a ?fair? system. I think most Java ?server? type applications strive for fairness as well - i.e. long tail latencies in anything are VERY bad (thus the constant fight against long GC pauses - better to amortize those for consistency). >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robaho at icloud.com Wed Jul 3 18:01:06 2024 From: robaho at icloud.com (Robert Engels) Date: Wed, 3 Jul 2024 13:01:06 -0500 Subject: [External] : Re: Experience using virtual threads in EA 23-loom+4-102 In-Reply-To: References: <07DDEEC5-688D-45A4-A651-CFDA38E3757C@oracle.com> <2B54EE29-CDD4-47A0-8178-27F8FE2AD39F@icloud.com> <052D6B72-3AD7-442C-99BB-87F1F183BB74@icloud.com> <5F0A5DAA-0333-4EFF-B297-1DFABAAC8D19@icloud.com> Message-ID: <8F515390-67CE-47AE-B99C-5CB80A61E831@icloud.com> As an example, the following demonstrates that not having timeslicing can be problematic for a ?fair? system. (make sure the task count is above your number of available processors). This can be worked around with enough observability and proper context checking and propagation, but sometimes it isn?t trivial, and the ?hang? will lurk until a certain production load hits it. import java.util.concurrent.ExecutorService; import java.util.concurrent.Executors; import java.util.concurrent.Semaphore; public class Main { public static void main(String[] args) throws InterruptedException { Semaphore s = new Semaphore(0); // ExecutorService executor = Executors.newCachedThreadPool(); // this will work ExecutorService executor = Executors.newVirtualThreadPerTaskExecutor(); // this will hang for(int i=0;i<16;i++) { executor.submit(() -> { while(true);}); } Thread.sleep(5000); executor.submit(() -> {s.release();}); s.acquire(); System.out.println("all done\n"); System.exit(0); } } > On Jul 3, 2024, at 12:47 PM, Robert Engels wrote: > > Tbc, I am referring to cpu bound tasks of equal duration (cpu time). > >> On Jul 3, 2024, at 12:46 PM, Robert Engels > wrote: >> >> Tbh, I didn?t quite understand this: >> >> "Latency is not generally improved by time sharing regardless of the number of CPUs. In some situations time sharing will make it (potentially much) better, and in others it will make it (potentially much) worse. ? >> >> Because it is referring to two different things in my opinion. >> >> I would have stated this that: >> >> ?Tail latency is improved for cpu bound tasks by timesharing regardless of the number of CPUs?. >> >> I don?t see how timesharing can ever make tail latency worse - as normally the context switch overhead is a very small percentage of the timeslice allotment. >> >> Also, the statement: >> >> "IO preempts threads both in the OS and with the virtual thread scheduler even without time sharing.? >> >> is not correct according to what I know about most OSes. An OS without timeslicing will never pre-empt a completely CPU bound task - it will run to completion or be killed - those are the only options (and the latter is close to Thread.stop() which as we know is problematic). >> >>> On Jul 3, 2024, at 12:39 PM, Attila Kelemen > wrote: >>> >>> I think you somewhat misunderstood Ron's comment on "same". Same means that they are progressing the same task. For example, you have a large composite task which is made up of 100 small chunks, and then you start these 100 chunks of work in parallel. If you are fair, then what you will see is that 0%, 0% ... and suddenly 100% when all of them are completed (assuming total fairness). While in case of non-fair, you will see progress that few chunks done, yet a few more done, etc. >>> >>> Robert Engels > ezt ?rta (id?pont: 2024. j?l. 3., Sze, 18:44): >>> I don't think that is correct - but I could be wrong. >>> >>> With platform threads the min and max latency in a completely cpu bound scenario should be very close the the average with a completely fair scheduler (when all tasks/threads are submitted at the same time). >>> >>> Without timesharing, the average will be the same, but the min and max latencies will be far off the average - as the tasks submitted first complete very quickly, and the tasks submitted at the end take a very long time because they need to have all of the tasks before them complete. >>> >>> In regards to the the ?enough cpus? comment, I only meant that if there are enough cpus and a ?somewhat? balanced workload, it is unlikely that all of the cpu bounds tasks could consume all of the carrier threads given a random distribution. If you have more active tasks than cpus and the majority of the tasks are cpu bound, the IO tasks are going to suffer in a non-timesliced scenario - they will be stalled waiting for a carrier thread - even though the amount of cpu they need will be very small. >>> >>> This has a lot of info on the subject https://docs.kernel.org/scheduler/sched-design-CFS.html including: >>> >>> On real hardware, we can run only a single task at once, so we have to introduce the concept of ?virtual runtime.? The virtual runtime of a task specifies when its next timeslice would start execution on the ideal multi-tasking CPU described above. In practice, the virtual runtime of a task is its actual runtime normalized to the total number of running tasks. >>> >>> I recommend this https://opensource.com/article/19/2/fair-scheduling-linux for an in-depth discussion on how the dynamic timeslices are computed. >>> >>> The linux scheduler relies on timeslicing in order to have a ?fair? system. I think most Java ?server? type applications strive for fairness as well - i.e. long tail latencies in anything are VERY bad (thus the constant fight against long GC pauses - better to amortize those for consistency). >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Wed Jul 3 22:22:07 2024 From: duke at openjdk.org (duke) Date: Wed, 3 Jul 2024 22:22:07 GMT Subject: git: openjdk/loom: master: 107 new changesets Message-ID: <08d657e1-1848-42b5-bb73-24131253ce02@openjdk.org> Changeset: b3bf31a0 Author: Coleen Phillimore Date: 2024-06-25 19:50:58 +0000 URL: https://git.openjdk.org/loom/commit/b3bf31a0a08da679ec2fd21613243fb17b1135a9 8333542: Breakpoint in parallel code does not work Co-authored-by: Chris Plummer Reviewed-by: dholmes, vlivanov ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/classfile/javaClasses.hpp ! src/hotspot/share/classfile/vmSymbols.hpp ! src/hotspot/share/interpreter/linkResolver.cpp ! src/hotspot/share/oops/cpCache.cpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/instanceKlass.hpp ! src/hotspot/share/runtime/sharedRuntime.cpp ! src/hotspot/share/runtime/synchronizer.cpp ! src/hotspot/share/runtime/synchronizer.hpp ! src/hotspot/share/runtime/vframe.cpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/hotspot/share/services/heapDumper.cpp ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java ! test/hotspot/jtreg/runtime/Thread/TestThreadDumpClassInitMonitor.java + test/jdk/com/sun/jdi/BreakpointOnClassPrepare.java Changeset: f101e153 Author: Volodymyr Paprotski Committer: Sandhya Viswanathan Date: 2024-06-25 22:31:39 +0000 URL: https://git.openjdk.org/loom/commit/f101e153cee68750fcf1f12da10e29806875b522 8333583: Crypto-XDH.generateSecret regression after JDK-8329538 Reviewed-by: sviswanathan, kvn, ascarpino ! make/jdk/src/classes/build/tools/intpoly/FieldGen.java ! src/hotspot/cpu/x86/stubGenerator_x86_64_poly_mont.cpp ! src/hotspot/share/classfile/vmIntrinsics.hpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/opto/runtime.cpp ! src/java.base/share/classes/sun/security/util/math/intpoly/IntegerPolynomial.java ! src/java.base/share/classes/sun/security/util/math/intpoly/IntegerPolynomial1305.java ! src/java.base/share/classes/sun/security/util/math/intpoly/IntegerPolynomialModBinP.java ! src/java.base/share/classes/sun/security/util/math/intpoly/MontgomeryIntegerPolynomialP256.java Changeset: c66f785f Author: Gui Cao Committer: Fei Yang Date: 2024-06-26 00:59:49 +0000 URL: https://git.openjdk.org/loom/commit/c66f785fb685d5c378fb4c4cdebdef29c01d321b 8334505: RISC-V: Several tests fail when MaxVectorSize does not match VM_Version::_initial_vector_length Reviewed-by: fyang ! src/hotspot/cpu/riscv/vm_version_riscv.cpp Changeset: 25c3845b Author: Kim Barrett Date: 2024-06-26 05:15:36 +0000 URL: https://git.openjdk.org/loom/commit/25c3845be270462388ee5e7330cc7315e5c738df 8333133: Simplify QuickSort::sort Reviewed-by: shade, dholmes ! src/hotspot/share/classfile/moduleEntry.cpp ! src/hotspot/share/classfile/packageEntry.cpp ! src/hotspot/share/compiler/compilationMemoryStatistic.cpp ! src/hotspot/share/gc/g1/g1CollectionSet.cpp ! src/hotspot/share/gc/g1/g1DirtyCardQueue.cpp ! src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp ! src/hotspot/share/logging/logSelection.cpp ! src/hotspot/share/oops/method.cpp ! src/hotspot/share/utilities/quickSort.hpp ! test/hotspot/gtest/gc/shared/test_oopStorage.cpp ! test/hotspot/gtest/utilities/test_quicksort.cpp Changeset: a5f401f3 Author: Christian Hagedorn Date: 2024-06-26 07:09:50 +0000 URL: https://git.openjdk.org/loom/commit/a5f401f3a8534a64cf3c27c2ef67f17860de6d6b 8334650: Add debug information about whether an Assertion Predicate is for the init or last value Reviewed-by: roland, kvn ! src/hotspot/share/opto/cfgnode.hpp ! src/hotspot/share/opto/ifnode.cpp ! src/hotspot/share/opto/loopPredicate.cpp ! src/hotspot/share/opto/loopTransform.cpp ! src/hotspot/share/opto/loopnode.hpp ! src/hotspot/share/opto/predicates.hpp Changeset: b88af942 Author: Albert Mingkun Yang Date: 2024-06-26 07:40:35 +0000 URL: https://git.openjdk.org/loom/commit/b88af94269640a160fbacf25618f3a00756464aa 8269870: PS: Membar in PSPromotionManager::copy_unmarked_to_survivor_space could be relaxed Co-authored-by: Hamlin Li Reviewed-by: mli, kbarrett, tschatzl ! src/hotspot/share/gc/parallel/psPromotionManager.inline.hpp Changeset: e1390056 Author: Thomas Stuefe Date: 2024-06-26 08:44:17 +0000 URL: https://git.openjdk.org/loom/commit/e1390056c9dbf0a02a131864ebee23435e997852 8333994: NMT: call stacks should show source information Reviewed-by: jsjolen, gziemski ! src/hotspot/share/nmt/memReporter.cpp ! src/hotspot/share/nmt/memReporter.hpp + src/hotspot/share/nmt/nativeCallStackPrinter.cpp + src/hotspot/share/nmt/nativeCallStackPrinter.hpp ! src/hotspot/share/nmt/virtualMemoryTracker.cpp ! src/hotspot/share/utilities/nativeCallStack.cpp ! src/hotspot/share/utilities/nativeCallStack.hpp ! test/hotspot/jtreg/runtime/NMT/CheckForProperDetailStackTrace.java Changeset: 7f6804ce Author: Adam Sotona Date: 2024-06-26 09:09:13 +0000 URL: https://git.openjdk.org/loom/commit/7f6804ceb63568d72e825d45b02d08f314c9b0fc 8334872: BigEndian: java/lang/invoke/condy Tests failing since JDK-8294960 Reviewed-by: redestad ! src/java.base/share/classes/java/lang/invoke/ClassSpecializer.java Changeset: 4ce8822b Author: Maurizio Cimadamore Date: 2024-06-26 09:12:02 +0000 URL: https://git.openjdk.org/loom/commit/4ce8822b6c53b8bd72713f1bfaf6673b91aabea4 8334037: Local class creation in lambda in pre-construction context crashes javac 8333313: NullPointerException in lambda instantiating an inner local class in prologue 8333766: Stack overflow with anonymous class in super() parameter 8334679: Wrong bug number in regression test for JDK-8334252 Co-authored-by: Archie Cobbs Reviewed-by: jlahoda, vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/CompileStates.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java + test/langtools/tools/javac/SuperInit/AnonSuperLambdaCrash.java + test/langtools/tools/javac/SuperInit/EarlyLocalTest1.java + test/langtools/tools/javac/SuperInit/EarlyLocalTest4.java + test/langtools/tools/javac/SuperInit/EarlyLocalTest5.java + test/langtools/tools/javac/SuperInit/EarlyLocalTest6.java + test/langtools/tools/javac/SuperInit/EarlyLocalTest7.java + test/langtools/tools/javac/SuperInit/LambdaLocalEarlyCrash.java ! test/langtools/tools/javac/SuperInit/LambdaOuterCapture.java ! test/langtools/tools/javac/lambda/T8129740/Universe.java.out Changeset: 741a0f39 Author: Hannes Walln?fer Date: 2024-06-26 09:37:22 +0000 URL: https://git.openjdk.org/loom/commit/741a0f39dd1fffc1caaa8d69bfe3662dad830452 8334241: Adjust API docs side bar dimensions Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/stylesheet.css Changeset: f23295ec Author: Daniel Fuchs Date: 2024-06-26 10:09:05 +0000 URL: https://git.openjdk.org/loom/commit/f23295ec1dde58d239a2625c9b1645534a2bb625 8334600: TEST java/net/MulticastSocket/IPMulticastIF.java fails on linux-aarch64 Reviewed-by: alanb ! test/jdk/java/net/MulticastSocket/IPMulticastIF.java Changeset: b2ac7259 Author: Kangcheng Xu Committer: Roland Westrelin Date: 2024-06-26 13:19:34 +0000 URL: https://git.openjdk.org/loom/commit/b2ac7259c96f154ba0ca54fd47b37caaa8c8647b 8327380: Add tests for Shenandoah barrier expansion optimization Reviewed-by: roland, shade + test/hotspot/jtreg/compiler/gcbarriers/TestShenandoahBarrierExpansion.java Changeset: efb905e5 Author: Matthias Baesken Date: 2024-06-26 13:37:58 +0000 URL: https://git.openjdk.org/loom/commit/efb905e57ab7a5299952419fa9961316541056c2 8334618: ubsan: support setting additional ubsan check options Reviewed-by: stuefe, lucy ! make/autoconf/jdk-options.m4 Changeset: 4ffc5e60 Author: Anthony Scarpino Date: 2024-06-26 13:58:22 +0000 URL: https://git.openjdk.org/loom/commit/4ffc5e60776353b03e9a557c39148e378b1690e2 8326705: Test CertMsgCheck.java fails to find alert certificate_required Reviewed-by: ssahoo, rhalade ! test/jdk/ProblemList.txt ! test/jdk/javax/net/ssl/SSLSession/CertMsgCheck.java ! test/jdk/javax/net/ssl/templates/TLSBase.java Changeset: 8374d165 Author: Emanuel Peter Date: 2024-06-26 14:12:44 +0000 URL: https://git.openjdk.org/loom/commit/8374d16504503c7441346c99045736b7ac72233f 8335006: C2 SuperWord: add JMH benchmark VectorLoadToStoreForwarding.java Reviewed-by: shade, kvn, sviswanathan + test/micro/org/openjdk/bench/vm/compiler/VectorLoadToStoreForwarding.java Changeset: 8591eff7 Author: Nizar Benalla Committer: Alexey Ivanov Date: 2024-06-26 14:39:21 +0000 URL: https://git.openjdk.org/loom/commit/8591eff78dbc9770b8d0a16e05040ac35c99881a 8332103: since-checker - Add missing @ since tags to java.desktop Reviewed-by: tr, aivanov ! src/java.desktop/share/classes/java/awt/geom/Path2D.java ! src/java.desktop/share/classes/java/beans/package-info.java ! src/java.desktop/share/classes/javax/swing/DefaultComboBoxModel.java ! src/java.desktop/share/classes/javax/swing/DefaultListModel.java ! src/java.desktop/share/classes/javax/swing/JSlider.java ! src/java.desktop/share/classes/javax/swing/package-info.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicSliderUI.java ! src/java.desktop/share/classes/javax/swing/plaf/synth/package-info.java ! src/java.desktop/share/classes/javax/swing/text/DefaultEditorKit.java Changeset: 5883a20b Author: Claes Redestad Date: 2024-06-26 14:46:17 +0000 URL: https://git.openjdk.org/loom/commit/5883a20b822bb8acb719076e4f7abee8403061cb 8334437: De-duplicate ProxyMethod list creation Reviewed-by: asotona, liach ! src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java Changeset: b5d58962 Author: Sonia Zaldana Calles Committer: Julian Waters Date: 2024-06-26 16:20:15 +0000 URL: https://git.openjdk.org/loom/commit/b5d589623c174757e946011495f771718318f1cc 8335108: Build error after JDK-8333658 due to class templates Reviewed-by: jwaters, jsjolen ! src/hotspot/share/nmt/arrayWithFreeList.hpp Changeset: bffc8484 Author: Justin Lu Date: 2024-06-26 17:10:09 +0000 URL: https://git.openjdk.org/loom/commit/bffc8484c32ad6c3205f7cebe4e262a2dc9de57e 8333755: NumberFormat integer only parsing breaks when format has suffix Reviewed-by: naoto ! src/java.base/share/classes/java/text/CompactNumberFormat.java ! src/java.base/share/classes/java/text/DecimalFormat.java ! src/java.base/share/classes/java/text/NumberFormat.java ! test/jdk/java/text/Format/NumberFormat/BigDecimalParse.java ! test/jdk/java/text/Format/NumberFormat/StrictParseTest.java Changeset: 817edcb6 Author: Xiaolong Peng Committer: Aleksey Shipilev Date: 2024-06-26 19:25:37 +0000 URL: https://git.openjdk.org/loom/commit/817edcb697cbb8c608c9292cdc4b99db4f5844dc 8331411: Shenandoah: Reconsider spinning duration in ShenandoahLock Reviewed-by: shade, kdnilsen, wkemper ! src/hotspot/share/gc/shenandoah/shenandoahLock.cpp ! src/hotspot/share/gc/shenandoah/shenandoahLock.hpp Changeset: 4ebb7712 Author: Zhengyu Gu Date: 2024-06-26 20:24:29 +0000 URL: https://git.openjdk.org/loom/commit/4ebb77120af5a4ccbfde63b24cb50e05a3161f16 8334769: Shenandoah: Move CodeCache_lock close to its use in ShenandoahConcurrentNMethodIterator Reviewed-by: shade, wkemper, kdnilsen ! src/hotspot/share/gc/shenandoah/shenandoahCodeRoots.cpp ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp ! src/hotspot/share/gc/shenandoah/shenandoahNMethod.cpp Changeset: 07bc523d Author: Anthony Scarpino Date: 2024-06-26 22:28:33 +0000 URL: https://git.openjdk.org/loom/commit/07bc523df85fde81bf736fedac62874d3cb11ee3 8334670: SSLSocketOutputRecord buffer miscalculation Reviewed-by: djelinski, ssahoo ! src/java.base/share/classes/sun/security/ssl/SSLSocketOutputRecord.java Changeset: 3796fdfc Author: Hannes Greule Committer: Chen Liang Date: 2024-06-26 23:17:32 +0000 URL: https://git.openjdk.org/loom/commit/3796fdfcedc2b2202b72cca062218f840960414c 8328536: javac - crash on unknown type referenced in yield statement Co-authored-by: Jan Lahoda Reviewed-by: jlahoda ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! test/langtools/jdk/jshell/ToolSimpleTest.java ! test/langtools/tools/javac/generics/diamond/7188968/T7188968.out ! test/langtools/tools/javac/lambda/MethodReference23.out ! test/langtools/tools/javac/lambda/methodReference/MethodRefToInnerWithoutOuter.out ! test/langtools/tools/javac/recovery/AttrRecovery.java Changeset: 6682305e Author: Vladimir Kozlov Date: 2024-06-27 03:34:04 +0000 URL: https://git.openjdk.org/loom/commit/6682305ee21cf595ec953d95bea594734a2982a8 8334779: Test compiler/c1/CanonicalizeArrayLength.java is timing out Reviewed-by: thartmann, dlong ! src/hotspot/cpu/x86/macroAssembler_x86.cpp Changeset: 9bb675f8 Author: Jaikiran Pai Date: 2024-06-27 04:38:32 +0000 URL: https://git.openjdk.org/loom/commit/9bb675f89dd1eeec423ca96cb3f96d29f5de477c 8334719: (se) Deferred close of SelectableChannel may result in a Selector doing the final close before concurrent I/O on channel has completed Co-authored-by: Alan Bateman Reviewed-by: alanb, dfuchs ! src/java.base/share/classes/sun/nio/ch/DatagramChannelImpl.java ! src/java.base/share/classes/sun/nio/ch/ServerSocketChannelImpl.java ! src/java.base/share/classes/sun/nio/ch/SocketChannelImpl.java ! src/java.base/unix/classes/sun/nio/ch/SinkChannelImpl.java ! src/java.base/unix/classes/sun/nio/ch/SourceChannelImpl.java + test/jdk/java/nio/channels/Selector/DeferredClose/DeferredCloseTest.java + test/jdk/java/nio/channels/Selector/DeferredClose/java.base/java/net/InetSocketAddress.java Changeset: 9d20b58f Author: Shaojin Wen Committer: Chen Liang Date: 2024-06-27 05:13:30 +0000 URL: https://git.openjdk.org/loom/commit/9d20b58f40275002afa0348d94d5592a26894e88 8334328: Reduce object allocation for FloatToDecimal and DoubleToDecimal Reviewed-by: redestad, rgiulietti ! src/java.base/share/classes/java/lang/AbstractStringBuilder.java ! src/java.base/share/classes/jdk/internal/math/DoubleToDecimal.java ! src/java.base/share/classes/jdk/internal/math/FloatToDecimal.java + src/java.base/share/classes/jdk/internal/math/ToDecimal.java ! test/micro/org/openjdk/bench/java/lang/StringBuilders.java Changeset: 0fc5b271 Author: Nizar Benalla Committer: Jan Lahoda Date: 2024-06-27 06:22:17 +0000 URL: https://git.openjdk.org/loom/commit/0fc5b2711fbdde972c40bfef2977dd9d70e09581 8332014: since-checker - Fix @ since tags in jdk.jshell Reviewed-by: jlahoda ! src/jdk.jshell/share/classes/jdk/jshell/Snippet.java ! src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysis.java ! src/jdk.jshell/share/classes/jdk/jshell/tool/JavaShellToolBuilder.java Changeset: 46b817b7 Author: Matthias Baesken Date: 2024-06-27 06:53:03 +0000 URL: https://git.openjdk.org/loom/commit/46b817b7499e74ba8812d38bcce93147ebf93b25 8333363: ubsan: instanceKlass.cpp: runtime error: member call on null pointer of type 'struct AnnotationArray' Reviewed-by: coleenp, stefank ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/metadata.hpp Changeset: f3b69da5 Author: Evemose <124714317+Evemose at users.noreply.github.com> Committer: Jan Lahoda Date: 2024-06-27 07:45:18 +0000 URL: https://git.openjdk.org/loom/commit/f3b69da55a1ec4857fff1537a80ab1fefee93dac 8335136: Underscore as parameter name in one-parameter functional types fails to compile Reviewed-by: jlahoda ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java + test/langtools/tools/javac/switchexpr/ExpressionSwitchUnderscoreAfterYield.java Changeset: 37e7698c Author: Kevin Walls Date: 2024-06-27 07:54:35 +0000 URL: https://git.openjdk.org/loom/commit/37e7698c29b8673b904945d397f0698ccd16d27b 8335154: jcmd VM.classes -verbose=false does not set verbose to false Reviewed-by: dholmes, stuefe ! src/hotspot/share/services/diagnosticCommand.cpp Changeset: 79a23017 Author: Albert Mingkun Yang Date: 2024-06-27 10:23:55 +0000 URL: https://git.openjdk.org/loom/commit/79a23017fc7154738c375fbb12a997525c3bf9e7 8322859: Parallel: Move transform_stack_chunk Reviewed-by: stefank, tschatzl ! src/hotspot/share/gc/parallel/psPromotionManager.inline.hpp Changeset: 50dd962b Author: Thomas Stuefe Date: 2024-06-27 12:56:26 +0000 URL: https://git.openjdk.org/loom/commit/50dd962b0d0fe36634d96dbbd9d94fbc34d9ff7f 8335007: Inline OopMapCache table Reviewed-by: stefank, coleenp, shade ! src/hotspot/share/interpreter/oopMapCache.cpp ! src/hotspot/share/interpreter/oopMapCache.hpp Changeset: 6b961acb Author: Albert Mingkun Yang Date: 2024-06-27 13:03:21 +0000 URL: https://git.openjdk.org/loom/commit/6b961acb87c29027f2158c6b7a764f1276a0bf52 8333786: Serial: Remove SerialHeap::_incremental_collection_failed Reviewed-by: tschatzl, iwalulya ! src/hotspot/share/gc/serial/defNewGeneration.cpp ! src/hotspot/share/gc/serial/defNewGeneration.hpp ! src/hotspot/share/gc/serial/serialHeap.cpp ! src/hotspot/share/gc/serial/serialHeap.hpp Changeset: d5375c7d Author: Sonia Zaldana Calles Committer: Thomas Stuefe Date: 2024-06-27 13:22:04 +0000 URL: https://git.openjdk.org/loom/commit/d5375c7db658de491c1f5bad053040d21b82941e 8333308: javap --system handling doesn't work on internal class names Reviewed-by: liach, stuefe ! src/jdk.jdeps/share/classes/com/sun/tools/javap/JavapTask.java Changeset: 5909d541 Author: Axel Boldt-Christmas Date: 2024-06-27 14:21:34 +0000 URL: https://git.openjdk.org/loom/commit/5909d54147355dd7da5786ff39ead4c15816705c 8326820: Metadata artificially kept alive Reviewed-by: eosterlund, stefank, coleenp ! src/hotspot/share/classfile/classLoaderDataGraph.cpp ! src/hotspot/share/classfile/classLoaderDataGraph.hpp ! src/hotspot/share/classfile/classLoaderStats.cpp ! src/hotspot/share/classfile/systemDictionary.hpp ! src/hotspot/share/prims/jvmtiEnvBase.cpp ! src/hotspot/share/prims/jvmtiGetLoadedClasses.cpp Changeset: 4ab7e98c Author: Francisco Ferrari Bihurriet Committer: Martin Balao Date: 2024-06-27 15:07:00 +0000 URL: https://git.openjdk.org/loom/commit/4ab7e98c79a1a0b7aba1ca74a8316820c906e70e 8330842: Support AES CBC with Ciphertext Stealing (CTS) in SunPKCS11 Co-authored-by: Francisco Ferrari Bihurriet Co-authored-by: Martin Balao Reviewed-by: valeriep ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/Config.java ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/Token.java + test/jdk/sun/security/pkcs11/Cipher/TestCipherTextStealingMultipart.java ! test/jdk/sun/security/pkcs11/Cipher/TestSymmCiphers.java ! test/jdk/sun/security/pkcs11/Cipher/TestSymmCiphersNoPad.java Changeset: b6ffb442 Author: Daniel Jeli?ski Date: 2024-06-27 15:14:36 +0000 URL: https://git.openjdk.org/loom/commit/b6ffb442acb4a222f017868433eff213d9b84ed8 8335135: HttpURLConnection#HttpInputStream does not throw IOException when response is truncated Reviewed-by: dfuchs ! src/java.base/share/classes/sun/net/www/MeteredStream.java ! test/jdk/java/net/Authenticator/BasicTest4.java + test/jdk/java/net/URLConnection/TruncatedFixedResponse.java ! test/jdk/sun/net/www/http/KeepAliveStream/KeepAliveStreamCloseWithWrongContentLength.java Changeset: 0e6b0cba Author: Erik Gahlin Date: 2024-06-27 15:38:06 +0000 URL: https://git.openjdk.org/loom/commit/0e6b0cbaaa0d5272f60ee4fe09cf5e247e68c2a8 8334886: jdk/jfr/api/recording/time/TestTimeMultiple.java failed with RuntimeException: getStopTime() > afterStop Reviewed-by: mgronlun ! src/hotspot/share/jfr/recorder/repository/jfrChunk.cpp ! src/jdk.jfr/share/classes/jdk/jfr/internal/JVMSupport.java Changeset: 9d986a01 Author: Vladimir Kozlov Date: 2024-06-27 16:06:35 +0000 URL: https://git.openjdk.org/loom/commit/9d986a013d01a5bcc0942bcc490258038291c22c 8335220: C2: Missing check for Opaque4 node in EscapeAnalysis Reviewed-by: chagedorn, cslucas ! src/hotspot/share/opto/escape.cpp Changeset: 243bae7d Author: Vladimir Ivanov Date: 2024-06-27 18:25:16 +0000 URL: https://git.openjdk.org/loom/commit/243bae7dc0c3e71c02ffed9e1ee7d436af11d3b9 8304693: Remove -XX:-UseVtableBasedCHA Reviewed-by: kvn, coleenp, dholmes ! src/hotspot/share/ci/ciMethod.cpp ! src/hotspot/share/code/dependencies.cpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/instanceKlass.hpp ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/globals.hpp ! test/hotspot/jtreg/compiler/cha/AbstractRootMethod.java ! test/hotspot/jtreg/compiler/cha/DefaultRootMethod.java ! test/hotspot/jtreg/compiler/cha/StrengthReduceInterfaceCall.java - test/hotspot/jtreg/runtime/InvocationTests/invocationOldCHATests.java ! test/jtreg-ext/requires/VMProps.java Changeset: c35e58a5 Author: Ioi Lam Date: 2024-06-27 20:10:13 +0000 URL: https://git.openjdk.org/loom/commit/c35e58a5adf06e25a3b482e2be384af95a84f11a 8309634: Resolve CONSTANT_MethodRef at CDS dump time Reviewed-by: matsaave, ccheung ! src/hotspot/share/cds/classListParser.cpp ! src/hotspot/share/cds/classListWriter.cpp ! src/hotspot/share/cds/classPrelinker.cpp ! src/hotspot/share/cds/dumpAllocStats.cpp ! src/hotspot/share/cds/dumpAllocStats.hpp ! src/hotspot/share/interpreter/interpreterRuntime.cpp ! src/hotspot/share/interpreter/interpreterRuntime.hpp ! src/hotspot/share/interpreter/linkResolver.cpp ! src/hotspot/share/interpreter/linkResolver.hpp ! src/hotspot/share/oops/cpCache.cpp ! src/hotspot/share/oops/cpCache.hpp ! src/hotspot/share/oops/resolvedMethodEntry.hpp ! test/hotspot/jtreg/runtime/cds/appcds/resolvedConstants/ResolvedConstants.java Changeset: 3b1ca986 Author: Vladimir Petko Committer: Erik Joelsson Date: 2024-06-27 20:27:51 +0000 URL: https://git.openjdk.org/loom/commit/3b1ca986427d3a69c9e167b9b4c07d1b83bc264d 8334895: OpenJDK fails to configure on linux aarch64 when CDS is disabled after JDK-8331942 Reviewed-by: erikj ! make/autoconf/jdk-options.m4 Changeset: 4e8cbf88 Author: Chris Plummer Date: 2024-06-27 22:20:14 +0000 URL: https://git.openjdk.org/loom/commit/4e8cbf884ab1eee9c3110712ab62edc706e948ba 8335134: Test com/sun/jdi/BreakpointOnClassPrepare.java timeout Reviewed-by: kevinw, coleenp ! test/jdk/com/sun/jdi/BreakpointOnClassPrepare.java Changeset: cd46c87d Author: Gui Cao Committer: Fei Yang Date: 2024-06-28 01:44:14 +0000 URL: https://git.openjdk.org/loom/commit/cd46c87dc916b2b74067accf80c62df1792f74cf 8334843: RISC-V: Fix wraparound checking for r_array_index in lookup_secondary_supers_table_slow_path Reviewed-by: fyang ! src/hotspot/cpu/riscv/macroAssembler_riscv.cpp Changeset: b4df380f Author: Jan Kratochvil Committer: Kim Barrett Date: 2024-06-28 03:07:09 +0000 URL: https://git.openjdk.org/loom/commit/b4df380f1a4587247a843fe28ae041265f7cfc29 8334763: --enable-asan: assert(_thread->is_in_live_stack((address)this)) failed: not on stack? Reviewed-by: kbarrett, stuefe, erikj ! make/autoconf/jdk-options.m4 Changeset: 308a8123 Author: Evgeny Nikitin Committer: Leonid Mesnik Date: 2024-06-28 04:42:33 +0000 URL: https://git.openjdk.org/loom/commit/308a81238362c39f5b18e2ae8444c96420ef297a 8334645: Un-problemlist vmTestbase/nsk/sysdict/vm/stress/chain/chain007/chain007.java Reviewed-by: thartmann, lmesnik ! test/hotspot/jtreg/ProblemList-generational-zgc.txt ! test/hotspot/jtreg/ProblemList-zgc.txt Changeset: c47a0e00 Author: Xiaolong Peng Committer: Y. Srinivas Ramakrishna Date: 2024-06-28 06:19:37 +0000 URL: https://git.openjdk.org/loom/commit/c47a0e005e54551e42ee1ae33d7169417a5f86d4 8334147: Shenandoah: Avoid taking lock for disabled free set logging Reviewed-by: shade, ysr ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp ! src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp ! src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp ! src/hotspot/share/gc/shenandoah/shenandoahFreeSet.hpp Changeset: d457609f Author: Amit Kumar Date: 2024-06-28 06:43:32 +0000 URL: https://git.openjdk.org/loom/commit/d457609f700bbb1fed233f1a04501c995852e5ac 8319947: Recursive lightweight locking: s390x implementation Reviewed-by: aboldtch, lucy ! src/hotspot/cpu/s390/c1_MacroAssembler_s390.cpp ! src/hotspot/cpu/s390/c2_MacroAssembler_s390.cpp ! src/hotspot/cpu/s390/c2_MacroAssembler_s390.hpp ! src/hotspot/cpu/s390/interp_masm_s390.cpp ! src/hotspot/cpu/s390/macroAssembler_s390.cpp ! src/hotspot/cpu/s390/macroAssembler_s390.hpp ! src/hotspot/cpu/s390/s390.ad ! src/hotspot/cpu/s390/sharedRuntime_s390.cpp ! src/hotspot/cpu/s390/vm_version_s390.hpp Changeset: 3b3a19e9 Author: Albert Mingkun Yang Date: 2024-06-28 08:27:07 +0000 URL: https://git.openjdk.org/loom/commit/3b3a19e907c7267f03c0b07312b929b7b4b6d200 8335314: Problem list compiler/uncommontrap/DeoptReallocFailure.java Reviewed-by: chagedorn ! test/hotspot/jtreg/ProblemList.txt Changeset: 6f4ddc2f Author: Christian Hagedorn Date: 2024-06-28 09:23:48 +0000 URL: https://git.openjdk.org/loom/commit/6f4ddc2f6bf0dd9a626a76d0f5e56a54c6cf6b65 8335142: compiler/c1/TestTraceLinearScanLevel.java occasionally times out with -Xcomp Reviewed-by: thartmann, kvn ! test/hotspot/jtreg/compiler/c1/TestTraceLinearScanLevel.java Changeset: 99d2bbf7 Author: Jan Lahoda Date: 2024-06-28 09:31:14 +0000 URL: https://git.openjdk.org/loom/commit/99d2bbf767ac33e1a021c90ba12d95ef37ea4816 8334433: jshell.exe runs an executable test.exe on startup Reviewed-by: jpai ! src/jdk.internal.le/share/classes/jdk/internal/org/jline/utils/OSUtils.java ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/ConsoleIOContext.java + test/langtools/jdk/jshell/TerminalNoExecTest.java Changeset: c798316b Author: SendaoYan Committer: Daniel Fuchs Date: 2024-06-28 09:38:18 +0000 URL: https://git.openjdk.org/loom/commit/c798316bc4cb33fd902f926030d8a0b6870d661a 8269657: Test java/nio/channels/DatagramChannel/Loopback.java failed: Unexpected message Reviewed-by: dfuchs ! test/jdk/java/nio/channels/DatagramChannel/Loopback.java Changeset: 8ec378a6 Author: Daniel Fuchs Date: 2024-06-28 11:03:29 +0000 URL: https://git.openjdk.org/loom/commit/8ec378a6c8a460dd0727df800419b3cf45d3c57a 8277949: (dc) java/nio/channels/DatagramChannel/AdaptorBasic.java failed in timeout Reviewed-by: jpai ! test/jdk/java/nio/channels/DatagramChannel/AdaptorBasic.java ! test/jdk/java/nio/channels/TestServers.java Changeset: 49eb00da Author: Daniel Fuchs Date: 2024-06-28 11:13:11 +0000 URL: https://git.openjdk.org/loom/commit/49eb00da8dc66cff3ca430f06ab21357ee6180ef 8299813: java/nio/channels/DatagramChannel/Disconnect.java fails with jtreg test timeout due to lost datagram Reviewed-by: aefimov ! test/jdk/java/nio/channels/DatagramChannel/Disconnect.java Changeset: f4d8c005 Author: Fernando Guallini Committer: Weijun Wang Date: 2024-06-28 12:45:26 +0000 URL: https://git.openjdk.org/loom/commit/f4d8c005b35ce34c96027b7f3abb7a307bca3f4c 8334562: Automate com/sun/security/auth/callback/TextCallbackHandler/Default.java test Reviewed-by: weijun ! test/jdk/ProblemList.txt ! test/jdk/TEST.groups ! test/jdk/com/sun/security/auth/callback/TextCallbackHandler/Default.java + test/jdk/java/security/testlibrary/HumanInputStream.java ! test/jdk/sun/security/tools/keytool/KeyToolTest.java Changeset: 486aa11e Author: Matthias Baesken Date: 2024-06-28 13:28:53 +0000 URL: https://git.openjdk.org/loom/commit/486aa11e74d0772ba84c2adc3c62fc1fcbf52604 8335237: ubsan: vtableStubs.hpp is_vtable_stub exclude from ubsan checks Reviewed-by: mdoerr, clanger ! src/hotspot/share/code/vtableStubs.hpp Changeset: 45c4eaa5 Author: Aleksey Shipilev Date: 2024-06-28 16:26:34 +0000 URL: https://git.openjdk.org/loom/commit/45c4eaa5600016d3da5ca769b2519df53835e4f7 8335274: SwitchBootstraps.ResolvedEnumLabels.resolvedEnum should be final Reviewed-by: liach, jlahoda ! src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java Changeset: 79a3554e Author: Kevin Walls Date: 2024-06-28 19:01:36 +0000 URL: https://git.openjdk.org/loom/commit/79a3554e1da604627b3a010dc269c1bd914c79d3 8335124: com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java failed with CPU time out of expected range Reviewed-by: phh, cjplummer ! test/jdk/com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java Changeset: 3e23e9c5 Author: Fernando Guallini Committer: Weijun Wang Date: 2024-06-28 19:17:24 +0000 URL: https://git.openjdk.org/loom/commit/3e23e9c535e0ed1d7517a836d4703c7fb3e917e4 8335344: test/jdk/sun/security/tools/keytool/NssTest.java fails to compile Reviewed-by: weijun ! test/jdk/sun/security/tools/keytool/NssTest.java Changeset: 166f9d9a Author: Vladimir Kozlov Date: 2024-06-28 19:36:00 +0000 URL: https://git.openjdk.org/loom/commit/166f9d9ac099fa971805511b32e1cae5c6c108e0 8335221: Some C2 intrinsics incorrectly assume that type argument is compile-time constant Reviewed-by: roland, chagedorn ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/opto/library_call.hpp Changeset: 5d866bf1 Author: Shaojin Wen Committer: Chen Liang Date: 2024-06-28 22:27:34 +0000 URL: https://git.openjdk.org/loom/commit/5d866bf17d96bd0f0e4545d7eee5912eda2e3a94 8335252: Reduce size of j.u.Formatter.Conversion#isValid Reviewed-by: redestad ! src/java.base/share/classes/java/util/Formatter.java Changeset: 8350b1da Author: Kim Barrett Date: 2024-06-29 05:04:47 +0000 URL: https://git.openjdk.org/loom/commit/8350b1daedae8ef5785a7165e664b1d3149b18b7 8335294: Fix simple -Wzero-as-null-pointer-constant warnings in gc code Reviewed-by: tschatzl, coleenp, jwaters ! src/hotspot/os/linux/gc/x/xPhysicalMemoryBacking_linux.cpp ! src/hotspot/os/linux/gc/z/zPhysicalMemoryBacking_linux.cpp ! src/hotspot/share/gc/parallel/parMarkBitMap.cpp ! src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp ! src/hotspot/share/gc/parallel/psParallelCompact.cpp ! src/hotspot/share/gc/z/zPage.inline.hpp ! test/hotspot/jtreg/vmTestbase/gc/gctests/nativeGC01/libnativeGC01.cpp ! test/hotspot/jtreg/vmTestbase/gc/gctests/nativeGC02/libnativeGC02.cpp ! test/hotspot/jtreg/vmTestbase/gc/gctests/nativeGC03/libnativeGC03.cpp ! test/hotspot/jtreg/vmTestbase/gc/gctests/nativeGC05/libnativeGC05.cpp Changeset: bb18498d Author: Kevin Walls Date: 2024-06-29 08:19:33 +0000 URL: https://git.openjdk.org/loom/commit/bb18498d71dddf49db9bdfac886aed9ae123651d 8335349: jcmd VM.classloaders "fold" option should be optional Reviewed-by: cjplummer, stuefe ! src/hotspot/share/classfile/classLoaderHierarchyDCmd.cpp Changeset: d9bcf061 Author: Zhengyu Gu Date: 2024-06-29 20:40:51 +0000 URL: https://git.openjdk.org/loom/commit/d9bcf061450ebfb7fe02b5a50c855db1d9178e5d 8335217: Fix memory ordering in ClassLoaderData::ChunkedHandleList Reviewed-by: dholmes, stefank, eosterlund ! src/hotspot/share/classfile/classLoaderData.cpp Changeset: 53242cdf Author: Matthias Baesken Date: 2024-07-01 06:37:09 +0000 URL: https://git.openjdk.org/loom/commit/53242cdf9ef17c502ebd541e84370e7c158639c1 8335283: Build failure due to 'no_sanitize' attribute directive ignored Reviewed-by: shade, tschatzl, kbarrett, jwaters ! src/hotspot/share/sanitizers/ub.hpp Changeset: c7e9ebb4 Author: Suchismith Roy Committer: Martin Doerr Date: 2024-07-01 08:07:42 +0000 URL: https://git.openjdk.org/loom/commit/c7e9ebb4cfff56b7a977eb2942f563f96b3336bd 8331732: [PPC64] Unify and optimize code which converts != 0 to 1 Reviewed-by: mdoerr, amitkumar ! src/hotspot/cpu/ppc/assembler_ppc.hpp ! src/hotspot/cpu/ppc/assembler_ppc.inline.hpp ! src/hotspot/cpu/ppc/macroAssembler_ppc.cpp ! src/hotspot/cpu/ppc/macroAssembler_ppc.hpp ! src/hotspot/cpu/ppc/macroAssembler_ppc.inline.hpp ! src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp ! src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp Changeset: 71e3798b Author: Albert Mingkun Yang Date: 2024-07-01 08:12:20 +0000 URL: https://git.openjdk.org/loom/commit/71e3798bf67cddef37a8b4e377c4bf21dbd01567 8335308: compiler/uncommontrap/DeoptReallocFailure.java times out with SerialGC on Windows Reviewed-by: kvn, thartmann, chagedorn ! test/hotspot/jtreg/ProblemList.txt ! test/hotspot/jtreg/compiler/uncommontrap/DeoptReallocFailure.java Changeset: 0a6ffa57 Author: Severin Gehwolf Date: 2024-07-01 08:47:29 +0000 URL: https://git.openjdk.org/loom/commit/0a6ffa57954ddf4f92205205a5a1bada813d127a 8261242: [Linux] OSContainer::is_containerized() returns true when run outside a container Reviewed-by: stuefe, iklam ! src/hotspot/os/linux/cgroupSubsystem_linux.cpp ! src/hotspot/os/linux/cgroupSubsystem_linux.hpp ! src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp ! src/hotspot/os/linux/cgroupV1Subsystem_linux.hpp ! src/hotspot/os/linux/cgroupV2Subsystem_linux.cpp ! src/hotspot/os/linux/cgroupV2Subsystem_linux.hpp ! src/hotspot/os/linux/osContainer_linux.cpp ! src/hotspot/share/include/jvm.h ! src/hotspot/share/prims/jvm.cpp ! src/java.base/linux/classes/jdk/internal/platform/CgroupMetrics.java ! src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystem.java ! src/java.base/linux/native/libjava/CgroupMetrics.c ! src/java.base/share/classes/jdk/internal/platform/Metrics.java ! src/java.base/share/classes/sun/launcher/LauncherHelper.java ! test/hotspot/gtest/runtime/test_cgroupSubsystem_linux.cpp ! test/hotspot/jtreg/ProblemList.txt - test/hotspot/jtreg/containers/cgroup/PlainRead.java + test/hotspot/jtreg/containers/cgroup/TestContainerized.java + test/jdk/jdk/internal/platform/cgroup/TestSystemSettings.java ! test/lib/jdk/test/lib/containers/cgroup/MetricsTester.java Changeset: 747e1e47 Author: Evgeny Nikitin Committer: Tobias Hartmann Date: 2024-07-01 10:21:31 +0000 URL: https://git.openjdk.org/loom/commit/747e1e47f576b0ca3ac97d1deea87418e67ff2d1 8334295: CTW: update modules Reviewed-by: shade, thartmann ! test/hotspot/jtreg/applications/ctw/modules/generate.bash + test/hotspot/jtreg/applications/ctw/modules/jdk_incubator_vector.java + test/hotspot/jtreg/applications/ctw/modules/jdk_internal_md.java + test/hotspot/jtreg/applications/ctw/modules/jdk_jpackage.java + test/hotspot/jtreg/applications/ctw/modules/jdk_nio_mapmode.java Changeset: 3ca2bcd4 Author: Adam Sotona Date: 2024-07-01 11:51:13 +0000 URL: https://git.openjdk.org/loom/commit/3ca2bcd402042791d7460dd79ee16a3f88436b3e 8335060: ClassCastException after JDK-8294960 Reviewed-by: liach, jpai ! src/java.base/share/classes/java/lang/invoke/TypeConvertingMethodAdapter.java + test/jdk/java/lang/invoke/TypeConvertingTest.java Changeset: 2f4f6cc3 Author: Arseny Bochkarev Committer: Ludovic Henry Date: 2024-07-01 12:19:49 +0000 URL: https://git.openjdk.org/loom/commit/2f4f6cc34c10c5519c74abbce8d1715013b50d5d 8317721: RISC-V: Implement CRC32 intrinsic Reviewed-by: vkempik, rehn ! src/hotspot/cpu/riscv/c1_LIRAssembler_riscv.cpp ! src/hotspot/cpu/riscv/c1_LIRGenerator_riscv.cpp ! src/hotspot/cpu/riscv/macroAssembler_riscv.cpp ! src/hotspot/cpu/riscv/macroAssembler_riscv.hpp ! src/hotspot/cpu/riscv/stubGenerator_riscv.cpp ! src/hotspot/cpu/riscv/stubRoutines_riscv.cpp ! src/hotspot/cpu/riscv/stubRoutines_riscv.hpp ! src/hotspot/cpu/riscv/vm_version_riscv.cpp Changeset: ee4720a7 Author: Leonid Mesnik Date: 2024-07-01 20:38:55 +0000 URL: https://git.openjdk.org/loom/commit/ee4720a75d815c84039055902c88b360737a1f9c 8333306: gc/arguments/TestParallelGCErgo.java fails when largepage are enabled Reviewed-by: ayang, zgu ! test/hotspot/jtreg/gc/arguments/TestParallelGCErgo.java Changeset: 5fe07b36 Author: Prasanta Sadhukhan Date: 2024-07-02 03:39:43 +0000 URL: https://git.openjdk.org/loom/commit/5fe07b36d9eb296661692d903ed0b9b5afefba0f 5021949: JSplitPane setEnabled(false) shouldn't be partially functional Reviewed-by: abhiscxk, achung, aivanov ! src/java.desktop/share/classes/javax/swing/JSplitPane.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicSplitPaneDivider.java + test/jdk/javax/swing/JSplitPane/TestSplitPaneEnableTest.java Changeset: 318d9aca Author: Kim Barrett Date: 2024-07-02 05:56:21 +0000 URL: https://git.openjdk.org/loom/commit/318d9acadf305f9d7d0cd8bb54b41506dd9914a8 8335369: Fix -Wzero-as-null-pointer-constant warnings in ImmutableOopMapBuilder Reviewed-by: kvn, jwaters ! src/hotspot/share/compiler/oopMap.hpp Changeset: 9046d7ae Author: Emanuel Peter Date: 2024-07-02 08:20:26 +0000 URL: https://git.openjdk.org/loom/commit/9046d7aee3082b6cbf79876efc1c508cb893caad 8335390: C2 MergeStores: wrong result with Unsafe Reviewed-by: thartmann, chagedorn, kvn ! src/hotspot/share/opto/memnode.cpp ! test/hotspot/jtreg/compiler/c2/TestMergeStores.java + test/hotspot/jtreg/compiler/c2/TestMergeStoresUnsafeArrayPointer.java Changeset: 4060b35b Author: Kim Barrett Date: 2024-07-02 08:58:20 +0000 URL: https://git.openjdk.org/loom/commit/4060b35b1d00fccbec4b20353063f77c43ecc686 8335298: Fix -Wzero-as-null-pointer-constant warning in G1CardSetContainers Reviewed-by: iwalulya, ayang ! src/hotspot/share/gc/g1/g1CardSetContainers.hpp Changeset: a537e87d Author: Daniel Fuchs Date: 2024-07-02 11:50:21 +0000 URL: https://git.openjdk.org/loom/commit/a537e87d2d2c6bff63f63bb436e3e919740221ce 8335530: Java file extension missing in AuthenticatorTest Reviewed-by: cstein, jpai - test/jdk/com/sun/net/httpserver/AuthenticatorTest + test/jdk/com/sun/net/httpserver/AuthenticatorTest.java Changeset: dd74e7f8 Author: Albert Mingkun Yang Date: 2024-07-02 12:15:02 +0000 URL: https://git.openjdk.org/loom/commit/dd74e7f8c1570ed34c89f4aca184f5668e4471db 8335147: Serial: Refactor TenuredGeneration::promote Reviewed-by: tschatzl, iwalulya ! src/hotspot/share/gc/serial/defNewGeneration.cpp ! src/hotspot/share/gc/serial/tenuredGeneration.cpp ! src/hotspot/share/gc/serial/tenuredGeneration.hpp Changeset: 685e5878 Author: Jasmine Karthikeyan Date: 2024-07-02 14:36:29 +0000 URL: https://git.openjdk.org/loom/commit/685e5878b823fa5e3ae88ffd76de6507d6057af2 8334816: compiler/c2/irTests/TestIfMinMax.java fails after 8334629 Reviewed-by: thartmann, chagedorn ! test/hotspot/jtreg/ProblemList.txt ! test/hotspot/jtreg/compiler/c2/irTests/TestIfMinMax.java Changeset: 153b12b9 Author: Severin Gehwolf Date: 2024-07-02 15:38:54 +0000 URL: https://git.openjdk.org/loom/commit/153b12b9df87fdf8122cae3bf7f13078f55f7101 8331560: Refactor Hotspot container detection code so that subsystem delegates to controllers Reviewed-by: jsjolen, stuefe ! src/hotspot/os/linux/cgroupSubsystem_linux.cpp ! src/hotspot/os/linux/cgroupSubsystem_linux.hpp + src/hotspot/os/linux/cgroupUtil_linux.cpp + src/hotspot/os/linux/cgroupUtil_linux.hpp ! src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp ! src/hotspot/os/linux/cgroupV1Subsystem_linux.hpp ! src/hotspot/os/linux/cgroupV2Subsystem_linux.cpp ! src/hotspot/os/linux/cgroupV2Subsystem_linux.hpp Changeset: a3479576 Author: Chris Plummer Date: 2024-07-02 18:13:50 +0000 URL: https://git.openjdk.org/loom/commit/a3479576c9b3e557cdc04e0984da6350e985dcc9 8335291: Problem list all SA core file tests on macosx-aarch64 due to JDK-8318754 Reviewed-by: kevinw, amenkov ! test/hotspot/jtreg/ProblemList.txt Changeset: 27982c8f Author: Viktor Klang Date: 2024-07-02 20:27:52 +0000 URL: https://git.openjdk.org/loom/commit/27982c8f5dad0e2d080846f803055c84bac9fddd 8327854: Test java/util/stream/test/org/openjdk/tests/java/util/stream/WhileOpStatefulTest.java failed with RuntimeException Reviewed-by: psandoz ! test/jdk/java/util/stream/test/org/openjdk/tests/java/util/stream/WhileOpStatefulTest.java Changeset: 1ef34c18 Author: Chen Liang Date: 2024-07-02 23:15:31 +0000 URL: https://git.openjdk.org/loom/commit/1ef34c183315b70ddc27c177a2867e30132609f5 8335475: ClassBuilder incorrectly calculates max_locals in some cases Reviewed-by: asotona ! src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java ! test/jdk/jdk/classfile/StackMapsTest.java Changeset: f187c92b Author: Kim Barrett Date: 2024-07-03 02:19:54 +0000 URL: https://git.openjdk.org/loom/commit/f187c92befbe63e23b11eb0401e5095c44c24389 8335370: Fix -Wzero-as-null-pointer-constant warning in jvmti_common.hpp Reviewed-by: jwaters, amenkov, sspitsyn ! test/lib/jdk/test/lib/jvmti/jvmti_common.hpp Changeset: 3a2d4264 Author: Chen Liang Date: 2024-07-03 02:42:06 +0000 URL: https://git.openjdk.org/loom/commit/3a2d426489ead9672512e0c5a6862284a54734ba 8334726: Remove accidentally exposed individual methods from Class-File API Reviewed-by: asotona ! src/java.base/share/classes/java/lang/classfile/attribute/ModuleAttribute.java ! src/java.base/share/classes/java/lang/classfile/components/CodeRelabeler.java ! src/java.base/share/classes/java/lang/classfile/constantpool/ConstantPoolBuilder.java ! src/java.base/share/classes/jdk/internal/classfile/impl/CodeRelabelerImpl.java ! src/java.base/share/classes/jdk/internal/classfile/impl/ModuleAttributeBuilderImpl.java ! src/java.base/share/classes/jdk/internal/classfile/impl/SplitConstantPool.java ! src/java.base/share/classes/jdk/internal/classfile/impl/TemporaryConstantPool.java Changeset: 8a664a4c Author: Chen Liang Date: 2024-07-03 02:43:41 +0000 URL: https://git.openjdk.org/loom/commit/8a664a4c359deefd7237f3672b62d7d8c1ffb453 8334734: Remove specialized readXxxEntry methods from ClassReader Reviewed-by: asotona ! src/java.base/share/classes/java/lang/classfile/ClassReader.java ! src/java.base/share/classes/jdk/internal/classfile/impl/AbstractInstruction.java ! src/java.base/share/classes/jdk/internal/classfile/impl/AnnotationReader.java ! src/java.base/share/classes/jdk/internal/classfile/impl/BoundAttribute.java ! src/java.base/share/classes/jdk/internal/classfile/impl/BoundRecordComponentInfo.java ! src/java.base/share/classes/jdk/internal/classfile/impl/ClassImpl.java ! src/java.base/share/classes/jdk/internal/classfile/impl/ClassReaderImpl.java ! src/java.base/share/classes/jdk/internal/classfile/impl/FieldImpl.java ! src/java.base/share/classes/jdk/internal/classfile/impl/MethodImpl.java Changeset: f7af4504 Author: Chen Liang Date: 2024-07-03 02:49:43 +0000 URL: https://git.openjdk.org/loom/commit/f7af4504a804711d93208b763b3e41eafcf61735 8335110: Fix instruction name and API spec inconsistencies in CodeBuilder Reviewed-by: asotona ! src/java.base/share/classes/java/lang/classfile/CodeBuilder.java ! src/java.base/share/classes/java/lang/classfile/attribute/CodeAttribute.java ! src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java ! src/java.base/share/classes/jdk/internal/classfile/impl/LabelImpl.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/EventInstrumentation.java ! test/jdk/jdk/classfile/helpers/RebuildingTransformation.java Changeset: f9b4ea13 Author: Xiaolong Peng Committer: David Holmes Date: 2024-07-03 02:56:17 +0000 URL: https://git.openjdk.org/loom/commit/f9b4ea13e693da268c9aee27dee49f9c7f798bb1 8334220: Optimize Klass layout after JDK-8180450 Reviewed-by: coleenp, stuefe, dholmes ! src/hotspot/share/oops/klass.hpp Changeset: fac74b11 Author: Xiaolong Peng Committer: David Holmes Date: 2024-07-03 03:01:06 +0000 URL: https://git.openjdk.org/loom/commit/fac74b118f5fda4ec297e46238d34ce5b9be1e21 8334229: Optimize InterpreterOopMap layout Reviewed-by: coleenp, dholmes ! src/hotspot/share/interpreter/oopMapCache.hpp Changeset: d51141e5 Author: Eirik Bj?rsn?s Committer: Jaikiran Pai Date: 2024-07-03 04:36:32 +0000 URL: https://git.openjdk.org/loom/commit/d51141e5fc84f9f933e78d0eb25af86e41798ad5 8321274: Rename ZipEntry.extraAttributes to ZipEntry.externalFileAttributes Reviewed-by: lancea, jpai ! src/java.base/share/classes/java/util/zip/ZipEntry.java ! src/java.base/share/classes/java/util/zip/ZipFile.java ! src/java.base/share/classes/java/util/zip/ZipOutputStream.java ! src/java.base/share/classes/jdk/internal/access/JavaUtilZipFileAccess.java ! src/jdk.jartool/share/classes/jdk/security/jarsigner/JarSigner.java ! src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java ! src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java ! src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources_de.java ! src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources_ja.java ! src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources_zh_CN.java ! src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java ! test/jdk/sun/security/tools/jarsigner/SymLinkTest.java Changeset: 0db9bc57 Author: Chen Liang Date: 2024-07-03 05:03:56 +0000 URL: https://git.openjdk.org/loom/commit/0db9bc57de07f8f1d0bf657621cb1b8fd7b01211 8335290: Rename ClassFile::transform to ClassFile::transformClass Reviewed-by: asotona ! src/java.base/share/classes/java/lang/Module.java ! src/java.base/share/classes/java/lang/classfile/ClassFile.java ! src/java.base/share/classes/java/lang/classfile/ClassFileTransform.java ! src/java.base/share/classes/java/lang/classfile/components/ClassRemapper.java ! src/java.base/share/classes/java/lang/classfile/components/snippet-files/PackageSnippets.java ! src/java.base/share/classes/java/lang/classfile/snippet-files/PackageSnippets.java ! src/java.base/share/classes/jdk/internal/classfile/impl/ClassFileImpl.java ! src/java.base/share/classes/jdk/internal/module/ModuleInfoExtender.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/StripJavaDebugAttributesPlugin.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/VersionPropsPlugin.java ! src/jdk.jshell/share/classes/jdk/jshell/execution/LocalExecutionControl.java ! test/jdk/java/io/Serializable/records/BadCanonicalCtrTest.java ! test/jdk/java/io/Serializable/records/ProhibitedMethods.java ! test/jdk/java/io/Serializable/records/SerialPersistentFieldsTest.java ! test/jdk/java/lang/ModuleTests/AnnotationsTest.java ! test/jdk/java/lang/instrument/asmlib/Instrumentor.java ! test/jdk/java/lang/invoke/8022701/BogoLoader.java ! test/jdk/java/lang/invoke/accessProtectedSuper/BogoLoader.java ! test/jdk/jdk/classfile/AdaptCodeTest.java ! test/jdk/jdk/classfile/AdvancedTransformationsTest.java ! test/jdk/jdk/classfile/BSMTest.java ! test/jdk/jdk/classfile/ClassBuildingTest.java ! test/jdk/jdk/classfile/ClassHierarchyInfoTest.java ! test/jdk/jdk/classfile/CorpusTest.java ! test/jdk/jdk/classfile/DiscontinuedInstructionsTest.java ! test/jdk/jdk/classfile/LvtTest.java ! test/jdk/jdk/classfile/MassAdaptCopyCodeTest.java ! test/jdk/jdk/classfile/MassAdaptCopyPrimitiveMatchCodeTest.java ! test/jdk/jdk/classfile/OptionsTest.java ! test/jdk/jdk/classfile/ShortJumpsFixTest.java ! test/jdk/jdk/classfile/StackMapsTest.java ! test/jdk/jdk/classfile/TestRecordComponent.java ! test/jdk/jdk/classfile/TransformTests.java ! test/jdk/jdk/classfile/VerifierSelfTest.java ! test/jdk/jdk/classfile/examples/AnnotationsExamples.java ! test/jdk/jdk/classfile/examples/ExampleGallery.java ! test/jdk/jdk/classfile/examples/ExperimentalTransformExamples.java ! test/jdk/jdk/classfile/examples/TransformExamples.java ! test/jdk/jdk/classfile/helpers/Transforms.java ! test/jdk/jdk/jfr/event/io/TestInstrumentation.java ! test/jdk/jdk/jfr/javaagent/TestEventInstrumentation.java ! test/jdk/jdk/lambda/separate/ClassToInterfaceConverter.java ! test/langtools/tools/javac/MethodParametersTest.java ! test/langtools/tools/javac/classreader/8171132/BadConstantValue.java ! test/langtools/tools/javac/classreader/BadMethodParameter.java ! test/langtools/tools/javac/defaultMethods/BadClassfile.java ! test/langtools/tools/javac/launcher/SourceLauncherTest.java ! test/langtools/tools/javac/modules/IncubatingTest.java ! test/langtools/tools/javac/modules/JavaBaseTest.java ! test/langtools/tools/javac/modules/OpenModulesTest.java ! test/langtools/tools/javac/platform/createsymbols/CreateSymbolsTestImpl.java ! test/langtools/tools/javac/processing/model/element/TestOrigin.java ! test/langtools/tools/javap/UndefinedAccessFlagTest.java ! test/micro/org/openjdk/bench/jdk/classfile/AdHocAdapt.java ! test/micro/org/openjdk/bench/jdk/classfile/ClassfileBenchmark.java ! test/micro/org/openjdk/bench/jdk/classfile/ParseOptions.java ! test/micro/org/openjdk/bench/jdk/classfile/RebuildMethodBodies.java ! test/micro/org/openjdk/bench/jdk/classfile/Transforms.java Changeset: 7bc8f9c1 Author: Kim Barrett Date: 2024-07-03 05:55:28 +0000 URL: https://git.openjdk.org/loom/commit/7bc8f9c150cbf457edf6144adba734ecd5ca5a0f 8335589: Fix -Wzero-as-null-pointer-constant warnings in IdealLoopTree ctor Reviewed-by: thartmann ! src/hotspot/share/opto/loopnode.hpp Changeset: f3f90dc1 Author: Kim Barrett Date: 2024-07-03 05:57:49 +0000 URL: https://git.openjdk.org/loom/commit/f3f90dc11a5cbc146a5ef8a73eadf4168373838d 8335592: Fix -Wzero-as-null-pointer-constant warnings in RootNode ctor Reviewed-by: thartmann ! src/hotspot/share/opto/rootnode.hpp Changeset: 77a7078b Author: Kim Barrett Date: 2024-07-03 06:00:20 +0000 URL: https://git.openjdk.org/loom/commit/77a7078b82fd0cb3cfa13685072f04fdef33758b 8335593: Fix -Wzero-as-null-pointer-constant warning in Type_Array ctor Reviewed-by: thartmann ! src/hotspot/share/opto/phaseX.hpp Changeset: 4d2f7376 Author: Gerg? Barany Committer: Doug Simon Date: 2024-07-03 08:08:22 +0000 URL: https://git.openjdk.org/loom/commit/4d2f73764bcd5ff62fbdb9d406d4180ae09613ff 8335357: Delete HotSpotJDKReflection.oopSizeOffset Reviewed-by: dnsimon ! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotJDKReflection.java Changeset: 6c84e9c8 Author: Albert Mingkun Yang Date: 2024-07-03 08:42:43 +0000 URL: https://git.openjdk.org/loom/commit/6c84e9c8cb71aac103901c0d92fe6ae51aabff15 8335544: Serial: Remove unused _should_allocate_from_space Reviewed-by: iwalulya ! src/hotspot/share/gc/serial/defNewGeneration.cpp ! src/hotspot/share/gc/serial/defNewGeneration.hpp Changeset: c06b75ff Author: Kim Barrett Date: 2024-07-03 11:12:08 +0000 URL: https://git.openjdk.org/loom/commit/c06b75ff88babf57bdcd0919ea177ff363fd858b 8335591: Fix -Wzero-as-null-pointer-constant warnings in ConcurrentHashTable Reviewed-by: chagedorn ! src/hotspot/share/utilities/concurrentHashTable.inline.hpp Changeset: 350f9c19 Author: Erik Gahlin Date: 2024-07-03 11:36:14 +0000 URL: https://git.openjdk.org/loom/commit/350f9c1947b0eab3ee233516ceefca1e25de9583 8322812: Manpage for jcmd is missing JFR.view command Reviewed-by: kevinw, mgronlun ! src/jdk.jcmd/share/man/jcmd.1 Changeset: 6db4c6a7 Author: Qizheng Xing Committer: Tobias Hartmann Date: 2024-07-03 12:12:00 +0000 URL: https://git.openjdk.org/loom/commit/6db4c6a772df856fc3099c32a5b2c102a30d360c 8335536: Fix assertion failure in IdealGraphPrinter when append is true Reviewed-by: thartmann, chagedorn, tholenstein ! src/hotspot/share/opto/idealGraphPrinter.cpp ! src/hotspot/share/opto/idealGraphPrinter.hpp Changeset: 5866b16d Author: Feilong Jiang Date: 2024-07-03 12:12:12 +0000 URL: https://git.openjdk.org/loom/commit/5866b16dbca3f63770c8792d204dabdf49b59839 8335411: RISC-V: Optimize encode_heap_oop when oop is not null Reviewed-by: fyang, rehn ! src/hotspot/cpu/riscv/macroAssembler_riscv.cpp ! src/hotspot/cpu/riscv/macroAssembler_riscv.hpp ! src/hotspot/cpu/riscv/riscv.ad Changeset: 6923a511 Author: Albert Mingkun Yang Date: 2024-07-03 12:57:26 +0000 URL: https://git.openjdk.org/loom/commit/6923a5114b2a9f02f0d6f0fefc21141ac3b9322a 8335607: Serial: Remove unused collection_attempt_is_safe Reviewed-by: tschatzl ! src/hotspot/share/gc/serial/defNewGeneration.cpp ! src/hotspot/share/gc/serial/defNewGeneration.hpp Changeset: 5a8af2b8 Author: Arseny Bochkarev Committer: Vladimir Kempik Date: 2024-07-03 14:09:59 +0000 URL: https://git.openjdk.org/loom/commit/5a8af2b8b93672de9b3a3e73e6984506980da932 8335615: Clean up left-overs from 8317721 Reviewed-by: fyang ! src/hotspot/cpu/riscv/macroAssembler_riscv.cpp Changeset: cf4f2b53 Author: Ivan Walulya Date: 2024-07-03 15:12:40 +0000 URL: https://git.openjdk.org/loom/commit/cf4f2b53d6174a808f8b45f0bb848efd5bd91c3c 8332517: G1: Refactor G1AllocRegion Reviewed-by: tschatzl, ayang ! src/hotspot/share/gc/g1/g1AllocRegion.cpp ! src/hotspot/share/gc/g1/g1AllocRegion.hpp ! src/hotspot/share/gc/g1/g1AllocRegion.inline.hpp ! src/hotspot/share/gc/g1/g1Allocator.cpp ! src/hotspot/share/gc/g1/g1HeapRegion.hpp ! src/hotspot/share/gc/g1/g1HeapRegion.inline.hpp Changeset: 19a8a2ba Author: Albert Mingkun Yang Date: 2024-07-03 15:42:47 +0000 URL: https://git.openjdk.org/loom/commit/19a8a2baa9e749c7527ff526b2794826f0cdebb3 8335618: Serial: Remove unused definitions in SerialHeap Reviewed-by: iwalulya ! src/hotspot/share/gc/serial/defNewGeneration.hpp ! src/hotspot/share/gc/serial/serialHeap.hpp Changeset: 8aaec37a Author: Thomas Stuefe Date: 2024-07-03 16:08:34 +0000 URL: https://git.openjdk.org/loom/commit/8aaec37ace102b55ee1387cfd1967ec3ab662083 8322475: Extend printing for System.map Reviewed-by: sgehwolf, jsjolen ! src/hotspot/os/linux/memMapPrinter_linux.cpp + src/hotspot/os/linux/procMapsParser.cpp + src/hotspot/os/linux/procMapsParser.hpp ! src/hotspot/share/nmt/memMapPrinter.cpp ! src/hotspot/share/nmt/memMapPrinter.hpp ! src/hotspot/share/runtime/java.cpp ! src/hotspot/share/services/attachListener.cpp ! src/hotspot/share/services/diagnosticCommand.cpp ! src/hotspot/share/services/diagnosticCommand.hpp ! src/hotspot/share/utilities/ostream.cpp ! src/hotspot/share/utilities/ostream.hpp ! test/hotspot/jtreg/serviceability/dcmd/vm/SystemDumpMapTest.java ! test/hotspot/jtreg/serviceability/dcmd/vm/SystemMapTest.java + test/hotspot/jtreg/serviceability/dcmd/vm/SystemMapTestBase.java Changeset: 13b782c3 Author: Hamlin Li Date: 2024-07-03 16:10:22 +0000 URL: https://git.openjdk.org/loom/commit/13b782c3de9a470a7cf1db9d5111ce19faf28729 8334554: RISC-V: verify & fix perf of string comparison Reviewed-by: rehn, luhenry, fyang ! src/hotspot/cpu/riscv/c2_MacroAssembler_riscv.cpp ! src/hotspot/cpu/riscv/c2_MacroAssembler_riscv.hpp ! src/hotspot/cpu/riscv/riscv_v.ad Changeset: 9a91865f Author: Thomas Schatzl Date: 2024-07-03 16:29:52 +0000 URL: https://git.openjdk.org/loom/commit/9a91865ff38f6fbb48b9aba5028e0b529d9bce76 8335395: G1: Verification does not detect references into Free regions Reviewed-by: ayang, iwalulya ! src/hotspot/share/gc/g1/g1CollectedHeap.inline.hpp ! src/hotspot/share/gc/g1/g1HeapRegion.cpp From duke at openjdk.org Wed Jul 3 22:29:50 2024 From: duke at openjdk.org (duke) Date: Wed, 3 Jul 2024 22:29:50 GMT Subject: git: openjdk/loom: fibers: 108 new changesets Message-ID: <4e06775c-ec92-4456-8226-92e6be44a09a@openjdk.org> Changeset: b3bf31a0 Author: Coleen Phillimore Date: 2024-06-25 19:50:58 +0000 URL: https://git.openjdk.org/loom/commit/b3bf31a0a08da679ec2fd21613243fb17b1135a9 8333542: Breakpoint in parallel code does not work Co-authored-by: Chris Plummer Reviewed-by: dholmes, vlivanov ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/classfile/javaClasses.hpp ! src/hotspot/share/classfile/vmSymbols.hpp ! src/hotspot/share/interpreter/linkResolver.cpp ! src/hotspot/share/oops/cpCache.cpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/instanceKlass.hpp ! src/hotspot/share/runtime/sharedRuntime.cpp ! src/hotspot/share/runtime/synchronizer.cpp ! src/hotspot/share/runtime/synchronizer.hpp ! src/hotspot/share/runtime/vframe.cpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/hotspot/share/services/heapDumper.cpp ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java ! test/hotspot/jtreg/runtime/Thread/TestThreadDumpClassInitMonitor.java + test/jdk/com/sun/jdi/BreakpointOnClassPrepare.java Changeset: f101e153 Author: Volodymyr Paprotski Committer: Sandhya Viswanathan Date: 2024-06-25 22:31:39 +0000 URL: https://git.openjdk.org/loom/commit/f101e153cee68750fcf1f12da10e29806875b522 8333583: Crypto-XDH.generateSecret regression after JDK-8329538 Reviewed-by: sviswanathan, kvn, ascarpino ! make/jdk/src/classes/build/tools/intpoly/FieldGen.java ! src/hotspot/cpu/x86/stubGenerator_x86_64_poly_mont.cpp ! src/hotspot/share/classfile/vmIntrinsics.hpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/opto/runtime.cpp ! src/java.base/share/classes/sun/security/util/math/intpoly/IntegerPolynomial.java ! src/java.base/share/classes/sun/security/util/math/intpoly/IntegerPolynomial1305.java ! src/java.base/share/classes/sun/security/util/math/intpoly/IntegerPolynomialModBinP.java ! src/java.base/share/classes/sun/security/util/math/intpoly/MontgomeryIntegerPolynomialP256.java Changeset: c66f785f Author: Gui Cao Committer: Fei Yang Date: 2024-06-26 00:59:49 +0000 URL: https://git.openjdk.org/loom/commit/c66f785fb685d5c378fb4c4cdebdef29c01d321b 8334505: RISC-V: Several tests fail when MaxVectorSize does not match VM_Version::_initial_vector_length Reviewed-by: fyang ! src/hotspot/cpu/riscv/vm_version_riscv.cpp Changeset: 25c3845b Author: Kim Barrett Date: 2024-06-26 05:15:36 +0000 URL: https://git.openjdk.org/loom/commit/25c3845be270462388ee5e7330cc7315e5c738df 8333133: Simplify QuickSort::sort Reviewed-by: shade, dholmes ! src/hotspot/share/classfile/moduleEntry.cpp ! src/hotspot/share/classfile/packageEntry.cpp ! src/hotspot/share/compiler/compilationMemoryStatistic.cpp ! src/hotspot/share/gc/g1/g1CollectionSet.cpp ! src/hotspot/share/gc/g1/g1DirtyCardQueue.cpp ! src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp ! src/hotspot/share/logging/logSelection.cpp ! src/hotspot/share/oops/method.cpp ! src/hotspot/share/utilities/quickSort.hpp ! test/hotspot/gtest/gc/shared/test_oopStorage.cpp ! test/hotspot/gtest/utilities/test_quicksort.cpp Changeset: a5f401f3 Author: Christian Hagedorn Date: 2024-06-26 07:09:50 +0000 URL: https://git.openjdk.org/loom/commit/a5f401f3a8534a64cf3c27c2ef67f17860de6d6b 8334650: Add debug information about whether an Assertion Predicate is for the init or last value Reviewed-by: roland, kvn ! src/hotspot/share/opto/cfgnode.hpp ! src/hotspot/share/opto/ifnode.cpp ! src/hotspot/share/opto/loopPredicate.cpp ! src/hotspot/share/opto/loopTransform.cpp ! src/hotspot/share/opto/loopnode.hpp ! src/hotspot/share/opto/predicates.hpp Changeset: b88af942 Author: Albert Mingkun Yang Date: 2024-06-26 07:40:35 +0000 URL: https://git.openjdk.org/loom/commit/b88af94269640a160fbacf25618f3a00756464aa 8269870: PS: Membar in PSPromotionManager::copy_unmarked_to_survivor_space could be relaxed Co-authored-by: Hamlin Li Reviewed-by: mli, kbarrett, tschatzl ! src/hotspot/share/gc/parallel/psPromotionManager.inline.hpp Changeset: e1390056 Author: Thomas Stuefe Date: 2024-06-26 08:44:17 +0000 URL: https://git.openjdk.org/loom/commit/e1390056c9dbf0a02a131864ebee23435e997852 8333994: NMT: call stacks should show source information Reviewed-by: jsjolen, gziemski ! src/hotspot/share/nmt/memReporter.cpp ! src/hotspot/share/nmt/memReporter.hpp + src/hotspot/share/nmt/nativeCallStackPrinter.cpp + src/hotspot/share/nmt/nativeCallStackPrinter.hpp ! src/hotspot/share/nmt/virtualMemoryTracker.cpp ! src/hotspot/share/utilities/nativeCallStack.cpp ! src/hotspot/share/utilities/nativeCallStack.hpp ! test/hotspot/jtreg/runtime/NMT/CheckForProperDetailStackTrace.java Changeset: 7f6804ce Author: Adam Sotona Date: 2024-06-26 09:09:13 +0000 URL: https://git.openjdk.org/loom/commit/7f6804ceb63568d72e825d45b02d08f314c9b0fc 8334872: BigEndian: java/lang/invoke/condy Tests failing since JDK-8294960 Reviewed-by: redestad ! src/java.base/share/classes/java/lang/invoke/ClassSpecializer.java Changeset: 4ce8822b Author: Maurizio Cimadamore Date: 2024-06-26 09:12:02 +0000 URL: https://git.openjdk.org/loom/commit/4ce8822b6c53b8bd72713f1bfaf6673b91aabea4 8334037: Local class creation in lambda in pre-construction context crashes javac 8333313: NullPointerException in lambda instantiating an inner local class in prologue 8333766: Stack overflow with anonymous class in super() parameter 8334679: Wrong bug number in regression test for JDK-8334252 Co-authored-by: Archie Cobbs Reviewed-by: jlahoda, vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/CompileStates.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java + test/langtools/tools/javac/SuperInit/AnonSuperLambdaCrash.java + test/langtools/tools/javac/SuperInit/EarlyLocalTest1.java + test/langtools/tools/javac/SuperInit/EarlyLocalTest4.java + test/langtools/tools/javac/SuperInit/EarlyLocalTest5.java + test/langtools/tools/javac/SuperInit/EarlyLocalTest6.java + test/langtools/tools/javac/SuperInit/EarlyLocalTest7.java + test/langtools/tools/javac/SuperInit/LambdaLocalEarlyCrash.java ! test/langtools/tools/javac/SuperInit/LambdaOuterCapture.java ! test/langtools/tools/javac/lambda/T8129740/Universe.java.out Changeset: 741a0f39 Author: Hannes Walln?fer Date: 2024-06-26 09:37:22 +0000 URL: https://git.openjdk.org/loom/commit/741a0f39dd1fffc1caaa8d69bfe3662dad830452 8334241: Adjust API docs side bar dimensions Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/stylesheet.css Changeset: f23295ec Author: Daniel Fuchs Date: 2024-06-26 10:09:05 +0000 URL: https://git.openjdk.org/loom/commit/f23295ec1dde58d239a2625c9b1645534a2bb625 8334600: TEST java/net/MulticastSocket/IPMulticastIF.java fails on linux-aarch64 Reviewed-by: alanb ! test/jdk/java/net/MulticastSocket/IPMulticastIF.java Changeset: b2ac7259 Author: Kangcheng Xu Committer: Roland Westrelin Date: 2024-06-26 13:19:34 +0000 URL: https://git.openjdk.org/loom/commit/b2ac7259c96f154ba0ca54fd47b37caaa8c8647b 8327380: Add tests for Shenandoah barrier expansion optimization Reviewed-by: roland, shade + test/hotspot/jtreg/compiler/gcbarriers/TestShenandoahBarrierExpansion.java Changeset: efb905e5 Author: Matthias Baesken Date: 2024-06-26 13:37:58 +0000 URL: https://git.openjdk.org/loom/commit/efb905e57ab7a5299952419fa9961316541056c2 8334618: ubsan: support setting additional ubsan check options Reviewed-by: stuefe, lucy ! make/autoconf/jdk-options.m4 Changeset: 4ffc5e60 Author: Anthony Scarpino Date: 2024-06-26 13:58:22 +0000 URL: https://git.openjdk.org/loom/commit/4ffc5e60776353b03e9a557c39148e378b1690e2 8326705: Test CertMsgCheck.java fails to find alert certificate_required Reviewed-by: ssahoo, rhalade ! test/jdk/ProblemList.txt ! test/jdk/javax/net/ssl/SSLSession/CertMsgCheck.java ! test/jdk/javax/net/ssl/templates/TLSBase.java Changeset: 8374d165 Author: Emanuel Peter Date: 2024-06-26 14:12:44 +0000 URL: https://git.openjdk.org/loom/commit/8374d16504503c7441346c99045736b7ac72233f 8335006: C2 SuperWord: add JMH benchmark VectorLoadToStoreForwarding.java Reviewed-by: shade, kvn, sviswanathan + test/micro/org/openjdk/bench/vm/compiler/VectorLoadToStoreForwarding.java Changeset: 8591eff7 Author: Nizar Benalla Committer: Alexey Ivanov Date: 2024-06-26 14:39:21 +0000 URL: https://git.openjdk.org/loom/commit/8591eff78dbc9770b8d0a16e05040ac35c99881a 8332103: since-checker - Add missing @ since tags to java.desktop Reviewed-by: tr, aivanov ! src/java.desktop/share/classes/java/awt/geom/Path2D.java ! src/java.desktop/share/classes/java/beans/package-info.java ! src/java.desktop/share/classes/javax/swing/DefaultComboBoxModel.java ! src/java.desktop/share/classes/javax/swing/DefaultListModel.java ! src/java.desktop/share/classes/javax/swing/JSlider.java ! src/java.desktop/share/classes/javax/swing/package-info.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicSliderUI.java ! src/java.desktop/share/classes/javax/swing/plaf/synth/package-info.java ! src/java.desktop/share/classes/javax/swing/text/DefaultEditorKit.java Changeset: 5883a20b Author: Claes Redestad Date: 2024-06-26 14:46:17 +0000 URL: https://git.openjdk.org/loom/commit/5883a20b822bb8acb719076e4f7abee8403061cb 8334437: De-duplicate ProxyMethod list creation Reviewed-by: asotona, liach ! src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java Changeset: b5d58962 Author: Sonia Zaldana Calles Committer: Julian Waters Date: 2024-06-26 16:20:15 +0000 URL: https://git.openjdk.org/loom/commit/b5d589623c174757e946011495f771718318f1cc 8335108: Build error after JDK-8333658 due to class templates Reviewed-by: jwaters, jsjolen ! src/hotspot/share/nmt/arrayWithFreeList.hpp Changeset: bffc8484 Author: Justin Lu Date: 2024-06-26 17:10:09 +0000 URL: https://git.openjdk.org/loom/commit/bffc8484c32ad6c3205f7cebe4e262a2dc9de57e 8333755: NumberFormat integer only parsing breaks when format has suffix Reviewed-by: naoto ! src/java.base/share/classes/java/text/CompactNumberFormat.java ! src/java.base/share/classes/java/text/DecimalFormat.java ! src/java.base/share/classes/java/text/NumberFormat.java ! test/jdk/java/text/Format/NumberFormat/BigDecimalParse.java ! test/jdk/java/text/Format/NumberFormat/StrictParseTest.java Changeset: 817edcb6 Author: Xiaolong Peng Committer: Aleksey Shipilev Date: 2024-06-26 19:25:37 +0000 URL: https://git.openjdk.org/loom/commit/817edcb697cbb8c608c9292cdc4b99db4f5844dc 8331411: Shenandoah: Reconsider spinning duration in ShenandoahLock Reviewed-by: shade, kdnilsen, wkemper ! src/hotspot/share/gc/shenandoah/shenandoahLock.cpp ! src/hotspot/share/gc/shenandoah/shenandoahLock.hpp Changeset: 4ebb7712 Author: Zhengyu Gu Date: 2024-06-26 20:24:29 +0000 URL: https://git.openjdk.org/loom/commit/4ebb77120af5a4ccbfde63b24cb50e05a3161f16 8334769: Shenandoah: Move CodeCache_lock close to its use in ShenandoahConcurrentNMethodIterator Reviewed-by: shade, wkemper, kdnilsen ! src/hotspot/share/gc/shenandoah/shenandoahCodeRoots.cpp ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp ! src/hotspot/share/gc/shenandoah/shenandoahNMethod.cpp Changeset: 07bc523d Author: Anthony Scarpino Date: 2024-06-26 22:28:33 +0000 URL: https://git.openjdk.org/loom/commit/07bc523df85fde81bf736fedac62874d3cb11ee3 8334670: SSLSocketOutputRecord buffer miscalculation Reviewed-by: djelinski, ssahoo ! src/java.base/share/classes/sun/security/ssl/SSLSocketOutputRecord.java Changeset: 3796fdfc Author: Hannes Greule Committer: Chen Liang Date: 2024-06-26 23:17:32 +0000 URL: https://git.openjdk.org/loom/commit/3796fdfcedc2b2202b72cca062218f840960414c 8328536: javac - crash on unknown type referenced in yield statement Co-authored-by: Jan Lahoda Reviewed-by: jlahoda ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! test/langtools/jdk/jshell/ToolSimpleTest.java ! test/langtools/tools/javac/generics/diamond/7188968/T7188968.out ! test/langtools/tools/javac/lambda/MethodReference23.out ! test/langtools/tools/javac/lambda/methodReference/MethodRefToInnerWithoutOuter.out ! test/langtools/tools/javac/recovery/AttrRecovery.java Changeset: 6682305e Author: Vladimir Kozlov Date: 2024-06-27 03:34:04 +0000 URL: https://git.openjdk.org/loom/commit/6682305ee21cf595ec953d95bea594734a2982a8 8334779: Test compiler/c1/CanonicalizeArrayLength.java is timing out Reviewed-by: thartmann, dlong ! src/hotspot/cpu/x86/macroAssembler_x86.cpp Changeset: 9bb675f8 Author: Jaikiran Pai Date: 2024-06-27 04:38:32 +0000 URL: https://git.openjdk.org/loom/commit/9bb675f89dd1eeec423ca96cb3f96d29f5de477c 8334719: (se) Deferred close of SelectableChannel may result in a Selector doing the final close before concurrent I/O on channel has completed Co-authored-by: Alan Bateman Reviewed-by: alanb, dfuchs ! src/java.base/share/classes/sun/nio/ch/DatagramChannelImpl.java ! src/java.base/share/classes/sun/nio/ch/ServerSocketChannelImpl.java ! src/java.base/share/classes/sun/nio/ch/SocketChannelImpl.java ! src/java.base/unix/classes/sun/nio/ch/SinkChannelImpl.java ! src/java.base/unix/classes/sun/nio/ch/SourceChannelImpl.java + test/jdk/java/nio/channels/Selector/DeferredClose/DeferredCloseTest.java + test/jdk/java/nio/channels/Selector/DeferredClose/java.base/java/net/InetSocketAddress.java Changeset: 9d20b58f Author: Shaojin Wen Committer: Chen Liang Date: 2024-06-27 05:13:30 +0000 URL: https://git.openjdk.org/loom/commit/9d20b58f40275002afa0348d94d5592a26894e88 8334328: Reduce object allocation for FloatToDecimal and DoubleToDecimal Reviewed-by: redestad, rgiulietti ! src/java.base/share/classes/java/lang/AbstractStringBuilder.java ! src/java.base/share/classes/jdk/internal/math/DoubleToDecimal.java ! src/java.base/share/classes/jdk/internal/math/FloatToDecimal.java + src/java.base/share/classes/jdk/internal/math/ToDecimal.java ! test/micro/org/openjdk/bench/java/lang/StringBuilders.java Changeset: 0fc5b271 Author: Nizar Benalla Committer: Jan Lahoda Date: 2024-06-27 06:22:17 +0000 URL: https://git.openjdk.org/loom/commit/0fc5b2711fbdde972c40bfef2977dd9d70e09581 8332014: since-checker - Fix @ since tags in jdk.jshell Reviewed-by: jlahoda ! src/jdk.jshell/share/classes/jdk/jshell/Snippet.java ! src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysis.java ! src/jdk.jshell/share/classes/jdk/jshell/tool/JavaShellToolBuilder.java Changeset: 46b817b7 Author: Matthias Baesken Date: 2024-06-27 06:53:03 +0000 URL: https://git.openjdk.org/loom/commit/46b817b7499e74ba8812d38bcce93147ebf93b25 8333363: ubsan: instanceKlass.cpp: runtime error: member call on null pointer of type 'struct AnnotationArray' Reviewed-by: coleenp, stefank ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/metadata.hpp Changeset: f3b69da5 Author: Evemose <124714317+Evemose at users.noreply.github.com> Committer: Jan Lahoda Date: 2024-06-27 07:45:18 +0000 URL: https://git.openjdk.org/loom/commit/f3b69da55a1ec4857fff1537a80ab1fefee93dac 8335136: Underscore as parameter name in one-parameter functional types fails to compile Reviewed-by: jlahoda ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java + test/langtools/tools/javac/switchexpr/ExpressionSwitchUnderscoreAfterYield.java Changeset: 37e7698c Author: Kevin Walls Date: 2024-06-27 07:54:35 +0000 URL: https://git.openjdk.org/loom/commit/37e7698c29b8673b904945d397f0698ccd16d27b 8335154: jcmd VM.classes -verbose=false does not set verbose to false Reviewed-by: dholmes, stuefe ! src/hotspot/share/services/diagnosticCommand.cpp Changeset: 79a23017 Author: Albert Mingkun Yang Date: 2024-06-27 10:23:55 +0000 URL: https://git.openjdk.org/loom/commit/79a23017fc7154738c375fbb12a997525c3bf9e7 8322859: Parallel: Move transform_stack_chunk Reviewed-by: stefank, tschatzl ! src/hotspot/share/gc/parallel/psPromotionManager.inline.hpp Changeset: 50dd962b Author: Thomas Stuefe Date: 2024-06-27 12:56:26 +0000 URL: https://git.openjdk.org/loom/commit/50dd962b0d0fe36634d96dbbd9d94fbc34d9ff7f 8335007: Inline OopMapCache table Reviewed-by: stefank, coleenp, shade ! src/hotspot/share/interpreter/oopMapCache.cpp ! src/hotspot/share/interpreter/oopMapCache.hpp Changeset: 6b961acb Author: Albert Mingkun Yang Date: 2024-06-27 13:03:21 +0000 URL: https://git.openjdk.org/loom/commit/6b961acb87c29027f2158c6b7a764f1276a0bf52 8333786: Serial: Remove SerialHeap::_incremental_collection_failed Reviewed-by: tschatzl, iwalulya ! src/hotspot/share/gc/serial/defNewGeneration.cpp ! src/hotspot/share/gc/serial/defNewGeneration.hpp ! src/hotspot/share/gc/serial/serialHeap.cpp ! src/hotspot/share/gc/serial/serialHeap.hpp Changeset: d5375c7d Author: Sonia Zaldana Calles Committer: Thomas Stuefe Date: 2024-06-27 13:22:04 +0000 URL: https://git.openjdk.org/loom/commit/d5375c7db658de491c1f5bad053040d21b82941e 8333308: javap --system handling doesn't work on internal class names Reviewed-by: liach, stuefe ! src/jdk.jdeps/share/classes/com/sun/tools/javap/JavapTask.java Changeset: 5909d541 Author: Axel Boldt-Christmas Date: 2024-06-27 14:21:34 +0000 URL: https://git.openjdk.org/loom/commit/5909d54147355dd7da5786ff39ead4c15816705c 8326820: Metadata artificially kept alive Reviewed-by: eosterlund, stefank, coleenp ! src/hotspot/share/classfile/classLoaderDataGraph.cpp ! src/hotspot/share/classfile/classLoaderDataGraph.hpp ! src/hotspot/share/classfile/classLoaderStats.cpp ! src/hotspot/share/classfile/systemDictionary.hpp ! src/hotspot/share/prims/jvmtiEnvBase.cpp ! src/hotspot/share/prims/jvmtiGetLoadedClasses.cpp Changeset: 4ab7e98c Author: Francisco Ferrari Bihurriet Committer: Martin Balao Date: 2024-06-27 15:07:00 +0000 URL: https://git.openjdk.org/loom/commit/4ab7e98c79a1a0b7aba1ca74a8316820c906e70e 8330842: Support AES CBC with Ciphertext Stealing (CTS) in SunPKCS11 Co-authored-by: Francisco Ferrari Bihurriet Co-authored-by: Martin Balao Reviewed-by: valeriep ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/Config.java ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/Token.java + test/jdk/sun/security/pkcs11/Cipher/TestCipherTextStealingMultipart.java ! test/jdk/sun/security/pkcs11/Cipher/TestSymmCiphers.java ! test/jdk/sun/security/pkcs11/Cipher/TestSymmCiphersNoPad.java Changeset: b6ffb442 Author: Daniel Jeli?ski Date: 2024-06-27 15:14:36 +0000 URL: https://git.openjdk.org/loom/commit/b6ffb442acb4a222f017868433eff213d9b84ed8 8335135: HttpURLConnection#HttpInputStream does not throw IOException when response is truncated Reviewed-by: dfuchs ! src/java.base/share/classes/sun/net/www/MeteredStream.java ! test/jdk/java/net/Authenticator/BasicTest4.java + test/jdk/java/net/URLConnection/TruncatedFixedResponse.java ! test/jdk/sun/net/www/http/KeepAliveStream/KeepAliveStreamCloseWithWrongContentLength.java Changeset: 0e6b0cba Author: Erik Gahlin Date: 2024-06-27 15:38:06 +0000 URL: https://git.openjdk.org/loom/commit/0e6b0cbaaa0d5272f60ee4fe09cf5e247e68c2a8 8334886: jdk/jfr/api/recording/time/TestTimeMultiple.java failed with RuntimeException: getStopTime() > afterStop Reviewed-by: mgronlun ! src/hotspot/share/jfr/recorder/repository/jfrChunk.cpp ! src/jdk.jfr/share/classes/jdk/jfr/internal/JVMSupport.java Changeset: 9d986a01 Author: Vladimir Kozlov Date: 2024-06-27 16:06:35 +0000 URL: https://git.openjdk.org/loom/commit/9d986a013d01a5bcc0942bcc490258038291c22c 8335220: C2: Missing check for Opaque4 node in EscapeAnalysis Reviewed-by: chagedorn, cslucas ! src/hotspot/share/opto/escape.cpp Changeset: 243bae7d Author: Vladimir Ivanov Date: 2024-06-27 18:25:16 +0000 URL: https://git.openjdk.org/loom/commit/243bae7dc0c3e71c02ffed9e1ee7d436af11d3b9 8304693: Remove -XX:-UseVtableBasedCHA Reviewed-by: kvn, coleenp, dholmes ! src/hotspot/share/ci/ciMethod.cpp ! src/hotspot/share/code/dependencies.cpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/instanceKlass.hpp ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/globals.hpp ! test/hotspot/jtreg/compiler/cha/AbstractRootMethod.java ! test/hotspot/jtreg/compiler/cha/DefaultRootMethod.java ! test/hotspot/jtreg/compiler/cha/StrengthReduceInterfaceCall.java - test/hotspot/jtreg/runtime/InvocationTests/invocationOldCHATests.java ! test/jtreg-ext/requires/VMProps.java Changeset: c35e58a5 Author: Ioi Lam Date: 2024-06-27 20:10:13 +0000 URL: https://git.openjdk.org/loom/commit/c35e58a5adf06e25a3b482e2be384af95a84f11a 8309634: Resolve CONSTANT_MethodRef at CDS dump time Reviewed-by: matsaave, ccheung ! src/hotspot/share/cds/classListParser.cpp ! src/hotspot/share/cds/classListWriter.cpp ! src/hotspot/share/cds/classPrelinker.cpp ! src/hotspot/share/cds/dumpAllocStats.cpp ! src/hotspot/share/cds/dumpAllocStats.hpp ! src/hotspot/share/interpreter/interpreterRuntime.cpp ! src/hotspot/share/interpreter/interpreterRuntime.hpp ! src/hotspot/share/interpreter/linkResolver.cpp ! src/hotspot/share/interpreter/linkResolver.hpp ! src/hotspot/share/oops/cpCache.cpp ! src/hotspot/share/oops/cpCache.hpp ! src/hotspot/share/oops/resolvedMethodEntry.hpp ! test/hotspot/jtreg/runtime/cds/appcds/resolvedConstants/ResolvedConstants.java Changeset: 3b1ca986 Author: Vladimir Petko Committer: Erik Joelsson Date: 2024-06-27 20:27:51 +0000 URL: https://git.openjdk.org/loom/commit/3b1ca986427d3a69c9e167b9b4c07d1b83bc264d 8334895: OpenJDK fails to configure on linux aarch64 when CDS is disabled after JDK-8331942 Reviewed-by: erikj ! make/autoconf/jdk-options.m4 Changeset: 4e8cbf88 Author: Chris Plummer Date: 2024-06-27 22:20:14 +0000 URL: https://git.openjdk.org/loom/commit/4e8cbf884ab1eee9c3110712ab62edc706e948ba 8335134: Test com/sun/jdi/BreakpointOnClassPrepare.java timeout Reviewed-by: kevinw, coleenp ! test/jdk/com/sun/jdi/BreakpointOnClassPrepare.java Changeset: cd46c87d Author: Gui Cao Committer: Fei Yang Date: 2024-06-28 01:44:14 +0000 URL: https://git.openjdk.org/loom/commit/cd46c87dc916b2b74067accf80c62df1792f74cf 8334843: RISC-V: Fix wraparound checking for r_array_index in lookup_secondary_supers_table_slow_path Reviewed-by: fyang ! src/hotspot/cpu/riscv/macroAssembler_riscv.cpp Changeset: b4df380f Author: Jan Kratochvil Committer: Kim Barrett Date: 2024-06-28 03:07:09 +0000 URL: https://git.openjdk.org/loom/commit/b4df380f1a4587247a843fe28ae041265f7cfc29 8334763: --enable-asan: assert(_thread->is_in_live_stack((address)this)) failed: not on stack? Reviewed-by: kbarrett, stuefe, erikj ! make/autoconf/jdk-options.m4 Changeset: 308a8123 Author: Evgeny Nikitin Committer: Leonid Mesnik Date: 2024-06-28 04:42:33 +0000 URL: https://git.openjdk.org/loom/commit/308a81238362c39f5b18e2ae8444c96420ef297a 8334645: Un-problemlist vmTestbase/nsk/sysdict/vm/stress/chain/chain007/chain007.java Reviewed-by: thartmann, lmesnik ! test/hotspot/jtreg/ProblemList-generational-zgc.txt ! test/hotspot/jtreg/ProblemList-zgc.txt Changeset: c47a0e00 Author: Xiaolong Peng Committer: Y. Srinivas Ramakrishna Date: 2024-06-28 06:19:37 +0000 URL: https://git.openjdk.org/loom/commit/c47a0e005e54551e42ee1ae33d7169417a5f86d4 8334147: Shenandoah: Avoid taking lock for disabled free set logging Reviewed-by: shade, ysr ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp ! src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp ! src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp ! src/hotspot/share/gc/shenandoah/shenandoahFreeSet.hpp Changeset: d457609f Author: Amit Kumar Date: 2024-06-28 06:43:32 +0000 URL: https://git.openjdk.org/loom/commit/d457609f700bbb1fed233f1a04501c995852e5ac 8319947: Recursive lightweight locking: s390x implementation Reviewed-by: aboldtch, lucy ! src/hotspot/cpu/s390/c1_MacroAssembler_s390.cpp ! src/hotspot/cpu/s390/c2_MacroAssembler_s390.cpp ! src/hotspot/cpu/s390/c2_MacroAssembler_s390.hpp ! src/hotspot/cpu/s390/interp_masm_s390.cpp ! src/hotspot/cpu/s390/macroAssembler_s390.cpp ! src/hotspot/cpu/s390/macroAssembler_s390.hpp ! src/hotspot/cpu/s390/s390.ad ! src/hotspot/cpu/s390/sharedRuntime_s390.cpp ! src/hotspot/cpu/s390/vm_version_s390.hpp Changeset: 3b3a19e9 Author: Albert Mingkun Yang Date: 2024-06-28 08:27:07 +0000 URL: https://git.openjdk.org/loom/commit/3b3a19e907c7267f03c0b07312b929b7b4b6d200 8335314: Problem list compiler/uncommontrap/DeoptReallocFailure.java Reviewed-by: chagedorn ! test/hotspot/jtreg/ProblemList.txt Changeset: 6f4ddc2f Author: Christian Hagedorn Date: 2024-06-28 09:23:48 +0000 URL: https://git.openjdk.org/loom/commit/6f4ddc2f6bf0dd9a626a76d0f5e56a54c6cf6b65 8335142: compiler/c1/TestTraceLinearScanLevel.java occasionally times out with -Xcomp Reviewed-by: thartmann, kvn ! test/hotspot/jtreg/compiler/c1/TestTraceLinearScanLevel.java Changeset: 99d2bbf7 Author: Jan Lahoda Date: 2024-06-28 09:31:14 +0000 URL: https://git.openjdk.org/loom/commit/99d2bbf767ac33e1a021c90ba12d95ef37ea4816 8334433: jshell.exe runs an executable test.exe on startup Reviewed-by: jpai ! src/jdk.internal.le/share/classes/jdk/internal/org/jline/utils/OSUtils.java ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/ConsoleIOContext.java + test/langtools/jdk/jshell/TerminalNoExecTest.java Changeset: c798316b Author: SendaoYan Committer: Daniel Fuchs Date: 2024-06-28 09:38:18 +0000 URL: https://git.openjdk.org/loom/commit/c798316bc4cb33fd902f926030d8a0b6870d661a 8269657: Test java/nio/channels/DatagramChannel/Loopback.java failed: Unexpected message Reviewed-by: dfuchs ! test/jdk/java/nio/channels/DatagramChannel/Loopback.java Changeset: 8ec378a6 Author: Daniel Fuchs Date: 2024-06-28 11:03:29 +0000 URL: https://git.openjdk.org/loom/commit/8ec378a6c8a460dd0727df800419b3cf45d3c57a 8277949: (dc) java/nio/channels/DatagramChannel/AdaptorBasic.java failed in timeout Reviewed-by: jpai ! test/jdk/java/nio/channels/DatagramChannel/AdaptorBasic.java ! test/jdk/java/nio/channels/TestServers.java Changeset: 49eb00da Author: Daniel Fuchs Date: 2024-06-28 11:13:11 +0000 URL: https://git.openjdk.org/loom/commit/49eb00da8dc66cff3ca430f06ab21357ee6180ef 8299813: java/nio/channels/DatagramChannel/Disconnect.java fails with jtreg test timeout due to lost datagram Reviewed-by: aefimov ! test/jdk/java/nio/channels/DatagramChannel/Disconnect.java Changeset: f4d8c005 Author: Fernando Guallini Committer: Weijun Wang Date: 2024-06-28 12:45:26 +0000 URL: https://git.openjdk.org/loom/commit/f4d8c005b35ce34c96027b7f3abb7a307bca3f4c 8334562: Automate com/sun/security/auth/callback/TextCallbackHandler/Default.java test Reviewed-by: weijun ! test/jdk/ProblemList.txt ! test/jdk/TEST.groups ! test/jdk/com/sun/security/auth/callback/TextCallbackHandler/Default.java + test/jdk/java/security/testlibrary/HumanInputStream.java ! test/jdk/sun/security/tools/keytool/KeyToolTest.java Changeset: 486aa11e Author: Matthias Baesken Date: 2024-06-28 13:28:53 +0000 URL: https://git.openjdk.org/loom/commit/486aa11e74d0772ba84c2adc3c62fc1fcbf52604 8335237: ubsan: vtableStubs.hpp is_vtable_stub exclude from ubsan checks Reviewed-by: mdoerr, clanger ! src/hotspot/share/code/vtableStubs.hpp Changeset: 45c4eaa5 Author: Aleksey Shipilev Date: 2024-06-28 16:26:34 +0000 URL: https://git.openjdk.org/loom/commit/45c4eaa5600016d3da5ca769b2519df53835e4f7 8335274: SwitchBootstraps.ResolvedEnumLabels.resolvedEnum should be final Reviewed-by: liach, jlahoda ! src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java Changeset: 79a3554e Author: Kevin Walls Date: 2024-06-28 19:01:36 +0000 URL: https://git.openjdk.org/loom/commit/79a3554e1da604627b3a010dc269c1bd914c79d3 8335124: com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java failed with CPU time out of expected range Reviewed-by: phh, cjplummer ! test/jdk/com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java Changeset: 3e23e9c5 Author: Fernando Guallini Committer: Weijun Wang Date: 2024-06-28 19:17:24 +0000 URL: https://git.openjdk.org/loom/commit/3e23e9c535e0ed1d7517a836d4703c7fb3e917e4 8335344: test/jdk/sun/security/tools/keytool/NssTest.java fails to compile Reviewed-by: weijun ! test/jdk/sun/security/tools/keytool/NssTest.java Changeset: 166f9d9a Author: Vladimir Kozlov Date: 2024-06-28 19:36:00 +0000 URL: https://git.openjdk.org/loom/commit/166f9d9ac099fa971805511b32e1cae5c6c108e0 8335221: Some C2 intrinsics incorrectly assume that type argument is compile-time constant Reviewed-by: roland, chagedorn ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/opto/library_call.hpp Changeset: 5d866bf1 Author: Shaojin Wen Committer: Chen Liang Date: 2024-06-28 22:27:34 +0000 URL: https://git.openjdk.org/loom/commit/5d866bf17d96bd0f0e4545d7eee5912eda2e3a94 8335252: Reduce size of j.u.Formatter.Conversion#isValid Reviewed-by: redestad ! src/java.base/share/classes/java/util/Formatter.java Changeset: 8350b1da Author: Kim Barrett Date: 2024-06-29 05:04:47 +0000 URL: https://git.openjdk.org/loom/commit/8350b1daedae8ef5785a7165e664b1d3149b18b7 8335294: Fix simple -Wzero-as-null-pointer-constant warnings in gc code Reviewed-by: tschatzl, coleenp, jwaters ! src/hotspot/os/linux/gc/x/xPhysicalMemoryBacking_linux.cpp ! src/hotspot/os/linux/gc/z/zPhysicalMemoryBacking_linux.cpp ! src/hotspot/share/gc/parallel/parMarkBitMap.cpp ! src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp ! src/hotspot/share/gc/parallel/psParallelCompact.cpp ! src/hotspot/share/gc/z/zPage.inline.hpp ! test/hotspot/jtreg/vmTestbase/gc/gctests/nativeGC01/libnativeGC01.cpp ! test/hotspot/jtreg/vmTestbase/gc/gctests/nativeGC02/libnativeGC02.cpp ! test/hotspot/jtreg/vmTestbase/gc/gctests/nativeGC03/libnativeGC03.cpp ! test/hotspot/jtreg/vmTestbase/gc/gctests/nativeGC05/libnativeGC05.cpp Changeset: bb18498d Author: Kevin Walls Date: 2024-06-29 08:19:33 +0000 URL: https://git.openjdk.org/loom/commit/bb18498d71dddf49db9bdfac886aed9ae123651d 8335349: jcmd VM.classloaders "fold" option should be optional Reviewed-by: cjplummer, stuefe ! src/hotspot/share/classfile/classLoaderHierarchyDCmd.cpp Changeset: d9bcf061 Author: Zhengyu Gu Date: 2024-06-29 20:40:51 +0000 URL: https://git.openjdk.org/loom/commit/d9bcf061450ebfb7fe02b5a50c855db1d9178e5d 8335217: Fix memory ordering in ClassLoaderData::ChunkedHandleList Reviewed-by: dholmes, stefank, eosterlund ! src/hotspot/share/classfile/classLoaderData.cpp Changeset: 53242cdf Author: Matthias Baesken Date: 2024-07-01 06:37:09 +0000 URL: https://git.openjdk.org/loom/commit/53242cdf9ef17c502ebd541e84370e7c158639c1 8335283: Build failure due to 'no_sanitize' attribute directive ignored Reviewed-by: shade, tschatzl, kbarrett, jwaters ! src/hotspot/share/sanitizers/ub.hpp Changeset: c7e9ebb4 Author: Suchismith Roy Committer: Martin Doerr Date: 2024-07-01 08:07:42 +0000 URL: https://git.openjdk.org/loom/commit/c7e9ebb4cfff56b7a977eb2942f563f96b3336bd 8331732: [PPC64] Unify and optimize code which converts != 0 to 1 Reviewed-by: mdoerr, amitkumar ! src/hotspot/cpu/ppc/assembler_ppc.hpp ! src/hotspot/cpu/ppc/assembler_ppc.inline.hpp ! src/hotspot/cpu/ppc/macroAssembler_ppc.cpp ! src/hotspot/cpu/ppc/macroAssembler_ppc.hpp ! src/hotspot/cpu/ppc/macroAssembler_ppc.inline.hpp ! src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp ! src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp Changeset: 71e3798b Author: Albert Mingkun Yang Date: 2024-07-01 08:12:20 +0000 URL: https://git.openjdk.org/loom/commit/71e3798bf67cddef37a8b4e377c4bf21dbd01567 8335308: compiler/uncommontrap/DeoptReallocFailure.java times out with SerialGC on Windows Reviewed-by: kvn, thartmann, chagedorn ! test/hotspot/jtreg/ProblemList.txt ! test/hotspot/jtreg/compiler/uncommontrap/DeoptReallocFailure.java Changeset: 0a6ffa57 Author: Severin Gehwolf Date: 2024-07-01 08:47:29 +0000 URL: https://git.openjdk.org/loom/commit/0a6ffa57954ddf4f92205205a5a1bada813d127a 8261242: [Linux] OSContainer::is_containerized() returns true when run outside a container Reviewed-by: stuefe, iklam ! src/hotspot/os/linux/cgroupSubsystem_linux.cpp ! src/hotspot/os/linux/cgroupSubsystem_linux.hpp ! src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp ! src/hotspot/os/linux/cgroupV1Subsystem_linux.hpp ! src/hotspot/os/linux/cgroupV2Subsystem_linux.cpp ! src/hotspot/os/linux/cgroupV2Subsystem_linux.hpp ! src/hotspot/os/linux/osContainer_linux.cpp ! src/hotspot/share/include/jvm.h ! src/hotspot/share/prims/jvm.cpp ! src/java.base/linux/classes/jdk/internal/platform/CgroupMetrics.java ! src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystem.java ! src/java.base/linux/native/libjava/CgroupMetrics.c ! src/java.base/share/classes/jdk/internal/platform/Metrics.java ! src/java.base/share/classes/sun/launcher/LauncherHelper.java ! test/hotspot/gtest/runtime/test_cgroupSubsystem_linux.cpp ! test/hotspot/jtreg/ProblemList.txt - test/hotspot/jtreg/containers/cgroup/PlainRead.java + test/hotspot/jtreg/containers/cgroup/TestContainerized.java + test/jdk/jdk/internal/platform/cgroup/TestSystemSettings.java ! test/lib/jdk/test/lib/containers/cgroup/MetricsTester.java Changeset: 747e1e47 Author: Evgeny Nikitin Committer: Tobias Hartmann Date: 2024-07-01 10:21:31 +0000 URL: https://git.openjdk.org/loom/commit/747e1e47f576b0ca3ac97d1deea87418e67ff2d1 8334295: CTW: update modules Reviewed-by: shade, thartmann ! test/hotspot/jtreg/applications/ctw/modules/generate.bash + test/hotspot/jtreg/applications/ctw/modules/jdk_incubator_vector.java + test/hotspot/jtreg/applications/ctw/modules/jdk_internal_md.java + test/hotspot/jtreg/applications/ctw/modules/jdk_jpackage.java + test/hotspot/jtreg/applications/ctw/modules/jdk_nio_mapmode.java Changeset: 3ca2bcd4 Author: Adam Sotona Date: 2024-07-01 11:51:13 +0000 URL: https://git.openjdk.org/loom/commit/3ca2bcd402042791d7460dd79ee16a3f88436b3e 8335060: ClassCastException after JDK-8294960 Reviewed-by: liach, jpai ! src/java.base/share/classes/java/lang/invoke/TypeConvertingMethodAdapter.java + test/jdk/java/lang/invoke/TypeConvertingTest.java Changeset: 2f4f6cc3 Author: Arseny Bochkarev Committer: Ludovic Henry Date: 2024-07-01 12:19:49 +0000 URL: https://git.openjdk.org/loom/commit/2f4f6cc34c10c5519c74abbce8d1715013b50d5d 8317721: RISC-V: Implement CRC32 intrinsic Reviewed-by: vkempik, rehn ! src/hotspot/cpu/riscv/c1_LIRAssembler_riscv.cpp ! src/hotspot/cpu/riscv/c1_LIRGenerator_riscv.cpp ! src/hotspot/cpu/riscv/macroAssembler_riscv.cpp ! src/hotspot/cpu/riscv/macroAssembler_riscv.hpp ! src/hotspot/cpu/riscv/stubGenerator_riscv.cpp ! src/hotspot/cpu/riscv/stubRoutines_riscv.cpp ! src/hotspot/cpu/riscv/stubRoutines_riscv.hpp ! src/hotspot/cpu/riscv/vm_version_riscv.cpp Changeset: ee4720a7 Author: Leonid Mesnik Date: 2024-07-01 20:38:55 +0000 URL: https://git.openjdk.org/loom/commit/ee4720a75d815c84039055902c88b360737a1f9c 8333306: gc/arguments/TestParallelGCErgo.java fails when largepage are enabled Reviewed-by: ayang, zgu ! test/hotspot/jtreg/gc/arguments/TestParallelGCErgo.java Changeset: 5fe07b36 Author: Prasanta Sadhukhan Date: 2024-07-02 03:39:43 +0000 URL: https://git.openjdk.org/loom/commit/5fe07b36d9eb296661692d903ed0b9b5afefba0f 5021949: JSplitPane setEnabled(false) shouldn't be partially functional Reviewed-by: abhiscxk, achung, aivanov ! src/java.desktop/share/classes/javax/swing/JSplitPane.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicSplitPaneDivider.java + test/jdk/javax/swing/JSplitPane/TestSplitPaneEnableTest.java Changeset: 318d9aca Author: Kim Barrett Date: 2024-07-02 05:56:21 +0000 URL: https://git.openjdk.org/loom/commit/318d9acadf305f9d7d0cd8bb54b41506dd9914a8 8335369: Fix -Wzero-as-null-pointer-constant warnings in ImmutableOopMapBuilder Reviewed-by: kvn, jwaters ! src/hotspot/share/compiler/oopMap.hpp Changeset: 9046d7ae Author: Emanuel Peter Date: 2024-07-02 08:20:26 +0000 URL: https://git.openjdk.org/loom/commit/9046d7aee3082b6cbf79876efc1c508cb893caad 8335390: C2 MergeStores: wrong result with Unsafe Reviewed-by: thartmann, chagedorn, kvn ! src/hotspot/share/opto/memnode.cpp ! test/hotspot/jtreg/compiler/c2/TestMergeStores.java + test/hotspot/jtreg/compiler/c2/TestMergeStoresUnsafeArrayPointer.java Changeset: 4060b35b Author: Kim Barrett Date: 2024-07-02 08:58:20 +0000 URL: https://git.openjdk.org/loom/commit/4060b35b1d00fccbec4b20353063f77c43ecc686 8335298: Fix -Wzero-as-null-pointer-constant warning in G1CardSetContainers Reviewed-by: iwalulya, ayang ! src/hotspot/share/gc/g1/g1CardSetContainers.hpp Changeset: a537e87d Author: Daniel Fuchs Date: 2024-07-02 11:50:21 +0000 URL: https://git.openjdk.org/loom/commit/a537e87d2d2c6bff63f63bb436e3e919740221ce 8335530: Java file extension missing in AuthenticatorTest Reviewed-by: cstein, jpai - test/jdk/com/sun/net/httpserver/AuthenticatorTest + test/jdk/com/sun/net/httpserver/AuthenticatorTest.java Changeset: dd74e7f8 Author: Albert Mingkun Yang Date: 2024-07-02 12:15:02 +0000 URL: https://git.openjdk.org/loom/commit/dd74e7f8c1570ed34c89f4aca184f5668e4471db 8335147: Serial: Refactor TenuredGeneration::promote Reviewed-by: tschatzl, iwalulya ! src/hotspot/share/gc/serial/defNewGeneration.cpp ! src/hotspot/share/gc/serial/tenuredGeneration.cpp ! src/hotspot/share/gc/serial/tenuredGeneration.hpp Changeset: 685e5878 Author: Jasmine Karthikeyan Date: 2024-07-02 14:36:29 +0000 URL: https://git.openjdk.org/loom/commit/685e5878b823fa5e3ae88ffd76de6507d6057af2 8334816: compiler/c2/irTests/TestIfMinMax.java fails after 8334629 Reviewed-by: thartmann, chagedorn ! test/hotspot/jtreg/ProblemList.txt ! test/hotspot/jtreg/compiler/c2/irTests/TestIfMinMax.java Changeset: 153b12b9 Author: Severin Gehwolf Date: 2024-07-02 15:38:54 +0000 URL: https://git.openjdk.org/loom/commit/153b12b9df87fdf8122cae3bf7f13078f55f7101 8331560: Refactor Hotspot container detection code so that subsystem delegates to controllers Reviewed-by: jsjolen, stuefe ! src/hotspot/os/linux/cgroupSubsystem_linux.cpp ! src/hotspot/os/linux/cgroupSubsystem_linux.hpp + src/hotspot/os/linux/cgroupUtil_linux.cpp + src/hotspot/os/linux/cgroupUtil_linux.hpp ! src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp ! src/hotspot/os/linux/cgroupV1Subsystem_linux.hpp ! src/hotspot/os/linux/cgroupV2Subsystem_linux.cpp ! src/hotspot/os/linux/cgroupV2Subsystem_linux.hpp Changeset: a3479576 Author: Chris Plummer Date: 2024-07-02 18:13:50 +0000 URL: https://git.openjdk.org/loom/commit/a3479576c9b3e557cdc04e0984da6350e985dcc9 8335291: Problem list all SA core file tests on macosx-aarch64 due to JDK-8318754 Reviewed-by: kevinw, amenkov ! test/hotspot/jtreg/ProblemList.txt Changeset: 27982c8f Author: Viktor Klang Date: 2024-07-02 20:27:52 +0000 URL: https://git.openjdk.org/loom/commit/27982c8f5dad0e2d080846f803055c84bac9fddd 8327854: Test java/util/stream/test/org/openjdk/tests/java/util/stream/WhileOpStatefulTest.java failed with RuntimeException Reviewed-by: psandoz ! test/jdk/java/util/stream/test/org/openjdk/tests/java/util/stream/WhileOpStatefulTest.java Changeset: 1ef34c18 Author: Chen Liang Date: 2024-07-02 23:15:31 +0000 URL: https://git.openjdk.org/loom/commit/1ef34c183315b70ddc27c177a2867e30132609f5 8335475: ClassBuilder incorrectly calculates max_locals in some cases Reviewed-by: asotona ! src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java ! test/jdk/jdk/classfile/StackMapsTest.java Changeset: f187c92b Author: Kim Barrett Date: 2024-07-03 02:19:54 +0000 URL: https://git.openjdk.org/loom/commit/f187c92befbe63e23b11eb0401e5095c44c24389 8335370: Fix -Wzero-as-null-pointer-constant warning in jvmti_common.hpp Reviewed-by: jwaters, amenkov, sspitsyn ! test/lib/jdk/test/lib/jvmti/jvmti_common.hpp Changeset: 3a2d4264 Author: Chen Liang Date: 2024-07-03 02:42:06 +0000 URL: https://git.openjdk.org/loom/commit/3a2d426489ead9672512e0c5a6862284a54734ba 8334726: Remove accidentally exposed individual methods from Class-File API Reviewed-by: asotona ! src/java.base/share/classes/java/lang/classfile/attribute/ModuleAttribute.java ! src/java.base/share/classes/java/lang/classfile/components/CodeRelabeler.java ! src/java.base/share/classes/java/lang/classfile/constantpool/ConstantPoolBuilder.java ! src/java.base/share/classes/jdk/internal/classfile/impl/CodeRelabelerImpl.java ! src/java.base/share/classes/jdk/internal/classfile/impl/ModuleAttributeBuilderImpl.java ! src/java.base/share/classes/jdk/internal/classfile/impl/SplitConstantPool.java ! src/java.base/share/classes/jdk/internal/classfile/impl/TemporaryConstantPool.java Changeset: 8a664a4c Author: Chen Liang Date: 2024-07-03 02:43:41 +0000 URL: https://git.openjdk.org/loom/commit/8a664a4c359deefd7237f3672b62d7d8c1ffb453 8334734: Remove specialized readXxxEntry methods from ClassReader Reviewed-by: asotona ! src/java.base/share/classes/java/lang/classfile/ClassReader.java ! src/java.base/share/classes/jdk/internal/classfile/impl/AbstractInstruction.java ! src/java.base/share/classes/jdk/internal/classfile/impl/AnnotationReader.java ! src/java.base/share/classes/jdk/internal/classfile/impl/BoundAttribute.java ! src/java.base/share/classes/jdk/internal/classfile/impl/BoundRecordComponentInfo.java ! src/java.base/share/classes/jdk/internal/classfile/impl/ClassImpl.java ! src/java.base/share/classes/jdk/internal/classfile/impl/ClassReaderImpl.java ! src/java.base/share/classes/jdk/internal/classfile/impl/FieldImpl.java ! src/java.base/share/classes/jdk/internal/classfile/impl/MethodImpl.java Changeset: f7af4504 Author: Chen Liang Date: 2024-07-03 02:49:43 +0000 URL: https://git.openjdk.org/loom/commit/f7af4504a804711d93208b763b3e41eafcf61735 8335110: Fix instruction name and API spec inconsistencies in CodeBuilder Reviewed-by: asotona ! src/java.base/share/classes/java/lang/classfile/CodeBuilder.java ! src/java.base/share/classes/java/lang/classfile/attribute/CodeAttribute.java ! src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java ! src/java.base/share/classes/jdk/internal/classfile/impl/LabelImpl.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/EventInstrumentation.java ! test/jdk/jdk/classfile/helpers/RebuildingTransformation.java Changeset: f9b4ea13 Author: Xiaolong Peng Committer: David Holmes Date: 2024-07-03 02:56:17 +0000 URL: https://git.openjdk.org/loom/commit/f9b4ea13e693da268c9aee27dee49f9c7f798bb1 8334220: Optimize Klass layout after JDK-8180450 Reviewed-by: coleenp, stuefe, dholmes ! src/hotspot/share/oops/klass.hpp Changeset: fac74b11 Author: Xiaolong Peng Committer: David Holmes Date: 2024-07-03 03:01:06 +0000 URL: https://git.openjdk.org/loom/commit/fac74b118f5fda4ec297e46238d34ce5b9be1e21 8334229: Optimize InterpreterOopMap layout Reviewed-by: coleenp, dholmes ! src/hotspot/share/interpreter/oopMapCache.hpp Changeset: d51141e5 Author: Eirik Bj?rsn?s Committer: Jaikiran Pai Date: 2024-07-03 04:36:32 +0000 URL: https://git.openjdk.org/loom/commit/d51141e5fc84f9f933e78d0eb25af86e41798ad5 8321274: Rename ZipEntry.extraAttributes to ZipEntry.externalFileAttributes Reviewed-by: lancea, jpai ! src/java.base/share/classes/java/util/zip/ZipEntry.java ! src/java.base/share/classes/java/util/zip/ZipFile.java ! src/java.base/share/classes/java/util/zip/ZipOutputStream.java ! src/java.base/share/classes/jdk/internal/access/JavaUtilZipFileAccess.java ! src/jdk.jartool/share/classes/jdk/security/jarsigner/JarSigner.java ! src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java ! src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java ! src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources_de.java ! src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources_ja.java ! src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources_zh_CN.java ! src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java ! test/jdk/sun/security/tools/jarsigner/SymLinkTest.java Changeset: 0db9bc57 Author: Chen Liang Date: 2024-07-03 05:03:56 +0000 URL: https://git.openjdk.org/loom/commit/0db9bc57de07f8f1d0bf657621cb1b8fd7b01211 8335290: Rename ClassFile::transform to ClassFile::transformClass Reviewed-by: asotona ! src/java.base/share/classes/java/lang/Module.java ! src/java.base/share/classes/java/lang/classfile/ClassFile.java ! src/java.base/share/classes/java/lang/classfile/ClassFileTransform.java ! src/java.base/share/classes/java/lang/classfile/components/ClassRemapper.java ! src/java.base/share/classes/java/lang/classfile/components/snippet-files/PackageSnippets.java ! src/java.base/share/classes/java/lang/classfile/snippet-files/PackageSnippets.java ! src/java.base/share/classes/jdk/internal/classfile/impl/ClassFileImpl.java ! src/java.base/share/classes/jdk/internal/module/ModuleInfoExtender.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/StripJavaDebugAttributesPlugin.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/VersionPropsPlugin.java ! src/jdk.jshell/share/classes/jdk/jshell/execution/LocalExecutionControl.java ! test/jdk/java/io/Serializable/records/BadCanonicalCtrTest.java ! test/jdk/java/io/Serializable/records/ProhibitedMethods.java ! test/jdk/java/io/Serializable/records/SerialPersistentFieldsTest.java ! test/jdk/java/lang/ModuleTests/AnnotationsTest.java ! test/jdk/java/lang/instrument/asmlib/Instrumentor.java ! test/jdk/java/lang/invoke/8022701/BogoLoader.java ! test/jdk/java/lang/invoke/accessProtectedSuper/BogoLoader.java ! test/jdk/jdk/classfile/AdaptCodeTest.java ! test/jdk/jdk/classfile/AdvancedTransformationsTest.java ! test/jdk/jdk/classfile/BSMTest.java ! test/jdk/jdk/classfile/ClassBuildingTest.java ! test/jdk/jdk/classfile/ClassHierarchyInfoTest.java ! test/jdk/jdk/classfile/CorpusTest.java ! test/jdk/jdk/classfile/DiscontinuedInstructionsTest.java ! test/jdk/jdk/classfile/LvtTest.java ! test/jdk/jdk/classfile/MassAdaptCopyCodeTest.java ! test/jdk/jdk/classfile/MassAdaptCopyPrimitiveMatchCodeTest.java ! test/jdk/jdk/classfile/OptionsTest.java ! test/jdk/jdk/classfile/ShortJumpsFixTest.java ! test/jdk/jdk/classfile/StackMapsTest.java ! test/jdk/jdk/classfile/TestRecordComponent.java ! test/jdk/jdk/classfile/TransformTests.java ! test/jdk/jdk/classfile/VerifierSelfTest.java ! test/jdk/jdk/classfile/examples/AnnotationsExamples.java ! test/jdk/jdk/classfile/examples/ExampleGallery.java ! test/jdk/jdk/classfile/examples/ExperimentalTransformExamples.java ! test/jdk/jdk/classfile/examples/TransformExamples.java ! test/jdk/jdk/classfile/helpers/Transforms.java ! test/jdk/jdk/jfr/event/io/TestInstrumentation.java ! test/jdk/jdk/jfr/javaagent/TestEventInstrumentation.java ! test/jdk/jdk/lambda/separate/ClassToInterfaceConverter.java ! test/langtools/tools/javac/MethodParametersTest.java ! test/langtools/tools/javac/classreader/8171132/BadConstantValue.java ! test/langtools/tools/javac/classreader/BadMethodParameter.java ! test/langtools/tools/javac/defaultMethods/BadClassfile.java ! test/langtools/tools/javac/launcher/SourceLauncherTest.java ! test/langtools/tools/javac/modules/IncubatingTest.java ! test/langtools/tools/javac/modules/JavaBaseTest.java ! test/langtools/tools/javac/modules/OpenModulesTest.java ! test/langtools/tools/javac/platform/createsymbols/CreateSymbolsTestImpl.java ! test/langtools/tools/javac/processing/model/element/TestOrigin.java ! test/langtools/tools/javap/UndefinedAccessFlagTest.java ! test/micro/org/openjdk/bench/jdk/classfile/AdHocAdapt.java ! test/micro/org/openjdk/bench/jdk/classfile/ClassfileBenchmark.java ! test/micro/org/openjdk/bench/jdk/classfile/ParseOptions.java ! test/micro/org/openjdk/bench/jdk/classfile/RebuildMethodBodies.java ! test/micro/org/openjdk/bench/jdk/classfile/Transforms.java Changeset: 7bc8f9c1 Author: Kim Barrett Date: 2024-07-03 05:55:28 +0000 URL: https://git.openjdk.org/loom/commit/7bc8f9c150cbf457edf6144adba734ecd5ca5a0f 8335589: Fix -Wzero-as-null-pointer-constant warnings in IdealLoopTree ctor Reviewed-by: thartmann ! src/hotspot/share/opto/loopnode.hpp Changeset: f3f90dc1 Author: Kim Barrett Date: 2024-07-03 05:57:49 +0000 URL: https://git.openjdk.org/loom/commit/f3f90dc11a5cbc146a5ef8a73eadf4168373838d 8335592: Fix -Wzero-as-null-pointer-constant warnings in RootNode ctor Reviewed-by: thartmann ! src/hotspot/share/opto/rootnode.hpp Changeset: 77a7078b Author: Kim Barrett Date: 2024-07-03 06:00:20 +0000 URL: https://git.openjdk.org/loom/commit/77a7078b82fd0cb3cfa13685072f04fdef33758b 8335593: Fix -Wzero-as-null-pointer-constant warning in Type_Array ctor Reviewed-by: thartmann ! src/hotspot/share/opto/phaseX.hpp Changeset: 4d2f7376 Author: Gerg? Barany Committer: Doug Simon Date: 2024-07-03 08:08:22 +0000 URL: https://git.openjdk.org/loom/commit/4d2f73764bcd5ff62fbdb9d406d4180ae09613ff 8335357: Delete HotSpotJDKReflection.oopSizeOffset Reviewed-by: dnsimon ! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotJDKReflection.java Changeset: 6c84e9c8 Author: Albert Mingkun Yang Date: 2024-07-03 08:42:43 +0000 URL: https://git.openjdk.org/loom/commit/6c84e9c8cb71aac103901c0d92fe6ae51aabff15 8335544: Serial: Remove unused _should_allocate_from_space Reviewed-by: iwalulya ! src/hotspot/share/gc/serial/defNewGeneration.cpp ! src/hotspot/share/gc/serial/defNewGeneration.hpp Changeset: c06b75ff Author: Kim Barrett Date: 2024-07-03 11:12:08 +0000 URL: https://git.openjdk.org/loom/commit/c06b75ff88babf57bdcd0919ea177ff363fd858b 8335591: Fix -Wzero-as-null-pointer-constant warnings in ConcurrentHashTable Reviewed-by: chagedorn ! src/hotspot/share/utilities/concurrentHashTable.inline.hpp Changeset: 350f9c19 Author: Erik Gahlin Date: 2024-07-03 11:36:14 +0000 URL: https://git.openjdk.org/loom/commit/350f9c1947b0eab3ee233516ceefca1e25de9583 8322812: Manpage for jcmd is missing JFR.view command Reviewed-by: kevinw, mgronlun ! src/jdk.jcmd/share/man/jcmd.1 Changeset: 6db4c6a7 Author: Qizheng Xing Committer: Tobias Hartmann Date: 2024-07-03 12:12:00 +0000 URL: https://git.openjdk.org/loom/commit/6db4c6a772df856fc3099c32a5b2c102a30d360c 8335536: Fix assertion failure in IdealGraphPrinter when append is true Reviewed-by: thartmann, chagedorn, tholenstein ! src/hotspot/share/opto/idealGraphPrinter.cpp ! src/hotspot/share/opto/idealGraphPrinter.hpp Changeset: 5866b16d Author: Feilong Jiang Date: 2024-07-03 12:12:12 +0000 URL: https://git.openjdk.org/loom/commit/5866b16dbca3f63770c8792d204dabdf49b59839 8335411: RISC-V: Optimize encode_heap_oop when oop is not null Reviewed-by: fyang, rehn ! src/hotspot/cpu/riscv/macroAssembler_riscv.cpp ! src/hotspot/cpu/riscv/macroAssembler_riscv.hpp ! src/hotspot/cpu/riscv/riscv.ad Changeset: 6923a511 Author: Albert Mingkun Yang Date: 2024-07-03 12:57:26 +0000 URL: https://git.openjdk.org/loom/commit/6923a5114b2a9f02f0d6f0fefc21141ac3b9322a 8335607: Serial: Remove unused collection_attempt_is_safe Reviewed-by: tschatzl ! src/hotspot/share/gc/serial/defNewGeneration.cpp ! src/hotspot/share/gc/serial/defNewGeneration.hpp Changeset: 5a8af2b8 Author: Arseny Bochkarev Committer: Vladimir Kempik Date: 2024-07-03 14:09:59 +0000 URL: https://git.openjdk.org/loom/commit/5a8af2b8b93672de9b3a3e73e6984506980da932 8335615: Clean up left-overs from 8317721 Reviewed-by: fyang ! src/hotspot/cpu/riscv/macroAssembler_riscv.cpp Changeset: cf4f2b53 Author: Ivan Walulya Date: 2024-07-03 15:12:40 +0000 URL: https://git.openjdk.org/loom/commit/cf4f2b53d6174a808f8b45f0bb848efd5bd91c3c 8332517: G1: Refactor G1AllocRegion Reviewed-by: tschatzl, ayang ! src/hotspot/share/gc/g1/g1AllocRegion.cpp ! src/hotspot/share/gc/g1/g1AllocRegion.hpp ! src/hotspot/share/gc/g1/g1AllocRegion.inline.hpp ! src/hotspot/share/gc/g1/g1Allocator.cpp ! src/hotspot/share/gc/g1/g1HeapRegion.hpp ! src/hotspot/share/gc/g1/g1HeapRegion.inline.hpp Changeset: 19a8a2ba Author: Albert Mingkun Yang Date: 2024-07-03 15:42:47 +0000 URL: https://git.openjdk.org/loom/commit/19a8a2baa9e749c7527ff526b2794826f0cdebb3 8335618: Serial: Remove unused definitions in SerialHeap Reviewed-by: iwalulya ! src/hotspot/share/gc/serial/defNewGeneration.hpp ! src/hotspot/share/gc/serial/serialHeap.hpp Changeset: 8aaec37a Author: Thomas Stuefe Date: 2024-07-03 16:08:34 +0000 URL: https://git.openjdk.org/loom/commit/8aaec37ace102b55ee1387cfd1967ec3ab662083 8322475: Extend printing for System.map Reviewed-by: sgehwolf, jsjolen ! src/hotspot/os/linux/memMapPrinter_linux.cpp + src/hotspot/os/linux/procMapsParser.cpp + src/hotspot/os/linux/procMapsParser.hpp ! src/hotspot/share/nmt/memMapPrinter.cpp ! src/hotspot/share/nmt/memMapPrinter.hpp ! src/hotspot/share/runtime/java.cpp ! src/hotspot/share/services/attachListener.cpp ! src/hotspot/share/services/diagnosticCommand.cpp ! src/hotspot/share/services/diagnosticCommand.hpp ! src/hotspot/share/utilities/ostream.cpp ! src/hotspot/share/utilities/ostream.hpp ! test/hotspot/jtreg/serviceability/dcmd/vm/SystemDumpMapTest.java ! test/hotspot/jtreg/serviceability/dcmd/vm/SystemMapTest.java + test/hotspot/jtreg/serviceability/dcmd/vm/SystemMapTestBase.java Changeset: 13b782c3 Author: Hamlin Li Date: 2024-07-03 16:10:22 +0000 URL: https://git.openjdk.org/loom/commit/13b782c3de9a470a7cf1db9d5111ce19faf28729 8334554: RISC-V: verify & fix perf of string comparison Reviewed-by: rehn, luhenry, fyang ! src/hotspot/cpu/riscv/c2_MacroAssembler_riscv.cpp ! src/hotspot/cpu/riscv/c2_MacroAssembler_riscv.hpp ! src/hotspot/cpu/riscv/riscv_v.ad Changeset: 9a91865f Author: Thomas Schatzl Date: 2024-07-03 16:29:52 +0000 URL: https://git.openjdk.org/loom/commit/9a91865ff38f6fbb48b9aba5028e0b529d9bce76 8335395: G1: Verification does not detect references into Free regions Reviewed-by: ayang, iwalulya ! src/hotspot/share/gc/g1/g1CollectedHeap.inline.hpp ! src/hotspot/share/gc/g1/g1HeapRegion.cpp Changeset: ab557740 Author: Patricio Chilano Mateo Date: 2024-07-03 13:17:58 +0000 URL: https://git.openjdk.org/loom/commit/ab557740b8f1d1ebd5c9410784b6c9fca3ab82d3 Merge branch 'master' into fibers ! src/hotspot/cpu/ppc/macroAssembler_ppc.cpp ! src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp ! src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp ! src/hotspot/cpu/riscv/c2_MacroAssembler_riscv.cpp ! src/hotspot/cpu/s390/macroAssembler_s390.cpp ! src/hotspot/cpu/s390/sharedRuntime_s390.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/classfile/javaClasses.hpp ! src/hotspot/share/classfile/vmIntrinsics.hpp ! src/hotspot/share/classfile/vmSymbols.hpp ! src/hotspot/share/include/jvm.h ! src/hotspot/share/interpreter/interpreterRuntime.cpp ! src/hotspot/share/interpreter/oopMapCache.cpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/method.cpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/opto/library_call.hpp ! src/hotspot/share/prims/jvm.cpp ! src/hotspot/share/prims/jvmtiEnvBase.cpp ! src/hotspot/share/runtime/globals.hpp ! src/hotspot/share/runtime/objectMonitor.cpp ! src/hotspot/share/runtime/objectMonitor.hpp ! src/hotspot/share/runtime/sharedRuntime.cpp ! src/hotspot/share/runtime/synchronizer.cpp ! src/hotspot/share/runtime/synchronizer.hpp ! src/hotspot/share/runtime/vframe.cpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/hotspot/share/services/diagnosticCommand.cpp ! src/hotspot/share/services/diagnosticCommand.hpp ! test/hotspot/jtreg/ProblemList.txt ! src/hotspot/cpu/ppc/macroAssembler_ppc.cpp ! src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp ! src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp ! src/hotspot/cpu/riscv/c2_MacroAssembler_riscv.cpp ! src/hotspot/cpu/s390/macroAssembler_s390.cpp ! src/hotspot/cpu/s390/sharedRuntime_s390.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/classfile/javaClasses.hpp ! src/hotspot/share/classfile/vmIntrinsics.hpp ! src/hotspot/share/classfile/vmSymbols.hpp ! src/hotspot/share/include/jvm.h ! src/hotspot/share/interpreter/interpreterRuntime.cpp ! src/hotspot/share/interpreter/oopMapCache.cpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/method.cpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/opto/library_call.hpp ! src/hotspot/share/prims/jvm.cpp ! src/hotspot/share/prims/jvmtiEnvBase.cpp ! src/hotspot/share/runtime/globals.hpp ! src/hotspot/share/runtime/objectMonitor.cpp ! src/hotspot/share/runtime/objectMonitor.hpp ! src/hotspot/share/runtime/sharedRuntime.cpp ! src/hotspot/share/runtime/synchronizer.cpp ! src/hotspot/share/runtime/synchronizer.hpp ! src/hotspot/share/runtime/vframe.cpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/hotspot/share/services/diagnosticCommand.cpp ! src/hotspot/share/services/diagnosticCommand.hpp ! test/hotspot/jtreg/ProblemList.txt From ron.pressler at oracle.com Thu Jul 4 18:02:29 2024 From: ron.pressler at oracle.com (Ron Pressler) Date: Thu, 4 Jul 2024 18:02:29 +0000 Subject: [External] : Re: Experience using virtual threads in EA 23-loom+4-102 In-Reply-To: <052D6B72-3AD7-442C-99BB-87F1F183BB74@icloud.com> References: <07DDEEC5-688D-45A4-A651-CFDA38E3757C@oracle.com> <2B54EE29-CDD4-47A0-8178-27F8FE2AD39F@icloud.com> <052D6B72-3AD7-442C-99BB-87F1F183BB74@icloud.com> Message-ID: > On 3 Jul 2024, at 17:43, Robert Engels wrote: > > I don't think that is correct - but I could be wrong. > > With platform threads the min and max latency in a completely cpu bound scenario should be very close the the average with a completely fair scheduler (when all tasks/threads are submitted at the same time). > > Without timesharing, the average will be the same, but the min and max latencies will be far off the average - as the tasks submitted first complete very quickly, and the tasks submitted at the end take a very long time because they need to have all of the tasks before them complete. Consider 100 tasks, each running for 1 CPU second on a 1 core machine (although it works the same way with any number of cores). With time-sharing, the average (and median) latency would be 100s. Without time sharing the average (and median) latency would be almost half that. > > The linux scheduler relies on timeslicing in order to have a ?fair? system. I think most Java ?server? type applications strive for fairness as well - i.e. long tail latencies in anything are VERY bad (thus the constant fight against long GC pauses - better to amortize those for consistency). We are familiar with the theory and design of time sharing. The one and only reason that the virtual thread scheduler doesn?t employ it is that we?ve yet to find realistic server workload for which it helpst. If someone brings to our attention some realistic server workloads where it helps, then we?ll have an actual problem we can try solving. ? Ron From ron.pressler at oracle.com Thu Jul 4 18:09:29 2024 From: ron.pressler at oracle.com (Ron Pressler) Date: Thu, 4 Jul 2024 18:09:29 +0000 Subject: [External] : Re: Experience using virtual threads in EA 23-loom+4-102 In-Reply-To: References: <07DDEEC5-688D-45A4-A651-CFDA38E3757C@oracle.com> <2B54EE29-CDD4-47A0-8178-27F8FE2AD39F@icloud.com> <052D6B72-3AD7-442C-99BB-87F1F183BB74@icloud.com> Message-ID: <00C71C42-4BCA-4D1F-BDE0-95190554DD0E@oracle.com> > On 3 Jul 2024, at 18:18, Sam Pullara wrote: > > As a developer trying to use this stuff, I 100% agree that fair is better. If I need something that isn't fair, I can do that myself. It?s not a question of agreement or preference, but of an actual problem we can solve and know that we?ve solved. We need realistic examples of server workloads where time sharing could help the virtual thread scheduler (and not examples where there are even better solultions without introducing time sharing into the scheduler) before we can change the scheduler to use it. We don?t want to introduce a ?solution? without knowing exactly what problem it aims to solve. However, if and when we expose custom schedulers, they could choose to use time sharing whether it is justified or not. ? Ron From ron.pressler at oracle.com Thu Jul 4 18:25:44 2024 From: ron.pressler at oracle.com (Ron Pressler) Date: Thu, 4 Jul 2024 18:25:44 +0000 Subject: [External] : Re: Experience using virtual threads in EA 23-loom+4-102 In-Reply-To: <00C71C42-4BCA-4D1F-BDE0-95190554DD0E@oracle.com> References: <07DDEEC5-688D-45A4-A651-CFDA38E3757C@oracle.com> <2B54EE29-CDD4-47A0-8178-27F8FE2AD39F@icloud.com> <052D6B72-3AD7-442C-99BB-87F1F183BB74@icloud.com> <00C71C42-4BCA-4D1F-BDE0-95190554DD0E@oracle.com> Message-ID: <3B22981B-7927-4026-BF10-5E912BD14C5C@oracle.com> > On 4 Jul 2024, at 19:09, Ron Pressler wrote: > > > >> On 3 Jul 2024, at 18:18, Sam Pullara wrote: >> >> As a developer trying to use this stuff, I 100% agree that fair is better. If I need something that isn't fair, I can do that myself. > > It?s not a question of agreement or preference, but of an actual problem we can solve and know that we?ve solved. We need realistic examples of server workloads where time sharing could help the virtual thread scheduler (and not examples where there are even better solultions without introducing time sharing into the scheduler) before we can change the scheduler to use it. We don?t want to introduce a ?solution? without knowing exactly what problem it aims to solve. > > However, if and when we expose custom schedulers, they could choose to use time sharing whether it is justified or not. > > ? Ron To elaborate more on that, there are two situations. The number of computation-heavy tasks may be small and known, like background processing, in which case we have a trivial solution that?s better than introducing time sharing to the scheduler ? run those tasks on platform threads. So the actual problem time sharing in the virtual thread scheduler would potentially solve is if some portion of the very large number of virtual threads would occasionally need to do heavy computation. But for time sharing to help in that situation, that portion would have to be just right. Too small or too large and time sharing won?t help. So the question becomes, when and how often does such a situation arise in practice? That?s why we need examples from the field. ? Ron From ron.pressler at oracle.com Thu Jul 4 18:27:31 2024 From: ron.pressler at oracle.com (Ron Pressler) Date: Thu, 4 Jul 2024 18:27:31 +0000 Subject: [External] : Re: Experience using virtual threads in EA 23-loom+4-102 In-Reply-To: <3B22981B-7927-4026-BF10-5E912BD14C5C@oracle.com> References: <07DDEEC5-688D-45A4-A651-CFDA38E3757C@oracle.com> <2B54EE29-CDD4-47A0-8178-27F8FE2AD39F@icloud.com> <052D6B72-3AD7-442C-99BB-87F1F183BB74@icloud.com> <00C71C42-4BCA-4D1F-BDE0-95190554DD0E@oracle.com> <3B22981B-7927-4026-BF10-5E912BD14C5C@oracle.com> Message-ID: <6861B1BB-48E3-44BB-8239-DC98C1EC7870@oracle.com> > On 4 Jul 2024, at 19:25, Ron Pressler wrote: > > > >> On 4 Jul 2024, at 19:09, Ron Pressler wrote: >> >> >> >>> On 3 Jul 2024, at 18:18, Sam Pullara wrote: >>> >>> As a developer trying to use this stuff, I 100% agree that fair is better. If I need something that isn't fair, I can do that myself. >> >> It?s not a question of agreement or preference, but of an actual problem we can solve and know that we?ve solved. We need realistic examples of server workloads where time sharing could help the virtual thread scheduler (and not examples where there are even better solultions without introducing time sharing into the scheduler) before we can change the scheduler to use it. We don?t want to introduce a ?solution? without knowing exactly what problem it aims to solve. >> >> However, if and when we expose custom schedulers, they could choose to use time sharing whether it is justified or not. >> >> ? Ron > > To elaborate more on that, there are two situations. The number of computation-heavy tasks may be small and known, like background processing, in which case we have a trivial solution that?s better than introducing time sharing to the scheduler ? run those tasks on platform threads. > > So the actual problem time sharing in the virtual thread scheduler would potentially solve is if some portion of the very large number of virtual threads would occasionally need to do heavy computation. But for time sharing to help in that situation, that portion would have to be just right. Too small or too large and time sharing won?t help. So the question becomes, when and how often does such a situation arise in practice? That?s why we need examples from the field. > > ? Ron * some RANDOM portion, that is. From robaho at icloud.com Thu Jul 4 18:41:03 2024 From: robaho at icloud.com (Robert Engels) Date: Thu, 4 Jul 2024 13:41:03 -0500 Subject: [External] : Re: Experience using virtual threads in EA 23-loom+4-102 In-Reply-To: References: <07DDEEC5-688D-45A4-A651-CFDA38E3757C@oracle.com> <2B54EE29-CDD4-47A0-8178-27F8FE2AD39F@icloud.com> <052D6B72-3AD7-442C-99BB-87F1F183BB74@icloud.com> Message-ID: <746D1DC1-D689-495A-ADC4-C6D8E465E39B@icloud.com> > > Consider 100 tasks, each running for 1 CPU second on a 1 core machine (although it works the same way with any number of cores). With time-sharing, the average (and median) latency would be 100s. Without time sharing the average (and median) latency would be almost half that. Yes, but the tail latency for timesharing is 100s. Without timesharing, the tail latency is more than 5000 secs - or an order of magnitude more. So much more in fact, that most requests will be cancelled due to timeout and resubmitted which further degrades the situation as the number of retry requests explode. As to a realistic workload, I imagine all of them. All the services I can think of strive to minimize tail latency, not the average latency - or at least the 90-99% latency. People can?t really distinguish 2x with small numbers - 50x it is obvious (100ms ms vs 200 ms ? 100ms vs 5 secs). Human perception/responsiveness expectations come into play. In some ways the low median hurts the non-timesliced case because the user/system expects a response within X and when it doesn?t happen (more than 50% of the time) they cancel and resubmit the request suspecting an error (or just human impatience). Obviously, the request volume and single average task duration play a large part in this, but it doesn?t seem that ?show me a workload? is a fair argument - timeslicing for fairness has been accepted for decades. And ?fair? systems are the expected systems. If that weren?t the case, most server Linux installations would be configured with timeslicing turned off - which they aren?t. Modern developers rely on timeslicing when designing systems. All of the above doesn?t even address the case of IO tasks being blocked by non-preemptible cpu bound tasks - which is often the strongest argument for timeslicing, especially in low cpu count systems with varied workloads. Which is also why the OS scheduler (in a non-preemtible OS) will play certain tricks, like running all ready to run IO bound tasks before scheduling any new tasks (which may be cpu bound). Similarly, even with timeslicing, most schedulers will prioritize running tasks that the OS estimates will run for a small amount then give up their slice due to IO. I don?t have hard numbers, I can only look to why most OS?s use timeslicing, and why Go had to add it, and make an educated guess. Luckily, Java also has platform threads, so even with non-timesliced VT?s, there are work-arounds available. I am not saying this needs to change, but I think it needs to be better communicated to the community and what the ramifications are (e.g. atomic spin loops can deadlock the system). > On Jul 4, 2024, at 1:02 PM, Ron Pressler wrote: > > > >> On 3 Jul 2024, at 17:43, Robert Engels wrote: >> >> I don't think that is correct - but I could be wrong. >> >> With platform threads the min and max latency in a completely cpu bound scenario should be very close the the average with a completely fair scheduler (when all tasks/threads are submitted at the same time). >> >> Without timesharing, the average will be the same, but the min and max latencies will be far off the average - as the tasks submitted first complete very quickly, and the tasks submitted at the end take a very long time because they need to have all of the tasks before them complete. > > > Consider 100 tasks, each running for 1 CPU second on a 1 core machine (although it works the same way with any number of cores). With time-sharing, the average (and median) latency would be 100s. Without time sharing the average (and median) latency would be almost half that. > >> >> The linux scheduler relies on timeslicing in order to have a ?fair? system. I think most Java ?server? type applications strive for fairness as well - i.e. long tail latencies in anything are VERY bad (thus the constant fight against long GC pauses - better to amortize those for consistency). > > We are familiar with the theory and design of time sharing. The one and only reason that the virtual thread scheduler doesn?t employ it is that we?ve yet to find realistic server workload for which it helpst. If someone brings to our attention some realistic server workloads where it helps, then we?ll have an actual problem we can try solving. > > ? Ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron.pressler at oracle.com Thu Jul 4 18:43:12 2024 From: ron.pressler at oracle.com (Ron Pressler) Date: Thu, 4 Jul 2024 18:43:12 +0000 Subject: [External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: References: <5A2E1F5D-9346-48B2-B6C8-3459FB6E32B0@oracle.com> <5C2E3DDB-6F90-44F8-9783-A2B2C77378AA@ix.netcom.com> <7196614D-E2FA-4492-BE1E-B2BB0B0DE1CE@oracle.com> <99B9907A-218C-46DF-B909-70EC39CEABAE@ix.netcom.com> <44E8FB97-4D46-4F3B-8C0C-13893A67EA9B@oracle.com> <0A2CC387-3B85-4C3F-8AEA-24B6FD1D9DB3@ix.netcom.com> Message-ID: > On 3 Jul 2024, at 18:27, robert engels wrote: > > I agree 100% - I am fighting that the auto-closing of the queues, clean-up, etc is ?unneeded magic? There is no auto-closing, no cleanup, and no magic. If a thread gets stuck in a state where it can never be observed or continued ? so if it is NOT waiting on a queue to which something could be enqueued because in that case the thread COULD possibly continue ? then whether that thread consumes some inaccessible bytes in memory or not is the same as far as functionality is concerned. To compare it to a magic trick, this is about as magical as me asking you to pick a card from a deck without looking at it and then torching both your card and the deck and telling you that I know your card had some suit and either a face or a number. ? Ron From bronee at gmail.com Thu Jul 4 20:34:05 2024 From: bronee at gmail.com (Brian S O'Neill) Date: Thu, 4 Jul 2024 13:34:05 -0700 Subject: [External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: References: <5A2E1F5D-9346-48B2-B6C8-3459FB6E32B0@oracle.com> <5C2E3DDB-6F90-44F8-9783-A2B2C77378AA@ix.netcom.com> <7196614D-E2FA-4492-BE1E-B2BB0B0DE1CE@oracle.com> <99B9907A-218C-46DF-B909-70EC39CEABAE@ix.netcom.com> <44E8FB97-4D46-4F3B-8C0C-13893A67EA9B@oracle.com> <0A2CC387-3B85-4C3F-8AEA-24B6FD1D9DB3@ix.netcom.com> Message-ID: <8a3f069c-6a2b-476d-a948-a5c96d572fc6@gmail.com> On 2024-07-04 11:43 AM, Ron Pressler wrote: > > >> On 3 Jul 2024, at 18:27, robert engels wrote: >> >> I agree 100% - I am fighting that the auto-closing of the queues, clean-up, etc is ?unneeded magic? > > There is no auto-closing, no cleanup, and no magic. If a thread gets stuck in a state where it can never be observed or continued ? so if it is NOT waiting on a queue to which something could be enqueued because in that case the thread COULD possibly continue ? then whether that thread consumes some inaccessible bytes in memory or not is the same as far as functionality is concerned. > What about the case that that freeing a forever-stuck VT allows more objects to be freed, which then might have cleaning actions? Freeing the stuck VT could create a side effect that would have only occurred when it resumed somehow. From robaho at icloud.com Thu Jul 4 21:41:51 2024 From: robaho at icloud.com (robert engels) Date: Thu, 4 Jul 2024 16:41:51 -0500 Subject: [External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: References: Message-ID: <375C8629-09D6-4238-8E6D-9CF63C11D22C@icloud.com> I?m sorry I don?t follow. I thought I explained benefit of observabiluty with regards to lifecycle but I guess I didn?t. I don?t think that comment was helpful - maybe it?s just me. > On Jul 4, 2024, at 1:44?PM, Ron Pressler wrote: > > ? > >> On 3 Jul 2024, at 18:27, robert engels wrote: >> >> I agree 100% - I am fighting that the auto-closing of the queues, clean-up, etc is ?unneeded magic? > > There is no auto-closing, no cleanup, and no magic. If a thread gets stuck in a state where it can never be observed or continued ? so if it is NOT waiting on a queue to which something could be enqueued because in that case the thread COULD possibly continue ? then whether that thread consumes some inaccessible bytes in memory or not is the same as far as functionality is concerned. > > To compare it to a magic trick, this is about as magical as me asking you to pick a card from a deck without looking at it and then torching both your card and the deck and telling you that I know your card had some suit and either a face or a number. > > ? Ron > From robaho at icloud.com Fri Jul 5 00:54:51 2024 From: robaho at icloud.com (robert engels) Date: Thu, 4 Jul 2024 19:54:51 -0500 Subject: [External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: <375C8629-09D6-4238-8E6D-9CF63C11D22C@icloud.com> References: <375C8629-09D6-4238-8E6D-9CF63C11D22C@icloud.com> Message-ID: Btw - this thread sounds like you?re annoyed. That was not my intent. I?m sorry if I annoyed you. I hope you had a wonderful 4th. > On Jul 4, 2024, at 4:43?PM, robert engels wrote: > > ?I?m sorry I don?t follow. I thought I explained benefit of observabiluty with regards to lifecycle but I guess I didn?t. I don?t think that comment was helpful - maybe it?s just me. > >> On Jul 4, 2024, at 1:44?PM, Ron Pressler wrote: >> >> ? >> >>>> On 3 Jul 2024, at 18:27, robert engels wrote: >>> >>> I agree 100% - I am fighting that the auto-closing of the queues, clean-up, etc is ?unneeded magic? >> >> There is no auto-closing, no cleanup, and no magic. If a thread gets stuck in a state where it can never be observed or continued ? so if it is NOT waiting on a queue to which something could be enqueued because in that case the thread COULD possibly continue ? then whether that thread consumes some inaccessible bytes in memory or not is the same as far as functionality is concerned. >> >> To compare it to a magic trick, this is about as magical as me asking you to pick a card from a deck without looking at it and then torching both your card and the deck and telling you that I know your card had some suit and either a face or a number. >> >> ? Ron >> From aph-open at littlepinkcloud.com Fri Jul 5 09:33:57 2024 From: aph-open at littlepinkcloud.com (Andrew Haley) Date: Fri, 5 Jul 2024 10:33:57 +0100 Subject: [External] : Re: Experience using virtual threads in EA 23-loom+4-102 In-Reply-To: References: <07DDEEC5-688D-45A4-A651-CFDA38E3757C@oracle.com> <2B54EE29-CDD4-47A0-8178-27F8FE2AD39F@icloud.com> <052D6B72-3AD7-442C-99BB-87F1F183BB74@icloud.com> Message-ID: On 7/3/24 18:18, Sam Pullara wrote: > As a developer trying to use this stuff, I 100% agree that fair is better. If I need something that isn't fair, I can do that myself. But fairness costs. There's a well-known branch of welfare economics which studies the "Efficiency-Fairness Trade-off". The limiting case of perfect fairness, where everybody gets the same, is that no one gets anything. So it is with thread scheduling, too. We must choose a parameter which is the degree of unfairness we'll tolerate, or conversely, the reduction of efficiency we'll tolerate. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From robaho at me.com Fri Jul 5 17:41:49 2024 From: robaho at me.com (Robert Engels) Date: Fri, 5 Jul 2024 12:41:49 -0500 Subject: Httpserver performance Message-ID: Some that follow this list might be interested in the latest release of my httpserver - which is a port of the JDK one - designed for virtual threads (no async, no synchronized blocks) at https://github.com/robaho/httpserver It shows nearly 3x performance on the tech empower low-level benchmarks. I attribute most of the performance gain due to it supporting http pipelining, which I think should be easy to backport in the JDK version. There are some other micro improvements that help quite a bit for these types of tests. As it is, it is able to saturate a 1gbit ethernet link. I am in the process of submitting it to Tech Empower as an available framework. Feel free to reach out with any questions. Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: PastedGraphic-6.png Type: image/png Size: 65926 bytes Desc: not available URL: From duke at openjdk.org Sat Jul 6 01:12:10 2024 From: duke at openjdk.org (duke) Date: Sat, 6 Jul 2024 01:12:10 GMT Subject: git: openjdk/loom: fibers: 31 new changesets Message-ID: Changeset: 68ffec98 Author: Erik Gahlin Date: 2024-07-03 20:43:08 +0000 URL: https://git.openjdk.org/loom/commit/68ffec9800b798927a050900a2d47000aa18ef30 8335479: JFR: Missing documentation for -XX:StartFlightRecording Reviewed-by: mgronlun ! src/java.base/share/man/java.1 Changeset: 587535c5 Author: David Holmes Date: 2024-07-03 21:42:08 +0000 URL: https://git.openjdk.org/loom/commit/587535c5b9bb258836b47c3a8c41ffb91bbfc131 8334545: runtime/ClassInitErrors/TestStackOverflowDuringInit.java fails after JDK-8294960 Reviewed-by: iklam, stuefe ! test/hotspot/jtreg/ProblemList.txt ! test/hotspot/jtreg/runtime/ClassInitErrors/TestStackOverflowDuringInit.java Changeset: 3efa93ba Author: Kim Barrett Date: 2024-07-03 22:03:23 +0000 URL: https://git.openjdk.org/loom/commit/3efa93ba1307cedf05609c0c04b2ba986a515f6e 8335588: Fix -Wzero-as-null-pointer-constant warnings in calls to Node ctor Reviewed-by: thartmann, chagedorn ! src/hotspot/share/opto/addnode.hpp ! src/hotspot/share/opto/convertnode.hpp ! src/hotspot/share/opto/countbitsnode.hpp ! src/hotspot/share/opto/intrinsicnode.hpp ! src/hotspot/share/opto/loopnode.hpp ! src/hotspot/share/opto/memnode.hpp ! src/hotspot/share/opto/movenode.hpp ! src/hotspot/share/opto/mulnode.hpp ! src/hotspot/share/opto/opaquenode.hpp ! src/hotspot/share/opto/subnode.hpp Changeset: e01626cf Author: David Holmes Date: 2024-07-04 04:18:31 +0000 URL: https://git.openjdk.org/loom/commit/e01626cf09850f7b0af33cdb905ca8992266fe5b 8335655: ProblemList serviceability/dcmd/vm tests failing after JDK-8322475 Reviewed-by: mikael ! test/hotspot/jtreg/ProblemList-generational-zgc.txt ! test/hotspot/jtreg/ProblemList-zgc.txt Changeset: 7b894bc4 Author: Thomas Stuefe Date: 2024-07-04 05:44:44 +0000 URL: https://git.openjdk.org/loom/commit/7b894bc4afa96bc04f0d58042f69becadb573e20 8332786: When dumping static CDS archives, explicitly assert that we don't use a CDS archive Reviewed-by: iklam, dholmes ! src/hotspot/share/cds/metaspaceShared.cpp Changeset: 38a578d5 Author: Thomas Stuefe Date: 2024-07-04 06:20:03 +0000 URL: https://git.openjdk.org/loom/commit/38a578d547f39c3637d97f5e0242f4a69f3bbb31 8334738: os::print_hex_dump should optionally print ASCII Reviewed-by: dholmes, sgehwolf ! src/hotspot/os_cpu/windows_aarch64/os_windows_aarch64.cpp ! src/hotspot/share/cds/archiveBuilder.cpp ! src/hotspot/share/runtime/os.cpp ! src/hotspot/share/runtime/os.hpp ! src/hotspot/share/utilities/globalDefinitions.hpp ! src/hotspot/share/utilities/ostream.hpp ! test/hotspot/gtest/runtime/test_os.cpp Changeset: b20e8c8e Author: Axel Boldt-Christmas Date: 2024-07-04 08:21:18 +0000 URL: https://git.openjdk.org/loom/commit/b20e8c8e85e0a0e96ae648f42ff803f1c83f6291 8335397: Improve reliability of TestRecursiveMonitorChurn.java Reviewed-by: coleenp, rkennke, dholmes ! src/hotspot/share/prims/whitebox.cpp ! src/hotspot/share/prims/whitebox.hpp ! src/hotspot/share/runtime/synchronizer.hpp ! test/hotspot/jtreg/runtime/locking/TestRecursiveMonitorChurn.java ! test/lib/jdk/test/whitebox/WhiteBox.java Changeset: 3e3f83f6 Author: Jan Lahoda Date: 2024-07-04 08:36:56 +0000 URL: https://git.openjdk.org/loom/commit/3e3f83f62c67caf960ca031439b022f915e1102a 8335385: javac crash on unattributed piece of AST Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java ! test/langtools/tools/javac/importscope/BadClassFileDuringImport.java + test/langtools/tools/javac/tree/ASTAttributesFilledForReferencesOnMissingTypes.java Changeset: 0bb9c762 Author: Erik Gahlin Date: 2024-07-04 10:03:39 +0000 URL: https://git.openjdk.org/loom/commit/0bb9c76288b5f63fe965c3276bb566cef5f51c50 8324089: Fix typo in the manual page for "jcmd" (man jcmd) Reviewed-by: mgronlun, kevinw ! src/jdk.jcmd/share/man/jcmd.1 Changeset: cf1be872 Author: Kim Barrett Date: 2024-07-04 10:04:52 +0000 URL: https://git.openjdk.org/loom/commit/cf1be87279ddfb2a9fd272e0b245fccd7ec10972 8335663: Fix simple -Wzero-as-null-pointer-constant warnings in C2 code Reviewed-by: jwaters, chagedorn ! src/hotspot/share/opto/block.hpp ! src/hotspot/share/opto/cfgnode.hpp ! src/hotspot/share/opto/constantTable.hpp ! src/hotspot/share/opto/machnode.hpp Changeset: c0604fb8 Author: Erik ?sterlund Date: 2024-07-04 10:06:09 +0000 URL: https://git.openjdk.org/loom/commit/c0604fb823d9f3b2e347a9857b11606b223ad8ec 8334890: Missing unconditional cross modifying fence in nmethod entry barriers Reviewed-by: aboldtch, kbarrett ! src/hotspot/share/gc/shared/barrierSetNMethod.cpp Changeset: 916db07e Author: Yudi Zheng Date: 2024-07-04 10:34:56 +0000 URL: https://git.openjdk.org/loom/commit/916db07e533cdc0fca2010751f7ebe54e6ada7b9 8335532: [JVMCI] Export VM_Version::L1_line_size in JVMCI Reviewed-by: dnsimon ! src/hotspot/share/jvmci/jvmciCompilerToVM.hpp ! src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp ! src/hotspot/share/jvmci/vmStructs_jvmci.cpp Changeset: ced99066 Author: Joachim Kern Date: 2024-07-04 11:20:57 +0000 URL: https://git.openjdk.org/loom/commit/ced99066354fc6a32c587b9e3c35b07e26d3452e 8334371: [AIX] Beginning with AIX 7.3 TL1 mmap() supports 64K memory pages Reviewed-by: stuefe, mbaesken, mdoerr ! src/hotspot/os/aix/os_aix.cpp ! src/hotspot/os/aix/os_aix.hpp ! src/hotspot/share/memory/virtualspace.cpp ! src/hotspot/share/runtime/os.cpp ! test/hotspot/gtest/runtime/test_os.cpp + test/hotspot/gtest/runtime/test_os_aix.cpp Changeset: 7e378fcc Author: Kim Barrett Date: 2024-07-04 12:16:54 +0000 URL: https://git.openjdk.org/loom/commit/7e378fccd8a4601c8b8e86aa2862c61e469c3a04 8335667: Fix simple -Wzero-as-null-pointer-constant warnings in compiler code Reviewed-by: chagedorn ! src/hotspot/share/ci/ciStreams.hpp ! src/hotspot/share/code/exceptionHandlerTable.hpp Changeset: 6a472797 Author: Nizar Benalla Committer: Aleksei Efimov Date: 2024-07-04 12:29:32 +0000 URL: https://git.openjdk.org/loom/commit/6a472797a410a6fa27f50371b255054af0cd3c99 8332072: Convert package.html files in `java.naming` to package-info.java 8335213: Code snippet in javax.naming.ldap package summary does not compile Reviewed-by: aefimov + src/java.naming/share/classes/javax/naming/directory/package-info.java - src/java.naming/share/classes/javax/naming/directory/package.html + src/java.naming/share/classes/javax/naming/event/package-info.java - src/java.naming/share/classes/javax/naming/event/package.html + src/java.naming/share/classes/javax/naming/ldap/package-info.java - src/java.naming/share/classes/javax/naming/ldap/package.html + src/java.naming/share/classes/javax/naming/ldap/spi/package-info.java + src/java.naming/share/classes/javax/naming/package-info.java - src/java.naming/share/classes/javax/naming/package.html + src/java.naming/share/classes/javax/naming/spi/package-info.java - src/java.naming/share/classes/javax/naming/spi/package.html Changeset: b0efd774 Author: Thomas Stuefe Date: 2024-07-04 12:42:47 +0000 URL: https://git.openjdk.org/loom/commit/b0efd7740243916ba22178524ab2ede9e5436d94 8314653: Metaspace: remove allocation guard feature Reviewed-by: azafari, dholmes ! src/hotspot/share/memory/metaspace/metaspaceArena.cpp ! src/hotspot/share/memory/metaspace/metaspaceArena.hpp ! src/hotspot/share/memory/metaspace/metaspaceSettings.cpp ! src/hotspot/share/memory/metaspace/metaspaceSettings.hpp ! src/hotspot/share/runtime/globals.hpp - test/hotspot/gtest/metaspace/test_allocationGuard.cpp ! test/hotspot/gtest/metaspace/test_metaspacearena.cpp ! test/hotspot/gtest/metaspace/test_metaspacearena_stress.cpp ! test/hotspot/jtreg/gtest/MetaspaceGtests.java ! test/hotspot/jtreg/runtime/Metaspace/PrintMetaspaceDcmd.java ! test/hotspot/jtreg/runtime/Metaspace/elastic/MetaspaceTestContext.java ! test/hotspot/jtreg/runtime/Metaspace/elastic/Settings.java ! test/hotspot/jtreg/runtime/Metaspace/elastic/TestMetaspaceAllocation.java ! test/hotspot/jtreg/runtime/Metaspace/elastic/TestMetaspaceAllocationMT1.java ! test/hotspot/jtreg/runtime/Metaspace/elastic/TestMetaspaceAllocationMT2.java Changeset: da0ffa8b Author: Robert Toyonaga Committer: Thomas Stuefe Date: 2024-07-04 13:35:24 +0000 URL: https://git.openjdk.org/loom/commit/da0ffa8b7ff04eb5cbc0fcbe4b858f20d7e46405 8334031: Generated JfrNativeSettings seems off Reviewed-by: egahlin ! make/src/classes/build/tools/jfr/GenerateJfrFiles.java Changeset: 3050ba01 Author: Jasmine Karthikeyan Date: 2024-07-04 14:09:45 +0000 URL: https://git.openjdk.org/loom/commit/3050ba017687ac13e1bbccdd1544d25f8eb2a747 8335654: Remove stale hyperlink in divnode.cpp Reviewed-by: chagedorn, thartmann ! src/hotspot/share/opto/divnode.cpp Changeset: f4fa35e2 Author: Nizar Benalla Committer: Chen Liang Date: 2024-07-04 15:44:57 +0000 URL: https://git.openjdk.org/loom/commit/f4fa35e28b9881729ac47c8518e758bba676fdec 8330954: since-checker - Fix remaining @ since tags in java.base Reviewed-by: liach, naoto ! src/java.base/share/classes/java/io/FileInputStream.java ! src/java.base/share/classes/java/lang/classfile/ClassSignature.java ! src/java.base/share/classes/java/lang/constant/ClassDesc.java ! src/java.base/share/classes/java/lang/constant/MethodHandleDesc.java ! src/java.base/share/classes/java/lang/constant/MethodTypeDesc.java ! src/java.base/share/classes/java/lang/foreign/MemorySegment.java ! src/java.base/share/classes/java/lang/ref/Reference.java ! src/java.base/share/classes/java/text/ChoiceFormat.java ! src/java.base/share/classes/java/util/concurrent/CompletableFuture.java ! src/java.base/share/classes/java/util/concurrent/DelayQueue.java ! src/java.base/share/classes/java/util/concurrent/ForkJoinTask.java ! src/java.base/share/classes/java/util/concurrent/FutureTask.java Changeset: cff9e246 Author: Liang Mao Committer: Denghui Dong Date: 2024-07-05 02:29:07 +0000 URL: https://git.openjdk.org/loom/commit/cff9e246cc2fbd3914f40bb71daa85dcf7731396 8335493: check_gc_overhead_limit should reset SoftRefPolicy::_should_clear_all_soft_refs Reviewed-by: ayang ! src/hotspot/share/gc/shared/gcOverheadChecker.cpp Changeset: b9d8056d Author: Sonia Zaldana Calles Date: 2024-07-05 04:49:01 +0000 URL: https://git.openjdk.org/loom/commit/b9d8056d5c1528198ad373f9b4a09547e2fcabd6 8332124: Jcmd should recognise options that look like requests for help Reviewed-by: kevinw, stuefe ! src/hotspot/share/services/diagnosticFramework.cpp ! src/hotspot/share/services/diagnosticFramework.hpp + test/jdk/sun/tools/jcmd/TestJcmdSubcommandHelp.java Changeset: 4ec1ae10 Author: Thomas Schatzl Date: 2024-07-05 07:18:34 +0000 URL: https://git.openjdk.org/loom/commit/4ec1ae109710aa150e27acf5706475d335c4655c 8331385: G1: Prefix HeapRegion helper classes with G1 Reviewed-by: ayang, dholmes ! src/hotspot/share/gc/g1/g1Arguments.cpp ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1CollectedHeap.hpp ! src/hotspot/share/gc/g1/g1CollectionSet.cpp ! src/hotspot/share/gc/g1/g1CollectionSet.hpp ! src/hotspot/share/gc/g1/g1CollectionSetCandidates.hpp ! src/hotspot/share/gc/g1/g1CollectionSetChooser.cpp ! src/hotspot/share/gc/g1/g1CommittedRegionMap.cpp ! src/hotspot/share/gc/g1/g1CommittedRegionMap.hpp ! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp ! src/hotspot/share/gc/g1/g1ConcurrentMark.hpp ! src/hotspot/share/gc/g1/g1ConcurrentRebuildAndScrub.cpp ! src/hotspot/share/gc/g1/g1ConcurrentRefine.cpp ! src/hotspot/share/gc/g1/g1EvacFailureRegions.cpp ! src/hotspot/share/gc/g1/g1EvacFailureRegions.hpp ! src/hotspot/share/gc/g1/g1FullCollector.cpp ! src/hotspot/share/gc/g1/g1FullGCAdjustTask.cpp ! src/hotspot/share/gc/g1/g1FullGCAdjustTask.hpp ! src/hotspot/share/gc/g1/g1FullGCCompactTask.hpp ! src/hotspot/share/gc/g1/g1FullGCHeapRegionAttr.hpp ! src/hotspot/share/gc/g1/g1FullGCPrepareTask.hpp ! src/hotspot/share/gc/g1/g1FullGCResetMetadataTask.hpp ! src/hotspot/share/gc/g1/g1HeapRegion.cpp ! src/hotspot/share/gc/g1/g1HeapRegion.hpp ! src/hotspot/share/gc/g1/g1HeapRegionBounds.hpp ! src/hotspot/share/gc/g1/g1HeapRegionBounds.inline.hpp ! src/hotspot/share/gc/g1/g1HeapRegionEventSender.cpp ! src/hotspot/share/gc/g1/g1HeapRegionManager.cpp ! src/hotspot/share/gc/g1/g1HeapRegionManager.hpp ! src/hotspot/share/gc/g1/g1HeapRegionManager.inline.hpp ! src/hotspot/share/gc/g1/g1HeapRegionPrinter.hpp ! src/hotspot/share/gc/g1/g1HeapRegionRemSet.cpp ! src/hotspot/share/gc/g1/g1HeapRegionRemSet.hpp ! src/hotspot/share/gc/g1/g1HeapRegionRemSet.inline.hpp ! src/hotspot/share/gc/g1/g1HeapRegionSet.cpp ! src/hotspot/share/gc/g1/g1HeapRegionSet.hpp ! src/hotspot/share/gc/g1/g1HeapRegionSet.inline.hpp ! src/hotspot/share/gc/g1/g1HeapRegionTracer.cpp ! src/hotspot/share/gc/g1/g1HeapRegionTracer.hpp ! src/hotspot/share/gc/g1/g1HeapRegionType.cpp ! src/hotspot/share/gc/g1/g1HeapRegionType.hpp ! src/hotspot/share/gc/g1/g1HeapTransition.cpp ! src/hotspot/share/gc/g1/g1HeapVerifier.cpp ! src/hotspot/share/gc/g1/g1NUMA.cpp ! src/hotspot/share/gc/g1/g1NUMA.hpp ! src/hotspot/share/gc/g1/g1OopClosures.inline.hpp ! src/hotspot/share/gc/g1/g1RemSet.cpp ! src/hotspot/share/gc/g1/g1RemSet.hpp ! src/hotspot/share/gc/g1/g1RemSetSummary.cpp ! src/hotspot/share/gc/g1/g1YoungCollector.cpp ! src/hotspot/share/gc/g1/g1YoungGCAllocationFailureInjector.cpp ! src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.cpp ! src/hotspot/share/gc/g1/jvmFlagConstraintsG1.cpp ! src/hotspot/share/gc/g1/vmStructs_g1.hpp ! src/hotspot/share/prims/whitebox.cpp ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/G1CollectedHeap.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/G1HeapRegion.java + src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/G1HeapRegionClosure.java = src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/G1HeapRegionManager.java = src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/G1HeapRegionSetBase.java + src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/G1HeapRegionType.java = src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/G1PrintRegionClosure.java - src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/HeapRegionClosure.java - src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/HeapRegionType.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/HeapSummary.java ! test/hotspot/gtest/gc/g1/test_freeRegionList.cpp ! test/hotspot/gtest/gc/g1/test_g1CardSetContainers.cpp ! test/hotspot/gtest/gc/g1/test_g1RegionMap.cpp Changeset: 6409ec33 Author: Albert Mingkun Yang Date: 2024-07-05 08:43:27 +0000 URL: https://git.openjdk.org/loom/commit/6409ec336af647044d0746c219496ad070de5e9d 8335711: G1: Remove unused bot_updates argument in G1AllocRegion constructor Reviewed-by: iwalulya, tschatzl ! src/hotspot/share/gc/g1/g1AllocRegion.cpp ! src/hotspot/share/gc/g1/g1AllocRegion.hpp Changeset: bdf470b3 Author: Thomas Schatzl Date: 2024-07-05 09:06:37 +0000 URL: https://git.openjdk.org/loom/commit/bdf470b3b8f8814cb29f2877490d5bc1e79bdecb 8335742: Problemlist gc/g1/TestMixedGCLiveThreshold.java#25percent with virtual threads Reviewed-by: aboldtch, kbarrett ! test/hotspot/jtreg/ProblemList-Virtual.txt Changeset: c8acea87 Author: Ivan Walulya Date: 2024-07-05 09:10:30 +0000 URL: https://git.openjdk.org/loom/commit/c8acea87e2c5ba6672c011ec4e57a53c55fee74b 8335706: G1: Remove unused G1ConcurrentRefine::RemSetSamplingClosure::_cset Reviewed-by: ayang, tschatzl ! src/hotspot/share/gc/g1/g1ConcurrentRefine.cpp Changeset: 194425d7 Author: Shaojin Wen Committer: Chen Liang Date: 2024-07-05 12:50:09 +0000 URL: https://git.openjdk.org/loom/commit/194425d7875ef42fce52516ed59c81ee97720399 8335645: j.u.Formatter#trailingZeros improved with String repeat Reviewed-by: liach, jlu, naoto ! src/java.base/share/classes/java/util/Formatter.java Changeset: ff49f677 Author: Severin Gehwolf Date: 2024-07-05 13:44:35 +0000 URL: https://git.openjdk.org/loom/commit/ff49f677ee5017019c90823bc412ceb90068ffbd 8335775: Remove extraneous 's' in comment of rawmonitor.cpp test file Reviewed-by: gdams, stuefe ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/functions/rawmonitor/rawmonitor.cpp Changeset: 7efe1603 Author: Erik Gahlin Date: 2024-07-05 16:44:41 +0000 URL: https://git.openjdk.org/loom/commit/7efe16038e5df9894a265ea1214068060f595c4e 8335730: JFR: Clean up jdk.jfr Reviewed-by: mgronlun ! src/jdk.jfr/share/classes/jdk/jfr/consumer/RecordedClass.java ! src/jdk.jfr/share/classes/jdk/jfr/consumer/RecordedFrame.java ! src/jdk.jfr/share/classes/jdk/jfr/consumer/RecordedMethod.java ! src/jdk.jfr/share/classes/jdk/jfr/consumer/RecordedObject.java ! src/jdk.jfr/share/classes/jdk/jfr/consumer/RecordedThread.java ! src/jdk.jfr/share/classes/jdk/jfr/events/AbstractBufferStatisticsEvent.java ! src/jdk.jfr/share/classes/jdk/jfr/events/ActiveRecordingEvent.java ! src/jdk.jfr/share/classes/jdk/jfr/events/ActiveSettingEvent.java ! src/jdk.jfr/share/classes/jdk/jfr/events/ExceptionStatisticsEvent.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/EventControl.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/MetadataRepository.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/OldObjectSample.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/RepositoryChunk.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/ShutdownHook.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/dcmd/QueryRecording.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/jfc/JFC.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/jfc/model/XmlSetting.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/query/Row.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/query/TableSorter.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/settings/LevelSetting.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/tool/Disassemble.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/tool/PrettyWriter.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/tool/View.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/util/ValueParser.java Changeset: b83766e5 Author: Erik Gahlin Date: 2024-07-05 17:07:22 +0000 URL: https://git.openjdk.org/loom/commit/b83766e59063a41ea8801ac9e7c15dce67727c62 8335632: jdk/jfr/api/consumer/streaming/TestJVMExit.java failed with "Process [...] is no longer alive" Reviewed-by: mgronlun ! test/jdk/jdk/jfr/api/consumer/streaming/TestJVMExit.java Changeset: 80447069 Author: Patricio Chilano Mateo Date: 2024-07-05 16:54:50 +0000 URL: https://git.openjdk.org/loom/commit/80447069109693e98ea75edf7aded30f8536bac5 Merge branch 'master' into fibers ! src/hotspot/share/jvmci/vmStructs_jvmci.cpp ! src/hotspot/share/runtime/globals.hpp ! src/hotspot/share/runtime/synchronizer.hpp ! src/hotspot/share/utilities/globalDefinitions.hpp ! test/hotspot/jtreg/ProblemList-Virtual.txt ! test/hotspot/jtreg/ProblemList.txt ! src/hotspot/share/jvmci/vmStructs_jvmci.cpp ! src/hotspot/share/runtime/globals.hpp ! src/hotspot/share/runtime/synchronizer.hpp ! src/hotspot/share/utilities/globalDefinitions.hpp ! test/hotspot/jtreg/ProblemList-Virtual.txt ! test/hotspot/jtreg/ProblemList.txt Changeset: 4ffb1790 Author: Patricio Chilano Mateo Date: 2024-07-05 19:18:04 +0000 URL: https://git.openjdk.org/loom/commit/4ffb179059bcd1909e4ab21b1cc5a4ac602d847b avoid pre/post mistmatch by inflating ahead of WB.getInUseMonitorCount() ! test/hotspot/jtreg/runtime/locking/TestRecursiveMonitorChurn.java From duke at openjdk.org Sat Jul 6 01:13:48 2024 From: duke at openjdk.org (duke) Date: Sat, 6 Jul 2024 01:13:48 GMT Subject: git: openjdk/loom: master: 29 new changesets Message-ID: Changeset: 68ffec98 Author: Erik Gahlin Date: 2024-07-03 20:43:08 +0000 URL: https://git.openjdk.org/loom/commit/68ffec9800b798927a050900a2d47000aa18ef30 8335479: JFR: Missing documentation for -XX:StartFlightRecording Reviewed-by: mgronlun ! src/java.base/share/man/java.1 Changeset: 587535c5 Author: David Holmes Date: 2024-07-03 21:42:08 +0000 URL: https://git.openjdk.org/loom/commit/587535c5b9bb258836b47c3a8c41ffb91bbfc131 8334545: runtime/ClassInitErrors/TestStackOverflowDuringInit.java fails after JDK-8294960 Reviewed-by: iklam, stuefe ! test/hotspot/jtreg/ProblemList.txt ! test/hotspot/jtreg/runtime/ClassInitErrors/TestStackOverflowDuringInit.java Changeset: 3efa93ba Author: Kim Barrett Date: 2024-07-03 22:03:23 +0000 URL: https://git.openjdk.org/loom/commit/3efa93ba1307cedf05609c0c04b2ba986a515f6e 8335588: Fix -Wzero-as-null-pointer-constant warnings in calls to Node ctor Reviewed-by: thartmann, chagedorn ! src/hotspot/share/opto/addnode.hpp ! src/hotspot/share/opto/convertnode.hpp ! src/hotspot/share/opto/countbitsnode.hpp ! src/hotspot/share/opto/intrinsicnode.hpp ! src/hotspot/share/opto/loopnode.hpp ! src/hotspot/share/opto/memnode.hpp ! src/hotspot/share/opto/movenode.hpp ! src/hotspot/share/opto/mulnode.hpp ! src/hotspot/share/opto/opaquenode.hpp ! src/hotspot/share/opto/subnode.hpp Changeset: e01626cf Author: David Holmes Date: 2024-07-04 04:18:31 +0000 URL: https://git.openjdk.org/loom/commit/e01626cf09850f7b0af33cdb905ca8992266fe5b 8335655: ProblemList serviceability/dcmd/vm tests failing after JDK-8322475 Reviewed-by: mikael ! test/hotspot/jtreg/ProblemList-generational-zgc.txt ! test/hotspot/jtreg/ProblemList-zgc.txt Changeset: 7b894bc4 Author: Thomas Stuefe Date: 2024-07-04 05:44:44 +0000 URL: https://git.openjdk.org/loom/commit/7b894bc4afa96bc04f0d58042f69becadb573e20 8332786: When dumping static CDS archives, explicitly assert that we don't use a CDS archive Reviewed-by: iklam, dholmes ! src/hotspot/share/cds/metaspaceShared.cpp Changeset: 38a578d5 Author: Thomas Stuefe Date: 2024-07-04 06:20:03 +0000 URL: https://git.openjdk.org/loom/commit/38a578d547f39c3637d97f5e0242f4a69f3bbb31 8334738: os::print_hex_dump should optionally print ASCII Reviewed-by: dholmes, sgehwolf ! src/hotspot/os_cpu/windows_aarch64/os_windows_aarch64.cpp ! src/hotspot/share/cds/archiveBuilder.cpp ! src/hotspot/share/runtime/os.cpp ! src/hotspot/share/runtime/os.hpp ! src/hotspot/share/utilities/globalDefinitions.hpp ! src/hotspot/share/utilities/ostream.hpp ! test/hotspot/gtest/runtime/test_os.cpp Changeset: b20e8c8e Author: Axel Boldt-Christmas Date: 2024-07-04 08:21:18 +0000 URL: https://git.openjdk.org/loom/commit/b20e8c8e85e0a0e96ae648f42ff803f1c83f6291 8335397: Improve reliability of TestRecursiveMonitorChurn.java Reviewed-by: coleenp, rkennke, dholmes ! src/hotspot/share/prims/whitebox.cpp ! src/hotspot/share/prims/whitebox.hpp ! src/hotspot/share/runtime/synchronizer.hpp ! test/hotspot/jtreg/runtime/locking/TestRecursiveMonitorChurn.java ! test/lib/jdk/test/whitebox/WhiteBox.java Changeset: 3e3f83f6 Author: Jan Lahoda Date: 2024-07-04 08:36:56 +0000 URL: https://git.openjdk.org/loom/commit/3e3f83f62c67caf960ca031439b022f915e1102a 8335385: javac crash on unattributed piece of AST Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java ! test/langtools/tools/javac/importscope/BadClassFileDuringImport.java + test/langtools/tools/javac/tree/ASTAttributesFilledForReferencesOnMissingTypes.java Changeset: 0bb9c762 Author: Erik Gahlin Date: 2024-07-04 10:03:39 +0000 URL: https://git.openjdk.org/loom/commit/0bb9c76288b5f63fe965c3276bb566cef5f51c50 8324089: Fix typo in the manual page for "jcmd" (man jcmd) Reviewed-by: mgronlun, kevinw ! src/jdk.jcmd/share/man/jcmd.1 Changeset: cf1be872 Author: Kim Barrett Date: 2024-07-04 10:04:52 +0000 URL: https://git.openjdk.org/loom/commit/cf1be87279ddfb2a9fd272e0b245fccd7ec10972 8335663: Fix simple -Wzero-as-null-pointer-constant warnings in C2 code Reviewed-by: jwaters, chagedorn ! src/hotspot/share/opto/block.hpp ! src/hotspot/share/opto/cfgnode.hpp ! src/hotspot/share/opto/constantTable.hpp ! src/hotspot/share/opto/machnode.hpp Changeset: c0604fb8 Author: Erik ?sterlund Date: 2024-07-04 10:06:09 +0000 URL: https://git.openjdk.org/loom/commit/c0604fb823d9f3b2e347a9857b11606b223ad8ec 8334890: Missing unconditional cross modifying fence in nmethod entry barriers Reviewed-by: aboldtch, kbarrett ! src/hotspot/share/gc/shared/barrierSetNMethod.cpp Changeset: 916db07e Author: Yudi Zheng Date: 2024-07-04 10:34:56 +0000 URL: https://git.openjdk.org/loom/commit/916db07e533cdc0fca2010751f7ebe54e6ada7b9 8335532: [JVMCI] Export VM_Version::L1_line_size in JVMCI Reviewed-by: dnsimon ! src/hotspot/share/jvmci/jvmciCompilerToVM.hpp ! src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp ! src/hotspot/share/jvmci/vmStructs_jvmci.cpp Changeset: ced99066 Author: Joachim Kern Date: 2024-07-04 11:20:57 +0000 URL: https://git.openjdk.org/loom/commit/ced99066354fc6a32c587b9e3c35b07e26d3452e 8334371: [AIX] Beginning with AIX 7.3 TL1 mmap() supports 64K memory pages Reviewed-by: stuefe, mbaesken, mdoerr ! src/hotspot/os/aix/os_aix.cpp ! src/hotspot/os/aix/os_aix.hpp ! src/hotspot/share/memory/virtualspace.cpp ! src/hotspot/share/runtime/os.cpp ! test/hotspot/gtest/runtime/test_os.cpp + test/hotspot/gtest/runtime/test_os_aix.cpp Changeset: 7e378fcc Author: Kim Barrett Date: 2024-07-04 12:16:54 +0000 URL: https://git.openjdk.org/loom/commit/7e378fccd8a4601c8b8e86aa2862c61e469c3a04 8335667: Fix simple -Wzero-as-null-pointer-constant warnings in compiler code Reviewed-by: chagedorn ! src/hotspot/share/ci/ciStreams.hpp ! src/hotspot/share/code/exceptionHandlerTable.hpp Changeset: 6a472797 Author: Nizar Benalla Committer: Aleksei Efimov Date: 2024-07-04 12:29:32 +0000 URL: https://git.openjdk.org/loom/commit/6a472797a410a6fa27f50371b255054af0cd3c99 8332072: Convert package.html files in `java.naming` to package-info.java 8335213: Code snippet in javax.naming.ldap package summary does not compile Reviewed-by: aefimov + src/java.naming/share/classes/javax/naming/directory/package-info.java - src/java.naming/share/classes/javax/naming/directory/package.html + src/java.naming/share/classes/javax/naming/event/package-info.java - src/java.naming/share/classes/javax/naming/event/package.html + src/java.naming/share/classes/javax/naming/ldap/package-info.java - src/java.naming/share/classes/javax/naming/ldap/package.html + src/java.naming/share/classes/javax/naming/ldap/spi/package-info.java + src/java.naming/share/classes/javax/naming/package-info.java - src/java.naming/share/classes/javax/naming/package.html + src/java.naming/share/classes/javax/naming/spi/package-info.java - src/java.naming/share/classes/javax/naming/spi/package.html Changeset: b0efd774 Author: Thomas Stuefe Date: 2024-07-04 12:42:47 +0000 URL: https://git.openjdk.org/loom/commit/b0efd7740243916ba22178524ab2ede9e5436d94 8314653: Metaspace: remove allocation guard feature Reviewed-by: azafari, dholmes ! src/hotspot/share/memory/metaspace/metaspaceArena.cpp ! src/hotspot/share/memory/metaspace/metaspaceArena.hpp ! src/hotspot/share/memory/metaspace/metaspaceSettings.cpp ! src/hotspot/share/memory/metaspace/metaspaceSettings.hpp ! src/hotspot/share/runtime/globals.hpp - test/hotspot/gtest/metaspace/test_allocationGuard.cpp ! test/hotspot/gtest/metaspace/test_metaspacearena.cpp ! test/hotspot/gtest/metaspace/test_metaspacearena_stress.cpp ! test/hotspot/jtreg/gtest/MetaspaceGtests.java ! test/hotspot/jtreg/runtime/Metaspace/PrintMetaspaceDcmd.java ! test/hotspot/jtreg/runtime/Metaspace/elastic/MetaspaceTestContext.java ! test/hotspot/jtreg/runtime/Metaspace/elastic/Settings.java ! test/hotspot/jtreg/runtime/Metaspace/elastic/TestMetaspaceAllocation.java ! test/hotspot/jtreg/runtime/Metaspace/elastic/TestMetaspaceAllocationMT1.java ! test/hotspot/jtreg/runtime/Metaspace/elastic/TestMetaspaceAllocationMT2.java Changeset: da0ffa8b Author: Robert Toyonaga Committer: Thomas Stuefe Date: 2024-07-04 13:35:24 +0000 URL: https://git.openjdk.org/loom/commit/da0ffa8b7ff04eb5cbc0fcbe4b858f20d7e46405 8334031: Generated JfrNativeSettings seems off Reviewed-by: egahlin ! make/src/classes/build/tools/jfr/GenerateJfrFiles.java Changeset: 3050ba01 Author: Jasmine Karthikeyan Date: 2024-07-04 14:09:45 +0000 URL: https://git.openjdk.org/loom/commit/3050ba017687ac13e1bbccdd1544d25f8eb2a747 8335654: Remove stale hyperlink in divnode.cpp Reviewed-by: chagedorn, thartmann ! src/hotspot/share/opto/divnode.cpp Changeset: f4fa35e2 Author: Nizar Benalla Committer: Chen Liang Date: 2024-07-04 15:44:57 +0000 URL: https://git.openjdk.org/loom/commit/f4fa35e28b9881729ac47c8518e758bba676fdec 8330954: since-checker - Fix remaining @ since tags in java.base Reviewed-by: liach, naoto ! src/java.base/share/classes/java/io/FileInputStream.java ! src/java.base/share/classes/java/lang/classfile/ClassSignature.java ! src/java.base/share/classes/java/lang/constant/ClassDesc.java ! src/java.base/share/classes/java/lang/constant/MethodHandleDesc.java ! src/java.base/share/classes/java/lang/constant/MethodTypeDesc.java ! src/java.base/share/classes/java/lang/foreign/MemorySegment.java ! src/java.base/share/classes/java/lang/ref/Reference.java ! src/java.base/share/classes/java/text/ChoiceFormat.java ! src/java.base/share/classes/java/util/concurrent/CompletableFuture.java ! src/java.base/share/classes/java/util/concurrent/DelayQueue.java ! src/java.base/share/classes/java/util/concurrent/ForkJoinTask.java ! src/java.base/share/classes/java/util/concurrent/FutureTask.java Changeset: cff9e246 Author: Liang Mao Committer: Denghui Dong Date: 2024-07-05 02:29:07 +0000 URL: https://git.openjdk.org/loom/commit/cff9e246cc2fbd3914f40bb71daa85dcf7731396 8335493: check_gc_overhead_limit should reset SoftRefPolicy::_should_clear_all_soft_refs Reviewed-by: ayang ! src/hotspot/share/gc/shared/gcOverheadChecker.cpp Changeset: b9d8056d Author: Sonia Zaldana Calles Date: 2024-07-05 04:49:01 +0000 URL: https://git.openjdk.org/loom/commit/b9d8056d5c1528198ad373f9b4a09547e2fcabd6 8332124: Jcmd should recognise options that look like requests for help Reviewed-by: kevinw, stuefe ! src/hotspot/share/services/diagnosticFramework.cpp ! src/hotspot/share/services/diagnosticFramework.hpp + test/jdk/sun/tools/jcmd/TestJcmdSubcommandHelp.java Changeset: 4ec1ae10 Author: Thomas Schatzl Date: 2024-07-05 07:18:34 +0000 URL: https://git.openjdk.org/loom/commit/4ec1ae109710aa150e27acf5706475d335c4655c 8331385: G1: Prefix HeapRegion helper classes with G1 Reviewed-by: ayang, dholmes ! src/hotspot/share/gc/g1/g1Arguments.cpp ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1CollectedHeap.hpp ! src/hotspot/share/gc/g1/g1CollectionSet.cpp ! src/hotspot/share/gc/g1/g1CollectionSet.hpp ! src/hotspot/share/gc/g1/g1CollectionSetCandidates.hpp ! src/hotspot/share/gc/g1/g1CollectionSetChooser.cpp ! src/hotspot/share/gc/g1/g1CommittedRegionMap.cpp ! src/hotspot/share/gc/g1/g1CommittedRegionMap.hpp ! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp ! src/hotspot/share/gc/g1/g1ConcurrentMark.hpp ! src/hotspot/share/gc/g1/g1ConcurrentRebuildAndScrub.cpp ! src/hotspot/share/gc/g1/g1ConcurrentRefine.cpp ! src/hotspot/share/gc/g1/g1EvacFailureRegions.cpp ! src/hotspot/share/gc/g1/g1EvacFailureRegions.hpp ! src/hotspot/share/gc/g1/g1FullCollector.cpp ! src/hotspot/share/gc/g1/g1FullGCAdjustTask.cpp ! src/hotspot/share/gc/g1/g1FullGCAdjustTask.hpp ! src/hotspot/share/gc/g1/g1FullGCCompactTask.hpp ! src/hotspot/share/gc/g1/g1FullGCHeapRegionAttr.hpp ! src/hotspot/share/gc/g1/g1FullGCPrepareTask.hpp ! src/hotspot/share/gc/g1/g1FullGCResetMetadataTask.hpp ! src/hotspot/share/gc/g1/g1HeapRegion.cpp ! src/hotspot/share/gc/g1/g1HeapRegion.hpp ! src/hotspot/share/gc/g1/g1HeapRegionBounds.hpp ! src/hotspot/share/gc/g1/g1HeapRegionBounds.inline.hpp ! src/hotspot/share/gc/g1/g1HeapRegionEventSender.cpp ! src/hotspot/share/gc/g1/g1HeapRegionManager.cpp ! src/hotspot/share/gc/g1/g1HeapRegionManager.hpp ! src/hotspot/share/gc/g1/g1HeapRegionManager.inline.hpp ! src/hotspot/share/gc/g1/g1HeapRegionPrinter.hpp ! src/hotspot/share/gc/g1/g1HeapRegionRemSet.cpp ! src/hotspot/share/gc/g1/g1HeapRegionRemSet.hpp ! src/hotspot/share/gc/g1/g1HeapRegionRemSet.inline.hpp ! src/hotspot/share/gc/g1/g1HeapRegionSet.cpp ! src/hotspot/share/gc/g1/g1HeapRegionSet.hpp ! src/hotspot/share/gc/g1/g1HeapRegionSet.inline.hpp ! src/hotspot/share/gc/g1/g1HeapRegionTracer.cpp ! src/hotspot/share/gc/g1/g1HeapRegionTracer.hpp ! src/hotspot/share/gc/g1/g1HeapRegionType.cpp ! src/hotspot/share/gc/g1/g1HeapRegionType.hpp ! src/hotspot/share/gc/g1/g1HeapTransition.cpp ! src/hotspot/share/gc/g1/g1HeapVerifier.cpp ! src/hotspot/share/gc/g1/g1NUMA.cpp ! src/hotspot/share/gc/g1/g1NUMA.hpp ! src/hotspot/share/gc/g1/g1OopClosures.inline.hpp ! src/hotspot/share/gc/g1/g1RemSet.cpp ! src/hotspot/share/gc/g1/g1RemSet.hpp ! src/hotspot/share/gc/g1/g1RemSetSummary.cpp ! src/hotspot/share/gc/g1/g1YoungCollector.cpp ! src/hotspot/share/gc/g1/g1YoungGCAllocationFailureInjector.cpp ! src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.cpp ! src/hotspot/share/gc/g1/jvmFlagConstraintsG1.cpp ! src/hotspot/share/gc/g1/vmStructs_g1.hpp ! src/hotspot/share/prims/whitebox.cpp ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/G1CollectedHeap.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/G1HeapRegion.java + src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/G1HeapRegionClosure.java = src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/G1HeapRegionManager.java = src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/G1HeapRegionSetBase.java + src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/G1HeapRegionType.java = src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/G1PrintRegionClosure.java - src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/HeapRegionClosure.java - src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/HeapRegionType.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/HeapSummary.java ! test/hotspot/gtest/gc/g1/test_freeRegionList.cpp ! test/hotspot/gtest/gc/g1/test_g1CardSetContainers.cpp ! test/hotspot/gtest/gc/g1/test_g1RegionMap.cpp Changeset: 6409ec33 Author: Albert Mingkun Yang Date: 2024-07-05 08:43:27 +0000 URL: https://git.openjdk.org/loom/commit/6409ec336af647044d0746c219496ad070de5e9d 8335711: G1: Remove unused bot_updates argument in G1AllocRegion constructor Reviewed-by: iwalulya, tschatzl ! src/hotspot/share/gc/g1/g1AllocRegion.cpp ! src/hotspot/share/gc/g1/g1AllocRegion.hpp Changeset: bdf470b3 Author: Thomas Schatzl Date: 2024-07-05 09:06:37 +0000 URL: https://git.openjdk.org/loom/commit/bdf470b3b8f8814cb29f2877490d5bc1e79bdecb 8335742: Problemlist gc/g1/TestMixedGCLiveThreshold.java#25percent with virtual threads Reviewed-by: aboldtch, kbarrett ! test/hotspot/jtreg/ProblemList-Virtual.txt Changeset: c8acea87 Author: Ivan Walulya Date: 2024-07-05 09:10:30 +0000 URL: https://git.openjdk.org/loom/commit/c8acea87e2c5ba6672c011ec4e57a53c55fee74b 8335706: G1: Remove unused G1ConcurrentRefine::RemSetSamplingClosure::_cset Reviewed-by: ayang, tschatzl ! src/hotspot/share/gc/g1/g1ConcurrentRefine.cpp Changeset: 194425d7 Author: Shaojin Wen Committer: Chen Liang Date: 2024-07-05 12:50:09 +0000 URL: https://git.openjdk.org/loom/commit/194425d7875ef42fce52516ed59c81ee97720399 8335645: j.u.Formatter#trailingZeros improved with String repeat Reviewed-by: liach, jlu, naoto ! src/java.base/share/classes/java/util/Formatter.java Changeset: ff49f677 Author: Severin Gehwolf Date: 2024-07-05 13:44:35 +0000 URL: https://git.openjdk.org/loom/commit/ff49f677ee5017019c90823bc412ceb90068ffbd 8335775: Remove extraneous 's' in comment of rawmonitor.cpp test file Reviewed-by: gdams, stuefe ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/functions/rawmonitor/rawmonitor.cpp Changeset: 7efe1603 Author: Erik Gahlin Date: 2024-07-05 16:44:41 +0000 URL: https://git.openjdk.org/loom/commit/7efe16038e5df9894a265ea1214068060f595c4e 8335730: JFR: Clean up jdk.jfr Reviewed-by: mgronlun ! src/jdk.jfr/share/classes/jdk/jfr/consumer/RecordedClass.java ! src/jdk.jfr/share/classes/jdk/jfr/consumer/RecordedFrame.java ! src/jdk.jfr/share/classes/jdk/jfr/consumer/RecordedMethod.java ! src/jdk.jfr/share/classes/jdk/jfr/consumer/RecordedObject.java ! src/jdk.jfr/share/classes/jdk/jfr/consumer/RecordedThread.java ! src/jdk.jfr/share/classes/jdk/jfr/events/AbstractBufferStatisticsEvent.java ! src/jdk.jfr/share/classes/jdk/jfr/events/ActiveRecordingEvent.java ! src/jdk.jfr/share/classes/jdk/jfr/events/ActiveSettingEvent.java ! src/jdk.jfr/share/classes/jdk/jfr/events/ExceptionStatisticsEvent.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/EventControl.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/MetadataRepository.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/OldObjectSample.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/RepositoryChunk.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/ShutdownHook.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/dcmd/QueryRecording.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/jfc/JFC.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/jfc/model/XmlSetting.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/query/Row.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/query/TableSorter.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/settings/LevelSetting.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/tool/Disassemble.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/tool/PrettyWriter.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/tool/View.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/util/ValueParser.java Changeset: b83766e5 Author: Erik Gahlin Date: 2024-07-05 17:07:22 +0000 URL: https://git.openjdk.org/loom/commit/b83766e59063a41ea8801ac9e7c15dce67727c62 8335632: jdk/jfr/api/consumer/streaming/TestJVMExit.java failed with "Process [...] is no longer alive" Reviewed-by: mgronlun ! test/jdk/jdk/jfr/api/consumer/streaming/TestJVMExit.java From robaho at icloud.com Sat Jul 6 03:18:24 2024 From: robaho at icloud.com (robert engels) Date: Fri, 5 Jul 2024 22:18:24 -0500 Subject: [External] : Re: Experience using virtual threads in EA 23-loom+4-102 In-Reply-To: References: Message-ID: I think if you review the current research that your assessment does not hold in the applied space. > On Jul 5, 2024, at 4:34?AM, Andrew Haley wrote: > > ?On 7/3/24 18:18, Sam Pullara wrote: >> As a developer trying to use this stuff, I 100% agree that fair is better. If I need something that isn't fair, I can do that myself. > > But fairness costs. There's a well-known branch of welfare economics > which studies the "Efficiency-Fairness Trade-off". The limiting case of > perfect fairness, where everybody gets the same, is that no one gets > anything. So it is with thread scheduling, too. We must choose a parameter > which is the degree of unfairness we'll tolerate, or conversely, the > reduction of efficiency we'll tolerate. > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > From matthew.swift at gmail.com Sat Jul 6 12:24:14 2024 From: matthew.swift at gmail.com (Matthew Swift) Date: Sat, 6 Jul 2024 14:24:14 +0200 Subject: Experience of adding JDK21 virtual thread support to a DB application In-Reply-To: <70AAB518-0B13-4611-B2F6-82938B81CE84@oracle.com> References: <70AAB518-0B13-4611-B2F6-82938B81CE84@oracle.com> Message-ID: Thanks for the great tip Ron. I had a look at how spinning is performed for Object monitors ( https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/objectMonitor.cpp#L1790) in order to get an idea of how much spinning should be performed before blocking. Judging by the adaptive heuristics, it's obviously quite a complex topic, especially in the general case. Despite that, I wondered if a fixed number of spin iterations would suffice in my specific use-case given that it is a single hot critical section with a well defined fixed length. Sure enough a few experiments revealed that spinning for 200-500 iterations seemed to get the best results for new and old multi-core hardware, so I now have performance back on a par with Object monitors. I will be able to revert back to using Object monitors once the recent monitor support has been officially released, because the Object monitor spin heuristics are more likely to work well across a wider range of hardware both now and in the future. Cheers, Matt On Sat, 29 Jun 2024 at 15:54, Ron Pressler wrote: > > > > On 21 Jun 2024, at 16:57, Matthew Swift wrote: > > > > I know that ReentrantLock is supposed to be a little bit less efficient > in highly contended situations, but I was surprised by an 8-10% impact. Is > that expected? > > > I wouldn?t say at all that it?s supposed to be slightly less efficient but > rather, as Alan mentioned, the behaviour of ReentrantLock and native > monitors is a little different ? monitors spin for a bit before blocking. > The reason this isn?t the default for ReentrantLock is that this may or may > not be what you want, depending on circumstance. However, the ReentrantLock > API supports adding spinning manually with a loop calling > ReentrantLock.tryLock in the condition and Thread.onSpinWait in the body. > > ? Ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.swift at gmail.com Sat Jul 6 18:20:35 2024 From: matthew.swift at gmail.com (Matthew Swift) Date: Sat, 6 Jul 2024 20:20:35 +0200 Subject: Experience using virtual threads in EA 23-loom+4-102 In-Reply-To: References: Message-ID: Thanks everyone for the helpful responses and continued discussion. Returning to my original message about high tail latencies when using virtual threads compared with platform threads, Viktor's response, in particular, prompted me to question whether I was missing something obvious. I fully agree that the high tail latencies are due to over saturation, but I still wanted to understand why the tail latencies were an order of magnitude worse when using virtual threads. I'm pleased to report (and slightly embarrassed!) that the cause of the bigger tail latencies is slightly more banal than subtle scheduling characteristics of the FJ pool, etc. As a reminder, the test involved a client sustaining 120[*] concurrent database transactions, each touching and locking over 400 DB records. The fixed size platform thread pool had 40 threads which had the effect of limiting concurrency to 40 simultaneous transactions. I naively swapped the platform thread pool for a virtual thread pool, which had the effect of removing the concurrency limits, allowing all 120 transactions to run concurrently and with a corresponding increase in lock thrashing / convoys. To test this I adjusted the platform thread pool to 120 threads and observed exactly the same high tail latencies that I saw with virtual threads. Conversely, the high tail latencies were reduced by an order of magnitude by throttling the writes using a Semaphore. In fact, I was able to reduce the P99.999 latency from over 10 seconds to 200ms with 20 permits, with no impact on P50. What's the conclusion here? In hindsight, the guidance in the section "Do not pool virtual threads" of JEP444 is pretty clear about using Semaphores for limiting concurrent access to limited resources. I think that the platform thread pool that we were using was using a small number of threads (e.g. 2 x #CPUs), as it was optimized for a mix of read txns (CPU bound, minimal locking) and write txns (low latency SSD IO, short lived record level locks), rather than high latency network IO. Thus, coincidentally, we never really observed significant lock thrashing related tail latencies and, therefore, didn't think we needed to limit concurrent access for writes. Cheers, Matt [*] I know virtual threads are intended for use cases involving thousands of concurrent requests. We see virtual threads as an opportunity for implementing features that may block threads for significant periods of time, such as fine grained rate limiting, distributed transactions and offloading password hashing to external microservices. Naturally, there will be a corresponding very significant increase in the number of concurrent requests. However, core functionality still needs to perform well and degrade gracefully, hence the test described in this thread. On Fri, 21 Jun 2024 at 19:05, Matthew Swift wrote: > Hello again, > > As promised, here is my second (shorter I hope!) email sharing feedback on > the recent Loom EA build (23-loom+4-102). If follows up on my previous > email https://mail.openjdk.org/pipermail/loom-dev/2024-June/006788.html. > > I performed some experiments using the same application described in my > previous email. However, in order to properly test the improvements to > Object monitors (synchronized blocks and Object.wait()) I reverted all of > the thread-pinning related changes that I had made in order to support > virtual threads with JDK21. Specifically, I reverted the changes converting > uses of monitors to ReentrantLock. > > I'm pleased to say that this EA build looks extremely promising! :-) > > ### Experiment #1: read stress test > > * platform threads: 215K/s throughput, CPU 14% idle > * virtual threads: 235K/s throughput, CPU 5% idle. > > Comment: there's a slight throughput improvement, but CPU utilization is > slightly higher too. Presumably this is due to the number of carrier > threads being closely matched to the number of CPUs (I noticed > significantly less context switching with v threads). > > ### Experiment #2: heavily indexed write stress test, with 40 clients > > * platform threads: 9300/s throughput, CPU 27% idle > * virtual threads: 8800/s throughput, CPU 24% idle. > > Comment: there is a ~5% performance degradation using virtual threads. > This is better than the degradation I observed in my previous email after > switching to ReentrantLock though. > > ### Experiment #3: extreme heavy indexed write stress test, with 120 > clients > > * platform threads: 1450/s throughput > * virtual threads: 1450/s throughput (i.e. about the same). > > Comment: > > This test is intended to stress the internal locking mechanisms as much as > possible and expose any pinning problems. > With JDK21 virtual threads the test would sometimes deadlock and thread > dumps would show 100+ fork join carrier threads. > This is no longer the case with the EA build. It looks really solid. > > This test does expose one important difference between platform threads > and virtual threads though. Let's take a look at the response times: > > Platform threads: > > > ------------------------------------------------------------------------------- > | Throughput | Response Time | > | > | (ops/second) | (milliseconds) | > | > | recent average | recent average 99.9% 99.99% 99.999% | > err/sec | > > ------------------------------------------------------------------------------- > ... > | 1442.6 1606.6 | 83.097 74.683 448.79 599.79 721.42 | > 0.0 | > | 1480.8 1594.0 | 81.125 75.282 442.50 599.79 721.42 | > 0.0 | > > Virtual threads: > > > ------------------------------------------------------------------------------- > | Throughput | Response Time | > | > | (ops/second) | (milliseconds) | > | > | recent average | recent average 99.9% 99.99% 99.999% | > err/sec | > > ------------------------------------------------------------------------------- > ... > | 1445.4 1645.3 | 81.375 72.623 3170.89 4798.28 8925.48 | > 0.0 | > | 1442.2 1625.0 | 81.047 73.371 3154.12 4798.28 6106.91 | > 0.0 | > > The outliers with virtual threads are much much higher. Could this be due > to potential starvation when rescheduling virtual threads in the fork join > pool? > > Cheers, > Matt > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron.pressler at oracle.com Sat Jul 6 20:23:58 2024 From: ron.pressler at oracle.com (Ron Pressler) Date: Sat, 6 Jul 2024 20:23:58 +0000 Subject: [External] : Re: Experience using virtual threads in EA 23-loom+4-102 In-Reply-To: <746D1DC1-D689-495A-ADC4-C6D8E465E39B@icloud.com> References: <07DDEEC5-688D-45A4-A651-CFDA38E3757C@oracle.com> <2B54EE29-CDD4-47A0-8178-27F8FE2AD39F@icloud.com> <052D6B72-3AD7-442C-99BB-87F1F183BB74@icloud.com> <746D1DC1-D689-495A-ADC4-C6D8E465E39B@icloud.com> Message-ID: <17A0ABBF-0ABD-4137-A269-D54CBCF3F51A@oracle.com> > On 4 Jul 2024, at 19:41, Robert Engels wrote: > >> >> Consider 100 tasks, each running for 1 CPU second on a 1 core machine (although it works the same way with any number of cores). With time-sharing, the average (and median) latency would be 100s. Without time sharing the average (and median) latency would be almost half that. > > > Yes, but the tail latency for timesharing is 100s. > > Without timesharing, the tail latency is more than 5000 secs - or an order of magnitude more. It would also be 100s. Time sharing makes things strictly worse in this case, and doesn?t even help tail latencies. > > I don?t have hard numbers, I can only look to why most OS?s use timeslicing, and why Go had to add it, and make an educated guess. OSes use timesharing for very different reasons than improving server workloads (and as far as we know ? it doesn?t), and Go added them because there are situations where time sharing is helpful, but Java offers an even better solution than adding time sharing in the virtual thread scheduler. In any event, there?s no point discussing the hypotheticals of scheduling. They are well known and fairly basic in this field. What isn?t well known is how common are server workloads where time sharing helps in practice. > > I am not saying this needs to change, but I think it needs to be better communicated to the community and what the ramifications are (e.g. atomic spin loops can deadlock the system). There are bigger problems than deadlocks if you use spin loops ? with or without time sharing ? when you have many thousands of threads. The most relevant thing to communicate, and we have, is that virtual threads? effectiveness stems from there being a very high number of them. Everything else follows. ? Ron From ron.pressler at oracle.com Sat Jul 6 20:28:54 2024 From: ron.pressler at oracle.com (Ron Pressler) Date: Sat, 6 Jul 2024 20:28:54 +0000 Subject: [External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: <8a3f069c-6a2b-476d-a948-a5c96d572fc6@gmail.com> References: <5A2E1F5D-9346-48B2-B6C8-3459FB6E32B0@oracle.com> <5C2E3DDB-6F90-44F8-9783-A2B2C77378AA@ix.netcom.com> <7196614D-E2FA-4492-BE1E-B2BB0B0DE1CE@oracle.com> <99B9907A-218C-46DF-B909-70EC39CEABAE@ix.netcom.com> <44E8FB97-4D46-4F3B-8C0C-13893A67EA9B@oracle.com> <0A2CC387-3B85-4C3F-8AEA-24B6FD1D9DB3@ix.netcom.com> <8a3f069c-6a2b-476d-a948-a5c96d572fc6@gmail.com> Message-ID: <8701CBF3-45A5-410A-9AEA-0AE31FA04649@oracle.com> > On 4 Jul 2024, at 21:34, Brian S O'Neill wrote: > > On 2024-07-04 11:43 AM, Ron Pressler wrote: >>> On 3 Jul 2024, at 18:27, robert engels wrote: >>> >>> I agree 100% - I am fighting that the auto-closing of the queues, clean-up, etc is ?unneeded magic? >> There is no auto-closing, no cleanup, and no magic. If a thread gets stuck in a state where it can never be observed or continued ? so if it is NOT waiting on a queue to which something could be enqueued because in that case the thread COULD possibly continue ? then whether that thread consumes some inaccessible bytes in memory or not is the same as far as functionality is concerned. > > What about the case that that freeing a forever-stuck VT allows more objects to be freed, which then might have cleaning actions? Freeing the stuck VT could create a side effect that would have only occurred when it resumed somehow. Whatever differences there may be, you could see similar differences when selecting a different GCs. Any functionality that depends on decisions made by the GC is at the mercy of a particular algorithm that may also change from one JDK release to another for a specific GC (and so probably should be avoided). ? Ron From robaho at icloud.com Sat Jul 6 20:29:50 2024 From: robaho at icloud.com (Robert Engels) Date: Sat, 6 Jul 2024 15:29:50 -0500 Subject: [External] : Re: Experience using virtual threads in EA 23-loom+4-102 In-Reply-To: <17A0ABBF-0ABD-4137-A269-D54CBCF3F51A@oracle.com> References: <07DDEEC5-688D-45A4-A651-CFDA38E3757C@oracle.com> <2B54EE29-CDD4-47A0-8178-27F8FE2AD39F@icloud.com> <052D6B72-3AD7-442C-99BB-87F1F183BB74@icloud.com> <746D1DC1-D689-495A-ADC4-C6D8E465E39B@icloud.com> <17A0ABBF-0ABD-4137-A269-D54CBCF3F51A@oracle.com> Message-ID: <3B19B482-43A5-4AD1-BE64-651D98768A80@icloud.com> Sorry, I?m an idiot. > On Jul 6, 2024, at 3:23 PM, Ron Pressler wrote: > > > >> On 4 Jul 2024, at 19:41, Robert Engels wrote: >> >>> >>> Consider 100 tasks, each running for 1 CPU second on a 1 core machine (although it works the same way with any number of cores). With time-sharing, the average (and median) latency would be 100s. Without time sharing the average (and median) latency would be almost half that. >> >> >> Yes, but the tail latency for timesharing is 100s. >> >> Without timesharing, the tail latency is more than 5000 secs - or an order of magnitude more. > > It would also be 100s. Time sharing makes things strictly worse in this case, and doesn?t even help tail latencies. > >> >> I don?t have hard numbers, I can only look to why most OS?s use timeslicing, and why Go had to add it, and make an educated guess. > > OSes use timesharing for very different reasons than improving server workloads (and as far as we know ? it doesn?t), and Go added them because there are situations where time sharing is helpful, but Java offers an even better solution than adding time sharing in the virtual thread scheduler. > > In any event, there?s no point discussing the hypotheticals of scheduling. They are well known and fairly basic in this field. What isn?t well known is how common are server workloads where time sharing helps in practice. > >> >> I am not saying this needs to change, but I think it needs to be better communicated to the community and what the ramifications are (e.g. atomic spin loops can deadlock the system). > > There are bigger problems than deadlocks if you use spin loops ? with or without time sharing ? when you have many thousands of threads. > > The most relevant thing to communicate, and we have, is that virtual threads? effectiveness stems from there being a very high number of them. Everything else follows. > > ? Ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron.pressler at oracle.com Sat Jul 6 20:36:37 2024 From: ron.pressler at oracle.com (Ron Pressler) Date: Sat, 6 Jul 2024 20:36:37 +0000 Subject: [External] : Re: Experience of adding JDK21 virtual thread support to a DB application In-Reply-To: References: <70AAB518-0B13-4611-B2F6-82938B81CE84@oracle.com> Message-ID: > On 6 Jul 2024, at 13:24, Matthew Swift wrote: > > Thanks for the great tip Ron. > > I had a look at how spinning is performed for Object monitors (https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/objectMonitor.cpp#L1790) in order to get an idea of how much spinning should be performed before blocking. Judging by the adaptive heuristics, it's obviously quite a complex topic, especially in the general case. Despite that, I wondered if a fixed number of spin iterations would suffice in my specific use-case given that it is a single hot critical section with a well defined fixed length. Sure enough a few experiments revealed that spinning for 200-500 iterations seemed to get the best results for new and old multi-core hardware, so I now have performance back on a par with Object monitors. Excellent. > > I will be able to revert back to using Object monitors once the recent monitor support has been officially released, because the Object monitor spin heuristics are more likely to work well across a wider range of hardware both now and in the future. > Unfortunately, while monitors would no longer pin virtual threads, their performance would suffer significantly when using virtual threads, and in general we recommend using j.u.c locks in new code anyway, because that implementation is likely to see further improvement, while monitors probably won?t. I don?t think there?s a good general way to determine how long to spin, and even the strategy for monitor is a heuristic based on whatever benchmarks were used at the time when it was designed. A spinning strategy for virtual threads would probably be different, and even then, it would differ from one workload to another. If you are very sensitive to spinning, my recommedation would be to do what you?re doing now ? explicit spinning with j.u.c locks ? pick a number that?s right for your workload, and revisit it every few years. ? Ron From ron.pressler at oracle.com Sat Jul 6 20:38:16 2024 From: ron.pressler at oracle.com (Ron Pressler) Date: Sat, 6 Jul 2024 20:38:16 +0000 Subject: Experience using virtual threads in EA 23-loom+4-102 In-Reply-To: References: Message-ID: > On 6 Jul 2024, at 19:20, Matthew Swift wrote: > > Thanks everyone for the helpful responses and continued discussion. > > Returning to my original message about high tail latencies when using virtual threads compared with platform threads, Viktor's response, in particular, prompted me to question whether I was missing something obvious. I fully agree that the high tail latencies are due to over saturation, but I still wanted to understand why the tail latencies were an order of magnitude worse when using virtual threads. > > I'm pleased to report (and slightly embarrassed!) that the cause of the bigger tail latencies is slightly more banal than subtle scheduling characteristics of the FJ pool, etc. > > As a reminder, the test involved a client sustaining 120[*] concurrent database transactions, each touching and locking over 400 DB records. The fixed size platform thread pool had 40 threads which had the effect of limiting concurrency to 40 simultaneous transactions. I naively swapped the platform thread pool for a virtual thread pool, which had the effect of removing the concurrency limits, allowing all 120 transactions to run concurrently and with a corresponding increase in lock thrashing / convoys. To test this I adjusted the platform thread pool to 120 threads and observed exactly the same high tail latencies that I saw with virtual threads. Conversely, the high tail latencies were reduced by an order of magnitude by throttling the writes using a Semaphore. In fact, I was able to reduce the P99.999 latency from over 10 seconds to 200ms with 20 permits, with no impact on P50. > > What's the conclusion here? In hindsight, the guidance in the section "Do not pool virtual threads" of JEP444 is pretty clear about using Semaphores for limiting concurrent access to limited resources. I think that the platform thread pool that we were using was using a small number of threads (e.g. 2 x #CPUs), as it was optimized for a mix of read txns (CPU bound, minimal locking) and write txns (low latency SSD IO, short lived record level locks), rather than high latency network IO. Thus, coincidentally, we never really observed significant lock thrashing related tail latencies and, therefore, didn't think we needed to limit concurrent access for writes. > > Cheers, > Matt > [*] I know virtual threads are intended for use cases involving thousands of concurrent requests. We see virtual threads as an opportunity for implementing features that may block threads for significant periods of time, such as fine grained rate limiting, distributed transactions and offloading password hashing to external microservices. Naturally, there will be a corresponding very significant increase in the number of concurrent requests. However, core functionality still needs to perform well and degrade gracefully, hence the test described in this thread. Very good. Thank you very much for your experience reports. Even reporting on such a ?user mistake? is helpful because this way we know what pitfalls may trip people. ? Ron From ron.pressler at oracle.com Sat Jul 6 21:05:11 2024 From: ron.pressler at oracle.com (Ron Pressler) Date: Sat, 6 Jul 2024 21:05:11 +0000 Subject: [External] : Re: Experience using virtual threads in EA 23-loom+4-102 In-Reply-To: <17A0ABBF-0ABD-4137-A269-D54CBCF3F51A@oracle.com> References: <07DDEEC5-688D-45A4-A651-CFDA38E3757C@oracle.com> <2B54EE29-CDD4-47A0-8178-27F8FE2AD39F@icloud.com> <052D6B72-3AD7-442C-99BB-87F1F183BB74@icloud.com> <746D1DC1-D689-495A-ADC4-C6D8E465E39B@icloud.com> <17A0ABBF-0ABD-4137-A269-D54CBCF3F51A@oracle.com> Message-ID: > On 6 Jul 2024, at 21:23, Ron Pressler wrote: > > > There are bigger problems than deadlocks if you use spin loops ? with or without time sharing ? when you have many thousands of threads. Actually, let me elaborate a bit more about this, and from your question I fear that someone may be using spinlocks when they shouldn?t: Spinlocks are only effective when the lock is held for very short durations, which typically means some computation ? not IO. When that?s the case, time sharing is irrelevant, as the owner thread is still scheduled to a core. If that?s not the case, i.e. the owner thread is doing some blocking IO operation, then a spinlock would just thrash your CPU for nothing, having a negative impact on throughput. Having a large number of threads would exacerbate the effect, and time sharing won?t solve the problem (imagine thousands of threads getting a significant CPU time slice to do nothing but thrash before the owner is finally selected by the scheduler). Rather, the right solution is not to use a spinlock in such situations. In other words, when a spinlock is actually appropriate, it will be just as effective without time-sharing. ? Ron From viktor.klang at oracle.com Mon Jul 8 19:42:48 2024 From: viktor.klang at oracle.com (Viktor Klang) Date: Mon, 8 Jul 2024 19:42:48 +0000 Subject: Experience using virtual threads in EA 23-loom+4-102 In-Reply-To: References: Message-ID: Hi Matt, Thanks for the write-up, I appreciate it! Cheers, ? Viktor Klang Software Architect, Java Platform Group Oracle ________________________________ From: loom-dev on behalf of Matthew Swift Sent: Saturday, 6 July 2024 20:20 To: loom-dev at openjdk.org Subject: Re: Experience using virtual threads in EA 23-loom+4-102 Thanks everyone for the helpful responses and continued discussion. Returning to my original message about high tail latencies when using virtual threads compared with platform threads, Viktor's response, in particular, prompted me to question whether I was missing something obvious. I fully agree that the high tail latencies are due to over saturation, but I still wanted to understand why the tail latencies were an order of magnitude worse when using virtual threads. I'm pleased to report (and slightly embarrassed!) that the cause of the bigger tail latencies is slightly more banal than subtle scheduling characteristics of the FJ pool, etc. As a reminder, the test involved a client sustaining 120[*] concurrent database transactions, each touching and locking over 400 DB records. The fixed size platform thread pool had 40 threads which had the effect of limiting concurrency to 40 simultaneous transactions. I naively swapped the platform thread pool for a virtual thread pool, which had the effect of removing the concurrency limits, allowing all 120 transactions to run concurrently and with a corresponding increase in lock thrashing / convoys. To test this I adjusted the platform thread pool to 120 threads and observed exactly the same high tail latencies that I saw with virtual threads. Conversely, the high tail latencies were reduced by an order of magnitude by throttling the writes using a Semaphore. In fact, I was able to reduce the P99.999 latency from over 10 seconds to 200ms with 20 permits, with no impact on P50. What's the conclusion here? In hindsight, the guidance in the section "Do not pool virtual threads" of JEP444 is pretty clear about using Semaphores for limiting concurrent access to limited resources. I think that the platform thread pool that we were using was using a small number of threads (e.g. 2 x #CPUs), as it was optimized for a mix of read txns (CPU bound, minimal locking) and write txns (low latency SSD IO, short lived record level locks), rather than high latency network IO. Thus, coincidentally, we never really observed significant lock thrashing related tail latencies and, therefore, didn't think we needed to limit concurrent access for writes. Cheers, Matt [*] I know virtual threads are intended for use cases involving thousands of concurrent requests. We see virtual threads as an opportunity for implementing features that may block threads for significant periods of time, such as fine grained rate limiting, distributed transactions and offloading password hashing to external microservices. Naturally, there will be a corresponding very significant increase in the number of concurrent requests. However, core functionality still needs to perform well and degrade gracefully, hence the test described in this thread. On Fri, 21 Jun 2024 at 19:05, Matthew Swift > wrote: Hello again, As promised, here is my second (shorter I hope!) email sharing feedback on the recent Loom EA build (23-loom+4-102). If follows up on my previous email https://mail.openjdk.org/pipermail/loom-dev/2024-June/006788.html. I performed some experiments using the same application described in my previous email. However, in order to properly test the improvements to Object monitors (synchronized blocks and Object.wait()) I reverted all of the thread-pinning related changes that I had made in order to support virtual threads with JDK21. Specifically, I reverted the changes converting uses of monitors to ReentrantLock. I'm pleased to say that this EA build looks extremely promising! :-) ### Experiment #1: read stress test * platform threads: 215K/s throughput, CPU 14% idle * virtual threads: 235K/s throughput, CPU 5% idle. Comment: there's a slight throughput improvement, but CPU utilization is slightly higher too. Presumably this is due to the number of carrier threads being closely matched to the number of CPUs (I noticed significantly less context switching with v threads). ### Experiment #2: heavily indexed write stress test, with 40 clients * platform threads: 9300/s throughput, CPU 27% idle * virtual threads: 8800/s throughput, CPU 24% idle. Comment: there is a ~5% performance degradation using virtual threads. This is better than the degradation I observed in my previous email after switching to ReentrantLock though. ### Experiment #3: extreme heavy indexed write stress test, with 120 clients * platform threads: 1450/s throughput * virtual threads: 1450/s throughput (i.e. about the same). Comment: This test is intended to stress the internal locking mechanisms as much as possible and expose any pinning problems. With JDK21 virtual threads the test would sometimes deadlock and thread dumps would show 100+ fork join carrier threads. This is no longer the case with the EA build. It looks really solid. This test does expose one important difference between platform threads and virtual threads though. Let's take a look at the response times: Platform threads: ------------------------------------------------------------------------------- | Throughput | Response Time | | | (ops/second) | (milliseconds) | | | recent average | recent average 99.9% 99.99% 99.999% | err/sec | ------------------------------------------------------------------------------- ... | 1442.6 1606.6 | 83.097 74.683 448.79 599.79 721.42 | 0.0 | | 1480.8 1594.0 | 81.125 75.282 442.50 599.79 721.42 | 0.0 | Virtual threads: ------------------------------------------------------------------------------- | Throughput | Response Time | | | (ops/second) | (milliseconds) | | | recent average | recent average 99.9% 99.99% 99.999% | err/sec | ------------------------------------------------------------------------------- ... | 1445.4 1645.3 | 81.375 72.623 3170.89 4798.28 8925.48 | 0.0 | | 1442.2 1625.0 | 81.047 73.371 3154.12 4798.28 6106.91 | 0.0 | The outliers with virtual threads are much much higher. Could this be due to potential starvation when rescheduling virtual threads in the fork join pool? Cheers, Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From outsider404 at gmail.com Mon Jul 8 21:12:21 2024 From: outsider404 at gmail.com (Michal Domagala) Date: Mon, 8 Jul 2024 23:12:21 +0200 Subject: [External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: <8701CBF3-45A5-410A-9AEA-0AE31FA04649@oracle.com> References: <5A2E1F5D-9346-48B2-B6C8-3459FB6E32B0@oracle.com> <5C2E3DDB-6F90-44F8-9783-A2B2C77378AA@ix.netcom.com> <7196614D-E2FA-4492-BE1E-B2BB0B0DE1CE@oracle.com> <99B9907A-218C-46DF-B909-70EC39CEABAE@ix.netcom.com> <44E8FB97-4D46-4F3B-8C0C-13893A67EA9B@oracle.com> <0A2CC387-3B85-4C3F-8AEA-24B6FD1D9DB3@ix.netcom.com> <8a3f069c-6a2b-476d-a948-a5c96d572fc6@gmail.com> <8701CBF3-45A5-410A-9AEA-0AE31FA04649@oracle.com> Message-ID: Hi As a thread author, I would like to say I opened the thread because I could not report a memory leak as a bug. Page https://bugreport.java.com/bugreport/submit_start does not work. In my understanding JEP 444 is finished and delivered in JDK 21. Any deviation between JEP 444 and JDK 21 is a bug. I hoped somebody will say "OMG" and start fixing procedure. But it seems to me discussion concerns on JEP 444 - good or bad decision was taken. Personally, I have high confidence in the written word. Written word convinced me that VT is GC'ed. It's very interesting to see other opinions, but in my understanding the time is out of joint and seek for help to set it right sob., 6 lip 2024 o 23:32 Ron Pressler napisa?(a): > > > > On 4 Jul 2024, at 21:34, Brian S O'Neill wrote: > > > > On 2024-07-04 11:43 AM, Ron Pressler wrote: > >>> On 3 Jul 2024, at 18:27, robert engels wrote: > >>> > >>> I agree 100% - I am fighting that the auto-closing of the queues, > clean-up, etc is ?unneeded magic? > >> There is no auto-closing, no cleanup, and no magic. If a thread gets > stuck in a state where it can never be observed or continued ? so if it is > NOT waiting on a queue to which something could be enqueued because in that > case the thread COULD possibly continue ? then whether that thread consumes > some inaccessible bytes in memory or not is the same as far as > functionality is concerned. > > > > What about the case that that freeing a forever-stuck VT allows more > objects to be freed, which then might have cleaning actions? Freeing the > stuck VT could create a side effect that would have only occurred when it > resumed somehow. > > Whatever differences there may be, you could see similar differences when > selecting a different GCs. Any functionality that depends on decisions made > by the GC is at the mercy of a particular algorithm that may also change > from one JDK release to another for a specific GC (and so probably should > be avoided). > > ? Ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From bronee at gmail.com Mon Jul 8 22:01:47 2024 From: bronee at gmail.com (Brian S O'Neill) Date: Mon, 8 Jul 2024 15:01:47 -0700 Subject: [External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: References: <5A2E1F5D-9346-48B2-B6C8-3459FB6E32B0@oracle.com> <5C2E3DDB-6F90-44F8-9783-A2B2C77378AA@ix.netcom.com> <7196614D-E2FA-4492-BE1E-B2BB0B0DE1CE@oracle.com> <99B9907A-218C-46DF-B909-70EC39CEABAE@ix.netcom.com> <44E8FB97-4D46-4F3B-8C0C-13893A67EA9B@oracle.com> <0A2CC387-3B85-4C3F-8AEA-24B6FD1D9DB3@ix.netcom.com> <8a3f069c-6a2b-476d-a948-a5c96d572fc6@gmail.com> <8701CBF3-45A5-410A-9AEA-0AE31FA04649@oracle.com> Message-ID: <9f199b81-aca6-41c9-8683-a99e689fa6ff@gmail.com> The exact phrase in JEP 444 is, "Unlike platform thread stacks, virtual thread stacks are not GC roots." GC roots also include static fields, but the tracked VT is only indirectly referenced by a static field, via a map object. So technically speaking, JEP 444 and JDK 21 are in agreement. Also note that JEP 444 says, "...the [virtual] thread can be garbage collected" It doesn't say that the virtual thread MUST be garbage collected. On 2024-07-08 02:12 PM, Michal Domagala wrote: > Hi > > As a thread author, I would like to say I opened the thread because I > could not report a memory?leak as a bug. Page > https://bugreport.java.com/bugreport/submit_start > ? does not work. > > In my understanding JEP 444 is finished and delivered in JDK 21. Any > deviation between JEP 444 and JDK 21 is a bug. > I hoped somebody will say "OMG" and start fixing procedure. But it seems > to me discussion concerns on JEP 444 - good or bad decision was taken. > > Personally, I have high confidence in the written word. Written word > convinced me that VT is GC'ed. It's very interesting to see other > opinions, but in my understanding the time is out of joint and seek?for > help?to set it right > From outsider404 at gmail.com Tue Jul 9 06:14:40 2024 From: outsider404 at gmail.com (Michal Domagala) Date: Tue, 9 Jul 2024 08:14:40 +0200 Subject: [External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: <9f199b81-aca6-41c9-8683-a99e689fa6ff@gmail.com> References: <5A2E1F5D-9346-48B2-B6C8-3459FB6E32B0@oracle.com> <5C2E3DDB-6F90-44F8-9783-A2B2C77378AA@ix.netcom.com> <7196614D-E2FA-4492-BE1E-B2BB0B0DE1CE@oracle.com> <99B9907A-218C-46DF-B909-70EC39CEABAE@ix.netcom.com> <44E8FB97-4D46-4F3B-8C0C-13893A67EA9B@oracle.com> <0A2CC387-3B85-4C3F-8AEA-24B6FD1D9DB3@ix.netcom.com> <8a3f069c-6a2b-476d-a948-a5c96d572fc6@gmail.com> <8701CBF3-45A5-410A-9AEA-0AE31FA04649@oracle.com> <9f199b81-aca6-41c9-8683-a99e689fa6ff@gmail.com> Message-ID: First, today I successfully reported the issue to https://bugreport.java.com. I do not need help or assistance anymore. Second, indeed, technically speaking, it is a memory leak issue, not GC root issue. Unfortunately, I do not know any documentation which declares that memory leaks in JDK are not allowed. However, the issue is strictly related to JEP 444, which directly explains how VTs are reclaimed by GC. Including an example. I'm pretty sure that the memory leak bug is caused by lack of awareness that VTs are not GC root. Continuing technical speaking, GC never MUST reclaim any particular object. GC MUST separate used and unused objects and MAY reclaim memory taken by unused objects. It means the contract "...the [virtual] thread can be garbage collected" is broken because blocked VT can NOT be garbage collected. Nevertheless, I'm satisfied because thread goal - report the issue to Oracle - is done. Thanks to any thread participant for taking effort wt., 9 lip 2024 o 00:02 Brian S O'Neill napisa?(a): > The exact phrase in JEP 444 is, "Unlike platform thread stacks, virtual > thread stacks are not GC roots." GC roots also include static fields, > but the tracked VT is only indirectly referenced by a static field, via > a map object. So technically speaking, JEP 444 and JDK 21 are in agreement. > > Also note that JEP 444 says, "...the [virtual] thread can be garbage > collected" It doesn't say that the virtual thread MUST be garbage > collected. > > > On 2024-07-08 02:12 PM, Michal Domagala wrote: > > Hi > > > > As a thread author, I would like to say I opened the thread because I > > could not report a memory leak as a bug. Page > > https://bugreport.java.com/bugreport/submit_start > > < > https://urldefense.com/v3/__https://bugreport.java.com/bugreport/submit_start__;!!ACWV5N9M2RV99hQ!O3-6Y8rB_Q3TnOXLeIa2WkhSm-X8hYgCkqwGAG4EqpVKaFgdKdh4kpH4juXWBBVbkBbMxFZDjRsTawE7Yeih$> > does not work. > > > > In my understanding JEP 444 is finished and delivered in JDK 21. Any > > deviation between JEP 444 and JDK 21 is a bug. > > I hoped somebody will say "OMG" and start fixing procedure. But it seems > > to me discussion concerns on JEP 444 - good or bad decision was taken. > > > > Personally, I have high confidence in the written word. Written word > > convinced me that VT is GC'ed. It's very interesting to see other > > opinions, but in my understanding the time is out of joint and seek for > > help to set it right > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Tue Jul 9 07:50:19 2024 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 9 Jul 2024 08:50:19 +0100 Subject: [External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: References: <5A2E1F5D-9346-48B2-B6C8-3459FB6E32B0@oracle.com> <5C2E3DDB-6F90-44F8-9783-A2B2C77378AA@ix.netcom.com> <7196614D-E2FA-4492-BE1E-B2BB0B0DE1CE@oracle.com> <99B9907A-218C-46DF-B909-70EC39CEABAE@ix.netcom.com> <44E8FB97-4D46-4F3B-8C0C-13893A67EA9B@oracle.com> <0A2CC387-3B85-4C3F-8AEA-24B6FD1D9DB3@ix.netcom.com> <8a3f069c-6a2b-476d-a948-a5c96d572fc6@gmail.com> <8701CBF3-45A5-410A-9AEA-0AE31FA04649@oracle.com> Message-ID: On 08/07/2024 22:12, Michal Domagala wrote: > Hi > > As a thread author, I would like to say I opened the thread because I > could not report a memory?leak as a bug. Page > https://bugreport.java.com/bugreport/submit_start > > does not work. > > In my understanding JEP 444 is finished and delivered in JDK 21. Any > deviation between JEP 444 and JDK 21 is a bug. > I hoped somebody will say "OMG" and start fixing procedure. But it > seems to me discussion concerns on JEP 444 - good or bad decision was > taken. > > Personally, I have high confidence in the written word. Written word > convinced me that VT is GC'ed. It's very interesting to see other > opinions, but in my understanding the time is out of joint and > seek?for help?to set it right > The topic you brought up was an open question when virtual threads were a preview feature in JDK 19/20. For JDK 19/20, virtual threads created directly with the Thread API were only only kept strongly reachable when doing some operation that may continue (blocked on I/O, timer, ...). This meant that, in some cases, "abandoned" virtual threads could be GC'ed even though they had not terminated. The main thing that came up during the preview period was observability. There were several questions here as to why virtual threads created directly with the Thread API didn't show up in thread dumps. It was surprising when virtual threads in other thread groupings (e.g. Executors.newVirtualThreadPerTaskExecutor) did appear in the thread dump. This was part of the motivation to change things before virtual threads became a permanent feature (see the History section of JEP 444). Aside from observability, the other issue is that GC'ing a thread that has not terminated will be very surprising to some developers. In many cases it will be transparent but there are cases where it is more nuanced and can be observed in advanced usages. Finalization is one topic. Another is Cleaner actions that may run while a resource is in an inconsistent state. The summary is that the behavior you observe in JDK 21/22/23 is the expected behavior. Virtual threads started directly with the Thread API will be kept strongly reachable until they terminate. The thread dump and other observability support can be used to identify "abandoned" threads.? This project has left the door open to the possibility of introducing some notion of "ephemeral threads" in the future. It would require quite a bit of exploration in several areas, would have to be opt-in, and would also require Finalization to be removed before introducing anything. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From robaho at icloud.com Tue Jul 9 10:44:38 2024 From: robaho at icloud.com (robert engels) Date: Tue, 9 Jul 2024 05:44:38 -0500 Subject: [External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: References: Message-ID: <2FDE94B6-540B-41D2-9CEC-6A82CCC73A8A@icloud.com> An HTML attachment was scrubbed... URL: From outsider404 at gmail.com Tue Jul 9 11:51:25 2024 From: outsider404 at gmail.com (Michal Domagala) Date: Tue, 9 Jul 2024 13:51:25 +0200 Subject: [External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: References: <5A2E1F5D-9346-48B2-B6C8-3459FB6E32B0@oracle.com> <5C2E3DDB-6F90-44F8-9783-A2B2C77378AA@ix.netcom.com> <7196614D-E2FA-4492-BE1E-B2BB0B0DE1CE@oracle.com> <99B9907A-218C-46DF-B909-70EC39CEABAE@ix.netcom.com> <44E8FB97-4D46-4F3B-8C0C-13893A67EA9B@oracle.com> <0A2CC387-3B85-4C3F-8AEA-24B6FD1D9DB3@ix.netcom.com> <8a3f069c-6a2b-476d-a948-a5c96d572fc6@gmail.com> <8701CBF3-45A5-410A-9AEA-0AE31FA04649@oracle.com> Message-ID: Thanks for valuable observability context As I understand, initially VT created by Thread API was not observable in thread dump and VT created by Executors API was observable. It was confusing and now both kinds of VT are observable. Make sense. But observability is reached by strong reference. VT created by Thread API are strongly referenced until stop and not GC'ed until stop and VT created by Executors API are not referenced at all and GC'ed when not reachable, regardless of being stopped or not. That's not OK and much worse than previous confusion. It is not clear to me if strongly-referenced-VT-created-from-Thread-API is intentional or a mistake. Initially I thought it was a mistake caused by lack of awareness of the VT lifecycle. However, it is written that "GC'ing a thread that has not terminated will be very surprising to some developers. (...) is the expected behavior. Virtual threads started directly with the Thread API will be kept strongly reachable until they terminate." In my understanding observability != strongly referenced. Current observability implementation, based on frail requirement that created-from-API VT should be present in thread dump as other VT, caused them to be strongly referenced, which is against JEP 444. I am convinced that VT must not be strongly referenced, regardless of whether the API was used for creation. However, if the opposite decision is taken, it must be documented and published somewhere. I would like to mention another clue that observability is implemented without VT knowledge. When -Djdk.trackAllThreads=false, observability is limited. Instead of strong references to VT (TrackingRootContainer#VTHREADS) there is counter: CountingRootContainer#VTHREAD_COUNT Counter is increased by onStart() and decreased by onStop(). But some VTs are gone without onStop(), so the counter is not properly decreased. wt., 9 lip 2024 o 09:50 Alan Bateman napisa?(a): > On 08/07/2024 22:12, Michal Domagala wrote: > > Hi > > As a thread author, I would like to say I opened the thread because I > could not report a memory leak as a bug. Page > https://bugreport.java.com/bugreport/submit_start > > does not work. > > In my understanding JEP 444 is finished and delivered in JDK 21. Any > deviation between JEP 444 and JDK 21 is a bug. > I hoped somebody will say "OMG" and start fixing procedure. But it seems > to me discussion concerns on JEP 444 - good or bad decision was taken. > > Personally, I have high confidence in the written word. Written word > convinced me that VT is GC'ed. It's very interesting to see other opinions, > but in my understanding the time is out of joint and seek for help to set > it right > > > The topic you brought up was an open question when virtual threads were a > preview feature in JDK 19/20. For JDK 19/20, virtual threads created > directly with the Thread API were only only kept strongly reachable when > doing some operation that may continue (blocked on I/O, timer, ...). This > meant that, in some cases, "abandoned" virtual threads could be GC'ed even > though they had not terminated. > > The main thing that came up during the preview period was observability. > There were several questions here as to why virtual threads created > directly with the Thread API didn't show up in thread dumps. It was > surprising when virtual threads in other thread groupings (e.g. > Executors.newVirtualThreadPerTaskExecutor) did appear in the thread dump. > This was part of the motivation to change things before virtual threads > became a permanent feature (see the History section of JEP 444). > > Aside from observability, the other issue is that GC'ing a thread that has > not terminated will be very surprising to some developers. In many cases it > will be transparent but there are cases where it is more nuanced and can be > observed in advanced usages. Finalization is one topic. Another is Cleaner > actions that may run while a resource is in an inconsistent state. > > The summary is that the behavior you observe in JDK 21/22/23 is the > expected behavior. Virtual threads started directly with the Thread API > will be kept strongly reachable until they terminate. The thread dump and > other observability support can be used to identify "abandoned" threads. > This project has left the door open to the possibility of introducing some > notion of "ephemeral threads" in the future. It would require quite a bit > of exploration in several areas, would have to be opt-in, and would also > require Finalization to be removed before introducing anything. > > -Alan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Tue Jul 9 14:24:01 2024 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 9 Jul 2024 15:24:01 +0100 Subject: [External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: References: <5A2E1F5D-9346-48B2-B6C8-3459FB6E32B0@oracle.com> <5C2E3DDB-6F90-44F8-9783-A2B2C77378AA@ix.netcom.com> <7196614D-E2FA-4492-BE1E-B2BB0B0DE1CE@oracle.com> <99B9907A-218C-46DF-B909-70EC39CEABAE@ix.netcom.com> <44E8FB97-4D46-4F3B-8C0C-13893A67EA9B@oracle.com> <0A2CC387-3B85-4C3F-8AEA-24B6FD1D9DB3@ix.netcom.com> <8a3f069c-6a2b-476d-a948-a5c96d572fc6@gmail.com> <8701CBF3-45A5-410A-9AEA-0AE31FA04649@oracle.com> Message-ID: <3a787d7b-5d83-4094-99c9-393b6341ce7c@oracle.com> On 09/07/2024 12:51, Michal Domagala wrote: > Thanks for valuable observability context > > As I understand, initially VT created by Thread API was not observable > in thread dump and VT created by Executors API was observable. It was > confusing and now both kinds of VT are observable. Make sense. > But observability is reached by strong reference. VT created by Thread > API are strongly referenced until stop and not GC'ed until stop and VT > created by Executors API are not referenced at all and GC'ed when not > reachable, regardless of being stopped or not. That's not OK and much > worse than previous?confusion. An ExecutorService implementation has to keep a reference to each task/thread because of the shutdownNow and close method. There are other thread groupings that arise when using structured concurrency that require a thread executing a main task wait for threads executing subtasks to finish executing. As things stand I don't expect there will be much confusion. For 25+ years, a started thread is alive (and strongly reachable) until it terminates. Having virtual thread work mostly the same shouldn't be a surprise. As I said, the door hasn't been closed on introducing some notion of ephemeral thread in the future. It's not really feasible right now because of finalization and because of several issues related to cleaner actions and explicit APIs to keep some object reachable until a thread gets to some point in its execution. So there is more to this than just observability (and yes of course observability could traverse other reference types if needed). As regards the thread counting in the root container when running with the undocumented system property jdk.trackAllThreads is set to false. That is the count of the live (started but not terminated) threads in that thread grouping. It is a left over from when we will mulling over what the right default should be (reporting a thread count when you can't list the threads has some value). -Alan From outsider404 at gmail.com Tue Jul 9 15:24:50 2024 From: outsider404 at gmail.com (Michal Domagala) Date: Tue, 9 Jul 2024 17:24:50 +0200 Subject: [External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: <3a787d7b-5d83-4094-99c9-393b6341ce7c@oracle.com> References: <5A2E1F5D-9346-48B2-B6C8-3459FB6E32B0@oracle.com> <5C2E3DDB-6F90-44F8-9783-A2B2C77378AA@ix.netcom.com> <7196614D-E2FA-4492-BE1E-B2BB0B0DE1CE@oracle.com> <99B9907A-218C-46DF-B909-70EC39CEABAE@ix.netcom.com> <44E8FB97-4D46-4F3B-8C0C-13893A67EA9B@oracle.com> <0A2CC387-3B85-4C3F-8AEA-24B6FD1D9DB3@ix.netcom.com> <8a3f069c-6a2b-476d-a948-a5c96d572fc6@gmail.com> <8701CBF3-45A5-410A-9AEA-0AE31FA04649@oracle.com> <3a787d7b-5d83-4094-99c9-393b6341ce7c@oracle.com> Message-ID: Indeed, for 25+ years thread is GC root. But for 3+ years virtual threads are present and they are documented as ephemeral. Developers are used to alive threads and virtual, alive threads are not confusing. But virtual, alive threads documented as ephemeral are confusing. Moreover, the idea that VT from Executors API is GCed but from Thread API not looks inconsistent. But it is low confusion. Working against documentation is high confusion. Let's consider my case. I take 1000 Kafka events for concrete people each poll. 90% of events are ignored (not my customers), 10% are processed (my customers), but each event must be acked. Each customer has a blocking queue. 10% is distributed to proper queues. Each queue has a VT, which processes the event and finally ack the event. >From time to time customers are off. Their blocking queues are thrown away. There is a chance that at the same moment the customer is off, new poll come with customer events. Kafka listener put event to customer queue and expects VT will ack the event. VT can't be stopped by the "customer-off" process, because new events may come to the blocking queue anytime. Race can be solved without synchronization. GC "knows" when the blocking queue is not visible by Kafka listener thread and "stops" the VT by reclaiming its resources. I hope this example is clear enough to see that reclaiming VT resources by GC is simple and automatic when manual solution requires thread synchronization and is prone to errors. wt., 9 lip 2024 o 16:24 Alan Bateman napisa?(a): > On 09/07/2024 12:51, Michal Domagala wrote: > > Thanks for valuable observability context > > > > As I understand, initially VT created by Thread API was not observable > > in thread dump and VT created by Executors API was observable. It was > > confusing and now both kinds of VT are observable. Make sense. > > But observability is reached by strong reference. VT created by Thread > > API are strongly referenced until stop and not GC'ed until stop and VT > > created by Executors API are not referenced at all and GC'ed when not > > reachable, regardless of being stopped or not. That's not OK and much > > worse than previous confusion. > > An ExecutorService implementation has to keep a reference to each > task/thread because of the shutdownNow and close method. There are other > thread groupings that arise when using structured concurrency that > require a thread executing a main task wait for threads executing > subtasks to finish executing. > > As things stand I don't expect there will be much confusion. For 25+ > years, a started thread is alive (and strongly reachable) until it > terminates. Having virtual thread work mostly the same shouldn't be a > surprise. As I said, the door hasn't been closed on introducing some > notion of ephemeral thread in the future. It's not really feasible right > now because of finalization and because of several issues related to > cleaner actions and explicit APIs to keep some object reachable until a > thread gets to some point in its execution. So there is more to this > than just observability (and yes of course observability could traverse > other reference types if needed). > > As regards the thread counting in the root container when running with > the undocumented system property jdk.trackAllThreads is set to false. > That is the count of the live (started but not terminated) threads in > that thread grouping. It is a left over from when we will mulling over > what the right default should be (reporting a thread count when you > can't list the threads has some value). > > -Alan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robaho at icloud.com Tue Jul 9 15:43:00 2024 From: robaho at icloud.com (Robert Engels) Date: Tue, 9 Jul 2024 10:43:00 -0500 Subject: [External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: References: <5A2E1F5D-9346-48B2-B6C8-3459FB6E32B0@oracle.com> <5C2E3DDB-6F90-44F8-9783-A2B2C77378AA@ix.netcom.com> <7196614D-E2FA-4492-BE1E-B2BB0B0DE1CE@oracle.com> <99B9907A-218C-46DF-B909-70EC39CEABAE@ix.netcom.com> <44E8FB97-4D46-4F3B-8C0C-13893A67EA9B@oracle.com> <0A2CC387-3B85-4C3F-8AEA-24B6FD1D9DB3@ix.netcom.com> <8a3f069c-6a2b-476d-a948-a5c96d572fc6@gmail.com> <8701CBF3-45A5-410A-9AEA-0AE31FA04649@oracle.com> <3a787d7b-5d83-4094-99c9-393b6341ce7c@oracle.com> Message-ID: <15F76FC3-7BDF-4BD4-AE11-334D84D50E00@icloud.com> As an aside, that seems like a much more complicated and obscure design than using closable queues. > On Jul 9, 2024, at 10:24 AM, Michal Domagala wrote: > > Indeed, for 25+ years thread is GC root. > But for 3+ years virtual threads are present and they are documented as ephemeral. > Developers are used to alive threads and virtual, alive threads are not confusing. But virtual, alive threads documented as ephemeral are confusing. > Moreover, the idea that VT from Executors API is GCed but from Thread API not looks inconsistent. But it is low confusion. Working against documentation is high confusion. > > Let's consider my case. I take 1000 Kafka events for concrete people each poll. 90% of events are ignored (not my customers), 10% are processed (my customers), but each event must be acked. > Each customer has a blocking queue. 10% is distributed to proper queues. Each queue has a VT, which processes the event and finally ack the event. > From time to time customers are off. Their blocking queues are thrown away. > There is a chance that at the same moment the customer is off, new poll come with customer events. Kafka listener put event to customer queue and expects VT will ack the event. > VT can't be stopped by the "customer-off" process, because new events may come to the blocking queue anytime. > > Race can be solved without synchronization. GC "knows" when the blocking queue is not visible by Kafka listener thread and "stops" the VT by reclaiming its resources. > > I hope this example is clear enough to see that reclaiming VT resources by GC is simple and automatic when manual solution requires thread synchronization and is prone to errors. > > wt., 9 lip 2024 o 16:24 Alan Bateman > napisa?(a): > On 09/07/2024 12:51, Michal Domagala wrote: > > Thanks for valuable observability context > > > > As I understand, initially VT created by Thread API was not observable > > in thread dump and VT created by Executors API was observable. It was > > confusing and now both kinds of VT are observable. Make sense. > > But observability is reached by strong reference. VT created by Thread > > API are strongly referenced until stop and not GC'ed until stop and VT > > created by Executors API are not referenced at all and GC'ed when not > > reachable, regardless of being stopped or not. That's not OK and much > > worse than previous confusion. > > An ExecutorService implementation has to keep a reference to each > task/thread because of the shutdownNow and close method. There are other > thread groupings that arise when using structured concurrency that > require a thread executing a main task wait for threads executing > subtasks to finish executing. > > As things stand I don't expect there will be much confusion. For 25+ > years, a started thread is alive (and strongly reachable) until it > terminates. Having virtual thread work mostly the same shouldn't be a > surprise. As I said, the door hasn't been closed on introducing some > notion of ephemeral thread in the future. It's not really feasible right > now because of finalization and because of several issues related to > cleaner actions and explicit APIs to keep some object reachable until a > thread gets to some point in its execution. So there is more to this > than just observability (and yes of course observability could traverse > other reference types if needed). > > As regards the thread counting in the root container when running with > the undocumented system property jdk.trackAllThreads is set to false. > That is the count of the live (started but not terminated) threads in > that thread grouping. It is a left over from when we will mulling over > what the right default should be (reporting a thread count when you > can't list the threads has some value). > > -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From outsider404 at gmail.com Tue Jul 9 15:54:22 2024 From: outsider404 at gmail.com (Michal Domagala) Date: Tue, 9 Jul 2024 17:54:22 +0200 Subject: [External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: <15F76FC3-7BDF-4BD4-AE11-334D84D50E00@icloud.com> References: <5A2E1F5D-9346-48B2-B6C8-3459FB6E32B0@oracle.com> <5C2E3DDB-6F90-44F8-9783-A2B2C77378AA@ix.netcom.com> <7196614D-E2FA-4492-BE1E-B2BB0B0DE1CE@oracle.com> <99B9907A-218C-46DF-B909-70EC39CEABAE@ix.netcom.com> <44E8FB97-4D46-4F3B-8C0C-13893A67EA9B@oracle.com> <0A2CC387-3B85-4C3F-8AEA-24B6FD1D9DB3@ix.netcom.com> <8a3f069c-6a2b-476d-a948-a5c96d572fc6@gmail.com> <8701CBF3-45A5-410A-9AEA-0AE31FA04649@oracle.com> <3a787d7b-5d83-4094-99c9-393b6341ce7c@oracle.com> <15F76FC3-7BDF-4BD4-AE11-334D84D50E00@icloud.com> Message-ID: Could you explain the "closeable queue"? Indeed, I want "close" queue and my implementation is > queueMap.remove(customerId) I was sure my solution is genius rather than obscure :) But I would like to learn another way to achieve closeable queue wt., 9 lip 2024 o 17:43 Robert Engels napisa?(a): > As an aside, that seems like a much more complicated and obscure design > than using closable queues. > > On Jul 9, 2024, at 10:24 AM, Michal Domagala > wrote: > > Indeed, for 25+ years thread is GC root. > But for 3+ years virtual threads are present and they are documented as > ephemeral. > Developers are used to alive threads and virtual, alive threads are not > confusing. But virtual, alive threads documented as ephemeral are confusing. > Moreover, the idea that VT from Executors API is GCed but from Thread API > not looks inconsistent. But it is low confusion. Working against > documentation is high confusion. > > Let's consider my case. I take 1000 Kafka events for concrete people each > poll. 90% of events are ignored (not my customers), 10% are processed (my > customers), but each event must be acked. > Each customer has a blocking queue. 10% is distributed to proper queues. > Each queue has a VT, which processes the event and finally ack the event. > From time to time customers are off. Their blocking queues are thrown > away. > There is a chance that at the same moment the customer is off, new poll > come with customer events. Kafka listener put event to customer queue and > expects VT will ack the event. > VT can't be stopped by the "customer-off" process, because new events may > come to the blocking queue anytime. > > Race can be solved without synchronization. GC "knows" when the blocking > queue is not visible by Kafka listener thread and "stops" the VT by > reclaiming its resources. > > I hope this example is clear enough to see that reclaiming VT resources by > GC is simple and automatic when manual solution requires thread > synchronization and is prone to errors. > > wt., 9 lip 2024 o 16:24 Alan Bateman napisa?(a): > >> On 09/07/2024 12:51, Michal Domagala wrote: >> > Thanks for valuable observability context >> > >> > As I understand, initially VT created by Thread API was not observable >> > in thread dump and VT created by Executors API was observable. It was >> > confusing and now both kinds of VT are observable. Make sense. >> > But observability is reached by strong reference. VT created by Thread >> > API are strongly referenced until stop and not GC'ed until stop and VT >> > created by Executors API are not referenced at all and GC'ed when not >> > reachable, regardless of being stopped or not. That's not OK and much >> > worse than previous confusion. >> >> An ExecutorService implementation has to keep a reference to each >> task/thread because of the shutdownNow and close method. There are other >> thread groupings that arise when using structured concurrency that >> require a thread executing a main task wait for threads executing >> subtasks to finish executing. >> >> As things stand I don't expect there will be much confusion. For 25+ >> years, a started thread is alive (and strongly reachable) until it >> terminates. Having virtual thread work mostly the same shouldn't be a >> surprise. As I said, the door hasn't been closed on introducing some >> notion of ephemeral thread in the future. It's not really feasible right >> now because of finalization and because of several issues related to >> cleaner actions and explicit APIs to keep some object reachable until a >> thread gets to some point in its execution. So there is more to this >> than just observability (and yes of course observability could traverse >> other reference types if needed). >> >> As regards the thread counting in the root container when running with >> the undocumented system property jdk.trackAllThreads is set to false. >> That is the count of the live (started but not terminated) threads in >> that thread grouping. It is a left over from when we will mulling over >> what the right default should be (reporting a thread count when you >> can't list the threads has some value). >> >> -Alan >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robaho at icloud.com Tue Jul 9 16:11:12 2024 From: robaho at icloud.com (robert engels) Date: Tue, 9 Jul 2024 11:11:12 -0500 Subject: [External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From robaho at icloud.com Tue Jul 9 16:12:55 2024 From: robaho at icloud.com (robert engels) Date: Tue, 9 Jul 2024 11:12:55 -0500 Subject: [External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: References: Message-ID: <68803F4C-2E00-4769-A31B-55D8BB718B1B@icloud.com> An HTML attachment was scrubbed... URL: From duke at openjdk.org Wed Jul 10 12:38:42 2024 From: duke at openjdk.org (duke) Date: Wed, 10 Jul 2024 12:38:42 GMT Subject: git: openjdk/loom: fibers: 35 new changesets Message-ID: <7f187ba4-75aa-407c-9fa1-a0ddde9fdf8e@openjdk.org> Changeset: 6f7f0f1d Branch: fibers Author: Per Minborg Date: 2024-07-06 15:05:26 +0000 URL: https://git.openjdk.org/loom/commit/6f7f0f1de05fdc0f6a88ccd90b806e8a5c5074ef 8333884: MemorySegment::reinterpret removes read-only property Reviewed-by: jvernee, mcimadamore ! src/java.base/share/classes/java/lang/foreign/MemorySegment.java ! src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java ! src/java.base/share/classes/jdk/internal/foreign/SegmentFactories.java ! test/jdk/java/foreign/TestSegments.java Changeset: 3f37c571 Branch: fibers Author: SendaoYan Committer: Fei Yang Date: 2024-07-08 01:19:36 +0000 URL: https://git.openjdk.org/loom/commit/3f37c5718d676b7001e6a084aed3ba645745a144 8335806: RISC-V: Corrected typos Bizarrely Reviewed-by: aph, amitkumar ! src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp ! src/hotspot/cpu/riscv/c2_MacroAssembler_riscv.cpp Changeset: 02956ab6 Branch: fibers Author: Emanuel Peter Date: 2024-07-08 06:23:03 +0000 URL: https://git.openjdk.org/loom/commit/02956ab6e161ca8556a73f328f79bcbfba997cbc 8332163: C2 SuperWord: refactor PacksetGraph and SuperWord::output into VTransformGraph Reviewed-by: chagedorn, kvn ! src/hotspot/share/opto/superword.cpp ! src/hotspot/share/opto/superword.hpp + src/hotspot/share/opto/superwordVTransformBuilder.cpp + src/hotspot/share/opto/superwordVTransformBuilder.hpp ! src/hotspot/share/opto/traceAutoVectorizationTag.hpp ! src/hotspot/share/opto/vectorization.cpp ! src/hotspot/share/opto/vectorization.hpp + src/hotspot/share/opto/vtransform.cpp + src/hotspot/share/opto/vtransform.hpp Changeset: 55fd1ed2 Branch: fibers Author: Jatin Bhateja Date: 2024-07-08 06:42:46 +0000 URL: https://git.openjdk.org/loom/commit/55fd1ed228ea3c42aaf92579e5dcb818fe14351d 8333890: Fatal error in auto-vectorizer with float16 kernel. Reviewed-by: kvn ! src/hotspot/share/opto/superword.cpp + test/hotspot/jtreg/compiler/vectorization/TestFloat16VectorConvChain.java Changeset: 3cce31ad Branch: fibers Author: Thomas Stuefe Date: 2024-07-08 08:06:56 +0000 URL: https://git.openjdk.org/loom/commit/3cce31ad8877ec62429981871bcb0067770f9ccb 8335643: serviceability/dcmd/vm tests fail for ZGC after JDK-8322475 Reviewed-by: sgehwolf, dholmes ! test/hotspot/jtreg/ProblemList-generational-zgc.txt ! test/hotspot/jtreg/ProblemList-zgc.txt ! test/hotspot/jtreg/serviceability/dcmd/vm/SystemMapTestBase.java Changeset: 540188fd Branch: fibers Author: Albert Mingkun Yang Date: 2024-07-08 10:03:39 +0000 URL: https://git.openjdk.org/loom/commit/540188fdebd089d4145eca18c0f95bf338cbcefc 8334445: Parallel: Decouple maximum compaction from SoftReference clearing Reviewed-by: zgu, lmao ! src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp ! src/hotspot/share/gc/parallel/psParallelCompact.cpp ! src/hotspot/share/gc/parallel/psParallelCompact.hpp ! src/hotspot/share/gc/parallel/psScavenge.cpp Changeset: c5a668bb Branch: fibers Author: Xiaolong Peng Committer: Aleksey Shipilev Date: 2024-07-08 10:33:08 +0000 URL: https://git.openjdk.org/loom/commit/c5a668bb653feb3408a9efa3274ceabf9f01a2c7 8334231: Optimize MethodData layout Reviewed-by: dholmes, chagedorn, shade ! src/hotspot/share/oops/methodData.hpp Changeset: c34a1b70 Branch: fibers Author: Tobias Hartmann Date: 2024-07-08 10:53:03 +0000 URL: https://git.openjdk.org/loom/commit/c34a1b7013b27a8a214f63387bd528a90342a416 8335861: Problem list compiler/vectorization/TestFloat16VectorConvChain.java Reviewed-by: epeter ! test/hotspot/jtreg/ProblemList.txt Changeset: 953c35eb Branch: fibers Author: Thomas Schatzl Date: 2024-07-08 11:44:04 +0000 URL: https://git.openjdk.org/loom/commit/953c35eb5bff49ec5f7dbb25edd8a324b94318eb 8335824: Test gc/arguments/TestMinInitialErgonomics.java is timing out Reviewed-by: ayang, kbarrett ! test/hotspot/jtreg/gc/arguments/TestMinInitialErgonomics.java Changeset: cec222e4 Branch: fibers Author: Jorn Vernee Date: 2024-07-08 12:39:33 +0000 URL: https://git.openjdk.org/loom/commit/cec222e46065fc15db3f2eb241d3607d605ab580 8317611: Add a tool like jdeprscan to find usage of restricted methods Reviewed-by: alanb, ihse, mcimadamore, jlahoda, jwaters ! make/modules/jdk.jdeps/Launcher.gmk ! src/jdk.compiler/share/classes/com/sun/tools/javac/platform/JDKPlatformProvider.java ! src/jdk.internal.opt/share/classes/module-info.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/Main.java + src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/ClassFileSource.java + src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/ClassResolver.java + src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/JNativeScanFatalError.java + src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/JNativeScanTask.java + src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/Main.java + src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/MethodRef.java + src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/NativeMethodFinder.java + src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/RestrictedUse.java ! src/jdk.jdeps/share/classes/module-info.java + src/jdk.jdeps/share/man/jnativescan.1 ! test/jdk/tools/launcher/HelpFlagsTest.java ! test/langtools/TEST.groups + test/langtools/tools/jnativescan/JNativeScanTestBase.java + test/langtools/tools/jnativescan/TestArrayTypeRefs.java + test/langtools/tools/jnativescan/TestJNativeScan.java + test/langtools/tools/jnativescan/TestMissingSystemClass.java + test/langtools/tools/jnativescan/TestSubclassRefs.java + test/langtools/tools/jnativescan/cases/classpath/app/App.java + test/langtools/tools/jnativescan/cases/classpath/arrayref/App.java + test/langtools/tools/jnativescan/cases/classpath/lib/Lib.java + test/langtools/tools/jnativescan/cases/classpath/missingsystem/App.java + test/langtools/tools/jnativescan/cases/classpath/singlejar/main/Main.java + test/langtools/tools/jnativescan/cases/classpath/subclassref/App.java + test/langtools/tools/jnativescan/cases/classpath/unnamed_package/UnnamedPackage.java + test/langtools/tools/jnativescan/cases/modules/org.lib/module-info.java + test/langtools/tools/jnativescan/cases/modules/org.lib/org/lib/Lib.java + test/langtools/tools/jnativescan/cases/modules/org.lib/org/lib/Service.java + test/langtools/tools/jnativescan/cases/modules/org.myapp/module-info.java + test/langtools/tools/jnativescan/cases/modules/org.myapp/org/myapp/main/Main.java + test/langtools/tools/jnativescan/cases/modules/org.service/module-info.java + test/langtools/tools/jnativescan/cases/modules/org.service/org/service/ServiceImpl.java + test/langtools/tools/jnativescan/cases/modules/org.singlejar/module-info.java + test/langtools/tools/jnativescan/cases/modules/org.singlejar/org/singlejar/main/Main.java Changeset: be3676f6 Branch: fibers Author: Matias Saavedra Silva Date: 2024-07-08 14:04:32 +0000 URL: https://git.openjdk.org/loom/commit/be3676f6bbc2d8041e43cf7bcfaee7fb9d864378 8304484: CDS dynamic dumping incorrectly leads to "Error occurred during initialization of VM" Reviewed-by: ccheung, iklam ! src/hotspot/share/classfile/classLoader.cpp Changeset: d8c1c6ab Branch: fibers Author: Albert Mingkun Yang Date: 2024-07-08 15:45:26 +0000 URL: https://git.openjdk.org/loom/commit/d8c1c6ab0543c986280dcfa1c6c79e010a7b35fb 8335604: Serial: Inline Generation::contiguous_available Reviewed-by: tschatzl ! src/hotspot/share/gc/serial/defNewGeneration.cpp ! src/hotspot/share/gc/serial/defNewGeneration.hpp ! src/hotspot/share/gc/serial/generation.hpp ! src/hotspot/share/gc/serial/tenuredGeneration.cpp ! src/hotspot/share/gc/serial/tenuredGeneration.hpp Changeset: a9b7f42f Branch: fibers Author: Joe Darcy Date: 2024-07-08 16:20:01 +0000 URL: https://git.openjdk.org/loom/commit/a9b7f42f29120a3cca0d341350ff03cae485e68b 8333826: Update --release 23 symbol information for JDK 23 build 29 Reviewed-by: iris, jlahoda ! src/jdk.compiler/share/data/symbols/java.desktop-N.sym.txt Changeset: 284671a1 Branch: fibers Author: Calvin Cheung Date: 2024-07-08 16:44:22 +0000 URL: https://git.openjdk.org/loom/commit/284671a1e4fb5bfe15b20b7f41fc24415b1235ed 8335449: runtime/cds/DeterministicDump.java fails with File content different at byte ... Reviewed-by: matsaave, iklam ! test/hotspot/jtreg/runtime/cds/DeterministicDump.java Changeset: 3a87eb5c Branch: fibers Author: Kelvin Nilsen Date: 2024-07-08 18:03:19 +0000 URL: https://git.openjdk.org/loom/commit/3a87eb5c4606ce39970962895315567e8606eba7 8335126: Shenandoah: Improve OOM handling Reviewed-by: shade, ysr, wkemper, rkennke ! src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp ! src/hotspot/share/gc/shenandoah/shenandoahDegeneratedGC.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp Changeset: 3733fe3a Branch: fibers Author: lawrence.andrews Committer: Alexey Ivanov Date: 2024-07-08 19:14:33 +0000 URL: https://git.openjdk.org/loom/commit/3733fe3a207078b585421cd2a098e808fafaa817 8335789: [TESTBUG] XparColor.java test fails with Error. Parse Exception: Invalid or unrecognized bugid: @ Reviewed-by: aivanov ! test/jdk/java/awt/print/PrinterJob/XparColor.java Changeset: babf6df7 Branch: fibers Author: Liam Miller-Cushon Date: 2024-07-08 20:09:07 +0000 URL: https://git.openjdk.org/loom/commit/babf6df7d97e4beedb25e689634d999412c1e950 8334757: AssertionError: Missing type variable in where clause Reviewed-by: jlahoda, vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java + test/langtools/tools/javac/annotations/typeAnnotations/failures/CantAnnotateClassWithTypeVariable.java + test/langtools/tools/javac/annotations/typeAnnotations/failures/CantAnnotateClassWithTypeVariable.out Changeset: bb1f8a16 Branch: fibers Author: Xiaolong Peng Committer: Aleksey Shipilev Date: 2024-07-08 20:10:27 +0000 URL: https://git.openjdk.org/loom/commit/bb1f8a1698553d5962569ac8912edd0d7ef010dd 8335904: Fix invalid comment in ShenandoahLock Reviewed-by: shade ! src/hotspot/share/gc/shenandoah/shenandoahLock.cpp Changeset: 9c7a6eab Branch: fibers Author: Ioi Lam Date: 2024-07-08 20:14:26 +0000 URL: https://git.openjdk.org/loom/commit/9c7a6eabb93c570fdb74076edc931576ed6be3e0 8312125: Refactor CDS enum class handling Reviewed-by: matsaave, ccheung + src/hotspot/share/cds/cdsEnumKlass.cpp + src/hotspot/share/cds/cdsEnumKlass.hpp ! src/hotspot/share/cds/heapShared.cpp ! src/hotspot/share/cds/heapShared.hpp ! src/hotspot/share/oops/instanceKlass.cpp Changeset: 564a72e1 Branch: fibers Author: Thomas Schatzl Date: 2024-07-09 08:10:55 +0000 URL: https://git.openjdk.org/loom/commit/564a72e1dba0f145600c8e7eff66992fbf294df0 8335955: JDK-8335742 wrongly used a "JDK-" prefix in the problemlist bug number Reviewed-by: iwalulya ! test/hotspot/jtreg/ProblemList-Virtual.txt Changeset: 2a296475 Branch: fibers Author: Kevin Walls Date: 2024-07-09 08:25:00 +0000 URL: https://git.openjdk.org/loom/commit/2a2964759c73b3b9ab6afaad109383c89952977b 8334777: Test javax/management/remote/mandatory/notif/NotifReconnectDeadlockTest.java failed with NullPointerException Reviewed-by: cjplummer, dholmes ! test/jdk/javax/management/remote/mandatory/notif/NotifReconnectDeadlockTest.java Changeset: 8f62f31d Branch: fibers Author: Amit Kumar Date: 2024-07-09 08:26:25 +0000 URL: https://git.openjdk.org/loom/commit/8f62f31dff564289a2422d58e8ecd5062d443b81 8335906: [s390x] Test Failure: GTestWrapper.java Reviewed-by: stuefe ! src/hotspot/share/runtime/os.cpp Changeset: f3ff4f74 Branch: fibers Author: Severin Gehwolf Date: 2024-07-09 10:21:47 +0000 URL: https://git.openjdk.org/loom/commit/f3ff4f7427c3c3f5cb2a115a61462bb9d28de1cd 8335882: platform/cgroup/TestSystemSettings.java fails on Alpine Linux Reviewed-by: stuefe, mbaesken ! test/jdk/jdk/internal/platform/cgroup/TestSystemSettings.java Changeset: 0e0dfca2 Branch: fibers Author: Aleksei Voitylov Committer: Dmitry Samersoff Date: 2024-07-09 10:27:44 +0000 URL: https://git.openjdk.org/loom/commit/0e0dfca21f64ecfcb3e5ed7cdc2a173834faa509 8330806: test/hotspot/jtreg/compiler/c1/TestLargeMonitorOffset.java fails on ARM32 Reviewed-by: snazarki, dsamersoff ! src/hotspot/cpu/arm/c1_LIRAssembler_arm.cpp Changeset: 531a6d85 Branch: fibers Author: Volker Simonis Date: 2024-07-09 13:11:07 +0000 URL: https://git.openjdk.org/loom/commit/531a6d85b00b88688668ab1ced0db6ce0214a5f1 8335911: Document ccls indexer in doc/ide.md Reviewed-by: erikj ! doc/ide.html ! doc/ide.md Changeset: 7e11fb70 Branch: fibers Author: Kim Barrett Date: 2024-07-09 13:11:20 +0000 URL: https://git.openjdk.org/loom/commit/7e11fb702696df733ca89d325200f2e9414402d9 8335688: Fix -Wzero-as-null-pointer-constant warnings from fflush calls in jvmti tests Reviewed-by: jwaters, coleenp ! test/hotspot/jtreg/serviceability/jvmti/AddModuleUsesAndProvides/libAddModuleUsesAndProvidesTest.c ! test/hotspot/jtreg/serviceability/jvmti/GenerateEvents/libGenerateEvents1.cpp ! test/hotspot/jtreg/serviceability/jvmti/GenerateEvents/libGenerateEvents2.cpp ! test/hotspot/jtreg/serviceability/jvmti/GetClassFields/FilteredFields/libFilteredFieldsTest.cpp ! test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/MissedStackMapFrames/libMissedStackMapFrames.cpp ! test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRetransform/libRedefineRetransform.cpp ! test/hotspot/jtreg/serviceability/jvmti/events/FramePop/framepop02/libframepop02.cpp ! test/hotspot/jtreg/serviceability/jvmti/thread/GetStackTrace/get_stack_trace.hpp ! test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendResume1/libSuspendResume1.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassFields/getclfld007/getclfld007.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/FollowReferences/followref001/followref001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/FollowReferences/followref002/followref002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/FollowReferences/followref003/followref003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/FollowReferences/followref004/followref004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/FollowReferences/followref005/followref005.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/FollowReferences/followref006/followref006.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretbase/earlyretbase.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretfp/earlyretfp.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretint/earlyretint.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretlong/earlyretlong.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretobj/earlyretobj.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretstr/earlyretstr.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretvoid/earlyretvoid.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/GetAllStackTraces/getallstktr001/getallstktr001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/GetConstantPool/getcpool001/getcpool001.cpp Changeset: 14721244 Branch: fibers Author: Mark Powers Date: 2024-07-09 20:38:09 +0000 URL: https://git.openjdk.org/loom/commit/1472124489c841642996ae984e21c533ffec8091 8333364: Minor cleanup could be done in com.sun.crypto.provider Reviewed-by: mullan, valeriep ! src/java.base/share/classes/com/sun/crypto/provider/AESKeyGenerator.java ! src/java.base/share/classes/com/sun/crypto/provider/AESKeyWrap.java ! src/java.base/share/classes/com/sun/crypto/provider/AESKeyWrapPadded.java ! src/java.base/share/classes/com/sun/crypto/provider/ARCFOURCipher.java ! src/java.base/share/classes/com/sun/crypto/provider/ChaCha20Cipher.java ! src/java.base/share/classes/com/sun/crypto/provider/ChaCha20Poly1305Parameters.java ! src/java.base/share/classes/com/sun/crypto/provider/CipherBlockChaining.java ! src/java.base/share/classes/com/sun/crypto/provider/CipherCore.java ! src/java.base/share/classes/com/sun/crypto/provider/CipherTextStealing.java ! src/java.base/share/classes/com/sun/crypto/provider/ConstructKeys.java ! src/java.base/share/classes/com/sun/crypto/provider/DESCrypt.java ! src/java.base/share/classes/com/sun/crypto/provider/DESKeyFactory.java ! src/java.base/share/classes/com/sun/crypto/provider/DESedeKeyFactory.java ! src/java.base/share/classes/com/sun/crypto/provider/DESedeKeyGenerator.java ! src/java.base/share/classes/com/sun/crypto/provider/DESedeWrapCipher.java ! src/java.base/share/classes/com/sun/crypto/provider/DHKEM.java ! src/java.base/share/classes/com/sun/crypto/provider/DHKeyAgreement.java ! src/java.base/share/classes/com/sun/crypto/provider/DHKeyPairGenerator.java ! src/java.base/share/classes/com/sun/crypto/provider/ElectronicCodeBook.java ! src/java.base/share/classes/com/sun/crypto/provider/FeedbackCipher.java ! src/java.base/share/classes/com/sun/crypto/provider/GCTR.java ! src/java.base/share/classes/com/sun/crypto/provider/GHASH.java ! src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java ! src/java.base/share/classes/com/sun/crypto/provider/HmacCore.java ! src/java.base/share/classes/com/sun/crypto/provider/HmacMD5.java ! src/java.base/share/classes/com/sun/crypto/provider/HmacMD5KeyGenerator.java ! src/java.base/share/classes/com/sun/crypto/provider/HmacSHA1.java ! src/java.base/share/classes/com/sun/crypto/provider/HmacSHA1KeyGenerator.java ! src/java.base/share/classes/com/sun/crypto/provider/ISO10126Padding.java ! src/java.base/share/classes/com/sun/crypto/provider/JceKeyStore.java ! src/java.base/share/classes/com/sun/crypto/provider/KWUtil.java ! src/java.base/share/classes/com/sun/crypto/provider/KeyProtector.java ! src/java.base/share/classes/com/sun/crypto/provider/KeyWrapCipher.java ! src/java.base/share/classes/com/sun/crypto/provider/OAEPParameters.java ! src/java.base/share/classes/com/sun/crypto/provider/OutputFeedback.java ! src/java.base/share/classes/com/sun/crypto/provider/PBEKeyFactory.java ! src/java.base/share/classes/com/sun/crypto/provider/PBES1Core.java ! src/java.base/share/classes/com/sun/crypto/provider/PBES2Parameters.java ! src/java.base/share/classes/com/sun/crypto/provider/PBKDF2KeyImpl.java ! src/java.base/share/classes/com/sun/crypto/provider/PBMAC1Core.java ! src/java.base/share/classes/com/sun/crypto/provider/PKCS5Padding.java ! src/java.base/share/classes/com/sun/crypto/provider/Poly1305.java ! src/java.base/share/classes/com/sun/crypto/provider/RC2Crypt.java ! src/java.base/share/classes/com/sun/crypto/provider/RSACipher.java ! src/java.base/share/classes/com/sun/crypto/provider/SslMacCore.java ! src/java.base/share/classes/com/sun/crypto/provider/TlsKeyMaterialGenerator.java ! src/java.base/share/classes/com/sun/crypto/provider/TlsPrfGenerator.java Changeset: dcf4e0d5 Branch: fibers Author: Jaikiran Pai Date: 2024-07-10 03:30:19 +0000 URL: https://git.openjdk.org/loom/commit/dcf4e0d51f392afe2711223484e932e3826e8864 8335966: Remove incorrect problem listing of java/lang/instrument/NativeMethodPrefixAgent.java in ProblemList-Virtual.txt Reviewed-by: kevinw, amenkov ! test/jdk/ProblemList-Virtual.txt Changeset: b5909cab Branch: fibers Author: Koichi Sakata Date: 2024-07-10 05:57:11 +0000 URL: https://git.openjdk.org/loom/commit/b5909cabeef22954f4d9c642b1cbf288b3454562 8323242: Remove vestigial DONT_USE_REGISTER_DEFINES Reviewed-by: gli, kvn ! src/hotspot/cpu/zero/register_zero.hpp Changeset: e4fc4ca5 Branch: fibers Author: Alan Bateman Date: 2024-07-10 07:00:52 +0000 URL: https://git.openjdk.org/loom/commit/e4fc4ca584f78151c38b7214896911d884339502 Merge ! src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp ! src/hotspot/cpu/riscv/c2_MacroAssembler_riscv.cpp ! src/hotspot/share/oops/instanceKlass.cpp ! test/hotspot/jtreg/ProblemList-Virtual.txt ! test/hotspot/jtreg/ProblemList.txt ! test/jdk/ProblemList-Virtual.txt ! src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp ! src/hotspot/cpu/riscv/c2_MacroAssembler_riscv.cpp ! src/hotspot/share/oops/instanceKlass.cpp ! test/hotspot/jtreg/ProblemList-Virtual.txt ! test/hotspot/jtreg/ProblemList.txt ! test/jdk/ProblemList-Virtual.txt Changeset: 8702c340 Branch: fibers Author: Alan Bateman Date: 2024-06-28 11:00:38 +0000 URL: https://git.openjdk.org/loom/commit/8702c340366bb05c6f3fdaad36a52a366924e66f Problem list cleanup/comments ! test/hotspot/jtreg/ProblemList-Virtual.txt ! test/hotspot/jtreg/ProblemList.txt ! test/jdk/ProblemList-Virtual.txt Changeset: f3a9ec74 Branch: fibers Author: Alan Bateman Date: 2024-07-09 14:03:56 +0000 URL: https://git.openjdk.org/loom/commit/f3a9ec7403d30a33df0a3451203b45f224eaf0f6 More ProblemList cleanup ! test/hotspot/jtreg/ProblemList-Xcomp.txt Changeset: 5c9e601f Branch: fibers Author: Alan Bateman Date: 2024-07-10 07:01:10 +0000 URL: https://git.openjdk.org/loom/commit/5c9e601f8106aa7c551c177572ae7588b5047726 Merge ! test/hotspot/jtreg/ProblemList-Virtual.txt ! test/hotspot/jtreg/ProblemList.txt ! test/jdk/ProblemList-Virtual.txt ! test/hotspot/jtreg/ProblemList-Virtual.txt ! test/hotspot/jtreg/ProblemList.txt ! test/jdk/ProblemList-Virtual.txt Changeset: 4ffe94dc Branch: fibers Author: Alan Bateman Date: 2024-07-10 13:34:42 +0000 URL: https://git.openjdk.org/loom/commit/4ffe94dc0fe617bab14750134bb76a2aede799cb Rename JoinPolicy to Joiner for now ! src/java.base/share/classes/java/util/concurrent/StructuredTaskScope.java ! test/jdk/java/lang/ScopedValue/StressStackOverflow.java ! test/jdk/java/util/concurrent/StructuredTaskScope/StressCancellation.java ! test/jdk/java/util/concurrent/StructuredTaskScope/StructuredTaskScopeTest.java ! test/jdk/java/util/concurrent/StructuredTaskScope/StructuredThreadDumpTest.java ! test/jdk/java/util/concurrent/StructuredTaskScope/WithScopedValue.java ! test/jdk/javax/security/auth/Subject/CallAsWithScopedValue.java Changeset: 3211b749 Branch: fibers Author: Alan Bateman Date: 2024-07-10 13:34:53 +0000 URL: https://git.openjdk.org/loom/commit/3211b749b32045be1ac45704bec2d5c7788ec989 Merge From duke at openjdk.org Wed Jul 10 12:40:21 2024 From: duke at openjdk.org (duke) Date: Wed, 10 Jul 2024 12:40:21 GMT Subject: git: openjdk/loom: master: 29 new changesets Message-ID: <81b25068-85d1-48ff-adef-e9d503ea5eee@openjdk.org> Changeset: 6f7f0f1d Branch: master Author: Per Minborg Date: 2024-07-06 15:05:26 +0000 URL: https://git.openjdk.org/loom/commit/6f7f0f1de05fdc0f6a88ccd90b806e8a5c5074ef 8333884: MemorySegment::reinterpret removes read-only property Reviewed-by: jvernee, mcimadamore ! src/java.base/share/classes/java/lang/foreign/MemorySegment.java ! src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java ! src/java.base/share/classes/jdk/internal/foreign/SegmentFactories.java ! test/jdk/java/foreign/TestSegments.java Changeset: 3f37c571 Branch: master Author: SendaoYan Committer: Fei Yang Date: 2024-07-08 01:19:36 +0000 URL: https://git.openjdk.org/loom/commit/3f37c5718d676b7001e6a084aed3ba645745a144 8335806: RISC-V: Corrected typos Bizarrely Reviewed-by: aph, amitkumar ! src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp ! src/hotspot/cpu/riscv/c2_MacroAssembler_riscv.cpp Changeset: 02956ab6 Branch: master Author: Emanuel Peter Date: 2024-07-08 06:23:03 +0000 URL: https://git.openjdk.org/loom/commit/02956ab6e161ca8556a73f328f79bcbfba997cbc 8332163: C2 SuperWord: refactor PacksetGraph and SuperWord::output into VTransformGraph Reviewed-by: chagedorn, kvn ! src/hotspot/share/opto/superword.cpp ! src/hotspot/share/opto/superword.hpp + src/hotspot/share/opto/superwordVTransformBuilder.cpp + src/hotspot/share/opto/superwordVTransformBuilder.hpp ! src/hotspot/share/opto/traceAutoVectorizationTag.hpp ! src/hotspot/share/opto/vectorization.cpp ! src/hotspot/share/opto/vectorization.hpp + src/hotspot/share/opto/vtransform.cpp + src/hotspot/share/opto/vtransform.hpp Changeset: 55fd1ed2 Branch: master Author: Jatin Bhateja Date: 2024-07-08 06:42:46 +0000 URL: https://git.openjdk.org/loom/commit/55fd1ed228ea3c42aaf92579e5dcb818fe14351d 8333890: Fatal error in auto-vectorizer with float16 kernel. Reviewed-by: kvn ! src/hotspot/share/opto/superword.cpp + test/hotspot/jtreg/compiler/vectorization/TestFloat16VectorConvChain.java Changeset: 3cce31ad Branch: master Author: Thomas Stuefe Date: 2024-07-08 08:06:56 +0000 URL: https://git.openjdk.org/loom/commit/3cce31ad8877ec62429981871bcb0067770f9ccb 8335643: serviceability/dcmd/vm tests fail for ZGC after JDK-8322475 Reviewed-by: sgehwolf, dholmes ! test/hotspot/jtreg/ProblemList-generational-zgc.txt ! test/hotspot/jtreg/ProblemList-zgc.txt ! test/hotspot/jtreg/serviceability/dcmd/vm/SystemMapTestBase.java Changeset: 540188fd Branch: master Author: Albert Mingkun Yang Date: 2024-07-08 10:03:39 +0000 URL: https://git.openjdk.org/loom/commit/540188fdebd089d4145eca18c0f95bf338cbcefc 8334445: Parallel: Decouple maximum compaction from SoftReference clearing Reviewed-by: zgu, lmao ! src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp ! src/hotspot/share/gc/parallel/psParallelCompact.cpp ! src/hotspot/share/gc/parallel/psParallelCompact.hpp ! src/hotspot/share/gc/parallel/psScavenge.cpp Changeset: c5a668bb Branch: master Author: Xiaolong Peng Committer: Aleksey Shipilev Date: 2024-07-08 10:33:08 +0000 URL: https://git.openjdk.org/loom/commit/c5a668bb653feb3408a9efa3274ceabf9f01a2c7 8334231: Optimize MethodData layout Reviewed-by: dholmes, chagedorn, shade ! src/hotspot/share/oops/methodData.hpp Changeset: c34a1b70 Branch: master Author: Tobias Hartmann Date: 2024-07-08 10:53:03 +0000 URL: https://git.openjdk.org/loom/commit/c34a1b7013b27a8a214f63387bd528a90342a416 8335861: Problem list compiler/vectorization/TestFloat16VectorConvChain.java Reviewed-by: epeter ! test/hotspot/jtreg/ProblemList.txt Changeset: 953c35eb Branch: master Author: Thomas Schatzl Date: 2024-07-08 11:44:04 +0000 URL: https://git.openjdk.org/loom/commit/953c35eb5bff49ec5f7dbb25edd8a324b94318eb 8335824: Test gc/arguments/TestMinInitialErgonomics.java is timing out Reviewed-by: ayang, kbarrett ! test/hotspot/jtreg/gc/arguments/TestMinInitialErgonomics.java Changeset: cec222e4 Branch: master Author: Jorn Vernee Date: 2024-07-08 12:39:33 +0000 URL: https://git.openjdk.org/loom/commit/cec222e46065fc15db3f2eb241d3607d605ab580 8317611: Add a tool like jdeprscan to find usage of restricted methods Reviewed-by: alanb, ihse, mcimadamore, jlahoda, jwaters ! make/modules/jdk.jdeps/Launcher.gmk ! src/jdk.compiler/share/classes/com/sun/tools/javac/platform/JDKPlatformProvider.java ! src/jdk.internal.opt/share/classes/module-info.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/Main.java + src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/ClassFileSource.java + src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/ClassResolver.java + src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/JNativeScanFatalError.java + src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/JNativeScanTask.java + src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/Main.java + src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/MethodRef.java + src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/NativeMethodFinder.java + src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/RestrictedUse.java ! src/jdk.jdeps/share/classes/module-info.java + src/jdk.jdeps/share/man/jnativescan.1 ! test/jdk/tools/launcher/HelpFlagsTest.java ! test/langtools/TEST.groups + test/langtools/tools/jnativescan/JNativeScanTestBase.java + test/langtools/tools/jnativescan/TestArrayTypeRefs.java + test/langtools/tools/jnativescan/TestJNativeScan.java + test/langtools/tools/jnativescan/TestMissingSystemClass.java + test/langtools/tools/jnativescan/TestSubclassRefs.java + test/langtools/tools/jnativescan/cases/classpath/app/App.java + test/langtools/tools/jnativescan/cases/classpath/arrayref/App.java + test/langtools/tools/jnativescan/cases/classpath/lib/Lib.java + test/langtools/tools/jnativescan/cases/classpath/missingsystem/App.java + test/langtools/tools/jnativescan/cases/classpath/singlejar/main/Main.java + test/langtools/tools/jnativescan/cases/classpath/subclassref/App.java + test/langtools/tools/jnativescan/cases/classpath/unnamed_package/UnnamedPackage.java + test/langtools/tools/jnativescan/cases/modules/org.lib/module-info.java + test/langtools/tools/jnativescan/cases/modules/org.lib/org/lib/Lib.java + test/langtools/tools/jnativescan/cases/modules/org.lib/org/lib/Service.java + test/langtools/tools/jnativescan/cases/modules/org.myapp/module-info.java + test/langtools/tools/jnativescan/cases/modules/org.myapp/org/myapp/main/Main.java + test/langtools/tools/jnativescan/cases/modules/org.service/module-info.java + test/langtools/tools/jnativescan/cases/modules/org.service/org/service/ServiceImpl.java + test/langtools/tools/jnativescan/cases/modules/org.singlejar/module-info.java + test/langtools/tools/jnativescan/cases/modules/org.singlejar/org/singlejar/main/Main.java Changeset: be3676f6 Branch: master Author: Matias Saavedra Silva Date: 2024-07-08 14:04:32 +0000 URL: https://git.openjdk.org/loom/commit/be3676f6bbc2d8041e43cf7bcfaee7fb9d864378 8304484: CDS dynamic dumping incorrectly leads to "Error occurred during initialization of VM" Reviewed-by: ccheung, iklam ! src/hotspot/share/classfile/classLoader.cpp Changeset: d8c1c6ab Branch: master Author: Albert Mingkun Yang Date: 2024-07-08 15:45:26 +0000 URL: https://git.openjdk.org/loom/commit/d8c1c6ab0543c986280dcfa1c6c79e010a7b35fb 8335604: Serial: Inline Generation::contiguous_available Reviewed-by: tschatzl ! src/hotspot/share/gc/serial/defNewGeneration.cpp ! src/hotspot/share/gc/serial/defNewGeneration.hpp ! src/hotspot/share/gc/serial/generation.hpp ! src/hotspot/share/gc/serial/tenuredGeneration.cpp ! src/hotspot/share/gc/serial/tenuredGeneration.hpp Changeset: a9b7f42f Branch: master Author: Joe Darcy Date: 2024-07-08 16:20:01 +0000 URL: https://git.openjdk.org/loom/commit/a9b7f42f29120a3cca0d341350ff03cae485e68b 8333826: Update --release 23 symbol information for JDK 23 build 29 Reviewed-by: iris, jlahoda ! src/jdk.compiler/share/data/symbols/java.desktop-N.sym.txt Changeset: 284671a1 Branch: master Author: Calvin Cheung Date: 2024-07-08 16:44:22 +0000 URL: https://git.openjdk.org/loom/commit/284671a1e4fb5bfe15b20b7f41fc24415b1235ed 8335449: runtime/cds/DeterministicDump.java fails with File content different at byte ... Reviewed-by: matsaave, iklam ! test/hotspot/jtreg/runtime/cds/DeterministicDump.java Changeset: 3a87eb5c Branch: master Author: Kelvin Nilsen Date: 2024-07-08 18:03:19 +0000 URL: https://git.openjdk.org/loom/commit/3a87eb5c4606ce39970962895315567e8606eba7 8335126: Shenandoah: Improve OOM handling Reviewed-by: shade, ysr, wkemper, rkennke ! src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp ! src/hotspot/share/gc/shenandoah/shenandoahDegeneratedGC.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp Changeset: 3733fe3a Branch: master Author: lawrence.andrews Committer: Alexey Ivanov Date: 2024-07-08 19:14:33 +0000 URL: https://git.openjdk.org/loom/commit/3733fe3a207078b585421cd2a098e808fafaa817 8335789: [TESTBUG] XparColor.java test fails with Error. Parse Exception: Invalid or unrecognized bugid: @ Reviewed-by: aivanov ! test/jdk/java/awt/print/PrinterJob/XparColor.java Changeset: babf6df7 Branch: master Author: Liam Miller-Cushon Date: 2024-07-08 20:09:07 +0000 URL: https://git.openjdk.org/loom/commit/babf6df7d97e4beedb25e689634d999412c1e950 8334757: AssertionError: Missing type variable in where clause Reviewed-by: jlahoda, vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java + test/langtools/tools/javac/annotations/typeAnnotations/failures/CantAnnotateClassWithTypeVariable.java + test/langtools/tools/javac/annotations/typeAnnotations/failures/CantAnnotateClassWithTypeVariable.out Changeset: bb1f8a16 Branch: master Author: Xiaolong Peng Committer: Aleksey Shipilev Date: 2024-07-08 20:10:27 +0000 URL: https://git.openjdk.org/loom/commit/bb1f8a1698553d5962569ac8912edd0d7ef010dd 8335904: Fix invalid comment in ShenandoahLock Reviewed-by: shade ! src/hotspot/share/gc/shenandoah/shenandoahLock.cpp Changeset: 9c7a6eab Branch: master Author: Ioi Lam Date: 2024-07-08 20:14:26 +0000 URL: https://git.openjdk.org/loom/commit/9c7a6eabb93c570fdb74076edc931576ed6be3e0 8312125: Refactor CDS enum class handling Reviewed-by: matsaave, ccheung + src/hotspot/share/cds/cdsEnumKlass.cpp + src/hotspot/share/cds/cdsEnumKlass.hpp ! src/hotspot/share/cds/heapShared.cpp ! src/hotspot/share/cds/heapShared.hpp ! src/hotspot/share/oops/instanceKlass.cpp Changeset: 564a72e1 Branch: master Author: Thomas Schatzl Date: 2024-07-09 08:10:55 +0000 URL: https://git.openjdk.org/loom/commit/564a72e1dba0f145600c8e7eff66992fbf294df0 8335955: JDK-8335742 wrongly used a "JDK-" prefix in the problemlist bug number Reviewed-by: iwalulya ! test/hotspot/jtreg/ProblemList-Virtual.txt Changeset: 2a296475 Branch: master Author: Kevin Walls Date: 2024-07-09 08:25:00 +0000 URL: https://git.openjdk.org/loom/commit/2a2964759c73b3b9ab6afaad109383c89952977b 8334777: Test javax/management/remote/mandatory/notif/NotifReconnectDeadlockTest.java failed with NullPointerException Reviewed-by: cjplummer, dholmes ! test/jdk/javax/management/remote/mandatory/notif/NotifReconnectDeadlockTest.java Changeset: 8f62f31d Branch: master Author: Amit Kumar Date: 2024-07-09 08:26:25 +0000 URL: https://git.openjdk.org/loom/commit/8f62f31dff564289a2422d58e8ecd5062d443b81 8335906: [s390x] Test Failure: GTestWrapper.java Reviewed-by: stuefe ! src/hotspot/share/runtime/os.cpp Changeset: f3ff4f74 Branch: master Author: Severin Gehwolf Date: 2024-07-09 10:21:47 +0000 URL: https://git.openjdk.org/loom/commit/f3ff4f7427c3c3f5cb2a115a61462bb9d28de1cd 8335882: platform/cgroup/TestSystemSettings.java fails on Alpine Linux Reviewed-by: stuefe, mbaesken ! test/jdk/jdk/internal/platform/cgroup/TestSystemSettings.java Changeset: 0e0dfca2 Branch: master Author: Aleksei Voitylov Committer: Dmitry Samersoff Date: 2024-07-09 10:27:44 +0000 URL: https://git.openjdk.org/loom/commit/0e0dfca21f64ecfcb3e5ed7cdc2a173834faa509 8330806: test/hotspot/jtreg/compiler/c1/TestLargeMonitorOffset.java fails on ARM32 Reviewed-by: snazarki, dsamersoff ! src/hotspot/cpu/arm/c1_LIRAssembler_arm.cpp Changeset: 531a6d85 Branch: master Author: Volker Simonis Date: 2024-07-09 13:11:07 +0000 URL: https://git.openjdk.org/loom/commit/531a6d85b00b88688668ab1ced0db6ce0214a5f1 8335911: Document ccls indexer in doc/ide.md Reviewed-by: erikj ! doc/ide.html ! doc/ide.md Changeset: 7e11fb70 Branch: master Author: Kim Barrett Date: 2024-07-09 13:11:20 +0000 URL: https://git.openjdk.org/loom/commit/7e11fb702696df733ca89d325200f2e9414402d9 8335688: Fix -Wzero-as-null-pointer-constant warnings from fflush calls in jvmti tests Reviewed-by: jwaters, coleenp ! test/hotspot/jtreg/serviceability/jvmti/AddModuleUsesAndProvides/libAddModuleUsesAndProvidesTest.c ! test/hotspot/jtreg/serviceability/jvmti/GenerateEvents/libGenerateEvents1.cpp ! test/hotspot/jtreg/serviceability/jvmti/GenerateEvents/libGenerateEvents2.cpp ! test/hotspot/jtreg/serviceability/jvmti/GetClassFields/FilteredFields/libFilteredFieldsTest.cpp ! test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/MissedStackMapFrames/libMissedStackMapFrames.cpp ! test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRetransform/libRedefineRetransform.cpp ! test/hotspot/jtreg/serviceability/jvmti/events/FramePop/framepop02/libframepop02.cpp ! test/hotspot/jtreg/serviceability/jvmti/thread/GetStackTrace/get_stack_trace.hpp ! test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendResume1/libSuspendResume1.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassFields/getclfld007/getclfld007.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/FollowReferences/followref001/followref001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/FollowReferences/followref002/followref002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/FollowReferences/followref003/followref003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/FollowReferences/followref004/followref004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/FollowReferences/followref005/followref005.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/FollowReferences/followref006/followref006.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretbase/earlyretbase.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretfp/earlyretfp.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretint/earlyretint.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretlong/earlyretlong.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretobj/earlyretobj.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretstr/earlyretstr.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretvoid/earlyretvoid.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/GetAllStackTraces/getallstktr001/getallstktr001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/GetConstantPool/getcpool001/getcpool001.cpp Changeset: 14721244 Branch: master Author: Mark Powers Date: 2024-07-09 20:38:09 +0000 URL: https://git.openjdk.org/loom/commit/1472124489c841642996ae984e21c533ffec8091 8333364: Minor cleanup could be done in com.sun.crypto.provider Reviewed-by: mullan, valeriep ! src/java.base/share/classes/com/sun/crypto/provider/AESKeyGenerator.java ! src/java.base/share/classes/com/sun/crypto/provider/AESKeyWrap.java ! src/java.base/share/classes/com/sun/crypto/provider/AESKeyWrapPadded.java ! src/java.base/share/classes/com/sun/crypto/provider/ARCFOURCipher.java ! src/java.base/share/classes/com/sun/crypto/provider/ChaCha20Cipher.java ! src/java.base/share/classes/com/sun/crypto/provider/ChaCha20Poly1305Parameters.java ! src/java.base/share/classes/com/sun/crypto/provider/CipherBlockChaining.java ! src/java.base/share/classes/com/sun/crypto/provider/CipherCore.java ! src/java.base/share/classes/com/sun/crypto/provider/CipherTextStealing.java ! src/java.base/share/classes/com/sun/crypto/provider/ConstructKeys.java ! src/java.base/share/classes/com/sun/crypto/provider/DESCrypt.java ! src/java.base/share/classes/com/sun/crypto/provider/DESKeyFactory.java ! src/java.base/share/classes/com/sun/crypto/provider/DESedeKeyFactory.java ! src/java.base/share/classes/com/sun/crypto/provider/DESedeKeyGenerator.java ! src/java.base/share/classes/com/sun/crypto/provider/DESedeWrapCipher.java ! src/java.base/share/classes/com/sun/crypto/provider/DHKEM.java ! src/java.base/share/classes/com/sun/crypto/provider/DHKeyAgreement.java ! src/java.base/share/classes/com/sun/crypto/provider/DHKeyPairGenerator.java ! src/java.base/share/classes/com/sun/crypto/provider/ElectronicCodeBook.java ! src/java.base/share/classes/com/sun/crypto/provider/FeedbackCipher.java ! src/java.base/share/classes/com/sun/crypto/provider/GCTR.java ! src/java.base/share/classes/com/sun/crypto/provider/GHASH.java ! src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java ! src/java.base/share/classes/com/sun/crypto/provider/HmacCore.java ! src/java.base/share/classes/com/sun/crypto/provider/HmacMD5.java ! src/java.base/share/classes/com/sun/crypto/provider/HmacMD5KeyGenerator.java ! src/java.base/share/classes/com/sun/crypto/provider/HmacSHA1.java ! src/java.base/share/classes/com/sun/crypto/provider/HmacSHA1KeyGenerator.java ! src/java.base/share/classes/com/sun/crypto/provider/ISO10126Padding.java ! src/java.base/share/classes/com/sun/crypto/provider/JceKeyStore.java ! src/java.base/share/classes/com/sun/crypto/provider/KWUtil.java ! src/java.base/share/classes/com/sun/crypto/provider/KeyProtector.java ! src/java.base/share/classes/com/sun/crypto/provider/KeyWrapCipher.java ! src/java.base/share/classes/com/sun/crypto/provider/OAEPParameters.java ! src/java.base/share/classes/com/sun/crypto/provider/OutputFeedback.java ! src/java.base/share/classes/com/sun/crypto/provider/PBEKeyFactory.java ! src/java.base/share/classes/com/sun/crypto/provider/PBES1Core.java ! src/java.base/share/classes/com/sun/crypto/provider/PBES2Parameters.java ! src/java.base/share/classes/com/sun/crypto/provider/PBKDF2KeyImpl.java ! src/java.base/share/classes/com/sun/crypto/provider/PBMAC1Core.java ! src/java.base/share/classes/com/sun/crypto/provider/PKCS5Padding.java ! src/java.base/share/classes/com/sun/crypto/provider/Poly1305.java ! src/java.base/share/classes/com/sun/crypto/provider/RC2Crypt.java ! src/java.base/share/classes/com/sun/crypto/provider/RSACipher.java ! src/java.base/share/classes/com/sun/crypto/provider/SslMacCore.java ! src/java.base/share/classes/com/sun/crypto/provider/TlsKeyMaterialGenerator.java ! src/java.base/share/classes/com/sun/crypto/provider/TlsPrfGenerator.java Changeset: dcf4e0d5 Branch: master Author: Jaikiran Pai Date: 2024-07-10 03:30:19 +0000 URL: https://git.openjdk.org/loom/commit/dcf4e0d51f392afe2711223484e932e3826e8864 8335966: Remove incorrect problem listing of java/lang/instrument/NativeMethodPrefixAgent.java in ProblemList-Virtual.txt Reviewed-by: kevinw, amenkov ! test/jdk/ProblemList-Virtual.txt Changeset: b5909cab Branch: master Author: Koichi Sakata Date: 2024-07-10 05:57:11 +0000 URL: https://git.openjdk.org/loom/commit/b5909cabeef22954f4d9c642b1cbf288b3454562 8323242: Remove vestigial DONT_USE_REGISTER_DEFINES Reviewed-by: gli, kvn ! src/hotspot/cpu/zero/register_zero.hpp From ron.pressler at oracle.com Wed Jul 10 14:15:08 2024 From: ron.pressler at oracle.com (Ron Pressler) Date: Wed, 10 Jul 2024 14:15:08 +0000 Subject: [External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: References: Message-ID: <12ACDD24-C874-45B1-9142-DACAB1E78956@oracle.com> > On 9 Jul 2024, at 17:11, robert engels wrote: > > With a closable queue you can have natural synchronization so that all submitted items can be acked then any further reads will cause a ?queue closed exception? causing the reader to terminate. > > It is very similar in design to an executor service. You are talking about something quite different from the subject of this discussion. You?re talking about a mechanism for *terminating* threads. The discussion is about collecting the effectively meaningless bytes of ?effectively dead? *unterminated* threads. The only impact of that is on heap usage and observability, not on any functional thread behaviour. These two things are orthogonal. You may ask what the pros and cons of collecting ?effectively dead? threads are, given that there is no functional difference whether you do or don?t, but I?ll leave that for a separate discussion. ? Ron From robaho at icloud.com Wed Jul 10 14:52:15 2024 From: robaho at icloud.com (robert engels) Date: Wed, 10 Jul 2024 08:52:15 -0600 Subject: [External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: <12ACDD24-C874-45B1-9142-DACAB1E78956@oracle.com> References: <12ACDD24-C874-45B1-9142-DACAB1E78956@oracle.com> Message-ID: <1B3A651B-90B7-41AC-ADC6-358E8175CD93@icloud.com> Understood. Just helping the OP with a solution that doesn?t require ephemeral threads. > On Jul 10, 2024, at 8:15?AM, Ron Pressler wrote: > > ? > >> On 9 Jul 2024, at 17:11, robert engels wrote: >> >> With a closable queue you can have natural synchronization so that all submitted items can be acked then any further reads will cause a ?queue closed exception? causing the reader to terminate. >> >> It is very similar in design to an executor service. > > You are talking about something quite different from the subject of this discussion. You?re talking about a mechanism for *terminating* threads. The discussion is about collecting the effectively meaningless bytes of ?effectively dead? *unterminated* threads. The only impact of that is on heap usage and observability, not on any functional thread behaviour. These two things are orthogonal. > > You may ask what the pros and cons of collecting ?effectively dead? threads are, given that there is no functional difference whether you do or don?t, but I?ll leave that for a separate discussion. > > ? Ron From robaho at icloud.com Wed Jul 10 14:54:07 2024 From: robaho at icloud.com (robert engels) Date: Wed, 10 Jul 2024 08:54:07 -0600 Subject: [External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: <12ACDD24-C874-45B1-9142-DACAB1E78956@oracle.com> References: <12ACDD24-C874-45B1-9142-DACAB1E78956@oracle.com> Message-ID: Also, my original point were about observability (monitoring, detecting hung threads, lifecycle events, etc). I think that is the same as what Alan was referring too. > On Jul 10, 2024, at 8:15?AM, Ron Pressler wrote: > > ? > >> On 9 Jul 2024, at 17:11, robert engels wrote: >> >> With a closable queue you can have natural synchronization so that all submitted items can be acked then any further reads will cause a ?queue closed exception? causing the reader to terminate. >> >> It is very similar in design to an executor service. > > You are talking about something quite different from the subject of this discussion. You?re talking about a mechanism for *terminating* threads. The discussion is about collecting the effectively meaningless bytes of ?effectively dead? *unterminated* threads. The only impact of that is on heap usage and observability, not on any functional thread behaviour. These two things are orthogonal. > > You may ask what the pros and cons of collecting ?effectively dead? threads are, given that there is no functional difference whether you do or don?t, but I?ll leave that for a separate discussion. > > ? Ron From Alan.Bateman at oracle.com Wed Jul 10 14:59:53 2024 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 10 Jul 2024 15:59:53 +0100 Subject: More useful structured concurrency stack traces In-Reply-To: References: Message-ID: On 09/07/2024 19:50, Louis Wasserman wrote: > My understanding of the structured concurrency APIs now in preview is > that when a subtask is forked, exceptions thrown in that stack trace > will have stack traces going up to the beginning of that subtask, not > e.g. up the structured concurrency task tree. ?(My tests suggest this > is the case for simple virtual threads without structured > concurrency.) ?Most concurrency frameworks on the JVM that I?ve > encountered share the property that stack traces for exceptions don?t > trace through the entire causal chain ? and, not unrelatedly, that > developers struggle to debug concurrent applications, especially with > stack traces from production and not full debuggers attached. > > In some cases, like chained CompletableFutures, this seems necessary > to ensure that executing what amounts to a loop does not result in > stack traces that grow linearly with the number of chained futures.? > But when structured concurrency is involved, it seems more plausible > to me that the most useful possible stack traces would go up the tree > of tasks ? that is, whenever a task was forked, the stack trace would > look roughly as if it were a normal/sequential/direct invocation of > the task.? This could conceivably cause stack overflows where they > didn?t happen before, but only for code that violates the expectations > we have around normal sequential code: you can?t recurse unboundedly; > use iteration instead. > > I?m curious if there are ways we could make the upcoming structured > concurrency APIs give those stack traces all the way up the tree, or > provide hooks to enable you to do that yourself. This project has given some thought to this topic, has prototyped a number of APIs but needs further exploration before deciding whether to expose anything or not. One of the prototypes allowed a thread to get the stack traces of the owners of the its enclosing scopes. The owner (essentially parent thread) is likely to be blocked in join but it may not be. There were also some thoughts given to captured stack traces or water marks at fork time. Right now the only thing that is exposed is the (usually shallow) tree in the JSON thread dump (jcmd Thread.dump_to_file -format=json ) where you can see the stack trace of the thread exactly a main tasks and the stack traces of threads executing the subtasks. -Alan > Last year?s JVMLS talk on Continuations Under the Covers demonstrated > how stacks were redesigned in ways that frequently and efficiently > snapshot the stack itself ? not just the trace, but the thing that > includes all the variables in use.? There?s a linked list of > StackChunks, and all but maybe the top of the stack has those elements > frozen, etc, and the top of the stack gets frozen when the thread is > yielded.? Without certainty about how stack traces are managed in the > JVM today, I would imagine you could possibly do something similar ? > you?d add a way to cheaply snapshot a reference to the current stack > trace that can be traversed later.? If you?re willing to hold on to > all the references currently on the stack ? which might be acceptable > for the structured concurrency case in particular, where you might be > able to assume you?ll return to the parent task and its stack at some > point ? you might be able to do this by simply wrapping the existing > StackChunks.? Then, each `fork` or `StructuredTaskScope` creation > might snapshot the current call stack, and you?d stitch together the > stack traces later?somewhere.? That part is a little more open ended: > would you add a new variant of `fillInStackTrace`?? Would it only > apply to exceptions that bubbled up to the task scope?? Or would we be > adding new semantics to what happens when you throw an exception or > walk the stack in general?? The most plausible vision I have at this > point is an API that spawns a virtual thread which receives a stack > trace of some sort ? or perhaps snapshots the current stack trace ? > and prepends that trace to all stack traces within the virtual > thread?s execution. > > I suppose this is doable today if you?re willing to pay the > performance cost of explicitly getting the current stack trace every > time you fork a task or start a scope.? That is kind of antithetical > to the point of virtual threads ? making forking tasks very efficient > ? but it?s something you might be willing to turn on during testing. > > Right now, my inspiration for this question is attempting to improve > the stack trace situation with Kotlin coroutines, where Google > production apps have complained about the difficulty of debugging with > the current stack traces.? But this is something I'd expect to apply > equally well to all JVM languages: the ability to snapshot and string > together stack trace causal chains like this in production could > significantly improve the experience of debugging concurrent code. > > -- > Louis Wasserman -------------- next part -------------- An HTML attachment was scrubbed... URL: From outsider404 at gmail.com Wed Jul 10 19:56:29 2024 From: outsider404 at gmail.com (Michal Domagala) Date: Wed, 10 Jul 2024 21:56:29 +0200 Subject: [External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: References: <12ACDD24-C874-45B1-9142-DACAB1E78956@oracle.com> Message-ID: Hi, My issue is accepted as Bug ID: JDK-8336061 Virtual threads cannot be GC'ed before they terminate (java.com) and solved as documentation defect. Still one issue is not clear to me. Is VT strongly referenced because being blocked and GC'ed is not useful or is problematic to implement? There were voices in discussion that VT GC is surprising for developers. For that reason I showed my case. I wanted to present that "closing" blocking queue by nullifying and GC does not need synchronization. Unsynchronized code is less prone to errors than code with synchronization. But there are voices that garbage collection "alive" VT is problematic: "Finalization is one topic. Another is Cleaner actions that may run while a resource is in an inconsistent state." I don't know this area so I can't deny it. I checked that the blocked task created by Executors. newVirtualThreadPerTaskExecutor().submit() is GCed. Does it mean that: 1) Executors.newVirtualThreadPerTaskExecutor().submit() does not create VT? 2) VT created by Executors API is different from that created by Thread API and can GCed without problem with finalization and Cleaner action? 3) VT created by Executors API is has the same problem as created by Thread API and in future all VT will be strongly referenced? 4) Is it a fairy tale that VT GC is problematic? ?r., 10 lip 2024 o 16:54 robert engels napisa?(a): > Also, my original point were about observability (monitoring, detecting > hung threads, lifecycle events, etc). I think that is the same as what Alan > was referring too. > > > On Jul 10, 2024, at 8:15?AM, Ron Pressler > wrote: > > > > ? > > > >> On 9 Jul 2024, at 17:11, robert engels wrote: > >> > >> With a closable queue you can have natural synchronization so that all > submitted items can be acked then any further reads will cause a ?queue > closed exception? causing the reader to terminate. > >> > >> It is very similar in design to an executor service. > > > > You are talking about something quite different from the subject of this > discussion. You?re talking about a mechanism for *terminating* threads. The > discussion is about collecting the effectively meaningless bytes of > ?effectively dead? *unterminated* threads. The only impact of that is on > heap usage and observability, not on any functional thread behaviour. These > two things are orthogonal. > > > > You may ask what the pros and cons of collecting ?effectively dead? > threads are, given that there is no functional difference whether you do or > don?t, but I?ll leave that for a separate discussion. > > > > ? Ron > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bronee at gmail.com Wed Jul 10 20:57:02 2024 From: bronee at gmail.com (Brian S O'Neill) Date: Wed, 10 Jul 2024 13:57:02 -0700 Subject: [External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: References: <12ACDD24-C874-45B1-9142-DACAB1E78956@oracle.com> Message-ID: I think there's also the question of efficiency. If every new VT needs to be registered, then this adds a bit of overhead and makes them slightly less useful for running short-lived tasks. On 2024-07-10 12:56 PM, Michal Domagala wrote: > Hi, > > My issue is accepted as Bug ID: JDK-8336061 Virtual threads cannot be > GC'ed before they terminate (java.com) > ?and > solved as documentation defect. > > Still one issue is not clear to me. Is VT strongly referenced because > being blocked and GC'ed is not useful or is problematic to implement? > > There were voices in discussion that VT GC? is surprising for > developers. For that reason I showed my case. I wanted to present that > "closing" blocking queue by nullifying and GC does not need > synchronization. Unsynchronized?code is less prone to errors than code > with synchronization. > > But there are voices that garbage collection "alive" VT is problematic: > "Finalization is one topic. Another is Cleaner actions that may run > while a resource is in an inconsistent state." I don't know this area so > I can't deny it. > > I checked that the blocked task created by > Executors.newVirtualThreadPerTaskExecutor().submit()?is GCed. Does it > mean that: > > 1) Executors.newVirtualThreadPerTaskExecutor().submit() does not create VT? > 2) VT created by Executors API is different from that created by Thread > API and can GCed without problem with finalization and Cleaner action? > 3) VT created by Executors API is has the same problem as created by > Thread API and in future all VT will be strongly referenced? > 4) Is it a fairy tale that VT GC is problematic? > From outsider404 at gmail.com Wed Jul 10 22:11:37 2024 From: outsider404 at gmail.com (Michal Domagala) Date: Thu, 11 Jul 2024 00:11:37 +0200 Subject: [External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: References: <12ACDD24-C874-45B1-9142-DACAB1E78956@oracle.com> Message-ID: It is a reason to NOT hold strong reference to VT created by Executor API but NOT a reason to hold strong reference to VT created by Thread API. Assume GC'able VT is risky due "Finalization is one topic. Another is Cleaner actions". Assume 99% VT is created by Executor API and 1% is created by Thread API If I can afford 99% VT is risky GC'ed, I can afford 100% VT is risky GC'ed and keep system simple without strong reference to any VT ?r., 10 lip 2024 o 22:57 Brian S O'Neill napisa?(a): > I think there's also the question of efficiency. If every new VT needs > to be registered, then this adds a bit of overhead and makes them > slightly less useful for running short-lived tasks. > > On 2024-07-10 12:56 PM, Michal Domagala wrote: > > Hi, > > > > My issue is accepted as Bug ID: JDK-8336061 Virtual threads cannot be > > GC'ed before they terminate (java.com) > > and > > solved as documentation defect. > > > > Still one issue is not clear to me. Is VT strongly referenced because > > being blocked and GC'ed is not useful or is problematic to implement? > > > > There were voices in discussion that VT GC is surprising for > > developers. For that reason I showed my case. I wanted to present that > > "closing" blocking queue by nullifying and GC does not need > > synchronization. Unsynchronized code is less prone to errors than code > > with synchronization. > > > > But there are voices that garbage collection "alive" VT is problematic: > > "Finalization is one topic. Another is Cleaner actions that may run > > while a resource is in an inconsistent state." I don't know this area so > > I can't deny it. > > > > I checked that the blocked task created by > > Executors.newVirtualThreadPerTaskExecutor().submit() is GCed. Does it > > mean that: > > > > 1) Executors.newVirtualThreadPerTaskExecutor().submit() does not create > VT? > > 2) VT created by Executors API is different from that created by Thread > > API and can GCed without problem with finalization and Cleaner action? > > 3) VT created by Executors API is has the same problem as created by > > Thread API and in future all VT will be strongly referenced? > > 4) Is it a fairy tale that VT GC is problematic? > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From volkan at yazi.ci Thu Jul 11 08:04:45 2024 From: volkan at yazi.ci (=?UTF-8?B?Vm9sa2FuIFlhesSxY8Sx?=) Date: Thu, 11 Jul 2024 10:04:45 +0200 Subject: Replacing monitors with locks Message-ID: Hello, I interpreted the Quality Outreach Heads-up for the upcoming Java 23 , sharing improvements on the way Loom handles monitors, as Loom will eventually handle monitors (in particular, carrier thread pinning issues) decently and remove the need to replace all `synchronized` usages with locks. Yet Attila Kelemen pointed in a Log4j ticket to this particular `loom-dev` post by Ron Pressler : *"Unfortunately, while monitors would no longer pin virtual threads, their performance would suffer significantly when using virtual threads, and in general we recommend using j.u.c locks in new code anyway, because that implementation is likely to see further improvement, while monitors probably won?t."* Am I right to conclude that even though the monitors will eventually no longer pin threads, replacing them with locks is still (and also will be so for the foreseeable future?) the recommended practice for performance and sustainability reasons? Kind regards. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dannyt at netflix.com Thu Jul 11 08:20:11 2024 From: dannyt at netflix.com (Danny Thomas) Date: Thu, 11 Jul 2024 18:20:11 +1000 Subject: Replacing monitors with locks In-Reply-To: References: Message-ID: I was going to ask the same question. We are planning a blog post on our experience with virtual threads, and wanted to clarify so we can add recommendations and pass them on to upstream library producers when we're reporting bugs/performance issues. On Thu, Jul 11, 2024 at 6:04?PM Volkan Yaz?c? wrote: > Hello, > > I interpreted the Quality Outreach Heads-up for the upcoming Java 23 > , sharing improvements > on the way Loom handles monitors, as Loom will eventually handle monitors > (in particular, carrier thread pinning issues) decently and remove the need > to replace all `synchronized` usages with locks. Yet Attila Kelemen > pointed in a Log4j ticket > > to this particular `loom-dev` post by Ron Pressler > : > > *"Unfortunately, while monitors would no longer pin virtual threads, their > performance would suffer significantly when using virtual threads, and in > general we recommend using j.u.c locks in new code anyway, because that > implementation is likely to see further improvement, while monitors > probably won?t."* > > Am I right to conclude that even though the monitors will eventually no > longer pin threads, replacing them with locks is still (and also will be so > for the foreseeable future?) the recommended practice for performance and > sustainability reasons? > > Kind regards. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Thu Jul 11 08:36:54 2024 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 11 Jul 2024 09:36:54 +0100 Subject: Replacing monitors with locks In-Reply-To: References: Message-ID: <1e295680-55b9-4b99-878f-4004bd176eb5@oracle.com> On 11/07/2024 09:20, Danny Thomas wrote: > I was going to ask the same question. We are planning a blog post on > our experience with virtual threads, and wanted to clarify so we can > add recommendations and pass them on to upstream library producers > when we're reporting bugs/performance issues. > I think the guidance in JEP 425 stands for now. As you probably know, there is work in progress (and EA builds available) to address the pinning issue with object monitors. That will required updating guidance when the time comes to proposing the changes for main line and a JDK release. -Alan. From Alan.Bateman at oracle.com Thu Jul 11 09:00:41 2024 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 11 Jul 2024 10:00:41 +0100 Subject: [External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: References: <12ACDD24-C874-45B1-9142-DACAB1E78956@oracle.com> Message-ID: <58e21790-551d-4717-ba16-17ccecbdaf22@oracle.com> On 10/07/2024 20:56, Michal Domagala wrote: > Hi, > > My issue is accepted as Bug ID: JDK-8336061 Virtual threads cannot be > GC'ed before they terminate (java.com) > ?and > solved as documentation defect. You can view the issue in JBS here: https://bugs.openjdk.org/browse/JDK-8336061 As noted, we missed an update to a paragraph when copying text from JEP 425/436 to JEP 444 so it wasn't aligned with the change summarized in the History section of JEP 444. That has been fixed. Otherwise, we can only close the JBS issue for now as support for some kind of ephemeral threads is definitely future exploration. > > Still one issue is not clear to me. Is VT strongly referenced because > being blocked and GC'ed is not useful or is problematic to implement? > > There were voices in discussion that VT GC is surprising for > developers. For that reason I showed my case. I wanted to present that > "closing" blocking queue by nullifying and GC does not need > synchronization. Unsynchronized?code is less prone to errors than code > with synchronization. In some cases then having the producer offering a special element to mean "done" can work as a signal to the consumer to shutdown. Some form of closable channel would be similar. I think this project has a good handle on possible use-cases so we know well that it's not as simple as this in some cases. In the Golang world the phrases used are "forgotten sender" and "abandoned receiver" when goroutines "leak". This seems to lead to complicated recipes for signalling and shutdown. Java has had threads since JDK 1.0 and it doesn't seem to arise as often, one reason could be that you can keep a reference to a Thread, another might be that the serviceability/observability support is good so it is possible to identify orphaned threads and their stack traces, maybe reason about why they did not terminate when expected. > > But there are voices that garbage collection "alive" VT is > problematic: "Finalization is one topic. Another is Cleaner actions > that may run while a resource is in an inconsistent state." I don't > know this area so I can't deny it. > > I checked that the blocked task created by > Executors.newVirtualThreadPerTaskExecutor().submit()?is GCed. Considerable time was spent on this topic before making virtual threads a permanent feature in JDK 21. We decided to leave this as is for now. In the case of a Thread-Per-Task-Executor (TPTE) then it keeps a reference to all threads executing tasks. It has to because of shutdownNow or close that may have to interrupt all threads. A TPTE is typically stored somewhere, often a static final field, or it will be used with try-with-resources. So once a TPTE is strongly reachable then it will ensure that all virtual threads executing tasks in that executor are keep reachable. There is a similar story for other "unowned" executor service implementations. For now, unowned executor services are weakly tracked for observability purposes. There is an argument that they should be strongly tracked when there is at least one thread but that adds some bookkeeping overhead, esp. when oscillating between zero and a single thread. So everything you are probing here is possible future work. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Thu Jul 11 10:17:08 2024 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 11 Jul 2024 11:17:08 +0100 Subject: Httpserver performance In-Reply-To: References: Message-ID: On 05/07/2024 18:41, Robert Engels wrote: > Some that follow this list might be interested in the latest release > of my httpserver - which is a port of the JDK one - designed for > virtual threads (no async, no synchronized blocks) at > https://github.com/robaho/httpserver > > It shows nearly 3x performance on the tech empower low-level benchmarks. > > I attribute most of the performance gain due to it supporting http > pipelining, which I think should be easy to backport in the JDK > version. There are some other micro improvements that help quite a bit > for these types of tests. As it is, it is able to saturate a 1gbit > ethernet link. Thanks for the post, it's interesting to this fork being used for performance testing. As you probably know, the original motive for this HTTP server was something basic to support XML web services callbacks. Today it provides an on-ramp to web development with local testing. It's also useful for other testing too, or just to serve up API docs or other content. It's never been a goal to have it be competitive in either features or performances when compared to other HTTP servers. Just saying to explain why there hasn't been a interest on net-dev to add pipelining or other features. -Alan From robaho at me.com Thu Jul 11 11:34:33 2024 From: robaho at me.com (robert engels) Date: Thu, 11 Jul 2024 05:34:33 -0600 Subject: Httpserver performance In-Reply-To: References: Message-ID: <35AF3AB9-C58A-4BD5-A88A-60F3902B0F8E@me.com> It was done more out of curiosity. I know the code fairly well so I was surprised in the low performance of the JDK httpserver so I set about to figure out why. > On Jul 11, 2024, at 4:17?AM, Alan Bateman wrote: > > ?On 05/07/2024 18:41, Robert Engels wrote: >> Some that follow this list might be interested in the latest release of my httpserver - which is a port of the JDK one - designed for virtual threads (no async, no synchronized blocks) at https://github.com/robaho/httpserver >> >> It shows nearly 3x performance on the tech empower low-level benchmarks. >> >> I attribute most of the performance gain due to it supporting http pipelining, which I think should be easy to backport in the JDK version. There are some other micro improvements that help quite a bit for these types of tests. As it is, it is able to saturate a 1gbit ethernet link. > > Thanks for the post, it's interesting to this fork being used for performance testing. As you probably know, the original motive for this HTTP server was something basic to support XML web services callbacks. Today it provides an on-ramp to web development with local testing. It's also useful for other testing too, or just to serve up API docs or other content. It's never been a goal to have it be competitive in either features or performances when compared to other HTTP servers. Just saying to explain why there hasn't been a interest on net-dev to add pipelining or other features. > > -Alan From outsider404 at gmail.com Thu Jul 11 11:38:15 2024 From: outsider404 at gmail.com (Michal Domagala) Date: Thu, 11 Jul 2024 13:38:15 +0200 Subject: [External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: <58e21790-551d-4717-ba16-17ccecbdaf22@oracle.com> References: <12ACDD24-C874-45B1-9142-DACAB1E78956@oracle.com> <58e21790-551d-4717-ba16-17ccecbdaf22@oracle.com> Message-ID: > In some cases then having the producer offering a special element to mean "done" can work as a signal to the consumer to shutdown. If the producer decides about shutdown, poison pill signal is a well known solution: simple and synchronization-less. If the other party decides to shut down, the poison pill does not work. Shutdown needs synchronization - or ephemeral VT shutdowned by GC. Regardless of the main issue, I understand that VT GC is problematic. JEP 444 is modified and GC paragraph is removed. VT created by Thread API is strongly referenced to avoid finalization problems VT created by Executors.newVirtualThreadPerTaskExecutor() or Executors.newThreadPerTaskExecutor(Thread.ofVirtual().factory()) are not strongly referenced due oscillating nature of Executor. Moreover, Executor and submit product Future is AutoCloseable. Being autocloseable + try-with-resource means it is easy to avoid finalization problems in code. Before try-with-resources, it was well known that some resources, like file descriptors, should not be released by GC. It was the developer's responsibility to close unused file descriptors. Try-with-resources simplifies safe implementation, but the rule is still valid. If releasing something by GC is problematic, it is the developer responsibility to provide safe implementation. In my opinion, wrong decisions are made. Having all VT ephemeral simplifies the system and allows a simpler programming model. If releasing resources by GC is problematic, it should be a developer problem, not JVM problem. If some VT are strongly referenced and some not, and this behavior is undocumented, whole system is unpredictable for developers, who are not subscribers of this group Thanks everybody for collaboration PS. I JEP 444 I still see GC root paragraph: Unlike platform thread stacks, virtual thread stacks are not GC roots. Thus the references they contain are not traversed in a stop-the-world pause by garbage collectors, such as G1, that perform concurrent heap scanning. What does it mean? I do not understand this paragraph. Will G1 clean VT or not? czw., 11 lip 2024 o 11:00 Alan Bateman napisa?(a): > On 10/07/2024 20:56, Michal Domagala wrote: > > Hi, > > My issue is accepted as Bug ID: JDK-8336061 Virtual threads cannot be > GC'ed before they terminate (java.com) > and > solved as documentation defect. > > > You can view the issue in JBS here: > https://bugs.openjdk.org/browse/JDK-8336061 > > As noted, we missed an update to a paragraph when copying text from JEP > 425/436 to JEP 444 so it wasn't aligned with the change summarized in the > History section of JEP 444. That has been fixed. Otherwise, we can only > close the JBS issue for now as support for some kind of ephemeral threads > is definitely future exploration. > > > Still one issue is not clear to me. Is VT strongly referenced because > being blocked and GC'ed is not useful or is problematic to implement? > > There were voices in discussion that VT GC is surprising for developers. > For that reason I showed my case. I wanted to present that "closing" > blocking queue by nullifying and GC does not need synchronization. > Unsynchronized code is less prone to errors than code with synchronization. > > > In some cases then having the producer offering a special element to mean > "done" can work as a signal to the consumer to shutdown. Some form of > closable channel would be similar. I think this project has a good handle > on possible use-cases so we know well that it's not as simple as this in > some cases. > > In the Golang world the phrases used are "forgotten sender" and "abandoned > receiver" when goroutines "leak". This seems to lead to complicated recipes > for signalling and shutdown. Java has had threads since JDK 1.0 and it > doesn't seem to arise as often, one reason could be that you can keep a > reference to a Thread, another might be that the > serviceability/observability support is good so it is possible to identify > orphaned threads and their stack traces, maybe reason about why they did > not terminate when expected. > > > But there are voices that garbage collection "alive" VT is problematic: > "Finalization is one topic. Another is Cleaner actions that may run while a > resource is in an inconsistent state." I don't know this area so I can't > deny it. > > I checked that the blocked task created by Executors. > newVirtualThreadPerTaskExecutor().submit() is GCed. > > > Considerable time was spent on this topic before making virtual threads a > permanent feature in JDK 21. We decided to leave this as is for now. In the > case of a Thread-Per-Task-Executor (TPTE) then it keeps a reference to all > threads executing tasks. It has to because of shutdownNow or close that may > have to interrupt all threads. A TPTE is typically stored somewhere, often > a static final field, or it will be used with try-with-resources. So once a > TPTE is strongly reachable then it will ensure that all virtual threads > executing tasks in that executor are keep reachable. There is a similar > story for other "unowned" executor service implementations. For now, > unowned executor services are weakly tracked for observability purposes. > There is an argument that they should be strongly tracked when there is at > least one thread but that adds some bookkeeping overhead, esp. when > oscillating between zero and a single thread. So everything you are probing > here is possible future work. > > -Alan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron.pressler at oracle.com Thu Jul 11 15:33:26 2024 From: ron.pressler at oracle.com (Ron Pressler) Date: Thu, 11 Jul 2024 15:33:26 +0000 Subject: [External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: References: <12ACDD24-C874-45B1-9142-DACAB1E78956@oracle.com> <58e21790-551d-4717-ba16-17ccecbdaf22@oracle.com> Message-ID: <2F579C4D-B83F-4AC8-88BB-03723A34BD18@oracle.com> > On 11 Jul 2024, at 12:38, Michal Domagala wrote: > > Regardless of the main issue, I understand that VT GC is problematic. JEP 444 is modified and GC paragraph is removed. > VT created by Thread API is strongly referenced to avoid finalization problems The reason for keeping a reference to virtual threads by default is not finalization but observability. The cost of holding a strong reference is near zero because we can rely on the same strong references in constructs such as Executors and StructuredTaskScope, while adding WeakReferences would come at a cost. > > What does it mean? I do not understand this paragraph. Will G1 clean VT or not? In most cases it will not because we keep a reference to the thread for observability unless you turn that off with a system property. ? Ron From ron.pressler at oracle.com Thu Jul 11 15:36:19 2024 From: ron.pressler at oracle.com (Ron Pressler) Date: Thu, 11 Jul 2024 15:36:19 +0000 Subject: More useful structured concurrency stack traces In-Reply-To: References: Message-ID: <92F6ABCE-6250-49F2-99AB-2614BAB5BED5@oracle.com> > On 9 Jul 2024, at 19:50, Louis Wasserman wrote: > > My understanding of the structured concurrency APIs now in preview is that when a subtask is forked, exceptions thrown in that stack trace will have stack traces going up to the beginning of that subtask, not e.g. up the structured concurrency task tree. (My tests suggest this is the case for simple virtual threads without structured concurrency.) If the exception is of interest to the owner scope, then the stack trace will go ?up the tree?, since when exceptions are propagated through scopes they are wrapped by the scope, which adds the relevant stack trace of the scope owner?s thread. ? Ron From outsider404 at gmail.com Thu Jul 11 17:07:44 2024 From: outsider404 at gmail.com (Michal Domagala) Date: Thu, 11 Jul 2024 19:07:44 +0200 Subject: [External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: <2F579C4D-B83F-4AC8-88BB-03723A34BD18@oracle.com> References: <12ACDD24-C874-45B1-9142-DACAB1E78956@oracle.com> <58e21790-551d-4717-ba16-17ccecbdaf22@oracle.com> <2F579C4D-B83F-4AC8-88BB-03723A34BD18@oracle.com> Message-ID: > The reason for keeping a reference to virtual threads by default is not finalization but observability. The cost of holding a strong reference is near zero because we can rely on the same strong references in constructs such as Executors and StructuredTaskScope, while adding WeakReferences would come at a cost. Got it. Observability needs reference. As VT can be plenty, they are strongly referenced, to avoid the cost of weak references. Comparing, VT created by Executors are observable because Executors are referenced weakly by jdk.internal.vm.ThreadContainers#CONTAINER_REGISTRY I deduce that number of Executors is expected to be smaller than the number of VTs and the cost of weak reference is acceptable. I can't help feeling that VT could be freely GC'able, but when it was realized that observability without strong reference is costly, narration was changed and GC'able VT became surprising for developers etc. czw., 11 lip 2024 o 17:33 Ron Pressler napisa?(a): > > > > On 11 Jul 2024, at 12:38, Michal Domagala wrote: > > > > Regardless of the main issue, I understand that VT GC is problematic. > JEP 444 is modified and GC paragraph is removed. > > VT created by Thread API is strongly referenced to avoid finalization > problems > > The reason for keeping a reference to virtual threads by default is not > finalization but observability. The cost of holding a strong reference is > near zero because we can rely on the same strong references in constructs > such as Executors and StructuredTaskScope, while adding WeakReferences > would come at a cost. > > > > > What does it mean? I do not understand this paragraph. Will G1 clean VT > or not? > > In most cases it will not because we keep a reference to the thread for > observability unless you turn that off with a system property. > > ? Ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From outsider404 at gmail.com Thu Jul 11 18:40:42 2024 From: outsider404 at gmail.com (Michal Domagala) Date: Thu, 11 Jul 2024 20:40:42 +0200 Subject: [External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: <2F579C4D-B83F-4AC8-88BB-03723A34BD18@oracle.com> References: <12ACDD24-C874-45B1-9142-DACAB1E78956@oracle.com> <58e21790-551d-4717-ba16-17ccecbdaf22@oracle.com> <2F579C4D-B83F-4AC8-88BB-03723A34BD18@oracle.com> Message-ID: czw., 11 lip 2024 o 17:33 Ron Pressler napisa?(a): > > > > On 11 Jul 2024, at 12:38, Michal Domagala wrote: > > > > PS. I JEP 444 I still see GC root paragraph: > > > Unlike platform thread stacks, virtual thread stacks are not GC roots. > Thus the references they contain are not traversed in a stop-the-world > pause by garbage collectors, such as G1, that perform concurrent heap > scanning. > > > What does it mean? I do not understand this paragraph. Will G1 clean VT > or not? > > > In most cases it will not because we keep a reference to the thread for > observability unless you turn that off with a system property. I must admit I do not undestand it. "Unlike platform thread stacks, virtual thread stacks are not GC roots. " PT stacks are GC roots, VT stacks are not. Clear "Thus the references they contain are not traversed in a stop-the-world pause by garbage collectors" PT stack references are traversed by GC, VT stack references are not traversed. Clear. GC starts from GC root and travers all references. Each object encountered on the road is alive, all others are abandoned. Clear. Live references survive, abandoned are collected. Clear. GC travers all PT references and saves live ones against collection. GC does not travers VT references. They are not marked as alive. They are treated as abandoned and collected. After the GC phase, all VT references are null. Nonsense. Where is the mistake in my reasoning? -------------- next part -------------- An HTML attachment was scrubbed... URL: From robin.bygrave at gmail.com Thu Jul 11 23:13:49 2024 From: robin.bygrave at gmail.com (Rob Bygrave) Date: Fri, 12 Jul 2024 11:13:49 +1200 Subject: Httpserver performance In-Reply-To: <35AF3AB9-C58A-4BD5-A88A-60F3902B0F8E@me.com> References: <35AF3AB9-C58A-4BD5-A88A-60F3902B0F8E@me.com> Message-ID: > out of curiosity I hope it becomes more than that :) For example, I'd say that today a HttpServer does not need to support the Servlet Spec (e.g. Helidon 4 SE HttpServer), and all that I'd look to add on top of JDK HttpServer is a "Routing Layer". A lot of deployed services are not directly internet facing but instead have gateways in front of them so imo we frequently don't need more http features (like http3 etc). Getting these changes in and JDK HttpServer could be pretty competitive for a lot of cases due to its minimalism. On Thu, 11 Jul 2024 at 23:34, robert engels wrote: > It was done more out of curiosity. I know the code fairly well so I was > surprised in the low performance of the JDK httpserver so I set about to > figure out why. > > > On Jul 11, 2024, at 4:17?AM, Alan Bateman > wrote: > > > > ?On 05/07/2024 18:41, Robert Engels wrote: > >> Some that follow this list might be interested in the latest release of > my httpserver - which is a port of the JDK one - designed for virtual > threads (no async, no synchronized blocks) at > https://github.com/robaho/httpserver > >> > >> It shows nearly 3x performance on the tech empower low-level benchmarks. > >> > >> I attribute most of the performance gain due to it supporting http > pipelining, which I think should be easy to backport in the JDK version. > There are some other micro improvements that help quite a bit for these > types of tests. As it is, it is able to saturate a 1gbit ethernet link. > > > > Thanks for the post, it's interesting to this fork being used for > performance testing. As you probably know, the original motive for this > HTTP server was something basic to support XML web services callbacks. > Today it provides an on-ramp to web development with local testing. It's > also useful for other testing too, or just to serve up API docs or other > content. It's never been a goal to have it be competitive in either > features or performances when compared to other HTTP servers. Just saying > to explain why there hasn't been a interest on net-dev to add pipelining or > other features. > > > > -Alan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robaho at me.com Thu Jul 11 23:18:10 2024 From: robaho at me.com (robert engels) Date: Thu, 11 Jul 2024 17:18:10 -0600 Subject: Httpserver performance In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From duke at openjdk.org Fri Jul 12 09:34:36 2024 From: duke at openjdk.org (duke) Date: Fri, 12 Jul 2024 09:34:36 GMT Subject: git: openjdk/loom: fibers: 36 new changesets Message-ID: Changeset: a44b60c8 Branch: fibers Author: Matthias Baesken Date: 2024-07-10 07:53:52 +0000 URL: https://git.openjdk.org/loom/commit/a44b60c8c14ad998e51239f48e64779304aaac50 8335778: runtime/ClassInitErrors/TestStackOverflowDuringInit.java fails on ppc64 platforms after JDK-8334545 Reviewed-by: dholmes, asteiner ! test/hotspot/jtreg/runtime/ClassInitErrors/TestStackOverflowDuringInit.java Changeset: 537d20af Branch: fibers Author: Jan Lahoda Date: 2024-07-10 09:55:56 +0000 URL: https://git.openjdk.org/loom/commit/537d20afbff255489a7b1bdb0410b9d1aba715b7 8335766: Switch case with pattern matching and guard clause compiles inconsistently Reviewed-by: abimpoudis ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java ! test/langtools/tools/javac/patterns/DisambiguatePatterns.java Changeset: e0fb9494 Branch: fibers Author: Erik Gahlin Date: 2024-07-10 14:28:20 +0000 URL: https://git.openjdk.org/loom/commit/e0fb949460d0c7e2ab1697a6466e7d4831a20a33 8335779: JFR: Hide sleep events Reviewed-by: mgronlun ! src/hotspot/share/jfr/support/jfrIntrinsics.hpp ! src/hotspot/share/runtime/objectMonitor.cpp - src/jdk.jfr/share/classes/jdk/jfr/internal/HiddenWait.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/JVM.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/JVMSupport.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/MetadataRepository.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/OngoingStream.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/RecordingInput.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/RepositoryFiles.java + src/jdk.jfr/share/classes/jdk/jfr/internal/management/HiddenWait.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/management/StreamBarrier.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/util/Utils.java ! src/jdk.management.jfr/share/classes/jdk/management/jfr/DownLoadThread.java ! src/jdk.management.jfr/share/classes/jdk/management/jfr/FileDump.java + test/jdk/jdk/jfr/jvm/TestHiddenWait.java Changeset: e6c5aa7a Branch: fibers Author: Christian Stein Date: 2024-07-10 15:12:49 +0000 URL: https://git.openjdk.org/loom/commit/e6c5aa7a6cb54c647d261facdcffa6a410849627 8336012: Fix usages of jtreg-reserved properties Reviewed-by: jjg ! test/jdk/java/lang/invoke/PrivateInvokeTest.java Changeset: fb9a227e Branch: fibers Author: Doug Simon Date: 2024-07-10 15:34:27 +0000 URL: https://git.openjdk.org/loom/commit/fb9a227e02ebf826edb762283e15dd7e402f8433 8313909: [JVMCI] assert(cp->tag_at(index).is_unresolved_klass()) in lookupKlassInPool Reviewed-by: yzheng, never ! src/hotspot/share/jvmci/jvmciCompilerToVM.cpp Changeset: fb66716a Branch: fibers Author: Axel Boldt-Christmas Date: 2024-07-10 16:12:40 +0000 URL: https://git.openjdk.org/loom/commit/fb66716a1bc914db194c5b0b833cc2317704f166 8331725: ubsan: pc may not always be the entry point for a VtableStub Reviewed-by: kvn, mbaesken ! src/hotspot/share/code/vtableStubs.cpp ! src/hotspot/share/code/vtableStubs.hpp Changeset: 7ab96c74 Branch: fibers Author: Patricio Chilano Mateo Date: 2024-07-10 16:26:16 +0000 URL: https://git.openjdk.org/loom/commit/7ab96c74e2c39f430a5c2f65a981da7314a2385b 8335409: Can't allocate and retain memory from resource area in frame::oops_interpreted_do oop closure after 8329665 Reviewed-by: dholmes, stuefe, coleenp, shade ! src/hotspot/share/interpreter/oopMapCache.cpp ! src/hotspot/share/interpreter/oopMapCache.hpp ! src/hotspot/share/runtime/frame.cpp Changeset: 66db7156 Branch: fibers Author: Joe Darcy Date: 2024-07-10 16:36:39 +0000 URL: https://git.openjdk.org/loom/commit/66db71563c3ebd715a1192a9b399b618d7bdb8d0 8335637: Add explicit non-null return value expectations to Object.toString() Reviewed-by: jpai, alanb, smarks, prappo ! src/java.base/share/classes/java/lang/Object.java Changeset: 242f1133 Branch: fibers Author: Yudi Zheng Date: 2024-07-10 19:42:23 +0000 URL: https://git.openjdk.org/loom/commit/242f1133f8e1b373de3714cefc7f6701c39707fe 8334481: [JVMCI] add LINK_TO_NATIVE to MethodHandleAccessProvider.IntrinsicMethod Reviewed-by: dnsimon ! src/hotspot/share/jvmci/vmStructs_jvmci.cpp ! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotMethodHandleAccessProvider.java ! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotVMConfig.java ! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/meta/MethodHandleAccessProvider.java Changeset: cad68e06 Branch: fibers Author: Chen Liang Date: 2024-07-10 21:06:39 +0000 URL: https://git.openjdk.org/loom/commit/cad68e06ecad1e19091d1af9c0f9b8145d6842fb 8335935: Chained builders not sending transformed models to next transforms Reviewed-by: asotona ! src/java.base/share/classes/java/lang/classfile/CodeBuilder.java ! src/java.base/share/classes/jdk/internal/classfile/impl/BlockCodeBuilderImpl.java ! src/java.base/share/classes/jdk/internal/classfile/impl/BufferedCodeBuilder.java ! src/java.base/share/classes/jdk/internal/classfile/impl/ChainedClassBuilder.java ! src/java.base/share/classes/jdk/internal/classfile/impl/ChainedMethodBuilder.java ! src/java.base/share/classes/jdk/internal/classfile/impl/DirectCodeBuilder.java ! src/java.base/share/classes/jdk/internal/classfile/impl/LabelContext.java ! src/java.base/share/classes/jdk/internal/classfile/impl/TerminalCodeBuilder.java - src/java.base/share/classes/jdk/internal/classfile/impl/TransformingCodeBuilder.java ! test/jdk/jdk/classfile/TransformTests.java Changeset: d6c6847e Branch: fibers Author: KIRIYAMA Takuya Committer: David Holmes Date: 2024-07-11 02:44:12 +0000 URL: https://git.openjdk.org/loom/commit/d6c6847e32673d36a1958cefd1851ec9f3b1e2ad 8335743: jhsdb jstack cannot print some information on the waiting thread Reviewed-by: dholmes, cjplummer, kevinw ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/JavaVFrame.java ! test/hotspot/jtreg/serviceability/sa/LingeredAppWithLock.java ! test/hotspot/jtreg/serviceability/sa/TestClhsdbJstackLock.java ! test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackLock.java Changeset: b363de8c Branch: fibers Author: Kuai Wei Committer: David Holmes Date: 2024-07-11 02:44:25 +0000 URL: https://git.openjdk.org/loom/commit/b363de8c9fbf7d9e4aade41a2e883cc83ced320b 8335946: DTrace code snippets should be generated when DTrace flags are enabled Reviewed-by: coleenp, dholmes ! src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp ! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp ! src/hotspot/cpu/aarch64/templateTable_aarch64.cpp ! src/hotspot/cpu/ppc/templateTable_ppc_64.cpp ! src/hotspot/cpu/riscv/interp_masm_riscv.cpp ! src/hotspot/cpu/riscv/sharedRuntime_riscv.cpp ! src/hotspot/cpu/riscv/templateTable_riscv.cpp ! src/hotspot/cpu/s390/templateTable_s390.cpp ! src/hotspot/cpu/x86/interp_masm_x86.cpp ! src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp ! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp ! src/hotspot/cpu/x86/templateTable_x86.cpp Changeset: cf940e13 Branch: fibers Author: Doug Simon Date: 2024-07-11 07:03:44 +0000 URL: https://git.openjdk.org/loom/commit/cf940e139a76e5aabd52379b8a87065d82b2284c 8335553: [Graal] Compiler thread calls into jdk.internal.vm.VMSupport.decodeAndThrowThrowable and crashes in OOM situation Reviewed-by: yzheng, never, dholmes ! src/hotspot/share/jvmci/jvmciCompilerToVM.cpp ! src/hotspot/share/jvmci/jvmciEnv.cpp ! src/hotspot/share/utilities/exceptions.cpp ! src/java.base/share/classes/jdk/internal/vm/TranslatedException.java ! src/java.base/share/classes/jdk/internal/vm/VMSupport.java ! test/jdk/jdk/internal/vm/TestTranslatedException.java Changeset: b7d0eff5 Branch: fibers Author: Kevin Walls Date: 2024-07-11 07:29:37 +0000 URL: https://git.openjdk.org/loom/commit/b7d0eff5ad77e338b237773d2fc047eea3d2ac12 8207908: JMXStatusTest.java fails assertion intermittently Reviewed-by: cjplummer, amenkov ! test/jdk/sun/management/jmxremote/startstop/JMXStatusTest.java ! test/jdk/sun/management/jmxremote/startstop/ManagementAgentJcmd.java Changeset: 1772a929 Branch: fibers Author: Prasanta Sadhukhan Date: 2024-07-11 07:35:48 +0000 URL: https://git.openjdk.org/loom/commit/1772a929af0c31bf22153cc19c5d11b00273453b 8334457: Test javax/swing/JTabbedPane/bug4666224.java fail on macOS with because pressing the ?C? key does not switch the layout to WRAP_TAB_LAYOUT Reviewed-by: achung, abhiscxk, tr ! test/jdk/javax/swing/JTabbedPane/bug4666224.java Changeset: 2928753b Branch: fibers Author: Axel Boldt-Christmas Date: 2024-07-11 08:18:46 +0000 URL: https://git.openjdk.org/loom/commit/2928753bd95356467e4fe42ee391e45d1cb6e89c 8324966: Allow selecting jtreg test case by ID from make Reviewed-by: erikj ! make/InitSupport.gmk Changeset: 62cbf703 Branch: fibers Author: Kim Barrett Date: 2024-07-11 08:28:25 +0000 URL: https://git.openjdk.org/loom/commit/62cbf70346e78ca94ce6ea4ba5a308ea0a2bbfa8 8336085: Fix simple -Wzero-as-null-pointer-constant warnings in CDS code Reviewed-by: dholmes, jwaters ! src/hotspot/share/cds/archiveBuilder.cpp ! src/hotspot/share/cds/filemap.hpp Changeset: b32e4a68 Branch: fibers Author: Xiaolong Peng Committer: Aleksey Shipilev Date: 2024-07-11 08:47:15 +0000 URL: https://git.openjdk.org/loom/commit/b32e4a68bca588d908bd81a398eb3171a6876dc5 8335356: Shenandoah: Improve concurrent cleanup locking Reviewed-by: ysr, shade ! src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp ! src/hotspot/share/gc/shenandoah/shenandoahFreeSet.hpp Changeset: 6fcd49f9 Branch: fibers Author: Pavel Rappo Date: 2024-07-11 10:08:54 +0000 URL: https://git.openjdk.org/loom/commit/6fcd49f9431cc3507f96ef2acdca43fc6a394a14 8336239: Fix javadoc markup in java.lang.Process Reviewed-by: jpai ! src/java.base/share/classes/java/lang/Process.java Changeset: 5c612c23 Branch: fibers Author: Robbin Ehn Date: 2024-07-11 10:24:00 +0000 URL: https://git.openjdk.org/loom/commit/5c612c230b0a852aed5fd36e58b82ebf2e1838af 8332689: RISC-V: Use load instead of trampolines Reviewed-by: fyang, mli, luhenry ! src/hotspot/cpu/riscv/c1_CodeStubs_riscv.cpp ! src/hotspot/cpu/riscv/c1_LIRAssembler_riscv.cpp ! src/hotspot/cpu/riscv/c1_LIRAssembler_riscv.hpp ! src/hotspot/cpu/riscv/c2_MacroAssembler_riscv.cpp ! src/hotspot/cpu/riscv/codeBuffer_riscv.cpp ! src/hotspot/cpu/riscv/codeBuffer_riscv.hpp ! src/hotspot/cpu/riscv/compiledIC_riscv.cpp ! src/hotspot/cpu/riscv/globals_riscv.hpp ! src/hotspot/cpu/riscv/jvmciCodeInstaller_riscv.cpp ! src/hotspot/cpu/riscv/macroAssembler_riscv.cpp ! src/hotspot/cpu/riscv/macroAssembler_riscv.hpp ! src/hotspot/cpu/riscv/nativeInst_riscv.cpp ! src/hotspot/cpu/riscv/nativeInst_riscv.hpp ! src/hotspot/cpu/riscv/relocInfo_riscv.cpp ! src/hotspot/cpu/riscv/riscv.ad ! src/hotspot/cpu/riscv/sharedRuntime_riscv.cpp Changeset: dea92742 Branch: fibers Author: Sonia Zaldana Calles Date: 2024-07-11 14:12:13 +0000 URL: https://git.openjdk.org/loom/commit/dea92742c2b5889717f2183dc29b5772daff5340 8332125: [nmt] Totals in diff report should print out total malloc and mmap diffs Reviewed-by: stuefe, jsjolen ! src/hotspot/share/nmt/memReporter.cpp + test/hotspot/jtreg/runtime/NMT/TotalMallocMmapDiffTest.java Changeset: d06d79c8 Branch: fibers Author: Chen Liang Date: 2024-07-11 16:07:03 +0000 URL: https://git.openjdk.org/loom/commit/d06d79c80980644df511cded0eb8bc0309d878d3 8325369: @sealedGraph: Bad link to image for tag on nested classes Reviewed-by: jjg ! make/jdk/src/classes/build/tools/taglet/SealedGraph.java Changeset: 58c98420 Branch: fibers Author: Joe Wang Date: 2024-07-11 18:38:32 +0000 URL: https://git.openjdk.org/loom/commit/58c98420b65bcea08f37982fdfba747005c03553 8336021: Doccheck: valign not allowed for HTML5 in java.xml Reviewed-by: lancea ! src/java.xml/share/classes/org/w3c/dom/Attr.java Changeset: 5100303c Branch: fibers Author: Justin Lu Date: 2024-07-11 18:40:40 +0000 URL: https://git.openjdk.org/loom/commit/5100303c6c5e4224d2c41f90719139bb5f4e236e 8335668: NumberFormat integer only parsing should throw exception for edge case Reviewed-by: naoto ! src/java.base/share/classes/java/text/DecimalFormat.java ! test/jdk/java/text/Format/NumberFormat/LenientParseTest.java ! test/jdk/java/text/Format/NumberFormat/StrictParseTest.java Changeset: 9eb611e7 Branch: fibers Author: Liam Miller-Cushon Date: 2024-07-11 19:53:52 +0000 URL: https://git.openjdk.org/loom/commit/9eb611e7f07ebb6eb0cbcca32d644abf8352c991 8334055: Unhelpful 'required: reference' diagnostics after JDK-8043226 Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java + test/langtools/tools/javac/annotations/typeAnnotations/failures/CantAnnotateMissingSymbol.java + test/langtools/tools/javac/annotations/typeAnnotations/failures/CantAnnotateMissingSymbol.out ! test/langtools/tools/javac/annotations/typeAnnotations/failures/CantAnnotatePackages.java ! test/langtools/tools/javac/annotations/typeAnnotations/failures/CantAnnotatePackages.out ! test/langtools/tools/javac/annotations/typeAnnotations/failures/CantAnnotateScoping.java ! test/langtools/tools/javac/annotations/typeAnnotations/failures/CantAnnotateScoping.out Changeset: 73e3e0ed Branch: fibers Author: Dean Long Date: 2024-07-11 20:18:16 +0000 URL: https://git.openjdk.org/loom/commit/73e3e0edeb20c6f701b213423476f92fb05dd262 8321509: False positive in get_trampoline fast path causes crash Reviewed-by: kvn, adinn, thartmann ! src/hotspot/cpu/aarch64/globalDefinitions_aarch64.hpp ! src/hotspot/cpu/aarch64/nativeInst_aarch64.cpp ! src/hotspot/cpu/aarch64/nativeInst_aarch64.hpp ! src/hotspot/cpu/aarch64/relocInfo_aarch64.cpp ! src/hotspot/share/code/relocInfo.cpp ! src/hotspot/share/code/relocInfo.hpp Changeset: 88905571 Branch: fibers Author: Nizar Benalla Committer: Chen Liang Date: 2024-07-11 20:44:21 +0000 URL: https://git.openjdk.org/loom/commit/889055713ea83f899ebd7bf640dcf3c3e1a82ebe 8335623: Clean up HtmlTag.HtmlTag and make the ARIA role attribute global Reviewed-by: liach ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/HtmlTag.java Changeset: 687601eb Branch: fibers Author: Kevin Walls Date: 2024-07-11 20:45:34 +0000 URL: https://git.openjdk.org/loom/commit/687601ebcaedf133fd4d5cecc42c5aadf9c73f3c 8336257: Additional tests in jmxremote/startstop to match on PID not app name Reviewed-by: cjplummer, alanb, amenkov, dcubed ! test/jdk/sun/management/jmxremote/startstop/JMXStartStopTest.java ! test/jdk/sun/management/jmxremote/startstop/JMXStatusPerfCountersTest.java Changeset: b3ef2a60 Branch: fibers Author: Chen Liang Date: 2024-07-11 20:51:27 +0000 URL: https://git.openjdk.org/loom/commit/b3ef2a600cfec31723dc78fe552e9cf9976b0337 8336036: Synthetic documentation for a record's equals is incorrect for floating-point types Reviewed-by: prappo ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties ! test/langtools/jdk/javadoc/doclet/testRecordTypes/TestRecordTypes.java Changeset: 81a0d1ba Branch: fibers Author: Vanitha B P Committer: Alexey Semenyuk Date: 2024-07-11 21:27:30 +0000 URL: https://git.openjdk.org/loom/commit/81a0d1ba03bbdbe718302b3925cdc207d5d05232 8325525: Create jtreg test case for JDK-8325203 Reviewed-by: asemenyuk, almatvee + test/jdk/tools/jpackage/apps/ChildProcessAppLauncher.java + test/jdk/tools/jpackage/windows/WinChildProcessTest.java Changeset: c703d290 Branch: fibers Author: Matthias Baesken Date: 2024-07-12 05:56:53 +0000 URL: https://git.openjdk.org/loom/commit/c703d290425f85a06e61d72c9672ac2adac92db9 8335710: serviceability/dcmd/vm/SystemDumpMapTest.java and SystemMapTest.java fail on Linux Alpine after 8322475 Reviewed-by: stuefe, lucy ! test/hotspot/jtreg/serviceability/dcmd/vm/SystemMapTestBase.java Changeset: 9ff318d5 Branch: fibers Author: Alan Bateman Date: 2024-07-12 07:08:16 +0000 URL: https://git.openjdk.org/loom/commit/9ff318d5783745e7796742fae9190121ff2245d7 Merge ! src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp ! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp ! src/hotspot/cpu/aarch64/templateTable_aarch64.cpp ! src/hotspot/cpu/riscv/c2_MacroAssembler_riscv.cpp ! src/hotspot/cpu/riscv/sharedRuntime_riscv.cpp ! src/hotspot/cpu/x86/interp_masm_x86.cpp ! src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp ! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp ! src/hotspot/share/interpreter/oopMapCache.cpp ! src/hotspot/share/jvmci/vmStructs_jvmci.cpp ! src/hotspot/share/runtime/frame.cpp ! src/hotspot/share/runtime/objectMonitor.cpp ! src/java.base/share/classes/java/lang/Object.java ! src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp ! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp ! src/hotspot/cpu/aarch64/templateTable_aarch64.cpp ! src/hotspot/cpu/riscv/c2_MacroAssembler_riscv.cpp ! src/hotspot/cpu/riscv/sharedRuntime_riscv.cpp ! src/hotspot/cpu/x86/interp_masm_x86.cpp ! src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp ! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp ! src/hotspot/share/interpreter/oopMapCache.cpp ! src/hotspot/share/jvmci/vmStructs_jvmci.cpp ! src/hotspot/share/runtime/frame.cpp ! src/hotspot/share/runtime/objectMonitor.cpp ! src/java.base/share/classes/java/lang/Object.java Changeset: e3cd1a67 Branch: fibers Author: Alan Bateman Date: 2024-07-11 14:38:11 +0000 URL: https://git.openjdk.org/loom/commit/e3cd1a676850dfbcb4e78a1be867ac655d961e83 Reduce use of lazySubmit to when local queue is empty ! src/java.base/share/classes/java/lang/VirtualThread.java Changeset: f48be7fe Branch: fibers Author: Alan Bateman Date: 2024-07-12 07:45:41 +0000 URL: https://git.openjdk.org/loom/commit/f48be7fe6d64c29b67f83296dc2ca67706268de9 Clarify comment ! src/java.base/share/classes/java/util/concurrent/StructuredTaskScope.java Changeset: f6f2ab0c Branch: fibers Author: Alan Bateman Date: 2024-07-12 07:45:53 +0000 URL: https://git.openjdk.org/loom/commit/f6f2ab0c9d79f911f894ac8924abc3d44e103471 Merge Changeset: daceb07f Branch: fibers Author: Alan Bateman Date: 2024-07-12 10:23:01 +0000 URL: https://git.openjdk.org/loom/commit/daceb07fa752530264c5ede1a8cf758ae212da4f Exclude serviceability/sa/TestClhsdbJstackLock.java for now ! test/hotspot/jtreg/ProblemList.txt From imediava at gmail.com Fri Jul 12 09:34:58 2024 From: imediava at gmail.com (=?UTF-8?Q?I=C3=B1igo_Mediavilla?=) Date: Fri, 12 Jul 2024 11:34:58 +0200 Subject: JDK-8334085: Cannot reproduce failing test Message-ID: Hello, While looking at possible JBS tickets to work on, I saw JDK-8334085 where an assertion was reported to be failing for the GetOwnedMonitorInfoTest. Before I even asked around to wonder if this issue was already being looked at, I tried to reproduce the failure locally, but I don't manage to make the test fail. Is this still an issue in JDK-24 ? David can you still reproduce the failing test ? Best ??igo Mediavilla Saiz -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Fri Jul 12 09:36:26 2024 From: duke at openjdk.org (duke) Date: Fri, 12 Jul 2024 09:36:26 GMT Subject: git: openjdk/loom: master: 31 new changesets Message-ID: Changeset: a44b60c8 Branch: master Author: Matthias Baesken Date: 2024-07-10 07:53:52 +0000 URL: https://git.openjdk.org/loom/commit/a44b60c8c14ad998e51239f48e64779304aaac50 8335778: runtime/ClassInitErrors/TestStackOverflowDuringInit.java fails on ppc64 platforms after JDK-8334545 Reviewed-by: dholmes, asteiner ! test/hotspot/jtreg/runtime/ClassInitErrors/TestStackOverflowDuringInit.java Changeset: 537d20af Branch: master Author: Jan Lahoda Date: 2024-07-10 09:55:56 +0000 URL: https://git.openjdk.org/loom/commit/537d20afbff255489a7b1bdb0410b9d1aba715b7 8335766: Switch case with pattern matching and guard clause compiles inconsistently Reviewed-by: abimpoudis ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java ! test/langtools/tools/javac/patterns/DisambiguatePatterns.java Changeset: e0fb9494 Branch: master Author: Erik Gahlin Date: 2024-07-10 14:28:20 +0000 URL: https://git.openjdk.org/loom/commit/e0fb949460d0c7e2ab1697a6466e7d4831a20a33 8335779: JFR: Hide sleep events Reviewed-by: mgronlun ! src/hotspot/share/jfr/support/jfrIntrinsics.hpp ! src/hotspot/share/runtime/objectMonitor.cpp - src/jdk.jfr/share/classes/jdk/jfr/internal/HiddenWait.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/JVM.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/JVMSupport.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/MetadataRepository.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/OngoingStream.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/RecordingInput.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/RepositoryFiles.java + src/jdk.jfr/share/classes/jdk/jfr/internal/management/HiddenWait.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/management/StreamBarrier.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/util/Utils.java ! src/jdk.management.jfr/share/classes/jdk/management/jfr/DownLoadThread.java ! src/jdk.management.jfr/share/classes/jdk/management/jfr/FileDump.java + test/jdk/jdk/jfr/jvm/TestHiddenWait.java Changeset: e6c5aa7a Branch: master Author: Christian Stein Date: 2024-07-10 15:12:49 +0000 URL: https://git.openjdk.org/loom/commit/e6c5aa7a6cb54c647d261facdcffa6a410849627 8336012: Fix usages of jtreg-reserved properties Reviewed-by: jjg ! test/jdk/java/lang/invoke/PrivateInvokeTest.java Changeset: fb9a227e Branch: master Author: Doug Simon Date: 2024-07-10 15:34:27 +0000 URL: https://git.openjdk.org/loom/commit/fb9a227e02ebf826edb762283e15dd7e402f8433 8313909: [JVMCI] assert(cp->tag_at(index).is_unresolved_klass()) in lookupKlassInPool Reviewed-by: yzheng, never ! src/hotspot/share/jvmci/jvmciCompilerToVM.cpp Changeset: fb66716a Branch: master Author: Axel Boldt-Christmas Date: 2024-07-10 16:12:40 +0000 URL: https://git.openjdk.org/loom/commit/fb66716a1bc914db194c5b0b833cc2317704f166 8331725: ubsan: pc may not always be the entry point for a VtableStub Reviewed-by: kvn, mbaesken ! src/hotspot/share/code/vtableStubs.cpp ! src/hotspot/share/code/vtableStubs.hpp Changeset: 7ab96c74 Branch: master Author: Patricio Chilano Mateo Date: 2024-07-10 16:26:16 +0000 URL: https://git.openjdk.org/loom/commit/7ab96c74e2c39f430a5c2f65a981da7314a2385b 8335409: Can't allocate and retain memory from resource area in frame::oops_interpreted_do oop closure after 8329665 Reviewed-by: dholmes, stuefe, coleenp, shade ! src/hotspot/share/interpreter/oopMapCache.cpp ! src/hotspot/share/interpreter/oopMapCache.hpp ! src/hotspot/share/runtime/frame.cpp Changeset: 66db7156 Branch: master Author: Joe Darcy Date: 2024-07-10 16:36:39 +0000 URL: https://git.openjdk.org/loom/commit/66db71563c3ebd715a1192a9b399b618d7bdb8d0 8335637: Add explicit non-null return value expectations to Object.toString() Reviewed-by: jpai, alanb, smarks, prappo ! src/java.base/share/classes/java/lang/Object.java Changeset: 242f1133 Branch: master Author: Yudi Zheng Date: 2024-07-10 19:42:23 +0000 URL: https://git.openjdk.org/loom/commit/242f1133f8e1b373de3714cefc7f6701c39707fe 8334481: [JVMCI] add LINK_TO_NATIVE to MethodHandleAccessProvider.IntrinsicMethod Reviewed-by: dnsimon ! src/hotspot/share/jvmci/vmStructs_jvmci.cpp ! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotMethodHandleAccessProvider.java ! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotVMConfig.java ! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/meta/MethodHandleAccessProvider.java Changeset: cad68e06 Branch: master Author: Chen Liang Date: 2024-07-10 21:06:39 +0000 URL: https://git.openjdk.org/loom/commit/cad68e06ecad1e19091d1af9c0f9b8145d6842fb 8335935: Chained builders not sending transformed models to next transforms Reviewed-by: asotona ! src/java.base/share/classes/java/lang/classfile/CodeBuilder.java ! src/java.base/share/classes/jdk/internal/classfile/impl/BlockCodeBuilderImpl.java ! src/java.base/share/classes/jdk/internal/classfile/impl/BufferedCodeBuilder.java ! src/java.base/share/classes/jdk/internal/classfile/impl/ChainedClassBuilder.java ! src/java.base/share/classes/jdk/internal/classfile/impl/ChainedMethodBuilder.java ! src/java.base/share/classes/jdk/internal/classfile/impl/DirectCodeBuilder.java ! src/java.base/share/classes/jdk/internal/classfile/impl/LabelContext.java ! src/java.base/share/classes/jdk/internal/classfile/impl/TerminalCodeBuilder.java - src/java.base/share/classes/jdk/internal/classfile/impl/TransformingCodeBuilder.java ! test/jdk/jdk/classfile/TransformTests.java Changeset: d6c6847e Branch: master Author: KIRIYAMA Takuya Committer: David Holmes Date: 2024-07-11 02:44:12 +0000 URL: https://git.openjdk.org/loom/commit/d6c6847e32673d36a1958cefd1851ec9f3b1e2ad 8335743: jhsdb jstack cannot print some information on the waiting thread Reviewed-by: dholmes, cjplummer, kevinw ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/JavaVFrame.java ! test/hotspot/jtreg/serviceability/sa/LingeredAppWithLock.java ! test/hotspot/jtreg/serviceability/sa/TestClhsdbJstackLock.java ! test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackLock.java Changeset: b363de8c Branch: master Author: Kuai Wei Committer: David Holmes Date: 2024-07-11 02:44:25 +0000 URL: https://git.openjdk.org/loom/commit/b363de8c9fbf7d9e4aade41a2e883cc83ced320b 8335946: DTrace code snippets should be generated when DTrace flags are enabled Reviewed-by: coleenp, dholmes ! src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp ! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp ! src/hotspot/cpu/aarch64/templateTable_aarch64.cpp ! src/hotspot/cpu/ppc/templateTable_ppc_64.cpp ! src/hotspot/cpu/riscv/interp_masm_riscv.cpp ! src/hotspot/cpu/riscv/sharedRuntime_riscv.cpp ! src/hotspot/cpu/riscv/templateTable_riscv.cpp ! src/hotspot/cpu/s390/templateTable_s390.cpp ! src/hotspot/cpu/x86/interp_masm_x86.cpp ! src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp ! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp ! src/hotspot/cpu/x86/templateTable_x86.cpp Changeset: cf940e13 Branch: master Author: Doug Simon Date: 2024-07-11 07:03:44 +0000 URL: https://git.openjdk.org/loom/commit/cf940e139a76e5aabd52379b8a87065d82b2284c 8335553: [Graal] Compiler thread calls into jdk.internal.vm.VMSupport.decodeAndThrowThrowable and crashes in OOM situation Reviewed-by: yzheng, never, dholmes ! src/hotspot/share/jvmci/jvmciCompilerToVM.cpp ! src/hotspot/share/jvmci/jvmciEnv.cpp ! src/hotspot/share/utilities/exceptions.cpp ! src/java.base/share/classes/jdk/internal/vm/TranslatedException.java ! src/java.base/share/classes/jdk/internal/vm/VMSupport.java ! test/jdk/jdk/internal/vm/TestTranslatedException.java Changeset: b7d0eff5 Branch: master Author: Kevin Walls Date: 2024-07-11 07:29:37 +0000 URL: https://git.openjdk.org/loom/commit/b7d0eff5ad77e338b237773d2fc047eea3d2ac12 8207908: JMXStatusTest.java fails assertion intermittently Reviewed-by: cjplummer, amenkov ! test/jdk/sun/management/jmxremote/startstop/JMXStatusTest.java ! test/jdk/sun/management/jmxremote/startstop/ManagementAgentJcmd.java Changeset: 1772a929 Branch: master Author: Prasanta Sadhukhan Date: 2024-07-11 07:35:48 +0000 URL: https://git.openjdk.org/loom/commit/1772a929af0c31bf22153cc19c5d11b00273453b 8334457: Test javax/swing/JTabbedPane/bug4666224.java fail on macOS with because pressing the ?C? key does not switch the layout to WRAP_TAB_LAYOUT Reviewed-by: achung, abhiscxk, tr ! test/jdk/javax/swing/JTabbedPane/bug4666224.java Changeset: 2928753b Branch: master Author: Axel Boldt-Christmas Date: 2024-07-11 08:18:46 +0000 URL: https://git.openjdk.org/loom/commit/2928753bd95356467e4fe42ee391e45d1cb6e89c 8324966: Allow selecting jtreg test case by ID from make Reviewed-by: erikj ! make/InitSupport.gmk Changeset: 62cbf703 Branch: master Author: Kim Barrett Date: 2024-07-11 08:28:25 +0000 URL: https://git.openjdk.org/loom/commit/62cbf70346e78ca94ce6ea4ba5a308ea0a2bbfa8 8336085: Fix simple -Wzero-as-null-pointer-constant warnings in CDS code Reviewed-by: dholmes, jwaters ! src/hotspot/share/cds/archiveBuilder.cpp ! src/hotspot/share/cds/filemap.hpp Changeset: b32e4a68 Branch: master Author: Xiaolong Peng Committer: Aleksey Shipilev Date: 2024-07-11 08:47:15 +0000 URL: https://git.openjdk.org/loom/commit/b32e4a68bca588d908bd81a398eb3171a6876dc5 8335356: Shenandoah: Improve concurrent cleanup locking Reviewed-by: ysr, shade ! src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp ! src/hotspot/share/gc/shenandoah/shenandoahFreeSet.hpp Changeset: 6fcd49f9 Branch: master Author: Pavel Rappo Date: 2024-07-11 10:08:54 +0000 URL: https://git.openjdk.org/loom/commit/6fcd49f9431cc3507f96ef2acdca43fc6a394a14 8336239: Fix javadoc markup in java.lang.Process Reviewed-by: jpai ! src/java.base/share/classes/java/lang/Process.java Changeset: 5c612c23 Branch: master Author: Robbin Ehn Date: 2024-07-11 10:24:00 +0000 URL: https://git.openjdk.org/loom/commit/5c612c230b0a852aed5fd36e58b82ebf2e1838af 8332689: RISC-V: Use load instead of trampolines Reviewed-by: fyang, mli, luhenry ! src/hotspot/cpu/riscv/c1_CodeStubs_riscv.cpp ! src/hotspot/cpu/riscv/c1_LIRAssembler_riscv.cpp ! src/hotspot/cpu/riscv/c1_LIRAssembler_riscv.hpp ! src/hotspot/cpu/riscv/c2_MacroAssembler_riscv.cpp ! src/hotspot/cpu/riscv/codeBuffer_riscv.cpp ! src/hotspot/cpu/riscv/codeBuffer_riscv.hpp ! src/hotspot/cpu/riscv/compiledIC_riscv.cpp ! src/hotspot/cpu/riscv/globals_riscv.hpp ! src/hotspot/cpu/riscv/jvmciCodeInstaller_riscv.cpp ! src/hotspot/cpu/riscv/macroAssembler_riscv.cpp ! src/hotspot/cpu/riscv/macroAssembler_riscv.hpp ! src/hotspot/cpu/riscv/nativeInst_riscv.cpp ! src/hotspot/cpu/riscv/nativeInst_riscv.hpp ! src/hotspot/cpu/riscv/relocInfo_riscv.cpp ! src/hotspot/cpu/riscv/riscv.ad ! src/hotspot/cpu/riscv/sharedRuntime_riscv.cpp Changeset: dea92742 Branch: master Author: Sonia Zaldana Calles Date: 2024-07-11 14:12:13 +0000 URL: https://git.openjdk.org/loom/commit/dea92742c2b5889717f2183dc29b5772daff5340 8332125: [nmt] Totals in diff report should print out total malloc and mmap diffs Reviewed-by: stuefe, jsjolen ! src/hotspot/share/nmt/memReporter.cpp + test/hotspot/jtreg/runtime/NMT/TotalMallocMmapDiffTest.java Changeset: d06d79c8 Branch: master Author: Chen Liang Date: 2024-07-11 16:07:03 +0000 URL: https://git.openjdk.org/loom/commit/d06d79c80980644df511cded0eb8bc0309d878d3 8325369: @sealedGraph: Bad link to image for tag on nested classes Reviewed-by: jjg ! make/jdk/src/classes/build/tools/taglet/SealedGraph.java Changeset: 58c98420 Branch: master Author: Joe Wang Date: 2024-07-11 18:38:32 +0000 URL: https://git.openjdk.org/loom/commit/58c98420b65bcea08f37982fdfba747005c03553 8336021: Doccheck: valign not allowed for HTML5 in java.xml Reviewed-by: lancea ! src/java.xml/share/classes/org/w3c/dom/Attr.java Changeset: 5100303c Branch: master Author: Justin Lu Date: 2024-07-11 18:40:40 +0000 URL: https://git.openjdk.org/loom/commit/5100303c6c5e4224d2c41f90719139bb5f4e236e 8335668: NumberFormat integer only parsing should throw exception for edge case Reviewed-by: naoto ! src/java.base/share/classes/java/text/DecimalFormat.java ! test/jdk/java/text/Format/NumberFormat/LenientParseTest.java ! test/jdk/java/text/Format/NumberFormat/StrictParseTest.java Changeset: 9eb611e7 Branch: master Author: Liam Miller-Cushon Date: 2024-07-11 19:53:52 +0000 URL: https://git.openjdk.org/loom/commit/9eb611e7f07ebb6eb0cbcca32d644abf8352c991 8334055: Unhelpful 'required: reference' diagnostics after JDK-8043226 Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java + test/langtools/tools/javac/annotations/typeAnnotations/failures/CantAnnotateMissingSymbol.java + test/langtools/tools/javac/annotations/typeAnnotations/failures/CantAnnotateMissingSymbol.out ! test/langtools/tools/javac/annotations/typeAnnotations/failures/CantAnnotatePackages.java ! test/langtools/tools/javac/annotations/typeAnnotations/failures/CantAnnotatePackages.out ! test/langtools/tools/javac/annotations/typeAnnotations/failures/CantAnnotateScoping.java ! test/langtools/tools/javac/annotations/typeAnnotations/failures/CantAnnotateScoping.out Changeset: 73e3e0ed Branch: master Author: Dean Long Date: 2024-07-11 20:18:16 +0000 URL: https://git.openjdk.org/loom/commit/73e3e0edeb20c6f701b213423476f92fb05dd262 8321509: False positive in get_trampoline fast path causes crash Reviewed-by: kvn, adinn, thartmann ! src/hotspot/cpu/aarch64/globalDefinitions_aarch64.hpp ! src/hotspot/cpu/aarch64/nativeInst_aarch64.cpp ! src/hotspot/cpu/aarch64/nativeInst_aarch64.hpp ! src/hotspot/cpu/aarch64/relocInfo_aarch64.cpp ! src/hotspot/share/code/relocInfo.cpp ! src/hotspot/share/code/relocInfo.hpp Changeset: 88905571 Branch: master Author: Nizar Benalla Committer: Chen Liang Date: 2024-07-11 20:44:21 +0000 URL: https://git.openjdk.org/loom/commit/889055713ea83f899ebd7bf640dcf3c3e1a82ebe 8335623: Clean up HtmlTag.HtmlTag and make the ARIA role attribute global Reviewed-by: liach ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/HtmlTag.java Changeset: 687601eb Branch: master Author: Kevin Walls Date: 2024-07-11 20:45:34 +0000 URL: https://git.openjdk.org/loom/commit/687601ebcaedf133fd4d5cecc42c5aadf9c73f3c 8336257: Additional tests in jmxremote/startstop to match on PID not app name Reviewed-by: cjplummer, alanb, amenkov, dcubed ! test/jdk/sun/management/jmxremote/startstop/JMXStartStopTest.java ! test/jdk/sun/management/jmxremote/startstop/JMXStatusPerfCountersTest.java Changeset: b3ef2a60 Branch: master Author: Chen Liang Date: 2024-07-11 20:51:27 +0000 URL: https://git.openjdk.org/loom/commit/b3ef2a600cfec31723dc78fe552e9cf9976b0337 8336036: Synthetic documentation for a record's equals is incorrect for floating-point types Reviewed-by: prappo ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties ! test/langtools/jdk/javadoc/doclet/testRecordTypes/TestRecordTypes.java Changeset: 81a0d1ba Branch: master Author: Vanitha B P Committer: Alexey Semenyuk Date: 2024-07-11 21:27:30 +0000 URL: https://git.openjdk.org/loom/commit/81a0d1ba03bbdbe718302b3925cdc207d5d05232 8325525: Create jtreg test case for JDK-8325203 Reviewed-by: asemenyuk, almatvee + test/jdk/tools/jpackage/apps/ChildProcessAppLauncher.java + test/jdk/tools/jpackage/windows/WinChildProcessTest.java Changeset: c703d290 Branch: master Author: Matthias Baesken Date: 2024-07-12 05:56:53 +0000 URL: https://git.openjdk.org/loom/commit/c703d290425f85a06e61d72c9672ac2adac92db9 8335710: serviceability/dcmd/vm/SystemDumpMapTest.java and SystemMapTest.java fail on Linux Alpine after 8322475 Reviewed-by: stuefe, lucy ! test/hotspot/jtreg/serviceability/dcmd/vm/SystemMapTestBase.java From chris.plummer at oracle.com Fri Jul 12 17:11:33 2024 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 12 Jul 2024 10:11:33 -0700 Subject: JDK-8334085: Cannot reproduce failing test In-Reply-To: References: Message-ID: <77540540-0831-4a51-a061-7680dba35b96@oracle.com> Failures are very intermittent. We last saw a failure in our CI testing on 2024-07-03. What command are you using to run the test? Chris On 7/12/24 2:34 AM, I?igo Mediavilla wrote: > Hello, > > While looking at possible JBS tickets to work on, I saw JDK-8334085 > where an assertion was reported to be failing for the > GetOwnedMonitorInfoTest. Before I even asked around to wonder if this > issue was already being looked at, I tried to reproduce the failure > locally, but I don't manage to make the test fail. Is this still an > issue in JDK-24 ? David can you still reproduce the failing test ? > > Best > > ??igo Mediavilla Saiz > > From imediava at gmail.com Sat Jul 13 07:07:41 2024 From: imediava at gmail.com (=?UTF-8?Q?I=C3=B1igo_Mediavilla?=) Date: Sat, 13 Jul 2024 09:07:41 +0200 Subject: JDK-8334085: Cannot reproduce failing test In-Reply-To: <77540540-0831-4a51-a061-7680dba35b96@oracle.com> References: <77540540-0831-4a51-a061-7680dba35b96@oracle.com> Message-ID: I see, in that case Serguei would you want to still own this JBS or would you be OK if I try to have a look at it ? I?igo El vie, 12 jul 2024, 19:11, Chris Plummer escribi?: > Failures are very intermittent. We last saw a failure in our CI testing > on 2024-07-03. What command are you using to run the test? > > Chris > > On 7/12/24 2:34 AM, I?igo Mediavilla wrote: > > Hello, > > > > While looking at possible JBS tickets to work on, I saw JDK-8334085 > > where an assertion was reported to be failing for the > > GetOwnedMonitorInfoTest. Before I even asked around to wonder if this > > issue was already being looked at, I tried to reproduce the failure > > locally, but I don't manage to make the test fail. Is this still an > > issue in JDK-24 ? David can you still reproduce the failing test ? > > > > Best > > > > ??igo Mediavilla Saiz > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Sat Jul 13 08:27:15 2024 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 13 Jul 2024 09:27:15 +0100 Subject: JDK-8334085: Cannot reproduce failing test In-Reply-To: References: <77540540-0831-4a51-a061-7680dba35b96@oracle.com> Message-ID: On 13/07/2024 08:07, I?igo Mediavilla wrote: > I see, in that case Serguei would you want to still own this JBS or > would you be OK if I try to have a look at it ? > Debug build and JTREG_TEST_THREAD_FACTORY=Virtual. Note that this code has changed significantly in the loom repo and the assert that is triggered in main line doesn't exist in the new code. -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron.pressler at oracle.com Sat Jul 13 12:57:27 2024 From: ron.pressler at oracle.com (Ron Pressler) Date: Sat, 13 Jul 2024 12:57:27 +0000 Subject: [External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: References: <12ACDD24-C874-45B1-9142-DACAB1E78956@oracle.com> <58e21790-551d-4717-ba16-17ccecbdaf22@oracle.com> <2F579C4D-B83F-4AC8-88BB-03723A34BD18@oracle.com> Message-ID: > On 11 Jul 2024, at 19:40, Michal Domagala wrote: > > Where is the mistake in my reasoning? > All objects in the heap, including virtual thread stacks, are traversed by the GC. GC *roots*, however, are things that some GCs, G1 in particular, traverse *in a stop-the-world-pause* while they don?t walk non-root objects in a STW pause but concurrently with the application running. Furthermore, roots are kept in memory even if there are no strong references to them, while normal objects are kept only if there are strong references to them. Virtual threads, unlike platform threads, are regular heap objects rather than roots. This makes a difference to *when* they are scanned by the GC, which has an impact on GC performance, especially as there can be lots and lots of virtual threads. Additionally, *if* there is no strong reference to the virtual thread, the GC may collect it, but I pointed out that usually there is a strong reference that is kept by default for observability purposes, but you can change that option so that such a reference is not kept. ? Ron From duke at openjdk.org Tue Jul 16 08:59:12 2024 From: duke at openjdk.org (duke) Date: Tue, 16 Jul 2024 08:59:12 GMT Subject: git: openjdk/loom: fibers: 35 new changesets Message-ID: <04814532-56da-4cef-82c2-d06eae0a8bad@openjdk.org> Changeset: 1fe3ada0 Branch: fibers Author: SendaoYan Committer: Alex Menkov Date: 2024-07-12 08:14:56 +0000 URL: https://git.openjdk.org/loom/commit/1fe3ada001e188754df5de00bf6804f028ad274b 8336284: Test TestClhsdbJstackLock.java/TestJhsdbJstackLock.java fails with -Xcomp after JDK-8335743 Reviewed-by: cjplummer, amenkov ! test/hotspot/jtreg/serviceability/sa/TestClhsdbJstackLock.java ! test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackLock.java Changeset: f677b90e Branch: fibers Author: Kevin Walls Date: 2024-07-12 08:19:24 +0000 URL: https://git.openjdk.org/loom/commit/f677b90eb93026d3fdfd4ae19d48415a7d8318e8 8267887: RMIConnector_NPETest.java fails after removal of RMI Activation (JDK-8267123) Reviewed-by: cjplummer, sspitsyn ! test/jdk/ProblemList.txt - test/jdk/javax/management/remote/mandatory/connection/RMIConnector_NPETest.java Changeset: 7a620329 Branch: fibers Author: Kim Barrett Date: 2024-07-12 09:30:38 +0000 URL: https://git.openjdk.org/loom/commit/7a6203296416268f1c3f269d0db2b0c817642a34 8336081: Fix -Wzero-as-null-pointer-constant warnings in JVMTypedFlagLimit ctors Reviewed-by: dholmes, jwaters ! src/hotspot/share/runtime/flags/jvmFlagLimit.hpp Changeset: 9b6f6c5c Branch: fibers Author: Kim Barrett Date: 2024-07-12 09:33:04 +0000 URL: https://git.openjdk.org/loom/commit/9b6f6c5c9dd6d0fbb056e8d84c3a0888a3320edf 8336082: Fix -Wzero-as-null-pointer-constant warnings in SimpleCompactHashtable Reviewed-by: coleenp, dholmes ! src/hotspot/share/classfile/compactHashtable.hpp Changeset: eec0e155 Branch: fibers Author: Volker Simonis Date: 2024-07-12 12:09:58 +0000 URL: https://git.openjdk.org/loom/commit/eec0e155f303ff4bbdab172765ca7c92c2b94cbd 8335619: Add an @apiNote to j.l.i.ClassFileTransformer to warn about recursive class loading and ClassCircularityErrors Reviewed-by: alanb, stuefe, liach ! src/java.instrument/share/classes/java/lang/instrument/ClassFileTransformer.java Changeset: 559826c2 Branch: fibers Author: Jan Lahoda Date: 2024-07-12 12:17:21 +0000 URL: https://git.openjdk.org/loom/commit/559826c2922851dbe45ead23ad1d73b1846334ac 8332474: Tighten up ToolBox' JavacTask to not silently accept javac crash as a failure Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java ! test/langtools/tools/lib/toolbox/AbstractTask.java ! test/langtools/tools/lib/toolbox/JavacTask.java Changeset: 2fc7eb44 Branch: fibers Author: Abhishek Kumar Date: 2024-07-12 12:37:58 +0000 URL: https://git.openjdk.org/loom/commit/2fc7eb44a018974734832576a0a2631ae747e0cd 8155030: The Menu Mnemonics are always displayed for GTK LAF Hides mnemonics on menus, buttons, and labels for GTK L&F. Moved shared code for hiding mnemonics into sun/swing/MnemonicHandler and AltProcessor to avoid code duplication. Reviewed-by: prr, tr, achung, dnguyen, aivanov ! src/java.desktop/macosx/classes/com/apple/laf/AquaButtonUI.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaLabelUI.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaLookAndFeel.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaMenuPainter.java - src/java.desktop/macosx/classes/com/apple/laf/AquaMnemonicHandler.java ! src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKGraphicsUtils.java ! src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKLookAndFeel.java + src/java.desktop/share/classes/sun/swing/AltProcessor.java + src/java.desktop/share/classes/sun/swing/MnemonicHandler.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsGraphicsUtils.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsLabelUI.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsMenuBarUI.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsMenuItemUI.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsPopupMenuUI.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsRootPaneUI.java ! test/jdk/javax/swing/JMenuBar/TestMenuMnemonic.java + test/jdk/javax/swing/JMenuBar/TestMenuMnemonicLinuxAndMac.java ! test/jdk/javax/swing/LookAndFeel/bug4736093.java ! test/jdk/javax/swing/plaf/windows/6921687/bug6921687.java Changeset: 34d8562a Branch: fibers Author: Albert Mingkun Yang Date: 2024-07-12 12:59:13 +0000 URL: https://git.openjdk.org/loom/commit/34d8562a913b8382601e4c0c31ad34a663b9ec0a 8335902: Parallel: Refactor VM_ParallelGCFailedAllocation and VM_ParallelGCSystemGC Reviewed-by: gli, zgu ! src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp ! src/hotspot/share/gc/parallel/parallelScavengeHeap.hpp ! src/hotspot/share/gc/parallel/parallelScavengeHeap.inline.hpp ! src/hotspot/share/gc/parallel/psGCAdaptivePolicyCounters.cpp ! src/hotspot/share/gc/parallel/psGCAdaptivePolicyCounters.hpp ! src/hotspot/share/gc/parallel/psParallelCompact.cpp ! src/hotspot/share/gc/parallel/psScavenge.cpp ! src/hotspot/share/gc/parallel/psScavenge.hpp ! src/hotspot/share/gc/parallel/psVMOperations.cpp ! src/hotspot/share/gc/parallel/psVMOperations.hpp ! src/hotspot/share/gc/shared/gcVMOperations.hpp ! src/hotspot/share/runtime/vmOperation.hpp ! src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/resources/aliasmap ! test/jdk/jdk/jfr/event/runtime/TestVMOperation.java Changeset: 4f312d6b Branch: fibers Author: Zhengyu Gu Date: 2024-07-12 12:59:22 +0000 URL: https://git.openjdk.org/loom/commit/4f312d6bc1fda6e3863ac623902a7decb0704ec3 8336152: Remove unused forward declaration in classLoadInfo.hpp Reviewed-by: dholmes, shade ! src/hotspot/share/classfile/classLoadInfo.hpp Changeset: 84c74ad0 Branch: fibers Author: Shaojin Wen Committer: Chen Liang Date: 2024-07-12 14:36:34 +0000 URL: https://git.openjdk.org/loom/commit/84c74ad0a94f5c36529c63d846f15916259ee6a5 8335802: Improve startup speed HexFormat uses boolean instead of enum Reviewed-by: liach ! src/java.base/share/classes/java/util/HexFormat.java Changeset: 1f6e106b Branch: fibers Author: Kevin Walls Date: 2024-07-12 17:11:20 +0000 URL: https://git.openjdk.org/loom/commit/1f6e106b45e5109224e13d70f1a40c9e666ec2ab 8335684: Test ThreadCpuTime.java should pause like ThreadCpuTimeArray.java Reviewed-by: sspitsyn, cjplummer ! test/jdk/java/lang/management/ThreadMXBean/ThreadCpuTime.java Changeset: 4957145e Branch: fibers Author: Shaojin Wen Committer: Chen Liang Date: 2024-07-12 21:49:28 +0000 URL: https://git.openjdk.org/loom/commit/4957145e6c823bfaa638a77457da5c031af978b9 8336278: Micro-optimize Replace String.format("%n") to System.lineSeparator Reviewed-by: dnsimon, shade ! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/code/CodeUtil.java ! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotMethodData.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/tool/StructuredWriter.java Changeset: 8ba9bc6f Branch: fibers Author: Sean Gwizdak Committer: Chen Liang Date: 2024-07-12 21:49:51 +0000 URL: https://git.openjdk.org/loom/commit/8ba9bc6f1735be98dcc039244a28884b4d9620ae 8332249: Micro-optimize Method.hashCode Reviewed-by: liach ! src/java.base/share/classes/java/lang/reflect/Method.java ! test/micro/org/openjdk/bench/java/lang/reflect/MethodBenchmark.java Changeset: 5bc86f33 Branch: fibers Author: Nizar Benalla Committer: Chen Liang Date: 2024-07-12 21:50:51 +0000 URL: https://git.openjdk.org/loom/commit/5bc86f332986e3fffc1363f569029bb73a706064 8336259: Wrong link to stylesheet.css in JavaDoc API documentation Reviewed-by: jjg, liach ! src/java.base/share/classes/java/lang/doc-files/ValueBased.html ! src/java.base/share/classes/java/lang/doc-files/threadPrimitiveDeprecation.html Changeset: 4166e534 Branch: fibers Author: Pavel Rappo Date: 2024-07-12 23:11:04 +0000 URL: https://git.openjdk.org/loom/commit/4166e5345283d118d76b20de579d73bd55436ea6 8318106: Generated HTML for snippet does not always contain an id Reviewed-by: liach ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlIds.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/taglets/SnippetTaglet.java ! test/langtools/jdk/javadoc/doclet/testMarkdown/TestMarkdownTaglets.java ! test/langtools/jdk/javadoc/doclet/testSnippetTag/TestLangProperties.java ! test/langtools/jdk/javadoc/doclet/testSnippetTag/TestSnippetMarkup.java ! test/langtools/jdk/javadoc/doclet/testSnippetTag/TestSnippetTag.java ! test/langtools/jdk/javadoc/doclet/testSnippetTag/TestSnippetUnnamedPackage.java Changeset: ae9f318f Branch: fibers Author: Jaikiran Pai Date: 2024-07-13 02:19:25 +0000 URL: https://git.openjdk.org/loom/commit/ae9f318fc35eeab497e546ebab9faed6ec774ec5 8336301: test/jdk/java/nio/channels/AsyncCloseAndInterrupt.java leaves around a FIFO file upon test completion Reviewed-by: alanb ! test/jdk/java/nio/channels/AsyncCloseAndInterrupt.java Changeset: 6f325db4 Branch: fibers Author: Brian Stafford Committer: Jaikiran Pai Date: 2024-07-13 04:59:04 +0000 URL: https://git.openjdk.org/loom/commit/6f325db49365d3d06add5d194d4696a1428675fa 8310915: Typo in aarch64.ad: "envcodings" Reviewed-by: thartmann ! src/hotspot/cpu/aarch64/aarch64.ad Changeset: a9f5e76a Branch: fibers Author: Chen Liang Date: 2024-07-14 15:01:51 +0000 URL: https://git.openjdk.org/loom/commit/a9f5e76a65f743be9cd995fbea9c78ff9cef3402 8335905: CompoundElement API cleanup Reviewed-by: asotona ! src/java.base/share/classes/java/lang/classfile/ClassFileBuilder.java ! src/java.base/share/classes/java/lang/classfile/ClassModel.java ! src/java.base/share/classes/java/lang/classfile/CodeModel.java ! src/java.base/share/classes/java/lang/classfile/CompoundElement.java ! src/java.base/share/classes/java/lang/classfile/FieldModel.java ! src/java.base/share/classes/java/lang/classfile/MethodModel.java ! src/java.base/share/classes/jdk/internal/classfile/impl/AbstractUnboundModel.java ! src/java.base/share/classes/jdk/internal/classfile/impl/BufferedCodeBuilder.java ! src/java.base/share/classes/jdk/internal/classfile/impl/BufferedMethodBuilder.java ! src/java.base/share/classes/jdk/internal/classfile/impl/ClassImpl.java ! src/java.base/share/classes/jdk/internal/classfile/impl/ClassRemapperImpl.java ! src/java.base/share/classes/jdk/internal/classfile/impl/CodeImpl.java ! src/java.base/share/classes/jdk/internal/classfile/impl/FieldImpl.java ! src/java.base/share/classes/jdk/internal/classfile/impl/MethodImpl.java ! src/jdk.jartool/share/classes/sun/tools/jar/FingerPrint.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/EventInstrumentation.java ! src/jdk.jlink/share/classes/jdk/tools/jimage/JImageTask.java ! test/jdk/java/lang/instrument/asmlib/Instrumentor.java ! test/jdk/java/lang/invoke/8022701/MHIllegalAccess.java ! test/jdk/java/lang/invoke/lambda/LambdaAsm.java ! test/jdk/jdk/classfile/AdaptCodeTest.java ! test/jdk/jdk/classfile/BasicBlockTest.java ! test/jdk/jdk/classfile/ClassHierarchyInfoTest.java ! test/jdk/jdk/classfile/CorpusTest.java ! test/jdk/jdk/classfile/LvtTest.java ! test/jdk/jdk/classfile/OptionsTest.java ! test/jdk/jdk/classfile/StackMapsTest.java ! test/jdk/jdk/classfile/TestRecordComponent.java ! test/jdk/jdk/classfile/VerifierSelfTest.java ! test/jdk/jdk/classfile/helpers/RebuildingTransformation.java ! test/jdk/jdk/classfile/helpers/Transforms.java ! test/jdk/jdk/jfr/event/compiler/TestCompilerInlining.java ! test/micro/org/openjdk/bench/jdk/classfile/ReadDeep.java ! test/micro/org/openjdk/bench/jdk/classfile/Transforms.java Changeset: 3f2636d9 Branch: fibers Author: Adam Sotona Date: 2024-07-15 05:41:52 +0000 URL: https://git.openjdk.org/loom/commit/3f2636d9b71f5270c83d17dcf5d18cf907978475 8335820: java/lang/invoke/LFCaching/LFSingleThreadCachingTest.java fails due to IllegalArgumentException: hash must be nonzero Reviewed-by: liach ! src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java ! src/java.base/share/classes/jdk/internal/classfile/impl/BootstrapMethodEntryImpl.java ! src/java.base/share/classes/jdk/internal/classfile/impl/BoundAttribute.java ! test/jdk/jdk/classfile/LimitsTest.java Changeset: a96de6d8 Branch: fibers Author: Richard Reingruber Date: 2024-07-15 07:34:10 +0000 URL: https://git.openjdk.org/loom/commit/a96de6d8d273d75a6500e10ed06faab9955f893b 8336256: memcpy short value to int local is incorrect in VtableStubs::unsafe_hash Reviewed-by: stuefe, shade, kvn ! src/hotspot/share/code/vtableStubs.cpp Changeset: 2b0adfc2 Branch: fibers Author: Jan Lahoda Date: 2024-07-15 11:26:33 +0000 URL: https://git.openjdk.org/loom/commit/2b0adfc2decf47f6f49f072549c96f301f275285 8335817: javac AssertionError addLocalVar checkNull Reviewed-by: vromero, mcimadamore ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java + test/langtools/tools/javac/patterns/MatchExceptionLambdaExpression.java Changeset: a253e0ff Branch: fibers Author: Chen Liang Date: 2024-07-15 12:11:53 +0000 URL: https://git.openjdk.org/loom/commit/a253e0ff4b88541d01596b0e73ede4b96a258fca 8335642: Hide Transform implementation for Class-File API Reviewed-by: asotona ! src/java.base/share/classes/java/lang/classfile/ClassFileBuilder.java ! src/java.base/share/classes/java/lang/classfile/ClassFileTransform.java ! src/java.base/share/classes/java/lang/classfile/ClassTransform.java ! src/java.base/share/classes/java/lang/classfile/CodeBuilder.java ! src/java.base/share/classes/java/lang/classfile/CodeTransform.java ! src/java.base/share/classes/java/lang/classfile/FieldTransform.java ! src/java.base/share/classes/java/lang/classfile/MethodTransform.java ! src/java.base/share/classes/jdk/internal/classfile/impl/AbstractDirectBuilder.java ! src/java.base/share/classes/jdk/internal/classfile/impl/TransformImpl.java Changeset: 46355319 Branch: fibers Author: Maurizio Cimadamore Date: 2024-07-15 14:24:27 +0000 URL: https://git.openjdk.org/loom/commit/4635531950dbcfcd3ee2f13a57f0909af78a94c7 8335159: Move method reference to lambda desugaring before Lower 8336320: NullPointerException: Cannot invoke Type.getTag because type is null after JDK-8334037 Reviewed-by: jlahoda, vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransTypes.java + test/langtools/tools/javac/SuperInit/MrefDoubleTrans.java Changeset: 000de306 Branch: fibers Author: Patricio Chilano Mateo Date: 2024-07-15 14:54:04 +0000 URL: https://git.openjdk.org/loom/commit/000de306286bb75bbdad2f572ce6dafd4184680e 8335269: [Graal] occasional timeout in java/lang/StringBuffer/TestSynchronization.java with loom Reviewed-by: dholmes, alanb ! src/hotspot/share/runtime/continuationFreezeThaw.cpp + test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java Changeset: 9dfcd75e Branch: fibers Author: Maurizio Cimadamore Date: 2024-07-15 15:28:24 +0000 URL: https://git.openjdk.org/loom/commit/9dfcd75ec4f6c1fb60e5416fa6fc759c969a24fb 8334121: Anonymous class capturing two enclosing instances fails to compile Reviewed-by: jlahoda, vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java ! test/langtools/tools/javac/MethodParameters/LocalClassTest.out + test/langtools/tools/javac/SuperInit/MultiLevelOuterInstance.java Changeset: ab27acab Branch: fibers Author: Kim Barrett Date: 2024-07-15 15:43:02 +0000 URL: https://git.openjdk.org/loom/commit/ab27acab0b0f4a8af080275e92c2f296f5f6486b 8336297: C2: Fix -Wzero-as-null-pointer-constant warnings in derived Node ctors Reviewed-by: kvn, jwaters ! src/hotspot/share/opto/graphKit.cpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/opto/loopnode.cpp ! src/hotspot/share/opto/parse1.cpp ! src/hotspot/share/opto/parse2.cpp Changeset: 388fcf03 Branch: fibers Author: Kim Barrett Date: 2024-07-15 16:00:00 +0000 URL: https://git.openjdk.org/loom/commit/388fcf03c02c41bb690733e8565642c24ead56e0 8336349: Fix more simple -Wzero-as-null-pointer-constant warnings in C2 code Reviewed-by: kvn, shade ! src/hotspot/share/opto/buildOopMap.cpp ! src/hotspot/share/opto/callnode.cpp ! src/hotspot/share/opto/chaitin.cpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/domgraph.cpp ! src/hotspot/share/opto/idealKit.cpp ! src/hotspot/share/opto/ifg.cpp ! src/hotspot/share/opto/live.cpp ! src/hotspot/share/opto/loopnode.cpp ! src/hotspot/share/opto/matcher.cpp ! src/hotspot/share/opto/memnode.cpp ! src/hotspot/share/opto/node.cpp ! src/hotspot/share/opto/output.cpp ! src/hotspot/share/opto/phaseX.cpp ! src/hotspot/share/opto/reg_split.cpp ! src/hotspot/share/opto/regalloc.cpp ! src/hotspot/share/opto/type.cpp Changeset: c8a95a76 Branch: fibers Author: Chris Plummer Date: 2024-07-15 20:26:52 +0000 URL: https://git.openjdk.org/loom/commit/c8a95a763c169b94c5ba07d2c6fbdf99ba3b9e3b 8072701: resume001 failed due to ERROR: timeout for waiting for a BreakpintEvent Reviewed-by: amenkov, kevinw, sspitsyn ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/resume/resume001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/resume/resume001a.java ! test/hotspot/jtreg/vmTestbase/nsk/share/jdi/Debugee.java Changeset: bc7cd42d Branch: fibers Author: Alexey Ushakov Date: 2024-07-15 23:25:11 +0000 URL: https://git.openjdk.org/loom/commit/bc7cd42d11943003470ed4c93a25db3a8f9b5d21 8314498: [macos] Transferring File objects to Finder fails Co-authored-by: Andrey Starovoyt Reviewed-by: prr ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CClipboard.java ! src/java.desktop/macosx/native/libawt_lwawt/awt/CClipboard.m Changeset: 8feabc84 Branch: fibers Author: SendaoYan Committer: Jaikiran Pai Date: 2024-07-16 01:43:36 +0000 URL: https://git.openjdk.org/loom/commit/8feabc849ba2f617c8c6dbb2ec5074297beb6437 8334057: JLinkReproducibleTest.java support receive test.tool.vm.opts Reviewed-by: jpai ! test/jdk/tools/jlink/JLinkReproducibleTest.java Changeset: ff04ef9a Branch: fibers Author: Alan Bateman Date: 2024-07-16 06:57:54 +0000 URL: https://git.openjdk.org/loom/commit/ff04ef9ab7473d9b5017391e6881ec4d2b55a6b9 Merge ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/runtime/continuationFreezeThaw.cpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/runtime/continuationFreezeThaw.cpp Changeset: 429172ad Branch: fibers Author: Alan Bateman Date: 2024-07-12 11:13:48 +0000 URL: https://git.openjdk.org/loom/commit/429172ad7cf648a85b0b3438b1d2c42dfc03d743 Docs clarification ! src/java.base/share/classes/java/util/concurrent/StructuredTaskScope.java Changeset: d96f2ca3 Branch: fibers Author: Alan Bateman Date: 2024-07-16 06:58:06 +0000 URL: https://git.openjdk.org/loom/commit/d96f2ca3fd6fbe865b9f7a7868c38c25b7b63dd4 Merge Changeset: 13c44446 Branch: fibers Author: Alan Bateman Date: 2024-07-16 07:34:31 +0000 URL: https://git.openjdk.org/loom/commit/13c44446a39e60d017ec81e4b997879b97f718af Fix typo in comment ! src/java.base/share/classes/java/lang/VirtualThread.java Changeset: d8a4d7b1 Branch: fibers Author: Alan Bateman Date: 2024-07-16 07:34:41 +0000 URL: https://git.openjdk.org/loom/commit/d8a4d7b1d71af64966da10a872b92b4e3b73dd2d Merge From duke at openjdk.org Tue Jul 16 09:00:59 2024 From: duke at openjdk.org (duke) Date: Tue, 16 Jul 2024 09:00:59 GMT Subject: git: openjdk/loom: master: 30 new changesets Message-ID: <42247735-7733-4ba9-9aa2-6bd42d95ee93@openjdk.org> Changeset: 1fe3ada0 Branch: master Author: SendaoYan Committer: Alex Menkov Date: 2024-07-12 08:14:56 +0000 URL: https://git.openjdk.org/loom/commit/1fe3ada001e188754df5de00bf6804f028ad274b 8336284: Test TestClhsdbJstackLock.java/TestJhsdbJstackLock.java fails with -Xcomp after JDK-8335743 Reviewed-by: cjplummer, amenkov ! test/hotspot/jtreg/serviceability/sa/TestClhsdbJstackLock.java ! test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackLock.java Changeset: f677b90e Branch: master Author: Kevin Walls Date: 2024-07-12 08:19:24 +0000 URL: https://git.openjdk.org/loom/commit/f677b90eb93026d3fdfd4ae19d48415a7d8318e8 8267887: RMIConnector_NPETest.java fails after removal of RMI Activation (JDK-8267123) Reviewed-by: cjplummer, sspitsyn ! test/jdk/ProblemList.txt - test/jdk/javax/management/remote/mandatory/connection/RMIConnector_NPETest.java Changeset: 7a620329 Branch: master Author: Kim Barrett Date: 2024-07-12 09:30:38 +0000 URL: https://git.openjdk.org/loom/commit/7a6203296416268f1c3f269d0db2b0c817642a34 8336081: Fix -Wzero-as-null-pointer-constant warnings in JVMTypedFlagLimit ctors Reviewed-by: dholmes, jwaters ! src/hotspot/share/runtime/flags/jvmFlagLimit.hpp Changeset: 9b6f6c5c Branch: master Author: Kim Barrett Date: 2024-07-12 09:33:04 +0000 URL: https://git.openjdk.org/loom/commit/9b6f6c5c9dd6d0fbb056e8d84c3a0888a3320edf 8336082: Fix -Wzero-as-null-pointer-constant warnings in SimpleCompactHashtable Reviewed-by: coleenp, dholmes ! src/hotspot/share/classfile/compactHashtable.hpp Changeset: eec0e155 Branch: master Author: Volker Simonis Date: 2024-07-12 12:09:58 +0000 URL: https://git.openjdk.org/loom/commit/eec0e155f303ff4bbdab172765ca7c92c2b94cbd 8335619: Add an @apiNote to j.l.i.ClassFileTransformer to warn about recursive class loading and ClassCircularityErrors Reviewed-by: alanb, stuefe, liach ! src/java.instrument/share/classes/java/lang/instrument/ClassFileTransformer.java Changeset: 559826c2 Branch: master Author: Jan Lahoda Date: 2024-07-12 12:17:21 +0000 URL: https://git.openjdk.org/loom/commit/559826c2922851dbe45ead23ad1d73b1846334ac 8332474: Tighten up ToolBox' JavacTask to not silently accept javac crash as a failure Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java ! test/langtools/tools/lib/toolbox/AbstractTask.java ! test/langtools/tools/lib/toolbox/JavacTask.java Changeset: 2fc7eb44 Branch: master Author: Abhishek Kumar Date: 2024-07-12 12:37:58 +0000 URL: https://git.openjdk.org/loom/commit/2fc7eb44a018974734832576a0a2631ae747e0cd 8155030: The Menu Mnemonics are always displayed for GTK LAF Hides mnemonics on menus, buttons, and labels for GTK L&F. Moved shared code for hiding mnemonics into sun/swing/MnemonicHandler and AltProcessor to avoid code duplication. Reviewed-by: prr, tr, achung, dnguyen, aivanov ! src/java.desktop/macosx/classes/com/apple/laf/AquaButtonUI.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaLabelUI.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaLookAndFeel.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaMenuPainter.java - src/java.desktop/macosx/classes/com/apple/laf/AquaMnemonicHandler.java ! src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKGraphicsUtils.java ! src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKLookAndFeel.java + src/java.desktop/share/classes/sun/swing/AltProcessor.java + src/java.desktop/share/classes/sun/swing/MnemonicHandler.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsGraphicsUtils.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsLabelUI.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsMenuBarUI.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsMenuItemUI.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsPopupMenuUI.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsRootPaneUI.java ! test/jdk/javax/swing/JMenuBar/TestMenuMnemonic.java + test/jdk/javax/swing/JMenuBar/TestMenuMnemonicLinuxAndMac.java ! test/jdk/javax/swing/LookAndFeel/bug4736093.java ! test/jdk/javax/swing/plaf/windows/6921687/bug6921687.java Changeset: 34d8562a Branch: master Author: Albert Mingkun Yang Date: 2024-07-12 12:59:13 +0000 URL: https://git.openjdk.org/loom/commit/34d8562a913b8382601e4c0c31ad34a663b9ec0a 8335902: Parallel: Refactor VM_ParallelGCFailedAllocation and VM_ParallelGCSystemGC Reviewed-by: gli, zgu ! src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp ! src/hotspot/share/gc/parallel/parallelScavengeHeap.hpp ! src/hotspot/share/gc/parallel/parallelScavengeHeap.inline.hpp ! src/hotspot/share/gc/parallel/psGCAdaptivePolicyCounters.cpp ! src/hotspot/share/gc/parallel/psGCAdaptivePolicyCounters.hpp ! src/hotspot/share/gc/parallel/psParallelCompact.cpp ! src/hotspot/share/gc/parallel/psScavenge.cpp ! src/hotspot/share/gc/parallel/psScavenge.hpp ! src/hotspot/share/gc/parallel/psVMOperations.cpp ! src/hotspot/share/gc/parallel/psVMOperations.hpp ! src/hotspot/share/gc/shared/gcVMOperations.hpp ! src/hotspot/share/runtime/vmOperation.hpp ! src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/resources/aliasmap ! test/jdk/jdk/jfr/event/runtime/TestVMOperation.java Changeset: 4f312d6b Branch: master Author: Zhengyu Gu Date: 2024-07-12 12:59:22 +0000 URL: https://git.openjdk.org/loom/commit/4f312d6bc1fda6e3863ac623902a7decb0704ec3 8336152: Remove unused forward declaration in classLoadInfo.hpp Reviewed-by: dholmes, shade ! src/hotspot/share/classfile/classLoadInfo.hpp Changeset: 84c74ad0 Branch: master Author: Shaojin Wen Committer: Chen Liang Date: 2024-07-12 14:36:34 +0000 URL: https://git.openjdk.org/loom/commit/84c74ad0a94f5c36529c63d846f15916259ee6a5 8335802: Improve startup speed HexFormat uses boolean instead of enum Reviewed-by: liach ! src/java.base/share/classes/java/util/HexFormat.java Changeset: 1f6e106b Branch: master Author: Kevin Walls Date: 2024-07-12 17:11:20 +0000 URL: https://git.openjdk.org/loom/commit/1f6e106b45e5109224e13d70f1a40c9e666ec2ab 8335684: Test ThreadCpuTime.java should pause like ThreadCpuTimeArray.java Reviewed-by: sspitsyn, cjplummer ! test/jdk/java/lang/management/ThreadMXBean/ThreadCpuTime.java Changeset: 4957145e Branch: master Author: Shaojin Wen Committer: Chen Liang Date: 2024-07-12 21:49:28 +0000 URL: https://git.openjdk.org/loom/commit/4957145e6c823bfaa638a77457da5c031af978b9 8336278: Micro-optimize Replace String.format("%n") to System.lineSeparator Reviewed-by: dnsimon, shade ! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/code/CodeUtil.java ! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotMethodData.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/tool/StructuredWriter.java Changeset: 8ba9bc6f Branch: master Author: Sean Gwizdak Committer: Chen Liang Date: 2024-07-12 21:49:51 +0000 URL: https://git.openjdk.org/loom/commit/8ba9bc6f1735be98dcc039244a28884b4d9620ae 8332249: Micro-optimize Method.hashCode Reviewed-by: liach ! src/java.base/share/classes/java/lang/reflect/Method.java ! test/micro/org/openjdk/bench/java/lang/reflect/MethodBenchmark.java Changeset: 5bc86f33 Branch: master Author: Nizar Benalla Committer: Chen Liang Date: 2024-07-12 21:50:51 +0000 URL: https://git.openjdk.org/loom/commit/5bc86f332986e3fffc1363f569029bb73a706064 8336259: Wrong link to stylesheet.css in JavaDoc API documentation Reviewed-by: jjg, liach ! src/java.base/share/classes/java/lang/doc-files/ValueBased.html ! src/java.base/share/classes/java/lang/doc-files/threadPrimitiveDeprecation.html Changeset: 4166e534 Branch: master Author: Pavel Rappo Date: 2024-07-12 23:11:04 +0000 URL: https://git.openjdk.org/loom/commit/4166e5345283d118d76b20de579d73bd55436ea6 8318106: Generated HTML for snippet does not always contain an id Reviewed-by: liach ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlIds.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/taglets/SnippetTaglet.java ! test/langtools/jdk/javadoc/doclet/testMarkdown/TestMarkdownTaglets.java ! test/langtools/jdk/javadoc/doclet/testSnippetTag/TestLangProperties.java ! test/langtools/jdk/javadoc/doclet/testSnippetTag/TestSnippetMarkup.java ! test/langtools/jdk/javadoc/doclet/testSnippetTag/TestSnippetTag.java ! test/langtools/jdk/javadoc/doclet/testSnippetTag/TestSnippetUnnamedPackage.java Changeset: ae9f318f Branch: master Author: Jaikiran Pai Date: 2024-07-13 02:19:25 +0000 URL: https://git.openjdk.org/loom/commit/ae9f318fc35eeab497e546ebab9faed6ec774ec5 8336301: test/jdk/java/nio/channels/AsyncCloseAndInterrupt.java leaves around a FIFO file upon test completion Reviewed-by: alanb ! test/jdk/java/nio/channels/AsyncCloseAndInterrupt.java Changeset: 6f325db4 Branch: master Author: Brian Stafford Committer: Jaikiran Pai Date: 2024-07-13 04:59:04 +0000 URL: https://git.openjdk.org/loom/commit/6f325db49365d3d06add5d194d4696a1428675fa 8310915: Typo in aarch64.ad: "envcodings" Reviewed-by: thartmann ! src/hotspot/cpu/aarch64/aarch64.ad Changeset: a9f5e76a Branch: master Author: Chen Liang Date: 2024-07-14 15:01:51 +0000 URL: https://git.openjdk.org/loom/commit/a9f5e76a65f743be9cd995fbea9c78ff9cef3402 8335905: CompoundElement API cleanup Reviewed-by: asotona ! src/java.base/share/classes/java/lang/classfile/ClassFileBuilder.java ! src/java.base/share/classes/java/lang/classfile/ClassModel.java ! src/java.base/share/classes/java/lang/classfile/CodeModel.java ! src/java.base/share/classes/java/lang/classfile/CompoundElement.java ! src/java.base/share/classes/java/lang/classfile/FieldModel.java ! src/java.base/share/classes/java/lang/classfile/MethodModel.java ! src/java.base/share/classes/jdk/internal/classfile/impl/AbstractUnboundModel.java ! src/java.base/share/classes/jdk/internal/classfile/impl/BufferedCodeBuilder.java ! src/java.base/share/classes/jdk/internal/classfile/impl/BufferedMethodBuilder.java ! src/java.base/share/classes/jdk/internal/classfile/impl/ClassImpl.java ! src/java.base/share/classes/jdk/internal/classfile/impl/ClassRemapperImpl.java ! src/java.base/share/classes/jdk/internal/classfile/impl/CodeImpl.java ! src/java.base/share/classes/jdk/internal/classfile/impl/FieldImpl.java ! src/java.base/share/classes/jdk/internal/classfile/impl/MethodImpl.java ! src/jdk.jartool/share/classes/sun/tools/jar/FingerPrint.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/EventInstrumentation.java ! src/jdk.jlink/share/classes/jdk/tools/jimage/JImageTask.java ! test/jdk/java/lang/instrument/asmlib/Instrumentor.java ! test/jdk/java/lang/invoke/8022701/MHIllegalAccess.java ! test/jdk/java/lang/invoke/lambda/LambdaAsm.java ! test/jdk/jdk/classfile/AdaptCodeTest.java ! test/jdk/jdk/classfile/BasicBlockTest.java ! test/jdk/jdk/classfile/ClassHierarchyInfoTest.java ! test/jdk/jdk/classfile/CorpusTest.java ! test/jdk/jdk/classfile/LvtTest.java ! test/jdk/jdk/classfile/OptionsTest.java ! test/jdk/jdk/classfile/StackMapsTest.java ! test/jdk/jdk/classfile/TestRecordComponent.java ! test/jdk/jdk/classfile/VerifierSelfTest.java ! test/jdk/jdk/classfile/helpers/RebuildingTransformation.java ! test/jdk/jdk/classfile/helpers/Transforms.java ! test/jdk/jdk/jfr/event/compiler/TestCompilerInlining.java ! test/micro/org/openjdk/bench/jdk/classfile/ReadDeep.java ! test/micro/org/openjdk/bench/jdk/classfile/Transforms.java Changeset: 3f2636d9 Branch: master Author: Adam Sotona Date: 2024-07-15 05:41:52 +0000 URL: https://git.openjdk.org/loom/commit/3f2636d9b71f5270c83d17dcf5d18cf907978475 8335820: java/lang/invoke/LFCaching/LFSingleThreadCachingTest.java fails due to IllegalArgumentException: hash must be nonzero Reviewed-by: liach ! src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java ! src/java.base/share/classes/jdk/internal/classfile/impl/BootstrapMethodEntryImpl.java ! src/java.base/share/classes/jdk/internal/classfile/impl/BoundAttribute.java ! test/jdk/jdk/classfile/LimitsTest.java Changeset: a96de6d8 Branch: master Author: Richard Reingruber Date: 2024-07-15 07:34:10 +0000 URL: https://git.openjdk.org/loom/commit/a96de6d8d273d75a6500e10ed06faab9955f893b 8336256: memcpy short value to int local is incorrect in VtableStubs::unsafe_hash Reviewed-by: stuefe, shade, kvn ! src/hotspot/share/code/vtableStubs.cpp Changeset: 2b0adfc2 Branch: master Author: Jan Lahoda Date: 2024-07-15 11:26:33 +0000 URL: https://git.openjdk.org/loom/commit/2b0adfc2decf47f6f49f072549c96f301f275285 8335817: javac AssertionError addLocalVar checkNull Reviewed-by: vromero, mcimadamore ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java + test/langtools/tools/javac/patterns/MatchExceptionLambdaExpression.java Changeset: a253e0ff Branch: master Author: Chen Liang Date: 2024-07-15 12:11:53 +0000 URL: https://git.openjdk.org/loom/commit/a253e0ff4b88541d01596b0e73ede4b96a258fca 8335642: Hide Transform implementation for Class-File API Reviewed-by: asotona ! src/java.base/share/classes/java/lang/classfile/ClassFileBuilder.java ! src/java.base/share/classes/java/lang/classfile/ClassFileTransform.java ! src/java.base/share/classes/java/lang/classfile/ClassTransform.java ! src/java.base/share/classes/java/lang/classfile/CodeBuilder.java ! src/java.base/share/classes/java/lang/classfile/CodeTransform.java ! src/java.base/share/classes/java/lang/classfile/FieldTransform.java ! src/java.base/share/classes/java/lang/classfile/MethodTransform.java ! src/java.base/share/classes/jdk/internal/classfile/impl/AbstractDirectBuilder.java ! src/java.base/share/classes/jdk/internal/classfile/impl/TransformImpl.java Changeset: 46355319 Branch: master Author: Maurizio Cimadamore Date: 2024-07-15 14:24:27 +0000 URL: https://git.openjdk.org/loom/commit/4635531950dbcfcd3ee2f13a57f0909af78a94c7 8335159: Move method reference to lambda desugaring before Lower 8336320: NullPointerException: Cannot invoke Type.getTag because type is null after JDK-8334037 Reviewed-by: jlahoda, vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransTypes.java + test/langtools/tools/javac/SuperInit/MrefDoubleTrans.java Changeset: 000de306 Branch: master Author: Patricio Chilano Mateo Date: 2024-07-15 14:54:04 +0000 URL: https://git.openjdk.org/loom/commit/000de306286bb75bbdad2f572ce6dafd4184680e 8335269: [Graal] occasional timeout in java/lang/StringBuffer/TestSynchronization.java with loom Reviewed-by: dholmes, alanb ! src/hotspot/share/runtime/continuationFreezeThaw.cpp + test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java Changeset: 9dfcd75e Branch: master Author: Maurizio Cimadamore Date: 2024-07-15 15:28:24 +0000 URL: https://git.openjdk.org/loom/commit/9dfcd75ec4f6c1fb60e5416fa6fc759c969a24fb 8334121: Anonymous class capturing two enclosing instances fails to compile Reviewed-by: jlahoda, vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java ! test/langtools/tools/javac/MethodParameters/LocalClassTest.out + test/langtools/tools/javac/SuperInit/MultiLevelOuterInstance.java Changeset: ab27acab Branch: master Author: Kim Barrett Date: 2024-07-15 15:43:02 +0000 URL: https://git.openjdk.org/loom/commit/ab27acab0b0f4a8af080275e92c2f296f5f6486b 8336297: C2: Fix -Wzero-as-null-pointer-constant warnings in derived Node ctors Reviewed-by: kvn, jwaters ! src/hotspot/share/opto/graphKit.cpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/opto/loopnode.cpp ! src/hotspot/share/opto/parse1.cpp ! src/hotspot/share/opto/parse2.cpp Changeset: 388fcf03 Branch: master Author: Kim Barrett Date: 2024-07-15 16:00:00 +0000 URL: https://git.openjdk.org/loom/commit/388fcf03c02c41bb690733e8565642c24ead56e0 8336349: Fix more simple -Wzero-as-null-pointer-constant warnings in C2 code Reviewed-by: kvn, shade ! src/hotspot/share/opto/buildOopMap.cpp ! src/hotspot/share/opto/callnode.cpp ! src/hotspot/share/opto/chaitin.cpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/domgraph.cpp ! src/hotspot/share/opto/idealKit.cpp ! src/hotspot/share/opto/ifg.cpp ! src/hotspot/share/opto/live.cpp ! src/hotspot/share/opto/loopnode.cpp ! src/hotspot/share/opto/matcher.cpp ! src/hotspot/share/opto/memnode.cpp ! src/hotspot/share/opto/node.cpp ! src/hotspot/share/opto/output.cpp ! src/hotspot/share/opto/phaseX.cpp ! src/hotspot/share/opto/reg_split.cpp ! src/hotspot/share/opto/regalloc.cpp ! src/hotspot/share/opto/type.cpp Changeset: c8a95a76 Branch: master Author: Chris Plummer Date: 2024-07-15 20:26:52 +0000 URL: https://git.openjdk.org/loom/commit/c8a95a763c169b94c5ba07d2c6fbdf99ba3b9e3b 8072701: resume001 failed due to ERROR: timeout for waiting for a BreakpintEvent Reviewed-by: amenkov, kevinw, sspitsyn ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/resume/resume001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/resume/resume001a.java ! test/hotspot/jtreg/vmTestbase/nsk/share/jdi/Debugee.java Changeset: bc7cd42d Branch: master Author: Alexey Ushakov Date: 2024-07-15 23:25:11 +0000 URL: https://git.openjdk.org/loom/commit/bc7cd42d11943003470ed4c93a25db3a8f9b5d21 8314498: [macos] Transferring File objects to Finder fails Co-authored-by: Andrey Starovoyt Reviewed-by: prr ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CClipboard.java ! src/java.desktop/macosx/native/libawt_lwawt/awt/CClipboard.m Changeset: 8feabc84 Branch: master Author: SendaoYan Committer: Jaikiran Pai Date: 2024-07-16 01:43:36 +0000 URL: https://git.openjdk.org/loom/commit/8feabc849ba2f617c8c6dbb2ec5074297beb6437 8334057: JLinkReproducibleTest.java support receive test.tool.vm.opts Reviewed-by: jpai ! test/jdk/tools/jlink/JLinkReproducibleTest.java From imediava at gmail.com Tue Jul 16 09:01:49 2024 From: imediava at gmail.com (=?UTF-8?Q?I=C3=B1igo_Mediavilla?=) Date: Tue, 16 Jul 2024 11:01:49 +0200 Subject: JDK-8334085: Cannot reproduce failing test In-Reply-To: References: <77540540-0831-4a51-a061-7680dba35b96@oracle.com> Message-ID: Thanks Alan, >> Note that this code has changed significantly in the loom repo and the assert that is triggered in main line doesn't exist in the new code. My assumption is that: - In the main line the assertion should hold because we don't unmount a virtual thread during blocking operations (we pin it to the carrier and park the thread) - In loom the assertion has been removed because there are changes like commit (756743da) that will make it possible for a thread to be unmounted while holding a lock. Can you confirm if this is correct ? ??igo On Sat, Jul 13, 2024 at 10:27?AM Alan Bateman wrote: > On 13/07/2024 08:07, I?igo Mediavilla wrote: > > I see, in that case Serguei would you want to still own this JBS or would > you be OK if I try to have a look at it ? > > Debug build and JTREG_TEST_THREAD_FACTORY=Virtual. Note that this code > has changed significantly in the loom repo and the assert that is triggered > in main line doesn't exist in the new code. -Alan. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From imediava at gmail.com Thu Jul 18 09:23:33 2024 From: imediava at gmail.com (=?UTF-8?Q?I=C3=B1igo_Mediavilla?=) Date: Thu, 18 Jul 2024 11:23:33 +0200 Subject: JDK-8334085: Cannot reproduce failing test In-Reply-To: References: <77540540-0831-4a51-a061-7680dba35b96@oracle.com> Message-ID: Hello again, I'm struggling to understanding how the value can be something other than zero: In the JBS ticket the error happened for (bsd-amd64) so I'm checking the code in : https://github.com/openjdk/jdk/blob/38a578d547f39c3637d97f5e0242f4a69f3bbb31/src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp#L1624 In that code, I see the call to thaw being done almost immediately after the call to `fill_continuation_entry` that sets the value of `held_monitor_count` to zero. I'm guessing that it can be some kind of race condition, but I can't think of which other thread could be having an impact on the `held_monitor_count` for our JavaThread. >> What command are you using to run the test? Sorry Chris, I forgot to answer your question. I'm running the following command: make run-test TEST=test/hotspot/jtreg/serviceability/jvmti/GetOwnedMonitorInfo/GetOwnedMonitorInfoTest.java JTREG_TEST_THREAD_FACTORY=Virtual JTREG_REPEAT_COUNT=100 Cheers ??igo On Tue, Jul 16, 2024 at 11:01?AM I?igo Mediavilla wrote: > Thanks Alan, > > >> Note that this code has changed significantly in the loom repo and the > assert that is triggered in main line doesn't exist in the new code. > > My assumption is that: > > - In the main line the assertion should hold because we don't unmount a > virtual thread during blocking operations (we pin it to the carrier and > park the thread) > - In loom the assertion has been removed because there are changes like > commit (756743da) that will make it possible for a thread to be unmounted > while holding a lock. > > Can you confirm if this is correct ? > > ??igo > > > On Sat, Jul 13, 2024 at 10:27?AM Alan Bateman > wrote: > >> On 13/07/2024 08:07, I?igo Mediavilla wrote: >> >> I see, in that case Serguei would you want to still own this JBS or would >> you be OK if I try to have a look at it ? >> >> Debug build and JTREG_TEST_THREAD_FACTORY=Virtual. Note that this code >> has changed significantly in the loom repo and the assert that is triggered >> in main line doesn't exist in the new code. -Alan. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Thu Jul 18 18:24:40 2024 From: duke at openjdk.org (duke) Date: Thu, 18 Jul 2024 18:24:40 GMT Subject: git: openjdk/loom: master: 36 new changesets Message-ID: <4a465017-a81a-4123-b34d-25627a7f0174@openjdk.org> Changeset: 419cc462 Branch: master Author: Christoph Langer Date: 2024-07-16 12:48:06 +0000 URL: https://git.openjdk.org/loom/commit/419cc4624891e5775847f8acaf92fa8c42a9719c 8335533: OutOfMemoryError: Metaspace observed again on AIX in test RedefineLeakThrowable.java after JDK-8294960 Reviewed-by: mbaesken, stuefe ! test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineLeakThrowable.java Changeset: c99be357 Branch: master Author: Aleksey Shipilev Date: 2024-07-16 15:23:55 +0000 URL: https://git.openjdk.org/loom/commit/c99be357c9ff3b4f7edd8673beefeab54aa4ee90 8336474: Problemlist compiler/interpreter/Test6833129 on x86_32 Reviewed-by: thartmann, stuefe ! test/hotspot/jtreg/ProblemList.txt Changeset: 88eff4c3 Branch: master Author: Vladimir Kozlov Date: 2024-07-16 16:11:00 +0000 URL: https://git.openjdk.org/loom/commit/88eff4c3054b7d9d6486ff418bbecca8f0388117 8336421: ciMethod() constructor should use ConditionalMutexLocker(Compile_lock) Reviewed-by: jwaters, thartmann, shade ! src/hotspot/share/ci/ciMethod.cpp Changeset: 59bf3d77 Branch: master Author: Kim Barrett Date: 2024-07-16 17:53:08 +0000 URL: https://git.openjdk.org/loom/commit/59bf3d77aa96dfdc199f5a6893c76c8a379e9fba 8336080: Fix -Wzero-as-null-pointer-constant warnings in ClassLoaderStats ctor Reviewed-by: dholmes, iwalulya ! src/hotspot/share/classfile/classLoaderStats.hpp Changeset: a60608e7 Branch: master Author: Alex Menkov Date: 2024-07-16 18:10:47 +0000 URL: https://git.openjdk.org/loom/commit/a60608e7a35aeeed57bcce641d4957de1e4b4def 8334169: Long arguments of attach operation are silently truncated on Windows Reviewed-by: sspitsyn, cjplummer ! src/jdk.attach/windows/native/libattach/VirtualMachineImpl.c + test/hotspot/jtreg/serviceability/attach/LongArgTest.java Changeset: 005fb67e Branch: master Author: Cesar Soares Lucas Committer: Vladimir Kozlov Date: 2024-07-16 20:47:42 +0000 URL: https://git.openjdk.org/loom/commit/005fb67e99370ef2bd15dae621a3924e1cf00124 8331194: NPE in ArrayCreationTree.java with -XX:-UseCompressedOops Reviewed-by: kvn ! src/hotspot/share/opto/machnode.hpp ! src/hotspot/share/opto/output.cpp ! src/hotspot/share/opto/output.hpp + test/hotspot/jtreg/compiler/escapeAnalysis/TestReduceAllocationAndNestedScalarized.java Changeset: f3e7063e Branch: master Author: Chris Plummer Date: 2024-07-16 23:27:32 +0000 URL: https://git.openjdk.org/loom/commit/f3e7063e26cefb6643e4150b7fcbdc9a1fdaebed 8336420: Add JVMTI setfldw001 and setfmodw001 tests to Xcomp problem list Reviewed-by: dcubed ! test/hotspot/jtreg/ProblemList-Xcomp.txt Changeset: 69baa7d2 Branch: master Author: Harshitha Onkar Date: 2024-07-16 23:46:41 +0000 URL: https://git.openjdk.org/loom/commit/69baa7d2850fafbd89978db12eec683c286eb921 8336413: gtk headers : Fix typedef redeclaration of GMainContext and GdkPixbuf Reviewed-by: prr, dnguyen ! src/java.desktop/unix/native/libawt_xawt/awt/gtk2_interface.h ! src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.h Changeset: 5f365d44 Branch: master Author: Tobias Hartmann Committer: Jaikiran Pai Date: 2024-01-23 08:25:53 +0000 URL: https://git.openjdk.org/loom/commit/5f365d44be9c1f3413c9ccde970e2745090a516a 8323231: Improve array management Co-authored-by: Martin Balao Reviewed-by: iveresov, rhalade, mschoene, dlong, kvn ! src/hotspot/share/c1/c1_RangeCheckElimination.cpp Changeset: 46c37686 Branch: master Author: Emanuel Peter Committer: Jaikiran Pai Date: 2024-01-25 14:47:13 +0000 URL: https://git.openjdk.org/loom/commit/46c37686454321011541499a79c776f774ff2b57 8320548: Improved loop handling Reviewed-by: mschoene, rhalade, thartmann, chagedorn ! src/hotspot/share/opto/superword.cpp Changeset: 227fc5e5 Branch: master Author: Matias Saavedra Silva Committer: Jaikiran Pai Date: 2024-01-29 21:40:21 +0000 URL: https://git.openjdk.org/loom/commit/227fc5e591da0ea7540a7f25451240401ead3495 8314794: Improve UTF8 String supports Reviewed-by: dholmes, coleenp, rhalade ! src/hotspot/share/utilities/exceptions.cpp ! src/hotspot/share/utilities/utf8.cpp Changeset: aea9a08b Branch: master Author: David Holmes Committer: Jaikiran Pai Date: 2024-02-11 21:54:51 +0000 URL: https://git.openjdk.org/loom/commit/aea9a08bebb6555ef6f00daba24afec394dd245b 8319859: Better symbol storage Reviewed-by: rhalade, coleenp, matsaave, iklam ! src/hotspot/share/classfile/symbolTable.cpp ! src/hotspot/share/oops/symbol.cpp ! src/hotspot/share/oops/symbol.hpp Changeset: c5a8c8a0 Branch: master Author: David Holmes Committer: Jaikiran Pai Date: 2024-02-13 21:15:08 +0000 URL: https://git.openjdk.org/loom/commit/c5a8c8a0b6d51c33679efb02514f7a44e93ad290 8325600: Better symbol storage Reviewed-by: coleenp, rhalade, matsaave ! src/hotspot/share/classfile/symbolTable.cpp Changeset: e6363255 Branch: master Author: Jayathirth D V Committer: Jaikiran Pai Date: 2024-03-15 10:28:00 +0000 URL: https://git.openjdk.org/loom/commit/e636325510e882afa703752c6d37c183d111565c 8324559: Improve 2D image handling Reviewed-by: rhalade, mschoene, psadhukhan, prr ! src/java.desktop/share/native/libawt/java2d/loops/MaskFill.c Changeset: 553f21ae Branch: master Author: Christian Hagedorn Committer: Jaikiran Pai Date: 2024-03-26 11:43:35 +0000 URL: https://git.openjdk.org/loom/commit/553f21ae5324029eef3c934d69be40f5d4266457 8327413: Enhance compilation efficiency Co-authored-by: Roland Westrelin Reviewed-by: ahgross, rhalade, thartmann, epeter, mbalao, fferrari ! src/hotspot/share/opto/ifnode.cpp Changeset: 8cc84bf7 Branch: master Author: Phil Race Committer: Jaikiran Pai Date: 2024-03-29 17:40:00 +0000 URL: https://git.openjdk.org/loom/commit/8cc84bf71e42bb72755a9f2d8532cbdbd428c2a5 8320097: Improve Image transformations Reviewed-by: jdv, psadhukhan, aivanov, rhalade ! src/java.desktop/share/classes/sun/java2d/pipe/DrawImage.java ! src/java.desktop/share/native/libawt/java2d/loops/TransformHelper.c Changeset: 13341ca7 Branch: master Author: Jayathirth D V Committer: Jaikiran Pai Date: 2024-04-02 06:02:01 +0000 URL: https://git.openjdk.org/loom/commit/13341ca70276c891add2e4652b6e1e8020610988 8323390: Enhance mask blit functionality Reviewed-by: prr, rhalade, psadhukhan ! src/java.desktop/share/classes/sun/java2d/SunGraphics2D.java ! src/java.desktop/share/native/libawt/java2d/SurfaceData.h ! src/java.desktop/share/native/libawt/java2d/loops/MaskBlit.c Changeset: d90c20c0 Branch: master Author: Jaikiran Pai Date: 2024-07-17 06:05:51 +0000 URL: https://git.openjdk.org/loom/commit/d90c20c0c728ced94493e0e58956153f6f61f898 Merge Reviewed-by: djelinski, dholmes Changeset: 3babffd4 Branch: master Author: Jaikiran Pai Date: 2024-07-17 06:12:01 +0000 URL: https://git.openjdk.org/loom/commit/3babffd4002be62f9f75a1a773c9561804612fad 8334167: Test java/lang/instrument/NativeMethodPrefixApp.java timed out Reviewed-by: dholmes, sspitsyn, alanb ! test/jdk/java/lang/instrument/NativeMethodPrefixAgent.java ! test/jdk/java/lang/instrument/NativeMethodPrefixApp.java + test/jdk/java/lang/instrument/libNativeMethodPrefix.c Changeset: b9b0b850 Branch: master Author: Jan Lahoda Date: 2024-07-17 06:46:34 +0000 URL: https://git.openjdk.org/loom/commit/b9b0b8504ec989ad0687188de4bccfe2c04e5d64 8336375: Crash on paste to JShell Reviewed-by: jvernee ! src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/ffm/Kernel32.java Changeset: 70f3e990 Branch: master Author: Albert Mingkun Yang Date: 2024-07-17 09:25:59 +0000 URL: https://git.openjdk.org/loom/commit/70f3e99016311a6520e6a7c0da4c7ff718364976 8336463: Parallel: Add PSOldGen::expand_and_allocate Reviewed-by: iwalulya, zgu ! src/hotspot/share/gc/parallel/mutableSpace.cpp ! src/hotspot/share/gc/parallel/mutableSpace.hpp ! src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp ! src/hotspot/share/gc/parallel/psOldGen.cpp ! src/hotspot/share/gc/parallel/psOldGen.hpp Changeset: 59843f4a Branch: master Author: Nizar Benalla Committer: Jaikiran Pai Date: 2024-07-17 09:42:04 +0000 URL: https://git.openjdk.org/loom/commit/59843f4a65c18b9a9cc32d4146e569b0e8c89baf 8336040: Missing closing anchor element in Docs.gmk Reviewed-by: dholmes, jpai, shade ! make/Docs.gmk Changeset: d41d2a7a Branch: master Author: Vladimir Petko Committer: Aleksey Shipilev Date: 2024-07-17 09:43:47 +0000 URL: https://git.openjdk.org/loom/commit/d41d2a7a82cb6eff17396717e2e14139ad8179ba 8334502: gtest/GTestWrapper.java fails on armhf due to LogDecorations.iso8601_utctime_test Reviewed-by: dholmes, shade ! src/hotspot/share/runtime/os.cpp Changeset: 67979eb0 Branch: master Author: Markus Gr?nlund Date: 2024-07-17 11:17:10 +0000 URL: https://git.openjdk.org/loom/commit/67979eb0771ff834d6d3d18ba5a8bfe161cfc2ce 8334781: JFR crash: assert(((((JfrTraceIdBits::load(klass)) & ((JfrTraceIdEpoch::this_epoch_method_and_class_bits()))) != 0))) failed: invariant Reviewed-by: egahlin ! src/hotspot/share/jfr/recorder/checkpoint/types/jfrTypeSet.cpp ! src/hotspot/share/jfr/recorder/checkpoint/types/jfrTypeSetUtils.hpp ! src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceId.cpp ! src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdLoadBarrier.inline.hpp ! src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdMacros.hpp ! src/hotspot/share/jfr/support/jfrTraceIdExtension.hpp ! src/hotspot/share/prims/jvmtiRedefineClasses.cpp Changeset: 87136287 Branch: master Author: Suchismith Roy Committer: Matthias Baesken Date: 2024-07-17 11:24:08 +0000 URL: https://git.openjdk.org/loom/commit/871362870ea8dc5f4ac186876e91023116891a5b 8334217: [AIX] Misleading error messages after JDK-8320005 Reviewed-by: jkern, mbaesken ! src/hotspot/os/aix/os_aix.cpp ! src/hotspot/os/aix/porting_aix.cpp ! src/hotspot/os/aix/porting_aix.hpp Changeset: 6df7acbc Branch: master Author: Pavel Rappo Date: 2024-07-17 12:20:17 +0000 URL: https://git.openjdk.org/loom/commit/6df7acbc74922d297852044596045a8b32636423 8299080: Wrong default value of snippet lang attribute Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/taglets/SnippetTaglet.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/taglets/snippet/Parser.java ! test/langtools/jdk/javadoc/doclet/testMarkdown/TestMarkdownTaglets.java ! test/langtools/jdk/javadoc/doclet/testSnippetTag/SnippetTester.java ! test/langtools/jdk/javadoc/doclet/testSnippetTag/TestSnippetMarkup.java ! test/langtools/jdk/javadoc/doclet/testSnippetTag/TestSnippetTag.java Changeset: 7ec55df3 Branch: master Author: Albert Mingkun Yang Date: 2024-07-17 14:49:00 +0000 URL: https://git.openjdk.org/loom/commit/7ec55df34af98e9a80381dba7f7f2127f2248f73 8336638: Parallel: Remove redundant mangle in PSScavenge::invoke Reviewed-by: zgu ! src/hotspot/share/gc/parallel/psScavenge.cpp Changeset: 10186ff4 Branch: master Author: Naoto Sato Date: 2024-07-17 16:25:36 +0000 URL: https://git.openjdk.org/loom/commit/10186ff48fe67aeb83c028b47f6b7e5105513cf3 8336300: DateFormatSymbols#getInstanceRef returns non-cached instance Reviewed-by: joehw, iris, jlu, aturbanov ! src/java.base/share/classes/java/text/DateFormatSymbols.java ! src/java.base/share/classes/java/text/SimpleDateFormat.java Changeset: bcb5e695 Branch: master Author: Vladimir Kozlov Date: 2024-07-17 18:46:00 +0000 URL: https://git.openjdk.org/loom/commit/bcb5e69505f6cc8a4f323924cd2c58e630595fc0 8335921: Fix HotSpot VM build without JVMTI Reviewed-by: dholmes, shade ! make/hotspot/lib/JvmFeatures.gmk ! src/hotspot/share/jfr/instrumentation/jfrJvmtiAgent.hpp ! src/hotspot/share/jfr/periodic/jfrPeriodic.cpp ! src/hotspot/share/jfr/recorder/jfrRecorder.cpp ! src/hotspot/share/jvmci/jvmciCompilerToVM.hpp ! src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp ! src/hotspot/share/jvmci/vmStructs_jvmci.cpp ! test/jdk/jdk/jfr/event/runtime/TestAgentEvent.java Changeset: 78cc0f95 Branch: master Author: Nizar Benalla Committer: Chen Liang Date: 2024-07-17 21:39:19 +0000 URL: https://git.openjdk.org/loom/commit/78cc0f9569535c72900cf4617e22cef99f695e61 8336091: Fix HTML warnings in the generated HTML files Reviewed-by: dholmes ! make/jdk/src/classes/build/tools/fixuppandoc/Main.java Changeset: 21a6cf84 Branch: master Author: Chris Plummer Date: 2024-07-18 00:21:03 +0000 URL: https://git.openjdk.org/loom/commit/21a6cf848da00c795d833f926f831c7aea05dfa3 8336587: failure_handler lldb command times out on macosx-aarch64 core file Reviewed-by: dlong, dholmes, jpai ! test/failure_handler/src/share/conf/mac.properties Changeset: 72297d22 Branch: master Author: Arseny Bochkarev Committer: Vladimir Kempik Date: 2024-07-18 08:55:07 +0000 URL: https://git.openjdk.org/loom/commit/72297d22d19e34ff26bd34644dc087a1dec9527e 8317720: RISC-V: Implement Adler32 intrinsic Reviewed-by: fyang ! src/hotspot/cpu/riscv/assembler_riscv.hpp ! src/hotspot/cpu/riscv/stubGenerator_riscv.cpp ! src/hotspot/cpu/riscv/vm_version_riscv.cpp Changeset: 1b83bd92 Branch: master Author: Albert Mingkun Yang Date: 2024-07-18 10:08:13 +0000 URL: https://git.openjdk.org/loom/commit/1b83bd9225fe9ada4c3770d5cd41242f82fe144f 8336661: Parallel: Remove stacks_empty assert in PSScavenge::invoke Reviewed-by: sangheki ! src/hotspot/share/gc/parallel/psScavenge.cpp Changeset: 7bf53132 Branch: master Author: Jorn Vernee Date: 2024-07-18 11:00:39 +0000 URL: https://git.openjdk.org/loom/commit/7bf531324404419e7de3e83e245d351e1a4e4499 8335480: Only deoptimize threads if needed when closing shared arena Reviewed-by: mcimadamore, kvn, uschindler, vlivanov, eosterlund ! src/hotspot/share/c1/c1_Compilation.cpp ! src/hotspot/share/c1/c1_Compilation.hpp ! src/hotspot/share/c1/c1_GraphBuilder.cpp ! src/hotspot/share/ci/ciEnv.cpp ! src/hotspot/share/ci/ciEnv.hpp ! src/hotspot/share/ci/ciMethod.cpp ! src/hotspot/share/ci/ciMethod.hpp ! src/hotspot/share/code/nmethod.cpp ! src/hotspot/share/code/nmethod.hpp ! src/hotspot/share/jvmci/jvmciRuntime.cpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/compile.hpp ! src/hotspot/share/opto/output.cpp ! src/hotspot/share/opto/parse1.cpp ! src/hotspot/share/prims/scopedMemoryAccess.cpp ! src/hotspot/share/runtime/vframe.cpp ! src/hotspot/share/runtime/vframe.hpp + test/jdk/java/foreign/TestConcurrentClose.java ! test/jdk/java/foreign/TestHandshake.java + test/micro/org/openjdk/bench/java/lang/foreign/ConcurrentClose.java Changeset: 35df48e1 Branch: master Author: Jatin Bhateja Date: 2024-07-18 11:22:58 +0000 URL: https://git.openjdk.org/loom/commit/35df48e1b321d16f44ba924065143af67143cf95 8335860: compiler/vectorization/TestFloat16VectorConvChain.java fails with non-standard AVX/SSE settings Reviewed-by: sviswanathan, kvn ! test/hotspot/jtreg/ProblemList.txt ! test/hotspot/jtreg/compiler/vectorization/TestFloat16VectorConvChain.java Changeset: 4a73ed44 Branch: master Author: Robert Toyonaga Committer: Thomas Stuefe Date: 2024-07-18 13:35:32 +0000 URL: https://git.openjdk.org/loom/commit/4a73ed44f1af4ea3e53b1e1a6acfca1ba6b636c3 8330144: Revise os::free_memory() Reviewed-by: stuefe, mbaesken ! src/hotspot/os/aix/os_aix.cpp ! src/hotspot/os/bsd/os_bsd.cpp ! src/hotspot/os/linux/os_linux.cpp ! src/hotspot/os/windows/os_windows.cpp ! src/hotspot/share/gc/parallel/mutableNUMASpace.cpp ! src/hotspot/share/gc/parallel/mutableSpace.cpp ! src/hotspot/share/runtime/os.cpp ! src/hotspot/share/runtime/os.hpp ! test/hotspot/gtest/runtime/test_committed_virtualmemory.cpp ! test/hotspot/gtest/runtime/test_os.cpp From duke at openjdk.org Thu Jul 18 18:28:56 2024 From: duke at openjdk.org (duke) Date: Thu, 18 Jul 2024 18:28:56 GMT Subject: git: openjdk/loom: fibers: 39 new changesets Message-ID: <99834507-91a5-4ecd-b090-9b39e50b0e01@openjdk.org> Changeset: 419cc462 Branch: fibers Author: Christoph Langer Date: 2024-07-16 12:48:06 +0000 URL: https://git.openjdk.org/loom/commit/419cc4624891e5775847f8acaf92fa8c42a9719c 8335533: OutOfMemoryError: Metaspace observed again on AIX in test RedefineLeakThrowable.java after JDK-8294960 Reviewed-by: mbaesken, stuefe ! test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineLeakThrowable.java Changeset: c99be357 Branch: fibers Author: Aleksey Shipilev Date: 2024-07-16 15:23:55 +0000 URL: https://git.openjdk.org/loom/commit/c99be357c9ff3b4f7edd8673beefeab54aa4ee90 8336474: Problemlist compiler/interpreter/Test6833129 on x86_32 Reviewed-by: thartmann, stuefe ! test/hotspot/jtreg/ProblemList.txt Changeset: 88eff4c3 Branch: fibers Author: Vladimir Kozlov Date: 2024-07-16 16:11:00 +0000 URL: https://git.openjdk.org/loom/commit/88eff4c3054b7d9d6486ff418bbecca8f0388117 8336421: ciMethod() constructor should use ConditionalMutexLocker(Compile_lock) Reviewed-by: jwaters, thartmann, shade ! src/hotspot/share/ci/ciMethod.cpp Changeset: 59bf3d77 Branch: fibers Author: Kim Barrett Date: 2024-07-16 17:53:08 +0000 URL: https://git.openjdk.org/loom/commit/59bf3d77aa96dfdc199f5a6893c76c8a379e9fba 8336080: Fix -Wzero-as-null-pointer-constant warnings in ClassLoaderStats ctor Reviewed-by: dholmes, iwalulya ! src/hotspot/share/classfile/classLoaderStats.hpp Changeset: a60608e7 Branch: fibers Author: Alex Menkov Date: 2024-07-16 18:10:47 +0000 URL: https://git.openjdk.org/loom/commit/a60608e7a35aeeed57bcce641d4957de1e4b4def 8334169: Long arguments of attach operation are silently truncated on Windows Reviewed-by: sspitsyn, cjplummer ! src/jdk.attach/windows/native/libattach/VirtualMachineImpl.c + test/hotspot/jtreg/serviceability/attach/LongArgTest.java Changeset: 005fb67e Branch: fibers Author: Cesar Soares Lucas Committer: Vladimir Kozlov Date: 2024-07-16 20:47:42 +0000 URL: https://git.openjdk.org/loom/commit/005fb67e99370ef2bd15dae621a3924e1cf00124 8331194: NPE in ArrayCreationTree.java with -XX:-UseCompressedOops Reviewed-by: kvn ! src/hotspot/share/opto/machnode.hpp ! src/hotspot/share/opto/output.cpp ! src/hotspot/share/opto/output.hpp + test/hotspot/jtreg/compiler/escapeAnalysis/TestReduceAllocationAndNestedScalarized.java Changeset: f3e7063e Branch: fibers Author: Chris Plummer Date: 2024-07-16 23:27:32 +0000 URL: https://git.openjdk.org/loom/commit/f3e7063e26cefb6643e4150b7fcbdc9a1fdaebed 8336420: Add JVMTI setfldw001 and setfmodw001 tests to Xcomp problem list Reviewed-by: dcubed ! test/hotspot/jtreg/ProblemList-Xcomp.txt Changeset: 69baa7d2 Branch: fibers Author: Harshitha Onkar Date: 2024-07-16 23:46:41 +0000 URL: https://git.openjdk.org/loom/commit/69baa7d2850fafbd89978db12eec683c286eb921 8336413: gtk headers : Fix typedef redeclaration of GMainContext and GdkPixbuf Reviewed-by: prr, dnguyen ! src/java.desktop/unix/native/libawt_xawt/awt/gtk2_interface.h ! src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.h Changeset: 5f365d44 Branch: fibers Author: Tobias Hartmann Committer: Jaikiran Pai Date: 2024-01-23 08:25:53 +0000 URL: https://git.openjdk.org/loom/commit/5f365d44be9c1f3413c9ccde970e2745090a516a 8323231: Improve array management Co-authored-by: Martin Balao Reviewed-by: iveresov, rhalade, mschoene, dlong, kvn ! src/hotspot/share/c1/c1_RangeCheckElimination.cpp Changeset: 46c37686 Branch: fibers Author: Emanuel Peter Committer: Jaikiran Pai Date: 2024-01-25 14:47:13 +0000 URL: https://git.openjdk.org/loom/commit/46c37686454321011541499a79c776f774ff2b57 8320548: Improved loop handling Reviewed-by: mschoene, rhalade, thartmann, chagedorn ! src/hotspot/share/opto/superword.cpp Changeset: 227fc5e5 Branch: fibers Author: Matias Saavedra Silva Committer: Jaikiran Pai Date: 2024-01-29 21:40:21 +0000 URL: https://git.openjdk.org/loom/commit/227fc5e591da0ea7540a7f25451240401ead3495 8314794: Improve UTF8 String supports Reviewed-by: dholmes, coleenp, rhalade ! src/hotspot/share/utilities/exceptions.cpp ! src/hotspot/share/utilities/utf8.cpp Changeset: aea9a08b Branch: fibers Author: David Holmes Committer: Jaikiran Pai Date: 2024-02-11 21:54:51 +0000 URL: https://git.openjdk.org/loom/commit/aea9a08bebb6555ef6f00daba24afec394dd245b 8319859: Better symbol storage Reviewed-by: rhalade, coleenp, matsaave, iklam ! src/hotspot/share/classfile/symbolTable.cpp ! src/hotspot/share/oops/symbol.cpp ! src/hotspot/share/oops/symbol.hpp Changeset: c5a8c8a0 Branch: fibers Author: David Holmes Committer: Jaikiran Pai Date: 2024-02-13 21:15:08 +0000 URL: https://git.openjdk.org/loom/commit/c5a8c8a0b6d51c33679efb02514f7a44e93ad290 8325600: Better symbol storage Reviewed-by: coleenp, rhalade, matsaave ! src/hotspot/share/classfile/symbolTable.cpp Changeset: e6363255 Branch: fibers Author: Jayathirth D V Committer: Jaikiran Pai Date: 2024-03-15 10:28:00 +0000 URL: https://git.openjdk.org/loom/commit/e636325510e882afa703752c6d37c183d111565c 8324559: Improve 2D image handling Reviewed-by: rhalade, mschoene, psadhukhan, prr ! src/java.desktop/share/native/libawt/java2d/loops/MaskFill.c Changeset: 553f21ae Branch: fibers Author: Christian Hagedorn Committer: Jaikiran Pai Date: 2024-03-26 11:43:35 +0000 URL: https://git.openjdk.org/loom/commit/553f21ae5324029eef3c934d69be40f5d4266457 8327413: Enhance compilation efficiency Co-authored-by: Roland Westrelin Reviewed-by: ahgross, rhalade, thartmann, epeter, mbalao, fferrari ! src/hotspot/share/opto/ifnode.cpp Changeset: 8cc84bf7 Branch: fibers Author: Phil Race Committer: Jaikiran Pai Date: 2024-03-29 17:40:00 +0000 URL: https://git.openjdk.org/loom/commit/8cc84bf71e42bb72755a9f2d8532cbdbd428c2a5 8320097: Improve Image transformations Reviewed-by: jdv, psadhukhan, aivanov, rhalade ! src/java.desktop/share/classes/sun/java2d/pipe/DrawImage.java ! src/java.desktop/share/native/libawt/java2d/loops/TransformHelper.c Changeset: 13341ca7 Branch: fibers Author: Jayathirth D V Committer: Jaikiran Pai Date: 2024-04-02 06:02:01 +0000 URL: https://git.openjdk.org/loom/commit/13341ca70276c891add2e4652b6e1e8020610988 8323390: Enhance mask blit functionality Reviewed-by: prr, rhalade, psadhukhan ! src/java.desktop/share/classes/sun/java2d/SunGraphics2D.java ! src/java.desktop/share/native/libawt/java2d/SurfaceData.h ! src/java.desktop/share/native/libawt/java2d/loops/MaskBlit.c Changeset: d90c20c0 Branch: fibers Author: Jaikiran Pai Date: 2024-07-17 06:05:51 +0000 URL: https://git.openjdk.org/loom/commit/d90c20c0c728ced94493e0e58956153f6f61f898 Merge Reviewed-by: djelinski, dholmes Changeset: 3babffd4 Branch: fibers Author: Jaikiran Pai Date: 2024-07-17 06:12:01 +0000 URL: https://git.openjdk.org/loom/commit/3babffd4002be62f9f75a1a773c9561804612fad 8334167: Test java/lang/instrument/NativeMethodPrefixApp.java timed out Reviewed-by: dholmes, sspitsyn, alanb ! test/jdk/java/lang/instrument/NativeMethodPrefixAgent.java ! test/jdk/java/lang/instrument/NativeMethodPrefixApp.java + test/jdk/java/lang/instrument/libNativeMethodPrefix.c Changeset: b9b0b850 Branch: fibers Author: Jan Lahoda Date: 2024-07-17 06:46:34 +0000 URL: https://git.openjdk.org/loom/commit/b9b0b8504ec989ad0687188de4bccfe2c04e5d64 8336375: Crash on paste to JShell Reviewed-by: jvernee ! src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/ffm/Kernel32.java Changeset: 70f3e990 Branch: fibers Author: Albert Mingkun Yang Date: 2024-07-17 09:25:59 +0000 URL: https://git.openjdk.org/loom/commit/70f3e99016311a6520e6a7c0da4c7ff718364976 8336463: Parallel: Add PSOldGen::expand_and_allocate Reviewed-by: iwalulya, zgu ! src/hotspot/share/gc/parallel/mutableSpace.cpp ! src/hotspot/share/gc/parallel/mutableSpace.hpp ! src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp ! src/hotspot/share/gc/parallel/psOldGen.cpp ! src/hotspot/share/gc/parallel/psOldGen.hpp Changeset: 59843f4a Branch: fibers Author: Nizar Benalla Committer: Jaikiran Pai Date: 2024-07-17 09:42:04 +0000 URL: https://git.openjdk.org/loom/commit/59843f4a65c18b9a9cc32d4146e569b0e8c89baf 8336040: Missing closing anchor element in Docs.gmk Reviewed-by: dholmes, jpai, shade ! make/Docs.gmk Changeset: d41d2a7a Branch: fibers Author: Vladimir Petko Committer: Aleksey Shipilev Date: 2024-07-17 09:43:47 +0000 URL: https://git.openjdk.org/loom/commit/d41d2a7a82cb6eff17396717e2e14139ad8179ba 8334502: gtest/GTestWrapper.java fails on armhf due to LogDecorations.iso8601_utctime_test Reviewed-by: dholmes, shade ! src/hotspot/share/runtime/os.cpp Changeset: 67979eb0 Branch: fibers Author: Markus Gr?nlund Date: 2024-07-17 11:17:10 +0000 URL: https://git.openjdk.org/loom/commit/67979eb0771ff834d6d3d18ba5a8bfe161cfc2ce 8334781: JFR crash: assert(((((JfrTraceIdBits::load(klass)) & ((JfrTraceIdEpoch::this_epoch_method_and_class_bits()))) != 0))) failed: invariant Reviewed-by: egahlin ! src/hotspot/share/jfr/recorder/checkpoint/types/jfrTypeSet.cpp ! src/hotspot/share/jfr/recorder/checkpoint/types/jfrTypeSetUtils.hpp ! src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceId.cpp ! src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdLoadBarrier.inline.hpp ! src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdMacros.hpp ! src/hotspot/share/jfr/support/jfrTraceIdExtension.hpp ! src/hotspot/share/prims/jvmtiRedefineClasses.cpp Changeset: 87136287 Branch: fibers Author: Suchismith Roy Committer: Matthias Baesken Date: 2024-07-17 11:24:08 +0000 URL: https://git.openjdk.org/loom/commit/871362870ea8dc5f4ac186876e91023116891a5b 8334217: [AIX] Misleading error messages after JDK-8320005 Reviewed-by: jkern, mbaesken ! src/hotspot/os/aix/os_aix.cpp ! src/hotspot/os/aix/porting_aix.cpp ! src/hotspot/os/aix/porting_aix.hpp Changeset: 6df7acbc Branch: fibers Author: Pavel Rappo Date: 2024-07-17 12:20:17 +0000 URL: https://git.openjdk.org/loom/commit/6df7acbc74922d297852044596045a8b32636423 8299080: Wrong default value of snippet lang attribute Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/taglets/SnippetTaglet.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/taglets/snippet/Parser.java ! test/langtools/jdk/javadoc/doclet/testMarkdown/TestMarkdownTaglets.java ! test/langtools/jdk/javadoc/doclet/testSnippetTag/SnippetTester.java ! test/langtools/jdk/javadoc/doclet/testSnippetTag/TestSnippetMarkup.java ! test/langtools/jdk/javadoc/doclet/testSnippetTag/TestSnippetTag.java Changeset: 7ec55df3 Branch: fibers Author: Albert Mingkun Yang Date: 2024-07-17 14:49:00 +0000 URL: https://git.openjdk.org/loom/commit/7ec55df34af98e9a80381dba7f7f2127f2248f73 8336638: Parallel: Remove redundant mangle in PSScavenge::invoke Reviewed-by: zgu ! src/hotspot/share/gc/parallel/psScavenge.cpp Changeset: 10186ff4 Branch: fibers Author: Naoto Sato Date: 2024-07-17 16:25:36 +0000 URL: https://git.openjdk.org/loom/commit/10186ff48fe67aeb83c028b47f6b7e5105513cf3 8336300: DateFormatSymbols#getInstanceRef returns non-cached instance Reviewed-by: joehw, iris, jlu, aturbanov ! src/java.base/share/classes/java/text/DateFormatSymbols.java ! src/java.base/share/classes/java/text/SimpleDateFormat.java Changeset: bcb5e695 Branch: fibers Author: Vladimir Kozlov Date: 2024-07-17 18:46:00 +0000 URL: https://git.openjdk.org/loom/commit/bcb5e69505f6cc8a4f323924cd2c58e630595fc0 8335921: Fix HotSpot VM build without JVMTI Reviewed-by: dholmes, shade ! make/hotspot/lib/JvmFeatures.gmk ! src/hotspot/share/jfr/instrumentation/jfrJvmtiAgent.hpp ! src/hotspot/share/jfr/periodic/jfrPeriodic.cpp ! src/hotspot/share/jfr/recorder/jfrRecorder.cpp ! src/hotspot/share/jvmci/jvmciCompilerToVM.hpp ! src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp ! src/hotspot/share/jvmci/vmStructs_jvmci.cpp ! test/jdk/jdk/jfr/event/runtime/TestAgentEvent.java Changeset: 78cc0f95 Branch: fibers Author: Nizar Benalla Committer: Chen Liang Date: 2024-07-17 21:39:19 +0000 URL: https://git.openjdk.org/loom/commit/78cc0f9569535c72900cf4617e22cef99f695e61 8336091: Fix HTML warnings in the generated HTML files Reviewed-by: dholmes ! make/jdk/src/classes/build/tools/fixuppandoc/Main.java Changeset: 21a6cf84 Branch: fibers Author: Chris Plummer Date: 2024-07-18 00:21:03 +0000 URL: https://git.openjdk.org/loom/commit/21a6cf848da00c795d833f926f831c7aea05dfa3 8336587: failure_handler lldb command times out on macosx-aarch64 core file Reviewed-by: dlong, dholmes, jpai ! test/failure_handler/src/share/conf/mac.properties Changeset: 72297d22 Branch: fibers Author: Arseny Bochkarev Committer: Vladimir Kempik Date: 2024-07-18 08:55:07 +0000 URL: https://git.openjdk.org/loom/commit/72297d22d19e34ff26bd34644dc087a1dec9527e 8317720: RISC-V: Implement Adler32 intrinsic Reviewed-by: fyang ! src/hotspot/cpu/riscv/assembler_riscv.hpp ! src/hotspot/cpu/riscv/stubGenerator_riscv.cpp ! src/hotspot/cpu/riscv/vm_version_riscv.cpp Changeset: 1b83bd92 Branch: fibers Author: Albert Mingkun Yang Date: 2024-07-18 10:08:13 +0000 URL: https://git.openjdk.org/loom/commit/1b83bd9225fe9ada4c3770d5cd41242f82fe144f 8336661: Parallel: Remove stacks_empty assert in PSScavenge::invoke Reviewed-by: sangheki ! src/hotspot/share/gc/parallel/psScavenge.cpp Changeset: 7bf53132 Branch: fibers Author: Jorn Vernee Date: 2024-07-18 11:00:39 +0000 URL: https://git.openjdk.org/loom/commit/7bf531324404419e7de3e83e245d351e1a4e4499 8335480: Only deoptimize threads if needed when closing shared arena Reviewed-by: mcimadamore, kvn, uschindler, vlivanov, eosterlund ! src/hotspot/share/c1/c1_Compilation.cpp ! src/hotspot/share/c1/c1_Compilation.hpp ! src/hotspot/share/c1/c1_GraphBuilder.cpp ! src/hotspot/share/ci/ciEnv.cpp ! src/hotspot/share/ci/ciEnv.hpp ! src/hotspot/share/ci/ciMethod.cpp ! src/hotspot/share/ci/ciMethod.hpp ! src/hotspot/share/code/nmethod.cpp ! src/hotspot/share/code/nmethod.hpp ! src/hotspot/share/jvmci/jvmciRuntime.cpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/compile.hpp ! src/hotspot/share/opto/output.cpp ! src/hotspot/share/opto/parse1.cpp ! src/hotspot/share/prims/scopedMemoryAccess.cpp ! src/hotspot/share/runtime/vframe.cpp ! src/hotspot/share/runtime/vframe.hpp + test/jdk/java/foreign/TestConcurrentClose.java ! test/jdk/java/foreign/TestHandshake.java + test/micro/org/openjdk/bench/java/lang/foreign/ConcurrentClose.java Changeset: 35df48e1 Branch: fibers Author: Jatin Bhateja Date: 2024-07-18 11:22:58 +0000 URL: https://git.openjdk.org/loom/commit/35df48e1b321d16f44ba924065143af67143cf95 8335860: compiler/vectorization/TestFloat16VectorConvChain.java fails with non-standard AVX/SSE settings Reviewed-by: sviswanathan, kvn ! test/hotspot/jtreg/ProblemList.txt ! test/hotspot/jtreg/compiler/vectorization/TestFloat16VectorConvChain.java Changeset: 4a73ed44 Branch: fibers Author: Robert Toyonaga Committer: Thomas Stuefe Date: 2024-07-18 13:35:32 +0000 URL: https://git.openjdk.org/loom/commit/4a73ed44f1af4ea3e53b1e1a6acfca1ba6b636c3 8330144: Revise os::free_memory() Reviewed-by: stuefe, mbaesken ! src/hotspot/os/aix/os_aix.cpp ! src/hotspot/os/bsd/os_bsd.cpp ! src/hotspot/os/linux/os_linux.cpp ! src/hotspot/os/windows/os_windows.cpp ! src/hotspot/share/gc/parallel/mutableNUMASpace.cpp ! src/hotspot/share/gc/parallel/mutableSpace.cpp ! src/hotspot/share/runtime/os.cpp ! src/hotspot/share/runtime/os.hpp ! test/hotspot/gtest/runtime/test_committed_virtualmemory.cpp ! test/hotspot/gtest/runtime/test_os.cpp Changeset: 5ccb204c Branch: fibers Author: Patricio Chilano Mateo Date: 2024-07-18 10:37:05 +0000 URL: https://git.openjdk.org/loom/commit/5ccb204c39912cb2f49ce721e6251c00c6a57142 Merge branch 'master' into fibers ! src/hotspot/share/code/nmethod.cpp ! src/hotspot/share/jvmci/vmStructs_jvmci.cpp ! src/hotspot/share/prims/jvmtiRedefineClasses.cpp ! src/hotspot/share/runtime/vframe.cpp ! test/hotspot/jtreg/ProblemList-Xcomp.txt ! test/hotspot/jtreg/ProblemList.txt ! src/hotspot/share/code/nmethod.cpp ! src/hotspot/share/jvmci/vmStructs_jvmci.cpp ! src/hotspot/share/prims/jvmtiRedefineClasses.cpp ! src/hotspot/share/runtime/vframe.cpp ! test/hotspot/jtreg/ProblemList-Xcomp.txt ! test/hotspot/jtreg/ProblemList.txt Changeset: 61d9c0c2 Branch: fibers Author: Patricio Chilano Mateo Date: 2024-07-18 10:38:33 +0000 URL: https://git.openjdk.org/loom/commit/61d9c0c2e6342f1ee68d90bd80e163bf0892a02e fix polling for the preempt case ! src/hotspot/share/runtime/continuationFreezeThaw.cpp Changeset: 520d152d Branch: fibers Author: Patricio Chilano Mateo Date: 2024-07-18 10:41:41 +0000 URL: https://git.openjdk.org/loom/commit/520d152dc99ca410bd52b1b7b6515f60aef57996 add fast freeze/thaw support for Object.wait & aarch64 ! src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp ! src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp ! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp ! src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp ! src/hotspot/cpu/x86/continuationFreezeThaw_x86.inline.hpp ! src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp ! src/hotspot/share/runtime/continuationFreezeThaw.cpp ! test/jdk/java/lang/Thread/virtual/MonitorEnterExit.java ! test/jdk/java/lang/Thread/virtual/MonitorWaitNotify.java ! test/jdk/java/lang/Thread/virtual/MonitorsTest.java From serguei.spitsyn at oracle.com Fri Jul 19 20:41:45 2024 From: serguei.spitsyn at oracle.com (Serguei Spitsyn) Date: Fri, 19 Jul 2024 20:41:45 +0000 Subject: JDK-8334085: Cannot reproduce failing test In-Reply-To: References: <77540540-0831-4a51-a061-7680dba35b96@oracle.com> Message-ID: Hi I?igo, Patricio helped to reproduce this issue and also identified the problem (please, see in the bug report). The fix is a one-liner. I?ll post a PR after some mach5 testing. Thank you for involvement into this issue! Thanks, Serguei From: I?igo Mediavilla Date: Saturday, July 13, 2024 at 12:08?AM To: Chris Plummer Cc: dholmes at openjdk.org , loom-dev at openjdk.org , sspitsyn at openjdk.org Subject: Re: JDK-8334085: Cannot reproduce failing test I see, in that case Serguei would you want to still own this JBS or would you be OK if I try to have a look at it ? I?igo El vie, 12 jul 2024, 19:11, Chris Plummer > escribi?: Failures are very intermittent. We last saw a failure in our CI testing on 2024-07-03. What command are you using to run the test? Chris On 7/12/24 2:34 AM, I?igo Mediavilla wrote: > Hello, > > While looking at possible JBS tickets to work on, I saw JDK-8334085 > where an assertion was reported to be failing for the > GetOwnedMonitorInfoTest. Before I even asked around to wonder if this > issue was already being looked at, I tried to reproduce the failure > locally, but I don't manage to make the test fail. Is this still an > issue in JDK-24 ? David can you still reproduce the failing test ? > > Best > > ??igo Mediavilla Saiz > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Sat Jul 20 12:52:50 2024 From: duke at openjdk.org (duke) Date: Sat, 20 Jul 2024 12:52:50 GMT Subject: git: openjdk/loom: fibers: 32 new changesets Message-ID: <590c46eb-67c0-4593-82c3-11ffbce78131@openjdk.org> Changeset: 5f7b0072 Branch: fibers Author: Kim Barrett Date: 2024-07-18 15:24:51 +0000 URL: https://git.openjdk.org/loom/commit/5f7b0072cfe7434b43dea53b2a8d55c56c6668ea 8336346: Fix -Wzero-as-null-pointer-constant warnings in jvmciJavaClasses.cpp Reviewed-by: jwaters, thartmann ! src/hotspot/share/jvmci/jvmciJavaClasses.cpp Changeset: 245c0866 Branch: fibers Author: Vicente Romero Date: 2024-07-18 15:54:41 +0000 URL: https://git.openjdk.org/loom/commit/245c08664896d63ac050ebc23259b23908dafed5 8332600: javac uses record components source position during compilation Reviewed-by: jlahoda ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java ! test/langtools/tools/javac/records/RecordCompilationTests.java Changeset: bbc79a5e Branch: fibers Author: Joe Darcy Date: 2024-07-18 16:33:48 +0000 URL: https://git.openjdk.org/loom/commit/bbc79a5e0144cb5ee6051e078681f9c6821441cb 8333768: Minor doc updates to java.lang.{Float, Double} Reviewed-by: rgiulietti ! src/java.base/share/classes/java/lang/Double.java ! src/java.base/share/classes/java/lang/Float.java ! src/java.base/share/classes/java/lang/Math.java ! src/java.base/share/classes/java/lang/StrictMath.java Changeset: 02be7b8d Branch: fibers Author: Phil Race Date: 2024-07-18 17:35:06 +0000 URL: https://git.openjdk.org/loom/commit/02be7b8ddcdb62977770cb5052e86bcada8478ba 8334495: Use FFM instead of jdk.internal.misc.Unsafe in java.desktop font implementation Reviewed-by: jdv, dnguyen, achung ! src/java.desktop/share/classes/sun/font/FileFontStrike.java ! src/java.desktop/share/classes/sun/font/GlyphList.java ! src/java.desktop/share/classes/sun/font/StrikeCache.java ! src/java.desktop/share/native/libfontmanager/sunFont.c ! src/java.desktop/unix/classes/sun/font/XRGlyphCacheEntry.java Changeset: b44632aa Branch: fibers Author: Chen Liang Date: 2024-07-18 21:46:07 +0000 URL: https://git.openjdk.org/loom/commit/b44632aa15d21a10e559aee02a9e4dcd876654f6 8336588: Ensure Transform downstream receives upstream start items only after downstream started Reviewed-by: asotona ! src/java.base/share/classes/jdk/internal/classfile/impl/TransformImpl.java ! test/jdk/jdk/classfile/TransformTests.java Changeset: 902c2afb Branch: fibers Author: Chen Liang Date: 2024-07-18 21:46:19 +0000 URL: https://git.openjdk.org/loom/commit/902c2afb6714f778e3229c8411e9f9d5c392b388 8336585: BoundAttribute.readEntryList not type-safe Reviewed-by: asotona ! src/java.base/share/classes/jdk/internal/classfile/impl/BoundAttribute.java ! test/jdk/jdk/classfile/BoundAttributeTest.java Changeset: 39f44768 Branch: fibers Author: Chen Liang Date: 2024-07-18 22:22:59 +0000 URL: https://git.openjdk.org/loom/commit/39f44768131254ee11f723f92e2bac57b0d1ade0 8334772: Change Class::signers to an explicit field Reviewed-by: dholmes, alanb, rriggs, coleenp ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/classfile/javaClasses.hpp ! src/hotspot/share/include/jvm.h ! src/hotspot/share/prims/jvm.cpp ! src/java.base/share/classes/java/lang/Class.java ! src/java.base/share/native/libjava/Class.c Changeset: 330e520c Branch: fibers Author: Fernando Guallini Date: 2024-07-18 22:36:26 +0000 URL: https://git.openjdk.org/loom/commit/330e520c1d42d3a9f3e187873dcd8ed7fd561aaf 8028127: Regtest java/security/Security/SynchronizedAccess.java is incorrect Reviewed-by: wetmore, mdonovan, rhalade ! test/jdk/java/security/Security/SynchronizedAccess.java Changeset: 1b9270ac Branch: fibers Author: Prajwal Kumaraswamy Committer: Bradford Wetmore Date: 2024-07-18 22:42:34 +0000 URL: https://git.openjdk.org/loom/commit/1b9270ac8a76b482103dd3f6b12606a22214e554 8328723: IP Address error when client enables HTTPS endpoint check on server socket Reviewed-by: wetmore, djelinski ! src/java.base/share/classes/sun/security/ssl/X509TrustManagerImpl.java Changeset: 902bada2 Branch: fibers Author: Prasanta Sadhukhan Date: 2024-07-19 02:56:42 +0000 URL: https://git.openjdk.org/loom/commit/902bada2cdd141ade8615d1e3c2fcbff2b80e3b1 8234071: JTable.AUTO_RESIZE_LAST_COLUMN acts like AUTO_RESIZE_ALL_COLUMNS Reviewed-by: prr, abhiscxk ! src/java.desktop/share/classes/javax/swing/JTable.java Changeset: f5871df2 Branch: fibers Author: Andrey Turbanov Date: 2024-07-19 05:54:25 +0000 URL: https://git.openjdk.org/loom/commit/f5871df25c60990825babb3bbae38c5ade93f097 8336675: Remove UnixFileSystemProvider.checkPath in favor of UnixPath.toUnixPath Reviewed-by: jpai, alanb, bpb ! src/java.base/unix/classes/sun/nio/fs/UnixFileSystemProvider.java Changeset: 10fcad70 Branch: fibers Author: David Holmes Date: 2024-07-19 06:23:11 +0000 URL: https://git.openjdk.org/loom/commit/10fcad70b3894023d65716b42dc67c1a2bda9c03 8325945: Error reporting should limit the number of String characters printed Reviewed-by: thartmann, stuefe ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/classfile/javaClasses.hpp ! src/hotspot/share/prims/whitebox.cpp ! src/hotspot/share/runtime/globals.hpp + test/hotspot/jtreg/runtime/PrintingTests/StringPrinting.java ! test/lib/jdk/test/whitebox/WhiteBox.java Changeset: fa5ad700 Branch: fibers Author: SendaoYan Committer: Serguei Spitsyn Date: 2024-07-19 07:06:51 +0000 URL: https://git.openjdk.org/loom/commit/fa5ad700bb6a92aef7577969e09b4fbd93feb388 8334771: [TESTBUG] Run TestDockerMemoryMetrics.java with -Xcomp fails exitValue = 137 Reviewed-by: lmesnik, sspitsyn ! test/jdk/jdk/internal/platform/docker/MetricsMemoryTester.java ! test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetrics.java Changeset: 10982fe5 Branch: fibers Author: Roland Westrelin Date: 2024-07-19 07:28:51 +0000 URL: https://git.openjdk.org/loom/commit/10982fe557e9e8b68b674630a9979cb355bdbe62 8335843: C2 hits assert(_print_inlining_stream->size() > 0) failed: missing inlining msg Reviewed-by: thartmann, kvn, vlivanov ! src/hotspot/share/opto/callGenerator.cpp + test/hotspot/jtreg/compiler/print/TestPrintInliningLateMHCall.java ! test/hotspot/jtreg/compiler/print/TestPrintInliningLateVirtualCall.java Changeset: 0ddf54e2 Branch: fibers Author: Roland Westrelin Date: 2024-07-19 07:30:23 +0000 URL: https://git.openjdk.org/loom/commit/0ddf54e222104469669f611804ae55e2685f54fb 8335709: C2: assert(!loop->is_member(get_loop(useblock))) failed: must be outside loop Co-authored-by: Emanuel Peter Reviewed-by: epeter, thartmann ! src/hotspot/share/opto/loopnode.cpp + test/hotspot/jtreg/compiler/loopopts/InfiniteLoopBadControlNeverBranch.java Changeset: b703be9c Branch: fibers Author: Aleksey Shipilev Date: 2024-07-19 08:34:36 +0000 URL: https://git.openjdk.org/loom/commit/b703be9cf633796456991279d07cbde98ad7f1aa 8336465: C2: EA incorrectly/unnecessarily checks for clinits Reviewed-by: kvn, thartmann ! src/hotspot/share/opto/bytecodeInfo.cpp Changeset: 5d965f36 Branch: fibers Author: Aleksey Shipilev Date: 2024-07-19 08:34:47 +0000 URL: https://git.openjdk.org/loom/commit/5d965f36d3cd7a1a1f22bf119a98a9e9576a647f 8336466: C2: Parser incorrectly/unnecessarily checks for clinits Reviewed-by: kvn, thartmann ! src/hotspot/share/opto/callnode.cpp ! src/hotspot/share/opto/parse1.cpp Changeset: 84bc4767 Branch: fibers Author: Volker Simonis Date: 2024-07-19 11:26:44 +0000 URL: https://git.openjdk.org/loom/commit/84bc4767a4cd68fb52a36c6644bbec67c24b0e1d 8336258: Document the behavior of 'exclude' and 'compileonly' with respect to inlining Reviewed-by: thartmann, jkarthikeyan ! src/hotspot/share/compiler/compilerOracle.cpp Changeset: 6e9fcc2d Branch: fibers Author: Jie Fu Date: 2024-07-19 12:28:56 +0000 URL: https://git.openjdk.org/loom/commit/6e9fcc2d80170c79e45b8710e98754c67d544012 8336816: runtime/PrintingTests/StringPrinting.java fails with release VMs Reviewed-by: dholmes ! test/hotspot/jtreg/runtime/PrintingTests/StringPrinting.java Changeset: c25c4896 Branch: fibers Author: Adam Sotona Date: 2024-07-19 13:09:45 +0000 URL: https://git.openjdk.org/loom/commit/c25c4896ad9ef031e3cddec493aef66ff87c48a7 8333812: ClassFile.verify() can throw exceptions instead of returning VerifyErrors Reviewed-by: liach ! src/java.base/share/classes/jdk/internal/classfile/impl/BoundAttribute.java ! src/java.base/share/classes/jdk/internal/classfile/impl/ClassFileImpl.java ! src/java.base/share/classes/jdk/internal/classfile/impl/verifier/VerifierImpl.java ! test/jdk/jdk/classfile/VerifierSelfTest.java Changeset: 3ade2b61 Branch: fibers Author: Chen Liang Date: 2024-07-19 21:25:20 +0000 URL: https://git.openjdk.org/loom/commit/3ade2b6114bbe81eb03e3a49c08b5401f70a2367 8336777: BufferedMethodBuilder not initialized with static flag Reviewed-by: asotona ! src/java.base/share/classes/jdk/internal/classfile/impl/BufferedMethodBuilder.java ! src/java.base/share/classes/jdk/internal/classfile/impl/ChainedClassBuilder.java ! src/java.base/share/classes/jdk/internal/classfile/impl/DirectMethodBuilder.java ! src/java.base/share/classes/jdk/internal/classfile/impl/MethodInfo.java ! src/java.base/share/classes/jdk/internal/classfile/impl/TerminalMethodBuilder.java + test/jdk/jdk/classfile/MethodBuilderStaticFlagTest.java Changeset: 939fe000 Branch: fibers Author: Liam Miller-Cushon Date: 2024-07-19 21:52:45 +0000 URL: https://git.openjdk.org/loom/commit/939fe000a96bc7c92c7b8814eb6ee66856718e4e 8336786: VerifyError with lambda capture and enclosing instance references Reviewed-by: mcimadamore ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java + test/langtools/tools/javac/lambda/SuperClassThisCapture/SuperClassThisCapture.java = test/langtools/tools/javac/lambda/SuperClassThisCapture/a/A.java Changeset: e7e48a78 Branch: fibers Author: Chris Plummer Date: 2024-07-19 21:53:04 +0000 URL: https://git.openjdk.org/loom/commit/e7e48a780a34007994f830869fdb74ba1cb5b3fe 8248609: [Graal] vmTestbase/nsk/jdi/VoidValue/toString/tostring001/TestDescription.java failed with Unexpected com.sun.jdi.ObjectCollectedException Reviewed-by: amenkov, lmesnik ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VoidValue/toString/tostring001.java Changeset: e3acf4c6 Branch: fibers Author: Shaojin Wen Committer: Chen Liang Date: 2024-07-19 22:06:23 +0000 URL: https://git.openjdk.org/loom/commit/e3acf4c627c3c75f9a2ef29647daa6f4746fdc62 8336792: DateTimeFormatterBuilder append zeros based on StringBuilder.repeat Reviewed-by: liach, rriggs, naoto ! src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java Changeset: 491b9f5e Branch: fibers Author: Shaojin Wen Committer: Chen Liang Date: 2024-07-20 06:54:19 +0000 URL: https://git.openjdk.org/loom/commit/491b9f5efc01fa36fb3c174e130b46bc69c8d707 8336706: Optimize LocalDate.toString with StringBuilder.repeat Reviewed-by: liach, rriggs ! src/java.base/share/classes/java/time/LocalDate.java Changeset: c492292d Branch: fibers Author: Alan Bateman Date: 2024-07-20 09:33:00 +0000 URL: https://git.openjdk.org/loom/commit/c492292d06a40bb2ac6d0bed9d58c75533b58287 Merge ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/classfile/javaClasses.hpp ! src/hotspot/share/code/nmethod.cpp ! src/hotspot/share/include/jvm.h ! src/hotspot/share/jvmci/vmStructs_jvmci.cpp ! src/hotspot/share/prims/jvm.cpp ! src/hotspot/share/prims/jvmtiRedefineClasses.cpp ! src/hotspot/share/runtime/globals.hpp ! src/hotspot/share/runtime/vframe.cpp ! src/java.base/share/classes/sun/security/ssl/X509TrustManagerImpl.java ! test/hotspot/jtreg/ProblemList-Xcomp.txt ! test/hotspot/jtreg/ProblemList.txt ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/classfile/javaClasses.hpp ! src/hotspot/share/code/nmethod.cpp ! src/hotspot/share/include/jvm.h ! src/hotspot/share/jvmci/vmStructs_jvmci.cpp ! src/hotspot/share/prims/jvm.cpp ! src/hotspot/share/prims/jvmtiRedefineClasses.cpp ! src/hotspot/share/runtime/globals.hpp ! src/hotspot/share/runtime/vframe.cpp ! src/java.base/share/classes/sun/security/ssl/X509TrustManagerImpl.java ! test/hotspot/jtreg/ProblemList-Xcomp.txt ! test/hotspot/jtreg/ProblemList.txt Changeset: dc58d9b1 Branch: fibers Author: Alan Bateman Date: 2024-07-16 15:17:26 +0000 URL: https://git.openjdk.org/loom/commit/dc58d9b15ad26553581493bb3ae01f4f46f4c4f6 Minor javadoc update ! src/java.base/share/classes/java/util/concurrent/StructuredTaskScope.java Changeset: 72dfafcf Branch: fibers Author: Alan Bateman Date: 2024-07-17 11:30:46 +0000 URL: https://git.openjdk.org/loom/commit/72dfafcfeb030f012bad57f0fe192d723923b205 Re-add cancel (was shutdown) ! src/java.base/share/classes/java/util/concurrent/StructuredTaskScope.java ! test/jdk/java/util/concurrent/StructuredTaskScope/StructuredTaskScopeTest.java Changeset: 954b2bfc Branch: fibers Author: Alan Bateman Date: 2024-07-18 11:17:11 +0000 URL: https://git.openjdk.org/loom/commit/954b2bfc14b4f008dc26c800688d65f3933c4e76 Reorder examples ! src/java.base/share/classes/java/util/concurrent/StructuredTaskScope.java Changeset: eead9cc0 Branch: fibers Author: Alan Bateman Date: 2024-07-19 08:34:02 +0000 URL: https://git.openjdk.org/loom/commit/eead9cc038fad39cf25585e4ba6d59635ac95c79 Parallelize execution, move test output to stderr to inline with JUnit output ! test/jdk/java/lang/Thread/virtual/MonitorsTest.java Changeset: 5ad6cf7e Branch: fibers Author: Alan Bateman Date: 2024-07-20 09:33:12 +0000 URL: https://git.openjdk.org/loom/commit/5ad6cf7e42e1faf3741b5b3684b94c3d71595052 Merge Changeset: 17091805 Branch: fibers Author: Alan Bateman Date: 2024-07-20 12:14:16 +0000 URL: https://git.openjdk.org/loom/commit/170918053fa4d136764b3f8c53cb1b33ff081c2c Increase timeout to allow for debug builds ! test/jdk/java/foreign/TestConcurrentClose.java From duke at openjdk.org Sat Jul 20 12:54:14 2024 From: duke at openjdk.org (duke) Date: Sat, 20 Jul 2024 12:54:14 GMT Subject: git: openjdk/loom: master: 25 new changesets Message-ID: <634ac82f-d236-485c-8767-d340e8762af5@openjdk.org> Changeset: 5f7b0072 Branch: master Author: Kim Barrett Date: 2024-07-18 15:24:51 +0000 URL: https://git.openjdk.org/loom/commit/5f7b0072cfe7434b43dea53b2a8d55c56c6668ea 8336346: Fix -Wzero-as-null-pointer-constant warnings in jvmciJavaClasses.cpp Reviewed-by: jwaters, thartmann ! src/hotspot/share/jvmci/jvmciJavaClasses.cpp Changeset: 245c0866 Branch: master Author: Vicente Romero Date: 2024-07-18 15:54:41 +0000 URL: https://git.openjdk.org/loom/commit/245c08664896d63ac050ebc23259b23908dafed5 8332600: javac uses record components source position during compilation Reviewed-by: jlahoda ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java ! test/langtools/tools/javac/records/RecordCompilationTests.java Changeset: bbc79a5e Branch: master Author: Joe Darcy Date: 2024-07-18 16:33:48 +0000 URL: https://git.openjdk.org/loom/commit/bbc79a5e0144cb5ee6051e078681f9c6821441cb 8333768: Minor doc updates to java.lang.{Float, Double} Reviewed-by: rgiulietti ! src/java.base/share/classes/java/lang/Double.java ! src/java.base/share/classes/java/lang/Float.java ! src/java.base/share/classes/java/lang/Math.java ! src/java.base/share/classes/java/lang/StrictMath.java Changeset: 02be7b8d Branch: master Author: Phil Race Date: 2024-07-18 17:35:06 +0000 URL: https://git.openjdk.org/loom/commit/02be7b8ddcdb62977770cb5052e86bcada8478ba 8334495: Use FFM instead of jdk.internal.misc.Unsafe in java.desktop font implementation Reviewed-by: jdv, dnguyen, achung ! src/java.desktop/share/classes/sun/font/FileFontStrike.java ! src/java.desktop/share/classes/sun/font/GlyphList.java ! src/java.desktop/share/classes/sun/font/StrikeCache.java ! src/java.desktop/share/native/libfontmanager/sunFont.c ! src/java.desktop/unix/classes/sun/font/XRGlyphCacheEntry.java Changeset: b44632aa Branch: master Author: Chen Liang Date: 2024-07-18 21:46:07 +0000 URL: https://git.openjdk.org/loom/commit/b44632aa15d21a10e559aee02a9e4dcd876654f6 8336588: Ensure Transform downstream receives upstream start items only after downstream started Reviewed-by: asotona ! src/java.base/share/classes/jdk/internal/classfile/impl/TransformImpl.java ! test/jdk/jdk/classfile/TransformTests.java Changeset: 902c2afb Branch: master Author: Chen Liang Date: 2024-07-18 21:46:19 +0000 URL: https://git.openjdk.org/loom/commit/902c2afb6714f778e3229c8411e9f9d5c392b388 8336585: BoundAttribute.readEntryList not type-safe Reviewed-by: asotona ! src/java.base/share/classes/jdk/internal/classfile/impl/BoundAttribute.java ! test/jdk/jdk/classfile/BoundAttributeTest.java Changeset: 39f44768 Branch: master Author: Chen Liang Date: 2024-07-18 22:22:59 +0000 URL: https://git.openjdk.org/loom/commit/39f44768131254ee11f723f92e2bac57b0d1ade0 8334772: Change Class::signers to an explicit field Reviewed-by: dholmes, alanb, rriggs, coleenp ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/classfile/javaClasses.hpp ! src/hotspot/share/include/jvm.h ! src/hotspot/share/prims/jvm.cpp ! src/java.base/share/classes/java/lang/Class.java ! src/java.base/share/native/libjava/Class.c Changeset: 330e520c Branch: master Author: Fernando Guallini Date: 2024-07-18 22:36:26 +0000 URL: https://git.openjdk.org/loom/commit/330e520c1d42d3a9f3e187873dcd8ed7fd561aaf 8028127: Regtest java/security/Security/SynchronizedAccess.java is incorrect Reviewed-by: wetmore, mdonovan, rhalade ! test/jdk/java/security/Security/SynchronizedAccess.java Changeset: 1b9270ac Branch: master Author: Prajwal Kumaraswamy Committer: Bradford Wetmore Date: 2024-07-18 22:42:34 +0000 URL: https://git.openjdk.org/loom/commit/1b9270ac8a76b482103dd3f6b12606a22214e554 8328723: IP Address error when client enables HTTPS endpoint check on server socket Reviewed-by: wetmore, djelinski ! src/java.base/share/classes/sun/security/ssl/X509TrustManagerImpl.java Changeset: 902bada2 Branch: master Author: Prasanta Sadhukhan Date: 2024-07-19 02:56:42 +0000 URL: https://git.openjdk.org/loom/commit/902bada2cdd141ade8615d1e3c2fcbff2b80e3b1 8234071: JTable.AUTO_RESIZE_LAST_COLUMN acts like AUTO_RESIZE_ALL_COLUMNS Reviewed-by: prr, abhiscxk ! src/java.desktop/share/classes/javax/swing/JTable.java Changeset: f5871df2 Branch: master Author: Andrey Turbanov Date: 2024-07-19 05:54:25 +0000 URL: https://git.openjdk.org/loom/commit/f5871df25c60990825babb3bbae38c5ade93f097 8336675: Remove UnixFileSystemProvider.checkPath in favor of UnixPath.toUnixPath Reviewed-by: jpai, alanb, bpb ! src/java.base/unix/classes/sun/nio/fs/UnixFileSystemProvider.java Changeset: 10fcad70 Branch: master Author: David Holmes Date: 2024-07-19 06:23:11 +0000 URL: https://git.openjdk.org/loom/commit/10fcad70b3894023d65716b42dc67c1a2bda9c03 8325945: Error reporting should limit the number of String characters printed Reviewed-by: thartmann, stuefe ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/classfile/javaClasses.hpp ! src/hotspot/share/prims/whitebox.cpp ! src/hotspot/share/runtime/globals.hpp + test/hotspot/jtreg/runtime/PrintingTests/StringPrinting.java ! test/lib/jdk/test/whitebox/WhiteBox.java Changeset: fa5ad700 Branch: master Author: SendaoYan Committer: Serguei Spitsyn Date: 2024-07-19 07:06:51 +0000 URL: https://git.openjdk.org/loom/commit/fa5ad700bb6a92aef7577969e09b4fbd93feb388 8334771: [TESTBUG] Run TestDockerMemoryMetrics.java with -Xcomp fails exitValue = 137 Reviewed-by: lmesnik, sspitsyn ! test/jdk/jdk/internal/platform/docker/MetricsMemoryTester.java ! test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetrics.java Changeset: 10982fe5 Branch: master Author: Roland Westrelin Date: 2024-07-19 07:28:51 +0000 URL: https://git.openjdk.org/loom/commit/10982fe557e9e8b68b674630a9979cb355bdbe62 8335843: C2 hits assert(_print_inlining_stream->size() > 0) failed: missing inlining msg Reviewed-by: thartmann, kvn, vlivanov ! src/hotspot/share/opto/callGenerator.cpp + test/hotspot/jtreg/compiler/print/TestPrintInliningLateMHCall.java ! test/hotspot/jtreg/compiler/print/TestPrintInliningLateVirtualCall.java Changeset: 0ddf54e2 Branch: master Author: Roland Westrelin Date: 2024-07-19 07:30:23 +0000 URL: https://git.openjdk.org/loom/commit/0ddf54e222104469669f611804ae55e2685f54fb 8335709: C2: assert(!loop->is_member(get_loop(useblock))) failed: must be outside loop Co-authored-by: Emanuel Peter Reviewed-by: epeter, thartmann ! src/hotspot/share/opto/loopnode.cpp + test/hotspot/jtreg/compiler/loopopts/InfiniteLoopBadControlNeverBranch.java Changeset: b703be9c Branch: master Author: Aleksey Shipilev Date: 2024-07-19 08:34:36 +0000 URL: https://git.openjdk.org/loom/commit/b703be9cf633796456991279d07cbde98ad7f1aa 8336465: C2: EA incorrectly/unnecessarily checks for clinits Reviewed-by: kvn, thartmann ! src/hotspot/share/opto/bytecodeInfo.cpp Changeset: 5d965f36 Branch: master Author: Aleksey Shipilev Date: 2024-07-19 08:34:47 +0000 URL: https://git.openjdk.org/loom/commit/5d965f36d3cd7a1a1f22bf119a98a9e9576a647f 8336466: C2: Parser incorrectly/unnecessarily checks for clinits Reviewed-by: kvn, thartmann ! src/hotspot/share/opto/callnode.cpp ! src/hotspot/share/opto/parse1.cpp Changeset: 84bc4767 Branch: master Author: Volker Simonis Date: 2024-07-19 11:26:44 +0000 URL: https://git.openjdk.org/loom/commit/84bc4767a4cd68fb52a36c6644bbec67c24b0e1d 8336258: Document the behavior of 'exclude' and 'compileonly' with respect to inlining Reviewed-by: thartmann, jkarthikeyan ! src/hotspot/share/compiler/compilerOracle.cpp Changeset: 6e9fcc2d Branch: master Author: Jie Fu Date: 2024-07-19 12:28:56 +0000 URL: https://git.openjdk.org/loom/commit/6e9fcc2d80170c79e45b8710e98754c67d544012 8336816: runtime/PrintingTests/StringPrinting.java fails with release VMs Reviewed-by: dholmes ! test/hotspot/jtreg/runtime/PrintingTests/StringPrinting.java Changeset: c25c4896 Branch: master Author: Adam Sotona Date: 2024-07-19 13:09:45 +0000 URL: https://git.openjdk.org/loom/commit/c25c4896ad9ef031e3cddec493aef66ff87c48a7 8333812: ClassFile.verify() can throw exceptions instead of returning VerifyErrors Reviewed-by: liach ! src/java.base/share/classes/jdk/internal/classfile/impl/BoundAttribute.java ! src/java.base/share/classes/jdk/internal/classfile/impl/ClassFileImpl.java ! src/java.base/share/classes/jdk/internal/classfile/impl/verifier/VerifierImpl.java ! test/jdk/jdk/classfile/VerifierSelfTest.java Changeset: 3ade2b61 Branch: master Author: Chen Liang Date: 2024-07-19 21:25:20 +0000 URL: https://git.openjdk.org/loom/commit/3ade2b6114bbe81eb03e3a49c08b5401f70a2367 8336777: BufferedMethodBuilder not initialized with static flag Reviewed-by: asotona ! src/java.base/share/classes/jdk/internal/classfile/impl/BufferedMethodBuilder.java ! src/java.base/share/classes/jdk/internal/classfile/impl/ChainedClassBuilder.java ! src/java.base/share/classes/jdk/internal/classfile/impl/DirectMethodBuilder.java ! src/java.base/share/classes/jdk/internal/classfile/impl/MethodInfo.java ! src/java.base/share/classes/jdk/internal/classfile/impl/TerminalMethodBuilder.java + test/jdk/jdk/classfile/MethodBuilderStaticFlagTest.java Changeset: 939fe000 Branch: master Author: Liam Miller-Cushon Date: 2024-07-19 21:52:45 +0000 URL: https://git.openjdk.org/loom/commit/939fe000a96bc7c92c7b8814eb6ee66856718e4e 8336786: VerifyError with lambda capture and enclosing instance references Reviewed-by: mcimadamore ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java + test/langtools/tools/javac/lambda/SuperClassThisCapture/SuperClassThisCapture.java = test/langtools/tools/javac/lambda/SuperClassThisCapture/a/A.java Changeset: e7e48a78 Branch: master Author: Chris Plummer Date: 2024-07-19 21:53:04 +0000 URL: https://git.openjdk.org/loom/commit/e7e48a780a34007994f830869fdb74ba1cb5b3fe 8248609: [Graal] vmTestbase/nsk/jdi/VoidValue/toString/tostring001/TestDescription.java failed with Unexpected com.sun.jdi.ObjectCollectedException Reviewed-by: amenkov, lmesnik ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VoidValue/toString/tostring001.java Changeset: e3acf4c6 Branch: master Author: Shaojin Wen Committer: Chen Liang Date: 2024-07-19 22:06:23 +0000 URL: https://git.openjdk.org/loom/commit/e3acf4c627c3c75f9a2ef29647daa6f4746fdc62 8336792: DateTimeFormatterBuilder append zeros based on StringBuilder.repeat Reviewed-by: liach, rriggs, naoto ! src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java Changeset: 491b9f5e Branch: master Author: Shaojin Wen Committer: Chen Liang Date: 2024-07-20 06:54:19 +0000 URL: https://git.openjdk.org/loom/commit/491b9f5efc01fa36fb3c174e130b46bc69c8d707 8336706: Optimize LocalDate.toString with StringBuilder.repeat Reviewed-by: liach, rriggs ! src/java.base/share/classes/java/time/LocalDate.java From yuval.l at securithings.com Sun Jul 21 07:05:44 2024 From: yuval.l at securithings.com (Yuval Lombard) Date: Sun, 21 Jul 2024 10:05:44 +0300 Subject: Experiencing an issue with ScheduledExecutorService alongside VT Message-ID: Hey team We are experiencing some weird halting issues when scheduling tasks with ScheduledExecutorService and VT. We are observing some near deadlock issues / halting of executors which we are not able to reproduce when using platform threads This is one example of a near deadlock situation, where for some reason virtual threads are starting to execute a task, and not reaching the finally block nor the catch Throwable block to release the acquired semaphore permit, reaching to drained semaphore. Are you familiar with this behavior? I hope we are doing something wrong ? Note - The scheduler is running on a platform thread ```ScheduledFuture deviceFutureTask = scheduler.scheduleAtFixedRate(() -> { try { logger.debug("[{}] Trying to acquire permit to schedule task [{}] for device. Number of available permits: [{}]", device, task, semaphore.availablePermits()); if (semaphore.tryAcquire(waitingTimeout, TimeUnit.MILLISECONDS)) { logger.debug("[{}] Acquired permit to schedule [{}] task for device", device, task); Thread.ofVirtual().start(() -> { try { logger.debug("[{}] Scheduling [{}] task for device", device, task); // some I/O intensive work logger.debug("[{}] Finished processing [{}] task for device", device, task); } catch (Exception e) { logger.error("[{}] Failed to process [{}] task for device", device, task, e); } finally { semaphore.release(); } }); } else { logger.error("Timed out while waiting for permit to schedule task [{}] for device [{}]", task, device); } } catch (Throwable t) { logger.error("Failed to execute task [{}] for device [{}]", task, deviceId, t); semaphore.release(); } }, (long) (entropy * schedulingInterval), schedulingInterval, TimeUnit. MILLISECONDS);``` We are -- Kind regards, *Yuval Lombard* *Lead Software Engineer* +972.50.548.0111 yuval.l at securithings.com [image: logo_black.png] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo_black.png Type: image/png Size: 99833 bytes Desc: not available URL: From yuval.l at securithings.com Sun Jul 21 07:16:07 2024 From: yuval.l at securithings.com (Yuval Lombard) Date: Sun, 21 Jul 2024 10:16:07 +0300 Subject: Experiencing an issue with ScheduledExecutorService alongside VT In-Reply-To: References: Message-ID: Did not mention by I based the code on version 23-loom+4-102 On Sun, 21 Jul 2024 at 10:05, Yuval Lombard wrote: > Hey team > > We are experiencing some weird halting issues when scheduling tasks with > ScheduledExecutorService and VT. > > We are observing some near deadlock issues / halting of executors which we > are not able to reproduce when using platform threads > > This is one example of a near deadlock situation, where for some reason > virtual threads are starting to execute a task, and not reaching the > finally block nor the catch Throwable block to release the acquired > semaphore permit, reaching to drained semaphore. > > Are you familiar with this behavior? I hope we are doing something wrong ? > > Note - The scheduler is running on a platform thread > > ```ScheduledFuture deviceFutureTask = scheduler.scheduleAtFixedRate(() > -> { > > try { > > logger.debug("[{}] Trying to acquire permit to schedule task [{}] for > device. Number of available permits: [{}]", > > device, task, semaphore.availablePermits()); > > if (semaphore.tryAcquire(waitingTimeout, TimeUnit.MILLISECONDS)) { > > logger.debug("[{}] Acquired permit to schedule [{}] task for device", > device, task); > > Thread.ofVirtual().start(() -> { > > try { > > logger.debug("[{}] Scheduling [{}] task for device", device, task); > > // some I/O intensive work > > logger.debug("[{}] Finished processing [{}] task for device", device, > task); > > } catch (Exception e) { > > logger.error("[{}] Failed to process [{}] task for device", device, task, > e); > > } finally { > > semaphore.release(); > > } > > }); > > } else { > > logger.error("Timed out while waiting for permit to schedule task [{}] > for device [{}]", task, device); > > } > > } catch (Throwable t) { > > logger.error("Failed to execute task [{}] for device [{}]", task, > deviceId, t); > > semaphore.release(); > > } > > }, (long) (entropy * schedulingInterval), schedulingInterval, TimeUnit. > MILLISECONDS);``` > > > We are > -- > > Kind regards, > > *Yuval Lombard* > > *Lead Software Engineer* > > +972.50.548.0111 > > yuval.l at securithings.com > > [image: logo_black.png] > -- Kind regards, *Yuval Lombard* *Lead Software Engineer* +972.50.548.0111 yuval.l at securithings.com [image: logo_black.png] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo_black.png Type: image/png Size: 99833 bytes Desc: not available URL: From yuval.l at securithings.com Sun Jul 21 08:01:54 2024 From: yuval.l at securithings.com (Yuval Lombard) Date: Sun, 21 Jul 2024 11:01:54 +0300 Subject: Experiencing an issue with ScheduledExecutorService alongside VT In-Reply-To: References: Message-ID: I will rewrite everything again as it lacks some context and information. Hey team We are experiencing some weird halting issues when scheduling tasks with ScheduledExecutorService and VT. We are observing some *random* near deadlock issues / halting of executors which we are not able to reproduce when using platform threads. It happens after a random amount of time. This is one example of a near deadlock situation, where the scheduling platform thread successfully acquires a semaphore permit, assumingly starting a virtual thread, but the debug log "Scheduling..." is not being printed at all, preventing the finally block or the catch Throwable block from releasing the acquired semaphore permit, and reaching to drained semaphore. Few notes: - We are testing on EA build 23-loom+4-102 - The scheduler is running on a platform thread *- Flight recorder does not indicate any pinned VT*- This code is running within a Docker container based on ubuntu:20.04 image - Using G1 GC Has anyone experienced this issue before? I hope we are doing something wrong ? ```ScheduledFuture deviceFutureTask = scheduler.scheduleAtFixedRate(() -> { try { logger.debug("[{}] Trying to acquire permit to schedule task [{}] for device. Number of available permits: [{}]", device, task, semaphore.availablePermits()); if (semaphore.tryAcquire(waitingTimeout, TimeUnit.MILLISECONDS)) { logger.debug("[{}] Acquired permit to schedule [{}] task for device", device, task); Thread.ofVirtual().start(() -> { try { logger.debug("[{}] Scheduling [{}] task for device", device, task); // some I/O intensive work logger.debug("[{}] Finished processing [{}] task for device", device, task); } catch (Exception e) { logger.error("[{}] Failed to process [{}] task for device", device, task, e); } finally { semaphore.release(); } }); } else { logger.error("Timed out while waiting for permit to schedule task [{}] for device [{}]", task, device); } } catch (Throwable t) { logger.error("Failed to execute task [{}] for device [{}]", task, deviceId, t); semaphore.release(); } }, (long) (entropy * schedulingInterval), schedulingInterval, TimeUnit. MILLISECONDS);``` On Sun, 21 Jul 2024 at 10:16, Yuval Lombard wrote: > Did not mention by I based the code on version 23-loom+4-102 > > On Sun, 21 Jul 2024 at 10:05, Yuval Lombard > wrote: > >> Hey team >> >> We are experiencing some weird halting issues when scheduling tasks with >> ScheduledExecutorService and VT. >> >> We are observing some near deadlock issues / halting of executors which >> we are not able to reproduce when using platform threads >> >> This is one example of a near deadlock situation, where for some reason >> virtual threads are starting to execute a task, and not reaching the >> finally block nor the catch Throwable block to release the acquired >> semaphore permit, reaching to drained semaphore. >> >> Are you familiar with this behavior? I hope we are doing something >> wrong ? >> >> Note - The scheduler is running on a platform thread >> >> ```ScheduledFuture deviceFutureTask = scheduler.scheduleAtFixedRate(() >> -> { >> >> try { >> >> logger.debug("[{}] Trying to acquire permit to schedule task [{}] for >> device. Number of available permits: [{}]", >> >> device, task, semaphore.availablePermits()); >> >> if (semaphore.tryAcquire(waitingTimeout, TimeUnit.MILLISECONDS)) { >> >> logger.debug("[{}] Acquired permit to schedule [{}] task for device", >> device, task); >> >> Thread.ofVirtual().start(() -> { >> >> try { >> >> logger.debug("[{}] Scheduling [{}] task for device", device, task); >> >> // some I/O intensive work >> >> logger.debug("[{}] Finished processing [{}] task for device", device, >> task); >> >> } catch (Exception e) { >> >> logger.error("[{}] Failed to process [{}] task for device", device, >> task, e); >> >> } finally { >> >> semaphore.release(); >> >> } >> >> }); >> >> } else { >> >> logger.error("Timed out while waiting for permit to schedule task [{}] >> for device [{}]", task, device); >> >> } >> >> } catch (Throwable t) { >> >> logger.error("Failed to execute task [{}] for device [{}]", task, >> deviceId, t); >> >> semaphore.release(); >> >> } >> >> }, (long) (entropy * schedulingInterval), schedulingInterval, TimeUnit. >> MILLISECONDS);``` >> >> >> We are >> -- >> >> Kind regards, >> >> *Yuval Lombard* >> >> *Lead Software Engineer* >> >> +972.50.548.0111 >> >> yuval.l at securithings.com >> >> [image: logo_black.png] >> > > > -- > > Kind regards, > > *Yuval Lombard* > > *Lead Software Engineer* > > +972.50.548.0111 > > yuval.l at securithings.com > > [image: logo_black.png] > -- Kind regards, *Yuval Lombard* *Lead Software Engineer* +972.50.548.0111 yuval.l at securithings.com [image: logo_black.png] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo_black.png Type: image/png Size: 99833 bytes Desc: not available URL: From Alan.Bateman at oracle.com Sun Jul 21 08:14:22 2024 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 21 Jul 2024 09:14:22 +0100 Subject: Experiencing an issue with ScheduledExecutorService alongside VT In-Reply-To: References: Message-ID: <3cdd7056-6321-4653-be4d-71bf5bea55e5@oracle.com> On 21/07/2024 08:05, Yuval Lombard wrote: > Hey team > > We are experiencing some weird halting issues when scheduling tasks > with ScheduledExecutorService and VT. > > We are observing some near deadlock issues / halting of executors > which we are not able to reproduce when using platform threads > > This is one example of a near deadlock situation, where for some > reason virtual threads are starting to execute a task, and not > reaching the finally block nor the catch Throwable block to release > the acquired semaphore permit, reaching to drained semaphore. Is "Scheduling .. task for device" logged? Did you take thread dump with `java Thread.dump_to_file ` and try to identify the virtual thread? One of the later mails mentions 23-loom+4-102 and not seeing JFR events. Can you re-run with the latest EA build (currently 24-loom+2-24) as that has changes for the JFR events that may provide some insight here. -Alan From yuval.l at securithings.com Sun Jul 21 09:41:29 2024 From: yuval.l at securithings.com (Yuval Lombard) Date: Sun, 21 Jul 2024 12:41:29 +0300 Subject: Experiencing an issue with ScheduledExecutorService alongside VT In-Reply-To: <3cdd7056-6321-4653-be4d-71bf5bea55e5@oracle.com> References: <3cdd7056-6321-4653-be4d-71bf5bea55e5@oracle.com> Message-ID: Hi Alan Thanks for replying! When the issue occurs the Log you mentioned is not being printed - it is as if (or maybe it is even what is really happening) the virtual thread is not being scheduled (by its internal scheduler) I to a thread dump by executing "kill -3 " and did not see the VT, will `java Thread.dump_to_file ` produce a more detailed view of the living threads? I will try to run the later EA build On Sun, 21 Jul 2024 at 11:14, Alan Bateman wrote: > On 21/07/2024 08:05, Yuval Lombard wrote: > > Hey team > > > > We are experiencing some weird halting issues when scheduling tasks > > with ScheduledExecutorService and VT. > > > > We are observing some near deadlock issues / halting of executors > > which we are not able to reproduce when using platform threads > > > > This is one example of a near deadlock situation, where for some > > reason virtual threads are starting to execute a task, and not > > reaching the finally block nor the catch Throwable block to release > > the acquired semaphore permit, reaching to drained semaphore. > > > Is "Scheduling .. task for device" logged? Did you take thread dump with > `java Thread.dump_to_file ` and try to identify the virtual > thread? > > One of the later mails mentions 23-loom+4-102 and not seeing JFR events. > Can you re-run with the latest EA build (currently 24-loom+2-24) as that > has changes for the JFR events that may provide some insight here. > > -Alan > -- Kind regards, *Yuval Lombard* *Lead Software Engineer* +972.50.548.0111 yuval.l at securithings.com [image: logo_black.png] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo_black.png Type: image/png Size: 99833 bytes Desc: not available URL: From yuval.l at securithings.com Sun Jul 21 13:11:20 2024 From: yuval.l at securithings.com (Yuval Lombard) Date: Sun, 21 Jul 2024 16:11:20 +0300 Subject: Experiencing an issue with ScheduledExecutorService alongside VT In-Reply-To: References: <3cdd7056-6321-4653-be4d-71bf5bea55e5@oracle.com> Message-ID: Hi Alan, Attaching the thread dump when the issue occurs (as a txt file) It might be useful On Sun, 21 Jul 2024 at 12:41, Yuval Lombard wrote: > Hi Alan > > Thanks for replying! > > When the issue occurs the Log you mentioned is not being printed - it is > as if (or maybe it is even what is really happening) the virtual thread is > not being scheduled (by its internal scheduler) > I to a thread dump by executing "kill -3 " and did not see the VT, > will `java Thread.dump_to_file ` produce a more detailed view > of the living threads? > > I will try to run the later EA build > > On Sun, 21 Jul 2024 at 11:14, Alan Bateman > wrote: > >> On 21/07/2024 08:05, Yuval Lombard wrote: >> > Hey team >> > >> > We are experiencing some weird halting issues when scheduling tasks >> > with ScheduledExecutorService and VT. >> > >> > We are observing some near deadlock issues / halting of executors >> > which we are not able to reproduce when using platform threads >> > >> > This is one example of a near deadlock situation, where for some >> > reason virtual threads are starting to execute a task, and not >> > reaching the finally block nor the catch Throwable block to release >> > the acquired semaphore permit, reaching to drained semaphore. >> >> >> Is "Scheduling .. task for device" logged? Did you take thread dump with >> `java Thread.dump_to_file ` and try to identify the virtual >> thread? >> >> One of the later mails mentions 23-loom+4-102 and not seeing JFR events. >> Can you re-run with the latest EA build (currently 24-loom+2-24) as that >> has changes for the JFR events that may provide some insight here. >> >> -Alan >> > > > -- > > Kind regards, > > *Yuval Lombard* > > *Lead Software Engineer* > > +972.50.548.0111 > > yuval.l at securithings.com > > [image: logo_black.png] > -- Kind regards, *Yuval Lombard* *Lead Software Engineer* +972.50.548.0111 yuval.l at securithings.com [image: logo_black.png] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo_black.png Type: image/png Size: 99833 bytes Desc: not available URL: -------------- next part -------------- Full thread dump OpenJDK 64-Bit Server VM (23-loom+4-102 mixed mode, sharing): Threads class SMR info: _java_thread_list=0x00007f8a50d73ee0, length=175, elements={ 0x00007f8ae816ca30, 0x00007f8ae816e0b0, 0x00007f8ae816fea0, 0x00007f8ae8171510, 0x00007f8ae8172ae0, 0x00007f8ae8174630, 0x00007f8ae8175d70, 0x00007f8ae8177ac0, 0x00007f8ae8185e90, 0x00007f8ae81897d0, 0x00007f8ae8207210, 0x00007f8ae9b48aa0, 0x00007f8ae8e49300, 0x00007f8ae8e4a210, 0x00007f8ae8e4b600, 0x00007f8ae8e4c6e0, 0x00007f8ae8e4d930, 0x00007f8ae8e4eb90, 0x00007f8ae8e501e0, 0x00007f8ae8e51840, 0x00007f8ae9d8ae70, 0x00007f8ae9de3900, 0x00007f8ae9de9850, 0x00007f8ae9ee9380, 0x00007f8ae9eeb1a0, 0x00007f8a14001e30, 0x00007f8aea452cd0, 0x00007f8aea4ac620, 0x00007f8aea5a4300, 0x00007f8aea694690, 0x00007f8aea6b8660, 0x00007f8aea6ec910, 0x00007f8aea16d9e0, 0x00007f8a14006730, 0x00007f8aea16f010, 0x00007f8a34003bd0, 0x00007f8a14010070, 0x00007f8aea169b20, 0x00007f8aea701af0, 0x00007f8ae9bc4f30, 0x00007f8aea1687d0, 0x00007f8ae9bcb470, 0x00007f8ae9bc9160, 0x00007f8ae9bca410, 0x00007f8aea035940, 0x00007f8ae9bc7320, 0x00007f8ae9bc7a60, 0x00007f8aea034a80, 0x00007f8aea02e6b0, 0x00007f8aea032fa0, 0x00007f8aea1b86f0, 0x00007f8aea1bda50, 0x00007f8aea1bee00, 0x00007f8aea1b7380, 0x00007f8aea1c09f0, 0x00007f8aea1c1d00, 0x00007f8aea1c6920, 0x00007f8aea1c7d30, 0x00007f8aea1c8ee0, 0x00007f8aea1ca090, 0x00007f8aea1d74a0, 0x00007f8aea27b2f0, 0x00007f8aea27bfb0, 0x00007f8aea27d260, 0x00007f8aea1c31d0, 0x00007f8aea1c4ad0, 0x00007f8aea286350, 0x00007f8aea1fd190, 0x00007f8aea198930, 0x00007f8ae9ba9970, 0x00007f8aea0aaa80, 0x00007f8ae9c57860, 0x00007f8aea0289b0, 0x00007f8ae9c11170, 0x00007f8aea788830, 0x00007f8ae9cc6b40, 0x00007f8ae9cc8590, 0x00007f8aea7c7a60, 0x00007f8a44f73850, 0x00007f8a44f7ec60, 0x00007f8a44f7fc70, 0x00007f8a44f810e0, 0x00007f8a44f85fb0, 0x00007f8a44f87f20, 0x00007f8aea7bb470, 0x00007f8ae9f71e00, 0x00007f8ae9f7e9a0, 0x00007f8ae99e5ef0, 0x00007f8aea2125f0, 0x00007f8aea91fd40, 0x00007f8aea9054f0, 0x00007f8aea90c330, 0x00007f8aea92a660, 0x00007f8aea92c900, 0x00007f8aea92ed40, 0x00007f8aea930870, 0x00007f8aeaa665e0, 0x00007f8aeaa6fee0, 0x00007f8aeabc4ee0, 0x00007f8aeabc5f00, 0x00007f8aeabc7030, 0x00007f8aeabd3fd0, 0x00007f8aeabd5050, 0x00007f8aeabd6570, 0x00007f8aeabd7720, 0x00007f8aeabd8c50, 0x00007f8aeabd3820, 0x00007f8ae8029de0, 0x00007f8a1c014ac0, 0x00007f8a2405dd80, 0x00007f8a1c021b60, 0x00007f8a3c010e00, 0x00007f8a24064530, 0x00007f8a3407ab60, 0x00007f8a1c0231c0, 0x00007f8a3c012370, 0x00007f8a6000acd0, 0x00007f8a24061600, 0x00007f8a340531b0, 0x00007f8a5c04ece0, 0x00007f8a641f4ce0, 0x00007f8a3005c150, 0x00007f8a3c0143f0, 0x00007f8a6000c990, 0x00007f8a0c0083f0, 0x00007f8a34080730, 0x00007f8a5c04f420, 0x00007f8a4000e260, 0x00007f8a641f5560, 0x00007f8a140afa50, 0x00007f8a6000db90, 0x00007f8a0c009410, 0x00007f8a4c03b130, 0x00007f8a5c0500d0, 0x00007f8a641f6910, 0x00007f8a5402b290, 0x00007f8a14043240, 0x00007f8a0c012b20, 0x00007f8ac0735800, 0x00007f8a04096810, 0x00007f8a1021b8f0, 0x00007f8a14881340, 0x00007f8a30027190, 0x00007f8a48658fc0, 0x00007f8a4529a010, 0x00007f8ac802e600, 0x00007f8ac0738670, 0x00007f8ac802ed40, 0x00007f8ac01e8510, 0x00007f8ac8031340, 0x00007f8ac01e97b0, 0x00007f8aea9ad0a0, 0x0000556b55612100, 0x00007f8a30032640, 0x00007f8a3002bd20, 0x00007f8a30039fd0, 0x00007f8a2c0168c0, 0x00007f8a14162f80, 0x00007f8a041bb560, 0x00007f8a041b8620, 0x00007f8a041b9410, 0x00007f8a10011140, 0x00007f8a144cfea0, 0x00007f8a2c017000, 0x00007f8a2c028dc0, 0x00007f8a2c01ccd0, 0x00007f8a38221550, 0x00007f8a48d7f130, 0x00007f8a48dba690, 0x00007f8a48d373b0, 0x00007f8a44a3a160, 0x00007f8a341875b0, 0x00007f8a44ad3cc0, 0x00007f8a1404d210, 0x00007f8a48d30db0 } "Reference Handler" #11 [94] daemon prio=10 os_prio=0 cpu=32.80ms elapsed=7216.06s tid=0x00007f8ae816ca30 nid=94 waiting on condition ?[0x00007f8acc3e4000] ? ?java.lang.Thread.State: RUNNABLE ? ? ? ? at java.lang.ref.Reference.waitForReferencePendingList(java.base at 23-loom/Native Method) ? ? ? ? at java.lang.ref.Reference.processPendingReferences(java.base at 23-loom/Reference.java:246) ? ? ? ? at java.lang.ref.Reference$ReferenceHandler.run(java.base at 23-loom/Reference.java:208) "Finalizer" #12 [95] daemon prio=8 os_prio=0 cpu=0.26ms elapsed=7216.06s tid=0x00007f8ae816e0b0 nid=95 in Object.wait() ?[0x00007f8acc2e3000] ? ?java.lang.Thread.State: WAITING (on object monitor) ? ? ? ? at java.lang.Object.wait0(java.base at 23-loom/Native Method) ? ? ? ? - waiting on <0x000000070c0cb560> (a java.lang.ref.NativeReferenceQueue$Lock) ? ? ? ? at java.lang.Object.wait(java.base at 23-loom/Object.java:389) ? ? ? ? at java.lang.Object.wait(java.base at 23-loom/Object.java:347) ? ? ? ? at java.lang.ref.NativeReferenceQueue.await(java.base at 23-loom/NativeReferenceQueue.java:48) ? ? ? ? at java.lang.ref.ReferenceQueue.remove0(java.base at 23-loom/ReferenceQueue.java:158) ? ? ? ? at java.lang.ref.NativeReferenceQueue.remove(java.base at 23-loom/NativeReferenceQueue.java:89) ? ? ? ? - locked <0x000000070c0cb560> (a java.lang.ref.NativeReferenceQueue$Lock) ? ? ? ? at java.lang.ref.Finalizer$FinalizerThread.run(java.base at 23-loom/Finalizer.java:173) "Signal Dispatcher" #13 [96] daemon prio=9 os_prio=0 cpu=0.22ms elapsed=7216.06s tid=0x00007f8ae816fea0 nid=96 waiting on condition ?[0x0000000000000000] ? ?java.lang.Thread.State: RUNNABLE "Service Thread" #14 [97] daemon prio=9 os_prio=0 cpu=299.01ms elapsed=7216.06s tid=0x00007f8ae8171510 nid=97 runnable ?[0x0000000000000000] ? ?java.lang.Thread.State: RUNNABLE "Monitor Deflation Thread" #15 [98] daemon prio=9 os_prio=0 cpu=878.06ms elapsed=7216.06s tid=0x00007f8ae8172ae0 nid=98 runnable ?[0x0000000000000000] ? ?java.lang.Thread.State: RUNNABLE "C2 CompilerThread0" #16 [99] daemon prio=9 os_prio=0 cpu=129865.07ms elapsed=7216.06s tid=0x00007f8ae8174630 nid=99 waiting on condition ?[0x0000000000000000] ? ?java.lang.Thread.State: RUNNABLE ? ?No compile task "C1 CompilerThread0" #18 [100] daemon prio=9 os_prio=0 cpu=16353.40ms elapsed=7216.06s tid=0x00007f8ae8175d70 nid=100 waiting on condition ?[0x0000000000000000] ? ?java.lang.Thread.State: RUNNABLE ? ?No compile task "StringDedupThread" #19 [101] daemon prio=5 os_prio=0 cpu=5096.86ms elapsed=7216.06s tid=0x00007f8ae8177ac0 nid=101 runnable ?[0x0000000000000000] ? ?java.lang.Thread.State: RUNNABLE "Notification Thread" #20 [102] daemon prio=9 os_prio=0 cpu=1206.04ms elapsed=7216.05s tid=0x00007f8ae8185e90 nid=102 runnable ?[0x0000000000000000] ? ?java.lang.Thread.State: RUNNABLE "Common-Cleaner" #21 [103] daemon prio=8 os_prio=0 cpu=12.78ms elapsed=7216.05s tid=0x00007f8ae81897d0 nid=103 waiting on condition ?[0x00007f8abd9f8000] ? ?java.lang.Thread.State: TIMED_WAITING (parking) ? ? ? ? at jdk.internal.misc.Unsafe.park(java.base at 23-loom/Native Method) ? ? ? ? - parking to wait for ?<0x000000070c0cb748> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) ? ? ? ? at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 23-loom/LockSupport.java:271) ? ? ? ? at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(java.base at 23-loom/AbstractQueuedSynchronizer.java:1852) ? ? ? ? at java.lang.ref.ReferenceQueue.await(java.base at 23-loom/ReferenceQueue.java:71) ? ? ? ? at java.lang.ref.ReferenceQueue.remove0(java.base at 23-loom/ReferenceQueue.java:143) ? ? ? ? at java.lang.ref.ReferenceQueue.remove(java.base at 23-loom/ReferenceQueue.java:218) ? ? ? ? at jdk.internal.ref.CleanerImpl.run(java.base at 23-loom/CleanerImpl.java:140) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) ? ? ? ? at jdk.internal.misc.InnocuousThread.run(java.base at 23-loom/InnocuousThread.java:186) "Cleaner-0" #22 [104] daemon prio=8 os_prio=0 cpu=35.01ms elapsed=7215.89s tid=0x00007f8ae8207210 nid=104 waiting on condition ?[0x00007f8abd8f7000] ? ?java.lang.Thread.State: TIMED_WAITING (parking) ? ? ? ? at jdk.internal.misc.Unsafe.park(java.base at 23-loom/Native Method) ? ? ? ? - parking to wait for ?<0x000000070c0cb860> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) ? ? ? ? at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 23-loom/LockSupport.java:271) ? ? ? ? at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(java.base at 23-loom/AbstractQueuedSynchronizer.java:1852) ? ? ? ? at java.lang.ref.ReferenceQueue.await(java.base at 23-loom/ReferenceQueue.java:71) ? ? ? ? at java.lang.ref.ReferenceQueue.remove0(java.base at 23-loom/ReferenceQueue.java:143) ? ? ? ? at java.lang.ref.ReferenceQueue.remove(java.base at 23-loom/ReferenceQueue.java:218) ? ? ? ? at jdk.internal.ref.CleanerImpl.run(java.base at 23-loom/CleanerImpl.java:140) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) ? ? ? ? at jdk.internal.misc.InnocuousThread.run(java.base at 23-loom/InnocuousThread.java:186) "Cleaner-1" #30 [118] daemon prio=8 os_prio=0 cpu=5.70ms elapsed=7206.03s tid=0x00007f8ae9b48aa0 nid=118 waiting on condition ?[0x00007f8abd3f2000] ? ?java.lang.Thread.State: TIMED_WAITING (parking) ? ? ? ? at jdk.internal.misc.Unsafe.park(java.base at 23-loom/Native Method) ? ? ? ? - parking to wait for ?<0x000000070e8ece08> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) ? ? ? ? at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 23-loom/LockSupport.java:271) ? ? ? ? at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(java.base at 23-loom/AbstractQueuedSynchronizer.java:1852) ? ? ? ? at java.lang.ref.ReferenceQueue.await(java.base at 23-loom/ReferenceQueue.java:71) ? ? ? ? at java.lang.ref.ReferenceQueue.remove0(java.base at 23-loom/ReferenceQueue.java:143) ? ? ? ? at java.lang.ref.ReferenceQueue.remove(java.base at 23-loom/ReferenceQueue.java:218) ? ? ? ? at jdk.internal.ref.CleanerImpl.run(java.base at 23-loom/CleanerImpl.java:140) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) ? ? ? ? at jdk.internal.misc.InnocuousThread.run(java.base at 23-loom/InnocuousThread.java:186) "qtp1177232287-31" #31 [119] prio=5 os_prio=0 cpu=105.49ms elapsed=7205.74s tid=0x00007f8ae8e49300 nid=119 waiting on condition ?[0x00007f8abd2f1000] ? ?java.lang.Thread.State: TIMED_WAITING (parking) ? ? ? ? at jdk.internal.misc.Unsafe.park(java.base at 23-loom/Native Method) ? ? ? ? - parking to wait for ?<0x000000070c9f87b0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) ? ? ? ? at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 23-loom/LockSupport.java:271) ? ? ? ? at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(java.base at 23-loom/AbstractQueuedSynchronizer.java:1763) ? ? ? ? at org.eclipse.jetty.util.BlockingArrayQueue.poll(BlockingArrayQueue.java:219) ? ? ? ? at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.idleJobPoll(QueuedThreadPool.java:1139) ? ? ? ? at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1156) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "qtp1177232287-32" #32 [120] prio=5 os_prio=0 cpu=123.23ms elapsed=7205.74s tid=0x00007f8ae8e4a210 nid=120 waiting on condition ?[0x00007f8abd1f0000] ? ?java.lang.Thread.State: TIMED_WAITING (parking) ? ? ? ? at jdk.internal.misc.Unsafe.park(java.base at 23-loom/Native Method) ? ? ? ? - parking to wait for ?<0x000000070c9f87b0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) ? ? ? ? at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 23-loom/LockSupport.java:271) ? ? ? ? at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(java.base at 23-loom/AbstractQueuedSynchronizer.java:1763) ? ? ? ? at org.eclipse.jetty.util.BlockingArrayQueue.poll(BlockingArrayQueue.java:219) ? ? ? ? at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.idleJobPoll(QueuedThreadPool.java:1139) ? ? ? ? at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1156) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "qtp1177232287-33-acceptor-0 at a9face6-SslValidatingServerConnector@45853c5{SSL, (ssl, http/1.1)}{127.0.0.1:8443}" #33 [121] prio=3 os_prio=0 cpu=65.67ms elapsed=7205.74s tid=0x00007f8ae8e4b600 nid=121 runnable ?[0x00007f8abd0ef000] ? ?java.lang.Thread.State: RUNNABLE ? ? ? ? at sun.nio.ch.Net.accept(java.base at 23-loom/Native Method) ? ? ? ? at sun.nio.ch.ServerSocketChannelImpl.implAccept(java.base at 23-loom/ServerSocketChannelImpl.java:434) ? ? ? ? at sun.nio.ch.ServerSocketChannelImpl.accept(java.base at 23-loom/ServerSocketChannelImpl.java:400) ? ? ? ? at org.eclipse.jetty.server.ServerConnector.accept(ServerConnector.java:389) ? ? ? ? at org.eclipse.jetty.server.AbstractConnector$Acceptor.run(AbstractConnector.java:698) ? ? ? ? at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:979) ? ? ? ? at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.doRunJob(QueuedThreadPool.java:1209) ? ? ? ? at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1164) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "qtp1177232287-34" #34 [122] prio=5 os_prio=0 cpu=1090.79ms elapsed=7205.73s tid=0x00007f8ae8e4c6e0 nid=122 runnable ?[0x00007f8abcfee000] ? ?java.lang.Thread.State: RUNNABLE ? ? ? ? at sun.nio.ch.EPoll.wait(java.base at 23-loom/Native Method) ? ? ? ? at sun.nio.ch.EPollSelectorImpl.doSelect(java.base at 23-loom/EPollSelectorImpl.java:123) ? ? ? ? at sun.nio.ch.SelectorImpl.lockAndDoSelect(java.base at 23-loom/SelectorImpl.java:130) ? ? ? ? - locked <0x0000000718a7f598> (a sun.nio.ch.Util$2) ? ? ? ? - locked <0x0000000718a7f548> (a sun.nio.ch.EPollSelectorImpl) ? ? ? ? at sun.nio.ch.SelectorImpl.select(java.base at 23-loom/SelectorImpl.java:147) ? ? ? ? at org.eclipse.jetty.io.ManagedSelector.nioSelect(ManagedSelector.java:181) ? ? ? ? at org.eclipse.jetty.io.ManagedSelector.select(ManagedSelector.java:188) ? ? ? ? at org.eclipse.jetty.io.ManagedSelector$SelectorProducer.select(ManagedSelector.java:612) ? ? ? ? at org.eclipse.jetty.io.ManagedSelector$SelectorProducer.produce(ManagedSelector.java:546) ? ? ? ? at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.produceTask(AdaptiveExecutionStrategy.java:512) ? ? ? ? at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.tryProduce(AdaptiveExecutionStrategy.java:258) ? ? ? ? at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.run(AdaptiveExecutionStrategy.java:201) ? ? ? ? at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:311) ? ? ? ? at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:979) ? ? ? ? at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.doRunJob(QueuedThreadPool.java:1209) ? ? ? ? at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1164) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "qtp1177232287-35" #35 [123] prio=5 os_prio=0 cpu=1134.61ms elapsed=7205.73s tid=0x00007f8ae8e4d930 nid=123 runnable ?[0x00007f8abceed000] ? ?java.lang.Thread.State: RUNNABLE ? ? ? ? at sun.nio.ch.EPoll.wait(java.base at 23-loom/Native Method) ? ? ? ? at sun.nio.ch.EPollSelectorImpl.doSelect(java.base at 23-loom/EPollSelectorImpl.java:123) ? ? ? ? at sun.nio.ch.SelectorImpl.lockAndDoSelect(java.base at 23-loom/SelectorImpl.java:130) ? ? ? ? - locked <0x0000000718acdca8> (a sun.nio.ch.Util$2) ? ? ? ? - locked <0x0000000718acdc58> (a sun.nio.ch.EPollSelectorImpl) ? ? ? ? at sun.nio.ch.SelectorImpl.select(java.base at 23-loom/SelectorImpl.java:147) ? ? ? ? at org.eclipse.jetty.io.ManagedSelector.nioSelect(ManagedSelector.java:181) ? ? ? ? at org.eclipse.jetty.io.ManagedSelector.select(ManagedSelector.java:188) ? ? ? ? at org.eclipse.jetty.io.ManagedSelector$SelectorProducer.select(ManagedSelector.java:612) ? ? ? ? at org.eclipse.jetty.io.ManagedSelector$SelectorProducer.produce(ManagedSelector.java:546) ? ? ? ? at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.produceTask(AdaptiveExecutionStrategy.java:512) ? ? ? ? at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.tryProduce(AdaptiveExecutionStrategy.java:258) ? ? ? ? at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.run(AdaptiveExecutionStrategy.java:201) ? ? ? ? at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:311) ? ? ? ? at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:979) ? ? ? ? at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.doRunJob(QueuedThreadPool.java:1209) ? ? ? ? at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1164) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "qtp1177232287-36" #36 [124] prio=5 os_prio=0 cpu=120.94ms elapsed=7205.73s tid=0x00007f8ae8e4eb90 nid=124 waiting on condition ?[0x00007f8abcdec000] ? ?java.lang.Thread.State: TIMED_WAITING (parking) ? ? ? ? at jdk.internal.misc.Unsafe.park(java.base at 23-loom/Native Method) ? ? ? ? - parking to wait for ?<0x000000070c9f87b0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) ? ? ? ? at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 23-loom/LockSupport.java:271) ? ? ? ? at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(java.base at 23-loom/AbstractQueuedSynchronizer.java:1763) ? ? ? ? at org.eclipse.jetty.util.BlockingArrayQueue.poll(BlockingArrayQueue.java:219) ? ? ? ? at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.idleJobPoll(QueuedThreadPool.java:1139) ? ? ? ? at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1156) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "qtp1177232287-37" #37 [125] prio=5 os_prio=0 cpu=118.36ms elapsed=7205.73s tid=0x00007f8ae8e501e0 nid=125 waiting on condition ?[0x00007f8abcceb000] ? ?java.lang.Thread.State: TIMED_WAITING (parking) ? ? ? ? at jdk.internal.misc.Unsafe.park(java.base at 23-loom/Native Method) ? ? ? ? - parking to wait for ?<0x000000070c9f87b0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) ? ? ? ? at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 23-loom/LockSupport.java:271) ? ? ? ? at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(java.base at 23-loom/AbstractQueuedSynchronizer.java:1763) ? ? ? ? at org.eclipse.jetty.util.BlockingArrayQueue.poll(BlockingArrayQueue.java:219) ? ? ? ? at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.idleJobPoll(QueuedThreadPool.java:1139) ? ? ? ? at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1156) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "qtp1177232287-38" #38 [126] prio=5 os_prio=0 cpu=1108.90ms elapsed=7205.73s tid=0x00007f8ae8e51840 nid=126 waiting on condition ?[0x00007f8abcbea000] ? ?java.lang.Thread.State: TIMED_WAITING (parking) ? ? ? ? at jdk.internal.misc.Unsafe.park(java.base at 23-loom/Native Method) ? ? ? ? - parking to wait for ?<0x000000071c747140> (a java.util.concurrent.Semaphore$NonfairSync) ? ? ? ? at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 23-loom/LockSupport.java:271) ? ? ? ? at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(java.base at 23-loom/AbstractQueuedSynchronizer.java:756) ? ? ? ? at java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(java.base at 23-loom/AbstractQueuedSynchronizer.java:1126) ? ? ? ? at java.util.concurrent.Semaphore.tryAcquire(java.base at 23-loom/Semaphore.java:415) ? ? ? ? at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.waitForTask(ReservedThreadExecutor.java:351) ? ? ? ? at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:290) ? ? ? ? at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:979) ? ? ? ? at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.doRunJob(QueuedThreadPool.java:1209) ? ? ? ? at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1164) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "Scheduler-54977996-1" #39 [127] prio=5 os_prio=0 cpu=15.19ms elapsed=7205.19s tid=0x00007f8ae9d8ae70 nid=127 waiting on condition ?[0x00007f8abcae9000] ? ?java.lang.Thread.State: TIMED_WAITING (parking) ? ? ? ? at jdk.internal.misc.Unsafe.park(java.base at 23-loom/Native Method) ? ? ? ? - parking to wait for ?<0x000000070e8eef68> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) ? ? ? ? at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 23-loom/LockSupport.java:271) ? ? ? ? at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(java.base at 23-loom/AbstractQueuedSynchronizer.java:1763) ? ? ? ? at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(java.base at 23-loom/ScheduledThreadPoolExecutor.java:1182) ? ? ? ? at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(java.base at 23-loom/ScheduledThreadPoolExecutor.java:899) ? ? ? ? at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 23-loom/ThreadPoolExecutor.java:1070) ? ? ? ? at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 23-loom/ThreadPoolExecutor.java:1130) ? ? ? ? at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 23-loom/ThreadPoolExecutor.java:642) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "metrics-all-1-thread-1" #41 [128] daemon prio=5 os_prio=0 cpu=5.68ms elapsed=7205.03s tid=0x00007f8ae9de3900 nid=128 waiting on condition ?[0x00007f8abc9e8000] ? ?java.lang.Thread.State: TIMED_WAITING (parking) ? ? ? ? at jdk.internal.misc.Unsafe.park(java.base at 23-loom/Native Method) ? ? ? ? - parking to wait for ?<0x000000070ebc0960> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) ? ? ? ? at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 23-loom/LockSupport.java:271) ? ? ? ? at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(java.base at 23-loom/AbstractQueuedSynchronizer.java:1763) ? ? ? ? at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(java.base at 23-loom/ScheduledThreadPoolExecutor.java:1182) ? ? ? ? at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(java.base at 23-loom/ScheduledThreadPoolExecutor.java:899) ? ? ? ? at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 23-loom/ThreadPoolExecutor.java:1070) ? ? ? ? at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 23-loom/ThreadPoolExecutor.java:1130) ? ? ? ? at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 23-loom/ThreadPoolExecutor.java:642) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "metrics-mgmt-server-2-thread-1" #42 [129] daemon prio=5 os_prio=0 cpu=0.83ms elapsed=7205.03s tid=0x00007f8ae9de9850 nid=129 waiting on condition ?[0x00007f8abc8e7000] ? ?java.lang.Thread.State: TIMED_WAITING (parking) ? ? ? ? at jdk.internal.misc.Unsafe.park(java.base at 23-loom/Native Method) ? ? ? ? - parking to wait for ?<0x000000070ebc0ac0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) ? ? ? ? at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 23-loom/LockSupport.java:271) ? ? ? ? at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(java.base at 23-loom/AbstractQueuedSynchronizer.java:1763) ? ? ? ? at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(java.base at 23-loom/ScheduledThreadPoolExecutor.java:1182) ? ? ? ? at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(java.base at 23-loom/ScheduledThreadPoolExecutor.java:899) ? ? ? ? at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 23-loom/ThreadPoolExecutor.java:1070) ? ? ? ? at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 23-loom/ThreadPoolExecutor.java:1130) ? ? ? ? at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 23-loom/ThreadPoolExecutor.java:642) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "VirtualThread-unblocker" #43 [130] daemon prio=5 os_prio=0 cpu=35724.74ms elapsed=7204.80s tid=0x00007f8ae9ee9380 nid=130 runnable ?[0x00007f8abc7e6000] ? ?java.lang.Thread.State: RUNNABLE ? ? ? ? at java.lang.VirtualThread.takeVirtualThreadListToUnblock(java.base at 23-loom/Native Method) ? ? ? ? at java.lang.VirtualThread.unblockVirtualThreads(java.base at 23-loom/VirtualThread.java:1552) ? ? ? ? at java.lang.VirtualThread$$Lambda/0x00007f8a6f563bd0.run(java.base at 23-loom/Unknown Source) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) ? ? ? ? at jdk.internal.misc.InnocuousThread.run(java.base at 23-loom/InnocuousThread.java:186) "ForkJoinPool-1-worker-1" #45 [131] daemon prio=5 os_prio=0 cpu=499706.88ms elapsed=7204.80s tid=0x00007f8ae9eeb1a0 ?[0x00007f8abc6e5000] ? ?Carrying virtual thread #45 ? ? ? ? at jdk.internal.vm.Continuation.run(java.base at 23-loom/Continuation.java:265) ? ? ? ? - parking to wait for ?<0x000000070ebc1318> (a java.util.concurrent.locks.ReentrantLock$NonfairSync) ? ? ? ? at java.lang.VirtualThread.runContinuation(java.base at 23-loom/VirtualThread.java:283) ? ? ? ? at java.lang.VirtualThread$$Lambda/0x00007f8a6f5644d8.run(java.base at 23-loom/Unknown Source) ? ? ? ? at java.util.concurrent.ForkJoinTask$RunnableExecuteAction.compute(java.base at 23-loom/ForkJoinTask.java:1726) ? ? ? ? at java.util.concurrent.ForkJoinTask$RunnableExecuteAction.compute(java.base at 23-loom/ForkJoinTask.java:1717) ? ? ? ? at java.util.concurrent.ForkJoinTask$InterruptibleTask.exec(java.base at 23-loom/ForkJoinTask.java:1641) ? ? ? ? at java.util.concurrent.ForkJoinTask.doExec(java.base at 23-loom/ForkJoinTask.java:507) ? ? ? ? at java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(java.base at 23-loom/ForkJoinPool.java:1455) ? ? ? ? at java.util.concurrent.ForkJoinPool.runWorker(java.base at 23-loom/ForkJoinPool.java:2031) ? ? ? ? at java.util.concurrent.ForkJoinWorkerThread.run(java.base at 23-loom/ForkJoinWorkerThread.java:189) "VirtualThread-unparker" #46 [132] daemon prio=5 os_prio=0 cpu=30433.11ms elapsed=7204.80s tid=0x00007f8a14001e30 nid=132 waiting on condition ?[0x00007f8abc5e4000] ? ?java.lang.Thread.State: TIMED_WAITING (parking) ? ? ? ? at jdk.internal.misc.Unsafe.park(java.base at 23-loom/Native Method) ? ? ? ? - parking to wait for ?<0x000000070ebc1068> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) ? ? ? ? at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 23-loom/LockSupport.java:271) ? ? ? ? at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(java.base at 23-loom/AbstractQueuedSynchronizer.java:1763) ? ? ? ? at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(java.base at 23-loom/ScheduledThreadPoolExecutor.java:1182) ? ? ? ? at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(java.base at 23-loom/ScheduledThreadPoolExecutor.java:899) ? ? ? ? at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 23-loom/ThreadPoolExecutor.java:1070) ? ? ? ? at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 23-loom/ThreadPoolExecutor.java:1130) ? ? ? ? at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 23-loom/ThreadPoolExecutor.java:642) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) ? ? ? ? at jdk.internal.misc.InnocuousThread.run(java.base at 23-loom/InnocuousThread.java:186) "Connection evictor" #47 [133] daemon prio=5 os_prio=0 cpu=13.79ms elapsed=7202.86s tid=0x00007f8aea452cd0 nid=133 waiting on condition ?[0x00007f8abc4e3000] ? ?java.lang.Thread.State: TIMED_WAITING (sleeping) ? ? ? ? at java.lang.Thread.sleepNanos0(java.base at 23-loom/Native Method) ? ? ? ? at java.lang.Thread.sleepNanos(java.base at 23-loom/Thread.java:502) ? ? ? ? at java.lang.Thread.sleep(java.base at 23-loom/Thread.java:533) ? ? ? ? at org.apache.http.impl.client.IdleConnectionEvictor$1.run(IdleConnectionEvictor.java:66) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "idle-connection-evictor-1" #48 [134] daemon prio=5 os_prio=0 cpu=187.64ms elapsed=7202.50s tid=0x00007f8aea4ac620 nid=134 waiting on condition ?[0x00007f8abc3e2000] ? ?java.lang.Thread.State: TIMED_WAITING (sleeping) ? ? ? ? at java.lang.Thread.sleepNanos0(java.base at 23-loom/Native Method) ? ? ? ? at java.lang.Thread.sleepNanos(java.base at 23-loom/Thread.java:502) ? ? ? ? at java.lang.Thread.sleep(java.base at 23-loom/Thread.java:570) ? ? ? ? at java.util.concurrent.TimeUnit.sleep(java.base at 23-loom/TimeUnit.java:446) ? ? ? ? at org.apache.hc.core5.util.TimeValue.sleep(TimeValue.java:382) ? ? ? ? at org.apache.hc.client5.http.impl.IdleConnectionEvictor.lambda$new$0(IdleConnectionEvictor.java:60) ? ? ? ? at org.apache.hc.client5.http.impl.IdleConnectionEvictor$$Lambda/0x00007f8a6f79e1c0.run(Unknown Source) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "idle-connection-evictor-1" #50 [135] daemon prio=5 os_prio=0 cpu=10.64ms elapsed=7202.26s tid=0x00007f8aea5a4300 nid=135 waiting on condition ?[0x00007f8abc2e1000] ? ?java.lang.Thread.State: TIMED_WAITING (sleeping) ? ? ? ? at java.lang.Thread.sleepNanos0(java.base at 23-loom/Native Method) ? ? ? ? at java.lang.Thread.sleepNanos(java.base at 23-loom/Thread.java:502) ? ? ? ? at java.lang.Thread.sleep(java.base at 23-loom/Thread.java:570) ? ? ? ? at java.util.concurrent.TimeUnit.sleep(java.base at 23-loom/TimeUnit.java:446) ? ? ? ? at org.apache.hc.core5.util.TimeValue.sleep(TimeValue.java:382) ? ? ? ? at org.apache.hc.client5.http.impl.IdleConnectionEvictor.lambda$new$0(IdleConnectionEvictor.java:60) ? ? ? ? at org.apache.hc.client5.http.impl.IdleConnectionEvictor$$Lambda/0x00007f8a6f79e1c0.run(Unknown Source) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "Connection evictor" #51 [136] daemon prio=5 os_prio=0 cpu=66.04ms elapsed=7201.50s tid=0x00007f8aea694690 nid=136 waiting on condition ?[0x00007f8abc1e0000] ? ?java.lang.Thread.State: TIMED_WAITING (sleeping) ? ? ? ? at java.lang.Thread.sleepNanos0(java.base at 23-loom/Native Method) ? ? ? ? at java.lang.Thread.sleepNanos(java.base at 23-loom/Thread.java:502) ? ? ? ? at java.lang.Thread.sleep(java.base at 23-loom/Thread.java:533) ? ? ? ? at org.apache.http.impl.client.IdleConnectionEvictor$1.run(IdleConnectionEvictor.java:66) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "Connection evictor" #53 [137] daemon prio=5 os_prio=0 cpu=14.66ms elapsed=7201.29s tid=0x00007f8aea6b8660 nid=137 waiting on condition ?[0x00007f8aafffe000] ? ?java.lang.Thread.State: TIMED_WAITING (sleeping) ? ? ? ? at java.lang.Thread.sleepNanos0(java.base at 23-loom/Native Method) ? ? ? ? at java.lang.Thread.sleepNanos(java.base at 23-loom/Thread.java:502) ? ? ? ? at java.lang.Thread.sleep(java.base at 23-loom/Thread.java:533) ? ? ? ? at org.apache.http.impl.client.IdleConnectionEvictor$1.run(IdleConnectionEvictor.java:66) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "idle-connection-evictor-1" #55 [138] daemon prio=5 os_prio=0 cpu=142.95ms elapsed=7201.12s tid=0x00007f8aea6ec910 nid=138 waiting on condition ?[0x00007f8aafefd000] ? ?java.lang.Thread.State: TIMED_WAITING (sleeping) ? ? ? ? at java.lang.Thread.sleepNanos0(java.base at 23-loom/Native Method) ? ? ? ? at java.lang.Thread.sleepNanos(java.base at 23-loom/Thread.java:502) ? ? ? ? at java.lang.Thread.sleep(java.base at 23-loom/Thread.java:570) ? ? ? ? at java.util.concurrent.TimeUnit.sleep(java.base at 23-loom/TimeUnit.java:446) ? ? ? ? at org.apache.hc.core5.util.TimeValue.sleep(TimeValue.java:382) ? ? ? ? at org.apache.hc.client5.http.impl.IdleConnectionEvictor.lambda$new$0(IdleConnectionEvictor.java:60) ? ? ? ? at org.apache.hc.client5.http.impl.IdleConnectionEvictor$$Lambda/0x00007f8a6f79e1c0.run(Unknown Source) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "ForkJoinPool-1-worker-2" #59 [139] daemon prio=5 os_prio=0 cpu=499435.12ms elapsed=7200.94s tid=0x00007f8aea16d9e0 ?[0x00007f8aafdfc000] ? ?Carrying virtual thread #59 ? ? ? ? at jdk.internal.vm.Continuation.run(java.base at 23-loom/Continuation.java:262) ? ? ? ? - parking to wait for ?<0x000000070ebc1318> (a java.util.concurrent.locks.ReentrantLock$NonfairSync) ? ? ? ? at java.lang.VirtualThread.runContinuation(java.base at 23-loom/VirtualThread.java:283) ? ? ? ? at java.lang.VirtualThread$$Lambda/0x00007f8a6f5644d8.run(java.base at 23-loom/Unknown Source) ? ? ? ? at java.util.concurrent.ForkJoinTask$RunnableExecuteAction.compute(java.base at 23-loom/ForkJoinTask.java:1726) ? ? ? ? at java.util.concurrent.ForkJoinTask$RunnableExecuteAction.compute(java.base at 23-loom/ForkJoinTask.java:1717) ? ? ? ? at java.util.concurrent.ForkJoinTask$InterruptibleTask.exec(java.base at 23-loom/ForkJoinTask.java:1641) ? ? ? ? at java.util.concurrent.ForkJoinTask.doExec(java.base at 23-loom/ForkJoinTask.java:507) ? ? ? ? at java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(java.base at 23-loom/ForkJoinPool.java:1455) ? ? ? ? at java.util.concurrent.ForkJoinPool.runWorker(java.base at 23-loom/ForkJoinPool.java:2031) ? ? ? ? at java.util.concurrent.ForkJoinWorkerThread.run(java.base at 23-loom/ForkJoinWorkerThread.java:189) "MasterPoller" #60 [140] daemon prio=5 os_prio=0 cpu=132373.30ms elapsed=7200.94s tid=0x00007f8a14006730 nid=140 runnable ?[0x00007f8aafcfb000] ? ?java.lang.Thread.State: RUNNABLE ? ? ? ? at sun.nio.ch.EPoll.wait(java.base at 23-loom/Native Method) ? ? ? ? at sun.nio.ch.EPollPoller.poll(java.base at 23-loom/EPollPoller.java:74) ? ? ? ? at sun.nio.ch.Poller.pollerLoop(java.base at 23-loom/Poller.java:237) ? ? ? ? at sun.nio.ch.Poller$Pollers$$Lambda/0x00007f8a6f7557c0.run(java.base at 23-loom/Unknown Source) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) ? ? ? ? at jdk.internal.misc.InnocuousThread.run(java.base at 23-loom/InnocuousThread.java:186) "idle-connection-evictor-1" #61 [141] daemon prio=5 os_prio=0 cpu=139.52ms elapsed=7200.93s tid=0x00007f8aea16f010 nid=141 waiting on condition ?[0x00007f8aafbfa000] ? ?java.lang.Thread.State: TIMED_WAITING (sleeping) ? ? ? ? at java.lang.Thread.sleepNanos0(java.base at 23-loom/Native Method) ? ? ? ? at java.lang.Thread.sleepNanos(java.base at 23-loom/Thread.java:502) ? ? ? ? at java.lang.Thread.sleep(java.base at 23-loom/Thread.java:570) ? ? ? ? at java.util.concurrent.TimeUnit.sleep(java.base at 23-loom/TimeUnit.java:446) ? ? ? ? at org.apache.hc.core5.util.TimeValue.sleep(TimeValue.java:382) ? ? ? ? at org.apache.hc.client5.http.impl.IdleConnectionEvictor.lambda$new$0(IdleConnectionEvictor.java:60) ? ? ? ? at org.apache.hc.client5.http.impl.IdleConnectionEvictor$$Lambda/0x00007f8a6f79e1c0.run(Unknown Source) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "ForkJoinPool-1-worker-3" #62 [142] daemon prio=5 os_prio=0 cpu=498772.41ms elapsed=7200.93s tid=0x00007f8a34003bd0 ?[0x00007f8aafaf9000] ? ?Carrying virtual thread #62 ? ? ? ? at jdk.internal.vm.Continuation.run(java.base at 23-loom/Continuation.java:262) ? ? ? ? - parking to wait for ?<0x000000070ebc1318> (a java.util.concurrent.locks.ReentrantLock$NonfairSync) ? ? ? ? at java.lang.VirtualThread.runContinuation(java.base at 23-loom/VirtualThread.java:283) ? ? ? ? at java.lang.VirtualThread$$Lambda/0x00007f8a6f5644d8.run(java.base at 23-loom/Unknown Source) ? ? ? ? at java.util.concurrent.ForkJoinTask$RunnableExecuteAction.compute(java.base at 23-loom/ForkJoinTask.java:1726) ? ? ? ? at java.util.concurrent.ForkJoinTask$RunnableExecuteAction.compute(java.base at 23-loom/ForkJoinTask.java:1717) ? ? ? ? at java.util.concurrent.ForkJoinTask$InterruptibleTask.exec(java.base at 23-loom/ForkJoinTask.java:1641) ? ? ? ? at java.util.concurrent.ForkJoinTask.doExec(java.base at 23-loom/ForkJoinTask.java:507) ? ? ? ? at java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(java.base at 23-loom/ForkJoinPool.java:1455) ? ? ? ? at java.util.concurrent.ForkJoinPool.runWorker(java.base at 23-loom/ForkJoinPool.java:2031) ? ? ? ? at java.util.concurrent.ForkJoinWorkerThread.run(java.base at 23-loom/ForkJoinWorkerThread.java:189) "ForkJoinPool-1-worker-4" #64 [143] daemon prio=5 os_prio=0 cpu=560333.85ms elapsed=7200.93s tid=0x00007f8a14010070 nid=143 waiting on condition ?[0x00007f8aaf9f8000] ? ?java.lang.Thread.State: WAITING (parking) ? ? ? ? at jdk.internal.misc.Unsafe.park(java.base at 23-loom/Native Method) ? ? ? ? - parking to wait for ?<0x000000070ebc1318> (a java.util.concurrent.locks.ReentrantLock$NonfairSync) ? ? ? ? at java.util.concurrent.locks.LockSupport.park(java.base at 23-loom/LockSupport.java:223) ? ? ? ? at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(java.base at 23-loom/AbstractQueuedSynchronizer.java:754) ? ? ? ? at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(java.base at 23-loom/AbstractQueuedSynchronizer.java:990) ? ? ? ? at java.util.concurrent.locks.ReentrantLock$Sync.lock(java.base at 23-loom/ReentrantLock.java:154) ? ? ? ? at java.util.concurrent.locks.ReentrantLock.lock(java.base at 23-loom/ReentrantLock.java:323) ? ? ? ? at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.offer(java.base at 23-loom/ScheduledThreadPoolExecutor.java:1100) ? ? ? ? at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.add(java.base at 23-loom/ScheduledThreadPoolExecutor.java:1127) ? ? ? ? at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.add(java.base at 23-loom/ScheduledThreadPoolExecutor.java:899) ? ? ? ? at java.util.concurrent.ScheduledThreadPoolExecutor.delayedExecute(java.base at 23-loom/ScheduledThreadPoolExecutor.java:342) ? ? ? ? at java.util.concurrent.ScheduledThreadPoolExecutor.schedule(java.base at 23-loom/ScheduledThreadPoolExecutor.java:562) ? ? ? ? at java.lang.VirtualThread.schedule(java.base at 23-loom/VirtualThread.java:1513) ? ? ? ? at java.lang.VirtualThread.afterYield(java.base at 23-loom/VirtualThread.java:574) ? ? ? ? at java.lang.VirtualThread.runContinuation(java.base at 23-loom/VirtualThread.java:289) ? ? ? ? at java.lang.VirtualThread$$Lambda/0x00007f8a6f5644d8.run(java.base at 23-loom/Unknown Source) ? ? ? ? at java.util.concurrent.ForkJoinTask$RunnableExecuteAction.compute(java.base at 23-loom/ForkJoinTask.java:1726) ? ? ? ? at java.util.concurrent.ForkJoinTask$RunnableExecuteAction.compute(java.base at 23-loom/ForkJoinTask.java:1717) ? ? ? ? at java.util.concurrent.ForkJoinTask$InterruptibleTask.exec(java.base at 23-loom/ForkJoinTask.java:1641) ? ? ? ? at java.util.concurrent.ForkJoinTask.doExec(java.base at 23-loom/ForkJoinTask.java:507) ? ? ? ? at java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(java.base at 23-loom/ForkJoinPool.java:1455) ? ? ? ? at java.util.concurrent.ForkJoinPool.runWorker(java.base at 23-loom/ForkJoinPool.java:2031) ? ? ? ? at java.util.concurrent.ForkJoinWorkerThread.run(java.base at 23-loom/ForkJoinWorkerThread.java:189) "idle-connection-evictor-1" #75 [147] daemon prio=5 os_prio=0 cpu=126.38ms elapsed=7200.83s tid=0x00007f8aea169b20 nid=147 waiting on condition ?[0x00007f8aaf5f4000] ? ?java.lang.Thread.State: TIMED_WAITING (sleeping) ? ? ? ? at java.lang.Thread.sleepNanos0(java.base at 23-loom/Native Method) ? ? ? ? at java.lang.Thread.sleepNanos(java.base at 23-loom/Thread.java:502) ? ? ? ? at java.lang.Thread.sleep(java.base at 23-loom/Thread.java:570) ? ? ? ? at java.util.concurrent.TimeUnit.sleep(java.base at 23-loom/TimeUnit.java:446) ? ? ? ? at org.apache.hc.core5.util.TimeValue.sleep(TimeValue.java:382) ? ? ? ? at org.apache.hc.client5.http.impl.IdleConnectionEvictor.lambda$new$0(IdleConnectionEvictor.java:60) ? ? ? ? at org.apache.hc.client5.http.impl.IdleConnectionEvictor$$Lambda/0x00007f8a6f79e1c0.run(Unknown Source) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "idle-connection-evictor-1" #79 [148] daemon prio=5 os_prio=0 cpu=152.82ms elapsed=7200.69s tid=0x00007f8aea701af0 nid=148 waiting on condition ?[0x00007f8aaf4f3000] ? ?java.lang.Thread.State: TIMED_WAITING (sleeping) ? ? ? ? at java.lang.Thread.sleepNanos0(java.base at 23-loom/Native Method) ? ? ? ? at java.lang.Thread.sleepNanos(java.base at 23-loom/Thread.java:502) ? ? ? ? at java.lang.Thread.sleep(java.base at 23-loom/Thread.java:570) ? ? ? ? at java.util.concurrent.TimeUnit.sleep(java.base at 23-loom/TimeUnit.java:446) ? ? ? ? at org.apache.hc.core5.util.TimeValue.sleep(TimeValue.java:382) ? ? ? ? at org.apache.hc.client5.http.impl.IdleConnectionEvictor.lambda$new$0(IdleConnectionEvictor.java:60) ? ? ? ? at org.apache.hc.client5.http.impl.IdleConnectionEvictor$$Lambda/0x00007f8a6f79e1c0.run(Unknown Source) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "idle-connection-evictor-1" #85 [149] daemon prio=5 os_prio=0 cpu=133.55ms elapsed=7200.52s tid=0x00007f8ae9bc4f30 nid=149 waiting on condition ?[0x00007f8aaf3f2000] ? ?java.lang.Thread.State: TIMED_WAITING (sleeping) ? ? ? ? at java.lang.Thread.sleepNanos0(java.base at 23-loom/Native Method) ? ? ? ? at java.lang.Thread.sleepNanos(java.base at 23-loom/Thread.java:502) ? ? ? ? at java.lang.Thread.sleep(java.base at 23-loom/Thread.java:570) ? ? ? ? at java.util.concurrent.TimeUnit.sleep(java.base at 23-loom/TimeUnit.java:446) ? ? ? ? at org.apache.hc.core5.util.TimeValue.sleep(TimeValue.java:382) ? ? ? ? at org.apache.hc.client5.http.impl.IdleConnectionEvictor.lambda$new$0(IdleConnectionEvictor.java:60) ? ? ? ? at org.apache.hc.client5.http.impl.IdleConnectionEvictor$$Lambda/0x00007f8a6f79e1c0.run(Unknown Source) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "idle-connection-evictor-1" #591 [150] daemon prio=5 os_prio=0 cpu=126.43ms elapsed=7200.42s tid=0x00007f8aea1687d0 nid=150 waiting on condition ?[0x00007f8aaf2f1000] ? ?java.lang.Thread.State: TIMED_WAITING (sleeping) ? ? ? ? at java.lang.Thread.sleepNanos0(java.base at 23-loom/Native Method) ? ? ? ? at java.lang.Thread.sleepNanos(java.base at 23-loom/Thread.java:502) ? ? ? ? at java.lang.Thread.sleep(java.base at 23-loom/Thread.java:570) ? ? ? ? at java.util.concurrent.TimeUnit.sleep(java.base at 23-loom/TimeUnit.java:446) ? ? ? ? at org.apache.hc.core5.util.TimeValue.sleep(TimeValue.java:382) ? ? ? ? at org.apache.hc.client5.http.impl.IdleConnectionEvictor.lambda$new$0(IdleConnectionEvictor.java:60) ? ? ? ? at org.apache.hc.client5.http.impl.IdleConnectionEvictor$$Lambda/0x00007f8a6f79e1c0.run(Unknown Source) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "idle-connection-evictor-1" #1098 [151] daemon prio=5 os_prio=0 cpu=139.06ms elapsed=7200.28s tid=0x00007f8ae9bcb470 nid=151 waiting on condition ?[0x00007f8aaf1f0000] ? ?java.lang.Thread.State: TIMED_WAITING (sleeping) ? ? ? ? at java.lang.Thread.sleepNanos0(java.base at 23-loom/Native Method) ? ? ? ? at java.lang.Thread.sleepNanos(java.base at 23-loom/Thread.java:502) ? ? ? ? at java.lang.Thread.sleep(java.base at 23-loom/Thread.java:570) ? ? ? ? at java.util.concurrent.TimeUnit.sleep(java.base at 23-loom/TimeUnit.java:446) ? ? ? ? at org.apache.hc.core5.util.TimeValue.sleep(TimeValue.java:382) ? ? ? ? at org.apache.hc.client5.http.impl.IdleConnectionEvictor.lambda$new$0(IdleConnectionEvictor.java:60) ? ? ? ? at org.apache.hc.client5.http.impl.IdleConnectionEvictor$$Lambda/0x00007f8a6f79e1c0.run(Unknown Source) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "idle-connection-evictor-1" #1105 [152] daemon prio=5 os_prio=0 cpu=126.38ms elapsed=7200.15s tid=0x00007f8ae9bc9160 nid=152 waiting on condition ?[0x00007f8a69ffe000] ? ?java.lang.Thread.State: TIMED_WAITING (sleeping) ? ? ? ? at java.lang.Thread.sleepNanos0(java.base at 23-loom/Native Method) ? ? ? ? at java.lang.Thread.sleepNanos(java.base at 23-loom/Thread.java:502) ? ? ? ? at java.lang.Thread.sleep(java.base at 23-loom/Thread.java:570) ? ? ? ? at java.util.concurrent.TimeUnit.sleep(java.base at 23-loom/TimeUnit.java:446) ? ? ? ? at org.apache.hc.core5.util.TimeValue.sleep(TimeValue.java:382) ? ? ? ? at org.apache.hc.client5.http.impl.IdleConnectionEvictor.lambda$new$0(IdleConnectionEvictor.java:60) ? ? ? ? at org.apache.hc.client5.http.impl.IdleConnectionEvictor$$Lambda/0x00007f8a6f79e1c0.run(Unknown Source) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "idle-connection-evictor-1" #1111 [153] daemon prio=5 os_prio=0 cpu=137.13ms elapsed=7200.02s tid=0x00007f8ae9bca410 nid=153 waiting on condition ?[0x00007f8a69efd000] ? ?java.lang.Thread.State: TIMED_WAITING (sleeping) ? ? ? ? at java.lang.Thread.sleepNanos0(java.base at 23-loom/Native Method) ? ? ? ? at java.lang.Thread.sleepNanos(java.base at 23-loom/Thread.java:502) ? ? ? ? at java.lang.Thread.sleep(java.base at 23-loom/Thread.java:570) ? ? ? ? at java.util.concurrent.TimeUnit.sleep(java.base at 23-loom/TimeUnit.java:446) ? ? ? ? at org.apache.hc.core5.util.TimeValue.sleep(TimeValue.java:382) ? ? ? ? at org.apache.hc.client5.http.impl.IdleConnectionEvictor.lambda$new$0(IdleConnectionEvictor.java:60) ? ? ? ? at org.apache.hc.client5.http.impl.IdleConnectionEvictor$$Lambda/0x00007f8a6f79e1c0.run(Unknown Source) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "idle-connection-evictor-1" #1126 [154] daemon prio=5 os_prio=0 cpu=144.63ms elapsed=7199.77s tid=0x00007f8aea035940 nid=154 waiting on condition ?[0x00007f8a69dfc000] ? ?java.lang.Thread.State: TIMED_WAITING (sleeping) ? ? ? ? at java.lang.Thread.sleepNanos0(java.base at 23-loom/Native Method) ? ? ? ? at java.lang.Thread.sleepNanos(java.base at 23-loom/Thread.java:502) ? ? ? ? at java.lang.Thread.sleep(java.base at 23-loom/Thread.java:570) ? ? ? ? at java.util.concurrent.TimeUnit.sleep(java.base at 23-loom/TimeUnit.java:446) ? ? ? ? at org.apache.hc.core5.util.TimeValue.sleep(TimeValue.java:382) ? ? ? ? at org.apache.hc.client5.http.impl.IdleConnectionEvictor.lambda$new$0(IdleConnectionEvictor.java:60) ? ? ? ? at org.apache.hc.client5.http.impl.IdleConnectionEvictor$$Lambda/0x00007f8a6f79e1c0.run(Unknown Source) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "idle-connection-evictor-1" #1131 [155] daemon prio=5 os_prio=0 cpu=149.78ms elapsed=7199.65s tid=0x00007f8ae9bc7320 nid=155 waiting on condition ?[0x00007f8a69cfb000] ? ?java.lang.Thread.State: TIMED_WAITING (sleeping) ? ? ? ? at java.lang.Thread.sleepNanos0(java.base at 23-loom/Native Method) ? ? ? ? at java.lang.Thread.sleepNanos(java.base at 23-loom/Thread.java:502) ? ? ? ? at java.lang.Thread.sleep(java.base at 23-loom/Thread.java:570) ? ? ? ? at java.util.concurrent.TimeUnit.sleep(java.base at 23-loom/TimeUnit.java:446) ? ? ? ? at org.apache.hc.core5.util.TimeValue.sleep(TimeValue.java:382) ? ? ? ? at org.apache.hc.client5.http.impl.IdleConnectionEvictor.lambda$new$0(IdleConnectionEvictor.java:60) ? ? ? ? at org.apache.hc.client5.http.impl.IdleConnectionEvictor$$Lambda/0x00007f8a6f79e1c0.run(Unknown Source) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "idle-connection-evictor-1" #1139 [156] daemon prio=5 os_prio=0 cpu=145.59ms elapsed=7199.53s tid=0x00007f8ae9bc7a60 nid=156 waiting on condition ?[0x00007f8a69bfa000] ? ?java.lang.Thread.State: TIMED_WAITING (sleeping) ? ? ? ? at java.lang.Thread.sleepNanos0(java.base at 23-loom/Native Method) ? ? ? ? at java.lang.Thread.sleepNanos(java.base at 23-loom/Thread.java:502) ? ? ? ? at java.lang.Thread.sleep(java.base at 23-loom/Thread.java:570) ? ? ? ? at java.util.concurrent.TimeUnit.sleep(java.base at 23-loom/TimeUnit.java:446) ? ? ? ? at org.apache.hc.core5.util.TimeValue.sleep(TimeValue.java:382) ? ? ? ? at org.apache.hc.client5.http.impl.IdleConnectionEvictor.lambda$new$0(IdleConnectionEvictor.java:60) ? ? ? ? at org.apache.hc.client5.http.impl.IdleConnectionEvictor$$Lambda/0x00007f8a6f79e1c0.run(Unknown Source) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "idle-connection-evictor-1" #1954 [157] daemon prio=5 os_prio=0 cpu=133.81ms elapsed=7199.34s tid=0x00007f8aea034a80 nid=157 waiting on condition ?[0x00007f8a69af9000] ? ?java.lang.Thread.State: TIMED_WAITING (sleeping) ? ? ? ? at java.lang.Thread.sleepNanos0(java.base at 23-loom/Native Method) ? ? ? ? at java.lang.Thread.sleepNanos(java.base at 23-loom/Thread.java:502) ? ? ? ? at java.lang.Thread.sleep(java.base at 23-loom/Thread.java:570) ? ? ? ? at java.util.concurrent.TimeUnit.sleep(java.base at 23-loom/TimeUnit.java:446) ? ? ? ? at org.apache.hc.core5.util.TimeValue.sleep(TimeValue.java:382) ? ? ? ? at org.apache.hc.client5.http.impl.IdleConnectionEvictor.lambda$new$0(IdleConnectionEvictor.java:60) ? ? ? ? at org.apache.hc.client5.http.impl.IdleConnectionEvictor$$Lambda/0x00007f8a6f79e1c0.run(Unknown Source) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "idle-connection-evictor-1" #3152 [158] daemon prio=5 os_prio=0 cpu=130.04ms elapsed=7199.22s tid=0x00007f8aea02e6b0 nid=158 waiting on condition ?[0x00007f8a699f8000] ? ?java.lang.Thread.State: TIMED_WAITING (sleeping) ? ? ? ? at java.lang.Thread.sleepNanos0(java.base at 23-loom/Native Method) ? ? ? ? at java.lang.Thread.sleepNanos(java.base at 23-loom/Thread.java:502) ? ? ? ? at java.lang.Thread.sleep(java.base at 23-loom/Thread.java:570) ? ? ? ? at java.util.concurrent.TimeUnit.sleep(java.base at 23-loom/TimeUnit.java:446) ? ? ? ? at org.apache.hc.core5.util.TimeValue.sleep(TimeValue.java:382) ? ? ? ? at org.apache.hc.client5.http.impl.IdleConnectionEvictor.lambda$new$0(IdleConnectionEvictor.java:60) ? ? ? ? at org.apache.hc.client5.http.impl.IdleConnectionEvictor$$Lambda/0x00007f8a6f79e1c0.run(Unknown Source) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "idle-connection-evictor-1" #4167 [159] daemon prio=5 os_prio=0 cpu=132.04ms elapsed=7199.01s tid=0x00007f8aea032fa0 nid=159 waiting on condition ?[0x00007f8a698f7000] ? ?java.lang.Thread.State: TIMED_WAITING (sleeping) ? ? ? ? at java.lang.Thread.sleepNanos0(java.base at 23-loom/Native Method) ? ? ? ? at java.lang.Thread.sleepNanos(java.base at 23-loom/Thread.java:502) ? ? ? ? at java.lang.Thread.sleep(java.base at 23-loom/Thread.java:570) ? ? ? ? at java.util.concurrent.TimeUnit.sleep(java.base at 23-loom/TimeUnit.java:446) ? ? ? ? at org.apache.hc.core5.util.TimeValue.sleep(TimeValue.java:382) ? ? ? ? at org.apache.hc.client5.http.impl.IdleConnectionEvictor.lambda$new$0(IdleConnectionEvictor.java:60) ? ? ? ? at org.apache.hc.client5.http.impl.IdleConnectionEvictor$$Lambda/0x00007f8a6f79e1c0.run(Unknown Source) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "idle-connection-evictor-1" #4679 [160] daemon prio=5 os_prio=0 cpu=127.45ms elapsed=7198.82s tid=0x00007f8aea1b86f0 nid=160 waiting on condition ?[0x00007f8a697f6000] ? ?java.lang.Thread.State: TIMED_WAITING (sleeping) ? ? ? ? at java.lang.Thread.sleepNanos0(java.base at 23-loom/Native Method) ? ? ? ? at java.lang.Thread.sleepNanos(java.base at 23-loom/Thread.java:502) ? ? ? ? at java.lang.Thread.sleep(java.base at 23-loom/Thread.java:570) ? ? ? ? at java.util.concurrent.TimeUnit.sleep(java.base at 23-loom/TimeUnit.java:446) ? ? ? ? at org.apache.hc.core5.util.TimeValue.sleep(TimeValue.java:382) ? ? ? ? at org.apache.hc.client5.http.impl.IdleConnectionEvictor.lambda$new$0(IdleConnectionEvictor.java:60) ? ? ? ? at org.apache.hc.client5.http.impl.IdleConnectionEvictor$$Lambda/0x00007f8a6f79e1c0.run(Unknown Source) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "idle-connection-evictor-1" #6201 [161] daemon prio=5 os_prio=0 cpu=125.04ms elapsed=7198.58s tid=0x00007f8aea1bda50 nid=161 waiting on condition ?[0x00007f8a696f5000] ? ?java.lang.Thread.State: TIMED_WAITING (sleeping) ? ? ? ? at java.lang.Thread.sleepNanos0(java.base at 23-loom/Native Method) ? ? ? ? at java.lang.Thread.sleepNanos(java.base at 23-loom/Thread.java:502) ? ? ? ? at java.lang.Thread.sleep(java.base at 23-loom/Thread.java:570) ? ? ? ? at java.util.concurrent.TimeUnit.sleep(java.base at 23-loom/TimeUnit.java:446) ? ? ? ? at org.apache.hc.core5.util.TimeValue.sleep(TimeValue.java:382) ? ? ? ? at org.apache.hc.client5.http.impl.IdleConnectionEvictor.lambda$new$0(IdleConnectionEvictor.java:60) ? ? ? ? at org.apache.hc.client5.http.impl.IdleConnectionEvictor$$Lambda/0x00007f8a6f79e1c0.run(Unknown Source) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "idle-connection-evictor-1" #7716 [162] daemon prio=5 os_prio=0 cpu=122.34ms elapsed=7198.41s tid=0x00007f8aea1bee00 nid=162 waiting on condition ?[0x00007f8a695f4000] ? ?java.lang.Thread.State: TIMED_WAITING (sleeping) ? ? ? ? at java.lang.Thread.sleepNanos0(java.base at 23-loom/Native Method) ? ? ? ? at java.lang.Thread.sleepNanos(java.base at 23-loom/Thread.java:502) ? ? ? ? at java.lang.Thread.sleep(java.base at 23-loom/Thread.java:570) ? ? ? ? at java.util.concurrent.TimeUnit.sleep(java.base at 23-loom/TimeUnit.java:446) ? ? ? ? at org.apache.hc.core5.util.TimeValue.sleep(TimeValue.java:382) ? ? ? ? at org.apache.hc.client5.http.impl.IdleConnectionEvictor.lambda$new$0(IdleConnectionEvictor.java:60) ? ? ? ? at org.apache.hc.client5.http.impl.IdleConnectionEvictor$$Lambda/0x00007f8a6f79e1c0.run(Unknown Source) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "idle-connection-evictor-1" #7727 [163] daemon prio=5 os_prio=0 cpu=125.97ms elapsed=7198.32s tid=0x00007f8aea1b7380 nid=163 waiting on condition ?[0x00007f8a694f3000] ? ?java.lang.Thread.State: TIMED_WAITING (sleeping) ? ? ? ? at java.lang.Thread.sleepNanos0(java.base at 23-loom/Native Method) ? ? ? ? at java.lang.Thread.sleepNanos(java.base at 23-loom/Thread.java:502) ? ? ? ? at java.lang.Thread.sleep(java.base at 23-loom/Thread.java:570) ? ? ? ? at java.util.concurrent.TimeUnit.sleep(java.base at 23-loom/TimeUnit.java:446) ? ? ? ? at org.apache.hc.core5.util.TimeValue.sleep(TimeValue.java:382) ? ? ? ? at org.apache.hc.client5.http.impl.IdleConnectionEvictor.lambda$new$0(IdleConnectionEvictor.java:60) ? ? ? ? at org.apache.hc.client5.http.impl.IdleConnectionEvictor$$Lambda/0x00007f8a6f79e1c0.run(Unknown Source) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "idle-connection-evictor-1" #8745 [164] daemon prio=5 os_prio=0 cpu=134.23ms elapsed=7198.07s tid=0x00007f8aea1c09f0 nid=164 waiting on condition ?[0x00007f8a693f2000] ? ?java.lang.Thread.State: TIMED_WAITING (sleeping) ? ? ? ? at java.lang.Thread.sleepNanos0(java.base at 23-loom/Native Method) ? ? ? ? at java.lang.Thread.sleepNanos(java.base at 23-loom/Thread.java:502) ? ? ? ? at java.lang.Thread.sleep(java.base at 23-loom/Thread.java:570) ? ? ? ? at java.util.concurrent.TimeUnit.sleep(java.base at 23-loom/TimeUnit.java:446) ? ? ? ? at org.apache.hc.core5.util.TimeValue.sleep(TimeValue.java:382) ? ? ? ? at org.apache.hc.client5.http.impl.IdleConnectionEvictor.lambda$new$0(IdleConnectionEvictor.java:60) ? ? ? ? at org.apache.hc.client5.http.impl.IdleConnectionEvictor$$Lambda/0x00007f8a6f79e1c0.run(Unknown Source) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "idle-connection-evictor-1" #9254 [165] daemon prio=5 os_prio=0 cpu=128.22ms elapsed=7197.93s tid=0x00007f8aea1c1d00 nid=165 waiting on condition ?[0x00007f8a692f1000] ? ?java.lang.Thread.State: TIMED_WAITING (sleeping) ? ? ? ? at java.lang.Thread.sleepNanos0(java.base at 23-loom/Native Method) ? ? ? ? at java.lang.Thread.sleepNanos(java.base at 23-loom/Thread.java:502) ? ? ? ? at java.lang.Thread.sleep(java.base at 23-loom/Thread.java:570) ? ? ? ? at java.util.concurrent.TimeUnit.sleep(java.base at 23-loom/TimeUnit.java:446) ? ? ? ? at org.apache.hc.core5.util.TimeValue.sleep(TimeValue.java:382) ? ? ? ? at org.apache.hc.client5.http.impl.IdleConnectionEvictor.lambda$new$0(IdleConnectionEvictor.java:60) ? ? ? ? at org.apache.hc.client5.http.impl.IdleConnectionEvictor$$Lambda/0x00007f8a6f79e1c0.run(Unknown Source) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "idle-connection-evictor-1" #9772 [166] daemon prio=5 os_prio=0 cpu=128.44ms elapsed=7197.79s tid=0x00007f8aea1c6920 nid=166 waiting on condition ?[0x00007f8a691f0000] ? ?java.lang.Thread.State: TIMED_WAITING (sleeping) ? ? ? ? at java.lang.Thread.sleepNanos0(java.base at 23-loom/Native Method) ? ? ? ? at java.lang.Thread.sleepNanos(java.base at 23-loom/Thread.java:502) ? ? ? ? at java.lang.Thread.sleep(java.base at 23-loom/Thread.java:570) ? ? ? ? at java.util.concurrent.TimeUnit.sleep(java.base at 23-loom/TimeUnit.java:446) ? ? ? ? at org.apache.hc.core5.util.TimeValue.sleep(TimeValue.java:382) ? ? ? ? at org.apache.hc.client5.http.impl.IdleConnectionEvictor.lambda$new$0(IdleConnectionEvictor.java:60) ? ? ? ? at org.apache.hc.client5.http.impl.IdleConnectionEvictor$$Lambda/0x00007f8a6f79e1c0.run(Unknown Source) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "idle-connection-evictor-1" #10289 [167] daemon prio=5 os_prio=0 cpu=120.05ms elapsed=7197.62s tid=0x00007f8aea1c7d30 nid=167 waiting on condition ?[0x00007f8a690ef000] ? ?java.lang.Thread.State: TIMED_WAITING (sleeping) ? ? ? ? at java.lang.Thread.sleepNanos0(java.base at 23-loom/Native Method) ? ? ? ? at java.lang.Thread.sleepNanos(java.base at 23-loom/Thread.java:502) ? ? ? ? at java.lang.Thread.sleep(java.base at 23-loom/Thread.java:570) ? ? ? ? at java.util.concurrent.TimeUnit.sleep(java.base at 23-loom/TimeUnit.java:446) ? ? ? ? at org.apache.hc.core5.util.TimeValue.sleep(TimeValue.java:382) ? ? ? ? at org.apache.hc.client5.http.impl.IdleConnectionEvictor.lambda$new$0(IdleConnectionEvictor.java:60) ? ? ? ? at org.apache.hc.client5.http.impl.IdleConnectionEvictor$$Lambda/0x00007f8a6f79e1c0.run(Unknown Source) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "idle-connection-evictor-1" #10809 [174] daemon prio=5 os_prio=0 cpu=126.36ms elapsed=7197.43s tid=0x00007f8aea1c8ee0 nid=174 waiting on condition ?[0x00007f8a68fee000] ? ?java.lang.Thread.State: TIMED_WAITING (sleeping) ? ? ? ? at java.lang.Thread.sleepNanos0(java.base at 23-loom/Native Method) ? ? ? ? at java.lang.Thread.sleepNanos(java.base at 23-loom/Thread.java:502) ? ? ? ? at java.lang.Thread.sleep(java.base at 23-loom/Thread.java:570) ? ? ? ? at java.util.concurrent.TimeUnit.sleep(java.base at 23-loom/TimeUnit.java:446) ? ? ? ? at org.apache.hc.core5.util.TimeValue.sleep(TimeValue.java:382) ? ? ? ? at org.apache.hc.client5.http.impl.IdleConnectionEvictor.lambda$new$0(IdleConnectionEvictor.java:60) ? ? ? ? at org.apache.hc.client5.http.impl.IdleConnectionEvictor$$Lambda/0x00007f8a6f79e1c0.run(Unknown Source) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "idle-connection-evictor-1" #11321 [176] daemon prio=5 os_prio=0 cpu=119.13ms elapsed=7197.32s tid=0x00007f8aea1ca090 nid=176 waiting on condition ?[0x00007f8a68eed000] ? ?java.lang.Thread.State: TIMED_WAITING (sleeping) ? ? ? ? at java.lang.Thread.sleepNanos0(java.base at 23-loom/Native Method) ? ? ? ? at java.lang.Thread.sleepNanos(java.base at 23-loom/Thread.java:502) ? ? ? ? at java.lang.Thread.sleep(java.base at 23-loom/Thread.java:570) ? ? ? ? at java.util.concurrent.TimeUnit.sleep(java.base at 23-loom/TimeUnit.java:446) ? ? ? ? at org.apache.hc.core5.util.TimeValue.sleep(TimeValue.java:382) ? ? ? ? at org.apache.hc.client5.http.impl.IdleConnectionEvictor.lambda$new$0(IdleConnectionEvictor.java:60) ? ? ? ? at org.apache.hc.client5.http.impl.IdleConnectionEvictor$$Lambda/0x00007f8a6f79e1c0.run(Unknown Source) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "idle-connection-evictor-1" #11841 [177] daemon prio=5 os_prio=0 cpu=125.45ms elapsed=7197.17s tid=0x00007f8aea1d74a0 nid=177 waiting on condition ?[0x00007f8a68dec000] ? ?java.lang.Thread.State: TIMED_WAITING (sleeping) ? ? ? ? at java.lang.Thread.sleepNanos0(java.base at 23-loom/Native Method) ? ? ? ? at java.lang.Thread.sleepNanos(java.base at 23-loom/Thread.java:502) ? ? ? ? at java.lang.Thread.sleep(java.base at 23-loom/Thread.java:570) ? ? ? ? at java.util.concurrent.TimeUnit.sleep(java.base at 23-loom/TimeUnit.java:446) ? ? ? ? at org.apache.hc.core5.util.TimeValue.sleep(TimeValue.java:382) ? ? ? ? at org.apache.hc.client5.http.impl.IdleConnectionEvictor.lambda$new$0(IdleConnectionEvictor.java:60) ? ? ? ? at org.apache.hc.client5.http.impl.IdleConnectionEvictor$$Lambda/0x00007f8a6f79e1c0.run(Unknown Source) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "idle-connection-evictor-1" #12360 [178] daemon prio=5 os_prio=0 cpu=132.14ms elapsed=7197.02s tid=0x00007f8aea27b2f0 nid=178 waiting on condition ?[0x00007f8a68ceb000] ? ?java.lang.Thread.State: TIMED_WAITING (sleeping) ? ? ? ? at java.lang.Thread.sleepNanos0(java.base at 23-loom/Native Method) ? ? ? ? at java.lang.Thread.sleepNanos(java.base at 23-loom/Thread.java:502) ? ? ? ? at java.lang.Thread.sleep(java.base at 23-loom/Thread.java:570) ? ? ? ? at java.util.concurrent.TimeUnit.sleep(java.base at 23-loom/TimeUnit.java:446) ? ? ? ? at org.apache.hc.core5.util.TimeValue.sleep(TimeValue.java:382) ? ? ? ? at org.apache.hc.client5.http.impl.IdleConnectionEvictor.lambda$new$0(IdleConnectionEvictor.java:60) ? ? ? ? at org.apache.hc.client5.http.impl.IdleConnectionEvictor$$Lambda/0x00007f8a6f79e1c0.run(Unknown Source) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "idle-connection-evictor-1" #12868 [179] daemon prio=5 os_prio=0 cpu=123.00ms elapsed=7196.91s tid=0x00007f8aea27bfb0 nid=179 waiting on condition ?[0x00007f8a68bea000] ? ?java.lang.Thread.State: TIMED_WAITING (sleeping) ? ? ? ? at java.lang.Thread.sleepNanos0(java.base at 23-loom/Native Method) ? ? ? ? at java.lang.Thread.sleepNanos(java.base at 23-loom/Thread.java:502) ? ? ? ? at java.lang.Thread.sleep(java.base at 23-loom/Thread.java:570) ? ? ? ? at java.util.concurrent.TimeUnit.sleep(java.base at 23-loom/TimeUnit.java:446) ? ? ? ? at org.apache.hc.core5.util.TimeValue.sleep(TimeValue.java:382) ? ? ? ? at org.apache.hc.client5.http.impl.IdleConnectionEvictor.lambda$new$0(IdleConnectionEvictor.java:60) ? ? ? ? at org.apache.hc.client5.http.impl.IdleConnectionEvictor$$Lambda/0x00007f8a6f79e1c0.run(Unknown Source) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "idle-connection-evictor-1" #13884 [180] daemon prio=5 os_prio=0 cpu=126.88ms elapsed=7196.77s tid=0x00007f8aea27d260 nid=180 waiting on condition ?[0x00007f8a68ae9000] ? ?java.lang.Thread.State: TIMED_WAITING (sleeping) ? ? ? ? at java.lang.Thread.sleepNanos0(java.base at 23-loom/Native Method) ? ? ? ? at java.lang.Thread.sleepNanos(java.base at 23-loom/Thread.java:502) ? ? ? ? at java.lang.Thread.sleep(java.base at 23-loom/Thread.java:570) ? ? ? ? at java.util.concurrent.TimeUnit.sleep(java.base at 23-loom/TimeUnit.java:446) ? ? ? ? at org.apache.hc.core5.util.TimeValue.sleep(TimeValue.java:382) ? ? ? ? at org.apache.hc.client5.http.impl.IdleConnectionEvictor.lambda$new$0(IdleConnectionEvictor.java:60) ? ? ? ? at org.apache.hc.client5.http.impl.IdleConnectionEvictor$$Lambda/0x00007f8a6f79e1c0.run(Unknown Source) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "idle-connection-evictor-1" #13897 [181] daemon prio=5 os_prio=0 cpu=134.02ms elapsed=7196.63s tid=0x00007f8aea1c31d0 nid=181 waiting on condition ?[0x00007f8a689e8000] ? ?java.lang.Thread.State: TIMED_WAITING (sleeping) ? ? ? ? at java.lang.Thread.sleepNanos0(java.base at 23-loom/Native Method) ? ? ? ? at java.lang.Thread.sleepNanos(java.base at 23-loom/Thread.java:502) ? ? ? ? at java.lang.Thread.sleep(java.base at 23-loom/Thread.java:570) ? ? ? ? at java.util.concurrent.TimeUnit.sleep(java.base at 23-loom/TimeUnit.java:446) ? ? ? ? at org.apache.hc.core5.util.TimeValue.sleep(TimeValue.java:382) ? ? ? ? at org.apache.hc.client5.http.impl.IdleConnectionEvictor.lambda$new$0(IdleConnectionEvictor.java:60) ? ? ? ? at org.apache.hc.client5.http.impl.IdleConnectionEvictor$$Lambda/0x00007f8a6f79e1c0.run(Unknown Source) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "pool-8-thread-1" #14406 [182] prio=5 os_prio=0 cpu=2665.65ms elapsed=7196.52s tid=0x00007f8aea1c4ad0 nid=182 waiting on condition ?[0x00007f8a688e7000] ? ?java.lang.Thread.State: TIMED_WAITING (parking) ? ? ? ? at jdk.internal.misc.Unsafe.park(java.base at 23-loom/Native Method) ? ? ? ? - parking to wait for ?<0x000000070d700230> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) ? ? ? ? at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 23-loom/LockSupport.java:271) ? ? ? ? at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(java.base at 23-loom/AbstractQueuedSynchronizer.java:1763) ? ? ? ? at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(java.base at 23-loom/ScheduledThreadPoolExecutor.java:1182) ? ? ? ? at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(java.base at 23-loom/ScheduledThreadPoolExecutor.java:899) ? ? ? ? at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 23-loom/ThreadPoolExecutor.java:1070) ? ? ? ? at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 23-loom/ThreadPoolExecutor.java:1130) ? ? ? ? at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 23-loom/ThreadPoolExecutor.java:642) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "idle-connection-evictor-1" #15423 [183] daemon prio=5 os_prio=0 cpu=10.38ms elapsed=7196.34s tid=0x00007f8aea286350 nid=183 waiting on condition ?[0x00007f8a687e6000] ? ?java.lang.Thread.State: TIMED_WAITING (sleeping) ? ? ? ? at java.lang.Thread.sleepNanos0(java.base at 23-loom/Native Method) ? ? ? ? at java.lang.Thread.sleepNanos(java.base at 23-loom/Thread.java:502) ? ? ? ? at java.lang.Thread.sleep(java.base at 23-loom/Thread.java:570) ? ? ? ? at java.util.concurrent.TimeUnit.sleep(java.base at 23-loom/TimeUnit.java:446) ? ? ? ? at org.apache.hc.core5.util.TimeValue.sleep(TimeValue.java:382) ? ? ? ? at org.apache.hc.client5.http.impl.IdleConnectionEvictor.lambda$new$0(IdleConnectionEvictor.java:60) ? ? ? ? at org.apache.hc.client5.http.impl.IdleConnectionEvictor$$Lambda/0x00007f8a6f79e1c0.run(Unknown Source) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "Connection evictor" #15444 [184] daemon prio=5 os_prio=0 cpu=10.98ms elapsed=7195.88s tid=0x00007f8aea1fd190 nid=184 waiting on condition ?[0x00007f8a686e5000] ? ?java.lang.Thread.State: TIMED_WAITING (sleeping) ? ? ? ? at java.lang.Thread.sleepNanos0(java.base at 23-loom/Native Method) ? ? ? ? at java.lang.Thread.sleepNanos(java.base at 23-loom/Thread.java:502) ? ? ? ? at java.lang.Thread.sleep(java.base at 23-loom/Thread.java:533) ? ? ? ? at org.apache.http.impl.client.IdleConnectionEvictor$1.run(IdleConnectionEvictor.java:66) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "Connection evictor" #15453 [185] daemon prio=5 os_prio=0 cpu=10.95ms elapsed=7195.81s tid=0x00007f8aea198930 nid=185 waiting on condition ?[0x00007f8a685e4000] ? ?java.lang.Thread.State: TIMED_WAITING (sleeping) ? ? ? ? at java.lang.Thread.sleepNanos0(java.base at 23-loom/Native Method) ? ? ? ? at java.lang.Thread.sleepNanos(java.base at 23-loom/Thread.java:502) ? ? ? ? at java.lang.Thread.sleep(java.base at 23-loom/Thread.java:533) ? ? ? ? at org.apache.http.impl.client.IdleConnectionEvictor$1.run(IdleConnectionEvictor.java:66) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "Connection evictor" #15491 [186] daemon prio=5 os_prio=0 cpu=11.38ms elapsed=7194.96s tid=0x00007f8ae9ba9970 nid=186 waiting on condition ?[0x00007f8a684e3000] ? ?java.lang.Thread.State: TIMED_WAITING (sleeping) ? ? ? ? at java.lang.Thread.sleepNanos0(java.base at 23-loom/Native Method) ? ? ? ? at java.lang.Thread.sleepNanos(java.base at 23-loom/Thread.java:502) ? ? ? ? at java.lang.Thread.sleep(java.base at 23-loom/Thread.java:533) ? ? ? ? at org.apache.http.impl.client.IdleConnectionEvictor$1.run(IdleConnectionEvictor.java:66) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "idle-connection-evictor-1" #15493 [187] daemon prio=5 os_prio=0 cpu=10.26ms elapsed=7194.88s tid=0x00007f8aea0aaa80 nid=187 waiting on condition ?[0x00007f8a683e2000] ? ?java.lang.Thread.State: TIMED_WAITING (sleeping) ? ? ? ? at java.lang.Thread.sleepNanos0(java.base at 23-loom/Native Method) ? ? ? ? at java.lang.Thread.sleepNanos(java.base at 23-loom/Thread.java:502) ? ? ? ? at java.lang.Thread.sleep(java.base at 23-loom/Thread.java:570) ? ? ? ? at java.util.concurrent.TimeUnit.sleep(java.base at 23-loom/TimeUnit.java:446) ? ? ? ? at org.apache.hc.core5.util.TimeValue.sleep(TimeValue.java:382) ? ? ? ? at org.apache.hc.client5.http.impl.IdleConnectionEvictor.lambda$new$0(IdleConnectionEvictor.java:60) ? ? ? ? at org.apache.hc.client5.http.impl.IdleConnectionEvictor$$Lambda/0x00007f8a6f79e1c0.run(Unknown Source) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "Connection evictor" #15508 [188] daemon prio=5 os_prio=0 cpu=11.75ms elapsed=7194.57s tid=0x00007f8ae9c57860 nid=188 waiting on condition ?[0x00007f8a682e1000] ? ?java.lang.Thread.State: TIMED_WAITING (sleeping) ? ? ? ? at java.lang.Thread.sleepNanos0(java.base at 23-loom/Native Method) ? ? ? ? at java.lang.Thread.sleepNanos(java.base at 23-loom/Thread.java:502) ? ? ? ? at java.lang.Thread.sleep(java.base at 23-loom/Thread.java:533) ? ? ? ? at org.apache.http.impl.client.IdleConnectionEvictor$1.run(IdleConnectionEvictor.java:66) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "Connection evictor" #15516 [189] daemon prio=5 os_prio=0 cpu=11.73ms elapsed=7194.48s tid=0x00007f8aea0289b0 nid=189 waiting on condition ?[0x00007f8a681e0000] ? ?java.lang.Thread.State: TIMED_WAITING (sleeping) ? ? ? ? at java.lang.Thread.sleepNanos0(java.base at 23-loom/Native Method) ? ? ? ? at java.lang.Thread.sleepNanos(java.base at 23-loom/Thread.java:502) ? ? ? ? at java.lang.Thread.sleep(java.base at 23-loom/Thread.java:533) ? ? ? ? at org.apache.http.impl.client.IdleConnectionEvictor$1.run(IdleConnectionEvictor.java:66) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "idle-connection-evictor-1" #15519 [190] daemon prio=5 os_prio=0 cpu=10.36ms elapsed=7194.41s tid=0x00007f8ae9c11170 nid=190 waiting on condition ?[0x00007f8a0bffe000] ? ?java.lang.Thread.State: TIMED_WAITING (sleeping) ? ? ? ? at java.lang.Thread.sleepNanos0(java.base at 23-loom/Native Method) ? ? ? ? at java.lang.Thread.sleepNanos(java.base at 23-loom/Thread.java:502) ? ? ? ? at java.lang.Thread.sleep(java.base at 23-loom/Thread.java:570) ? ? ? ? at java.util.concurrent.TimeUnit.sleep(java.base at 23-loom/TimeUnit.java:446) ? ? ? ? at org.apache.hc.core5.util.TimeValue.sleep(TimeValue.java:382) ? ? ? ? at org.apache.hc.client5.http.impl.IdleConnectionEvictor.lambda$new$0(IdleConnectionEvictor.java:60) ? ? ? ? at org.apache.hc.client5.http.impl.IdleConnectionEvictor$$Lambda/0x00007f8a6f79e1c0.run(Unknown Source) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "pool-77-thread-1" #15529 [191] prio=5 os_prio=0 cpu=3768.73ms elapsed=7194.19s tid=0x00007f8aea788830 nid=191 waiting on condition ?[0x00007f8a0befd000] ? ?java.lang.Thread.State: TIMED_WAITING (parking) ? ? ? ? at jdk.internal.misc.Unsafe.park(java.base at 23-loom/Native Method) ? ? ? ? - parking to wait for ?<0x000000070f400148> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) ? ? ? ? at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 23-loom/LockSupport.java:271) ? ? ? ? at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(java.base at 23-loom/AbstractQueuedSynchronizer.java:1763) ? ? ? ? at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(java.base at 23-loom/ScheduledThreadPoolExecutor.java:1182) ? ? ? ? at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(java.base at 23-loom/ScheduledThreadPoolExecutor.java:899) ? ? ? ? at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 23-loom/ThreadPoolExecutor.java:1070) ? ? ? ? at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 23-loom/ThreadPoolExecutor.java:1130) ? ? ? ? at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 23-loom/ThreadPoolExecutor.java:642) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "Connection evictor" #15530 [192] daemon prio=5 os_prio=0 cpu=11.62ms elapsed=7194.16s tid=0x00007f8ae9cc6b40 nid=192 waiting on condition ?[0x00007f8a0bdfc000] ? ?java.lang.Thread.State: TIMED_WAITING (sleeping) ? ? ? ? at java.lang.Thread.sleepNanos0(java.base at 23-loom/Native Method) ? ? ? ? at java.lang.Thread.sleepNanos(java.base at 23-loom/Thread.java:502) ? ? ? ? at java.lang.Thread.sleep(java.base at 23-loom/Thread.java:533) ? ? ? ? at org.apache.http.impl.client.IdleConnectionEvictor$1.run(IdleConnectionEvictor.java:66) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "Connection evictor" #15533 [193] daemon prio=5 os_prio=0 cpu=9.98ms elapsed=7194.13s tid=0x00007f8ae9cc8590 nid=193 waiting on condition ?[0x00007f8a0bcfb000] ? ?java.lang.Thread.State: TIMED_WAITING (sleeping) ? ? ? ? at java.lang.Thread.sleepNanos0(java.base at 23-loom/Native Method) ? ? ? ? at java.lang.Thread.sleepNanos(java.base at 23-loom/Thread.java:502) ? ? ? ? at java.lang.Thread.sleep(java.base at 23-loom/Thread.java:533) ? ? ? ? at org.apache.http.impl.client.IdleConnectionEvictor$1.run(IdleConnectionEvictor.java:66) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "pool-78-thread-1" #15588 [194] prio=5 os_prio=0 cpu=0.37ms elapsed=7192.99s tid=0x00007f8aea7c7a60 nid=194 waiting on condition ?[0x00007f8a0bbfa000] ? ?java.lang.Thread.State: TIMED_WAITING (parking) ? ? ? ? at jdk.internal.misc.Unsafe.park(java.base at 23-loom/Native Method) ? ? ? ? - parking to wait for ?<0x000000070f488d18> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) ? ? ? ? at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 23-loom/LockSupport.java:271) ? ? ? ? at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(java.base at 23-loom/AbstractQueuedSynchronizer.java:1763) ? ? ? ? at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(java.base at 23-loom/ScheduledThreadPoolExecutor.java:1182) ? ? ? ? at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(java.base at 23-loom/ScheduledThreadPoolExecutor.java:899) ? ? ? ? at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 23-loom/ThreadPoolExecutor.java:1070) ? ? ? ? at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 23-loom/ThreadPoolExecutor.java:1130) ? ? ? ? at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 23-loom/ThreadPoolExecutor.java:642) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "pool-79-thread-1" #15694 [195] prio=5 os_prio=0 cpu=2162.78ms elapsed=7191.38s tid=0x00007f8a44f73850 nid=195 waiting on condition ?[0x00007f8a0baf9000] ? ?java.lang.Thread.State: TIMED_WAITING (parking) ? ? ? ? at jdk.internal.misc.Unsafe.park(java.base at 23-loom/Native Method) ? ? ? ? - parking to wait for ?<0x000000070d870310> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) ? ? ? ? at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 23-loom/LockSupport.java:271) ? ? ? ? at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(java.base at 23-loom/AbstractQueuedSynchronizer.java:1763) ? ? ? ? at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(java.base at 23-loom/ScheduledThreadPoolExecutor.java:1182) ? ? ? ? at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(java.base at 23-loom/ScheduledThreadPoolExecutor.java:899) ? ? ? ? at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 23-loom/ThreadPoolExecutor.java:1070) ? ? ? ? at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 23-loom/ThreadPoolExecutor.java:1130) ? ? ? ? at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 23-loom/ThreadPoolExecutor.java:642) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "pool-80-thread-1" #15697 [196] prio=5 os_prio=0 cpu=0.65ms elapsed=7191.35s tid=0x00007f8a44f7ec60 nid=196 waiting on condition ?[0x00007f8a0b9f8000] ? ?java.lang.Thread.State: TIMED_WAITING (parking) ? ? ? ? at jdk.internal.misc.Unsafe.park(java.base at 23-loom/Native Method) ? ? ? ? - parking to wait for ?<0x000000070d8dfac8> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) ? ? ? ? at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 23-loom/LockSupport.java:271) ? ? ? ? at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(java.base at 23-loom/AbstractQueuedSynchronizer.java:1763) ? ? ? ? at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(java.base at 23-loom/ScheduledThreadPoolExecutor.java:1182) ? ? ? ? at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(java.base at 23-loom/ScheduledThreadPoolExecutor.java:899) ? ? ? ? at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 23-loom/ThreadPoolExecutor.java:1070) ? ? ? ? at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 23-loom/ThreadPoolExecutor.java:1130) ? ? ? ? at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 23-loom/ThreadPoolExecutor.java:642) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "pool-81-thread-1" #15698 [197] prio=5 os_prio=0 cpu=14858.40ms elapsed=7191.35s tid=0x00007f8a44f7fc70 nid=197 waiting on condition ?[0x00007f8a0b8f7000] ? ?java.lang.Thread.State: WAITING (parking) ? ? ? ? at jdk.internal.misc.Unsafe.park(java.base at 23-loom/Native Method) ? ? ? ? - parking to wait for ?<0x000000070cc58b50> (a java.util.concurrent.locks.ReentrantLock$NonfairSync) ? ? ? ? at java.util.concurrent.locks.LockSupport.park(java.base at 23-loom/LockSupport.java:223) ? ? ? ? at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(java.base at 23-loom/AbstractQueuedSynchronizer.java:754) ? ? ? ? at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(java.base at 23-loom/AbstractQueuedSynchronizer.java:990) ? ? ? ? at java.util.concurrent.locks.ReentrantLock$Sync.lock(java.base at 23-loom/ReentrantLock.java:154) ? ? ? ? at java.util.concurrent.locks.ReentrantLock.lock(java.base at 23-loom/ReentrantLock.java:323) ? ? ? ? at ch.qos.logback.core.OutputStreamAppender.writeBytes(OutputStreamAppender.java:200) ? ? ? ? at ch.qos.logback.core.OutputStreamAppender.writeOut(OutputStreamAppender.java:193) ? ? ? ? at ch.qos.logback.core.OutputStreamAppender.subAppend(OutputStreamAppender.java:237) ? ? ? ? at ch.qos.logback.core.OutputStreamAppender.append(OutputStreamAppender.java:102) ? ? ? ? at ch.qos.logback.core.UnsynchronizedAppenderBase.doAppend(UnsynchronizedAppenderBase.java:85) ? ? ? ? at ch.qos.logback.core.spi.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:51) ? ? ? ? at ch.qos.logback.classic.Logger.appendLoopOnAppenders(Logger.java:272) ? ? ? ? at ch.qos.logback.classic.Logger.callAppenders(Logger.java:259) ? ? ? ? at ch.qos.logback.classic.Logger.buildLoggingEventAndAppend(Logger.java:426) ? ? ? ? at ch.qos.logback.classic.Logger.filterAndLog_2(Logger.java:419) ? ? ? ? at ch.qos.logback.classic.Logger.debug(Logger.java:495) ? ? ? ? at com.securithings.stam.monitoring.scheduling.spring.VirtualThreadAgentlessTaskScheduler.lambda$getScheduledFuture$2(VirtualThreadAgentlessTaskScheduler.java:74) ? ? ? ? at com.securithings.stam.monitoring.scheduling.spring.VirtualThreadAgentlessTaskScheduler$$Lambda/0x00007f8a6f9a8420.run(Unknown Source) ? ? ? ? at java.util.concurrent.Executors$RunnableAdapter.call(java.base at 23-loom/Executors.java:572) ? ? ? ? at java.util.concurrent.FutureTask.runAndReset(java.base at 23-loom/FutureTask.java:358) ? ? ? ? at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(java.base at 23-loom/ScheduledThreadPoolExecutor.java:305) ? ? ? ? at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 23-loom/ThreadPoolExecutor.java:1144) ? ? ? ? at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 23-loom/ThreadPoolExecutor.java:642) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "pool-82-thread-1" #15699 [198] prio=5 os_prio=0 cpu=12475.61ms elapsed=7191.33s tid=0x00007f8a44f810e0 nid=198 waiting on condition ?[0x00007f8a0b7f6000] ? ?java.lang.Thread.State: WAITING (parking) ? ? ? ? at jdk.internal.misc.Unsafe.park(java.base at 23-loom/Native Method) ? ? ? ? - parking to wait for ?<0x000000070cc58b50> (a java.util.concurrent.locks.ReentrantLock$NonfairSync) ? ? ? ? at java.util.concurrent.locks.LockSupport.park(java.base at 23-loom/LockSupport.java:223) ? ? ? ? at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(java.base at 23-loom/AbstractQueuedSynchronizer.java:754) ? ? ? ? at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(java.base at 23-loom/AbstractQueuedSynchronizer.java:990) ? ? ? ? at java.util.concurrent.locks.ReentrantLock$Sync.lock(java.base at 23-loom/ReentrantLock.java:154) ? ? ? ? at java.util.concurrent.locks.ReentrantLock.lock(java.base at 23-loom/ReentrantLock.java:323) ? ? ? ? at ch.qos.logback.core.OutputStreamAppender.writeBytes(OutputStreamAppender.java:200) ? ? ? ? at ch.qos.logback.core.OutputStreamAppender.writeOut(OutputStreamAppender.java:193) ? ? ? ? at ch.qos.logback.core.OutputStreamAppender.subAppend(OutputStreamAppender.java:237) ? ? ? ? at ch.qos.logback.core.OutputStreamAppender.append(OutputStreamAppender.java:102) ? ? ? ? at ch.qos.logback.core.UnsynchronizedAppenderBase.doAppend(UnsynchronizedAppenderBase.java:85) ? ? ? ? at ch.qos.logback.core.spi.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:51) ? ? ? ? at ch.qos.logback.classic.Logger.appendLoopOnAppenders(Logger.java:272) ? ? ? ? at ch.qos.logback.classic.Logger.callAppenders(Logger.java:259) ? ? ? ? at ch.qos.logback.classic.Logger.buildLoggingEventAndAppend(Logger.java:426) ? ? ? ? at ch.qos.logback.classic.Logger.filterAndLog_2(Logger.java:419) ? ? ? ? at ch.qos.logback.classic.Logger.debug(Logger.java:495) ? ? ? ? at com.securithings.stam.monitoring.scheduling.spring.VirtualThreadAgentlessTaskScheduler.lambda$getScheduledFuture$2(VirtualThreadAgentlessTaskScheduler.java:74) ? ? ? ? at com.securithings.stam.monitoring.scheduling.spring.VirtualThreadAgentlessTaskScheduler$$Lambda/0x00007f8a6f9a8420.run(Unknown Source) ? ? ? ? at java.util.concurrent.Executors$RunnableAdapter.call(java.base at 23-loom/Executors.java:572) ? ? ? ? at java.util.concurrent.FutureTask.runAndReset(java.base at 23-loom/FutureTask.java:358) ? ? ? ? at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(java.base at 23-loom/ScheduledThreadPoolExecutor.java:305) ? ? ? ? at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 23-loom/ThreadPoolExecutor.java:1144) ? ? ? ? at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 23-loom/ThreadPoolExecutor.java:642) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "pool-83-thread-1" #15703 [199] prio=5 os_prio=0 cpu=1123.74ms elapsed=7191.31s tid=0x00007f8a44f85fb0 nid=199 waiting on condition ?[0x00007f8a0b6f5000] ? ?java.lang.Thread.State: WAITING (parking) ? ? ? ? at jdk.internal.misc.Unsafe.park(java.base at 23-loom/Native Method) ? ? ? ? - parking to wait for ?<0x000000070cc58b50> (a java.util.concurrent.locks.ReentrantLock$NonfairSync) ? ? ? ? at java.util.concurrent.locks.LockSupport.park(java.base at 23-loom/LockSupport.java:223) ? ? ? ? at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(java.base at 23-loom/AbstractQueuedSynchronizer.java:754) ? ? ? ? at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(java.base at 23-loom/AbstractQueuedSynchronizer.java:990) ? ? ? ? at java.util.concurrent.locks.ReentrantLock$Sync.lock(java.base at 23-loom/ReentrantLock.java:154) ? ? ? ? at java.util.concurrent.locks.ReentrantLock.lock(java.base at 23-loom/ReentrantLock.java:323) ? ? ? ? at ch.qos.logback.core.OutputStreamAppender.writeBytes(OutputStreamAppender.java:200) ? ? ? ? at ch.qos.logback.core.OutputStreamAppender.writeOut(OutputStreamAppender.java:193) ? ? ? ? at ch.qos.logback.core.OutputStreamAppender.subAppend(OutputStreamAppender.java:237) ? ? ? ? at ch.qos.logback.core.OutputStreamAppender.append(OutputStreamAppender.java:102) ? ? ? ? at ch.qos.logback.core.UnsynchronizedAppenderBase.doAppend(UnsynchronizedAppenderBase.java:85) ? ? ? ? at ch.qos.logback.core.spi.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:51) ? ? ? ? at ch.qos.logback.classic.Logger.appendLoopOnAppenders(Logger.java:272) ? ? ? ? at ch.qos.logback.classic.Logger.callAppenders(Logger.java:259) ? ? ? ? at ch.qos.logback.classic.Logger.buildLoggingEventAndAppend(Logger.java:426) ? ? ? ? at ch.qos.logback.classic.Logger.filterAndLog_2(Logger.java:419) ? ? ? ? at ch.qos.logback.classic.Logger.debug(Logger.java:495) ? ? ? ? at com.securithings.stam.monitoring.scheduling.spring.VirtualThreadAgentlessTaskScheduler.lambda$getScheduledFuture$2(VirtualThreadAgentlessTaskScheduler.java:74) ? ? ? ? at com.securithings.stam.monitoring.scheduling.spring.VirtualThreadAgentlessTaskScheduler$$Lambda/0x00007f8a6f9a8420.run(Unknown Source) ? ? ? ? at java.util.concurrent.Executors$RunnableAdapter.call(java.base at 23-loom/Executors.java:572) ? ? ? ? at java.util.concurrent.FutureTask.runAndReset(java.base at 23-loom/FutureTask.java:358) ? ? ? ? at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(java.base at 23-loom/ScheduledThreadPoolExecutor.java:305) ? ? ? ? at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 23-loom/ThreadPoolExecutor.java:1144) ? ? ? ? at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 23-loom/ThreadPoolExecutor.java:642) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "pool-84-thread-1" #15704 [200] prio=5 os_prio=0 cpu=30690.27ms elapsed=7191.31s tid=0x00007f8a44f87f20 nid=200 waiting on condition ?[0x00007f8a0b5f4000] ? ?java.lang.Thread.State: WAITING (parking) ? ? ? ? at jdk.internal.misc.Unsafe.park(java.base at 23-loom/Native Method) ? ? ? ? - parking to wait for ?<0x000000070cc58b50> (a java.util.concurrent.locks.ReentrantLock$NonfairSync) ? ? ? ? at java.util.concurrent.locks.LockSupport.park(java.base at 23-loom/LockSupport.java:223) ? ? ? ? at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(java.base at 23-loom/AbstractQueuedSynchronizer.java:754) ? ? ? ? at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(java.base at 23-loom/AbstractQueuedSynchronizer.java:990) ? ? ? ? at java.util.concurrent.locks.ReentrantLock$Sync.lock(java.base at 23-loom/ReentrantLock.java:154) ? ? ? ? at java.util.concurrent.locks.ReentrantLock.lock(java.base at 23-loom/ReentrantLock.java:323) ? ? ? ? at ch.qos.logback.core.OutputStreamAppender.writeBytes(OutputStreamAppender.java:200) ? ? ? ? at ch.qos.logback.core.OutputStreamAppender.writeOut(OutputStreamAppender.java:193) ? ? ? ? at ch.qos.logback.core.OutputStreamAppender.subAppend(OutputStreamAppender.java:237) ? ? ? ? at ch.qos.logback.core.OutputStreamAppender.append(OutputStreamAppender.java:102) ? ? ? ? at ch.qos.logback.core.UnsynchronizedAppenderBase.doAppend(UnsynchronizedAppenderBase.java:85) ? ? ? ? at ch.qos.logback.core.spi.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:51) ? ? ? ? at ch.qos.logback.classic.Logger.appendLoopOnAppenders(Logger.java:272) ? ? ? ? at ch.qos.logback.classic.Logger.callAppenders(Logger.java:259) ? ? ? ? at ch.qos.logback.classic.Logger.buildLoggingEventAndAppend(Logger.java:426) ? ? ? ? at ch.qos.logback.classic.Logger.filterAndLog_2(Logger.java:419) ? ? ? ? at ch.qos.logback.classic.Logger.debug(Logger.java:495) ? ? ? ? at com.securithings.stam.monitoring.scheduling.spring.VirtualThreadAgentlessTaskScheduler.lambda$getScheduledFuture$2(VirtualThreadAgentlessTaskScheduler.java:74) ? ? ? ? at com.securithings.stam.monitoring.scheduling.spring.VirtualThreadAgentlessTaskScheduler$$Lambda/0x00007f8a6f9a8420.run(Unknown Source) ? ? ? ? at java.util.concurrent.Executors$RunnableAdapter.call(java.base at 23-loom/Executors.java:572) ? ? ? ? at java.util.concurrent.FutureTask.runAndReset(java.base at 23-loom/FutureTask.java:358) ? ? ? ? at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(java.base at 23-loom/ScheduledThreadPoolExecutor.java:305) ? ? ? ? at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 23-loom/ThreadPoolExecutor.java:1144) ? ? ? ? at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 23-loom/ThreadPoolExecutor.java:642) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "idle-connection-evictor-1" #15856 [201] daemon prio=5 os_prio=0 cpu=10.40ms elapsed=7189.28s tid=0x00007f8aea7bb470 nid=201 waiting on condition ?[0x00007f8a0b4f3000] ? ?java.lang.Thread.State: TIMED_WAITING (sleeping) ? ? ? ? at java.lang.Thread.sleepNanos0(java.base at 23-loom/Native Method) ? ? ? ? at java.lang.Thread.sleepNanos(java.base at 23-loom/Thread.java:502) ? ? ? ? at java.lang.Thread.sleep(java.base at 23-loom/Thread.java:570) ? ? ? ? at java.util.concurrent.TimeUnit.sleep(java.base at 23-loom/TimeUnit.java:446) ? ? ? ? at org.apache.hc.core5.util.TimeValue.sleep(TimeValue.java:382) ? ? ? ? at org.apache.hc.client5.http.impl.IdleConnectionEvictor.lambda$new$0(IdleConnectionEvictor.java:60) ? ? ? ? at org.apache.hc.client5.http.impl.IdleConnectionEvictor$$Lambda/0x00007f8a6f79e1c0.run(Unknown Source) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "idle-connection-evictor-1" #15862 [202] daemon prio=5 os_prio=0 cpu=11.53ms elapsed=7189.20s tid=0x00007f8ae9f71e00 nid=202 waiting on condition ?[0x00007f8a0b3f2000] ? ?java.lang.Thread.State: TIMED_WAITING (sleeping) ? ? ? ? at java.lang.Thread.sleepNanos0(java.base at 23-loom/Native Method) ? ? ? ? at java.lang.Thread.sleepNanos(java.base at 23-loom/Thread.java:502) ? ? ? ? at java.lang.Thread.sleep(java.base at 23-loom/Thread.java:570) ? ? ? ? at java.util.concurrent.TimeUnit.sleep(java.base at 23-loom/TimeUnit.java:446) ? ? ? ? at org.apache.hc.core5.util.TimeValue.sleep(TimeValue.java:382) ? ? ? ? at org.apache.hc.client5.http.impl.IdleConnectionEvictor.lambda$new$0(IdleConnectionEvictor.java:60) ? ? ? ? at org.apache.hc.client5.http.impl.IdleConnectionEvictor$$Lambda/0x00007f8a6f79e1c0.run(Unknown Source) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "idle-connection-evictor-1" #15864 [203] daemon prio=5 os_prio=0 cpu=87.63ms elapsed=7189.08s tid=0x00007f8ae9f7e9a0 nid=203 waiting on condition ?[0x00007f8a0b2f1000] ? ?java.lang.Thread.State: TIMED_WAITING (sleeping) ? ? ? ? at java.lang.Thread.sleepNanos0(java.base at 23-loom/Native Method) ? ? ? ? at java.lang.Thread.sleepNanos(java.base at 23-loom/Thread.java:502) ? ? ? ? at java.lang.Thread.sleep(java.base at 23-loom/Thread.java:570) ? ? ? ? at java.util.concurrent.TimeUnit.sleep(java.base at 23-loom/TimeUnit.java:446) ? ? ? ? at org.apache.hc.core5.util.TimeValue.sleep(TimeValue.java:382) ? ? ? ? at org.apache.hc.client5.http.impl.IdleConnectionEvictor.lambda$new$0(IdleConnectionEvictor.java:60) ? ? ? ? at org.apache.hc.client5.http.impl.IdleConnectionEvictor$$Lambda/0x00007f8a6f79e1c0.run(Unknown Source) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "idle-connection-evictor-1" #15868 [204] daemon prio=5 os_prio=0 cpu=9.95ms elapsed=7189.02s tid=0x00007f8ae99e5ef0 nid=204 waiting on condition ?[0x00007f8a0b1f0000] ? ?java.lang.Thread.State: TIMED_WAITING (sleeping) ? ? ? ? at java.lang.Thread.sleepNanos0(java.base at 23-loom/Native Method) ? ? ? ? at java.lang.Thread.sleepNanos(java.base at 23-loom/Thread.java:502) ? ? ? ? at java.lang.Thread.sleep(java.base at 23-loom/Thread.java:570) ? ? ? ? at java.util.concurrent.TimeUnit.sleep(java.base at 23-loom/TimeUnit.java:446) ? ? ? ? at org.apache.hc.core5.util.TimeValue.sleep(TimeValue.java:382) ? ? ? ? at org.apache.hc.client5.http.impl.IdleConnectionEvictor.lambda$new$0(IdleConnectionEvictor.java:60) ? ? ? ? at org.apache.hc.client5.http.impl.IdleConnectionEvictor$$Lambda/0x00007f8a6f79e1c0.run(Unknown Source) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "idle-connection-evictor-1" #15871 [205] daemon prio=5 os_prio=0 cpu=9.88ms elapsed=7189.00s tid=0x00007f8aea2125f0 nid=205 waiting on condition ?[0x00007f8a0b0ef000] ? ?java.lang.Thread.State: TIMED_WAITING (sleeping) ? ? ? ? at java.lang.Thread.sleepNanos0(java.base at 23-loom/Native Method) ? ? ? ? at java.lang.Thread.sleepNanos(java.base at 23-loom/Thread.java:502) ? ? ? ? at java.lang.Thread.sleep(java.base at 23-loom/Thread.java:570) ? ? ? ? at java.util.concurrent.TimeUnit.sleep(java.base at 23-loom/TimeUnit.java:446) ? ? ? ? at org.apache.hc.core5.util.TimeValue.sleep(TimeValue.java:382) ? ? ? ? at org.apache.hc.client5.http.impl.IdleConnectionEvictor.lambda$new$0(IdleConnectionEvictor.java:60) ? ? ? ? at org.apache.hc.client5.http.impl.IdleConnectionEvictor$$Lambda/0x00007f8a6f79e1c0.run(Unknown Source) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "DefaultUDPTransportMapping_0:0:0:0:0:0:0:0/49227" #15873 [206] daemon prio=5 os_prio=0 cpu=2.72ms elapsed=7188.89s tid=0x00007f8aea91fd40 nid=206 runnable ?[0x00007f8a0afee000] ? ?java.lang.Thread.State: RUNNABLE ? ? ? ? at sun.nio.ch.DatagramChannelImpl.receive0(java.base at 23-loom/Native Method) ? ? ? ? at sun.nio.ch.DatagramChannelImpl.receiveIntoNativeBuffer(java.base at 23-loom/DatagramChannelImpl.java:815) ? ? ? ? at sun.nio.ch.DatagramChannelImpl.receive(java.base at 23-loom/DatagramChannelImpl.java:791) ? ? ? ? at sun.nio.ch.DatagramChannelImpl.tryBlockingReceive(java.base at 23-loom/DatagramChannelImpl.java:752) ? ? ? ? at sun.nio.ch.DatagramChannelImpl.blockingReceive(java.base at 23-loom/DatagramChannelImpl.java:693) ? ? ? ? at sun.nio.ch.DatagramSocketAdaptor.receive(java.base at 23-loom/DatagramSocketAdaptor.java:204) ? ? ? ? at java.net.DatagramSocket.receive(java.base at 23-loom/DatagramSocket.java:718) ? ? ? ? at org.snmp4j.transport.DefaultUdpTransportMapping$ListenThread.run(DefaultUdpTransportMapping.java:455) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "idle-connection-evictor-1" #15875 [207] daemon prio=5 os_prio=0 cpu=9.90ms elapsed=7188.86s tid=0x00007f8aea9054f0 nid=207 waiting on condition ?[0x00007f8a0aeed000] ? ?java.lang.Thread.State: TIMED_WAITING (sleeping) ? ? ? ? at java.lang.Thread.sleepNanos0(java.base at 23-loom/Native Method) ? ? ? ? at java.lang.Thread.sleepNanos(java.base at 23-loom/Thread.java:502) ? ? ? ? at java.lang.Thread.sleep(java.base at 23-loom/Thread.java:570) ? ? ? ? at java.util.concurrent.TimeUnit.sleep(java.base at 23-loom/TimeUnit.java:446) ? ? ? ? at org.apache.hc.core5.util.TimeValue.sleep(TimeValue.java:382) ? ? ? ? at org.apache.hc.client5.http.impl.IdleConnectionEvictor.lambda$new$0(IdleConnectionEvictor.java:60) ? ? ? ? at org.apache.hc.client5.http.impl.IdleConnectionEvictor$$Lambda/0x00007f8a6f79e1c0.run(Unknown Source) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "DefaultUDPTransportMapping_0:0:0:0:0:0:0:0/44601" #15878 [208] daemon prio=5 os_prio=0 cpu=0.35ms elapsed=7188.84s tid=0x00007f8aea90c330 nid=208 runnable ?[0x00007f8a0adec000] ? ?java.lang.Thread.State: RUNNABLE ? ? ? ? at sun.nio.ch.DatagramChannelImpl.receive0(java.base at 23-loom/Native Method) ? ? ? ? at sun.nio.ch.DatagramChannelImpl.receiveIntoNativeBuffer(java.base at 23-loom/DatagramChannelImpl.java:815) ? ? ? ? at sun.nio.ch.DatagramChannelImpl.receive(java.base at 23-loom/DatagramChannelImpl.java:791) ? ? ? ? at sun.nio.ch.DatagramChannelImpl.tryBlockingReceive(java.base at 23-loom/DatagramChannelImpl.java:752) ? ? ? ? at sun.nio.ch.DatagramChannelImpl.blockingReceive(java.base at 23-loom/DatagramChannelImpl.java:693) ? ? ? ? at sun.nio.ch.DatagramSocketAdaptor.receive(java.base at 23-loom/DatagramSocketAdaptor.java:204) ? ? ? ? at java.net.DatagramSocket.receive(java.base at 23-loom/DatagramSocket.java:718) ? ? ? ? at org.snmp4j.transport.DefaultUdpTransportMapping$ListenThread.run(DefaultUdpTransportMapping.java:455) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "DefaultUDPTransportMapping_0:0:0:0:0:0:0:0/60465" #15879 [209] daemon prio=5 os_prio=0 cpu=0.36ms elapsed=7188.82s tid=0x00007f8aea92a660 nid=209 runnable ?[0x00007f8a0aceb000] ? ?java.lang.Thread.State: RUNNABLE ? ? ? ? at sun.nio.ch.DatagramChannelImpl.receive0(java.base at 23-loom/Native Method) ? ? ? ? at sun.nio.ch.DatagramChannelImpl.receiveIntoNativeBuffer(java.base at 23-loom/DatagramChannelImpl.java:815) ? ? ? ? at sun.nio.ch.DatagramChannelImpl.receive(java.base at 23-loom/DatagramChannelImpl.java:791) ? ? ? ? at sun.nio.ch.DatagramChannelImpl.tryBlockingReceive(java.base at 23-loom/DatagramChannelImpl.java:752) ? ? ? ? at sun.nio.ch.DatagramChannelImpl.blockingReceive(java.base at 23-loom/DatagramChannelImpl.java:693) ? ? ? ? at sun.nio.ch.DatagramSocketAdaptor.receive(java.base at 23-loom/DatagramSocketAdaptor.java:204) ? ? ? ? at java.net.DatagramSocket.receive(java.base at 23-loom/DatagramSocket.java:718) ? ? ? ? at org.snmp4j.transport.DefaultUdpTransportMapping$ListenThread.run(DefaultUdpTransportMapping.java:455) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "Connection evictor" #15881 [210] daemon prio=5 os_prio=0 cpu=10.52ms elapsed=7188.81s tid=0x00007f8aea92c900 nid=210 waiting on condition ?[0x00007f8a0abea000] ? ?java.lang.Thread.State: TIMED_WAITING (sleeping) ? ? ? ? at java.lang.Thread.sleepNanos0(java.base at 23-loom/Native Method) ? ? ? ? at java.lang.Thread.sleepNanos(java.base at 23-loom/Thread.java:502) ? ? ? ? at java.lang.Thread.sleep(java.base at 23-loom/Thread.java:533) ? ? ? ? at org.apache.http.impl.client.IdleConnectionEvictor$1.run(IdleConnectionEvictor.java:66) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "pool-87-thread-1" #15883 [211] prio=5 os_prio=0 cpu=61.67ms elapsed=7188.79s tid=0x00007f8aea92ed40 nid=211 waiting on condition ?[0x00007f8a0aae9000] ? ?java.lang.Thread.State: TIMED_WAITING (parking) ? ? ? ? at jdk.internal.misc.Unsafe.park(java.base at 23-loom/Native Method) ? ? ? ? - parking to wait for ?<0x0000000718400360> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) ? ? ? ? at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 23-loom/LockSupport.java:271) ? ? ? ? at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(java.base at 23-loom/AbstractQueuedSynchronizer.java:1763) ? ? ? ? at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(java.base at 23-loom/ScheduledThreadPoolExecutor.java:1182) ? ? ? ? at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(java.base at 23-loom/ScheduledThreadPoolExecutor.java:899) ? ? ? ? at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 23-loom/ThreadPoolExecutor.java:1070) ? ? ? ? at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 23-loom/ThreadPoolExecutor.java:1130) ? ? ? ? at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 23-loom/ThreadPoolExecutor.java:642) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "pool-87-thread-2" #15884 [212] prio=5 os_prio=0 cpu=45.62ms elapsed=7188.79s tid=0x00007f8aea930870 nid=212 waiting on condition ?[0x00007f8a0a9e8000] ? ?java.lang.Thread.State: WAITING (parking) ? ? ? ? at jdk.internal.misc.Unsafe.park(java.base at 23-loom/Native Method) ? ? ? ? - parking to wait for ?<0x0000000718400360> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) ? ? ? ? at java.util.concurrent.locks.LockSupport.park(java.base at 23-loom/LockSupport.java:369) ? ? ? ? at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionNode.block(java.base at 23-loom/AbstractQueuedSynchronizer.java:519) ? ? ? ? at java.util.concurrent.ForkJoinPool.unmanagedBlock(java.base at 23-loom/ForkJoinPool.java:4014) ? ? ? ? at java.util.concurrent.ForkJoinPool.managedBlock(java.base at 23-loom/ForkJoinPool.java:3960) ? ? ? ? at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(java.base at 23-loom/AbstractQueuedSynchronizer.java:1712) ? ? ? ? at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(java.base at 23-loom/ScheduledThreadPoolExecutor.java:1177) ? ? ? ? at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(java.base at 23-loom/ScheduledThreadPoolExecutor.java:899) ? ? ? ? at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 23-loom/ThreadPoolExecutor.java:1070) ? ? ? ? at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 23-loom/ThreadPoolExecutor.java:1130) ? ? ? ? at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 23-loom/ThreadPoolExecutor.java:642) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "quartzScheduler_Worker-1" #15970 [213] prio=5 os_prio=0 cpu=411.04ms elapsed=7187.50s tid=0x00007f8aeaa665e0 nid=213 in Object.wait() ?[0x00007f8a0a8e7000] ? ?java.lang.Thread.State: TIMED_WAITING (on object monitor) ? ? ? ? at java.lang.Object.wait0(java.base at 23-loom/Native Method) ? ? ? ? - waiting on ? ? ? ? at java.lang.Object.wait(java.base at 23-loom/Object.java:389) ? ? ? ? at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:568) ? ? ? ? - locked <0x0000000718746670> (a java.lang.Object) "quartzScheduler_QuartzSchedulerThread" #15971 [214] prio=5 os_prio=0 cpu=209.05ms elapsed=7187.49s tid=0x00007f8aeaa6fee0 nid=214 in Object.wait() ?[0x00007f8a0a7e6000] ? ?java.lang.Thread.State: TIMED_WAITING (on object monitor) ? ? ? ? at java.lang.Object.wait0(java.base at 23-loom/Native Method) ? ? ? ? - waiting on ? ? ? ? at java.lang.Object.wait(java.base at 23-loom/Object.java:389) ? ? ? ? at org.quartz.core.QuartzSchedulerThread.run(QuartzSchedulerThread.java:255) ? ? ? ? - locked <0x0000000718770da0> (a java.lang.Object) "qtp1333217812-16028-acceptor-0 at 77b1ab29-ServerConnector@5d585ca0{HTTP/1.1, (http/1.1)}{127.0.0.1:7000}" #16028 [222] prio=3 os_prio=0 cpu=99.44ms elapsed=7186.33s tid=0x00007f8aeabc4ee0 nid=222 runnable ?[0x00007f8a0a6e5000] ? ?java.lang.Thread.State: RUNNABLE ? ? ? ? at sun.nio.ch.Net.accept(java.base at 23-loom/Native Method) ? ? ? ? at sun.nio.ch.ServerSocketChannelImpl.implAccept(java.base at 23-loom/ServerSocketChannelImpl.java:434) ? ? ? ? at sun.nio.ch.ServerSocketChannelImpl.accept(java.base at 23-loom/ServerSocketChannelImpl.java:400) ? ? ? ? at org.eclipse.jetty.server.ServerConnector.accept(ServerConnector.java:389) ? ? ? ? at org.eclipse.jetty.server.AbstractConnector$Acceptor.run(AbstractConnector.java:698) ? ? ? ? at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:979) ? ? ? ? at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.doRunJob(QueuedThreadPool.java:1209) ? ? ? ? at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1164) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "qtp1333217812-16029" #16029 [223] prio=5 os_prio=0 cpu=86.50ms elapsed=7186.32s tid=0x00007f8aeabc5f00 nid=223 waiting on condition ?[0x00007f8a0a5e4000] ? ?java.lang.Thread.State: TIMED_WAITING (parking) ? ? ? ? at jdk.internal.misc.Unsafe.park(java.base at 23-loom/Native Method) ? ? ? ? - parking to wait for ?<0x0000000718aa6ad8> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) ? ? ? ? at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 23-loom/LockSupport.java:271) ? ? ? ? at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(java.base at 23-loom/AbstractQueuedSynchronizer.java:1763) ? ? ? ? at org.eclipse.jetty.util.BlockingArrayQueue.poll(BlockingArrayQueue.java:219) ? ? ? ? at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.idleJobPoll(QueuedThreadPool.java:1139) ? ? ? ? at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1156) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "qtp1333217812-16030" #16030 [224] prio=5 os_prio=0 cpu=71.56ms elapsed=7186.32s tid=0x00007f8aeabc7030 nid=224 waiting on condition ?[0x00007f8a0a4e3000] ? ?java.lang.Thread.State: TIMED_WAITING (parking) ? ? ? ? at jdk.internal.misc.Unsafe.park(java.base at 23-loom/Native Method) ? ? ? ? - parking to wait for ?<0x0000000718aa6ad8> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) ? ? ? ? at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 23-loom/LockSupport.java:271) ? ? ? ? at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(java.base at 23-loom/AbstractQueuedSynchronizer.java:1763) ? ? ? ? at org.eclipse.jetty.util.BlockingArrayQueue.poll(BlockingArrayQueue.java:219) ? ? ? ? at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.idleJobPoll(QueuedThreadPool.java:1139) ? ? ? ? at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1156) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "qtp1333217812-16031" #16031 [225] prio=5 os_prio=0 cpu=145.41ms elapsed=7186.32s tid=0x00007f8aeabd3fd0 nid=225 waiting on condition ?[0x00007f8a0a3e2000] ? ?java.lang.Thread.State: TIMED_WAITING (parking) ? ? ? ? at jdk.internal.misc.Unsafe.park(java.base at 23-loom/Native Method) ? ? ? ? - parking to wait for ?<0x0000000718aa6ad8> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) ? ? ? ? at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 23-loom/LockSupport.java:271) ? ? ? ? at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(java.base at 23-loom/AbstractQueuedSynchronizer.java:1763) ? ? ? ? at org.eclipse.jetty.util.BlockingArrayQueue.poll(BlockingArrayQueue.java:219) ? ? ? ? at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.idleJobPoll(QueuedThreadPool.java:1139) ? ? ? ? at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1156) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "qtp1333217812-16032" #16032 [226] prio=5 os_prio=0 cpu=1354.97ms elapsed=7186.32s tid=0x00007f8aeabd5050 nid=226 waiting on condition ?[0x00007f8a0a2e1000] ? ?java.lang.Thread.State: TIMED_WAITING (parking) ? ? ? ? at jdk.internal.misc.Unsafe.park(java.base at 23-loom/Native Method) ? ? ? ? - parking to wait for ?<0x0000000719e40300> (a java.util.concurrent.Semaphore$NonfairSync) ? ? ? ? at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 23-loom/LockSupport.java:271) ? ? ? ? at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(java.base at 23-loom/AbstractQueuedSynchronizer.java:756) ? ? ? ? at java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(java.base at 23-loom/AbstractQueuedSynchronizer.java:1126) ? ? ? ? at java.util.concurrent.Semaphore.tryAcquire(java.base at 23-loom/Semaphore.java:415) ? ? ? ? at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.waitForTask(ReservedThreadExecutor.java:351) ? ? ? ? at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:290) ? ? ? ? at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:979) ? ? ? ? at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.doRunJob(QueuedThreadPool.java:1209) ? ? ? ? at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1164) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "qtp1333217812-16033" #16033 [227] prio=5 os_prio=0 cpu=1769.54ms elapsed=7186.32s tid=0x00007f8aeabd6570 nid=227 runnable ?[0x00007f8a0a1e0000] ? ?java.lang.Thread.State: RUNNABLE ? ? ? ? at sun.nio.ch.EPoll.wait(java.base at 23-loom/Native Method) ? ? ? ? at sun.nio.ch.EPollSelectorImpl.doSelect(java.base at 23-loom/EPollSelectorImpl.java:123) ? ? ? ? at sun.nio.ch.SelectorImpl.lockAndDoSelect(java.base at 23-loom/SelectorImpl.java:130) ? ? ? ? - locked <0x0000000718acde58> (a sun.nio.ch.Util$2) ? ? ? ? - locked <0x0000000718acde08> (a sun.nio.ch.EPollSelectorImpl) ? ? ? ? at sun.nio.ch.SelectorImpl.select(java.base at 23-loom/SelectorImpl.java:147) ? ? ? ? at org.eclipse.jetty.io.ManagedSelector.nioSelect(ManagedSelector.java:181) ? ? ? ? at org.eclipse.jetty.io.ManagedSelector.select(ManagedSelector.java:188) ? ? ? ? at org.eclipse.jetty.io.ManagedSelector$SelectorProducer.select(ManagedSelector.java:612) ? ? ? ? at org.eclipse.jetty.io.ManagedSelector$SelectorProducer.produce(ManagedSelector.java:546) ? ? ? ? at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.produceTask(AdaptiveExecutionStrategy.java:512) ? ? ? ? at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.tryProduce(AdaptiveExecutionStrategy.java:258) ? ? ? ? at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.run(AdaptiveExecutionStrategy.java:201) ? ? ? ? at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:311) ? ? ? ? at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:979) ? ? ? ? at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.doRunJob(QueuedThreadPool.java:1209) ? ? ? ? at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1164) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "qtp1333217812-16034" #16034 [228] prio=5 os_prio=0 cpu=1366.83ms elapsed=7186.32s tid=0x00007f8aeabd7720 nid=228 runnable ?[0x00007f8a0a0df000] ? ?java.lang.Thread.State: RUNNABLE ? ? ? ? at sun.nio.ch.EPoll.wait(java.base at 23-loom/Native Method) ? ? ? ? at sun.nio.ch.EPollSelectorImpl.doSelect(java.base at 23-loom/EPollSelectorImpl.java:123) ? ? ? ? at sun.nio.ch.SelectorImpl.lockAndDoSelect(java.base at 23-loom/SelectorImpl.java:130) ? ? ? ? - locked <0x0000000718ace0a0> (a sun.nio.ch.Util$2) ? ? ? ? - locked <0x0000000718acdf98> (a sun.nio.ch.EPollSelectorImpl) ? ? ? ? at sun.nio.ch.SelectorImpl.select(java.base at 23-loom/SelectorImpl.java:147) ? ? ? ? at org.eclipse.jetty.io.ManagedSelector.nioSelect(ManagedSelector.java:181) ? ? ? ? at org.eclipse.jetty.io.ManagedSelector.select(ManagedSelector.java:188) ? ? ? ? at org.eclipse.jetty.io.ManagedSelector$SelectorProducer.select(ManagedSelector.java:612) ? ? ? ? at org.eclipse.jetty.io.ManagedSelector$SelectorProducer.produce(ManagedSelector.java:546) ? ? ? ? at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.produceTask(AdaptiveExecutionStrategy.java:512) ? ? ? ? at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.tryProduce(AdaptiveExecutionStrategy.java:258) ? ? ? ? at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.run(AdaptiveExecutionStrategy.java:201) ? ? ? ? at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:311) ? ? ? ? at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:979) ? ? ? ? at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.doRunJob(QueuedThreadPool.java:1209) ? ? ? ? at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1164) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "qtp1333217812-16035" #16035 [229] prio=5 os_prio=0 cpu=1321.61ms elapsed=7186.32s tid=0x00007f8aeabd8c50 nid=229 waiting on condition ?[0x00007f8a09fde000] ? ?java.lang.Thread.State: TIMED_WAITING (parking) ? ? ? ? at jdk.internal.misc.Unsafe.park(java.base at 23-loom/Native Method) ? ? ? ? - parking to wait for ?<0x00000007246bcbb0> (a java.util.concurrent.Semaphore$NonfairSync) ? ? ? ? at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 23-loom/LockSupport.java:271) ? ? ? ? at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(java.base at 23-loom/AbstractQueuedSynchronizer.java:756) ? ? ? ? at java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(java.base at 23-loom/AbstractQueuedSynchronizer.java:1126) ? ? ? ? at java.util.concurrent.Semaphore.tryAcquire(java.base at 23-loom/Semaphore.java:415) ? ? ? ? at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.waitForTask(ReservedThreadExecutor.java:351) ? ? ? ? at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:290) ? ? ? ? at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:979) ? ? ? ? at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.doRunJob(QueuedThreadPool.java:1209) ? ? ? ? at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1164) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "Scheduler-1040240917-1" #16039 [230] prio=5 os_prio=0 cpu=21.61ms elapsed=7186.31s tid=0x00007f8aeabd3820 nid=230 waiting on condition ?[0x00007f8a09edd000] ? ?java.lang.Thread.State: TIMED_WAITING (parking) ? ? ? ? at jdk.internal.misc.Unsafe.park(java.base at 23-loom/Native Method) ? ? ? ? - parking to wait for ?<0x0000000718aa6d88> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) ? ? ? ? at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 23-loom/LockSupport.java:271) ? ? ? ? at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(java.base at 23-loom/AbstractQueuedSynchronizer.java:1763) ? ? ? ? at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(java.base at 23-loom/ScheduledThreadPoolExecutor.java:1182) ? ? ? ? at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(java.base at 23-loom/ScheduledThreadPoolExecutor.java:899) ? ? ? ? at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 23-loom/ThreadPoolExecutor.java:1070) ? ? ? ? at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 23-loom/ThreadPoolExecutor.java:1130) ? ? ? ? at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 23-loom/ThreadPoolExecutor.java:642) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "DestroyJavaVM" #16054 [86] prio=5 os_prio=0 cpu=20887.87ms elapsed=7186.03s tid=0x00007f8ae8029de0 nid=86 waiting on condition ?[0x0000000000000000] ? ?java.lang.Thread.State: RUNNABLE "MQTT Rec: test2:con08:1" #20337 [275] daemon prio=5 os_prio=0 cpu=479.97ms elapsed=7142.42s tid=0x00007f8a1c014ac0 nid=275 runnable ?[0x00007f8a099d8000] ? ?java.lang.Thread.State: RUNNABLE ? ? ? ? at sun.nio.ch.Net.poll(java.base at 23-loom/Native Method) ? ? ? ? at sun.nio.ch.NioSocketImpl.park(java.base at 23-loom/NioSocketImpl.java:191) ? ? ? ? at sun.nio.ch.NioSocketImpl.timedRead(java.base at 23-loom/NioSocketImpl.java:280) ? ? ? ? at sun.nio.ch.NioSocketImpl.implRead(java.base at 23-loom/NioSocketImpl.java:304) ? ? ? ? at sun.nio.ch.NioSocketImpl.read(java.base at 23-loom/NioSocketImpl.java:346) ? ? ? ? at sun.nio.ch.NioSocketImpl$1.read(java.base at 23-loom/NioSocketImpl.java:796) ? ? ? ? at java.net.Socket$SocketInputStream.implRead(java.base at 23-loom/Socket.java:1116) ? ? ? ? at java.net.Socket$SocketInputStream.read(java.base at 23-loom/Socket.java:1103) ? ? ? ? at sun.security.ssl.SSLSocketInputRecord.read(java.base at 23-loom/SSLSocketInputRecord.java:489) ? ? ? ? at sun.security.ssl.SSLSocketInputRecord.readHeader(java.base at 23-loom/SSLSocketInputRecord.java:483) ? ? ? ? at sun.security.ssl.SSLSocketInputRecord.bytesInCompletePacket(java.base at 23-loom/SSLSocketInputRecord.java:70) ? ? ? ? at sun.security.ssl.SSLSocketImpl.readApplicationRecord(java.base at 23-loom/SSLSocketImpl.java:1462) ? ? ? ? at sun.security.ssl.SSLSocketImpl$AppInputStream.read(java.base at 23-loom/SSLSocketImpl.java:1068) ? ? ? ? at sun.security.ssl.SSLSocketImpl$AppInputStream.read(java.base at 23-loom/SSLSocketImpl.java:975) ? ? ? ? at java.io.DataInputStream.readUnsignedByte(java.base at 23-loom/DataInputStream.java:295) ? ? ? ? at java.io.DataInputStream.readByte(java.base at 23-loom/DataInputStream.java:275) ? ? ? ? at org.eclipse.paho.client.mqttv3.internal.wire.MqttInputStream.readMqttWireMessage(MqttInputStream.java:92) ? ? ? ? at org.eclipse.paho.client.mqttv3.internal.CommsReceiver.run(CommsReceiver.java:137) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "MQTT Rec: test2:con08:4" #20344 [279] daemon prio=5 os_prio=0 cpu=510.60ms elapsed=7142.39s tid=0x00007f8a2405dd80 nid=279 runnable ?[0x00007f8a095d4000] ? ?java.lang.Thread.State: RUNNABLE ? ? ? ? at sun.nio.ch.Net.poll(java.base at 23-loom/Native Method) ? ? ? ? at sun.nio.ch.NioSocketImpl.park(java.base at 23-loom/NioSocketImpl.java:191) ? ? ? ? at sun.nio.ch.NioSocketImpl.timedRead(java.base at 23-loom/NioSocketImpl.java:280) ? ? ? ? at sun.nio.ch.NioSocketImpl.implRead(java.base at 23-loom/NioSocketImpl.java:304) ? ? ? ? at sun.nio.ch.NioSocketImpl.read(java.base at 23-loom/NioSocketImpl.java:346) ? ? ? ? at sun.nio.ch.NioSocketImpl$1.read(java.base at 23-loom/NioSocketImpl.java:796) ? ? ? ? at java.net.Socket$SocketInputStream.implRead(java.base at 23-loom/Socket.java:1116) ? ? ? ? at java.net.Socket$SocketInputStream.read(java.base at 23-loom/Socket.java:1103) ? ? ? ? at sun.security.ssl.SSLSocketInputRecord.read(java.base at 23-loom/SSLSocketInputRecord.java:489) ? ? ? ? at sun.security.ssl.SSLSocketInputRecord.readHeader(java.base at 23-loom/SSLSocketInputRecord.java:483) ? ? ? ? at sun.security.ssl.SSLSocketInputRecord.bytesInCompletePacket(java.base at 23-loom/SSLSocketInputRecord.java:70) ? ? ? ? at sun.security.ssl.SSLSocketImpl.readApplicationRecord(java.base at 23-loom/SSLSocketImpl.java:1462) ? ? ? ? at sun.security.ssl.SSLSocketImpl$AppInputStream.read(java.base at 23-loom/SSLSocketImpl.java:1068) ? ? ? ? at sun.security.ssl.SSLSocketImpl$AppInputStream.read(java.base at 23-loom/SSLSocketImpl.java:975) ? ? ? ? at java.io.DataInputStream.readUnsignedByte(java.base at 23-loom/DataInputStream.java:295) ? ? ? ? at java.io.DataInputStream.readByte(java.base at 23-loom/DataInputStream.java:275) ? ? ? ? at org.eclipse.paho.client.mqttv3.internal.wire.MqttInputStream.readMqttWireMessage(MqttInputStream.java:92) ? ? ? ? at org.eclipse.paho.client.mqttv3.internal.CommsReceiver.run(CommsReceiver.java:137) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "MQTT Snd: test2:con08:1" #20362 [281] daemon prio=5 os_prio=0 cpu=6502.40ms elapsed=7142.32s tid=0x00007f8a1c021b60 nid=281 in Object.wait() ?[0x00007f8a093d2000] ? ?java.lang.Thread.State: WAITING (on object monitor) ? ? ? ? at java.lang.Object.wait0(java.base at 23-loom/Native Method) ? ? ? ? - waiting on ? ? ? ? at java.lang.Object.wait(java.base at 23-loom/Object.java:389) ? ? ? ? at java.lang.Object.wait(java.base at 23-loom/Object.java:347) ? ? ? ? at org.eclipse.paho.client.mqttv3.internal.ClientState.get(ClientState.java:833) ? ? ? ? - locked <0x000000071c79b980> (a java.lang.Object) ? ? ? ? at org.eclipse.paho.client.mqttv3.internal.CommsSender.run(CommsSender.java:129) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "MQTT Rec: test2:con08:6" #20367 [284] daemon prio=5 os_prio=0 cpu=441.57ms elapsed=7142.29s tid=0x00007f8a3c010e00 nid=284 runnable ?[0x00007f8a090cf000] ? ?java.lang.Thread.State: RUNNABLE ? ? ? ? at sun.nio.ch.Net.poll(java.base at 23-loom/Native Method) ? ? ? ? at sun.nio.ch.NioSocketImpl.park(java.base at 23-loom/NioSocketImpl.java:191) ? ? ? ? at sun.nio.ch.NioSocketImpl.timedRead(java.base at 23-loom/NioSocketImpl.java:280) ? ? ? ? at sun.nio.ch.NioSocketImpl.implRead(java.base at 23-loom/NioSocketImpl.java:304) ? ? ? ? at sun.nio.ch.NioSocketImpl.read(java.base at 23-loom/NioSocketImpl.java:346) ? ? ? ? at sun.nio.ch.NioSocketImpl$1.read(java.base at 23-loom/NioSocketImpl.java:796) ? ? ? ? at java.net.Socket$SocketInputStream.implRead(java.base at 23-loom/Socket.java:1116) ? ? ? ? at java.net.Socket$SocketInputStream.read(java.base at 23-loom/Socket.java:1103) ? ? ? ? at sun.security.ssl.SSLSocketInputRecord.read(java.base at 23-loom/SSLSocketInputRecord.java:489) ? ? ? ? at sun.security.ssl.SSLSocketInputRecord.readHeader(java.base at 23-loom/SSLSocketInputRecord.java:483) ? ? ? ? at sun.security.ssl.SSLSocketInputRecord.bytesInCompletePacket(java.base at 23-loom/SSLSocketInputRecord.java:70) ? ? ? ? at sun.security.ssl.SSLSocketImpl.readApplicationRecord(java.base at 23-loom/SSLSocketImpl.java:1462) ? ? ? ? at sun.security.ssl.SSLSocketImpl$AppInputStream.read(java.base at 23-loom/SSLSocketImpl.java:1068) ? ? ? ? at sun.security.ssl.SSLSocketImpl$AppInputStream.read(java.base at 23-loom/SSLSocketImpl.java:975) ? ? ? ? at java.io.DataInputStream.readUnsignedByte(java.base at 23-loom/DataInputStream.java:295) ? ? ? ? at java.io.DataInputStream.readByte(java.base at 23-loom/DataInputStream.java:275) ? ? ? ? at org.eclipse.paho.client.mqttv3.internal.wire.MqttInputStream.readMqttWireMessage(MqttInputStream.java:92) ? ? ? ? at org.eclipse.paho.client.mqttv3.internal.CommsReceiver.run(CommsReceiver.java:137) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "MQTT Snd: test2:con08:4" #20368 [285] daemon prio=5 os_prio=0 cpu=4134.42ms elapsed=7142.28s tid=0x00007f8a24064530 nid=285 in Object.wait() ?[0x00007f8a08fce000] ? ?java.lang.Thread.State: WAITING (on object monitor) ? ? ? ? at java.lang.Object.wait0(java.base at 23-loom/Native Method) ? ? ? ? - waiting on ? ? ? ? at java.lang.Object.wait(java.base at 23-loom/Object.java:389) ? ? ? ? at java.lang.Object.wait(java.base at 23-loom/Object.java:347) ? ? ? ? at org.eclipse.paho.client.mqttv3.internal.ClientState.get(ClientState.java:833) ? ? ? ? - locked <0x000000071c7a3010> (a java.lang.Object) ? ? ? ? at org.eclipse.paho.client.mqttv3.internal.CommsSender.run(CommsSender.java:129) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "MQTT Rec: test2:con08:5" #20369 [286] daemon prio=5 os_prio=0 cpu=514.58ms elapsed=7142.28s tid=0x00007f8a3407ab60 nid=286 runnable ?[0x00007f8a08ecd000] ? ?java.lang.Thread.State: RUNNABLE ? ? ? ? at sun.nio.ch.Net.poll(java.base at 23-loom/Native Method) ? ? ? ? at sun.nio.ch.NioSocketImpl.park(java.base at 23-loom/NioSocketImpl.java:191) ? ? ? ? at sun.nio.ch.NioSocketImpl.timedRead(java.base at 23-loom/NioSocketImpl.java:280) ? ? ? ? at sun.nio.ch.NioSocketImpl.implRead(java.base at 23-loom/NioSocketImpl.java:304) ? ? ? ? at sun.nio.ch.NioSocketImpl.read(java.base at 23-loom/NioSocketImpl.java:346) ? ? ? ? at sun.nio.ch.NioSocketImpl$1.read(java.base at 23-loom/NioSocketImpl.java:796) ? ? ? ? at java.net.Socket$SocketInputStream.implRead(java.base at 23-loom/Socket.java:1116) ? ? ? ? at java.net.Socket$SocketInputStream.read(java.base at 23-loom/Socket.java:1103) ? ? ? ? at sun.security.ssl.SSLSocketInputRecord.read(java.base at 23-loom/SSLSocketInputRecord.java:489) ? ? ? ? at sun.security.ssl.SSLSocketInputRecord.readHeader(java.base at 23-loom/SSLSocketInputRecord.java:483) ? ? ? ? at sun.security.ssl.SSLSocketInputRecord.bytesInCompletePacket(java.base at 23-loom/SSLSocketInputRecord.java:70) ? ? ? ? at sun.security.ssl.SSLSocketImpl.readApplicationRecord(java.base at 23-loom/SSLSocketImpl.java:1462) ? ? ? ? at sun.security.ssl.SSLSocketImpl$AppInputStream.read(java.base at 23-loom/SSLSocketImpl.java:1068) ? ? ? ? at sun.security.ssl.SSLSocketImpl$AppInputStream.read(java.base at 23-loom/SSLSocketImpl.java:975) ? ? ? ? at java.io.DataInputStream.readUnsignedByte(java.base at 23-loom/DataInputStream.java:295) ? ? ? ? at java.io.DataInputStream.readByte(java.base at 23-loom/DataInputStream.java:275) ? ? ? ? at org.eclipse.paho.client.mqttv3.internal.wire.MqttInputStream.readMqttWireMessage(MqttInputStream.java:92) ? ? ? ? at org.eclipse.paho.client.mqttv3.internal.CommsReceiver.run(CommsReceiver.java:137) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "MQTT Call: test2:con08:1" #20378 [290] daemon prio=5 os_prio=0 cpu=2829.11ms elapsed=7142.21s tid=0x00007f8a1c0231c0 nid=290 in Object.wait() ?[0x00007f8a08ac9000] ? ?java.lang.Thread.State: WAITING (on object monitor) ? ? ? ? at java.lang.Object.wait0(java.base at 23-loom/Native Method) ? ? ? ? - waiting on ? ? ? ? at java.lang.Object.wait(java.base at 23-loom/Object.java:389) ? ? ? ? at java.lang.Object.wait(java.base at 23-loom/Object.java:347) ? ? ? ? at org.eclipse.paho.client.mqttv3.internal.CommsCallback.run(CommsCallback.java:181) ? ? ? ? - locked <0x000000071c79ec10> (a java.lang.Object) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "MQTT Snd: test2:con08:6" #20382 [293] daemon prio=5 os_prio=0 cpu=4110.12ms elapsed=7142.19s tid=0x00007f8a3c012370 nid=293 in Object.wait() ?[0x00007f8a087c6000] ? ?java.lang.Thread.State: WAITING (on object monitor) ? ? ? ? at java.lang.Object.wait0(java.base at 23-loom/Native Method) ? ? ? ? - waiting on ? ? ? ? at java.lang.Object.wait(java.base at 23-loom/Object.java:389) ? ? ? ? at java.lang.Object.wait(java.base at 23-loom/Object.java:347) ? ? ? ? at org.eclipse.paho.client.mqttv3.internal.ClientState.get(ClientState.java:833) ? ? ? ? - locked <0x000000071c7c4660> (a java.lang.Object) ? ? ? ? at org.eclipse.paho.client.mqttv3.internal.CommsSender.run(CommsSender.java:129) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "MQTT Rec: test2:con08:7" #20384 [294] daemon prio=5 os_prio=0 cpu=426.17ms elapsed=7142.18s tid=0x00007f8a6000acd0 nid=294 runnable ?[0x00007f8a086c5000] ? ?java.lang.Thread.State: RUNNABLE ? ? ? ? at sun.nio.ch.Net.poll(java.base at 23-loom/Native Method) ? ? ? ? at sun.nio.ch.NioSocketImpl.park(java.base at 23-loom/NioSocketImpl.java:191) ? ? ? ? at sun.nio.ch.NioSocketImpl.timedRead(java.base at 23-loom/NioSocketImpl.java:280) ? ? ? ? at sun.nio.ch.NioSocketImpl.implRead(java.base at 23-loom/NioSocketImpl.java:304) ? ? ? ? at sun.nio.ch.NioSocketImpl.read(java.base at 23-loom/NioSocketImpl.java:346) ? ? ? ? at sun.nio.ch.NioSocketImpl$1.read(java.base at 23-loom/NioSocketImpl.java:796) ? ? ? ? at java.net.Socket$SocketInputStream.implRead(java.base at 23-loom/Socket.java:1116) ? ? ? ? at java.net.Socket$SocketInputStream.read(java.base at 23-loom/Socket.java:1103) ? ? ? ? at sun.security.ssl.SSLSocketInputRecord.read(java.base at 23-loom/SSLSocketInputRecord.java:489) ? ? ? ? at sun.security.ssl.SSLSocketInputRecord.readHeader(java.base at 23-loom/SSLSocketInputRecord.java:483) ? ? ? ? at sun.security.ssl.SSLSocketInputRecord.bytesInCompletePacket(java.base at 23-loom/SSLSocketInputRecord.java:70) ? ? ? ? at sun.security.ssl.SSLSocketImpl.readApplicationRecord(java.base at 23-loom/SSLSocketImpl.java:1462) ? ? ? ? at sun.security.ssl.SSLSocketImpl$AppInputStream.read(java.base at 23-loom/SSLSocketImpl.java:1068) ? ? ? ? at sun.security.ssl.SSLSocketImpl$AppInputStream.read(java.base at 23-loom/SSLSocketImpl.java:975) ? ? ? ? at java.io.DataInputStream.readUnsignedByte(java.base at 23-loom/DataInputStream.java:295) ? ? ? ? at java.io.DataInputStream.readByte(java.base at 23-loom/DataInputStream.java:275) ? ? ? ? at org.eclipse.paho.client.mqttv3.internal.wire.MqttInputStream.readMqttWireMessage(MqttInputStream.java:92) ? ? ? ? at org.eclipse.paho.client.mqttv3.internal.CommsReceiver.run(CommsReceiver.java:137) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "MQTT Call: test2:con08:4" #20385 [295] daemon prio=5 os_prio=0 cpu=1752.76ms elapsed=7142.18s tid=0x00007f8a24061600 nid=295 in Object.wait() ?[0x00007f8a085c4000] ? ?java.lang.Thread.State: WAITING (on object monitor) ? ? ? ? at java.lang.Object.wait0(java.base at 23-loom/Native Method) ? ? ? ? - waiting on ? ? ? ? at java.lang.Object.wait(java.base at 23-loom/Object.java:389) ? ? ? ? at java.lang.Object.wait(java.base at 23-loom/Object.java:347) ? ? ? ? at org.eclipse.paho.client.mqttv3.internal.CommsCallback.run(CommsCallback.java:181) ? ? ? ? - locked <0x000000071c7a2fe0> (a java.lang.Object) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "MQTT Snd: test2:con08:5" #20386 [296] daemon prio=5 os_prio=0 cpu=1818.26ms elapsed=7142.18s tid=0x00007f8a340531b0 nid=296 in Object.wait() ?[0x00007f8a084c3000] ? ?java.lang.Thread.State: WAITING (on object monitor) ? ? ? ? at java.lang.Object.wait0(java.base at 23-loom/Native Method) ? ? ? ? - waiting on ? ? ? ? at java.lang.Object.wait(java.base at 23-loom/Object.java:389) ? ? ? ? at java.lang.Object.wait(java.base at 23-loom/Object.java:347) ? ? ? ? at org.eclipse.paho.client.mqttv3.internal.ClientState.get(ClientState.java:833) ? ? ? ? - locked <0x000000071c7dfd98> (a java.lang.Object) ? ? ? ? at org.eclipse.paho.client.mqttv3.internal.CommsSender.run(CommsSender.java:129) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "MQTT Rec: test2:con08:8" #20388 [298] daemon prio=5 os_prio=0 cpu=427.88ms elapsed=7142.17s tid=0x00007f8a5c04ece0 nid=298 runnable ?[0x00007f8a082c1000] ? ?java.lang.Thread.State: RUNNABLE ? ? ? ? at sun.nio.ch.Net.poll(java.base at 23-loom/Native Method) ? ? ? ? at sun.nio.ch.NioSocketImpl.park(java.base at 23-loom/NioSocketImpl.java:191) ? ? ? ? at sun.nio.ch.NioSocketImpl.timedRead(java.base at 23-loom/NioSocketImpl.java:280) ? ? ? ? at sun.nio.ch.NioSocketImpl.implRead(java.base at 23-loom/NioSocketImpl.java:304) ? ? ? ? at sun.nio.ch.NioSocketImpl.read(java.base at 23-loom/NioSocketImpl.java:346) ? ? ? ? at sun.nio.ch.NioSocketImpl$1.read(java.base at 23-loom/NioSocketImpl.java:796) ? ? ? ? at java.net.Socket$SocketInputStream.implRead(java.base at 23-loom/Socket.java:1116) ? ? ? ? at java.net.Socket$SocketInputStream.read(java.base at 23-loom/Socket.java:1103) ? ? ? ? at sun.security.ssl.SSLSocketInputRecord.read(java.base at 23-loom/SSLSocketInputRecord.java:489) ? ? ? ? at sun.security.ssl.SSLSocketInputRecord.readHeader(java.base at 23-loom/SSLSocketInputRecord.java:483) ? ? ? ? at sun.security.ssl.SSLSocketInputRecord.bytesInCompletePacket(java.base at 23-loom/SSLSocketInputRecord.java:70) ? ? ? ? at sun.security.ssl.SSLSocketImpl.readApplicationRecord(java.base at 23-loom/SSLSocketImpl.java:1462) ? ? ? ? at sun.security.ssl.SSLSocketImpl$AppInputStream.read(java.base at 23-loom/SSLSocketImpl.java:1068) ? ? ? ? at sun.security.ssl.SSLSocketImpl$AppInputStream.read(java.base at 23-loom/SSLSocketImpl.java:975) ? ? ? ? at java.io.DataInputStream.readUnsignedByte(java.base at 23-loom/DataInputStream.java:295) ? ? ? ? at java.io.DataInputStream.readByte(java.base at 23-loom/DataInputStream.java:275) ? ? ? ? at org.eclipse.paho.client.mqttv3.internal.wire.MqttInputStream.readMqttWireMessage(MqttInputStream.java:92) ? ? ? ? at org.eclipse.paho.client.mqttv3.internal.CommsReceiver.run(CommsReceiver.java:137) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "MQTT Rec: test2:con08:9" #20392 [299] daemon prio=5 os_prio=0 cpu=421.34ms elapsed=7142.15s tid=0x00007f8a641f4ce0 nid=299 runnable ?[0x00007f8a081c0000] ? ?java.lang.Thread.State: RUNNABLE ? ? ? ? at sun.nio.ch.Net.poll(java.base at 23-loom/Native Method) ? ? ? ? at sun.nio.ch.NioSocketImpl.park(java.base at 23-loom/NioSocketImpl.java:191) ? ? ? ? at sun.nio.ch.NioSocketImpl.timedRead(java.base at 23-loom/NioSocketImpl.java:280) ? ? ? ? at sun.nio.ch.NioSocketImpl.implRead(java.base at 23-loom/NioSocketImpl.java:304) ? ? ? ? at sun.nio.ch.NioSocketImpl.read(java.base at 23-loom/NioSocketImpl.java:346) ? ? ? ? at sun.nio.ch.NioSocketImpl$1.read(java.base at 23-loom/NioSocketImpl.java:796) ? ? ? ? at java.net.Socket$SocketInputStream.implRead(java.base at 23-loom/Socket.java:1116) ? ? ? ? at java.net.Socket$SocketInputStream.read(java.base at 23-loom/Socket.java:1103) ? ? ? ? at sun.security.ssl.SSLSocketInputRecord.read(java.base at 23-loom/SSLSocketInputRecord.java:489) ? ? ? ? at sun.security.ssl.SSLSocketInputRecord.readHeader(java.base at 23-loom/SSLSocketInputRecord.java:483) ? ? ? ? at sun.security.ssl.SSLSocketInputRecord.bytesInCompletePacket(java.base at 23-loom/SSLSocketInputRecord.java:70) ? ? ? ? at sun.security.ssl.SSLSocketImpl.readApplicationRecord(java.base at 23-loom/SSLSocketImpl.java:1462) ? ? ? ? at sun.security.ssl.SSLSocketImpl$AppInputStream.read(java.base at 23-loom/SSLSocketImpl.java:1068) ? ? ? ? at sun.security.ssl.SSLSocketImpl$AppInputStream.read(java.base at 23-loom/SSLSocketImpl.java:975) ? ? ? ? at java.io.DataInputStream.readUnsignedByte(java.base at 23-loom/DataInputStream.java:295) ? ? ? ? at java.io.DataInputStream.readByte(java.base at 23-loom/DataInputStream.java:275) ? ? ? ? at org.eclipse.paho.client.mqttv3.internal.wire.MqttInputStream.readMqttWireMessage(MqttInputStream.java:92) ? ? ? ? at org.eclipse.paho.client.mqttv3.internal.CommsReceiver.run(CommsReceiver.java:137) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "MQTT Ping: test2:con08:1" #20402 [304] prio=5 os_prio=0 cpu=11.66ms elapsed=7142.09s tid=0x00007f8a3005c150 nid=304 in Object.wait() ?[0x00007f8a09bda000] ? ?java.lang.Thread.State: TIMED_WAITING (on object monitor) ? ? ? ? at java.lang.Object.wait0(java.base at 23-loom/Native Method) ? ? ? ? - waiting on ? ? ? ? at java.lang.Object.wait(java.base at 23-loom/Object.java:389) ? ? ? ? at java.util.TimerThread.mainLoop(java.base at 23-loom/Timer.java:569) ? ? ? ? - locked <0x000000071c79ed80> (a java.util.TaskQueue) ? ? ? ? at java.util.TimerThread.run(java.base at 23-loom/Timer.java:522) "MQTT Call: test2:con08:6" #20403 [305] daemon prio=5 os_prio=0 cpu=1750.03ms elapsed=7142.09s tid=0x00007f8a3c0143f0 nid=305 in Object.wait() ?[0x00007f8a09ddc000] ? ?java.lang.Thread.State: WAITING (on object monitor) ? ? ? ? at java.lang.Object.wait0(java.base at 23-loom/Native Method) ? ? ? ? - waiting on ? ? ? ? at java.lang.Object.wait(java.base at 23-loom/Object.java:389) ? ? ? ? at java.lang.Object.wait(java.base at 23-loom/Object.java:347) ? ? ? ? at org.eclipse.paho.client.mqttv3.internal.CommsCallback.run(CommsCallback.java:181) ? ? ? ? - locked <0x000000071c7c4630> (a java.lang.Object) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "MQTT Snd: test2:con08:7" #20404 [306] daemon prio=5 os_prio=0 cpu=2416.38ms elapsed=7142.09s tid=0x00007f8a6000c990 nid=306 in Object.wait() ?[0x00007f89ffcfb000] ? ?java.lang.Thread.State: WAITING (on object monitor) ? ? ? ? at java.lang.Object.wait0(java.base at 23-loom/Native Method) ? ? ? ? - waiting on ? ? ? ? at java.lang.Object.wait(java.base at 23-loom/Object.java:389) ? ? ? ? at java.lang.Object.wait(java.base at 23-loom/Object.java:347) ? ? ? ? at org.eclipse.paho.client.mqttv3.internal.ClientState.get(ClientState.java:833) ? ? ? ? - locked <0x000000071c7f5578> (a java.lang.Object) ? ? ? ? at org.eclipse.paho.client.mqttv3.internal.CommsSender.run(CommsSender.java:129) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "MQTT Rec: test2:con08:11" #20409 [307] daemon prio=5 os_prio=0 cpu=467.58ms elapsed=7142.08s tid=0x00007f8a0c0083f0 nid=307 runnable ?[0x00007f8a09ad9000] ? ?java.lang.Thread.State: RUNNABLE ? ? ? ? at sun.nio.ch.Net.poll(java.base at 23-loom/Native Method) ? ? ? ? at sun.nio.ch.NioSocketImpl.park(java.base at 23-loom/NioSocketImpl.java:191) ? ? ? ? at sun.nio.ch.NioSocketImpl.timedRead(java.base at 23-loom/NioSocketImpl.java:280) ? ? ? ? at sun.nio.ch.NioSocketImpl.implRead(java.base at 23-loom/NioSocketImpl.java:304) ? ? ? ? at sun.nio.ch.NioSocketImpl.read(java.base at 23-loom/NioSocketImpl.java:346) ? ? ? ? at sun.nio.ch.NioSocketImpl$1.read(java.base at 23-loom/NioSocketImpl.java:796) ? ? ? ? at java.net.Socket$SocketInputStream.implRead(java.base at 23-loom/Socket.java:1116) ? ? ? ? at java.net.Socket$SocketInputStream.read(java.base at 23-loom/Socket.java:1103) ? ? ? ? at sun.security.ssl.SSLSocketInputRecord.read(java.base at 23-loom/SSLSocketInputRecord.java:489) ? ? ? ? at sun.security.ssl.SSLSocketInputRecord.readHeader(java.base at 23-loom/SSLSocketInputRecord.java:483) ? ? ? ? at sun.security.ssl.SSLSocketInputRecord.bytesInCompletePacket(java.base at 23-loom/SSLSocketInputRecord.java:70) ? ? ? ? at sun.security.ssl.SSLSocketImpl.readApplicationRecord(java.base at 23-loom/SSLSocketImpl.java:1462) ? ? ? ? at sun.security.ssl.SSLSocketImpl$AppInputStream.read(java.base at 23-loom/SSLSocketImpl.java:1068) ? ? ? ? at sun.security.ssl.SSLSocketImpl$AppInputStream.read(java.base at 23-loom/SSLSocketImpl.java:975) ? ? ? ? at java.io.DataInputStream.readUnsignedByte(java.base at 23-loom/DataInputStream.java:295) ? ? ? ? at java.io.DataInputStream.readByte(java.base at 23-loom/DataInputStream.java:275) ? ? ? ? at org.eclipse.paho.client.mqttv3.internal.wire.MqttInputStream.readMqttWireMessage(MqttInputStream.java:92) ? ? ? ? at org.eclipse.paho.client.mqttv3.internal.CommsReceiver.run(CommsReceiver.java:137) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "MQTT Call: test2:con08:5" #20411 [309] daemon prio=5 os_prio=0 cpu=818.73ms elapsed=7142.07s tid=0x00007f8a34080730 nid=309 in Object.wait() ?[0x00007f89ffaf9000] ? ?java.lang.Thread.State: WAITING (on object monitor) ? ? ? ? at java.lang.Object.wait0(java.base at 23-loom/Native Method) ? ? ? ? - waiting on ? ? ? ? at java.lang.Object.wait(java.base at 23-loom/Object.java:389) ? ? ? ? at java.lang.Object.wait(java.base at 23-loom/Object.java:347) ? ? ? ? at org.eclipse.paho.client.mqttv3.internal.CommsCallback.run(CommsCallback.java:181) ? ? ? ? - locked <0x000000071c7df8d0> (a java.lang.Object) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "MQTT Snd: test2:con08:8" #20413 [310] daemon prio=5 os_prio=0 cpu=6038.00ms elapsed=7142.06s tid=0x00007f8a5c04f420 nid=310 in Object.wait() ?[0x00007f89ff9f8000] ? ?java.lang.Thread.State: WAITING (on object monitor) ? ? ? ? at java.lang.Object.wait0(java.base at 23-loom/Native Method) ? ? ? ? - waiting on ? ? ? ? at java.lang.Object.wait(java.base at 23-loom/Object.java:389) ? ? ? ? at java.lang.Object.wait(java.base at 23-loom/Object.java:347) ? ? ? ? at org.eclipse.paho.client.mqttv3.internal.ClientState.get(ClientState.java:833) ? ? ? ? - locked <0x000000071c7e7878> (a java.lang.Object) ? ? ? ? at org.eclipse.paho.client.mqttv3.internal.CommsSender.run(CommsSender.java:129) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "MQTT Ping: test2:con08:4" #20414 [311] prio=5 os_prio=0 cpu=12.93ms elapsed=7142.06s tid=0x00007f8a4000e260 nid=311 in Object.wait() ?[0x00007f89ff8f7000] ? ?java.lang.Thread.State: TIMED_WAITING (on object monitor) ? ? ? ? at java.lang.Object.wait0(java.base at 23-loom/Native Method) ? ? ? ? - waiting on ? ? ? ? at java.lang.Object.wait(java.base at 23-loom/Object.java:389) ? ? ? ? at java.util.TimerThread.mainLoop(java.base at 23-loom/Timer.java:569) ? ? ? ? - locked <0x000000071c7a2170> (a java.util.TaskQueue) ? ? ? ? at java.util.TimerThread.run(java.base at 23-loom/Timer.java:522) "MQTT Snd: test2:con08:9" #20415 [312] daemon prio=5 os_prio=0 cpu=6225.95ms elapsed=7142.06s tid=0x00007f8a641f5560 nid=312 in Object.wait() ?[0x00007f89ff7f6000] ? ?java.lang.Thread.State: WAITING (on object monitor) ? ? ? ? at java.lang.Object.wait0(java.base at 23-loom/Native Method) ? ? ? ? - waiting on ? ? ? ? at java.lang.Object.wait(java.base at 23-loom/Object.java:389) ? ? ? ? at java.lang.Object.wait(java.base at 23-loom/Object.java:347) ? ? ? ? at org.eclipse.paho.client.mqttv3.internal.ClientState.get(ClientState.java:833) ? ? ? ? - locked <0x000000070d8807e0> (a java.lang.Object) ? ? ? ? at org.eclipse.paho.client.mqttv3.internal.CommsSender.run(CommsSender.java:129) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "MQTT Rec: test2:con08:12" #20421 [313] daemon prio=5 os_prio=0 cpu=412.30ms elapsed=7142.03s tid=0x00007f8a140afa50 nid=313 runnable ?[0x00007f89ff6f5000] ? ?java.lang.Thread.State: RUNNABLE ? ? ? ? at sun.nio.ch.Net.poll(java.base at 23-loom/Native Method) ? ? ? ? at sun.nio.ch.NioSocketImpl.park(java.base at 23-loom/NioSocketImpl.java:191) ? ? ? ? at sun.nio.ch.NioSocketImpl.timedRead(java.base at 23-loom/NioSocketImpl.java:280) ? ? ? ? at sun.nio.ch.NioSocketImpl.implRead(java.base at 23-loom/NioSocketImpl.java:304) ? ? ? ? at sun.nio.ch.NioSocketImpl.read(java.base at 23-loom/NioSocketImpl.java:346) ? ? ? ? at sun.nio.ch.NioSocketImpl$1.read(java.base at 23-loom/NioSocketImpl.java:796) ? ? ? ? at java.net.Socket$SocketInputStream.implRead(java.base at 23-loom/Socket.java:1116) ? ? ? ? at java.net.Socket$SocketInputStream.read(java.base at 23-loom/Socket.java:1103) ? ? ? ? at sun.security.ssl.SSLSocketInputRecord.read(java.base at 23-loom/SSLSocketInputRecord.java:489) ? ? ? ? at sun.security.ssl.SSLSocketInputRecord.readHeader(java.base at 23-loom/SSLSocketInputRecord.java:483) ? ? ? ? at sun.security.ssl.SSLSocketInputRecord.bytesInCompletePacket(java.base at 23-loom/SSLSocketInputRecord.java:70) ? ? ? ? at sun.security.ssl.SSLSocketImpl.readApplicationRecord(java.base at 23-loom/SSLSocketImpl.java:1462) ? ? ? ? at sun.security.ssl.SSLSocketImpl$AppInputStream.read(java.base at 23-loom/SSLSocketImpl.java:1068) ? ? ? ? at sun.security.ssl.SSLSocketImpl$AppInputStream.read(java.base at 23-loom/SSLSocketImpl.java:975) ? ? ? ? at java.io.DataInputStream.readUnsignedByte(java.base at 23-loom/DataInputStream.java:295) ? ? ? ? at java.io.DataInputStream.readByte(java.base at 23-loom/DataInputStream.java:275) ? ? ? ? at org.eclipse.paho.client.mqttv3.internal.wire.MqttInputStream.readMqttWireMessage(MqttInputStream.java:92) ? ? ? ? at org.eclipse.paho.client.mqttv3.internal.CommsReceiver.run(CommsReceiver.java:137) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "MQTT Call: test2:con08:7" #20426 [317] daemon prio=5 os_prio=0 cpu=1002.82ms elapsed=7141.98s tid=0x00007f8a6000db90 nid=317 in Object.wait() ?[0x00007f8a094d3000] ? ?java.lang.Thread.State: WAITING (on object monitor) ? ? ? ? at java.lang.Object.wait0(java.base at 23-loom/Native Method) ? ? ? ? - waiting on ? ? ? ? at java.lang.Object.wait(java.base at 23-loom/Object.java:389) ? ? ? ? at java.lang.Object.wait(java.base at 23-loom/Object.java:347) ? ? ? ? at org.eclipse.paho.client.mqttv3.internal.CommsCallback.run(CommsCallback.java:181) ? ? ? ? - locked <0x000000071c7cc3c8> (a java.lang.Object) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "MQTT Snd: test2:con08:11" #20427 [318] daemon prio=5 os_prio=0 cpu=5996.41ms elapsed=7141.98s tid=0x00007f8a0c009410 nid=318 in Object.wait() ?[0x00007f89ff2f1000] ? ?java.lang.Thread.State: WAITING (on object monitor) ? ? ? ? at java.lang.Object.wait0(java.base at 23-loom/Native Method) ? ? ? ? - waiting on ? ? ? ? at java.lang.Object.wait(java.base at 23-loom/Object.java:389) ? ? ? ? at java.lang.Object.wait(java.base at 23-loom/Object.java:347) ? ? ? ? at org.eclipse.paho.client.mqttv3.internal.ClientState.get(ClientState.java:833) ? ? ? ? - locked <0x000000070d87be90> (a java.lang.Object) ? ? ? ? at org.eclipse.paho.client.mqttv3.internal.CommsSender.run(CommsSender.java:129) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "MQTT Ping: test2:con08:6" #20429 [319] prio=5 os_prio=0 cpu=11.69ms elapsed=7141.97s tid=0x00007f8a4c03b130 nid=319 in Object.wait() ?[0x00007f89ff1f0000] ? ?java.lang.Thread.State: TIMED_WAITING (on object monitor) ? ? ? ? at java.lang.Object.wait0(java.base at 23-loom/Native Method) ? ? ? ? - waiting on ? ? ? ? at java.lang.Object.wait(java.base at 23-loom/Object.java:389) ? ? ? ? at java.util.TimerThread.mainLoop(java.base at 23-loom/Timer.java:569) ? ? ? ? - locked <0x000000071c7c36d0> (a java.util.TaskQueue) ? ? ? ? at java.util.TimerThread.run(java.base at 23-loom/Timer.java:522) "MQTT Call: test2:con08:8" #20430 [320] daemon prio=5 os_prio=0 cpu=2635.66ms elapsed=7141.96s tid=0x00007f8a5c0500d0 nid=320 in Object.wait() ?[0x00007f8a096d5000] ? ?java.lang.Thread.State: WAITING (on object monitor) ? ? ? ? at java.lang.Object.wait0(java.base at 23-loom/Native Method) ? ? ? ? - waiting on ? ? ? ? at java.lang.Object.wait(java.base at 23-loom/Object.java:389) ? ? ? ? at java.lang.Object.wait(java.base at 23-loom/Object.java:347) ? ? ? ? at org.eclipse.paho.client.mqttv3.internal.CommsCallback.run(CommsCallback.java:181) ? ? ? ? - locked <0x000000071c7e7848> (a java.lang.Object) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "MQTT Call: test2:con08:9" #20431 [321] daemon prio=5 os_prio=0 cpu=2674.62ms elapsed=7141.96s tid=0x00007f8a641f6910 nid=321 in Object.wait() ?[0x00007f89ff0ef000] ? ?java.lang.Thread.State: WAITING (on object monitor) ? ? ? ? at java.lang.Object.wait0(java.base at 23-loom/Native Method) ? ? ? ? - waiting on ? ? ? ? at java.lang.Object.wait(java.base at 23-loom/Object.java:389) ? ? ? ? at java.lang.Object.wait(java.base at 23-loom/Object.java:347) ? ? ? ? at org.eclipse.paho.client.mqttv3.internal.CommsCallback.run(CommsCallback.java:181) ? ? ? ? - locked <0x000000071c7f14a8> (a java.lang.Object) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "MQTT Ping: test2:con08:5" #20432 [322] prio=5 os_prio=0 cpu=13.00ms elapsed=7141.95s tid=0x00007f8a5402b290 nid=322 in Object.wait() ?[0x00007f89fefee000] ? ?java.lang.Thread.State: TIMED_WAITING (on object monitor) ? ? ? ? at java.lang.Object.wait0(java.base at 23-loom/Native Method) ? ? ? ? - waiting on ? ? ? ? at java.lang.Object.wait(java.base at 23-loom/Object.java:389) ? ? ? ? at java.util.TimerThread.mainLoop(java.base at 23-loom/Timer.java:569) ? ? ? ? - locked <0x000000071c7df950> (a java.util.TaskQueue) ? ? ? ? at java.util.TimerThread.run(java.base at 23-loom/Timer.java:522) "MQTT Snd: test2:con08:12" #20433 [323] daemon prio=5 os_prio=0 cpu=2959.93ms elapsed=7141.93s tid=0x00007f8a14043240 nid=323 in Object.wait() ?[0x00007f89feeed000] ? ?java.lang.Thread.State: WAITING (on object monitor) ? ? ? ? at java.lang.Object.wait0(java.base at 23-loom/Native Method) ? ? ? ? - waiting on ? ? ? ? at java.lang.Object.wait(java.base at 23-loom/Object.java:389) ? ? ? ? at java.lang.Object.wait(java.base at 23-loom/Object.java:347) ? ? ? ? at org.eclipse.paho.client.mqttv3.internal.ClientState.get(ClientState.java:833) ? ? ? ? - locked <0x000000071c7fdbd8> (a java.lang.Object) ? ? ? ? at org.eclipse.paho.client.mqttv3.internal.CommsSender.run(CommsSender.java:129) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "MQTT Call: test2:con08:11" #20437 [326] daemon prio=5 os_prio=0 cpu=2609.85ms elapsed=7141.88s tid=0x00007f8a0c012b20 nid=326 in Object.wait() ?[0x00007f8a08dcc000] ? ?java.lang.Thread.State: WAITING (on object monitor) ? ? ? ? at java.lang.Object.wait0(java.base at 23-loom/Native Method) ? ? ? ? - waiting on ? ? ? ? at java.lang.Object.wait(java.base at 23-loom/Object.java:389) ? ? ? ? at java.lang.Object.wait(java.base at 23-loom/Object.java:347) ? ? ? ? at org.eclipse.paho.client.mqttv3.internal.CommsCallback.run(CommsCallback.java:181) ? ? ? ? - locked <0x000000070d87af40> (a java.lang.Object) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "MQTT Ping: test2:con08:7" #20440 [327] prio=5 os_prio=0 cpu=12.12ms elapsed=7141.86s tid=0x00007f8ac0735800 nid=327 in Object.wait() ?[0x00007f89febea000] ? ?java.lang.Thread.State: TIMED_WAITING (on object monitor) ? ? ? ? at java.lang.Object.wait0(java.base at 23-loom/Native Method) ? ? ? ? - waiting on ? ? ? ? at java.lang.Object.wait(java.base at 23-loom/Object.java:389) ? ? ? ? at java.util.TimerThread.mainLoop(java.base at 23-loom/Timer.java:569) ? ? ? ? - locked <0x000000071c7cc448> (a java.util.TaskQueue) ? ? ? ? at java.util.TimerThread.run(java.base at 23-loom/Timer.java:522) "MQTT Ping: test2:con08:8" #20444 [328] prio=5 os_prio=0 cpu=9.70ms elapsed=7141.84s tid=0x00007f8a04096810 nid=328 in Object.wait() ?[0x00007f8a08bca000] ? ?java.lang.Thread.State: TIMED_WAITING (on object monitor) ? ? ? ? at java.lang.Object.wait0(java.base at 23-loom/Native Method) ? ? ? ? - waiting on ? ? ? ? at java.lang.Object.wait(java.base at 23-loom/Object.java:389) ? ? ? ? at java.util.TimerThread.mainLoop(java.base at 23-loom/Timer.java:569) ? ? ? ? - locked <0x000000071c7cc9b8> (a java.util.TaskQueue) ? ? ? ? at java.util.TimerThread.run(java.base at 23-loom/Timer.java:522) "MQTT Ping: test2:con08:9" #20445 [329] prio=5 os_prio=0 cpu=11.66ms elapsed=7141.84s tid=0x00007f8a1021b8f0 nid=329 in Object.wait() ?[0x00007f8a08ccb000] ? ?java.lang.Thread.State: TIMED_WAITING (on object monitor) ? ? ? ? at java.lang.Object.wait0(java.base at 23-loom/Native Method) ? ? ? ? - waiting on ? ? ? ? at java.lang.Object.wait(java.base at 23-loom/Object.java:389) ? ? ? ? at java.util.TimerThread.mainLoop(java.base at 23-loom/Timer.java:569) ? ? ? ? - locked <0x000000071c7f1528> (a java.util.TaskQueue) ? ? ? ? at java.util.TimerThread.run(java.base at 23-loom/Timer.java:522) "MQTT Call: test2:con08:12" #20449 [330] daemon prio=5 os_prio=0 cpu=1249.79ms elapsed=7141.83s tid=0x00007f8a14881340 nid=330 in Object.wait() ?[0x00007f89feae9000] ? ?java.lang.Thread.State: WAITING (on object monitor) ? ? ? ? at java.lang.Object.wait0(java.base at 23-loom/Native Method) ? ? ? ? - waiting on ? ? ? ? at java.lang.Object.wait(java.base at 23-loom/Object.java:389) ? ? ? ? at java.lang.Object.wait(java.base at 23-loom/Object.java:347) ? ? ? ? at org.eclipse.paho.client.mqttv3.internal.CommsCallback.run(CommsCallback.java:181) ? ? ? ? - locked <0x000000071c7fdb50> (a java.lang.Object) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "MQTT Ping: test2:con08:11" #20458 [333] prio=5 os_prio=0 cpu=12.78ms elapsed=7141.72s tid=0x00007f8a30027190 nid=333 in Object.wait() ?[0x00007f8a083c2000] ? ?java.lang.Thread.State: TIMED_WAITING (on object monitor) ? ? ? ? at java.lang.Object.wait0(java.base at 23-loom/Native Method) ? ? ? ? - waiting on ? ? ? ? at java.lang.Object.wait(java.base at 23-loom/Object.java:389) ? ? ? ? at java.util.TimerThread.mainLoop(java.base at 23-loom/Timer.java:569) ? ? ? ? - locked <0x000000070d87afc0> (a java.util.TaskQueue) ? ? ? ? at java.util.TimerThread.run(java.base at 23-loom/Timer.java:522) "MQTT Ping: test2:con08:12" #20464 [335] prio=5 os_prio=0 cpu=9.70ms elapsed=7141.70s tid=0x00007f8a48658fc0 nid=335 in Object.wait() ?[0x00007f89ffefd000] ? ?java.lang.Thread.State: TIMED_WAITING (on object monitor) ? ? ? ? at java.lang.Object.wait0(java.base at 23-loom/Native Method) ? ? ? ? - waiting on ? ? ? ? at java.lang.Object.wait(java.base at 23-loom/Object.java:389) ? ? ? ? at java.util.TimerThread.mainLoop(java.base at 23-loom/Timer.java:569) ? ? ? ? - locked <0x000000070d87b828> (a java.util.TaskQueue) ? ? ? ? at java.util.TimerThread.run(java.base at 23-loom/Timer.java:522) "pool-88-thread-1" #27261 [360] prio=5 os_prio=0 cpu=2005.99ms elapsed=7107.78s tid=0x00007f8a4529a010 nid=360 waiting on condition ?[0x00007f8aaf8f7000] ? ?java.lang.Thread.State: WAITING (parking) ? ? ? ? at jdk.internal.misc.Unsafe.park(java.base at 23-loom/Native Method) ? ? ? ? - parking to wait for ?<0x000000070cc58b50> (a java.util.concurrent.locks.ReentrantLock$NonfairSync) ? ? ? ? at java.util.concurrent.locks.LockSupport.park(java.base at 23-loom/LockSupport.java:223) ? ? ? ? at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(java.base at 23-loom/AbstractQueuedSynchronizer.java:754) ? ? ? ? at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(java.base at 23-loom/AbstractQueuedSynchronizer.java:990) ? ? ? ? at java.util.concurrent.locks.ReentrantLock$Sync.lock(java.base at 23-loom/ReentrantLock.java:154) ? ? ? ? at java.util.concurrent.locks.ReentrantLock.lock(java.base at 23-loom/ReentrantLock.java:323) ? ? ? ? at ch.qos.logback.core.OutputStreamAppender.writeBytes(OutputStreamAppender.java:200) ? ? ? ? at ch.qos.logback.core.OutputStreamAppender.writeOut(OutputStreamAppender.java:193) ? ? ? ? at ch.qos.logback.core.OutputStreamAppender.subAppend(OutputStreamAppender.java:237) ? ? ? ? at ch.qos.logback.core.OutputStreamAppender.append(OutputStreamAppender.java:102) ? ? ? ? at ch.qos.logback.core.UnsynchronizedAppenderBase.doAppend(UnsynchronizedAppenderBase.java:85) ? ? ? ? at ch.qos.logback.core.spi.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:51) ? ? ? ? at ch.qos.logback.classic.Logger.appendLoopOnAppenders(Logger.java:272) ? ? ? ? at ch.qos.logback.classic.Logger.callAppenders(Logger.java:259) ? ? ? ? at ch.qos.logback.classic.Logger.buildLoggingEventAndAppend(Logger.java:426) ? ? ? ? at ch.qos.logback.classic.Logger.filterAndLog_2(Logger.java:419) ? ? ? ? at ch.qos.logback.classic.Logger.debug(Logger.java:495) ? ? ? ? at com.securithings.stam.monitoring.scheduling.spring.VirtualThreadAgentlessTaskScheduler.lambda$getScheduledFuture$2(VirtualThreadAgentlessTaskScheduler.java:74) ? ? ? ? at com.securithings.stam.monitoring.scheduling.spring.VirtualThreadAgentlessTaskScheduler$$Lambda/0x00007f8a6f9a8420.run(Unknown Source) ? ? ? ? at java.util.concurrent.Executors$RunnableAdapter.call(java.base at 23-loom/Executors.java:572) ? ? ? ? at java.util.concurrent.FutureTask.runAndReset(java.base at 23-loom/FutureTask.java:358) ? ? ? ? at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(java.base at 23-loom/ScheduledThreadPoolExecutor.java:305) ? ? ? ? at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 23-loom/ThreadPoolExecutor.java:1144) ? ? ? ? at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 23-loom/ThreadPoolExecutor.java:642) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "MQTT Rec: test2:con08:14" #106613 [513] daemon prio=5 os_prio=0 cpu=463.87ms elapsed=6913.49s tid=0x00007f8ac802e600 nid=513 runnable ?[0x00007f89fe6e5000] ? ?java.lang.Thread.State: RUNNABLE ? ? ? ? at sun.nio.ch.Net.poll(java.base at 23-loom/Native Method) ? ? ? ? at sun.nio.ch.NioSocketImpl.park(java.base at 23-loom/NioSocketImpl.java:191) ? ? ? ? at sun.nio.ch.NioSocketImpl.timedRead(java.base at 23-loom/NioSocketImpl.java:280) ? ? ? ? at sun.nio.ch.NioSocketImpl.implRead(java.base at 23-loom/NioSocketImpl.java:304) ? ? ? ? at sun.nio.ch.NioSocketImpl.read(java.base at 23-loom/NioSocketImpl.java:346) ? ? ? ? at sun.nio.ch.NioSocketImpl$1.read(java.base at 23-loom/NioSocketImpl.java:796) ? ? ? ? at java.net.Socket$SocketInputStream.implRead(java.base at 23-loom/Socket.java:1116) ? ? ? ? at java.net.Socket$SocketInputStream.read(java.base at 23-loom/Socket.java:1103) ? ? ? ? at sun.security.ssl.SSLSocketInputRecord.read(java.base at 23-loom/SSLSocketInputRecord.java:489) ? ? ? ? at sun.security.ssl.SSLSocketInputRecord.readHeader(java.base at 23-loom/SSLSocketInputRecord.java:483) ? ? ? ? at sun.security.ssl.SSLSocketInputRecord.bytesInCompletePacket(java.base at 23-loom/SSLSocketInputRecord.java:70) ? ? ? ? at sun.security.ssl.SSLSocketImpl.readApplicationRecord(java.base at 23-loom/SSLSocketImpl.java:1462) ? ? ? ? at sun.security.ssl.SSLSocketImpl$AppInputStream.read(java.base at 23-loom/SSLSocketImpl.java:1068) ? ? ? ? at sun.security.ssl.SSLSocketImpl$AppInputStream.read(java.base at 23-loom/SSLSocketImpl.java:975) ? ? ? ? at java.io.DataInputStream.readUnsignedByte(java.base at 23-loom/DataInputStream.java:295) ? ? ? ? at java.io.DataInputStream.readByte(java.base at 23-loom/DataInputStream.java:275) ? ? ? ? at org.eclipse.paho.client.mqttv3.internal.wire.MqttInputStream.readMqttWireMessage(MqttInputStream.java:92) ? ? ? ? at org.eclipse.paho.client.mqttv3.internal.CommsReceiver.run(CommsReceiver.java:137) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "MQTT Rec: test2:con08:15" #106614 [514] daemon prio=5 os_prio=0 cpu=424.30ms elapsed=6913.48s tid=0x00007f8ac0738670 nid=514 runnable ?[0x00007f89fe5e4000] ? ?java.lang.Thread.State: RUNNABLE ? ? ? ? at sun.nio.ch.Net.poll(java.base at 23-loom/Native Method) ? ? ? ? at sun.nio.ch.NioSocketImpl.park(java.base at 23-loom/NioSocketImpl.java:191) ? ? ? ? at sun.nio.ch.NioSocketImpl.timedRead(java.base at 23-loom/NioSocketImpl.java:280) ? ? ? ? at sun.nio.ch.NioSocketImpl.implRead(java.base at 23-loom/NioSocketImpl.java:304) ? ? ? ? at sun.nio.ch.NioSocketImpl.read(java.base at 23-loom/NioSocketImpl.java:346) ? ? ? ? at sun.nio.ch.NioSocketImpl$1.read(java.base at 23-loom/NioSocketImpl.java:796) ? ? ? ? at java.net.Socket$SocketInputStream.implRead(java.base at 23-loom/Socket.java:1116) ? ? ? ? at java.net.Socket$SocketInputStream.read(java.base at 23-loom/Socket.java:1103) ? ? ? ? at sun.security.ssl.SSLSocketInputRecord.read(java.base at 23-loom/SSLSocketInputRecord.java:489) ? ? ? ? at sun.security.ssl.SSLSocketInputRecord.readHeader(java.base at 23-loom/SSLSocketInputRecord.java:483) ? ? ? ? at sun.security.ssl.SSLSocketInputRecord.bytesInCompletePacket(java.base at 23-loom/SSLSocketInputRecord.java:70) ? ? ? ? at sun.security.ssl.SSLSocketImpl.readApplicationRecord(java.base at 23-loom/SSLSocketImpl.java:1462) ? ? ? ? at sun.security.ssl.SSLSocketImpl$AppInputStream.read(java.base at 23-loom/SSLSocketImpl.java:1068) ? ? ? ? at sun.security.ssl.SSLSocketImpl$AppInputStream.read(java.base at 23-loom/SSLSocketImpl.java:975) ? ? ? ? at java.io.DataInputStream.readUnsignedByte(java.base at 23-loom/DataInputStream.java:295) ? ? ? ? at java.io.DataInputStream.readByte(java.base at 23-loom/DataInputStream.java:275) ? ? ? ? at org.eclipse.paho.client.mqttv3.internal.wire.MqttInputStream.readMqttWireMessage(MqttInputStream.java:92) ? ? ? ? at org.eclipse.paho.client.mqttv3.internal.CommsReceiver.run(CommsReceiver.java:137) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "MQTT Snd: test2:con08:14" #106641 [515] daemon prio=5 os_prio=0 cpu=4214.13ms elapsed=6913.39s tid=0x00007f8ac802ed40 nid=515 in Object.wait() ?[0x00007f89fe4e3000] ? ?java.lang.Thread.State: WAITING (on object monitor) ? ? ? ? at java.lang.Object.wait0(java.base at 23-loom/Native Method) ? ? ? ? - waiting on ? ? ? ? at java.lang.Object.wait(java.base at 23-loom/Object.java:389) ? ? ? ? at java.lang.Object.wait(java.base at 23-loom/Object.java:347) ? ? ? ? at org.eclipse.paho.client.mqttv3.internal.ClientState.get(ClientState.java:833) ? ? ? ? - locked <0x000000070d6004a8> (a java.lang.Object) ? ? ? ? at org.eclipse.paho.client.mqttv3.internal.CommsSender.run(CommsSender.java:129) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "MQTT Snd: test2:con08:15" #106642 [516] daemon prio=5 os_prio=0 cpu=3438.43ms elapsed=6913.39s tid=0x00007f8ac01e8510 nid=516 in Object.wait() ?[0x00007f89fe3e2000] ? ?java.lang.Thread.State: WAITING (on object monitor) ? ? ? ? at java.lang.Object.wait0(java.base at 23-loom/Native Method) ? ? ? ? - waiting on ? ? ? ? at java.lang.Object.wait(java.base at 23-loom/Object.java:389) ? ? ? ? at java.lang.Object.wait(java.base at 23-loom/Object.java:347) ? ? ? ? at org.eclipse.paho.client.mqttv3.internal.ClientState.get(ClientState.java:833) ? ? ? ? - locked <0x000000070d700340> (a java.lang.Object) ? ? ? ? at org.eclipse.paho.client.mqttv3.internal.CommsSender.run(CommsSender.java:129) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "MQTT Call: test2:con08:14" #106681 [517] daemon prio=5 os_prio=0 cpu=1823.43ms elapsed=6913.29s tid=0x00007f8ac8031340 nid=517 in Object.wait() ?[0x00007f89fe2e1000] ? ?java.lang.Thread.State: WAITING (on object monitor) ? ? ? ? at java.lang.Object.wait0(java.base at 23-loom/Native Method) ? ? ? ? - waiting on ? ? ? ? at java.lang.Object.wait(java.base at 23-loom/Object.java:389) ? ? ? ? at java.lang.Object.wait(java.base at 23-loom/Object.java:347) ? ? ? ? at org.eclipse.paho.client.mqttv3.internal.CommsCallback.run(CommsCallback.java:181) ? ? ? ? - locked <0x000000070d6005f8> (a java.lang.Object) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "MQTT Call: test2:con08:15" #106682 [518] daemon prio=5 os_prio=0 cpu=1536.86ms elapsed=6913.28s tid=0x00007f8ac01e97b0 nid=518 in Object.wait() ?[0x00007f89fe1e0000] ? ?java.lang.Thread.State: WAITING (on object monitor) ? ? ? ? at java.lang.Object.wait0(java.base at 23-loom/Native Method) ? ? ? ? - waiting on ? ? ? ? at java.lang.Object.wait(java.base at 23-loom/Object.java:389) ? ? ? ? at java.lang.Object.wait(java.base at 23-loom/Object.java:347) ? ? ? ? at org.eclipse.paho.client.mqttv3.internal.CommsCallback.run(CommsCallback.java:181) ? ? ? ? - locked <0x000000070d700490> (a java.lang.Object) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "MQTT Ping: test2:con08:14" #106735 [519] prio=5 os_prio=0 cpu=12.37ms elapsed=6913.17s tid=0x00007f8aea9ad0a0 nid=519 in Object.wait() ?[0x00007f89fe8e7000] ? ?java.lang.Thread.State: TIMED_WAITING (on object monitor) ? ? ? ? at java.lang.Object.wait0(java.base at 23-loom/Native Method) ? ? ? ? - waiting on ? ? ? ? at java.lang.Object.wait(java.base at 23-loom/Object.java:389) ? ? ? ? at java.util.TimerThread.mainLoop(java.base at 23-loom/Timer.java:569) ? ? ? ? - locked <0x000000070d6006d8> (a java.util.TaskQueue) ? ? ? ? at java.util.TimerThread.run(java.base at 23-loom/Timer.java:522) "MQTT Ping: test2:con08:15" #106736 [520] prio=5 os_prio=0 cpu=10.06ms elapsed=6913.17s tid=0x0000556b55612100 nid=520 in Object.wait() ?[0x00007f89fe7e6000] ? ?java.lang.Thread.State: TIMED_WAITING (on object monitor) ? ? ? ? at java.lang.Object.wait0(java.base at 23-loom/Native Method) ? ? ? ? - waiting on ? ? ? ? at java.lang.Object.wait(java.base at 23-loom/Object.java:389) ? ? ? ? at java.util.TimerThread.mainLoop(java.base at 23-loom/Timer.java:569) ? ? ? ? - locked <0x0000000713000568> (a java.util.TaskQueue) ? ? ? ? at java.util.TimerThread.run(java.base at 23-loom/Timer.java:522) "MQTT Rec: test2:con08:2" #516628 [1368] daemon prio=5 os_prio=0 cpu=414.12ms elapsed=5751.81s tid=0x00007f8a30032640 nid=1368 runnable ?[0x00007f8a097d6000] ? ?java.lang.Thread.State: RUNNABLE ? ? ? ? at sun.nio.ch.Net.poll(java.base at 23-loom/Native Method) ? ? ? ? at sun.nio.ch.NioSocketImpl.park(java.base at 23-loom/NioSocketImpl.java:191) ? ? ? ? at sun.nio.ch.NioSocketImpl.timedRead(java.base at 23-loom/NioSocketImpl.java:280) ? ? ? ? at sun.nio.ch.NioSocketImpl.implRead(java.base at 23-loom/NioSocketImpl.java:304) ? ? ? ? at sun.nio.ch.NioSocketImpl.read(java.base at 23-loom/NioSocketImpl.java:346) ? ? ? ? at sun.nio.ch.NioSocketImpl$1.read(java.base at 23-loom/NioSocketImpl.java:796) ? ? ? ? at java.net.Socket$SocketInputStream.implRead(java.base at 23-loom/Socket.java:1116) ? ? ? ? at java.net.Socket$SocketInputStream.read(java.base at 23-loom/Socket.java:1103) ? ? ? ? at sun.security.ssl.SSLSocketInputRecord.read(java.base at 23-loom/SSLSocketInputRecord.java:489) ? ? ? ? at sun.security.ssl.SSLSocketInputRecord.readHeader(java.base at 23-loom/SSLSocketInputRecord.java:483) ? ? ? ? at sun.security.ssl.SSLSocketInputRecord.bytesInCompletePacket(java.base at 23-loom/SSLSocketInputRecord.java:70) ? ? ? ? at sun.security.ssl.SSLSocketImpl.readApplicationRecord(java.base at 23-loom/SSLSocketImpl.java:1462) ? ? ? ? at sun.security.ssl.SSLSocketImpl$AppInputStream.read(java.base at 23-loom/SSLSocketImpl.java:1068) ? ? ? ? at sun.security.ssl.SSLSocketImpl$AppInputStream.read(java.base at 23-loom/SSLSocketImpl.java:975) ? ? ? ? at java.io.DataInputStream.readUnsignedByte(java.base at 23-loom/DataInputStream.java:295) ? ? ? ? at java.io.DataInputStream.readByte(java.base at 23-loom/DataInputStream.java:275) ? ? ? ? at org.eclipse.paho.client.mqttv3.internal.wire.MqttInputStream.readMqttWireMessage(MqttInputStream.java:92) ? ? ? ? at org.eclipse.paho.client.mqttv3.internal.CommsReceiver.run(CommsReceiver.java:137) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "MQTT Snd: test2:con08:2" #516667 [1369] daemon prio=5 os_prio=0 cpu=3232.05ms elapsed=5751.71s tid=0x00007f8a3002bd20 nid=1369 in Object.wait() ?[0x00007f8a088c7000] ? ?java.lang.Thread.State: WAITING (on object monitor) ? ? ? ? at java.lang.Object.wait0(java.base at 23-loom/Native Method) ? ? ? ? - waiting on ? ? ? ? at java.lang.Object.wait(java.base at 23-loom/Object.java:389) ? ? ? ? at java.lang.Object.wait(java.base at 23-loom/Object.java:347) ? ? ? ? at org.eclipse.paho.client.mqttv3.internal.ClientState.get(ClientState.java:833) ? ? ? ? - locked <0x000000071c7b0a28> (a java.lang.Object) ? ? ? ? at org.eclipse.paho.client.mqttv3.internal.CommsSender.run(CommsSender.java:129) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "MQTT Call: test2:con08:2" #516717 [1370] daemon prio=5 os_prio=0 cpu=1316.27ms elapsed=5751.61s tid=0x00007f8a30039fd0 nid=1370 in Object.wait() ?[0x00007f8a091d0000] ? ?java.lang.Thread.State: WAITING (on object monitor) ? ? ? ? at java.lang.Object.wait0(java.base at 23-loom/Native Method) ? ? ? ? - waiting on ? ? ? ? at java.lang.Object.wait(java.base at 23-loom/Object.java:389) ? ? ? ? at java.lang.Object.wait(java.base at 23-loom/Object.java:347) ? ? ? ? at org.eclipse.paho.client.mqttv3.internal.CommsCallback.run(CommsCallback.java:181) ? ? ? ? - locked <0x000000071c7b09f8> (a java.lang.Object) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "MQTT Ping: test2:con08:2" #516791 [1371] prio=5 os_prio=0 cpu=10.02ms elapsed=5751.49s tid=0x00007f8a2c0168c0 nid=1371 in Object.wait() ?[0x00007f89ff4f3000] ? ?java.lang.Thread.State: TIMED_WAITING (on object monitor) ? ? ? ? at java.lang.Object.wait0(java.base at 23-loom/Native Method) ? ? ? ? - waiting on ? ? ? ? at java.lang.Object.wait(java.base at 23-loom/Object.java:389) ? ? ? ? at java.util.TimerThread.mainLoop(java.base at 23-loom/Timer.java:569) ? ? ? ? - locked <0x000000070d600908> (a java.util.TaskQueue) ? ? ? ? at java.util.TimerThread.run(java.base at 23-loom/Timer.java:522) "MariaDb-bulk-12" #538351 [1402] daemon prio=5 os_prio=0 cpu=751.15ms elapsed=5712.26s tid=0x00007f8a14162f80 nid=1402 waiting on condition ?[0x00007f89fdbda000] ? ?java.lang.Thread.State: WAITING (parking) ? ? ? ? at jdk.internal.misc.Unsafe.park(java.base at 23-loom/Native Method) ? ? ? ? - parking to wait for ?<0x000000072470ff80> (a java.util.concurrent.SynchronousQueue$Transferer) ? ? ? ? at java.util.concurrent.locks.LockSupport.park(java.base at 23-loom/LockSupport.java:369) ? ? ? ? at java.util.concurrent.LinkedTransferQueue$DualNode.await(java.base at 23-loom/LinkedTransferQueue.java:458) ? ? ? ? at java.util.concurrent.SynchronousQueue$Transferer.xferLifo(java.base at 23-loom/SynchronousQueue.java:194) ? ? ? ? at java.util.concurrent.SynchronousQueue.xfer(java.base at 23-loom/SynchronousQueue.java:235) ? ? ? ? at java.util.concurrent.SynchronousQueue.take(java.base at 23-loom/SynchronousQueue.java:318) ? ? ? ? at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 23-loom/ThreadPoolExecutor.java:1070) ? ? ? ? at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 23-loom/ThreadPoolExecutor.java:1130) ? ? ? ? at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 23-loom/ThreadPoolExecutor.java:642) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "MQTT Rec: test2:con08:10" #789650 [1889] daemon prio=5 os_prio=0 cpu=318.10ms elapsed=5025.35s tid=0x00007f8a041bb560 nid=1889 runnable ?[0x00007f89ff3f2000] ? ?java.lang.Thread.State: RUNNABLE ? ? ? ? at sun.nio.ch.Net.poll(java.base at 23-loom/Native Method) ? ? ? ? at sun.nio.ch.NioSocketImpl.park(java.base at 23-loom/NioSocketImpl.java:191) ? ? ? ? at sun.nio.ch.NioSocketImpl.timedRead(java.base at 23-loom/NioSocketImpl.java:280) ? ? ? ? at sun.nio.ch.NioSocketImpl.implRead(java.base at 23-loom/NioSocketImpl.java:304) ? ? ? ? at sun.nio.ch.NioSocketImpl.read(java.base at 23-loom/NioSocketImpl.java:346) ? ? ? ? at sun.nio.ch.NioSocketImpl$1.read(java.base at 23-loom/NioSocketImpl.java:796) ? ? ? ? at java.net.Socket$SocketInputStream.implRead(java.base at 23-loom/Socket.java:1116) ? ? ? ? at java.net.Socket$SocketInputStream.read(java.base at 23-loom/Socket.java:1103) ? ? ? ? at sun.security.ssl.SSLSocketInputRecord.read(java.base at 23-loom/SSLSocketInputRecord.java:489) ? ? ? ? at sun.security.ssl.SSLSocketInputRecord.readHeader(java.base at 23-loom/SSLSocketInputRecord.java:483) ? ? ? ? at sun.security.ssl.SSLSocketInputRecord.bytesInCompletePacket(java.base at 23-loom/SSLSocketInputRecord.java:70) ? ? ? ? at sun.security.ssl.SSLSocketImpl.readApplicationRecord(java.base at 23-loom/SSLSocketImpl.java:1462) ? ? ? ? at sun.security.ssl.SSLSocketImpl$AppInputStream.read(java.base at 23-loom/SSLSocketImpl.java:1068) ? ? ? ? at sun.security.ssl.SSLSocketImpl$AppInputStream.read(java.base at 23-loom/SSLSocketImpl.java:975) ? ? ? ? at java.io.DataInputStream.readUnsignedByte(java.base at 23-loom/DataInputStream.java:295) ? ? ? ? at java.io.DataInputStream.readByte(java.base at 23-loom/DataInputStream.java:275) ? ? ? ? at org.eclipse.paho.client.mqttv3.internal.wire.MqttInputStream.readMqttWireMessage(MqttInputStream.java:92) ? ? ? ? at org.eclipse.paho.client.mqttv3.internal.CommsReceiver.run(CommsReceiver.java:137) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "MQTT Snd: test2:con08:10" #789695 [1890] daemon prio=5 os_prio=0 cpu=3889.43ms elapsed=5025.25s tid=0x00007f8a041b8620 nid=1890 in Object.wait() ?[0x00007f8a09cdb000] ? ?java.lang.Thread.State: WAITING (on object monitor) ? ? ? ? at java.lang.Object.wait0(java.base at 23-loom/Native Method) ? ? ? ? - waiting on ? ? ? ? at java.lang.Object.wait(java.base at 23-loom/Object.java:389) ? ? ? ? at java.lang.Object.wait(java.base at 23-loom/Object.java:347) ? ? ? ? at org.eclipse.paho.client.mqttv3.internal.ClientState.get(ClientState.java:833) ? ? ? ? - locked <0x000000071c7f5f68> (a java.lang.Object) ? ? ? ? at org.eclipse.paho.client.mqttv3.internal.CommsSender.run(CommsSender.java:129) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "MQTT Call: test2:con08:10" #789728 [1891] daemon prio=5 os_prio=0 cpu=1617.39ms elapsed=5025.15s tid=0x00007f8a041b9410 nid=1891 in Object.wait() ?[0x00007f89feceb000] ? ?java.lang.Thread.State: WAITING (on object monitor) ? ? ? ? at java.lang.Object.wait0(java.base at 23-loom/Native Method) ? ? ? ? - waiting on ? ? ? ? at java.lang.Object.wait(java.base at 23-loom/Object.java:389) ? ? ? ? at java.lang.Object.wait(java.base at 23-loom/Object.java:347) ? ? ? ? at org.eclipse.paho.client.mqttv3.internal.CommsCallback.run(CommsCallback.java:181) ? ? ? ? - locked <0x000000071c7f5f38> (a java.lang.Object) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "MQTT Ping: test2:con08:10" #789788 [1892] prio=5 os_prio=0 cpu=8.99ms elapsed=5025.03s tid=0x00007f8a10011140 nid=1892 in Object.wait() ?[0x00007f89ffffe000] ? ?java.lang.Thread.State: TIMED_WAITING (on object monitor) ? ? ? ? at java.lang.Object.wait0(java.base at 23-loom/Native Method) ? ? ? ? - waiting on ? ? ? ? at java.lang.Object.wait(java.base at 23-loom/Object.java:389) ? ? ? ? at java.util.TimerThread.mainLoop(java.base at 23-loom/Timer.java:569) ? ? ? ? - locked <0x00000007130f58a0> (a java.util.TaskQueue) ? ? ? ? at java.util.TimerThread.run(java.base at 23-loom/Timer.java:522) "CircuitBreakerAutoTransitionThread" #883840 [2092] daemon prio=5 os_prio=0 cpu=1.59ms elapsed=4742.06s tid=0x00007f8a144cfea0 nid=2092 waiting on condition ?[0x00007f89fedec000] ? ?java.lang.Thread.State: WAITING (parking) ? ? ? ? at jdk.internal.misc.Unsafe.park(java.base at 23-loom/Native Method) ? ? ? ? - parking to wait for ?<0x0000000713000778> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) ? ? ? ? at java.util.concurrent.locks.LockSupport.park(java.base at 23-loom/LockSupport.java:369) ? ? ? ? at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionNode.block(java.base at 23-loom/AbstractQueuedSynchronizer.java:519) ? ? ? ? at java.util.concurrent.ForkJoinPool.unmanagedBlock(java.base at 23-loom/ForkJoinPool.java:4014) ? ? ? ? at java.util.concurrent.ForkJoinPool.managedBlock(java.base at 23-loom/ForkJoinPool.java:3960) ? ? ? ? at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(java.base at 23-loom/AbstractQueuedSynchronizer.java:1712) ? ? ? ? at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(java.base at 23-loom/ScheduledThreadPoolExecutor.java:1170) ? ? ? ? at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(java.base at 23-loom/ScheduledThreadPoolExecutor.java:899) ? ? ? ? at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 23-loom/ThreadPoolExecutor.java:1070) ? ? ? ? at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 23-loom/ThreadPoolExecutor.java:1130) ? ? ? ? at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 23-loom/ThreadPoolExecutor.java:642) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "MQTT Rec: test2:con08:13" #891095 [2128] daemon prio=5 os_prio=0 cpu=366.01ms elapsed=4692.89s tid=0x00007f8a2c017000 nid=2128 runnable ?[0x00007f89fd9d8000] ? ?java.lang.Thread.State: RUNNABLE ? ? ? ? at sun.nio.ch.Net.poll(java.base at 23-loom/Native Method) ? ? ? ? at sun.nio.ch.NioSocketImpl.park(java.base at 23-loom/NioSocketImpl.java:191) ? ? ? ? at sun.nio.ch.NioSocketImpl.timedRead(java.base at 23-loom/NioSocketImpl.java:280) ? ? ? ? at sun.nio.ch.NioSocketImpl.implRead(java.base at 23-loom/NioSocketImpl.java:304) ? ? ? ? at sun.nio.ch.NioSocketImpl.read(java.base at 23-loom/NioSocketImpl.java:346) ? ? ? ? at sun.nio.ch.NioSocketImpl$1.read(java.base at 23-loom/NioSocketImpl.java:796) ? ? ? ? at java.net.Socket$SocketInputStream.implRead(java.base at 23-loom/Socket.java:1116) ? ? ? ? at java.net.Socket$SocketInputStream.read(java.base at 23-loom/Socket.java:1103) ? ? ? ? at sun.security.ssl.SSLSocketInputRecord.read(java.base at 23-loom/SSLSocketInputRecord.java:489) ? ? ? ? at sun.security.ssl.SSLSocketInputRecord.readHeader(java.base at 23-loom/SSLSocketInputRecord.java:483) ? ? ? ? at sun.security.ssl.SSLSocketInputRecord.bytesInCompletePacket(java.base at 23-loom/SSLSocketInputRecord.java:70) ? ? ? ? at sun.security.ssl.SSLSocketImpl.readApplicationRecord(java.base at 23-loom/SSLSocketImpl.java:1462) ? ? ? ? at sun.security.ssl.SSLSocketImpl$AppInputStream.read(java.base at 23-loom/SSLSocketImpl.java:1068) ? ? ? ? at sun.security.ssl.SSLSocketImpl$AppInputStream.read(java.base at 23-loom/SSLSocketImpl.java:975) ? ? ? ? at java.io.DataInputStream.readUnsignedByte(java.base at 23-loom/DataInputStream.java:295) ? ? ? ? at java.io.DataInputStream.readByte(java.base at 23-loom/DataInputStream.java:275) ? ? ? ? at org.eclipse.paho.client.mqttv3.internal.wire.MqttInputStream.readMqttWireMessage(MqttInputStream.java:92) ? ? ? ? at org.eclipse.paho.client.mqttv3.internal.CommsReceiver.run(CommsReceiver.java:137) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "MQTT Snd: test2:con08:13" #891110 [2129] daemon prio=5 os_prio=0 cpu=2772.51ms elapsed=4692.79s tid=0x00007f8a2c028dc0 nid=2129 in Object.wait() ?[0x00007f89fe0df000] ? ?java.lang.Thread.State: WAITING (on object monitor) ? ? ? ? at java.lang.Object.wait0(java.base at 23-loom/Native Method) ? ? ? ? - waiting on ? ? ? ? at java.lang.Object.wait(java.base at 23-loom/Object.java:389) ? ? ? ? at java.lang.Object.wait(java.base at 23-loom/Object.java:347) ? ? ? ? at org.eclipse.paho.client.mqttv3.internal.ClientState.get(ClientState.java:833) ? ? ? ? - locked <0x000000070d880b08> (a java.lang.Object) ? ? ? ? at org.eclipse.paho.client.mqttv3.internal.CommsSender.run(CommsSender.java:129) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "MQTT Call: test2:con08:13" #891140 [2130] daemon prio=5 os_prio=0 cpu=1150.61ms elapsed=4692.69s tid=0x00007f8a2c01ccd0 nid=2130 in Object.wait() ?[0x00007f89ff5f4000] ? ?java.lang.Thread.State: WAITING (on object monitor) ? ? ? ? at java.lang.Object.wait0(java.base at 23-loom/Native Method) ? ? ? ? - waiting on ? ? ? ? at java.lang.Object.wait(java.base at 23-loom/Object.java:389) ? ? ? ? at java.lang.Object.wait(java.base at 23-loom/Object.java:347) ? ? ? ? at org.eclipse.paho.client.mqttv3.internal.CommsCallback.run(CommsCallback.java:181) ? ? ? ? - locked <0x000000070d8836b0> (a java.lang.Object) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "MQTT Ping: test2:con08:13" #891157 [2131] prio=5 os_prio=0 cpu=8.72ms elapsed=4692.57s tid=0x00007f8a38221550 nid=2131 in Object.wait() ?[0x00007f89fdfde000] ? ?java.lang.Thread.State: TIMED_WAITING (on object monitor) ? ? ? ? at java.lang.Object.wait0(java.base at 23-loom/Native Method) ? ? ? ? - waiting on ? ? ? ? at java.lang.Object.wait(java.base at 23-loom/Object.java:389) ? ? ? ? at java.util.TimerThread.mainLoop(java.base at 23-loom/Timer.java:569) ? ? ? ? - locked <0x0000000716776ee8> (a java.util.TaskQueue) ? ? ? ? at java.util.TimerThread.run(java.base at 23-loom/Timer.java:522) "MQTT Rec: test2:con08:3" #898127 [2153] daemon prio=5 os_prio=0 cpu=281.99ms elapsed=4657.92s tid=0x00007f8a48d7f130 nid=2153 runnable ?[0x00007f8a092d1000] ? ?java.lang.Thread.State: RUNNABLE ? ? ? ? at sun.nio.ch.Net.poll(java.base at 23-loom/Native Method) ? ? ? ? at sun.nio.ch.NioSocketImpl.park(java.base at 23-loom/NioSocketImpl.java:191) ? ? ? ? at sun.nio.ch.NioSocketImpl.timedRead(java.base at 23-loom/NioSocketImpl.java:280) ? ? ? ? at sun.nio.ch.NioSocketImpl.implRead(java.base at 23-loom/NioSocketImpl.java:304) ? ? ? ? at sun.nio.ch.NioSocketImpl.read(java.base at 23-loom/NioSocketImpl.java:346) ? ? ? ? at sun.nio.ch.NioSocketImpl$1.read(java.base at 23-loom/NioSocketImpl.java:796) ? ? ? ? at java.net.Socket$SocketInputStream.implRead(java.base at 23-loom/Socket.java:1116) ? ? ? ? at java.net.Socket$SocketInputStream.read(java.base at 23-loom/Socket.java:1103) ? ? ? ? at sun.security.ssl.SSLSocketInputRecord.read(java.base at 23-loom/SSLSocketInputRecord.java:489) ? ? ? ? at sun.security.ssl.SSLSocketInputRecord.readHeader(java.base at 23-loom/SSLSocketInputRecord.java:483) ? ? ? ? at sun.security.ssl.SSLSocketInputRecord.bytesInCompletePacket(java.base at 23-loom/SSLSocketInputRecord.java:70) ? ? ? ? at sun.security.ssl.SSLSocketImpl.readApplicationRecord(java.base at 23-loom/SSLSocketImpl.java:1462) ? ? ? ? at sun.security.ssl.SSLSocketImpl$AppInputStream.read(java.base at 23-loom/SSLSocketImpl.java:1068) ? ? ? ? at sun.security.ssl.SSLSocketImpl$AppInputStream.read(java.base at 23-loom/SSLSocketImpl.java:975) ? ? ? ? at java.io.DataInputStream.readUnsignedByte(java.base at 23-loom/DataInputStream.java:295) ? ? ? ? at java.io.DataInputStream.readByte(java.base at 23-loom/DataInputStream.java:275) ? ? ? ? at org.eclipse.paho.client.mqttv3.internal.wire.MqttInputStream.readMqttWireMessage(MqttInputStream.java:92) ? ? ? ? at org.eclipse.paho.client.mqttv3.internal.CommsReceiver.run(CommsReceiver.java:137) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "MQTT Snd: test2:con08:3" #898152 [2154] daemon prio=5 os_prio=0 cpu=2318.89ms elapsed=4657.82s tid=0x00007f8a48dba690 nid=2154 in Object.wait() ?[0x00007f89ffbfa000] ? ?java.lang.Thread.State: WAITING (on object monitor) ? ? ? ? at java.lang.Object.wait0(java.base at 23-loom/Native Method) ? ? ? ? - waiting on ? ? ? ? at java.lang.Object.wait(java.base at 23-loom/Object.java:389) ? ? ? ? at java.lang.Object.wait(java.base at 23-loom/Object.java:347) ? ? ? ? at org.eclipse.paho.client.mqttv3.internal.ClientState.get(ClientState.java:833) ? ? ? ? - locked <0x000000071c7a7930> (a java.lang.Object) ? ? ? ? at org.eclipse.paho.client.mqttv3.internal.CommsSender.run(CommsSender.java:129) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "MQTT Call: test2:con08:3" #898169 [2162] daemon prio=5 os_prio=0 cpu=986.40ms elapsed=4657.72s tid=0x00007f8a48d373b0 nid=2162 in Object.wait() ?[0x00007f8a089c8000] ? ?java.lang.Thread.State: WAITING (on object monitor) ? ? ? ? at java.lang.Object.wait0(java.base at 23-loom/Native Method) ? ? ? ? - waiting on ? ? ? ? at java.lang.Object.wait(java.base at 23-loom/Object.java:389) ? ? ? ? at java.lang.Object.wait(java.base at 23-loom/Object.java:347) ? ? ? ? at org.eclipse.paho.client.mqttv3.internal.CommsCallback.run(CommsCallback.java:181) ? ? ? ? - locked <0x000000071c7a1f78> (a java.lang.Object) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "MQTT Ping: test2:con08:3" #898192 [2163] prio=5 os_prio=0 cpu=8.12ms elapsed=4657.60s tid=0x00007f8a44a3a160 nid=2163 in Object.wait() ?[0x00007f8a098d7000] ? ?java.lang.Thread.State: TIMED_WAITING (on object monitor) ? ? ? ? at java.lang.Object.wait0(java.base at 23-loom/Native Method) ? ? ? ? - waiting on ? ? ? ? at java.lang.Object.wait(java.base at 23-loom/Object.java:389) ? ? ? ? at java.util.TimerThread.mainLoop(java.base at 23-loom/Timer.java:569) ? ? ? ? - locked <0x000000070d607378> (a java.util.TaskQueue) ? ? ? ? at java.util.TimerThread.run(java.base at 23-loom/Timer.java:522) "MariaDb-bulk-19" #1047253 [2457] daemon prio=5 os_prio=0 cpu=331.24ms elapsed=4226.73s tid=0x00007f8a341875b0 nid=2457 waiting on condition ?[0x00007f8aaf6f5000] ? ?java.lang.Thread.State: WAITING (parking) ? ? ? ? at jdk.internal.misc.Unsafe.park(java.base at 23-loom/Native Method) ? ? ? ? - parking to wait for ?<0x000000072470ff80> (a java.util.concurrent.SynchronousQueue$Transferer) ? ? ? ? at java.util.concurrent.locks.LockSupport.park(java.base at 23-loom/LockSupport.java:369) ? ? ? ? at java.util.concurrent.LinkedTransferQueue$DualNode.await(java.base at 23-loom/LinkedTransferQueue.java:458) ? ? ? ? at java.util.concurrent.SynchronousQueue$Transferer.xferLifo(java.base at 23-loom/SynchronousQueue.java:194) ? ? ? ? at java.util.concurrent.SynchronousQueue.xfer(java.base at 23-loom/SynchronousQueue.java:235) ? ? ? ? at java.util.concurrent.SynchronousQueue.take(java.base at 23-loom/SynchronousQueue.java:318) ? ? ? ? at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 23-loom/ThreadPoolExecutor.java:1070) ? ? ? ? at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 23-loom/ThreadPoolExecutor.java:1130) ? ? ? ? at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 23-loom/ThreadPoolExecutor.java:642) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "MariaDb-bulk-20" #1076996 [2513] daemon prio=5 os_prio=0 cpu=301.54ms elapsed=4141.38s tid=0x00007f8a44ad3cc0 nid=2513 waiting on condition ?[0x00007f89fdddc000] ? ?java.lang.Thread.State: WAITING (parking) ? ? ? ? at jdk.internal.misc.Unsafe.park(java.base at 23-loom/Native Method) ? ? ? ? - parking to wait for ?<0x000000072470ff80> (a java.util.concurrent.SynchronousQueue$Transferer) ? ? ? ? at java.util.concurrent.locks.LockSupport.park(java.base at 23-loom/LockSupport.java:369) ? ? ? ? at java.util.concurrent.LinkedTransferQueue$DualNode.await(java.base at 23-loom/LinkedTransferQueue.java:458) ? ? ? ? at java.util.concurrent.SynchronousQueue$Transferer.xferLifo(java.base at 23-loom/SynchronousQueue.java:194) ? ? ? ? at java.util.concurrent.SynchronousQueue.xfer(java.base at 23-loom/SynchronousQueue.java:235) ? ? ? ? at java.util.concurrent.SynchronousQueue.take(java.base at 23-loom/SynchronousQueue.java:318) ? ? ? ? at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 23-loom/ThreadPoolExecutor.java:1070) ? ? ? ? at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 23-loom/ThreadPoolExecutor.java:1130) ? ? ? ? at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 23-loom/ThreadPoolExecutor.java:642) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "MariaDb-bulk-22" #1077012 [2515] daemon prio=5 os_prio=0 cpu=380.58ms elapsed=4141.31s tid=0x00007f8a1404d210 nid=2515 waiting on condition ?[0x00007f89fe9e8000] ? ?java.lang.Thread.State: WAITING (parking) ? ? ? ? at jdk.internal.misc.Unsafe.park(java.base at 23-loom/Native Method) ? ? ? ? - parking to wait for ?<0x000000072470ff80> (a java.util.concurrent.SynchronousQueue$Transferer) ? ? ? ? at java.util.concurrent.locks.LockSupport.park(java.base at 23-loom/LockSupport.java:369) ? ? ? ? at java.util.concurrent.LinkedTransferQueue$DualNode.await(java.base at 23-loom/LinkedTransferQueue.java:458) ? ? ? ? at java.util.concurrent.SynchronousQueue$Transferer.xferLifo(java.base at 23-loom/SynchronousQueue.java:194) ? ? ? ? at java.util.concurrent.SynchronousQueue.xfer(java.base at 23-loom/SynchronousQueue.java:235) ? ? ? ? at java.util.concurrent.SynchronousQueue.take(java.base at 23-loom/SynchronousQueue.java:318) ? ? ? ? at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 23-loom/ThreadPoolExecutor.java:1070) ? ? ? ? at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 23-loom/ThreadPoolExecutor.java:1130) ? ? ? ? at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 23-loom/ThreadPoolExecutor.java:642) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "MariaDb-bulk-23" #1077016 [2516] daemon prio=5 os_prio=0 cpu=536.72ms elapsed=4141.29s tid=0x00007f8a48d30db0 nid=2516 waiting on condition ?[0x00007f89ffdfc000] ? ?java.lang.Thread.State: WAITING (parking) ? ? ? ? at jdk.internal.misc.Unsafe.park(java.base at 23-loom/Native Method) ? ? ? ? - parking to wait for ?<0x000000072470ff80> (a java.util.concurrent.SynchronousQueue$Transferer) ? ? ? ? at java.util.concurrent.locks.LockSupport.park(java.base at 23-loom/LockSupport.java:369) ? ? ? ? at java.util.concurrent.LinkedTransferQueue$DualNode.await(java.base at 23-loom/LinkedTransferQueue.java:458) ? ? ? ? at java.util.concurrent.SynchronousQueue$Transferer.xferLifo(java.base at 23-loom/SynchronousQueue.java:194) ? ? ? ? at java.util.concurrent.SynchronousQueue.xfer(java.base at 23-loom/SynchronousQueue.java:235) ? ? ? ? at java.util.concurrent.SynchronousQueue.take(java.base at 23-loom/SynchronousQueue.java:318) ? ? ? ? at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 23-loom/ThreadPoolExecutor.java:1070) ? ? ? ? at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 23-loom/ThreadPoolExecutor.java:1130) ? ? ? ? at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 23-loom/ThreadPoolExecutor.java:642) ? ? ? ? at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) ? ? ? ? at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) "GC Thread#3" os_prio=0 cpu=34598.69ms elapsed=7215.73s tid=0x00007f8a640082e0 nid=108 runnable "GC Thread#2" os_prio=0 cpu=34526.98ms elapsed=7215.73s tid=0x00007f8a640077c0 nid=107 runnable "GC Thread#1" os_prio=0 cpu=35003.49ms elapsed=7215.73s tid=0x00007f8a64006ca0 nid=106 runnable "VM Thread" os_prio=0 cpu=3041.06ms elapsed=7216.13s tid=0x00007f8ae815dd60 nid=93 runnable "VM Periodic Task Thread" os_prio=0 cpu=3060.28ms elapsed=7216.20s tid=0x00007f8ae813f860 nid=92 waiting on condition "G1 Service" os_prio=0 cpu=440.61ms elapsed=7216.22s tid=0x00007f8ae8125c10 nid=91 runnable "G1 Refine#0" os_prio=0 cpu=5835.07ms elapsed=7216.22s tid=0x00007f8ae8124c50 nid=90 runnable "G1 Conc#0" os_prio=0 cpu=11616.32ms elapsed=7216.22s tid=0x00007f8ae80a5010 nid=89 runnable "G1 Main Marker" os_prio=0 cpu=26.90ms elapsed=7216.22s tid=0x00007f8ae80a4070 nid=88 runnable "GC Thread#0" os_prio=0 cpu=34770.08ms elapsed=7216.22s tid=0x00007f8ae808f910 nid=87 runnable JNI global refs: 19, weak refs: 0 Heap ?garbage-first heap ? total reserved 3997696K, committed 1488896K, used 758311K [0x000000070c000000, 0x0000000800000000) ? region size 2048K, 229 young (468992K), 12 survivors (24576K) ?Metaspace ? ? ? used 93936K, committed 95296K, reserved 1179648K ? class space ? ?used 11245K, committed 11904K, reserved 1048576K From rengels at ix.netcom.com Sun Jul 21 14:10:58 2024 From: rengels at ix.netcom.com (robert engels) Date: Sun, 21 Jul 2024 09:10:58 -0500 Subject: Experiencing an issue with ScheduledExecutorService alongside VT In-Reply-To: References: <3cdd7056-6321-4653-be4d-71bf5bea55e5@oracle.com> Message-ID: Hi. The code looks incorrect (although it is not complete so hard to tell). The outer exception catch is releasing the semaphore even though it may have never acquired it. Since the code is not complete, there is no way to validate what you are seeing. I suggest trying to provide a standalone reproducible test case. > On Jul 21, 2024, at 8:11 AM, Yuval Lombard wrote: > > Hi Alan, > > Attaching the thread dump when the issue occurs (as a txt file) > > It might be useful > > On Sun, 21 Jul 2024 at 12:41, Yuval Lombard > wrote: > Hi Alan > > Thanks for replying! > > When the issue occurs the Log you mentioned is not being printed - it is as if (or maybe it is even what is really happening) the virtual thread is not being scheduled (by its internal scheduler) > I to a thread dump by executing "kill -3 " and did not see the VT, will `java Thread.dump_to_file ` produce a more detailed view of the living threads? > > I will try to run the later EA build > > On Sun, 21 Jul 2024 at 11:14, Alan Bateman > wrote: > On 21/07/2024 08:05, Yuval Lombard wrote: > > Hey team > > > > We are experiencing some weird halting issues when scheduling tasks > > with ScheduledExecutorService and VT. > > > > We are observing some near deadlock issues / halting of executors > > which we are not able to reproduce when using platform threads > > > > This is one example of a near deadlock situation, where for some > > reason virtual threads are starting to execute a task, and not > > reaching the finally block nor the catch Throwable block to release > > the acquired semaphore permit, reaching to drained semaphore. > > > Is "Scheduling .. task for device" logged? Did you take thread dump with > `java Thread.dump_to_file ` and try to identify the virtual > thread? > > One of the later mails mentions 23-loom+4-102 and not seeing JFR events. > Can you re-run with the latest EA build (currently 24-loom+2-24) as that > has changes for the JFR events that may provide some insight here. > > -Alan > > > -- > Kind regards, > > Yuval Lombard > > Lead Software Engineer > > +972.50.548.0111 > > yuval.l at securithings.com > > > > > -- > Kind regards, > > Yuval Lombard > > Lead Software Engineer > > +972.50.548.0111 > > yuval.l at securithings.com > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rengels at ix.netcom.com Sun Jul 21 14:42:29 2024 From: rengels at ix.netcom.com (robert engels) Date: Sun, 21 Jul 2024 09:42:29 -0500 Subject: Experiencing an issue with ScheduledExecutorService alongside VT In-Reply-To: References: <3cdd7056-6321-4653-be4d-71bf5bea55e5@oracle.com> Message-ID: If you look at the thread dump, you will see: "MQTT Snd: test2:con08:13" #891110 [2129] daemon prio=5 os_prio=0 cpu=2772.51ms elapsed=4692.79s tid=0x00007f8a2c028dc0 nid=2129 in Object.wait() [0x00007f89fe0df000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait0(java.base at 23-loom/Native Method) - waiting on at java.lang.Object.wait(java.base at 23-loom/Object.java:389) at java.lang.Object.wait(java.base at 23-loom/Object.java:347) at org.eclipse.paho.client.mqttv3.internal.ClientState.get(ClientState.java:833) - locked <0x000000070d880b08> (a java.lang.Object) at org.eclipse.paho.client.mqttv3.internal.CommsSender.run(CommsSender.java:129) at java.lang.Thread.runWith(java.base at 23-loom/Thread.java:1595) at java.lang.Thread.run(java.base at 23-loom/Thread.java:1582) I am guessing you have library code using monitors. I am concerned about the ?no object reference available? above. I also suggest testing with a lighter weight VT native http server like github.com/robaho/httpserver to avoid so many framework threads - it should make things easier to diagnose. Most importantly, use jcmd Thread.dump_to_file -format=text so that the thread dumps contain virtual thread information. > On Jul 21, 2024, at 9:10 AM, robert engels wrote: > > Hi. The code looks incorrect (although it is not complete so hard to tell). > > The outer exception catch is releasing the semaphore even though it may have never acquired it. > > Since the code is not complete, there is no way to validate what you are seeing. > > I suggest trying to provide a standalone reproducible test case. > >> On Jul 21, 2024, at 8:11 AM, Yuval Lombard > wrote: >> >> Hi Alan, >> >> Attaching the thread dump when the issue occurs (as a txt file) >> >> It might be useful >> >> On Sun, 21 Jul 2024 at 12:41, Yuval Lombard > wrote: >> Hi Alan >> >> Thanks for replying! >> >> When the issue occurs the Log you mentioned is not being printed - it is as if (or maybe it is even what is really happening) the virtual thread is not being scheduled (by its internal scheduler) >> I to a thread dump by executing "kill -3 " and did not see the VT, will `java Thread.dump_to_file ` produce a more detailed view of the living threads? >> >> I will try to run the later EA build >> >> On Sun, 21 Jul 2024 at 11:14, Alan Bateman > wrote: >> On 21/07/2024 08:05, Yuval Lombard wrote: >> > Hey team >> > >> > We are experiencing some weird halting issues when scheduling tasks >> > with ScheduledExecutorService and VT. >> > >> > We are observing some near deadlock issues / halting of executors >> > which we are not able to reproduce when using platform threads >> > >> > This is one example of a near deadlock situation, where for some >> > reason virtual threads are starting to execute a task, and not >> > reaching the finally block nor the catch Throwable block to release >> > the acquired semaphore permit, reaching to drained semaphore. >> >> >> Is "Scheduling .. task for device" logged? Did you take thread dump with >> `java Thread.dump_to_file ` and try to identify the virtual >> thread? >> >> One of the later mails mentions 23-loom+4-102 and not seeing JFR events. >> Can you re-run with the latest EA build (currently 24-loom+2-24) as that >> has changes for the JFR events that may provide some insight here. >> >> -Alan >> >> >> -- >> Kind regards, >> >> Yuval Lombard >> >> Lead Software Engineer >> >> +972.50.548.0111 >> >> yuval.l at securithings.com >> >> >> >> >> -- >> Kind regards, >> >> Yuval Lombard >> >> Lead Software Engineer >> >> +972.50.548.0111 >> >> yuval.l at securithings.com >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Sun Jul 21 17:13:25 2024 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 21 Jul 2024 18:13:25 +0100 Subject: Experiencing an issue with ScheduledExecutorService alongside VT In-Reply-To: References: <3cdd7056-6321-4653-be4d-71bf5bea55e5@oracle.com> Message-ID: On 21/07/2024 14:11, Yuval Lombard wrote: > Hi Alan, > > Attaching the thread dump when the issue occurs (as a txt?file) > > It might be useful > Thanks. From a quick look, ForkJoinPool-1-worker-4 has an interesting stack trace. It tells us that a virtual thread has unmounted while trying to enter a monitor and the carrier is scheduling it to unblock+retry after a delay (this is detail on what the first thread to contend has to do in the object monitor implementation). It may be that the thread dump was taken at just the right thing to capture this contented on scheduling the wakeup but it may be something else. There is at least one issue in this area fixed in the more recent EA build so it would be good to try that. In the addition to the thread dumps, can you add `jcmd Thread.vthread_summary` to the list of things to capture? Asking because that will print a summary of timer queues which might be relevant to the issue. -Alan From Alan.Bateman at oracle.com Sun Jul 21 17:32:05 2024 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 21 Jul 2024 18:32:05 +0100 Subject: Experiencing an issue with ScheduledExecutorService alongside VT In-Reply-To: References: <3cdd7056-6321-4653-be4d-71bf5bea55e5@oracle.com> Message-ID: <213a86b9-2c9a-494f-9077-695008a48870@oracle.com> On 21/07/2024 18:10, Yuval Lombard wrote: > Hi Robert > > Thanks for your reply and feedback. > Unfortunately I have no choice but using the MQTT 3rd party lib > > Attaching also the jcmd thread dump as you suggested. > Hope it would be helpful There are 120k virtual threads. Most of them have empty stack traces? so I assume they have been started but haven't executed yet. The dump is hinting that it is something timer related. There are two virtual threads (#1561853 and #1561856) doing Socket.connect with a timeout and both are scheduling to be unparked if their connection isn't established before the timeout expires. At the same time, some other virtual thread (not sure which) has just unmounted from ForkJoinPool-1-worker-4 due to contention trying to enter a monitor. ForkJoinPool-1-worker-4 is attempt to schedule the virtual thread to unblocked after a short delay. So I think you are running into a bug but I think we need to see if duplicates with the more recent EA build. -Alan From yuval.l at securithings.com Sun Jul 21 18:14:43 2024 From: yuval.l at securithings.com (Yuval Lombard) Date: Sun, 21 Jul 2024 21:14:43 +0300 Subject: Experiencing an issue with ScheduledExecutorService alongside VT In-Reply-To: <213a86b9-2c9a-494f-9077-695008a48870@oracle.com> References: <3cdd7056-6321-4653-be4d-71bf5bea55e5@oracle.com> <213a86b9-2c9a-494f-9077-695008a48870@oracle.com> Message-ID: Hi Alan, By "So I think you are running into a bug.." do you mean on my end? (Hope you do ?) When scheduling my tasks with platform threads I dont see it is being reproduced, although I must say my current platform threads scheduler is different (quartz scheduler) and does not make use of semaphores (but instead it pools its workers) that is why I suspect my usage of semaphores with VT. Also when I try to execute the vthread_summary command you suggested I get this error: java.lang.IllegalArgumentException: Unknown diagnostic command I will certainly do as you suggest and try to upgrade the java version to the latest ea, but I really want to make sure I am not doing anything stupid and missing something before I do that On Sun, 21 Jul 2024 at 20:32, Alan Bateman wrote: > On 21/07/2024 18:10, Yuval Lombard wrote: > > Hi Robert > > > > Thanks for your reply and feedback. > > Unfortunately I have no choice but using the MQTT 3rd party lib > > > > Attaching also the jcmd thread dump as you suggested. > > Hope it would be helpful > > There are 120k virtual threads. Most of them have empty stack traces so > I assume they have been started but haven't executed yet. The dump is > hinting that it is something timer related. There are two virtual > threads (#1561853 and #1561856) doing Socket.connect with a timeout and > both are scheduling to be unparked if their connection isn't established > before the timeout expires. At the same time, some other virtual thread > (not sure which) has just unmounted from ForkJoinPool-1-worker-4 due to > contention trying to enter a monitor. ForkJoinPool-1-worker-4 is attempt > to schedule the virtual thread to unblocked after a short delay. So I > think you are running into a bug but I think we need to see if > duplicates with the more recent EA build. > > -Alan > > -- Kind regards, *Yuval Lombard* *Lead Software Engineer* +972.50.548.0111 yuval.l at securithings.com [image: logo_black.png] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo_black.png Type: image/png Size: 99833 bytes Desc: not available URL: From Alan.Bateman at oracle.com Sun Jul 21 19:56:29 2024 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 21 Jul 2024 20:56:29 +0100 Subject: Experiencing an issue with ScheduledExecutorService alongside VT In-Reply-To: References: <3cdd7056-6321-4653-be4d-71bf5bea55e5@oracle.com> <213a86b9-2c9a-494f-9077-695008a48870@oracle.com> Message-ID: <6d928b93-8698-4546-9571-c7e00651ab3c@oracle.com> On 21/07/2024 19:14, Yuval Lombard wrote: > Hi Alan, > > By "So I > think you are running into a bug.." do you mean on my end? (Hope you > do??) I should have been clearer, I meant this is likely a JDK bug in the EA build. From the thread I'm 80% certain it's related preemption when cancelling the timer after Object.wait(millis). The only thing that you might want to check is whether something is accidentally pooling virtual threads to execute periodic tasks, meaning something is calling Executors.newScheduleThreadPool with a thread factory that creates virtual threads. It's not the cause of this hang, just something that I see in the thread dump. > > When scheduling my tasks with platform threads I dont?see it is being > reproduced, although I must say my current platform threads scheduler > is different (quartz scheduler) and does not make use of semaphores > (but instead it pools its workers) that is why I suspect my usage of > semaphores with VT. > > Also when I try to execute the vthread_summary command you suggested I > get this error: > java.lang.IllegalArgumentException: Unknown diagnostic command Ah right, this jcmd is not in the older EA build so it can't be used until you pick up a more recent EA build. -Alan From yuval.l at securithings.com Mon Jul 22 06:09:14 2024 From: yuval.l at securithings.com (Yuval Lombard) Date: Mon, 22 Jul 2024 09:09:14 +0300 Subject: Experiencing an issue with ScheduledExecutorService alongside VT In-Reply-To: <6d928b93-8698-4546-9571-c7e00651ab3c@oracle.com> References: <3cdd7056-6321-4653-be4d-71bf5bea55e5@oracle.com> <213a86b9-2c9a-494f-9077-695008a48870@oracle.com> <6d928b93-8698-4546-9571-c7e00651ab3c@oracle.com> Message-ID: Hi Alan, Thanks for the clarifications! OK regarding the pooling of the VT, now I understand what robert meant about the partial code example. The scheduler is created in this way: ScheduledExecutorService scheduler = Executors.newScheduledThreadPool(1) then as the code example shows after it is granted with a permit to execute a task, it delegates it to the VT by starting it this way: Thread.ofVirtual().start(() -> { ... } I upgrade the jdk to the latest EA and test it again, and get back to you in any case with the relevant thread dumps. On Sun, 21 Jul 2024 at 22:56, Alan Bateman wrote: > > > On 21/07/2024 19:14, Yuval Lombard wrote: > > Hi Alan, > > > > By "So I > > think you are running into a bug.." do you mean on my end? (Hope you > > do ?) > > I should have been clearer, I meant this is likely a JDK bug in the EA > build. From the thread I'm 80% certain it's related preemption when > cancelling the timer after Object.wait(millis). > > The only thing that you might want to check is whether something is > accidentally pooling virtual threads to execute periodic tasks, meaning > something is calling Executors.newScheduleThreadPool with a thread > factory that creates virtual threads. It's not the cause of this hang, > just something that I see in the thread dump. > > > > > When scheduling my tasks with platform threads I dont see it is being > > reproduced, although I must say my current platform threads scheduler > > is different (quartz scheduler) and does not make use of semaphores > > (but instead it pools its workers) that is why I suspect my usage of > > semaphores with VT. > > > > Also when I try to execute the vthread_summary command you suggested I > > get this error: > > java.lang.IllegalArgumentException: Unknown diagnostic command > Ah right, this jcmd is not in the older EA build so it can't be used > until you pick up a more recent EA build. > > -Alan > -- Kind regards, *Yuval Lombard* *Lead Software Engineer* +972.50.548.0111 yuval.l at securithings.com [image: logo_black.png] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo_black.png Type: image/png Size: 99833 bytes Desc: not available URL: From duke at openjdk.org Mon Jul 22 07:16:04 2024 From: duke at openjdk.org (duke) Date: Mon, 22 Jul 2024 07:16:04 GMT Subject: git: openjdk/loom: fibers: Cancel timer task in context of carrier Message-ID: <58aae46b-28f0-4a54-be56-4c2c0594193a@openjdk.org> Changeset: db80e44b Branch: fibers Author: Alan Bateman Date: 2024-07-22 08:07:10 +0000 URL: https://git.openjdk.org/loom/commit/db80e44b39d2f0ebfbc11877b7da7392be167077 Cancel timer task in context of carrier ! src/java.base/share/classes/java/lang/VirtualThread.java From Alan.Bateman at oracle.com Mon Jul 22 07:46:24 2024 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 22 Jul 2024 08:46:24 +0100 Subject: Experiencing an issue with ScheduledExecutorService alongside VT In-Reply-To: References: <3cdd7056-6321-4653-be4d-71bf5bea55e5@oracle.com> <213a86b9-2c9a-494f-9077-695008a48870@oracle.com> <6d928b93-8698-4546-9571-c7e00651ab3c@oracle.com> Message-ID: On 22/07/2024 07:09, Yuval Lombard wrote: > Hi Alan, > > Thanks for the clarifications! > OK regarding the pooling of the VT, now I understand what robert meant > about the partial code example. > > The scheduler?is created in this way: > ScheduledExecutorService scheduler = Executors.newScheduledThreadPool(1) > then as the code example shows after it is granted with a permit to > execute a task, it delegates it to the VT by starting it this way: > Thread.ofVirtual().start(() -> { ... } I read Robert's mail as a comment on the code fragment in your first mail. The finally block in that code fragment releases a permit unconditionally whereas I assume you only want to release if acquired in that thread. My comment is about thread dump you attached. Look at threads #73, #77 and #83 as examples. The stack traces suggests a SPTE using virtual threads as worker threads. It's nothing to do with the issue we are discussing here, just a comment that on a something surprising that you might want to look into. > I upgrade?the jdk to the latest EA and test it again, and get back to > you in any case with the relevant thread dumps. > Thanks. As I mentioned, I think this is related to preemption when cancelling a timer after Object.wait(millis). We may have to publish a new EA build. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From yuval.l at securithings.com Mon Jul 22 09:11:34 2024 From: yuval.l at securithings.com (Yuval Lombard) Date: Mon, 22 Jul 2024 12:11:34 +0300 Subject: Experiencing an issue with ScheduledExecutorService alongside VT In-Reply-To: References: <3cdd7056-6321-4653-be4d-71bf5bea55e5@oracle.com> <213a86b9-2c9a-494f-9077-695008a48870@oracle.com> <6d928b93-8698-4546-9571-c7e00651ab3c@oracle.com> Message-ID: Hi Alan, Thanks, sorry for the confusion, we also saw this odd release, and got read of it, it was just a side note btw, because I realized I did not attach how I have created my scheduler, so I elaborated on this as well. Just to make sure by SPTE what exactly do you mean? We are running into some difficulties now after upgrading to the latest EA based on jdk24 where most of our utilized framework's libs are not supporting it yet (Spring, and Spring-Boot) So if there is an older available EA build based on jdk23 that may be addressing one of the possible issues that may got us into this locking state, we will be happy to test it. Otherwise it will require some work from our end in order to try to package our app On Mon, 22 Jul 2024 at 10:46, Alan Bateman wrote: > On 22/07/2024 07:09, Yuval Lombard wrote: > > Hi Alan, > > Thanks for the clarifications! > OK regarding the pooling of the VT, now I understand what robert meant > about the partial code example. > > The scheduler is created in this way: > ScheduledExecutorService scheduler = Executors.newScheduledThreadPool(1) > then as the code example shows after it is granted with a permit to > execute a task, it delegates it to the VT by starting it this way: > Thread.ofVirtual().start(() -> { ... } > > > I read Robert's mail as a comment on the code fragment in your first mail. > The finally block in that code fragment releases a permit unconditionally > whereas I assume you only want to release if acquired in that thread. > > My comment is about thread dump you attached. Look at threads #73, #77 and > #83 as examples. The stack traces suggests a SPTE using virtual threads as > worker threads. It's nothing to do with the issue we are discussing here, > just a comment that on a something surprising that you might want to look > into. > > I upgrade the jdk to the latest EA and test it again, and get back to you > in any case with the relevant thread dumps. > > Thanks. As I mentioned, I think this is related to preemption when > cancelling a timer after Object.wait(millis). We may have to publish a new > EA build. > > -Alan > -- Kind regards, *Yuval Lombard* *Lead Software Engineer* +972.50.548.0111 yuval.l at securithings.com [image: logo_black.png] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo_black.png Type: image/png Size: 99833 bytes Desc: not available URL: From yuval.l at securithings.com Mon Jul 22 09:13:28 2024 From: yuval.l at securithings.com (Yuval Lombard) Date: Mon, 22 Jul 2024 12:13:28 +0300 Subject: Experiencing an issue with ScheduledExecutorService alongside VT In-Reply-To: References: <3cdd7056-6321-4653-be4d-71bf5bea55e5@oracle.com> <213a86b9-2c9a-494f-9077-695008a48870@oracle.com> <6d928b93-8698-4546-9571-c7e00651ab3c@oracle.com> Message-ID: Probably an executor, just want to make sure we are aligned :) On Mon, 22 Jul 2024 at 12:11, Yuval Lombard wrote: > Hi Alan, > > Thanks, sorry for the confusion, we also saw this odd release, and got > read of it, it was just a side note btw, because I realized I did not > attach how I have created my scheduler, so I elaborated on this as well. > > Just to make sure by SPTE what exactly do you mean? > > We are running into some difficulties now after upgrading to the latest EA > based on jdk24 where most of our utilized framework's libs are not > supporting it yet (Spring, and Spring-Boot) > So if there is an older available EA build based on jdk23 that may be > addressing one of the possible issues that may got us into this locking > state, we will be happy to test it. > Otherwise it will require some work from our end in order to try to > package our app > > > On Mon, 22 Jul 2024 at 10:46, Alan Bateman > wrote: > >> On 22/07/2024 07:09, Yuval Lombard wrote: >> >> Hi Alan, >> >> Thanks for the clarifications! >> OK regarding the pooling of the VT, now I understand what robert meant >> about the partial code example. >> >> The scheduler is created in this way: >> ScheduledExecutorService scheduler = Executors.newScheduledThreadPool(1) >> then as the code example shows after it is granted with a permit to >> execute a task, it delegates it to the VT by starting it this way: >> Thread.ofVirtual().start(() -> { ... } >> >> >> I read Robert's mail as a comment on the code fragment in your first >> mail. The finally block in that code fragment releases a permit >> unconditionally whereas I assume you only want to release if acquired in >> that thread. >> >> My comment is about thread dump you attached. Look at threads #73, #77 >> and #83 as examples. The stack traces suggests a SPTE using virtual threads >> as worker threads. It's nothing to do with the issue we are discussing >> here, just a comment that on a something surprising that you might want to >> look into. >> >> I upgrade the jdk to the latest EA and test it again, and get back to you >> in any case with the relevant thread dumps. >> >> Thanks. As I mentioned, I think this is related to preemption when >> cancelling a timer after Object.wait(millis). We may have to publish a new >> EA build. >> >> -Alan >> > > > -- > > Kind regards, > > *Yuval Lombard* > > *Lead Software Engineer* > > +972.50.548.0111 > > yuval.l at securithings.com > > [image: logo_black.png] > -- Kind regards, *Yuval Lombard* *Lead Software Engineer* +972.50.548.0111 yuval.l at securithings.com [image: logo_black.png] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo_black.png Type: image/png Size: 99833 bytes Desc: not available URL: From Alan.Bateman at oracle.com Mon Jul 22 09:52:26 2024 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 22 Jul 2024 10:52:26 +0100 Subject: Experiencing an issue with ScheduledExecutorService alongside VT In-Reply-To: References: <3cdd7056-6321-4653-be4d-71bf5bea55e5@oracle.com> <213a86b9-2c9a-494f-9077-695008a48870@oracle.com> <6d928b93-8698-4546-9571-c7e00651ab3c@oracle.com> Message-ID: <28d98b3a-85b5-4e40-a935-a3a6e93e745d@oracle.com> On 22/07/2024 10:11, Yuval Lombard wrote: > Hi Alan, > > Thanks, sorry for the confusion, we also saw this odd release, and got > read of it, it was just a side note btw, because I realized I did not > attach how I have created my scheduler, so I elaborated on this as well. > > Just to make sure by SPTE what exactly do you mean? I mean ScheduledThreadPoolExecutor (STPE), likely code calling Executors.newScheduledThreadPool with a ThreadFactory that creates virtual threads. > > We are running into some difficulties now after upgrading to the > latest EA based on jdk24 where most of our utilized framework's libs > are not supporting it yet (Spring, and Spring-Boot) > So if there is an older available EA build based on jdk23 that may be > addressing one of the possible issues that may got us into this > locking state, we will be happy to test it. > Otherwise it will require some work from our end in order to try to > package our app JDK main line, and the loom repo, moved to targeting JDK 24 in June and not really feasible to go back. There are Spring engineers testing EA builds from Project Leyden and those builds are also based on main line so there may be Spring builds that support JDK 24 EA builds. I realize it means testing a combination of EA bits. -Alan From imediava at gmail.com Mon Jul 22 11:30:04 2024 From: imediava at gmail.com (=?UTF-8?Q?I=C3=B1igo_Mediavilla?=) Date: Mon, 22 Jul 2024 13:30:04 +0200 Subject: JDK-8334085: Cannot reproduce failing test In-Reply-To: References: <77540540-0831-4a51-a061-7680dba35b96@oracle.com> Message-ID: Hello Serguei, Thanks a lot for sharing the update and for solving the issue. Do you think that you could help me understand exactly what's happening ? Based on the DBG output shared in JBS, my understanding is that what happens in the test is the following: Main Thread ------------------------- ---------------------------- 1. acquire java lock 2. starting thread 3. jni call 4. MonitorContendedEnter 5. release java lock 6. acquire java lock 7. MonitorContendedEntered 8. Thread in sync section 9. release java lock 10. why freeze doesn't pin ? What I'm struggling to understand is why after the thread releases the java lock, the virtual thread is still frozen, and specially why does it freeze while holding a jni monitor ? I've run tests locally trying to freeze a virtual thread holding a JNI lock and my virtual threads are always being pinned to the carrier with reason ("holding a lock"). Thanks in advance ??igo On Fri, Jul 19, 2024 at 10:41?PM Serguei Spitsyn wrote: > Hi I?igo, > > Patricio helped to reproduce this issue and also identified the problem > (please, see in the bug report). > The fix is a one-liner. I?ll post a PR after some mach5 testing. > > Thank you for involvement into this issue! > > Thanks, > > Serguei > > > > *From: *I?igo Mediavilla > *Date: *Saturday, July 13, 2024 at 12:08?AM > *To: *Chris Plummer > *Cc: *dholmes at openjdk.org , loom-dev at openjdk.org < > loom-dev at openjdk.org>, sspitsyn at openjdk.org > *Subject: *Re: JDK-8334085: Cannot reproduce failing test > > I see, in that case Serguei would you want to still own this JBS or would > you be OK if I try to have a look at it ? > > > > I?igo > > El vie, 12 jul 2024, 19:11, Chris Plummer > escribi?: > > Failures are very intermittent. We last saw a failure in our CI testing > on 2024-07-03. What command are you using to run the test? > > Chris > > On 7/12/24 2:34 AM, I?igo Mediavilla wrote: > > Hello, > > > > While looking at possible JBS tickets to work on, I saw JDK-8334085 > > where an assertion was reported to be failing for the > > GetOwnedMonitorInfoTest. Before I even asked around to wonder if this > > issue was already being looked at, I tried to reproduce the failure > > locally, but I don't manage to make the test fail. Is this still an > > issue in JDK-24 ? David can you still reproduce the failing test ? > > > > Best > > > > ??igo Mediavilla Saiz > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yuval.l at securithings.com Mon Jul 22 11:45:33 2024 From: yuval.l at securithings.com (Yuval Lombard) Date: Mon, 22 Jul 2024 14:45:33 +0300 Subject: Experiencing an issue with ScheduledExecutorService alongside VT In-Reply-To: <28d98b3a-85b5-4e40-a935-a3a6e93e745d@oracle.com> References: <3cdd7056-6321-4653-be4d-71bf5bea55e5@oracle.com> <213a86b9-2c9a-494f-9077-695008a48870@oracle.com> <6d928b93-8698-4546-9571-c7e00651ab3c@oracle.com> <28d98b3a-85b5-4e40-a935-a3a6e93e745d@oracle.com> Message-ID: Thanks Alan I will take a look into those builds On Mon, 22 Jul 2024 at 12:52, Alan Bateman wrote: > > > On 22/07/2024 10:11, Yuval Lombard wrote: > > Hi Alan, > > > > Thanks, sorry for the confusion, we also saw this odd release, and got > > read of it, it was just a side note btw, because I realized I did not > > attach how I have created my scheduler, so I elaborated on this as well. > > > > Just to make sure by SPTE what exactly do you mean? > I mean ScheduledThreadPoolExecutor (STPE), likely code calling > Executors.newScheduledThreadPool with a ThreadFactory that creates > virtual threads. > > > > > We are running into some difficulties now after upgrading to the > > latest EA based on jdk24 where most of our utilized framework's libs > > are not supporting it yet (Spring, and Spring-Boot) > > So if there is an older available EA build based on jdk23 that may be > > addressing one of the possible issues that may got us into this > > locking state, we will be happy to test it. > > Otherwise it will require some work from our end in order to try to > > package our app > > JDK main line, and the loom repo, moved to targeting JDK 24 in June and > not really feasible to go back. There are Spring engineers testing EA > builds from Project Leyden and those builds are also based on main line > so there may be Spring builds that support JDK 24 EA builds. I realize > it means testing a combination of EA bits. > > -Alan > -- Kind regards, *Yuval Lombard* *Lead Software Engineer* +972.50.548.0111 yuval.l at securithings.com [image: logo_black.png] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo_black.png Type: image/png Size: 99833 bytes Desc: not available URL: From patricio.chilano.mateo at oracle.com Mon Jul 22 14:11:29 2024 From: patricio.chilano.mateo at oracle.com (Patricio Chilano Mateo) Date: Mon, 22 Jul 2024 10:11:29 -0400 Subject: JDK-8334085: Cannot reproduce failing test In-Reply-To: References: <77540540-0831-4a51-a061-7680dba35b96@oracle.com> Message-ID: <03122653-89ff-9fc0-1c12-649504df1bea@oracle.com> Hi I?igo, The problem is that we can unmount a virtual thread, then mount it again, thaw a few frames, execute code that acquires a JNI monitor, and then call thaw again without releasing that monitor. Thaw code assumes all monitors must be released at that point but doesn't consider JNI acquired ones. In this test this will happen if the vthread is unmounted in?System.out.println("Thread doing JNI call: " ...)?because of contention with the main thread doing?System.out.println("Main waiting for event."). You can reproduce this issue by adding Thread.yield() before jniMonitorEnterAndLetObjectDie(). Thanks, Patricio On 7/22/24 7:30 AM, I?igo Mediavilla wrote: > Hello Serguei, > > Thanks a lot for sharing the update and for solving the issue. Do you > think that you could help me understand exactly what's happening ? > > Based on the DBG output shared in JBS, my understanding is that what > happens in the test is the following: > > Main ? ? ? ? ? ? ? ? ? ? ??? Thread > ------------------------- ? ---------------------------- > 1. acquire java lock > 2. starting thread > ? ? ? ? ? ? ? ? ? ? ? ? ? ?????? 3. jni call > ? ? ? ? ? ? ? ? ? ? ? ? ? ?????? 4. MonitorContendedEnter > 5. release java lock > ? ? ? ? ? ? ? ? ? ? ? ? ? ?????? 6. acquire java lock > ? ? ? ? ? ? ? ? ? ? ? ? ? ???? ? 7. MonitorContendedEntered > ? ? ? ? ? ? ? ? ? ? ? ? ? ?????? 8. Thread in sync section > ? ? ? ? ? ? ? ? ? ? ? ? ? ?????? 9. release java lock > ? ? ? ? ? ? ? ? ? ? ? ? ? ???? 10. why freeze doesn't pin ? > > What I'm struggling to understand is why after the thread releases the > java lock, the virtual thread is still frozen, and specially why does > it freeze while holding a jni monitor ? I've run tests locally trying > to freeze a virtual thread holding a JNI lock and my virtual threads > are always being pinned to the carrier with reason ("holding a lock"). > > Thanks in advance > > ??igo > > On Fri, Jul 19, 2024 at 10:41?PM Serguei Spitsyn > wrote: > > Hi I?igo, > > Patricio helped to reproduce this issue and also identified the > problem (please, see in the bug report). > The fix is a one-liner. I?ll post a PR after some mach5 testing. > > Thank you for involvement into this issue! > > Thanks, > > Serguei > > *From: *I?igo Mediavilla > *Date: *Saturday, July 13, 2024 at 12:08?AM > *To: *Chris Plummer > *Cc: *dholmes at openjdk.org , > loom-dev at openjdk.org , sspitsyn at openjdk.org > > *Subject: *Re: JDK-8334085: Cannot reproduce failing test > > I see, in that case Serguei would you want to still own this JBS > or would you be OK if I try to have a look at it ? > > I?igo > > El vie, 12 jul 2024, 19:11, Chris Plummer > escribi?: > > Failures are very intermittent. We last saw a failure in our > CI testing > on 2024-07-03. What command are you using to run the test? > > Chris > > On 7/12/24 2:34 AM, I?igo Mediavilla wrote: > > Hello, > > > > While looking at possible JBS tickets to work on, I saw > JDK-8334085 > > where an assertion was reported to be failing for the > > GetOwnedMonitorInfoTest. Before I even asked around to > wonder if this > > issue was already being looked at, I tried to reproduce the > failure > > locally, but I don't manage to make the test fail. Is this > still an > > issue in JDK-24 ? David can you still reproduce the failing > test ? > > > > Best > > > > ??igo Mediavilla Saiz > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yzheng at openjdk.org Mon Jul 22 16:06:21 2024 From: yzheng at openjdk.org (Yudi Zheng) Date: Mon, 22 Jul 2024 16:06:21 GMT Subject: RFR: Export JavaThread::_lock_id, ObjectMonitor::_stack_locker and markWord::marked_value. Message-ID: Essential exports for implementing fibers support in Graal. ------------- Commit messages: - Export JavaThread::_lock_id, ObjectMonitor::_stack_locker and markWord::marked_value. Changes: https://git.openjdk.org/loom/pull/211/files Webrev: https://webrevs.openjdk.org/?repo=loom&pr=211&range=00 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.org/loom/pull/211.diff Fetch: git fetch https://git.openjdk.org/loom.git pull/211/head:pull/211 PR: https://git.openjdk.org/loom/pull/211 From outsider404 at gmail.com Mon Jul 22 21:51:22 2024 From: outsider404 at gmail.com (Michal Domagala) Date: Mon, 22 Jul 2024 23:51:22 +0200 Subject: [External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: References: <12ACDD24-C874-45B1-9142-DACAB1E78956@oracle.com> <58e21790-551d-4717-ba16-17ccecbdaf22@oracle.com> <2F579C4D-B83F-4AC8-88BB-03723A34BD18@oracle.com> Message-ID: Thanks for the explanation. I understand that paragraph "Unlike platform thread stacks, virtual thread stacks are not GC roots. Thus the references they contain are not traversed in a stop-the-world pause by garbage collectors, such as G1, that perform concurrent heap scanning" can be rewritten as "Some GC, such as G1, marks GC roots in stop-the-world pause. Unlike platform thread stacks, virtual thread stacks are not GC roots, therefore they do not impact stop-the-world pause." In my opinion, the current paragraph in JEP 444 requires readers to have a deep GC background. Usually, developers are not aware of GC root cost (at least I was not aware). Developers could tune the number of GC roots by changing the number of platform threads. Others, like static variables, are rather not tunable. But usually, the OS limits the number of platform threads much more strictly than GC performance. To sum up, JEP 444's message is: "Do not be afraid of the G1 initial mark phase when using virtual threads". But I think most developers, like me, never heard about it. Ohers, more advanced, could also never care about it, because Oracle docs says about the initial mark phase: "This phase is piggybacked on a normal (STW) young garbage collection.". I understand this sentence as the phase is "for free". To sum up again: when a developer like me reads that VT is not GC root, he does not see G1 profit behind. He reads: VT is GC'able. And the current state, when behavior is different, is misleading. sob., 13 lip 2024 o 14:57 Ron Pressler napisa?(a): > > > > On 11 Jul 2024, at 19:40, Michal Domagala wrote: > > > > Where is the mistake in my reasoning? > > > > All objects in the heap, including virtual thread stacks, are traversed by > the GC. GC *roots*, however, are things that some GCs, G1 in particular, > traverse *in a stop-the-world-pause* while they don?t walk non-root objects > in a STW pause but concurrently with the application running. Furthermore, > roots are kept in memory even if there are no strong references to them, > while normal objects are kept only if there are strong references to them. > > Virtual threads, unlike platform threads, are regular heap objects rather > than roots. This makes a difference to *when* they are scanned by the GC, > which has an impact on GC performance, especially as there can be lots and > lots of virtual threads. Additionally, *if* there is no strong reference to > the virtual thread, the GC may collect it, but I pointed out that usually > there is a strong reference that is kept by default for observability > purposes, but you can change that option so that such a reference is not > kept. > > ? Ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From rengels at ix.netcom.com Mon Jul 22 22:24:00 2024 From: rengels at ix.netcom.com (robert engels) Date: Mon, 22 Jul 2024 17:24:00 -0500 Subject: [External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: References: <12ACDD24-C874-45B1-9142-DACAB1E78956@oracle.com> <58e21790-551d-4717-ba16-17ccecbdaf22@oracle.com> <2F579C4D-B83F-4AC8-88BB-03723A34BD18@oracle.com> Message-ID: <3DE96CF5-5879-4A28-9183-866DEC062E08@ix.netcom.com> But even if VT threads are not GC roots, a GC root must have a reference to them, right? (to the Loom team) Otherwise they would be immediately collected. If there is a reference to them, then that must follow up to a GC root (the static VT map), meaning that GC will still need to start from that root when tracing. I assume there could be low-level optimizations, where if a VT thread hasn?t run since the last GC, there is no need to follow it?s references because they could not have changed - but what if one of these references on its stack was a WeakReference? This would need clean-up since the clean-up handler might cause the VT or another to become Runnable. TL;DR; It feels to me that VT threads not being GC roots doesn?t matter - as something must hold a strong reference - but I suspect I am missing something. > On Jul 22, 2024, at 4:51 PM, Michal Domagala wrote: > > Thanks for the explanation. > > I understand that paragraph > > "Unlike platform thread stacks, virtual thread stacks are not GC roots. Thus the references they contain are not traversed in a stop-the-world pause by garbage collectors, such as G1, that perform concurrent heap scanning" > > can be rewritten as > > "Some GC, such as G1, marks GC roots in stop-the-world pause. Unlike platform thread stacks, virtual thread stacks are not GC roots, therefore they do not impact stop-the-world pause." > > In my opinion, the current paragraph in JEP 444 requires readers to have a deep GC background. Usually, developers are not aware of GC root cost (at least I was not aware). Developers could tune the number of GC roots by changing the number of platform threads. Others, like static variables, are rather not tunable. > But usually, the OS limits the number of platform threads much more strictly than GC performance. > > To sum up, JEP 444's message is: "Do not be afraid of the G1 initial mark phase when using virtual threads". But I think most developers, like me, never heard about it. Ohers, more advanced, could also never care about it, because Oracle docs says about the initial mark phase: "This phase is piggybacked on a normal (STW) young garbage collection.". I understand this sentence as the phase is "for free". > > To sum up again: when a developer like me reads that VT is not GC root, he does not see G1 profit behind. He reads: VT is GC'able. And the current state, when behavior is different, is misleading. > > sob., 13 lip 2024 o 14:57 Ron Pressler > napisa?(a): > > > > On 11 Jul 2024, at 19:40, Michal Domagala > wrote: > > > > Where is the mistake in my reasoning? > > > > All objects in the heap, including virtual thread stacks, are traversed by the GC. GC *roots*, however, are things that some GCs, G1 in particular, traverse *in a stop-the-world-pause* while they don?t walk non-root objects in a STW pause but concurrently with the application running. Furthermore, roots are kept in memory even if there are no strong references to them, while normal objects are kept only if there are strong references to them. > > Virtual threads, unlike platform threads, are regular heap objects rather than roots. This makes a difference to *when* they are scanned by the GC, which has an impact on GC performance, especially as there can be lots and lots of virtual threads. Additionally, *if* there is no strong reference to the virtual thread, the GC may collect it, but I pointed out that usually there is a strong reference that is kept by default for observability purposes, but you can change that option so that such a reference is not kept. > > ? Ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From aph-open at littlepinkcloud.com Tue Jul 23 09:07:19 2024 From: aph-open at littlepinkcloud.com (Andrew Haley) Date: Tue, 23 Jul 2024 10:07:19 +0100 Subject: [External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: <3DE96CF5-5879-4A28-9183-866DEC062E08@ix.netcom.com> References: <12ACDD24-C874-45B1-9142-DACAB1E78956@oracle.com> <58e21790-551d-4717-ba16-17ccecbdaf22@oracle.com> <2F579C4D-B83F-4AC8-88BB-03723A34BD18@oracle.com> <3DE96CF5-5879-4A28-9183-866DEC062E08@ix.netcom.com> Message-ID: <7d578f1e-f68d-4342-8190-a0466335a2e1@littlepinkcloud.com> On 7/22/24 23:24, robert engels wrote: > But even if VT threads are not GC roots, a GC root must have a reference > to them, right? Yes. > (to the Loom team) Otherwise they would be immediately collected. Which would be good, because if a virtual thread is not reachable from any root, then it will never run (because no one can reach it.) So let's immediately collect it. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From imediava at gmail.com Tue Jul 23 09:59:48 2024 From: imediava at gmail.com (=?UTF-8?Q?I=C3=B1igo_Mediavilla?=) Date: Tue, 23 Jul 2024 11:59:48 +0200 Subject: JDK-8334085: Cannot reproduce failing test In-Reply-To: <03122653-89ff-9fc0-1c12-649504df1bea@oracle.com> References: <77540540-0831-4a51-a061-7680dba35b96@oracle.com> <03122653-89ff-9fc0-1c12-649504df1bea@oracle.com> Message-ID: Hello Patricio, Thanks a lot for your explanation. Why is it safe for Thaw code to assume that all non-jni monitors will be released at that point, but the same assumption cannot be made for jni monitors ? What would happen if ? 1. A virtual thread is unmounted 2. We thaw a few frames and execute code that acquires a non-JNI monitor 3. We call thaw again Or is that not possible ? Thanks ??igo On Mon, Jul 22, 2024 at 4:11?PM Patricio Chilano Mateo < patricio.chilano.mateo at oracle.com> wrote: > Hi I?igo, > > The problem is that we can unmount a virtual thread, then mount it again, > thaw a few frames, execute code that acquires a JNI monitor, and then call > thaw again without releasing that monitor. Thaw code assumes all monitors > must be released at that point but doesn't consider JNI acquired ones. In > this test this will happen if the vthread is unmounted > in System.out.println("Thread doing JNI call: " ...) because of contention > with the main thread doing System.out.println("Main waiting for event."). > You can reproduce this issue by adding Thread.yield() before > jniMonitorEnterAndLetObjectDie(). > > Thanks, > Patricio > > On 7/22/24 7:30 AM, I?igo Mediavilla wrote: > > Hello Serguei, > > Thanks a lot for sharing the update and for solving the issue. Do you > think that you could help me understand exactly what's happening ? > > Based on the DBG output shared in JBS, my understanding is that what > happens in the test is the following: > > Main Thread > ------------------------- ---------------------------- > 1. acquire java lock > 2. starting thread > 3. jni call > 4. MonitorContendedEnter > 5. release java lock > 6. acquire java lock > 7. MonitorContendedEntered > 8. Thread in sync section > 9. release java lock > 10. why freeze doesn't pin ? > > What I'm struggling to understand is why after the thread releases the > java lock, the virtual thread is still frozen, and specially why does it > freeze while holding a jni monitor ? I've run tests locally trying to > freeze a virtual thread holding a JNI lock and my virtual threads are > always being pinned to the carrier with reason ("holding a lock"). > > Thanks in advance > > ??igo > > On Fri, Jul 19, 2024 at 10:41?PM Serguei Spitsyn < > serguei.spitsyn at oracle.com> wrote: > >> Hi I?igo, >> >> Patricio helped to reproduce this issue and also identified the problem >> (please, see in the bug report). >> The fix is a one-liner. I?ll post a PR after some mach5 testing. >> >> Thank you for involvement into this issue! >> >> Thanks, >> >> Serguei >> >> >> >> *From: *I?igo Mediavilla >> *Date: *Saturday, July 13, 2024 at 12:08?AM >> *To: *Chris Plummer >> *Cc: *dholmes at openjdk.org , loom-dev at openjdk.org < >> loom-dev at openjdk.org>, sspitsyn at openjdk.org >> *Subject: *Re: JDK-8334085: Cannot reproduce failing test >> >> I see, in that case Serguei would you want to still own this JBS or would >> you be OK if I try to have a look at it ? >> >> >> >> I?igo >> >> El vie, 12 jul 2024, 19:11, Chris Plummer >> escribi?: >> >> Failures are very intermittent. We last saw a failure in our CI testing >> on 2024-07-03. What command are you using to run the test? >> >> Chris >> >> On 7/12/24 2:34 AM, I?igo Mediavilla wrote: >> > Hello, >> > >> > While looking at possible JBS tickets to work on, I saw JDK-8334085 >> > where an assertion was reported to be failing for the >> > GetOwnedMonitorInfoTest. Before I even asked around to wonder if this >> > issue was already being looked at, I tried to reproduce the failure >> > locally, but I don't manage to make the test fail. Is this still an >> > issue in JDK-24 ? David can you still reproduce the failing test ? >> > >> > Best >> > >> > ??igo Mediavilla Saiz >> > >> > >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robaho at icloud.com Tue Jul 23 12:49:22 2024 From: robaho at icloud.com (robert engels) Date: Tue, 23 Jul 2024 07:49:22 -0500 Subject: [External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: <7d578f1e-f68d-4342-8190-a0466335a2e1@littlepinkcloud.com> References: <7d578f1e-f68d-4342-8190-a0466335a2e1@littlepinkcloud.com> Message-ID: Ok, but since the virtual thread scheduler needs to schedule them, they would always be reachable unless the reference used by the scheduler was outside GC or weak, and then though if they are not a GC root as soon as they are created they would be collected or the user code would need to keep a reference to every VT it creates. None of these cases feel like existing platform threads - nor do they feel easy to read on about. > On Jul 23, 2024, at 4:08?AM, Andrew Haley wrote: > > ?On 7/22/24 23:24, robert engels wrote: >> But even if VT threads are not GC roots, a GC root must have a reference >> to them, right? > > Yes. > >> (to the Loom team) Otherwise they would be immediately collected. > > Which would be good, because if a virtual thread is not reachable from any > root, then it will never run (because no one can reach it.) So let's > immediately collect it. > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > From ron.pressler at oracle.com Tue Jul 23 14:56:57 2024 From: ron.pressler at oracle.com (Ron Pressler) Date: Tue, 23 Jul 2024 14:56:57 +0000 Subject: [External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: References: <12ACDD24-C874-45B1-9142-DACAB1E78956@oracle.com> <58e21790-551d-4717-ba16-17ccecbdaf22@oracle.com> <2F579C4D-B83F-4AC8-88BB-03723A34BD18@oracle.com> Message-ID: <323FD2E4-4902-48BD-9F62-2A2836DB860B@oracle.com> > On 22 Jul 2024, at 22:51, Michal Domagala wrote: > > Thanks for the explanation. > > I understand that paragraph > > "Unlike platform thread stacks, virtual thread stacks are not GC roots. Thus the references they contain are not traversed in a stop-the-world pause by garbage collectors, such as G1, that perform concurrent heap scanning" > > can be rewritten as > > "Some GC, such as G1, marks GC roots in stop-the-world pause. Unlike platform thread stacks, virtual thread stacks are not GC roots, therefore they do not impact stop-the-world pause." > > In my opinion, the current paragraph in JEP 444 requires readers to have a deep GC background. Usually, developers are not aware of GC root cost (at least I was not aware). Developers could tune the number of GC roots by changing the number of platform threads. Others, like static variables, are rather not tunable. > But usually, the OS limits the number of platform threads much more strictly than GC performance. > > To sum up, JEP 444's message is: "Do not be afraid of the G1 initial mark phase when using virtual threads". But I think most developers, like me, never heard about it. Ohers, more advanced, could also never care about it, because Oracle docs says about the initial mark phase: "This phase is piggybacked on a normal (STW) young garbage collection.". I understand this sentence as the phase is "for free". > > To sum up again: when a developer like me reads that VT is not GC root, he does not see G1 profit behind. He reads: VT is GC'able. And the current state, when behavior is different, is misleading. A virtual thread *is* GCable, just like a String, when it is not strongly referenced. However, by default virtual threads will have a strong reference for observability, but you can turn that off. But, yes, the very notion of GC roots requires an advanced understanding of how the Java platform?s GCs work. I *think* that the very notion of GC roots is not part of the spec, but an implementation detail. No inference can be made, for any object, from whether or not it is a root, to when it will be collected. In fact, the platform?s GC make no guarantees as to when objects are collected, regardless of whether they?re roots or not. The only guarantee is that an object will not be collected if it is strongly reachable. ? Ron From patricio.chilano.mateo at oracle.com Tue Jul 23 16:09:16 2024 From: patricio.chilano.mateo at oracle.com (Patricio Chilano Mateo) Date: Tue, 23 Jul 2024 12:09:16 -0400 Subject: [External] : Re: JDK-8334085: Cannot reproduce failing test In-Reply-To: References: <77540540-0831-4a51-a061-7680dba35b96@oracle.com> <03122653-89ff-9fc0-1c12-649504df1bea@oracle.com> Message-ID: On 7/23/24 5:59 AM, I?igo Mediavilla wrote: > Hello Patricio, > > Thanks a lot for your explanation. > > Why is it safe for Thaw code to assume that all non-jni monitors will > be released at that point, but the same assumption cannot be made for > jni monitors ? > > What would happen if ? > > 1. A virtual thread is unmounted > 2. We thaw a few frames and execute code that acquires a non-JNI monitor > 3. We call thaw again > > Or is that not possible ? That would not be possible unless there is a bug. All monitors acquired from synchronized methods/blocks should have been released once execution of the synchronized method/block completes, either normally or abruptly (see [1]). Monitors that are acquired through JNI function MonitorEnter though are not automatically exited and a call to JNI function MonitorExit is required, unless DetachCurrentThread is used to implicitly release them (see [2]). [1] https://docs.oracle.com/javase/specs/jls/se22/html/jls-17.html#jls-17.1 [2] https://docs.oracle.com/en/java/javase/22/docs/specs/jni/functions.html#monitor-operations Patricio > Thanks > ??igo > > On Mon, Jul 22, 2024 at 4:11?PM Patricio Chilano Mateo > wrote: > > Hi I?igo, > > The problem is that we can unmount a virtual thread, then mount it > again, thaw a few frames, execute code that acquires a JNI > monitor, and then call thaw again without releasing that monitor. > Thaw code assumes all monitors must be released at that point but > doesn't consider JNI acquired ones. In this test this will happen > if the vthread is unmounted in?System.out.println("Thread doing > JNI call: " ...)?because of contention with the main thread > doing?System.out.println("Main waiting for event."). You can > reproduce this issue by adding Thread.yield() before > jniMonitorEnterAndLetObjectDie(). > > Thanks, > Patricio > > On 7/22/24 7:30 AM, I?igo Mediavilla wrote: >> Hello Serguei, >> >> Thanks a lot for sharing the update and for solving the issue. Do >> you think that you could help me understand exactly what's >> happening ? >> >> Based on the DBG output shared in JBS, my understanding is that >> what happens in the test is the following: >> >> Main ? ? ? ? ? ? ? ? ? ? ??? Thread >> ------------------------- ---------------------------- >> 1. acquire java lock >> 2. starting thread >> ? ? ? ? ? ? ? ? ? ? ? ? ? ?????? 3. jni call >> ? ? ? ? ? ? ? ? ? ? ? ? ? ?????? 4. MonitorContendedEnter >> 5. release java lock >> ? ? ? ? ? ? ? ? ? ? ? ? ? ?????? 6. acquire java lock >> ? ? ? ? ? ? ? ? ? ? ? ? ? ???? ? 7. MonitorContendedEntered >> ? ? ? ? ? ? ? ? ? ? ? ? ? ?????? 8. Thread in sync section >> ? ? ? ? ? ? ? ? ? ? ? ? ? ?????? 9. release java lock >> ? ? ? ? ? ? ? ? ? ? ? ? ? ???? 10. why freeze doesn't pin ? >> >> What I'm struggling to understand is why after the thread >> releases the java lock, the virtual thread is still frozen, and >> specially why does it freeze while holding a jni monitor ? I've >> run tests locally trying to freeze a virtual thread holding a JNI >> lock and my virtual threads are always being pinned to the >> carrier with reason ("holding a lock"). >> >> Thanks in advance >> >> ??igo >> >> On Fri, Jul 19, 2024 at 10:41?PM Serguei Spitsyn >> wrote: >> >> Hi I?igo, >> >> Patricio helped to reproduce this issue and also identified >> the problem (please, see in the bug report). >> The fix is a one-liner. I?ll post a PR after some mach5 testing. >> >> Thank you for involvement into this issue! >> >> Thanks, >> >> Serguei >> >> *From: *I?igo Mediavilla >> *Date: *Saturday, July 13, 2024 at 12:08?AM >> *To: *Chris Plummer >> *Cc: *dholmes at openjdk.org , >> loom-dev at openjdk.org , >> sspitsyn at openjdk.org >> *Subject: *Re: JDK-8334085: Cannot reproduce failing test >> >> I see, in that case Serguei would you want to still own this >> JBS or would you be OK if I try to have a look at it ? >> >> I?igo >> >> El vie, 12 jul 2024, 19:11, Chris Plummer >> escribi?: >> >> Failures are very intermittent. We last saw a failure in >> our CI testing >> on 2024-07-03. What command are you using to run the test? >> >> Chris >> >> On 7/12/24 2:34 AM, I?igo Mediavilla wrote: >> > Hello, >> > >> > While looking at possible JBS tickets to work on, I saw >> JDK-8334085 >> > where an assertion was reported to be failing for the >> > GetOwnedMonitorInfoTest. Before I even asked around to >> wonder if this >> > issue was already being looked at, I tried to reproduce >> the failure >> > locally, but I don't manage to make the test fail. Is >> this still an >> > issue in JDK-24 ? David can you still reproduce the >> failing test ? >> > >> > Best >> > >> > ??igo Mediavilla Saiz >> > >> > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Tue Jul 23 17:50:58 2024 From: duke at openjdk.org (duke) Date: Tue, 23 Jul 2024 17:50:58 GMT Subject: git: openjdk/loom: fibers: 33 new changesets Message-ID: <11a5e3f6-7d57-4032-bc62-3438fcc7eae7@openjdk.org> Changeset: c5b7af73 Branch: fibers Author: Vladimir Kozlov Date: 2024-07-20 15:41:29 +0000 URL: https://git.openjdk.org/loom/commit/c5b7af73d07f7458e970f5752eb75640562ddc7b 8336692: Redo fix for JDK-8284620 Reviewed-by: dlong ! src/hotspot/share/asm/codeBuffer.cpp Changeset: b21cb44e Branch: fibers Author: Aleksei Efimov Date: 2024-07-20 16:48:30 +0000 URL: https://git.openjdk.org/loom/commit/b21cb44e38ee8ea75e3a1c51e3a28388056a492d 8329398: Links in InetAddress class description show "#format" Reviewed-by: jpai ! src/java.base/share/classes/java/net/InetAddress.java Changeset: ad498f57 Branch: fibers Author: Christian Stein Date: 2024-07-21 08:49:16 +0000 URL: https://git.openjdk.org/loom/commit/ad498f57fcead174306c6e6e3b2d1f9916821b84 8335896: Source launcher should set TCCL Reviewed-by: alanb ! src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/MemoryContext.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/SourceLauncher.java ! test/langtools/tools/javac/launcher/SourceLauncherTest.java Changeset: fd741a88 Branch: fibers Author: Hai-May Chao Date: 2024-07-21 17:05:46 +0000 URL: https://git.openjdk.org/loom/commit/fd741a88e8bc73a9db6d4283bb54daab1760b442 8327538: The SSLExtension class specifies incorrect values for heartbeat per RFC 6520 and post_handshake_auth per RFC 8446 Reviewed-by: wetmore ! src/java.base/share/classes/sun/security/ssl/SSLExtension.java Changeset: 4da99158 Branch: fibers Author: lingjun.cg Date: 2024-07-22 02:01:08 +0000 URL: https://git.openjdk.org/loom/commit/4da99158754c25c5d0650f2d042aad3e94a9b0c5 8333396: Use StringBuilder internally for java.text.Format.* formatting Reviewed-by: naoto, liach, jlu ! src/java.base/share/classes/java/text/CharacterIteratorFieldDelegate.java ! src/java.base/share/classes/java/text/ChoiceFormat.java ! src/java.base/share/classes/java/text/CompactNumberFormat.java ! src/java.base/share/classes/java/text/DateFormat.java ! src/java.base/share/classes/java/text/DecimalFormat.java ! src/java.base/share/classes/java/text/DontCareFieldPosition.java ! src/java.base/share/classes/java/text/FieldPosition.java ! src/java.base/share/classes/java/text/Format.java ! src/java.base/share/classes/java/text/ListFormat.java ! src/java.base/share/classes/java/text/MessageFormat.java ! src/java.base/share/classes/java/text/NumberFormat.java ! src/java.base/share/classes/java/text/SimpleDateFormat.java + src/java.base/share/classes/java/text/StringBufFactory.java + test/micro/org/openjdk/bench/java/text/DateFormatterBench.java + test/micro/org/openjdk/bench/java/text/ListFormatterBench.java + test/micro/org/openjdk/bench/java/text/MessageFormatterBench.java Changeset: 0db6c15e Branch: fibers Author: Adam Sotona Date: 2024-07-22 07:33:29 +0000 URL: https://git.openjdk.org/loom/commit/0db6c15efe255bd313fb2b827d2ee05171e62ae9 8336833: Endless loop in Javap ClassWriter Reviewed-by: liach ! src/java.base/share/classes/jdk/internal/classfile/impl/AbstractInstruction.java ! test/jdk/jdk/classfile/LimitsTest.java Changeset: c1fdc04a Branch: fibers Author: Aggelos Biboudis Date: 2024-07-22 10:29:34 +0000 URL: https://git.openjdk.org/loom/commit/c1fdc04ad78e6e4712f2173370012106f9cc45ee 8336781: Erroneous exhaustivity check with boolean switch Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java + test/langtools/tools/javac/patterns/T8336781.java Changeset: 7ddd0259 Branch: fibers Author: Prasanta Sadhukhan Date: 2024-07-22 13:19:30 +0000 URL: https://git.openjdk.org/loom/commit/7ddd02599c4cb85fdc0a1f0a7c4ce37a09efe16e 4265389: JSplitPane does not support ComponentOrientation Reviewed-by: tr, abhiscxk ! src/java.desktop/share/classes/javax/swing/JSplitPane.java + test/jdk/javax/swing/JSplitPane/TestSplitPaneOrientationTest.java Changeset: 92de2b2d Branch: fibers Author: Nizar Benalla Committer: Chen Liang Date: 2024-07-22 13:27:12 +0000 URL: https://git.openjdk.org/loom/commit/92de2b2d5f21af38380b437af51e49c7ac142258 8336039: Doccheck: HTML warnings, broken links and missing files in java.base documentation Reviewed-by: liach, djelinski ! src/java.base/share/classes/java/lang/classfile/components/CodeStackTracker.java ! src/java.base/share/classes/java/lang/classfile/package-info.java ! src/java.base/share/classes/java/lang/foreign/Arena.java ! src/java.base/share/classes/java/lang/foreign/MemorySegment.java ! src/java.base/share/classes/java/lang/foreign/SymbolLookup.java ! src/java.base/share/classes/java/net/spi/InetAddressResolver.java ! src/java.base/share/classes/java/text/MessageFormat.java ! src/java.base/share/classes/javax/security/auth/Subject.java Changeset: c3226aae Branch: fibers Author: Weijun Wang Date: 2024-07-22 13:43:55 +0000 URL: https://git.openjdk.org/loom/commit/c3226aaeb810521257e961be5763552c86ee5651 8334394: Race condition in Class::protectionDomain Reviewed-by: liach, jpai, rriggs, alanb ! src/java.base/share/classes/java/lang/Class.java + test/jdk/java/lang/Class/ProtectionDomainRace.java Changeset: 0725eb1d Branch: fibers Author: Daniel Lund?n Date: 2024-07-22 14:41:40 +0000 URL: https://git.openjdk.org/loom/commit/0725eb1df2357bb0489e2521d96bb424fc233406 8336753: Don't run serviceability/sa/ClhsdbDumpheap.java with -Xcomp Reviewed-by: cjplummer, kvn, thartmann ! test/hotspot/jtreg/serviceability/sa/ClhsdbDumpheap.java Changeset: c740e1e3 Branch: fibers Author: Weijun Wang Date: 2024-07-22 16:00:40 +0000 URL: https://git.openjdk.org/loom/commit/c740e1e3b080d43cf9871853538f233843d1b81c 8333772: Incorrect Kerberos behavior when udp_preference_limit = 0 Reviewed-by: ssahoo, mullan ! src/java.security.jgss/share/classes/sun/security/krb5/KdcComm.java ! src/java.security.jgss/share/classes/sun/security/krb5/internal/Krb5.java ! test/jdk/sun/security/krb5/auto/KdcPolicy.java + test/jdk/sun/security/krb5/auto/RealmSpecificValues.java Changeset: 7ea77305 Branch: fibers Author: Kevin Walls Date: 2024-07-22 16:40:34 +0000 URL: https://git.openjdk.org/loom/commit/7ea773056433c467dbd321a0a063f4789552ef89 8332551: Test vmTestbase/nsk/monitoring/MemoryNotificationInfo/from/from001/TestDescription.java timed out Reviewed-by: sspitsyn, lmesnik ! test/hotspot/jtreg/vmTestbase/nsk/monitoring/MemoryNotificationInfo/from/from001.java ! test/hotspot/jtreg/vmTestbase/nsk/monitoring/MemoryNotificationInfo/from/from001/TestDescription.java Changeset: c1c97042 Branch: fibers Author: Naoto Sato Date: 2024-07-22 17:17:46 +0000 URL: https://git.openjdk.org/loom/commit/c1c9704268e9e651cd82c8550913d8ac60aa494a 8336479: Provide Process.waitFor(Duration) Reviewed-by: liach, jpai, rriggs ! src/java.base/share/classes/java/lang/Process.java + test/jdk/java/lang/Process/WaitForDuration.java ! test/lib/jdk/test/lib/process/ProcessTools.java Changeset: 8438c585 Branch: fibers Author: Liam Miller-Cushon Date: 2024-07-22 17:20:58 +0000 URL: https://git.openjdk.org/loom/commit/8438c5853f4ae5cef4e861cd0b3952371c886f45 8336844: ZipConstants64 defines duplicate constants EXTID_ZIP64 and ZIP64_EXTID Reviewed-by: jpai, vtewari, lancea ! src/java.base/share/classes/java/util/zip/ZipConstants64.java ! src/java.base/share/classes/java/util/zip/ZipFile.java ! src/java.base/share/classes/java/util/zip/ZipInputStream.java ! src/java.base/share/classes/java/util/zip/ZipOutputStream.java ! src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipConstants.java ! src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java Changeset: 31a85f17 Branch: fibers Author: Liam Miller-Cushon Date: 2024-07-22 17:25:42 +0000 URL: https://git.openjdk.org/loom/commit/31a85f17440ca0d791f694d670119ba8adc1ba7f 8336491: Unnecessary boxing conversions in void-returning lambdas Reviewed-by: mcimadamore ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java + test/langtools/tools/javac/lambda/VoidReturnBoxing.java Changeset: 34eea6a5 Branch: fibers Author: Henry Lin Committer: Aleksey Shipilev Date: 2024-07-22 17:29:12 +0000 URL: https://git.openjdk.org/loom/commit/34eea6a5fa27121bc0e9e8ace0894833d4a9f826 8333088: ubsan: shenandoahAdaptiveHeuristics.cpp:245:44: runtime error: division by zero Reviewed-by: shade, rkennke ! src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp Changeset: b5575942 Branch: fibers Author: Henry Lin Committer: Aleksey Shipilev Date: 2024-07-22 17:29:27 +0000 URL: https://git.openjdk.org/loom/commit/b5575942027281166676678e2081b024ec572644 8333728: ubsan: shenandoahFreeSet.cpp:1347:24: runtime error: division by zero Reviewed-by: shade, rkennke ! src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp Changeset: b144910e Branch: fibers Author: Chris Plummer Date: 2024-07-22 18:56:30 +0000 URL: https://git.openjdk.org/loom/commit/b144910ebb74be5a12dae57263f2a93452535f02 8334145: missing from vm_memory_map_.txt in System.dump_map help text Reviewed-by: dholmes, stuefe ! src/jdk.jcmd/share/man/jcmd.1 Changeset: ed649944 Branch: fibers Author: Chris Plummer Date: 2024-07-22 19:34:09 +0000 URL: https://git.openjdk.org/loom/commit/ed6499446dadc339599271a282ceca4a52dbeed4 8333391: Test com/sun/jdi/InterruptHangTest.java failed: Thread was never interrupted during sleep Reviewed-by: lmesnik, amenkov ! test/jdk/com/sun/jdi/InterruptHangTest.java Changeset: d63d6e23 Branch: fibers Author: Weijun Wang Date: 2024-07-22 22:17:43 +0000 URL: https://git.openjdk.org/loom/commit/d63d6e23d123e82cef1372aed31b5846fb6d23fd 8336935: Test sun/security/krb5/auto/RealmSpecificValues.java fails: java.lang.RuntimeException: Should not reach here Reviewed-by: hchao, dholmes ! test/jdk/sun/security/krb5/auto/RealmSpecificValues.java Changeset: 96e4a187 Branch: fibers Author: Chen Liang Date: 2024-07-22 22:53:52 +0000 URL: https://git.openjdk.org/loom/commit/96e4a1876a3ab0819c017ba9b634711fe19e58c3 8304929: MethodTypeDesc throws an unchecked exception than ReflectiveOperationException when a component class cannot be resolved Reviewed-by: jvernee ! src/java.base/share/classes/jdk/internal/constant/MethodTypeDescImpl.java ! test/jdk/java/lang/constant/MethodTypeDescTest.java Changeset: aabec4a9 Branch: fibers Author: Chen Liang Date: 2024-07-22 22:54:36 +0000 URL: https://git.openjdk.org/loom/commit/aabec4a947ed2a808a1443fa6b2dabedd8c2dd9f 8335922: Incorrect @Stable usage of LambdaForm$Name.index Reviewed-by: jvernee, shade ! src/java.base/share/classes/java/lang/invoke/LambdaForm.java Changeset: 22914e07 Branch: fibers Author: Chen Liang Date: 2024-07-23 04:59:58 +0000 URL: https://git.openjdk.org/loom/commit/22914e0774f5bb8ded3d825bea1dc312b12d4d4a 8335938: Review XxxBuilder.original and XxxModel.parent Reviewed-by: asotona ! src/java.base/share/classes/java/lang/classfile/ClassBuilder.java ! src/java.base/share/classes/java/lang/classfile/CodeBuilder.java ! src/java.base/share/classes/java/lang/classfile/FieldBuilder.java ! src/java.base/share/classes/java/lang/classfile/MethodBuilder.java ! src/java.base/share/classes/jdk/internal/classfile/impl/AbstractDirectBuilder.java ! src/java.base/share/classes/jdk/internal/classfile/impl/BufferedCodeBuilder.java ! src/java.base/share/classes/jdk/internal/classfile/impl/BufferedFieldBuilder.java ! src/java.base/share/classes/jdk/internal/classfile/impl/BufferedMethodBuilder.java ! src/java.base/share/classes/jdk/internal/classfile/impl/ChainedClassBuilder.java ! src/java.base/share/classes/jdk/internal/classfile/impl/ChainedFieldBuilder.java ! src/java.base/share/classes/jdk/internal/classfile/impl/ChainedMethodBuilder.java ! src/java.base/share/classes/jdk/internal/classfile/impl/NonterminalCodeBuilder.java Changeset: 9f03f687 Branch: fibers Author: Alan Bateman Date: 2024-07-23 05:13:49 +0000 URL: https://git.openjdk.org/loom/commit/9f03f687556ee61436a1cb8c89ff063a7cbeaa51 8336339: (se) SelectionKey.interestOps(int) should not throw ClosedSelectorException Reviewed-by: jpai, bpb ! src/java.base/linux/classes/sun/nio/ch/EPollSelectorImpl.java ! src/java.base/macosx/classes/sun/nio/ch/KQueueSelectorImpl.java ! src/java.base/share/classes/java/nio/channels/spi/AbstractSelectableChannel.java ! src/java.base/share/classes/sun/nio/ch/SelectorImpl.java ! src/java.base/unix/classes/sun/nio/ch/PollSelectorImpl.java ! src/java.base/windows/classes/sun/nio/ch/WEPollSelectorImpl.java ! src/java.base/windows/classes/sun/nio/ch/WindowsSelectorImpl.java + test/jdk/java/nio/channels/Selector/RaceUpdatesAndClose.java Changeset: 48030a2a Branch: fibers Author: SendaoYan Committer: Fei Yang Date: 2024-07-23 05:23:48 +0000 URL: https://git.openjdk.org/loom/commit/48030a2a8670e6274abb6c77f19dd3d92517e888 8336855: Duplicate protected declaration and comment in interp_masm_aarch64.hpp Reviewed-by: jiefu, shade ! src/hotspot/cpu/aarch64/interp_masm_aarch64.hpp Changeset: 4c7b3e7f Branch: fibers Author: Raffaello Giulietti Date: 2024-07-23 07:43:57 +0000 URL: https://git.openjdk.org/loom/commit/4c7b3e7fc39a06e208ea1668095d055457549d63 8334758: Incorrect note in Javadoc for a few RandomGenerator methods Reviewed-by: bpb ! src/java.base/share/classes/java/util/random/RandomGenerator.java Changeset: e83b4b23 Branch: fibers Author: Claes Redestad Date: 2024-07-23 11:50:57 +0000 URL: https://git.openjdk.org/loom/commit/e83b4b236eca48d0b75094006f7f888398194fe4 8335182: Consolidate and streamline String concat code shapes Reviewed-by: liach, jvernee ! src/java.base/share/classes/java/lang/StringConcatHelper.java ! src/java.base/share/classes/java/lang/System.java ! src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java ! src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java ! test/micro/org/openjdk/bench/java/lang/StringConcat.java + test/micro/org/openjdk/bench/java/lang/StringConcatStartup.java Changeset: a2a236f9 Branch: fibers Author: Chen Liang Date: 2024-07-23 12:11:47 +0000 URL: https://git.openjdk.org/loom/commit/a2a236f9041083e4b8f11e068da0031dd5f52c2b 8335939: Hide element writing across the ClassFile API Reviewed-by: asotona ! src/java.base/share/classes/java/lang/classfile/Annotation.java ! src/java.base/share/classes/java/lang/classfile/AnnotationElement.java ! src/java.base/share/classes/java/lang/classfile/AnnotationValue.java ! src/java.base/share/classes/java/lang/classfile/Attribute.java ! src/java.base/share/classes/java/lang/classfile/BootstrapMethodEntry.java ! src/java.base/share/classes/java/lang/classfile/BufWriter.java ! src/java.base/share/classes/java/lang/classfile/ClassFileElement.java ! src/java.base/share/classes/java/lang/classfile/ClassReader.java ! src/java.base/share/classes/java/lang/classfile/CustomAttribute.java ! src/java.base/share/classes/java/lang/classfile/FieldModel.java ! src/java.base/share/classes/java/lang/classfile/MethodModel.java - src/java.base/share/classes/java/lang/classfile/WritableElement.java ! src/java.base/share/classes/java/lang/classfile/constantpool/ConstantPoolBuilder.java ! src/java.base/share/classes/java/lang/classfile/constantpool/PoolEntry.java ! src/java.base/share/classes/java/lang/classfile/instruction/LocalVariable.java ! src/java.base/share/classes/java/lang/classfile/instruction/LocalVariableType.java ! src/java.base/share/classes/jdk/internal/classfile/impl/AbstractAttributeMapper.java ! src/java.base/share/classes/jdk/internal/classfile/impl/AbstractBoundLocalVariable.java ! src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java ! src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPseudoInstruction.java ! src/java.base/share/classes/jdk/internal/classfile/impl/AbstractUnboundModel.java ! src/java.base/share/classes/jdk/internal/classfile/impl/AnnotationImpl.java ! src/java.base/share/classes/jdk/internal/classfile/impl/AnnotationReader.java ! src/java.base/share/classes/jdk/internal/classfile/impl/AttributeHolder.java ! src/java.base/share/classes/jdk/internal/classfile/impl/BootstrapMethodEntryImpl.java ! src/java.base/share/classes/jdk/internal/classfile/impl/BoundAttribute.java ! src/java.base/share/classes/jdk/internal/classfile/impl/BufWriterImpl.java ! src/java.base/share/classes/jdk/internal/classfile/impl/BufferedCodeBuilder.java ! src/java.base/share/classes/jdk/internal/classfile/impl/BufferedFieldBuilder.java ! src/java.base/share/classes/jdk/internal/classfile/impl/BufferedMethodBuilder.java ! src/java.base/share/classes/jdk/internal/classfile/impl/ClassReaderImpl.java ! src/java.base/share/classes/jdk/internal/classfile/impl/CodeImpl.java ! src/java.base/share/classes/jdk/internal/classfile/impl/DirectClassBuilder.java ! src/java.base/share/classes/jdk/internal/classfile/impl/DirectCodeBuilder.java ! src/java.base/share/classes/jdk/internal/classfile/impl/DirectFieldBuilder.java ! src/java.base/share/classes/jdk/internal/classfile/impl/DirectMethodBuilder.java ! src/java.base/share/classes/jdk/internal/classfile/impl/FieldImpl.java ! src/java.base/share/classes/jdk/internal/classfile/impl/MethodImpl.java ! src/java.base/share/classes/jdk/internal/classfile/impl/SplitConstantPool.java ! src/java.base/share/classes/jdk/internal/classfile/impl/StackCounter.java ! src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java ! src/java.base/share/classes/jdk/internal/classfile/impl/TemporaryConstantPool.java ! src/java.base/share/classes/jdk/internal/classfile/impl/UnboundAttribute.java ! src/java.base/share/classes/jdk/internal/classfile/impl/Util.java ! test/jdk/jdk/classfile/BoundAttributeTest.java ! test/jdk/jdk/classfile/CorpusTest.java ! test/jdk/jdk/classfile/LimitsTest.java ! test/jdk/jdk/classfile/LowAdaptTest.java ! test/jdk/jdk/classfile/VerifierSelfTest.java ! test/langtools/tools/javac/classfiles/attributes/AnnotationDefault/AnnotationDefaultVerifier.java Changeset: 0e555b5d Branch: fibers Author: Athijegannathan Sundararajan Date: 2024-07-23 12:22:53 +0000 URL: https://git.openjdk.org/loom/commit/0e555b5ded819cc3b363673320dc848c321861ce 8204582: Extra spaces in jlink documentation make it incorrect. Reviewed-by: alanb ! src/jdk.jlink/share/man/jlink.1 Changeset: 6498af15 Branch: fibers Author: Alan Bateman Date: 2024-07-23 14:23:30 +0000 URL: https://git.openjdk.org/loom/commit/6498af153e22c27fc8bd16f9dcf50866b1948f92 Merge ! src/java.base/linux/classes/sun/nio/ch/EPollSelectorImpl.java ! src/java.base/macosx/classes/sun/nio/ch/KQueueSelectorImpl.java ! src/java.base/share/classes/java/lang/System.java ! src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java ! src/java.base/linux/classes/sun/nio/ch/EPollSelectorImpl.java ! src/java.base/macosx/classes/sun/nio/ch/KQueueSelectorImpl.java ! src/java.base/share/classes/java/lang/System.java ! src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java Changeset: d2f63cda Branch: fibers Author: Alan Bateman Date: 2024-07-23 12:29:06 +0000 URL: https://git.openjdk.org/loom/commit/d2f63cdac6ab10327b816d9014042d7a4be48065 cancelWaitTimeout need only pin, add test ! src/java.base/share/classes/java/lang/VirtualThread.java + test/jdk/java/lang/Thread/virtual/CancelTimerWithContention.java Changeset: 9d633a3e Branch: fibers Author: Alan Bateman Date: 2024-07-23 14:23:47 +0000 URL: https://git.openjdk.org/loom/commit/9d633a3e3907766ac004b27991981c132939f460 Merge From duke at openjdk.org Tue Jul 23 17:52:43 2024 From: duke at openjdk.org (duke) Date: Tue, 23 Jul 2024 17:52:43 GMT Subject: git: openjdk/loom: master: 30 new changesets Message-ID: Changeset: c5b7af73 Branch: master Author: Vladimir Kozlov Date: 2024-07-20 15:41:29 +0000 URL: https://git.openjdk.org/loom/commit/c5b7af73d07f7458e970f5752eb75640562ddc7b 8336692: Redo fix for JDK-8284620 Reviewed-by: dlong ! src/hotspot/share/asm/codeBuffer.cpp Changeset: b21cb44e Branch: master Author: Aleksei Efimov Date: 2024-07-20 16:48:30 +0000 URL: https://git.openjdk.org/loom/commit/b21cb44e38ee8ea75e3a1c51e3a28388056a492d 8329398: Links in InetAddress class description show "#format" Reviewed-by: jpai ! src/java.base/share/classes/java/net/InetAddress.java Changeset: ad498f57 Branch: master Author: Christian Stein Date: 2024-07-21 08:49:16 +0000 URL: https://git.openjdk.org/loom/commit/ad498f57fcead174306c6e6e3b2d1f9916821b84 8335896: Source launcher should set TCCL Reviewed-by: alanb ! src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/MemoryContext.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/SourceLauncher.java ! test/langtools/tools/javac/launcher/SourceLauncherTest.java Changeset: fd741a88 Branch: master Author: Hai-May Chao Date: 2024-07-21 17:05:46 +0000 URL: https://git.openjdk.org/loom/commit/fd741a88e8bc73a9db6d4283bb54daab1760b442 8327538: The SSLExtension class specifies incorrect values for heartbeat per RFC 6520 and post_handshake_auth per RFC 8446 Reviewed-by: wetmore ! src/java.base/share/classes/sun/security/ssl/SSLExtension.java Changeset: 4da99158 Branch: master Author: lingjun.cg Date: 2024-07-22 02:01:08 +0000 URL: https://git.openjdk.org/loom/commit/4da99158754c25c5d0650f2d042aad3e94a9b0c5 8333396: Use StringBuilder internally for java.text.Format.* formatting Reviewed-by: naoto, liach, jlu ! src/java.base/share/classes/java/text/CharacterIteratorFieldDelegate.java ! src/java.base/share/classes/java/text/ChoiceFormat.java ! src/java.base/share/classes/java/text/CompactNumberFormat.java ! src/java.base/share/classes/java/text/DateFormat.java ! src/java.base/share/classes/java/text/DecimalFormat.java ! src/java.base/share/classes/java/text/DontCareFieldPosition.java ! src/java.base/share/classes/java/text/FieldPosition.java ! src/java.base/share/classes/java/text/Format.java ! src/java.base/share/classes/java/text/ListFormat.java ! src/java.base/share/classes/java/text/MessageFormat.java ! src/java.base/share/classes/java/text/NumberFormat.java ! src/java.base/share/classes/java/text/SimpleDateFormat.java + src/java.base/share/classes/java/text/StringBufFactory.java + test/micro/org/openjdk/bench/java/text/DateFormatterBench.java + test/micro/org/openjdk/bench/java/text/ListFormatterBench.java + test/micro/org/openjdk/bench/java/text/MessageFormatterBench.java Changeset: 0db6c15e Branch: master Author: Adam Sotona Date: 2024-07-22 07:33:29 +0000 URL: https://git.openjdk.org/loom/commit/0db6c15efe255bd313fb2b827d2ee05171e62ae9 8336833: Endless loop in Javap ClassWriter Reviewed-by: liach ! src/java.base/share/classes/jdk/internal/classfile/impl/AbstractInstruction.java ! test/jdk/jdk/classfile/LimitsTest.java Changeset: c1fdc04a Branch: master Author: Aggelos Biboudis Date: 2024-07-22 10:29:34 +0000 URL: https://git.openjdk.org/loom/commit/c1fdc04ad78e6e4712f2173370012106f9cc45ee 8336781: Erroneous exhaustivity check with boolean switch Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java + test/langtools/tools/javac/patterns/T8336781.java Changeset: 7ddd0259 Branch: master Author: Prasanta Sadhukhan Date: 2024-07-22 13:19:30 +0000 URL: https://git.openjdk.org/loom/commit/7ddd02599c4cb85fdc0a1f0a7c4ce37a09efe16e 4265389: JSplitPane does not support ComponentOrientation Reviewed-by: tr, abhiscxk ! src/java.desktop/share/classes/javax/swing/JSplitPane.java + test/jdk/javax/swing/JSplitPane/TestSplitPaneOrientationTest.java Changeset: 92de2b2d Branch: master Author: Nizar Benalla Committer: Chen Liang Date: 2024-07-22 13:27:12 +0000 URL: https://git.openjdk.org/loom/commit/92de2b2d5f21af38380b437af51e49c7ac142258 8336039: Doccheck: HTML warnings, broken links and missing files in java.base documentation Reviewed-by: liach, djelinski ! src/java.base/share/classes/java/lang/classfile/components/CodeStackTracker.java ! src/java.base/share/classes/java/lang/classfile/package-info.java ! src/java.base/share/classes/java/lang/foreign/Arena.java ! src/java.base/share/classes/java/lang/foreign/MemorySegment.java ! src/java.base/share/classes/java/lang/foreign/SymbolLookup.java ! src/java.base/share/classes/java/net/spi/InetAddressResolver.java ! src/java.base/share/classes/java/text/MessageFormat.java ! src/java.base/share/classes/javax/security/auth/Subject.java Changeset: c3226aae Branch: master Author: Weijun Wang Date: 2024-07-22 13:43:55 +0000 URL: https://git.openjdk.org/loom/commit/c3226aaeb810521257e961be5763552c86ee5651 8334394: Race condition in Class::protectionDomain Reviewed-by: liach, jpai, rriggs, alanb ! src/java.base/share/classes/java/lang/Class.java + test/jdk/java/lang/Class/ProtectionDomainRace.java Changeset: 0725eb1d Branch: master Author: Daniel Lund?n Date: 2024-07-22 14:41:40 +0000 URL: https://git.openjdk.org/loom/commit/0725eb1df2357bb0489e2521d96bb424fc233406 8336753: Don't run serviceability/sa/ClhsdbDumpheap.java with -Xcomp Reviewed-by: cjplummer, kvn, thartmann ! test/hotspot/jtreg/serviceability/sa/ClhsdbDumpheap.java Changeset: c740e1e3 Branch: master Author: Weijun Wang Date: 2024-07-22 16:00:40 +0000 URL: https://git.openjdk.org/loom/commit/c740e1e3b080d43cf9871853538f233843d1b81c 8333772: Incorrect Kerberos behavior when udp_preference_limit = 0 Reviewed-by: ssahoo, mullan ! src/java.security.jgss/share/classes/sun/security/krb5/KdcComm.java ! src/java.security.jgss/share/classes/sun/security/krb5/internal/Krb5.java ! test/jdk/sun/security/krb5/auto/KdcPolicy.java + test/jdk/sun/security/krb5/auto/RealmSpecificValues.java Changeset: 7ea77305 Branch: master Author: Kevin Walls Date: 2024-07-22 16:40:34 +0000 URL: https://git.openjdk.org/loom/commit/7ea773056433c467dbd321a0a063f4789552ef89 8332551: Test vmTestbase/nsk/monitoring/MemoryNotificationInfo/from/from001/TestDescription.java timed out Reviewed-by: sspitsyn, lmesnik ! test/hotspot/jtreg/vmTestbase/nsk/monitoring/MemoryNotificationInfo/from/from001.java ! test/hotspot/jtreg/vmTestbase/nsk/monitoring/MemoryNotificationInfo/from/from001/TestDescription.java Changeset: c1c97042 Branch: master Author: Naoto Sato Date: 2024-07-22 17:17:46 +0000 URL: https://git.openjdk.org/loom/commit/c1c9704268e9e651cd82c8550913d8ac60aa494a 8336479: Provide Process.waitFor(Duration) Reviewed-by: liach, jpai, rriggs ! src/java.base/share/classes/java/lang/Process.java + test/jdk/java/lang/Process/WaitForDuration.java ! test/lib/jdk/test/lib/process/ProcessTools.java Changeset: 8438c585 Branch: master Author: Liam Miller-Cushon Date: 2024-07-22 17:20:58 +0000 URL: https://git.openjdk.org/loom/commit/8438c5853f4ae5cef4e861cd0b3952371c886f45 8336844: ZipConstants64 defines duplicate constants EXTID_ZIP64 and ZIP64_EXTID Reviewed-by: jpai, vtewari, lancea ! src/java.base/share/classes/java/util/zip/ZipConstants64.java ! src/java.base/share/classes/java/util/zip/ZipFile.java ! src/java.base/share/classes/java/util/zip/ZipInputStream.java ! src/java.base/share/classes/java/util/zip/ZipOutputStream.java ! src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipConstants.java ! src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java Changeset: 31a85f17 Branch: master Author: Liam Miller-Cushon Date: 2024-07-22 17:25:42 +0000 URL: https://git.openjdk.org/loom/commit/31a85f17440ca0d791f694d670119ba8adc1ba7f 8336491: Unnecessary boxing conversions in void-returning lambdas Reviewed-by: mcimadamore ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java + test/langtools/tools/javac/lambda/VoidReturnBoxing.java Changeset: 34eea6a5 Branch: master Author: Henry Lin Committer: Aleksey Shipilev Date: 2024-07-22 17:29:12 +0000 URL: https://git.openjdk.org/loom/commit/34eea6a5fa27121bc0e9e8ace0894833d4a9f826 8333088: ubsan: shenandoahAdaptiveHeuristics.cpp:245:44: runtime error: division by zero Reviewed-by: shade, rkennke ! src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp Changeset: b5575942 Branch: master Author: Henry Lin Committer: Aleksey Shipilev Date: 2024-07-22 17:29:27 +0000 URL: https://git.openjdk.org/loom/commit/b5575942027281166676678e2081b024ec572644 8333728: ubsan: shenandoahFreeSet.cpp:1347:24: runtime error: division by zero Reviewed-by: shade, rkennke ! src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp Changeset: b144910e Branch: master Author: Chris Plummer Date: 2024-07-22 18:56:30 +0000 URL: https://git.openjdk.org/loom/commit/b144910ebb74be5a12dae57263f2a93452535f02 8334145: missing from vm_memory_map_.txt in System.dump_map help text Reviewed-by: dholmes, stuefe ! src/jdk.jcmd/share/man/jcmd.1 Changeset: ed649944 Branch: master Author: Chris Plummer Date: 2024-07-22 19:34:09 +0000 URL: https://git.openjdk.org/loom/commit/ed6499446dadc339599271a282ceca4a52dbeed4 8333391: Test com/sun/jdi/InterruptHangTest.java failed: Thread was never interrupted during sleep Reviewed-by: lmesnik, amenkov ! test/jdk/com/sun/jdi/InterruptHangTest.java Changeset: d63d6e23 Branch: master Author: Weijun Wang Date: 2024-07-22 22:17:43 +0000 URL: https://git.openjdk.org/loom/commit/d63d6e23d123e82cef1372aed31b5846fb6d23fd 8336935: Test sun/security/krb5/auto/RealmSpecificValues.java fails: java.lang.RuntimeException: Should not reach here Reviewed-by: hchao, dholmes ! test/jdk/sun/security/krb5/auto/RealmSpecificValues.java Changeset: 96e4a187 Branch: master Author: Chen Liang Date: 2024-07-22 22:53:52 +0000 URL: https://git.openjdk.org/loom/commit/96e4a1876a3ab0819c017ba9b634711fe19e58c3 8304929: MethodTypeDesc throws an unchecked exception than ReflectiveOperationException when a component class cannot be resolved Reviewed-by: jvernee ! src/java.base/share/classes/jdk/internal/constant/MethodTypeDescImpl.java ! test/jdk/java/lang/constant/MethodTypeDescTest.java Changeset: aabec4a9 Branch: master Author: Chen Liang Date: 2024-07-22 22:54:36 +0000 URL: https://git.openjdk.org/loom/commit/aabec4a947ed2a808a1443fa6b2dabedd8c2dd9f 8335922: Incorrect @Stable usage of LambdaForm$Name.index Reviewed-by: jvernee, shade ! src/java.base/share/classes/java/lang/invoke/LambdaForm.java Changeset: 22914e07 Branch: master Author: Chen Liang Date: 2024-07-23 04:59:58 +0000 URL: https://git.openjdk.org/loom/commit/22914e0774f5bb8ded3d825bea1dc312b12d4d4a 8335938: Review XxxBuilder.original and XxxModel.parent Reviewed-by: asotona ! src/java.base/share/classes/java/lang/classfile/ClassBuilder.java ! src/java.base/share/classes/java/lang/classfile/CodeBuilder.java ! src/java.base/share/classes/java/lang/classfile/FieldBuilder.java ! src/java.base/share/classes/java/lang/classfile/MethodBuilder.java ! src/java.base/share/classes/jdk/internal/classfile/impl/AbstractDirectBuilder.java ! src/java.base/share/classes/jdk/internal/classfile/impl/BufferedCodeBuilder.java ! src/java.base/share/classes/jdk/internal/classfile/impl/BufferedFieldBuilder.java ! src/java.base/share/classes/jdk/internal/classfile/impl/BufferedMethodBuilder.java ! src/java.base/share/classes/jdk/internal/classfile/impl/ChainedClassBuilder.java ! src/java.base/share/classes/jdk/internal/classfile/impl/ChainedFieldBuilder.java ! src/java.base/share/classes/jdk/internal/classfile/impl/ChainedMethodBuilder.java ! src/java.base/share/classes/jdk/internal/classfile/impl/NonterminalCodeBuilder.java Changeset: 9f03f687 Branch: master Author: Alan Bateman Date: 2024-07-23 05:13:49 +0000 URL: https://git.openjdk.org/loom/commit/9f03f687556ee61436a1cb8c89ff063a7cbeaa51 8336339: (se) SelectionKey.interestOps(int) should not throw ClosedSelectorException Reviewed-by: jpai, bpb ! src/java.base/linux/classes/sun/nio/ch/EPollSelectorImpl.java ! src/java.base/macosx/classes/sun/nio/ch/KQueueSelectorImpl.java ! src/java.base/share/classes/java/nio/channels/spi/AbstractSelectableChannel.java ! src/java.base/share/classes/sun/nio/ch/SelectorImpl.java ! src/java.base/unix/classes/sun/nio/ch/PollSelectorImpl.java ! src/java.base/windows/classes/sun/nio/ch/WEPollSelectorImpl.java ! src/java.base/windows/classes/sun/nio/ch/WindowsSelectorImpl.java + test/jdk/java/nio/channels/Selector/RaceUpdatesAndClose.java Changeset: 48030a2a Branch: master Author: SendaoYan Committer: Fei Yang Date: 2024-07-23 05:23:48 +0000 URL: https://git.openjdk.org/loom/commit/48030a2a8670e6274abb6c77f19dd3d92517e888 8336855: Duplicate protected declaration and comment in interp_masm_aarch64.hpp Reviewed-by: jiefu, shade ! src/hotspot/cpu/aarch64/interp_masm_aarch64.hpp Changeset: 4c7b3e7f Branch: master Author: Raffaello Giulietti Date: 2024-07-23 07:43:57 +0000 URL: https://git.openjdk.org/loom/commit/4c7b3e7fc39a06e208ea1668095d055457549d63 8334758: Incorrect note in Javadoc for a few RandomGenerator methods Reviewed-by: bpb ! src/java.base/share/classes/java/util/random/RandomGenerator.java Changeset: e83b4b23 Branch: master Author: Claes Redestad Date: 2024-07-23 11:50:57 +0000 URL: https://git.openjdk.org/loom/commit/e83b4b236eca48d0b75094006f7f888398194fe4 8335182: Consolidate and streamline String concat code shapes Reviewed-by: liach, jvernee ! src/java.base/share/classes/java/lang/StringConcatHelper.java ! src/java.base/share/classes/java/lang/System.java ! src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java ! src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java ! test/micro/org/openjdk/bench/java/lang/StringConcat.java + test/micro/org/openjdk/bench/java/lang/StringConcatStartup.java Changeset: a2a236f9 Branch: master Author: Chen Liang Date: 2024-07-23 12:11:47 +0000 URL: https://git.openjdk.org/loom/commit/a2a236f9041083e4b8f11e068da0031dd5f52c2b 8335939: Hide element writing across the ClassFile API Reviewed-by: asotona ! src/java.base/share/classes/java/lang/classfile/Annotation.java ! src/java.base/share/classes/java/lang/classfile/AnnotationElement.java ! src/java.base/share/classes/java/lang/classfile/AnnotationValue.java ! src/java.base/share/classes/java/lang/classfile/Attribute.java ! src/java.base/share/classes/java/lang/classfile/BootstrapMethodEntry.java ! src/java.base/share/classes/java/lang/classfile/BufWriter.java ! src/java.base/share/classes/java/lang/classfile/ClassFileElement.java ! src/java.base/share/classes/java/lang/classfile/ClassReader.java ! src/java.base/share/classes/java/lang/classfile/CustomAttribute.java ! src/java.base/share/classes/java/lang/classfile/FieldModel.java ! src/java.base/share/classes/java/lang/classfile/MethodModel.java - src/java.base/share/classes/java/lang/classfile/WritableElement.java ! src/java.base/share/classes/java/lang/classfile/constantpool/ConstantPoolBuilder.java ! src/java.base/share/classes/java/lang/classfile/constantpool/PoolEntry.java ! src/java.base/share/classes/java/lang/classfile/instruction/LocalVariable.java ! src/java.base/share/classes/java/lang/classfile/instruction/LocalVariableType.java ! src/java.base/share/classes/jdk/internal/classfile/impl/AbstractAttributeMapper.java ! src/java.base/share/classes/jdk/internal/classfile/impl/AbstractBoundLocalVariable.java ! src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java ! src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPseudoInstruction.java ! src/java.base/share/classes/jdk/internal/classfile/impl/AbstractUnboundModel.java ! src/java.base/share/classes/jdk/internal/classfile/impl/AnnotationImpl.java ! src/java.base/share/classes/jdk/internal/classfile/impl/AnnotationReader.java ! src/java.base/share/classes/jdk/internal/classfile/impl/AttributeHolder.java ! src/java.base/share/classes/jdk/internal/classfile/impl/BootstrapMethodEntryImpl.java ! src/java.base/share/classes/jdk/internal/classfile/impl/BoundAttribute.java ! src/java.base/share/classes/jdk/internal/classfile/impl/BufWriterImpl.java ! src/java.base/share/classes/jdk/internal/classfile/impl/BufferedCodeBuilder.java ! src/java.base/share/classes/jdk/internal/classfile/impl/BufferedFieldBuilder.java ! src/java.base/share/classes/jdk/internal/classfile/impl/BufferedMethodBuilder.java ! src/java.base/share/classes/jdk/internal/classfile/impl/ClassReaderImpl.java ! src/java.base/share/classes/jdk/internal/classfile/impl/CodeImpl.java ! src/java.base/share/classes/jdk/internal/classfile/impl/DirectClassBuilder.java ! src/java.base/share/classes/jdk/internal/classfile/impl/DirectCodeBuilder.java ! src/java.base/share/classes/jdk/internal/classfile/impl/DirectFieldBuilder.java ! src/java.base/share/classes/jdk/internal/classfile/impl/DirectMethodBuilder.java ! src/java.base/share/classes/jdk/internal/classfile/impl/FieldImpl.java ! src/java.base/share/classes/jdk/internal/classfile/impl/MethodImpl.java ! src/java.base/share/classes/jdk/internal/classfile/impl/SplitConstantPool.java ! src/java.base/share/classes/jdk/internal/classfile/impl/StackCounter.java ! src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java ! src/java.base/share/classes/jdk/internal/classfile/impl/TemporaryConstantPool.java ! src/java.base/share/classes/jdk/internal/classfile/impl/UnboundAttribute.java ! src/java.base/share/classes/jdk/internal/classfile/impl/Util.java ! test/jdk/jdk/classfile/BoundAttributeTest.java ! test/jdk/jdk/classfile/CorpusTest.java ! test/jdk/jdk/classfile/LimitsTest.java ! test/jdk/jdk/classfile/LowAdaptTest.java ! test/jdk/jdk/classfile/VerifierSelfTest.java ! test/langtools/tools/javac/classfiles/attributes/AnnotationDefault/AnnotationDefaultVerifier.java Changeset: 0e555b5d Branch: master Author: Athijegannathan Sundararajan Date: 2024-07-23 12:22:53 +0000 URL: https://git.openjdk.org/loom/commit/0e555b5ded819cc3b363673320dc848c321861ce 8204582: Extra spaces in jlink documentation make it incorrect. Reviewed-by: alanb ! src/jdk.jlink/share/man/jlink.1 From imediava at gmail.com Tue Jul 23 20:38:05 2024 From: imediava at gmail.com (=?UTF-8?Q?I=C3=B1igo_Mediavilla?=) Date: Tue, 23 Jul 2024 22:38:05 +0200 Subject: [External] : Re: JDK-8334085: Cannot reproduce failing test In-Reply-To: References: <77540540-0831-4a51-a061-7680dba35b96@oracle.com> <03122653-89ff-9fc0-1c12-649504df1bea@oracle.com> Message-ID: Thanks again Patricio, I guess I was struggling to make the connection between the synchronized blocks and the calls to thaw. Based on your last email, I think that I understand that connection, but feel free to correct me if I'm wrong: - There cannot be a call to thaw after a synchronized block has entered and before its execution has completed. If I think about why this is not possible, I think that a thaw cannot happen after something like Thread.yield because in that case the yield would fail and the virtual thread would be pinned. It also should not happen because of a return barrier because a thaw of that kind only happens when we need to load a higher frame in the stack, which by definition cannot happen inside a synchronized block method / block. - held_monitor_count is only affected by synchronized methods / blocks or by JNI's MonitorEnter / MonitorExit. Other synchronization primitives in the JVM do not affect that variable. On Tue, Jul 23, 2024 at 6:09?PM Patricio Chilano Mateo < patricio.chilano.mateo at oracle.com> wrote: > > On 7/23/24 5:59 AM, I?igo Mediavilla wrote: > > Hello Patricio, > > Thanks a lot for your explanation. > > Why is it safe for Thaw code to assume that all non-jni monitors will be > released at that point, but the same assumption cannot be made for jni > monitors ? > > What would happen if ? > > 1. A virtual thread is unmounted > 2. We thaw a few frames and execute code that acquires a non-JNI monitor > 3. We call thaw again > > Or is that not possible ? > > That would not be possible unless there is a bug. All monitors acquired > from synchronized methods/blocks should have been released once execution > of the synchronized method/block completes, either normally or abruptly > (see [1]). > Monitors that are acquired through JNI function MonitorEnter though are > not automatically exited and a call to JNI function MonitorExit is > required, unless DetachCurrentThread is used to implicitly release them > (see [2]). > > [1] > https://docs.oracle.com/javase/specs/jls/se22/html/jls-17.html#jls-17.1 > [2] > https://docs.oracle.com/en/java/javase/22/docs/specs/jni/functions.html#monitor-operations > > Patricio > > Thanks > ??igo > > On Mon, Jul 22, 2024 at 4:11?PM Patricio Chilano Mateo < > patricio.chilano.mateo at oracle.com> wrote: > >> Hi I?igo, >> >> The problem is that we can unmount a virtual thread, then mount it again, >> thaw a few frames, execute code that acquires a JNI monitor, and then call >> thaw again without releasing that monitor. Thaw code assumes all monitors >> must be released at that point but doesn't consider JNI acquired ones. In >> this test this will happen if the vthread is unmounted >> in System.out.println("Thread doing JNI call: " ...) because of contention >> with the main thread doing System.out.println("Main waiting for event."). >> You can reproduce this issue by adding Thread.yield() before >> jniMonitorEnterAndLetObjectDie(). >> >> Thanks, >> Patricio >> >> On 7/22/24 7:30 AM, I?igo Mediavilla wrote: >> >> Hello Serguei, >> >> Thanks a lot for sharing the update and for solving the issue. Do you >> think that you could help me understand exactly what's happening ? >> >> Based on the DBG output shared in JBS, my understanding is that what >> happens in the test is the following: >> >> Main Thread >> ------------------------- ---------------------------- >> 1. acquire java lock >> 2. starting thread >> 3. jni call >> 4. MonitorContendedEnter >> 5. release java lock >> 6. acquire java lock >> 7. MonitorContendedEntered >> 8. Thread in sync section >> 9. release java lock >> 10. why freeze doesn't pin ? >> >> What I'm struggling to understand is why after the thread releases the >> java lock, the virtual thread is still frozen, and specially why does it >> freeze while holding a jni monitor ? I've run tests locally trying to >> freeze a virtual thread holding a JNI lock and my virtual threads are >> always being pinned to the carrier with reason ("holding a lock"). >> >> Thanks in advance >> >> ??igo >> >> On Fri, Jul 19, 2024 at 10:41?PM Serguei Spitsyn < >> serguei.spitsyn at oracle.com> wrote: >> >>> Hi I?igo, >>> >>> Patricio helped to reproduce this issue and also identified the problem >>> (please, see in the bug report). >>> The fix is a one-liner. I?ll post a PR after some mach5 testing. >>> >>> Thank you for involvement into this issue! >>> >>> Thanks, >>> >>> Serguei >>> >>> >>> >>> *From: *I?igo Mediavilla >>> *Date: *Saturday, July 13, 2024 at 12:08?AM >>> *To: *Chris Plummer >>> *Cc: *dholmes at openjdk.org , loom-dev at openjdk.org < >>> loom-dev at openjdk.org>, sspitsyn at openjdk.org >>> *Subject: *Re: JDK-8334085: Cannot reproduce failing test >>> >>> I see, in that case Serguei would you want to still own this JBS or >>> would you be OK if I try to have a look at it ? >>> >>> >>> >>> I?igo >>> >>> El vie, 12 jul 2024, 19:11, Chris Plummer >>> escribi?: >>> >>> Failures are very intermittent. We last saw a failure in our CI testing >>> on 2024-07-03. What command are you using to run the test? >>> >>> Chris >>> >>> On 7/12/24 2:34 AM, I?igo Mediavilla wrote: >>> > Hello, >>> > >>> > While looking at possible JBS tickets to work on, I saw JDK-8334085 >>> > where an assertion was reported to be failing for the >>> > GetOwnedMonitorInfoTest. Before I even asked around to wonder if this >>> > issue was already being looked at, I tried to reproduce the failure >>> > locally, but I don't manage to make the test fail. Is this still an >>> > issue in JDK-24 ? David can you still reproduce the failing test ? >>> > >>> > Best >>> > >>> > ??igo Mediavilla Saiz >>> > >>> > >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Tue Jul 23 22:53:25 2024 From: duke at openjdk.org (duke) Date: Tue, 23 Jul 2024 22:53:25 GMT Subject: git: openjdk/loom: fibers: 2 new changesets Message-ID: <4150441e-1157-4d19-9080-a80334c976a8@openjdk.org> Changeset: eab7b38b Branch: fibers Author: Patricio Chilano Mateo Date: 2024-07-23 18:46:41 +0000 URL: https://git.openjdk.org/loom/commit/eab7b38b5001ef245f87b57b69b928409d91b09f UseZGC: fix race with gc threads ! src/hotspot/share/runtime/continuationFreezeThaw.cpp Changeset: 9ca0b083 Branch: fibers Author: Patricio Chilano Mateo Date: 2024-07-23 18:47:50 +0000 URL: https://git.openjdk.org/loom/commit/9ca0b0830e7025749d7f73c5e912a3697b39fa17 Add Xcomp and reduce test time ! test/jdk/java/lang/Thread/virtual/MonitorsTest.java From patricio.chilano.mateo at oracle.com Tue Jul 23 23:13:23 2024 From: patricio.chilano.mateo at oracle.com (Patricio Chilano Mateo) Date: Tue, 23 Jul 2024 19:13:23 -0400 Subject: [External] : Re: JDK-8334085: Cannot reproduce failing test In-Reply-To: References: <77540540-0831-4a51-a061-7680dba35b96@oracle.com> <03122653-89ff-9fc0-1c12-649504df1bea@oracle.com> Message-ID: <56355134-f179-3a32-1c42-a16a6b4b5a56@oracle.com> On 7/23/24 4:38 PM, I?igo Mediavilla wrote: > Thanks again Patricio, > > I guess I was struggling to make the connection between the > synchronized blocks and the calls to thaw. Based on your last email, I > think that I understand that connection, but feel free to correct me > if I'm wrong: > > - There cannot be a call to thaw after a synchronized block has > entered and before its execution has completed. If I think about why > this is not possible, I think that a thaw cannot happen after > something like Thread.yield because in that case the yield would fail > and the virtual thread would be pinned. It also should not happen > because of a return barrier because a thaw of that kind only happens > when we need to load a higher frame in the stack, which by definition > cannot happen inside a synchronized block method / block. Right. > - held_monitor_count is only affected by synchronized methods / blocks > or by JNI's MonitorEnter / MonitorExit. Other synchronization > primitives in the JVM do not affect that variable. There is also ObjectLocker which is used to acquire a Java monitor from inside the VM. Also note that the counter can be modified during deoptimization if we need to relock objects for which synchronization was eliminated. Patricio > On Tue, Jul 23, 2024 at 6:09?PM Patricio Chilano Mateo > wrote: > > > On 7/23/24 5:59 AM, I?igo Mediavilla wrote: >> Hello Patricio, >> >> Thanks a lot for your explanation. >> >> Why is it safe for Thaw code to assume that all non-jni monitors >> will be released at that point, but the same assumption cannot be >> made for jni monitors ? >> >> What would happen if ? >> >> 1. A virtual thread is unmounted >> 2. We thaw a few frames and execute code that acquires a non-JNI >> monitor >> 3. We call thaw again >> >> Or is that not possible ? > That would not be possible unless there is a bug. All monitors > acquired from synchronized methods/blocks should have been > released once execution of the synchronized method/block > completes, either normally or abruptly (see [1]). > Monitors that are acquired through JNI function MonitorEnter > though are not automatically exited and a call to JNI function > MonitorExit is required, unless DetachCurrentThread is used to > implicitly release them (see [2]). > > [1] > https://docs.oracle.com/javase/specs/jls/se22/html/jls-17.html#jls-17.1 > [2] > https://docs.oracle.com/en/java/javase/22/docs/specs/jni/functions.html#monitor-operations > > Patricio >> Thanks >> ??igo >> >> On Mon, Jul 22, 2024 at 4:11?PM Patricio Chilano Mateo >> wrote: >> >> Hi I?igo, >> >> The problem is that we can unmount a virtual thread, then >> mount it again, thaw a few frames, execute code that acquires >> a JNI monitor, and then call thaw again without releasing >> that monitor. Thaw code assumes all monitors must be released >> at that point but doesn't consider JNI acquired ones. In this >> test this will happen if the vthread is unmounted >> in?System.out.println("Thread doing JNI call: " ...)?because >> of contention with the main thread >> doing?System.out.println("Main waiting for event."). You can >> reproduce this issue by adding Thread.yield() before >> jniMonitorEnterAndLetObjectDie(). >> >> Thanks, >> Patricio >> >> On 7/22/24 7:30 AM, I?igo Mediavilla wrote: >>> Hello Serguei, >>> >>> Thanks a lot for sharing the update and for solving the >>> issue. Do you think that you could help me understand >>> exactly what's happening ? >>> >>> Based on the DBG output shared in JBS, my understanding is >>> that what happens in the test is the following: >>> >>> Main ? ? ? ? ? ? ? ? ? ? ??? Thread >>> ------------------------- ---------------------------- >>> 1. acquire java lock >>> 2. starting thread >>> ? ? ? ? ? ? ? ? ? ? ? ? ? ?????? 3. jni call >>> ? ? ? ? ? ? ? ? ? ? ? ? ? ?????? 4. MonitorContendedEnter >>> 5. release java lock >>> ? ? ? ? ? ? ? ? ? ? ? ? ? ?????? 6. acquire java lock >>> ? ? ? ? ? ? ? ? ? ? ? ? ? ???? ? 7. MonitorContendedEntered >>> ? ? ? ? ? ? ? ? ? ? ? ? ? ?????? 8. Thread in sync section >>> ? ? ? ? ? ? ? ? ? ? ? ? ? ?????? 9. release java lock >>> ? ? ? ? ? ? ? ? ? ? ? ? ? ???? 10. why freeze doesn't pin ? >>> >>> What I'm struggling to understand is why after the thread >>> releases the java lock, the virtual thread is still frozen, >>> and specially why does it freeze while holding a jni monitor >>> ? I've run tests locally trying to freeze a virtual thread >>> holding a JNI lock and my virtual threads are always being >>> pinned to the carrier with reason ("holding a lock"). >>> >>> Thanks in advance >>> >>> ??igo >>> >>> On Fri, Jul 19, 2024 at 10:41?PM Serguei Spitsyn >>> wrote: >>> >>> Hi I?igo, >>> >>> Patricio helped to reproduce this issue and also >>> identified the problem (please, see in the bug report). >>> The fix is a one-liner. I?ll post a PR after some mach5 >>> testing. >>> >>> Thank you for involvement into this issue! >>> >>> Thanks, >>> >>> Serguei >>> >>> *From: *I?igo Mediavilla >>> *Date: *Saturday, July 13, 2024 at 12:08?AM >>> *To: *Chris Plummer >>> *Cc: *dholmes at openjdk.org , >>> loom-dev at openjdk.org , >>> sspitsyn at openjdk.org >>> *Subject: *Re: JDK-8334085: Cannot reproduce failing test >>> >>> I see, in that case Serguei would you want to still own >>> this JBS or would you be OK if I try to have a look at it ? >>> >>> I?igo >>> >>> El vie, 12 jul 2024, 19:11, Chris Plummer >>> escribi?: >>> >>> Failures are very intermittent. We last saw a >>> failure in our CI testing >>> on 2024-07-03. What command are you using to run the >>> test? >>> >>> Chris >>> >>> On 7/12/24 2:34 AM, I?igo Mediavilla wrote: >>> > Hello, >>> > >>> > While looking at possible JBS tickets to work on, >>> I saw JDK-8334085 >>> > where an assertion was reported to be failing for the >>> > GetOwnedMonitorInfoTest. Before I even asked >>> around to wonder if this >>> > issue was already being looked at, I tried to >>> reproduce the failure >>> > locally, but I don't manage to make the test fail. >>> Is this still an >>> > issue in JDK-24 ? David can you still reproduce >>> the failing test ? >>> > >>> > Best >>> > >>> > ??igo Mediavilla Saiz >>> > >>> > >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alanb at openjdk.org Wed Jul 24 07:02:59 2024 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 24 Jul 2024 07:02:59 GMT Subject: RFR: Export JavaThread::_lock_id, ObjectMonitor::_stack_locker and markWord::marked_value. In-Reply-To: References: Message-ID: On Mon, 22 Jul 2024 16:00:00 GMT, Yudi Zheng wrote: > Essential exports for implementing fibers support in Graal. Marked as reviewed by alanb (Committer). ------------- PR Review: https://git.openjdk.org/loom/pull/211#pullrequestreview-2195805526 From yzheng at openjdk.org Wed Jul 24 09:57:01 2024 From: yzheng at openjdk.org (Yudi Zheng) Date: Wed, 24 Jul 2024 09:57:01 GMT Subject: RFR: Export JavaThread::_lock_id, ObjectMonitor::_stack_locker and markWord::marked_value. In-Reply-To: References: Message-ID: On Mon, 22 Jul 2024 16:00:00 GMT, Yudi Zheng wrote: > Essential exports for implementing fibers support in Graal. Thanks for the review! ------------- PR Comment: https://git.openjdk.org/loom/pull/211#issuecomment-2247436057 From duke at openjdk.org Wed Jul 24 09:57:01 2024 From: duke at openjdk.org (duke) Date: Wed, 24 Jul 2024 09:57:01 GMT Subject: RFR: Export JavaThread::_lock_id, ObjectMonitor::_stack_locker and markWord::marked_value. In-Reply-To: References: Message-ID: On Mon, 22 Jul 2024 16:00:00 GMT, Yudi Zheng wrote: > Essential exports for implementing fibers support in Graal. @mur47x111 Your change (at version 0b808fc35d3db7cc9b2cf868a647cc90165067fb) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/loom/pull/211#issuecomment-2247440090 From duke at openjdk.org Wed Jul 24 18:11:13 2024 From: duke at openjdk.org (duke) Date: Wed, 24 Jul 2024 18:11:13 GMT Subject: git: openjdk/loom: fibers: Change RQ back to monitors, disallow preempt when polling queue Message-ID: <1e988e5f-cad8-4228-911e-10b509a3fd9b@openjdk.org> Changeset: 477e9580 Branch: fibers Author: Alan Bateman Date: 2024-07-24 19:06:30 +0000 URL: https://git.openjdk.org/loom/commit/477e95805f3777034a5de939e52ad9a1d2d54563 Change RQ back to monitors, disallow preempt when polling queue ! src/java.base/share/classes/java/lang/invoke/MethodType.java ! src/java.base/share/classes/java/lang/ref/Finalizer.java - src/java.base/share/classes/java/lang/ref/NativeReferenceQueue.java ! src/java.base/share/classes/java/lang/ref/Reference.java ! src/java.base/share/classes/java/lang/ref/ReferenceQueue.java ! src/java.base/share/classes/jdk/internal/access/JavaLangRefAccess.java ! src/java.base/share/classes/jdk/internal/util/ReferencedKeyMap.java ! src/java.base/share/classes/jdk/internal/util/ReferencedKeySet.java ! test/hotspot/jtreg/serviceability/sa/ClhsdbInspect.java From mwolberg at mail.yu.edu Wed Jul 24 22:03:15 2024 From: mwolberg at mail.yu.edu (Moshe Wolberg) Date: Wed, 24 Jul 2024 18:03:15 -0400 Subject: Suggestions on getting involved? Message-ID: Hi, My name is Moshe, I'm finishing up my final year of undergraduate CS (also interned at Microsoft in .NET Core Libraries), particularly focused in concurrency and networking. I'd be very interested in getting involved; I was hoping for some guidance on any areas or issues that might make a good starting point for a newcomer. Also unsure on what the contribution process is. Would appreciate any pointers. Best Moshe -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Thu Jul 25 07:29:02 2024 From: duke at openjdk.org (duke) Date: Thu, 25 Jul 2024 07:29:02 GMT Subject: git: openjdk/loom: fibers: 23 new changesets Message-ID: Changeset: 8e1f17e3 Branch: fibers Author: Sonia Zaldana Calles Date: 2024-07-23 15:49:34 +0000 URL: https://git.openjdk.org/loom/commit/8e1f17e351bc7949b318a0542a4a4cb30ead5a97 8327054: DiagnosticCommand Compiler.perfmap does not log on output() Reviewed-by: lmesnik, stuefe, kevinw, cjplummer ! src/hotspot/share/code/codeCache.cpp ! src/hotspot/share/code/codeCache.hpp ! src/hotspot/share/runtime/java.cpp ! src/hotspot/share/services/diagnosticCommand.cpp ! test/hotspot/jtreg/serviceability/dcmd/compiler/PerfMapTest.java Changeset: 8efcb40c Branch: fibers Author: Joe Darcy Date: 2024-07-23 16:27:09 +0000 URL: https://git.openjdk.org/loom/commit/8efcb40c47d8730d84620a9e980ab9eeb5f51441 8335823: Update --release 23 symbol information for JDK 23 build 33 Reviewed-by: iris, liach ! src/jdk.compiler/share/data/symbols/java.base-N.sym.txt Changeset: 2f2223d7 Branch: fibers Author: William Kemper Date: 2024-07-23 16:50:25 +0000 URL: https://git.openjdk.org/loom/commit/2f2223d7524c4405cc7ca6ab77da62016bbfa911 8336944: Shenandoah: Should only relativize stack chunks for successful evacuations Reviewed-by: shade, ysr ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp Changeset: 4c91d5cb Branch: fibers Author: Ben Perez Committer: Sean Mullan Date: 2024-07-23 19:35:11 +0000 URL: https://git.openjdk.org/loom/commit/4c91d5cb4176e5f4970dc00835d802d857390d72 8322133: getParameterSpec(ECGenParameterSpec.class) on EC AlgorithmParameters does not return standard names Reviewed-by: mullan ! src/java.base/share/classes/sun/security/util/ECParameters.java + test/jdk/com/sun/crypto/provider/AlgorithmParameters/EC/CurveGetParameterSpec.java Changeset: 476d2ae6 Branch: fibers Author: Shaojin Wen Committer: Chen Liang Date: 2024-07-23 20:21:08 +0000 URL: https://git.openjdk.org/loom/commit/476d2ae69d6f67fdf9e2a9353f224141318690f2 8336831: Optimize StringConcatHelper.simpleConcat Reviewed-by: liach, redestad, rriggs ! src/java.base/share/classes/java/lang/String.java ! src/java.base/share/classes/java/lang/StringConcatHelper.java Changeset: 3251eea1 Branch: fibers Author: Martin Balao Date: 2024-07-24 02:39:35 +0000 URL: https://git.openjdk.org/loom/commit/3251eea1f4289a0505052be204407c02ca38b0ad 8336499: Failure when creating non-CRT RSA private keys in SunPKCS11 Co-authored-by: Francisco Ferrari Bihurriet Co-authored-by: Martin Balao Reviewed-by: fferrari, valeriep ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java Changeset: 5b4824cf Branch: fibers Author: Matthias Baesken Date: 2024-07-24 07:21:45 +0000 URL: https://git.openjdk.org/loom/commit/5b4824cf9aba297fa6873ebdadc0e9545647e90d 8336827: compiler/vectorization/TestFloat16VectorConvChain.java timeouts on ppc64 platforms after JDK-8335860 Reviewed-by: kvn, mdoerr, shade ! test/hotspot/jtreg/compiler/vectorization/TestFloat16VectorConvChain.java Changeset: 05d88de0 Branch: fibers Author: Albert Mingkun Yang Date: 2024-07-24 09:10:38 +0000 URL: https://git.openjdk.org/loom/commit/05d88de05e9b7814ecd5517aacd17f0feafdff3c 8336098: G1: Refactor G1RebuildRSAndScrubTask Reviewed-by: tschatzl, gli ! src/hotspot/share/gc/g1/g1ConcurrentRebuildAndScrub.cpp Changeset: 332df83e Branch: fibers Author: Chen Liang Date: 2024-07-24 12:13:15 +0000 URL: https://git.openjdk.org/loom/commit/332df83e7cb1f272c08f8e4955d6abaf3f091ace 8336927: Missing equals and hashCode in java.lang.classfile.Annotation Reviewed-by: asotona ! src/java.base/share/classes/jdk/internal/classfile/impl/AnnotationImpl.java ! test/jdk/jdk/classfile/AnnotationTest.java Changeset: aa15b895 Branch: fibers Author: Erik Gahlin Date: 2024-07-24 15:12:53 +0000 URL: https://git.openjdk.org/loom/commit/aa15b895c96fd62152d5ae5a1a9dfd28610c5125 8336485: jdk/jfr/jcmd/TestJcmdView.java RuntimeException: 'Invoked Concurrent' missing from stdout/stderr Reviewed-by: mgronlun ! test/jdk/jdk/jfr/jcmd/TestJcmdView.java Changeset: b2599f8b Branch: fibers Author: Erik Gahlin Date: 2024-07-24 15:13:02 +0000 URL: https://git.openjdk.org/loom/commit/b2599f8b0ed227f7b67fbbb77b4a5af1f12730e2 8336316: JFR: Use SettingControl::getValue() instead of setValue() for ActiveSetting event Reviewed-by: mgronlun ! src/jdk.jfr/share/classes/jdk/jfr/internal/Control.java Changeset: 04e8cb86 Branch: fibers Author: Jaikiran Pai Date: 2024-07-24 15:43:53 +0000 URL: https://git.openjdk.org/loom/commit/04e8cb8641bfdad717b368c087619905bccdf5e6 8336815: Several methods in java.net.Socket and ServerSocket do not specify behavior when already bound, connected or closed Reviewed-by: alanb ! src/java.base/share/classes/java/net/ServerSocket.java ! src/java.base/share/classes/java/net/Socket.java + test/jdk/java/net/ServerSocket/ClosedServerSocketTest.java + test/jdk/java/net/Socket/ClosedSocketTest.java Changeset: 4ea4d7c6 Branch: fibers Author: Naoto Sato Date: 2024-07-24 16:48:34 +0000 URL: https://git.openjdk.org/loom/commit/4ea4d7c68444200ab38cbd76762c2f27848e264e 8336679: Add @implSpec for the default implementations in Process.waitFor() Reviewed-by: bpb, jlu, liach ! src/java.base/share/classes/java/lang/Process.java Changeset: 9e8e3595 Branch: fibers Author: Justin Lu Date: 2024-07-24 20:08:13 +0000 URL: https://git.openjdk.org/loom/commit/9e8e359513cf15faf549b12ced947d3a78e544aa 8336787: Examine java.text.Format API for implSpec usage Reviewed-by: liach ! src/java.base/share/classes/java/text/Format.java Changeset: 5a8861a3 Branch: fibers Author: Justin Lu Date: 2024-07-24 20:14:00 +0000 URL: https://git.openjdk.org/loom/commit/5a8861a3a1b436ce7414176c095c58c9a1e038d6 8336847: Use pattern match switch in NumberFormat classes Reviewed-by: liach, naoto ! src/java.base/share/classes/java/text/CompactNumberFormat.java ! src/java.base/share/classes/java/text/DecimalFormat.java ! src/java.base/share/classes/java/text/NumberFormat.java Changeset: e716f5ed Branch: fibers Author: Andrey Turbanov Date: 2024-07-24 20:26:11 +0000 URL: https://git.openjdk.org/loom/commit/e716f5ed53c20f4235787e2d6927a16ebcf67b8f 8336755: Remove unused UNALIGNED field from view buffers Reviewed-by: alanb, liach, bpb ! src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template Changeset: 021c2c36 Branch: fibers Author: David Holmes Date: 2024-07-24 21:15:18 +0000 URL: https://git.openjdk.org/loom/commit/021c2c36ac243009c71147072d405636cab0b12c 8337067: Test runtime/classFileParserBug/Bad_NCDFE_Msg.java won't compile Reviewed-by: lfoltan ! test/hotspot/jtreg/runtime/classFileParserBug/Bad_NCDFE_Msg.java Changeset: 24f67d02 Branch: fibers Author: Neethu Prasad Committer: Vladimir Kozlov Date: 2024-07-24 22:22:18 +0000 URL: https://git.openjdk.org/loom/commit/24f67d0254c08a668d24f28ec0fa768ef10feed5 8334232: Optimize C1 classes layout Reviewed-by: phh, kvn ! src/hotspot/share/c1/c1_Instruction.hpp ! src/hotspot/share/c1/c1_LIR.cpp ! src/hotspot/share/c1/c1_LIR.hpp Changeset: 0898ab7f Branch: fibers Author: Shaojin Wen Committer: Chen Liang Date: 2024-07-24 22:39:49 +0000 URL: https://git.openjdk.org/loom/commit/0898ab7f7496689e5de52a5dc4530ca21def1fca 8336741: Optimize LocalTime.toString with StringBuilder.repeat Reviewed-by: liach, rriggs, naoto ! src/java.base/share/classes/java/time/LocalTime.java ! src/java.base/share/classes/jdk/internal/util/DecimalDigits.java + test/micro/org/openjdk/bench/java/time/ToStringBench.java Changeset: d3e51daf Branch: fibers Author: Serguei Spitsyn Date: 2024-07-25 01:35:03 +0000 URL: https://git.openjdk.org/loom/commit/d3e51daf7331b84b4e78f7f10360848d7c549c1a 8334085: Test crash: assert(thread->held_monitor_count() == 0) failed: Must be Reviewed-by: dholmes, pchilanomate ! src/hotspot/share/runtime/continuationFreezeThaw.cpp ! test/hotspot/jtreg/serviceability/jvmti/GetOwnedMonitorInfo/GetOwnedMonitorInfoTest.java Changeset: 6e228ce3 Branch: fibers Author: Alan Bateman Date: 2024-07-25 04:59:01 +0000 URL: https://git.openjdk.org/loom/commit/6e228ce382d1fad6cba0d0df8a507e6bd32a9a4a 8336254: Virtual thread implementation + test updates Reviewed-by: sspitsyn, kevinw ! make/test/JtregNativeHotspot.gmk ! src/java.base/share/classes/java/lang/System.java ! src/java.base/share/classes/java/lang/VirtualThread.java ! src/java.base/share/classes/java/util/concurrent/locks/LockSupport.java ! src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java - src/java.base/share/classes/jdk/internal/misc/VirtualThreads.java ! test/hotspot/jtreg/serviceability/jvmti/thread/GetFrameCount/framecnt01/framecnt01.java ! test/hotspot/jtreg/serviceability/jvmti/vthread/GetThreadState/GetThreadStateTest.java ! test/hotspot/jtreg/serviceability/jvmti/vthread/VThreadEventTest/VThreadEventTest.java ! test/hotspot/jtreg/serviceability/jvmti/vthread/VThreadEventTest/libVThreadEventTest.cpp + test/jdk/java/lang/Thread/virtual/CarrierThreadInfo.java - test/jdk/java/lang/Thread/virtual/CarrierThreadWaits.java ! test/jdk/java/lang/Thread/virtual/CustomScheduler.java - test/jdk/java/lang/Thread/virtual/GetStackTrace.java - test/jdk/java/lang/Thread/virtual/GetStackTraceWhenRunnable.java ! test/jdk/java/lang/Thread/virtual/JfrEvents.java + test/jdk/java/lang/Thread/virtual/MonitorEnterExit.java ! test/jdk/java/lang/Thread/virtual/MonitorWaitNotify.java ! test/jdk/java/lang/Thread/virtual/ParkWithFixedThreadPool.java ! test/jdk/java/lang/Thread/virtual/Reflection.java + test/jdk/java/lang/Thread/virtual/StackFrames.java - test/jdk/java/lang/Thread/virtual/StackTraces.java ! test/jdk/java/lang/Thread/virtual/ThreadAPI.java - test/jdk/java/lang/Thread/virtual/ThreadBuilders.java ! test/jdk/java/lang/Thread/virtual/VirtualThreadPinnedEventThrows.java + test/jdk/java/lang/Thread/virtual/stress/CompletableFutureTimedGet.java - test/jdk/java/lang/Thread/virtual/stress/GetStackTraceALot.java + test/jdk/java/lang/Thread/virtual/stress/GetStackTraceALotWhenBlocking.java + test/jdk/java/lang/Thread/virtual/stress/GetStackTraceALotWhenParking.java ! test/jdk/java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java ! test/jdk/java/lang/Thread/virtual/stress/PinALot.java ! test/jdk/java/lang/Thread/virtual/stress/PingPong.java ! test/jdk/java/lang/Thread/virtual/stress/Skynet.java ! test/jdk/java/lang/Thread/virtual/stress/SleepALot.java - test/jdk/java/lang/Thread/virtual/stress/TimedGet.java + test/jdk/java/lang/Thread/virtual/stress/TimedWaitALot.java ! test/jdk/java/lang/Thread/virtual/stress/YieldALot.java + test/jdk/java/lang/management/ThreadMXBean/LockedMonitorInNative.java ! test/jdk/java/lang/management/ThreadMXBean/VirtualThreads.java + test/jdk/java/lang/management/ThreadMXBean/libLockedMonitorInNative.c ! test/jdk/jdk/internal/misc/ThreadFlock/ThreadFlockTest.java + test/lib/jdk/test/lib/thread/VThreadScheduler.java Changeset: d862dee5 Branch: fibers Author: Alan Bateman Date: 2024-07-25 06:17:11 +0000 URL: https://git.openjdk.org/loom/commit/d862dee580cd398ab05420c81fed1ca2d62bb472 Merge ! src/hotspot/share/services/diagnosticCommand.cpp ! test/jdk/jdk/internal/misc/ThreadFlock/ThreadFlockTest.java ! src/hotspot/share/services/diagnosticCommand.cpp ! test/jdk/jdk/internal/misc/ThreadFlock/ThreadFlockTest.java Changeset: 03a7b3de Branch: fibers Author: Alan Bateman Date: 2024-07-25 08:05:47 +0000 URL: https://git.openjdk.org/loom/commit/03a7b3def3baf560c51023129d4b6839f3dd7408 Restore copyright date ! test/jdk/java/lang/Thread/virtual/stress/GetStackTraceALotWhenBlocking.java From duke at openjdk.org Thu Jul 25 07:30:14 2024 From: duke at openjdk.org (duke) Date: Thu, 25 Jul 2024 07:30:14 GMT Subject: git: openjdk/loom: master: 21 new changesets Message-ID: Changeset: 8e1f17e3 Branch: master Author: Sonia Zaldana Calles Date: 2024-07-23 15:49:34 +0000 URL: https://git.openjdk.org/loom/commit/8e1f17e351bc7949b318a0542a4a4cb30ead5a97 8327054: DiagnosticCommand Compiler.perfmap does not log on output() Reviewed-by: lmesnik, stuefe, kevinw, cjplummer ! src/hotspot/share/code/codeCache.cpp ! src/hotspot/share/code/codeCache.hpp ! src/hotspot/share/runtime/java.cpp ! src/hotspot/share/services/diagnosticCommand.cpp ! test/hotspot/jtreg/serviceability/dcmd/compiler/PerfMapTest.java Changeset: 8efcb40c Branch: master Author: Joe Darcy Date: 2024-07-23 16:27:09 +0000 URL: https://git.openjdk.org/loom/commit/8efcb40c47d8730d84620a9e980ab9eeb5f51441 8335823: Update --release 23 symbol information for JDK 23 build 33 Reviewed-by: iris, liach ! src/jdk.compiler/share/data/symbols/java.base-N.sym.txt Changeset: 2f2223d7 Branch: master Author: William Kemper Date: 2024-07-23 16:50:25 +0000 URL: https://git.openjdk.org/loom/commit/2f2223d7524c4405cc7ca6ab77da62016bbfa911 8336944: Shenandoah: Should only relativize stack chunks for successful evacuations Reviewed-by: shade, ysr ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp Changeset: 4c91d5cb Branch: master Author: Ben Perez Committer: Sean Mullan Date: 2024-07-23 19:35:11 +0000 URL: https://git.openjdk.org/loom/commit/4c91d5cb4176e5f4970dc00835d802d857390d72 8322133: getParameterSpec(ECGenParameterSpec.class) on EC AlgorithmParameters does not return standard names Reviewed-by: mullan ! src/java.base/share/classes/sun/security/util/ECParameters.java + test/jdk/com/sun/crypto/provider/AlgorithmParameters/EC/CurveGetParameterSpec.java Changeset: 476d2ae6 Branch: master Author: Shaojin Wen Committer: Chen Liang Date: 2024-07-23 20:21:08 +0000 URL: https://git.openjdk.org/loom/commit/476d2ae69d6f67fdf9e2a9353f224141318690f2 8336831: Optimize StringConcatHelper.simpleConcat Reviewed-by: liach, redestad, rriggs ! src/java.base/share/classes/java/lang/String.java ! src/java.base/share/classes/java/lang/StringConcatHelper.java Changeset: 3251eea1 Branch: master Author: Martin Balao Date: 2024-07-24 02:39:35 +0000 URL: https://git.openjdk.org/loom/commit/3251eea1f4289a0505052be204407c02ca38b0ad 8336499: Failure when creating non-CRT RSA private keys in SunPKCS11 Co-authored-by: Francisco Ferrari Bihurriet Co-authored-by: Martin Balao Reviewed-by: fferrari, valeriep ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java Changeset: 5b4824cf Branch: master Author: Matthias Baesken Date: 2024-07-24 07:21:45 +0000 URL: https://git.openjdk.org/loom/commit/5b4824cf9aba297fa6873ebdadc0e9545647e90d 8336827: compiler/vectorization/TestFloat16VectorConvChain.java timeouts on ppc64 platforms after JDK-8335860 Reviewed-by: kvn, mdoerr, shade ! test/hotspot/jtreg/compiler/vectorization/TestFloat16VectorConvChain.java Changeset: 05d88de0 Branch: master Author: Albert Mingkun Yang Date: 2024-07-24 09:10:38 +0000 URL: https://git.openjdk.org/loom/commit/05d88de05e9b7814ecd5517aacd17f0feafdff3c 8336098: G1: Refactor G1RebuildRSAndScrubTask Reviewed-by: tschatzl, gli ! src/hotspot/share/gc/g1/g1ConcurrentRebuildAndScrub.cpp Changeset: 332df83e Branch: master Author: Chen Liang Date: 2024-07-24 12:13:15 +0000 URL: https://git.openjdk.org/loom/commit/332df83e7cb1f272c08f8e4955d6abaf3f091ace 8336927: Missing equals and hashCode in java.lang.classfile.Annotation Reviewed-by: asotona ! src/java.base/share/classes/jdk/internal/classfile/impl/AnnotationImpl.java ! test/jdk/jdk/classfile/AnnotationTest.java Changeset: aa15b895 Branch: master Author: Erik Gahlin Date: 2024-07-24 15:12:53 +0000 URL: https://git.openjdk.org/loom/commit/aa15b895c96fd62152d5ae5a1a9dfd28610c5125 8336485: jdk/jfr/jcmd/TestJcmdView.java RuntimeException: 'Invoked Concurrent' missing from stdout/stderr Reviewed-by: mgronlun ! test/jdk/jdk/jfr/jcmd/TestJcmdView.java Changeset: b2599f8b Branch: master Author: Erik Gahlin Date: 2024-07-24 15:13:02 +0000 URL: https://git.openjdk.org/loom/commit/b2599f8b0ed227f7b67fbbb77b4a5af1f12730e2 8336316: JFR: Use SettingControl::getValue() instead of setValue() for ActiveSetting event Reviewed-by: mgronlun ! src/jdk.jfr/share/classes/jdk/jfr/internal/Control.java Changeset: 04e8cb86 Branch: master Author: Jaikiran Pai Date: 2024-07-24 15:43:53 +0000 URL: https://git.openjdk.org/loom/commit/04e8cb8641bfdad717b368c087619905bccdf5e6 8336815: Several methods in java.net.Socket and ServerSocket do not specify behavior when already bound, connected or closed Reviewed-by: alanb ! src/java.base/share/classes/java/net/ServerSocket.java ! src/java.base/share/classes/java/net/Socket.java + test/jdk/java/net/ServerSocket/ClosedServerSocketTest.java + test/jdk/java/net/Socket/ClosedSocketTest.java Changeset: 4ea4d7c6 Branch: master Author: Naoto Sato Date: 2024-07-24 16:48:34 +0000 URL: https://git.openjdk.org/loom/commit/4ea4d7c68444200ab38cbd76762c2f27848e264e 8336679: Add @implSpec for the default implementations in Process.waitFor() Reviewed-by: bpb, jlu, liach ! src/java.base/share/classes/java/lang/Process.java Changeset: 9e8e3595 Branch: master Author: Justin Lu Date: 2024-07-24 20:08:13 +0000 URL: https://git.openjdk.org/loom/commit/9e8e359513cf15faf549b12ced947d3a78e544aa 8336787: Examine java.text.Format API for implSpec usage Reviewed-by: liach ! src/java.base/share/classes/java/text/Format.java Changeset: 5a8861a3 Branch: master Author: Justin Lu Date: 2024-07-24 20:14:00 +0000 URL: https://git.openjdk.org/loom/commit/5a8861a3a1b436ce7414176c095c58c9a1e038d6 8336847: Use pattern match switch in NumberFormat classes Reviewed-by: liach, naoto ! src/java.base/share/classes/java/text/CompactNumberFormat.java ! src/java.base/share/classes/java/text/DecimalFormat.java ! src/java.base/share/classes/java/text/NumberFormat.java Changeset: e716f5ed Branch: master Author: Andrey Turbanov Date: 2024-07-24 20:26:11 +0000 URL: https://git.openjdk.org/loom/commit/e716f5ed53c20f4235787e2d6927a16ebcf67b8f 8336755: Remove unused UNALIGNED field from view buffers Reviewed-by: alanb, liach, bpb ! src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template Changeset: 021c2c36 Branch: master Author: David Holmes Date: 2024-07-24 21:15:18 +0000 URL: https://git.openjdk.org/loom/commit/021c2c36ac243009c71147072d405636cab0b12c 8337067: Test runtime/classFileParserBug/Bad_NCDFE_Msg.java won't compile Reviewed-by: lfoltan ! test/hotspot/jtreg/runtime/classFileParserBug/Bad_NCDFE_Msg.java Changeset: 24f67d02 Branch: master Author: Neethu Prasad Committer: Vladimir Kozlov Date: 2024-07-24 22:22:18 +0000 URL: https://git.openjdk.org/loom/commit/24f67d0254c08a668d24f28ec0fa768ef10feed5 8334232: Optimize C1 classes layout Reviewed-by: phh, kvn ! src/hotspot/share/c1/c1_Instruction.hpp ! src/hotspot/share/c1/c1_LIR.cpp ! src/hotspot/share/c1/c1_LIR.hpp Changeset: 0898ab7f Branch: master Author: Shaojin Wen Committer: Chen Liang Date: 2024-07-24 22:39:49 +0000 URL: https://git.openjdk.org/loom/commit/0898ab7f7496689e5de52a5dc4530ca21def1fca 8336741: Optimize LocalTime.toString with StringBuilder.repeat Reviewed-by: liach, rriggs, naoto ! src/java.base/share/classes/java/time/LocalTime.java ! src/java.base/share/classes/jdk/internal/util/DecimalDigits.java + test/micro/org/openjdk/bench/java/time/ToStringBench.java Changeset: d3e51daf Branch: master Author: Serguei Spitsyn Date: 2024-07-25 01:35:03 +0000 URL: https://git.openjdk.org/loom/commit/d3e51daf7331b84b4e78f7f10360848d7c549c1a 8334085: Test crash: assert(thread->held_monitor_count() == 0) failed: Must be Reviewed-by: dholmes, pchilanomate ! src/hotspot/share/runtime/continuationFreezeThaw.cpp ! test/hotspot/jtreg/serviceability/jvmti/GetOwnedMonitorInfo/GetOwnedMonitorInfoTest.java Changeset: 6e228ce3 Branch: master Author: Alan Bateman Date: 2024-07-25 04:59:01 +0000 URL: https://git.openjdk.org/loom/commit/6e228ce382d1fad6cba0d0df8a507e6bd32a9a4a 8336254: Virtual thread implementation + test updates Reviewed-by: sspitsyn, kevinw ! make/test/JtregNativeHotspot.gmk ! src/java.base/share/classes/java/lang/System.java ! src/java.base/share/classes/java/lang/VirtualThread.java ! src/java.base/share/classes/java/util/concurrent/locks/LockSupport.java ! src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java - src/java.base/share/classes/jdk/internal/misc/VirtualThreads.java ! test/hotspot/jtreg/serviceability/jvmti/thread/GetFrameCount/framecnt01/framecnt01.java ! test/hotspot/jtreg/serviceability/jvmti/vthread/GetThreadState/GetThreadStateTest.java ! test/hotspot/jtreg/serviceability/jvmti/vthread/VThreadEventTest/VThreadEventTest.java ! test/hotspot/jtreg/serviceability/jvmti/vthread/VThreadEventTest/libVThreadEventTest.cpp + test/jdk/java/lang/Thread/virtual/CarrierThreadInfo.java - test/jdk/java/lang/Thread/virtual/CarrierThreadWaits.java ! test/jdk/java/lang/Thread/virtual/CustomScheduler.java - test/jdk/java/lang/Thread/virtual/GetStackTrace.java - test/jdk/java/lang/Thread/virtual/GetStackTraceWhenRunnable.java ! test/jdk/java/lang/Thread/virtual/JfrEvents.java + test/jdk/java/lang/Thread/virtual/MonitorEnterExit.java ! test/jdk/java/lang/Thread/virtual/MonitorWaitNotify.java ! test/jdk/java/lang/Thread/virtual/ParkWithFixedThreadPool.java ! test/jdk/java/lang/Thread/virtual/Reflection.java + test/jdk/java/lang/Thread/virtual/StackFrames.java - test/jdk/java/lang/Thread/virtual/StackTraces.java ! test/jdk/java/lang/Thread/virtual/ThreadAPI.java - test/jdk/java/lang/Thread/virtual/ThreadBuilders.java ! test/jdk/java/lang/Thread/virtual/VirtualThreadPinnedEventThrows.java + test/jdk/java/lang/Thread/virtual/stress/CompletableFutureTimedGet.java - test/jdk/java/lang/Thread/virtual/stress/GetStackTraceALot.java + test/jdk/java/lang/Thread/virtual/stress/GetStackTraceALotWhenBlocking.java + test/jdk/java/lang/Thread/virtual/stress/GetStackTraceALotWhenParking.java ! test/jdk/java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java ! test/jdk/java/lang/Thread/virtual/stress/PinALot.java ! test/jdk/java/lang/Thread/virtual/stress/PingPong.java ! test/jdk/java/lang/Thread/virtual/stress/Skynet.java ! test/jdk/java/lang/Thread/virtual/stress/SleepALot.java - test/jdk/java/lang/Thread/virtual/stress/TimedGet.java + test/jdk/java/lang/Thread/virtual/stress/TimedWaitALot.java ! test/jdk/java/lang/Thread/virtual/stress/YieldALot.java + test/jdk/java/lang/management/ThreadMXBean/LockedMonitorInNative.java ! test/jdk/java/lang/management/ThreadMXBean/VirtualThreads.java + test/jdk/java/lang/management/ThreadMXBean/libLockedMonitorInNative.c ! test/jdk/jdk/internal/misc/ThreadFlock/ThreadFlockTest.java + test/lib/jdk/test/lib/thread/VThreadScheduler.java From david.vlijmincx at gmail.com Thu Jul 25 09:12:17 2024 From: david.vlijmincx at gmail.com (David) Date: Thu, 25 Jul 2024 11:12:17 +0200 Subject: Understanding Virtual thread performance for quick API calls Message-ID: Hi, I'm looking for some insight into some benchmark performance [1]. I'm comparing the performance of Virtual threads and Platform threads by submitting 10_000 tasks that perform 1 or 2 API requests to either a newVirtualThreadPerTaskExecutor or an Executors.newFixedThreadPool(Runtime.getRuntime().availableProcessors()). I expected the Virtual threads to perform better because the tasks don't look CPU-bound (response times around 4ms), but platform threads outperformed the Virtual threads when a response returned within 9ms. The results using JDK 24-loom+1-17 (2024/6/22) were the following: Benchmark (delay) (numberOfCalls) Mode Cnt Score Error Units Improv.LoomBenchmark.FixedPlatformPool 0 1 avgt 10 0.808 ? 0.001 s/op Improv.LoomBenchmark.FixedPlatformPool 0 2 avgt 10 1.614 ? 0.001 s/op Improv.LoomBenchmark.FixedPlatformPool 1 1 avgt 10 1.239 ? 0.002 s/op Improv.LoomBenchmark.FixedPlatformPool 1 2 avgt 10 2.473 ? 0.004 s/op Improv.LoomBenchmark.FixedPlatformPool 2 1 avgt 10 1.461 ? 0.003 s/op Improv.LoomBenchmark.FixedPlatformPool 2 2 avgt 10 2.918 ? 0.004 s/op Improv.LoomBenchmark.FixedPlatformPool 3 1 avgt 10 1.730 ? 0.002 s/op Improv.LoomBenchmark.FixedPlatformPool 3 2 avgt 10 3.461 ? 0.008 s/op Improv.LoomBenchmark.FixedPlatformPool 4 1 avgt 10 2.017 ? 0.003 s/op Improv.LoomBenchmark.FixedPlatformPool 4 2 avgt 10 4.032 ? 0.007 s/op Improv.LoomBenchmark.FixedPlatformPool 5 1 avgt 10 2.317 ? 0.003 s/op Improv.LoomBenchmark.FixedPlatformPool 5 2 avgt 10 4.633 ? 0.006 s/op Improv.LoomBenchmark.virtualThreadExecutor 0 1 avgt 10 2.976 ? 0.262 s/op Improv.LoomBenchmark.virtualThreadExecutor 0 2 avgt 10 2.909 ? 0.093 s/op Improv.LoomBenchmark.virtualThreadExecutor 1 1 avgt 10 2.853 ? 0.181 s/op Improv.LoomBenchmark.virtualThreadExecutor 1 2 avgt 10 2.913 ? 0.146 s/op Improv.LoomBenchmark.virtualThreadExecutor 2 1 avgt 10 2.875 ? 0.254 s/op Improv.LoomBenchmark.virtualThreadExecutor 2 2 avgt 10 2.876 ? 0.112 s/op Improv.LoomBenchmark.virtualThreadExecutor 3 1 avgt 10 2.772 ? 0.126 s/op Improv.LoomBenchmark.virtualThreadExecutor 3 2 avgt 10 2.856 ? 0.196 s/op Improv.LoomBenchmark.virtualThreadExecutor 4 1 avgt 10 2.731 ? 0.166 s/op Improv.LoomBenchmark.virtualThreadExecutor 4 2 avgt 10 2.888 ? 0.155 s/op Improv.LoomBenchmark.virtualThreadExecutor 5 1 avgt 10 2.855 ? 0.213 s/op Improv.LoomBenchmark.virtualThreadExecutor 5 2 avgt 10 2.906 ? 0.172 s/op The delay column shows how much delay in milliseconds was added by the end-point. Without any added delay the response time is about 4ms. I attached two visualizations of the results to this mail. I'd be grateful if someone could shed some light on potential reasons behind virtual threads underperforming for these short-lived API with below 9ms response times. Are there any best practices for benchmarking Virtual threads that I might be missing? Kind regards, David [1]: https://github.com/davidtos/VirtualThreadPerformanceShortLivedTasks/blob/master/src/main/java/Improv/LoomBenchmark.java -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 10_000_x_1_call_API_call.png Type: image/png Size: 14544 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 10_000_x_2_call_API_call.png Type: image/png Size: 14911 bytes Desc: not available URL: From Alan.Bateman at oracle.com Thu Jul 25 09:58:24 2024 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 25 Jul 2024 10:58:24 +0100 Subject: Understanding Virtual thread performance for quick API calls In-Reply-To: References: Message-ID: <294d8e74-8757-42cc-bdbf-fe4f8d8fbc6a@oracle.com> On 25/07/2024 10:12, David wrote: > Hi, > > I'm looking for some insight into some benchmark performance [1]. I'm > comparing the performance of Virtual threads and Platform threads by > submitting 10_000 tasks that perform 1 or 2 API requests to either > a?newVirtualThreadPerTaskExecutor or an > Executors.newFixedThreadPool(Runtime.getRuntime().availableProcessors()). It might be useful to collect some data on the number of HTTP connections. For your thread pool test you've limited the concurrency so you've N connections and likely benefits greatly from HTTP keep alive.? It will likely be different in your virtual threads test, in the extreme it might have 10_000 connections. If you can get some data on that then it might help the analysis. -Alan From robin.bygrave at gmail.com Thu Jul 25 10:06:42 2024 From: robin.bygrave at gmail.com (Rob Bygrave) Date: Thu, 25 Jul 2024 22:06:42 +1200 Subject: Understanding Virtual thread performance for quick API calls In-Reply-To: References: Message-ID: Some thoughts in case it's useful (I've done a similar test quite a long time ago). To me, it looks like with VT it will approximately try to submit 10K requests *almost* concurrently, where as with platform threads the number of concurrent requests is limited to the number of available processors (so there is a lot less concurrent requests in the platform thread case - there is a good chance the server is much happier at the lower concurrency). First note is that the VT test will can look like a *Denial of service attack*. As I see it, for this test to be useful the server needs to be able to handle the level of concurrency we want to throw at it. When I ran this test I needed my http server to run VT in order to handle the high level of concurrent requests (as otherwise the http server hits its max concurrency and then effectively queues requests). If you know the max concurrency that the http server can handle, then you can run interesting tests around this max. The question for this test, is if http://192.168.1.17:8080/v1/crawl/delay/ is happy with the level of concurrency being thrown at it in the VT case. When I ran a similar test (quite some time ago) I also found empirically that I needed to slow down the submission of jobs in the VT case. That is, it wasn't happy submitting 10K requests in a really tight loop and I believe I actually added in some LockSupport.parkNanos() inside that tight 10K loop in order to get what I thought was "better" behaviour on the test. Hopefully that gives you some ideas. Cheers, Rob. On Thu, 25 Jul 2024 at 21:12, David wrote: > Hi, > > I'm looking for some insight into some benchmark performance [1]. I'm > comparing the performance of Virtual threads and Platform threads by > submitting 10_000 tasks that perform 1 or 2 API requests to either > a newVirtualThreadPerTaskExecutor or an > Executors.newFixedThreadPool(Runtime.getRuntime().availableProcessors()). > > I expected the Virtual threads to perform better because the tasks don't > look CPU-bound (response times around 4ms), but platform threads > outperformed the Virtual threads when a response returned within 9ms. The > results using JDK 24-loom+1-17 (2024/6/22) were the following: > > Benchmark (delay) > (numberOfCalls) Mode Cnt Score Error Units > Improv.LoomBenchmark.FixedPlatformPool 0 1 avgt > 10 0.808 ? 0.001 s/op > Improv.LoomBenchmark.FixedPlatformPool 0 2 avgt > 10 1.614 ? 0.001 s/op > Improv.LoomBenchmark.FixedPlatformPool 1 1 avgt > 10 1.239 ? 0.002 s/op > Improv.LoomBenchmark.FixedPlatformPool 1 2 avgt > 10 2.473 ? 0.004 s/op > Improv.LoomBenchmark.FixedPlatformPool 2 1 avgt > 10 1.461 ? 0.003 s/op > Improv.LoomBenchmark.FixedPlatformPool 2 2 avgt > 10 2.918 ? 0.004 s/op > Improv.LoomBenchmark.FixedPlatformPool 3 1 avgt > 10 1.730 ? 0.002 s/op > Improv.LoomBenchmark.FixedPlatformPool 3 2 avgt > 10 3.461 ? 0.008 s/op > Improv.LoomBenchmark.FixedPlatformPool 4 1 avgt > 10 2.017 ? 0.003 s/op > Improv.LoomBenchmark.FixedPlatformPool 4 2 avgt > 10 4.032 ? 0.007 s/op > Improv.LoomBenchmark.FixedPlatformPool 5 1 avgt > 10 2.317 ? 0.003 s/op > Improv.LoomBenchmark.FixedPlatformPool 5 2 avgt > 10 4.633 ? 0.006 s/op > > Improv.LoomBenchmark.virtualThreadExecutor 0 1 avgt > 10 2.976 ? 0.262 s/op > Improv.LoomBenchmark.virtualThreadExecutor 0 2 avgt > 10 2.909 ? 0.093 s/op > Improv.LoomBenchmark.virtualThreadExecutor 1 1 avgt > 10 2.853 ? 0.181 s/op > Improv.LoomBenchmark.virtualThreadExecutor 1 2 avgt > 10 2.913 ? 0.146 s/op > Improv.LoomBenchmark.virtualThreadExecutor 2 1 avgt > 10 2.875 ? 0.254 s/op > Improv.LoomBenchmark.virtualThreadExecutor 2 2 avgt > 10 2.876 ? 0.112 s/op > Improv.LoomBenchmark.virtualThreadExecutor 3 1 avgt > 10 2.772 ? 0.126 s/op > Improv.LoomBenchmark.virtualThreadExecutor 3 2 avgt > 10 2.856 ? 0.196 s/op > Improv.LoomBenchmark.virtualThreadExecutor 4 1 avgt > 10 2.731 ? 0.166 s/op > Improv.LoomBenchmark.virtualThreadExecutor 4 2 avgt > 10 2.888 ? 0.155 s/op > Improv.LoomBenchmark.virtualThreadExecutor 5 1 avgt > 10 2.855 ? 0.213 s/op > Improv.LoomBenchmark.virtualThreadExecutor 5 2 avgt > 10 2.906 ? 0.172 s/op > > The delay column shows how much delay in milliseconds was added by the > end-point. Without any added delay the response time is about 4ms. I > attached two visualizations of the results to this mail. > > I'd be grateful if someone could shed some light on potential reasons > behind virtual threads underperforming for these short-lived API with below > 9ms response times. Are there any best practices for benchmarking Virtual > threads that I might be missing? > > Kind regards, > David > > [1]: > https://github.com/davidtos/VirtualThreadPerformanceShortLivedTasks/blob/master/src/main/java/Improv/LoomBenchmark.java > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robaho at icloud.com Thu Jul 25 11:00:15 2024 From: robaho at icloud.com (robert engels) Date: Thu, 25 Jul 2024 06:00:15 -0500 Subject: Understanding Virtual thread performance for quick API calls In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From matthew.swift at gmail.com Thu Jul 25 12:21:08 2024 From: matthew.swift at gmail.com (Matthew Swift) Date: Thu, 25 Jul 2024 14:21:08 +0200 Subject: [External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: <323FD2E4-4902-48BD-9F62-2A2836DB860B@oracle.com> References: <12ACDD24-C874-45B1-9142-DACAB1E78956@oracle.com> <58e21790-551d-4717-ba16-17ccecbdaf22@oracle.com> <2F579C4D-B83F-4AC8-88BB-03723A34BD18@oracle.com> <323FD2E4-4902-48BD-9F62-2A2836DB860B@oracle.com> Message-ID: Hmm, I'm starting to think I may have fallen into the same trap here as Michal. I've been using virtual threads similar to platform threads for performing IO tasks asynchronously. Background: originally, I was using Executors#newVirtualThreadPerTaskExecutor to run these tasks, which was fine because the Executor tracks the virtual threads it creates in order to support shutdown. However, from an observability point of view I've found the executor to be a bit frustrating because it is impossible to set the thread name before the thread is scheduled to run[1]. This means that under heavy load where the FJ pool is busy a thread dump shows many unnamed threads, which are waiting to be scheduled for the first time. Admittedly, this is only a minor annoyance because I'm more interested in the threads that are clogging up the FJ pool than the ones which are waiting to use it, even so it'd be nice to have an overall picture of what's active and what's queued (note also thread names are included in JFR events, which is super helpful). To remedy this, I've switched away from using an Executor and now I just use "Thread.ofVirtual().name(initialName).start(task)". However, I don't think all of the tasks are strongly reachable - some are "fire and forget" tasks (e.g. async resource cleanup), so I may be inadvertently relying on the JVM's observability support to keep these tasks alive until they complete, which seems a bit brittle. In fact, now that I think of it, it may not even be limited to fire and forget tasks. A VT that is reading messages from a Socket could be GC'd IIUC since, I'm not maintaining references to the reader VT itself: * application creates/accepts Socket * application creates reader VT referencing the socket and starts the thread but doesn't keep a reference to the thread * reader VT terminates when either client closes the socket (EOS) or when the application closes the socket triggering an exception in the reader VT. In other words, there are strong references to the task and its state (e.g. Socket), but there is no strong reference to the task itself AFAICS, nor do I need one really, since the thread lifecycle is managed indirectly. I fear I may have a similar problem for VTs that are executing client requests - I maintain strong references to the task's state (e.g. request), but not the VT itself. Am I misunderstanding? Thanks :-) [1] VTs make thread naming very lightweight, which is great for debugging. For example, I've included connection information, a summary of request parameters and even updated the thread name to include internal routing information, DB index names, records and keys (making it easy to identify contended DB keys). On Tue, 23 Jul 2024 at 16:57, Ron Pressler wrote: > > > > On 22 Jul 2024, at 22:51, Michal Domagala wrote: > > > > Thanks for the explanation. > > > > I understand that paragraph > > > > "Unlike platform thread stacks, virtual thread stacks are not GC roots. > Thus the references they contain are not traversed in a stop-the-world > pause by garbage collectors, such as G1, that perform concurrent heap > scanning" > > > > can be rewritten as > > > > "Some GC, such as G1, marks GC roots in stop-the-world pause. Unlike > platform thread stacks, virtual thread stacks are not GC roots, therefore > they do not impact stop-the-world pause." > > > > In my opinion, the current paragraph in JEP 444 requires readers to have > a deep GC background. Usually, developers are not aware of GC root cost (at > least I was not aware). Developers could tune the number of GC roots by > changing the number of platform threads. Others, like static variables, are > rather not tunable. > > But usually, the OS limits the number of platform threads much more > strictly than GC performance. > > > > To sum up, JEP 444's message is: "Do not be afraid of the G1 initial > mark phase when using virtual threads". But I think most developers, like > me, never heard about it. Ohers, more advanced, could also never care about > it, because Oracle docs says about the initial mark phase: "This phase is > piggybacked on a normal (STW) young garbage collection.". I understand this > sentence as the phase is "for free". > > > > To sum up again: when a developer like me reads that VT is not GC root, > he does not see G1 profit behind. He reads: VT is GC'able. And the current > state, when behavior is different, is misleading. > > A virtual thread *is* GCable, just like a String, when it is not strongly > referenced. However, by default virtual threads will have a strong > reference for observability, but you can turn that off. > > But, yes, the very notion of GC roots requires an advanced understanding > of how the Java platform?s GCs work. I *think* that the very notion of GC > roots is not part of the spec, but an implementation detail. No inference > can be made, for any object, from whether or not it is a root, to when it > will be collected. In fact, the platform?s GC make no guarantees as to when > objects are collected, regardless of whether they?re roots or not. The only > guarantee is that an object will not be collected if it is strongly > reachable. > > ? Ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Thu Jul 25 12:54:59 2024 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 25 Jul 2024 13:54:59 +0100 Subject: [External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: References: <12ACDD24-C874-45B1-9142-DACAB1E78956@oracle.com> <58e21790-551d-4717-ba16-17ccecbdaf22@oracle.com> <2F579C4D-B83F-4AC8-88BB-03723A34BD18@oracle.com> <323FD2E4-4902-48BD-9F62-2A2836DB860B@oracle.com> Message-ID: <89a06f68-0eec-4fce-9d7d-000057440a1b@oracle.com> On 25/07/2024 13:21, Matthew Swift wrote: > Hmm, I'm starting to think I may have fallen into the same trap here > as Michal. > > I've been using virtual threads similar to platform threads for > performing IO tasks asynchronously. > > Background: originally, I was using > Executors#newVirtualThreadPerTaskExecutor to run these tasks, which > was fine because the Executor tracks the virtual threads it creates in > order to support shutdown. However, from an observability point of > view I've found the executor to be a bit frustrating because it is > impossible to set the thread name before the thread is scheduled to > run[1]. You can specify a ThreadFactory to newThreadPerTaskExecutor so you can set the thread name if you need it. Virtual threads are meant to be lightweight and numerous so don't get a name by default. For many cases, this is okay as the they have a thread ID which will identity them in thread dumps and elsewhere. > This means that under heavy load where the FJ pool is busy a thread > dump shows many unnamed threads, which are waiting to be scheduled for > the first time. Admittedly, this is only a minor annoyance because I'm > more interested in the threads that are clogging up the FJ pool than > the ones which are waiting to use it, even so it'd be nice to have an > overall picture of what's active and what's queued (note also thread > names are included in JFR events, which is super helpful). With the Loom EA builds [1] you can use `jcmd Thread.vthread_summary` to get a summary view of all thread grouping so you get thread counts, a summary of the scheduler, timers, and any socket I/O that it outstanding. We would like to bring this diagnostic command into the main line JDK at some point. > > To remedy this, I've switched away from using an Executor and now I > just use "Thread.ofVirtual().name(initialName).start(task)". However, > I don't think all of the tasks are strongly reachable - some are "fire > and forget" tasks (e.g. async resource cleanup), so I may be > inadvertently relying on the JVM's observability support to keep these > tasks alive until they complete, which seems a bit brittle. In fact, > now that I think of it, it may not even be limited to fire and forget > tasks. A VT that is reading messages from a Socket could be GC'd A virtual thread that is blocked reading from a Socket will continue when there are bytes to read, the peer closes the connection, some I/O exception, or the thread is interrupted. So it will be strongly reachable. -Alan [1] https://jdk.java.net/loom/ From robaho at icloud.com Thu Jul 25 13:05:52 2024 From: robaho at icloud.com (robert engels) Date: Thu, 25 Jul 2024 08:05:52 -0500 Subject: [External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: References: Message-ID: <8A9A26BA-960B-4239-814C-36C3F560C379@icloud.com> This is what I?ve been trying to state albeit obviously not very well. A VT must be a defacto ?root? or technically it can just disappear as soon as as it is created - if the creator doesn?t maintain a reference. This seems nonsensical to me. I believe section 12.6.1of the language spec covers this. Since it states that an object is reachable if it is reachable from any live thread. Thread ?liveness? is not specified based on reachability. Since the spec doesn?t include anything about Thread methods, a Thread must be ?live? independent of its reachability (observability from Thread.getAllStackTraces()), otherwise as soon as a Thread is created it it would be unreachable, and any objects it created would be unreachable as well. Since a virtual thread inherits from Thread, it must be a Thread, and thus should be governed by the same rules. > On Jul 25, 2024, at 7:22?AM, Matthew Swift wrote: > > ? > Hmm, I'm starting to think I may have fallen into the same trap here as Michal. > > I've been using virtual threads similar to platform threads for performing IO tasks asynchronously. > > Background: originally, I was using Executors#newVirtualThreadPerTaskExecutor to run these tasks, which was fine because the Executor tracks the virtual threads it creates in order to support shutdown. However, from an observability point of view I've found the executor to be a bit frustrating because it is impossible to set the thread name before the thread is scheduled to run[1]. This means that under heavy load where the FJ pool is busy a thread dump shows many unnamed threads, which are waiting to be scheduled for the first time. Admittedly, this is only a minor annoyance because I'm more interested in the threads that are clogging up the FJ pool than the ones which are waiting to use it, even so it'd be nice to have an overall picture of what's active and what's queued (note also thread names are included in JFR events, which is super helpful). > > To remedy this, I've switched away from using an Executor and now I just use "Thread.ofVirtual().name(initialName).start(task)". However, I don't think all of the tasks are strongly reachable - some are "fire and forget" tasks (e.g. async resource cleanup), so I may be inadvertently relying on the JVM's observability support to keep these tasks alive until they complete, which seems a bit brittle. In fact, now that I think of it, it may not even be limited to fire and forget tasks. A VT that is reading messages from a Socket could be GC'd IIUC since, I'm not maintaining references to the reader VT itself: > > * application creates/accepts Socket > * application creates reader VT referencing the socket and starts the thread but doesn't keep a reference to the thread > * reader VT terminates when either client closes the socket (EOS) or when the application closes the socket triggering an exception in the reader VT. > > In other words, there are strong references to the task and its state (e.g. Socket), but there is no strong reference to the task itself AFAICS, nor do I need one really, since the thread lifecycle is managed indirectly. I fear I may have a similar problem for VTs that are executing client requests - I maintain strong references to the task's state (e.g. request), but not the VT itself. > > Am I misunderstanding? > > Thanks :-) > > [1] VTs make thread naming very lightweight, which is great for debugging. For example, I've included connection information, a summary of request parameters and even updated the thread name to include internal routing information, DB index names, records and keys (making it easy to identify contended DB keys). > > On Tue, 23 Jul 2024 at 16:57, Ron Pressler > wrote: > > > > On 22 Jul 2024, at 22:51, Michal Domagala > wrote: > > > > Thanks for the explanation. > > > > I understand that paragraph > > > > "Unlike platform thread stacks, virtual thread stacks are not GC roots. Thus the references they contain are not traversed in a stop-the-world pause by garbage collectors, such as G1, that perform concurrent heap scanning" > > > > can be rewritten as > > > > "Some GC, such as G1, marks GC roots in stop-the-world pause. Unlike platform thread stacks, virtual thread stacks are not GC roots, therefore they do not impact stop-the-world pause." > > > > In my opinion, the current paragraph in JEP 444 requires readers to have a deep GC background. Usually, developers are not aware of GC root cost (at least I was not aware). Developers could tune the number of GC roots by changing the number of platform threads. Others, like static variables, are rather not tunable. > > But usually, the OS limits the number of platform threads much more strictly than GC performance. > > > > To sum up, JEP 444's message is: "Do not be afraid of the G1 initial mark phase when using virtual threads". But I think most developers, like me, never heard about it. Ohers, more advanced, could also never care about it, because Oracle docs says about the initial mark phase: "This phase is piggybacked on a normal (STW) young garbage collection.". I understand this sentence as the phase is "for free". > > > > To sum up again: when a developer like me reads that VT is not GC root, he does not see G1 profit behind. He reads: VT is GC'able. And the current state, when behavior is different, is misleading. > > A virtual thread *is* GCable, just like a String, when it is not strongly referenced. However, by default virtual threads will have a strong reference for observability, but you can turn that off. > > But, yes, the very notion of GC roots requires an advanced understanding of how the Java platform?s GCs work. I *think* that the very notion of GC roots is not part of the spec, but an implementation detail. No inference can be made, for any object, from whether or not it is a root, to when it will be collected. In fact, the platform?s GC make no guarantees as to when objects are collected, regardless of whether they?re roots or not. The only guarantee is that an object will not be collected if it is strongly reachable. > > ? Ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From robaho at icloud.com Thu Jul 25 13:12:42 2024 From: robaho at icloud.com (Robert Engels) Date: Thu, 25 Jul 2024 08:12:42 -0500 Subject: [External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: <8A9A26BA-960B-4239-814C-36C3F560C379@icloud.com> References: <8A9A26BA-960B-4239-814C-36C3F560C379@icloud.com> Message-ID: <076BCC86-4AF2-451F-9E26-8F0FF99EDC53@icloud.com> Here is a trivial example of why this must be so, Thread A: has WeakRef to object O. Thread B: Strong ref to object O. B blocks indefinitely on a queue that becomes unreachable except by B. ? other operations X1..Xn.. B sets O to null. ---- If B were ?cleaned up? auto-magically, O would no longer have a strong reference, A would see that O no longer existed, and could assume because of happens-before relationship that operations X1?Xn completed - which would break the happens-before relationship guarantees. Doing so would break sequential consistency. > On Jul 25, 2024, at 8:05 AM, robert engels wrote: > > This is what I?ve been trying to state albeit obviously not very well. > > A VT must be a defacto ?root? or technically it can just disappear as soon as as it is created - if the creator doesn?t maintain a reference. This seems nonsensical to me. > > I believe section 12.6.1of the language spec covers this. Since it states that an object is reachable if it is reachable from any live thread. Thread ?liveness? is not specified based on reachability. Since the spec doesn?t include anything about Thread methods, a Thread must be ?live? independent of its reachability (observability from Thread.getAllStackTraces()), otherwise as soon as a Thread is created it it would be unreachable, and any objects it created would be unreachable as well. > > Since a virtual thread inherits from Thread, it must be a Thread, and thus should be governed by the same rules. > >> On Jul 25, 2024, at 7:22?AM, Matthew Swift > wrote: >> >> ? >> Hmm, I'm starting to think I may have fallen into the same trap here as Michal. >> >> I've been using virtual threads similar to platform threads for performing IO tasks asynchronously. >> >> Background: originally, I was using Executors#newVirtualThreadPerTaskExecutor to run these tasks, which was fine because the Executor tracks the virtual threads it creates in order to support shutdown. However, from an observability point of view I've found the executor to be a bit frustrating because it is impossible to set the thread name before the thread is scheduled to run[1]. This means that under heavy load where the FJ pool is busy a thread dump shows many unnamed threads, which are waiting to be scheduled for the first time. Admittedly, this is only a minor annoyance because I'm more interested in the threads that are clogging up the FJ pool than the ones which are waiting to use it, even so it'd be nice to have an overall picture of what's active and what's queued (note also thread names are included in JFR events, which is super helpful). >> >> To remedy this, I've switched away from using an Executor and now I just use "Thread.ofVirtual().name(initialName).start(task)". However, I don't think all of the tasks are strongly reachable - some are "fire and forget" tasks (e.g. async resource cleanup), so I may be inadvertently relying on the JVM's observability support to keep these tasks alive until they complete, which seems a bit brittle. In fact, now that I think of it, it may not even be limited to fire and forget tasks. A VT that is reading messages from a Socket could be GC'd IIUC since, I'm not maintaining references to the reader VT itself: >> >> * application creates/accepts Socket >> * application creates reader VT referencing the socket and starts the thread but doesn't keep a reference to the thread >> * reader VT terminates when either client closes the socket (EOS) or when the application closes the socket triggering an exception in the reader VT. >> >> In other words, there are strong references to the task and its state (e.g. Socket), but there is no strong reference to the task itself AFAICS, nor do I need one really, since the thread lifecycle is managed indirectly. I fear I may have a similar problem for VTs that are executing client requests - I maintain strong references to the task's state (e.g. request), but not the VT itself. >> >> Am I misunderstanding? >> >> Thanks :-) >> >> [1] VTs make thread naming very lightweight, which is great for debugging. For example, I've included connection information, a summary of request parameters and even updated the thread name to include internal routing information, DB index names, records and keys (making it easy to identify contended DB keys). >> >> On Tue, 23 Jul 2024 at 16:57, Ron Pressler > wrote: >> >> >> > On 22 Jul 2024, at 22:51, Michal Domagala > wrote: >> > >> > Thanks for the explanation. >> > >> > I understand that paragraph >> > >> > "Unlike platform thread stacks, virtual thread stacks are not GC roots. Thus the references they contain are not traversed in a stop-the-world pause by garbage collectors, such as G1, that perform concurrent heap scanning" >> > >> > can be rewritten as >> > >> > "Some GC, such as G1, marks GC roots in stop-the-world pause. Unlike platform thread stacks, virtual thread stacks are not GC roots, therefore they do not impact stop-the-world pause." >> > >> > In my opinion, the current paragraph in JEP 444 requires readers to have a deep GC background. Usually, developers are not aware of GC root cost (at least I was not aware). Developers could tune the number of GC roots by changing the number of platform threads. Others, like static variables, are rather not tunable. >> > But usually, the OS limits the number of platform threads much more strictly than GC performance. >> > >> > To sum up, JEP 444's message is: "Do not be afraid of the G1 initial mark phase when using virtual threads". But I think most developers, like me, never heard about it. Ohers, more advanced, could also never care about it, because Oracle docs says about the initial mark phase: "This phase is piggybacked on a normal (STW) young garbage collection.". I understand this sentence as the phase is "for free". >> > >> > To sum up again: when a developer like me reads that VT is not GC root, he does not see G1 profit behind. He reads: VT is GC'able. And the current state, when behavior is different, is misleading. >> >> A virtual thread *is* GCable, just like a String, when it is not strongly referenced. However, by default virtual threads will have a strong reference for observability, but you can turn that off. >> >> But, yes, the very notion of GC roots requires an advanced understanding of how the Java platform?s GCs work. I *think* that the very notion of GC roots is not part of the spec, but an implementation detail. No inference can be made, for any object, from whether or not it is a root, to when it will be collected. In fact, the platform?s GC make no guarantees as to when objects are collected, regardless of whether they?re roots or not. The only guarantee is that an object will not be collected if it is strongly reachable. >> >> ? Ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.swift at gmail.com Thu Jul 25 13:49:21 2024 From: matthew.swift at gmail.com (Matthew Swift) Date: Thu, 25 Jul 2024 15:49:21 +0200 Subject: [External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: <89a06f68-0eec-4fce-9d7d-000057440a1b@oracle.com> References: <12ACDD24-C874-45B1-9142-DACAB1E78956@oracle.com> <58e21790-551d-4717-ba16-17ccecbdaf22@oracle.com> <2F579C4D-B83F-4AC8-88BB-03723A34BD18@oracle.com> <323FD2E4-4902-48BD-9F62-2A2836DB860B@oracle.com> <89a06f68-0eec-4fce-9d7d-000057440a1b@oracle.com> Message-ID: Thanks for the quick response Alan. A couple of comments: > You can specify a ThreadFactory to newThreadPerTaskExecutor so you can > set the thread name if you need it. Virtual threads are meant to be > lightweight and numerous so don't get a name by default. For many cases, > this is okay as the they have a thread ID which will identity them in > thread dumps and elsewhere. That may be so, but it's not very flexible, unless I'm missing something, because it's not possible to derive the thread name from the task itself. Said otherwise, a ThreadFactory lets you create very generic thread names like "HTTP Connection #1" ahead of time, but doesn't let you derive a rich name from the Runnable itself, like "HTTP Connection from 1.2.3.4 to 5.6.7.8 on port 8080". I tried cheating a bit by relying on the toString() of the Runnable, but sadly this doesn't work because the executor wraps the provided Runnable before calling the thread factory (see ThreadPerTaskExecutor#start(java.lang.Runnable)). > A virtual thread that is blocked reading from a Socket will continue > when there are bytes to read, the peer closes the connection, some I/O > exception, or the thread is interrupted. So it will be strongly reachable. Ah, of course, silly me. And, following from that, the VT is strongly reachable when running because it is directly referenced by the carrier thread itself. Thanks Matt On Thu, 25 Jul 2024 at 14:55, Alan Bateman wrote: > > > On 25/07/2024 13:21, Matthew Swift wrote: > > Hmm, I'm starting to think I may have fallen into the same trap here > > as Michal. > > > > I've been using virtual threads similar to platform threads for > > performing IO tasks asynchronously. > > > > Background: originally, I was using > > Executors#newVirtualThreadPerTaskExecutor to run these tasks, which > > was fine because the Executor tracks the virtual threads it creates in > > order to support shutdown. However, from an observability point of > > view I've found the executor to be a bit frustrating because it is > > impossible to set the thread name before the thread is scheduled to > > run[1]. > You can specify a ThreadFactory to newThreadPerTaskExecutor so you can > set the thread name if you need it. Virtual threads are meant to be > lightweight and numerous so don't get a name by default. For many cases, > this is okay as the they have a thread ID which will identity them in > thread dumps and elsewhere. > > > > This means that under heavy load where the FJ pool is busy a thread > > dump shows many unnamed threads, which are waiting to be scheduled for > > the first time. Admittedly, this is only a minor annoyance because I'm > > more interested in the threads that are clogging up the FJ pool than > > the ones which are waiting to use it, even so it'd be nice to have an > > overall picture of what's active and what's queued (note also thread > > names are included in JFR events, which is super helpful). > > With the Loom EA builds [1] you can use `jcmd > Thread.vthread_summary` to get a summary view of all thread grouping so > you get thread counts, a summary of the scheduler, timers, and any > socket I/O that it outstanding. We would like to bring this diagnostic > command into the main line JDK at some point. > > > > > To remedy this, I've switched away from using an Executor and now I > > just use "Thread.ofVirtual().name(initialName).start(task)". However, > > I don't think all of the tasks are strongly reachable - some are "fire > > and forget" tasks (e.g. async resource cleanup), so I may be > > inadvertently relying on the JVM's observability support to keep these > > tasks alive until they complete, which seems a bit brittle. In fact, > > now that I think of it, it may not even be limited to fire and forget > > tasks. A VT that is reading messages from a Socket could be GC'd > A virtual thread that is blocked reading from a Socket will continue > when there are bytes to read, the peer closes the connection, some I/O > exception, or the thread is interrupted. So it will be strongly reachable. > > -Alan > > [1] https://jdk.java.net/loom/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robaho at icloud.com Thu Jul 25 13:52:43 2024 From: robaho at icloud.com (Robert Engels) Date: Thu, 25 Jul 2024 08:52:43 -0500 Subject: [External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: References: <12ACDD24-C874-45B1-9142-DACAB1E78956@oracle.com> <58e21790-551d-4717-ba16-17ccecbdaf22@oracle.com> <2F579C4D-B83F-4AC8-88BB-03723A34BD18@oracle.com> <323FD2E4-4902-48BD-9F62-2A2836DB860B@oracle.com> <89a06f68-0eec-4fce-9d7d-000057440a1b@oracle.com> Message-ID: <3FA9AD3E-BF31-4FF2-BB60-FCAEDADF228E@icloud.com> If it is blocked reading a socket, it is not on a CarrierThread (i.e. blocked not running) so there is no strong reference from the CarrierThread to the VirtualThread in this case. I am fairly certain that the scheduler/blocking handler is what maintains the strong thread references in this case. > On Jul 25, 2024, at 8:49 AM, Matthew Swift wrote: > > Thanks for the quick response Alan. A couple of comments: > > > You can specify a ThreadFactory to newThreadPerTaskExecutor so you can > > set the thread name if you need it. Virtual threads are meant to be > > lightweight and numerous so don't get a name by default. For many cases, > > this is okay as the they have a thread ID which will identity them in > > thread dumps and elsewhere. > > That may be so, but it's not very flexible, unless I'm missing something, because it's not possible to derive the thread name from the task itself. Said otherwise, a ThreadFactory lets you create very generic thread names like "HTTP Connection #1" ahead of time, but doesn't let you derive a rich name from the Runnable itself, like "HTTP Connection from 1.2.3.4 to 5.6.7.8 on port 8080". I tried cheating a bit by relying on the toString() of the Runnable, but sadly this doesn't work because the executor wraps the provided Runnable before calling the thread factory (see ThreadPerTaskExecutor#start(java.lang.Runnable)). > > > A virtual thread that is blocked reading from a Socket will continue > > when there are bytes to read, the peer closes the connection, some I/O > > exception, or the thread is interrupted. So it will be strongly reachable. > > Ah, of course, silly me. And, following from that, the VT is strongly reachable when running because it is directly referenced by the carrier thread itself. > > Thanks > Matt > > > On Thu, 25 Jul 2024 at 14:55, Alan Bateman > wrote: > > > On 25/07/2024 13:21, Matthew Swift wrote: > > Hmm, I'm starting to think I may have fallen into the same trap here > > as Michal. > > > > I've been using virtual threads similar to platform threads for > > performing IO tasks asynchronously. > > > > Background: originally, I was using > > Executors#newVirtualThreadPerTaskExecutor to run these tasks, which > > was fine because the Executor tracks the virtual threads it creates in > > order to support shutdown. However, from an observability point of > > view I've found the executor to be a bit frustrating because it is > > impossible to set the thread name before the thread is scheduled to > > run[1]. > You can specify a ThreadFactory to newThreadPerTaskExecutor so you can > set the thread name if you need it. Virtual threads are meant to be > lightweight and numerous so don't get a name by default. For many cases, > this is okay as the they have a thread ID which will identity them in > thread dumps and elsewhere. > > > > This means that under heavy load where the FJ pool is busy a thread > > dump shows many unnamed threads, which are waiting to be scheduled for > > the first time. Admittedly, this is only a minor annoyance because I'm > > more interested in the threads that are clogging up the FJ pool than > > the ones which are waiting to use it, even so it'd be nice to have an > > overall picture of what's active and what's queued (note also thread > > names are included in JFR events, which is super helpful). > > With the Loom EA builds [1] you can use `jcmd > Thread.vthread_summary` to get a summary view of all thread grouping so > you get thread counts, a summary of the scheduler, timers, and any > socket I/O that it outstanding. We would like to bring this diagnostic > command into the main line JDK at some point. > > > > > To remedy this, I've switched away from using an Executor and now I > > just use "Thread.ofVirtual().name(initialName).start(task)". However, > > I don't think all of the tasks are strongly reachable - some are "fire > > and forget" tasks (e.g. async resource cleanup), so I may be > > inadvertently relying on the JVM's observability support to keep these > > tasks alive until they complete, which seems a bit brittle. In fact, > > now that I think of it, it may not even be limited to fire and forget > > tasks. A VT that is reading messages from a Socket could be GC'd > A virtual thread that is blocked reading from a Socket will continue > when there are bytes to read, the peer closes the connection, some I/O > exception, or the thread is interrupted. So it will be strongly reachable. > > -Alan > > [1] https://jdk.java.net/loom/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.swift at gmail.com Thu Jul 25 14:44:11 2024 From: matthew.swift at gmail.com (Matthew Swift) Date: Thu, 25 Jul 2024 16:44:11 +0200 Subject: [External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: <3FA9AD3E-BF31-4FF2-BB60-FCAEDADF228E@icloud.com> References: <12ACDD24-C874-45B1-9142-DACAB1E78956@oracle.com> <58e21790-551d-4717-ba16-17ccecbdaf22@oracle.com> <2F579C4D-B83F-4AC8-88BB-03723A34BD18@oracle.com> <323FD2E4-4902-48BD-9F62-2A2836DB860B@oracle.com> <89a06f68-0eec-4fce-9d7d-000057440a1b@oracle.com> <3FA9AD3E-BF31-4FF2-BB60-FCAEDADF228E@icloud.com> Message-ID: I agree Robert, that's my understanding from Alan's previous response: * when blocked, a VT is referenced by the scheduler or wait lists on locks, etc * when running, a VT is referenced by the carrier thread. >From a life-cycle point of view, a VT "is a" Thread, as you correctly say. On Thu, 25 Jul 2024 at 15:52, Robert Engels wrote: > If it is blocked reading a socket, it is not on a CarrierThread (i.e. > blocked not running) so there is no strong reference from the CarrierThread > to the VirtualThread in this case. > > I am fairly certain that the scheduler/blocking handler is what maintains > the strong thread references in this case. > > On Jul 25, 2024, at 8:49 AM, Matthew Swift > wrote: > > Thanks for the quick response Alan. A couple of comments: > > > You can specify a ThreadFactory to newThreadPerTaskExecutor so you can > > set the thread name if you need it. Virtual threads are meant to be > > lightweight and numerous so don't get a name by default. For many cases, > > this is okay as the they have a thread ID which will identity them in > > thread dumps and elsewhere. > > That may be so, but it's not very flexible, unless I'm missing something, > because it's not possible to derive the thread name from the task itself. > Said otherwise, a ThreadFactory lets you create very generic thread names > like "HTTP Connection #1" ahead of time, but doesn't let you derive a rich > name from the Runnable itself, like "HTTP Connection from 1.2.3.4 to > 5.6.7.8 on port 8080". I tried cheating a bit by relying on the toString() > of the Runnable, but sadly this doesn't work because the executor wraps the > provided Runnable before calling the thread factory (see > ThreadPerTaskExecutor#start(java.lang.Runnable)). > > > A virtual thread that is blocked reading from a Socket will continue > > when there are bytes to read, the peer closes the connection, some I/O > > exception, or the thread is interrupted. So it will be strongly > reachable. > > Ah, of course, silly me. And, following from that, the VT is strongly > reachable when running because it is directly referenced by the carrier > thread itself. > > Thanks > Matt > > > On Thu, 25 Jul 2024 at 14:55, Alan Bateman > wrote: > >> >> >> On 25/07/2024 13:21, Matthew Swift wrote: >> > Hmm, I'm starting to think I may have fallen into the same trap here >> > as Michal. >> > >> > I've been using virtual threads similar to platform threads for >> > performing IO tasks asynchronously. >> > >> > Background: originally, I was using >> > Executors#newVirtualThreadPerTaskExecutor to run these tasks, which >> > was fine because the Executor tracks the virtual threads it creates in >> > order to support shutdown. However, from an observability point of >> > view I've found the executor to be a bit frustrating because it is >> > impossible to set the thread name before the thread is scheduled to >> > run[1]. >> You can specify a ThreadFactory to newThreadPerTaskExecutor so you can >> set the thread name if you need it. Virtual threads are meant to be >> lightweight and numerous so don't get a name by default. For many cases, >> this is okay as the they have a thread ID which will identity them in >> thread dumps and elsewhere. >> >> >> > This means that under heavy load where the FJ pool is busy a thread >> > dump shows many unnamed threads, which are waiting to be scheduled for >> > the first time. Admittedly, this is only a minor annoyance because I'm >> > more interested in the threads that are clogging up the FJ pool than >> > the ones which are waiting to use it, even so it'd be nice to have an >> > overall picture of what's active and what's queued (note also thread >> > names are included in JFR events, which is super helpful). >> >> With the Loom EA builds [1] you can use `jcmd >> Thread.vthread_summary` to get a summary view of all thread grouping so >> you get thread counts, a summary of the scheduler, timers, and any >> socket I/O that it outstanding. We would like to bring this diagnostic >> command into the main line JDK at some point. >> >> > >> > To remedy this, I've switched away from using an Executor and now I >> > just use "Thread.ofVirtual().name(initialName).start(task)". However, >> > I don't think all of the tasks are strongly reachable - some are "fire >> > and forget" tasks (e.g. async resource cleanup), so I may be >> > inadvertently relying on the JVM's observability support to keep these >> > tasks alive until they complete, which seems a bit brittle. In fact, >> > now that I think of it, it may not even be limited to fire and forget >> > tasks. A VT that is reading messages from a Socket could be GC'd >> A virtual thread that is blocked reading from a Socket will continue >> when there are bytes to read, the peer closes the connection, some I/O >> exception, or the thread is interrupted. So it will be strongly reachable. >> >> -Alan >> >> [1] https://jdk.java.net/loom/ >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robaho at icloud.com Thu Jul 25 15:17:20 2024 From: robaho at icloud.com (Robert Engels) Date: Thu, 25 Jul 2024 10:17:20 -0500 Subject: [External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: References: <12ACDD24-C874-45B1-9142-DACAB1E78956@oracle.com> <58e21790-551d-4717-ba16-17ccecbdaf22@oracle.com> <2F579C4D-B83F-4AC8-88BB-03723A34BD18@oracle.com> <323FD2E4-4902-48BD-9F62-2A2836DB860B@oracle.com> <89a06f68-0eec-4fce-9d7d-000057440a1b@oracle.com> <3FA9AD3E-BF31-4FF2-BB60-FCAEDADF228E@icloud.com> Message-ID: <9F42BD8F-B5CB-4655-9D01-6081580213FD@icloud.com> I have created a very simple unbounded FIFO queue designed for use with virtual threads to better ensure thread clean-up without the reliance of automatic clean-up of VTs. You can review the project here https://github.com/robaho/closablequeue > On Jul 25, 2024, at 9:44 AM, Matthew Swift wrote: > > I agree Robert, that's my understanding from Alan's previous response: > > * when blocked, a VT is referenced by the scheduler or wait lists on locks, etc > * when running, a VT is referenced by the carrier thread. > > From a life-cycle point of view, a VT "is a" Thread, as you correctly say. > > > On Thu, 25 Jul 2024 at 15:52, Robert Engels > wrote: > If it is blocked reading a socket, it is not on a CarrierThread (i.e. blocked not running) so there is no strong reference from the CarrierThread to the VirtualThread in this case. > > I am fairly certain that the scheduler/blocking handler is what maintains the strong thread references in this case. > >> On Jul 25, 2024, at 8:49 AM, Matthew Swift > wrote: >> >> Thanks for the quick response Alan. A couple of comments: >> >> > You can specify a ThreadFactory to newThreadPerTaskExecutor so you can >> > set the thread name if you need it. Virtual threads are meant to be >> > lightweight and numerous so don't get a name by default. For many cases, >> > this is okay as the they have a thread ID which will identity them in >> > thread dumps and elsewhere. >> >> That may be so, but it's not very flexible, unless I'm missing something, because it's not possible to derive the thread name from the task itself. Said otherwise, a ThreadFactory lets you create very generic thread names like "HTTP Connection #1" ahead of time, but doesn't let you derive a rich name from the Runnable itself, like "HTTP Connection from 1.2.3.4 to 5.6.7.8 on port 8080". I tried cheating a bit by relying on the toString() of the Runnable, but sadly this doesn't work because the executor wraps the provided Runnable before calling the thread factory (see ThreadPerTaskExecutor#start(java.lang.Runnable)). >> >> > A virtual thread that is blocked reading from a Socket will continue >> > when there are bytes to read, the peer closes the connection, some I/O >> > exception, or the thread is interrupted. So it will be strongly reachable. >> >> Ah, of course, silly me. And, following from that, the VT is strongly reachable when running because it is directly referenced by the carrier thread itself. >> >> Thanks >> Matt >> >> >> On Thu, 25 Jul 2024 at 14:55, Alan Bateman > wrote: >> >> >> On 25/07/2024 13:21, Matthew Swift wrote: >> > Hmm, I'm starting to think I may have fallen into the same trap here >> > as Michal. >> > >> > I've been using virtual threads similar to platform threads for >> > performing IO tasks asynchronously. >> > >> > Background: originally, I was using >> > Executors#newVirtualThreadPerTaskExecutor to run these tasks, which >> > was fine because the Executor tracks the virtual threads it creates in >> > order to support shutdown. However, from an observability point of >> > view I've found the executor to be a bit frustrating because it is >> > impossible to set the thread name before the thread is scheduled to >> > run[1]. >> You can specify a ThreadFactory to newThreadPerTaskExecutor so you can >> set the thread name if you need it. Virtual threads are meant to be >> lightweight and numerous so don't get a name by default. For many cases, >> this is okay as the they have a thread ID which will identity them in >> thread dumps and elsewhere. >> >> >> > This means that under heavy load where the FJ pool is busy a thread >> > dump shows many unnamed threads, which are waiting to be scheduled for >> > the first time. Admittedly, this is only a minor annoyance because I'm >> > more interested in the threads that are clogging up the FJ pool than >> > the ones which are waiting to use it, even so it'd be nice to have an >> > overall picture of what's active and what's queued (note also thread >> > names are included in JFR events, which is super helpful). >> >> With the Loom EA builds [1] you can use `jcmd >> Thread.vthread_summary` to get a summary view of all thread grouping so >> you get thread counts, a summary of the scheduler, timers, and any >> socket I/O that it outstanding. We would like to bring this diagnostic >> command into the main line JDK at some point. >> >> > >> > To remedy this, I've switched away from using an Executor and now I >> > just use "Thread.ofVirtual().name(initialName).start(task)". However, >> > I don't think all of the tasks are strongly reachable - some are "fire >> > and forget" tasks (e.g. async resource cleanup), so I may be >> > inadvertently relying on the JVM's observability support to keep these >> > tasks alive until they complete, which seems a bit brittle. In fact, >> > now that I think of it, it may not even be limited to fire and forget >> > tasks. A VT that is reading messages from a Socket could be GC'd >> A virtual thread that is blocked reading from a Socket will continue >> when there are bytes to read, the peer closes the connection, some I/O >> exception, or the thread is interrupted. So it will be strongly reachable. >> >> -Alan >> >> [1] https://jdk.java.net/loom/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Fri Jul 26 07:54:33 2024 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 26 Jul 2024 08:54:33 +0100 Subject: [External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: References: <12ACDD24-C874-45B1-9142-DACAB1E78956@oracle.com> <58e21790-551d-4717-ba16-17ccecbdaf22@oracle.com> <2F579C4D-B83F-4AC8-88BB-03723A34BD18@oracle.com> <323FD2E4-4902-48BD-9F62-2A2836DB860B@oracle.com> <89a06f68-0eec-4fce-9d7d-000057440a1b@oracle.com> Message-ID: <9d653aad-8b17-4425-b500-17e77f96eb21@oracle.com> On 25/07/2024 14:49, Matthew Swift wrote: > : > > That may be so, but it's not very flexible, unless I'm missing > something, because it's not possible to derive the thread name from > the task itself. Said otherwise, a ThreadFactory lets you create very > generic thread names like "HTTP Connection #1" ahead of time, but > doesn't let you derive a rich name from the Runnable itself, like > "HTTP Connection from 1.2.3.4 to 5.6.7.8 on port 8080". I tried > cheating a bit by relying on the toString() of the Runnable, but sadly > this doesn't work because the executor wraps the provided Runnable > before calling the thread factory (see > ThreadPerTaskExecutor#start(java.lang.Runnable)). Okay, so this isn't really anything specific to virtual threads, and not specific to TPTE either, instead I think you are asking for an overload of ES.submit that allows you to set the thread name for the duration of the task.? Maybe you've tried this already but a thread can change its own name so you can set it at the start of the task or just wrap the TPTE to set the name. With a new virtual thread per task then you don't have to restore it as the thread terminates immediately after the task completes. -Alan From duke at openjdk.org Sat Jul 27 07:06:54 2024 From: duke at openjdk.org (duke) Date: Sat, 27 Jul 2024 07:06:54 GMT Subject: git: openjdk/loom: fibers: 30 new changesets Message-ID: <0444d31b-6f96-4771-95f6-f6580f614cc6@openjdk.org> Changeset: 9d879186 Branch: fibers Author: Hamlin Li Date: 2024-07-25 07:47:45 +0000 URL: https://git.openjdk.org/loom/commit/9d8791864ec48f3321707d7f7805cd3618fc3b51 8335191: RISC-V: verify perf of chacha20 Reviewed-by: fyang ! src/hotspot/cpu/riscv/vm_version_riscv.cpp Changeset: 8081f870 Branch: fibers Author: Shaojin Wen Committer: Tobias Hartmann Date: 2024-07-25 09:16:32 +0000 URL: https://git.openjdk.org/loom/commit/8081f8702a89c4895302377be62da22fc34f2c74 8334342: Add MergeStore JMH benchmarks Reviewed-by: epeter, thartmann + test/micro/org/openjdk/bench/vm/compiler/MergeStoreBench.java Changeset: 3baff2af Branch: fibers Author: Roland Westrelin Date: 2024-07-25 09:26:11 +0000 URL: https://git.openjdk.org/loom/commit/3baff2af6a30cc6cb2e0d4391db1cf7e61c33f64 8335393: C2: assert(!had_error) failed: bad dominance Reviewed-by: thartmann, chagedorn ! src/hotspot/share/opto/loopTransform.cpp + test/hotspot/jtreg/compiler/rangechecks/TestEmptyLoopDeadCast.java Changeset: 00b53481 Branch: fibers Author: Albert Mingkun Yang Date: 2024-07-25 13:16:31 +0000 URL: https://git.openjdk.org/loom/commit/00b53481064ed1ca914008d06ce5b530ca7ffe16 8337192: [BACKOUT] JDK-8336098 G1: Refactor G1RebuildRSAndScrubTask Reviewed-by: tschatzl ! src/hotspot/share/gc/g1/g1ConcurrentRebuildAndScrub.cpp Changeset: 34ee06f5 Branch: fibers Author: Vicente Romero Date: 2024-07-25 13:41:32 +0000 URL: https://git.openjdk.org/loom/commit/34ee06f51122e8afb875cc3b75f513912272fd9b 8332850: javac crashes if container for repeatable annotation is not found Reviewed-by: darcy ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Annotate.java + test/langtools/tools/javac/annotations/repeatingAnnotations/CompletionErrorOnRepeatingAnnosTest.java Changeset: f61a5059 Branch: fibers Author: Roland Westrelin Date: 2024-07-25 15:45:41 +0000 URL: https://git.openjdk.org/loom/commit/f61a50598958e928e9a4d81130b077cd6eaf876a 8334647: C2: CastII added by PhaseIdealLoop::add_template_assertion_predicate() should have control Reviewed-by: chagedorn, kvn ! src/hotspot/share/opto/castnode.hpp ! src/hotspot/share/opto/loopPredicate.cpp ! src/hotspot/share/opto/loopTransform.cpp ! src/hotspot/share/opto/loopopts.cpp ! src/hotspot/share/opto/vectorIntrinsics.cpp Changeset: e74edbae Branch: fibers Author: Xiaolong Peng Committer: Aleksey Shipilev Date: 2024-07-25 16:04:58 +0000 URL: https://git.openjdk.org/loom/commit/e74edbaea9f09169f597a470f647f3b7d10cc71b 8336640: Shenandoah: Parallel worker use in parallel_heap_region_iterate Reviewed-by: shade, wkemper, ysr ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp Changeset: 81ed0287 Branch: fibers Author: Jorn Vernee Date: 2024-07-25 16:36:31 +0000 URL: https://git.openjdk.org/loom/commit/81ed0287175617e6f7ad79dd7036b2fbde27e80a 8337060: Test java/foreign/TestConcurrentClose.java failed: IllegalStateException: SegmentAccessor::doAccess method not being compiled Reviewed-by: mcimadamore, alanb ! test/jdk/java/foreign/TestConcurrentClose.java Changeset: cf0d9e0e Branch: fibers Author: Vicente Romero Date: 2024-07-25 17:03:45 +0000 URL: https://git.openjdk.org/loom/commit/cf0d9e0e521b495a96a3de7775b1b3ae14d20d80 8337037: compiler internal options are not printing the stacktrace after a compiler crash Reviewed-by: mcimadamore ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/PoolWriter.java + src/jdk.compiler/share/classes/com/sun/tools/javac/util/CompilerInternalException.java ! src/jdk.jshell/share/classes/jdk/jshell/TreeDissector.java Changeset: b5b5a5b8 Branch: fibers Author: Weijun Wang Date: 2024-07-25 17:11:59 +0000 URL: https://git.openjdk.org/loom/commit/b5b5a5b8e54ebd766456d2a4781a806ff97816a8 8336667: IAE in DerInputStream.toByteArray Reviewed-by: valeriep ! src/java.base/share/classes/sun/security/util/DerInputStream.java + test/jdk/sun/security/util/DerInputBuffer/B8336667/PoC.java + test/jdk/sun/security/util/DerInputBuffer/B8336667/Reproducer.java Changeset: 8c28f25e Branch: fibers Author: Brian Burkhalter Date: 2024-07-25 20:59:48 +0000 URL: https://git.openjdk.org/loom/commit/8c28f25e1383f10a78b05e47ccf1cc4262069e69 8337124: (fs) sun.nio.fs.WindowsSecurity.enablePrivilege should pin when continuations supported Reviewed-by: jpai, alanb ! src/java.base/windows/classes/sun/nio/fs/WindowsSecurity.java Changeset: 0584af23 Branch: fibers Author: William Kemper Date: 2024-07-25 23:59:56 +0000 URL: https://git.openjdk.org/loom/commit/0584af23255b6b8f49190eaf2618f3bcc299adfe 8336685: Shenandoah: Remove experimental incremental update mode Reviewed-by: shade ! src/hotspot/cpu/aarch64/gc/shenandoah/c1/shenandoahBarrierSetC1_aarch64.cpp ! src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.hpp ! src/hotspot/cpu/ppc/gc/shenandoah/c1/shenandoahBarrierSetC1_ppc.cpp ! src/hotspot/cpu/ppc/gc/shenandoah/shenandoahBarrierSetAssembler_ppc.cpp ! src/hotspot/cpu/ppc/gc/shenandoah/shenandoahBarrierSetAssembler_ppc.hpp ! src/hotspot/cpu/riscv/gc/shenandoah/c1/shenandoahBarrierSetC1_riscv.cpp ! src/hotspot/cpu/riscv/gc/shenandoah/shenandoahBarrierSetAssembler_riscv.cpp ! src/hotspot/cpu/riscv/gc/shenandoah/shenandoahBarrierSetAssembler_riscv.hpp ! src/hotspot/cpu/x86/gc/shenandoah/c1/shenandoahBarrierSetC1_x86.cpp ! src/hotspot/cpu/x86/gc/shenandoah/shenandoahBarrierSetAssembler_x86.cpp ! src/hotspot/cpu/x86/gc/shenandoah/shenandoahBarrierSetAssembler_x86.hpp ! src/hotspot/share/gc/shenandoah/c1/shenandoahBarrierSetC1.cpp ! src/hotspot/share/gc/shenandoah/c1/shenandoahBarrierSetC1.hpp ! src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.cpp ! src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.hpp ! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp ! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.hpp - src/hotspot/share/gc/shenandoah/mode/shenandoahIUMode.cpp - src/hotspot/share/gc/shenandoah/mode/shenandoahIUMode.hpp ! src/hotspot/share/gc/shenandoah/mode/shenandoahPassiveMode.cpp ! src/hotspot/share/gc/shenandoah/mode/shenandoahSATBMode.cpp ! src/hotspot/share/gc/shenandoah/shenandoahArguments.cpp ! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.cpp ! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.hpp ! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahBarrierSetClone.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp ! src/hotspot/share/opto/classes.hpp ! test/hotspot/jtreg/compiler/c2/aarch64/TestVolatiles.java ! test/hotspot/jtreg/compiler/c2/aarch64/TestVolatilesShenandoah.java ! test/hotspot/jtreg/gc/TestAllocHumongousFragment.java ! test/hotspot/jtreg/gc/shenandoah/TestAllocIntArrays.java ! test/hotspot/jtreg/gc/shenandoah/TestAllocObjectArrays.java ! test/hotspot/jtreg/gc/shenandoah/TestAllocObjects.java ! test/hotspot/jtreg/gc/shenandoah/TestDynamicSoftMaxHeapSize.java ! test/hotspot/jtreg/gc/shenandoah/TestGCThreadGroups.java ! test/hotspot/jtreg/gc/shenandoah/TestHeapUncommit.java ! test/hotspot/jtreg/gc/shenandoah/TestJcmdHeapDump.java ! test/hotspot/jtreg/gc/shenandoah/TestLotsOfCycles.java ! test/hotspot/jtreg/gc/shenandoah/TestObjItrWithHeapDump.java ! test/hotspot/jtreg/gc/shenandoah/TestPeriodicGC.java ! test/hotspot/jtreg/gc/shenandoah/TestReferenceRefersToShenandoah.java ! test/hotspot/jtreg/gc/shenandoah/TestReferenceShortcutCycle.java ! test/hotspot/jtreg/gc/shenandoah/TestRefprocSanity.java ! test/hotspot/jtreg/gc/shenandoah/TestRegionSampling.java ! test/hotspot/jtreg/gc/shenandoah/TestResizeTLAB.java ! test/hotspot/jtreg/gc/shenandoah/TestRetainObjects.java ! test/hotspot/jtreg/gc/shenandoah/TestSieveObjects.java ! test/hotspot/jtreg/gc/shenandoah/TestStringDedup.java ! test/hotspot/jtreg/gc/shenandoah/TestStringDedupStress.java ! test/hotspot/jtreg/gc/shenandoah/TestStringInternCleanup.java ! test/hotspot/jtreg/gc/shenandoah/TestVerifyJCStress.java ! test/hotspot/jtreg/gc/shenandoah/TestWrongArrayMember.java ! test/hotspot/jtreg/gc/shenandoah/compiler/BarrierInInfiniteLoop.java - test/hotspot/jtreg/gc/shenandoah/compiler/TestUnexpectedIUBarrierEA.java ! test/hotspot/jtreg/gc/shenandoah/mxbeans/TestChurnNotifications.java ! test/hotspot/jtreg/gc/shenandoah/mxbeans/TestPauseNotifications.java ! test/hotspot/jtreg/gc/shenandoah/oom/TestClassLoaderLeak.java ! test/hotspot/jtreg/gc/shenandoah/options/TestExplicitGC.java ! test/hotspot/jtreg/gc/shenandoah/options/TestModeUnlock.java ! test/hotspot/jtreg/gc/shenandoah/options/TestSelectiveBarrierFlags.java ! test/hotspot/jtreg/gc/shenandoah/options/TestWrongBarrierDisable.java ! test/hotspot/jtreg/gc/shenandoah/options/TestWrongBarrierEnable.java ! test/hotspot/jtreg/gc/stress/gcbasher/TestGCBasherWithShenandoah.java ! test/hotspot/jtreg/gc/stress/gcold/TestGCOldWithShenandoah.java ! test/hotspot/jtreg/gc/stress/systemgc/TestSystemGCWithShenandoah.java Changeset: ee839b7f Branch: fibers Author: Kim Barrett Date: 2024-07-26 03:44:22 +0000 URL: https://git.openjdk.org/loom/commit/ee839b7f0ebe471d3877cddd2c87019ccb8ee5ae 8337239: Fix simple -Wzero-as-null-pointer-constant warnings in classfile code Reviewed-by: dholmes ! src/hotspot/share/classfile/classFileParser.cpp ! src/hotspot/share/classfile/defaultMethods.cpp ! src/hotspot/share/classfile/javaAssertions.cpp ! src/hotspot/share/classfile/symbolTable.cpp Changeset: 29f0f174 Branch: fibers Author: Abhishek Kumar Date: 2024-07-26 06:23:47 +0000 URL: https://git.openjdk.org/loom/commit/29f0f174a0460a98c5500c4cf4bf9abdf9354572 8336879: Always true condition 'img != null' in GTKPainter.paintPopupMenuBackground Reviewed-by: psadhukhan, tr ! src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKPainter.java Changeset: 487450cb Branch: fibers Author: Abhishek Kumar Date: 2024-07-26 06:26:52 +0000 URL: https://git.openjdk.org/loom/commit/487450cb5e8b3781f77896125573ee89a556b454 8216471: GTK LnF: Frame is clipped and does not show JTable,Tooltip and JTree demo in SwingSet2 demo Reviewed-by: psadhukhan, achung ! src/demo/share/jfc/SwingSet2/SwingSet2.java Changeset: 7f119354 Branch: fibers Author: Shaojin Wen Committer: Chen Liang Date: 2024-07-26 07:08:33 +0000 URL: https://git.openjdk.org/loom/commit/7f11935461a6ff1ef0fac800fb4264a519e21061 8337167: StringSize deduplication Reviewed-by: liach, rriggs ! src/java.base/share/classes/java/lang/AbstractStringBuilder.java ! src/java.base/share/classes/java/lang/Integer.java ! src/java.base/share/classes/java/lang/Long.java ! src/java.base/share/classes/java/lang/StringConcatHelper.java ! src/java.base/share/classes/java/lang/System.java ! src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java ! src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java ! src/java.base/share/classes/jdk/internal/util/DecimalDigits.java Changeset: d10afa26 Branch: fibers Author: Fei Gao Date: 2024-07-26 09:36:23 +0000 URL: https://git.openjdk.org/loom/commit/d10afa26e5c59475e49b353ed34e8e85d0615d92 8336245: AArch64: remove extra register copy when converting from long to pointer Co-authored-by: Andrew Haley Reviewed-by: aph, adinn ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/aarch64/gc/x/x_aarch64.ad ! src/hotspot/cpu/aarch64/gc/z/z_aarch64.ad ! src/hotspot/share/opto/machnode.cpp + test/hotspot/jtreg/compiler/c2/TestCastX2P.java Changeset: 2aeb12ec Branch: fibers Author: Aleksey Shipilev Date: 2024-07-26 11:20:40 +0000 URL: https://git.openjdk.org/loom/commit/2aeb12ec03944c777d617d0be48982fd225b16e7 8334482: Shenandoah: Deadlock when safepoint is pending during nmethods iteration Reviewed-by: wkemper, xpeng, rkennke ! src/hotspot/share/gc/shenandoah/shenandoahCodeRoots.cpp ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp ! src/hotspot/share/gc/shenandoah/shenandoahNMethod.cpp ! src/hotspot/share/gc/shenandoah/shenandoahNMethod.hpp Changeset: 374fca0f Branch: fibers Author: Alexey Ivanov Date: 2024-07-26 11:22:32 +0000 URL: https://git.openjdk.org/loom/commit/374fca0fcbc049f937fa49bb4825edcbbf961f2b 8335967: "text-decoration: none" does not work with "A" HTML tags Reviewed-by: abhiscxk, dmarkov, honkar, prr ! src/java.desktop/share/classes/javax/swing/text/html/CSS.java + test/jdk/javax/swing/text/html/HTMLDocument/HTMLTextDecorationNone.java Changeset: 5ff7c57f Branch: fibers Author: Shaojin Wen Date: 2024-07-26 12:10:21 +0000 URL: https://git.openjdk.org/loom/commit/5ff7c57f9ff5428ef3d2aedd7e860bb1e8ff29ea 8337168: Optimize LocalDateTime.toString Reviewed-by: liach, naoto ! src/java.base/share/classes/java/time/LocalDate.java ! src/java.base/share/classes/java/time/LocalDateTime.java ! src/java.base/share/classes/java/time/LocalTime.java Changeset: 3abe8a6e Branch: fibers Author: Tomas Zezula Date: 2024-07-26 14:42:24 +0000 URL: https://git.openjdk.org/loom/commit/3abe8a6e5e459fb764b8cef2425be50fe1a83fab 8336663: [JVMCI] VM Crash on ZGC due to incompatible handle returned by HotSpotJVMCIRuntime#getJObjectValue Reviewed-by: dnsimon, never ! src/hotspot/share/jvmci/jvmciCompilerToVM.cpp ! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/CompilerToVM.java ! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotJVMCIRuntime.java Changeset: 4bcb8f04 Branch: fibers Author: Kim Barrett Date: 2024-07-26 15:45:12 +0000 URL: https://git.openjdk.org/loom/commit/4bcb8f04ed3623da7c84dda28017f473cbc97e53 8337243: Fix more -Wzero-as-null-pointer-constant warnings in compiler code Reviewed-by: vlivanov, kvn ! src/hotspot/share/c1/c1_LIRGenerator.cpp ! src/hotspot/share/ci/ciConstantPoolCache.cpp ! src/hotspot/share/ci/ciStreams.cpp ! src/hotspot/share/code/codeCache.cpp ! src/hotspot/share/code/dependencies.cpp ! src/hotspot/share/code/nmethod.cpp ! src/hotspot/share/code/oopRecorder.cpp Changeset: f35af717 Branch: fibers Author: Kelvin Nilsen Committer: Aleksey Shipilev Date: 2024-07-26 15:55:12 +0000 URL: https://git.openjdk.org/loom/commit/f35af7171213c09107b99104a73022853bff91b0 8334315: Shenandoah: reduce GC logging noise Reviewed-by: wkemper, ysr, shade ! src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp Changeset: 4f194f10 Branch: fibers Author: William Kemper Date: 2024-07-26 15:57:58 +0000 URL: https://git.openjdk.org/loom/commit/4f194f10a1481cdc9df4e6338f6cabd07a34c84c 8337241: Shenandoah: Normalize include guards Reviewed-by: shade ! src/hotspot/share/gc/shenandoah/shenandoahController.hpp ! src/hotspot/share/gc/shenandoah/shenandoahMarkBitMap.hpp ! src/hotspot/share/gc/shenandoah/shenandoahMarkBitMap.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahReferenceProcessor.hpp Changeset: 0c3720b4 Branch: fibers Author: Abhishek Kumar Date: 2024-07-26 17:39:00 +0000 URL: https://git.openjdk.org/loom/commit/0c3720b42176c7bc92105be87df7449973fbcea0 8335131: Test "javax/swing/JColorChooser/Test6977726.java" failed on ubuntu x64 because "Preview" title is missing for GTK L&F Reviewed-by: dnguyen, psadhukhan ! test/jdk/javax/swing/JColorChooser/Test6977726.java Changeset: abc4ca5a Branch: fibers Author: Alex Menkov Date: 2024-07-26 17:55:35 +0000 URL: https://git.openjdk.org/loom/commit/abc4ca5a8c440f8f3f36a9b35036772c5b5ee7ea 8330427: Obsolete -XX:+PreserveAllAnnotations Reviewed-by: dholmes, sspitsyn, coleenp ! src/hotspot/share/classfile/classFileParser.cpp ! src/hotspot/share/classfile/classFileParser.hpp ! src/hotspot/share/prims/jvmtiClassFileReconstituter.cpp ! src/hotspot/share/prims/jvmtiClassFileReconstituter.hpp ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/globals.hpp - test/jdk/java/lang/instrument/RetransformRecordAnnotation.java Changeset: 034297a6 Branch: fibers Author: Fernando Guallini Committer: Bradford Wetmore Date: 2024-07-26 18:51:12 +0000 URL: https://git.openjdk.org/loom/commit/034297a6bd9bfcea7fa48792f54c84a6e976b319 8336240: Test com/sun/crypto/provider/Cipher/DES/PerformanceTest.java fails with java.lang.ArithmeticException Reviewed-by: wetmore ! test/jdk/ProblemList.txt ! test/jdk/TEST.groups ! test/jdk/com/sun/crypto/provider/Cipher/DES/PerformanceTest.java Changeset: 9651299f Branch: fibers Author: Alan Bateman Date: 2024-07-27 05:52:37 +0000 URL: https://git.openjdk.org/loom/commit/9651299f32bddc2c2701850dd2c8726b9dfbc016 Merge ! src/hotspot/share/code/nmethod.cpp ! src/hotspot/share/runtime/globals.hpp ! src/java.base/share/classes/java/lang/System.java ! src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java ! src/hotspot/share/code/nmethod.cpp ! src/hotspot/share/runtime/globals.hpp ! src/java.base/share/classes/java/lang/System.java ! src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java Changeset: c55de0c1 Branch: fibers Author: Alan Bateman Date: 2024-07-27 05:53:37 +0000 URL: https://git.openjdk.org/loom/commit/c55de0c12d92e73dc8f253fed86deb618955a169 Test cleanup ! test/jdk/java/lang/Thread/virtual/MonitorEnterExit.java ! test/jdk/java/lang/Thread/virtual/Parking.java ! test/jdk/java/lang/Thread/virtual/ThreadAPI.java Changeset: ba909920 Branch: fibers Author: Alan Bateman Date: 2024-07-27 05:57:08 +0000 URL: https://git.openjdk.org/loom/commit/ba90992061a1a4d1945e4d22259b04f1bacb5584 Exclude tests that fail with -Xcomp ! test/jdk/ProblemList-Xcomp.txt From duke at openjdk.org Sat Jul 27 07:08:25 2024 From: duke at openjdk.org (duke) Date: Sat, 27 Jul 2024 07:08:25 GMT Subject: git: openjdk/loom: master: 27 new changesets Message-ID: <3ae4303c-4c60-4f16-b80a-5c7760bcd9ff@openjdk.org> Changeset: 9d879186 Branch: master Author: Hamlin Li Date: 2024-07-25 07:47:45 +0000 URL: https://git.openjdk.org/loom/commit/9d8791864ec48f3321707d7f7805cd3618fc3b51 8335191: RISC-V: verify perf of chacha20 Reviewed-by: fyang ! src/hotspot/cpu/riscv/vm_version_riscv.cpp Changeset: 8081f870 Branch: master Author: Shaojin Wen Committer: Tobias Hartmann Date: 2024-07-25 09:16:32 +0000 URL: https://git.openjdk.org/loom/commit/8081f8702a89c4895302377be62da22fc34f2c74 8334342: Add MergeStore JMH benchmarks Reviewed-by: epeter, thartmann + test/micro/org/openjdk/bench/vm/compiler/MergeStoreBench.java Changeset: 3baff2af Branch: master Author: Roland Westrelin Date: 2024-07-25 09:26:11 +0000 URL: https://git.openjdk.org/loom/commit/3baff2af6a30cc6cb2e0d4391db1cf7e61c33f64 8335393: C2: assert(!had_error) failed: bad dominance Reviewed-by: thartmann, chagedorn ! src/hotspot/share/opto/loopTransform.cpp + test/hotspot/jtreg/compiler/rangechecks/TestEmptyLoopDeadCast.java Changeset: 00b53481 Branch: master Author: Albert Mingkun Yang Date: 2024-07-25 13:16:31 +0000 URL: https://git.openjdk.org/loom/commit/00b53481064ed1ca914008d06ce5b530ca7ffe16 8337192: [BACKOUT] JDK-8336098 G1: Refactor G1RebuildRSAndScrubTask Reviewed-by: tschatzl ! src/hotspot/share/gc/g1/g1ConcurrentRebuildAndScrub.cpp Changeset: 34ee06f5 Branch: master Author: Vicente Romero Date: 2024-07-25 13:41:32 +0000 URL: https://git.openjdk.org/loom/commit/34ee06f51122e8afb875cc3b75f513912272fd9b 8332850: javac crashes if container for repeatable annotation is not found Reviewed-by: darcy ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Annotate.java + test/langtools/tools/javac/annotations/repeatingAnnotations/CompletionErrorOnRepeatingAnnosTest.java Changeset: f61a5059 Branch: master Author: Roland Westrelin Date: 2024-07-25 15:45:41 +0000 URL: https://git.openjdk.org/loom/commit/f61a50598958e928e9a4d81130b077cd6eaf876a 8334647: C2: CastII added by PhaseIdealLoop::add_template_assertion_predicate() should have control Reviewed-by: chagedorn, kvn ! src/hotspot/share/opto/castnode.hpp ! src/hotspot/share/opto/loopPredicate.cpp ! src/hotspot/share/opto/loopTransform.cpp ! src/hotspot/share/opto/loopopts.cpp ! src/hotspot/share/opto/vectorIntrinsics.cpp Changeset: e74edbae Branch: master Author: Xiaolong Peng Committer: Aleksey Shipilev Date: 2024-07-25 16:04:58 +0000 URL: https://git.openjdk.org/loom/commit/e74edbaea9f09169f597a470f647f3b7d10cc71b 8336640: Shenandoah: Parallel worker use in parallel_heap_region_iterate Reviewed-by: shade, wkemper, ysr ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp Changeset: 81ed0287 Branch: master Author: Jorn Vernee Date: 2024-07-25 16:36:31 +0000 URL: https://git.openjdk.org/loom/commit/81ed0287175617e6f7ad79dd7036b2fbde27e80a 8337060: Test java/foreign/TestConcurrentClose.java failed: IllegalStateException: SegmentAccessor::doAccess method not being compiled Reviewed-by: mcimadamore, alanb ! test/jdk/java/foreign/TestConcurrentClose.java Changeset: cf0d9e0e Branch: master Author: Vicente Romero Date: 2024-07-25 17:03:45 +0000 URL: https://git.openjdk.org/loom/commit/cf0d9e0e521b495a96a3de7775b1b3ae14d20d80 8337037: compiler internal options are not printing the stacktrace after a compiler crash Reviewed-by: mcimadamore ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/PoolWriter.java + src/jdk.compiler/share/classes/com/sun/tools/javac/util/CompilerInternalException.java ! src/jdk.jshell/share/classes/jdk/jshell/TreeDissector.java Changeset: b5b5a5b8 Branch: master Author: Weijun Wang Date: 2024-07-25 17:11:59 +0000 URL: https://git.openjdk.org/loom/commit/b5b5a5b8e54ebd766456d2a4781a806ff97816a8 8336667: IAE in DerInputStream.toByteArray Reviewed-by: valeriep ! src/java.base/share/classes/sun/security/util/DerInputStream.java + test/jdk/sun/security/util/DerInputBuffer/B8336667/PoC.java + test/jdk/sun/security/util/DerInputBuffer/B8336667/Reproducer.java Changeset: 8c28f25e Branch: master Author: Brian Burkhalter Date: 2024-07-25 20:59:48 +0000 URL: https://git.openjdk.org/loom/commit/8c28f25e1383f10a78b05e47ccf1cc4262069e69 8337124: (fs) sun.nio.fs.WindowsSecurity.enablePrivilege should pin when continuations supported Reviewed-by: jpai, alanb ! src/java.base/windows/classes/sun/nio/fs/WindowsSecurity.java Changeset: 0584af23 Branch: master Author: William Kemper Date: 2024-07-25 23:59:56 +0000 URL: https://git.openjdk.org/loom/commit/0584af23255b6b8f49190eaf2618f3bcc299adfe 8336685: Shenandoah: Remove experimental incremental update mode Reviewed-by: shade ! src/hotspot/cpu/aarch64/gc/shenandoah/c1/shenandoahBarrierSetC1_aarch64.cpp ! src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.hpp ! src/hotspot/cpu/ppc/gc/shenandoah/c1/shenandoahBarrierSetC1_ppc.cpp ! src/hotspot/cpu/ppc/gc/shenandoah/shenandoahBarrierSetAssembler_ppc.cpp ! src/hotspot/cpu/ppc/gc/shenandoah/shenandoahBarrierSetAssembler_ppc.hpp ! src/hotspot/cpu/riscv/gc/shenandoah/c1/shenandoahBarrierSetC1_riscv.cpp ! src/hotspot/cpu/riscv/gc/shenandoah/shenandoahBarrierSetAssembler_riscv.cpp ! src/hotspot/cpu/riscv/gc/shenandoah/shenandoahBarrierSetAssembler_riscv.hpp ! src/hotspot/cpu/x86/gc/shenandoah/c1/shenandoahBarrierSetC1_x86.cpp ! src/hotspot/cpu/x86/gc/shenandoah/shenandoahBarrierSetAssembler_x86.cpp ! src/hotspot/cpu/x86/gc/shenandoah/shenandoahBarrierSetAssembler_x86.hpp ! src/hotspot/share/gc/shenandoah/c1/shenandoahBarrierSetC1.cpp ! src/hotspot/share/gc/shenandoah/c1/shenandoahBarrierSetC1.hpp ! src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.cpp ! src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.hpp ! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp ! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.hpp - src/hotspot/share/gc/shenandoah/mode/shenandoahIUMode.cpp - src/hotspot/share/gc/shenandoah/mode/shenandoahIUMode.hpp ! src/hotspot/share/gc/shenandoah/mode/shenandoahPassiveMode.cpp ! src/hotspot/share/gc/shenandoah/mode/shenandoahSATBMode.cpp ! src/hotspot/share/gc/shenandoah/shenandoahArguments.cpp ! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.cpp ! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.hpp ! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahBarrierSetClone.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp ! src/hotspot/share/opto/classes.hpp ! test/hotspot/jtreg/compiler/c2/aarch64/TestVolatiles.java ! test/hotspot/jtreg/compiler/c2/aarch64/TestVolatilesShenandoah.java ! test/hotspot/jtreg/gc/TestAllocHumongousFragment.java ! test/hotspot/jtreg/gc/shenandoah/TestAllocIntArrays.java ! test/hotspot/jtreg/gc/shenandoah/TestAllocObjectArrays.java ! test/hotspot/jtreg/gc/shenandoah/TestAllocObjects.java ! test/hotspot/jtreg/gc/shenandoah/TestDynamicSoftMaxHeapSize.java ! test/hotspot/jtreg/gc/shenandoah/TestGCThreadGroups.java ! test/hotspot/jtreg/gc/shenandoah/TestHeapUncommit.java ! test/hotspot/jtreg/gc/shenandoah/TestJcmdHeapDump.java ! test/hotspot/jtreg/gc/shenandoah/TestLotsOfCycles.java ! test/hotspot/jtreg/gc/shenandoah/TestObjItrWithHeapDump.java ! test/hotspot/jtreg/gc/shenandoah/TestPeriodicGC.java ! test/hotspot/jtreg/gc/shenandoah/TestReferenceRefersToShenandoah.java ! test/hotspot/jtreg/gc/shenandoah/TestReferenceShortcutCycle.java ! test/hotspot/jtreg/gc/shenandoah/TestRefprocSanity.java ! test/hotspot/jtreg/gc/shenandoah/TestRegionSampling.java ! test/hotspot/jtreg/gc/shenandoah/TestResizeTLAB.java ! test/hotspot/jtreg/gc/shenandoah/TestRetainObjects.java ! test/hotspot/jtreg/gc/shenandoah/TestSieveObjects.java ! test/hotspot/jtreg/gc/shenandoah/TestStringDedup.java ! test/hotspot/jtreg/gc/shenandoah/TestStringDedupStress.java ! test/hotspot/jtreg/gc/shenandoah/TestStringInternCleanup.java ! test/hotspot/jtreg/gc/shenandoah/TestVerifyJCStress.java ! test/hotspot/jtreg/gc/shenandoah/TestWrongArrayMember.java ! test/hotspot/jtreg/gc/shenandoah/compiler/BarrierInInfiniteLoop.java - test/hotspot/jtreg/gc/shenandoah/compiler/TestUnexpectedIUBarrierEA.java ! test/hotspot/jtreg/gc/shenandoah/mxbeans/TestChurnNotifications.java ! test/hotspot/jtreg/gc/shenandoah/mxbeans/TestPauseNotifications.java ! test/hotspot/jtreg/gc/shenandoah/oom/TestClassLoaderLeak.java ! test/hotspot/jtreg/gc/shenandoah/options/TestExplicitGC.java ! test/hotspot/jtreg/gc/shenandoah/options/TestModeUnlock.java ! test/hotspot/jtreg/gc/shenandoah/options/TestSelectiveBarrierFlags.java ! test/hotspot/jtreg/gc/shenandoah/options/TestWrongBarrierDisable.java ! test/hotspot/jtreg/gc/shenandoah/options/TestWrongBarrierEnable.java ! test/hotspot/jtreg/gc/stress/gcbasher/TestGCBasherWithShenandoah.java ! test/hotspot/jtreg/gc/stress/gcold/TestGCOldWithShenandoah.java ! test/hotspot/jtreg/gc/stress/systemgc/TestSystemGCWithShenandoah.java Changeset: ee839b7f Branch: master Author: Kim Barrett Date: 2024-07-26 03:44:22 +0000 URL: https://git.openjdk.org/loom/commit/ee839b7f0ebe471d3877cddd2c87019ccb8ee5ae 8337239: Fix simple -Wzero-as-null-pointer-constant warnings in classfile code Reviewed-by: dholmes ! src/hotspot/share/classfile/classFileParser.cpp ! src/hotspot/share/classfile/defaultMethods.cpp ! src/hotspot/share/classfile/javaAssertions.cpp ! src/hotspot/share/classfile/symbolTable.cpp Changeset: 29f0f174 Branch: master Author: Abhishek Kumar Date: 2024-07-26 06:23:47 +0000 URL: https://git.openjdk.org/loom/commit/29f0f174a0460a98c5500c4cf4bf9abdf9354572 8336879: Always true condition 'img != null' in GTKPainter.paintPopupMenuBackground Reviewed-by: psadhukhan, tr ! src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKPainter.java Changeset: 487450cb Branch: master Author: Abhishek Kumar Date: 2024-07-26 06:26:52 +0000 URL: https://git.openjdk.org/loom/commit/487450cb5e8b3781f77896125573ee89a556b454 8216471: GTK LnF: Frame is clipped and does not show JTable,Tooltip and JTree demo in SwingSet2 demo Reviewed-by: psadhukhan, achung ! src/demo/share/jfc/SwingSet2/SwingSet2.java Changeset: 7f119354 Branch: master Author: Shaojin Wen Committer: Chen Liang Date: 2024-07-26 07:08:33 +0000 URL: https://git.openjdk.org/loom/commit/7f11935461a6ff1ef0fac800fb4264a519e21061 8337167: StringSize deduplication Reviewed-by: liach, rriggs ! src/java.base/share/classes/java/lang/AbstractStringBuilder.java ! src/java.base/share/classes/java/lang/Integer.java ! src/java.base/share/classes/java/lang/Long.java ! src/java.base/share/classes/java/lang/StringConcatHelper.java ! src/java.base/share/classes/java/lang/System.java ! src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java ! src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java ! src/java.base/share/classes/jdk/internal/util/DecimalDigits.java Changeset: d10afa26 Branch: master Author: Fei Gao Date: 2024-07-26 09:36:23 +0000 URL: https://git.openjdk.org/loom/commit/d10afa26e5c59475e49b353ed34e8e85d0615d92 8336245: AArch64: remove extra register copy when converting from long to pointer Co-authored-by: Andrew Haley Reviewed-by: aph, adinn ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/aarch64/gc/x/x_aarch64.ad ! src/hotspot/cpu/aarch64/gc/z/z_aarch64.ad ! src/hotspot/share/opto/machnode.cpp + test/hotspot/jtreg/compiler/c2/TestCastX2P.java Changeset: 2aeb12ec Branch: master Author: Aleksey Shipilev Date: 2024-07-26 11:20:40 +0000 URL: https://git.openjdk.org/loom/commit/2aeb12ec03944c777d617d0be48982fd225b16e7 8334482: Shenandoah: Deadlock when safepoint is pending during nmethods iteration Reviewed-by: wkemper, xpeng, rkennke ! src/hotspot/share/gc/shenandoah/shenandoahCodeRoots.cpp ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp ! src/hotspot/share/gc/shenandoah/shenandoahNMethod.cpp ! src/hotspot/share/gc/shenandoah/shenandoahNMethod.hpp Changeset: 374fca0f Branch: master Author: Alexey Ivanov Date: 2024-07-26 11:22:32 +0000 URL: https://git.openjdk.org/loom/commit/374fca0fcbc049f937fa49bb4825edcbbf961f2b 8335967: "text-decoration: none" does not work with "A" HTML tags Reviewed-by: abhiscxk, dmarkov, honkar, prr ! src/java.desktop/share/classes/javax/swing/text/html/CSS.java + test/jdk/javax/swing/text/html/HTMLDocument/HTMLTextDecorationNone.java Changeset: 5ff7c57f Branch: master Author: Shaojin Wen Date: 2024-07-26 12:10:21 +0000 URL: https://git.openjdk.org/loom/commit/5ff7c57f9ff5428ef3d2aedd7e860bb1e8ff29ea 8337168: Optimize LocalDateTime.toString Reviewed-by: liach, naoto ! src/java.base/share/classes/java/time/LocalDate.java ! src/java.base/share/classes/java/time/LocalDateTime.java ! src/java.base/share/classes/java/time/LocalTime.java Changeset: 3abe8a6e Branch: master Author: Tomas Zezula Date: 2024-07-26 14:42:24 +0000 URL: https://git.openjdk.org/loom/commit/3abe8a6e5e459fb764b8cef2425be50fe1a83fab 8336663: [JVMCI] VM Crash on ZGC due to incompatible handle returned by HotSpotJVMCIRuntime#getJObjectValue Reviewed-by: dnsimon, never ! src/hotspot/share/jvmci/jvmciCompilerToVM.cpp ! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/CompilerToVM.java ! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotJVMCIRuntime.java Changeset: 4bcb8f04 Branch: master Author: Kim Barrett Date: 2024-07-26 15:45:12 +0000 URL: https://git.openjdk.org/loom/commit/4bcb8f04ed3623da7c84dda28017f473cbc97e53 8337243: Fix more -Wzero-as-null-pointer-constant warnings in compiler code Reviewed-by: vlivanov, kvn ! src/hotspot/share/c1/c1_LIRGenerator.cpp ! src/hotspot/share/ci/ciConstantPoolCache.cpp ! src/hotspot/share/ci/ciStreams.cpp ! src/hotspot/share/code/codeCache.cpp ! src/hotspot/share/code/dependencies.cpp ! src/hotspot/share/code/nmethod.cpp ! src/hotspot/share/code/oopRecorder.cpp Changeset: f35af717 Branch: master Author: Kelvin Nilsen Committer: Aleksey Shipilev Date: 2024-07-26 15:55:12 +0000 URL: https://git.openjdk.org/loom/commit/f35af7171213c09107b99104a73022853bff91b0 8334315: Shenandoah: reduce GC logging noise Reviewed-by: wkemper, ysr, shade ! src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp Changeset: 4f194f10 Branch: master Author: William Kemper Date: 2024-07-26 15:57:58 +0000 URL: https://git.openjdk.org/loom/commit/4f194f10a1481cdc9df4e6338f6cabd07a34c84c 8337241: Shenandoah: Normalize include guards Reviewed-by: shade ! src/hotspot/share/gc/shenandoah/shenandoahController.hpp ! src/hotspot/share/gc/shenandoah/shenandoahMarkBitMap.hpp ! src/hotspot/share/gc/shenandoah/shenandoahMarkBitMap.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahReferenceProcessor.hpp Changeset: 0c3720b4 Branch: master Author: Abhishek Kumar Date: 2024-07-26 17:39:00 +0000 URL: https://git.openjdk.org/loom/commit/0c3720b42176c7bc92105be87df7449973fbcea0 8335131: Test "javax/swing/JColorChooser/Test6977726.java" failed on ubuntu x64 because "Preview" title is missing for GTK L&F Reviewed-by: dnguyen, psadhukhan ! test/jdk/javax/swing/JColorChooser/Test6977726.java Changeset: abc4ca5a Branch: master Author: Alex Menkov Date: 2024-07-26 17:55:35 +0000 URL: https://git.openjdk.org/loom/commit/abc4ca5a8c440f8f3f36a9b35036772c5b5ee7ea 8330427: Obsolete -XX:+PreserveAllAnnotations Reviewed-by: dholmes, sspitsyn, coleenp ! src/hotspot/share/classfile/classFileParser.cpp ! src/hotspot/share/classfile/classFileParser.hpp ! src/hotspot/share/prims/jvmtiClassFileReconstituter.cpp ! src/hotspot/share/prims/jvmtiClassFileReconstituter.hpp ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/globals.hpp - test/jdk/java/lang/instrument/RetransformRecordAnnotation.java Changeset: 034297a6 Branch: master Author: Fernando Guallini Committer: Bradford Wetmore Date: 2024-07-26 18:51:12 +0000 URL: https://git.openjdk.org/loom/commit/034297a6bd9bfcea7fa48792f54c84a6e976b319 8336240: Test com/sun/crypto/provider/Cipher/DES/PerformanceTest.java fails with java.lang.ArithmeticException Reviewed-by: wetmore ! test/jdk/ProblemList.txt ! test/jdk/TEST.groups ! test/jdk/com/sun/crypto/provider/Cipher/DES/PerformanceTest.java From yuval.l at securithings.com Sun Jul 28 11:41:23 2024 From: yuval.l at securithings.com (Yuval Lombard) Date: Sun, 28 Jul 2024 14:41:23 +0300 Subject: Experiencing an issue with ScheduledExecutorService alongside VT In-Reply-To: References: <3cdd7056-6321-4653-be4d-71bf5bea55e5@oracle.com> <213a86b9-2c9a-494f-9077-695008a48870@oracle.com> <6d928b93-8698-4546-9571-c7e00651ab3c@oracle.com> <28d98b3a-85b5-4e40-a935-a3a6e93e745d@oracle.com> Message-ID: Hi Team, For the sake of accuracy and integrity, I have noticed the previous thread dump was taken from a piece of code that does not match the provided example I attached in the first couple of mails I have sent. I have attached a new thread dump file that was taken from the exact version of the code I was testing. Will appreciate it if you could take a look again just to make sure you see the issue ( related to preemption when cancelling a timer after Object.wait(millis) ) you found in the previous dump I attached. Apologies On Mon, 22 Jul 2024 at 14:45, Yuval Lombard wrote: > Thanks Alan > > I will take a look into those builds > > On Mon, 22 Jul 2024 at 12:52, Alan Bateman > wrote: > >> >> >> On 22/07/2024 10:11, Yuval Lombard wrote: >> > Hi Alan, >> > >> > Thanks, sorry for the confusion, we also saw this odd release, and got >> > read of it, it was just a side note btw, because I realized I did not >> > attach how I have created my scheduler, so I elaborated on this as well. >> > >> > Just to make sure by SPTE what exactly do you mean? >> I mean ScheduledThreadPoolExecutor (STPE), likely code calling >> Executors.newScheduledThreadPool with a ThreadFactory that creates >> virtual threads. >> >> > >> > We are running into some difficulties now after upgrading to the >> > latest EA based on jdk24 where most of our utilized framework's libs >> > are not supporting it yet (Spring, and Spring-Boot) >> > So if there is an older available EA build based on jdk23 that may be >> > addressing one of the possible issues that may got us into this >> > locking state, we will be happy to test it. >> > Otherwise it will require some work from our end in order to try to >> > package our app >> >> JDK main line, and the loom repo, moved to targeting JDK 24 in June and >> not really feasible to go back. There are Spring engineers testing EA >> builds from Project Leyden and those builds are also based on main line >> so there may be Spring builds that support JDK 24 EA builds. I realize >> it means testing a combination of EA bits. >> >> -Alan >> > > > -- > > Kind regards, > > *Yuval Lombard* > > *Lead Software Engineer* > > +972.50.548.0111 > > yuval.l at securithings.com > > [image: logo_black.png] > -- Kind regards, *Yuval Lombard* *Lead Software Engineer* +972.50.548.0111 yuval.l at securithings.com [image: logo_black.png] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo_black.png Type: image/png Size: 99833 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: thread_dump Type: application/octet-stream Size: 369440 bytes Desc: not available URL: From Alan.Bateman at oracle.com Sun Jul 28 12:48:47 2024 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 28 Jul 2024 13:48:47 +0100 Subject: Experiencing an issue with ScheduledExecutorService alongside VT In-Reply-To: References: <3cdd7056-6321-4653-be4d-71bf5bea55e5@oracle.com> <213a86b9-2c9a-494f-9077-695008a48870@oracle.com> <6d928b93-8698-4546-9571-c7e00651ab3c@oracle.com> <28d98b3a-85b5-4e40-a935-a3a6e93e745d@oracle.com> Message-ID: <6baa943c-ddc7-4b30-825b-88e5aeabb33c@oracle.com> On 28/07/2024 12:41, Yuval Lombard wrote: > Hi Team, > > For the sake of accuracy and integrity, I have noticed the > previous?thread dump was taken from a piece of code that does not > match the provided example I attached in the first couple of mails I > have sent. > I have attached a new thread dump file that was taken from the exact > version of the code I was testing. > > Will appreciate it if you could take a look again just to make sure > you see the issue ( related to preemption when cancelling a timer > after Object.wait(millis) ) you found in the previous dump I attached. Looks to me the same thing. In this dump, #302878 and #302879 are scheduling a timeout as part of a timed-Socket.connect. ForkJoinPool-1-worker-2 and ForkJoinPool-1-worker-3 are blocked trying to schedule a timeout. The interesting one is #302780 as it seems to have been preempted while blocking as it removes a cancelled timeout. This issue is fixed but the EA download is a bit behind and we need to get it refreshed. Also I think you said something about the version of Spring needing to updated to work with an EA build (as the EA builds are tracking main line for JDK 24). -Alan From sergei.tsypanov at yandex.ru Sun Jul 28 12:59:48 2024 From: sergei.tsypanov at yandex.ru (=?utf-8?B?0KHQtdGA0LPQtdC5INCm0YvQv9Cw0L3QvtCy?=) Date: Sun, 28 Jul 2024 14:59:48 +0200 Subject: Concurrency issue with virtual threads Message-ID: <57721722171588@7jeuw3ncvslfpppo.sas.yp-c.yandex.net> Hello, I've run into a concurrency issue manifested in application becoming frozen due to pinned virtual threads. Here I've described the reproduction steps in details: https://stackoverflow.com/questions/78790376/spring-boot-application-gets-stuck-when-virtual-threads-are-used-on-java-21 The problem is manifested when you run the Spring Boot application having virtual threads enabled. Under the hood my demo application has a feign client using connection pool with up to 20 connections (threshold cannot be increased due to a configuration bug), and as soon as you try to make more than 20 simultaneous request (even 21), the pool gets exhausted, meaning that upcoming requests have to wait for a connection released, and the application gets stuck (though it doesn't when platform threads are used i.e. when configuration property spring.threads.virtual.enabled is false). Running the code with -Djdk.tracePinnedThreads=full I've identified the cause more precisely: it is located within AbstractConnPool.getPoolEntryBlocking(). Here's the link to the pinned threads stack trace: https://github.com/stsypanov/concurrency-demo/blob/master/pinned-threads.txt In the file pay attention to these lines: 12 org.apache.http.pool.AbstractConnPool.getPoolEntryBlocking(AbstractConnPool.java:319) 92 org.apache.http.pool.AbstractConnPool.getPoolEntryBlocking(AbstractConnPool.java:391) Now let's examine the source code of o.a.h.p.AbstractConnPool.getPoolEntryBlocking over here: https://github.com/apache/httpcomponents-core/blob/4.4.x/httpcore/src/main/java/org/apache/http/pool/AbstractConnPool.java In this class we have a ReentrantLock (encouraged to be used with virtual threads instead of synchronized blocks) and its Condition: private final Lock lock; private final Condition condition; public AbstractConnPool() { this.lock = new ReentrantLock(); this.condition = this.lock.newCondition(); } Later in method AbstractConnPool.getPoolEntryBlocking() we have this logic: private E getPoolEntryBlocking() { this.lock.lock(); // line 319 try { for (;;) { try { if (deadline != null) { success = this.condition.awaitUntil(deadline); } else { this.condition.await(); // line 391 success = true; } } } } finally { this.lock.unlock(); } } This code works with platform threads but gets stuck with virtual ones. If one gets thread dump of the stuck application there'll be 20 workers in ForkJoinPool and each will have the same stack trace (with different ids, of course): "ForkJoinPool-1-worker-1" prio=0 tid=0x0 nid=0x0 waiting on condition java.lang.Thread.State: WAITING on java.lang.VirtualThread at 121c8328 owned by "tomcat-handler-123" Id=214 at java.base at 22.0.2/jdk.internal.vm.Continuation.run(Continuation.java:248) at java.base at 22.0.2/java.lang.VirtualThread.runContinuation(VirtualThread.java:245) at java.base at 22.0.2/java.lang.VirtualThread$$Lambda/0x000001579b475d08.run(Unknown Source) at java.base at 22.0.2/java.util.concurrent.ForkJoinTask$RunnableExecuteAction.compute(ForkJoinTask.java:1726) at java.base at 22.0.2/java.util.concurrent.ForkJoinTask$RunnableExecuteAction.compute(ForkJoinTask.java:1717) at java.base at 22.0.2/java.util.concurrent.ForkJoinTask$InterruptibleTask.exec(ForkJoinTask.java:1641) at java.base at 22.0.2/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:507) at java.base at 22.0.2/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1489) at java.base at 22.0.2/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:2071) at java.base at 22.0.2/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:2033) at java.base at 22.0.2/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:187) As you see from the code above, the issue is still there on Java 22, also it's reproducible with other distributions of JDK (e.g. Liberica JDK). I think this is a bug somewhere in the JVM, as the ending point of the stacktrace is native Continuation.enterSpecial(), otherwise the behavior would be the same regardless of platform or virtual threads. Regards, Sergey Tsypanov From stnordstrom at gmail.com Sun Jul 28 13:10:34 2024 From: stnordstrom at gmail.com (Sten Nordstrom) Date: Sun, 28 Jul 2024 16:10:34 +0300 Subject: Question about StructuredTaskScope.joinUntil(Instant) In-Reply-To: References: <439D398A-5972-49CE-8C06-1E6E05D92E60@fibermail.ch> Message-ID: This was surprising to me as well, as this can lead to some surprising results in environments with unreliable time synchronization. Are there any pointers re discussion why this approach was chosen instead of the more common way of specifying a maximum duration to wait? Glad to hear that you found a solution, we will need to do something similar when we start using StructuredTaskScopes. Best Regards, Sten On Tue, Jun 11, 2024 at 18.33 Werner Randelshofer < werner.randelshofer at fibermail.ch> wrote: > I have solved my problem. :-) > > I have now implemented a subclass of StructuredTaskScope, which allows to > specify a deadline in System.nanoTime() units. > With this design, the deadline is independent from external resources > (like NTP time servers) over which the Java process has no control. > > See code below. > > With best regards, > Werner > > > > package org.example.structuredconcurrency; > > import java.time.Duration; > import java.util.concurrent.StructuredTaskScope; > import java.util.concurrent.ThreadFactory; > import java.util.concurrent.TimeoutException; > > /** > * A {@link StructuredTaskScope} that supports a deadline given in {@link > System#nanoTime()}. > * > * @param the type of the structured task scope > */ > public class StructuredTaskScopeNanoTime extends StructuredTaskScope > { > > /** > * Creates an unnamed structured task scope that creates virtual > threads. The task > * scope is owned by the current thread. > */ > public StructuredTaskScopeNanoTime() { > } > > /** > * Creates a structured task scope with the given name and thread > factory. > * > * @param name the name of the task scope, can be null > * @param factory the thread factory > */ > public StructuredTaskScopeNanoTime(String name, ThreadFactory factory) > { > super(name, factory); > } > > /** > * Wait for all subtasks started in this task scope to finish or the > task scope to > * shut down, up to the given deadline. > * > * @param deadlineNanoTime the deadline given in {@link > System#nanoTime()} units > * @return this task scope > * @throws IllegalStateException if this task scope is closed > * @throws WrongThreadException if the current thread is not the task > scope owner > * @throws InterruptedException if interrupted while waiting > * @throws TimeoutException if the deadline is reached while > waiting > */ > public StructuredTaskScopeNanoTime joinUntilNanoTime(long > deadlineNanoTime) throws InterruptedException, TimeoutException { > fork(() -> { > Thread.sleep(Duration.ofNanos(deadlineNanoTime - > System.nanoTime())); > shutdown(); > return null; > }); > join(); > return this; > } > } > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yuval.l at securithings.com Sun Jul 28 13:59:22 2024 From: yuval.l at securithings.com (Yuval Lombard) Date: Sun, 28 Jul 2024 16:59:22 +0300 Subject: Experiencing an issue with ScheduledExecutorService alongside VT In-Reply-To: <6baa943c-ddc7-4b30-825b-88e5aeabb33c@oracle.com> References: <3cdd7056-6321-4653-be4d-71bf5bea55e5@oracle.com> <213a86b9-2c9a-494f-9077-695008a48870@oracle.com> <6d928b93-8698-4546-9571-c7e00651ab3c@oracle.com> <28d98b3a-85b5-4e40-a935-a3a6e93e745d@oracle.com> <6baa943c-ddc7-4b30-825b-88e5aeabb33c@oracle.com> Message-ID: Hi Alan, Thanks for your feedback Happy to hear that the issue is observed. Yes, we are currently blocked by Spring's support, so I guess it will take us some time until we can resume testing I don't think we will have the privileges of dedicating time to try and adjust our branch to work with the two EAs. I am also concerned about possible noise that can come up when testing two EAs so we will wait On Sun, 28 Jul 2024 at 15:48, Alan Bateman wrote: > > > On 28/07/2024 12:41, Yuval Lombard wrote: > > Hi Team, > > > > For the sake of accuracy and integrity, I have noticed the > > previous thread dump was taken from a piece of code that does not > > match the provided example I attached in the first couple of mails I > > have sent. > > I have attached a new thread dump file that was taken from the exact > > version of the code I was testing. > > > > Will appreciate it if you could take a look again just to make sure > > you see the issue ( related to preemption when cancelling a timer > > after Object.wait(millis) ) you found in the previous dump I attached. > > Looks to me the same thing. > > In this dump, #302878 and #302879 are scheduling a timeout as part of a > timed-Socket.connect. ForkJoinPool-1-worker-2 and > ForkJoinPool-1-worker-3 are blocked trying to schedule a timeout. The > interesting one is #302780 as it seems to have been preempted while > blocking as it removes a cancelled timeout. > > This issue is fixed but the EA download is a bit behind and we need to > get it refreshed. Also I think you said something about the version of > Spring needing to updated to work with an EA build (as the EA builds are > tracking main line for JDK 24). > > -Alan > > > > -- Kind regards, *Yuval Lombard* *Lead Software Engineer* +972.50.548.0111 yuval.l at securithings.com [image: logo_black.png] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo_black.png Type: image/png Size: 99833 bytes Desc: not available URL: From werner.randelshofer at fibermail.ch Sun Jul 28 16:20:44 2024 From: werner.randelshofer at fibermail.ch (Werner Randelshofer) Date: Sun, 28 Jul 2024 18:20:44 +0200 Subject: Question about StructuredTaskScope.joinUntil(Instant) In-Reply-To: References: <439D398A-5972-49CE-8C06-1E6E05D92E60@fibermail.ch> Message-ID: Hi Sten, I had to revise my solution. The solution waited for too long, if the task finished earlier. The revised solution is quite complex now. See code below. Having a public method in StructuredTaskScope that waits until a timeout elapses, for example something like StructuredTaskScope.join(Duration timeout), would be very helpful for my use case. With best regards, Werner Revised solution: package org.example.structuredconcurrency; import java.util.concurrent.Callable; import java.util.concurrent.StructuredTaskScope; import java.util.concurrent.ThreadFactory; import java.util.concurrent.TimeoutException; /** * A {@link StructuredTaskScope} that supports a deadline given in {@link System#nanoTime()}. * * This code is public domain. * * @param the type of the structured task scope */ public class StructuredTaskScopeNanoTime extends StructuredTaskScope { private static class Sem { private volatile int threadCount; public synchronized void inc() { threadCount++; } public synchronized void dec() { threadCount--; if (threadCount == 0) { notifyAll(); } } public synchronized void awaitAll(long deadlineNanos) throws InterruptedException { long timeout; while (threadCount > 0 && (timeout = (deadlineNanos - System.nanoTime()/1000_000L)) > 0) { wait(timeout); } } } private final Sem sem = new Sem(); /** * Creates an unnamed structured task scope that creates virtual threads. The task * scope is owned by the current thread. */ public StructuredTaskScopeNanoTime() { } /** * Creates a structured task scope with the given name and thread factory. * * @param name the name of the task scope, can be null * @param factory the thread factory */ public StructuredTaskScopeNanoTime(String name, ThreadFactory factory) { super(name, factory); } @Override public Subtask fork(Callable task) { sem.inc(); return super.fork(() -> { try { return task.call(); } finally { sem.dec(); } }); } /** * Wait for all subtasks started in this task scope to finish or the task scope to * shut down, up to the given deadline. * * @param deadlineNanoTime the deadline given in {@link System#nanoTime()} units * @return this task scope * @throws IllegalStateException if this task scope is closed * @throws WrongThreadException if the current thread is not the task scope owner * @throws InterruptedException if interrupted while waiting * @throws TimeoutException if the deadline is reached while waiting */ public StructuredTaskScopeNanoTime joinUntilNanoTime(long deadlineNanoTime) throws InterruptedException, TimeoutException { super.fork(() -> { sem.awaitAll(deadlineNanoTime); shutdown(); return null; }); join(); return this; } } > On 28 Jul 2024, at 15:10, Sten Nordstrom wrote: > > This was surprising to me as well, as this can lead to some surprising results in environments with unreliable time synchronization. Are there any pointers re discussion why this approach was chosen instead of the more common way of specifying a maximum duration to wait? > > Glad to hear that you found a solution, we will need to do something similar when we start using StructuredTaskScopes. > > Best Regards, > Sten > > > > On Tue, Jun 11, 2024 at 18.33 Werner Randelshofer wrote: > I have solved my problem. :-) > > I have now implemented a subclass of StructuredTaskScope, which allows to specify a deadline in System.nanoTime() units. > With this design, the deadline is independent from external resources (like NTP time servers) over which the Java process has no control. > > See code below. > > With best regards, > Werner > ... From alan.bateman at oracle.com Sun Jul 28 17:30:13 2024 From: alan.bateman at oracle.com (Alan Bateman) Date: Sun, 28 Jul 2024 18:30:13 +0100 Subject: Concurrency issue with virtual threads In-Reply-To: <57721722171588@7jeuw3ncvslfpppo.sas.yp-c.yandex.net> References: <57721722171588@7jeuw3ncvslfpppo.sas.yp-c.yandex.net> Message-ID: <02937d44-6089-4eca-9deb-bcc8a20b1a14@oracle.com> On 28/07/2024 13:59, ?????? ??????? wrote: > : > > In the file pay attention to these lines: > > 12 org.apache.http.pool.AbstractConnPool.getPoolEntryBlocking(AbstractConnPool.java:319) > 92 org.apache.http.pool.AbstractConnPool.getPoolEntryBlocking(AbstractConnPool.java:391) Further up in the stack is AbstractConnPool.get with the synchronized block that is causing the issue here. A limitation right now is that a virtual thread cannot unmount when inside a synchronized statement or method. In this case it seems that all carriers are pinned by virtual threads that are all blocked in the same place. The other short term fix is to this to migrate this code to also use a j.u.concurrent lock. There is work under way to remove this limitation. There are EA builds available [1] that we looking for help testing before the changes are proposed for the main line and a future JDK release. -Alan [1] https://jdk.java.net/loom/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergei.tsypanov at yandex.ru Mon Jul 29 10:09:01 2024 From: sergei.tsypanov at yandex.ru (=?utf-8?B?0KHQtdGA0LPQtdC5INCm0YvQv9Cw0L3QvtCy?=) Date: Mon, 29 Jul 2024 12:09:01 +0200 Subject: Concurrency issue with virtual threads In-Reply-To: <02937d44-6089-4eca-9deb-bcc8a20b1a14@oracle.com> References: <57721722171588@7jeuw3ncvslfpppo.sas.yp-c.yandex.net> <02937d44-6089-4eca-9deb-bcc8a20b1a14@oracle.com> Message-ID: <6935251722247741@2mm3r6nfvztjs7vi.sas.yp-c.yandex.net> Hi Alan, and thanks for clarification! Is there any issue in tracker for this? Sergey > On 28/07/2024 13:59, ?????? ??????? wrote: > >> : >> >> In the file pay attention to these lines: >> >> 12 org.apache.http.pool.AbstractConnPool.getPoolEntryBlocking(AbstractConnPool.java:319) >> 92 org.apache.http.pool.AbstractConnPool.getPoolEntryBlocking(AbstractConnPool.java:391) > > Further up in the stack is AbstractConnPool.get with the synchronized block that is causing the issue here. A limitation right now is that a virtual thread cannot unmount when inside a synchronized statement or method. In this case it seems that all carriers are pinned by virtual threads that are all blocked in the same place. The other short term fix is to this to migrate this code to also use a j.u.concurrent lock. > > There is work under way to remove this limitation. There are EA builds available [1] that we looking for help testing before the changes are proposed for the main line and a future JDK release. > > -Alan > > [1] https://jdk.java.net/loom/ From Alan.Bateman at oracle.com Mon Jul 29 12:37:15 2024 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 29 Jul 2024 13:37:15 +0100 Subject: Question about StructuredTaskScope.joinUntil(Instant) In-Reply-To: References: <439D398A-5972-49CE-8C06-1E6E05D92E60@fibermail.ch> Message-ID: <2d23e490-6ef4-4f25-8949-81476daa97ab@oracle.com> On 28/07/2024 17:20, Werner Randelshofer wrote: > : > > Having a public method in StructuredTaskScope that waits until a timeout elapses, > for example something like StructuredTaskScope.join(Duration timeout), > would be very helpful for my use case. We have some proposed updates to this API for the next preview. Part of it is dropping the joinUntil preview API and replacing it with a timeout (as a Duration) that can be providing when opening a new STS. If the timeout expires before the join has completed then the STS will be cancelled. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From werner.randelshofer at fibermail.ch Tue Jul 30 13:22:02 2024 From: werner.randelshofer at fibermail.ch (Werner Randelshofer) Date: Tue, 30 Jul 2024 15:22:02 +0200 Subject: Question about StructuredTaskScope.joinUntil(Instant) In-Reply-To: <2d23e490-6ef4-4f25-8949-81476daa97ab@oracle.com> References: <439D398A-5972-49CE-8C06-1E6E05D92E60@fibermail.ch> <2d23e490-6ef4-4f25-8949-81476daa97ab@oracle.com> Message-ID: That?s awesome. Looking forward to the updated API! :-D -Werner > On 29 Jul 2024, at 14:37, Alan Bateman wrote: > > > > On 28/07/2024 17:20, Werner Randelshofer wrote: >> : >> >> Having a public method in StructuredTaskScope that waits until a timeout elapses, >> for example something like StructuredTaskScope.join(Duration timeout), >> would be very helpful for my use case. > We have some proposed updates to this API for the next preview. Part of it is dropping the joinUntil preview API and replacing it with a timeout (as a Duration) that can be providing when opening a new STS. If the timeout expires before the join has completed then the STS will be cancelled. > > -Alan From duke at openjdk.org Tue Jul 30 18:18:23 2024 From: duke at openjdk.org (duke) Date: Tue, 30 Jul 2024 18:18:23 GMT Subject: git: openjdk/loom: fibers: 3 new changesets Message-ID: Changeset: fcd988d8 Branch: fibers Author: Patricio Chilano Mateo Date: 2024-07-30 10:49:57 +0000 URL: https://git.openjdk.org/loom/commit/fcd988d899016d53af746f95c2e40f1c24f8ade2 remove LM_LEGACY support ! src/hotspot/cpu/aarch64/c1_MacroAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/c2_CodeStubs_aarch64.cpp ! src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp ! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp ! src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp ! src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp ! src/hotspot/cpu/aarch64/templateTable_aarch64.cpp ! src/hotspot/cpu/aarch64/vm_version_aarch64.hpp ! src/hotspot/cpu/riscv/c2_MacroAssembler_riscv.cpp ! src/hotspot/cpu/x86/c1_MacroAssembler_x86.cpp ! src/hotspot/cpu/x86/c2_CodeStubs_x86.cpp ! src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp ! src/hotspot/cpu/x86/interp_masm_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp ! src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp ! src/hotspot/cpu/x86/vm_version_x86.hpp ! src/hotspot/share/include/jvm.h ! src/hotspot/share/interpreter/interpreterRuntime.cpp ! src/hotspot/share/oops/instanceStackChunkKlass.cpp ! src/hotspot/share/oops/stackChunkOop.inline.hpp ! src/hotspot/share/prims/jvmtiEnv.cpp ! src/hotspot/share/runtime/abstract_vm_version.hpp ! src/hotspot/share/runtime/continuation.cpp ! src/hotspot/share/runtime/continuation.hpp ! src/hotspot/share/runtime/continuationFreezeThaw.cpp ! src/hotspot/share/runtime/continuationHelper.hpp ! src/hotspot/share/runtime/continuationHelper.inline.hpp ! src/hotspot/share/runtime/deoptimization.cpp ! src/hotspot/share/runtime/javaThread.cpp ! src/hotspot/share/runtime/objectMonitor.cpp ! src/hotspot/share/runtime/synchronizer.cpp ! test/hotspot/jtreg/runtime/vthread/JNIMonitor/JNIMonitor.java ! test/hotspot/jtreg/serviceability/jvmti/vthread/StopThreadTest/StopThreadTest.java ! test/jdk/java/lang/Thread/virtual/ActivateSpareCarrier.java ! test/jdk/java/lang/Thread/virtual/MonitorEnterExit.java ! test/jdk/java/lang/Thread/virtual/MonitorWaitNotify.java ! test/jdk/java/lang/Thread/virtual/MonitorsTest.java ! test/jdk/java/lang/Thread/virtual/Parking.java ! test/jdk/java/lang/Thread/virtual/RetryMonitorEnterWhenPinned.java ! test/jdk/java/lang/Thread/virtual/ThreadAPI.java ! test/jdk/java/lang/Thread/virtual/stress/LotsOfContendedMonitorEnter.java ! test/jdk/java/lang/Thread/virtual/stress/Skynet100kWithMonitors.java ! test/jdk/jdk/internal/vm/Continuation/Fuzz.java Changeset: 78f81b3c Branch: fibers Author: Patricio Chilano Mateo Date: 2024-07-30 10:50:30 +0000 URL: https://git.openjdk.org/loom/commit/78f81b3c392a39c30a7adbee7e0e631d53feb7e3 fix wrong assert in VThreadMonitorEnter ! src/hotspot/share/runtime/objectMonitor.cpp Changeset: 9b28761b Branch: fibers Author: Patricio Chilano Mateo Date: 2024-07-30 12:46:51 +0000 URL: https://git.openjdk.org/loom/commit/9b28761b635c09a5a1fc274a7a454c92303e6907 remove test ActivateSpareCarrier.java - test/jdk/java/lang/Thread/virtual/ActivateSpareCarrier.java From simon.koenig at ipvs.uni-stuttgart.de Wed Jul 31 10:56:42 2024 From: simon.koenig at ipvs.uni-stuttgart.de (=?UTF-8?Q?Simon_K=C3=B6nig?=) Date: Wed, 31 Jul 2024 12:56:42 +0200 Subject: Virtual Threads Deadlock on Trival Tail-Call Recursion Message-ID: # Problem Project Loom's virtual threads exhibit unexpected behavior when the virtual thread's stack grows. The following example shows a tail-recursive function `recursion` that stops the recursion at a depth of 1 million. Hence, it is not an infinite recursion. However, when submitting a virtual thread that executes this function, the program hangs indefinitely. # Code ```java package main; import java.util.concurrent.ExecutorService; import java.util.concurrent.Executors; import java.util.concurrent.Semaphore; public class Main { private static Semaphore sem = new Semaphore(0); public static void recursion(int depth) { if(depth < 1_000_000) { System.out.println(depth); recursion(depth + 1); return; } System.out.println("End :)"); sem.release(); } public static ExecutorService executor = Executors.newVirtualThreadPerTaskExecutor(); public static void main(String[] args) throws InterruptedException { executor.submit(() -> { recursion(0); }); // wait for recursion task to end sem.acquire(); } } ``` I am running ```sh $> java --version openjdk 22.0.2 2024-07-16 OpenJDK Runtime Environment (build 22.0.2+9) OpenJDK 64-Bit Server VM (build 22.0.2+9, mixed mode, sharing) $> javac --version javac 22.0.2 ``` And ```sh $> jstat -gc S0C S1C S0U S1U EC EU OC OU MC MU CCSC CCSU YGC YGCT FGC FGCT CGC CGCT GCT 0.0 0.0 0.0 0.0 24576.0 4096.0 471040.0 0.0 0.0 0.0 0.0 0.0 0 0.000 0 0.000 0 0.000 0.000 ``` # Expected Behavior The tail call should be optimized out and the program should exit normally. At the very least, a stack overflow exception should be raised, if this is the true cause of the deadlock. # Actual Behavior The program outputs ``` <...> 12961 12962 12963 12964 12965 ``` and hangs. -- Simon K?nig University of Stuttgart Institute of Parallel and Distributed Systems (IPVS) Distributed Systems Department Universit?tsstr. 38 70569 Stuttgart Germany e-mail: simon.koenig at ipvs.uni-stuttgart.de -------------- next part -------------- A non-text attachment was scrubbed... Name: simon_koenig.vcf Type: text/vcard Size: 122 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5073 bytes Desc: S/MIME Cryptographic Signature URL: From Alan.Bateman at oracle.com Wed Jul 31 11:34:14 2024 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 31 Jul 2024 12:34:14 +0100 Subject: Virtual Threads Deadlock on Trival Tail-Call Recursion In-Reply-To: References: Message-ID: On 31/07/2024 11:56, Simon K?nig wrote: > At the very least, a stack overflow exception should be raised, if > this is the true cause of the deadlock. The submit method returns a Future that can be used to get the result or exception, in this case Future::get will reveal the StackOverflowError. -Alan From stnordstrom at gmail.com Wed Jul 31 13:40:19 2024 From: stnordstrom at gmail.com (Sten Nordstrom) Date: Wed, 31 Jul 2024 16:40:19 +0300 Subject: Question about StructuredTaskScope.joinUntil(Instant) In-Reply-To: <2d23e490-6ef4-4f25-8949-81476daa97ab@oracle.com> References: <439D398A-5972-49CE-8C06-1E6E05D92E60@fibermail.ch> <2d23e490-6ef4-4f25-8949-81476daa97ab@oracle.com> Message-ID: This sounds excellent! Thank you! ? Sten On Mon, Jul 29, 2024 at 15.37 Alan Bateman wrote: > > > On 28/07/2024 17:20, Werner Randelshofer wrote: > > : > > Having a public method in StructuredTaskScope that waits until a timeout elapses, > for example something like StructuredTaskScope.join(Duration timeout), > would be very helpful for my use case. > > We have some proposed updates to this API for the next preview. Part of it > is dropping the joinUntil preview API and replacing it with a timeout (as a > Duration) that can be providing when opening a new STS. If the timeout > expires before the join has completed then the STS will be cancelled. > > > -Alan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron.pressler at oracle.com Wed Jul 31 14:10:25 2024 From: ron.pressler at oracle.com (Ron Pressler) Date: Wed, 31 Jul 2024 14:10:25 +0000 Subject: [External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: <9F42BD8F-B5CB-4655-9D01-6081580213FD@icloud.com> References: <12ACDD24-C874-45B1-9142-DACAB1E78956@oracle.com> <58e21790-551d-4717-ba16-17ccecbdaf22@oracle.com> <2F579C4D-B83F-4AC8-88BB-03723A34BD18@oracle.com> <323FD2E4-4902-48BD-9F62-2A2836DB860B@oracle.com> <89a06f68-0eec-4fce-9d7d-000057440a1b@oracle.com> <3FA9AD3E-BF31-4FF2-BB60-FCAEDADF228E@icloud.com> <9F42BD8F-B5CB-4655-9D01-6081580213FD@icloud.com> Message-ID: <69B230A1-4CB5-4146-8174-2B0841F32833@oracle.com> > On 25 Jul 2024, at 16:17, Robert Engels wrote: > > I have created a very simple unbounded FIFO queue designed for use with virtual threads to better ensure thread clean-up without the reliance of automatic clean-up of VTs. > > You can review the project here https://github.com/robaho/closablequeue Just to be clear, there is never any kind of ?automatic clean-up? of virtual threads. The bytes holding the state of a virtual thread that cannot possibly continue may or may not be collected before it is terminated, but even if the memory is collected, no cleanup is performed. The only way the collection can be observed is through mechanism that observe the GC?s implementation choices, such as weak references, etc. ? Ron From robaho at icloud.com Wed Jul 31 14:24:37 2024 From: robaho at icloud.com (Robert Engels) Date: Wed, 31 Jul 2024 09:24:37 -0500 Subject: [External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: <69B230A1-4CB5-4146-8174-2B0841F32833@oracle.com> References: <12ACDD24-C874-45B1-9142-DACAB1E78956@oracle.com> <58e21790-551d-4717-ba16-17ccecbdaf22@oracle.com> <2F579C4D-B83F-4AC8-88BB-03723A34BD18@oracle.com> <323FD2E4-4902-48BD-9F62-2A2836DB860B@oracle.com> <89a06f68-0eec-4fce-9d7d-000057440a1b@oracle.com> <3FA9AD3E-BF31-4FF2-BB60-FCAEDADF228E@icloud.com> <9F42BD8F-B5CB-4655-9D01-6081580213FD@icloud.com> <69B230A1-4CB5-4146-8174-2B0841F32833@oracle.com> Message-ID: The purpose of the queue implementation is so that a VT is not left running - hung on a queue that will never receive a value, and the reader has a way of cleaning up cleanly if needed. I still don?t see how automatically ?terminating/vanishing? the reading thread when it can?t make progress will work. It will be an absolute nightmare to audit any system that relies on this. I confess I am not a JDK engineer but without special casing how can the runtime know this - a special reference type for queue classes only? I.e. the blocked reader is using a WeakReference internally? Today, circular references are not circular in the context of a Thread GC root. You either have discoverability and monitorability of the execution threads or you don?t. I cited the areas of the Java specification that I believe govern this in terms of reachability, and I don?t think having them disappear is valid. It would be an incorrect subclassing of Thread to change this behavior in VirtualThread. > On Jul 31, 2024, at 9:10 AM, Ron Pressler wrote: > > > >> On 25 Jul 2024, at 16:17, Robert Engels wrote: >> >> I have created a very simple unbounded FIFO queue designed for use with virtual threads to better ensure thread clean-up without the reliance of automatic clean-up of VTs. >> >> You can review the project here https://github.com/robaho/closablequeue > > Just to be clear, there is never any kind of ?automatic clean-up? of virtual threads. The bytes holding the state of a virtual thread that cannot possibly continue may or may not be collected before it is terminated, but even if the memory is collected, no cleanup is performed. The only way the collection can be observed is through mechanism that observe the GC?s implementation choices, such as weak references, etc. > > ? Ron From ron.pressler at oracle.com Wed Jul 31 15:52:45 2024 From: ron.pressler at oracle.com (Ron Pressler) Date: Wed, 31 Jul 2024 15:52:45 +0000 Subject: [External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: References: <12ACDD24-C874-45B1-9142-DACAB1E78956@oracle.com> <58e21790-551d-4717-ba16-17ccecbdaf22@oracle.com> <2F579C4D-B83F-4AC8-88BB-03723A34BD18@oracle.com> <323FD2E4-4902-48BD-9F62-2A2836DB860B@oracle.com> <89a06f68-0eec-4fce-9d7d-000057440a1b@oracle.com> <3FA9AD3E-BF31-4FF2-BB60-FCAEDADF228E@icloud.com> <9F42BD8F-B5CB-4655-9D01-6081580213FD@icloud.com> <69B230A1-4CB5-4146-8174-2B0841F32833@oracle.com> Message-ID: > On 31 Jul 2024, at 15:24, Robert Engels wrote: > > The purpose of the queue implementation is so that a VT is not left running - hung on a queue that will never receive a value, and the reader has a way of cleaning up cleanly if needed. > > I still don?t see how automatically ?terminating/vanishing? the reading thread when it can?t make progress will work. There is no automatic termination or vanishing of anything. A virtual thread that cannot possibly ever have any effect and _already_ cannot be accessed or observed in any way, may or may not have its memory reclaimed, same as for all Java objects. > > It will be an absolute nightmare to audit any system that relies on this. Every Java system relies on this already, as this is how Java?s GCs have always worked. > I confess I am not a JDK engineer but without special casing how can the runtime know this - a special reference type for queue classes only? I.e. the blocked reader is using a WeakReference internally? Today, circular references are not circular in the context of a Thread GC root. There is nothing about queues or anything special here. No new kind of vanishing or cleanup. Just about the GC reclaiming and reusing the heap bytes of objects that have already vanished. If a thread can be observed, then its memory won't be reclaimed. If it cannot, then whether or not the bytes are reused is an internal implementation detail, just as it is for any Java object. ? Ron From robaho at icloud.com Wed Jul 31 16:35:08 2024 From: robaho at icloud.com (robert engels) Date: Wed, 31 Jul 2024 11:35:08 -0500 Subject: [External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: References: Message-ID: Ron, Given the following code 4 running in a VT: A a = new VeryLargeObjectWithFinalizer(); try { queue.take(); } finally { a.doSonething(); } What in the Java spec would allow a to be reclaimed without doSomething() being called? If a can?t be reclaimed then the reclaiming on VT in this case is pointless. > On Jul 31, 2024, at 10:54?AM, Ron Pressler wrote: > > ? > >> On 31 Jul 2024, at 15:24, Robert Engels wrote: >> >> The purpose of the queue implementation is so that a VT is not left running - hung on a queue that will never receive a value, and the reader has a way of cleaning up cleanly if needed. >> >> I still don?t see how automatically ?terminating/vanishing? the reading thread when it can?t make progress will work. > > There is no automatic termination or vanishing of anything. A virtual thread that cannot possibly ever have any effect and _already_ cannot be accessed or observed in any way, may or may not have its memory reclaimed, same as for all Java objects. > >> >> It will be an absolute nightmare to audit any system that relies on this. > > > Every Java system relies on this already, as this is how Java?s GCs have always worked. > > >> I confess I am not a JDK engineer but without special casing how can the runtime know this - a special reference type for queue classes only? I.e. the blocked reader is using a WeakReference internally? Today, circular references are not circular in the context of a Thread GC root. > > There is nothing about queues or anything special here. No new kind of vanishing or cleanup. Just about the GC reclaiming and reusing the heap bytes of objects that have already vanished. If a thread can be observed, then its memory won't be reclaimed. If it cannot, then whether or not the bytes are reused is an internal implementation detail, just as it is for any Java object. > > ? Ron > > From robaho at icloud.com Wed Jul 31 16:39:25 2024 From: robaho at icloud.com (robert engels) Date: Wed, 31 Jul 2024 11:39:25 -0500 Subject: [External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: References: Message-ID: <83D4E0D6-AFFE-4BD4-B751-B497DEFA60BF@icloud.com> To clarify, there is no other reference to the queue so take() cannot proceed > On Jul 31, 2024, at 11:36?AM, robert engels wrote: > > ?Ron, > > Given the following code 4 running in a VT: > > A a = new VeryLargeObjectWithFinalizer(); > > try { > queue.take(); > } finally { > a.doSonething(); > } > > What in the Java spec would allow a to be reclaimed without doSomething() being called? > > If a can?t be reclaimed then the reclaiming on VT in this case is pointless. > >> On Jul 31, 2024, at 10:54?AM, Ron Pressler wrote: >> >> ? >> >>>> On 31 Jul 2024, at 15:24, Robert Engels wrote: >>> >>> The purpose of the queue implementation is so that a VT is not left running - hung on a queue that will never receive a value, and the reader has a way of cleaning up cleanly if needed. >>> >>> I still don?t see how automatically ?terminating/vanishing? the reading thread when it can?t make progress will work. >> >> There is no automatic termination or vanishing of anything. A virtual thread that cannot possibly ever have any effect and _already_ cannot be accessed or observed in any way, may or may not have its memory reclaimed, same as for all Java objects. >> >>> >>> It will be an absolute nightmare to audit any system that relies on this. >> >> >> Every Java system relies on this already, as this is how Java?s GCs have always worked. >> >> >>> I confess I am not a JDK engineer but without special casing how can the runtime know this - a special reference type for queue classes only? I.e. the blocked reader is using a WeakReference internally? Today, circular references are not circular in the context of a Thread GC root. >> >> There is nothing about queues or anything special here. No new kind of vanishing or cleanup. Just about the GC reclaiming and reusing the heap bytes of objects that have already vanished. If a thread can be observed, then its memory won't be reclaimed. If it cannot, then whether or not the bytes are reused is an internal implementation detail, just as it is for any Java object. >> >> ? Ron >> >> From duke at openjdk.org Wed Jul 31 16:42:50 2024 From: duke at openjdk.org (duke) Date: Wed, 31 Jul 2024 16:42:50 GMT Subject: git: openjdk/loom: fibers: 2 new changesets Message-ID: Changeset: 7488f603 Branch: fibers Author: Patricio Chilano Mateo Date: 2024-07-31 11:41:43 +0000 URL: https://git.openjdk.org/loom/commit/7488f603b73623b6dece7a952f70eb9dc4e2ea60 fix assert ! src/hotspot/share/runtime/continuation.cpp Changeset: 47f46ad0 Branch: fibers Author: Patricio Chilano Mateo Date: 2024-07-31 12:39:16 +0000 URL: https://git.openjdk.org/loom/commit/47f46ad04eff64924f8fe3e85ffa7531789afa1d add comment on StubAssembler::epilogue ! src/hotspot/cpu/aarch64/c1_Runtime1_aarch64.cpp ! src/hotspot/cpu/x86/c1_Runtime1_x86.cpp From pedro.lamarao at prodist.com.br Wed Jul 31 16:43:15 2024 From: pedro.lamarao at prodist.com.br (=?UTF-8?Q?Pedro_Lamar=C3=A3o?=) Date: Wed, 31 Jul 2024 13:43:15 -0300 Subject: [External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: <83D4E0D6-AFFE-4BD4-B751-B497DEFA60BF@icloud.com> References: <83D4E0D6-AFFE-4BD4-B751-B497DEFA60BF@icloud.com> Message-ID: if take cannot possibly proceed, then the body of the finally block will never, ever, run, and all memory involved has just leaked. Em qua., 31 de jul. de 2024 ?s 13:41, robert engels escreveu: > To clarify, there is no other reference to the queue so take() cannot > proceed > > > On Jul 31, 2024, at 11:36?AM, robert engels wrote: > > > > ?Ron, > > > > Given the following code 4 running in a VT: > > > > A a = new VeryLargeObjectWithFinalizer(); > > > > try { > > queue.take(); > > } finally { > > a.doSonething(); > > } > > > > What in the Java spec would allow a to be reclaimed without > doSomething() being called? > > > > If a can?t be reclaimed then the reclaiming on VT in this case is > pointless. > > > >> On Jul 31, 2024, at 10:54?AM, Ron Pressler > wrote: > >> > >> ? > >> > >>>> On 31 Jul 2024, at 15:24, Robert Engels wrote: > >>> > >>> The purpose of the queue implementation is so that a VT is not left > running - hung on a queue that will never receive a value, and the reader > has a way of cleaning up cleanly if needed. > >>> > >>> I still don?t see how automatically ?terminating/vanishing? the > reading thread when it can?t make progress will work. > >> > >> There is no automatic termination or vanishing of anything. A virtual > thread that cannot possibly ever have any effect and _already_ cannot be > accessed or observed in any way, may or may not have its memory reclaimed, > same as for all Java objects. > >> > >>> > >>> It will be an absolute nightmare to audit any system that relies on > this. > >> > >> > >> Every Java system relies on this already, as this is how Java?s GCs > have always worked. > >> > >> > >>> I confess I am not a JDK engineer but without special casing how can > the runtime know this - a special reference type for queue classes only? > I.e. the blocked reader is using a WeakReference internally? Today, > circular references are not circular in the context of a Thread GC root. > >> > >> There is nothing about queues or anything special here. No new kind of > vanishing or cleanup. Just about the GC reclaiming and reusing the heap > bytes of objects that have already vanished. If a thread can be observed, > then its memory won't be reclaimed. If it cannot, then whether or not the > bytes are reused is an internal implementation detail, just as it is for > any Java object. > >> > >> ? Ron > >> > >> > -- Pedro Lamar?o -------------- next part -------------- An HTML attachment was scrubbed... URL: From robaho at icloud.com Wed Jul 31 16:48:47 2024 From: robaho at icloud.com (robert engels) Date: Wed, 31 Jul 2024 11:48:47 -0500 Subject: [External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From rengels at ix.netcom.com Wed Jul 31 16:53:31 2024 From: rengels at ix.netcom.com (Robert Engels) Date: Wed, 31 Jul 2024 11:53:31 -0500 Subject: [External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: References: Message-ID: <39E8937D-D166-48E1-9839-2D68A25778C0@ix.netcom.com> An HTML attachment was scrubbed... URL: From pedro.lamarao at prodist.com.br Wed Jul 31 16:58:44 2024 From: pedro.lamarao at prodist.com.br (=?UTF-8?Q?Pedro_Lamar=C3=A3o?=) Date: Wed, 31 Jul 2024 13:58:44 -0300 Subject: [External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: <39E8937D-D166-48E1-9839-2D68A25778C0@ix.netcom.com> References: <39E8937D-D166-48E1-9839-2D68A25778C0@ix.netcom.com> Message-ID: This seems to me a simple contradiction of requirements. One cannot require that this program behaves as stated, that this thread cannot proceed, and then require that the finally block runs. Either the thread can proceed, or it cannot. If it cannot, requiring that this thread runs code is nonsensical to me. Perhaps one should just revise one's queue design and/or implementation to avoid becoming "impossible" instead. The fact the queue in question allows for "zombie platform thread" does not seem a feature to me. "zombie platform threads" is just a resource leak in a system with no automatic resource reclamation. Em qua., 31 de jul. de 2024 ?s 13:53, Robert Engels escreveu: > More importantly the reason to reclaim the VT would be to release its > stack memory I assume. So then there are no rererences to a which would > means would get reclaimed without running the finally. This is invalid. > > On Jul 31, 2024, at 11:50?AM, robert engels wrote: > > ? > Correct and that is valid. Reclaiming a without running the finally block > is invalid. > > On Jul 31, 2024, at 11:44?AM, Pedro Lamar?o > wrote: > > ? > if take cannot possibly proceed, then the body of the finally block will > never, ever, run, and all memory involved has just leaked. > > > Em qua., 31 de jul. de 2024 ?s 13:41, robert engels > escreveu: > >> To clarify, there is no other reference to the queue so take() cannot >> proceed >> >> > On Jul 31, 2024, at 11:36?AM, robert engels wrote: >> > >> > ?Ron, >> > >> > Given the following code 4 running in a VT: >> > >> > A a = new VeryLargeObjectWithFinalizer(); >> > >> > try { >> > queue.take(); >> > } finally { >> > a.doSonething(); >> > } >> > >> > What in the Java spec would allow a to be reclaimed without >> doSomething() being called? >> > >> > If a can?t be reclaimed then the reclaiming on VT in this case is >> pointless. >> > >> >> On Jul 31, 2024, at 10:54?AM, Ron Pressler >> wrote: >> >> >> >> ? >> >> >> >>>> On 31 Jul 2024, at 15:24, Robert Engels wrote: >> >>> >> >>> The purpose of the queue implementation is so that a VT is not left >> running - hung on a queue that will never receive a value, and the reader >> has a way of cleaning up cleanly if needed. >> >>> >> >>> I still don?t see how automatically ?terminating/vanishing? the >> reading thread when it can?t make progress will work. >> >> >> >> There is no automatic termination or vanishing of anything. A virtual >> thread that cannot possibly ever have any effect and _already_ cannot be >> accessed or observed in any way, may or may not have its memory reclaimed, >> same as for all Java objects. >> >> >> >>> >> >>> It will be an absolute nightmare to audit any system that relies on >> this. >> >> >> >> >> >> Every Java system relies on this already, as this is how Java?s GCs >> have always worked. >> >> >> >> >> >>> I confess I am not a JDK engineer but without special casing how can >> the runtime know this - a special reference type for queue classes only? >> I.e. the blocked reader is using a WeakReference internally? Today, >> circular references are not circular in the context of a Thread GC root. >> >> >> >> There is nothing about queues or anything special here. No new kind of >> vanishing or cleanup. Just about the GC reclaiming and reusing the heap >> bytes of objects that have already vanished. If a thread can be observed, >> then its memory won't be reclaimed. If it cannot, then whether or not the >> bytes are reused is an internal implementation detail, just as it is for >> any Java object. >> >> >> >> ? Ron >> >> >> >> >> > > > -- > Pedro Lamar?o > > -- Pedro Lamar?o -------------- next part -------------- An HTML attachment was scrubbed... URL: From robaho at icloud.com Wed Jul 31 17:14:08 2024 From: robaho at icloud.com (robert engels) Date: Wed, 31 Jul 2024 12:14:08 -0500 Subject: [External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: References: Message-ID: <37D2BBEE-1B05-4FB0-82CC-CD14935B1C8E@icloud.com> An HTML attachment was scrubbed... URL: From robaho at icloud.com Wed Jul 31 17:15:49 2024 From: robaho at icloud.com (robert engels) Date: Wed, 31 Jul 2024 12:15:49 -0500 Subject: [External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: References: Message-ID: <370F3502-38BE-4775-87B6-8472050F067E@icloud.com> An HTML attachment was scrubbed... URL: From pedro.lamarao at prodist.com.br Wed Jul 31 17:23:08 2024 From: pedro.lamarao at prodist.com.br (=?UTF-8?Q?Pedro_Lamar=C3=A3o?=) Date: Wed, 31 Jul 2024 14:23:08 -0300 Subject: [External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: <370F3502-38BE-4775-87B6-8472050F067E@icloud.com> References: <370F3502-38BE-4775-87B6-8472050F067E@icloud.com> Message-ID: In the situation being considered, the finally block will never, ever, run. What is the meaning of requiring that this effect be ordered before or after some point in time? Effects that will never, ever, happen, have no place in time to be ordered here or there. The machine cannot fail to properly order an effect that will never, ever, happen. Em qua., 31 de jul. de 2024 ?s 14:16, robert engels escreveu: > More specifically, it is that ?a? cannot be reclaimed and the finally not > run. This breaks the program ordering guarantees as related to > retainability. > > On Jul 31, 2024, at 11:59?AM, Pedro Lamar?o > wrote: > > ? > This seems to me a simple contradiction of requirements. > One cannot require that this program behaves as stated, that this thread > cannot proceed, and then require that the finally block runs. > Either the thread can proceed, or it cannot. > If it cannot, requiring that this thread runs code is nonsensical to me. > Perhaps one should just revise one's queue design and/or implementation to > avoid becoming "impossible" instead. > The fact the queue in question allows for "zombie platform thread" does > not seem a feature to me. > "zombie platform threads" is just a resource leak in a system with no > automatic resource reclamation. > > -- Pedro Lamar?o -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Wed Jul 31 17:27:47 2024 From: duke at openjdk.org (duke) Date: Wed, 31 Jul 2024 17:27:47 GMT Subject: git: openjdk/loom: fibers: 47 new changesets Message-ID: <144a04e9-8e24-4866-838a-ea900cb11667@openjdk.org> Changeset: 2fbdbaca Branch: fibers Author: Shaojin Wen Committer: Claes Redestad Date: 2024-07-27 22:54:47 +0000 URL: https://git.openjdk.org/loom/commit/2fbdbacad7ad45055a482c764f84da4568383020 8337245: Fix wrong comment of StringConcatHelper Reviewed-by: phh, redestad ! src/java.base/share/classes/java/lang/StringConcatHelper.java Changeset: 90641a60 Branch: fibers Author: Tobias Hartmann Date: 2024-07-29 05:05:32 +0000 URL: https://git.openjdk.org/loom/commit/90641a601c9385b5e76e1abc5362ace3ab1fff3d 8336095: Use-after-free in Superword leads to memory corruption Reviewed-by: epeter, kvn, rrich ! src/hotspot/share/opto/loopnode.hpp Changeset: 657c0bdd Branch: fibers Author: Tobias Hartmann Date: 2024-07-29 05:31:10 +0000 URL: https://git.openjdk.org/loom/commit/657c0bddf90b537ac653817571532705a6e3643a 8336999: Verification for resource area allocated data structures in C2 Reviewed-by: chagedorn, kvn ! src/hotspot/share/ci/ciReplay.cpp ! src/hotspot/share/libadt/vectset.cpp ! src/hotspot/share/libadt/vectset.hpp ! src/hotspot/share/memory/allocation.cpp ! src/hotspot/share/memory/allocation.hpp ! src/hotspot/share/opto/block.cpp ! src/hotspot/share/opto/block.hpp ! src/hotspot/share/opto/domgraph.cpp ! src/hotspot/share/opto/loopnode.cpp ! src/hotspot/share/opto/loopnode.hpp ! src/hotspot/share/opto/node.cpp ! src/hotspot/share/opto/node.hpp ! src/hotspot/share/opto/phaseX.cpp ! src/hotspot/share/opto/vector.cpp Changeset: dab2a0b5 Branch: fibers Author: Thomas Schatzl Date: 2024-07-29 09:10:25 +0000 URL: https://git.openjdk.org/loom/commit/dab2a0b5978cdd3fad693e4c120a84bb64a3ccde 8337222: gc/TestDisableExplicitGC.java fails due to unexpected CodeCache GC Reviewed-by: iwalulya, shade ! test/hotspot/jtreg/gc/TestDisableExplicitGC.java Changeset: db168d9e Branch: fibers Author: Jan Kratochvil Committer: Yuri Nesterenko Date: 2024-07-29 09:18:56 +0000 URL: https://git.openjdk.org/loom/commit/db168d9e10c4a302b743ee208e24ba7303fec582 8336966: Alpine Linux x86_64 compilation error: sendfile64 Reviewed-by: bpb ! src/java.base/linux/native/libnio/ch/FileDispatcherImpl.c ! src/java.base/linux/native/libnio/fs/LinuxNativeDispatcher.c Changeset: 9124a94e Branch: fibers Author: Erik Gahlin Date: 2024-07-29 09:52:38 +0000 URL: https://git.openjdk.org/loom/commit/9124a94e383f5bc6a3376eecc97ee8bd22f9e420 8337165: Test jdk/jfr/event/gc/stacktrace/TestG1YoungAllocationPendingStackTrace.java failed: IndexOutOfBoundsException: Index 64 out of bounds for length 64 Reviewed-by: phh ! test/jdk/jdk/jfr/event/gc/stacktrace/TestDefNewAllocationPendingStackTrace.java ! test/jdk/jdk/jfr/event/gc/stacktrace/TestG1HumongousAllocationPendingStackTrace.java ! test/jdk/jdk/jfr/event/gc/stacktrace/TestG1OldAllocationPendingStackTrace.java ! test/jdk/jdk/jfr/event/gc/stacktrace/TestG1YoungAllocationPendingStackTrace.java ! test/jdk/jdk/jfr/event/gc/stacktrace/TestMarkSweepCompactAllocationPendingStackTrace.java ! test/jdk/jdk/jfr/event/gc/stacktrace/TestMetaspaceG1GCAllocationPendingStackTrace.java ! test/jdk/jdk/jfr/event/gc/stacktrace/TestMetaspaceParallelGCAllocationPendingStackTrace.java ! test/jdk/jdk/jfr/event/gc/stacktrace/TestMetaspaceSerialGCAllocationPendingStackTrace.java ! test/jdk/jdk/jfr/event/gc/stacktrace/TestParallelMarkSweepAllocationPendingStackTrace.java ! test/jdk/jdk/jfr/event/gc/stacktrace/TestParallelScavengeAllocationPendingStackTrace.java Changeset: cd52ad80 Branch: fibers Author: Albert Mingkun Yang Date: 2024-07-29 12:30:57 +0000 URL: https://git.openjdk.org/loom/commit/cd52ad80a82c8165424722dcddd37d6584137031 8337267: [REDO] G1: Refactor G1RebuildRSAndScrubTask Reviewed-by: gli, tschatzl ! src/hotspot/share/gc/g1/g1ConcurrentRebuildAndScrub.cpp Changeset: ee365d75 Branch: fibers Author: Aleksey Shipilev Date: 2024-07-29 13:37:56 +0000 URL: https://git.openjdk.org/loom/commit/ee365d75cca6f33e5781fe514e557caba2b67c32 8336342: Fix known X11 library locations in sysroot Reviewed-by: jwaters, phh, prr ! make/autoconf/lib-x11.m4 Changeset: c23d37e1 Branch: fibers Author: Naoto Sato Date: 2024-07-29 16:43:25 +0000 URL: https://git.openjdk.org/loom/commit/c23d37e10a429c0e7248593b07ef1ccdcd34bd1c 8337300: java/lang/Process/WaitForDuration.java leaves child process behind Reviewed-by: alanb, iris, bpb ! test/jdk/java/lang/Process/WaitForDuration.java Changeset: c4e6255a Branch: fibers Author: Chris Plummer Date: 2024-07-29 16:55:38 +0000 URL: https://git.openjdk.org/loom/commit/c4e6255ac3ec5520c4cb6d0d4ad9013da177ba88 8332738: Debug agent can deadlock on callbackLock when using StackFrame.PopFrames Reviewed-by: sspitsyn, amenkov ! src/jdk.jdwp.agent/share/native/libjdwp/eventHandler.c ! src/jdk.jdwp.agent/share/native/libjdwp/eventHandler.h ! src/jdk.jdwp.agent/share/native/libjdwp/invoker.c ! src/jdk.jdwp.agent/share/native/libjdwp/stepControl.c ! src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c Changeset: a86244f8 Branch: fibers Author: Archie Cobbs Date: 2024-07-29 19:16:39 +0000 URL: https://git.openjdk.org/loom/commit/a86244f83cc4e234bdf8dc2c8d87640b6aab8463 6381729: Javadoc for generic constructor doesn't document type parameter Reviewed-by: jjg, liach ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractExecutableMemberWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractMemberWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassUseWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ConstructorWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Signatures.java ! test/langtools/jdk/javadoc/doclet/testErasure/TestErasure.java ! test/langtools/jdk/javadoc/doclet/testTypeParams/TestTypeParameters.java = test/langtools/jdk/javadoc/doclet/testTypeParams/pkg/CtorTypeParam.java Changeset: bd36b6ae Branch: fibers Author: Justin Lu Date: 2024-07-29 19:28:14 +0000 URL: https://git.openjdk.org/loom/commit/bd36b6ae5d0d760670a0bd722878614a6cd553d6 8337285: Examine java.text.DecimalFormat API for api/implXxx tag usage Reviewed-by: naoto, liach ! src/java.base/share/classes/java/text/DecimalFormat.java Changeset: ab27090a Branch: fibers Author: Chen Liang Date: 2024-07-29 21:58:08 +0000 URL: https://git.openjdk.org/loom/commit/ab27090aa085283233851410827767785b3b7b1f 8337225: Demote maxStack and maxLocals from CodeModel to CodeAttribute Reviewed-by: asotona ! src/java.base/share/classes/java/lang/classfile/CodeModel.java ! src/java.base/share/classes/java/lang/classfile/attribute/CodeAttribute.java ! src/java.base/share/classes/jdk/internal/classfile/impl/AbstractUnboundModel.java ! src/java.base/share/classes/jdk/internal/classfile/impl/BufferedCodeBuilder.java ! src/java.base/share/classes/jdk/internal/classfile/impl/BufferedFieldBuilder.java ! src/java.base/share/classes/jdk/internal/classfile/impl/BufferedMethodBuilder.java ! src/java.base/share/classes/jdk/internal/classfile/impl/CodeImpl.java ! src/java.base/share/classes/jdk/internal/classfile/impl/DirectCodeBuilder.java ! src/java.base/share/classes/jdk/internal/classfile/impl/TerminalCodeBuilder.java ! test/jdk/jdk/classfile/BuilderBlockTest.java ! test/jdk/jdk/classfile/CorpusTest.java ! test/jdk/jdk/classfile/DiscontinuedInstructionsTest.java ! test/jdk/jdk/classfile/StackMapsTest.java Changeset: 7e21d4c1 Branch: fibers Author: Prasanta Sadhukhan Date: 2024-07-30 03:03:43 +0000 URL: https://git.openjdk.org/loom/commit/7e21d4c1916d6690b717911179314c26a0da5ed9 8337268: Redundant Math.ceil in StyleSheet.ListPainter#drawShape Reviewed-by: prr, aivanov ! src/java.desktop/share/classes/javax/swing/text/html/StyleSheet.java Changeset: bc7c255b Branch: fibers Author: Kim Barrett Date: 2024-07-30 07:24:22 +0000 URL: https://git.openjdk.org/loom/commit/bc7c255b156bf3bb3fd8c3f622b8127ab27e7c7a 8337416: Fix -Wzero-as-null-pointer-constant warnings in misc. runtime code Reviewed-by: dholmes, jwaters ! src/hotspot/share/logging/logConfiguration.cpp ! src/hotspot/share/memory/metaspace/metachunk.cpp ! src/hotspot/share/memory/metaspace/rootChunkArea.cpp ! src/hotspot/share/memory/virtualspace.cpp ! src/hotspot/share/oops/constantPool.cpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/method.cpp ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/javaThread.cpp ! src/hotspot/share/runtime/vframeArray.cpp Changeset: 9e6e0a8f Branch: fibers Author: Aleksey Shipilev Date: 2024-07-30 08:27:27 +0000 URL: https://git.openjdk.org/loom/commit/9e6e0a8f341389215f0db6b2260f2b16351f02be 8336343: Add more known sysroot library locations for ALSA Reviewed-by: phh, prr, ihse ! make/autoconf/lib-alsa.m4 Changeset: 156f0b43 Branch: fibers Author: Aleksey Shipilev Date: 2024-07-30 08:29:23 +0000 URL: https://git.openjdk.org/loom/commit/156f0b4332bf076165898417cf6678d2fc32df5c 8337213: Shenandoah: Add verification for class mirrors Reviewed-by: rkennke, wkemper ! src/hotspot/share/gc/shenandoah/shenandoahAsserts.cpp ! src/hotspot/share/gc/shenandoah/shenandoahVerifier.cpp Changeset: 7ac53118 Branch: fibers Author: Amit Kumar Date: 2024-07-30 09:32:27 +0000 URL: https://git.openjdk.org/loom/commit/7ac531181c25815577ba2f6f426e1da270e4f589 8331126: [s390x] secondary_super_cache does not scale well Reviewed-by: lucy, aph, mdoerr ! src/hotspot/cpu/s390/macroAssembler_s390.cpp ! src/hotspot/cpu/s390/macroAssembler_s390.hpp ! src/hotspot/cpu/s390/s390.ad ! src/hotspot/cpu/s390/stubGenerator_s390.cpp ! src/hotspot/cpu/s390/vm_version_s390.cpp ! src/hotspot/cpu/s390/vm_version_s390.hpp Changeset: 0325ab8d Branch: fibers Author: Kevin Walls Date: 2024-07-30 10:44:31 +0000 URL: https://git.openjdk.org/loom/commit/0325ab8d2353f29ac40ff4b028cbc29bff40c59b 8335610: DiagnosticFramework: CmdLine::is_executable() correction Reviewed-by: dholmes, jsjolen ! src/hotspot/share/services/diagnosticFramework.hpp Changeset: 81628328 Branch: fibers Author: Matthias Baesken Date: 2024-07-30 12:40:35 +0000 URL: https://git.openjdk.org/loom/commit/8162832832ac6e8c17f942e718e309a3489e0da6 8333354: ubsan: frame.inline.hpp:91:25: and src/hotspot/share/runtime/frame.inline.hpp:88:29: runtime error: member call on null pointer of type 'const struct SmallRegisterMap' Co-authored-by: Kim Barrett Reviewed-by: rrich, clanger ! src/hotspot/cpu/aarch64/smallRegisterMap_aarch64.inline.hpp ! src/hotspot/cpu/arm/smallRegisterMap_arm.inline.hpp ! src/hotspot/cpu/ppc/smallRegisterMap_ppc.inline.hpp ! src/hotspot/cpu/riscv/smallRegisterMap_riscv.inline.hpp ! src/hotspot/cpu/s390/smallRegisterMap_s390.inline.hpp ! src/hotspot/cpu/x86/smallRegisterMap_x86.inline.hpp ! src/hotspot/cpu/zero/smallRegisterMap_zero.inline.hpp ! src/hotspot/share/oops/stackChunkOop.cpp ! src/hotspot/share/oops/stackChunkOop.inline.hpp ! src/hotspot/share/runtime/continuationFreezeThaw.cpp Changeset: 79bdd811 Branch: fibers Author: Albert Mingkun Yang Date: 2024-07-30 13:38:11 +0000 URL: https://git.openjdk.org/loom/commit/79bdd811876d75974536aac088bae1719387c97f 8336763: Parallel: Merge PCMarkAndPushClosure and PCIterateMarkAndPushClosure Reviewed-by: gli, zgu ! src/hotspot/share/gc/parallel/psCompactionManager.cpp ! src/hotspot/share/gc/parallel/psCompactionManager.hpp ! src/hotspot/share/gc/parallel/psCompactionManager.inline.hpp ! src/hotspot/share/gc/parallel/psParallelCompact.cpp Changeset: 41486131 Branch: fibers Author: Erik Gahlin Date: 2024-07-30 13:47:58 +0000 URL: https://git.openjdk.org/loom/commit/41486131481164a559aa534807fe1a77a7d29fc8 8335907: JFR: Make SettingControls more robust Reviewed-by: mgronlun ! src/jdk.jfr/share/classes/jdk/jfr/internal/EventControl.java + src/jdk.jfr/share/classes/jdk/jfr/internal/settings/BooleanSetting.java - src/jdk.jfr/share/classes/jdk/jfr/internal/settings/BooleanValue.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/settings/CutoffSetting.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/settings/EnabledSetting.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/settings/LevelSetting.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/settings/PeriodSetting.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/settings/StackTraceSetting.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/settings/ThresholdSetting.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/settings/ThrottleSetting.java - src/jdk.jfr/share/classes/jdk/jfr/internal/settings/ThrottleUnit.java + src/jdk.jfr/share/classes/jdk/jfr/internal/util/Rate.java + src/jdk.jfr/share/classes/jdk/jfr/internal/util/TimespanUnit.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/util/Utils.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/util/ValueFormatter.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/util/ValueParser.java + test/jdk/jdk/jfr/api/settings/TestSettingControl.java Changeset: 1cb27f7e Branch: fibers Author: Neethu Prasad Date: 2024-07-30 14:08:17 +0000 URL: https://git.openjdk.org/loom/commit/1cb27f7e2355ccb911bb274fc004e5bc57fd5dc9 8334230: Optimize C2 classes layout Reviewed-by: shade, kvn, thartmann ! src/hotspot/share/gc/shared/c2/barrierSetC2.hpp ! src/hotspot/share/libadt/vectset.hpp ! src/hotspot/share/opto/callnode.hpp ! src/hotspot/share/opto/memnode.cpp Changeset: 2c9fd901 Branch: fibers Author: Vanitha B P Committer: Alexey Semenyuk Date: 2024-07-30 15:04:57 +0000 URL: https://git.openjdk.org/loom/commit/2c9fd9016f4675448a62380ff2b86533020e690f 8336315: tools/jpackage/windows/WinChildProcessTest.java Failed: Check is calculator process is alive Reviewed-by: asemenyuk, almatvee ! test/jdk/tools/jpackage/apps/ChildProcessAppLauncher.java ! test/jdk/tools/jpackage/windows/WinChildProcessTest.java Changeset: a91f9ba8 Branch: fibers Author: Gerard Ziemski Date: 2024-07-30 15:22:25 +0000 URL: https://git.openjdk.org/loom/commit/a91f9ba84906dae10b050e15307ba0f0f05af3e4 8301403: Eliminate memory allocations in JVMFlag::printFlags during signal handling Reviewed-by: stuefe, jsjolen, dholmes ! src/hotspot/share/runtime/flags/jvmFlag.cpp ! src/hotspot/share/utilities/bitMap.cpp ! src/hotspot/share/utilities/bitMap.hpp ! src/hotspot/share/utilities/globalDefinitions.hpp Changeset: 6154a212 Branch: fibers Author: Chen Liang Date: 2024-07-30 17:41:38 +0000 URL: https://git.openjdk.org/loom/commit/6154a2129ba505b7163a1998792296827a056750 8336032: Enforce immutability of Lists used by ClassFile API Reviewed-by: asotona ! src/java.base/share/classes/java/lang/classfile/AttributedElement.java ! src/java.base/share/classes/java/lang/classfile/ClassSignature.java ! src/java.base/share/classes/java/lang/classfile/CompoundElement.java ! src/java.base/share/classes/jdk/internal/classfile/impl/AbstractUnboundModel.java ! src/java.base/share/classes/jdk/internal/classfile/impl/BoundAttribute.java ! src/java.base/share/classes/jdk/internal/classfile/impl/BufferedCodeBuilder.java ! src/java.base/share/classes/jdk/internal/classfile/impl/BufferedFieldBuilder.java ! src/java.base/share/classes/jdk/internal/classfile/impl/BufferedMethodBuilder.java ! src/java.base/share/classes/jdk/internal/classfile/impl/StackMapDecoder.java ! src/java.base/share/classes/jdk/internal/classfile/impl/UnboundAttribute.java ! src/java.base/share/classes/jdk/internal/classfile/impl/verifier/VerifierImpl.java Changeset: 93c19ac7 Branch: fibers Author: Chen Liang Date: 2024-07-30 17:41:49 +0000 URL: https://git.openjdk.org/loom/commit/93c19ac73c2feb8d6191bc5da98b4a9c8e2b5590 8337219: AccessFlags factories do not require necessary arguments Reviewed-by: asotona ! src/java.base/share/classes/java/lang/classfile/AccessFlags.java ! src/java.base/share/classes/java/lang/classfile/ClassBuilder.java ! src/java.base/share/classes/java/lang/classfile/FieldBuilder.java ! src/java.base/share/classes/java/lang/classfile/MethodBuilder.java ! src/java.base/share/classes/jdk/internal/classfile/impl/BufferedFieldBuilder.java ! src/java.base/share/classes/jdk/internal/classfile/impl/BufferedMethodBuilder.java ! src/java.base/share/classes/jdk/internal/classfile/impl/ClassImpl.java ! src/java.base/share/classes/jdk/internal/classfile/impl/FieldImpl.java ! src/java.base/share/classes/jdk/internal/classfile/impl/MethodImpl.java ! src/jdk.jdeps/share/classes/com/sun/tools/javap/ClassWriter.java ! test/jdk/jdk/classfile/AccessFlagsTest.java ! test/jdk/jdk/classfile/BuilderBlockTest.java ! test/jdk/jdk/classfile/BuilderTryCatchTest.java ! test/jdk/jdk/classfile/LDCTest.java ! test/jdk/jdk/classfile/LowAdaptTest.java ! test/jdk/jdk/classfile/LvtTest.java ! test/jdk/jdk/classfile/OneToOneTest.java ! test/jdk/jdk/classfile/SwapTest.java ! test/jdk/jdk/classfile/WriteTest.java ! test/jdk/jdk/classfile/examples/ExampleGallery.java ! test/micro/org/openjdk/bench/jdk/classfile/Write.java Changeset: f5c9e8f1 Branch: fibers Author: Sonia Zaldana Calles Date: 2024-07-30 18:40:37 +0000 URL: https://git.openjdk.org/loom/commit/f5c9e8f1229f3aa00743119a2dee3e15d57048d8 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID Reviewed-by: kevinw, stuefe, lmesnik ! src/hotspot/share/code/codeCache.cpp ! src/hotspot/share/code/codeCache.hpp ! src/hotspot/share/prims/wbtestmethods/parserTests.cpp ! src/hotspot/share/services/diagnosticArgument.cpp ! src/hotspot/share/services/diagnosticArgument.hpp ! src/hotspot/share/services/diagnosticCommand.cpp ! test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTestDumpBase.java ! test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTestStaticDump.java ! test/hotspot/jtreg/serviceability/ParserTest.java + test/jdk/sun/tools/jcmd/TestJcmdPIDSubstitution.java ! test/lib/jdk/test/whitebox/parser/DiagnosticCommand.java Changeset: 6c3ba5a6 Branch: fibers Author: Kim Barrett Date: 2024-07-30 21:19:50 +0000 URL: https://git.openjdk.org/loom/commit/6c3ba5a6c47d29908ddaf58582ee8d26bb8779f9 8337415: Remove inappropriate Atomic access in FreeListAllocator Reviewed-by: tschatzl, shade ! src/hotspot/share/gc/shared/freeListAllocator.cpp Changeset: d39e7af2 Branch: fibers Author: David Holmes Date: 2024-07-30 22:35:14 +0000 URL: https://git.openjdk.org/loom/commit/d39e7af2e5d28df43c0b2dad770f41adede5cc29 8320561: Inconsistency in monitorinflation logging Reviewed-by: stefank, shade ! src/hotspot/share/runtime/synchronizer.cpp Changeset: 5b7bb40d Branch: fibers Author: David Holmes Date: 2024-07-30 22:35:28 +0000 URL: https://git.openjdk.org/loom/commit/5b7bb40d1f5a8e1261cc252db2a09b5e4f07e5f0 8325002: Exceptions::fthrow needs to ensure it truncates to a valid utf8 string Reviewed-by: djelinski, stuefe ! src/hotspot/share/utilities/exceptions.cpp ! src/hotspot/share/utilities/utf8.cpp ! src/hotspot/share/utilities/utf8.hpp ! test/hotspot/gtest/utilities/test_utf8.cpp Changeset: 1c6fef8f Branch: fibers Author: David Holmes Date: 2024-07-31 00:58:52 +0000 URL: https://git.openjdk.org/loom/commit/1c6fef8f1cd12b26de9d31799a6516ce4399313f 8337515: JVM_DumpAllStacks is dead code Reviewed-by: kvn ! src/hotspot/share/include/jvm.h ! src/hotspot/share/prims/jvm.cpp Changeset: e63d0165 Branch: fibers Author: Ashutosh Mehra Date: 2024-07-31 01:36:37 +0000 URL: https://git.openjdk.org/loom/commit/e63d01654e0b702b3a8c0c4de97a6bb6893fbd1f 8337031: Improvements to CompilationMemoryStatistic Reviewed-by: kvn, stuefe ! src/hotspot/share/compiler/compilationMemoryStatistic.cpp ! src/hotspot/share/compiler/compilationMemoryStatistic.hpp ! src/hotspot/share/memory/arena.cpp ! src/hotspot/share/memory/arena.hpp ! test/hotspot/jtreg/compiler/print/CompileCommandPrintMemStat.java ! test/hotspot/jtreg/serviceability/dcmd/compiler/CompilerMemoryStatisticTest.java Changeset: f1f0de4f Branch: fibers Author: Alan Bateman Date: 2024-07-31 07:34:18 +0000 URL: https://git.openjdk.org/loom/commit/f1f0de4f3efe04d36eb8ad58b91ff494d5932931 Merge ! src/hotspot/cpu/s390/macroAssembler_s390.cpp ! src/hotspot/share/include/jvm.h ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/method.cpp ! src/hotspot/share/oops/stackChunkOop.cpp ! src/hotspot/share/oops/stackChunkOop.inline.hpp ! src/hotspot/share/prims/jvm.cpp ! src/hotspot/share/runtime/continuationFreezeThaw.cpp ! src/hotspot/share/runtime/javaThread.cpp ! src/hotspot/share/runtime/synchronizer.cpp ! src/hotspot/share/services/diagnosticCommand.cpp ! src/hotspot/share/utilities/globalDefinitions.hpp ! src/hotspot/cpu/s390/macroAssembler_s390.cpp ! src/hotspot/share/include/jvm.h ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/method.cpp ! src/hotspot/share/oops/stackChunkOop.cpp ! src/hotspot/share/oops/stackChunkOop.inline.hpp ! src/hotspot/share/prims/jvm.cpp ! src/hotspot/share/runtime/continuationFreezeThaw.cpp ! src/hotspot/share/runtime/javaThread.cpp ! src/hotspot/share/runtime/synchronizer.cpp ! src/hotspot/share/services/diagnosticCommand.cpp ! src/hotspot/share/utilities/globalDefinitions.hpp Changeset: d3cc3f21 Branch: fibers Author: Alan Bateman Date: 2024-07-31 08:44:40 +0000 URL: https://git.openjdk.org/loom/commit/d3cc3f2109320d04b1f8ec5daeadadc224744b2d Fix post merge build issue ! src/hotspot/share/runtime/continuationFreezeThaw.cpp Changeset: 16610500 Branch: fibers Author: Alan Bateman Date: 2024-07-31 11:55:21 +0000 URL: https://git.openjdk.org/loom/commit/16610500f8ab0c88f60000d2c8807a6ba90ad59a Allow stress tests to run concurrently - test/jdk/java/lang/Thread/virtual/stress/TEST.properties Changeset: 374421cc Branch: fibers Author: Alan Bateman Date: 2024-07-31 11:56:19 +0000 URL: https://git.openjdk.org/loom/commit/374421cc83bc3d9481636cf804aacc543550910c Fix Thread.print help message ! src/hotspot/share/services/diagnosticCommand.hpp Changeset: 83131ae3 Branch: fibers Author: Alan Bateman Date: 2024-07-31 12:10:24 +0000 URL: https://git.openjdk.org/loom/commit/83131ae3ca3d4160eb71c28d6ccae7771207e913 Add supporting class to test locking mode in tests + test/jdk/java/lang/Thread/virtual/LockingMode.java ! test/jdk/java/lang/Thread/virtual/MonitorEnterExit.java ! test/jdk/java/lang/Thread/virtual/MonitorWaitNotify.java ! test/jdk/java/lang/Thread/virtual/MonitorsTest.java ! test/jdk/java/lang/Thread/virtual/Parking.java ! test/jdk/java/lang/Thread/virtual/ThreadAPI.java Changeset: ce669f9e Branch: fibers Author: Alan Bateman Date: 2024-07-31 15:40:04 +0000 URL: https://git.openjdk.org/loom/commit/ce669f9eaf7285d927d6751c4e0df682513c9395 Tests not suited to -Xcomp ! test/jdk/ProblemList-Xcomp.txt ! test/jdk/java/foreign/TestStubAllocFailure.java ! test/jdk/java/lang/reflect/callerCache/ReflectionCallerCacheTest.java Changeset: de0b5040 Branch: fibers Author: Thomas Schatzl Date: 2024-07-31 08:08:15 +0000 URL: https://git.openjdk.org/loom/commit/de0b50400a4155554c83d5c3346ab1ec5353df61 8336912: G1: Undefined behavior for G1ConfidencePercent=0 Reviewed-by: ayang, sangheki ! src/hotspot/share/gc/g1/g1_globals.hpp ! test/hotspot/jtreg/gc/arguments/TestG1PercentageOptions.java Changeset: 9b428dda Branch: fibers Author: David Leopoldseder Committer: Doug Simon Date: 2024-07-31 09:40:47 +0000 URL: https://git.openjdk.org/loom/commit/9b428dda8fb86ed595b05f3c930b3ce9c341db9b 8336242: compiler/jvmci/jdk.vm.ci.code.test/src/jdk/vm/ci/code/test/SimpleDebugInfoTest.java failed assert(oopDesc::is_oop_or_null(val)) failed: bad oop found (again) Reviewed-by: dnsimon, never ! test/hotspot/jtreg/compiler/jvmci/jdk.vm.ci.code.test/src/jdk/vm/ci/code/test/SimpleDebugInfoTest.java Changeset: c73b3cb5 Branch: fibers Author: Aleksey Shipilev Date: 2024-07-31 12:56:43 +0000 URL: https://git.openjdk.org/loom/commit/c73b3cb5996723c5a15c833a9da059b79c99cf9c 8336635: Add IR test for Reference.refersTo intrinsic Reviewed-by: thartmann, kvn + test/hotspot/jtreg/compiler/c2/irTests/gc/ReferenceRefersToTests.java Changeset: 07dd7250 Branch: fibers Author: Kim Barrett Date: 2024-07-31 13:15:52 +0000 URL: https://git.openjdk.org/loom/commit/07dd725025a54035436a76ac4c0a8bb2b12e264a 8337418: Fix -Wzero-as-null-pointer-constant warnings in prims code Reviewed-by: dholmes, shade, jwaters, sspitsyn ! src/hotspot/share/prims/jni.cpp ! src/hotspot/share/prims/jvm.cpp ! src/hotspot/share/prims/jvmtiExport.cpp ! src/hotspot/share/prims/jvmtiTrace.cpp ! src/hotspot/share/prims/methodHandles.cpp ! src/hotspot/share/prims/perf.cpp ! src/hotspot/share/prims/unsafe.cpp Changeset: 61386c19 Branch: fibers Author: Kim Barrett Date: 2024-07-31 13:17:30 +0000 URL: https://git.openjdk.org/loom/commit/61386c199a3b29457c002ad31a23990b7f6f88fd 8337523: Fix -Wzero-as-null-pointer-constant warnings in jvmci code Reviewed-by: chagedorn, shade ! src/hotspot/share/jvmci/jvmciCodeInstaller.cpp ! src/hotspot/share/jvmci/jvmciCompilerToVM.cpp ! src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp ! src/hotspot/share/jvmci/jvmciRuntime.cpp Changeset: 7121d71b Branch: fibers Author: Gui Cao Date: 2024-07-31 14:43:35 +0000 URL: https://git.openjdk.org/loom/commit/7121d71b516b415c7c11e3643731cd32d4057aa6 8337421: RISC-V: client VM build failure after JDK-8335191 Reviewed-by: fyang, mli ! src/hotspot/cpu/riscv/stubGenerator_riscv.cpp ! src/hotspot/cpu/riscv/vm_version_riscv.cpp ! src/hotspot/cpu/riscv/vm_version_riscv.hpp Changeset: 575e902e Branch: fibers Author: Alan Bateman Date: 2024-07-31 15:48:00 +0000 URL: https://git.openjdk.org/loom/commit/575e902eb46efe028ab886698edf86a2aa20eaa9 Merge ! src/hotspot/share/prims/jvm.cpp ! src/hotspot/share/prims/jvmtiExport.cpp ! src/hotspot/share/prims/jvm.cpp ! src/hotspot/share/prims/jvmtiExport.cpp Changeset: 121561d6 Branch: fibers Author: Alan Bateman Date: 2024-07-31 17:47:46 +0000 URL: https://git.openjdk.org/loom/commit/121561d669e6ea9c2559daef713c1736209731a3 Merge From duke at openjdk.org Wed Jul 31 17:29:55 2024 From: duke at openjdk.org (duke) Date: Wed, 31 Jul 2024 17:29:55 GMT Subject: git: openjdk/loom: master: 39 new changesets Message-ID: <2b6f64b6-c1b8-4211-b10b-f1e804a5e496@openjdk.org> Changeset: 2fbdbaca Branch: master Author: Shaojin Wen Committer: Claes Redestad Date: 2024-07-27 22:54:47 +0000 URL: https://git.openjdk.org/loom/commit/2fbdbacad7ad45055a482c764f84da4568383020 8337245: Fix wrong comment of StringConcatHelper Reviewed-by: phh, redestad ! src/java.base/share/classes/java/lang/StringConcatHelper.java Changeset: 90641a60 Branch: master Author: Tobias Hartmann Date: 2024-07-29 05:05:32 +0000 URL: https://git.openjdk.org/loom/commit/90641a601c9385b5e76e1abc5362ace3ab1fff3d 8336095: Use-after-free in Superword leads to memory corruption Reviewed-by: epeter, kvn, rrich ! src/hotspot/share/opto/loopnode.hpp Changeset: 657c0bdd Branch: master Author: Tobias Hartmann Date: 2024-07-29 05:31:10 +0000 URL: https://git.openjdk.org/loom/commit/657c0bddf90b537ac653817571532705a6e3643a 8336999: Verification for resource area allocated data structures in C2 Reviewed-by: chagedorn, kvn ! src/hotspot/share/ci/ciReplay.cpp ! src/hotspot/share/libadt/vectset.cpp ! src/hotspot/share/libadt/vectset.hpp ! src/hotspot/share/memory/allocation.cpp ! src/hotspot/share/memory/allocation.hpp ! src/hotspot/share/opto/block.cpp ! src/hotspot/share/opto/block.hpp ! src/hotspot/share/opto/domgraph.cpp ! src/hotspot/share/opto/loopnode.cpp ! src/hotspot/share/opto/loopnode.hpp ! src/hotspot/share/opto/node.cpp ! src/hotspot/share/opto/node.hpp ! src/hotspot/share/opto/phaseX.cpp ! src/hotspot/share/opto/vector.cpp Changeset: dab2a0b5 Branch: master Author: Thomas Schatzl Date: 2024-07-29 09:10:25 +0000 URL: https://git.openjdk.org/loom/commit/dab2a0b5978cdd3fad693e4c120a84bb64a3ccde 8337222: gc/TestDisableExplicitGC.java fails due to unexpected CodeCache GC Reviewed-by: iwalulya, shade ! test/hotspot/jtreg/gc/TestDisableExplicitGC.java Changeset: db168d9e Branch: master Author: Jan Kratochvil Committer: Yuri Nesterenko Date: 2024-07-29 09:18:56 +0000 URL: https://git.openjdk.org/loom/commit/db168d9e10c4a302b743ee208e24ba7303fec582 8336966: Alpine Linux x86_64 compilation error: sendfile64 Reviewed-by: bpb ! src/java.base/linux/native/libnio/ch/FileDispatcherImpl.c ! src/java.base/linux/native/libnio/fs/LinuxNativeDispatcher.c Changeset: 9124a94e Branch: master Author: Erik Gahlin Date: 2024-07-29 09:52:38 +0000 URL: https://git.openjdk.org/loom/commit/9124a94e383f5bc6a3376eecc97ee8bd22f9e420 8337165: Test jdk/jfr/event/gc/stacktrace/TestG1YoungAllocationPendingStackTrace.java failed: IndexOutOfBoundsException: Index 64 out of bounds for length 64 Reviewed-by: phh ! test/jdk/jdk/jfr/event/gc/stacktrace/TestDefNewAllocationPendingStackTrace.java ! test/jdk/jdk/jfr/event/gc/stacktrace/TestG1HumongousAllocationPendingStackTrace.java ! test/jdk/jdk/jfr/event/gc/stacktrace/TestG1OldAllocationPendingStackTrace.java ! test/jdk/jdk/jfr/event/gc/stacktrace/TestG1YoungAllocationPendingStackTrace.java ! test/jdk/jdk/jfr/event/gc/stacktrace/TestMarkSweepCompactAllocationPendingStackTrace.java ! test/jdk/jdk/jfr/event/gc/stacktrace/TestMetaspaceG1GCAllocationPendingStackTrace.java ! test/jdk/jdk/jfr/event/gc/stacktrace/TestMetaspaceParallelGCAllocationPendingStackTrace.java ! test/jdk/jdk/jfr/event/gc/stacktrace/TestMetaspaceSerialGCAllocationPendingStackTrace.java ! test/jdk/jdk/jfr/event/gc/stacktrace/TestParallelMarkSweepAllocationPendingStackTrace.java ! test/jdk/jdk/jfr/event/gc/stacktrace/TestParallelScavengeAllocationPendingStackTrace.java Changeset: cd52ad80 Branch: master Author: Albert Mingkun Yang Date: 2024-07-29 12:30:57 +0000 URL: https://git.openjdk.org/loom/commit/cd52ad80a82c8165424722dcddd37d6584137031 8337267: [REDO] G1: Refactor G1RebuildRSAndScrubTask Reviewed-by: gli, tschatzl ! src/hotspot/share/gc/g1/g1ConcurrentRebuildAndScrub.cpp Changeset: ee365d75 Branch: master Author: Aleksey Shipilev Date: 2024-07-29 13:37:56 +0000 URL: https://git.openjdk.org/loom/commit/ee365d75cca6f33e5781fe514e557caba2b67c32 8336342: Fix known X11 library locations in sysroot Reviewed-by: jwaters, phh, prr ! make/autoconf/lib-x11.m4 Changeset: c23d37e1 Branch: master Author: Naoto Sato Date: 2024-07-29 16:43:25 +0000 URL: https://git.openjdk.org/loom/commit/c23d37e10a429c0e7248593b07ef1ccdcd34bd1c 8337300: java/lang/Process/WaitForDuration.java leaves child process behind Reviewed-by: alanb, iris, bpb ! test/jdk/java/lang/Process/WaitForDuration.java Changeset: c4e6255a Branch: master Author: Chris Plummer Date: 2024-07-29 16:55:38 +0000 URL: https://git.openjdk.org/loom/commit/c4e6255ac3ec5520c4cb6d0d4ad9013da177ba88 8332738: Debug agent can deadlock on callbackLock when using StackFrame.PopFrames Reviewed-by: sspitsyn, amenkov ! src/jdk.jdwp.agent/share/native/libjdwp/eventHandler.c ! src/jdk.jdwp.agent/share/native/libjdwp/eventHandler.h ! src/jdk.jdwp.agent/share/native/libjdwp/invoker.c ! src/jdk.jdwp.agent/share/native/libjdwp/stepControl.c ! src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c Changeset: a86244f8 Branch: master Author: Archie Cobbs Date: 2024-07-29 19:16:39 +0000 URL: https://git.openjdk.org/loom/commit/a86244f83cc4e234bdf8dc2c8d87640b6aab8463 6381729: Javadoc for generic constructor doesn't document type parameter Reviewed-by: jjg, liach ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractExecutableMemberWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractMemberWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassUseWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ConstructorWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Signatures.java ! test/langtools/jdk/javadoc/doclet/testErasure/TestErasure.java ! test/langtools/jdk/javadoc/doclet/testTypeParams/TestTypeParameters.java = test/langtools/jdk/javadoc/doclet/testTypeParams/pkg/CtorTypeParam.java Changeset: bd36b6ae Branch: master Author: Justin Lu Date: 2024-07-29 19:28:14 +0000 URL: https://git.openjdk.org/loom/commit/bd36b6ae5d0d760670a0bd722878614a6cd553d6 8337285: Examine java.text.DecimalFormat API for api/implXxx tag usage Reviewed-by: naoto, liach ! src/java.base/share/classes/java/text/DecimalFormat.java Changeset: ab27090a Branch: master Author: Chen Liang Date: 2024-07-29 21:58:08 +0000 URL: https://git.openjdk.org/loom/commit/ab27090aa085283233851410827767785b3b7b1f 8337225: Demote maxStack and maxLocals from CodeModel to CodeAttribute Reviewed-by: asotona ! src/java.base/share/classes/java/lang/classfile/CodeModel.java ! src/java.base/share/classes/java/lang/classfile/attribute/CodeAttribute.java ! src/java.base/share/classes/jdk/internal/classfile/impl/AbstractUnboundModel.java ! src/java.base/share/classes/jdk/internal/classfile/impl/BufferedCodeBuilder.java ! src/java.base/share/classes/jdk/internal/classfile/impl/BufferedFieldBuilder.java ! src/java.base/share/classes/jdk/internal/classfile/impl/BufferedMethodBuilder.java ! src/java.base/share/classes/jdk/internal/classfile/impl/CodeImpl.java ! src/java.base/share/classes/jdk/internal/classfile/impl/DirectCodeBuilder.java ! src/java.base/share/classes/jdk/internal/classfile/impl/TerminalCodeBuilder.java ! test/jdk/jdk/classfile/BuilderBlockTest.java ! test/jdk/jdk/classfile/CorpusTest.java ! test/jdk/jdk/classfile/DiscontinuedInstructionsTest.java ! test/jdk/jdk/classfile/StackMapsTest.java Changeset: 7e21d4c1 Branch: master Author: Prasanta Sadhukhan Date: 2024-07-30 03:03:43 +0000 URL: https://git.openjdk.org/loom/commit/7e21d4c1916d6690b717911179314c26a0da5ed9 8337268: Redundant Math.ceil in StyleSheet.ListPainter#drawShape Reviewed-by: prr, aivanov ! src/java.desktop/share/classes/javax/swing/text/html/StyleSheet.java Changeset: bc7c255b Branch: master Author: Kim Barrett Date: 2024-07-30 07:24:22 +0000 URL: https://git.openjdk.org/loom/commit/bc7c255b156bf3bb3fd8c3f622b8127ab27e7c7a 8337416: Fix -Wzero-as-null-pointer-constant warnings in misc. runtime code Reviewed-by: dholmes, jwaters ! src/hotspot/share/logging/logConfiguration.cpp ! src/hotspot/share/memory/metaspace/metachunk.cpp ! src/hotspot/share/memory/metaspace/rootChunkArea.cpp ! src/hotspot/share/memory/virtualspace.cpp ! src/hotspot/share/oops/constantPool.cpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/method.cpp ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/javaThread.cpp ! src/hotspot/share/runtime/vframeArray.cpp Changeset: 9e6e0a8f Branch: master Author: Aleksey Shipilev Date: 2024-07-30 08:27:27 +0000 URL: https://git.openjdk.org/loom/commit/9e6e0a8f341389215f0db6b2260f2b16351f02be 8336343: Add more known sysroot library locations for ALSA Reviewed-by: phh, prr, ihse ! make/autoconf/lib-alsa.m4 Changeset: 156f0b43 Branch: master Author: Aleksey Shipilev Date: 2024-07-30 08:29:23 +0000 URL: https://git.openjdk.org/loom/commit/156f0b4332bf076165898417cf6678d2fc32df5c 8337213: Shenandoah: Add verification for class mirrors Reviewed-by: rkennke, wkemper ! src/hotspot/share/gc/shenandoah/shenandoahAsserts.cpp ! src/hotspot/share/gc/shenandoah/shenandoahVerifier.cpp Changeset: 7ac53118 Branch: master Author: Amit Kumar Date: 2024-07-30 09:32:27 +0000 URL: https://git.openjdk.org/loom/commit/7ac531181c25815577ba2f6f426e1da270e4f589 8331126: [s390x] secondary_super_cache does not scale well Reviewed-by: lucy, aph, mdoerr ! src/hotspot/cpu/s390/macroAssembler_s390.cpp ! src/hotspot/cpu/s390/macroAssembler_s390.hpp ! src/hotspot/cpu/s390/s390.ad ! src/hotspot/cpu/s390/stubGenerator_s390.cpp ! src/hotspot/cpu/s390/vm_version_s390.cpp ! src/hotspot/cpu/s390/vm_version_s390.hpp Changeset: 0325ab8d Branch: master Author: Kevin Walls Date: 2024-07-30 10:44:31 +0000 URL: https://git.openjdk.org/loom/commit/0325ab8d2353f29ac40ff4b028cbc29bff40c59b 8335610: DiagnosticFramework: CmdLine::is_executable() correction Reviewed-by: dholmes, jsjolen ! src/hotspot/share/services/diagnosticFramework.hpp Changeset: 81628328 Branch: master Author: Matthias Baesken Date: 2024-07-30 12:40:35 +0000 URL: https://git.openjdk.org/loom/commit/8162832832ac6e8c17f942e718e309a3489e0da6 8333354: ubsan: frame.inline.hpp:91:25: and src/hotspot/share/runtime/frame.inline.hpp:88:29: runtime error: member call on null pointer of type 'const struct SmallRegisterMap' Co-authored-by: Kim Barrett Reviewed-by: rrich, clanger ! src/hotspot/cpu/aarch64/smallRegisterMap_aarch64.inline.hpp ! src/hotspot/cpu/arm/smallRegisterMap_arm.inline.hpp ! src/hotspot/cpu/ppc/smallRegisterMap_ppc.inline.hpp ! src/hotspot/cpu/riscv/smallRegisterMap_riscv.inline.hpp ! src/hotspot/cpu/s390/smallRegisterMap_s390.inline.hpp ! src/hotspot/cpu/x86/smallRegisterMap_x86.inline.hpp ! src/hotspot/cpu/zero/smallRegisterMap_zero.inline.hpp ! src/hotspot/share/oops/stackChunkOop.cpp ! src/hotspot/share/oops/stackChunkOop.inline.hpp ! src/hotspot/share/runtime/continuationFreezeThaw.cpp Changeset: 79bdd811 Branch: master Author: Albert Mingkun Yang Date: 2024-07-30 13:38:11 +0000 URL: https://git.openjdk.org/loom/commit/79bdd811876d75974536aac088bae1719387c97f 8336763: Parallel: Merge PCMarkAndPushClosure and PCIterateMarkAndPushClosure Reviewed-by: gli, zgu ! src/hotspot/share/gc/parallel/psCompactionManager.cpp ! src/hotspot/share/gc/parallel/psCompactionManager.hpp ! src/hotspot/share/gc/parallel/psCompactionManager.inline.hpp ! src/hotspot/share/gc/parallel/psParallelCompact.cpp Changeset: 41486131 Branch: master Author: Erik Gahlin Date: 2024-07-30 13:47:58 +0000 URL: https://git.openjdk.org/loom/commit/41486131481164a559aa534807fe1a77a7d29fc8 8335907: JFR: Make SettingControls more robust Reviewed-by: mgronlun ! src/jdk.jfr/share/classes/jdk/jfr/internal/EventControl.java + src/jdk.jfr/share/classes/jdk/jfr/internal/settings/BooleanSetting.java - src/jdk.jfr/share/classes/jdk/jfr/internal/settings/BooleanValue.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/settings/CutoffSetting.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/settings/EnabledSetting.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/settings/LevelSetting.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/settings/PeriodSetting.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/settings/StackTraceSetting.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/settings/ThresholdSetting.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/settings/ThrottleSetting.java - src/jdk.jfr/share/classes/jdk/jfr/internal/settings/ThrottleUnit.java + src/jdk.jfr/share/classes/jdk/jfr/internal/util/Rate.java + src/jdk.jfr/share/classes/jdk/jfr/internal/util/TimespanUnit.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/util/Utils.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/util/ValueFormatter.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/util/ValueParser.java + test/jdk/jdk/jfr/api/settings/TestSettingControl.java Changeset: 1cb27f7e Branch: master Author: Neethu Prasad Date: 2024-07-30 14:08:17 +0000 URL: https://git.openjdk.org/loom/commit/1cb27f7e2355ccb911bb274fc004e5bc57fd5dc9 8334230: Optimize C2 classes layout Reviewed-by: shade, kvn, thartmann ! src/hotspot/share/gc/shared/c2/barrierSetC2.hpp ! src/hotspot/share/libadt/vectset.hpp ! src/hotspot/share/opto/callnode.hpp ! src/hotspot/share/opto/memnode.cpp Changeset: 2c9fd901 Branch: master Author: Vanitha B P Committer: Alexey Semenyuk Date: 2024-07-30 15:04:57 +0000 URL: https://git.openjdk.org/loom/commit/2c9fd9016f4675448a62380ff2b86533020e690f 8336315: tools/jpackage/windows/WinChildProcessTest.java Failed: Check is calculator process is alive Reviewed-by: asemenyuk, almatvee ! test/jdk/tools/jpackage/apps/ChildProcessAppLauncher.java ! test/jdk/tools/jpackage/windows/WinChildProcessTest.java Changeset: a91f9ba8 Branch: master Author: Gerard Ziemski Date: 2024-07-30 15:22:25 +0000 URL: https://git.openjdk.org/loom/commit/a91f9ba84906dae10b050e15307ba0f0f05af3e4 8301403: Eliminate memory allocations in JVMFlag::printFlags during signal handling Reviewed-by: stuefe, jsjolen, dholmes ! src/hotspot/share/runtime/flags/jvmFlag.cpp ! src/hotspot/share/utilities/bitMap.cpp ! src/hotspot/share/utilities/bitMap.hpp ! src/hotspot/share/utilities/globalDefinitions.hpp Changeset: 6154a212 Branch: master Author: Chen Liang Date: 2024-07-30 17:41:38 +0000 URL: https://git.openjdk.org/loom/commit/6154a2129ba505b7163a1998792296827a056750 8336032: Enforce immutability of Lists used by ClassFile API Reviewed-by: asotona ! src/java.base/share/classes/java/lang/classfile/AttributedElement.java ! src/java.base/share/classes/java/lang/classfile/ClassSignature.java ! src/java.base/share/classes/java/lang/classfile/CompoundElement.java ! src/java.base/share/classes/jdk/internal/classfile/impl/AbstractUnboundModel.java ! src/java.base/share/classes/jdk/internal/classfile/impl/BoundAttribute.java ! src/java.base/share/classes/jdk/internal/classfile/impl/BufferedCodeBuilder.java ! src/java.base/share/classes/jdk/internal/classfile/impl/BufferedFieldBuilder.java ! src/java.base/share/classes/jdk/internal/classfile/impl/BufferedMethodBuilder.java ! src/java.base/share/classes/jdk/internal/classfile/impl/StackMapDecoder.java ! src/java.base/share/classes/jdk/internal/classfile/impl/UnboundAttribute.java ! src/java.base/share/classes/jdk/internal/classfile/impl/verifier/VerifierImpl.java Changeset: 93c19ac7 Branch: master Author: Chen Liang Date: 2024-07-30 17:41:49 +0000 URL: https://git.openjdk.org/loom/commit/93c19ac73c2feb8d6191bc5da98b4a9c8e2b5590 8337219: AccessFlags factories do not require necessary arguments Reviewed-by: asotona ! src/java.base/share/classes/java/lang/classfile/AccessFlags.java ! src/java.base/share/classes/java/lang/classfile/ClassBuilder.java ! src/java.base/share/classes/java/lang/classfile/FieldBuilder.java ! src/java.base/share/classes/java/lang/classfile/MethodBuilder.java ! src/java.base/share/classes/jdk/internal/classfile/impl/BufferedFieldBuilder.java ! src/java.base/share/classes/jdk/internal/classfile/impl/BufferedMethodBuilder.java ! src/java.base/share/classes/jdk/internal/classfile/impl/ClassImpl.java ! src/java.base/share/classes/jdk/internal/classfile/impl/FieldImpl.java ! src/java.base/share/classes/jdk/internal/classfile/impl/MethodImpl.java ! src/jdk.jdeps/share/classes/com/sun/tools/javap/ClassWriter.java ! test/jdk/jdk/classfile/AccessFlagsTest.java ! test/jdk/jdk/classfile/BuilderBlockTest.java ! test/jdk/jdk/classfile/BuilderTryCatchTest.java ! test/jdk/jdk/classfile/LDCTest.java ! test/jdk/jdk/classfile/LowAdaptTest.java ! test/jdk/jdk/classfile/LvtTest.java ! test/jdk/jdk/classfile/OneToOneTest.java ! test/jdk/jdk/classfile/SwapTest.java ! test/jdk/jdk/classfile/WriteTest.java ! test/jdk/jdk/classfile/examples/ExampleGallery.java ! test/micro/org/openjdk/bench/jdk/classfile/Write.java Changeset: f5c9e8f1 Branch: master Author: Sonia Zaldana Calles Date: 2024-07-30 18:40:37 +0000 URL: https://git.openjdk.org/loom/commit/f5c9e8f1229f3aa00743119a2dee3e15d57048d8 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID Reviewed-by: kevinw, stuefe, lmesnik ! src/hotspot/share/code/codeCache.cpp ! src/hotspot/share/code/codeCache.hpp ! src/hotspot/share/prims/wbtestmethods/parserTests.cpp ! src/hotspot/share/services/diagnosticArgument.cpp ! src/hotspot/share/services/diagnosticArgument.hpp ! src/hotspot/share/services/diagnosticCommand.cpp ! test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTestDumpBase.java ! test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTestStaticDump.java ! test/hotspot/jtreg/serviceability/ParserTest.java + test/jdk/sun/tools/jcmd/TestJcmdPIDSubstitution.java ! test/lib/jdk/test/whitebox/parser/DiagnosticCommand.java Changeset: 6c3ba5a6 Branch: master Author: Kim Barrett Date: 2024-07-30 21:19:50 +0000 URL: https://git.openjdk.org/loom/commit/6c3ba5a6c47d29908ddaf58582ee8d26bb8779f9 8337415: Remove inappropriate Atomic access in FreeListAllocator Reviewed-by: tschatzl, shade ! src/hotspot/share/gc/shared/freeListAllocator.cpp Changeset: d39e7af2 Branch: master Author: David Holmes Date: 2024-07-30 22:35:14 +0000 URL: https://git.openjdk.org/loom/commit/d39e7af2e5d28df43c0b2dad770f41adede5cc29 8320561: Inconsistency in monitorinflation logging Reviewed-by: stefank, shade ! src/hotspot/share/runtime/synchronizer.cpp Changeset: 5b7bb40d Branch: master Author: David Holmes Date: 2024-07-30 22:35:28 +0000 URL: https://git.openjdk.org/loom/commit/5b7bb40d1f5a8e1261cc252db2a09b5e4f07e5f0 8325002: Exceptions::fthrow needs to ensure it truncates to a valid utf8 string Reviewed-by: djelinski, stuefe ! src/hotspot/share/utilities/exceptions.cpp ! src/hotspot/share/utilities/utf8.cpp ! src/hotspot/share/utilities/utf8.hpp ! test/hotspot/gtest/utilities/test_utf8.cpp Changeset: 1c6fef8f Branch: master Author: David Holmes Date: 2024-07-31 00:58:52 +0000 URL: https://git.openjdk.org/loom/commit/1c6fef8f1cd12b26de9d31799a6516ce4399313f 8337515: JVM_DumpAllStacks is dead code Reviewed-by: kvn ! src/hotspot/share/include/jvm.h ! src/hotspot/share/prims/jvm.cpp Changeset: e63d0165 Branch: master Author: Ashutosh Mehra Date: 2024-07-31 01:36:37 +0000 URL: https://git.openjdk.org/loom/commit/e63d01654e0b702b3a8c0c4de97a6bb6893fbd1f 8337031: Improvements to CompilationMemoryStatistic Reviewed-by: kvn, stuefe ! src/hotspot/share/compiler/compilationMemoryStatistic.cpp ! src/hotspot/share/compiler/compilationMemoryStatistic.hpp ! src/hotspot/share/memory/arena.cpp ! src/hotspot/share/memory/arena.hpp ! test/hotspot/jtreg/compiler/print/CompileCommandPrintMemStat.java ! test/hotspot/jtreg/serviceability/dcmd/compiler/CompilerMemoryStatisticTest.java Changeset: de0b5040 Branch: master Author: Thomas Schatzl Date: 2024-07-31 08:08:15 +0000 URL: https://git.openjdk.org/loom/commit/de0b50400a4155554c83d5c3346ab1ec5353df61 8336912: G1: Undefined behavior for G1ConfidencePercent=0 Reviewed-by: ayang, sangheki ! src/hotspot/share/gc/g1/g1_globals.hpp ! test/hotspot/jtreg/gc/arguments/TestG1PercentageOptions.java Changeset: 9b428dda Branch: master Author: David Leopoldseder Committer: Doug Simon Date: 2024-07-31 09:40:47 +0000 URL: https://git.openjdk.org/loom/commit/9b428dda8fb86ed595b05f3c930b3ce9c341db9b 8336242: compiler/jvmci/jdk.vm.ci.code.test/src/jdk/vm/ci/code/test/SimpleDebugInfoTest.java failed assert(oopDesc::is_oop_or_null(val)) failed: bad oop found (again) Reviewed-by: dnsimon, never ! test/hotspot/jtreg/compiler/jvmci/jdk.vm.ci.code.test/src/jdk/vm/ci/code/test/SimpleDebugInfoTest.java Changeset: c73b3cb5 Branch: master Author: Aleksey Shipilev Date: 2024-07-31 12:56:43 +0000 URL: https://git.openjdk.org/loom/commit/c73b3cb5996723c5a15c833a9da059b79c99cf9c 8336635: Add IR test for Reference.refersTo intrinsic Reviewed-by: thartmann, kvn + test/hotspot/jtreg/compiler/c2/irTests/gc/ReferenceRefersToTests.java Changeset: 07dd7250 Branch: master Author: Kim Barrett Date: 2024-07-31 13:15:52 +0000 URL: https://git.openjdk.org/loom/commit/07dd725025a54035436a76ac4c0a8bb2b12e264a 8337418: Fix -Wzero-as-null-pointer-constant warnings in prims code Reviewed-by: dholmes, shade, jwaters, sspitsyn ! src/hotspot/share/prims/jni.cpp ! src/hotspot/share/prims/jvm.cpp ! src/hotspot/share/prims/jvmtiExport.cpp ! src/hotspot/share/prims/jvmtiTrace.cpp ! src/hotspot/share/prims/methodHandles.cpp ! src/hotspot/share/prims/perf.cpp ! src/hotspot/share/prims/unsafe.cpp Changeset: 61386c19 Branch: master Author: Kim Barrett Date: 2024-07-31 13:17:30 +0000 URL: https://git.openjdk.org/loom/commit/61386c199a3b29457c002ad31a23990b7f6f88fd 8337523: Fix -Wzero-as-null-pointer-constant warnings in jvmci code Reviewed-by: chagedorn, shade ! src/hotspot/share/jvmci/jvmciCodeInstaller.cpp ! src/hotspot/share/jvmci/jvmciCompilerToVM.cpp ! src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp ! src/hotspot/share/jvmci/jvmciRuntime.cpp Changeset: 7121d71b Branch: master Author: Gui Cao Date: 2024-07-31 14:43:35 +0000 URL: https://git.openjdk.org/loom/commit/7121d71b516b415c7c11e3643731cd32d4057aa6 8337421: RISC-V: client VM build failure after JDK-8335191 Reviewed-by: fyang, mli ! src/hotspot/cpu/riscv/stubGenerator_riscv.cpp ! src/hotspot/cpu/riscv/vm_version_riscv.cpp ! src/hotspot/cpu/riscv/vm_version_riscv.hpp From robaho at icloud.com Wed Jul 31 17:51:31 2024 From: robaho at icloud.com (robert engels) Date: Wed, 31 Jul 2024 12:51:31 -0500 Subject: [External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: References: Message-ID: <500C56F5-3A88-463A-88B1-65B24A590009@icloud.com> An HTML attachment was scrubbed... URL: From pedro.lamarao at prodist.com.br Wed Jul 31 18:01:07 2024 From: pedro.lamarao at prodist.com.br (=?UTF-8?Q?Pedro_Lamar=C3=A3o?=) Date: Wed, 31 Jul 2024 15:01:07 -0300 Subject: [External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: <500C56F5-3A88-463A-88B1-65B24A590009@icloud.com> References: <500C56F5-3A88-463A-88B1-65B24A590009@icloud.com> Message-ID: Certainly it would be incorrect to execute the finally block after reclaiming a. But the finally block, in this case, will never, ever, run. Therefore, the machine will never, ever, execute the finally block after reclaiming a. No execution ordering mistake can be made by the machine here. That this whole situation is undesirable seems to be a particular case of the general undesirability of deadlocks. Unfortunately, in the machine under consideration, threads are allowed to deadlock -- both "platform" and "virtual". Since it is out of question to require that deadlocks be impossible, one must accept that the finally block may not execute, and etc. etc. Em qua., 31 de jul. de 2024 ?s 14:52, robert engels escreveu: > Right but then you can?t reclaim ?a? especially with a finalizer but even > then it will break all sorts of things even when it doesn?t. > > On Jul 31, 2024, at 12:25?PM, Pedro Lamar?o > wrote: > > ? > In the situation being considered, the finally block will never, ever, run. > What is the meaning of requiring that this effect be ordered before or > after some point in time? > Effects that will never, ever, happen, have no place in time to be ordered > here or there. > The machine cannot fail to properly order an effect that will never, ever, > happen. > > Em qua., 31 de jul. de 2024 ?s 14:16, robert engels > escreveu: > >> More specifically, it is that ?a? cannot be reclaimed and the finally not >> run. This breaks the program ordering guarantees as related to >> retainability. >> >> On Jul 31, 2024, at 11:59?AM, Pedro Lamar?o >> wrote: >> >> ? >> This seems to me a simple contradiction of requirements. >> One cannot require that this program behaves as stated, that this thread >> cannot proceed, and then require that the finally block runs. >> Either the thread can proceed, or it cannot. >> If it cannot, requiring that this thread runs code is nonsensical to me. >> Perhaps one should just revise one's queue design and/or implementation >> to avoid becoming "impossible" instead. >> The fact the queue in question allows for "zombie platform thread" does >> not seem a feature to me. >> "zombie platform threads" is just a resource leak in a system with no >> automatic resource reclamation. >> >> > -- > Pedro Lamar?o > > -- Pedro Lamar?o -------------- next part -------------- An HTML attachment was scrubbed... URL: From robaho at icloud.com Wed Jul 31 18:05:43 2024 From: robaho at icloud.com (robert engels) Date: Wed, 31 Jul 2024 13:05:43 -0500 Subject: [External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From outsider404 at gmail.com Wed Jul 31 18:19:52 2024 From: outsider404 at gmail.com (Michal Domagala) Date: Wed, 31 Jul 2024 20:19:52 +0200 Subject: [External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: <370F3502-38BE-4775-87B6-8472050F067E@icloud.com> References: <370F3502-38BE-4775-87B6-8472050F067E@icloud.com> Message-ID: Documentation says: "The finally block always executes when the try block exits" Not "The finally block always executes" I think there are 3 areas to seek an answer about correct VT behavior. First is general, "sky-level" rules. GC rule says that "what is unreferenced and is not GC root, is collectable". The rule says that VT should be collectable, but many may contest that the rule - as very generic - is not applicable for blocked VT. But the rule works: blocked VT is successfully GC-able, if only observability is off. Second is habits. I agree that there is a habit that "finally block" is always executed. But maybe it is just a habit? I think VT GC case in something fresh and cannot be matched to existing experience, but if do "kill -s SIGTERM", which is more cooperative than SIGKILL or unplug power, "finally block" is not executed Third is common sense. If something is unreachable, better reclaim resources and pray it works than have a memory leak and countdown to OOM. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robaho at icloud.com Wed Jul 31 20:05:42 2024 From: robaho at icloud.com (robert engels) Date: Wed, 31 Jul 2024 15:05:42 -0500 Subject: [External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: References: Message-ID: This analysis is incorrect. The guarantees about program order say that ?a? must be alive OR the finally block must execute. There is no gray area here. This MUST hold. You don?t even need to references GC roots - the specification considers reachability from instance of Thread. A VirtualThread extends Thread so proper OO means it must act as a Thread for all behaviors of Thread. > On Jul 31, 2024, at 1:29?PM, Michal Domagala wrote: > > ? > Documentation says: "The finally block always executes when the try block exits" > Not "The finally block always executes" > > I think there are 3 areas to seek an answer about correct VT behavior. > > First is general, "sky-level" rules. GC rule says that "what is unreferenced and is not GC root, is collectable". The rule says that VT should be collectable, but many may contest that the rule - as very generic - is not applicable for blocked VT. But the rule works: blocked VT is successfully GC-able, if only observability is off. > > Second is habits. I agree that there is a habit that "finally block" is always executed. But maybe it is just a habit? I think VT GC case in something fresh and cannot be matched to existing experience, but if do "kill -s SIGTERM", which is more cooperative than SIGKILL or unplug power, "finally block" is not executed > > Third is common sense. If something is unreachable, better reclaim resources and pray it works than have a memory leak and countdown to OOM. -------------- next part -------------- An HTML attachment was scrubbed... URL: From oleksandr.otenko at gmail.com Wed Jul 31 21:22:25 2024 From: oleksandr.otenko at gmail.com (Alex Otenko) Date: Wed, 31 Jul 2024 22:22:25 +0100 Subject: [External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: References: Message-ID: I think your observation about finalizers is important. But without finalizers - how do you detect that the object is not alive? More broadly - it is not the object that matters; the code must behave like if the object were alive. (Think of unwrapped Optionals and Integers) On Wed, 31 Jul 2024, 22:03 robert engels, wrote: > This analysis is incorrect. The guarantees about program order say that > ?a? must be alive OR the finally block must execute. There is no gray area > here. This MUST hold. > > You don?t even need to references GC roots - the specification considers > reachability from instance of Thread. A VirtualThread extends Thread so > proper OO means it must act as a Thread for all behaviors of Thread. > > On Jul 31, 2024, at 1:29?PM, Michal Domagala > wrote: > > ? > Documentation says: "The finally block always executes when the try block > exits" > Not "The finally block always executes" > > I think there are 3 areas to seek an answer about correct VT behavior. > > First is general, "sky-level" rules. GC rule says that "what is > unreferenced and is not GC root, is collectable". The rule says that VT > should be collectable, but many may contest that the rule - as very generic > - is not applicable for blocked VT. But the rule works: blocked VT is > successfully GC-able, if only observability is off. > > Second is habits. I agree that there is a habit that "finally block" is > always executed. But maybe it is just a habit? I think VT GC case in > something fresh and cannot be matched to existing experience, but if do > "kill -s SIGTERM", which is more cooperative than SIGKILL or unplug power, > "finally block" is not executed > > Third is common sense. If something is unreachable, better reclaim > resources and pray it works than have a memory leak and countdown to OOM. > >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From robaho at icloud.com Wed Jul 31 21:58:16 2024 From: robaho at icloud.com (robert engels) Date: Wed, 31 Jul 2024 16:58:16 -0500 Subject: [External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From robaho at icloud.com Wed Jul 31 22:03:28 2024 From: robaho at icloud.com (robert engels) Date: Wed, 31 Jul 2024 17:03:28 -0500 Subject: [External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From outsider404 at gmail.com Wed Jul 31 22:17:52 2024 From: outsider404 at gmail.com (Michal Domagala) Date: Thu, 1 Aug 2024 00:17:52 +0200 Subject: [External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: References: Message-ID: > > > This analysis is incorrect. The guarantees about program order say that > ?a? must be alive OR the finally block must execute. There is no gray area > here. This MUST hold. > > Robert, could you point out the documentation you cited? I tried to find myself, but I found only the following in JLS: A *reachable* object is any object that can be accessed in any potential continuing computation from any live thread. It means that 'a' is not reachable - but how does it match to being alive? -------------- next part -------------- An HTML attachment was scrubbed... URL: From oleksandr.otenko at gmail.com Wed Jul 31 22:22:52 2024 From: oleksandr.otenko at gmail.com (Alex Otenko) Date: Wed, 31 Jul 2024 23:22:52 +0100 Subject: [External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: References: Message-ID: I think you may need to revisit heap dump format. It is all best effort to capture JVM state, not actual state, and not true memory representation. Like, the pointers are 64 bit, even if compressed oops are in use, ... I've seen heap dumps with missing stack traces and missing GC roots. So, no, I don't think we should worry too much about objects that get optimised away. Side-effecting finalizers bug me. But if you can reclaim memory without executing them, I think it may be fine. After all, that's the behaviour of the program where the object is still alive. On Wed, 31 Jul 2024, 23:03 robert engels, wrote: > As a follow-up, even if the heap dump could show the A instance - what > about inspection of its fields? Or if you trace its back references what is > its root? > > A virtual thread may not be a GC root, but it?s stack data has to be or > every monitoring/analysis technique is broken - and systems will be > impossible to audit. > > > On Jul 31, 2024, at 4:59?PM, robert engels wrote: > > ? > Yes, but it?s a graph, because if A doesn?t have a finalizer but > references something that does you face the same problem. > > I think it will. R very hard to profile / debug applications if this were > to come to pass. So I open a profiler and expect to see and instance of A > but I don?t, and I don?t see any log message (assume finally block printed > something) - am I just suppose to assume? well it was a virtual thread and > it ?vanished? because it couldn?t make progress. > > That is ludicrous imo. And also completely unnecessary and against 20 plus > years of Java design. > > On Jul 31, 2024, at 4:23?PM, Alex Otenko > wrote: > > ? > > I think your observation about finalizers is important. But without > finalizers - how do you detect that the object is not alive? > > More broadly - it is not the object that matters; the code must behave > like if the object were alive. (Think of unwrapped Optionals and Integers) > > On Wed, 31 Jul 2024, 22:03 robert engels, wrote: > >> This analysis is incorrect. The guarantees about program order say that >> ?a? must be alive OR the finally block must execute. There is no gray area >> here. This MUST hold. >> >> You don?t even need to references GC roots - the specification considers >> reachability from instance of Thread. A VirtualThread extends Thread so >> proper OO means it must act as a Thread for all behaviors of Thread. >> >> On Jul 31, 2024, at 1:29?PM, Michal Domagala >> wrote: >> >> ? >> Documentation says: "The finally block always executes when the try block >> exits" >> Not "The finally block always executes" >> >> I think there are 3 areas to seek an answer about correct VT behavior. >> >> First is general, "sky-level" rules. GC rule says that "what is >> unreferenced and is not GC root, is collectable". The rule says that VT >> should be collectable, but many may contest that the rule - as very generic >> - is not applicable for blocked VT. But the rule works: blocked VT is >> successfully GC-able, if only observability is off. >> >> Second is habits. I agree that there is a habit that "finally block" is >> always executed. But maybe it is just a habit? I think VT GC case in >> something fresh and cannot be matched to existing experience, but if do >> "kill -s SIGTERM", which is more cooperative than SIGKILL or unplug power, >> "finally block" is not executed >> >> Third is common sense. If something is unreachable, better reclaim >> resources and pray it works than have a memory leak and countdown to OOM. >> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From oleksandr.otenko at gmail.com Wed Jul 31 22:26:51 2024 From: oleksandr.otenko at gmail.com (Alex Otenko) Date: Wed, 31 Jul 2024 23:26:51 +0100 Subject: [External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: References: Message-ID: Like, imagine it is not GCed, but swapped out to /dev/null. Eh? What's the problem with that? We'll swap it back in, when the VT can continue. Deal? :) On Wed, 31 Jul 2024, 23:22 Alex Otenko, wrote: > I think you may need to revisit heap dump format. It is all best effort to > capture JVM state, not actual state, and not true memory representation. > Like, the pointers are 64 bit, even if compressed oops are in use, ... > > I've seen heap dumps with missing stack traces and missing GC roots. So, > no, I don't think we should worry too much about objects that get optimised > away. > > Side-effecting finalizers bug me. But if you can reclaim memory without > executing them, I think it may be fine. After all, that's the behaviour of > the program where the object is still alive. > > On Wed, 31 Jul 2024, 23:03 robert engels, wrote: > >> As a follow-up, even if the heap dump could show the A instance - what >> about inspection of its fields? Or if you trace its back references what is >> its root? >> >> A virtual thread may not be a GC root, but it?s stack data has to be or >> every monitoring/analysis technique is broken - and systems will be >> impossible to audit. >> >> >> On Jul 31, 2024, at 4:59?PM, robert engels wrote: >> >> ? >> Yes, but it?s a graph, because if A doesn?t have a finalizer but >> references something that does you face the same problem. >> >> I think it will. R very hard to profile / debug applications if this were >> to come to pass. So I open a profiler and expect to see and instance of A >> but I don?t, and I don?t see any log message (assume finally block printed >> something) - am I just suppose to assume? well it was a virtual thread and >> it ?vanished? because it couldn?t make progress. >> >> That is ludicrous imo. And also completely unnecessary and against 20 >> plus years of Java design. >> >> On Jul 31, 2024, at 4:23?PM, Alex Otenko >> wrote: >> >> ? >> >> I think your observation about finalizers is important. But without >> finalizers - how do you detect that the object is not alive? >> >> More broadly - it is not the object that matters; the code must behave >> like if the object were alive. (Think of unwrapped Optionals and Integers) >> >> On Wed, 31 Jul 2024, 22:03 robert engels, wrote: >> >>> This analysis is incorrect. The guarantees about program order say that >>> ?a? must be alive OR the finally block must execute. There is no gray area >>> here. This MUST hold. >>> >>> You don?t even need to references GC roots - the specification considers >>> reachability from instance of Thread. A VirtualThread extends Thread so >>> proper OO means it must act as a Thread for all behaviors of Thread. >>> >>> On Jul 31, 2024, at 1:29?PM, Michal Domagala >>> wrote: >>> >>> ? >>> Documentation says: "The finally block always executes when the try >>> block exits" >>> Not "The finally block always executes" >>> >>> I think there are 3 areas to seek an answer about correct VT behavior. >>> >>> First is general, "sky-level" rules. GC rule says that "what is >>> unreferenced and is not GC root, is collectable". The rule says that VT >>> should be collectable, but many may contest that the rule - as very generic >>> - is not applicable for blocked VT. But the rule works: blocked VT is >>> successfully GC-able, if only observability is off. >>> >>> Second is habits. I agree that there is a habit that "finally block" is >>> always executed. But maybe it is just a habit? I think VT GC case in >>> something fresh and cannot be matched to existing experience, but if do >>> "kill -s SIGTERM", which is more cooperative than SIGKILL or unplug power, >>> "finally block" is not executed >>> >>> Third is common sense. If something is unreachable, better reclaim >>> resources and pray it works than have a memory leak and countdown to OOM. >>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From robaho at icloud.com Wed Jul 31 22:58:48 2024 From: robaho at icloud.com (robert engels) Date: Wed, 31 Jul 2024 17:58:48 -0500 Subject: [External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From oleksandr.otenko at gmail.com Wed Jul 31 23:03:54 2024 From: oleksandr.otenko at gmail.com (Alex Otenko) Date: Thu, 1 Aug 2024 00:03:54 +0100 Subject: [External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: References: Message-ID: I don't see objects missing from a heap dump as a problem. I don't think there is any guarantee about that in the JVM spec. In fact, there is no requirement to provide any heap dump. Is there?.. So it really is just about the finalizers being executed or not. I actually think not executing them is better (no guarantees of when they should be executed, is there?), but maybe there are good reasons to get them executed. On Wed, 31 Jul 2024, 23:59 robert engels, wrote: > The program order - except in a case of abrupt termination - must hold. So > having A not be present in a heap dump with the finally block never being > executed is a problem. It is breaking the specification on reachability. > > So change the spec but then you have different behavior if a platform > thread is executing the code versus a virtual thread - which would be > another nightmare for readability and auditing. > > I am honestly baffled how this has proceeded so far without someone from > the loom team saying - you?re right this would be crazy to do. > > It has if people are writing systems code with no concern for the > application code sitting on top. > > On Jul 31, 2024, at 5:28?PM, Alex Otenko > wrote: > > ? > > Like, imagine it is not GCed, but swapped out to /dev/null. Eh? What's the > problem with that? We'll swap it back in, when the VT can continue. Deal? :) > > On Wed, 31 Jul 2024, 23:22 Alex Otenko, > wrote: > >> I think you may need to revisit heap dump format. It is all best effort >> to capture JVM state, not actual state, and not true memory representation. >> Like, the pointers are 64 bit, even if compressed oops are in use, ... >> >> I've seen heap dumps with missing stack traces and missing GC roots. So, >> no, I don't think we should worry too much about objects that get optimised >> away. >> >> Side-effecting finalizers bug me. But if you can reclaim memory without >> executing them, I think it may be fine. After all, that's the behaviour of >> the program where the object is still alive. >> >> On Wed, 31 Jul 2024, 23:03 robert engels, wrote: >> >>> As a follow-up, even if the heap dump could show the A instance - what >>> about inspection of its fields? Or if you trace its back references what is >>> its root? >>> >>> A virtual thread may not be a GC root, but it?s stack data has to be or >>> every monitoring/analysis technique is broken - and systems will be >>> impossible to audit. >>> >>> >>> On Jul 31, 2024, at 4:59?PM, robert engels wrote: >>> >>> ? >>> Yes, but it?s a graph, because if A doesn?t have a finalizer but >>> references something that does you face the same problem. >>> >>> I think it will. R very hard to profile / debug applications if this >>> were to come to pass. So I open a profiler and expect to see and instance >>> of A but I don?t, and I don?t see any log message (assume finally block >>> printed something) - am I just suppose to assume? well it was a virtual >>> thread and it ?vanished? because it couldn?t make progress. >>> >>> That is ludicrous imo. And also completely unnecessary and against 20 >>> plus years of Java design. >>> >>> On Jul 31, 2024, at 4:23?PM, Alex Otenko >>> wrote: >>> >>> ? >>> >>> I think your observation about finalizers is important. But without >>> finalizers - how do you detect that the object is not alive? >>> >>> More broadly - it is not the object that matters; the code must behave >>> like if the object were alive. (Think of unwrapped Optionals and Integers) >>> >>> On Wed, 31 Jul 2024, 22:03 robert engels, wrote: >>> >>>> This analysis is incorrect. The guarantees about program order say that >>>> ?a? must be alive OR the finally block must execute. There is no gray area >>>> here. This MUST hold. >>>> >>>> You don?t even need to references GC roots - the specification >>>> considers reachability from instance of Thread. A VirtualThread extends >>>> Thread so proper OO means it must act as a Thread for all behaviors of >>>> Thread. >>>> >>>> On Jul 31, 2024, at 1:29?PM, Michal Domagala >>>> wrote: >>>> >>>> ? >>>> Documentation says: "The finally block always executes when the try >>>> block exits" >>>> Not "The finally block always executes" >>>> >>>> I think there are 3 areas to seek an answer about correct VT behavior. >>>> >>>> First is general, "sky-level" rules. GC rule says that "what is >>>> unreferenced and is not GC root, is collectable". The rule says that VT >>>> should be collectable, but many may contest that the rule - as very generic >>>> - is not applicable for blocked VT. But the rule works: blocked VT is >>>> successfully GC-able, if only observability is off. >>>> >>>> Second is habits. I agree that there is a habit that "finally block" is >>>> always executed. But maybe it is just a habit? I think VT GC case in >>>> something fresh and cannot be matched to existing experience, but if do >>>> "kill -s SIGTERM", which is more cooperative than SIGKILL or unplug power, >>>> "finally block" is not executed >>>> >>>> Third is common sense. If something is unreachable, better reclaim >>>> resources and pray it works than have a memory leak and countdown to OOM. >>>> >>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From robaho at icloud.com Wed Jul 31 23:07:44 2024 From: robaho at icloud.com (Robert Engels) Date: Wed, 31 Jul 2024 18:07:44 -0500 Subject: [External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: References: Message-ID: The reason it needs to be there is that a developer needs to be able to reason about the code - and the state changes that moved the system to its current state. If you know you created an A, but the A does not appear in the heap dump, and you can determine that the finally block never executed - how are you supposed to reason and validate the system - remember the take() in this case could be several levels deep - so not anyway near obvious to say ?it must be due to a virtual thread vanishing?. > On Jul 31, 2024, at 6:03 PM, Alex Otenko wrote: > > I don't see objects missing from a heap dump as a problem. I don't think there is any guarantee about that in the JVM spec. In fact, there is no requirement to provide any heap dump. Is there?.. > > So it really is just about the finalizers being executed or not. I actually think not executing them is better (no guarantees of when they should be executed, is there?), but maybe there are good reasons to get them executed. > > > On Wed, 31 Jul 2024, 23:59 robert engels, > wrote: > The program order - except in a case of abrupt termination - must hold. So having A not be present in a heap dump with the finally block never being executed is a problem. It is breaking the specification on reachability. > > So change the spec but then you have different behavior if a platform thread is executing the code versus a virtual thread - which would be another nightmare for readability and auditing. > > I am honestly baffled how this has proceeded so far without someone from the loom team saying - you?re right this would be crazy to do. > > It has if people are writing systems code with no concern for the application code sitting on top. > >> On Jul 31, 2024, at 5:28?PM, Alex Otenko > wrote: >> >> ? >> Like, imagine it is not GCed, but swapped out to /dev/null. Eh? What's the problem with that? We'll swap it back in, when the VT can continue. Deal? :) >> >> >> On Wed, 31 Jul 2024, 23:22 Alex Otenko, > wrote: >> I think you may need to revisit heap dump format. It is all best effort to capture JVM state, not actual state, and not true memory representation. Like, the pointers are 64 bit, even if compressed oops are in use, ... >> >> I've seen heap dumps with missing stack traces and missing GC roots. So, no, I don't think we should worry too much about objects that get optimised away. >> >> Side-effecting finalizers bug me. But if you can reclaim memory without executing them, I think it may be fine. After all, that's the behaviour of the program where the object is still alive. >> >> >> On Wed, 31 Jul 2024, 23:03 robert engels, > wrote: >> As a follow-up, even if the heap dump could show the A instance - what about inspection of its fields? Or if you trace its back references what is its root? >> >> A virtual thread may not be a GC root, but it?s stack data has to be or every monitoring/analysis technique is broken - and systems will be impossible to audit. >> >> >>> On Jul 31, 2024, at 4:59?PM, robert engels > wrote: >>> >>> ? >>> Yes, but it?s a graph, because if A doesn?t have a finalizer but references something that does you face the same problem. >>> >>> I think it will. R very hard to profile / debug applications if this were to come to pass. So I open a profiler and expect to see and instance of A but I don?t, and I don?t see any log message (assume finally block printed something) - am I just suppose to assume? well it was a virtual thread and it ?vanished? because it couldn?t make progress. >>> >>> That is ludicrous imo. And also completely unnecessary and against 20 plus years of Java design. >>> >>>> On Jul 31, 2024, at 4:23?PM, Alex Otenko > wrote: >>>> >>>> ? >>>> I think your observation about finalizers is important. But without finalizers - how do you detect that the object is not alive? >>>> >>>> More broadly - it is not the object that matters; the code must behave like if the object were alive. (Think of unwrapped Optionals and Integers) >>>> >>>> >>>> On Wed, 31 Jul 2024, 22:03 robert engels, > wrote: >>>> This analysis is incorrect. The guarantees about program order say that ?a? must be alive OR the finally block must execute. There is no gray area here. This MUST hold. >>>> >>>> You don?t even need to references GC roots - the specification considers reachability from instance of Thread. A VirtualThread extends Thread so proper OO means it must act as a Thread for all behaviors of Thread. >>>> >>>>> On Jul 31, 2024, at 1:29?PM, Michal Domagala > wrote: >>>>> >>>>> ? >>>>> Documentation says: "The finally block always executes when the try block exits" >>>>> Not "The finally block always executes" >>>>> >>>>> I think there are 3 areas to seek an answer about correct VT behavior. >>>>> >>>>> First is general, "sky-level" rules. GC rule says that "what is unreferenced and is not GC root, is collectable". The rule says that VT should be collectable, but many may contest that the rule - as very generic - is not applicable for blocked VT. But the rule works: blocked VT is successfully GC-able, if only observability is off. >>>>> >>>>> Second is habits. I agree that there is a habit that "finally block" is always executed. But maybe it is just a habit? I think VT GC case in something fresh and cannot be matched to existing experience, but if do "kill -s SIGTERM", which is more cooperative than SIGKILL or unplug power, "finally block" is not executed >>>>> >>>>> Third is common sense. If something is unreachable, better reclaim resources and pray it works than have a memory leak and countdown to OOM. -------------- next part -------------- An HTML attachment was scrubbed... URL: From robaho at icloud.com Wed Jul 31 23:15:05 2024 From: robaho at icloud.com (Robert Engels) Date: Wed, 31 Jul 2024 18:15:05 -0500 Subject: [External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads In-Reply-To: References: Message-ID: Also, I will share this, as it seems very similar to the Thread.stop() deprecation: Why is Thread.stop deprecated? Because it is inherently unsafe. Stopping a thread causes it to unlock all the monitors that it has locked. (The monitors are unlocked as the ThreadDeath exception propagates up the stack.) If any of the objects previously protected by these monitors were in an inconsistent state, other threads may now view these objects in an inconsistent state. Such objects are said to be damaged. When threads operate on damaged objects, arbitrary behavior can result. This behavior may be subtle and difficult to detect, or it may be pronounced. Unlike other unchecked exceptions, ThreadDeath kills threads silently; thus, the user has no warning that his program may be corrupted. The corruption can manifest itself at any time after the actual damage occurs, even hours or days in the future. Here we are talking about something even worse - no exception up the stack - just object references vanishing - regardless of locks, stack-levels, etc. Imagine an auxiliary thread that had a soft/weak reference to A and and a reference queue. It would see A reference added to the code - but no review of any logs, etc. would allow the developer to determine why it became unreachable. The logs would be inconsistent. > On Jul 31, 2024, at 6:07 PM, Robert Engels wrote: > > The reason it needs to be there is that a developer needs to be able to reason about the code - and the state changes that moved the system to its current state. > > If you know you created an A, but the A does not appear in the heap dump, and you can determine that the finally block never executed - how are you supposed to reason and validate the system - remember the take() in this case could be several levels deep - so not anyway near obvious to say ?it must be due to a virtual thread vanishing?. > > > >> On Jul 31, 2024, at 6:03 PM, Alex Otenko > wrote: >> >> I don't see objects missing from a heap dump as a problem. I don't think there is any guarantee about that in the JVM spec. In fact, there is no requirement to provide any heap dump. Is there?.. >> >> So it really is just about the finalizers being executed or not. I actually think not executing them is better (no guarantees of when they should be executed, is there?), but maybe there are good reasons to get them executed. >> >> >> On Wed, 31 Jul 2024, 23:59 robert engels, > wrote: >> The program order - except in a case of abrupt termination - must hold. So having A not be present in a heap dump with the finally block never being executed is a problem. It is breaking the specification on reachability. >> >> So change the spec but then you have different behavior if a platform thread is executing the code versus a virtual thread - which would be another nightmare for readability and auditing. >> >> I am honestly baffled how this has proceeded so far without someone from the loom team saying - you?re right this would be crazy to do. >> >> It has if people are writing systems code with no concern for the application code sitting on top. >> >>> On Jul 31, 2024, at 5:28?PM, Alex Otenko > wrote: >>> >>> ? >>> Like, imagine it is not GCed, but swapped out to /dev/null. Eh? What's the problem with that? We'll swap it back in, when the VT can continue. Deal? :) >>> >>> >>> On Wed, 31 Jul 2024, 23:22 Alex Otenko, > wrote: >>> I think you may need to revisit heap dump format. It is all best effort to capture JVM state, not actual state, and not true memory representation. Like, the pointers are 64 bit, even if compressed oops are in use, ... >>> >>> I've seen heap dumps with missing stack traces and missing GC roots. So, no, I don't think we should worry too much about objects that get optimised away. >>> >>> Side-effecting finalizers bug me. But if you can reclaim memory without executing them, I think it may be fine. After all, that's the behaviour of the program where the object is still alive. >>> >>> >>> On Wed, 31 Jul 2024, 23:03 robert engels, > wrote: >>> As a follow-up, even if the heap dump could show the A instance - what about inspection of its fields? Or if you trace its back references what is its root? >>> >>> A virtual thread may not be a GC root, but it?s stack data has to be or every monitoring/analysis technique is broken - and systems will be impossible to audit. >>> >>> >>>> On Jul 31, 2024, at 4:59?PM, robert engels > wrote: >>>> >>>> ? >>>> Yes, but it?s a graph, because if A doesn?t have a finalizer but references something that does you face the same problem. >>>> >>>> I think it will. R very hard to profile / debug applications if this were to come to pass. So I open a profiler and expect to see and instance of A but I don?t, and I don?t see any log message (assume finally block printed something) - am I just suppose to assume? well it was a virtual thread and it ?vanished? because it couldn?t make progress. >>>> >>>> That is ludicrous imo. And also completely unnecessary and against 20 plus years of Java design. >>>> >>>>> On Jul 31, 2024, at 4:23?PM, Alex Otenko > wrote: >>>>> >>>>> ? >>>>> I think your observation about finalizers is important. But without finalizers - how do you detect that the object is not alive? >>>>> >>>>> More broadly - it is not the object that matters; the code must behave like if the object were alive. (Think of unwrapped Optionals and Integers) >>>>> >>>>> >>>>> On Wed, 31 Jul 2024, 22:03 robert engels, > wrote: >>>>> This analysis is incorrect. The guarantees about program order say that ?a? must be alive OR the finally block must execute. There is no gray area here. This MUST hold. >>>>> >>>>> You don?t even need to references GC roots - the specification considers reachability from instance of Thread. A VirtualThread extends Thread so proper OO means it must act as a Thread for all behaviors of Thread. >>>>> >>>>>> On Jul 31, 2024, at 1:29?PM, Michal Domagala > wrote: >>>>>> >>>>>> ? >>>>>> Documentation says: "The finally block always executes when the try block exits" >>>>>> Not "The finally block always executes" >>>>>> >>>>>> I think there are 3 areas to seek an answer about correct VT behavior. >>>>>> >>>>>> First is general, "sky-level" rules. GC rule says that "what is unreferenced and is not GC root, is collectable". The rule says that VT should be collectable, but many may contest that the rule - as very generic - is not applicable for blocked VT. But the rule works: blocked VT is successfully GC-able, if only observability is off. >>>>>> >>>>>> Second is habits. I agree that there is a habit that "finally block" is always executed. But maybe it is just a habit? I think VT GC case in something fresh and cannot be matched to existing experience, but if do "kill -s SIGTERM", which is more cooperative than SIGKILL or unplug power, "finally block" is not executed >>>>>> >>>>>> Third is common sense. If something is unreachable, better reclaim resources and pray it works than have a memory leak and countdown to OOM. > -------------- next part -------------- An HTML attachment was scrubbed... URL: