[LLVMdev] LLVM and managed languages

[Talin]

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.

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>