[bitc-dev] Retrospective Thoughts on BitC
davidj at gmail.com
Mon Apr 16 18:59:54 PDT 2012
On Mon, Apr 16, 2012 at 10:52 AM, Jonathan S. Shapiro <shap at eros-os.org>wrote:
> On Sun, Apr 15, 2012 at 10:56 PM, Matt Oliveri <atmacen at gmail.com> wrote:
>>> If you want a typesafe runtime to replace C, then you are essentially
>>> saying we should write all programs on top of some fixed runtime.
>> Yes. That runtime would evolve over time, but yes.
> I more or less agree. One thing I would like to see is a successor to CIL
> that provides for regions and parametric types, and maybe for "shape types"
> (which I need to explain).
Sounds great! (as long as it doesn't stop-the-world) Wait, I think that
angelic sound and light beaming down from the heavens is Shape-Jeske
unification. Lets go build that.
- Are CIL apartments not a different way to achieve Regions?
- What about the CIL type-instantiated generics does not meet your
definition of parametrics?
- very interested to hear about shape-types..
- As for your previous comment about wanting subtyping in structs.... I'm
not convinced subtyping is the right reuse mechanism. It creates very large
challenges for modular forward upgradability. I'd prefer to see us
experiment more with composition and aggregation, more like COM or
Google-Go. Composition is a common pattern at the program architecture
level as well because of greater flexibility vs locked single-inheritence
hierarchies. (i.e. traits, game-component-architectures, flat-driver
interfaces, flat-plugin interfaces, etc.)
> I object to this. I do not believe people turn to C to avoid compromise.
>> If so they would always turn to assembler. I believe they turn to C because
>> it offers an improvement in programmer productivity in exchange for a
>> linear-performance degregation.
> But you yourself note that C is essentially asm with human syntax.
touche! Guilty as charged.
I still maintain it is primarily the non-linearity of GC-pausing that has
us stuck in C-land, not a linear performance degredation.
Linear performance degredation is not a limit to deployment or scalability
and is only an issue in the most hyper-optimized of cases (which hardly
exist). Wheras GC-pausing is a non-assaultable response-time wall. GC
systems which stop the world don't give us ways to avoid it for many
application types. (the best we can do is get data out of the heap, which
often means just moving to C++)
> I think there are a bunch of reasons people turn to C:
I'm really thinking about the reasons people continue to turn-to-C "in the
limit case" (i.e. into the forseeable future until we give them a way not
to). Not the instantaneous reasons we do.
Broadening my scope somewhat, my list is much shorter than yours...
- non-linear performance cases (GC-pausing and mandatory stack-walking at
- lack of a suitable contract model for exceptions (which is a whole
additional discussion in itself)
- lack of a truly-permissive royalty-free-runtime... (mono-runtime is LGPL,
and there is Microsoft patent fear)
( Aside: I wish Microsoft would just solve the patent fear thing already.
They kinda did but didn't with the vague promise of
non-discriminatory licensing. It would be better if CIL was declared free
or had a licensing price-list for runtime patents. Otherwise the industry
will probably steer clear for a long time. When I was at Google I
encouraged the consideration of CIL for Android, but the MSFT rivalry is
challenging to work through. Ironic now given the Oracle lawsuit. Licensing
CIL might have been reasonable in comparison. )
I really like your list, so I'm going to deep-end a little commenting on
> - Maybe I'm writing something that is dependent on an existing library
> in C (e.g. OpenSSL)
> Software is kinda magical in that we can copy it for free, so I'm pretty
sure we'd built up a healthy core of pretty much everything as soon as a
typesafe system met the criteria. Heck, we've built up a pretty healthy
core of stuff in lots of systems that don't actually meet the criteria.
> - Maybe I need decent I/O performance, and safety is pushing me into
> data copies that I can't afford to do. Biagioni's work on TCP in ML is
> instructive here. Foxnet is painted as a success, but actually it's pretty
> I don't see what data-copies are required if CIL talks to the syscall
interface directly. CIL also opens the door for post-syscall kernel
designs. Again, I'm thinking limit-case here.... of course today I agree
with your comment.
> - Maybe my app warm-up time matters (so JIT gets in the way). This was
> the main issue for in-transaction database servlets
> This was a problem in JVM, but CIL AOT pretty much solves this.
In fact, CIL provides the best of both worlds, because you can AOT
something that approaches C-shlib level startup times, and still get JIT
inlining across boundaries with polymorphic inline caches and other tricks.
CIL can also do a safer and better job assuring there are no
field-offset-compatibility mismatches (like expectations of different
layout stat_t structs) and can even fix some of them automagically.
> - Maybe pause times worry me
> Isn't that the ugly truth!
> - Maybe the problem of debugging inadvertently retained storage was
> too hard
> I read that as "debugging memory leaks". It's always seemed roughly the
same as debugging C/C++ memory leaks to me. I suppose automatic-memory
management does allow us to build contracts with much more complex memory
ownership consequences, which in turn could lead to this problem. I'll have
to consider that.
> - Maybe I just don't know any better
> We need to make a better CIL-ish before we can say this. Currently the
C-runtime *IS* actually better.
> - Maybe I care about performance, therefore about memory placement,
> and therefore need a rich system for unboxed types
> I've been really happy with CIL structs, struct-arrays, type-instantiated
generics. What do you think we need that it can't do?
> - Maybe the *physical* heap footprint of my app matters. Either I
> can't afford 10x the memory initially, or I'm operating at a scale where I
> can't afford to *cool* 10x the memory. That's why Google can't use
> some of this stuff.
> Why would CIL take 10x the heap? I don't see that at all. Except for maybe
the dubious decision to make all strings UCS-2, I don't see any reason CIL
needs to be much bigger than C++. Azul-C4 has a constant heap overhead.
One of the projects I ran while at Google started out on .NET 2.0 / Windows
as a bit of an experiment. We tried to move it to Linux-mono, but it wasn't
viable at the time. It ultimately moved to a mix of C++ and Java. Memory
overhead (in CIL or Java) was not an issue. GC pausing was/is. It had "very
> - Maybe I care about security and modularity, and I've worked out that
> taming the Java standard library is utterly hopeless.
> All I'm saying here is that GC is just one of *several* issues that are
> getting in the way of safety adoption
Certainly there are more issues than GC-pausing. I guess I single it out
because it's among the few issues that no amount of library work can solve.
One has to change the runtime, and if Azul C4 is any indication, the
operating system and hopefully one-day the processor.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the bitc-dev