Bytecode Verification

I was able to track down and fix PR 5537 with a simple patch, but fixing it exposed other problems in the front end bytecode verifier that cause failures in the libjava testsuite and in the Mauve verifier testsuite.

So now I need to go after these bugs before I can submit a patch.
~sigh~
(Why do such things always happen to me?)

I found an interesting presentation (PDF) by Gilad Bracha (a "Computational Theologist" in Sun) on bytecode verification. I found it interesting because he says that Sun went with load-time bytecode verification to reduce run-time verification overheads and had to introduce strict definite (un)assignment as a mandatory feature of the language to be able to carry out proper type inference during verification! The other interesting bit was that they went with type inference (instead of type checking) to reduce the space used by class files at the cost of increased complexity, memory usage and speed - they later found out that type checking would have meant faster and simpler code at the cost of only a little extra space (5-10%)!

"Premature optimisation is the root of all evil!"

By the way, JDK 1.5 will have class data sharing to reduce startup times. So should libgcj use prelinking?


(Originally posted on Advogato.)

Tweet