Odd Handling of Wide by GetBytecodes -- Any Thoughts?

Question

Hello Everyone,
I have been playing with examining the set of bytecodes executed by different Java applications using the JVMTI. However, I have come across an oddity with respect to how wide is handled. I wrote a simple hello world type program (prints "Hello World", then assigns 5 to a local variable, then prints out the local variable) that makes use of wide by declaring 300 local variables, the first 299 of which are not used. The bytecode for my program, as generated by javap -c is:
public static void main(java.lang.String[]);
Code:
0: getstatic #2; //Field java/lang/System.out:Ljava/io/PrintStream;
3: ldc #3; //String Hello World!
5: invokevirtual #4; //Method java/io/PrintStream.println:(Ljava/lang/String;)V
8: iconst_5
9: istore_w 300
13: getstatic #2; //Field java/lang/System.out:Ljava/io/PrintStream;
16: iload_w 300
20: invokevirtual #5; //Method java/io/PrintStream.println:(I)V
23: return
However, when I use GetBytecodes to get the array of unsigned chars inside my agent, the array of bytes contains the following values. I am getting these values back in a handler for JVMTI_EVENT_CLASS_PREPARE.
Method name: main
0: b2
1: 00
2: 02
3: 12
4: 03
5: b6
6: 00
7: 04
8: 08
9: 36 <-- why is this 0x36 and not WIDE (0xc4)
10: 36
11: 01
12: 2c
13: b2
14: 00
15: 02
16: 15 <-- why is this 0x15 and not WIDE (0xc4)
17: 15
18: 01
19: 2c
20: b6
21: 00
22: 05
23: b1
When I install a handler for JVMTI_EVENT_SINGLE_STEP I am also able to check each bytecode executed. I never see a WIDE execute here either. I would really like to be able to differentiate between the execution of a wide usage of <t>load and <t>store and their standard narrow forms.
Any thoughts are greatly appreciated.

Answer 1

Which release/build are you using? I believe there was a bug in the GetBytecodes function in 5.0 - that bug existed in JVMDI in 1.4.x too but wasn't observed or reported. The problems with the bytecode reconstitution were fixed in Java SE 6 ((you can grab the latest binary from http://download.java.net/jdk6/binaries). I also think the fix was back-ported to 5.0 update 4.