Assertions in Jikes RVM and MMTk

Partly for historical reasons, we use our own built-in assertion facility rather than the one that appeared in Sun®'s JDK 1.4. All assertion checks have one of the two forms:

if (VM.VerifyAssertions)  VM._assert(condition)
if (VM.VerifyAssertions)  VM._assert(condition,  message)

VM.VerifyAssertions is a public static final field. The config.assertions configuration variable determines VM.VerifyAssertions' value. If config.assertions is set to none, Jikes RVM has no assertion overhead.

If you use the form without a message, then the default message "vm internal error at:" will appear.

If you use the form with a message the message must be a single string literal. Doing string appends in assertions can be a source of horrible performance problems when assertions are enabled (i.e. most development builds). If you want to provide a more detailed error message when the assertion fails, then you must use the following coding pattern:

if (VM.VerifyAssertions && condition) {
  ... build message ...
  VM._assert(VM.NOT_REACHED, message);
}

An assertion failure is always followed by a stack dump.

Use VM.ExtremeAssertions instead of VM.VerifyAssertions if the assertion is costly to check but generally useful. These kinds of assertions are only enabled when config.assertions is set to extreme.

Use IR.SANITY_CHECK or IR.PARANOID to guard assertions that relate to the intermediate representation in the optimizing compiler.

Assertions in the MMTk Test Harness

The assert keyword may be used in the MMTk Harness.

Error Handling

All code in the system needs to detect and handle errors. If you know that your code does not handle certain situations, you should aim to write the code in way that detects these situations. The code also needs to be documented well enough so that users get a hint about the source of the problem. Keep in mind that the Jikes RVM is also used by students who may not be as familiar with the domain as researchers are.

Examples