On Mon, Apr 9, 2012 at 5:54 PM, David Jeske <[email protected]> wrote:
> On Mon, Apr 9, 2012 at 4:11 PM, Jonathan S. Shapiro <[email protected]>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 versions. 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 somehow. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
