• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

string question

 
Rauhl Roy
Ranch Hand
Posts: 401
Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
what is the difference between

// 1/
String a="how";
a=a+"are";
a=a+"you";

System.out.println(a);

And

// 2/

String a="how";
String b="are";
String c="you";
String d=a+b+c;
System.out.println(d);

is it same or 1st one performs better then 2nd due to may string declarations? how is it going to impact in big applications?


 
Prabhakar Reddy Bokka
Ranch Hand
Posts: 197
Java Oracle Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In the first case all the strings created before the last statement are became orphan. Since they are not assigned to any variables they are eligible for Garbage Collection.

In the second case all the strings are pointing to some variables so, they are not eligible for Garbage Collection.

Hope you got the reason why first case is optimum.
 
Rauhl Roy
Ranch Hand
Posts: 401
Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Prabhakar Bokka wrote:In the first case all the strings created before the last statement are became orphan. Since they are not assigned to any variables they are eligible for Garbage Collection.

In the second case all the strings are pointing to some variables so, they are not eligible for Garbage Collection.

Hope you got the reason why first case is optimum.


not fully clear. can you tell me one more time.
 
Prabhakar Reddy Bokka
Ranch Hand
Posts: 197
Java Oracle Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In the first case will you be able to access the strings "how" , "are", "you" anywhere in your code after
a=a+"you";
??
So, where they will go? GC?? your memory freed?

In second case you are still be able to access. so they will be in memory.
 
Rob Spoor
Sheriff
Pie
Posts: 20611
63
Chrome Eclipse IDE Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
With Sun's Java 6 compiler, your two examples will be compiled to these:
So the second one is slightly better.
 
Rauhl Roy
Ranch Hand
Posts: 401
Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
may i know why second one is better when your making most of the date to GCable through first example.
 
Janeice DelVecchio
Saloon Keeper
Posts: 1809
12
Eclipse IDE Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Rob -

I like your example.

In the first example, how is the "old a" ever able to be GC?
I was under the impression that string literals hung out in the pool forever..... of course I'm incredibly dense when it comes to GC and strings.....
 
Krep Lock
Ranch Hand
Posts: 43
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Janeice DelVecchio wrote:Rob -

I like your example.

In the first example, how is the "old a" ever able to be GC?
I was under the impression that string literals hung out in the pool forever..... of course I'm incredibly dense when it comes to GC and strings.....


String literals safely remain in the pool as long as one or more reference is pointing at them. So when the reference to "how" is overwritten in a with a reference to "howare" the older String's milliseconds are numbered.
 
Rauhl Roy
Ranch Hand
Posts: 401
Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
String literals safely remain in the pool as long as one or more reference is pointing at them. So when the reference to "how" is overwritten in a with a reference to "howare" the older String's milliseconds are numbered.

kemp may i know the answer to my question?
 
Krep Lock
Ranch Hand
Posts: 43
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Rauhl Roy wrote:

kemp may i know the answer to my question?


Q. Which example is better?

A. Example 1, which uses only String a.

Q. Why o why?

A. Example 1 uses less heap memory. By the time you get to the final line of example 1 you have the following string persisting on the heap:

"howareyou"

By the last line of example 2 there are many more strings persisting on the heap:

"how"
"are"
"you"
"howareyou"

All other things being equal, in a "big application" you are likely to tax system resources much quicker using example 2.
 
Darryl Burke
Bartender
Posts: 5148
11
Java Netbeans IDE Opera
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Rauhl Roy wrote:String literals safely remain in the pool as long as one or more reference is pointing at them. So when the reference to "how" is overwritten in a with a reference to "howare" the older String's milliseconds are numbered.

Nope. From http://www.javaranch.com/journal/200409/ScjpTipLine-StringsLiterally.html
Unlike most objects, String literals always have a reference to them from the String Literal Pool. That means that they always have a reference to them and are, therefore, not eligible for garbage collection.
 
Jesper de Jong
Java Cowboy
Saloon Keeper
Posts: 15448
42
Android IntelliJ IDE Java Scala Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Rob is correct.

If you want to find out exactly what the Java compiler does with your source code, you can use the javap tool which is included in the JDK to disassemble your class file. Have a look at the following program, for example:


You can compile this and then disassemble the class file with the command:

javap -c JavaRanch

You'll get this output:

It's Java virtual machine assembly language, with comments from which you can see what exactly it's doing.
 
Rob Spoor
Sheriff
Pie
Posts: 20611
63
Chrome Eclipse IDE Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Janeice DelVecchio wrote:In the first example, how is the "old a" ever able to be GC?

With "old a" I indeed meant "howare". "how", "are" and "you" still exist in the String pool.

Krep Lock wrote:Q. Which example is better?

A. Example 1, which uses only String a.

Q. Why o why?

A. Example 1 uses less heap memory. By the time you get to the final line of example 1 you have the following string persisting on the heap:

"howareyou"

By the last line of example 2 there are many more strings persisting on the heap:

"how"
"are"
"you"
"howareyou"

The String literals "how", "are" and "you" do not exist on the heap but in the String pool. This is true for both examples. So example one has two Strings ("howare" and "howareyou") on the heap whereas example two only has one ('howareyou"). Not to mention the intermediate StringBuilders - two for example one versus one for example two. In the end, after garbage collection has cleaned up, both only have "howareyou" on the heap. It's the intermediate situation that makes the second example better.
 
Campbell Ritchie
Sheriff
Pie
Posts: 49827
69
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Too difficult for "beginning". Moving thread.
 
Prabhakar Reddy Bokka
Ranch Hand
Posts: 197
Java Oracle Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I had a question again on this!

Is there any size limit to the "String pool"?

If no limit, isn't it occupy the whole heep? (Thinking there are many strings created in many classes in a large application)
 
Ernest Friedman-Hill
author and iconoclast
Marshal
Pie
Posts: 24212
35
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Prabhakar Bokka wrote:
Is there any size limit to the "String pool"?

If no limit, isn't it occupy the whole heep? (Thinking there are many strings created in many classes in a large application)


There's no limit, but it by default holds only Strings that appear as "double quoted literals" in your source code, and it's hard to imagine code that contained so many of those that there was a problem. It holds only one copy of each literal that appears, and in fact, literals will be shared between classes -- so it's actually a means of using less memory, not more.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic