Re: memory managment

[acken@informatik.uni-kl.de]

I accept your word that the Oberon collectors got much smarter in the
last few years.  The latest ETH publication I read regarding this
topic described how arrays can be handled by the gc.  I guess there
are more up to date documents from ETH out there.  Can anyone give me
pointers to these texts?

Michael G. wrote:
> > >  - 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.

I don't understand how this solves the problem of fragmentation.  Any
deallocator worth this name merges memory segments, but this is only a
mechanism to reduce it.  Fragmentation is still a concern.

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

Calling the GC inside a NEW implies that stack and registers are
checked, otherwise vital root pointers might be ignored and alive
blocks are discarded.  This suggests that these gcs scan stack and
registers conservatively.  Can you assert this?  Do they switch to
precise collection as soon as roots to alive heap objects are
identified? 

-- mva