On Tue, 26 Nov 2024 01:41:34 GMT, David Holmes <dhol...@openjdk.org> wrote:
>> c.f: >> [https://bugs.openjdk.org/browse/JDK-8339420](https://bugs.openjdk.org/browse/JDK-8339420) >> >> Summary >> ------- >> >> Add `jcmd <pid> Thread.vthread_summary` to print summary information that is >> useful when trying to diagnose issues with virtual threads. >> >> >> Problem >> ------- >> >> The JDK is lacking tooling to diagnose issues with virtual threads. >> >> >> Solution >> -------- >> >> Add a new command that the `jcmd` command line tool can use to print >> information about virtual threads. The output includes the virtual thread >> scheduler, the schedulers used to support timeouts, and the I/O pollers used >> to support virtual threads doing socket I/O, and a summary of the thread >> groupings. >> >> Here is sample output. The output is intended for experts and is not >> intended for automated parsing. >> >> >> Virtual thread scheduler: >> java.util.concurrent.ForkJoinPool@4a624db0[Running, parallelism = 16, size = >> 2, active = 0, running = 0, steals = 2, tasks = 0, submissions = 0] >> >> Timeout schedulers: >> [0] java.util.concurrent.ScheduledThreadPoolExecutor@1f17ae12[Running, pool >> size = 0, active threads = 0, queued tasks = 0, completed tasks = 0] >> [1] java.util.concurrent.ScheduledThreadPoolExecutor@6193b845[Running, pool >> size = 1, active threads = 0, queued tasks = 1, completed tasks = 0] >> [2] java.util.concurrent.ScheduledThreadPoolExecutor@c4437c4[Running, pool >> size = 0, active threads = 0, queued tasks = 0, completed tasks = 0] >> [3] java.util.concurrent.ScheduledThreadPoolExecutor@3f91beef[Running, pool >> size = 0, active threads = 0, queued tasks = 0, completed tasks = 0] >> >> Read I/O pollers: >> [0] sun.nio.ch.KQueuePoller@524bf25 [registered = 1] >> >> Write I/O pollers: >> [0] sun.nio.ch.KQueuePoller@25c41da2 [registered = 0] >> >> Thread groupings: >> <root> [platform threads = 11, virtual threads = 0] >> java.util.concurrent.ScheduledThreadPoolExecutor@c4437c4 [platform threads = >> 0, virtual threads = 0] >> java.util.concurrent.ScheduledThreadPoolExecutor@3f91beef [platform threads >> = 0, virtual threads = 0] >> ForkJoinPool.commonPool/jdk.internal.vm.SharedThreadContainer@4fa374ea >> [platform threads = 0, virtual threads = 0] >> java.util.concurrent.ThreadPoolExecutor@506e1b77 [platform threads = 1, >> virtual threads = 0] >> java.util.concurrent.ScheduledThreadPoolExecutor@1f17ae12 [platform threads >> = 0, virtual threads = 0] >> java.util.concurrent.ThreadPerTaskExecutor@24155ffc [platform threads = 0, >> virtual threads = 2] >> ForkJoinPool-1/jdk.internal.vm.SharedThreadC... > > src/java.base/share/classes/jdk/internal/vm/VThreadSummary.java line 106: > >> 104: .append(masterPoller) >> 105: .append(System.lineSeparator()); >> 106: sb.append(System.lineSeparator()); > > Is this style trying to draw attention to the blank lines between sections? > It looks odd to me to not chain the final append as well. It is a blank line, shouldn't be chained to the previous statement. > src/java.base/share/classes/sun/nio/ch/Poller.java line 280: > >> 278: public String toString() { >> 279: return Objects.toIdentityString(this) + " [registered = " + >> map.size() + "]"; >> 280: } > > Why did you move this and "inline" the content of `registered()`? I think that is PR merge issue, it's correct in the loom repo. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22121#discussion_r1857890217 PR Review Comment: https://git.openjdk.org/jdk/pull/22121#discussion_r1857890689
