Dynamic system memory use

John M McIntosh johnmci at smalltalkconsulting.com
Sat Feb 2 06:52:53 UTC 2002


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

I think this depend on the unix.

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

Mmm calloc gives you zero pages, malloc might not. I believe mmap 
anonymous does, but in anycase Squeak writtens zeros or nilobj onto 
free space.

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

Actually I have MADV_FREE, which means free the page and I don't need 
the contents back. If I refer to the page in the future, I *might* 
get the contents back, or I might get a zero filled page.

The real intent of doing this is to tell the VM those pages I really 
aren't interested in anymore so they are much more eligible for page 
stealing, when memory starts to get low. In FreeBSD and OS-X 
(apparently) saying MADV_FREE helps because the page isn't pageout 
(an i/o) if we want to steal it.

>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

On my freebsd system the man page for sbrk reads

The brk and sbrk functions are historical curiosities left over from 
earlier days before the advent of virtual memory management.

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



More information about the Squeak-dev mailing list