Re: memory managment

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

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

Not at the moment.  The documents are at another location.  I'll let
you know tomorrow.
 
> 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 all
> ocated.
> 
> 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.

Memory merging is not necessary with the ETH approach.  Basically they
start every marking phase by treating the memory as a single block again
and then carve out only those pieces which are still allocated.  The
remaining blocks then become "large" blocks which can be allocated or
reduced in size as needed.

You're right fragmentation is not really addressed here -- just memory
merging is not required so garbage collection is faster than if memory
merging were needed.  However, ETH's approach reduces fragmentation
because the smaller blocks don't leave large gaps of unused memory
between them because they are allocated to fit fairly closely to the
required memory.
 
> > 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? 

I don't understand what you mean by conservatively.  From my code
perusal it looks like they check that the address in a register or
on the stack is within the range of the allocated memory and then
do some more tests (which I don't understand yet) and finally if
the address passes these tests the block gets marked as still being
used.  This seems pretty agressive to me -- but I dunno.

> -- mva

Michael G.