[VM] Bytecode Subroutine Verification

[Pavel Rebriy <pa...@gmail.com>]

There are several virtual machines in Harmony project and none of them
provides subroutine verification for Java bytecode. I would like to discuss
appropriate methodology of subroutine verification.

In Java bytecode, subroutines represent code in "finally" construction. The
use of such subroutines makes bytecode analysis very difficult. Fortunately,
modern compilers eliminate usage of subroutines through inlining.

Subroutine verification approach described in the Java Virtual Machine
Specification 2nd Edition has a fundamental limit and rejects a legal Java
code. The limit is inherent to approach of tracking modified variables and
selectively propagating from ret to jsr instructions.

A possible approach is to inline subroutines for bytecode verification.
After inlining, the simpler data flow analysis can be run. In certain cases
it's not clear how to define subroutine boundaries for inlining so in
general, some analysis is needed to define subroutines' boundaries.

The question is whether it is better to inline subroutines and then run a
simpler data flow analysis, or to run directly a more complex data flow
analysis.
-- 
Best regards,
Pavel Rebriy

Re: [VM] Bytecode Subroutine Verification

[Tom Tromey <tr...@redhat.com>]

>>>>> "Pavel" == Pavel Rebriy <pa...@gmail.com> writes:

Pavel> There are several virtual machines in Harmony project and none
Pavel> of them provides subroutine verification for Java bytecode. I
Pavel> would like to discuss appropriate methodology of subroutine
Pavel> verification.

Pavel> The question is whether it is better to inline subroutines and
Pavel> then run a simpler data flow analysis, or to run directly a
Pavel> more complex data flow analysis.

It isn't clear to me that you can successfully determine the
boundaries of subroutines in a useful way.  I considered this for a
while in my implementation but gave up.  I didn't keep any of my
example code around though.

I recommend ignoring a good chunk of what the JVM Spec has to say
about verification.  It is simply wrong.

Instead, read the various papers by Alessandro Coglio on this topic.
In libgcj I basically implemented what he suggests.  This seems to
work well in practice... that is, it has caught compiler bugs and
other problems for us, and we haven't had major problems with the
verifier rejecting valid code.  (We did have these problems when we
tried to follow the JVM Spec.)

While you can construct bad cases that make Coglio-style verifiers
very slow, I'd be surprised if the verifier generally shows up high in
profiles.  (Our profiles tend to omit the verifier for other reasons,
but other per-class things like linking appear quite low.)

Tom

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org