[M3devel] WeakRef mechanism...
Dragiša Durić
dragisha at m3w.org
Sat Mar 15 10:29:39 CET 2008
On Fri, 2008-03-14 at 11:08 -0400, Tony Hosking wrote:
> On Mar 14, 2008, at 2:45 AM, Dragiša Durić wrote:
>
> > My understanding of conservativeness of GC with regard to register and
> > stack content was something else... I was thinking it's like this:
> > ProcessStacks will process registers and stacks; each time
> > address-sized, correctly-aligned bit pattern which looks like
> > address of
> > some object GC knows occurs, GC accepts it as it's address - it
> > maybe is
> > not, but conservative thinking will not make risks there. This way,
> > ProcessStacks will know exactly what objects are (maybe, but no
> > risks...) referenced from stack.
>
> The problem can arise that the compiler optimizes the code so that you
> get a pointer from the stack that may refer one word past the object
> it refers to (e.g., for looping through array elements). I'm not sure
> if it actually occurs, but it might.
I understand this, and also point from your GC paper about fields as VAR
args... Address in regs/stack can be one inside our object, not only
object's address. But, this still means we can know which object is
pointed by ambiguous root. It's not only ambiguous root heap page
identification (as is now), there are some address compares. IIRC, in
your paper you stated ambiguously referenced pages are only a couple per
round of GC, so it probably will not be performance hit at all, and
we'll get nearly perfect WeakRef situation.
dd
--
Dragiša Durić <dragisha at m3w.org>
More information about the M3devel
mailing list