Re: dynamic library cost (was RE: libtool, java woes)

[Jonathan P. Olson <olson at mmsi dot com>]

I'll check out the paper.  However it seems like the compacting collector
would need to suspend threads for long periods of time while it's 
modifying
all the memory references since all references to an object would need to
be modified atomically.  In a multi-threaded system it would be very 
costly.

On Friday, April 13, 2001, at 09:09  AM, Tom Tromey wrote:

> They did this work so that they could implement a compacting collector
> but still have the compiler generate optimized code.  So what they did
> is even more ambitious -- if an object is moved they update the stack
> and registers to reflect this.
>
> My guess is that it would be cheaper, easier, and probably not much
> worse to simply implement a mostly-copying-or-compacting collector.
> (I have no facts to back up this assertion.)
>
> Anyway, for them the question wasn't about the cost of scanning the
> stack per se.  That cost is just part of a larger cost framework.  For
> some reason they wanted to use a compacting collector and this is the
> work required to do that.
>
> Tom