Hi John,

> I've been glancing at squeak startup time on the mac this 
> morning and have a few observations. Actually I have noticed on
> windows the images "SNAP' open, but take seconds on the mac and I'd  
> like to fix that...

Look at the logic which opens the image and actually reads the file. I
_have_ seen situations where it takes seconds on Windows and in these
situations it was always due to some search on the hard-disk for where
exactly the image file is, or (in the case of file system compression) the
reading itself.

> So what can we do?
> 
> a) Because of the magic of BSD malloc a saved Squeak 
> Macintosh image & Virtual machine usually ends up allocating
> the image at the  same location in the Virtual Memory address
> space, thus the offset is usually ZERO.   Therefore rewritting
> and fiddling with all the oops when they don't change when you
> add zero to them is really quite pointless. I propose to change
> Interpreter>>adjustFieldsAndClassOf: by: to return if the offset is  
> zero.

Sounds good.

> b) Rewritting all the oops to clear the Root bit, is also tedious,  
> especially since in my image of 251,816 objects I've only 1 object
> that has the root bit set. I propose to only clear and write 
> if the bit was set.

But how do we find out if a) only one object has it set and b) which one?

> c) After looking again at 251,816 objects we only find 360 compile  
> methods that match the criteria for flushing the session & address.
> Therefore I propose to remember those oops addresses (somewhere,  
> perhaps in an existing array temporarily) then spin through them
> after the oops have been adjusted by possible offset and  
> Root bit. If we exceed say 4096 objects we can just spin
> through the data again, then penalty for the extra work is minimal.

We could actually flush them when saving the image. There would be a small
penalty for having to look up the primitive again but I think that's
neglectable. This would bring the startup overhead down to zero.

> In doing all this I can reduce flushExternalPrimitives to zero, and  
> initializeObjectMemory to 6.9% removing 10% of the
> startup time for your standard 3.6 image.

Agreed. But there's one major gotcha here - if we do this, it'll break any
older images we're trying to run on any such VM. Any ideas how to work
around this without changing the image format?

Cheers,
  - Andreas