[LLVMdev] LLVM and managed languages

[Talin]

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>