Re: GC: cons sweeping and cons block size

[dmantipov]

Jonathan Yavner wrote:

> On some systems, large malloc blocks go directly to MMAP_ANONYMOUS and 
> so fragmentation worries are eliminated.  I don't see any support for 
> direct use of mmap() in gmalloc.c, though.  Should we consider it?  
> OS-specific code is needed -- Windoze calls it VirtualAlloc(), while 
> MacOS calls it vm_alloc().

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

On other systems, like the most commonly used i386 systems with GNU C library 
:-), all malloc()ed addresses are multiplies of 8, so top 3 bits may be used 
for tagging and address space may be unrestricted. It's technically possible to 
use mmap() on such systems, an it would ne an interesting task to implement 
this. The minor weakness of having everything 8-bytes aligned is a 
fragmentation - for example, 20-bytes objects must be interleaved with 4-bytes 
holes, or have spacers to enlarge themselves to 24 bytes.

And, finally, what about the dumper ? "Lisp data may not be mmap()'ed because 
mapped region contents are not preserved in a dumped Emacs" - quoted from 
src/alloc.c. I'm not familiar with dumper details enough to answer on this. Of 
course, we may check if we're dumped or not and use mmap() only if dumped, but 
I'm not sure this is the most elegant solution.

Dmitry