aspose file tools
The moose likes Beginning Java and the fly likes Does the JVM actually RUN code? (And other related questions) Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

Win a copy of Head First Android this week in the Android forum!
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "Does the JVM actually RUN code? (And other related questions)" Watch "Does the JVM actually RUN code? (And other related questions)" New topic

Does the JVM actually RUN code? (And other related questions)

Lou Cabron

Joined: Aug 29, 2012
Posts: 3
I posted this on another site, but I'm still struggling to understand the answer. I realized I don't know exactly what the JVM does with my code. Java World ran an interesting article which implies that all the JVM does is convert the compiled byte code from a class file into machine-level code, and then hands it off to the processor to execute. So does that mean the JVM's role is really to be more like a memory manager -- holding variables and objects, maintaining their values, scheduling threads, etc. (In Head-First Java, there's an interview with the JVM where it brags that it runs the program - so maybe I guess how exactly we're defining "run"...)

And my confusion about this brings up some related questions...

-- Did the JVM ever run code? I have some very old Java books which talk about JVM implementations that send the byte code to an interpreter (rather than to a just-in-time compiler which converts it into machine code). So I guess specifically here I'm asking, was that interpreter running the interpreted code? Or was it still just passing it off to the microprocessor...

- So how is what the JVM doing any different then from what a regular piece of software does -- say, Microsoft Word? Doesn't Word ultimately just hand off its own calls to the processor to execute? (Maybe I should be asking whether everything is ultimately handled by the microprocessor -- albeit usually through the main operating system?)

-- Here's a specific example that shows where I'm confused. I've been trying to visualize the answer to a specific question: Where exactly does a JFrame come from? I know the old java.awt.Frame objects were "heavyweight," which I guess means they were spawned from pre-existing Frame code in whatever underlying device was running the JVM. But if JFrame's are "lightweight," then where exactly are they coming from? Is there actually code in the JVM implementation that knows how to draw windows onto a screen, which gets executed without going back to the underlying machine or machine processor?
Jayesh A Lalwani
Saloon Keeper

Joined: Jan 17, 2008
Posts: 2631

How do you define running code? What is "running code" exactly? Philosophically speaking, all code is interpreted

So, what happens is that there is something called machine language. Every kind of CPU has an instruction set, and programs are made up of instructions using that instruction set. When you execute a program, you are essentially telling the CPU to execute the instructions in the program. The CPU retrieves an instruction, carries out the steps required the fulfill that instruction, then goes to the next instruction... Repeat rinse. Now you might say that this is Execution. I can call it interpretation. The CPU is interpreting an instruction written in machine code, and flipping switches in the rest of the machine to do the work. Essentially execution is interpretation.

Anyways, lets put the interpretation-execution dichotomy aside for now to get to the meat of your question: what does the JVM do exactly

First we need to understand first what the java compiler does. The java compiler takes code and converts it into java byte code. This byte code is packaged into class files. The class file is basically a series of instructions using an instruction set that the creators of java have defined. When you execute the class file using the JVM , the JVM "executes" the class file. The previous versions of JVM would read each instruction in the class file, and based on the instruction, it would do the things that the instruction requires. Essentially the JVM followed the same steps for every instruction

A) parse the instruction
B) lookup the piece of machine code that corresponds to the parsed instruction
C) actual execution of the code.

The problem with that is that its inefficient. Each instruction requires, parse-lookup-execute. Even after it has already executed a block of code, it needs to parse and lookup the instructions every time. So newer JVMs reduce this overhead by Compiling the java byte code into machine code. Basically, when the JVM a block of java byte code for the first time, it parses it and uses the lookup to find the corresponding machine code. However, instead of executing the code, it writes the machine code in memory, then executes it. Next time when it sees the same block of code, it just finds the block of corresponding machine code and executes it.

Well modern JVMs do a lot more like optimizing the machine code as it executes it, but hope you get the idea
Mansukhdeep Thind
Ranch Hand

Joined: Jul 27, 2010
Posts: 1157

Welcome to the ranch Lou. I had asked a question on the similar lines about the JVM implementation. You may read through this thread for getting a better grasp of what it does. Additionally, there is something called the JVM Specifications. Those are the instructions / op-codes / mnemonic codes etc.. that Jayesh is talking about. That is how the JVM interprets your byte code and sends the respective instructions to underlying platform/CPU.

~ Mansukh
Jeff Verdegan

Joined: Jan 03, 2004
Posts: 6109

Lou Cabron wrote:
- So how is what the JVM doing any different then from what a regular piece of software does -- say, Microsoft Word? Doesn't Word ultimately just hand off its own calls to the processor to execute? (Maybe I should be asking whether everything is ultimately handled by the microprocessor -- albeit usually through the main operating system?)

You're right. The JVM is just like MS Word in many respects. It's a piece of software that runs on your computer and executes certain instructions based on its input, which in turn causes changes to the overall state of that software and sends data to its output. That's all any software is and does.

The main differences--and they are really only quantitative, but are so large that they may as well be qualitative--are 1) The JVMs inputs are much more primitive, or "low level", and 2) The result of #1 is that the JVM has a much less rigid combination of possible input/state/output possibilities--that is, it can vary its overall high-level behavior much more widely than Word can.

It's kind of like the difference between your microwave oven and your PC. They both have a CPU that takes input, manipulates state, and produces output.

Your microwave has a high-level set of operations that produce a limited variation in behavior: "Cook for N seconds at power level M." Same with Word: "type, cut, copy, paste, set font size, ... etc. ..."

Your PC, on the other hand, has low-level operations that get put together in very complex ways to produce widely different behavior. "Add 1 to this memory location; copy that memory location's value to this other memory location; send these bits to that output; ... etc. ..." Repeated bazillions of times in very rapid sequence, that give us very different high-level behaviors. Same with the JVM. Its "add, move, output" operations are just software like Words "type, copy, paste" operations, but the JVM's operations correspond more closely to similar low-level operations on the hardware, and so, by executing the JVM's operations bazilions of time in rapid sequence in vastly differing patterns, we can make the JVM act like Word, or like a web server, or like a video game.
Consider Paul's rocket mass heater.
subject: Does the JVM actually RUN code? (And other related questions)
jQuery in Action, 3rd edition