Anonymous
Unregistered
|
|
But does Java specification says anything about the string pool like whether it is maintained at the JVM level or class level?
|
vlad_roubtsov
member
Reged: 06/21/03
Posts: 169
|
|
Quote:
But does Java specification says anything about the string pool like whether it is maintained at the JVM level or class level?
I am not sure I understand you question 100% correctly.
If you are asking whether interned Strings are scoped to a JVM-global or class-scoped pool then the answer is obviously that the pool cannot be scoped to individual classes, because several loaded classes interning the same String value will end up (as required by the VM spec) sharing the same interned String instance.
If you are asking whether the intern pool must be implemented natively or in bytecode, then I don't believe the VM spec goes to this level of detail. It is possible to verify that recent JVMs don't even use the Java heap memory for interned Strings. That is, all interned Strings go into an internal native data area.
|
Erb
Unregistered
|
|
I think he might be referring to the part about how String literals are maintained in the defining class. I understand that the .class file has a string literal table in it, but does the specification say that string literals in different classes will be different?
|
vlad_roubtsov
member
Reged: 06/21/03
Posts: 169
|
|
Quote:
I think he might be referring to the part about how String literals are maintained in the defining class. I understand that the .class file has a string literal table in it, but does the specification say that string literals in different classes will be different?
No it doesn't say that precisely. String literals in different classes that are loaded at the same point in time can never be different instances. This is a language spec requirement. String literals in different classes whose life scopes are disjoint may be represented by different string instances -- this is precisely what is shown by the second code snippet in the article.
Furthermore, just to cover all bases I will mention here (and perhaps this should have been mentioned in the article) that the constant_pool segment in a .class definition (as detailed in the section 4.4. of the JVM spec) has nothing to do with the interned string pool that might be used natively by the JVM to implement String.intern().
The former is the standard format for how classes are compiled and how class bytecode is loaded by the JVM. Once the bytecode is loaded, the .class definition is discarded and is instead represented internally in some native data structures that are likely very different from .class layout.
In fact, the constant_pool is allowed to contain duplicate CONST_String and CONST_Utf8 entries for the same string content. (It normally does not happen because compilers and common bytecode manipulation kits usually merge such duplicates into a single entry per unique value {primarily because .class layout was designed with compactness in mind}, but it is not forbidden by the spec). A simple experiment will show that a class with duplicate CONST_String entries in its constant_pool will be loaded without any problems and it will not affect String.intern() in any way.
So, the two things (constant_pool in every .class and String.intern() value pool) are completely independent entities. The first one is just a data layout that enables Java's dynamic class linking, the second one is what really implements String.intern() behavior at runtime.
|
piglet
Unregistered
|
|
I hope you are still there...
I would like to know whether there is any advantage (concerning memory, performance) in defining globally constant string literals, e.g. EMPTY_STRING="", as opposed to repeating the literal each time I need it. Java will use the interned reference anyway, so I could as well go without the constant?
|
Unregistered
|
|
I have done similar tests. The interned strings go to "old" generation memory pool in jdk 1.5.
|
Previous
Index
Next
Threaded
Edit
Reply
Quote
