Jan Vroonhof <vroonhof(a)math.ethz.ch&gt; writes: It already is. AFAIK dlmalloc is used by default on Linux. The change was made when minimal tagbits were created. That's why minimal tagbits are chosen by default on Linux. It is my understanding that there are safety issues which make ralloc unsafe for anything but buffer text. But these issues might be restricted to non-mmap version of the allocator. I don't know. Yes, and that's a feature. mmap()-based allocation would be way too slow for small allocations. 1000 1k buffers is probably contrived. However, 1000 1k strings would be relocated by the compactor, and the cons cells would be allocated in frob blocks. Which means the memory will be released after GC. But why not test it? 1) Evaluate: ;; 100,000 cons-cells is about 1M (prog1 nil (setq a (make-list 100000 ?a))) 2) Evaluate: (setq a nil) (garbage-collect) The sizes are: 8876 5656 (1) 9956 6748 (2) 8932 5728 Apparently the memory is reclaimed. The string test has failed, and I don't think I can really explain it. If I read alloc.c correctly, strings smaller than 8K should be "small strings", and all of these are supposed to fit that category. It seems they were nevertheless exempt from compacting/freeing. No idea why. The biggest problem with frob blocks in our GC is that no relocation or compacting is done. This means that if only one cons-cell in a frob block remains in use, the whole frob block can't be freed. This was not the case in your example. It seems to. How much is it now? 1000 conses? The no-relocation problem described above makes me uneasy about making it larger.