GC and Threading

[Bix]

Pascal J. Bourguignon writes:

> On 25/10/15 09:28, Bix wrote:
>> Hi,
>> just two quick question:
>> 1. Is it possible to disable the threading model and have multiple thread
>> to eval the code or have one ECL per thread?
> Not, yes, probably not.
> Check: https://common-lisp.net/project/ecl/manual/ch33.html
> reading cl_boot should be instructive.
>
> Being able to have several ECL instances per process could be 
> interesting: you would have multiple heaps, managed in different 
> threads, and some lisp data could be shared from one instance to another 
> (with some interesting consequences on teh garbage collection occuring 
> in each instance).  There would also be some fun with signals, if having 
> to deal with them between ecl and the host program wasn't enough fun 
> already.

Wondering if I can have multiple ECL instance that share nothing.
Signal are shared by definition, isn't ?

> Or alternatively, if you manage a single heap, why would you want to 
> have several instances?

true I almost convinced about a single heap.

>> 2. Can the garbage collector be disabled at all and have the memory
>> managed in a reference counting fashion?
>
> Ecl uses Boehm GC, so it's rather modular, and I guess you could link in 
> a stub library.
> You could add a dealloc function, and manage the memory manually. Good luck.

Yep, manage memory manually is impratical  and as you said circular
structures are one of the real problem.

>
>> I like to embed the ECL in my multithread application but I've got very
>> restrictive constrain about thread and memory:
>> * I can not spawn new thread but I've got concurrent thread to execute
>> ecl call.
> Ecl doesn't create any thread on its own. Only lisp programs may do so. 
> Do not use libraries that create threads and you'll be ok.

I played a bit with the boot option but I was unable to embed ECL and
not have at least one additional thread spaw by the GC or it was the
SIGNAL_HANDLING_THREAD ? However I always end up with at least two
thread ( in Linux  ), am I doing something wrong ?

>
>> * A component that bring GC would probably not be accepted
>
> Then I would suggest to resign and find a better job.
> Because, yes, you can disable the garbage collector,
> but I wouldn't wish that on my worst enemy.
>
>> and I'm
>> wondering if there is an alternative to that in ECL, or at least have
>> more control how/when GC will be run.
> BoehmGC doesn't seem to offer a lot of options there.
> It has the option to use a generational garbage collector.
>

I tried to build with --enable-gengc but I'm unable to build, I think
that is Issue #81.
I'm getting SegFault on "ecl_min compile"
I debugged the code and so far I just find out that this is a consistent
failure at cl_boot when it is doing this :
env->bindings_array = si_make_vector

in si_make_vector it is doing
ecl_array_allocself(x);

and in ecl_array_allocself
the sefault happen when we are doing the assignment

        case ecl_aet_object:
                x->array.self.t = alloc_pointerfull_memory(d);

I verified that before calling alloc_pointerfull_memory the assignment
work, but after the call the assignment raise the signal. I also
verified that x is not collected as it's flagged( I'm still double
checking )  and my debugger show
that x value does not change and still point to the same memory
address.

any cue?



I just noticed the cl_boot options allow INCREMENTAL_GC what the
difference between that one and the autoconf option --enable-gengc



>>
>> Can you point me out where to look in the source code to understand those
>> aspect of ECL?
> src/bdwgc contains a copy of the Boehm-Demers-Weiser Garbage Collector
> src/bdwgc/include/gc.h shows the API you could implement or stub to 
> disable it from the point of view of ecl.
> Notice that it's mostly GC_MALLOC, and there's a GC_FREE (never used in 
> ecl, you you would have to provide a lisp function calling it to free 
> the lisp objects).
>
>
> (And don't count on reference counting, most lisp data structures are 
> circular).



Kindest Regards
bix