On Wed, Mar 2, 2011 at 11:41 PM, Ben Kloosterman <[email protected]> wrote:
> Also customers will create there own libs this is a compete and utter > mess in Unix (esp linux) which should have been sorted out years ago . 95% > of apps can make do with a VM ( where you can change the GC strategy) and > the pauses are irrelevant ( too small to matter) . I would strongly push > customers into this at it gives a much better experience with user written > libs. > I agree with a lot of this, though I'm not convinced about the last sentence. The question is: how much energy should we devote to VM issues, and when is the right time to devote that energy. The other statement, which you missed, is that VM users don't care about low-level data layout. Before Eric Northup identified a data layout strategy that met the CLI requirements, I was inclined to give some attention to VMs. Now that he has, and in particular now that the mono project is making credible attempts to build a real GC over time, I'm not. We can compile BitC to CLI and gain the benefits of a VM that way with essentially no investment. This will allow us to focus on native compilation, which is where BitC really needs to differentiate itself. It is also (probably) the fastest path to a self-hosting BitC implementation with a reasonable GC in the near- to mid- term. With that said, I think it's still vitally important to focus on native compilation, and in particular on native compilation strategies that can exploit low-level dynamic rewriting. That is: strategies in which the compiler is *aware* that dynamic rewriting will be happening, and emits code in a way that pre-plans for this. For example: given a choice between multiple on-disk versions of libraries - for example a multi-threaded compilation model and a single-threaded compilation model - I would very much prefer an approach in which the compiler emits the multi-threading interlocks unconditionally, but also emits relocation-like information that can be used by a low-level dynamic rewriter to eliminate the interlocks at run time. Caveat: multi-threading is difficult, because an app can go from single-thread to multi-thread as a consequence of a library load. I think we need to be careful not to optimize too much for a case that is increasingly going away... Jonathan
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
