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. 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.
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.
Im still curious how BITc would have gone for stack / static types
> which are a pain in C# ( eg I bet on a generic array of ints writes to
> the value type fields still incur the GC write barrier or at least
> some escape condition). The support of explicit boxing . non nullable
> types and immutable types would have greatly assisted the runtime
> here.. ( and perhaps also some indicator that a type contains no
> references so the GC and card table don't need to do anything)
>
Agreed on both the question and the "what would help here" part. In
particular, it isn't clear that we want the code generator for the GC to
use the same barrier implementation as the main code - the GC operates
under different barrier constraints. So that seems like a potentially
significant complication in the compiler for what may not turn out to be a
significant benefit.
> 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.
It doesn't really matter which of us is right on this, though.
shap
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
