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