Ufdjrw

I have some code which is like:

String country = null;
country = getEuropeanCountry(); //Germany
//after few lines of code
country = getAsianCountry(); //Japan
//after few more lines
country = getNorthAmericanCountry(); //Canada
/*and the code follows by assigning a different country value to the same variable "country"*/

I have this kind of usage in most of my code.

For some reason, my application throws "Error java.lang.OutOfMemoryError: GC overhead limit exceeded".
So I tried with VM argument: -XX:-UseGCOverheadLimit
Then my app ran successfully but I noticed that it is consuming more memory (I had to set -Xmx to 5g or 6g; otherwise I get: out of memory error).

I checked my app and there are no memory leaks. But most of my code has the similar code that I posted above.

Can anyone tell me if it is beneficial for memory management if I refactor the above code to:

String europeanCountry = getEuropeanCountry(); //Germany
//after few lines of code
String asianCountry = getAsianCountry(); //Japan
//after few more lines
String northAmericanCountry = getNorthAmericanCountry(); //Canada
/*and the code follows by assigning a different country value to a different String variable*/

I can't use collections. I mean, in general, which way is better to use heap space and garbage collector efficiently?

For the question " I mean, in general, which way is better to use heap space and garbage collector efficiently?"

Lets look at the String implementation e.g. jdk8 https://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/share/classes/java/lang/String.java

public final class String

 implements java.io.Serializable, Comparable<String>, CharSequence {

 /** The value is used for character storage. */

 private final char value[];

So it is a final character array - it cannot be reasigned or changed. So it is generated on the heap in your method and is never changed - only a reference(a name) is generated.

To make no mistake lets also look at the constructor of a String (doing smth. like eg. "newString = new String(otherString)":

public String(String original) 

 this.value = original.value;

 this.hash = original.hash;

Also in that case no additional space on the heap is allocated - it stays the same single final char array on the heap.

So you can assign a new String to a reference.(Give it an additional name). But it is allways the same unique String generated in your method and no new space on the heap is allocated.

So comparing the two methods in a first narrowing:

String europeanCountry = getEuropeanCountry();
String asianCountry = getAsianCountry();

and

String country = null;
country = getEuropeanCountry();
country = getAsianCountry();

Both will formaly create the same amount of Strings on the heap as the String is allways generated in the same methods. The variable are only references to that.

The only difference is that reusing in the second case allows formaly the String to be earlier garbage collected(In the moment the reference to it is removed by reusing the variable).

So with the second approach(reusing) you may generate a smaller memory footprint for a neclectable time.

I said in a first narrowing as this is only true if there is no other reference to the String and without optimization - so if no other reference exists and no optimization would take place the above would be the case.

However in your above code the variables don't exit scope and are never used. The compiler will detect this and no variable will be assigned at all. Depending on what the methods do they may be inlined and also not called. So what the methods you call look like makes a difference. Depending how complex they are the space on the heap is allocated or not.

Also the other way round: if you use the variable and runtime detects that you will likely call the method again for the same value, the value will be kept on the heap and not freed even if there is formal no reference and it could formally be garbage collected - so the assigment again makes no difference but the call of the method.

Also the obvioue: if the methods don't only generate the Strings but pull them from somewhere(a container) or store them somewhere that other reference is the one for which space on the heap is kept (and is) allocated and your assignment makes no difference at all regarding heap: it is the same final char array on the heap.

With that in mind the problem you are facing is most probably not that assignment of Strings but the design of your code. It must be a by far more complex scenario in which references are kept longer.

So far for your question.

For your problem i would look out:

• for containers


• where variables are generated


• for frequent use . That is calling the methods very frequently for a lot of different values as in such case they are kept in memory for the next assumed call to happen.


• for code where it is not easy to follow the flow of the data. The compiler optimizes by analyzing the flow. If you can't follow, it is more likely that the compiler can't neither than in other parts.

Assuming lines of code shown are from single method(let me know if that's not the case), there are at least 3 issues I can point outwith the code:

1. it seems method size is too large. Prefer writing methods that are as concise as possible and do just "one thing" and do it well.




2. too much state change. In the 1st example where you set variable 'country' to 3 different method return values.




3. consider using polymorphism, rather than repeating code in an if-else fashion for fetching the country

finally, it's not clear how country values are used in methods.