Q&A / Panel Discussion.

Godmar Back asked about the runtime overhead of recompiling the implementation of an entire system all the time. [You can do so incrementally; witness Self.] He mentioned that you'd want well defined APIs. [I heartily agree. The APIs only disappear in the implementation; programmers are still bound by them. The interface disappears, but its properties are preserved because partial evaluation is a correctness-preserving transformation.]

Michael Jones mentioned the OSDI panel, where Rob Pike talked about OS support for languages. (I don't recall what Mike's point was; these notes are reconstituted from chicken scratch.)

Someone shuddered at the idea of a self-modifying kernel. I said that it's worse than that! The ``kernel'' is being constantly rewritten; indeed, you can't even look at a particular basic block in the implementation and say that it belongs to either a specific application or the kernel (run-time services). [Why is self-modifying scary? Synthetix does it. It's scary because you're thinking of ad-hoc self-modifications that are performance hacks. What I'm talking about is modification generated by a partial evaluator that is correctness-preserving, the same partial evaluator that built the first copy of the system is modifying it. It's like worrying that recompiling your kernel is scary because maybe the compiler might not get it right this time!]

I think Stefan Savage described his experience with SPIN, pointing out that the challenge isn't where to put the red line, but to figure out the ``width'' of the red line. If the interface is too big, it's hard to retain any guarantees of security or integrity of the system. I agreed, affirming that I didn't purport to offer an easy replacement for SPIN, but a good framework to fit extensibility work into.

Armando Fox asked about how ugly this thing would be to debug. I think David Patterson complained about this as well. I don't think I answered the complaint, to give others a chance to speak. [My answer is to use Self as an existence proof. Self has a mess of hairy specialized code hiding under the hood, but falls back on slow, unspecialized code for debugging. The entire process is transparent to the programmer. The programmer can't tell that his or her lovely software-engineered function call interfaces have been optimized into oblivion in the real implementation.]

Buck (Charles) Krasic from OGI came up front after the panel session, and pointed out that he was reasonably sure that similar long-term goals were envisioned for the Synthetix project (currently dormant). I said I wasn't surprised; that perhaps my role here was to help sell that vision, because from the looks of the community, no one else seems to have shared it.

As we discussed getting partial evaluation to work down low, we hit on garbage collection. He mentioned ``region inference'' from the functional programming community, which infers where malloc() and free() calls should go, generating code with statically managed memory.

He mentioned staged programming, in which one writes explicit transformations, and then uses type systems to verify some aspect of the correctness of the transformation.

He said to look on Charles Consel's web page, and find Scott Thibault's work on interpretive specification for domain-specific languages. He mentioned George Necula's proof-carrying code as an example of a contribution from the languages community that was well-received in the OS community. [I'm not so sure -- see any pcc-protected extensible/component systems?] Regarding Self's bimodal code generation (non-inlined and specialized), he mentioned CAML, which uses a combination of byte codes or optimized native code segments, falling back on the byte codes for debugging.

David Kidston from CRC also came up to talk after the panel.

John Regehr, from the U. Va, grabbed me during the Outrageous Opinions section, and pointed out that in the Ensemble project at Cornell, they (manually) discovered the common paths through their network stack, and generated optimized fast paths. Of course, this optimization is constrained to within the network stack by existing system implementation boundaries. [He followed up with an e-mail pointer to Optimizing Layered Communication Protocols.]