[Vm-dev] Re: [squeak-dev] What is meant by 'shrink' in the VM parameters?

Ken Causey ken at kencausey.com
Fri Oct 22 19:37:57 UTC 2010

On Fri, 2010-10-22 at 09:23 -0700, John M McIntosh wrote:
> It *would* give the memory back to the operating system. 
> But we don't anymore again read the following
> /* Note:
> * 
> *   The code allows memory to be overallocated; i.e., the initial
> *   block is reserved via mmap() and then the unused portion
> *   munmap()ped from the top end.  This is INHERENTLY DANGEROUS since
> *   malloc() may randomly map new memory in the block we "reserved"
> *   and subsequently unmap()ped.  Enabling this causes crashes in
> *   Croquet, which makes heavy use of the FFI and thus calls malloc()
> *   all over the place.
> *   
> *   For this reason, overallocateMemory is DISABLED by default.
> *   
> *   The upshot of all this is that Squeak will claim (and hold on to)
> *   ALL of the available virtual memory (or at least 75% of it) when
> *   it starts up.  If you can't live with that, use the -memory
> *   option to allocate a fixed size heap.
> */
> ===========================================================================
> John M. McIntosh <johnmci at smalltalkconsulting.com>   Twitter:  squeaker68882
> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
> ===========================================================================

OK, I should have replied to this aspect before, sorry about that.

I'm sure I'm not telling you anything here I just want to be clear we
are using the same terminology or that you at least understand what I'm

Note that under Linux there are two (really more than two, but two
major) memory figures.  One is Virtual Set Size (VSZ) and the other is
Resident Set Size (RSS).  It's nothing new that with Squeak on Linux if
you don't specify a -memory option it mmaps a gigabyte and this is
reflected in the VSZ, in my experience this value never changes, I'm not
sure what would happen if more than a gigabyte was actually addressed.
I'm not at all concerned about the VSZ value because this does not count
against true allocated RAM.  So I may be wrong but I believe what you
are referring to in VSZ and is irrelevant to us.

My problem instead is with RSS which represents an actual cost in used
RAM.  What I am expecting to see is that the RSS value I see is in some
way representative of the end of memory (vm parameter 3) figure.  This
is true initially, but as I've said before, when the end of memory drops
due to a GC, the RSS does not.

Setting the value of -memory is not going to help here.   That's simply
going to change the VSZ and set a lower ceiling, a limit on the RSS.
The reality is that the way the website is emulated there are short
periods of time in which it needs one or two hundred megabytes of
memory, but these times are short lived and this is evidence by the end
of memory figure dropping back to the normal base level.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part
Url : http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20101022/0e9dd600/attachment.pgp

More information about the Vm-dev mailing list