[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r109327: Generalize INTERNAL_FIEL

From: Dmitry Antipov
Subject: Re: [Emacs-diffs] /srv/bzr/emacs/trunk r109327: Generalize INTERNAL_FIELD between buffers, keyboards and frames.
Date: Wed, 01 Aug 2012 20:52:00 +0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120713 Thunderbird/14.0

On 08/01/2012 06:58 PM, Paul Eggert wrote:

OK, but why bother to do the hugely overestimated
write barrier that FVAR implies?  Surely that is not
what is wanted here, for the garbage collector.  As I
understand it, what's really wanted for the GC is SET_FVAR.
FVAR itself might be useful in that it can be forced
to be an rvalue so that code doesn't use FVAR (...) = VAL
by mistake, but surely that is secondary.

I agree, but see 

Stefan's point also, is that it'll be easy enough to
introduce SET_FVAR when the GC bits are ready,
and that there's no pressing need to introduce it now.

I'm considering this much like a kind of chicken-egg problem:
it's very hard to design GC bits without supporting infrastructure
implemented, and no one wants to deal with obfuscated internal
things in the absence of visible advantages provided by new GC :-).

While we're on the topic, the code is currently sloppy
about using ASET; sometimes it uses 'AREF (a, b) = c'
rather than 'ASET (a, b, c)'.  I suppose this will
need fixing too.  It probably should be fixed regardless
of any GC changes.

Yes. BTW, there are few other things which are bad from GC's point of view:
X = &AREF (obj, idx), memcpy and memmove directly between FOO->contents
of struct Lisp_Vector, etc.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]