Changes between Version 3 and Version 4 of OOMHandling

Timestamp:

04/10/11 20:02:18 (13 years ago)

Author:

pduboue

Comment:

some hints on dealing with stack overflows.

OOMHandling

@@ -8 +8 @@
  * 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.
    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.