The old verifier tries to verified unreachable code

Eric Bruneton ebruneton at
Mon Aug 20 10:38:54 PDT 2012

 > Hmmm. I don't think control flow analysis is needed here. The data-flow
 > analysis that the JVMS describes would seem to preclude verification of
 > unreachable code. You start by marking the "changed" bit of the first
 > instruction of the method and proceed by finding all successor
 > instructions to that one, marking those and repeating the process until
 > no more instructions are marked as "changed". So in this case (assuming
 > the goto goes to the return) we start by marking the goto, the only
 > successor is the return and it has no successor in this method. Hence
 > the astore would never be verified.
 > That said I'm not 100% sure that JVMS 4.9.2 was meant be to prescriptive
 > rather than just descriptive.

ASM implements this algorithm, and thus sets the max stack size to 0. If 
the JVMS 4.9.2 was just descriptive instead of prescriptive this would 
be a problem, as compilers and other tools manipulating classes could 
not be sure that the classes they generate will be accepted by the 
unknow JVM verifier algorithm.


More information about the hotspot-runtime-dev mailing list