Andrew C. Greenberg writes:

> Has anyone figured out a way to "Steal" a block of memory, either
> from squeak or the operating system, in order to set up a heap in
> which the primitive can deal with memory in the traditional
> malloc/free manner, or, in the alternative, a way to interact safely
> with the garbage collector that would be transparent to a malloc/free
> central C-language library?  For example, in Macland, would calls to
> NewPtr or NewHandle for a "private heap" or to substitute for
> malloc/free calls screw up the mainline?
>
> Clearly, such uses of external resources imply some need for care and
> use of the finalization routines.  However, it would be useful to be
> able to write squeak wrappers for the massive amount of useful
> existing Open Source libraries already out there.

A while back (in 2.2), I wrote some primitives that allowed me to allocate
and free external blocks of memory (using standard malloc and free).  I was
doing that in an attempt to create a generic mechanism for calling out to
external functions (using any of several well known calling
conventions)...which I was doing to implement a framework for abstracting OS
platform specifics.  I too needed to guarantee the location of the memory
wouldn't change underneath me.  I then created a nice Smalltalk class to
wrapper the blocks of external memory.  It was very elegant to have this
ability to manage external memory using Smalltalk objects.  The only thing
lacking was a finalization capability in 2.2 (so memory was never freed, but
I was waiting for others to add the finalization).

Getting the memory from the operating system is likely a lot safer and
easier that trying to "steal" it from Squeak heaps.  My guess is fiddling
with Squeak heaps would tricky and dangerous.

I stopped work on this stuff once I heard that pluggable primitives were
being added (sounds like I had a similar experience to Chris Reuter).  Has
anyone tried the pluggable primitives?  How well does it work?  Is good
support for marshaling objects to and from external data types?

Also, it appears to me that finalization is tied to weak references as in
VisualWorks.  I think the approach that others (Dophin for one) have taken
is much better.  An object can simply requests that it be sent #finalize
instead of GC reclaiming it's space (when no references remain for the
object).  It seems to me that this approach is much safer and cleaner
depending on the finalizable object having weak references (that send the
#finalize message).  Is it possible that Squeak could adopt this scheme?
Would not having an object table be a big obstacle to implementing such a
scheme?

- Stephen