[bitc-dev] Retrospective Thoughts on BitC

Jonathan S. Shapiro shap at eros-os.org
Mon Apr 9 18:18:47 PDT 2012

On Mon, Apr 9, 2012 at 5:54 PM, David Jeske <davidj at gmail.com> wrote:

> On Mon, Apr 9, 2012 at 4:11 PM, Jonathan S. Shapiro <shap at eros-os.org>wrote:
>> I'd certainly be very happy to see that, but I think we need to take one
>> step at a time. We still don't know how to do modularity in the *absence* of
>> versioning issues.
> This I'm surprised at.
> In the absense of versioning issues, don't most dynamic language runtimes
> handle modularity? Java/JVM, C#/CIL, Python, Ruby, Javascript... all can
> have interfaces specified (whether checked by a compiler or not) and load
> compatible classes at runtime.

I think that most of the "object as hash-map" languages are immodular - the
problem is that in most of those languages an object's has-map is
modifiable by third party code.

Regarding Java and MSIL, I think you make a good point. Java, regrettably,
has insufficient support for unboxed types.

As far as I can see, both C-shlibs and CIL both (to some degree) at least
> have some capability to handle multi-versioned dependencies because both of
> them record the required dependency version in a way that is visible to the
> runtime load/linker. Further, they can both load multiple versions of the
> same shlib/DLL. Compare this with Java, Python, Javascript, etc.. which
> don't have any record of such information to make available to the runtime,
> nor can the runtime handle more than one version of a module/class loaded
> because of name-clash.

Right. So recording the version number seems like a good place to start,
and perhaps it may be as much as can be done - though it's also important
that those version numbers reflect interface contract versions.

I also agree that Java, MSIL, and friends seem to have this wrong, though
it's certainly easy enough to arrange a class path with a known set of

I'd be satisfied if I could have badly overspcified interfaces between DLLs
> and actually load two modules without version typeclash. I think C-shlibs
> and CIL both give me this. Do they not?

I'm not sure about CIL.

Another interesting approach here would be to declare that the effect of
loading a library is to get back a function which, when called,
instantiates that library. The point being that if there is no static
global state then you can load multiple versions of a subsystem
simultaneously into the same address space.

I see and agree fully with your view here. I wasn't aware of this 'tree
>> shaking'. When I referenced Singularity I was thinking of the attempt to
>> provide isolation between modules via a mechanism which resembles the type
>> of brute-force message-passing we do today (between kernel and user or on
>> socket interfaces), but without the copying... (i.e. singularity's
>> immutable object transfer model) I admit it was many years ago I read this
>> paper, so I may be remembering it incorrectly.
You're thinking of the linear typing work. It turns out that linear typing
really isn't a good match for the way that data tends to flow in real
systems, and in any case, merely mortal programmers can't manage linear
types when they are exposed in their full glory.

The problem of stop-the-world pauses are exacerbated by threading and
> layered-systems. Much like cumulative MTBF, when many subsystems may have
> unpredictable worst-cases pauses overlayed, the systemic worst-case pause
> is additive....

Ah. When I read this initially, I was considering a slightly different
issue - the cumulative memory overheads arising from the fact that
two-space (or more) GCs hold twice as much young memory as they actually
need, and this tends to present a requirement on real RAM. Your point is
important as well.

However: it is often the case that in layered systems of the type you
describe, the layers in the "waiting for message" state are sitting at the
top of an event loop, and therefore have an effectively empty heap. I think
it is an interesting question whether this can be usefully exploited

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.coyotos.org/pipermail/bitc-dev/attachments/20120409/472507e5/attachment.html 

More information about the bitc-dev mailing list