similar to: [LLVMdev] Accurate garbage collection

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

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

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

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

I recently added initial support for accurate GC to LLVM, as described in this document: http://llvm.cs.uiuc.edu/docs/GarbageCollection.html I've started implementing a trivial copying collector as a testcase for it, but it is not done yet. All code generators support identification of roots on the stack though. If you're interested in such things, I would really appreciate feedback on

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

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 >

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

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. If you review the mailing list history, I think you'll also find that developers who do care about performance have been disappointed with the impact

Hi all, I need to add thread-switching support to Unladen Swallow's JIT, and LLVM's safe point support looks like a good way to get code into all the right places. However, http://llvm.org/docs/GarbageCollection.html#collector-algos points out that there's no way to emit code at safe points yet, and there are no loop safe points at all. So I'll be trying to implement them. Is

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

Hi Rotem, Thank to you, and especially to Marina! The problem gone. I'm a bit interested, what is the reason it worked in Win7, and not in Win8. I've recently used Process Explorer to discover, that the call was to ntdll.dll, which in Win8 is loaded to the totally different address. Best regards, Victor Milovanov Moscow State University graduate student 2012/3/3 Rotem, Nadav

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

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

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

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