Summary

Provide additional contextual information about bytecode-verification errors toease diagnosis of bytecode or stackmap deficiencies in the field.

Goals

Bytecodes are verified by the JVM's bytecode verifier. Bytecodes emittedby the JDK'sjavac compiler generally result in highly conformant bytecode.However, there are other tools and packages that modify bytecode forvarious reasons, including instrumentation and debugging. Occasionally,post-processing bytecode results in aVerifyError. Currently, the messageassociated with the error is rather terse and non-specific. The purposeof this feature is to expand the information available when aVerifyErroroccurs in modern classfiles so that a developer can more quickly resolve theproblem.

Non-Goals

While additional data about errors can be provided, it is not the goal toprovide "all possible" data about an error, especially in cases whereadditional data can be obtained by other means. For instance, whilethe actual bytecode where the problem occurs may be included in an errormessage, it may not be disassembled into human-readable form. Additionallythe state of the system such as loaded classes and their relationships arenot provided as this information is available using other mechanisms.

This extra data will only be available and displayed for errors that aregenerated by the type-checking verifier. Classfiles with a version lessthan 50 are verified using the inferencing verifier. Errors generated bythe inferencing verifier will not change.

The format of the error message and it's data are not official nor fullyspecified, and are subject to change in any release.

Success Metrics

This project is considered successful if the additional data provided isused by any single engineer to diagnose a real verification error situation.Given the unpredictability of the problem, and the continuing resistance ofengineers to allow implanted tracking chips in their brains, there reallyis no useful metric that can be applied in this case. We have to rely uponcommon sense and experience in determining what is likely to be useful, whichis historically a notoriously hard thing to quantify.

Motivation

Verification errors are hard to decipher. The current messages attached toVerifyError messages are cryptic and provide very little help in pinpointingwhere and why the bytecode or stackmap is flawed.

Description

There are two parts to this project. The first is the exposure of a previouslyinternal flag which traces the verification project, and the second anaugmentation of the messages contained in a VerifyError with additionalcontextual information.

The flag which turns on verification tracing was previously an internalglobal flag which required a change to the source and a recompile of the JVM(in debug mode) to enable. This project turns that flag into the diagnosticflag, 'VerboseVerification'. As such, verification tracing can be turned on(even in product mode) using the command-line flags:"-XX:+UnlockDiagnosticVMOptions -XX:+VerboseVerification"

When run with this flag enabled, the JVM will output tracing information tostdout. This tracing information details which methods are being verified,what mechanism is used for verification, the method's stackmap table. and indebug mode, each instruction's bci, opcode, and current frame state.

In addition, the traditional error message included in thrown VerifyErrorinstance is augmented with the following detailed information: the exactlocation where the error was detected (class and method name plusbytecode offset); a more detailed error notification which details the originsof any referenced types (if applicable); the current analysis frame state(if applicable); a hex dump of the bytecode; a textual representation of theexception handler table; a textual representation of the stack map table.

The additional error details are formatted into sections and present in amulti-line format in the exception message. The original error message isalso unchanged and present at the beginning of the exception message.

Alternatives

One alternative is to not augment with detailed error messages unless acommand-line flag is present. This is still a possibility, but sinceVerifyErrors are rare it is assumed that having extra details by defaultwill not cause any problems.

Testing

Existing test suites for the bytecode verifier can be used to validatethis feature. Some tests however, might need to be enhanced to expectadditional diagnostic information provided by this feature.

Comprehensive testing requires crafting a number of tests (each being aspecialized classfile) which triggers a VerifyError in each possible placein the code, as well as creating a variety of tests that exercise thedifferent origins for types (stack/locals/constant pool).

Risks and Assumptions

Very low risk. We do assume that no one is dependent on the existingcontents of the VerifyError exception message and thus it is safe forus to augment it without compatibility problems. If this assumption iswrong we may want to investigate the listed alternative.

Dependences

No dependencies

Impact

We expect no impact upon other parts of the platform.