[LLVMdev] LLVM and managed languages
viridia at gmail.com
Tue Jul 5 11:42:02 PDT 2011
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.
> -- Talin
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev