Why Idel

[an incomplete draft full of rash assertions]

Idel tries to solve several problems. In order of importance:

1. You can't take a compiled program and run it on an arbitrary computer. To the extent that you can, you usually can't move a *running* program over to another arbitrary computer and resume it there. Furthermore, nobody wants to make their machines available to mobile code without control over the resources it can consume.

2. Organizing a tightly-coupled program as a set of separate processes is so expensive and awkward that most extensible systems either use special `scripting' languages or link extensions directly into their address space where they can trash the main program.

3. Linkers are outdated and grotty. Outdated: they don't fit software components or generative programming well. Grotty: over the years they've accumulated hacks supporting various approximations to those features, like shared libraries and STL template code.

4. There's no really good portable way to generate machine code on the fly in a running program.

The obvious questions about these points are: why do they matter, don't other systems handle them, and how does Idel work?

Why does point 1 matter? It's easy to think of applications for mobile code, but the most basic reason is, it could change the way people provide network services. The client/server model encourages monolithic services like EBay, Amazon, and so on -- which is almost to say it encourages monopoly. When you need a new protocol and custom client programs for every new distributed system like Usenet or Napster, a Usenet or a Napster is not the first design you think of when you have a new application to build.

In a few years there'll be tens of millions of PCs on broadband in U.S. homes alone. Current software leaves them idle almost all the time. The distributed-computing companies I'm aware of are aimed at a model where a few big clients submit jobs for all those machines. (Mojo Nation is a possible exception, but they don't have any CPU trading yet.) This is a tremendous opportunity to create something better.

Java is the obvious answer for mobile code -- except it isn't, because:

it has no defined way to serialize the full state of a running program;
it has no defined way to limit the resources consumed by programs within one virtual machine, or to organize processes across multiple VMs and set limits on the individual VMs, either;
the VM, designed only for Java, is a painful target for lots of useful languages;
it's under the thumb of a single corporation; and
while these all could be fixed, or at least ameliorated, Sun has made no progress on them in its 5 years and more of hyping Java. I used to be optimistic -- now I think they'll do nothing until forced to, and then do the least that will keep their position.

I might add that:

the JVM is a questionable VM design even for Java;
its trusted computing base is enormous;
the security architecture strikes me as complicated and cumbersome;
its performance is still less than stellar;

but those don't seem to matter in the marketplace.

When resource control comes up, people tend to say that's the OS's job, and why reinvent the wheel? Well, we still need an API to get at those features, but the real trouble is that conventional OS's suck really hard when they meet mobile code. Verifying this is easy: just go to a webpage with an applet that steals all your CPU and memory. There are ways to hack in control over a Unix-style process for all the different kinds of resources it might want, but it seems to get hairier all the time; and what's more, that gives no way for different agents *within* the JVM to get appropriate service. DoS attacks and quality of service issues just recur at a new level. I think a different set of abstractions would make our lives a lot simpler at this point.

Okay, so those are not the answer because they require every individual mobile-code program to provide for checkpointing, resource control, distributed debugging, etc. There are at least two systems that address these issues at the language level instead: Agent Tcl and ARA. (I'm leaving out dead projects and mobile-code languages that aren't part of a multi-language system.) These each provide a framework for multiple languages to work within, and require each language implementation to be modified with checkpointing support, etc. This is a good thing, and Idel could work with these systems as one of their sublanguages, but adapting each language implementation for ARA or Agent Tcl is likely to be more work than porting to a reasonable VM -- portable systems are designed with that sort of port in mind. In short, Idel enables things like checkpointing to be implemented just once.

Point 2 up above is a continuation of the ``OS's suck'' theme. IPC is notoriously expensive because it has to go through the kernel, perform context switches, and typically copy stuff between address spaces. OS's don't seem to be getting faster at these things as quickly as the underlying hardware is improving. Newer applications tend to be more communication-oriented than classical ones of 20 years ago. This all has a pervasive effect on the design of programs, leading to things like thread pools and custom extension languages, all to keep the OS out of the fast path. What if OS functions were cheap?

This is a lot like the VAX subroutine-calling situation -- they had one high-level instruction that did everything but cost more than combining simpler instructions, that people were stuck with using for the sake of interoperability. Since subroutines were proverbially expensive, people distorted their code to avoid them. I believe we need a RISC approach to things like memory protection now.