[armedbear-devel] Low memory condition signalling
alessiostalla at gmail.com
Thu Apr 8 15:25:28 UTC 2010
On Sat, Apr 3, 2010 at 5:17 PM, Erik Huelsmann <ehuels at gmail.com> wrote:
> Yesterday I completed an abcl-dev blogpost about 0.18 which handles
> out of memory (OOM) conditions much better than earlier versions.
> However, as the post concludes, it would be even lispier to have a
> low-memory signal instead of OOM, because in that case the condition
> system can be used to handle the situation right in the call stack
> where the condition occurred, in order to be able to continue
> execution after handling the condition.
> Douglas Miles suggested we use JMX memory management notifications to
> create this behaviour. Before we can implement such behaviour, a
> number of questions need to be answered:
Just my .02 €:
> * How does an application tell the difference between our current OOM
> condition and the new behaviour?
> -> this is important, because the current behaviour unwinds the
> stack; the future one won't
- the new behaviour should not be an ERROR but a WARNING, in my
opinion. You can react to it or ignore it. After all, low-memory is
not the same as no-more-memory.
> * Do we remove the current behaviour?
- no! Having the new behaviour does not make OOM impossible to occur,
and we still need to react to that in a meaningful manner.
> * Do we let the user select the parameters for signalling the
> requested condition?
- If possible, I'd give the user the possibility to select those parameters.
> * Should we let the user install handlers to be called when a
> condition like this occurs?
- yes, why not? It's a condition like any other.
> * <others>?
- JMX is fully available out of the box from Java 1.6. In 1.5 you have
to launch the VM with some properties set to enable it. Since
low-memory signaling is a kind of help to the programmer, but it's not
mandatory, we could simply warn if JMX is not enabled and never signal
any low-memory condition in that case.
More information about the armedbear-devel