Re: Calling Scheme from C and Garbage Collection

[Greg Harvey <Greg.Harvey@thezone.net>]

Chris.Bitmead@misys.com.au writes:

> >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 really dislike the current work around, since it is, after all, not
much less than explicit marking. I'm hoping that there's a way to
avoid this without declaring every SCM value volatile.
 
> Can this be solved by looking at CPU registers or something?

The conservative gc does look at the CPU registers, but by that time,
the value has floated off to the ether.

> >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
> >croaked.
> 
> 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. 

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.

> 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.
 
This would be the absolute best, but I'd think that a lot of people
approach most problems by writing them in c. Maybe because they're
more familiar with c, maybe for efficiency, maybe bit twiddling gives
them a warm, fuzzy feeling. Also, when you're talking about
integrating a large, pre-existing app with guile, you're talking about
a large amount of guile programming in c. As if all of c weren't bad
enough, you also get the joy of explicit registration pairs.
Eventually you just say bugger it, shave your head, buy a funky robe
and start dancing in airports.

-- 
Greg, `hari krishna' *ding* *ding*