Re: understanding GC
Ar an triú lá de mí Feabhra, scríobh Julian Bradfield:
>Julian Bradfield <jcb+xeb(a)jcbradfield.org> writes:
>> As usual when I try to do anything, I find I really don't quite
>> understand GC and when GCPRO is necessary.
I felt like this for years, and now I don’t any more, mainly because I
committed a few patches where things got garbage-collected that shouldn’t
have been, and it wasn’t always my mistake. Cf. this and the related thread:
http://mid.gmane.org/19139.32892.491325.763382＠parhasard.net
The #'reduce bug here *was* my mistake, though:
http://hg.debian.org/hg/xemacs/xemacs/rev/4c4085177ca5
It’s difficult to get GCPRO right all the time, but understanding when one
should GCPRO is not that difficult.
>Did you look at the section on garbage collection in the
internals
>manual? In particular, there's a subsection on GCPRO.
Yes...but I should have read the Invocation section more carefully.
>> concat() in fns.c GCPROs its arguments, to be helpful to the caller.
>> What is it that concat() does that could cause a GC or QUIT?
>
>It allocates. If there's not enough free space in the heap to satisfy
>an allocation, a GC is triggered.
The manual clearly says "this is _not_ the case".
Right. Feval(), Ffuncall() are what to worry about. The CHECK_STRING() etc.
macros are less of an issue now, they used to signal continuable errors, but
now they’re non-continuable, so you won’t get past that line of the C code
with some memory you’ve just allocated having disappeared. But the various
code that calls wrong_type_argument () in emulation of the continuable
behaviour will shoot you in the foot.
--
“Apart from the nine-banded armadillo, man is the only natural host of
Mycobacterium leprae, although it can be grown in the footpads of mice.”
-- Kumar & Clark, Clinical Medicine, summarising improbable leprosy research
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta