Re: Fix stale allocChunkLimit when recycling AllocSet

On Mon, 19 Oct 2026 at 19:04, Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> wrote:
> >> In summary, this bug doesn’t lead to memory leaks, but it breaks AllocSet’s intended allocation behavior: sometimes causing unexpected malloc()/free() calls, and sometimes unexpected pooling and memory retention.
> > Per the comment you moved to the helper function, if allocChunkLimit
> > doesn't follow the ALLOC_CHUNK_FRACTION formula, it could also lead to
> > unexpected size of memory waste at a block's tail.
>
> Yes, that’s another consequence of stale larger allocChunkLimit.

I don't think this is 100% accurate, as when a non-large allocation is
made and there's not enough remaining space in the block, the
remaining space is divvied up and put onto the freelists. That might
happen to get wasted of those freelist items are never used, but to
say the entire remaining space is wasted isn't strictly true.

I did consider if this was worth a backpatch and I think it is, as
having the performance characteristics depend on the random chance of
what context was last pushed onto the freelist doesn't seem great.

I've backpatched this to v14. I kept the comments prior to the
allocChunkLimit being set the same as they had been in each version.
Annoyingly, that block had changed various times since v14.

I took the liberty and added an Assert(set->nextBlockSize ==
set->initBlockSize); to clarify that we expect that to have been done
the last time the context was reset.

David