Re: memory managment

[acken@informatik.uni-kl.de]

>  Date: Tue, 12 Mar 96 14:46:22 EST
>  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.  

>  - 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?  

>  - 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.

>  - don't keep entire pages occupied just for one dirty block

No, you keep a block of severak MB for a single object ;-).

>  - same algorithm can be used with larger objects (as ETH currently does)

This makes things definitely easier.

>  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
- delegates responsibility of GC activation to the user (ie,
  programmer); you know that users can't be trusted, don't you? ;-)
- can't cope with pointers on stack or in registers
- break if more memory is allocated than anticipated, i.e. if the huge
  block simply overflows

-- mva