OOM detection  
Author Message
Frank Cornelis





PostPosted: 2003-8-30 23:50:00 Top

java-programmer, OOM detection Hi,

I'm looking for a way to detect that the JVM is reaching an out of
memory situation. But, I don't want to do this by means of catching
an OutOfMemoryError, because by that time the ship is already
sinking. I came up with a solution that uses the Reference Objects
API, but I don't know if it will do the job correctly.
Below is a demo. Please give me some feedback on this.
I also tried it out using a SoftReference, but then it gives an
OutOfMemoryError eventually. Is this behavior JVM dependent?


CC me,
Frank.


/*
* Run with: java -verbose:gc Test
*/
import java.lang.ref.*;
import java.util.*;


public class Test extends Thread {

private ReferenceQueue queue = new ReferenceQueue();
private Reference pr;

private static Stack stack;


public void run() {
while(true) {
Object o = new Object(); // dummy object
pr = new WeakReference(o, queue);
o = null;
try {
queue.remove(); // when our dummy object gets finalised we continue here...
}
catch(InterruptedException e) { }
System.out.println("OOM");
stack.clear(); // prevent OutOfMemoryError here...
}
}


public static void main(String [] args) {
stack = new Stack();
new Test().start();
while (true) {
stack.push(new Object());
}
}

}
 
Mark Thornton





PostPosted: 2003-8-31 0:07:00 Top

java-programmer >> OOM detection Frank Cornelis wrote:

> Hi,
>
> I'm looking for a way to detect that the JVM is reaching an out of
> memory situation. But, I don't want to do this by means of catching
> an OutOfMemoryError, because by that time the ship is already
> sinking. I came up with a solution that uses the Reference Objects
> API, but I don't know if it will do the job correctly.
> Below is a demo. Please give me some feedback on this.
> I also tried it out using a SoftReference, but then it gives an
> OutOfMemoryError eventually. Is this behavior JVM dependent?
>
>
> CC me,
> Frank.
>

This approach won't work. The nexact strategy used with SoftReference is
VM dependent. All that is guaranteed is that it will clear them before
throwing an OOM exception (at least it is supposed, some JVM have bugs
in this respect). However using a SoftReference as a 'flag' to indicate
that memory is short and then taking action while precessing the queue
will not work --- you queue processing will be too late to alleviate the
memory shortage.

Instead you should hold any large amounts of data which can be
regenerated by SoftReference's so that the JVM can free this data
directly when memory runs short.

Mark Thornton

 
Skippy





PostPosted: 2003-8-31 19:06:00 Top

java-programmer >> OOM detection > I'm looking for a way to detect that the JVM is reaching an out of
> memory situation.


Runtime rt = Runtime.getRuntime();
long max = rt.maxMemory();
long used = rt.totalMemory() - rt.freeMemory();
long free = max-used;

A deamon-thread could monitor the 'free-memory' and watch for dangerous
levels.


 
 
Mark Thornton





PostPosted: 2003-8-31 19:19:00 Top

java-programmer >> OOM detection Skippy wrote:
>>I'm looking for a way to detect that the JVM is reaching an out of
>>memory situation.
>
>
>
> Runtime rt = Runtime.getRuntime();
> long max = rt.maxMemory();
> long used = rt.totalMemory() - rt.freeMemory();
> long free = max-used;
>
> A deamon-thread could monitor the 'free-memory' and watch for dangerous
> levels.
>
>

Watch out for this bug:
http://developer.java.sun.com/developer/bugParade/bugs/4686462.html

Also this approach may fail if memory is allocated too quickly.

Mark Thornton

 
 
Mark Thornton





PostPosted: 2003-8-31 19:25:00 Top

java-programmer >> OOM detection Skippy wrote:

>>I'm looking for a way to detect that the JVM is reaching an out of
>>memory situation.
>
>
>
> Runtime rt = Runtime.getRuntime();
> long max = rt.maxMemory();
> long used = rt.totalMemory() - rt.freeMemory();
> long free = max-used;
>
> A deamon-thread could monitor the 'free-memory' and watch for dangerous
> levels.
>
>

And there is this plea from the GC developers:

http://developer.java.sun.com/developer/bugParade/bugs/4744780.html

Mark Thornton