Any plans to emit Thread Stall events through MXBeans?

Tue Apr 22 08:49:17 UTC 2025

 Hi,
As commented here Allocation Stalls is a MUST to proper monitor ZGC performance, because in practice is usually the main contributor to latency spikes.

In our case we are monitoring JVM memory and Gen ZGC collections via MBeans, and I would say that is still quite common (e.g. Spring actuator).
JFR events will provide the info, BUT at least has small performance penalty compared with MBeans. In my view having the info via JMX could be a nice addition. Probably having something like number of allocation stalls and the accumulated time for all of them could be a great addition in my view.

Thanks a lot for all the good work with ZGC.
Regards,
Evaristo
    En martes, 22 de abril de 2025, 08:59:42 CEST, Stefan Karlsson <stefan.karlsson at oracle.com> escribió:  

  Hi Misha,

 On 2025-04-21 23:49, Misha Dmitriev wrote:

 #yiv1653332920 P {margin-top:0;margin-bottom:0;}  Hi ZGC team,  
   Are there any plans at this time to enable emission of Thread Stall events through MXBeans? We all know that ZGC stop-the-world GC pauses are normally very short. But we've noticed that for real apps at LinkedIn, thread stalls can sometimes be really long (up to a few sec), and apparently, they may affect latencies very noticeably at times. Thus, any system that monitors ZGC performance needs to track both types of GC events. We currently achieve that in some of our monitoring systems through gc.log parsing in real time, but MXBeans may have some advantages in some situations. 

 Just to be sure we are on the same page, when you are saying Thread Stall events are you referring to what we call Allocation Stalls, where Java threads are waiting for the GC to reclaim memory? Or are referring to all kinds of stall that could block the threads?

 We don't have any plans to add more MXBeans to  ZGC, but maybe we should? Nowadays we tend to send events through JFR instead, and I don't see much new development of features with MXBeans in the JVM. I'll bring question up with the Serviceability team.

 If JFR would work for you, we do have the ZAllocationStall event that gets sent every time we hit an allocation stall. Maybe this together with the newish JFR streaming API would be enough to monitor these stalls? See: https://openjdk.org/jeps/349

 Cheers,
 StefanK

   The same question is valid for Shenandoah as well.  
   Thanks,  
   Misha

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/zgc-dev/attachments/20250422/877ed92a/attachment.htm>