Setting Java Virtual Memory

[Sandesh Pai]

Hi,
Often I get 'out of memory exception'. So I want to increase the memory.
Please any one tell me how to set the java virtual memory settings.
Thanx
Sandesh Pai

 

[HK]

Hi,
Often I get 'out of memory exception'. So I want to increase the memory.
Please any one tell me how to set the java virtual memory settings.

See the -Xmx option of the JVM. Either run 'java -X' or see the manual
page. Example to allocate 900m
java -Xmx900m your.class.Here

Harald.

 

[Skip]

Hi,

Often I get 'out of memory exception'. So I want to increase the memory.
Please any one tell me how to set the java virtual memory settings.
Thanx
Sandesh Pai

java -msXXm -mxXXm <normal arguments>

ms is initial heap-size
mx is maximum heap-size

 

[monroeds]

Hi,
Often I get 'out of memory exception'. So I want to increase the memory.
Please any one tell me how to set the java virtual memory settings.
Thanx
Sandesh Pai

You are probably instantiating too many objects. Review your code.

A common cause of this is using the '+=' construct to concatenate
strings. Every time this is used, a StringBuffer is instantiated.

 

[Chris Smith]

You are probably instantiating too many objects. Review your code.

A common cause of this is using the '+=' construct to concatenate
strings. Every time this is used, a StringBuffer is instantiated.

Nope, the implicit StringBuffer instances used to implement the +=
operator on Strings will never cause an OutOfMemoryError. A full
garbage collection is guaranteed to occur prior to OutOfMemoryError
being thrown, so only the memory that's really required will contribute
toward this problem. The implicit object from += will be garbage
collected before the error is thrown.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[=?ISO-8859-15?Q?Daniel_Sj=F6blom?=]

Nope, the implicit StringBuffer instances used to implement the +=
operator on Strings will never cause an OutOfMemoryError. A full
garbage collection is guaranteed to occur prior to OutOfMemoryError
being thrown, so only the memory that's really required will contribute
toward this problem. The implicit object from += will be garbage
collected before the error is thrown.

This is not strictly true, but it may be that I'm misinterpreting what
you are saying. It is very much possible for the JVM to throw an
OutOfMemoryError when concatenating large Strings. Here is an example
illustrating such behaviour, it will print "Smart is ok", but will crash
with an out of memory error before printing out "Naive is ok", when run
on the Sun JVM without any additional flags (you may possibly have to
play around with the number of iterations to get it to work as
intended). Warning: running this may take a moderately long time.

public class StringConcatenation
{
public static void main(String[] args)
{
final int ITERATIONS = 80;

smarterConcat("", ITERATIONS);
System.out.println("Smart is ok");
naiveConcat("", ITERATIONS);
System.out.println("Naive is ok");
}

public static String naiveConcat(String str, int iterations)
{
String str2 = new String(new char[100000]);

for (int i = 0; i < iterations; i++)
str += str2;

return str;
}

public static String smarterConcat(String str, int iterations)
{
StringBuffer sb = new StringBuffer(str);
String str2 = new String(new char[100000]);

for (int i = 0; i < iterations; i++)
sb.append(str2);

return sb.toString();
}
}

 

[Chris Smith]

This is not strictly true, but it may be that I'm misinterpreting what
you are saying.

You're giving an example of concatenating strings that are too large for
the buffers to fit into memory. The post I was replying to talked about
too many of these StringBuffer objects being created, not their being
too large to fit in memory. The two are quite different. It's
impossible to accumulate too many StringBuffer objects from string
concatenation operators and so cause an OutOfMemoryException.

Your scenario, on the other hand, could possibly avoid an
OutOfMemoryError but not in a very interesting way. Notice that you
basically just got lucky in your "smarterConcat" method. If that last
concatenation had required that the StringBuffer increase its buffer
size, it would have also ran out of memory. In real life, you might
decrease the probability of your code failing, but you'll never make it
correct.

If you know the final size of the result in advance, though, then you
could have really done some good with your smarterConcat and an explicit
StringBuffer. That code would look like this:

public static String reallySmarterConcat(String str, int iterations)
{
String str2 = new String(new char[100000]);
int resultLen = str.length() + str2.length * iterations;

StringBuffer sb = new StringBuffer(resultLen);
sb.append(str);

for (int i = 0; i < iterations; i++) sb.append(str2);

return sb.toString();
}

Also note that use of a StringBuffer in this situation (concatenation is
a loop of non-trivial size) is always good practice, but that's
primarily because it avoids the work of consistently copying the
character data, *not* because of any probable decrease in the high water
mark for memory usage of the algorithm.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[=?ISO-8859-15?Q?Daniel_Sj=F6blom?=]

Your scenario, on the other hand, could possibly avoid an
OutOfMemoryError but not in a very interesting way. Notice that you
basically just got lucky in your "smarterConcat" method. If that last
concatenation had required that the StringBuffer increase its buffer
size, it would have also ran out of memory.

No, that is not necessarily the case. It would have in the original
example, because I constructed it slightly wrong, but the example below
produces the same result (the naive version runs out of memory), but the
smarter version can actually double its buffer size without running out
of memory. I leave it to the reader to figure out why this happens.

public class StringConcatenation
{
public static void main(String[] args)
{
final int ITERATIONS = 32;

smarterConcat("", ITERATIONS + 20);
smarterConcat("", ITERATIONS);
System.out.println("Smart is ok");
naiveConcat("", ITERATIONS);
System.out.println("Naive is ok");
}

public static String naiveConcat(String str, int iterations)
{
String str2 = new String(new char[250000]);

for (int i = 0; i < iterations; i++)
str += str2;

return str;
}

public static String smarterConcat(String str, int iterations)
{
StringBuffer sb = new StringBuffer(str);
String str2 = new String(new char[250000]);

for (int i = 0; i < iterations; i++)
sb.append(str2);

System.out.println("StringBuffer capacity after " + iterations + "
iterations: " + sb.capacity());
return sb.toString();
}
}

Also note that use of a StringBuffer in this situation (concatenation is
a loop of non-trivial size) is always good practice, but that's
primarily because it avoids the work of consistently copying the
character data, *not* because of any probable decrease in the high water
mark for memory usage of the algorithm.

The point of the example was obviously not to demonstrate good
programming practices, which is why I called the method "smarterConcat",
not "smartConcat"