Re: memory managment

[Mike Griebling <grieblm@trt.allied.com>]

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

Well, you don't need to allocate a super-sized chunk all at once.  You
could start with a chunk which is the largest available piece you can
get.
 
> >  - 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?  

No, I don't remember all the details at the moment, but the ETH collector
starts out with the original block which was allocated and redivides it.
Previously allocated pieces just stay allocated.
 
> >  - 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.

The GC won't move blocks around.  The GC is also called automatically
in the NEW calls.  This could be tuned so that it happens more frequently
than just when the allocator is out of memory (ie., a timer could be
enabled to cause collection every period of time).  AFAIK the ETH
collector (the latest incarnation -- at least) checks the stack and
also checks the CPU registers.
 
> >  - don't keep entire pages occupied just for one dirty block
> 
> No, you keep a block of severak MB for a single object ;-).

Nobody's perfect. :-)
 
> >  - 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

Well, the term large needs to be defined and possibly settable by the
user.  I don't think system performance needs to be reliant on the
available memory anyway -- most multi-tasking systems also have memory
management (ie., blocks of memory not in use are swapped to disk).

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

Well, ETH's collectors have worked well for quite some time.  I also
think you are forgetting about the NEW collection invocation.  See my
comments above as well.

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

I think the latest collectors do cope with these.  At any rate, this is
a trivial addition. ;-)

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

I'm not sure about what happens in this case.  Have you ever heard of
an ETH collector crashing the system?  I haven't, so this must have been
solved or is a very rare occurrence.  Probably, once the block overflows 
they begin treating more memory requests as large memory allocations?  
More likely they start a garbage collection phase.  I'll have to read 
through the docs again.

> -- mva
> 

Michael G.