On Apr 9, 2012 6:32 PM, "Jonathan S. Shapiro" <[email protected]> wrote: >> 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.
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 classes at runtime. Javascript (and prototype languages in general) do, 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 module. 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 versions. 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 somehow. 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.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
