- The JVM is open to host different languages among them JRuby, Groovy and Jython all these translate to JVM bytecode for runtime. Java is translated in exactly the same process to bytecode using javac.
- Bytecode is the assembly language of the JVM, you might as well think of the JVM as a globally available instruction set.
- The translation of bytecode to human readable form is encouraged by Sun. Fact is Sun provides a tool called javap that allows you to do just that in an easily accessible way.
- Bytecode works by calling instructions with their relevant data, for example a reference to a memory location that contains a string. What's interesting about this idea is that methods are also called by string reference- so for example if your default code is designed to call a method by the instruction invokevirtual #4 you could very replace that with invokevirtual #7 at runtime, this opens a huge range of possibilities for the application.
- Inside the JVM the stack is divided into slots, each slot size is 4bytes (32bits).
- The size of a bytecode instruction is 1 byte. Which makes this the simplest assembly language in the world. In fact the grand total of bytecode instructions existing is 224!
- The method by which the JVM passes data between instructions is by putting and popping data into the stack. The calling context, before instructing the JVM to execute a bytecode instruction loads data into the stack, the instruction in turn once called pops data out of the stack. The amount of loaded data by the caller must match the amount that would be popped otherwise we have a Buffer Overflow, something that does not exist in the JVM (As far as I know).
I've just covered the first section of the article, you are encouraged to read the whole thing. Please by all means don't retain yourself from commenting with ideas and requests regarding additional covering you would like to read. Also, I should mention that people wishing to participate in the writing of this blog are welcome to do.
Please contact me at maxim.veksler@gmail.com for further discussion.
No comments:
Post a Comment