Java bytecode verification: when, how, or maybe to turn it off?
Today's Java developers are increasingly relying on libraries that generate Java bytecode at runtime to effectively implement various tricks that are hard or impossible to do in Java. However, while the javac compiler is guaranteed to produce correct Java bytecode, shifting down to the bytecode level requires that you keep track of its correctness yourself. Otherwise, there is a chance to get a j.l.VerifyError at runtime upon the loading of a generated class, because the JVM passes all classes through the Java bytecode verifier to enforce strict correctness requirements. Therefore, knowing just the semantics of Java bytecode instructions is often not enough to properly synthesize classes — you also need to know how the Java bytecode verifier works, what bytecode it deems correct, and what it does not.
In this talk, Nikita will tell what mission the Java bytecode verifier carries out in the JVM, when and how it works, whether it may affect the performance of your application, and why turning it off is so dangerous.
Nikita is the initiator and product lead of Excelsior JET project — certified Java SE implementation with AOT compiler developed by Excelsior LLC. Working on the project since 1997 he took part in almost every activity of the project from the JVM core to product management and support. In particular, he is the author of OSGi support at the JVM level in Excelsior JET, Java Runtime Slim-Down technology (Java SE modularization implemented in Excelsior JET since 2007), both Java bytecode verifiers and many others.