similar to: [LLVMdev] Garbage Collection

Thanks for the example code. Its gives a good idea how the shadow stack works. But I have another question. Using the shadow stack is a nice and simple way to implement GC, but it might have a large runtime overhead per function call. Is there another way to preserve garbage specific information (gcroots) through the llvm optimizer and native code generator? This information could be used to

Couple of questions: 1. void llvm_gc_write(void *V, void *ObjPtr, void **FieldPtr) I haven't seen an adequate explanation of these, but I'm guessing: void *V: value being written to the field void *ObjPtr: current value of the field (ie. ObjPtr == *FieldPtr upon entry to llvm_gc_write) void **FieldPtr: address of the field being written 2. The current semispace collector includes

On Mon, 27 Feb 2006, Sandro Magi wrote: > Couple of questions: Ok, it's been a long while since I've worked on the GC stuff, but I'll try to help :) > 1. void llvm_gc_write(void *V, void *ObjPtr, void **FieldPtr) > > I haven't seen an adequate explanation of these, but I'm guessing: > void *V: value being written to the field > void *ObjPtr: current value

On 2/27/06, Chris Lattner <sabre at nondot.org> wrote: > > 1. void llvm_gc_write(void *V, void *ObjPtr, void **FieldPtr) > > > > I haven't seen an adequate explanation of these, but I'm guessing: > > void *V: value being written to the field > > void *ObjPtr: current value of the field (ie. ObjPtr == *FieldPtr > > upon entry to llvm_gc_write)

On Sep 2, 2007 5:31 AM, Gordon Henriksen <gordonhenriksen at mac.com> wrote: > Hi Talin, > > On Sep 2, 2007, at 04:54, Talin wrote: > > > I've been looking through the documentation (http://llvm.org/docs/ > > GarbageCollection.html) on how to implement a garbage collector for > > LLVM and there's a couple of things that I don't quite understand. >

On 2007-09-03, at 23:14, Talin wrote: > On Sep 2, 2007 5:31 AM, Gordon Henriksen <gordonhenriksen at mac.com> > wrote: > >> On Sep 2, 2007, at 04:54, Talin wrote: >> >>> I've been looking through the documentation (http://llvm.org/docs/ >>> GarbageCollection.html) on how to implement a garbage collector >>> for LLVM and there's a

On Apr 20, 2008, at 5:36 PM, Gordon Henriksen wrote: > The shadow stack walker is in the runtime directory with the semispace > heap example. The runtime directory is built to LLVM IR using llvm- > gcc. So it's skipped unless you configure llvm with llvm-gcc support. doh! That's how I missed the binary. thanks! > Since the semispace heap doesn't actually work (it's

Hello LLVM community, We have been experimenting with using LLVM IR as a target for a managed (dynamically typed) language via an AOT compiler (including a backend for ARM). One main challenge is getting the garbage collection right: We would like to be able to implement a moving collector. This requires us to a) find a precise set of root pointers and b) be able to rewrite those pointers after

Hi Terence, On 2008-04-20, at 20:08, Terence Parr wrote: > I've exhausted what I can do on my own to make a GC example bind > (usual googling, reading, playing, looking at source). I can't find > the shadow collector lib or perhaps the -l options needed to link my > sample (not even to point where I'm figuring out GC actually as I > can't link). The shadow

Couple of questions: 1. void llvm_gc_write(void *V, void *ObjPtr, void **FieldPtr) I haven't seen an adequate explanation of these, but I'm guessing: void *V: value being written to the field void *ObjPtr: current value of the field (ie. ObjPtr == *FieldPtr upon entry to llvm_gc_write) void **FieldPtr: address of the field being written 2. The current semispace collector includes

Hi, This is regarding the backend for garbage collection. My problem might be related to some strange memory fault created by my frontend, but I'll try here to get some feedback. For some strange reason I get segmentation fault in process_pointer in semispace.c (I've implemented a small collector, hopefully :). The fault occurs when I do: printf("process_root[0x%p] = 0x%p\n",

I'm in a group tasked with improving the GC of LLVM for a 421 project. We are having trouble getting started with the given SemiSpace collector. We found the string llvm_gc_initialize called from a single source file ./test/Regression/CodeGen/Generic/GC/alloc_loop.ll which we tried with the following... (showing LLVM checked out from cvs a few days ago, similar output with release 1.3) $

Hi Talin, On Sep 2, 2007, at 04:54, Talin wrote: > I've been looking through the documentation (http://llvm.org/docs/ > GarbageCollection.html) on how to implement a garbage collector for > LLVM and there's a couple of things that I don't quite understand. > Specifically, it says that when a stack variable goes out of scope, > you're supposed to assign a

I am using LLVM as the last stage of a compiler in order to easily produce a binary in native code. My compiler is implemented in Ocaml and has various layers of languages. In the last layer prior to LLVM, I have a value which has been converted to CPS, closure and hoisting (of functions). I am now trying to write a garbage collector for this language. The shadow stack is not suitable for me,

Hi all, I've been looking through the documentation (http://llvm.org/docs/GarbageCollection.html) on how to implement a garbage collector for LLVM and there's a couple of things that I don't quite understand. Specifically, it says that when a stack variable goes out of scope, you're supposed to assign a null value to it to indicate that the value is no longer live. What I

On Sun, Apr 27, 2008 at 9:34 PM, Gordon Henriksen <gordonhenriksen at mac.com> wrote: > As for the compiler plugin interface, I suggest you ignore it > initially and use the provided shadow-stack option for the time being. > The shadow stack generates significantly suboptimal code, but will let > you avoid writing some platform-specific code. Instead, simply copy > the

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 code or so. > > > Ok, copying; can't find ShadowStackEntry though.

On Tue, 26 Oct 2004, Tom Brown wrote: > I'm in a group tasked with improving the GC of LLVM for a 421 project. > We are having trouble getting started with the given SemiSpace > collector. > > We found the string llvm_gc_initialize called from a single source file > ./test/Regression/CodeGen/Generic/GC/alloc_loop.ll > which we tried with the following... (showing LLVM

On Mon, Apr 21, 2008 at 8:13 PM, Gordon Henriksen <gordonhenriksen at mac.com> wrote: > > 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

Now that the statepoint changes have landed, I wanted to start a discussion about what's next for GC support in LLVM. I'm going to sketch out a strawman proposal, but I'm not set on any of this. I mostly just want to draw interested parties out of the woodwork. :) Overall Direction: In the short term, my intent is to preserve the functionality of the existing code, but migrate