On my Linux system, Libc info documentation states this about malloc(): Very large blocks (much larger than a page) are allocated with `mmap' (anonymous or via `/dev/zero') by this implementation. This has the great advantage that these chunks are returned to the system immediately when they are freed. Therefore, it cannot happen that a large chunk becomes "locked" in between smaller ones and even after calling `free' wastes memory. The size threshold for `mmap' to be used can be adjusted with `mallopt' [the default one is 128K --hniksic]. The use of `mmap' can also be disabled completely. It seems that our relocating allocator attempts to do what Doug Lea malloc() already does. The system-provided mmap-based allocation seems a better idea in XEmacs because it's performed for *all* large allocations (large vectors, strings, frob blocks etc.) rather than only for buffers, as our ralloc does. So I conducted the following test: 1) Allocate a 10M string with (prog1 nil (setq a (make-string 10000000 ?x))) 2) Allocate a 5M string with (prog1 nil (setq b (make-string 5000000 ?x))) 3) Remove reference to the first string and garbage collect. (setq a nil) (garbage-collect) 4) Remove reference to the second string, the same way. Sizes of the XEmacs process go like this (size/resident size, as reported by ps): Start: 8860 5640 (1) 18644 15444 (2) 23532 20332 (3) 13776 10572 (4) 8892 5692 Obviously, XEmacs grows by 10M, then by 5M more, then shrinks by 10M, and finally removes to original state. All that memory comes from strings, on an XEmacs compiled without relocating allocator. To me it seems that things work as advertised in the manual. Does this mean we ought to turn off relalloc on Linux for 21.2?