how actually string store in java machine

R

Rishipal Singh

i have read so many articles about how string store in java .
but i have still problem
most of the sites says that the string is stored in run time constant pool memory .
but how
please help me explain in detail ...
 
R

Roedy Green

i have read so many articles about how string store in java .
but i have still problem
most of the sites says that the string is stored in run time constant pool memory .
but how
please help me explain in detail ...

In theory this is secret however, Internally a String is a char[]. The
reference is just a 4 byte (or 8 byte) pointer to the String object.
There are no methods to modify the contents of the string after
instantiation, or to modify the length. The char[] is allocated like
an other char array, an a block of contiguous RAM somewhere in the
free space pool.

Actually, the pointer may be indirect to make it easier to move the
string around in RAM for garbage collection.
--
Roedy Green Canadian Mind Products http://mindprod.com
"A great lathe operator commands several times the wage of an average lathe
operator, but a great writer of software code is worth 10,000 times the
price of an average software writer."
~ Bill Gates
 
R

Roedy Green

i have read so many articles about how string store in java .
but i have still problem
most of the sites says that the string is stored in run time constant pool memory .
but how
please help me explain in detail ...


have a look at the implementation of String in src.zip.
--
Roedy Green Canadian Mind Products http://mindprod.com
"A great lathe operator commands several times the wage of an average lathe
operator, but a great writer of software code is worth 10,000 times the
price of an average software writer."
~ Bill Gates
 
J

Jeff Higgins

i have read so many articles about how string store in java .
but i have still problem
most of the sites says that the string is stored in run time constant pool memory .
but how
please help me explain in detail ...
Please provide links to the article(s) that you are having trouble
understanding, along with pointers to the parts you do not understand.
 
M

markspace



Quoted from your link:


"Summary

"Despite serious optimizations done in the String.intern()
implementation in Java 7+, it still takes a noticeable time to run
(noticeable for CPU sensitive applications). The simple example in this
article runs 3.5 times faster without calls to String.intern(). You
should not use String.intern() as a safety net, passing every long
living string into it. Instead process only fields with a limited number
of possible distinct values (for example, states/provinces if processing
addresses) - memory savings in this situation will definitely pay off
the initial CPU costs of String.intern()."

* * *


Basically the "you should not use String.intern() ... passing every ...
string into it." Is the money shot. If you have a string that's
obviously repetitious (like a field for states or countries) it might be
useful, other wise not so much.

Also, using String.intern() heavily requires that you increase memory
available to it.


"The requirement to set -XX:StringTableSize=N JVM parameter in advance
and dealing with its fixed value"


That alone would make me want to use a HashSet instead.
 
J

Jeff Higgins

Basically the "you should not use String.intern() ... passing every ...
string into it." Is the money shot.
I don't think there is anything new here.
But an interesting evolution to watch.
 
R

Roedy Green


I was under the impression all string constants lived in the same pool
along with the interned strings. That would imply a shared constant
pool since day 1. Have I had this wrong since Java 1.0?
--
Roedy Green Canadian Mind Products http://mindprod.com
"A great lathe operator commands several times the wage of an average lathe
operator, but a great writer of software code is worth 10,000 times the
price of an average software writer."
~ Bill Gates
 
J

Jan Burse

Roedy said:
I was under the impression all string constants lived in the same pool
along with the interned strings. That would imply a shared constant
pool since day 1. Have I had this wrong since Java 1.0?

Yeah, probably the answer is not a good one. Blurring
the compiletime format of byte code with the runtime
representation of a string.

But I guess there is a difference between Hotspot
and Dalvik in compiletime, the Hotspot Bytecode has
different pools per class, and the Dalvik has a single
pool.

What this implies for the runtime, I don't know. I
even don't know whether the constants from the pools
go into memory via intern(). The constant pool can
also have floats etc.. And there are complications
such as:

"Class data sharing (CDS) is a feature introduced in J2SE 5.0 that is
intended to reduce the startup time for Java programming language
applications, in particular smaller applications, as well as reduce
footprint. When the JRE is installed on 32-bit platforms using the Sun
provided installer, the installer loads a set of classes from the system
jar file into a private internal representation, and dumps that
representation to a file, called a “shared archive”. If the Sun JRE
installer is not being used, this can be done manually, as explained
below. During subsequent JVM invocations, the shared archive is
memory-mapped in, saving the cost of loading those classes and allowing
much of the JVM's metadata for these classes to be shared among multiple
JVM processes. etc.."
http://openjdk.java.net/groups/hotspot/docs/RuntimeOverview.html#VM Class Loading|outline

Possibly the best idea is to say it is implementation
dependent what happens with the Strings in the constant
pool. You can try the following test code:

class A {
String t = "hello";
}

class B {
String t = "hello";
}

if (A.t == B.t) {
System.out.println("yes");
} else {
System.out.println("no");
}

The bottom line could be, that we are not in position to
say what the above program does alone from the Java
Language Specification, since it is JVM implementation
dependent. But I might be wrong.

Bye
 
M

markspace

I was under the impression all string constants lived in the same pool
along with the interned strings. That would imply a shared constant
pool since day 1. Have I had this wrong since Java 1.0?


Yes, I'm pretty sure you've been wrong if that's what you thought. Each
class has its own pool of strings. If you have a class with a constant
string:

String a = "a";
String b = "a";

The constant "a" is only stored once, and a==b will be true. But that's
only for a single class file. Outside of the class file, each string is
unique and a different object. I don't think any implementations of the
JVM called String.intern() for each constant string read in each class file.

And certainly if you read a string from a file or the network, the VM
does not call String.intern() for you. That would be silly.
 
J

Jeff Higgins

I don't think there is anything new here.

Well, we do now have a couple of java.lang.String.join() methods.
And a java.util.StringJoiner class.

Thanks to all for prompting me to look.
 
E

Eric Sosman

Yes, I'm pretty sure you've been wrong if that's what you thought. Each
class has its own pool of strings. If you have a class with a constant
string:

String a = "a";
String b = "a";

The constant "a" is only stored once, and a==b will be true. But that's
only for a single class file. Outside of the class file, each string is
unique and a different object. I don't think any implementations of the
JVM called String.intern() for each constant string read in each class
file.

// Foo.java:
public class Foo {
public static String HELLO = "Hello";
}

// FooBar.java:
public class FooBar {
public static void main(String[] unused) {
System.out.println("Foo.HELLO == \"Hello\": "
+ (Foo.HELLO == "Hello"));
}
}

.... prints

Foo.HELLO == "Hello": true

.... on my Java 1.7.0_51 system. You might also want to re-read
Section 3.10.5 of the Java Language Specification; for Java 7 and 8
it reads (in part)

"Moreover, a string literal always refers to the /same/
instance of class String. This is because string literals -
or, more generally, strings that are the values of constant
expressions (§15.28) - are "interned" so as to share unique
instances, using the method String.intern."

Java 6 words it a bit differently:

"String literals-or, more generally, strings that are the
values of constant expressions (§15.28)-are "interned" so
as to share unique instances, using the method String.intern."

.... and goes on to give a multi-class, multi-package example.
And certainly if you read a string from a file or the network, the VM
does not call String.intern() for you. That would be silly.

That would be silly, yes. But the handling of literals is
a different matter, and does not behave as you described.
 
T

taqmcg

If we extend Eric's comments with the relevant quote from the Java 1.0 spec(in 3.10.5):

Each string literal is a reference (§4.3) to an instance (§4.3.1, §12..5) of class String (§4.3.3, §20.12). String objects have a constant value. String literals-or, more generally, strings that are the values of constant expressions (§15.27)-are "interned" so as to share unique instances, using the method String.intern (§20.12.47).

So just as Roedy suggested this is the way it has been since day 1.

Regards,
Tom McGlynn
 
S

Stefan Ram

If we extend Eric's comments with the relevant quote from the Java 1.0 spec (in 3.10.5):
Each string literal is a reference (§4.3) to an instance (§4.3.1, §12.5) of class String

It would be more correct to say that the /value/ of
a string literal is a reference, not the literal itself.
String literals-or,

In JLS 8, now, there is a space in front of the hyphen and
another space after the hyphen. This is real progress!
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,902
Latest member
Elena68X5

Latest Threads

Top