From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Paul Eggert <paul.eggert@verizon.net>
Cc: emacs-devel@gnu.org
Subject: Re: [Emacs-diffs] /srv/bzr/emacs/trunk r107377: * src/lisp.h: Improve comment about USE_LSB_TAG.
Date: Wed, 22 Feb 2012 22:15:40 -0500 [thread overview]
Message-ID: <jwvaa4axnig.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <4F459455.8070206@verizon.net> (Paul Eggert's message of "Wed, 22 Feb 2012 17:20:21 -0800")
>> What kind of extra masking are you referring to? The XFASTINT?
>> Note that the LSB masking can be cheaper than the MSB masking
> No, it's XPNTR that's faster, because its masking comes for free --
> zero runtime overhead on my platform.
Oh, interesting. The masking code is not null, but the compiler manages
to compile it away because it masks bits that are outside the range
of pointers.
>> So "VALBITS is greater than the pointer width in bits" is not
>> the exactly right condition (e.g. if we have 48bit pointers and 61
>> VALBITS then the problem should not appear).
> Most likely not, true. The current code is conservative. I don't
> know of any real platform where the conservatism matters, though.
No, indeed it doesn't matter in practical terms, it only matters if
you try to understand what's really going on.
>> Maybe a better fix is to add code to the stack marking loop, conditional
>> on WIDE_EMACS_INT and USE_LSB_TAGS, which passes pointer-sized
>> words to mark_maybe_object after expanding them to EMACS_INT size.
> That patch would be more intrusive.
Arguably, yes, but it would have the advantage to attack more precisely
the actual core of the problem, so it "reifies" in the code our
deeper understanding of the problem. IOW it makes it less likely that
someone later on won't understand what's going on.
> Plus, the following (further) patch is simpler and faster. This patch
> is purely a performance improvement so I didn't install it (was
> planning to do it after 24.1 comes out, but if you like I can do it
> now....).
> +#if defined USE_LSB_TAG || UINTPTR_MAX >> VALBITS != 0
> /* Mark Lisp_Objects. */
> for (p = start; (void *) p < end; p++)
> for (i = 0; i < sizeof *p; i += GC_LISP_OBJECT_ALIGNMENT)
> mark_maybe_object (*(Lisp_Object *) ((char *) p + i));
> +#endif
I'm not sure why you think this patch is "simpler and faster", since
AFAICT it does not solve the original problem, whereas the change
I suggested does (or at least, should), so they're
basically incomparable.
As for that change, the reasoning for why it's correct doesn't seem
obvious to me (I understand why it's correct in the current
WIDE_EMACS_INT case, but generalizing from that to the case
"UINTPTR_MAX >> VALBITS != 0" seems risky). So I'm not in favor of this
optimization as it is (of course not for 24.1, but probably not for 24.2
either).
Stefan
next prev parent reply other threads:[~2012-02-23 3:15 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <E1S0EsZ-0006bE-5w@vcs.savannah.gnu.org>
2012-02-22 20:25 ` [Emacs-diffs] /srv/bzr/emacs/trunk r107377: * src/lisp.h: Improve comment about USE_LSB_TAG Stefan Monnier
2012-02-23 1:20 ` Paul Eggert
2012-02-23 3:15 ` Stefan Monnier [this message]
2012-02-23 6:31 ` Paul Eggert
2012-02-23 7:42 ` Stefan Monnier
2012-02-25 7:00 ` Paul Eggert
2012-02-25 10:06 ` Stefan Monnier
2012-02-25 19:46 ` Paul Eggert
2012-02-23 3:57 ` YAMAMOTO Mitsuharu
2012-02-23 6:28 ` Paul Eggert
2012-05-09 17:56 ` Paul Eggert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwvaa4axnig.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=emacs-devel@gnu.org \
--cc=paul.eggert@verizon.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.