[Openmcl-devel] Proper Heap Memory Allocation

[Gary Byers]

At one point in the fairly recent past, I think that #_NewPtr on
OSX was implemented in terms of #_malloc.  That may not be true
(if I'm even correct in thinking that it was), and it would probably
not be a good idea to #_free things allocated via #_NewPtr or
#_DisposePtr thing allocated via #_malloc, but it may have once
been (accidentally) possible to do that

In the old (very old) days, #_NewPtr was in ROM and was a fundamental
part of the Mac Memory Manager; it could be invoked by executing
a 68K trap instruction.  (No, I don't remember which one.)  #_malloc
was something provided in a static C library by a C compiler vendor,
and if you went to the trouble of loading that library and FF-CALLing
malloc, you'd just wind up calling something layered on top of the
Mac Memory Manager, so it was reasonable to think of #_NewPtr as the
"primitive" and #_malloc as something esoteric and uninteresting.

In OpenMCL's case, it's kind of the other way around: #_malloc is
the primitive (part of the C library) and #_NewPtr is some legacy
thing provided as part of Carbon.  (The fact that there's a wrapper
- CCL::MALLOC - around #_malloc has to do with the fact that it
may need to be called very early in the bootstrapping process, before
foreign symbols can be looked up in shared libraries.  I think that
it may also have had to do with differences between the more-or-less
standard Unix/POSIX ways of doing things and VxWorks: OpenMCL was
originally something intended to be used in spacecraft and other
embedded systems and intended to run under VxWorks.)

>From OpenMCL's point of view, there's no real difference between
the results of (#_NewPtr 20) and the results of (#_malloc 20) or
(ccl::malloc 20); there may be a library function that could
tell the difference between the resulting blocks of memory, but
nothing in lisp's type system or runtime (GC) really knows or
cares where a MACPTR came from. (That's not quite true, since
the type system can recognize foreign classes and instances in
some cases (Cocoa).  There was a test to see if an address was
allocated via #_malloc as part of the Cocoa instance recognition
code, but that had more to do with "will we segfault if we look
at the first word of this address ?" than with "was this address
allocated via #_malloc or via something else ?")

On Mon, 27 Nov 2006, Brent Fulgham wrote:

> The MCL code for the OpenGL bindings makes a lot of use of (#_NewPtr
> [size]).  The UFFI library seems to translate this for OpenMCL as
> (ccl::malloc [size]).  I'm curious if (given the existance of the
> various macptr-related functions) it would be more 'proper' to use
> the macptr examples shown in the Documentation.  I guess the main
> advantage is having access to the lisp-tagging for updating the
> contents of the allocated block.  Are there any other key features
> I'm forgetting?
>
> Thanks,
>
> -Brent
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>