Design idea behind AllocMem()?

[Steam Ranger]

Plain and simple, why did the devs implement AllocMem()?

AllocVec() was implemented with 2.0, and it has the same capability as AllocMem(), while being easier to use for the assembly programmer and being more similar to the C standard library functions. Seen as AllocVec() was implemented so quickly, I have to wonder, why did the devs bother with AllocMem() in the first place?

[alkis]

Probably because "metadata" is waste of memory. A1000 came with 256K ram. Also UNIX had a free with size up until 1979.

https://stackoverflow.com/questions/...22002#24222002

[Samurai_Crow]

AllocMem() was designed around the specific constraints of Exec.library and was never intended to be the memory allocator for the whole system. I remember this because when the AmigaOS4 dev team announced the new slab allocator, the original author was there at the DevCon (Carl Sassenrath?) and announced this publicly.

AllocVec() was just a linked-list wrapper around AllocMem(). Without AllocMem(), AllocVec() wouldn't work.

Sidenotes:
AllocVec() allocations place a pointer in the header of the allocated memory, making it waste chip RAM and slowing deallocation operations if that's where they are located.

I'd prefer using a custom allocator wrapping AllocMem() rather than AllocVec() for most applications anyway. Possibly a slab allocator that honors cache row alignment instead, for example. That way the context header (allocated in MEMF_ANY RAM) would be an array of pointers per slab, reducing the overhead of the allocation and deallocation since there would be one list node per slab of allocations rather than a list node per individual allocation.

[Thorham]

Originally Posted by alkis

Probably because "metadata" is waste of memory.

Except that you still have to store the size anyway or you can't free allocated memory.

[Docent]

Exec memory management works on a list of free memory chunks and do not maintain information about allocated memory. In such design freeing allocated memory and adding it to free memory list requires specifying both the pointer to allocated memory and its size.

In 1984 when memory management was implemented, there was only 256kb of ram available, so system could not afford to store information on allocated size as it would cause 4 bytes overhead per allocation. AllocVec appeared in 1990, when all amigas shipped with minimum 512kb of ram, so additional 4 bytes wasnt such an issue.

[Minuous]

It's often the case that there are many allocations made of the same size, eg. when working with lists. Storing the size in each allocation is unnecessary and wasteful in such situations.

[Docent]

Originally Posted by Samurai_Crow

AllocMem() was designed around the specific constraints of Exec.library and was never intended to be the memory allocator for the whole system. I remember this because when the AmigaOS4 dev team announced the new slab allocator, the original author was there at the DevCon (Carl Sassenrath?) and announced this publicly.

Exec memory management was designed around machine constraints, not exec itself. I never heard about other memory allocators in exec planned for original system. The fact is, AllocMem was often misused as a general memory allocator in an application and it caused significant memory fragmentation, especially when allocating/freeing a lot of small chunks of memory (KS 3.0 introduced pool management to help solve this problem)
The indended use of exec memory management in a task was to allocate some memory from the system via AllocMem and then maintain other allocations from already allocated block with Allocate/Deallocate calls.

Originally Posted by Samurai_Crow

AllocVec() was just a linked-list wrapper around AllocMem(). Without AllocMem(), AllocVec() wouldn't work.

This is not true. AllocVec/FreeVec is not a linked-list wrapper - it is just a small wrapper that works on top of AllocMem/FreeMem. It basically allocates requested memory block size+4 from AllocMem and stores the size at the beginning of allocated block. FreeVec takes stored allocated block size from provided memory pointer and calls FreeMem.

Originally Posted by Samurai_Crow

AllocVec() allocations place a pointer in the header of the allocated memory, making it waste chip RAM and slowing deallocation operations if that's where they are located.

It is not a pointer but the size of allocated block.

[Samurai_Crow]

Originally Posted by Docent

Exec memory management was designed around machine constraints, not exec itself. I never heard about other memory allocators in exec planned for original system. The fact is, AllocMem was often misused as a general memory allocator in an application and it caused significant memory fragmentation, especially when allocating/freeing a lot of small chunks of memory (KS 3.0 introduced pool management to help solve this problem)

Slab allocation just takes memory pools to the next level by grouping same-size allocations together, where each size uses a different pool. On AmigaOS 4, the PPC processors all have an MMU so the puddle size is generally the page size of the MMU and allocates a page at a time using a second-stage allocator. (At least that's how I would have done it.)

[mschulz]

Originally Posted by Thorham

Except that you still have to store the size anyway or you can't free allocated memory.

Of course you can. Exec does not maintain a list of allocated blocks. Instead it maintains single linked list of free blocks. In this design, as Docent wrote, you need to know address and size of block to be freed as it must be relinked to free mem chunk list and eventually merged.

BTW. As a side effect of such memory management by exec it is perfectly possible to free only an arbitrary portion of memory allocated as a single block previously. This works well as long as one correctly frees the remaining parts afterwards.

[SpeedGeek]

Originally Posted by Docent

Exec memory management was designed around machine constraints, not exec itself. I never heard about other memory allocators in exec planned for original system. The fact is, AllocMem was often misused as a general memory allocator in an application and it caused significant memory fragmentation, especially when allocating/freeing a lot of small chunks of memory (KS 3.0 introduced pool management to help solve this problem)
The indended use of exec memory management in a task was to allocate some memory from the system via AllocMem and then maintain other allocations from already allocated block with Allocate/Deallocate calls.

This is not true. AllocVec/FreeVec is not a linked-list wrapper - it is just a small wrapper that works on top of AllocMem/FreeMem. It basically allocates requested memory block size+4 from AllocMem and stores the size at the beginning of allocated block. FreeVec takes stored allocated block size from provided memory pointer and calls FreeMem.

It is not a pointer but the size of allocated block.

The fragmentation problem is not caused by Allocmem, rather it is caused by the misuse of Allocmem. The SAS C linker was rather notorious at creating programs with a large number of hunks. AllocVec does not prevent the memory fragmentation problem, it's just a more convenient way to allocate and release memory which only the user program can do safely. Amiga OS was just intended to keep track of the available free memory in a multitasking environment with the so called "Well Behaved" user programs allocating and/or releasing memory as needed.

[Docent]

Originally Posted by SpeedGeek

The fragmentation problem is not caused by Allocmem, rather it is caused by the misuse of Allocmem.

You quoted my earlier answer with your message, but I did not write that AllocMem caused memory fragmentation

Originally Posted by SpeedGeek

AllocVec does not prevent the memory fragmentation problem,

and I did not write that AllocVec prevents memory fragmentation either.

[paraj]

It has already been said, but I think it's worth spelling out: AllocMem/FreeMem is strictly more "powerful" than AllocVec/FreeVec. You can implement AllocVec on your own (or anything else you might like) in terms of AllocMem, but not the other way round.

AllocMem is the obvious, minimal thing you would implement in a small kernel at this point in time. The developers were likely imagining you would either be using a higher level language to handle allocations or write your own wrapper if you were using assembly and wanted convenience rather than lower memory usage.

You could ask similar questions for why CreateIORequest was not initially available in exec for example.

[Thomas Richter]

Originally Posted by Steam Ranger

Seen as AllocVec() was implemented so quickly, I have to wonder, why did the devs bother with AllocMem() in the first place?

That we have both AllocVec() and AllocMem() is more a historical accident. AllocMem() was intended more in the directio of brk() under *ix operating systems which allocates a large chunk of memory for a process which then splits it up into pieces itself. Then Tripos came and brought its own memory allocation functions, getvec() namely, eachable through the GlobVec of BCPL. This was quickly bolted on top of AllocMem() though works otherwise according to the semantics of AllocVec() already. Kick 36 moved then the BCPL/Tripos function getvec() into AllocVec() of the exec.library, keeping the semantics of the function.


Memory pool functions closer to what was originally indented also became available in v36 as AllocPooled()/FreePooled() to allow processes to manage memory more efficiently.


Concerning memory management, the situation is already quite messy. Processes can keep lists of allocated memory that is automatically released when they go down, though this feature is rarely used. This is AllocEntry() and the process memory list.



Then we have the AllocRemember() functions of intuition which work around the limitations of exec, though without really adding pools, just tagging memory, and then at the level of the icon.library we have a third memory adminsitration function.


In v45 and v47, layers and graphics became smarter to pool their cliprects and regions in lists such that not every allocation needs to go down to exec, helping to reduce the fragmentation problem a bit.



For today's requirements, I would just leave AllocEntry() and the intuition and icon functions alone, and programs could/should use the AllocPooled() functions of exec.


Most C compilers implement memory pools by their own, and implement malloc() through their own memory pools. So malloc() does not sit directly on top of AllocMem(), but through another layer in the C standard library. Unfortunately, that layer is typically different from AllocPooled() to be able to implement realloc.

[Thomas Richter]

Originally Posted by SpeedGeek

The SAS C linker was rather notorious at creating programs with a large number of hunks.

Actually, make this the Lattic BLink linker or even more concretely the default settings of the Lattice C compiler. This problem was long gone when SAS bought the Lattice compiler. Early Lattic versions placed each stub function from amiga.lib and each program unit into its own hunk, but those times were long gone already with later versions of Lattice C.

[Thomas Richter]

Originally Posted by mschulz

BTW. As a side effect of such memory management by exec it is perfectly possible to free only an arbitrary portion of memory allocated as a single block previously. This works well as long as one correctly frees the remaining parts afterwards.

That's perfectly illegal. The reason being that this requires knowledge of the internal rounding algorithms of exec, and it also causes headaches of all kinds of debugging tools. In short. "DON'T".


Some versions of the layers.library did this, causing a lot of issues in mungwall that caused debugging headaches even in 3.1.4. Layers was already fixed to avoid this in v40, but mungwall still had a workaround in it.


You find interface requirements for AllocMem() and FreeMem() in the documentation of PoolMem (on Aminet) for example. Most of what is said there is pretty obvious, and one of the important points is "don't break up one AllocMem() into multiple FreeMem()s", this is really asking for trouble and is creating forward compatiblity issues.


Just to give you one idea: Typically, you would like to allocate memory aligned to at least cache line boundaries, which requires a change of the exec memory alignment policy. With such changes, any hacks that splits up one allocation into multiple releases are going to break.

[paraj]

Originally Posted by Thomas Richter

That's perfectly illegal. The reason being that this requires knowledge of the internal rounding algorithms of exec, and it also causes headaches of all kinds of debugging tools. In short. "DON'T".


Some versions of the layers.library did this, causing a lot of issues in mungwall that caused debugging headaches even in 3.1.4. Layers was already fixed to avoid this in v40, but mungwall still had a workaround in it.


You find interface requirements for AllocMem() and FreeMem() in the documentation of PoolMem (on Aminet) for example. Most of what is said there is pretty obvious, and one of the important points is "don't break up one AllocMem() into multiple FreeMem()s", this is really asking for trouble and is creating forward compatiblity issues.


Just to give you one idea: Typically, you would like to allocate memory aligned to at least cache line boundaries, which requires a change of the exec memory alignment policy. With such changes, any hacks that splits up one allocation into multiple releases are going to break.

While I agree that it's probably not a good idea, the documentation for FreeMem just says that "freeing partial blocks back into the system pool is unwise" not "illegal" - I know how to read between the lines, but they should have used stronger language instead of being clever. Yes, it also says it will round it to "a multiple of the system memory chunk size", but that chunk size being 8 is effectively set in stone by "Hyrum's Law" of interfaces.


IOW you shouldn't (for your own sake) FreeMem in the middle of a block depending on the 8-byte chunk size, but on the other hand it will work, and have to keep working in 3.x.

[SpeedGeek]

Originally Posted by Docent

You quoted my earlier answer with your message, but I did not write that AllocMem caused memory fragmentation and I did not write that AllocVec prevents memory fragmentation either.

You wrote:

"The fact is, AllocMem was often misused as a general memory allocator in an application and it caused significant memory fragmentation..."

Because of the way you wrote this, it could be interpreted as Allocmem causing the memory fragmentation. But thanks for clarifying that you did not intend it to be interpreted that way.

Originally Posted by Thomas Richter

Actually, make this the Lattic BLink linker or even more concretely the default settings of the Lattice C compiler. This problem was long gone when SAS bought the Lattice compiler. Early Lattic versions placed each stub function from amiga.lib and each program unit into its own hunk, but those times were long gone already with later versions of Lattice C.

RSCP v1.10 was compiled and linked with SAS C 5.x and it had approx. 10 hunks. The more recently updated versions were compiled and linked with SAS C 6.58 and they have 3 hunks. I order to get the 3 hunks I used the SMALLCODE and SMALLDATA options. They are not the default options for the Slink linker and AFAIK the old Blink linker did not offer these options.

As far as the old Lattice C compiler and linker, I don't know exactly how it compares to SAS C 5.x but I doubt it could do any better.