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

[Dmitry Antipov <dmantipov@yandex.ru>]

On 08/02/2012 03:52 AM, Stefan Monnier wrote:

> Then, please undo your changes.  The INTERNAL_FIELD part is fine, but
> the new FVAR, WVAR, ... are not.  Maybe it can be useful as an
> intermediate step on some separate generational-gc branch, but it
> doesn't have its place in trunk:

Look at concurrency branch. Everyone agrees that this is an interesting
and useful feature, but no one wants to handle an endless merging efforts.
If we had the same amount of developers as involved in Linux kernel, it's
the only possible practice to maintain 100 branches or even separate
trees for each major feature; for us, everything which is not in trunk
is the candidate to throw and forget, and large amount of code increases
the probability of such an inglorious end.

> I can't think of any way to make such
> macros give realistic performance with anything but a write-barrier, so
> such macros will only ever be needed for write accesses and never for
> read-accesses.
> So you're obfuscating the read-accesses (i.e. the most common case) for
> no good reason.
> I'm OK with introducing such macros to *set* such fields (i.e. for write
> barriers), but not to read them (at least not until there's a really
> good case for them).

Really good case comes very quickly when you start the real debugging.
Things like FVAR are very helpful to trace _all_ accesses to Lisp_Object
members; when FVARs will be converted to rvalues and SETFVARs will be
used appropriately, this guarantees that no pointer stores bypasses
the barrier (just one such a store is fatal for the collector). Next,
when we will know that the collector invariant is never broken, it's
possible to replace these obfuscated FVAR (x, y) back to x->y.

Again, this is 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. IMHO the only solution is to suffer
some obfuscation until it becomes really useful.

Dmitry