12 July 2024, 03:07 | #1 |
Registered User
Join Date: May 2022
Location: Adelaide, South Australia, Australia
Posts: 209
|
Design idea behind AllocMem()?
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? |
12 July 2024, 04:18 | #2 |
Registered User
Join Date: Dec 2010
Location: Athens/Greece
Age: 53
Posts: 730
|
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 |
12 July 2024, 04:20 | #3 |
Total Chaos forever!
Join Date: Aug 2007
Location: Waterville, MN, USA
Age: 49
Posts: 2,224
|
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. |
12 July 2024, 04:27 | #4 |
Computer Nerd
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 48
Posts: 3,948
|
|
12 July 2024, 05:35 | #5 |
Registered User
Join Date: Mar 2019
Location: Poland
Posts: 67
|
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. |
12 July 2024, 05:41 | #6 |
Coder/webmaster/gamer
Join Date: Oct 2001
Location: Canberra/Australia
Posts: 2,711
|
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.
|
12 July 2024, 06:14 | #7 | ||
Registered User
Join Date: Mar 2019
Location: Poland
Posts: 67
|
Quote:
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. Quote:
It is not a pointer but the size of allocated block. |
||
12 July 2024, 07:14 | #8 | |
Total Chaos forever!
Join Date: Aug 2007
Location: Waterville, MN, USA
Age: 49
Posts: 2,224
|
Quote:
|
|
12 July 2024, 13:25 | #9 | |
Registered User
Join Date: Nov 2018
Location: Germany
Posts: 120
|
Quote:
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. |
|
12 July 2024, 16:27 | #10 | |
Moderator
Join Date: Dec 2010
Location: Wisconsin USA
Age: 61
Posts: 850
|
Quote:
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. Last edited by SpeedGeek; 12 July 2024 at 22:42. |
|
12 July 2024, 17:29 | #11 | |
Registered User
Join Date: Mar 2019
Location: Poland
Posts: 67
|
Quote:
|
|
12 July 2024, 18:58 | #12 |
Registered User
Join Date: Feb 2017
Location: Denmark
Posts: 1,300
|
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. |
12 July 2024, 19:06 | #13 | |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,489
|
Quote:
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. |
|
12 July 2024, 19:09 | #14 | |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,489
|
Quote:
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. Last edited by SpeedGeek; 12 July 2024 at 22:45. |
|
12 July 2024, 19:15 | #15 | |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,489
|
Quote:
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. |
|
12 July 2024, 19:37 | #16 | |
Registered User
Join Date: Feb 2017
Location: Denmark
Posts: 1,300
|
Quote:
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. |
|
13 July 2024, 17:23 | #17 | ||
Moderator
Join Date: Dec 2010
Location: Wisconsin USA
Age: 61
Posts: 850
|
Quote:
"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. Quote:
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. |
||
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Is it possible to reduce an AllocMem() chunk? | 8bitbubsy | Coders. Asm / Hardware | 34 | 12 October 2023 19:51 |
Accelerator board + Zorro II: good idea bad idea ? | Clad | support.Hardware | 4 | 15 July 2023 15:00 |
Idea for the vampire owners - just an idea | Syntrax | support.Hardware | 18 | 19 January 2019 13:08 |
How not to design a console... | tonyyeb | Retrogaming General Discussion | 26 | 26 August 2009 02:48 |
New PPC design | Brass | support.Hardware | 9 | 19 December 2007 14:50 |
|
|