Java Magazine, September/October 2017
ORACLE COM JAVAMAGAZINE SEPTEMBER OCTOBER 2017 46 java 9 variable Next instructions 12 to 16 set up the stack with the HashMap object and the arguments for the call to put The actual invocation of the put method is performed by instructions 17 to 19 The invoke opcode used this time is invokevirtual This differs from a static call because a static call does not have an instance on which the method is called such an instance is sometimes called the receiver object In bytecode an instance call must be set up by placing the receiver and any call arguments on the evaluation stack and then issuing the invoke instruction In this case the return value from put is not used so instruction 20 discards it The sequence of bytes from 21 to 25 seems rather odd at first glance 21 aload_ 3 22 astore 4 24 aload 4 26 ldc 8 String foo 28 ldc 9 String baz 30 invokeinterface 10 3 InterfaceMethod java util Map put Ljava lang Object Ljava lang Object Ljava lang Object 35 pop The HashMap instance that was created at bytecode 4 and saved to a local variable 3 at instruction 11 is now loaded back onto the stack and then a copy of the reference is saved to local variable 4 This process removes it from the stack so it must be reloaded from variable 4 before use This shuffling occurs because in the original Java code an additional local variable of type Map rather than HashMap is created even though it always refers to the same object as the original variable This is another example of the bytecode staying as close as possible to the original source code One of the main reasons for this so called dumb bytecode approach that Java takes is to provide a simple input format for the JVMs JIT compiler After the stack and variable shufling the values to be placed in the Map are loaded at instructions 26 to 29 Now that the stack has been prepared with the receiver and the arguments the call to put is dispatched at instruction 30 This time the opcode is
You must have JavaScript enabled to view digital editions.
