From: [email protected] [mailto:[email protected]] On Behalf Of Jonathan S. Shapiro Sent: Friday, March 04, 2011 5:21 AM To: [email protected]; Discussions about the BitC language Subject: BitC, GC, and VMs 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. Completely agree here , but you will need some time ( and this little time is big reward) and resolve the IR issue discussed earlier ( ie do you use none , your own , MSIL , or LLVM) ..A Bitc on CLR immediately gives access to the whole .NET libs and reasonable performance. 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. Yes agree on native compilation but more the static memory management of native code even the no gc option. This is the real key , get your normal programmers to churn out VM code but put your guns on critical shared , driver or server processes that may use static memory management when a VM is not appropriate . In terms of native compilation itself the distinction is hard the CLR provides ngen and Mono LLVM which does output binary code but still uses a gc and is not appropriate for drivers/kernels.. 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. That's nice for me. 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...
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
