• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

What happens to the bytecode

 
Ranch Hand
Posts: 152
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello all,
I have a small question. After the .java source file is compiled to a .class file this .class file contains the bytecode. Now this bytecode is verified by the Javaverifier for correctness of the bytecode(correctness of bytecode means checking for viruses in the bytecode, isn't it?) and then the java interpreter changes the bytecode to native code and the jvm executes. Is it that the native code will be sent to the OS by the JVM to interact with the hardware or will the jvm directly interact with the native code.
 
lowercase baba
Posts: 13089
67
Chrome Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
my understanding is that every machine can only understand it's native code. what the JVM does is translate the bytecode to native. that's why there is a different JVM on every kind of platform (apple, Sun, Linux, etc).
Sun took care of all that stuff for us, making development (theoreticaly) easier.
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The JVM has a couple choices. In "interpreter" mode, it looks at a bytecode that maybe says "add 1 to x". It looks up x in a symbol table, finds out where x is in memory, gets the current value, adds one, puts it back. Ok, it's much smarter than that, but you get the idea. The JVM doesn't convert the bytecode to native code, but it is written in native code itself so it's doing all those steps in native code.
In "hot spot" mode the JVM actually compiles the bytecode into native code and stores that native code some place. Next time it comes across that statement it executes the native code. Extra cost to compile once, benefit of native code maybe millions of times. Or maybe once.
I think some JVMs still profile the code as they run. A JVM migh reason: I've interpreted this code a few thousand times recently, maybe I should compile it. I think that's where the "spot" part of hot spot came from.
 
Chandra Bairi
Ranch Hand
Posts: 152
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
My question exactly is what converts the platform independent bytecode to native code and who executes that native code. is it passed to OS by the JVM to execute or the JVM directly executes the bytecode without any intervention of the Operating System.
 
author and iconoclast
Posts: 24207
46
Mac OS X Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Operating systems generally don't have any sort of "here's some native code, please execute it for me" function; neither operating systems nor computers work that way. The native code that is generated essentially becomes a function in the JVM's address space, and the JVM simply invokes it.
 
Stan James
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Compiled code ready for execution is nothing but a bunch of bytes in memory, whether a JVM does it as it runs or a C++ or COBOL compiler does it ahead of time. Once it's in memory, the JVM can "branch" into that code and the CPU executes it. So there is no OS call, just a normal GOTO into its own memory space. The code eventually returns and the JVM figures out what to do next.
It occurs to me this is similar to buffer-overrun attacks by hackers. They find ways to write bytes into memory that will later be executed, altering the program on the fly to do evil things.
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic