Andreas,

> How would [memory mapped files] work? And how would it
> integrate with the garbage collector?

I see two ways to use memory mapped files.

The first way is that although a MappedFile object is in memory, the actual
mapped storage (and thus the data) is outside the heap.  The MappedFile
encapsulates the data, and handles all access.  I don't believe that this
would effect the garbage collector, but it is not fully integrated into
Squeak, and a not altogether satisfying solution.

Hence the reason to find a better way to integrate memory mapped files.  And
this is really why I had asked earlier about disjoint heaps, because I see a
lot of open issues here.  Apparently, my inquiry was mis-understood as a
simple inquiry into garbage collection and memory management.

The following is basically me thinking outloud.  I'm sure that you know all
of it better than I do,  as you are intimately familiar with the internals
of Squeak.  In fact, in many of the interesting methods I was looking at,
your initials are found.

Squeak currently uses a single contiguous allocation.  This allocation is
subdivided internally by the VM, and managed within ObjectMemory.  The
Interpreter, itself, is is subclass of ObjectMemory.  As currently
implemented, there are parts of Squeak which rely upon the fact that there
is a single physical allocation.

Were Squeak to internally support multiple disjoint allocations, one way to
treat each mapped allocation might be as an independently managed heap.  I
say independent because just adding the ability to manage disjoint
allocations wouldn't be really interesting to me.  My reason for having the
disjoint allocations in the first place (to support memory mapped images)
implies that garbage collection should be intra-allocation, not
inter-allocation; objects created in an allocation stay in that allocation.

So my real inquiry, which I've expressed in the other thread, revolves
around how to bring such allocated areas into existance, how to remove them
from the system in mid-stream, and more importantly, how to "attach" and
"detach" objects that might be in them.

So, after that long-winded prologue, answer me this ...

Is there some way we might use reuse and extend the concepts found in
ImageSegment to allow segments to be mapped directly into separate heaps,
rather than read into/written from the main heap?  Obviously the use of
memory mapping is a specific case of loading a set of objects into a
separate allocation; however, it would be such use of memory mapped files
that would effectively mandate support for multiple allocations.

	--- Noel