Squeak Image Size?

John M McIntosh johnmci at smalltalkconsulting.com
Wed Jan 8 21:00:03 UTC 2003


Well with the current mac VM you can only grow an image upto 512MB  
since it's
a hardcoded limit in the VM.

Once you ask for a GB or so then the osx Virtual Memory manager will
try to slot you in say the 2-3GB memory location, this causes the VM to
crash because a pointer is not a 32 bit integer which is an assumption  
made
by much of the code so add 4 to a signed integer which is > 2GB which is
really an address brings disaster.  Fixing this isn't trivial however  
no-one
yet has pushed for a solution either. Just look for all the users of an  
oops address and
change the variable type to pointer and ensure implicit type conversion  
isn't going on and any
math considers the effect of addition or subtraction from the oop  
address, that cascades into
more than a few places to check. I'm sure once could change SLANG to do  
this and attempt to
enforce so really the work is validating the changes to make Squeak  
32Bit clean. That and
reviewing all the plugins and platform specific code to ensure a  
developer who usually says
int oopsAddress isn't also committing a crime.

Also I've seen a fair amount of debate about how large a contiguous  
chunk of memory can your VM actually allocate for you.
Awhile back on os-x it was <2GB, might be different today and certainly  
different depending on the hosting OS, etc.

PS in my past experiences of dealing with multiple GM smalltalk images  
I can say
that garbage collection events become more interesting, when dealing  
with 10's of millions of
objects. It takes time even if the cpu is fast...

Mmm 64bit squeak, got to wonder, all those places where we add 4 to  
pseudo-addresses...


On Wednesday, January 8, 2003, at 12:30  PM, Tim Rowledge wrote:

> William Cole <jumpstart at csi.com> appears to have written:
>
>> Does anyone have any direct or anecdotal knowledge of how large a  
>> Squeak
>> image can get before running into memory constraints?
> Theoretically it can get to something like a halfgig. Practically...
> well lets just say that I have doubts that the garbage collection  
> regime
> is really useful for large amounts of dynamic data. I think it would
> need to be split up a little more to create more generations and
> possibly special spaces for things like large bitmaps, rarely touched
> methods etc.
> tim
>
> --  
> Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
> Useful random insult:- Couldn't balance a checkbook if Einstein helped.
>
>
>
>
--
======================================================================== 
===
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