![[Home]](http://www.bayleshanks.com/cartoonbayle.png)
Table of Contents for Programming Languages: a survey
The JVM uses the common system of stack frames, where each stack frame contains local variables. The stack frame also contains an 'operand stack' which is the stack that JVM instructions manipulate. The JVM has instructions which load a local variable onto the operand stack (eg aload for objects, iload for ints, etc), or store a value from the operand stack into a local variable (eg astore, istore).
" The word size must be large enough to hold a value of type byte, short, int, char, float, returnAddress, or reference. Two words must be large enough to hold a value of type long or double. An implementation designer must therefore choose a word size that is at least 32 bits, but otherwise can pick whatever word size will yield the most efficient implementation. The word size is often chosen to be the size of a native pointer on the host platform.
...the local variables and operand stack-- are defined in terms of words....
As they run, Java programs cannot determine the word size of their host virtual machine implementation. " -- [1]
Links:
The JVM guarantees no segfault/null pointer error crashes. This simple idea is an innovative one, particularly in light of its high performance.
The bytecode is syntactically capable of expressing type errors (and i think: including errors that could cause a segfault if executed, eg attempting to dereferencing something which is not a valid pointer), however the JVM actually verifies the bytecode before executing it, ensuring that it typechecks. The low-level expressiveness of the bytecode allows relatively good performance, while the verification allows an entity to call bytecode within the JVM while trusting that the JVM will not crash itself, even if the bytecode has been created by a malicious actor (however, of course if calling into with native code supplied by a malicious actor is permitted, anything could happen).
One might think that this would significantly slow down initialization, but in fact, a 40% speedup of the verifier only translated to a 5% speedup of large program startup time [2]