[Ecls-list] alloc.d questions

Juan Jose Garcia-Ripoll jjgarcia at users.sourceforge.net
Sun May 18 17:27:50 UTC 2008


Hi Vadim,

On Sun, May 18, 2008 at 10:15 PM, Vadim Konovalov <vadrer at gmail.com> wrote:
> first, all functions to convert char* -> cl_object use strlen, as documented.
> This means no \0 char allowed within strings. How this could be avoided?

Use the string creation operators that specify a size and copy the
content of your string into the freshly allocated memory.

> More important question - what if I want to return memory back.
> There is a function dealloc, which takes a pointer to memory and integer, and
> the function itself frightened me a lot.

alloc.d is not used by default. That belongs to the old garbage
collector which is as old as my parents, so don't be scared. The code
that is used by default is alloc_2.d and the macros in external.h
which in turn call functions from the Boehm-Weiser garbage collector.

> Fourthly,  if defined GBC_BOEHM, then cl_dealloc dummied away?
> FWIW allocator should be improved, but I do not know how :)

There is no need for improvement. You were simply looking at the wrong
code. The Boehm-Weiser garbage collector is that: a garbage collector.
If your data is not referenced anywhere, it will be collected. There
are no "free" functions whatsoever.

> I do know that allocator within perl5 is very efficient and it could be used
> for reference. It's interface is quite siple and I even suceeded re-using
> perl5 allocator for Tcl and gained significant performance!

Is it a real conservative garbage collector? I am afraied we need more
than just an allocator. We need a garbage collector that can work with
circular structures, does not require  reference counting, can find
data where C code hides it, etc, etc.

> All in all, when not considering alloc.d, the overall impression is very good
> for the LISP novice like me :)

Please be not scared by the low level details like the memory
management. Things work. The B-W garbage collector is a very good one
and it will be fast enough for your needs. I doubt Perl has something
better. The next level of garbage collection is provided by CLISP or
SBCL, but memory management has so far been no problem with ECL.

Juanjo

-- 
Facultad de Fisicas, Universidad Complutense,
Ciudad Universitaria s/n Madrid 28040 (Spain)
http://juanjose.garciaripoll.googlepages.com




More information about the ecl-devel mailing list