[HN Gopher] Understanding the heap - a beautiful mess
___________________________________________________________________
Understanding the heap - a beautiful mess
Author : jicea
Score : 46 points
Date : 2023-11-29 05:53 UTC (17 hours ago)
(HTM) web link (jackfromeast.site)
(TXT) w3m dump (jackfromeast.site)
| wavemode wrote:
| Site seems hugged to death
|
| archive:
| http://web.archive.org/web/20231129055356/https://jackfromea...
| turtledragonfly wrote:
| Not so much the author's fault, but there's a bit of confusing
| terminology around the meaning of "pool" in memory allocator
| literature in general, and this article in particular.
|
| In this article, they say:
|
| > Pools ... involve: pre-allocating ... core resources that are
| frequently used in a program, which are self-managed by the
| program ...
|
| This (IME) most often means some sort of "object pool," with
| fixed-size objects and O(1) allocation and de-allocation.
|
| And also:
|
| > a memory pool pre-allocates a large block of memory ... When
| the programmer releases the memory, it is returned to the pool
| ... and is merged with surrounding free memory blocks as much as
| possible.
|
| This clearly is _not_ referring to the object pool concept. In
| the article, the O(1) freelist approach falls under the "bins"
| nomenclature.
|
| In general, memory allocator terminology is pretty messy, varying
| between sources and implementations. Words like "arena allocator"
| and "stack allocator" seem frequently abused/blurred, made worse
| by the fact that one can nest allocators in each other -- eg: a
| stack allocator which allocates from an arena, but sometimes
| referred to one or the other interchangeably.
|
| I had a bit of a rollercoaster ride trying to make heads and
| tails of it all when I was researching these things.
___________________________________________________________________
(page generated 2023-11-29 23:01 UTC)