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: > >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. This is usually not a problem. The compiler will only optimize away an SCM value if you're not using it any more. If you're not using it any more, GC:ing the value is the right thing to do. If you are able to access the SCM value later in your function, the GC will be able to access it as well. The optimization-hazard only exists when you do things like storing SCM values in a data structure on the heap, in which case you might want to protect it for a while with a pointer in an automatic variable. You can't trust that an SCM variable will work as GC protection for some other use of the object, but you can trust that SCM variables are valid as long as you're using their values. /mdj