similar to: [LLVMdev] Improving Garbage Collection

On Mon, Jul 18, 2011 at 11:00 AM, Peter Lawrence <peterl95124 at sbcglobal.net>wrote: > Talin, > do you identify safe-points in the current or proposed llvm > scheme, and if so how, > or are they implicit as being at all call sites (which begs the question > what about leaves > in the call tree, how does GC get started at all in that case). > > The LLVM

Talin, how about having the front-end generate an llvm.safe.point () intrinsic call at the desired safe points, and having the addresses of the GC roots (at that point, can vary from call to call) be the parameters (with noescape attribute) to the intrinsic, IIUC currently the GC roots are tagged, and all analysis and transform optimizations have to special case these tagged

On Jul 19, 2011, at 10:06 AM, Peter Lawrence wrote: > Talin, > how about having the front-end generate an llvm.safe.point() intrinsic call at > the desired safe points, and having the addresses of the GC roots (at that point, > can vary from call to call) be the parameters (with noescape attribute) to the intrinsic, > > IIUC currently the GC roots are tagged, and all

On Wed, Jul 6, 2011 at 5:24 PM, Talin <viridia at gmail.com> wrote: > One approach would be to extend the current scheme to work with SSA values, > possibly using a new intrinsic. This is somewhat problematic because you > can't really have a 'do-nothing' function on SSA values - the result of the > function is always going to be a copy of the value, not the original

So - here's a really modest proposal: Based on Renato's suggestion, there is a way to associate arbitrary annotation data with any LLVM type. So what I would propose as a first step is to simply replace (or perhaps supplement) the current llvm.gcroot() feature with a type annotation. That is, LLVM would only support roots that are allocas, just it does today. The backend code would not

On Wed, Jul 6, 2011 at 3:51 PM, Kenneth Uildriks <kennethuil at gmail.com>wrote: > On Wed, Jul 6, 2011 at 5:24 PM, Talin <viridia at gmail.com> wrote: > > > One approach would be to extend the current scheme to work with SSA > values, > > possibly using a new intrinsic. This is somewhat problematic because you > > can't really have a 'do-nothing'

On 7/6/2011 6:24 PM, Talin wrote: > The LLVM code generators and analysis passes have a much more thorough > knowledge of SSA value lifetimes than frontends do, and therefore > could avoid spilling and reloading of values when it wasn't needed. Although this would indeed be nice, it is not done by similar platforms in practice. I have investigated [very] briefly into whether the

On Jul 6, 2011, at 3:24 PM, Talin wrote: > Overall Proposal: Support marking SSA values as roots (an evolutionary approach) > > My proposal consists of three rather significant changes to LLVM: > Allow frontends to mark SSA values - or even portions of SSA values - as stack roots. > For alloca roots, add a way to communicate to LLVM when a root goes out of scope. > Transfer the

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

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'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 of all objects, however, and can pass along that type information to

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

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

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

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

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 >

*Motivation & Abstract* It has been observed by a number of LLVM users that the current garbage collection framework requires frontends to generate complex and inefficient code. This is primarily due to the fact that only allocas can be stack roots - it is not possible to trace SSA values directly. Because of this limitation, a frontend wanting to support garbage collection has to manually

Dave, The way I see it there should be just one pass that implements deleting UB (maybe it would come to be called UBCE), and that one pass should have a command line option simply for the reason than all passes should have one. Peter Lawrence. > On Jul 26, 2017, at 10:02 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > > On Wed, Jul 26, 2017 at 9:23 PM