1

Almost all bytecodes know the type of their operands to be found on the stack at runtime, the bytecode verifier will have checked that only these types will actually be found at runtime (for every path) so the interpreter can just go ahead poping values that it expects and all should be well.

There are however a few instructions that need to know the type of the operands e.g. some of the 'dup' bytecodes which have different forms if some of the operands are category 2 (longs & doubles). During verification this is easy as previous push instructions use pseudo verification types where a long is pushed as a type 'long' and a type 'top' so verifying the dup knows that there is a long (as it also finds a 'top').

But how does the runtime determine this?

Hi all, original question says "some of the 'dup' bytecodes", should have been more specific i.e. the more complex ones 'dup_x2', 'dup_2', 'dup2_x1', and 'dup2_x2' whwere the different forms are dependant on what is found on the stack, they will do different things if they encounter longs, or doubles.

My question is how can the runtime determine if a value is 1 entry int or a 2 valued long/double and respond accordingly. thanks

John Priest
  • 13
  • 4
  • Maybe the type gets pushed to the stack too? I'm just guessing here. – ShellFish Jan 10 '15 at 18:49
  • What do you mean by "how does the runtime determine this"? It can't - that's why there are separate instructions for operations with ints and longs. – yole Jan 10 '15 at 18:50
  • `DUP` is not used with `long` or `double` types (`DUP2` is). – August Jan 10 '15 at 18:51
  • Runtime doesn't need to know. – Hot Licks Jan 10 '15 at 19:28
  • Hi Hot Licks, for the more complex dup... instructions the runtime does need to know, please see amendment above – John Priest Jan 10 '15 at 20:29
  • 1
    Oh dear I'm being a bit stupid, the descriptions only appear to make the instructions do different things when they find category 2 entries, just looking at how the stack slots are moved they always do the same and all the cat 2 (2 slot) entries are always preserved intact – John Priest Jan 11 '15 at 12:32

1 Answers1

1

The dup instructions don't care about type. They just blindly duplicate x number of stack slots and place them appropriately. dup2 will duplicate 2 ints (or a float and a reference or whatever) just as well as a single long.

The one caveat is that the verifier still has to verify that single words out of a long/double are not split. But this isn't unique to the dup instructions.

Every stack or local slot at every point in the bytecode has an implicit type defined by the verifier's dataflow analysis. (In later bytecode versions, there are also type annotations (not to be confused with Java level Annotations) in the classfile to make the verifier more efficient).

Antimony
  • 37,781
  • 10
  • 100
  • 107
  • Yeah, the 1-word/2-word stack scheme is one of the half-dozen or so major screw-ups in the JVM architecture, but the verifier assures it will work, and the runtime doesn't need to know the details. – Hot Licks Jan 10 '15 at 19:31
  • 1
    (The "type annotations" make the verifier theoretically faster, but a lot screwier, so "more efficient" is a matter of opinion.) – Hot Licks Jan 10 '15 at 19:32
  • Thanks the descriptions only make it appear that different things happen, as you say the instructions just blindly shuffle slots and the verifier will have already checked that longs/doubles will not be split – John Priest Jan 11 '15 at 12:35
  • The feature of later bytecode versions is [`StackMapTable`](http://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.7.4). Calling it “type annotations” is a bit unlucky as it confuses readers with the [Java 8 feature called “Type Annotations”](http://docs.oracle.com/javase/tutorial/java/annotations/type_annotations.html) – Holger Jan 12 '15 at 15:00