Re: memory managment

[Frank Copeland <fjc@wossname.apana.org.au>]

Michael van Acken wrote:

> >  From: Mike Griebling <grieblm@trt.allied.com>
> >
> >  [stuff about carving up a single large chunk of memory deleted...]
> >
> >  Advantages
> >  - reasonably good use of memory for small objects
> >  - a single call to the OS memory allocation functions
>
> To allocate several MB of memory.  I don't think this is an option for
> Frank's Oberon-A, although it is an execellent choice for systems
> where every process has it's own address space that starts up with a
> fragmentation of zero.

The option I'm looking at now is to steal^H^H^Hadapt the allocator in the
ETH Oberon System for the Amiga, which requests memory from the OS in 64K
chunks and divides them up. The problem with that is that the minimum
memory requirement for a process becomes 64K, which *will* be considered
excessive by many people. I may have to allow the option of using the
existing, simple allocator for programs with modest memory needs.

> >  - fragmentation is not a concern since garbage collection will
> >    automatically compact memory and reslice it.
>
> Are you talking about a copying garbage collector that moves blocks
> around during garbage collection?

The ETH collectors certainly aren't copying collectors. Maybe Michael G is
referring to the way that the ETH collector rebuilds the free list during
the sweep phase.

> >  - can use the ETH standard garbage collection algorithms
>
> The ETH stuff is very nice.  But it has the drawback that it forces
> the user to call the garbage collector himself.  And the GC has to be
> called at places where the stack doesn't hold relevant pointers (or
> any pointers or intermediate addresses at all if blocks of memory are
> moved around by the gc).  The Oberon System hides this call in its
> command loop and silently hopes that a single command won't overflow
> the heap.  This is not an option for a traditional style program.

Its true the ETH collector has to be explicitly called, but its no longer
true that it cannot trace pointers on the stack. Tracing the stack is
expensive compared to tracing global pointers, but it is also optional. At
present the Oberon-A collector doesn't trace the stack, but that will be
attended to.

> >  - don't keep entire pages occupied just for one dirty block
>
> No, you keep a block of severak MB for a single object ;-).

And people wonder why Unix programs tend to be memory hogs when ported :-).

> >  Disadvantages
> >  - still some overhead although not as much as with the original "worst
> >    case" allocator
>
> Some other disadv of the ETH collectors (please correct me if I'm
> wrong, my experience with the System dates some years back):
> - assumes that allocating large quantities of (possibly unused) memory
>   have no negative effect on the system performance; for a
>   multi-tasking system this can be a problem

This is a problem with the current V4 for Windows, which tries to reserve
as much as 4M for its own heap. The V4 for Amiga used to require at least
2M I believe, but now is much better.

> - delegates responsibility of GC activation to the user (ie,
>   programmer); you know that users can't be trusted, don't you? ;-)

I don't think this is all that much of a problem. Small utilities often
don't call the GC at all, and larger applications can have the calls safely
hidden away in the main event loop, which should be encapsulated in some
kind of framework class anyway.

> - can't cope with pointers on stack or in registers

No longer a problem.

> - break if more memory is allocated than anticipated, i.e. if the huge
>   block simply overflows

Not a problem if it is designed to allocate smaller blocks as required.

Frank