[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Emacs-diffs] /srv/bzr/emacs/trunk r107377: * src/lisp.h: Improve co
From: |
Stefan Monnier |
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 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.0.93 (gnu/linux) |
>>> > 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
Re: [Emacs-diffs] /srv/bzr/emacs/trunk r107377: * src/lisp.h: Improve comment about USE_LSB_TAG., YAMAMOTO Mitsuharu, 2012/02/22