Markus Kohler wrote:
At least on HP-UX (10.20) the man page says that sbrk can be used with negative arguments to shrink the process.
Right, but if more than one allocator used sbrk the shrinking isn't a possibility because one may end up deallocating memory used by another allocator. e.g. malloc implementations are often built above sbrk.
But what's nice about mmap is that it so quickly allocates the memory without ant paging. What I not yet understand is how munmap can be used to shrink or grow the memory.
mmap allocates memory in empty ranges of the address space, typically high addresses below the stack.
Or do you never grow ?
Previous to VisualWorks 2.5.2 oldSpace grew by on Unix, mallocing memory, and on Windows by reserving 512M bytes of address space and committing pages to it as required.
My understanding was that munmap releases the memory and one cannot get back the data that was stored in the released area.
That's right; the pages associated with the mapped address-range are freed and the range removed from the address space.
We added the ability to shrink memory in VW 2.5.2, and its now being used in real server applications.
Ah, I didn't know that. Was it advertised ?
Not very well. It was in the release notes. We've done a better job with VW 3.0.
_______________,,,^..^,,,_______________ Eliot Miranda, ParcPlace Aspect, ObjectShare
squeak-dev@lists.squeakfoundation.org