> LLVM currently lacks working examples demonstrating the use of garbage > collection...Hello, if anybody has time, I would recommend putting a big disclaimer at the top of the garbage collection page that explains that, for the most part, garbage collection falls outside of LLVM's domain. Right now LLVM advertises itself as "supporting garbage collecting", which although true, somewhat misses the point. LLVM just happens to not get in the way. The only real garbage collection feature that LLVM provides is accurate stack walking, and even that can be implemented separately through a shadow stack. That the documentation contains llvm.gc intrinsics is a bit of a red herring. You end up doing most of the work yourself. To illustrate, for our own LLVM work we implemented garbage collecting completely without using any LLVM primitives. Granted, we're a conservative collector right now, and once we go accurate we'll investigate the stack-walking. Just a head's up from an beginner/intermediate LLVM programmer. The current state of the GC documentation makes it seem as if: "you just connect the GC and it works". I'm sure that isn't the intention, but judging from some of the posts on this mailing lists over the past months, this seems to be a common expectation. Two cents... Jaap Suter
On Tuesday 05 February 2008 17:22:36 Jaap Suter wrote:> if anybody has time, I would recommend putting a big disclaimer at the top > of the garbage collection page that explains that, for the most part, > garbage collection falls outside of LLVM's domain.Yes. However, I think it would also be extremely productive to have working examples showcasing what LLVM does provide, e.g. with trivial GC and exception mechanisms. If nothing else, this would at least prove that they really do work. :-)> Just a head's up from an beginner/intermediate LLVM programmer. The current > state of the GC documentation makes it seem as if: "you just connect the GC > and it works". I'm sure that isn't the intention, but judging from some of > the posts on this mailing lists over the past months, this seems to be a > common expectation.I think that is the goal though. New users are certainly expecting it to work because that's the way its phrased. It isn't there yet but it continues to improve at a tremendous rate (IMHO). I'm just sorry that I haven't been able to devote more of my own time to this... There is also the question of when the LLVM maintainers should start kicking stuff out of the LLVM repository. As soon as we get working examples I'm sure they will be deluged with mini Lisp/Haskell/CAML etc. implementations, most of which will snowball beyond minimal working examples and no longer belong in LLVM itself. -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. ffconsultancy.com/products/?e
On Tue, 5 Feb 2008, Jon Harrop wrote:> There is also the question of when the LLVM maintainers should start kicking > stuff out of the LLVM repository. As soon as we get working examples I'm sure > they will be deluged with mini Lisp/Haskell/CAML etc. implementations, most > of which will snowball beyond minimal working examples and no longer belong > in LLVM itself.IMO, there are two classes of projects here. The easy class are little samples or demos or examples which are (at most) a couple hundred lines of code. These can live in the main llvm repo, f.e. under llvm/examples. Projects that are bigger than this can be part of the llvm project umbrella if desired, but should live in a separate module. For example, llvm-gcc, clang, stacker, java, poolalloc etc all exist this way. The bar for creating a separate module is very low, so this isn't a big issue. One real issue though is that these projects will get out of synch with mainline if noone is active to maintain it (e.g. java). In my mind, this is actually a good thing: putting these into mainline would cause increased maintenance burden in the case when noone is interested in the project. When someone later becomes reinterested in a project, it usually isn't too hard to synch the project up to mainline again. Anyway, in short, bring on the deluge! -Chris -- nondot.org/sabre llvm.org
Jaap Suter wrote: >> LLVM currently lacks working examples demonstrating the use of garbage >> collection... > > Hello, > > if anybody has time, I would recommend putting a big disclaimer at the top of > the garbage collection page that explains that, for the most part, garbage > collection falls outside of LLVM's domain. > > Right now LLVM advertises itself as "supporting garbage collecting", which > although true, somewhat misses the point. LLVM just happens to not get in the > way. The only real garbage collection feature that LLVM provides is accurate > stack walking, and even that can be implemented separately through a shadow stack. > > That the documentation contains llvm.gc intrinsics is a bit of a red herring. > You end up doing most of the work yourself. To illustrate, for our own LLVM work > we implemented garbage collecting completely without using any LLVM primitives. > Granted, we're a conservative collector right now, and once we go accurate we'll > investigate the stack-walking. In my opinion this is exactly what LLVM _should_ provide. If you try to implement an exact GC one of the most annoying bits is getting information about your stack roots. Using a shadow stack is possible but there are costs attached to it (in PyPy we observed slowdowns of around 5%) as well as implementation complexity. morepypy.blogspot.com/2008/01/finding-gc-roots-using-llvm-or-parsing.html > Just a head's up from an beginner/intermediate LLVM programmer. The current > state of the GC documentation makes it seem as if: "you just connect the GC and > it works". I'm sure that isn't the intention, but judging from some of the posts > on this mailing lists over the past months, this seems to be a common expectation. Maybe a disclaimer would make sense indeed. Cheers, Carl Friedrich Bolz
On Tuesday 05 February 2008 21:15:16 Carl Friedrich Bolz wrote:> In my opinion this is exactly what LLVM _should_ provide. If you try to > implement an exact GC one of the most annoying bits is getting > information about your stack roots. Using a shadow stack is possible but > there are costs attached to it (in PyPy we observed slowdowns of around > 5%) as well as implementation complexity. > > morepypy.blogspot.com/2008/01/finding-gc-roots-using-llvm-or-parsing >.htmlTo put this into perspective, the difference in allocation performance (which is also due to different run-times between OCaml and F#) is up to 500%, so the 5% difference you've observed is tiny and (IMHO) well within the "no significant difference" region. Moreover, I'd be amazed if that 5% were not tremendously architecture and platform specific. How many CPU designs and compilers have you tried this on? -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. ffconsultancy.com/products/?e