Unconfigured Ad Widget

Collapse

Announcement

Collapse
No announcement yet.

Java Journal: Rise of the Virtual Machine

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Java Journal: Rise of the Virtual Machine

    ** This thread discusses the article: Java Journal: Rise of the Virtual Machine **
    ** This thread discusses the Content article: Java Journal: Rise of the Virtual Machine **
    0

  • #2
    Java Journal: Rise of the Virtual Machine

    ** This thread discusses the article: Java Journal: Rise of the Virtual Machine **
    It's worth noting that virtual machines have existed even prior to the concept of p-code and Pascal and many of us have been using them for years. IBM began experimenting with the concept of the virtual machine back in the late 60s and early 70s when it created its first virtual OS. The entire OS was constructed to be "interpreted". Listening to old-time IBMers explain how they debugged the OS is an interesting story. They ran the instructions through an interpreter that existed on a mainframe that fielded intermediary OS langauage statements (like p-code), and then interpreted the code "on the fly." When they ran into a bug, they had to determine if it was a bug in the virtual OS, or a bug in the interpreter, and everything about the execution speed was extremely slow. As an architectural construct, this represented the first layer of abstraction between the OS and the hardware, separating the commands received by virtual OS from the hardware that implemented those commands. In order to facilitate languages to run inside this virtual OS, IBM had to add a second layer of abstraction: something to allow a compiled program running in the OS to not be concerned with specific hard-coded memory addresses or device tables. This led them to develop a radical idea for its time, called "Single Level Store." (I know. You always thought Single Level Store referred to the 7-11 at the corner, but this was even before those Single Level Store removed the confines of direct memory addressing from the concern of programmers. If the programmer's program needed more addressable space, it asked the virtual OS to find it. The virtual OS sent an instruction down through the control language to the interpreter, and the underlying control program coughed up the location. The virtual OS then took the programmer's request, and connected it to the memory location. This development of Single Level Store opened up an entire new realm to programs by virtualizing the memory matrix. It was, in fact, a second layer of abstraction that confounded traditional programmers who felt extremely insecure not knowing exactly where their bits and bytes resided in main memory. It also made debugging a pain, so they had to include a substantial new invention called an integrated debugging facility. Every instruction was logged to a specific place as code was interpreted, so the programmer could "see" exactly what was happening. It was revolutionary. A third layer of abstraction separated the programmer from the data: Instead of creating hard-coded addresses for databases and then building access paths to retrieve records (something quite common on the S/370 architecture of the time), IBM developed a unique structure called a "relational database". This was a tremendous, expandable "table" of records that were accessed using IBM's previous experiments with Index Sequential (ISAM) algorhythms. The virtual OS received the instructions to obtain a record, and the OS constructed the necessary instructions to pass along to the underlying control program, which spit out the data. What an amazing idea! No longer did you, as a programmer, need to know exactly where a record resided, either on the disk or in the file. The first product released with this virtual machine was called the IBM System/38. At first nobody though it could work, but it did! All told it was a moderately successful product, but it had a few problems because the hardware was not yet advanced or powerful enough to manage the such a complex system. Still, it was the leading edge for its time. The entire hardware platform was then removed and refreshed in the late 80s, (an incredible feat, because it allowed all the applications that had been written for the System/38 to be transported without recompilation, directly to the new machine. All those layers of abstraction proved it to be incredibly agile in a migration.) IBM called the new package the Application System/400 -- what we know as the AS/400. Of course, the AS/400's hardware platform went through numerous iterations, while the virtual machine riding on top stayed pretty much the same. Then IBM rewrote the entire underlying code package for the OS/400 operating sytem for 64 bit computing, to take advantage of the RISC chip. Meanwhile, the great majority of the applications written at the second and third layers of abstraction never had to be touched. In fact, this machine was so "virtual" that IBM began swapping hardware components with the RS-6000 RISC-based machines, to reduce the cost of developing dual platforms. At the end of the day, the differences in hardware of an AS/400 and a RS-6000 were mostly cosmetic -- even though one ran OS/400 and the other AIX. Today, of course, the AS/400 is called the iSeries. It's heritage as a virtual machine -- and the architecture that allows it to function -- make it the perfect box for running Java applications and other 2nd generation virtual machine structures (Yet a fourth level of abstraction.) It also makes it the most resilient machine available to handle things like virtual partitions (called Logical Partitions) in which other operating systems may be run (Linux and Unix for example.) And it's hardware abstraction layer allows other sub-processing chips, like Intel chips, to be plugged into it to allow it to run things like Microsoft servers. In fact, most of the advances that have driven the computing model forward were built around the requirements that were developed as a result of those first IBM's virtual machine experiments. Things like DB2, virtual memory, virtual address space, (and including Microsoft's Hardware Abstraction Layer HAL), etc. were all derived from similar requirements that were leading computer scientists down similar paths. But the iSeries' parents and grandparents had already confronted and resolved the technical issues. Even the need to have products like High Availability were the direct result of the needs created by this virtual machine architecture. So, virtual machines go a lot further back than the JVM, and even further back than Pascal compilers and p-code. Thanks for the excellent article, Micheal. Tom Stockwell

    Comment

    Working...
    X