similar to: [LLVMdev] Garbage collection implementation

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

Hello, I want to add garbage collection support to a compiler with a llvm backend, using the shadow-stack compiler plugin. I read the GC tutorial in the LLVM documentation, and the paper about shadow-stacks. Im currently adding intrinsics to my generated llvm code, and trying to write code to connected it to my (existing) garbage collector library. Im not sure yet how everything fits together.

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 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 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

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

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

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

Gordon Henriksen wrote: > The intrinsics are entirely neutral to collector implementation, and > thus to threading. They could easily be used to implement reference > counting, for instance, which may or may not be implemented in a > threadsafe manner. However, as with your algorithm, reference counting > does not require code generator support, and so would not justify the

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) $

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

If I recall correctly, the garbage collector interface consists mostly of some fuctions that one calls during execution to notify the collector about a GC root. There's one othr thing that's needed if you do JIT compilation: you have to garbage-collect the generated code. This means that the collector must be able to find where the pointers are in the generated code together with

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

Talin, do you identify safe-points in the current or proposed llvm scheme, and if so how, or are they implicit as being at all call sites (which begs the question what about leaves in the call tree, how does GC get started at all in that case). Peter Lawrence.

Howdy do LLVM folks! 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). Not sure this IR is correct but here is what I've been playing

I'm still (slowly) working on the project of creating a concurrent garbage collector that works with LLVM. I want to ask a little bit more about object tags and write barriers and so on. Let's start with the assumption that a particular language does not use per-object type tags. The code generator knows the types of all objects, however, and can pass along that type information to

Hi, As far as I understand now, only stack variables can be marked as gc roots. Our compiler however can also generate roots that are not necessarily on the stack. We can solve this by putting it on the stack anyway. So far so good. The problem is that we want to implement some sort of copying garbage collector. In this case, the roots on the stack must be updated. However, if this root

On 2007-09-15, at 18:01, Talin wrote: > I'm still (slowly) working on the project of creating a concurrent > garbage collector that works with LLVM. I want to ask a little bit > more about object tags and write barriers and so on. > > Let's start with the assumption that a particular language does not > use per-object type tags. The code generator knows the types

Yes, the JIT implementation was recently improved to add support for this. There's nothing you need to do (or emit). The JIT implementation will automatically collect memory that is not being used. See the JITMemoryManager in lib/ExecutionEngine/JIT/JITEmitter.cpp for details. Reid. On Sun, 2006-08-06 at 14:30 -0400, Hendrik Boom wrote: > If I recall correctly, the garbage collector

This is really nice, it supports my (somewhere-in-the-future) work with llvm, garbage collection and persistent memories. Can/Will one garbage collector be used for several different front-end languages? If so, don't you have to put functionality to traverse objects in the language implementation, since the internal representation depends on what language that is compiled. One language's