[Openmcl-devel] sharing data between fortran and OpenMCL

[Gary Byers]

>
> > If a C-oriented memory-management system decided that relocation was
> > a good thing (offered benefits that outweighed its costs), how would
> > it implement such a scheme ?
>
> Like OpenMCL does today? The problem arises when you mix cross the
> boundary between stuff that wants regular memory addresses (the OS,
> other libraries, etc...) and stuff that thinks it can move memory
> around. This always seemed like one of the big PITA's in the old MacOS
> (Carbon too?).

When lisp GCs move memory around, they can be confident that they
correctly update all pointers to objects that move (failure to to this
is a GC bug.)  In order for a GC to have that confidence, it needs to
have reliable type information associated with each object (either at
compile time or, as is the case with most lisps, at run time); this
information has to be accurate enough to distinguish pointers from
non-pointers.

C implementations and runtime systems typically don't provide this
type information reliably.  (That information has to be entirely
reliable or it's useless from the point of view of a relocating GC.)

The point of this (rhetorical) question was that C programs don't
implement reliable relocating memory-management schemes because they
-can't-.  If you find yourself asking "why don't most lisps just do
memory management like C does?" ... well, that's a legitimate
question, but I think that it makes sense to ask it while being aware
that most lisps have options that C doesn't, and from my point of view
those other options are generally significantly better.

The easiest way to avoid problems with "stuff that thinks it can move
memory around" (these problems seem to be experienced by "stuff that
can't move memory around, and doesn't understand how anything else
can") is to not allow C code to point at lisp objects.  I think that
it's fair to say that OpenMCL does a pretty thorough job of
discouraging this.