• Post Reply Bookmark Topic Watch Topic
  • New Topic

Why only Strings are handled in a different kind of memory pool?  RSS feed

 
pawan chopra
Ranch Hand
Posts: 419
jQuery Mac Objective C
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all,

I have this question, may be this was answered so many times by you guys. but I hope to get a satisfactory answer again.

(1) Why only Strings are handled in a different kind of memory pool?
(2) why they are made immutable, and How Java has implemented immutability in Strings?
(3) How can we make an object immutable?

Thanks,
Pawan Chopra.
 
Jesper de Jong
Java Cowboy
Sheriff
Posts: 16060
88
Android IntelliJ IDE Java Scala Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
(1) Strings are not handled in a different kind of memory pool. The contents of String objects is stored on the heap, just like any other kind of object in Java. What you probably are referring to is the string pool, which is an optimization technique to reduce the amount of memory that Java programs use. The string pool is not a special kind of memory pool that's different from the heap or the stack.

(2) Read this article to understand what "immutable" means. String objects are immutable because of the way the String class is constructed. If String objects were not immutable, then an optimization technique like string pooling would not be possible.

(3) Read the article that I mentioned above. To make your own class immutable, don't provide any methods that change the state of an instance of your class after it has been created (so, don't provide any setter methods or other methods that change the internal state of the object).
 
pawan chopra
Ranch Hand
Posts: 419
jQuery Mac Objective C
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
For first question I am asking that why a different string pool for Strings only? why not for Double or any other object?
 
David O'Meara
Rancher
Posts: 13459
Android Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Integers can get pooled too, and Booleans should always attempt to use Boolean.TRUE and Boolean.FALSE, although that is not quite the same.
 
pawan chopra
Ranch Hand
Posts: 419
jQuery Mac Objective C
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think I am not able to explain my question. I know that we can also pool Integers and Doubles. But why Java has handled pooling for Strings only not for Integers or Doubles when they can be pooled?


Sorry If It is irritating you guys
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by pawan chopra:
I think I am not able to explain my question. I know that we can also pool Integers and Doubles. But why Java has handled pooling for Strings only not for Integers or Doubles when they can be pooled?


Because the difference in memory usage is much bigger for Strings.
 
David O'Meara
Rancher
Posts: 13459
Android Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
But Java does have special treatment for Integer.valueOf(...)
 
David O'Meara
Rancher
Posts: 13459
Android Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Mutable and Immutable Objects

Discussing the immutable tricks from Strings is not so simple as it employs tricks we can only dream of. Feel free to browse the source code.
 
Bill Shirley
Ranch Hand
Posts: 457
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There can be a lot of memory chewed up by string usage, and there is a lot of value to be saved by pooling that memory. Especially given typical programmatic manipulation that occurs on strings.

Int/Double are of fixed size, and a lookup for all ints would be much less productive. You usually want to optimize processing speed when working with numbers, moreso than memory usage.

You easily could decided to use a similar scheme, but the Masters of Java� have weighed the pluses and minuses and not gone that direction.
 
Ernest Friedman-Hill
author and iconoclast
Sheriff
Posts: 24217
38
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Another thing that hasn't been mentioned here is that String object literals have been built into the Java language since day one: i.e., you write

System.out.println("Hello, World");

and this refers to a String object whose value is "Hello, World". If your code uses "Hello, World" a couple of times, it would be silly to create a separate String for each occurrence: thus the pool. You see how this fell naturally out of the language itself. Strings are special because there traditionally were no other kind of "invisible objects" like this, that appeared seemingly out of nowhere.

But since Java 5, we've had autoboxing, and so Integer, Double, etc objects can all be created invisibly. And so, in fact, there are pools for these too (as someone did point out above.) These new pools are accessed via the "valueOf()" methods in each wrapper class. Integer.valueOf(3) will return a pooled Integer object with value 3. Therefore the String pool is no longer unique.

As to immutability requiring "tricks we can only dream of", I'm not quite sure what that means. It's easy to make an immutable class: just don't provide any way to change the innards of the object!
 
Mike Simmons
Ranch Hand
Posts: 3090
14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
[Jesper]: (1) Strings are not handled in a different kind of memory pool. The contents of String objects is stored on the heap, just like any other kind of object in Java. What you probably are referring to is the string pool, which is an optimization technique to reduce the amount of memory that Java programs use. The string pool is not a special kind of memory pool that's different from the heap or the stack.

That's what the documentation for String.intern() indicates, but it's not really true, at least for modern JVMs. Strings in the intern pool are in the heap, true, but it's a special part of the heap - the permanent generation. This is an area for objects that are assumed to stay around in memory for a long time - though contrary to the name, objects here aren't necessarily permanent, just very long-lived.

Additionally, the string intern pool consists of two components: the strings themselves, and a hash table that contains references to the strings. This hash table is part of the JVM infrastructure, implemented in native code, not a Java HashMap or other Java object. Not in the heap at all, really.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!