void * sqAllocateMemory(minHeapSize, desiredHeapSize)


Parms:
minHeapSize size we must allocate for storing oops space
desiredHeapSize size + growth we can allocate for storing oops space.

return: pointer to start of memory
From: Interpreter
Why:
Allocate memory for the oops storage area

Responsibility:
The platform must allocate a chunk of memory that is at least minHeapSize, but can be upwards of desiredHeapSize.
Historically minHeapSize is the size of the image, and desiredHeapSize is 100,000 bytes more, decisions made on a 4 MB macintosh...
Recall that the image is the GCed compacted oldspace. So we need to read that in, then allocate room for young space and growth.

By default this #define maps to malloc(desiredHeapSize)

MacIntosh
os-9/OSXCarbon
Uses mmap to allocate a chunk of memory upto the SqueakMaxHeapSize setting in info.plist

Pending is the concept of 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 SqueakMaxHeapSize setting in info.plist minus the file file.

However this means we must pass in the file path, and the header offset so we can mmap the entire file and return the memory location adjusted by the header offset. The reason for mmap at 500MB is to ensure a suggested address will work, lower values fail on os-x, with the suggested address then on other platforms that use mmap we can map in the oops and not have to swizzle each oops address at startup time since oops address are really memory addresess, thus with a swizzle change of 0 we don't need to swizzle.

Cocoa:
See iPhone, resuse code

iPhone
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.

Unix
if SQUEAK_MMAP is zero, then use the historical values (100,000+image size)
Otherwise use SQUEAK_MMAP or SQUEAK_MEMORY to decide how big mmap area should be.
SQUEAK_MMAP if non-zero is the upper limit of the mmap
If SQUEAK_MEMORY is set use that as a malloc value versus using mmap
*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.

Windows
Uses VirtualAlloc to reserve the desiredHeapSize, and again VirtualAlloc to commit to #define MAX_VIRTUAL_MEMORY 512*1024*1024
For grow/shink use VirtualAlloc and VirtualFree to adjust limits


BUGS
If you are not using a 32bit clean VM, (if you don't know what this means, you need to check with the squeak mailing list archives, and then use the most current version of VMMaker to build a VM).

Anyway if not using a 32bit clean VM then asking for 1GB of memory might push the memory allocation over or span the 2gb boundary. With non 32-bit clean VMS this instantly results in a VM crash because pointers go negative and you are hosed.

There are no comments on this page.
Valid XHTML :: Valid CSS: :: Powered by WikkaWiki