<tt><font size=2>On Sat, Jan 14, 2012 at 05:18:23PM +0100, Bert Freudenberg
wrote:</font></tt>
<br><tt><font size=2>> For reducing startup time, it might be a good
idea to use the mmap trick<br>
> of suggesting a target address. That way no oop adjustment is necessary<br>
> on startup because the object memory would likely have the same base
address.<br>
> Pages are loaded on demand, so it would take until the first full
GC to<br>
> load the whole image into memory. IIRC, John got that to work on iOS.<br>
</font></tt>
<br><tt><font size=2>I wonder if a (special) GC realy needs to load the
whole image in memory to collect garbage. If you assume what you made a
full gc before saving the image where shouldn't be any garbage in the image
on disk and the gc only has to scan through the in memory part of the image.
But then the VM/GC needs to know, which parts of the image are in memory.
So it gets complicated.</font></tt>
<br>
<br><tt><font size=2>Dietmar</font></tt>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">Von:
</font><font size=1 face="sans-serif">"David T. Lewis"
<lewis@mail.msen.com></font>
<br><font size=1 color=#5f5f5f face="sans-serif">An:
</font><font size=1 face="sans-serif">The general-purpose
Squeak developers list <squeak-dev@lists.squeakfoundation.org>, </font>
<br><font size=1 color=#5f5f5f face="sans-serif">Datum:
</font><font size=1 face="sans-serif">14.01.2012 21:48</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Betreff:
</font><font size=1 face="sans-serif">Re: [squeak-dev]
A pretty big Squeak 4.3 image (nearly 8 GB)</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Gesendet von:
</font><font size=1 face="sans-serif">squeak-dev-bounces@lists.squeakfoundation.org</font>
<br>
<hr noshade>
<br>
<br>
<br><tt><font size=2>On Sat, Jan 14, 2012 at 05:18:23PM +0100, Bert Freudenberg
wrote:<br>
> On 14.01.2012, at 17:09, David T. Lewis wrote:<br>
> <br>
> > Here is a screen shot of the Squeak 4.3 release image traced
to 64-bit<br>
> > object format, showing the image size after allocating a lot
of object<br>
> > memory. This is running on a box with 8GB of real memory, so
the image<br>
> > is about as large as can get on my computer.<br>
> > <br>
> > <</font></tt><a href="http://squeakvm.org/~lewis/squeak4.3-64bit/squeak64-big.png"><tt><font size=2>http://squeakvm.org/~lewis/squeak4.3-64bit/squeak64-big.png</font></tt></a><tt><font size=2>><br>
> <br>
> Yay!<br>
> <br>
> > The image is fully functional and can be saved to disk and reloaded.<br>
> > Monticello and other tools all work, and the image can be updated
from<br>
> > the trunk update stream as normal. Saving the image to disk and
restarting<br>
> > it are slow due the file size and amount of memory used, but
the image<br>
> > itself works fine. Garbage collection works, and overall the
performance<br>
> > remains good up to the point that the operating system is forced
to start<br>
> > page swapping (because the image is larger than available real
memory<br>
> > on this box).<br>
> > <br>
> > Dave<br>
> <br>
> For reducing startup time, it might be a good idea to use the mmap
trick<br>
> of suggesting a target address. That way no oop adjustment is necessary<br>
> on startup because the object memory would likely have the same base
address.<br>
> Pages are loaded on demand, so it would take until the first full
GC to<br>
> load the whole image into memory. IIRC, John got that to work on iOS.<br>
><br>
<br>
It's times like this that I really appreciate the Mantis bug tracker. The<br>
background on John's mmap approach is recorded here:<br>
<br>
<</font></tt><a href="http://bugs.squeak.org/view.php?id=7233"><tt><font size=2>http://bugs.squeak.org/view.php?id=7233</font></tt></a><tt><font size=2>><br>
<br>
Along with a link to the original discussions on vm-dev:<br>
<br>
<</font></tt><a href="http://lists.squeakfoundation.org/pipermail/vm-dev/2008-October/002054.html"><tt><font size=2>http://lists.squeakfoundation.org/pipermail/vm-dev/2008-October/002054.html</font></tt></a><tt><font size=2>><br>
<br>
And the related updates that were added to VMMaker in VMMaker-dtl.109.<br>
<br>
... just in case anyone else is trying to keep track of this.<br>
<br>
Dave<br>
<br>
<br>
</font></tt>
<br>