I've been looking to find exactly what the jvm is in physical terms. While I understand that it takes the bytecode, converts it to platform specific binary, and does all the thread handling, garbage collecting, and so on...I have yet to understand what is it physically. When speaking specifically about java APPLICATIONS, is it just the java executable that gets invoked when you type >java at the command line. It isn't something that is resident, already running on the computer, is it? Is the JVM a one to one relationship with the program? i.e. is there one jvm running for each >java myprogram that I start? Is this the same as the java runtime? or java interpreter? Thanks
Phil Mahone<br />scjp1.4<br />I used to be clueless but I've turned that around 360 degrees.
To answer a couple of your questions... It isn't something that is resident, already running on the computer, is it? You are correct, the JVM gets invoked each time you launch a Java program. Is this the same as the java runtime? or java interpreter? These terms are often used interchangeably with JVM. However, Java Interpreter can be misleading as discussed (on page 2 of chapter 1) in the treatise I mention below. Is the JVM a one to one relationship with the program? i.e. is there one jvm running for each >java myprogram that I start? Yes. For more detailed information about what the JVM is, take a look at Inside the Java Virtual Machine by Bill Venners. He has many of the chapters printed online. Chapter 1 & 5 are probably most applicable to your questions.
To give you a somewhat general, but concrete idea of the JVM, imagine how your CPU runs code. It has a bunch of registers. (A register is a circuit that is a sequence of 32 wires...there's either a voltage on a wire, meaning it represents a 1, or no voltage, meaning it represents a 0.) Each register is given a purpose in the CPU, so the CPU looks at some registers and treats the content as data, and it looks at one other register and maps the bit sequence to an instruction (for instance, add the contents of data register 1 to the contents of data register 2 and place the result in data register 3). The JVM is basically a CPU, except it's implemented in software instead of hardware. Just as a program runs on a hardware CPU by loading data into the data registers and instructions into the instruction register one after another, the JVM runs byte codes through its software CPU. It's not called a "virtual machine" for nothing. So the JVM's job is to take the code that's been compiled for it--class files--and run the bytecodes by translating them into the machine language that is unique to the underlying hardware platform. So a JVM that runs on a PC can take a Java program and translate it into the machine code for Intel chips, whereas the JVM installed on the Mac platform will take those same bytecodes and translate them into machine code that runs on a Motorola PowerPC CPU. That's how Java carries off platform independence--in C, you have to recompile for every CPU that has a different machine-level instruction set. In Java, you compile for the virtual machine, and let the VM translate for you at runtime. Make sense? sev