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] |
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