[gclist] Fast-allocating non-copying GC's
Robert A Duff
bobduff@world.std.com
Mon, 18 Mar 1996 20:11:47 -0500
> Our collector also support precise scanning of objects on the heap,
> WITHOUT modifying the compiler. We have a tool that extracts debug
> output from object files and uses it to construct type descriptor records.
Possibly a good plan, but beware Ada features that don't quite fit the
standard debugging formats. Check with ACT as to how these are handled.
Gdb has been modified to handle Ada programs OK, sort of, but it doesn't
fully understand Ada yet.
By the way, such a tool seems more generally useful: I'd like to have a
handy subroutine that walks all the components of an object, calling a
client-specified operation at each point. Does that make sense?
(Of course, some languages can do that as a matter of course.)
> (You can then recompile the program without the debugging option, so
> there's no runtime space or time hit for having debug output in your
> executable. This is easily automated in the makefile.)
Or strip it. Gcc-based compilers (including GNAT) do not alter
executable code when you turn on debugging, they just generate extra
tables of info.
> Remember that you have many hundreds or thousands of pages of main
> memory on a reasonable computer.
But the same effects at the cache level are probably more important for
most programs. (Most of my programs *never* page. Or hardly ever. And
if/when they do, they're thrashing, so something needs to be fixed. But
I'm sure they reload cache lines quite a bit.)
- Bob