The old verifier tries to verified unreachable code
Eric Bruneton
ebruneton at free.fr
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.
Eric
More information about the hotspot-runtime-dev
mailing list