Comment by yvdriess
11 years ago
Finger crossed then that Azule can get a proper moving GC to work with LLVM then, until then a CL on LLVM (even Julia) are stuck with kinda bad GC.
I wonder why start from scratch for an LLVM backend, can't SBCL be used to generate LLVM code?
SBCL doesn't generate LLVM code. My primary goal was Common Lisp with C++ interoperation. It seemed easier at the time to start from the ECL Common Lisp code base and write a new C++ core and a Common Lisp interpreter that always interoperated with C++. As I wrote the compiler and expanded the system I maintained C++ interoperation all the time. There were a hundred problems that I had to discover and solve along the way to maintain a Common Lisp that interoperated with C++. You can get some level of interoperation between ECL and C++ up in a weekend but it won't work with C++ exceptions and RAII and there are dozens of other problems. In retrospect I don't think I would have gotten here starting from ECL because I never really understood the ECL code.
It wasn't from scratch, it was from ECL. And did you mean Azul?
Is the compacting garbage collector mentioned in the article not a proper moving GC? I am not familiar with it.
Yes, the Memory Pool System by Ravenbrook (https://www.ravenbrook.com/project/mps/) is a proper, moving garbage collector. It uses precise GC on the heap and conservative GC on the stack, as does the garbage collector in Steel Bank Common Lisp on x86 chips. I need it because I need my code to run on 100,000 CPU supercomputers with a controlled memory footprint to develop organic nano machines (seriously).
To be honest I was just kind of thinking "oh great another language implementation," before I read what you're actually doing and why you needed to create clasp. I appreciate the difficulty of writing precisely GC'd C/C++. It's pretty awesome that you were able to use clang to (I assume this is mainly what the analyzer does) track roots in C & C++ code.
Best of luck.
1 reply →