Re: Ada GC and a bunch of other stuff

hbaker@netcom.com (Henry Baker) writes:
> Someone mentioned the issue of the interaction of GC with compiler
> optimizations. David Chase has probably studied this more (at least
> in the last several years) than most everyone else, and has published
> papers on this (ACM PLDI, 1988??).


David Chase <chase@centerline.com> writes:


> Thanks for the plug, but you should also take note of the work done at
> U Mass by Eliot Moss, Rick Hudson, Amer Diwan, and probably others
> whose names I don't know offhand. Their goal is a Modula-3 system
> that does both the "usual optimizations" and precise pointer-tracking
> as part of a persistent object system (I'm paraphrasing -- I'm most
> familiar with the subgoal of pointer tracking in a compiler-optimized
> system, and not so familiar with their main goal). It's not a pretty
> problem.


To continue the plug, the accurate GC for M3 work of Diwan et al at
UMass, which was originally implemented in the context of our
now-defunct GNU M3 effort, has been reincarnated within DEC SRC M3
here at Purdue. We (myself and a student, Nedim Fresko) have been
running the SRC collector fairly reliably with accurate stack tracing
for about a month now, though we are still operating pretty much in
debug mode. Nevertheless, we compile and run some fairly substantial
(and threaded) programs in the M3 distribution quite successively.
Over the next month we expect to get a better idea of the effect of
optimization disasters such as those mentioned by David as we start to
turn on the gcc backend's -O switch.


> [long list of disaster scenarios deleted]


> 5. Something really vile involving different values assigned to the
> same variable on converging flow paths (this was related to me by
> Eliot Moss) -- this has a bad interaction with precise pointer tracking.


Funny you should mention this, as we spent most of last week tracking
down a bug related to this -- it turned out that gcc was reusing a
stack-allocated temporary both for a "derived" (Diwan terminology, see
PLDI'92) pointer and for an integer on two different code paths
upstream of a GC. Needless to say, treating an integer as a pointer
in an accurate collector can have a nasty effect.


> Preston Briggs and I had a wonderful idea over beer a few years ago
> that is too small to fit into the margin here, and that neither of us
> has had the time to properly follow up.


C'mon then, 'fess up.


I certainly have enjoyed this thread so far; hope to see more.
--

Return to the comp.compilers page.
Search the comp.compilers archives again.