>On Friday, February 1, 2002, at 10:22 , John M McIntosh wrote:
>
>>>Any particular reason for using mmap() and not just simply 
>>>malloc()? It will have the same semantics of just allocating 
>>>address-space.
>>
>>I started with mmap because of the linux work. Also I'm not sure if 
>>malloc would reserve all 512mb right away for me.
>
>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, (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)

>>Good question, when does the grow happen? Versus if you have 500MB 
>>of free space.
>
>I am not quite sure what you mean here.  There is no real growth, as 
>in realloc() or the like.  As soon as you touch a page (read or 
>write, it seems, although it could really delay until a write), the 
>kernel will provide real memory for it, but no sooner.


I was really referring to how squeak deals with this and if there is 
different logic depending on if the boundary for end of memory is 
*way* out there, or it must ask the VM to grow. Is there an extra GC 
event here? Some other logic that dictates grow is expensive and 
should be avoid before we do it? Mm I could look, but I'm failing 
back on my VW knowledge about memory policies that decide if growth 
should occur or not, and when that full GC event happens.

Ok I'll looked, it's not as if I don't have the source code eh.

It seems growth will occur if the estimated forward table size which 
uses the current free space is less than the total object count, on a 
full GC event. Or if space becomes low and we do an IGC and then a 
full GC and space is still low then we grow.

Shrinking occurs after a IGC or full GC if there is too much space around, 8MB.

>In the meantime, I think just setting a large memory size and 
>letting the VM subsystem handle it is probably fully adequate.
>
>Marcel

Ok, 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.


Right now of course I'm awaiting feedback from those OS-X users.

-- 
--
===========================================================================
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
===========================================================================