[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GC: cons sweeping and cons block size
From: |
dmantipov |
Subject: |
Re: GC: cons sweeping and cons block size |
Date: |
Wed, 4 Jul 2007 10:43:32 +0400 (MSD) |
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