Re: Problems with Java Bytecode Verification

David Chase <>
26 Jan 2003 16:31:42 -0500

          From comp.compilers

Related articles
Problems with Java Bytecode Verification (Alan Cabrera) (2003-01-25)
Re: Problems with Java Bytecode Verification (David Chase) (2003-01-26)
Re: Problems with Java Bytecode Verification (Peter Finderup Lund) (2003-02-05)
Re: Problems with Java Bytecode Verification (Alan Cabrera) (2003-02-06)
| List of all articles for this month |

From: David Chase <>
Date: 26 Jan 2003 16:31:42 -0500
Organization: Little or none
References: 03-01-145
Keywords: Java
Posted-Date: 26 Jan 2003 16:31:42 EST

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

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.