Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Setting Java Virtual Memory

Reply
Thread Tools

Setting Java Virtual Memory

 
 
Sandesh Pai
Guest
Posts: n/a
 
      12-16-2004
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
 
Reply With Quote
 
 
 
 
HK
Guest
Posts: n/a
 
      12-16-2004
Sandesh Pai wrote:
> 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.

 
Reply With Quote
 
 
 
 
Skip
Guest
Posts: n/a
 
      12-16-2004
> 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


 
Reply With Quote
 
monroeds@hampton-data.com
Guest
Posts: n/a
 
      12-16-2004

Sandesh Pai wrote:
> 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.

 
Reply With Quote
 
Chris Smith
Guest
Posts: n/a
 
      12-16-2004
<(E-Mail Removed)> wrote:
> 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
 
Reply With Quote
 
=?ISO-8859-15?Q?Daniel_Sj=F6blom?=
Guest
Posts: n/a
 
      12-16-2004
Chris Smith wrote:
> <(E-Mail Removed)> wrote:
>
>>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.


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();
}
}
--
Daniel Sj÷blom
Remove _NOSPAM to reply by mail
 
Reply With Quote
 
Chris Smith
Guest
Posts: n/a
 
      12-16-2004
Daniel Sj÷blom <(E-Mail Removed)_NOSPAM> wrote:
> 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
 
Reply With Quote
 
=?ISO-8859-15?Q?Daniel_Sj=F6blom?=
Guest
Posts: n/a
 
      12-16-2004
Chris Smith wrote:
> 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"

--
Daniel Sj÷blom
Remove _NOSPAM to reply by mail
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Using virtual memory and/or disk to save reduce memory footprint nick C++ 58 03-16-2009 01:08 PM
"Virtual memory" framework for Java zeus Java 13 08-01-2005 07:47 AM
Java / Virtual Memory Problem with Irix 6.5 Carla Tironi Farinati Java 1 06-29-2005 08:30 PM
Differences between Sony Memory Stick & memory Stick Pro vs Memory Stick Duo? zxcvar Digital Photography 3 11-28-2004 10:48 PM
Virtual Computer Corporation (VCC) Virtual Workbench VW300 Derek Simmons VHDL 0 08-01-2004 04:55 AM



Advertisments