GC and Threading
strabixbox at yahoo.com
Thu Nov 5 23:12:40 UTC 2015
Pascal J. Bourguignon writes:
> On 25/10/15 09:28, Bix wrote:
>> 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
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
and in ecl_array_allocself
the sefault happen when we are doing the assignment
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
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
More information about the ecl-devel