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
|