Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: sketch some guidelines about error handling


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.


  • The code does not work at all in a certain situation, e.g. it gives incorrect results when the optimizing compiler is enabled or a certain optimization is turned on. In this case, the best approach is to detect the situation and fail fast. This can be done using assertions. You can use VM.sysFail(..) for builds without assertions if correct execution after failure is impossible.
  • A compiler optimizations fails. The correct approach is to throw an OptimizingCompilerException (e.g. via one of the static methods provided by that class). This will lead to a hard failure when -X:vm:errorsFatal=true is set (which is the case in regression tests). In other cases, the VM will just revert to using the baseline compiler.
  • A command line option has a limited range of values. In MMTk, the correct approach is to implement the validate() method for the option. In other places, the value of the option needs to be checked at a suitable time.