ZGC Allocation stall metrics via MXBean

[Sundara Mohan M]

Thanks Per, for the nice explanation.

I would prefer to have just the AllocationStall count in
c.s.m.GarbageCollectorMXBean or c.s.m.ZGarbageCollectorMXBean and stall
time related metrics in c.s.m.ThreadMXBean (assuming this will have metrics
for each thread).
Also i would choose c.s.m.ZGarbageCollectorMXBean so that we don't have to
deal with backward compatibility issues(like people using other GC and
seeing ZGC metrics or the other way) later. Again assuming java development
is moving toward that with multiple feature releases in a year model.

That's just my two cents.

Thanks
Sundar

On Thu, Oct 24, 2019 at 12:46 AM Per Liden <per.liden at oracle.com> wrote:

> Hi,
>
> When allocating a small object (object size <= 256K), if the thread
> already has a TLAB it will continue to allocate from it without being
> stalled. If the TLAB is exhausted, the thread will try to allocate a new
> TLAB from a CPU-local ZPage (this can be seen as a "CPU-LAB" for
> allocating TLABS), again without being stalled. Only if that CPU-local
> ZPage is also exhausted will the thread try to allocate a new ZPage, in
> which case it will be stalled if we're currently out of memory.
>
> The allocation path is slightly different when allocating medium objects
> (object size <= 4M). In this cases, the first attempt is to allocate the
> object into a global/shared medium ZPage. If that page is exhausted, it
> will try to allocate a new medium ZPage, and is subject to allocation
> stall if we're out of memory.
>
> For large objects (object size > 4M), we always allocate a new large
> ZPage, so we'll have an allocation stall if we're out of memory.
>
> In summary, if we're out of memory, a thread might still be able to
> allocate obejcts without being stalled. If circumstances are right.
>
> Exposing allocation stall information via an MXBean might be useful. We
> certainly have the information, so it's mostly a question about if and
> how we want to expose it. Just thinking out loud, one could imagine
> adding something to c.s.m.GarbageCollectorMXBean or c.s.m.ThreadMXBean,
> or maybe even introduce a c.s.m.ZGarbageCollectorMXBean.
>
> cheers,
> Per
>
> On 10/24/19 6:08 AM, Connaughton, Niall wrote:
> > I was going to ask the same question.
> >
> > In addition - is there any documentation on how the allocation stalls
> work? I'm looking to understand things like whether the stall happens to
> any thread that attempts to allocate a new object, or only threads that
> need a new TLAB, or some other mechanism. Put another way - if we do
> something like jHiccup and have a thread constantly sleeping and allocating
> a small amount, would it detect allocation stalls? Or would it not be
> stalled until it exhausts its TLAB?
> >
> > Thanks,
> > Niall
> >
> > On 10/22/19, 11:19, "zgc-dev on behalf of Sundara Mohan M" <
> zgc-dev-bounces at openjdk.java.net on behalf of m.sundar85 at gmail.com> wrote:
> >
> >      Hi,
> >          I was trying to get GC metrics via GarbageCollectorMXBean but
> only see
> >      CollectionCount and CollectionTime.
> >      Even though i can get the Allocation Stall event from gc log i have
> to do
> >      some special setup to get that collected and reported properly.
> >      Since ZGC allocation stall is important event to identify if the
> >      application is having issue, can we expose it via any other MXBean?
> >
> >      Thanks
> >      Sundar
> >
> >
>