similar to: [LLVMdev] More Garbage Collection Questions

On 2007-09-15, at 18:01, Talin wrote: > I'm still (slowly) working on the project of creating a concurrent > garbage collector that works with LLVM. I want to ask a little bit > more about object tags and write barriers and so on. > > Let's start with the assumption that a particular language does not > use per-object type tags. The code generator knows the types

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: http://citeseer.ist.psu.edu/cache/papers/cs2/442/http:zSzzSzwww.cs.technion.ac.ilzSz~erezzSzPaperszSzms-sliding-views.pdf/an-on-the-fly.pdf > Write barriers are

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: > > http://citeseer.ist.psu.edu/cache/papers/cs2/442/ >

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

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 2008-04-27, at 21:29, Lane Schwartz wrote: > Hi guys, Hi Lane! This is a lot of questions. I'm not going to answer each individually, but will instead give general guidance to help you avoid the pain points… > I somehow need to inform the garbage collection runtime (my > copycollector.c) about my variables - specifically about gc roots. > So, after I get new memory

On Mon, Apr 21, 2008 at 8:13 PM, Gordon Henriksen <gordonhenriksen at mac.com> wrote: > > Hi Terence, > > > I think you're getting hung up on the details of the shadow stack collector. > The shadow stack is a GC that is possible within this framework, but of > course could be implemented without any special support. Its presence is > more misleading than anything

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

One of the more interesting subjects of conversation at the 2008 developer day was related to garbage collection. 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. (I am now involved in two different open-source projects both of which will eventually have a strong

On Sun, 2008-04-27 at 22:34 -0400, Gordon Henriksen wrote: > On 2008-04-27, at 21:29, Lane Schwartz wrote: > > Since this is a simple copying collector, the functions llvm_gc_read > > and llvm_gc_write won't really do much: > > void *llvm_gc_read(void *ObjPtr, void **FieldPtr) { return > > *FieldPtr; } > > void llvm_gc_write(void *V, void *ObjPtr, void

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 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) > there can be replaceable policy components etc. > 3. A couple of actual GC implementations built

Hello, 2009/2/26 Talin <viridia at gmail.com> > The IR-level intrinsics themselves don't much help you *write* a GC, so > much as to integrate one with LLVM. What is provided is essentially a > mechanism for walking the stack, and a means to insert read/write > barriers into the generated code, which together form a tiny fraction of > what it would take to design a

Hello All Does any know about some opensource multithread-compatible (or concurrent) garbage collector library, if possible suitable for LLVM? (I mean that I want several mutator threads; the collector can be stoptheworld or concurrent ....) H.Boehm's conservative GC is multithread compatible, but seems quite slow (allocation is about the time of a C malloc). And it is well known that

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 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 more direct support for GC is the > theory that there is no such thing as a

Gordon Henriksen wrote: > The intrinsics are entirely neutral to collector implementation, and > thus to threading. They could easily be used to implement reference > counting, for instance, which may or may not be implemented in a > threadsafe manner. However, as with your algorithm, reference counting > does not require code generator support, and so would not justify the

On Feb 26, 2009, at 12:25, 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. > > What you see in LLVM right now is really only the second step of the >

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 May 1, 2009, at 1:27 PM, Basile STARYNKEVITCH wrote: > Hello All > > Does any know about some opensource multithread-compatible (or > concurrent) garbage collector library, if possible suitable for LLVM? In fact, yes! http://code.google.com/p/scarcity/ -Chris