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

On 08/08/2012 07:39 AM, Chong Yidong wrote:

Another problem, which I haven't seen mentioned in this thread, is that
when you see C code which does FVAR (x, y) the natural assumption is
that x and y are C variables.  So these macros hurt code readability.

The introduction of BVAR also violated this principle, and I'm not eager
to see the problem compounded.

It looks like we should think about how to redesign BVARs and KVARs so
that it should be suitable both for GC and concurrency development.

I think FSET/WSET/PSET/PGET/etc should be removed from the trunk, at
least for now.  I recommend moving the generational GC work to a branch.

Look at the size of changes I did just for a few days. This is just a
preliminary changes needed to implement write barriers on top of them.
Each pointer store is a subject to handle; most probably each source
file will be affected. I suppose that new GC tree will look so different
so the final merge will be a tremendous task on a few weeks. So I'm
thinking about 2-stage approach: preliminary work is in trunk (where
it might be used for concurrency branch and other development), and
new GC (barriers and core GC bits) is in branch.


reply via email to

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