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

The problem is present in a multithreaded system - some actor in your =20=

system (either a single thread, or many of them over time) may =20
allocate so much memory (either just temporarily as part of their =20
normal computation, or permanently because they're leaking) as to =20
nearly, but not quite exhaust the heap. This will cause unpredictable =20=

OOME in other threads as they try and fail to allocate otherwise =20
reasonable amounts of memory. The stability of the JVM is no longer =20
guaranteed (after all, there's a reason OOME is a subclass of =20
VirtualMachineError) as those threads might not even be able to =20
complete any "finally" blocks normally and thus can't exit whatever =20
they were doing gracefully.

You're right though that if you have one thread that attempts to =20
allocate a huge chunk of memory and fails, that is atomic, its effects =20=

are local to that thread, and it won't affect any other thread. If you =20=

know your code will be doing that, then in such a circumstance it can =20=

be reasonable to catch OOME and attempt to recover from it (if the =20
context of the problem at hand allows recovery from it). I was under =20
impression that Randall described such a single-threaded scenario and =20=

said that even in it he failed to recover from an OOME, which honestly =20=

I do find puzzling; as the stack unwinds, stack frames are being =20
discarded along with strong references they hold, so I think that =20
should work...

Attila.

--
home: http://www.szegedi.org
weblog: http://constc.blogspot.com

On 2008.04.14., at 1:06, Endre St=F8lsvik wrote:
> Peter Booth wrote:
>> Here's my two cents:
>>
>> Catching an OutOfMemory error is a waste of time, because by the tim
>> eyou get that error all bets ar eoff an dthere is no guarantee that =20=

>> the
>> VM is functional.
>
> As mentioned, I've also heard this. I'd like to have pointers to =20
> actual
> documentation describing this, because I don't necessarily believe in
> it. See my other post in this thread about why I don't necessarily
> blindly believe that the OOM should come on any random thread. And I
> specifically don't understand why there shouldn't be any guarantee =20
> that
> the VM is functional after an OOM.
>  So pointers to docs or authoritative voices on this would be great.
>
> Endre.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
This list is hosted by DevelopMentor=AE  http://www.develop.com

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