This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: robustness vs. conservative GC

	> what would prevent [hidden pointer] bugs from biting GCC or
	> various Java implementations?

    The fact that the Java collector always treats interior pointers from the
    stack as valid,

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).

	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.

	 You have to be really careful here.  There are two kinds of
	 actions you can take when an object goes away:


	 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.

	[Precise, compiler-independent collectors cause slow
	calling conventions.]

That's a definate maybe.  It depends, of course, on how calls are
implemented -- you and Fergus are taking a narrow view of that, but
presenting that view as if it were universal.

Regardless, even sticking to the particular implementations you
have in mind, the size of the performance hit is unknown, and
has to be weighed against robustness and correctness.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]