[Ecls-list] alloc.d questions

[Vadim Konovalov]

On Sunday 18 May 2008 17:27:50 Juan Jose Garcia-Ripoll wrote:
> 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.

... just like it is done within ECL internally (e.g in 
make_base_string_copy) :

        x = cl_alloc_simple_base_string(len);
        memcpy(x->base_string.self, str, len);

wouldn't it be useful to add such a function to API?

> 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.

ok, that's fine.
so if I do not specify anything during ./configure then BOEHM will be 
activated?

>
> > 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.

This part I do not fully understand

first, looking into the
./src/gc/doc/gc.man
file makes me think that there *is* function GC_free

It is okay for internal to lisp memory to be garbage-collected using some 
sophisticated or not-so-sophisticated algorithm, but when using ECL from C 
sometimes I do know that I am not using that part of memory anymore and want 
for LISP to circulate it away, otherwise there could be memory leaks.

Also, for the sake of efficiency it could be useful to sometimes return 
memory, just for GC to have less troubles afterwards.

>
> > 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.

yes, this is an allocator, not GC, because Perl uses ref-counting, so 
different approach to memory.

Thank you for quick and useful reply :)

Vadim.