search for: copycollector

.... Currently, my frontend creates a normal LLVM IR of a program. Before adding GC, all variables are allocated by doing an alloca or malloc, then by doing a store of the alloca to the variable. Now let's assume I want to add a simple copying garbage collector. I write an implementation called copycollector.c (based on semispace.c) that implements the functions declared in GCInterface.h. When my frontend generates LLVM IR code for a program, it should also generate a call (early in the IR code) to llvm_gc_initialize. This function uses the system calloc to allocate two big blocks of memory, then stor...

Hi Terence, I think you're getting hung up on the details of the shadow stack collector. The shadow stack is a GC that is possible within this framework, but of course could be implemented without any special support. Its presence is more misleading than anything else. Taking a step back, the concepts are: llvm.gcroot instructs the code generator --> My GC needs to be able to

On 2008-04-27, at 21:29, Lane Schwartz wrote: > Hi guys, Hi Lane! This is a lot of questions. I'm not going to answer each individually, but will instead give general guidance to help you avoid the pain points… > I somehow need to inform the garbage collection runtime (my > copycollector.c) about my variables - specifically about gc roots. > So, after I get new memory using llvm_gc_initialize, I think I > should generate an @llvm.gcroot intrinsic. This is correct. Think of the llvm.gcroot intrinsic call as an annotation on a stack variable (an alloca). Like noalias, i...

On Apr 20, 2008, at 6:52 PM, Gordon Henriksen wrote: > On 2008-04-20, at 21:05, Terence Parr wrote: > >> On Apr 20, 2008, at 5:36 PM, Gordon Henriksen wrote: >> >>> Since the semispace heap doesn't actually work (it's an example, >>> at best), I suggest you simply copy the stack visitor into your >>> project; it's only a dozen lines of