memory allocation on commandline

John Maloney JohnMaloney at earthlink.net
Sun Jan 19 13:35:27 UTC 2003


Tim,

What's in that tea you're drinking? :-> :->

I'm sure that the Mac VM was *always* a total memory setup, but you may
have interpreted things differently when you did the Acorn port.

On machines with virtual memory--or so much real memory than you don't
need to worry about it--specifying the amount of free memory that you
want after the image is installed may make sense. But implementing it
could be a bit tricky, since a number of things are done at startup time that
expand the storage requirements. For example, the Display is allocated to
be the size of the window, and at 16-bit or 32-bit depths that adds many
megabytes. In addition, Form objects are compressed ("hibernated") before
the image is saved, and they get expanded on demand as you use
them. Thus, the amount of space a given image on the disk will need
when it is fired up is hard to predict. You basically have to run the image
to find out.

I think the new mechanism to automatically grow the object heap has
made this issue moot on platforms that have the proper virtual memory
model. On other platforms, my personal inclination is to retain the
current behavior of specifying the total memory, partly just because
it's what I'm used to and expect.

Andreas, when did the Windows VM stop looking at the -memory
switch? Was it before the 3.2 VM?

	-- John


Re:
>> Ian and Andreas will probably have opinions about the *nix and Win32
>> VM's, but I seem to recall that "-memory" used to mean the total memory
>> allocation on these platforms as well, up through 2.8 at least...
>It's wierd; my code and the variable names I used clearly imply the idea
>of headroom rather than total room, but the oldest sources I have only
>go back to 2.6 and that is indeed a total-room setup. Am I imagining
>things? Could be... too many cups of tea can do that to you. I can
>easily make it so that it works 'my' way on Acorns but I am interested
>in how people feel it ought to work as well.
>
>tim




More information about the Squeak-dev mailing list