On Thu, Aug 22, 2013 at 2:34 AM, William ML Leslie < [email protected]> wrote:
> On 22 August 2013 16:32, David Jeske <[email protected]> wrote: > > > I'd flip that around and say that what matters is that for the type of > > interface you would like to express and an interesting set of library > > changes, a new binary object can be supplied for which applications > compiled > > against the old binary can run-time link and run against the new binary. > > Ah, yes. So you would like whatever ecosystem bitc integrates into to > support the declaration of these stable, compile-time interfaces. Sorry, but it keeps itching at me that we're mis-stating the requirement here, and in consequence it's possible that we are not looking at this problem in the right way. Let's start with three assumptions: 1. We're going to have a byte-code form at a level of abstraction similar to that of CLR. Which means we aren't limited to static or dynamic linking as our means of dealing with versioning. For better or worse, any language that combines generics/parametrics with unboxed types is going to need this. 2. In any practical system, we're going to have something analogous to a process or address space boundary. 3. We're willing to ship some level of compiler as a foundational part of the system There may be data and object interchange across address spaces, and *that* interchange involves a whole bunch of interesting versioning issues, but it's at least a place where programmers know they have to design and plan ahead. I'm intentionally disregarding situations that demand whole-program or whole-library compilation for this discussion. I think that applications which want to rely on direct-to-binary static compilation and dynamic linking are going to be limited in the type systems they can use at loadable/linkable module boundaries. Mainly (once again) because of the parametrics+unboxing issue. So with those two stakes in the ground, let's go back and look at the proposed requirement. *Why* is it that we want backwards compatible dynamic linking? Here are some alternatives: 1. Link-and-load: a relocation-style rewriting pass that is not as complex as JIT. The main limitation of this is emitting procedure calls having unboxed parameter types, mainly because that doesn't mesh well with the underlying calling conventions on most machines. Fortunately we only have to respect those calling conventions at points where cross-language calls occur. 2. Post-install AOT: When a new library arrives we compile it with AOT. We keep the old version of the library. We then run around recompiling all of the things that depend on that library one at a time. When all of those have been compiled, we drop the old version of the library. As processes halt and restart in the normal order of things, the old version of the library disappears. The main problem that the second approach doesn't solve is run-time loading of *unregistered* code. That is: code where the dependency between the application and the thing it loads is only recorded in a string somewhere that is getting passed to LoadDynamicLibrary() or some such thing. I'm frankly not convinced that this issue is all that serious. First, I'm not sure that promiscuous dynamic loading is a good idea from a security perspective. But even if it is, we can register such libraries as "might be loaded by *", do the post-install AOT thing, and not drop the old version until *all* applications in the system have been recompiled. It's not pretty, but it would work. So what is it, exactly, that we're really trying to accomplish with the traditional style of dynamic library? What's the use case? I think it's mainly to do with kernels, and with things that sit very low in the system runtime - notably those things that need to exist to support the post-install AOT implementation. For loadable kernel modules we certainly have an issue, but even *those* can be handled with this kind of post-install AOT. I'm sure there are things I'm not considering here, but what do people think about this? shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
