[armedbear-devel] Low memory condition signalling

Alessio Stalla alessiostalla at gmail.com
Fri Apr 9 13:22:31 UTC 2010


On Thu, Apr 8, 2010 at 5:51 PM, Kevin Reid <kpreid at 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 at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
>




More information about the armedbear-devel mailing list