woods at weird.com (Greg A. Woods) wrote:
> [ On Sunday, May 27, 2001 at 12:08:54 (-0500), Lex Spoon wrote: ]
> > Subject: Re: Multiple disjoint object memory in Smalltalk
> >
> > Let it not pass, that being able to use multiple heaps also allows for a
> > very easy-to-implement grow/shrink mechanism.  The current mechanism is
> > pretty hard to implement on Unix; actually, I don't really have a clue
> > how to do it at all without using Linux-specific extensions.
> 
> Since you don't say what Linux-only features you have in mind, won't
> mmap() do (maybe not with ideal efficiency, but...)?
> 

I made a stab at it based on mmap and munmap, but I ran into problems. 
Am I missing something?


An initial problem is that on many Unices the default is to mmap at the
*end* of the address space, so that there is no room to grow segments. 
My solution to this was to mmap as much as I could to begin with; grow
becomes trivial, and shrink involves an munmap followed by an mmap of
the end of the space -- thus releasing some pages of memory used while
hanging on to the relevant region of the address space.   A new problem
arises, though: occasionally the second mmap() fails and I end up with a
hole in the middle of the heap.  The rules that Linux (never mind any
other Unix) has for how much phony memory I can allocate are opaque to
me, so this error to happen randomly.  Maybe when this happens it would
work to deallocate pages at the end of the mmap-ed region, and to try
the mmap() again.  I dunno, it also might *not* work, and who knows what
will happen on the next Unix?  This approach really seems to push the
limits.

One Linux-specific feature of interest is mremap().  Or maybe not -- it
still seems to have problems.

Alternatively, an excellent Linux solution would be to replace malloc()
with something that allocates at the end of the address space.  Then,
the perfectly suited brk() is made available for Squeak's heap. 
Unfortunately, the "replace malloc" part is going to be a little
different on different Unices.


To contrast all of this discussion, if Squeak had an ObjectMemory that
could manage multiple chunks of memory, then you could use plain-old,
extremely-portable malloc() and free().


Lex