[bitc-dev] Retrospective Thoughts on BitC
davidj at gmail.com
Tue Apr 10 03:50:25 PDT 2012
On Apr 9, 2012 6:32 PM, "Jonathan S. Shapiro" <shap at eros-os.org> wrote:
>> In the absense of versioning issues, don't most dynamic language
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.
I agree with this design criticism, though in practice this is often not an
issue. For example, the large majority of Python software does not modify
however, have this problem.
In practice I have trouble the most trouble because
source-dynamic-languages don't have version specificity. For example, the
tiny Python program (#!/usr/bin/python import foo) offers absolutly no
means of dependent version disambiguation of either the runtime or the
This problem is exacerbated by traditional OS/UNIX design, where
/usr/bin/python is a single installed version of python. How then are we to
support two python programs which require different versions of python to
coexist on the same system?
This is not at all a problem for the C-shlib runtime, in which each
coff/elf executable references specific versions of dependent shlibs, and
where those shlibs are uniquely named to allow multiple versions to coexist.
> Regarding Java and MSIL, I think you make a good point. Java,
regrettably, has insufficient support for unboxed types.
Agreed. By my view CIL seems a strictly better technical design than JVM
in all ways.
If CIL has a weakness, it's that IETF standardization and a single
open-source implementation (mono) have not been enough to eclipse industry
concern over Microsoft's intentions.
> 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.
Yes. Version-specific runtime linking (like C-shlibs) is critical...
> 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
My understanding is that MSIL/CIL does this corrrectly (and is the only
one). CIL Assemblies make reference both to a specific runtime version, and
specific versions of dependencies, just like C-shlibs.
> 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.
The true requirement is the elimination of absolute-fixed-addresses. AFAIK,
shlibs achieve this through PIC and load-time resolution, while still
having state they believe is 'global'. We can load three versions of a
C-shlib into the same process without the global state colliding.
Either way, we're thinking along the same lines. Pre-requisites for
handling versioning issues include being able to see the versions
requested, and load multiple versions into the runtime. AFAIK, C-shlibs and
CIL can do this, other systems can not.
> 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
I struggle to understand what system this is with an empty heap. Take a
look at some open-source projects struggling with this now... HBase and
Cassandra.. two data-storage engines built with GC. They have very busy
heaps, and their GC pauses are petty unacceptable for clients.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the bitc-dev