similar to: [LLVMdev] New ideas about how to improve garbage collection support

Hello, I've spent some time with the LLVM documentation and am beginning to grasp a few things, but I sometimes need very literal statements to actually understand things. My first question is about StackMaps: Is it true that llvm_gc_root_chain is an API? I've been trying to understand how exactly one accesses this structure and no where in the documentation does it mention this is a

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 Apr 28, 2008, at 14:28, Lane Schwartz wrote: > 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

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

On 2009-03-01, at 05:41, Mark Shannon wrote: > Gordon Henriksen wrote: > >>> The semantics of llvm.gcroot are vague: "At compile-time, the code >>> generator generates information to allow the runtime to find the >>> pointer at GC safe points." >>> >>> Vague, ill-specified interfaces are worse than none. >> >>

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 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 3/14/06, Chris Lattner <sabre at nondot.org> wrote: > > > How exactly does this indicate X is no longer live? Is this internal > > code-generator logic/magic? > > No, this just prevents the GC from accidentally thinking that *X is live > through that pointer. The collector cannot distinguish between > pointers that are out of scope from those that aren't,

Gordon Henriksen wrote: > > The "runtime interface" is a historical artifact. LLVM does not impose > a runtime library on its users. I wouldn't have a problem deleting all > mention of it, since LLVM does not impose a contract on the runtime. > Excellent, I found it somewhat unhelpful! >> The semantics of llvm.gcroot are vague: >> "At

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 Feb 27, 2009, at 12:56, Mark Shannon wrote: > Gordon Henriksen wrote: > >> The ultimate endgoal is to support schemes with still-lower >> execution overhead. The next step for LLVM GC would be elimination >> of the reload penalty for using GC intrinsics with a copying >> collector. This, again, requires that the code generator perform >> bookkeeping

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

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

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

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

LLVMers, Attached for your review: basic infrastructure for efficient garbage collectors. Only enough information is currently gathered to support the runtime I'm working with, and -print-gc is currently the only consumer of this information. All collector policies are presently controlled by constants. There are no regressions (on darwin-i686) if the feature is left disabled. If

On Jul 19, 2011, at 10:06 AM, Peter Lawrence wrote: > Talin, > how about having the front-end generate an llvm.safe.point() intrinsic call at > the desired safe points, and having the addresses of the GC roots (at that point, > can vary from call to call) be the parameters (with noescape attribute) to the intrinsic, > > IIUC currently the GC roots are tagged, and all

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

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

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