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] |
>> 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. >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. >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. >and have made life that >much more annoying for the c side of things (I think it's annoying >enough as it is ;).