[LLVMdev] Criticism of garbage collection support in LLVM
Chris Lattner
clattner at apple.com
Sat Jan 17 11:02:47 PST 2009
On Jan 17, 2009, at 10:18 AM, Mikhail Glushenkov wrote:
> This may be of interest:
>
> http://lhc-compiler.blogspot.com/2009/01/case-against-cllvm.html
>
> People implementing a new Haskell compiler explain why LLVM is an
> unsuitable target for them.
I find the article, and particularly the preceding one (http://lhc-compiler.blogspot.com/2009/01/what-is-lhc.html
) to be quite amusing. First, this article should be titled "the case
against C / LLVM 2.5", not against LLVM in general. There is nothing
in the design that prevents holding GC roots in registers, it is just
that noone has implemented support for it yet. It would actually be a
pretty simple hack to move the current GC implementation to use the
address space support, and say that all pointers into address space 42
are GC'd pointers (for example). This would work fine for languages
like haskell and java where the GC doesn't need static metadata
associated with the pointers.
I assert that the time and cost to implement an entirely new x86
backend (to start with?) is far more than would be required to add
this feature to LLVM (also note that their non-existent code generator
doesn't support this feature either). Further, the skill set required
to implement a very performant low-level code generator is very
different than that required to produce a performant implementation of
a high level language like Haskell.
In the end, I consider this to be a yet-another chapter in the
"functional language people don't like LLVM" saga. Whether it be
small improvements in LLVM tail calls or the fact that LLVM currently
pins GC roots to the stack, there is always a "good reason" to justify
writing something new, rather than learning and extend an existing
system. I'm sure that LLVM being written in C++ (as opposed to, say,
ocaml) is part of this as well.
In the end, I think that diversity is good in the compiler world, and
wish them the best. It's just not the approach I would take in
2009. ;-)
-Chris
More information about the llvm-dev
mailing list