This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: dynamic library cost (was RE: libtool, java woes)
- To: "Jonathan P. Olson" <olson at mmsi dot com>
- Subject: Re: dynamic library cost (was RE: libtool, java woes)
- From: Tom Tromey <tromey at redhat dot com>
- Date: 13 Apr 2001 10:09:38 -0600
- Cc: dewar at gnat dot com, hans_boehm at hp dot com, gcc at gcc dot gnu dot org, java at gcc dot gnu dot org, jsturm at one-point dot com
- References: <200104131451.f3DEpoV06885@mail.redhat.com>
- Reply-To: tromey at redhat dot com
>>>>> "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.
Tom