> 

> 
> For OS-X I mmap as anonymous 512MB. I then move the end of memory 
> location within those 512MB. If the memory isn't used it never gets 
> allocated. If the memory gets used, and is paged out to disk, *and* 
> we shrink the image size, well I just ignore it and have the virtual 
> memory manager leave those inactive pages sit on the disk. If we 
> grow, then the cost is mapping those pages in to be overwritten, but 
> the cost is no different than taking a page fault to get more memory 
> in a malloc situation.  (but see my note about madvise)
> 
> So mmap and forget about an ummap and mmap.

On Unix, this is equivalent to "-memory 512MB".  In fact, many malloc
implementations will use mmap to allocate such large chunks of memory.



Marcel Weiher <marcel at metaobject.com> wrote:
> 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.
> 

On Linux, at least, it does *not*.  I can malloc() more than I have swap
space for.  I believe this is common behavior among Unices.  Also, you
are not guaranteed to get zeroed pages.



Scott A Crosby <crosby at qwes.math.cmu.edu> wrote:
> On Thu, 31 Jan 2002, John M McIntosh wrote:
> 
> > I *think* linux is MADV_DONTNEED, but I'm not sure exactly what it
> > does (conflicting stories).
> >
> 
> It looks it. Searching the include files, I coauld only find this:


The name sounds good, but my reading of the man page suggests that this
only tells the memory system "I won't need it *soon*".  Thus, the memory
system will still try and preserve the contents of that memory.


> What I would recommend is looking at your common C allocator and find a
> way of reserving address space (is there a function to create a new heap
> in Linux?) and allocate/free continous portions from it (used to be
> called sbrk()).


sbrk() provides precisely the interface Squeak wants, *but*, there are
functions in the standard C library that already use it.  In particular,
malloc() does, and malloc() is used by system library functions, e.g.
fopen().


One possibility is to substitute a different malloc() library that
doesn't use sbrk(), and try to convince the system libraries to use your
substitution.  Feasible, but whenever I start thinking of spending that
much effort on it, I start wondering how hard it would really be to make
a segmented memory manager....


-Lex