Re: robustness vs. conservative GC

[Jeff Sturm <jsturm at one-point dot com>]

On Fri, 10 Aug 2001, Tom Lord wrote:
> You push in here and it pops out there.  This design would seem to to
> raise the probability of incorrectly failing to collect some genuinely
> dead objects, which is an unpredictable and uncontrollable source of
> arbitrarilly catastrophic failure, sufficiently improbable to escape
> most testing, and sufficiently serious that it ought not be ignored or
> swept under the rug with vague (and inaccurate) replies such as "the
> resulting leaks only waste a little memory" (a specific reply I do not
> attribute to Hans).

Supposing you do have exact type information for the stack, how can GC 
be certain a stack slot is initialized?

You can initialize each stack frame on function entry, but it incurs some 
cost.  Anyway, early intialization helps conservative GC too.

> 
> 	I know of no cases in which a compiler generates unsafe code
> 	with this model and optimization disabled.
> 
> Fine.  I think that's a weak assurance, which is why I propose
> building a common run time system that doesn't rely on it.  The GCC
> team can achieve a similar effect by adding compiler flags (as you've
> proposed), but I'd like a run-time systems that isn't formally
> dependent on a particular compiler and that permits use of "-O" flags.

When Sun wanted exact GC and multi-language support for Java they created
JNI.  Of course it is slow and difficult to use correctly.  Red Hat (then
Cygnus) implemented CNI in their runtime as an alternative.

If you can design something as unintrusive as CNI without sacrificing
exact GC, I know there are many who would be interested.  But I'm afraid 
it is not easy to do.

> 
> 	 2) Asynchronous as in Java finalizers.  Here the programmer
> 	 has decided to abdicate responsibility for timing,
> 	 e.g. because it's hard to predict when precisely the last
> 	 pointer to the object will be dropped.
> 
> That's misleading.  One practical question is whether the programmer
> has useful pre-conditions that assure an object has been collected.
> Keeping track of object references isn't "hard to predict" for all
> objects;  on the contrary -- it's part of how good programmers use
> good collectors.

Your argument makes sense only for resources that are used by a
single thread.  Hans specifically described Java finalization, which must
be asynchronous.

Jeff