similar to: [LLVMdev] Garbage collection

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

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 >

BTW, have you look at MMTk (http://jikesrvm.org/MMTk) ? This is the garbage collection library that underlies JikesRVM. It is a 'research-oriented' implementation, meaning that it has lots of configurable settings and plugin interfaces for implementing a broad range of collection algorithms. I was amused by the fact that "building a hybrid copying/mark-sweep collector" is

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

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) >> there can be replaceable policy components etc.

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

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

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 Feb 26, 2:18 pm, Ralf Schneider <li... at gestaltgeber.com> wrote: > Hello, > > 2009/2/26 Talin <viri... 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 > >

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

Hello, I want to add garbage collection support to a compiler with a llvm backend, using the shadow-stack compiler plugin. I read the GC tutorial in the LLVM documentation, and the paper about shadow-stacks. Im currently adding intrinsics to my generated llvm code, and trying to write code to connected it to my (existing) garbage collector library. Im not sure yet how everything fits together.

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

A while back there was a discussion thread about whether an accurate, concurrent garbage collector could be "generic" in the sense of being able to support multiple different languages efficiently. After having done some work on this, I now believe that this is the case - using C++ policy-based design principles, you can create a set of modules that represent different aspects of

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

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

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.

On Tuesday 16 June 2009 07:37:32 Talin wrote: > A while back there was a discussion thread about whether an accurate, > concurrent garbage collector could be "generic" in the sense of being > able to support multiple different languages efficiently. After having > done some work on this, I now believe that this is the case - using C++ > policy-based design principles, you

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

On 2009-02-26 18:22, Gabor Greif wrote: > On Feb 26, 2:18 pm, Ralf Schneider <li... at gestaltgeber.com> wrote: > >> Hello, >> >> 2009/2/26 Talin <viri... 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