Pfff.
Now i really spent some time on Mac OS X memory management.
I did it for Wanda.  :)

(First: i don't know why you want to drop that nice mmap(2),
it's wonderful to test harddisk performance!
And if you want to support Apple, then you have to spend
some blood - right???
Implement a state machine, disallow mmap(2) if the file has
been written to.  Maybe i should spend some more hours and
try to find rules behind this??)

Situation is a follows.
Also here there are some nice sysctl(8) variables:

    hw.memsize: 2147483648
    hw.usermem = 1651843072
    vm.global_no_user_wire_amount: 67108864
    vm.global_user_wire_limit: 1811939328
    vm.user_wire_limit: 1811939328

That doesn't mean much though.
I've searched Apples developer pages with their unbelievable
stupid search engine and found
    developer.apple.com/library/mac/#documentation/Darwin/Conceptual/KernelProgramming/About/About.html

I've downloaded that as a PDF (upper right corner).
That doesn't mean much though.

So i finally did some tests using Nadeem's code snippet
from msg133677.  The largest top(1) i ever got was
    30477  python3      2.7       00:09.77 1    0    18    77    912M+  240K
but the system is unusable then.

I killed all tests which spent more than about three minutes first,
later i did so whenever 900M was not reached in top(1) output -
it seems to me that Apple's VM is not intelligent enough to detect
that it effectively has entered an endless loop!!!

The result of all that is that i think i can savely give you the
following advice for my MacBook (Mac OS X 10.6.7, but uname 10.7):

    x = bytearray(hw.usermem=1651843072   // 2)
responses in few fractions of a second almost regardless of system
load and gives that top(1) line:
    31369  python3      0.0       00:01.29 1    0    18    71    794M   240K

    x = bytearray(hw.user_wire_limit=1811939328   // 2)
responses in noticably more fractions of a second and gives the
following top(1) line:
   32899  python3      0.0       00:01.39 1    0    18    71    870M   240K

Note that the system seemed to handle the first case somewhat
easily, whereas the latter resulted in unresponsive window
switching etc. etc., so that it seems as if...

I don't know wether Python offers the available memory size values
somewhere, but note that Apple has moved sysctl(8) from /sbin
to /usr/sbin, which is a lie if you would ask me to express my
opinion.

Except for all this i don't understand this thread.
Isn't that bot the one for which haypo has noticed those
random failures???