Muli Ben-Yehuda's journal

November 29, 2005

Running P on Bare Metal

Filed under: Uncategorized — Muli Ben-Yehuda @ 8:33 PM

I just submitted this proposal to OSDC::Israel::2006. I suppose I
better run off now and actually finish the work, in case they accept
it 🙂

A P interpreter is an execution environment that P programs run
in. The program’s interactions with the external environment,
e.g. console, network IO or memory management, are done via the
interpreter. The interpeter, in turn, commonly runs in its own
execution environemnt as a process in a a general purpose operating
system. This layering of execution environments is on one hand
desirable, since general purpose OS’s are mighty convenient to work
in, but on the other hand can create a number of adverse effects. For
instance, it has been shown that garbage collection at the interpreter
level can significantly reduce performance due to pessimal
interactions with paging at the OS level.

It is desirable to remove the middle man and run the interpreter
directly on the hardware for optimal performance. At the same time, it
is also desirable to keep a general purpose OS around for ease of
use. How can we achieve both?

This presentation describes such a scheme, wherein the interpreter
runs on the bare metal under a hypervisor, and a general purpose OS
runs alongside it. We have implemented this scheme by porting the
movitz[1] lisp interpreter to run on bare metal under the Xen[2]
hypervisor. We will begin the presentation by making a compelling
argument for running P on bare metal; continue by surveying the work
required; and conclude with a discussion of future research




  1. Long long ago and far far away, I attempted to make Mach handle CMU Common Lisp’s GC better using a custom pager. Mach had a generalized interface to the pager functionality and it was fairly simple chore to write your own pager by implementing a set of RPC’s.
    The advantage was that we could handle the dead semispace (Cheney stop and copy gc) with less overhead than we could otherwise.
    I suspect we could have done the same thing with a richer interface to allocating/deallocating/zeroing memory than the standard POSIX-style interface. (And we did have some of that, but I seem to recall it wasn’t quite what we needed.)

    Comment by ch — November 29, 2005 @ 11:05 PM | Reply

    • Sounds mighty interesting, got a reference for it I could look up?

      Comment by mulix — November 30, 2005 @ 1:59 PM | Reply

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Blog at

%d bloggers like this: