[Openmcl-devel] Allocate heap and call C question

[Gary Byers]

On Tue, 6 Jul 2004, Dan Knapp wrote:

>    I don't have a lot to say on this question, but...
>

>    If the language were to be extended, a more Lisp-like way would be to
> offer a  special form which allocates an object outside the Lisp heap... but
> with a lifetime determined lexically, ie, lasting only until the body of the
> form finishes executing.  Behind the scenes, the deallocation would be done
> by having unwind-protect call the appropriate function.

There are a variety of ways of allocating (lisp or foreign) objects
outside of the heap (typically on a stack) and asserting that those
objects have "dynamic extent".

>
>    I don't have an opinion yet on whether that would be a good thing;
> but it
> would certainly be better than using explicit deallocation.  You could
> implement it yourself, Andrew, fairly easily.

The trickier issue is with objects that have "indefinite extent"
(i.e., objects that exist as long as it's possible to reference them
and which we'd like to have deallocated automatically afterwards.)
For objects that are managed by the GC, this happens automatically;
for a "nailed down" (pinned ?) lisp object whose address can safely be
passed to foreign code, we sort of want to know when the object
becomes unreferenced, but since we don't want the GC to be "managing"
it we need to deallocate it ourselves.

This kind of mechanism is usually called "finalization" (OpenMCL calls
it "termination"), and it's certainly closer to being the right thing
than explicit deallocation would be.  It's a little more complicated
in the MAKE-HEAP-IVECTOR case, since we have the unusual case of two
objects (a lisp vector and an underlying MACPTR) sharing the same block
of foreign memory, and it's only really safe to deallocate that block
of memory if you're sure that both the pointer and the vector are about
to become garbage. Naive ways of keeping track of this make it hard
for those objects to ever become garbage.



>
> -- Dan Knapp
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>