Re: Calling Scheme from C and Garbage Collection

[Tel <telford@eng.uts.edu.au>]

> > >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.
> 
> Nope, you don't have to upgrade your compiler to get it to happen, it
> will happen now with any current gcc or offshoot. The thing is that
> it's both being put into a register and being thrown away after the
> last reference. A good example of a place where this can happen is in
> numbers.c, in scm_big2str. Now, I don't know gcc intimately, but what
> appears to happen is that, with all the references to t occuring in
> one small block, it can stick t on a register, then let it die after
> the last use.

I'm not understanding why there is a problem here. If the value is in
a register it can still be discovered by the garbage collector by checking
the registers. If the value is no longer used then it doesn't matter
if it is being collected or not.

The reason that big2str() has a problem is that the pointer `ds' is
accessing the internals of the bignum directly while the `t' value is
holding the SCM that keeps the bignum. The C pointer is doing all of the
real work but is depending on the SCM value to protect the memory from
collection. It seems to me that this is a rather unusual circumstance
and I would argue that the SCM should be declared volatile in this
particular case. This doesn't mean that every SCM need be declared
volatile nor does it imply that SCM values can't go into registers.

> Well, collected objects will get set to a free cell already, so that
> isn't necessary. This is also, without a doubt, the worst possible way
> to try and find a bug (says me, who's spent the past few days hunting
> similar things down with the new gc ;). In a large program with a lot
> of things getting written in c, you likely won't want to stop to
> compile and test after writing every function that can be called from
> scheme.  So you have a big bunch of functions, then you have to design
> a test that runs them all through the paces, and then you try to hunt
> down all the things that could be screwed up. To make it more
> interesting, gc bugs tend to not show up where the problem actually
> occurs, particularly if you're talking about values that live too
> long, rather than die too early.

Hence the idea of forcing GC more often than it would normally occur
(i.e. as often as possible). Changing the SCM value at collection time
is not enough to precipitate a crash though because (as I noted above)
the real issue is when that SCM value is holding some malloced memory
and there are pointers into the malloced memory. To be serious about
GC bugs you have to make the collector chase down any malloced memory
such as vectors and SMOBs and scrub the contents of this memory too.

	- Tel