Handling serious errors (such as Exhaustion of heap memory and Stack overflow)

One of the advantages of running on the JVM is that some kinds of critical errors don't crash the application, but are rather signaled as Java exceptions.

ABCL can handle Java exceptions in two ways, depending on when they are thrown:

• if they are thrown by Java code invoked through the Java FFI, they are automatically remapped to a condition of type JAVA-EXCEPTION or to another custom type defined by the user (refer to Java FFI for details).
• if they are thrown during the execution of Lisp code - which can be the case for serious errors like exhaustion of heap memory or call stack overflow - the Lisp stack unwinds while the exception propagates up; the unwinding stops at the first handler-bind (this includes forms that use handler-bind in their implementation, such as handler-case and ignore-errors). The exception is then remapped to a Lisp condition, allowing user code to handle it. In particular, ​OutOfMemoryError and ​StackOverflowError are remapped to STORAGE-CONDITION. Of course the standard Common Lisp condition handling still applies fully in this exceptional case (e.g. with respect to the dynamic environment in which handlers are run). The unwinding of the stack allows the garbage collector to reclaim some memory, so it's possible to recover from the error (for example, by emptying caches used by the application).

Please note that ABCL uses the Java stack for the Lisp function calls and the usual JVM arguments for controlling the stack size are useful in dealing with stack overflow problems. Also, ABCL does not handle (yet) tail recursion elimination and as such it might require more stack than other CL compilers.

Tip: if you are running out of stack with a 64-bit JVM, try using a 32-bit JVM instead.