similar to: [LLVMdev] Accurate garbage collection support

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

By the way, it would be nice to have a small example in the documentation how to compile code to use the GC. A small code example and the flags to llvm to compile it. Thanks, Tobias On Mon, 24 May 2004, Chris Lattner wrote: > > I recently added initial support for accurate GC to LLVM, as described in > this document: > > http://llvm.cs.uiuc.edu/docs/GarbageCollection.html >

Hello! I'm looking at "Overview of available features" here: http://llvm.org/docs/GarbageCollection.html#collector-algos and can't understand something. First, does table header mean that there are already some GC's implemented besides "shadow stack"? E.g. can I just use them? Second, does row "JIT", "NO" mean that GC is not compatible with

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

Hi Victor, You can write your own GC or use other's GC with LLVM. What LLVM provides is a framework to generate a representation of objects locations in a method's frames. Right now, LLVM can emit the shadow stack (which dynamically updates the locations), or the ocaml format. If you have implemented a GC, you can parse the ocaml format to locate the objects. I think the web page needs

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

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've written a reference-counting garbage collector for LLVM, but I'm still unclear on a few things. The following piece of code that appears on http://llvm.cs.uiuc.edu/docs/GarbageCollection.html is unclear: ;; As the pointer goes out of scope, store a null value into ;; it, to indicate that the value is no longer live. store %Object* null, %Object** %X ... How exactly does

On 17/09/10 09:55, Pedro Ferreira wrote: > As I understand it, LLVM simply gives you support for garbage collectors > that you have to implement yourself and link into the final binary, > similar to what C's malloc does (it's a library call). The issue with > GC's is that they need to be provided info about the stack, thats where > LLVM's support comes in. Are there

As I understand it, LLVM simply gives you support for garbage collectors that you have to implement yourself and link into the final binary, similar to what C's malloc does (it's a library call). The issue with GC's is that they need to be provided info about the stack, thats where LLVM's support comes in. As far as I know, the garbage collector is linked into the final binary

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.

Gordon Henriksen wrote: > Hi Mark, > > I don't think anyone will dispute that it's easier to hack up a shadow > stack (or plug into a conservative collector) to get up and running > with GC. That is absolutely the route to go if portability trumps > performance. Why? LLVM is all about portability AND performance. > > If you review the mailing list history,

On Fri, 2010-09-17 at 12:16 +0100, David Given wrote: > On 17/09/10 09:55, Pedro Ferreira wrote: > > As I understand it, LLVM simply gives you support for garbage collectors > > that you have to implement yourself and link into the final binary, > > similar to what C's malloc does (it's a library call). The issue with > > GC's is that they need to be provided

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)

Again, sorry for the delay. :( On Thu, 9 Mar 2006, Sandro Magi wrote: > I've written a reference-counting garbage collector for LLVM, but I'm > still unclear on a few things. Cool! > The following piece of code that appears on > http://llvm.cs.uiuc.edu/docs/GarbageCollection.html is unclear: > > ;; As the pointer goes out of scope, store a null value into > ;;

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

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

Gordon Henriksen wrote: > On 2007-09-15, at 23:55, Talin wrote: > >> Gordon Henriksen wrote: >> >>> Can you be more specific the algorithm for which you need type >>> metadata in a write barrier? No algorithms I am aware of perform any >>> tracing from a write barrier. >> >> This one does: >> >>

Chris Lattner wrote: > On Feb 26, 2009, at 12:02 AM, Talin wrote: > >> With the increasing >> number of LLVM-based VMs and other projects, I suspect that the desire >> for more comprehensive garbage collection support in LLVM is only >> going >> to increase. >> > > Absolutely! > > >> Part of the reason why there isn't