Antwort: Re: [squeak-dev] A pretty big Squeak 4.3 image (nearly 8 GB)

Dietmar Schielke dietmar.schielke at data-experts.de
Wed Jan 18 11:06:51 UTC 2012


On Sat, Jan 14, 2012 at 05:18:23PM +0100, Bert Freudenberg wrote:
> For reducing startup time, it might be a good idea to use the mmap trick
> of suggesting a target address. That way no oop adjustment is necessary
> on startup because the object memory would likely have the same base 
address.
> Pages are loaded on demand, so it would take until the first full GC to
> load the whole image into memory. IIRC, John got that to work on iOS.

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.

Dietmar



Von:    "David T. Lewis" <lewis at mail.msen.com>
An:     The general-purpose Squeak developers list 
<squeak-dev at lists.squeakfoundation.org>, 
Datum:  14.01.2012 21:48
Betreff:        Re: [squeak-dev] A pretty big Squeak 4.3 image (nearly 8 
GB)
Gesendet von:   squeak-dev-bounces at lists.squeakfoundation.org



On Sat, Jan 14, 2012 at 05:18:23PM +0100, Bert Freudenberg wrote:
> On 14.01.2012, at 17:09, David T. Lewis wrote:
> 
> > Here is a screen shot of the Squeak 4.3 release image traced to 64-bit
> > object format, showing the image size after allocating a lot of object
> > memory. This is running on a box with 8GB of real memory, so the image
> > is about as large as can get on my computer.
> > 
> > <http://squeakvm.org/~lewis/squeak4.3-64bit/squeak64-big.png>
> 
> Yay!
> 
> > The image is fully functional and can be saved to disk and reloaded.
> > Monticello and other tools all work, and the image can be updated from
> > the trunk update stream as normal. Saving the image to disk and 
restarting
> > it are slow due the file size and amount of memory used, but the image
> > itself works fine. Garbage collection works, and overall the 
performance
> > remains good up to the point that the operating system is forced to 
start
> > page swapping (because the image is larger than available real memory
> > on this box).
> > 
> > Dave
> 
> For reducing startup time, it might be a good idea to use the mmap trick
> of suggesting a target address. That way no oop adjustment is necessary
> on startup because the object memory would likely have the same base 
address.
> Pages are loaded on demand, so it would take until the first full GC to
> load the whole image into memory. IIRC, John got that to work on iOS.
>

It's times like this that I really appreciate the Mantis bug tracker. The
background on John's mmap approach is recorded here:

 <http://bugs.squeak.org/view.php?id=7233>

Along with a link to the original discussions on vm-dev:

 <
http://lists.squeakfoundation.org/pipermail/vm-dev/2008-October/002054.html
>

And the related updates that were added to VMMaker in VMMaker-dtl.109.

... just in case anyone else is trying to keep track of this.

Dave
 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20120118/4d944253/attachment.htm


More information about the Squeak-dev mailing list