From: David Chase <chase@theworld.com>
Newsgroups: comp.lang.java.machine,comp.compilers
Subject: Re: Problems with Java Bytecode Verification
Date: 26 Jan 2003 16:31:42 -0500
Message-ID: <03-01-160@comp.compilers>
Keywords: Java

Alan Cabrera wrote:

>I read an article Stark and Schmid about problems with the bytecode
>verification algorithm outlined in the JVM spec.  I find this
>fascinating.  Are there any surveys on this field?

The other replies that I saw on c.l.j.machine are not likely to help
you that much.  There are (at least) four categories of problems:

1) problems in the specification

e.g., problems with merging of class types whose implemented
interfaces combine in "interesting ways".  The VM description from Sun
is simply wrong in certain cases, and it is possible to create
bytecodes where the base case of the type-correctness proof is not
true, and most verifiers (Sun's included) don't catch it.

2) actual practice does not follow the specification

e.g., illegal identifier names in the bytecodes

3) the specification allows something surprising enough that only
    a pedant would figure it out.

e.g., exception ranges don't need to be nested.

4) the specification allows more or less strict verification, up to
you to figure out which.

e.g., a verifier may or may not require that locks balance in
the flow graph.  What's actual practice?

I don't think that you will find this definitively described anywhere,
since it constitutes a barrier to entry for anyone writing a competing
JVM -- only someone writing a VM and running it on lots of inputs
would learn this, and what does it profit them to share the
information?  Failing that, you can study the output from bytecode
obfuscators; they tend to push the envelope in terms of weird-looking
stuff that still manages to run.

This is one of the downsides of Sun not standardizing Java; I am
pretty sure that most of these warts would have been described,
because the plan was to standardize "what exists now".

David Chase