By: Adrian (a.delete@this.acm.org), June 30, 2022 9:43 am
Room: Moderated Discussions
Foo_ (foo.delete@this.nomail.com) on June 30, 2022 9:07 am wrote:
> Adrian (a.delete@this.acm.org) on June 30, 2022 8:31 am wrote:
> >
> > When there is a dedicated memory pool size for each possible requested size of an allocation (typically
> > the requested sizes are rounded up to a power of two, to avoid an excessive number of memory pools),
> > then the list of free memory blocks can be implemented as a stack, not as a heap, because all the
> > blocks are equivalent and any of them can be returned to an allocation request.
> >
> > In this case, it no longer matters which is the sequence in time of allocate and free requests and
> > which were the corresponding sizes, the state of the memory allocator from the point of view of the
> > memory fragmentation is the same after one year of continuous running as at the start time.
>
> You are assuming there is a steady state with an almost fixed (de)allocation rate. That is not the
> case for many workloads, where you can have spikes with many allocations and/or deallocations.
>
> So you certainly can have a long term situation ("after one year of
> continuous running") where the heap occupancy is very spread out.
>
>
I am not assuming any kind of steady state.
When all the allocation and free requests are done from stacks, each stack corresponding to a certain size class, nothing ever changes from the point of view of fragmentation.
The only thing that changes is the amount of free memory for each size class, i.e. the number of free memory blocks in each stack.
When there is not enough memory for a size class, the simplest way is to get more memory from the operating system, though it is possible to redistribute the memory blocks between the memory pools.
Such memory allocators have existed for many decades, with the advantage of no memory fragmentation for long-lived processes. However, they are neither the fastest nor the most efficient in using the available memory.
Because of that, many "malloc" implementations use other strategies, which are better suited for applications which will be executed only for a limited time before being terminated, even if there is some small risk that a part of the heap could become unusable.
> Adrian (a.delete@this.acm.org) on June 30, 2022 8:31 am wrote:
> >
> > When there is a dedicated memory pool size for each possible requested size of an allocation (typically
> > the requested sizes are rounded up to a power of two, to avoid an excessive number of memory pools),
> > then the list of free memory blocks can be implemented as a stack, not as a heap, because all the
> > blocks are equivalent and any of them can be returned to an allocation request.
> >
> > In this case, it no longer matters which is the sequence in time of allocate and free requests and
> > which were the corresponding sizes, the state of the memory allocator from the point of view of the
> > memory fragmentation is the same after one year of continuous running as at the start time.
>
> You are assuming there is a steady state with an almost fixed (de)allocation rate. That is not the
> case for many workloads, where you can have spikes with many allocations and/or deallocations.
>
> So you certainly can have a long term situation ("after one year of
> continuous running") where the heap occupancy is very spread out.
>
>
I am not assuming any kind of steady state.
When all the allocation and free requests are done from stacks, each stack corresponding to a certain size class, nothing ever changes from the point of view of fragmentation.
The only thing that changes is the amount of free memory for each size class, i.e. the number of free memory blocks in each stack.
When there is not enough memory for a size class, the simplest way is to get more memory from the operating system, though it is possible to redistribute the memory blocks between the memory pools.
Such memory allocators have existed for many decades, with the advantage of no memory fragmentation for long-lived processes. However, they are neither the fastest nor the most efficient in using the available memory.
Because of that, many "malloc" implementations use other strategies, which are better suited for applications which will be executed only for a limited time before being terminated, even if there is some small risk that a part of the heap could become unusable.
