Re: GC: cons sweeping and cons block size

[Stefan Monnier <monnier@iro.umontreal.ca>]

>>> On some systems, Lisp_Object may be a tagged pointer with 29-bit (on
>>> 32-bit system) pointer field. Since mmap() tends to allocate memory at
>>> high addresses, this memory is likely to be non-addressable by such
>>> pointer. That is why lisp_align_malloc() currently uses
>>> mallopt(M_MMAP_MAX, 0) to prevent mapping the region (if underlying
>>> malloc() supports this). 
>> 
>> 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.

> Would that impact the severity of YAILM (or what the integer/lisp
> mixups were called) occurences?

Not at all.  Actually the severity of YAILOM is increased with the use of
LSB bits for tags: since the 000 tag has traditionally been used for
integers, it means that positive integers were represented by themselves
(when placing tags in the MSB), so YAILOM errors would often cause no
problem in practice, whereas when placing tags in the LSB all integers need
shifting, so YAILOM errors lead to lack of those shifts which leads to
integers being "tagged" randomly (depending on their value mod 8), often
causing Emacs to treat those integers as pointers which then cause
segmentation violations.

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).


        Stefan