realloc.. doesn’t?
Apparently, Darwin's implementation of realloc never frees memory if you ask for a smaller size. Python, and probably plenty of other software, assumes that it does, because that's how it behaves on the other platforms (at least Linux and OpenBSD). Oops!
Not that this matters: Python never frees any memory. This is an issue I am hoping to fix for the next version of Python.
Comment by Evan Jones — 2005-01-03 @ 2:56 pm
Well, of course, that’s a simplification too.
Comment by Michael Hudson — 2005-01-04 @ 10:32 am
You can’t make any assumptions about the behaviour of malloc and friends on various unixlike platforms. On many platforms, memory is freed (i.e. it can be re-malloced) but isn’t freed back to other processes, even when a whole page becomes free.
Comment by Doug Winter — 2005-01-05 @ 2:50 am
This takes me back a long way - back in, um, 1993 or so, when working on a very large X11 application, we ended up writing our own malloc library that *did* call sbrk() to reduce the size of the heap when the top of the heap was all on the free list. That gain was well worth the development and testing effort of a malloc replacement - I’m curious as to why pymalloc doesn’t do something similar (I’m sure there’ll be a good rationale somewhere).
Comment by Ben Last — 2005-01-05 @ 6:35 am
On Darwin, every process gets 4 gb process space and memory is mapped or unmapped in on demand by the kernel. It doesn’t have the sharing memory problem.
The only problem that I’m aware of is that it can’t resize a chunk of mapped memory, so realloc is a no-op.
Comment by Bob Ippolito — 2005-01-05 @ 10:21 am
The man page for sbrk in Darwin says the following at the top of the description (bold theirs):
The brk and sbrk functions are historical curiosities left over from earlier days before the advent of virtual memory management.
Comment by Bob Ippolito — 2005-01-05 @ 12:10 pm