How to avoid out of memory exception programatically during runtime execution

[Raj Datla]

Hi All,

Is there way to avoid out of memory exception programatically?, other than using JVM options "-XX:PermSize" and "-XX:MaxPermSize". I am trying to find solution during runtime of JVM.

Regards
Raj

[Tim Cooke]

Java has a SoftReference that you can use to keep a weak handle on some expensive object that you have. The JVM knows that it can dereference any object referenced by a SoftReference if it needs to. For example:

MagicBean hugeExpensiveThing = ...; // create some huge memory hog
SoftReference expensiveThingReference = new SoftReference(hugeExpensiveThing);

And to access your MagicBean

MagicBean myExpensiveThing = (MagicBean) expensiveThingReference.get();

Normally you may well create lots of MagicBean's and consume a load of memory each time until there's none left and the JVM bails, but by using this technique we are telling the JVM that it can take back the memory used by anything referenced through a SoftReference if it needs the memory back. This is a really neat trick to help you keep your application running rather than just falling over unexpectedly. To use this method effectively though you must be prepared for the expensiveThingReference.get() method to return null which will happen if the JVM's claimed back the memory.

You'll find further discussion of this technique in Michael T Nygard's book "Release It!"

[Jelle Klap]

Hi, and welcome to JavaRach!
There isn't a way to programatically prevent and OutOfMemoryError at runtime that is reliable. Some methods of the java.lang.Runtime class offer ways to retrieve memory related information at any given instant, but you can't realiably make use of those to prevent an OutOfMemoryError. The best defense is to profile your application to find out how much memory it needs and to find out if there are any memory leaks. Tweaking the heap and garbage collection settings is usually also worth the effort if you have a feel for your application's memory usage.

[Rajesh Datla]

Thank you, All.

Regards
Raj

[Winston Gutkowski]

Raj Datla wrote:Is there way to avoid out of memory exception programatically?, other than using JVM options "-XX:PermSize" and "-XX:MaxPermSize".

As Jelle said: No. And tweaking those parameters is treating the symptom, not the cause. It may buy you a bit of time, but it will almost never solve the problem. Indeed, OOME is itself a symptom - usually of badly-written code.

As Tim suggested, there are some things you can do to help; although I'd suggest that SoftReference's are a last resort, as they can get a bit tricky.

Another, indirect, way of tackling memory issues is to make objects immutable (Google it), because truly immutable objects can share internals. For example, If I write:

String last999999 = millionCharacterString.substring(1);

I am not creating a copy of millionCharacterString.

Indeed, if you look at the memory usage before and after that statement, you'll probably find that it only differs by 20-30 bytes.

It does require thought though, so don't just go making everything immutable because you "heard it here".

Winston

[Jelle Klap]

Eek. That is actually not a terrific example, as the substring() method used to copy the entire original char array, which would actually result higher than necessary memory usage. I think that wasn't changed until a minor JDK 7 release, but I may be off the mark a bit there.

[Winston Gutkowski]

Jelle Klap wrote:Eek. That is actually not a terrific example, as the substring() method used to copy the entire original char array, which would actually result higher than necessary memory usage. I think that wasn't changed until a minor JDK 7 release, but I may be off the mark a bit there.

Well it's in the v6 openjava source - specifically, the 'offset' field, which is what makes all that nice stuff possible.

But I think the general point is important: you can save a lot of memory if you design immutable classes properly.
If BigInteger, for example, had a "copy" constructor (and I wish it did):

public BigInteger(BigInteger other) {

there would be no need to actually copy the entire contents of other.

Winston

[Jeff Verdegan]

Winston Gutkowski wrote:

Raj Datla wrote:Is there way to avoid out of memory exception programatically?, other than using JVM options "-XX:PermSize" and "-XX:MaxPermSize".

As Jelle said: No. And tweaking those parameters is treating the symptom, not the cause. It may buy you a bit of time, but it will almost never solve the problem. Indeed, OOME is itself a symptom - usually of badly-written code.

I'd soften that a bit to say that it can be a symptom of poor design or poor coding. There are definitely lots of cases where we legitimately need a lot of memory--or at least more than the default value.