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