[gclist] Compiler tables for accurate gc

[David Chase]

At 02:02 PM 12/17/97 -0800, Hans Boehm wrote:
>This gives you fast allocation of short-lived objects for pure Java apps, which
>would presumably always run in mode 1.  Any app that makes frequent native
>calls would run in mode 2, thus getting the same performance and reliability
>that you get with existing conservative implementations (except that it's not
>hard to do better than many of them).
>
>This also makes it much easier to debug the type information generated by the
>runtime.  You can run in mode 2, and turn it off selectively until things start
>working.

Speaking from recent experience, I think that the debugging works
better with an exact, simple copying-compacting collector, especially
if you unmap the oldspace each time you finish with it (even better
if the OS gives you a different address each time you ask for a
new newspace, which is what NT appears to do unless you request
otherwise).  In such a system, bugs have a very hard time escaping
notice.  The reason this is good is that a compiler (especially a new
compiler, like you might try to use with accurate GC) continues to be
"improved" after it first "works", and sometimes those improvements
are just a wee bit buggy.  The unmap-old-pointers game works very
well; miss a pointer, and you don't get far after GC.  Accurate GC
also has the property that you can point to a list of pointers that
is supposed to be the actual root set, and you can easily see if a
given pointer is in that root set.

As for use of native code, one way to deal with different vendors
disagreeing on native interfaces is to write an optimizing bytecode
compiler, and avoid native code except when absolutely necessary.

David Chase
chase@world.std.com