[gclist] What to say about GC.

[Roy Ward]

I wrote:

> On the other side of the coin, a few years ago, I was writing a
> symbolic algebra program in a language that was still under
> development, and I found that my program would run fine for
> about an hour, then it would crash in an obscure way after a GC.

Jerry Leichter wrote:

> and I don't recall the last time I heard someone argue for using
> assembler to avoid all those compiler-caused problems!

but I have often heard the suggestion of turning off some of the
optimizations on compilers. Of course that means a broken compiler
(or at least broken optimizers).

Richard A. O'Keefe wrote:

> How is this different from any other bug in the support for your
> language?

[lots of examples snipped]

The main difference is the lack of locality in GC bugs. (This
property is shared with allocation bugs and, I imagine, bugs in
muti-threaded systems). In the first two examples you gave, the
errors could be tracked down to quite a small piece of code, and
if the worst came to the worst, looking at the assembler code
could show the problem up. Most (not all) optimizer bugs seem
to be like this. I agree that printf is messier, but at least
you can easily find out what function has the problem, then look
for a workaround.

Not so the GC bugs. My memories of using that package was that
there were lots of bugs (expected, since I was the second user of
it), but that most of the non-GC bugs were easily tracked down and
fixed, whereas debugging the GC related stuff seemed like about 80%
of the work. Eventually the author wrote some debugging code that
went through the whole application memory after each GC and checked
for errors, and this improved things immensely.

> Does that say to me "oh, printf is wrong, never use it
> again"?  Does that even say to me, "oh, C is bad, never use it again"?
> Nope.  It tells me *that* version of *that* compiler is broken,
> and that's all.

If I was to work that way, I'd never use a compiler at all ...
but I do get a bit miffed when I have to work around a compiler
error.

I wrote:

> ... possibly given GC a very bad name with those who have
> had that sort of trouble

I did not mean to imply that I considered GC itself to be bad,
just that when the system takes over the job that a programmer
used to perform, then gets it wrong, the programmer is not going
to feel like the situation has improved.

To make myself clearer:

I do _not_ advocate using manual memory management, because that
is horribly error prone. (I avoid such languages where I can).

Having a language that takes care of all memory management
reliably (whether by full GC or other ways) is at least as
much of a step up from languages with manual new/delete as
languages with types are a step up from assembler.

My observation is that implementing one such language was
very hard work, and a big part of the problem was a faulty
GC introducing the very problems it was supposed to prevent.

I suppose that I could turn this into a question, and ask
"What techniques have people found useful in GC debugging,
as some of the usual methods don't work well?" The obvious
ones are:
- writing separate code that checks for GC induced errors
- writing locations with values likely to cause bus errors,
   to cause errors to show up quickly.

Any others? Or (on-line) places I can look for information
on this? I want to be well prepared when I start working
on GC for my system.

A buggy GC is in many ways worse than no GC.

Roy Ward.