0
String str1=new String("Hello");

Consider there is no instance of any String Object in the String Constant Pool (SCP) and heap. "Hello" doesn't exist anywhere either in Heap or SCP till now. And I'm executing this line of Code. How many objects it will create?

In some Articles they say it's created both in heap and scp and in some articles they say it's in heap only

References: In Only Heap: https://www.javatpoint.com/string-pool-in-java

In both heap and Scp: https://www.edureka.co/blog/java-string/#:~:text=By%20new%20keyword%20%3A%20Java%20String,the%20object%20in%20the%20heap

Joachim Sauer
  • 302,674
  • 57
  • 556
  • 614
Sriram prasanth
  • 3
  • 2
  • The second link goes to stackoverflow.com, I'm sure that's not what you intend. – Jiminy Cricket. Nov 10 '22 at 09:16
  • Minor note: since about Java 7 the string pool *does live on the heap* so both strings in the string pool and non-interns strings will be created on the heap. – Joachim Sauer Nov 10 '22 at 09:29
  • 1
    The constant pool is not a storage. It’s just a table of references. So “being in the constant pool” just means “being referenced by the constant pool”. This should feel familiar, as every collection in Java works that way. E.g. storing an object in an `ArrayList` doesn’t change the fact that the object’s memory is part of the heap memory. – Holger Nov 10 '22 at 09:29
  • 1
    @JoachimSauer the strings of the pool *always* lived in the heap memory, even if JMX reported the PermGen to be non-heap memory. As that’s [a matter of definition](https://docs.oracle.com/javase/specs/jvms/se17/html/jvms-2.html#jvms-2.5.3): “*The heap is the run-time data area from which memory for all class instances and arrays is allocated.*” Even in the PermGen, the strings were visible to all threads and they were subject to garbage collection, which are the characteristics of heap memory. – Holger Nov 10 '22 at 09:39
  • @Holger: fair, but in another very practically relevant way the constant pool lived in an unresizable, un-garbage-collectable part of the heap, which caused many problems. And "being resizable" and "being garbage-collectable" are properties that (correctly or incorrectly) are strongly associated with "the heap" in Java. – Joachim Sauer Nov 10 '22 at 09:41
  • 2
    @JoachimSauer this is not correct. The PermGen was not “un-garbage-collectable”. Strings in the pool [were always garbage collectable](http://blog.kdgregory.com/2009/09/intern-isnt-forever-and-maybe-never-was.html), if not referenced by still reachable code. The fixed size was indeed a problem, but the specification never said that heap memory has to be expandable. In fact, there’s a maximum size for the heap in most implementations, so “being expandable” is only relevant because they can be smaller than that maximum. – Holger Nov 10 '22 at 10:07
  • @Holger: interesting, maybe I did fall prey to some cargo cult. Now I'm vaguely curious to get to the root of this persistent "knowledge". But on the other hand I'm lazy enough not to invest time into something that has roughly 0 practical impact since almost all of the constraints from back then (whatever they actually were) have been removed since. – Joachim Sauer Nov 10 '22 at 10:22

0 Answers0