This is the mail archive of the guile@sourceware.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: gc-mistakes.txt


"Jorgen `forcer' Schaefer" <forcer@mindless.com> writes:

> Hi there..
> gc-mistakes.txt is a nice document and quite helpful, i just have
> a few reccomendations on how to improve it :]
>
> First of all, it's nice to know that something is bad, but it's
> nicer to know why.  gc-mistakes says "Do this and you'll lose the
> object" -- it's not quite obvious the the newbie *why* you'll
> lose it.
> 
> e.g.
> > and make_new_foo_elts can cause a collection, then any number
> > of foo elts can be dead by the time you actually use it.
> 
> it would be nice to add
> > This is because the elements in foo_elts are not referenced
> > anywhere and are not on the stack.

> and to the fix add
> > This works since we add the array to our object, which will
> > mark the objects in the array.
> 
> It's quite tedious to find out such information yourself, and
> probably impossible for "newcomers"...

Sorry, I thought most of that would be implicit (i.e., create a vector
that we can see and we'll mark it :).

> 
> Section 3 i still don't understand.  If you get passed an object,
> it's on the stack, right?  

Not necessarily; it could be in a register (dunno how often this
happens, tho), it could be on the stack, but the compiler could see
that we aren't using it, and steal that stack location, or it could
get really funky and only keep a reference to the stuff that we're
using. Trying to guess what the compiler may or may not do is the path
to madness ;). Actually, my example didn't cover all the places where
this can happen. I'd expect that the most likely culprit would be
something like:

SCM x = scm_make_vector(SCM_MAKINUM(20));
SCM *velts = SCM_VELTS(x);

etc...

If x isn't returned, this can also get into trouble.

> So, why does one need to remember it?
> And why ad the *end* of the function?

At the end is part stylistic, part necessary (maybe). Often, it's
clearer to just do a

return scm_return_first(val_you_want, stuff to be remembered,...); 

So, it's just as well to put the scm_remember at the end, too. For the
necessity part, the compiler could see that we're still only looking
at it once towards the beginning, and ignore it (dunno if it would or
not, but it might be less likely to optimize it away if it's not
very close to the point where we stop actually using it). 

I'll update the actual document with these things over the next few
days. Thanks for the suggestions :)

-- 
Gregh

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