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 that 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 <[email protected]>: >> 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 <[email protected]> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ======================================================================== _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
