On Friday, February 1, 2002, at 08:37 , John M McIntosh wrote:

>> It would.  It has to, since it guarantees to return a chunk of 
>> sequential memory.  With such a large allocation, you will get 
>> zero-filled VM-pages.
>
> The mmap doesn't do anything until you access the pages, even a mention 
> of specialized zero fill logic,

'Zero filled' is how the lowest-level Mach routines return the 'memory' 
(really just address space).  This is the same for mmap() as for 
malloc().  All of that eventually comes down to the Mach function 
vm_allocate(), at least with anonymous maps...

>  (why wouldn't the VM zero fill logic be ok?, mind it might not grab 
> zero fill pages from the VM, rather do it for you then and now)

I don't know what you're saying here.


>> IOk, but I think I'd fiddle with it a bit, can't resist. I think the 
>> issue with providing one big chunk is that there is no cost to grow it 
>> to 512MB in Squeak's viewpoint, beyond a IGC every 4000 objects and if 
>> early tenuring occurs things will just fill up until you do a full GC 
>> once you run out of memory. Of course this is the worst case. The 
>> other choice is multiple full GCs to reach 512MB, and both these 
>> behaviors don't take into account what the VM will do to you.

Hmm...so implement the grow/shrink primitives essentially as NOPs, 
except that grow keeps track of the total size and fail at 512MB.

Marcel