The virtual machine revisited

The virtual machine revisited

Summary: George Ou hit the nail on the head when he wrote "The dumbest gripe with Windows Vista to date."Does anyone remember the original Basic interpreter found in the Apple II and in PC-DOS?


George Ou hit the nail on the head when he wrote "The dumbest gripe with Windows Vista to date."

Does anyone remember the original Basic interpreter found in the Apple II and in PC-DOS? How about the Pascal-based p-system from UCSD -- introduced in the late 1980s?

The early days of integrated software suites were no better. I remember one particular software suite that had to load its 256KB interpreter (an old term for today's run-time engines) in order to execute the command to clear the screen! On a 640KB machine, this represented a lot of overhead. The MS-DOS "" and today's "cmd.exe" are none other than simple run-time interpreters for executing commands.

All of these tools were attractive because they permitted non-programmers to better utilize processors more powerful than the operating system running on those machines.

Well, Java and .NET are just the latest software tools to take advantage of an important side-effect of Moore's law (that processing power doubles every 18 months or so.) Of course, a modern virtual machine, such as Java's JVM or that of .NET, is a great deal more powerful than the code of yesteryear.

Software capabilities always lag behind the hardware they run on -- as evidenced by the fact that Windows XP Professional is quite capable of running on a Pentium II processor running at 300 MHz. No, it's not pretty, but it will do everything the user needs. But, put that same OS on a 3,000 MHz (3 GHz) PC and watch it fly. The fact that today's operating systems (either Windows or some flavor of Unix/Linux -- including MacOSX) can run on such a wide range of processor speeds is itself quite remarkable.

In 1969, Unix was born with the concept of OS portability in mind. The development of C made it possible to port any software written for Unix on one platform to run on Unix on any platform simply by re-compiling the C source code using the compiler accompanying the OS. Once the original version of Unix was re-written in C, porting Unix from one platform was just as straightforward.

The virtual machine model dates back to the early 1980s -- on IBM mainframes. This model permitted dissimilar operating systems to run side-by-side on the same hardware -- by running under a virtual machine which effectively tricked the OS running under it into thinking is was running either by itself on the native hardware or even on other hardware the virtual machine OS was emulating. This made it possible for developers to leverage expensive but under-utilized hardware for cross-platform software development.

It's the marriage of these two concepts that brings us to today's virtual machine design. Returning to the thrust of George's article, it is important to understand the job at hand in order to determine which tools are appropriate.

For instance, the Java Virtual Machine is ideally suited for web-based applications. The JVM itself (call JRE for Java Runtime Environment by Sun) is OS-dependent -- Windows, Solaris, Linux, or Macintosh -- but only the Windows flavor is unique. The others are all variations of a basic Unix implementation of the JVM -- making porting almost as straightforward as re-compiling the source code. As a result, versions of the JVM have now been ported to handheld computers running PalmOS, RimOS, SymbianOS and others. The only other component necessary to make web-based Java applications (called applets) work seamlessly across the web is a browser-dependent plug-in.

Prior to the advent of the personal computer, the cost of hardware far exceeded the cost of the programmers. With the commoditization of personal computing, just the reverse is true. Add to this the fact that processors are much faster than they need to be to keep up with the software available today, and you have a very good argument for using virtual machine-based tools for a lot of software development tasks -- but certainly not all of them.

Sure, a small dedicated OS (such as that on a cell phone or handheld computer) can be designed around a virtual machine for a few dedicated tasks, but as soon as you introduce pre-emptive multi-tasking to the list of capabilities a general purpose operating system must have, the suitability of the virtual machine model must be called into question.

Topic: Operating Systems

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Is portability important?

    That's the question to ask to determine if you will use a VM. If you write code in Java, you can port it anywhere (supposedly), so theoretically you can pick and choose hardware vendors based on performance and other factors. This is the strength of VMs.

    This seems to be true until you consider .NET. .NET is NOT portable, AND you take the performance hit for using a VM. Hmm, slow and vendor lock-in - just who is pushing this tech anyway?
    Roger Ramjet
    • Not very important for servers

      Portability is not important compared to performance for servers. But for client applications, portability is very nice to have. It can give corporations option to buy non-Windows systems. Currently Java is not up for the quality to develop Windows standalone systems, they develop using native platforms and therefore very poor business applications available for Mac and Unix/Linux.
  • What you and George have completely overlooked,

    is JIT (just-in-time) compiling that Java Virtual Machine does (No, it is not optional, but rather the default feature of JVM). So in essence, you are NOT running the interpreted code, but instead, the compiled code.

    It is bogus to say that Virtual Machines are theoratically slow. They may be slow due to bad design by vendors. But a properly designed Virtual Machine which does pre-compiling or just-in-time compiling can be as fast as a C-complied code. Now add the benefits of platform independence, and you have quite a winning solution...
    • I care about actual implementation, not theory

      From every implementation of a Java application running on Windows that I've seen, they were dog slow and massively bloated.
      • I fully agree!

        Java is currently web-site tool and they are very bloated!
      • you only care about the windows platform. anything that is not M$ will run

        slower on that massively serial piece of human ego.

        take your friend and go yank someone else's chain.

        java programmers don't need that windows monstrocity to make their applications, not just cute little explorer ditties, work.

        just give us a hardware abstraction for the compiler/interpreter to use and watch java fly.

        but you've got your interest so far up M$ backoffice interface that you'll never see it.

        who is this wagner guy anyway?
        some lacky of yours?

    • No matter how well designed an OS ...

      ... might be (or any other application for that matter), Just-in-Time compiling cannot be as efficient as native machine code. This isn't at all obvious unless one has taken courses in compiler design theory. A well-designed compiler will be able to utilized multi-pass techniques to recognize optimizations suitable for the specific hardware in question. These optimizations cannot be performed in real-time without taking a severe performance hit.

      In truth, the only thing more efficient than native pre-compiled code (in any language) is code written in assembler by a master programmer. Of course, today assembler-language progammers are few and far between and cost way too much to hire for OS development -- let alone application development.

      In the end, a high-performance optimizing compiler is almost as good as a Human assembler language programmer and it is far less expensive to buy a faster processor than it is to pay someone to code in assembler.

      Even then, a highly-skilled applications programmer -- someone with experience with C, C++, Fortran, COBOL, Basic, or a dozen other nearly forgotten languages is too expensive for many application-development projects.

      The virtual machine model found in the likes of JVM or .NET is well-suited for any application development project where hardware independence is more important than raw performance.

      Hardware independence is the important point here. In order to be hardware independent, a VM model must assume some lowest common denominator for the virtual machine it emulates -- and hadware emulation brgins with it overhead.

      That virtual machine need not be based upon any real-world architecture nor can it do anything which requires knowledge of the underlying hardware. In fact, only the runtime-engine (or the JIT compiler) needs to know anything about the hardware it runs on -- and it has to be written in a traditional programming language and pre-compiled for that specific hardware -- preferably using a high-performance compiler.
      M Wagner
  • One of my points is that commercial software should not use Java

    If you're writing something for 1000 people to use in a corporation with a mixed environment and that one corporation has to bear the cost of the entire development project, using a high level language like Java makes some sense. If it?s not a mixed environment or if you?re going to go through Citrix or terminal services where the client OS doesn?t matter, you?d be much better off doing this using .NET because it?s more specialized for Windows and will run faster with less memory. Your other option is to use ASP.NET and run the application though a browser, but I?m not a fan of browser based software.

    This is a far cry from suggesting that Windows itself or Solaris or Linux be written in a language that requires a run time engine on a conventional hardware platform. As for ?shrink wrap? commercial software, I?m not in a mood to buy or install software from someone too lazy to develop it in C or C++. I?m not in a mood to have bloated Java software slowing down my 3.6 GHz PC because I want my software to react quickly. There is no ?cost? excuse when you?re talking about mass distribution software because the development costs are spread out. This is why there are NO successful implementations of a Java based Office productivity software or anything else major.
    • Commercial Software

      You need to be more directly explicit about your definition of commercial software. You're referring to client-side software with a very rich GUI, such as an office suite. There's plenty of commercial software out there written in Java, that should be written in Java, that runs on servers. There's also more light weight Java GUI client side apps were, in they are written well, run fine.
      • I'm not talking about server side implementations

        I'm not talking about server side implementations that have light client side requirements. I'm talking about stand alone applications that run on the client side, applications such as router/switch/firewall management software from Cisco that's uses the JRE. It's disgustingly slow and bloated. For a simple device management interface, it takes around 60 megs of ram and takes forever to load (if it loads at all). This doesn't run fine.

        Speaking to the software companies:
        If you're going to write software for the Windows platform which is more than 90% of the market, you better give me something that's at least semi-optimized. Whether or not your applications run on other platforms is your problem, not mine. I don't want to suffer because you want to write your application only once with Java.
        • I agree your point, but ...

          I agree fully with your point made. But the scarece-ness of Java stand-alone has nothing to with performance. Stand-alone desktop systems written in Java can run with reasonable performance with modern day cpus. But the problem is with the AWT/Swing java packages they built. They are too sloppy to build Windows level quality desktop s/w. They are not only ugly, but also don't work like Windows. For 90% users, they have no reason to pay to buy Linux-class software. They didn't buy to run substandard s/w. That's what Java-based commercial developers have problems with. There are some Java-based stand-alone systems. Simply they are not competitive against natively written gooodies. This is why Eclise SWT project got started to improve this aspect. I worked on this area over 8 years. I don't see that you will see competitive Java-based stand-alone systems commining along in the near future. It may when Microsoft rejoin and make Java work for Windows, then you will see lot of goodies written in Java.
          • I think you're mostly right

            "But the scarce-ness of Java stand-alone has nothing to with performance"

            You're mostly right on that, stability is probably the deciding factor. The fact that it's so slow is secondary but still important. All the applications that run on JRE are horribly inconsistent depending on the computer you run it on.

            The fact that Java applications run "OK" on a new computer is not the reason I bought a fast computer. I bought a fast computer to run my applications blazingly fast, I didn't buy it so that software companies can take a short cut and cheat me of my speed gains.
    • George too is lazy.

      First paragraph made sense (I didn't appreciate the last sentence..) Why did you write the second?

      I do agree that the OS language is meaningless. You just buy that. It loads your vitrual machine <g>!

      But George.... you should learn to be nicer and less insulting to the inteligent people out there who do see the benefit of vitrual machines (like the JPL and embedded systems folks). The Java advantage is in the small and the large. The middle works too however. Java serialization (stolen I know... I did CORBA too) between JVM means nothing to you? Class portability between mainframe and PC means nothing to you? We don't live in the same world my friend. "As for shrink wrapped" commerical software... I hope it dies. Aren't we supposed to be about the service now (I'll accept XML as a serialization technology too.. so we'll meet the .Net folks in the middle). And in 2005+2006 that means virtual machines. Business logic is king in the service. The smart folks writing the vitural machines are doing a great job of optimizing bytecode execution. Admit it... for what you get in the way of libraries and ease of development both .Net and Java are awesome.

      I'm surprized with your arrogance that you would not be requiring everyone to write their "shrinked wrapped" applications in assembler for their specific platform. Or are you too "lazy" for that optimization? Surely you're much smarter than the compilers out there aren't you George? Why put down people? See.. it doesn't feel nice and makes you act supidly. It's not nice and makes people not listen to you when you actually have something worthwhile to contribute. You could have made your point and featured the strengths of the current desktop application development environments. Don't attack...explain and educate. That's why you're a jerk my friend.

      The fact that you can not see the benefit in a browser based application is no surprize either. With a capable (standards based) browser and smart content folks, you can get what you want from it. It's a platform to grow from.. not whine about or put down. If you really dislike them, show us better. Again.. explain and educate, don't degrade.

      You should try to loosen up... and be a lot less insulting. Arrogance requires talent. Putting down requires ignorance only. When all you do is put down, we mistakenly assume you are ignorant.
      • Actually wouldn't mind software in Assembler

        If a company put out software in Assembler and it matched feature sets, I'd pay a premium for it. Since this is very rare (if ever), applications in C and C++ would have to suffice.

        If I say I don't like browser based applications, I'm telling you my personal preference. I'm not trying to put you down or anything, I'm just telling you how I feel about something. If you don't agree, no problem but don't start this whining that I'm somehow insulting you because I don?t like browser based applications. It doesn?t make me look bad; it just makes you look like a cry baby.
  • Check your dates

    UCDS's Pascal P-code machine dates back to the late 70's not the late 80's. It predated the original IBM PC and was offered as one of the original operating system choices. I remember running this system on my first PC, a Z-80 based computer with only 48k of RAM.

    Also IBM's Virtual Machine technology is also much older than is claimed in the article. I believe it was developed in the early 70's and was frequently used by systems programmers to test and run other IBM operating systems. In fact I seem to remember that there was at least one IBM operating system that actually ran faster under VM than it did natively.