Virtual Machine Discussion

The continuing hype over Java continues to bother me. The first time I came across Java, Sun's marketing department was busy rewriting computer history by saying it was the only platform where one could "write once, run anywhere." That mantra was repeated by Java language fans who lacked a sense of history and scope. Java fans may rightfully claim it is the most successful attempt, but there have been others.

Take for example the UCSD p-System. There, the language was an extended Pascal, but the essential qualities were the same as Java-- the language was compiled down to a platform-independent virtual machine, and that virtual machine was ported to a number of different platforms. I don't remember the exact date for this, but it was during the early to mid 70's.

Another example is the Pick operating system. This time the language was BASIC, but it was executed on top of a virtual machine that was common between ports. I believe the dates for this were mid to late 70's.

The Apollo Guidance Computer (AGC) designed in the mid-1960's and used on the moon missions also used a pseudocode system for some of its calculations.

This is not to say the Java language isn't new and interesting (which it isn't). And certainly the Java virtual machine is different from UCSD p-System or Pick in that it support object orientation at the virtual machine level. But this seems to me to be a refinement, not a fundamentally new concept. -- JohnPassaniti

I thihk you are missing the point John. Java has never claimed to invented all of these innovations. In fact, it has never even claimed it was the first environment to support WORA. Where are you reading this stuff? Could you point me to the quotes by Gosling that say this? You sound bitter. Java merely attempted to support WORA by using tried and true practices. Java tried to include the best of CeePlusPlus, Simula, SmallTalk and others. I've never heard any at Sun ever say that Java invented PseudoCode, the VirtualMachine, or GarbageCollection. However, it is clear to most people that Java has improved on some of these basic concepts. Anyone whose worked on or with languages for over 10 years has come across GarbageCollection, VirtualMachines, and PseudoCode a bunch of times. Hell, even the Dbase Compiler, Clipper had GarbageCollection, a VirtualMachine, and PseudoCode. -- RobertDiFalco

Comments added by others:

But this seems to me to be a refinement, not a fundamentally new concept.

So, isn't that what we're supposed to do? Refine and improve ideas? How could you actually criticize something for refining an idea. i.e. "Those bastards, they actually tried to improve on some fundamental ideas. How dare they!" I mean, really, are you going to give SmallTalk sh%^ because the didn't invent the idea of an Object? Come on.

Don't forget SqueakSmalltalk, which runs on a bazillion platforms and has portable image files.

Good point, if you talk about Smalltalk generically. I forgot that initial Smalltalk implementations used a virtual machine. I knew about SqueakSmalltalk, but I was more interested in historical examples. Squeak came after Java.

Another example is emacs lisp, which, given that emacs runs on practically every hardware/os there is, is more "write once, run everywhere" than Java is.

The claimed innovation in Java's virtual machine is its static type-state safety, which previously had only been seen in research papers/languages. It is mostly about combining efficiency with security. UCSD P-Code didn't have the security. Squeak doesn't have the efficiency. To get both at once is interesting for small platforms which don't have CPU power to waste, nor hardware memory protection, yet want to run untrusted code. -- DaveHarris

The concept of a reasonably well-defined and stable VirtualMachine was and is fundamental to Smalltalk. The key architectural distinction between the Smalltalk VirtualMachine and the p-System is that the Smalltalk environment is CausallyReflective?. I believe that Smalltalk was the first environment to integrate the reflective nature of Lisp with the VirtualMachine concept elaborated in the p-System. The Pascal compiler ran outside the P-System; there was no PascalEnvironment?.

The definition of Smalltalk byte codes was heavily influenced by p-codes of the p-System; the wrinkle was to turn the system on itself and use bytecodes to reflect and control the execution state of the system.

Another interesting virtual machine was the Forth VirtualMachine, from which the PostScript family of virtual machines descended.

Finally, the big Microsoft applications -- Word and Excel, for sure, and perhaps others, are written using private, internal virtual machines. This is the mechanism that allows them to be readily migrated between alternative platforms.

-- TomStambaugh

Tom, here's a link to some information about Microsoft's p-code technology (http://msdn.microsoft.com/library/backgrnd/html/msdn_c7pcode2.htm). I'm pretty sure that Microsoft has long since abandoned this stuff (note the date on that document). My recollection is that MS's p-code emulation was implicated in the Macintosh Word 6.0 fiasco, and hasn't been heard from since.

I should also point out that the reason MS used p-code emulation at all was to reduce code size, not for portability. MS has, to my knowledge always shipped different binaries for PC and Mac applications, so there's no portability advantage to using p-code. Besides which p-code will only buy you CPU-independence, it won't do anything for operating system portability.

-- CurtisBartley

Why couldn't a p-code interpreter offer you operating system portability? Just add opcodes that abstract operating system services. -- JohnPassaniti

You could have op-codes like CreateWindow? or ShowStandardWindowsOpenFileDialog?, but then you'd have to a) write the code underneath to make these opcodes work and b) if you ran them on another platform, like say, a Mac, your program would still look like a Windows program. I guess the key point here is that although you can achieve portability for some basic operating systems services like memory management, a lot of services don't map well from one OS to another. For example, even file operations don't map well between the Mac and Windows, since Macs have this weird resource-fork notion. A secondary point is that even when portability is achievable, it's not a p-code sort of issue. Traditional libraries can serve the same role, even if you're compiling to native code. -- cb

I'm sorry, I don't see the problem. Writing that you would have to write the code underneath the opcodes to make them work seems irrelevant-- we're talking about a p-machine here! You already have to write all the code underneath the opcodes! I don't understand the claim that a Mac program would still look like a Windows program at all. If the opcodes mapped to equivalent services, one would expect an application would look like other native applications.

Likewise, I don't see the problem with files either. If we were talking about porting Macintosh file operations to Windows, sure, there might be a problem. But I thought we were describing a p-machine that wasn't for a specific platform, but an abstraction that would presumably find a common subset between platforms. For example, it doesn't matter that under Windows the directory separator is a backslash and under Unix it is a slash. Code written for the virtual machine would define a standard, and the virtual machine would translate as necessary.

You're right that you don't need p-code to effect this sort of portability. Really, when we're talking about p-code, we're just talking about a layer of indirection to some portability library. Or put another way, I see very little difference between defining an abstraction behind a p-code or behind a library function call. The only difference would be physical and/or temporal-- a p-code opcode execution would likely take less physical space, but would also take more time. -- JohnPassaniti

It looks like we agree that p-code is orthogonal to OS portability, and presumably we agree that p-code can provide CPU-portability. The remaining question is whether a library can provide OS portability. Even here I think we agree that this can work for a common subset of OS functionality, as you mentioned above. However, I also think that Microsoft Word and Excel (see TomStambaugh's comment above that I was responding to) drastically exceed whatever that subset may be, on Windows and the Mac both. Microsoft no doubt does rely on some sort of portability library to share as much code as possible between the Mac and Windows incarnations of their applications. However, they are also writing OS-native code for each platform as well, in order to get the applications to look and behave the way the users of the respective platforms expect. -- cb