What are the opcodes that put vars on the local frame array? Remove them?

Question

Does anyone know of a reference that lists all the opcodes that put a local variable in the local frame array (like ASTORE, BIPUSH, etc) and all the ones that remove them (like POP, ALOAD, etc)?

Answer 1

BIPUSH doesn't affect the frame, it pushes a value onto the operand stack. The distinction may be subtle, but it's
important since the JVM is a stack-based architecture (in other words, if you don't make the distinction, than your
list contains [almost] all of the JVM opcodes).You're right. So then, what exactly are POP, DUP, etc doing? Are they taking from the frame?First thing to remember is that the frame and operand stack are logically different: the frame contains method parameters and local variables, while the operand stack is used for intermediate results. They may be implemented using a single processor stack (in X86 terms, the BP register would point to the start of the frame, while pushes and pops would modify the SP), but don't have to be. I think the JVM spec even talks about storing frames in the heap.
Here's an example:
public static int foo(int a, int b)
    int c = a + b;
    int d = (c + c) * 5;
    return d;
}Running javap -c to show the bytecodes, we get this:
public static int foo(int, int);
  Code:
   0:   iload_0
   1:   iload_1
   2:   iadd
   3:   istore_2
   4:   iload_2
   5:   iload_2
   6:   iadd
   7:   iconst_5
   8:   imul
   9:   istore_3
   10:  iload_3
   11:  ireturnThe two method parameters, a and b, are stored in the frame in slot 0 and 1 (if this were an instance method, slot 0 would contain "this"). They get pushed onto the stack using the iload opcode (the normal version of this opcode takes a second byte index into the frame; to minimize code size, the JVM has alternate versions of most frame-access opcodes that are hardcoded for a specific low-numbered slots).
After the loads, the stack will contain the values held in b and a; the iadd instruction adds these together, leaving the result on the stack. The istore_2 removes the topmost value from the operand stack, and stores it in the frame (in the slot assigned to variable "c").
To your question about dup and so forth, I was hoping to demonstrate that with the repeated reference to variable "c"; instead, the compiler translated that into the two iload operations (opcodes 4 and 5). I suppose it makes sense, but it shows just how little optimization the compiler attempts to do -- instead, it relies on Hotspot being smart enough to optimize hardware accesses.
The iconst_5 opcode is another example of something that affects the operand stack but not the frame: it pushes a hardcoded constant value onto the stack.
It's also another case where the JVM defines several opcodes that do the same thing: the iconst_n for values -1 to 5, bipush for values that are outside this range but still smaller than a byte, sipush for values that will fit into a short, and ldc for everything else. The goal is efficient code generation: 1-3 bytes for most of the integer values that you're likely to load. The ldc opcode is interesting in its own right: it does a lookup into a per-class table to find the value to push. Not very efficient in terms of CPU cycles and memory access (although it can be inlined by Hotspot), but again efficient from a bytecode perspective: if you're loading a large constant, there's at least a chance that you'll be loading it multiple times.
Chapter 6 of the VM spec lists all the opcodes, and I seem to remember groupings by purpose: http://
java.sun.com/docs/books/jvms/second_edition/html/Instructions.doc.htmlUnfortunately, it doesn't quite do that. They're mostly all in the same place on the summary page but not quite all. (For example, the array ones were in a separate place) And the link you posted lists them only alphabetically.Yeah, but jverd posted the link to section 3.11, which groups the opcodes. You probably want 3.11.2: http://java.sun.com/docs/books/jvms/second_edition/html/Overview.doc.html#6348
Which leads to the more interesting question: why?