similar to: [LLVMdev] Garbage Collection Project

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

> Firstly, rather than using a single 1 word pointer to represent a reference > I > chose to use 3 words including a pointer to the type and a pointer to the > value (as well as metadata). This allows typed nulls and that addresses an > important deficiency found in most other VMs including the CLR. Is Scarcity > able to handle such references or does its implementation of stack

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 Thursday 18 June 2009 12:28:57 Cory Nelson wrote: > I'm also curious what language uses this and why it is useful :) HLVM is intended to be a general-purpose VM rather than a particular language. > Also, things like this would make lock-free algorithms difficult or > impossible. True. Perhaps that is a good argument for providing both kinds. However, nulls are certainly more

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

> > That is similar to the approach I used, although HLVM provides a pointer directly to the type, saving you a single hop. I'm not so sure that is a very good reason, depending on your implementation data structures that are fundamental to the type system of the virtual machine use custom allocators so the extra hop carries little to no expense. I would not have considered it had I

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

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 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 Thu, Jun 18, 2009 at 3:14 AM, Granville Barnett<granvillebarnett at googlemail.com> wrote: > >> Firstly, rather than using a single 1 word pointer to represent a >> reference I >> chose to use 3 words including a pointer to the type and a pointer to the >> value (as well as metadata). This allows typed nulls and that addresses an >> important deficiency

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.

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

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 07.07.2011 08:31, Nate Fries wrote: > 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 >

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

*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

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

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

On Friday 27 February 2009 18:42:13 Gordon Henriksen wrote: > I agree this could be better. I think it would be prudent of you, > being aware of this problem, to structure your compiler so as to limit > the number of pieces of code which would be effected when you switch > to a copying collector. I think that would make my VM a lot more complicated for no clear practical gain. >