Java String: String Constant Pool(SCP)

After reading all the String documentation and exact code of String class, I find the main engine that makes String in Java (study of deep knowledge) i.e., String constant pool. when we say String s0 = "example1" , String s1 = "example1" and String s2 = "example2" what happens is exactly: at compile time the .class file is genrated when JVM runs the class constant pool of String class get's into work s0 hashcode is generated by intrinsic method and the formula used is standard horner(31) using that hash it need to find the allocated bucket After finding exact hash it need to compare each char by char to check whether it's equal or collison a different char can also have same hashcode. if it's equal the pointer directly to points to that object -->process ends next process works. If not equal there is two work done 1. new object is created on heap memory and then wrapped up by a WeakHandle and pushed in "stringTable" bucket. (if equal no object is created)! there was never an object creation the pointer just points to object . Now the example case: s0 -> hashcode(x1)->not found in "stringTable"->Object creation on Heap-> weakHandle process them into stringTable. s1 -> hashcode(x1)->found->(collision|equal)->equal->pointer points to "example1" from SCP to s1. s2-> hashcode(x2)->not found in "stringTable"->Object creation on Heap-> weakHandle process them into stringTable. After reading and analysing there is also a issue of massive garbage I see: suppose if 4 thread are runnable and they are trying to intern() the object in SCP that creates garbage according to your data size suppose , we used latin-1 type 256B data so total thread is 4 but in CAS only one thread execute rest all thread dumps the object so out of 1KB storage 768B is garbage. if the String was in UTF-16 it would cost 2*768B. {the MM is not actual Java object Layout} https://bugs.java.com/bugdatabase/JDK-6962931 (Shifting from PermGen) HotSpot uses lazy resolution for string literals when a class is loa