3 ms·
64-bit longs and doubles take up two slots in the JVM's local variable table, whereas Object references only take one. So, if anything, the design of Java bytec
by komadori 3y ago
64-bit longs and doubles take up two slots in the JVM's local variable table, whereas Object references only take one. So, if anything, the design of Java bytecode assumed 32-bit pointers.
- kaba0 3y agoThey can just use 64-bit slots for everything (it does leave unused 32bit for each 32bit local variable, but there are not many, and you get the benefit of the same logic no matter what you store there, plus it has the same performance on 64-bit systems) Edit: mind explaining the downvote ?
- ternaryoperator 3y agoNot sure why you're being downvoted. The Jacobin JVM [0] does exactly what you suggest: 64-bit operand stack and local variables. Longs and doubles still occupy two slots on the operand stack, so as to avoid having to recompile Java classes that assume the two-slot allocation, but the design avoids having to smash together two 32-bit values every time a long or double is operated on. [0] http://jacobin.org/ http://jacobin.org/
- skitter 3y agoRelatedly the JVM specification section 4.4.5 says (as the same holds for the cp and stack): In retrospect, making 8-byte constants take two constant pool entries was a poor choice.