> DS> At 12:29 AM 9/21/2001 +0200, Bart Lateur wrote:
>
> >> >Horribly wasteful of memory, definitely, and the final allocation system
> >> >will do things better, but this is OK to start.
> >>
> >> So to stop it waste memory, subtract 1 first and add it again later.
>
> DS> Nah, it'll still waste memory. It can't not, because of the way it
> DS> works. It has to ask for a big gob of memory and ignore bits to
> DS> make sure it gets the alignment right. This particular
> DS> implementation's not all that efficient I'm sure, but it'll get
> DS> ripped out and replaced when we have a real memory management
> DS> system.
>
> what about a binary type allocation system?
>
> we have multiple allocation structures in an array with each one
> allocating the next size up binary size. so the lowest level does say 32
> bytes (or whatever our smallest granularity is). the highest level could
> be in the multi-megabytes or larger. when a size is requested it go to
> that size queue and if there is a free block on its list, it gets it. if
> no block exists, it requests from a larger size and will break it
> down. now, if you allocate with malloc and it is not on the proper,
> boundary the preceding ram is broekn into smaller parts and put onthose
> queues. so no (or little) ram is wasted. all blocks are allocated on
> proper boundaries and you can do binary coallescing during (incremental)
> GC.
>
> a first request of a small block may allocate 32 (or some other 2**N) of
> them in a large chunk. that large blocks are managed by just slice off
> the leading chunk and moving a pointer so that is very fast. when the
> block is gone and the queue is empty, a new larger block is allocated.
>
> once the queues get populated some, it will be very fast.
>
> lemme try to whip out something like this soon and see what happens. or
> does anyone else want to hack it with or without me?
>
> uri
Why aren't we just using the perl5 memory manager? Cut-and-paste right?
It used 2k page alignments for the most part. That should account for
most of our alignment needs. Actually I think it put the size as the
first several bytes. But this could be rectified by "spilling into the
predecessor". Namely All allocations start at 2K but spill back 4 or so
bytes. This means that free chains have to be <=4 above the grain. If
you use pow2 based allocation instead of physical size-of-data, then you
can assume that it's 2^idx-4 when allocating. It's more wasteful of
memory, but with things like 2k-4B pages and clustered sub 2K allocations,
it's very efficient.
Until we get to that point, our current hack of a memory allocator is fine
for any applications we're capable of writing with this boot-strap API.
-Michael
