From rengels at ix.netcom.com Mon Jan 2 07:27:06 2023 From: rengels at ix.netcom.com (robert engels) Date: Mon, 2 Jan 2023 01:27:06 -0600 Subject: Loom scheduler improvements? Message-ID: Hi loom devs - Happy New Year! I have been digging into loom and testing the performance. I think I see an area for possible improvement in the scheduler. See the following async profiler capture: Notice that the most expensive operation in the system is that the ForkJoin worker is parking attempting to schedule work due to contention on the DelayedWorkQueue lock (the vthread is trying to park itself for N nanos). Ordinarily I wouldn?t be too concerned with micro benchmarks, but the primary goal of Loom is efficiency and this seems like it should be fairly straightforward to address with a specialized lock-free structure for use by Loom carrier threads. I have to expect the Loom design is to handle vthreads will a very short runtime until park/reschedule. As it is, I wrote a specialized lock, rather than using the standard ReentrentLock since the standard always ended up parking the acquiring too soon - only to be awoken nearly immediately, and then rescheduled. It seems better to use some heuristics based on the cost of schedule switch and the expected park time and then spin for N loops prior to parking. I see the same behavior with both JDK19 and JDK20. Does the above look reasonable? Any other suggestions? -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: PastedGraphic-2.png Type: image/png Size: 537656 bytes Desc: not available URL: From ron.pressler at oracle.com Tue Jan 3 09:51:03 2023 From: ron.pressler at oracle.com (Ron Pressler) Date: Tue, 3 Jan 2023 09:51:03 +0000 Subject: Project Loom VirtualThreads hang In-Reply-To: References: Message-ID: <6BFE89AA-844A-4DC5-8AF8-152EA4368474@oracle.com> Hi. Let me first address some of the topics that have come up in this thread before I get to the main point. The meaning of Thread.yield is ?inform the runtime that this thread doesn?t have anything useful to do at the moment, but it might again in the future?. What the runtime does with that information is up to the runtime. As Alan said, in JDK 20 we?ve changed the implementation to have the scheduler spend more time to more aggressively look for other work to do, but Thread.yield shouldn?t be used for scheduling control. It should be used (and very sparingly) to say ?I temporarily have nothing useful to do.? Virtual threads are scheduled preemptively, not cooperatively. This means that the runtime makes the decision when to deschedule (preempt) one thread and schedule another without cooperation from user code. However, the virtual thread scheduler currently does not employ time-sharing, i.e. it does not decide to preempt a thread based on it exceeding some allotted time-slice quota on the CPU. The reason for that is we haven?t yet identified a use-case where time-sharing can help for the use-cases virtual threads address (although we?re very interested to hear about such use-cases if anyone comes across one). Virtual threads are mostly intended to write servers, non-realtime kernels primarily employ time-sharing when the CPU is at 100%, servers don?t usually run at 100% CPU and when they do people aren?t generally happy with the result. So servers don?t rely on time-sharing even without virtual threads (at least not the kind that requires special support), but when we identify a use case where time-sharing could help server workloads we can consider adding it to the preemption considerations. Now for the central point. Virtual threads have scalability benefits for a single reason: their high number. This is due to Little?s law. Replacing a set of platform threads with virtual threads ? as the JEP explains ? should not yield any significant benefits. The benefits come when employing a very high number of virtual threads. For example, the Helidon framework creates 3 million new virtual threads every seconds under high load. As a rule of thumb, if your application doesn?t create a few thousand or so brand-new virtual threads every second, then you?re not using them in the manner for which they were intended and will not see substantial benefits. Virtual threads replace short individual *tasks* in your application, not platform threads. They are best thought of as a business logic entity representing a task rather than an ?execution resource.? For those who are used to managing threads as resources, this is a big change in how they think about threads, and will take some getting used to. ? Ron On 27 Dec 2022, at 22:27, robert engels > wrote: Hi devs, First, Thanks for this amazing work!!! It literally solves the only remaining problem Java had. Sorry for the long email. I have been very excited to test-drive Project Loom in JDK19. I have extensive experience in highly concurrent systems/HFT/HPC, so I usually :) know what I am doing. For the easiest test, I took a highly threaded (connection based) server based system (Java port of Go?s nats.io message broker), and converted the threads to virtual threads. The project (jnatsd) is available here. The ?master? branch runs very well with excellent performance, but I thought switching to virtual threads might be able to improve things over using async IO, channels, etc. (I have a branch for this that works as well, but it is much more complex, and didn?t provide a huge performance benefit)/ There are two branches ?simple_virtual_threads? and ?virtual_threads?. In the former, it is literally a 2 line change to enable the virtual threads but it doesn?t work. I narrowed it down the issue that LockSupport.unpark(thread) does not work consistently. At some point, the virtual thread is never scheduled again. I enabled the debug options and I see that the the virtual thread is in: yield0:365, Continuation (jdk.internal.vm) yield:357, Continuation (jdk.internal.vm) yieldContinuation:370, VirtualThread (java.lang) park:499, VirtualThread (java.lang) parkVirtualThread:2606, System$2 (java.lang) park:54, VirtualThreads (jdk.internal.misc) park:369, LockSupport (java.util.concurrent.locks) run:88, Connection$ConnectionWriter (com.robaho.jnatsd) run:287, VirtualThread (java.lang) lambda$new$0:174, VirtualThread$VThreadContinuation (java.lang) run:-1, VirtualThread$VThreadContinuation$$Lambda$50/0x0000000801065670 (java.lang) enter0:327, Continuation (jdk.internal.vm) enter:320, Continuation (jdk.internal.vm) The instance state is: this = {VirtualThread$VThreadContinuation at 1775} target = {VirtualThread$VThreadContinuation$lambda at 1777} arg$1 = {VirtualThread at 1699} scheduler = {ForkJoinPool at 1781} cont = {VirtualThread$VThreadContinuation at 1775} runContinuation = {VirtualThread$lambda at 1782} state = 2 parkPermit = true carrierThread = null termination = null eetop = 0 tid = 76 name = "" interrupted = false contextClassLoader = {ClassLoaders$AppClassLoader at 1784} inheritedAccessControlContext = {AccessControlContext at 1785} holder = null threadLocals = null inheritableThreadLocals = null extentLocalBindings = null interruptLock = {Object at 1786} parkBlocker = null nioBlocker = null Thread.cont = null uncaughtExceptionHandler = null threadLocalRandomSeed = 0 threadLocalRandomProbe = 0 threadLocalRandomSecondarySeed = 0 container = {ThreadContainers$RootContainer$CountingRootContainer at 1787} headStackableScopes = null arg$2 = {Connection$ConnectionWriter at 1780} scope = {ContinuationScope at 1776} parent = null child = null tail = {StackChunk at 1778} done = false mounted = false yieldInfo = null preempted = false extentLocalCache = null scope = {ContinuationScope at 1776} child = null As you see in the above, the parkPermit is true, but it never runs again. In the latter branch, ?virtual_threads?, I changed the lock-free RingBuffer class to use simple synchronized primitives - under the assumption that with virtual threads lock/wait/notify should be highly efficient. It worked, but it was nearly 2x slower than the original thread based lock-free implementation. So, I added a ?spin loop? in the RingBuffer methods. This code is completely optional and can be no-op?d, and I was able to increase performance to above that of the Thread based version. I dug a little deeper, and decided that using Thread.yield() should be even more efficient than LockSupport.parkNanos(1) - problem is that changing that simple line brings back the hangs. I think there is very little semantic difference between LockSupport.parkNanos(1) and Thread.yield() but the latter should avoid any timer scheduling. The RingBuffer code there is fairly trivial. So, before I dig deeper, is this a known issue that Thread.yield() does not work as expected? Is it is known issue that LockSupport.unpark() fails to reschedule threads? Is it possible because the VirtualThreads do not implement the Java memory model properly? Any ideas how to further diagnose? -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron.pressler at oracle.com Tue Jan 3 09:58:09 2023 From: ron.pressler at oracle.com (Ron Pressler) Date: Tue, 3 Jan 2023 09:58:09 +0000 Subject: Loom scheduler improvements? In-Reply-To: References: Message-ID: <09316865-115D-46D3-A11E-5D081B20C4F3@oracle.com> > On 2 Jan 2023, at 07:27, robert engels wrote: > > Hi loom devs - Happy New Year! > > I have been digging into loom and testing the performance. > > I think I see an area for possible improvement in the scheduler. See the following async profiler capture: > > > > Notice that the most expensive operation in the system is that the ForkJoin worker is parking attempting to schedule work due to contention on the DelayedWorkQueue lock (the vthread is trying to park itself for N nanos). Ordinarily I wouldn?t be too concerned with micro benchmarks, but the primary goal of Loom is efficiency and this seems like it should be fairly straightforward to address with a specialized lock-free structure for use by Loom carrier threads. I have to expect the Loom design is to handle vthreads will a very short runtime until park/reschedule. > > As it is, I wrote a specialized lock, rather than using the standard ReentrentLock since the standard always ended up parking the acquiring too soon - only to be awoken nearly immediately, and then rescheduled. It seems better to use some heuristics based on the cost of schedule switch and the expected park time and then spin for N loops prior to parking. > > I see the same behavior with both JDK19 and JDK20. > > Does the above look reasonable? Any other suggestions? > > > Your profile seems to be using ScheduledThreadPoolExecutor rather than ForkJoinPool. Also, keep in mind that virtual threads? performance mostly comes from their ability to be plentiful, so a reasonable assumption for benchmarks is a high number of threads (at least thousands). ? Ron From ron.pressler at oracle.com Tue Jan 3 10:02:52 2023 From: ron.pressler at oracle.com (Ron Pressler) Date: Tue, 3 Jan 2023 10:02:52 +0000 Subject: Thread::yield in a VirtualThread In-Reply-To: <1923444327.4402301.1672095540213@mail.yahoo.com> References: <1923444327.4402301.1672095540213.ref@mail.yahoo.com> <1923444327.4402301.1672095540213@mail.yahoo.com> Message-ID: Hi. We?ve changed the implementation of yield in JDK 20 to be more in line with what most people expect it to do (it now looks for other tasks more aggressively) so I suggest you give JDK 20-EA a try. Having said that, yield shouldn?t generally be relied upon to exhibit some specific scheduling behaviour and it doesn?t make more guarantees when called on a virtual thread. ? Ron > On 26 Dec 2022, at 22:59, KT Nabe wrote: > > In writing a simulation for my students, I've encountered some unexpected behavior when virtual threads invoke Thread.yield (understanding that it isn't really clear what guarantees if any are provided). > > In short, if enough* virtual threads are concurrently executing Thread.yield, then no other suspended (sic? yielded/paused) virtual threads will ever be resumed (in my case the other vt's in question were Thread.sleeping, but their deadline has long since expired) > > *enough seems to be =:= the number of CarrierThreads allocated for the default FJP used to run virtual threads (but that's merely an inference from debugging the simulation and may not be what is really going on) > > so I have a check-before-continue (spin) loop: > > A: > while (0 != (mask & state.get())) > { > Thread.yield(); //nothing to do until some other thread mutates #state > } > > and other virtual threads: > B: > Thread.sleep(1_000L) //at some point this never returns, and so the next line is never executed > state.addAndGet(-mask) > > > in running the code in a debugger, as best I can tell, > Thread.yield() > .... > Continuation.yield(SCOPE) // returns false?!? > although the return value is ignored > I don't know what Continuation::yield returning false actually means, and what its effects are > > What did I expect? > Well, that yielding a virtual-thread/continuation would result in the opportunity for other virtual threads to be resumed/run; I realize that Thread.yield on a platform thread is more or less undefined, but I assumed that on a virtual thread it would have stronger guarantees (yielding a continuation is kind of the point, isn't it?) > > Now, if I replace A: > while (0 != (mask & state.get())) > { > // Thread.yield(); //nothing to do until some other thread mutates #state > Thread.sleep(10L); > } > > that solves the problem (there are no program logic errors), and all virtual threads make progress as expected. > > Is this surprising behavior or do I not understand something? > > Thanks. > -T > > particulars: > Java: 19.0.1; OpenJDK 64-Bit Server VM 19.0.1+10 > Runtime: OpenJDK Runtime Environment 19.0.1+10 From Alan.Bateman at oracle.com Tue Jan 3 10:18:00 2023 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 3 Jan 2023 10:18:00 +0000 Subject: Thread::yield in a VirtualThread In-Reply-To: <1923444327.4402301.1672095540213@mail.yahoo.com> References: <1923444327.4402301.1672095540213.ref@mail.yahoo.com> <1923444327.4402301.1672095540213@mail.yahoo.com> Message-ID: On 26/12/2022 22:59, KT Nabe wrote: > In writing a simulation for my students, I've encountered some unexpected behavior when virtual threads invoke Thread.yield (understanding that it isn't really clear what guarantees if any are provided). > > In short, if enough* virtual threads are concurrently executing Thread.yield, then no other suspended (sic? yielded/paused) virtual threads will ever be resumed (in my case the other vt's in question were Thread.sleeping, but their deadline has long since expired) > > : > > particulars: > Java: 19.0.1; OpenJDK 64-Bit Server VM 19.0.1+10 > Runtime: OpenJDK Runtime Environment 19.0.1+10 The implementation of virtual Thread.yield has changed in JDK 20 to improve fairness a bit and should reduce surprises. The intention isn't to use is to control scheduling but the changed implementation may be useful for your teaching. -Alan From ron.pressler at oracle.com Tue Jan 3 10:21:15 2023 From: ron.pressler at oracle.com (Ron Pressler) Date: Tue, 3 Jan 2023 10:21:15 +0000 Subject: StructuredTaskScope and Futures Message-ID: Hi. A question to those of you who have been using StructuredTaskScope: Have you ever used any method on the Future returned from fork other than resultNow and, if so, when/why? ? Ron From forax at univ-mlv.fr Tue Jan 3 10:31:59 2023 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 3 Jan 2023 11:31:59 +0100 (CET) Subject: StructuredTaskScope and Futures In-Reply-To: References: Message-ID: <1009113343.75754648.1672741919013.JavaMail.zimbra@u-pem.fr> ----- Original Message ----- > From: "Ron Pressler" > To: "loom-dev" > Sent: Tuesday, January 3, 2023 11:21:15 AM > Subject: StructuredTaskScope and Futures > Hi. Hi, happy new year, > > A question to those of you who have been using StructuredTaskScope: Have you > ever used any method on the Future returned from fork other than resultNow and, > if so, when/why? state() to know the result/cancellation/error and exceptionNow() to propagate/log the error messages. > > ? Ron R?mi From ron.pressler at oracle.com Tue Jan 3 11:00:45 2023 From: ron.pressler at oracle.com (Ron Pressler) Date: Tue, 3 Jan 2023 11:00:45 +0000 Subject: [External] : Re: StructuredTaskScope and Futures In-Reply-To: <1009113343.75754648.1672741919013.JavaMail.zimbra@u-pem.fr> References: <1009113343.75754648.1672741919013.JavaMail.zimbra@u-pem.fr> Message-ID: <5FBD5E84-6A71-41BB-8179-E5FF87E255B6@oracle.com> > On 3 Jan 2023, at 10:31, Remi Forax wrote: > > ----- Original Message ----- >> From: "Ron Pressler" >> To: "loom-dev" >> Sent: Tuesday, January 3, 2023 11:21:15 AM >> Subject: StructuredTaskScope and Futures > >> Hi. > > Hi, > happy new year, > Happy new year! >> >> A question to those of you who have been using StructuredTaskScope: Have you >> ever used any method on the Future returned from fork other than resultNow and, >> if so, when/why? > > state() to know the result/cancellation/error and exceptionNow() to propagate/log the error messages. > When do you need to know the state or exception on an individual task rather than rely on the policy to handle errors collectively before processing successful results? If you have a code example that would be helpful. ? Ron From ron.pressler at oracle.com Tue Jan 3 11:03:30 2023 From: ron.pressler at oracle.com (Ron Pressler) Date: Tue, 3 Jan 2023 11:03:30 +0000 Subject: Loom scheduler improvements? In-Reply-To: <09316865-115D-46D3-A11E-5D081B20C4F3@oracle.com> References: <09316865-115D-46D3-A11E-5D081B20C4F3@oracle.com> Message-ID: <6C1EC3B1-1BFE-4B9B-9B06-021258D3A7C4@oracle.com> I?m sorry, parkNanos uses ScheduledThreadPoolExecutor and I didn?t notice that?s the operation in your profile. ? Ron > On 3 Jan 2023, at 09:58, Ron Pressler wrote: > > > >> On 2 Jan 2023, at 07:27, robert engels wrote: >> >> Hi loom devs - Happy New Year! >> >> I have been digging into loom and testing the performance. >> >> I think I see an area for possible improvement in the scheduler. See the following async profiler capture: >> >> >> >> Notice that the most expensive operation in the system is that the ForkJoin worker is parking attempting to schedule work due to contention on the DelayedWorkQueue lock (the vthread is trying to park itself for N nanos). Ordinarily I wouldn?t be too concerned with micro benchmarks, but the primary goal of Loom is efficiency and this seems like it should be fairly straightforward to address with a specialized lock-free structure for use by Loom carrier threads. I have to expect the Loom design is to handle vthreads will a very short runtime until park/reschedule. >> >> As it is, I wrote a specialized lock, rather than using the standard ReentrentLock since the standard always ended up parking the acquiring too soon - only to be awoken nearly immediately, and then rescheduled. It seems better to use some heuristics based on the cost of schedule switch and the expected park time and then spin for N loops prior to parking. >> >> I see the same behavior with both JDK19 and JDK20. >> >> Does the above look reasonable? Any other suggestions? >> >> >> > > > Your profile seems to be using ScheduledThreadPoolExecutor rather than ForkJoinPool. > > Also, keep in mind that virtual threads? performance mostly comes from their ability to be plentiful, so a reasonable assumption for benchmarks is a high number of threads (at least thousands). > > ? Ron From rengels at ix.netcom.com Tue Jan 3 13:53:37 2023 From: rengels at ix.netcom.com (Robert Engels) Date: Tue, 3 Jan 2023 07:53:37 -0600 Subject: Loom scheduler improvements? In-Reply-To: <6C1EC3B1-1BFE-4B9B-9B06-021258D3A7C4@oracle.com> References: <6C1EC3B1-1BFE-4B9B-9B06-021258D3A7C4@oracle.com> Message-ID: <40E2FF7B-886F-4EEB-B2A2-23CB30412FCF@ix.netcom.com> Correct. I don?t see this contention when using park() and then my own external scheduler to wake the vthread after the required duration. > On Jan 3, 2023, at 5:03 AM, Ron Pressler wrote: > > ?I?m sorry, parkNanos uses ScheduledThreadPoolExecutor and I didn?t notice that?s the operation in your profile. > > ? Ron > >>> On 3 Jan 2023, at 09:58, Ron Pressler wrote: >>> >>> >>> >>>> On 2 Jan 2023, at 07:27, robert engels wrote: >>> >>> Hi loom devs - Happy New Year! >>> >>> I have been digging into loom and testing the performance. >>> >>> I think I see an area for possible improvement in the scheduler. See the following async profiler capture: >>> >>> >>> >>> Notice that the most expensive operation in the system is that the ForkJoin worker is parking attempting to schedule work due to contention on the DelayedWorkQueue lock (the vthread is trying to park itself for N nanos). Ordinarily I wouldn?t be too concerned with micro benchmarks, but the primary goal of Loom is efficiency and this seems like it should be fairly straightforward to address with a specialized lock-free structure for use by Loom carrier threads. I have to expect the Loom design is to handle vthreads will a very short runtime until park/reschedule. >>> >>> As it is, I wrote a specialized lock, rather than using the standard ReentrentLock since the standard always ended up parking the acquiring too soon - only to be awoken nearly immediately, and then rescheduled. It seems better to use some heuristics based on the cost of schedule switch and the expected park time and then spin for N loops prior to parking. >>> >>> I see the same behavior with both JDK19 and JDK20. >>> >>> Does the above look reasonable? Any other suggestions? >>> >>> >>> >> >> >> Your profile seems to be using ScheduledThreadPoolExecutor rather than ForkJoinPool. >> >> Also, keep in mind that virtual threads? performance mostly comes from their ability to be plentiful, so a reasonable assumption for benchmarks is a high number of threads (at least thousands). >> >> ? Ron > From rengels at ix.netcom.com Tue Jan 3 14:03:51 2023 From: rengels at ix.netcom.com (Robert Engels) Date: Tue, 3 Jan 2023 08:03:51 -0600 Subject: Project Loom VirtualThreads hang In-Reply-To: <6BFE89AA-844A-4DC5-8AF8-152EA4368474@oracle.com> References: <6BFE89AA-844A-4DC5-8AF8-152EA4368474@oracle.com> Message-ID: <31C08A9D-14E5-46A9-BD5E-79F71CB1D0CB@ix.netcom.com> Hi Ron. I think there is another traditional use case of ?virtual threads? which is to increase efficiency for short cycle tasks. You can write a simple blocking queue and a message passing system - and with as little as 32 threads you will see > 50% system cpu time due to trashing in the scheduler. A virtual thread should be far more efficient in regards to user space locking/blocking/wake-up - my tests show only a few % system cpu time. To do this well though the vthread scheduler needs to be super efficient and the locking constructs rewritten knowing they?re on green threads - because the spin time/block decisions are much different (eg upwards of 16 microseconds to perform an os switch to another thread on the cpu vs a few hundred nanoseconds for a green thread switch). > On Jan 3, 2023, at 3:51 AM, Ron Pressler wrote: > > ? Hi. > > Let me first address some of the topics that have come up in this thread before I get to the main point. > > The meaning of Thread.yield is ?inform the runtime that this thread doesn?t have anything useful to do at the moment, but it might again in the future?. What the runtime does with that information is up to the runtime. As Alan said, in JDK 20 we?ve changed the implementation to have the scheduler spend more time to more aggressively look for other work to do, but Thread.yield shouldn?t be used for scheduling control. It should be used (and very sparingly) to say ?I temporarily have nothing useful to do.? > > Virtual threads are scheduled preemptively, not cooperatively. This means that the runtime makes the decision when to deschedule (preempt) one thread and schedule another without cooperation from user code. However, the virtual thread scheduler currently does not employ time-sharing, i.e. it does not decide to preempt a thread based on it exceeding some allotted time-slice quota on the CPU. The reason for that is we haven?t yet identified a use-case where time-sharing can help for the use-cases virtual threads address (although we?re very interested to hear about such use-cases if anyone comes across one). Virtual threads are mostly intended to write servers, non-realtime kernels primarily employ time-sharing when the CPU is at 100%, servers don?t usually run at 100% CPU and when they do people aren?t generally happy with the result. So servers don?t rely on time-sharing even without virtual threads (at least not the kind that requires special support), but when we identify a use case where time-sharing could help server workloads we can consider adding it to the preemption considerations. > > Now for the central point. Virtual threads have scalability benefits for a single reason: their high number. This is due to Little?s law. Replacing a set of platform threads with virtual threads ? as the JEP explains ? should not yield any significant benefits. The benefits come when employing a very high number of virtual threads. For example, the Helidon framework creates 3 million new virtual threads every seconds under high load. As a rule of thumb, if your application doesn?t create a few thousand or so brand-new virtual threads every second, then you?re not using them in the manner for which they were intended and will not see substantial benefits. Virtual threads replace short individual *tasks* in your application, not platform threads. They are best thought of as a business logic entity representing a task rather than an ?execution resource.? For those who are used to managing threads as resources, this is a big change in how they think about threads, and will take some getting used to. > > ? Ron > >> On 27 Dec 2022, at 22:27, robert engels wrote: >> >> Hi devs, >> >> First, >> >> Thanks for this amazing work!!! It literally solves the only remaining problem Java had. >> >> Sorry for the long email. >> >> I have been very excited to test-drive Project Loom in JDK19. I have extensive experience in highly concurrent systems/HFT/HPC, so I usually :) know what I am doing. >> >> For the easiest test, I took a highly threaded (connection based) server based system (Java port of Go?s nats.io message broker), and converted the threads to virtual threads. The project (jnatsd) is available here. The ?master? branch runs very well with excellent performance, but I thought switching to virtual threads might be able to improve things over using async IO, channels, etc. (I have a branch for this that works as well, but it is much more complex, and didn?t provide a huge performance benefit)/ >> >> There are two branches ?simple_virtual_threads? and ?virtual_threads?. >> >> In the former, it is literally a 2 line change to enable the virtual threads but it doesn?t work. I narrowed it down the issue that LockSupport.unpark(thread) does not work consistently. At some point, the virtual thread is never scheduled again. I enabled the debug options and I see that the the virtual thread is in: >> >> yield0:365, Continuation (jdk.internal.vm) >> yield:357, Continuation (jdk.internal.vm) >> yieldContinuation:370, VirtualThread (java.lang) >> park:499, VirtualThread (java.lang) >> parkVirtualThread:2606, System$2 (java.lang) >> park:54, VirtualThreads (jdk.internal.misc) >> park:369, LockSupport (java.util.concurrent.locks) >> run:88, Connection$ConnectionWriter (com.robaho.jnatsd) >> run:287, VirtualThread (java.lang) >> lambda$new$0:174, VirtualThread$VThreadContinuation (java.lang) >> run:-1, VirtualThread$VThreadContinuation$$Lambda$50/0x0000000801065670 (java.lang) >> enter0:327, Continuation (jdk.internal.vm) >> enter:320, Continuation (jdk.internal.vm) >> The instance state is: >> >> this = {VirtualThread$VThreadContinuation at 1775} >> target = {VirtualThread$VThreadContinuation$lambda at 1777} >> arg$1 = {VirtualThread at 1699} >> scheduler = {ForkJoinPool at 1781} >> cont = {VirtualThread$VThreadContinuation at 1775} >> runContinuation = {VirtualThread$lambda at 1782} >> state = 2 >> parkPermit = true >> carrierThread = null >> termination = null >> eetop = 0 >> tid = 76 >> name = "" >> interrupted = false >> contextClassLoader = {ClassLoaders$AppClassLoader at 1784} >> inheritedAccessControlContext = {AccessControlContext at 1785} >> holder = null >> threadLocals = null >> inheritableThreadLocals = null >> extentLocalBindings = null >> interruptLock = {Object at 1786} >> parkBlocker = null >> nioBlocker = null >> Thread.cont = null >> uncaughtExceptionHandler = null >> threadLocalRandomSeed = 0 >> threadLocalRandomProbe = 0 >> threadLocalRandomSecondarySeed = 0 >> container = {ThreadContainers$RootContainer$CountingRootContainer at 1787} >> headStackableScopes = null >> arg$2 = {Connection$ConnectionWriter at 1780} >> scope = {ContinuationScope at 1776} >> parent = null >> child = null >> tail = {StackChunk at 1778} >> done = false >> mounted = false >> yieldInfo = null >> preempted = false >> extentLocalCache = null >> scope = {ContinuationScope at 1776} >> child = null >> >> As you see in the above, the parkPermit is true, but it never runs again. >> >> In the latter branch, ?virtual_threads?, I changed the lock-free RingBuffer class to use simple synchronized primitives - under the assumption that with virtual threads lock/wait/notify should be highly efficient. It worked, but it was nearly 2x slower than the original thread based lock-free implementation. So, I added a ?spin loop? in the RingBuffer methods. This code is completely optional and can be no-op?d, and I was able to increase performance to above that of the Thread based version. >> >> I dug a little deeper, and decided that using Thread.yield() should be even more efficient than LockSupport.parkNanos(1) - problem is that changing that simple line brings back the hangs. I think there is very little semantic difference between LockSupport.parkNanos(1) and Thread.yield() but the latter should avoid any timer scheduling. The RingBuffer code there is fairly trivial. >> >> So, before I dig deeper, is this a known issue that Thread.yield() does not work as expected? Is it is known issue that LockSupport.unpark() fails to reschedule threads? >> >> Is it possible because the VirtualThreads do not implement the Java memory model properly? >> >> Any ideas how to further diagnose? >> >> >> >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Tue Jan 3 14:10:53 2023 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 3 Jan 2023 14:10:53 +0000 Subject: Project Loom VirtualThreads hang In-Reply-To: <6D0BBA80-2749-4C58-8A5A-316E162B6CC2@ix.netcom.com> References: <34BCE332-8EE9-4742-AAE2-16D52548437E@ix.netcom.com> <6D0BBA80-2749-4C58-8A5A-316E162B6CC2@ix.netcom.com> Message-ID: On 28/12/2022 13:07, Robert Engels wrote: > Alan, > > I tested with JDK 20 and both the VThreadTest and SpinTest complete successfully using Thread.yield! > > Surprisingly, it is slower than using LockSupport.parkNanos(1) - 14 secs vs 7 secs I am not sure this makes sense - as conceptually a thread yield should be at least as efficient as a 0 time sleep - and probably more efficient. A timed park for very short <1us durations (or in particular <250ns) is problematic in that the timeout may be reached before the virtual thread has fully parked. In that case, it may get re-scheduled on the same carrier rather than bouncing between carriers as might happen with Thread.yield. So that might partly explain what you are seeing. Also 7 and 14s is very short run for a benchmark. I think I'd need to see the benchmark to know what you are testing. -Alan From Alan.Bateman at oracle.com Tue Jan 3 14:34:08 2023 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 3 Jan 2023 14:34:08 +0000 Subject: Project Loom VirtualThreads hang In-Reply-To: <31C08A9D-14E5-46A9-BD5E-79F71CB1D0CB@ix.netcom.com> References: <6BFE89AA-844A-4DC5-8AF8-152EA4368474@oracle.com> <31C08A9D-14E5-46A9-BD5E-79F71CB1D0CB@ix.netcom.com> Message-ID: <8ac87cf2-7737-7e0b-64d7-9e81db99159c@oracle.com> On 03/01/2023 14:03, Robert Engels wrote: > : > > A virtual thread should be far more efficient in regards to user space > locking/blocking/wake-up - my tests show only a few % system cpu time. > To do this well though the vthread scheduler needs to be super > efficient and the locking constructs rewritten knowing they?re on > green threads - because the spin time/block decisions are much > different (eg upwards of 16 microseconds to perform an os switch to > another thread on the cpu vs a few hundred nanoseconds for a green > thread switch). Yes, the cost model is different so the use of spin loops to reduce parking has to looked at in several places. So what are you testing, is a? j.u.concurrent API or something else? There is some spinning and yield once in APIs such as SQ and LTQ that do need to be re-examined. -Alan From rengels at ix.netcom.com Tue Jan 3 14:37:29 2023 From: rengels at ix.netcom.com (Robert Engels) Date: Tue, 3 Jan 2023 08:37:29 -0600 Subject: Project Loom VirtualThreads hang In-Reply-To: References: Message-ID: I can describe the scenario a bit more. In a message passing system N producers send messages to M consumers. When a message is sent to a consumer it isn?t necessarily flushed to the os tcp buffers immediately - since the cross into the os is expensive and if a consumer just received a message there?s a good chance they will receive one again soon so a timer is set for 500us after which the messages are flushed. This sacrifices single message latency for throughout and is configurable if the delay occurs. The way I had to address it was to use LockSupport park() instead and use an external thread to wake the thread if needed. It is actually more efficient since the single thread can handle the timers for all consumers. > On Jan 3, 2023, at 8:11 AM, Alan Bateman wrote: > > ?On 28/12/2022 13:07, Robert Engels wrote: >> Alan, >> >> I tested with JDK 20 and both the VThreadTest and SpinTest complete successfully using Thread.yield! >> >> Surprisingly, it is slower than using LockSupport.parkNanos(1) - 14 secs vs 7 secs I am not sure this makes sense - as conceptually a thread yield should be at least as efficient as a 0 time sleep - and probably more efficient. > A timed park for very short <1us durations (or in particular <250ns) is problematic in that the timeout may be reached before the virtual thread has fully parked. In that case, it may get re-scheduled on the same carrier rather than bouncing between carriers as might happen with Thread.yield. So that might partly explain what you are seeing. Also 7 and 14s is very short run for a benchmark. I think I'd need to see the benchmark to know what you are testing. > > -Alan > > > > > > From rengels at ix.netcom.com Tue Jan 3 15:02:03 2023 From: rengels at ix.netcom.com (Robert Engels) Date: Tue, 3 Jan 2023 09:02:03 -0600 Subject: Project Loom VirtualThreads hang In-Reply-To: <8ac87cf2-7737-7e0b-64d7-9e81db99159c@oracle.com> References: <8ac87cf2-7737-7e0b-64d7-9e81db99159c@oracle.com> Message-ID: <0F114671-B895-4E04-B4A5-7DD6EA1FBA07@ix.netcom.com> I start with the standard j.u.c containers but I?ve reworked a few for green threads. One of the biggest surprises is that synchronized() doesn?t work well with green threads. Changing the code to use a specialized exclusive lock made a huge improvement. I plan on working up a post with my summary findings and code samples when I can find some time. In general Loom is working really well except for a few surprising cases. My Java server has been able to match the performance of the Go server but not consistently (may be due to GC) but prior the native thread version could only get to within 20% of it - the async version showed more promise but the code is messy. Since producer P1 and P2 might send a message to consumer C1 at the same time, there is locking involved. With native threads the only solution was to use a intermediary specialized queue. With threads it is more efficient to use standard locking on the output side. The above is evidence that the use case of vthreads is beyond ?thousands of threads creating every few seconds? and more efficient user space synchronization should also be a primary metric. > On Jan 3, 2023, at 8:34 AM, Alan Bateman wrote: > > ?On 03/01/2023 14:03, Robert Engels wrote: >> : >> >> A virtual thread should be far more efficient in regards to user space locking/blocking/wake-up - my tests show only a few % system cpu time. To do this well though the vthread scheduler needs to be super efficient and the locking constructs rewritten knowing they?re on green threads - because the spin time/block decisions are much different (eg upwards of 16 microseconds to perform an os switch to another thread on the cpu vs a few hundred nanoseconds for a green thread switch). > > Yes, the cost model is different so the use of spin loops to reduce parking has to looked at in several places. So what are you testing, is a j.u.concurrent API or something else? There is some spinning and yield once in APIs such as SQ and LTQ that do need to be re-examined. > > -Alan From eric at kolotyluk.net Tue Jan 3 17:19:35 2023 From: eric at kolotyluk.net (Eric Kolotyluk) Date: Tue, 3 Jan 2023 09:19:35 -0800 Subject: Thread::yield in a VirtualThread In-Reply-To: References: <1923444327.4402301.1672095540213.ref@mail.yahoo.com> <1923444327.4402301.1672095540213@mail.yahoo.com> Message-ID: <4e3b73e1-4c17-3c2b-b3e4-0baa4ec48a29@kolotyluk.net> As someone who many be abusing Thread::yield at times, I really appreciate these little discussions... I would love to see such gems captured somewhere in a document, blog, etc. as email is rather ephemeral... A Loom Best Practices Wiki would be nice, but the JavaDoc would be best... unfortunately, there seems to be a reluctance in JavaDocs for lengthy discussions. Personally, in my own JavaDocs, I embed links to Wikis, such as Confluence, for further explanations. As far back as Java AWT (who remembers AWT?) and Swing, I routinely fixed scheduling problems by throwing operations on the Event Thread for reprocessing, even when I was already on the Event Thread. This was a simple fix that solved many synchrnization problems... I have retained this practice, for good or bad, in Java Platform Threads. I have not used Virtual Threads yet in production, but I would probably continue to do so in Virtual Threads without some caveats. Now that I better understand the engineering intent of Thread::yield, I will be more mindful in the future. Thanks again for such clarifications. I look forward to reading Ron Pressler's forthcoming book "The Metaphysics of Loom" ? Cheers, Eric On 2023-01-03 2:18 a.m., Alan Bateman wrote: > On 26/12/2022 22:59, KT Nabe wrote: >> In writing a simulation for my students, I've encountered some >> unexpected behavior when virtual threads invoke Thread.yield >> (understanding that it isn't really clear what guarantees if any are >> provided). >> >> In short, if enough* virtual threads are concurrently executing >> Thread.yield, then no other suspended (sic? yielded/paused) virtual >> threads will ever be resumed (in my case the other vt's in question >> were Thread.sleeping, but their deadline has long since expired) >> >> : >> >> particulars: >> Java: 19.0.1; OpenJDK 64-Bit Server VM 19.0.1+10 >> Runtime: OpenJDK Runtime Environment 19.0.1+10 > The implementation of virtual Thread.yield has changed in JDK 20 to > improve fairness a bit and should reduce surprises. The intention > isn't to use is to control scheduling but the changed implementation > may be useful for your teaching. > > -Alan From ron.pressler at oracle.com Tue Jan 3 17:52:58 2023 From: ron.pressler at oracle.com (Ron Pressler) Date: Tue, 3 Jan 2023 17:52:58 +0000 Subject: [External] : Re: Project Loom VirtualThreads hang In-Reply-To: <31C08A9D-14E5-46A9-BD5E-79F71CB1D0CB@ix.netcom.com> References: <6BFE89AA-844A-4DC5-8AF8-152EA4368474@oracle.com> <31C08A9D-14E5-46A9-BD5E-79F71CB1D0CB@ix.netcom.com> Message-ID: <8C7E4BDF-ABAD-49E6-A885-F695390B6D92@oracle.com> On 3 Jan 2023, at 14:03, Robert Engels > wrote: Hi Ron. I think there is another traditional use case of ?virtual threads? which is to increase efficiency for short cycle tasks. You can write a simple blocking queue and a message passing system - and with as little as 32 threads you will see > 50% system cpu time due to trashing in the scheduler. A virtual thread should be far more efficient in regards to user space locking/blocking/wake-up - my tests show only a few % system cpu time. To do this well though the vthread scheduler needs to be super efficient and the locking constructs rewritten knowing they?re on green threads - because the spin time/block decisions are much different (eg upwards of 16 microseconds to perform an os switch to another thread on the cpu vs a few hundred nanoseconds for a green thread switch). Quite possibly, but that use-case is not a primary focus for us at the moment because there?s more efficiency to be gained for the simple servers that use hundreds of thousands of virtual threads. Not only is that use-case more common, but the efficiency can increase by hundreds of percent, while reducing context-switching costs has an impact in the single digits for I/O workloads (see https://inside.java/2020/08/07/loom-performance/). That?s not to say we?re not interested in scheduling improvements ? far from it, and we?ll definitely do them with time ? but in terms of prioritising effort, we?ll probably first invest more where there?s more to be gained. ? Ron On Jan 3, 2023, at 3:51 AM, Ron Pressler > wrote: ? Hi. Let me first address some of the topics that have come up in this thread before I get to the main point. The meaning of Thread.yield is ?inform the runtime that this thread doesn?t have anything useful to do at the moment, but it might again in the future?. What the runtime does with that information is up to the runtime. As Alan said, in JDK 20 we?ve changed the implementation to have the scheduler spend more time to more aggressively look for other work to do, but Thread.yield shouldn?t be used for scheduling control. It should be used (and very sparingly) to say ?I temporarily have nothing useful to do.? Virtual threads are scheduled preemptively, not cooperatively. This means that the runtime makes the decision when to deschedule (preempt) one thread and schedule another without cooperation from user code. However, the virtual thread scheduler currently does not employ time-sharing, i.e. it does not decide to preempt a thread based on it exceeding some allotted time-slice quota on the CPU. The reason for that is we haven?t yet identified a use-case where time-sharing can help for the use-cases virtual threads address (although we?re very interested to hear about such use-cases if anyone comes across one). Virtual threads are mostly intended to write servers, non-realtime kernels primarily employ time-sharing when the CPU is at 100%, servers don?t usually run at 100% CPU and when they do people aren?t generally happy with the result. So servers don?t rely on time-sharing even without virtual threads (at least not the kind that requires special support), but when we identify a use case where time-sharing could help server workloads we can consider adding it to the preemption considerations. Now for the central point. Virtual threads have scalability benefits for a single reason: their high number. This is due to Little?s law. Replacing a set of platform threads with virtual threads ? as the JEP explains ? should not yield any significant benefits. The benefits come when employing a very high number of virtual threads. For example, the Helidon framework creates 3 million new virtual threads every seconds under high load. As a rule of thumb, if your application doesn?t create a few thousand or so brand-new virtual threads every second, then you?re not using them in the manner for which they were intended and will not see substantial benefits. Virtual threads replace short individual *tasks* in your application, not platform threads. They are best thought of as a business logic entity representing a task rather than an ?execution resource.? For those who are used to managing threads as resources, this is a big change in how they think about threads, and will take some getting used to. ? Ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From thurston.nomagicsoftware at gmail.com Tue Jan 3 19:24:18 2023 From: thurston.nomagicsoftware at gmail.com (thurston N) Date: Tue, 3 Jan 2023 11:24:18 -0800 Subject: Project Loom VirtualThreads hang Message-ID: Hello Ron, Quoting: "Virtual threads replace *short *individual *tasks* in your application, not platform threads." Why *short?* *Take a TCP server's accept loop. I would have thought that's a natural target for execution in a virtual thread. * *And it's more or less intended to run forever.* * "They are best thought of as a business logic entity representing a task rather than an ?execution resource.?"* *That's a pretty good definition of an "actor" (as in actors-model). But there's no (even implicit) restriction on the duration of * *an actor's lifetime.* *Is it your intent to proscribe virtual threads as a possible implementation for actor-model type designs? * *I'm thinking of simulations, e.g. modelling a migrating herd, bees at a honeycomb, a very busy traffic intersection, et al.* *It seems natural (even elegant) to represent each of those entities (deer, bee, car) as a virtual thread, and executing them as a * *platform thread isn't an option (because of their sheer number, the essence of the problem that virtual threads is the solution for)* *And I'm sure there are innumerable other circumstances that could benefit from LWP (as Erlang terms them)* *IMO, it's awfully reductive to restrict practical uses of virtual threads to writing sequential single request/response scenarios * -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron.pressler at oracle.com Tue Jan 3 22:16:41 2023 From: ron.pressler at oracle.com (Ron Pressler) Date: Tue, 3 Jan 2023 22:16:41 +0000 Subject: Project Loom VirtualThreads hang In-Reply-To: References: Message-ID: On 3 Jan 2023, at 19:24, thurston N > wrote: Hello Ron, Quoting: "Virtual threads replace short individual *tasks* in your application, not platform threads." Why short? Take a TCP server's accept loop. I would have thought that's a natural target for execution in a virtual thread. And it's more or less intended to run forever. A small number of virtual threads may run for a long time, but the vast majority would be short lived. They would naturally form a hierarchy: you?d have one or a couple of threads accepting connections that live forever, several thousand request-handling threads that live as long as a single request, and then tens of thousands or more each servicing a single outgoing service request in a fanout, and those would be even shorter-lived. "They are best thought of as a business logic entity representing a task rather than an ?execution resource.?" That's a pretty good definition of an "actor" (as in actors-model). But there's no (even implicit) restriction on the duration of an actor's lifetime. Is it your intent to proscribe virtual threads as a possible implementation for actor-model type designs? Threads are sequential task that is done concurrently with others. What protocols are used to communicate among threads (and the actor model is a communication protocol) is up to the programmer. An actor model is a bit too high-level for the JDK, but libraries may certainly offer actors based on virtual threads, just as others may build other high level constructs. I'm thinking of simulations, e.g. modelling a migrating herd, bees at a honeycomb, a very busy traffic intersection, et al. It seems natural (even elegant) to represent each of those entities (deer, bee, car) as a virtual thread, and executing them as a platform thread isn't an option (because of their sheer number, the essence of the problem that virtual threads is the solution for) And I'm sure there are innumerable other circumstances that could benefit from LWP (as Erlang terms them) IMO, it's awfully reductive to restrict practical uses of virtual threads to writing sequential single request/response scenarios My intent is not to restrict so much as to focus. Simulations are absolutely a great use-case for lightweight threads, but there are implementation choices that may need to balance some desirable properties with others and could result in virtual threads being a better fit for some use-cases than others. Because there are significantly more Java servers than Java simulations, and because servers are normally more complex (in terms of failure modes and architectural graph) and their developers are more mainstream and could benefit from more help, *if* there?s some prioritisation to be made, the server use-case is the one we prioritise over others by addressing it *first*. More people are interested in that use-case, that?s where virtual threads can contribute the most value, and that?s why it?s our *initial* focus. ? Ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From robin.bygrave at gmail.com Wed Jan 4 01:22:16 2023 From: robin.bygrave at gmail.com (Rob Bygrave) Date: Wed, 4 Jan 2023 14:22:16 +1300 Subject: Project Loom VirtualThreads hang In-Reply-To: References: Message-ID: FWIW, as I see it in the case of Nima http 1.1 server case with little to no fanout (which in my experience to date is the majority case) there can be relatively few (less than 200) relatively long lived virtual threads + virtual threads used for fanout requests. A lot fewer VTs that gets touted often here. Nima Http 1.1 case: 1 platform thread listens for new connections - lives for server lifetime. 1 virtual thread per connection - lives for the lifetime of http connection and handles all the requests/responses for that connection. This can be relatively long lived based on keepalive & client lifetime. If request/response processing requires NO fanout (no requests to other services) but request handling is instead just persisting to and from databases then that's it and Nima will have 1 VT per connection (and imo for many folks this will commonly be low *hundreds* depending on your server size - we are not all building services for twitter scale etc). The next common case is limited fanout meaning that a single request/response only incurs 1 or 2 fanout requests to other services (not order of magnitude or anything like this). In this scenario for example, a http 1.1 based service running with 200 concurrent connections is operating with up to 600 virtual threads at any given time. IMO I think it's going to be common for many "common folk services" to be running with less than 600 virtual threads at any given time. My now outdated testing using Jetty was designed to confirm that using *sub 200 VT in total* was still preferable to traditional 200 platform threads - to see if there was some inflexion point where we need to choose between VT and PT. Note that Nima might change to more a VT per request approach but that will not change the number of virtual threads running at any given time. Cheers, Rob. On Wed, 4 Jan 2023 at 11:23, Ron Pressler wrote: > > > On 3 Jan 2023, at 19:24, thurston N > wrote: > > Hello Ron, > > Quoting: > > "Virtual threads replace *short *individual *tasks* in your application, not platform threads." > > Why > > *short?* > > > > *Take a TCP server's accept loop. I would have thought that's a natural target for execution in a virtual thread. * > > > *And it's more or less intended to run forever.* > > > A small number of virtual threads may run for a long time, but the vast > majority would be short lived. They would naturally form a hierarchy: you?d > have one or a couple of threads accepting connections that live forever, > several thousand request-handling threads that live as long as a single > request, and then tens of thousands or more each servicing a single > outgoing service request in a fanout, and those would be even shorter-lived. > > > > * > "They are best thought of as a business logic entity representing a task rather than an ?execution resource.?"* > > > *That's a pretty good definition of an "actor" (as in actors-model). But there's no (even implicit) restriction on the duration of * > > > *an actor's lifetime.* > > *Is it your intent to proscribe virtual threads as a possible implementation for actor-model type designs?* > > > Threads are sequential task that is done concurrently with others. What > protocols are used to communicate among threads (and the actor model is a > communication protocol) is up to the programmer. An actor model is a bit > too high-level for the JDK, but libraries may certainly offer actors based > on virtual threads, just as others may build other high level constructs. > > > > *I'm thinking of simulations, e.g. modelling a migrating herd, bees at a honeycomb, a very busy traffic intersection, et al.* > > > *It seems natural (even elegant) to represent each of those entities (deer, bee, car) as a virtual thread, and executing them as a * > > > *platform thread isn't an option (because of their sheer number, the essence of the problem that virtual threads is the solution for)* > > > *And I'm sure there are innumerable other circumstances that could benefit from LWP (as Erlang terms them)* > > *IMO, it's awfully reductive to restrict practical uses of virtual threads to writing sequential single request/response scenarios > > * > > > My intent is not to restrict so much as to focus. Simulations are > absolutely a great use-case for lightweight threads, but there are > implementation choices that may need to balance some desirable properties > with others and could result in virtual threads being a better fit for some > use-cases than others. Because there are significantly more Java servers > than Java simulations, and because servers are normally more complex (in > terms of failure modes and architectural graph) and their developers are > more mainstream and could benefit from more help, *if* there?s some > prioritisation to be made, the server use-case is the one we prioritise > over others by addressing it *first*. More people are interested in that > use-case, that?s where virtual threads can contribute the most value, and > that?s why it?s our *initial* focus. > > ? Ron > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rengels at ix.netcom.com Wed Jan 4 04:59:35 2023 From: rengels at ix.netcom.com (robert engels) Date: Tue, 3 Jan 2023 22:59:35 -0600 Subject: Project Loom VirtualThreads hang In-Reply-To: References: Message-ID: <96631C23-9C63-4848-B310-C0521FB094E9@ix.netcom.com> For some further data points. Using VthreadTest here (essentially a message passing system): With 32 producers, 32 consumers, 500k messages on an 4/8 core machine: 1a. native threads w ABQ: 60-65% system cpu, 20% user cpu, 15-20% idle, total time 189 seconds 1b. vthreads w ABQ: 5-10% system cpu, 75% user cpu, 15% idle, total time 63 seconds 2a. native threads w RingBuffer, spin=1: 70% system cpu, 30% user cpu, 0% idle, total time 174 seconds 2b. vthreads w RingBuffer, spin=1: 13% system cpu, 85% user, 2% idle, total time 37 seconds 3a. native threads w RingBuffer, spin=32: 68% system cpu, 30% user cpu, 2% idle, total time 164 seconds 3b. vthreads w RingBuffer, spin=32: 13% system cpu, 85% user, 3% idle, total time 40 seconds (ABQ is stdlib ArrayBlockingQueue) The above times have a lot of variance which is not fully accounted for but the interesting thing is that the RingBuffer makes such a huge difference between 1 & 2. Even in 2b, there is 13% taken up by the OS - I assume due to thread switching as there is no IO in the test, which means the scheduling can probably be improved. I would expect a green thread system to approach 0% idle and 0% system utilization in this type of test. I am ?fairly cetain? the code should able to use all carrier threads 100%. Maybe the system % is going to something else? (You can use the SpinTest - comment out the println - and see that 100% cpu bound ?do nothing? test that allocates no objects still uses more than 25% system cpu - which seems odd). Here is a async profile capture of 3b: Notice that the vast majority of the time is used in internal context switching. I can ?fairly agree? with the project?s stated bias towards server systems with 1000?s of threads (I do think 1000?s of threads is enough vs. millions of threads), but I hope this can be addressed moving forward. I think the CSP (communicating sequential processes) model (close to Actor model) simplifies a lot of concurrent programming concerns but it requires highly efficient context switching and queues to work well. > On Jan 3, 2023, at 4:16 PM, Ron Pressler > wrote: > > > >> On 3 Jan 2023, at 19:24, thurston N > wrote: >> >> Hello Ron, >> >> Quoting: >> "Virtual threads replace short individual *tasks* in your application, not platform threads." >> >> Why short? >> >> Take a TCP server's accept loop. I would have thought that's a natural target for execution in a virtual thread. >> >> And it's more or less intended to run forever. > > A small number of virtual threads may run for a long time, but the vast majority would be short lived. They would naturally form a hierarchy: you?d have one or a couple of threads accepting connections that live forever, several thousand request-handling threads that live as long as a single request, and then tens of thousands or more each servicing a single outgoing service request in a fanout, and those would be even shorter-lived. >> >> "They are best thought of as a business logic entity representing a task rather than an ?execution resource.?" >> >> That's a pretty good definition of an "actor" (as in actors-model). But there's no (even implicit) restriction on the duration of >> an actor's lifetime. >> Is it your intent to proscribe virtual threads as a possible implementation for actor-model type designs? > > Threads are sequential task that is done concurrently with others. What protocols are used to communicate among threads (and the actor model is a communication protocol) is up to the programmer. An actor model is a bit too high-level for the JDK, but libraries may certainly offer actors based on virtual threads, just as others may build other high level constructs. >> >> I'm thinking of simulations, e.g. modelling a migrating herd, bees at a honeycomb, a very busy traffic intersection, et al. >> It seems natural (even elegant) to represent each of those entities (deer, bee, car) as a virtual thread, and executing them as a >> platform thread isn't an option (because of their sheer number, the essence of the problem that virtual threads is the solution for) >> And I'm sure there are innumerable other circumstances that could benefit from LWP (as Erlang terms them) >> IMO, it's awfully reductive to restrict practical uses of virtual threads to writing sequential single request/response scenarios >> > > My intent is not to restrict so much as to focus. Simulations are absolutely a great use-case for lightweight threads, but there are implementation choices that may need to balance some desirable properties with others and could result in virtual threads being a better fit for some use-cases than others. Because there are significantly more Java servers than Java simulations, and because servers are normally more complex (in terms of failure modes and architectural graph) and their developers are more mainstream and could benefit from more help, *if* there?s some prioritisation to be made, the server use-case is the one we prioritise over others by addressing it *first*. More people are interested in that use-case, that?s where virtual threads can contribute the most value, and that?s why it?s our *initial* focus. > > ? Ron -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: PastedGraphic-3.png Type: image/png Size: 289575 bytes Desc: not available URL: From ron.pressler at oracle.com Wed Jan 4 09:22:21 2023 From: ron.pressler at oracle.com (Ron Pressler) Date: Wed, 4 Jan 2023 09:22:21 +0000 Subject: [External] : Re: Project Loom VirtualThreads hang In-Reply-To: References: Message-ID: The main difference between virtual threads and platform threads is that you can have many more virtual threads. Their throughput impact is a result of their number, which allows a server to scale to higher throughputs, and fewer servers to serve the same workload. An application employing 200 virtual threads will not perform significantly better than one employing 200 platform threads (although it might have some convenience advantages, such as not sharing threads and not risking ThreadLocal leaks), and the number of servers required cannot drop from one to zero. Obviously, servers that never reach the workload that virtual threads exist to support will not benefit from the scalability they never use. ? Ron On 4 Jan 2023, at 01:22, Rob Bygrave > wrote: FWIW, as I see it in the case of Nima http 1.1 server case with little to no fanout (which in my experience to date is the majority case) there can be relatively few (less than 200) relatively long lived virtual threads + virtual threads used for fanout requests. A lot fewer VTs that gets touted often here. Nima Http 1.1 case: 1 platform thread listens for new connections - lives for server lifetime. 1 virtual thread per connection - lives for the lifetime of http connection and handles all the requests/responses for that connection. This can be relatively long lived based on keepalive & client lifetime. If request/response processing requires NO fanout (no requests to other services) but request handling is instead just persisting to and from databases then that's it and Nima will have 1 VT per connection (and imo for many folks this will commonly be low hundreds depending on your server size - we are not all building services for twitter scale etc). The next common case is limited fanout meaning that a single request/response only incurs 1 or 2 fanout requests to other services (not order of magnitude or anything like this). In this scenario for example, a http 1.1 based service running with 200 concurrent connections is operating with up to 600 virtual threads at any given time. IMO I think it's going to be common for many "common folk services" to be running with less than 600 virtual threads at any given time. My now outdated testing using Jetty was designed to confirm that using sub 200 VT in total was still preferable to traditional 200 platform threads - to see if there was some inflexion point where we need to choose between VT and PT. Note that Nima might change to more a VT per request approach but that will not change the number of virtual threads running at any given time. Cheers, Rob. On Wed, 4 Jan 2023 at 11:23, Ron Pressler > wrote: On 3 Jan 2023, at 19:24, thurston N > wrote: Hello Ron, Quoting: "Virtual threads replace short individual *tasks* in your application, not platform threads." Why short? Take a TCP server's accept loop. I would have thought that's a natural target for execution in a virtual thread. And it's more or less intended to run forever. A small number of virtual threads may run for a long time, but the vast majority would be short lived. They would naturally form a hierarchy: you?d have one or a couple of threads accepting connections that live forever, several thousand request-handling threads that live as long as a single request, and then tens of thousands or more each servicing a single outgoing service request in a fanout, and those would be even shorter-lived. "They are best thought of as a business logic entity representing a task rather than an ?execution resource.?" That's a pretty good definition of an "actor" (as in actors-model). But there's no (even implicit) restriction on the duration of an actor's lifetime. Is it your intent to proscribe virtual threads as a possible implementation for actor-model type designs? Threads are sequential task that is done concurrently with others. What protocols are used to communicate among threads (and the actor model is a communication protocol) is up to the programmer. An actor model is a bit too high-level for the JDK, but libraries may certainly offer actors based on virtual threads, just as others may build other high level constructs. I'm thinking of simulations, e.g. modelling a migrating herd, bees at a honeycomb, a very busy traffic intersection, et al. It seems natural (even elegant) to represent each of those entities (deer, bee, car) as a virtual thread, and executing them as a platform thread isn't an option (because of their sheer number, the essence of the problem that virtual threads is the solution for) And I'm sure there are innumerable other circumstances that could benefit from LWP (as Erlang terms them) IMO, it's awfully reductive to restrict practical uses of virtual threads to writing sequential single request/response scenarios My intent is not to restrict so much as to focus. Simulations are absolutely a great use-case for lightweight threads, but there are implementation choices that may need to balance some desirable properties with others and could result in virtual threads being a better fit for some use-cases than others. Because there are significantly more Java servers than Java simulations, and because servers are normally more complex (in terms of failure modes and architectural graph) and their developers are more mainstream and could benefit from more help, *if* there?s some prioritisation to be made, the server use-case is the one we prioritise over others by addressing it *first*. More people are interested in that use-case, that?s where virtual threads can contribute the most value, and that?s why it?s our *initial* focus. ? Ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Wed Jan 4 09:32:17 2023 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 4 Jan 2023 09:32:17 +0000 Subject: Project Loom VirtualThreads hang In-Reply-To: <96631C23-9C63-4848-B310-C0521FB094E9@ix.netcom.com> References: <96631C23-9C63-4848-B310-C0521FB094E9@ix.netcom.com> Message-ID: On 04/01/2023 04:59, robert engels wrote: > : > > Here is a async profile capture of 3b: > > > Notice that the vast majority of the time is used in internal context > switching. > I can't immediately tell if there is a Heisenberg effect here but the notifyJvmtiMountXXX methods suggest that the profiler has a JVMTI environment. There is work in progress to address scalability issues with JVMTI in exactly this area. In the mean-time, it would be useful if you could re-run the profiler with the test running with: -XX:+UnlockExperimentalVMOptions -XX:+DoJVMTIVirtualThreadTransitions -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: PastedGraphic-3.png Type: image/png Size: 289575 bytes Desc: not available URL: From ron.pressler at oracle.com Wed Jan 4 15:27:14 2023 From: ron.pressler at oracle.com (Ron Pressler) Date: Wed, 4 Jan 2023 15:27:14 +0000 Subject: [External] : Re: Project Loom VirtualThreads hang In-Reply-To: <96631C23-9C63-4848-B310-C0521FB094E9@ix.netcom.com> References: <96631C23-9C63-4848-B310-C0521FB094E9@ix.netcom.com> Message-ID: Thank you. To make your benchmark more interesting, I would suggest varying both the number of producers and consumers as well as the number of queues they contend over (e.g. 100,000 queues with 1 producer and 1 consumer each, 1000 queues with 100 producers and 100 consumers each etc.). This would also give you a sense of the kinds of benchmarks we?re using. BTW, the impact on throughput that context switching has on message passing systems is related to the ratio between the average context switching duration and the average wait-time between messages, i.e. context-switching needs to be efficient only to the point that it is significantly smaller than the wait-time between messages. Once it?s small enough *in comparison*, reducing it further has little impact (see calculation here: https://inside.java/2020/08/07/loom-performance/). ? Ron On 4 Jan 2023, at 04:59, robert engels > wrote: For some further data points. Using VthreadTest here (essentially a message passing system): With 32 producers, 32 consumers, 500k messages on an 4/8 core machine: 1a. native threads w ABQ: 60-65% system cpu, 20% user cpu, 15-20% idle, total time 189 seconds 1b. vthreads w ABQ: 5-10% system cpu, 75% user cpu, 15% idle, total time 63 seconds 2a. native threads w RingBuffer, spin=1: 70% system cpu, 30% user cpu, 0% idle, total time 174 seconds 2b. vthreads w RingBuffer, spin=1: 13% system cpu, 85% user, 2% idle, total time 37 seconds 3a. native threads w RingBuffer, spin=32: 68% system cpu, 30% user cpu, 2% idle, total time 164 seconds 3b. vthreads w RingBuffer, spin=32: 13% system cpu, 85% user, 3% idle, total time 40 seconds (ABQ is stdlib ArrayBlockingQueue) The above times have a lot of variance which is not fully accounted for but the interesting thing is that the RingBuffer makes such a huge difference between 1 & 2. Even in 2b, there is 13% taken up by the OS - I assume due to thread switching as there is no IO in the test, which means the scheduling can probably be improved. I would expect a green thread system to approach 0% idle and 0% system utilization in this type of test. I am ?fairly cetain? the code should able to use all carrier threads 100%. Maybe the system % is going to something else? (You can use the SpinTest - comment out the println - and see that 100% cpu bound ?do nothing? test that allocates no objects still uses more than 25% system cpu - which seems odd). Here is a async profile capture of 3b: Notice that the vast majority of the time is used in internal context switching. I can ?fairly agree? with the project?s stated bias towards server systems with 1000?s of threads (I do think 1000?s of threads is enough vs. millions of threads), but I hope this can be addressed moving forward. I think the CSP (communicating sequential processes) model (close to Actor model) simplifies a lot of concurrent programming concerns but it requires highly efficient context switching and queues to work well. -------------- next part -------------- An HTML attachment was scrubbed... URL: From forax at univ-mlv.fr Wed Jan 4 15:54:03 2023 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Wed, 4 Jan 2023 16:54:03 +0100 (CET) Subject: [External] : Re: StructuredTaskScope and Futures In-Reply-To: <5FBD5E84-6A71-41BB-8179-E5FF87E255B6@oracle.com> References: <1009113343.75754648.1672741919013.JavaMail.zimbra@u-pem.fr> <5FBD5E84-6A71-41BB-8179-E5FF87E255B6@oracle.com> Message-ID: <1526188641.77436768.1672847643264.JavaMail.zimbra@u-pem.fr> ----- Original Message ----- > From: "Ron Pressler" > To: "Remi Forax" > Cc: "loom-dev" > Sent: Tuesday, January 3, 2023 12:00:45 PM > Subject: Re: [External] : Re: StructuredTaskScope and Futures >> On 3 Jan 2023, at 10:31, Remi Forax wrote: >> >> ----- Original Message ----- >>> From: "Ron Pressler" >>> To: "loom-dev" >>> Sent: Tuesday, January 3, 2023 11:21:15 AM >>> Subject: StructuredTaskScope and Futures >> >>> Hi. >> >> Hi, >> happy new year, >> > > Happy new year! > >>> >>> A question to those of you who have been using StructuredTaskScope: Have you >>> ever used any method on the Future returned from fork other than resultNow and, >>> if so, when/why? >> >> state() to know the result/cancellation/error and exceptionNow() to >> propagate/log the error messages. >> > > > When do you need to know the state or exception on an individual task rather > than rely on the policy to handle errors collectively before processing > successful results? If you have a code example that would be helpful. because you may want to log the suppressed exceptions. Let say you use a ShutdownOnSuccess, even if you get a result, you still want to log all the exceptions that occurs before the result because some exceptions are triggered by an issue that should be fixed (an invalid auth key, an expired token, etc) which shows that even if it works, something had gone wrong. Conceptually, we are looking at abstracting a loop over async calls, a shutdown on success is equivalent to a short-circuit of the loop. Each call returns Result | Exception. So all calls are a (Result1 | Exception1) x (Result2 | Exception2) x ... If you reduce it, you get a Result x Exception. > > ? Ron R?mi From ron.pressler at oracle.com Wed Jan 4 16:06:56 2023 From: ron.pressler at oracle.com (Ron Pressler) Date: Wed, 4 Jan 2023 16:06:56 +0000 Subject: [External] : Re: Project Loom VirtualThreads hang In-Reply-To: References: <96631C23-9C63-4848-B310-C0521FB094E9@ix.netcom.com> Message-ID: P.S. To explain my hint about benchmarking with many queues, let me say that often what makes the scheduler work harder is not the context-switching itself but finding a task (in this case, a runnable thread) to run. When the amount of contention is very high compared to the total number of threads, this may be hard and require expensive inter-core chatter. But in more realistic workloads, the level of contention is significantly lower than the total number of threads, so it?s easier for the scheduler to find a thread to schedule. I.e. in common conditions with, say, 50,000 threads, they will not all be contending for the same data structure, but small groups of them may be contending over multiple data structures, and there will be sufficiently many runnable threads to keep the scheduler from working hard to find things to run on other cores? queues. On 4 Jan 2023, at 15:27, Ron Pressler > wrote: Thank you. To make your benchmark more interesting, I would suggest varying both the number of producers and consumers as well as the number of queues they contend over (e.g. 100,000 queues with 1 producer and 1 consumer each, 1000 queues with 100 producers and 100 consumers each etc.). This would also give you a sense of the kinds of benchmarks we?re using. BTW, the impact on throughput that context switching has on message passing systems is related to the ratio between the average context switching duration and the average wait-time between messages, i.e. context-switching needs to be efficient only to the point that it is significantly smaller than the wait-time between messages. Once it?s small enough *in comparison*, reducing it further has little impact (see calculation here: https://inside.java/2020/08/07/loom-performance/). ? Ron On 4 Jan 2023, at 04:59, robert engels > wrote: For some further data points. Using VthreadTest here (essentially a message passing system): With 32 producers, 32 consumers, 500k messages on an 4/8 core machine: 1a. native threads w ABQ: 60-65% system cpu, 20% user cpu, 15-20% idle, total time 189 seconds 1b. vthreads w ABQ: 5-10% system cpu, 75% user cpu, 15% idle, total time 63 seconds 2a. native threads w RingBuffer, spin=1: 70% system cpu, 30% user cpu, 0% idle, total time 174 seconds 2b. vthreads w RingBuffer, spin=1: 13% system cpu, 85% user, 2% idle, total time 37 seconds 3a. native threads w RingBuffer, spin=32: 68% system cpu, 30% user cpu, 2% idle, total time 164 seconds 3b. vthreads w RingBuffer, spin=32: 13% system cpu, 85% user, 3% idle, total time 40 seconds (ABQ is stdlib ArrayBlockingQueue) The above times have a lot of variance which is not fully accounted for but the interesting thing is that the RingBuffer makes such a huge difference between 1 & 2. Even in 2b, there is 13% taken up by the OS - I assume due to thread switching as there is no IO in the test, which means the scheduling can probably be improved. I would expect a green thread system to approach 0% idle and 0% system utilization in this type of test. I am ?fairly cetain? the code should able to use all carrier threads 100%. Maybe the system % is going to something else? (You can use the SpinTest - comment out the println - and see that 100% cpu bound ?do nothing? test that allocates no objects still uses more than 25% system cpu - which seems odd). Here is a async profile capture of 3b: Notice that the vast majority of the time is used in internal context switching. I can ?fairly agree? with the project?s stated bias towards server systems with 1000?s of threads (I do think 1000?s of threads is enough vs. millions of threads), but I hope this can be addressed moving forward. I think the CSP (communicating sequential processes) model (close to Actor model) simplifies a lot of concurrent programming concerns but it requires highly efficient context switching and queues to work well. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron.pressler at oracle.com Wed Jan 4 16:17:24 2023 From: ron.pressler at oracle.com (Ron Pressler) Date: Wed, 4 Jan 2023 16:17:24 +0000 Subject: [External] : Re: StructuredTaskScope and Futures In-Reply-To: <1526188641.77436768.1672847643264.JavaMail.zimbra@u-pem.fr> References: <1009113343.75754648.1672741919013.JavaMail.zimbra@u-pem.fr> <5FBD5E84-6A71-41BB-8179-E5FF87E255B6@oracle.com> <1526188641.77436768.1672847643264.JavaMail.zimbra@u-pem.fr> Message-ID: <1FF55B57-DB86-4C62-B454-F3A62813CB0A@oracle.com> On 4 Jan 2023, at 15:54, forax at univ-mlv.fr wrote: ----- Original Message ----- From: "Ron Pressler" > To: "Remi Forax" > Cc: "loom-dev" > Sent: Tuesday, January 3, 2023 12:00:45 PM Subject: Re: [External] : Re: StructuredTaskScope and Futures When do you need to know the state or exception on an individual task rather than rely on the policy to handle errors collectively before processing successful results? If you have a code example that would be helpful. because you may want to log the suppressed exceptions. Let say you use a ShutdownOnSuccess, even if you get a result, you still want to log all the exceptions that occurs before the result because some exceptions are triggered by an issue that should be fixed (an invalid auth key, an expired token, etc) which shows that even if it works, something had gone wrong. Conceptually, we are looking at abstracting a loop over async calls, a shutdown on success is equivalent to a short-circuit of the loop. Each call returns Result | Exception. So all calls are a (Result1 | Exception1) x (Result2 | Exception2) x ... If you reduce it, you get a Result x Exception. Then let me give you a hard time and ask you two follow ups: 1. In the case where no real failures are encountered, when ShutdownOnSuccess completes, you?d expect to see one successful result and (say) nine cancelled forks (or, equivalently, forks that throw InterruptedException). Even when some forks could have actually failed, whether you?ll see a real failure or a cancellation (/InterruptedException) is entirely up to chance. So how useful is it to see the exceptions? 2. If the purpose is just logging, wouldn?t it be more helpful if, upon failure, the policy would add all the exceptions as suppressed exceptions to the one it throws? Moreover, if you want to log an exception associated with each specific fork, the forks could log it themselves. The reason I?m asking this question in the first place is that I?d like to consider having fork return a Supplier rather than a Future, as that API is not only significantly simpler, but more clearly directs the user toward the right thing to do (as there?s only one thing they *can* do). If getting specific exceptions is useful in a *small* number of cases, this can be solved with a simple indirection: have the task itself be a Callable> that returns a completed Future, and so fork would return Supplier>. If, on the other hand, having access to a richer Future object is useful in *many* situations, then we?ll keep things as they are, but that?s what I?m trying to ascertain. ? Ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From flow at cs.fau.de Wed Jan 4 16:48:54 2023 From: flow at cs.fau.de (Florian Schmaus) Date: Wed, 4 Jan 2023 17:48:54 +0100 Subject: [External] : Re: StructuredTaskScope and Futures In-Reply-To: <1FF55B57-DB86-4C62-B454-F3A62813CB0A@oracle.com> References: <1009113343.75754648.1672741919013.JavaMail.zimbra@u-pem.fr> <5FBD5E84-6A71-41BB-8179-E5FF87E255B6@oracle.com> <1526188641.77436768.1672847643264.JavaMail.zimbra@u-pem.fr> <1FF55B57-DB86-4C62-B454-F3A62813CB0A@oracle.com> Message-ID: On 04/01/2023 17.17, Ron Pressler wrote: >> On 4 Jan 2023, at 15:54, forax at univ-mlv.fr >> wrote: >> Each call returns Result | Exception. >> So all calls are a (Result1 | Exception1) x (Result2 | Exception2) x ... >> If you reduce it, you get a Result x Exception. I always wondered if it would be helpful if StructuredTaskScope had List results() List exceptions() As Remi wrote, it is sometimes useful to inspect the failure cases, e.g., to check if it was a sporadic or persistent failure. Similar, it is sometimes good to have access to all results. For example to fall back to other results in case a result is not usable. > If, on the other hand, having > access to a richer Future object is useful in *many* situations, then > we?ll keep things as they are, but that?s what I?m trying to ascertain. I don't feel like I have enough experience from my experiments with Loom and its API to answer that. But couldn't fork() return a superclass of Future? This would allow the API to change in a backwards-compatible way in case a reason to return Future is discovered. - Florian From rengels at ix.netcom.com Wed Jan 4 16:53:14 2023 From: rengels at ix.netcom.com (Robert Engels) Date: Wed, 4 Jan 2023 10:53:14 -0600 Subject: [External] : Re: StructuredTaskScope and Futures In-Reply-To: References: Message-ID: I think an exception without the request is harder to use - you have to reassemble. Easier to return a List where some results might be failures with exceptions. > On Jan 4, 2023, at 10:49 AM, Florian Schmaus wrote: > > ?On 04/01/2023 17.17, Ron Pressler wrote: >>>> On 4 Jan 2023, at 15:54, forax at univ-mlv.fr wrote: >>> Each call returns Result | Exception. >>> So all calls are a (Result1 | Exception1) x (Result2 | Exception2) x ... >>> If you reduce it, you get a Result x Exception. > > I always wondered if it would be helpful if StructuredTaskScope had > > List results() > List exceptions() > > As Remi wrote, it is sometimes useful to inspect the failure cases, e.g., to check if it was a sporadic or persistent failure. Similar, it is sometimes good to have access to all results. For example to fall back to other results in case a result is not usable. > > >> If, on the other hand, having access to a richer Future object is useful in *many* situations, then we?ll keep things as they are, but that?s what I?m trying to ascertain. > > I don't feel like I have enough experience from my experiments with Loom and its API to answer that. > > But couldn't fork() return a superclass of Future? This would allow the API to change in a backwards-compatible way in case a reason to return Future is discovered. > > - Florian From forax at univ-mlv.fr Wed Jan 4 16:57:31 2023 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Wed, 4 Jan 2023 17:57:31 +0100 (CET) Subject: [External] : Re: StructuredTaskScope and Futures In-Reply-To: <1FF55B57-DB86-4C62-B454-F3A62813CB0A@oracle.com> References: <1009113343.75754648.1672741919013.JavaMail.zimbra@u-pem.fr> <5FBD5E84-6A71-41BB-8179-E5FF87E255B6@oracle.com> <1526188641.77436768.1672847643264.JavaMail.zimbra@u-pem.fr> <1FF55B57-DB86-4C62-B454-F3A62813CB0A@oracle.com> Message-ID: <538344709.77477288.1672851451955.JavaMail.zimbra@u-pem.fr> > From: "Ron Pressler" > To: "Remi Forax" > Cc: "loom-dev" > Sent: Wednesday, January 4, 2023 5:17:24 PM > Subject: Re: [External] : Re: StructuredTaskScope and Futures >> On 4 Jan 2023, at 15:54, [ mailto:forax at univ-mlv.fr | >> forax at univ-mlv.fr ] wrote: >> ----- Original Message ----- >>> From: "Ron Pressler" < [ mailto:ron.pressler at oracle.com | >>> ron.pressler at oracle.com ] > >>> To: "Remi Forax" < [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ] > >>> Cc: "loom-dev" < [ mailto:loom-dev at openjdk.org | loom-dev at openjdk.org ] > >>> Sent: Tuesday, January 3, 2023 12:00:45 PM >>> Subject: Re: [External] : Re: StructuredTaskScope and Futures >>> When do you need to know the state or exception on an individual task rather >>> than rely on the policy to handle errors collectively before processing >>> successful results? If you have a code example that would be helpful. >> because you may want to log the suppressed exceptions. >> Let say you use a ShutdownOnSuccess, even if you get a result, you still want to >> log all the exceptions that occurs before the result because some exceptions >> are triggered by an issue that should be fixed (an invalid auth key, an expired >> token, etc) which shows that even if it works, something had gone wrong. >> Conceptually, we are looking at abstracting a loop over async calls, a shutdown >> on success is equivalent to a short-circuit of the loop. >> Each call returns Result | Exception. >> So all calls are a (Result1 | Exception1) x (Result2 | Exception2) x ... >> If you reduce it, you get a Result x Exception. > Then let me give you a hard time and ask you two follow ups: > 1. In the case where no real failures are encountered, when ShutdownOnSuccess > completes, you?d expect to see one successful result and (say) nine cancelled > forks (or, equivalently, forks that throw InterruptedException). Even when some > forks could have actually failed, whether you?ll see a real failure or a > cancellation (/InterruptedException) is entirely up to chance. So how useful is > it to see the exceptions? I think we are starting to drift from the original question here but yes, some task failures are hidden by the fact that the chosen semantics is ShutdownOnSuccess or if you have a timeout. Anyway, that does not make the exceptions that happen before less valuable. > 2. If the purpose is just logging, wouldn?t it be more helpful if, upon failure, > the policy would add all the exceptions as suppressed exceptions to the one it > throws? Moreover, if you want to log an exception associated with each specific > fork, the forks could log it themselves. Those suppressed exceptions are interesting, independently of the success of the computation. If each fork logs itself, you make the monitoring work harder because you are loosing the information that the errors are part of the same computation. > The reason I?m asking this question in the first place is that I?d like to > consider having fork return a Supplier rather than a Future, as that API > is not only significantly simpler, but more clearly directs the user toward the > right thing to do (as there?s only one thing they *can* do). If getting > specific exceptions is useful in a *small* number of cases, this can be solved > with a simple indirection: have the task itself be a Callable> that > returns a completed Future, and so fork would return Supplier>. If, > on the other hand, having access to a richer Future object is useful in *many* > situations, then we?ll keep things as they are, but that?s what I?m trying to > ascertain. I do not see how the indirection can work given that the Future object returned by fork() is specific to a StructuredTaskScope ? I see how this can be done by inheriting from StructuredTaskScope, but you have to be a concurrency expert to do that given that the callback (handleComplete) is called by each virtual threads. > ? Ron R?mi -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Wed Jan 4 17:03:36 2023 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 4 Jan 2023 17:03:36 +0000 Subject: [External] : Re: StructuredTaskScope and Futures In-Reply-To: References: <1009113343.75754648.1672741919013.JavaMail.zimbra@u-pem.fr> <5FBD5E84-6A71-41BB-8179-E5FF87E255B6@oracle.com> <1526188641.77436768.1672847643264.JavaMail.zimbra@u-pem.fr> <1FF55B57-DB86-4C62-B454-F3A62813CB0A@oracle.com> Message-ID: <4ccb11e6-4719-da59-ead2-ed9d673aeeca@oracle.com> On 04/01/2023 16:48, Florian Schmaus wrote: > > I always wondered if it would be helpful if StructuredTaskScope had > > List results() > List exceptions() > > As Remi wrote, it is sometimes useful to inspect the failure cases, > e.g., to check if it was a sporadic or persistent failure. Similar, it > is sometimes good to have access to all results. For example to fall > back to other results in case a result is not usable. The intention with StructuredTaskScope is that the API defines a small number of subclasses that implement common policies and for it to be easy to extend to implement whatever collection or policy is appropriate. The subclass is meant to define the methods that make available the results or other outcome. The "Extending StructuredTaskScope" section in the class description has an example that collects all results, and a method to get the results as a stream. Once we get more experience and feedback in this area then it might be that the two "built-in" policies that aren't the best but for now I think it should be easy to implement other policies. Just to put more context on this discussion - the issue with fork returning Future is the temptation to call Future::get and wait for the result whereas the intention with this API is to wait in StructuredTaskScope::join and then process the results or outcome. -Alan. From rengels at ix.netcom.com Wed Jan 4 17:19:56 2023 From: rengels at ix.netcom.com (Robert Engels) Date: Wed, 4 Jan 2023 11:19:56 -0600 Subject: [External] : Re: Project Loom VirtualThreads hang In-Reply-To: References: Message-ID: To clarify, this is not a contrived test. This is a reproduction of a real world system. With vthreads it is more efficient to remove the intermediate queues and have the producers ?write through? into the consumers network connection. This isn?t ideal as a slow consumer can block everyone - intermediary queues isolate that problem (to a degree - the queue can still backup). The alternative is to set a write timeout and drop the consumer if it triggers. > On Jan 4, 2023, at 10:07 AM, Ron Pressler wrote: > > ? P.S. > > To explain my hint about benchmarking with many queues, let me say that often what makes the scheduler work harder is not the context-switching itself but finding a task (in this case, a runnable thread) to run. When the amount of contention is very high compared to the total number of threads, this may be hard and require expensive inter-core chatter. But in more realistic workloads, the level of contention is significantly lower than the total number of threads, so it?s easier for the scheduler to find a thread to schedule. I.e. in common conditions with, say, 50,000 threads, they will not all be contending for the same data structure, but small groups of them may be contending over multiple data structures, and there will be sufficiently many runnable threads to keep the scheduler from working hard to find things to run on other cores? queues. > >>> On 4 Jan 2023, at 15:27, Ron Pressler wrote: >>> >>> Thank you. >>> >>> To make your benchmark more interesting, I would suggest varying both the number of producers and consumers as well as the number of queues they contend over (e.g. 100,000 queues with 1 producer and 1 consumer each, 1000 queues with 100 producers and 100 consumers each etc.). This would also give you a sense of the kinds of benchmarks we?re using. >>> >>> BTW, the impact on throughput that context switching has on message passing systems is related to the ratio between the average context switching duration and the average wait-time between messages, i.e. context-switching needs to be efficient only to the point that it is significantly smaller than the wait-time between messages. Once it?s small enough *in comparison*, reducing it further has little impact (see calculation here: https://inside.java/2020/08/07/loom-performance/). >>> >>> ? Ron >>> >>> On 4 Jan 2023, at 04:59, robert engels wrote: >>> >>> For some further data points. Using VthreadTest here (essentially a message passing system): >>> >>> With 32 producers, 32 consumers, 500k messages on an 4/8 core machine: >>> >>> 1a. native threads w ABQ: 60-65% system cpu, 20% user cpu, 15-20% idle, total time 189 seconds >>> 1b. vthreads w ABQ: 5-10% system cpu, 75% user cpu, 15% idle, total time 63 seconds >>> 2a. native threads w RingBuffer, spin=1: 70% system cpu, 30% user cpu, 0% idle, total time 174 seconds >>> 2b. vthreads w RingBuffer, spin=1: 13% system cpu, 85% user, 2% idle, total time 37 seconds >>> 3a. native threads w RingBuffer, spin=32: 68% system cpu, 30% user cpu, 2% idle, total time 164 seconds >>> 3b. vthreads w RingBuffer, spin=32: 13% system cpu, 85% user, 3% idle, total time 40 seconds >>> >>> (ABQ is stdlib ArrayBlockingQueue) >>> >>> The above times have a lot of variance which is not fully accounted for but the interesting thing is that the RingBuffer makes such a huge difference between 1 & 2. >>> >>> Even in 2b, there is 13% taken up by the OS - I assume due to thread switching as there is no IO in the test, which means the scheduling can probably be improved. >>> >>> I would expect a green thread system to approach 0% idle and 0% system utilization in this type of test. I am ?fairly cetain? the code should able to use all carrier threads 100%. Maybe the system % is going to something else? (You can use the SpinTest - comment out the println - and see that 100% cpu bound ?do nothing? test that allocates no objects still uses more than 25% system cpu - which seems odd). >>> >>> Here is a async profile capture of 3b: >>> >>> >>> >>> Notice that the vast majority of the time is used in internal context switching. >>> >>> I can ?fairly agree? with the project?s stated bias towards server systems with 1000?s of threads (I do think 1000?s of threads is enough vs. millions of threads), but I hope this can be addressed moving forward. I think the CSP (communicating sequential processes) model (close to Actor model) simplifies a lot of concurrent programming concerns but it requires highly efficient context switching and queues to work well. >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nigro.fra at gmail.com Wed Jan 4 17:31:19 2023 From: nigro.fra at gmail.com (Francesco Nigro) Date: Wed, 4 Jan 2023 18:31:19 +0100 Subject: [External] : Re: Project Loom VirtualThreads hang In-Reply-To: References: Message-ID: > With vthreads it is more efficient to remove the intermediate queues and have the producers ?write through? into the consumers network connection. Such producers are using "blocking" connections? If yes, beware congested network use case and lack of batching + congested networks: - if they batch, they will amortize syscalls but, if the network is congested, they will likely be descheduled by Loom while still holding the allocated buffer reference (that cannot be used by others): with many of them it can easily cause OOM (or worse!) - if they are not batching and using small buffers, they will die due to syscall costs/SOFT IRQs and underutilizing the network (already congested) The first case, to return OT, is what concern me a bit about using batching with Loom (and no, application level flow control mechanisms won't help with congested networks :/) Il giorno mer 4 gen 2023 alle ore 18:23 Robert Engels ha scritto: > To clarify, this is not a contrived test. This is a reproduction of a real > world system. With vthreads it is more efficient to remove the intermediate > queues and have the producers ?write through? into the consumers network > connection. > > This isn?t ideal as a slow consumer can block everyone - intermediary > queues isolate that problem (to a degree - the queue can still backup). The > alternative is to set a write timeout and drop the consumer if it triggers. > > On Jan 4, 2023, at 10:07 AM, Ron Pressler wrote: > > ? P.S. > > To explain my hint about benchmarking with many queues, let me say that > often what makes the scheduler work harder is not the context-switching > itself but finding a task (in this case, a runnable thread) to run. When > the amount of contention is very high compared to the total number of > threads, this may be hard and require expensive inter-core chatter. But in > more realistic workloads, the level of contention is significantly lower > than the total number of threads, so it?s easier for the scheduler to find > a thread to schedule. I.e. in common conditions with, say, 50,000 threads, > they will not all be contending for the same data structure, but small > groups of them may be contending over multiple data structures, and there > will be sufficiently many runnable threads to keep the scheduler from > working hard to find things to run on other cores? queues. > > On 4 Jan 2023, at 15:27, Ron Pressler wrote: > > Thank you. > > To make your benchmark more interesting, I would suggest varying both the > number of producers and consumers as well as the number of queues they > contend over (e.g. 100,000 queues with 1 producer and 1 consumer each, 1000 > queues with 100 producers and 100 consumers each etc.). This would also > give you a sense of the kinds of benchmarks we?re using. > > BTW, the impact on throughput that context switching has on message > passing systems is related to the ratio between the average context > switching duration and the average wait-time between messages, i.e. > context-switching needs to be efficient only to the point that it is > significantly smaller than the wait-time between messages. Once it?s small > enough *in comparison*, reducing it further has little impact (see > calculation here: https://inside.java/2020/08/07/loom-performance/). > > ? Ron > > On 4 Jan 2023, at 04:59, robert engels wrote: > > For some further data points. Using VthreadTest here > (essentially > a message passing system): > > With 32 producers, 32 consumers, 500k messages on an 4/8 core machine: > > 1a. native threads w ABQ: 60-65% system cpu, 20% user cpu, 15-20% idle, > total time 189 seconds > 1b. vthreads w ABQ: 5-10% system cpu, 75% user cpu, 15% idle, total time > 63 seconds > 2a. native threads w RingBuffer, spin=1: 70% system cpu, 30% user cpu, 0% > idle, total time 174 seconds > 2b. vthreads w RingBuffer, spin=1: 13% system cpu, 85% user, 2% idle, > total time 37 seconds > 3a. native threads w RingBuffer, spin=32: 68% system cpu, 30% user cpu, 2% > idle, total time 164 seconds > 3b. vthreads w RingBuffer, spin=32: 13% system cpu, 85% user, 3% idle, > total time 40 seconds > > (ABQ is stdlib ArrayBlockingQueue) > > The above times have a lot of variance which is not fully accounted for > but the interesting thing is that the RingBuffer makes such a huge > difference between 1 & 2. > > Even in 2b, there is 13% taken up by the OS - I assume due to thread > switching as there is no IO in the test, which means the scheduling can > probably be improved. > > I would expect a green thread system to approach 0% idle and 0% system > utilization in this type of test. I am ?fairly cetain? the code should able > to use all carrier threads 100%. Maybe the system % is going to something > else? (You can use the SpinTest - comment out the println - and see that > 100% cpu bound ?do nothing? test that allocates no objects still uses more > than 25% system cpu - which seems odd). > > Here is a async profile capture of 3b: > > > > Notice that the vast majority of the time is used in internal context > switching. > > I can ?fairly agree? with the project?s stated bias towards server systems > with 1000?s of threads (I do think 1000?s of threads is enough vs. millions > of threads), but I hope this can be addressed moving forward. I think the > CSP (communicating sequential processes) model (close to Actor model) > simplifies a lot of concurrent programming concerns but it requires highly > efficient context switching and queues to work well. > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron.pressler at oracle.com Wed Jan 4 17:36:33 2023 From: ron.pressler at oracle.com (Ron Pressler) Date: Wed, 4 Jan 2023 17:36:33 +0000 Subject: [External] : Re: Project Loom VirtualThreads hang In-Reply-To: References: Message-ID: <8288D3F9-7FA1-4AB0-B69F-6C8FA17D2FB5@oracle.com> Sure, but virtual threads are intended to be used when you have lots of threads (with low contention relative to their total number), so an interesting benchmark is one that tries to create such an intended scenario. Note that in the CSP/actor paradigms are also primarily designed for cases with a very large number of channels/mailboxes as well as processes/actors, also with relatively low contention. Rather, your benchmark is more similar to SEDA (where you have a relatively small number of threads and queues), which is a very useful architecture, but ? unlike CSP and actors that are a great fit for virtual threads ? not virtual threads? primary focus. Again, that is not to say that someone might not want to use virtual threads for other reasons, but because those use-cases cannot provide as much of a performance boost as the many-thread scenario and because they?re less common, they?re not our current main focus. We?d like to first optimise virtual threads for thread-per-request servers, as well as (I/O-driven) CSP/actors, and only later for other uses because those uses are more common and because virtual threads can enhance their throughput more significantly. ? Ron On 4 Jan 2023, at 17:19, Robert Engels > wrote: To clarify, this is not a contrived test. This is a reproduction of a real world system. With vthreads it is more efficient to remove the intermediate queues and have the producers ?write through? into the consumers network connection. This isn?t ideal as a slow consumer can block everyone - intermediary queues isolate that problem (to a degree - the queue can still backup). The alternative is to set a write timeout and drop the consumer if it triggers. On Jan 4, 2023, at 10:07 AM, Ron Pressler > wrote: ? P.S. To explain my hint about benchmarking with many queues, let me say that often what makes the scheduler work harder is not the context-switching itself but finding a task (in this case, a runnable thread) to run. When the amount of contention is very high compared to the total number of threads, this may be hard and require expensive inter-core chatter. But in more realistic workloads, the level of contention is significantly lower than the total number of threads, so it?s easier for the scheduler to find a thread to schedule. I.e. in common conditions with, say, 50,000 threads, they will not all be contending for the same data structure, but small groups of them may be contending over multiple data structures, and there will be sufficiently many runnable threads to keep the scheduler from working hard to find things to run on other cores? queues. On 4 Jan 2023, at 15:27, Ron Pressler > wrote: Thank you. To make your benchmark more interesting, I would suggest varying both the number of producers and consumers as well as the number of queues they contend over (e.g. 100,000 queues with 1 producer and 1 consumer each, 1000 queues with 100 producers and 100 consumers each etc.). This would also give you a sense of the kinds of benchmarks we?re using. BTW, the impact on throughput that context switching has on message passing systems is related to the ratio between the average context switching duration and the average wait-time between messages, i.e. context-switching needs to be efficient only to the point that it is significantly smaller than the wait-time between messages. Once it?s small enough *in comparison*, reducing it further has little impact (see calculation here: https://inside.java/2020/08/07/loom-performance/). ? Ron On 4 Jan 2023, at 04:59, robert engels > wrote: For some further data points. Using VthreadTest here (essentially a message passing system): With 32 producers, 32 consumers, 500k messages on an 4/8 core machine: 1a. native threads w ABQ: 60-65% system cpu, 20% user cpu, 15-20% idle, total time 189 seconds 1b. vthreads w ABQ: 5-10% system cpu, 75% user cpu, 15% idle, total time 63 seconds 2a. native threads w RingBuffer, spin=1: 70% system cpu, 30% user cpu, 0% idle, total time 174 seconds 2b. vthreads w RingBuffer, spin=1: 13% system cpu, 85% user, 2% idle, total time 37 seconds 3a. native threads w RingBuffer, spin=32: 68% system cpu, 30% user cpu, 2% idle, total time 164 seconds 3b. vthreads w RingBuffer, spin=32: 13% system cpu, 85% user, 3% idle, total time 40 seconds (ABQ is stdlib ArrayBlockingQueue) The above times have a lot of variance which is not fully accounted for but the interesting thing is that the RingBuffer makes such a huge difference between 1 & 2. Even in 2b, there is 13% taken up by the OS - I assume due to thread switching as there is no IO in the test, which means the scheduling can probably be improved. I would expect a green thread system to approach 0% idle and 0% system utilization in this type of test. I am ?fairly cetain? the code should able to use all carrier threads 100%. Maybe the system % is going to something else? (You can use the SpinTest - comment out the println - and see that 100% cpu bound ?do nothing? test that allocates no objects still uses more than 25% system cpu - which seems odd). Here is a async profile capture of 3b: Notice that the vast majority of the time is used in internal context switching. I can ?fairly agree? with the project?s stated bias towards server systems with 1000?s of threads (I do think 1000?s of threads is enough vs. millions of threads), but I hope this can be addressed moving forward. I think the CSP (communicating sequential processes) model (close to Actor model) simplifies a lot of concurrent programming concerns but it requires highly efficient context switching and queues to work well. -------------- next part -------------- An HTML attachment was scrubbed... URL: From forax at univ-mlv.fr Wed Jan 4 17:38:41 2023 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 4 Jan 2023 18:38:41 +0100 (CET) Subject: [External] : Re: StructuredTaskScope and Futures In-Reply-To: <4ccb11e6-4719-da59-ead2-ed9d673aeeca@oracle.com> References: <1009113343.75754648.1672741919013.JavaMail.zimbra@u-pem.fr> <5FBD5E84-6A71-41BB-8179-E5FF87E255B6@oracle.com> <1526188641.77436768.1672847643264.JavaMail.zimbra@u-pem.fr> <1FF55B57-DB86-4C62-B454-F3A62813CB0A@oracle.com> <4ccb11e6-4719-da59-ead2-ed9d673aeeca@oracle.com> Message-ID: <492134113.77493872.1672853921606.JavaMail.zimbra@u-pem.fr> ----- Original Message ----- > From: "Alan Bateman" > To: "Florian Schmaus" , "loom-dev" > Sent: Wednesday, January 4, 2023 6:03:36 PM > Subject: Re: [External] : Re: StructuredTaskScope and Futures > On 04/01/2023 16:48, Florian Schmaus wrote: >> >> I always wondered if it would be helpful if StructuredTaskScope had >> >> List results() >> List exceptions() >> >> As Remi wrote, it is sometimes useful to inspect the failure cases, >> e.g., to check if it was a sporadic or persistent failure. Similar, it >> is sometimes good to have access to all results. For example to fall >> back to other results in case a result is not usable. > > The intention with StructuredTaskScope is that the API defines a small > number of subclasses that implement common policies and for it to be > easy to extend to implement whatever collection or policy is > appropriate. The subclass is meant to define the methods that make > available the results or other outcome. The "Extending > StructuredTaskScope" section in the class description has an example > that collects all results, and a method to get the results as a stream. > Once we get more experience and feedback in this area then it might be > that the two "built-in" policies that aren't the best but for now I > think it should be easy to implement other policies. > > Just to put more context on this discussion - the issue with fork > returning Future is the temptation to call Future::get and wait for the > result whereas the intention with this API is to wait in > StructuredTaskScope::join and then process the results or outcome. so Future has too many methods, but a Supplier has too few. It looks like we want either a supertype of Future or a Future that throws an ISE if get() is called. > > -Alan. R?mi From flow at cs.fau.de Wed Jan 4 18:08:41 2023 From: flow at cs.fau.de (Florian Schmaus) Date: Wed, 4 Jan 2023 19:08:41 +0100 Subject: [External] : Re: StructuredTaskScope and Futures In-Reply-To: <4ccb11e6-4719-da59-ead2-ed9d673aeeca@oracle.com> References: <1009113343.75754648.1672741919013.JavaMail.zimbra@u-pem.fr> <5FBD5E84-6A71-41BB-8179-E5FF87E255B6@oracle.com> <1526188641.77436768.1672847643264.JavaMail.zimbra@u-pem.fr> <1FF55B57-DB86-4C62-B454-F3A62813CB0A@oracle.com> <4ccb11e6-4719-da59-ead2-ed9d673aeeca@oracle.com> Message-ID: <3f85cc7e-f124-d40a-4b6b-0a20f56140f6@cs.fau.de> On 04/01/2023 18.03, Alan Bateman wrote: > On 04/01/2023 16:48, Florian Schmaus wrote: >> I always wondered if it would be helpful if StructuredTaskScope had >> >> List results() >> List exceptions() >> >> As Remi wrote, it is sometimes useful to inspect the failure cases, >> e.g., to check if it was a sporadic or persistent failure. Similar, it >> is sometimes good to have access to all results. For example to fall >> back to other results in case a result is not usable. > > The intention with StructuredTaskScope is that the API defines a small > number of subclasses that implement common policies and for it to be > easy to extend to implement whatever collection or policy is > appropriate. The subclass is meant to define the methods that make > available the results or other outcome. The "Extending > StructuredTaskScope" section in the class description has an example > that collects all results, and a method to get the results as a stream. > Once we get more experience and feedback in this area then it might be > that the two "built-in" policies that aren't the best but for now I > think it should be easy to implement other policies. Agreed, it later occurred to me that this can be easily implemented by a subclass of StructedTaskScope. And, as you wrote, it may be sensible to ship those implementations with the runtime library one day. > Just to put more context on this discussion - the issue with fork > returning Future is the temptation to call Future::get and wait for the > result whereas the intention with this API is to wait in > StructuredTaskScope::join and then process the results or outcome. If Future is replaced with Supplier, then you still have a get() method to call, right? So the temptation is still there (even if arguably in a weaker form). I am also not sure how one should map the 'throws' declarations of Future::get() to Supplier. Which leads to me ponder if it wouldn't be better if StructuredTaskScope would orientate more on Cilk-ish semantic. That is, fork() would return a StructuredTaskResult with a get() method that will immediately return the result if invoked after a join(). And otherwise, if get() is invoked before a join point, get() would throw. So users that could not resist the temptation and misuse get() would get immediate feedback at run time. And I think this would make life easier for static code analysis tools to detect cases where get() is invoked before a join(). However, I am not sure about the performance penalty of such an design. As it brings an additional synchronization between StructuredTaskScope and StructuredTaskResult that probably does not exist in the current API. As always, designing a good API is hard? - Florian From rengels at ix.netcom.com Wed Jan 4 18:38:43 2023 From: rengels at ix.netcom.com (Robert Engels) Date: Wed, 4 Jan 2023 12:38:43 -0600 Subject: [External] : Re: Project Loom VirtualThreads hang In-Reply-To: <8288D3F9-7FA1-4AB0-B69F-6C8FA17D2FB5@oracle.com> References: <8288D3F9-7FA1-4AB0-B69F-6C8FA17D2FB5@oracle.com> Message-ID: <31273EBC-3619-4980-BE56-DF8B079E2323@ix.netcom.com> As my testing shows - simply switching from native threads to vthreads is a 3x performance boost (using unspecialized code) - so that?s pretty good :) > On Jan 4, 2023, at 11:36 AM, Ron Pressler wrote: > > ? Sure, but virtual threads are intended to be used when you have lots of threads (with low contention relative to their total number), so an interesting benchmark is one that tries to create such an intended scenario. Note that in the CSP/actor paradigms are also primarily designed for cases with a very large number of channels/mailboxes as well as processes/actors, also with relatively low contention. Rather, your benchmark is more similar to SEDA (where you have a relatively small number of threads and queues), which is a very useful architecture, but ? unlike CSP and actors that are a great fit for virtual threads ? not virtual threads? primary focus. > > Again, that is not to say that someone might not want to use virtual threads for other reasons, but because those use-cases cannot provide as much of a performance boost as the many-thread scenario and because they?re less common, they?re not our current main focus. We?d like to first optimise virtual threads for thread-per-request servers, as well as (I/O-driven) CSP/actors, and only later for other uses because those uses are more common and because virtual threads can enhance their throughput more significantly. > > ? Ron > >>> On 4 Jan 2023, at 17:19, Robert Engels wrote: >>> >>> To clarify, this is not a contrived test. This is a reproduction of a real world system. With vthreads it is more efficient to remove the intermediate queues and have the producers ?write through? into the consumers network connection. >>> >>> This isn?t ideal as a slow consumer can block everyone - intermediary queues isolate that problem (to a degree - the queue can still backup). The alternative is to set a write timeout and drop the consumer if it triggers. >>> >>> On Jan 4, 2023, at 10:07 AM, Ron Pressler wrote: >>> >>> ? P.S. >>> >>> To explain my hint about benchmarking with many queues, let me say that often what makes the scheduler work harder is not the context-switching itself but finding a task (in this case, a runnable thread) to run. When the amount of contention is very high compared to the total number of threads, this may be hard and require expensive inter-core chatter. But in more realistic workloads, the level of contention is significantly lower than the total number of threads, so it?s easier for the scheduler to find a thread to schedule. I.e. in common conditions with, say, 50,000 threads, they will not all be contending for the same data structure, but small groups of them may be contending over multiple data structures, and there will be sufficiently many runnable threads to keep the scheduler from working hard to find things to run on other cores? queues. >>> >>>> On 4 Jan 2023, at 15:27, Ron Pressler wrote: >>>> >>>> Thank you. >>>> >>>> To make your benchmark more interesting, I would suggest varying both the number of producers and consumers as well as the number of queues they contend over (e.g. 100,000 queues with 1 producer and 1 consumer each, 1000 queues with 100 producers and 100 consumers each etc.). This would also give you a sense of the kinds of benchmarks we?re using. >>>> >>>> BTW, the impact on throughput that context switching has on message passing systems is related to the ratio between the average context switching duration and the average wait-time between messages, i.e. context-switching needs to be efficient only to the point that it is significantly smaller than the wait-time between messages. Once it?s small enough *in comparison*, reducing it further has little impact (see calculation here: https://inside.java/2020/08/07/loom-performance/). >>>> >>>> ? Ron >>>> >>>>> On 4 Jan 2023, at 04:59, robert engels wrote: >>>>> >>>>> For some further data points. Using VthreadTest here (essentially a message passing system): >>>>> >>>>> With 32 producers, 32 consumers, 500k messages on an 4/8 core machine: >>>>> >>>>> 1a. native threads w ABQ: 60-65% system cpu, 20% user cpu, 15-20% idle, total time 189 seconds >>>>> 1b. vthreads w ABQ: 5-10% system cpu, 75% user cpu, 15% idle, total time 63 seconds >>>>> 2a. native threads w RingBuffer, spin=1: 70% system cpu, 30% user cpu, 0% idle, total time 174 seconds >>>>> 2b. vthreads w RingBuffer, spin=1: 13% system cpu, 85% user, 2% idle, total time 37 seconds >>>>> 3a. native threads w RingBuffer, spin=32: 68% system cpu, 30% user cpu, 2% idle, total time 164 seconds >>>>> 3b. vthreads w RingBuffer, spin=32: 13% system cpu, 85% user, 3% idle, total time 40 seconds >>>>> >>>>> (ABQ is stdlib ArrayBlockingQueue) >>>>> >>>>> The above times have a lot of variance which is not fully accounted for but the interesting thing is that the RingBuffer makes such a huge difference between 1 & 2. >>>>> >>>>> Even in 2b, there is 13% taken up by the OS - I assume due to thread switching as there is no IO in the test, which means the scheduling can probably be improved. >>>>> >>>>> I would expect a green thread system to approach 0% idle and 0% system utilization in this type of test. I am ?fairly cetain? the code should able to use all carrier threads 100%. Maybe the system % is going to something else? (You can use the SpinTest - comment out the println - and see that 100% cpu bound ?do nothing? test that allocates no objects still uses more than 25% system cpu - which seems odd). >>>>> >>>>> Here is a async profile capture of 3b: >>>>> >>>>> >>>>> >>>>> Notice that the vast majority of the time is used in internal context switching. >>>>> >>>>> I can ?fairly agree? with the project?s stated bias towards server systems with 1000?s of threads (I do think 1000?s of threads is enough vs. millions of threads), but I hope this can be addressed moving forward. I think the CSP (communicating sequential processes) model (close to Actor model) simplifies a lot of concurrent programming concerns but it requires highly efficient context switching and queues to work well. >>>>> >>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rengels at ix.netcom.com Wed Jan 4 18:39:50 2023 From: rengels at ix.netcom.com (Robert Engels) Date: Wed, 4 Jan 2023 12:39:50 -0600 Subject: [External] : Re: Project Loom VirtualThreads hang In-Reply-To: References: Message-ID: <57321C4D-9530-4335-B29C-FE005D9F02EF@ix.netcom.com> The real system uses its own native buffers per connection so an OOM due to pass through isn?t possible. > On Jan 4, 2023, at 11:31 AM, Francesco Nigro wrote: > > ? > > With vthreads it is more efficient to remove the intermediate queues and have the producers ?write through? into the consumers network connection. > > Such producers are using "blocking" connections? If yes, beware congested network use case and lack of batching + congested networks: > if they batch, they will amortize syscalls but, if the network is congested, they will likely be descheduled by Loom while still holding the allocated buffer reference (that cannot be used by others): with many of them it can easily cause OOM (or worse!) > if they are not batching and using small buffers, they will die due to syscall costs/SOFT IRQs and underutilizing the network (already congested) > The first case, to return OT, is what concern me a bit about using batching with Loom (and no, application level flow control mechanisms won't help with congested networks :/) > > >> Il giorno mer 4 gen 2023 alle ore 18:23 Robert Engels ha scritto: >> To clarify, this is not a contrived test. This is a reproduction of a real world system. With vthreads it is more efficient to remove the intermediate queues and have the producers ?write through? into the consumers network connection. >> >> This isn?t ideal as a slow consumer can block everyone - intermediary queues isolate that problem (to a degree - the queue can still backup). The alternative is to set a write timeout and drop the consumer if it triggers. >> >>>> On Jan 4, 2023, at 10:07 AM, Ron Pressler wrote: >>>> >>> ? P.S. >>> >>> To explain my hint about benchmarking with many queues, let me say that often what makes the scheduler work harder is not the context-switching itself but finding a task (in this case, a runnable thread) to run. When the amount of contention is very high compared to the total number of threads, this may be hard and require expensive inter-core chatter. But in more realistic workloads, the level of contention is significantly lower than the total number of threads, so it?s easier for the scheduler to find a thread to schedule. I.e. in common conditions with, say, 50,000 threads, they will not all be contending for the same data structure, but small groups of them may be contending over multiple data structures, and there will be sufficiently many runnable threads to keep the scheduler from working hard to find things to run on other cores? queues. >>> >>>> On 4 Jan 2023, at 15:27, Ron Pressler wrote: >>>> >>>> Thank you. >>>> >>>> To make your benchmark more interesting, I would suggest varying both the number of producers and consumers as well as the number of queues they contend over (e.g. 100,000 queues with 1 producer and 1 consumer each, 1000 queues with 100 producers and 100 consumers each etc.). This would also give you a sense of the kinds of benchmarks we?re using. >>>> >>>> BTW, the impact on throughput that context switching has on message passing systems is related to the ratio between the average context switching duration and the average wait-time between messages, i.e. context-switching needs to be efficient only to the point that it is significantly smaller than the wait-time between messages. Once it?s small enough *in comparison*, reducing it further has little impact (see calculation here: https://inside.java/2020/08/07/loom-performance/). >>>> >>>> ? Ron >>>> >>>>> On 4 Jan 2023, at 04:59, robert engels wrote: >>>>> >>>>> For some further data points. Using VthreadTest here (essentially a message passing system): >>>>> >>>>> With 32 producers, 32 consumers, 500k messages on an 4/8 core machine: >>>>> >>>>> 1a. native threads w ABQ: 60-65% system cpu, 20% user cpu, 15-20% idle, total time 189 seconds >>>>> 1b. vthreads w ABQ: 5-10% system cpu, 75% user cpu, 15% idle, total time 63 seconds >>>>> 2a. native threads w RingBuffer, spin=1: 70% system cpu, 30% user cpu, 0% idle, total time 174 seconds >>>>> 2b. vthreads w RingBuffer, spin=1: 13% system cpu, 85% user, 2% idle, total time 37 seconds >>>>> 3a. native threads w RingBuffer, spin=32: 68% system cpu, 30% user cpu, 2% idle, total time 164 seconds >>>>> 3b. vthreads w RingBuffer, spin=32: 13% system cpu, 85% user, 3% idle, total time 40 seconds >>>>> >>>>> (ABQ is stdlib ArrayBlockingQueue) >>>>> >>>>> The above times have a lot of variance which is not fully accounted for but the interesting thing is that the RingBuffer makes such a huge difference between 1 & 2. >>>>> >>>>> Even in 2b, there is 13% taken up by the OS - I assume due to thread switching as there is no IO in the test, which means the scheduling can probably be improved. >>>>> >>>>> I would expect a green thread system to approach 0% idle and 0% system utilization in this type of test. I am ?fairly cetain? the code should able to use all carrier threads 100%. Maybe the system % is going to something else? (You can use the SpinTest - comment out the println - and see that 100% cpu bound ?do nothing? test that allocates no objects still uses more than 25% system cpu - which seems odd). >>>>> >>>>> Here is a async profile capture of 3b: >>>>> >>>>> >>>>> >>>>> Notice that the vast majority of the time is used in internal context switching. >>>>> >>>>> I can ?fairly agree? with the project?s stated bias towards server systems with 1000?s of threads (I do think 1000?s of threads is enough vs. millions of threads), but I hope this can be addressed moving forward. I think the CSP (communicating sequential processes) model (close to Actor model) simplifies a lot of concurrent programming concerns but it requires highly efficient context switching and queues to work well. >>>>> >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From robin.bygrave at gmail.com Wed Jan 4 23:07:42 2023 From: robin.bygrave at gmail.com (Rob Bygrave) Date: Thu, 5 Jan 2023 12:07:42 +1300 Subject: [External] : Re: Project Loom VirtualThreads hang In-Reply-To: <57321C4D-9530-4335-B29C-FE005D9F02EF@ix.netcom.com> References: <57321C4D-9530-4335-B29C-FE005D9F02EF@ix.netcom.com> Message-ID: *> An application employing 200 virtual threads will not perform significantly better than one employing 200 platform threads * It doesn't have to but we do desire it to not be materially worse. That is, it's more that we don't want to end up in conversations that go like "When we are > 1000 VT then we use Nima, JDBC, and just write simple blocking code but when we are under 200 VT we need to switch to PT and use WebFlux, R2DBC, Rx libraries, and write using callbacks and deal with errors/exceptions differently etc". *> The main difference between virtual threads and platform threads is that you can have many more virtual threads.* In terms of developer impact, I see it more like "With VT blocking is cheap" which then impacts fundamental library choices that developers make (server libs and db drivers) and even the style of code. As a developer we ideally want these choices to work at all the various levels of scale desired at "competitive performance" without having to change our fundamental choices (which imo is approx based on "Reactive" vs "Blocking"). For myself, I'm not looking for VT to be significantly better in this sub 200 Threads range but to be competitive. Having a *"wide sweet spot"* impacts choosing a library like Nima (which does not have PT option unlike say Jetty). FWIW: In my testing to date we can see material performance improvement via VT over PT in measuring *gitter* when load goes over a PT thread pool size resource limit. There is some argument that VT can provide "smoother scalability" behavior in this range. On Thu, 5 Jan 2023 at 07:40, Robert Engels wrote: > The real system uses its own native buffers per connection so an OOM due > to pass through isn?t possible. > > On Jan 4, 2023, at 11:31 AM, Francesco Nigro wrote: > > ? > > With vthreads it is more efficient to remove the intermediate queues > and have the producers ?write through? into the consumers network > connection. > > Such producers are using "blocking" connections? If yes, beware > congested network use case and lack of batching + congested networks: > > - if they batch, they will amortize syscalls but, if the network is > congested, they will likely be descheduled by Loom while still holding the > allocated buffer reference (that cannot be used by others): with many of > them it can easily cause OOM (or worse!) > - if they are not batching and using small buffers, they will die due > to syscall costs/SOFT IRQs and underutilizing the network (already > congested) > > The first case, to return OT, is what concern me a bit about using > batching with Loom (and no, application level flow control mechanisms won't > help with congested networks :/) > > > Il giorno mer 4 gen 2023 alle ore 18:23 Robert Engels < > rengels at ix.netcom.com> ha scritto: > >> To clarify, this is not a contrived test. This is a reproduction of a >> real world system. With vthreads it is more efficient to remove the >> intermediate queues and have the producers ?write through? into the >> consumers network connection. >> >> This isn?t ideal as a slow consumer can block everyone - intermediary >> queues isolate that problem (to a degree - the queue can still backup). The >> alternative is to set a write timeout and drop the consumer if it triggers. >> >> On Jan 4, 2023, at 10:07 AM, Ron Pressler >> wrote: >> >> ? P.S. >> >> To explain my hint about benchmarking with many queues, let me say that >> often what makes the scheduler work harder is not the context-switching >> itself but finding a task (in this case, a runnable thread) to run. When >> the amount of contention is very high compared to the total number of >> threads, this may be hard and require expensive inter-core chatter. But in >> more realistic workloads, the level of contention is significantly lower >> than the total number of threads, so it?s easier for the scheduler to find >> a thread to schedule. I.e. in common conditions with, say, 50,000 threads, >> they will not all be contending for the same data structure, but small >> groups of them may be contending over multiple data structures, and there >> will be sufficiently many runnable threads to keep the scheduler from >> working hard to find things to run on other cores? queues. >> >> On 4 Jan 2023, at 15:27, Ron Pressler wrote: >> >> Thank you. >> >> To make your benchmark more interesting, I would suggest varying both the >> number of producers and consumers as well as the number of queues they >> contend over (e.g. 100,000 queues with 1 producer and 1 consumer each, 1000 >> queues with 100 producers and 100 consumers each etc.). This would also >> give you a sense of the kinds of benchmarks we?re using. >> >> BTW, the impact on throughput that context switching has on message >> passing systems is related to the ratio between the average context >> switching duration and the average wait-time between messages, i.e. >> context-switching needs to be efficient only to the point that it is >> significantly smaller than the wait-time between messages. Once it?s small >> enough *in comparison*, reducing it further has little impact (see >> calculation here: https://inside.java/2020/08/07/loom-performance/). >> >> ? Ron >> >> On 4 Jan 2023, at 04:59, robert engels wrote: >> >> For some further data points. Using VthreadTest here >> (essentially >> a message passing system): >> >> With 32 producers, 32 consumers, 500k messages on an 4/8 core machine: >> >> 1a. native threads w ABQ: 60-65% system cpu, 20% user cpu, 15-20% idle, >> total time 189 seconds >> 1b. vthreads w ABQ: 5-10% system cpu, 75% user cpu, 15% idle, total time >> 63 seconds >> 2a. native threads w RingBuffer, spin=1: 70% system cpu, 30% user cpu, 0% >> idle, total time 174 seconds >> 2b. vthreads w RingBuffer, spin=1: 13% system cpu, 85% user, 2% idle, >> total time 37 seconds >> 3a. native threads w RingBuffer, spin=32: 68% system cpu, 30% user cpu, >> 2% idle, total time 164 seconds >> 3b. vthreads w RingBuffer, spin=32: 13% system cpu, 85% user, 3% idle, >> total time 40 seconds >> >> (ABQ is stdlib ArrayBlockingQueue) >> >> The above times have a lot of variance which is not fully accounted for >> but the interesting thing is that the RingBuffer makes such a huge >> difference between 1 & 2. >> >> Even in 2b, there is 13% taken up by the OS - I assume due to thread >> switching as there is no IO in the test, which means the scheduling can >> probably be improved. >> >> I would expect a green thread system to approach 0% idle and 0% system >> utilization in this type of test. I am ?fairly cetain? the code should able >> to use all carrier threads 100%. Maybe the system % is going to something >> else? (You can use the SpinTest - comment out the println - and see that >> 100% cpu bound ?do nothing? test that allocates no objects still uses more >> than 25% system cpu - which seems odd). >> >> Here is a async profile capture of 3b: >> >> >> >> Notice that the vast majority of the time is used in internal context >> switching. >> >> I can ?fairly agree? with the project?s stated bias towards server >> systems with 1000?s of threads (I do think 1000?s of threads is enough vs. >> millions of threads), but I hope this can be addressed moving forward. I >> think the CSP (communicating sequential processes) model (close to Actor >> model) simplifies a lot of concurrent programming concerns but it requires >> highly efficient context switching and queues to work well. >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron.pressler at oracle.com Wed Jan 4 23:47:24 2023 From: ron.pressler at oracle.com (Ron Pressler) Date: Wed, 4 Jan 2023 23:47:24 +0000 Subject: [External] : Re: Project Loom VirtualThreads hang In-Reply-To: References: <57321C4D-9530-4335-B29C-FE005D9F02EF@ix.netcom.com> Message-ID: <04A0B4B8-770A-44C8-A066-5412BF7AD981@oracle.com> On 4 Jan 2023, at 23:07, Rob Bygrave > wrote: > An application employing 200 virtual threads will not perform significantly better than one employing 200 platform threads It doesn't have to but we do desire it to not be materially worse. That is, it's more that we don't want to end up in conversations that go like "When we are > 1000 VT then we use Nima, JDBC, and just write simple blocking code but when we are under 200 VT we need to switch to PT and use WebFlux, R2DBC, Rx libraries, and write using callbacks and deal with errors/exceptions differently etc". There?s a misunderstanding here. An application that end up 200 threads when it uses the style virtual threads were designed for ? i.e. thread-per-request ? can switch between virtual threads and platform threads by merely choosing an appropriate ExecutorService. There?s never a need to change the programming paradigm. The number of virtual threads used is not determined by the developer, but by the workload on the server. This is a very important point that I try explaining in talks. Virtual threads are not an execution resource, but a business logic object like a string. If your job is to store a map of user IDs and names, the number of strings used cannot be any higher or lower than the number of users. Similarly for virtual threads. The number of virtual threads will be equal ? no higher and no lower ? than the number of concurrent tasks your server performs. If that number ends up being 200, i.e. your server operates at a low throughput or your latency is extremely low, then switching between thread implementation is trivial. > The main difference between virtual threads and platform threads is that you can have many more virtual threads. In terms of developer impact, I see it more like "With VT blocking is cheap" which then impacts fundamental library choices that developers make (server libs and db drivers) and even the style of code. As a developer we ideally want these choices to work at all the various levels of scale desired at "competitive performance" without having to change our fundamental choices (which imo is approx based on "Reactive" vs "Blocking"). Virtual threads make blocking cheap *because* they can be numerous. Put another way, blocking platform threads is expensive because it consumes a very limited time for a long duration, which, by Little?s law, places a low limit on throughput. The impact of blocking on server throughput due to the number of threads is orders of magnitude higher than due to any other effect. For myself, I'm not looking for VT to be significantly better in this sub 200 Threads range but to be competitive. Having a "wide sweet spot" impacts choosing a library like Nima (which does not have PT option unlike say Jetty). It really shouldn?t matter. Thread-per-request is the style that the Java platform supports best. Before virtual thread, it had a performance cost that forced some to pick a different programming style. With virtual threads available, you can use that style no matter what the load on your server is, and easily switch between thread implementation if it makes a difference. ? Ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron.pressler at oracle.com Wed Jan 4 23:50:33 2023 From: ron.pressler at oracle.com (Ron Pressler) Date: Wed, 4 Jan 2023 23:50:33 +0000 Subject: [External] : Re: Project Loom VirtualThreads hang In-Reply-To: <04A0B4B8-770A-44C8-A066-5412BF7AD981@oracle.com> References: <57321C4D-9530-4335-B29C-FE005D9F02EF@ix.netcom.com> <04A0B4B8-770A-44C8-A066-5412BF7AD981@oracle.com> Message-ID: <2E93A6D5-D2D6-40EC-BDA7-AD56BFC3E169@oracle.com> > On 4 Jan 2023, at 23:47, Ron Pressler wrote: > > Virtual threads make blocking cheap *because* they can be numerous. Put another way, blocking platform threads is expensive because it consumes a very limited time for a long duration, which, by Little?s law, places a low limit on throughput. The impact of blocking on server throughput due to the number of threads is orders of magnitude higher than due to any other effect. > * consumes a very limited RESOURCE for a long duration From thurston.nomagicsoftware at gmail.com Thu Jan 5 00:25:10 2023 From: thurston.nomagicsoftware at gmail.com (thurston N) Date: Wed, 4 Jan 2023 16:25:10 -0800 Subject: [External] : Re: Project Loom VirtualThreads hang In-Reply-To: <2E93A6D5-D2D6-40EC-BDA7-AD56BFC3E169@oracle.com> References: <57321C4D-9530-4335-B29C-FE005D9F02EF@ix.netcom.com> <04A0B4B8-770A-44C8-A066-5412BF7AD981@oracle.com> <2E93A6D5-D2D6-40EC-BDA7-AD56BFC3E169@oracle.com> Message-ID: " With virtual threads available, you can use that style no matter what the load on your server is, and easily switch between thread implementation if it makes a difference." Can you? even if it's a configuration option, you need to bounce a production server(s) to "switch" My experience jibes with Robin's, especially since load is not constant in the real world, as long as virtual threads offer acceptable throughput and latency *even when their true benefits, viz high numbers are not in effect". If that is the case (and I don't see why it wouldn't be), the question might better be "why would you ever bother to switch (from virtual to platform)"? On Wed, Jan 4, 2023 at 3:50 PM Ron Pressler wrote: > > > > On 4 Jan 2023, at 23:47, Ron Pressler wrote: > > > > Virtual threads make blocking cheap *because* they can be numerous. Put > another way, blocking platform threads is expensive because it consumes a > very limited time for a long duration, which, by Little?s law, places a low > limit on throughput. The impact of blocking on server throughput due to the > number of threads is orders of magnitude higher than due to any other > effect. > > > > > * consumes a very limited RESOURCE for a long duration -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron.pressler at oracle.com Thu Jan 5 00:54:15 2023 From: ron.pressler at oracle.com (Ron Pressler) Date: Thu, 5 Jan 2023 00:54:15 +0000 Subject: [External] : Re: Project Loom VirtualThreads hang In-Reply-To: References: <57321C4D-9530-4335-B29C-FE005D9F02EF@ix.netcom.com> <04A0B4B8-770A-44C8-A066-5412BF7AD981@oracle.com> <2E93A6D5-D2D6-40EC-BDA7-AD56BFC3E169@oracle.com> Message-ID: > On 5 Jan 2023, at 00:25, thurston N wrote: > > " With virtual threads available, you can use that style no matter what the load on your server is, and easily switch between thread implementation if it makes a difference." > > Can you? > even if it's a configuration option, you need to bounce a production server(s) to "switch" > > My experience jibes with Robin's, especially since load is not constant in the real world, as long as virtual threads offer acceptable throughput and latency *even when their true benefits, viz high numbers are not in effect". If that is the case (and I don't see why it wouldn't be), the question might better be "why would you ever bother to switch (from virtual to platform)"? If the workload *could* rise to the point that it requires more threads, then virtual threads already help: they support the possibly-needed scale, and if they work well at some high throughput X, then they obviously work well at throughput 0.1X. There?s obviously no need to switch. I?m talking about cases where the workload is such that it could never rise to the point where virtual threads would be necessary, and the appropriate thread implementation is picked during development, but whatever it is, the thread-per-request style that the platform is designed for would fit well. So you can always use the right style for Java, no matter what your workload is, and then you can pick an appropriate thread implementation for your application. In the vast majority of cases, the choice in the low-throughput cases doesn?t matter much, but when it does, it?s not an API choice, but a simple implementation choice. So in these cases there?s also no need to switch. My main point is to try and steer the discussion away from cases where, for whatever reason, the developer doesn?t wish to use the thread-per-request model, because however well virtual threads perform such tasks now, that is not their primary focus. Once the ecosystem gains more experience with virtual threads for their primary usage, we can shift our attention to other uses as well. There?s a lot of excitement about virtual threads, and people are experimenting with them for various tasks ? and that?s great. But because we must choose what to focus on *first*, we choose the more common use-cases where the performance impact is also much higher (and if virtual threads help for other things too, that?s terrific, but still not our primary focus). ? Ron From rengels at ix.netcom.com Thu Jan 5 00:54:25 2023 From: rengels at ix.netcom.com (robert engels) Date: Wed, 4 Jan 2023 18:54:25 -0600 Subject: Project Loom VirtualThreads hang In-Reply-To: References: <96631C23-9C63-4848-B310-C0521FB094E9@ix.netcom.com> Message-ID: > On Jan 4, 2023, at 3:32 AM, Alan Bateman wrote: > > -XX:+UnlockExperimentalVMOptions -XX:+DoJVMTIVirtualThreadTransitions As an fyi, the above did not affect the async profiler trace that I could tell. I get similar profilers with both the Intellij profiler and the async profiler. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rengels at ix.netcom.com Thu Jan 5 01:01:03 2023 From: rengels at ix.netcom.com (robert engels) Date: Wed, 4 Jan 2023 19:01:03 -0600 Subject: [External] : Re: Project Loom VirtualThreads hang In-Reply-To: References: <96631C23-9C63-4848-B310-C0521FB094E9@ix.netcom.com> Message-ID: <8AC301FC-6E3B-49CC-9215-E5CF0421AB16@ix.netcom.com> Understood. Thanks. For a large swath of ?message systems? you are talking about hundreds of clients, not thousands, and certainly not millions. I am particularly referring to financial/trading systems. These usually use a fan-out structure so any given node only has < 100 clients and often far smaller than that. Latency is a huge concern however. This can be done with async IO and native threads but it doesn?t ?feel like Java? - and is certainly harder to understand/maintain in my opinion. If Loom allowed Go like performance it would be a killer solution for these ?router? type nodes. But please don?t take this as a strong criticism - in my testing Loom is within 10% of Go performance as it is today - which is a remarkable achievement especially given the backwards compatibility/programming model. > On Jan 4, 2023, at 9:27 AM, Ron Pressler wrote: > > Thank you. > > To make your benchmark more interesting, I would suggest varying both the number of producers and consumers as well as the number of queues they contend over (e.g. 100,000 queues with 1 producer and 1 consumer each, 1000 queues with 100 producers and 100 consumers each etc.). This would also give you a sense of the kinds of benchmarks we?re using. > > BTW, the impact on throughput that context switching has on message passing systems is related to the ratio between the average context switching duration and the average wait-time between messages, i.e. context-switching needs to be efficient only to the point that it is significantly smaller than the wait-time between messages. Once it?s small enough *in comparison*, reducing it further has little impact (see calculation here: https://inside.java/2020/08/07/loom-performance/ ). > > ? Ron > >> On 4 Jan 2023, at 04:59, robert engels > wrote: >> >> For some further data points. Using VthreadTest here (essentially a message passing system): >> >> With 32 producers, 32 consumers, 500k messages on an 4/8 core machine: >> >> 1a. native threads w ABQ: 60-65% system cpu, 20% user cpu, 15-20% idle, total time 189 seconds >> 1b. vthreads w ABQ: 5-10% system cpu, 75% user cpu, 15% idle, total time 63 seconds >> 2a. native threads w RingBuffer, spin=1: 70% system cpu, 30% user cpu, 0% idle, total time 174 seconds >> 2b. vthreads w RingBuffer, spin=1: 13% system cpu, 85% user, 2% idle, total time 37 seconds >> 3a. native threads w RingBuffer, spin=32: 68% system cpu, 30% user cpu, 2% idle, total time 164 seconds >> 3b. vthreads w RingBuffer, spin=32: 13% system cpu, 85% user, 3% idle, total time 40 seconds >> >> (ABQ is stdlib ArrayBlockingQueue) >> >> The above times have a lot of variance which is not fully accounted for but the interesting thing is that the RingBuffer makes such a huge difference between 1 & 2. >> >> Even in 2b, there is 13% taken up by the OS - I assume due to thread switching as there is no IO in the test, which means the scheduling can probably be improved. >> >> I would expect a green thread system to approach 0% idle and 0% system utilization in this type of test. I am ?fairly cetain? the code should able to use all carrier threads 100%. Maybe the system % is going to something else? (You can use the SpinTest - comment out the println - and see that 100% cpu bound ?do nothing? test that allocates no objects still uses more than 25% system cpu - which seems odd). >> >> Here is a async profile capture of 3b: >> >> >> >> Notice that the vast majority of the time is used in internal context switching. >> >> I can ?fairly agree? with the project?s stated bias towards server systems with 1000?s of threads (I do think 1000?s of threads is enough vs. millions of threads), but I hope this can be addressed moving forward. I think the CSP (communicating sequential processes) model (close to Actor model) simplifies a lot of concurrent programming concerns but it requires highly efficient context switching and queues to work well. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thurston.nomagicsoftware at gmail.com Thu Jan 5 01:11:45 2023 From: thurston.nomagicsoftware at gmail.com (thurston N) Date: Wed, 4 Jan 2023 17:11:45 -0800 Subject: [External] : Re: Project Loom VirtualThreads hang In-Reply-To: References: <57321C4D-9530-4335-B29C-FE005D9F02EF@ix.netcom.com> <04A0B4B8-770A-44C8-A066-5412BF7AD981@oracle.com> <2E93A6D5-D2D6-40EC-BDA7-AD56BFC3E169@oracle.com> Message-ID: Yes, I agree. The "false" choice is between: load is less than some sweetspot N -> use reactive style design load is greater than N -> use sequential style with virtual threads in that sense I disagree with Rob's post (despite my previous post)- why would reactive style perform better than sequential style (whether using virtual or platform threads) at some small N? surely it wouldn't Having written that, speaking for myself, I think the whole "just have to change the ExecutorService" is a bit of a fool's errand, and is n't important; e.g. because a fixed pool size ES has the side effect (and it is only a side effect) as a throttle on your application, where you need to do something different (though not difficult) if using a VT ES; I'm sure in the end there will be many other examples. I would prefer making VirtualThread and Continuation accessible (if read-only) to "minimizing surface API", if only for better observability/debugging at the user code level, but that's a different discussion The main point you make makes sense: there is no need to choose between sequential and reactive style design *because of efficiency/performance* reasons - touche On Wed, Jan 4, 2023 at 4:54 PM Ron Pressler wrote: > > > > On 5 Jan 2023, at 00:25, thurston N > wrote: > > > > " With virtual threads available, you can use that style no matter what > the load on your server is, and easily switch between thread implementation > if it makes a difference." > > > > Can you? > > even if it's a configuration option, you need to bounce a production > server(s) to "switch" > > > > My experience jibes with Robin's, especially since load is not constant > in the real world, as long as virtual threads offer acceptable throughput > and latency *even when their true benefits, viz high numbers are not in > effect". If that is the case (and I don't see why it wouldn't be), the > question might better be "why would you ever bother to switch (from virtual > to platform)"? > > If the workload *could* rise to the point that it requires more threads, > then virtual threads already help: they support the possibly-needed scale, > and if they work well at some high throughput X, then they obviously work > well at throughput 0.1X. There?s obviously no need to switch. > > I?m talking about cases where the workload is such that it could never > rise to the point where virtual threads would be necessary, and the > appropriate thread implementation is picked during development, but > whatever it is, the thread-per-request style that the platform is designed > for would fit well. So you can always use the right style for Java, no > matter what your workload is, and then you can pick an appropriate thread > implementation for your application. In the vast majority of cases, the > choice in the low-throughput cases doesn?t matter much, but when it does, > it?s not an API choice, but a simple implementation choice. So in these > cases there?s also no need to switch. > > My main point is to try and steer the discussion away from cases where, > for whatever reason, the developer doesn?t wish to use the > thread-per-request model, because however well virtual threads perform such > tasks now, that is not their primary focus. Once the ecosystem gains more > experience with virtual threads for their primary usage, we can shift our > attention to other uses as well. There?s a lot of excitement about virtual > threads, and people are experimenting with them for various tasks ? and > that?s great. But because we must choose what to focus on *first*, we > choose the more common use-cases where the performance impact is also much > higher (and if virtual threads help for other things too, that?s terrific, > but still not our primary focus). > > ? Ron > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robin.bygrave at gmail.com Thu Jan 5 05:15:46 2023 From: robin.bygrave at gmail.com (Rob Bygrave) Date: Thu, 5 Jan 2023 18:15:46 +1300 Subject: [External] : Re: Project Loom VirtualThreads hang In-Reply-To: References: <57321C4D-9530-4335-B29C-FE005D9F02EF@ix.netcom.com> <04A0B4B8-770A-44C8-A066-5412BF7AD981@oracle.com> <2E93A6D5-D2D6-40EC-BDA7-AD56BFC3E169@oracle.com> Message-ID: Well I think this discussion has gone well. Thanks and apologies in equal measure I reckon :) To be blunt, I'm really comfortable using VT in low numbers and for myself I'm squarely in the camp "The default choice is to use VT". I'm in the camp that says my server of choice going forward is very likely Nima *regardless of load*. To be explicit, the implication is that I'm also in the camp that is never willingly choosing to use reactive style so no WebFlux, no R2DBC and use of Rx Libraries is going to be niche for me. I might have misunderstood prior comments but frequently wrt VT I read something that goes like "blah blah ... *but they are designed for cases with 1000's of VT*" which to me was giving off the wrong vibe / implication that VT are not designed to be used for cases where there are relatively low numbers of VT. *> if they work well at some high throughput X, then they obviously work well at throughput 0.1X* It wasn't obvious to me how the costs would play out in the 0.1X range which was why I did the testing I did with Jetty and JDK HttpClient (where it's easy to swap between VT and PT). It was this testing that made me comfortable in the 0.1X range and the outcome for myself having the expectation that "The default is VT". To me it wasn't surprising that Nima provides *no option* to "swap in an ES that uses Platform Threads" - it's an example of a library that is 100% committed to Virtual Threads regardless of load and regardless of the number of VT. Cheers, Rob. On Thu, 5 Jan 2023 at 14:11, thurston N wrote: > Yes, I agree. > The "false" choice is between: > load is less than some sweetspot N -> use reactive style design > load is greater than N -> use sequential style with virtual threads > > in that sense I disagree with Rob's post (despite my previous post)- why > would reactive style perform better than sequential style (whether using > virtual or platform threads) at some small N? surely it wouldn't > > Having written that, speaking for myself, I think the whole "just have to > change the ExecutorService" is a bit of a fool's errand, and is n't > important; e.g. because a fixed pool size ES has the side effect (and it is > only a side effect) as a throttle on your application, where you need to do > something different (though not difficult) if using a VT ES; I'm sure in > the end there will be many other examples. > I would prefer making VirtualThread and Continuation accessible (if > read-only) to "minimizing surface API", if only for better > observability/debugging at the user code level, but that's a different > discussion > > The main point you make makes sense: there is no need to choose between > sequential and reactive style design *because of efficiency/performance* > reasons - touche > > > > On Wed, Jan 4, 2023 at 4:54 PM Ron Pressler > wrote: > >> >> >> > On 5 Jan 2023, at 00:25, thurston N >> wrote: >> > >> > " With virtual threads available, you can use that style no matter what >> the load on your server is, and easily switch between thread implementation >> if it makes a difference." >> > >> > Can you? >> > even if it's a configuration option, you need to bounce a production >> server(s) to "switch" >> > >> > My experience jibes with Robin's, especially since load is not constant >> in the real world, as long as virtual threads offer acceptable throughput >> and latency *even when their true benefits, viz high numbers are not in >> effect". If that is the case (and I don't see why it wouldn't be), the >> question might better be "why would you ever bother to switch (from virtual >> to platform)"? >> >> If the workload *could* rise to the point that it requires more threads, >> then virtual threads already help: they support the possibly-needed scale, >> and if they work well at some high throughput X, then they obviously work >> well at throughput 0.1X. There?s obviously no need to switch. >> >> I?m talking about cases where the workload is such that it could never >> rise to the point where virtual threads would be necessary, and the >> appropriate thread implementation is picked during development, but >> whatever it is, the thread-per-request style that the platform is designed >> for would fit well. So you can always use the right style for Java, no >> matter what your workload is, and then you can pick an appropriate thread >> implementation for your application. In the vast majority of cases, the >> choice in the low-throughput cases doesn?t matter much, but when it does, >> it?s not an API choice, but a simple implementation choice. So in these >> cases there?s also no need to switch. >> >> My main point is to try and steer the discussion away from cases where, >> for whatever reason, the developer doesn?t wish to use the >> thread-per-request model, because however well virtual threads perform such >> tasks now, that is not their primary focus. Once the ecosystem gains more >> experience with virtual threads for their primary usage, we can shift our >> attention to other uses as well. There?s a lot of excitement about virtual >> threads, and people are experimenting with them for various tasks ? and >> that?s great. But because we must choose what to focus on *first*, we >> choose the more common use-cases where the performance impact is also much >> higher (and if virtual threads help for other things too, that?s terrific, >> but still not our primary focus). >> >> ? Ron >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Thu Jan 5 07:05:38 2023 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 5 Jan 2023 07:05:38 +0000 Subject: Project Loom VirtualThreads hang In-Reply-To: References: <96631C23-9C63-4848-B310-C0521FB094E9@ix.netcom.com> Message-ID: <71ce35d6-1fd1-866b-df57-aafdfb896cd1@oracle.com> On 05/01/2023 00:54, robert engels wrote: > > >> On Jan 4, 2023, at 3:32 AM, Alan Bateman wrote: >> >> -XX:+UnlockExperimentalVMOptions -XX:+DoJVMTIVirtualThreadTransitions > > As an fyi, the above did not affect the async profiler trace that I > could tell. I get similar profilers with both the Intellij profiler > and the async profiler. Oops, a typo in my mail, it should be -XX:-DoJVMTIVirtualThreadTransitionsto disable (not '+' to enable). -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron.pressler at oracle.com Thu Jan 5 10:34:37 2023 From: ron.pressler at oracle.com (Ron Pressler) Date: Thu, 5 Jan 2023 10:34:37 +0000 Subject: [External] : Re: StructuredTaskScope and Futures In-Reply-To: <538344709.77477288.1672851451955.JavaMail.zimbra@u-pem.fr> References: <1009113343.75754648.1672741919013.JavaMail.zimbra@u-pem.fr> <5FBD5E84-6A71-41BB-8179-E5FF87E255B6@oracle.com> <1526188641.77436768.1672847643264.JavaMail.zimbra@u-pem.fr> <1FF55B57-DB86-4C62-B454-F3A62813CB0A@oracle.com> <538344709.77477288.1672851451955.JavaMail.zimbra@u-pem.fr> Message-ID: <1AD38F79-31AA-4841-B694-9076120CB7AF@oracle.com> On 4 Jan 2023, at 16:57, forax at univ-mlv.fr wrote: Those suppressed exceptions are interesting, independently of the success of the computation. If each fork logs itself, you make the monitoring work harder because you are loosing the information that the errors are part of the same computation. Logging a fork?s failure in its scope is not an effective mechanism for observing context because it?s only one level deep ? the parent scope?s own context is lost, not to mention that it doesn?t provide context for any logging events that aren?t task failures. Rather, the solution we have in mind for logging is to provide an API that allows observing the full context hierarchy for logging and monitoring purposes (i.e. you?ll be able to observe a stack of the hierarchy up to the root). I do not see how the indirection can work given that the Future object returned by fork() is specific to a StructuredTaskScope ? Since we only care about completed futures anyway, what I had in mind is something like: Supplier> sf = sts.fork(asCompletedFuture(() -> foo())); where, static Callable> toCompletedFuture(Callable task) { return () -> { try { return CompletableFuture.completedFuture(task.call()); } catch (Exception ex) { return CompletableFuture.failedFuture(ex); } }); } This could be used when an association between exceptions and particular tasks is needed for uses other than logging. What I?m trying to ascertain is how frequently this is needed, where my hypothesis is not very frequently at all. Now, in addition to making the right thing more obvious, the Supplier approach directs the user into the right frame of mind when working with STS, i.e. to think of the forks as a unit rather than individual tasks, and anything that belongs to the individual task should be done in the fork. ? Ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron.pressler at oracle.com Thu Jan 5 10:38:08 2023 From: ron.pressler at oracle.com (Ron Pressler) Date: Thu, 5 Jan 2023 10:38:08 +0000 Subject: [External] : Re: StructuredTaskScope and Futures In-Reply-To: <3f85cc7e-f124-d40a-4b6b-0a20f56140f6@cs.fau.de> References: <1009113343.75754648.1672741919013.JavaMail.zimbra@u-pem.fr> <5FBD5E84-6A71-41BB-8179-E5FF87E255B6@oracle.com> <1526188641.77436768.1672847643264.JavaMail.zimbra@u-pem.fr> <1FF55B57-DB86-4C62-B454-F3A62813CB0A@oracle.com> <4ccb11e6-4719-da59-ead2-ed9d673aeeca@oracle.com> <3f85cc7e-f124-d40a-4b6b-0a20f56140f6@cs.fau.de> Message-ID: <2A2A3D3B-4FE2-41D4-8478-BBA21AB6E976@oracle.com> > On 4 Jan 2023, at 18:08, Florian Schmaus wrote: > > If Future is replaced with Supplier, then you still have a get() method to call, right? So the temptation is still there (even if arguably in a weaker form). I am also not sure how one should map the 'throws' declarations of Future::get() to Supplier. > > Which leads to me ponder if it wouldn't be better if StructuredTaskScope would orientate more on Cilk-ish semantic. That is, fork() would return a StructuredTaskResult with a get() method that will immediately return the result if invoked after a join(). And otherwise, if get() is invoked before a join point, get() would throw. So users that could not resist the temptation and misuse get() would get immediate feedback at run time. And I think this would make life easier for static code analysis tools to detect cases where get() is invoked before a join(). > That is exactly what Supplier.get() would do. It will not block, but throw an IllegalStateException if called before the scope is joined. There is no need for it to every throw any ?logic? exception, because failures would be handled collectively by the policy immediately after joining. In the ShutdownOnFailure case, you would then call get once you know the forks have succeeded. In the ShutdownOnSuccess case, you won?t use the Supplier at all (just ShutdownOnSuccess.result()). ? Ron From forax at univ-mlv.fr Thu Jan 5 10:46:06 2023 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 5 Jan 2023 11:46:06 +0100 (CET) Subject: API proposal for StructuredTaskScope Message-ID: <1656042197.78345370.1672915566603.JavaMail.zimbra@u-pem.fr> Hi all, this is a proposal of a slightly different API for StructuredTaskScope The idea is to provide as parameter of the constructor of StructuredTaskScope a "reducer" that get the value | error from each task and try to compute a result from it. A reducer is quite similar in intent to a stream Collector but it's a different API. Before deep diving into the details, here are some examples of how to use it. Like the current API, as task is submitted with fork() but unlike the current API, fork() returns void instead of a Future. Then there is a method result() that works like join() but also returns the computed result of the tasks by the reducer. If you ask for a Reducer.toList(), the method result() returns a List of all results (a Result is a record with three components, a state (SUCCEED or FAILED), an element is SUCCEED and a suppressed exception (which itself can has suppressed exceptions) for all the exceptions that you may care or not). public static void toList() throws InterruptedException { try(var scope = StructuredTaskScope.of(Reducer.toList())) { scope.fork(() -> 3); scope.fork(() -> { throw new IOException(); }); List> list = scope.result(); System.out.println(list); // [Result[state=FAILED, element=null, suppressed=java.io.IOException], Result[state=SUCCEED, element=3, suppressed=null]] } } When you run the code above several times, the two results exchange location in the list which is normal. You may want only one result, for that you have Reducer.max(comparator) that will give you either an Optional.empty() if there is no call to fork(), or a failed result if no results succeed or the maximum result once at least one succeeded result is available public static void max() throws InterruptedException { try(var scope = StructuredTaskScope.of(Reducer.max(Integer::compareTo))) { scope.fork(() -> 3); scope.fork(() -> { throw new IOException(); }); scope.fork(() -> 42); Optional> max = scope.result(); System.out.println(max); // Optional[Result[state=SUCCEED, element=42, suppressed=java.io.IOException]] } } When you run this code several times, you always have the same max value. You may also want the first result that in success, for that you have Reducer.first() that returns Optional.empty if there is no fork(), a failed result if no task succeed or the first result that succeed (the previous suppressed exception are also available for logging if you want). public static void first() throws InterruptedException { try(var scope = StructuredTaskScope.of(Reducer.first())) { scope.fork(() -> { throw new IOException(); }); scope.fork(() -> 3); scope.fork(() -> 42); Optional> first = scope.result(); System.out.println(first); // Optional[Result[state=SUCCEED, element=3, suppressed=java.io.IOException]] } } When you run this code several times, the returned result can also be 42 and the suppressed exception may or may not be present. So what is a Reducer, it's a record with two functions, a combiner and a finisher, the combiner combines the different results and the finisher provides a nicer object like java.util.List or java.util.Optional as result at the end. @FunctionalInterface public interface Combiner { A apply(A oldValue, Result result, Runnable shouldShutdown); } public record Reducer(Combiner combiner, Function finisher) {} The Reducer API is a little bit complex because it hides the fact that several virtual threads may want to combine their results at the same time. So the combiner function can be called several time with the same result (it's called in the loop that does a CAS). The API supposes that both functions do not do any side effects, otherwise there will be concurrency issues. The combiner also have a third parameter that ask to gently stop the computation (by calling shouldShutdown.run()), this interrupts all other threads if a result is good enough. The prototype is here https://github.com/forax/loom-fiber/blob/master/src/main/java/fr/umlv/loom/reducer/StructuredAsyncScope.java If you want to see the gritty details :) regards, R?mi From ron.pressler at oracle.com Thu Jan 5 11:34:15 2023 From: ron.pressler at oracle.com (Ron Pressler) Date: Thu, 5 Jan 2023 11:34:15 +0000 Subject: [External] : Re: Project Loom VirtualThreads hang In-Reply-To: <8AC301FC-6E3B-49CC-9215-E5CF0421AB16@ix.netcom.com> References: <96631C23-9C63-4848-B310-C0521FB094E9@ix.netcom.com> <8AC301FC-6E3B-49CC-9215-E5CF0421AB16@ix.netcom.com> Message-ID: The main thing I am trying to get across is not that virtual threads work best *only* when their number is high, but that the right way to adopt them is not to replace a platform thread with a virtual thread, but to represent some domain object (a request, a message etc.) with a virtual thread, and then, *as a result*, the number of virtual threads becomes a function of the load and will be high for systems under high load. This is particularly easy to do in very straightforward programs that don?t manually manage platform threads, and in these use-cases ? where a virtual thread *doesn?t* replace a platform thread but some other object ? we already match or exceed Go?s performance, especially when there?s some real work done. Adopting virtual threads in a useful manner in systems that depend on careful management of platform threads is harder. ? Ron > On 5 Jan 2023, at 01:01, robert engels wrote: > > Understood. Thanks. > > For a large swath of ?message systems? you are talking about hundreds of clients, not thousands, and certainly not millions. I am particularly referring to financial/trading systems. > > These usually use a fan-out structure so any given node only has < 100 clients and often far smaller than that. Latency is a huge concern however. This can be done with async IO and native threads but it doesn?t ?feel like Java? - and is certainly harder to understand/maintain in my opinion. > > If Loom allowed Go like performance it would be a killer solution for these ?router? type nodes. > > But please don?t take this as a strong criticism - in my testing Loom is within 10% of Go performance as it is today - which is a remarkable achievement especially given the backwards compatibility/programming model. From rengels at ix.netcom.com Thu Jan 5 12:36:39 2023 From: rengels at ix.netcom.com (robert engels) Date: Thu, 5 Jan 2023 06:36:39 -0600 Subject: Project Loom VirtualThreads hang In-Reply-To: <71ce35d6-1fd1-866b-df57-aafdfb896cd1@oracle.com> References: <96631C23-9C63-4848-B310-C0521FB094E9@ix.netcom.com> <71ce35d6-1fd1-866b-df57-aafdfb896cd1@oracle.com> Message-ID: <2D4B540C-EAAF-4AD9-AB66-1A8FB7070152@ix.netcom.com> Amazing. With that option disabled, the runtime falls from 36 seconds to 22 seconds. It also eliminated the significant overhead previously seen when running under the async profiler. The system cpu is < 3% and the idle is < 3%. The system % is much closer to the ideal for a test like this. Somewhat unexpected, but any spinning for locks now has a detrimental effect on performance. In the ?real world? test, it didn?t seem to make much difference, but I haven?t fully reviewed that code in light of findings in the micro benchmarks. The updated profiler shows: which is interesting because the #1 consumer is still the ForkJoin pool parking while waiting for work - even though the system and idle percentages are so low. Can you briefly describe what that runtime option does? > On Jan 5, 2023, at 1:05 AM, Alan Bateman wrote: > > On 05/01/2023 00:54, robert engels wrote: >> >> >>> On Jan 4, 2023, at 3:32 AM, Alan Bateman > wrote: >>> >>> -XX:+UnlockExperimentalVMOptions -XX:+DoJVMTIVirtualThreadTransitions >> >> As an fyi, the above did not affect the async profiler trace that I could tell. I get similar profilers with both the Intellij profiler and the async profiler. > > Oops, a typo in my mail, it should be -XX:-DoJVMTIVirtualThreadTransitions to disable (not '+' to enable). > > -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: PastedGraphic-4.png Type: image/png Size: 326415 bytes Desc: not available URL: From pedro.lamarao at prodist.com.br Thu Jan 5 12:56:01 2023 From: pedro.lamarao at prodist.com.br (=?UTF-8?Q?Pedro_Lamar=C3=A3o?=) Date: Thu, 5 Jan 2023 09:56:01 -0300 Subject: [External] : Re: StructuredTaskScope and Futures In-Reply-To: <538344709.77477288.1672851451955.JavaMail.zimbra@u-pem.fr> References: <1009113343.75754648.1672741919013.JavaMail.zimbra@u-pem.fr> <5FBD5E84-6A71-41BB-8179-E5FF87E255B6@oracle.com> <1526188641.77436768.1672847643264.JavaMail.zimbra@u-pem.fr> <1FF55B57-DB86-4C62-B454-F3A62813CB0A@oracle.com> <538344709.77477288.1672851451955.JavaMail.zimbra@u-pem.fr> Message-ID: > > 2. If the purpose is just logging, wouldn?t it be more helpful if, upon > failure, the policy would add all the exceptions as suppressed exceptions > to the one it throws? Moreover, if you want to log an exception associated > with each specific fork, the forks could log it themselves. > > > Those suppressed exceptions are interesting, independently of the success > of the computation. > If each fork logs itself, you make the monitoring work harder because you > are loosing the information that the errors are part of the same > computation. > This is solved by log correlation techniques that you already need in order to solve the same problem for the internal logging of each task. -- Pedro Lamar?o -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnaud.masson at fr.ibm.com Thu Jan 5 13:16:14 2023 From: arnaud.masson at fr.ibm.com (Arnaud Masson) Date: Thu, 5 Jan 2023 13:16:14 +0000 Subject: : Re: StructuredTaskScope and Futures In-Reply-To: <2A2A3D3B-4FE2-41D4-8478-BBA21AB6E976@oracle.com> References: <1009113343.75754648.1672741919013.JavaMail.zimbra@u-pem.fr> <5FBD5E84-6A71-41BB-8179-E5FF87E255B6@oracle.com> <1526188641.77436768.1672847643264.JavaMail.zimbra@u-pem.fr> <1FF55B57-DB86-4C62-B454-F3A62813CB0A@oracle.com> <4ccb11e6-4719-da59-ead2-ed9d673aeeca@oracle.com> <3f85cc7e-f124-d40a-4b6b-0a20f56140f6@cs.fau.de> <2A2A3D3B-4FE2-41D4-8478-BBA21AB6E976@oracle.com> Message-ID: I prefer the Supplier approach a lot. Future usage in StructuredTaskScope looks weird especially since it reintroduces async style ?legacy? where we don?t expect it. Btw has a safer lambda-oriented API been considered (as an optional static helper)? for example: var sum = StructuredTaskScope.execute( () -> task1(), () -> task2(), (result1, result2) -> result1 + result2 ) // throws if any error in one of the parallel tasks (It could be defined for 2,3,4? args) Thanks Arnaud That is exactly what Supplier.get() would do. It will not block, but throw an IllegalStateException if called before the scope is joined. There is no need for it to every throw any ?logic? exception, because failures would be handled collectively by the policy immediately after joining. In the ShutdownOnFailure case, you would then call get once you know the forks have succeeded. In the ShutdownOnSuccess case, you won?t use the Supplier at all (just ShutdownOnSuccess.result()). ? Ron Unless otherwise stated above: Compagnie IBM France Si?ge Social : 17, avenue de l'Europe, 92275 Bois-Colombes Cedex RCS Nanterre 552 118 465 Forme Sociale : S.A.S. Capital Social : 664 069 390,60 ? SIRET : 552 118 465 03644 - Code NAF 6203Z -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron.pressler at oracle.com Thu Jan 5 14:31:56 2023 From: ron.pressler at oracle.com (Ron Pressler) Date: Thu, 5 Jan 2023 14:31:56 +0000 Subject: : Re: StructuredTaskScope and Futures In-Reply-To: References: <1009113343.75754648.1672741919013.JavaMail.zimbra@u-pem.fr> <5FBD5E84-6A71-41BB-8179-E5FF87E255B6@oracle.com> <1526188641.77436768.1672847643264.JavaMail.zimbra@u-pem.fr> <1FF55B57-DB86-4C62-B454-F3A62813CB0A@oracle.com> <4ccb11e6-4719-da59-ead2-ed9d673aeeca@oracle.com> <3f85cc7e-f124-d40a-4b6b-0a20f56140f6@cs.fau.de> <2A2A3D3B-4FE2-41D4-8478-BBA21AB6E976@oracle.com> Message-ID: <1CDB1511-C61E-44F7-839B-BFF1A815689B@oracle.com> On 5 Jan 2023, at 13:16, Arnaud Masson > wrote: I prefer the Supplier approach a lot. Future usage in StructuredTaskScope looks weird especially since it reintroduces async style ?legacy? where we don?t expect it. The original thinking was that: 1. fork returning Future would feel more familiar to programmers acquainted with ExecutorService.submit 2. We didn?t know how important it would be to match exceptions to particular forks. That?s what we're trying to learn now. Btw has a safer lambda-oriented API been considered (as an optional static helper)? for example: var sum = StructuredTaskScope.execute( () -> task1(), () -> task2(), (result1, result2) -> result1 + result2 ) // throws if any error in one of the parallel tasks (It could be defined for 2,3,4? args) Yes. Pretty much any approach you can imagine has been tried. However, libraries are welcome to build convenience methods for common situations on top of STS as they see fit. ? Ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron.pressler at oracle.com Thu Jan 5 14:37:06 2023 From: ron.pressler at oracle.com (Ron Pressler) Date: Thu, 5 Jan 2023 14:37:06 +0000 Subject: [External] : API proposal for StructuredTaskScope In-Reply-To: <1656042197.78345370.1672915566603.JavaMail.zimbra@u-pem.fr> References: <1656042197.78345370.1672915566603.JavaMail.zimbra@u-pem.fr> Message-ID: We have considered such approaches. One glaring problem is the case of ?heterogenous tasks?, i.e. tasks that each return a result of a different type. This is a very common scenario for ShutdownOnFailure. In the homogenous case, we already have a similar API/concept we can exploit: Stream. I.e. the Stream API could be used for simple and common homogenous structured concurrency operations. This is now being actively explored. ? Ron > On 5 Jan 2023, at 10:46, Remi Forax wrote: > > Hi all, > this is a proposal of a slightly different API for StructuredTaskScope > > The idea is to provide as parameter of the constructor of StructuredTaskScope a "reducer" that get the value | error from each task and try to compute a result from it. > A reducer is quite similar in intent to a stream Collector but it's a different API. > > Before deep diving into the details, here are some examples of how to use it. > Like the current API, as task is submitted with fork() but unlike the current API, fork() returns void instead of a Future. > Then there is a method result() that works like join() but also returns the computed result of the tasks by the reducer. > > If you ask for a Reducer.toList(), the method result() returns a List of all results (a Result is a record with three components, a state (SUCCEED or FAILED), an element is SUCCEED and a suppressed exception (which itself can has suppressed exceptions) for all the exceptions that you may care or not). > > public static void toList() throws InterruptedException { > try(var scope = StructuredTaskScope.of(Reducer.toList())) { > scope.fork(() -> 3); > scope.fork(() -> { > throw new IOException(); > }); > > List> list = scope.result(); > System.out.println(list); // [Result[state=FAILED, element=null, suppressed=java.io.IOException], Result[state=SUCCEED, element=3, suppressed=null]] > } > } > > When you run the code above several times, the two results exchange location in the list which is normal. > > You may want only one result, for that you have Reducer.max(comparator) that will give you either an Optional.empty() if there is no call to fork(), or a failed result if no results succeed or the maximum result once at least one succeeded result is available > > > public static void max() throws InterruptedException { > try(var scope = StructuredTaskScope.of(Reducer.max(Integer::compareTo))) { > scope.fork(() -> 3); > scope.fork(() -> { > throw new IOException(); > }); > scope.fork(() -> 42); > > Optional> max = scope.result(); > System.out.println(max); // Optional[Result[state=SUCCEED, element=42, suppressed=java.io.IOException]] > } > } > > When you run this code several times, you always have the same max value. > > > You may also want the first result that in success, for that you have Reducer.first() that returns Optional.empty if there is no fork(), a failed result if no task succeed or the first result that succeed (the previous suppressed exception are also available for logging if you want). > > public static void first() throws InterruptedException { > try(var scope = StructuredTaskScope.of(Reducer.first())) { > scope.fork(() -> { > throw new IOException(); > }); > scope.fork(() -> 3); > scope.fork(() -> 42); > > Optional> first = scope.result(); > System.out.println(first); // Optional[Result[state=SUCCEED, element=3, suppressed=java.io.IOException]] > } > } > > When you run this code several times, the returned result can also be 42 and the suppressed exception may or may not be present. > > > So what is a Reducer, it's a record with two functions, a combiner and a finisher, the combiner combines the different results and the finisher provides a nicer object like java.util.List or java.util.Optional as result at the end. > > @FunctionalInterface > public interface Combiner { > A apply(A oldValue, Result result, Runnable shouldShutdown); > } > > public record Reducer(Combiner combiner, Function finisher) {} > > The Reducer API is a little bit complex because it hides the fact that several virtual threads may want to combine their results at the same time. > So the combiner function can be called several time with the same result (it's called in the loop that does a CAS). > The API supposes that both functions do not do any side effects, otherwise there will be concurrency issues. > > The combiner also have a third parameter that ask to gently stop the computation (by calling shouldShutdown.run()), this interrupts all other threads if a result is good enough. > > The prototype is here > https://urldefense.com/v3/__https://github.com/forax/loom-fiber/blob/master/src/main/java/fr/umlv/loom/reducer/StructuredAsyncScope.java__;!!ACWV5N9M2RV99hQ!M1q6KXpg3ACLN-m4TGq83WRYJcNpU3ycnXg_ndGT9-uJxigOt9bKvfkAH0W3WSbOkN4YJyfT9RHcTKYHhEQ$ > > If you want to see the gritty details :) > > regards, > R?mi From ron.pressler at oracle.com Thu Jan 5 15:13:06 2023 From: ron.pressler at oracle.com (Ron Pressler) Date: Thu, 5 Jan 2023 15:13:06 +0000 Subject: Project Loom VirtualThreads hang In-Reply-To: <2D4B540C-EAAF-4AD9-AB66-1A8FB7070152@ix.netcom.com> References: <96631C23-9C63-4848-B310-C0521FB094E9@ix.netcom.com> <71ce35d6-1fd1-866b-df57-aafdfb896cd1@oracle.com> <2D4B540C-EAAF-4AD9-AB66-1A8FB7070152@ix.netcom.com> Message-ID: <9603A6B9-0A8A-4359-969D-C611A30FEBDF@oracle.com> > On 5 Jan 2023, at 12:36, robert engels wrote: > > which is interesting because the #1 consumer is still the ForkJoin pool parking while waiting for work - even though the system and idle percentages are so low. Parks in the scheduler are usually a result of workers being starved for work due to a high relative rate of contention. A high relative contention rate is usually an application problem and shouldn?t be common in well-architected ones. Try adding more instances of a queue+producers+consumers, and you should see fewer parks. Alternatively, reduce the scheduler?s parallelism with `-Djdk.virtualThreadScheduler.parallelism=N` where N is smaller than the number of cores. In these situations (that typically arise only in artificial benchmarks) the result could even be improved overall performance. ? Ron From forax at univ-mlv.fr Thu Jan 5 15:22:51 2023 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Thu, 5 Jan 2023 16:22:51 +0100 (CET) Subject: [External] : API proposal for StructuredTaskScope In-Reply-To: References: <1656042197.78345370.1672915566603.JavaMail.zimbra@u-pem.fr> Message-ID: <1820007192.78636534.1672932171087.JavaMail.zimbra@u-pem.fr> ----- Original Message ----- > From: "Ron Pressler" > To: "Remi Forax" > Cc: "loom-dev" > Sent: Thursday, January 5, 2023 3:37:06 PM > Subject: Re: [External] : API proposal for StructuredTaskScope > We have considered such approaches. > > One glaring problem is the case of ?heterogenous tasks?, i.e. tasks that each > return a result of a different type. This is a very common scenario for > ShutdownOnFailure. I believe that using a static factory instead of a constructor (here StructuredTaskScope.of()) solve that pretty well. If no type is explicitly provided, the inference will default to Object which is exactly what you want in case of a shutdown on failure. > > In the homogenous case, we already have a similar API/concept we can exploit: > Stream. I.e. the Stream API could be used for simple and common homogenous > structured concurrency operations. This is now being actively explored. yes, i've written a prototype of that too. I maybe wrong but using a Stream requires an intermediary queue, something you don't need if you reduce the task values one at a time. Also, a stream of tuples (result, exception) is not something that is currently easy to use. Sure, you can add new Collectors to make it easier to use ... at that point, using a reducer/collector directly starts to become appealing :) > > ? Ron R?mi > > >> On 5 Jan 2023, at 10:46, Remi Forax wrote: >> >> Hi all, >> this is a proposal of a slightly different API for StructuredTaskScope >> >> The idea is to provide as parameter of the constructor of StructuredTaskScope a >> "reducer" that get the value | error from each task and try to compute a result >> from it. >> A reducer is quite similar in intent to a stream Collector but it's a different >> API. >> >> Before deep diving into the details, here are some examples of how to use it. >> Like the current API, as task is submitted with fork() but unlike the current >> API, fork() returns void instead of a Future. >> Then there is a method result() that works like join() but also returns the >> computed result of the tasks by the reducer. >> >> If you ask for a Reducer.toList(), the method result() returns a List of all >> results (a Result is a record with three components, a state (SUCCEED or >> FAILED), an element is SUCCEED and a suppressed exception (which itself can has >> suppressed exceptions) for all the exceptions that you may care or not). >> >> public static void toList() throws InterruptedException { >> try(var scope = StructuredTaskScope.of(Reducer.toList())) { >> scope.fork(() -> 3); >> scope.fork(() -> { >> throw new IOException(); >> }); >> >> List> list = scope.result(); >> System.out.println(list); // [Result[state=FAILED, element=null, >> suppressed=java.io.IOException], Result[state=SUCCEED, element=3, >> suppressed=null]] >> } >> } >> >> When you run the code above several times, the two results exchange location in >> the list which is normal. >> >> You may want only one result, for that you have Reducer.max(comparator) that >> will give you either an Optional.empty() if there is no call to fork(), or a >> failed result if no results succeed or the maximum result once at least one >> succeeded result is available >> >> >> public static void max() throws InterruptedException { >> try(var scope = StructuredTaskScope.of(Reducer.max(Integer::compareTo))) { >> scope.fork(() -> 3); >> scope.fork(() -> { >> throw new IOException(); >> }); >> scope.fork(() -> 42); >> >> Optional> max = scope.result(); >> System.out.println(max); // Optional[Result[state=SUCCEED, element=42, >> suppressed=java.io.IOException]] >> } >> } >> >> When you run this code several times, you always have the same max value. >> >> >> You may also want the first result that in success, for that you have >> Reducer.first() that returns Optional.empty if there is no fork(), a failed >> result if no task succeed or the first result that succeed (the previous >> suppressed exception are also available for logging if you want). >> >> public static void first() throws InterruptedException { >> try(var scope = StructuredTaskScope.of(Reducer.first())) { >> scope.fork(() -> { >> throw new IOException(); >> }); >> scope.fork(() -> 3); >> scope.fork(() -> 42); >> >> Optional> first = scope.result(); >> System.out.println(first); // Optional[Result[state=SUCCEED, element=3, >> suppressed=java.io.IOException]] >> } >> } >> >> When you run this code several times, the returned result can also be 42 and the >> suppressed exception may or may not be present. >> >> >> So what is a Reducer, it's a record with two functions, a combiner and a >> finisher, the combiner combines the different results and the finisher provides >> a nicer object like java.util.List or java.util.Optional as result at the end. >> >> @FunctionalInterface >> public interface Combiner { >> A apply(A oldValue, Result result, Runnable shouldShutdown); >> } >> >> public record Reducer(Combiner combiner, Function> extends V> finisher) {} >> >> The Reducer API is a little bit complex because it hides the fact that several >> virtual threads may want to combine their results at the same time. >> So the combiner function can be called several time with the same result (it's >> called in the loop that does a CAS). >> The API supposes that both functions do not do any side effects, otherwise there >> will be concurrency issues. >> >> The combiner also have a third parameter that ask to gently stop the computation >> (by calling shouldShutdown.run()), this interrupts all other threads if a >> result is good enough. >> >> The prototype is here >> https://urldefense.com/v3/__https://github.com/forax/loom-fiber/blob/master/src/main/java/fr/umlv/loom/reducer/StructuredAsyncScope.java__;!!ACWV5N9M2RV99hQ!M1q6KXpg3ACLN-m4TGq83WRYJcNpU3ycnXg_ndGT9-uJxigOt9bKvfkAH0W3WSbOkN4YJyfT9RHcTKYHhEQ$ >> >> If you want to see the gritty details :) >> >> regards, > > R?mi From Alan.Bateman at oracle.com Thu Jan 5 15:28:13 2023 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 5 Jan 2023 15:28:13 +0000 Subject: Project Loom VirtualThreads hang In-Reply-To: <2D4B540C-EAAF-4AD9-AB66-1A8FB7070152@ix.netcom.com> References: <96631C23-9C63-4848-B310-C0521FB094E9@ix.netcom.com> <71ce35d6-1fd1-866b-df57-aafdfb896cd1@oracle.com> <2D4B540C-EAAF-4AD9-AB66-1A8FB7070152@ix.netcom.com> Message-ID: <987277f2-bcb1-bc38-5ae0-00f65fbaa076@oracle.com> On 05/01/2023 12:36, robert engels wrote: > : > > The system cpu is < 3% and the idle is < 3%. The system % is much > closer to the ideal for a test like this. Somewhat unexpected, but any > spinning for locks now has a detrimental effect on performance.: > > Can you briefly describe what that runtime option does? > The interface for debuggers, profilers, and other tooling is the JVM Tool Interface. This is a native interface and poses a number of challenges for areas of the runtime that are implemented in Java code rather than in the VM. Right now, there are some scalability and performance issues with JVMTI when using virtual threads. Work is in progress to address some of this. In the mean-time, it means that some proifiling tools may impact performance and skew profiles. The XX flag disables calls into the VM to notify JVMTI when virtual threads are parking/unparking, something that an async profiler probably doesn't need. That mechanism also has a mutex in the VM to coordinate the thread transitions which I think is the surprising sys time that you saw in the original profile. -Alan From spullara at gmail.com Thu Jan 5 18:01:59 2023 From: spullara at gmail.com (Sam Pullara) Date: Thu, 5 Jan 2023 10:01:59 -0800 Subject: [External] : Re: Project Loom VirtualThreads hang In-Reply-To: References: <96631C23-9C63-4848-B310-C0521FB094E9@ix.netcom.com> <8AC301FC-6E3B-49CC-9215-E5CF0421AB16@ix.netcom.com> Message-ID: I think the biggest concern of completely moving to virtual threads is that they don't fairly share the CPU when there are more than cores virtual threads. This makes me hesitant to say they are the default. On Thu, Jan 5, 2023 at 3:34 AM Ron Pressler wrote: > The main thing I am trying to get across is not that virtual threads work > best *only* when their number is high, but that the right way to adopt them > is not to replace a platform thread with a virtual thread, but to represent > some domain object (a request, a message etc.) with a virtual thread, and > then, *as a result*, the number of virtual threads becomes a function of > the load and will be high for systems under high load. This is particularly > easy to do in very straightforward programs that don?t manually manage > platform threads, and in these use-cases ? where a virtual thread *doesn?t* > replace a platform thread but some other object ? we already match or > exceed Go?s performance, especially when there?s some real work done. > Adopting virtual threads in a useful manner in systems that depend on > careful management of platform threads is harder. > > ? Ron > > > On 5 Jan 2023, at 01:01, robert engels wrote: > > > > Understood. Thanks. > > > > For a large swath of ?message systems? you are talking about hundreds of > clients, not thousands, and certainly not millions. I am particularly > referring to financial/trading systems. > > > > These usually use a fan-out structure so any given node only has < 100 > clients and often far smaller than that. Latency is a huge concern however. > This can be done with async IO and native threads but it doesn?t ?feel like > Java? - and is certainly harder to understand/maintain in my opinion. > > > > If Loom allowed Go like performance it would be a killer solution for > these ?router? type nodes. > > > > But please don?t take this as a strong criticism - in my testing Loom > is within 10% of Go performance as it is today - which is a remarkable > achievement especially given the backwards compatibility/programming model. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron.pressler at oracle.com Thu Jan 5 18:45:42 2023 From: ron.pressler at oracle.com (Ron Pressler) Date: Thu, 5 Jan 2023 18:45:42 +0000 Subject: [External] : Re: Project Loom VirtualThreads hang In-Reply-To: References: <96631C23-9C63-4848-B310-C0521FB094E9@ix.netcom.com> <8AC301FC-6E3B-49CC-9215-E5CF0421AB16@ix.netcom.com> Message-ID: <1F382E46-A3AD-40B9-8895-292FC08D9031@oracle.com> > On 5 Jan 2023, at 18:01, Sam Pullara wrote: > > I think the biggest concern of completely moving to virtual threads is that they don't fairly share the CPU when there are more than cores virtual threads. This makes me hesitant to say they are the default. Note that existing Java servers also don?t rely on time-sharing even when using platform threads. Non-realtime kernels usually only employ time-sharing when the CPU is at 100%. I think that the vast majority of Java servers don?t run at 100% CPU utilisation, and when they do, I don?t think anyone is particularly happy with the result. In fact, the scheduling offered by fixed thread pools that are commonly used in thread-per-request servers is far *less* ?fair?, or shared, than virtual threads. It is not hard to add time-sharing to virtual threads, it?s just that I think people have an incorrect impression of how useful time-sharing is for server workloads. BTW, even parallel streams, which are designed for CPU-bound workloads, don?t offer time-sharing. Asynchronous constructs in the JDK or Java libraries don?t offer time-sharing, either. We would gladly consider adding time-sharing to virtual threads if anyone finds reasonable workloads where it actually helps considerably. I?m not saying there aren?t any, it?s just that we haven?t seen them yet. Perhaps wider use of virtual threads in the field will expose some. ? Ron From spullara at gmail.com Thu Jan 5 19:02:38 2023 From: spullara at gmail.com (Sam Pullara) Date: Thu, 5 Jan 2023 11:02:38 -0800 Subject: [External] : Re: Project Loom VirtualThreads hang In-Reply-To: <1F382E46-A3AD-40B9-8895-292FC08D9031@oracle.com> References: <96631C23-9C63-4848-B310-C0521FB094E9@ix.netcom.com> <8AC301FC-6E3B-49CC-9215-E5CF0421AB16@ix.netcom.com> <1F382E46-A3AD-40B9-8895-292FC08D9031@oracle.com> Message-ID: So the place where this comes up is when you do a short computation but use tons of threads to do it. Like, for example, I have a brute force embedding search library that uses parallel streams to do the query. If that takes a few seconds (or even hundreds of ms) I still want other threads doing more mundane, fast work to get CPU time rather than every other computation on the system being blocked. On Thu, Jan 5, 2023 at 10:45 AM Ron Pressler wrote: > > > > On 5 Jan 2023, at 18:01, Sam Pullara wrote: > > > > I think the biggest concern of completely moving to virtual threads is > that they don't fairly share the CPU when there are more than cores virtual > threads. This makes me hesitant to say they are the default. > > Note that existing Java servers also don?t rely on time-sharing even when > using platform threads. Non-realtime kernels usually only employ > time-sharing when the CPU is at 100%. I think that the vast majority of > Java servers don?t run at 100% CPU utilisation, and when they do, I don?t > think anyone is particularly happy with the result. In fact, the scheduling > offered by fixed thread pools that are commonly used in thread-per-request > servers is far *less* ?fair?, or shared, than virtual threads. > > It is not hard to add time-sharing to virtual threads, it?s just that I > think people have an incorrect impression of how useful time-sharing is for > server workloads. BTW, even parallel streams, which are designed for > CPU-bound workloads, don?t offer time-sharing. Asynchronous constructs in > the JDK or Java libraries don?t offer time-sharing, either. > > We would gladly consider adding time-sharing to virtual threads if anyone > finds reasonable workloads where it actually helps considerably. I?m not > saying there aren?t any, it?s just that we haven?t seen them yet. Perhaps > wider use of virtual threads in the field will expose some. > > ? Ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From pedro.lamarao at prodist.com.br Thu Jan 5 19:29:39 2023 From: pedro.lamarao at prodist.com.br (=?UTF-8?Q?Pedro_Lamar=C3=A3o?=) Date: Thu, 5 Jan 2023 16:29:39 -0300 Subject: [External] : Re: Project Loom VirtualThreads hang In-Reply-To: References: <96631C23-9C63-4848-B310-C0521FB094E9@ix.netcom.com> <8AC301FC-6E3B-49CC-9215-E5CF0421AB16@ix.netcom.com> <1F382E46-A3AD-40B9-8895-292FC08D9031@oracle.com> Message-ID: Em qui., 5 de jan. de 2023 ?s 16:04, Sam Pullara escreveu: > So the place where this comes up is when you do a short computation but > use tons of threads to do it. Like, for example, I have a brute force > embedding search library that uses parallel streams to do the query. If > that takes a few seconds (or even hundreds of ms) I still want other > threads doing more mundane, fast work to get CPU time rather than every > other computation on the system being blocked. > If this system processes more than one request at a time, you will not want any single request to occupy 100% processor time anyway. If you do have spare processor time, those fast tasks will get done. If you do not, your system has crossed the line to instability, and all tasks, not only the fast ones, will receive a penalty. In cases like these, time sharing, like disk swapping, is a last resort to keep the system running. -- Pedro Lamar?o -------------- next part -------------- An HTML attachment was scrubbed... URL: From thurston.nomagicsoftware at gmail.com Thu Jan 5 20:43:21 2023 From: thurston.nomagicsoftware at gmail.com (thurston N) Date: Thu, 5 Jan 2023 12:43:21 -0800 Subject: [External] : Re: Project Loom VirtualThreads hang In-Reply-To: <1F382E46-A3AD-40B9-8895-292FC08D9031@oracle.com> References: <96631C23-9C63-4848-B310-C0521FB094E9@ix.netcom.com> <8AC301FC-6E3B-49CC-9215-E5CF0421AB16@ix.netcom.com> <1F382E46-A3AD-40B9-8895-292FC08D9031@oracle.com> Message-ID: "It is not hard to add time-sharing to virtual threads" If so, how hard would it be to add *user-directed timesharing*. e.g. VirtualThreads.yield(reschedule=LOW_PRIORITY) // a strong hint to scheduler to run other Continuations (that's other continuations not just other "tasks") before resuming current continuation I don't know if that ameliorates Sam's specific situation or not, but it's not difficult to think of many circumstances that could benefit from such an ability. One of the core ideas of coroutines is cooperative multitasking, now I suppose one could rejoin with CONTINUATIONS ARE NOT COROUTINES, but so what? what's wrong with cooperative-multitasking continuations? It's one thing not to have automated timesharing built into the scheduler (which I would think would be difficult to do well, but IDK), it's quite another to afford no opportunity for user-level code to "control the scheduling" (how about "influence" or "affect" vis a vis "control"?) This strikes me as a bit of a circular argument, viz. if your target/focus is workloads with a lot of *short-lived* tasks, then yeah, it's going to be difficult to conjure scenarios where automated timesharing will make any difference (in the extreme case where every task runs shorter than its allotted time quantum, then time-slicing can make no difference at all) -T On Thu, Jan 5, 2023 at 10:45 AM Ron Pressler wrote: > > > > On 5 Jan 2023, at 18:01, Sam Pullara wrote: > > > > I think the biggest concern of completely moving to virtual threads is > that they don't fairly share the CPU when there are more than cores virtual > threads. This makes me hesitant to say they are the default. > > Note that existing Java servers also don?t rely on time-sharing even when > using platform threads. Non-realtime kernels usually only employ > time-sharing when the CPU is at 100%. I think that the vast majority of > Java servers don?t run at 100% CPU utilisation, and when they do, I don?t > think anyone is particularly happy with the result. In fact, the scheduling > offered by fixed thread pools that are commonly used in thread-per-request > servers is far *less* ?fair?, or shared, than virtual threads. > > It is not hard to add time-sharing to virtual threads, it?s just that I > think people have an incorrect impression of how useful time-sharing is for > server workloads. BTW, even parallel streams, which are designed for > CPU-bound workloads, don?t offer time-sharing. Asynchronous constructs in > the JDK or Java libraries don?t offer time-sharing, either. > > We would gladly consider adding time-sharing to virtual threads if anyone > finds reasonable workloads where it actually helps considerably. I?m not > saying there aren?t any, it?s just that we haven?t seen them yet. Perhaps > wider use of virtual threads in the field will expose some. > > ? Ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From rengels at ix.netcom.com Thu Jan 5 21:24:40 2023 From: rengels at ix.netcom.com (Robert Engels) Date: Thu, 5 Jan 2023 15:24:40 -0600 Subject: [External] : Re: Project Loom VirtualThreads hang In-Reply-To: <1F382E46-A3AD-40B9-8895-292FC08D9031@oracle.com> References: <1F382E46-A3AD-40B9-8895-292FC08D9031@oracle.com> Message-ID: <6471F28E-51D5-49F3-B59F-8BE1F22C4E37@ix.netcom.com> I think it would be better to be able to park/unpark on a monitor efficiently. I think the overhead in handling that common case is more significant than expected. I like the idea of carrying over the Thread.priority in vthreads to allow finer control over the scheduling. > On Jan 5, 2023, at 12:45 PM, Ron Pressler wrote: > > ? > >> On 5 Jan 2023, at 18:01, Sam Pullara wrote: >> >> I think the biggest concern of completely moving to virtual threads is that they don't fairly share the CPU when there are more than cores virtual threads. This makes me hesitant to say they are the default. > > Note that existing Java servers also don?t rely on time-sharing even when using platform threads. Non-realtime kernels usually only employ time-sharing when the CPU is at 100%. I think that the vast majority of Java servers don?t run at 100% CPU utilisation, and when they do, I don?t think anyone is particularly happy with the result. In fact, the scheduling offered by fixed thread pools that are commonly used in thread-per-request servers is far *less* ?fair?, or shared, than virtual threads. > > It is not hard to add time-sharing to virtual threads, it?s just that I think people have an incorrect impression of how useful time-sharing is for server workloads. BTW, even parallel streams, which are designed for CPU-bound workloads, don?t offer time-sharing. Asynchronous constructs in the JDK or Java libraries don?t offer time-sharing, either. > > We would gladly consider adding time-sharing to virtual threads if anyone finds reasonable workloads where it actually helps considerably. I?m not saying there aren?t any, it?s just that we haven?t seen them yet. Perhaps wider use of virtual threads in the field will expose some. > > ? Ron From rengels at ix.netcom.com Thu Jan 5 21:26:31 2023 From: rengels at ix.netcom.com (Robert Engels) Date: Thu, 5 Jan 2023 15:26:31 -0600 Subject: [External] : Re: Project Loom VirtualThreads hang In-Reply-To: <6471F28E-51D5-49F3-B59F-8BE1F22C4E37@ix.netcom.com> References: <6471F28E-51D5-49F3-B59F-8BE1F22C4E37@ix.netcom.com> Message-ID: <91C87111-1E87-4644-A84C-FEF703F273A6@ix.netcom.com> Didn?t the original Java green threads support the priorities properly - then it was a noop with the original native implementation- then Sun brought us back for some platforms and RTOS. > On Jan 5, 2023, at 3:24 PM, Robert Engels wrote: > > ?I think it would be better to be able to park/unpark on a monitor efficiently. I think the overhead in handling that common case is more significant than expected. > > I like the idea of carrying over the Thread.priority in vthreads to allow finer control over the scheduling. > >> On Jan 5, 2023, at 12:45 PM, Ron Pressler wrote: >> >> ? >> >>>> On 5 Jan 2023, at 18:01, Sam Pullara wrote: >>> >>> I think the biggest concern of completely moving to virtual threads is that they don't fairly share the CPU when there are more than cores virtual threads. This makes me hesitant to say they are the default. >> >> Note that existing Java servers also don?t rely on time-sharing even when using platform threads. Non-realtime kernels usually only employ time-sharing when the CPU is at 100%. I think that the vast majority of Java servers don?t run at 100% CPU utilisation, and when they do, I don?t think anyone is particularly happy with the result. In fact, the scheduling offered by fixed thread pools that are commonly used in thread-per-request servers is far *less* ?fair?, or shared, than virtual threads. >> >> It is not hard to add time-sharing to virtual threads, it?s just that I think people have an incorrect impression of how useful time-sharing is for server workloads. BTW, even parallel streams, which are designed for CPU-bound workloads, don?t offer time-sharing. Asynchronous constructs in the JDK or Java libraries don?t offer time-sharing, either. >> >> We would gladly consider adding time-sharing to virtual threads if anyone finds reasonable workloads where it actually helps considerably. I?m not saying there aren?t any, it?s just that we haven?t seen them yet. Perhaps wider use of virtual threads in the field will expose some. >> >> ? Ron From ron.pressler at oracle.com Thu Jan 5 22:52:00 2023 From: ron.pressler at oracle.com (Ron Pressler) Date: Thu, 5 Jan 2023 22:52:00 +0000 Subject: [External] : Re: Project Loom VirtualThreads hang In-Reply-To: References: <96631C23-9C63-4848-B310-C0521FB094E9@ix.netcom.com> <8AC301FC-6E3B-49CC-9215-E5CF0421AB16@ix.netcom.com> <1F382E46-A3AD-40B9-8895-292FC08D9031@oracle.com> Message-ID: <01FFBDBC-2A4A-4CBB-BD8B-1C44D60BC145@oracle.com> > On 5 Jan 2023, at 19:02, Sam Pullara wrote: > > So the place where this comes up is when you do a short computation but use tons of threads to do it. Like, for example, I have a brute force embedding search library that uses parallel streams to do the query. If that takes a few seconds (or even hundreds of ms) I still want other threads doing more mundane, fast work to get CPU time rather than every other computation on the system being blocked. Virtual threads would behave the same way as platform threads in this case. First, there is no time-sharing among parallel stream tasks anyway today, but there is time-sharing between parallel streams and other threads, be they platform or virtual. From ron.pressler at oracle.com Thu Jan 5 23:00:26 2023 From: ron.pressler at oracle.com (Ron Pressler) Date: Thu, 5 Jan 2023 23:00:26 +0000 Subject: [External] : Re: Project Loom VirtualThreads hang In-Reply-To: <6471F28E-51D5-49F3-B59F-8BE1F22C4E37@ix.netcom.com> References: <1F382E46-A3AD-40B9-8895-292FC08D9031@oracle.com> <6471F28E-51D5-49F3-B59F-8BE1F22C4E37@ix.netcom.com> Message-ID: <1025FBDC-680E-4173-A20E-702967EA5139@oracle.com> > On 5 Jan 2023, at 21:24, Robert Engels wrote: > > I think it would be better to be able to park/unpark on a monitor efficiently. I think the overhead in handling that common case is more significant than expected. We know; it?s work-in-progress, but will take some time. > > I like the idea of carrying over the Thread.priority in vthreads to allow finer control over the scheduling. Scheduling with priorities can either be done well or fast but not both. Non-realtime kernels schedule relatively fast, but their priority implementation isn?t that good; realtime kernels do priorities well, but their scheduling is very slow (realtime always trades off predictability for speed). Respecting priorities becomes even harder when there are lots and lots of threads, and problems such as priority inversion certainly don?t get easier. For the common cases where you have a small set of low-priority threads doing work in the background, the easiest solution is just to use platform threads for those. As in the case of time-sharing, the need for priorities is something that will need to be demonstrated in real projects in the field to justify addressing. ? Ron From ron.pressler at oracle.com Thu Jan 5 23:01:59 2023 From: ron.pressler at oracle.com (Ron Pressler) Date: Thu, 5 Jan 2023 23:01:59 +0000 Subject: [External] : Re: Project Loom VirtualThreads hang In-Reply-To: References: <96631C23-9C63-4848-B310-C0521FB094E9@ix.netcom.com> <8AC301FC-6E3B-49CC-9215-E5CF0421AB16@ix.netcom.com> <1F382E46-A3AD-40B9-8895-292FC08D9031@oracle.com> Message-ID: <573BECB8-3585-4A5F-A598-D8B03E54B160@oracle.com> > On 5 Jan 2023, at 20:43, thurston N wrote: > > "It is not hard to add time-sharing to virtual threads" > > If so, how hard would it be to add *user-directed timesharing*. e.g. > > VirtualThreads.yield(reschedule=LOW_PRIORITY) // a strong hint to scheduler to run other Continuations (that's other continuations not just other "tasks") before resuming current continuation > > I don't know if that ameliorates Sam's specific situation or not, but it's not difficult to think of many circumstances that could benefit from such an ability. > One of the core ideas of coroutines is cooperative multitasking, now I suppose one could rejoin with CONTINUATIONS ARE NOT COROUTINES, but so what? what's wrong with cooperative-multitasking continuations? > > It's one thing not to have automated timesharing built into the scheduler (which I would think would be difficult to do well, but IDK), it's quite another to afford no opportunity for user-level code to "control the scheduling" (how about "influence" or "affect" vis a vis "control"?) > > This strikes me as a bit of a circular argument, viz. if your target/focus is workloads with a lot of *short-lived* tasks, then yeah, it's going to be difficult to conjure scenarios where automated timesharing will make any difference (in the extreme case where every task runs shorter than its allotted time quantum, then time-slicing can make no difference at all) > > > -T Custom schedulers are on the roadmap, and will probably not take long to arrive, but we need to focus the 99% use-case before turning our attention to the 1% use-case. ? Ron From rengels at ix.netcom.com Fri Jan 6 00:27:53 2023 From: rengels at ix.netcom.com (robert engels) Date: Thu, 5 Jan 2023 18:27:53 -0600 Subject: Project Loom VirtualThreads hang In-Reply-To: <987277f2-bcb1-bc38-5ae0-00f65fbaa076@oracle.com> References: <96631C23-9C63-4848-B310-C0521FB094E9@ix.netcom.com> <71ce35d6-1fd1-866b-df57-aafdfb896cd1@oracle.com> <2D4B540C-EAAF-4AD9-AB66-1A8FB7070152@ix.netcom.com> <987277f2-bcb1-bc38-5ae0-00f65fbaa076@oracle.com> Message-ID: <85841B4F-1602-4C31-BF71-BEB900E506A8@ix.netcom.com> Thanks. The surprising aspect is that the performance hit was present even when the debugger was not attached. > On Jan 5, 2023, at 9:28 AM, Alan Bateman wrote: > > On 05/01/2023 12:36, robert engels wrote: >> : >> >> The system cpu is < 3% and the idle is < 3%. The system % is much closer to the ideal for a test like this. Somewhat unexpected, but any spinning for locks now has a detrimental effect on performance.: >> >> Can you briefly describe what that runtime option does? >> > > The interface for debuggers, profilers, and other tooling is the JVM Tool Interface. This is a native interface and poses a number of challenges for areas of the runtime that are implemented in Java code rather than in the VM. Right now, there are some scalability and performance issues with JVMTI when using virtual threads. Work is in progress to address some of this. In the mean-time, it means that some proifiling tools may impact performance and skew profiles. The XX flag disables calls into the VM to notify JVMTI when virtual threads are parking/unparking, something that an async profiler probably doesn't need. That mechanism also has a mutex in the VM to coordinate the thread transitions which I think is the surprising sys time that you saw in the original profile. > > -Alan From duke at openjdk.org Fri Jan 6 09:25:03 2023 From: duke at openjdk.org (duke) Date: Fri, 6 Jan 2023 09:25:03 GMT Subject: git: openjdk/loom: fibers: 192 new changesets Message-ID: <667b6694-4b82-48f2-9f7f-ca9684d44cb5@openjdk.org> Changeset: ccb94acc Author: Chris Plummer Date: 2022-12-14 19:37:20 +0000 URL: https://git.openjdk.org/loom/commit/ccb94acc442767a7047756806c8dc7ecacd8bae9 8287812: Cleanup JDWP agent GetEnv initialization Reviewed-by: alanb, sspitsyn ! src/jdk.jdwp.agent/share/native/libjdwp/debugInit.c ! src/jdk.jdwp.agent/share/native/libjdwp/util.c Changeset: bf78f716 Author: Brent Christian Date: 2022-12-13 19:07:44 +0000 URL: https://git.openjdk.org/loom/commit/bf78f716bd3e58df24ff1e6f4a0104025379f821 8295857: Clarify that cleanup code can be skipped when the JVM terminates (e.g. when calling halt()) Reviewed-by: iris Backport-of: c7aca73177339f931f7dfb6627365548a32874f7 ! src/java.base/share/classes/java/lang/Runtime.java Changeset: c6f22b41 Author: Joe Darcy Date: 2022-12-13 20:48:13 +0000 URL: https://git.openjdk.org/loom/commit/c6f22b416072a9be5436f45e2f595ceea228f3bd 8297305: Clarify that javax.lang.model.util.Elements.overrides is irreflexive Reviewed-by: jjg ! src/java.compiler/share/classes/javax/lang/model/util/Elements.java Changeset: 61ab16f7 Author: Jonathan Gibbons Date: 2022-12-13 23:20:43 +0000 URL: https://git.openjdk.org/loom/commit/61ab16f79a735a98b3c095daf1b541f4fc5413c0 8298700: Typo in DocTree comment Reviewed-by: darcy ! src/jdk.compiler/share/classes/com/sun/source/doctree/DocTree.java Changeset: 51f0a1ce Author: Christoph Langer Date: 2022-12-14 07:32:28 +0000 URL: https://git.openjdk.org/loom/commit/51f0a1ce4b0d72cf7e82e01f7014274d8b7d1575 8298527: Cygwin's uname -m returns different string than before Reviewed-by: erikj ! make/autoconf/build-aux/config.guess Changeset: 27d49711 Author: Roland Westrelin Date: 2022-12-14 10:03:36 +0000 URL: https://git.openjdk.org/loom/commit/27d4971182ab1cbe7e6bc40cd22c1c70661a3ab2 8298520: C2: assert(found_opaque == res) failed: wrong pattern Reviewed-by: thartmann, chagedorn ! src/hotspot/share/opto/loopnode.cpp ! src/hotspot/share/opto/loopnode.hpp Changeset: 9bcdfc42 Author: Jan Lahoda Date: 2022-12-14 11:36:04 +0000 URL: https://git.openjdk.org/loom/commit/9bcdfc428597e1465c8a014d816ef671420d22df 8298425: System.console().readLine() hangs in jshell Reviewed-by: naoto, alanb ! src/jdk.jshell/share/classes/jdk/jshell/execution/JdiDefaultExecutionControl.java + test/langtools/jdk/jshell/ConsoleTest.java Changeset: 0bbc4181 Author: Andrew Haley Date: 2022-12-14 13:32:21 +0000 URL: https://git.openjdk.org/loom/commit/0bbc4181cdbccfc3a542f306ce1902cc2e9f36cb 8294902: Undefined Behavior in C2 regalloc with null references Reviewed-by: kvn, vlivanov ! src/hotspot/share/memory/arena.cpp ! src/hotspot/share/opto/bytecodeInfo.cpp ! src/hotspot/share/opto/chaitin.hpp ! src/hotspot/share/opto/postaloc.cpp ! src/hotspot/share/runtime/vmStructs.hpp ! src/hotspot/share/utilities/globalDefinitions.hpp ! src/hotspot/share/utilities/globalDefinitions_gcc.hpp Changeset: 27917014 Author: Kim Barrett Date: 2022-12-14 13:36:36 +0000 URL: https://git.openjdk.org/loom/commit/279170147a10ec2da2242b4dcb3279c41c471000 8298296: gc/TestFullGCCount.java fails with "System.gc collections miscounted." Reviewed-by: tschatzl, ayang ! test/hotspot/jtreg/ProblemList.txt ! test/hotspot/jtreg/gc/TestFullGCCount.java Changeset: 0eeaf6b2 Author: Erik Gahlin Date: 2022-12-14 13:40:15 +0000 URL: https://git.openjdk.org/loom/commit/0eeaf6b219758563712d951b3c6ff160ebeff52d 8298649: JFR: RemoteRecordingStream support for checkpoint event sizes beyond u4 Reviewed-by: mgronlun ! src/jdk.management.jfr/share/classes/jdk/management/jfr/DiskRepository.java Changeset: 581f9f23 Author: Axel Boldt-Christmas Date: 2022-12-14 14:10:24 +0000 URL: https://git.openjdk.org/loom/commit/581f9f2306835680cd6d5dbbe37f610fb4de4677 8297235: ZGC: assert(regs[i] != regs[j]) failed: Multiple uses of register: rax Reviewed-by: thartmann, rcastanedalo Backport-of: 042b7062f19b313f31b228bd96d2a74cc1165ab9 ! src/hotspot/cpu/x86/gc/z/z_x86_64.ad ! test/jdk/ProblemList-zgc.txt Changeset: a130c8a6 Author: Jesper Wilhelmsson Date: 2022-12-14 21:47:29 +0000 URL: https://git.openjdk.org/loom/commit/a130c8a6688fcdda92e0f6295ec06f1591382328 Merge ! src/hotspot/share/opto/loopnode.cpp ! src/hotspot/share/utilities/globalDefinitions.hpp ! test/hotspot/jtreg/ProblemList.txt ! src/hotspot/share/opto/loopnode.cpp ! src/hotspot/share/utilities/globalDefinitions.hpp ! test/hotspot/jtreg/ProblemList.txt Changeset: 0ed6d0b4 Author: Alisen Chung Date: 2022-12-14 22:10:01 +0000 URL: https://git.openjdk.org/loom/commit/0ed6d0b456e58e4122b97c3d12faabada0d8c530 8297296: java/awt/Mouse/EnterExitEvents/DragWindowTest.java fails with "No MouseReleased event on label!" Reviewed-by: psadhukhan, dnguyen ! test/jdk/ProblemList.txt ! test/jdk/java/awt/Mouse/EnterExitEvents/DragWindowTest.java Changeset: 3ef38241 Author: Coleen Phillimore Date: 2022-12-14 23:08:32 +0000 URL: https://git.openjdk.org/loom/commit/3ef382416f5ff38cd44fa8d4e552f1935156e765 8298794: Remove JVM_ACC_PROMOTED_FLAGS breaks minimal build Reviewed-by: ayang, dcubed ! src/hotspot/share/oops/instanceKlassMiscStatus.cpp Changeset: d1085d1b Author: Matias Saavedra Silva Committer: Ioi Lam Date: 2022-12-15 05:03:57 +0000 URL: https://git.openjdk.org/loom/commit/d1085d1be7bc798ced8d539062fa7a9a3ab0341c 8281946: VM.native_memory should report size of shareable memory Reviewed-by: stuefe, iklam ! src/hotspot/share/cds/filemap.cpp ! src/hotspot/share/cds/filemap.hpp ! src/hotspot/share/services/memReporter.cpp ! test/hotspot/jtreg/runtime/NMT/SummarySanityCheck.java Changeset: ebc47104 Author: Per Minborg Committer: Maurizio Cimadamore Date: 2022-12-14 21:40:29 +0000 URL: https://git.openjdk.org/loom/commit/ebc471040e03dc41829d57e1280cabd75b2ad53a 8298277: Replace "session" with "scope" for FFM access Reviewed-by: mcimadamore ! src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java ! src/java.base/share/classes/jdk/internal/foreign/HeapMemorySegmentImpl.java ! src/java.base/share/classes/jdk/internal/foreign/MappedMemorySegmentImpl.java ! src/java.base/share/classes/jdk/internal/foreign/MemorySessionImpl.java ! src/java.base/share/classes/jdk/internal/foreign/NativeMemorySegmentImpl.java ! src/java.base/share/classes/jdk/internal/foreign/abi/Binding.java ! src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java ! src/java.base/share/classes/jdk/internal/foreign/abi/SharedUtils.java ! src/java.base/share/classes/jdk/internal/foreign/abi/UpcallLinker.java ! src/java.base/share/classes/jdk/internal/foreign/abi/UpcallStubs.java ! src/java.base/share/classes/jdk/internal/foreign/abi/aarch64/linux/LinuxAArch64Linker.java ! src/java.base/share/classes/jdk/internal/foreign/abi/aarch64/linux/LinuxAArch64VaList.java ! src/java.base/share/classes/jdk/internal/foreign/abi/aarch64/macos/MacOsAArch64Linker.java ! src/java.base/share/classes/jdk/internal/foreign/abi/x64/sysv/CallArranger.java ! src/java.base/share/classes/jdk/internal/foreign/abi/x64/sysv/SysVVaList.java ! src/java.base/share/classes/jdk/internal/foreign/abi/x64/sysv/SysVx64Linker.java ! src/java.base/share/classes/jdk/internal/foreign/abi/x64/windows/CallArranger.java ! src/java.base/share/classes/jdk/internal/foreign/abi/x64/windows/WinVaList.java ! src/java.base/share/classes/jdk/internal/foreign/abi/x64/windows/Windowsx64Linker.java Changeset: 80cadd40 Author: Kim Barrett Date: 2022-12-14 21:57:55 +0000 URL: https://git.openjdk.org/loom/commit/80cadd40103cf1f490a5d70be784652e27588114 8298785: gc/TestFullGCCount.java fails with "invalid boolean value: `null' for expression `vm.opt.ExplicitGCInvokesConcurrent'" Reviewed-by: dcubed ! test/hotspot/jtreg/gc/TestFullGCCount.java Changeset: 10bc86cc Author: Jesper Wilhelmsson Date: 2022-12-15 06:36:55 +0000 URL: https://git.openjdk.org/loom/commit/10bc86cc260fac48bf10f67dd56aa73c6954f026 Merge Changeset: b9074fa1 Author: Daniel Jeli?ski Date: 2022-12-15 06:54:33 +0000 URL: https://git.openjdk.org/loom/commit/b9074fa1ed489993d60ce873fd8105a95d30782a 8298249: Excessive memory allocation in CipherInputStream AEAD decryption Reviewed-by: ascarpino, valeriep ! src/java.base/share/classes/javax/crypto/CipherInputStream.java + test/micro/org/openjdk/bench/javax/crypto/full/AESGCMCipherInputStream.java Changeset: 3ae71872 Author: Daniel Jeli?ski Date: 2022-12-15 06:55:25 +0000 URL: https://git.openjdk.org/loom/commit/3ae718725a72cc2758331e932130d846cfba64e4 8298498: sun/net/www/http/KeepAliveCache/B8291637.java fails with "Server exception terminating: java.net.SocketException: Socket closed" Reviewed-by: dfuchs, jpai ! test/jdk/sun/net/www/http/KeepAliveCache/B8291637.java Changeset: 5f63f7a7 Author: Alan Bateman Date: 2022-12-15 07:14:02 +0000 URL: https://git.openjdk.org/loom/commit/5f63f7a742a1071a87ca69463bae6e04a44fe462 8298726: (fs) Change PollingWatchService to record last modified time as FileTime rather than milliseconds Reviewed-by: bpb, jpai ! src/java.base/share/classes/sun/nio/fs/PollingWatchService.java Changeset: 98fa48c3 Author: Matthias Baesken Date: 2022-12-15 08:11:09 +0000 URL: https://git.openjdk.org/loom/commit/98fa48c330941efe6588a907b383802a11ed0e6b 8298093: improve cleanup and error handling of awt_parseColorModel in awt_parseImage.c Reviewed-by: lucy, clanger ! src/java.desktop/share/native/libawt/awt/image/awt_parseImage.c Changeset: b17c5242 Author: Erik ?sterlund Date: 2022-12-15 09:26:13 +0000 URL: https://git.openjdk.org/loom/commit/b17c52422c91ad1e7ff35844676f6269a1b87f79 8298059: Linked stack watermarks don't support nesting Reviewed-by: stefank, sspitsyn, rehn, pchilanomate ! src/hotspot/share/runtime/keepStackGCProcessed.cpp ! src/hotspot/share/runtime/stackWatermark.cpp ! src/hotspot/share/runtime/stackWatermark.hpp ! test/hotspot/jtreg/ProblemList-zgc.txt Changeset: 0288210f Author: Alexander Zvegintsev Date: 2022-12-15 16:43:06 +0000 URL: https://git.openjdk.org/loom/commit/0288210f25e3d56870d1aa58ad076c97aad1c232 8298859: ProblemList java/awt/Mouse/EnterExitEvents/DragWindowTest.java on macosx-all Reviewed-by: jdv ! test/jdk/ProblemList.txt Changeset: 831b35fa Author: Brian Burkhalter Date: 2022-12-15 17:27:39 +0000 URL: https://git.openjdk.org/loom/commit/831b35fad352887717d5cc8f001ad822ac9a5c46 7093322: (fs spec) Files.newBufferedWriter should be clear when coding errors are detected Reviewed-by: alanb ! src/java.base/share/classes/java/nio/file/Files.java Changeset: 0ef35392 Author: Naoto Sato Date: 2022-12-15 19:20:12 +0000 URL: https://git.openjdk.org/loom/commit/0ef353925e645dd519e17aeb7a83e927271f8b95 8298416: Console should be declared `sealed` Reviewed-by: jpai, alanb ! src/java.base/share/classes/java/io/Console.java + src/java.base/share/classes/java/io/ConsoleImpl.java ! src/java.base/unix/native/libjava/Console_md.c Changeset: ae8988e8 Author: Julian Waters Committer: Vladimir Kozlov Date: 2022-12-15 19:38:39 +0000 URL: https://git.openjdk.org/loom/commit/ae8988e834032d9d6a4b644c3ebf9ee1957c9522 8297912: HotSpot Style Guide should permit alignas (Second Proposal Attempt) Reviewed-by: kbarrett, stuefe, kvn ! doc/hotspot-style.html ! doc/hotspot-style.md Changeset: 4b313b51 Author: Matthew Donovan Committer: Rajan Halade Date: 2022-12-15 19:48:35 +0000 URL: https://git.openjdk.org/loom/commit/4b313b51b1787113961c289a41708e31fa19cacc 8297798: Timeout with DTLSOverDatagram test template Reviewed-by: jnimeh, rhalade ! test/jdk/ProblemList.txt ! test/jdk/javax/net/ssl/DTLS/DTLSOverDatagram.java ! test/jdk/javax/net/ssl/DTLS/InvalidRecords.java Changeset: 10737e16 Author: Coleen Phillimore Date: 2022-12-15 19:54:25 +0000 URL: https://git.openjdk.org/loom/commit/10737e168c967a08e257927251861bf2c14795ab 8298468: Clean up class_loader parameters Reviewed-by: dholmes, iklam ! src/hotspot/share/cds/cdsProtectionDomain.cpp ! src/hotspot/share/classfile/loaderConstraints.cpp ! src/hotspot/share/classfile/loaderConstraints.hpp ! src/hotspot/share/classfile/systemDictionary.cpp ! src/hotspot/share/classfile/systemDictionary.hpp Changeset: 3cdbd878 Author: David Holmes Date: 2022-12-15 21:15:34 +0000 URL: https://git.openjdk.org/loom/commit/3cdbd878e68dc1131093137a7357710ad303ae8c 8298241: Replace C-style casts with JavaThread::cast Reviewed-by: coleenp, stefank, sspitsyn ! src/hotspot/cpu/aarch64/frame_aarch64.cpp ! src/hotspot/os/posix/signals_posix.cpp ! src/hotspot/os_cpu/bsd_aarch64/javaThread_bsd_aarch64.cpp ! src/hotspot/os_cpu/windows_aarch64/javaThread_windows_aarch64.cpp ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/jvmci/jvmci.cpp ! src/hotspot/share/jvmci/jvmciRuntime.cpp ! src/hotspot/share/oops/instanceStackChunkKlass.cpp ! src/hotspot/share/oops/stackChunkOop.inline.hpp ! src/hotspot/share/prims/jvmtiEnv.cpp ! src/hotspot/share/prims/jvmtiEnvBase.cpp ! src/hotspot/share/prims/jvmtiImpl.cpp ! src/hotspot/share/prims/scopedMemoryAccess.cpp ! src/hotspot/share/runtime/continuation.cpp ! src/hotspot/share/runtime/continuationFreezeThaw.cpp ! src/hotspot/share/runtime/frame.cpp ! src/hotspot/share/runtime/javaThread.hpp ! src/hotspot/share/runtime/objectMonitor.cpp ! src/hotspot/share/runtime/synchronizer.cpp Changeset: 54124394 Author: Brian Burkhalter Date: 2022-12-15 22:47:29 +0000 URL: https://git.openjdk.org/loom/commit/5412439445fadcf66101018a9bd051f8e5d751e8 8298187: (fs) BsdFileAttributeViews::setTimes does not support lastAccessTime on HFS+ Reviewed-by: alanb ! src/java.base/macosx/classes/sun/nio/fs/BsdFileAttributeViews.java ! src/java.base/macosx/classes/sun/nio/fs/BsdNativeDispatcher.java ! src/java.base/macosx/native/libnio/fs/BsdNativeDispatcher.c ! src/java.base/share/classes/java/nio/file/attribute/BasicFileAttributeView.java ! src/java.base/unix/classes/sun/nio/fs/UnixConstants.java.template Changeset: 2bb727c4 Author: Sergey Bylokhov Date: 2022-12-16 00:43:56 +0000 URL: https://git.openjdk.org/loom/commit/2bb727c4eaf8a948f17f6416a1e6fbaeade4d7ce 8290899: java/lang/String/StringRepeat.java test requests too much heap on windows x86 Reviewed-by: jpai, phh ! test/jdk/java/lang/String/StringRepeat.java Changeset: a3364612 Author: David Holmes Date: 2022-12-16 01:08:30 +0000 URL: https://git.openjdk.org/loom/commit/a3364612f7d49f3633661b9ba4e9b721534cafad 8298081: DiagnoseSyncOnValueBasedClasses doesn't report useful information for virtual threads Reviewed-by: gziemski, pchilanomate ! src/hotspot/share/runtime/javaThread.cpp ! src/hotspot/share/runtime/javaThread.hpp ! src/hotspot/share/runtime/synchronizer.cpp ! test/hotspot/jtreg/runtime/Monitor/SyncOnValueBasedClassTest.java Changeset: e41686b4 Author: Jaikiran Pai Date: 2022-12-16 05:16:40 +0000 URL: https://git.openjdk.org/loom/commit/e41686b4050d6b32fb451de8af39a78ec8bed0fd 8298710: Fix typos in test/jdk/sun/security/tools/jarsigner/ Co-authored-by: Michael Ernst Reviewed-by: lancea ! test/jdk/javax/security/auth/x500/X500Principal/EscapedChars.java ! test/jdk/sun/security/tools/jarsigner/DigestDontIgnoreCase.java ! test/jdk/sun/security/tools/jarsigner/FindHeaderEndVsManifestDigesterFindFirstSection.java Changeset: fa322e40 Author: Jaikiran Pai Date: 2022-12-16 07:10:36 +0000 URL: https://git.openjdk.org/loom/commit/fa322e40b68abf0a253040d14414d41f4e01e028 8298709: Fix typos in src/java.desktop/ and various test classes of client component Co-authored-by: Michael Ernst Reviewed-by: iris, prr ! src/java.desktop/share/classes/javax/swing/text/Document.java ! test/jdk/java/awt/Multiscreen/DeviceIdentificationTest/DeviceIdentificationTest.java ! test/jdk/java/awt/datatransfer/HTMLDataFlavors/ManualHTMLDataFlavorTest.java ! test/jdk/java/awt/print/PrinterJob/PageFormatChange.java ! test/jdk/javax/imageio/stream/DeleteOnExitTest.sh ! test/jdk/javax/print/attribute/ServiceDlgPageRangeTest.java ! test/jdk/javax/sound/midi/Sequencer/SequencerState.java ! test/jdk/javax/swing/JColorChooser/Test4193384.java ! test/jdk/sanity/client/SwingSet/src/EditorPaneDemoTest.java ! test/jdk/sanity/client/SwingSet/src/TabbedPaneDemoTest.java ! test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/tree/resources/TreeDemo.properties ! test/jdk/sanity/client/lib/jemmy/src/org/netbeans/jemmy/WindowWaiter.java ! test/jdk/sanity/client/lib/jemmy/src/org/netbeans/jemmy/operators/ComponentOperator.java ! test/jdk/sanity/client/lib/jemmy/src/org/netbeans/jemmy/operators/JTreeOperator.java ! test/jdk/sanity/client/lib/jemmy/src/org/netbeans/jemmy/operators/Operator.java ! test/jdk/sun/java2d/pipe/hw/RSLAPITest/RSLAPITest.java Changeset: 226e579c Author: Fei Yang Date: 2022-12-16 08:45:52 +0000 URL: https://git.openjdk.org/loom/commit/226e579c3004a37a09f3329a8ef09c0933126bd6 8298088: RISC-V: Make Address a discriminated union internally Reviewed-by: fjiang, yadongwang, shade ! src/hotspot/cpu/riscv/assembler_riscv.cpp ! src/hotspot/cpu/riscv/assembler_riscv.hpp Changeset: 909d0cb4 Author: Michal Karm Babacek Committer: Jaikiran Pai Date: 2022-12-16 12:28:39 +0000 URL: https://git.openjdk.org/loom/commit/909d0cb4d9475fd367b8bc64a6b50c5a324e9a01 8298588: WebSockets: HandshakeUrlEncodingTest unnecessarily depends on a response body Reviewed-by: dfuchs ! test/jdk/java/net/httpclient/websocket/HandshakeUrlEncodingTest.java Changeset: ac2fcf3f Author: Ivan Walulya Date: 2022-12-16 12:59:44 +0000 URL: https://git.openjdk.org/loom/commit/ac2fcf3f7598caf8384282ec1178ec0b66c8408a 8296374: Check for young region in G1BarrierSet::invalidate instead of card-by-card check Reviewed-by: ayang, tschatzl ! src/hotspot/share/gc/g1/g1BarrierSet.cpp Changeset: f4caaca1 Author: Justin King Committer: Coleen Phillimore Date: 2022-12-16 14:00:56 +0000 URL: https://git.openjdk.org/loom/commit/f4caaca100d334b671eed56287dfe7a1009c47d7 8298852: Use of uninitialized memory in MetadataFactory::free_metadata Reviewed-by: coleenp, stefank, dholmes ! src/hotspot/share/memory/metadataFactory.hpp Changeset: 323e574a Author: Stefan Karlsson Date: 2022-12-15 11:28:06 +0000 URL: https://git.openjdk.org/loom/commit/323e574a50520735f41549f36907563e1b4a1040 8298371: monitors_on_stack extracts unprocessed oops Backport-of: b754aa5e3f231aea8da5274c330dc55dd78b0f67 ! src/hotspot/share/runtime/continuationFreezeThaw.cpp Changeset: 22a6b591 Author: Jan Lahoda Date: 2022-12-15 11:33:56 +0000 URL: https://git.openjdk.org/loom/commit/22a6b5910290cb8a3876f94213ba60db86e60718 8298727: Trees.getPath may crash for unnamed package Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Enter.java + test/langtools/tools/javac/processing/model/EmptyPackageInfo.java Changeset: 48f61273 Author: Stefan Karlsson Date: 2022-12-15 11:44:21 +0000 URL: https://git.openjdk.org/loom/commit/48f6127325108e573b41d19213e65af99956a31f 8298376: ZGC: thaws stackChunk with stale oops Backport-of: ed8a2120ca1e9756c6ab5eeebfe24c15d549f04e ! src/hotspot/share/oops/stackChunkOop.hpp ! src/hotspot/share/oops/stackChunkOop.inline.hpp ! src/hotspot/share/runtime/continuationJavaClasses.hpp ! src/hotspot/share/runtime/continuationJavaClasses.inline.hpp Changeset: 2c424992 Author: Per Minborg Committer: Joe Darcy Date: 2022-12-15 15:46:05 +0000 URL: https://git.openjdk.org/loom/commit/2c42499266377a32aa0ff96a0241d76d7517cf2e 8298050: Add links to graph output for javadoc Reviewed-by: darcy ! make/jdk/src/classes/build/tools/taglet/SealedGraph.java Changeset: ca39eb90 Author: Brian Burkhalter Date: 2022-12-15 17:27:08 +0000 URL: https://git.openjdk.org/loom/commit/ca39eb906692568347e7f264520593188f9276cf 7093322: (fs spec) Files.newBufferedWriter should be clear when coding errors are detected Reviewed-by: alanb ! src/java.base/share/classes/java/nio/file/Files.java Changeset: c7d7e7e3 Author: Daniel D. Daugherty Date: 2022-12-16 00:01:08 +0000 URL: https://git.openjdk.org/loom/commit/c7d7e7e3be768b35447d65661ec328204aeb40e4 8298888: ProblemList gc/g1/TestVerifyGCType.java on linux and macosx 8298889: ProblemList runtime/StackGuardPages/TestStackGuardPages.java on linux 8298891: ProblemList vmTestbase/nsk/monitoring/MemoryPoolMBean/isCollectionUsageThresholdExceeded/isexceeded002/TestDescription.java with ZGC 8298892: ProblemList vmTestbase/nsk/sysdict/vm/stress/chain/chain008/chain008.java with ZGC Reviewed-by: bpb, lmesnik ! test/hotspot/jtreg/ProblemList-zgc.txt ! test/hotspot/jtreg/ProblemList.txt Changeset: 03a694af Author: Sergey Bylokhov Date: 2022-12-16 06:33:08 +0000 URL: https://git.openjdk.org/loom/commit/03a694afda81f575f8a24e655d53b2b029e3d968 8298083: The "CheckBox/RadioButton[Enabled/Disabled].textForeground" stoped working Reviewed-by: prr Backport-of: 5540a8c5b7160ab5c67bb84631e3de54fa5aeceb ! src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKStyle.java ! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthStyle.java ! test/jdk/ProblemList.txt ! test/jdk/javax/swing/JRadioButton/4314194/bug4314194.java Changeset: c47e64e4 Author: Stefan Johansson Date: 2022-12-16 08:06:09 +0000 URL: https://git.openjdk.org/loom/commit/c47e64e4f3be80f434dd4dea9b6e8d282b2c2b32 8297979: ZGC: Ensure consistent MemoryUsage from MemoryMXBean.getHeapMemoryUsage() Reviewed-by: stefank, ayang ! src/hotspot/share/gc/z/zCollectedHeap.cpp ! src/hotspot/share/gc/z/zCollectedHeap.hpp ! test/hotspot/jtreg/ProblemList-zgc.txt Changeset: 0ba47348 Author: Markus Gr?nlund Date: 2022-12-16 10:46:37 +0000 URL: https://git.openjdk.org/loom/commit/0ba473489151d74c8a15b75ff4964ac480fecb28 8287699: jdk/jfr/api/consumer/TestRecordingFileWrite.java fails with exception: java.lang.Exception: Found event that should not be there. Reviewed-by: egahlin ! src/hotspot/share/jfr/support/jfrThreadLocal.cpp ! test/jdk/ProblemList.txt Changeset: f771c56e Author: Maurizio Cimadamore Date: 2022-12-16 10:49:22 +0000 URL: https://git.openjdk.org/loom/commit/f771c56e16a39724712ca0d8c2dd55b9ce260f4d 8298797: Specification of some restricted methods is incorrect Reviewed-by: jvernee, pminborg ! src/java.base/share/classes/java/lang/foreign/Linker.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/lang/foreign/VaList.java ! src/java.base/share/classes/java/lang/foreign/ValueLayout.java ! test/jdk/java/foreign/handles/lookup_module/handle/lookup/MethodHandleLookup.java Changeset: 3696711e Author: Jesper Wilhelmsson Date: 2022-12-16 15:48:24 +0000 URL: https://git.openjdk.org/loom/commit/3696711efa566fb776d6923da86e17b0e1e22964 Merge ! test/hotspot/jtreg/ProblemList-zgc.txt ! test/hotspot/jtreg/ProblemList.txt ! test/jdk/ProblemList.txt ! test/hotspot/jtreg/ProblemList-zgc.txt ! test/hotspot/jtreg/ProblemList.txt ! test/jdk/ProblemList.txt Changeset: 81e23ab3 Author: Eric Caspole Date: 2022-12-16 16:30:31 +0000 URL: https://git.openjdk.org/loom/commit/81e23ab3403a983ccddf27b1169a49e2ca061296 8298809: Clean up vm/compiler/InterfaceCalls JMH Reviewed-by: kvn ! test/micro/org/openjdk/bench/vm/compiler/InterfaceCalls.java Changeset: 0eeaeb8e Author: Naoto Sato Date: 2022-12-16 17:16:20 +0000 URL: https://git.openjdk.org/loom/commit/0eeaeb8e7ba40be5e93eb87c7e3dc94230062746 8298808: Check `script` code on detecting the base locales Reviewed-by: joehw ! make/jdk/src/classes/build/tools/cldrconverter/CLDRConverter.java ! make/jdk/src/classes/build/tools/cldrconverter/ResourceBundleGenerator.java Changeset: bf9a8ce0 Author: Matthew Donovan Committer: Rajan Halade Date: 2022-12-16 17:51:57 +0000 URL: https://git.openjdk.org/loom/commit/bf9a8ce0bb975a3d50e92148f92850ef930d64b0 8249826: 5 javax/net/ssl/SSLEngine tests use @ignore w/o bug-id Reviewed-by: xuelei, rhalade, ssahoo ! test/jdk/ProblemList.txt ! test/jdk/javax/net/ssl/SSLEngine/Basics.java ! test/jdk/javax/net/ssl/SSLEngine/CheckStatus.java ! test/jdk/javax/net/ssl/SSLEngine/ConnectionTest.java ! test/jdk/javax/net/ssl/SSLEngine/EngineCloseOnAlert.java ! test/jdk/javax/net/ssl/SSLEngine/IllegalHandshakeMessage.java ! test/jdk/javax/net/ssl/SSLEngine/IllegalRecordVersion.java ! test/jdk/javax/net/ssl/SSLEngine/TestAllSuites.java Changeset: bfa921ae Author: Kim Barrett Date: 2022-12-16 20:47:40 +0000 URL: https://git.openjdk.org/loom/commit/bfa921ae6ce068c53dfa708d6d3d2cddbad5fc33 8160404: RelocationHolder constructors have bugs Reviewed-by: kvn, jrose, jvernee ! src/hotspot/cpu/x86/assembler_x86.cpp ! src/hotspot/share/code/relocInfo.cpp ! src/hotspot/share/code/relocInfo.hpp Changeset: 7938f8c3 Author: Per Minborg Committer: Alan Bateman Date: 2022-12-18 20:25:42 +0000 URL: https://git.openjdk.org/loom/commit/7938f8c32a1c0ecdd3bcc8cd1a2652df248a2213 8298639: Perform I/O operations in bulk for RandomAccessFile Co-authored-by: Sergey Tsypanov Reviewed-by: alanb, bpb ! src/java.base/share/classes/java/io/RandomAccessFile.java ! test/jdk/java/io/File/Basic.java + test/micro/org/openjdk/bench/java/io/RandomAccessFileBenchmark.java Changeset: ba942c24 Author: Fei Gao Committer: Ningsheng Jian Date: 2022-12-19 01:11:19 +0000 URL: https://git.openjdk.org/loom/commit/ba942c24e8894f4422870fb53253f5946dc4f0d1 8298244: AArch64: Optimize vector implementation of AddReduction for floating point Reviewed-by: aph, xgong ! src/hotspot/cpu/aarch64/aarch64_vector.ad ! src/hotspot/cpu/aarch64/aarch64_vector_ad.m4 ! src/hotspot/cpu/aarch64/assembler_aarch64.hpp ! test/hotspot/gtest/aarch64/aarch64-asmtest.py ! test/hotspot/gtest/aarch64/asmtest.out.h Changeset: 5e678f75 Author: Christian Hagedorn Date: 2022-12-19 07:10:12 +0000 URL: https://git.openjdk.org/loom/commit/5e678f7500e514f04637c546959613d4688f989c 8298824: C2 crash: assert(is_Bool()) failed: invalid node class: ConI Reviewed-by: roland, kvn, thartmann ! src/hotspot/share/opto/subnode.cpp + test/hotspot/jtreg/compiler/c2/TestCMoveIConAsBool.java Changeset: 36376605 Author: sunguoyun Committer: Tobias Hartmann Date: 2022-12-19 07:56:36 +0000 URL: https://git.openjdk.org/loom/commit/36376605215ba3380bfc07752eec043af04a5c29 8298813: [C2] Converting double to float cause a loss of precision and resulting crypto.aes scores fluctuate Reviewed-by: thartmann ! src/hotspot/share/opto/chaitin.hpp Changeset: 16225630 Author: Damon Fenacci Committer: Tobias Hartmann Date: 2022-12-19 08:35:00 +0000 URL: https://git.openjdk.org/loom/commit/16225630ec3d4943e359f7a8b0f531429bb434c8 8265688: Unused ciMethodType::ptype_at should be removed Reviewed-by: thartmann, kvn ! src/hotspot/share/ci/ciMethodType.cpp ! src/hotspot/share/ci/ciMethodType.hpp Changeset: ec959914 Author: Damon Fenacci Committer: Tobias Hartmann Date: 2022-12-19 08:47:04 +0000 URL: https://git.openjdk.org/loom/commit/ec95991470a99c917f757614fc6d2cd883bdb39b 8298736: Revisit usages of log10 in compiler code Reviewed-by: thartmann, chagedorn, epeter ! src/hotspot/share/opto/loopnode.cpp ! src/hotspot/share/opto/node.cpp Changeset: 86d588b0 Author: Damon Fenacci Committer: Tobias Hartmann Date: 2022-12-19 08:48:41 +0000 URL: https://git.openjdk.org/loom/commit/86d588b035d09141d807dbed6b91d9909782d61a 8283740: C1: Convert flag TwoOperandLIRForm to a constant on all platforms Reviewed-by: thartmann, chagedorn ! src/hotspot/cpu/aarch64/c1_Defs_aarch64.hpp ! src/hotspot/cpu/aarch64/c1_globals_aarch64.hpp ! src/hotspot/cpu/arm/c1_Defs_arm.hpp ! src/hotspot/cpu/arm/c1_globals_arm.hpp ! src/hotspot/cpu/ppc/c1_Defs_ppc.hpp ! src/hotspot/cpu/ppc/c1_globals_ppc.hpp ! src/hotspot/cpu/riscv/c1_Defs_riscv.hpp ! src/hotspot/cpu/riscv/c1_globals_riscv.hpp ! src/hotspot/cpu/s390/c1_Defs_s390.hpp ! src/hotspot/cpu/s390/c1_globals_s390.hpp ! src/hotspot/cpu/x86/c1_Defs_x86.hpp ! src/hotspot/cpu/x86/c1_globals_x86.hpp ! src/hotspot/share/c1/c1_Defs.hpp ! src/hotspot/share/c1/c1_LIR.cpp ! src/hotspot/share/c1/c1_LIRGenerator.cpp ! src/hotspot/share/c1/c1_globals.hpp ! src/hotspot/share/gc/g1/c1/g1BarrierSetC1.cpp ! src/hotspot/share/gc/shared/c1/cardTableBarrierSetC1.cpp ! src/hotspot/share/gc/shenandoah/c1/shenandoahBarrierSetC1.cpp Changeset: 8e49fcdd Author: Damon Fenacci Committer: Tobias Hartmann Date: 2022-12-19 08:50:44 +0000 URL: https://git.openjdk.org/loom/commit/8e49fcdde4fef5a8db36823b35d409ba2c9ec47b 8295661: CompileTask::compile_id() should be passed as int Reviewed-by: thartmann, dnsimon, never ! src/hotspot/share/ci/ciEnv.cpp ! src/hotspot/share/ci/ciEnv.hpp ! src/hotspot/share/code/codeHeapState.cpp ! src/hotspot/share/code/codeHeapState.hpp ! src/hotspot/share/compiler/compileBroker.cpp ! src/hotspot/share/compiler/compileBroker.hpp ! src/hotspot/share/compiler/compileTask.hpp ! src/hotspot/share/jfr/metadata/metadata.xml ! src/hotspot/share/runtime/vmStructs.cpp Changeset: da38d43f Author: Emanuel Peter Date: 2022-12-19 12:21:50 +0000 URL: https://git.openjdk.org/loom/commit/da38d43fcc640ea9852db6c7c23817dcef7080d5 8296412: Special case infinite loops with unmerged backedges in IdealLoopTree::check_safepts Reviewed-by: chagedorn, kvn, thartmann ! src/hotspot/share/opto/loopnode.cpp + test/hotspot/jtreg/compiler/loopopts/TestInfiniteLoopWithUnmergedBackedges.jasm + test/hotspot/jtreg/compiler/loopopts/TestInfiniteLoopWithUnmergedBackedgesMain.java Changeset: de0ce792 Author: Damon Fenacci Committer: Christian Hagedorn Date: 2022-12-19 15:44:38 +0000 URL: https://git.openjdk.org/loom/commit/de0ce792c1865f80b6bcfce6741681cb74d75cef 8297801: printnm crashes with invalid address due to null pointer dereference Reviewed-by: thartmann, chagedorn, kvn ! src/hotspot/share/utilities/debug.cpp Changeset: 756a06d4 Author: Matthias Baesken Date: 2022-12-19 16:20:12 +0000 URL: https://git.openjdk.org/loom/commit/756a06d4c239966ed68bbbe8ee4c6b6d02154c02 8299022: Linux ppc64le and s390x build issues after JDK-8160404 Reviewed-by: mdoerr, lucy ! src/hotspot/cpu/ppc/assembler_ppc.hpp ! src/hotspot/cpu/s390/assembler_s390.hpp Changeset: 4c927df7 Author: Coleen Phillimore Date: 2022-12-19 17:13:57 +0000 URL: https://git.openjdk.org/loom/commit/4c927df7125f3c9d4c24dc587ad99d7fa1d1ccb3 8298470: Short cut java.lang.Object super class loading Reviewed-by: dholmes, iklam ! src/hotspot/share/classfile/classFileParser.cpp Changeset: 9194e915 Author: Chris Plummer Date: 2022-12-19 18:02:34 +0000 URL: https://git.openjdk.org/loom/commit/9194e915495434c154ff4cf142d527b163026b3c 8298701: Cleanup SA entries in ProblemList-zgc.txt. Reviewed-by: sspitsyn, amenkov ! test/hotspot/jtreg/ProblemList-zgc.txt Changeset: 40cb431f Author: Archie L. Cobbs Committer: Jonathan Gibbons Date: 2022-12-19 19:48:13 +0000 URL: https://git.openjdk.org/loom/commit/40cb431fee7c1f193b2f445c397c1444ed2e0015 8298943: Missing escapes for single quote marks in compiler.properties Reviewed-by: jjg ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/langtools/tools/javac/diags/CheckResourceKeys.java Changeset: 5d330f52 Author: Jonathan Gibbons Date: 2022-12-19 21:09:01 +0000 URL: https://git.openjdk.org/loom/commit/5d330f5285b535b37dde5cd4e42374d92fafb550 8299045: tools/doclint/BadPackageCommentTest.java fails after JDK-8298943 Reviewed-by: vromero ! test/langtools/tools/doclint/BadPackageCommentTest.out Changeset: abc12976 Author: lawrence.andrews Committer: Harshitha Onkar Date: 2022-12-19 23:26:01 +0000 URL: https://git.openjdk.org/loom/commit/abc1297643b03ea9b4a03a12ce681971784774fb 8299044: test/jdk/javax/swing/JComboBox/JComboBoxBorderTest.java fails on non mac Reviewed-by: serb, honkar ! test/jdk/javax/swing/JComboBox/JComboBoxBorderTest.java Changeset: 05f9e767 Author: Phil Race Date: 2022-12-19 23:32:58 +0000 URL: https://git.openjdk.org/loom/commit/05f9e7676ea457cd5ef44acca9a1706b5dd0d093 8298974: Add ftcolor.c to imported freetype sources Reviewed-by: serb + src/java.desktop/share/native/libfreetype/src/base/ftcolor.c Changeset: dd15d306 Author: lawrence.andrews Committer: Sergey Bylokhov Date: 2022-12-20 01:16:37 +0000 URL: https://git.openjdk.org/loom/commit/dd15d306a68caa02659dd95d16b71d0f1a437bc6 8299043: test/jdk/javax/swing/AbstractButton/5049549/bug5049549.java fails with java.lang.NullPointerException Reviewed-by: serb ! test/jdk/javax/swing/AbstractButton/5049549/bug5049549.java Changeset: 36de61c4 Author: Daniel Jeli?ski Date: 2022-12-20 10:27:33 +0000 URL: https://git.openjdk.org/loom/commit/36de61c460d7038019294293143e420dfcce2936 8298865: Excessive memory allocation in CipherOutputStream AEAD decryption Reviewed-by: valeriep, ascarpino ! src/java.base/share/classes/javax/crypto/CipherInputStream.java ! src/java.base/share/classes/javax/crypto/CipherOutputStream.java + test/micro/org/openjdk/bench/javax/crypto/full/AESGCMCipherOutputStream.java Changeset: 5df00d34 Author: Daniel Fuchs Date: 2022-12-20 11:05:38 +0000 URL: https://git.openjdk.org/loom/commit/5df00d34fe83648fb833dac738a45653865ca426 8298931: java/net/httpclient/CancelStreamedBodyTest.java fails with AssertionError due to Pending TCP connections: 1 Reviewed-by: jpai ! test/jdk/java/net/httpclient/CancelStreamedBodyTest.java ! test/jdk/java/net/httpclient/ISO_8859_1_Test.java ! test/jdk/java/net/httpclient/ReferenceTracker.java Changeset: e5edb10d Author: Daniel Fuchs Date: 2022-12-20 11:06:36 +0000 URL: https://git.openjdk.org/loom/commit/e5edb10dc56d9edac8e050e0f8e6c116743975d6 8299018: java/net/httpclient/HttpsTunnelAuthTest.java fails with java.io.IOException: HTTP/1.1 header parser received no bytes Reviewed-by: djelinski, jpai ! test/jdk/java/net/httpclient/ProxyServer.java Changeset: b14794db Author: Coleen Phillimore Date: 2022-12-16 14:09:55 +0000 URL: https://git.openjdk.org/loom/commit/b14794db00ded878dbfc7080f9d57a0f65c02dee 8298852: Use of uninitialized memory in MetadataFactory::free_metadata Backport-of: f4caaca100d334b671eed56287dfe7a1009c47d7 ! src/hotspot/share/memory/metadataFactory.hpp Changeset: 9e10f00e Author: Tobias Hartmann Date: 2022-12-16 14:39:48 +0000 URL: https://git.openjdk.org/loom/commit/9e10f00edbf37e5e5db8efc4f1e0c2a76541aab2 8298919: Add a regression test for JDK-8298520 Reviewed-by: chagedorn, roland + test/hotspot/jtreg/compiler/loopopts/TestUnexpectedOpaque1.java Changeset: c997b5bf Author: Damon Nguyen Committer: Naoto Sato Date: 2022-12-16 21:15:29 +0000 URL: https://git.openjdk.org/loom/commit/c997b5bffd0ebbd6d68332572639c8cea05ccdb1 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 Reviewed-by: achung, naoto, joehw, cjplummer, almatvee ! src/java.base/share/classes/sun/launcher/resources/launcher_de.properties ! src/java.base/share/classes/sun/launcher/resources/launcher_ja.properties ! src/java.base/share/classes/sun/launcher/resources/launcher_zh_CN.properties ! src/java.base/share/classes/sun/security/tools/keytool/Resources_de.java ! src/java.base/share/classes/sun/security/tools/keytool/Resources_ja.java ! src/java.base/share/classes/sun/security/tools/keytool/Resources_zh_CN.java ! src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_de.properties ! src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_ja.properties ! src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_zh_CN.properties ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_de.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_ja.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_zh_CN.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_de.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_ja.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_zh_CN.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_de.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_ja.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_zh_CN.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_de.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_ja.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_zh_CN.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_de.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_ja.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_zh_CN.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_de.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_ja.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_zh_CN.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_de.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_ja.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_zh_CN.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_de.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_ja.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_zh_CN.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_de.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_ja.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_zh_CN.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_de.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_ja.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_zh_CN.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_de.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_ja.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_zh_CN.properties ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_de.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_ja.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_zh_CN.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_de.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_ja.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_zh_CN.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac_de.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac_ja.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac_zh_CN.properties ! src/jdk.jartool/share/classes/sun/tools/jar/resources/jar_de.properties ! src/jdk.jartool/share/classes/sun/tools/jar/resources/jar_ja.properties ! src/jdk.jartool/share/classes/sun/tools/jar/resources/jar_zh_CN.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard_de.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard_ja.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard_zh_CN.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets_de.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets_ja.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets_zh_CN.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/resources/doclint_de.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/resources/doclint_ja.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/resources/doclint_zh_CN.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/resources/javadoc_de.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/resources/javadoc_ja.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/resources/javadoc_zh_CN.properties ! src/jdk.jdeps/share/classes/com/sun/tools/javap/resources/javap_de.properties ! src/jdk.jdeps/share/classes/com/sun/tools/javap/resources/javap_ja.properties ! src/jdk.jdeps/share/classes/com/sun/tools/javap/resources/javap_zh_CN.properties ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/resources/jdeps_de.properties ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/resources/jdeps_ja.properties ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/resources/jdeps_zh_CN.properties ! src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_de.java ! src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_ja.java ! src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_zh_CN.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/resources/jdi_de.properties ! src/jdk.jdi/share/classes/com/sun/tools/jdi/resources/jdi_ja.properties ! src/jdk.jdi/share/classes/com/sun/tools/jdi/resources/jdi_zh_CN.properties ! src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink_de.properties ! src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink_ja.properties ! src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink_zh_CN.properties ! src/jdk.jlink/share/classes/jdk/tools/jmod/resources/jmod_de.properties ! src/jdk.jlink/share/classes/jdk/tools/jmod/resources/jmod_ja.properties ! src/jdk.jlink/share/classes/jdk/tools/jmod/resources/jmod_zh_CN.properties ! src/jdk.jpackage/linux/classes/jdk/jpackage/internal/resources/LinuxResources_de.properties ! src/jdk.jpackage/linux/classes/jdk/jpackage/internal/resources/LinuxResources_ja.properties ! src/jdk.jpackage/linux/classes/jdk/jpackage/internal/resources/LinuxResources_zh_CN.properties ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources_de.properties ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources_ja.properties ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources_zh_CN.properties ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/HelpResources_de.properties ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/HelpResources_ja.properties ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/HelpResources_zh_CN.properties ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources_de.properties ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources_ja.properties ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources_zh_CN.properties ! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_de.properties ! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_ja.properties ! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_zh_CN.properties Changeset: 0ecad28d Author: Daniel D. Daugherty Date: 2022-12-16 21:17:04 +0000 URL: https://git.openjdk.org/loom/commit/0ecad28daa64ae1a0e6194e207ae57486b06e484 8298976: ProblemList java/util/concurrent/ExecutorService/CloseTest.java on macosx-aarch64 8298977: ProblemList vmTestbase/nsk/stress/strace/strace002.java on 2 platforms 8298978: ProblemList vmTestbase/nsk/stress/strace/strace003.java on 2 platforms Reviewed-by: kbarrett, iris ! test/hotspot/jtreg/ProblemList.txt ! test/jdk/ProblemList.txt Changeset: 3b7970ca Author: Ajit Ghaisas Date: 2022-12-17 06:37:18 +0000 URL: https://git.openjdk.org/loom/commit/3b7970cab39a67eabcde331822f0432f71d9186b 8298217: Regressions 30-110% in SwingMark on MacOS, more so on aarch64 Reviewed-by: avu, prr, jdv ! src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLRenderQueue.h ! src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLRenderQueue.m ! src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLRenderer.h ! src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLRenderer.m - test/jdk/java/awt/Graphics2D/DrawPrimitivesTest.java Changeset: 41cc0443 Author: Alexander Zvegintsev Date: 2022-12-17 13:28:39 +0000 URL: https://git.openjdk.org/loom/commit/41cc04430ab9e6db31ea26b5254668c9ab18966d 8298970: Problem list java/awt/event/KeyEvent/KeyTyped/CtrlASCII.java Reviewed-by: serb ! test/jdk/ProblemList.txt Changeset: d1026720 Author: Alexander Zvegintsev Date: 2022-12-17 13:30:24 +0000 URL: https://git.openjdk.org/loom/commit/d1026720d323d0acd9bd8d85d5caba7185107863 8298905: Test "java/awt/print/PrinterJob/ImagePrinting/PrintARGBImage.java" fails because the frames of instruction does not display Reviewed-by: honkar, serb ! test/jdk/java/awt/print/PrinterJob/ImagePrinting/PrintARGBImage.java ! test/jdk/java/awt/print/PrinterJob/PageRangesDlgTest.java ! test/jdk/javax/swing/ProgressMonitor/ProgressTest.java Changeset: 34105556 Author: Daniel D. Daugherty Date: 2022-12-17 16:13:03 +0000 URL: https://git.openjdk.org/loom/commit/34105556d16774439195076f22f37f275d0d8873 8298987: ProblemList jdk/internal/vm/Continuation/Fuzz.java#default with ZGC on X64 8298989: ProblemList vmTestbase/nsk/jvmti/InterruptThread/intrpthrd003/TestDescription.java on macosx-x64 8298990: ProblemList java/lang/Thread/virtual/stress/Skynet.java subtests with ZGC Reviewed-by: azvegint ! test/hotspot/jtreg/ProblemList.txt ! test/jdk/ProblemList-zgc.txt Changeset: 2c69c41d Author: Alan Bateman Date: 2022-12-19 18:06:19 +0000 URL: https://git.openjdk.org/loom/commit/2c69c41d48fddcbeb40a374f691b7e5faba3c99a 8298894: java/lang/Thread/virtual/stress/Skynet.java timed out and threw OutOfMemoryError Reviewed-by: eosterlund ! test/jdk/ProblemList-zgc.txt ! test/jdk/java/lang/Thread/virtual/stress/Skynet.java Changeset: 188aaef3 Author: Hannes Walln?fer Date: 2022-12-19 19:13:29 +0000 URL: https://git.openjdk.org/loom/commit/188aaef38594658288e9222ed815d5af4b8d3dad 8277074: Qualified exported types show up in JavaDoc Reviewed-by: psandoz ! src/java.base/share/classes/jdk/internal/event/Event.java ! src/java.base/share/classes/jdk/internal/vm/vector/VectorSupport.java Changeset: 3e17e3c1 Author: Alexander Zuev Date: 2022-12-19 22:16:56 +0000 URL: https://git.openjdk.org/loom/commit/3e17e3c1c12d71461213bf15cdb72d4d93c88460 4512626: Non-editable JTextArea provides no visual indication of keyboard focus 8194048: Regression automated test '/open/test/jdk/javax/swing/text/DefaultCaret/HidingSelection/HidingSelectionTest.java' fails 8213562: Test javax/swing/text/DefaultCaret/HidingSelection/MultiSelectionTest.java fails Reviewed-by: aivanov, azvegint ! src/java.desktop/share/classes/javax/swing/text/DefaultCaret.java ! test/jdk/ProblemList.txt ! test/jdk/javax/swing/text/DefaultCaret/HidingSelection/HidingSelectionTest.java ! test/jdk/javax/swing/text/DefaultCaret/HidingSelection/MultiSelectionTest.java Changeset: f07acfc1 Author: Daniel D. Daugherty Date: 2022-12-19 23:08:56 +0000 URL: https://git.openjdk.org/loom/commit/f07acfc166e1261f830e63629e76303ec6235377 8298699: java/lang/reflect/IllegalArgumentsTest.java times out with slowdebug bits Reviewed-by: iris ! test/jdk/java/lang/reflect/IllegalArgumentsTest.java Changeset: d0a7679d Author: Roger Riggs Date: 2022-12-19 23:10:30 +0000 URL: https://git.openjdk.org/loom/commit/d0a7679d2e9c86ee2fc6edf2e37c1729c833ae11 4958969: ObjectOutputStream example leads to non-working code Reviewed-by: lancea, naoto ! src/java.base/share/classes/java/io/ObjectInputFilter.java ! src/java.base/share/classes/java/io/ObjectInputStream.java ! src/java.base/share/classes/java/io/ObjectOutputStream.java Changeset: ea40f299 Author: Kim Barrett Date: 2022-12-20 00:13:25 +0000 URL: https://git.openjdk.org/loom/commit/ea40f299397f19f1bbedd4eeb4d24802a709a912 8298215: gc/g1/TestVerifyGCType.java failed with "Missing expected verification pattern Verifying After GC for: Pause Young (Prepare Mixed): expected true, was false" Reviewed-by: iwalulya, tschatzl ! src/hotspot/share/gc/g1/g1Policy.cpp ! src/hotspot/share/gc/g1/g1Policy.hpp ! test/hotspot/jtreg/ProblemList.txt ! test/hotspot/jtreg/gc/g1/TestVerifyGCType.java Changeset: 3dd2cfab Author: Erik Gahlin Date: 2022-12-20 10:52:11 +0000 URL: https://git.openjdk.org/loom/commit/3dd2cfabdcd91cf9e53d977ef76d0c81b3a072eb 8298784: JFR: Test chunk integrity Reviewed-by: mgronlun + test/jdk/jdk/jfr/jvm/TestChunkIntegrity.java Changeset: c5a4a7a6 Author: Jesper Wilhelmsson Date: 2022-12-20 11:40:56 +0000 URL: https://git.openjdk.org/loom/commit/c5a4a7a679ec76cb08a999a198e5c73e9cd9d2f0 Merge ! src/hotspot/share/gc/g1/g1Policy.cpp ! src/hotspot/share/gc/g1/g1Policy.hpp ! test/hotspot/jtreg/ProblemList.txt ! test/hotspot/jtreg/gc/g1/TestVerifyGCType.java ! test/jdk/ProblemList.txt ! src/hotspot/share/gc/g1/g1Policy.cpp ! src/hotspot/share/gc/g1/g1Policy.hpp ! test/hotspot/jtreg/ProblemList.txt ! test/hotspot/jtreg/gc/g1/TestVerifyGCType.java ! test/jdk/ProblemList.txt Changeset: 318526b0 Author: Erik Gahlin Date: 2022-12-20 12:22:01 +0000 URL: https://git.openjdk.org/loom/commit/318526b01e45698cd1fa2c930a97f8c2aa84fb2d 8299031: JFR: Clean up jdk.management.jfr Reviewed-by: mgronlun ! src/jdk.management.jfr/share/classes/jdk/management/jfr/ConfigurationInfo.java ! src/jdk.management.jfr/share/classes/jdk/management/jfr/EventTypeInfo.java ! src/jdk.management.jfr/share/classes/jdk/management/jfr/RecordingInfo.java ! src/jdk.management.jfr/share/classes/jdk/management/jfr/RemoteRecordingStream.java Changeset: de8153ca Author: Erik Gahlin Date: 2022-12-20 13:07:25 +0000 URL: https://git.openjdk.org/loom/commit/de8153cab76606350eb0ecc4302b23c52f0565a6 8298526: JFR: Generate missing filename for time-bound recordings Reviewed-by: mgronlun ! src/jdk.jfr/share/classes/jdk/jfr/internal/dcmd/DCmdStart.java ! test/jdk/jdk/jfr/startupargs/TestStartDuration.java Changeset: 8dfb6d76 Author: Albert Mingkun Yang Date: 2022-12-20 19:36:52 +0000 URL: https://git.openjdk.org/loom/commit/8dfb6d76e8528af2c5dd6a1354ba9175f5369fe5 8298651: Serial: Remove MarkSweep::follow_klass Reviewed-by: kbarrett, tschatzl ! src/hotspot/share/gc/serial/markSweep.cpp ! src/hotspot/share/gc/serial/markSweep.hpp Changeset: 65fc0588 Author: Albert Mingkun Yang Date: 2022-12-20 12:43:53 +0000 URL: https://git.openjdk.org/loom/commit/65fc05884bc96ce0b6f572034ae085c933f85c61 8298968: G1: Incorrect merged remset stats Reviewed-by: tschatzl, kbarrett ! src/hotspot/share/gc/g1/g1RemSet.cpp Changeset: 03d99272 Author: Coleen Phillimore Date: 2022-12-20 13:21:50 +0000 URL: https://git.openjdk.org/loom/commit/03d992728e27bd3dcd00d1af8a7b7179281e626f 8298061: vmTestbase/nsk/sysdict/vm/stress/btree/btree012/btree012.java failed with "fatal error: refcount has gone to zero" Reviewed-by: iklam, dholmes ! src/hotspot/share/classfile/placeholders.hpp Changeset: 03afec16 Author: Coleen Phillimore Date: 2022-12-20 14:09:22 +0000 URL: https://git.openjdk.org/loom/commit/03afec16f8abecb845eb14db5b51eaac9131a3c8 8298162: Test PrintClasses hits assert when run with code that retransform classes Reviewed-by: dholmes, mgronlun ! src/hotspot/share/runtime/fieldDescriptor.cpp ! test/hotspot/jtreg/runtime/CommandLine/PrintClasses.java Changeset: f4d7f433 Author: Daniel D. Daugherty Date: 2022-12-20 16:20:50 +0000 URL: https://git.openjdk.org/loom/commit/f4d7f433942219704072a3fef156fe0fa7864f66 8299123: [BACKOUT] 4512626 Non-editable JTextArea provides no visual indication of keyboard focus Reviewed-by: tschatzl ! src/java.desktop/share/classes/javax/swing/text/DefaultCaret.java ! test/jdk/ProblemList.txt ! test/jdk/javax/swing/text/DefaultCaret/HidingSelection/HidingSelectionTest.java ! test/jdk/javax/swing/text/DefaultCaret/HidingSelection/MultiSelectionTest.java Changeset: 386db071 Author: Jesper Wilhelmsson Date: 2022-12-20 20:20:17 +0000 URL: https://git.openjdk.org/loom/commit/386db07143883f85307138eca2f0305d997a2171 Merge ! test/jdk/ProblemList.txt ! test/jdk/ProblemList.txt Changeset: 396a9bff Author: Kim Barrett Date: 2022-12-21 01:22:11 +0000 URL: https://git.openjdk.org/loom/commit/396a9bff68cd25331ff88927264eae51c583bf48 8298913: Add override qualifiers to Relocation classes Reviewed-by: kvn, aboldtch ! src/hotspot/share/code/relocInfo.hpp Changeset: f56285c3 Author: Xue-Lei Andrew Fan Date: 2022-12-21 01:47:50 +0000 URL: https://git.openjdk.org/loom/commit/f56285c3613bb127e22f544bd4b461a0584e9d2a 8299146: No copyright statement on ArtifactResolverException.java Reviewed-by: erikj ! test/lib/jdk/test/lib/artifacts/ArtifactResolverException.java Changeset: f36e1449 Author: Matthias Baesken Date: 2022-12-21 08:05:37 +0000 URL: https://git.openjdk.org/loom/commit/f36e144923da431a9c47faf5ae6577714fcf3adf 8299025: BMPImageReader.java readColorPalette could use staggeredReadByteStream Reviewed-by: clanger ! src/java.desktop/share/classes/com/sun/imageio/plugins/bmp/BMPImageReader.java Changeset: 85f9b37d Author: Andrey Turbanov Date: 2022-12-21 08:15:11 +0000 URL: https://git.openjdk.org/loom/commit/85f9b37d71852d35a75d404e1657db0562dacac5 8297682: Use Collections.emptyIterator where applicable Reviewed-by: stsypanov, alanb, jpai ! src/java.base/unix/classes/sun/nio/fs/UnixFileSystem.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java Changeset: b005013a Author: Naveen Narayanan Committer: Alexey Ivanov Date: 2022-12-21 10:48:27 +0000 URL: https://git.openjdk.org/loom/commit/b005013a0015656b7f6ccc26f8a13c44d61f77b9 8296275: Write a test to verify setAccelerator method of JMenuItem Reviewed-by: mvs, aivanov + test/jdk/javax/swing/JMenuItem/JMenuItemSetAcceleratorTest.java Changeset: a7d6de71 Author: Chris Hegarty Date: 2022-12-21 12:19:06 +0000 URL: https://git.openjdk.org/loom/commit/a7d6de71bb83c8715654f61dd166aad6e8dab847 8299015: Ensure that HttpResponse.BodySubscribers.ofFile writes all bytes Co-authored-by: Daniel Jeli?ski Reviewed-by: dfuchs, djelinski, jpai ! src/java.net.http/share/classes/jdk/internal/net/http/ResponseSubscribers.java ! src/java.net.http/share/classes/jdk/internal/net/http/common/Utils.java ! test/jdk/java/net/httpclient/PathSubscriber/BodySubscriberOfFileTest.java Changeset: 88bfe4d3 Author: Roland Westrelin Date: 2022-12-21 14:46:57 +0000 URL: https://git.openjdk.org/loom/commit/88bfe4d3bff5504bb6061d1484325dd6a55f06a2 8297724: Loop strip mining prevents some empty loops from being eliminated Reviewed-by: kvn, thartmann ! src/hotspot/share/opto/loopTransform.cpp ! src/hotspot/share/opto/loopnode.hpp + test/hotspot/jtreg/compiler/c2/irTests/TestLSMMissedEmptyLoop.java Changeset: 65442a2e Author: Matias Saavedra Silva Committer: Ioi Lam Date: 2022-12-21 15:33:24 +0000 URL: https://git.openjdk.org/loom/commit/65442a2e26afa7c31b5949e7e20606e4066ced3b 8269736: Optimize CDS PatchEmbeddedPointers::do_bit() Reviewed-by: ccheung, iklam ! src/hotspot/share/cds/archiveHeapLoader.cpp ! src/hotspot/share/cds/archiveHeapLoader.hpp ! src/hotspot/share/cds/archiveHeapLoader.inline.hpp ! src/hotspot/share/cds/filemap.cpp ! src/hotspot/share/cds/filemap.hpp ! test/hotspot/jtreg/runtime/cds/appcds/cacheObject/DifferentHeapSizes.java Changeset: 10d62fa2 Author: Xin Liu Date: 2022-12-21 16:48:20 +0000 URL: https://git.openjdk.org/loom/commit/10d62fa2183c0ed252ad0a9a743ae6a7710f9a95 8299061: Using lambda to optimize GraphKit::compute_stack_effects() Reviewed-by: kbarrett, thartmann ! src/hotspot/share/opto/graphKit.cpp Changeset: 7e59a0ec Author: Naoto Sato Date: 2022-12-21 18:09:21 +0000 URL: https://git.openjdk.org/loom/commit/7e59a0ecb672292814abdf7f2e31a5f5868c43d8 8298971: Move Console implementation into jdk internal package Reviewed-by: jpai ! src/java.base/share/classes/java/io/Console.java = src/java.base/share/classes/jdk/internal/io/JdkConsoleImpl.java ! src/java.base/unix/native/libjava/Console_md.c + src/java.base/unix/native/libjava/JdkConsoleImpl_md.c Changeset: f80faced Author: Damon Nguyen Committer: Harshitha Onkar Date: 2022-12-21 20:10:52 +0000 URL: https://git.openjdk.org/loom/commit/f80faced6e6c6c1b10541a8b0c91625215c9ef43 8202931: [macos] java/awt/Choice/ChoicePopupLocation/ChoicePopupLocation.java fails Reviewed-by: serb, honkar ! test/jdk/ProblemList.txt ! test/jdk/java/awt/Choice/ChoicePopupLocation/ChoicePopupLocation.java Changeset: e85d00f6 Author: Jonathan Gibbons Date: 2022-12-20 21:33:53 +0000 URL: https://git.openjdk.org/loom/commit/e85d00f6c32c9938fbc9529b055d90082f565fa3 8299147: Minor accessibility errors in the specs and man index pages Reviewed-by: mchung, erikj ! make/Docs.gmk Changeset: 3d4d9fd6 Author: Martin Doerr Date: 2022-12-20 22:02:34 +0000 URL: https://git.openjdk.org/loom/commit/3d4d9fd6e6de037950f94482d4e33f178eb15daa 8298947: compiler/codecache/MHIntrinsicAllocFailureTest.java fails intermittently Reviewed-by: kvn, chagedorn ! test/hotspot/jtreg/compiler/codecache/MHIntrinsicAllocFailureTest.java Changeset: f7be5b53 Author: Jonathan Gibbons Date: 2022-12-20 22:53:09 +0000 URL: https://git.openjdk.org/loom/commit/f7be5b530d10005ba928309870c9adc42afdf66a 8299156: Broken link in jdk.compiler/module-info.java Reviewed-by: iris ! src/jdk.compiler/share/classes/module-info.java Changeset: 92fe304f Author: Christoph Langer Date: 2022-12-21 10:57:24 +0000 URL: https://git.openjdk.org/loom/commit/92fe304f08b406cb0f87cf32497aea2f5ce9c5ea 8298588: WebSockets: HandshakeUrlEncodingTest unnecessarily depends on a response body Backport-of: 909d0cb4d9475fd367b8bc64a6b50c5a324e9a01 ! test/jdk/java/net/httpclient/websocket/HandshakeUrlEncodingTest.java Changeset: 81933b7a Author: Nick Gasson Date: 2022-12-21 11:00:48 +0000 URL: https://git.openjdk.org/loom/commit/81933b7a927c1579eda7b6678901e5d2bc1c1aed 8298642: ParallelGC -XX:+UseNUMA eden spaces allocated on wrong node Reviewed-by: tschatzl, ayang ! src/hotspot/share/gc/parallel/mutableNUMASpace.cpp Changeset: 9adc349c Author: Tyler Steele Date: 2022-12-21 18:17:42 +0000 URL: https://git.openjdk.org/loom/commit/9adc349cbb38ccc23096c4504c7b4b70009c660f 8298726: (fs) Change PollingWatchService to record last modified time as FileTime rather than milliseconds Backport-of: 5f63f7a742a1071a87ca69463bae6e04a44fe462 ! src/java.base/share/classes/sun/nio/fs/PollingWatchService.java Changeset: 22007a1e Author: Volodymyr Paprotski Committer: Sandhya Viswanathan Date: 2022-12-21 18:43:40 +0000 URL: https://git.openjdk.org/loom/commit/22007a1e387a1b8e897c6fbb056377b7ddc6ec00 8298893: Rename option UsePolyIntrinsics to UsePoly1305Intrinsics Reviewed-by: jnimeh, chagedorn, thartmann ! src/hotspot/cpu/x86/stubGenerator_x86_64.cpp ! src/hotspot/cpu/x86/vm_version_x86.cpp ! src/hotspot/share/classfile/vmIntrinsics.cpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/runtime/globals.hpp Changeset: 34cdda5b Author: Jesper Wilhelmsson Date: 2022-12-21 23:50:59 +0000 URL: https://git.openjdk.org/loom/commit/34cdda5b8359cce33c2d4f92a41a620aea4f96e7 Merge Changeset: 50120396 Author: Sergey Bylokhov Date: 2022-12-22 07:20:06 +0000 URL: https://git.openjdk.org/loom/commit/50120396b6cca1219fb5dd42a11e4b29b79bd3bd 8298887: On the latest macOS+XCode the Robot API may report wrong colors Reviewed-by: azvegint ! src/java.desktop/macosx/native/libawt_lwawt/awt/CRobot.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/QuartzSurfaceData.h ! test/jdk/java/awt/AlphaComposite/WindowAlphaCompositeTest.java ! test/jdk/java/awt/Robot/CheckCommonColors/CheckCommonColors.java ! test/jdk/java/awt/font/GlyphVector/MultiSlotFontTest.java Changeset: a3693ccc Author: Bill Huang Date: 2022-12-22 16:50:59 +0000 URL: https://git.openjdk.org/loom/commit/a3693ccc617d06137a61050b34646e8a90ed3d7e 8295087: Manual Test to Automated Test Conversion Reviewed-by: ssahoo, rhalade ! test/jdk/ProblemList.txt ! test/jdk/TEST.groups ! test/jdk/java/security/Policy/Root/Root.java ! test/jdk/javax/crypto/CryptoPermissions/InconsistentEntries.java + test/jdk/javax/crypto/CryptoPermissions/default_local.policy ! test/jdk/sun/security/provider/PolicyParser/ExtDirs.java ! test/jdk/sun/security/provider/PolicyParser/ExtDirs.policy ! test/jdk/sun/security/provider/PolicyParser/ExtDirs1.policy ! test/jdk/sun/security/provider/PolicyParser/ExtDirs2.policy ! test/jdk/sun/security/provider/PolicyParser/ExtDirs3.policy ! test/jdk/sun/security/provider/PolicyParser/ExtDirsChange.java ! test/jdk/sun/security/provider/PolicyParser/ExtDirsChange.policy ! test/jdk/sun/security/provider/PolicyParser/ExtDirsDefaultPolicy.java Changeset: 62a033ec Author: Kim Barrett Date: 2022-12-22 17:30:09 +0000 URL: https://git.openjdk.org/loom/commit/62a033ecd7058f4a4354ebdcd667b3d7991e1f3d 8299191: Unnecessarily global friend functions for relocInfo Reviewed-by: chagedorn, kvn ! src/hotspot/share/asm/codeBuffer.cpp ! src/hotspot/share/code/relocInfo.cpp ! src/hotspot/share/code/relocInfo.hpp Changeset: b378381a Author: Andrey Turbanov Date: 2022-12-22 19:09:37 +0000 URL: https://git.openjdk.org/loom/commit/b378381a9c5abf555c4ccf87d387d2cd77196e04 8299199: Avoid redundant split calls in FontConfiguration.initReorderMap implementations Reviewed-by: aivanov ! src/java.desktop/share/classes/sun/awt/FontConfiguration.java ! src/java.desktop/unix/classes/sun/font/MFontConfiguration.java ! src/java.desktop/windows/classes/sun/awt/windows/WFontConfiguration.java Changeset: 6ccee839 Author: Ioi Lam Date: 2022-12-22 20:50:20 +0000 URL: https://git.openjdk.org/loom/commit/6ccee839580fd9dc4cd4941b44dbbe3105202561 8292206: TestCgroupMetrics.java fails as getMemoryUsage() is lower than expected Reviewed-by: dholmes, sgehwolf ! test/jdk/jdk/internal/platform/cgroup/TestCgroupMetrics.java ! test/jdk/jdk/internal/platform/docker/TestSystemMetrics.java ! test/lib/jdk/test/lib/containers/cgroup/MetricsTester.java Changeset: 5e2de896 Author: Ichiroh Takiguchi Date: 2022-12-22 21:07:01 +0000 URL: https://git.openjdk.org/loom/commit/5e2de89628aaf6acb8e458fb417426ca5e477bea 8299194: CustomTzIDCheckDST.java may fail at future date Reviewed-by: naoto ! test/jdk/java/util/TimeZone/CustomTzIDCheckDST.java Changeset: 2294f225 Author: Jonathan Gibbons Date: 2022-12-22 21:20:43 +0000 URL: https://git.openjdk.org/loom/commit/2294f225c074516abd2fecf5c64e2e1a2453bc6f 8286311: remove boilerplate from use of runTests Reviewed-by: hannesw ! test/langtools/jdk/javadoc/doclet/5093723/T5093723.java ! test/langtools/jdk/javadoc/doclet/AccessAsciiArt/AccessAsciiArt.java ! test/langtools/jdk/javadoc/doclet/AccessH1/AccessH1.java ! test/langtools/jdk/javadoc/doclet/AccessSkipNav/AccessSkipNav.java ! test/langtools/jdk/javadoc/doclet/AccessSummary/AccessSummary.java ! test/langtools/jdk/javadoc/doclet/AuthorDD/AuthorDD.java ! test/langtools/jdk/javadoc/doclet/DocRootSlash/DocRootSlash.java ! test/langtools/jdk/javadoc/doclet/InheritDocForUserTags/DocTest.java ! test/langtools/jdk/javadoc/doclet/JavascriptWinTitle/JavascriptWinTitle.java ! test/langtools/jdk/javadoc/doclet/MetaTag/MetaTag.java ! test/langtools/jdk/javadoc/doclet/T6735320/T6735320.java ! test/langtools/jdk/javadoc/doclet/ValidHtml/ValidHtml.java ! test/langtools/jdk/javadoc/doclet/VersionNumber/VersionNumber.java ! test/langtools/jdk/javadoc/doclet/WindowTitles/WindowTitles.java ! test/langtools/jdk/javadoc/doclet/constantValues/TestConstantValuesDriver.java ! test/langtools/jdk/javadoc/doclet/dupThrowsTags/TestDupThrowsTags.java ! test/langtools/jdk/javadoc/doclet/testAbsLinkPath/TestAbsLinkPath.java ! test/langtools/jdk/javadoc/doclet/testAbstractMethod/TestAbstractMethod.java ! test/langtools/jdk/javadoc/doclet/testAnchorNames/TestAnchorNames.java ! test/langtools/jdk/javadoc/doclet/testAnnotationOptional/TestAnnotationOptional.java ! test/langtools/jdk/javadoc/doclet/testAnnotationTypes/TestAnnotationTypes.java ! test/langtools/jdk/javadoc/doclet/testAuthor/TestAuthor.java ! test/langtools/jdk/javadoc/doclet/testAutoHeaderId/TestAutoHeaderId.java ! test/langtools/jdk/javadoc/doclet/testAutoLoadTaglets/TestAutoLoadTaglets.java ! test/langtools/jdk/javadoc/doclet/testBackSlashInLink/TestBackSlashInLink.java ! test/langtools/jdk/javadoc/doclet/testBadHtml/TestBadHtml.java ! test/langtools/jdk/javadoc/doclet/testBadPackageFileInJar/TestBadPackageFileInJar.java ! test/langtools/jdk/javadoc/doclet/testBadSourceFile/TestBadSourceFile.java ! test/langtools/jdk/javadoc/doclet/testBaseClass/TestBaseClass.java ! test/langtools/jdk/javadoc/doclet/testBimodalTaglets/TestBimodalTaglets.java ! test/langtools/jdk/javadoc/doclet/testBreakIterator/TestBreakIterator.java ! test/langtools/jdk/javadoc/doclet/testCRLineSeparator/TestCRLineSeparator.java ! test/langtools/jdk/javadoc/doclet/testCharset/TestCharset.java ! test/langtools/jdk/javadoc/doclet/testCharsetDocencodingOptions/TestCharsetDocencodingOptions.java ! test/langtools/jdk/javadoc/doclet/testClassCrossReferences/TestClassCrossReferences.java ! test/langtools/jdk/javadoc/doclet/testClassLinks/TestClassLinks.java ! test/langtools/jdk/javadoc/doclet/testClassTree/TestClassTree.java ! test/langtools/jdk/javadoc/doclet/testCmndLineClass/TestCmndLineClass.java ! test/langtools/jdk/javadoc/doclet/testCompletionFailure/TestCompletionFailure.java ! test/langtools/jdk/javadoc/doclet/testConditionalPages/TestConditionalPages.java ! test/langtools/jdk/javadoc/doclet/testConstantValuesPage/TestConstantValuesPage.java ! test/langtools/jdk/javadoc/doclet/testConstructorIndent/TestConstructorIndent.java ! test/langtools/jdk/javadoc/doclet/testConstructors/TestConstructors.java ! test/langtools/jdk/javadoc/doclet/testCopyFiles/TestCopyFiles.java ! test/langtools/jdk/javadoc/doclet/testCustomTagletRegistration/TestRegistrationErrors.java ! test/langtools/jdk/javadoc/doclet/testDateOption/TestDateOption.java ! test/langtools/jdk/javadoc/doclet/testDeprecatedDocs/TestDeprecatedDocs.java ! test/langtools/jdk/javadoc/doclet/testDiagsLineCaret/TestDiagsLineCaret.java ! test/langtools/jdk/javadoc/doclet/testDocEncoding/TestDocEncoding.java ! test/langtools/jdk/javadoc/doclet/testDocErrorReporter/TestDocErrorReporter.java ! test/langtools/jdk/javadoc/doclet/testDocFileDir/TestDocFileDir.java ! test/langtools/jdk/javadoc/doclet/testDocFiles/TestDocFiles.java ! test/langtools/jdk/javadoc/doclet/testDocLintOption/TestDocLintOption.java ! test/langtools/jdk/javadoc/doclet/testDocPaths/TestDocPaths.java ! test/langtools/jdk/javadoc/doclet/testDocRootInlineTag/TestDocRootInlineTag.java ! test/langtools/jdk/javadoc/doclet/testDocRootLink/TestDocRootLink.java ! test/langtools/jdk/javadoc/doclet/testDocTreeDiags/TestDocTreeDiags.java ! test/langtools/jdk/javadoc/doclet/testDoclintDocletMessages/TestDocLintDocletMessages.java ! test/langtools/jdk/javadoc/doclet/testDupParamWarn/TestDupParamWarn.java ! test/langtools/jdk/javadoc/doclet/testEmptyClass/TestEmptyClass.java ! test/langtools/jdk/javadoc/doclet/testEmptyInheritDoc/TestEmptyInheritDoc.java ! test/langtools/jdk/javadoc/doclet/testEnclosingClass/TestEnclosingClass.java ! test/langtools/jdk/javadoc/doclet/testEncoding/TestEncoding.java ! test/langtools/jdk/javadoc/doclet/testEnumConstructor/TestEnumConstructor.java ! test/langtools/jdk/javadoc/doclet/testExceptionInheritance/TestExceptionInheritance.java ! test/langtools/jdk/javadoc/doclet/testExternalOverriddenMethod/TestExternalOverriddenMethod.java ! test/langtools/jdk/javadoc/doclet/testGeneratedBy/TestGeneratedBy.java ! test/langtools/jdk/javadoc/doclet/testGeneratedClasses/TestGeneratedClasses.java ! test/langtools/jdk/javadoc/doclet/testGenericMethodLinkTaglet/TestGenericMethodLinkTaglet.java ! test/langtools/jdk/javadoc/doclet/testGrandParentTypes/TestGrandParentTypes.java ! test/langtools/jdk/javadoc/doclet/testGroupName/TestGroupName.java ! test/langtools/jdk/javadoc/doclet/testGroupOption/TestGroupOption.java ! test/langtools/jdk/javadoc/doclet/testHeadTag/TestHeadTag.java ! test/langtools/jdk/javadoc/doclet/testHeadings/TestHeadings.java ! test/langtools/jdk/javadoc/doclet/testHelpFile/TestHelpFile.java ! test/langtools/jdk/javadoc/doclet/testHelpOption/TestHelpOption.java ! test/langtools/jdk/javadoc/doclet/testHelpPage/TestHelpPage.java ! test/langtools/jdk/javadoc/doclet/testHiddenMembers/TestHiddenMembers.java ! test/langtools/jdk/javadoc/doclet/testHiddenTag/TestHiddenTag.java ! test/langtools/jdk/javadoc/doclet/testHref/TestHref.java ! test/langtools/jdk/javadoc/doclet/testHrefInDocComment/TestHrefInDocComment.java ! test/langtools/jdk/javadoc/doclet/testHtml4Removal/TestHtml4Removal.java ! test/langtools/jdk/javadoc/doclet/testHtmlComments/TestHtmlComments.java ! test/langtools/jdk/javadoc/doclet/testHtmlDefinitionListTag/TestHtmlDefinitionListTag.java ! test/langtools/jdk/javadoc/doclet/testHtmlDocument/TestHtmlDocument.java ! test/langtools/jdk/javadoc/doclet/testHtmlLandmarkRegions/TestHtmlLandmarkRegions.java ! test/langtools/jdk/javadoc/doclet/testHtmlStrongTag/TestHtmlStrongTag.java ! test/langtools/jdk/javadoc/doclet/testHtmlTableStyles/TestHtmlTableStyles.java ! test/langtools/jdk/javadoc/doclet/testHtmlTableTags/TestHtmlTableTags.java ! test/langtools/jdk/javadoc/doclet/testHtmlTag/TestHtmlTag.java ! test/langtools/jdk/javadoc/doclet/testHtmlVersion/TestHtmlVersion.java ! test/langtools/jdk/javadoc/doclet/testIOException/TestIOException.java ! test/langtools/jdk/javadoc/doclet/testIncluded/TestIncluded.java ! test/langtools/jdk/javadoc/doclet/testIndentation/TestIndentation.java ! test/langtools/jdk/javadoc/doclet/testIndex/TestIndex.java ! test/langtools/jdk/javadoc/doclet/testIndexFiles/TestIndexFiles.java ! test/langtools/jdk/javadoc/doclet/testIndexInDocFiles/TestIndexInDocFiles.java ! test/langtools/jdk/javadoc/doclet/testIndexInPackageFiles/TestIndexInPackageFiles.java ! test/langtools/jdk/javadoc/doclet/testIndexTaglet/TestIndexTaglet.java ! test/langtools/jdk/javadoc/doclet/testIndexWithModules/TestIndexWithModules.java ! test/langtools/jdk/javadoc/doclet/testInheritDocWithinInappropriateTag/TestInheritDocWithinInappropriateTag.java ! test/langtools/jdk/javadoc/doclet/testInherited/TestInherited.java ! test/langtools/jdk/javadoc/doclet/testInlineLinkLabel/TestInlineLinkLabel.java ! test/langtools/jdk/javadoc/doclet/testInterface/TestInterface.java ! test/langtools/jdk/javadoc/doclet/testJavaFX/TestFxProperties.java ! test/langtools/jdk/javadoc/doclet/testJavaFX/TestJavaFX.java ! test/langtools/jdk/javadoc/doclet/testJavaFX/TestJavaFXCombo.java ! test/langtools/jdk/javadoc/doclet/testJavaFX/TestJavaFXMissingPropComments.java ! test/langtools/jdk/javadoc/doclet/testJavaFX/TestJavaFxMode.java ! test/langtools/jdk/javadoc/doclet/testJavaPackage/TestJavaPackage.java ! test/langtools/jdk/javadoc/doclet/testJavascript/TestJavascript.java ! test/langtools/jdk/javadoc/doclet/testLeadingSpaces/LeadingSpaces.java ! test/langtools/jdk/javadoc/doclet/testLegacyTaglet/TestLegacyTaglet.java ! test/langtools/jdk/javadoc/doclet/testLegalNotices/TestLegalNotices.java ! test/langtools/jdk/javadoc/doclet/testLinkOption/TestBadLinkOption.java ! test/langtools/jdk/javadoc/doclet/testLinkOption/TestLinkOption.java ! test/langtools/jdk/javadoc/doclet/testLinkOption/TestLinkOptionWithAutomaticModule.java ! test/langtools/jdk/javadoc/doclet/testLinkOption/TestLinkOptionWithModule.java ! test/langtools/jdk/javadoc/doclet/testLinkOption/TestNewLineInLink.java ! test/langtools/jdk/javadoc/doclet/testLinkOption/TestOptionOrder.java ! test/langtools/jdk/javadoc/doclet/testLinkOption/TestRedirectLinks.java ! test/langtools/jdk/javadoc/doclet/testLinkPlatform/TestLinkPlatform.java ! test/langtools/jdk/javadoc/doclet/testLinkTaglet/TestLinkNotFound.java ! test/langtools/jdk/javadoc/doclet/testLinkTaglet/TestLinkTaglet.java ! test/langtools/jdk/javadoc/doclet/testLinkTaglet/TestLinkTagletPrimitive.java ! test/langtools/jdk/javadoc/doclet/testLinkTaglet/TestLinkTagletWithModule.java ! test/langtools/jdk/javadoc/doclet/testLinkToSerialForm/TestLinkToSerialForm.java ! test/langtools/jdk/javadoc/doclet/testLinksWithNoDeprecatedOption/TestLinksWithNoDeprecatedOption.java ! test/langtools/jdk/javadoc/doclet/testLists/TestLists.java ! test/langtools/jdk/javadoc/doclet/testLiteralCodeInPre/TestLiteralCodeInPre.java ! test/langtools/jdk/javadoc/doclet/testMemberInheritance/TestMemberInheritance.java ! test/langtools/jdk/javadoc/doclet/testMemberSummary/TestMemberSummary.java ! test/langtools/jdk/javadoc/doclet/testMetadata/TestMetadata.java ! test/langtools/jdk/javadoc/doclet/testMethodId/TestMethodId.java ! test/langtools/jdk/javadoc/doclet/testMethodSignature/TestMethodSignature.java ! test/langtools/jdk/javadoc/doclet/testMethodTypes/TestMethodTypes.java ! test/langtools/jdk/javadoc/doclet/testMissingComment/TestMissingComment.java ! test/langtools/jdk/javadoc/doclet/testMissingType/TestMissingType.java ! test/langtools/jdk/javadoc/doclet/testModifierEx/TestModifierEx.java ! test/langtools/jdk/javadoc/doclet/testModuleDirs/TestModuleDirs.java ! test/langtools/jdk/javadoc/doclet/testModuleSpecificStylesheet/TestModuleSpecificStylesheet.java ! test/langtools/jdk/javadoc/doclet/testModules/TestEmptyModule.java ! test/langtools/jdk/javadoc/doclet/testModules/TestIndirectExportsOpens.java ! test/langtools/jdk/javadoc/doclet/testModules/TestModulePackages.java ! test/langtools/jdk/javadoc/doclet/testModules/TestModuleServices.java ! test/langtools/jdk/javadoc/doclet/testModules/TestModuleServicesLink.java ! test/langtools/jdk/javadoc/doclet/testModules/TestModules.java ! test/langtools/jdk/javadoc/doclet/testNavigation/TestModuleNavigation.java ! test/langtools/jdk/javadoc/doclet/testNavigation/TestNavigation.java ! test/langtools/jdk/javadoc/doclet/testNestedClasses/TestNestedClasses.java ! test/langtools/jdk/javadoc/doclet/testNestedGenerics/TestNestedGenerics.java ! test/langtools/jdk/javadoc/doclet/testNestedInlineTags/TestNestedIndexTag.java ! test/langtools/jdk/javadoc/doclet/testNestedInlineTags/TestNestedLinkTag.java ! test/langtools/jdk/javadoc/doclet/testNestedInlineTags/TestNestedReturnTag.java ! test/langtools/jdk/javadoc/doclet/testNestedInlineTags/TestNestedSummaryTag.java ! test/langtools/jdk/javadoc/doclet/testNewLanguageFeatures/TestNewLanguageFeatures.java ! test/langtools/jdk/javadoc/doclet/testNoFrames/TestNoFrames.java ! test/langtools/jdk/javadoc/doclet/testNoPackagesFile/TestNoPackagesFile.java ! test/langtools/jdk/javadoc/doclet/testNonInlineHtmlTagRemoval/TestNonInlineHtmlTagRemoval.java ! test/langtools/jdk/javadoc/doclet/testNotifications/TestNotifications.java ! test/langtools/jdk/javadoc/doclet/testOptions/TestOptions.java ! test/langtools/jdk/javadoc/doclet/testOrdering/TestOrdering.java ! test/langtools/jdk/javadoc/doclet/testOverriddenMethods/TestBadOverride.java ! test/langtools/jdk/javadoc/doclet/testOverriddenMethods/TestMultiInheritance.java ! test/langtools/jdk/javadoc/doclet/testOverriddenMethods/TestOverriddenDeprecatedMethods.java ! test/langtools/jdk/javadoc/doclet/testOverriddenMethods/TestOverriddenMethodDocCopy.java ! test/langtools/jdk/javadoc/doclet/testOverriddenMethods/TestOverriddenPrivateMethods.java ! test/langtools/jdk/javadoc/doclet/testOverriddenMethods/TestOverriddenPrivateMethodsWithPackageFlag.java ! test/langtools/jdk/javadoc/doclet/testOverriddenMethods/TestOverriddenPrivateMethodsWithPrivateFlag.java ! test/langtools/jdk/javadoc/doclet/testOverriddenMethods/TestOverrideMethods.java ! test/langtools/jdk/javadoc/doclet/testOverview/TestOverview.java ! test/langtools/jdk/javadoc/doclet/testPackageAnnotation/TestPackageAnnotation.java ! test/langtools/jdk/javadoc/doclet/testPackageDeprecation/TestPackageDeprecation.java ! test/langtools/jdk/javadoc/doclet/testPackageDescription/TestPackageDescription.java ! test/langtools/jdk/javadoc/doclet/testPackageHtml/TestPackageHtml.java ! test/langtools/jdk/javadoc/doclet/testPackagePage/TestPackagePage.java ! test/langtools/jdk/javadoc/doclet/testPackageSpecificStylesheet/TestPackageSpecificStylesheet.java ! test/langtools/jdk/javadoc/doclet/testPackageSummary/TestPackageSummary.java ! test/langtools/jdk/javadoc/doclet/testParamTaglet/TestParamTaglet.java ! test/langtools/jdk/javadoc/doclet/testPreview/TestPreview.java ! test/langtools/jdk/javadoc/doclet/testPrivateClasses/TestPrivateClasses.java ! test/langtools/jdk/javadoc/doclet/testProperty/TestProperty.java ! test/langtools/jdk/javadoc/doclet/testRecordLinks/TestRecordLinks.java ! test/langtools/jdk/javadoc/doclet/testRecordTypes/TestRecordTypes.java ! test/langtools/jdk/javadoc/doclet/testRecurseSubPackages/TestRecurseSubPackages.java ! test/langtools/jdk/javadoc/doclet/testRelatedPackages/TestRelatedPackages.java ! test/langtools/jdk/javadoc/doclet/testRelativeLinks/TestRelativeLinks.java ! test/langtools/jdk/javadoc/doclet/testRelativeLinks/TestRelativeModuleLinks.java ! test/langtools/jdk/javadoc/doclet/testRepeatedAnnotations/TestRepeatedAnnotations.java ! test/langtools/jdk/javadoc/doclet/testReporterStreams/TestReporterStreams.java ! test/langtools/jdk/javadoc/doclet/testReturnTag/TestReturnTag.java ! test/langtools/jdk/javadoc/doclet/testSealedTypes/TestSealedTypes.java ! test/langtools/jdk/javadoc/doclet/testSearch/TestSearch.java ! test/langtools/jdk/javadoc/doclet/testSearchScript/TestSearchScript.java ! test/langtools/jdk/javadoc/doclet/testSeeLinkAnchor/TestSeeLinkAnchor.java ! test/langtools/jdk/javadoc/doclet/testSeeTag/TestSeeTag.java ! test/langtools/jdk/javadoc/doclet/testSeeTag/TestSeeTagWithModule.java ! test/langtools/jdk/javadoc/doclet/testSerialMissing/TestSerialMissing.java ! test/langtools/jdk/javadoc/doclet/testSerialTag/TestSerialTag.java ! test/langtools/jdk/javadoc/doclet/testSerialVersionUID/TestSerialVersionUID.java ! test/langtools/jdk/javadoc/doclet/testSerialWithLink/TestSerialWithLink.java ! test/langtools/jdk/javadoc/doclet/testSerializedForm/TestSerializedForm.java ! test/langtools/jdk/javadoc/doclet/testSerializedFormDeprecationInfo/TestSerializedFormDeprecationInfo.java ! test/langtools/jdk/javadoc/doclet/testSerializedFormWithClassFile/TestSerializedFormWithClassFile.java ! test/langtools/jdk/javadoc/doclet/testSerializedFormWithSee/TestSerializedFormWithSee.java ! test/langtools/jdk/javadoc/doclet/testSimpleTag/TestSimpleTag.java ! test/langtools/jdk/javadoc/doclet/testSimpleTagExclude/TestSimpleTagExclude.java ! test/langtools/jdk/javadoc/doclet/testSimpleTagInherit/TestSimpleTagInherit.java ! test/langtools/jdk/javadoc/doclet/testSinceTag/TestSinceTag.java ! test/langtools/jdk/javadoc/doclet/testSingleQuotedLink/TestSingleQuotedLink.java ! test/langtools/jdk/javadoc/doclet/testSingletonLists/TestSingletonLists.java ! test/langtools/jdk/javadoc/doclet/testSnippetTag/TestLangProperties.java ! test/langtools/jdk/javadoc/doclet/testSnippetTag/TestSnippetMarkup.java ! test/langtools/jdk/javadoc/doclet/testSnippetTag/TestSnippetPathOption.java ! test/langtools/jdk/javadoc/doclet/testSnippetTag/TestSnippetTag.java ! test/langtools/jdk/javadoc/doclet/testSourceTab/TestSourceTab.java ! test/langtools/jdk/javadoc/doclet/testSpecTag/TestSpecTag.java ! test/langtools/jdk/javadoc/doclet/testStylesheet/TestStylesheet.java ! test/langtools/jdk/javadoc/doclet/testStylesheetOverwrite/TestStylesheetOverwrite.java ! test/langtools/jdk/javadoc/doclet/testSubTitle/TestSubTitle.java ! test/langtools/jdk/javadoc/doclet/testSummaryHeading/TestSummaryHeading.java ! test/langtools/jdk/javadoc/doclet/testSummaryTag/TestSummaryTag.java ! test/langtools/jdk/javadoc/doclet/testSuperclassInSerialForm/TestSuperClassInSerialForm.java ! test/langtools/jdk/javadoc/doclet/testSupplementary/TestSupplementary.java ! test/langtools/jdk/javadoc/doclet/testSystemPropertyPage/TestSystemPropertyPage.java ! test/langtools/jdk/javadoc/doclet/testSystemPropertyTaglet/TestSystemPropertyTaglet.java ! test/langtools/jdk/javadoc/doclet/testTagInheritance/TestTagInheritance.java ! test/langtools/jdk/javadoc/doclet/testTagMisuse/TestTagMisuse.java ! test/langtools/jdk/javadoc/doclet/testTagOrder/TestTagOrder.java ! test/langtools/jdk/javadoc/doclet/testTagOutput/TestTagOutput.java ! test/langtools/jdk/javadoc/doclet/testTaglets/TestTaglets.java ! test/langtools/jdk/javadoc/doclet/testTerminology/TestTerminology.java ! test/langtools/jdk/javadoc/doclet/testThrows/TestThrows.java ! test/langtools/jdk/javadoc/doclet/testThrowsHead/TestThrowsHead.java ! test/langtools/jdk/javadoc/doclet/testThrowsInheritance/TestThrowsTagInheritance.java ! test/langtools/jdk/javadoc/doclet/testThrowsInheritanceMatching/TestExceptionTypeMatching.java ! test/langtools/jdk/javadoc/doclet/testThrowsInheritanceMultiple/TestOneToMany.java ! test/langtools/jdk/javadoc/doclet/testThrowsTag/TestThrowsTag.java ! test/langtools/jdk/javadoc/doclet/testTitleInHref/TestTitleInHref.java ! test/langtools/jdk/javadoc/doclet/testTopOption/TestTopOption.java ! test/langtools/jdk/javadoc/doclet/testTypeAnnotations/TestTypeAnnotations.java ! test/langtools/jdk/javadoc/doclet/testTypeParams/TestTypeParameters.java ! test/langtools/jdk/javadoc/doclet/testTypeVariableLinks/TestTypeVariableLinks.java ! test/langtools/jdk/javadoc/doclet/testUnicode/TestUnicode.java ! test/langtools/jdk/javadoc/doclet/testUnnamedPackage/TestUnnamedPackage.java ! test/langtools/jdk/javadoc/doclet/testUseOption/TestUseOption.java ! test/langtools/jdk/javadoc/doclet/testUserTaglet/TestUserTaglet.java ! test/langtools/jdk/javadoc/doclet/testValueTag/TestValueFormats.java ! test/langtools/jdk/javadoc/doclet/testValueTag/TestValueTag.java ! test/langtools/jdk/javadoc/doclet/testValueTag/TestValueTagInModule.java ! test/langtools/jdk/javadoc/doclet/testVersionOption/TestVersionOption.java ! test/langtools/jdk/javadoc/doclet/testVersionTag/TestVersionTag.java ! test/langtools/jdk/javadoc/doclet/testVisibleMembers/TestVisibleMembers.java ! test/langtools/jdk/javadoc/doclet/testWarnBadParamNames/TestWarnBadParamNames.java ! test/langtools/jdk/javadoc/doclet/testWarnings/TestWarnings.java ! test/langtools/jdk/javadoc/doclet/testXOption/TestXOption.java ! test/langtools/jdk/javadoc/doclet/typeAnnotations/smoke/TestSmoke.java ! test/langtools/jdk/javadoc/lib/javadoc/tester/JavadocTester.java ! test/langtools/jdk/javadoc/testJavadocTester/TestJavadocTester.java ! test/langtools/jdk/javadoc/testJavadocTester/TestJavadocTesterCrash.java ! test/langtools/jdk/javadoc/testTFMBuilder/TestTFMBuilder.java ! test/langtools/jdk/javadoc/tool/8224612/OptionsTest.java ! test/langtools/jdk/javadoc/tool/8224613/OptionProcessingFailureTest.java ! test/langtools/jdk/javadoc/tool/CommandLineHelpTest.java ! test/langtools/jdk/javadoc/tool/exceptionHandling/TestExceptionHandling.java ! test/langtools/jdk/javadoc/tool/removeOldDoclet/RemoveOldDoclet.java ! test/langtools/jdk/javadoc/tool/reporter_generates_warnings/ReporterGeneratesWarningsInsteadOfNotes.java ! test/langtools/jdk/javadoc/tool/testToolStreams/TestToolStreams.java ! test/langtools/jdk/javadoc/tool/testWErrorOption/TestWErrorOption.java Changeset: 2f4098e1 Author: Xiaolin Zheng Committer: Fei Yang Date: 2022-12-23 09:22:39 +0000 URL: https://git.openjdk.org/loom/commit/2f4098e1dc9c97e706d70008e473f9c4496cbc8a 8299168: RISC-V: Fix MachNode size mismatch for MacroAssembler::_verify_oops* Reviewed-by: fyang ! src/hotspot/cpu/riscv/macroAssembler_riscv.cpp Changeset: fef70d78 Author: Alexander Zuev Date: 2022-12-22 00:12:15 +0000 URL: https://git.openjdk.org/loom/commit/fef70d78baec9ce11d50b9a4c1fb26a1b854ccbf 8299077: [REDO] JDK-4512626 Non-editable JTextArea provides no visual indication of keyboard focus 8299127: [REDO] JDK-8194048 Regression automated test '/open/test/jdk/javax/swing/text/DefaultCaret/HidingSelection/HidingSelectionTest.java' fails 8299128: [REDO] JDK-8213562 Test javax/swing/text/DefaultCaret/HidingSelection/MultiSelectionTest.java fails Reviewed-by: aivanov, azvegint ! src/java.desktop/share/classes/javax/swing/text/DefaultCaret.java ! test/jdk/ProblemList.txt ! test/jdk/javax/swing/text/DefaultCaret/HidingSelection/HidingSelectionTest.java ! test/jdk/javax/swing/text/DefaultCaret/HidingSelection/MultiSelectionTest.java Changeset: a0a09d56 Author: Roland Westrelin Date: 2022-12-22 08:56:00 +0000 URL: https://git.openjdk.org/loom/commit/a0a09d56ba4fc6133b423ad29d86fc99dd6dc19b 8298176: remove OpaqueZeroTripGuardPostLoop once main-loop disappears Reviewed-by: thartmann, chagedorn, kvn ! src/hotspot/share/opto/loopTransform.cpp ! src/hotspot/share/opto/opaquenode.hpp ! src/hotspot/share/opto/phaseX.cpp ! src/hotspot/share/opto/phaseX.hpp ! src/hotspot/share/opto/subnode.cpp ! src/hotspot/share/opto/subnode.hpp + test/hotspot/jtreg/compiler/loopopts/TestOpaqueZeroTripGuardPostLoopRemoval.java Changeset: 5e001d6f Author: Ajit Ghaisas Date: 2022-12-22 10:38:12 +0000 URL: https://git.openjdk.org/loom/commit/5e001d6ff34e2cc954f824117a73dd39f09a81c1 8299207: [Testbug] Add back test/jdk/java/awt/Graphics2D/DrawPrimitivesTest.java Co-authored-by: Alexey Ushakov Reviewed-by: jdv + test/jdk/java/awt/Graphics2D/DrawPrimitivesTest.java Changeset: 9863f59e Author: Chris Hegarty Date: 2022-12-22 12:49:25 +0000 URL: https://git.openjdk.org/loom/commit/9863f59e1db84f55dc9a1670cd73ec4bfc07bcb0 8299015: Ensure that HttpResponse.BodySubscribers.ofFile writes all bytes Backport-of: a7d6de71bb83c8715654f61dd166aad6e8dab847 ! src/java.net.http/share/classes/jdk/internal/net/http/ResponseSubscribers.java ! src/java.net.http/share/classes/jdk/internal/net/http/common/Utils.java ! test/jdk/java/net/httpclient/PathSubscriber/BodySubscriberOfFileTest.java Changeset: a80c91d0 Author: Mark Powers Committer: Sean Mullan Date: 2022-12-22 15:29:53 +0000 URL: https://git.openjdk.org/loom/commit/a80c91d0360864e34569b684cf159e2dcdebeaaf 8299230: Use https: in links Reviewed-by: jjg, mullan, xuelei ! src/java.base/share/classes/java/security/DrbgParameters.java ! src/java.base/share/classes/java/security/SecureRandom.java Changeset: 33042a49 Author: Stuart Marks Date: 2022-12-22 21:56:04 +0000 URL: https://git.openjdk.org/loom/commit/33042a49d75011958e5030679433e6b2a779d90a 8299237: add ArraysSupport.newLength test to a test group Reviewed-by: naoto ! test/jdk/TEST.groups Changeset: 19ce23c6 Author: Jesper Wilhelmsson Date: 2022-12-23 11:25:10 +0000 URL: https://git.openjdk.org/loom/commit/19ce23c6459a452c8d3856b9ed96bfa54a8346ae Merge ! src/hotspot/share/opto/loopTransform.cpp ! src/hotspot/share/opto/phaseX.cpp ! src/hotspot/share/opto/phaseX.hpp ! src/hotspot/share/opto/subnode.cpp ! test/jdk/ProblemList.txt ! test/jdk/TEST.groups ! src/hotspot/share/opto/loopTransform.cpp ! src/hotspot/share/opto/phaseX.cpp ! src/hotspot/share/opto/phaseX.hpp ! src/hotspot/share/opto/subnode.cpp ! test/jdk/ProblemList.txt ! test/jdk/TEST.groups Changeset: da75de31 Author: Xiaolin Zheng Committer: Fei Yang Date: 2022-12-23 11:54:00 +0000 URL: https://git.openjdk.org/loom/commit/da75de31841e4b50477774e9efc4f554e1f3e4c0 8299172: RISC-V: [TESTBUG] Fix stack alignment logic in jvmci RISCV64TestAssembler.java Reviewed-by: fyang ! test/hotspot/jtreg/compiler/jvmci/jdk.vm.ci.code.test/src/jdk/vm/ci/code/test/riscv64/RISCV64TestAssembler.java Changeset: fd746a2f Author: Artem Semenov Date: 2022-12-23 22:07:14 +0000 URL: https://git.openjdk.org/loom/commit/fd746a2fe0e4c1c056065da93e2be2d8bb4e5428 8298643: JNI call of getAccessibleRowWithIndex and getAccessibleColumnWithIndex on a wrong thread Reviewed-by: serb, kizune ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/TableAccessibility.m Changeset: 5e861e39 Author: Artem Semenov Date: 2022-12-23 22:28:41 +0000 URL: https://git.openjdk.org/loom/commit/5e861e3965ce110889c8a1782ab0260937dee6ee 8298645: JNI works with accessibleSelection on a wrong thread Reviewed-by: serb, kizune ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CAccessibility.java ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ComboBoxAccessibility.m Changeset: 26868c1a Author: Toshio Nakamura Date: 2022-12-24 14:26:42 +0000 URL: https://git.openjdk.org/loom/commit/26868c1ac471c3b305b1d15e3075de0baa9319d2 8299255: Unexpected round errors in FreetypeFontScaler Reviewed-by: prr, serb ! src/java.desktop/share/native/libfontmanager/freetypeScaler.c + test/jdk/java/awt/FontClass/FontScalerRoundTest.java Changeset: 188911c9 Author: Daniel D. Daugherty Date: 2022-12-23 13:51:58 +0000 URL: https://git.openjdk.org/loom/commit/188911c925e4067c7f912c5ddb6f715bad7a3892 8299241: jdk/jfr/api/consumer/streaming/TestJVMCrash.java generates unnecessary core file Reviewed-by: coleenp ! test/jdk/jdk/jfr/api/consumer/streaming/TestJVMCrash.java ! test/jdk/jdk/jfr/api/consumer/streaming/TestProcess.java Changeset: 19373b2f Author: Jesper Wilhelmsson Date: 2022-12-25 01:56:28 +0000 URL: https://git.openjdk.org/loom/commit/19373b2ff0cd795afa262c17dcb3388fd6a5be59 Merge Changeset: 04591595 Author: Yi Yang Date: 2022-12-26 02:16:06 +0000 URL: https://git.openjdk.org/loom/commit/04591595374e84cfbfe38d92bff4409105b28009 8288204: GVN Crash: assert() failed: correct memory chain Reviewed-by: kvn, thartmann ! src/hotspot/share/opto/cfgnode.cpp ! src/hotspot/share/opto/memnode.cpp + test/hotspot/jtreg/compiler/c2/TestGVNCrash.java Changeset: 11fd651a Author: Alan Bateman Date: 2022-12-27 07:51:04 +0000 URL: https://git.openjdk.org/loom/commit/11fd651ab1820770e3c65cd49589416098987a87 8298875: A module requiring "java.base" with flags ACC_SYNTHETIC should be rejected Reviewed-by: jpai, mchung ! src/java.base/share/classes/jdk/internal/module/ModuleInfo.java ! test/jdk/java/lang/module/ModuleDescriptorTest.java Changeset: d490f15e Author: Matthias Baesken Date: 2022-12-28 08:28:02 +0000 URL: https://git.openjdk.org/loom/commit/d490f15e3b8222d0ba80e2161cc3f063092fc460 8235297: sun/security/ssl/SSLSessionImpl/ResumptionUpdateBoundValues.java fails intermittent Reviewed-by: xuelei ! test/jdk/sun/security/ssl/SSLSessionImpl/ResumptionUpdateBoundValues.java Changeset: 6f85a9c9 Author: Matthias Baesken Date: 2022-12-28 14:22:43 +0000 URL: https://git.openjdk.org/loom/commit/6f85a9c9a8ea3f76575acb4964cd80219822f073 8299387: CompressedClassPointers.java still fails on ppc with 'Narrow klass shift: 0' missing Reviewed-by: mdoerr ! test/hotspot/jtreg/runtime/CompressedOops/CompressedClassPointers.java Changeset: 684e5069 Author: Daniel Jeli?ski Date: 2022-12-30 06:40:27 +0000 URL: https://git.openjdk.org/loom/commit/684e50690c54fb93cb411553a8798cce041faac9 8299260: libawt and libfreetype should export only explicitly requested symbols Reviewed-by: prr, aivanov, serb ! make/common/modules/LibCommon.gmk ! make/modules/java.desktop/lib/Awt2dLibraries.gmk Changeset: c2e3d728 Author: Matthias Baesken Date: 2022-12-30 07:43:32 +0000 URL: https://git.openjdk.org/loom/commit/c2e3d7284814cd6b49f44b4de18e0f92310422b0 8299388: java/util/regex/NegativeArraySize.java fails on Alpine and sometimes Windows Reviewed-by: mdoerr, alanb ! test/jdk/java/util/regex/NegativeArraySize.java Changeset: 2ee34f14 Author: Abhishek Kumar Committer: Jayathirth D V Date: 2023-01-02 06:03:12 +0000 URL: https://git.openjdk.org/loom/commit/2ee34f14880cccca02e2933f80b000979f33c6d1 4912623: GTK L&F: Folder list of the JFileChooser is allowing multiple selection unlike native Reviewed-by: psadhukhan, jdv, serb ! src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKFileChooserUI.java + test/jdk/com/sun/java/swing/plaf/gtk/TestFileChooserCtrlASelection.java Changeset: 18ff1f5a Author: Prasanta Sadhukhan Date: 2023-01-02 09:49:51 +0000 URL: https://git.openjdk.org/loom/commit/18ff1f5a055deb29f56f16e0fb6bbe3f5c7e4169 6257207: JTable.getDefaultEditor throws NullPointerException Reviewed-by: tr, dnguyen, aivanov, serb ! src/java.desktop/share/classes/javax/swing/JTable.java + test/jdk/javax/swing/JTable/JTableEditorNPE.java Changeset: 95d4db3a Author: Matthias Baesken Date: 2023-01-02 11:16:18 +0000 URL: https://git.openjdk.org/loom/commit/95d4db3a92228d0211fa369c7d12d54234b22f72 8299424: containers/docker/TestMemoryWithCgroupV1.java fails on SLES12 ppc64le when testing Memory and Swap Limit Reviewed-by: mdoerr ! test/hotspot/jtreg/containers/docker/TestMemoryWithCgroupV1.java Changeset: d8120228 Author: Justin King Committer: Thomas Schatzl Date: 2023-01-02 12:00:39 +0000 URL: https://git.openjdk.org/loom/commit/d812022890815c33031905e7ec489b8729a45d90 8299398: Remove metaprogramming/isConst.hpp Reviewed-by: kbarrett, iwalulya, tschatzl ! src/hotspot/share/gc/shared/oopStorage.inline.hpp - src/hotspot/share/metaprogramming/isConst.hpp - test/hotspot/gtest/metaprogramming/test_isConst.cpp Changeset: 0532045e Author: Jorn Vernee Date: 2023-01-02 12:06:26 +0000 URL: https://git.openjdk.org/loom/commit/0532045edb709a995a42c07d95cb1cbabe886bed 8298590: Refactor LambdaForm constructors Reviewed-by: redestad ! src/java.base/share/classes/java/lang/invoke/DelegatingMethodHandle.java ! src/java.base/share/classes/java/lang/invoke/DirectMethodHandle.java ! src/java.base/share/classes/java/lang/invoke/Invokers.java ! src/java.base/share/classes/java/lang/invoke/LambdaForm.java ! src/java.base/share/classes/java/lang/invoke/LambdaFormBuffer.java ! src/java.base/share/classes/java/lang/invoke/LambdaFormEditor.java ! src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/java.base/share/classes/java/lang/invoke/NativeMethodHandle.java Changeset: e09e2431 Author: Per Minborg Committer: Jaikiran Pai Date: 2023-01-02 13:22:19 +0000 URL: https://git.openjdk.org/loom/commit/e09e243116545a7c1324bfcc145c94fbc25c7d59 8299187: (bf) ByteOrder.name should be declared final Reviewed-by: jpai ! src/java.base/share/classes/java/nio/ByteOrder.java Changeset: 8a10eef4 Author: Per Minborg Committer: Jaikiran Pai Date: 2023-01-02 13:25:04 +0000 URL: https://git.openjdk.org/loom/commit/8a10eef408f10d1a6d698a6f74942111b72d0765 8299193: (bf) Buffer.capacity should be declared final Reviewed-by: rriggs, dholmes, jpai ! src/java.base/share/classes/java/nio/Buffer.java Changeset: c252a85f Author: Albert Mingkun Yang Date: 2023-01-02 14:01:34 +0000 URL: https://git.openjdk.org/loom/commit/c252a85fb0c291f3eef8f049a2ca7d0c51d2e0d1 8298652: G1: Refactor G1MarkAndPushClosure Reviewed-by: iwalulya, tschatzl ! src/hotspot/share/gc/g1/g1FullGCMarker.cpp ! src/hotspot/share/gc/g1/g1FullGCMarker.hpp ! src/hotspot/share/gc/g1/g1FullGCMarker.inline.hpp ! src/hotspot/share/gc/g1/g1FullGCOopClosures.hpp ! src/hotspot/share/gc/g1/g1FullGCOopClosures.inline.hpp Changeset: 9d3d0399 Author: Justin King Committer: Thomas Schatzl Date: 2023-01-02 14:16:26 +0000 URL: https://git.openjdk.org/loom/commit/9d3d03997e9eb283bd58c8ea740e62689334966a 8299402: Remove metaprogramming/isVolatile.hpp Reviewed-by: kbarrett, iwalulya, tschatzl - src/hotspot/share/metaprogramming/isVolatile.hpp ! src/hotspot/share/oops/accessBackend.hpp - test/hotspot/gtest/metaprogramming/test_isVolatile.cpp Changeset: 532ccdb6 Author: Justin King Committer: Thomas Schatzl Date: 2023-01-02 14:33:44 +0000 URL: https://git.openjdk.org/loom/commit/532ccdb61a4b7dce9ad1141cef78c4f6be8d2f5a 8299396: Remove metaprogramming/removeExtent.hpp Reviewed-by: kbarrett, iwalulya, tschatzl ! src/hotspot/share/gc/z/zSafeDelete.hpp - src/hotspot/share/metaprogramming/removeExtent.hpp - test/hotspot/gtest/metaprogramming/test_removeExtent.cpp Changeset: 71a64a1b Author: Justin King Committer: Thomas Schatzl Date: 2023-01-02 14:34:44 +0000 URL: https://git.openjdk.org/loom/commit/71a64a1b7afea4d214f4fe8f0c0085aa959b6d09 8299399: Remove metaprogramming/isArray.hpp Reviewed-by: kbarrett, iwalulya, tschatzl ! src/hotspot/share/gc/z/zSafeDelete.inline.hpp - src/hotspot/share/metaprogramming/isArray.hpp - test/hotspot/gtest/metaprogramming/test_isArray.cpp Changeset: ce6395a1 Author: Justin King Committer: Thomas Schatzl Date: 2023-01-02 14:36:01 +0000 URL: https://git.openjdk.org/loom/commit/ce6395a1356a3d1334aeffc70ac8e4f86dd81a4c 8299397: Remove metaprogramming/isFloatingPoint.hpp Reviewed-by: kbarrett, iwalulya, tschatzl - src/hotspot/share/metaprogramming/isFloatingPoint.hpp ! src/hotspot/share/oops/accessBackend.hpp - test/hotspot/gtest/metaprogramming/test_isFloatingPoint.cpp Changeset: 67086ebf Author: Albert Mingkun Yang Date: 2023-01-02 14:59:11 +0000 URL: https://git.openjdk.org/loom/commit/67086ebf80109a623f3c2ad24d4e1a65de43d986 8299030: Refactor ReservedSpace::reserve Reviewed-by: dholmes, tschatzl ! src/hotspot/share/memory/virtualspace.cpp Changeset: 5b5552ff Author: David Holmes Date: 2023-01-02 23:34:20 +0000 URL: https://git.openjdk.org/loom/commit/5b5552ff2a5fccaa9a34886d9df4c0075fc8f5e8 8299483: ProblemList java/text/Format/NumberFormat/CurrencyFormat.java Reviewed-by: lancea ! test/jdk/ProblemList.txt Changeset: 417d01ea Author: Jaikiran Pai Date: 2023-01-03 01:58:49 +0000 URL: https://git.openjdk.org/loom/commit/417d01ea63261afb4fb29b4d11de799f2c0846d7 8299441: Fix typos in some test files under core-libs component Co-authored-by: Michael Ernst Reviewed-by: lancea ! test/jdk/javax/script/GetInterfaceTest.java ! test/jdk/javax/sql/testng/test/rowset/cachedrowset/CommonCachedRowSetTests.java ! test/jdk/javax/sql/testng/test/rowset/serial/SerialDataLinkTests.java ! test/micro/org/openjdk/bench/java/lang/ArrayFiddle.java Changeset: 37574333 Author: David Holmes Date: 2023-01-03 04:22:51 +0000 URL: https://git.openjdk.org/loom/commit/375743336dc15f9f945a03422eaa7ff773622cd8 8295974: jni_FatalError and Xcheck:jni warnings should print the native stack when there are no Java frames Reviewed-by: coleenp, rehn, sspitsyn ! make/test/JtregNativeHotspot.gmk ! src/hotspot/share/runtime/javaThread.cpp ! src/hotspot/share/runtime/javaThread.hpp ! src/hotspot/share/utilities/vmError.hpp + test/hotspot/jtreg/runtime/jni/nativeStack/TestNativeStack.java + test/hotspot/jtreg/runtime/jni/nativeStack/libnativeStack.c Changeset: 8afd665b Author: Justin King Committer: Thomas Schatzl Date: 2023-01-03 09:13:49 +0000 URL: https://git.openjdk.org/loom/commit/8afd665bf911ed9dc5d7c1f61f488ebe2f7b3cae 8299395: Remove metaprogramming/removeCV.hpp Reviewed-by: kbarrett, tschatzl ! src/hotspot/share/metaprogramming/decay.hpp ! src/hotspot/share/metaprogramming/isIntegral.hpp ! src/hotspot/share/metaprogramming/isSigned.hpp - src/hotspot/share/metaprogramming/removeCV.hpp ! src/hotspot/share/runtime/atomic.hpp - test/hotspot/gtest/metaprogramming/test_removeCV.cpp Changeset: a9ce7726 Author: Per Minborg Committer: Jaikiran Pai Date: 2023-01-03 10:00:19 +0000 URL: https://git.openjdk.org/loom/commit/a9ce7726a722c9deba659dff3f87b7e72d6c4997 8299437: Make InetSocketAddressHolder shallowly immutable Reviewed-by: djelinski, jpai, alanb ! src/java.base/share/classes/java/net/InetSocketAddress.java Changeset: 245f0cf4 Author: Aleksei Voitylov Committer: Martin Doerr Date: 2023-01-03 12:02:39 +0000 URL: https://git.openjdk.org/loom/commit/245f0cf4ac9dc655bfe2abb1c88c6ed1ddffd291 8291302: ARM32: nmethod entry barriers support Reviewed-by: eosterlund, rrich, mdoerr, aph ! src/hotspot/cpu/arm/arm.ad ! src/hotspot/cpu/arm/c1_MacroAssembler_arm.cpp ! src/hotspot/cpu/arm/gc/shared/barrierSetAssembler_arm.cpp ! src/hotspot/cpu/arm/gc/shared/barrierSetAssembler_arm.hpp ! src/hotspot/cpu/arm/gc/shared/barrierSetNMethod_arm.cpp ! src/hotspot/cpu/arm/macroAssembler_arm.hpp ! src/hotspot/cpu/arm/nativeInst_arm_32.hpp ! src/hotspot/cpu/arm/sharedRuntime_arm.cpp ! src/hotspot/cpu/arm/stubGenerator_arm.cpp ! src/hotspot/cpu/arm/stubRoutines_arm.cpp ! src/hotspot/cpu/arm/stubRoutines_arm.hpp ! src/hotspot/share/gc/shared/barrierSet.cpp Changeset: 37f8b059 Author: Jamil Nimeh Date: 2022-12-29 22:34:53 +0000 URL: https://git.openjdk.org/loom/commit/37f8b059c1c9245e7f3af90d6ed47c862fee54a3 8298592: Add java man page documentation for ChaCha20 and Poly1305 intrinsics Reviewed-by: weijun ! src/java.base/share/man/java.1 Changeset: a6a903d4 Author: Tobias Hartmann Date: 2023-01-03 08:21:22 +0000 URL: https://git.openjdk.org/loom/commit/a6a903d4b627bde85a311336ce25a7f5e25cf664 8288204: GVN Crash: assert() failed: correct memory chain Backport-of: 04591595374e84cfbfe38d92bff4409105b28009 ! src/hotspot/share/opto/cfgnode.cpp ! src/hotspot/share/opto/memnode.cpp + test/hotspot/jtreg/compiler/c2/TestGVNCrash.java Changeset: 3d0db02c Author: Jesper Wilhelmsson Date: 2023-01-03 13:10:15 +0000 URL: https://git.openjdk.org/loom/commit/3d0db02c76b91bfd0826ca27b1722b701b29d4d0 Merge ! src/java.base/share/man/java.1 ! src/java.base/share/man/java.1 Changeset: 92dfc735 Author: Ryan Wallace Committer: Weijun Wang Date: 2023-01-03 13:52:47 +0000 URL: https://git.openjdk.org/loom/commit/92dfc735f2297441a99b3e39464fb8f77a354d55 8294526: sun/security/provider/SubjectCodeSource.java no longer referenced Reviewed-by: weijun, xuelei - src/java.base/share/classes/sun/security/provider/SubjectCodeSource.java - test/jdk/sun/security/provider/PolicyFile/Comparator.Combined.Policy - test/jdk/sun/security/provider/PolicyFile/Comparator.Comparator.Policy - test/jdk/sun/security/provider/PolicyFile/Comparator.Principal.Policy - test/jdk/sun/security/provider/PolicyFile/Comparator.java Changeset: ea25a561 Author: Matthias Baesken Date: 2023-01-03 15:26:10 +0000 URL: https://git.openjdk.org/loom/commit/ea25a561c57cba63c5581aefa21f92ffd7386244 8299520: TestPrintXML.java output error messages in case compare fails Reviewed-by: mgronlun ! test/jdk/jdk/jfr/tool/TestPrintXML.java Changeset: 38cfc591 Author: Xue-Lei Andrew Fan Date: 2023-01-03 22:44:14 +0000 URL: https://git.openjdk.org/loom/commit/38cfc591725de478879266584280562f0ba4b42f 8299378: sprintf is deprecated in Xcode 14 Reviewed-by: kbarrett, dholmes ! test/hotspot/gtest/logging/test_logDecorators.cpp ! test/hotspot/gtest/logging/test_logMessageTest.cpp ! test/hotspot/gtest/utilities/test_unsigned5.cpp Changeset: 77ff1977 Author: Prasanta Sadhukhan Date: 2023-01-04 03:26:32 +0000 URL: https://git.openjdk.org/loom/commit/77ff19774651f1c41bbb1e59b2873d74522c8666 7030853: JDK 7 Serializable Swing classes not compatible with JDK 6 Reviewed-by: serb, aivanov ! src/java.desktop/share/classes/javax/swing/LayoutComparator.java ! src/java.desktop/share/classes/javax/swing/package-info.java ! src/java.desktop/share/classes/javax/swing/text/html/parser/ParserDelegator.java Changeset: 82deb5ca Author: Ioi Lam Date: 2023-01-04 04:03:43 +0000 URL: https://git.openjdk.org/loom/commit/82deb5ca615f70634f8cd84836265d01edd1c5a5 8298601: Refactor archiving of java.lang.Module objects Reviewed-by: coleenp, ccheung ! src/hotspot/share/cds/heapShared.cpp ! src/hotspot/share/cds/heapShared.hpp ! src/hotspot/share/classfile/classLoaderDataShared.cpp ! src/hotspot/share/classfile/classLoaderDataShared.hpp ! src/hotspot/share/classfile/moduleEntry.cpp ! src/hotspot/share/classfile/moduleEntry.hpp ! src/hotspot/share/classfile/modules.cpp ! src/hotspot/share/classfile/modules.hpp Changeset: 41900b57 Author: Daniel Jeli?ski Date: 2023-01-04 13:17:29 +0000 URL: https://git.openjdk.org/loom/commit/41900b57af084e0cfc1453681b24fe5606e11ab2 8189338: JMX RMI Remote Mbean server connection hangs if the server stops responding during a SSL Handshake Reviewed-by: smarks ! src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java ! test/jdk/java/rmi/transport/handshakeTimeout/HandshakeTimeout.java Changeset: e3035bad Author: Erik ?sterlund Date: 2023-01-04 14:31:07 +0000 URL: https://git.openjdk.org/loom/commit/e3035bad60dfa71e9c24fcc509cd7f07eb2bf62e 8299079: Better interface nmethod oop accesses Co-authored-by: Axel Boldt-Christmas Reviewed-by: kvn, dholmes ! src/hotspot/share/code/nmethod.cpp ! src/hotspot/share/oops/access.hpp ! src/hotspot/share/oops/accessDecorators.hpp Changeset: ccbcea83 Author: Coleen Phillimore Date: 2023-01-04 14:42:15 +0000 URL: https://git.openjdk.org/loom/commit/ccbcea830dc8d8b99c919d491adc60f7b4e8f28d 8299326: LinkResolver::resolve_field resolved_klass cannot be null Reviewed-by: iklam, fparain ! src/hotspot/share/interpreter/linkResolver.cpp ! src/hotspot/share/interpreter/linkResolver.hpp Changeset: c32a34c2 Author: Erik ?sterlund Date: 2023-01-04 14:49:44 +0000 URL: https://git.openjdk.org/loom/commit/c32a34c2e534147bccf8320b095edda9e1088f5a 8299072: java_lang_ref_Reference::clear_referent should be GC agnostic Co-authored-by: Axel Boldt-Christmas Reviewed-by: dholmes, shade, kbarrett ! src/hotspot/share/classfile/javaClasses.hpp ! src/hotspot/share/classfile/javaClasses.inline.hpp ! src/hotspot/share/gc/shared/referenceProcessor.cpp ! src/hotspot/share/gc/shenandoah/shenandoahReferenceProcessor.cpp ! src/hotspot/share/gc/z/zReferenceProcessor.cpp Changeset: c6588d5b Author: Yi-Fan Tsai Committer: Ludovic Henry Date: 2023-01-04 14:51:25 +0000 URL: https://git.openjdk.org/loom/commit/c6588d5bb3f778806c9112e86dbfba964c0636fd 8299158: Improve MD5 intrinsic on AArch64 Reviewed-by: luhenry, haosun, aph ! src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp Changeset: 4c0f24ef Author: Archie L. Cobbs Committer: Vicente Romero Date: 2023-01-04 16:00:22 +0000 URL: https://git.openjdk.org/loom/commit/4c0f24ef7108c889afdd4443d07e58c1798633cc 8064931: tools/javac/scope/DupUnsharedTest.java needs to be updated to add the bug id Reviewed-by: vromero ! test/langtools/tools/javac/scope/DupUnsharedTest.java Changeset: 6a07fd0e Author: Archie L. Cobbs Committer: Vicente Romero Date: 2023-01-04 16:01:59 +0000 URL: https://git.openjdk.org/loom/commit/6a07fd0ec1e6b57ffff852bcdc4f3304ac828018 8155259: Suspicious buffer allocation in com.sun.tools.javac.file.BaseFileManager 8172106: javac throws exception when compiling source file of size 1.5G Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/BaseFileManager.java Changeset: 3eb85d19 Author: Mark Powers Committer: Sean Mullan Date: 2023-01-03 15:41:55 +0000 URL: https://git.openjdk.org/loom/commit/3eb85d19ec80105bcbc5ad5422d694c29a9029d2 8299235: broken link referencing missing id Reviewed-by: mullan ! src/java.base/share/classes/java/security/KeyStore.java ! src/java.base/share/classes/javax/crypto/Cipher.java Changeset: 031829d8 Author: Erik Joelsson Date: 2023-01-03 21:07:19 +0000 URL: https://git.openjdk.org/loom/commit/031829d8854f2eae5f04d74bca515d58aab801ef 8298324: Unable to run shell test with make Reviewed-by: dholmes ! make/RunTests.gmk Changeset: 8254cbb2 Author: David Holmes Date: 2023-01-03 21:22:16 +0000 URL: https://git.openjdk.org/loom/commit/8254cbb21d164f39aa12020bfbd555d7535a428e 8299483: ProblemList java/text/Format/NumberFormat/CurrencyFormat.java Backport-of: 5b5552ff2a5fccaa9a34886d9df4c0075fc8f5e8 ! test/jdk/ProblemList.txt Changeset: b743519b Author: Kim Barrett Date: 2023-01-04 03:28:31 +0000 URL: https://git.openjdk.org/loom/commit/b743519ba911a254669fa8a96e6006c14e3f5ad1 8293824: gc/whitebox/TestConcMarkCycleWB.java failed "RuntimeException: assertTrue: expected true, was false" Reviewed-by: iwalulya, tschatzl ! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp ! src/hotspot/share/gc/g1/g1ConcurrentMark.hpp ! src/hotspot/share/gc/g1/g1ConcurrentMarkThread.cpp ! src/hotspot/share/prims/whitebox.cpp ! test/hotspot/jtreg/gc/g1/TestGCLogMessages.java ! test/hotspot/jtreg/gc/g1/TestHumongousRemsetsMatch.java ! test/hotspot/jtreg/gc/g1/TestMixedGCLiveThreshold.java ! test/hotspot/jtreg/gc/g1/TestNoEagerReclaimOfHumongousRegions.java ! test/hotspot/jtreg/gc/g1/TestRegionLivenessPrint.java ! test/hotspot/jtreg/gc/g1/TestRemarkCleanupMXBean.java ! test/hotspot/jtreg/gc/g1/TestSkipRebuildRemsetPhase.java ! test/hotspot/jtreg/gc/g1/TestVerifyGCType.java ! test/hotspot/jtreg/gc/g1/humongousObjects/TestHumongousClassLoader.java ! test/hotspot/jtreg/gc/g1/humongousObjects/TestObjectCollected.java ! test/hotspot/jtreg/gc/g1/humongousObjects/objectGraphTest/GC.java ! test/hotspot/jtreg/gc/g1/humongousObjects/objectGraphTest/GCTokens.java ! test/hotspot/jtreg/gc/stress/TestMultiThreadStressRSet.java ! test/hotspot/jtreg/gc/stress/TestStressRSetCoarsening.java ! test/hotspot/jtreg/gc/testlibrary/g1/MixedGCProvoker.java - test/hotspot/jtreg/gc/whitebox/TestConcMarkCycleWB.java ! test/hotspot/jtreg/runtime/ClassUnload/UnloadTestWithVerifyDuringGC.java ! test/jdk/com/sun/management/GarbageCollectorMXBean/GarbageCollectionNotificationContentTest.java ! test/jdk/com/sun/management/GarbageCollectorMXBean/GarbageCollectionNotificationTest.java ! test/lib/jdk/test/whitebox/WhiteBox.java Changeset: a17f505d Author: Aleksey Shipilev Date: 2023-01-04 10:46:34 +0000 URL: https://git.openjdk.org/loom/commit/a17f505d7351b0031d17c3ce8df3723b121a301e 8299476: PPC64 Zero build fails after JDK-8286302 Reviewed-by: mdoerr ! src/hotspot/share/runtime/continuationFreezeThaw.cpp Changeset: df1caf90 Author: Jesper Wilhelmsson Date: 2023-01-04 16:03:09 +0000 URL: https://git.openjdk.org/loom/commit/df1caf90818558b897a6b8ab80757f2a03398c55 Merge ! src/hotspot/share/prims/whitebox.cpp ! src/hotspot/share/runtime/continuationFreezeThaw.cpp ! test/hotspot/jtreg/gc/g1/TestGCLogMessages.java ! test/hotspot/jtreg/gc/g1/TestVerifyGCType.java ! src/hotspot/share/prims/whitebox.cpp ! src/hotspot/share/runtime/continuationFreezeThaw.cpp ! test/hotspot/jtreg/gc/g1/TestGCLogMessages.java ! test/hotspot/jtreg/gc/g1/TestVerifyGCType.java Changeset: b9758d22 Author: Archie L. Cobbs Committer: Vicente Romero Date: 2023-01-04 17:32:33 +0000 URL: https://git.openjdk.org/loom/commit/b9758d2201655cecfdda48660e77c598c52fcd9b 8200610: Compiling fails with java.nio.file.ReadOnlyFileSystemException Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java Changeset: 44be5edf Author: Archie L. Cobbs Committer: Vicente Romero Date: 2023-01-04 17:50:32 +0000 URL: https://git.openjdk.org/loom/commit/44be5edf5aa661169c665aa9386e5930a3632524 8219810: javac throws NullPointerException Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties + test/langtools/tools/javac/classreader/8219810/BadFieldFlags.jcod + test/langtools/tools/javac/classreader/8219810/BadFieldFlagsTest.java + test/langtools/tools/javac/classreader/8219810/BadFieldFlagsTest.out + test/langtools/tools/javac/classreader/8219810/BadMethodFlags.jcod + test/langtools/tools/javac/classreader/8219810/BadMethodFlagsTest.java + test/langtools/tools/javac/classreader/8219810/BadMethodFlagsTest.out ! test/langtools/tools/javac/diags/examples.not-yet.txt Changeset: 7dcc6899 Author: Michael Ernst Committer: Alexey Ivanov Date: 2023-01-04 19:59:45 +0000 URL: https://git.openjdk.org/loom/commit/7dcc689932ea276586282e0917f2efc10a598eb7 8299563: Fix typos Reviewed-by: lancea, aivanov, sspitsyn ! test/jaxp/javax/xml/jaxp/unittest/stream/XMLStreamReaderTest/XMLSchema.xsd ! test/jdk/javax/xml/jaxp/testng/parse/XMLEntityScannerLoad.java ! test/jdk/sun/jvmstat/testlibrary/utils.sh ! test/jdk/sun/management/jmxremote/bootstrap/JMXInterfaceBindingTest.java ! test/jdk/sun/misc/SunMiscSignalTest.java Changeset: 3b374c01 Author: Justin Lu Committer: Naoto Sato Date: 2023-01-04 21:59:02 +0000 URL: https://git.openjdk.org/loom/commit/3b374c0153950ab193f3a188b57d3404b4ce2fe2 8299439: java/text/Format/NumberFormat/CurrencyFormat.java fails for hr_HR Reviewed-by: naoto, lancea, jpai ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_hr_HR.properties ! test/jdk/ProblemList.txt ! test/jdk/java/text/Format/NumberFormat/CurrencySymbols.properties Changeset: 569ce64f Author: Alan Bateman Date: 2023-01-05 19:33:12 +0000 URL: https://git.openjdk.org/loom/commit/569ce64fd2a5065f57c92c2b9c9d4b67a0cebcd7 Merge with jdk-21+4 ! make/RunTests.gmk ! src/hotspot/share/runtime/continuation.cpp ! src/hotspot/share/runtime/globals.hpp ! test/hotspot/jtreg/ProblemList.txt ! make/RunTests.gmk ! src/hotspot/share/runtime/continuation.cpp ! src/hotspot/share/runtime/globals.hpp ! test/hotspot/jtreg/ProblemList.txt Changeset: 784e892a Author: Alan Bateman Date: 2023-01-05 19:33:33 +0000 URL: https://git.openjdk.org/loom/commit/784e892a59f2fe556c3c3fecb03fb8825dc61b08 Merge Changeset: a12222f9 Author: Alan Bateman Date: 2023-01-06 07:58:49 +0000 URL: https://git.openjdk.org/loom/commit/a12222f9919b3f8c656ee00f410d040ed558e24c Restore ProblemList.txt ! test/jdk/ProblemList.txt From duke at openjdk.org Fri Jan 6 09:36:02 2023 From: duke at openjdk.org (duke) Date: Fri, 6 Jan 2023 09:36:02 GMT Subject: git: openjdk/loom: master: 189 new changesets Message-ID: <5a97f9bc-ff71-4eb1-9dd9-090a3efc2e26@openjdk.org> Changeset: ccb94acc Author: Chris Plummer Date: 2022-12-14 19:37:20 +0000 URL: https://git.openjdk.org/loom/commit/ccb94acc442767a7047756806c8dc7ecacd8bae9 8287812: Cleanup JDWP agent GetEnv initialization Reviewed-by: alanb, sspitsyn ! src/jdk.jdwp.agent/share/native/libjdwp/debugInit.c ! src/jdk.jdwp.agent/share/native/libjdwp/util.c Changeset: bf78f716 Author: Brent Christian Date: 2022-12-13 19:07:44 +0000 URL: https://git.openjdk.org/loom/commit/bf78f716bd3e58df24ff1e6f4a0104025379f821 8295857: Clarify that cleanup code can be skipped when the JVM terminates (e.g. when calling halt()) Reviewed-by: iris Backport-of: c7aca73177339f931f7dfb6627365548a32874f7 ! src/java.base/share/classes/java/lang/Runtime.java Changeset: c6f22b41 Author: Joe Darcy Date: 2022-12-13 20:48:13 +0000 URL: https://git.openjdk.org/loom/commit/c6f22b416072a9be5436f45e2f595ceea228f3bd 8297305: Clarify that javax.lang.model.util.Elements.overrides is irreflexive Reviewed-by: jjg ! src/java.compiler/share/classes/javax/lang/model/util/Elements.java Changeset: 61ab16f7 Author: Jonathan Gibbons Date: 2022-12-13 23:20:43 +0000 URL: https://git.openjdk.org/loom/commit/61ab16f79a735a98b3c095daf1b541f4fc5413c0 8298700: Typo in DocTree comment Reviewed-by: darcy ! src/jdk.compiler/share/classes/com/sun/source/doctree/DocTree.java Changeset: 51f0a1ce Author: Christoph Langer Date: 2022-12-14 07:32:28 +0000 URL: https://git.openjdk.org/loom/commit/51f0a1ce4b0d72cf7e82e01f7014274d8b7d1575 8298527: Cygwin's uname -m returns different string than before Reviewed-by: erikj ! make/autoconf/build-aux/config.guess Changeset: 27d49711 Author: Roland Westrelin Date: 2022-12-14 10:03:36 +0000 URL: https://git.openjdk.org/loom/commit/27d4971182ab1cbe7e6bc40cd22c1c70661a3ab2 8298520: C2: assert(found_opaque == res) failed: wrong pattern Reviewed-by: thartmann, chagedorn ! src/hotspot/share/opto/loopnode.cpp ! src/hotspot/share/opto/loopnode.hpp Changeset: 9bcdfc42 Author: Jan Lahoda Date: 2022-12-14 11:36:04 +0000 URL: https://git.openjdk.org/loom/commit/9bcdfc428597e1465c8a014d816ef671420d22df 8298425: System.console().readLine() hangs in jshell Reviewed-by: naoto, alanb ! src/jdk.jshell/share/classes/jdk/jshell/execution/JdiDefaultExecutionControl.java + test/langtools/jdk/jshell/ConsoleTest.java Changeset: 0bbc4181 Author: Andrew Haley Date: 2022-12-14 13:32:21 +0000 URL: https://git.openjdk.org/loom/commit/0bbc4181cdbccfc3a542f306ce1902cc2e9f36cb 8294902: Undefined Behavior in C2 regalloc with null references Reviewed-by: kvn, vlivanov ! src/hotspot/share/memory/arena.cpp ! src/hotspot/share/opto/bytecodeInfo.cpp ! src/hotspot/share/opto/chaitin.hpp ! src/hotspot/share/opto/postaloc.cpp ! src/hotspot/share/runtime/vmStructs.hpp ! src/hotspot/share/utilities/globalDefinitions.hpp ! src/hotspot/share/utilities/globalDefinitions_gcc.hpp Changeset: 27917014 Author: Kim Barrett Date: 2022-12-14 13:36:36 +0000 URL: https://git.openjdk.org/loom/commit/279170147a10ec2da2242b4dcb3279c41c471000 8298296: gc/TestFullGCCount.java fails with "System.gc collections miscounted." Reviewed-by: tschatzl, ayang ! test/hotspot/jtreg/ProblemList.txt ! test/hotspot/jtreg/gc/TestFullGCCount.java Changeset: 0eeaf6b2 Author: Erik Gahlin Date: 2022-12-14 13:40:15 +0000 URL: https://git.openjdk.org/loom/commit/0eeaf6b219758563712d951b3c6ff160ebeff52d 8298649: JFR: RemoteRecordingStream support for checkpoint event sizes beyond u4 Reviewed-by: mgronlun ! src/jdk.management.jfr/share/classes/jdk/management/jfr/DiskRepository.java Changeset: 581f9f23 Author: Axel Boldt-Christmas Date: 2022-12-14 14:10:24 +0000 URL: https://git.openjdk.org/loom/commit/581f9f2306835680cd6d5dbbe37f610fb4de4677 8297235: ZGC: assert(regs[i] != regs[j]) failed: Multiple uses of register: rax Reviewed-by: thartmann, rcastanedalo Backport-of: 042b7062f19b313f31b228bd96d2a74cc1165ab9 ! src/hotspot/cpu/x86/gc/z/z_x86_64.ad ! test/jdk/ProblemList-zgc.txt Changeset: a130c8a6 Author: Jesper Wilhelmsson Date: 2022-12-14 21:47:29 +0000 URL: https://git.openjdk.org/loom/commit/a130c8a6688fcdda92e0f6295ec06f1591382328 Merge ! src/hotspot/share/opto/loopnode.cpp ! src/hotspot/share/utilities/globalDefinitions.hpp ! test/hotspot/jtreg/ProblemList.txt ! src/hotspot/share/opto/loopnode.cpp ! src/hotspot/share/utilities/globalDefinitions.hpp ! test/hotspot/jtreg/ProblemList.txt Changeset: 0ed6d0b4 Author: Alisen Chung Date: 2022-12-14 22:10:01 +0000 URL: https://git.openjdk.org/loom/commit/0ed6d0b456e58e4122b97c3d12faabada0d8c530 8297296: java/awt/Mouse/EnterExitEvents/DragWindowTest.java fails with "No MouseReleased event on label!" Reviewed-by: psadhukhan, dnguyen ! test/jdk/ProblemList.txt ! test/jdk/java/awt/Mouse/EnterExitEvents/DragWindowTest.java Changeset: 3ef38241 Author: Coleen Phillimore Date: 2022-12-14 23:08:32 +0000 URL: https://git.openjdk.org/loom/commit/3ef382416f5ff38cd44fa8d4e552f1935156e765 8298794: Remove JVM_ACC_PROMOTED_FLAGS breaks minimal build Reviewed-by: ayang, dcubed ! src/hotspot/share/oops/instanceKlassMiscStatus.cpp Changeset: d1085d1b Author: Matias Saavedra Silva Committer: Ioi Lam Date: 2022-12-15 05:03:57 +0000 URL: https://git.openjdk.org/loom/commit/d1085d1be7bc798ced8d539062fa7a9a3ab0341c 8281946: VM.native_memory should report size of shareable memory Reviewed-by: stuefe, iklam ! src/hotspot/share/cds/filemap.cpp ! src/hotspot/share/cds/filemap.hpp ! src/hotspot/share/services/memReporter.cpp ! test/hotspot/jtreg/runtime/NMT/SummarySanityCheck.java Changeset: ebc47104 Author: Per Minborg Committer: Maurizio Cimadamore Date: 2022-12-14 21:40:29 +0000 URL: https://git.openjdk.org/loom/commit/ebc471040e03dc41829d57e1280cabd75b2ad53a 8298277: Replace "session" with "scope" for FFM access Reviewed-by: mcimadamore ! src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java ! src/java.base/share/classes/jdk/internal/foreign/HeapMemorySegmentImpl.java ! src/java.base/share/classes/jdk/internal/foreign/MappedMemorySegmentImpl.java ! src/java.base/share/classes/jdk/internal/foreign/MemorySessionImpl.java ! src/java.base/share/classes/jdk/internal/foreign/NativeMemorySegmentImpl.java ! src/java.base/share/classes/jdk/internal/foreign/abi/Binding.java ! src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java ! src/java.base/share/classes/jdk/internal/foreign/abi/SharedUtils.java ! src/java.base/share/classes/jdk/internal/foreign/abi/UpcallLinker.java ! src/java.base/share/classes/jdk/internal/foreign/abi/UpcallStubs.java ! src/java.base/share/classes/jdk/internal/foreign/abi/aarch64/linux/LinuxAArch64Linker.java ! src/java.base/share/classes/jdk/internal/foreign/abi/aarch64/linux/LinuxAArch64VaList.java ! src/java.base/share/classes/jdk/internal/foreign/abi/aarch64/macos/MacOsAArch64Linker.java ! src/java.base/share/classes/jdk/internal/foreign/abi/x64/sysv/CallArranger.java ! src/java.base/share/classes/jdk/internal/foreign/abi/x64/sysv/SysVVaList.java ! src/java.base/share/classes/jdk/internal/foreign/abi/x64/sysv/SysVx64Linker.java ! src/java.base/share/classes/jdk/internal/foreign/abi/x64/windows/CallArranger.java ! src/java.base/share/classes/jdk/internal/foreign/abi/x64/windows/WinVaList.java ! src/java.base/share/classes/jdk/internal/foreign/abi/x64/windows/Windowsx64Linker.java Changeset: 80cadd40 Author: Kim Barrett Date: 2022-12-14 21:57:55 +0000 URL: https://git.openjdk.org/loom/commit/80cadd40103cf1f490a5d70be784652e27588114 8298785: gc/TestFullGCCount.java fails with "invalid boolean value: `null' for expression `vm.opt.ExplicitGCInvokesConcurrent'" Reviewed-by: dcubed ! test/hotspot/jtreg/gc/TestFullGCCount.java Changeset: 10bc86cc Author: Jesper Wilhelmsson Date: 2022-12-15 06:36:55 +0000 URL: https://git.openjdk.org/loom/commit/10bc86cc260fac48bf10f67dd56aa73c6954f026 Merge Changeset: b9074fa1 Author: Daniel Jeli?ski Date: 2022-12-15 06:54:33 +0000 URL: https://git.openjdk.org/loom/commit/b9074fa1ed489993d60ce873fd8105a95d30782a 8298249: Excessive memory allocation in CipherInputStream AEAD decryption Reviewed-by: ascarpino, valeriep ! src/java.base/share/classes/javax/crypto/CipherInputStream.java + test/micro/org/openjdk/bench/javax/crypto/full/AESGCMCipherInputStream.java Changeset: 3ae71872 Author: Daniel Jeli?ski Date: 2022-12-15 06:55:25 +0000 URL: https://git.openjdk.org/loom/commit/3ae718725a72cc2758331e932130d846cfba64e4 8298498: sun/net/www/http/KeepAliveCache/B8291637.java fails with "Server exception terminating: java.net.SocketException: Socket closed" Reviewed-by: dfuchs, jpai ! test/jdk/sun/net/www/http/KeepAliveCache/B8291637.java Changeset: 5f63f7a7 Author: Alan Bateman Date: 2022-12-15 07:14:02 +0000 URL: https://git.openjdk.org/loom/commit/5f63f7a742a1071a87ca69463bae6e04a44fe462 8298726: (fs) Change PollingWatchService to record last modified time as FileTime rather than milliseconds Reviewed-by: bpb, jpai ! src/java.base/share/classes/sun/nio/fs/PollingWatchService.java Changeset: 98fa48c3 Author: Matthias Baesken Date: 2022-12-15 08:11:09 +0000 URL: https://git.openjdk.org/loom/commit/98fa48c330941efe6588a907b383802a11ed0e6b 8298093: improve cleanup and error handling of awt_parseColorModel in awt_parseImage.c Reviewed-by: lucy, clanger ! src/java.desktop/share/native/libawt/awt/image/awt_parseImage.c Changeset: b17c5242 Author: Erik ?sterlund Date: 2022-12-15 09:26:13 +0000 URL: https://git.openjdk.org/loom/commit/b17c52422c91ad1e7ff35844676f6269a1b87f79 8298059: Linked stack watermarks don't support nesting Reviewed-by: stefank, sspitsyn, rehn, pchilanomate ! src/hotspot/share/runtime/keepStackGCProcessed.cpp ! src/hotspot/share/runtime/stackWatermark.cpp ! src/hotspot/share/runtime/stackWatermark.hpp ! test/hotspot/jtreg/ProblemList-zgc.txt Changeset: 0288210f Author: Alexander Zvegintsev Date: 2022-12-15 16:43:06 +0000 URL: https://git.openjdk.org/loom/commit/0288210f25e3d56870d1aa58ad076c97aad1c232 8298859: ProblemList java/awt/Mouse/EnterExitEvents/DragWindowTest.java on macosx-all Reviewed-by: jdv ! test/jdk/ProblemList.txt Changeset: 831b35fa Author: Brian Burkhalter Date: 2022-12-15 17:27:39 +0000 URL: https://git.openjdk.org/loom/commit/831b35fad352887717d5cc8f001ad822ac9a5c46 7093322: (fs spec) Files.newBufferedWriter should be clear when coding errors are detected Reviewed-by: alanb ! src/java.base/share/classes/java/nio/file/Files.java Changeset: 0ef35392 Author: Naoto Sato Date: 2022-12-15 19:20:12 +0000 URL: https://git.openjdk.org/loom/commit/0ef353925e645dd519e17aeb7a83e927271f8b95 8298416: Console should be declared `sealed` Reviewed-by: jpai, alanb ! src/java.base/share/classes/java/io/Console.java + src/java.base/share/classes/java/io/ConsoleImpl.java ! src/java.base/unix/native/libjava/Console_md.c Changeset: ae8988e8 Author: Julian Waters Committer: Vladimir Kozlov Date: 2022-12-15 19:38:39 +0000 URL: https://git.openjdk.org/loom/commit/ae8988e834032d9d6a4b644c3ebf9ee1957c9522 8297912: HotSpot Style Guide should permit alignas (Second Proposal Attempt) Reviewed-by: kbarrett, stuefe, kvn ! doc/hotspot-style.html ! doc/hotspot-style.md Changeset: 4b313b51 Author: Matthew Donovan Committer: Rajan Halade Date: 2022-12-15 19:48:35 +0000 URL: https://git.openjdk.org/loom/commit/4b313b51b1787113961c289a41708e31fa19cacc 8297798: Timeout with DTLSOverDatagram test template Reviewed-by: jnimeh, rhalade ! test/jdk/ProblemList.txt ! test/jdk/javax/net/ssl/DTLS/DTLSOverDatagram.java ! test/jdk/javax/net/ssl/DTLS/InvalidRecords.java Changeset: 10737e16 Author: Coleen Phillimore Date: 2022-12-15 19:54:25 +0000 URL: https://git.openjdk.org/loom/commit/10737e168c967a08e257927251861bf2c14795ab 8298468: Clean up class_loader parameters Reviewed-by: dholmes, iklam ! src/hotspot/share/cds/cdsProtectionDomain.cpp ! src/hotspot/share/classfile/loaderConstraints.cpp ! src/hotspot/share/classfile/loaderConstraints.hpp ! src/hotspot/share/classfile/systemDictionary.cpp ! src/hotspot/share/classfile/systemDictionary.hpp Changeset: 3cdbd878 Author: David Holmes Date: 2022-12-15 21:15:34 +0000 URL: https://git.openjdk.org/loom/commit/3cdbd878e68dc1131093137a7357710ad303ae8c 8298241: Replace C-style casts with JavaThread::cast Reviewed-by: coleenp, stefank, sspitsyn ! src/hotspot/cpu/aarch64/frame_aarch64.cpp ! src/hotspot/os/posix/signals_posix.cpp ! src/hotspot/os_cpu/bsd_aarch64/javaThread_bsd_aarch64.cpp ! src/hotspot/os_cpu/windows_aarch64/javaThread_windows_aarch64.cpp ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/jvmci/jvmci.cpp ! src/hotspot/share/jvmci/jvmciRuntime.cpp ! src/hotspot/share/oops/instanceStackChunkKlass.cpp ! src/hotspot/share/oops/stackChunkOop.inline.hpp ! src/hotspot/share/prims/jvmtiEnv.cpp ! src/hotspot/share/prims/jvmtiEnvBase.cpp ! src/hotspot/share/prims/jvmtiImpl.cpp ! src/hotspot/share/prims/scopedMemoryAccess.cpp ! src/hotspot/share/runtime/continuation.cpp ! src/hotspot/share/runtime/continuationFreezeThaw.cpp ! src/hotspot/share/runtime/frame.cpp ! src/hotspot/share/runtime/javaThread.hpp ! src/hotspot/share/runtime/objectMonitor.cpp ! src/hotspot/share/runtime/synchronizer.cpp Changeset: 54124394 Author: Brian Burkhalter Date: 2022-12-15 22:47:29 +0000 URL: https://git.openjdk.org/loom/commit/5412439445fadcf66101018a9bd051f8e5d751e8 8298187: (fs) BsdFileAttributeViews::setTimes does not support lastAccessTime on HFS+ Reviewed-by: alanb ! src/java.base/macosx/classes/sun/nio/fs/BsdFileAttributeViews.java ! src/java.base/macosx/classes/sun/nio/fs/BsdNativeDispatcher.java ! src/java.base/macosx/native/libnio/fs/BsdNativeDispatcher.c ! src/java.base/share/classes/java/nio/file/attribute/BasicFileAttributeView.java ! src/java.base/unix/classes/sun/nio/fs/UnixConstants.java.template Changeset: 2bb727c4 Author: Sergey Bylokhov Date: 2022-12-16 00:43:56 +0000 URL: https://git.openjdk.org/loom/commit/2bb727c4eaf8a948f17f6416a1e6fbaeade4d7ce 8290899: java/lang/String/StringRepeat.java test requests too much heap on windows x86 Reviewed-by: jpai, phh ! test/jdk/java/lang/String/StringRepeat.java Changeset: a3364612 Author: David Holmes Date: 2022-12-16 01:08:30 +0000 URL: https://git.openjdk.org/loom/commit/a3364612f7d49f3633661b9ba4e9b721534cafad 8298081: DiagnoseSyncOnValueBasedClasses doesn't report useful information for virtual threads Reviewed-by: gziemski, pchilanomate ! src/hotspot/share/runtime/javaThread.cpp ! src/hotspot/share/runtime/javaThread.hpp ! src/hotspot/share/runtime/synchronizer.cpp ! test/hotspot/jtreg/runtime/Monitor/SyncOnValueBasedClassTest.java Changeset: e41686b4 Author: Jaikiran Pai Date: 2022-12-16 05:16:40 +0000 URL: https://git.openjdk.org/loom/commit/e41686b4050d6b32fb451de8af39a78ec8bed0fd 8298710: Fix typos in test/jdk/sun/security/tools/jarsigner/ Co-authored-by: Michael Ernst Reviewed-by: lancea ! test/jdk/javax/security/auth/x500/X500Principal/EscapedChars.java ! test/jdk/sun/security/tools/jarsigner/DigestDontIgnoreCase.java ! test/jdk/sun/security/tools/jarsigner/FindHeaderEndVsManifestDigesterFindFirstSection.java Changeset: fa322e40 Author: Jaikiran Pai Date: 2022-12-16 07:10:36 +0000 URL: https://git.openjdk.org/loom/commit/fa322e40b68abf0a253040d14414d41f4e01e028 8298709: Fix typos in src/java.desktop/ and various test classes of client component Co-authored-by: Michael Ernst Reviewed-by: iris, prr ! src/java.desktop/share/classes/javax/swing/text/Document.java ! test/jdk/java/awt/Multiscreen/DeviceIdentificationTest/DeviceIdentificationTest.java ! test/jdk/java/awt/datatransfer/HTMLDataFlavors/ManualHTMLDataFlavorTest.java ! test/jdk/java/awt/print/PrinterJob/PageFormatChange.java ! test/jdk/javax/imageio/stream/DeleteOnExitTest.sh ! test/jdk/javax/print/attribute/ServiceDlgPageRangeTest.java ! test/jdk/javax/sound/midi/Sequencer/SequencerState.java ! test/jdk/javax/swing/JColorChooser/Test4193384.java ! test/jdk/sanity/client/SwingSet/src/EditorPaneDemoTest.java ! test/jdk/sanity/client/SwingSet/src/TabbedPaneDemoTest.java ! test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/tree/resources/TreeDemo.properties ! test/jdk/sanity/client/lib/jemmy/src/org/netbeans/jemmy/WindowWaiter.java ! test/jdk/sanity/client/lib/jemmy/src/org/netbeans/jemmy/operators/ComponentOperator.java ! test/jdk/sanity/client/lib/jemmy/src/org/netbeans/jemmy/operators/JTreeOperator.java ! test/jdk/sanity/client/lib/jemmy/src/org/netbeans/jemmy/operators/Operator.java ! test/jdk/sun/java2d/pipe/hw/RSLAPITest/RSLAPITest.java Changeset: 226e579c Author: Fei Yang Date: 2022-12-16 08:45:52 +0000 URL: https://git.openjdk.org/loom/commit/226e579c3004a37a09f3329a8ef09c0933126bd6 8298088: RISC-V: Make Address a discriminated union internally Reviewed-by: fjiang, yadongwang, shade ! src/hotspot/cpu/riscv/assembler_riscv.cpp ! src/hotspot/cpu/riscv/assembler_riscv.hpp Changeset: 909d0cb4 Author: Michal Karm Babacek Committer: Jaikiran Pai Date: 2022-12-16 12:28:39 +0000 URL: https://git.openjdk.org/loom/commit/909d0cb4d9475fd367b8bc64a6b50c5a324e9a01 8298588: WebSockets: HandshakeUrlEncodingTest unnecessarily depends on a response body Reviewed-by: dfuchs ! test/jdk/java/net/httpclient/websocket/HandshakeUrlEncodingTest.java Changeset: ac2fcf3f Author: Ivan Walulya Date: 2022-12-16 12:59:44 +0000 URL: https://git.openjdk.org/loom/commit/ac2fcf3f7598caf8384282ec1178ec0b66c8408a 8296374: Check for young region in G1BarrierSet::invalidate instead of card-by-card check Reviewed-by: ayang, tschatzl ! src/hotspot/share/gc/g1/g1BarrierSet.cpp Changeset: f4caaca1 Author: Justin King Committer: Coleen Phillimore Date: 2022-12-16 14:00:56 +0000 URL: https://git.openjdk.org/loom/commit/f4caaca100d334b671eed56287dfe7a1009c47d7 8298852: Use of uninitialized memory in MetadataFactory::free_metadata Reviewed-by: coleenp, stefank, dholmes ! src/hotspot/share/memory/metadataFactory.hpp Changeset: 323e574a Author: Stefan Karlsson Date: 2022-12-15 11:28:06 +0000 URL: https://git.openjdk.org/loom/commit/323e574a50520735f41549f36907563e1b4a1040 8298371: monitors_on_stack extracts unprocessed oops Backport-of: b754aa5e3f231aea8da5274c330dc55dd78b0f67 ! src/hotspot/share/runtime/continuationFreezeThaw.cpp Changeset: 22a6b591 Author: Jan Lahoda Date: 2022-12-15 11:33:56 +0000 URL: https://git.openjdk.org/loom/commit/22a6b5910290cb8a3876f94213ba60db86e60718 8298727: Trees.getPath may crash for unnamed package Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Enter.java + test/langtools/tools/javac/processing/model/EmptyPackageInfo.java Changeset: 48f61273 Author: Stefan Karlsson Date: 2022-12-15 11:44:21 +0000 URL: https://git.openjdk.org/loom/commit/48f6127325108e573b41d19213e65af99956a31f 8298376: ZGC: thaws stackChunk with stale oops Backport-of: ed8a2120ca1e9756c6ab5eeebfe24c15d549f04e ! src/hotspot/share/oops/stackChunkOop.hpp ! src/hotspot/share/oops/stackChunkOop.inline.hpp ! src/hotspot/share/runtime/continuationJavaClasses.hpp ! src/hotspot/share/runtime/continuationJavaClasses.inline.hpp Changeset: 2c424992 Author: Per Minborg Committer: Joe Darcy Date: 2022-12-15 15:46:05 +0000 URL: https://git.openjdk.org/loom/commit/2c42499266377a32aa0ff96a0241d76d7517cf2e 8298050: Add links to graph output for javadoc Reviewed-by: darcy ! make/jdk/src/classes/build/tools/taglet/SealedGraph.java Changeset: ca39eb90 Author: Brian Burkhalter Date: 2022-12-15 17:27:08 +0000 URL: https://git.openjdk.org/loom/commit/ca39eb906692568347e7f264520593188f9276cf 7093322: (fs spec) Files.newBufferedWriter should be clear when coding errors are detected Reviewed-by: alanb ! src/java.base/share/classes/java/nio/file/Files.java Changeset: c7d7e7e3 Author: Daniel D. Daugherty Date: 2022-12-16 00:01:08 +0000 URL: https://git.openjdk.org/loom/commit/c7d7e7e3be768b35447d65661ec328204aeb40e4 8298888: ProblemList gc/g1/TestVerifyGCType.java on linux and macosx 8298889: ProblemList runtime/StackGuardPages/TestStackGuardPages.java on linux 8298891: ProblemList vmTestbase/nsk/monitoring/MemoryPoolMBean/isCollectionUsageThresholdExceeded/isexceeded002/TestDescription.java with ZGC 8298892: ProblemList vmTestbase/nsk/sysdict/vm/stress/chain/chain008/chain008.java with ZGC Reviewed-by: bpb, lmesnik ! test/hotspot/jtreg/ProblemList-zgc.txt ! test/hotspot/jtreg/ProblemList.txt Changeset: 03a694af Author: Sergey Bylokhov Date: 2022-12-16 06:33:08 +0000 URL: https://git.openjdk.org/loom/commit/03a694afda81f575f8a24e655d53b2b029e3d968 8298083: The "CheckBox/RadioButton[Enabled/Disabled].textForeground" stoped working Reviewed-by: prr Backport-of: 5540a8c5b7160ab5c67bb84631e3de54fa5aeceb ! src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKStyle.java ! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthStyle.java ! test/jdk/ProblemList.txt ! test/jdk/javax/swing/JRadioButton/4314194/bug4314194.java Changeset: c47e64e4 Author: Stefan Johansson Date: 2022-12-16 08:06:09 +0000 URL: https://git.openjdk.org/loom/commit/c47e64e4f3be80f434dd4dea9b6e8d282b2c2b32 8297979: ZGC: Ensure consistent MemoryUsage from MemoryMXBean.getHeapMemoryUsage() Reviewed-by: stefank, ayang ! src/hotspot/share/gc/z/zCollectedHeap.cpp ! src/hotspot/share/gc/z/zCollectedHeap.hpp ! test/hotspot/jtreg/ProblemList-zgc.txt Changeset: 0ba47348 Author: Markus Gr?nlund Date: 2022-12-16 10:46:37 +0000 URL: https://git.openjdk.org/loom/commit/0ba473489151d74c8a15b75ff4964ac480fecb28 8287699: jdk/jfr/api/consumer/TestRecordingFileWrite.java fails with exception: java.lang.Exception: Found event that should not be there. Reviewed-by: egahlin ! src/hotspot/share/jfr/support/jfrThreadLocal.cpp ! test/jdk/ProblemList.txt Changeset: f771c56e Author: Maurizio Cimadamore Date: 2022-12-16 10:49:22 +0000 URL: https://git.openjdk.org/loom/commit/f771c56e16a39724712ca0d8c2dd55b9ce260f4d 8298797: Specification of some restricted methods is incorrect Reviewed-by: jvernee, pminborg ! src/java.base/share/classes/java/lang/foreign/Linker.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/lang/foreign/VaList.java ! src/java.base/share/classes/java/lang/foreign/ValueLayout.java ! test/jdk/java/foreign/handles/lookup_module/handle/lookup/MethodHandleLookup.java Changeset: 3696711e Author: Jesper Wilhelmsson Date: 2022-12-16 15:48:24 +0000 URL: https://git.openjdk.org/loom/commit/3696711efa566fb776d6923da86e17b0e1e22964 Merge ! test/hotspot/jtreg/ProblemList-zgc.txt ! test/hotspot/jtreg/ProblemList.txt ! test/jdk/ProblemList.txt ! test/hotspot/jtreg/ProblemList-zgc.txt ! test/hotspot/jtreg/ProblemList.txt ! test/jdk/ProblemList.txt Changeset: 81e23ab3 Author: Eric Caspole Date: 2022-12-16 16:30:31 +0000 URL: https://git.openjdk.org/loom/commit/81e23ab3403a983ccddf27b1169a49e2ca061296 8298809: Clean up vm/compiler/InterfaceCalls JMH Reviewed-by: kvn ! test/micro/org/openjdk/bench/vm/compiler/InterfaceCalls.java Changeset: 0eeaeb8e Author: Naoto Sato Date: 2022-12-16 17:16:20 +0000 URL: https://git.openjdk.org/loom/commit/0eeaeb8e7ba40be5e93eb87c7e3dc94230062746 8298808: Check `script` code on detecting the base locales Reviewed-by: joehw ! make/jdk/src/classes/build/tools/cldrconverter/CLDRConverter.java ! make/jdk/src/classes/build/tools/cldrconverter/ResourceBundleGenerator.java Changeset: bf9a8ce0 Author: Matthew Donovan Committer: Rajan Halade Date: 2022-12-16 17:51:57 +0000 URL: https://git.openjdk.org/loom/commit/bf9a8ce0bb975a3d50e92148f92850ef930d64b0 8249826: 5 javax/net/ssl/SSLEngine tests use @ignore w/o bug-id Reviewed-by: xuelei, rhalade, ssahoo ! test/jdk/ProblemList.txt ! test/jdk/javax/net/ssl/SSLEngine/Basics.java ! test/jdk/javax/net/ssl/SSLEngine/CheckStatus.java ! test/jdk/javax/net/ssl/SSLEngine/ConnectionTest.java ! test/jdk/javax/net/ssl/SSLEngine/EngineCloseOnAlert.java ! test/jdk/javax/net/ssl/SSLEngine/IllegalHandshakeMessage.java ! test/jdk/javax/net/ssl/SSLEngine/IllegalRecordVersion.java ! test/jdk/javax/net/ssl/SSLEngine/TestAllSuites.java Changeset: bfa921ae Author: Kim Barrett Date: 2022-12-16 20:47:40 +0000 URL: https://git.openjdk.org/loom/commit/bfa921ae6ce068c53dfa708d6d3d2cddbad5fc33 8160404: RelocationHolder constructors have bugs Reviewed-by: kvn, jrose, jvernee ! src/hotspot/cpu/x86/assembler_x86.cpp ! src/hotspot/share/code/relocInfo.cpp ! src/hotspot/share/code/relocInfo.hpp Changeset: 7938f8c3 Author: Per Minborg Committer: Alan Bateman Date: 2022-12-18 20:25:42 +0000 URL: https://git.openjdk.org/loom/commit/7938f8c32a1c0ecdd3bcc8cd1a2652df248a2213 8298639: Perform I/O operations in bulk for RandomAccessFile Co-authored-by: Sergey Tsypanov Reviewed-by: alanb, bpb ! src/java.base/share/classes/java/io/RandomAccessFile.java ! test/jdk/java/io/File/Basic.java + test/micro/org/openjdk/bench/java/io/RandomAccessFileBenchmark.java Changeset: ba942c24 Author: Fei Gao Committer: Ningsheng Jian Date: 2022-12-19 01:11:19 +0000 URL: https://git.openjdk.org/loom/commit/ba942c24e8894f4422870fb53253f5946dc4f0d1 8298244: AArch64: Optimize vector implementation of AddReduction for floating point Reviewed-by: aph, xgong ! src/hotspot/cpu/aarch64/aarch64_vector.ad ! src/hotspot/cpu/aarch64/aarch64_vector_ad.m4 ! src/hotspot/cpu/aarch64/assembler_aarch64.hpp ! test/hotspot/gtest/aarch64/aarch64-asmtest.py ! test/hotspot/gtest/aarch64/asmtest.out.h Changeset: 5e678f75 Author: Christian Hagedorn Date: 2022-12-19 07:10:12 +0000 URL: https://git.openjdk.org/loom/commit/5e678f7500e514f04637c546959613d4688f989c 8298824: C2 crash: assert(is_Bool()) failed: invalid node class: ConI Reviewed-by: roland, kvn, thartmann ! src/hotspot/share/opto/subnode.cpp + test/hotspot/jtreg/compiler/c2/TestCMoveIConAsBool.java Changeset: 36376605 Author: sunguoyun Committer: Tobias Hartmann Date: 2022-12-19 07:56:36 +0000 URL: https://git.openjdk.org/loom/commit/36376605215ba3380bfc07752eec043af04a5c29 8298813: [C2] Converting double to float cause a loss of precision and resulting crypto.aes scores fluctuate Reviewed-by: thartmann ! src/hotspot/share/opto/chaitin.hpp Changeset: 16225630 Author: Damon Fenacci Committer: Tobias Hartmann Date: 2022-12-19 08:35:00 +0000 URL: https://git.openjdk.org/loom/commit/16225630ec3d4943e359f7a8b0f531429bb434c8 8265688: Unused ciMethodType::ptype_at should be removed Reviewed-by: thartmann, kvn ! src/hotspot/share/ci/ciMethodType.cpp ! src/hotspot/share/ci/ciMethodType.hpp Changeset: ec959914 Author: Damon Fenacci Committer: Tobias Hartmann Date: 2022-12-19 08:47:04 +0000 URL: https://git.openjdk.org/loom/commit/ec95991470a99c917f757614fc6d2cd883bdb39b 8298736: Revisit usages of log10 in compiler code Reviewed-by: thartmann, chagedorn, epeter ! src/hotspot/share/opto/loopnode.cpp ! src/hotspot/share/opto/node.cpp Changeset: 86d588b0 Author: Damon Fenacci Committer: Tobias Hartmann Date: 2022-12-19 08:48:41 +0000 URL: https://git.openjdk.org/loom/commit/86d588b035d09141d807dbed6b91d9909782d61a 8283740: C1: Convert flag TwoOperandLIRForm to a constant on all platforms Reviewed-by: thartmann, chagedorn ! src/hotspot/cpu/aarch64/c1_Defs_aarch64.hpp ! src/hotspot/cpu/aarch64/c1_globals_aarch64.hpp ! src/hotspot/cpu/arm/c1_Defs_arm.hpp ! src/hotspot/cpu/arm/c1_globals_arm.hpp ! src/hotspot/cpu/ppc/c1_Defs_ppc.hpp ! src/hotspot/cpu/ppc/c1_globals_ppc.hpp ! src/hotspot/cpu/riscv/c1_Defs_riscv.hpp ! src/hotspot/cpu/riscv/c1_globals_riscv.hpp ! src/hotspot/cpu/s390/c1_Defs_s390.hpp ! src/hotspot/cpu/s390/c1_globals_s390.hpp ! src/hotspot/cpu/x86/c1_Defs_x86.hpp ! src/hotspot/cpu/x86/c1_globals_x86.hpp ! src/hotspot/share/c1/c1_Defs.hpp ! src/hotspot/share/c1/c1_LIR.cpp ! src/hotspot/share/c1/c1_LIRGenerator.cpp ! src/hotspot/share/c1/c1_globals.hpp ! src/hotspot/share/gc/g1/c1/g1BarrierSetC1.cpp ! src/hotspot/share/gc/shared/c1/cardTableBarrierSetC1.cpp ! src/hotspot/share/gc/shenandoah/c1/shenandoahBarrierSetC1.cpp Changeset: 8e49fcdd Author: Damon Fenacci Committer: Tobias Hartmann Date: 2022-12-19 08:50:44 +0000 URL: https://git.openjdk.org/loom/commit/8e49fcdde4fef5a8db36823b35d409ba2c9ec47b 8295661: CompileTask::compile_id() should be passed as int Reviewed-by: thartmann, dnsimon, never ! src/hotspot/share/ci/ciEnv.cpp ! src/hotspot/share/ci/ciEnv.hpp ! src/hotspot/share/code/codeHeapState.cpp ! src/hotspot/share/code/codeHeapState.hpp ! src/hotspot/share/compiler/compileBroker.cpp ! src/hotspot/share/compiler/compileBroker.hpp ! src/hotspot/share/compiler/compileTask.hpp ! src/hotspot/share/jfr/metadata/metadata.xml ! src/hotspot/share/runtime/vmStructs.cpp Changeset: da38d43f Author: Emanuel Peter Date: 2022-12-19 12:21:50 +0000 URL: https://git.openjdk.org/loom/commit/da38d43fcc640ea9852db6c7c23817dcef7080d5 8296412: Special case infinite loops with unmerged backedges in IdealLoopTree::check_safepts Reviewed-by: chagedorn, kvn, thartmann ! src/hotspot/share/opto/loopnode.cpp + test/hotspot/jtreg/compiler/loopopts/TestInfiniteLoopWithUnmergedBackedges.jasm + test/hotspot/jtreg/compiler/loopopts/TestInfiniteLoopWithUnmergedBackedgesMain.java Changeset: de0ce792 Author: Damon Fenacci Committer: Christian Hagedorn Date: 2022-12-19 15:44:38 +0000 URL: https://git.openjdk.org/loom/commit/de0ce792c1865f80b6bcfce6741681cb74d75cef 8297801: printnm crashes with invalid address due to null pointer dereference Reviewed-by: thartmann, chagedorn, kvn ! src/hotspot/share/utilities/debug.cpp Changeset: 756a06d4 Author: Matthias Baesken Date: 2022-12-19 16:20:12 +0000 URL: https://git.openjdk.org/loom/commit/756a06d4c239966ed68bbbe8ee4c6b6d02154c02 8299022: Linux ppc64le and s390x build issues after JDK-8160404 Reviewed-by: mdoerr, lucy ! src/hotspot/cpu/ppc/assembler_ppc.hpp ! src/hotspot/cpu/s390/assembler_s390.hpp Changeset: 4c927df7 Author: Coleen Phillimore Date: 2022-12-19 17:13:57 +0000 URL: https://git.openjdk.org/loom/commit/4c927df7125f3c9d4c24dc587ad99d7fa1d1ccb3 8298470: Short cut java.lang.Object super class loading Reviewed-by: dholmes, iklam ! src/hotspot/share/classfile/classFileParser.cpp Changeset: 9194e915 Author: Chris Plummer Date: 2022-12-19 18:02:34 +0000 URL: https://git.openjdk.org/loom/commit/9194e915495434c154ff4cf142d527b163026b3c 8298701: Cleanup SA entries in ProblemList-zgc.txt. Reviewed-by: sspitsyn, amenkov ! test/hotspot/jtreg/ProblemList-zgc.txt Changeset: 40cb431f Author: Archie L. Cobbs Committer: Jonathan Gibbons Date: 2022-12-19 19:48:13 +0000 URL: https://git.openjdk.org/loom/commit/40cb431fee7c1f193b2f445c397c1444ed2e0015 8298943: Missing escapes for single quote marks in compiler.properties Reviewed-by: jjg ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/langtools/tools/javac/diags/CheckResourceKeys.java Changeset: 5d330f52 Author: Jonathan Gibbons Date: 2022-12-19 21:09:01 +0000 URL: https://git.openjdk.org/loom/commit/5d330f5285b535b37dde5cd4e42374d92fafb550 8299045: tools/doclint/BadPackageCommentTest.java fails after JDK-8298943 Reviewed-by: vromero ! test/langtools/tools/doclint/BadPackageCommentTest.out Changeset: abc12976 Author: lawrence.andrews Committer: Harshitha Onkar Date: 2022-12-19 23:26:01 +0000 URL: https://git.openjdk.org/loom/commit/abc1297643b03ea9b4a03a12ce681971784774fb 8299044: test/jdk/javax/swing/JComboBox/JComboBoxBorderTest.java fails on non mac Reviewed-by: serb, honkar ! test/jdk/javax/swing/JComboBox/JComboBoxBorderTest.java Changeset: 05f9e767 Author: Phil Race Date: 2022-12-19 23:32:58 +0000 URL: https://git.openjdk.org/loom/commit/05f9e7676ea457cd5ef44acca9a1706b5dd0d093 8298974: Add ftcolor.c to imported freetype sources Reviewed-by: serb + src/java.desktop/share/native/libfreetype/src/base/ftcolor.c Changeset: dd15d306 Author: lawrence.andrews Committer: Sergey Bylokhov Date: 2022-12-20 01:16:37 +0000 URL: https://git.openjdk.org/loom/commit/dd15d306a68caa02659dd95d16b71d0f1a437bc6 8299043: test/jdk/javax/swing/AbstractButton/5049549/bug5049549.java fails with java.lang.NullPointerException Reviewed-by: serb ! test/jdk/javax/swing/AbstractButton/5049549/bug5049549.java Changeset: 36de61c4 Author: Daniel Jeli?ski Date: 2022-12-20 10:27:33 +0000 URL: https://git.openjdk.org/loom/commit/36de61c460d7038019294293143e420dfcce2936 8298865: Excessive memory allocation in CipherOutputStream AEAD decryption Reviewed-by: valeriep, ascarpino ! src/java.base/share/classes/javax/crypto/CipherInputStream.java ! src/java.base/share/classes/javax/crypto/CipherOutputStream.java + test/micro/org/openjdk/bench/javax/crypto/full/AESGCMCipherOutputStream.java Changeset: 5df00d34 Author: Daniel Fuchs Date: 2022-12-20 11:05:38 +0000 URL: https://git.openjdk.org/loom/commit/5df00d34fe83648fb833dac738a45653865ca426 8298931: java/net/httpclient/CancelStreamedBodyTest.java fails with AssertionError due to Pending TCP connections: 1 Reviewed-by: jpai ! test/jdk/java/net/httpclient/CancelStreamedBodyTest.java ! test/jdk/java/net/httpclient/ISO_8859_1_Test.java ! test/jdk/java/net/httpclient/ReferenceTracker.java Changeset: e5edb10d Author: Daniel Fuchs Date: 2022-12-20 11:06:36 +0000 URL: https://git.openjdk.org/loom/commit/e5edb10dc56d9edac8e050e0f8e6c116743975d6 8299018: java/net/httpclient/HttpsTunnelAuthTest.java fails with java.io.IOException: HTTP/1.1 header parser received no bytes Reviewed-by: djelinski, jpai ! test/jdk/java/net/httpclient/ProxyServer.java Changeset: b14794db Author: Coleen Phillimore Date: 2022-12-16 14:09:55 +0000 URL: https://git.openjdk.org/loom/commit/b14794db00ded878dbfc7080f9d57a0f65c02dee 8298852: Use of uninitialized memory in MetadataFactory::free_metadata Backport-of: f4caaca100d334b671eed56287dfe7a1009c47d7 ! src/hotspot/share/memory/metadataFactory.hpp Changeset: 9e10f00e Author: Tobias Hartmann Date: 2022-12-16 14:39:48 +0000 URL: https://git.openjdk.org/loom/commit/9e10f00edbf37e5e5db8efc4f1e0c2a76541aab2 8298919: Add a regression test for JDK-8298520 Reviewed-by: chagedorn, roland + test/hotspot/jtreg/compiler/loopopts/TestUnexpectedOpaque1.java Changeset: c997b5bf Author: Damon Nguyen Committer: Naoto Sato Date: 2022-12-16 21:15:29 +0000 URL: https://git.openjdk.org/loom/commit/c997b5bffd0ebbd6d68332572639c8cea05ccdb1 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 Reviewed-by: achung, naoto, joehw, cjplummer, almatvee ! src/java.base/share/classes/sun/launcher/resources/launcher_de.properties ! src/java.base/share/classes/sun/launcher/resources/launcher_ja.properties ! src/java.base/share/classes/sun/launcher/resources/launcher_zh_CN.properties ! src/java.base/share/classes/sun/security/tools/keytool/Resources_de.java ! src/java.base/share/classes/sun/security/tools/keytool/Resources_ja.java ! src/java.base/share/classes/sun/security/tools/keytool/Resources_zh_CN.java ! src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_de.properties ! src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_ja.properties ! src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_zh_CN.properties ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_de.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_ja.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_zh_CN.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_de.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_ja.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_zh_CN.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_de.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_ja.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_zh_CN.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_de.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_ja.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_zh_CN.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_de.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_ja.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_zh_CN.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_de.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_ja.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_zh_CN.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_de.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_ja.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_zh_CN.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_de.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_ja.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_zh_CN.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_de.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_ja.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_zh_CN.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_de.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_ja.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_zh_CN.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_de.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_ja.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_zh_CN.properties ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_de.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_ja.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_zh_CN.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_de.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_ja.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_zh_CN.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac_de.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac_ja.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac_zh_CN.properties ! src/jdk.jartool/share/classes/sun/tools/jar/resources/jar_de.properties ! src/jdk.jartool/share/classes/sun/tools/jar/resources/jar_ja.properties ! src/jdk.jartool/share/classes/sun/tools/jar/resources/jar_zh_CN.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard_de.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard_ja.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard_zh_CN.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets_de.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets_ja.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets_zh_CN.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/resources/doclint_de.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/resources/doclint_ja.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/resources/doclint_zh_CN.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/resources/javadoc_de.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/resources/javadoc_ja.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/resources/javadoc_zh_CN.properties ! src/jdk.jdeps/share/classes/com/sun/tools/javap/resources/javap_de.properties ! src/jdk.jdeps/share/classes/com/sun/tools/javap/resources/javap_ja.properties ! src/jdk.jdeps/share/classes/com/sun/tools/javap/resources/javap_zh_CN.properties ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/resources/jdeps_de.properties ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/resources/jdeps_ja.properties ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/resources/jdeps_zh_CN.properties ! src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_de.java ! src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_ja.java ! src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_zh_CN.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/resources/jdi_de.properties ! src/jdk.jdi/share/classes/com/sun/tools/jdi/resources/jdi_ja.properties ! src/jdk.jdi/share/classes/com/sun/tools/jdi/resources/jdi_zh_CN.properties ! src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink_de.properties ! src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink_ja.properties ! src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink_zh_CN.properties ! src/jdk.jlink/share/classes/jdk/tools/jmod/resources/jmod_de.properties ! src/jdk.jlink/share/classes/jdk/tools/jmod/resources/jmod_ja.properties ! src/jdk.jlink/share/classes/jdk/tools/jmod/resources/jmod_zh_CN.properties ! src/jdk.jpackage/linux/classes/jdk/jpackage/internal/resources/LinuxResources_de.properties ! src/jdk.jpackage/linux/classes/jdk/jpackage/internal/resources/LinuxResources_ja.properties ! src/jdk.jpackage/linux/classes/jdk/jpackage/internal/resources/LinuxResources_zh_CN.properties ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources_de.properties ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources_ja.properties ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources_zh_CN.properties ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/HelpResources_de.properties ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/HelpResources_ja.properties ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/HelpResources_zh_CN.properties ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources_de.properties ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources_ja.properties ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources_zh_CN.properties ! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_de.properties ! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_ja.properties ! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_zh_CN.properties Changeset: 0ecad28d Author: Daniel D. Daugherty Date: 2022-12-16 21:17:04 +0000 URL: https://git.openjdk.org/loom/commit/0ecad28daa64ae1a0e6194e207ae57486b06e484 8298976: ProblemList java/util/concurrent/ExecutorService/CloseTest.java on macosx-aarch64 8298977: ProblemList vmTestbase/nsk/stress/strace/strace002.java on 2 platforms 8298978: ProblemList vmTestbase/nsk/stress/strace/strace003.java on 2 platforms Reviewed-by: kbarrett, iris ! test/hotspot/jtreg/ProblemList.txt ! test/jdk/ProblemList.txt Changeset: 3b7970ca Author: Ajit Ghaisas Date: 2022-12-17 06:37:18 +0000 URL: https://git.openjdk.org/loom/commit/3b7970cab39a67eabcde331822f0432f71d9186b 8298217: Regressions 30-110% in SwingMark on MacOS, more so on aarch64 Reviewed-by: avu, prr, jdv ! src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLRenderQueue.h ! src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLRenderQueue.m ! src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLRenderer.h ! src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLRenderer.m - test/jdk/java/awt/Graphics2D/DrawPrimitivesTest.java Changeset: 41cc0443 Author: Alexander Zvegintsev Date: 2022-12-17 13:28:39 +0000 URL: https://git.openjdk.org/loom/commit/41cc04430ab9e6db31ea26b5254668c9ab18966d 8298970: Problem list java/awt/event/KeyEvent/KeyTyped/CtrlASCII.java Reviewed-by: serb ! test/jdk/ProblemList.txt Changeset: d1026720 Author: Alexander Zvegintsev Date: 2022-12-17 13:30:24 +0000 URL: https://git.openjdk.org/loom/commit/d1026720d323d0acd9bd8d85d5caba7185107863 8298905: Test "java/awt/print/PrinterJob/ImagePrinting/PrintARGBImage.java" fails because the frames of instruction does not display Reviewed-by: honkar, serb ! test/jdk/java/awt/print/PrinterJob/ImagePrinting/PrintARGBImage.java ! test/jdk/java/awt/print/PrinterJob/PageRangesDlgTest.java ! test/jdk/javax/swing/ProgressMonitor/ProgressTest.java Changeset: 34105556 Author: Daniel D. Daugherty Date: 2022-12-17 16:13:03 +0000 URL: https://git.openjdk.org/loom/commit/34105556d16774439195076f22f37f275d0d8873 8298987: ProblemList jdk/internal/vm/Continuation/Fuzz.java#default with ZGC on X64 8298989: ProblemList vmTestbase/nsk/jvmti/InterruptThread/intrpthrd003/TestDescription.java on macosx-x64 8298990: ProblemList java/lang/Thread/virtual/stress/Skynet.java subtests with ZGC Reviewed-by: azvegint ! test/hotspot/jtreg/ProblemList.txt ! test/jdk/ProblemList-zgc.txt Changeset: 2c69c41d Author: Alan Bateman Date: 2022-12-19 18:06:19 +0000 URL: https://git.openjdk.org/loom/commit/2c69c41d48fddcbeb40a374f691b7e5faba3c99a 8298894: java/lang/Thread/virtual/stress/Skynet.java timed out and threw OutOfMemoryError Reviewed-by: eosterlund ! test/jdk/ProblemList-zgc.txt ! test/jdk/java/lang/Thread/virtual/stress/Skynet.java Changeset: 188aaef3 Author: Hannes Walln?fer Date: 2022-12-19 19:13:29 +0000 URL: https://git.openjdk.org/loom/commit/188aaef38594658288e9222ed815d5af4b8d3dad 8277074: Qualified exported types show up in JavaDoc Reviewed-by: psandoz ! src/java.base/share/classes/jdk/internal/event/Event.java ! src/java.base/share/classes/jdk/internal/vm/vector/VectorSupport.java Changeset: 3e17e3c1 Author: Alexander Zuev Date: 2022-12-19 22:16:56 +0000 URL: https://git.openjdk.org/loom/commit/3e17e3c1c12d71461213bf15cdb72d4d93c88460 4512626: Non-editable JTextArea provides no visual indication of keyboard focus 8194048: Regression automated test '/open/test/jdk/javax/swing/text/DefaultCaret/HidingSelection/HidingSelectionTest.java' fails 8213562: Test javax/swing/text/DefaultCaret/HidingSelection/MultiSelectionTest.java fails Reviewed-by: aivanov, azvegint ! src/java.desktop/share/classes/javax/swing/text/DefaultCaret.java ! test/jdk/ProblemList.txt ! test/jdk/javax/swing/text/DefaultCaret/HidingSelection/HidingSelectionTest.java ! test/jdk/javax/swing/text/DefaultCaret/HidingSelection/MultiSelectionTest.java Changeset: f07acfc1 Author: Daniel D. Daugherty Date: 2022-12-19 23:08:56 +0000 URL: https://git.openjdk.org/loom/commit/f07acfc166e1261f830e63629e76303ec6235377 8298699: java/lang/reflect/IllegalArgumentsTest.java times out with slowdebug bits Reviewed-by: iris ! test/jdk/java/lang/reflect/IllegalArgumentsTest.java Changeset: d0a7679d Author: Roger Riggs Date: 2022-12-19 23:10:30 +0000 URL: https://git.openjdk.org/loom/commit/d0a7679d2e9c86ee2fc6edf2e37c1729c833ae11 4958969: ObjectOutputStream example leads to non-working code Reviewed-by: lancea, naoto ! src/java.base/share/classes/java/io/ObjectInputFilter.java ! src/java.base/share/classes/java/io/ObjectInputStream.java ! src/java.base/share/classes/java/io/ObjectOutputStream.java Changeset: ea40f299 Author: Kim Barrett Date: 2022-12-20 00:13:25 +0000 URL: https://git.openjdk.org/loom/commit/ea40f299397f19f1bbedd4eeb4d24802a709a912 8298215: gc/g1/TestVerifyGCType.java failed with "Missing expected verification pattern Verifying After GC for: Pause Young (Prepare Mixed): expected true, was false" Reviewed-by: iwalulya, tschatzl ! src/hotspot/share/gc/g1/g1Policy.cpp ! src/hotspot/share/gc/g1/g1Policy.hpp ! test/hotspot/jtreg/ProblemList.txt ! test/hotspot/jtreg/gc/g1/TestVerifyGCType.java Changeset: 3dd2cfab Author: Erik Gahlin Date: 2022-12-20 10:52:11 +0000 URL: https://git.openjdk.org/loom/commit/3dd2cfabdcd91cf9e53d977ef76d0c81b3a072eb 8298784: JFR: Test chunk integrity Reviewed-by: mgronlun + test/jdk/jdk/jfr/jvm/TestChunkIntegrity.java Changeset: c5a4a7a6 Author: Jesper Wilhelmsson Date: 2022-12-20 11:40:56 +0000 URL: https://git.openjdk.org/loom/commit/c5a4a7a679ec76cb08a999a198e5c73e9cd9d2f0 Merge ! src/hotspot/share/gc/g1/g1Policy.cpp ! src/hotspot/share/gc/g1/g1Policy.hpp ! test/hotspot/jtreg/ProblemList.txt ! test/hotspot/jtreg/gc/g1/TestVerifyGCType.java ! test/jdk/ProblemList.txt ! src/hotspot/share/gc/g1/g1Policy.cpp ! src/hotspot/share/gc/g1/g1Policy.hpp ! test/hotspot/jtreg/ProblemList.txt ! test/hotspot/jtreg/gc/g1/TestVerifyGCType.java ! test/jdk/ProblemList.txt Changeset: 318526b0 Author: Erik Gahlin Date: 2022-12-20 12:22:01 +0000 URL: https://git.openjdk.org/loom/commit/318526b01e45698cd1fa2c930a97f8c2aa84fb2d 8299031: JFR: Clean up jdk.management.jfr Reviewed-by: mgronlun ! src/jdk.management.jfr/share/classes/jdk/management/jfr/ConfigurationInfo.java ! src/jdk.management.jfr/share/classes/jdk/management/jfr/EventTypeInfo.java ! src/jdk.management.jfr/share/classes/jdk/management/jfr/RecordingInfo.java ! src/jdk.management.jfr/share/classes/jdk/management/jfr/RemoteRecordingStream.java Changeset: de8153ca Author: Erik Gahlin Date: 2022-12-20 13:07:25 +0000 URL: https://git.openjdk.org/loom/commit/de8153cab76606350eb0ecc4302b23c52f0565a6 8298526: JFR: Generate missing filename for time-bound recordings Reviewed-by: mgronlun ! src/jdk.jfr/share/classes/jdk/jfr/internal/dcmd/DCmdStart.java ! test/jdk/jdk/jfr/startupargs/TestStartDuration.java Changeset: 8dfb6d76 Author: Albert Mingkun Yang Date: 2022-12-20 19:36:52 +0000 URL: https://git.openjdk.org/loom/commit/8dfb6d76e8528af2c5dd6a1354ba9175f5369fe5 8298651: Serial: Remove MarkSweep::follow_klass Reviewed-by: kbarrett, tschatzl ! src/hotspot/share/gc/serial/markSweep.cpp ! src/hotspot/share/gc/serial/markSweep.hpp Changeset: 65fc0588 Author: Albert Mingkun Yang Date: 2022-12-20 12:43:53 +0000 URL: https://git.openjdk.org/loom/commit/65fc05884bc96ce0b6f572034ae085c933f85c61 8298968: G1: Incorrect merged remset stats Reviewed-by: tschatzl, kbarrett ! src/hotspot/share/gc/g1/g1RemSet.cpp Changeset: 03d99272 Author: Coleen Phillimore Date: 2022-12-20 13:21:50 +0000 URL: https://git.openjdk.org/loom/commit/03d992728e27bd3dcd00d1af8a7b7179281e626f 8298061: vmTestbase/nsk/sysdict/vm/stress/btree/btree012/btree012.java failed with "fatal error: refcount has gone to zero" Reviewed-by: iklam, dholmes ! src/hotspot/share/classfile/placeholders.hpp Changeset: 03afec16 Author: Coleen Phillimore Date: 2022-12-20 14:09:22 +0000 URL: https://git.openjdk.org/loom/commit/03afec16f8abecb845eb14db5b51eaac9131a3c8 8298162: Test PrintClasses hits assert when run with code that retransform classes Reviewed-by: dholmes, mgronlun ! src/hotspot/share/runtime/fieldDescriptor.cpp ! test/hotspot/jtreg/runtime/CommandLine/PrintClasses.java Changeset: f4d7f433 Author: Daniel D. Daugherty Date: 2022-12-20 16:20:50 +0000 URL: https://git.openjdk.org/loom/commit/f4d7f433942219704072a3fef156fe0fa7864f66 8299123: [BACKOUT] 4512626 Non-editable JTextArea provides no visual indication of keyboard focus Reviewed-by: tschatzl ! src/java.desktop/share/classes/javax/swing/text/DefaultCaret.java ! test/jdk/ProblemList.txt ! test/jdk/javax/swing/text/DefaultCaret/HidingSelection/HidingSelectionTest.java ! test/jdk/javax/swing/text/DefaultCaret/HidingSelection/MultiSelectionTest.java Changeset: 386db071 Author: Jesper Wilhelmsson Date: 2022-12-20 20:20:17 +0000 URL: https://git.openjdk.org/loom/commit/386db07143883f85307138eca2f0305d997a2171 Merge ! test/jdk/ProblemList.txt ! test/jdk/ProblemList.txt Changeset: 396a9bff Author: Kim Barrett Date: 2022-12-21 01:22:11 +0000 URL: https://git.openjdk.org/loom/commit/396a9bff68cd25331ff88927264eae51c583bf48 8298913: Add override qualifiers to Relocation classes Reviewed-by: kvn, aboldtch ! src/hotspot/share/code/relocInfo.hpp Changeset: f56285c3 Author: Xue-Lei Andrew Fan Date: 2022-12-21 01:47:50 +0000 URL: https://git.openjdk.org/loom/commit/f56285c3613bb127e22f544bd4b461a0584e9d2a 8299146: No copyright statement on ArtifactResolverException.java Reviewed-by: erikj ! test/lib/jdk/test/lib/artifacts/ArtifactResolverException.java Changeset: f36e1449 Author: Matthias Baesken Date: 2022-12-21 08:05:37 +0000 URL: https://git.openjdk.org/loom/commit/f36e144923da431a9c47faf5ae6577714fcf3adf 8299025: BMPImageReader.java readColorPalette could use staggeredReadByteStream Reviewed-by: clanger ! src/java.desktop/share/classes/com/sun/imageio/plugins/bmp/BMPImageReader.java Changeset: 85f9b37d Author: Andrey Turbanov Date: 2022-12-21 08:15:11 +0000 URL: https://git.openjdk.org/loom/commit/85f9b37d71852d35a75d404e1657db0562dacac5 8297682: Use Collections.emptyIterator where applicable Reviewed-by: stsypanov, alanb, jpai ! src/java.base/unix/classes/sun/nio/fs/UnixFileSystem.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java Changeset: b005013a Author: Naveen Narayanan Committer: Alexey Ivanov Date: 2022-12-21 10:48:27 +0000 URL: https://git.openjdk.org/loom/commit/b005013a0015656b7f6ccc26f8a13c44d61f77b9 8296275: Write a test to verify setAccelerator method of JMenuItem Reviewed-by: mvs, aivanov + test/jdk/javax/swing/JMenuItem/JMenuItemSetAcceleratorTest.java Changeset: a7d6de71 Author: Chris Hegarty Date: 2022-12-21 12:19:06 +0000 URL: https://git.openjdk.org/loom/commit/a7d6de71bb83c8715654f61dd166aad6e8dab847 8299015: Ensure that HttpResponse.BodySubscribers.ofFile writes all bytes Co-authored-by: Daniel Jeli?ski Reviewed-by: dfuchs, djelinski, jpai ! src/java.net.http/share/classes/jdk/internal/net/http/ResponseSubscribers.java ! src/java.net.http/share/classes/jdk/internal/net/http/common/Utils.java ! test/jdk/java/net/httpclient/PathSubscriber/BodySubscriberOfFileTest.java Changeset: 88bfe4d3 Author: Roland Westrelin Date: 2022-12-21 14:46:57 +0000 URL: https://git.openjdk.org/loom/commit/88bfe4d3bff5504bb6061d1484325dd6a55f06a2 8297724: Loop strip mining prevents some empty loops from being eliminated Reviewed-by: kvn, thartmann ! src/hotspot/share/opto/loopTransform.cpp ! src/hotspot/share/opto/loopnode.hpp + test/hotspot/jtreg/compiler/c2/irTests/TestLSMMissedEmptyLoop.java Changeset: 65442a2e Author: Matias Saavedra Silva Committer: Ioi Lam Date: 2022-12-21 15:33:24 +0000 URL: https://git.openjdk.org/loom/commit/65442a2e26afa7c31b5949e7e20606e4066ced3b 8269736: Optimize CDS PatchEmbeddedPointers::do_bit() Reviewed-by: ccheung, iklam ! src/hotspot/share/cds/archiveHeapLoader.cpp ! src/hotspot/share/cds/archiveHeapLoader.hpp ! src/hotspot/share/cds/archiveHeapLoader.inline.hpp ! src/hotspot/share/cds/filemap.cpp ! src/hotspot/share/cds/filemap.hpp ! test/hotspot/jtreg/runtime/cds/appcds/cacheObject/DifferentHeapSizes.java Changeset: 10d62fa2 Author: Xin Liu Date: 2022-12-21 16:48:20 +0000 URL: https://git.openjdk.org/loom/commit/10d62fa2183c0ed252ad0a9a743ae6a7710f9a95 8299061: Using lambda to optimize GraphKit::compute_stack_effects() Reviewed-by: kbarrett, thartmann ! src/hotspot/share/opto/graphKit.cpp Changeset: 7e59a0ec Author: Naoto Sato Date: 2022-12-21 18:09:21 +0000 URL: https://git.openjdk.org/loom/commit/7e59a0ecb672292814abdf7f2e31a5f5868c43d8 8298971: Move Console implementation into jdk internal package Reviewed-by: jpai ! src/java.base/share/classes/java/io/Console.java = src/java.base/share/classes/jdk/internal/io/JdkConsoleImpl.java ! src/java.base/unix/native/libjava/Console_md.c + src/java.base/unix/native/libjava/JdkConsoleImpl_md.c Changeset: f80faced Author: Damon Nguyen Committer: Harshitha Onkar Date: 2022-12-21 20:10:52 +0000 URL: https://git.openjdk.org/loom/commit/f80faced6e6c6c1b10541a8b0c91625215c9ef43 8202931: [macos] java/awt/Choice/ChoicePopupLocation/ChoicePopupLocation.java fails Reviewed-by: serb, honkar ! test/jdk/ProblemList.txt ! test/jdk/java/awt/Choice/ChoicePopupLocation/ChoicePopupLocation.java Changeset: e85d00f6 Author: Jonathan Gibbons Date: 2022-12-20 21:33:53 +0000 URL: https://git.openjdk.org/loom/commit/e85d00f6c32c9938fbc9529b055d90082f565fa3 8299147: Minor accessibility errors in the specs and man index pages Reviewed-by: mchung, erikj ! make/Docs.gmk Changeset: 3d4d9fd6 Author: Martin Doerr Date: 2022-12-20 22:02:34 +0000 URL: https://git.openjdk.org/loom/commit/3d4d9fd6e6de037950f94482d4e33f178eb15daa 8298947: compiler/codecache/MHIntrinsicAllocFailureTest.java fails intermittently Reviewed-by: kvn, chagedorn ! test/hotspot/jtreg/compiler/codecache/MHIntrinsicAllocFailureTest.java Changeset: f7be5b53 Author: Jonathan Gibbons Date: 2022-12-20 22:53:09 +0000 URL: https://git.openjdk.org/loom/commit/f7be5b530d10005ba928309870c9adc42afdf66a 8299156: Broken link in jdk.compiler/module-info.java Reviewed-by: iris ! src/jdk.compiler/share/classes/module-info.java Changeset: 92fe304f Author: Christoph Langer Date: 2022-12-21 10:57:24 +0000 URL: https://git.openjdk.org/loom/commit/92fe304f08b406cb0f87cf32497aea2f5ce9c5ea 8298588: WebSockets: HandshakeUrlEncodingTest unnecessarily depends on a response body Backport-of: 909d0cb4d9475fd367b8bc64a6b50c5a324e9a01 ! test/jdk/java/net/httpclient/websocket/HandshakeUrlEncodingTest.java Changeset: 81933b7a Author: Nick Gasson Date: 2022-12-21 11:00:48 +0000 URL: https://git.openjdk.org/loom/commit/81933b7a927c1579eda7b6678901e5d2bc1c1aed 8298642: ParallelGC -XX:+UseNUMA eden spaces allocated on wrong node Reviewed-by: tschatzl, ayang ! src/hotspot/share/gc/parallel/mutableNUMASpace.cpp Changeset: 9adc349c Author: Tyler Steele Date: 2022-12-21 18:17:42 +0000 URL: https://git.openjdk.org/loom/commit/9adc349cbb38ccc23096c4504c7b4b70009c660f 8298726: (fs) Change PollingWatchService to record last modified time as FileTime rather than milliseconds Backport-of: 5f63f7a742a1071a87ca69463bae6e04a44fe462 ! src/java.base/share/classes/sun/nio/fs/PollingWatchService.java Changeset: 22007a1e Author: Volodymyr Paprotski Committer: Sandhya Viswanathan Date: 2022-12-21 18:43:40 +0000 URL: https://git.openjdk.org/loom/commit/22007a1e387a1b8e897c6fbb056377b7ddc6ec00 8298893: Rename option UsePolyIntrinsics to UsePoly1305Intrinsics Reviewed-by: jnimeh, chagedorn, thartmann ! src/hotspot/cpu/x86/stubGenerator_x86_64.cpp ! src/hotspot/cpu/x86/vm_version_x86.cpp ! src/hotspot/share/classfile/vmIntrinsics.cpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/runtime/globals.hpp Changeset: 34cdda5b Author: Jesper Wilhelmsson Date: 2022-12-21 23:50:59 +0000 URL: https://git.openjdk.org/loom/commit/34cdda5b8359cce33c2d4f92a41a620aea4f96e7 Merge Changeset: 50120396 Author: Sergey Bylokhov Date: 2022-12-22 07:20:06 +0000 URL: https://git.openjdk.org/loom/commit/50120396b6cca1219fb5dd42a11e4b29b79bd3bd 8298887: On the latest macOS+XCode the Robot API may report wrong colors Reviewed-by: azvegint ! src/java.desktop/macosx/native/libawt_lwawt/awt/CRobot.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/QuartzSurfaceData.h ! test/jdk/java/awt/AlphaComposite/WindowAlphaCompositeTest.java ! test/jdk/java/awt/Robot/CheckCommonColors/CheckCommonColors.java ! test/jdk/java/awt/font/GlyphVector/MultiSlotFontTest.java Changeset: a3693ccc Author: Bill Huang Date: 2022-12-22 16:50:59 +0000 URL: https://git.openjdk.org/loom/commit/a3693ccc617d06137a61050b34646e8a90ed3d7e 8295087: Manual Test to Automated Test Conversion Reviewed-by: ssahoo, rhalade ! test/jdk/ProblemList.txt ! test/jdk/TEST.groups ! test/jdk/java/security/Policy/Root/Root.java ! test/jdk/javax/crypto/CryptoPermissions/InconsistentEntries.java + test/jdk/javax/crypto/CryptoPermissions/default_local.policy ! test/jdk/sun/security/provider/PolicyParser/ExtDirs.java ! test/jdk/sun/security/provider/PolicyParser/ExtDirs.policy ! test/jdk/sun/security/provider/PolicyParser/ExtDirs1.policy ! test/jdk/sun/security/provider/PolicyParser/ExtDirs2.policy ! test/jdk/sun/security/provider/PolicyParser/ExtDirs3.policy ! test/jdk/sun/security/provider/PolicyParser/ExtDirsChange.java ! test/jdk/sun/security/provider/PolicyParser/ExtDirsChange.policy ! test/jdk/sun/security/provider/PolicyParser/ExtDirsDefaultPolicy.java Changeset: 62a033ec Author: Kim Barrett Date: 2022-12-22 17:30:09 +0000 URL: https://git.openjdk.org/loom/commit/62a033ecd7058f4a4354ebdcd667b3d7991e1f3d 8299191: Unnecessarily global friend functions for relocInfo Reviewed-by: chagedorn, kvn ! src/hotspot/share/asm/codeBuffer.cpp ! src/hotspot/share/code/relocInfo.cpp ! src/hotspot/share/code/relocInfo.hpp Changeset: b378381a Author: Andrey Turbanov Date: 2022-12-22 19:09:37 +0000 URL: https://git.openjdk.org/loom/commit/b378381a9c5abf555c4ccf87d387d2cd77196e04 8299199: Avoid redundant split calls in FontConfiguration.initReorderMap implementations Reviewed-by: aivanov ! src/java.desktop/share/classes/sun/awt/FontConfiguration.java ! src/java.desktop/unix/classes/sun/font/MFontConfiguration.java ! src/java.desktop/windows/classes/sun/awt/windows/WFontConfiguration.java Changeset: 6ccee839 Author: Ioi Lam Date: 2022-12-22 20:50:20 +0000 URL: https://git.openjdk.org/loom/commit/6ccee839580fd9dc4cd4941b44dbbe3105202561 8292206: TestCgroupMetrics.java fails as getMemoryUsage() is lower than expected Reviewed-by: dholmes, sgehwolf ! test/jdk/jdk/internal/platform/cgroup/TestCgroupMetrics.java ! test/jdk/jdk/internal/platform/docker/TestSystemMetrics.java ! test/lib/jdk/test/lib/containers/cgroup/MetricsTester.java Changeset: 5e2de896 Author: Ichiroh Takiguchi Date: 2022-12-22 21:07:01 +0000 URL: https://git.openjdk.org/loom/commit/5e2de89628aaf6acb8e458fb417426ca5e477bea 8299194: CustomTzIDCheckDST.java may fail at future date Reviewed-by: naoto ! test/jdk/java/util/TimeZone/CustomTzIDCheckDST.java Changeset: 2294f225 Author: Jonathan Gibbons Date: 2022-12-22 21:20:43 +0000 URL: https://git.openjdk.org/loom/commit/2294f225c074516abd2fecf5c64e2e1a2453bc6f 8286311: remove boilerplate from use of runTests Reviewed-by: hannesw ! test/langtools/jdk/javadoc/doclet/5093723/T5093723.java ! test/langtools/jdk/javadoc/doclet/AccessAsciiArt/AccessAsciiArt.java ! test/langtools/jdk/javadoc/doclet/AccessH1/AccessH1.java ! test/langtools/jdk/javadoc/doclet/AccessSkipNav/AccessSkipNav.java ! test/langtools/jdk/javadoc/doclet/AccessSummary/AccessSummary.java ! test/langtools/jdk/javadoc/doclet/AuthorDD/AuthorDD.java ! test/langtools/jdk/javadoc/doclet/DocRootSlash/DocRootSlash.java ! test/langtools/jdk/javadoc/doclet/InheritDocForUserTags/DocTest.java ! test/langtools/jdk/javadoc/doclet/JavascriptWinTitle/JavascriptWinTitle.java ! test/langtools/jdk/javadoc/doclet/MetaTag/MetaTag.java ! test/langtools/jdk/javadoc/doclet/T6735320/T6735320.java ! test/langtools/jdk/javadoc/doclet/ValidHtml/ValidHtml.java ! test/langtools/jdk/javadoc/doclet/VersionNumber/VersionNumber.java ! test/langtools/jdk/javadoc/doclet/WindowTitles/WindowTitles.java ! test/langtools/jdk/javadoc/doclet/constantValues/TestConstantValuesDriver.java ! test/langtools/jdk/javadoc/doclet/dupThrowsTags/TestDupThrowsTags.java ! test/langtools/jdk/javadoc/doclet/testAbsLinkPath/TestAbsLinkPath.java ! test/langtools/jdk/javadoc/doclet/testAbstractMethod/TestAbstractMethod.java ! test/langtools/jdk/javadoc/doclet/testAnchorNames/TestAnchorNames.java ! test/langtools/jdk/javadoc/doclet/testAnnotationOptional/TestAnnotationOptional.java ! test/langtools/jdk/javadoc/doclet/testAnnotationTypes/TestAnnotationTypes.java ! test/langtools/jdk/javadoc/doclet/testAuthor/TestAuthor.java ! test/langtools/jdk/javadoc/doclet/testAutoHeaderId/TestAutoHeaderId.java ! test/langtools/jdk/javadoc/doclet/testAutoLoadTaglets/TestAutoLoadTaglets.java ! test/langtools/jdk/javadoc/doclet/testBackSlashInLink/TestBackSlashInLink.java ! test/langtools/jdk/javadoc/doclet/testBadHtml/TestBadHtml.java ! test/langtools/jdk/javadoc/doclet/testBadPackageFileInJar/TestBadPackageFileInJar.java ! test/langtools/jdk/javadoc/doclet/testBadSourceFile/TestBadSourceFile.java ! test/langtools/jdk/javadoc/doclet/testBaseClass/TestBaseClass.java ! test/langtools/jdk/javadoc/doclet/testBimodalTaglets/TestBimodalTaglets.java ! test/langtools/jdk/javadoc/doclet/testBreakIterator/TestBreakIterator.java ! test/langtools/jdk/javadoc/doclet/testCRLineSeparator/TestCRLineSeparator.java ! test/langtools/jdk/javadoc/doclet/testCharset/TestCharset.java ! test/langtools/jdk/javadoc/doclet/testCharsetDocencodingOptions/TestCharsetDocencodingOptions.java ! test/langtools/jdk/javadoc/doclet/testClassCrossReferences/TestClassCrossReferences.java ! test/langtools/jdk/javadoc/doclet/testClassLinks/TestClassLinks.java ! test/langtools/jdk/javadoc/doclet/testClassTree/TestClassTree.java ! test/langtools/jdk/javadoc/doclet/testCmndLineClass/TestCmndLineClass.java ! test/langtools/jdk/javadoc/doclet/testCompletionFailure/TestCompletionFailure.java ! test/langtools/jdk/javadoc/doclet/testConditionalPages/TestConditionalPages.java ! test/langtools/jdk/javadoc/doclet/testConstantValuesPage/TestConstantValuesPage.java ! test/langtools/jdk/javadoc/doclet/testConstructorIndent/TestConstructorIndent.java ! test/langtools/jdk/javadoc/doclet/testConstructors/TestConstructors.java ! test/langtools/jdk/javadoc/doclet/testCopyFiles/TestCopyFiles.java ! test/langtools/jdk/javadoc/doclet/testCustomTagletRegistration/TestRegistrationErrors.java ! test/langtools/jdk/javadoc/doclet/testDateOption/TestDateOption.java ! test/langtools/jdk/javadoc/doclet/testDeprecatedDocs/TestDeprecatedDocs.java ! test/langtools/jdk/javadoc/doclet/testDiagsLineCaret/TestDiagsLineCaret.java ! test/langtools/jdk/javadoc/doclet/testDocEncoding/TestDocEncoding.java ! test/langtools/jdk/javadoc/doclet/testDocErrorReporter/TestDocErrorReporter.java ! test/langtools/jdk/javadoc/doclet/testDocFileDir/TestDocFileDir.java ! test/langtools/jdk/javadoc/doclet/testDocFiles/TestDocFiles.java ! test/langtools/jdk/javadoc/doclet/testDocLintOption/TestDocLintOption.java ! test/langtools/jdk/javadoc/doclet/testDocPaths/TestDocPaths.java ! test/langtools/jdk/javadoc/doclet/testDocRootInlineTag/TestDocRootInlineTag.java ! test/langtools/jdk/javadoc/doclet/testDocRootLink/TestDocRootLink.java ! test/langtools/jdk/javadoc/doclet/testDocTreeDiags/TestDocTreeDiags.java ! test/langtools/jdk/javadoc/doclet/testDoclintDocletMessages/TestDocLintDocletMessages.java ! test/langtools/jdk/javadoc/doclet/testDupParamWarn/TestDupParamWarn.java ! test/langtools/jdk/javadoc/doclet/testEmptyClass/TestEmptyClass.java ! test/langtools/jdk/javadoc/doclet/testEmptyInheritDoc/TestEmptyInheritDoc.java ! test/langtools/jdk/javadoc/doclet/testEnclosingClass/TestEnclosingClass.java ! test/langtools/jdk/javadoc/doclet/testEncoding/TestEncoding.java ! test/langtools/jdk/javadoc/doclet/testEnumConstructor/TestEnumConstructor.java ! test/langtools/jdk/javadoc/doclet/testExceptionInheritance/TestExceptionInheritance.java ! test/langtools/jdk/javadoc/doclet/testExternalOverriddenMethod/TestExternalOverriddenMethod.java ! test/langtools/jdk/javadoc/doclet/testGeneratedBy/TestGeneratedBy.java ! test/langtools/jdk/javadoc/doclet/testGeneratedClasses/TestGeneratedClasses.java ! test/langtools/jdk/javadoc/doclet/testGenericMethodLinkTaglet/TestGenericMethodLinkTaglet.java ! test/langtools/jdk/javadoc/doclet/testGrandParentTypes/TestGrandParentTypes.java ! test/langtools/jdk/javadoc/doclet/testGroupName/TestGroupName.java ! test/langtools/jdk/javadoc/doclet/testGroupOption/TestGroupOption.java ! test/langtools/jdk/javadoc/doclet/testHeadTag/TestHeadTag.java ! test/langtools/jdk/javadoc/doclet/testHeadings/TestHeadings.java ! test/langtools/jdk/javadoc/doclet/testHelpFile/TestHelpFile.java ! test/langtools/jdk/javadoc/doclet/testHelpOption/TestHelpOption.java ! test/langtools/jdk/javadoc/doclet/testHelpPage/TestHelpPage.java ! test/langtools/jdk/javadoc/doclet/testHiddenMembers/TestHiddenMembers.java ! test/langtools/jdk/javadoc/doclet/testHiddenTag/TestHiddenTag.java ! test/langtools/jdk/javadoc/doclet/testHref/TestHref.java ! test/langtools/jdk/javadoc/doclet/testHrefInDocComment/TestHrefInDocComment.java ! test/langtools/jdk/javadoc/doclet/testHtml4Removal/TestHtml4Removal.java ! test/langtools/jdk/javadoc/doclet/testHtmlComments/TestHtmlComments.java ! test/langtools/jdk/javadoc/doclet/testHtmlDefinitionListTag/TestHtmlDefinitionListTag.java ! test/langtools/jdk/javadoc/doclet/testHtmlDocument/TestHtmlDocument.java ! test/langtools/jdk/javadoc/doclet/testHtmlLandmarkRegions/TestHtmlLandmarkRegions.java ! test/langtools/jdk/javadoc/doclet/testHtmlStrongTag/TestHtmlStrongTag.java ! test/langtools/jdk/javadoc/doclet/testHtmlTableStyles/TestHtmlTableStyles.java ! test/langtools/jdk/javadoc/doclet/testHtmlTableTags/TestHtmlTableTags.java ! test/langtools/jdk/javadoc/doclet/testHtmlTag/TestHtmlTag.java ! test/langtools/jdk/javadoc/doclet/testHtmlVersion/TestHtmlVersion.java ! test/langtools/jdk/javadoc/doclet/testIOException/TestIOException.java ! test/langtools/jdk/javadoc/doclet/testIncluded/TestIncluded.java ! test/langtools/jdk/javadoc/doclet/testIndentation/TestIndentation.java ! test/langtools/jdk/javadoc/doclet/testIndex/TestIndex.java ! test/langtools/jdk/javadoc/doclet/testIndexFiles/TestIndexFiles.java ! test/langtools/jdk/javadoc/doclet/testIndexInDocFiles/TestIndexInDocFiles.java ! test/langtools/jdk/javadoc/doclet/testIndexInPackageFiles/TestIndexInPackageFiles.java ! test/langtools/jdk/javadoc/doclet/testIndexTaglet/TestIndexTaglet.java ! test/langtools/jdk/javadoc/doclet/testIndexWithModules/TestIndexWithModules.java ! test/langtools/jdk/javadoc/doclet/testInheritDocWithinInappropriateTag/TestInheritDocWithinInappropriateTag.java ! test/langtools/jdk/javadoc/doclet/testInherited/TestInherited.java ! test/langtools/jdk/javadoc/doclet/testInlineLinkLabel/TestInlineLinkLabel.java ! test/langtools/jdk/javadoc/doclet/testInterface/TestInterface.java ! test/langtools/jdk/javadoc/doclet/testJavaFX/TestFxProperties.java ! test/langtools/jdk/javadoc/doclet/testJavaFX/TestJavaFX.java ! test/langtools/jdk/javadoc/doclet/testJavaFX/TestJavaFXCombo.java ! test/langtools/jdk/javadoc/doclet/testJavaFX/TestJavaFXMissingPropComments.java ! test/langtools/jdk/javadoc/doclet/testJavaFX/TestJavaFxMode.java ! test/langtools/jdk/javadoc/doclet/testJavaPackage/TestJavaPackage.java ! test/langtools/jdk/javadoc/doclet/testJavascript/TestJavascript.java ! test/langtools/jdk/javadoc/doclet/testLeadingSpaces/LeadingSpaces.java ! test/langtools/jdk/javadoc/doclet/testLegacyTaglet/TestLegacyTaglet.java ! test/langtools/jdk/javadoc/doclet/testLegalNotices/TestLegalNotices.java ! test/langtools/jdk/javadoc/doclet/testLinkOption/TestBadLinkOption.java ! test/langtools/jdk/javadoc/doclet/testLinkOption/TestLinkOption.java ! test/langtools/jdk/javadoc/doclet/testLinkOption/TestLinkOptionWithAutomaticModule.java ! test/langtools/jdk/javadoc/doclet/testLinkOption/TestLinkOptionWithModule.java ! test/langtools/jdk/javadoc/doclet/testLinkOption/TestNewLineInLink.java ! test/langtools/jdk/javadoc/doclet/testLinkOption/TestOptionOrder.java ! test/langtools/jdk/javadoc/doclet/testLinkOption/TestRedirectLinks.java ! test/langtools/jdk/javadoc/doclet/testLinkPlatform/TestLinkPlatform.java ! test/langtools/jdk/javadoc/doclet/testLinkTaglet/TestLinkNotFound.java ! test/langtools/jdk/javadoc/doclet/testLinkTaglet/TestLinkTaglet.java ! test/langtools/jdk/javadoc/doclet/testLinkTaglet/TestLinkTagletPrimitive.java ! test/langtools/jdk/javadoc/doclet/testLinkTaglet/TestLinkTagletWithModule.java ! test/langtools/jdk/javadoc/doclet/testLinkToSerialForm/TestLinkToSerialForm.java ! test/langtools/jdk/javadoc/doclet/testLinksWithNoDeprecatedOption/TestLinksWithNoDeprecatedOption.java ! test/langtools/jdk/javadoc/doclet/testLists/TestLists.java ! test/langtools/jdk/javadoc/doclet/testLiteralCodeInPre/TestLiteralCodeInPre.java ! test/langtools/jdk/javadoc/doclet/testMemberInheritance/TestMemberInheritance.java ! test/langtools/jdk/javadoc/doclet/testMemberSummary/TestMemberSummary.java ! test/langtools/jdk/javadoc/doclet/testMetadata/TestMetadata.java ! test/langtools/jdk/javadoc/doclet/testMethodId/TestMethodId.java ! test/langtools/jdk/javadoc/doclet/testMethodSignature/TestMethodSignature.java ! test/langtools/jdk/javadoc/doclet/testMethodTypes/TestMethodTypes.java ! test/langtools/jdk/javadoc/doclet/testMissingComment/TestMissingComment.java ! test/langtools/jdk/javadoc/doclet/testMissingType/TestMissingType.java ! test/langtools/jdk/javadoc/doclet/testModifierEx/TestModifierEx.java ! test/langtools/jdk/javadoc/doclet/testModuleDirs/TestModuleDirs.java ! test/langtools/jdk/javadoc/doclet/testModuleSpecificStylesheet/TestModuleSpecificStylesheet.java ! test/langtools/jdk/javadoc/doclet/testModules/TestEmptyModule.java ! test/langtools/jdk/javadoc/doclet/testModules/TestIndirectExportsOpens.java ! test/langtools/jdk/javadoc/doclet/testModules/TestModulePackages.java ! test/langtools/jdk/javadoc/doclet/testModules/TestModuleServices.java ! test/langtools/jdk/javadoc/doclet/testModules/TestModuleServicesLink.java ! test/langtools/jdk/javadoc/doclet/testModules/TestModules.java ! test/langtools/jdk/javadoc/doclet/testNavigation/TestModuleNavigation.java ! test/langtools/jdk/javadoc/doclet/testNavigation/TestNavigation.java ! test/langtools/jdk/javadoc/doclet/testNestedClasses/TestNestedClasses.java ! test/langtools/jdk/javadoc/doclet/testNestedGenerics/TestNestedGenerics.java ! test/langtools/jdk/javadoc/doclet/testNestedInlineTags/TestNestedIndexTag.java ! test/langtools/jdk/javadoc/doclet/testNestedInlineTags/TestNestedLinkTag.java ! test/langtools/jdk/javadoc/doclet/testNestedInlineTags/TestNestedReturnTag.java ! test/langtools/jdk/javadoc/doclet/testNestedInlineTags/TestNestedSummaryTag.java ! test/langtools/jdk/javadoc/doclet/testNewLanguageFeatures/TestNewLanguageFeatures.java ! test/langtools/jdk/javadoc/doclet/testNoFrames/TestNoFrames.java ! test/langtools/jdk/javadoc/doclet/testNoPackagesFile/TestNoPackagesFile.java ! test/langtools/jdk/javadoc/doclet/testNonInlineHtmlTagRemoval/TestNonInlineHtmlTagRemoval.java ! test/langtools/jdk/javadoc/doclet/testNotifications/TestNotifications.java ! test/langtools/jdk/javadoc/doclet/testOptions/TestOptions.java ! test/langtools/jdk/javadoc/doclet/testOrdering/TestOrdering.java ! test/langtools/jdk/javadoc/doclet/testOverriddenMethods/TestBadOverride.java ! test/langtools/jdk/javadoc/doclet/testOverriddenMethods/TestMultiInheritance.java ! test/langtools/jdk/javadoc/doclet/testOverriddenMethods/TestOverriddenDeprecatedMethods.java ! test/langtools/jdk/javadoc/doclet/testOverriddenMethods/TestOverriddenMethodDocCopy.java ! test/langtools/jdk/javadoc/doclet/testOverriddenMethods/TestOverriddenPrivateMethods.java ! test/langtools/jdk/javadoc/doclet/testOverriddenMethods/TestOverriddenPrivateMethodsWithPackageFlag.java ! test/langtools/jdk/javadoc/doclet/testOverriddenMethods/TestOverriddenPrivateMethodsWithPrivateFlag.java ! test/langtools/jdk/javadoc/doclet/testOverriddenMethods/TestOverrideMethods.java ! test/langtools/jdk/javadoc/doclet/testOverview/TestOverview.java ! test/langtools/jdk/javadoc/doclet/testPackageAnnotation/TestPackageAnnotation.java ! test/langtools/jdk/javadoc/doclet/testPackageDeprecation/TestPackageDeprecation.java ! test/langtools/jdk/javadoc/doclet/testPackageDescription/TestPackageDescription.java ! test/langtools/jdk/javadoc/doclet/testPackageHtml/TestPackageHtml.java ! test/langtools/jdk/javadoc/doclet/testPackagePage/TestPackagePage.java ! test/langtools/jdk/javadoc/doclet/testPackageSpecificStylesheet/TestPackageSpecificStylesheet.java ! test/langtools/jdk/javadoc/doclet/testPackageSummary/TestPackageSummary.java ! test/langtools/jdk/javadoc/doclet/testParamTaglet/TestParamTaglet.java ! test/langtools/jdk/javadoc/doclet/testPreview/TestPreview.java ! test/langtools/jdk/javadoc/doclet/testPrivateClasses/TestPrivateClasses.java ! test/langtools/jdk/javadoc/doclet/testProperty/TestProperty.java ! test/langtools/jdk/javadoc/doclet/testRecordLinks/TestRecordLinks.java ! test/langtools/jdk/javadoc/doclet/testRecordTypes/TestRecordTypes.java ! test/langtools/jdk/javadoc/doclet/testRecurseSubPackages/TestRecurseSubPackages.java ! test/langtools/jdk/javadoc/doclet/testRelatedPackages/TestRelatedPackages.java ! test/langtools/jdk/javadoc/doclet/testRelativeLinks/TestRelativeLinks.java ! test/langtools/jdk/javadoc/doclet/testRelativeLinks/TestRelativeModuleLinks.java ! test/langtools/jdk/javadoc/doclet/testRepeatedAnnotations/TestRepeatedAnnotations.java ! test/langtools/jdk/javadoc/doclet/testReporterStreams/TestReporterStreams.java ! test/langtools/jdk/javadoc/doclet/testReturnTag/TestReturnTag.java ! test/langtools/jdk/javadoc/doclet/testSealedTypes/TestSealedTypes.java ! test/langtools/jdk/javadoc/doclet/testSearch/TestSearch.java ! test/langtools/jdk/javadoc/doclet/testSearchScript/TestSearchScript.java ! test/langtools/jdk/javadoc/doclet/testSeeLinkAnchor/TestSeeLinkAnchor.java ! test/langtools/jdk/javadoc/doclet/testSeeTag/TestSeeTag.java ! test/langtools/jdk/javadoc/doclet/testSeeTag/TestSeeTagWithModule.java ! test/langtools/jdk/javadoc/doclet/testSerialMissing/TestSerialMissing.java ! test/langtools/jdk/javadoc/doclet/testSerialTag/TestSerialTag.java ! test/langtools/jdk/javadoc/doclet/testSerialVersionUID/TestSerialVersionUID.java ! test/langtools/jdk/javadoc/doclet/testSerialWithLink/TestSerialWithLink.java ! test/langtools/jdk/javadoc/doclet/testSerializedForm/TestSerializedForm.java ! test/langtools/jdk/javadoc/doclet/testSerializedFormDeprecationInfo/TestSerializedFormDeprecationInfo.java ! test/langtools/jdk/javadoc/doclet/testSerializedFormWithClassFile/TestSerializedFormWithClassFile.java ! test/langtools/jdk/javadoc/doclet/testSerializedFormWithSee/TestSerializedFormWithSee.java ! test/langtools/jdk/javadoc/doclet/testSimpleTag/TestSimpleTag.java ! test/langtools/jdk/javadoc/doclet/testSimpleTagExclude/TestSimpleTagExclude.java ! test/langtools/jdk/javadoc/doclet/testSimpleTagInherit/TestSimpleTagInherit.java ! test/langtools/jdk/javadoc/doclet/testSinceTag/TestSinceTag.java ! test/langtools/jdk/javadoc/doclet/testSingleQuotedLink/TestSingleQuotedLink.java ! test/langtools/jdk/javadoc/doclet/testSingletonLists/TestSingletonLists.java ! test/langtools/jdk/javadoc/doclet/testSnippetTag/TestLangProperties.java ! test/langtools/jdk/javadoc/doclet/testSnippetTag/TestSnippetMarkup.java ! test/langtools/jdk/javadoc/doclet/testSnippetTag/TestSnippetPathOption.java ! test/langtools/jdk/javadoc/doclet/testSnippetTag/TestSnippetTag.java ! test/langtools/jdk/javadoc/doclet/testSourceTab/TestSourceTab.java ! test/langtools/jdk/javadoc/doclet/testSpecTag/TestSpecTag.java ! test/langtools/jdk/javadoc/doclet/testStylesheet/TestStylesheet.java ! test/langtools/jdk/javadoc/doclet/testStylesheetOverwrite/TestStylesheetOverwrite.java ! test/langtools/jdk/javadoc/doclet/testSubTitle/TestSubTitle.java ! test/langtools/jdk/javadoc/doclet/testSummaryHeading/TestSummaryHeading.java ! test/langtools/jdk/javadoc/doclet/testSummaryTag/TestSummaryTag.java ! test/langtools/jdk/javadoc/doclet/testSuperclassInSerialForm/TestSuperClassInSerialForm.java ! test/langtools/jdk/javadoc/doclet/testSupplementary/TestSupplementary.java ! test/langtools/jdk/javadoc/doclet/testSystemPropertyPage/TestSystemPropertyPage.java ! test/langtools/jdk/javadoc/doclet/testSystemPropertyTaglet/TestSystemPropertyTaglet.java ! test/langtools/jdk/javadoc/doclet/testTagInheritance/TestTagInheritance.java ! test/langtools/jdk/javadoc/doclet/testTagMisuse/TestTagMisuse.java ! test/langtools/jdk/javadoc/doclet/testTagOrder/TestTagOrder.java ! test/langtools/jdk/javadoc/doclet/testTagOutput/TestTagOutput.java ! test/langtools/jdk/javadoc/doclet/testTaglets/TestTaglets.java ! test/langtools/jdk/javadoc/doclet/testTerminology/TestTerminology.java ! test/langtools/jdk/javadoc/doclet/testThrows/TestThrows.java ! test/langtools/jdk/javadoc/doclet/testThrowsHead/TestThrowsHead.java ! test/langtools/jdk/javadoc/doclet/testThrowsInheritance/TestThrowsTagInheritance.java ! test/langtools/jdk/javadoc/doclet/testThrowsInheritanceMatching/TestExceptionTypeMatching.java ! test/langtools/jdk/javadoc/doclet/testThrowsInheritanceMultiple/TestOneToMany.java ! test/langtools/jdk/javadoc/doclet/testThrowsTag/TestThrowsTag.java ! test/langtools/jdk/javadoc/doclet/testTitleInHref/TestTitleInHref.java ! test/langtools/jdk/javadoc/doclet/testTopOption/TestTopOption.java ! test/langtools/jdk/javadoc/doclet/testTypeAnnotations/TestTypeAnnotations.java ! test/langtools/jdk/javadoc/doclet/testTypeParams/TestTypeParameters.java ! test/langtools/jdk/javadoc/doclet/testTypeVariableLinks/TestTypeVariableLinks.java ! test/langtools/jdk/javadoc/doclet/testUnicode/TestUnicode.java ! test/langtools/jdk/javadoc/doclet/testUnnamedPackage/TestUnnamedPackage.java ! test/langtools/jdk/javadoc/doclet/testUseOption/TestUseOption.java ! test/langtools/jdk/javadoc/doclet/testUserTaglet/TestUserTaglet.java ! test/langtools/jdk/javadoc/doclet/testValueTag/TestValueFormats.java ! test/langtools/jdk/javadoc/doclet/testValueTag/TestValueTag.java ! test/langtools/jdk/javadoc/doclet/testValueTag/TestValueTagInModule.java ! test/langtools/jdk/javadoc/doclet/testVersionOption/TestVersionOption.java ! test/langtools/jdk/javadoc/doclet/testVersionTag/TestVersionTag.java ! test/langtools/jdk/javadoc/doclet/testVisibleMembers/TestVisibleMembers.java ! test/langtools/jdk/javadoc/doclet/testWarnBadParamNames/TestWarnBadParamNames.java ! test/langtools/jdk/javadoc/doclet/testWarnings/TestWarnings.java ! test/langtools/jdk/javadoc/doclet/testXOption/TestXOption.java ! test/langtools/jdk/javadoc/doclet/typeAnnotations/smoke/TestSmoke.java ! test/langtools/jdk/javadoc/lib/javadoc/tester/JavadocTester.java ! test/langtools/jdk/javadoc/testJavadocTester/TestJavadocTester.java ! test/langtools/jdk/javadoc/testJavadocTester/TestJavadocTesterCrash.java ! test/langtools/jdk/javadoc/testTFMBuilder/TestTFMBuilder.java ! test/langtools/jdk/javadoc/tool/8224612/OptionsTest.java ! test/langtools/jdk/javadoc/tool/8224613/OptionProcessingFailureTest.java ! test/langtools/jdk/javadoc/tool/CommandLineHelpTest.java ! test/langtools/jdk/javadoc/tool/exceptionHandling/TestExceptionHandling.java ! test/langtools/jdk/javadoc/tool/removeOldDoclet/RemoveOldDoclet.java ! test/langtools/jdk/javadoc/tool/reporter_generates_warnings/ReporterGeneratesWarningsInsteadOfNotes.java ! test/langtools/jdk/javadoc/tool/testToolStreams/TestToolStreams.java ! test/langtools/jdk/javadoc/tool/testWErrorOption/TestWErrorOption.java Changeset: 2f4098e1 Author: Xiaolin Zheng Committer: Fei Yang Date: 2022-12-23 09:22:39 +0000 URL: https://git.openjdk.org/loom/commit/2f4098e1dc9c97e706d70008e473f9c4496cbc8a 8299168: RISC-V: Fix MachNode size mismatch for MacroAssembler::_verify_oops* Reviewed-by: fyang ! src/hotspot/cpu/riscv/macroAssembler_riscv.cpp Changeset: fef70d78 Author: Alexander Zuev Date: 2022-12-22 00:12:15 +0000 URL: https://git.openjdk.org/loom/commit/fef70d78baec9ce11d50b9a4c1fb26a1b854ccbf 8299077: [REDO] JDK-4512626 Non-editable JTextArea provides no visual indication of keyboard focus 8299127: [REDO] JDK-8194048 Regression automated test '/open/test/jdk/javax/swing/text/DefaultCaret/HidingSelection/HidingSelectionTest.java' fails 8299128: [REDO] JDK-8213562 Test javax/swing/text/DefaultCaret/HidingSelection/MultiSelectionTest.java fails Reviewed-by: aivanov, azvegint ! src/java.desktop/share/classes/javax/swing/text/DefaultCaret.java ! test/jdk/ProblemList.txt ! test/jdk/javax/swing/text/DefaultCaret/HidingSelection/HidingSelectionTest.java ! test/jdk/javax/swing/text/DefaultCaret/HidingSelection/MultiSelectionTest.java Changeset: a0a09d56 Author: Roland Westrelin Date: 2022-12-22 08:56:00 +0000 URL: https://git.openjdk.org/loom/commit/a0a09d56ba4fc6133b423ad29d86fc99dd6dc19b 8298176: remove OpaqueZeroTripGuardPostLoop once main-loop disappears Reviewed-by: thartmann, chagedorn, kvn ! src/hotspot/share/opto/loopTransform.cpp ! src/hotspot/share/opto/opaquenode.hpp ! src/hotspot/share/opto/phaseX.cpp ! src/hotspot/share/opto/phaseX.hpp ! src/hotspot/share/opto/subnode.cpp ! src/hotspot/share/opto/subnode.hpp + test/hotspot/jtreg/compiler/loopopts/TestOpaqueZeroTripGuardPostLoopRemoval.java Changeset: 5e001d6f Author: Ajit Ghaisas Date: 2022-12-22 10:38:12 +0000 URL: https://git.openjdk.org/loom/commit/5e001d6ff34e2cc954f824117a73dd39f09a81c1 8299207: [Testbug] Add back test/jdk/java/awt/Graphics2D/DrawPrimitivesTest.java Co-authored-by: Alexey Ushakov Reviewed-by: jdv + test/jdk/java/awt/Graphics2D/DrawPrimitivesTest.java Changeset: 9863f59e Author: Chris Hegarty Date: 2022-12-22 12:49:25 +0000 URL: https://git.openjdk.org/loom/commit/9863f59e1db84f55dc9a1670cd73ec4bfc07bcb0 8299015: Ensure that HttpResponse.BodySubscribers.ofFile writes all bytes Backport-of: a7d6de71bb83c8715654f61dd166aad6e8dab847 ! src/java.net.http/share/classes/jdk/internal/net/http/ResponseSubscribers.java ! src/java.net.http/share/classes/jdk/internal/net/http/common/Utils.java ! test/jdk/java/net/httpclient/PathSubscriber/BodySubscriberOfFileTest.java Changeset: a80c91d0 Author: Mark Powers Committer: Sean Mullan Date: 2022-12-22 15:29:53 +0000 URL: https://git.openjdk.org/loom/commit/a80c91d0360864e34569b684cf159e2dcdebeaaf 8299230: Use https: in links Reviewed-by: jjg, mullan, xuelei ! src/java.base/share/classes/java/security/DrbgParameters.java ! src/java.base/share/classes/java/security/SecureRandom.java Changeset: 33042a49 Author: Stuart Marks Date: 2022-12-22 21:56:04 +0000 URL: https://git.openjdk.org/loom/commit/33042a49d75011958e5030679433e6b2a779d90a 8299237: add ArraysSupport.newLength test to a test group Reviewed-by: naoto ! test/jdk/TEST.groups Changeset: 19ce23c6 Author: Jesper Wilhelmsson Date: 2022-12-23 11:25:10 +0000 URL: https://git.openjdk.org/loom/commit/19ce23c6459a452c8d3856b9ed96bfa54a8346ae Merge ! src/hotspot/share/opto/loopTransform.cpp ! src/hotspot/share/opto/phaseX.cpp ! src/hotspot/share/opto/phaseX.hpp ! src/hotspot/share/opto/subnode.cpp ! test/jdk/ProblemList.txt ! test/jdk/TEST.groups ! src/hotspot/share/opto/loopTransform.cpp ! src/hotspot/share/opto/phaseX.cpp ! src/hotspot/share/opto/phaseX.hpp ! src/hotspot/share/opto/subnode.cpp ! test/jdk/ProblemList.txt ! test/jdk/TEST.groups Changeset: da75de31 Author: Xiaolin Zheng Committer: Fei Yang Date: 2022-12-23 11:54:00 +0000 URL: https://git.openjdk.org/loom/commit/da75de31841e4b50477774e9efc4f554e1f3e4c0 8299172: RISC-V: [TESTBUG] Fix stack alignment logic in jvmci RISCV64TestAssembler.java Reviewed-by: fyang ! test/hotspot/jtreg/compiler/jvmci/jdk.vm.ci.code.test/src/jdk/vm/ci/code/test/riscv64/RISCV64TestAssembler.java Changeset: fd746a2f Author: Artem Semenov Date: 2022-12-23 22:07:14 +0000 URL: https://git.openjdk.org/loom/commit/fd746a2fe0e4c1c056065da93e2be2d8bb4e5428 8298643: JNI call of getAccessibleRowWithIndex and getAccessibleColumnWithIndex on a wrong thread Reviewed-by: serb, kizune ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/TableAccessibility.m Changeset: 5e861e39 Author: Artem Semenov Date: 2022-12-23 22:28:41 +0000 URL: https://git.openjdk.org/loom/commit/5e861e3965ce110889c8a1782ab0260937dee6ee 8298645: JNI works with accessibleSelection on a wrong thread Reviewed-by: serb, kizune ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CAccessibility.java ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ComboBoxAccessibility.m Changeset: 26868c1a Author: Toshio Nakamura Date: 2022-12-24 14:26:42 +0000 URL: https://git.openjdk.org/loom/commit/26868c1ac471c3b305b1d15e3075de0baa9319d2 8299255: Unexpected round errors in FreetypeFontScaler Reviewed-by: prr, serb ! src/java.desktop/share/native/libfontmanager/freetypeScaler.c + test/jdk/java/awt/FontClass/FontScalerRoundTest.java Changeset: 188911c9 Author: Daniel D. Daugherty Date: 2022-12-23 13:51:58 +0000 URL: https://git.openjdk.org/loom/commit/188911c925e4067c7f912c5ddb6f715bad7a3892 8299241: jdk/jfr/api/consumer/streaming/TestJVMCrash.java generates unnecessary core file Reviewed-by: coleenp ! test/jdk/jdk/jfr/api/consumer/streaming/TestJVMCrash.java ! test/jdk/jdk/jfr/api/consumer/streaming/TestProcess.java Changeset: 19373b2f Author: Jesper Wilhelmsson Date: 2022-12-25 01:56:28 +0000 URL: https://git.openjdk.org/loom/commit/19373b2ff0cd795afa262c17dcb3388fd6a5be59 Merge Changeset: 04591595 Author: Yi Yang Date: 2022-12-26 02:16:06 +0000 URL: https://git.openjdk.org/loom/commit/04591595374e84cfbfe38d92bff4409105b28009 8288204: GVN Crash: assert() failed: correct memory chain Reviewed-by: kvn, thartmann ! src/hotspot/share/opto/cfgnode.cpp ! src/hotspot/share/opto/memnode.cpp + test/hotspot/jtreg/compiler/c2/TestGVNCrash.java Changeset: 11fd651a Author: Alan Bateman Date: 2022-12-27 07:51:04 +0000 URL: https://git.openjdk.org/loom/commit/11fd651ab1820770e3c65cd49589416098987a87 8298875: A module requiring "java.base" with flags ACC_SYNTHETIC should be rejected Reviewed-by: jpai, mchung ! src/java.base/share/classes/jdk/internal/module/ModuleInfo.java ! test/jdk/java/lang/module/ModuleDescriptorTest.java Changeset: d490f15e Author: Matthias Baesken Date: 2022-12-28 08:28:02 +0000 URL: https://git.openjdk.org/loom/commit/d490f15e3b8222d0ba80e2161cc3f063092fc460 8235297: sun/security/ssl/SSLSessionImpl/ResumptionUpdateBoundValues.java fails intermittent Reviewed-by: xuelei ! test/jdk/sun/security/ssl/SSLSessionImpl/ResumptionUpdateBoundValues.java Changeset: 6f85a9c9 Author: Matthias Baesken Date: 2022-12-28 14:22:43 +0000 URL: https://git.openjdk.org/loom/commit/6f85a9c9a8ea3f76575acb4964cd80219822f073 8299387: CompressedClassPointers.java still fails on ppc with 'Narrow klass shift: 0' missing Reviewed-by: mdoerr ! test/hotspot/jtreg/runtime/CompressedOops/CompressedClassPointers.java Changeset: 684e5069 Author: Daniel Jeli?ski Date: 2022-12-30 06:40:27 +0000 URL: https://git.openjdk.org/loom/commit/684e50690c54fb93cb411553a8798cce041faac9 8299260: libawt and libfreetype should export only explicitly requested symbols Reviewed-by: prr, aivanov, serb ! make/common/modules/LibCommon.gmk ! make/modules/java.desktop/lib/Awt2dLibraries.gmk Changeset: c2e3d728 Author: Matthias Baesken Date: 2022-12-30 07:43:32 +0000 URL: https://git.openjdk.org/loom/commit/c2e3d7284814cd6b49f44b4de18e0f92310422b0 8299388: java/util/regex/NegativeArraySize.java fails on Alpine and sometimes Windows Reviewed-by: mdoerr, alanb ! test/jdk/java/util/regex/NegativeArraySize.java Changeset: 2ee34f14 Author: Abhishek Kumar Committer: Jayathirth D V Date: 2023-01-02 06:03:12 +0000 URL: https://git.openjdk.org/loom/commit/2ee34f14880cccca02e2933f80b000979f33c6d1 4912623: GTK L&F: Folder list of the JFileChooser is allowing multiple selection unlike native Reviewed-by: psadhukhan, jdv, serb ! src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKFileChooserUI.java + test/jdk/com/sun/java/swing/plaf/gtk/TestFileChooserCtrlASelection.java Changeset: 18ff1f5a Author: Prasanta Sadhukhan Date: 2023-01-02 09:49:51 +0000 URL: https://git.openjdk.org/loom/commit/18ff1f5a055deb29f56f16e0fb6bbe3f5c7e4169 6257207: JTable.getDefaultEditor throws NullPointerException Reviewed-by: tr, dnguyen, aivanov, serb ! src/java.desktop/share/classes/javax/swing/JTable.java + test/jdk/javax/swing/JTable/JTableEditorNPE.java Changeset: 95d4db3a Author: Matthias Baesken Date: 2023-01-02 11:16:18 +0000 URL: https://git.openjdk.org/loom/commit/95d4db3a92228d0211fa369c7d12d54234b22f72 8299424: containers/docker/TestMemoryWithCgroupV1.java fails on SLES12 ppc64le when testing Memory and Swap Limit Reviewed-by: mdoerr ! test/hotspot/jtreg/containers/docker/TestMemoryWithCgroupV1.java Changeset: d8120228 Author: Justin King Committer: Thomas Schatzl Date: 2023-01-02 12:00:39 +0000 URL: https://git.openjdk.org/loom/commit/d812022890815c33031905e7ec489b8729a45d90 8299398: Remove metaprogramming/isConst.hpp Reviewed-by: kbarrett, iwalulya, tschatzl ! src/hotspot/share/gc/shared/oopStorage.inline.hpp - src/hotspot/share/metaprogramming/isConst.hpp - test/hotspot/gtest/metaprogramming/test_isConst.cpp Changeset: 0532045e Author: Jorn Vernee Date: 2023-01-02 12:06:26 +0000 URL: https://git.openjdk.org/loom/commit/0532045edb709a995a42c07d95cb1cbabe886bed 8298590: Refactor LambdaForm constructors Reviewed-by: redestad ! src/java.base/share/classes/java/lang/invoke/DelegatingMethodHandle.java ! src/java.base/share/classes/java/lang/invoke/DirectMethodHandle.java ! src/java.base/share/classes/java/lang/invoke/Invokers.java ! src/java.base/share/classes/java/lang/invoke/LambdaForm.java ! src/java.base/share/classes/java/lang/invoke/LambdaFormBuffer.java ! src/java.base/share/classes/java/lang/invoke/LambdaFormEditor.java ! src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/java.base/share/classes/java/lang/invoke/NativeMethodHandle.java Changeset: e09e2431 Author: Per Minborg Committer: Jaikiran Pai Date: 2023-01-02 13:22:19 +0000 URL: https://git.openjdk.org/loom/commit/e09e243116545a7c1324bfcc145c94fbc25c7d59 8299187: (bf) ByteOrder.name should be declared final Reviewed-by: jpai ! src/java.base/share/classes/java/nio/ByteOrder.java Changeset: 8a10eef4 Author: Per Minborg Committer: Jaikiran Pai Date: 2023-01-02 13:25:04 +0000 URL: https://git.openjdk.org/loom/commit/8a10eef408f10d1a6d698a6f74942111b72d0765 8299193: (bf) Buffer.capacity should be declared final Reviewed-by: rriggs, dholmes, jpai ! src/java.base/share/classes/java/nio/Buffer.java Changeset: c252a85f Author: Albert Mingkun Yang Date: 2023-01-02 14:01:34 +0000 URL: https://git.openjdk.org/loom/commit/c252a85fb0c291f3eef8f049a2ca7d0c51d2e0d1 8298652: G1: Refactor G1MarkAndPushClosure Reviewed-by: iwalulya, tschatzl ! src/hotspot/share/gc/g1/g1FullGCMarker.cpp ! src/hotspot/share/gc/g1/g1FullGCMarker.hpp ! src/hotspot/share/gc/g1/g1FullGCMarker.inline.hpp ! src/hotspot/share/gc/g1/g1FullGCOopClosures.hpp ! src/hotspot/share/gc/g1/g1FullGCOopClosures.inline.hpp Changeset: 9d3d0399 Author: Justin King Committer: Thomas Schatzl Date: 2023-01-02 14:16:26 +0000 URL: https://git.openjdk.org/loom/commit/9d3d03997e9eb283bd58c8ea740e62689334966a 8299402: Remove metaprogramming/isVolatile.hpp Reviewed-by: kbarrett, iwalulya, tschatzl - src/hotspot/share/metaprogramming/isVolatile.hpp ! src/hotspot/share/oops/accessBackend.hpp - test/hotspot/gtest/metaprogramming/test_isVolatile.cpp Changeset: 532ccdb6 Author: Justin King Committer: Thomas Schatzl Date: 2023-01-02 14:33:44 +0000 URL: https://git.openjdk.org/loom/commit/532ccdb61a4b7dce9ad1141cef78c4f6be8d2f5a 8299396: Remove metaprogramming/removeExtent.hpp Reviewed-by: kbarrett, iwalulya, tschatzl ! src/hotspot/share/gc/z/zSafeDelete.hpp - src/hotspot/share/metaprogramming/removeExtent.hpp - test/hotspot/gtest/metaprogramming/test_removeExtent.cpp Changeset: 71a64a1b Author: Justin King Committer: Thomas Schatzl Date: 2023-01-02 14:34:44 +0000 URL: https://git.openjdk.org/loom/commit/71a64a1b7afea4d214f4fe8f0c0085aa959b6d09 8299399: Remove metaprogramming/isArray.hpp Reviewed-by: kbarrett, iwalulya, tschatzl ! src/hotspot/share/gc/z/zSafeDelete.inline.hpp - src/hotspot/share/metaprogramming/isArray.hpp - test/hotspot/gtest/metaprogramming/test_isArray.cpp Changeset: ce6395a1 Author: Justin King Committer: Thomas Schatzl Date: 2023-01-02 14:36:01 +0000 URL: https://git.openjdk.org/loom/commit/ce6395a1356a3d1334aeffc70ac8e4f86dd81a4c 8299397: Remove metaprogramming/isFloatingPoint.hpp Reviewed-by: kbarrett, iwalulya, tschatzl - src/hotspot/share/metaprogramming/isFloatingPoint.hpp ! src/hotspot/share/oops/accessBackend.hpp - test/hotspot/gtest/metaprogramming/test_isFloatingPoint.cpp Changeset: 67086ebf Author: Albert Mingkun Yang Date: 2023-01-02 14:59:11 +0000 URL: https://git.openjdk.org/loom/commit/67086ebf80109a623f3c2ad24d4e1a65de43d986 8299030: Refactor ReservedSpace::reserve Reviewed-by: dholmes, tschatzl ! src/hotspot/share/memory/virtualspace.cpp Changeset: 5b5552ff Author: David Holmes Date: 2023-01-02 23:34:20 +0000 URL: https://git.openjdk.org/loom/commit/5b5552ff2a5fccaa9a34886d9df4c0075fc8f5e8 8299483: ProblemList java/text/Format/NumberFormat/CurrencyFormat.java Reviewed-by: lancea ! test/jdk/ProblemList.txt Changeset: 417d01ea Author: Jaikiran Pai Date: 2023-01-03 01:58:49 +0000 URL: https://git.openjdk.org/loom/commit/417d01ea63261afb4fb29b4d11de799f2c0846d7 8299441: Fix typos in some test files under core-libs component Co-authored-by: Michael Ernst Reviewed-by: lancea ! test/jdk/javax/script/GetInterfaceTest.java ! test/jdk/javax/sql/testng/test/rowset/cachedrowset/CommonCachedRowSetTests.java ! test/jdk/javax/sql/testng/test/rowset/serial/SerialDataLinkTests.java ! test/micro/org/openjdk/bench/java/lang/ArrayFiddle.java Changeset: 37574333 Author: David Holmes Date: 2023-01-03 04:22:51 +0000 URL: https://git.openjdk.org/loom/commit/375743336dc15f9f945a03422eaa7ff773622cd8 8295974: jni_FatalError and Xcheck:jni warnings should print the native stack when there are no Java frames Reviewed-by: coleenp, rehn, sspitsyn ! make/test/JtregNativeHotspot.gmk ! src/hotspot/share/runtime/javaThread.cpp ! src/hotspot/share/runtime/javaThread.hpp ! src/hotspot/share/utilities/vmError.hpp + test/hotspot/jtreg/runtime/jni/nativeStack/TestNativeStack.java + test/hotspot/jtreg/runtime/jni/nativeStack/libnativeStack.c Changeset: 8afd665b Author: Justin King Committer: Thomas Schatzl Date: 2023-01-03 09:13:49 +0000 URL: https://git.openjdk.org/loom/commit/8afd665bf911ed9dc5d7c1f61f488ebe2f7b3cae 8299395: Remove metaprogramming/removeCV.hpp Reviewed-by: kbarrett, tschatzl ! src/hotspot/share/metaprogramming/decay.hpp ! src/hotspot/share/metaprogramming/isIntegral.hpp ! src/hotspot/share/metaprogramming/isSigned.hpp - src/hotspot/share/metaprogramming/removeCV.hpp ! src/hotspot/share/runtime/atomic.hpp - test/hotspot/gtest/metaprogramming/test_removeCV.cpp Changeset: a9ce7726 Author: Per Minborg Committer: Jaikiran Pai Date: 2023-01-03 10:00:19 +0000 URL: https://git.openjdk.org/loom/commit/a9ce7726a722c9deba659dff3f87b7e72d6c4997 8299437: Make InetSocketAddressHolder shallowly immutable Reviewed-by: djelinski, jpai, alanb ! src/java.base/share/classes/java/net/InetSocketAddress.java Changeset: 245f0cf4 Author: Aleksei Voitylov Committer: Martin Doerr Date: 2023-01-03 12:02:39 +0000 URL: https://git.openjdk.org/loom/commit/245f0cf4ac9dc655bfe2abb1c88c6ed1ddffd291 8291302: ARM32: nmethod entry barriers support Reviewed-by: eosterlund, rrich, mdoerr, aph ! src/hotspot/cpu/arm/arm.ad ! src/hotspot/cpu/arm/c1_MacroAssembler_arm.cpp ! src/hotspot/cpu/arm/gc/shared/barrierSetAssembler_arm.cpp ! src/hotspot/cpu/arm/gc/shared/barrierSetAssembler_arm.hpp ! src/hotspot/cpu/arm/gc/shared/barrierSetNMethod_arm.cpp ! src/hotspot/cpu/arm/macroAssembler_arm.hpp ! src/hotspot/cpu/arm/nativeInst_arm_32.hpp ! src/hotspot/cpu/arm/sharedRuntime_arm.cpp ! src/hotspot/cpu/arm/stubGenerator_arm.cpp ! src/hotspot/cpu/arm/stubRoutines_arm.cpp ! src/hotspot/cpu/arm/stubRoutines_arm.hpp ! src/hotspot/share/gc/shared/barrierSet.cpp Changeset: 37f8b059 Author: Jamil Nimeh Date: 2022-12-29 22:34:53 +0000 URL: https://git.openjdk.org/loom/commit/37f8b059c1c9245e7f3af90d6ed47c862fee54a3 8298592: Add java man page documentation for ChaCha20 and Poly1305 intrinsics Reviewed-by: weijun ! src/java.base/share/man/java.1 Changeset: a6a903d4 Author: Tobias Hartmann Date: 2023-01-03 08:21:22 +0000 URL: https://git.openjdk.org/loom/commit/a6a903d4b627bde85a311336ce25a7f5e25cf664 8288204: GVN Crash: assert() failed: correct memory chain Backport-of: 04591595374e84cfbfe38d92bff4409105b28009 ! src/hotspot/share/opto/cfgnode.cpp ! src/hotspot/share/opto/memnode.cpp + test/hotspot/jtreg/compiler/c2/TestGVNCrash.java Changeset: 3d0db02c Author: Jesper Wilhelmsson Date: 2023-01-03 13:10:15 +0000 URL: https://git.openjdk.org/loom/commit/3d0db02c76b91bfd0826ca27b1722b701b29d4d0 Merge ! src/java.base/share/man/java.1 ! src/java.base/share/man/java.1 Changeset: 92dfc735 Author: Ryan Wallace Committer: Weijun Wang Date: 2023-01-03 13:52:47 +0000 URL: https://git.openjdk.org/loom/commit/92dfc735f2297441a99b3e39464fb8f77a354d55 8294526: sun/security/provider/SubjectCodeSource.java no longer referenced Reviewed-by: weijun, xuelei - src/java.base/share/classes/sun/security/provider/SubjectCodeSource.java - test/jdk/sun/security/provider/PolicyFile/Comparator.Combined.Policy - test/jdk/sun/security/provider/PolicyFile/Comparator.Comparator.Policy - test/jdk/sun/security/provider/PolicyFile/Comparator.Principal.Policy - test/jdk/sun/security/provider/PolicyFile/Comparator.java Changeset: ea25a561 Author: Matthias Baesken Date: 2023-01-03 15:26:10 +0000 URL: https://git.openjdk.org/loom/commit/ea25a561c57cba63c5581aefa21f92ffd7386244 8299520: TestPrintXML.java output error messages in case compare fails Reviewed-by: mgronlun ! test/jdk/jdk/jfr/tool/TestPrintXML.java Changeset: 38cfc591 Author: Xue-Lei Andrew Fan Date: 2023-01-03 22:44:14 +0000 URL: https://git.openjdk.org/loom/commit/38cfc591725de478879266584280562f0ba4b42f 8299378: sprintf is deprecated in Xcode 14 Reviewed-by: kbarrett, dholmes ! test/hotspot/gtest/logging/test_logDecorators.cpp ! test/hotspot/gtest/logging/test_logMessageTest.cpp ! test/hotspot/gtest/utilities/test_unsigned5.cpp Changeset: 77ff1977 Author: Prasanta Sadhukhan Date: 2023-01-04 03:26:32 +0000 URL: https://git.openjdk.org/loom/commit/77ff19774651f1c41bbb1e59b2873d74522c8666 7030853: JDK 7 Serializable Swing classes not compatible with JDK 6 Reviewed-by: serb, aivanov ! src/java.desktop/share/classes/javax/swing/LayoutComparator.java ! src/java.desktop/share/classes/javax/swing/package-info.java ! src/java.desktop/share/classes/javax/swing/text/html/parser/ParserDelegator.java Changeset: 82deb5ca Author: Ioi Lam Date: 2023-01-04 04:03:43 +0000 URL: https://git.openjdk.org/loom/commit/82deb5ca615f70634f8cd84836265d01edd1c5a5 8298601: Refactor archiving of java.lang.Module objects Reviewed-by: coleenp, ccheung ! src/hotspot/share/cds/heapShared.cpp ! src/hotspot/share/cds/heapShared.hpp ! src/hotspot/share/classfile/classLoaderDataShared.cpp ! src/hotspot/share/classfile/classLoaderDataShared.hpp ! src/hotspot/share/classfile/moduleEntry.cpp ! src/hotspot/share/classfile/moduleEntry.hpp ! src/hotspot/share/classfile/modules.cpp ! src/hotspot/share/classfile/modules.hpp Changeset: 41900b57 Author: Daniel Jeli?ski Date: 2023-01-04 13:17:29 +0000 URL: https://git.openjdk.org/loom/commit/41900b57af084e0cfc1453681b24fe5606e11ab2 8189338: JMX RMI Remote Mbean server connection hangs if the server stops responding during a SSL Handshake Reviewed-by: smarks ! src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java ! test/jdk/java/rmi/transport/handshakeTimeout/HandshakeTimeout.java Changeset: e3035bad Author: Erik ?sterlund Date: 2023-01-04 14:31:07 +0000 URL: https://git.openjdk.org/loom/commit/e3035bad60dfa71e9c24fcc509cd7f07eb2bf62e 8299079: Better interface nmethod oop accesses Co-authored-by: Axel Boldt-Christmas Reviewed-by: kvn, dholmes ! src/hotspot/share/code/nmethod.cpp ! src/hotspot/share/oops/access.hpp ! src/hotspot/share/oops/accessDecorators.hpp Changeset: ccbcea83 Author: Coleen Phillimore Date: 2023-01-04 14:42:15 +0000 URL: https://git.openjdk.org/loom/commit/ccbcea830dc8d8b99c919d491adc60f7b4e8f28d 8299326: LinkResolver::resolve_field resolved_klass cannot be null Reviewed-by: iklam, fparain ! src/hotspot/share/interpreter/linkResolver.cpp ! src/hotspot/share/interpreter/linkResolver.hpp Changeset: c32a34c2 Author: Erik ?sterlund Date: 2023-01-04 14:49:44 +0000 URL: https://git.openjdk.org/loom/commit/c32a34c2e534147bccf8320b095edda9e1088f5a 8299072: java_lang_ref_Reference::clear_referent should be GC agnostic Co-authored-by: Axel Boldt-Christmas Reviewed-by: dholmes, shade, kbarrett ! src/hotspot/share/classfile/javaClasses.hpp ! src/hotspot/share/classfile/javaClasses.inline.hpp ! src/hotspot/share/gc/shared/referenceProcessor.cpp ! src/hotspot/share/gc/shenandoah/shenandoahReferenceProcessor.cpp ! src/hotspot/share/gc/z/zReferenceProcessor.cpp Changeset: c6588d5b Author: Yi-Fan Tsai Committer: Ludovic Henry Date: 2023-01-04 14:51:25 +0000 URL: https://git.openjdk.org/loom/commit/c6588d5bb3f778806c9112e86dbfba964c0636fd 8299158: Improve MD5 intrinsic on AArch64 Reviewed-by: luhenry, haosun, aph ! src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp Changeset: 4c0f24ef Author: Archie L. Cobbs Committer: Vicente Romero Date: 2023-01-04 16:00:22 +0000 URL: https://git.openjdk.org/loom/commit/4c0f24ef7108c889afdd4443d07e58c1798633cc 8064931: tools/javac/scope/DupUnsharedTest.java needs to be updated to add the bug id Reviewed-by: vromero ! test/langtools/tools/javac/scope/DupUnsharedTest.java Changeset: 6a07fd0e Author: Archie L. Cobbs Committer: Vicente Romero Date: 2023-01-04 16:01:59 +0000 URL: https://git.openjdk.org/loom/commit/6a07fd0ec1e6b57ffff852bcdc4f3304ac828018 8155259: Suspicious buffer allocation in com.sun.tools.javac.file.BaseFileManager 8172106: javac throws exception when compiling source file of size 1.5G Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/BaseFileManager.java Changeset: 3eb85d19 Author: Mark Powers Committer: Sean Mullan Date: 2023-01-03 15:41:55 +0000 URL: https://git.openjdk.org/loom/commit/3eb85d19ec80105bcbc5ad5422d694c29a9029d2 8299235: broken link referencing missing id Reviewed-by: mullan ! src/java.base/share/classes/java/security/KeyStore.java ! src/java.base/share/classes/javax/crypto/Cipher.java Changeset: 031829d8 Author: Erik Joelsson Date: 2023-01-03 21:07:19 +0000 URL: https://git.openjdk.org/loom/commit/031829d8854f2eae5f04d74bca515d58aab801ef 8298324: Unable to run shell test with make Reviewed-by: dholmes ! make/RunTests.gmk Changeset: 8254cbb2 Author: David Holmes Date: 2023-01-03 21:22:16 +0000 URL: https://git.openjdk.org/loom/commit/8254cbb21d164f39aa12020bfbd555d7535a428e 8299483: ProblemList java/text/Format/NumberFormat/CurrencyFormat.java Backport-of: 5b5552ff2a5fccaa9a34886d9df4c0075fc8f5e8 ! test/jdk/ProblemList.txt Changeset: b743519b Author: Kim Barrett Date: 2023-01-04 03:28:31 +0000 URL: https://git.openjdk.org/loom/commit/b743519ba911a254669fa8a96e6006c14e3f5ad1 8293824: gc/whitebox/TestConcMarkCycleWB.java failed "RuntimeException: assertTrue: expected true, was false" Reviewed-by: iwalulya, tschatzl ! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp ! src/hotspot/share/gc/g1/g1ConcurrentMark.hpp ! src/hotspot/share/gc/g1/g1ConcurrentMarkThread.cpp ! src/hotspot/share/prims/whitebox.cpp ! test/hotspot/jtreg/gc/g1/TestGCLogMessages.java ! test/hotspot/jtreg/gc/g1/TestHumongousRemsetsMatch.java ! test/hotspot/jtreg/gc/g1/TestMixedGCLiveThreshold.java ! test/hotspot/jtreg/gc/g1/TestNoEagerReclaimOfHumongousRegions.java ! test/hotspot/jtreg/gc/g1/TestRegionLivenessPrint.java ! test/hotspot/jtreg/gc/g1/TestRemarkCleanupMXBean.java ! test/hotspot/jtreg/gc/g1/TestSkipRebuildRemsetPhase.java ! test/hotspot/jtreg/gc/g1/TestVerifyGCType.java ! test/hotspot/jtreg/gc/g1/humongousObjects/TestHumongousClassLoader.java ! test/hotspot/jtreg/gc/g1/humongousObjects/TestObjectCollected.java ! test/hotspot/jtreg/gc/g1/humongousObjects/objectGraphTest/GC.java ! test/hotspot/jtreg/gc/g1/humongousObjects/objectGraphTest/GCTokens.java ! test/hotspot/jtreg/gc/stress/TestMultiThreadStressRSet.java ! test/hotspot/jtreg/gc/stress/TestStressRSetCoarsening.java ! test/hotspot/jtreg/gc/testlibrary/g1/MixedGCProvoker.java - test/hotspot/jtreg/gc/whitebox/TestConcMarkCycleWB.java ! test/hotspot/jtreg/runtime/ClassUnload/UnloadTestWithVerifyDuringGC.java ! test/jdk/com/sun/management/GarbageCollectorMXBean/GarbageCollectionNotificationContentTest.java ! test/jdk/com/sun/management/GarbageCollectorMXBean/GarbageCollectionNotificationTest.java ! test/lib/jdk/test/whitebox/WhiteBox.java Changeset: a17f505d Author: Aleksey Shipilev Date: 2023-01-04 10:46:34 +0000 URL: https://git.openjdk.org/loom/commit/a17f505d7351b0031d17c3ce8df3723b121a301e 8299476: PPC64 Zero build fails after JDK-8286302 Reviewed-by: mdoerr ! src/hotspot/share/runtime/continuationFreezeThaw.cpp Changeset: df1caf90 Author: Jesper Wilhelmsson Date: 2023-01-04 16:03:09 +0000 URL: https://git.openjdk.org/loom/commit/df1caf90818558b897a6b8ab80757f2a03398c55 Merge ! src/hotspot/share/prims/whitebox.cpp ! src/hotspot/share/runtime/continuationFreezeThaw.cpp ! test/hotspot/jtreg/gc/g1/TestGCLogMessages.java ! test/hotspot/jtreg/gc/g1/TestVerifyGCType.java ! src/hotspot/share/prims/whitebox.cpp ! src/hotspot/share/runtime/continuationFreezeThaw.cpp ! test/hotspot/jtreg/gc/g1/TestGCLogMessages.java ! test/hotspot/jtreg/gc/g1/TestVerifyGCType.java Changeset: b9758d22 Author: Archie L. Cobbs Committer: Vicente Romero Date: 2023-01-04 17:32:33 +0000 URL: https://git.openjdk.org/loom/commit/b9758d2201655cecfdda48660e77c598c52fcd9b 8200610: Compiling fails with java.nio.file.ReadOnlyFileSystemException Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java Changeset: 44be5edf Author: Archie L. Cobbs Committer: Vicente Romero Date: 2023-01-04 17:50:32 +0000 URL: https://git.openjdk.org/loom/commit/44be5edf5aa661169c665aa9386e5930a3632524 8219810: javac throws NullPointerException Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties + test/langtools/tools/javac/classreader/8219810/BadFieldFlags.jcod + test/langtools/tools/javac/classreader/8219810/BadFieldFlagsTest.java + test/langtools/tools/javac/classreader/8219810/BadFieldFlagsTest.out + test/langtools/tools/javac/classreader/8219810/BadMethodFlags.jcod + test/langtools/tools/javac/classreader/8219810/BadMethodFlagsTest.java + test/langtools/tools/javac/classreader/8219810/BadMethodFlagsTest.out ! test/langtools/tools/javac/diags/examples.not-yet.txt Changeset: 7dcc6899 Author: Michael Ernst Committer: Alexey Ivanov Date: 2023-01-04 19:59:45 +0000 URL: https://git.openjdk.org/loom/commit/7dcc689932ea276586282e0917f2efc10a598eb7 8299563: Fix typos Reviewed-by: lancea, aivanov, sspitsyn ! test/jaxp/javax/xml/jaxp/unittest/stream/XMLStreamReaderTest/XMLSchema.xsd ! test/jdk/javax/xml/jaxp/testng/parse/XMLEntityScannerLoad.java ! test/jdk/sun/jvmstat/testlibrary/utils.sh ! test/jdk/sun/management/jmxremote/bootstrap/JMXInterfaceBindingTest.java ! test/jdk/sun/misc/SunMiscSignalTest.java Changeset: 3b374c01 Author: Justin Lu Committer: Naoto Sato Date: 2023-01-04 21:59:02 +0000 URL: https://git.openjdk.org/loom/commit/3b374c0153950ab193f3a188b57d3404b4ce2fe2 8299439: java/text/Format/NumberFormat/CurrencyFormat.java fails for hr_HR Reviewed-by: naoto, lancea, jpai ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_hr_HR.properties ! test/jdk/ProblemList.txt ! test/jdk/java/text/Format/NumberFormat/CurrencySymbols.properties From arnaud.masson at fr.ibm.com Fri Jan 6 09:42:27 2023 From: arnaud.masson at fr.ibm.com (Arnaud Masson) Date: Fri, 6 Jan 2023 09:42:27 +0000 Subject: : Re: Project Loom VirtualThreads hang In-Reply-To: <01FFBDBC-2A4A-4CBB-BD8B-1C44D60BC145@oracle.com> References: <96631C23-9C63-4848-B310-C0521FB094E9@ix.netcom.com> <8AC301FC-6E3B-49CC-9215-E5CF0421AB16@ix.netcom.com> <1F382E46-A3AD-40B9-8895-292FC08D9031@oracle.com> <01FFBDBC-2A4A-4CBB-BD8B-1C44D60BC145@oracle.com> Message-ID: A long CPU-bound request (without any IO/yield) on a vthread would virtually ?pin? its native thread, which is a thing we don?t generally want, no? (A server can have both CPU-bound and IO-bound requests at the same time.) That would be a bit like blocking the even loop on NodeJS: https://nodejs.org/en/docs/guides/dont-block-the-event-loop/#blocking-the-event-loop-json-dos (mitigated by the fact there are more than 1 native thread to run vthreads in general). Wouldn?t vthread preemptive scheduling fix that? Otherwise, I guess we can insert manually Thread.yield in the slow CPU code but it?s not ideal: For (int i=0; i<99999999; i++) { Thread.yield(); // CPU-only stuff, or maybe old sync file IO } Arnaud > On 5 Jan 2023, at 19:02, Sam Pullara wrote: > > So the place where this comes up is when you do a short computation but use tons of threads to do it. Like, for example, I have a brute force embedding search library that uses parallel streams to do the query. If that takes a few seconds (or even hundreds of ms) I still want other threads doing more mundane, fast work to get CPU time rather than every other computation on the system being blocked. Virtual threads would behave the same way as platform threads in this case. First, there is no time-sharing among parallel stream tasks anyway today, but there is time-sharing between parallel streams and other threads, be they platform or virtual. Unless otherwise stated above: Compagnie IBM France Si?ge Social : 17, avenue de l'Europe, 92275 Bois-Colombes Cedex RCS Nanterre 552 118 465 Forme Sociale : S.A.S. Capital Social : 664 069 390,60 ? SIRET : 552 118 465 03644 - Code NAF 6203Z -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Fri Jan 6 10:08:40 2023 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 6 Jan 2023 10:08:40 +0000 Subject: : Re: Project Loom VirtualThreads hang In-Reply-To: References: <96631C23-9C63-4848-B310-C0521FB094E9@ix.netcom.com> <8AC301FC-6E3B-49CC-9215-E5CF0421AB16@ix.netcom.com> <1F382E46-A3AD-40B9-8895-292FC08D9031@oracle.com> <01FFBDBC-2A4A-4CBB-BD8B-1C44D60BC145@oracle.com> Message-ID: <05965053-f574-dca6-9993-be36c2a2bf13@oracle.com> On 06/01/2023 09:42, Arnaud Masson wrote: > > A long CPU-bound request (without any IO/yield) on a vthread would > virtually ?pin? its native thread, which is a thing we don?t generally > want, no? > > (A server can have both CPU-bound and IO-bound requests at the same time.) > > That would be a bit like blocking the even loop on NodeJS: > https://nodejs.org/en/docs/guides/dont-block-the-event-loop/#blocking-the-event-loop-json-dos > (mitigated by the fact there are more than 1 native thread to run > vthreads in general). > > Wouldn?t vthread preemptive scheduling fix that? > > Maybe but it needs a lot more real world usage of virtual threads to see if this is really needed. As Ron mentioned, custom schedulers on the list to re-visit and that may where the primitive to force preempt is exposed and allow people to experiment with time sharing if they want. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron.pressler at oracle.com Fri Jan 6 10:21:02 2023 From: ron.pressler at oracle.com (Ron Pressler) Date: Fri, 6 Jan 2023 10:21:02 +0000 Subject: : Re: Project Loom VirtualThreads hang In-Reply-To: References: <96631C23-9C63-4848-B310-C0521FB094E9@ix.netcom.com> <8AC301FC-6E3B-49CC-9215-E5CF0421AB16@ix.netcom.com> <1F382E46-A3AD-40B9-8895-292FC08D9031@oracle.com> <01FFBDBC-2A4A-4CBB-BD8B-1C44D60BC145@oracle.com> Message-ID: On 6 Jan 2023, at 09:42, Arnaud Masson > wrote: A long CPU-bound request (without any IO/yield) on a vthread would virtually ?pin? its native thread, which is a thing we don?t generally want, no? (A server can have both CPU-bound and IO-bound requests at the same time.) That would be a bit like blocking the even loop on NodeJS: https://nodejs.org/en/docs/guides/dont-block-the-event-loop/#blocking-the-event-loop-json-dos(mitigated by the fact there are more than 1 native thread to run vthreads in general). Wouldn?t vthread preemptive scheduling fix that? Otherwise, I guess we can insert manually Thread.yield in the slow CPU code but it?s not ideal: For (int i=0; i<99999999; i++) { Thread.yield(); // CPU-only stuff, or maybe old sync file IO } Arnaud First, virtual thread scheduling is already preemptive ? the JDK decides when to preempt a virtual thread without any explicit cooperation from user code. What you?re talking about is making the decision to preempt based on some expired time-slice on the CPU. This is called time-sharing. Second, no, this isn?t like Node.JS because the scheduler uses all cores. To saturate the scheduler you?d need to hog the CPU on *all* cores at the same time, i.e. reach 100% CPU utilisation. It is true that the kernel scheduler will employ time-sharing at 100% CPU while the virtual threads scheduler currently doesn?t, but servers don?t normally run at 100% CPU, and when they do I don?t think people are happy with how well they behave under that condition. I.e. the time-sharing offered by the OS is definitely useful for some things, but making servers work well at 100% CPU doesn?t appear to be one of them ? as far as we know. Time-sharing does help when you have a small number of low-priority background processing jobs running on the server, but unlike Erlang or Go, Java easily offers that without adding time-sharing to the virtual thread scheduler. So the question is, can time-sharing for virtual threads actually improve real workloads, and, if so, what should be the scheduling algorithm that would achieve that? To know the answer to this question, we?ll need to see real workloads that could potentially be helped by time-sharing. I haven?t seen one yet, but if anyone finds any, we?d certainly take a close look at that. As for file IO, we?re currently working on employing io_uring (where available) to make that properly block the virtual thread rather than the OS thread. By the way, the current implementation will actually temporarily increase the number of OS threads used by the scheduler when doing long filesystem operations. ? Ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnaud.masson at fr.ibm.com Fri Jan 6 10:36:38 2023 From: arnaud.masson at fr.ibm.com (Arnaud Masson) Date: Fri, 6 Jan 2023 10:36:38 +0000 Subject: : Re: Project Loom VirtualThreads hang In-Reply-To: <1025FBDC-680E-4173-A20E-702967EA5139@oracle.com> References: <1F382E46-A3AD-40B9-8895-292FC08D9031@oracle.com> <6471F28E-51D5-49F3-B59F-8BE1F22C4E37@ix.netcom.com> <1025FBDC-680E-4173-A20E-702967EA5139@oracle.com> Message-ID: I think what could be useful is to automatically add scheduling ?weight? on vthread in the context of structured concurrency. (A bit like CPU request/limit at pod level in Kubernetes.) For example, let?s say I have 2 vthreads on a server processing concurrent http requests (mostly CPU-bound). If one of them forks 2 sub tasks with a structured concurrency scope, I would like that the weights of the 2 requests remain globally constant: Initially: * request 1: weight 1.0 * request 2: weight 1.0 after fork: * request 1 (blocked waiting for sub tasks) * sub task 1: weight 0.5 * sub task 2: weight 0.5 * request 2: weight 1.0 if 3 cores available, the 3 actives tasks can run at 100% (and request1 will complete faster). If 2 cores only, request 2 would be at 100% on a core, and the 2 sub tasks of request1 would get 50% of a core each, so request1 forking won?t have negative impact on request 2. In other words, that would allow to optimize for multicore (inside a request handler) without breaking scheduling fairness. Thanks Arnaud > On 5 Jan 2023, at 21:24, Robert Engels wrote: > > I think it would be better to be able to park/unpark on a monitor efficiently. I think the overhead in handling that common case is more significant than expected. We know; it?s work-in-progress, but will take some time. > > I like the idea of carrying over the Thread.priority in vthreads to allow finer control over the scheduling. Scheduling with priorities can either be done well or fast but not both. Non-realtime kernels schedule relatively fast, but their priority implementation isn?t that good; realtime kernels do priorities well, but their scheduling is very slow (realtime always trades off predictability for speed). Respecting priorities becomes even harder when there are lots and lots of threads, and problems such as priority inversion certainly don?t get easier. For the common cases where you have a small set of low-priority threads doing work in the background, the easiest solution is just to use platform threads for those. As in the case of time-sharing, the need for priorities is something that will need to be demonstrated in real projects in the field to justify addressing. ? Ron Unless otherwise stated above: Compagnie IBM France Si?ge Social : 17, avenue de l'Europe, 92275 Bois-Colombes Cedex RCS Nanterre 552 118 465 Forme Sociale : S.A.S. Capital Social : 664 069 390,60 ? SIRET : 552 118 465 03644 - Code NAF 6203Z -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron.pressler at oracle.com Fri Jan 6 11:33:07 2023 From: ron.pressler at oracle.com (Ron Pressler) Date: Fri, 6 Jan 2023 11:33:07 +0000 Subject: : Re: Project Loom VirtualThreads hang In-Reply-To: References: <1F382E46-A3AD-40B9-8895-292FC08D9031@oracle.com> <6471F28E-51D5-49F3-B59F-8BE1F22C4E37@ix.netcom.com> <1025FBDC-680E-4173-A20E-702967EA5139@oracle.com> Message-ID: <0D78B2E9-3520-432B-8CF5-F9FAEE1E91C5@oracle.com> You are making the assumption that any kind of clever scheduling would be able to substantially improve server workloads at 100% CPU, but this hypothesis is yet to be demonstrated. To consider better scheduling algorithms, we first need to see real-world cases where the current scheduling causes a problem that requires a solution. We can?t solve a problem before we know what it is. What we?re looking for is something along the lines of: ?I have a server based on virtual threads, and I?ve run into the following scheduling-related problem: ?? I expect that such reports will take time to show up, as they require more widespread use of virtual threads in production (or even in integration testing). ? Ron On 6 Jan 2023, at 10:36, Arnaud Masson > wrote: I think what could be useful is to automatically add scheduling ?weight? on vthread in the context of structured concurrency. (A bit like CPU request/limit at pod level in Kubernetes.) For example, let?s say I have 2 vthreads on a server processing concurrent http requests (mostly CPU-bound). If one of them forks 2 sub tasks with a structured concurrency scope, I would like that the weights of the 2 requests remain globally constant: Initially: * request 1: weight 1.0 * request 2: weight 1.0 after fork: * request 1 (blocked waiting for sub tasks) * sub task 1: weight 0.5 * sub task 2: weight 0.5 * request 2: weight 1.0 if 3 cores available, the 3 actives tasks can run at 100% (and request1 will complete faster). If 2 cores only, request 2 would be at 100% on a core, and the 2 sub tasks of request1 would get 50% of a core each, so request1 forking won?t have negative impact on request 2. In other words, that would allow to optimize for multicore (inside a request handler) without breaking scheduling fairness. Thanks Arnaud > On 5 Jan 2023, at 21:24, Robert Engels > wrote: > > I think it would be better to be able to park/unpark on a monitor efficiently. I think the overhead in handling that common case is more significant than expected. We know; it?s work-in-progress, but will take some time. > > I like the idea of carrying over the Thread.priority in vthreads to allow finer control over the scheduling. Scheduling with priorities can either be done well or fast but not both. Non-realtime kernels schedule relatively fast, but their priority implementation isn?t that good; realtime kernels do priorities well, but their scheduling is very slow (realtime always trades off predictability for speed). Respecting priorities becomes even harder when there are lots and lots of threads, and problems such as priority inversion certainly don?t get easier. For the common cases where you have a small set of low-priority threads doing work in the background, the easiest solution is just to use platform threads for those. As in the case of time-sharing, the need for priorities is something that will need to be demonstrated in real projects in the field to justify addressing. ? Ron Unless otherwise stated above: Compagnie IBM France Si?ge Social : 17, avenue de l'Europe, 92275 Bois-Colombes Cedex RCS Nanterre 552 118 465 Forme Sociale : S.A.S. Capital Social : 664 069 390,60 ? SIRET : 552 118 465 03644 - Code NAF 6203Z -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnaud.masson at fr.ibm.com Fri Jan 6 11:49:22 2023 From: arnaud.masson at fr.ibm.com (Arnaud Masson) Date: Fri, 6 Jan 2023 11:49:22 +0000 Subject: : Re: Project Loom VirtualThreads hang In-Reply-To: References: <96631C23-9C63-4848-B310-C0521FB094E9@ix.netcom.com> <8AC301FC-6E3B-49CC-9215-E5CF0421AB16@ix.netcom.com> <1F382E46-A3AD-40B9-8895-292FC08D9031@oracle.com> <01FFBDBC-2A4A-4CBB-BD8B-1C44D60BC145@oracle.com> Message-ID: Sorry, I mean preemptive time sharing then. ? (From user perspective, right now Loom doesn?t _look_ preemptive even if it is under the hood since switch can occur only at specific points in user code unless I?m missing something.) As I said, it would not be as bad as the NodeJS example but still a similar problem: a native thread pinned by CPU-bound request. If I have a Kub pod with CPU limit 2, I send 4 CPU-bound http requests concurrently, I really expect them to run concurrently, not 2 then 2 ? it?s rather real world scenario. Especially since the 2 first might be longer, I can?t always know in advance. Sure, if you have 100% CPU usage all the time there is a problem, but that doesn?t mean incoming requests should be fully stuck as soon as 100% CPU usage is hit on a pod. (Note that 100% usage on Pod doesn?t mean 100% on the underlying worker node VM.) The problem here is not raw performance but scheduling fairness. In my opinion, for CPU-bound requests on vthreads, that would be even better to have slightly worse perf overall but maintain correct fairness. Otherwise, we will have to be concerned each time about running enough carrier/native threads to support possible worst-case concurrent CPU-bound requests ? compared with the awesome simplification Loom gives regarding blocked IO handling. From a different perspective: I think Loom cheap stack/thread parking could be useful also for CPU-bound tasks. It could allow more concurrent CPU-bound tasks to make progress without improving perf overall. Thanks Arnaud First, virtual thread scheduling is already preemptive ? the JDK decides when to preempt a virtual thread without any explicit cooperation from user code. What you?re talking about is making the decision to preempt based on some expired time-slice on the CPU. This is called time-sharing. Second, no, this isn?t like Node.JS because the scheduler uses all cores. To saturate the scheduler you?d need to hog the CPU on *all* cores at the same time, i.e. reach 100% CPU utilisation. It is true that the kernel scheduler will employ time-sharing at 100% CPU while the virtual threads scheduler currently doesn?t, but servers don?t normally run at 100% CPU, and when they do I don?t think people are happy with how well they behave under that condition. I.e. the time-sharing offered by the OS is definitely useful for some things, but making servers work well at 100% CPU doesn?t appear to be one of them ? as far as we know. Time-sharing does help when you have a small number of low-priority background processing jobs running on the server, but unlike Erlang or Go, Java easily offers that without adding time-sharing to the virtual thread scheduler. So the question is, can time-sharing for virtual threads actually improve real workloads, and, if so, what should be the scheduling algorithm that would achieve that? To know the answer to this question, we?ll need to see real workloads that could potentially be helped by time-sharing. I haven?t seen one yet, but if anyone finds any, we?d certainly take a close look at that. As for file IO, we?re currently working on employing io_uring (where available) to make that properly block the virtual thread rather than the OS thread. By the way, the current implementation will actually temporarily increase the number of OS threads used by the scheduler when doing long filesystem operations. ? Ron Unless otherwise stated above: Compagnie IBM France Si?ge Social : 17, avenue de l'Europe, 92275 Bois-Colombes Cedex RCS Nanterre 552 118 465 Forme Sociale : S.A.S. Capital Social : 664 069 390,60 ? SIRET : 552 118 465 03644 - Code NAF 6203Z -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnaud.masson at fr.ibm.com Fri Jan 6 12:04:25 2023 From: arnaud.masson at fr.ibm.com (Arnaud Masson) Date: Fri, 6 Jan 2023 12:04:25 +0000 Subject: : Re: Project Loom VirtualThreads hang In-Reply-To: <0D78B2E9-3520-432B-8CF5-F9FAEE1E91C5@oracle.com> References: <1F382E46-A3AD-40B9-8895-292FC08D9031@oracle.com> <6471F28E-51D5-49F3-B59F-8BE1F22C4E37@ix.netcom.com> <1025FBDC-680E-4173-A20E-702967EA5139@oracle.com> <0D78B2E9-3520-432B-8CF5-F9FAEE1E91C5@oracle.com> Message-ID: Well, weight for CPU share is what Kubernetes does at the Pod level for example. As discussed, if we don?t have such mechanism, a single request that is internally parallelized can have too much weight. I don?t say it?s a super urgent feature, it will just be as problematic as before ? I had this problem myself on prod some time ago, pre-loom, with classic threads. The consequence is that people tend to be very conservative and underutilize cores. Thanks Arnaud You are making the assumption that any kind of clever scheduling would be able to substantially improve server workloads at 100% CPU, but this hypothesis is yet to be demonstrated. To consider better scheduling algorithms, we first need to ZjQcmQRYFpfptBannerStart You are making the assumption that any kind of clever scheduling would be able to substantially improve server workloads at 100% CPU, but this hypothesis is yet to be demonstrated. To consider better scheduling algorithms, we first need to see real-world cases where the current scheduling causes a problem that requires a solution. We can?t solve a problem before we know what it is. What we?re looking for is something along the lines of: ?I have a server based on virtual threads, and I?ve run into the following scheduling-related problem: ?? I expect that such reports will take time to show up, as they require more widespread use of virtual threads in production (or even in integration testing). Unless otherwise stated above: Compagnie IBM France Si?ge Social : 17, avenue de l'Europe, 92275 Bois-Colombes Cedex RCS Nanterre 552 118 465 Forme Sociale : S.A.S. Capital Social : 664 069 390,60 ? SIRET : 552 118 465 03644 - Code NAF 6203Z -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron.pressler at oracle.com Fri Jan 6 13:42:29 2023 From: ron.pressler at oracle.com (Ron Pressler) Date: Fri, 6 Jan 2023 13:42:29 +0000 Subject: : Re: Project Loom VirtualThreads hang In-Reply-To: References: <96631C23-9C63-4848-B310-C0521FB094E9@ix.netcom.com> <8AC301FC-6E3B-49CC-9215-E5CF0421AB16@ix.netcom.com> <1F382E46-A3AD-40B9-8895-292FC08D9031@oracle.com> <01FFBDBC-2A4A-4CBB-BD8B-1C44D60BC145@oracle.com> Message-ID: <8F14EA4E-8B71-4306-9702-F8FAD7DBB4D5@oracle.com> On 6 Jan 2023, at 11:49, Arnaud Masson > wrote: As I said, it would not be as bad as the NodeJS example but still a similar problem: a native thread pinned by CPU-bound request. It is a phenomenon. Whether or not it?s a problem is still to be determined. If I have a Kub pod with CPU limit 2, I send 4 CPU-bound http requests concurrently, I really expect them to run concurrently, not 2 then 2 ? it?s rather real world scenario. And in most situations they will run in parallel, and in those they won?t, chances are that you won?t notice or it doesn?t matter as your server is already sputtering. Sure, if you have 100% CPU usage all the time there is a problem, but that doesn?t mean incoming requests should be fully stuck as soon as 100% CPU usage is hit on a pod. (Note that 100% usage on Pod doesn?t mean 100% on the underlying worker node VM.) The problem here is not raw performance but scheduling fairness. In my opinion, for CPU-bound requests on vthreads, that would be even better to have slightly worse perf overall but maintain correct fairness. Otherwise, we will have to be concerned each time about running enough carrier/native threads to support possible worst-case concurrent CPU-bound requests ? compared with the awesome simplification Loom gives regarding blocked IO handling. From a different perspective: I think Loom cheap stack/thread parking could be useful also for CPU-bound tasks. It could allow more concurrent CPU-bound tasks to make progress without improving perf overall. What you?re showing is not a problem. It?s a scenario that you hypothesise could be a problem, and then you further hypothesise that a certain mechanism would fix the hypothetical problem. But we can?t fix something until we see an actual problem and know what it is that requires fixing. In particular, I don?t know why you have to be preemptively concerned about a problem you have not seen, and that platform threads aren?t known to address either. In fact, virtual threads already give you better fairness than both platform thread pools and async code. So are you concerned that virtual threads will improve things but not to the extent you wish there was something that could? ? Ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnaud.masson at fr.ibm.com Fri Jan 6 14:39:02 2023 From: arnaud.masson at fr.ibm.com (Arnaud Masson) Date: Fri, 6 Jan 2023 14:39:02 +0000 Subject: : Re: Project Loom VirtualThreads hang In-Reply-To: <8F14EA4E-8B71-4306-9702-F8FAD7DBB4D5@oracle.com> References: <96631C23-9C63-4848-B310-C0521FB094E9@ix.netcom.com> <8AC301FC-6E3B-49CC-9215-E5CF0421AB16@ix.netcom.com> <1F382E46-A3AD-40B9-8895-292FC08D9031@oracle.com> <01FFBDBC-2A4A-4CBB-BD8B-1C44D60BC145@oracle.com> <8F14EA4E-8B71-4306-9702-F8FAD7DBB4D5@oracle.com> Message-ID: Ron, My concern is that Loom (in its current form) greatly improves scalability on IO-bound requests and but introduce a new fairness problem regarding CPU-bound request. Of course generally on web apps, most requests are IO-bound (http, jdbc) but I do have seen CPU-bound requests on prod (sometimes accidental). I don?t use Loom on prod today (I guess not a lot of people do since it?s still preview), so if you are asking if I see a production issue, answer is no. I suppose if I want to migrate to loom and be safe, I can increase the number of native carriers in the underlying pool (N >> core count). It?s just that if there was timesharing in Loom, I don?t see why vthreads would not be systematically used (almost blindly, for CPU-bound and IO-bound). I?m curious, when do you think preemptive time sharing (as implemented in various OSes for decades) is useful? thanks Arnaud What you?re showing is not a problem. It?s a scenario that you hypothesise could be a problem, and then you further hypothesise that a certain mechanism would fix the hypothetical problem. But we can?t fix something until we see an actual problem and know what it is that requires fixing. In particular, I don?t know why you have to be preemptively concerned about a problem you have not seen, and that platform threads aren?t known to address either. In fact, virtual threads already give you better fairness than both platform thread pools and async code. So are you concerned that virtual threads will improve things but not to the extent you wish there was something that could? ? Ron Unless otherwise stated above: Compagnie IBM France Si?ge Social : 17, avenue de l'Europe, 92275 Bois-Colombes Cedex RCS Nanterre 552 118 465 Forme Sociale : S.A.S. Capital Social : 664 069 390,60 ? SIRET : 552 118 465 03644 - Code NAF 6203Z -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron.pressler at oracle.com Fri Jan 6 15:50:00 2023 From: ron.pressler at oracle.com (Ron Pressler) Date: Fri, 6 Jan 2023 15:50:00 +0000 Subject: : Re: Project Loom VirtualThreads hang In-Reply-To: References: <96631C23-9C63-4848-B310-C0521FB094E9@ix.netcom.com> <8AC301FC-6E3B-49CC-9215-E5CF0421AB16@ix.netcom.com> <1F382E46-A3AD-40B9-8895-292FC08D9031@oracle.com> <01FFBDBC-2A4A-4CBB-BD8B-1C44D60BC145@oracle.com> <8F14EA4E-8B71-4306-9702-F8FAD7DBB4D5@oracle.com> Message-ID: <06432EB1-B6BA-496D-ADE2-D627E14050EE@oracle.com> On 6 Jan 2023, at 14:39, Arnaud Masson > wrote: Ron, My concern is that Loom (in its current form) greatly improves scalability on IO-bound requests and but introduce a new fairness problem regarding CPU-bound request. Why are you concerned about a problem no one has reported yet? As I said, we are very interested in fixing problems, but we don?t know how to fix non-problems. If someone shows us a problem ? a server that misbehaves under some loads ? we?ll try to address it. Even if there is a problem with scheduling, and even if time-sharing could solve it, we still don?t know what kind of time-sharing algorithm to employ until we see the actual problem, so there?s nothing we can do about it until we know what it actually is. It?s not that I?m resistant to adding time-sharing. Far from it. But until we have a problem-reproducer that we can test and mark as fixed, we really can?t tell if the time-sharing that we were to introduce today is the time-sharing that would solve the problem we are yet to see. Of course generally on web apps, most requests are IO-bound (http, jdbc) but I do have seen CPU-bound requests on prod (sometimes accidental). Have you encountered a problem with virtual threads in servers with occasional CPU-bound requests? I don?t use Loom on prod today (I guess not a lot of people do since it?s still preview), so if you are asking if I see a production issue, answer is no. Have you seen a problem with a server misbehaving in testing, then? You need to understand that I?m not teasing you. I actually want people to report problems so that we could make the product better by fixing them. But merely saying that there could be a problem and that some sketch of a solution could address it doesn?t give us anything actionable that would help us improve the product. I suppose if I want to migrate to loom and be safe, I can increase the number of native carriers in the underlying pool (N >> core count). It?s just that if there was timesharing in Loom, I don?t see why vthreads would not be systematically used (almost blindly, for CPU-bound and IO-bound). But servers based on thread pools have *worse* fairness than virtual threads: they don?t share as well even when not at 100% CPU. I don?t understand why you think more workers would make you safer when you?re not sure whether or not time-sharing helps server workloads at all. I?m curious, when do you think preemptive time sharing (as implemented in various OSes for decades) is useful? Time-sharing in *non* realtime kernels is crucial useful to keep a system responsive to operator interaction in the presence of a few background tasks that can saturate the CPU; without it, the operator isn?t even able to terminate resource-hungry processes (as would happen in early Windows versions). But transaction processing in servers is different. You have tens of thousands of tasks, if they consume a significant amount CPU then you?re overcommitted by orders of magnitude ? indeed, OS time sharing is not able to make servers well-behaved at 100% CPU ? but responsiveness to operator intervention is still preserved thanks to the OS time-sharing. ? Ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From rengels at ix.netcom.com Fri Jan 6 16:37:53 2023 From: rengels at ix.netcom.com (Robert Engels) Date: Fri, 6 Jan 2023 10:37:53 -0600 Subject: : Re: Project Loom VirtualThreads hang In-Reply-To: <06432EB1-B6BA-496D-ADE2-D627E14050EE@oracle.com> References: <06432EB1-B6BA-496D-ADE2-D627E14050EE@oracle.com> Message-ID: <4CDB44DD-2C5D-4547-B1D0-D7F56EDF19CF@ix.netcom.com> I have to agree a bit with Arnaud. I don?t like the idea that I have to ?reason about? these issues. Imagine a server service that encodes video. Highly cpu bound. But then a need to emit heartbeats to keep clients alive. I have to know ?put heartbeat requests on their own native thread? because too many client encoding requests will cause them not to be sent. Or even more simply - a very short encoding request takes a very long time because it is blocked by other long running requests that got there first. FIFO doesn?t lead to the best user experience at times. With timeslicing and fairness that can be avoided. > On Jan 6, 2023, at 9:50 AM, Ron Pressler wrote: > > ? > >>> On 6 Jan 2023, at 14:39, Arnaud Masson wrote: >>> >>> Ron, >>> >>> My concern is that Loom (in its current form) greatly improves scalability on IO-bound requests and but introduce a new fairness problem regarding CPU-bound request. >>> >> >> Why are you concerned about a problem no one has reported yet? As I said, we are very interested in fixing problems, but we don?t know how to fix non-problems. If someone shows us a problem ? a server that misbehaves under some loads ? we?ll try to address it. Even if there is a problem with scheduling, and even if time-sharing could solve it, we still don?t know what kind of time-sharing algorithm to employ until we see the actual problem, so there?s nothing we can do about it until we know what it actually is. >> >> It?s not that I?m resistant to adding time-sharing. Far from it. But until we have a problem-reproducer that we can test and mark as fixed, we really can?t tell if the time-sharing that we were to introduce today is the time-sharing that would solve the problem we are yet to see. >> >> Of course generally on web apps, most requests are IO-bound (http, jdbc) but I do have seen CPU-bound requests on prod (sometimes accidental). > > Have you encountered a problem with virtual threads in servers with occasional CPU-bound requests? > >> >> I don?t use Loom on prod today (I guess not a lot of people do since it?s still preview), so if you are asking if I see a production issue, answer is no. > > Have you seen a problem with a server misbehaving in testing, then? > > You need to understand that I?m not teasing you. I actually want people to report problems so that we could make the product better by fixing them. But merely saying that there could be a problem and that some sketch of a solution could address it doesn?t give us anything actionable that would help us improve the product. > >> >> I suppose if I want to migrate to loom and be safe, I can increase the number of native carriers in the underlying pool (N >> core count). >> It?s just that if there was timesharing in Loom, I don?t see why vthreads would not be systematically used (almost blindly, for CPU-bound and IO-bound). > > But servers based on thread pools have *worse* fairness than virtual threads: they don?t share as well even when not at 100% CPU. I don?t understand why you think more workers would make you safer when you?re not sure whether or not time-sharing helps server workloads at all. > >> >> I?m curious, when do you think preemptive time sharing (as implemented in various OSes for decades) is useful? > > Time-sharing in *non* realtime kernels is crucial useful to keep a system responsive to operator interaction in the presence of a few background tasks that can saturate the CPU; without it, the operator isn?t even able to terminate resource-hungry processes (as would happen in early Windows versions). But transaction processing in servers is different. You have tens of thousands of tasks, if they consume a significant amount CPU then you?re overcommitted by orders of magnitude ? indeed, OS time sharing is not able to make servers well-behaved at 100% CPU ? but responsiveness to operator intervention is still preserved thanks to the OS time-sharing. > > ? Ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From rengels at ix.netcom.com Fri Jan 6 16:53:14 2023 From: rengels at ix.netcom.com (Robert Engels) Date: Fri, 6 Jan 2023 10:53:14 -0600 Subject: : Re: Project Loom VirtualThreads hang In-Reply-To: <4CDB44DD-2C5D-4547-B1D0-D7F56EDF19CF@ix.netcom.com> References: <4CDB44DD-2C5D-4547-B1D0-D7F56EDF19CF@ix.netcom.com> Message-ID: <62EADF59-D225-41DC-B23C-356ABE0F415F@ix.netcom.com> To clarify, there are ways of addressing each of those issues given the current constraints but they?re a lot more work/specialized code than the fire and forget it model. Not that you don?t have sone of these issues with native threads as well, but there are ways of addressing it that are more common place (eg create separate worker pools for long and short requests, another for short admin/housekeeping/etc) and rely on the kernels scheduler. > On Jan 6, 2023, at 10:38 AM, Robert Engels wrote: > > ? > I have to agree a bit with Arnaud. I don?t like the idea that I have to ?reason about? these issues. Imagine a server service that encodes video. Highly cpu bound. But then a need to emit heartbeats to keep clients alive. I have to know ?put heartbeat requests on their own native thread? because too many client encoding requests will cause them not to be sent. Or even more simply - a very short encoding request takes a very long time because it is blocked by other long running requests that got there first. FIFO doesn?t lead to the best user experience at times. > > With timeslicing and fairness that can be avoided. > > >>> On Jan 6, 2023, at 9:50 AM, Ron Pressler wrote: >>> >> ? >> >>> On 6 Jan 2023, at 14:39, Arnaud Masson wrote: >>> >>> Ron, >>> >>> My concern is that Loom (in its current form) greatly improves scalability on IO-bound requests and but introduce a new fairness problem regarding CPU-bound request. >>> >> >> Why are you concerned about a problem no one has reported yet? As I said, we are very interested in fixing problems, but we don?t know how to fix non-problems. If someone shows us a problem ? a server that misbehaves under some loads ? we?ll try to address it. Even if there is a problem with scheduling, and even if time-sharing could solve it, we still don?t know what kind of time-sharing algorithm to employ until we see the actual problem, so there?s nothing we can do about it until we know what it actually is. >> >> It?s not that I?m resistant to adding time-sharing. Far from it. But until we have a problem-reproducer that we can test and mark as fixed, we really can?t tell if the time-sharing that we were to introduce today is the time-sharing that would solve the problem we are yet to see. >> >>> Of course generally on web apps, most requests are IO-bound (http, jdbc) but I do have seen CPU-bound requests on prod (sometimes accidental). >> >> Have you encountered a problem with virtual threads in servers with occasional CPU-bound requests? >> >>> >>> I don?t use Loom on prod today (I guess not a lot of people do since it?s still preview), so if you are asking if I see a production issue, answer is no. >> >> Have you seen a problem with a server misbehaving in testing, then? >> >> You need to understand that I?m not teasing you. I actually want people to report problems so that we could make the product better by fixing them. But merely saying that there could be a problem and that some sketch of a solution could address it doesn?t give us anything actionable that would help us improve the product. >> >>> >>> I suppose if I want to migrate to loom and be safe, I can increase the number of native carriers in the underlying pool (N >> core count). >>> It?s just that if there was timesharing in Loom, I don?t see why vthreads would not be systematically used (almost blindly, for CPU-bound and IO-bound). >> >> But servers based on thread pools have *worse* fairness than virtual threads: they don?t share as well even when not at 100% CPU. I don?t understand why you think more workers would make you safer when you?re not sure whether or not time-sharing helps server workloads at all. >> >>> >>> I?m curious, when do you think preemptive time sharing (as implemented in various OSes for decades) is useful? >> >> Time-sharing in *non* realtime kernels is crucial useful to keep a system responsive to operator interaction in the presence of a few background tasks that can saturate the CPU; without it, the operator isn?t even able to terminate resource-hungry processes (as would happen in early Windows versions). But transaction processing in servers is different. You have tens of thousands of tasks, if they consume a significant amount CPU then you?re overcommitted by orders of magnitude ? indeed, OS time sharing is not able to make servers well-behaved at 100% CPU ? but responsiveness to operator intervention is still preserved thanks to the OS time-sharing. >> >> ? Ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnaud.masson at fr.ibm.com Fri Jan 6 16:56:10 2023 From: arnaud.masson at fr.ibm.com (Arnaud Masson) Date: Fri, 6 Jan 2023 16:56:10 +0000 Subject: : Re: Project Loom VirtualThreads hang In-Reply-To: <06432EB1-B6BA-496D-ADE2-D627E14050EE@oracle.com> References: <96631C23-9C63-4848-B310-C0521FB094E9@ix.netcom.com> <8AC301FC-6E3B-49CC-9215-E5CF0421AB16@ix.netcom.com> <1F382E46-A3AD-40B9-8895-292FC08D9031@oracle.com> <01FFBDBC-2A4A-4CBB-BD8B-1C44D60BC145@oracle.com> <8F14EA4E-8B71-4306-9702-F8FAD7DBB4D5@oracle.com> <06432EB1-B6BA-496D-ADE2-D627E14050EE@oracle.com> Message-ID: My scenario is not when you have ten thousands of CPU bound tasks. The scenario I?m talking about is when you have thousands of IO bound tasks and just enough CPU-bound tasks (in the same scheduler) to pin most of the carrier threads for some time. When I talk about CPU-bound task here, it?s the worst case when there is not even a yield() or random small IO so it won?t allow to switch the carrier thread until fully completed if I understand correctly. Example: A webapp with a Loom scheduler with 4 native threads. The server gets continuously on average 100 concurrent IO-bound requests: ok Then it gets a one-shot group of 4 CPU-bound requests, pure CPU (no yield) stuff taking 10 secs each. Won?t the 4 carrier threads be sticking to the 4 CPU-bounds requests preventing progress on the other IO-bound requests for 10 secs, then resume work on IO-bound requests? (So not very different from your time sharing example: timesharing on the minority / CPU-bounds tasks would maintain responsiveness for the majority of IO-bound.) Thanks Arnaud Why are you concerned about a problem no one has reported yet? As I said, we are very interested in fixing problems, but we don?t know how to fix non-problems. If someone shows us a problem ? a server that misbehaves under some loads ? we?ll try to address it. Even if there is a problem with scheduling, and even if time-sharing could solve it, we still don?t know what kind of time-sharing algorithm to employ until we see the actual problem, so there?s nothing we can do about it until we know what it actually is. It?s not that I?m resistant to adding time-sharing. Far from it. But until we have a problem-reproducer that we can test and mark as fixed, we really can?t tell if the time-sharing that we were to introduce today is the time-sharing that would solve the problem we are yet to see. Of course generally on web apps, most requests are IO-bound (http, jdbc) but I do have seen CPU-bound requests on prod (sometimes accidental). Have you encountered a problem with virtual threads in servers with occasional CPU-bound requests? I don?t use Loom on prod today (I guess not a lot of people do since it?s still preview), so if you are asking if I see a production issue, answer is no. Have you seen a problem with a server misbehaving in testing, then? You need to understand that I?m not teasing you. I actually want people to report problems so that we could make the product better by fixing them. But merely saying that there could be a problem and that some sketch of a solution could address it doesn?t give us anything actionable that would help us improve the product. I suppose if I want to migrate to loom and be safe, I can increase the number of native carriers in the underlying pool (N >> core count). It?s just that if there was timesharing in Loom, I don?t see why vthreads would not be systematically used (almost blindly, for CPU-bound and IO-bound). But servers based on thread pools have *worse* fairness than virtual threads: they don?t share as well even when not at 100% CPU. I don?t understand why you think more workers would make you safer when you?re not sure whether or not time-sharing helps server workloads at all. I?m curious, when do you think preemptive time sharing (as implemented in various OSes for decades) is useful? Time-sharing in *non* realtime kernels is crucial useful to keep a system responsive to operator interaction in the presence of a few background tasks that can saturate the CPU; without it, the operator isn?t even able to terminate resource-hungry processes (as would happen in early Windows versions). But transaction processing in servers is different. You have tens of thousands of tasks, if they consume a significant amount CPU then you?re overcommitted by orders of magnitude ? indeed, OS time sharing is not able to make servers well-behaved at 100% CPU ? but responsiveness to operator intervention is still preserved thanks to the OS time-sharing. ? Ron Unless otherwise stated above: Compagnie IBM France Si?ge Social : 17, avenue de l'Europe, 92275 Bois-Colombes Cedex RCS Nanterre 552 118 465 Forme Sociale : S.A.S. Capital Social : 664 069 390,60 ? SIRET : 552 118 465 03644 - Code NAF 6203Z -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron.pressler at oracle.com Fri Jan 6 18:32:50 2023 From: ron.pressler at oracle.com (Ron Pressler) Date: Fri, 6 Jan 2023 18:32:50 +0000 Subject: : Re: Project Loom VirtualThreads hang In-Reply-To: References: <96631C23-9C63-4848-B310-C0521FB094E9@ix.netcom.com> <8AC301FC-6E3B-49CC-9215-E5CF0421AB16@ix.netcom.com> <1F382E46-A3AD-40B9-8895-292FC08D9031@oracle.com> <01FFBDBC-2A4A-4CBB-BD8B-1C44D60BC145@oracle.com> <8F14EA4E-8B71-4306-9702-F8FAD7DBB4D5@oracle.com> <06432EB1-B6BA-496D-ADE2-D627E14050EE@oracle.com> Message-ID: <2E883936-6C18-4F5D-8E0C-0498251EFB54@oracle.com> On 6 Jan 2023, at 16:56, Arnaud Masson > wrote: My scenario is not when you have ten thousands of CPU bound tasks. The scenario I?m talking about is when you have thousands of IO bound tasks and just enough CPU-bound tasks (in the same scheduler) to pin most of the carrier threads for some time. That scenario still doesn?t amount to a problem, let alone we can investigate and solve and know we?ve solved. There are many reasons why this hypothetical scenario is unlikely to arise in practice, and/or that if it does, time-sharing won?t be able to help. When I talk about CPU-bound task here, it?s the worst case when there is not even a yield() or random small IO so it won?t allow to switch the carrier thread until fully completed if I understand correctly. Example: A webapp with a Loom scheduler with 4 native threads. The server gets continuously on average 100 concurrent IO-bound requests: ok Then it gets a one-shot group of 4 CPU-bound requests, pure CPU (no yield) stuff taking 10 secs each. Won?t the 4 carrier threads be sticking to the 4 CPU-bounds requests preventing progress on the other IO-bound requests for 10 secs, then resume work on IO-bound requests? The issue here is how is such a server expected to work in the first place? Because of all the short tasks, time-sharing would make those expensive tasks complete in a lot more than 10 seconds, and how is it that the careful balance between the task types is maintained to ensure such a server could work? For time-sharing to improve matters, you?d need just a high enough number of big CPU-bound tasks to saturate the CPU but low enough so that those tasks don?t end up overwhelming the server. A server of the kind you?d describing would occasionally but consistently reach 100% CPU for at least 10 seconds even if platform threads are used. So, if it turns out virtual threads pose a problem for servers that regularly but only occasionally reach 100% CPU for 10 seconds and yet behave well under some other scheduling regime, we would certainly address that problem. BTW, a large company has reported an actual problem that time-sharing could solve, but only for custom schedulers. Their problem is batch tasks that can consume CPU for many minutes at a time, and they want to pause them and re-run them during evening downtimes because they want to spread out their batch jobs and offer better latency, but we?re talking very high latencies here (they don?t have a good solution today, but are hoping that virtual threads with custom schedulers could help). That?s an actual problem that?s been observed that a certain kind of time-sharing could address, but it?s not the kind of time-sharing you have in mind. Reporting a problem is very helpful to us, so when you find one, please report it here! ? Ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron.pressler at oracle.com Fri Jan 6 18:40:07 2023 From: ron.pressler at oracle.com (Ron Pressler) Date: Fri, 6 Jan 2023 18:40:07 +0000 Subject: [External] : Re: : Re: Project Loom VirtualThreads hang In-Reply-To: <4CDB44DD-2C5D-4547-B1D0-D7F56EDF19CF@ix.netcom.com> References: <06432EB1-B6BA-496D-ADE2-D627E14050EE@oracle.com> <4CDB44DD-2C5D-4547-B1D0-D7F56EDF19CF@ix.netcom.com> Message-ID: <92CC97FF-92BB-4AD5-BA28-A6F976AFA77A@oracle.com> On 6 Jan 2023, at 16:37, Robert Engels > wrote: I have to agree a bit with Arnaud. I don?t like the idea that I have to ?reason about? these issues. I?m not asking anyone to reason about any issue. I am asking people to report any problem they run into, as that is extremely valuable feedback and could help us a lot. Reporting a hypothetical problem that people have *not* run into is not particularly useful, not because the problem cannot manifest in reality, but because I don?t know how to solve a hypothetical problem (how would I know that I?ve solved it)? There?s just nothing we can do with that discussion (and these are all things we?ve thought about for years, but because we haven?t been able to observe them, we obviously haven?t been able to address them). I just don?t know how to fix a non-bug. We could add, say, a 10ms time slice, but would that really fix a problem that we haven?t seen yet? How would we know that the non-bug has been fixed before if no one encounters the bug? Imagine a server service that encodes video. Highly cpu bound. But then a need to emit heartbeats to keep clients alive. I have to know ?put heartbeat requests on their own native thread? because too many client encoding requests will cause them not to be sent. Or even more simply - a very short encoding request takes a very long time because it is blocked by other long running requests that got there first. FIFO doesn?t lead to the best user experience at times. With timeslicing and fairness that can be avoided. Yes, but there?s a much better way to do this than by adding timesharing to virtual threads: run your encoding service on platform threads. ? Ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From rengels at ix.netcom.com Fri Jan 6 18:50:49 2023 From: rengels at ix.netcom.com (Robert Engels) Date: Fri, 6 Jan 2023 12:50:49 -0600 Subject: [External] : Re: : Re: Project Loom VirtualThreads hang In-Reply-To: <92CC97FF-92BB-4AD5-BA28-A6F976AFA77A@oracle.com> References: <92CC97FF-92BB-4AD5-BA28-A6F976AFA77A@oracle.com> Message-ID: <0F5AB51E-027D-4988-8180-5332893204E7@ix.netcom.com> I didn?t say it wasn?t possible - I?m saying forcing the designer to figure out ?this runs here and that runs there? has scalability problems for large systems (not microsevices). Having better support in vthreads would be great - but certainly not required. > On Jan 6, 2023, at 12:40 PM, Ron Pressler wrote: > > ? > >>> On 6 Jan 2023, at 16:37, Robert Engels wrote: >>> >>> I have to agree a bit with Arnaud. I don?t like the idea that I have to ?reason about? these issues. >> >> I?m not asking anyone to reason about any issue. I am asking people to report any problem they run into, as that is extremely valuable feedback and could help us a lot. >> >> Reporting a hypothetical problem that people have *not* run into is not particularly useful, not because the problem cannot manifest in reality, but because I don?t know how to solve a hypothetical problem (how would I know that I?ve solved it)? There?s just nothing we can do with that discussion (and these are all things we?ve thought about for years, but because we haven?t been able to observe them, we obviously haven?t been able to address them). >> >> I just don?t know how to fix a non-bug. We could add, say, a 10ms time slice, but would that really fix a problem that we haven?t seen yet? How would we know that the non-bug has been fixed before if no one encounters the bug? >> >> Imagine a server service that encodes video. Highly cpu bound. But then a need to emit heartbeats to keep clients alive. I have to know ?put heartbeat requests on their own native thread? because too many client encoding requests will cause them not to be sent. Or even more simply - a very short encoding request takes a very long time because it is blocked by other long running requests that got there first. FIFO doesn?t lead to the best user experience at times. >> >> With timeslicing and fairness that can be avoided. >> > > Yes, but there?s a much better way to do this than by adding timesharing to virtual threads: run your encoding service on platform threads. > > ? Ron > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron.pressler at oracle.com Fri Jan 6 19:08:28 2023 From: ron.pressler at oracle.com (Ron Pressler) Date: Fri, 6 Jan 2023 19:08:28 +0000 Subject: [External] : Re: : Re: Project Loom VirtualThreads hang In-Reply-To: <0F5AB51E-027D-4988-8180-5332893204E7@ix.netcom.com> References: <92CC97FF-92BB-4AD5-BA28-A6F976AFA77A@oracle.com> <0F5AB51E-027D-4988-8180-5332893204E7@ix.netcom.com> Message-ID: <0241FC51-9FCA-420C-B259-09D0B3B45EA3@oracle.com> > On 6 Jan 2023, at 18:50, Robert Engels wrote: > > I didn?t say it wasn?t possible - I?m saying forcing the designer to figure out ?this runs here and that runs there? has scalability problems for large systems (not microsevices). I think what you?re saying is that you?re *hypothesising* that needing to submit a video encoding task to the video encoding ExecutorService *could* be a problem, not that it is one, although it is certainly no harder than what you said you?d do anyway with platform threads: submit different tasks to different ExecutorServices. So to be even more precise, what you?re saying is that you wish virtual threads could improve the situation for video encoding tasks to be better than the situation today. Maybe that?s possible, but to do that we?ll need to actually see such services and study their particular needs, and because more people are asking to use virtual threads for transaction processing than for video encoding, we?re prioritising their needs. But again, if you run into a problem, even with your video encoding service ? please report it. > Having better support in vthreads would be great - but certainly not required. It would be great only under the assumption that better support for video encoding in the default virtual-thread scheduler will not harm its transaction processing performance, but one of the reasons why we can improve on scheduling in the first place is that we can optimise our scheduler for transaction processing, whereas the kernel scheduler needs to be a general compromise for very different kinds of tasks. Of course, custom schedulers ? which are on the roadmap ? could be used here, but you?d still need to assign different kinds threads to different schedulers/ExecutorServices, just as you may need to do today with either platform or virtual threads. ? Ron From pedro.lamarao at prodist.com.br Fri Jan 6 19:11:29 2023 From: pedro.lamarao at prodist.com.br (=?UTF-8?Q?Pedro_Lamar=C3=A3o?=) Date: Fri, 6 Jan 2023 16:11:29 -0300 Subject: : Re: Project Loom VirtualThreads hang In-Reply-To: <4CDB44DD-2C5D-4547-B1D0-D7F56EDF19CF@ix.netcom.com> References: <06432EB1-B6BA-496D-ADE2-D627E14050EE@oracle.com> <4CDB44DD-2C5D-4547-B1D0-D7F56EDF19CF@ix.netcom.com> Message-ID: Em sex., 6 de jan. de 2023 ?s 13:39, Robert Engels escreveu: > I have to agree a bit with Arnaud. I don?t like the idea that I have to > ?reason about? these issues. Imagine a server service that encodes video. > Highly cpu bound. But then a need to emit heartbeats to keep clients alive. > I have to know ?put heartbeat requests on their own native thread? because > too many client encoding requests will cause them not to be sent. Or even > more simply - a very short encoding request takes a very long time because > it is blocked by other long running requests that got there first. FIFO > doesn?t lead to the best user experience at times. > This is the kind of service I provide in practice, not video encoding, but data encryption / decryption. Any single request amounts to getting data, pushing it through some transformation, then forwarding the result. "Sharing" happens because I/O happens. No healthy service instance will exhaust processing capacity at any time for the very simple reason that processing capacity *must* be provisioned to ensure this never happens. If this ever happens, as a consequence of underprovisioned processing capacity, request latency would start to increase unpredictably and we would miss quality targets. The scenario where a processing unit in some data pipeline exhausts processing capacity is unacceptable in general. Time sharing merely allows the system to operate minimally instead of becoming absolutely unresponsive. It cannot solve the actual problem. Processing is not special in this matter. If you read from disk, and you exhaust "I/O slices", the problem would be the same. -- Pedro Lamar?o -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnaud.masson at fr.ibm.com Fri Jan 6 19:11:55 2023 From: arnaud.masson at fr.ibm.com (Arnaud Masson) Date: Fri, 6 Jan 2023 19:11:55 +0000 Subject: : Re: Project Loom VirtualThreads hang In-Reply-To: <2E883936-6C18-4F5D-8E0C-0498251EFB54@oracle.com> References: <96631C23-9C63-4848-B310-C0521FB094E9@ix.netcom.com> <8AC301FC-6E3B-49CC-9215-E5CF0421AB16@ix.netcom.com> <1F382E46-A3AD-40B9-8895-292FC08D9031@oracle.com> <01FFBDBC-2A4A-4CBB-BD8B-1C44D60BC145@oracle.com> <8F14EA4E-8B71-4306-9702-F8FAD7DBB4D5@oracle.com> <06432EB1-B6BA-496D-ADE2-D627E14050EE@oracle.com> <2E883936-6C18-4F5D-8E0C-0498251EFB54@oracle.com> Message-ID: I don?t think having 100% CPU usage on a pod is enough to justify a ?stop-the-world? effect on Loom scheduling for the other tasks. Also 100% is the extreme case, but there can be 75% CPU usage, meaning only 1 carrier left for all other tasks in my example. Again not a blocker I guess, just have to increase the carrier count to mitigate, but it?s good old native thread sizing again where it should not be really needed. ?Time-sharing would make those expensive tasks complete in a lot more than 10 seconds?: I understand there would be switching overhead (so it?s slower), but I don?t understand why it would be much slower if there are few of them like in my example. thanks Arnaud On 6 Jan 2023, at 16:56, Arnaud Masson > wrote: My scenario is not when you have ten thousands of CPU bound tasks. The scenario I?m talking about is when you have thousands of IO bound tasks and just enough CPU-bound tasks (in the same scheduler) to pin most of the carrier threads for some time. That scenario still doesn?t amount to a problem, let alone we can investigate and solve and know we?ve solved. There are many reasons why this hypothetical scenario is unlikely to arise in practice, and/or that if it does, time-sharing won?t be able to help. When I talk about CPU-bound task here, it?s the worst case when there is not even a yield() or random small IO so it won?t allow to switch the carrier thread until fully completed if I understand correctly. Example: A webapp with a Loom scheduler with 4 native threads. The server gets continuously on average 100 concurrent IO-bound requests: ok Then it gets a one-shot group of 4 CPU-bound requests, pure CPU (no yield) stuff taking 10 secs each. Won?t the 4 carrier threads be sticking to the 4 CPU-bounds requests preventing progress on the other IO-bound requests for 10 secs, then resume work on IO-bound requests? The issue here is how is such a server expected to work in the first place? Because of all the short tasks, time-sharing would make those expensive tasks complete in a lot more than 10 seconds, and how is it that the careful balance between the task types is maintained to ensure such a server could work? For time-sharing to improve matters, you?d need just a high enough number of big CPU-bound tasks to saturate the CPU but low enough so that those tasks don?t end up overwhelming the server. A server of the kind you?d describing would occasionally but consistently reach 100% CPU for at least 10 seconds even if platform threads are used. So, if it turns out virtual threads pose a problem for servers that regularly but only occasionally reach 100% CPU for 10 seconds and yet behave well under some other scheduling regime, we would certainly address that problem. BTW, a large company has reported an actual problem that time-sharing could solve, but only for custom schedulers. Their problem is batch tasks that can consume CPU for many minutes at a time, and they want to pause them and re-run them during evening downtimes because they want to spread out their batch jobs and offer better latency, but we?re talking very high latencies here (they don?t have a good solution today, but are hoping that virtual threads with custom schedulers could help). That?s an actual problem that?s been observed that a certain kind of time-sharing could address, but it?s not the kind of time-sharing you have in mind. Reporting a problem is very helpful to us, so when you find one, please report it here! ? Ron Unless otherwise stated above: Compagnie IBM France Si?ge Social : 17, avenue de l'Europe, 92275 Bois-Colombes Cedex RCS Nanterre 552 118 465 Forme Sociale : S.A.S. Capital Social : 664 069 390,60 ? SIRET : 552 118 465 03644 - Code NAF 6203Z -------------- next part -------------- An HTML attachment was scrubbed... URL: From thurston.nomagicsoftware at gmail.com Fri Jan 6 19:24:38 2023 From: thurston.nomagicsoftware at gmail.com (thurston N) Date: Fri, 6 Jan 2023 11:24:38 -0800 Subject: effectiveness of jdk.virtualThreadScheduler.maxPoolSize Message-ID: I have a question about the impact of setting jdk.virtualThreadScheduler.maxPoolSize (MAX) to some value > jdk.virtualThreadScheduler.parallelism (P) I'll add the caveat that my particular scenario is *not* the target scenario of virtual threads, but I think it might have relevance for more realistic scenarios Here's what I've observed (and can reliably reproduce): In my simulation, the system can reach a state where: A. each of the P CarrierThreads is running a continuation that is completely CPU-bound (reaching 100% CPU) B. there are other runnable continuations that are enqueued to the FJP but the FJP never spawns other worker CarrierThread(s), even though the total # of CarrierThreads is well below MAX - this was an unexpected and unpleasant surprise I guess my question is: should I be surprised? (effectively, is this a bug in FJP?) and if not, is there anything I can do about it (in accessible user-level code) to help trigger FJP to spawn more CarrierThreads (workers) up to MAX so that (because of *OS* preemptive scheduling), the other runnable continuations (described in B) will get run? -T -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron.pressler at oracle.com Fri Jan 6 19:26:29 2023 From: ron.pressler at oracle.com (Ron Pressler) Date: Fri, 6 Jan 2023 19:26:29 +0000 Subject: : Re: Project Loom VirtualThreads hang In-Reply-To: References: <96631C23-9C63-4848-B310-C0521FB094E9@ix.netcom.com> <8AC301FC-6E3B-49CC-9215-E5CF0421AB16@ix.netcom.com> <1F382E46-A3AD-40B9-8895-292FC08D9031@oracle.com> <01FFBDBC-2A4A-4CBB-BD8B-1C44D60BC145@oracle.com> <8F14EA4E-8B71-4306-9702-F8FAD7DBB4D5@oracle.com> <06432EB1-B6BA-496D-ADE2-D627E14050EE@oracle.com> <2E883936-6C18-4F5D-8E0C-0498251EFB54@oracle.com> Message-ID: <9027F27F-614C-4F35-8AC4-F89DA4638044@oracle.com> I don?t think that increasing the scheduler?s parallelism would help, nor do I think you?d see a ?stop-the-world?, but again, these hypotheses are just not actionable. There?s nothing we can do to address them. When you find a problem, please report it and we?ll investigate what can be done. ? Ron On 6 Jan 2023, at 19:11, Arnaud Masson > wrote: I don?t think having 100% CPU usage on a pod is enough to justify a ?stop-the-world? effect on Loom scheduling for the other tasks. Also 100% is the extreme case, but there can be 75% CPU usage, meaning only 1 carrier left for all other tasks in my example. Again not a blocker I guess, just have to increase the carrier count to mitigate, but it?s good old native thread sizing again where it should not be really needed. ?Time-sharing would make those expensive tasks complete in a lot more than 10 seconds?: I understand there would be switching overhead (so it?s slower), but I don?t understand why it would be much slower if there are few of them like in my example. thanks Arnaud -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron.pressler at oracle.com Fri Jan 6 19:33:08 2023 From: ron.pressler at oracle.com (Ron Pressler) Date: Fri, 6 Jan 2023 19:33:08 +0000 Subject: effectiveness of jdk.virtualThreadScheduler.maxPoolSize In-Reply-To: References: Message-ID: > On 6 Jan 2023, at 19:24, thurston N wrote: > > I have a question about the impact of setting jdk.virtualThreadScheduler.maxPoolSize (MAX) to some value > jdk.virtualThreadScheduler.parallelism (P) > > I'll add the caveat that my particular scenario is *not* the target scenario of virtual threads, but I think it might have relevance for more realistic scenarios > > Here's what I've observed (and can reliably reproduce): > In my simulation, the system can reach a state where: > A. each of the P CarrierThreads is running a continuation that is completely CPU-bound (reaching 100% CPU) > B. there are other runnable continuations that are enqueued to the FJP > > but the FJP never spawns other worker CarrierThread(s), even though the total # of CarrierThreads is well below MAX - this was an unexpected and unpleasant surprise > > I guess my question is: should I be surprised? (effectively, is this a bug in FJP?) > and if not, is there anything I can do about it (in accessible user-level code) to help trigger FJP to spawn more CarrierThreads (workers) up to MAX so that (because of *OS* preemptive scheduling), the other runnable continuations (described in B) will get run? > > -T > > > It?s not a bug, and increasing maxPoolSize won?t help, since if your CPU is exhausted, adding more threads won?t add more CPU. Parallel streams behave in the exact same way. maxPoolSize refers to compensation by the scheduler for some operations listed in the JEP, which include filesystem IO, where additional threads can actually help. You could increase parallelism, but the first thing to understand here is why problem are you trying to solve with virtual threads? What is it that you?d like to see happen, why, and why do you think virtual threads are the mechanism to solve it (i.e. we do offer a thread scheduler that offers time-sharing ? the kernel scheduler)? ? Ron From ron.pressler at oracle.com Fri Jan 6 19:38:09 2023 From: ron.pressler at oracle.com (Ron Pressler) Date: Fri, 6 Jan 2023 19:38:09 +0000 Subject: [External] : API proposal for StructuredTaskScope In-Reply-To: <1820007192.78636534.1672932171087.JavaMail.zimbra@u-pem.fr> References: <1656042197.78345370.1672915566603.JavaMail.zimbra@u-pem.fr> <1820007192.78636534.1672932171087.JavaMail.zimbra@u-pem.fr> Message-ID: <26D6577B-7E19-4E8B-814F-16B330B3FC00@oracle.com> On 5 Jan 2023, at 15:22, forax at univ-mlv.fr wrote: ----- Original Message ----- From: "Ron Pressler" > To: "Remi Forax" > Cc: "loom-dev" > Sent: Thursday, January 5, 2023 3:37:06 PM Subject: Re: [External] : API proposal for StructuredTaskScope We have considered such approaches. One glaring problem is the case of ?heterogenous tasks?, i.e. tasks that each return a result of a different type. This is a very common scenario for ShutdownOnFailure. I believe that using a static factory instead of a constructor (here StructuredTaskScope.of()) solve that pretty well. If no type is explicitly provided, the inference will default to Object which is exactly what you want in case of a shutdown on failure. I don?t follow. The scenario I had in mind is this: Response handle() throws ExecutionException, InterruptedException { try (var scope = new StructuredTaskScope.ShutdownOnFailure()) { Future s1 = scope.fork(() -> fetchS1()); Future s2 = scope.fork(() -> fetchS2()); Future i1 = scope.fork(() -> fetchI1()); Future i2 = scope.fork(() -> fetchI2()); scope.join().throwIfFailed(); return new Response(s1, s2, i1, i2); } } How do you propose to do it when fork returns void? ? Ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From rengels at ix.netcom.com Fri Jan 6 19:39:29 2023 From: rengels at ix.netcom.com (Robert Engels) Date: Fri, 6 Jan 2023 13:39:29 -0600 Subject: : Re: Project Loom VirtualThreads hang In-Reply-To: <9027F27F-614C-4F35-8AC4-F89DA4638044@oracle.com> References: <9027F27F-614C-4F35-8AC4-F89DA4638044@oracle.com> Message-ID: <63A68E18-0737-4D34-A659-05E76A89A68B@ix.netcom.com> I could go into a long description of the 64 core machines we used for hft along with the native thread prioritization we added - along with multiple specialized lock-free queues along with core affinity and numa aware scheduling all to reduce latency and increase throughput. I think a lot of those techniques still apply to vthreads and having it in the platform would benefit everyone. > On Jan 6, 2023, at 1:27 PM, Ron Pressler wrote: > > ? I don?t think that increasing the scheduler?s parallelism would help, nor do I think you?d see a ?stop-the-world?, but again, these hypotheses are just not actionable. There?s nothing we can do to address them. When you find a problem, please report it and we?ll investigate what can be done. > > ? Ron > >> On 6 Jan 2023, at 19:11, Arnaud Masson wrote: >> >> I don?t think having 100% CPU usage on a pod is enough to justify a ?stop-the-world? effect on Loom scheduling for the other tasks. >> Also 100% is the extreme case, but there can be 75% CPU usage, meaning only 1 carrier left for all other tasks in my example. >> >> Again not a blocker I guess, just have to increase the carrier count to mitigate, but it?s good old native thread sizing again where it should not be really needed. >> >> ?Time-sharing would make those expensive tasks complete in a lot more than 10 seconds?: >> I understand there would be switching overhead (so it?s slower), but I don?t understand why it would be much slower if there are few of them like in my example. >> >> thanks >> Arnaud >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnaud.masson at fr.ibm.com Fri Jan 6 19:45:43 2023 From: arnaud.masson at fr.ibm.com (Arnaud Masson) Date: Fri, 6 Jan 2023 19:45:43 +0000 Subject: : Re: Project Loom VirtualThreads hang In-Reply-To: <9027F27F-614C-4F35-8AC4-F89DA4638044@oracle.com> References: <96631C23-9C63-4848-B310-C0521FB094E9@ix.netcom.com> <8AC301FC-6E3B-49CC-9215-E5CF0421AB16@ix.netcom.com> <1F382E46-A3AD-40B9-8895-292FC08D9031@oracle.com> <01FFBDBC-2A4A-4CBB-BD8B-1C44D60BC145@oracle.com> <8F14EA4E-8B71-4306-9702-F8FAD7DBB4D5@oracle.com> <06432EB1-B6BA-496D-ADE2-D627E14050EE@oracle.com> <2E883936-6C18-4F5D-8E0C-0498251EFB54@oracle.com> <9027F27F-614C-4F35-8AC4-F89DA4638044@oracle.com> Message-ID: I can?t see how stop-the-world effect can be avoided once all your carriers are busy with non-switchable CPU-bound tasks. Maybe I?m missing something ? Not very different from other pinning problems (JNI...), except the argument that 100% CPU usage should never occur so not a problem. I will try to make some test to simulate and post the result here. Thanks Arnaud I don?t think that increasing the scheduler?s parallelism would help, nor do I think you?d see a ?stop-the-world?, but again, these hypotheses are just not actionable. There?s nothing we can do to address them. When you find a problem, please report it and we?ll investigate what can be done. ? Ron On 6 Jan 2023, at 19:11, Arnaud Masson > wrote: I don?t think having 100% CPU usage on a pod is enough to justify a ?stop-the-world? effect on Loom scheduling for the other tasks. Also 100% is the extreme case, but there can be 75% CPU usage, meaning only 1 carrier left for all other tasks in my example. Again not a blocker I guess, just have to increase the carrier count to mitigate, but it?s good old native thread sizing again where it should not be really needed. ?Time-sharing would make those expensive tasks complete in a lot more than 10 seconds?: I understand there would be switching overhead (so it?s slower), but I don?t understand why it would be much slower if there are few of them like in my example. thanks Arnaud Unless otherwise stated above: Compagnie IBM France Si?ge Social : 17, avenue de l'Europe, 92275 Bois-Colombes Cedex RCS Nanterre 552 118 465 Forme Sociale : S.A.S. Capital Social : 664 069 390,60 ? SIRET : 552 118 465 03644 - Code NAF 6203Z -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron.pressler at oracle.com Fri Jan 6 19:47:07 2023 From: ron.pressler at oracle.com (Ron Pressler) Date: Fri, 6 Jan 2023 19:47:07 +0000 Subject: [External] : Re: : Re: Project Loom VirtualThreads hang In-Reply-To: <63A68E18-0737-4D34-A659-05E76A89A68B@ix.netcom.com> References: <9027F27F-614C-4F35-8AC4-F89DA4638044@oracle.com> <63A68E18-0737-4D34-A659-05E76A89A68B@ix.netcom.com> Message-ID: <05A426CA-E580-4C2B-AE9E-8BA465C43B37@oracle.com> Absolutely! Once you report a problem you encounter with virtual threads, we?d be able to prioritise it and find mechanisms that would benefit everyone. Even if they don?t benefit everyone we?d still love to do them (with the right priority, as we get many such requests). As I said, we?re working to add support for custom schedulers (that could also be used for core affinity), which are certainly an advanced feature and not for the average web application, but we?re only able to work on them because we have concrete problems that we can try to solve. As long as there is no actual problem in front of us, we?re simply incapable in providing any mechanism to solve that non-problem, regardless of priority. So in some situations I might say, that?s interesting but not a high priority. But if you?re not reporting a problem ? one that we determine should be solved by virtual threads rather than some other feature ? there?s literally nothing we can do, other than keep asking you to report real problems. ? Ron > On 6 Jan 2023, at 19:39, Robert Engels wrote: > > I could go into a long description of the 64 core machines we used for hft along with the native thread prioritization we added - along with multiple specialized lock-free queues along with core affinity and numa aware scheduling all to reduce latency and increase throughput. > > I think a lot of those techniques still apply to vthreads and having it in the platform would benefit everyone. From rengels at ix.netcom.com Fri Jan 6 19:48:40 2023 From: rengels at ix.netcom.com (Robert Engels) Date: Fri, 6 Jan 2023 13:48:40 -0600 Subject: effectiveness of jdk.virtualThreadScheduler.maxPoolSize In-Reply-To: References: Message-ID: The point is that spin locks are valid. If used with vthreads you will quickly lock the pool - if the unlocker is behind the others. With time sharing that shouldn?t happen. > On Jan 6, 2023, at 1:33 PM, Ron Pressler wrote: > > ? > >> On 6 Jan 2023, at 19:24, thurston N wrote: >> >> I have a question about the impact of setting jdk.virtualThreadScheduler.maxPoolSize (MAX) to some value > jdk.virtualThreadScheduler.parallelism (P) >> >> I'll add the caveat that my particular scenario is *not* the target scenario of virtual threads, but I think it might have relevance for more realistic scenarios >> >> Here's what I've observed (and can reliably reproduce): >> In my simulation, the system can reach a state where: >> A. each of the P CarrierThreads is running a continuation that is completely CPU-bound (reaching 100% CPU) >> B. there are other runnable continuations that are enqueued to the FJP >> >> but the FJP never spawns other worker CarrierThread(s), even though the total # of CarrierThreads is well below MAX - this was an unexpected and unpleasant surprise >> >> I guess my question is: should I be surprised? (effectively, is this a bug in FJP?) >> and if not, is there anything I can do about it (in accessible user-level code) to help trigger FJP to spawn more CarrierThreads (workers) up to MAX so that (because of *OS* preemptive scheduling), the other runnable continuations (described in B) will get run? >> >> -T >> >> >> > > It?s not a bug, and increasing maxPoolSize won?t help, since if your CPU is exhausted, adding more threads won?t add more CPU. Parallel streams behave in the exact same way. maxPoolSize refers to compensation by the scheduler for some operations listed in the JEP, which include filesystem IO, where additional threads can actually help. > > You could increase parallelism, but the first thing to understand here is why problem are you trying to solve with virtual threads? What is it that you?d like to see happen, why, and why do you think virtual threads are the mechanism to solve it (i.e. we do offer a thread scheduler that offers time-sharing ? the kernel scheduler)? > > ? Ron From ron.pressler at oracle.com Fri Jan 6 19:49:03 2023 From: ron.pressler at oracle.com (Ron Pressler) Date: Fri, 6 Jan 2023 19:49:03 +0000 Subject: : Re: Project Loom VirtualThreads hang In-Reply-To: References: <96631C23-9C63-4848-B310-C0521FB094E9@ix.netcom.com> <8AC301FC-6E3B-49CC-9215-E5CF0421AB16@ix.netcom.com> <1F382E46-A3AD-40B9-8895-292FC08D9031@oracle.com> <01FFBDBC-2A4A-4CBB-BD8B-1C44D60BC145@oracle.com> <8F14EA4E-8B71-4306-9702-F8FAD7DBB4D5@oracle.com> <06432EB1-B6BA-496D-ADE2-D627E14050EE@oracle.com> <2E883936-6C18-4F5D-8E0C-0498251EFB54@oracle.com> <9027F27F-614C-4F35-8AC4-F89DA4638044@oracle.com> Message-ID: <66AEC9D2-AFD3-4593-9F79-FE2D7AC31094@oracle.com> Over the years we?ve been working on virtual threads, we?ve made lots of simulations. But the features we have are not features that address artificial simulations, but only those of them that correspond to real problems our real users face in the real world. What we need to improve things aren?t more simulations, but reports from real systems (or simulations that try to mimic behaviour observed in a real system). ? Ron On 6 Jan 2023, at 19:45, Arnaud Masson > wrote: I can?t see how stop-the-world effect can be avoided once all your carriers are busy with non-switchable CPU-bound tasks. Maybe I?m missing something ? Not very different from other pinning problems (JNI...), except the argument that 100% CPU usage should never occur so not a problem. I will try to make some test to simulate and post the result here. Thanks Arnaud I don?t think that increasing the scheduler?s parallelism would help, nor do I think you?d see a ?stop-the-world?, but again, these hypotheses are just not actionable. There?s nothing we can do to address them. When you find a problem, please report it and we?ll investigate what can be done. ? Ron On 6 Jan 2023, at 19:11, Arnaud Masson > wrote: I don?t think having 100% CPU usage on a pod is enough to justify a ?stop-the-world? effect on Loom scheduling for the other tasks. Also 100% is the extreme case, but there can be 75% CPU usage, meaning only 1 carrier left for all other tasks in my example. Again not a blocker I guess, just have to increase the carrier count to mitigate, but it?s good old native thread sizing again where it should not be really needed. ?Time-sharing would make those expensive tasks complete in a lot more than 10 seconds?: I understand there would be switching overhead (so it?s slower), but I don?t understand why it would be much slower if there are few of them like in my example. thanks Arnaud Unless otherwise stated above: Compagnie IBM France Si?ge Social : 17, avenue de l'Europe, 92275 Bois-Colombes Cedex RCS Nanterre 552 118 465 Forme Sociale : S.A.S. Capital Social : 664 069 390,60 ? SIRET : 552 118 465 03644 - Code NAF 6203Z -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron.pressler at oracle.com Fri Jan 6 19:55:21 2023 From: ron.pressler at oracle.com (Ron Pressler) Date: Fri, 6 Jan 2023 19:55:21 +0000 Subject: [External] : Re: effectiveness of jdk.virtualThreadScheduler.maxPoolSize In-Reply-To: References: Message-ID: <8F3CDA70-A8A7-4B34-B13F-C6E0E4A51840@oracle.com> On 6 Jan 2023, at 19:48, Robert Engels > wrote: The point is that spin locks are valid. If used with vthreads you will quickly lock the pool - if the unlocker is behind the others. With time sharing that shouldn?t happen. With time sharing you might get some desired behaviour only if the number of threads is quite small, and we already offer a solution for that that I think is better overall than adding time-sharing to virtual threads (although I?d say that if you have a system that?s frequently overcommitted, spin locks are *not* the construct you should use). But please, we?ve done all these thought experiments and tests for years. I am asking you to talk about a problem you?ve actually faced with virtual threads for which you think changes to virtual threads are the right solution. What we?re lacking isn?t ideas or hypotheses. The team working on virtual threads has worked on concurrency for many, *many* years (not just in Loom). What we?re lacking is data about usage of virtual threads in the field. If you?d like to help and shape what future features we add, that?s the way to do it. ? Ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnaud.masson at fr.ibm.com Fri Jan 6 20:03:07 2023 From: arnaud.masson at fr.ibm.com (Arnaud Masson) Date: Fri, 6 Jan 2023 20:03:07 +0000 Subject: : Re: Project Loom VirtualThreads hang In-Reply-To: <66AEC9D2-AFD3-4593-9F79-FE2D7AC31094@oracle.com> References: <96631C23-9C63-4848-B310-C0521FB094E9@ix.netcom.com> <8AC301FC-6E3B-49CC-9215-E5CF0421AB16@ix.netcom.com> <1F382E46-A3AD-40B9-8895-292FC08D9031@oracle.com> <01FFBDBC-2A4A-4CBB-BD8B-1C44D60BC145@oracle.com> <8F14EA4E-8B71-4306-9702-F8FAD7DBB4D5@oracle.com> <06432EB1-B6BA-496D-ADE2-D627E14050EE@oracle.com> <2E883936-6C18-4F5D-8E0C-0498251EFB54@oracle.com> <9027F27F-614C-4F35-8AC4-F89DA4638044@oracle.com> <66AEC9D2-AFD3-4593-9F79-FE2D7AC31094@oracle.com> Message-ID: Sure. Servers with both IO-bound and CPU-bound requests are what I see in the real world. ? Thanks Arnaud Over the years we?ve been working on virtual threads, we?ve made lots of simulations. But the features we have are not features that address artificial simulations, but only those of them that correspond to real problems our real users face in the real world. What we need to improve things aren?t more simulations, but reports from real systems (or simulations that try to mimic behaviour observed in a real system). ? Ron On 6 Jan 2023, at 19:45, Arnaud Masson > wrote: I can?t see how stop-the-world effect can be avoided once all your carriers are busy with non-switchable CPU-bound tasks. Maybe I?m missing something ? Not very different from other pinning problems (JNI...), except the argument that 100% CPU usage should never occur so not a problem. I will try to make some test to simulate and post the result here. Thanks Arnaud I don?t think that increasing the scheduler?s parallelism would help, nor do I think you?d see a ?stop-the-world?, but again, these hypotheses are just not actionable. There?s nothing we can do to address them. When you find a problem, please report it and we?ll investigate what can be done. ? Ron On 6 Jan 2023, at 19:11, Arnaud Masson > wrote: I don?t think having 100% CPU usage on a pod is enough to justify a ?stop-the-world? effect on Loom scheduling for the other tasks. Also 100% is the extreme case, but there can be 75% CPU usage, meaning only 1 carrier left for all other tasks in my example. Again not a blocker I guess, just have to increase the carrier count to mitigate, but it?s good old native thread sizing again where it should not be really needed. ?Time-sharing would make those expensive tasks complete in a lot more than 10 seconds?: I understand there would be switching overhead (so it?s slower), but I don?t understand why it would be much slower if there are few of them like in my example. thanks Arnaud Unless otherwise stated above: Compagnie IBM France Si?ge Social : 17, avenue de l'Europe, 92275 Bois-Colombes Cedex RCS Nanterre 552 118 465 Forme Sociale : S.A.S. Capital Social : 664 069 390,60 ? SIRET : 552 118 465 03644 - Code NAF 6203Z Unless otherwise stated above: Compagnie IBM France Si?ge Social : 17, avenue de l'Europe, 92275 Bois-Colombes Cedex RCS Nanterre 552 118 465 Forme Sociale : S.A.S. Capital Social : 664 069 390,60 ? SIRET : 552 118 465 03644 - Code NAF 6203Z -------------- next part -------------- An HTML attachment was scrubbed... URL: From forax at univ-mlv.fr Fri Jan 6 21:02:53 2023 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Fri, 6 Jan 2023 22:02:53 +0100 (CET) Subject: [External] : API proposal for StructuredTaskScope In-Reply-To: <26D6577B-7E19-4E8B-814F-16B330B3FC00@oracle.com> References: <1656042197.78345370.1672915566603.JavaMail.zimbra@u-pem.fr> <1820007192.78636534.1672932171087.JavaMail.zimbra@u-pem.fr> <26D6577B-7E19-4E8B-814F-16B330B3FC00@oracle.com> Message-ID: <1134028269.79704983.1673038973120.JavaMail.zimbra@u-pem.fr> > From: "Ron Pressler" > To: "Remi Forax" > Cc: "loom-dev" > Sent: Friday, January 6, 2023 8:38:09 PM > Subject: Re: [External] : API proposal for StructuredTaskScope >> On 5 Jan 2023, at 15:22, [ mailto:forax at univ-mlv.fr | >> forax at univ-mlv.fr ] wrote: >> ----- Original Message ----- >>> From: "Ron Pressler" < [ mailto:ron.pressler at oracle.com | >>> ron.pressler at oracle.com ] > >>> To: "Remi Forax" < [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ] > >>> Cc: "loom-dev" < [ mailto:loom-dev at openjdk.java.net | loom-dev at openjdk.java.net >>> ] > >>> Sent: Thursday, January 5, 2023 3:37:06 PM >>> Subject: Re: [External] : API proposal for StructuredTaskScope >>> We have considered such approaches. >>> One glaring problem is the case of ?heterogenous tasks?, i.e. tasks that each >>> return a result of a different type. This is a very common scenario for >>> ShutdownOnFailure. >> I believe that using a static factory instead of a constructor (here >> StructuredTaskScope.of()) solve that pretty well. >> If no type is explicitly provided, the inference will default to Object which is >> exactly what you want in case of a shutdown on failure. > I don?t follow. The scenario I had in mind is this: > Response handle() throws ExecutionException, InterruptedException { > try (var scope = new StructuredTaskScope.ShutdownOnFailure()) { > Future s1 = scope.fork(() -> fetchS1()); > Future s2 = scope.fork(() -> fetchS2()); > Future i1 = scope.fork(() -> fetchI1()); > Future< Integer > i2 = scope.fork(() -> fetchI2()); > scope.join() .throwIfFailed(); > return new Response(s1, s2, i1, i2); > } > } > How do you propose to do it when fork returns void? Ok, I get it, if the result values are heterogeneous, as you said, fork() has to return a Supplier. try(var scope = StructuredTaskScope.of(Reducer.firstException().shutdownOnFailure())) { Supplier s1 = scope.fork(() -> fetchS1()); Supplier s2 = scope.fork(() -> fetchS2()); Supplier i1 = scope.fork(() -> fetchI1()); Supplier i2 = scope.fork(() -> fetchI2()); Optional result = scope.result(); result.ifPresent(e -> { throw new RuntimeException(e); }); return new Response(s1.get(), s2.get(), i1.get(), i2.get()); } firstException() returns the first exception as an Optional and shutdownOnFailure() calls shutdown() if there is a failure. The nice thing is that shutdownOnFailure() is a composable higern order function that can be used not only with firstException() but with any reducers, like toList() by example. > ? Ron R?mi -------------- next part -------------- An HTML attachment was scrubbed... URL: From thurston.nomagicsoftware at gmail.com Fri Jan 6 22:03:40 2023 From: thurston.nomagicsoftware at gmail.com (thurston N) Date: Fri, 6 Jan 2023 14:03:40 -0800 Subject: [External] : Re: effectiveness of jdk.virtualThreadScheduler.maxPoolSize In-Reply-To: <8F3CDA70-A8A7-4B34-B13F-C6E0E4A51840@oracle.com> References: <8F3CDA70-A8A7-4B34-B13F-C6E0E4A51840@oracle.com> Message-ID: Ron, What would be the minimum # of virtual threads you would need to provide useful data so that you could investigate? 1K? 10K? or even more? -T On Fri, Jan 6, 2023 at 11:55 AM Ron Pressler wrote: > > > On 6 Jan 2023, at 19:48, Robert Engels wrote: > > The point is that spin locks are valid. If used with vthreads you will > quickly lock the pool - if the unlocker is behind the others. With time > sharing that shouldn?t happen. > > > With time sharing you might get some desired behaviour only if the number > of threads is quite small, and we already offer a solution for that that I > think is better overall than adding time-sharing to virtual threads > (although I?d say that if you have a system that?s frequently > overcommitted, spin locks are *not* the construct you should use). > > But please, we?ve done all these thought experiments and tests for years. > I am asking you to talk about a problem you?ve actually faced with virtual > threads for which you think changes to virtual threads are the right > solution. > > What we?re lacking isn?t ideas or hypotheses. The team working on virtual > threads has worked on concurrency for many, *many* years (not just in > Loom). What we?re lacking is data about usage of virtual threads in the > field. If you?d like to help and shape what future features we add, that?s > the way to do it. > > ? Ron > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Sat Jan 7 12:48:53 2023 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 7 Jan 2023 12:48:53 +0000 Subject: effectiveness of jdk.virtualThreadScheduler.maxPoolSize In-Reply-To: References: Message-ID: <1389ae83-25fb-ebc5-4710-268b4499865e@oracle.com> On 06/01/2023 19:48, Robert Engels wrote: > The point is that spin locks are valid. If used with vthreads you will quickly lock the pool - if the unlocker is behind the others. With time sharing that shouldn?t happen. Spinlocks are usually only used for locks that that are held for very brief periods. If a virtual thread is doing I/O or running other code that causes it to preempted while hold such a lock then yes, then deadlocks like this could arise. We expect that the maintainers of low level code with their own lock implementations, or code doing spin waits to avoid parking, will need to make some changes to work efficiently with virtual threads and with greedy schedulers. Given that parking is cheap then it might be that code goes straight to park when running in a virtual thread. For spin locks it might be that it changes to be more hybrid so that it is efficient when executed by both platform and virtual threads, and when used together. -Alan From stephan.j.bircher at gmail.com Sat Jan 7 18:31:22 2023 From: stephan.j.bircher at gmail.com (Stephan B) Date: Sat, 7 Jan 2023 19:31:22 +0100 Subject: ThreadFactory for carrier threads, access to native thread, callback when carrier thread is mounted Message-ID: Hi loom dev team The project I work on involves a great deal of native code where thread interaction between java and native code is vital. Therefore the java Thread was extended to hold a reference to the native thread data structure. Once a java thread is taken from the thread pool the runtime structure must only be attached to native thread which is done directly by updating the pointer in the native thread structure. Like the following code illustrates var runtime = Runtime.current(); unsafe.putLong(thread + ThreadOffset.runtime, runtime.ptr); unsafe.putLong(thread + ThreadOffset.userContext, runner.getUserContext().getPtr()); Once the runtime state is attached any further JNI call to the native code can access the runtime data by calling (pthread_getspecific). This could be achieved by having a custom ThreadFactory for the carrier thread pool used by virtual threads and by having a callback mechanism which informs once a Virtual Thread is mounted to the native thread. Another problem which I see is that virtual threads hide the native java thread so native thread state can not be stored. ThreadLocal returns the local state of the virtual thread which is not of much use as one can simply store this state in the Task (Runnable). There should be a way to access the native thread and to store state on that. Thank you very much for considering these suggestions. - Stephan From stephan.j.bircher at gmail.com Sat Jan 7 18:31:22 2023 From: stephan.j.bircher at gmail.com (Stephan B) Date: Sat, 7 Jan 2023 19:31:22 +0100 Subject: ThreadFactory for carrier threads, access to native thread, callback when carrier thread is mounted Message-ID: Hi loom dev team The project I work on involves a great deal of native code where thread interaction between java and native code is vital. Therefore the java Thread was extended to hold a reference to the native thread data structure. Once a java thread is taken from the thread pool the runtime structure must only be attached to native thread which is done directly by updating the pointer in the native thread structure. Like the following code illustrates var runtime = Runtime.current(); unsafe.putLong(thread + ThreadOffset.runtime, runtime.ptr); unsafe.putLong(thread + ThreadOffset.userContext, runner.getUserContext().getPtr()); Once the runtime state is attached any further JNI call to the native code can access the runtime data by calling (pthread_getspecific). This could be achieved by having a custom ThreadFactory for the carrier thread pool used by virtual threads and by having a callback mechanism which informs once a Virtual Thread is mounted to the native thread. Another problem which I see is that virtual threads hide the native java thread so native thread state can not be stored. ThreadLocal returns the local state of the virtual thread which is not of much use as one can simply store this state in the Task (Runnable). There should be a way to access the native thread and to store state on that. Thank you very much for considering these suggestions. - Stephan From rengels at ix.netcom.com Sat Jan 7 21:13:50 2023 From: rengels at ix.netcom.com (robert engels) Date: Sat, 7 Jan 2023 15:13:50 -0600 Subject: ThreadFactory for carrier threads, access to native thread, callback when carrier thread is mounted In-Reply-To: References: Message-ID: The vthread can move between native threads at anytime (technically, in practice only at continuation points), you are going to have corruption of the native structure. Why not store the native structure in the runnable instance passed to the vthread during creation? e.g. class MyVThread implements Runnable { private NativeStructure ns; public void run() {?} } and pass the native struct reference to each native call, eg. callNativeMethod(&ns,?); Probably best to allocate NativeStructure off-head to maintain a constant address. > On Jan 7, 2023, at 12:31 PM, Stephan B wrote: > > Hi loom dev team > > The project I work on involves a great deal of native code where thread interaction between java and native code is vital. > Therefore the java Thread was extended to hold a reference to the native thread data structure. Once a java thread is taken from the thread pool the runtime structure must only be attached to native thread which is done directly by updating the pointer in the native thread structure. > > Like the following code illustrates > > var runtime = Runtime.current(); > unsafe.putLong(thread + ThreadOffset.runtime, runtime.ptr); > unsafe.putLong(thread + ThreadOffset.userContext, runner.getUserContext().getPtr()); > > Once the runtime state is attached any further JNI call to the native code can access the runtime data by calling (pthread_getspecific). > > This could be achieved by having a custom ThreadFactory for the carrier thread pool used by virtual threads and by having a callback mechanism which informs once a Virtual Thread is mounted to the native thread. > > Another problem which I see is that virtual threads hide the native java thread so native thread state can not be stored. > ThreadLocal returns the local state of the virtual thread which is not of much use as one can simply store this state in the Task (Runnable). > There should be a way to access the native thread and to store state on that. > > Thank you very much for considering these suggestions. > > - Stephan > From Alan.Bateman at oracle.com Sat Jan 7 21:37:44 2023 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 7 Jan 2023 21:37:44 +0000 Subject: ThreadFactory for carrier threads, access to native thread, callback when carrier thread is mounted In-Reply-To: References: Message-ID: <5ed19906-e1b3-84f0-160a-98db0f161024@oracle.com> On 07/01/2023 18:31, Stephan B wrote: > Hi loom dev team > > The project I work on involves a great deal of native code where thread interaction between java and native code is vital. > Therefore the java Thread was extended to hold a reference to the native thread data structure. Once a java thread is taken from the thread pool the runtime structure must only be attached to native thread which is done directly by updating the pointer in the native thread structure. > > Like the following code illustrates > > var runtime = Runtime.current(); > unsafe.putLong(thread + ThreadOffset.runtime, runtime.ptr); > unsafe.putLong(thread + ThreadOffset.userContext, runner.getUserContext().getPtr()); > > Once the runtime state is attached any further JNI call to the native code can access the runtime data by calling (pthread_getspecific). > > This could be achieved by having a custom ThreadFactory for the carrier thread pool used by virtual threads and by having a callback mechanism which informs once a Virtual Thread is mounted to the native thread. > > Another problem which I see is that virtual threads hide the native java thread so native thread state can not be stored. > ThreadLocal returns the local state of the virtual thread which is not of much use as one can simply store this state in the Task (Runnable). > There should be a way to access the native thread and to store state on that. So far, the main issue we have with native code is that a virtual thread is pinned to its carrier when executing native methods.? If you are blocking in native code, or calling through native frames back to Java and blocking, then it may not be too scalable. On thread-specific data (pthread_getspecific, etc.) then there isn't any supported way to change that at scheduling points. We did have prototype support for "custom schedulers" in early access builds for a long time that did provide the before/after hooks that could be used to do this. It's not something that most developers will every interact with directly but we do hope to explore the area further to decide what might be exposed. -Alan From stephan.j.bircher at gmail.com Sun Jan 8 00:37:31 2023 From: stephan.j.bircher at gmail.com (Stephan B) Date: Sun, 8 Jan 2023 01:37:31 +0100 Subject: ThreadFactory for carrier threads, access to native thread, callback when carrier thread is mounted In-Reply-To: <5ed19906-e1b3-84f0-160a-98db0f161024@oracle.com> References: <5ed19906-e1b3-84f0-160a-98db0f161024@oracle.com> Message-ID: Thank you for your insight. I'm aware that the thread is pinned and must be pinned while executing native code. However it would be great to have a JNI native API to unmount the thread while waiting for data and to mount again to an available carrier thread once data arrived. I guess however that this will never happen. I hope you will decide to expose more to give more flexibility to interact with native code. I know that there is a lot of discussion about how much to expose and how much to guard the programmer. Even though most developers will not need such flexibility I still believe it is vital to support it so that great products can be built which interact with native code. The JVM is so brillant and it would be a pity if it got too restricted. It makes me also a bit worried about what is going to happen to sun.misc.Unsafe as we use it heavily for memory IO. I hope it will stay and coexists with the new Foreign-Memory Access API. - Stephan > On 7 Jan 2023, at 22:37, Alan Bateman wrote: > > On 07/01/2023 18:31, Stephan B wrote: >> Hi loom dev team >> >> The project I work on involves a great deal of native code where thread interaction between java and native code is vital. >> Therefore the java Thread was extended to hold a reference to the native thread data structure. Once a java thread is taken from the thread pool the runtime structure must only be attached to native thread which is done directly by updating the pointer in the native thread structure. >> >> Like the following code illustrates >> >> var runtime = Runtime.current(); >> unsafe.putLong(thread + ThreadOffset.runtime, runtime.ptr); >> unsafe.putLong(thread + ThreadOffset.userContext, runner.getUserContext().getPtr()); >> >> Once the runtime state is attached any further JNI call to the native code can access the runtime data by calling (pthread_getspecific). >> >> This could be achieved by having a custom ThreadFactory for the carrier thread pool used by virtual threads and by having a callback mechanism which informs once a Virtual Thread is mounted to the native thread. >> >> Another problem which I see is that virtual threads hide the native java thread so native thread state can not be stored. >> ThreadLocal returns the local state of the virtual thread which is not of much use as one can simply store this state in the Task (Runnable). >> There should be a way to access the native thread and to store state on that. > > So far, the main issue we have with native code is that a virtual thread is pinned to its carrier when executing native methods. If you are blocking in native code, or calling through native frames back to Java and blocking, then it may not be too scalable. > > On thread-specific data (pthread_getspecific, etc.) then there isn't any supported way to change that at scheduling points. We did have prototype support for "custom schedulers" in early access builds for a long time that did provide the before/after hooks that could be used to do this. It's not something that most developers will every interact with directly but we do hope to explore the area further to decide what might be exposed. > > -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From rengels at ix.netcom.com Sun Jan 8 03:37:45 2023 From: rengels at ix.netcom.com (Robert Engels) Date: Sat, 7 Jan 2023 21:37:45 -0600 Subject: ThreadFactory for carrier threads, access to native thread, callback when carrier thread is mounted In-Reply-To: References: Message-ID: You can easily implement this today. This is essentially an async request by the vthread. Return immediately from the native back to Java with a request id. Park the Java thread. Have a single native thread Java poller that parks in the native code waiting for any async requests to complete - the poller returns to Java and wakes the vthread - which then calls back into native to get the results which should be available to so no blocking required and you have very efficient usage for the carrier threads. This does require having async in your native library. > On Jan 7, 2023, at 6:38 PM, Stephan B wrote: > > ?Thank you for your insight. I'm aware that the thread is pinned and must be pinned while executing native code. However it would be great to have a JNI native API to unmount the thread while waiting for data and to mount again to an available carrier thread once data arrived. I guess however that this will never happen. > > I hope you will decide to expose more to give more flexibility to interact with native code. I know that there is a lot of discussion about how much to expose and how much to guard the programmer. Even though most developers will not need such flexibility I still believe it is vital to support it so that great products can be built which interact with native code. The JVM is so brillant and it would be a pity if it got too restricted. It makes me also a bit worried about what is going to happen to sun.misc.Unsafe as we use it heavily for memory IO. I hope it will stay and coexists with the new Foreign-Memory Access API. > > - Stephan > > >> On 7 Jan 2023, at 22:37, Alan Bateman wrote: >> >>> On 07/01/2023 18:31, Stephan B wrote: >>> Hi loom dev team >>> >>> The project I work on involves a great deal of native code where thread interaction between java and native code is vital. >>> Therefore the java Thread was extended to hold a reference to the native thread data structure. Once a java thread is taken from the thread pool the runtime structure must only be attached to native thread which is done directly by updating the pointer in the native thread structure. >>> >>> Like the following code illustrates >>> >>> var runtime = Runtime.current(); >>> unsafe.putLong(thread + ThreadOffset.runtime, runtime.ptr); >>> unsafe.putLong(thread + ThreadOffset.userContext, runner.getUserContext().getPtr()); >>> >>> Once the runtime state is attached any further JNI call to the native code can access the runtime data by calling (pthread_getspecific). >>> >>> This could be achieved by having a custom ThreadFactory for the carrier thread pool used by virtual threads and by having a callback mechanism which informs once a Virtual Thread is mounted to the native thread. >>> >>> Another problem which I see is that virtual threads hide the native java thread so native thread state can not be stored. >>> ThreadLocal returns the local state of the virtual thread which is not of much use as one can simply store this state in the Task (Runnable). >>> There should be a way to access the native thread and to store state on that. >> >> So far, the main issue we have with native code is that a virtual thread is pinned to its carrier when executing native methods. If you are blocking in native code, or calling through native frames back to Java and blocking, then it may not be too scalable. >> >> On thread-specific data (pthread_getspecific, etc.) then there isn't any supported way to change that at scheduling points. We did have prototype support for "custom schedulers" in early access builds for a long time that did provide the before/after hooks that could be used to do this. It's not something that most developers will every interact with directly but we do hope to explore the area further to decide what might be exposed. >> >> -Alan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rengels at ix.netcom.com Sun Jan 8 18:58:19 2023 From: rengels at ix.netcom.com (robert engels) Date: Sun, 8 Jan 2023 12:58:19 -0600 Subject: effectiveness of jdk.virtualThreadScheduler.maxPoolSize In-Reply-To: <1389ae83-25fb-ebc5-4710-268b4499865e@oracle.com> References: <1389ae83-25fb-ebc5-4710-268b4499865e@oracle.com> Message-ID: <8DB91B8E-39F7-4C86-8641-97EAA1653BF1@ix.netcom.com> But even if not using spin locks - with fair scheduling you expect shorter runtime tasks to be completed before long-running cpu bound tasks. The linux scheduler will lower the priority of threads that hog the cpu too much to facilitate this even further (or use a scheduler type of ?batch/idle? - i.e. only run when nothing else needs to run). So if very short tasks get stuck behind long-running cpu bound tasks this is unexpected behavior - it is not necessarily incorrect. If you spawned more carrier threads (i.e. when the scheduler feels the tasks are not making ?progress?) you give more of a chance for the OS scheduler to give cpu time to the short lived tasks. I think that is what the OP was trying to say. > On Jan 7, 2023, at 6:48 AM, Alan Bateman wrote: > > On 06/01/2023 19:48, Robert Engels wrote: >> The point is that spin locks are valid. If used with vthreads you will quickly lock the pool - if the unlocker is behind the others. With time sharing that shouldn?t happen. > > Spinlocks are usually only used for locks that that are held for very brief periods. If a virtual thread is doing I/O or running other code that causes it to preempted while hold such a lock then yes, then deadlocks like this could arise. > > We expect that the maintainers of low level code with their own lock implementations, or code doing spin waits to avoid parking, will need to make some changes to work efficiently with virtual threads and with greedy schedulers. Given that parking is cheap then it might be that code goes straight to park when running in a virtual thread. For spin locks it might be that it changes to be more hybrid so that it is efficient when executed by both platform and virtual threads, and when used together. > > -Alan > > > From stephan.j.bircher at gmail.com Sun Jan 8 19:12:34 2023 From: stephan.j.bircher at gmail.com (Stephan B) Date: Sun, 8 Jan 2023 20:12:34 +0100 Subject: ThreadFactory for carrier threads, access to native thread, callback when carrier thread is mounted In-Reply-To: References: Message-ID: <8994FC67-718B-4B49-9A90-CB107B13F21A@gmail.com> Thank you for your input. I have done some more reading and prototyping with virtual threads to get a deeper understanding. Virtual threads are really great! The API might be sufficient to solve all my challenges with native code otherwise I let you know. However it needs some refactoring which I believe is worth doing considering the benefits. - Stephan > On 8 Jan 2023, at 04:37, Robert Engels wrote: > > You can easily implement this today. This is essentially an async request by the vthread. Return immediately from the native back to Java with a request id. Park the Java thread. Have a single native thread Java poller that parks in the native code waiting for any async requests to complete - the poller returns to Java and wakes the vthread - which then calls back into native to get the results which should be available to so no blocking required and you have very efficient usage for the carrier threads. > > This does require having async in your native library. > >> On Jan 7, 2023, at 6:38 PM, Stephan B wrote: >> >> ?Thank you for your insight. I'm aware that the thread is pinned and must be pinned while executing native code. However it would be great to have a JNI native API to unmount the thread while waiting for data and to mount again to an available carrier thread once data arrived. I guess however that this will never happen. >> >> I hope you will decide to expose more to give more flexibility to interact with native code. I know that there is a lot of discussion about how much to expose and how much to guard the programmer. Even though most developers will not need such flexibility I still believe it is vital to support it so that great products can be built which interact with native code. The JVM is so brillant and it would be a pity if it got too restricted. It makes me also a bit worried about what is going to happen to sun.misc.Unsafe as we use it heavily for memory IO. I hope it will stay and coexists with the new Foreign-Memory Access API. >> >> - Stephan >> >> >>> On 7 Jan 2023, at 22:37, Alan Bateman wrote: >>> >>> On 07/01/2023 18:31, Stephan B wrote: >>>> Hi loom dev team >>>> >>>> The project I work on involves a great deal of native code where thread interaction between java and native code is vital. >>>> Therefore the java Thread was extended to hold a reference to the native thread data structure. Once a java thread is taken from the thread pool the runtime structure must only be attached to native thread which is done directly by updating the pointer in the native thread structure. >>>> >>>> Like the following code illustrates >>>> >>>> var runtime = Runtime.current(); >>>> unsafe.putLong(thread + ThreadOffset.runtime, runtime.ptr); >>>> unsafe.putLong(thread + ThreadOffset.userContext, runner.getUserContext().getPtr()); >>>> >>>> Once the runtime state is attached any further JNI call to the native code can access the runtime data by calling (pthread_getspecific). >>>> >>>> This could be achieved by having a custom ThreadFactory for the carrier thread pool used by virtual threads and by having a callback mechanism which informs once a Virtual Thread is mounted to the native thread. >>>> >>>> Another problem which I see is that virtual threads hide the native java thread so native thread state can not be stored. >>>> ThreadLocal returns the local state of the virtual thread which is not of much use as one can simply store this state in the Task (Runnable). >>>> There should be a way to access the native thread and to store state on that. >>> >>> So far, the main issue we have with native code is that a virtual thread is pinned to its carrier when executing native methods. If you are blocking in native code, or calling through native frames back to Java and blocking, then it may not be too scalable. >>> >>> On thread-specific data (pthread_getspecific, etc.) then there isn't any supported way to change that at scheduling points. We did have prototype support for "custom schedulers" in early access builds for a long time that did provide the before/after hooks that could be used to do this. It's not something that most developers will every interact with directly but we do hope to explore the area further to decide what might be exposed. >>> >>> -Alan >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron.pressler at oracle.com Sun Jan 8 23:05:29 2023 From: ron.pressler at oracle.com (Ron Pressler) Date: Sun, 8 Jan 2023 23:05:29 +0000 Subject: effectiveness of jdk.virtualThreadScheduler.maxPoolSize In-Reply-To: <8DB91B8E-39F7-4C86-8641-97EAA1653BF1@ix.netcom.com> References: <1389ae83-25fb-ebc5-4710-268b4499865e@oracle.com> <8DB91B8E-39F7-4C86-8641-97EAA1653BF1@ix.netcom.com> Message-ID: <0EF9E9AD-6BD4-44EE-94EB-A480953495B1@oracle.com> > On 8 Jan 2023, at 18:58, robert engels wrote: > > But even if not using spin locks - with fair scheduling you expect shorter runtime tasks to be completed before long-running cpu bound tasks. The linux scheduler will lower the priority of threads that hog the cpu too much to facilitate this even further (or use a scheduler type of ?batch/idle? - i.e. only run when nothing else needs to run). > If you use spin locks and have significantly more threads than cores, you may well experience an orders of magnitud slow-down. I.e., you don?t use spin locks and rely on time-sharing to make them work well ? there won?t be a deadlock, but you won?t get an acceptable behaviour, either. > So if very short tasks get stuck behind long-running cpu bound tasks this is unexpected behavior - it is not necessarily incorrect. If you spawned more carrier threads (i.e. when the scheduler feels the tasks are not making ?progress?) you give more of a chance for the OS scheduler to give cpu time to the short lived tasks. I think that is what the OP was trying to say. This may seem obvious at first, but the easiest way to explain why it?s hard to find an actual problem caused by this (and why you don?t actually rely on the ?expected behaviour?) is to remember that the OS will do this (pretty-much) only when your CPU is at 100%. But at that point, there?s very little the OS can do to make your server behave well. When you?re at 100% CPU for any significant duration, since requests keep coming, they?re piling up and your server is now unstable. In other words, time sharing only kicks in when it can?t do much good. In non-realtime kernels, time-sharing is mostly used to run a small number of background tasks or to keep the machine responsive to an operator in cases of emergency. Clever scheduling is not enough to compensate for lack of resources. Time sharing can also be useful for to smooth over the latency of CPU-bound batch-processing tasks, but since it only makes sense to run only a few of them in parallel, virtual threads can?t give you any benefit there anyway. However, as I?ve said multiple times already, we don?t rule out the possibility of a workload where time sharing could solve an actual problem. So if you encounter a problem, please report it. ? Ron From rengels at ix.netcom.com Sun Jan 8 23:19:51 2023 From: rengels at ix.netcom.com (Robert Engels) Date: Sun, 8 Jan 2023 17:19:51 -0600 Subject: effectiveness of jdk.virtualThreadScheduler.maxPoolSize In-Reply-To: <0EF9E9AD-6BD4-44EE-94EB-A480953495B1@oracle.com> References: <0EF9E9AD-6BD4-44EE-94EB-A480953495B1@oracle.com> Message-ID: <90C07807-C611-4919-A387-EC789E9151A8@ix.netcom.com> We?ll have to agree to disagree. I think servers routinely hit 100% cpu and rely on the scheduler to deprioritize tasks to be fair - maybe not ?forever? but for extended periods. This is not dissimilar to the various background tools for cosmos searching that use the available cycles - as long as nothing else needs them. I am guessing a lot of long running simulations work similarly. As I?ve said though I don?t think it?s a huge deal - move things that have to run to their own native thread pool. Maybe that?s a better and simpler solution than trying to add time slicing to vthreads anyway. > On Jan 8, 2023, at 5:05 PM, Ron Pressler wrote: > > ? > >> On 8 Jan 2023, at 18:58, robert engels wrote: >> >> But even if not using spin locks - with fair scheduling you expect shorter runtime tasks to be completed before long-running cpu bound tasks. The linux scheduler will lower the priority of threads that hog the cpu too much to facilitate this even further (or use a scheduler type of ?batch/idle? - i.e. only run when nothing else needs to run). >> > > If you use spin locks and have significantly more threads than cores, you may well experience an orders of magnitud slow-down. I.e., you don?t use spin locks and rely on time-sharing to make them work well ? there won?t be a deadlock, but you won?t get an acceptable behaviour, either. > > >> So if very short tasks get stuck behind long-running cpu bound tasks this is unexpected behavior - it is not necessarily incorrect. If you spawned more carrier threads (i.e. when the scheduler feels the tasks are not making ?progress?) you give more of a chance for the OS scheduler to give cpu time to the short lived tasks. I think that is what the OP was trying to say. > > This may seem obvious at first, but the easiest way to explain why it?s hard to find an actual problem caused by this (and why you don?t actually rely on the ?expected behaviour?) is to remember that the OS will do this (pretty-much) only when your CPU is at 100%. But at that point, there?s very little the OS can do to make your server behave well. When you?re at 100% CPU for any significant duration, since requests keep coming, they?re piling up and your server is now unstable. In other words, time sharing only kicks in when it can?t do much good. > > In non-realtime kernels, time-sharing is mostly used to run a small number of background tasks or to keep the machine responsive to an operator in cases of emergency. Clever scheduling is not enough to compensate for lack of resources. Time sharing can also be useful for to smooth over the latency of CPU-bound batch-processing tasks, but since it only makes sense to run only a few of them in parallel, virtual threads can?t give you any benefit there anyway. > > However, as I?ve said multiple times already, we don?t rule out the possibility of a workload where time sharing could solve an actual problem. So if you encounter a problem, please report it. > > ? Ron From ron.pressler at oracle.com Mon Jan 9 00:07:19 2023 From: ron.pressler at oracle.com (Ron Pressler) Date: Mon, 9 Jan 2023 00:07:19 +0000 Subject: effectiveness of jdk.virtualThreadScheduler.maxPoolSize In-Reply-To: <90C07807-C611-4919-A387-EC789E9151A8@ix.netcom.com> References: <0EF9E9AD-6BD4-44EE-94EB-A480953495B1@oracle.com> <90C07807-C611-4919-A387-EC789E9151A8@ix.netcom.com> Message-ID: I don?t know how to evaluate and compare solutions before knowing what the problem they supposedly solve is, so I have no way of knowing which if any of time-sharing for virtual threads or adding scheduler workers is a better solution to a problem that hasn?t been reported. If servers employing virtual threads tend to reach conditions where time-sharing could help, then when the problem is reported we would be more than happy to fix it with that solution. What I?m trying to convey is not that I think your hypothesis must be wrong, but that it is not necessarily correct, either, and so we are simply unable to fix hypothetical bugs. It really doesn?t matter how strongly anyone feels that some problem *could* arise. We cannot fix bugs before they are reported, so that we can assess their severity, prioritise them, and consider solutions. If you do find a problem with virtual threads, please report it to this mailing list. ? Ron On 8 Jan 2023, at 23:19, Robert Engels > wrote: We?ll have to agree to disagree. I think servers routinely hit 100% cpu and rely on the scheduler to deprioritize tasks to be fair - maybe not ?forever? but for extended periods. This is not dissimilar to the various background tools for cosmos searching that use the available cycles - as long as nothing else needs them. I am guessing a lot of long running simulations work similarly. As I?ve said though I don?t think it?s a huge deal - move things that have to run to their own native thread pool. Maybe that?s a better and simpler solution than trying to add time slicing to vthreads anyway. On Jan 8, 2023, at 5:05 PM, Ron Pressler > wrote: ? On 8 Jan 2023, at 18:58, robert engels > wrote: But even if not using spin locks - with fair scheduling you expect shorter runtime tasks to be completed before long-running cpu bound tasks. The linux scheduler will lower the priority of threads that hog the cpu too much to facilitate this even further (or use a scheduler type of ?batch/idle? - i.e. only run when nothing else needs to run). If you use spin locks and have significantly more threads than cores, you may well experience an orders of magnitud slow-down. I.e., you don?t use spin locks and rely on time-sharing to make them work well ? there won?t be a deadlock, but you won?t get an acceptable behaviour, either. So if very short tasks get stuck behind long-running cpu bound tasks this is unexpected behavior - it is not necessarily incorrect. If you spawned more carrier threads (i.e. when the scheduler feels the tasks are not making ?progress?) you give more of a chance for the OS scheduler to give cpu time to the short lived tasks. I think that is what the OP was trying to say. This may seem obvious at first, but the easiest way to explain why it?s hard to find an actual problem caused by this (and why you don?t actually rely on the ?expected behaviour?) is to remember that the OS will do this (pretty-much) only when your CPU is at 100%. But at that point, there?s very little the OS can do to make your server behave well. When you?re at 100% CPU for any significant duration, since requests keep coming, they?re piling up and your server is now unstable. In other words, time sharing only kicks in when it can?t do much good. In non-realtime kernels, time-sharing is mostly used to run a small number of background tasks or to keep the machine responsive to an operator in cases of emergency. Clever scheduling is not enough to compensate for lack of resources. Time sharing can also be useful for to smooth over the latency of CPU-bound batch-processing tasks, but since it only makes sense to run only a few of them in parallel, virtual threads can?t give you any benefit there anyway. However, as I?ve said multiple times already, we don?t rule out the possibility of a workload where time sharing could solve an actual problem. So if you encounter a problem, please report it. ? Ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnaud.masson at fr.ibm.com Mon Jan 9 08:46:44 2023 From: arnaud.masson at fr.ibm.com (Arnaud Masson) Date: Mon, 9 Jan 2023 08:46:44 +0000 Subject: effectiveness of jdk.virtualThreadScheduler.maxPoolSize In-Reply-To: References: <0EF9E9AD-6BD4-44EE-94EB-A480953495B1@oracle.com> <90C07807-C611-4919-A387-EC789E9151A8@ix.netcom.com> Message-ID: Side note : it seems ?more? preemptive time sharing was added for goroutines in Go 1.14 to avoid the kind of scheduling starvation we discussed: https://medium.com/a-journey-with-go/go-asynchronous-preemption-b5194227371c Thanks Arnaud I don?t know how to ev I don?t know how to evaluate and compare solutions before knowing what the problem they supposedly solve is, so I have no way of knowing which if any of time-sharing for virtual threads or adding scheduler workers is a better solution to a problem that hasn?t been reported. If servers employing virtual threads tend to reach conditions where time-sharing could help, then when the problem is reported we would be more than happy to fix it with that solution. What I?m trying to convey is not that I think your hypothesis must be wrong, but that it is not necessarily correct, either, and so we are simply unable to fix hypothetical bugs. It really doesn?t matter how strongly anyone feels that some problem *could* arise. We cannot fix bugs before they are reported, so that we can assess their severity, prioritise them, and consider solutions. If you do find a problem with virtual threads, please report it to this mailing list. ? Ron On 8 Jan 2023, at 23:19, Robert Engels > wrote: We?ll have to agree to disagree. I think servers routinely hit 100% cpu and rely on the scheduler to deprioritize tasks to be fair - maybe not ?forever? but for extended periods. This is not dissimilar to the various background tools for cosmos searching that use the available cycles - as long as nothing else needs them. I am guessing a lot of long running simulations work similarly. As I?ve said though I don?t think it?s a huge deal - move things that have to run to their own native thread pool. Maybe that?s a better and simpler solution than trying to add time slicing to vthreads anyway. On Jan 8, 2023, at 5:05 PM, Ron Pressler > wrote: ? On 8 Jan 2023, at 18:58, robert engels > wrote: But even if not using spin locks - with fair scheduling you expect shorter runtime tasks to be completed before long-running cpu bound tasks. The linux scheduler will lower the priority of threads that hog the cpu too much to facilitate this even further (or use a scheduler type of ?batch/idle? - i.e. only run when nothing else needs to run). If you use spin locks and have significantly more threads than cores, you may well experience an orders of magnitud slow-down. I.e., you don?t use spin locks and rely on time-sharing to make them work well ? there won?t be a deadlock, but you won?t get an acceptable behaviour, either. So if very short tasks get stuck behind long-running cpu bound tasks this is unexpected behavior - it is not necessarily incorrect. If you spawned more carrier threads (i.e. when the scheduler feels the tasks are not making ?progress?) you give more of a chance for the OS scheduler to give cpu time to the short lived tasks. I think that is what the OP was trying to say. This may seem obvious at first, but the easiest way to explain why it?s hard to find an actual problem caused by this (and why you don?t actually rely on the ?expected behaviour?) is to remember that the OS will do this (pretty-much) only when your CPU is at 100%. But at that point, there?s very little the OS can do to make your server behave well. When you?re at 100% CPU for any significant duration, since requests keep coming, they?re piling up and your server is now unstable. In other words, time sharing only kicks in when it can?t do much good. In non-realtime kernels, time-sharing is mostly used to run a small number of background tasks or to keep the machine responsive to an operator in cases of emergency. Clever scheduling is not enough to compensate for lack of resources. Time sharing can also be useful for to smooth over the latency of CPU-bound batch-processing tasks, but since it only makes sense to run only a few of them in parallel, virtual threads can?t give you any benefit there anyway. However, as I?ve said multiple times already, we don?t rule out the possibility of a workload where time sharing could solve an actual problem. So if you encounter a problem, please report it. ? Ron Unless otherwise stated above: Compagnie IBM France Si?ge Social : 17, avenue de l'Europe, 92275 Bois-Colombes Cedex RCS Nanterre 552 118 465 Forme Sociale : S.A.S. Capital Social : 664 069 390,60 ? SIRET : 552 118 465 03644 - Code NAF 6203Z -------------- next part -------------- An HTML attachment was scrubbed... URL: From spullara at gmail.com Mon Jan 9 08:48:58 2023 From: spullara at gmail.com (Sam Pullara) Date: Mon, 9 Jan 2023 00:48:58 -0800 Subject: effectiveness of jdk.virtualThreadScheduler.maxPoolSize In-Reply-To: References: <0EF9E9AD-6BD4-44EE-94EB-A480953495B1@oracle.com> <90C07807-C611-4919-A387-EC789E9151A8@ix.netcom.com> Message-ID: Ron, I think you are being purposefully obtuse by not recognizing that some folks are going to run high CPU jobs in vthreads. The proof is with the folks using Go that already encountered it and fixed it. On Mon, Jan 9, 2023 at 12:46 AM Arnaud Masson wrote: > Side note : it seems ?more? preemptive time sharing was added for > goroutines in Go 1.14 to avoid the kind of scheduling starvation we > discussed: > > > > > https://medium.com/a-journey-with-go/go-asynchronous-preemption-b5194227371c > > > > Thanks > > Arnaud > > > > I don?t know how to ev > > I don?t know how to evaluate and compare solutions before knowing what the > problem they supposedly solve is, so I have no way of knowing which if any > of time-sharing for virtual threads or adding scheduler workers is a better > solution to a problem that hasn?t been reported. > > > > If servers employing virtual threads tend to reach conditions where > time-sharing could help, then when the problem is reported we would be more > than happy to fix it with that solution. What I?m trying to convey is not > that I think your hypothesis must be wrong, but that it is not necessarily > correct, either, and so we are simply unable to fix hypothetical bugs. It > really doesn?t matter how strongly anyone feels that some problem *could* > arise. We cannot fix bugs before they are reported, so that we can assess > their severity, prioritise them, and consider solutions. If you do find a > problem with virtual threads, please report it to this mailing list. > > > > ? Ron > > > > > > > > On 8 Jan 2023, at 23:19, Robert Engels wrote: > > > > We?ll have to agree to disagree. I think servers routinely hit 100% cpu > and rely on the scheduler to deprioritize tasks to be fair - maybe not > ?forever? but for extended periods. > > This is not dissimilar to the various background tools for cosmos > searching that use the available cycles - as long as nothing else needs > them. > > I am guessing a lot of long running simulations work similarly. > > As I?ve said though I don?t think it?s a huge deal - move things that have > to run to their own native thread pool. Maybe that?s a better and simpler > solution than trying to add time slicing to vthreads anyway. > > > On Jan 8, 2023, at 5:05 PM, Ron Pressler wrote: > > ? > > > On 8 Jan 2023, at 18:58, robert engels wrote: > > But even if not using spin locks - with fair scheduling you expect shorter > runtime tasks to be completed before long-running cpu bound tasks. The > linux scheduler will lower the priority of threads that hog the cpu too > much to facilitate this even further (or use a scheduler type of > ?batch/idle? - i.e. only run when nothing else needs to run). > > > If you use spin locks and have significantly more threads than cores, you > may well experience an orders of magnitud slow-down. I.e., you don?t use > spin locks and rely on time-sharing to make them work well ? there won?t be > a deadlock, but you won?t get an acceptable behaviour, either. > > > > So if very short tasks get stuck behind long-running cpu bound tasks this > is unexpected behavior - it is not necessarily incorrect. If you spawned > more carrier threads (i.e. when the scheduler feels the tasks are not > making ?progress?) you give more of a chance for the OS scheduler to give > cpu time to the short lived tasks. I think that is what the OP was trying > to say. > > > This may seem obvious at first, but the easiest way to explain why it?s > hard to find an actual problem caused by this (and why you don?t actually > rely on the ?expected behaviour?) is to remember that the OS will do this > (pretty-much) only when your CPU is at 100%. But at that point, there?s > very little the OS can do to make your server behave well. When you?re at > 100% CPU for any significant duration, since requests keep coming, they?re > piling up and your server is now unstable. In other words, time sharing > only kicks in when it can?t do much good. > > In non-realtime kernels, time-sharing is mostly used to run a small number > of background tasks or to keep the machine responsive to an operator in > cases of emergency. Clever scheduling is not enough to compensate for lack > of resources. Time sharing can also be useful for to smooth over the > latency of CPU-bound batch-processing tasks, but since it only makes sense > to run only a few of them in parallel, virtual threads can?t give you any > benefit there anyway. > > However, as I?ve said multiple times already, we don?t rule out the > possibility of a workload where time sharing could solve an actual problem. > So if you encounter a problem, please report it. > > ? Ron > > > Unless otherwise stated above: > > Compagnie IBM France > Si?ge Social : 17, avenue de l'Europe, 92275 Bois-Colombes Cedex > RCS Nanterre 552 118 465 > Forme Sociale : S.A.S. > Capital Social : 664 069 390,60 ? > SIRET : 552 118 465 03644 - Code NAF 6203Z > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Mon Jan 9 09:01:02 2023 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 9 Jan 2023 09:01:02 +0000 Subject: effectiveness of jdk.virtualThreadScheduler.maxPoolSize In-Reply-To: References: <0EF9E9AD-6BD4-44EE-94EB-A480953495B1@oracle.com> <90C07807-C611-4919-A387-EC789E9151A8@ix.netcom.com> Message-ID: On 09/01/2023 08:46, Arnaud Masson wrote: > > Side note?: it seems ?more? preemptive time sharing was added for > goroutines in Go 1.14 to avoid the kind of scheduling starvation we > discussed: > > https://medium.com/a-journey-with-go/go-asynchronous-preemption-b5194227371c > > As I understand it, Go doesn't expose the equivalent of platform threads so that may have been a forced move. For Project Loom, this is the "custom scheduler" topic where the primitive for forced preemption is the primitive required to do time sharing. It will take a bit of time to figure out if/how this might be exposed, and time will tell if we really this with the default scheduler. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron.pressler at oracle.com Mon Jan 9 11:36:42 2023 From: ron.pressler at oracle.com (Ron Pressler) Date: Mon, 9 Jan 2023 11:36:42 +0000 Subject: effectiveness of jdk.virtualThreadScheduler.maxPoolSize In-Reply-To: References: <0EF9E9AD-6BD4-44EE-94EB-A480953495B1@oracle.com> <90C07807-C611-4919-A387-EC789E9151A8@ix.netcom.com> Message-ID: <231464EE-3DD7-4BFF-9751-D7697A671576@oracle.com> Great, then one someone who runs CPU-heavy jobs that are appropriate for virtual threads presents a problem the?ve encountered that could be solved by some form of time-sharing, we?ll take a look. For the time being, we have a hypothesis that one or more problems could occur, and a further hypothesis that some class of solutions might fix or mitigate them. Unfortunately, theses hypotheses are not presently actionable. I don?t know what problem Go?s maintainers solve with time-sharing. Maybe they just want to solve Go?s lack of convenient access to a scheduler with time-sharing even in the case of background processing tasks ? a problem that Java doesn?t have ? or perhaps they?ve managed to identify common server workloads that could be helped by time-sharing, in which case we?d love to see those workloads so that we can make sure our fix works. I am not at all resistant to adding time-sharing to the virtual thread scheduler. I am resistant to fixing bugs that have not been reported. I have said many times ? and not just on the mailing lists ? that the best and often only way to get a some change made to Java is to report a problem. You might have noticed that all JEPs start with a motivation section that attempts to clearly present a problem that?s encountered by Java?s users (and sometimes maintainers) and analyse its relative severity to justify the proposed solution. That is usually the JEP?s most important section (and the section we typically spend most time writing) because the most important thing is to understand the problem you?re trying to tackle. Every change has a cost. A feature might add overhead that harms workloads that don?t benefit from it, and it certainly has an opportunity cost. Neither of these is disqualifying, but we simply cannot judge the pros and cons of doing something until we can weigh some problem against another, and we can?t even get started on this process until we have a problem in front of us. We *have* been presented with a problem that some specific kind of time-sharing can solve (postponing a batch job that?s consuming resources to run at a much later time), and it is one of the reasons we?ve added custom schedulers that will be able to employ it to our roadmap. It is certainly possible that the lack of time-sharing causes problems that need addressing in the default (currently only) virtual-thread scheduler ? I am not at all dismissing that possibility ? but there?s not much we can do until those problems are actually reported to us, which would allow us to know more about when those problems occur, how frequently, and what kind of time-sharing can assist in which circumstances and to what degree. There?s no point in trying to convince us of something we are already convinced of, namely that the possibility exists that some virtual thread workloads could be significantly helped by time-sharing. In fact, I?ve mentioned that possibility on this mailing list a few times already. If the problems are common, now that more people are giving virtual threads a try, I expect they will be reported by someone soon enough and we could start the process of tackling them. ? Ron On 9 Jan 2023, at 08:48, Sam Pullara > wrote: Ron, I think you are being purposefully obtuse by not recognizing that some folks are going to run high CPU jobs in vthreads. The proof is with the folks using Go that already encountered it and fixed it. On Mon, Jan 9, 2023 at 12:46 AM Arnaud Masson > wrote: Side note : it seems ?more? preemptive time sharing was added for goroutines in Go 1.14 to avoid the kind of scheduling starvation we discussed: https://medium.com/a-journey-with-go/go-asynchronous-preemption-b5194227371c Thanks Arnaud -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnaud.masson at fr.ibm.com Mon Jan 9 12:04:30 2023 From: arnaud.masson at fr.ibm.com (Arnaud Masson) Date: Mon, 9 Jan 2023 12:04:30 +0000 Subject: effectiveness of jdk.virtualThreadScheduler.maxPoolSize In-Reply-To: <231464EE-3DD7-4BFF-9751-D7697A671576@oracle.com> References: <0EF9E9AD-6BD4-44EE-94EB-A480953495B1@oracle.com> <90C07807-C611-4919-A387-EC789E9151A8@ix.netcom.com> <231464EE-3DD7-4BFF-9751-D7697A671576@oracle.com> Message-ID: I doubt it will suddenly convince anyone, but I wrote a minimal example to illustrate the concrete problem. With the classic thread executor, the normal requests (fastIORequest) complete quickly even during concurrent CPU requests (slowCPURequest), while using the default Loom executor they are stuck for some time. Arnaud package org.example; import java.time.Duration; import java.time.Instant; import java.util.ArrayList; import java.util.Timer; import java.util.TimerTask; import java.util.concurrent.Executors; import java.util.concurrent.Future; public class MixedServer { static final Instant t0 = Instant.now(); static long slowCPURequest(String name, Instant posted) throws Exception { long t = 0; var n = 1e9; // slow CPU-only stuff: e.g. image codec, XML manip, collection iteration, ... for (int i = 0; i < n; i++) { t = t + 2; } var completed = Instant.now(); System.out.println(Duration.between(t0, Instant.now()) + " - " + name + " completed (duration: " + Duration.between(posted, completed) + ")"); return t; } static Object fastIORequest(Instant posted) throws Exception { // IO stuff, e.g. JDBC call // (but sleep would have the same effect for this test, i.e. block the thread) Thread.sleep(2); var completed = Instant.now(); System.out.println(Duration.between(t0, Instant.now()) + " - fast IO task" + " completed (duration: " + Duration.between(posted, completed) + ")"); return null; } public static void main(String[] args) throws Exception { var executor = Executors.newVirtualThreadPerTaskExecutor(); // unfair //Executors.newCachedThreadPool(); // fair var timer = new Timer(); timer.schedule(new TimerTask() { @Override public void run() { var posted = Instant.now(); executor.submit(() -> fastIORequest(posted)); } }, 100, 100); var futures = new ArrayList(); for (int i = 0; i < 60; i++) { final var name = "Task_" + i; var posted = Instant.now(); futures.add(executor.submit(() -> slowCPURequest(name, posted))); } for (Future f: futures) f.get(); System.out.println("--- done ---"); executor.shutdownNow(); timer.cancel(); } } Great, then one someone who runs CPU-heavy jobs that are appropriate for virtual threads presents a problem the?ve encountered that could be solved by some form of time-sharing, we?ll take a look. For the time being, we have a hypothesis that ZjQcmQRYFpfptBannerStart Great, then one someone who runs CPU-heavy jobs that are appropriate for virtual threads presents a problem the?ve encountered that could be solved by some form of time-sharing, we?ll take a look. For the time being, we have a hypothesis that one or more problems could occur, and a further hypothesis that some class of solutions might fix or mitigate them. Unfortunately, theses hypotheses are not presently actionable. I don?t know what problem Go?s maintainers solve with time-sharing. Maybe they just want to solve Go?s lack of convenient access to a scheduler with time-sharing even in the case of background processing tasks ? a problem that Java doesn?t have ? or perhaps they?ve managed to identify common server workloads that could be helped by time-sharing, in which case we?d love to see those workloads so that we can make sure our fix works. I am not at all resistant to adding time-sharing to the virtual thread scheduler. I am resistant to fixing bugs that have not been reported. I have said many times ? and not just on the mailing lists ? that the best and often only way to get a some change made to Java is to report a problem. You might have noticed that all JEPs start with a motivation section that attempts to clearly present a problem that?s encountered by Java?s users (and sometimes maintainers) and analyse its relative severity to justify the proposed solution. That is usually the JEP?s most important section (and the section we typically spend most time writing) because the most important thing is to understand the problem you?re trying to tackle. Every change has a cost. A feature might add overhead that harms workloads that don?t benefit from it, and it certainly has an opportunity cost. Neither of these is disqualifying, but we simply cannot judge the pros and cons of doing something until we can weigh some problem against another, and we can?t even get started on this process until we have a problem in front of us. We *have* been presented with a problem that some specific kind of time-sharing can solve (postponing a batch job that?s consuming resources to run at a much later time), and it is one of the reasons we?ve added custom schedulers that will be able to employ it to our roadmap. It is certainly possible that the lack of time-sharing causes problems that need addressing in the default (currently only) virtual-thread scheduler ? I am not at all dismissing that possibility ? but there?s not much we can do until those problems are actually reported to us, which would allow us to know more about when those problems occur, how frequently, and what kind of time-sharing can assist in which circumstances and to what degree. There?s no point in trying to convince us of something we are already convinced of, namely that the possibility exists that some virtual thread workloads could be significantly helped by time-sharing. In fact, I?ve mentioned that possibility on this mailing list a few times already. If the problems are common, now that more people are giving virtual threads a try, I expect they will be reported by someone soon enough and we could start the process of tackling them. ? Ron On 9 Jan 2023, at 08:48, Sam Pullara > wrote: Ron, I think you are being purposefully obtuse by not recognizing that some folks are going to run high CPU jobs in vthreads. The proof is with the folks using Go that already encountered it and fixed it. On Mon, Jan 9, 2023 at 12:46 AM Arnaud Masson > wrote: Side note : it seems ?more? preemptive time sharing was added for goroutines in Go 1.14 to avoid the kind of scheduling starvation we discussed: https://medium.com/a-journey-with-go/go-asynchronous-preemption-b5194227371c Thanks Arnaud Unless otherwise stated above: Compagnie IBM France Si?ge Social : 17, avenue de l'Europe, 92275 Bois-Colombes Cedex RCS Nanterre 552 118 465 Forme Sociale : S.A.S. Capital Social : 664 069 390,60 ? SIRET : 552 118 465 03644 - Code NAF 6203Z -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron.pressler at oracle.com Mon Jan 9 12:58:56 2023 From: ron.pressler at oracle.com (Ron Pressler) Date: Mon, 9 Jan 2023 12:58:56 +0000 Subject: effectiveness of jdk.virtualThreadScheduler.maxPoolSize In-Reply-To: References: <0EF9E9AD-6BD4-44EE-94EB-A480953495B1@oracle.com> <90C07807-C611-4919-A387-EC789E9151A8@ix.netcom.com> <231464EE-3DD7-4BFF-9751-D7697A671576@oracle.com> Message-ID: As I wrote to the mailing list some years ago, the virtual thread scheduler is designed in a way that will create this phenomenon, and it is done in this way because two things are unclear: 1. Whether or not this phenomenon is a problem, and 2. Whether time-sharing could help if it is. What is unclear is not whether such circumstances could hypothetically arise, but whether or not they actually do, and if so, at what frequency. Let?s examine what would be required for your example to manifest as a problem that time-sharing could help with: the rate of slowCPURequest needs to be high enough to saturate the CPU for long enough to cause a significant increase in the latency of fastIORequest, and at the same time low enough not to destabilise the server so that requests start piling up (for the server to be stable, the average throughput must be exactly equal to the average request rate). If the rate of slowCPURequest is any higher or lower, time sharing won?t help. So the question is, how common is it for servers to run in that operational band, and how do such servers ensure that they can always maintain their throughput and don?t destabilise? This is the kind of information that will allow us to to start working on time-sharing, and it requires a report, not any kind of convincing. We can?t work on a fix for problem X encountered while running server Y until we get a report saying ?I?ve encountered problem X while running server Y?. At this time, however, I will appreciate it if someone could explain why it is so hard to understand that we cannot fix a bug until it is reported that I?ve had to repeat this so many times. Even if we decided today that we?re dropping everything else and working on time-sharing in the scheduler because that is the most urgent thing to work on, we still couldn?t do it without the information required to know when the problem is fixed and we can move on to something else. If it?s hard to understand because you think it is obvious that this bug will occur since the scenario I described above is common, then someone will report it soon enough, at which point we?ll have at least some of the relevant operational parameters and will then be able to start considering solutions. Without that necessary information, it doesn?t matter how much we want to work on a fix; we simply can?t. Now, while it won?t help us identifying a bug, it might be interesting for you to at least simulate an *endless* stream of requests, and try different rates of the two kinds of operations (and add at least a bit more CPU usage in the fastIO case). ? Ron On 9 Jan 2023, at 12:04, Arnaud Masson > wrote: I doubt it will suddenly convince anyone, but I wrote a minimal example to illustrate the concrete problem. With the classic thread executor, the normal requests (fastIORequest) complete quickly even during concurrent CPU requests (slowCPURequest), while using the default Loom executor they are stuck for some time. Arnaud package org.example; import java.time.Duration; import java.time.Instant; import java.util.ArrayList; import java.util.Timer; import java.util.TimerTask; import java.util.concurrent.Executors; import java.util.concurrent.Future; public class MixedServer { static final Instant t0 = Instant.now(); static long slowCPURequest(String name, Instant posted) throws Exception { long t = 0; var n = 1e9; // slow CPU-only stuff: e.g. image codec, XML manip, collection iteration, ... for (int i = 0; i < n; i++) { t = t + 2; } var completed = Instant.now(); System.out.println(Duration.between(t0, Instant.now()) + " - " + name + " completed (duration: " + Duration.between(posted, completed) + ")"); return t; } static Object fastIORequest(Instant posted) throws Exception { // IO stuff, e.g. JDBC call // (but sleep would have the same effect for this test, i.e. block the thread) Thread.sleep(2); var completed = Instant.now(); System.out.println(Duration.between(t0, Instant.now()) + " - fast IO task" + " completed (duration: " + Duration.between(posted, completed) + ")"); return null; } public static void main(String[] args) throws Exception { var executor = Executors.newVirtualThreadPerTaskExecutor(); // unfair //Executors.newCachedThreadPool(); // fair var timer = new Timer(); timer.schedule(new TimerTask() { @Override public void run() { var posted = Instant.now(); executor.submit(() -> fastIORequest(posted)); } }, 100, 100); var futures = new ArrayList(); for (int i = 0; i < 60; i++) { final var name = "Task_" + i; var posted = Instant.now(); futures.add(executor.submit(() -> slowCPURequest(name, posted))); } for (Future f: futures) f.get(); System.out.println("--- done ---"); executor.shutdownNow(); timer.cancel(); } } Great, then one someone who runs CPU-heavy jobs that are appropriate for virtual threads presents a problem the?ve encountered that could be solved by some form of time-sharing, we?ll take a look. For the time being, we have a hypothesis that ZjQcmQRYFpfptBannerStart Great, then one someone who runs CPU-heavy jobs that are appropriate for virtual threads presents a problem the?ve encountered that could be solved by some form of time-sharing, we?ll take a look. For the time being, we have a hypothesis that one or more problems could occur, and a further hypothesis that some class of solutions might fix or mitigate them. Unfortunately, theses hypotheses are not presently actionable. I don?t know what problem Go?s maintainers solve with time-sharing. Maybe they just want to solve Go?s lack of convenient access to a scheduler with time-sharing even in the case of background processing tasks ? a problem that Java doesn?t have ? or perhaps they?ve managed to identify common server workloads that could be helped by time-sharing, in which case we?d love to see those workloads so that we can make sure our fix works. I am not at all resistant to adding time-sharing to the virtual thread scheduler. I am resistant to fixing bugs that have not been reported. I have said many times ? and not just on the mailing lists ? that the best and often only way to get a some change made to Java is to report a problem. You might have noticed that all JEPs start with a motivation section that attempts to clearly present a problem that?s encountered by Java?s users (and sometimes maintainers) and analyse its relative severity to justify the proposed solution. That is usually the JEP?s most important section (and the section we typically spend most time writing) because the most important thing is to understand the problem you?re trying to tackle. Every change has a cost. A feature might add overhead that harms workloads that don?t benefit from it, and it certainly has an opportunity cost. Neither of these is disqualifying, but we simply cannot judge the pros and cons of doing something until we can weigh some problem against another, and we can?t even get started on this process until we have a problem in front of us. We *have* been presented with a problem that some specific kind of time-sharing can solve (postponing a batch job that?s consuming resources to run at a much later time), and it is one of the reasons we?ve added custom schedulers that will be able to employ it to our roadmap. It is certainly possible that the lack of time-sharing causes problems that need addressing in the default (currently only) virtual-thread scheduler ? I am not at all dismissing that possibility ? but there?s not much we can do until those problems are actually reported to us, which would allow us to know more about when those problems occur, how frequently, and what kind of time-sharing can assist in which circumstances and to what degree. There?s no point in trying to convince us of something we are already convinced of, namely that the possibility exists that some virtual thread workloads could be significantly helped by time-sharing. In fact, I?ve mentioned that possibility on this mailing list a few times already. If the problems are common, now that more people are giving virtual threads a try, I expect they will be reported by someone soon enough and we could start the process of tackling them. ? Ron On 9 Jan 2023, at 08:48, Sam Pullara > wrote: Ron, I think you are being purposefully obtuse by not recognizing that some folks are going to run high CPU jobs in vthreads. The proof is with the folks using Go that already encountered it and fixed it. On Mon, Jan 9, 2023 at 12:46 AM Arnaud Masson > wrote: Side note : it seems ?more? preemptive time sharing was added for goroutines in Go 1.14 to avoid the kind of scheduling starvation we discussed: https://medium.com/a-journey-with-go/go-asynchronous-preemption-b5194227371c Thanks Arnaud Unless otherwise stated above: Compagnie IBM France Si?ge Social : 17, avenue de l'Europe, 92275 Bois-Colombes Cedex RCS Nanterre 552 118 465 Forme Sociale : S.A.S. Capital Social : 664 069 390,60 ? SIRET : 552 118 465 03644 - Code NAF 6203Z -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron.pressler at oracle.com Mon Jan 9 18:19:02 2023 From: ron.pressler at oracle.com (Ron Pressler) Date: Mon, 9 Jan 2023 18:19:02 +0000 Subject: effectiveness of jdk.virtualThreadScheduler.maxPoolSize In-Reply-To: References: <0EF9E9AD-6BD4-44EE-94EB-A480953495B1@oracle.com> <90C07807-C611-4919-A387-EC789E9151A8@ix.netcom.com> <231464EE-3DD7-4BFF-9751-D7697A671576@oracle.com> Message-ID: I think it would be interesting to explain in more detail the effects of scheduling, and why the question of time-sharing is not obvious and so crucially depends on real-world data. Suppose you are given 10 tasks, 5 of them have a processing duration of 0ms, and 5 of them have a duration of 100ms. For simplicity, let?s assume we have no parallelism. Both a shortest-task-first and a longest-task-first will complete all tasks in 500ms, but their average task latency will be quite different. That of the shortest-task-first scheduler will be 150ms (= (5*0 + 100 + 200 + 300 + 400 + 500)/10), while that of the longest-task-first scheduler will be 400ms (= 100 + 200 + 300 + 400 + 500 + 5*500)/10). A perfect time-sharing scheduler (with zero overhead and infinitesimal granularity) would yield an average latency of 250ms (= 0*5 + 500*5). Those are big differences! But now let?s consider a server where an infinite stream of requests arrive from the outside, half of them with a processing duration of 0ms and half with a duration of 100ms. Regardless of how we schedule the requests in the queue that may form, because the average request duration is 50ms, as long as the request rate is less than or equal to 20 req/s the server will be stable. If the rate is higher than that, the server will become unstable with requests piling up in an ever-growing queue and the latency will climb to infinity ? again, regardless of scheduling policy. What about latency? The average latency will depend on the distribution of requests. Without time-sharing, it can range between 50ms and 100ms; with perfect time-sharing it may be much higher (i.e. worse). Perfect time-sharing will decrease the latency of the short tasks (to 0ms!) at the expense of increasing the latency of the long tasks. But say we conclude that reducing latencies of short tasks at the expense of long tasks is what everyone always wants; that?s not entirely obvious, but not completely unreasonable, either. Suppose that at the same request rate of 20 per second, the probability for a long task weren't 0.5 but 0.55, or that instead of 100ms it takes 110 ms. In that situation time sharing can no longer help ? the server will destabilise. Alternatively, suppose that the probability of a long task is 0.05 or that its duration is 50 ms; time sharing is no longer effective, either. So at 20 req/s, within the band of 50-100ms or 0.05-0.5 probability time sharing can help; above it or below it ? it doesn?t. Keeping in mind that time-sharing can?t actually be perfect and that no request can actually have a duration of zero, I hope it is now clearer why we?re so curious to find real-world cases and why simulations provide little insight. It?s easy to construct an artificial simulation at the operational band where time-sharing is effective, but it?s precisely because, in practice, it is most effective when the server is on the edge of stability and becomes gradually less effective the further away we are from that tipping-point that the most important questions become: how often do servers operate within that operational band, where exactly along that band do they commonly find themselves, and how does that situation arise in real-world scenarios? Only when we get real-wold data can we answer those questions and can consider the pros and cons, and only then can we either conclude that the work isn?t worth it or be able to satisfactorily justify it. (Note that for the classic case where time sharing helps? some fixed set of background processing operations ? there is no need to add time-sharing to the virtual thread scheduler, as a better solution is already available.) ? Ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From rengels at ix.netcom.com Mon Jan 9 18:34:54 2023 From: rengels at ix.netcom.com (Robert Engels) Date: Mon, 9 Jan 2023 12:34:54 -0600 Subject: effectiveness of jdk.virtualThreadScheduler.maxPoolSize In-Reply-To: References: Message-ID: I think what is not given enough weight in the analysis is that long running tasks are usually deprioritized by the scheduler - not equally time slices - reducing the latency for short requests - increasing the latency for long/batch requests. This is expected today based on the Linux (and many other) schedulers. The vthread scheduler is breaking from this - which is fine if it has good reasons to do so. You can read the Go rationale for adding time slicing into the scheduler here https://github.com/golang/go/issues/10958 There were multiple issues it addressed - I?m not sure all of them apply to Java. > On Jan 9, 2023, at 12:19 PM, Ron Pressler wrote: > > ? > I think it would be interesting to explain in more detail the effects of scheduling, and why the question of time-sharing is not obvious and so crucially depends on real-world data. > > Suppose you are given 10 tasks, 5 of them have a processing duration of 0ms, and 5 of them have a duration of 100ms. For simplicity, let?s assume we have no parallelism. Both a shortest-task-first and a longest-task-first will complete all tasks in 500ms, but their average task latency will be quite different. That of the shortest-task-first scheduler will be 150ms (= (5*0 + 100 + 200 + 300 + 400 + 500)/10), while that of the longest-task-first scheduler will be 400ms (= 100 + 200 + 300 + 400 + 500 + 5*500)/10). A perfect time-sharing scheduler (with zero overhead and infinitesimal granularity) would yield an average latency of 250ms (= 0*5 + 500*5). Those are big differences! > > But now let?s consider a server where an infinite stream of requests arrive from the outside, half of them with a processing duration of 0ms and half with a duration of 100ms. Regardless of how we schedule the requests in the queue that may form, because the average request duration is 50ms, as long as the request rate is less than or equal to 20 req/s the server will be stable. If the rate is higher than that, the server will become unstable with requests piling up in an ever-growing queue and the latency will climb to infinity ? again, regardless of scheduling policy. > > What about latency? The average latency will depend on the distribution of requests. Without time-sharing, it can range between 50ms and 100ms; with perfect time-sharing it may be much higher (i.e. worse). Perfect time-sharing will decrease the latency of the short tasks (to 0ms!) at the expense of increasing the latency of the long tasks. > > But say we conclude that reducing latencies of short tasks at the expense of long tasks is what everyone always wants; that?s not entirely obvious, but not completely unreasonable, either. Suppose that at the same request rate of 20 per second, the probability for a long task weren't 0.5 but 0.55, or that instead of 100ms it takes 110 ms. In that situation time sharing can no longer help ? the server will destabilise. Alternatively, suppose that the probability of a long task is 0.05 or that its duration is 50 ms; time sharing is no longer effective, either. So at 20 req/s, within the band of 50-100ms or 0.05-0.5 probability time sharing can help; above it or below it ? it doesn?t. > > Keeping in mind that time-sharing can?t actually be perfect and that no request can actually have a duration of zero, I hope it is now clearer why we?re so curious to find real-world cases and why simulations provide little insight. It?s easy to construct an artificial simulation at the operational band where time-sharing is effective, but it?s precisely because, in practice, it is most effective when the server is on the edge of stability and becomes gradually less effective the further away we are from that tipping-point that the most important questions become: how often do servers operate within that operational band, where exactly along that band do they commonly find themselves, and how does that situation arise in real-world scenarios? Only when we get real-wold data can we answer those questions and can consider the pros and cons, and only then can we either conclude that the work isn?t worth it or be able to satisfactorily justify it. > > (Note that for the classic case where time sharing helps? some fixed set of background processing operations ? there is no need to add time-sharing to the virtual thread scheduler, as a better solution is already available.) > > ? Ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnaud.masson at fr.ibm.com Mon Jan 9 19:02:56 2023 From: arnaud.masson at fr.ibm.com (Arnaud Masson) Date: Mon, 9 Jan 2023 19:02:56 +0000 Subject: effectiveness of jdk.virtualThreadScheduler.maxPoolSize In-Reply-To: References: <0EF9E9AD-6BD4-44EE-94EB-A480953495B1@oracle.com> <90C07807-C611-4919-A387-EC789E9151A8@ix.netcom.com> <231464EE-3DD7-4BFF-9751-D7697A671576@oracle.com> Message-ID: My concern right now is not constant high rate of slowCPURequets or having Loom threads handle arbitrary high CPU load for long time. It?s just that Loom (default Executor) makes some real scenarios worse compared to classic Executor, like the modest burst of slowCPURequests causing brutal pause on fastIORequests in the code example. (Again, there are workarounds, but it makes Loom transition more complex/sensitive for _some_ webapps.) About the operational band: Let?s say C is the number is of available CPUs (or Pod CPU limit) and M the max number of active native threads beyond which your pod becomes useless. You assume any concurrent CPU activity between C and M is irrelevant, but it doesn?t make sense for me: why would it be better to be stuck suddenly with long pauses at C rather than scaling gracefully until M? Interestingly, the scenario you consider (postponing a batch job to run at a much later time) is less relevant in my opinion in modern cloud environment where you want your pod to migrate smoothly but quickly (save state/stop/restart/reload state in a few minutes max) during cluster scaling for example. Thanks Arnaud As I wrote to the mailing list some years ago, the virtual thread scheduler is designed in a way that will create this phenomenon, and it is done in this way because two things are unclear: 1. Whether or not this phenomenon is a problem, and ZjQcmQRYFpfptBannerStart As I wrote to the mailing list some years ago, the virtual thread scheduler is designed in a way that will create this phenomenon, and it is done in this way because two things are unclear: 1. Whether or not this phenomenon is a problem, and 2. Whether time-sharing could help if it is. What is unclear is not whether such circumstances could hypothetically arise, but whether or not they actually do, and if so, at what frequency. Let?s examine what would be required for your example to manifest as a problem that time-sharing could help with: the rate of slowCPURequest needs to be high enough to saturate the CPU for long enough to cause a significant increase in the latency of fastIORequest, and at the same time low enough not to destabilise the server so that requests start piling up (for the server to be stable, the average throughput must be exactly equal to the average request rate). If the rate of slowCPURequest is any higher or lower, time sharing won?t help. So the question is, how common is it for servers to run in that operational band, and how do such servers ensure that they can always maintain their throughput and don?t destabilise? This is the kind of information that will allow us to to start working on time-sharing, and it requires a report, not any kind of convincing. We can?t work on a fix for problem X encountered while running server Y until we get a report saying ?I?ve encountered problem X while running server Y?. At this time, however, I will appreciate it if someone could explain why it is so hard to understand that we cannot fix a bug until it is reported that I?ve had to repeat this so many times. Even if we decided today that we?re dropping everything else and working on time-sharing in the scheduler because that is the most urgent thing to work on, we still couldn?t do it without the information required to know when the problem is fixed and we can move on to something else. If it?s hard to understand because you think it is obvious that this bug will occur since the scenario I described above is common, then someone will report it soon enough, at which point we?ll have at least some of the relevant operational parameters and will then be able to start considering solutions. Without that necessary information, it doesn?t matter how much we want to work on a fix; we simply can?t. Now, while it won?t help us identifying a bug, it might be interesting for you to at least simulate an *endless* stream of requests, and try different rates of the two kinds of operations (and add at least a bit more CPU usage in the fastIO case). ? Ron On 9 Jan 2023, at 12:04, Arnaud Masson > wrote: I doubt it will suddenly convince anyone, but I wrote a minimal example to illustrate the concrete problem. With the classic thread executor, the normal requests (fastIORequest) complete quickly even during concurrent CPU requests (slowCPURequest), while using the default Loom executor they are stuck for some time. Arnaud package org.example; import java.time.Duration; import java.time.Instant; import java.util.ArrayList; import java.util.Timer; import java.util.TimerTask; import java.util.concurrent.Executors; import java.util.concurrent.Future; public class MixedServer { static final Instant t0 = Instant.now(); static long slowCPURequest(String name, Instant posted) throws Exception { long t = 0; var n = 1e9; // slow CPU-only stuff: e.g. image codec, XML manip, collection iteration, ... for (int i = 0; i < n; i++) { t = t + 2; } var completed = Instant.now(); System.out.println(Duration.between(t0, Instant.now()) + " - " + name + " completed (duration: " + Duration.between(posted, completed) + ")"); return t; } static Object fastIORequest(Instant posted) throws Exception { // IO stuff, e.g. JDBC call // (but sleep would have the same effect for this test, i.e. block the thread) Thread.sleep(2); var completed = Instant.now(); System.out.println(Duration.between(t0, Instant.now()) + " - fast IO task" + " completed (duration: " + Duration.between(posted, completed) + ")"); return null; } public static void main(String[] args) throws Exception { var executor = Executors.newVirtualThreadPerTaskExecutor(); // unfair //Executors.newCachedThreadPool(); // fair var timer = new Timer(); timer.schedule(new TimerTask() { @Override public void run() { var posted = Instant.now(); executor.submit(() -> fastIORequest(posted)); } }, 100, 100); var futures = new ArrayList(); for (int i = 0; i < 60; i++) { final var name = "Task_" + i; var posted = Instant.now(); futures.add(executor.submit(() -> slowCPURequest(name, posted))); } for (Future f: futures) f.get(); System.out.println("--- done ---"); executor.shutdownNow(); timer.cancel(); } } Great, then one someone who runs CPU-heavy jobs that are appropriate for virtual threads presents a problem the?ve encountered that could be solved by some form of time-sharing, we?ll take a look. For the time being, we have a hypothesis that ZjQcmQRYFpfptBannerStart Great, then one someone who runs CPU-heavy jobs that are appropriate for virtual threads presents a problem the?ve encountered that could be solved by some form of time-sharing, we?ll take a look. For the time being, we have a hypothesis that one or more problems could occur, and a further hypothesis that some class of solutions might fix or mitigate them. Unfortunately, theses hypotheses are not presently actionable. I don?t know what problem Go?s maintainers solve with time-sharing. Maybe they just want to solve Go?s lack of convenient access to a scheduler with time-sharing even in the case of background processing tasks ? a problem that Java doesn?t have ? or perhaps they?ve managed to identify common server workloads that could be helped by time-sharing, in which case we?d love to see those workloads so that we can make sure our fix works. I am not at all resistant to adding time-sharing to the virtual thread scheduler. I am resistant to fixing bugs that have not been reported. I have said many times ? and not just on the mailing lists ? that the best and often only way to get a some change made to Java is to report a problem. You might have noticed that all JEPs start with a motivation section that attempts to clearly present a problem that?s encountered by Java?s users (and sometimes maintainers) and analyse its relative severity to justify the proposed solution. That is usually the JEP?s most important section (and the section we typically spend most time writing) because the most important thing is to understand the problem you?re trying to tackle. Every change has a cost. A feature might add overhead that harms workloads that don?t benefit from it, and it certainly has an opportunity cost. Neither of these is disqualifying, but we simply cannot judge the pros and cons of doing something until we can weigh some problem against another, and we can?t even get started on this process until we have a problem in front of us. We *have* been presented with a problem that some specific kind of time-sharing can solve (postponing a batch job that?s consuming resources to run at a much later time), and it is one of the reasons we?ve added custom schedulers that will be able to employ it to our roadmap. It is certainly possible that the lack of time-sharing causes problems that need addressing in the default (currently only) virtual-thread scheduler ? I am not at all dismissing that possibility ? but there?s not much we can do until those problems are actually reported to us, which would allow us to know more about when those problems occur, how frequently, and what kind of time-sharing can assist in which circumstances and to what degree. There?s no point in trying to convince us of something we are already convinced of, namely that the possibility exists that some virtual thread workloads could be significantly helped by time-sharing. In fact, I?ve mentioned that possibility on this mailing list a few times already. If the problems are common, now that more people are giving virtual threads a try, I expect they will be reported by someone soon enough and we could start the process of tackling them. ? Ron On 9 Jan 2023, at 08:48, Sam Pullara > wrote: Ron, I think you are being purposefully obtuse by not recognizing that some folks are going to run high CPU jobs in vthreads. The proof is with the folks using Go that already encountered it and fixed it. On Mon, Jan 9, 2023 at 12:46 AM Arnaud Masson > wrote: Side note : it seems ?more? preemptive time sharing was added for goroutines in Go 1.14 to avoid the kind of scheduling starvation we discussed: https://medium.com/a-journey-with-go/go-asynchronous-preemption-b5194227371c Thanks Arnaud Unless otherwise stated above: Compagnie IBM France Si?ge Social : 17, avenue de l'Europe, 92275 Bois-Colombes Cedex RCS Nanterre 552 118 465 Forme Sociale : S.A.S. Capital Social : 664 069 390,60 ? SIRET : 552 118 465 03644 - Code NAF 6203Z Unless otherwise stated above: Compagnie IBM France Si?ge Social : 17, avenue de l'Europe, 92275 Bois-Colombes Cedex RCS Nanterre 552 118 465 Forme Sociale : S.A.S. Capital Social : 664 069 390,60 ? SIRET : 552 118 465 03644 - Code NAF 6203Z -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron.pressler at oracle.com Mon Jan 9 19:19:04 2023 From: ron.pressler at oracle.com (Ron Pressler) Date: Mon, 9 Jan 2023 19:19:04 +0000 Subject: [External] : Re: effectiveness of jdk.virtualThreadScheduler.maxPoolSize In-Reply-To: References: Message-ID: <4A7DF7F1-3600-4599-8F08-F25B58402213@oracle.com> On 9 Jan 2023, at 18:34, Robert Engels > wrote: I think what is not given enough weight in the analysis is that long running tasks are usually deprioritized by the scheduler - not equally time slices - reducing the latency for short requests - increasing the latency for long/batch requests. Actually, this is covered as a special case. Even assuming perfect time-sharing, its effectiveness for virtual thread use cases is unclear until we obtain more data from the field. This is expected today based on the Linux (and many other) schedulers. The vthread scheduler is breaking from this - which is fine if it has good reasons to do so. An OS scheduler must be a reasonable compromise for many kinds of threads. Virtual threads are optimised for transaction-processing workloads. I assume it will take some years to gather sufficient information from the field so that we can tweak our decisions based on data, but after spending years considering various hypotheses, I don?t see a reason to change what we have now without obtaining more data. You can read the Go rationale for adding time slicing into the scheduler here https://github.com/golang/go/issues/10958 There were multiple issues it addressed - I?m not sure all of them apply to Java. When we studied those motivations some years ago, it appeared they do not apply to Java. Once again, we must only solve problems faced by Java developers in the field. ? Ron On Jan 9, 2023, at 12:19 PM, Ron Pressler > wrote: ? I think it would be interesting to explain in more detail the effects of scheduling, and why the question of time-sharing is not obvious and so crucially depends on real-world data. Suppose you are given 10 tasks, 5 of them have a processing duration of 0ms, and 5 of them have a duration of 100ms. For simplicity, let?s assume we have no parallelism. Both a shortest-task-first and a longest-task-first will complete all tasks in 500ms, but their average task latency will be quite different. That of the shortest-task-first scheduler will be 150ms (= (5*0 + 100 + 200 + 300 + 400 + 500)/10), while that of the longest-task-first scheduler will be 400ms (= 100 + 200 + 300 + 400 + 500 + 5*500)/10). A perfect time-sharing scheduler (with zero overhead and infinitesimal granularity) would yield an average latency of 250ms (= 0*5 + 500*5). Those are big differences! But now let?s consider a server where an infinite stream of requests arrive from the outside, half of them with a processing duration of 0ms and half with a duration of 100ms. Regardless of how we schedule the requests in the queue that may form, because the average request duration is 50ms, as long as the request rate is less than or equal to 20 req/s the server will be stable. If the rate is higher than that, the server will become unstable with requests piling up in an ever-growing queue and the latency will climb to infinity ? again, regardless of scheduling policy. What about latency? The average latency will depend on the distribution of requests. Without time-sharing, it can range between 50ms and 100ms; with perfect time-sharing it may be much higher (i.e. worse). Perfect time-sharing will decrease the latency of the short tasks (to 0ms!) at the expense of increasing the latency of the long tasks. But say we conclude that reducing latencies of short tasks at the expense of long tasks is what everyone always wants; that?s not entirely obvious, but not completely unreasonable, either. Suppose that at the same request rate of 20 per second, the probability for a long task weren't 0.5 but 0.55, or that instead of 100ms it takes 110 ms. In that situation time sharing can no longer help ? the server will destabilise. Alternatively, suppose that the probability of a long task is 0.05 or that its duration is 50 ms; time sharing is no longer effective, either. So at 20 req/s, within the band of 50-100ms or 0.05-0.5 probability time sharing can help; above it or below it ? it doesn?t. Keeping in mind that time-sharing can?t actually be perfect and that no request can actually have a duration of zero, I hope it is now clearer why we?re so curious to find real-world cases and why simulations provide little insight. It?s easy to construct an artificial simulation at the operational band where time-sharing is effective, but it?s precisely because, in practice, it is most effective when the server is on the edge of stability and becomes gradually less effective the further away we are from that tipping-point that the most important questions become: how often do servers operate within that operational band, where exactly along that band do they commonly find themselves, and how does that situation arise in real-world scenarios? Only when we get real-wold data can we answer those questions and can consider the pros and cons, and only then can we either conclude that the work isn?t worth it or be able to satisfactorily justify it. (Note that for the classic case where time sharing helps? some fixed set of background processing operations ? there is no need to add time-sharing to the virtual thread scheduler, as a better solution is already available.) ? Ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron.pressler at oracle.com Mon Jan 9 19:35:44 2023 From: ron.pressler at oracle.com (Ron Pressler) Date: Mon, 9 Jan 2023 19:35:44 +0000 Subject: effectiveness of jdk.virtualThreadScheduler.maxPoolSize In-Reply-To: References: <0EF9E9AD-6BD4-44EE-94EB-A480953495B1@oracle.com> <90C07807-C611-4919-A387-EC789E9151A8@ix.netcom.com> <231464EE-3DD7-4BFF-9751-D7697A671576@oracle.com> Message-ID: <8E068F87-5F59-4C27-876A-4149973FDC79@oracle.com> On 9 Jan 2023, at 19:02, Arnaud Masson > wrote: My concern right now is not constant high rate of slowCPURequets or having Loom threads handle arbitrary high CPU load for long time. It?s just that Loom (default Executor) makes some real scenarios worse compared to classic Executor, like the modest burst of slowCPURequests causing brutal pause on fastIORequests in the code example. I don?t think that?s true. The only scenarios where we?ve seen that situation is ?worse? (under the assumption that you want to increase latency for long tasks and decrease it for short tasks) is are those where it is trivial to pick a different scheduler once the programmer decides they have a preference for one scheduling policy over another. We have not seen situations where virtual threads are the obvious choice and yet you see a problem. We would be very interested in finding them so we could study them. But please assume that any *hypothetical* scenario that could be considered has already been. I was hoping to clarify why after spending years considering hypotheses we?re at a point we need more actual data, not the same hypotheses we?ve already considered. Every single hypothetical case you bring up has already been considered, and we concluded that the only thing we can do is wait until someone actually encounters it in the field. (Again, there are workarounds, but it makes Loom transition more complex/sensitive for _some_ webapps.) A workaround implies someone has encountered a problem. We first need to establish that some webapps find this more complex, and we can?t even do that until they report a problem. About the operational band: Let?s say C is the number is of available CPUs (or Pod CPU limit) and M the max number of active native threads beyond which your pod becomes useless. You assume any concurrent CPU activity between C and M is irrelevant, but it doesn?t make sense for me: why would it be better to be stuck suddenly with long pauses at C rather than scaling gracefully until M? Time-sharing doesn?t ?scale gracefully?. It decreases the latency for some tasks at the cost of increasing it for others (and sometimes increasing the average), while having no impact on scalability (scheduling cannot affect scalability). Interestingly, the scenario you consider (postponing a batch job to run at a much later time) is less relevant in my opinion in modern cloud environment where you want your pod to migrate smoothly but quickly (save state/stop/restart/reload state in a few minutes max) during cluster scaling for example. Quite possibly, but given that a big company has actually presented us with a real problem they encountered while no one has reported a problem of the kind we?re discussing, our only course of action is to prioritise the problem that we know exists. There really is absolutely nothing we can do about problems that have not been reported, no many how many times we consider hypotheticals. If you can?t accept it as the only reasonable course of action, please accept it as an arbitrary axiom: until someone reports a problem they?ve actually encountered in some reasonable program, we cannot consider requests for changes. If the problem is likely to occur, then someone will surely report it soon enough and we could start studying it. There?s no point in arguing over this axiom, and the only insight that can help us move forward is real data from the field. ? Ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnaud.masson at fr.ibm.com Mon Jan 9 19:39:40 2023 From: arnaud.masson at fr.ibm.com (Arnaud Masson) Date: Mon, 9 Jan 2023 19:39:40 +0000 Subject: : Re: effectiveness of jdk.virtualThreadScheduler.maxPoolSize In-Reply-To: <4A7DF7F1-3600-4599-8F08-F25B58402213@oracle.com> References: <4A7DF7F1-3600-4599-8F08-F25B58402213@oracle.com> Message-ID: The average latency of different request types doesn?t matter much, I think. What matters (for ?interactive? web apps at least) is rather the request latency relatively to its own intrinsic duration. Example: Adding 1s to a 10s request is not much worse than adding 10ms to a 100ms request. Adding 1s to a 100ms request is a more serious problem. Not sure to understand the last part ?some fixed set of background processing operations?, is it about using non-Loom/classic executor when time sharing is more needed? (It was considered as useless when it was suggested earlier as a workaround, so I?m a bit confused). Sounds like a good workaround but it adds some complexity for the developer that must distinguish in advance which request must go to Loom Executor and which request must go to classic Executor. (Something Go developers don?t have to worry about now.) Thanks Arnaud On 9 Jan 2023, at 18:34, Robert Engels > wrote: I think what is not given enough weight in the analysis is that long running tasks are usually deprioritized by the scheduler - not equally time slices - reducing the latency for short requests - increasing the latency for long/batch requests. Actually, this is covered as a special case. Even assuming perfect time-sharing, its effectiveness for virtual thread use cases is unclear until we obtain more data from the field. This is expected today based on the Linux (and many other) schedulers. The vthread scheduler is breaking from this - which is fine if it has good reasons to do so. An OS scheduler must be a reasonable compromise for many kinds of threads. Virtual threads are optimised for transaction-processing workloads. I assume it will take some years to gather sufficient information from the field so that we can tweak our decisions based on data, but after spending years considering various hypotheses, I don?t see a reason to change what we have now without obtaining more data. You can read the Go rationale for adding time slicing into the scheduler here https://github.com/golang/go/issues/10958 There were multiple issues it addressed - I?m not sure all of them apply to Java. When we studied those motivations some years ago, it appeared they do not apply to Java. Once again, we must only solve problems faced by Java developers in the field. ? Ron On Jan 9, 2023, at 12:19 PM, Ron Pressler > wrote: ? I think it would be interesting to explain in more detail the effects of scheduling, and why the question of time-sharing is not obvious and so crucially depends on real-world data. Suppose you are given 10 tasks, 5 of them have a processing duration of 0ms, and 5 of them have a duration of 100ms. For simplicity, let?s assume we have no parallelism. Both a shortest-task-first and a longest-task-first will complete all tasks in 500ms, but their average task latency will be quite different. That of the shortest-task-first scheduler will be 150ms (= (5*0 + 100 + 200 + 300 + 400 + 500)/10), while that of the longest-task-first scheduler will be 400ms (= 100 + 200 + 300 + 400 + 500 + 5*500)/10). A perfect time-sharing scheduler (with zero overhead and infinitesimal granularity) would yield an average latency of 250ms (= 0*5 + 500*5). Those are big differences! But now let?s consider a server where an infinite stream of requests arrive from the outside, half of them with a processing duration of 0ms and half with a duration of 100ms. Regardless of how we schedule the requests in the queue that may form, because the average request duration is 50ms, as long as the request rate is less than or equal to 20 req/s the server will be stable. If the rate is higher than that, the server will become unstable with requests piling up in an ever-growing queue and the latency will climb to infinity ? again, regardless of scheduling policy. What about latency? The average latency will depend on the distribution of requests. Without time-sharing, it can range between 50ms and 100ms; with perfect time-sharing it may be much higher (i.e. worse). Perfect time-sharing will decrease the latency of the short tasks (to 0ms!) at the expense of increasing the latency of the long tasks. But say we conclude that reducing latencies of short tasks at the expense of long tasks is what everyone always wants; that?s not entirely obvious, but not completely unreasonable, either. Suppose that at the same request rate of 20 per second, the probability for a long task weren't 0.5 but 0.55, or that instead of 100ms it takes 110 ms. In that situation time sharing can no longer help ? the server will destabilise. Alternatively, suppose that the probability of a long task is 0.05 or that its duration is 50 ms; time sharing is no longer effective, either. So at 20 req/s, within the band of 50-100ms or 0.05-0.5 probability time sharing can help; above it or below it ? it doesn?t. Keeping in mind that time-sharing can?t actually be perfect and that no request can actually have a duration of zero, I hope it is now clearer why we?re so curious to find real-world cases and why simulations provide little insight. It?s easy to construct an artificial simulation at the operational band where time-sharing is effective, but it?s precisely because, in practice, it is most effective when the server is on the edge of stability and becomes gradually less effective the further away we are from that tipping-point that the most important questions become: how often do servers operate within that operational band, where exactly along that band do they commonly find themselves, and how does that situation arise in real-world scenarios? Only when we get real-wold data can we answer those questions and can consider the pros and cons, and only then can we either conclude that the work isn?t worth it or be able to satisfactorily justify it. (Note that for the classic case where time sharing helps? some fixed set of background processing operations ? there is no need to add time-sharing to the virtual thread scheduler, as a better solution is already available.) ? Ron Unless otherwise stated above: Compagnie IBM France Si?ge Social : 17, avenue de l'Europe, 92275 Bois-Colombes Cedex RCS Nanterre 552 118 465 Forme Sociale : S.A.S. Capital Social : 664 069 390,60 ? SIRET : 552 118 465 03644 - Code NAF 6203Z -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnaud.masson at fr.ibm.com Mon Jan 9 20:12:52 2023 From: arnaud.masson at fr.ibm.com (Arnaud Masson) Date: Mon, 9 Jan 2023 20:12:52 +0000 Subject: effectiveness of jdk.virtualThreadScheduler.maxPoolSize In-Reply-To: <8E068F87-5F59-4C27-876A-4149973FDC79@oracle.com> References: <0EF9E9AD-6BD4-44EE-94EB-A480953495B1@oracle.com> <90C07807-C611-4919-A387-EC789E9151A8@ix.netcom.com> <231464EE-3DD7-4BFF-9751-D7697A671576@oracle.com> <8E068F87-5F59-4C27-876A-4149973FDC79@oracle.com> Message-ID: On 9 Jan 2023, at 19:?02, Arnau > We have not seen situations where virtual threads are the obvious choice and yet you see a problem I suppose I see a problem where vthreads are not a so obvious choice ? It?s the main issue for Loom in its current form: to know in advance for each request if it?s Loom friendly (most requests I guess) or not. More work for app devs. >Time-sharing doesn?t ?scale gracefully?. It decreases the latency for some tasks at the cost of increasing it for others (and sometimes increasing the average), while having no impact on scalability (scheduling cannot affect scalability). It is more graceful since it?s proportional to tasks own durations, instead of brutal pause at some threshold. Quite possibly, but given that a big company has actually presented us with a real problem they encountered while no one has reported a problem of the kind we?re discussing Sorry, I don?t understand what you mean by reporting a problem, I thought that what I was doing here. You mean filling formal ticket? (I can?t really run Loom on prod right now since it?s still JDK Preview.) Thanks Arnaud Unless otherwise stated above: Compagnie IBM France Si?ge Social : 17, avenue de l'Europe, 92275 Bois-Colombes Cedex RCS Nanterre 552 118 465 Forme Sociale : S.A.S. Capital Social : 664 069 390,60 ? SIRET : 552 118 465 03644 - Code NAF 6203Z -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron.pressler at oracle.com Mon Jan 9 20:14:14 2023 From: ron.pressler at oracle.com (Ron Pressler) Date: Mon, 9 Jan 2023 20:14:14 +0000 Subject: : Re: effectiveness of jdk.virtualThreadScheduler.maxPoolSize In-Reply-To: References: <4A7DF7F1-3600-4599-8F08-F25B58402213@oracle.com> Message-ID: <09DFDFF7-8297-4241-9D97-FDF53E1270AE@oracle.com> On 9 Jan 2023, at 19:39, Arnaud Masson > wrote: The average latency of different request types doesn?t matter much, I think. What matters (for ?interactive? web apps at least) is rather the request latency relatively to its own intrinsic duration. Example: Adding 1s to a 10s request is not much worse than adding 10ms to a 100ms request. Adding 1s to a 100ms request is a more serious problem. Maybe, but since it?s unclear that time-sharing can actually provide any significant help, we can't take any action until we know more about what happens in real servers, why it occurs, and at what frequency. Remember that time sharing will only have any significant impact in specific situations, whose importance cannot be determined without data. So either you give virtual threads a try in your server workload, and if you encounter a problem your information would help us and be much appreciated, or you don?t, and wait until someone else can give us the insight we need to tackle any problems that arise. Of course, it is perfectly reasonable to decide that you?d rather have others try things first and have them help us if they run into problems, but you need to accept that in order to justify prioritising some work, we must refer to actual problems that people encounter. You?ll notice that all JEPs and even smaller work items are always justified by some problem that someone has actually encountered. Even if you think that you would prioritise things differently, you can appreciate that this way adds, at worst, only a little latency to the process: the more likely a hypothetical problem is (and so the more important), the sooner someone will run into it and we?ll be able to start working on fixing it once they report it. Not sure to understand the last part ?some fixed set of background processing operations?, is it about using non-Loom/classic executor when time sharing is more needed? (It was considered as useless when it was suggested earlier as a workaround, so I?m a bit confused). It?s about a case where it?s not that incoming requests can vary widely in the resources they consume, but where there?s some known set of CPU-heavy tasks that need to run in the background. If that work is directly related to the workload on the server, it?s unlikely that scheduling can help (as scheduling does not help scalability, which is only a function of the resources an average request consumes and the average rate of requests), but if it?s bounded in some way, then that set of tasks can be run on on specialised thread-pools as they are today. It?s neither a ?workaround? nor a solution to the same problem. Sounds like a good workaround but it adds some complexity for the developer that must distinguish in advance which request must go to Loom Executor and which request must go to classic Executor. (Something Go developers don?t have to worry about now.) Such tasks are run on specialised thread-pools today, too (as fairness with thread pools is worse than with virtual threads anyway), so there?s no added complexity whatsoever. And until you identify some actual problematic workloads in a reasonable program, you can?t possibly know what Go developers need not worry about compared to Java developers (as they might well need to have only a fixed set of such tasks, too). It is certainly possible that someone else knows something we don?t, but knowing that they do is of little help; we need to know what they know. Once you do find a relevant workload, please report it. ? Ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron.pressler at oracle.com Mon Jan 9 20:31:10 2023 From: ron.pressler at oracle.com (Ron Pressler) Date: Mon, 9 Jan 2023 20:31:10 +0000 Subject: effectiveness of jdk.virtualThreadScheduler.maxPoolSize In-Reply-To: References: <0EF9E9AD-6BD4-44EE-94EB-A480953495B1@oracle.com> <90C07807-C611-4919-A387-EC789E9151A8@ix.netcom.com> <231464EE-3DD7-4BFF-9751-D7697A671576@oracle.com> <8E068F87-5F59-4C27-876A-4149973FDC79@oracle.com> Message-ID: <2D481A24-B81C-4118-A01D-CA67753F51F5@oracle.com> On 9 Jan 2023, at 20:12, Arnaud Masson > wrote: On 9 Jan 2023, at 19:?02, Arnau > We have not seen situations where virtual threads are the obvious choice and yet you see a problem I suppose I see a problem where vthreads are not a so obvious choice ? It?s the main issue for Loom in its current form: to know in advance for each request if it?s Loom friendly (most requests I guess) or not. More work for app devs. No, I don?t think so. You?ve hypothesised that different resource consumption could lead to issues, but it?s not at all clear that it does in the real world. So if you find a case where this is a problem, report it. You?ve gone through an entire series of logical steps, and, having spent years on this, I tried explaining to you why it?s not clear that each step follows from the previous: It is not clear that different resource consumption causes any issue whatsoever in real workloads, and it?s not clear that if it does, time sharing is the solution. But since you have concerns, I suggest you wait and see what other report. >Time-sharing doesn?t ?scale gracefully?. It decreases the latency for some tasks at the cost of increasing it for others (and sometimes increasing the average), while having no impact on scalability (scheduling cannot affect scalability). It is more graceful since it?s proportional to tasks own durations, instead of brutal pause at some threshold. It has no impact on throughput or on server scalability, and it actually increases the maximum latency. I think you might be speculating over the effects of time sharing on server workloads rather than actually observing them. Sorry, I don?t understand what you mean by reporting a problem, I thought that what I was doing here. You mean filling formal ticket? (I can?t really run Loom on prod right now since it?s still JDK Preview.) Production is, of course, more interesting, but it?s not at all a prerequisite for a report of an actual problem. What you?ve done so far is speculate that you may run into a problem (and the problem with your simulation, aside from it not simulating a server with an infinite stream of requests, is that it does not explain how the server keeps the long tasks at just the right rate). If you build a server based on virtual threads that you use to evaluate virtual threads for your production workloads by mimicking them as well as you can, and *then* run into a problem in testing, reporting that here would be useful, and have to potential of providing us with some new information. ? Ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnaud.masson at fr.ibm.com Mon Jan 9 20:51:25 2023 From: arnaud.masson at fr.ibm.com (Arnaud Masson) Date: Mon, 9 Jan 2023 20:51:25 +0000 Subject: effectiveness of jdk.virtualThreadScheduler.maxPoolSize In-Reply-To: <2D481A24-B81C-4118-A01D-CA67753F51F5@oracle.com> References: <0EF9E9AD-6BD4-44EE-94EB-A480953495B1@oracle.com> <90C07807-C611-4919-A387-EC789E9151A8@ix.netcom.com> <231464EE-3DD7-4BFF-9751-D7697A671576@oracle.com> <8E068F87-5F59-4C27-876A-4149973FDC79@oracle.com> <2D481A24-B81C-4118-A01D-CA67753F51F5@oracle.com> Message-ID: I don?t think I can have any impact on what you think, so I will stop here ? Anyway, thanks for the awesome work on Loom! Arnaud On 9 Jan 2023, at 20:12, Arnaud Masson > wrote: On 9 Jan 2023, at 19:?02, Arnau > We have not seen situations where virtual threads are the obvious choice and yet you see a problem I suppose I see a problem where vthreads are not a so obvious choice ? It?s the main issue for Loom in its current form: to know in advance for each request if it?s Loom friendly (most requests I guess) or not. More work for app devs. No, I don?t think so. You?ve hypothesised that different resource consumption could lead to issues, but it?s not at all clear that it does in the real world. So if you find a case where this is a problem, report it. You?ve gone through an entire series of logical steps, and, having spent years on this, I tried explaining to you why it?s not clear that each step follows from the previous: It is not clear that different resource consumption causes any issue whatsoever in real workloads, and it?s not clear that if it does, time sharing is the solution. But since you have concerns, I suggest you wait and see what other report. >Time-sharing doesn?t ?scale gracefully?. It decreases the latency for some tasks at the cost of increasing it for others (and sometimes increasing the average), while having no impact on scalability (scheduling cannot affect scalability). It is more graceful since it?s proportional to tasks own durations, instead of brutal pause at some threshold. It has no impact on throughput or on server scalability, and it actually increases the maximum latency. I think you might be speculating over the effects of time sharing on server workloads rather than actually observing them. Sorry, I don?t understand what you mean by reporting a problem, I thought that what I was doing here. You mean filling formal ticket? (I can?t really run Loom on prod right now since it?s still JDK Preview.) Production is, of course, more interesting, but it?s not at all a prerequisite for a report of an actual problem. What you?ve done so far is speculate that you may run into a problem (and the problem with your simulation, aside from it not simulating a server with an infinite stream of requests, is that it does not explain how the server keeps the long tasks at just the right rate). If you build a server based on virtual threads that you use to evaluate virtual threads for your production workloads by mimicking them as well as you can, and *then* run into a problem in testing, reporting that here would be useful, and have to potential of providing us with some new information. ? Ron Unless otherwise stated above: Compagnie IBM France Si?ge Social : 17, avenue de l'Europe, 92275 Bois-Colombes Cedex RCS Nanterre 552 118 465 Forme Sociale : S.A.S. Capital Social : 664 069 390,60 ? SIRET : 552 118 465 03644 - Code NAF 6203Z -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron.pressler at oracle.com Mon Jan 9 20:57:36 2023 From: ron.pressler at oracle.com (Ron Pressler) Date: Mon, 9 Jan 2023 20:57:36 +0000 Subject: effectiveness of jdk.virtualThreadScheduler.maxPoolSize In-Reply-To: References: <0EF9E9AD-6BD4-44EE-94EB-A480953495B1@oracle.com> <90C07807-C611-4919-A387-EC789E9151A8@ix.netcom.com> <231464EE-3DD7-4BFF-9751-D7697A671576@oracle.com> <8E068F87-5F59-4C27-876A-4149973FDC79@oracle.com> <2D481A24-B81C-4118-A01D-CA67753F51F5@oracle.com> Message-ID: <6D04015B-3031-46B4-9C1E-9B96DC6F2C64@oracle.com> On 9 Jan 2023, at 20:51, Arnaud Masson > wrote: I don?t think I can have any impact on what you think, so I will stop here ? All right. What I (or you) think doesn?t matter at this point since what we do has to be justified by at least some amount of data; if you have none to report, I hope others do. Anyway, thanks for the awesome work on Loom! Thank you! ? Ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Tue Jan 10 00:45:14 2023 From: duke at openjdk.org (duke) Date: Tue, 10 Jan 2023 00:45:14 GMT Subject: git: openjdk/loom: fibers: fixed test is excluded. Message-ID: <3b48e146-635d-4de9-82c7-447ed089ec0c@openjdk.org> Changeset: 80335d7a Author: Leonid Mesnik Date: 2023-01-10 00:42:18 +0000 URL: https://git.openjdk.org/loom/commit/80335d7aabb3ef50520e143e856192e6c8cd6bf3 fixed test is excluded. ! test/hotspot/jtreg/ProblemList-vthread.txt From duke at openjdk.org Tue Jan 10 19:08:42 2023 From: duke at openjdk.org (duke) Date: Tue, 10 Jan 2023 19:08:42 GMT Subject: git: openjdk/loom: fibers: testng tests problemlisted Message-ID: <12c9ba1c-ef1f-4699-a38a-db8cb3c541b3@openjdk.org> Changeset: 1e1b3dd1 Author: Leonid Mesnik Date: 2023-01-10 19:04:30 +0000 URL: https://git.openjdk.org/loom/commit/1e1b3dd1e82fe379eabb2a35b3cb7e05deb6e968 testng tests problemlisted ! test/jdk/ProblemList-vthread.txt From duke at openjdk.org Thu Jan 12 20:30:52 2023 From: duke at openjdk.org (duke) Date: Thu, 12 Jan 2023 20:30:52 GMT Subject: git: openjdk/loom: fibers: 107 new changesets Message-ID: <7e48313e-ed2b-4c28-af54-ccd0da5bbc37@openjdk.org> Changeset: 5ae6de85 Author: ravi.ra.gupta Committer: Sergey Bylokhov Date: 2023-01-04 22:44:38 +0000 URL: https://git.openjdk.org/loom/commit/5ae6de859d472d107cdf642c417c6d2f1c74e5db 8299296: Write a test to verify the components selection sends ItemEvent Reviewed-by: serb + test/jdk/java/awt/event/ComponentEvent/ComponentItemEventTest.java Changeset: 578c287a Author: Abhishek Kumar Committer: Sergey Bylokhov Date: 2023-01-04 22:45:39 +0000 URL: https://git.openjdk.org/loom/commit/578c287a68f38f21a91d200b7a0657aaeb721b3f 8081507: Open or Save button in JFileChooser has OK title in GTK LaF Reviewed-by: serb, tr ! src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk.properties + test/jdk/com/sun/java/swing/plaf/gtk/TestFileChooserOpenSaveButtonText.java ! test/jdk/sanity/client/SwingSet/src/FileChooserDemoTest.java Changeset: 2ccdefc8 Author: Matthias Baesken Date: 2023-01-05 07:59:41 +0000 URL: https://git.openjdk.org/loom/commit/2ccdefc81c0ea2ea5c4380bb045aa82ad1eb8205 8299470: sun/jvm/hotspot/SALauncher.java handling of negative rmiport args Reviewed-by: clanger, sspitsyn, kevinw ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/SAGetopt.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/SALauncher.java ! test/hotspot/jtreg/serviceability/sa/sadebugd/SADebugDTest.java Changeset: c929d8be Author: Matthias Baesken Date: 2023-01-05 08:26:38 +0000 URL: https://git.openjdk.org/loom/commit/c929d8be5d19f2030406eb5c19f854e672c7a547 8299475: Enhance SocketException by cause where it is missing in net and nio area Reviewed-by: alanb ! src/java.base/share/classes/java/net/ServerSocket.java ! src/java.base/share/classes/java/net/Socket.java ! src/java.base/share/classes/java/net/SocksSocketImpl.java ! src/java.base/share/classes/sun/nio/ch/NioSocketImpl.java Changeset: e7361cb7 Author: Sergey Bylokhov Date: 2023-01-05 08:47:21 +0000 URL: https://git.openjdk.org/loom/commit/e7361cb746cf00984dd5193ec8a8cc90e1e5a39b 8299430: Cleanup: delete unnecessary semicolons in java.desktop module Reviewed-by: stsypanov, aghaisas, iris ! src/java.desktop/macosx/classes/apple/laf/JRSUIControl.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaFileChooserUI.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaTabbedPaneContrastUI.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaTabbedPaneCopyFromBasicUI.java ! src/java.desktop/macosx/classes/sun/font/CCharToGlyphMapper.java ! src/java.desktop/macosx/classes/sun/java2d/MacOSFlags.java ! src/java.desktop/macosx/classes/sun/java2d/metal/MTLLayer.java ! src/java.desktop/macosx/classes/sun/java2d/opengl/CGLLayer.java ! src/java.desktop/macosx/native/libawt_lwawt/awt/JavaAccessibilityUtilities.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/JavaTextAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CellAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CommonComponentAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CommonTextAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/OutlineRowAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLClip.m ! src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLGlyphCache.h ! src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLPaints.m ! src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLRenderer.m ! src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp ! src/java.desktop/share/classes/com/sun/imageio/plugins/png/PNGImageReader.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/png/RowFilter.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/tiff/TIFFImageWriteParam.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/tiff/TIFFOldJPEGDecompressor.java ! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifDesktopPaneUI.java ! src/java.desktop/share/classes/java/awt/Component.java ! src/java.desktop/share/classes/java/awt/Desktop.java ! src/java.desktop/share/classes/java/awt/Dialog.java ! src/java.desktop/share/classes/java/awt/EventFilter.java ! src/java.desktop/share/classes/java/awt/GraphicsDevice.java ! src/java.desktop/share/classes/java/awt/TrayIcon.java ! src/java.desktop/share/classes/java/awt/im/InputMethodHighlight.java ! src/java.desktop/share/classes/java/awt/image/ColorConvertOp.java ! src/java.desktop/share/classes/javax/accessibility/AccessibleAttributeSequence.java ! src/java.desktop/share/classes/javax/accessibility/AccessibleTextSequence.java ! src/java.desktop/share/classes/javax/print/StreamPrintService.java ! src/java.desktop/share/classes/javax/swing/DefaultDesktopManager.java ! src/java.desktop/share/classes/javax/swing/LayoutStyle.java ! src/java.desktop/share/classes/javax/swing/MultiUIDefaults.java ! src/java.desktop/share/classes/javax/swing/Spring.java ! src/java.desktop/share/classes/javax/swing/TransferHandler.java ! src/java.desktop/share/classes/javax/swing/event/TableColumnModelEvent.java ! src/java.desktop/share/classes/javax/swing/event/TableModelEvent.java ! src/java.desktop/share/classes/javax/swing/filechooser/FileView.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicComboPopup.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicDesktopIconUI.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicIconFactory.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicMenuUI.java ! src/java.desktop/share/classes/javax/swing/plaf/metal/MetalInternalFrameUI.java ! src/java.desktop/share/classes/javax/swing/plaf/nimbus/ImageScalingHelper.java ! src/java.desktop/share/classes/javax/swing/text/Caret.java ! src/java.desktop/share/classes/javax/swing/text/Highlighter.java ! src/java.desktop/share/classes/javax/swing/text/View.java ! src/java.desktop/share/classes/sun/awt/AppContext.java ! src/java.desktop/share/classes/sun/awt/CausedFocusEvent.java ! src/java.desktop/share/classes/sun/awt/EmbeddedFrame.java ! src/java.desktop/share/classes/sun/awt/SunToolkit.java ! src/java.desktop/share/classes/sun/awt/image/ImageCache.java ! src/java.desktop/share/classes/sun/font/LayoutPathImpl.java ! src/java.desktop/share/classes/sun/font/SunFontManager.java ! src/java.desktop/share/classes/sun/java2d/Disposer.java ! src/java.desktop/share/classes/sun/java2d/StateTrackable.java ! src/java.desktop/share/classes/sun/java2d/cmm/lcms/LCMS.java ! src/java.desktop/share/classes/sun/java2d/loops/ProcessPath.java ! src/java.desktop/share/classes/sun/swing/plaf/synth/Paint9Painter.java ! src/java.desktop/share/classes/sun/swing/text/TextComponentPrintable.java ! src/java.desktop/share/native/common/awt/medialib/mlib_ImageCreate.c ! src/java.desktop/share/native/common/font/AccelGlyphCache.h ! src/java.desktop/share/native/common/java2d/opengl/OGLSurfaceData.h ! src/java.desktop/share/native/libawt/java2d/Disposer.h ! src/java.desktop/share/native/libawt/java2d/SurfaceData.h ! src/java.desktop/share/native/libawt/java2d/Trace.h ! src/java.desktop/share/native/libawt/java2d/loops/GraphicsPrimitiveMgr.h ! src/java.desktop/share/native/libawt/java2d/loops/ImageData.h ! src/java.desktop/share/native/libawt/java2d/pipe/Region.h ! src/java.desktop/unix/classes/sun/awt/UNIXToolkit.java ! src/java.desktop/unix/classes/sun/awt/X11/XBaseWindow.java ! src/java.desktop/unix/classes/sun/awt/X11/XKeysym.java ! src/java.desktop/unix/classes/sun/awt/X11/XSelection.java ! src/java.desktop/unix/classes/sun/awt/X11/XTrayIconPeer.java ! src/java.desktop/unix/classes/sun/font/NativeFont.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsIconFactory.java ! src/java.desktop/windows/classes/sun/awt/windows/WDataTransferer.java ! src/java.desktop/windows/classes/sun/java2d/d3d/D3DGraphicsDevice.java ! src/java.desktop/windows/classes/sun/java2d/d3d/D3DSurfaceData.java ! src/java.desktop/windows/native/libawt/java2d/d3d/ShaderList.h ! src/java.desktop/windows/native/libawt/java2d/windows/GDIBlitLoops.cpp ! src/java.desktop/windows/native/libawt/windows/awt_DCHolder.cpp ! src/java.desktop/windows/native/libawt/windows/awt_Mlib.h ! src/java.desktop/windows/native/libawt/windows/awt_PrintJob.cpp ! src/java.desktop/windows/native/libawt/windows/awt_ScrollPane.cpp ! src/java.desktop/windows/native/libawt/windows/awt_Toolkit.cpp ! src/java.desktop/windows/native/libawt/windows/img_util_md.h Changeset: 1ca31d34 Author: Matthias Baesken Date: 2023-01-05 09:31:38 +0000 URL: https://git.openjdk.org/loom/commit/1ca31d34fcba5e9861104402466b5dd4cccdbafd 8299657: sun/tools/jhsdb/SAGetoptTest.java fails after 8299470 Reviewed-by: clanger ! test/jdk/sun/tools/jhsdb/SAGetoptTest.java Changeset: 87238470 Author: Roland Westrelin Date: 2023-01-05 09:33:14 +0000 URL: https://git.openjdk.org/loom/commit/872384707e89d03ede655aad16f360dc94f10152 8298848: C2: clone all of (CmpP (LoadKlass (AddP down at split if Reviewed-by: kvn, thartmann, chagedorn ! src/hotspot/share/opto/loopnode.hpp ! src/hotspot/share/opto/split_if.cpp + test/hotspot/jtreg/compiler/types/TestCheckCastPPBecomesTOP.java Changeset: be64bf8c Author: Ashutosh Mehra Committer: Calvin Cheung Date: 2023-01-05 16:09:28 +0000 URL: https://git.openjdk.org/loom/commit/be64bf8cf085c17b8e405b9447357ae59ef21765 8299329: Assertion failure with fastdebug build when trying to use CDS without classpath Reviewed-by: iklam, ccheung ! src/hotspot/share/cds/filemap.cpp ! test/hotspot/jtreg/runtime/cds/appcds/WrongClasspath.java ! test/lib/jdk/test/lib/process/ProcessTools.java Changeset: b908388e Author: Andrey Turbanov Date: 2023-01-05 16:49:23 +0000 URL: https://git.openjdk.org/loom/commit/b908388e817e9bf30c8558b53efc9b2ddf2bad75 8298449: Unnecessary Vector usage in MetaData.ProxyPersistenceDelegate Reviewed-by: serb ! src/java.desktop/share/classes/java/beans/MetaData.java Changeset: a49ccb95 Author: Naoto Sato Date: 2023-01-05 17:49:24 +0000 URL: https://git.openjdk.org/loom/commit/a49ccb959b7e50ee67b1ab4feca47c34bdbc14fe 8299292: Missing elements in aliased String array Reviewed-by: iris, joehw ! make/jdk/src/classes/build/tools/cldrconverter/CLDRConverter.java Changeset: 3e2314d0 Author: Kim Barrett Date: 2023-01-05 19:49:01 +0000 URL: https://git.openjdk.org/loom/commit/3e2314d08218dc8a4f4fc61bd4e1d5e58a0129c7 8299254: Support dealing with standard assert macro Reviewed-by: erikj, xuelei, dholmes, mikael ! make/hotspot/lib/JvmFlags.gmk + src/hotspot/share/utilities/vmassert_reinstall.hpp + src/hotspot/share/utilities/vmassert_uninstall.hpp ! test/hotspot/gtest/code/test_codestrings.cpp ! test/hotspot/gtest/gc/shared/test_memset_with_concurrent_readers.cpp ! test/hotspot/gtest/gc/shenandoah/test_shenandoahNumberSeq.cpp ! test/hotspot/gtest/jfr/test_networkUtilization.cpp ! test/hotspot/gtest/unittest.hpp Changeset: dfdbd0fe Author: Kim Barrett Date: 2023-01-05 22:02:45 +0000 URL: https://git.openjdk.org/loom/commit/dfdbd0fe7f800257c40fd148bc0a41c8eb826bdf 8299343: Windows: Invalid thread_native_entry declaration Reviewed-by: dholmes, iklam ! src/hotspot/os/windows/os_windows.cpp ! src/hotspot/os/windows/os_windows.hpp Changeset: 4b6809b9 Author: Mikael Vidstedt Date: 2023-01-05 22:39:44 +0000 URL: https://git.openjdk.org/loom/commit/4b6809b94a09871712df7a1c51b7192adbe2093b 8299693: Change to Xcode12.4+1.1 devkit for building on macOS at Oracle Reviewed-by: dholmes, erikj ! make/conf/jib-profiles.js Changeset: 7845b0d7 Author: Anto J Committer: Sergey Bylokhov Date: 2023-01-06 00:37:26 +0000 URL: https://git.openjdk.org/loom/commit/7845b0d7b4193688448b7bf0c427df4976d302e5 8296934: Write a test to verify whether Undecorated Frame can be iconified or not Reviewed-by: serb + test/jdk/java/awt/Frame/Iconify/IconifyTest.java Changeset: 775da84a Author: Artem Semenov Date: 2023-01-06 07:09:05 +0000 URL: https://git.openjdk.org/loom/commit/775da84a84770696495561277eb040f53260ecaf 8299412: JNI call of getAccessibleActionCount on a wrong thread Reviewed-by: prr, serb ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CAccessibility.java ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CommonComponentAccessibility.m Changeset: 99be7408 Author: Tejesh R Date: 2023-01-06 07:50:33 +0000 URL: https://git.openjdk.org/loom/commit/99be74088eec3e7974642c8aa5792377d32ebe67 8299306: Test "javax/swing/JFileChooser/FileSystemView/CustomFSVLinkTest.java" fails on Windows 10 x64 because there are some buttons did not display button name Reviewed-by: psadhukhan, abhiscxk ! test/jdk/javax/swing/JFileChooser/FileSystemView/CustomFSVLinkTest.java Changeset: b5b7948d Author: Sergey Bylokhov Date: 2023-01-06 08:04:51 +0000 URL: https://git.openjdk.org/loom/commit/b5b7948d9b4870d9e84ec8d8b544b252f9053785 8298240: Replace the usage of ImageLayoutException by the CMMException Reviewed-by: prr ! src/java.desktop/share/classes/sun/java2d/cmm/lcms/LCMSImageLayout.java ! src/java.desktop/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java Changeset: cc4936a7 Author: Tobias Hartmann Date: 2023-01-06 08:28:09 +0000 URL: https://git.openjdk.org/loom/commit/cc4936a79e1c1723542d575a2596edd29248817e 8298720: Insufficient error handling when CodeBuffer is exhausted Reviewed-by: kvn, fyang ! src/hotspot/cpu/aarch64/c1_MacroAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/c2_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/riscv/c2_MacroAssembler_riscv.cpp ! src/hotspot/cpu/riscv/macroAssembler_riscv.hpp ! src/hotspot/cpu/riscv/sharedRuntime_riscv.cpp Changeset: 0234f813 Author: Andrey Turbanov Date: 2023-01-06 08:29:47 +0000 URL: https://git.openjdk.org/loom/commit/0234f813e6113fee133a2cab77566d1fcb191c8b 8298447: Unnecessary Vector usage in DocPrintJob implementations Reviewed-by: serb ! src/java.desktop/share/classes/sun/print/PSStreamPrintJob.java ! src/java.desktop/unix/classes/sun/print/UnixPrintJob.java ! src/java.desktop/windows/classes/sun/print/Win32PrintJob.java Changeset: 88f0ea78 Author: bobpengxie Committer: Jie Fu Date: 2023-01-06 10:48:28 +0000 URL: https://git.openjdk.org/loom/commit/88f0ea7887ef3b05517e8c14be2d2d084f72943f 8299726: [cleanup] Some code cleanup in opto/compile.hpp Reviewed-by: thartmann ! src/hotspot/share/opto/compile.hpp Changeset: 5598acc3 Author: Aleksey Shipilev Date: 2023-01-06 11:28:38 +0000 URL: https://git.openjdk.org/loom/commit/5598acc345dbd6f806145157ae6f7c591340a1d1 8294403: [REDO] make test should report only on executed tests Reviewed-by: erikj, dholmes, jpai, djelinski ! doc/testing.html ! doc/testing.md ! make/RunTests.gmk Changeset: 8cc1669f Author: Jie Fu Date: 2023-01-06 12:56:36 +0000 URL: https://git.openjdk.org/loom/commit/8cc1669ffd22c8cabc98585ca6df6fc5fed5fb10 8299721: [Vector API] assert in switch-default of LibraryCallKit::arch_supports_vector_rotate is too weak to catch bugs Reviewed-by: jbhateja ! src/hotspot/share/opto/vectorIntrinsics.cpp Changeset: 1e997292 Author: Coleen Phillimore Date: 2023-01-06 13:57:23 +0000 URL: https://git.openjdk.org/loom/commit/1e9972922a3d8232cf111a391584638b272a3a17 8299274: Add elements to resolved_references consistently Reviewed-by: iklam, dholmes, rehn, fparain ! src/hotspot/share/cds/cdsProtectionDomain.cpp ! src/hotspot/share/ci/ciEnv.cpp ! src/hotspot/share/interpreter/interpreterRuntime.cpp ! src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp ! src/hotspot/share/oops/constantPool.cpp ! src/hotspot/share/oops/constantPool.hpp ! src/hotspot/share/oops/cpCache.cpp ! src/hotspot/share/oops/cpCache.hpp ! src/hotspot/share/oops/cpCache.inline.hpp ! src/hotspot/share/oops/objArrayOop.cpp ! src/hotspot/share/oops/objArrayOop.hpp Changeset: 3dcf7001 Author: Markus KARG Committer: Brian Burkhalter Date: 2023-01-06 17:35:17 +0000 URL: https://git.openjdk.org/loom/commit/3dcf7001611aa66a7a1b4a01dfa6dfb296e70da1 8299336: InputStream::DEFAULT_BUFFER_SIZE should be 16384 Reviewed-by: bpb ! src/java.base/share/classes/java/io/InputStream.java Changeset: ba03f42a Author: Weijun Wang Date: 2023-01-06 18:46:37 +0000 URL: https://git.openjdk.org/loom/commit/ba03f42a50375c05400de9bd19d1d6d444f0a46d 8299746: Accept unknown signatureAlgorithm in PKCS7 SignerInfo Reviewed-by: kdriver, ascarpino, hchao ! src/java.base/share/classes/sun/security/pkcs/SignerInfo.java + test/jdk/sun/security/pkcs/pkcs7/NewSigAlg.java Changeset: d6e9f015 Author: Chris Plummer Date: 2023-01-06 18:49:11 +0000 URL: https://git.openjdk.org/loom/commit/d6e9f01584ef84d6390c356fd3b342d9d79899ab 8285416: [LOOM] Some nsk/jdi tests fail due to needing too many virtual threads 8282383: [LOOM] 6 nsk JDI and JDB tests sometimes failing with vthread wrapper due to running out of carrier threads Reviewed-by: dholmes, sspitsyn, alanb, lmesnik ! test/hotspot/jtreg/ProblemList-svc-vthread.txt ! test/hotspot/jtreg/vmTestbase/nsk/share/jdb/Launcher.java ! test/hotspot/jtreg/vmTestbase/nsk/share/jdi/Binder.java Changeset: 8c70bf3f Author: Andrei Pangin Committer: Sandhya Viswanathan Date: 2023-01-06 19:00:20 +0000 URL: https://git.openjdk.org/loom/commit/8c70bf3fff6f01b637f9e72a0b4c617051dbfafd 8299544: Improve performance of CRC32C intrinsics (non-AVX-512) for small inputs Reviewed-by: kvn, eastigeevich, sviswanathan ! src/hotspot/cpu/x86/crc32c.h ! src/hotspot/cpu/x86/macroAssembler_x86.cpp Changeset: d6d6eb4c Author: Ashutosh Mehra Committer: Calvin Cheung Date: 2023-01-06 19:56:12 +0000 URL: https://git.openjdk.org/loom/commit/d6d6eb4cba3d2d85035b46d18e8817b5b2a354a2 8299699: Test runtime/cds/appcds/WrongClasspath.java fails after JDK-8299329 Reviewed-by: iklam, ccheung ! test/hotspot/jtreg/runtime/cds/appcds/TestCommon.java Changeset: 4a95c74b Author: Sergey Bylokhov Date: 2023-01-06 20:17:10 +0000 URL: https://git.openjdk.org/loom/commit/4a95c74b7628ad297d2a6bff2d47c6a9ddf876e3 8299425: "LCMSImageLayout.isIntPacked" flag can be deleted Reviewed-by: prr ! src/java.desktop/share/classes/sun/java2d/cmm/lcms/LCMS.java ! src/java.desktop/share/classes/sun/java2d/cmm/lcms/LCMSImageLayout.java ! src/java.desktop/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java ! src/java.desktop/share/native/liblcms/LCMS.c Changeset: d086e82b Author: Sergey Tsypanov Committer: Brian Burkhalter Date: 2023-01-06 21:01:21 +0000 URL: https://git.openjdk.org/loom/commit/d086e82b3c554362a8fc7095025f8f2910d6e4bc 8299600: Use Objects.check*() where appropriate in java.io Reviewed-by: alanb, bpb ! src/java.base/share/classes/java/io/CharArrayWriter.java ! src/java.base/share/classes/java/io/FilterOutputStream.java ! src/java.base/share/classes/java/io/LineNumberInputStream.java ! src/java.base/share/classes/java/io/PipedOutputStream.java ! src/java.base/share/classes/java/io/PipedWriter.java ! src/java.base/share/classes/java/io/StringWriter.java Changeset: 73101314 Author: Sergey Bylokhov Date: 2023-01-06 23:09:07 +0000 URL: https://git.openjdk.org/loom/commit/7310131409d3be351e780696173e7354ab51e467 8299337: The java.awt.image.ColorModel#pData field is unused Reviewed-by: prr ! src/java.desktop/macosx/native/libawt_lwawt/awt/ImageSurfaceData.m ! src/java.desktop/share/classes/java/awt/image/ColorModel.java ! src/java.desktop/share/native/libawt/awt/image/imageInitIDs.c ! src/java.desktop/share/native/libawt/awt/image/imageInitIDs.h ! src/java.desktop/unix/native/common/awt/X11Color.c Changeset: 9c4ed16b Author: Maurizio Cimadamore Date: 2023-01-05 09:44:16 +0000 URL: https://git.openjdk.org/loom/commit/9c4ed16be2fdb20f2917a6e8efacfbb30d3118b1 8299561: VaList.empty() doesn't return a list associated with the global scope Reviewed-by: jvernee ! src/java.base/share/classes/jdk/internal/foreign/abi/aarch64/linux/LinuxAArch64VaList.java ! src/java.base/share/classes/jdk/internal/foreign/abi/x64/sysv/SysVVaList.java ! test/jdk/java/foreign/valist/VaListTest.java Changeset: 284c94e2 Author: Pavel Rappo Date: 2023-01-05 22:43:20 +0000 URL: https://git.openjdk.org/loom/commit/284c94e20d49b6b6a09b1daa398abbbe4d049de3 8298525: javadoc crashes with "UnsupportedOperationException: Not yet implemented" in SeeTaglet.inherit Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/SeeTaglet.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/SpecTaglet.java ! test/langtools/jdk/javadoc/doclet/testInheritDocWithinInappropriateTag/TestInheritDocWithinInappropriateTag.java Changeset: 136f5db0 Author: Bhavana Kilambi Committer: Nick Gasson Date: 2023-01-06 10:04:04 +0000 URL: https://git.openjdk.org/loom/commit/136f5db03d664fd77f8042c6f0875dea964ca5e9 8299528: IR test: TestEor3AArch64.java fails on aarch64 Reviewed-by: thartmann, chagedorn ! test/hotspot/jtreg/compiler/lib/ir_framework/IRNode.java ! test/hotspot/jtreg/compiler/vectorization/TestEor3AArch64.java Changeset: 5eee2a07 Author: Maurizio Cimadamore Date: 2023-01-06 14:52:08 +0000 URL: https://git.openjdk.org/loom/commit/5eee2a07f5db5979149cc3e96d4f608ed135a7b3 8299740: CaptureCallState is missing @Preview annotation Reviewed-by: alanb ! src/java.base/share/classes/java/lang/foreign/Linker.java Changeset: 1f141bd7 Author: Alexandre Iline Date: 2023-01-06 18:51:41 +0000 URL: https://git.openjdk.org/loom/commit/1f141bd7a99085c5464626eb83402ffabf9d38c8 8299705: JCov coverage runs depend on jdk_symbols Reviewed-by: erikj ! make/conf/jib-profiles.js Changeset: 5393dc9a Author: Jesper Wilhelmsson Date: 2023-01-07 02:05:59 +0000 URL: https://git.openjdk.org/loom/commit/5393dc9a48064505f0b79b7059f87bec33c1c8fe Merge ! make/conf/jib-profiles.js ! test/hotspot/jtreg/compiler/lib/ir_framework/IRNode.java ! test/langtools/jdk/javadoc/doclet/testInheritDocWithinInappropriateTag/TestInheritDocWithinInappropriateTag.java ! make/conf/jib-profiles.js ! test/hotspot/jtreg/compiler/lib/ir_framework/IRNode.java ! test/langtools/jdk/javadoc/doclet/testInheritDocWithinInappropriateTag/TestInheritDocWithinInappropriateTag.java Changeset: 63cf4aa0 Author: Justin Lu Committer: Jaikiran Pai Date: 2023-01-07 02:19:15 +0000 URL: https://git.openjdk.org/loom/commit/63cf4aa0c897406fc9370a8e05cb035caafc5d69 8299499: Usage of constructors of primitive wrapper classes should be avoided in java.net API docs Reviewed-by: naoto, jpai ! src/java.base/share/classes/java/net/SocketOptions.java Changeset: d5b80abc Author: Justin Lu Committer: Jaikiran Pai Date: 2023-01-07 02:20:12 +0000 URL: https://git.openjdk.org/loom/commit/d5b80abcbfff57c7728d3e42a696a762f08bc7ad 8299617: CurrencySymbols.properties is missing the copyright notice Reviewed-by: naoto, iris, jpai ! test/jdk/java/text/Format/NumberFormat/CurrencySymbols.properties Changeset: e209693a Author: Jaikiran Pai Date: 2023-01-07 02:33:52 +0000 URL: https://git.openjdk.org/loom/commit/e209693a37e49ba5fd5b1ad3404e9dd807c545f3 8258776: ThreadLocal#initialValue() Javadoc is unaware of ThreadLocal#withInitial() Reviewed-by: alanb ! src/java.base/share/classes/java/lang/ThreadLocal.java Changeset: 834e50e9 Author: Srinivas Mandalika Committer: Sergey Bylokhov Date: 2023-01-08 09:08:04 +0000 URL: https://git.openjdk.org/loom/commit/834e50e9efc16effad7469cae99ab8f918a30e86 8298921: Create a regression test for JDK-8139581 Reviewed-by: serb + test/jdk/java/awt/Component/ComponentRedrawnTest.java Changeset: d53cac37 Author: Justin King Committer: Kim Barrett Date: 2023-01-08 10:45:36 +0000 URL: https://git.openjdk.org/loom/commit/d53cac379419b7b74df045bb119df6d5f9e91878 8299481: Remove metaprogramming/removePointer.hpp Reviewed-by: kbarrett, tschatzl - src/hotspot/share/metaprogramming/removePointer.hpp ! src/hotspot/share/runtime/atomic.hpp - test/hotspot/gtest/metaprogramming/test_removePointer.cpp Changeset: 7607c07e Author: SWinxy Committer: Julian Waters Date: 2023-01-09 02:14:43 +0000 URL: https://git.openjdk.org/loom/commit/7607c07e002cd86cf2a0f44df9933612550ced95 8299774: SYNTH_BUTTON_UI_KEY field is unused Reviewed-by: serb ! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthButtonUI.java Changeset: c4449224 Author: Abhishek Kumar Committer: Tejesh R Date: 2023-01-09 04:47:33 +0000 URL: https://git.openjdk.org/loom/commit/c4449224bbb70d1a0256ebf19297450ab0f98d4b 8218474: JComboBox display issue with GTKLookAndFeel Reviewed-by: tr, serb ! src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKLookAndFeel.java ! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthComboBoxUI.java ! src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.c + test/jdk/javax/swing/JComboBox/TestComboBoxComponentRendering.java ! test/jdk/javax/swing/JComboBox/TestComboBoxHeight.java Changeset: d03a5d95 Author: Daniel Jeli?ski Date: 2023-01-09 07:32:55 +0000 URL: https://git.openjdk.org/loom/commit/d03a5d9580ef3b9be4d766ff9a11d6fd5fa133f9 8299593: getprotobyname should not be used Reviewed-by: cjplummer ! src/jdk.jdwp.agent/unix/native/libdt_socket/socket_md.c ! src/jdk.jdwp.agent/windows/native/libdt_socket/socket_md.c Changeset: 8d17d1ee Author: Daniel Jeli?ski Date: 2023-01-09 07:39:12 +0000 URL: https://git.openjdk.org/loom/commit/8d17d1ee6f08ee90771d469182aaaaa7c23971fd 6914801: IPv6 unavailable if stdin is a socket Reviewed-by: michaelm ! src/java.base/unix/native/libnet/net_util_md.c ! src/java.base/unix/native/libnio/ch/InheritedChannel.c + test/jdk/java/nio/channels/spi/SelectorProvider/inheritedChannel/CheckIPv6Service.java + test/jdk/java/nio/channels/spi/SelectorProvider/inheritedChannel/CheckIPv6Test.java ! test/jdk/java/nio/channels/spi/SelectorProvider/inheritedChannel/EchoTest.java ! test/jdk/java/nio/channels/spi/SelectorProvider/inheritedChannel/InheritedChannelTest.java ! test/jdk/java/nio/channels/spi/SelectorProvider/inheritedChannel/Launcher.java Changeset: 9b1ade8e Author: Damon Fenacci Committer: Tobias Hartmann Date: 2023-01-09 07:56:11 +0000 URL: https://git.openjdk.org/loom/commit/9b1ade8e2b324b3875bf97c70d8591c577568c32 8295406: C1 crash with -XX:TypeProfileArgsLimit=0 -XX:TypeProfileLevel=222 Reviewed-by: thartmann, kvn ! src/hotspot/share/oops/methodData.cpp + test/hotspot/jtreg/compiler/profiling/TestTypeProfileArgsLimit.java Changeset: 05a0a710 Author: Roland Westrelin Date: 2023-01-09 08:26:08 +0000 URL: https://git.openjdk.org/loom/commit/05a0a710313917fe7124ff43fe9c9af1d649bcac 8297933: [REDO] Compiler should only use verified interface types for optimization Reviewed-by: kvn, vlivanov ! src/hotspot/share/ci/ciArrayKlass.cpp ! src/hotspot/share/ci/ciInstanceKlass.cpp ! src/hotspot/share/ci/ciInstanceKlass.hpp ! src/hotspot/share/ci/ciObjectFactory.cpp ! src/hotspot/share/opto/arraycopynode.cpp ! src/hotspot/share/opto/castnode.cpp ! src/hotspot/share/opto/castnode.hpp ! src/hotspot/share/opto/cfgnode.cpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/compile.hpp ! src/hotspot/share/opto/doCall.cpp ! src/hotspot/share/opto/graphKit.cpp ! src/hotspot/share/opto/idealGraphPrinter.cpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/opto/memnode.cpp ! src/hotspot/share/opto/node.cpp ! src/hotspot/share/opto/parse1.cpp ! src/hotspot/share/opto/parse3.cpp ! src/hotspot/share/opto/parseHelper.cpp ! src/hotspot/share/opto/subnode.cpp ! src/hotspot/share/opto/subtypenode.cpp ! src/hotspot/share/opto/type.cpp ! src/hotspot/share/opto/type.hpp ! test/hotspot/jtreg/compiler/intrinsics/klass/CastNullCheckDroppingsTest.java + test/hotspot/jtreg/compiler/types/TestExactArrayOfBasicType.java Changeset: d2827ec8 Author: Emanuel Peter Date: 2023-01-09 08:34:24 +0000 URL: https://git.openjdk.org/loom/commit/d2827ec8f77020241fee7d613fb7cf081b455eb9 8299671: speed up compiler/intrinsics/string/TestStringLatin1IndexOfChar.java Reviewed-by: thartmann, kvn ! test/hotspot/jtreg/compiler/intrinsics/string/TestStringLatin1IndexOfChar.java Changeset: a503ec2c Author: Erik ?sterlund Date: 2023-01-09 10:01:26 +0000 URL: https://git.openjdk.org/loom/commit/a503ec2cc7042f0d2427fcbec0237937f324c755 8299608: Add Register + imm32 orq to x86_64 assembler Reviewed-by: shade, sviswanathan, kvn ! src/hotspot/cpu/x86/assembler_x86.cpp ! src/hotspot/cpu/x86/assembler_x86.hpp Changeset: 4072412c Author: Prasanta Sadhukhan Date: 2023-01-09 10:14:06 +0000 URL: https://git.openjdk.org/loom/commit/4072412c1fd1e28febff71c6b37a9813f22bdc4b 8298876: Swing applications do not get repainted coming out of sleep on Windows 10 Reviewed-by: angorya, prr ! src/java.desktop/windows/classes/sun/java2d/d3d/D3DScreenUpdateManager.java - test/jdk/sun/java2d/DirectX/MultiPaintEventTest/MultiPaintEventTest.java Changeset: 500c3c17 Author: Johan Sj?len Date: 2023-01-09 10:18:26 +0000 URL: https://git.openjdk.org/loom/commit/500c3c17379fe0a62d42ba31bdcdb584b1823f60 8298730: Refactor subsystem_file_line_contents and add docs and tests Reviewed-by: sgehwolf, iklam ! src/hotspot/os/linux/cgroupSubsystem_linux.hpp ! src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp ! src/hotspot/os/linux/cgroupV2Subsystem_linux.cpp + test/hotspot/gtest/os/linux/test_cgroupSubsystem_linux.cpp ! test/hotspot/gtest/runtime/test_os_linux_cgroups.cpp Changeset: 70684574 Author: Patrick Zhang Committer: Nick Gasson Date: 2023-01-09 11:07:05 +0000 URL: https://git.openjdk.org/loom/commit/706845743699efb01994e2d12c65023a3e972b77 8298472: AArch64: Detect Ampere-1 and Ampere-1A CPUs and set default options Reviewed-by: aph, ngasson ! src/hotspot/cpu/aarch64/vm_version_aarch64.cpp ! src/hotspot/cpu/aarch64/vm_version_aarch64.hpp Changeset: 66db0bb6 Author: Albert Mingkun Yang Date: 2023-01-09 11:39:06 +0000 URL: https://git.openjdk.org/loom/commit/66db0bb6a15310e4e60ff1e33d40e03c52c4eca8 8299692: G1: Remove unused G1BlockOffsetTable::is_card_boundary Reviewed-by: kbarrett ! src/hotspot/share/gc/g1/g1BlockOffsetTable.cpp ! src/hotspot/share/gc/g1/g1BlockOffsetTable.hpp Changeset: 4ba81221 Author: Erik ?sterlund Date: 2023-01-09 13:31:26 +0000 URL: https://git.openjdk.org/loom/commit/4ba8122197e912db4894ed7fe395a8842268fbef 8299312: Clean up BarrierSetNMethod Reviewed-by: mdoerr, fyang ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/aarch64/gc/shared/barrierSetAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/gc/shared/barrierSetNMethod_aarch64.cpp ! src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp ! src/hotspot/cpu/arm/arm.ad ! src/hotspot/cpu/arm/gc/shared/barrierSetAssembler_arm.cpp ! src/hotspot/cpu/arm/gc/shared/barrierSetNMethod_arm.cpp ! src/hotspot/cpu/ppc/gc/shared/barrierSetAssembler_ppc.cpp ! src/hotspot/cpu/ppc/gc/shared/barrierSetNMethod_ppc.cpp ! src/hotspot/cpu/riscv/gc/shared/barrierSetAssembler_riscv.cpp ! src/hotspot/cpu/riscv/gc/shared/barrierSetNMethod_riscv.cpp ! src/hotspot/cpu/riscv/riscv.ad ! src/hotspot/cpu/riscv/stubGenerator_riscv.cpp ! src/hotspot/cpu/s390/gc/shared/barrierSetAssembler_s390.cpp ! src/hotspot/cpu/s390/gc/shared/barrierSetNMethod_s390.cpp ! src/hotspot/cpu/x86/gc/shared/barrierSetAssembler_x86.cpp ! src/hotspot/cpu/x86/gc/shared/barrierSetNMethod_x86.cpp ! src/hotspot/cpu/x86/x86_64.ad ! src/hotspot/cpu/zero/gc/shared/barrierSetNMethod_zero.cpp ! src/hotspot/share/gc/shared/barrierSet.cpp ! src/hotspot/share/gc/shared/barrierSetNMethod.cpp ! src/hotspot/share/gc/shared/barrierSetNMethod.hpp ! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.cpp ! src/hotspot/share/gc/shenandoah/shenandoahCodeRoots.cpp ! src/hotspot/share/gc/z/zBarrierSetNMethod.cpp ! src/hotspot/share/gc/z/zBarrierSetNMethod.hpp ! src/hotspot/share/gc/z/zNMethod.cpp ! src/hotspot/share/gc/z/zNMethod.hpp ! src/hotspot/share/runtime/thread.hpp Changeset: 17a3f0e2 Author: Coleen Phillimore Date: 2023-01-09 15:01:34 +0000 URL: https://git.openjdk.org/loom/commit/17a3f0e2577f2f9eb3fe62a4b8261e3dbe4c3b28 8299275: Add some ClassLoaderData verification code Reviewed-by: iklam, fparain ! src/hotspot/share/classfile/classLoaderData.cpp ! src/hotspot/share/oops/oop.inline.hpp ! src/hotspot/share/oops/verifyOopClosure.hpp Changeset: bfd59714 Author: Alexandre Iline Date: 2023-01-09 15:39:46 +0000 URL: https://git.openjdk.org/loom/commit/bfd597142945bf87cefe320371b7648d44c6f916 8299757: Update JCov version to 3.0.14 Reviewed-by: erikj, serb ! make/conf/jib-profiles.js Changeset: cd10c727 Author: Justin Lu Committer: Naoto Sato Date: 2023-01-09 17:43:31 +0000 URL: https://git.openjdk.org/loom/commit/cd10c7278d8fcf7ce6713a3ee688bb1e10c024f6 8299500: Usage of constructors of primitive wrapper classes should be avoided in java.text API docs Reviewed-by: naoto, lancea ! src/java.base/share/classes/java/text/ChoiceFormat.java ! src/java.base/share/classes/java/text/MessageFormat.java Changeset: 679e4858 Author: Archie L. Cobbs Committer: Vicente Romero Date: 2023-01-09 18:38:15 +0000 URL: https://git.openjdk.org/loom/commit/679e485838881c1364845072af305fb60d95e60a 8043251: Bogus javac error: required: no arguments, found: no arguments Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties + test/langtools/tools/javac/Diagnostics/8043251/T8043251.java + test/langtools/tools/javac/Diagnostics/8043251/T8043251.out ! test/langtools/tools/javac/diags/examples/ExplicitParamsDoNotConformToBounds.java ! test/langtools/tools/javac/diags/examples/WrongNumberTypeArgsFragment.java Changeset: b8852f65 Author: Justin Lu Committer: Naoto Sato Date: 2023-01-09 21:24:40 +0000 URL: https://git.openjdk.org/loom/commit/b8852f65a0adcb9ee5693bb6727a0668aa9808bf 8299502: Usage of constructors of primitive wrapper classes should be avoided in javax.xml API docs Reviewed-by: joehw, naoto, lancea ! src/java.xml/share/classes/javax/xml/stream/XMLOutputFactory.java Changeset: f36f1354 Author: Justin Lu Committer: Naoto Sato Date: 2023-01-09 21:26:08 +0000 URL: https://git.openjdk.org/loom/commit/f36f1354c63a500c70ae51a9c2b2d21ad55cfa77 8299501: Usage of constructors of primitive wrapper classes should be avoided in java.util API docs Reviewed-by: naoto, lancea ! src/java.base/share/classes/java/util/Arrays.java Changeset: f79b3d42 Author: Justin Lu Committer: Naoto Sato Date: 2023-01-09 22:10:36 +0000 URL: https://git.openjdk.org/loom/commit/f79b3d42f07b703f0e3b9fc67c92dee260b0e602 6381945: (cal) Japanese calendar unit test system should avoid multiple static imports Reviewed-by: lancea, iris, naoto ! test/jdk/java/util/Calendar/CalendarTestScripts/Symbol.java Changeset: d49851a8 Author: Naoto Sato Date: 2023-01-09 18:23:42 +0000 URL: https://git.openjdk.org/loom/commit/d49851a8b8e80b6ffa53c2bb4f5b2897735d471f 8299689: Make use of JLine for Console as "opt-in" Reviewed-by: jpai, alanb ! src/java.base/share/classes/java/io/Console.java ! src/java.base/share/classes/jdk/internal/io/JdkConsoleProvider.java ! test/jdk/java/io/Console/ModuleSelectionTest.java ! test/jdk/java/io/Console/RedirectTest.java Changeset: 4395578b Author: Jesper Wilhelmsson Date: 2023-01-09 23:31:32 +0000 URL: https://git.openjdk.org/loom/commit/4395578b6f0432d158c4b6c0c0a9d0838f74baa8 Merge ! src/java.base/share/classes/java/io/Console.java ! src/java.base/share/classes/java/io/Console.java Changeset: a6386634 Author: David Holmes Date: 2023-01-10 00:45:43 +0000 URL: https://git.openjdk.org/loom/commit/a63866341ee8d169bdf88cf56f5d72168263fa81 8255119: Monitor::wait takes signed integer as timeout Reviewed-by: jsjolen, stuefe, coleenp, gziemski ! src/hotspot/os/posix/mutex_posix.hpp ! src/hotspot/os/posix/os_posix.cpp ! src/hotspot/os/windows/mutex_windows.hpp ! src/hotspot/os/windows/os_windows.cpp ! src/hotspot/share/runtime/mutex.cpp ! src/hotspot/share/runtime/mutex.hpp Changeset: b7eb4e2f Author: Jaikiran Pai Date: 2023-01-10 01:53:48 +0000 URL: https://git.openjdk.org/loom/commit/b7eb4e2ffd3bce12fd960ab8102bfaabf89e8865 8297306: Incorrect brackets in Javadoc for a constructor of IteratorSpliterator Reviewed-by: alanb, iris, naoto ! src/java.base/share/classes/java/util/Spliterators.java Changeset: 3a667370 Author: Yadong Wang Committer: Fei Yang Date: 2023-01-10 02:43:14 +0000 URL: https://git.openjdk.org/loom/commit/3a667370010881ab754f8f8d540ca9e2ce45fe2c 8299525: RISC-V: Add backend support for half float conversion intrinsics Reviewed-by: fyang, fjiang ! src/hotspot/cpu/riscv/assembler_riscv.hpp ! src/hotspot/cpu/riscv/globals_riscv.hpp ! src/hotspot/cpu/riscv/riscv.ad ! src/hotspot/cpu/riscv/vm_version_riscv.cpp Changeset: 195f3137 Author: Hao Sun Committer: Ningsheng Jian Date: 2023-01-10 05:37:02 +0000 URL: https://git.openjdk.org/loom/commit/195f31371f4612a2d9d12a83deb281698ff68bfb 8287925: AArch64: intrinsics for compareUnsigned method in Integer and Long Reviewed-by: adinn, aph ! src/hotspot/cpu/aarch64/aarch64.ad ! test/hotspot/jtreg/compiler/intrinsics/TestCompareUnsigned.java Changeset: f95346e8 Author: Daniel Jeli?ski Date: 2023-01-10 07:11:24 +0000 URL: https://git.openjdk.org/loom/commit/f95346e870d314fdc224aed4e8b9c22159bd89d3 8299261: Clean up AWT D3D exports Reviewed-by: serb, aivanov ! src/java.desktop/windows/native/libawt/java2d/d3d/D3DBlitLoops.cpp ! src/java.desktop/windows/native/libawt/java2d/d3d/D3DBlitLoops.h ! src/java.desktop/windows/native/libawt/java2d/d3d/D3DContext.h ! src/java.desktop/windows/native/libawt/java2d/d3d/D3DPipeline.h ! src/java.desktop/windows/native/libawt/java2d/d3d/D3DPipelineManager.h ! src/java.desktop/windows/native/libawt/java2d/d3d/D3DRenderer.cpp ! src/java.desktop/windows/native/libawt/java2d/d3d/D3DRenderer.h ! src/java.desktop/windows/native/libawt/java2d/d3d/D3DVertexCacher.h Changeset: 5f37cbec Author: Albert Mingkun Yang Date: 2023-01-10 07:52:28 +0000 URL: https://git.openjdk.org/loom/commit/5f37cbec942d081a87fc7ef49a0a3d9c932774fc 8297572: Remove unused PrecisionStyle::Precise Reviewed-by: tschatzl, kbarrett ! src/hotspot/share/gc/shared/cardTable.hpp ! src/hotspot/share/gc/shared/cardTableRS.cpp ! src/hotspot/share/gc/shared/space.cpp ! src/hotspot/share/gc/shared/space.hpp ! src/hotspot/share/gc/shared/vmStructs_gc.hpp Changeset: c8a8388a Author: Sergey Bylokhov Date: 2023-01-10 10:30:34 +0000 URL: https://git.openjdk.org/loom/commit/c8a8388aba3dc121bad04aaa123f6cd7525c3d38 8299789: Compilation of gtest causes build to fail if runtime libraries are in different dirs Reviewed-by: erikj ! make/hotspot/test/GtestImage.gmk Changeset: eab1e626 Author: Richard Reingruber Date: 2023-01-10 10:32:32 +0000 URL: https://git.openjdk.org/loom/commit/eab1e6260d5622722b3e930b8457a64c6da28ccc 8297487: G1 Remark: no need to keep alive oop constants of nmethods on stack Reviewed-by: tschatzl, ayang, eosterlund ! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp ! src/hotspot/share/gc/shared/barrierSet.cpp Changeset: debe5879 Author: Volker Simonis Date: 2023-01-10 11:49:36 +0000 URL: https://git.openjdk.org/loom/commit/debe5879aa7118a114ff6fcf8d15951757ae70a8 8298381: Improve handling of session tickets for multiple SSLContexts Reviewed-by: xuelei, ascarpino, serb ! src/java.base/share/classes/sun/security/ssl/SSLContextImpl.java ! src/java.base/share/classes/sun/security/ssl/SSLSessionContextImpl.java ! src/java.base/share/classes/sun/security/ssl/SessionTicketExtension.java Changeset: d68de02b Author: Albert Mingkun Yang Date: 2023-01-10 14:26:32 +0000 URL: https://git.openjdk.org/loom/commit/d68de02befb8dc099842497cefb23943c506079c 8299845: Remove obsolete comments in DirtyCardToOopClosure::get_actual_top Co-authored-by: Y. Srinivas Ramakrishna Reviewed-by: tschatzl, sjohanss ! src/hotspot/share/gc/shared/space.cpp Changeset: 8b0133f2 Author: Christian Hagedorn Date: 2023-01-10 14:35:46 +0000 URL: https://git.openjdk.org/loom/commit/8b0133f2760f67cd968528c041a600408cc26978 8299259: C2: Div/Mod nodes without zero check could be split through iv phi of loop resulting in SIGFPE Reviewed-by: roland, kvn, thartmann ! src/hotspot/share/opto/loopnode.hpp ! src/hotspot/share/opto/loopopts.cpp + test/hotspot/jtreg/compiler/splitif/TestSplitDivisionThroughPhi.java Changeset: a86b6f6f Author: Mandy Chung Date: 2023-01-10 17:05:33 +0000 URL: https://git.openjdk.org/loom/commit/a86b6f6fde11a1cb27f926c43d53585049fed5e4 8299183: Invokers.checkExactType passes parameters to create WMTE in opposite order Reviewed-by: iris, jpai ! src/java.base/share/classes/java/lang/invoke/Invokers.java ! src/java.base/share/classes/java/lang/invoke/VarHandle.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestExact.java + test/jdk/java/lang/invoke/WrongMethodTypeTest.java Changeset: 5a51ef22 Author: Calvin Cheung Date: 2023-01-10 17:09:52 +0000 URL: https://git.openjdk.org/loom/commit/5a51ef22adb81cf268f7ce395a1af0d40d0d01a7 8297874: get_dump_directory() in jfrEmergencyDump.cpp should pass correct length to jio_snprintf Reviewed-by: mgronlun ! src/hotspot/share/jfr/recorder/repository/jfrEmergencyDump.cpp Changeset: 3c99e786 Author: Alexey Semenyuk Date: 2023-01-10 18:02:34 +0000 URL: https://git.openjdk.org/loom/commit/3c99e786ab4f89448f8d2a6eaf532255a8a560bf 8298735: Some tools/jpackage/windows/* tests fails with jtreg test timeout Reviewed-by: almatvee ! test/jdk/tools/jpackage/windows/WinDirChooserTest.java ! test/jdk/tools/jpackage/windows/WinInstallerIconTest.java ! test/jdk/tools/jpackage/windows/WinInstallerUiTest.java ! test/jdk/tools/jpackage/windows/WinMenuGroupTest.java ! test/jdk/tools/jpackage/windows/WinMenuTest.java ! test/jdk/tools/jpackage/windows/WinPerUserInstallTest.java ! test/jdk/tools/jpackage/windows/WinScriptTest.java ! test/jdk/tools/jpackage/windows/WinShortcutPromptTest.java ! test/jdk/tools/jpackage/windows/WinShortcutTest.java ! test/jdk/tools/jpackage/windows/WinUrlTest.java Changeset: c595f965 Author: Alexey Semenyuk Date: 2023-01-10 18:03:42 +0000 URL: https://git.openjdk.org/loom/commit/c595f965abcf0ea80ace87b8f2180feebbb8984e 8299278: tools/jpackage/share/AddLauncherTest.java#id1 failed AddLauncherTest.bug8230933 Reviewed-by: almatvee ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/Executor.java ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/LauncherIconVerifier.java Changeset: ddca2b9b Author: Kim Barrett Date: 2023-01-11 05:12:26 +0000 URL: https://git.openjdk.org/loom/commit/ddca2b9b46110ecae9f67eab9677e96168f7e9cf 8299701: Remove unused GCCause::_wb_conc_mark Reviewed-by: eosterlund, iwalulya ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1CollectedHeap.hpp ! src/hotspot/share/gc/shared/gcCause.cpp ! src/hotspot/share/gc/shared/gcCause.hpp ! src/hotspot/share/gc/z/zDriver.cpp ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/shared/GCCause.java Changeset: 10a747c7 Author: Justin King Committer: Kim Barrett Date: 2023-01-11 05:31:56 +0000 URL: https://git.openjdk.org/loom/commit/10a747c70bb957b7dd268009e6062771085b97eb 8299479: Remove metaprogramming/decay.hpp Reviewed-by: tschatzl, kbarrett - src/hotspot/share/metaprogramming/decay.hpp ! src/hotspot/share/oops/accessBackend.hpp - test/hotspot/gtest/metaprogramming/test_decay.cpp Changeset: f312c999 Author: Justin King Committer: Kim Barrett Date: 2023-01-11 05:33:29 +0000 URL: https://git.openjdk.org/loom/commit/f312c99977635a0c54600016c0814a64f8aff2ef 8299482: Remove metaprogramming/isIntegral.hpp Reviewed-by: kbarrett, tschatzl - src/hotspot/share/metaprogramming/isIntegral.hpp ! src/hotspot/share/oops/accessBackend.hpp ! src/hotspot/share/runtime/atomic.hpp ! src/hotspot/share/utilities/population_count.hpp - test/hotspot/gtest/metaprogramming/test_isIntegral.cpp Changeset: 95b102c9 Author: Tejesh R Date: 2023-01-11 07:35:30 +0000 URL: https://git.openjdk.org/loom/commit/95b102c9b1e6a46771f4bea0ca2101c05476172d 8299309: Test "java/awt/Dialog/ModalDialogTest/ModalDialogTest.java" fails because new frame was not displayed when "New Frame" button was clicked Reviewed-by: honkar, dnguyen, psadhukhan ! test/jdk/java/awt/Dialog/ModalDialogTest/ModalDialogTest.java Changeset: ef32fdb8 Author: Prasanta Sadhukhan Date: 2023-01-11 08:06:57 +0000 URL: https://git.openjdk.org/loom/commit/ef32fdb8cc9681cf7f1b7a40e3c5a3239491ec75 8284825: sun/java2d/DirectX/MultiPaintEventTest/MultiPaintEventTest.java failed with "RuntimeException: Processed unnecessary paint()." Reviewed-by: serb ! test/jdk/ProblemList.txt Changeset: 030e88d6 Author: Adam Sotona Date: 2023-01-11 08:30:48 +0000 URL: https://git.openjdk.org/loom/commit/030e88d63844f185b839977ff1b19bbc4fe688e8 8299829: In jshell, the output of "0".repeat(49999)+"2" ends with a '0' Reviewed-by: jlahoda ! src/jdk.jshell/share/classes/jdk/jshell/execution/ExecutionControlForwarder.java ! test/langtools/jdk/jshell/ToolFormatTest.java Changeset: 257f667a Author: Adam Sotona Date: 2023-01-11 09:21:28 +0000 URL: https://git.openjdk.org/loom/commit/257f667afb3dfaefb9a5a6916472066257ca0788 8296789: -completion in jshell fails to expose synthetic bridge methods Reviewed-by: jlahoda ! src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysisImpl.java ! test/langtools/jdk/jshell/CompletionSuggestionTest.java Changeset: f857f8a0 Author: Erik ?sterlund Date: 2023-01-11 09:33:05 +0000 URL: https://git.openjdk.org/loom/commit/f857f8a092d12cc11b2d48a6c9d47a70ee04c88e 8299327: Allow super late barrier expansion of store barriers in C2 Reviewed-by: kvn, rcastanedalo ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/ppc/ppc.ad ! src/hotspot/cpu/riscv/riscv.ad ! src/hotspot/cpu/x86/x86_64.ad ! src/hotspot/share/gc/shared/c2/barrierSetC2.hpp ! src/hotspot/share/opto/graphKit.cpp ! src/hotspot/share/opto/graphKit.hpp ! src/hotspot/share/opto/memnode.cpp Changeset: 5a9490a4 Author: Albert Mingkun Yang Date: 2023-01-11 10:07:52 +0000 URL: https://git.openjdk.org/loom/commit/5a9490a40e0fe281fc1b33d2c39a9a970d8a7b4f 8299853: Serial: Use more concrete type for TenuredGeneration::_the_space Reviewed-by: tschatzl, stefank ! src/hotspot/share/gc/serial/tenuredGeneration.cpp ! src/hotspot/share/gc/serial/tenuredGeneration.hpp ! src/hotspot/share/gc/serial/vmStructs_serial.hpp ! src/hotspot/share/gc/shared/cardTableRS.cpp ! src/hotspot/share/gc/shared/cardTableRS.hpp ! test/hotspot/jtreg/serviceability/sa/ClhsdbField.java Changeset: d15285f9 Author: Tobias Hartmann Date: 2023-01-11 12:39:50 +0000 URL: https://git.openjdk.org/loom/commit/d15285f948c5414028790e25b4497d28775eeb54 8299956: [BACKOUT] 8297487: G1 Remark: no need to keep alive oop constants of nmethods on stack Reviewed-by: chagedorn, tschatzl ! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp ! src/hotspot/share/gc/shared/barrierSet.cpp Changeset: 7d3400b1 Author: Per Minborg Date: 2023-01-11 15:08:52 +0000 URL: https://git.openjdk.org/loom/commit/7d3400b1cf6befd28af81113b218d0aae60ac05f 8299864: ZipFileStore#supportsFileAttributeView(String) doesn't throw NPE Reviewed-by: lancea ! src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileStore.java ! test/jdk/jdk/nio/zipfs/ZipFSTester.java Changeset: 4cd87f1b Author: Andrey Turbanov Date: 2023-01-11 15:14:41 +0000 URL: https://git.openjdk.org/loom/commit/4cd87f1bdab759ab7792afdcf644a6c3d21d51df 8299835: (jrtfs) Unnecessary null check in JrtPath.getAttributes Reviewed-by: alanb, lancea ! src/java.base/share/classes/jdk/internal/jrtfs/JrtPath.java Changeset: c7716a01 Author: Naoto Sato Date: 2023-01-11 17:01:48 +0000 URL: https://git.openjdk.org/loom/commit/c7716a0101d337ec75ffdbcc3d18058a03c2373f 8299571: ZoneRulesProvider.registerProvider() can leave inconsistent state on failure Reviewed-by: iris, rriggs, joehw ! src/java.base/share/classes/java/time/zone/ZoneRulesProvider.java + test/jdk/java/time/test/java/time/zone/TestZoneRulesProvider.java Changeset: 437d69a2 Author: Justin Lu Committer: Naoto Sato Date: 2023-01-11 17:14:08 +0000 URL: https://git.openjdk.org/loom/commit/437d69a220a8615f845013e0b495c5b47d945698 8299836: Make `user.timezone` system property searchable Reviewed-by: jpai, naoto ! src/java.base/share/classes/java/util/TimeZone.java Changeset: d663b5da Author: Justin Lu Committer: Naoto Sato Date: 2023-01-11 17:18:39 +0000 URL: https://git.openjdk.org/loom/commit/d663b5da10be1f3f33a2729e4b3605fb5e13b4d6 8299498: Usage of constructors of primitive wrapper classes should be avoided in java.lang API docs Reviewed-by: naoto, darcy, rriggs, mchung, lancea ! src/java.base/share/classes/java/lang/ArrayStoreException.java ! src/java.base/share/classes/java/lang/Byte.java ! 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/Integer.java ! src/java.base/share/classes/java/lang/Long.java ! src/java.base/share/classes/java/lang/Short.java Changeset: 9c1e98da Author: Calvin Cheung Date: 2023-01-11 17:48:36 +0000 URL: https://git.openjdk.org/loom/commit/9c1e98dac54ed2ce169f3f3df05bc80052f6a217 8298321: 2 File Leak defect groups in 2 files Reviewed-by: vlivanov, iklam, dholmes ! src/hotspot/os/posix/perfMemory_posix.cpp ! src/hotspot/share/compiler/directivesParser.cpp Changeset: a17b563f Author: Mikael Vidstedt Date: 2023-01-11 18:26:38 +0000 URL: https://git.openjdk.org/loom/commit/a17b563f54b2e0953a1dd9a613e6d5e0e9a8e4cb 8299918: Update Xcode11.3.1-MacOSX10.15 devkit at Oracle Reviewed-by: erikj ! make/conf/jib-profiles.js Changeset: 43847c43 Author: Matias Saavedra Silva Committer: Coleen Phillimore Date: 2023-01-11 19:13:26 +0000 URL: https://git.openjdk.org/loom/commit/43847c43ad2e84999554468f79016dd33528ec14 8298065: Provide more information in message of NoSuchFieldError Reviewed-by: dholmes, iklam, coleenp ! src/hotspot/share/interpreter/linkResolver.cpp ! src/hotspot/share/oops/symbol.cpp ! src/hotspot/share/oops/symbol.hpp + test/hotspot/jtreg/runtime/linkResolver/NoSuchFieldArray.jasm + test/hotspot/jtreg/runtime/linkResolver/NoSuchFieldMultiArray.jasm + test/hotspot/jtreg/runtime/linkResolver/NoSuchFieldOutputTest.java + test/hotspot/jtreg/runtime/linkResolver/NoSuchFieldPrimitive.jasm + test/hotspot/jtreg/runtime/linkResolver/NoSuchFieldReference.jasm + test/hotspot/jtreg/runtime/linkResolver/TestClass.java Changeset: 8db73f77 Author: Rajan Halade Date: 2023-01-11 21:36:08 +0000 URL: https://git.openjdk.org/loom/commit/8db73f7743014ed4527ba3cd51f58a2dfcf161fe 8300001: ProblemList test java/security/Policy/Root/Root.java Reviewed-by: mikael, dcubed ! test/jdk/ProblemList.txt Changeset: 5826a077 Author: Mikael Vidstedt Date: 2023-01-10 04:39:53 +0000 URL: https://git.openjdk.org/loom/commit/5826a077f9415cab88f90553fbfdeaabb439a53d 8299693: Change to Xcode12.4+1.1 devkit for building on macOS at Oracle Reviewed-by: erikj Backport-of: 4b6809b94a09871712df7a1c51b7192adbe2093b ! make/conf/jib-profiles.js Changeset: 21d468e5 Author: Nick Gasson Date: 2023-01-10 13:29:55 +0000 URL: https://git.openjdk.org/loom/commit/21d468e5751b082edc8db919e378fbb1cc6dc9ad 8299733: AArch64: "unexpected literal addressing mode" assertion failure with -XX:+PrintC1Statistics Co-authored-by: Ningsheng Jian Reviewed-by: chagedorn, fyang, aph ! src/hotspot/cpu/aarch64/assembler_aarch64.hpp ! test/hotspot/jtreg/ProblemList-Xcomp.txt Changeset: 151450ea Author: Patricio Chilano Mateo Date: 2023-01-10 17:16:26 +0000 URL: https://git.openjdk.org/loom/commit/151450ea9b78243130eb89a1c8ea9ad7ac13fb4a 8294744: AArch64: applications/kitchensink/Kitchensink.java crashed: assert(oopDesc::is_oop(obj)) failed: not an oop Co-authored-by: Fei Yang Reviewed-by: aph, fyang, dcubed ! src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp ! src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp Changeset: de79162f Author: Xiaohong Gong Date: 2023-01-11 01:49:56 +0000 URL: https://git.openjdk.org/loom/commit/de79162fdf122236fd518a51fd47aec75daf2948 8299715: IR test: VectorGatherScatterTest.java fails with SVE randomly Reviewed-by: psandoz, thartmann ! test/hotspot/jtreg/compiler/vectorapi/VectorGatherScatterTest.java Changeset: 0abb87a4 Author: Abhishek Kumar Committer: Tejesh R Date: 2023-01-11 07:42:42 +0000 URL: https://git.openjdk.org/loom/commit/0abb87a488e99cdbc418e14411a6bbf7a3f28079 8299227: host `exif.org` not found in link in doc comment Reviewed-by: prr, serb ! src/java.desktop/share/classes/com/sun/imageio/plugins/tiff/TIFFImageWriteParam.java ! src/java.desktop/share/classes/javax/imageio/metadata/doc-files/tiff_metadata.html ! src/java.desktop/share/native/libjavajpeg/imageioJPEG.c Changeset: 636976ad Author: Jan Lahoda Date: 2023-01-11 07:52:18 +0000 URL: https://git.openjdk.org/loom/commit/636976ada8773474a5540234a38667668349b30b 8299849: Revert JDK-8294461: wrong effectively final determination by javac Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java - test/langtools/tools/javac/lambda/8294461/EffectivelyFinalLoopIncrement.java - test/langtools/tools/javac/lambda/8294461/EffectivelyFinalLoopIncrement.out Changeset: 945ef075 Author: Maurizio Cimadamore Date: 2023-01-11 10:31:25 +0000 URL: https://git.openjdk.org/loom/commit/945ef07564bb2e7db9743d07d7d9ac7faa3f3d4d 8299862: OfAddress setter should disallow heap segments Reviewed-by: jvernee ! src/java.base/share/classes/java/lang/foreign/MemorySegment.java ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java ! src/java.base/share/classes/jdk/internal/foreign/Utils.java ! src/java.base/share/classes/jdk/internal/foreign/abi/SharedUtils.java ! test/jdk/java/foreign/TestMemoryAccessInstance.java Changeset: 33f3bd8f Author: Jesper Wilhelmsson Date: 2023-01-11 21:50:42 +0000 URL: https://git.openjdk.org/loom/commit/33f3bd8fadb26a0f99c6a13474f8676639f91c0c Merge ! src/hotspot/cpu/aarch64/assembler_aarch64.hpp ! src/java.desktop/share/classes/com/sun/imageio/plugins/tiff/TIFFImageWriteParam.java ! src/hotspot/cpu/aarch64/assembler_aarch64.hpp ! src/java.desktop/share/classes/com/sun/imageio/plugins/tiff/TIFFImageWriteParam.java Changeset: efed8893 Author: Alan Bateman Date: 2023-01-12 20:21:29 +0000 URL: https://git.openjdk.org/loom/commit/efed8893d28a336485c9fd4a7b45f1c7b287b4bc Merge ! make/RunTests.gmk ! make/conf/jib-profiles.js ! test/hotspot/jtreg/ProblemList-Xcomp.txt ! test/jdk/ProblemList.txt ! make/RunTests.gmk ! make/conf/jib-profiles.js ! test/hotspot/jtreg/ProblemList-Xcomp.txt ! test/jdk/ProblemList.txt From duke at openjdk.org Thu Jan 12 20:36:58 2023 From: duke at openjdk.org (duke) Date: Thu, 12 Jan 2023 20:36:58 GMT Subject: git: openjdk/loom: master: 106 new changesets Message-ID: <62b47ee5-37be-4016-a705-0618c5ff48a1@openjdk.org> Changeset: 5ae6de85 Author: ravi.ra.gupta Committer: Sergey Bylokhov Date: 2023-01-04 22:44:38 +0000 URL: https://git.openjdk.org/loom/commit/5ae6de859d472d107cdf642c417c6d2f1c74e5db 8299296: Write a test to verify the components selection sends ItemEvent Reviewed-by: serb + test/jdk/java/awt/event/ComponentEvent/ComponentItemEventTest.java Changeset: 578c287a Author: Abhishek Kumar Committer: Sergey Bylokhov Date: 2023-01-04 22:45:39 +0000 URL: https://git.openjdk.org/loom/commit/578c287a68f38f21a91d200b7a0657aaeb721b3f 8081507: Open or Save button in JFileChooser has OK title in GTK LaF Reviewed-by: serb, tr ! src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk.properties + test/jdk/com/sun/java/swing/plaf/gtk/TestFileChooserOpenSaveButtonText.java ! test/jdk/sanity/client/SwingSet/src/FileChooserDemoTest.java Changeset: 2ccdefc8 Author: Matthias Baesken Date: 2023-01-05 07:59:41 +0000 URL: https://git.openjdk.org/loom/commit/2ccdefc81c0ea2ea5c4380bb045aa82ad1eb8205 8299470: sun/jvm/hotspot/SALauncher.java handling of negative rmiport args Reviewed-by: clanger, sspitsyn, kevinw ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/SAGetopt.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/SALauncher.java ! test/hotspot/jtreg/serviceability/sa/sadebugd/SADebugDTest.java Changeset: c929d8be Author: Matthias Baesken Date: 2023-01-05 08:26:38 +0000 URL: https://git.openjdk.org/loom/commit/c929d8be5d19f2030406eb5c19f854e672c7a547 8299475: Enhance SocketException by cause where it is missing in net and nio area Reviewed-by: alanb ! src/java.base/share/classes/java/net/ServerSocket.java ! src/java.base/share/classes/java/net/Socket.java ! src/java.base/share/classes/java/net/SocksSocketImpl.java ! src/java.base/share/classes/sun/nio/ch/NioSocketImpl.java Changeset: e7361cb7 Author: Sergey Bylokhov Date: 2023-01-05 08:47:21 +0000 URL: https://git.openjdk.org/loom/commit/e7361cb746cf00984dd5193ec8a8cc90e1e5a39b 8299430: Cleanup: delete unnecessary semicolons in java.desktop module Reviewed-by: stsypanov, aghaisas, iris ! src/java.desktop/macosx/classes/apple/laf/JRSUIControl.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaFileChooserUI.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaTabbedPaneContrastUI.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaTabbedPaneCopyFromBasicUI.java ! src/java.desktop/macosx/classes/sun/font/CCharToGlyphMapper.java ! src/java.desktop/macosx/classes/sun/java2d/MacOSFlags.java ! src/java.desktop/macosx/classes/sun/java2d/metal/MTLLayer.java ! src/java.desktop/macosx/classes/sun/java2d/opengl/CGLLayer.java ! src/java.desktop/macosx/native/libawt_lwawt/awt/JavaAccessibilityUtilities.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/JavaTextAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CellAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CommonComponentAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CommonTextAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/OutlineRowAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLClip.m ! src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLGlyphCache.h ! src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLPaints.m ! src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLRenderer.m ! src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp ! src/java.desktop/share/classes/com/sun/imageio/plugins/png/PNGImageReader.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/png/RowFilter.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/tiff/TIFFImageWriteParam.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/tiff/TIFFOldJPEGDecompressor.java ! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifDesktopPaneUI.java ! src/java.desktop/share/classes/java/awt/Component.java ! src/java.desktop/share/classes/java/awt/Desktop.java ! src/java.desktop/share/classes/java/awt/Dialog.java ! src/java.desktop/share/classes/java/awt/EventFilter.java ! src/java.desktop/share/classes/java/awt/GraphicsDevice.java ! src/java.desktop/share/classes/java/awt/TrayIcon.java ! src/java.desktop/share/classes/java/awt/im/InputMethodHighlight.java ! src/java.desktop/share/classes/java/awt/image/ColorConvertOp.java ! src/java.desktop/share/classes/javax/accessibility/AccessibleAttributeSequence.java ! src/java.desktop/share/classes/javax/accessibility/AccessibleTextSequence.java ! src/java.desktop/share/classes/javax/print/StreamPrintService.java ! src/java.desktop/share/classes/javax/swing/DefaultDesktopManager.java ! src/java.desktop/share/classes/javax/swing/LayoutStyle.java ! src/java.desktop/share/classes/javax/swing/MultiUIDefaults.java ! src/java.desktop/share/classes/javax/swing/Spring.java ! src/java.desktop/share/classes/javax/swing/TransferHandler.java ! src/java.desktop/share/classes/javax/swing/event/TableColumnModelEvent.java ! src/java.desktop/share/classes/javax/swing/event/TableModelEvent.java ! src/java.desktop/share/classes/javax/swing/filechooser/FileView.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicComboPopup.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicDesktopIconUI.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicIconFactory.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicMenuUI.java ! src/java.desktop/share/classes/javax/swing/plaf/metal/MetalInternalFrameUI.java ! src/java.desktop/share/classes/javax/swing/plaf/nimbus/ImageScalingHelper.java ! src/java.desktop/share/classes/javax/swing/text/Caret.java ! src/java.desktop/share/classes/javax/swing/text/Highlighter.java ! src/java.desktop/share/classes/javax/swing/text/View.java ! src/java.desktop/share/classes/sun/awt/AppContext.java ! src/java.desktop/share/classes/sun/awt/CausedFocusEvent.java ! src/java.desktop/share/classes/sun/awt/EmbeddedFrame.java ! src/java.desktop/share/classes/sun/awt/SunToolkit.java ! src/java.desktop/share/classes/sun/awt/image/ImageCache.java ! src/java.desktop/share/classes/sun/font/LayoutPathImpl.java ! src/java.desktop/share/classes/sun/font/SunFontManager.java ! src/java.desktop/share/classes/sun/java2d/Disposer.java ! src/java.desktop/share/classes/sun/java2d/StateTrackable.java ! src/java.desktop/share/classes/sun/java2d/cmm/lcms/LCMS.java ! src/java.desktop/share/classes/sun/java2d/loops/ProcessPath.java ! src/java.desktop/share/classes/sun/swing/plaf/synth/Paint9Painter.java ! src/java.desktop/share/classes/sun/swing/text/TextComponentPrintable.java ! src/java.desktop/share/native/common/awt/medialib/mlib_ImageCreate.c ! src/java.desktop/share/native/common/font/AccelGlyphCache.h ! src/java.desktop/share/native/common/java2d/opengl/OGLSurfaceData.h ! src/java.desktop/share/native/libawt/java2d/Disposer.h ! src/java.desktop/share/native/libawt/java2d/SurfaceData.h ! src/java.desktop/share/native/libawt/java2d/Trace.h ! src/java.desktop/share/native/libawt/java2d/loops/GraphicsPrimitiveMgr.h ! src/java.desktop/share/native/libawt/java2d/loops/ImageData.h ! src/java.desktop/share/native/libawt/java2d/pipe/Region.h ! src/java.desktop/unix/classes/sun/awt/UNIXToolkit.java ! src/java.desktop/unix/classes/sun/awt/X11/XBaseWindow.java ! src/java.desktop/unix/classes/sun/awt/X11/XKeysym.java ! src/java.desktop/unix/classes/sun/awt/X11/XSelection.java ! src/java.desktop/unix/classes/sun/awt/X11/XTrayIconPeer.java ! src/java.desktop/unix/classes/sun/font/NativeFont.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsIconFactory.java ! src/java.desktop/windows/classes/sun/awt/windows/WDataTransferer.java ! src/java.desktop/windows/classes/sun/java2d/d3d/D3DGraphicsDevice.java ! src/java.desktop/windows/classes/sun/java2d/d3d/D3DSurfaceData.java ! src/java.desktop/windows/native/libawt/java2d/d3d/ShaderList.h ! src/java.desktop/windows/native/libawt/java2d/windows/GDIBlitLoops.cpp ! src/java.desktop/windows/native/libawt/windows/awt_DCHolder.cpp ! src/java.desktop/windows/native/libawt/windows/awt_Mlib.h ! src/java.desktop/windows/native/libawt/windows/awt_PrintJob.cpp ! src/java.desktop/windows/native/libawt/windows/awt_ScrollPane.cpp ! src/java.desktop/windows/native/libawt/windows/awt_Toolkit.cpp ! src/java.desktop/windows/native/libawt/windows/img_util_md.h Changeset: 1ca31d34 Author: Matthias Baesken Date: 2023-01-05 09:31:38 +0000 URL: https://git.openjdk.org/loom/commit/1ca31d34fcba5e9861104402466b5dd4cccdbafd 8299657: sun/tools/jhsdb/SAGetoptTest.java fails after 8299470 Reviewed-by: clanger ! test/jdk/sun/tools/jhsdb/SAGetoptTest.java Changeset: 87238470 Author: Roland Westrelin Date: 2023-01-05 09:33:14 +0000 URL: https://git.openjdk.org/loom/commit/872384707e89d03ede655aad16f360dc94f10152 8298848: C2: clone all of (CmpP (LoadKlass (AddP down at split if Reviewed-by: kvn, thartmann, chagedorn ! src/hotspot/share/opto/loopnode.hpp ! src/hotspot/share/opto/split_if.cpp + test/hotspot/jtreg/compiler/types/TestCheckCastPPBecomesTOP.java Changeset: be64bf8c Author: Ashutosh Mehra Committer: Calvin Cheung Date: 2023-01-05 16:09:28 +0000 URL: https://git.openjdk.org/loom/commit/be64bf8cf085c17b8e405b9447357ae59ef21765 8299329: Assertion failure with fastdebug build when trying to use CDS without classpath Reviewed-by: iklam, ccheung ! src/hotspot/share/cds/filemap.cpp ! test/hotspot/jtreg/runtime/cds/appcds/WrongClasspath.java ! test/lib/jdk/test/lib/process/ProcessTools.java Changeset: b908388e Author: Andrey Turbanov Date: 2023-01-05 16:49:23 +0000 URL: https://git.openjdk.org/loom/commit/b908388e817e9bf30c8558b53efc9b2ddf2bad75 8298449: Unnecessary Vector usage in MetaData.ProxyPersistenceDelegate Reviewed-by: serb ! src/java.desktop/share/classes/java/beans/MetaData.java Changeset: a49ccb95 Author: Naoto Sato Date: 2023-01-05 17:49:24 +0000 URL: https://git.openjdk.org/loom/commit/a49ccb959b7e50ee67b1ab4feca47c34bdbc14fe 8299292: Missing elements in aliased String array Reviewed-by: iris, joehw ! make/jdk/src/classes/build/tools/cldrconverter/CLDRConverter.java Changeset: 3e2314d0 Author: Kim Barrett Date: 2023-01-05 19:49:01 +0000 URL: https://git.openjdk.org/loom/commit/3e2314d08218dc8a4f4fc61bd4e1d5e58a0129c7 8299254: Support dealing with standard assert macro Reviewed-by: erikj, xuelei, dholmes, mikael ! make/hotspot/lib/JvmFlags.gmk + src/hotspot/share/utilities/vmassert_reinstall.hpp + src/hotspot/share/utilities/vmassert_uninstall.hpp ! test/hotspot/gtest/code/test_codestrings.cpp ! test/hotspot/gtest/gc/shared/test_memset_with_concurrent_readers.cpp ! test/hotspot/gtest/gc/shenandoah/test_shenandoahNumberSeq.cpp ! test/hotspot/gtest/jfr/test_networkUtilization.cpp ! test/hotspot/gtest/unittest.hpp Changeset: dfdbd0fe Author: Kim Barrett Date: 2023-01-05 22:02:45 +0000 URL: https://git.openjdk.org/loom/commit/dfdbd0fe7f800257c40fd148bc0a41c8eb826bdf 8299343: Windows: Invalid thread_native_entry declaration Reviewed-by: dholmes, iklam ! src/hotspot/os/windows/os_windows.cpp ! src/hotspot/os/windows/os_windows.hpp Changeset: 4b6809b9 Author: Mikael Vidstedt Date: 2023-01-05 22:39:44 +0000 URL: https://git.openjdk.org/loom/commit/4b6809b94a09871712df7a1c51b7192adbe2093b 8299693: Change to Xcode12.4+1.1 devkit for building on macOS at Oracle Reviewed-by: dholmes, erikj ! make/conf/jib-profiles.js Changeset: 7845b0d7 Author: Anto J Committer: Sergey Bylokhov Date: 2023-01-06 00:37:26 +0000 URL: https://git.openjdk.org/loom/commit/7845b0d7b4193688448b7bf0c427df4976d302e5 8296934: Write a test to verify whether Undecorated Frame can be iconified or not Reviewed-by: serb + test/jdk/java/awt/Frame/Iconify/IconifyTest.java Changeset: 775da84a Author: Artem Semenov Date: 2023-01-06 07:09:05 +0000 URL: https://git.openjdk.org/loom/commit/775da84a84770696495561277eb040f53260ecaf 8299412: JNI call of getAccessibleActionCount on a wrong thread Reviewed-by: prr, serb ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CAccessibility.java ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CommonComponentAccessibility.m Changeset: 99be7408 Author: Tejesh R Date: 2023-01-06 07:50:33 +0000 URL: https://git.openjdk.org/loom/commit/99be74088eec3e7974642c8aa5792377d32ebe67 8299306: Test "javax/swing/JFileChooser/FileSystemView/CustomFSVLinkTest.java" fails on Windows 10 x64 because there are some buttons did not display button name Reviewed-by: psadhukhan, abhiscxk ! test/jdk/javax/swing/JFileChooser/FileSystemView/CustomFSVLinkTest.java Changeset: b5b7948d Author: Sergey Bylokhov Date: 2023-01-06 08:04:51 +0000 URL: https://git.openjdk.org/loom/commit/b5b7948d9b4870d9e84ec8d8b544b252f9053785 8298240: Replace the usage of ImageLayoutException by the CMMException Reviewed-by: prr ! src/java.desktop/share/classes/sun/java2d/cmm/lcms/LCMSImageLayout.java ! src/java.desktop/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java Changeset: cc4936a7 Author: Tobias Hartmann Date: 2023-01-06 08:28:09 +0000 URL: https://git.openjdk.org/loom/commit/cc4936a79e1c1723542d575a2596edd29248817e 8298720: Insufficient error handling when CodeBuffer is exhausted Reviewed-by: kvn, fyang ! src/hotspot/cpu/aarch64/c1_MacroAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/c2_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/riscv/c2_MacroAssembler_riscv.cpp ! src/hotspot/cpu/riscv/macroAssembler_riscv.hpp ! src/hotspot/cpu/riscv/sharedRuntime_riscv.cpp Changeset: 0234f813 Author: Andrey Turbanov Date: 2023-01-06 08:29:47 +0000 URL: https://git.openjdk.org/loom/commit/0234f813e6113fee133a2cab77566d1fcb191c8b 8298447: Unnecessary Vector usage in DocPrintJob implementations Reviewed-by: serb ! src/java.desktop/share/classes/sun/print/PSStreamPrintJob.java ! src/java.desktop/unix/classes/sun/print/UnixPrintJob.java ! src/java.desktop/windows/classes/sun/print/Win32PrintJob.java Changeset: 88f0ea78 Author: bobpengxie Committer: Jie Fu Date: 2023-01-06 10:48:28 +0000 URL: https://git.openjdk.org/loom/commit/88f0ea7887ef3b05517e8c14be2d2d084f72943f 8299726: [cleanup] Some code cleanup in opto/compile.hpp Reviewed-by: thartmann ! src/hotspot/share/opto/compile.hpp Changeset: 5598acc3 Author: Aleksey Shipilev Date: 2023-01-06 11:28:38 +0000 URL: https://git.openjdk.org/loom/commit/5598acc345dbd6f806145157ae6f7c591340a1d1 8294403: [REDO] make test should report only on executed tests Reviewed-by: erikj, dholmes, jpai, djelinski ! doc/testing.html ! doc/testing.md ! make/RunTests.gmk Changeset: 8cc1669f Author: Jie Fu Date: 2023-01-06 12:56:36 +0000 URL: https://git.openjdk.org/loom/commit/8cc1669ffd22c8cabc98585ca6df6fc5fed5fb10 8299721: [Vector API] assert in switch-default of LibraryCallKit::arch_supports_vector_rotate is too weak to catch bugs Reviewed-by: jbhateja ! src/hotspot/share/opto/vectorIntrinsics.cpp Changeset: 1e997292 Author: Coleen Phillimore Date: 2023-01-06 13:57:23 +0000 URL: https://git.openjdk.org/loom/commit/1e9972922a3d8232cf111a391584638b272a3a17 8299274: Add elements to resolved_references consistently Reviewed-by: iklam, dholmes, rehn, fparain ! src/hotspot/share/cds/cdsProtectionDomain.cpp ! src/hotspot/share/ci/ciEnv.cpp ! src/hotspot/share/interpreter/interpreterRuntime.cpp ! src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp ! src/hotspot/share/oops/constantPool.cpp ! src/hotspot/share/oops/constantPool.hpp ! src/hotspot/share/oops/cpCache.cpp ! src/hotspot/share/oops/cpCache.hpp ! src/hotspot/share/oops/cpCache.inline.hpp ! src/hotspot/share/oops/objArrayOop.cpp ! src/hotspot/share/oops/objArrayOop.hpp Changeset: 3dcf7001 Author: Markus KARG Committer: Brian Burkhalter Date: 2023-01-06 17:35:17 +0000 URL: https://git.openjdk.org/loom/commit/3dcf7001611aa66a7a1b4a01dfa6dfb296e70da1 8299336: InputStream::DEFAULT_BUFFER_SIZE should be 16384 Reviewed-by: bpb ! src/java.base/share/classes/java/io/InputStream.java Changeset: ba03f42a Author: Weijun Wang Date: 2023-01-06 18:46:37 +0000 URL: https://git.openjdk.org/loom/commit/ba03f42a50375c05400de9bd19d1d6d444f0a46d 8299746: Accept unknown signatureAlgorithm in PKCS7 SignerInfo Reviewed-by: kdriver, ascarpino, hchao ! src/java.base/share/classes/sun/security/pkcs/SignerInfo.java + test/jdk/sun/security/pkcs/pkcs7/NewSigAlg.java Changeset: d6e9f015 Author: Chris Plummer Date: 2023-01-06 18:49:11 +0000 URL: https://git.openjdk.org/loom/commit/d6e9f01584ef84d6390c356fd3b342d9d79899ab 8285416: [LOOM] Some nsk/jdi tests fail due to needing too many virtual threads 8282383: [LOOM] 6 nsk JDI and JDB tests sometimes failing with vthread wrapper due to running out of carrier threads Reviewed-by: dholmes, sspitsyn, alanb, lmesnik ! test/hotspot/jtreg/ProblemList-svc-vthread.txt ! test/hotspot/jtreg/vmTestbase/nsk/share/jdb/Launcher.java ! test/hotspot/jtreg/vmTestbase/nsk/share/jdi/Binder.java Changeset: 8c70bf3f Author: Andrei Pangin Committer: Sandhya Viswanathan Date: 2023-01-06 19:00:20 +0000 URL: https://git.openjdk.org/loom/commit/8c70bf3fff6f01b637f9e72a0b4c617051dbfafd 8299544: Improve performance of CRC32C intrinsics (non-AVX-512) for small inputs Reviewed-by: kvn, eastigeevich, sviswanathan ! src/hotspot/cpu/x86/crc32c.h ! src/hotspot/cpu/x86/macroAssembler_x86.cpp Changeset: d6d6eb4c Author: Ashutosh Mehra Committer: Calvin Cheung Date: 2023-01-06 19:56:12 +0000 URL: https://git.openjdk.org/loom/commit/d6d6eb4cba3d2d85035b46d18e8817b5b2a354a2 8299699: Test runtime/cds/appcds/WrongClasspath.java fails after JDK-8299329 Reviewed-by: iklam, ccheung ! test/hotspot/jtreg/runtime/cds/appcds/TestCommon.java Changeset: 4a95c74b Author: Sergey Bylokhov Date: 2023-01-06 20:17:10 +0000 URL: https://git.openjdk.org/loom/commit/4a95c74b7628ad297d2a6bff2d47c6a9ddf876e3 8299425: "LCMSImageLayout.isIntPacked" flag can be deleted Reviewed-by: prr ! src/java.desktop/share/classes/sun/java2d/cmm/lcms/LCMS.java ! src/java.desktop/share/classes/sun/java2d/cmm/lcms/LCMSImageLayout.java ! src/java.desktop/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java ! src/java.desktop/share/native/liblcms/LCMS.c Changeset: d086e82b Author: Sergey Tsypanov Committer: Brian Burkhalter Date: 2023-01-06 21:01:21 +0000 URL: https://git.openjdk.org/loom/commit/d086e82b3c554362a8fc7095025f8f2910d6e4bc 8299600: Use Objects.check*() where appropriate in java.io Reviewed-by: alanb, bpb ! src/java.base/share/classes/java/io/CharArrayWriter.java ! src/java.base/share/classes/java/io/FilterOutputStream.java ! src/java.base/share/classes/java/io/LineNumberInputStream.java ! src/java.base/share/classes/java/io/PipedOutputStream.java ! src/java.base/share/classes/java/io/PipedWriter.java ! src/java.base/share/classes/java/io/StringWriter.java Changeset: 73101314 Author: Sergey Bylokhov Date: 2023-01-06 23:09:07 +0000 URL: https://git.openjdk.org/loom/commit/7310131409d3be351e780696173e7354ab51e467 8299337: The java.awt.image.ColorModel#pData field is unused Reviewed-by: prr ! src/java.desktop/macosx/native/libawt_lwawt/awt/ImageSurfaceData.m ! src/java.desktop/share/classes/java/awt/image/ColorModel.java ! src/java.desktop/share/native/libawt/awt/image/imageInitIDs.c ! src/java.desktop/share/native/libawt/awt/image/imageInitIDs.h ! src/java.desktop/unix/native/common/awt/X11Color.c Changeset: 9c4ed16b Author: Maurizio Cimadamore Date: 2023-01-05 09:44:16 +0000 URL: https://git.openjdk.org/loom/commit/9c4ed16be2fdb20f2917a6e8efacfbb30d3118b1 8299561: VaList.empty() doesn't return a list associated with the global scope Reviewed-by: jvernee ! src/java.base/share/classes/jdk/internal/foreign/abi/aarch64/linux/LinuxAArch64VaList.java ! src/java.base/share/classes/jdk/internal/foreign/abi/x64/sysv/SysVVaList.java ! test/jdk/java/foreign/valist/VaListTest.java Changeset: 284c94e2 Author: Pavel Rappo Date: 2023-01-05 22:43:20 +0000 URL: https://git.openjdk.org/loom/commit/284c94e20d49b6b6a09b1daa398abbbe4d049de3 8298525: javadoc crashes with "UnsupportedOperationException: Not yet implemented" in SeeTaglet.inherit Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/SeeTaglet.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/SpecTaglet.java ! test/langtools/jdk/javadoc/doclet/testInheritDocWithinInappropriateTag/TestInheritDocWithinInappropriateTag.java Changeset: 136f5db0 Author: Bhavana Kilambi Committer: Nick Gasson Date: 2023-01-06 10:04:04 +0000 URL: https://git.openjdk.org/loom/commit/136f5db03d664fd77f8042c6f0875dea964ca5e9 8299528: IR test: TestEor3AArch64.java fails on aarch64 Reviewed-by: thartmann, chagedorn ! test/hotspot/jtreg/compiler/lib/ir_framework/IRNode.java ! test/hotspot/jtreg/compiler/vectorization/TestEor3AArch64.java Changeset: 5eee2a07 Author: Maurizio Cimadamore Date: 2023-01-06 14:52:08 +0000 URL: https://git.openjdk.org/loom/commit/5eee2a07f5db5979149cc3e96d4f608ed135a7b3 8299740: CaptureCallState is missing @Preview annotation Reviewed-by: alanb ! src/java.base/share/classes/java/lang/foreign/Linker.java Changeset: 1f141bd7 Author: Alexandre Iline Date: 2023-01-06 18:51:41 +0000 URL: https://git.openjdk.org/loom/commit/1f141bd7a99085c5464626eb83402ffabf9d38c8 8299705: JCov coverage runs depend on jdk_symbols Reviewed-by: erikj ! make/conf/jib-profiles.js Changeset: 5393dc9a Author: Jesper Wilhelmsson Date: 2023-01-07 02:05:59 +0000 URL: https://git.openjdk.org/loom/commit/5393dc9a48064505f0b79b7059f87bec33c1c8fe Merge ! make/conf/jib-profiles.js ! test/hotspot/jtreg/compiler/lib/ir_framework/IRNode.java ! test/langtools/jdk/javadoc/doclet/testInheritDocWithinInappropriateTag/TestInheritDocWithinInappropriateTag.java ! make/conf/jib-profiles.js ! test/hotspot/jtreg/compiler/lib/ir_framework/IRNode.java ! test/langtools/jdk/javadoc/doclet/testInheritDocWithinInappropriateTag/TestInheritDocWithinInappropriateTag.java Changeset: 63cf4aa0 Author: Justin Lu Committer: Jaikiran Pai Date: 2023-01-07 02:19:15 +0000 URL: https://git.openjdk.org/loom/commit/63cf4aa0c897406fc9370a8e05cb035caafc5d69 8299499: Usage of constructors of primitive wrapper classes should be avoided in java.net API docs Reviewed-by: naoto, jpai ! src/java.base/share/classes/java/net/SocketOptions.java Changeset: d5b80abc Author: Justin Lu Committer: Jaikiran Pai Date: 2023-01-07 02:20:12 +0000 URL: https://git.openjdk.org/loom/commit/d5b80abcbfff57c7728d3e42a696a762f08bc7ad 8299617: CurrencySymbols.properties is missing the copyright notice Reviewed-by: naoto, iris, jpai ! test/jdk/java/text/Format/NumberFormat/CurrencySymbols.properties Changeset: e209693a Author: Jaikiran Pai Date: 2023-01-07 02:33:52 +0000 URL: https://git.openjdk.org/loom/commit/e209693a37e49ba5fd5b1ad3404e9dd807c545f3 8258776: ThreadLocal#initialValue() Javadoc is unaware of ThreadLocal#withInitial() Reviewed-by: alanb ! src/java.base/share/classes/java/lang/ThreadLocal.java Changeset: 834e50e9 Author: Srinivas Mandalika Committer: Sergey Bylokhov Date: 2023-01-08 09:08:04 +0000 URL: https://git.openjdk.org/loom/commit/834e50e9efc16effad7469cae99ab8f918a30e86 8298921: Create a regression test for JDK-8139581 Reviewed-by: serb + test/jdk/java/awt/Component/ComponentRedrawnTest.java Changeset: d53cac37 Author: Justin King Committer: Kim Barrett Date: 2023-01-08 10:45:36 +0000 URL: https://git.openjdk.org/loom/commit/d53cac379419b7b74df045bb119df6d5f9e91878 8299481: Remove metaprogramming/removePointer.hpp Reviewed-by: kbarrett, tschatzl - src/hotspot/share/metaprogramming/removePointer.hpp ! src/hotspot/share/runtime/atomic.hpp - test/hotspot/gtest/metaprogramming/test_removePointer.cpp Changeset: 7607c07e Author: SWinxy Committer: Julian Waters Date: 2023-01-09 02:14:43 +0000 URL: https://git.openjdk.org/loom/commit/7607c07e002cd86cf2a0f44df9933612550ced95 8299774: SYNTH_BUTTON_UI_KEY field is unused Reviewed-by: serb ! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthButtonUI.java Changeset: c4449224 Author: Abhishek Kumar Committer: Tejesh R Date: 2023-01-09 04:47:33 +0000 URL: https://git.openjdk.org/loom/commit/c4449224bbb70d1a0256ebf19297450ab0f98d4b 8218474: JComboBox display issue with GTKLookAndFeel Reviewed-by: tr, serb ! src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKLookAndFeel.java ! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthComboBoxUI.java ! src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.c + test/jdk/javax/swing/JComboBox/TestComboBoxComponentRendering.java ! test/jdk/javax/swing/JComboBox/TestComboBoxHeight.java Changeset: d03a5d95 Author: Daniel Jeli?ski Date: 2023-01-09 07:32:55 +0000 URL: https://git.openjdk.org/loom/commit/d03a5d9580ef3b9be4d766ff9a11d6fd5fa133f9 8299593: getprotobyname should not be used Reviewed-by: cjplummer ! src/jdk.jdwp.agent/unix/native/libdt_socket/socket_md.c ! src/jdk.jdwp.agent/windows/native/libdt_socket/socket_md.c Changeset: 8d17d1ee Author: Daniel Jeli?ski Date: 2023-01-09 07:39:12 +0000 URL: https://git.openjdk.org/loom/commit/8d17d1ee6f08ee90771d469182aaaaa7c23971fd 6914801: IPv6 unavailable if stdin is a socket Reviewed-by: michaelm ! src/java.base/unix/native/libnet/net_util_md.c ! src/java.base/unix/native/libnio/ch/InheritedChannel.c + test/jdk/java/nio/channels/spi/SelectorProvider/inheritedChannel/CheckIPv6Service.java + test/jdk/java/nio/channels/spi/SelectorProvider/inheritedChannel/CheckIPv6Test.java ! test/jdk/java/nio/channels/spi/SelectorProvider/inheritedChannel/EchoTest.java ! test/jdk/java/nio/channels/spi/SelectorProvider/inheritedChannel/InheritedChannelTest.java ! test/jdk/java/nio/channels/spi/SelectorProvider/inheritedChannel/Launcher.java Changeset: 9b1ade8e Author: Damon Fenacci Committer: Tobias Hartmann Date: 2023-01-09 07:56:11 +0000 URL: https://git.openjdk.org/loom/commit/9b1ade8e2b324b3875bf97c70d8591c577568c32 8295406: C1 crash with -XX:TypeProfileArgsLimit=0 -XX:TypeProfileLevel=222 Reviewed-by: thartmann, kvn ! src/hotspot/share/oops/methodData.cpp + test/hotspot/jtreg/compiler/profiling/TestTypeProfileArgsLimit.java Changeset: 05a0a710 Author: Roland Westrelin Date: 2023-01-09 08:26:08 +0000 URL: https://git.openjdk.org/loom/commit/05a0a710313917fe7124ff43fe9c9af1d649bcac 8297933: [REDO] Compiler should only use verified interface types for optimization Reviewed-by: kvn, vlivanov ! src/hotspot/share/ci/ciArrayKlass.cpp ! src/hotspot/share/ci/ciInstanceKlass.cpp ! src/hotspot/share/ci/ciInstanceKlass.hpp ! src/hotspot/share/ci/ciObjectFactory.cpp ! src/hotspot/share/opto/arraycopynode.cpp ! src/hotspot/share/opto/castnode.cpp ! src/hotspot/share/opto/castnode.hpp ! src/hotspot/share/opto/cfgnode.cpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/compile.hpp ! src/hotspot/share/opto/doCall.cpp ! src/hotspot/share/opto/graphKit.cpp ! src/hotspot/share/opto/idealGraphPrinter.cpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/opto/memnode.cpp ! src/hotspot/share/opto/node.cpp ! src/hotspot/share/opto/parse1.cpp ! src/hotspot/share/opto/parse3.cpp ! src/hotspot/share/opto/parseHelper.cpp ! src/hotspot/share/opto/subnode.cpp ! src/hotspot/share/opto/subtypenode.cpp ! src/hotspot/share/opto/type.cpp ! src/hotspot/share/opto/type.hpp ! test/hotspot/jtreg/compiler/intrinsics/klass/CastNullCheckDroppingsTest.java + test/hotspot/jtreg/compiler/types/TestExactArrayOfBasicType.java Changeset: d2827ec8 Author: Emanuel Peter Date: 2023-01-09 08:34:24 +0000 URL: https://git.openjdk.org/loom/commit/d2827ec8f77020241fee7d613fb7cf081b455eb9 8299671: speed up compiler/intrinsics/string/TestStringLatin1IndexOfChar.java Reviewed-by: thartmann, kvn ! test/hotspot/jtreg/compiler/intrinsics/string/TestStringLatin1IndexOfChar.java Changeset: a503ec2c Author: Erik ?sterlund Date: 2023-01-09 10:01:26 +0000 URL: https://git.openjdk.org/loom/commit/a503ec2cc7042f0d2427fcbec0237937f324c755 8299608: Add Register + imm32 orq to x86_64 assembler Reviewed-by: shade, sviswanathan, kvn ! src/hotspot/cpu/x86/assembler_x86.cpp ! src/hotspot/cpu/x86/assembler_x86.hpp Changeset: 4072412c Author: Prasanta Sadhukhan Date: 2023-01-09 10:14:06 +0000 URL: https://git.openjdk.org/loom/commit/4072412c1fd1e28febff71c6b37a9813f22bdc4b 8298876: Swing applications do not get repainted coming out of sleep on Windows 10 Reviewed-by: angorya, prr ! src/java.desktop/windows/classes/sun/java2d/d3d/D3DScreenUpdateManager.java - test/jdk/sun/java2d/DirectX/MultiPaintEventTest/MultiPaintEventTest.java Changeset: 500c3c17 Author: Johan Sj?len Date: 2023-01-09 10:18:26 +0000 URL: https://git.openjdk.org/loom/commit/500c3c17379fe0a62d42ba31bdcdb584b1823f60 8298730: Refactor subsystem_file_line_contents and add docs and tests Reviewed-by: sgehwolf, iklam ! src/hotspot/os/linux/cgroupSubsystem_linux.hpp ! src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp ! src/hotspot/os/linux/cgroupV2Subsystem_linux.cpp + test/hotspot/gtest/os/linux/test_cgroupSubsystem_linux.cpp ! test/hotspot/gtest/runtime/test_os_linux_cgroups.cpp Changeset: 70684574 Author: Patrick Zhang Committer: Nick Gasson Date: 2023-01-09 11:07:05 +0000 URL: https://git.openjdk.org/loom/commit/706845743699efb01994e2d12c65023a3e972b77 8298472: AArch64: Detect Ampere-1 and Ampere-1A CPUs and set default options Reviewed-by: aph, ngasson ! src/hotspot/cpu/aarch64/vm_version_aarch64.cpp ! src/hotspot/cpu/aarch64/vm_version_aarch64.hpp Changeset: 66db0bb6 Author: Albert Mingkun Yang Date: 2023-01-09 11:39:06 +0000 URL: https://git.openjdk.org/loom/commit/66db0bb6a15310e4e60ff1e33d40e03c52c4eca8 8299692: G1: Remove unused G1BlockOffsetTable::is_card_boundary Reviewed-by: kbarrett ! src/hotspot/share/gc/g1/g1BlockOffsetTable.cpp ! src/hotspot/share/gc/g1/g1BlockOffsetTable.hpp Changeset: 4ba81221 Author: Erik ?sterlund Date: 2023-01-09 13:31:26 +0000 URL: https://git.openjdk.org/loom/commit/4ba8122197e912db4894ed7fe395a8842268fbef 8299312: Clean up BarrierSetNMethod Reviewed-by: mdoerr, fyang ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/aarch64/gc/shared/barrierSetAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/gc/shared/barrierSetNMethod_aarch64.cpp ! src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp ! src/hotspot/cpu/arm/arm.ad ! src/hotspot/cpu/arm/gc/shared/barrierSetAssembler_arm.cpp ! src/hotspot/cpu/arm/gc/shared/barrierSetNMethod_arm.cpp ! src/hotspot/cpu/ppc/gc/shared/barrierSetAssembler_ppc.cpp ! src/hotspot/cpu/ppc/gc/shared/barrierSetNMethod_ppc.cpp ! src/hotspot/cpu/riscv/gc/shared/barrierSetAssembler_riscv.cpp ! src/hotspot/cpu/riscv/gc/shared/barrierSetNMethod_riscv.cpp ! src/hotspot/cpu/riscv/riscv.ad ! src/hotspot/cpu/riscv/stubGenerator_riscv.cpp ! src/hotspot/cpu/s390/gc/shared/barrierSetAssembler_s390.cpp ! src/hotspot/cpu/s390/gc/shared/barrierSetNMethod_s390.cpp ! src/hotspot/cpu/x86/gc/shared/barrierSetAssembler_x86.cpp ! src/hotspot/cpu/x86/gc/shared/barrierSetNMethod_x86.cpp ! src/hotspot/cpu/x86/x86_64.ad ! src/hotspot/cpu/zero/gc/shared/barrierSetNMethod_zero.cpp ! src/hotspot/share/gc/shared/barrierSet.cpp ! src/hotspot/share/gc/shared/barrierSetNMethod.cpp ! src/hotspot/share/gc/shared/barrierSetNMethod.hpp ! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.cpp ! src/hotspot/share/gc/shenandoah/shenandoahCodeRoots.cpp ! src/hotspot/share/gc/z/zBarrierSetNMethod.cpp ! src/hotspot/share/gc/z/zBarrierSetNMethod.hpp ! src/hotspot/share/gc/z/zNMethod.cpp ! src/hotspot/share/gc/z/zNMethod.hpp ! src/hotspot/share/runtime/thread.hpp Changeset: 17a3f0e2 Author: Coleen Phillimore Date: 2023-01-09 15:01:34 +0000 URL: https://git.openjdk.org/loom/commit/17a3f0e2577f2f9eb3fe62a4b8261e3dbe4c3b28 8299275: Add some ClassLoaderData verification code Reviewed-by: iklam, fparain ! src/hotspot/share/classfile/classLoaderData.cpp ! src/hotspot/share/oops/oop.inline.hpp ! src/hotspot/share/oops/verifyOopClosure.hpp Changeset: bfd59714 Author: Alexandre Iline Date: 2023-01-09 15:39:46 +0000 URL: https://git.openjdk.org/loom/commit/bfd597142945bf87cefe320371b7648d44c6f916 8299757: Update JCov version to 3.0.14 Reviewed-by: erikj, serb ! make/conf/jib-profiles.js Changeset: cd10c727 Author: Justin Lu Committer: Naoto Sato Date: 2023-01-09 17:43:31 +0000 URL: https://git.openjdk.org/loom/commit/cd10c7278d8fcf7ce6713a3ee688bb1e10c024f6 8299500: Usage of constructors of primitive wrapper classes should be avoided in java.text API docs Reviewed-by: naoto, lancea ! src/java.base/share/classes/java/text/ChoiceFormat.java ! src/java.base/share/classes/java/text/MessageFormat.java Changeset: 679e4858 Author: Archie L. Cobbs Committer: Vicente Romero Date: 2023-01-09 18:38:15 +0000 URL: https://git.openjdk.org/loom/commit/679e485838881c1364845072af305fb60d95e60a 8043251: Bogus javac error: required: no arguments, found: no arguments Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties + test/langtools/tools/javac/Diagnostics/8043251/T8043251.java + test/langtools/tools/javac/Diagnostics/8043251/T8043251.out ! test/langtools/tools/javac/diags/examples/ExplicitParamsDoNotConformToBounds.java ! test/langtools/tools/javac/diags/examples/WrongNumberTypeArgsFragment.java Changeset: b8852f65 Author: Justin Lu Committer: Naoto Sato Date: 2023-01-09 21:24:40 +0000 URL: https://git.openjdk.org/loom/commit/b8852f65a0adcb9ee5693bb6727a0668aa9808bf 8299502: Usage of constructors of primitive wrapper classes should be avoided in javax.xml API docs Reviewed-by: joehw, naoto, lancea ! src/java.xml/share/classes/javax/xml/stream/XMLOutputFactory.java Changeset: f36f1354 Author: Justin Lu Committer: Naoto Sato Date: 2023-01-09 21:26:08 +0000 URL: https://git.openjdk.org/loom/commit/f36f1354c63a500c70ae51a9c2b2d21ad55cfa77 8299501: Usage of constructors of primitive wrapper classes should be avoided in java.util API docs Reviewed-by: naoto, lancea ! src/java.base/share/classes/java/util/Arrays.java Changeset: f79b3d42 Author: Justin Lu Committer: Naoto Sato Date: 2023-01-09 22:10:36 +0000 URL: https://git.openjdk.org/loom/commit/f79b3d42f07b703f0e3b9fc67c92dee260b0e602 6381945: (cal) Japanese calendar unit test system should avoid multiple static imports Reviewed-by: lancea, iris, naoto ! test/jdk/java/util/Calendar/CalendarTestScripts/Symbol.java Changeset: d49851a8 Author: Naoto Sato Date: 2023-01-09 18:23:42 +0000 URL: https://git.openjdk.org/loom/commit/d49851a8b8e80b6ffa53c2bb4f5b2897735d471f 8299689: Make use of JLine for Console as "opt-in" Reviewed-by: jpai, alanb ! src/java.base/share/classes/java/io/Console.java ! src/java.base/share/classes/jdk/internal/io/JdkConsoleProvider.java ! test/jdk/java/io/Console/ModuleSelectionTest.java ! test/jdk/java/io/Console/RedirectTest.java Changeset: 4395578b Author: Jesper Wilhelmsson Date: 2023-01-09 23:31:32 +0000 URL: https://git.openjdk.org/loom/commit/4395578b6f0432d158c4b6c0c0a9d0838f74baa8 Merge ! src/java.base/share/classes/java/io/Console.java ! src/java.base/share/classes/java/io/Console.java Changeset: a6386634 Author: David Holmes Date: 2023-01-10 00:45:43 +0000 URL: https://git.openjdk.org/loom/commit/a63866341ee8d169bdf88cf56f5d72168263fa81 8255119: Monitor::wait takes signed integer as timeout Reviewed-by: jsjolen, stuefe, coleenp, gziemski ! src/hotspot/os/posix/mutex_posix.hpp ! src/hotspot/os/posix/os_posix.cpp ! src/hotspot/os/windows/mutex_windows.hpp ! src/hotspot/os/windows/os_windows.cpp ! src/hotspot/share/runtime/mutex.cpp ! src/hotspot/share/runtime/mutex.hpp Changeset: b7eb4e2f Author: Jaikiran Pai Date: 2023-01-10 01:53:48 +0000 URL: https://git.openjdk.org/loom/commit/b7eb4e2ffd3bce12fd960ab8102bfaabf89e8865 8297306: Incorrect brackets in Javadoc for a constructor of IteratorSpliterator Reviewed-by: alanb, iris, naoto ! src/java.base/share/classes/java/util/Spliterators.java Changeset: 3a667370 Author: Yadong Wang Committer: Fei Yang Date: 2023-01-10 02:43:14 +0000 URL: https://git.openjdk.org/loom/commit/3a667370010881ab754f8f8d540ca9e2ce45fe2c 8299525: RISC-V: Add backend support for half float conversion intrinsics Reviewed-by: fyang, fjiang ! src/hotspot/cpu/riscv/assembler_riscv.hpp ! src/hotspot/cpu/riscv/globals_riscv.hpp ! src/hotspot/cpu/riscv/riscv.ad ! src/hotspot/cpu/riscv/vm_version_riscv.cpp Changeset: 195f3137 Author: Hao Sun Committer: Ningsheng Jian Date: 2023-01-10 05:37:02 +0000 URL: https://git.openjdk.org/loom/commit/195f31371f4612a2d9d12a83deb281698ff68bfb 8287925: AArch64: intrinsics for compareUnsigned method in Integer and Long Reviewed-by: adinn, aph ! src/hotspot/cpu/aarch64/aarch64.ad ! test/hotspot/jtreg/compiler/intrinsics/TestCompareUnsigned.java Changeset: f95346e8 Author: Daniel Jeli?ski Date: 2023-01-10 07:11:24 +0000 URL: https://git.openjdk.org/loom/commit/f95346e870d314fdc224aed4e8b9c22159bd89d3 8299261: Clean up AWT D3D exports Reviewed-by: serb, aivanov ! src/java.desktop/windows/native/libawt/java2d/d3d/D3DBlitLoops.cpp ! src/java.desktop/windows/native/libawt/java2d/d3d/D3DBlitLoops.h ! src/java.desktop/windows/native/libawt/java2d/d3d/D3DContext.h ! src/java.desktop/windows/native/libawt/java2d/d3d/D3DPipeline.h ! src/java.desktop/windows/native/libawt/java2d/d3d/D3DPipelineManager.h ! src/java.desktop/windows/native/libawt/java2d/d3d/D3DRenderer.cpp ! src/java.desktop/windows/native/libawt/java2d/d3d/D3DRenderer.h ! src/java.desktop/windows/native/libawt/java2d/d3d/D3DVertexCacher.h Changeset: 5f37cbec Author: Albert Mingkun Yang Date: 2023-01-10 07:52:28 +0000 URL: https://git.openjdk.org/loom/commit/5f37cbec942d081a87fc7ef49a0a3d9c932774fc 8297572: Remove unused PrecisionStyle::Precise Reviewed-by: tschatzl, kbarrett ! src/hotspot/share/gc/shared/cardTable.hpp ! src/hotspot/share/gc/shared/cardTableRS.cpp ! src/hotspot/share/gc/shared/space.cpp ! src/hotspot/share/gc/shared/space.hpp ! src/hotspot/share/gc/shared/vmStructs_gc.hpp Changeset: c8a8388a Author: Sergey Bylokhov Date: 2023-01-10 10:30:34 +0000 URL: https://git.openjdk.org/loom/commit/c8a8388aba3dc121bad04aaa123f6cd7525c3d38 8299789: Compilation of gtest causes build to fail if runtime libraries are in different dirs Reviewed-by: erikj ! make/hotspot/test/GtestImage.gmk Changeset: eab1e626 Author: Richard Reingruber Date: 2023-01-10 10:32:32 +0000 URL: https://git.openjdk.org/loom/commit/eab1e6260d5622722b3e930b8457a64c6da28ccc 8297487: G1 Remark: no need to keep alive oop constants of nmethods on stack Reviewed-by: tschatzl, ayang, eosterlund ! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp ! src/hotspot/share/gc/shared/barrierSet.cpp Changeset: debe5879 Author: Volker Simonis Date: 2023-01-10 11:49:36 +0000 URL: https://git.openjdk.org/loom/commit/debe5879aa7118a114ff6fcf8d15951757ae70a8 8298381: Improve handling of session tickets for multiple SSLContexts Reviewed-by: xuelei, ascarpino, serb ! src/java.base/share/classes/sun/security/ssl/SSLContextImpl.java ! src/java.base/share/classes/sun/security/ssl/SSLSessionContextImpl.java ! src/java.base/share/classes/sun/security/ssl/SessionTicketExtension.java Changeset: d68de02b Author: Albert Mingkun Yang Date: 2023-01-10 14:26:32 +0000 URL: https://git.openjdk.org/loom/commit/d68de02befb8dc099842497cefb23943c506079c 8299845: Remove obsolete comments in DirtyCardToOopClosure::get_actual_top Co-authored-by: Y. Srinivas Ramakrishna Reviewed-by: tschatzl, sjohanss ! src/hotspot/share/gc/shared/space.cpp Changeset: 8b0133f2 Author: Christian Hagedorn Date: 2023-01-10 14:35:46 +0000 URL: https://git.openjdk.org/loom/commit/8b0133f2760f67cd968528c041a600408cc26978 8299259: C2: Div/Mod nodes without zero check could be split through iv phi of loop resulting in SIGFPE Reviewed-by: roland, kvn, thartmann ! src/hotspot/share/opto/loopnode.hpp ! src/hotspot/share/opto/loopopts.cpp + test/hotspot/jtreg/compiler/splitif/TestSplitDivisionThroughPhi.java Changeset: a86b6f6f Author: Mandy Chung Date: 2023-01-10 17:05:33 +0000 URL: https://git.openjdk.org/loom/commit/a86b6f6fde11a1cb27f926c43d53585049fed5e4 8299183: Invokers.checkExactType passes parameters to create WMTE in opposite order Reviewed-by: iris, jpai ! src/java.base/share/classes/java/lang/invoke/Invokers.java ! src/java.base/share/classes/java/lang/invoke/VarHandle.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestExact.java + test/jdk/java/lang/invoke/WrongMethodTypeTest.java Changeset: 5a51ef22 Author: Calvin Cheung Date: 2023-01-10 17:09:52 +0000 URL: https://git.openjdk.org/loom/commit/5a51ef22adb81cf268f7ce395a1af0d40d0d01a7 8297874: get_dump_directory() in jfrEmergencyDump.cpp should pass correct length to jio_snprintf Reviewed-by: mgronlun ! src/hotspot/share/jfr/recorder/repository/jfrEmergencyDump.cpp Changeset: 3c99e786 Author: Alexey Semenyuk Date: 2023-01-10 18:02:34 +0000 URL: https://git.openjdk.org/loom/commit/3c99e786ab4f89448f8d2a6eaf532255a8a560bf 8298735: Some tools/jpackage/windows/* tests fails with jtreg test timeout Reviewed-by: almatvee ! test/jdk/tools/jpackage/windows/WinDirChooserTest.java ! test/jdk/tools/jpackage/windows/WinInstallerIconTest.java ! test/jdk/tools/jpackage/windows/WinInstallerUiTest.java ! test/jdk/tools/jpackage/windows/WinMenuGroupTest.java ! test/jdk/tools/jpackage/windows/WinMenuTest.java ! test/jdk/tools/jpackage/windows/WinPerUserInstallTest.java ! test/jdk/tools/jpackage/windows/WinScriptTest.java ! test/jdk/tools/jpackage/windows/WinShortcutPromptTest.java ! test/jdk/tools/jpackage/windows/WinShortcutTest.java ! test/jdk/tools/jpackage/windows/WinUrlTest.java Changeset: c595f965 Author: Alexey Semenyuk Date: 2023-01-10 18:03:42 +0000 URL: https://git.openjdk.org/loom/commit/c595f965abcf0ea80ace87b8f2180feebbb8984e 8299278: tools/jpackage/share/AddLauncherTest.java#id1 failed AddLauncherTest.bug8230933 Reviewed-by: almatvee ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/Executor.java ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/LauncherIconVerifier.java Changeset: ddca2b9b Author: Kim Barrett Date: 2023-01-11 05:12:26 +0000 URL: https://git.openjdk.org/loom/commit/ddca2b9b46110ecae9f67eab9677e96168f7e9cf 8299701: Remove unused GCCause::_wb_conc_mark Reviewed-by: eosterlund, iwalulya ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1CollectedHeap.hpp ! src/hotspot/share/gc/shared/gcCause.cpp ! src/hotspot/share/gc/shared/gcCause.hpp ! src/hotspot/share/gc/z/zDriver.cpp ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/shared/GCCause.java Changeset: 10a747c7 Author: Justin King Committer: Kim Barrett Date: 2023-01-11 05:31:56 +0000 URL: https://git.openjdk.org/loom/commit/10a747c70bb957b7dd268009e6062771085b97eb 8299479: Remove metaprogramming/decay.hpp Reviewed-by: tschatzl, kbarrett - src/hotspot/share/metaprogramming/decay.hpp ! src/hotspot/share/oops/accessBackend.hpp - test/hotspot/gtest/metaprogramming/test_decay.cpp Changeset: f312c999 Author: Justin King Committer: Kim Barrett Date: 2023-01-11 05:33:29 +0000 URL: https://git.openjdk.org/loom/commit/f312c99977635a0c54600016c0814a64f8aff2ef 8299482: Remove metaprogramming/isIntegral.hpp Reviewed-by: kbarrett, tschatzl - src/hotspot/share/metaprogramming/isIntegral.hpp ! src/hotspot/share/oops/accessBackend.hpp ! src/hotspot/share/runtime/atomic.hpp ! src/hotspot/share/utilities/population_count.hpp - test/hotspot/gtest/metaprogramming/test_isIntegral.cpp Changeset: 95b102c9 Author: Tejesh R Date: 2023-01-11 07:35:30 +0000 URL: https://git.openjdk.org/loom/commit/95b102c9b1e6a46771f4bea0ca2101c05476172d 8299309: Test "java/awt/Dialog/ModalDialogTest/ModalDialogTest.java" fails because new frame was not displayed when "New Frame" button was clicked Reviewed-by: honkar, dnguyen, psadhukhan ! test/jdk/java/awt/Dialog/ModalDialogTest/ModalDialogTest.java Changeset: ef32fdb8 Author: Prasanta Sadhukhan Date: 2023-01-11 08:06:57 +0000 URL: https://git.openjdk.org/loom/commit/ef32fdb8cc9681cf7f1b7a40e3c5a3239491ec75 8284825: sun/java2d/DirectX/MultiPaintEventTest/MultiPaintEventTest.java failed with "RuntimeException: Processed unnecessary paint()." Reviewed-by: serb ! test/jdk/ProblemList.txt Changeset: 030e88d6 Author: Adam Sotona Date: 2023-01-11 08:30:48 +0000 URL: https://git.openjdk.org/loom/commit/030e88d63844f185b839977ff1b19bbc4fe688e8 8299829: In jshell, the output of "0".repeat(49999)+"2" ends with a '0' Reviewed-by: jlahoda ! src/jdk.jshell/share/classes/jdk/jshell/execution/ExecutionControlForwarder.java ! test/langtools/jdk/jshell/ToolFormatTest.java Changeset: 257f667a Author: Adam Sotona Date: 2023-01-11 09:21:28 +0000 URL: https://git.openjdk.org/loom/commit/257f667afb3dfaefb9a5a6916472066257ca0788 8296789: -completion in jshell fails to expose synthetic bridge methods Reviewed-by: jlahoda ! src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysisImpl.java ! test/langtools/jdk/jshell/CompletionSuggestionTest.java Changeset: f857f8a0 Author: Erik ?sterlund Date: 2023-01-11 09:33:05 +0000 URL: https://git.openjdk.org/loom/commit/f857f8a092d12cc11b2d48a6c9d47a70ee04c88e 8299327: Allow super late barrier expansion of store barriers in C2 Reviewed-by: kvn, rcastanedalo ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/ppc/ppc.ad ! src/hotspot/cpu/riscv/riscv.ad ! src/hotspot/cpu/x86/x86_64.ad ! src/hotspot/share/gc/shared/c2/barrierSetC2.hpp ! src/hotspot/share/opto/graphKit.cpp ! src/hotspot/share/opto/graphKit.hpp ! src/hotspot/share/opto/memnode.cpp Changeset: 5a9490a4 Author: Albert Mingkun Yang Date: 2023-01-11 10:07:52 +0000 URL: https://git.openjdk.org/loom/commit/5a9490a40e0fe281fc1b33d2c39a9a970d8a7b4f 8299853: Serial: Use more concrete type for TenuredGeneration::_the_space Reviewed-by: tschatzl, stefank ! src/hotspot/share/gc/serial/tenuredGeneration.cpp ! src/hotspot/share/gc/serial/tenuredGeneration.hpp ! src/hotspot/share/gc/serial/vmStructs_serial.hpp ! src/hotspot/share/gc/shared/cardTableRS.cpp ! src/hotspot/share/gc/shared/cardTableRS.hpp ! test/hotspot/jtreg/serviceability/sa/ClhsdbField.java Changeset: d15285f9 Author: Tobias Hartmann Date: 2023-01-11 12:39:50 +0000 URL: https://git.openjdk.org/loom/commit/d15285f948c5414028790e25b4497d28775eeb54 8299956: [BACKOUT] 8297487: G1 Remark: no need to keep alive oop constants of nmethods on stack Reviewed-by: chagedorn, tschatzl ! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp ! src/hotspot/share/gc/shared/barrierSet.cpp Changeset: 7d3400b1 Author: Per Minborg Date: 2023-01-11 15:08:52 +0000 URL: https://git.openjdk.org/loom/commit/7d3400b1cf6befd28af81113b218d0aae60ac05f 8299864: ZipFileStore#supportsFileAttributeView(String) doesn't throw NPE Reviewed-by: lancea ! src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileStore.java ! test/jdk/jdk/nio/zipfs/ZipFSTester.java Changeset: 4cd87f1b Author: Andrey Turbanov Date: 2023-01-11 15:14:41 +0000 URL: https://git.openjdk.org/loom/commit/4cd87f1bdab759ab7792afdcf644a6c3d21d51df 8299835: (jrtfs) Unnecessary null check in JrtPath.getAttributes Reviewed-by: alanb, lancea ! src/java.base/share/classes/jdk/internal/jrtfs/JrtPath.java Changeset: c7716a01 Author: Naoto Sato Date: 2023-01-11 17:01:48 +0000 URL: https://git.openjdk.org/loom/commit/c7716a0101d337ec75ffdbcc3d18058a03c2373f 8299571: ZoneRulesProvider.registerProvider() can leave inconsistent state on failure Reviewed-by: iris, rriggs, joehw ! src/java.base/share/classes/java/time/zone/ZoneRulesProvider.java + test/jdk/java/time/test/java/time/zone/TestZoneRulesProvider.java Changeset: 437d69a2 Author: Justin Lu Committer: Naoto Sato Date: 2023-01-11 17:14:08 +0000 URL: https://git.openjdk.org/loom/commit/437d69a220a8615f845013e0b495c5b47d945698 8299836: Make `user.timezone` system property searchable Reviewed-by: jpai, naoto ! src/java.base/share/classes/java/util/TimeZone.java Changeset: d663b5da Author: Justin Lu Committer: Naoto Sato Date: 2023-01-11 17:18:39 +0000 URL: https://git.openjdk.org/loom/commit/d663b5da10be1f3f33a2729e4b3605fb5e13b4d6 8299498: Usage of constructors of primitive wrapper classes should be avoided in java.lang API docs Reviewed-by: naoto, darcy, rriggs, mchung, lancea ! src/java.base/share/classes/java/lang/ArrayStoreException.java ! src/java.base/share/classes/java/lang/Byte.java ! 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/Integer.java ! src/java.base/share/classes/java/lang/Long.java ! src/java.base/share/classes/java/lang/Short.java Changeset: 9c1e98da Author: Calvin Cheung Date: 2023-01-11 17:48:36 +0000 URL: https://git.openjdk.org/loom/commit/9c1e98dac54ed2ce169f3f3df05bc80052f6a217 8298321: 2 File Leak defect groups in 2 files Reviewed-by: vlivanov, iklam, dholmes ! src/hotspot/os/posix/perfMemory_posix.cpp ! src/hotspot/share/compiler/directivesParser.cpp Changeset: a17b563f Author: Mikael Vidstedt Date: 2023-01-11 18:26:38 +0000 URL: https://git.openjdk.org/loom/commit/a17b563f54b2e0953a1dd9a613e6d5e0e9a8e4cb 8299918: Update Xcode11.3.1-MacOSX10.15 devkit at Oracle Reviewed-by: erikj ! make/conf/jib-profiles.js Changeset: 43847c43 Author: Matias Saavedra Silva Committer: Coleen Phillimore Date: 2023-01-11 19:13:26 +0000 URL: https://git.openjdk.org/loom/commit/43847c43ad2e84999554468f79016dd33528ec14 8298065: Provide more information in message of NoSuchFieldError Reviewed-by: dholmes, iklam, coleenp ! src/hotspot/share/interpreter/linkResolver.cpp ! src/hotspot/share/oops/symbol.cpp ! src/hotspot/share/oops/symbol.hpp + test/hotspot/jtreg/runtime/linkResolver/NoSuchFieldArray.jasm + test/hotspot/jtreg/runtime/linkResolver/NoSuchFieldMultiArray.jasm + test/hotspot/jtreg/runtime/linkResolver/NoSuchFieldOutputTest.java + test/hotspot/jtreg/runtime/linkResolver/NoSuchFieldPrimitive.jasm + test/hotspot/jtreg/runtime/linkResolver/NoSuchFieldReference.jasm + test/hotspot/jtreg/runtime/linkResolver/TestClass.java Changeset: 8db73f77 Author: Rajan Halade Date: 2023-01-11 21:36:08 +0000 URL: https://git.openjdk.org/loom/commit/8db73f7743014ed4527ba3cd51f58a2dfcf161fe 8300001: ProblemList test java/security/Policy/Root/Root.java Reviewed-by: mikael, dcubed ! test/jdk/ProblemList.txt Changeset: 5826a077 Author: Mikael Vidstedt Date: 2023-01-10 04:39:53 +0000 URL: https://git.openjdk.org/loom/commit/5826a077f9415cab88f90553fbfdeaabb439a53d 8299693: Change to Xcode12.4+1.1 devkit for building on macOS at Oracle Reviewed-by: erikj Backport-of: 4b6809b94a09871712df7a1c51b7192adbe2093b ! make/conf/jib-profiles.js Changeset: 21d468e5 Author: Nick Gasson Date: 2023-01-10 13:29:55 +0000 URL: https://git.openjdk.org/loom/commit/21d468e5751b082edc8db919e378fbb1cc6dc9ad 8299733: AArch64: "unexpected literal addressing mode" assertion failure with -XX:+PrintC1Statistics Co-authored-by: Ningsheng Jian Reviewed-by: chagedorn, fyang, aph ! src/hotspot/cpu/aarch64/assembler_aarch64.hpp ! test/hotspot/jtreg/ProblemList-Xcomp.txt Changeset: 151450ea Author: Patricio Chilano Mateo Date: 2023-01-10 17:16:26 +0000 URL: https://git.openjdk.org/loom/commit/151450ea9b78243130eb89a1c8ea9ad7ac13fb4a 8294744: AArch64: applications/kitchensink/Kitchensink.java crashed: assert(oopDesc::is_oop(obj)) failed: not an oop Co-authored-by: Fei Yang Reviewed-by: aph, fyang, dcubed ! src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp ! src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp Changeset: de79162f Author: Xiaohong Gong Date: 2023-01-11 01:49:56 +0000 URL: https://git.openjdk.org/loom/commit/de79162fdf122236fd518a51fd47aec75daf2948 8299715: IR test: VectorGatherScatterTest.java fails with SVE randomly Reviewed-by: psandoz, thartmann ! test/hotspot/jtreg/compiler/vectorapi/VectorGatherScatterTest.java Changeset: 0abb87a4 Author: Abhishek Kumar Committer: Tejesh R Date: 2023-01-11 07:42:42 +0000 URL: https://git.openjdk.org/loom/commit/0abb87a488e99cdbc418e14411a6bbf7a3f28079 8299227: host `exif.org` not found in link in doc comment Reviewed-by: prr, serb ! src/java.desktop/share/classes/com/sun/imageio/plugins/tiff/TIFFImageWriteParam.java ! src/java.desktop/share/classes/javax/imageio/metadata/doc-files/tiff_metadata.html ! src/java.desktop/share/native/libjavajpeg/imageioJPEG.c Changeset: 636976ad Author: Jan Lahoda Date: 2023-01-11 07:52:18 +0000 URL: https://git.openjdk.org/loom/commit/636976ada8773474a5540234a38667668349b30b 8299849: Revert JDK-8294461: wrong effectively final determination by javac Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java - test/langtools/tools/javac/lambda/8294461/EffectivelyFinalLoopIncrement.java - test/langtools/tools/javac/lambda/8294461/EffectivelyFinalLoopIncrement.out Changeset: 945ef075 Author: Maurizio Cimadamore Date: 2023-01-11 10:31:25 +0000 URL: https://git.openjdk.org/loom/commit/945ef07564bb2e7db9743d07d7d9ac7faa3f3d4d 8299862: OfAddress setter should disallow heap segments Reviewed-by: jvernee ! src/java.base/share/classes/java/lang/foreign/MemorySegment.java ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java ! src/java.base/share/classes/jdk/internal/foreign/Utils.java ! src/java.base/share/classes/jdk/internal/foreign/abi/SharedUtils.java ! test/jdk/java/foreign/TestMemoryAccessInstance.java Changeset: 33f3bd8f Author: Jesper Wilhelmsson Date: 2023-01-11 21:50:42 +0000 URL: https://git.openjdk.org/loom/commit/33f3bd8fadb26a0f99c6a13474f8676639f91c0c Merge ! src/hotspot/cpu/aarch64/assembler_aarch64.hpp ! src/java.desktop/share/classes/com/sun/imageio/plugins/tiff/TIFFImageWriteParam.java ! src/hotspot/cpu/aarch64/assembler_aarch64.hpp ! src/java.desktop/share/classes/com/sun/imageio/plugins/tiff/TIFFImageWriteParam.java From mika.a.moilanen at gmail.com Fri Jan 20 06:22:12 2023 From: mika.a.moilanen at gmail.com (mikmoila) Date: Fri, 20 Jan 2023 08:22:12 +0200 Subject: ConcurrentHashMap::computeIfAbsent and synchronized Message-ID: Hi. As often mentioned in this mailing-list a feedback about preview/incubator features is appreciated, so here's one: I was experimenting with a caching system utilising ConcurrentHashMap as cache store and Structured Concurrency API for refreshing the entries from multiple sources ( StructuredTaskScope.ShutdownOnSuccess ). The idea was to make http-requests for getting the fresh values but the first implementation simply uses UUID::randomUUID for simulating that. I noticed that the programs halts In a test case where "N" concurrent calls (where "N" >= number of cpu cores) running on virtual threads end-up calling the ConcurrentHashMap::computeIfAbsent for the same (non-existing) key. "-Djdk.tracePinnedThreads=full" reveals that there is a pinned carrier thread: java.base/java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1708) <== monitors:1 The documentation ( https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/concurrent/ConcurrentHashMap.html#computeIfAbsent(K,java.util.function.Function) ) says: "Some attempted update operations on this map by other threads may be blocked while computation is in progress, so the computation should be short and simple." This is clear but I still found it as a surprise that it uses synchronized instead of "virtual-thread friendly" constructs. If needed I can post a small demo program. JDK used is latest OpenJDK-19 GA, OS is Windows: openjdk version "19.0.2" 2023-01-17 OpenJDK Runtime Environment (build 19.0.2+7-44) OpenJDK 64-Bit Server VM (build 19.0.2+7-44, mixed mode, sharing) Best Regards, Mika -------------- next part -------------- An HTML attachment was scrubbed... URL: From heinz at javaspecialists.eu Fri Jan 20 07:40:24 2023 From: heinz at javaspecialists.eu (Dr Heinz M. Kabutz) Date: Fri, 20 Jan 2023 09:40:24 +0200 Subject: ConcurrentHashMap::computeIfAbsent and synchronized In-Reply-To: References: Message-ID: <20fdac7a-1a73-dc12-c021-a492f13de2b9@javaspecialists.eu> Hi Mika, I was thinking about that yesterday. Since CHM gives a guarantee that the compute() functions are called atomically, it might be worth looking at the implications of moving (back) to ReentrantLock. However, that would also mean that we need to allocate a lot of ReentrantLock instances, and those are 40 bytes per lock. Here is a demo that shows the issue: import java.util.Map; import java.util.concurrent.CancellationException; import java.util.concurrent.ConcurrentHashMap; public class CHMPinning { public static void main(String... args)throws InterruptedException { Map map =new ConcurrentHashMap<>(); for (int i =0; i <1_000; i++) { int finalI = i; Thread.startVirtualThread(() -> map.computeIfAbsent(finalI %3, key -> { try { Thread.sleep(2_000); }catch (InterruptedException e) { throw new CancellationException("interrupted"); } return finalI; })); } long time = System.nanoTime(); try { Thread.startVirtualThread(() -> System.out.println( "Hi, I'm an innocent virtual thread")) .join(); }finally { time = System.nanoTime() - time; System.out.printf("time = %dms%n", (time /1_000_000)); } System.out.println("map = " + map); } } Output is something like: Hi, I'm an innocent virtual thread time = 2002ms map = {0=0, 1=7, 2=2} IMHO, I would not like to see the CHM memory usage increase by 40 x # nodes bytes to cater for an edge case of the compute() function taking a bit longer. Regards Heinz -- Dr Heinz M. Kabutz (PhD CompSci) Author of "The Java? Specialists' Newsletter" -www.javaspecialists.eu Java Champion -www.javachampions.org JavaOne Rock Star Speaker Tel: +30 69 75 595 262 Skype: kabutz On 2023/01/20 01:22, mikmoila wrote: > Hi. > > As often mentioned in this mailing-list a feedback about > preview/incubator features is appreciated, so here's one: > > I was experimenting with a caching system utilising ConcurrentHashMap > as cache store and Structured Concurrency API for refreshing the > entries from multiple sources ( StructuredTaskScope.ShutdownOnSuccess > ). The idea was to make http-requests for getting the fresh values but > the first implementation simply uses UUID::randomUUID for simulating that. > I noticed that the programs halts In a test case where "N" concurrent > calls (where "N" >= number of cpu cores) running on virtual threads > end-up calling the ConcurrentHashMap::computeIfAbsent for the same > (non-existing) key. > > "-Djdk.tracePinnedThreads=full" reveals that there is a pinned carrier > thread: > java.base/java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1708) > <== monitors:1 > > The documentation ( > https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/concurrent/ConcurrentHashMap.html#computeIfAbsent(K,java.util.function.Function) > ) says: > > ? "Some attempted update operations on this map by other threads may > be blocked while computation is in progress, so the computation should > be short and simple." > > This is clear but I still found it as a surprise that it uses > synchronized instead of "virtual-thread friendly" constructs. > > If needed I can post a small demo program. > > JDK used is latest OpenJDK-19 GA, OS is Windows: > ? openjdk version "19.0.2" 2023-01-17 > ? OpenJDK Runtime Environment (build 19.0.2+7-44) > ? OpenJDK 64-Bit Server VM (build 19.0.2+7-44, mixed mode, sharing) > > Best Regards, > ? Mika -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Fri Jan 20 10:01:36 2023 From: duke at openjdk.org (duke) Date: Fri, 20 Jan 2023 10:01:36 GMT Subject: git: openjdk/loom: fibers: 128 new changesets Message-ID: Changeset: 78b1686c Author: Sergey Bylokhov Date: 2023-01-12 01:52:56 +0000 URL: https://git.openjdk.org/loom/commit/78b1686c150aeaa29c5d969b70c9c42c872246a2 8227257: javax/swing/JFileChooser/4847375/bug4847375.java fails with AssertionError Reviewed-by: aivanov, tr ! src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java ! src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolderManager2.java ! test/jdk/javax/swing/JFileChooser/4847375/bug4847375.java + test/jdk/javax/swing/JFileChooser/FileSystemView/InaccessibleLink.java Changeset: af8d3fb2 Author: Afshin Zafari Committer: Ioi Lam Date: 2023-01-12 01:54:11 +0000 URL: https://git.openjdk.org/loom/commit/af8d3fb21ab59104d49bd664f634399fb72ecbd2 8264684: os::get_summary_cpu_info padded with spaces Reviewed-by: iklam, ccheung ! src/hotspot/os/windows/os_windows.cpp Changeset: d716ec5d Author: Emanuel Peter Date: 2023-01-12 07:23:19 +0000 URL: https://git.openjdk.org/loom/commit/d716ec5d3034240b7dd0aed86d9bb371bc3e5f5a 8299179: ArrayFill with store on backedge needs to reduce length by 1 Reviewed-by: thartmann, kvn ! src/hotspot/share/opto/loopTransform.cpp + test/hotspot/jtreg/compiler/loopopts/TestBackedgeLoadArrayFill.jasm + test/hotspot/jtreg/compiler/loopopts/TestBackedgeLoadArrayFillMain.java Changeset: 0ee8cac7 Author: Matthias Baesken Date: 2023-01-12 08:04:46 +0000 URL: https://git.openjdk.org/loom/commit/0ee8cac7c7b317c780e4a08c2dd6daf36301a3e5 8299672: Enhance HeapDump JFR event Reviewed-by: rschmelter, clanger ! src/hotspot/share/jfr/metadata/metadata.xml ! src/hotspot/share/services/heapDumper.cpp ! test/jdk/jdk/jfr/event/diagnostics/TestHeapDump.java Changeset: 036c8084 Author: Nick Gasson Date: 2023-01-12 09:28:46 +0000 URL: https://git.openjdk.org/loom/commit/036c80844e30559bdced3587bb70b29ee38af498 8298482: Implement ParallelGC NUMAStats for Linux Reviewed-by: ayang, sjohanss, tschatzl ! 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/mutableNUMASpace.hpp ! src/hotspot/share/runtime/os.hpp Changeset: 4b573343 Author: Alan Bateman Date: 2023-01-12 09:38:31 +0000 URL: https://git.openjdk.org/loom/commit/4b573343a6eb05b8b469177935d48c48957aff64 8278326: Socket close is not thread safe and other cleanup Reviewed-by: jpai ! src/java.base/share/classes/java/net/HttpConnectSocketImpl.java ! src/java.base/share/classes/java/net/ServerSocket.java ! src/java.base/share/classes/java/net/Socket.java + test/jdk/java/net/ServerSocket/ImplAccept.java + test/jdk/java/net/Socket/asyncClose/Leaky.java Changeset: 89d3f3d9 Author: Axel Boldt-Christmas Date: 2023-01-12 12:38:13 +0000 URL: https://git.openjdk.org/loom/commit/89d3f3d96b220c249e7b273a09cc3897428f8814 8299125: UnifiedOopRef in JFR leakprofiler should treat thread local oops correctly Reviewed-by: eosterlund, mgronlun ! src/hotspot/share/jfr/leakprofiler/chains/rootSetClosure.cpp ! src/hotspot/share/jfr/leakprofiler/utilities/unifiedOopRef.hpp ! src/hotspot/share/jfr/leakprofiler/utilities/unifiedOopRef.inline.hpp ! src/hotspot/share/oops/accessBackend.hpp Changeset: 48c8fb39 Author: Claes Redestad Date: 2023-01-12 13:39:59 +0000 URL: https://git.openjdk.org/loom/commit/48c8fb39a74f07335d366a0a3052e3c00634d869 8299978: Remove MethodHandleNatives.getMembers Reviewed-by: jvernee, mchung ! src/hotspot/share/classfile/javaClasses.hpp ! src/hotspot/share/prims/methodHandles.cpp ! src/hotspot/share/prims/methodHandles.hpp ! src/java.base/share/classes/java/lang/invoke/MethodHandleNatives.java Changeset: cf00d09c Author: Julian Waters Date: 2023-01-12 14:32:14 +0000 URL: https://git.openjdk.org/loom/commit/cf00d09c8c37ee301e1c6657df45777647a834e9 8299330: Minor improvements in MSYS2 Workflow handling Reviewed-by: clanger, ihse ! .github/actions/get-msys2/action.yml ! .github/workflows/build-windows.yml Changeset: 26890d19 Author: Julian Waters Date: 2023-01-12 15:01:59 +0000 URL: https://git.openjdk.org/loom/commit/26890d19096a9af95df05105e7e2972068af3742 8296478: Rework 8282948 and 8282700 to use the new autoconf UTIL_ARG_WITH Reviewed-by: erikj, ihse ! make/autoconf/jdk-options.m4 ! make/autoconf/jdk-version.m4 ! make/autoconf/util.m4 Changeset: 7a85d95e Author: Justin King Committer: Magnus Ihse Bursie Date: 2023-01-12 15:50:05 +0000 URL: https://git.openjdk.org/loom/commit/7a85d95e828283d57e1df0344be454626470675d 8298448: UndefinedBehaviorSanitizer Reviewed-by: erikj, ihse ! make/autoconf/configure.ac ! make/autoconf/jdk-options.m4 ! make/autoconf/spec.gmk.in ! make/common/NativeCompilation.gmk + make/data/ubsan/ubsan_default_options.c = make/data/ubsan/ubsan_default_options.cpp Changeset: 33412c10 Author: Raffaello Giulietti Date: 2023-01-12 19:21:09 +0000 URL: https://git.openjdk.org/loom/commit/33412c102ce799ff2de3512df77e6e07d76acd36 8299677: Formatter.format might take a long time to format an integer or floating-point Reviewed-by: alanb, stsypanov, darcy ! src/java.base/share/classes/java/util/Formatter.java + test/jdk/java/util/Formatter/Padding.java Changeset: 3918f9f5 Author: Jorn Vernee Date: 2023-01-12 06:49:27 +0000 URL: https://git.openjdk.org/loom/commit/3918f9f523521e77bd3820be28d79a4c1d02903c 8299090: Specify coordinate order for additional CaptureCallState parameters on class as well Reviewed-by: pminborg, mcimadamore ! src/java.base/share/classes/java/lang/foreign/Linker.java Changeset: 752a3701 Author: Christoph Langer Date: 2023-01-12 08:02:58 +0000 URL: https://git.openjdk.org/loom/commit/752a37016f49ef8f2405dd74f96f58f80d606cd3 8299439: java/text/Format/NumberFormat/CurrencyFormat.java fails for hr_HR Reviewed-by: naoto Backport-of: 3b374c0153950ab193f3a188b57d3404b4ce2fe2 ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_hr_HR.properties ! test/jdk/ProblemList.txt ! test/jdk/java/text/Format/NumberFormat/CurrencySymbols.properties Changeset: 6a4a8743 Author: Roger Riggs Date: 2023-01-12 14:54:39 +0000 URL: https://git.openjdk.org/loom/commit/6a4a8743562bd8f937542cdeb6557b3fe60e9a23 8299034: Runtime::exec clarification of inherited environment Reviewed-by: alanb ! src/java.base/share/classes/java/lang/ProcessBuilder.java ! src/java.base/share/classes/java/lang/Runtime.java Changeset: 4b92fb0c Author: Mikael Vidstedt Date: 2023-01-12 18:47:08 +0000 URL: https://git.openjdk.org/loom/commit/4b92fb0c6bc82e37e5fb20c72c3ff701070be6dd 8299918: Update Xcode11.3.1-MacOSX10.15 devkit at Oracle Reviewed-by: erikj Backport-of: a17b563f54b2e0953a1dd9a613e6d5e0e9a8e4cb ! make/conf/jib-profiles.js Changeset: 98870472 Author: Jesper Wilhelmsson Date: 2023-01-12 22:24:19 +0000 URL: https://git.openjdk.org/loom/commit/98870472282a76be14acb2dfba483c97359dabba Merge Changeset: 19628e3e Author: Justin King Committer: Magnus Ihse Bursie Date: 2023-01-13 04:07:42 +0000 URL: https://git.openjdk.org/loom/commit/19628e3e0c5d24341cacf60b126070195c77216a 8300068: UBSan CFLAGS/LDFLAGS not passed when building ADLC Reviewed-by: ihse ! make/autoconf/jdk-options.m4 ! make/autoconf/spec.gmk.in ! make/hotspot/gensrc/GensrcAdlc.gmk Changeset: 640eff64 Author: Tobias Hartmann Date: 2023-01-13 07:16:53 +0000 URL: https://git.openjdk.org/loom/commit/640eff64d296cc34b7b3fd50dc7075ffe23a642f 8300040: TypeOopPtr::make_from_klass_common calls itself with args in wrong order Co-authored-by: David Simms Reviewed-by: chagedorn, kvn ! src/hotspot/share/opto/type.cpp Changeset: be8e6d05 Author: Matthias Baesken Date: 2023-01-13 07:57:38 +0000 URL: https://git.openjdk.org/loom/commit/be8e6d05db2f623626506e64a2fb7caf755d5d06 8299957: Enhance error logging in instrument coding with additional jplis_assert_msg Reviewed-by: sspitsyn ! src/java.instrument/share/native/libinstrument/InvocationAdapter.c ! src/java.instrument/share/native/libinstrument/JPLISAgent.c Changeset: ac63f5f8 Author: Markus Gr?nlund Date: 2023-01-13 12:11:09 +0000 URL: https://git.openjdk.org/loom/commit/ac63f5f8dd02b6af59c065add63ab4002fbc3e24 8297877: Risk for uninitialized memory in case of CHECK macro early return as part of field access Reviewed-by: ccheung, egahlin ! src/hotspot/share/jfr/jni/jfrJavaSupport.cpp ! src/hotspot/share/jfr/jni/jfrJavaSupport.hpp ! src/hotspot/share/jfr/recorder/repository/jfrChunkRotation.cpp Changeset: c2502228 Author: Stefan Karlsson Date: 2023-01-13 12:28:52 +0000 URL: https://git.openjdk.org/loom/commit/c250222880b815873f1b24119c58f9f9b50946a9 8300110: Unproblemlist Fuzz.java from ProblemList-zgc.txt Reviewed-by: aboldtch, tschatzl ! test/jdk/ProblemList-zgc.txt Changeset: e7fa150b Author: Erik ?sterlund Date: 2023-01-13 12:48:30 +0000 URL: https://git.openjdk.org/loom/commit/e7fa150bc15b1bf5ab8921bfdf1a628ae08f5624 8299032: Interface IN_NATIVE oop stores for C2 Reviewed-by: stefank, rcastanedalo ! src/hotspot/share/gc/shared/c2/barrierSetC2.cpp ! src/hotspot/share/opto/library_call.cpp Changeset: 3ffc9557 Author: Jie Fu Date: 2023-01-13 13:53:22 +0000 URL: https://git.openjdk.org/loom/commit/3ffc955783e56ed66a931f13c2688311596224e4 8300099: Configuration fails to auto-detect build user through $USER in dockers Reviewed-by: ihse ! make/autoconf/basic_tools.m4 ! make/autoconf/jdk-version.m4 Changeset: ce1193a1 Author: Per Minborg Date: 2023-01-13 15:19:12 +0000 URL: https://git.openjdk.org/loom/commit/ce1193a1edb3cdf20f9448ccbbfb053c2418074a 8299976: Initialize static fields in Net eagerly Reviewed-by: alanb ! src/java.base/share/classes/sun/nio/ch/Net.java Changeset: d1179795 Author: Albert Mingkun Yang Date: 2023-01-13 16:49:26 +0000 URL: https://git.openjdk.org/loom/commit/d1179795031ec1429850e2f835fc2abf173ac35a 8300054: Use static_assert in basic_types_init Reviewed-by: stefank, kbarrett ! src/hotspot/share/utilities/globalDefinitions.cpp Changeset: 4ec36598 Author: Eirik Bjorsnos Committer: Weijun Wang Date: 2023-01-13 17:55:07 +0000 URL: https://git.openjdk.org/loom/commit/4ec3659845486ee9f9227cdfb3f8b47f19462b19 8278349: JarSigner javadoc example uses SHA-1 Reviewed-by: weijun ! src/jdk.jartool/share/classes/jdk/security/jarsigner/JarSigner.java Changeset: 500b45e1 Author: Justin Lu Committer: Naoto Sato Date: 2023-01-13 18:13:50 +0000 URL: https://git.openjdk.org/loom/commit/500b45e12dccc254e2d1cbd9513653ae939ef349 8299865: Unnecessary NullPointerException catch in java.util.TimeZone#setDefaultZone Reviewed-by: lancea, iris, naoto, aturbanov ! src/java.base/share/classes/java/util/TimeZone.java Changeset: 8cb25d3d Author: Artem Semenov Date: 2023-01-13 19:39:56 +0000 URL: https://git.openjdk.org/loom/commit/8cb25d3de494c6d9357a1c199e1a9dbff9be9948 8298644: JNI call of getCurrentComponent on a wrong thread Reviewed-by: avu, serb, kizune ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CAccessibility.java ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/OutlineRowAccessibility.m ! src/java.desktop/share/classes/javax/swing/JTree.java ! src/java.desktop/share/classes/sun/swing/SwingAccessor.java Changeset: f4e119d5 Author: Chris Plummer Date: 2023-01-13 23:25:25 +0000 URL: https://git.openjdk.org/loom/commit/f4e119d5fcdf592f59a7d029070eba3878e24a7c 8300012: Remove unused JDI VirtualMachineImpl.removeObjectMirror(ObjectReferenceImpl object) method Reviewed-by: alanb, sspitsyn ! src/jdk.jdi/share/classes/com/sun/tools/jdi/VirtualMachineImpl.java Changeset: e0081462 Author: Gerard Ziemski Date: 2023-01-13 15:38:49 +0000 URL: https://git.openjdk.org/loom/commit/e0081462f456138b818a596099e2598cbe1648e0 8300055: [BACKOUT] OPEN_MAX is no longer the max limit on macOS >= 10.6 for RLIMIT_NOFILE Reviewed-by: tschatzl, rriggs ! src/hotspot/os/bsd/os_bsd.cpp Changeset: bc498f87 Author: Daniel D. Daugherty Date: 2023-01-13 22:55:08 +0000 URL: https://git.openjdk.org/loom/commit/bc498f87f7037c37ad9c2a101fee5e39ae6bfda1 8300141: ProblemList java/util/concurrent/locks/Lock/OOMEInAQS.java with ZGC 8300144: ProblemList vmTestbase/nsk/sysdict/vm/stress/chain/chain007/chain007.java with ZGC 8300147: ProblemList vmTestbase/nsk/jvmti/SetFieldModificationWatch/setfmodw001/TestDescription.java in Xcomp Reviewed-by: mikael ! test/hotspot/jtreg/ProblemList-Xcomp.txt ! test/hotspot/jtreg/ProblemList-zgc.txt ! test/jdk/ProblemList-zgc.txt Changeset: ab7f43f0 Author: Justin Lu Committer: Naoto Sato Date: 2023-01-13 23:14:14 +0000 URL: https://git.openjdk.org/loom/commit/ab7f43f0801eeb6b0514f5e8241404c13c04269d 8299498: Usage of constructors of primitive wrapper classes should be avoided in java.lang API docs Backport-of: d663b5da10be1f3f33a2729e4b3605fb5e13b4d6 ! src/java.base/share/classes/java/lang/ArrayStoreException.java ! src/java.base/share/classes/java/lang/Byte.java ! 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/Integer.java ! src/java.base/share/classes/java/lang/Long.java ! src/java.base/share/classes/java/lang/Short.java Changeset: 628266af Author: Justin Lu Committer: Naoto Sato Date: 2023-01-13 23:15:28 +0000 URL: https://git.openjdk.org/loom/commit/628266af60b054903fccd1582972acb2c998f1d4 8299501: Usage of constructors of primitive wrapper classes should be avoided in java.util API docs Backport-of: f36f1354c63a500c70ae51a9c2b2d21ad55cfa77 ! src/java.base/share/classes/java/util/Arrays.java Changeset: 98eae6da Author: Justin Lu Committer: Naoto Sato Date: 2023-01-13 23:16:48 +0000 URL: https://git.openjdk.org/loom/commit/98eae6dade075c6e58ad0379d0b3b38b75836994 8299500: Usage of constructors of primitive wrapper classes should be avoided in java.text API docs Reviewed-by: iris Backport-of: cd10c7278d8fcf7ce6713a3ee688bb1e10c024f6 ! src/java.base/share/classes/java/text/ChoiceFormat.java ! src/java.base/share/classes/java/text/MessageFormat.java Changeset: dc5cc616 Author: Justin Lu Committer: Naoto Sato Date: 2023-01-13 23:17:53 +0000 URL: https://git.openjdk.org/loom/commit/dc5cc61621ec6ad23e6107737b46276171d90622 8299499: Usage of constructors of primitive wrapper classes should be avoided in java.net API docs Backport-of: 63cf4aa0c897406fc9370a8e05cb035caafc5d69 ! src/java.base/share/classes/java/net/SocketOptions.java Changeset: 87865e0e Author: Justin Lu Committer: Naoto Sato Date: 2023-01-13 23:19:02 +0000 URL: https://git.openjdk.org/loom/commit/87865e0eb8af6a23263494f3397ee01c7eccb1b8 8299502: Usage of constructors of primitive wrapper classes should be avoided in javax.xml API docs Backport-of: b8852f65a0adcb9ee5693bb6727a0668aa9808bf ! src/java.xml/share/classes/javax/xml/stream/XMLOutputFactory.java Changeset: 4be94e43 Author: Jesper Wilhelmsson Date: 2023-01-14 01:57:13 +0000 URL: https://git.openjdk.org/loom/commit/4be94e435002d9d6cb594a393e9e35d650a9a0c9 Merge ! src/hotspot/os/bsd/os_bsd.cpp ! test/hotspot/jtreg/ProblemList-zgc.txt ! src/hotspot/os/bsd/os_bsd.cpp ! test/hotspot/jtreg/ProblemList-zgc.txt Changeset: 7bcd5f41 Author: Ioi Lam Date: 2023-01-15 20:30:31 +0000 URL: https://git.openjdk.org/loom/commit/7bcd5f418c399678e9459dc376c3ef061493b33f 8297914: Remove java_lang_Class::process_archived_mirror() Reviewed-by: ccheung ! src/hotspot/share/cds/heapShared.cpp ! src/hotspot/share/cds/heapShared.hpp ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/classfile/javaClasses.hpp ! src/hotspot/share/memory/universe.cpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/klass.cpp ! src/hotspot/share/oops/klass.hpp ! src/hotspot/share/runtime/mutexLocker.cpp ! src/hotspot/share/runtime/mutexLocker.hpp Changeset: 12edd6f9 Author: Julian Waters Date: 2023-01-16 06:07:38 +0000 URL: https://git.openjdk.org/loom/commit/12edd6f922195f193659814d6c37c361c83e6797 8300052: PdhDll::PdhCollectQueryData and PdhLookupPerfNameByIndex will never be NULL Reviewed-by: dholmes ! src/hotspot/os/windows/pdh_interface.cpp Changeset: fe7fca01 Author: Daniel Jeli?ski Date: 2023-01-16 06:56:43 +0000 URL: https://git.openjdk.org/loom/commit/fe7fca0128ca3a7b514c49d1508ca64499a8bb8e 8300032: DwarfParser resource leak Reviewed-by: cjplummer, sspitsyn ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/linux/amd64/DwarfParser.java Changeset: 50e7df91 Author: Daniel Jeli?ski Date: 2023-01-16 06:58:27 +0000 URL: https://git.openjdk.org/loom/commit/50e7df91c77d436937fff9134174ddb8a8dd4dd7 8300024: Replace use of JNI_COMMIT mode with mode 0 Reviewed-by: amenkov, sspitsyn, cjplummer ! src/jdk.hotspot.agent/linux/native/libsaproc/LinuxDebuggerLocal.cpp ! src/jdk.hotspot.agent/macosx/native/libsaproc/MacosxDebuggerLocal.m ! src/jdk.hotspot.agent/windows/native/libsaproc/sawindbg.cpp ! test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRetransform/libRedefineRetransform.cpp Changeset: 83f2c9a2 Author: Damon Fenacci Committer: Tobias Hartmann Date: 2023-01-16 07:34:11 +0000 URL: https://git.openjdk.org/loom/commit/83f2c9a2b290f11fbfb118a22c9667f26ac7c516 8293410: Remove GenerateRangeChecks flag Reviewed-by: thartmann, chagedorn, kvn ! src/hotspot/share/c1/c1_LIRGenerator.cpp ! src/hotspot/share/opto/parse2.cpp ! src/hotspot/share/runtime/globals.hpp Changeset: abfd7e89 Author: Aleksey Shipilev Date: 2023-01-16 08:49:02 +0000 URL: https://git.openjdk.org/loom/commit/abfd7e89f6ee03cdadf0adecd28c2672cf77d184 8300113: C2: Single-bit fields with signed type in TypePtr after JDK-8297933 Reviewed-by: roland, thartmann ! src/hotspot/share/opto/type.hpp Changeset: 7c1ebcc4 Author: Emanuel Peter Date: 2023-01-16 09:15:31 +0000 URL: https://git.openjdk.org/loom/commit/7c1ebcc4ce74bb06f7c911e59a86bcfb5c5da844 8299962: Speed up compiler/intrinsics/unsafe/DirectByteBufferTest.java and HeapByteBufferTest.java Reviewed-by: kvn, thartmann ! test/hotspot/jtreg/compiler/intrinsics/unsafe/DirectByteBufferTest.java ! test/hotspot/jtreg/compiler/intrinsics/unsafe/HeapByteBufferTest.java Changeset: 6fea233e Author: Emanuel Peter Date: 2023-01-16 09:17:31 +0000 URL: https://git.openjdk.org/loom/commit/6fea233e229188c193c03f7164104ed5f377ed0e 8299960: Speed up test/hotspot/jtreg/compiler/c2/irTests/TestVectorizeURShiftSubword.java Reviewed-by: thartmann, chagedorn, fgao ! test/hotspot/jtreg/compiler/c2/irTests/TestVectorizeURShiftSubword.java Changeset: cac72a60 Author: Aleksey Shipilev Date: 2023-01-16 09:32:04 +0000 URL: https://git.openjdk.org/loom/commit/cac72a60181d3570562f8534c691528d06e40cb8 8300053: Shenandoah: Handle more GCCauses in ShenandoahControlThread::request_gc Reviewed-by: wkemper, rkennke ! src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp Changeset: 98d75f18 Author: Bhavana Kilambi Committer: Nick Gasson Date: 2023-01-16 10:47:38 +0000 URL: https://git.openjdk.org/loom/commit/98d75f1879269ff337c28f8cb916212d417e2769 8299038: Add AArch64 backend support for auto-vectorized FP16 conversions Reviewed-by: xgong, ngasson ! src/hotspot/cpu/aarch64/aarch64_vector.ad ! src/hotspot/cpu/aarch64/aarch64_vector_ad.m4 ! src/hotspot/cpu/aarch64/assembler_aarch64.hpp ! test/hotspot/gtest/aarch64/aarch64-asmtest.py ! test/hotspot/gtest/aarch64/asmtest.out.h ! test/hotspot/jtreg/compiler/vectorization/TestFloatConversionsVector.java Changeset: a7342853 Author: Erik ?sterlund Date: 2023-01-16 10:54:10 +0000 URL: https://git.openjdk.org/loom/commit/a734285314a34ed61583132f2fc6be9d9c861af4 8299879: CollectedHeap hierarchy should use override Reviewed-by: stefank, tschatzl ! src/hotspot/share/gc/epsilon/epsilonHeap.hpp ! src/hotspot/share/gc/parallel/parallelScavengeHeap.hpp ! src/hotspot/share/gc/serial/serialHeap.hpp ! src/hotspot/share/gc/shared/genCollectedHeap.hpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp ! src/hotspot/share/gc/z/zCollectedHeap.hpp Changeset: a2f67660 Author: Manukumar V S Committer: Alexey Ivanov Date: 2023-01-16 12:18:51 +0000 URL: https://git.openjdk.org/loom/commit/a2f67660f088559ce49f73da7401801fb826028b 8288415: java/awt/PopupMenu/PopupMenuLocation.java is unstable in MacOS machines Reviewed-by: dnguyen, aivanov ! test/jdk/java/awt/PopupMenu/PopupMenuLocation.java Changeset: 289aed46 Author: Afshin Zafari Committer: Robbin Ehn Date: 2023-01-16 12:36:45 +0000 URL: https://git.openjdk.org/loom/commit/289aed465e9b8449938d4cdb515748e7aca1d070 8298128: runtime/ErrorHandling/TestSigInfoInHsErrFile.java fails to find pattern with slowdebug Reviewed-by: dcubed, dholmes, stuefe ! src/hotspot/share/utilities/vmError.cpp ! test/hotspot/jtreg/runtime/ErrorHandling/HsErrFileUtils.java Changeset: 319de6a6 Author: Albert Mingkun Yang Date: 2023-01-16 14:25:35 +0000 URL: https://git.openjdk.org/loom/commit/319de6a6d3c559419056a6148e0aab07ab6b43bc 8300124: Remove unnecessary assert in GenCollectedHeap::initialize Reviewed-by: stefank, tschatzl ! src/hotspot/share/gc/shared/genCollectedHeap.cpp Changeset: 506c8186 Author: Leo Korinth Date: 2023-01-16 16:36:36 +0000 URL: https://git.openjdk.org/loom/commit/506c81868997cdea656fb480ebe18d49ab0e075e 8296401: ConcurrentHashTable::bulk_delete might miss to delete some objects Reviewed-by: rehn, iwalulya, aboldtch ! src/hotspot/share/utilities/concurrentHashTable.hpp ! src/hotspot/share/utilities/concurrentHashTable.inline.hpp ! test/hotspot/gtest/utilities/test_concurrentHashtable.cpp Changeset: 4073b685 Author: Magnus Ihse Bursie Date: 2023-01-16 18:53:54 +0000 URL: https://git.openjdk.org/loom/commit/4073b68565f9d5283be96ee6b75bab686f076bea 8298047: Remove all non-significant trailing whitespace from properties files Reviewed-by: serb, rriggs ! src/demo/share/jfc/SwingSet2/resources/swingset.properties ! src/demo/share/jfc/SwingSet2/resources/swingset_de.properties ! src/demo/share/jfc/SwingSet2/resources/swingset_ja.properties ! src/demo/share/jfc/SwingSet2/resources/swingset_zh_CN.properties ! src/java.base/share/classes/sun/util/resources/CurrencyNames_en_US.properties ! src/java.datatransfer/macosx/classes/sun/datatransfer/resources/flavormap.properties ! src/java.datatransfer/unix/classes/sun/datatransfer/resources/flavormap.properties ! src/java.desktop/share/classes/com/sun/accessibility/internal/resources/accessibility.properties ! src/java.desktop/share/classes/com/sun/accessibility/internal/resources/accessibility_de.properties ! src/java.desktop/share/classes/com/sun/accessibility/internal/resources/accessibility_en.properties ! src/java.desktop/share/classes/com/sun/accessibility/internal/resources/accessibility_es.properties ! src/java.desktop/share/classes/com/sun/accessibility/internal/resources/accessibility_fr.properties ! src/java.desktop/share/classes/com/sun/accessibility/internal/resources/accessibility_it.properties ! src/java.desktop/share/classes/com/sun/accessibility/internal/resources/accessibility_ja.properties ! src/java.desktop/share/classes/com/sun/accessibility/internal/resources/accessibility_ko.properties ! src/java.desktop/share/classes/com/sun/accessibility/internal/resources/accessibility_pt_BR.properties ! src/java.desktop/share/classes/com/sun/accessibility/internal/resources/accessibility_sv.properties ! src/java.desktop/share/classes/com/sun/accessibility/internal/resources/accessibility_zh_CN.properties ! src/java.desktop/share/classes/com/sun/accessibility/internal/resources/accessibility_zh_TW.properties ! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/resources/motif.properties ! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/resources/motif_de.properties ! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/resources/motif_es.properties ! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/resources/motif_fr.properties ! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/resources/motif_it.properties ! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/resources/motif_ja.properties ! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/resources/motif_ko.properties ! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/resources/motif_pt_BR.properties ! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/resources/motif_sv.properties ! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/resources/motif_zh_CN.properties ! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/resources/motif_zh_TW.properties ! src/java.desktop/share/classes/sun/print/resources/serviceui.properties ! src/java.desktop/share/classes/sun/print/resources/serviceui_de.properties ! src/java.desktop/share/classes/sun/print/resources/serviceui_es.properties ! src/java.desktop/share/classes/sun/print/resources/serviceui_fr.properties ! src/java.desktop/share/classes/sun/print/resources/serviceui_it.properties ! src/java.desktop/share/classes/sun/print/resources/serviceui_ja.properties ! src/java.desktop/share/classes/sun/print/resources/serviceui_ko.properties ! src/java.desktop/share/classes/sun/print/resources/serviceui_pt_BR.properties ! src/java.desktop/share/classes/sun/print/resources/serviceui_sv.properties ! src/java.desktop/share/classes/sun/print/resources/serviceui_zh_CN.properties ! src/java.desktop/share/classes/sun/print/resources/serviceui_zh_TW.properties ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/resources/windows.properties ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/resources/windows_de.properties ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/resources/windows_es.properties ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/resources/windows_fr.properties ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/resources/windows_it.properties ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/resources/windows_ja.properties ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/resources/windows_ko.properties ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/resources/windows_pt_BR.properties ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/resources/windows_sv.properties ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/resources/windows_zh_CN.properties ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/resources/windows_zh_TW.properties ! src/java.desktop/windows/data/fontconfig/fontconfig.properties ! src/java.naming/share/classes/com/sun/jndi/ldap/jndiprovider.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_de.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_es.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_fr.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_it.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_ja.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_ko.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_pt_BR.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_sv.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_zh_CN.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_zh_TW.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_de.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_es.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_fr.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_it.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_ja.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_ko.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_pt_BR.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_sv.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_zh_CN.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_zh_TW.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_de.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_es.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_fr.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_it.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_ja.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_ko.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_pt_BR.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_sv.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_zh_CN.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_zh_TW.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CalendarData_el_CY.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CalendarData_en_MT.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CalendarData_es_US.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CalendarData_id_ID.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CalendarData_ms_MY.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CalendarData_mt.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CalendarData_mt_MT.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CalendarData_sr.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CalendarData_tr.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CalendarData_uk.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CalendarData_vi.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CalendarData_zh.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_ar_AE.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_ar_BH.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_ar_DZ.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_ar_EG.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_ar_IQ.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_ar_JO.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_ar_KW.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_ar_LB.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_ar_LY.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_ar_MA.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_ar_OM.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_ar_QA.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_ar_SA.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_ar_SD.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_ar_SY.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_ar_TN.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_ar_YE.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_be_BY.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_bg_BG.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_ca_ES.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_cs_CZ.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_da_DK.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_de_AT.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_de_CH.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_de_DE.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_de_LU.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_el_CY.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_el_GR.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_en_AU.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_en_CA.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_en_GB.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_en_IE.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_en_IN.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_en_MT.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_en_NZ.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_en_PH.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_en_SG.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_en_ZA.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_es_AR.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_es_BO.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_es_CL.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_es_CO.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_es_CR.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_es_DO.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_es_EC.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_es_ES.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_es_GT.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_es_HN.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_es_MX.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_es_NI.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_es_PA.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_es_PR.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_es_PY.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_es_SV.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_es_US.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_es_UY.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_es_VE.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_fi_FI.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_fr_BE.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_fr_CA.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_fr_CH.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_fr_FR.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_fr_LU.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_ga_IE.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_he_IL.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_hi_IN.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_hr_HR.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_hu_HU.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_id_ID.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_is_IS.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_it_CH.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_it_IT.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_ja_JP.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_ko_KR.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_lt_LT.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_lv_LV.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_mk_MK.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_ms_MY.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_mt_MT.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_nl_BE.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_nl_NL.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_no_NO.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_pl_PL.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_pt_BR.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_pt_PT.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_ro_RO.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_ru_RU.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_sl_SI.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_sq_AL.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_sr_BA.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_sr_CS.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_sr_ME.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_sv_SE.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_th_TH.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_tr_TR.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_uk_UA.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_vi_VN.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_el.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_el_CY.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_en_MT.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_en_PH.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_en_SG.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_es_US.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_ga.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_id.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_ms.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_mt.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_pt.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_pt_BR.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_pt_PT.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_sr.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_th.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_zh_SG.properties ! test/jdk/java/util/PluggableLocale/providersrc/barprovider/com/bar/LocaleNames.properties ! test/jdk/java/util/PluggableLocale/providersrc/barprovider/com/bar/LocaleNames_ja.properties ! test/jdk/java/util/PluggableLocale/providersrc/barprovider/com/bar/LocaleNames_ja_JP_kyoto.properties ! test/jdk/java/util/PluggableLocale/providersrc/barprovider/com/bar/LocaleNames_ja_JP_osaka.properties ! test/jdk/java/util/PluggableLocale/providersrc/barprovider/com/bar/LocaleNames_xx.properties ! test/jdk/java/util/Properties/Bug6609431.properties ! test/jdk/java/util/ResourceBundle/Bug4083270Test.properties ! test/jdk/java/util/ResourceBundle/Bug4177489_Resource_jf_JF.properties ! test/jdk/java/util/ResourceBundle/Bug6190861Data.properties ! test/jdk/java/util/ResourceBundle/Bug6190861Data_en_US.properties ! test/jdk/java/util/ResourceBundle/Bug6204853.properties ! test/jdk/java/util/ResourceBundle/Bug6204853_Utf8.properties ! test/jdk/java/util/ResourceBundle/Bug6356571.properties ! test/jdk/java/util/ResourceBundle/Control/Bug6530694_de_DE.properties ! test/jdk/java/util/ResourceBundle/Control/Chinese.properties ! test/jdk/java/util/ResourceBundle/Control/Chinese_zh.properties ! test/jdk/java/util/ResourceBundle/Control/Chinese_zh_CN.properties ! test/jdk/java/util/ResourceBundle/Control/Chinese_zh_TW.properties ! test/jdk/java/util/ResourceBundle/Control/MalformedDataRB_en.properties ! test/jdk/java/util/ResourceBundle/Control/StressOut.properties ! test/jdk/java/util/ResourceBundle/Control/StressOut_en_CA.properties ! test/jdk/java/util/ResourceBundle/Control/StressOut_ja.properties ! test/jdk/java/util/ResourceBundle/Control/StressOut_ja_JP.properties ! test/jdk/java/util/ResourceBundle/Control/StressOut_ko.properties ! test/jdk/java/util/ResourceBundle/Control/StressOut_zh_CN.properties ! test/jdk/java/util/ResourceBundle/KeySetResources.properties ! test/jdk/java/util/ResourceBundle/KeySetResources_ja_JP.properties ! test/jdk/java/util/ResourceBundle/RB4353454_en.properties ! test/jdk/java/util/ResourceBundle/ReferencesTestBundle.properties ! test/jdk/java/util/ResourceBundle/Test4314141A.properties ! test/jdk/java/util/ResourceBundle/Test4314141A_.properties ! test/jdk/java/util/ResourceBundle/Test4314141A__DE.properties ! test/jdk/java/util/ResourceBundle/Test4314141A___EURO.properties ! test/jdk/java/util/ResourceBundle/Test4314141A_de.properties ! test/jdk/java/util/ResourceBundle/Test4314141A_de_.properties ! test/jdk/java/util/ResourceBundle/Test4314141B_en.properties ! test/jdk/java/util/ResourceBundle/Test4314141B_fr.properties ! test/jdk/java/util/ResourceBundle/Test4314141B_fr_CH.properties ! test/jdk/java/util/ResourceBundle/Test4318520RB_de.properties ! test/jdk/java/util/ResourceBundle/Test4318520RB_en.properties ! test/jdk/java/util/ResourceBundle/bug4195978Test.properties ! test/jdk/java/util/logging/bundlesearch/ClassPathTestBundle_en.properties ! test/jdk/java/util/logging/bundlesearch/resources/CallerSearchableResource_en.properties ! test/jdk/java/util/logging/bundlesearch/resources/ContextClassLoaderTestBundle_en.properties ! test/jdk/java/util/logging/bundlesearch/resources/StackSearchableResource_en.properties ! test/jdk/java/util/logging/modules/LogManagerInModule/logging.properties ! test/jdk/java/util/spi/ResourceBundleControlProvider/simple.properties ! test/jdk/javax/management/remote/mandatory/connection/mgmt1.properties ! test/jdk/javax/management/remote/mandatory/connection/mgmt2.properties ! test/jdk/sanity/client/TEST.properties ! test/jdk/sanity/client/lib/SwingSet2/src/resources/swingset.properties ! test/jdk/sun/management/LoggingTest/logging.properties Changeset: 4c1e66e0 Author: Justin King Committer: Kim Barrett Date: 2023-01-16 19:28:25 +0000 URL: https://git.openjdk.org/loom/commit/4c1e66e0abe9e379926e555bd651e9fcc5a0e8b6 8299971: Remove metaprogramming/conditional.hpp Reviewed-by: tschatzl, kbarrett ! src/hotspot/share/gc/shared/oopStorage.inline.hpp ! src/hotspot/share/gc/shared/oopStorageParState.hpp ! src/hotspot/share/gc/shared/oopStorageParState.inline.hpp - src/hotspot/share/metaprogramming/conditional.hpp ! src/hotspot/share/oops/accessBackend.hpp ! src/hotspot/share/runtime/atomic.hpp ! src/hotspot/share/runtime/continuationFreezeThaw.cpp ! src/hotspot/share/utilities/moveBits.hpp ! src/hotspot/share/utilities/population_count.hpp ! test/hotspot/gtest/gc/shared/test_oopStorage.cpp - test/hotspot/gtest/metaprogramming/test_conditional.cpp Changeset: f52f6e65 Author: Justin King Committer: Kim Barrett Date: 2023-01-16 19:30:16 +0000 URL: https://git.openjdk.org/loom/commit/f52f6e65fba0360d3cf114e19fea402ab0d65eba 8299972: Remove metaprogramming/removeReference.hpp Reviewed-by: tschatzl, kbarrett - src/hotspot/share/metaprogramming/removeReference.hpp - test/hotspot/gtest/metaprogramming/test_removeReference.cpp Changeset: 240830df Author: Hao Sun Date: 2023-01-17 02:07:43 +0000 URL: https://git.openjdk.org/loom/commit/240830df7eaa04e0056e9585ebdbf6b02e8b747c 8297092: [macos_aarch64] Add support for SHA feature detection Reviewed-by: njian, aph, gziemski ! src/hotspot/cpu/aarch64/vm_version_aarch64.cpp ! src/hotspot/os_cpu/bsd_aarch64/vm_version_bsd_aarch64.cpp Changeset: 859ccd1a Author: Fei Yang Date: 2023-01-17 03:06:57 +0000 URL: https://git.openjdk.org/loom/commit/859ccd1a150653c42ebbcd3402994ef9ff4c810f 8299847: RISC-V: Improve PrintOptoAssembly output of CMoveI/L nodes Reviewed-by: fjiang, shade ! src/hotspot/cpu/riscv/riscv.ad Changeset: 06f9374e Author: Matthew Donovan Committer: Julian Waters Date: 2023-01-17 04:41:55 +0000 URL: https://git.openjdk.org/loom/commit/06f9374e0c59fa666e6f120749d9170f65fadc4f 8298867: Basics.java fails with SSL handshake exception Reviewed-by: xuelei, rhalade ! test/jdk/ProblemList.txt ! test/jdk/javax/net/ssl/SSLEngine/Basics.java Changeset: 382fe51b Author: Archie L. Cobbs Committer: Julian Waters Date: 2023-01-17 04:43:40 +0000 URL: https://git.openjdk.org/loom/commit/382fe51b6d7eba7094afa070032bedaa9ffc0633 8163229: several regression tests have a main method that is never executed Reviewed-by: vromero ! test/langtools/tools/javac/4980495/static/Test.java ! test/langtools/tools/javac/4980495/std/Test.java ! test/langtools/tools/javac/6491592/T6491592.java ! test/langtools/tools/javac/6857948/T6857948.java ! test/langtools/tools/javac/8062359/UnresolvableClassNPEInAttrTest.java ! test/langtools/tools/javac/8161985/T8161985a.java ! test/langtools/tools/javac/8238735/T8238735.java ! test/langtools/tools/javac/AnonymousClass/AnonymousInSuperCallNegTest.java ! test/langtools/tools/javac/BreakAcrossClass.java ! test/langtools/tools/javac/CaptureInSubtype.java ! test/langtools/tools/javac/DefiniteAssignment/DASwitch.java ! test/langtools/tools/javac/DefiniteAssignment/DUParam1.java ! test/langtools/tools/javac/DefiniteAssignment/DefAssignAfterTry1.java ! test/langtools/tools/javac/DefiniteAssignment/DefAssignAfterTry2.java ! test/langtools/tools/javac/DefiniteAssignment/DefAssignAfterTry3.java ! test/langtools/tools/javac/DefiniteAssignment/T4717164.java ! test/langtools/tools/javac/DefiniteAssignment/T4718142.java ! test/langtools/tools/javac/DefiniteAssignment/T4718142a.java ! test/langtools/tools/javac/DefiniteAssignment/UncaughtException.java ! test/langtools/tools/javac/OverrideChecks/T4721069.java ! test/langtools/tools/javac/ParseConditional.java ! test/langtools/tools/javac/SwitchScope.java ! test/langtools/tools/javac/SynthName2.java ! test/langtools/tools/javac/T5003235/T5003235b.java ! test/langtools/tools/javac/T6306967.java ! test/langtools/tools/javac/T6326754.java ! test/langtools/tools/javac/T6379327.java ! test/langtools/tools/javac/T6407257.java ! test/langtools/tools/javac/TryWithResources/BadTwr.java ! test/langtools/tools/javac/TryWithResources/BadTwr.out ! test/langtools/tools/javac/TryWithResources/BadTwrSyntax.java ! test/langtools/tools/javac/TryWithResources/DuplicateResourceDecl.java ! test/langtools/tools/javac/TryWithResources/DuplicateResourceDecl.out ! test/langtools/tools/javac/TryWithResources/ImplicitFinal.java ! test/langtools/tools/javac/TryWithResources/PlainTry.java ! test/langtools/tools/javac/TryWithResources/T7022711.java ! test/langtools/tools/javac/TryWithResources/TwrAndLambda.java ! test/langtools/tools/javac/TryWithResources/TwrFlow.java ! test/langtools/tools/javac/TryWithResources/TwrForVariable2.java ! test/langtools/tools/javac/TryWithResources/TwrForVariable3.java ! test/langtools/tools/javac/TryWithResources/TwrForVariable4.java ! test/langtools/tools/javac/TryWithResources/TwrOnNonResource.java ! test/langtools/tools/javac/TryWithResources/TwrVarKinds.java ! test/langtools/tools/javac/TryWithResources/TwrVarRedeclaration.java ! test/langtools/tools/javac/TryWithResources/TwrVarRedeclaration.out ! test/langtools/tools/javac/UseEnum.java ! test/langtools/tools/javac/annotations/neg/Cycle3.java ! test/langtools/tools/javac/annotations/typeAnnotations/failures/StaticFields.java ! test/langtools/tools/javac/annotations/typeAnnotations/failures/target/DotClass.java ! test/langtools/tools/javac/capture/Martin.java ! test/langtools/tools/javac/defaultMethods/private/Private06.java ! test/langtools/tools/javac/defaultMethods/static/Static02.java ! test/langtools/tools/javac/depDocComment/DeprecatedDocComment.java ! test/langtools/tools/javac/generics/6245699/T6245699b.java ! test/langtools/tools/javac/generics/6413682/T6413682.java ! test/langtools/tools/javac/generics/6495506/T6495506.java ! test/langtools/tools/javac/generics/6723444/T6723444.java ! test/langtools/tools/javac/generics/GetClass.java ! test/langtools/tools/javac/generics/Nonlinear.java ! test/langtools/tools/javac/generics/UnsoundInference.java ! test/langtools/tools/javac/generics/diamond/neg/Neg08.java ! test/langtools/tools/javac/generics/diamond/neg/Neg13.java ! test/langtools/tools/javac/generics/diamond/neg/Neg14.java ! test/langtools/tools/javac/generics/diamond/neg/Neg15.java ! test/langtools/tools/javac/generics/diamond/neg/Neg17.java ! test/langtools/tools/javac/generics/diamond/neg/Neg18.java ! test/langtools/tools/javac/generics/diamond/neg/Neg19.java ! test/langtools/tools/javac/generics/inference/4972073/T4972073.java ! test/langtools/tools/javac/generics/inference/5081782/Neg.java ! test/langtools/tools/javac/generics/odersky/BadTest.java ! test/langtools/tools/javac/generics/odersky/BadTest3.java ! test/langtools/tools/javac/generics/typeargs/Metharg1.java ! test/langtools/tools/javac/generics/typeargs/Metharg2.java ! test/langtools/tools/javac/generics/typeargs/Newarg1.java ! test/langtools/tools/javac/generics/typeargs/Newarg2.java ! test/langtools/tools/javac/generics/typeargs/Superarg1.java ! test/langtools/tools/javac/generics/typeargs/Superarg2.java ! test/langtools/tools/javac/generics/typeargs/ThisArg.java ! test/langtools/tools/javac/generics/wildcards/6437894/T6437894.java ! test/langtools/tools/javac/generics/wildcards/AssignmentDifferentTypes.java ! test/langtools/tools/javac/generics/wildcards/AssignmentSameType.java ! test/langtools/tools/javac/generics/wildcards/T6450290.java ! test/langtools/tools/javac/implicitThis/NewBeforeOuterConstructed2.java ! test/langtools/tools/javac/lambda/8071432/T8071432.java ! test/langtools/tools/javac/lambda/LambdaConv10.java ! test/langtools/tools/javac/lambda/MethodReference20.java ! test/langtools/tools/javac/lambda/MethodReference25.java ! test/langtools/tools/javac/lambda/MethodReference41.java ! test/langtools/tools/javac/lambda/MethodReference42.java ! test/langtools/tools/javac/lambda/MethodReference43.java ! test/langtools/tools/javac/lambda/MethodReference44.java ! test/langtools/tools/javac/lambda/MethodReference46.java ! test/langtools/tools/javac/lambda/MethodReference47.java ! test/langtools/tools/javac/lambda/MethodReference48.java ! test/langtools/tools/javac/lambda/MethodReference60.java ! test/langtools/tools/javac/lambda/MostSpecific04.java ! test/langtools/tools/javac/lambda/MostSpecific05.java ! test/langtools/tools/javac/lambda/funcInterfaces/LambdaTest2_neg1.java ! test/langtools/tools/javac/lambda/methodReference/MethodRefIntColonColonNewTest.java ! test/langtools/tools/javac/lambda/methodReference/MethodRefToInnerWithoutOuter.java ! test/langtools/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestVarHandle_neg.java ! test/langtools/tools/javac/lambda/typeInference/InferenceTest_neg1_2.java ! test/langtools/tools/javac/limits/ArrayDims1.java ! test/langtools/tools/javac/limits/ArrayDims2.java ! test/langtools/tools/javac/limits/ArrayDims3.java ! test/langtools/tools/javac/limits/ArrayDims4.java ! test/langtools/tools/javac/limits/PoolSize2.java ! test/langtools/tools/javac/limits/StringLength.java ! test/langtools/tools/javac/nested/5009484/X.java ! test/langtools/tools/javac/overload/T5090220.java ! test/langtools/tools/javac/patterns/BindingsTest1Merging.java ! test/langtools/tools/javac/patterns/BindingsTest2.java ! test/langtools/tools/javac/patterns/CastConversionMatch.java ! test/langtools/tools/javac/patterns/DeconstructionPatternErrors.java ! test/langtools/tools/javac/patterns/DeconstructionPatternErrors.out ! test/langtools/tools/javac/patterns/EnsureTypesOrderTest.java ! test/langtools/tools/javac/patterns/ImpossibleTypeTest.java ! test/langtools/tools/javac/patterns/MatchBindingScopeTest.java ! test/langtools/tools/javac/patterns/NullsInPatterns.java ! test/langtools/tools/javac/patterns/PatternVariablesAreNonFinal.java ! test/langtools/tools/javac/patterns/UncheckedWarningOnMatchesTest.java ! test/langtools/tools/javac/scope/6225935/Estatico4.java ! test/langtools/tools/javac/staticImport/ImportPrivate.java ! test/langtools/tools/javac/switchexpr/DefiniteAssignment2.java ! test/langtools/tools/javac/switchexpr/ExpressionSwitchUnreachable.java ! test/langtools/tools/javac/switchextra/DefiniteAssignment2.java ! test/langtools/tools/javac/unicode/NonasciiDigit.java ! test/langtools/tools/javac/varargs/6313164/T7175433.java ! test/langtools/tools/javac/varargs/Warn2.java Changeset: 8365c677 Author: Tejesh R Date: 2023-01-17 04:44:42 +0000 URL: https://git.openjdk.org/loom/commit/8365c6775cb3d2e15c4849f0ba69dc49bad2cf6a 8300084: AquaFileChooserUI.getDefaultButton returns null Reviewed-by: aivanov, serb ! src/java.desktop/macosx/classes/com/apple/laf/AquaFileChooserUI.java Changeset: 6a81d528 Author: Afshin Zafari Committer: David Holmes Date: 2023-01-17 05:44:41 +0000 URL: https://git.openjdk.org/loom/commit/6a81d528e89de73183d6b51c9c366c85ae594d9d 8299213: Bad cast in GrowableArrayWithAllocator<>::grow Reviewed-by: kbarrett, jsjolen, jwaters ! src/hotspot/share/utilities/growableArray.hpp Changeset: f829a679 Author: Hao Sun Date: 2023-01-17 06:43:58 +0000 URL: https://git.openjdk.org/loom/commit/f829a67935328824d2465d9073107cda7eaaf216 8300227: [macos_aarch64] assert(cpu_has("hw.optional.arm.FEAT_AES")) failed after JDK-8297092 Reviewed-by: dholmes ! src/hotspot/os_cpu/bsd_aarch64/vm_version_bsd_aarch64.cpp Changeset: 3462438a Author: Per Minborg Date: 2023-01-17 07:44:26 +0000 URL: https://git.openjdk.org/loom/commit/3462438ae1bc469243096abeb5adbe007ef14fe5 8299576: Reimplement java.io.Bits using VarHandle access Reviewed-by: uschindler, alanb ! src/java.base/share/classes/java/io/Bits.java + test/jdk/java/io/Bits/ReadWriteValues.java + test/jdk/java/io/Bits/java.base/java/io/BitsProxy.java Changeset: 9a36f8aa Author: Erik ?sterlund Date: 2023-01-17 08:00:56 +0000 URL: https://git.openjdk.org/loom/commit/9a36f8aadb08f8ade578530c70d9abe38f1826c6 8299673: Simplify object pinning interactions with string deduplication Co-authored-by: Stefan Karlsson Co-authored-by: Axel Boldt-Christmas Reviewed-by: kbarrett, stefank, dholmes ! src/hotspot/share/gc/epsilon/epsilonHeap.hpp ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1CollectedHeap.hpp ! src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp ! src/hotspot/share/gc/parallel/parallelScavengeHeap.hpp ! src/hotspot/share/gc/serial/serialHeap.cpp ! src/hotspot/share/gc/serial/serialHeap.hpp ! src/hotspot/share/gc/shared/collectedHeap.cpp ! src/hotspot/share/gc/shared/collectedHeap.hpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp ! src/hotspot/share/gc/z/zCollectedHeap.cpp ! src/hotspot/share/gc/z/zCollectedHeap.hpp ! src/hotspot/share/prims/jni.cpp Changeset: e82dc693 Author: Matthias Baesken Date: 2023-01-17 08:21:12 +0000 URL: https://git.openjdk.org/loom/commit/e82dc6935b5f575a53fcba9c96767cee1b535cb8 8300205: Swing test bug8078268 make latch timeout configurable Reviewed-by: aivanov, serb ! test/jdk/javax/swing/text/html/parser/Parser/8078268/bug8078268.java Changeset: 07d57531 Author: Abhishek Kumar Committer: Tejesh R Date: 2023-01-17 10:40:19 +0000 URL: https://git.openjdk.org/loom/commit/07d57531726092a003d4c5d4febd33e35e02a1a7 8300168: Typo in AccessibleJTableHeaderEntry javadoc Reviewed-by: psadhukhan, tr ! src/java.desktop/share/classes/javax/swing/table/JTableHeader.java Changeset: b7fb8ef8 Author: Erik ?sterlund Date: 2023-01-17 12:16:05 +0000 URL: https://git.openjdk.org/loom/commit/b7fb8ef89edf21ab1d6197ca8aff5a421d82c74c 8299323: Allow extended registers for cmpw Reviewed-by: sviswanathan, kvn ! src/hotspot/cpu/x86/assembler_x86.cpp Changeset: e15bdc58 Author: Sergey Bylokhov Date: 2023-01-14 04:19:54 +0000 URL: https://git.openjdk.org/loom/commit/e15bdc58abdac131c635de80440006f48c303b3f 8299789: Compilation of gtest causes build to fail if runtime libraries are in different dirs Reviewed-by: erikj Backport-of: c8a8388aba3dc121bad04aaa123f6cd7525c3d38 ! make/hotspot/test/GtestImage.gmk Changeset: 85d70acc Author: Jesper Wilhelmsson Date: 2023-01-17 13:19:14 +0000 URL: https://git.openjdk.org/loom/commit/85d70acc6e5b9f394d446c270f15bb3793916e63 Merge Changeset: 4cd166ff Author: Albert Mingkun Yang Date: 2023-01-17 15:41:23 +0000 URL: https://git.openjdk.org/loom/commit/4cd166ff27c1e03a61855664f61dda4fca9aa5c9 8300125: Serial: Remove unused Generation::reset_saved_marks Reviewed-by: kbarrett, lkorinth ! src/hotspot/share/gc/serial/defNewGeneration.cpp ! src/hotspot/share/gc/serial/defNewGeneration.hpp ! src/hotspot/share/gc/serial/tenuredGeneration.cpp ! src/hotspot/share/gc/serial/tenuredGeneration.hpp ! src/hotspot/share/gc/shared/generation.hpp Changeset: fb147aae Author: Alan Bateman Date: 2023-01-17 16:25:11 +0000 URL: https://git.openjdk.org/loom/commit/fb147aaea1593e8a13d562d15994f67cdde3eb35 8300228: ModuleReader.find on exploded module throws if resource name maps to invalid file path Reviewed-by: jpai, chegar, cstein ! src/java.base/share/classes/jdk/internal/module/Resources.java ! test/jdk/java/lang/module/ModuleReader/ModuleReaderTest.java Changeset: e139ec3d Author: Justin King Committer: Magnus Ihse Bursie Date: 2023-01-17 16:59:31 +0000 URL: https://git.openjdk.org/loom/commit/e139ec3db24f68c9907742b530069192a4eec3f3 8300069: Left shift of negative value in share/adlc/dict2.cpp Reviewed-by: ihse, kbarrett ! make/autoconf/jdk-options.m4 Changeset: 75b122fe Author: Magnus Ihse Bursie Date: 2023-01-17 17:00:46 +0000 URL: https://git.openjdk.org/loom/commit/75b122feeae60c38076883b27b173c1cafcacdf5 8300120: Configure should support different defaults for CI/dev build environments Reviewed-by: erikj ! .github/workflows/build-linux.yml ! .github/workflows/build-macos.yml ! .github/workflows/build-windows.yml ! make/autoconf/basic.m4 ! make/autoconf/configure.ac ! make/autoconf/lib-tests.m4 ! make/conf/jib-profiles.js Changeset: 0b9ff06f Author: Xin Liu Date: 2023-01-17 17:09:25 +0000 URL: https://git.openjdk.org/loom/commit/0b9ff06f3a72d26d64cdc43f9991005bba2aedba 8300184: Optimize ResourceHashtableBase::iterate_all using _number_of_entries Reviewed-by: dholmes, rehn ! src/hotspot/share/utilities/resourceHash.hpp Changeset: e7e37121 Author: Naoto Sato Date: 2023-01-17 17:25:44 +0000 URL: https://git.openjdk.org/loom/commit/e7e371212163ba6a56a9a365c662da3fa1a0fe47 8300010: UnsatisfiedLinkError on calling System.console().readPassword() on Windows Reviewed-by: alanb ! src/java.base/windows/native/libjava/Console_md.c + src/java.base/windows/native/libjava/JdkConsoleImpl_md.c Changeset: 8c12ae86 Author: SWinxy Committer: Alexey Ivanov Date: 2023-01-17 17:30:25 +0000 URL: https://git.openjdk.org/loom/commit/8c12ae867350a866a6a110ea85d86404f1efb0fb 8283203: Fix typo in SystemTray.getTrayIconSize javadoc Reviewed-by: aivanov ! src/java.desktop/share/classes/java/awt/SystemTray.java Changeset: d7c05d18 Author: Justin Lu Committer: Naoto Sato Date: 2023-01-17 18:30:32 +0000 URL: https://git.openjdk.org/loom/commit/d7c05d18700e512722aee078c049389733f87867 8300011: Refactor code examples to use @snippet in java.util.TimeZone Reviewed-by: lancea, naoto, iris ! src/java.base/share/classes/java/util/TimeZone.java Changeset: ade08e19 Author: Justin Lu Committer: Naoto Sato Date: 2023-01-17 19:40:41 +0000 URL: https://git.openjdk.org/loom/commit/ade08e190cc28cf0ce0194fa3fb67e48dc634e07 8300093: Refactor code examples to use @snippet in java.text.MessageFormat Reviewed-by: iris, naoto ! src/java.base/share/classes/java/text/MessageFormat.java Changeset: e37078f5 Author: Claes Redestad Date: 2023-01-17 21:06:22 +0000 URL: https://git.openjdk.org/loom/commit/e37078f5bb626c7ce0348a38bb86ca2ca62ba915 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops Co-authored-by: Sandhya Viswanathan Co-authored-by: Ludovic Henry Co-authored-by: Claes Redestad Reviewed-by: vlivanov, sviswanathan, luhenry ! src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp ! src/hotspot/cpu/x86/c2_MacroAssembler_x86.hpp ! src/hotspot/cpu/x86/stubRoutines_x86.cpp ! src/hotspot/cpu/x86/stubRoutines_x86.hpp ! src/hotspot/cpu/x86/vm_version_x86.cpp ! src/hotspot/cpu/x86/x86_64.ad ! src/hotspot/share/adlc/formssel.cpp ! src/hotspot/share/classfile/vmIntrinsics.cpp ! src/hotspot/share/classfile/vmIntrinsics.hpp ! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp ! src/hotspot/share/opto/c2compiler.cpp ! src/hotspot/share/opto/classes.hpp ! src/hotspot/share/opto/escape.cpp ! src/hotspot/share/opto/intrinsicnode.cpp ! src/hotspot/share/opto/intrinsicnode.hpp ! src/hotspot/share/opto/lcm.cpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/opto/library_call.hpp ! src/hotspot/share/opto/loopTransform.cpp ! src/hotspot/share/opto/loopnode.cpp ! src/hotspot/share/opto/matcher.cpp ! src/hotspot/share/runtime/globals.hpp ! src/java.base/share/classes/java/lang/StringLatin1.java ! src/java.base/share/classes/java/lang/StringUTF16.java ! src/java.base/share/classes/java/lang/System.java ! src/java.base/share/classes/java/util/Arrays.java ! src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java ! src/java.base/share/classes/jdk/internal/util/ArraysSupport.java + test/jdk/java/lang/String/HashCode.java + test/jdk/java/util/Arrays/HashCode.java ! test/jdk/javax/net/ssl/SSLEngine/Arrays.java ! test/micro/org/openjdk/bench/java/lang/StringHashCode.java + test/micro/org/openjdk/bench/java/util/ArraysHashCode.java Changeset: 00b6c551 Author: Justin King Committer: Magnus Ihse Bursie Date: 2023-01-17 21:53:34 +0000 URL: https://git.openjdk.org/loom/commit/00b6c551ec4254ff9adf9749f5eb3980af3ddb3d 8300254: ASan build does not correctly propagate ASAN_OPTIONS Reviewed-by: ihse ! make/autoconf/jdk-options.m4 ! make/autoconf/spec.gmk.in ! make/common/modules/LauncherCommon.gmk + make/data/asan/asan_default_options.c Changeset: f9883fc4 Author: Joe Darcy Date: 2023-01-17 22:17:34 +0000 URL: https://git.openjdk.org/loom/commit/f9883fc45b3bf5fc6e104491d24f7303802f8dbd 8300279: Use generalized see and link tags in core libs in client libs Reviewed-by: aivanov, prr ! src/java.desktop/share/classes/java/awt/Shape.java Changeset: 1d8b87dd Author: Joe Darcy Date: 2023-01-17 22:19:30 +0000 URL: https://git.openjdk.org/loom/commit/1d8b87dda4f0e40b02dd025fb5fa9d0a75fc9f90 8300321: Use link tags in javax.sql.rowset package-info Reviewed-by: lancea, iris ! src/java.sql.rowset/share/classes/javax/sql/rowset/package-info.java Changeset: 7071397e Author: Jonathan Gibbons Date: 2023-01-17 23:43:35 +0000 URL: https://git.openjdk.org/loom/commit/7071397ed92fb70a52723b4b753c943c010e0fb2 8299224: TestReporterStreams.java has bad indentation for legal header Reviewed-by: prappo ! test/langtools/jdk/javadoc/doclet/testReporterStreams/TestReporterStreams.java Changeset: 89a032dc Author: Sergey Kuksenko Date: 2023-01-18 00:16:34 +0000 URL: https://git.openjdk.org/loom/commit/89a032dc057d04c996632ad317a0303cf3560852 8300002: Performance regression caused by non-inlined hot methods due to post call noop instructions Reviewed-by: kvn, iveresov, eosterlund ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp ! src/hotspot/cpu/ppc/macroAssembler_ppc.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! src/hotspot/share/asm/assembler.hpp ! src/hotspot/share/asm/codeBuffer.cpp ! src/hotspot/share/asm/codeBuffer.hpp ! src/hotspot/share/ci/ciMethod.cpp ! src/hotspot/share/ci/ciMethod.hpp ! src/hotspot/share/ci/ciReplay.cpp ! src/hotspot/share/code/compiledMethod.hpp ! src/hotspot/share/code/nmethod.cpp ! src/hotspot/share/code/nmethod.hpp ! src/hotspot/share/opto/bytecodeInfo.cpp ! src/hotspot/share/runtime/vmStructs.cpp Changeset: f1194dc0 Author: Fei Yang Date: 2023-01-18 01:14:47 +0000 URL: https://git.openjdk.org/loom/commit/f1194dc07ec347f4f9d785e7647983da61441c0e 8300109: RISC-V: Improve code generation for MinI/MaxI nodes Reviewed-by: fjiang, luhenry, shade ! src/hotspot/cpu/riscv/riscv.ad Changeset: 1f438a8a Author: Ramkumar Sunderbabu Committer: Fairoz Matte Date: 2023-01-18 06:53:04 +0000 URL: https://git.openjdk.org/loom/commit/1f438a8a702034c2f10c0008e72395f526b15ef5 8282651: ZGC: vmTestbase/gc/ArrayJuggle/ tests fails intermittently with exit code 97 Reviewed-by: lmesnik ! test/hotspot/jtreg/vmTestbase/gc/ArrayJuggle/Juggle01/Juggle01.java ! test/hotspot/jtreg/vmTestbase/gc/ArrayJuggle/Juggle02/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/ArrayJuggle/Juggle03/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/ArrayJuggle/Juggle04/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/ArrayJuggle/Juggle05/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/ArrayJuggle/Juggle06/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/ArrayJuggle/Juggle07/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/ArrayJuggle/Juggle08/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/ArrayJuggle/Juggle09/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/ArrayJuggle/Juggle10/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/ArrayJuggle/Juggle11/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/ArrayJuggle/Juggle12/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/ArrayJuggle/Juggle13/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/ArrayJuggle/Juggle14/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/ArrayJuggle/Juggle15/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/ArrayJuggle/Juggle16/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/ArrayJuggle/Juggle17/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/ArrayJuggle/Juggle18/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/ArrayJuggle/Juggle19/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/ArrayJuggle/Juggle20/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/ArrayJuggle/Juggle21/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/ArrayJuggle/Juggle22/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/ArrayJuggle/Juggle23/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/ArrayJuggle/Juggle24/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/ArrayJuggle/Juggle25/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/ArrayJuggle/Juggle26/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/ArrayJuggle/Juggle27/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/ArrayJuggle/Juggle28/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/ArrayJuggle/Juggle29/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/ArrayJuggle/Juggle30/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/ArrayJuggle/Juggle31/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/ArrayJuggle/Juggle32/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/ArrayJuggle/Juggle33/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/ArrayJuggle/Juggle34/TestDescription.java Changeset: 66f7387b Author: Tobias Hartmann Date: 2023-01-18 08:15:19 +0000 URL: https://git.openjdk.org/loom/commit/66f7387b5ffa53861b92b068fb9832fc433d9f79 8299074: nmethod marked for deoptimization is not deoptimized Reviewed-by: eosterlund, rehn, kvn ! src/hotspot/share/code/dependencyContext.cpp Changeset: c7056737 Author: Axel Boldt-Christmas Date: 2023-01-18 09:21:08 +0000 URL: https://git.openjdk.org/loom/commit/c7056737e33d3d5a6ec24639d46b9e3e7a8da01a 8299089: Instrument global jni handles with tag to make them distinguishable Co-authored-by: Stefan Karlsson Co-authored-by: Martin Doerr Co-authored-by: Leslie Zhai Reviewed-by: eosterlund, stefank, ayang ! src/hotspot/cpu/aarch64/gc/shared/barrierSetAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp ! src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp ! src/hotspot/cpu/arm/jniFastGetField_arm.cpp ! src/hotspot/cpu/arm/macroAssembler_arm.cpp ! src/hotspot/cpu/arm/macroAssembler_arm.hpp ! src/hotspot/cpu/arm/stubGenerator_arm.cpp ! src/hotspot/cpu/ppc/gc/g1/g1BarrierSetAssembler_ppc.cpp ! src/hotspot/cpu/ppc/gc/shared/barrierSetAssembler_ppc.cpp ! src/hotspot/cpu/ppc/gc/shared/barrierSetAssembler_ppc.hpp ! src/hotspot/cpu/ppc/gc/shared/modRefBarrierSetAssembler_ppc.cpp ! src/hotspot/cpu/ppc/macroAssembler_ppc.cpp ! src/hotspot/cpu/ppc/macroAssembler_ppc.hpp ! src/hotspot/cpu/ppc/stubGenerator_ppc.cpp ! src/hotspot/cpu/riscv/gc/shared/barrierSetAssembler_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/s390/gc/g1/g1BarrierSetAssembler_s390.cpp ! src/hotspot/cpu/s390/gc/shared/barrierSetAssembler_s390.cpp ! src/hotspot/cpu/x86/gc/shared/barrierSetAssembler_x86.cpp ! src/hotspot/cpu/x86/jniFastGetField_x86_32.cpp ! src/hotspot/cpu/x86/jniFastGetField_x86_64.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.hpp ! src/hotspot/cpu/x86/stubGenerator_x86_32.cpp ! src/hotspot/cpu/x86/stubGenerator_x86_64.cpp ! src/hotspot/share/code/nmethod.cpp ! src/hotspot/share/compiler/compileTask.cpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/runtime/jniHandles.cpp ! src/hotspot/share/runtime/jniHandles.hpp ! src/hotspot/share/runtime/jniHandles.inline.hpp ! test/hotspot/jtreg/runtime/jni/FastGetField/FastGetField.java ! test/hotspot/jtreg/runtime/jni/FastGetField/libFastGetField.c Changeset: 7c8b99ee Author: Daniel Jeli?ski Date: 2023-01-18 09:29:04 +0000 URL: https://git.openjdk.org/loom/commit/7c8b99eedb46890c06af3b8e698b3ba169475231 8300117: Replace use of JNI_COMMIT mode with mode 0 Reviewed-by: serb, prr ! src/java.desktop/macosx/native/libawt_lwawt/awt/CClipboard.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CDropTarget.m Changeset: d9180423 Author: Robbin Ehn Date: 2023-01-18 10:23:11 +0000 URL: https://git.openjdk.org/loom/commit/d9180423b8c7dbe30b60ec844f389a80a1f0b551 8300267: Remove duplicated setter/getter for do_not_unlock Reviewed-by: coleenp, dholmes ! src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp ! src/hotspot/share/runtime/javaThread.hpp Changeset: 15a9186d Author: Jie Fu Date: 2023-01-18 10:32:00 +0000 URL: https://git.openjdk.org/loom/commit/15a9186db251f4be7a13e173842ac1bd858f984d 8300169: Build failure with clang-15 Reviewed-by: dholmes, prr ! make/hotspot/lib/CompileJvm.gmk ! make/modules/java.base/lib/CoreLibraries.gmk ! make/modules/java.desktop/lib/Awt2dLibraries.gmk ! src/hotspot/share/oops/generateOopMap.cpp ! src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m ! src/java.desktop/share/native/libharfbuzz/hb-meta.hh Changeset: bd5ca953 Author: Johan Sj?len Date: 2023-01-18 13:10:13 +0000 URL: https://git.openjdk.org/loom/commit/bd5ca953058704087da4bc5796b3ce28ce2a8f78 8300222: Replace NULL with nullptr in share/logging Reviewed-by: coleenp, dholmes ! src/hotspot/share/logging/log.hpp ! src/hotspot/share/logging/logAsyncWriter.cpp ! src/hotspot/share/logging/logConfiguration.cpp ! src/hotspot/share/logging/logConfiguration.hpp ! src/hotspot/share/logging/logDecorations.cpp ! src/hotspot/share/logging/logDecorators.cpp ! src/hotspot/share/logging/logDecorators.hpp ! src/hotspot/share/logging/logDiagnosticCommand.cpp ! src/hotspot/share/logging/logDiagnosticCommand.hpp ! src/hotspot/share/logging/logFileOutput.cpp ! src/hotspot/share/logging/logFileStreamOutput.cpp ! src/hotspot/share/logging/logMessageBuffer.cpp ! src/hotspot/share/logging/logMessageBuffer.hpp ! src/hotspot/share/logging/logOutput.cpp ! src/hotspot/share/logging/logOutputList.cpp ! src/hotspot/share/logging/logOutputList.hpp ! src/hotspot/share/logging/logSelection.cpp ! src/hotspot/share/logging/logSelection.hpp ! src/hotspot/share/logging/logSelectionList.cpp ! src/hotspot/share/logging/logSelectionList.hpp ! src/hotspot/share/logging/logStream.cpp ! src/hotspot/share/logging/logStream.hpp ! src/hotspot/share/logging/logTagSet.cpp ! src/hotspot/share/logging/logTagSetDescriptions.cpp Changeset: 1aded82e Author: Julian Waters Date: 2023-01-18 13:11:32 +0000 URL: https://git.openjdk.org/loom/commit/1aded82e546869f80b0464e92de137cc42db2658 8300488: Incorrect usage of CATCH_BAD_ALLOC as a macro call Reviewed-by: aivanov ! src/java.desktop/windows/native/libawt/windows/awt_TrayIcon.cpp Changeset: c464ef1d Author: Afshin Zafari Committer: Robbin Ehn Date: 2023-01-18 13:21:32 +0000 URL: https://git.openjdk.org/loom/commit/c464ef1d61c2ea4a37759546f0ee39b1f530ccdc 8292741: Convert JvmtiTagMapTable to ResourceHashtable Reviewed-by: dholmes, coleenp, rehn ! src/hotspot/share/prims/jvmtiTagMap.cpp ! src/hotspot/share/prims/jvmtiTagMap.hpp ! src/hotspot/share/prims/jvmtiTagMapTable.cpp ! src/hotspot/share/prims/jvmtiTagMapTable.hpp Changeset: 85d8bacb Author: Andrey Turbanov Date: 2023-01-18 13:23:59 +0000 URL: https://git.openjdk.org/loom/commit/85d8bacb0ff4015941db53305e6a0d5d28391e1f 8300166: Unused array allocation in ProcessPath.doProcessPath Reviewed-by: aivanov ! src/java.desktop/share/classes/sun/java2d/loops/ProcessPath.java Changeset: 754f6e61 Author: Sergey Tsypanov Committer: Claes Redestad Date: 2023-01-18 13:55:09 +0000 URL: https://git.openjdk.org/loom/commit/754f6e6116b8889c49abf34d01f6fc3e9f1b3cb7 8300237: Minor improvements in MethodHandles Reviewed-by: redestad ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java Changeset: b3684f4b Author: Dmitry Chuyko Date: 2023-01-18 14:56:53 +0000 URL: https://git.openjdk.org/loom/commit/b3684f4bacd8310eea75ebf4ccc70397328d5e86 8153837: AArch64: Handle special cases for MaxINode & MinINode Reviewed-by: fyang, aph ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/aarch64/aarch64_ad.m4 + test/hotspot/jtreg/compiler/intrinsics/math/TestMinMaxIntrinsics.java Changeset: c3242ee4 Author: Coleen Phillimore Date: 2023-01-18 15:19:30 +0000 URL: https://git.openjdk.org/loom/commit/c3242ee452c25b5038283c68e65541122a10df0d 8298596: vmTestbase/nsk/sysdict/vm/stress/chain/chain008/chain008.java fails with "NoClassDefFoundError: Could not initialize class java.util.concurrent.ThreadLocalRandom" Reviewed-by: ayang, tschatzl ! test/hotspot/jtreg/ProblemList-zgc.txt ! test/hotspot/jtreg/vmTestbase/nsk/share/gc/gp/GarbageUtils.java Changeset: c205caea Author: Magnus Ihse Bursie Date: 2023-01-18 16:16:51 +0000 URL: https://git.openjdk.org/loom/commit/c205caead557aea92e319c85d0e974ca7b4830e1 8297851: Add devkit for RISC-V Reviewed-by: fyang, erikj ! make/conf/jib-profiles.js ! make/devkit/Tools.gmk + make/devkit/patches/riscv64-gcc-11.3.0.patch Changeset: fcbf9d05 Author: Johan Sj?len Date: 2023-01-18 16:56:31 +0000 URL: https://git.openjdk.org/loom/commit/fcbf9d052efd16821750fb20813f8030ee828472 8300243: Replace NULL with nullptr in share/compiler/ Reviewed-by: thartmann, kvn ! src/hotspot/share/compiler/abstractDisassembler.cpp ! src/hotspot/share/compiler/compilationLog.cpp ! src/hotspot/share/compiler/compilationPolicy.cpp ! src/hotspot/share/compiler/compilationPolicy.hpp ! src/hotspot/share/compiler/compileBroker.cpp ! src/hotspot/share/compiler/compileBroker.hpp ! src/hotspot/share/compiler/compileLog.cpp ! src/hotspot/share/compiler/compileTask.cpp ! src/hotspot/share/compiler/compileTask.hpp ! src/hotspot/share/compiler/compilerDefinitions.cpp ! src/hotspot/share/compiler/compilerDefinitions.hpp ! src/hotspot/share/compiler/compilerDirectives.cpp ! src/hotspot/share/compiler/compilerDirectives.hpp ! src/hotspot/share/compiler/compilerEvent.cpp ! src/hotspot/share/compiler/compilerOracle.cpp ! src/hotspot/share/compiler/compilerThread.cpp ! src/hotspot/share/compiler/compilerThread.hpp ! src/hotspot/share/compiler/compiler_globals.hpp ! src/hotspot/share/compiler/directivesParser.cpp ! src/hotspot/share/compiler/disassembler.cpp ! src/hotspot/share/compiler/disassembler.hpp ! src/hotspot/share/compiler/methodLiveness.cpp ! src/hotspot/share/compiler/methodMatcher.cpp ! src/hotspot/share/compiler/methodMatcher.hpp ! src/hotspot/share/compiler/oopMap.cpp ! src/hotspot/share/compiler/oopMap.hpp ! src/hotspot/share/compiler/oopMap.inline.hpp Changeset: 3ea0b8bc Author: Claes Redestad Date: 2023-01-18 17:39:27 +0000 URL: https://git.openjdk.org/loom/commit/3ea0b8bc253f1498895a879681406ecc15f37afb 8300489: Use ArraysSupport.vectorizedHashCode in j.l.CharacterName Reviewed-by: alanb, naoto ! src/java.base/share/classes/java/lang/CharacterName.java ! test/micro/org/openjdk/bench/java/lang/Characters.java Changeset: 2a46e07f Author: Rajat Mahajan Committer: Alexey Ivanov Date: 2023-01-18 18:04:30 +0000 URL: https://git.openjdk.org/loom/commit/2a46e07f7d85a3c7db93b53b5c347cd96a91cbb9 8286581: Make Java process DPI Aware if sun.java2d.dpiaware property is set Reviewed-by: aivanov, prr ! src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsEnv.cpp Changeset: 7bf0d146 Author: Joe Darcy Date: 2023-01-18 18:54:03 +0000 URL: https://git.openjdk.org/loom/commit/7bf0d1465e73d83aae30f1cd9fd318af9e9c1b70 8300133: Use generalized see and link tags in core libs Reviewed-by: jjg, mchung, naoto, smarks ! src/java.base/share/classes/java/lang/CharSequence.java ! src/java.base/share/classes/java/lang/String.java ! src/java.base/share/classes/java/lang/module/Configuration.java ! src/java.base/share/classes/java/math/BigDecimal.java ! src/java.base/share/classes/java/net/spi/InetAddressResolverProvider.java ! src/java.base/share/classes/java/util/Collection.java ! src/java.base/share/classes/java/util/Deque.java ! src/java.base/share/classes/java/util/Map.java ! src/java.base/share/classes/java/util/ResourceBundle.java ! src/java.base/share/classes/javax/net/ssl/SNIHostName.java Changeset: 5473e8a1 Author: Joe Darcy Date: 2023-01-18 20:08:37 +0000 URL: https://git.openjdk.org/loom/commit/5473e8a1c616a7004f4a154e235c5344b559104c 8300357: Use generalized see and link tags in java.management Reviewed-by: alanb, dfuchs ! src/java.management/share/classes/java/lang/management/ThreadMXBean.java ! src/java.management/share/classes/javax/management/remote/JMXConnectorFactory.java ! src/java.management/share/classes/javax/management/remote/JMXConnectorServerFactory.java Changeset: ba899b42 Author: Magnus Ihse Bursie Date: 2023-01-18 20:09:34 +0000 URL: https://git.openjdk.org/loom/commit/ba899b42ce2b4b11cd45f8e7795479331d59a1be 8300550: BASIC_JVM_LIBS is set for buildjdk even if this is incorrect Reviewed-by: erikj ! make/autoconf/libraries.m4 Changeset: 8b70c432 Author: Sergey Bylokhov Date: 2023-01-18 20:27:30 +0000 URL: https://git.openjdk.org/loom/commit/8b70c432d31b29bf5f6b8d29809e3c3b91318be1 8299772: The ColorModel.getRGBdefault() method is not thread-safe Reviewed-by: prr ! src/java.desktop/share/classes/java/awt/image/ColorModel.java + test/jdk/java/awt/image/ColorModel/RGBdefaultSingleton.java Changeset: 601e0ae7 Author: Joe Darcy Date: 2023-01-18 22:44:28 +0000 URL: https://git.openjdk.org/loom/commit/601e0ae7da472acb68b53f766b30a688e6bacbcf 8300594: Use generalized see and link tags in UnicastRemoteObject Reviewed-by: rriggs, smarks ! src/java.rmi/share/classes/java/rmi/server/UnicastRemoteObject.java Changeset: dfe94b89 Author: Justin Lu Committer: Naoto Sato Date: 2023-01-18 23:09:46 +0000 URL: https://git.openjdk.org/loom/commit/dfe94b89f82a6a43e2f563bcf93cf5a13930c44e 8300307: Refactor code examples to use @snippet in java.text.DateFormat Reviewed-by: lancea, iris, naoto ! src/java.base/share/classes/java/text/DateFormat.java Changeset: 31a2e02a Author: Justin Lu Committer: Naoto Sato Date: 2023-01-18 23:10:57 +0000 URL: https://git.openjdk.org/loom/commit/31a2e02afcf4853f71925ec75a9a6427b08b4cbd 8300308: java.text.MessageFormat has incorrect doc comment Reviewed-by: naoto, lancea ! src/java.base/share/classes/java/text/MessageFormat.java Changeset: ae0e0276 Author: Erik ?sterlund Date: 2023-01-17 15:05:51 +0000 URL: https://git.openjdk.org/loom/commit/ae0e02766ad01ec6a9a5d4f900c50bd413b09638 8298059: Linked stack watermarks don't support nesting Reviewed-by: stefank Backport-of: b17c52422c91ad1e7ff35844676f6269a1b87f79 ! src/hotspot/share/runtime/keepStackGCProcessed.cpp ! src/hotspot/share/runtime/stackWatermark.cpp ! src/hotspot/share/runtime/stackWatermark.hpp ! test/hotspot/jtreg/ProblemList-zgc.txt Changeset: ba86c23e Author: Naoto Sato Committer: Henry Jen Date: 2022-05-11 17:52:25 +0000 URL: https://git.openjdk.org/loom/commit/ba86c23eaf9b0adaa0a1ee457207a8472037cf8e 8286070: Improve UTF8 representation Reviewed-by: bchristi, rhalade ! src/java.base/share/native/libjava/jni_util.c Changeset: 5aae8226 Author: Phil Race Committer: Henry Jen Date: 2022-08-09 16:57:10 +0000 URL: https://git.openjdk.org/loom/commit/5aae8226fc6196a13c0346a048ce30a57fd1ef14 8288516: Enhance font creation Reviewed-by: psadhukhan, azvegint, rhalade, mschoene ! src/java.desktop/windows/native/libawt/windows/awt_Font.cpp ! src/java.desktop/windows/native/libawt/windows/awt_PrintJob.cpp ! src/java.desktop/windows/native/libfontmanager/fontpath.c ! src/java.desktop/windows/native/libfontmanager/lcdglyph.c Changeset: 51e52c4e Author: Markus Gr?nlund Committer: Henry Jen Date: 2022-09-19 11:27:04 +0000 URL: https://git.openjdk.org/loom/commit/51e52c4eb851d485fd41ad0bdf7df617a1cdb792 8286496: Improve Thread labels Reviewed-by: mschoene, rhalade, egahlin ! src/hotspot/share/jfr/recorder/checkpoint/jfrCheckpointManager.cpp ! src/hotspot/share/jfr/recorder/storage/jfrBuffer.cpp ! src/hotspot/share/jfr/recorder/storage/jfrBuffer.hpp ! src/hotspot/share/jfr/recorder/storage/jfrMemorySpace.inline.hpp ! src/hotspot/share/jfr/writers/jfrWriterHost.inline.hpp Changeset: b7cfb681 Author: Daniel Jeli?ski Committer: Henry Jen Date: 2022-09-26 19:16:22 +0000 URL: https://git.openjdk.org/loom/commit/b7cfb6817b3aabb099d21f5fc6d1619ba346911b 8293598: Enhance InetAddress address handling Reviewed-by: skoivu, alanb, aefimov, rhalade, dfuchs ! src/java.base/share/classes/java/net/InetAddress.java ! src/java.base/share/classes/sun/net/util/IPAddressUtil.java Changeset: 3364c460 Author: Jayathirth D V Committer: Henry Jen Date: 2022-09-29 06:59:58 +0000 URL: https://git.openjdk.org/loom/commit/3364c460a4d5b9b0ce43742130bc0766bb106955 8293734: Improve BMP image handling Reviewed-by: kizune, prr, azvegint, rhalade, mschoene ! src/java.desktop/share/classes/com/sun/imageio/plugins/bmp/BMPImageReader.java Changeset: d6b15132 Author: Prasanta Sadhukhan Committer: Henry Jen Date: 2022-09-29 07:39:29 +0000 URL: https://git.openjdk.org/loom/commit/d6b1513233e926dc77c81ef1123737d6a6ad94b1 8293717: Objective view of ObjectView Reviewed-by: kizune, rhalade, prr, azvegint, skoivu ! src/java.desktop/share/classes/javax/swing/text/html/ObjectView.java Changeset: 2e8073e4 Author: Jamil Nimeh Committer: Henry Jen Date: 2022-10-04 16:55:57 +0000 URL: https://git.openjdk.org/loom/commit/2e8073e4f90156b213a7dca0e8844a6a2525581b 8287411: Enhance DTLS Performance Reviewed-by: rhalade, ahgross, weijun, ascarpino ! src/java.base/share/classes/sun/security/ssl/ClientHello.java ! src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java Changeset: 6c5aefe6 Author: Valerie Peng Committer: Henry Jen Date: 2022-10-07 22:25:38 +0000 URL: https://git.openjdk.org/loom/commit/6c5aefe60c8d294631c716c63ec411feb7f7a4ea 8293554: Enhanced DH Key Exchanges Reviewed-by: rhalade, mschoene, ascarpino, weijun ! src/java.base/share/classes/com/sun/crypto/provider/DHKeyPairGenerator.java ! src/java.base/share/classes/com/sun/crypto/provider/DHParameterGenerator.java ! src/java.base/share/classes/sun/security/provider/ParameterCache.java ! src/java.base/share/classes/sun/security/ssl/PredefinedDHParameterSpecs.java ! src/java.base/share/classes/sun/security/util/SecurityProviderConstants.java Changeset: 93161e46 Author: Alexander Zuev Committer: Henry Jen Date: 2022-10-26 21:29:01 +0000 URL: https://git.openjdk.org/loom/commit/93161e46e73a93e20e5fa45946457b32fdf0613d 8293742: Better Banking of Sounds Reviewed-by: rhalade, azvegint, prr ! src/java.desktop/share/classes/com/sun/media/sound/JARSoundbankReader.java Changeset: bd324cee Author: Jayathirth D V Committer: Henry Jen Date: 2022-11-10 06:16:14 +0000 URL: https://git.openjdk.org/loom/commit/bd324cee9c839e5a78c12cbcea17c4762acfcfd0 8295687: Better BMP bounds Reviewed-by: rhalade, mschoene, psadhukhan, prr ! src/java.desktop/share/classes/com/sun/imageio/plugins/bmp/BMPImageReader.java Changeset: 0f925fef Author: Valerie Peng Committer: Henry Jen Date: 2022-11-10 17:56:33 +0000 URL: https://git.openjdk.org/loom/commit/0f925fefdfc0160b896b35e37c1fef3b3c47a8db 8295723: security/infra/wycheproof/RunWycheproof.java fails with Assertion Error Reviewed-by: mschoene, ascarpino, coffeys, rhalade, weijun ! src/java.base/share/classes/com/sun/crypto/provider/DHKeyPairGenerator.java ! src/java.base/share/classes/sun/security/provider/ParameterCache.java ! src/java.base/share/classes/sun/security/ssl/PredefinedDHParameterSpecs.java + src/java.base/share/classes/sun/security/util/SafeDHParameterSpec.java ! src/java.base/share/classes/sun/security/util/SecurityProviderConstants.java Changeset: c1b4212a Author: Jan Lahoda Date: 2023-01-18 10:43:53 +0000 URL: https://git.openjdk.org/loom/commit/c1b4212a53e5d26108e560a82250b01689ae03f0 8300195: Fall-through issue occurs when using record pattern in switch statements Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java ! test/langtools/tools/javac/patterns/PatternDesugaring.java Changeset: b9275a8e Author: Maurizio Cimadamore Date: 2023-01-18 12:36:15 +0000 URL: https://git.openjdk.org/loom/commit/b9275a8ed1c462cfad33dab140022e5968765e58 8300275: SegmentScope.isAccessibleBy returning incorrect values Reviewed-by: alanb, jvernee ! src/java.base/share/classes/jdk/internal/foreign/MemorySessionImpl.java ! test/jdk/java/foreign/TestSegments.java Changeset: fc9f8baf Author: Jesper Wilhelmsson Date: 2023-01-18 23:29:12 +0000 URL: https://git.openjdk.org/loom/commit/fc9f8baf56a8888362ad60d0e6dc8953690b80d3 Merge ! src/java.desktop/share/classes/com/sun/imageio/plugins/bmp/BMPImageReader.java ! src/java.desktop/windows/native/libawt/windows/awt_PrintJob.cpp ! src/java.desktop/share/classes/com/sun/imageio/plugins/bmp/BMPImageReader.java ! src/java.desktop/windows/native/libawt/windows/awt_PrintJob.cpp Changeset: 910dffea Author: Calvin Cheung Date: 2023-01-19 00:20:13 +0000 URL: https://git.openjdk.org/loom/commit/910dffea867ea57b6338daf9ed7f6ea81536a934 8292635: Run ArchivedEnumTest.java in jdk tier testing Reviewed-by: iklam, dholmes ! src/hotspot/share/cds/cdsHeapVerifier.cpp ! src/hotspot/share/cds/cdsHeapVerifier.hpp ! test/jdk/TEST.ROOT = test/jdk/jdk/internal/misc/CDS/ArchivedEnumApp.java = test/jdk/jdk/internal/misc/CDS/ArchivedEnumTest.java Changeset: f0df27c1 Author: Alan Bateman Date: 2023-01-20 07:58:36 +0000 URL: https://git.openjdk.org/loom/commit/f0df27c18aa7594952f39bcde38887eecdbc38f0 Merge with jdk-21+6 ! make/autoconf/configure.ac ! make/autoconf/lib-tests.m4 ! make/autoconf/spec.gmk.in ! make/conf/jib-profiles.js ! src/hotspot/share/runtime/globals.hpp ! test/hotspot/jtreg/ProblemList-Xcomp.txt ! test/jdk/ProblemList.txt ! make/autoconf/configure.ac ! make/autoconf/lib-tests.m4 ! make/autoconf/spec.gmk.in ! make/conf/jib-profiles.js ! src/hotspot/share/runtime/globals.hpp ! test/hotspot/jtreg/ProblemList-Xcomp.txt ! test/jdk/ProblemList.txt Changeset: 52d0d547 Author: Alan Bateman Date: 2023-01-20 09:51:58 +0000 URL: https://git.openjdk.org/loom/commit/52d0d547a59bf156fb9bba5f08b24bc1b644cad0 Exclude jdk/internal/misc/CDS/ArchivedEnumTest.java from wrapper runs ! test/jdk/ProblemList-vthread.txt From duke at openjdk.org Fri Jan 20 10:08:44 2023 From: duke at openjdk.org (duke) Date: Fri, 20 Jan 2023 10:08:44 GMT Subject: git: openjdk/loom: master: 126 new changesets Message-ID: Changeset: 78b1686c Author: Sergey Bylokhov Date: 2023-01-12 01:52:56 +0000 URL: https://git.openjdk.org/loom/commit/78b1686c150aeaa29c5d969b70c9c42c872246a2 8227257: javax/swing/JFileChooser/4847375/bug4847375.java fails with AssertionError Reviewed-by: aivanov, tr ! src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java ! src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolderManager2.java ! test/jdk/javax/swing/JFileChooser/4847375/bug4847375.java + test/jdk/javax/swing/JFileChooser/FileSystemView/InaccessibleLink.java Changeset: af8d3fb2 Author: Afshin Zafari Committer: Ioi Lam Date: 2023-01-12 01:54:11 +0000 URL: https://git.openjdk.org/loom/commit/af8d3fb21ab59104d49bd664f634399fb72ecbd2 8264684: os::get_summary_cpu_info padded with spaces Reviewed-by: iklam, ccheung ! src/hotspot/os/windows/os_windows.cpp Changeset: d716ec5d Author: Emanuel Peter Date: 2023-01-12 07:23:19 +0000 URL: https://git.openjdk.org/loom/commit/d716ec5d3034240b7dd0aed86d9bb371bc3e5f5a 8299179: ArrayFill with store on backedge needs to reduce length by 1 Reviewed-by: thartmann, kvn ! src/hotspot/share/opto/loopTransform.cpp + test/hotspot/jtreg/compiler/loopopts/TestBackedgeLoadArrayFill.jasm + test/hotspot/jtreg/compiler/loopopts/TestBackedgeLoadArrayFillMain.java Changeset: 0ee8cac7 Author: Matthias Baesken Date: 2023-01-12 08:04:46 +0000 URL: https://git.openjdk.org/loom/commit/0ee8cac7c7b317c780e4a08c2dd6daf36301a3e5 8299672: Enhance HeapDump JFR event Reviewed-by: rschmelter, clanger ! src/hotspot/share/jfr/metadata/metadata.xml ! src/hotspot/share/services/heapDumper.cpp ! test/jdk/jdk/jfr/event/diagnostics/TestHeapDump.java Changeset: 036c8084 Author: Nick Gasson Date: 2023-01-12 09:28:46 +0000 URL: https://git.openjdk.org/loom/commit/036c80844e30559bdced3587bb70b29ee38af498 8298482: Implement ParallelGC NUMAStats for Linux Reviewed-by: ayang, sjohanss, tschatzl ! 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/mutableNUMASpace.hpp ! src/hotspot/share/runtime/os.hpp Changeset: 4b573343 Author: Alan Bateman Date: 2023-01-12 09:38:31 +0000 URL: https://git.openjdk.org/loom/commit/4b573343a6eb05b8b469177935d48c48957aff64 8278326: Socket close is not thread safe and other cleanup Reviewed-by: jpai ! src/java.base/share/classes/java/net/HttpConnectSocketImpl.java ! src/java.base/share/classes/java/net/ServerSocket.java ! src/java.base/share/classes/java/net/Socket.java + test/jdk/java/net/ServerSocket/ImplAccept.java + test/jdk/java/net/Socket/asyncClose/Leaky.java Changeset: 89d3f3d9 Author: Axel Boldt-Christmas Date: 2023-01-12 12:38:13 +0000 URL: https://git.openjdk.org/loom/commit/89d3f3d96b220c249e7b273a09cc3897428f8814 8299125: UnifiedOopRef in JFR leakprofiler should treat thread local oops correctly Reviewed-by: eosterlund, mgronlun ! src/hotspot/share/jfr/leakprofiler/chains/rootSetClosure.cpp ! src/hotspot/share/jfr/leakprofiler/utilities/unifiedOopRef.hpp ! src/hotspot/share/jfr/leakprofiler/utilities/unifiedOopRef.inline.hpp ! src/hotspot/share/oops/accessBackend.hpp Changeset: 48c8fb39 Author: Claes Redestad Date: 2023-01-12 13:39:59 +0000 URL: https://git.openjdk.org/loom/commit/48c8fb39a74f07335d366a0a3052e3c00634d869 8299978: Remove MethodHandleNatives.getMembers Reviewed-by: jvernee, mchung ! src/hotspot/share/classfile/javaClasses.hpp ! src/hotspot/share/prims/methodHandles.cpp ! src/hotspot/share/prims/methodHandles.hpp ! src/java.base/share/classes/java/lang/invoke/MethodHandleNatives.java Changeset: cf00d09c Author: Julian Waters Date: 2023-01-12 14:32:14 +0000 URL: https://git.openjdk.org/loom/commit/cf00d09c8c37ee301e1c6657df45777647a834e9 8299330: Minor improvements in MSYS2 Workflow handling Reviewed-by: clanger, ihse ! .github/actions/get-msys2/action.yml ! .github/workflows/build-windows.yml Changeset: 26890d19 Author: Julian Waters Date: 2023-01-12 15:01:59 +0000 URL: https://git.openjdk.org/loom/commit/26890d19096a9af95df05105e7e2972068af3742 8296478: Rework 8282948 and 8282700 to use the new autoconf UTIL_ARG_WITH Reviewed-by: erikj, ihse ! make/autoconf/jdk-options.m4 ! make/autoconf/jdk-version.m4 ! make/autoconf/util.m4 Changeset: 7a85d95e Author: Justin King Committer: Magnus Ihse Bursie Date: 2023-01-12 15:50:05 +0000 URL: https://git.openjdk.org/loom/commit/7a85d95e828283d57e1df0344be454626470675d 8298448: UndefinedBehaviorSanitizer Reviewed-by: erikj, ihse ! make/autoconf/configure.ac ! make/autoconf/jdk-options.m4 ! make/autoconf/spec.gmk.in ! make/common/NativeCompilation.gmk + make/data/ubsan/ubsan_default_options.c = make/data/ubsan/ubsan_default_options.cpp Changeset: 33412c10 Author: Raffaello Giulietti Date: 2023-01-12 19:21:09 +0000 URL: https://git.openjdk.org/loom/commit/33412c102ce799ff2de3512df77e6e07d76acd36 8299677: Formatter.format might take a long time to format an integer or floating-point Reviewed-by: alanb, stsypanov, darcy ! src/java.base/share/classes/java/util/Formatter.java + test/jdk/java/util/Formatter/Padding.java Changeset: 3918f9f5 Author: Jorn Vernee Date: 2023-01-12 06:49:27 +0000 URL: https://git.openjdk.org/loom/commit/3918f9f523521e77bd3820be28d79a4c1d02903c 8299090: Specify coordinate order for additional CaptureCallState parameters on class as well Reviewed-by: pminborg, mcimadamore ! src/java.base/share/classes/java/lang/foreign/Linker.java Changeset: 752a3701 Author: Christoph Langer Date: 2023-01-12 08:02:58 +0000 URL: https://git.openjdk.org/loom/commit/752a37016f49ef8f2405dd74f96f58f80d606cd3 8299439: java/text/Format/NumberFormat/CurrencyFormat.java fails for hr_HR Reviewed-by: naoto Backport-of: 3b374c0153950ab193f3a188b57d3404b4ce2fe2 ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_hr_HR.properties ! test/jdk/ProblemList.txt ! test/jdk/java/text/Format/NumberFormat/CurrencySymbols.properties Changeset: 6a4a8743 Author: Roger Riggs Date: 2023-01-12 14:54:39 +0000 URL: https://git.openjdk.org/loom/commit/6a4a8743562bd8f937542cdeb6557b3fe60e9a23 8299034: Runtime::exec clarification of inherited environment Reviewed-by: alanb ! src/java.base/share/classes/java/lang/ProcessBuilder.java ! src/java.base/share/classes/java/lang/Runtime.java Changeset: 4b92fb0c Author: Mikael Vidstedt Date: 2023-01-12 18:47:08 +0000 URL: https://git.openjdk.org/loom/commit/4b92fb0c6bc82e37e5fb20c72c3ff701070be6dd 8299918: Update Xcode11.3.1-MacOSX10.15 devkit at Oracle Reviewed-by: erikj Backport-of: a17b563f54b2e0953a1dd9a613e6d5e0e9a8e4cb ! make/conf/jib-profiles.js Changeset: 98870472 Author: Jesper Wilhelmsson Date: 2023-01-12 22:24:19 +0000 URL: https://git.openjdk.org/loom/commit/98870472282a76be14acb2dfba483c97359dabba Merge Changeset: 19628e3e Author: Justin King Committer: Magnus Ihse Bursie Date: 2023-01-13 04:07:42 +0000 URL: https://git.openjdk.org/loom/commit/19628e3e0c5d24341cacf60b126070195c77216a 8300068: UBSan CFLAGS/LDFLAGS not passed when building ADLC Reviewed-by: ihse ! make/autoconf/jdk-options.m4 ! make/autoconf/spec.gmk.in ! make/hotspot/gensrc/GensrcAdlc.gmk Changeset: 640eff64 Author: Tobias Hartmann Date: 2023-01-13 07:16:53 +0000 URL: https://git.openjdk.org/loom/commit/640eff64d296cc34b7b3fd50dc7075ffe23a642f 8300040: TypeOopPtr::make_from_klass_common calls itself with args in wrong order Co-authored-by: David Simms Reviewed-by: chagedorn, kvn ! src/hotspot/share/opto/type.cpp Changeset: be8e6d05 Author: Matthias Baesken Date: 2023-01-13 07:57:38 +0000 URL: https://git.openjdk.org/loom/commit/be8e6d05db2f623626506e64a2fb7caf755d5d06 8299957: Enhance error logging in instrument coding with additional jplis_assert_msg Reviewed-by: sspitsyn ! src/java.instrument/share/native/libinstrument/InvocationAdapter.c ! src/java.instrument/share/native/libinstrument/JPLISAgent.c Changeset: ac63f5f8 Author: Markus Gr?nlund Date: 2023-01-13 12:11:09 +0000 URL: https://git.openjdk.org/loom/commit/ac63f5f8dd02b6af59c065add63ab4002fbc3e24 8297877: Risk for uninitialized memory in case of CHECK macro early return as part of field access Reviewed-by: ccheung, egahlin ! src/hotspot/share/jfr/jni/jfrJavaSupport.cpp ! src/hotspot/share/jfr/jni/jfrJavaSupport.hpp ! src/hotspot/share/jfr/recorder/repository/jfrChunkRotation.cpp Changeset: c2502228 Author: Stefan Karlsson Date: 2023-01-13 12:28:52 +0000 URL: https://git.openjdk.org/loom/commit/c250222880b815873f1b24119c58f9f9b50946a9 8300110: Unproblemlist Fuzz.java from ProblemList-zgc.txt Reviewed-by: aboldtch, tschatzl ! test/jdk/ProblemList-zgc.txt Changeset: e7fa150b Author: Erik ?sterlund Date: 2023-01-13 12:48:30 +0000 URL: https://git.openjdk.org/loom/commit/e7fa150bc15b1bf5ab8921bfdf1a628ae08f5624 8299032: Interface IN_NATIVE oop stores for C2 Reviewed-by: stefank, rcastanedalo ! src/hotspot/share/gc/shared/c2/barrierSetC2.cpp ! src/hotspot/share/opto/library_call.cpp Changeset: 3ffc9557 Author: Jie Fu Date: 2023-01-13 13:53:22 +0000 URL: https://git.openjdk.org/loom/commit/3ffc955783e56ed66a931f13c2688311596224e4 8300099: Configuration fails to auto-detect build user through $USER in dockers Reviewed-by: ihse ! make/autoconf/basic_tools.m4 ! make/autoconf/jdk-version.m4 Changeset: ce1193a1 Author: Per Minborg Date: 2023-01-13 15:19:12 +0000 URL: https://git.openjdk.org/loom/commit/ce1193a1edb3cdf20f9448ccbbfb053c2418074a 8299976: Initialize static fields in Net eagerly Reviewed-by: alanb ! src/java.base/share/classes/sun/nio/ch/Net.java Changeset: d1179795 Author: Albert Mingkun Yang Date: 2023-01-13 16:49:26 +0000 URL: https://git.openjdk.org/loom/commit/d1179795031ec1429850e2f835fc2abf173ac35a 8300054: Use static_assert in basic_types_init Reviewed-by: stefank, kbarrett ! src/hotspot/share/utilities/globalDefinitions.cpp Changeset: 4ec36598 Author: Eirik Bjorsnos Committer: Weijun Wang Date: 2023-01-13 17:55:07 +0000 URL: https://git.openjdk.org/loom/commit/4ec3659845486ee9f9227cdfb3f8b47f19462b19 8278349: JarSigner javadoc example uses SHA-1 Reviewed-by: weijun ! src/jdk.jartool/share/classes/jdk/security/jarsigner/JarSigner.java Changeset: 500b45e1 Author: Justin Lu Committer: Naoto Sato Date: 2023-01-13 18:13:50 +0000 URL: https://git.openjdk.org/loom/commit/500b45e12dccc254e2d1cbd9513653ae939ef349 8299865: Unnecessary NullPointerException catch in java.util.TimeZone#setDefaultZone Reviewed-by: lancea, iris, naoto, aturbanov ! src/java.base/share/classes/java/util/TimeZone.java Changeset: 8cb25d3d Author: Artem Semenov Date: 2023-01-13 19:39:56 +0000 URL: https://git.openjdk.org/loom/commit/8cb25d3de494c6d9357a1c199e1a9dbff9be9948 8298644: JNI call of getCurrentComponent on a wrong thread Reviewed-by: avu, serb, kizune ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CAccessibility.java ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/OutlineRowAccessibility.m ! src/java.desktop/share/classes/javax/swing/JTree.java ! src/java.desktop/share/classes/sun/swing/SwingAccessor.java Changeset: f4e119d5 Author: Chris Plummer Date: 2023-01-13 23:25:25 +0000 URL: https://git.openjdk.org/loom/commit/f4e119d5fcdf592f59a7d029070eba3878e24a7c 8300012: Remove unused JDI VirtualMachineImpl.removeObjectMirror(ObjectReferenceImpl object) method Reviewed-by: alanb, sspitsyn ! src/jdk.jdi/share/classes/com/sun/tools/jdi/VirtualMachineImpl.java Changeset: e0081462 Author: Gerard Ziemski Date: 2023-01-13 15:38:49 +0000 URL: https://git.openjdk.org/loom/commit/e0081462f456138b818a596099e2598cbe1648e0 8300055: [BACKOUT] OPEN_MAX is no longer the max limit on macOS >= 10.6 for RLIMIT_NOFILE Reviewed-by: tschatzl, rriggs ! src/hotspot/os/bsd/os_bsd.cpp Changeset: bc498f87 Author: Daniel D. Daugherty Date: 2023-01-13 22:55:08 +0000 URL: https://git.openjdk.org/loom/commit/bc498f87f7037c37ad9c2a101fee5e39ae6bfda1 8300141: ProblemList java/util/concurrent/locks/Lock/OOMEInAQS.java with ZGC 8300144: ProblemList vmTestbase/nsk/sysdict/vm/stress/chain/chain007/chain007.java with ZGC 8300147: ProblemList vmTestbase/nsk/jvmti/SetFieldModificationWatch/setfmodw001/TestDescription.java in Xcomp Reviewed-by: mikael ! test/hotspot/jtreg/ProblemList-Xcomp.txt ! test/hotspot/jtreg/ProblemList-zgc.txt ! test/jdk/ProblemList-zgc.txt Changeset: ab7f43f0 Author: Justin Lu Committer: Naoto Sato Date: 2023-01-13 23:14:14 +0000 URL: https://git.openjdk.org/loom/commit/ab7f43f0801eeb6b0514f5e8241404c13c04269d 8299498: Usage of constructors of primitive wrapper classes should be avoided in java.lang API docs Backport-of: d663b5da10be1f3f33a2729e4b3605fb5e13b4d6 ! src/java.base/share/classes/java/lang/ArrayStoreException.java ! src/java.base/share/classes/java/lang/Byte.java ! 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/Integer.java ! src/java.base/share/classes/java/lang/Long.java ! src/java.base/share/classes/java/lang/Short.java Changeset: 628266af Author: Justin Lu Committer: Naoto Sato Date: 2023-01-13 23:15:28 +0000 URL: https://git.openjdk.org/loom/commit/628266af60b054903fccd1582972acb2c998f1d4 8299501: Usage of constructors of primitive wrapper classes should be avoided in java.util API docs Backport-of: f36f1354c63a500c70ae51a9c2b2d21ad55cfa77 ! src/java.base/share/classes/java/util/Arrays.java Changeset: 98eae6da Author: Justin Lu Committer: Naoto Sato Date: 2023-01-13 23:16:48 +0000 URL: https://git.openjdk.org/loom/commit/98eae6dade075c6e58ad0379d0b3b38b75836994 8299500: Usage of constructors of primitive wrapper classes should be avoided in java.text API docs Reviewed-by: iris Backport-of: cd10c7278d8fcf7ce6713a3ee688bb1e10c024f6 ! src/java.base/share/classes/java/text/ChoiceFormat.java ! src/java.base/share/classes/java/text/MessageFormat.java Changeset: dc5cc616 Author: Justin Lu Committer: Naoto Sato Date: 2023-01-13 23:17:53 +0000 URL: https://git.openjdk.org/loom/commit/dc5cc61621ec6ad23e6107737b46276171d90622 8299499: Usage of constructors of primitive wrapper classes should be avoided in java.net API docs Backport-of: 63cf4aa0c897406fc9370a8e05cb035caafc5d69 ! src/java.base/share/classes/java/net/SocketOptions.java Changeset: 87865e0e Author: Justin Lu Committer: Naoto Sato Date: 2023-01-13 23:19:02 +0000 URL: https://git.openjdk.org/loom/commit/87865e0eb8af6a23263494f3397ee01c7eccb1b8 8299502: Usage of constructors of primitive wrapper classes should be avoided in javax.xml API docs Backport-of: b8852f65a0adcb9ee5693bb6727a0668aa9808bf ! src/java.xml/share/classes/javax/xml/stream/XMLOutputFactory.java Changeset: 4be94e43 Author: Jesper Wilhelmsson Date: 2023-01-14 01:57:13 +0000 URL: https://git.openjdk.org/loom/commit/4be94e435002d9d6cb594a393e9e35d650a9a0c9 Merge ! src/hotspot/os/bsd/os_bsd.cpp ! test/hotspot/jtreg/ProblemList-zgc.txt ! src/hotspot/os/bsd/os_bsd.cpp ! test/hotspot/jtreg/ProblemList-zgc.txt Changeset: 7bcd5f41 Author: Ioi Lam Date: 2023-01-15 20:30:31 +0000 URL: https://git.openjdk.org/loom/commit/7bcd5f418c399678e9459dc376c3ef061493b33f 8297914: Remove java_lang_Class::process_archived_mirror() Reviewed-by: ccheung ! src/hotspot/share/cds/heapShared.cpp ! src/hotspot/share/cds/heapShared.hpp ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/classfile/javaClasses.hpp ! src/hotspot/share/memory/universe.cpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/klass.cpp ! src/hotspot/share/oops/klass.hpp ! src/hotspot/share/runtime/mutexLocker.cpp ! src/hotspot/share/runtime/mutexLocker.hpp Changeset: 12edd6f9 Author: Julian Waters Date: 2023-01-16 06:07:38 +0000 URL: https://git.openjdk.org/loom/commit/12edd6f922195f193659814d6c37c361c83e6797 8300052: PdhDll::PdhCollectQueryData and PdhLookupPerfNameByIndex will never be NULL Reviewed-by: dholmes ! src/hotspot/os/windows/pdh_interface.cpp Changeset: fe7fca01 Author: Daniel Jeli?ski Date: 2023-01-16 06:56:43 +0000 URL: https://git.openjdk.org/loom/commit/fe7fca0128ca3a7b514c49d1508ca64499a8bb8e 8300032: DwarfParser resource leak Reviewed-by: cjplummer, sspitsyn ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/linux/amd64/DwarfParser.java Changeset: 50e7df91 Author: Daniel Jeli?ski Date: 2023-01-16 06:58:27 +0000 URL: https://git.openjdk.org/loom/commit/50e7df91c77d436937fff9134174ddb8a8dd4dd7 8300024: Replace use of JNI_COMMIT mode with mode 0 Reviewed-by: amenkov, sspitsyn, cjplummer ! src/jdk.hotspot.agent/linux/native/libsaproc/LinuxDebuggerLocal.cpp ! src/jdk.hotspot.agent/macosx/native/libsaproc/MacosxDebuggerLocal.m ! src/jdk.hotspot.agent/windows/native/libsaproc/sawindbg.cpp ! test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRetransform/libRedefineRetransform.cpp Changeset: 83f2c9a2 Author: Damon Fenacci Committer: Tobias Hartmann Date: 2023-01-16 07:34:11 +0000 URL: https://git.openjdk.org/loom/commit/83f2c9a2b290f11fbfb118a22c9667f26ac7c516 8293410: Remove GenerateRangeChecks flag Reviewed-by: thartmann, chagedorn, kvn ! src/hotspot/share/c1/c1_LIRGenerator.cpp ! src/hotspot/share/opto/parse2.cpp ! src/hotspot/share/runtime/globals.hpp Changeset: abfd7e89 Author: Aleksey Shipilev Date: 2023-01-16 08:49:02 +0000 URL: https://git.openjdk.org/loom/commit/abfd7e89f6ee03cdadf0adecd28c2672cf77d184 8300113: C2: Single-bit fields with signed type in TypePtr after JDK-8297933 Reviewed-by: roland, thartmann ! src/hotspot/share/opto/type.hpp Changeset: 7c1ebcc4 Author: Emanuel Peter Date: 2023-01-16 09:15:31 +0000 URL: https://git.openjdk.org/loom/commit/7c1ebcc4ce74bb06f7c911e59a86bcfb5c5da844 8299962: Speed up compiler/intrinsics/unsafe/DirectByteBufferTest.java and HeapByteBufferTest.java Reviewed-by: kvn, thartmann ! test/hotspot/jtreg/compiler/intrinsics/unsafe/DirectByteBufferTest.java ! test/hotspot/jtreg/compiler/intrinsics/unsafe/HeapByteBufferTest.java Changeset: 6fea233e Author: Emanuel Peter Date: 2023-01-16 09:17:31 +0000 URL: https://git.openjdk.org/loom/commit/6fea233e229188c193c03f7164104ed5f377ed0e 8299960: Speed up test/hotspot/jtreg/compiler/c2/irTests/TestVectorizeURShiftSubword.java Reviewed-by: thartmann, chagedorn, fgao ! test/hotspot/jtreg/compiler/c2/irTests/TestVectorizeURShiftSubword.java Changeset: cac72a60 Author: Aleksey Shipilev Date: 2023-01-16 09:32:04 +0000 URL: https://git.openjdk.org/loom/commit/cac72a60181d3570562f8534c691528d06e40cb8 8300053: Shenandoah: Handle more GCCauses in ShenandoahControlThread::request_gc Reviewed-by: wkemper, rkennke ! src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp Changeset: 98d75f18 Author: Bhavana Kilambi Committer: Nick Gasson Date: 2023-01-16 10:47:38 +0000 URL: https://git.openjdk.org/loom/commit/98d75f1879269ff337c28f8cb916212d417e2769 8299038: Add AArch64 backend support for auto-vectorized FP16 conversions Reviewed-by: xgong, ngasson ! src/hotspot/cpu/aarch64/aarch64_vector.ad ! src/hotspot/cpu/aarch64/aarch64_vector_ad.m4 ! src/hotspot/cpu/aarch64/assembler_aarch64.hpp ! test/hotspot/gtest/aarch64/aarch64-asmtest.py ! test/hotspot/gtest/aarch64/asmtest.out.h ! test/hotspot/jtreg/compiler/vectorization/TestFloatConversionsVector.java Changeset: a7342853 Author: Erik ?sterlund Date: 2023-01-16 10:54:10 +0000 URL: https://git.openjdk.org/loom/commit/a734285314a34ed61583132f2fc6be9d9c861af4 8299879: CollectedHeap hierarchy should use override Reviewed-by: stefank, tschatzl ! src/hotspot/share/gc/epsilon/epsilonHeap.hpp ! src/hotspot/share/gc/parallel/parallelScavengeHeap.hpp ! src/hotspot/share/gc/serial/serialHeap.hpp ! src/hotspot/share/gc/shared/genCollectedHeap.hpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp ! src/hotspot/share/gc/z/zCollectedHeap.hpp Changeset: a2f67660 Author: Manukumar V S Committer: Alexey Ivanov Date: 2023-01-16 12:18:51 +0000 URL: https://git.openjdk.org/loom/commit/a2f67660f088559ce49f73da7401801fb826028b 8288415: java/awt/PopupMenu/PopupMenuLocation.java is unstable in MacOS machines Reviewed-by: dnguyen, aivanov ! test/jdk/java/awt/PopupMenu/PopupMenuLocation.java Changeset: 289aed46 Author: Afshin Zafari Committer: Robbin Ehn Date: 2023-01-16 12:36:45 +0000 URL: https://git.openjdk.org/loom/commit/289aed465e9b8449938d4cdb515748e7aca1d070 8298128: runtime/ErrorHandling/TestSigInfoInHsErrFile.java fails to find pattern with slowdebug Reviewed-by: dcubed, dholmes, stuefe ! src/hotspot/share/utilities/vmError.cpp ! test/hotspot/jtreg/runtime/ErrorHandling/HsErrFileUtils.java Changeset: 319de6a6 Author: Albert Mingkun Yang Date: 2023-01-16 14:25:35 +0000 URL: https://git.openjdk.org/loom/commit/319de6a6d3c559419056a6148e0aab07ab6b43bc 8300124: Remove unnecessary assert in GenCollectedHeap::initialize Reviewed-by: stefank, tschatzl ! src/hotspot/share/gc/shared/genCollectedHeap.cpp Changeset: 506c8186 Author: Leo Korinth Date: 2023-01-16 16:36:36 +0000 URL: https://git.openjdk.org/loom/commit/506c81868997cdea656fb480ebe18d49ab0e075e 8296401: ConcurrentHashTable::bulk_delete might miss to delete some objects Reviewed-by: rehn, iwalulya, aboldtch ! src/hotspot/share/utilities/concurrentHashTable.hpp ! src/hotspot/share/utilities/concurrentHashTable.inline.hpp ! test/hotspot/gtest/utilities/test_concurrentHashtable.cpp Changeset: 4073b685 Author: Magnus Ihse Bursie Date: 2023-01-16 18:53:54 +0000 URL: https://git.openjdk.org/loom/commit/4073b68565f9d5283be96ee6b75bab686f076bea 8298047: Remove all non-significant trailing whitespace from properties files Reviewed-by: serb, rriggs ! src/demo/share/jfc/SwingSet2/resources/swingset.properties ! src/demo/share/jfc/SwingSet2/resources/swingset_de.properties ! src/demo/share/jfc/SwingSet2/resources/swingset_ja.properties ! src/demo/share/jfc/SwingSet2/resources/swingset_zh_CN.properties ! src/java.base/share/classes/sun/util/resources/CurrencyNames_en_US.properties ! src/java.datatransfer/macosx/classes/sun/datatransfer/resources/flavormap.properties ! src/java.datatransfer/unix/classes/sun/datatransfer/resources/flavormap.properties ! src/java.desktop/share/classes/com/sun/accessibility/internal/resources/accessibility.properties ! src/java.desktop/share/classes/com/sun/accessibility/internal/resources/accessibility_de.properties ! src/java.desktop/share/classes/com/sun/accessibility/internal/resources/accessibility_en.properties ! src/java.desktop/share/classes/com/sun/accessibility/internal/resources/accessibility_es.properties ! src/java.desktop/share/classes/com/sun/accessibility/internal/resources/accessibility_fr.properties ! src/java.desktop/share/classes/com/sun/accessibility/internal/resources/accessibility_it.properties ! src/java.desktop/share/classes/com/sun/accessibility/internal/resources/accessibility_ja.properties ! src/java.desktop/share/classes/com/sun/accessibility/internal/resources/accessibility_ko.properties ! src/java.desktop/share/classes/com/sun/accessibility/internal/resources/accessibility_pt_BR.properties ! src/java.desktop/share/classes/com/sun/accessibility/internal/resources/accessibility_sv.properties ! src/java.desktop/share/classes/com/sun/accessibility/internal/resources/accessibility_zh_CN.properties ! src/java.desktop/share/classes/com/sun/accessibility/internal/resources/accessibility_zh_TW.properties ! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/resources/motif.properties ! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/resources/motif_de.properties ! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/resources/motif_es.properties ! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/resources/motif_fr.properties ! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/resources/motif_it.properties ! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/resources/motif_ja.properties ! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/resources/motif_ko.properties ! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/resources/motif_pt_BR.properties ! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/resources/motif_sv.properties ! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/resources/motif_zh_CN.properties ! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/resources/motif_zh_TW.properties ! src/java.desktop/share/classes/sun/print/resources/serviceui.properties ! src/java.desktop/share/classes/sun/print/resources/serviceui_de.properties ! src/java.desktop/share/classes/sun/print/resources/serviceui_es.properties ! src/java.desktop/share/classes/sun/print/resources/serviceui_fr.properties ! src/java.desktop/share/classes/sun/print/resources/serviceui_it.properties ! src/java.desktop/share/classes/sun/print/resources/serviceui_ja.properties ! src/java.desktop/share/classes/sun/print/resources/serviceui_ko.properties ! src/java.desktop/share/classes/sun/print/resources/serviceui_pt_BR.properties ! src/java.desktop/share/classes/sun/print/resources/serviceui_sv.properties ! src/java.desktop/share/classes/sun/print/resources/serviceui_zh_CN.properties ! src/java.desktop/share/classes/sun/print/resources/serviceui_zh_TW.properties ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/resources/windows.properties ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/resources/windows_de.properties ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/resources/windows_es.properties ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/resources/windows_fr.properties ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/resources/windows_it.properties ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/resources/windows_ja.properties ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/resources/windows_ko.properties ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/resources/windows_pt_BR.properties ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/resources/windows_sv.properties ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/resources/windows_zh_CN.properties ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/resources/windows_zh_TW.properties ! src/java.desktop/windows/data/fontconfig/fontconfig.properties ! src/java.naming/share/classes/com/sun/jndi/ldap/jndiprovider.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_de.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_es.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_fr.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_it.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_ja.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_ko.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_pt_BR.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_sv.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_zh_CN.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_zh_TW.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_de.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_es.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_fr.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_it.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_ja.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_ko.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_pt_BR.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_sv.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_zh_CN.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_zh_TW.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_de.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_es.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_fr.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_it.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_ja.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_ko.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_pt_BR.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_sv.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_zh_CN.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_zh_TW.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CalendarData_el_CY.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CalendarData_en_MT.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CalendarData_es_US.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CalendarData_id_ID.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CalendarData_ms_MY.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CalendarData_mt.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CalendarData_mt_MT.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CalendarData_sr.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CalendarData_tr.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CalendarData_uk.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CalendarData_vi.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CalendarData_zh.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_ar_AE.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_ar_BH.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_ar_DZ.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_ar_EG.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_ar_IQ.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_ar_JO.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_ar_KW.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_ar_LB.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_ar_LY.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_ar_MA.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_ar_OM.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_ar_QA.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_ar_SA.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_ar_SD.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_ar_SY.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_ar_TN.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_ar_YE.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_be_BY.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_bg_BG.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_ca_ES.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_cs_CZ.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_da_DK.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_de_AT.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_de_CH.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_de_DE.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_de_LU.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_el_CY.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_el_GR.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_en_AU.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_en_CA.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_en_GB.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_en_IE.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_en_IN.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_en_MT.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_en_NZ.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_en_PH.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_en_SG.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_en_ZA.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_es_AR.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_es_BO.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_es_CL.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_es_CO.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_es_CR.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_es_DO.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_es_EC.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_es_ES.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_es_GT.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_es_HN.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_es_MX.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_es_NI.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_es_PA.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_es_PR.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_es_PY.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_es_SV.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_es_US.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_es_UY.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_es_VE.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_fi_FI.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_fr_BE.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_fr_CA.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_fr_CH.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_fr_FR.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_fr_LU.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_ga_IE.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_he_IL.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_hi_IN.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_hr_HR.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_hu_HU.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_id_ID.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_is_IS.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_it_CH.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_it_IT.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_ja_JP.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_ko_KR.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_lt_LT.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_lv_LV.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_mk_MK.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_ms_MY.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_mt_MT.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_nl_BE.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_nl_NL.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_no_NO.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_pl_PL.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_pt_BR.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_pt_PT.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_ro_RO.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_ru_RU.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_sl_SI.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_sq_AL.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_sr_BA.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_sr_CS.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_sr_ME.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_sv_SE.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_th_TH.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_tr_TR.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_uk_UA.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_vi_VN.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_el.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_el_CY.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_en_MT.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_en_PH.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_en_SG.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_es_US.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_ga.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_id.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_ms.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_mt.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_pt.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_pt_BR.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_pt_PT.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_sr.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_th.properties ! src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_zh_SG.properties ! test/jdk/java/util/PluggableLocale/providersrc/barprovider/com/bar/LocaleNames.properties ! test/jdk/java/util/PluggableLocale/providersrc/barprovider/com/bar/LocaleNames_ja.properties ! test/jdk/java/util/PluggableLocale/providersrc/barprovider/com/bar/LocaleNames_ja_JP_kyoto.properties ! test/jdk/java/util/PluggableLocale/providersrc/barprovider/com/bar/LocaleNames_ja_JP_osaka.properties ! test/jdk/java/util/PluggableLocale/providersrc/barprovider/com/bar/LocaleNames_xx.properties ! test/jdk/java/util/Properties/Bug6609431.properties ! test/jdk/java/util/ResourceBundle/Bug4083270Test.properties ! test/jdk/java/util/ResourceBundle/Bug4177489_Resource_jf_JF.properties ! test/jdk/java/util/ResourceBundle/Bug6190861Data.properties ! test/jdk/java/util/ResourceBundle/Bug6190861Data_en_US.properties ! test/jdk/java/util/ResourceBundle/Bug6204853.properties ! test/jdk/java/util/ResourceBundle/Bug6204853_Utf8.properties ! test/jdk/java/util/ResourceBundle/Bug6356571.properties ! test/jdk/java/util/ResourceBundle/Control/Bug6530694_de_DE.properties ! test/jdk/java/util/ResourceBundle/Control/Chinese.properties ! test/jdk/java/util/ResourceBundle/Control/Chinese_zh.properties ! test/jdk/java/util/ResourceBundle/Control/Chinese_zh_CN.properties ! test/jdk/java/util/ResourceBundle/Control/Chinese_zh_TW.properties ! test/jdk/java/util/ResourceBundle/Control/MalformedDataRB_en.properties ! test/jdk/java/util/ResourceBundle/Control/StressOut.properties ! test/jdk/java/util/ResourceBundle/Control/StressOut_en_CA.properties ! test/jdk/java/util/ResourceBundle/Control/StressOut_ja.properties ! test/jdk/java/util/ResourceBundle/Control/StressOut_ja_JP.properties ! test/jdk/java/util/ResourceBundle/Control/StressOut_ko.properties ! test/jdk/java/util/ResourceBundle/Control/StressOut_zh_CN.properties ! test/jdk/java/util/ResourceBundle/KeySetResources.properties ! test/jdk/java/util/ResourceBundle/KeySetResources_ja_JP.properties ! test/jdk/java/util/ResourceBundle/RB4353454_en.properties ! test/jdk/java/util/ResourceBundle/ReferencesTestBundle.properties ! test/jdk/java/util/ResourceBundle/Test4314141A.properties ! test/jdk/java/util/ResourceBundle/Test4314141A_.properties ! test/jdk/java/util/ResourceBundle/Test4314141A__DE.properties ! test/jdk/java/util/ResourceBundle/Test4314141A___EURO.properties ! test/jdk/java/util/ResourceBundle/Test4314141A_de.properties ! test/jdk/java/util/ResourceBundle/Test4314141A_de_.properties ! test/jdk/java/util/ResourceBundle/Test4314141B_en.properties ! test/jdk/java/util/ResourceBundle/Test4314141B_fr.properties ! test/jdk/java/util/ResourceBundle/Test4314141B_fr_CH.properties ! test/jdk/java/util/ResourceBundle/Test4318520RB_de.properties ! test/jdk/java/util/ResourceBundle/Test4318520RB_en.properties ! test/jdk/java/util/ResourceBundle/bug4195978Test.properties ! test/jdk/java/util/logging/bundlesearch/ClassPathTestBundle_en.properties ! test/jdk/java/util/logging/bundlesearch/resources/CallerSearchableResource_en.properties ! test/jdk/java/util/logging/bundlesearch/resources/ContextClassLoaderTestBundle_en.properties ! test/jdk/java/util/logging/bundlesearch/resources/StackSearchableResource_en.properties ! test/jdk/java/util/logging/modules/LogManagerInModule/logging.properties ! test/jdk/java/util/spi/ResourceBundleControlProvider/simple.properties ! test/jdk/javax/management/remote/mandatory/connection/mgmt1.properties ! test/jdk/javax/management/remote/mandatory/connection/mgmt2.properties ! test/jdk/sanity/client/TEST.properties ! test/jdk/sanity/client/lib/SwingSet2/src/resources/swingset.properties ! test/jdk/sun/management/LoggingTest/logging.properties Changeset: 4c1e66e0 Author: Justin King Committer: Kim Barrett Date: 2023-01-16 19:28:25 +0000 URL: https://git.openjdk.org/loom/commit/4c1e66e0abe9e379926e555bd651e9fcc5a0e8b6 8299971: Remove metaprogramming/conditional.hpp Reviewed-by: tschatzl, kbarrett ! src/hotspot/share/gc/shared/oopStorage.inline.hpp ! src/hotspot/share/gc/shared/oopStorageParState.hpp ! src/hotspot/share/gc/shared/oopStorageParState.inline.hpp - src/hotspot/share/metaprogramming/conditional.hpp ! src/hotspot/share/oops/accessBackend.hpp ! src/hotspot/share/runtime/atomic.hpp ! src/hotspot/share/runtime/continuationFreezeThaw.cpp ! src/hotspot/share/utilities/moveBits.hpp ! src/hotspot/share/utilities/population_count.hpp ! test/hotspot/gtest/gc/shared/test_oopStorage.cpp - test/hotspot/gtest/metaprogramming/test_conditional.cpp Changeset: f52f6e65 Author: Justin King Committer: Kim Barrett Date: 2023-01-16 19:30:16 +0000 URL: https://git.openjdk.org/loom/commit/f52f6e65fba0360d3cf114e19fea402ab0d65eba 8299972: Remove metaprogramming/removeReference.hpp Reviewed-by: tschatzl, kbarrett - src/hotspot/share/metaprogramming/removeReference.hpp - test/hotspot/gtest/metaprogramming/test_removeReference.cpp Changeset: 240830df Author: Hao Sun Date: 2023-01-17 02:07:43 +0000 URL: https://git.openjdk.org/loom/commit/240830df7eaa04e0056e9585ebdbf6b02e8b747c 8297092: [macos_aarch64] Add support for SHA feature detection Reviewed-by: njian, aph, gziemski ! src/hotspot/cpu/aarch64/vm_version_aarch64.cpp ! src/hotspot/os_cpu/bsd_aarch64/vm_version_bsd_aarch64.cpp Changeset: 859ccd1a Author: Fei Yang Date: 2023-01-17 03:06:57 +0000 URL: https://git.openjdk.org/loom/commit/859ccd1a150653c42ebbcd3402994ef9ff4c810f 8299847: RISC-V: Improve PrintOptoAssembly output of CMoveI/L nodes Reviewed-by: fjiang, shade ! src/hotspot/cpu/riscv/riscv.ad Changeset: 06f9374e Author: Matthew Donovan Committer: Julian Waters Date: 2023-01-17 04:41:55 +0000 URL: https://git.openjdk.org/loom/commit/06f9374e0c59fa666e6f120749d9170f65fadc4f 8298867: Basics.java fails with SSL handshake exception Reviewed-by: xuelei, rhalade ! test/jdk/ProblemList.txt ! test/jdk/javax/net/ssl/SSLEngine/Basics.java Changeset: 382fe51b Author: Archie L. Cobbs Committer: Julian Waters Date: 2023-01-17 04:43:40 +0000 URL: https://git.openjdk.org/loom/commit/382fe51b6d7eba7094afa070032bedaa9ffc0633 8163229: several regression tests have a main method that is never executed Reviewed-by: vromero ! test/langtools/tools/javac/4980495/static/Test.java ! test/langtools/tools/javac/4980495/std/Test.java ! test/langtools/tools/javac/6491592/T6491592.java ! test/langtools/tools/javac/6857948/T6857948.java ! test/langtools/tools/javac/8062359/UnresolvableClassNPEInAttrTest.java ! test/langtools/tools/javac/8161985/T8161985a.java ! test/langtools/tools/javac/8238735/T8238735.java ! test/langtools/tools/javac/AnonymousClass/AnonymousInSuperCallNegTest.java ! test/langtools/tools/javac/BreakAcrossClass.java ! test/langtools/tools/javac/CaptureInSubtype.java ! test/langtools/tools/javac/DefiniteAssignment/DASwitch.java ! test/langtools/tools/javac/DefiniteAssignment/DUParam1.java ! test/langtools/tools/javac/DefiniteAssignment/DefAssignAfterTry1.java ! test/langtools/tools/javac/DefiniteAssignment/DefAssignAfterTry2.java ! test/langtools/tools/javac/DefiniteAssignment/DefAssignAfterTry3.java ! test/langtools/tools/javac/DefiniteAssignment/T4717164.java ! test/langtools/tools/javac/DefiniteAssignment/T4718142.java ! test/langtools/tools/javac/DefiniteAssignment/T4718142a.java ! test/langtools/tools/javac/DefiniteAssignment/UncaughtException.java ! test/langtools/tools/javac/OverrideChecks/T4721069.java ! test/langtools/tools/javac/ParseConditional.java ! test/langtools/tools/javac/SwitchScope.java ! test/langtools/tools/javac/SynthName2.java ! test/langtools/tools/javac/T5003235/T5003235b.java ! test/langtools/tools/javac/T6306967.java ! test/langtools/tools/javac/T6326754.java ! test/langtools/tools/javac/T6379327.java ! test/langtools/tools/javac/T6407257.java ! test/langtools/tools/javac/TryWithResources/BadTwr.java ! test/langtools/tools/javac/TryWithResources/BadTwr.out ! test/langtools/tools/javac/TryWithResources/BadTwrSyntax.java ! test/langtools/tools/javac/TryWithResources/DuplicateResourceDecl.java ! test/langtools/tools/javac/TryWithResources/DuplicateResourceDecl.out ! test/langtools/tools/javac/TryWithResources/ImplicitFinal.java ! test/langtools/tools/javac/TryWithResources/PlainTry.java ! test/langtools/tools/javac/TryWithResources/T7022711.java ! test/langtools/tools/javac/TryWithResources/TwrAndLambda.java ! test/langtools/tools/javac/TryWithResources/TwrFlow.java ! test/langtools/tools/javac/TryWithResources/TwrForVariable2.java ! test/langtools/tools/javac/TryWithResources/TwrForVariable3.java ! test/langtools/tools/javac/TryWithResources/TwrForVariable4.java ! test/langtools/tools/javac/TryWithResources/TwrOnNonResource.java ! test/langtools/tools/javac/TryWithResources/TwrVarKinds.java ! test/langtools/tools/javac/TryWithResources/TwrVarRedeclaration.java ! test/langtools/tools/javac/TryWithResources/TwrVarRedeclaration.out ! test/langtools/tools/javac/UseEnum.java ! test/langtools/tools/javac/annotations/neg/Cycle3.java ! test/langtools/tools/javac/annotations/typeAnnotations/failures/StaticFields.java ! test/langtools/tools/javac/annotations/typeAnnotations/failures/target/DotClass.java ! test/langtools/tools/javac/capture/Martin.java ! test/langtools/tools/javac/defaultMethods/private/Private06.java ! test/langtools/tools/javac/defaultMethods/static/Static02.java ! test/langtools/tools/javac/depDocComment/DeprecatedDocComment.java ! test/langtools/tools/javac/generics/6245699/T6245699b.java ! test/langtools/tools/javac/generics/6413682/T6413682.java ! test/langtools/tools/javac/generics/6495506/T6495506.java ! test/langtools/tools/javac/generics/6723444/T6723444.java ! test/langtools/tools/javac/generics/GetClass.java ! test/langtools/tools/javac/generics/Nonlinear.java ! test/langtools/tools/javac/generics/UnsoundInference.java ! test/langtools/tools/javac/generics/diamond/neg/Neg08.java ! test/langtools/tools/javac/generics/diamond/neg/Neg13.java ! test/langtools/tools/javac/generics/diamond/neg/Neg14.java ! test/langtools/tools/javac/generics/diamond/neg/Neg15.java ! test/langtools/tools/javac/generics/diamond/neg/Neg17.java ! test/langtools/tools/javac/generics/diamond/neg/Neg18.java ! test/langtools/tools/javac/generics/diamond/neg/Neg19.java ! test/langtools/tools/javac/generics/inference/4972073/T4972073.java ! test/langtools/tools/javac/generics/inference/5081782/Neg.java ! test/langtools/tools/javac/generics/odersky/BadTest.java ! test/langtools/tools/javac/generics/odersky/BadTest3.java ! test/langtools/tools/javac/generics/typeargs/Metharg1.java ! test/langtools/tools/javac/generics/typeargs/Metharg2.java ! test/langtools/tools/javac/generics/typeargs/Newarg1.java ! test/langtools/tools/javac/generics/typeargs/Newarg2.java ! test/langtools/tools/javac/generics/typeargs/Superarg1.java ! test/langtools/tools/javac/generics/typeargs/Superarg2.java ! test/langtools/tools/javac/generics/typeargs/ThisArg.java ! test/langtools/tools/javac/generics/wildcards/6437894/T6437894.java ! test/langtools/tools/javac/generics/wildcards/AssignmentDifferentTypes.java ! test/langtools/tools/javac/generics/wildcards/AssignmentSameType.java ! test/langtools/tools/javac/generics/wildcards/T6450290.java ! test/langtools/tools/javac/implicitThis/NewBeforeOuterConstructed2.java ! test/langtools/tools/javac/lambda/8071432/T8071432.java ! test/langtools/tools/javac/lambda/LambdaConv10.java ! test/langtools/tools/javac/lambda/MethodReference20.java ! test/langtools/tools/javac/lambda/MethodReference25.java ! test/langtools/tools/javac/lambda/MethodReference41.java ! test/langtools/tools/javac/lambda/MethodReference42.java ! test/langtools/tools/javac/lambda/MethodReference43.java ! test/langtools/tools/javac/lambda/MethodReference44.java ! test/langtools/tools/javac/lambda/MethodReference46.java ! test/langtools/tools/javac/lambda/MethodReference47.java ! test/langtools/tools/javac/lambda/MethodReference48.java ! test/langtools/tools/javac/lambda/MethodReference60.java ! test/langtools/tools/javac/lambda/MostSpecific04.java ! test/langtools/tools/javac/lambda/MostSpecific05.java ! test/langtools/tools/javac/lambda/funcInterfaces/LambdaTest2_neg1.java ! test/langtools/tools/javac/lambda/methodReference/MethodRefIntColonColonNewTest.java ! test/langtools/tools/javac/lambda/methodReference/MethodRefToInnerWithoutOuter.java ! test/langtools/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestVarHandle_neg.java ! test/langtools/tools/javac/lambda/typeInference/InferenceTest_neg1_2.java ! test/langtools/tools/javac/limits/ArrayDims1.java ! test/langtools/tools/javac/limits/ArrayDims2.java ! test/langtools/tools/javac/limits/ArrayDims3.java ! test/langtools/tools/javac/limits/ArrayDims4.java ! test/langtools/tools/javac/limits/PoolSize2.java ! test/langtools/tools/javac/limits/StringLength.java ! test/langtools/tools/javac/nested/5009484/X.java ! test/langtools/tools/javac/overload/T5090220.java ! test/langtools/tools/javac/patterns/BindingsTest1Merging.java ! test/langtools/tools/javac/patterns/BindingsTest2.java ! test/langtools/tools/javac/patterns/CastConversionMatch.java ! test/langtools/tools/javac/patterns/DeconstructionPatternErrors.java ! test/langtools/tools/javac/patterns/DeconstructionPatternErrors.out ! test/langtools/tools/javac/patterns/EnsureTypesOrderTest.java ! test/langtools/tools/javac/patterns/ImpossibleTypeTest.java ! test/langtools/tools/javac/patterns/MatchBindingScopeTest.java ! test/langtools/tools/javac/patterns/NullsInPatterns.java ! test/langtools/tools/javac/patterns/PatternVariablesAreNonFinal.java ! test/langtools/tools/javac/patterns/UncheckedWarningOnMatchesTest.java ! test/langtools/tools/javac/scope/6225935/Estatico4.java ! test/langtools/tools/javac/staticImport/ImportPrivate.java ! test/langtools/tools/javac/switchexpr/DefiniteAssignment2.java ! test/langtools/tools/javac/switchexpr/ExpressionSwitchUnreachable.java ! test/langtools/tools/javac/switchextra/DefiniteAssignment2.java ! test/langtools/tools/javac/unicode/NonasciiDigit.java ! test/langtools/tools/javac/varargs/6313164/T7175433.java ! test/langtools/tools/javac/varargs/Warn2.java Changeset: 8365c677 Author: Tejesh R Date: 2023-01-17 04:44:42 +0000 URL: https://git.openjdk.org/loom/commit/8365c6775cb3d2e15c4849f0ba69dc49bad2cf6a 8300084: AquaFileChooserUI.getDefaultButton returns null Reviewed-by: aivanov, serb ! src/java.desktop/macosx/classes/com/apple/laf/AquaFileChooserUI.java Changeset: 6a81d528 Author: Afshin Zafari Committer: David Holmes Date: 2023-01-17 05:44:41 +0000 URL: https://git.openjdk.org/loom/commit/6a81d528e89de73183d6b51c9c366c85ae594d9d 8299213: Bad cast in GrowableArrayWithAllocator<>::grow Reviewed-by: kbarrett, jsjolen, jwaters ! src/hotspot/share/utilities/growableArray.hpp Changeset: f829a679 Author: Hao Sun Date: 2023-01-17 06:43:58 +0000 URL: https://git.openjdk.org/loom/commit/f829a67935328824d2465d9073107cda7eaaf216 8300227: [macos_aarch64] assert(cpu_has("hw.optional.arm.FEAT_AES")) failed after JDK-8297092 Reviewed-by: dholmes ! src/hotspot/os_cpu/bsd_aarch64/vm_version_bsd_aarch64.cpp Changeset: 3462438a Author: Per Minborg Date: 2023-01-17 07:44:26 +0000 URL: https://git.openjdk.org/loom/commit/3462438ae1bc469243096abeb5adbe007ef14fe5 8299576: Reimplement java.io.Bits using VarHandle access Reviewed-by: uschindler, alanb ! src/java.base/share/classes/java/io/Bits.java + test/jdk/java/io/Bits/ReadWriteValues.java + test/jdk/java/io/Bits/java.base/java/io/BitsProxy.java Changeset: 9a36f8aa Author: Erik ?sterlund Date: 2023-01-17 08:00:56 +0000 URL: https://git.openjdk.org/loom/commit/9a36f8aadb08f8ade578530c70d9abe38f1826c6 8299673: Simplify object pinning interactions with string deduplication Co-authored-by: Stefan Karlsson Co-authored-by: Axel Boldt-Christmas Reviewed-by: kbarrett, stefank, dholmes ! src/hotspot/share/gc/epsilon/epsilonHeap.hpp ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1CollectedHeap.hpp ! src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp ! src/hotspot/share/gc/parallel/parallelScavengeHeap.hpp ! src/hotspot/share/gc/serial/serialHeap.cpp ! src/hotspot/share/gc/serial/serialHeap.hpp ! src/hotspot/share/gc/shared/collectedHeap.cpp ! src/hotspot/share/gc/shared/collectedHeap.hpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp ! src/hotspot/share/gc/z/zCollectedHeap.cpp ! src/hotspot/share/gc/z/zCollectedHeap.hpp ! src/hotspot/share/prims/jni.cpp Changeset: e82dc693 Author: Matthias Baesken Date: 2023-01-17 08:21:12 +0000 URL: https://git.openjdk.org/loom/commit/e82dc6935b5f575a53fcba9c96767cee1b535cb8 8300205: Swing test bug8078268 make latch timeout configurable Reviewed-by: aivanov, serb ! test/jdk/javax/swing/text/html/parser/Parser/8078268/bug8078268.java Changeset: 07d57531 Author: Abhishek Kumar Committer: Tejesh R Date: 2023-01-17 10:40:19 +0000 URL: https://git.openjdk.org/loom/commit/07d57531726092a003d4c5d4febd33e35e02a1a7 8300168: Typo in AccessibleJTableHeaderEntry javadoc Reviewed-by: psadhukhan, tr ! src/java.desktop/share/classes/javax/swing/table/JTableHeader.java Changeset: b7fb8ef8 Author: Erik ?sterlund Date: 2023-01-17 12:16:05 +0000 URL: https://git.openjdk.org/loom/commit/b7fb8ef89edf21ab1d6197ca8aff5a421d82c74c 8299323: Allow extended registers for cmpw Reviewed-by: sviswanathan, kvn ! src/hotspot/cpu/x86/assembler_x86.cpp Changeset: e15bdc58 Author: Sergey Bylokhov Date: 2023-01-14 04:19:54 +0000 URL: https://git.openjdk.org/loom/commit/e15bdc58abdac131c635de80440006f48c303b3f 8299789: Compilation of gtest causes build to fail if runtime libraries are in different dirs Reviewed-by: erikj Backport-of: c8a8388aba3dc121bad04aaa123f6cd7525c3d38 ! make/hotspot/test/GtestImage.gmk Changeset: 85d70acc Author: Jesper Wilhelmsson Date: 2023-01-17 13:19:14 +0000 URL: https://git.openjdk.org/loom/commit/85d70acc6e5b9f394d446c270f15bb3793916e63 Merge Changeset: 4cd166ff Author: Albert Mingkun Yang Date: 2023-01-17 15:41:23 +0000 URL: https://git.openjdk.org/loom/commit/4cd166ff27c1e03a61855664f61dda4fca9aa5c9 8300125: Serial: Remove unused Generation::reset_saved_marks Reviewed-by: kbarrett, lkorinth ! src/hotspot/share/gc/serial/defNewGeneration.cpp ! src/hotspot/share/gc/serial/defNewGeneration.hpp ! src/hotspot/share/gc/serial/tenuredGeneration.cpp ! src/hotspot/share/gc/serial/tenuredGeneration.hpp ! src/hotspot/share/gc/shared/generation.hpp Changeset: fb147aae Author: Alan Bateman Date: 2023-01-17 16:25:11 +0000 URL: https://git.openjdk.org/loom/commit/fb147aaea1593e8a13d562d15994f67cdde3eb35 8300228: ModuleReader.find on exploded module throws if resource name maps to invalid file path Reviewed-by: jpai, chegar, cstein ! src/java.base/share/classes/jdk/internal/module/Resources.java ! test/jdk/java/lang/module/ModuleReader/ModuleReaderTest.java Changeset: e139ec3d Author: Justin King Committer: Magnus Ihse Bursie Date: 2023-01-17 16:59:31 +0000 URL: https://git.openjdk.org/loom/commit/e139ec3db24f68c9907742b530069192a4eec3f3 8300069: Left shift of negative value in share/adlc/dict2.cpp Reviewed-by: ihse, kbarrett ! make/autoconf/jdk-options.m4 Changeset: 75b122fe Author: Magnus Ihse Bursie Date: 2023-01-17 17:00:46 +0000 URL: https://git.openjdk.org/loom/commit/75b122feeae60c38076883b27b173c1cafcacdf5 8300120: Configure should support different defaults for CI/dev build environments Reviewed-by: erikj ! .github/workflows/build-linux.yml ! .github/workflows/build-macos.yml ! .github/workflows/build-windows.yml ! make/autoconf/basic.m4 ! make/autoconf/configure.ac ! make/autoconf/lib-tests.m4 ! make/conf/jib-profiles.js Changeset: 0b9ff06f Author: Xin Liu Date: 2023-01-17 17:09:25 +0000 URL: https://git.openjdk.org/loom/commit/0b9ff06f3a72d26d64cdc43f9991005bba2aedba 8300184: Optimize ResourceHashtableBase::iterate_all using _number_of_entries Reviewed-by: dholmes, rehn ! src/hotspot/share/utilities/resourceHash.hpp Changeset: e7e37121 Author: Naoto Sato Date: 2023-01-17 17:25:44 +0000 URL: https://git.openjdk.org/loom/commit/e7e371212163ba6a56a9a365c662da3fa1a0fe47 8300010: UnsatisfiedLinkError on calling System.console().readPassword() on Windows Reviewed-by: alanb ! src/java.base/windows/native/libjava/Console_md.c + src/java.base/windows/native/libjava/JdkConsoleImpl_md.c Changeset: 8c12ae86 Author: SWinxy Committer: Alexey Ivanov Date: 2023-01-17 17:30:25 +0000 URL: https://git.openjdk.org/loom/commit/8c12ae867350a866a6a110ea85d86404f1efb0fb 8283203: Fix typo in SystemTray.getTrayIconSize javadoc Reviewed-by: aivanov ! src/java.desktop/share/classes/java/awt/SystemTray.java Changeset: d7c05d18 Author: Justin Lu Committer: Naoto Sato Date: 2023-01-17 18:30:32 +0000 URL: https://git.openjdk.org/loom/commit/d7c05d18700e512722aee078c049389733f87867 8300011: Refactor code examples to use @snippet in java.util.TimeZone Reviewed-by: lancea, naoto, iris ! src/java.base/share/classes/java/util/TimeZone.java Changeset: ade08e19 Author: Justin Lu Committer: Naoto Sato Date: 2023-01-17 19:40:41 +0000 URL: https://git.openjdk.org/loom/commit/ade08e190cc28cf0ce0194fa3fb67e48dc634e07 8300093: Refactor code examples to use @snippet in java.text.MessageFormat Reviewed-by: iris, naoto ! src/java.base/share/classes/java/text/MessageFormat.java Changeset: e37078f5 Author: Claes Redestad Date: 2023-01-17 21:06:22 +0000 URL: https://git.openjdk.org/loom/commit/e37078f5bb626c7ce0348a38bb86ca2ca62ba915 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops Co-authored-by: Sandhya Viswanathan Co-authored-by: Ludovic Henry Co-authored-by: Claes Redestad Reviewed-by: vlivanov, sviswanathan, luhenry ! src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp ! src/hotspot/cpu/x86/c2_MacroAssembler_x86.hpp ! src/hotspot/cpu/x86/stubRoutines_x86.cpp ! src/hotspot/cpu/x86/stubRoutines_x86.hpp ! src/hotspot/cpu/x86/vm_version_x86.cpp ! src/hotspot/cpu/x86/x86_64.ad ! src/hotspot/share/adlc/formssel.cpp ! src/hotspot/share/classfile/vmIntrinsics.cpp ! src/hotspot/share/classfile/vmIntrinsics.hpp ! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp ! src/hotspot/share/opto/c2compiler.cpp ! src/hotspot/share/opto/classes.hpp ! src/hotspot/share/opto/escape.cpp ! src/hotspot/share/opto/intrinsicnode.cpp ! src/hotspot/share/opto/intrinsicnode.hpp ! src/hotspot/share/opto/lcm.cpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/opto/library_call.hpp ! src/hotspot/share/opto/loopTransform.cpp ! src/hotspot/share/opto/loopnode.cpp ! src/hotspot/share/opto/matcher.cpp ! src/hotspot/share/runtime/globals.hpp ! src/java.base/share/classes/java/lang/StringLatin1.java ! src/java.base/share/classes/java/lang/StringUTF16.java ! src/java.base/share/classes/java/lang/System.java ! src/java.base/share/classes/java/util/Arrays.java ! src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java ! src/java.base/share/classes/jdk/internal/util/ArraysSupport.java + test/jdk/java/lang/String/HashCode.java + test/jdk/java/util/Arrays/HashCode.java ! test/jdk/javax/net/ssl/SSLEngine/Arrays.java ! test/micro/org/openjdk/bench/java/lang/StringHashCode.java + test/micro/org/openjdk/bench/java/util/ArraysHashCode.java Changeset: 00b6c551 Author: Justin King Committer: Magnus Ihse Bursie Date: 2023-01-17 21:53:34 +0000 URL: https://git.openjdk.org/loom/commit/00b6c551ec4254ff9adf9749f5eb3980af3ddb3d 8300254: ASan build does not correctly propagate ASAN_OPTIONS Reviewed-by: ihse ! make/autoconf/jdk-options.m4 ! make/autoconf/spec.gmk.in ! make/common/modules/LauncherCommon.gmk + make/data/asan/asan_default_options.c Changeset: f9883fc4 Author: Joe Darcy Date: 2023-01-17 22:17:34 +0000 URL: https://git.openjdk.org/loom/commit/f9883fc45b3bf5fc6e104491d24f7303802f8dbd 8300279: Use generalized see and link tags in core libs in client libs Reviewed-by: aivanov, prr ! src/java.desktop/share/classes/java/awt/Shape.java Changeset: 1d8b87dd Author: Joe Darcy Date: 2023-01-17 22:19:30 +0000 URL: https://git.openjdk.org/loom/commit/1d8b87dda4f0e40b02dd025fb5fa9d0a75fc9f90 8300321: Use link tags in javax.sql.rowset package-info Reviewed-by: lancea, iris ! src/java.sql.rowset/share/classes/javax/sql/rowset/package-info.java Changeset: 7071397e Author: Jonathan Gibbons Date: 2023-01-17 23:43:35 +0000 URL: https://git.openjdk.org/loom/commit/7071397ed92fb70a52723b4b753c943c010e0fb2 8299224: TestReporterStreams.java has bad indentation for legal header Reviewed-by: prappo ! test/langtools/jdk/javadoc/doclet/testReporterStreams/TestReporterStreams.java Changeset: 89a032dc Author: Sergey Kuksenko Date: 2023-01-18 00:16:34 +0000 URL: https://git.openjdk.org/loom/commit/89a032dc057d04c996632ad317a0303cf3560852 8300002: Performance regression caused by non-inlined hot methods due to post call noop instructions Reviewed-by: kvn, iveresov, eosterlund ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp ! src/hotspot/cpu/ppc/macroAssembler_ppc.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! src/hotspot/share/asm/assembler.hpp ! src/hotspot/share/asm/codeBuffer.cpp ! src/hotspot/share/asm/codeBuffer.hpp ! src/hotspot/share/ci/ciMethod.cpp ! src/hotspot/share/ci/ciMethod.hpp ! src/hotspot/share/ci/ciReplay.cpp ! src/hotspot/share/code/compiledMethod.hpp ! src/hotspot/share/code/nmethod.cpp ! src/hotspot/share/code/nmethod.hpp ! src/hotspot/share/opto/bytecodeInfo.cpp ! src/hotspot/share/runtime/vmStructs.cpp Changeset: f1194dc0 Author: Fei Yang Date: 2023-01-18 01:14:47 +0000 URL: https://git.openjdk.org/loom/commit/f1194dc07ec347f4f9d785e7647983da61441c0e 8300109: RISC-V: Improve code generation for MinI/MaxI nodes Reviewed-by: fjiang, luhenry, shade ! src/hotspot/cpu/riscv/riscv.ad Changeset: 1f438a8a Author: Ramkumar Sunderbabu Committer: Fairoz Matte Date: 2023-01-18 06:53:04 +0000 URL: https://git.openjdk.org/loom/commit/1f438a8a702034c2f10c0008e72395f526b15ef5 8282651: ZGC: vmTestbase/gc/ArrayJuggle/ tests fails intermittently with exit code 97 Reviewed-by: lmesnik ! test/hotspot/jtreg/vmTestbase/gc/ArrayJuggle/Juggle01/Juggle01.java ! test/hotspot/jtreg/vmTestbase/gc/ArrayJuggle/Juggle02/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/ArrayJuggle/Juggle03/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/ArrayJuggle/Juggle04/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/ArrayJuggle/Juggle05/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/ArrayJuggle/Juggle06/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/ArrayJuggle/Juggle07/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/ArrayJuggle/Juggle08/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/ArrayJuggle/Juggle09/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/ArrayJuggle/Juggle10/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/ArrayJuggle/Juggle11/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/ArrayJuggle/Juggle12/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/ArrayJuggle/Juggle13/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/ArrayJuggle/Juggle14/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/ArrayJuggle/Juggle15/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/ArrayJuggle/Juggle16/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/ArrayJuggle/Juggle17/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/ArrayJuggle/Juggle18/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/ArrayJuggle/Juggle19/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/ArrayJuggle/Juggle20/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/ArrayJuggle/Juggle21/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/ArrayJuggle/Juggle22/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/ArrayJuggle/Juggle23/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/ArrayJuggle/Juggle24/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/ArrayJuggle/Juggle25/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/ArrayJuggle/Juggle26/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/ArrayJuggle/Juggle27/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/ArrayJuggle/Juggle28/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/ArrayJuggle/Juggle29/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/ArrayJuggle/Juggle30/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/ArrayJuggle/Juggle31/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/ArrayJuggle/Juggle32/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/ArrayJuggle/Juggle33/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/ArrayJuggle/Juggle34/TestDescription.java Changeset: 66f7387b Author: Tobias Hartmann Date: 2023-01-18 08:15:19 +0000 URL: https://git.openjdk.org/loom/commit/66f7387b5ffa53861b92b068fb9832fc433d9f79 8299074: nmethod marked for deoptimization is not deoptimized Reviewed-by: eosterlund, rehn, kvn ! src/hotspot/share/code/dependencyContext.cpp Changeset: c7056737 Author: Axel Boldt-Christmas Date: 2023-01-18 09:21:08 +0000 URL: https://git.openjdk.org/loom/commit/c7056737e33d3d5a6ec24639d46b9e3e7a8da01a 8299089: Instrument global jni handles with tag to make them distinguishable Co-authored-by: Stefan Karlsson Co-authored-by: Martin Doerr Co-authored-by: Leslie Zhai Reviewed-by: eosterlund, stefank, ayang ! src/hotspot/cpu/aarch64/gc/shared/barrierSetAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp ! src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp ! src/hotspot/cpu/arm/jniFastGetField_arm.cpp ! src/hotspot/cpu/arm/macroAssembler_arm.cpp ! src/hotspot/cpu/arm/macroAssembler_arm.hpp ! src/hotspot/cpu/arm/stubGenerator_arm.cpp ! src/hotspot/cpu/ppc/gc/g1/g1BarrierSetAssembler_ppc.cpp ! src/hotspot/cpu/ppc/gc/shared/barrierSetAssembler_ppc.cpp ! src/hotspot/cpu/ppc/gc/shared/barrierSetAssembler_ppc.hpp ! src/hotspot/cpu/ppc/gc/shared/modRefBarrierSetAssembler_ppc.cpp ! src/hotspot/cpu/ppc/macroAssembler_ppc.cpp ! src/hotspot/cpu/ppc/macroAssembler_ppc.hpp ! src/hotspot/cpu/ppc/stubGenerator_ppc.cpp ! src/hotspot/cpu/riscv/gc/shared/barrierSetAssembler_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/s390/gc/g1/g1BarrierSetAssembler_s390.cpp ! src/hotspot/cpu/s390/gc/shared/barrierSetAssembler_s390.cpp ! src/hotspot/cpu/x86/gc/shared/barrierSetAssembler_x86.cpp ! src/hotspot/cpu/x86/jniFastGetField_x86_32.cpp ! src/hotspot/cpu/x86/jniFastGetField_x86_64.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.hpp ! src/hotspot/cpu/x86/stubGenerator_x86_32.cpp ! src/hotspot/cpu/x86/stubGenerator_x86_64.cpp ! src/hotspot/share/code/nmethod.cpp ! src/hotspot/share/compiler/compileTask.cpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/runtime/jniHandles.cpp ! src/hotspot/share/runtime/jniHandles.hpp ! src/hotspot/share/runtime/jniHandles.inline.hpp ! test/hotspot/jtreg/runtime/jni/FastGetField/FastGetField.java ! test/hotspot/jtreg/runtime/jni/FastGetField/libFastGetField.c Changeset: 7c8b99ee Author: Daniel Jeli?ski Date: 2023-01-18 09:29:04 +0000 URL: https://git.openjdk.org/loom/commit/7c8b99eedb46890c06af3b8e698b3ba169475231 8300117: Replace use of JNI_COMMIT mode with mode 0 Reviewed-by: serb, prr ! src/java.desktop/macosx/native/libawt_lwawt/awt/CClipboard.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CDropTarget.m Changeset: d9180423 Author: Robbin Ehn Date: 2023-01-18 10:23:11 +0000 URL: https://git.openjdk.org/loom/commit/d9180423b8c7dbe30b60ec844f389a80a1f0b551 8300267: Remove duplicated setter/getter for do_not_unlock Reviewed-by: coleenp, dholmes ! src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp ! src/hotspot/share/runtime/javaThread.hpp Changeset: 15a9186d Author: Jie Fu Date: 2023-01-18 10:32:00 +0000 URL: https://git.openjdk.org/loom/commit/15a9186db251f4be7a13e173842ac1bd858f984d 8300169: Build failure with clang-15 Reviewed-by: dholmes, prr ! make/hotspot/lib/CompileJvm.gmk ! make/modules/java.base/lib/CoreLibraries.gmk ! make/modules/java.desktop/lib/Awt2dLibraries.gmk ! src/hotspot/share/oops/generateOopMap.cpp ! src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m ! src/java.desktop/share/native/libharfbuzz/hb-meta.hh Changeset: bd5ca953 Author: Johan Sj?len Date: 2023-01-18 13:10:13 +0000 URL: https://git.openjdk.org/loom/commit/bd5ca953058704087da4bc5796b3ce28ce2a8f78 8300222: Replace NULL with nullptr in share/logging Reviewed-by: coleenp, dholmes ! src/hotspot/share/logging/log.hpp ! src/hotspot/share/logging/logAsyncWriter.cpp ! src/hotspot/share/logging/logConfiguration.cpp ! src/hotspot/share/logging/logConfiguration.hpp ! src/hotspot/share/logging/logDecorations.cpp ! src/hotspot/share/logging/logDecorators.cpp ! src/hotspot/share/logging/logDecorators.hpp ! src/hotspot/share/logging/logDiagnosticCommand.cpp ! src/hotspot/share/logging/logDiagnosticCommand.hpp ! src/hotspot/share/logging/logFileOutput.cpp ! src/hotspot/share/logging/logFileStreamOutput.cpp ! src/hotspot/share/logging/logMessageBuffer.cpp ! src/hotspot/share/logging/logMessageBuffer.hpp ! src/hotspot/share/logging/logOutput.cpp ! src/hotspot/share/logging/logOutputList.cpp ! src/hotspot/share/logging/logOutputList.hpp ! src/hotspot/share/logging/logSelection.cpp ! src/hotspot/share/logging/logSelection.hpp ! src/hotspot/share/logging/logSelectionList.cpp ! src/hotspot/share/logging/logSelectionList.hpp ! src/hotspot/share/logging/logStream.cpp ! src/hotspot/share/logging/logStream.hpp ! src/hotspot/share/logging/logTagSet.cpp ! src/hotspot/share/logging/logTagSetDescriptions.cpp Changeset: 1aded82e Author: Julian Waters Date: 2023-01-18 13:11:32 +0000 URL: https://git.openjdk.org/loom/commit/1aded82e546869f80b0464e92de137cc42db2658 8300488: Incorrect usage of CATCH_BAD_ALLOC as a macro call Reviewed-by: aivanov ! src/java.desktop/windows/native/libawt/windows/awt_TrayIcon.cpp Changeset: c464ef1d Author: Afshin Zafari Committer: Robbin Ehn Date: 2023-01-18 13:21:32 +0000 URL: https://git.openjdk.org/loom/commit/c464ef1d61c2ea4a37759546f0ee39b1f530ccdc 8292741: Convert JvmtiTagMapTable to ResourceHashtable Reviewed-by: dholmes, coleenp, rehn ! src/hotspot/share/prims/jvmtiTagMap.cpp ! src/hotspot/share/prims/jvmtiTagMap.hpp ! src/hotspot/share/prims/jvmtiTagMapTable.cpp ! src/hotspot/share/prims/jvmtiTagMapTable.hpp Changeset: 85d8bacb Author: Andrey Turbanov Date: 2023-01-18 13:23:59 +0000 URL: https://git.openjdk.org/loom/commit/85d8bacb0ff4015941db53305e6a0d5d28391e1f 8300166: Unused array allocation in ProcessPath.doProcessPath Reviewed-by: aivanov ! src/java.desktop/share/classes/sun/java2d/loops/ProcessPath.java Changeset: 754f6e61 Author: Sergey Tsypanov Committer: Claes Redestad Date: 2023-01-18 13:55:09 +0000 URL: https://git.openjdk.org/loom/commit/754f6e6116b8889c49abf34d01f6fc3e9f1b3cb7 8300237: Minor improvements in MethodHandles Reviewed-by: redestad ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java Changeset: b3684f4b Author: Dmitry Chuyko Date: 2023-01-18 14:56:53 +0000 URL: https://git.openjdk.org/loom/commit/b3684f4bacd8310eea75ebf4ccc70397328d5e86 8153837: AArch64: Handle special cases for MaxINode & MinINode Reviewed-by: fyang, aph ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/aarch64/aarch64_ad.m4 + test/hotspot/jtreg/compiler/intrinsics/math/TestMinMaxIntrinsics.java Changeset: c3242ee4 Author: Coleen Phillimore Date: 2023-01-18 15:19:30 +0000 URL: https://git.openjdk.org/loom/commit/c3242ee452c25b5038283c68e65541122a10df0d 8298596: vmTestbase/nsk/sysdict/vm/stress/chain/chain008/chain008.java fails with "NoClassDefFoundError: Could not initialize class java.util.concurrent.ThreadLocalRandom" Reviewed-by: ayang, tschatzl ! test/hotspot/jtreg/ProblemList-zgc.txt ! test/hotspot/jtreg/vmTestbase/nsk/share/gc/gp/GarbageUtils.java Changeset: c205caea Author: Magnus Ihse Bursie Date: 2023-01-18 16:16:51 +0000 URL: https://git.openjdk.org/loom/commit/c205caead557aea92e319c85d0e974ca7b4830e1 8297851: Add devkit for RISC-V Reviewed-by: fyang, erikj ! make/conf/jib-profiles.js ! make/devkit/Tools.gmk + make/devkit/patches/riscv64-gcc-11.3.0.patch Changeset: fcbf9d05 Author: Johan Sj?len Date: 2023-01-18 16:56:31 +0000 URL: https://git.openjdk.org/loom/commit/fcbf9d052efd16821750fb20813f8030ee828472 8300243: Replace NULL with nullptr in share/compiler/ Reviewed-by: thartmann, kvn ! src/hotspot/share/compiler/abstractDisassembler.cpp ! src/hotspot/share/compiler/compilationLog.cpp ! src/hotspot/share/compiler/compilationPolicy.cpp ! src/hotspot/share/compiler/compilationPolicy.hpp ! src/hotspot/share/compiler/compileBroker.cpp ! src/hotspot/share/compiler/compileBroker.hpp ! src/hotspot/share/compiler/compileLog.cpp ! src/hotspot/share/compiler/compileTask.cpp ! src/hotspot/share/compiler/compileTask.hpp ! src/hotspot/share/compiler/compilerDefinitions.cpp ! src/hotspot/share/compiler/compilerDefinitions.hpp ! src/hotspot/share/compiler/compilerDirectives.cpp ! src/hotspot/share/compiler/compilerDirectives.hpp ! src/hotspot/share/compiler/compilerEvent.cpp ! src/hotspot/share/compiler/compilerOracle.cpp ! src/hotspot/share/compiler/compilerThread.cpp ! src/hotspot/share/compiler/compilerThread.hpp ! src/hotspot/share/compiler/compiler_globals.hpp ! src/hotspot/share/compiler/directivesParser.cpp ! src/hotspot/share/compiler/disassembler.cpp ! src/hotspot/share/compiler/disassembler.hpp ! src/hotspot/share/compiler/methodLiveness.cpp ! src/hotspot/share/compiler/methodMatcher.cpp ! src/hotspot/share/compiler/methodMatcher.hpp ! src/hotspot/share/compiler/oopMap.cpp ! src/hotspot/share/compiler/oopMap.hpp ! src/hotspot/share/compiler/oopMap.inline.hpp Changeset: 3ea0b8bc Author: Claes Redestad Date: 2023-01-18 17:39:27 +0000 URL: https://git.openjdk.org/loom/commit/3ea0b8bc253f1498895a879681406ecc15f37afb 8300489: Use ArraysSupport.vectorizedHashCode in j.l.CharacterName Reviewed-by: alanb, naoto ! src/java.base/share/classes/java/lang/CharacterName.java ! test/micro/org/openjdk/bench/java/lang/Characters.java Changeset: 2a46e07f Author: Rajat Mahajan Committer: Alexey Ivanov Date: 2023-01-18 18:04:30 +0000 URL: https://git.openjdk.org/loom/commit/2a46e07f7d85a3c7db93b53b5c347cd96a91cbb9 8286581: Make Java process DPI Aware if sun.java2d.dpiaware property is set Reviewed-by: aivanov, prr ! src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsEnv.cpp Changeset: 7bf0d146 Author: Joe Darcy Date: 2023-01-18 18:54:03 +0000 URL: https://git.openjdk.org/loom/commit/7bf0d1465e73d83aae30f1cd9fd318af9e9c1b70 8300133: Use generalized see and link tags in core libs Reviewed-by: jjg, mchung, naoto, smarks ! src/java.base/share/classes/java/lang/CharSequence.java ! src/java.base/share/classes/java/lang/String.java ! src/java.base/share/classes/java/lang/module/Configuration.java ! src/java.base/share/classes/java/math/BigDecimal.java ! src/java.base/share/classes/java/net/spi/InetAddressResolverProvider.java ! src/java.base/share/classes/java/util/Collection.java ! src/java.base/share/classes/java/util/Deque.java ! src/java.base/share/classes/java/util/Map.java ! src/java.base/share/classes/java/util/ResourceBundle.java ! src/java.base/share/classes/javax/net/ssl/SNIHostName.java Changeset: 5473e8a1 Author: Joe Darcy Date: 2023-01-18 20:08:37 +0000 URL: https://git.openjdk.org/loom/commit/5473e8a1c616a7004f4a154e235c5344b559104c 8300357: Use generalized see and link tags in java.management Reviewed-by: alanb, dfuchs ! src/java.management/share/classes/java/lang/management/ThreadMXBean.java ! src/java.management/share/classes/javax/management/remote/JMXConnectorFactory.java ! src/java.management/share/classes/javax/management/remote/JMXConnectorServerFactory.java Changeset: ba899b42 Author: Magnus Ihse Bursie Date: 2023-01-18 20:09:34 +0000 URL: https://git.openjdk.org/loom/commit/ba899b42ce2b4b11cd45f8e7795479331d59a1be 8300550: BASIC_JVM_LIBS is set for buildjdk even if this is incorrect Reviewed-by: erikj ! make/autoconf/libraries.m4 Changeset: 8b70c432 Author: Sergey Bylokhov Date: 2023-01-18 20:27:30 +0000 URL: https://git.openjdk.org/loom/commit/8b70c432d31b29bf5f6b8d29809e3c3b91318be1 8299772: The ColorModel.getRGBdefault() method is not thread-safe Reviewed-by: prr ! src/java.desktop/share/classes/java/awt/image/ColorModel.java + test/jdk/java/awt/image/ColorModel/RGBdefaultSingleton.java Changeset: 601e0ae7 Author: Joe Darcy Date: 2023-01-18 22:44:28 +0000 URL: https://git.openjdk.org/loom/commit/601e0ae7da472acb68b53f766b30a688e6bacbcf 8300594: Use generalized see and link tags in UnicastRemoteObject Reviewed-by: rriggs, smarks ! src/java.rmi/share/classes/java/rmi/server/UnicastRemoteObject.java Changeset: dfe94b89 Author: Justin Lu Committer: Naoto Sato Date: 2023-01-18 23:09:46 +0000 URL: https://git.openjdk.org/loom/commit/dfe94b89f82a6a43e2f563bcf93cf5a13930c44e 8300307: Refactor code examples to use @snippet in java.text.DateFormat Reviewed-by: lancea, iris, naoto ! src/java.base/share/classes/java/text/DateFormat.java Changeset: 31a2e02a Author: Justin Lu Committer: Naoto Sato Date: 2023-01-18 23:10:57 +0000 URL: https://git.openjdk.org/loom/commit/31a2e02afcf4853f71925ec75a9a6427b08b4cbd 8300308: java.text.MessageFormat has incorrect doc comment Reviewed-by: naoto, lancea ! src/java.base/share/classes/java/text/MessageFormat.java Changeset: ae0e0276 Author: Erik ?sterlund Date: 2023-01-17 15:05:51 +0000 URL: https://git.openjdk.org/loom/commit/ae0e02766ad01ec6a9a5d4f900c50bd413b09638 8298059: Linked stack watermarks don't support nesting Reviewed-by: stefank Backport-of: b17c52422c91ad1e7ff35844676f6269a1b87f79 ! src/hotspot/share/runtime/keepStackGCProcessed.cpp ! src/hotspot/share/runtime/stackWatermark.cpp ! src/hotspot/share/runtime/stackWatermark.hpp ! test/hotspot/jtreg/ProblemList-zgc.txt Changeset: ba86c23e Author: Naoto Sato Committer: Henry Jen Date: 2022-05-11 17:52:25 +0000 URL: https://git.openjdk.org/loom/commit/ba86c23eaf9b0adaa0a1ee457207a8472037cf8e 8286070: Improve UTF8 representation Reviewed-by: bchristi, rhalade ! src/java.base/share/native/libjava/jni_util.c Changeset: 5aae8226 Author: Phil Race Committer: Henry Jen Date: 2022-08-09 16:57:10 +0000 URL: https://git.openjdk.org/loom/commit/5aae8226fc6196a13c0346a048ce30a57fd1ef14 8288516: Enhance font creation Reviewed-by: psadhukhan, azvegint, rhalade, mschoene ! src/java.desktop/windows/native/libawt/windows/awt_Font.cpp ! src/java.desktop/windows/native/libawt/windows/awt_PrintJob.cpp ! src/java.desktop/windows/native/libfontmanager/fontpath.c ! src/java.desktop/windows/native/libfontmanager/lcdglyph.c Changeset: 51e52c4e Author: Markus Gr?nlund Committer: Henry Jen Date: 2022-09-19 11:27:04 +0000 URL: https://git.openjdk.org/loom/commit/51e52c4eb851d485fd41ad0bdf7df617a1cdb792 8286496: Improve Thread labels Reviewed-by: mschoene, rhalade, egahlin ! src/hotspot/share/jfr/recorder/checkpoint/jfrCheckpointManager.cpp ! src/hotspot/share/jfr/recorder/storage/jfrBuffer.cpp ! src/hotspot/share/jfr/recorder/storage/jfrBuffer.hpp ! src/hotspot/share/jfr/recorder/storage/jfrMemorySpace.inline.hpp ! src/hotspot/share/jfr/writers/jfrWriterHost.inline.hpp Changeset: b7cfb681 Author: Daniel Jeli?ski Committer: Henry Jen Date: 2022-09-26 19:16:22 +0000 URL: https://git.openjdk.org/loom/commit/b7cfb6817b3aabb099d21f5fc6d1619ba346911b 8293598: Enhance InetAddress address handling Reviewed-by: skoivu, alanb, aefimov, rhalade, dfuchs ! src/java.base/share/classes/java/net/InetAddress.java ! src/java.base/share/classes/sun/net/util/IPAddressUtil.java Changeset: 3364c460 Author: Jayathirth D V Committer: Henry Jen Date: 2022-09-29 06:59:58 +0000 URL: https://git.openjdk.org/loom/commit/3364c460a4d5b9b0ce43742130bc0766bb106955 8293734: Improve BMP image handling Reviewed-by: kizune, prr, azvegint, rhalade, mschoene ! src/java.desktop/share/classes/com/sun/imageio/plugins/bmp/BMPImageReader.java Changeset: d6b15132 Author: Prasanta Sadhukhan Committer: Henry Jen Date: 2022-09-29 07:39:29 +0000 URL: https://git.openjdk.org/loom/commit/d6b1513233e926dc77c81ef1123737d6a6ad94b1 8293717: Objective view of ObjectView Reviewed-by: kizune, rhalade, prr, azvegint, skoivu ! src/java.desktop/share/classes/javax/swing/text/html/ObjectView.java Changeset: 2e8073e4 Author: Jamil Nimeh Committer: Henry Jen Date: 2022-10-04 16:55:57 +0000 URL: https://git.openjdk.org/loom/commit/2e8073e4f90156b213a7dca0e8844a6a2525581b 8287411: Enhance DTLS Performance Reviewed-by: rhalade, ahgross, weijun, ascarpino ! src/java.base/share/classes/sun/security/ssl/ClientHello.java ! src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java Changeset: 6c5aefe6 Author: Valerie Peng Committer: Henry Jen Date: 2022-10-07 22:25:38 +0000 URL: https://git.openjdk.org/loom/commit/6c5aefe60c8d294631c716c63ec411feb7f7a4ea 8293554: Enhanced DH Key Exchanges Reviewed-by: rhalade, mschoene, ascarpino, weijun ! src/java.base/share/classes/com/sun/crypto/provider/DHKeyPairGenerator.java ! src/java.base/share/classes/com/sun/crypto/provider/DHParameterGenerator.java ! src/java.base/share/classes/sun/security/provider/ParameterCache.java ! src/java.base/share/classes/sun/security/ssl/PredefinedDHParameterSpecs.java ! src/java.base/share/classes/sun/security/util/SecurityProviderConstants.java Changeset: 93161e46 Author: Alexander Zuev Committer: Henry Jen Date: 2022-10-26 21:29:01 +0000 URL: https://git.openjdk.org/loom/commit/93161e46e73a93e20e5fa45946457b32fdf0613d 8293742: Better Banking of Sounds Reviewed-by: rhalade, azvegint, prr ! src/java.desktop/share/classes/com/sun/media/sound/JARSoundbankReader.java Changeset: bd324cee Author: Jayathirth D V Committer: Henry Jen Date: 2022-11-10 06:16:14 +0000 URL: https://git.openjdk.org/loom/commit/bd324cee9c839e5a78c12cbcea17c4762acfcfd0 8295687: Better BMP bounds Reviewed-by: rhalade, mschoene, psadhukhan, prr ! src/java.desktop/share/classes/com/sun/imageio/plugins/bmp/BMPImageReader.java Changeset: 0f925fef Author: Valerie Peng Committer: Henry Jen Date: 2022-11-10 17:56:33 +0000 URL: https://git.openjdk.org/loom/commit/0f925fefdfc0160b896b35e37c1fef3b3c47a8db 8295723: security/infra/wycheproof/RunWycheproof.java fails with Assertion Error Reviewed-by: mschoene, ascarpino, coffeys, rhalade, weijun ! src/java.base/share/classes/com/sun/crypto/provider/DHKeyPairGenerator.java ! src/java.base/share/classes/sun/security/provider/ParameterCache.java ! src/java.base/share/classes/sun/security/ssl/PredefinedDHParameterSpecs.java + src/java.base/share/classes/sun/security/util/SafeDHParameterSpec.java ! src/java.base/share/classes/sun/security/util/SecurityProviderConstants.java Changeset: c1b4212a Author: Jan Lahoda Date: 2023-01-18 10:43:53 +0000 URL: https://git.openjdk.org/loom/commit/c1b4212a53e5d26108e560a82250b01689ae03f0 8300195: Fall-through issue occurs when using record pattern in switch statements Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java ! test/langtools/tools/javac/patterns/PatternDesugaring.java Changeset: b9275a8e Author: Maurizio Cimadamore Date: 2023-01-18 12:36:15 +0000 URL: https://git.openjdk.org/loom/commit/b9275a8ed1c462cfad33dab140022e5968765e58 8300275: SegmentScope.isAccessibleBy returning incorrect values Reviewed-by: alanb, jvernee ! src/java.base/share/classes/jdk/internal/foreign/MemorySessionImpl.java ! test/jdk/java/foreign/TestSegments.java Changeset: fc9f8baf Author: Jesper Wilhelmsson Date: 2023-01-18 23:29:12 +0000 URL: https://git.openjdk.org/loom/commit/fc9f8baf56a8888362ad60d0e6dc8953690b80d3 Merge ! src/java.desktop/share/classes/com/sun/imageio/plugins/bmp/BMPImageReader.java ! src/java.desktop/windows/native/libawt/windows/awt_PrintJob.cpp ! src/java.desktop/share/classes/com/sun/imageio/plugins/bmp/BMPImageReader.java ! src/java.desktop/windows/native/libawt/windows/awt_PrintJob.cpp Changeset: 910dffea Author: Calvin Cheung Date: 2023-01-19 00:20:13 +0000 URL: https://git.openjdk.org/loom/commit/910dffea867ea57b6338daf9ed7f6ea81536a934 8292635: Run ArchivedEnumTest.java in jdk tier testing Reviewed-by: iklam, dholmes ! src/hotspot/share/cds/cdsHeapVerifier.cpp ! src/hotspot/share/cds/cdsHeapVerifier.hpp ! test/jdk/TEST.ROOT = test/jdk/jdk/internal/misc/CDS/ArchivedEnumApp.java = test/jdk/jdk/internal/misc/CDS/ArchivedEnumTest.java From Alan.Bateman at oracle.com Fri Jan 20 12:49:10 2023 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 20 Jan 2023 12:49:10 +0000 Subject: ConcurrentHashMap::computeIfAbsent and synchronized In-Reply-To: References: Message-ID: <49a35841-8734-147e-ea35-5c2633faf5dc@oracle.com> On 20/01/2023 06:22, mikmoila wrote: > Hi. > > As often mentioned in this mailing-list a feedback about > preview/incubator features is appreciated, so here's one: > > I was experimenting with a caching system utilising ConcurrentHashMap > as cache store and Structured Concurrency API for refreshing the > entries from multiple sources ( StructuredTaskScope.ShutdownOnSuccess > ). The idea was to make http-requests for getting the fresh values but > the first implementation simply uses UUID::randomUUID for simulating that. > I noticed that the programs halts In a test case where "N" concurrent > calls (where "N" >= number of cpu cores) running on virtual threads > end-up calling the ConcurrentHashMap::computeIfAbsent for the same > (non-existing) key. > > "-Djdk.tracePinnedThreads=full" reveals that there is a pinned carrier > thread: > java.base/java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1708) > <== monitors:1 > > The documentation ( > https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/concurrent/ConcurrentHashMap.html#computeIfAbsent(K,java.util.function.Function) > ) says: > > ? "Some attempted update operations on this map by other threads may > be blocked while computation is in progress, so the computation should > be short and simple." > > This is clear but I still found it as a surprise that it uses > synchronized instead of "virtual-thread friendly" constructs. > Thanks for taking time to send feedback. The CHM.computeXXX methods work okay from virtual threads when the mapping function does something short/simple. The quality of implementation issue is when they do something long running, like block on I/O, in which case you get disappointing performance, as you would with platform threads too. I think Doug Lea has looked at the synchronization in this code a few times. Separately, we expect the pinning issus will go away but it's not a trivial project and requires work in several areas. -Alan From dl at cs.oswego.edu Fri Jan 20 12:51:17 2023 From: dl at cs.oswego.edu (Doug Lea) Date: Fri, 20 Jan 2023 07:51:17 -0500 Subject: ConcurrentHashMap::computeIfAbsent and synchronized In-Reply-To: <20fdac7a-1a73-dc12-c021-a492f13de2b9@javaspecialists.eu> References: <20fdac7a-1a73-dc12-c021-a492f13de2b9@javaspecialists.eu> Message-ID: <5495ea3f-ef54-708b-6854-c5ec8edfd734@cs.oswego.edu> Updates to ConcurrentHashMap to avoid builtin synchronization are on the todo list. As you've noticed, using a ReentrantLock per node would add unacceptable overhead, and would be especially unwelcome for the huge number of non-loom usages. I have a few ideas in mind, but it will surely be a while until arriving at a replacement good enough to release. -Doug On 1/20/23 02:40, Dr Heinz M. Kabutz wrote: > > Hi Mika, > > I was thinking about that yesterday. Since CHM gives a guarantee that > the compute() functions are called atomically, it might be worth > looking at the implications of moving (back) to ReentrantLock. > However, that would also mean that we need to allocate a lot of > ReentrantLock instances, and those are 40 bytes per lock. Here is a > demo that shows the issue: > > import java.util.Map; import java.util.concurrent.CancellationException; import java.util.concurrent.ConcurrentHashMap; public class CHMPinning { > public static void main(String... args)throws InterruptedException { > Map map =new ConcurrentHashMap<>(); for (int i =0; i <1_000; i++) { > int finalI = i; Thread.startVirtualThread(() -> > map.computeIfAbsent(finalI %3, key -> { > try { > Thread.sleep(2_000); }catch (InterruptedException e) { > throw new CancellationException("interrupted"); } > return finalI; })); } > long time = System.nanoTime(); try { > Thread.startVirtualThread(() -> > System.out.println( > "Hi, I'm an innocent virtual thread")) > .join(); }finally { > time = System.nanoTime() - time; System.out.printf("time = %dms%n", (time /1_000_000)); } > System.out.println("map = " + map); } > } > > Output is something like: > > Hi, I'm an innocent virtual thread > time = 2002ms > map = {0=0, 1=7, 2=2} > > IMHO, I would not like to see the CHM memory usage increase by 40 x # > nodes bytes to cater for an edge case of the compute() function taking > a bit longer. > > > Regards > > Heinz > -- > Dr Heinz M. Kabutz (PhD CompSci) > Author of "The Java? Specialists' Newsletter" -www.javaspecialists.eu > Java Champion -www.javachampions.org > JavaOne Rock Star Speaker > Tel: +30 69 75 595 262 > Skype: kabutz > On 2023/01/20 01:22, mikmoila wrote: >> Hi. >> >> As often mentioned in this mailing-list a feedback about >> preview/incubator features is appreciated, so here's one: >> >> I was experimenting with a caching system utilising ConcurrentHashMap >> as cache store and Structured Concurrency API for refreshing the >> entries from multiple sources ( StructuredTaskScope.ShutdownOnSuccess >> ). The idea was to make http-requests for getting the fresh values >> but the first implementation simply uses UUID::randomUUID for >> simulating that. >> I noticed that the programs halts In a test case where "N" concurrent >> calls (where "N" >= number of cpu cores) running on virtual threads >> end-up calling the ConcurrentHashMap::computeIfAbsent for the same >> (non-existing) key. >> >> "-Djdk.tracePinnedThreads=full" reveals that there is a pinned >> carrier thread: >> java.base/java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1708) >> <== monitors:1 >> >> The documentation ( >> https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/concurrent/ConcurrentHashMap.html#computeIfAbsent(K,java.util.function.Function) >> ) says: >> >> ? "Some attempted update operations on this map by other threads may >> be blocked while computation is in progress, so the computation >> should be short and simple." >> >> This is clear but I still found it as a surprise that it uses >> synchronized instead of "virtual-thread friendly" constructs. >> >> If needed I can post a small demo program. >> >> JDK used is latest OpenJDK-19 GA, OS is Windows: >> ? openjdk version "19.0.2" 2023-01-17 >> ? OpenJDK Runtime Environment (build 19.0.2+7-44) >> ? OpenJDK 64-Bit Server VM (build 19.0.2+7-44, mixed mode, sharing) >> >> Best Regards, >> ? Mika -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika.a.moilanen at gmail.com Fri Jan 20 13:17:07 2023 From: mika.a.moilanen at gmail.com (mikmoila) Date: Fri, 20 Jan 2023 15:17:07 +0200 Subject: ConcurrentHashMap::computeIfAbsent and synchronized In-Reply-To: <49a35841-8734-147e-ea35-5c2633faf5dc@oracle.com> References: <49a35841-8734-147e-ea35-5c2633faf5dc@oracle.com> Message-ID: Hi. Thank you for the information, that's good to know. Just to be sure that I've understood the problem correctly, here's my example code: public class C2 { private static final ConcurrentMap cache = new ConcurrentHashMap<>(); private static String refresh(String key) { try (var scope = new StructuredTaskScope.ShutdownOnSuccess()) { scope.fork(() -> UUID.randomUUID().toString()); scope.join(); return scope.result(); } catch (Exception e) { throw new RuntimeException(e); } } public static void main(String[] args) throws Exception { var cpus = Runtime.getRuntime().availableProcessors(); List fl = new ArrayList<>(); try (var es = Executors.newVirtualThreadPerTaskExecutor()) { for (int i = 0; i < cpus; ++i) fl.add(es.submit(() -> cache.computeIfAbsent("foo", k -> refresh(k)))); } for (var f : fl) System.out.println(f.get()); } } If you set the "cpus" to Runtime.getRuntime().availableProcessors() - 1 it completes, otherwise it hangs. On Fri, Jan 20, 2023 at 2:49 PM Alan Bateman wrote: > On 20/01/2023 06:22, mikmoila wrote: > > Hi. > > > > As often mentioned in this mailing-list a feedback about > > preview/incubator features is appreciated, so here's one: > > > > I was experimenting with a caching system utilising ConcurrentHashMap > > as cache store and Structured Concurrency API for refreshing the > > entries from multiple sources ( StructuredTaskScope.ShutdownOnSuccess > > ). The idea was to make http-requests for getting the fresh values but > > the first implementation simply uses UUID::randomUUID for simulating > that. > > I noticed that the programs halts In a test case where "N" concurrent > > calls (where "N" >= number of cpu cores) running on virtual threads > > end-up calling the ConcurrentHashMap::computeIfAbsent for the same > > (non-existing) key. > > > > "-Djdk.tracePinnedThreads=full" reveals that there is a pinned carrier > > thread: > > > java.base/java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1708) > > > <== monitors:1 > > > > The documentation ( > > > https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/concurrent/ConcurrentHashMap.html#computeIfAbsent(K,java.util.function.Function) > > ) says: > > > > "Some attempted update operations on this map by other threads may > > be blocked while computation is in progress, so the computation should > > be short and simple." > > > > This is clear but I still found it as a surprise that it uses > > synchronized instead of "virtual-thread friendly" constructs. > > > Thanks for taking time to send feedback. > > The CHM.computeXXX methods work okay from virtual threads when the > mapping function does something short/simple. The quality of > implementation issue is when they do something long running, like block > on I/O, in which case you get disappointing performance, as you would > with platform threads too. > > I think Doug Lea has looked at the synchronization in this code a few > times. Separately, we expect the pinning issus will go away but it's not > a trivial project and requires work in several areas. > > -Alan > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Fri Jan 20 19:30:16 2023 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 20 Jan 2023 19:30:16 +0000 Subject: ConcurrentHashMap::computeIfAbsent and synchronized In-Reply-To: References: <49a35841-8734-147e-ea35-5c2633faf5dc@oracle.com> Message-ID: On 20/01/2023 13:17, mikmoila wrote: > : > > If you set the "cpus" to Runtime.getRuntime().availableProcessors() - > 1 it completes, otherwise it hangs. > Right, it effectively deadlocks because one of the virtual threads is executing the mapping function and is in STS.join waiting for a child task to complete. The child task can't execute because all carriers are pinned by other virtual threads trying to execute the same mapping function. If you generate a thread dump with `jcmd Thread.dump_to_file -format=json ` it should be easy to see. -Alan From thurston.nomagicsoftware at gmail.com Sat Jan 21 22:07:56 2023 From: thurston.nomagicsoftware at gmail.com (thurston N) Date: Sat, 21 Jan 2023 14:07:56 -0800 Subject: ConcurrentHashMap::computeIfAbsent and synchronized In-Reply-To: <5495ea3f-ef54-708b-6854-c5ec8edfd734@cs.oswego.edu> References: <20fdac7a-1a73-dc12-c021-a492f13de2b9@javaspecialists.eu> <5495ea3f-ef54-708b-6854-c5ec8edfd734@cs.oswego.edu> Message-ID: Just spitballing, there's already a ReservationNode type, adding a ReentrantLock instance variable to it should address the overhead issue (since each ReservationNode is very short-lived, only temporarily in the #table) although the else branch in computeIfAbsent wouldn't be pretty and would require instance of checks -T On Fri, Jan 20, 2023 at 4:51 AM Doug Lea
wrote: > Updates to ConcurrentHashMap to avoid builtin synchronization are on the > todo list. As you've noticed, using a ReentrantLock per node would add > unacceptable overhead, and would be especially unwelcome for the huge > number of non-loom usages. I have a few ideas in mind, but it will surely > be a while until arriving at a replacement good enough to release. > > -Doug > On 1/20/23 02:40, Dr Heinz M. Kabutz wrote: > > Hi Mika, > > I was thinking about that yesterday. Since CHM gives a guarantee that the > compute() functions are called atomically, it might be worth looking at the > implications of moving (back) to ReentrantLock. However, that would also > mean that we need to allocate a lot of ReentrantLock instances, and those > are 40 bytes per lock. Here is a demo that shows the issue: > > import java.util.Map;import java.util.concurrent.CancellationException;import java.util.concurrent.ConcurrentHashMap;public class CHMPinning { > public static void main(String... args) throws InterruptedException { > Map map = new ConcurrentHashMap<>(); for (int i = 0; i < 1_000; i++) { > int finalI = i; Thread.startVirtualThread(() -> > map.computeIfAbsent(finalI % 3, key -> { > try { > Thread.sleep(2_000); } catch (InterruptedException e) { > throw new CancellationException("interrupted"); } > return finalI; })); } > long time = System.nanoTime(); try { > Thread.startVirtualThread(() -> > System.out.println( > "Hi, I'm an innocent virtual thread")) > .join(); } finally { > time = System.nanoTime() - time; System.out.printf("time = %dms%n", (time / 1_000_000)); } > System.out.println("map = " + map); } > } > > Output is something like: > > Hi, I'm an innocent virtual thread > time = 2002ms > map = {0=0, 1=7, 2=2} > > IMHO, I would not like to see the CHM memory usage increase by 40 x # > nodes bytes to cater for an edge case of the compute() function taking a > bit longer. > > > Regards > > Heinz > -- > Dr Heinz M. Kabutz (PhD CompSci) > Author of "The Java? Specialists' Newsletter" - www.javaspecialists.eu > Java Champion - www.javachampions.org > JavaOne Rock Star Speaker > Tel: +30 69 75 595 262 > Skype: kabutz > > On 2023/01/20 01:22, mikmoila wrote: > > Hi. > > As often mentioned in this mailing-list a feedback about preview/incubator > features is appreciated, so here's one: > > I was experimenting with a caching system utilising ConcurrentHashMap as > cache store and Structured Concurrency API for refreshing the entries from > multiple sources ( StructuredTaskScope.ShutdownOnSuccess ). The idea was to > make http-requests for getting the fresh values but the first > implementation simply uses UUID::randomUUID for simulating that. > > I noticed that the programs halts In a test case where "N" concurrent > calls (where "N" >= number of cpu cores) running on virtual threads end-up > calling the ConcurrentHashMap::computeIfAbsent for the same (non-existing) > key. > > "-Djdk.tracePinnedThreads=full" reveals that there is a pinned carrier > thread: > > java.base/java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1708) > <== monitors:1 > > The documentation ( > https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/concurrent/ConcurrentHashMap.html#computeIfAbsent(K,java.util.function.Function) > ) says: > > "Some attempted update operations on this map by other threads may be > blocked while computation is in progress, so the computation should be > short and simple." > > This is clear but I still found it as a surprise that it uses synchronized > instead of "virtual-thread friendly" constructs. > > If needed I can post a small demo program. > > JDK used is latest OpenJDK-19 GA, OS is Windows: > openjdk version "19.0.2" 2023-01-17 > OpenJDK Runtime Environment (build 19.0.2+7-44) > OpenJDK 64-Bit Server VM (build 19.0.2+7-44, mixed mode, sharing) > > Best Regards, > Mika > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Fri Jan 27 12:57:33 2023 From: duke at openjdk.org (duke) Date: Fri, 27 Jan 2023 12:57:33 GMT Subject: git: openjdk/loom: fibers: 112 new changesets Message-ID: <303a6e3b-76e4-43b3-873e-ab4148b3a4c8@openjdk.org> Changeset: 715b509f Author: Pengfei Li Date: 2023-01-19 01:05:58 +0000 URL: https://git.openjdk.org/loom/commit/715b509f3d3dd2e8ef75f8e710becc959dd538e0 8298632: [TESTBUG] Add IR checks in jtreg vectorization tests Reviewed-by: kvn, jbhateja ! test/hotspot/jtreg/compiler/lib/ir_framework/IRNode.java ! test/hotspot/jtreg/compiler/vectorization/runner/ArrayCopyTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/ArrayIndexFillTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/ArrayInvariantFillTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/ArrayShiftOpTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/ArrayTypeConvertTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/ArrayUnsafeOpTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/BasicBooleanOpTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/BasicByteOpTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/BasicCharOpTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/BasicDoubleOpTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/BasicFloatOpTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/BasicIntOpTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/BasicLongOpTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/BasicShortOpTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/LoopArrayIndexComputeTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/LoopCombinedOpTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/LoopControlFlowTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/LoopLiveOutNodesTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/LoopRangeStrideTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/LoopReductionOpTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/MultipleLoopsTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/StripMinedLoopTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/VectorizationTestRunner.java Changeset: 8e3036cf Author: Joe Darcy Date: 2023-01-19 01:14:12 +0000 URL: https://git.openjdk.org/loom/commit/8e3036cf7430cee5c5df2584d0a0eef816868c62 8300595: Use improved @see and @link syntax in javax.lang.model and javax.tools Reviewed-by: jjg, iris ! src/java.compiler/share/classes/javax/lang/model/element/Element.java ! src/java.compiler/share/classes/javax/lang/model/element/ExecutableElement.java ! src/java.compiler/share/classes/javax/lang/model/element/ModuleElement.java ! src/java.compiler/share/classes/javax/lang/model/element/PackageElement.java ! src/java.compiler/share/classes/javax/lang/model/element/TypeElement.java ! src/java.compiler/share/classes/javax/lang/model/util/Elements.java ! src/java.compiler/share/classes/javax/tools/JavaFileManager.java Changeset: 24cdcd4c Author: Feilong Jiang Committer: Fei Yang Date: 2023-01-19 01:33:35 +0000 URL: https://git.openjdk.org/loom/commit/24cdcd4c70dd538fd6c6c9f05da480ea65463209 8293841: RISC-V: Implementation of Foreign Function & Memory API (Preview) Co-authored-by: Weikai He Co-authored-by: Fei Yang Reviewed-by: jvernee, fyang, shade, yadongwang ! src/hotspot/cpu/riscv/codeBuffer_riscv.cpp ! src/hotspot/cpu/riscv/downcallLinker_riscv.cpp ! src/hotspot/cpu/riscv/foreignGlobals_riscv.cpp ! src/hotspot/cpu/riscv/foreignGlobals_riscv.hpp ! src/hotspot/cpu/riscv/frame_riscv.cpp ! src/hotspot/cpu/riscv/frame_riscv.inline.hpp ! src/hotspot/cpu/riscv/macroAssembler_riscv.hpp ! src/hotspot/cpu/riscv/methodHandles_riscv.cpp ! src/hotspot/cpu/riscv/register_riscv.hpp ! src/hotspot/cpu/riscv/upcallLinker_riscv.cpp ! src/hotspot/cpu/riscv/vmreg_riscv.cpp ! src/hotspot/cpu/riscv/vmstorage_riscv.hpp ! src/java.base/share/classes/java/lang/foreign/VaList.java ! src/java.base/share/classes/jdk/internal/foreign/CABI.java ! src/java.base/share/classes/jdk/internal/foreign/PlatformLayouts.java ! src/java.base/share/classes/jdk/internal/foreign/SystemLookup.java ! src/java.base/share/classes/jdk/internal/foreign/abi/AbstractLinker.java ! src/java.base/share/classes/jdk/internal/foreign/abi/SharedUtils.java + src/java.base/share/classes/jdk/internal/foreign/abi/riscv64/RISCV64Architecture.java + src/java.base/share/classes/jdk/internal/foreign/abi/riscv64/linux/LinuxRISCV64CallArranger.java + src/java.base/share/classes/jdk/internal/foreign/abi/riscv64/linux/LinuxRISCV64Linker.java + src/java.base/share/classes/jdk/internal/foreign/abi/riscv64/linux/LinuxRISCV64VaList.java + src/java.base/share/classes/jdk/internal/foreign/abi/riscv64/linux/TypeClass.java ! test/jdk/java/foreign/LibraryLookupTest.java ! test/jdk/java/foreign/SafeFunctionAccessTest.java ! test/jdk/java/foreign/StdLibTest.java ! test/jdk/java/foreign/TestClassLoaderFindNative.java ! test/jdk/java/foreign/TestDowncallScope.java ! test/jdk/java/foreign/TestDowncallStack.java ! test/jdk/java/foreign/TestFunctionDescriptor.java ! test/jdk/java/foreign/TestHeapAlignment.java ! test/jdk/java/foreign/TestIllegalLink.java ! test/jdk/java/foreign/TestIntrinsics.java ! test/jdk/java/foreign/TestLayoutEquality.java ! test/jdk/java/foreign/TestLinker.java ! test/jdk/java/foreign/TestMatrix.java ! test/jdk/java/foreign/TestNULLAddress.java ! test/jdk/java/foreign/TestNative.java ! test/jdk/java/foreign/TestNulls.java ! test/jdk/java/foreign/TestScopedOperations.java ! test/jdk/java/foreign/TestSegments.java ! test/jdk/java/foreign/TestStringEncoding.java ! test/jdk/java/foreign/TestUpcallAsync.java ! test/jdk/java/foreign/TestUpcallException.java ! test/jdk/java/foreign/TestUpcallHighArity.java ! test/jdk/java/foreign/TestUpcallScope.java ! test/jdk/java/foreign/TestUpcallStack.java ! test/jdk/java/foreign/TestUpcallStructScope.java ! test/jdk/java/foreign/TestVarArgs.java + test/jdk/java/foreign/callarranger/TestRISCV64CallArranger.java ! test/jdk/java/foreign/capturecallstate/TestCaptureCallState.java ! test/jdk/java/foreign/dontrelease/TestDontRelease.java ! test/jdk/java/foreign/enablenativeaccess/TestEnableNativeAccess.java ! test/jdk/java/foreign/enablenativeaccess/TestEnableNativeAccessDynamic.java ! test/jdk/java/foreign/handles/Driver.java ! test/jdk/java/foreign/loaderLookup/TestLoaderLookup.java ! test/jdk/java/foreign/loaderLookup/TestLoaderLookupJNI.java ! test/jdk/java/foreign/normalize/TestNormalize.java ! test/jdk/java/foreign/passheapsegment/TestPassHeapSegment.java ! test/jdk/java/foreign/stackwalk/TestAsyncStackWalk.java ! test/jdk/java/foreign/stackwalk/TestStackWalk.java ! test/jdk/java/foreign/upcalldeopt/TestUpcallDeopt.java ! test/jdk/java/foreign/valist/VaListTest.java ! test/jdk/java/foreign/virtual/TestVirtualCalls.java Changeset: 7348b9ec Author: Sergey Bylokhov Date: 2023-01-19 05:02:12 +0000 URL: https://git.openjdk.org/loom/commit/7348b9ec9373746bb76bc9fa9556f1811bd9e475 8300167: Add validation of the raster's layout before using in native Reviewed-by: prr ! src/java.desktop/share/classes/sun/java2d/cmm/lcms/LCMSImageLayout.java Changeset: 2e9cb4b1 Author: SWinxy Committer: Julian Waters Date: 2023-01-19 05:05:20 +0000 URL: https://git.openjdk.org/loom/commit/2e9cb4b1f6ebba75cffa407f5142fdd95ed9bd88 8267582: BasicLookAndFeel should not call getComponentPopupMenu twice to get a popup menu Reviewed-by: psadhukhan ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicLookAndFeel.java Changeset: 5b0af1a8 Author: Alan Bateman Date: 2023-01-19 06:59:38 +0000 URL: https://git.openjdk.org/loom/commit/5b0af1a80bb4d2a81cda7e26a6ad0db43e679519 8208077: File.listRoots performance degradation Reviewed-by: lancea, bpb ! src/java.base/windows/classes/java/io/WinNTFileSystem.java ! test/jdk/java/io/File/ListRoots.java Changeset: 5f66024e Author: Emanuel Peter Date: 2023-01-19 07:37:50 +0000 URL: https://git.openjdk.org/loom/commit/5f66024e957e5e40ce8d5a65717ea7f82c9f0b8f 8299959: C2: CmpU::Value must filter overflow computation against local sub computation Reviewed-by: kvn, chagedorn, roland ! src/hotspot/share/opto/subnode.cpp + test/hotspot/jtreg/compiler/rangechecks/TestRangeCheckCmpUOverflowVsSub.java Changeset: cfe57466 Author: Johan Sj?len Date: 2023-01-19 08:48:36 +0000 URL: https://git.openjdk.org/loom/commit/cfe57466ddecb93b528478d0b053b089dd1ed285 8300242: Replace NULL with nullptr in share/code/ Reviewed-by: kvn, thartmann ! src/hotspot/share/code/codeBehaviours.cpp ! src/hotspot/share/code/codeBlob.cpp ! src/hotspot/share/code/codeBlob.hpp ! src/hotspot/share/code/codeBlob.inline.hpp ! src/hotspot/share/code/codeCache.cpp ! src/hotspot/share/code/codeCache.hpp ! src/hotspot/share/code/codeCache.inline.hpp ! src/hotspot/share/code/codeHeapState.cpp ! src/hotspot/share/code/compiledIC.cpp ! src/hotspot/share/code/compiledIC.hpp ! src/hotspot/share/code/compiledMethod.cpp ! src/hotspot/share/code/compiledMethod.hpp ! src/hotspot/share/code/compiledMethod.inline.hpp ! src/hotspot/share/code/compressedStream.cpp ! src/hotspot/share/code/debugInfo.cpp ! src/hotspot/share/code/debugInfo.hpp ! src/hotspot/share/code/debugInfoRec.cpp ! src/hotspot/share/code/debugInfoRec.hpp ! src/hotspot/share/code/dependencies.cpp ! src/hotspot/share/code/dependencies.hpp ! src/hotspot/share/code/dependencyContext.cpp ! src/hotspot/share/code/dependencyContext.hpp ! src/hotspot/share/code/exceptionHandlerTable.cpp ! src/hotspot/share/code/exceptionHandlerTable.hpp ! src/hotspot/share/code/icBuffer.cpp ! src/hotspot/share/code/icBuffer.hpp ! src/hotspot/share/code/nmethod.cpp ! src/hotspot/share/code/nmethod.hpp ! src/hotspot/share/code/oopRecorder.cpp ! src/hotspot/share/code/oopRecorder.hpp ! src/hotspot/share/code/oopRecorder.inline.hpp ! src/hotspot/share/code/pcDesc.cpp ! src/hotspot/share/code/relocInfo.cpp ! src/hotspot/share/code/relocInfo.hpp ! src/hotspot/share/code/scopeDesc.cpp ! src/hotspot/share/code/scopeDesc.hpp ! src/hotspot/share/code/stubs.cpp ! src/hotspot/share/code/stubs.hpp ! src/hotspot/share/code/vmreg.cpp ! src/hotspot/share/code/vtableStubs.cpp ! src/hotspot/share/code/vtableStubs.hpp Changeset: 08e62182 Author: Alan Bateman Date: 2023-01-19 09:00:01 +0000 URL: https://git.openjdk.org/loom/commit/08e621829bd60d37e946f4de8de42863ba78c3dc 8300526: Test runtime/jni/IsVirtualThread/IsVirtualThread.java should exercise alternative virtual thread implementation Reviewed-by: pchilanomate ! test/hotspot/jtreg/runtime/jni/IsVirtualThread/IsVirtualThread.java Changeset: eba87a0e Author: Justin King Committer: Thomas Schatzl Date: 2023-01-19 09:11:22 +0000 URL: https://git.openjdk.org/loom/commit/eba87a0ee0410f61ae764293986ecc162f48c707 8300264: Remove metaprogramming/isPointer.hpp Reviewed-by: kbarrett, tschatzl - src/hotspot/share/metaprogramming/isPointer.hpp ! src/hotspot/share/oops/accessBackend.hpp ! src/hotspot/share/runtime/atomic.hpp ! src/hotspot/share/utilities/concurrentHashTable.inline.hpp - test/hotspot/gtest/metaprogramming/test_isPointer.cpp Changeset: 8f7faa63 Author: Albert Mingkun Yang Date: 2023-01-19 11:51:43 +0000 URL: https://git.openjdk.org/loom/commit/8f7faa631bd9b6d6421ee6f4b4b08ef6ec87f30f 8300447: Parallel: Refactor PSPromotionManager::drain_stacks_depth Reviewed-by: tschatzl, kbarrett ! src/hotspot/share/gc/parallel/psPromotionManager.cpp Changeset: 11df6eb2 Author: Albert Mingkun Yang Date: 2023-01-19 11:52:40 +0000 URL: https://git.openjdk.org/loom/commit/11df6eb28ac2bd8d9d95b452c0e3eb59cc82ce08 8300540: Serial: Remove obsolete comments in GenMarkSweep Reviewed-by: tschatzl ! src/hotspot/share/gc/serial/genMarkSweep.cpp Changeset: e326b86d Author: Matthias Baesken Date: 2023-01-19 12:01:50 +0000 URL: https://git.openjdk.org/loom/commit/e326b86d37cec3b395b88598cf30ce4239732a15 8300042: Improve CPU related JFR events descriptions Reviewed-by: clanger, lucy ! src/hotspot/share/jfr/metadata/metadata.xml Changeset: 2e4a3c47 Author: Alexey Ivanov Date: 2023-01-19 13:00:09 +0000 URL: https://git.openjdk.org/loom/commit/2e4a3c47e262f91a7f881d9d990eb81a929d1627 8293862: javax/swing/JFileChooser/8046391/bug8046391.java failed with 'Cannot invoke "java.awt.Image.getWidth(java.awt.image.ImageObserver)" because "retVal" is null' Co-authored-by: Tejesh R Reviewed-by: prr, serb ! src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java ! src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp ! test/jdk/ProblemList.txt ! test/jdk/javax/swing/JFileChooser/8046391/bug8046391.java Changeset: dea58efb Author: Jonathan Dowland Committer: Severin Gehwolf Date: 2023-01-19 13:26:18 +0000 URL: https://git.openjdk.org/loom/commit/dea58efb6280bb1d94daf208ac909aa013439397 8300119: CgroupMetrics.getTotalMemorySize0() can report invalid results on 32 bit systems Reviewed-by: sgehwolf ! src/java.base/linux/native/libjava/CgroupMetrics.c Changeset: 1084fd24 Author: Johan Sj?len Date: 2023-01-19 13:42:08 +0000 URL: https://git.openjdk.org/loom/commit/1084fd24eb118d4131538c2a3ead714db7d0357b 8299973: Replace NULL with nullptr in share/utilities/ Reviewed-by: coleenp, stefank, dholmes, kbarrett ! src/hotspot/share/utilities/bitMap.cpp ! src/hotspot/share/utilities/chunkedList.hpp ! src/hotspot/share/utilities/concurrentHashTable.hpp ! src/hotspot/share/utilities/concurrentHashTable.inline.hpp ! src/hotspot/share/utilities/concurrentHashTableTasks.inline.hpp ! src/hotspot/share/utilities/copy.cpp ! src/hotspot/share/utilities/debug.cpp ! src/hotspot/share/utilities/decoder.cpp ! src/hotspot/share/utilities/decoder.hpp ! src/hotspot/share/utilities/decoder_elf.cpp ! src/hotspot/share/utilities/decoder_elf.hpp ! src/hotspot/share/utilities/defaultStream.hpp ! src/hotspot/share/utilities/elfFile.cpp ! src/hotspot/share/utilities/elfFile.hpp ! src/hotspot/share/utilities/elfFuncDescTable.cpp ! src/hotspot/share/utilities/elfFuncDescTable.hpp ! src/hotspot/share/utilities/elfStringTable.cpp ! src/hotspot/share/utilities/elfSymbolTable.cpp ! src/hotspot/share/utilities/events.cpp ! src/hotspot/share/utilities/events.hpp ! src/hotspot/share/utilities/exceptions.cpp ! src/hotspot/share/utilities/exceptions.hpp ! src/hotspot/share/utilities/filterQueue.hpp ! src/hotspot/share/utilities/filterQueue.inline.hpp ! src/hotspot/share/utilities/globalDefinitions.cpp ! src/hotspot/share/utilities/growableArray.hpp ! src/hotspot/share/utilities/hashtable.cpp ! src/hotspot/share/utilities/hashtable.hpp ! src/hotspot/share/utilities/hashtable.inline.hpp ! src/hotspot/share/utilities/json.cpp ! src/hotspot/share/utilities/linkedlist.hpp ! src/hotspot/share/utilities/lockFreeStack.hpp ! src/hotspot/share/utilities/nativeCallStack.cpp ! src/hotspot/share/utilities/nativeCallStack.hpp ! src/hotspot/share/utilities/numberSeq.cpp ! src/hotspot/share/utilities/objectBitSet.inline.hpp ! src/hotspot/share/utilities/ostream.cpp ! src/hotspot/share/utilities/ostream.hpp ! src/hotspot/share/utilities/preserveException.cpp ! src/hotspot/share/utilities/resizeableResourceHash.hpp ! src/hotspot/share/utilities/resourceHash.hpp ! src/hotspot/share/utilities/stack.hpp ! src/hotspot/share/utilities/stack.inline.hpp ! src/hotspot/share/utilities/stringUtils.cpp ! src/hotspot/share/utilities/unsigned5.cpp ! src/hotspot/share/utilities/unsigned5.hpp ! src/hotspot/share/utilities/utf8.cpp ! src/hotspot/share/utilities/utf8.hpp ! src/hotspot/share/utilities/virtualizationSupport.cpp ! src/hotspot/share/utilities/vmError.cpp ! src/hotspot/share/utilities/vmError.hpp ! src/hotspot/share/utilities/xmlstream.cpp ! src/hotspot/share/utilities/xmlstream.hpp Changeset: 453dbd12 Author: Stefan Karlsson Date: 2023-01-19 13:49:14 +0000 URL: https://git.openjdk.org/loom/commit/453dbd12ee42731d7ebfd1a856338099429277c8 8298377: JfrVframeStream causes deadlocks in ZGC Co-authored-by: Erik ?sterlund Reviewed-by: eosterlund, mgronlun ! src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp ! src/hotspot/share/jfr/recorder/stacktrace/jfrStackTrace.cpp Changeset: d85243f0 Author: Claes Redestad Date: 2023-01-19 16:50:07 +0000 URL: https://git.openjdk.org/loom/commit/d85243f02b34d03bd7af63a5bcbc73f500f720df 8300647: Miscellaneous hashCode improvements in java.base Reviewed-by: stsypanov, rriggs ! src/java.base/share/classes/sun/security/util/DerValue.java ! src/java.base/unix/classes/java/lang/ProcessEnvironment.java Changeset: b317658d Author: Weijun Wang Date: 2023-01-19 18:32:08 +0000 URL: https://git.openjdk.org/loom/commit/b317658d69a477df04ded3cc2e107970f8a6e20d 8300399: EdDSA does not verify when there is no message Reviewed-by: ascarpino ! src/jdk.crypto.ec/share/classes/sun/security/ec/ed/EdDSASignature.java + test/jdk/sun/security/ec/ed/EmptyMessage.java Changeset: 80ab50b3 Author: Harshitha Onkar Date: 2023-01-19 18:43:54 +0000 URL: https://git.openjdk.org/loom/commit/80ab50b3389cbdae6bced7cea3f3a84b94c5bb82 8294680: Refactor scaled border rendering Co-authored-by: Alexey Ivanov Reviewed-by: rmahajan, achung, aivanov, jdv ! src/java.desktop/share/classes/com/sun/java/swing/SwingUtilities3.java ! src/java.desktop/share/classes/javax/swing/border/EtchedBorder.java ! src/java.desktop/share/classes/javax/swing/border/LineBorder.java ! src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBorders.java Changeset: 558d610b Author: Alexey Ivanov Date: 2023-01-19 19:32:58 +0000 URL: https://git.openjdk.org/loom/commit/558d610bebb6967b4cfe922f62f1c4ba0df7daaf 8299553: Make ScaledEtchedBorderTest.java comprehensive Reviewed-by: serb, honkar, achung ! test/jdk/javax/swing/border/EtchedBorder/ScaledEtchedBorderTest.java ! test/jdk/javax/swing/border/LineBorder/ScaledLineBorderTest.java ! test/jdk/javax/swing/border/LineBorder/ScaledTextFieldBorderTest.java Changeset: f2a1eb98 Author: Joe Darcy Date: 2023-01-19 22:11:23 +0000 URL: https://git.openjdk.org/loom/commit/f2a1eb980437b43cde222755dbf427d7916cf9e2 8300698: Missing @since tag for ClassFileFormatVersion.RELEASE_21 Reviewed-by: rriggs, mchung ! src/java.base/share/classes/java/lang/reflect/ClassFileFormatVersion.java Changeset: 62a2f232 Author: Christoph Langer Date: 2023-01-19 06:43:44 +0000 URL: https://git.openjdk.org/loom/commit/62a2f2327a7879724cab6d2d1d7d9ddfeb37d189 8300490: Spaces in name of MacOS Code Signing Identity are not correctly handled after JDK-8293550 Reviewed-by: erikj ! make/autoconf/jdk-options.m4 Changeset: 1c840506 Author: Ron Pressler Date: 2023-01-19 15:34:01 +0000 URL: https://git.openjdk.org/loom/commit/1c84050610e778010a2ce3a25d48fceee87af6cc 8298400: Virtual thread instability when stack overflows Co-authored-by: Fei Yang Co-authored-by: Richard Reingruber Reviewed-by: dlong, pchilanomate ! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp ! src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp ! src/hotspot/cpu/riscv/sharedRuntime_riscv.cpp ! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp ! src/hotspot/share/runtime/continuationFreezeThaw.cpp Changeset: dfcd65c2 Author: Jesper Wilhelmsson Date: 2023-01-19 22:27:45 +0000 URL: https://git.openjdk.org/loom/commit/dfcd65c2719cae19d41caf25f9aa0691568247e8 Merge ! make/autoconf/jdk-options.m4 ! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp ! src/hotspot/cpu/riscv/sharedRuntime_riscv.cpp ! src/hotspot/share/runtime/continuationFreezeThaw.cpp ! make/autoconf/jdk-options.m4 ! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp ! src/hotspot/cpu/riscv/sharedRuntime_riscv.cpp ! src/hotspot/share/runtime/continuationFreezeThaw.cpp Changeset: fbbb27e7 Author: Justin Lu Committer: Naoto Sato Date: 2023-01-19 22:35:24 +0000 URL: https://git.openjdk.org/loom/commit/fbbb27e77085c346a251e75527af8b21e76f7fc5 8300356: Refactor code examples to use @snippet in java.text.CollationElementIterator Reviewed-by: naoto ! src/java.base/share/classes/java/text/CollationElementIterator.java Changeset: 9b97699b Author: Justin Lu Committer: Naoto Sato Date: 2023-01-19 22:36:17 +0000 URL: https://git.openjdk.org/loom/commit/9b97699be50966672d382a6f288a543ab42bdfd0 8300586: Refactor code examples to use @snippet in java.text.Collator Reviewed-by: iris, lancea, naoto ! src/java.base/share/classes/java/text/Collator.java Changeset: 93a933d4 Author: Joe Darcy Date: 2023-01-19 23:24:01 +0000 URL: https://git.openjdk.org/loom/commit/93a933d4eff24f975dea32cd4b2b28ccbb50ed8f 8300400: Update --release 20 symbol information for JDK 20 build 32 Reviewed-by: iris, jjg ! src/jdk.compiler/share/data/symbols/java.base-K.sym.txt Changeset: 77f2d20e Author: Matias Saavedra Silva Committer: Ioi Lam Date: 2023-01-20 00:55:28 +0000 URL: https://git.openjdk.org/loom/commit/77f2d20e96712de725abffd9db5f28b1a48153b4 8287873: Add test for using -XX:+AutoCreateSharedArchive with different JDK versions Reviewed-by: iklam ! test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/TestAutoCreateSharedArchiveUpgrade.java ! test/lib/jdk/test/lib/artifacts/ArtifactManager.java ! test/lib/jdk/test/lib/artifacts/ArtifactResolver.java Changeset: e1893976 Author: Damon Fenacci Committer: Tobias Hartmann Date: 2023-01-20 08:16:28 +0000 URL: https://git.openjdk.org/loom/commit/e1893976d588c7c2bffe47a133ecd0e0e35f17ea 8296403: [TESTBUG] IR test runner methods in TestLongRangeChecks.java invoke wrong test methods Reviewed-by: thartmann, chagedorn, jiefu ! test/hotspot/jtreg/compiler/c2/irTests/TestLongRangeChecks.java Changeset: 49d60fee Author: Daniel Fuchs Date: 2023-01-20 09:23:37 +0000 URL: https://git.openjdk.org/loom/commit/49d60fee49b9f5f7182dcd1557d9b2f886901100 8300172: java/net/httpclient/MappingResponseSubscriber.java failed with java.net.ConnectException Reviewed-by: jpai ! test/jdk/java/net/httpclient/MappingResponseSubscriber.java Changeset: eca64795 Author: Johan Sj?len Date: 2023-01-20 09:57:20 +0000 URL: https://git.openjdk.org/loom/commit/eca64795be63c599a637ce2a7f740b2d0a1ec9bc 8300087: Replace NULL with nullptr in share/cds/ Reviewed-by: dholmes, iklam ! src/hotspot/share/cds/archiveBuilder.cpp ! src/hotspot/share/cds/archiveBuilder.hpp ! src/hotspot/share/cds/archiveHeapLoader.cpp ! src/hotspot/share/cds/archiveHeapLoader.hpp ! src/hotspot/share/cds/archiveUtils.cpp ! src/hotspot/share/cds/archiveUtils.hpp ! src/hotspot/share/cds/archiveUtils.inline.hpp ! src/hotspot/share/cds/cdsHeapVerifier.cpp ! src/hotspot/share/cds/cdsHeapVerifier.hpp ! src/hotspot/share/cds/cdsProtectionDomain.cpp ! src/hotspot/share/cds/cds_globals.hpp ! src/hotspot/share/cds/classListParser.cpp ! src/hotspot/share/cds/classListParser.hpp ! src/hotspot/share/cds/classListWriter.cpp ! src/hotspot/share/cds/classListWriter.hpp ! src/hotspot/share/cds/classPrelinker.cpp ! src/hotspot/share/cds/cppVtables.cpp ! src/hotspot/share/cds/dumpAllocStats.hpp ! src/hotspot/share/cds/dumpTimeClassInfo.cpp ! src/hotspot/share/cds/dumpTimeClassInfo.hpp ! src/hotspot/share/cds/dynamicArchive.cpp ! src/hotspot/share/cds/dynamicArchive.hpp ! src/hotspot/share/cds/filemap.cpp ! src/hotspot/share/cds/filemap.hpp ! src/hotspot/share/cds/heapShared.cpp ! src/hotspot/share/cds/heapShared.hpp ! src/hotspot/share/cds/lambdaFormInvokers.cpp ! src/hotspot/share/cds/lambdaProxyClassDictionary.cpp ! src/hotspot/share/cds/lambdaProxyClassDictionary.hpp ! src/hotspot/share/cds/metaspaceShared.cpp ! src/hotspot/share/cds/unregisteredClasses.cpp Changeset: 26410c18 Author: Afshin Zafari Committer: Evgeny Astigeevich Date: 2023-01-20 10:17:07 +0000 URL: https://git.openjdk.org/loom/commit/26410c180b88b4342217fdad63f1221786d8c37b 8281213: Unsafe uses of long and size_t in MemReporterBase::diff_in_current_scale Reviewed-by: eastigeevich, kbarrett ! src/hotspot/share/services/memReporter.cpp ! src/hotspot/share/services/memReporter.hpp ! src/hotspot/share/utilities/globalDefinitions.hpp Changeset: 4562b402 Author: Coleen Phillimore Date: 2023-01-20 13:20:29 +0000 URL: https://git.openjdk.org/loom/commit/4562b402fbfedbc3b531b19bf55638b00973b680 8300682: InstanceKlassMiscStatus is a bad name Reviewed-by: fparain, dholmes ! src/hotspot/share/jvmci/vmStructs_jvmci.cpp ! src/hotspot/share/oops/instanceKlass.hpp + src/hotspot/share/oops/instanceKlassFlags.cpp = src/hotspot/share/oops/instanceKlassFlags.hpp - src/hotspot/share/oops/instanceKlassMiscStatus.cpp ! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotVMConfig.java Changeset: 97c611d0 Author: Tobias Holenstein Date: 2023-01-20 14:20:32 +0000 URL: https://git.openjdk.org/loom/commit/97c611d029b614bb462a8f5398ea75b2715c3f07 8289748: C2 compiled code crashes with SIGFPE with -XX:+StressLCM and -XX:+StressGCM Reviewed-by: thartmann, chagedorn, kvn ! src/hotspot/share/opto/loopTransform.cpp + test/hotspot/jtreg/compiler/loopopts/TestRemoveEmptyCountedLoop.java Changeset: 623ba5b6 Author: Thomas Schatzl Date: 2023-01-20 14:31:06 +0000 URL: https://git.openjdk.org/loom/commit/623ba5b6dc0273eb4647e39e8aaa143dc8c9036e 8300653: G1EvacInfo should use common naming scheme for collection set Reviewed-by: ayang, iwalulya ! src/hotspot/share/gc/g1/g1EvacInfo.hpp ! src/hotspot/share/gc/g1/g1Trace.cpp ! src/hotspot/share/gc/g1/g1YoungCollector.cpp ! src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.cpp Changeset: b2d36221 Author: Hannes Walln?fer Date: 2023-01-20 14:50:35 +0000 URL: https://git.openjdk.org/loom/commit/b2d3622115ce0b4c0647c7b79f28c075dfcdebbc 8299896: Reduce enum values of HtmlLinkInfo.Kind Reviewed-by: jjg ! 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/AbstractTreeWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AllClassesIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AnnotationTypeMemberWriterImpl.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/ClassWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ConstantsSummaryWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/EnumConstantWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/FieldWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlLinkFactory.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlLinkInfo.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlSerialFieldWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/IndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/MethodWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/NestedClassWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PropertyWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SerializedFormWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Signatures.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TagletWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/links/LinkFactory.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/links/LinkInfo.java ! test/langtools/jdk/javadoc/doclet/testInterface/TestInterface.java Changeset: c6d56003 Author: Stuart Marks Date: 2023-01-20 16:33:48 +0000 URL: https://git.openjdk.org/loom/commit/c6d560039682ec52efa6fa7755d2aa86f20e1148 8038146: Clarify Map.Entry's connection to the underlying map Reviewed-by: alanb ! src/java.base/share/classes/java/util/AbstractMap.java ! src/java.base/share/classes/java/util/Map.java ! src/java.base/share/classes/java/util/NavigableMap.java ! src/java.base/share/classes/java/util/TreeMap.java Changeset: 92d8326e Author: Ralf Schmelter Date: 2023-01-20 16:36:45 +0000 URL: https://git.openjdk.org/loom/commit/92d8326e4037605897d7c4eb4b3edb63a2fc11b0 8299827: Add resolved IP address in connection exception for sockets Reviewed-by: alanb, vtewari, jpai, dfuchs ! src/java.base/share/classes/sun/net/util/SocketExceptions.java ! test/jdk/java/net/Socket/ExceptionText.java Changeset: e8038557 Author: Darragh Clarke Committer: Daniel Fuchs Date: 2023-01-20 17:00:53 +0000 URL: https://git.openjdk.org/loom/commit/e8038557080ba686829395b49658a899bea15d35 8299863: URLFromURITest.java should import org.junit.jupiter.api.Test Reviewed-by: dfuchs, cstein ! test/jdk/java/net/URL/URLFromURITest.java Changeset: facd4151 Author: Mandy Chung Date: 2023-01-20 17:25:18 +0000 URL: https://git.openjdk.org/loom/commit/facd41511b972e940ecab3bc57f5f23efca43343 8297757: VarHandles.getStaticFieldFromBaseAndOffset should get the receiver type from VarHandle Reviewed-by: psandoz, alanb ! src/java.base/share/classes/java/lang/invoke/VarHandles.java ! src/java.base/share/classes/java/lang/invoke/X-VarHandle.java.template Changeset: 9d44dd0c Author: Volodymyr Paprotski Committer: Jamil Nimeh Date: 2023-01-20 19:51:28 +0000 URL: https://git.openjdk.org/loom/commit/9d44dd0cca620ef8e16e0c4306e6e54d8de6d1e8 8297972: Poly1305 Endianness on ByteBuffer not enforced Reviewed-by: jnimeh ! src/java.base/share/classes/sun/security/util/math/intpoly/IntegerPolynomial1305.java ! test/jdk/com/sun/crypto/provider/Cipher/ChaCha20/unittest/java.base/com/sun/crypto/provider/Poly1305IntrinsicFuzzTest.java Changeset: 5784eb7b Author: Chris Plummer Date: 2023-01-20 19:58:54 +0000 URL: https://git.openjdk.org/loom/commit/5784eb7b68a880e130fda5f07c527187764038a2 8300721: Cleanup ProblemList-svc-vthread.txt Reviewed-by: alanb, lmesnik ! test/hotspot/jtreg/ProblemList-svc-vthread.txt Changeset: 7c2f77a4 Author: Scott Gibbons Committer: Sandhya Viswanathan Date: 2023-01-21 00:07:31 +0000 URL: https://git.openjdk.org/loom/commit/7c2f77a42293eb79829fce99bfce82e89a5df6d7 8300584: Accelerate AVX-512 CRC32C for small buffers Reviewed-by: kvn, sviswanathan ! src/hotspot/cpu/x86/stubGenerator_x86_64.cpp Changeset: e1ee6727 Author: Sergey Bylokhov Date: 2023-01-21 07:09:00 +0000 URL: https://git.openjdk.org/loom/commit/e1ee6727f70209cf046cafba109835ad4acc1c23 8300725: Improve performance of ColorConvertOp for default destinations with alpha Reviewed-by: prr ! src/java.desktop/share/classes/sun/java2d/cmm/lcms/LCMSImageLayout.java ! src/java.desktop/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java ! test/jdk/sun/java2d/cmm/ColorConvertOp/ColCvtAlphaDifferentSrcDst.java Changeset: 5331a3ef Author: Justin King Committer: Thomas Stuefe Date: 2023-01-21 08:57:14 +0000 URL: https://git.openjdk.org/loom/commit/5331a3ef739166b2a2b0871fc9615f2c99effa89 8298908: Instrument Metaspace for ASan Reviewed-by: stuefe, ihse, iklam ! make/autoconf/jdk-options.m4 ! src/hotspot/share/memory/metaspace/chunkManager.cpp ! src/hotspot/share/memory/metaspace/chunkManager.hpp ! src/hotspot/share/memory/metaspace/virtualSpaceNode.cpp + src/hotspot/share/sanitizers/address.h ! test/hotspot/gtest/metaspace/test_virtualspacenode.cpp Changeset: 06394ee8 Author: Doug Simon Date: 2023-01-21 11:31:44 +0000 URL: https://git.openjdk.org/loom/commit/06394ee8b110fe8e37a3b9e582f5dfbf225a3d89 8300590: [JVMCI] BytecodeFrame.equals is broken Reviewed-by: adinn, dlong ! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/BytecodeFrame.java + test/hotspot/jtreg/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestBytecodeFrame.java Changeset: bb42e61a Author: Claes Redestad Date: 2023-01-21 11:54:51 +0000 URL: https://git.openjdk.org/loom/commit/bb42e61a6176a7f4f9485efa47a248b23b09a16d 8300493: Use ArraysSupport.vectorizedHashCode in j.u.zip.ZipCoder Reviewed-by: alanb, lancea ! src/java.base/share/classes/java/lang/System.java ! src/java.base/share/classes/java/util/zip/ZipCoder.java ! src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java + test/micro/org/openjdk/bench/java/util/zip/ZipFileOpen.java Changeset: a6c2a2ae Author: Dan Lutker Committer: Julian Waters Date: 2023-01-21 12:05:35 +0000 URL: https://git.openjdk.org/loom/commit/a6c2a2ae79be6810dca55b13bfc8a7625f25d48d 8300692: GCC 12 reports some compiler warnings in bundled freetype Reviewed-by: erikj, serb, jwaters ! make/modules/java.desktop/lib/Awt2dLibraries.gmk Changeset: c8dd7583 Author: Justin King Committer: Kim Barrett Date: 2023-01-21 15:03:26 +0000 URL: https://git.openjdk.org/loom/commit/c8dd7583a92082bcd2a4dfd5429889e7f0a44050 8300260: Remove metaprogramming/isSame.hpp Reviewed-by: tschatzl, kbarrett - src/hotspot/share/metaprogramming/isSame.hpp ! src/hotspot/share/oops/accessBackend.hpp ! src/hotspot/share/runtime/atomic.hpp ! src/hotspot/share/utilities/devirtualizer.inline.hpp - test/hotspot/gtest/metaprogramming/test_isSame.cpp ! test/hotspot/gtest/metaprogramming/test_isSigned.cpp ! test/hotspot/gtest/metaprogramming/test_primitiveConversions.cpp Changeset: 67b1c890 Author: Tagir F. Valeev Date: 2023-01-21 18:36:31 +0000 URL: https://git.openjdk.org/loom/commit/67b1c890b3351c1b1317477dd12316d18c01dd72 8294693: Add Collections.shuffle overload that accepts RandomGenerator interface Reviewed-by: smarks, darcy ! src/java.base/share/classes/java/util/Collections.java + test/jdk/java/util/Collections/Shuffle.java Changeset: cbfc069f Author: Andrey Turbanov Date: 2023-01-21 19:25:18 +0000 URL: https://git.openjdk.org/loom/commit/cbfc069f6a27b272577ddf2abfbc7a3b64739571 8300731: Avoid unnecessary array fill after creation in PaletteBuilder Reviewed-by: prr, serb ! src/java.desktop/share/classes/com/sun/imageio/plugins/common/PaletteBuilder.java Changeset: 3ea4eac1 Author: Sergey Bylokhov Date: 2023-01-21 21:51:41 +0000 URL: https://git.openjdk.org/loom/commit/3ea4eac1450954db095ef56385baa3aceea524ea 8300817: The build is broken after JDK-8294693 Reviewed-by: tvaleev, darcy ! src/java.base/share/classes/java/util/Collections.java Changeset: 7ced08d4 Author: Jatin Bhateja Date: 2023-01-22 06:47:00 +0000 URL: https://git.openjdk.org/loom/commit/7ced08d4ec1b4aec534bd9061f52dd72fa2270f6 8300638: Tier1 IR Test failure after JDK-8298632 on macosx-x64-debug Reviewed-by: kvn, pli ! test/hotspot/jtreg/compiler/vectorization/runner/ArrayIndexFillTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/ArrayInvariantFillTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/ArrayShiftOpTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/ArrayTypeConvertTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/BasicBooleanOpTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/BasicByteOpTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/BasicCharOpTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/BasicDoubleOpTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/BasicFloatOpTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/BasicLongOpTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/LoopArrayIndexComputeTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/LoopCombinedOpTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/LoopLiveOutNodesTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/LoopRangeStrideTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/LoopReductionOpTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/MultipleLoopsTest.java Changeset: 030b071d Author: Raffaello Giulietti Date: 2023-01-22 12:45:52 +0000 URL: https://git.openjdk.org/loom/commit/030b071db1fb6197a2633a04b20aa95432a903bc 8300207: Add a pre-check for the number of canonical equivalent permutations in j.u.r.Pattern Reviewed-by: smarks ! src/java.base/share/classes/java/util/regex/Pattern.java Changeset: 45e4e009 Author: Tobias Hartmann Date: 2023-01-23 06:06:32 +0000 URL: https://git.openjdk.org/loom/commit/45e4e00981ef8b4bf143afce0889698319273c1d 8300079: SIGSEGV in LibraryCallKit::inline_string_copy due to constant NULL src argument Reviewed-by: roland, chagedorn, kvn ! src/hotspot/share/opto/library_call.cpp + test/hotspot/jtreg/compiler/intrinsics/string/TestCopyValueOf.java Changeset: 836198a4 Author: Adam Sotona Date: 2023-01-23 08:14:51 +0000 URL: https://git.openjdk.org/loom/commit/836198a4009c4a3f10a76dc8734e4792bb2509ba 8300591: @SuppressWarnings option "lossy-conversions" missing from jdk.compiler module javadoc Reviewed-by: jjg, darcy ! src/jdk.compiler/share/classes/module-info.java ! src/jdk.compiler/share/man/javac.1 Changeset: 11aadc9d Author: Prasanta Sadhukhan Date: 2023-01-23 10:18:23 +0000 URL: https://git.openjdk.org/loom/commit/11aadc9d98d364b91114c028c7e2eff8de2f2bf0 8244400: MenuItem may cache the size and did not update it when the screen DPI is changed Reviewed-by: serb, aivanov ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicMenuItemUI.java ! test/jdk/javax/swing/GraphicsConfigNotifier/StalePreferredSize.java Changeset: f307e8c6 Author: Fredrik Bredberg Committer: Robbin Ehn Date: 2023-01-23 10:43:50 +0000 URL: https://git.openjdk.org/loom/commit/f307e8c667895c302e916124751456a5443353ce 8299795: Relativize locals in interpreter frames Reviewed-by: coleenp, rehn, pchilanomate, mdoerr, fyang ! src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp ! src/hotspot/cpu/aarch64/continuationHelper_aarch64.inline.hpp ! src/hotspot/cpu/aarch64/frame_aarch64.cpp ! src/hotspot/cpu/aarch64/frame_aarch64.inline.hpp ! src/hotspot/cpu/aarch64/interp_masm_aarch64.hpp ! src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp ! src/hotspot/cpu/arm/frame_arm.cpp ! src/hotspot/cpu/arm/frame_arm.inline.hpp ! src/hotspot/cpu/arm/interp_masm_arm.hpp ! src/hotspot/cpu/arm/templateInterpreterGenerator_arm.cpp ! src/hotspot/cpu/ppc/continuationFreezeThaw_ppc.inline.hpp ! src/hotspot/cpu/ppc/continuationHelper_ppc.inline.hpp ! src/hotspot/cpu/ppc/frame_ppc.cpp ! src/hotspot/cpu/ppc/frame_ppc.inline.hpp ! src/hotspot/cpu/ppc/interp_masm_ppc_64.cpp ! src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp ! src/hotspot/cpu/riscv/continuationFreezeThaw_riscv.inline.hpp ! src/hotspot/cpu/riscv/continuationHelper_riscv.inline.hpp ! src/hotspot/cpu/riscv/frame_riscv.cpp ! src/hotspot/cpu/riscv/frame_riscv.inline.hpp ! src/hotspot/cpu/riscv/interp_masm_riscv.hpp ! src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp ! src/hotspot/cpu/s390/frame_s390.cpp ! src/hotspot/cpu/s390/frame_s390.inline.hpp ! src/hotspot/cpu/x86/continuationFreezeThaw_x86.inline.hpp ! src/hotspot/cpu/x86/continuationHelper_x86.inline.hpp ! src/hotspot/cpu/x86/frame_x86.cpp ! src/hotspot/cpu/x86/frame_x86.hpp ! src/hotspot/cpu/x86/frame_x86.inline.hpp ! src/hotspot/cpu/x86/interp_masm_x86.hpp ! src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp ! src/hotspot/cpu/zero/frame_zero.cpp ! src/hotspot/cpu/zero/frame_zero.inline.hpp ! src/hotspot/share/runtime/frame.cpp ! src/hotspot/share/runtime/frame.hpp ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Frame.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/aarch64/AARCH64Frame.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/ppc64/PPC64Frame.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/riscv64/RISCV64Frame.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/x86/X86Frame.java Changeset: 5a4945c0 Author: Emanuel Peter Date: 2023-01-23 13:10:42 +0000 URL: https://git.openjdk.org/loom/commit/5a4945c0d95423d0ab07762c915e9cb4d3c66abb 8299975: Limit underflow protection CMoveINode in PhaseIdealLoop::do_unroll must also protect type from underflow Reviewed-by: roland, chagedorn ! src/hotspot/share/opto/loopTransform.cpp + test/hotspot/jtreg/compiler/loopopts/TestCMoveLimitType.java Changeset: 03a9a88e Author: Justin King Committer: Thomas Schatzl Date: 2023-01-23 16:03:28 +0000 URL: https://git.openjdk.org/loom/commit/03a9a88efbb68537e24b7de28c5b81d6cd8fdb04 8300265: Remove metaprogramming/isSigned.hpp Reviewed-by: kbarrett, tschatzl ! src/hotspot/share/memory/metaspace/counters.hpp - src/hotspot/share/metaprogramming/isSigned.hpp ! src/hotspot/share/runtime/atomic.hpp ! src/hotspot/share/utilities/population_count.hpp - test/hotspot/gtest/metaprogramming/test_isSigned.cpp ! test/hotspot/gtest/utilities/test_count_leading_zeros.cpp Changeset: 542bfe61 Author: Brian Burkhalter Date: 2023-01-23 17:05:36 +0000 URL: https://git.openjdk.org/loom/commit/542bfe61e67b72bebff45e7382ec3f40bdab9aae 8300587: (bf) Some covariant overrides are missing @since tags Reviewed-by: lancea, iris ! src/java.base/share/classes/java/nio/MappedByteBuffer.java ! src/java.base/share/classes/java/nio/X-Buffer.java.template Changeset: a56598f5 Author: Brian Burkhalter Date: 2023-01-23 17:12:49 +0000 URL: https://git.openjdk.org/loom/commit/a56598f5a534cc9223367e7faa8433ea38661db9 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly Reviewed-by: dholmes, alanb ! make/test/JtregNativeJdk.gmk ! src/hotspot/share/prims/jni.cpp ! src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template + test/jdk/java/nio/jni/NewDirectByteBuffer.java + test/jdk/java/nio/jni/libNewDirectByteBuffer.c Changeset: 079255e3 Author: Per Minborg Date: 2023-01-23 17:40:13 +0000 URL: https://git.openjdk.org/loom/commit/079255e312a60584d748babcd320eacec99c5a02 8300864: Declare some fields in java.io as final Reviewed-by: rriggs, lancea ! src/java.base/share/classes/java/io/BufferedInputStream.java ! src/java.base/share/classes/java/io/BufferedReader.java ! src/java.base/share/classes/java/io/ExpiringCache.java ! src/java.base/share/classes/java/io/File.java ! src/java.base/share/classes/java/io/FileOutputStream.java ! src/java.base/share/classes/java/io/ObjectStreamClass.java ! src/java.base/share/classes/java/io/StringReader.java ! src/java.base/share/classes/java/io/StringWriter.java Changeset: a7f035db Author: Per Minborg Date: 2023-01-23 17:47:01 +0000 URL: https://git.openjdk.org/loom/commit/a7f035db762ce44b72733094422488047c9ad738 8300868: Reduce visibility in java.io.SerialCallbackContext Reviewed-by: rriggs ! src/java.base/share/classes/java/io/SerialCallbackContext.java Changeset: 4525aa31 Author: Per Minborg Date: 2023-01-23 17:53:20 +0000 URL: https://git.openjdk.org/loom/commit/4525aa318a1025e19d4ed9924ed25992be0075e9 8300867: Fix document issues in java.io Reviewed-by: alanb, lancea, iris ! src/java.base/share/classes/java/io/BufferedInputStream.java ! src/java.base/share/classes/java/io/DeleteOnExitHook.java ! src/java.base/share/classes/java/io/File.java ! src/java.base/share/classes/java/io/ObjectInputStream.java ! src/java.base/share/classes/java/io/ObjectOutputStream.java ! src/java.base/share/classes/java/io/ObjectStreamConstants.java Changeset: 86fed796 Author: Mandy Chung Date: 2023-01-23 17:58:53 +0000 URL: https://git.openjdk.org/loom/commit/86fed79670c109fc3a7fbe1eb2b1485c6dd99e2f 8300693: Lower the compile threshold and reduce the iterations of warmup loop in VarHandles tests Reviewed-by: jvernee, dholmes, psandoz ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessBoolean.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessByte.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessChar.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessDouble.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessFloat.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessInt.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessLong.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessShort.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessString.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsChar.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsDouble.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsFloat.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsInt.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsLong.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsShort.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessBoolean.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessByte.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessChar.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessDouble.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessFloat.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessInt.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessLong.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessShort.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessString.java ! test/jdk/java/lang/invoke/VarHandles/X-VarHandleTestAccess.java.template ! test/jdk/java/lang/invoke/VarHandles/X-VarHandleTestByteArrayView.java.template ! test/jdk/java/lang/invoke/VarHandles/X-VarHandleTestMethodHandleAccess.java.template Changeset: 1a3cb8c5 Author: Jamil Nimeh Date: 2023-01-23 18:05:48 +0000 URL: https://git.openjdk.org/loom/commit/1a3cb8c5018bc016c2ad6b078e4abe13b39d151c 8296343: CPVE thrown on missing content-length in OCSP response Reviewed-by: mullan, rhalade ! src/java.base/share/classes/sun/security/provider/certpath/OCSP.java ! test/jdk/java/security/cert/CertPathValidator/OCSP/GetAndPostTests.java ! test/jdk/java/security/testlibrary/SimpleOCSPServer.java ! test/jdk/javax/net/ssl/Stapling/HttpsUrlConnClient.java ! test/jdk/javax/net/ssl/Stapling/SSLEngineWithStapling.java ! test/jdk/javax/net/ssl/Stapling/SSLSocketWithStapling.java ! test/jdk/javax/net/ssl/Stapling/StapleEnableProps.java + test/jdk/sun/security/provider/certpath/OCSP/OCSPNoContentLength.java ! test/jdk/sun/security/ssl/Stapling/java.base/sun/security/ssl/StatusResponseManagerTests.java Changeset: d1173508 Author: Per Minborg Date: 2023-01-23 19:09:39 +0000 URL: https://git.openjdk.org/loom/commit/d11735087507a17204bd81ae565409a3b7e881ae 8300866: Declare some classes final in java.io Reviewed-by: alanb ! src/java.base/share/classes/java/io/ExpiringCache.java ! src/java.base/share/classes/java/io/ObjectInputStream.java ! src/java.base/share/classes/java/io/ObjectOutputStream.java ! src/java.base/share/classes/java/io/ObjectStreamClass.java ! src/java.base/share/classes/java/io/ProxyingConsole.java Changeset: dcf1523b Author: Justin Lu Committer: Naoto Sato Date: 2023-01-23 19:31:36 +0000 URL: https://git.openjdk.org/loom/commit/dcf1523bf2dba234371190a70a41cfcb77907196 8300077: Refactor code examples to use @snippet in java.text.ChoiceFormat Reviewed-by: lancea, iris, naoto ! src/java.base/share/classes/java/text/ChoiceFormat.java Changeset: 0ea2dd1f Author: Erik Joelsson Date: 2023-01-23 20:51:13 +0000 URL: https://git.openjdk.org/loom/commit/0ea2dd1f77a7925d02ae0136bb40dcc8abf354d9 8146132: Excessive output from make test-image Reviewed-by: ihse ! make/common/NativeCompilation.gmk ! make/common/TestFilesCompilation.gmk Changeset: fd752178 Author: David Holmes Date: 2023-01-23 07:44:32 +0000 URL: https://git.openjdk.org/loom/commit/fd752178e364fb5deeec062bef3dde1fea1dcbe3 8290919: Update nroff pages in JDK 20 before RC Reviewed-by: iris, alanb ! src/java.base/share/man/java.1 ! src/java.base/share/man/keytool.1 ! src/java.rmi/share/man/rmiregistry.1 ! src/java.scripting/share/man/jrunscript.1 ! src/jdk.compiler/share/man/javac.1 ! src/jdk.compiler/share/man/serialver.1 ! src/jdk.hotspot.agent/share/man/jhsdb.1 ! src/jdk.httpserver/share/man/jwebserver.1 ! src/jdk.jartool/share/man/jar.1 ! src/jdk.jartool/share/man/jarsigner.1 ! src/jdk.javadoc/share/man/javadoc.1 ! src/jdk.jcmd/share/man/jcmd.1 ! src/jdk.jcmd/share/man/jinfo.1 ! src/jdk.jcmd/share/man/jmap.1 ! src/jdk.jcmd/share/man/jps.1 ! src/jdk.jcmd/share/man/jstack.1 ! src/jdk.jcmd/share/man/jstat.1 ! src/jdk.jconsole/share/man/jconsole.1 ! src/jdk.jdeps/share/man/javap.1 ! src/jdk.jdeps/share/man/jdeprscan.1 ! src/jdk.jdeps/share/man/jdeps.1 ! src/jdk.jdi/share/man/jdb.1 ! src/jdk.jfr/share/man/jfr.1 ! src/jdk.jlink/share/man/jlink.1 ! src/jdk.jlink/share/man/jmod.1 ! src/jdk.jpackage/share/man/jpackage.1 ! src/jdk.jshell/share/man/jshell.1 ! src/jdk.jstatd/share/man/jstatd.1 Changeset: 56dc3b08 Author: Jesper Wilhelmsson Date: 2023-01-23 20:58:40 +0000 URL: https://git.openjdk.org/loom/commit/56dc3b08a62f651835c5bccca987d93ba2bb8961 Merge ! src/jdk.compiler/share/man/javac.1 ! src/jdk.compiler/share/man/javac.1 Changeset: f79e5871 Author: Andrey Turbanov Date: 2023-01-23 21:05:14 +0000 URL: https://git.openjdk.org/loom/commit/f79e5871813ab9554e3250cf4b36e92522bddd0a 8300828: Avoid unnecessary array fill after creation in com.sun.media.sound Reviewed-by: serb, prr ! src/java.desktop/share/classes/com/sun/media/sound/ModelInstrument.java ! src/java.desktop/share/classes/com/sun/media/sound/SoftChannel.java ! src/java.desktop/share/classes/com/sun/media/sound/SoftPerformer.java Changeset: 77a50105 Author: David Holmes Date: 2023-01-24 00:21:29 +0000 URL: https://git.openjdk.org/loom/commit/77a50105f0c4a4cb7286dda13c633f1e69295210 8286775: Remove identical per-compiler definitions of unsigned integral jtypes Reviewed-by: kbarrett, coleenp ! src/hotspot/share/utilities/globalDefinitions.hpp ! src/hotspot/share/utilities/globalDefinitions_gcc.hpp ! src/hotspot/share/utilities/globalDefinitions_visCPP.hpp ! src/hotspot/share/utilities/globalDefinitions_xlc.hpp Changeset: b5ee3d1f Author: Tingjun Yuan Committer: Sergey Bylokhov Date: 2023-01-24 01:25:29 +0000 URL: https://git.openjdk.org/loom/commit/b5ee3d1f2abf5af86438ac4c9e3da3cc026dffd3 8299497: Usage of constructors of primitive wrapper classes should be avoided in java.desktop API docs Reviewed-by: serb, prr ! src/java.desktop/share/classes/java/awt/font/LineBreakMeasurer.java ! src/java.desktop/share/classes/java/awt/image/renderable/ParameterBlock.java Changeset: 0323609f Author: Justin Lu Committer: Naoto Sato Date: 2023-01-24 02:05:05 +0000 URL: https://git.openjdk.org/loom/commit/0323609f44e68ba8d992419a23be7066838a0e01 8300706: Use @snippet in java.text Reviewed-by: naoto ! src/java.base/share/classes/java/text/BreakIterator.java ! src/java.base/share/classes/java/text/CharacterIterator.java ! src/java.base/share/classes/java/text/DateFormatSymbols.java ! src/java.base/share/classes/java/text/DecimalFormat.java ! src/java.base/share/classes/java/text/NumberFormat.java Changeset: 2da2e5a0 Author: Jamil Nimeh Date: 2023-01-24 02:09:48 +0000 URL: https://git.openjdk.org/loom/commit/2da2e5a0e80e6c54c848cf39bee534fa9b7086b1 8300946: Add sun/security/provider/certpath/OCSP/OCSPNoContentLength to ProblemList Reviewed-by: jpai ! test/jdk/ProblemList.txt Changeset: 937ba1ca Author: david Committer: Alexey Semenyuk Date: 2023-01-24 03:07:16 +0000 URL: https://git.openjdk.org/loom/commit/937ba1cadbe1e8663ad5663e5a2048b21dc63527 8300111: Add rpath for common lib locations for jpackageapplauncher Reviewed-by: ihse, asemenyuk, almatvee ! make/modules/jdk.jpackage/Lib.gmk Changeset: afd5921f Author: Ioi Lam Date: 2023-01-24 04:07:06 +0000 URL: https://git.openjdk.org/loom/commit/afd5921f1cc5b9a05a7ec3a3690a06bb5e05d23a 8298610: Refactor archiving of ConstantPool::resolved_references() Reviewed-by: dholmes, ccheung ! src/hotspot/share/cds/heapShared.cpp ! src/hotspot/share/cds/heapShared.hpp ! src/hotspot/share/oops/constantPool.cpp ! src/hotspot/share/oops/constantPool.hpp ! src/hotspot/share/oops/cpCache.cpp ! src/hotspot/share/oops/cpCache.hpp Changeset: b3822f50 Author: Justin Lu Committer: Naoto Sato Date: 2023-01-24 04:35:46 +0000 URL: https://git.openjdk.org/loom/commit/b3822f50c85524a00a045aa3a3d902f190e35906 8300589: Use @snippet and @linkplain in java.text.CollationKey and java.text.CompactNumberFormat Reviewed-by: lancea, naoto, iris ! src/java.base/share/classes/java/text/CollationKey.java ! src/java.base/share/classes/java/text/CompactNumberFormat.java Changeset: 6dd8723f Author: David Holmes Date: 2023-01-24 06:27:54 +0000 URL: https://git.openjdk.org/loom/commit/6dd8723f66a22e626d98c74cff0b0b344a62626d 8290918: Initial nroff manpage generation for JDK 21 Reviewed-by: lancea, iris, darcy ! src/java.base/share/man/keytool.1 ! src/java.rmi/share/man/rmiregistry.1 ! src/java.scripting/share/man/jrunscript.1 ! src/jdk.compiler/share/man/javac.1 ! src/jdk.compiler/share/man/serialver.1 ! src/jdk.hotspot.agent/share/man/jhsdb.1 ! src/jdk.httpserver/share/man/jwebserver.1 ! src/jdk.jartool/share/man/jar.1 ! src/jdk.jartool/share/man/jarsigner.1 ! src/jdk.javadoc/share/man/javadoc.1 ! src/jdk.jcmd/share/man/jcmd.1 ! src/jdk.jcmd/share/man/jinfo.1 ! src/jdk.jcmd/share/man/jmap.1 ! src/jdk.jcmd/share/man/jps.1 ! src/jdk.jcmd/share/man/jstack.1 ! src/jdk.jcmd/share/man/jstat.1 ! src/jdk.jconsole/share/man/jconsole.1 ! src/jdk.jdeps/share/man/javap.1 ! src/jdk.jdeps/share/man/jdeprscan.1 ! src/jdk.jdeps/share/man/jdeps.1 ! src/jdk.jdi/share/man/jdb.1 ! src/jdk.jfr/share/man/jfr.1 ! src/jdk.jlink/share/man/jlink.1 ! src/jdk.jlink/share/man/jmod.1 ! src/jdk.jpackage/share/man/jpackage.1 ! src/jdk.jshell/share/man/jshell.1 ! src/jdk.jstatd/share/man/jstatd.1 Changeset: 2292ce13 Author: Thomas Stuefe Date: 2023-01-24 06:35:26 +0000 URL: https://git.openjdk.org/loom/commit/2292ce137c16accf0622600d5a096403b8a8058d 8294677: chunklevel::MAX_CHUNK_WORD_SIZE too small for some applications Reviewed-by: simonis, phh ! src/hotspot/share/memory/metaspace/chunklevel.hpp ! src/hotspot/share/memory/metaspace/metaspaceSettings.hpp ! test/hotspot/gtest/metaspace/test_chunkManager_stress.cpp ! test/hotspot/gtest/metaspace/test_metachunk.cpp ! test/hotspot/gtest/metaspace/test_metaspace_misc.cpp ! test/hotspot/gtest/metaspace/test_virtualspacenode.cpp ! test/hotspot/jtreg/runtime/CompressedOops/CompressedClassSpaceSize.java ! test/hotspot/jtreg/runtime/Metaspace/elastic/Settings.java ! test/hotspot/jtreg/runtime/Metaspace/elastic/TestMetaspaceAllocationMT1.java ! test/hotspot/jtreg/runtime/Metaspace/elastic/TestMetaspaceAllocationMT2.java Changeset: 57f2d48e Author: Per Minborg Date: 2023-01-24 07:43:29 +0000 URL: https://git.openjdk.org/loom/commit/57f2d48e1e11eb2f87be7e47ab943031696e51f5 8300863: Remove C-style array declarations in java.io Reviewed-by: alanb, rriggs, darcy, iris ! src/java.base/share/classes/java/io/BufferedOutputStream.java ! src/java.base/share/classes/java/io/BufferedWriter.java ! src/java.base/share/classes/java/io/ByteArrayInputStream.java ! src/java.base/share/classes/java/io/ByteArrayOutputStream.java ! src/java.base/share/classes/java/io/CharArrayWriter.java ! src/java.base/share/classes/java/io/File.java ! src/java.base/share/classes/java/io/PipedReader.java ! src/java.base/share/classes/java/io/StreamTokenizer.java Changeset: 544c16e0 Author: Matthias Baesken Date: 2023-01-24 08:05:03 +0000 URL: https://git.openjdk.org/loom/commit/544c16e0bdd4335b2624158fd1f6521984aa5079 8300266: Detect Virtualization on Linux aarch64 Reviewed-by: stuefe, lucy ! src/hotspot/cpu/aarch64/vm_version_aarch64.cpp ! src/hotspot/cpu/aarch64/vm_version_aarch64.hpp Changeset: 048705c0 Author: Justin King Committer: Thomas Schatzl Date: 2023-01-24 11:39:18 +0000 URL: https://git.openjdk.org/loom/commit/048705c04967d106dedc09a4cf2325a3b46ef4e7 8300910: Remove metaprogramming/integralConstant.hpp Reviewed-by: kbarrett, tschatzl - src/hotspot/share/metaprogramming/integralConstant.hpp ! src/hotspot/share/oops/accessBackend.hpp ! src/hotspot/share/oops/accessBackend.inline.hpp ! src/hotspot/share/oops/accessDecorators.hpp ! src/hotspot/share/oops/markWord.hpp ! src/hotspot/share/oops/oopHandle.hpp ! src/hotspot/share/oops/oopsHierarchy.hpp ! src/hotspot/share/runtime/os.hpp Changeset: 859ca75b Author: Thomas Schatzl Date: 2023-01-24 17:15:53 +0000 URL: https://git.openjdk.org/loom/commit/859ca75b4c269bc71d1e9638b5b02bbb6386166d 8300862: Remove some G1 collection set remembered set debugging code Reviewed-by: ayang, iwalulya ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1CollectedHeap.hpp Changeset: 3be5758b Author: Thomas Schatzl Date: 2023-01-24 17:33:35 +0000 URL: https://git.openjdk.org/loom/commit/3be5758bb413fb6b4dc6191d78ca38332d5153f1 8300769: Remove G1CollectionSet::_inc_bytes_used_before Reviewed-by: ayang, iwalulya ! src/hotspot/share/gc/g1/g1CollectionSet.cpp ! src/hotspot/share/gc/g1/g1CollectionSet.hpp ! src/hotspot/share/gc/g1/g1Policy.cpp ! src/hotspot/share/gc/g1/g1YoungCollector.cpp ! src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.cpp Changeset: b678e700 Author: Brian Burkhalter Date: 2023-01-24 20:32:46 +0000 URL: https://git.openjdk.org/loom/commit/b678e70003cc2c84df426bb63a07f43e508604bf 8300942: JDK-8299684 breaks x86 build Reviewed-by: dholmes, jiefu ! test/jdk/java/nio/jni/libNewDirectByteBuffer.c Changeset: cf46004f Author: Eirik Bjorsnos Committer: Weijun Wang Date: 2023-01-24 22:16:28 +0000 URL: https://git.openjdk.org/loom/commit/cf46004f276293ce8b092fe17ae579cbe45914a2 8300272: Improve readability of the test JarWithOneNonDisabledDigestAlg Reviewed-by: weijun ! test/jdk/jdk/security/jarsigner/JarWithOneNonDisabledDigestAlg.java Changeset: a3ed7e94 Author: Jan Lahoda Date: 2023-01-24 06:40:06 +0000 URL: https://git.openjdk.org/loom/commit/a3ed7e94a23c0c89138d831f4b36b26dce5b3d01 8300623: Lambda deserialization regression involving Enum method reference Reviewed-by: mcimadamore, vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java - test/langtools/tools/javac/lambda/methodReference/8059632/MethodRefQualifyingTypeTest.java - test/langtools/tools/javac/lambda/methodReference/8059632/MethodSupplierImpl.java - test/langtools/tools/javac/lambda/methodReference/8059632/TestBootstrapInvocation.java Changeset: 60b8a985 Author: Adam Sotona Date: 2023-01-24 13:15:02 +0000 URL: https://git.openjdk.org/loom/commit/60b8a98501c6aafa47827b2f05c354c461cfe75c 8300591: @SuppressWarnings option "lossy-conversions" missing from jdk.compiler module javadoc Backport-of: 836198a4009c4a3f10a76dc8734e4792bb2509ba ! src/jdk.compiler/share/classes/module-info.java ! src/jdk.compiler/share/man/javac.1 Changeset: 81d523d3 Author: Jesper Wilhelmsson Date: 2023-01-24 22:28:07 +0000 URL: https://git.openjdk.org/loom/commit/81d523d382331a06ec57b302890ccd4d25fdd095 Merge Changeset: 13394615 Author: Jie Fu Date: 2023-01-24 23:44:35 +0000 URL: https://git.openjdk.org/loom/commit/133946159c699afa2748b41271c15c5a7ec5bc53 8300981: Build failure on 32-bit platforms after JDK-8281213 Reviewed-by: coleenp ! src/hotspot/share/services/memReporter.hpp Changeset: fbe5ab00 Author: David Holmes Date: 2023-01-25 01:05:25 +0000 URL: https://git.openjdk.org/loom/commit/fbe5ab0066e2766124a7f5db155b9634e1790671 8300830: Remove redundant assertion in src/hotspot/share/runtime/javaCalls.cpp Reviewed-by: iklam, rehn, dcubed ! src/hotspot/share/runtime/javaCalls.cpp Changeset: 7465de45 Author: Prasanta Sadhukhan Date: 2023-01-25 05:48:07 +0000 URL: https://git.openjdk.org/loom/commit/7465de453afac9499582cb8c7573bcdc988f623b 6603771: Nimbus L&F: Ctrl+F7 keybinding for Jinternal Frame throws a NPE. Reviewed-by: abhiscxk, serb ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicDesktopPaneUI.java + test/jdk/javax/swing/JInternalFrame/JInternalFrameTest.java Changeset: 5a478ef7 Author: Christian Hagedorn Date: 2023-01-25 07:22:12 +0000 URL: https://git.openjdk.org/loom/commit/5a478ef7759e64da6d17426673700ff0d9c66b33 8297730: C2: Arraycopy intrinsic throws incorrect exception Reviewed-by: thartmann, kvn ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/opto/library_call.hpp + test/hotspot/jtreg/compiler/arraycopy/TestArrayCopyIntrinsicWithUCT.java Changeset: 95fafd09 Author: Erik ?sterlund Date: 2023-01-25 08:15:35 +0000 URL: https://git.openjdk.org/loom/commit/95fafd094f93eaf3ff15c76ca25345123d1586fe 8300644: Remove gc/shenandoah/jni/TestStringCriticalWithDedup.java Reviewed-by: wkemper, mbaesken - test/hotspot/jtreg/gc/shenandoah/jni/TestStringCriticalWithDedup.java - test/hotspot/jtreg/gc/shenandoah/jni/libTestStringCriticalWithDedup.c Changeset: b2071f79 Author: Erik ?sterlund Date: 2023-01-25 08:17:56 +0000 URL: https://git.openjdk.org/loom/commit/b2071f79d854f40df0f3bc2de6828fbcea4d325a 8300657: Remove null filtering in CLD oop handle area Reviewed-by: coleenp, dholmes ! src/hotspot/share/classfile/classLoaderData.cpp Changeset: 3c61d5aa Author: Severin Gehwolf Date: 2023-01-25 10:24:33 +0000 URL: https://git.openjdk.org/loom/commit/3c61d5aa48606dab2d2c639d5f0a56313476917d 8300659: Refactor TestMemoryAwareness to use WhiteBox api for host values Reviewed-by: mbaesken ! src/hotspot/share/prims/whitebox.cpp ! test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java ! test/lib/jdk/test/whitebox/WhiteBox.java Changeset: 71107f46 Author: Johan Sj?len Date: 2023-01-25 10:30:02 +0000 URL: https://git.openjdk.org/loom/commit/71107f4648d8f31a7bcc0aa5202ef46230df583f 8300651: Replace NULL with nullptr in share/runtime/ Reviewed-by: rehn, dholmes ! src/hotspot/share/runtime/abstract_vm_version.cpp ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/arguments.hpp ! src/hotspot/share/runtime/atomic.hpp ! src/hotspot/share/runtime/basicLock.cpp ! src/hotspot/share/runtime/continuationFreezeThaw.cpp ! src/hotspot/share/runtime/deoptimization.cpp ! src/hotspot/share/runtime/deoptimization.hpp ! src/hotspot/share/runtime/escapeBarrier.cpp ! src/hotspot/share/runtime/escapeBarrier.hpp ! src/hotspot/share/runtime/fieldDescriptor.cpp ! src/hotspot/share/runtime/flags/debug_globals.hpp ! src/hotspot/share/runtime/flags/jvmFlag.cpp ! src/hotspot/share/runtime/flags/jvmFlagAccess.cpp ! src/hotspot/share/runtime/flags/jvmFlagAccess.hpp ! src/hotspot/share/runtime/flags/jvmFlagLimit.cpp ! src/hotspot/share/runtime/flags/jvmFlagLimit.hpp ! src/hotspot/share/runtime/flags/jvmFlagLookup.cpp ! src/hotspot/share/runtime/frame.cpp ! src/hotspot/share/runtime/frame.hpp ! src/hotspot/share/runtime/frame.inline.hpp ! src/hotspot/share/runtime/globals.hpp ! src/hotspot/share/runtime/handles.cpp ! src/hotspot/share/runtime/handles.hpp ! src/hotspot/share/runtime/handles.inline.hpp ! src/hotspot/share/runtime/handshake.cpp ! src/hotspot/share/runtime/icache.cpp ! src/hotspot/share/runtime/interfaceSupport.cpp ! src/hotspot/share/runtime/interfaceSupport.inline.hpp ! src/hotspot/share/runtime/java.cpp ! src/hotspot/share/runtime/java.hpp ! src/hotspot/share/runtime/javaCalls.cpp ! src/hotspot/share/runtime/javaCalls.hpp ! src/hotspot/share/runtime/javaFrameAnchor.hpp ! src/hotspot/share/runtime/javaThread.cpp ! src/hotspot/share/runtime/javaThread.hpp ! src/hotspot/share/runtime/javaThread.inline.hpp ! src/hotspot/share/runtime/jniHandles.cpp ! src/hotspot/share/runtime/jniHandles.hpp ! src/hotspot/share/runtime/jniHandles.inline.hpp ! src/hotspot/share/runtime/jniPeriodicChecker.cpp ! src/hotspot/share/runtime/jniPeriodicChecker.hpp ! src/hotspot/share/runtime/keepStackGCProcessed.cpp ! src/hotspot/share/runtime/monitorChunk.cpp ! src/hotspot/share/runtime/mutex.cpp ! src/hotspot/share/runtime/mutex.hpp ! src/hotspot/share/runtime/mutexLocker.cpp ! src/hotspot/share/runtime/mutexLocker.hpp ! src/hotspot/share/runtime/nonJavaThread.cpp ! src/hotspot/share/runtime/nonJavaThread.hpp ! src/hotspot/share/runtime/objectMonitor.cpp ! src/hotspot/share/runtime/objectMonitor.hpp ! src/hotspot/share/runtime/objectMonitor.inline.hpp ! src/hotspot/share/runtime/orderAccess.cpp ! src/hotspot/share/runtime/os.cpp ! src/hotspot/share/runtime/os.hpp ! src/hotspot/share/runtime/os.inline.hpp ! src/hotspot/share/runtime/park.cpp ! src/hotspot/share/runtime/park.hpp ! src/hotspot/share/runtime/perfData.cpp ! src/hotspot/share/runtime/perfData.hpp ! src/hotspot/share/runtime/perfData.inline.hpp ! src/hotspot/share/runtime/perfMemory.cpp ! src/hotspot/share/runtime/perfMemory.hpp ! src/hotspot/share/runtime/reflection.cpp ! src/hotspot/share/runtime/reflectionUtils.cpp ! src/hotspot/share/runtime/registerMap.hpp ! src/hotspot/share/runtime/relocator.cpp ! src/hotspot/share/runtime/relocator.hpp ! src/hotspot/share/runtime/safepoint.cpp ! src/hotspot/share/runtime/serviceThread.cpp ! src/hotspot/share/runtime/sharedRuntime.cpp ! src/hotspot/share/runtime/sharedRuntime.hpp ! src/hotspot/share/runtime/signature.cpp ! src/hotspot/share/runtime/signature.hpp ! src/hotspot/share/runtime/stackChunkFrameStream.hpp ! src/hotspot/share/runtime/stackValue.cpp ! src/hotspot/share/runtime/stackWatermark.cpp ! src/hotspot/share/runtime/stackWatermarkSet.cpp ! src/hotspot/share/runtime/stackWatermarkSet.inline.hpp ! src/hotspot/share/runtime/statSampler.cpp ! src/hotspot/share/runtime/statSampler.hpp ! src/hotspot/share/runtime/stubCodeGenerator.cpp ! src/hotspot/share/runtime/stubCodeGenerator.hpp ! src/hotspot/share/runtime/stubRoutines.cpp ! src/hotspot/share/runtime/stubRoutines.hpp ! src/hotspot/share/runtime/synchronizer.cpp ! src/hotspot/share/runtime/synchronizer.hpp ! src/hotspot/share/runtime/task.cpp ! src/hotspot/share/runtime/thread.cpp ! src/hotspot/share/runtime/thread.hpp ! src/hotspot/share/runtime/threadSMR.cpp ! src/hotspot/share/runtime/threadSMR.hpp ! src/hotspot/share/runtime/threadSMR.inline.hpp ! src/hotspot/share/runtime/threads.cpp ! src/hotspot/share/runtime/timerTrace.cpp ! src/hotspot/share/runtime/timerTrace.hpp ! src/hotspot/share/runtime/unhandledOops.cpp ! src/hotspot/share/runtime/unhandledOops.hpp ! src/hotspot/share/runtime/vframe.cpp ! src/hotspot/share/runtime/vframe.hpp ! src/hotspot/share/runtime/vframe.inline.hpp ! src/hotspot/share/runtime/vframeArray.cpp ! src/hotspot/share/runtime/vframe_hp.cpp ! src/hotspot/share/runtime/vframe_hp.hpp ! src/hotspot/share/runtime/vmOperation.hpp ! src/hotspot/share/runtime/vmOperations.cpp ! src/hotspot/share/runtime/vmOperations.hpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/hotspot/share/runtime/vmStructs.hpp ! src/hotspot/share/runtime/vmThread.cpp ! src/hotspot/share/runtime/vmThread.hpp Changeset: a5d8e128 Author: Johan Sj?len Date: 2023-01-25 10:31:51 +0000 URL: https://git.openjdk.org/loom/commit/a5d8e12872d9de399fa97b33896635d101b71372 8300244: Replace NULL with nullptr in share/interpreter/ Reviewed-by: coleenp, dholmes ! src/hotspot/share/interpreter/abstractInterpreter.cpp ! src/hotspot/share/interpreter/abstractInterpreter.hpp ! src/hotspot/share/interpreter/bootstrapInfo.cpp ! src/hotspot/share/interpreter/bootstrapInfo.hpp ! src/hotspot/share/interpreter/bytecode.cpp ! src/hotspot/share/interpreter/bytecode.hpp ! src/hotspot/share/interpreter/bytecodeTracer.cpp ! src/hotspot/share/interpreter/bytecodeUtils.cpp ! src/hotspot/share/interpreter/bytecodes.cpp ! src/hotspot/share/interpreter/bytecodes.hpp ! src/hotspot/share/interpreter/interpreter.cpp ! src/hotspot/share/interpreter/interpreterRuntime.cpp ! src/hotspot/share/interpreter/linkResolver.cpp ! src/hotspot/share/interpreter/linkResolver.hpp ! src/hotspot/share/interpreter/oopMapCache.cpp ! src/hotspot/share/interpreter/rewriter.cpp ! src/hotspot/share/interpreter/templateInterpreter.cpp ! src/hotspot/share/interpreter/templateInterpreter.hpp ! src/hotspot/share/interpreter/templateInterpreterGenerator.cpp ! src/hotspot/share/interpreter/templateInterpreterGenerator.hpp ! src/hotspot/share/interpreter/templateTable.hpp ! src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp ! src/hotspot/share/interpreter/zero/bytecodeInterpreter.inline.hpp ! src/hotspot/share/interpreter/zero/zeroInterpreter.hpp ! src/hotspot/share/interpreter/zero/zeroInterpreterGenerator.cpp Changeset: 74e1a8bf Author: Per Minborg Date: 2023-01-25 12:54:27 +0000 URL: https://git.openjdk.org/loom/commit/74e1a8bfa852a55fb8e6e93e19e2999f4d23f959 8300236: Use VarHandle access in Data(Input | Output)Stream classes Reviewed-by: rriggs, alanb - src/java.base/share/classes/java/io/Bits.java ! src/java.base/share/classes/java/io/DataInputStream.java ! src/java.base/share/classes/java/io/DataOutputStream.java ! src/java.base/share/classes/java/io/ObjectInputStream.java ! src/java.base/share/classes/java/io/ObjectOutputStream.java ! src/java.base/share/classes/java/io/ObjectStreamClass.java ! src/java.base/share/classes/java/io/RandomAccessFile.java + src/java.base/share/classes/jdk/internal/util/ByteArray.java - test/jdk/java/io/Bits/ReadWriteValues.java - test/jdk/java/io/Bits/java.base/java/io/BitsProxy.java + test/jdk/jdk/internal/util/ByteArray/ReadWriteValues.java + test/micro/org/openjdk/bench/java/io/PrimitiveFieldSerializationBenchmark.java Changeset: c8ad6000 Author: Daniel Fuchs Date: 2023-01-25 13:33:22 +0000 URL: https://git.openjdk.org/loom/commit/c8ad6000646abd6e1faac396d901135c85c73cf5 8301004: httpclient: Add more debug to HttpResponseInputStream Reviewed-by: jpai ! src/java.net.http/share/classes/jdk/internal/net/http/ResponseSubscribers.java Changeset: 8a47429d Author: Jaikiran Pai Date: 2023-01-25 13:38:02 +0000 URL: https://git.openjdk.org/loom/commit/8a47429dc065ad7645a40fa2350d043ef4606d92 8295944: Move the Http2TestServer and related classes into a package of its own Reviewed-by: dfuchs ! test/jdk/com/sun/net/httpserver/SANTest.java ! test/jdk/java/net/httpclient/ALPNProxyFailureTest.java ! test/jdk/java/net/httpclient/AbstractNoBody.java ! test/jdk/java/net/httpclient/AbstractThrowingPublishers.java ! test/jdk/java/net/httpclient/AbstractThrowingPushPromises.java ! test/jdk/java/net/httpclient/AbstractThrowingSubscribers.java ! test/jdk/java/net/httpclient/AggregateRequestBodyTest.java ! test/jdk/java/net/httpclient/AsFileDownloadTest.java ! test/jdk/java/net/httpclient/AsFileDownloadTest.policy ! test/jdk/java/net/httpclient/AsyncExecutorShutdown.java ! test/jdk/java/net/httpclient/AuthFilterCacheTest.java ! test/jdk/java/net/httpclient/BasicRedirectTest.java ! test/jdk/java/net/httpclient/CancelRequestTest.java ! test/jdk/java/net/httpclient/CancelStreamedBodyTest.java ! test/jdk/java/net/httpclient/ConcurrentResponses.java ! test/jdk/java/net/httpclient/CookieHeaderTest.java ! test/jdk/java/net/httpclient/CustomRequestPublisher.java ! test/jdk/java/net/httpclient/CustomResponseSubscriber.java ! test/jdk/java/net/httpclient/DependentActionsTest.java ! test/jdk/java/net/httpclient/DependentPromiseActionsTest.java ! test/jdk/java/net/httpclient/DigestEchoClient.java ! test/jdk/java/net/httpclient/DigestEchoClientSSL.java ! test/jdk/java/net/httpclient/DigestEchoServer.java ! test/jdk/java/net/httpclient/EncodedCharsInURI.java ! test/jdk/java/net/httpclient/EscapedOctetsInURI.java ! test/jdk/java/net/httpclient/ExecutorShutdown.java ! test/jdk/java/net/httpclient/ExpectContinueTest.java ! test/jdk/java/net/httpclient/FilePublisher/FilePublisherPermsTest.java ! test/jdk/java/net/httpclient/FilePublisher/FilePublisherPermsTest1.policy ! test/jdk/java/net/httpclient/FilePublisher/FilePublisherPermsTest2.policy ! test/jdk/java/net/httpclient/FilePublisher/FilePublisherPermsTest3.policy ! test/jdk/java/net/httpclient/FilePublisher/FilePublisherTest.java ! test/jdk/java/net/httpclient/FilePublisher/FilePublisherTest.policy ! test/jdk/java/net/httpclient/FlowAdapterPublisherTest.java ! test/jdk/java/net/httpclient/FlowAdapterSubscriberTest.java ! test/jdk/java/net/httpclient/ForbiddenHeadTest.java ! test/jdk/java/net/httpclient/GZIPInputStreamTest.java ! test/jdk/java/net/httpclient/HeadTest.java ! test/jdk/java/net/httpclient/HttpClientLocalAddrTest.java ! test/jdk/java/net/httpclient/HttpRedirectTest.java ! test/jdk/java/net/httpclient/HttpSlowServerTest.java ! test/jdk/java/net/httpclient/HttpVersionsTest.java ! test/jdk/java/net/httpclient/HttpsTunnelAuthTest.java ! test/jdk/java/net/httpclient/HttpsTunnelTest.java ! test/jdk/java/net/httpclient/ISO_8859_1_Test.java ! test/jdk/java/net/httpclient/ImmutableFlowItems.java ! test/jdk/java/net/httpclient/InvalidInputStreamSubscriptionRequest.java ! test/jdk/java/net/httpclient/InvalidSubscriptionRequest.java ! test/jdk/java/net/httpclient/LargeHandshakeTest.java ! test/jdk/java/net/httpclient/LargeResponseTest.java ! test/jdk/java/net/httpclient/LineBodyHandlerTest.java ! test/jdk/java/net/httpclient/MappingResponseSubscriber.java ! test/jdk/java/net/httpclient/MaxStreams.java ! test/jdk/java/net/httpclient/NoBodyPartOne.java ! test/jdk/java/net/httpclient/NoBodyPartTwo.java ! test/jdk/java/net/httpclient/NonAsciiCharsInURI.java ! test/jdk/java/net/httpclient/PathSubscriber/BodyHandlerOfFileDownloadTest.java ! test/jdk/java/net/httpclient/PathSubscriber/BodyHandlerOfFileTest.java ! test/jdk/java/net/httpclient/PathSubscriber/BodySubscriberOfFileTest.java ! test/jdk/java/net/httpclient/PathSubscriber/ofFile.policy ! test/jdk/java/net/httpclient/PathSubscriber/ofFileDownload.policy ! test/jdk/java/net/httpclient/ProxyAuthDisabledSchemes.java ! test/jdk/java/net/httpclient/ProxyAuthDisabledSchemesSSL.java ! test/jdk/java/net/httpclient/ProxySelectorTest.java ! test/jdk/java/net/httpclient/RedirectMethodChange.java ! test/jdk/java/net/httpclient/RedirectWithCookie.java ! test/jdk/java/net/httpclient/Response1xxTest.java ! test/jdk/java/net/httpclient/Response204V2Test.java ! test/jdk/java/net/httpclient/ResponsePublisher.java ! test/jdk/java/net/httpclient/RetryWithCookie.java ! test/jdk/java/net/httpclient/ServerCloseTest.java ! test/jdk/java/net/httpclient/SpecialHeadersTest.java ! test/jdk/java/net/httpclient/StreamCloseTest.java ! test/jdk/java/net/httpclient/StreamingBody.java ! test/jdk/java/net/httpclient/TEST.properties ! test/jdk/java/net/httpclient/ThrowingPublishersCustomAfterCancel.java ! test/jdk/java/net/httpclient/ThrowingPublishersCustomBeforeCancel.java ! test/jdk/java/net/httpclient/ThrowingPublishersIOAfterCancel.java ! test/jdk/java/net/httpclient/ThrowingPublishersIOBeforeCancel.java ! test/jdk/java/net/httpclient/ThrowingPublishersInNextRequest.java ! test/jdk/java/net/httpclient/ThrowingPublishersInRequest.java ! test/jdk/java/net/httpclient/ThrowingPublishersInSubscribe.java ! test/jdk/java/net/httpclient/ThrowingPublishersSanity.java ! test/jdk/java/net/httpclient/ThrowingPushPromisesAsInputStreamCustom.java ! test/jdk/java/net/httpclient/ThrowingPushPromisesAsInputStreamIO.java ! test/jdk/java/net/httpclient/ThrowingPushPromisesAsLinesCustom.java ! test/jdk/java/net/httpclient/ThrowingPushPromisesAsLinesIO.java ! test/jdk/java/net/httpclient/ThrowingPushPromisesAsStringCustom.java ! test/jdk/java/net/httpclient/ThrowingPushPromisesAsStringIO.java ! test/jdk/java/net/httpclient/ThrowingPushPromisesSanity.java ! test/jdk/java/net/httpclient/ThrowingSubscribersAsInputStream.java ! test/jdk/java/net/httpclient/ThrowingSubscribersAsInputStreamAsync.java ! test/jdk/java/net/httpclient/ThrowingSubscribersAsLines.java ! test/jdk/java/net/httpclient/ThrowingSubscribersAsLinesAsync.java ! test/jdk/java/net/httpclient/ThrowingSubscribersAsString.java ! test/jdk/java/net/httpclient/ThrowingSubscribersAsStringAsync.java ! test/jdk/java/net/httpclient/ThrowingSubscribersSanity.java ! test/jdk/java/net/httpclient/TlsContextTest.java ! test/jdk/java/net/httpclient/UnauthorizedTest.java ! test/jdk/java/net/httpclient/UserCookieTest.java ! test/jdk/java/net/httpclient/dependent.policy ! test/jdk/java/net/httpclient/http2/BadHeadersTest.java ! test/jdk/java/net/httpclient/http2/BasicTest.java ! test/jdk/java/net/httpclient/http2/ContinuationFrameTest.java ! test/jdk/java/net/httpclient/http2/ErrorTest.java ! test/jdk/java/net/httpclient/http2/FixedThreadPoolTest.java ! test/jdk/java/net/httpclient/http2/IdleConnectionTimeoutTest.java ! test/jdk/java/net/httpclient/http2/ImplicitPushCancel.java ! test/jdk/java/net/httpclient/http2/NoBodyTest.java ! test/jdk/java/net/httpclient/http2/ProxyTest2.java ! test/jdk/java/net/httpclient/http2/PushPromiseContinuation.java ! test/jdk/java/net/httpclient/http2/RedirectTest.java ! test/jdk/java/net/httpclient/http2/ServerPush.java ! test/jdk/java/net/httpclient/http2/ServerPushWithDiffTypes.java ! test/jdk/java/net/httpclient/http2/TLSConnection.java ! test/jdk/java/net/httpclient/http2/UserInfoTest.java ! test/jdk/java/net/httpclient/httpclient-localaddr-security.policy = test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/common/ExceptionallyCloseable.java = test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/common/HttpServerAdapters.java = test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/common/TestUtil.java = test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/http2/BodyInputStream.java = test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/http2/BodyOutputStream.java = test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/http2/EchoHandler.java = test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/http2/Http2EchoHandler.java = test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/http2/Http2Handler.java = test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/http2/Http2RedirectHandler.java = test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/http2/Http2TestExchange.java = test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/http2/Http2TestExchangeImpl.java = test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/http2/Http2TestExchangeSupplier.java = test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/http2/Http2TestServer.java = test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/http2/Http2TestServerConnection.java = test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/http2/NoBodyHandler.java = test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/http2/OutgoingPushPromise.java = test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/http2/PushHandler.java = test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/http2/Queue.java Changeset: 61775c85 Author: Eirik Bjorsnos Committer: Erik Joelsson Date: 2023-01-25 14:01:03 +0000 URL: https://git.openjdk.org/loom/commit/61775c85b0989e4de310290e9441851f32cb84a3 8300997: Add curl support to createJMHBundle.sh Reviewed-by: erikj ! make/devkit/createJMHBundle.sh Changeset: a23ff63a Author: Per Minborg Date: 2023-01-25 14:13:22 +0000 URL: https://git.openjdk.org/loom/commit/a23ff63af147067e0704970a9f9e6d847df22dff 8301086: jdk/internal/util/ByteArray/ReadWriteValues.java fails with CompilationError Reviewed-by: dfuchs ! test/jdk/jdk/internal/util/ByteArray/ReadWriteValues.java Changeset: f279c751 Author: Erik Joelsson Date: 2023-01-25 14:14:56 +0000 URL: https://git.openjdk.org/loom/commit/f279c751a5b2132c11aa3a31084ee37f1a349150 8300805: Update autoconf build-aux files with latest from 2022-09-17 Reviewed-by: mikael, clanger ! make/autoconf/build-aux/autoconf-config.guess ! make/autoconf/build-aux/autoconf-config.sub ! make/autoconf/build-aux/config.guess ! make/autoconf/build-aux/config.sub Changeset: e80b5ea4 Author: Xue-Lei Andrew Fan Date: 2023-01-25 15:42:53 +0000 URL: https://git.openjdk.org/loom/commit/e80b5ea448c715519d14e238321ceb5ec40b37f4 8299635: Hotspot update for deprecated sprintf in Xcode 14 Reviewed-by: dholmes, mikael ! src/hotspot/cpu/arm/arm.ad ! src/hotspot/cpu/ppc/ppc.ad ! src/hotspot/os/aix/attachListener_aix.cpp ! src/hotspot/os/aix/os_aix.cpp ! src/hotspot/os/linux/attachListener_linux.cpp ! src/hotspot/os/linux/os_linux.cpp ! src/hotspot/os/windows/os_windows.cpp ! src/hotspot/share/adlc/formssel.cpp ! src/hotspot/share/opto/callnode.cpp ! src/hotspot/share/opto/cfgnode.cpp ! src/hotspot/share/opto/chaitin.cpp ! src/hotspot/share/opto/chaitin.hpp ! src/hotspot/share/opto/idealGraphPrinter.cpp ! src/hotspot/share/opto/node.cpp ! src/hotspot/share/opto/regalloc.hpp ! src/hotspot/share/opto/type.cpp ! src/hotspot/share/utilities/globalDefinitions.hpp ! test/hotspot/jtreg/runtime/Thread/libAsyncExceptionOnMonitorEnter.cpp ! test/hotspot/jtreg/serviceability/jvmti/AddModuleExportsAndOpens/libAddModuleExportsAndOpensTest.c ! test/hotspot/jtreg/serviceability/jvmti/events/ThreadEnd/threadend01/libthreadend01.cpp ! test/hotspot/jtreg/serviceability/jvmti/events/ThreadStart/threadstart01/libthreadstart01.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/CreateRawMonitor/crrawmon001/crrawmon001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/DestroyRawMonitor/drrawmon001/drrawmon001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorEnter/rawmonenter001/rawmonenter001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorExit/rawmonexit001/rawmonexit001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorNotify/rawmnntfy001/rawmnntfy001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorNotifyAll/rawmnntfyall001/rawmnntfyall001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorWait/rawmnwait001/rawmnwait001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI04/bi04t002/bi04t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS201/hs201t001/hs201t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS201/hs201t002/hs201t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/GetAllStackTraces/getallstktr001/getallstktr001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/MethodBind/JvmtiTest/JvmtiTest.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/StackTrace/JvmtiTest/JvmtiTest.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/functions/nosuspendStackTrace/JvmtiTest/JvmtiTest.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/functions/rawmonitor/rawmonitor.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/JVMTIagent.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/aod/jvmti_aod.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_tools.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/native/nsk_tools.cpp Changeset: edf1e1ab Author: Justin King Committer: Magnus Ihse Bursie Date: 2023-01-25 16:18:29 +0000 URL: https://git.openjdk.org/loom/commit/edf1e1ab4a49aab0990457e534cc4f7e7518efef 8300592: ASan build does not correctly propagate options to some test launchers Reviewed-by: ihse ! make/autoconf/jdk-options.m4 ! make/common/TestFilesCompilation.gmk = make/data/asan/asan_default_options.cpp ! make/hotspot/lib/CompileGtest.gmk ! make/test/JtregNativeHotspot.gmk ! make/test/JtregNativeJdk.gmk Changeset: ccf2f583 Author: Mikael Vidstedt Date: 2023-01-25 18:27:26 +0000 URL: https://git.openjdk.org/loom/commit/ccf2f5837b31cddd24ec81f7f67107d9fc03c294 8300806: Update googletest to v1.13.0 Reviewed-by: erikj, ihse ! .github/actions/get-gtest/action.yml ! doc/building.html ! doc/building.md ! make/autoconf/lib-tests.m4 ! make/conf/github-actions.conf ! make/conf/jib-profiles.js ! test/hotspot/gtest/gtestMain.cpp Changeset: b6f785d8 Author: Alan Bateman Date: 2023-01-27 09:02:46 +0000 URL: https://git.openjdk.org/loom/commit/b6f785d836dad7b7a2ac992cda02514d88fede95 Merge with jdk-21+7 ! make/autoconf/lib-tests.m4 ! make/conf/jib-profiles.js ! src/hotspot/share/runtime/globals.hpp ! test/jdk/ProblemList.txt ! make/autoconf/lib-tests.m4 ! make/conf/jib-profiles.js ! src/hotspot/share/runtime/globals.hpp ! test/jdk/ProblemList.txt From duke at openjdk.org Fri Jan 27 13:03:49 2023 From: duke at openjdk.org (duke) Date: Fri, 27 Jan 2023 13:03:49 GMT Subject: git: openjdk/loom: master: 111 new changesets Message-ID: Changeset: 715b509f Author: Pengfei Li Date: 2023-01-19 01:05:58 +0000 URL: https://git.openjdk.org/loom/commit/715b509f3d3dd2e8ef75f8e710becc959dd538e0 8298632: [TESTBUG] Add IR checks in jtreg vectorization tests Reviewed-by: kvn, jbhateja ! test/hotspot/jtreg/compiler/lib/ir_framework/IRNode.java ! test/hotspot/jtreg/compiler/vectorization/runner/ArrayCopyTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/ArrayIndexFillTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/ArrayInvariantFillTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/ArrayShiftOpTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/ArrayTypeConvertTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/ArrayUnsafeOpTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/BasicBooleanOpTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/BasicByteOpTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/BasicCharOpTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/BasicDoubleOpTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/BasicFloatOpTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/BasicIntOpTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/BasicLongOpTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/BasicShortOpTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/LoopArrayIndexComputeTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/LoopCombinedOpTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/LoopControlFlowTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/LoopLiveOutNodesTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/LoopRangeStrideTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/LoopReductionOpTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/MultipleLoopsTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/StripMinedLoopTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/VectorizationTestRunner.java Changeset: 8e3036cf Author: Joe Darcy Date: 2023-01-19 01:14:12 +0000 URL: https://git.openjdk.org/loom/commit/8e3036cf7430cee5c5df2584d0a0eef816868c62 8300595: Use improved @see and @link syntax in javax.lang.model and javax.tools Reviewed-by: jjg, iris ! src/java.compiler/share/classes/javax/lang/model/element/Element.java ! src/java.compiler/share/classes/javax/lang/model/element/ExecutableElement.java ! src/java.compiler/share/classes/javax/lang/model/element/ModuleElement.java ! src/java.compiler/share/classes/javax/lang/model/element/PackageElement.java ! src/java.compiler/share/classes/javax/lang/model/element/TypeElement.java ! src/java.compiler/share/classes/javax/lang/model/util/Elements.java ! src/java.compiler/share/classes/javax/tools/JavaFileManager.java Changeset: 24cdcd4c Author: Feilong Jiang Committer: Fei Yang Date: 2023-01-19 01:33:35 +0000 URL: https://git.openjdk.org/loom/commit/24cdcd4c70dd538fd6c6c9f05da480ea65463209 8293841: RISC-V: Implementation of Foreign Function & Memory API (Preview) Co-authored-by: Weikai He Co-authored-by: Fei Yang Reviewed-by: jvernee, fyang, shade, yadongwang ! src/hotspot/cpu/riscv/codeBuffer_riscv.cpp ! src/hotspot/cpu/riscv/downcallLinker_riscv.cpp ! src/hotspot/cpu/riscv/foreignGlobals_riscv.cpp ! src/hotspot/cpu/riscv/foreignGlobals_riscv.hpp ! src/hotspot/cpu/riscv/frame_riscv.cpp ! src/hotspot/cpu/riscv/frame_riscv.inline.hpp ! src/hotspot/cpu/riscv/macroAssembler_riscv.hpp ! src/hotspot/cpu/riscv/methodHandles_riscv.cpp ! src/hotspot/cpu/riscv/register_riscv.hpp ! src/hotspot/cpu/riscv/upcallLinker_riscv.cpp ! src/hotspot/cpu/riscv/vmreg_riscv.cpp ! src/hotspot/cpu/riscv/vmstorage_riscv.hpp ! src/java.base/share/classes/java/lang/foreign/VaList.java ! src/java.base/share/classes/jdk/internal/foreign/CABI.java ! src/java.base/share/classes/jdk/internal/foreign/PlatformLayouts.java ! src/java.base/share/classes/jdk/internal/foreign/SystemLookup.java ! src/java.base/share/classes/jdk/internal/foreign/abi/AbstractLinker.java ! src/java.base/share/classes/jdk/internal/foreign/abi/SharedUtils.java + src/java.base/share/classes/jdk/internal/foreign/abi/riscv64/RISCV64Architecture.java + src/java.base/share/classes/jdk/internal/foreign/abi/riscv64/linux/LinuxRISCV64CallArranger.java + src/java.base/share/classes/jdk/internal/foreign/abi/riscv64/linux/LinuxRISCV64Linker.java + src/java.base/share/classes/jdk/internal/foreign/abi/riscv64/linux/LinuxRISCV64VaList.java + src/java.base/share/classes/jdk/internal/foreign/abi/riscv64/linux/TypeClass.java ! test/jdk/java/foreign/LibraryLookupTest.java ! test/jdk/java/foreign/SafeFunctionAccessTest.java ! test/jdk/java/foreign/StdLibTest.java ! test/jdk/java/foreign/TestClassLoaderFindNative.java ! test/jdk/java/foreign/TestDowncallScope.java ! test/jdk/java/foreign/TestDowncallStack.java ! test/jdk/java/foreign/TestFunctionDescriptor.java ! test/jdk/java/foreign/TestHeapAlignment.java ! test/jdk/java/foreign/TestIllegalLink.java ! test/jdk/java/foreign/TestIntrinsics.java ! test/jdk/java/foreign/TestLayoutEquality.java ! test/jdk/java/foreign/TestLinker.java ! test/jdk/java/foreign/TestMatrix.java ! test/jdk/java/foreign/TestNULLAddress.java ! test/jdk/java/foreign/TestNative.java ! test/jdk/java/foreign/TestNulls.java ! test/jdk/java/foreign/TestScopedOperations.java ! test/jdk/java/foreign/TestSegments.java ! test/jdk/java/foreign/TestStringEncoding.java ! test/jdk/java/foreign/TestUpcallAsync.java ! test/jdk/java/foreign/TestUpcallException.java ! test/jdk/java/foreign/TestUpcallHighArity.java ! test/jdk/java/foreign/TestUpcallScope.java ! test/jdk/java/foreign/TestUpcallStack.java ! test/jdk/java/foreign/TestUpcallStructScope.java ! test/jdk/java/foreign/TestVarArgs.java + test/jdk/java/foreign/callarranger/TestRISCV64CallArranger.java ! test/jdk/java/foreign/capturecallstate/TestCaptureCallState.java ! test/jdk/java/foreign/dontrelease/TestDontRelease.java ! test/jdk/java/foreign/enablenativeaccess/TestEnableNativeAccess.java ! test/jdk/java/foreign/enablenativeaccess/TestEnableNativeAccessDynamic.java ! test/jdk/java/foreign/handles/Driver.java ! test/jdk/java/foreign/loaderLookup/TestLoaderLookup.java ! test/jdk/java/foreign/loaderLookup/TestLoaderLookupJNI.java ! test/jdk/java/foreign/normalize/TestNormalize.java ! test/jdk/java/foreign/passheapsegment/TestPassHeapSegment.java ! test/jdk/java/foreign/stackwalk/TestAsyncStackWalk.java ! test/jdk/java/foreign/stackwalk/TestStackWalk.java ! test/jdk/java/foreign/upcalldeopt/TestUpcallDeopt.java ! test/jdk/java/foreign/valist/VaListTest.java ! test/jdk/java/foreign/virtual/TestVirtualCalls.java Changeset: 7348b9ec Author: Sergey Bylokhov Date: 2023-01-19 05:02:12 +0000 URL: https://git.openjdk.org/loom/commit/7348b9ec9373746bb76bc9fa9556f1811bd9e475 8300167: Add validation of the raster's layout before using in native Reviewed-by: prr ! src/java.desktop/share/classes/sun/java2d/cmm/lcms/LCMSImageLayout.java Changeset: 2e9cb4b1 Author: SWinxy Committer: Julian Waters Date: 2023-01-19 05:05:20 +0000 URL: https://git.openjdk.org/loom/commit/2e9cb4b1f6ebba75cffa407f5142fdd95ed9bd88 8267582: BasicLookAndFeel should not call getComponentPopupMenu twice to get a popup menu Reviewed-by: psadhukhan ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicLookAndFeel.java Changeset: 5b0af1a8 Author: Alan Bateman Date: 2023-01-19 06:59:38 +0000 URL: https://git.openjdk.org/loom/commit/5b0af1a80bb4d2a81cda7e26a6ad0db43e679519 8208077: File.listRoots performance degradation Reviewed-by: lancea, bpb ! src/java.base/windows/classes/java/io/WinNTFileSystem.java ! test/jdk/java/io/File/ListRoots.java Changeset: 5f66024e Author: Emanuel Peter Date: 2023-01-19 07:37:50 +0000 URL: https://git.openjdk.org/loom/commit/5f66024e957e5e40ce8d5a65717ea7f82c9f0b8f 8299959: C2: CmpU::Value must filter overflow computation against local sub computation Reviewed-by: kvn, chagedorn, roland ! src/hotspot/share/opto/subnode.cpp + test/hotspot/jtreg/compiler/rangechecks/TestRangeCheckCmpUOverflowVsSub.java Changeset: cfe57466 Author: Johan Sj?len Date: 2023-01-19 08:48:36 +0000 URL: https://git.openjdk.org/loom/commit/cfe57466ddecb93b528478d0b053b089dd1ed285 8300242: Replace NULL with nullptr in share/code/ Reviewed-by: kvn, thartmann ! src/hotspot/share/code/codeBehaviours.cpp ! src/hotspot/share/code/codeBlob.cpp ! src/hotspot/share/code/codeBlob.hpp ! src/hotspot/share/code/codeBlob.inline.hpp ! src/hotspot/share/code/codeCache.cpp ! src/hotspot/share/code/codeCache.hpp ! src/hotspot/share/code/codeCache.inline.hpp ! src/hotspot/share/code/codeHeapState.cpp ! src/hotspot/share/code/compiledIC.cpp ! src/hotspot/share/code/compiledIC.hpp ! src/hotspot/share/code/compiledMethod.cpp ! src/hotspot/share/code/compiledMethod.hpp ! src/hotspot/share/code/compiledMethod.inline.hpp ! src/hotspot/share/code/compressedStream.cpp ! src/hotspot/share/code/debugInfo.cpp ! src/hotspot/share/code/debugInfo.hpp ! src/hotspot/share/code/debugInfoRec.cpp ! src/hotspot/share/code/debugInfoRec.hpp ! src/hotspot/share/code/dependencies.cpp ! src/hotspot/share/code/dependencies.hpp ! src/hotspot/share/code/dependencyContext.cpp ! src/hotspot/share/code/dependencyContext.hpp ! src/hotspot/share/code/exceptionHandlerTable.cpp ! src/hotspot/share/code/exceptionHandlerTable.hpp ! src/hotspot/share/code/icBuffer.cpp ! src/hotspot/share/code/icBuffer.hpp ! src/hotspot/share/code/nmethod.cpp ! src/hotspot/share/code/nmethod.hpp ! src/hotspot/share/code/oopRecorder.cpp ! src/hotspot/share/code/oopRecorder.hpp ! src/hotspot/share/code/oopRecorder.inline.hpp ! src/hotspot/share/code/pcDesc.cpp ! src/hotspot/share/code/relocInfo.cpp ! src/hotspot/share/code/relocInfo.hpp ! src/hotspot/share/code/scopeDesc.cpp ! src/hotspot/share/code/scopeDesc.hpp ! src/hotspot/share/code/stubs.cpp ! src/hotspot/share/code/stubs.hpp ! src/hotspot/share/code/vmreg.cpp ! src/hotspot/share/code/vtableStubs.cpp ! src/hotspot/share/code/vtableStubs.hpp Changeset: 08e62182 Author: Alan Bateman Date: 2023-01-19 09:00:01 +0000 URL: https://git.openjdk.org/loom/commit/08e621829bd60d37e946f4de8de42863ba78c3dc 8300526: Test runtime/jni/IsVirtualThread/IsVirtualThread.java should exercise alternative virtual thread implementation Reviewed-by: pchilanomate ! test/hotspot/jtreg/runtime/jni/IsVirtualThread/IsVirtualThread.java Changeset: eba87a0e Author: Justin King Committer: Thomas Schatzl Date: 2023-01-19 09:11:22 +0000 URL: https://git.openjdk.org/loom/commit/eba87a0ee0410f61ae764293986ecc162f48c707 8300264: Remove metaprogramming/isPointer.hpp Reviewed-by: kbarrett, tschatzl - src/hotspot/share/metaprogramming/isPointer.hpp ! src/hotspot/share/oops/accessBackend.hpp ! src/hotspot/share/runtime/atomic.hpp ! src/hotspot/share/utilities/concurrentHashTable.inline.hpp - test/hotspot/gtest/metaprogramming/test_isPointer.cpp Changeset: 8f7faa63 Author: Albert Mingkun Yang Date: 2023-01-19 11:51:43 +0000 URL: https://git.openjdk.org/loom/commit/8f7faa631bd9b6d6421ee6f4b4b08ef6ec87f30f 8300447: Parallel: Refactor PSPromotionManager::drain_stacks_depth Reviewed-by: tschatzl, kbarrett ! src/hotspot/share/gc/parallel/psPromotionManager.cpp Changeset: 11df6eb2 Author: Albert Mingkun Yang Date: 2023-01-19 11:52:40 +0000 URL: https://git.openjdk.org/loom/commit/11df6eb28ac2bd8d9d95b452c0e3eb59cc82ce08 8300540: Serial: Remove obsolete comments in GenMarkSweep Reviewed-by: tschatzl ! src/hotspot/share/gc/serial/genMarkSweep.cpp Changeset: e326b86d Author: Matthias Baesken Date: 2023-01-19 12:01:50 +0000 URL: https://git.openjdk.org/loom/commit/e326b86d37cec3b395b88598cf30ce4239732a15 8300042: Improve CPU related JFR events descriptions Reviewed-by: clanger, lucy ! src/hotspot/share/jfr/metadata/metadata.xml Changeset: 2e4a3c47 Author: Alexey Ivanov Date: 2023-01-19 13:00:09 +0000 URL: https://git.openjdk.org/loom/commit/2e4a3c47e262f91a7f881d9d990eb81a929d1627 8293862: javax/swing/JFileChooser/8046391/bug8046391.java failed with 'Cannot invoke "java.awt.Image.getWidth(java.awt.image.ImageObserver)" because "retVal" is null' Co-authored-by: Tejesh R Reviewed-by: prr, serb ! src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java ! src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp ! test/jdk/ProblemList.txt ! test/jdk/javax/swing/JFileChooser/8046391/bug8046391.java Changeset: dea58efb Author: Jonathan Dowland Committer: Severin Gehwolf Date: 2023-01-19 13:26:18 +0000 URL: https://git.openjdk.org/loom/commit/dea58efb6280bb1d94daf208ac909aa013439397 8300119: CgroupMetrics.getTotalMemorySize0() can report invalid results on 32 bit systems Reviewed-by: sgehwolf ! src/java.base/linux/native/libjava/CgroupMetrics.c Changeset: 1084fd24 Author: Johan Sj?len Date: 2023-01-19 13:42:08 +0000 URL: https://git.openjdk.org/loom/commit/1084fd24eb118d4131538c2a3ead714db7d0357b 8299973: Replace NULL with nullptr in share/utilities/ Reviewed-by: coleenp, stefank, dholmes, kbarrett ! src/hotspot/share/utilities/bitMap.cpp ! src/hotspot/share/utilities/chunkedList.hpp ! src/hotspot/share/utilities/concurrentHashTable.hpp ! src/hotspot/share/utilities/concurrentHashTable.inline.hpp ! src/hotspot/share/utilities/concurrentHashTableTasks.inline.hpp ! src/hotspot/share/utilities/copy.cpp ! src/hotspot/share/utilities/debug.cpp ! src/hotspot/share/utilities/decoder.cpp ! src/hotspot/share/utilities/decoder.hpp ! src/hotspot/share/utilities/decoder_elf.cpp ! src/hotspot/share/utilities/decoder_elf.hpp ! src/hotspot/share/utilities/defaultStream.hpp ! src/hotspot/share/utilities/elfFile.cpp ! src/hotspot/share/utilities/elfFile.hpp ! src/hotspot/share/utilities/elfFuncDescTable.cpp ! src/hotspot/share/utilities/elfFuncDescTable.hpp ! src/hotspot/share/utilities/elfStringTable.cpp ! src/hotspot/share/utilities/elfSymbolTable.cpp ! src/hotspot/share/utilities/events.cpp ! src/hotspot/share/utilities/events.hpp ! src/hotspot/share/utilities/exceptions.cpp ! src/hotspot/share/utilities/exceptions.hpp ! src/hotspot/share/utilities/filterQueue.hpp ! src/hotspot/share/utilities/filterQueue.inline.hpp ! src/hotspot/share/utilities/globalDefinitions.cpp ! src/hotspot/share/utilities/growableArray.hpp ! src/hotspot/share/utilities/hashtable.cpp ! src/hotspot/share/utilities/hashtable.hpp ! src/hotspot/share/utilities/hashtable.inline.hpp ! src/hotspot/share/utilities/json.cpp ! src/hotspot/share/utilities/linkedlist.hpp ! src/hotspot/share/utilities/lockFreeStack.hpp ! src/hotspot/share/utilities/nativeCallStack.cpp ! src/hotspot/share/utilities/nativeCallStack.hpp ! src/hotspot/share/utilities/numberSeq.cpp ! src/hotspot/share/utilities/objectBitSet.inline.hpp ! src/hotspot/share/utilities/ostream.cpp ! src/hotspot/share/utilities/ostream.hpp ! src/hotspot/share/utilities/preserveException.cpp ! src/hotspot/share/utilities/resizeableResourceHash.hpp ! src/hotspot/share/utilities/resourceHash.hpp ! src/hotspot/share/utilities/stack.hpp ! src/hotspot/share/utilities/stack.inline.hpp ! src/hotspot/share/utilities/stringUtils.cpp ! src/hotspot/share/utilities/unsigned5.cpp ! src/hotspot/share/utilities/unsigned5.hpp ! src/hotspot/share/utilities/utf8.cpp ! src/hotspot/share/utilities/utf8.hpp ! src/hotspot/share/utilities/virtualizationSupport.cpp ! src/hotspot/share/utilities/vmError.cpp ! src/hotspot/share/utilities/vmError.hpp ! src/hotspot/share/utilities/xmlstream.cpp ! src/hotspot/share/utilities/xmlstream.hpp Changeset: 453dbd12 Author: Stefan Karlsson Date: 2023-01-19 13:49:14 +0000 URL: https://git.openjdk.org/loom/commit/453dbd12ee42731d7ebfd1a856338099429277c8 8298377: JfrVframeStream causes deadlocks in ZGC Co-authored-by: Erik ?sterlund Reviewed-by: eosterlund, mgronlun ! src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp ! src/hotspot/share/jfr/recorder/stacktrace/jfrStackTrace.cpp Changeset: d85243f0 Author: Claes Redestad Date: 2023-01-19 16:50:07 +0000 URL: https://git.openjdk.org/loom/commit/d85243f02b34d03bd7af63a5bcbc73f500f720df 8300647: Miscellaneous hashCode improvements in java.base Reviewed-by: stsypanov, rriggs ! src/java.base/share/classes/sun/security/util/DerValue.java ! src/java.base/unix/classes/java/lang/ProcessEnvironment.java Changeset: b317658d Author: Weijun Wang Date: 2023-01-19 18:32:08 +0000 URL: https://git.openjdk.org/loom/commit/b317658d69a477df04ded3cc2e107970f8a6e20d 8300399: EdDSA does not verify when there is no message Reviewed-by: ascarpino ! src/jdk.crypto.ec/share/classes/sun/security/ec/ed/EdDSASignature.java + test/jdk/sun/security/ec/ed/EmptyMessage.java Changeset: 80ab50b3 Author: Harshitha Onkar Date: 2023-01-19 18:43:54 +0000 URL: https://git.openjdk.org/loom/commit/80ab50b3389cbdae6bced7cea3f3a84b94c5bb82 8294680: Refactor scaled border rendering Co-authored-by: Alexey Ivanov Reviewed-by: rmahajan, achung, aivanov, jdv ! src/java.desktop/share/classes/com/sun/java/swing/SwingUtilities3.java ! src/java.desktop/share/classes/javax/swing/border/EtchedBorder.java ! src/java.desktop/share/classes/javax/swing/border/LineBorder.java ! src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBorders.java Changeset: 558d610b Author: Alexey Ivanov Date: 2023-01-19 19:32:58 +0000 URL: https://git.openjdk.org/loom/commit/558d610bebb6967b4cfe922f62f1c4ba0df7daaf 8299553: Make ScaledEtchedBorderTest.java comprehensive Reviewed-by: serb, honkar, achung ! test/jdk/javax/swing/border/EtchedBorder/ScaledEtchedBorderTest.java ! test/jdk/javax/swing/border/LineBorder/ScaledLineBorderTest.java ! test/jdk/javax/swing/border/LineBorder/ScaledTextFieldBorderTest.java Changeset: f2a1eb98 Author: Joe Darcy Date: 2023-01-19 22:11:23 +0000 URL: https://git.openjdk.org/loom/commit/f2a1eb980437b43cde222755dbf427d7916cf9e2 8300698: Missing @since tag for ClassFileFormatVersion.RELEASE_21 Reviewed-by: rriggs, mchung ! src/java.base/share/classes/java/lang/reflect/ClassFileFormatVersion.java Changeset: 62a2f232 Author: Christoph Langer Date: 2023-01-19 06:43:44 +0000 URL: https://git.openjdk.org/loom/commit/62a2f2327a7879724cab6d2d1d7d9ddfeb37d189 8300490: Spaces in name of MacOS Code Signing Identity are not correctly handled after JDK-8293550 Reviewed-by: erikj ! make/autoconf/jdk-options.m4 Changeset: 1c840506 Author: Ron Pressler Date: 2023-01-19 15:34:01 +0000 URL: https://git.openjdk.org/loom/commit/1c84050610e778010a2ce3a25d48fceee87af6cc 8298400: Virtual thread instability when stack overflows Co-authored-by: Fei Yang Co-authored-by: Richard Reingruber Reviewed-by: dlong, pchilanomate ! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp ! src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp ! src/hotspot/cpu/riscv/sharedRuntime_riscv.cpp ! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp ! src/hotspot/share/runtime/continuationFreezeThaw.cpp Changeset: dfcd65c2 Author: Jesper Wilhelmsson Date: 2023-01-19 22:27:45 +0000 URL: https://git.openjdk.org/loom/commit/dfcd65c2719cae19d41caf25f9aa0691568247e8 Merge ! make/autoconf/jdk-options.m4 ! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp ! src/hotspot/cpu/riscv/sharedRuntime_riscv.cpp ! src/hotspot/share/runtime/continuationFreezeThaw.cpp ! make/autoconf/jdk-options.m4 ! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp ! src/hotspot/cpu/riscv/sharedRuntime_riscv.cpp ! src/hotspot/share/runtime/continuationFreezeThaw.cpp Changeset: fbbb27e7 Author: Justin Lu Committer: Naoto Sato Date: 2023-01-19 22:35:24 +0000 URL: https://git.openjdk.org/loom/commit/fbbb27e77085c346a251e75527af8b21e76f7fc5 8300356: Refactor code examples to use @snippet in java.text.CollationElementIterator Reviewed-by: naoto ! src/java.base/share/classes/java/text/CollationElementIterator.java Changeset: 9b97699b Author: Justin Lu Committer: Naoto Sato Date: 2023-01-19 22:36:17 +0000 URL: https://git.openjdk.org/loom/commit/9b97699be50966672d382a6f288a543ab42bdfd0 8300586: Refactor code examples to use @snippet in java.text.Collator Reviewed-by: iris, lancea, naoto ! src/java.base/share/classes/java/text/Collator.java Changeset: 93a933d4 Author: Joe Darcy Date: 2023-01-19 23:24:01 +0000 URL: https://git.openjdk.org/loom/commit/93a933d4eff24f975dea32cd4b2b28ccbb50ed8f 8300400: Update --release 20 symbol information for JDK 20 build 32 Reviewed-by: iris, jjg ! src/jdk.compiler/share/data/symbols/java.base-K.sym.txt Changeset: 77f2d20e Author: Matias Saavedra Silva Committer: Ioi Lam Date: 2023-01-20 00:55:28 +0000 URL: https://git.openjdk.org/loom/commit/77f2d20e96712de725abffd9db5f28b1a48153b4 8287873: Add test for using -XX:+AutoCreateSharedArchive with different JDK versions Reviewed-by: iklam ! test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/TestAutoCreateSharedArchiveUpgrade.java ! test/lib/jdk/test/lib/artifacts/ArtifactManager.java ! test/lib/jdk/test/lib/artifacts/ArtifactResolver.java Changeset: e1893976 Author: Damon Fenacci Committer: Tobias Hartmann Date: 2023-01-20 08:16:28 +0000 URL: https://git.openjdk.org/loom/commit/e1893976d588c7c2bffe47a133ecd0e0e35f17ea 8296403: [TESTBUG] IR test runner methods in TestLongRangeChecks.java invoke wrong test methods Reviewed-by: thartmann, chagedorn, jiefu ! test/hotspot/jtreg/compiler/c2/irTests/TestLongRangeChecks.java Changeset: 49d60fee Author: Daniel Fuchs Date: 2023-01-20 09:23:37 +0000 URL: https://git.openjdk.org/loom/commit/49d60fee49b9f5f7182dcd1557d9b2f886901100 8300172: java/net/httpclient/MappingResponseSubscriber.java failed with java.net.ConnectException Reviewed-by: jpai ! test/jdk/java/net/httpclient/MappingResponseSubscriber.java Changeset: eca64795 Author: Johan Sj?len Date: 2023-01-20 09:57:20 +0000 URL: https://git.openjdk.org/loom/commit/eca64795be63c599a637ce2a7f740b2d0a1ec9bc 8300087: Replace NULL with nullptr in share/cds/ Reviewed-by: dholmes, iklam ! src/hotspot/share/cds/archiveBuilder.cpp ! src/hotspot/share/cds/archiveBuilder.hpp ! src/hotspot/share/cds/archiveHeapLoader.cpp ! src/hotspot/share/cds/archiveHeapLoader.hpp ! src/hotspot/share/cds/archiveUtils.cpp ! src/hotspot/share/cds/archiveUtils.hpp ! src/hotspot/share/cds/archiveUtils.inline.hpp ! src/hotspot/share/cds/cdsHeapVerifier.cpp ! src/hotspot/share/cds/cdsHeapVerifier.hpp ! src/hotspot/share/cds/cdsProtectionDomain.cpp ! src/hotspot/share/cds/cds_globals.hpp ! src/hotspot/share/cds/classListParser.cpp ! src/hotspot/share/cds/classListParser.hpp ! src/hotspot/share/cds/classListWriter.cpp ! src/hotspot/share/cds/classListWriter.hpp ! src/hotspot/share/cds/classPrelinker.cpp ! src/hotspot/share/cds/cppVtables.cpp ! src/hotspot/share/cds/dumpAllocStats.hpp ! src/hotspot/share/cds/dumpTimeClassInfo.cpp ! src/hotspot/share/cds/dumpTimeClassInfo.hpp ! src/hotspot/share/cds/dynamicArchive.cpp ! src/hotspot/share/cds/dynamicArchive.hpp ! src/hotspot/share/cds/filemap.cpp ! src/hotspot/share/cds/filemap.hpp ! src/hotspot/share/cds/heapShared.cpp ! src/hotspot/share/cds/heapShared.hpp ! src/hotspot/share/cds/lambdaFormInvokers.cpp ! src/hotspot/share/cds/lambdaProxyClassDictionary.cpp ! src/hotspot/share/cds/lambdaProxyClassDictionary.hpp ! src/hotspot/share/cds/metaspaceShared.cpp ! src/hotspot/share/cds/unregisteredClasses.cpp Changeset: 26410c18 Author: Afshin Zafari Committer: Evgeny Astigeevich Date: 2023-01-20 10:17:07 +0000 URL: https://git.openjdk.org/loom/commit/26410c180b88b4342217fdad63f1221786d8c37b 8281213: Unsafe uses of long and size_t in MemReporterBase::diff_in_current_scale Reviewed-by: eastigeevich, kbarrett ! src/hotspot/share/services/memReporter.cpp ! src/hotspot/share/services/memReporter.hpp ! src/hotspot/share/utilities/globalDefinitions.hpp Changeset: 4562b402 Author: Coleen Phillimore Date: 2023-01-20 13:20:29 +0000 URL: https://git.openjdk.org/loom/commit/4562b402fbfedbc3b531b19bf55638b00973b680 8300682: InstanceKlassMiscStatus is a bad name Reviewed-by: fparain, dholmes ! src/hotspot/share/jvmci/vmStructs_jvmci.cpp ! src/hotspot/share/oops/instanceKlass.hpp + src/hotspot/share/oops/instanceKlassFlags.cpp = src/hotspot/share/oops/instanceKlassFlags.hpp - src/hotspot/share/oops/instanceKlassMiscStatus.cpp ! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotVMConfig.java Changeset: 97c611d0 Author: Tobias Holenstein Date: 2023-01-20 14:20:32 +0000 URL: https://git.openjdk.org/loom/commit/97c611d029b614bb462a8f5398ea75b2715c3f07 8289748: C2 compiled code crashes with SIGFPE with -XX:+StressLCM and -XX:+StressGCM Reviewed-by: thartmann, chagedorn, kvn ! src/hotspot/share/opto/loopTransform.cpp + test/hotspot/jtreg/compiler/loopopts/TestRemoveEmptyCountedLoop.java Changeset: 623ba5b6 Author: Thomas Schatzl Date: 2023-01-20 14:31:06 +0000 URL: https://git.openjdk.org/loom/commit/623ba5b6dc0273eb4647e39e8aaa143dc8c9036e 8300653: G1EvacInfo should use common naming scheme for collection set Reviewed-by: ayang, iwalulya ! src/hotspot/share/gc/g1/g1EvacInfo.hpp ! src/hotspot/share/gc/g1/g1Trace.cpp ! src/hotspot/share/gc/g1/g1YoungCollector.cpp ! src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.cpp Changeset: b2d36221 Author: Hannes Walln?fer Date: 2023-01-20 14:50:35 +0000 URL: https://git.openjdk.org/loom/commit/b2d3622115ce0b4c0647c7b79f28c075dfcdebbc 8299896: Reduce enum values of HtmlLinkInfo.Kind Reviewed-by: jjg ! 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/AbstractTreeWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AllClassesIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AnnotationTypeMemberWriterImpl.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/ClassWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ConstantsSummaryWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/EnumConstantWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/FieldWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlLinkFactory.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlLinkInfo.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlSerialFieldWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/IndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/MethodWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/NestedClassWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PropertyWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SerializedFormWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Signatures.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TagletWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/links/LinkFactory.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/links/LinkInfo.java ! test/langtools/jdk/javadoc/doclet/testInterface/TestInterface.java Changeset: c6d56003 Author: Stuart Marks Date: 2023-01-20 16:33:48 +0000 URL: https://git.openjdk.org/loom/commit/c6d560039682ec52efa6fa7755d2aa86f20e1148 8038146: Clarify Map.Entry's connection to the underlying map Reviewed-by: alanb ! src/java.base/share/classes/java/util/AbstractMap.java ! src/java.base/share/classes/java/util/Map.java ! src/java.base/share/classes/java/util/NavigableMap.java ! src/java.base/share/classes/java/util/TreeMap.java Changeset: 92d8326e Author: Ralf Schmelter Date: 2023-01-20 16:36:45 +0000 URL: https://git.openjdk.org/loom/commit/92d8326e4037605897d7c4eb4b3edb63a2fc11b0 8299827: Add resolved IP address in connection exception for sockets Reviewed-by: alanb, vtewari, jpai, dfuchs ! src/java.base/share/classes/sun/net/util/SocketExceptions.java ! test/jdk/java/net/Socket/ExceptionText.java Changeset: e8038557 Author: Darragh Clarke Committer: Daniel Fuchs Date: 2023-01-20 17:00:53 +0000 URL: https://git.openjdk.org/loom/commit/e8038557080ba686829395b49658a899bea15d35 8299863: URLFromURITest.java should import org.junit.jupiter.api.Test Reviewed-by: dfuchs, cstein ! test/jdk/java/net/URL/URLFromURITest.java Changeset: facd4151 Author: Mandy Chung Date: 2023-01-20 17:25:18 +0000 URL: https://git.openjdk.org/loom/commit/facd41511b972e940ecab3bc57f5f23efca43343 8297757: VarHandles.getStaticFieldFromBaseAndOffset should get the receiver type from VarHandle Reviewed-by: psandoz, alanb ! src/java.base/share/classes/java/lang/invoke/VarHandles.java ! src/java.base/share/classes/java/lang/invoke/X-VarHandle.java.template Changeset: 9d44dd0c Author: Volodymyr Paprotski Committer: Jamil Nimeh Date: 2023-01-20 19:51:28 +0000 URL: https://git.openjdk.org/loom/commit/9d44dd0cca620ef8e16e0c4306e6e54d8de6d1e8 8297972: Poly1305 Endianness on ByteBuffer not enforced Reviewed-by: jnimeh ! src/java.base/share/classes/sun/security/util/math/intpoly/IntegerPolynomial1305.java ! test/jdk/com/sun/crypto/provider/Cipher/ChaCha20/unittest/java.base/com/sun/crypto/provider/Poly1305IntrinsicFuzzTest.java Changeset: 5784eb7b Author: Chris Plummer Date: 2023-01-20 19:58:54 +0000 URL: https://git.openjdk.org/loom/commit/5784eb7b68a880e130fda5f07c527187764038a2 8300721: Cleanup ProblemList-svc-vthread.txt Reviewed-by: alanb, lmesnik ! test/hotspot/jtreg/ProblemList-svc-vthread.txt Changeset: 7c2f77a4 Author: Scott Gibbons Committer: Sandhya Viswanathan Date: 2023-01-21 00:07:31 +0000 URL: https://git.openjdk.org/loom/commit/7c2f77a42293eb79829fce99bfce82e89a5df6d7 8300584: Accelerate AVX-512 CRC32C for small buffers Reviewed-by: kvn, sviswanathan ! src/hotspot/cpu/x86/stubGenerator_x86_64.cpp Changeset: e1ee6727 Author: Sergey Bylokhov Date: 2023-01-21 07:09:00 +0000 URL: https://git.openjdk.org/loom/commit/e1ee6727f70209cf046cafba109835ad4acc1c23 8300725: Improve performance of ColorConvertOp for default destinations with alpha Reviewed-by: prr ! src/java.desktop/share/classes/sun/java2d/cmm/lcms/LCMSImageLayout.java ! src/java.desktop/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java ! test/jdk/sun/java2d/cmm/ColorConvertOp/ColCvtAlphaDifferentSrcDst.java Changeset: 5331a3ef Author: Justin King Committer: Thomas Stuefe Date: 2023-01-21 08:57:14 +0000 URL: https://git.openjdk.org/loom/commit/5331a3ef739166b2a2b0871fc9615f2c99effa89 8298908: Instrument Metaspace for ASan Reviewed-by: stuefe, ihse, iklam ! make/autoconf/jdk-options.m4 ! src/hotspot/share/memory/metaspace/chunkManager.cpp ! src/hotspot/share/memory/metaspace/chunkManager.hpp ! src/hotspot/share/memory/metaspace/virtualSpaceNode.cpp + src/hotspot/share/sanitizers/address.h ! test/hotspot/gtest/metaspace/test_virtualspacenode.cpp Changeset: 06394ee8 Author: Doug Simon Date: 2023-01-21 11:31:44 +0000 URL: https://git.openjdk.org/loom/commit/06394ee8b110fe8e37a3b9e582f5dfbf225a3d89 8300590: [JVMCI] BytecodeFrame.equals is broken Reviewed-by: adinn, dlong ! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/BytecodeFrame.java + test/hotspot/jtreg/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestBytecodeFrame.java Changeset: bb42e61a Author: Claes Redestad Date: 2023-01-21 11:54:51 +0000 URL: https://git.openjdk.org/loom/commit/bb42e61a6176a7f4f9485efa47a248b23b09a16d 8300493: Use ArraysSupport.vectorizedHashCode in j.u.zip.ZipCoder Reviewed-by: alanb, lancea ! src/java.base/share/classes/java/lang/System.java ! src/java.base/share/classes/java/util/zip/ZipCoder.java ! src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java + test/micro/org/openjdk/bench/java/util/zip/ZipFileOpen.java Changeset: a6c2a2ae Author: Dan Lutker Committer: Julian Waters Date: 2023-01-21 12:05:35 +0000 URL: https://git.openjdk.org/loom/commit/a6c2a2ae79be6810dca55b13bfc8a7625f25d48d 8300692: GCC 12 reports some compiler warnings in bundled freetype Reviewed-by: erikj, serb, jwaters ! make/modules/java.desktop/lib/Awt2dLibraries.gmk Changeset: c8dd7583 Author: Justin King Committer: Kim Barrett Date: 2023-01-21 15:03:26 +0000 URL: https://git.openjdk.org/loom/commit/c8dd7583a92082bcd2a4dfd5429889e7f0a44050 8300260: Remove metaprogramming/isSame.hpp Reviewed-by: tschatzl, kbarrett - src/hotspot/share/metaprogramming/isSame.hpp ! src/hotspot/share/oops/accessBackend.hpp ! src/hotspot/share/runtime/atomic.hpp ! src/hotspot/share/utilities/devirtualizer.inline.hpp - test/hotspot/gtest/metaprogramming/test_isSame.cpp ! test/hotspot/gtest/metaprogramming/test_isSigned.cpp ! test/hotspot/gtest/metaprogramming/test_primitiveConversions.cpp Changeset: 67b1c890 Author: Tagir F. Valeev Date: 2023-01-21 18:36:31 +0000 URL: https://git.openjdk.org/loom/commit/67b1c890b3351c1b1317477dd12316d18c01dd72 8294693: Add Collections.shuffle overload that accepts RandomGenerator interface Reviewed-by: smarks, darcy ! src/java.base/share/classes/java/util/Collections.java + test/jdk/java/util/Collections/Shuffle.java Changeset: cbfc069f Author: Andrey Turbanov Date: 2023-01-21 19:25:18 +0000 URL: https://git.openjdk.org/loom/commit/cbfc069f6a27b272577ddf2abfbc7a3b64739571 8300731: Avoid unnecessary array fill after creation in PaletteBuilder Reviewed-by: prr, serb ! src/java.desktop/share/classes/com/sun/imageio/plugins/common/PaletteBuilder.java Changeset: 3ea4eac1 Author: Sergey Bylokhov Date: 2023-01-21 21:51:41 +0000 URL: https://git.openjdk.org/loom/commit/3ea4eac1450954db095ef56385baa3aceea524ea 8300817: The build is broken after JDK-8294693 Reviewed-by: tvaleev, darcy ! src/java.base/share/classes/java/util/Collections.java Changeset: 7ced08d4 Author: Jatin Bhateja Date: 2023-01-22 06:47:00 +0000 URL: https://git.openjdk.org/loom/commit/7ced08d4ec1b4aec534bd9061f52dd72fa2270f6 8300638: Tier1 IR Test failure after JDK-8298632 on macosx-x64-debug Reviewed-by: kvn, pli ! test/hotspot/jtreg/compiler/vectorization/runner/ArrayIndexFillTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/ArrayInvariantFillTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/ArrayShiftOpTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/ArrayTypeConvertTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/BasicBooleanOpTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/BasicByteOpTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/BasicCharOpTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/BasicDoubleOpTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/BasicFloatOpTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/BasicLongOpTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/LoopArrayIndexComputeTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/LoopCombinedOpTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/LoopLiveOutNodesTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/LoopRangeStrideTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/LoopReductionOpTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/MultipleLoopsTest.java Changeset: 030b071d Author: Raffaello Giulietti Date: 2023-01-22 12:45:52 +0000 URL: https://git.openjdk.org/loom/commit/030b071db1fb6197a2633a04b20aa95432a903bc 8300207: Add a pre-check for the number of canonical equivalent permutations in j.u.r.Pattern Reviewed-by: smarks ! src/java.base/share/classes/java/util/regex/Pattern.java Changeset: 45e4e009 Author: Tobias Hartmann Date: 2023-01-23 06:06:32 +0000 URL: https://git.openjdk.org/loom/commit/45e4e00981ef8b4bf143afce0889698319273c1d 8300079: SIGSEGV in LibraryCallKit::inline_string_copy due to constant NULL src argument Reviewed-by: roland, chagedorn, kvn ! src/hotspot/share/opto/library_call.cpp + test/hotspot/jtreg/compiler/intrinsics/string/TestCopyValueOf.java Changeset: 836198a4 Author: Adam Sotona Date: 2023-01-23 08:14:51 +0000 URL: https://git.openjdk.org/loom/commit/836198a4009c4a3f10a76dc8734e4792bb2509ba 8300591: @SuppressWarnings option "lossy-conversions" missing from jdk.compiler module javadoc Reviewed-by: jjg, darcy ! src/jdk.compiler/share/classes/module-info.java ! src/jdk.compiler/share/man/javac.1 Changeset: 11aadc9d Author: Prasanta Sadhukhan Date: 2023-01-23 10:18:23 +0000 URL: https://git.openjdk.org/loom/commit/11aadc9d98d364b91114c028c7e2eff8de2f2bf0 8244400: MenuItem may cache the size and did not update it when the screen DPI is changed Reviewed-by: serb, aivanov ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicMenuItemUI.java ! test/jdk/javax/swing/GraphicsConfigNotifier/StalePreferredSize.java Changeset: f307e8c6 Author: Fredrik Bredberg Committer: Robbin Ehn Date: 2023-01-23 10:43:50 +0000 URL: https://git.openjdk.org/loom/commit/f307e8c667895c302e916124751456a5443353ce 8299795: Relativize locals in interpreter frames Reviewed-by: coleenp, rehn, pchilanomate, mdoerr, fyang ! src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp ! src/hotspot/cpu/aarch64/continuationHelper_aarch64.inline.hpp ! src/hotspot/cpu/aarch64/frame_aarch64.cpp ! src/hotspot/cpu/aarch64/frame_aarch64.inline.hpp ! src/hotspot/cpu/aarch64/interp_masm_aarch64.hpp ! src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp ! src/hotspot/cpu/arm/frame_arm.cpp ! src/hotspot/cpu/arm/frame_arm.inline.hpp ! src/hotspot/cpu/arm/interp_masm_arm.hpp ! src/hotspot/cpu/arm/templateInterpreterGenerator_arm.cpp ! src/hotspot/cpu/ppc/continuationFreezeThaw_ppc.inline.hpp ! src/hotspot/cpu/ppc/continuationHelper_ppc.inline.hpp ! src/hotspot/cpu/ppc/frame_ppc.cpp ! src/hotspot/cpu/ppc/frame_ppc.inline.hpp ! src/hotspot/cpu/ppc/interp_masm_ppc_64.cpp ! src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp ! src/hotspot/cpu/riscv/continuationFreezeThaw_riscv.inline.hpp ! src/hotspot/cpu/riscv/continuationHelper_riscv.inline.hpp ! src/hotspot/cpu/riscv/frame_riscv.cpp ! src/hotspot/cpu/riscv/frame_riscv.inline.hpp ! src/hotspot/cpu/riscv/interp_masm_riscv.hpp ! src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp ! src/hotspot/cpu/s390/frame_s390.cpp ! src/hotspot/cpu/s390/frame_s390.inline.hpp ! src/hotspot/cpu/x86/continuationFreezeThaw_x86.inline.hpp ! src/hotspot/cpu/x86/continuationHelper_x86.inline.hpp ! src/hotspot/cpu/x86/frame_x86.cpp ! src/hotspot/cpu/x86/frame_x86.hpp ! src/hotspot/cpu/x86/frame_x86.inline.hpp ! src/hotspot/cpu/x86/interp_masm_x86.hpp ! src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp ! src/hotspot/cpu/zero/frame_zero.cpp ! src/hotspot/cpu/zero/frame_zero.inline.hpp ! src/hotspot/share/runtime/frame.cpp ! src/hotspot/share/runtime/frame.hpp ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Frame.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/aarch64/AARCH64Frame.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/ppc64/PPC64Frame.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/riscv64/RISCV64Frame.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/x86/X86Frame.java Changeset: 5a4945c0 Author: Emanuel Peter Date: 2023-01-23 13:10:42 +0000 URL: https://git.openjdk.org/loom/commit/5a4945c0d95423d0ab07762c915e9cb4d3c66abb 8299975: Limit underflow protection CMoveINode in PhaseIdealLoop::do_unroll must also protect type from underflow Reviewed-by: roland, chagedorn ! src/hotspot/share/opto/loopTransform.cpp + test/hotspot/jtreg/compiler/loopopts/TestCMoveLimitType.java Changeset: 03a9a88e Author: Justin King Committer: Thomas Schatzl Date: 2023-01-23 16:03:28 +0000 URL: https://git.openjdk.org/loom/commit/03a9a88efbb68537e24b7de28c5b81d6cd8fdb04 8300265: Remove metaprogramming/isSigned.hpp Reviewed-by: kbarrett, tschatzl ! src/hotspot/share/memory/metaspace/counters.hpp - src/hotspot/share/metaprogramming/isSigned.hpp ! src/hotspot/share/runtime/atomic.hpp ! src/hotspot/share/utilities/population_count.hpp - test/hotspot/gtest/metaprogramming/test_isSigned.cpp ! test/hotspot/gtest/utilities/test_count_leading_zeros.cpp Changeset: 542bfe61 Author: Brian Burkhalter Date: 2023-01-23 17:05:36 +0000 URL: https://git.openjdk.org/loom/commit/542bfe61e67b72bebff45e7382ec3f40bdab9aae 8300587: (bf) Some covariant overrides are missing @since tags Reviewed-by: lancea, iris ! src/java.base/share/classes/java/nio/MappedByteBuffer.java ! src/java.base/share/classes/java/nio/X-Buffer.java.template Changeset: a56598f5 Author: Brian Burkhalter Date: 2023-01-23 17:12:49 +0000 URL: https://git.openjdk.org/loom/commit/a56598f5a534cc9223367e7faa8433ea38661db9 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly Reviewed-by: dholmes, alanb ! make/test/JtregNativeJdk.gmk ! src/hotspot/share/prims/jni.cpp ! src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template + test/jdk/java/nio/jni/NewDirectByteBuffer.java + test/jdk/java/nio/jni/libNewDirectByteBuffer.c Changeset: 079255e3 Author: Per Minborg Date: 2023-01-23 17:40:13 +0000 URL: https://git.openjdk.org/loom/commit/079255e312a60584d748babcd320eacec99c5a02 8300864: Declare some fields in java.io as final Reviewed-by: rriggs, lancea ! src/java.base/share/classes/java/io/BufferedInputStream.java ! src/java.base/share/classes/java/io/BufferedReader.java ! src/java.base/share/classes/java/io/ExpiringCache.java ! src/java.base/share/classes/java/io/File.java ! src/java.base/share/classes/java/io/FileOutputStream.java ! src/java.base/share/classes/java/io/ObjectStreamClass.java ! src/java.base/share/classes/java/io/StringReader.java ! src/java.base/share/classes/java/io/StringWriter.java Changeset: a7f035db Author: Per Minborg Date: 2023-01-23 17:47:01 +0000 URL: https://git.openjdk.org/loom/commit/a7f035db762ce44b72733094422488047c9ad738 8300868: Reduce visibility in java.io.SerialCallbackContext Reviewed-by: rriggs ! src/java.base/share/classes/java/io/SerialCallbackContext.java Changeset: 4525aa31 Author: Per Minborg Date: 2023-01-23 17:53:20 +0000 URL: https://git.openjdk.org/loom/commit/4525aa318a1025e19d4ed9924ed25992be0075e9 8300867: Fix document issues in java.io Reviewed-by: alanb, lancea, iris ! src/java.base/share/classes/java/io/BufferedInputStream.java ! src/java.base/share/classes/java/io/DeleteOnExitHook.java ! src/java.base/share/classes/java/io/File.java ! src/java.base/share/classes/java/io/ObjectInputStream.java ! src/java.base/share/classes/java/io/ObjectOutputStream.java ! src/java.base/share/classes/java/io/ObjectStreamConstants.java Changeset: 86fed796 Author: Mandy Chung Date: 2023-01-23 17:58:53 +0000 URL: https://git.openjdk.org/loom/commit/86fed79670c109fc3a7fbe1eb2b1485c6dd99e2f 8300693: Lower the compile threshold and reduce the iterations of warmup loop in VarHandles tests Reviewed-by: jvernee, dholmes, psandoz ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessBoolean.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessByte.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessChar.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessDouble.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessFloat.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessInt.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessLong.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessShort.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessString.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsChar.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsDouble.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsFloat.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsInt.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsLong.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsShort.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessBoolean.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessByte.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessChar.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessDouble.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessFloat.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessInt.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessLong.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessShort.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessString.java ! test/jdk/java/lang/invoke/VarHandles/X-VarHandleTestAccess.java.template ! test/jdk/java/lang/invoke/VarHandles/X-VarHandleTestByteArrayView.java.template ! test/jdk/java/lang/invoke/VarHandles/X-VarHandleTestMethodHandleAccess.java.template Changeset: 1a3cb8c5 Author: Jamil Nimeh Date: 2023-01-23 18:05:48 +0000 URL: https://git.openjdk.org/loom/commit/1a3cb8c5018bc016c2ad6b078e4abe13b39d151c 8296343: CPVE thrown on missing content-length in OCSP response Reviewed-by: mullan, rhalade ! src/java.base/share/classes/sun/security/provider/certpath/OCSP.java ! test/jdk/java/security/cert/CertPathValidator/OCSP/GetAndPostTests.java ! test/jdk/java/security/testlibrary/SimpleOCSPServer.java ! test/jdk/javax/net/ssl/Stapling/HttpsUrlConnClient.java ! test/jdk/javax/net/ssl/Stapling/SSLEngineWithStapling.java ! test/jdk/javax/net/ssl/Stapling/SSLSocketWithStapling.java ! test/jdk/javax/net/ssl/Stapling/StapleEnableProps.java + test/jdk/sun/security/provider/certpath/OCSP/OCSPNoContentLength.java ! test/jdk/sun/security/ssl/Stapling/java.base/sun/security/ssl/StatusResponseManagerTests.java Changeset: d1173508 Author: Per Minborg Date: 2023-01-23 19:09:39 +0000 URL: https://git.openjdk.org/loom/commit/d11735087507a17204bd81ae565409a3b7e881ae 8300866: Declare some classes final in java.io Reviewed-by: alanb ! src/java.base/share/classes/java/io/ExpiringCache.java ! src/java.base/share/classes/java/io/ObjectInputStream.java ! src/java.base/share/classes/java/io/ObjectOutputStream.java ! src/java.base/share/classes/java/io/ObjectStreamClass.java ! src/java.base/share/classes/java/io/ProxyingConsole.java Changeset: dcf1523b Author: Justin Lu Committer: Naoto Sato Date: 2023-01-23 19:31:36 +0000 URL: https://git.openjdk.org/loom/commit/dcf1523bf2dba234371190a70a41cfcb77907196 8300077: Refactor code examples to use @snippet in java.text.ChoiceFormat Reviewed-by: lancea, iris, naoto ! src/java.base/share/classes/java/text/ChoiceFormat.java Changeset: 0ea2dd1f Author: Erik Joelsson Date: 2023-01-23 20:51:13 +0000 URL: https://git.openjdk.org/loom/commit/0ea2dd1f77a7925d02ae0136bb40dcc8abf354d9 8146132: Excessive output from make test-image Reviewed-by: ihse ! make/common/NativeCompilation.gmk ! make/common/TestFilesCompilation.gmk Changeset: fd752178 Author: David Holmes Date: 2023-01-23 07:44:32 +0000 URL: https://git.openjdk.org/loom/commit/fd752178e364fb5deeec062bef3dde1fea1dcbe3 8290919: Update nroff pages in JDK 20 before RC Reviewed-by: iris, alanb ! src/java.base/share/man/java.1 ! src/java.base/share/man/keytool.1 ! src/java.rmi/share/man/rmiregistry.1 ! src/java.scripting/share/man/jrunscript.1 ! src/jdk.compiler/share/man/javac.1 ! src/jdk.compiler/share/man/serialver.1 ! src/jdk.hotspot.agent/share/man/jhsdb.1 ! src/jdk.httpserver/share/man/jwebserver.1 ! src/jdk.jartool/share/man/jar.1 ! src/jdk.jartool/share/man/jarsigner.1 ! src/jdk.javadoc/share/man/javadoc.1 ! src/jdk.jcmd/share/man/jcmd.1 ! src/jdk.jcmd/share/man/jinfo.1 ! src/jdk.jcmd/share/man/jmap.1 ! src/jdk.jcmd/share/man/jps.1 ! src/jdk.jcmd/share/man/jstack.1 ! src/jdk.jcmd/share/man/jstat.1 ! src/jdk.jconsole/share/man/jconsole.1 ! src/jdk.jdeps/share/man/javap.1 ! src/jdk.jdeps/share/man/jdeprscan.1 ! src/jdk.jdeps/share/man/jdeps.1 ! src/jdk.jdi/share/man/jdb.1 ! src/jdk.jfr/share/man/jfr.1 ! src/jdk.jlink/share/man/jlink.1 ! src/jdk.jlink/share/man/jmod.1 ! src/jdk.jpackage/share/man/jpackage.1 ! src/jdk.jshell/share/man/jshell.1 ! src/jdk.jstatd/share/man/jstatd.1 Changeset: 56dc3b08 Author: Jesper Wilhelmsson Date: 2023-01-23 20:58:40 +0000 URL: https://git.openjdk.org/loom/commit/56dc3b08a62f651835c5bccca987d93ba2bb8961 Merge ! src/jdk.compiler/share/man/javac.1 ! src/jdk.compiler/share/man/javac.1 Changeset: f79e5871 Author: Andrey Turbanov Date: 2023-01-23 21:05:14 +0000 URL: https://git.openjdk.org/loom/commit/f79e5871813ab9554e3250cf4b36e92522bddd0a 8300828: Avoid unnecessary array fill after creation in com.sun.media.sound Reviewed-by: serb, prr ! src/java.desktop/share/classes/com/sun/media/sound/ModelInstrument.java ! src/java.desktop/share/classes/com/sun/media/sound/SoftChannel.java ! src/java.desktop/share/classes/com/sun/media/sound/SoftPerformer.java Changeset: 77a50105 Author: David Holmes Date: 2023-01-24 00:21:29 +0000 URL: https://git.openjdk.org/loom/commit/77a50105f0c4a4cb7286dda13c633f1e69295210 8286775: Remove identical per-compiler definitions of unsigned integral jtypes Reviewed-by: kbarrett, coleenp ! src/hotspot/share/utilities/globalDefinitions.hpp ! src/hotspot/share/utilities/globalDefinitions_gcc.hpp ! src/hotspot/share/utilities/globalDefinitions_visCPP.hpp ! src/hotspot/share/utilities/globalDefinitions_xlc.hpp Changeset: b5ee3d1f Author: Tingjun Yuan Committer: Sergey Bylokhov Date: 2023-01-24 01:25:29 +0000 URL: https://git.openjdk.org/loom/commit/b5ee3d1f2abf5af86438ac4c9e3da3cc026dffd3 8299497: Usage of constructors of primitive wrapper classes should be avoided in java.desktop API docs Reviewed-by: serb, prr ! src/java.desktop/share/classes/java/awt/font/LineBreakMeasurer.java ! src/java.desktop/share/classes/java/awt/image/renderable/ParameterBlock.java Changeset: 0323609f Author: Justin Lu Committer: Naoto Sato Date: 2023-01-24 02:05:05 +0000 URL: https://git.openjdk.org/loom/commit/0323609f44e68ba8d992419a23be7066838a0e01 8300706: Use @snippet in java.text Reviewed-by: naoto ! src/java.base/share/classes/java/text/BreakIterator.java ! src/java.base/share/classes/java/text/CharacterIterator.java ! src/java.base/share/classes/java/text/DateFormatSymbols.java ! src/java.base/share/classes/java/text/DecimalFormat.java ! src/java.base/share/classes/java/text/NumberFormat.java Changeset: 2da2e5a0 Author: Jamil Nimeh Date: 2023-01-24 02:09:48 +0000 URL: https://git.openjdk.org/loom/commit/2da2e5a0e80e6c54c848cf39bee534fa9b7086b1 8300946: Add sun/security/provider/certpath/OCSP/OCSPNoContentLength to ProblemList Reviewed-by: jpai ! test/jdk/ProblemList.txt Changeset: 937ba1ca Author: david Committer: Alexey Semenyuk Date: 2023-01-24 03:07:16 +0000 URL: https://git.openjdk.org/loom/commit/937ba1cadbe1e8663ad5663e5a2048b21dc63527 8300111: Add rpath for common lib locations for jpackageapplauncher Reviewed-by: ihse, asemenyuk, almatvee ! make/modules/jdk.jpackage/Lib.gmk Changeset: afd5921f Author: Ioi Lam Date: 2023-01-24 04:07:06 +0000 URL: https://git.openjdk.org/loom/commit/afd5921f1cc5b9a05a7ec3a3690a06bb5e05d23a 8298610: Refactor archiving of ConstantPool::resolved_references() Reviewed-by: dholmes, ccheung ! src/hotspot/share/cds/heapShared.cpp ! src/hotspot/share/cds/heapShared.hpp ! src/hotspot/share/oops/constantPool.cpp ! src/hotspot/share/oops/constantPool.hpp ! src/hotspot/share/oops/cpCache.cpp ! src/hotspot/share/oops/cpCache.hpp Changeset: b3822f50 Author: Justin Lu Committer: Naoto Sato Date: 2023-01-24 04:35:46 +0000 URL: https://git.openjdk.org/loom/commit/b3822f50c85524a00a045aa3a3d902f190e35906 8300589: Use @snippet and @linkplain in java.text.CollationKey and java.text.CompactNumberFormat Reviewed-by: lancea, naoto, iris ! src/java.base/share/classes/java/text/CollationKey.java ! src/java.base/share/classes/java/text/CompactNumberFormat.java Changeset: 6dd8723f Author: David Holmes Date: 2023-01-24 06:27:54 +0000 URL: https://git.openjdk.org/loom/commit/6dd8723f66a22e626d98c74cff0b0b344a62626d 8290918: Initial nroff manpage generation for JDK 21 Reviewed-by: lancea, iris, darcy ! src/java.base/share/man/keytool.1 ! src/java.rmi/share/man/rmiregistry.1 ! src/java.scripting/share/man/jrunscript.1 ! src/jdk.compiler/share/man/javac.1 ! src/jdk.compiler/share/man/serialver.1 ! src/jdk.hotspot.agent/share/man/jhsdb.1 ! src/jdk.httpserver/share/man/jwebserver.1 ! src/jdk.jartool/share/man/jar.1 ! src/jdk.jartool/share/man/jarsigner.1 ! src/jdk.javadoc/share/man/javadoc.1 ! src/jdk.jcmd/share/man/jcmd.1 ! src/jdk.jcmd/share/man/jinfo.1 ! src/jdk.jcmd/share/man/jmap.1 ! src/jdk.jcmd/share/man/jps.1 ! src/jdk.jcmd/share/man/jstack.1 ! src/jdk.jcmd/share/man/jstat.1 ! src/jdk.jconsole/share/man/jconsole.1 ! src/jdk.jdeps/share/man/javap.1 ! src/jdk.jdeps/share/man/jdeprscan.1 ! src/jdk.jdeps/share/man/jdeps.1 ! src/jdk.jdi/share/man/jdb.1 ! src/jdk.jfr/share/man/jfr.1 ! src/jdk.jlink/share/man/jlink.1 ! src/jdk.jlink/share/man/jmod.1 ! src/jdk.jpackage/share/man/jpackage.1 ! src/jdk.jshell/share/man/jshell.1 ! src/jdk.jstatd/share/man/jstatd.1 Changeset: 2292ce13 Author: Thomas Stuefe Date: 2023-01-24 06:35:26 +0000 URL: https://git.openjdk.org/loom/commit/2292ce137c16accf0622600d5a096403b8a8058d 8294677: chunklevel::MAX_CHUNK_WORD_SIZE too small for some applications Reviewed-by: simonis, phh ! src/hotspot/share/memory/metaspace/chunklevel.hpp ! src/hotspot/share/memory/metaspace/metaspaceSettings.hpp ! test/hotspot/gtest/metaspace/test_chunkManager_stress.cpp ! test/hotspot/gtest/metaspace/test_metachunk.cpp ! test/hotspot/gtest/metaspace/test_metaspace_misc.cpp ! test/hotspot/gtest/metaspace/test_virtualspacenode.cpp ! test/hotspot/jtreg/runtime/CompressedOops/CompressedClassSpaceSize.java ! test/hotspot/jtreg/runtime/Metaspace/elastic/Settings.java ! test/hotspot/jtreg/runtime/Metaspace/elastic/TestMetaspaceAllocationMT1.java ! test/hotspot/jtreg/runtime/Metaspace/elastic/TestMetaspaceAllocationMT2.java Changeset: 57f2d48e Author: Per Minborg Date: 2023-01-24 07:43:29 +0000 URL: https://git.openjdk.org/loom/commit/57f2d48e1e11eb2f87be7e47ab943031696e51f5 8300863: Remove C-style array declarations in java.io Reviewed-by: alanb, rriggs, darcy, iris ! src/java.base/share/classes/java/io/BufferedOutputStream.java ! src/java.base/share/classes/java/io/BufferedWriter.java ! src/java.base/share/classes/java/io/ByteArrayInputStream.java ! src/java.base/share/classes/java/io/ByteArrayOutputStream.java ! src/java.base/share/classes/java/io/CharArrayWriter.java ! src/java.base/share/classes/java/io/File.java ! src/java.base/share/classes/java/io/PipedReader.java ! src/java.base/share/classes/java/io/StreamTokenizer.java Changeset: 544c16e0 Author: Matthias Baesken Date: 2023-01-24 08:05:03 +0000 URL: https://git.openjdk.org/loom/commit/544c16e0bdd4335b2624158fd1f6521984aa5079 8300266: Detect Virtualization on Linux aarch64 Reviewed-by: stuefe, lucy ! src/hotspot/cpu/aarch64/vm_version_aarch64.cpp ! src/hotspot/cpu/aarch64/vm_version_aarch64.hpp Changeset: 048705c0 Author: Justin King Committer: Thomas Schatzl Date: 2023-01-24 11:39:18 +0000 URL: https://git.openjdk.org/loom/commit/048705c04967d106dedc09a4cf2325a3b46ef4e7 8300910: Remove metaprogramming/integralConstant.hpp Reviewed-by: kbarrett, tschatzl - src/hotspot/share/metaprogramming/integralConstant.hpp ! src/hotspot/share/oops/accessBackend.hpp ! src/hotspot/share/oops/accessBackend.inline.hpp ! src/hotspot/share/oops/accessDecorators.hpp ! src/hotspot/share/oops/markWord.hpp ! src/hotspot/share/oops/oopHandle.hpp ! src/hotspot/share/oops/oopsHierarchy.hpp ! src/hotspot/share/runtime/os.hpp Changeset: 859ca75b Author: Thomas Schatzl Date: 2023-01-24 17:15:53 +0000 URL: https://git.openjdk.org/loom/commit/859ca75b4c269bc71d1e9638b5b02bbb6386166d 8300862: Remove some G1 collection set remembered set debugging code Reviewed-by: ayang, iwalulya ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1CollectedHeap.hpp Changeset: 3be5758b Author: Thomas Schatzl Date: 2023-01-24 17:33:35 +0000 URL: https://git.openjdk.org/loom/commit/3be5758bb413fb6b4dc6191d78ca38332d5153f1 8300769: Remove G1CollectionSet::_inc_bytes_used_before Reviewed-by: ayang, iwalulya ! src/hotspot/share/gc/g1/g1CollectionSet.cpp ! src/hotspot/share/gc/g1/g1CollectionSet.hpp ! src/hotspot/share/gc/g1/g1Policy.cpp ! src/hotspot/share/gc/g1/g1YoungCollector.cpp ! src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.cpp Changeset: b678e700 Author: Brian Burkhalter Date: 2023-01-24 20:32:46 +0000 URL: https://git.openjdk.org/loom/commit/b678e70003cc2c84df426bb63a07f43e508604bf 8300942: JDK-8299684 breaks x86 build Reviewed-by: dholmes, jiefu ! test/jdk/java/nio/jni/libNewDirectByteBuffer.c Changeset: cf46004f Author: Eirik Bjorsnos Committer: Weijun Wang Date: 2023-01-24 22:16:28 +0000 URL: https://git.openjdk.org/loom/commit/cf46004f276293ce8b092fe17ae579cbe45914a2 8300272: Improve readability of the test JarWithOneNonDisabledDigestAlg Reviewed-by: weijun ! test/jdk/jdk/security/jarsigner/JarWithOneNonDisabledDigestAlg.java Changeset: a3ed7e94 Author: Jan Lahoda Date: 2023-01-24 06:40:06 +0000 URL: https://git.openjdk.org/loom/commit/a3ed7e94a23c0c89138d831f4b36b26dce5b3d01 8300623: Lambda deserialization regression involving Enum method reference Reviewed-by: mcimadamore, vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java - test/langtools/tools/javac/lambda/methodReference/8059632/MethodRefQualifyingTypeTest.java - test/langtools/tools/javac/lambda/methodReference/8059632/MethodSupplierImpl.java - test/langtools/tools/javac/lambda/methodReference/8059632/TestBootstrapInvocation.java Changeset: 60b8a985 Author: Adam Sotona Date: 2023-01-24 13:15:02 +0000 URL: https://git.openjdk.org/loom/commit/60b8a98501c6aafa47827b2f05c354c461cfe75c 8300591: @SuppressWarnings option "lossy-conversions" missing from jdk.compiler module javadoc Backport-of: 836198a4009c4a3f10a76dc8734e4792bb2509ba ! src/jdk.compiler/share/classes/module-info.java ! src/jdk.compiler/share/man/javac.1 Changeset: 81d523d3 Author: Jesper Wilhelmsson Date: 2023-01-24 22:28:07 +0000 URL: https://git.openjdk.org/loom/commit/81d523d382331a06ec57b302890ccd4d25fdd095 Merge Changeset: 13394615 Author: Jie Fu Date: 2023-01-24 23:44:35 +0000 URL: https://git.openjdk.org/loom/commit/133946159c699afa2748b41271c15c5a7ec5bc53 8300981: Build failure on 32-bit platforms after JDK-8281213 Reviewed-by: coleenp ! src/hotspot/share/services/memReporter.hpp Changeset: fbe5ab00 Author: David Holmes Date: 2023-01-25 01:05:25 +0000 URL: https://git.openjdk.org/loom/commit/fbe5ab0066e2766124a7f5db155b9634e1790671 8300830: Remove redundant assertion in src/hotspot/share/runtime/javaCalls.cpp Reviewed-by: iklam, rehn, dcubed ! src/hotspot/share/runtime/javaCalls.cpp Changeset: 7465de45 Author: Prasanta Sadhukhan Date: 2023-01-25 05:48:07 +0000 URL: https://git.openjdk.org/loom/commit/7465de453afac9499582cb8c7573bcdc988f623b 6603771: Nimbus L&F: Ctrl+F7 keybinding for Jinternal Frame throws a NPE. Reviewed-by: abhiscxk, serb ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicDesktopPaneUI.java + test/jdk/javax/swing/JInternalFrame/JInternalFrameTest.java Changeset: 5a478ef7 Author: Christian Hagedorn Date: 2023-01-25 07:22:12 +0000 URL: https://git.openjdk.org/loom/commit/5a478ef7759e64da6d17426673700ff0d9c66b33 8297730: C2: Arraycopy intrinsic throws incorrect exception Reviewed-by: thartmann, kvn ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/opto/library_call.hpp + test/hotspot/jtreg/compiler/arraycopy/TestArrayCopyIntrinsicWithUCT.java Changeset: 95fafd09 Author: Erik ?sterlund Date: 2023-01-25 08:15:35 +0000 URL: https://git.openjdk.org/loom/commit/95fafd094f93eaf3ff15c76ca25345123d1586fe 8300644: Remove gc/shenandoah/jni/TestStringCriticalWithDedup.java Reviewed-by: wkemper, mbaesken - test/hotspot/jtreg/gc/shenandoah/jni/TestStringCriticalWithDedup.java - test/hotspot/jtreg/gc/shenandoah/jni/libTestStringCriticalWithDedup.c Changeset: b2071f79 Author: Erik ?sterlund Date: 2023-01-25 08:17:56 +0000 URL: https://git.openjdk.org/loom/commit/b2071f79d854f40df0f3bc2de6828fbcea4d325a 8300657: Remove null filtering in CLD oop handle area Reviewed-by: coleenp, dholmes ! src/hotspot/share/classfile/classLoaderData.cpp Changeset: 3c61d5aa Author: Severin Gehwolf Date: 2023-01-25 10:24:33 +0000 URL: https://git.openjdk.org/loom/commit/3c61d5aa48606dab2d2c639d5f0a56313476917d 8300659: Refactor TestMemoryAwareness to use WhiteBox api for host values Reviewed-by: mbaesken ! src/hotspot/share/prims/whitebox.cpp ! test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java ! test/lib/jdk/test/whitebox/WhiteBox.java Changeset: 71107f46 Author: Johan Sj?len Date: 2023-01-25 10:30:02 +0000 URL: https://git.openjdk.org/loom/commit/71107f4648d8f31a7bcc0aa5202ef46230df583f 8300651: Replace NULL with nullptr in share/runtime/ Reviewed-by: rehn, dholmes ! src/hotspot/share/runtime/abstract_vm_version.cpp ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/arguments.hpp ! src/hotspot/share/runtime/atomic.hpp ! src/hotspot/share/runtime/basicLock.cpp ! src/hotspot/share/runtime/continuationFreezeThaw.cpp ! src/hotspot/share/runtime/deoptimization.cpp ! src/hotspot/share/runtime/deoptimization.hpp ! src/hotspot/share/runtime/escapeBarrier.cpp ! src/hotspot/share/runtime/escapeBarrier.hpp ! src/hotspot/share/runtime/fieldDescriptor.cpp ! src/hotspot/share/runtime/flags/debug_globals.hpp ! src/hotspot/share/runtime/flags/jvmFlag.cpp ! src/hotspot/share/runtime/flags/jvmFlagAccess.cpp ! src/hotspot/share/runtime/flags/jvmFlagAccess.hpp ! src/hotspot/share/runtime/flags/jvmFlagLimit.cpp ! src/hotspot/share/runtime/flags/jvmFlagLimit.hpp ! src/hotspot/share/runtime/flags/jvmFlagLookup.cpp ! src/hotspot/share/runtime/frame.cpp ! src/hotspot/share/runtime/frame.hpp ! src/hotspot/share/runtime/frame.inline.hpp ! src/hotspot/share/runtime/globals.hpp ! src/hotspot/share/runtime/handles.cpp ! src/hotspot/share/runtime/handles.hpp ! src/hotspot/share/runtime/handles.inline.hpp ! src/hotspot/share/runtime/handshake.cpp ! src/hotspot/share/runtime/icache.cpp ! src/hotspot/share/runtime/interfaceSupport.cpp ! src/hotspot/share/runtime/interfaceSupport.inline.hpp ! src/hotspot/share/runtime/java.cpp ! src/hotspot/share/runtime/java.hpp ! src/hotspot/share/runtime/javaCalls.cpp ! src/hotspot/share/runtime/javaCalls.hpp ! src/hotspot/share/runtime/javaFrameAnchor.hpp ! src/hotspot/share/runtime/javaThread.cpp ! src/hotspot/share/runtime/javaThread.hpp ! src/hotspot/share/runtime/javaThread.inline.hpp ! src/hotspot/share/runtime/jniHandles.cpp ! src/hotspot/share/runtime/jniHandles.hpp ! src/hotspot/share/runtime/jniHandles.inline.hpp ! src/hotspot/share/runtime/jniPeriodicChecker.cpp ! src/hotspot/share/runtime/jniPeriodicChecker.hpp ! src/hotspot/share/runtime/keepStackGCProcessed.cpp ! src/hotspot/share/runtime/monitorChunk.cpp ! src/hotspot/share/runtime/mutex.cpp ! src/hotspot/share/runtime/mutex.hpp ! src/hotspot/share/runtime/mutexLocker.cpp ! src/hotspot/share/runtime/mutexLocker.hpp ! src/hotspot/share/runtime/nonJavaThread.cpp ! src/hotspot/share/runtime/nonJavaThread.hpp ! src/hotspot/share/runtime/objectMonitor.cpp ! src/hotspot/share/runtime/objectMonitor.hpp ! src/hotspot/share/runtime/objectMonitor.inline.hpp ! src/hotspot/share/runtime/orderAccess.cpp ! src/hotspot/share/runtime/os.cpp ! src/hotspot/share/runtime/os.hpp ! src/hotspot/share/runtime/os.inline.hpp ! src/hotspot/share/runtime/park.cpp ! src/hotspot/share/runtime/park.hpp ! src/hotspot/share/runtime/perfData.cpp ! src/hotspot/share/runtime/perfData.hpp ! src/hotspot/share/runtime/perfData.inline.hpp ! src/hotspot/share/runtime/perfMemory.cpp ! src/hotspot/share/runtime/perfMemory.hpp ! src/hotspot/share/runtime/reflection.cpp ! src/hotspot/share/runtime/reflectionUtils.cpp ! src/hotspot/share/runtime/registerMap.hpp ! src/hotspot/share/runtime/relocator.cpp ! src/hotspot/share/runtime/relocator.hpp ! src/hotspot/share/runtime/safepoint.cpp ! src/hotspot/share/runtime/serviceThread.cpp ! src/hotspot/share/runtime/sharedRuntime.cpp ! src/hotspot/share/runtime/sharedRuntime.hpp ! src/hotspot/share/runtime/signature.cpp ! src/hotspot/share/runtime/signature.hpp ! src/hotspot/share/runtime/stackChunkFrameStream.hpp ! src/hotspot/share/runtime/stackValue.cpp ! src/hotspot/share/runtime/stackWatermark.cpp ! src/hotspot/share/runtime/stackWatermarkSet.cpp ! src/hotspot/share/runtime/stackWatermarkSet.inline.hpp ! src/hotspot/share/runtime/statSampler.cpp ! src/hotspot/share/runtime/statSampler.hpp ! src/hotspot/share/runtime/stubCodeGenerator.cpp ! src/hotspot/share/runtime/stubCodeGenerator.hpp ! src/hotspot/share/runtime/stubRoutines.cpp ! src/hotspot/share/runtime/stubRoutines.hpp ! src/hotspot/share/runtime/synchronizer.cpp ! src/hotspot/share/runtime/synchronizer.hpp ! src/hotspot/share/runtime/task.cpp ! src/hotspot/share/runtime/thread.cpp ! src/hotspot/share/runtime/thread.hpp ! src/hotspot/share/runtime/threadSMR.cpp ! src/hotspot/share/runtime/threadSMR.hpp ! src/hotspot/share/runtime/threadSMR.inline.hpp ! src/hotspot/share/runtime/threads.cpp ! src/hotspot/share/runtime/timerTrace.cpp ! src/hotspot/share/runtime/timerTrace.hpp ! src/hotspot/share/runtime/unhandledOops.cpp ! src/hotspot/share/runtime/unhandledOops.hpp ! src/hotspot/share/runtime/vframe.cpp ! src/hotspot/share/runtime/vframe.hpp ! src/hotspot/share/runtime/vframe.inline.hpp ! src/hotspot/share/runtime/vframeArray.cpp ! src/hotspot/share/runtime/vframe_hp.cpp ! src/hotspot/share/runtime/vframe_hp.hpp ! src/hotspot/share/runtime/vmOperation.hpp ! src/hotspot/share/runtime/vmOperations.cpp ! src/hotspot/share/runtime/vmOperations.hpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/hotspot/share/runtime/vmStructs.hpp ! src/hotspot/share/runtime/vmThread.cpp ! src/hotspot/share/runtime/vmThread.hpp Changeset: a5d8e128 Author: Johan Sj?len Date: 2023-01-25 10:31:51 +0000 URL: https://git.openjdk.org/loom/commit/a5d8e12872d9de399fa97b33896635d101b71372 8300244: Replace NULL with nullptr in share/interpreter/ Reviewed-by: coleenp, dholmes ! src/hotspot/share/interpreter/abstractInterpreter.cpp ! src/hotspot/share/interpreter/abstractInterpreter.hpp ! src/hotspot/share/interpreter/bootstrapInfo.cpp ! src/hotspot/share/interpreter/bootstrapInfo.hpp ! src/hotspot/share/interpreter/bytecode.cpp ! src/hotspot/share/interpreter/bytecode.hpp ! src/hotspot/share/interpreter/bytecodeTracer.cpp ! src/hotspot/share/interpreter/bytecodeUtils.cpp ! src/hotspot/share/interpreter/bytecodes.cpp ! src/hotspot/share/interpreter/bytecodes.hpp ! src/hotspot/share/interpreter/interpreter.cpp ! src/hotspot/share/interpreter/interpreterRuntime.cpp ! src/hotspot/share/interpreter/linkResolver.cpp ! src/hotspot/share/interpreter/linkResolver.hpp ! src/hotspot/share/interpreter/oopMapCache.cpp ! src/hotspot/share/interpreter/rewriter.cpp ! src/hotspot/share/interpreter/templateInterpreter.cpp ! src/hotspot/share/interpreter/templateInterpreter.hpp ! src/hotspot/share/interpreter/templateInterpreterGenerator.cpp ! src/hotspot/share/interpreter/templateInterpreterGenerator.hpp ! src/hotspot/share/interpreter/templateTable.hpp ! src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp ! src/hotspot/share/interpreter/zero/bytecodeInterpreter.inline.hpp ! src/hotspot/share/interpreter/zero/zeroInterpreter.hpp ! src/hotspot/share/interpreter/zero/zeroInterpreterGenerator.cpp Changeset: 74e1a8bf Author: Per Minborg Date: 2023-01-25 12:54:27 +0000 URL: https://git.openjdk.org/loom/commit/74e1a8bfa852a55fb8e6e93e19e2999f4d23f959 8300236: Use VarHandle access in Data(Input | Output)Stream classes Reviewed-by: rriggs, alanb - src/java.base/share/classes/java/io/Bits.java ! src/java.base/share/classes/java/io/DataInputStream.java ! src/java.base/share/classes/java/io/DataOutputStream.java ! src/java.base/share/classes/java/io/ObjectInputStream.java ! src/java.base/share/classes/java/io/ObjectOutputStream.java ! src/java.base/share/classes/java/io/ObjectStreamClass.java ! src/java.base/share/classes/java/io/RandomAccessFile.java + src/java.base/share/classes/jdk/internal/util/ByteArray.java - test/jdk/java/io/Bits/ReadWriteValues.java - test/jdk/java/io/Bits/java.base/java/io/BitsProxy.java + test/jdk/jdk/internal/util/ByteArray/ReadWriteValues.java + test/micro/org/openjdk/bench/java/io/PrimitiveFieldSerializationBenchmark.java Changeset: c8ad6000 Author: Daniel Fuchs Date: 2023-01-25 13:33:22 +0000 URL: https://git.openjdk.org/loom/commit/c8ad6000646abd6e1faac396d901135c85c73cf5 8301004: httpclient: Add more debug to HttpResponseInputStream Reviewed-by: jpai ! src/java.net.http/share/classes/jdk/internal/net/http/ResponseSubscribers.java Changeset: 8a47429d Author: Jaikiran Pai Date: 2023-01-25 13:38:02 +0000 URL: https://git.openjdk.org/loom/commit/8a47429dc065ad7645a40fa2350d043ef4606d92 8295944: Move the Http2TestServer and related classes into a package of its own Reviewed-by: dfuchs ! test/jdk/com/sun/net/httpserver/SANTest.java ! test/jdk/java/net/httpclient/ALPNProxyFailureTest.java ! test/jdk/java/net/httpclient/AbstractNoBody.java ! test/jdk/java/net/httpclient/AbstractThrowingPublishers.java ! test/jdk/java/net/httpclient/AbstractThrowingPushPromises.java ! test/jdk/java/net/httpclient/AbstractThrowingSubscribers.java ! test/jdk/java/net/httpclient/AggregateRequestBodyTest.java ! test/jdk/java/net/httpclient/AsFileDownloadTest.java ! test/jdk/java/net/httpclient/AsFileDownloadTest.policy ! test/jdk/java/net/httpclient/AsyncExecutorShutdown.java ! test/jdk/java/net/httpclient/AuthFilterCacheTest.java ! test/jdk/java/net/httpclient/BasicRedirectTest.java ! test/jdk/java/net/httpclient/CancelRequestTest.java ! test/jdk/java/net/httpclient/CancelStreamedBodyTest.java ! test/jdk/java/net/httpclient/ConcurrentResponses.java ! test/jdk/java/net/httpclient/CookieHeaderTest.java ! test/jdk/java/net/httpclient/CustomRequestPublisher.java ! test/jdk/java/net/httpclient/CustomResponseSubscriber.java ! test/jdk/java/net/httpclient/DependentActionsTest.java ! test/jdk/java/net/httpclient/DependentPromiseActionsTest.java ! test/jdk/java/net/httpclient/DigestEchoClient.java ! test/jdk/java/net/httpclient/DigestEchoClientSSL.java ! test/jdk/java/net/httpclient/DigestEchoServer.java ! test/jdk/java/net/httpclient/EncodedCharsInURI.java ! test/jdk/java/net/httpclient/EscapedOctetsInURI.java ! test/jdk/java/net/httpclient/ExecutorShutdown.java ! test/jdk/java/net/httpclient/ExpectContinueTest.java ! test/jdk/java/net/httpclient/FilePublisher/FilePublisherPermsTest.java ! test/jdk/java/net/httpclient/FilePublisher/FilePublisherPermsTest1.policy ! test/jdk/java/net/httpclient/FilePublisher/FilePublisherPermsTest2.policy ! test/jdk/java/net/httpclient/FilePublisher/FilePublisherPermsTest3.policy ! test/jdk/java/net/httpclient/FilePublisher/FilePublisherTest.java ! test/jdk/java/net/httpclient/FilePublisher/FilePublisherTest.policy ! test/jdk/java/net/httpclient/FlowAdapterPublisherTest.java ! test/jdk/java/net/httpclient/FlowAdapterSubscriberTest.java ! test/jdk/java/net/httpclient/ForbiddenHeadTest.java ! test/jdk/java/net/httpclient/GZIPInputStreamTest.java ! test/jdk/java/net/httpclient/HeadTest.java ! test/jdk/java/net/httpclient/HttpClientLocalAddrTest.java ! test/jdk/java/net/httpclient/HttpRedirectTest.java ! test/jdk/java/net/httpclient/HttpSlowServerTest.java ! test/jdk/java/net/httpclient/HttpVersionsTest.java ! test/jdk/java/net/httpclient/HttpsTunnelAuthTest.java ! test/jdk/java/net/httpclient/HttpsTunnelTest.java ! test/jdk/java/net/httpclient/ISO_8859_1_Test.java ! test/jdk/java/net/httpclient/ImmutableFlowItems.java ! test/jdk/java/net/httpclient/InvalidInputStreamSubscriptionRequest.java ! test/jdk/java/net/httpclient/InvalidSubscriptionRequest.java ! test/jdk/java/net/httpclient/LargeHandshakeTest.java ! test/jdk/java/net/httpclient/LargeResponseTest.java ! test/jdk/java/net/httpclient/LineBodyHandlerTest.java ! test/jdk/java/net/httpclient/MappingResponseSubscriber.java ! test/jdk/java/net/httpclient/MaxStreams.java ! test/jdk/java/net/httpclient/NoBodyPartOne.java ! test/jdk/java/net/httpclient/NoBodyPartTwo.java ! test/jdk/java/net/httpclient/NonAsciiCharsInURI.java ! test/jdk/java/net/httpclient/PathSubscriber/BodyHandlerOfFileDownloadTest.java ! test/jdk/java/net/httpclient/PathSubscriber/BodyHandlerOfFileTest.java ! test/jdk/java/net/httpclient/PathSubscriber/BodySubscriberOfFileTest.java ! test/jdk/java/net/httpclient/PathSubscriber/ofFile.policy ! test/jdk/java/net/httpclient/PathSubscriber/ofFileDownload.policy ! test/jdk/java/net/httpclient/ProxyAuthDisabledSchemes.java ! test/jdk/java/net/httpclient/ProxyAuthDisabledSchemesSSL.java ! test/jdk/java/net/httpclient/ProxySelectorTest.java ! test/jdk/java/net/httpclient/RedirectMethodChange.java ! test/jdk/java/net/httpclient/RedirectWithCookie.java ! test/jdk/java/net/httpclient/Response1xxTest.java ! test/jdk/java/net/httpclient/Response204V2Test.java ! test/jdk/java/net/httpclient/ResponsePublisher.java ! test/jdk/java/net/httpclient/RetryWithCookie.java ! test/jdk/java/net/httpclient/ServerCloseTest.java ! test/jdk/java/net/httpclient/SpecialHeadersTest.java ! test/jdk/java/net/httpclient/StreamCloseTest.java ! test/jdk/java/net/httpclient/StreamingBody.java ! test/jdk/java/net/httpclient/TEST.properties ! test/jdk/java/net/httpclient/ThrowingPublishersCustomAfterCancel.java ! test/jdk/java/net/httpclient/ThrowingPublishersCustomBeforeCancel.java ! test/jdk/java/net/httpclient/ThrowingPublishersIOAfterCancel.java ! test/jdk/java/net/httpclient/ThrowingPublishersIOBeforeCancel.java ! test/jdk/java/net/httpclient/ThrowingPublishersInNextRequest.java ! test/jdk/java/net/httpclient/ThrowingPublishersInRequest.java ! test/jdk/java/net/httpclient/ThrowingPublishersInSubscribe.java ! test/jdk/java/net/httpclient/ThrowingPublishersSanity.java ! test/jdk/java/net/httpclient/ThrowingPushPromisesAsInputStreamCustom.java ! test/jdk/java/net/httpclient/ThrowingPushPromisesAsInputStreamIO.java ! test/jdk/java/net/httpclient/ThrowingPushPromisesAsLinesCustom.java ! test/jdk/java/net/httpclient/ThrowingPushPromisesAsLinesIO.java ! test/jdk/java/net/httpclient/ThrowingPushPromisesAsStringCustom.java ! test/jdk/java/net/httpclient/ThrowingPushPromisesAsStringIO.java ! test/jdk/java/net/httpclient/ThrowingPushPromisesSanity.java ! test/jdk/java/net/httpclient/ThrowingSubscribersAsInputStream.java ! test/jdk/java/net/httpclient/ThrowingSubscribersAsInputStreamAsync.java ! test/jdk/java/net/httpclient/ThrowingSubscribersAsLines.java ! test/jdk/java/net/httpclient/ThrowingSubscribersAsLinesAsync.java ! test/jdk/java/net/httpclient/ThrowingSubscribersAsString.java ! test/jdk/java/net/httpclient/ThrowingSubscribersAsStringAsync.java ! test/jdk/java/net/httpclient/ThrowingSubscribersSanity.java ! test/jdk/java/net/httpclient/TlsContextTest.java ! test/jdk/java/net/httpclient/UnauthorizedTest.java ! test/jdk/java/net/httpclient/UserCookieTest.java ! test/jdk/java/net/httpclient/dependent.policy ! test/jdk/java/net/httpclient/http2/BadHeadersTest.java ! test/jdk/java/net/httpclient/http2/BasicTest.java ! test/jdk/java/net/httpclient/http2/ContinuationFrameTest.java ! test/jdk/java/net/httpclient/http2/ErrorTest.java ! test/jdk/java/net/httpclient/http2/FixedThreadPoolTest.java ! test/jdk/java/net/httpclient/http2/IdleConnectionTimeoutTest.java ! test/jdk/java/net/httpclient/http2/ImplicitPushCancel.java ! test/jdk/java/net/httpclient/http2/NoBodyTest.java ! test/jdk/java/net/httpclient/http2/ProxyTest2.java ! test/jdk/java/net/httpclient/http2/PushPromiseContinuation.java ! test/jdk/java/net/httpclient/http2/RedirectTest.java ! test/jdk/java/net/httpclient/http2/ServerPush.java ! test/jdk/java/net/httpclient/http2/ServerPushWithDiffTypes.java ! test/jdk/java/net/httpclient/http2/TLSConnection.java ! test/jdk/java/net/httpclient/http2/UserInfoTest.java ! test/jdk/java/net/httpclient/httpclient-localaddr-security.policy = test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/common/ExceptionallyCloseable.java = test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/common/HttpServerAdapters.java = test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/common/TestUtil.java = test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/http2/BodyInputStream.java = test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/http2/BodyOutputStream.java = test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/http2/EchoHandler.java = test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/http2/Http2EchoHandler.java = test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/http2/Http2Handler.java = test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/http2/Http2RedirectHandler.java = test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/http2/Http2TestExchange.java = test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/http2/Http2TestExchangeImpl.java = test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/http2/Http2TestExchangeSupplier.java = test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/http2/Http2TestServer.java = test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/http2/Http2TestServerConnection.java = test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/http2/NoBodyHandler.java = test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/http2/OutgoingPushPromise.java = test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/http2/PushHandler.java = test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/http2/Queue.java Changeset: 61775c85 Author: Eirik Bjorsnos Committer: Erik Joelsson Date: 2023-01-25 14:01:03 +0000 URL: https://git.openjdk.org/loom/commit/61775c85b0989e4de310290e9441851f32cb84a3 8300997: Add curl support to createJMHBundle.sh Reviewed-by: erikj ! make/devkit/createJMHBundle.sh Changeset: a23ff63a Author: Per Minborg Date: 2023-01-25 14:13:22 +0000 URL: https://git.openjdk.org/loom/commit/a23ff63af147067e0704970a9f9e6d847df22dff 8301086: jdk/internal/util/ByteArray/ReadWriteValues.java fails with CompilationError Reviewed-by: dfuchs ! test/jdk/jdk/internal/util/ByteArray/ReadWriteValues.java Changeset: f279c751 Author: Erik Joelsson Date: 2023-01-25 14:14:56 +0000 URL: https://git.openjdk.org/loom/commit/f279c751a5b2132c11aa3a31084ee37f1a349150 8300805: Update autoconf build-aux files with latest from 2022-09-17 Reviewed-by: mikael, clanger ! make/autoconf/build-aux/autoconf-config.guess ! make/autoconf/build-aux/autoconf-config.sub ! make/autoconf/build-aux/config.guess ! make/autoconf/build-aux/config.sub Changeset: e80b5ea4 Author: Xue-Lei Andrew Fan Date: 2023-01-25 15:42:53 +0000 URL: https://git.openjdk.org/loom/commit/e80b5ea448c715519d14e238321ceb5ec40b37f4 8299635: Hotspot update for deprecated sprintf in Xcode 14 Reviewed-by: dholmes, mikael ! src/hotspot/cpu/arm/arm.ad ! src/hotspot/cpu/ppc/ppc.ad ! src/hotspot/os/aix/attachListener_aix.cpp ! src/hotspot/os/aix/os_aix.cpp ! src/hotspot/os/linux/attachListener_linux.cpp ! src/hotspot/os/linux/os_linux.cpp ! src/hotspot/os/windows/os_windows.cpp ! src/hotspot/share/adlc/formssel.cpp ! src/hotspot/share/opto/callnode.cpp ! src/hotspot/share/opto/cfgnode.cpp ! src/hotspot/share/opto/chaitin.cpp ! src/hotspot/share/opto/chaitin.hpp ! src/hotspot/share/opto/idealGraphPrinter.cpp ! src/hotspot/share/opto/node.cpp ! src/hotspot/share/opto/regalloc.hpp ! src/hotspot/share/opto/type.cpp ! src/hotspot/share/utilities/globalDefinitions.hpp ! test/hotspot/jtreg/runtime/Thread/libAsyncExceptionOnMonitorEnter.cpp ! test/hotspot/jtreg/serviceability/jvmti/AddModuleExportsAndOpens/libAddModuleExportsAndOpensTest.c ! test/hotspot/jtreg/serviceability/jvmti/events/ThreadEnd/threadend01/libthreadend01.cpp ! test/hotspot/jtreg/serviceability/jvmti/events/ThreadStart/threadstart01/libthreadstart01.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/CreateRawMonitor/crrawmon001/crrawmon001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/DestroyRawMonitor/drrawmon001/drrawmon001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorEnter/rawmonenter001/rawmonenter001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorExit/rawmonexit001/rawmonexit001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorNotify/rawmnntfy001/rawmnntfy001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorNotifyAll/rawmnntfyall001/rawmnntfyall001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorWait/rawmnwait001/rawmnwait001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI04/bi04t002/bi04t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS201/hs201t001/hs201t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS201/hs201t002/hs201t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/GetAllStackTraces/getallstktr001/getallstktr001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/MethodBind/JvmtiTest/JvmtiTest.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/StackTrace/JvmtiTest/JvmtiTest.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/functions/nosuspendStackTrace/JvmtiTest/JvmtiTest.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/functions/rawmonitor/rawmonitor.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/JVMTIagent.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/aod/jvmti_aod.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_tools.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/native/nsk_tools.cpp Changeset: edf1e1ab Author: Justin King Committer: Magnus Ihse Bursie Date: 2023-01-25 16:18:29 +0000 URL: https://git.openjdk.org/loom/commit/edf1e1ab4a49aab0990457e534cc4f7e7518efef 8300592: ASan build does not correctly propagate options to some test launchers Reviewed-by: ihse ! make/autoconf/jdk-options.m4 ! make/common/TestFilesCompilation.gmk = make/data/asan/asan_default_options.cpp ! make/hotspot/lib/CompileGtest.gmk ! make/test/JtregNativeHotspot.gmk ! make/test/JtregNativeJdk.gmk Changeset: ccf2f583 Author: Mikael Vidstedt Date: 2023-01-25 18:27:26 +0000 URL: https://git.openjdk.org/loom/commit/ccf2f5837b31cddd24ec81f7f67107d9fc03c294 8300806: Update googletest to v1.13.0 Reviewed-by: erikj, ihse ! .github/actions/get-gtest/action.yml ! doc/building.html ! doc/building.md ! make/autoconf/lib-tests.m4 ! make/conf/github-actions.conf ! make/conf/jib-profiles.js ! test/hotspot/gtest/gtestMain.cpp