[gclist] stack map generation in the presence of optimization

[David Chase]

At 11:32 AM 11/19/99 -0500, Eliot Moss wrote:
>The original reference to building stack maps, in the presence of
>optimization, that the correspondent may have had in mind is:

>    Amer Diwan, J. Eliot B. Moss, and Richard L. Hudson, "Compiler Support
>    for Garbage Collection in a Statically Typed Language," ACM SIGPLAN '92
>    Conference on Programming Language Design and Implementation, San
>    Francisco, CA, June 1992, pp. 273-282.

It's been a while since I read that paper, but given the experience
of recent years (building a compiler with stack maps and some
optimization) how the heck did you ever convince yourself that
you had it all right?

The reason I ask is that just recently, after adding a frob to register
allocation, we did something wrong to our stack maps, but programs
(large, complex programs) would often run for quite some time
without an error.  This was even so when using a full copying
collector with the old space unmapped after a collection; if a
collection leaves a still-useful pointer dangling, then there
will be a noticeable error.  A less aggressive collector (for
instance, a generational collector, or a mark with deferred
sweep) would make the error even harder to detect.  We've had
similar problems occur in the past when (for instance) unsafe
code carried a loopholed pointer past a garbage collection.

To debug this (in particular, to figure out what went wrong)
in our system, we run a garbage collection at every single
safepoint (that is, at every single place a thread could
possibly be interrupted by a collection) to ensure that we
have exhaustively tested GC possibilities within a single program.
It's slow as anything, but it works like nothing else we have
tried.  Execution is nearly deterministic, too, which is also
a big help.

So, what do other people do?  Especially, what do you do
without safepoints?

David Chase
chase@naturalbridge.com