From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Paul Eggert <eggert@cs.ucla.edu>
Cc: emacs-devel@gnu.org
Subject: Re: [Emacs-diffs] /srv/bzr/emacs/trunk r107377: * src/lisp.h: Improve comment about USE_LSB_TAG.
Date: Thu, 23 Feb 2012 02:42:39 -0500 [thread overview]
Message-ID: <jwvehtmuhwb.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <4F45DD5B.3010801@cs.ucla.edu> (Paul Eggert's message of "Wed, 22 Feb 2012 22:31:55 -0800")
>>> > 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.
> I don't know what you mean by "actual core". As I
> understand it the change you're proposing would require an
> O(N**2) pass through a stack with N 32-bit words (assuming
> 32-bit registers and 64-bit EMACS_INT).
No, that would be a "real fix". What I suggest is just to take the O(N)
pointer-sized entities on the stack, cast them to EMACS_INT, and pass
them to mark_maybe_object.
>> 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).
> I don't understand what you mean by "generalizing"; can you give
> an example of the more-general situation you're worried about?
No, the problem is theoretical: what is the logical justification?
> Are you worried that pointers might be aligned more-strictly
> than EMACS_INT values?
Not really. I'm just trying to construct a proof in my head that your
optimization is correct, and I can't seem to connect your
hypothesis "UINTPTR_MAX >> VALBITS != 0" with the conclusion.
Your additional alignment hypothesis might be the key, but I'm still
struggling to see how the proof would work.
> + /* The mark_maybe_pointer loop will suffice, since it will recognize
> + the bottom bits of any Lisp_Object containing a pointer, if we
> + can assume that Lisp_Object values are aligned at least as
> + strictly as pointers. Although this assumption is true on all
> + practical Emacs porting targets, check it anyway, to be safer. */
> + { verify (GC_LISP_OBJECT_ALIGNMENT % GC_POINTER_ALIGNMENT == 0); }
I really don't think such complexity is warranted for such a minor
optimization of a compilation option which is currently not enabled
by default. If/when we enable it by default, we may revisit this
choice, but for now, I'd rather not go there.
Stefan
next prev parent reply other threads:[~2012-02-23 7:42 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
2012-02-23 6:31 ` Paul Eggert
2012-02-23 7:42 ` Stefan Monnier [this message]
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=jwvehtmuhwb.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=eggert@cs.ucla.edu \
--cc=emacs-devel@gnu.org \
/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.