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. */
On 2010-10-22, at 6:24 AM, Ken Causey wrote:
I'm wondering what 'shrink' means in the following VM parameter comments:
"24 memory threshold above which shrinking object memory (rw)"
and
"32 number of shrink memory requests (read-only)"
My first thought is that a shrink represents Squeak release memory back to the operating system once it is no longer needed.
As I've mentioned before we are trying to reduce the RAM footprint of the www.squeak.org process and are watching various related figures.
We can see the value in VM parameter 32 increase, but while the value for parameter 3 (end of memory) goes down as you would expect, the operating system's view of the memory usage does not change.
Ken
-- =========================================================================== John M. McIntosh johnmci@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================