This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: dynamic library cost (was RE: libtool, java woes)
- To: dewar at gnat dot com
- Subject: Re: dynamic library cost (was RE: libtool, java woes)
- From: Jonathan P. Olson <olson at mmsi dot com>
- Date: Fri, 13 Apr 2001 07:48:47 -0700
- Cc: hans_boehm at hp dot com,tromey at redhat dot com,gcc at gcc dot gnu dot org,java at gcc dot gnu dot org,jsturm at one-point dot com
Does anybody have a feel for the costs of non-conservative stack
scanning?
Seems like the compiler would have to emit a ton of debugging information
to specify the contents of each word of the stack frame at each PC
location
within the program. Wading through all this mess in a GC would likely be
more costly than just conservatively scanning the stacks.
In my experience, stacks are normally the smallest amount of memory
that's
actually scanned by a collector. Most O-O applications have an order of
magnitude
more heap memory allocated than stack memory, so the only thing a precise
stack scan would buy you is elimination of (theoretical) memory leaks.
On Friday, April 13, 2001, at 04:52 AM, dewar@gnat.com wrote:
>> Adding non-conservative stack scanning is much harder
>
>
> A nice term for non-conservative GC that has been introduced by IBM is
> "type accurate".