[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Purify'd scheme(s) -- a contribution to the `GEL = SCM + RMS' debate
From: Matthias Blume <blume@CS.Princeton.EDU>
Date: Wed, 26 Oct 1994 17:49:54 -0400
I just got a chance to play with Purify (a commercial product for
`purifying' C programs).
And just for the heck of it I thought -- why don't I try applying it
to SCM...? So I went and did it. The `Purify'd' SCM was then used to
run some of the Gabriel benchmarks. Here is what I found:
CPSTAK : Finished scm (11492 errors, 0 leaked bytes)
CTAK : Finished scm (1724633 errors, 0 leaked bytes)
I leave the detailed evaluation of these figures to you.
OK. "0 leaked bytes"; I assume that means that SCM freed all malloced
memory. Good, I'm glad the effort to do this paid off.
As for the "errors", SCM uses a conservative GC. This means that it
scans any memory (including stack) which might contain pointers to
UMR: Uninitialized memory read (45 times)
Such memory may well be uninitialized. It would be a meaningless
waste of cycles to initialize it just to satisfy "Purify".
SBR: Stack array bounds read (96 times)
BSR: Beyond stack read error (5 times)
In order to assure that all of the stack is scanned, the top of stack
is gotten by a call to a procedure. This outer limit is then used for
the scan. But the stack has shrunk when returning from that call,
thus the "Beyond stack read error".
SBW: Stack array bounds write (166 times)
This is how SCM restores continuations. This would not occur in GEL
as RMS has outlined it, since he wants only escape continuations and
SCM has a flag which turns off stack copying.
Notice one thing further. "Beyond stack write error" doesn't occur in
your list. SCM calls a procedure repeatedly until the bottom of its
stack frame is above the top of the stack to be copied in. Thus SCM
only copies into bonified stack.
I myself can give these recommendations:
1. If you are a C programmer, then give Purify a try! (I'm not
affiliated with Pure Software Inc.)
Why? Just below you give a disclaimer saying it was unreliable. And
the above results show that it definitely misdiagnoses a conservative
GC. You only report success with one program.
2. Don't use SCM for critical applications until it has been
CAREFULLY overhauled. Don't turn it into a (*the*) GEL, before
this has been done!
This is not a valid conclusion since it is drawn from an admittidly
unreliable tool. Didn't it make you wonder how all the people who use
SCM on a wide variety of hardware and systems manage not to get
segment violations and other problems given the millions of "errors"
found by Purify?
What you are really attacking here is conservative GC, not SCM's C
code integrity. George Carrette (firstname.lastname@example.org) actually *does*
write mission critical applications (chemical plant controls) using
the same conservative GC that SCM's was derived from! I believe he
has more experience in this area than anyone on the rrrs-authors list.
I suggest you contact him for an authoritative opinion on conservative
SCM is not the first program to use conservative GC and will probably
not be the last. You are welcome to your opinion that conservative GC
is undesirable, but there are thosands of hours of time logged on
conservative GC systems that show that it can be a solid, reliable GC
3. Don't close your eyes in front of other choices!
Incorporating C routines into GEL is a major requirement.
Conservative GC is actually a feature in this case because of the ease
with which C code can be incorporated (not having to maintain explicit
GC protects, etc). Do any Scheme implementations other than SIOD and
SCM use conservative GC?
Disclaimer: I found Purify on the machine I was using to be somewhat
unreliable in some cases. So take everything I said with a grain of