Re: FAQ, 4.1 OutOfMemoryException

[Archie Cobbs]

Sascha Brawer wrote:
> I was just re-reading the FAQ [1] -- what would speak against 
> pre-allocating thread-specific OutOfMemoryException objects when 
> creating a thread? (Probably more a VM-specific thing, but since it's 
> mentioned in the Classpath FAQ...)

FWIW, here's the approach JC takes. I'd be interested to compare with
the strategies of other VMs.

#1. For all exceptions that can be instantiated by the VM itself, there
     is a single stacktrace-less "backup" instance. This instance is thrown
     in a thread when we try to instantiate a normal instance but the same
     exception is triggered recursively. This idea is borrowed from SableVM
     and prevents any infinite loops when instantiating exceptions within
     the VM (recursive exceptions within normal Java code are OK).

#2. When a heap allocation fails, we perform up to 3 GC cycles to try to
     make memory available:

      - The first GC cycle is normal, only weak references are cleared
      - The second GC cycle enables clearing soft references too
      - Before the third GC cycle, we run the finalizer

     If all 3 attempts fail, we then set the per-thread "out of memory"
     flag (see #3) and then instantiate and throw an OutOfMemoryError.

#3. A small percentage of the heap is reserved. The reserved portion
     of the heap is only available to threads with the "out of memory"
     flag set. When a GC cycle occurs, all "out of memory" flags for
     all threads are cleared. But if a thread has already started
     its 3 GC attempts (see #2) then it won't notice this flag being
     cleared until the current allocation attempt completes.

The net result is that OutOfMemoryErrors are thrown very reliably,
with stack traces, because they get to draw from the reserved area.
Also, because of the multiple GC attempts, typically only one thread
will throw an OutOfMemoryError. When it does, it frees up memory that
other threads can then use, so they don't throw one also.

Also, the "out of memory" flag is not cleared in a thread until the
next GC cycle. If you clear it too soon (e.g., immediately after you
create the OutOfMemoryError instance), then often the thread will throw
another one. The extra time gives it a chance to "clean up" after itself
before restricting it back to the non-reserved portion of the heap.

-Archie

__________________________________________________________________________
Archie Cobbs      *        CTO, Awarix        *      http://www.awarix.com


*
Confidentiality Notice: This e-mail message, including any attachments, is for 
the sole use of the intended recipient(s) and may contain confidential and 
privileged information. Any unauthorized review, use, disclosure or 
distribution is prohibited. If you are not the intended
recipient, please contact the sender by reply e-mail and destroy all copies of 
the original message.
*