[bitc-dev] Choice of runtime/VM

[Ben Karel]

I'm not sure if it's an inherent or incidental limitation, but LLVM's shadow
stack implementation inhibits tail call optimization.

Probably the biggest missing feature from LLVM's GC infrastructure is the
ability to generate machine code at safe points. Well, that, and the lack of
compatibility with the JIT.

There are some nice-to-haves for performance that are also currently not
available. Because LLVM does not compute register maps, code supported by a
moving collector must manually re-load GC roots from the stack after any
potential collection point. Liveness analysis for GC roots could cut down
the amount of unnecessary work at some GC points.

What makes the Go backend more appealing than LLVM's C bindings?

On Thu, Jul 29, 2010 at 2:05 AM, Jonathan S. Shapiro <shap at eros-os.org>wrote:
>
>
> *GC* This partly depends on the choice of target environment. CLR more or
> less defines the GC for us. There are at least two precise collectors on
> LLVM, and either the Harmony GCv5 collector or the dis collector might be
> adaptable for our purposes.
>
> *Target *Still not decided. Native code is important to us, so probably
> not CLR first (though that's a good exercise). LLVM most likely, or possibly
> a port of the Go back end. I'ld actually prefer the Go back end, but it
> doesn't currently support read barriers, write barriers, or GC root
> tagging/preservation. In spite of these deficiencies, the Go back-end (a
> derivative of the Plan9 back-end) is in C, which would make it much easier
> to "lift" it into BitC. I do know that Rob et al would be interested in
> adding support for these things to the Go back end, and would probably take
> a well-crafted patch back into the origin tree.
>
> Precise collection can also be obtained by other means without help from
> the back end, most notably by means of the Henderson techniques.
>
> The situation for LLVM has evolved considerably in the past year; matters
> may not be as bad now as Ben is assuming.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.coyotos.org/pipermail/bitc-dev/attachments/20100729/c6982a6a/attachment-0001.html