Re: Out-of-Memory Handling in Long-Running / Server Applications

On Sunday 13 April 2008 23:43, Attila Szegedi wrote:
> ...
>
> You're right though that if you have one thread that attempts to
> allocate a huge chunk of memory and fails, that is atomic, its
> effects are local to that thread, and it won't affect any other
> thread. If you know your code will be doing that, then in such a
> circumstance it can be reasonable to catch OOME and attempt to
> recover from it (if the context of the problem at hand allows
> recovery from it). I was under impression that Randall described such
> a single-threaded scenario and said that even in it he failed to
> recover from an OOME, which honestly I do find puzzling; as the stack
> unwinds, stack frames are being discarded along with strong
> references they hold, so I think that should work...

But in my situation, memory demand comes as a large number of small
allocations many of which have long lifetimes. When I catch the OOM
error, sometimes I can carry on after freeing my population of
instances, requesting a GC and indicating a failure through the
program's ordinary status reporting mechanism. But in some cases, I get
another OOM soon after, and that one is fatal, of course.

As far as it being single-threaded, when running as a CLI command, it is
(JVM threads notwithstanding), and in that setting it's no big deal if
OOM handling is disorderly. The user can simply re-run the program with
different limits (memory or operation count). But when it runs in a
servlet container, there are potentially other threads executing
competing user request as well as whatever other threads the servlet
container uses to do its things.


> Attila.


Randall Schulz

===================================
This list is hosted by DevelopMentor®  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com