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 would better *concurrency > primitives*. These are things I could > > > Tackling the "still way too difficult" and "should be more batteries > included" aspects of your post, I think that there is a lot of room for an > LLVM subproject that provides a "language implementors toolbox" in the form > of some really well documented and standardized runtime libraries that > provide GC, synchronization, etc capabilities. Having them available and > reusable (and sub-settable!) would allow code sharing across a wide range of > different llvm language implementation. > > A few additional thoughts: The language implementer's library that youpropose would include a whole bunch of stuff that I didn't mention in the original post because it's stuff that I already have, but which might be useful to other language implementers. Some examples: - DWARF exception table decoding functions, useful for writing personality functions. - Other functions for accessing DWARF data at runtime - useful for generating stack dumps. - Aligned memory allocators. It's useful for some garbage collection algorithms to be able to allocate heap blocks that are aligned on a large power-of-two boundary (like 64K boundary) so that you can quickly determine which memory pool an address belongs to by looking at the upper bits of the address. (Mainly this would just be a standardized interface around the platform's C library functions that do this, such as posix_memalign.) - An efficient map class for mapping function return addresses to a pointer. This map would be initialized on program start from a table of tuples and would be immutable after that. One use of this is finding the stack map for a given function return address. - Integer/float parsing and printing functions for building your language's equivalent of 'printf'. - Helper functions for finding and running static constructors. - Getting and setting thread-local data in a way that uses the __thread attribute if available, and pthreads if not. (I notice that pthread_getspecific is extremely efficient on OS X.) - Low-level debugging support. One requirement is that all of these functions should be written in such as way as to not require the C++ runtime libraries, only C libs. These are the capabilities that the JVM provides languages implemented on> top of it, and are clearly useful. Of course the power of LLVM is that it > doesn't force you to use a *particular* set of synch primitives, a > particular memory management scheme, etc. However, that doesn't mean that > we can't provide a toolbox of parts to choose from, just like we provide a > standard optimization sequence which clients can choose to use or not. > > -Chris >-- -- Talin -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110705/28534ba8/attachment.html>
On Tue, Jul 5, 2011 at 11:35 AM, Talin <viridia at gmail.com> wrote:> 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 would better *concurrency >> primitives*. These are things I could >> >> >> Tackling the "still way too difficult" and "should be more batteries >> included" aspects of your post, I think that there is a lot of room for an >> LLVM subproject that provides a "language implementors toolbox" in the form >> of some really well documented and standardized runtime libraries that >> provide GC, synchronization, etc capabilities. Having them available and >> reusable (and sub-settable!) would allow code sharing across a wide range of >> different llvm language implementation. >> >> A few additional thoughts: The language implementer's library that you > propose would include a whole bunch of stuff that I didn't mention in the > original post because it's stuff that I already have, but which might be > useful to other language implementers. Some examples: > > - DWARF exception table decoding functions, useful for writing > personality functions. > - Other functions for accessing DWARF data at runtime - useful for > generating stack dumps. > - Aligned memory allocators. It's useful for some garbage collection > algorithms to be able to allocate heap blocks that are aligned on a large > power-of-two boundary (like 64K boundary) so that you can quickly determine > which memory pool an address belongs to by looking at the upper bits of the > address. (Mainly this would just be a standardized interface around the > platform's C library functions that do this, such as posix_memalign.) > - An efficient map class for mapping function return addresses to a > pointer. This map would be initialized on program start from a table of > tuples and would be immutable after that. One use of this is finding the > stack map for a given function return address. > - Integer/float parsing and printing functions for building your > language's equivalent of 'printf'. > - Helper functions for finding and running static constructors. > - Getting and setting thread-local data in a way that uses the __thread > attribute if available, and pthreads if not. (I notice that > pthread_getspecific is extremely efficient on OS X.) > - Low-level debugging support. > > One requirement is that all of these functions should be written in such as > way as to not require the C++ runtime libraries, only C libs. > > Oh, and also:1) I'd be happy to donate whatever code I have to this effort; 2) However, I don't think we should do this unless we can identify at least one other customer other than myself - mainly because I don't want the design decisions to be too tailored to my specific use cases.> These are the capabilities that the JVM provides languages implemented on >> top of it, and are clearly useful. Of course the power of LLVM is that it >> doesn't force you to use a *particular* set of synch primitives, a >> particular memory management scheme, etc. However, that doesn't mean that >> we can't provide a toolbox of parts to choose from, just like we provide a >> standard optimization sequence which clients can choose to use or not. >> >> -Chris >> > > > > -- > -- Talin >-- -- Talin -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110705/d3d7cc9d/attachment.html>
On 07/05/2011 08:42 PM, Talin wrote:> 2) However, I don't think we should do this unless we can identify at > least one other customer other than myself - mainly because I don't want > the design decisions to be too tailored to my specific use cases.Pure would be another candidate, so I'd be interested in such a toolbox as well, especially in the synchronization primitives and the DWARF support. Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr.Graef at t-online.de, ag at muwiinfa.geschichte.uni-mainz.de WWW: http://www.musikinformatik.uni-mainz.de/ag