Re: [Emacs-diffs] /srv/bzr/emacs/trunk r109327: Generalize INTERNAL_FIELD between buffers, keyboards and frames.

[Dmitry Antipov]

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 
http://lists.gnu.org/archive/html/emacs-devel/2012-08/msg00001.html.

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

Dmitry