On Sat, Apr 3, 2010 at 5:17 PM, Erik Huelsmann ehuels@gmail.com wrote:
Hi,
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.
Cheers, Alessio