A pretty big Squeak 4.3 image (nearly 8 GB)
Locked
A pretty big Squeak 4.3 image (nearly 8 GB)
 
|
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> 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 |
Re: A pretty big Squeak 4.3 image (nearly 8 GB)
|
|
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. - Bert - |
Re: A pretty big Squeak 4.3 image (nearly 8 GB)
|
|
In reply to this post by David T. Lewis
The coolest thing in your screenshot is this:
GCs full 103 totaling 103,207,042ms (6470.0% uptime) :-) Cheers, - Andreas On 1/14/2012 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> > > 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 > > > |
Re: A pretty big Squeak 4.3 image (nearly 8 GB)
|
|
I think the garbage collector may be using some of those high speed
neutrinos they located over at CERN ;) On Sat, Jan 14, 2012 at 05:23:25PM +0100, Andreas Raab wrote: > The coolest thing in your screenshot is this: > > GCs > full 103 totaling 103,207,042ms (6470.0% uptime) > > :-) > > Cheers, > - Andreas > > On 1/14/2012 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> > > > >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 > > > > > > > |
Re: A pretty big Squeak 4.3 image (nearly 8 GB)
|
|
In reply to this post by Bert Freudenberg
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. > > - Bert - > Good idea. Although I think I may need to save that project for another weekend. Dave |
Re: A pretty big Squeak 4.3 image (nearly 8 GB)
|
|
In reply to this post by Bert Freudenberg
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 |
Re: A pretty big Squeak 4.3 image (nearly 8 GB)
|
|
In reply to this post by David T. Lewis
The bartender says: we don't allow your kind in here.
Three FTL neutrinos walk into a bar and... On 1/14/12 9:34 AM, David T. Lewis wrote: > I think the garbage collector may be using some of those high speed > neutrinos they located over at CERN ;) > > On Sat, Jan 14, 2012 at 05:23:25PM +0100, Andreas Raab wrote: >> The coolest thing in your screenshot is this: >> >> GCs >> full 103 totaling 103,207,042ms (6470.0% uptime) >> >> :-) >> >> Cheers, >> - Andreas >> >> On 1/14/2012 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> >>> >>> 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 >>> >>> >>> > |
Antwort: Re: [squeak-dev] A pretty big Squeak 4.3 image (nearly 8 GB)
|
|
In reply to this post by David T. Lewis
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" <[hidden email]> An: The general-purpose Squeak developers list <[hidden email]>, Datum: 14.01.2012 21:48 Betreff: Re: [squeak-dev] A pretty big Squeak 4.3 image (nearly 8 GB) Gesendet von: [hidden email] 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 |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |