[LLVMdev] Garbage collection

[Gordon Henriksen]

On Feb 26, 2009, at 21:17, Jon Harrop wrote:

> For example, the IR I am generating shares pointers read from the  
> heap even across function calls. That is built on the assumption  
> that the pointers are immutable and, therefore, that the GC is non- 
> moving. [...]
>
> If you wanted to add a copying GC to my VM you would probably  
> replace every lookup of the IR register with a lookup of the code to  
> reload it, generating a lot of redundant loads that would greatly  
> degrade performance so you would rely upon LLVM's optimization  
> passes to clean it up again. However, I bet they do not have enough  
> information to recover all of the lost performance. So there is a  
> fundamental conflict here where a simple GC design decision has a  
> drastic effect on the IR generator.


I agree this could be better. I think it would be prudent of you,  
being aware of this problem, to structure your compiler so as to limit  
the number of pieces of code which would be effected when you switch  
to a copying collector. I think such structure in the back-end for  
your compiler addresses the same needs as would be by your "slightly  
less low-level virtual machine."

I order to address it thoroughly, the LLVM GC infrastructure needs to  
track register roots so that it doesn't need to conservatively reload  
from the stack so frequently. This would likely entail a change to the  
IR (either a 'GC' address space as Chris suggests, a new intrinsic to  
'tag' a value as a GC pointer, or even a change to the Type  
hierarchy)--another reason to isolate GC-handling code in your compiler.

— Gordon