[ENH][VM][FIX] faster image startup 3.7

John M McIntosh johnmci at smalltalkconsulting.com
Wed Dec 3 22:55:58 UTC 2003


Andreas had submitted a change set which went into 3.7.x which was a  
revision of my faster image startup logic.

  At OOPSLA I noted that totalObjectCount gets set to NULL/0 if we do  
not need to adjust the OOPS starting location. I had thought this was a  
problem, but in testing this morning I realized that although this  
number is  used to re-calculate a end of memory location to reserved  
space for forwarding blocks the fact that *most* VM uses a floating  
allocation for memory end, versus memory reserved, say 1GB for unix,  
means the issue becomes difficult to understand since the GC logic  
attempts to keep N MB free for youngSpace meaning about 500,000 entries  
are free, and of course on the first full GC the totoalObjectCount gets  
reset.

However to ensure behavior is the same as in the past, I'll suggest we  
just return a constant 300,000 which maps to roughly the objects found  
for the 3.7 image. Which I think *is* needed for VMs that have a  
constant memory size for image allocation.

  Perhaps a bit more study is needed I'm not quite sure about the  
relationships here between endOfMemory, memoryLimit, and the attempt to  
deal with reserving space for forward tables, and to set up free space  
size based on the targeted value.


On Aug 6, 2003, at 2:21 PM, Andreas Raab wrote:

> Hi John,
>
> You know what ... let's fix this problem for real. I've spent a bit of  
> time
> looking through what happens and I'm certain now that the root bit  
> problem
> only affects the active and the home context. If it were any different  
> we
> would have been crashing all the time as the original problem showed  
> quite
> nicely (it was _very_ reliable once you triggered a store into  
> activeCtx ;-)
>
> I've just been doing a little cleanup anyway (there is so much code
> duplication between primitiveSnapshot and primitiveSnapshotEmbedded)  
> so I'll
> just add the external prim flushing to it and clean out the root bit.  
> The
> root bit in the active context can act as the trigger for doing the  
> full
> cleanup otherwise we rely on a cleanly saved image. BTW, I have  
> checked it
> and the root bit of the active context _is_ set in all Squeak images  
> back to
> 1.1 ;-) so we won't have any nasty surprises.
>
> So do we have any other cleanup we'd like to do upon image save? This  
> is a
> good time to mention it.
>
> Cheers,
>   - Andreas--
======================================================================== 
===
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
======================================================================== 
===
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ImageStartupFix-JMM.1.cs.gz
Type: application/x-gzip
Size: 609 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20031203/33db33ee/ImageStartupFix-JMM.1.cs.bin


More information about the Squeak-dev mailing list