4 ms·
Is there an explanation of the memory allocation used? There seem to be a GC (https://github.com/eriksvedang/Carp/blob/master/src/gc.c https://github.com/eriks
by junke 10y ago
Is there an explanation of the memory allocation used?
There seem to be a GC (https://github.com/eriksvedang/Carp/blob/master/src/gc.c https://github.com/eriksvedang/Carp/blob/master/src/gc.c), maybe used in the compiler only, coupled with lifetime analysis (https://github.com/eriksvedang/Carp/blob/8665a7f9a19d9347cc0f5785cee946fc25d1f645/lisp/calculate_lifetimes.carp https://github.com/eriksvedang/Carp/blob/8665a7f9a19d9347cc0...), which as far as I know is used once (https://github.com/eriksvedang/Carp/blob/6107e619d4f632acacef9c9d2cf808e06353158c/lisp/builder.carp#L177 https://github.com/eriksvedang/Carp/blob/6107e619d4f632acace...) in the compiler. This analysis seems tied to the manual "reset!" special form which apparently frees any existing data bound to a symbol. So, what happens when lifetime analysis cannot determine lifetime? what about stack-allocation? What should I worry about when programming in Carp w.r.t. memory?
- larsbrinkhoff 10y agoAs far as I understand from listening to Erik talk about Carp, there is an interactive interpreter which does use GC. In contrast, the compiler generates GC-free code.
- junke 10y agoThanks. Is this talk online? I can't find it.
- larsbrinkhoff 10y agoSorry, it was not recorded.
- tom_mellior 10y ago> In contrast, the compiler generates GC-free code. Yes, but the question was how it does that. Does it reject code where it cannot reliably detect lifetimes? Or does it generate code that just does not deallocate (i.e., that leaks) objects whose lifetime the compiler can't determine? Both of these are "GC-free"...
- rurban 10y agoVery simple. The compiler, written in lisp (with a GC) just generates C code, which is compiled and executed. Without any GC, it tracks the vars.
- PDoyle 10y agoNo, not simple. Analyzing an arbitrary lisp program to determine the lifetimes of all allocated structures reduces to the halting problem, so it's undecidable. You must either restrict the input program or tolerate some leaks.
- eudox 10y ago>arbitrary lisp program Well, Carp is a dialect of Lisp so it's free to impose whatever semantics it wants. It's not a dynamically-typed language (where it would indeed be impossible to statically manage memory).
- eriksvedang 10y agoYes, only the statically compiled code is GC free.
- rurban 10y agoVery simple. Each C allocated structure is allocated at the end of its C scope, and free'd at each end. Since the compiler knows the scope of each variable it's trivial. Harder is of course the ffi, which doesn't generally know if the extern call allocated something. This is undecidable for the compiler and he has to trust the user/program. Other lisps have an attribute for those externally malloc'd args.
- jahewson 10y agoNo, really no. First of all the values of the variables can escape their scope, e.g. when used as a return value. Secondly, some child scopes outlive their parents, e.g. closures. As the parent comment correctly points out you'd literally need to solve the halting problem to infer all the lifetimes for arbitrary code.