Changes between Version 3 and Version 4 of OOMHandling


Ignore:
Timestamp:
04/10/11 20:02:18 (4 years ago)
Author:
pduboue
Comment:

some hints on dealing with stack overflows.

Legend:

Unmodified
Added
Removed
Modified
  • OOMHandling

    v3 v4  
    88 * 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, [http://java.sun.com/javase/6/docs/api/java/lang/OutOfMemoryError.html OutOfMemoryError] and [http://java.sun.com/javase/6/docs/api/java/lang/StackOverflowError.html StackOverflowError] are remapped to STORAGE-CONDITION.
    99   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).
     10
     11Please 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.
     12
     13Tip: if you are running out of stack with a 64-bit JVM, try using a 32-bit JVM instead.