On Thu, Aug 22, 2013 at 11:12 AM, Jonathan S. Shapiro <[email protected]>wrote:
> 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. > Agreed. I think a subtlety is that we'd like this intermediate-representiation to not be trivially decompilable into full source -- which I think at least means replacing non-exported human-readable symbols with something else. JVM and CLR language compilers haven't really done a great job of this, maybe due to their reflection APIs (perhaps another reason to drop reflection and focus on compile-time-metaprogramming?) Though there are separate code-obfuscators which will obfuscate non-public symbols. > 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. > This is close to the strategy of Objective-C + ilvar, though they offload the method call polymorphism to runtime dispatch. This seems also remotely like the approach of WinRT/CXX. However, this link-and-load approach encourages a fight between polymorphism and performance. This is the wedge that's driving JIT into modern systems, as we desire both. > 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. > I presume the recompile of "things that depend on the library" can then inline as needed? My naive view is that determining what to inline without call frequencies in a very polymorphic interface-based world is a hard problem, though nothing about AOT prevents this data from being collected and analyzed. By my view the line between AOT and JIT is a fuzzy one. Some modern systems make use of runtime code generation (regex, sql, etc), if this is supported then JIT is effectively supported. > The main problem that the second approach doesn't solve is run-time > loading of *unregistered* code. > This sounds like an over-constraint. A Photoshop plugin could easily be "run-time registered" into a running program, "AOT compiled" while the program waits, and then loaded. As long as there is no type-definition collision, the difference between AOT and JIT here is just time-delay and inlining differences. What the second approach does not admit is run-time registration and loading of a *new-version* of an existing registered assembly -- since that would require stopping and recompiling the application. I don't see a problem with this constraint, since type-redefinition is a mess of problems anyhow. It feels like there may be a useful solution here which involves only allowing exported-types which exist before registration. Deviations in "internal" types are not allowed to be exported. This is effectively like static-linking those internal types and not sharing them with anyone -- which is what we do in the C world anyhow. > So what is it, exactly, that we're really trying to accomplish with the > traditional style of dynamic library? What's the use case? > a) Updatable binary (non source) component and compatibility management - which the AOT can solve b) Code-page sharing, especially in memory constrained environments - for which AOT is better anyhow c) run-time loadable modules - which AOT can solve as long as type-collision/redefinitions are not allowed (they are just a huge problem anyhow) IMO, the only additional benefit of JIT is faster launch for previously unknown code, and more flexibility about when inlined specializations can be created and introduced. I like these capabilities, but they are certainly not pivotal. Performing the inlining eventually, however, I think *is* pivotal.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
