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

Tom Tromey tromey@redhat.com
Fri Apr 13 08:59:00 GMT 2001

>>>>> "Jon" == Jonathan P Olson <olson@mmsi.com> writes:

Jon> Does anybody have a feel for the costs of non-conservative stack
Jon> scanning?

Read the paper "Compiler Support for Garbage Collection in a
Statically Typed Language", by Diwan, Moss, and Hudson.  My copy says
"To appear in SIGPLAN '92 PLDI".

Jon> Wading through all this mess in a GC would likely be more costly
Jon> than just conservatively scanning the stacks.

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.


More information about the Java mailing list