similar to: [LLVMdev] LLVM and managed languages

Hi Talin, I have some questions below. If these topics have already been discussed in earlier threads, kindly point me there. I'm aware of your GC proposal, but the rest is new to me. On Jul 1, 2011, at 11:05 AM, Talin wrote: > Garbage collection is still way too difficult. The biggest problem is the inability to track SSA values - it requires the frontend to generate very inefficient and

Hi Talin, I wrote HLVM: http://www.ffconsultancy.com/ocaml/hlvm/ The whole project took a few man months. HLVM provides an ML-like type system, unboxed tuples, discriminated unions, TCO, generic printing, C FFI, POSIX threads, mark-sweep GC and both JIT and standalone compilation. I wrote several (accurate) garbage collectors for it including a stop-the-world mark-sweep collector and they

Hi Talin, Interesting post, On Jul 1, 2011, at 11:05 AM, Talin wrote: > Garbage collection is still way too difficult. The biggest problem is the inability to track SSA values - it requires the > Light-weight coroutines would be a "nice to have", as would better concurrency primitives. These are things I could Tackling the "still way too difficult" and "should

Comments inline. On Sun, Dec 4, 2011 at 1:38 PM, Jon Harrop < jonathandeanharrop at googlemail.com> wrote: > Hi Talin, > > I wrote HLVM: > > http://www.ffconsultancy.com/ocaml/hlvm/ > > The whole project took a few man months. HLVM provides an ML-like type > system, unboxed tuples, discriminated unions, TCO, generic printing, C FFI, > POSIX threads, mark-sweep

*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

Talin wrote: > Jon wrote: > > Talin wrote: > > > Garbage collection is still way too difficult. > > > > This is completely untrue. > > I'm afraid I'm going to have to disagree... I failed to get my point across. You're still talking about the difficulty of using LLVM's GC support. I was talking about circumventing it. The shadow stack HLVM uses

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 Fri, Jul 01, 2011 at 11:05:44AM -0700, Talin said > So I've been using LLVM for about 4 years now, and I've posted a lot on this > list about specific issues. What I would like to do is step back for a > moment and give my "big picture" assessment of LLVM overall, particularly > with respect to developing a "managed" language like Java / C# or my own >

Hi Talin, On Fri, Feb 18, 2011 at 1:36 AM, Talin <viridia at gmail.com> wrote: > > Thinking about it even more, here's a short summary of what I would > propose: > > - *llvm.gc.value*(value, metadata) - marks an SSA value as a garbage > collection root. This remains in effect for the lifetime of the SSA value. > - *llvm.gc.declare*(alloca, metadata) - marks

Would you then agree with me that "LLVM's garbage collection facilities, _as described in the LLVM documentation_, are too difficult to use"? On Tue, Dec 6, 2011 at 3:40 AM, Jon Harrop < jonathandeanharrop at googlemail.com> wrote: > Talin wrote: > > Jon wrote: > > > Talin wrote: > > > > Garbage collection is still way too difficult. > >

On Thu, Feb 17, 2011 at 1:07 PM, Talin <viridia at gmail.com> wrote: > On Wed, Feb 16, 2011 at 4:51 PM, Talin <viridia at gmail.com> wrote: > >> I think I'm one of the few people actually using LLVM's support for >> garbage collection, and so far I've found it very difficult to generate code >> that uses llvm.gcroot() correctly. >> >> In

I think I'm one of the few people actually using LLVM's support for garbage collection, and so far I've found it very difficult to generate code that uses llvm.gcroot() correctly. In the current scheme, it is the frontend's responsibility to insure that any intermediate SSA values containing references to garbage collectible objects are copied to stack variables so that the GC

On Fri, Feb 18, 2011 at 1:05 AM, nicolas geoffray < nicolas.geoffray at gmail.com> wrote: > Hi Talin, > > On Fri, Feb 18, 2011 at 1:36 AM, Talin <viridia at gmail.com> wrote: >> >> Thinking about it even more, here's a short summary of what I would >> propose: >> >> - *llvm.gc.value*(value, metadata) - marks an SSA value as a garbage

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

Just a thought, but it would it make sense for garbage collection to be some sort of minimal debug information for potentially optimized code. Store just enough debug information to reconstruct call stacks and know where gc-roots are. Perhaps an approach like this could minimize the work required as it is shared between gc-support and debug information support. >From what I understand, DWARF

On Sun, Jul 3, 2011 at 9:07 AM, Chris Lattner <clattner at apple.com> wrote: > Hi Talin, > > Interesting post, > > On Jul 1, 2011, at 11:05 AM, Talin wrote: > > *Garbage collection is still way too difficult*. The biggest problem is > the inability to track SSA values - it requires the > > > *Light-weight coroutines* would be a "nice to have", as

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

Sorting through all of the discussions would be difficult, as the ideas have morphed over the years. Also, some of the discussion took place offline at various LLVM dev conferences. I can summarize the main points here: The biggest improvement in GC would be to allow SSA values to be declared as GC roots - currently only alloca values, that is, values in memory, can be GC roots. This means that

(This is a summary of the big long thread on llvm.gcroot, for those who didn't have time to read it.) I'm proposing the replacement of llvm.gcroot() with three new intrinsics: - *llvm.gc.declare*(alloca, meta). This intrinsic marks an alloca as a garbage collection root. It can occur anywhere within a function, and lasts either until the end of the function, or a until matching

On Wed, Feb 16, 2011 at 4:51 PM, Talin <viridia at gmail.com> wrote: > I think I'm one of the few people actually using LLVM's support for garbage > collection, and so far I've found it very difficult to generate code that > uses llvm.gcroot() correctly. > > In the current scheme, it is the frontend's responsibility to insure that > any intermediate SSA