Guile Mailing List Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Calling Scheme from C and Garbage Collection
> >Looks like it could be. What happens sometimes is that the compiler is
> >optimizing away the SCM value, so that the gc can miss it. What you
> >can do is scm_remember(&r),
> Heck, I wasn't that worried before. Now I _AM_ worried. That means if
> every time I get a minor compiler upgrade I have to re-test every
> single thread of logic in case the compiler has got better at optimising
> things. And you think explicit marking is hard work? At least what works
> stays working.
> Can this be solved by looking at CPU registers or something?
It *requires* looking at CPU registers. In most cases setjmp saves
the register values that need looking at, but this is not required
by any standard save perhaps good taste. Several years ago, before
Guile, a Cray Research compiler upgrade did break my port of SCM --
it was necessary to write a replacement for setjmp in order to make
SCM garbage collection work.
The problem is variables being optimized away entirely, not merely
allocated in registers. Guile assumes that SCM objects passed on
the C stack are protected -- this is not necessarily true for C
compilers that do aggressive inlining. It was necessary to turn
off inlining in the case of the Cray port.
> >Of course, the same can be said of a program that used explicit
> >allocation/deallocation or registration of roots, where it was messed
> >in one out of the way place that didn't show up until someone
> I can't see the problem here. If you write a new C function then there
> should be some scheme testing flag that does a full garbage collect
> every time a scheme object is allocated. Any collected objects are
> set to 0xffff for testing purposes. You'd find out pretty quick if there
> were any bugs in a newly added function doing this. Of course the idea
> is not to be writing C functions all day and integrating it into scheme.
> I think you should be aiming to write everything in scheme and only adding
> C functions for external libraries or when absolutely necessary.
I have actually tried your exhaustive testing solution -- it is *far*
too slow to be practical. One can arrange to gc on every 100th or
1000th allocation and hope to shake bugs out sooner than by using the
normal gc policy.
Collected objects *are* bashed, the car of each is set to 0x7f, and
the cdr points to the next free cell. I have never seen a problem
with cons cells being collected, all of the gc glitches have involved
malloc headers. As a debug option, it's not unreasonable to bash
mallocated storage before freeing, this is now a debugging option in
To sum up, conservative gc requires a chumminess with the C compiler
that is not warranted by any standard. It may require platform and
compiler specific hacks in order to work properly. I still think it's
likely to be more trouble free than the alternative.
Guile Home |
Main Index |