[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