Hmm. Would it be possible to run the image on wince from where it sits in "storage" RAM, without copying it into "program" RAM? It seems a shame to use twice the space. I'm willing to give up the integrity of a snapshot after startup (as long as I can still make another snapshot). Can iPAQ/Linux Squeak do something clever in this regard?
thanks,
-C
-- Craig Latta composer and computer scientist craig.latta@netjam.org www.netjam.org crl@watson.ibm.com Smalltalkers do: [:it | All with: Class, (And love: it)]
Interesting question! I'm not certain about this, but does not WinCE support XIP (execute-in-place)? If so then it should be able to do what you say.
iPaq/Linux however, is a different story. Current images use JFFS2, which is a journalling flash file system. It treats the entire flash as a read-write filesystem (performing some voodoo to make sure that no one area of flash gets accessed more than others). This question was asked on the linux-Ipaq list and I believe the best answer was that Linux will only use memory as it is needed or accessed. It doesn't behave like XIP, but it's pretty efficient just the same.
If you're curious the discussion should be archived on www.handhelds.org in the 'ipaq' mailing list archive somewhere. ;)
On Thu, May 24, 2001 at 07:40:47PM -0700, Craig Latta wrote:
Hmm. Would it be possible to run the image on wince from where it sits in "storage" RAM, without copying it into "program" RAM? It seems a shame to use twice the space. I'm willing to give up the integrity of a snapshot after startup (as long as I can still make another snapshot). Can iPAQ/Linux Squeak do something clever in this regard?
thanks,
-C
-- Craig Latta composer and computer scientist craig.latta@netjam.org www.netjam.org crl@watson.ibm.com Smalltalkers do: [:it | All with: Class, (And love: it)]
Kevin,
I think you mis-understood Craig. He wasn't talking about the VM binary; he was talking about the image file. He wanted to know if we could use the image file directly from storage RAM without duplicating the contents into the heap.
does not WinCE support XIP (execute-in-place)?
On WinCE, you can just handle the image using the memory mapped file solution I outlined earlier.
For that matter, the same could be used to (optionally) handle other files if my suggestion to support memory mapped files is adopted.
iPaq/Linux however, is a different story. Current images use JFFS2 [...]
I raised the issue of mmap on handhelds.org, and got back the word from Jamey. The answer from Jamey is that:
"It depends on the filesystem in which you are opening the fd. If you're using ramfs, it's certainly just mapping the memory. If you're using cramfs or jffs2, then it is mapping a copy of the data because the data is kept compressed in flash but has to be presented uncompressed to the application. Even in this case, the use of mmap should reduce the number of times the data is copied."
Remember ... we are talking about the image file, not the VM binary.
Note: the use of a memory mapped image needs to be optional, since one might want to remove a CF chip containing the image, while still running Squeak.
--- Noel
Craig Latta Craig.Latta@NetJam.ORG pondered...
Hmm. Would it be possible to run the image on wince from where it sits in "storage" RAM, without copying it into "program" RAM? It seems a shame to use twice the space. I'm willing to give up the integrity of a snapshot after startup (as long as I can still make another snapshot). Can iPAQ/Linux Squeak do something clever in this regard?
Here's another slant on this. Suppose we always gzipped the images. This typically saves 50%. So we would have...
# images space now space w/ XIP (xeq in place) space w/gzipped images 1 2M M 1.5M 2 3M 2M 2M 3 4M 3M 2.5M N (n+1)M nM n(M/2) + M
This would seem to be a win for two or more images, doesn't depend on any details of XIP, and could benefit the entire Squeak universe. Hmm can you expand a gzip file as fast as you can read it from the disk?
I especially like what this would do for the stats of MiniSqueak with abandoned sources: An image of 327k decompiles 855k of source code, with an integrated development environment thrown in for free.
- Dan
Hi Dan--
Here's another slant on this. Suppose we always gzipped the images. This typically saves 50%... This would seem to be a win for two or more images, doesn't depend on any details of XIP, and could benefit the entire Squeak universe.
Yes, although I'd be happy just being able to use one image. :) In particular, I've got 32M and I want to run the latest image (12M). With the current system I'd need (while snapshotting, anyway) 36M (12M to store the current snapshot, 12M to run it, and 12M to make a new snapshot). Of course, I'd be willing to majorShrink the image first, but that doesn't seem to work in the latest system (one can only run majorShrink in the top project, which must be an MVC project, but the top project is a Morphic project).
With image compression I'd need 24M (6+12+6). With memory mapping I'd need 12M (but possibly giving up crash recovery in certain conditions). Either would be fine with me; it just seemed like less effort to get memory mapping going (I'll find out tomorrow, when I have more time to work on it). It also seems natural somehow to really treat a memory image like a memory image, without copying it at all on startup.
thanks,
-C
p.s.
I suspect that when I start storing multiple snapshots on the PDA it'll be because I've gone way past 32M (e.g., with a 1GB MicroDrive or somesuch). On "normal" machines with plentiful storage I'm not terribly concerned with minimizing snapshot size (yet :). But I think image compression would be great, as long as the time overhead isn't onerous.
-- Craig Latta composer and computer scientist craig.latta@netjam.org www.netjam.org crl@watson.ibm.com Smalltalkers do: [:it | All with: Class, (And love: it)]
Dan,
Would it be possible to run the image on wince from where it sits in "storage" RAM, without copying it into "program" RAM?
Suppose we always gzipped the images. This would seem to be a win for two or more images, doesn't depend on any
details of XIP ...
There seems to be a misunderstanding about what Craig is talking about, and why. It has nothing to do with XIP. It has to do with the way memory is managed under Windows CE, and effects only the heap allocated for the image.
A Windows CE device has a certain amount of memory, which is split between PROGRAM (or executable) memory, and STORAGE memory known as the object store. The split can be configured by the user, and is adjusted dynamically by Windows. There is no paging file; no backing store. If you exhaust your memory, you're done. Each application is allocated a 32 MB slot of address space from the overall address space in the system. That is the maximum amount of space that an application can use.
The 32 MB address space limitation might not viewed as an issue for Squeak, but available RAM is certainly an issue. Consider a PocketPC with 16 MB of RAM. Forget the fact that contacts, calendar, database, documents, AvantGo, ... every WinCE application consumes part of that memory. Just consider a Squeak image.
With the current scheme, the image consumes both storage, AND the executable RAM necessary for the run-time heap. That heap needs to be at least the size of the image plus room for growth; in practice, Squeak currently defaults to a 20 MB heap (STARTINGsqueakHeapMBytes), except in the case of the browser plug-in. A 20 MB heap won't (currently) fit on a 16 MB device, but we'll skip over that detail for now, and just focus on what happens to heap memory.
You have proposed compression. I like the idea, but not in this situation for two reasons. The first is a minor point: Windows CE already compresses files in the object store. So the gain from compressing the image(s) won't be as significant as it would be on a non-compressed file system. But compression would be a nice OPTION for non-compressed file systems, and for transfering images over the net.
The second, more serious, issue is that the critical resource is available RAM, not storage space, and compressed images disable the ability to properly manage RAM consumption.
So this gets us to the real point. When you allocate heap, the RAM consumed by that heap is dedicated, and limited by the amount of free RAM present in the device. I can move the image from the internal store to external (ATA) storage, but I can't do anything about the run-time heap allocation required. Compressing an image to zero (hyperbole), or moving it to CF, doesn't effect the amount of RAM consumed in the heap; all it does is effect the storage requirement, which isn't necessarily a critical resource.
So now consider the alternative, intended as an OPTION for suitable limited-memory devices: memory mapped files. A 6 MB image in the internal store takes up whatever compressed space in the object store is necessary to hold it. A 6 MB image stored externally takes up zero memory from my device. What about the heap? At run-time, the address space necessary to map that file is separate from the 32 MB allotment given to the program, and the RAM used to hold those pages is managed by the OS depending upon available memory. If you have enough available RAM, each page actually used will remain resident; if not, you can still run the image, with backing store provided by the image, itself. The amount of RAM consumed by the image heap is dynamic; governed by however much memory WinCE has available to hold the mapped pages, and the size of the working set. So if I allocate a 20 MB space, and map in a 6 MB image, the actual RAM used will grow and shrink as memory demands are placed on the system. And, in fact, I can allocate a 20 MB heap on a 16 MB device, if the mapped file resides on external storage of sufficient size.
The penalty for mapping on my iPAQ is roughly 0.2 milliseconds whenever WinCE needs to page in from the internal object store (the penalty is roughly 1 millisecond if the image is on CF). I have not run the timing tests under Linux.
On my iPAQ 3670, which has 64MB of RAM and Squeak on a CF, I might be inclined to use compressed image files. But that's the exception; most WinCE devices have far less memory, e.g.,
16 MB: iPAQ 3150; Jornada 520, 525, 540, 545 Casio EM-500 32 MB: iPAQ 3650; Jornada 547, 548, 710, 720; Casio E-115, E-125
Given that Squeak currently allocates 20 MB for the heap, even on 32 MB units a memory mapped image would be a winner. To reiterate, heap, not storage, is typically the critically limited resource on this class of platforms.
In fact, if one does have a lot of image files, and would see an important net win from compressing them in a file system, one might still want to use a mapped file, using a temporary file, for the heap.
--- Noel
Links:
Windows CE Memory Architecture http://msdn.microsoft.com/library/wcedoc/wcekern/prog_mem.htm
Using the [Windows CE] File System http://msdn.microsoft.com/library/wcedoc/wcefiles/objstore_3.htm
Minimizing the Memory Footprint of Your Windows CE-based Program (old article ... memory mapped files improved since WinCE 2.x) http://msdn.microsoft.com/library/periodic/period98/memory.htm
squeak-dev@lists.squeakfoundation.org