Of course, the benefits of multi-level binaries might be implemented at a purely application level. We might simply create a cache file for each source code file and have this loaded by the JIT compiler. Of course, this approach runs in to all sorts of difficult in copying files and the like but perhaps we just need a special file format. However, this makes things quite difficult if we want to write programs in more than one language without the overhead of RPC or CORBA. This difficult is no doubt one of the reasons integrating source and binary information isn't more common. Still, we might address this issue by some system of standards and shared libraries used by the various compilers and JIT systems.
If we only want to address the issue of performance this might be a workable solution. However, if we want all the benefits of process/thread isolation without the overhead of loading a new VM/JIT compiler for each execution context we have no choice but to add operating system support or re-implement all the features of task management again in each JIT compiler. By making the various compiler functionalities as specialized OS modules each execution context written in a VM can share the same JIT/VM code while gaining all the benefits of process isolation. Essentially the JIT code would be a shared read only code segment which may be executed in several different processes. Thus the OS may be executing the same JIT code in several different processes at the same time. Also OS support could aid profiling with little overhead by saving the execution location in the saved snippets of machine code whenever it interrupts the process at that point.
While the FX!32 style saved code snippets provide great performance after the program is run several times it seems silly for the program to under-perform the first several times it is run. Moreover, one of the performance problems with JIT compiling is that only computationally easy optimizations can be performed. Why not solve both of these problems with a background compiler(s) which scans the multi-level binaries on your system in free CPU cycles applying optimizations, interpreting profiling data and generating snippets of machine code to minimize time spent in the JIT compiler. Of course a JIT compiler or interpreter is still needed to handle sensitive operations or run code which the background optimizer hasn't gotten to yet but it can be much smaller and faster counting on the background pass to perform many optimizations or at least tell it which optimizations should be carried out.
This raises the tantalizing possibility that OS updates would actually speed up programs you already have on disk. The background optimizer could download clever new ways to compile the source code and update your programs while you sleep. Since the multi-layer binary keeps so much program structure this could mean real efficiency enhancements. For instance if someone figures out a much more efficient way to implement the printf function the background optimizer could void the VM code in all your binaries corresponding to the printf function replacing it with the more efficient version without the need to recompile the rest of the code.
Of course the prospect of strangers changing the code on your system is a scary one from the prospect of security or even stability. Thus it is only reasonable for our background optimizer to require a proof of equivalence. Each line of code, or code snippet would be characterized by some manner of contract or even just a piece of reference code in the next level down. In either case the effect of the code would be captured in some formal system which allows for proofs of equivalence and only provably equivalent optimizations would be accepted.
A Vision of the Future
So in my vision of the future the distinction between the compiler and the OS blurs or disappears completely. In so doing we approach the holy grail of code reuse. If someone anywhere discovers a clever optimization or algorithm, and they can prove it equivalent to the standard algorithm, everyone benefits. If some clever assembly language hacker out there discovers a really fast way to implement some VM instruction he can use some specialized tool to prove his implementation is equivalent and it will spread across the internet speeding up every program using that VM instruction. The use of multi-level binaries even hints at the possibility of replacing entire algorithms by proving they are equivalent to some faster version, though our formal proof systems need some time to improve before this can happen.
While some of the ideas about downloading optimizations may be far off I think our constant evolution towards later binding languages and VMs makes the integration of the compiler and OS inevitable. It may not happen the way I suggest but hopefully by getting these ideas out there people can begin to think about it and perhaps avoid the grim possibility of these ideas being patented by a mega-corporation and strangling technology which truly could enable write once run anywhere freeing up the OS and hardware markets to real competition. At the very least I want to know why the technology of caching code snippets that FX!32 had long ago is absent in every JIT compiler I have ever seen.
The author, Peter Gerdes or logicnazi as he is known on OSNews, is a graduate student in mathematics/philosophy not computer science. So it is entirely possible that these ideas suffer from some simple pragmatic problem he doesn't know about. If you want to contact him to tell him about one of these problems you can email him at firstname.lastname@example.org where he is bravely testing gmail's spam filters.
- "Page 1"
- "Page 2"