[Pharo-project] [Vm-dev] hampering the desire of the VM and image to visit every object at startup time (multiple times)

John M McIntosh johnmci at smalltalkconsulting.com
Tue Apr 14 19:38:15 UTC 2009

Well a PermSpace would be helpful since it would then avoid a GC which  
causes the header bits to change making all pages as
written, and if the pages are written then the virtual memory system  
can't free the page under stress.

However the real benefit here was that I actually never touch 6MB of  
objects, so they are never moved from Flash into
dynamic RAM. So I do not need to find 1,600 pages of ram to hold pages  
which the application doesn't need.
If I did an allInstances it would transverse PermSpace and bring all  
those 1600 pages into RAM, really want to avoid that.

For example if the iPhone receives a phone call, it starts up a daemon  
to display a dialog asking if you want to answer or ignore, memory for  
has to come from somewhere, or a double-click of the home key can  
bring up the iPod dialog prompt if the iPod audio app is running, again
pages have to come from somewhere.

With 700K of old objects, and about 5MB for young space it means the  
4.5MB of image objects that is faulted in but not written, can be  
freed since a page fault will
re-read them from the image file.

On 14-Apr-09, at 11:02 AM, Nicolas Cellier wrote:

> 2009/4/14 John M McIntosh <johnmci at smalltalkconsulting.com>:
>> Yes, so WikiServer  ( http://www.mobilewikiserver.com ) is an image
>> file of 10.5 MB.
>> As startup only 4.5 MB of OOPS memory is faulted in, and about 700K  
>> of
>> memory is altered, which reduces initial memory use by 6MB and  
>> reduces
>> the startup time by 3+ seconds.
>> Given the slow speed of the iPhone, and the fact I've a 64MB limit,
>> 6MB is a lot, and 3 seconds is welcome. Unfortunately a full GC will
>> fault all that 10.5 MB in, however by doing some GC tuning one
>> can avoid a full GC until things are quite stressed.
> Wouldn't a VW-like PermSpace reduce the burden?
> Nicolas

John M. McIntosh <johnmci at smalltalkconsulting.com>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com

More information about the Vm-dev mailing list