Re: tools to make non-conservative GC feasible.

[Chris.Bitmead@misys.com.au]

>> 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 ;).