cc:Mail Link to SMTP Undeliverable Message

amos murphy amurphy@NetEdge.COM
Thu, 22 May 97 01:44:21 -0500

--simple boundary
Content-Type: text/plain; charset=US-ACSII
Content-Transfer-Encoding: 7bit

Message is undeliverable.
Reason: Unable to access cc:Mail Post office.
	Please retry later.
Original text follows:

--simple boundary
Content-Type: text/plain; charset=US-ACSII
Content-Transfer-Encoding: 7bit

Received: from tahoe.NetEdge.COM by (ccMail Link to SMTP R6.00.02)
	; Thu, 22 May 97 01:41:37 -0500
Return-Path: <>
Received: from by NetEdge.COM id AA25635; Thu, 22 May 97 01:39:29 EDT
Received: from NetEdge.COM by id AA28758; Thu, 22 May 97 01:35:45 EDT
Received: (from list@localhost) by (8.7.3/8.7.3) id BAA13875; Thu, 22 May 1997 01:31:39 -0400 (EDT)
Resent-Date: Thu, 22 May 1997 01:31:39 -0400 (EDT)
Message-Id: <>
From: "Dwight Hughes" <>
To: <>, <>
Subject: Re: Virtual machines
Date: Thu, 22 May 1997 00:38:31 -0500
X-Msmail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1161
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Resent-Message-Id: <"HRm1v3.0.lO3.xezWp"@euclid>
X-Mailing-List: <> archive/latest/89
Precedence: list

| From: Terrence W. Zellers <>
  [  snip  ]
|    I'd like to jump in here.  Let me say at the outset that I haven't
| even *looked* at the JVM architecture and know nothing about it save
| passing mentions I've encountered.   But as a more-or-less expert on
| the original real "VM" from IBM I'd like to make a suggestion to
| anyone *thinking* about what an idealized virtual machine should do.

Well, if you would like to see what you are describing here in the JVM,
don't even bother looking! JVM is a miserable excuse for a VM even
in comparison to other "normal" VMs, never mind something like this.
|    IMO it ***MUST*** be capable of fully virtualizing itself in 
| execution, not just emulation.   This means it must have a paging
| prefix algorithm, the ability to intercept any instructions which
| deals with "real" rather than "virtual" hardware,  and the
| interception and determination of any illegal program state (invalid
| opcode, invalid address, etc).   Admittedly this is not trivial but it
| buys the ability to completely virtualize a process as if it were
| running on "real" hardware.   

Can this be done with an i486 or Pentium? Does it require special
hardware to pull it off properly?

|     This in turn, buys the ability to create an OS which can run
| indefinitely deep under itself. (I've reliable reports from IBM of VM
| running 8 levels deep).  That means that you can test different
| versions of the OS on one live running box.  You can concurrently test
| different versions of the same program.  You can create safe "cells"
| for users to run OS level software without danger of them corrupting
| your "real" OS.  You can create and test software for hardware which
| **doesn't exist on your real system**.
|    As someone who knows VM very well, I'm afraid I'm not communicating
| this very clearly, but it's part and parcel of what I work with every
| day.
|    Anyway there is some discussion of this kind of thing, though not
| as deep or detailed as I hoped it would be on the archive logs of
| FREEVM-L on  The list is pretty much dead
| I'm afraid, but anyone really interested ought to at least look at
| what the real, honest, original VM has been doing for years.  The
| mainframe may (or maybe not) be dying, but I think the idea of a
| self-idealizing virtual machine is valuable enough to perpetuate.
|       ---------------------------------------------------------
|     I think that in the argot of the present company I'm trying to
| say that the architecture should be such that the OS itself can be
| implemented as an instancable(sic?) object (forgive me, I'm fairly 
| new to OO as well).
|                                                    -- TWZ

Thank you very much for all this information -- this could also make a
great contribution to the LispOS side of this project, perhaps more
than the LispVM side. The ability to self virtualize is one hell of
a security (and reliability) mechanism without weighing everything
down with paranoid security measures down to the lowest level. We
want our system to be fully reflective, but I must admit I had not
thought about it this deeply. Some things we have been looking at
are VMs as first class objects (meaning there could be multiple
completely independent instances of any VM or any number of different
VMs, each would behave as any other object in the system (once no
longer needed the garbage collector would clean it up, encapsulation
from the OS would be automatic, they could be stored, transmitted,...).
We have also considered environments/address spaces as first class

I need to find out more on this.


-- Dwight

PS: would you mind if I posted your letter over to the LispOS side?

--simple boundary--