Quetion about the counter ZCounterOutOfMemory
Guoxiong Li
lgxbslgx at gmail.com
Wed Apr 3 03:26:14 UTC 2024
Hi Stefan,
Thanks for your detailed explanation. My confusion is gone now.
Best Regards,
-- Guoxiong
On Tue, Apr 2, 2024 at 6:20 PM Stefan Karlsson <stefan.karlsson at oracle.com>
wrote:
> Hi Guoxiong,
>
> On 2024-03-31 15:54, Guoxiong Li wrote:
> > Hi all,
> >
> > I notice the ZCounterOutOfMemory is only increased in the call link
> > `ZAllocatorEden::alloc_object -> ZHeap::out_of_memory`.
> > Should we increase this counter in the method
> > `ZAllocatorEden::alloc_tlab`
>
> I don't think we should. When we fail alloc_tlab, the code will continue
> and try a direct allocation with alloc_object. See:
>
> HeapWord* MemAllocator::mem_allocate_slow(Allocation& allocation) const {
> // Allocation of an oop can always invoke a safepoint.
> debug_only(allocation._thread->check_for_valid_safepoint_state());
>
> if (UseTLAB) {
> // Try refilling the TLAB and allocating the object in it.
> HeapWord* mem = mem_allocate_inside_tlab_slow(allocation);
> if (mem != nullptr) {
> return mem;
> }
> }
>
> return mem_allocate_outside_tlab(allocation);
> }
>
> > and other allocation methods such as
> > `ZAllocatorForRelocation::alloc_object`?
>
> Relocations will never fail. If we run out of memory during relocation,
> the object will be in-place compacted into its current ZPage.
>
> > And should we move the incremental code like `ZHeap::out_of_memory` to
> > the allocation methods of `ZObjectAllocator`, which is a lower level
> > class for allocation.
>
> If we should do anything here, I think it is to move the call to
> ZHeap::out_of_memory() to ZCollectedHeap::mem_allocate.
>
> Cheers,
> StefanK
>
> >
> > Any ideas are appreciated. Thanks.
> >
> > Best Regards,
> > -- Guoxiong
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20240403/f074a500/attachment-0001.htm>
More information about the hotspot-gc-dev
mailing list