[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: Thu, 02 Aug 2012 08:12:29 +0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120713 Thunderbird/14.0

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


reply via email to

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