Revision history for sqAllocateMemory
Additions:
See iPhone, resuse code
mmap the image file into memory at the 500MB boundary and at the end of the file mmap we allocate youngspace as an anonymous memory segment upto the setting in the Settings pane minus the file size. Note that pagable virtual memory is not activated on an iphone, so you are limited to a limit of about 64 mb on a first generation iphone 3g. Doing the mmap to the image file is much faster than mmap and a read, you also only end up with pages in memory that are touched, not all the pages.
Notes: You can choose between doing an mmap of the image file or a mmap of anonymous memory and reading the memory into it. For OS-X you should not mmap the image file because there are problems that configuration when you launch the image off an NFS server. Apparently the Virtual Memory file node pager doesn't like the NFS file driver...
Although this sound simple there is a fair amount of complications to handle the 64bit VM dealing with a 32bit image, since we have to remember the 64bit offset so that we calculate a proper 64bit address from the 32bit oops offset.
mmap the image file into memory at the 500MB boundary and at the end of the file mmap we allocate youngspace as an anonymous memory segment upto the setting in the Settings pane minus the file size. Note that pagable virtual memory is not activated on an iphone, so you are limited to a limit of about 64 mb on a first generation iphone 3g. Doing the mmap to the image file is much faster than mmap and a read, you also only end up with pages in memory that are touched, not all the pages.
Notes: You can choose between doing an mmap of the image file or a mmap of anonymous memory and reading the memory into it. For OS-X you should not mmap the image file because there are problems that configuration when you launch the image off an NFS server. Apparently the Virtual Memory file node pager doesn't like the NFS file driver...
Although this sound simple there is a fair amount of complications to handle the 64bit VM dealing with a 32bit image, since we have to remember the 64bit offset so that we calculate a proper 64bit address from the 32bit oops offset.
Deletions:
mmap the image file into memory at the 500MB boundary and at the end of the file mmap we allocate youngspace as an anonymous memory segment upto the setting in the Settings pane minus the file size. Note that pagable virtual memory is not activated on an iphone, so you are limited to a limit of about 64 mb on a first generation iphone 3g
Additions:
mmap the image file into memory at the 500MB boundary and at the end of the file mmap we allocate youngspace as an anonymous memory segment upto the setting in the Settings pane minus the file size. Note that pagable virtual memory is not activated on an iphone, so you are limited to a limit of about 64 mb on a first generation iphone 3g
*overallocateMemory
?? So why don't you use munmap and mmap and adjust the size of the region as it grows/shrinks. You can but you immediately find out mmap regions can overlap and ones allocated by the application are manged by the application so growing/shrinking them is disaster unless all the players know what is going on. Therefore the object memory is not expanded/shrunk by mmap.
Note the behavior of your unix virtual memory system plays a part here, if the memory pages are only allocated on usage then as on the macintosh (a BSD based system) you can allocate say 1GB and use just the first 64 MB, the fact the other nearly 1GB is not used does not impact performance. However if your squeak application runs away with recursive method calls then consuming that other 1GB until memory usage failure can take a long time. But if your virtual memory system actually wants to map the entire 1GB then you might need to consider growing/shrinking the actual allocated area.
*overallocateMemory
?? So why don't you use munmap and mmap and adjust the size of the region as it grows/shrinks. You can but you immediately find out mmap regions can overlap and ones allocated by the application are manged by the application so growing/shrinking them is disaster unless all the players know what is going on. Therefore the object memory is not expanded/shrunk by mmap.
Note the behavior of your unix virtual memory system plays a part here, if the memory pages are only allocated on usage then as on the macintosh (a BSD based system) you can allocate say 1GB and use just the first 64 MB, the fact the other nearly 1GB is not used does not impact performance. However if your squeak application runs away with recursive method calls then consuming that other 1GB until memory usage failure can take a long time. But if your virtual memory system actually wants to map the entire 1GB then you might need to consider growing/shrinking the actual allocated area.
Deletions:
?? So why don't you use mmap and adjust the size of the region as it grows/shrinks. You can but you immediately find out mmap regions can overlap and ones allocated by the application are manged by the application so growing/shrinking them is disaster unless all the players know what is going on. Therefore the object memory is not expanded/shrunk by mmap.
