[Vm-dev] Question about memory allocation in VM

John M McIntosh johnmci at smalltalkconsulting.com
Tue May 4 16:22:43 UTC 2010


http://isqueak.org/sqAllocateMemory
http://isqueak.org/sqGrowMemoryBy
http://isqueak.org/sqShrinkMemoryBy
http://isqueak.org/sqMemoryExtraBytesLeft


That said, there are some issues which can defeat your vision of only working with part of the oops space

(a) I can't remember if this was removed, but at startup time we would iterate over the oops space confirming the setting of the root bit to 
fix a problem related to images created in mm what 1992?  This should not be a concern for closure based images since cleanup 
code at image save time fixed the issue and was introduced 10 or so years ago. 

(b) If you invoke allInstances it ends up iterating over the entire oops space, you'll find there are a dozen or so uses of that pattern in the image that are triggered via startup: 

(c) If your oops space start address isn't the same as it was when you saved the image, then the vm will iterate over all the oops readjusting the oops address to the start address offset.  Adjusting the platforms Virtual memory mapping system to place the oops space at 512MB helps avoid that. 

(d) The untuned GC will at some point invoke a full GC if you don't adjust it to bias against full GC activity. 

Given all that then for example for WikiServer for the iPhone where the operating system does not pre-load virtual memory mapped pages and where I've removed the desire to do allInstances and tuned the GC not to do a full GC at the drop of a hat. Then that results in a image that spans 1,932 4K pages (7,913,472), of which 806 pages (3,301,376) are swapped in from Flash, and 68 pages are modified to get the first wiki page visible.  This means 4,612,096 bytes are left in Flash, which on a iPhone 3G shaves 2 or 3 seconds off the startup time. 


On 2010-05-04, at 7:56 AM, Andreas Raab wrote:

> Look at memory mapping (mmap on unix, MapViewOfFile on Windows). What you're describing can be done simply by mapping and unmapping memory regions from an image file. I believe the iPhone does just that.
> 
> Cheers,
>  - Andreas
> 
> On 5/4/2010 6:12 AM, Mariano Martinez Peck wrote:
>> Sorry in advance if this was asked before...I have something in my mind
>> that says it was :(
>> 
>> I want to know how the memory is allocated between the VM and the OS.
>> For example, I know (actually, I think I know) that in Mac OS VM when
>> you run an image, the VM allocates (malloc() I guess) the same size at
>> least, of the image. So...I couple of questions:
>> 
>> 1) Is the same behavior for all OS ? If not, which happens with the rest?
>> 
>> 2) Where is such behavior defined? I don't think it is in VMMaker but in
>> the C support code of each VM. But where (.c and function anme) , any
>> quotes?
>> 
>> 3) In am working (actually yet thinking) a mechanism that will probably
>> use much less memory than the image. The idea is to swap to disk unused
>> objects. Then....the amount of memory I will use should be MUCH smaller
>> than the size of the image. So my question is, which changes should I do
>> to the VM so that it uses only THAT amount of memory and not the size of
>> the image.
>> 
>> As I said, suppose I have an image size (in disk) on 15MB. Suppose I run
>> that image, and then, as I swapped a lot of objects to disk, the actual
>> usage of memory is 3 MBs. So what I want is that OS only uses 3 MB and
>> not 15. Can I do that ?
>> 
>> Thanks a lot for answering to this newbie :)
>> 
>> Mariano

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




-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2445 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20100504/75619548/smime.bin


More information about the Vm-dev mailing list