 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / First Aid / February 2005Question on JVM and Bytecode
I am trying to get my head wrapped around the concepts of Bytecode and Java Virtual Machines. This is my understanding (right or wrong) so far. When I write a java program and compile it, the code that gets generated is not object code, as would be generated by a different kind of compiler. It's this thing called bytecode. Similar to object code, but not exactly the same. In order for me to be able to run this program I need to run it through a piece of software called Java Virtual Machine. JVM takes the bytecode and runs it. I guess, at no point does true object code get generated, nor does an executable module. Does this sound close to correct? If this is correct, what exactly is the advantage of never creating an executable load module? It seems to me that JVM is kind of performing the same function that the Linker performs for other languages. It's creating something that can be executed. If that's so, what's the advantage over the traditional approach? That is, what's the advantage of bytecode that can be executed over a load module that can be executed? Thanks, Ken Ken, I'm no Java expert, but I know something about bytecode, having used Smalltalk for 12 years, and having written bytecode compilers and virtual machines myself. > I am trying to get my head wrapped around the concepts of Bytecode and Java > Virtual Machines. This is my understanding (right or wrong) so far. [quoted text clipped - 7 lines] > piece of software called Java Virtual Machine. JVM takes the bytecode and > runs it. Right so far. > I guess, at no point does true object code get generated, nor does > an executable module. Not quite right. Some virtual machines can selectively compile bytecode into native machine code for the platform they're running on. This is called JIT, or Just-In-Time compilation/code-generation. And some Java compilers can generate native code for the particular platform they're designed for. > Does this sound close to correct? If this is correct, what exactly is the > advantage of never creating an executable load module? It seems to me that [quoted text clipped - 3 lines] > advantage of bytecode that can be executed over a load module that can be > executed? Two main advantages I can think of. (1) The bytecode is platform-independent. That means you get object-level binary compatibility between programs running on different platforms. That in turn means that, provided the VM has been implemented correctly, a program will execute identically on every platform. (2) When Java bytecode for a particular class is loaded at runtime, the VM actually checks the bytecode for consistency before running it. So if a rogue Java compiler (or malicious hacker) produces bytecode which, say, tries to fool around with the VM value stack in ways which might fool the VM, this can be detected before any damage is done. This is particularly important for guaranteeing the integrity of Java applets running inside web browsers, to ensure (provided that the VM is itself trustwothy) that an applet can't gain access to your private data. Experts may be able to amplify this, or correct any mistakes. Cheers, Paul [....] >> Does this sound close to correct? If this is correct, what exactly is >> the [quoted text clipped - 26 lines] > > Experts may be able to amplify this, or correct any mistakes. I can amplify this. Platform-independency (1) and security (2) were the 2 main goals of the JVM, as stated in its specification (paragraph 1.2) http://java.sun.com/docs/books/vmspec/2nd-edition/html/Introduction.doc.html#3057 > Cheers, Paul Regards, Thomas Thomas > I can amplify this. Platform-independency (1) and security (2) were the > 2 main goals of the JVM, as stated in its specification (paragraph 1.2) http://java.sun.com/docs/books/vmspec/2nd-edition/html/Introduction.doc.html#3057 The first para of that link also mentions "the small size of its compiled code", which I had later thought of adding here myself. It was also one of the main reasons I chose bytecode for an APL interpreter I wrote in the '80s which had to run on 8-bit 64K machines. Cheers, Paul > I am trying to get my head wrapped around the concepts of Bytecode and Java > Virtual Machines. This is my understanding (right or wrong) so far. [quoted text clipped - 3 lines] > this thing called bytecode. Similar to object code, but not exactly the > same. You could argur that it is object code, for an imaginary machine. The VM specification is more-or-less a specification for a machine that executes bytecode instructions, whether that be a real machine or an emulator. > In order for me to be able to run this program I need to run it through a > piece of software called Java Virtual Machine. JVM takes the bytecode and > runs it. I guess, at no point does true object code get generated, nor does > an executable module. Some VMs do produce native code and execute that, as a means of efficiently emulating the machine specified by the JVM spec. Others (older ones) don't compile and run, they just calculate what the real machine would have done. Real hardware machines in silicon have been made in labs that run bytecode directly, but they have not been sold commercially. I think some of the instructions are difficult to do in silicon - the spec was never intended to be implemented in silicon - it was just a spec for an imaginary processor that could be emulated easily. > Does this sound close to correct? Yes. > If this is correct, what exactly is the > advantage of never creating an executable load module? It seems to me that [quoted text clipped - 3 lines] > advantage of bytecode that can be executed over a load module that can be > executed? As others have said - portability and security. Also speed, I think. Steve Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.