The New MorphOS Memory System

[Piru]

I wrote a small article about the new memory system in MorphOS 2.0 and beyond. It describes the background, design goals, some of the challenges met and the actual technical implementation.

The Article

[Trev]

Nice. And now we wait for negative comments from the same naysayers that thwarted Chris's efforts. ;-)

Re: legacy MEMF_REVERSE usage, if you observed that your allocations were in the upper half of memory (either physically or with respect to memory lists), wouldn't using MEMF_REVERSE have decreased allocation time by at least a factor of two, barring fragmentation?

It also seems to me that using an allocaligned-like function would have increased fragmentation with very little benefit, particularly for alignments <= 16, by unnecessarily increasng the size of the system memory lists. I'm speaking from the perspective of someone with no real knowledge of the internals of Amiga OS memory allocation, though.

[Damion]

From a non-coder perspective, I've noticed quite an improvement using the TLSFMem available for 3.x. Usable, responsive uptime between reboots is often drastically increased. Hours of IBrowse, AmiNetRadio, WHDLoad, etc, with little (if any) detectable lag from a clean boot. Recently I managed to burn through about 15 or so demos on the A1200 before something finally crashed it, and everything ran fast/responsive while it lasted. :-P

So - The details are way over my head, but I think the concept is pretty cool. It will definitely be fun to play with MorphOS again when the MacMini version is released.

[Piru]

@Trev

Re: legacy MEMF_REVERSE usage, if you observed that your allocations were in the upper half of memory (either physically or with respect to memory lists), wouldn't using MEMF_REVERSE have decreased allocation time by at least a factor of two, barring fragmentation?

The way MEMF_REVERSE flag is implemented in the First Fit algo is actually even slower than normal allocations. It always must scan all free memory blocks to find the last matching one (since they're sorted by address). Also, with TLSF the MEMF_REVERSE flag only adds complexity to the routine without adding any performance, or reducing the fragmentation.

It also seems to me that using an allocaligned-like function would have increased fragmentation with very little benefit, particularly for alignments <= 16, by unnecessarily increasng the size of the system memory lists.

Allocaligned kind of functions are only used to get memory aligned to specific granularily. Often it's needed for DMA operations, getting memory aligned to PPC code/stack alignment requirements or MMU page size aligned memory areas. You indeed should not use them lightly as they increase fragmentation quite dramatically. Luckily with TLSF the fragmentation no longer is an issue.

[Trev]

@Piru

The way MEMF_REVERSE flag is implemented in the First Fit algo is actually even slower than normal allocations. It always must scan all free memory blocks to find the last matching one (since they're sorted by address). Also, with TLSF the MEMF_REVERSE flag only adds complexity to the routine without adding any performance, or reducing the fragmentation.

Eek. I had assumed OS3 memory lists were doubly-linked, in which case they could be traversed in the reverse direction. D'oh! So yes, MEMF_REVERSE = mostly useless.

Allocaligned kind of functions are only used to get memory aligned to specific granularily. Often it's needed for DMA operations, getting memory aligned to PPC code/stack alignment requirements or MMU page size aligned memory areas. You indeed should not use them lightly as they increase fragmentation quite dramatically. Luckily with TLSF the fragmentation no longer is an issue.

Which is why I've been allocating size+align-1, keeping track of the original pointer, and just passing around pointer&~align without reallocating....

Anyhow, I'm always glad to see Amiga-like operating systems keeping up with the state of the art, even if I don't have the hardware to run them. :-P And I'm also glad that Chris is still maintaining TLSFMem for OS3, albeit for E3B customers. Fortunately, I have a Deneb.

[Piru]

@Trev

Which is why I've been allocating size+align-1, keeping track of the original pointer, and just passing around pointer&~align without reallocating....

That's a good strategy, indeed. This way it won't break with allocation systems that don't implement AllocAbs() properly. It also is faster than AllocMem+FreeMem+AllocAbs sequence, and indeed does not add additional fragmentation. The obvious downside is holding extra "align" bytes of memory (shouldn't be a problem these days).