I've implemented a set of GC algorithms that could move objects in
the ISE Eiffel runtime back in 1991-92.
The result was well worth the effort, but it was a can of worms.
:.,$s/Eiffel/Perl/g
Everything in the Eiffel world worked great, but Eiffel has provision
to call C routines, that can then callback Eiffel routines from C.
Since GC could trigger anywhere, one had to be careful.
Some C routines specially written with Eiffel in mind were told to
use the eif_access() macro (name may be not exact) to access Eiffel
objects, without caching the results, since it could change anytime
du to a GC cycle being run.
That did not work for C routine NOT written with that in mind
(e.g. a pure libc routine), so I added the ability to eif_freeze()
objects into memory, with the guarantee that the object would no
longer move.
But then, if object don't move, they pollute your generation-scavenging
algorithms, so you need to freeze objects elsewhere, in a place where
they will NEVER move again.
If you have a decent GC that can workaround cycles, you also need to
maintain a set of active roots in your object graph. That's usually
the root object (in Eiffel, it's an architected object, built by the
runtime on entry), plus the stack (local vars), plus "old objects
referencing new ones" for generation scavening, plus "remembered"
objects (objects given by Eiffel to the C side and no longer referenced
from any Eiffel object, but which must stay alive because the C side
can use them for feature calls).
Add threading to that.
What saved me was that the compiler was re-written from scratch, and
so was the run-time. I started with a new "malloc", then the GC.
The two were tightly connected and needed to be aware of each other.
Then I tackled the CECIL (C -> Eiffel) and HECTOR (Eiffel -> C)
interfaces. Everything else followed nicely.
I don't know how much of this applies to Perl6, but now you know
as much as I do on the subject. (well, almost...)
Raphael
