On Thu, May 24, 2012 at 5:20 AM, Jonathan S. Shapiro <[email protected]> wrote: > On Wed, May 16, 2012 at 10:36 PM, Bennie Kloosteman <[email protected]> > wrote: >> >> You can write a memory manager in safe code and possibly nearly all of >> a runtime but it would be very tricky. Is the benefit worth it for >> the sake of a few unsafe calls ? > > > I think the answer to this is that the benefit is DEFINITELY worth it. > > First, though, let's separate a couple of issues here: > > From my experience on the BitC runtime and the TinyScheme runtime, there are > a surprising number of places in the runtime system that deal with array > issues of one form or another. In very many cases, the *sole* reason that > these are part of the runtime system is to evade the bounds checking > requirements of the source language.
Agree > This occurs for two reasons: > > 1. The concurrency contracts for byte code (e.g. in Java and CIL) are > awkward, and > 2. The source languages lack a Nat kind and therefore cannot abstract over > length. > > The second point is telling: it is the essential reason that we cannot > implement efficient arrays and vectors within the language, but it also > presents a range of challenges for typing things like object headers from > the perspective of the runtime implementation. IM not sure how a NAT kind can prevent bounds checking eg if I want 3 chars at point n how do you know with certainty that it is not out of bounds ? Java has mostly solved it at a great engineering cost and for JITS , mono for example only eliminates bounds checks if it a 0 to max length iteration. > > Since we know how to deal with that, let's assume it away for the balance of > this discussion. > > > The remaining reason to use a safe language for a runtime implementation is > confidence. I don't mean to suggest here that 100% of the runtime > implementation should be implemented within the bounds of safety. Rather, > I'm suggesting that the more of it you can do that way the more confidence > you will have in the implementation. So long as the safe language has > first-class support for unboxed types and ability to check the NOALLOC > effect, it shouldn't be that hard to do much of the runtime within the > language. Actually I think we agree here.. im basically saying its good to write in a safe language but I would not push it to 100% it is really difficult to get the last few % and the hacks are probably more ugly than unsafe. <snip> >> Bitc seemed to get lost in inheritance/type classes and trying to make >> a better C++ but most system programming is still in C not C++..and >> to me bitc as a language seemed better than C... > > > I'm not convinced that what you say about the balance of C vs C++ is true. > My sense was that any system already committed to C stayed in C, and that > accounted for a lot of low-level code. On the other hand, a lot of newer > work seems to get done in C++ with a back-compatible API for C clients. Yes there is a lot of critical old c code , that said C++ kernels are pretty rare , many newer ones eg barrelfish are still C ( I note Coyotos was a trend setter in requiring C++ :-) . But the case for upgrading the C++ code is smaller than the C code. Its the old C code that really needs to be updated. I think fundamentally these libraries are performance critical and due to micro benches some people don't even want the vcall overhead , memcpy is still asm in some cases. _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
