Re: After deserialization program occupies about 66% more RAM
On 19.09.2006 15:24, Paul Davis wrote:
Robert Klemme wrote:
On 19.09.2006 14:32, Paul Davis wrote:
Changing the code to actually show the internal reference shows that
the deserialized version produces the same results as the one before
What exactly do you mean by "same results"? Of course string values
I apologize for being unclear, by same results, I meant that:
System.out.println(a1 == a2);
for (int i = 0; i < a1.length; ++i)
System.out.println(i + ": " + (a1[i] == a2[i]));
produced the same output as:
System.out.println(c1 == c2);
for (int i = 0; i < c1.length; ++i)
System.out.println(i + ": " + (c1[i] == c2[i]));
Ok, now I understand. But that was not the main point of that piece of
meaning that there is no difference between the original values and the
With regard to internal relationships between instances, yes. But
deserialized instances are differently set up with regard of size and
sharing of the internal buffer.
remain the same. I was talking about internal representation (i.e. the
char arrays used). You cannot see that with a Java program alone, you
The intern() method returns a reference to the internal reference used
by the string object (according to the javadoc anyway).
I am not sure I fully agree, there is no such thing as an "internal
reference". "interned reference" is probably a bit better.
String.intern() will either return the same ref and store it in its
internal map (or whatever representation Sun chose) or you get a
reference to another instance representing an equivalent string but
already present in the internal data structure.
A pool of strings, initially empty, is maintained privately by the class
When the intern method is invoked, if the pool already contains a string
equal to this String object as determined by the equals(Object) method,
then the string from the pool is returned. Otherwise, this String object
is added to the pool and a reference to this String object is returned.
Using intern() might also be a bad idea for changing data because
interned strings will continuously increase the VM's memory. This might
not be an issue for short lived applications but it certainly can be for
long running apps.
I agree the intern() method should probably never be used. I was using
it here to demonstrate that the objects were pointing to the same
Not exactly: you interned the strings after deserialization and thus it
comes at no surprise that they point to the same instance after you did
Please forgive but, I don't understand what the example is trying to
demonstrate when the tests performed on the deserialized objects
produce the same output as the tests on the original objects.
As said, that output was not the main point. As I wrote above, set a
breakpoint at the line indicated and then look at object identities.
Then you'll see what I mean and try to convey from the beginning.