<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=gb2312">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
Hi Leslie,</div>
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
<br>
</div>
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
To close the loop for now: turns out that the app from which I got the "problematic" gc.log (with no "gc,start" tags) is no longer running with ZGC. That was just an experiment, and all the logs are already gone (or at least it would be quite hard to find them
and determine the JVM configuration at the time when they were generated). A few apps that currently do run with ZGC generate logs with "gc,start" present.</div>
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
<br>
</div>
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
So for now I am not sure what it was - perhaps some kind of misconfiguration somewhere. I'll keep an eye on this as more apps at LI pick up ZGC, and will let you know if anything suspicious happens.</div>
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
<br>
</div>
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
Misha</div>
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
<br>
</div>
<div id="appendonsend"></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> zgc-dev <zgc-dev-retn@openjdk.org> on behalf of Misha Dmitriev <mdmitriev@linkedin.com><br>
<b>Sent:</b> Sunday, September 17, 2023 12:46 PM<br>
<b>To:</b> Leslie Zhai <zhaixiang@loongson.cn><br>
<b>Cc:</b> zgc-dev@openjdk.org <zgc-dev@openjdk.org><br>
<b>Subject:</b> Re: What gc.log lines reliably indicate STW pauses for ZGC?</font>
<div> </div>
</div>
<style type="text/css" style="display:none">
<!--
p
{margin-top:0;
margin-bottom:0}
-->
</style>
<div dir="ltr">
<div class="x_elementToProof" style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
Hi Leslie,</div>
<div class="x_elementToProof" style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<div class="x_elementToProof" style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
I am currently on vacation, will get back to this when I return in the second half of the next week.</div>
<div class="x_elementToProof" style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<div class="x_elementToProof" style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
For now, I can only say that of two ZGC logs that I currently have, from two different apps running in production, one doesn't have any lines with the 'gc,start' tags (and it's a pretty big log, 71M - whereas another one does have some such lines. Otherwise
the logs look similar.</div>
<div class="x_elementToProof" style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<span style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; color:rgb(0,0,0)">When I return, I'll check the GC logging configuration etc. for both apps. Meanwhile, it would be good if you further investigate the conditions
under which ZStatPhaseCycle::register_start may not print to the log (or may not be called at all?)</span></div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<span style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; color:rgb(0,0,0)"><br>
</span></div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<span style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; color:rgb(0,0,0)">Misha</span></div>
<div id="x_appendonsend"></div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> Leslie Zhai <zhaixiang@loongson.cn><br>
<b>Sent:</b> Friday, September 15, 2023 7:40 PM<br>
<b>To:</b> Misha Dmitriev <mdmitriev@linkedin.com><br>
<b>Cc:</b> zgc-dev@openjdk.org <zgc-dev@openjdk.org><br>
<b>Subject:</b> Re: What gc.log lines reliably indicate STW pauses for ZGC?</font>
<div> </div>
</div>
<div class="x_BodyFragment"><font size="2"><span style="font-size:11pt">
<div class="x_PlainText">Hi Misha,<br>
<br>
I investigated why GCViewer failed to parse jdk17 single generation ZGC:<br>
<br>
The intuitive phenomenon is `parentEvent` is null[1]:<br>
<br>
AbstractGCEvent<?> parentEvent = context.getPartialEventsMap().get(event.getNumber() + "¡±);<br>
<br>
<br>
Then there is no opportunity to return ZGC event[2] but instead return null.<br>
<br>
But why `parentEvent` AKA `context.getPartialEventsMap().get(eventNumber)` is null?<br>
<br>
That¡¯s due to `Map<String, AbstractGCEvent<?>> partialEventsMap` doesn¡¯t contain (through `put`) such event[3]:<br>
<br>
context.getPartialEventsMap().put(event.getNumber() + "", event);<br>
<br>
<br>
So the root cause is there are no `gc,start` tags to `handleTagGcStartTail`[4]:<br>
<br>
case TAG_GC_START: // <¡ª TAG_GC_START = "gc,start";<br>
returnEvent = handleTagGcStartTail(context, event);<br>
break;<br>
<br>
<br>
I am investigating why jdk17 single generation `ZStatPhaseCycle::register_start` failed to `log_info(gc, start)`???
<br>
<br>
I also dumped the jdk17 single generation ZGC log for Renaissance[6] philosophers for x86_64, aarch64 and also loongarch64:<br>
<br>
-XX:+UseZGC -Xlog:gc*=debug:file=zgc-`date +%Y%m%d%H%M%S`.log:time,uptime,level,tags -jar renaissance-gpl-0.14.2.jar philosophers<br>
<br>
And there are `gc,start` tags:<br>
<br>
[2023-09-16T10:27:34.880+0800][0.485s][info ][gc,start ] GC(0) Garbage Collection (System.gc())<br>
[2023-09-16T10:27:35.903+0800][1.508s][info ][gc,start ] GC(1) Garbage Collection (Warmup)<br>
[2023-09-16T10:27:36.803+0800][2.408s][info ][gc,start ] GC(2) Garbage Collection (Warmup)<br>
[2023-09-16T10:27:38.103+0800][3.708s][info ][gc,start ] GC(3) Garbage Collection (Warmup)<br>
[2023-09-16T10:27:38.282+0800][3.887s][info ][gc,start ] GC(4) Garbage Collection (System.gc())<br>
[2023-09-16T10:27:39.103+0800][4.708s][info ][gc,start ] GC(5) Garbage Collection (Proactive)<br>
[2023-09-16T10:27:40.103+0800][5.708s][info ][gc,start ] GC(6) Garbage Collection (Proactive)<br>
[2023-09-16T10:27:40.903+0800][6.508s][info ][gc,start ] GC(7) Garbage Collection (Proactive)<br>
<br>
Why there are no `gc,start` tags in your jdk17-zgc.gc.log???<br>
<br>
Could you run Renaissance philosophers and dump the log in your real production environment shown as above?<br>
<br>
What is your real production environment? lscpu? sysctl -a | grep machdep.cpu?<br>
<br>
Thanks,<br>
Leslie Zhai<br>
<br>
<br>
1. <a href="https://github.com/chewiebug/GCViewer/blob/develop/src/main/java/com/tagtraum/perf/gcviewer/imp/DataReaderUnifiedJvmLogging.java#L303" originalsrc="https://github.com/chewiebug/GCViewer/blob/develop/src/main/java/com/tagtraum/perf/gcviewer/imp/DataReaderUnifiedJvmLogging.java#L303" shash="U1bvKo+b7oaffFGqtDUeFZMlZNBL4vL1lRPMky+SLUaK8GYCWFNNgp+jkJdH7nPyrOnY8Wz5whQEgL/lqbxiGasIcab8GpCx5MwVlLdxjbHqQ2vNf3b+o+2HSt2JQIsrYsj+aSt+TFzGt3eqYQMx2h6pnJFoLC/25excW89Fmtw=">
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fchewiebug%2FGCViewer%2Fblob%2Fdevelop%2Fsrc%2Fmain%2Fjava%2Fcom%2Ftagtraum%2Fperf%2Fgcviewer%2Fimp%2FDataReaderUnifiedJvmLogging.java%23L303&data=05%7C01%7Cmdmitriev%40linkedin.com%7C4d110bc930284e890e6308dbb65e5ec5%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C638304288679249773%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=7KtXLn6Vpau46Nf15NuSsUwvkH%2BCAorYI2S1QosBXTg%3D&reserved=0</a><br>
<br>
2. <a href="https://github.com/chewiebug/GCViewer/blob/develop/src/main/java/com/tagtraum/perf/gcviewer/model/AbstractGCEvent.java#L714" originalsrc="https://github.com/chewiebug/GCViewer/blob/develop/src/main/java/com/tagtraum/perf/gcviewer/model/AbstractGCEvent.java#L714" shash="kFCvSbJbC0l4zY13uWfzxLKUXdfTDz5KeCehvY+ONqcQ+5MfLxi0s+uL+JeI7oQP8vSOG7/lJCBo4eMSrzGqvl6AmbbFMnWqKWqj9xMONlYv5Uby6qz3Ne8gUYlQm82obp82L0hq80HBnggj7xGoHF/R7P6wCDPqS0Zh5QHidoY=">
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fchewiebug%2FGCViewer%2Fblob%2Fdevelop%2Fsrc%2Fmain%2Fjava%2Fcom%2Ftagtraum%2Fperf%2Fgcviewer%2Fmodel%2FAbstractGCEvent.java%23L714&data=05%7C01%7Cmdmitriev%40linkedin.com%7C4d110bc930284e890e6308dbb65e5ec5%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C638304288679249773%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=IlIjpMQRSM72bBG3UQMNGaEKvVKvyUblfVREIlkVNSY%3D&reserved=0</a><br>
<br>
3. <a href="https://github.com/chewiebug/GCViewer/blob/develop/src/main/java/com/tagtraum/perf/gcviewer/imp/DataReaderUnifiedJvmLogging.java#L296" originalsrc="https://github.com/chewiebug/GCViewer/blob/develop/src/main/java/com/tagtraum/perf/gcviewer/imp/DataReaderUnifiedJvmLogging.java#L296" shash="gHu3Y6uHkj3Jb5YtQl80bw3IyzWaJx2knXM32EXytvaf/2+/RIVfxdvRNO534iSfgI1YnL+uogPZgPUPENM94Wv+dGTtn8Pmc5aTb3yyZ+VV7FaxEm3mE/FYYmb8BdJZ7BX8hVf2aI/LY3gtxZp6vY4mnNSxg/dEwDIx29RonQ0=">
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fchewiebug%2FGCViewer%2Fblob%2Fdevelop%2Fsrc%2Fmain%2Fjava%2Fcom%2Ftagtraum%2Fperf%2Fgcviewer%2Fimp%2FDataReaderUnifiedJvmLogging.java%23L296&data=05%7C01%7Cmdmitriev%40linkedin.com%7C4d110bc930284e890e6308dbb65e5ec5%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C638304288679249773%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=uarOB8FIf7dWkgomQ7ICTRhL6yUbGBKK%2BwL2X6kOozI%3D&reserved=0</a><br>
<br>
4. <a href="https://github.com/chewiebug/GCViewer/blob/develop/src/main/java/com/tagtraum/perf/gcviewer/imp/DataReaderUnifiedJvmLogging.java#L264" originalsrc="https://github.com/chewiebug/GCViewer/blob/develop/src/main/java/com/tagtraum/perf/gcviewer/imp/DataReaderUnifiedJvmLogging.java#L264" shash="nFPga1pVdy5UUxv7JrEyFomB6mTBtwXIsXI8WdsjmNSJ9MiCB+VE5vo8/WPQLdvPp97MtRbiMLNb+VQx5jKqujU1K6FaQSnFD8wDglh1xkWmyCbcCGvBFcHXXgFURDcBGyPtlGh4Im2gU0s5GoQG3lXT5N1cy3/46dA6cLgnNRo=">
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fchewiebug%2FGCViewer%2Fblob%2Fdevelop%2Fsrc%2Fmain%2Fjava%2Fcom%2Ftagtraum%2Fperf%2Fgcviewer%2Fimp%2FDataReaderUnifiedJvmLogging.java%23L264&data=05%7C01%7Cmdmitriev%40linkedin.com%7C4d110bc930284e890e6308dbb65e5ec5%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C638304288679249773%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2B%2Fd9vgM%2BcDmQG%2Baihz4CcgTWQjxrujdR6y5WflT17tM%3D&reserved=0</a><br>
<br>
5. <a href="https://github.com/openjdk/jdk17u-dev/blob/master/src/hotspot/share/gc/z/zStat.cpp#L641" originalsrc="https://github.com/openjdk/jdk17u-dev/blob/master/src/hotspot/share/gc/z/zStat.cpp#L641" shash="Dkr8G003wh4MMfS1tWmTYxdCKHr2WMIFuoz9fcoDzK78NscKd+ZRh1auEjDtZNHrNadr5LG4hWb1Q/Kw3mZsuz7h+eje7gyCcD8yjlb5+NFm6UMNZ2GweEK4e213GCIEvdXD7ACU6OdwvKGAzHv5ljxa9JU43JGvpFkX9N4lWtE=">
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenjdk%2Fjdk17u-dev%2Fblob%2Fmaster%2Fsrc%2Fhotspot%2Fshare%2Fgc%2Fz%2FzStat.cpp%23L641&data=05%7C01%7Cmdmitriev%40linkedin.com%7C4d110bc930284e890e6308dbb65e5ec5%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C638304288679249773%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2BKM2Bpba3lJu1LFEw7TdTV6nYyaBQV9jf%2FuweQnVYgU%3D&reserved=0</a><br>
<br>
6. <a href="https://github.com/renaissance-benchmarks/renaissance" originalsrc="https://github.com/renaissance-benchmarks/renaissance" shash="usZQrHiVW/aTn6UFY2FxN04XaPQTEbsSCihGs//ZhlGoD/e0F4M+FLbr2HQel5K6JytYNis2xp0cC5SwS/bORtBUSxx89yMQfEE/dASwpPuzIbA89iGgp+Z99BLaQDm2s/ESLrf+W8mbJNTM25bma9b7U2xYGX2pkxNxQkry81c=">
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Frenaissance-benchmarks%2Frenaissance&data=05%7C01%7Cmdmitriev%40linkedin.com%7C4d110bc930284e890e6308dbb65e5ec5%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C638304288679249773%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=JxCJHokctj2387jELulYTqmGMP2IykBym1LAJcf2Qn8%3D&reserved=0</a><br>
<br>
<br>
> 2023Äê9ÔÂ15ÈÕ 13:07£¬Misha Dmitriev <mdmitriev@linkedin.com> дµÀ£º<br>
> <br>
> Hi Leslie,<br>
> <br>
> I think it's worth letting you know, just in case: GCViewer seems to not handle ZGC logs very well at this time. I hope you can pass this information to its maintainers. I guess it's also worth notifying the ZGC group about this issue, in case you guys want
to use GCViewer at some point. I used it a lot in the past to analyze CMS and G1 logs, and I still consider it a very good tool. So it would be sad if it doesn't support more modern GCs well.<br>
> <br>
> Anyway, here is why I think so. I am attaching a short ZGC log, which was created by taking one of our real production logs and cutting it to a few hundred lines. When I grep it for pauses, I get the following:<br>
> <br>
> $ grep ") Pause" jdk17-zgc.gc.log <br>
> [2023-09-05T18:54:16.683+0000][506290.976s][info ][gc,phases ] GC(76751) Pause Mark End 0.070ms<br>
> [2023-09-05T18:54:16.765+0000][506291.058s][info ][gc,phases ] GC(76751) Pause Relocate Start 0.013ms<br>
> [2023-09-05T18:54:20.922+0000][506295.215s][info ][gc,phases ] GC(76752) Pause Mark Start 0.017ms<br>
> [2023-09-05T18:54:23.456+0000][506297.749s][info ][gc,phases ] GC(76752) Pause Mark End 0.060ms<br>
> [2023-09-05T18:54:23.566+0000][506297.859s][info ][gc,phases ] GC(76752) Pause Relocate Start 0.010ms<br>
> [2023-09-05T18:54:23.623+0000][506297.916s][info ][gc,phases ] GC(76753) Pause Mark Start 0.012ms<br>
> [2023-09-05T18:54:24.664+0000][506298.956s][info ][gc,phases ] GC(76753) Pause Mark End 0.064ms<br>
> [2023-09-05T18:54:24.721+0000][506299.013s][info ][gc,phases ] GC(76753) Pause Relocate Start 0.012ms<br>
> <br>
> There are clearly 8 pauses. However, when I feed it to GCViewer (I built it from the latest source code), it says that there are just 3 pauses. It also prints some NaNs, probably due to lack of precision. On bigger logs we observed similar discrepancies,
though the difference between pauses obtained by grepping and reported by GCViewer was not so big.<br>
> <br>
> Misha<br>
> <br>
> From: Misha Dmitriev <mdmitriev@linkedin.com><br>
> Sent: Friday, September 8, 2023 11:40 AM<br>
> To: Stefan Karlsson <stefan.karlsson@oracle.com>; zgc-dev@openjdk.org <zgc-dev@openjdk.org><br>
> Subject: Re: What gc.log lines reliably indicate STW pauses for ZGC?<br>
> Thank you very much, Stefan! Really appreciate your response.<br>
> <br>
> Misha<br>
> <br>
> From: Stefan Karlsson <stefan.karlsson@oracle.com><br>
> Sent: Thursday, September 7, 2023 11:08 PM<br>
> To: Misha Dmitriev <mdmitriev@linkedin.com>; zgc-dev@openjdk.org <zgc-dev@openjdk.org><br>
> Subject: Re: What gc.log lines reliably indicate STW pauses for ZGC?<br>
> Hi Misha,<br>
> <br>
> On 2023-09-06 21:15, Misha Dmitriev wrote:<br>
>> Hi ZGC developers,<br>
>> <br>
>> I work at LinkedIn, where we have internal tooling for end-to-end GC performance monitoring and analysis. To record GC pauses and other interesting events, we parse GC logs as they are generated, in near real time. Since JDK 11, the unified logging format
allowed us to extract STW pauses for all GCs in the same straightforward way: we look for lines such as:<br>
>> <br>
>> [2020-03-09T19:12:22.542+0000][info][gc ] GC(62189) Pause Young (Allocation Failure) 14263M->9334M(14745M) 41.359ms<br>
>> <br>
>> that is, we check every line for the following condition (we don't use pattern matching for speed):<br>
>> <br>
>> if (line.endsWith("ms") && line.contains("[gc ") && line.contains("Pause ")) {<br>
>> // Extract pause time in ms from the end of the line<br>
>> <br>
>> However, looks like ZGC, though it uses the unified logging format, has a different format for STW pause lines. From the logs that we have, I am not 100% sure I understand everything. So far looks like the candidates lines look like<br>
>> <br>
>> [2023-09-05T18:47:27.323+0000][505881.615s][info ][gc,phases ] GC(76657) Pause Mark Start 0.024ms<br>
>> <br>
>> i.e. the condition should be<br>
>> <br>
>> if (line.endsWith("ms") && line.contains("[gc,phases ") && line.contains("Pause ")) {<br>
>> // Extract pause time in ms from the end of line<br>
>> <br>
>> I wonder if this is all we need or I am missing something?<br>
> <br>
> I think you also need to search for 'info' to make sure you don't get the more detailed breakdown of the pauses.<br>
> <br>
>> <br>
>> Also, what's the meaning of lines like these:<br>
>> <br>
>> [2023-09-05T18:47:44.003+0000][505898.295s][debug ][gc,phases ] GC(76661) Pause Mark Try Complete (ZWorker#2) 0.002ms<br>
>> <br>
>> Formally they look similar to the previous line, but "debug" and "ZWorker#2" suggests that it may not be a STW pause but pausing just one thread? Please advise.<br>
> <br>
> This line prints what one of the GC worker threads was doing during the Mark End pause. The "(ZWorker#2)" indicates that this a GC worker thread. You should filter out these lines if you try to collect the GC pauses.<br>
> <br>
> FWIW, in the version you are running this line is printed on the 'debug' level. However, in the latest source code this has changed and worker logging has been moved to the 'trace' level. There we have this breakdown:<br>
> 1) 'info' logs a full pause or concurrent phase<br>
> 2) 'debug' logs a subphase of (1)<br>
> 3) 'trace' logs what individual worker threads are doing<br>
> <br>
> HTH,<br>
> StefanK<br>
> <br>
>> <br>
>> Thank you,<br>
>> <br>
>> Misha<br>
>> <br>
> <br>
> <jdk17-zgc.gc.log><br>
<br>
</div>
</span></font></div>
</div>
</body>
</html>