similar to: [LLVMdev] Garbage Collection

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

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

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

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 Thu, Jul 7, 2011 at 1:35 PM, Anderson, Todd A <todd.a.anderson at intel.com>wrote: > ** ** > > On Thu, Jul 7, 2011 at 10:55 AM, Anderson, Todd A < > todd.a.anderson at intel.com> wrote:**** > > For the past few years, my group in Intel Labs has been working on a > project similar to LLVM and C--, and perhaps our experience in handling > roots and stack

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 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 Thu, Jul 7, 2011 at 10:55 AM, Anderson, Todd A <todd.a.anderson at intel.com<mailto:todd.a.anderson at intel.com>> wrote: For the past few years, my group in Intel Labs has been working on a project similar to LLVM and C--, and perhaps our experience in handling roots and stack walking could be useful in deciding how LLVM should evolve in the GC area. Our project is called Pillar

Hi Talin, First of, thanks for generating such an interesting discussion on garbage collection! > For example, I mentioned the "stop the world" function - however since > LLVM defines no primitives for creating threads or synchronizing between > them, its hard to see how this could be part of LLVM proper. So LLVM should not be aware of "stop the world" stuff.

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

Hi, We are working on a project to improve garbage collection using pool allocation in llvm. Has anybody implemented any garbage collection algorithm in llvm? There is an incomplete semispace GC implementation in llvm. It will be of great help, if somebody has a complete GC implementation. Regards, Swarup. ************************************* Swarup Kumar Sahoo Thomas M. Siebel Center for

On Wed, Feb 16, 2011 at 4:51 PM, Talin <viridia at gmail.com> wrote: > I think I'm one of the few people actually using LLVM's support for garbage > collection, and so far I've found it very difficult to generate code that > uses llvm.gcroot() correctly. > > In the current scheme, it is the frontend's responsibility to insure that > any intermediate SSA

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 Oct 6, 2011, at 17:19, Yiannis Tsiouris wrote: > Hello all, > > I set: InitRoots = true; in my gc plugin as i want the roots to be > initialized to the "null" value. > Is there a way to define which value should be the initial one? For > example, i would like to initialize my roots to -5 (tagged, null value > for the GC in my runtime system) instead of 0. >

So - here's a really modest proposal: Based on Renato's suggestion, there is a way to associate arbitrary annotation data with any LLVM type. So what I would propose as a first step is to simply replace (or perhaps supplement) the current llvm.gcroot() feature with a type annotation. That is, LLVM would only support roots that are allocas, just it does today. The backend code would not