Re: memory managment

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

Mike Griebling wrote:

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

The documentation I'm using is the source code ;-). Actually, the issue of
collecting POINTER TO ARRAY OF POINTER types seems to be a peculiar blind
spot for ETH. I solved the problem in Oberon-A by creating an anonymous
type descriptor for a RECORD type with a single pointer field and using
that. Perhaps my solution is bogus, and no-one has found the deadly bug in
it yet...

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

The ETH collector most certainly *isn't* conservative, if I understand the
term correctly. It assumes everything that isn't marked is garbage, which
makes it a precise collector. This applies even to pointers on the stack
and in registers, because it will scan the allocated blocks if necessary to
determine if a pointer is valid.

Frank