[Top][All Lists]

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

Re: GC: cons sweeping and cons block size

From: Ken Raeburn
Subject: Re: GC: cons sweeping and cons block size
Date: Fri, 6 Jul 2007 07:54:46 -0400

On Jul 5, 2007, at 12:02, Stefan Monnier wrote:
(quoting David, who was quoting Stefan)
I haven't found the time to do it, but it would be good to get rid of this
situation and always place tags in the 3 LSB bits.

It does appear to be the default for most systems, maybe all modern ones, but only when we compile with GCC. Are we confident no one is using Emacs on systems where we use a system malloc that doesn't do 8- byte alignment? Or where the native compiler doesn't do 8-byte alignment for static objects? I think I'd be happier with changing the default to use USE_LSB_TAG always but check the malloc return values and compiler-produced alignment on the configurations where we don't already know we're safe, and perhaps delete that code and maybe much of the non-USE_LSB_TAG code a while after it's released without related bug reports; I'm afraid that temporarily increases the ugliness rather than reducing it though.

Luckily, YAILOM problems can be cought by the compiler if you
use -DUSE_LISP_UNION_TYPE (but it incurs a performance hit, which is why
it's not used by default).

Hm, I don't think I ever got around to seeing if __attribute__ ((transparent_union)) would fix the performance...

We could do a USE_LSB_TAG variant of the union, to get more address space back but keep the paranoid type checking capability.


reply via email to

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