bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#41321: 27.0.91; Emacs aborts due to invalid pseudovector objects


From: Paul Eggert
Subject: bug#41321: 27.0.91; Emacs aborts due to invalid pseudovector objects
Date: Sat, 30 May 2020 15:18:53 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0

On 5/30/20 12:33 PM, Eli Zaretskii wrote:

Posix may require it, but do we actually know of any supported
important platforms where this happens?

That depends on what the question is. If the question is "Are there platforms where the lost-marker bug occurs?", then no, we don't know of any supported important platforms. But if the question is "Are there platforms where LISP_ALIGNMENT should be some value other than 8?", then yes, LISP_ALIGNMENT should be 4 on Ubuntu 18.04.3 i386 when Emacs is configured --with-wide-int (I just tested this, and it is indeed 4 on that platform in the Emacs master branch). This is because on this platform Lisp objects have a native alignment of 4, and this platform is !USE_LSB_TAG so the presence of tag bits imposes no extra alignment requirement.

let's worry about the
more general fix on master, where we still have time to try various
solutions, and settle for a simpler and easier fix on emacs-27.

Yes, that's what we're trying to do, and it's what's in the latest patch that Pip Cet and I proposed very similar variants of.

But your proposal is also less efficient, isn't it?   If so, its more
general nature comes at a price.

Sure. Compared to simply making LISP_ALIGNMENT = 8 as a workaround (which is not correct as noted above but which fixes the lost-marker bug), the proposed patch is about a 1% CPU-time hit in my usual benchmark (make compile-always) on a 32-bit platform compiled with --with-wide-int (this is Ubuntu 18.04.4, gcc -m32, Xeon E3-1225 v2). We can surely speed this up with some cost in complexity (that's what I was working on on the master branch), but for emacs-27 I thought that reliability took precedence over 1% performance improvements.

I expect that most of the performance hit is not due to the LISP_ALIGNMENT thing, it's due to the "you have to check pointers three times" thing. In my master-branch draft I'm working on getting this down to "you have to check pointers an average of 1+epsilon times" for some suitable value of epsilon. I don't know yet what epsilon will be. But anyway, this is only about improving that 1% performance hit.





reply via email to

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