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

[Paul Eggert]

On 5/27/20 11:56 AM, Pip Cet wrote:

> So, at the very least, we need to always keep the immediately
> preceding object alive if we go that way.

Yes, I'm assuming that. I'll check that the code is doing that (if it isn't
doing it already).

> that's a significant overhead because it
> usually means two objects are being kept alive by one reference.

For Lisp_Objects with nonzero tags this shouldn't be an issue, since the tags
mean the pointers won't tie down two objects. For Lisp_Symbols (whose tags are
zero) it is an issue; also for untagged pointers to the start of objects.

I'll measure how much overhead is involved in my usual 'make compile-always'
benchmark. If it's not that much then we'll be OK. I'm hoping that's the case.
If not, there are some more measures we can take.

> With prefetch instructions, it's quite likely the compiler concludes
> it's easiest to prefetch something 256 bytes ahead of where it
> actually makes the access, then make the actual access relative to
> that address...

I wouldn't worry about that; it's so unlikely that it's not a practical concern.
"Some C optimizers may lose the last undisguised pointer to a memory object as a
consequence of clever optimizations. This has almost never been observed in
practice." <https://github.com/ivmai/bdwgc> As I understand it, the times "in
practice" that Hans-J. Boehm was talking about were for C code deliberately
designed to fool the compiler / GC combination.

I think it unlikely that a modern compiler would break all the code out there
that uses conservative GC.

(Besides, if that stuff really were of practical concern we'd have to give up on
conservative GC entirely. :-)