[Vm-dev] definition of vm parameter 25?

John McIntosh johnmci at smalltalkconsulting.com
Wed Oct 16 17:52:10 UTC 2013

10/6/04  How memory is allocated

9/21/02  Memory allocation on the Mac?

As this topic is a good twelve years old you'll have to rely on my foggy

I recall it coming from the windows vm. The intent was to allocate memory
from the VM and ensure parm 25 was at least free, later on a check after a
full GC if we have free memory > parm 24 free we release memory back to the
operating system.  However since Squeak allocates a contiguous check of
memory versus segments this is tricky for some operating systems.

At the time > 10 years back I choose for the mac vm just to move pointers
around versus unmapping.
Ian did implement a unix unmapping, but later withdrew it some unix flavors
had buggy implementations of unmapping

Note in some os-x/ios memory allocation code I opt via a suggestion from
David Pennell to mmap the image, then mmap free space. Which leads to some
interesting behaviour on IOS. Some N milliseonds shaved off startup time on
199x era macs, but then exposed the bug in OS-X NFS drivers if you attempt
to mmap a file on a NFS drive. Might be fixed now?

As my iOS images were always setup read only, I never pursued setting the
mmap to shared and then confirming a virtual memory manager flush/sync
would in fact write out all the changed pages and newly allocated free
pages to the original file, as that required copying the base image from
the app readonly resource directory to the read/write directory and on the
iPhone 3G that took seconds..

On Wed, Oct 16, 2013 at 1:06 PM, Eliot Miranda <eliot.miranda at gmail.com>wrote:

> Hi All,
>     can anyone give me a specification of parameter 25's behaviour?  25 is
> the grow headroom:
>         "25 memory headroom when growing object memory (read-write)"
> what does this mean?  That growth should be at least this much?  That
> growth should be in multiples of this?  That growth should not be done if
> free memory exceeds this?  Or...?
> --
> best,
> Eliot

John M. McIntosh <johnmci at smalltalkconsulting.com>
Corporate Smalltalk Consulting Ltd. Twitter: squeaker68882
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20131016/43650cbb/attachment-0001.htm

More information about the Vm-dev mailing list