Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Newer
Older
100644 101 lines (67 sloc) 3.8 kb
8f0cd17 @krestenkrab initial import
authored
1
2
3 Kresten's Verifier for Java Byte Codes
4 ======================================
5
6
7 The interface to the verifier is currently very crude.
8 To run it, type
9
10 prompt> java verify.Tool class-or-file-name ...
11
12 If you give it a name of a class file, it will try to figure out
13 the corresponding class name, (removing leading "./", and
14 terminating ".class", and replace '.' with the path seperator).
15
16 To start off, you may want to verify the verifier. On unix, you can
17 write something like this,
18
19 prompt> java verify.Tool `find verify/ -name '*.class'`
20
21
22 As it runs, it will print a '.' for each method checked, and a '#'
23 whenever it loads extra auxillary classes needed.
24
25
26 It has two interesting options.
27
28 --classpath=PATH
29
30 Where path is a : or ; separated path (according to the java
31 property "path.separator"). This specifies the "class path" from
32 which to load classes. The classpath defaults to whatever the Java
33 Runtime decides to make available in the java.class.path property.
34
35 The verifier does not use the Java system's class loader. Rather,
36 it incorporates it's own loading mechanism which is more
37 ligh-weight. Also you don't really need to "load" classes in order
38 to verify them.
39
40
41 The second interesting option is
42
43 --verbose=true
44
45 which will make the verifier print a line of information for each
46 instruction checked. (or perhaps this is just to be considered my
47 debugging output...) It might look like this:
48
49 --[151]----------
50 (##) <[#JXJX#I#I????????> pc=151 new
51 (##@) <[#JXJX#I#I????????> pc=154 dup
52 (##@@) <[#JXJX#I#I????????> pc=155 iconst_1
53 (##@@I) <[#JXJX#I#I????????> pc=156 invokespecial
54 calling java/lang/Boolean.<init> (boolean) void
55
56 For a given sequence of four instructions. The --[151]---- marks
57 an entrypoint for a basic block. The part on the left, in
58 parentheses describes the state of the stack at this particular
59 instruction. Each character represents one "stack item". The
60 right-most element is the top of the stack. Generally, these are
61 the same as the characters encoding types in a field descriptor,
62 "I" is integer, "J" is long, "D" is double and so on. Special are
63 however "X", representing the second half of a long, and "Q", the
64 same thing for doubles. "#" is a normal object, "@" is an
65 uninitialized object (one for which a constructor has not yet been
66 called) and "[" is an array. (See types/TypeTags.java for the full
67 list)
68
69 On the right, in angle brackets, is the "state" of the local
70 variables. These are represented using the same characters as
71 before. Location, which have yet to be assigned a value, are
72 marked with "?". One of the jobs of the verifier is to make sure
73 that such a location is never being read.
74
75 Finally, on the right, you see the current pc (program counter) and
76 the symbolic name of the opcode being checked.
77
78 When the bytecode verifier detects an error, and you did not choose
79 the --verbose=true option already, it will turn it on for you, and
80 re-check the very same method.
81
82 Right now, the interface is rather crude. If you get no specific
83 messages, that means that your code did verify.
84
85
86
87 As a consequence of the way it works, it may discover unreachable
88 code in the instruction sequence. I have not seen javac-generated
89 code with unreachable instructions, but several other compilers
90 produce them all over. In specific, IBM's Jikes compiler does.
91 When the verifier discovers such a sequence, it will print a
92 message like
93
94 unreachable in fooBar(): 3417+4, 7732+2
95
96 Where the +X means how many bytes onward in the byte sequence to
97 find the unreachable code.
98
99
100
Something went wrong with that request. Please try again.