This is the mail archive of the guile@cygnus.com mailing list for the guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: tools to make non-conservative GC feasible.


Chris.Bitmead@misys.com.au writes:

> >> As I've noted, though, we *could* pretty easily build tools to catch
> >> this automatically.
> >>
> >
> >Quite right, but will it even be possible to catch all uses that can
> >cause problems? I would think maybe, but continuations &
> >setjmp/longjmp are somewhat iffy. If we can't be 100% sure of catching
> >all the problems, what benefit do we really achieve over conservative
> >marking?
> 
> Programmers have always lived in fear of longjmp.  Code that uses
> longjmp has always needed to be very very careful with memory issues. I
> can't see that as a big deal. Who wants to longjmp all the time? Anyway,
> a tool could probably address even this I would say.

Continuations use longjmp. I'm not sure how explicit marking would
work around setjmp&longjmp, and it will probably be very difficult to
analyse for correctness.

> >We make execution time worse,
> 
> Do we know that for sure? For one thing, scanning the stack would be much
> quicker, which would allow incremental collection to become more feasible.

The overhead at runtime does increase. Stack values that never have to
be traced still get the full treatment, so it's easy to see more work
will be done for the explicit marking. For incremental collection it
doesn't really help, since what we need is a write barrier for the
stack (though the two can be combined, we don't really need the
explicit marking).

> >still have some uncertainty
> >over the correctness of the code (and the chances of fatal errors in
> >messed up explicit marking seem larger to me than the chances of fatal
> >errors in the conservative scan, though the optimized away variables
> >really need to be addressed in a clean way),
> 
> If the optimised away variables problem is real, then I'd take comfort in
> code that once it's written stays working even if it took a bit more work
> as opposed to easy to write code that may well break on any new compiler
> release or minor code tweak.

It isn't really, I didn't explain the problem correctly, as has been
pointed out. All it requires is that you use SCM values, rather than
getting pointers to it's innards, and playing with those (that's why
the SCM value can be chucked, even though it's still being
[indirectly] used). This is probably better style anyway, and the
performance increase from using the pointer will generally be
negligable (and may even hurt on register starved platforms).

This is essentially a machine dependant oddity, and there are more
than enough of those to cause worry, conservative marking or not. Now
everyone is painfully aware of the potential problems, so things
should go fine ;).
-- 
Greg