[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.
>
> Well, sort of. Things like GC tracing of SSA values can't really be done as
a library, i'm assuming it requires changes to the code generator.

Things like iterating stack frames can be done as an add-on library, but I
think they would work better as intrinsics - which again requires changes to
the code generators.

Things like stack switching could go either way I guess.

Most of the things that *could* go in an add-on library I could write
myself. The primary exception is cases where the library code has to be
different for each target platform - in such cases what you'd really like is
for each different platform-specific implementation to have a maintainer who
is an expert on that platform.

This is not to say that such a library as you propose would not be useful
and convenient.

Of course, I'm assuming that the typical language implementor has skills and
needs similar to my own, which might not be true. In general, I try to be an
expert on the first half of the dragon book, and leave the second half to
experts who know far more than I do.


> 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/20110704/c4ea0d76/attachment.html>