search for: gcwrite

Hi, I'm thinking out loud, please give me some feedback. Regarding llvm.gcread and llvm.gcwrite, wouldn't it be nicer if they are implemented as: llvm.gcread(sbyte** object, uint offset) llvm.gcwrite(sbyte* data, sbyte** object, uint offset) Where you also have the offset into the object. In this way the GC would know where the header of the object we are reading/writing to is. Also i...

On Mon, 19 Jul 2004, Tobias Nurmiranta wrote: > > Not currently. In the future this will definitely be improved. In > > particular, when the code generators are enhanced to provide more accurate > > mapping information for GC pointers (e.g. which registers contain > > pointers), we can do this. This is in the long term plans, but I suspect > > that performance will

...negative comments, but I would like to implement a generational collector for llvm, but I cannot do so in a portable way. So, here is a suggestion: Call the GC 'intrinsics' something else, "extinsics"?, and provide low-level intrinsics so that the GC calls, gcroot, gcread and gcwrite can be converted to GC-free LLVM code in a GC-lowering pass. IR+GC -> | GC Lowering pass | -> IR Rather than than the current. IR+GC -> | Backend lowering pass(es) | -> SelectionDAG Read and write barriers can already be written in llvm-IR. It is the marking of roots that is the pr...

On Wed, 21 Jul 2004, Tobias Nurmiranta wrote: > > Hi, I'm thinking out loud, please give me some feedback. > > Regarding llvm.gcread and llvm.gcwrite, wouldn't it be nicer if they are > implemented as: > > llvm.gcread(sbyte** object, uint offset) > llvm.gcwrite(sbyte* data, sbyte** object, uint offset) > > Where you also have the offset into the object. In this way the GC would > know where the header of the object we...

Hi, I realise this might be a bit controversial ;) Suppose I am writing a VM (such as VMKit), or a VM toolkit, and I want to add a generational GC. If I want to use the llvm.gcwrite intrinsic for my write barrier then I need to write a GC and then implement for each and *every* backend the gcwrite intrinsic for my write barrier. Now, if I don't use the intrinsic, I need to write my write barrier *once* in llvm IR. All I need is a nop intrinsic and ensure that all objec...

...itch to static stack maps later (with the requirement that your runtime be able to crawl the machine stack, which is out-of-scope for LLVM unless Talin makes some progress with his GC building blocks). • As you observe, your write barrier can be written in LLVM IR without the use of the llvm.gcwrite intrinsic if you so desire. Otherwise, you can perform the IR-to-IR transform to eliminate llvm.gcwrite using the performCustomLowering hook. What else is blocking you? > By the way, I think that adding a GC pointer type is an unnecessary > burden on the the back-ends, front-ends real...

...m/lib/VMCore/Verifier.cpp =================================================================== RCS file: /var/cvs/llvm/llvm/lib/VMCore/Verifier.cpp,v retrieving revision 1.115 diff -r1.115 Verifier.cpp 714,715c714,715 < case Intrinsic::gcread: NumArgs = 1; break; < case Intrinsic::gcwrite: NumArgs = 2; break; --- > case Intrinsic::gcread: NumArgs = 2; break; > case Intrinsic::gcwrite: NumArgs = 3; break; Index: llvm/runtime/GC/GCInterface.h =================================================================== RCS file: /var/cvs/llvm/llvm/runtime/GC/G...

Ok, that makes sense :). , Tobias On Wed, 21 Jul 2004, Chris Lattner wrote: > On Wed, 21 Jul 2004, Tobias Nurmiranta wrote: > > > void *llvm_gc_read(void *ObjPtr, void **FieldPtr) { > > > return *FieldPtr; > > > } > > > > Hm, but doesn't FieldPtr need to be calculated target-specific in those > > cases? > > For the field pointer, one

Browsing http://llvm.org/releases/2.5/docs/GarbageCollection.html#ocaml I stumbled across the sentence "...The ocaml collector does not use read or write barriers, so the user program may use load and store instead of llvm.gcread and llvm.gcwrite..." Which I believe is wrong as the ocaml collector does indeed use a write barrier (caml_modify). But maybe I misunderstood? Thanks, Benedikt Grundmann -- Calvin: I try to make everyone's day a little more surreal. (From Calvin & Hobbes)

Hello, i want to implement a common lisp subset using llvm for fun. This requires the use of a garbage collector. I read the docs, but many things are still unclear to me. 1. how are collectors supposed to find all living objects? there is llvm.gcroot for marking objects on the stack,but how do collectors crawl heap objects? I did not see a way to provide custom mark functions. Are

On Wed, 21 Jul 2004, Tobias Nurmiranta wrote: > > void *llvm_gc_read(void *ObjPtr, void **FieldPtr) { > > return *FieldPtr; > > } > > Hm, but doesn't FieldPtr need to be calculated target-specific in those > cases? For the field pointer, one could use the getelementptr instruction: %pairty = { sbyte, sbyte, int* } %pairPtr = ... %fieldptr = getelementptr

Mark Shannon wrote: > Jon Harrop wrote: >> On Thursday 26 February 2009 17:25:56 Chris Lattner wrote: >>> In my ideal world, this would be: >>> >>> 1. Subsystems [with clean interfaces] for thread management, >>> finalization, object model interactions, etc. >>> 2. Within different high-level designs (e.g. copying, mark/sweep, etc) >>>

...llvm/docs/GarbageCollection.html =================================================================== RCS file: /var/cvs/llvm/llvm/docs/GarbageCollection.html,v retrieving revision 1.6 diff -r1.6 GarbageCollection.html 237,238c237,238 < sbyte *%llvm.gcread(sbyte **)<br> < void %llvm.gcwrite(sbyte*, sbyte**) --- > sbyte *%llvm.gcread(sbyte *, sbyte **)<br> > void %llvm.gcwrite(sbyte*, sbyte*, sbyte**) 253c253,255 < second has the same semantics as a non-volatile LLVM store. At code generation --- > second has the same semantics as a non-volatile LLVM store, with...

...header part uses type tags, but the tail part is just a raw data buffer. From a GC perspective, it may be simplest to treat these as a single object, such that only the head part gets added to the work queue, and both are traced by the same tracer function. This implies, however, that when calling gcwrite(), the 'derived' pointer might be in a different memory block than the 'object' pointer, and may even be located at a negative offset from it. More questions to follow as I come up with them... -- -- Talin

...39;m not sure where such vociferous concern on this subject arises. All > the extant collector plugins I'm aware of operate in conjunction with > the target-independent framework and require exactly zero code within > each target backend. No collector plugins actually use gcread/gcwrite, since there are no generational collectors for llvm (as yet). According to the documentation http://llvm.org/docs/GarbageCollection.html#runtime The GC interface is "a work in progress" The semantics of llvm.gcroot are vague: "At compile-time, the code generator generates inform...

...> constraint on the values that the object pointer and the derived > pointer can take? There is no constraint on the relationship between the object and derived pointer parameters except as the plugin requires. I've made this explicit. There is currently no benefit to using gcread/gcwrite vs. coding in the barrier up front. > In particular, I am thinking about the case where you have an > object, such as an ArrayList, in which there are two separate non- > contiguous allocations: A fixed-length "header" part, and a variable- > length "tail" par...

...n 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 for GC pointers. On Feb 27, 2009, at 06:38, Mark Shannon wrote: > If I want to use the llvm.gcwrite intrinsic for my write barrier > then I need to write a GC and then implement for each and *every* > backend the gcwrite intrinsic for my write barrier. I'm not sure where such vociferous concern on this subject arises. All the extant collector plugins I'm aware of operate in c...

...uch vociferous concern on this subject arises. >> All the extant collector plugins I'm aware of operate in >> conjunction with the target-independent framework and require >> exactly zero code within each target backend. > > No collector plugins actually use gcread/gcwrite, since there are > no generational collectors for llvm (as yet). > > According to the documentation > http://llvm.org/docs/GarbageCollection.html#runtime > The GC interface is "a work in progress" The "runtime interface" is a historical artifact. LLVM does not...

...id the llvm intrinsics. Therefore, they are useless and should be removed. However, if the ability to traverse the stack is added to llvm then most of my objections to the intrinsics disappear. > • As you observe, your write barrier can be written in LLVM IR without > the use of the llvm.gcwrite intrinsic if you so desire. Otherwise, you > can perform the IR-to-IR transform to eliminate llvm.gcwrite using the > performCustomLowering hook. > > What else is blocking you? > Nothing, except the lack of stack traversal code ;) Once the portable stack-traversal code is ava...

...into ;; it, to indicate that the value is no longer live. store %Object* null, %Object** %X ... How exactly does this indicate X is no longer live? Is this internal code-generator logic/magic? The problem I'm currently unsure of, is how roots would affect refcounts. Should the gcread/gcwrite not be used with stack refs, etc? 1. If root refs are NOT included in the count, then objects of refcount 0 must be tracked in a list of scheduled deletions, but will be continually deferred until the root goes out of scope (the deletion list is filtered during a collection by the roots callback)....