On Thursday, July 31, 2003, at 04:21  PM, Andreas Raab wrote:

> 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.

Yes I'm looking at that tonight.

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

Well it's not so much that only one object is set, it's if any object  
has the root bit set. I read them, but
then I can avoid a write back for it seems almost everyone. Hard to  
measure impact, but I'd think we'd save a few ms.

>
>> 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.

Yes, but that wouldn't work because we can't say where the image comes  
from, so I can' say they are clean. However what I'm
saving here is a pass thru all 251,816 objects again just to find the  
methods, remember I've already
looked at the oops to decide about the root bit, so the overhead of  
checking there is minimal. Also remember that
because I'm looking at megabytes of memory, we need to drag this in and  
out of L2 cache & main memory, which is
slow relatively speaking. So remembering which oops needs to be  
changed, then going back and cleaning
a few hundred up is a minor task.

>
>> 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?

See above. Don't think it will break anything, all we are doing is  
consolidating the tasks from two passes
over object memory to one pass

> Another thought: Is it possible that you're allocating the memory  
> lazily and
> the image loading process hits the exception handler upon first access  
> to
> each memory page? This might slow down things quite a bit. In the  
> Windows VM
> I am actually pre-allocating the memory needed for the image data  
> (plus some
> extra) before the read comes along to avoid this.

That I'm looking at, we do page all that memory in because we read the  
file into the first chunk of
it.

--
======================================================================== 
===
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
======================================================================== 
===