On Thu, Apr 8, 2010 at 5:51 PM, Kevin Reid kpreid@switchb.org wrote:
On Apr 8, 2010, at 11:25, Alessio Stalla wrote:
- 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.
Actions to be taken in low memory can also be (might particularly be) unrelated to what's currently on the stack (dynamic scope), such as clearing caches. On the other hand, condition handlers are always dynamically scoped. It might be good to have a way to register global handlers for the low memory warning.
On the other hand, what thread is a global handler called in, when? For that matter, when might a condition be signaled -- what if it's the result of an allocation in the middle of a subsystem in an inconsistent state? OOM always has this problem, but in the low memory case it's more feasible to recover well (since you have some room to calculate your cleanup), so you need to think more about not accidentally breaking invariants.
The issues associated with threading are indeed subtle; I hadn't considered them. OOM being an exception means that it will be handled in the thread(s) that raised it. With JMX, instead, you either poll the memory MXBean from a dedicated thread, or register a listener that will be automatically invoked when the threshold is exceeded; see [1]. The thread that gets to call the listener seems to be a dedicated one ([1] says not to do lengthy operations in the listener to avoid blocking further notifications). So, in either case, a global handler is more appropriate.
Regards, Alessio
[1] http://download.java.net/jdk7/docs/technotes/guides/management/mxbeans.html (search for "Detecting Low Memory")
-- Kevin Reid http://switchb.org/kpreid/
armedbear-devel mailing list armedbear-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel